Просмотр полной версии : подскажите насчет slow memory в родных машинах
Хотел multicolor 8x2 на компо выкатить, под pentagon бысто вьювер написал, а вот со spectrum128 (смотрю на EmuZWin 2.7) проблемы начались.
Вектор прерываний в #BE00 - 256 байт.
сам код активный раскранчиваю с #8000 по #BC00.
когда я пропушиваю стеком 2 строчки на втором экране, то показываю первый. когда я пропушиваю стеком 2 строчки на первом экране, то показываю второй.
я так понимаю, что на 1 и 2 экране это занимает разное количество тактов.
А вот на сколько именно больше тактов занимает эта процедура в медленной памяти ?
я использую вот такой цикл на 2 линии:
LD SP,NN-----10 t
LD HL,NN-----10 t x16=160
PUSH HL------11 t x16=176
ADD HL,BC----11 t x4=044
INC HL------06 t
NOP--------04 t
INC HL------06 t
NOP--------04 t
INC HL------06 t
XOR E------04 t
OUT (C),A--12 t
итого-------432 tacts (строка в spectrum128 должна быть 216)
и еще, что там с нечетнотактовыми коммандами ?
я так понимаю, что на 1 и 2 экране это занимает разное количество тактов.
как бывший владелец двухполевой машины докладываю, что оба экрана тормозные (если я правильно понял вопрос)
PUSH HL------11
вот тут будет засада.
5 тактов уйдёт на чтение комманды и её декодирование (из быстрой памяти)
6* тактов уйдёт на запись (так как запись идёт в медленную память, то может уйти больше тактов). причём если в это время отрисовывается бордюр, то торможения не будет (в этом я не уверен на все 100, надо схему байта искать)
sinus, я к сожалению на пейпере все время, речь то о картинке.
И кстати, компо то на кот. я хочу успеть, у вас =)
Так как узнать то сколько тактов занимает в медленной памяти тот же push например.
И вообще, существуют где-нибудь данные о весе в тактах комманд z80 в быстрой/в медленной памяти ?
---------- Post added at 05:20 ---------- Previous post was at 05:20 ----------
я тут попробовал раскранчить код из расчета того, что push = 12 tacts
LD SP,NN--------10 t
LD HL,NN--------10 t x16=160
PUSH HL---------12 t x16=192
LD HL,(#8000)---16 t x03=048
LD A,A----------06 t
XOR E-----------04 t
OUT (C),A-------12 t
итого-------432 tacts
но все равно все криво отображается =(
а попробуй просто подогнать n-ным количеством лишних нопов. если есть время, сделай смену цвета бордюра, будет видно, в какую сторону крутить задержку (т.к. если все синхронно, излом на бордюре должен быть по верт. линии).
psb, да оно не стабильно - дрожит и в четное прерывание отрисовывается отлично от нечетного.
И потом 216 tacts per line - это ж точно !!!
Неужели это такая проблема, узнать растактовку в медленной памяти ?!
ну у тебя ведь сам innerloop отрисовки всегда одинаковое кол-во тактов занимает? если считать без заморочек? когда спек тормозит, он точно так же тормозит всегда одинаково, пока рисует папер. пиксельная точность тебе не нужна, поэтому думаю можно подогнать "на глаз", не высчитывая.
дрожит
сложно представить, как это... я бы все равно порекомендовал юзать бордюр, хотя бы первое время (пусть вместо вывода части картинки).
и в четное прерывание отрисовывается отлично от нечетного.
так ты их по отдельности отстрой:)
Неужели это такая проблема, узнать растактовку в медленной памяти ?!
может и не проблема, но... все забыто... наверняка если копать где-нить на WOSе, то можно все найти.
---------- Post added at 12:55 ---------- Previous post was at 12:53 ----------
кстати, LD A,A = 4 такта
rOm, насчет HT не заморачивайся, там точно Pentagon будет compo машиной. А рабочий вьювер под фирменные компы есть у Pulsar'a, посмотри картинку Risk'a c последнего Forever'a, к примеру. Думаю он сам здесь отпишется, что да как.
Неужели это такая проблема, узнать растактовку в медленной памяти ?!
вот тут описанно: http://scratchpad.wikia.com/wiki/Contended_memory
Но чтобы знать когда же сработал твой push в экран относительно положения луча нужно обязательно поменять цвет бордюра перед push-ем и потом обратно после push-а тогда будет четко видна черточка на бордюре (если черточка будет дрожать значит прога каждый раз попадает на разные циклы задержки и надо подгонять дальше).
доберусь домой отпишу.
вот что откопал (http://zx.pk.ru/showpost.php?p=219937&postcount=159), пока была пара минут.
всем спасибо! написал, оказалось, что это должно выглядеть так:
LD SP,Nn-----10
LD HL,Nn-----10 x16
PUSH HL-----?? x16
LD H,N------07
XOR E------04
OUT (C),A--12
хотя так и непонял я, ведь если все такты кроме push hl суммировать и вычесть эту сумму из 432, то должно получиться время (push hl) x 16.
432 - 193 = 239
делим на кол-во (push hl) и получаем время 1 (push hl)
239 / 16 = 14,9375 !
прицепил "вьевер" для пентагона/класики с черездвухстрочником. останется только заменить в tap'е/scl'е картинку на свою и можно отправлять на конкурс (tap версия пофикшена под классический спек, scl под пентагон). ссылку на исходник прицеплял где-то выше.
r0m, все не совсем так на самом деле все примерно так как пишет conan (http://zx.pk.ru/showpost.php?p=1675&postcount=11). просто в ту логику, по которой работает мультиколор 8х2 не всякий мультиколорный режим ляжет в реализации на классичесом спеке.
а вообще забавно на дворе 2010 год, на спеке все еще что-то открывается "новое", и как ни странно мы приходим к классическому спеку, и уже не так от него отмахиваемся как скажем в 96-03гг...
doorsfan
15.04.2010, 22:47
да, +2а и обожаемый Клоном +3 к классическим не относятся. там в очередной раз поменяна растактовка экрана: про мультиколоры от 128 (и+2 серый) можно забыть.
странно что Animeeshon.tap практически не отличимо работает на emuzwin при переключении конфигураций 128/+2/+2A/+3
doorsfan
16.04.2010, 02:52
может детектит наличие порта 1ffd?
Ну а в LYRA2 в первой-же части вместо земного шарика - атрибуты.
да нет, на лету можно переключать
а вот такой еще вопрос:
Конан пишет http://zx.pk.ru/showpost.php?p=1675&postcount=11
"Начало экрана в ZX Spectrum 128 и +2 +2A,+2B,+3 это: 14364 такт он прерывания."
а TMK использует такую конструкцию ожидания :
ld bc ,575---10t
dec bc------06t
ld a,b-------04t
or c---------04t
jp nz,--------10t
575 * 34t = 19550
почему эти цифры не совпадают ?
а TMK использует такую конструкцию ожидания :
ld bc ,575---10t
dec bc------06t
ld a,b-------04t
or c---------04t
jp nz,--------10t
575 * 34t = 19550
почему эти цифры не совпадают ?
потому, что:
jp nz на dec bc
575 * 24t = 13800
+ чего-то до и после.
sorry, заморочился с LD BC,NN , но все равно 13800 и 14364 , что это за разница ?
---------- Post added at 01:09 ---------- Previous post was at 00:46 ----------
прицепил "вьевер" для пентагона/класики с черездвухстрочником. останется только заменить в tap'е/scl'е картинку на свою и можно отправлять на конкурс (tap версия пофикшена под классический спек, scl под пентагон). ссылку на исходник прицеплял где-то выше.
спасибо, а в каком там формате лежит дата , 19456 bytes ?
вроде gigscr = 18432 ? Если вьювер в boot'e, то что за лишние байты на диске ?
я то себе сам хотел написать не только, что бы подвспомнить asm, но и потому, что я multicolor тот рисовал в BMP2SCR_Pro_2_01.exe А он просто сбрасывает 6144 scr + 6144 attr даже если 8x2, a не 8x1.
все равно без перефасовки б не обошлось
r0m, "вьевер" с черездвухстрочным интерлейзом для multigigascreen'а 8х2 в формате mg2 by tmk (из multiartist):
For MG1,MG2,MG4,MG8 file have HEADER 256 bytes length
-------------------------------------------------------------------------
[3] MGx_FILE_ID Identifier for MG files = "MGH" (Milti Gigascreen ZX File Header)
[1] MGx_FILE_VER MG zx file format Version
[1] MGS_CharSize Size of Char[1=8x1, 2=8x2, 4=8x4, 8=8x8]
[1] ZX Color1 Border
[1] ZX Color2 Border
Data Format *.MG2
-------------------------------------------------------------------------
[6144] BitPlane0 Interlaced Bit Data (ZX original screen bitplan)
[6144] BitPlane1 Interlaced Bit Data (ZX original screen bitplan)
[3072] MGSAttr0 Linear MultiGigaScreen ATTR Data
[3072] MGSAttr1 Linear MultiGigaScreen ATTR Data
sorry, заморочился с LD BC,NN , но все равно 13800 и 14364 , что это за разница ?Нужно смотреть какой код кроме этой процедуры ожидания выполняется между прерыванием и началом экрана.
на прерываниях - ret
в осн. коде
...
halt
call wait.........17 t
ld a,#1f.........7t
ld e,8............7t
ld bc,#7ffd.....10t
out (c),a........12t
ld (nn),sp........20t
jp на расписанный строчный код, еще 10t,
итого после ожидания циклом еще плюс 66, и до - call + ret+ ldbc = 37.
24t * 575 = 13800
103 + 13800 = 13903
wait
ld bc,575....10t
dec bc.....6t
ld a,b.......4t
or c........ 4t
jp nz,......10t
ret..........10t
jp на расписанный строчный кода что этот код делает (где результат визуально проявляется на экране)?
это поехала печать
ld sp,NN
( ld hl,NN : push hl ) x 16раз
с конца в начало 1ой строчки пейпера
А почему эта печать должна начаться точно в момент отрисовки пейпера, а не чуть раньше?
P.S. Понятно, если бордюрные эффекты (по верхему краю экрана), а тут для чего привязка к началу экрана?
нуна за 2 строки до экрана, т.е. -4хх тактов.
нуна за 2 строки до экрана, т.е. -4хх тактов.тогда оно ровно так и получается: 14364-13903=461
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot