Most nézem csak... Tavaly (2013) lusta voltam a hazai legnagyobb AMIGA-s találkozóról beszámolót írni? Ejnye! Pedig voltam mind a kettőn, ha jól emlékszem.... Sebaj, idén úgy alakult, hogy az elsőn ott tudtam lenni! Ezúton is köszönöm Lázinak a meghívást, a vendéglátást és a türelmet!
Chain-Q Charlie-nak pedig a felajánlott lomokat! ;-) Hű, hát kisebb fajta izgalom lett úrrá a társaságon, amikor kinyílt a garázs ajtó és megpillantottuk az asztalokra kipakolt cuccokat. Indult a böngészés ezerrel! Örülök, sikerült lőnöm a lomok közül pár elengedhetetlenül szükséges (de tényleg!) dolgot. Egy kisméretű LCD kijelzőt (remélem működik), a típusát még nem néztem meg, de PIC-es fejlesztésekhez valószínűleg nagyon jól fog jönni. Egy marék, AMIGA gépekből kibontott billentyűt és hozzá szervesen kapcsolódó műanyag biz-bazokat! Még tegnap melegében helyre is pofoztam a segítségével egy viharvert AMIGA 2000-es billentyűzetet! Mekkora mák, hogy pont azok a billentyűk voltak közte, amik nekem eddig hiányoztak. Így nem kell filccel irkálni, meg semmi ilyen, maximum a színben van egy árnyalatnyi eltérés. Aztán sikerült kifognom egy közepes állapotú Commodore plus 4-et működő táppal és még egy kompozit videó kábelt is találtam hozzá, abban a szatyorban ahol a billentyűk is voltak. A plus 4-et ízekre szedtem (billentyű lenyomásra nehezen reagált), kitakarítottam, jelenleg szárad, de az összerakásról lesz cikk. Szóval most is szép számmal voltak résztvevők.  Olyanok is jöttek, akik jó messze laknak, így ritkán találkozunk, vagy eddig még nem jutottak el AmiCon-ra. A hangulat ismét a megszokott volt, a party-kutyust (egy fekete színű palotapincsi szerű jószág, aki mindig be van ilyenkor pörögve miattunk) hiányoltam. :-)
címszavakban:
- Classic és új vasak tömkelege
- új, nagyon olcsó Pendirve-os floppy emulátor bemutató
- retro kuriózum gép nyomkodás - PECOM 64
- Chaos Guns beharangozó, új AGA-s AMIGA játék (hasonló mint a Hired Guns) Hevőtől
- Enterprise 128 SD Adapter játék és demó kompó
- helyben Hardver bütykölés (egy Apollo kártyába forrasztottam be foglalatot)
- garázs Lomizás ;-)
- Dumaparty
Az idei első AmiCon pár képben:

Rövid bevezető...
2013. október 1-én vásároltam egy Videoton TV Computerhez készült SD kártya illesztőt, a cartridge változatot. Ez a kiegészítő teljes egészében hazai fejlesztés. Pál lelkesedésének, kísérletező kedvének és kiváló munkájának az eredménye (ha lesz rá idő, írok egy ismertetőt róla, meglepő dolgokat hoz ki egy Videoton TVC-ből). Személyesen vettem át az SD kártya adaptert, az akkori beszélgetésből egy hosszú levelezés indult a fejlesztővel. Felvetődött a Videoton TVC – ENTERPRISE 128 közös hardver gyökerei okán a VTVC SD kártya illesztő átdolgozásának ötlete. A beszélgetést tettek követték, tervezgetés, méricskélés következett. Majd 2014 év elején az elkészült tervek alapján megrendelésre került a prototípusok NYÁK lapja és megvettük az alkatrészeket. Amikor összeépítettük az első prototípusokat, akkor az ENTERPRISE Forever fórumról ismert ZozoSoft-tól kértünk segítséget. Az anno Pál által megírt VTDOS SD kezelő I/O kódok alapján került sor az EXDOS rendszer kiegészítésére. Pár hardver és szoftver probléma kiküszöbölését követően már siker koronázta az erőfeszítéseinket!
Az ENTERPRISE 128 szépen működik SD adapterrel! Ugyan még nincs rendesen kihegyezve a szoftver része, de így is nagyon jó. Pokoli gyors a betöltés, szépen hozza a EXDOS floppy meghajtós időszak élményét. Egy NC szintű fájlkezelő program nagyon kell majd rá, meg pár hasznos UTIL, zene lejátszó, képnézegető és hajrá!
Hát ez bizony gyors és kiváló munka volt!

A projekt állapota: működő prototípus ENTERPRISE 128 SD adapter Cartridge portra - Rev 1.0
Szolgáltatások:
- A hardver lelke egy Xilinx CPLD chip.
- BASIC, EXDOS és SDEXT szoftvereket a felületszerelt flash memória IC-ben tartalmazza.
- Két kártya foglalatot tartalmaz: SD és microSD kártya számára, külön külön és párhuzamosan is használható.
- Cache memóriát tartalmaz.
- Egy IDE kártyához hasonlóan FAT12 kompatibilis, 32Mb méretű partíciókat kezel,
  jelenleg fejlesztés és tesztelés alatt.
- Rendelhető: a Rev 1.0 pár hónapon belül elérhető lesz.
- Fogyasztói ár: a NYÁK lap és az alkatrész árak változásának függvénye.

English summary ( sorry for my bad english ):
/2013. October 1./ I purchased a Videoton TV Computer SD card interface, the cartridge version. This accessory is entirely home-grown, Paul's enthusiasm, experimentation and excellence is the result of the work!
Personally I took the SD card adapter, then began a serious discussion of correspondence. It has been Videoton TVC - ENTERPRISE for common hardware roots of the idea of recasting SD card interface to ENTERPRISE 128.
The conversation has been committed, planning, assessment has occurred. Then the beginning of the year 2014 based on the final plans were to order the PCB prototypes Cards. When we built together the first prototypes, we asked for help from the forum "ENTERPRISE Forever" known ZozoSoft from. The code was based on the VTDOS codes (anno written by Paul) to make the ENTERPRISE EXDOS system to compatible. After eliminating couple of hardware and software problems have been rewarded for our efforts! The ENTERPRISE 128 will operate with SD card adapter! Well, that was certainly quick and excellent work!

- Project Status: working prototype ENTERPRISE 128 SD interface on cartridge port - Rev 1.0
Features:
- The soul of the hardware a Xilinx CPLD chip.
- BASIC, EXDOS, SDEXT software on the surface mounted flash memory IC.
- Two card slot: microSD and SD card, can be used separately and in parallel.
- Cache memory.
- FAT12 like a IDE HardDisk card, compatible with 32MB partitions,
   but currently under development and testing.
- Optional: Rev 1.0 will be available in a few months.
- Planned price: depending on the PCB and component prices.

Ahogy ígértem, itt a Commodore LCD gépezet / emulátor cikksorozat befejező része is! :-)

Hardware ügyben abszolúte nincs vége a projektnek. Először is van az ACIA (6551) nevű IC a gépben, aminek segítségével a Commodore LCD soros (mármint RS232 szerű, nem az IEC busz) kapcsolatot tett lehetővé, tehát soros terminálnak volt használható, de beépített modemet is tartalmazott! A VIA port kiosztás dokumentáció szerint valami hangja is lehetett a gépnek (bár egyes források szerint nem volt ...). Ne egy SID minőséget képzeljünk el, egyszerű beep-beepelésről lehetett szó. Ezen funkciók jelenleg még nincsenek kezelve az én emulátoromban. Andy nagyon kedvesen küldött a későbbiekben több további dokumentációt is részemre. Ezek alapján azonban nem tudtam "forradalmi" felfedezést tenni (pl. az MMU-s esettől eltérően). Mind olyan dolgokról szóltak, amit többe-kevésbé jól kitaláltam magamtól is. Nyilván volt pár kisebb dolog, amit tudtam "szépíteni" a dokumentációnak hála, de semmi eget rengető újdonság nem került elő.

Eddig inkább a hardware-re koncentráltam, de a felderítő munkám, illetve az emulátor írás során valójában párhuzamosan zajlott a software megismerése. Erről dokumentáció végképp nem volt, mind az én kísérleteimen (az emulátoraimmal) illetve a ROM disassembly-n alapult. A Commodore LCD alapvetően elindul csak a kernal-al is, aminek mérete 32Kb. A kernal bekapcsolás után scanneli a 256Kb rendszer címtartomány felső 128Kb-ját 16Kb-os lépésekben a "Commodore LCD" azonosító stringet keresve. Ha ilyet talál adott helyen, akkor az ott található "app directory"-t nézi, ami megmondja, hogy az adott ROM-ban milyen applikációk vannak. Ezt használja fel ahhoz majd, hogy a "menüben" (ennek hivatalos neve a ROM alapján: Shell) megjelenítse őket. A közismert BASIC nem indul automatikusan, Commodore-os szokástól eltérően a Commodore LCD az említett Shell-el nyit, és maga a BASIC is csak egy applikáció, amit el lehet indítani szükség esetén. Ha egy valódi Commodore LCD-ből minden ROM-ot kivennénk (kivéve a kernal) az működőképes maradna. Mivel a kernal-t is hordozó ROM-ban a kernal-on kívül csak a monitor program van, akkor automatikusan az indul el (mivel maga a Shell is máshol van). Az említett ROM scan rutin részleteit most mellőzve (ami anno amúgy sokat segített abban, hogy az MMU-ról képet tudjak alkotni), ezt próbára is tettem, írtam egy saját ROM-ot, amit a Commodore LCD emulátoromban alkalmazva a kernal meg is találta, és sikeresen betette a Shell app menüjébe! Ráadásul némi grafikus/görgetős buta kis "demót" írtam bele, így ezt is tesztelni lehetett.

Software-es oldalról a már említett "virtual 1541" (vagy RAM disk) mindenképpen említést érdemel. Ahogy már írtam, az alapelképzelés egyszerű és elegáns. A Commodore LCD "kis", hordozható gép, nincs hely benne "fizikai" meghajtó számára, persze kapcsolható hozzá opcionálisan. Illetve egyes források szerint később terveztek hozzá egy drive típust, ami szintén akkumulátorról ment volna - ebből aztán persze semmi sem lett. Ezért a Commodore mérnökei azt találták ki, hogy inkább a RAM-ot látják el állandóan feszültséggel, kvázi kikapcsolt állapotban is az akkumulátort felhasználva. Így a gép lekapcsoláskor "sem felejt", nyilván így a RAM disk tartalma is megmarad. Ez utóbbit amúgy a Shell remekül meg is mutat az applikációk alatt közvetlenül. Ez már az elején feltűnt (még mielőtt működött volna az emulátorom), mivel a ROM disassembly-ben elég jól látszik az a rész, ahol pl. a $-al azonosítható listát összeállítja software-esen. A Commodore LCD alapértelmezett tároló perifériája amúgy pont a RAM disk, de természetesen külső lemezegység is működhet, a szokásos módon (LOAD"...",8 stb.). Érdekes tulajdonsága a Shell-nek, hogy file név "kiterjesztés" (pl. .BAS) segítségével összekapcsolja az applikációkat a fileokkal, azaz ha Shell-ben a "virtual 1541" résznél egy .BAS-ra végződő filenevet választunk ki, a "BAS"-ról automatikusan tudja, hogy Basic program, így elindítja a Basic applikációt, és betölti a kérdéses file-t is, mint Basic programot. Ez persze nem csak a „.BAS”-ra igaz, hanem más mellékelt applikációkra is.

A Commodore LCD beépített applikációi amúgy nagyon érdekesek. Nagy vonalakban a következők érhetőek el, monitor, terminál program, szövegszerkesztő, táblázatkezelő, kalkulátor, és egy "memopad" (rövid szövegek tárolására). Maga a Shell is egy applikáció (bár a Shell nem mutatja önmagát), illetve a Basic is. A fentebb vázolt file név kiterjesztés alapján való applikáció hozzárendelés mindegyikre működik, ahol ennek van értelme. További érdekesség, hogy némi multitasking érzést kölcsönöz azon jellegzetesség, hogy bizonyos (de nem mindegyik!) applikáció futása közben kvázi indíthatunk egy másikat, illetve egyes esetekben "osztott képernyővel" dolgozhatunk több applikációval is!

Ezen a ponton viszont érdemes visszatérni a RAM táplálásához, ami kvázi kikapcsolt állapotban is történik. Nagyon sokáig fejfájást okozott nekem az a tény, hogy bár látszólag az emulátorom jól működött, mégis fura dolgok történtek: Basicben a számok helyett PI karakterek jelentek még (vagy csak szóköz), és egyéb hasonló misztikus jelenségek, néha "fagyás" is. A RAM disk pedig "elfelejtett" mindent, ha valamit mentett rá az ember, azonnal visszanézve sem látszott semmi. Az elején két feltételezésem volt: az emulátorom a hibás, vagy pedig a kérdéses ROM image-ek annyira alpha verziót képviseltek még csak, hogy nem is működik minden rendesen. Mivel a Commodore LCD sosem jelent meg, és igen kevés készült belőlük, ez nem volt megalapozatlan feltételezés. Természetesen ismét a disassembly-hez menekültem, és a bekapcsolási folyamatot - kezdve a reset vektortól - elkezdtem követni. Ami feltűnő volt, hogy RAM-ból tolt be olyasmiket, ami még inicializálva sem volt előtte, mégis "kész tényként" használja, hogy helyes az értékük. Az jutott eszembe, hogy ez nem feltétlen kernal bug: mivel a Commodore LCD úgy készült, hogy a RAM mindig táplálva van, feltételezhető, hogy bekapcsolás előtt is helyesek voltak azok az értékek. Igen ám, de ez nem segít sokat, hogy mik a kezdeti értékek, ha előtte nem volt helyes a memória állapota, ami ugye egy emulátornál mindig igaz, illetve egy igazi Commodore LCD-nél is igaznak kell lennie, a legelső bekapcsolás pillanatban, illetve ha pl. teljesen lemerül az akkumulátor (vagy valaki kiveszi/visszateszi), ezért a RAM elveszti tartalmát. Úgy tűnt, hogy ezekben az esetekben a Commodore LCD hibásan fog működni, és kb. használhatatlan.

Végül a megoldás az lett, hogy patch-eltem a kernal ROM-ot, hogy mindig inicializálja a RAM-ot. Ez egy JavaScript/web alapú emulátorban nem nagy érvágás, hiszen amúgy se maradna még a memória tartalom. Így a fentebb említett hibák azonnal eltűntek, működött a RAM disk, a BASIC, stb. Viszont csaknem ezzel egy időben rájöttem még valamire a disassembly-s utat követve: valójában a Commodore LCD lehetőséget ad egy "teljes inicializálás kikényszerítésére", ehhez egy bizonyos billentyű kombinációt kell lenyomva tartani bekapcsolás alatt (mindezek ellenére emulátoromban a ROM patch-elése egyszerűbbnek tűnt, ezért az maradt). Így már minden érthető! A bennem kialakult kép a következő: a Commodore LCD alapvetően arra épít, hogy a RAM tartalom megmarad. Ezt reset után ellenőrzi is több ponton, és ha valami nem stimmel, erre figyelmeztet, mindezek ellenére _NEM_ inicializálja a memóriát újra! Ennek oka véleményem szerint az, hogy meg akarja adni a lehetőséget a felhasználónak: hátha valami software hiba miatt kismértékű sérülés áll fenn, és még van lehetősége megmenteni adatot, ami megsemmisülne a teljes inicializálással. Ugyanakkor lehetőséget biztosít, a "tiszta" állapotra az említett billentyűzetkombináció segítségével. Ez kérdéses, hogy mennyire intuitív megoldás, de vegyük figyelembe, hogy a gép soha nem jelent még a piacon, elképzelhető, hogy a végleges változatban ezt másképpen kezeltek volna.

Természetesen még rengeteg érdekes dolog, és történet lenne elmondható software (amit kissé összecsaptam itt a vége felé ...) és hardware tekintetében is. Ám írásom már így is botrányos méreteket kezd ölteni, tehát mondjuk ki, hogy eljutottunk ahhoz az állapothoz, hogy az emulátor többé-kevésbé használható, az elkészítésekor kitalált és megismert információk birtokában pedig írhattam egy specifikációt is a rendszerről. Ezt egy web site - Commodore-LCD.LGB.HU - formájában közzétettem, ahol az emulátor is használható, illetve az említett specifikáció is olvasható. Bil Herd már érdeklődött, hogy site-ján (c128.com) említheti-e a projektet, most zöld utat kapott. Illetve én is megemlítettem a már említett levelező listán.

Ha a kedves olvasó idáig jutva fellélegzik, sajnos le kell, hogy lombozzam, a történetnek még nincs vége. :) Mert természetesen voltak visszajelzések. Tulajdonképpen nem annyi, amit reméltem. Nem arról van szó, hogy azt vártam, hogy kitüntessenek és nyilvánosan aranyba foglaljanak. Számomra furcsa, hogy milyen relatíve kis visszhangot váltott ki egy kvázi totál ismeretlen Commodore gépről elérhető részletes leírás és működő emulátor egy Commodore specifikus levelezőlistán. Nem az "elismerés" hiányzott, hanem az, hogy esetleg más valaki is csatlakozik a projekthez, mert azért volt még mit tenni.

Bár leírásomban már említettem Mike nevet, és hogy több dolog is neki köszönhető, ezt csak utólag írom így: amikor a ROM image-eket felleltem a neten, őszintén nem néztem, hogy kinek köszönhető ez. Ahogy azt sem, hogy az említett Python 65xx emulátor kezdemény kinek a műve (ami csak véletlen, hogy mindkettő az ő nevéhez fűződik). Utólag tehát nem kell csodálkozni azon, hogy általam sértődött hangvételűnek ítélt mail-t kaptam tőle. Szóvá tettem, hogy az ő nevét meg sem említem a site-omon. Természetesen Bil, Andi, Hedley és Jeff nevet nem felejtettem el – őket külön meg is kérdeztem, hogy hozzájárulnak-e ahhoz, hogy nevüket feltüntessem. Gyorsan tisztáztuk a dolgot, és elnézését kertem privátban, és az említett levelezőlistán is, és persze a nevét is feltüntettem. Azonban mégis volt értelme ennek, mivel ennek kapcsán hosszabb levelezésbe bonyolódtunk Mike-al, miután az én hibámból eredő problémát sikerült tisztázni. Leszögeznem, hogy tényleg sajnálom a mulasztásomat, Mike nélkül nem lenne se Commodore LCD emulátor se specifikáció, mivel az ő lelkesedése (és pénze) tette lehetővé, hogy ROM image-unk legyen. Arról nem is beszelve, hogy később jöttem rá csak, hogy az említett Python CPU emulátor is az munkája - igaz így legálabb tudtam neki bugreport-al szolgálni. Viszont Mike-tól megtudtam azt is, hogy van már létező Commodore LCD emulátor kezdemény, habár nem működik. Az MAME/MESS project keretében készült, az általam is említett PDF felhasználásával. Nyilván ennek írója is rájött, hogy az a PDF nem használható, és itt félbeszakadt a projekt.

Ezek után jelentkezett még két srác, az egyikük pont a MAME/MESS projekt kapcsán. Próbáltam mindenben segíteni, azóta állítólag az ott tálalható emulátor is gyors fejlődésnek indult, és már működik is (habár én őszintén szólva nem próbáltam még ki). Jó azt látni, ha az ember munkája másoknak is hasznos. Tulajdonképpen ezt hiányaltom, nem a személyes "éljenzést", hanem, hogy legyen értelme mások számára is annak, amit csinálok. Ez el is gondolkodtatott. A MAME/MESS projekt ott állt le, hogy nincs információ, én is így kezdtem (bár én nem tudtam róla, hogy valaki már megpróbálta előttem). Szerintem bárki némi lelkesedéssel és hozzáértéssel véghezvihette volna azt, amit én tettem. Ennek tükrében furcsa, hogy 2008 óta senki nem könyvelhetett el említésre méltó haladást.

A másik srác, aki irt, inkább érdeklődő volt, nem az a programozó típus. Azonban fontos megjegyezni, hogy érdekes felfedezést tett. Egy neten fellelt meglehetősen gyenge minőségű fénykép alapján (ahol látszott egy valódi Commodore LCD kijelzője) rekonstruálta az LCD tartalmat, amin a Shell látszott. Érdekes módon kisebb-nagyobb eltéréseket mutatott ahhoz képest, amit az én emulátorom megjelenített! Ebből arra a következtetésre jutottam, hogy valószínűleg egy más fejlettségi szinten levő példány lehetett, kicsit más ROM tartalommal. Az hamar kiderült, hogy ez valószínűleg Jeff tulajdonában levő Commodore LCD-ről készült. Az én munkám Bil példánya (és ROM image-e) alapján állt elő. Mike-al megvitattam a dolgot, és felajánlotta, hogy említett EPROM égető/olvasó hardware-jét szívesen elpostázza Jeff-nek is, ha ő hajlandó a ROM mentésre (ahogy ez 2008-ban Bil-el is eljátszotta). Ez ügyben kapcsolatba léptem Jeff-el, aki nyitottnak mutatkozott, de azóta nem történt előrelépés a dologban. Bil véleménye szerint az ő példánya sokkal inkább egy "lab product" még Jeff-é a bemutatókra szánt eszköz, ebből nehéz megjósolni, hogy melyik lehetett a "fejlettebb".

Amit leírtam, az a leegyszerűsített és lerövidített vázlata annak, amit a Commodore LCD megismerése érdekében végigvittem. Bár így is meglehetősen hosszú, az írásom több ponton is talán hiányosnak, vagy következetlennek tűnhet. Ennek oka az, hogy nem akartam még ennél is hosszabb cikket írni, véleményem szerint már így is éppen elég hosszú. Néhány dolgot a jobb érthetőség kedvéért kénytelen voltam külön kezelni (témaként), ami valójában párhuzamosan zajlott. Mindezek ellenére remélem, hogy sikerült még az én teljesen hiányzó fogalmazási képességem nélkül is valami "egyszer talán elmegy" irományt alkotni.

Köszönöm a figyelmet!

URL gyűjtemény:

* A Commodore LCD site-om

* Az emulátorom

* Az emulátorom a saját ROM-ommal (válaszd az lgb-t az app menüből)

* Az emulátoromról

* Az általam írt specifikáció

* Több verzió kérdése

* Köszönetnyilvánítás/linkek

* A charset keresési projektem, vizualizált formában a kernal, látható a charset infó benne

* Mike és a ROM image-ek

* A "hamis" PDF

* "Secret weapons of Commodore" (képek, infók)

* Wikipedia oldal a gépről

* MJK oldala

Ahogy közeledünk a befejező részhez, egyre izgalmasabbnak találtam a cikket ;-) úgyhogy nem is kíméltem magam és beszerkesztettem a harmadik részt is gyorsan!

Az áttörés Andy-vel kapcsolatos beszélgetéseim során jött. Konkrétan egyetlen scannelt oldalon múlt a dolog, amit volt szíves nekem elküldeni. A kérdéses oldal az MMU működését mutatja be röviden. Szép lett volna, ha tisztán saját erőmből mindenre rájövök, de valljuk be, ez szinte lehetetlen, mivel az MMU nem nevezhető egyszerűnek, több módja van, négy - nem is egyenlő nagyságú - ablakra osztja a memóriát, egyes módokban mindegyik szabadon állítható Kbyte-onként, illetve van olyan, hogy MMU mód mentése, majd visszaállítása, stb. Természetesen, a tudást azonnal felhasználtam az emulátoromban. És íme, az emulátor még tovább jutott, és közölte velem, hogy "Press a Key". Na, ez nehéz lesz - gondoltam -, mivel az még nincs emulálva. Mint írtam, a módszerre, amit a Commodore LCD használ nagyjából rájöttem már a kernal disassembly tanulmányozásával, most tehát nekiálltam implementálni. Nemsokára képes voltam a "Press a Key" kihívást teljesíteni az emulátorral, és wow, az emuláció eljutott arra a pontra, hogy egy neten talált képhez hasonló "menü" fogadott!

A menüben különböző applikációk futtathatóak, köztük szerepelt a BASIC is. Azt hozzá kell tenni, hogy mivel a billentyűzet mátrix kiosztását nem ismertem, ezért csupán egy 8*8-as mátrixot tettem ki az emulált LCD panel mellé, ahol egérrel lehetett "megnyomni" az adott pozícióban található billentyűt, legyen az bármi. A "Press a Key" kihíváson átmentem, ámde a menüben még mozogni sem tudtam, hiába próbálgattam az egyes sor/oszlop kombinációkat, sőt némelyiknél még "fagyott" is az emulátor (eltűnt minden a képernyőről). Vissza a disassembly-hez! Rájöttem, hogy a dolog azért nem annyira egyszerű, mint gondoltam, valójában van a 8*8 mátrix mellett még egy byte (amiben vannak misztikus "lefagyást okozó" byte-ok, illetve vélhetően a shift/ctrl/stb. gombok is itt vannak), és egy adott VIA port biten lehet megmondani, hogy én a mátrix állapotát akarom olvasni vagy ezt az extra byteot. Ez alapján módosítottam az emulációt. Nagy megelégedésemre sikerült, így már próbálgatással a kurzormozgató gombokat fellelnem, illetve a RETURN-t. Ezzel sikerült a BASIC app-ra navigálnom, és "indítani", így volt READY prompt is. :) Itt aztán elkezdtem egyenként az egyes billentyűzet pozíciókat "aktiválni" (az egérrel az említett mátrixban) és megnéztem, mi történik. Ez alapján lassan felépítettem a billentyűzet mátrix kiosztását, amit aztán implementáltam az emulátorban, hogy normál billentyűzet leütéseket fordítson át (mar egér nélkül), azaz normálisan lehessen a PC billentyűzeten gépelni. Az is kiderült, hogy a "misztikus lefagyasztó" bitek igazi Commodore LCD-n az akkumulátorral kapcsolatosak, és valószínűleg azért okoz kettő is "fagyást" mert azt lemerült akkumulátor jelzésének érzékelte és gyorsan lekapcsolta magát a gép (arra is rájöttem, hogy van egy olyan VIA port vonal, amivel saját magát software-esen képes lekapcsolni). Erre vélhetően azért van szükség, mert lekapcsolt állapotban is képes a RAM-okat táplálni (így nem törlődik a memóriában levő tartalom!), de ehhez nyilván nem szabad hagyni totálisan lemerülni az akkumulátort normál üzem során. Az egyik bit pl. csak azt eredményezi, hogy a menüben figyelmeztet arra, hogy alacsony feszültségszint, de még enged tovább dolgozni.

Mivel azt több forrás is említette, hogy grafikus módja is van a gépnek, ez is érdekelt természetesen. A BASIC használatával lehetővé vált, hogy egy GRAPHIC1 utasítással grafikus módba lépjek. Természetesen, mivel ez nem volt emulálva, nem történt túl sok minden, ámde ez remek módnak bizonyult, hogy próbálgassak, ha ezek után pl. egy kort rajzoltam a CIRCLE paranccsal. Nemi próbálgatás után kiderült, hogy grafikus módban $1000 címen kezdődik a video RAM. Az is feltűnt, hogy adott I/O regiszterekre pont módváltásnál megy írás művelet, feltételeztem tehát, hogy az az LCD vezérlő. A változásban könnyű volt megsaccolni, mi lehet a grafikus módot jelző bit. Azt is kikövetkeztettem a találgatásból, hogy hogyan lehet megadni a video memória kezdetet az LCD kontrollernek. Így először az emulátoromban, már nem csak feltételeztem fixen a videó RAM kezdetet és a videó módot, hanem emuláltam az LCD vezérlő I/O regisztereit, és ez alapján emuláltam. Az eredmény egy totálisan zavaros kép volt grafikus módban. Pontokat rakosgatva ki, rájöttem valamire: hasonlóan a karakteres módhoz (ahol 128 byte egy sor, de csak 80 van használva) grafikus módban is a kettő egy hatványára van felkerekítve egy sor mérete, de itt 64 byte egy sor, amiből 60 byte (480 bit) van használva. Ezt helyesen implementálva, már működött a grafikus mód is remekül!

Hozzá kell tenni, hogy még mindig akadt egy probléma. Ráadásul egy olyan, ami mind a mai napig nem oldódott meg. Ez pedig a következő: az tisztán látszott, hogy a Commodore LCD a többi hasonló Commodore gépnél megszokott módon két karakterkészletet használ. Van ugyebár a nagybetű+grafikus karakterek, illetve a kisbetű+nagybetű üzemmód. A probléma az, hogy a ROM image-ekben _csak_ az előbbi van meg, az utóbbi nem! Többször, részletesen átnéztem az említett bitmapként renderelési módszerrel a rendelkezésre álló ROM image-eket, de semmi. Ugyanakkor, az a Commodore LCD "menü" képernyőjén is tisztán látszott, hogy kis+nagy-betűs módot igényelne, hiszen például egyes szavak eleje vagy egész szavak csak grafikus jelekből álltak, ami azonban pont nagybetű lenne a másik karakter készletben. Első körben a gyors "megoldásom" az volt, hogy az emulátorban átkonvertálom ezeket mind. Így minden úgy jelent meg, mintha csak a nagybetű+grafikus készlet kellene. Ez azonban persze teljesen hibás megoldás, és zavart is.

Hol lehet a hiányzó karakterkészlet amúgy is? Az LCD vezérlő regisztereibe irt adatok alapján gyaníthatóvá vált, hogy melyik bit szabályozná a karakterkészlet kiválasztását, csak éppen nem volt miből választani. A neten fellelhető PCB fotókat nézegetve a szemem elé került egy, ahol egy igen rossz minőségű képen egy IC látszik, rajta a "charset ROM" felirattal. A dolog kezdett gyanússá válni, és a következőkre gondoltam: a Commodore LCD-nek valójában saját ROM-ja van a karakterkészlet tárolására! Erről pedig nincs ROM image-unk egyáltalán! Az valószínűleg csak a szerencse műve, hogy a kernal-ban ott van az egyik, tippem szerint az csak valami software célokra kellhet (tudom is én, BASIC grafikus módban karakter kiírása, vagy hasonló!), és valójában nem az a karakterkészlet, amit az LCD vezérlő használ, mivel ez utóbbi teljesen független ROM. A megoldás az emulátoromban - ROM image hiányában - az lett, hogy vadásztam az internetről egy random 6*8 mátrixszal rendelkező karakter készletet, ahol az angol ABC kisbetűi vannak. A kernal-ban találta nagybetű+grafikus készlet lett az egyik charset, illetve ezt klónoztam másodiknak is, csak ebben nemi módosítást eszközöltem: áthelyeztem a nagy betűket, illetve a fenti forrásból beszerzett kisbetűk mintáját beleerőszakoltam. Emulálva az LCD vezérlő set váltó bitjét, bár jól jelent még minden: a "menüben" volt kis és nagy betű is, BASIC-ben még kapásból csak nagy (de átváltható billentyűzetről, ahogy C64-en is).

Természetesen csak hardware "felderítés" ügyben is volt több kisebb kitérő, amit közben nem említettem: ilyen például az IEC busz emulálásának kérdése. A Commodore LCD rendelkezik soros IEC busszal, így elvileg akar egy 1541 is kapcsolható hozza például (alapból a Commodore LCD - leven hordozható gép - nem ezt használja, hanem "RAM diszket", de erről majd kesébb). Próbáltam emulálni ezt is, kezdve az alapvető IEC busz handshake-től, ámde ez valamiért nem jött össze (mellesleg közben írtam JavaScript-ban egy primitív C64 emulátort, mivel ott tudom persze, hogy az IEC busz tényleg működik, ott ment is). Azt mind a mai napig nem tudom, hogy ez Commodore LCD-vel miért nem jött össze. Ezt azért akartam megtenni, mert így "kissé" nehézkes a file beötlése és mentése, a Commodore LCD filozófiája alapból az, hogy emulál részben egy 1541-et amit "virtual 1541"-nek nevez, és valójában RAM disk. Mivel kikapcsolt állapotban is táplálja az akkumulátor a RAM-ot, ezért "nem felejti el", ámde egy JavaScript/web alapú emulátornál ez probléma, hiszen nem tudom megtartani a memória állapotát (a HTML5 localstorage eljárását felhasználtam, de sajnos így sem kaptam használható eredményt). Az is elképzelhető, hogy az általam írt VIA emuláció nem tökéletes, és ennek köszönhető a probléma (a C64-es "tanulmány emulátoromban" nyilván CIA van, 6526).

A másik kisebb hardware-es kitérő az RTC (Real Time Clock) chip emulációja volt. Már a kezdet kezdetén a (VIA emuláció írásánál) feltűnt, hogy az egyik VIA bizonyos portjainak "default” értéket adva mindig más dátum/idő jelenik meg a "menüben" a jobb felső sarokban. Ebből feltételeztem, hogy a Commodore LCD tartalmaz valamiféle hardware-es RTC elemeket. Az eredeti PDF is ír erről, azonban abban az eddig bizonyított használhatatlansága miatt nem tudtam megbízni. Ismét Andy segített ki, egy újabb scannelt oldalon, amit elküldött a VIA port kiosztása volt látható, és a billentyűzet is. Elsőként ellenőrizni tudtam a billentyűzetet, amire magamtól is rájöttem. Örömmel könyveltem el, hogy kb. pontos volt, amit kitaláltam magamtól is, habár a konkrét hardware más, mint aminek elképzeltem, software szempontból a hozzáférés tényleg úgy működött, illetve persze a billentyűzet mátrix is stimmelt (másképpen nem is lehetett volna, hiszen akkor nem működhetett volna jól e tekintetben az emulátorom). Másrészt, az IEC busz "bekötése" is meglett, amiben szintén nem tévedtem (de sajnos ennek emulálása - mint írtam – valamiért továbbra sem ment). Ezek mellett ott volt az RTC chip bekötése is a VIA portok tükrében. Apróbb bökkenő, hogy nem lehetett tudni, hogy konkrétan milyen RTC chipről van szó. Úgy látszik, Andy-t is elkezdte ez érdekelni, mert egy napon írt egy mail-t, hogy ő is talált a neten egy PCB fotót, amin nagyon nehezen olvasható, de sikerült kiolvasnia mi lehetett az említett IC-n a felirat. Ez alapján rákerestem a kérdéses IC adatlapjára a neten, és implementáltam annak funkcionalitását kissé amatőr módon, írni időt/dátumot nem lehet, olvasásnál még a JavaScript megfelelő dátumkezelő dolgai alapján az aktuális időt mondja. Ezek után emulátorom már a helyes időt és dátumot jelezte ki automatikusan.
Folytatás a befejező résszel hamarosan ...

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...