[SharpMZ] Emulator MZ-800

[Michal Hucik - ORDOZ]

Verze emulatoru, kterou jsem zverejnil nepouziva zadnou HW akceleraci 
pri vykresleni okna. Vse probiha pres interni framebufer, nad kterym 
provadim jednoduchou analyzu bloku, ktere se zmenily a podle toho 
aktualizuju jen tyto jednotlive casti obrazu. Proto tedy dochazi k tomu 
vyraznemu zpomaleni pri resetu, protoze se tam vykresli stavajici obsah 
cele VRAM, a po zmene rezimu na MZ700 pak dojde ke globalni zmene celeho 
snimku.

Moje emulace provadi aktualizaci vsech signalu po kazde vykonane 
instrukci. U slozenych instrukci, jako je napr. LDIR probiha aktualizace 
i po kazdem internim  instrukcnim prubehu. Navic si myslim, ze pro  
naprosto presnou emulaci je nutne aktualizovat vsechny signaly i uvnitr 
vsech IORQ operaci a take uvnitr MEMOP operaci, ktere pracuji s VRAM - 
alespon ja to tak delam...

Co se tyka sledovani prubehu paprsku, tak tam se proste neda nic 
preskocit. Zapis do framebuferu si musi poctive projit pres kazdy pixel 
obrazu. Jinak by ti nefungovaly spravne treba tyhle obrazove efekty 
http://mz-800.xf.cz/pics/gpsim.gif , 
http://mz-800.xf.cz/pics/gardner.gif ...

Uz jsem premyslel treba nad tim, jak to cele zrychlit napr. tim, ze se 
ani ve framebufferu nebudou vykonavat snimky, ve kterych se nic 
nezmenilo, nicmene tim sice paradne zrychlim celeho Sharpa, ale stejne 
si nepomuzu v ramci normalne realizovaneho snimku, coz je mnohem 
dulezitejsi. Tam proste primarne tech 20 ms nesmi byt nikdy prekroceno.

Zdenkova emulace mi sice bezi na 8500% rychlosti, ale kdyz napr. v Turbo 
Copy nahravam program v rychlosti 3600 baudu, tak diky pruhum v borderu 
uz ta rychlost sleti cca na 1500 % - coz je samozrejme porad super, ale 
je na tom krasne videt, ze vetsinu te "klidove" rychlosti cini prave to 
vynechavani obrazovych rutin ve chvili, kdy se na obraz nesaha.

Experimentuju ted s HW akceleraci obrazu, cimz uz alespon na svem 
pomerne nabusenem PC dosahuju cca 400% a to i v pripade, kdy roztahnu 
okno Sharpa na fullscreen - ovsem ventilator na grafice pak rve jako 
kdyby mi pod stolem startoval vrtulnik.
Bohuzel takto realizovany obraz je naprosto nepouzitelny v mem Linuxu. 
Pouzivam virtualizovany Linuxovy desktop jako sve nativni vyvojove 
prostredi. Tam je ta absence HW akcelerace saframentsky znat a projevi 
se to tim, ze emulator bezi cca na 8%. Dokud se mi toto nepodari 
zlepsit, tak budu muset zrejme podporovat obe varianty obrazoveho vystupu.

Michal

Dne 19.12.2014 v 21:40 Miloš napsal(a):
> Michal, ja by som nejakú spätnú väzbu mal. Celkom mi nie je jasné, prečo
> sa tak pomaly prekresluje obrazovka pri resete a zmene typu monitora.
> Priznám sa, že som zatiaľ stiahol len tú najstaršiu verziu emulátora a k
> tým novším som sa ešte nedostal, aby som ich stiahol, ale mám v pláne aj to.
>
> My sme boli asi jediní, čo sme mali Sharpa takého, že keď sme ho zapli,
> tak tam bolo vždy 128 bajtov 00 a 128 bajtov FF a takto celá pamäť.
> Zdeňkov Sharp a zrejme aj ostatné to mali takto FF FF 00 00 FF FF a
> potom po 128 bajtoch zas naopak.
>
> No a teraz sa vrátim k začiatku. Náš Sharp sa zresetoval asi do cca 0,4
> sekundy. Približne tak to trvá aj môjmu emulátoru a krásne tam vidieť
> mapu pamäte (128 bajtov 00, 128 bajtov FF). Potom monitor nahodí farbu a
> nahrá CGRAM. Nepamätám si, či bolo v pamäti najprv FF a potom 00 alebo
> naopak. Výsledok je taký, že ak FF, tak naskočí tá "mapa", potom naskočí
> biela obrazovka, lebo v CGRAM na začiatku sú FF, potom sa prekreslí na
> modro a nakoniec naskočí text. Ak je najprv 00, tak je to to isté, len
> sa z "mapy" zmení obrazovka na modrú (lebo na začiatku CGRAM sú 00) a
> potom naskočí text, Celé to trvá asi 0,3 sekundy.
>
> Nerozumiem teda prečo to v tvojom tak pomaly prekresľuje. Je to len tým
> "zapnutím" alebo je to celkovo problém s pomalým prekresľovaním
> obrazovky? Neviem ako to robí Zdeněk, ale ja som začal prekresľovanie
> riešiť tak, že som uložil informáciu, ktorý riadok treba prekresliť a
> prekresľoval som, ak to bolo nutné. Border som prekresľoval vždy. Potom
> som vyhodil počítanie po jednotke a postupné posúvanie lúča a ak to
> nebolo nutné, tak som rovno posúval lúč podľa toho, aká dlhá bola
> inštrukcia. Toto mi rapídne emulátor zrýchlilo a potom som ešte zrušil
> aktualizáciu borderu, ak sa nezmenil. Z rýchlosti 176 % som sa dostal na
> 540 %. Pokusne som odpojil aj procesor a vyšlo to na cca 690 %, ak sa
> dobre pamätám, takže procesor mám optimalizovaný asi relatívne dobre a
> jednoducho Lazarus viac nedokáže. Alebo je chyba inde, neviem. Ale
> nechápem ako Zdeněk dokázal rozbehať 4500 % (všetko namerané na mojom
> počítači). Bojím sa, že ak raz budem mať zvuk a virtuálne CMT, tak
> klesnem hlboko pod 100 %.
>
> Ja som zo Zdeňkovho kódu videl iba unitu na spracovanie MZS. Je to
> čitateľné celkom dobre. Išlo mi o skompatibilnenie môjho emulátora s
> jeho, keď raz dôjde na MZS. No a už som to síce Zdeňkovi raz písal, ale
> zrejme sa to k nemu nedostalo, v emulácii je chyba, pri načítaní MZS sa
> nespustia časovače (krásne to vidieť na Nipsoft Commanderi alebo v
> BASICu pri ? TI$
>
> Miloš
>