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

Kellemes év eleji meglepetésként kaptam egy terjedelmes cikket LGB-től (aki rendszeres kommentelőm a blogon), egy igazi kuriózumnak számító Commodore masinával kapcsolatos próbálkozásairól ír! Beleolvastam a megküldött anyagba és úgy ítéltem meg, hogy ez érdeklődésre tarthat számot (számomra mindenképpen érdekes). Habár az anyag terjedelme meghaladja egy blog információ közlő lehetőségeit (bizony - bizony, jelenleg a mikroblogok 140 karakternyi, vagy egy képnyi tömör közlésvilágában élünk), de biztos vagyok benne, hogy a téma igazi szerelmesei örömmel fogják végigolvasni ezt a négy részesre tervezett cikksorozatot.

Egy, szinte ismeretlen gépről, a Commodore LCD-ről szeretnék írni, ami sajnos sosem jelent meg a piacon. Érdekessége, hogy 1984 -1985 körül igen ütős masina lett volna, hordozható volt, akkumulátorral ellátva, és LCD kijelzővel rendelkezett. Különböző források szerint az LCD panel minősége a maga korában egyszerűen kiválónak volt mondható. A Commodore saját optoelektronikai részleget vásárolt és tartott fenn a projekt érdekében, amitől aztán azonnal meg is szabadult, amikor a Commodore LCD projekt elvetése mellett döntöttek. Érdekes anekdota, miszerint a Commodore CEO-ja (megjegyzés: Chief Executive Officer, elnök-vezérigazgató) éppen a Tandy CEO-jával beszélgetett, és ez utóbbi említette, hogy a "mobil computing"-ben nincs üzlet, ez bukás lesz. Ezt a Commodore felső vezetése - úgy tűnik - komolyan vette, és ez volt az egyik fő oka a projekt leállításának. Az már csak érdekes adat, hogy a Tandy később komolyabb bevételeket könyvelhetett el ebben a kategóriában. Bil Herd megjegyezte, hogy irodája falán sokáig kinn volt a cikk is, hogy milyen sikeres a Tandy ebben is.

Én viszonylag későn szereztem tudomást erről a gépről (2013 vége felé), de azonnal lecsaptam a témára, és elhatároztam, megpróbálok pontosabb információkat szerezni róla, és ezek alapján emulátort írni. Már ha valaki ezt nem tette meg előttem (mint később kiderült, nem). Akkor még nem tudtam, hogy mekkora fába vágtam a fejszemet.
Először is fontos leszögezni, hogy nem gyakori géptípussal van dolgunk. Talán érdemes összehasonlítani egy másik soha meg nem jelent Commodore masinával, a Commodore 65-tel. A Commodore csődje után számtalan - némileg különböző fejlesztési stádiumban lévő - "teljesen" összeszerelt gép szivárgott ki ilyen vagy olyan módon. Állítólag több, alaplap és hasonló formátumú példány is. Számukat nehéz megbecsülni, de akar a százat vagy - egyes források szerint – ezret is elérhette a nagyságrend. A Commodore 65-ről elég részletes és pontos anyag érhető el, részletes hardware leírással. Ehhez képest a Commodore LCD szinte ismeretlen, konkrétan két létező példányról tudunk, egyes források szerint lehetett belőle akar öt darab is. Szintén fontos különbség, hogy semmiféle dokumentáció nincs eme érdekes számítógépről. Még abban sem értenek egyet az elérhető információforrások (melyek általában rövid cikkek voltak a tervezett tulajdonságról), hogy pontosan milyen CPU-t használ, milyen órajelen ketyeg, vagy például mennyi volt a RAM mérete. Nyilvánvalónak tűnik, hogy ennyi információ birtokában szinte lehetetlen küldetés a gép jobb megismerése.
Szerencse a szerencsétlenségben, hogy az egyik Commodore LCD példány egy volt Commodore mérnök tulajdonában van. Név szerint Bil Herdről van szó, aki mellesleg részt vett a Commodore Plus 4 illetve a 128 tervezésében is. Mike Naberezny pár évvel ezelőtt felvette a kapcsolatot Bil Herddel, és küldött neki egy modern, USB-s EPROM égetőt, azért, hogy a ROM tartalmat le lehessen menteni. Ennek a mozzanatnak köszönhető, hogy rendelkezünk a ROM image-ekkel. Ez kavart egy kis port a Commodore hacker levelező listán, állítólag többen is neki álltak visszafejteni a kódot, hogy megismerjék a Commodore LCD-t. Bár én mar évek óta olvasom a kérdéses levelező listát, ez valahogy nem tűnt fel nekem. Akkoriban (2008), nem is tudtam ennek a gépnek a létezéséről.

Történt egyszer (ez még régebbi történet), hogy a Facebook-on Bil Herd ismerősnek jelölt, amit megtiszteltetésnek vettem (a magyarázat szerint többször találkozott a nevemmel - bár azt nem nagyon tudom hol, igaz így jártam Jeri Ellsworth-szel is). Később történt, hogy kiderült, Bil Herd saját site-ot indított a c128.com név alatt, ahova regisztráltam is. Itt akadt a szemem elé egy cikk, ami a Commodore LCD-t említette. Ez felkeltette az érdeklődésemet, hiszen számomra ismeretlen Commodore gépről volt szó, ami ráadásul eléggé el is ütött a többitől, hiszen egy hordozható eszközről volt szó. Azonnal kutakodni kezdtem, elsőként a neten. Találtam több oldalt is, ahol volt némi információ, de - mint mar említettem - néha a legalapvetőbb jellemzőkben se értettek egyet. Az hamarosan világossá vált, hogy erről a gépről részletes leírás sehol nincs (természetesen emulátor sem), beszerezni egyet pedig reménytelen, annak ritkasága így értéke miatt. Ahogy Bil megjegyezte, szívesen eladja nekem, ha gazdag vagyok. A már említett levelezőlistára visszatérve is azt láttam, hogy a kezdeti lelkesedés a ROM image-ek kapcsán lecsengett. A kérdésemre, hogy valaki foglalkozott-e vele azóta, nem jött válasz. Úgy tűnt, azóta senki nem foglalkozott a kérdéssel, és a ROM image-ek megléte nem segített túl sokat.
Ezek után el lehet képzelni a meglepetésemet, amikor a c128.com-on mégis egy igen részletekbe menő leírással találkoztam, egy PDF file formájában! A leírás igen részletes volt, és hirtelen nem is értettem, miért nincs akkor egy emulátor, amivel meg lehetne tapasztalni a Commodore LCD élményt. Gondoltam, akkor írok egyet én. Elvégre van ROM image, és van részletes hardware leírás, nincs itt semmi probléma. Akkor még nem gyanítottam, hogy ez messze nem lesz olyan egyszerű (pedig gyanúra adhatott volna okot, hogy senki foglalkozott a témával). Elsőként úgy döntöttem, hogy Python-ban írok valamit, ami sima (Linux) terminal ncurses módban jeleníti meg a karaktereket. Igen, ez ronda, és mellesleg nagyon lassú is, ámde könnyebb volt így megtenni a kezdeti lépeseket. Természetesen nem ezt szántam a véglegesnek. A neten tálaltam egy 65xx emulátort Python-ban, azt faragtam át (érdekesség, hogy kiderült, ezt az a Mike írta, aki a ROM image-eket elkérte Biltől meg 2008-ban). A ROM image nem volt más, mint négy darab 32K méretű file, némileg érdekes file névvel. Azt feltételeztem, hogy a Commodore LCD a 65xx családból származó CPU-t tartalmazott, az elérhető információforrások is különböző 65xx családba tartozó CPU-król tettek említést. Megkerestem azt a file-t, ami a végén értelmesnek tűnő RESET és IRQ vektort tartalmazott, olyan címre mutatva, ahol a disassembly (a cc65 csomagba tartozó da65-ot használtam) eljárás értelmesnek tűnő kódot mutatott. Ez egyben arra is rávezetett az eredményt elnézve, hogy itt 65C02 CPU-val van dolgunk (egyes források 65C102-t említettek, de ennek utána nézve kiderült, hogy software oldalról felfogható a dolog 65C02-nek is). Nevezzük ezt az image-t kernal-nak, elvégre az úgy szokott lenni egy Commodore gépen.

Nagyon hamar világossá vált, hogy a kérdéses PDF sajnos használhatatlan. Ez egyben magyarázatot ad arra, mért nem írt más emulátort a részletes leírás birtokában. A leírásban szerepelő szinte egyik jellemző sem bizonyult igaznak. Például a leírás egy I/O tartományt definiált a $D000 címtől kezdve. A kezdeti emulátor próbálkozásom során a kernal-t (mivel mérete 32K) betöltöttem a 64K címtartomány felső felébe, az alsó maradt a RAM. Aztán a Python-ban írt 65C02 emulátorral elkezdtem végrehajttatni, egy file-ba naplózva minden egyes opcode-ot, és memóriaírást. Feltételeztem, hogy előbb-utóbb csak inicializálnia kell a dolgokat, így lesz írás az I/O területre. Az kissé elgondolkodtatott, hogy a fenti séma szerint a $D000 a ROM területre esik, de el lehetett képzelni valami C64 szerű memória bankolási technikát is. Érdekes módon semmi jelet nem tálaltam a $D000 terület írásának. A PDF alapján implementált MMU funkcionalitás ennek hiányában elképzelhetetlen volt, ugyanakkor olyasmiket csinált a kód, ami ellentétben volt a leírással.

Ekkor meg mindig bíztam benne, hogy a leírás csak pár ponton téves (elvégre a PDF saját állítása szerint is csak előzetes dokumentáció). A leírás alapján körvonalazódó gép egyik érdekes jellemzője volt az LCD panel vezérlése. A szokásos Commodore megoldás (memória adott területén lévő video RAM) helyett az LCD kontrollernek egy regiszteren át lehetett sorban küldeni a karaktereket és egyéb vezérlő kódokat, amit neki meg kell jeleníteni, illetve végrehajtani. Természetesen az LCD kontroller regiszterének valahol az I/O tartományban kellett lennie. Mivel $D000 vagy bármi hasonló címre nem hivatkozott a rendszer, az emulátor-kezdeményem napló file-jában megvizsgáltam a memóriaírási műveleteket. Azonnal feltűnt, hogy $F800 címtől kezdve (aminek elvileg ROM-nak kellene lennie) változatos címekre vannak írási műveletek, melyek jól érzékelhető módon 128-as lépesekben "tömörödnek". Azaz ötletem támadt, hogy az írási műveleteknél kiírom az ASCII értéket. Az eredmény nem maradt el, hamarosan meglett az a cím ($FA00), ahova a byte-ok értelmezhető angol nyelvű üzenetek karaktereinek tűntek. Megvan tehát az LCD kontroller, amiről a PDF szólt, bár igencsak más címen! Emulátoromat módosítva, ezt ki is írattam ASCII értékekként. Azonban volt pár dolog, ami zavart. Néha látszólag teljesen random értékek kerültek oda (az CPU akkumulátora nem volt előtte feltöltve, csak "maradék" érték volt ott az STA $FA00 előtt). Továbbá, más értelmezhetetlen byte-ok is oda kerültek az üzenetek szövege mellé, amit a leírás alapján még vezérlőkódnak sem lehetett értelmezni. Bar így az emulátor némi zagyvalék mellett értelmes üzeneteket is kiírt, egy ponton mindig elszállt. Nem csoda, hiszen MMU kell (elvégre csak a ROM image-ek összmérete 128Kb, és akkor még RAM-ról nem is beszéltünk), ámde a PDF szerinti MMU működésnek nyomát sem láttam, sőt, az inicializálás során a KERNAL úgy tűnt, hogy például a $4000-es címtől kezdve lapozgat be valamit, ami ROM scan rutinnak tűnt, a "Commodore LCD" stringet keresve.

Sokáig hátráltatott az a tény, hogy foggal-körömmel ragaszkodtam a PDF-hez, hogy legalább egy-két pontban igaz. Az se segített, hogy elég egyértelműnek tűnt, a $FA00 címen lévő LCD kontroller ötlete, elvégre az emulátorom pár üzenetet már kiírt (igaz, néha itt-ott ismeretlen karakterek tévedtek oda)! A leírás semmit sem segített, semmi nem tűnt igaznak abból, amit írt. Ezen a ponton elakadtam. Elkezdtem komolyabban tanulmányozni a disassembly eredményét, illetve kommentekkel ellátni, értelmes címkéket behelyezni, stb. Egyszer az az ötletem támadt, hogy kiírom az emulált RAM tartalmat egy file-ba az emulátor futása után, hogy meg tudjam vizsgálni. Azt is emuláltam, hogy egy adott memóriacím lett-e írva legalább egyszer. Amit tálaltam, az a várható zero-page használat, a stack, illetve 1-2 cím. Ami viszont nagyon érdekes volt, az a $800-tól kezdődő 2Kb méretű terület. Itt minden 128 byte-ban 80 byte került írásra, így 16db ilyen egységünk volt. Mivel az már az előzetes infókból kiderült, 80*16 karaktert jelenített meg az LCD, ez azonnal gyanús lett. Ránézésre (és Commodore hagyományok szerint is várható módon) ezek úgynevezett "Commodore video memória kódoknak" tűntek (ahol pl. a „@” a nullás byte). Ez alapján átkonvertálva a kérdéses memóriaterületet tényleg értelmes üzeneteket találtam! A meglepő ebben ugye az, hogy a PDF szerint nem video RAM-ot használ a rendszer, hanem egyetlen regiszteren át küldi a karakter vagy vezérlő kódokat. Az $FA00 címnél tapasztalt élményeim is ezt támasztották alá. Első körben arra gondoltam, hogy az elképzelt LCD kontroller működése igaz. Ez a video RAM csupán valami "software”-esen használt terület, és innen küldi ki az adatokat a rendszer. Ha software-es, ha nem, úgy döntöttem, hogy emulátoromat átírom, a tapasztalataim alapján $800-tol kezdve feltételeztem video RAM-ot, ahol minden sor 128 byte, de csak 80 byte van használva. A módosítás után az emulátor határozottan jobban nézett ki! Először is eltűnt a "szemét" amibe ágyazva fel lehetett fedezni néha legalább értelmes üzeneteket. Ami megjelent, az már teljesen normálisnak nézett ki.
Folytatása következik, mihelyt beszerkesztettem a második részt ...

Ma, azaz 2014 február 13-án lett két éves a Retro Tauta Blogom :-D hogy repül az idő!? Anno, két évvel ezelőtt, egy zártkörű Retro fórum oldal folyamatos leállásai miatt döntöttem a saját Retro témájú blog elindítása mellett. Ne kelljen már csendben kuksolnom... ;-) szerintem jó döntés volt!  Bár a frissen kikerülő cikkek számán ez most nem látszik, de továbbra is napi szintem foglalkozom a Retroval. Akkor még egyszer boldog születésnapot Retro Tauta Blog!!!! :-D

Nézzük egy rövid summázatot a 2013 történéseiből, tavalyi évben huszonnégy cikkecske került ki az oldalra. Ebből kettőt külső szerzőtől kaptam (DigitáisGrafika és CodeKiller), akik azóta sajnos nem küldtek új cikket, de a zászló továbbra is áll azoknak, akik szeretnének kitenni / kitetetni anyagot az érdekes bütyköléseikről. A cikkek téma szerinti megoszlása továbbra is a nagy szerelem, az AMIGA túlsúlyát mutatják. Hét AMIGA-val, három ATARI-val, három DidaktikBeta-val, három C128-al, három AMIGA Turbó élesztéssel és két hardverkezdeménnyel foglalkozó cikk volt olvasható. Igen, tudom, hogy ez így meglehetősen kevés. :-( A szűk keresztmetszet az idő, amióta komolyabban fejembe vettem, hogy Retro kiegészítők fejlesztésével kéne foglalkozni, a legtöbb erőforrásom erre megy el. Mint azt a közismert mondás is tartja, az idő pénz, tehát az ATM egy időgép! ;-) Na de hiába nyomkodtam, nem lett több az időm... :-)

Idén vannak tervek dögivel, főleg hardverrel kapcsolatosak ;-) ... Volt pár újabb gép beszerzésem (Tesla PMD 85-2, AMIGA 1000, Schneider CPC 464, Videoton TVC 64+) ...volt még más is? Nem emlékszem, szét kéne nézni, (nem merek) és meg kéne róluk írni a beszámolót! Kiegészítőket is rendszeresen vásárolok (AMIGA CDTV SCSI Kit, VTVC SD Interface) és ha minden jól megy tavaszra lesz egy unicum számba menő üres alaplapom, ami csak arra vár, hogy kiélhessem rajta a bütykölési (összeépítési) hajlamaimat. Közben folynak az AMIGA kiegészítő fejlesztések a háttérben. Pár HW projektbe belekotyogtam, a fast ram bővítőről beszámoltam már, a HD vezérlőt is össze kéne építenem végre (az alkatrészek cirka fél éve porosodnak a polcon). Januárban elkészítettem az Accel14MHz turbóm, kézzel készített saját NYÁK-os kompaktabb változatát. Egész vállalható lett, szegény például hardveres beélesztésre vár cirka egy hónapja. ;-)

Az egér adapter fejlesztését is folytatni szándékozom ;-) hegyekben állnak a Xilinx CPLD-k, a PIC-ek és az AVR-ek, na persze kéne még pár GAL is a teljes boldogsághoz... Apropó :-) keresek technikai megoldást a 2708-as jelzésű UV EPROM-ok programozására. ;-) Azzal is elkezdtem foglalkozni... Közben dobozokban figyelnek az összeépítésre, javításra váró különböző Retro hardverek is...

Januárban teljesen véletlenül találtam egy hiánypótló videó sorozatot, egy sorkimenő tekercs hibás CRT televízió készülék javításról. Speciális :-D teljesen oda vagyok meg vissza! Minden benne van, ami nekem kell, néha nagyon értetlen vagyok, ez végre közelebb vitt a megértéshez. Belegányolás javítás, hibás alkatrész csere, sorkimenő tekercs csere, nagyfeszültségű mérés, oszcilloszkópos mérés, füst és végül boldog vég. :-D Ezen annyira felbátorodtam (kV, vagy nem kV ez itt a kérdés), hogy rendeltem egy sorkimenő tekercset az egyik Phillips CM8833 vagy CM8833-II monitoromhoz. Biztos, ami biztos el kéne készítenem egy sorkimenő tesztelő kapcsolást a hibakereséshez és neki kéne állni monitorokat javítani. :-) Más lehetőségen nem nagyon van, senki nem tolongott, hogy (alkatrész árban + minimum munkadíj) hajlandó lenne ezt helyettem megtenni. :-)

A legfontosabb viszont az, hogy a héten kézbe kaptam az első kooperációban készülő (saját ötlet, nem után gyártás!) hardverkiegészítőnk NYÁK lapjait! Erről a projektről még lesz bőven szó a későbbiekben, most csak kiteszek egy képet mutatóban...

RetroTauta Blog - folyt. köv. hamarosan! ;-)

... ez egy régi tervem, hogy a "Extra-Terrestrial-Hardware"-ekről is fogok írni, azt hiszem két doboznyi  van belőle... Mitől szörnyűek? Attól, hogy annyira régiek, egyediek, vagy rosszak, hogy használhatóságuk, kipróbálhatóságuk kérdéses. A funkcionális beazonosításuk komoly fejtörést okoz. Összeépítésük, üzembe helyezésük adott esetben a lehetetlennel egyenértékű vállalkozás. Ha ezzel a kupaccal foglalkozom, akkor a legtöbb időm a forráskutatással megy el, keresgélek róluk anyagokat. Általában az Internet hallgat róluk (szerencsés esetben nem), aztán ha sikerül fellelni valami információt régi folyóiratokról szkennelt oldalakon (vagy a polcról, mert ezeket is gyűjtöm), akkor talán idővel lehet is belőlük valami... Adódik a kérdés, hogy akkor miért foglalkozom velük? Természetesen azért mert retro történeti ritkaságnak számítanak, így értékkel bírnak a téma rajongói számára (de számomra mindenképpen)...

Első körben a Extra-Terrestrial-Hardware kategóriában néhány, kevesebb mint negyed száz éves, de frissen beszerzett hazai gyártású NYÁK lemezről készült fotót mutatok be, ezek Commodore 64 kiegészítők. Kezdjük egy kis történettel, a "nagy öreg" (Commodore 64) 1982-ben született és 1993-ban fejezte be földi pályafutását, nagyjából 20 millió darab épült belőle. Elterjedtségének, kedvező árának és remek tulajdonságainak okán rengeteg kiegészítő született hozzá. Az ipari felhasználástól az otthoni használatot segítő eszközökig minden. Természetesen ez kis hazánkban sem volt másképp és ez innentől kezdve lesz számomra érdekes.
Egy korabeli hardver hirdetés tanulsága szerint a megvásárolható kiegészítők közül többről forgott közkézen valamilyen szintű leírás!
PLOFI Datasette cartridge - Rádiótechnika 1989/3
PLOFI Fastload Cartridge - Rádiótechnika 1989/10
PLOFI Simon's cartridge - Rádiótechnika 1990/3
FINAL III cartridge - ?
ACTION Replay VII - ?
Fényceruza, szoftverrel - Rádiótechnika 1989/11
Hangdigitalizáló + szoftver - Rádiótechnika 1990/8
Hangkapcsoló - Rádiótechnika 1990/8
EPROM-égető - Rádiótechnika 1989/4
EPROM-bank (256Kbájt) - Rádiótechnika 1991/10
IC teszter - Rádiótechnika 1991/10
Datasette gyorsmásoló - Rádiótechnika 1991/7
Datasette fejbeállító - Hobbielektronika 1991/7
CPU stop + reset - Hobbielektronika 1990/12
256Kb ram bővítő kártya - Commodore Újság 1993/12
Tehát erről a listából négy kiegészítőről van szó (FINAL III cartridge, ACTION Replay VII, EPROM-bank, 256Kb ram bővítő kártya), amelyiknek meg van a PCB-je. Még autentikus (elméretezett, vetemedő, nem záródó) hazai kártyatokokat is sikerült hozzájuk szereznem. ;-) Mi az ami hiányzik? Elviekben a Final3-hoz minden meg van, be kéne azonosítanom, hogy pontosan melyik változat van nekem és összeépíteni. Az Action Replay, az EPROM-bank és a 256Kb ram bővítő anyagai jelenleg hiányosak. Úgyhogy arra kérném a kedves olvasóimat, hogy ha van ezekkel kapcsolatos anyaguk, archivált programjuk, GAL forrásuk, leírásuk, vagy esetleg le tudja fotózni számomra (az alkatrészek beazonosítása érdekében) akkor jelentkezzen a vortyex kukac frímél pont hú címen, vagy a blog facebook csoportjában. :-)

... tehát ott hagytam abba, hogy pár meddő kísérlet után végre sikerült a megfelelő HEX állományt beégetni a PIC-be és a további BUG-ok kikerülése érdekében egy breadboard-on (magyarul szerelőlap) összeraktam a kapcsolást, ami aztán egyből működött. Ezzel kéne kezdeni valamit! :-) Ugyan a breadboard éppen elfér a billentyűzet nélküli teszt gépem floppyján, de praktikusnak egyáltalán nem nevezhető méretű adapter...

Próbapanelen próbáltam először ismét összerakni a prototípust, de néhány technikai akadályba ütköztem. A panelba forrasztható DSUB9 csatlakozó lábosztásához a panel furatai nem megfelelőek. A próbapanel egyoldalas kivitelű, tehát a lengő kivitelű DSUB9 csatlakozót is csak toldással lehet rágányolni (lásd előző cikk JDM programozó). Ha elhajlítgatom fogóval a DSUB9-et (mint ahogy meg is tettem), nem lehetett BUG mentesen beforrasztani. A másik technikai probléma, hogy a PS2 csatlakozós egerem elromlott. Az anno vaterán vásárolt PS2 egér illesztővel és egy átalakítóval próbáltam pár USB csatlakozós egeret, a legtöbb sajnos USB HID eszköz, de szerencsére találtam köztük egy PS2 kompatibiliset.

A breadbord-os változathoz csináltam egy USB kábelt, így a házi készítésű nyomtatott áramköri lap tervére már az USB anya csatlakozó került. Tűkön ülve vártam, hogy január 2-án kinyissanak a boltok és megvehessem a szükséges dolgokat (Wolf Gyorsmarató TN150 - azért mert ezt lehet kapni, maratás álló filctoll). Persze maratás álló filctollat nem kaptam (és azóta sem), kifogyott (mert mindent megvesztek). Úgyhogy egy nagyon ócska vízálló filccel rajzoltam meg végül a panelt (olyan is lett, de a célnak megfelelő).

A gyorsmarató folyadékból műanyag tálba öntöttem egy kicsit, majd a kivágott panel hátuljára ragasztottam egy szigetelő szalag csíkot (hogy ne kelljen a maró folyadékban nyúlkálnom) és annak segítségével mozgattam. Időnként felemeltem és megnéztem, hogy mi történik. Először mattulni kezdett a réz, majd szép lassan előtűnt a panel műszálas anyaga. Szoba hőmérsékletű oldatban nagyjából 2-3 perc alatt indul be a folyamat látványos része és 5 perc alatt fel is oldódott a felesleges réz. Figyelem! Maratás közben mérgező gőzök szabadulnak fel, ha egy mód van rá, ne lélegezzük be! Ez ellen talán a szellőztetést tudom javasolni... A marató folyadékot öntsük vissza a helyére, óvatosan kezeljük. A porcelán, az üveg és a műanyag felületekkel nem, de minden mással szívesen reakcióba lép (ne vágjuk tönkre az inox mosogató tálcát stb.). A kész panelt érdemes szappannal és bő vízzel, körömkefével megmosni (savak közömbösítése érdekében). Egy teljesen barkács célú gravírozó készlet segítségével kifúrtam a szükséges lukakat. Jobb oldalon látható életem első (na jó, a 80-as évekbeli elektronika szakkörös pályafutásomat a villogó LED-el és a Morse-gyakorlóval most inkább hagyjuk) nyomtatott áramköri lapja. Látszik, nem sikerült megfelelően "tükörbe" rajzolni (a forrasztási oldal felől kell az alkatrész lábszámozást nézni, különben semmi nem lesz a helyén) így ezt nem tudtam használni, ellenben csináltam belőle sablont. :-) A bal oldali NYÁK lett az AMIGA PS/2 egér adapter prototípus Rev 1.1. változata. Miután beforrasztottam az alkatrészeket, kipróbáltam a kész adaptert (működik), a réz vezetékeket befuttattam ónnal (a korrózió elleni védelem témája). Legközelebb veszek kémiai ónozót (azt sem kaptam, azt is megvettétek) és kipróbálom azt is. Ha az beválik, akkor nem kell ónszívó harisnyával (kiforrasztó szalag) a felhordott fölösleges önt lemelegítenem.

Az elkészült illesztő most nagyjából gyufás-skatulya méretűre zsugorodott (a breadboard-on 10x15cm-es volt), de SMD alkatrészekkel és két oldalas panelra készíthető ennél kisebb változat is (már elkezdtem tervezni, további technológiai fogások kipróbálása folyamatban). A galériában találtok pár képet, többek között a NYÁK tervet is (nem fért el minden egy oldalon, ócska filccel meg pláne, ezért a C1 kondenzátort külön kábellel kötöttem be, persze biztosan van elegánsabb megoldás is).
Alaktrész lista:
- PIC16F84A
- DIP18 lemezes foglalat
- tördelhető tüskesor
- DSUB9 csatlakozó
- USB csatlakozó
- R1,R2 - 10K
- R3 - 4K7
- C1 - 27pF
- C2 - 100nF