[SharpMZ] Neco noveho o GDG

[Michal Hucik - ORDOZ]

Pomerne dlouho uz se vi, ze v rezimu MZ-700 nelze pracovat s VRAM ve 
chvili, kdy zrovna paprsek leti po obrazovce - pri zapisu 1. bajtu to 
jeste projde bez perzekuce, protoze je tam zrejme nejaky latch, ale pri 
zapisu druheho, nebo pri jakemkoliv cteni obdrzite okamzite WAIT az do 
HBLN +/- (kolik je to +/- snad jednou zjistime z analyzy GDG).

Co se ovsem doposud nevedelo je to, ze ta mrcha GDG posila WAIT i v 
rezimu MZ-800 !!! Proto je tedy napr. u Patikova FX sound 4 ten sedy 
pruh v emulatorech umisten malinko vyse, nez na realnem HW.

Prozatim jsem to tedy jeste moc nezkoumal, nicmene vypada to, ze WAIT 
obdrzime jen pri cteni VRAM. Podle mne proto, ze fyzicky se tusim 
nacitaji ty ctyri video banky na 2 faze a 3. faze je potom cas, ktery je 
pridelen pro komunikaci s CPU. Pri zapisu se zrejme vyuzije ten latch a 
k WAITu nedojde ... Budu muset jeste analyzerem opichat ridici signaly 
VRAM, abych si udelal jasno o tom jaka je tam perioda, protoze z toho co 
jsem nameril jsou ty WAITy dlouhe v rozpeti 1 - 4 cpu takty.

BTW: prijde mi to celkem jako zajimave zjisteni nejen z duvodu emulace, 
ale napr. proto, ze kdyz jsem kdysi programoval engine Pushovera, tak 
jsem skoncil m.j. na tom, ze pri animaci v horni casti obrazovky uz mi 
to docela poblikavalo. Je dost mozne, ze kdybych se pri animaci vyhnul 
nacitani spritu z VRAM, ale tahal je z normalni RAM, tak bych zrejme 
usetril trochu strojoveho casu a paprsek by mne nedohnal...

Michal


------------- další část ---------------
HTML příloha byla odstraněna...
URL: http://mail.ordoz.com/pipermail/sharpmz/attachments/20170209/384e7973/attachment.html