Emulátor Z80 na Motorole 680x0 z roku 1994 v dnešním kontextu

Emulátor byl uložen v archívu a nebyl nikdy zcela dokončen.

Projekt byl spuštěn v mých 19 letech, když jsem učil na střední průmyslové škole 16-leté studenty používání kancelářského softwaru na desktopu. Konkrétně ClarisWorks na počítačích Apple (16/20MHz 680×0). Počítače byly spojeny do sítě AppleTalk (fyzicky propojené klasickými telefonními kabely).

Emulátor je vydán jako 20 let stará technologie, která v roce 2014 ukazuje, že se všichni mýlíme, když si myslíme, že dnešní GHz mobilní procesory jsou pomalé a žerou baterku. Je to všechno jinak, problém je ve špatném softwaru.

Vzpomeňte si na roky 1993–4, kde byl PC svět? Ve světě Maců byl plně grafický desktop a použití sítí, ale všechno bylo velmi jednoduše použitelné pro běžné lidi. Také tu bylo RAD databázové vývojové prostředí 4th Dimension. Žádné programování, „kreslení“ oken pomocí myši (tlačítka, texty, obrázky, grafická tlačítka…), „kreslení“ relační databáze pomocí myši. Univerzální spustitelný soubor pro lokální spuštění i pro použití jako klient/server. Všechno mnohem jednodušší než Borland Delphi později na Windows. Všechno fungovalo na 16/20MHz barevném (8bit/16bit/24bit barvy) grafickém desktopu s myší včetně spojení do lokální sítě. Rok 1993!

Emulátor běžel v roce 1994 na MC68030/16MHz (writethrough cache na procesoru) zhruba na 80% rychlosti skutečného 8bitového ZX Spectra, které běželo na 3,5MHz. Na MC68040/20MHz (writeback cache) běžel emulátor rychlostí 120% původního Spectra s plnými grafickými efekty. To znamená, že emulace byla o 50% rychlejší, i když procesor měl jen o 25% vyšší frekvenci, právě kvůli writeback cache na procesoru. Také se podívejte na frekvenci, Motorola je 4 až 5 krát rychlejší ve frekvenci. Emulátor má 4–5 instrukcí assembleru Motoroly na jednu instrukci Z80. To znamená, že 8bitový procesor Z80 je porovnatelně stejné rychlosti/efektivity na stejné frekvenci (bez cache) jako o 10–15 let novější Motorola. Kromě toho, že MC680×0 má 32bitovou datovou sběrnici a je teoreticky 4× rychlejší při přesunu dat v RAM kvůli rozdílu mezi 8bit x 32bit :)

Simulace počítala pozici paprsku na obrazovce ve spojení s časováním instrukcí a díky tomu bylo možné měnit barvu na každém řádku obrazovky Spectra. Díky tomu bylo možné dělat BORDER efekty na ZX Spectru a také měnit nezávisle každý pixelový řádek – stejně jako na skutečném Spectru.

Zdrojáky jsou beze změny 20 let (včetně komentářů v češtině). Opustil jsem práci na projektu v roce 1994 kvůli kritické chybě v Macintosh ROM. V okamžiku předání kontroly kooperativního multitaskingu systému pomocí SystemTask(), změnila náhodně ROM (čas od času) registry D0 a D1. Aplikace dělala náhodně neočekávané chyby při používání D0 a D1. Odkrokoval jsem debuggrem System ROM a ta neukládala D0 a D1 na zásobník v okamžiku změny hodnoty. Myslím si, že toto byl tehdejší problém občasného celkového zamrzání Macintoshe. Ve 20 let starém „Think C“ (vývojářský software s knihou o programování aplikací pro počítače Apple umožňující programování v C a inline assembleru), si můžete přečíst jednu větu. Toto bylo napsané v knize o D0 a D1: „Není doporučeno používat D0 a D1 na ukládání hodnot na delší dobu.“… WTF!!! Stále si to pamatuju, nikdy to nezapomenu.

Dvě fotky obrazovky ukazují spuštění emulátoru, ale v okamžiku přepnutí na 16 barev a použití celé obrazovky, uvidíte bílou plochu monitoru ZX Spectra a černý okraj desktopu Maca. Překladač instrukcí Z80 běží, ale problém je, že grafika je tvořena přímým zápisem do VideoRAM Maca na paměťovou adresu v assembleru. Pravděpodobně emulátor Maca to nezvládne na 32bitové barevné hloubce na desktopu Debian/Linux. Také emulace instrukcí Z80 je hotová na 99% a není dokončena. ZX Spectrum nastartuje do BASICu, můžete psát na klávesnici, vyzkoušet BORDER efekty v BASICu pomocí PAUSE 1 atd…, ale stále jsou tam nějaké chyby ohledně Z80 překladu.

Z80 se na MC680×0 mnohem hůře emuluje než na x86 procesorech. Některé Z80 flagy na 680×0 chybí a musíte je vypočítat. Intel x86 ty flagy má a je mnohem jednodušší emulovat Z80 na x86. Celkově emulace na x86 bude vždycky rychlejší, protože na MC680×0 se musí dopočítávat stavy procesorových flagů.

Nejzajímavější věc na tomto emulátoru je velikost všeho. Spustitelný soubor má 36KB včetně 16KB ZX Spectrum ROM. To znamená, že celý spustitelný soubor emulátoru je jen 20KB Mac aplikace včetně celé emulace instrukční sady Z80. Emulátor využívá 750KB RAM, aby byla dosažena vyšší rychlost v assembleru (víte proč?). Refresh/R registr je také emulován atd. V době, kdy jsem psal emulátor, jsem chtěl spustit „ochranný systém Arnold“ napsaný Františkem Fukou. To je důvod, proč jsem emuloval hodnoty v registru R.

Můžete si stáhnout HFS/1MB obraz disku obsahující spustitelný Z80 emulátor (25KB zazipováno) a připojit ho v nějakém Mac emulátoru. Další možnost je zkusit kompletní kolekci souborů včetně zdrojáku Z80 emulátoru (26KB zip soubor.

Konec vysvětlení Z80 emulace na MC680×0.

---

Začátek informací o zdrojácích, aplikacích a optimalizacích na jiných platformách.

Zdroják emulátoru Z80 není dobrý příklad hezkého zdrojáku, ale příklad jak něco udělat, aby to běželo extrémně rychle na pomalém hardware. Jestli chcete vidět lepší zdroják, podívejte se na zdrojové kódy javascriptové hry Kameny. Podívejte se na rychlost algoritmu a časovací pauzy, když hraje každý hráč. Celý zdroják javascriptové hry je obsažen v 11KB HTML stránce.

Jiný příklad optimalizace software na velikost napsaný v Borland Delphi (zdrojáky už nemám, je mi líto) je vlastní hra puzzle pro moji dceru. Můžete aplikaci spustit pod Linuxem pomocí WINE jako samostatný 1270KB .exe soubor pro Windows (1MB zip ke stažení). Aplikace obsahuje uvnitř 27 různých obrázků pro skládání puzzle. Můžete si obrázky i texty uvnitř aplikace změnit na svoje vlastní, pokud víte, jak to udělat… je to jednoduché.

A v neposlední řadě… nejkratší program a extrémně kompresovaný algoritmus. Nemyslím tím samotný krátký zdroják, ale algoritmus založený na maticích (anglicky Matrix). Jen 3 řádky kódu samotného algoritmu v Javascriptu z roku 1998: (arab-rim.zip)

---

---

Tento blog post ukazuje, že vím o čem mluvím, když píšu o tom, „Co je špatně na Androidu?“ a taky si k tomuto tématu můžete přečíst „Pohádku o Softwarovi“.