Ahogy ígértem, igyekszem mihamarabb beszerkeszteni a kapott anyagot, a Commodore LCD rejtelmeivel foglakozó cikk folytatódik! ;-)

Az MMU ismeretlensége természetesen hatalmas probléma volt. Nem csoda, hogy egy ponton soha nem jutott túl az emulációm, BRK opcode-okra került a vezérlés a RAM-ban (azaz nulla byte-ok, mivel erre inicializáltam a RAM-ot). A $4000-es címtől megsejtett "lapozható" memória tartomány a ROM disassembly szerint azt sejtette, hogy a Commodore LCD 256Kb címtartománnyal rendelkezik, amiből a felső 128Kb a ROM (a 4db 32K méretű ROM image) az alsó 128Kb meg valószínűleg RAM (még ha alapból nincs is benne ennyi memória). Ez ismét szöges ellentétben áll a PDF-ben leírtakkal, ami 1Mbyte címtartományt ír, és az MMU regisztereket is a $D000-as tartományba teszi. Keményen ráfeküdtem a ROM disassembly-re, a $F800-as cím felett már említett módon úgy tűnt, hogy több I/O-val kapcsolatos dolog is van. Bár ez elvileg ROM lenne, valószínűsíthető volt, hogy bizonyos címek "dummy write I/O" (azaz bármit ír oda az ember a funkció adott, csak az írás ténye számít adott cím viszonylatában), más címeknél viszont fontos a kiírt byte értéke is. Olvasásnál pedig simán a ROM tartalma jön, konkrétan a kernal futtatható kódja. Próbáltam elemezni, hogy milyen címeket irkál a KERNAL pontosan. A PDF két 6524-es periféria illesztőről beszél, ámde sikerült azonosítanom pár címtartományt, amik jellege 6522-re (VIA) mutat. Sejtésemet beigazolta az a tény, hogy tálaltam pár fotót a neten az alaplapról, ahol látszott, hogy ez igaz. Még egy érv a PDF használhatatlansága mellett! A disassembly eredményét hosszú órákig tanulmányozva megpróbáltam a feltételezett MMU funkcionalitást implementálni. Az emuláció tovább jutott, de egy ponton változatlanul elakadt, valami még hiányzott. A VIA-s vonalon továbbmenve a T1 számláló feltételezhetően IRQ generálásra van használva. A kernal kódját nézegetve feltűnt, hogy egy adott kódrészlet az IRQ rutinból fut, és pont úgy növel néhány byte-ot ami óra/perc/másodpercnek tűnik. Ez alapján az IRQ rate-et ismerve (VIA T1 inicializálás) megállapítottam, hogy vélhetően 1MHz a CPU órajele. Hozzá kell tenni, hogy a Python-ban irt kód még egy elfogadható sebességű notebook-on (amin dolgozom) is csak kb. 10%-os sebességet érte el egy valódi 1MHz-es 65C02-val szemben. Az természetesen egyértelmű volt, hogy ezt az alkalmazást így nem adom ki, csak addig lesz jó, amíg a "detektívmunka" tart. Nem csak a sebesség volt gond, hanem a megjelenítés módja is, mint írtam, egy Linux terminálban futott.

A ROM disassembly tanulmányozása során több dologra is rájöttem még, pl. hogy vélhetően a VIA (legalábbis az egyik, úgy tűnt kettő van, és a PDF is két - igaz nem VIA-t - említ) "A" portja választja ki a keyboard mátrixot, de a soros shift regiszteren át tudja beolvasni. Itt egy kis lökést adott az a felismerés, hogy meg kéne próbálni végre a ROM disassembly eredményét egy "Commodore-os gép" kernal-jának tekinteni, például a C64-en szokásos kernal ugrási táblázatot feltétezni. Ez helyes útnak tűnt, több ponton is ellenőrizve. Itt is azonnal feltűnt, hogy a fő különbség egy C64-hez képest, hogy az adott kernal belépési pontnál először egy adott $F800 cím feletti - vélhetően MMU - regiszterre ír ki valamit, és utána ugrik csak a kernal alacsonyabb címeire a kód. Vélhetően ezzel "lapozza be" a ROM alacsonyabb régióit, ami előtte pl. RAM-ként elérhető, pl. az IRQ rutinra is jellemző ez. Csupán az volt a zavaró, hogy igen nagy mennyiségű regisztert volt erre használva, és nem igazán értettem, pontosan mi mit jelent. Az is világossá vált a VIA kapcsán, hogy néhány I/O regiszter olvasható is, hiába van ott elvileg ROM, azaz nem jellemző rá más regiszterek azon jellemzője, hogy csak írható, és olvasásnál a ROM tartalma látszik ott csupán.

Itt csúnyán megfeneklett a projekt, fel is adtam, és inkább más részével kezdtem el foglalkozni, ismét az LCD vezérlő kérdésével. Hirtelen az az ötletem támadt, hogy a PDF tényleg teljesen hibás, és a video RAM $800 címnél valódi "hardware video RAM" (nem csak a kernal által használt software-es puffer). Ezen az úton továbbhaladva, gondoltam, hogy valahol kell lennie karakterek alakját leíró "chargen" ROM-nak, amit az LCD vezérlő használ. Karakteres módban a videó RAM-ot olvassa és a chargen ROM alapján megjeleníti. Nosza, írtam egy kis buta script-et, ami a ROM-ok tartalmát "grafikusan" mutatja, mintha bittérkép lenne, annak reményében, hogy meglesz, amit keresek. Fáradozásaimat siker koronázta, $F700 címtől kezdve egy 6*8-as felbontású karakterkészlet bontakozott ki. Igen, 6*8 nem 8*8. Az alkalmazott LCD panel felbontása 480*128 pixel, ami csak akkor teszi lehetővé a 80*16 karakteres megjelenítést, ha 6*8 pixel méretű egy karakter.
Ez volt az a pont, ahol a Linux terminál már nem volt elegendő, ha pixelesen is akarok dolgozni. Itt volt az ideje, hogy körvonalazódjon egy használhatónak tűnő emulátor a Python-os terminálos megoldás helyett, ami a sebességnek is jót tenne. :-) Azt tudni kell, hogy soha nem használtam Windows-t, se otthoni, se munkahelyi gépen nem volt ilyen operációs rendszerem még. Ha egy natív, grafikus Linux-os megoldással rukkolok elő, az bizony sok embernek nem lesz használható, aki Windows-ozik. Úgy döntöttem, hogy web browser-ben futó, JavaScript-es megoldással élek, hiszen az platform független, ráadásul még letölteni/installálni sem kell így! A másik oka ennek a furának tűnő döntésnek, hogy JavaScript-ben már írtam 8 bites emulátort, nevezetesen az Enterprise 128-hoz. Az új emulátorom 2013 karácsony-újév közötti pár nap alatt született meg, már a $800 címtől kezdődő videó RAM ötleten, és a kernal-ban talált karakter készletet használva renderelte le pixelenként a látható eredményt. Ugyanazon a gépen ez a megoldás már bőven Real-Time-ban tudott futni! Sőt, kicsit tovább is ment az emuláció, mint a Python-os megoldásban! Ennek okát nem értettem, valószínű, hogy a CPU emulációban valahol volt a hiba. A JavaScript verzióban írt CPU emulátort már én írtam a nulláról, így ebben a munkában minden kód az enyém volt. Ez szép eredmény, de az emuláció továbbra is elakadt egy ponton. Ez az MMU kemény dió lesz! Egy dologra viszont rájöttem és ez nagy (és tanulságos) felismerés volt. Amikor azt gondoltam, hogy az $FA00 címre kell küldeni a karakter/vezérlő kódokat az LCD felé (és nincs hardware-es videó RAM) akkor valójában totálisan tévedtem. Az csak egy nagyon vicces dolog eredménye, hogy az $FA00 címre menő adatok néha értelmes üzeneteknek tűntek. Ennek oka pedig az, hogy a karaktereket kiíró rutin is állítgat(hat?) MMU dolgokat, ami pont egy "dummy write" (azaz mindegy mit írunk oda, csak az írás ténye számít) jellegű regiszter, amit STA-val ír a KERNAL, de a CPU akkumulátorában ekkor általában pont a kiírni kívánt karakter kódja helyezkedik el! Viszont más ponton is használva van a regiszter, ez megmagyarázza, hogy miért volt annyi "szemét" is az értelmes üzenetek mellett.
Úgy döntöttem, hogy itt az ideje segítséget kérni. Bil Herd sajnos nem igazán emlékezett a részletekre, bár megerősítette, hogy a kérdéses PDF tényleg egy korai elképzelés, és nem az került megvalósításra. Ha ezt az elején tudtam volna? :) Itt kb. vége is lehetne a történetnek, használható emulátor nélkül. Ámde az történt, hogy kiderült, kinél van a másik ismert Commodore LCD. A tulajdonos természetesen ismét egy volt Commodore-os dolgozó, Jeff Porter. Ezt is netes keresgetéseim során sikerült kiderítenem. Közvetlen contact-ot ugyan nem tálaltam, de elég bátor módon rákerestem Facebook-on, és megdobtam egy üzenttel, hogy információt szeretnék. Válaszolt is, sajnálkozva, hogy bár tényleg van neki Commodore LCD-je, de nem működik, és sajnos már nem is emlékszik olyan részletekre, ami engem érdekelt. Viszont ajánlott két másik lehetslége „áldozatot”. Micsoda meglepetés ismét volt Commodore-os dolgozókról volt szó, név szerint Hedley Davis és Andy Finkel. Hedley-től megtudtam, hogy ő írta a kernal-t, de "természetesen" ő sem emlékszik túl sok mindenre. Segített pár ponton comment-elni a ROM disassembly eredményét, viszont pont az MMU dolgairól nem tudott sokat mondani. Volt viszont egy érdekes megjegyzése, amire emlékezett. Megemlítette, hogy a hardware-es srácok mindig kinevették, mert "két teljes flip-flop-ot kér csak tőlük", illetve azt is elmondta, hogy ez valahogy az IRQ-val volt kapcsolatban, de már nem tudja mi volt pontosan. Ugye két flip-flop az összesen 2 bit információt képes tárolni, tehát négy érteket vehet fel összesen. Az IRQ rutin legelején (pl. kernal belépési pontoknál) vannak elég misztikus I/O regiszterírások (dummy write módon), illetve máshol is elfordulnak. Arra gondoltam, hogy esetleg többféle "MMU mód" van, és a kérdéses 2 bitnyi információ ehhez kell. Tehát - elvileg - akkor négy MMU mód létezhet, de ötletem sem volt, hogy ezek pontosan mik lehetnek, hogyan kell használni őket, stb.. Így tehát sajnos nem jutottam sokkal előbbre, bár a kernal jobb megértésében segített egy picit az információ.

Folytatása következik, ahogy az időm engedi...