<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font size="+1"><br>
</font></p>
<p><font size="+1">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).<br>
</font></p>
<p><font size="+1">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.</font></p>
<p><font size="+1">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.</font></p>
<p><font size="+1">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...<br>
</font></p>
<p><font size="+1">Michal</font></p>
<p><font size="+1"></font><br>
</p>
</body>
</html>