Virtuális retro: emulátorban fejleszteni? (Avagy: így programoz(t)unk mi!)

A programfejlesztés régen úgy ment, hogy az ember begépelte a mágikus MONITOR parancsot, ezzel belépett egy egyszerű assembly nyelven programozni / hibát keresni segítő „felületre”. Ez volt a TEDMON, ami igen nagy segítség volt ahhoz, hogy gépi kódban az ember elkezdjen alkotni. A C64-ből pl. hiányzott ez a „segédprogram”, ott egy csomó ilyet készítettek, de mindet be kellett tölteni, foglalta a memóriában az amúgy se bőséges helyet. (Persze a bővítőkártyák, mint az Action Replay meg a Final Cartridge már megoldották ezt a problémát, sőt, de ez itt erősen off.)

Ezzel a kis utility-vel a memóriát lehet közvetlenül turkálni, mindenféle módon nézegetni, de az alapvető I/O műveleteket is el lehet innen végezni. (Memóriába betöltés / memóriából mentés kazettára / floppyra leginkább...) Nem egy „bolondbiztos”, „felhasználóbarát” dolog, de ahhoz képest igen érdekes alkotások születtek a segítségével. (Nem „Felhasználóbarát”? Mit szólnak ehhez a kijelentéshez azok, akik lyukkártyákkal nyomták... :) ) Persze ma már hosszabb programok lekódolásához nem állnák neki a segítségével, de régen nem volt más. Voltak persze különböző assemblerek, de mindegyiknek megvolt az a hátránya, hogy foglalták a memóriát. Ez még nem az az éra, amikor a beírt parancsot a háttértárról töltjük be gyorsan... Szóval maradt „ez”.

Nálam egy későbbi időszakban már PC-n „folyt” a fejlesztés. DOS-ra volt egy cross-compiler, a TASM, ami akkor szinte „szabvány” keresztfordító volt, egy csomó fajta CPU-t támogatott, köztük a 6502-őt is. Ennek a processzornak a leszármazottja, egy vele teljesen kód-kompatibilis CPU van a plus/4-ben, 8501 típusszámon. (A C64-ben levő 6510 is 6502-es „mag”.) (Érdekesség: ez a fordító úgy tudott sok fajta CPU-t, hogy az architektúrák „leírása” egy mezei szövegfájlban van, mindegyik targethez saját. Másik processzort hozzáadni emiatt nem egy bonyolult feladat, a linkelt archívban is van vagy 10 fajta...)

Az assembler csak egy dolog, a leforgatott cuccot valahogy át kellene varázsolni a „célgépre”, ami nem egy egyszerű feladat. (...volt akkoriban.) Hiába volt (mert akkor még nekem volt) 5¼-es floppy meghajtó a pécében, azzal nem lehet olyan formátumban írni a lemezt, hogy egy 1541 (ill. 1551) el tudja olvasni, így más megoldás kell... Az egyik az, hogy magát az 1541-et kapcsolom a PC-hez, erre akkortájt már volt lehetőség (X1541 kábel és különböző változatai, emlékszik még rá valaki? :) ), de két meghajtóm nem lévén, elég szívás a szituáció. Meg egyébként is, lemezezni kényelmetlen. A megoldás az lett, hogy a PC párhuzamos portot összekötöttem a Plus/4 USER portjával, így volt 12 jelem adatátvitel + handshake céljára. Ehhez készült négy program, vagyis két programpár. Az egyik pár a PC → plus/4 a másik meg a plus/4 → PC irányt valósította meg. A PC-s oldal TurboPascal-ban készült, az adatátvitel 8088 assemblyben. (Ezt valamennyit még a szakközépben tanultam, akkor döntöttem el, hogy ezt a sz... én nem fogom programozni... :) ) A plus/4-es oldal egyértelműen asm, csak annyival lett megvadítva, hogy a KERNAL-t (a gép ROM-jában levő FW egy része) egy kicsit „megmókoltam”, megszakításból figyelte a PC-s kommunikáció igényét, ha akart valami jönni, akkor mindenféle user aktivitás nélkül szépen „elszedte”. A DOS alatt használt VC-ben a lefordított „ojjektum” kiterjesztésére beállítottam a fájl-küldést, így a lefordított cuccot egy mezei ENTER-rel simán átküldtem a plus/4-be. Ez így már eléggé „user-friendly”. (A V2.0-s változat: a fordításhoz úgyis készítettem egy batch fájlt, az „áttolás” bekerült a végére, még egypár gombnyomkodás megspórolva... :) )

Azóta azért pár év eltellett, de még manapság is eszembe jut, hogy jó lenne újra nekiállni plus/4-re kódolni. A lelkesedés mondjuk elég hamar elmúlik... :) De ha mégis megmarad, akkor mi a legegyszerűbb módja a dolognak? Hát persze hogy a PC-s emulátor, mivel ezek a mai vasak már elég erősek ahhoz, hogy egy 27 éves hardvert emulálni tudjanak. Szóba jöhet két program, mondanom sem kell, mindkettő „hazai” fejlesztés. (Ill. van még pár... A VICE is jó lehetne, de ez inkább C64 emulációban erős. Aztán ott a minus4, ill. ennek a JAVA-s változata, az utóbbi megy böngészőben applet-ként... :) ) A most de facto szabványnak tekintett emu a Yet Another Plus/4 Emulator, vagy ahogy mindenki ismeri a YAPE. Jó kis stuff, de sajnos csak Windows verziója van. (Van neki egy OS, SDL-es változata is, de ősrégi, az alapgépen kívül gyakorlatilag semmit se emulál, emiatt maximum érdekességnek jó.) A program a wine segítségével tulajdonképpen használható Linuxon is, de eléggé „nemszeretem” módszer, jobb lenne a natív megoldás... (A tisztelt fejlesztő urat ugyan megkértük párszor, hogy az SDL-es változatot aktualizálja, de nem tűnik úgy, hogy magas prioritásúnak kezelné a feladatot... :) (Update: azóta azért ez a feladat is haladt sokat, most már ~elég jó az SDL-es verzió is.)) Mindenesetre ez az emu az, amivel a legtöbbször összefut az ember. De most nem erről lesz szó...

A másik emulátor a „nagy rivális”, a beszédes nevű plus4emu, ez egy „szép” multiplatformos szoftver. Viszont erről nem sokat hallani, vajon miért? Emulál mindent, amit kell, de nekem eddig nem sikerült beizzítanom valami miatt. Emlékeim szerint ezt anno le akartam magamnak forgatni, de az azért annyira nem egyszerű, kell hozzá egy marék devel cucc... Viszont most ahogy nézem a letöltési oldalt, vannak linuxra is előfordított bináris pakkok... A dátumokból ítélve ezek már akkor ott voltak, amikor próbálkoztam a forgatással. Azokról viszont semmi emlék... Valószínűleg a CenOS5-ben jó régi volt pár lib (szokás szerint...), ami miatt el se indultak, emiatt próbálkoztam volna? Na mindegy végül is, CentOS6 alatt most újra megpróbálva, hibátlanul megy, ráadásul az x86_64-es verzió. (Nesze neked wine-s YAPE... :) )

A „szép” nem véletlenül van idézőjelben; a felület az FLTK-re épül, pici, gyors, de legalább csúnya. (Persze ez ízlés kérdése... Nekem jobban bejön egy GTK-s vagy Qt-os felület, de jelentősége kb. semmi, úgyse azt nézzük... :) ) Ami egy kicsit „idegen” a menürendszerében, hogy a beállítások szét vannak szórva mindenfele, ez a rész nem túl barátságos, de persze meg van benne a logika. Jó esetben úgyis egyszer fogja az ember beállítani, utána már úgyse lényeges. De beállítani szó szerint MINDENT be lehet, ahhoz képest hogy milyen „sutácska” benyomást kelt, a tudása elég meggyőző... Az én „alap” beállításaim mellett kb. 40% körüli a CPU használata, de van egy izgalmas video-üzemmódja, ahol az emulált gép képfrissítési frekvenciáját „odakonvertálja” az éppen használt megjelenítőjéhez. Ez elég szépen megfekszi a gyomrát a gépnek, ilyet még nem láttam:

Olyat, hogy egy process 135%-os CPU terhelést okozzon, azért nem semmi elérni... :) Ettől függetlenül szépen működik döcögés nélkül így is... Tulajdonképpen arról van szó, hogy egy sok gigahertzes géppel emulálunk egy 886KHz/1.77MHz-s gépet... És kell is alá a vas. :) (Ez az, amikor izomból emulálunk egyszerű célhardvereket...)

Emu az van, kellene valami „környezet”, amivel fejleszthetek... A TASM-ot lehetne használni DosBox-szal, de az megint ilyen „nyögvenyelős” történet, azt inkább kihagynám. De volt anno egy másik assembler, amit használtam, arról az rémlett, mintha Open Source lenne... Csak mi is volt a neve? Talán AS? De erre rákeresve elég sok olyan találat jön, aminek köze sincs ahhoz, amire vadászok. De némi kergetőzés, meg verziószám keresés után meglett a darab: The Macroassembler: AS. „Ő” lesz az... Ebből az utolsó stabil az nem mai gyerek, de végül is ha működik, akkor nem baj ha régi. Viszont ebből tényleg nincs előfordított linuxos verzió, szerencsére nem túl bonyolult a fordítás. A README fájlban azt írják, hogy az installáláshoz olvassam el az INSTALL fájlt. Jó... Abban az írják, hogy:

1. see if there are additional README files for your platform
2. create a Makefile.def
3. compile
4. execute the test suite
5. build the documentation
6. install into the system directories

Az 1.41r8 változat 1999-es dátumú, szinte még friss ropogós... És persze nem akar fordulni (gondolom azóta történt egy s más a gcc háza táján...), de a „latest” az pörög egy kis túrás után. A második pont lényeges: a Makefile-ba belenézve „behúzza” az elején a Makefile.def-et. Ezt kell megalkotni, de szerencsére van egy Makefile.def-samples könyvtár, ott van jó pár minta a különböző platformokhoz. Ebből nekem a Makefile.def-i386-unknown-linux2.x.x a szimpatikus, ezt kell kimásolni a „gyökérbe” a Makefile mellé Makefile.def néven. Majd jöhet benne pár módosítás:

CFLAGS = -g -O3 -mcpu=i586 -fomit-frame-pointer -Wall
BINDIR = /usr/local/bin 
INCDIR = /usr/local/include/asl 
MANDIR = /usr/local/man 
LIBDIR = /usr/local/lib/asl 
DOCDIR = /usr/local/doc/asl 

Ezek a sorok módosulnak, mégpedig erre:

CFLAGS = -g -O3 -mtume=generic -fomit-frame-pointer -Wall
BINDIR = /usr/bin 
INCDIR = /usr/include/asl 
MANDIR = /usr/share/man 
LIBDIR = /usr/lib64/asl 
DOCDIR = /usr/share/doc/asl 

Az első sor csak annyit tesz, hogy nem i586 lesz a lefordított pakk architektúrája, hanem annak az alapja, amin a fordítás készül. Esetemben ez egy alap x86-64 lesz. A többi csak az install könyvtárak megadása, hogy kb. hasonlítson a jelenlegi felépítésre... A lib64-ben tulajdonképpen architektúra-független fájlok fognak kerülni (A lefordult binárisok szövegei), de mindegy...

Ezután jöhet a fordítás (make), majd egy teszt (make test). Ez annyit csinál, hogy az összes támogatott architektúrára fordít egy tesztet az imént készült fordítóval. A végén kiír egy összegzést, hogy hány fordítás volt sikeres/sikertelen. Ha a sikertelen = 0, akkor örülünk... :) Aztán jönne a dokumentációk „fordítása” (make docs), de nincs LaTeX telepítve, ehhez meg az kellene... Mindegy, ez nem fontos, a man oldalak ettől még megvannak. Majd az install (root-ként make install), ez a helyére másol mindent. Látszólag rendben az egész... Valamivel le kellene tesztelni.

Először is: az előző „tesztprogramom” egy text fájlban (test.asm) a következőképpen néz ki:

	cpu	6502				;CPU típusa

start_addr	=	$1100			;Kezdőcím 

monitor		=	$ff52			;MONITOR belépési címe 
irq_continue	=	$ce0e			;Gyári IRQ rutin 

	ORG	start_addr-2 
		ADR	start_addr		;Töltési cím berakása 

		sei 
		lda	#interrupt & $ff	;IRQ cím LO BYTE
		sta	$0314 
		lda	#interrupt >> 8		;IRQ cím HI BYTE
		sta	$0315 
		cli 
		jmp	monitor 

interrupt	lda	$ff19 			;Keretszín beolvasva
		eor	#$46 			;Forgatva
		sta	$ff19 			;Visszaírva
		jmp	irq_continue 		;Eredeti megszakítás-rutin végrehajtása

	END 

Ezt ezek után le kellene fordítani:

asl test.asm -L -u -x

Az -L paraméter bekapcsolja a fordítás közbeni listafájl generálását, az -u engedélyezi a memória-használat vizsgálatát (mivel több ORG direktíva is megadható, ennek a segítségével figyelhető az esetleges „overlapping”), az -x meg „bővebb” (mihez képest... :) ) hibakiírásokat eredményez. (Elvileg...) A fordítás kész, de a végeredményhez csak egy test.p fájl lett, ebből még meg kell kreálni a plus/4-be (ill. most az emulátorba) tölthető programot:

p2bin test.p test.prg -r '$-$' -l 0 -k

Ide is jöhet pár magyarázat: az -r paraméter azt mondja meg, hogy milyen memóriaterületet kell „kimásolni” a végeredmény fájlba. Itt az -r '$-$' paraméter azt jelenti, hogy az első használt címtől az utolsóig történjen a másolás. Az -l 0 azt adja meg, hogy azokon a helyeken, ahol a .p fájl nem tartalmaz adatot, azt milyen értékkel töltse föl. (Itt 0 lesz. A fordított programban lehet több ORG direktíva, a végeredményben viszont így lehetnek „lukak”, üres területek, ez ezekről a területekről szól.) A -k csak annyit tesz, hogy ha a „kimásolás” kész, a .p fájlt letörölheti, mivel az már nem kell.

Mivel ezt a „fordítás + másolás” mókát mindig el kell játszani, ezért készült hozzá egy sima szkript, amivel „egyszerűsíthető” a művelet (beszédes _ass.sh nevet találtam... :) ):

#!/bin/sh
PARAM=$1
asl $PARAM.asm -L -u -x
p2bin $PARAM.p $PARAM.prg -r '$-$' -l 0 -k

Ezek után a fordítást egy egyszerű _ass.sh test parancs kiadásával le lehet zavarni.

A végeredmény egy 28 byte-os fájl lett (test.prg), amit már be lehet tölteni az emulátorba:

És igen, működik, és igen, jól... A mai napra is megvan a sikerélmény. :) Most már neki is lehet állni kódolni. Csak a lelkesedésem tűnt el... :) De azért nem rossz ez. Viszont az „emulátorozás” valahogy nem hozza azt a „feelinget”, mint az eredeti vas. Azt hiszem elő kell szednem azt a „programletöltő” kábel projectet, van is pár ötletem...

balagesz

---

2011.10.19
2019.12.06. D8.