Retró rovat XII: modernizált (hehe...) adatmozgatás V1 (Plusz pécé szerviz #2)

A triviális megoldás nyilván az lenne, hogy egy olyan „valamire” kellene a szerzeményt kiírni, amit az adott gép használ. A korabeli mikrogépek alap háttértárnak kompakt kazettát használtak, ez volt a legolcsóbb megoldás. (Mint adathordozó, mint az azt kezelő eszköz oldaláról.) De már itt is két csoport van, az egyik adag sima monó magnót használt (régen ilyenről is hallgatott az ember zenét), a másik meg direkt az adott számítógéphez (-szériához) kifejlesztett datasette-et igényelt. Én a linken is szereplő CBM magnó variánsaival találkoztam leginkább, a környezetemben Commodore gépekkel voltak felszerelkezve az ismerősök. De annyira még én sem vagyok őrült, hogy most kazettára akarnék kiírni bármit. :) (Természetesen lenne rá megoldás, mint ahogy a „kiírás nélküli” emulációra is, de ennél azért van jobb verzió.)

Háttértárnak használtak (egy két kuriózumon kívül, mint pl. A Spectrum-hoz kapcsolható Microdrive) még valamilyen floppy diszket, leginkább 5¼-es méretben. (Persze itt is vannak kivételek, mint például a CPC6128 igen ritka 3”-os floppy-ja.) Itt már akár a célegyenesben is érezheti magát az ember, mert azért akad még használatban olyan pécé, amiben van floppy-csatoló, csak be kell egy meghajtót rakni a gépbe, aztán mehet a másolgatás. Hát, ahogy ezt Móricka elképzelte...

Itt is két, vagyis inkább három felé lehet választani a feladatot. A legegyszerűbb az, amikor valamilyen DOS-kompatibilis módon kezelte az adott gép a lemezt, ekkor tényleg csak egy sima floppyra másolás a megoldás. Ez a legritkább esetben működik így, én az Enterprise-t leszámítva mással nem is találkoztam élőben. A másik eset már gázosabb, de ekkor még a lemez szektor „formátuma” olyan, mint amilyet a pc-s floppy-vezérlő is tud írni / olvasni. Ilyenkor „csak” szoftver kérdése, de a pécébe berakott meghajtóval legalább lehet a lemezt kezelni. Valami ilyesmi a ZX-Spectrum (egyik fajta?) floppy-interfésze, ahol hiába a „hardveres” szektor-kompatibilitás, lehet küzdeni rendesen a lemezírással. A harmadik a legproblémásabb verzió, amikor a pc-s floppy-vezérlő eleve nem képes azt a formátumot kezelni, ahogy a lemezen van az adat. A Commodore élen járt ebben, természetesen itt nincs „egyszerű” megoldás. Viszont most pont ezzel fogok küzdeni... :)

Egyelőre maradok a 8 bites vonalnál, de ugyanez a gond megvan az AMIGA lemezformátumával is. Ott a rögzítés módja legalább ugyanolyan MFM, mint amit az x86-os floppyvezérlők is támogatnak, csakhogy a szektorok fejléce más felépítésű. Ez meg a pécés vezérlőkben „hard-kódolt”, emiatt se írni, se olvasni nem lehet velük az AMIGÁs lemezeket. De a régebbi, 8 bites lemezek még cifrábbak, ott a felírás nem MFM hanem GCR, azokat teljesen esélytelen így kezelni. Persze nem én vagyok az első, akinek ez feltűnt, létezik ehhez vezérlőkártya, amire egy hagyományos meghajtót kötve kezelhetővé válnak pc oldalról is ezek a lemezek. Persze ilyenem nincs, amúgy sem gyártják már, kérdéses a programkínálat hozzá, a GCR formátummal (illetve az azt kezelő „mindenki által ismert” 1541-gyel) használt lemezeket amúgy is csak megkötésekkel tudja kezelni egy gyári állapotú 5¼-es floppy-drive, szóval messze nem ideális.

Az 1541 lemezeit a legegyszerűbben egy 1541-es meghajtóval lehet kezelni. (Fura, mi? :) ) Ha pécéről akarok ilyen lemezt írni / olvasni, akkor a legcélravezetőbb megoldás a komplett drive pc-hez kapcsolása valamilyen interfésszel. Ilyet csináltam már nagyon régen is, akkor pécé oldalon elegendő volt egy párhuzamos nyomtató port. Ehhez kellett egy sima összekötő kábelt csinálni, utána egy remek programmal, a Star Commanderrel már lehetett is másolgatni. (Az X1541-es kábel egyik megkötése, hogy csak az eredeti „Standard Parallel Port”-ot (SPP) támogatja. A későbbi, alaplapra integrált portok ennél bonyolultabbak, de a linkelt oldalon rengeteg X..1541 kábelfajta leírása ott van, az ECP/EPP módban működő portokhoz az összes többi ajánlható. Nekem volt (van) SPP-s kártyám, emiatt az X1541-en kívül mást nem használtam.)

Eddig ha 1541 lemez olvasására vagy írására volt szükségem, egy régi gépet használtam, mivel a fenti összeállítás (SPP, X1541 kábel, 1541, Star Commander) kiválóan működik még ma is. Egy (nem túl friss) FreeDOS az operációs rendszer, emiatt elég nyűgös; nincs hálózat, nincs USB (Mass Storage támogatás), csak floppy-n (mármint pc-s, 3½-es 1.44MBYTE-os...) tudok rá adatot pakolni. Érdemes lenne az „alapot” lecserélni. (Már csak azért is, mert ezt a pakkot most félre is kellett raknom helyhiány miatt. Egy másolást most erős pakolással kell kezdeni / befejezni...) De ezzel a cserével akad két gondom. Az egyik, hogy a printer-port kiveszőben van, a másik, hogy a Star Commander DOS-os cucc. (Bizonyos körülmények között állítólag életre lehet kelteni DOSBox alól is, de igencsak nyögvenyelősnek tűnik csak végiggondolva is a használata.) Szerencsére ezekhez a kábelekhez van Linux alatt is használható „meghajtó”, amit most jól igénybe is fogok venni, de a printer portot, mint interfészt el kellene végre engedni. Szerencsére erre egy ideje már készülök... :) Az elpakolt régi gép meg adott némi inspirációt ahhoz, hogy befejezzek egy már hosszú ideje tervezett projektet.

Régebben meséltem egy fejhibás 1551-ről, amiben sikerült mechanikát cserélni. Akkor említettem, hogy egy olyan mechanikát anno rákötöttem egy 1541-II elektronikájára is, és az is teszi szépen a dolgát. Azt a projektet valamikor a múltban elbontottam, viszont most eszembe jutott belőle ez a meghajtó... Ami a mostani feladathoz pont jó alany lesz. Mivel az 1541-II olyan, hogy a meghajtó „arca” a gépházból van kialakítva, emiatt a cserélt mechanika nem szerelhető bele, újra kellene dobozolni. De úgy is lehetne pakolászni állandóan...

...hacsak nem építem be az egészet a pécé házába, ott kéznél lesz, nem útban. (Ráadásul a pokoli torony megfelelő alany ehhez, van benne 5¼-es hely rendesen.) A dobozolást így megúszom; csak az elektronikát kell a mechanika alá rögzíteni. Ez egyszerű: a mechanika alján vannak furatok M3-as menettel, azokhoz rögzíthető egy szerelőlap:

Ez a lap most egy szalagparketta-darab újrahasznosítva, már most van rajta egy rakás furat, de ha nincsenek útban, akkor itt nem számít. A mechanikához rögzítő csavarok furatait elkészítve, valami ilyen lenne az elképzelés:

A hosszú csavarokra majd valami távtartó kell a mechanika meg a szerelőlap közé (hogy „fölfelé” ne tudjon mozogni), az elektronikát meg fel lehet rá rögzíteni. Annak a pontos helyét azért nem ártana kitalálni:

A kritikus rész a fej kábele, azt nem tudom hosszabbra kicserélni (többek között azért, mert nincs ilyen kábelem). Annak a megfelelő helyre úgy kell odaérnie, hogy a fej normálisan tudjon tőle mozogni:

Az elektronikának ezért kell a mechanika alól kilógni, mert a fej mozgó szerelvénye a külső sávoknál már beleütközne a csatlakozóba. A szerelőlapot ugyan engedhetném „lejjebb”, de olyan hosszú csavarom nincs kéznél. :) (Illetve jó lenne 2U magasságba beférni, de a kilógásból még messze van jelenleg, az nem kritikus.)

Ez a felépítés így nagyjából jó, de hogyan is lesz ez a pécéhez kötve? Párhuzamos portom ugyan még van, de egyrészt meddig, másrészt meg nem akarnám erre a célra fixen elhasználni. Marad az USB, szerencsére ezt se nekem kell föltalálni. Mivel Linux oldalon az opencbm lesz a kezelőszoftver, ezért olyan hardver jöhet csak szóba, amit az tud használni.

A dokumentáció jelenleg két fajtát említ támogatottnak, az egyik az XU1541. Ennek a leírása (benne a kapcsolási rajzzal) elérhető, régebben már építettem egy ilyent. Valami miatt akkor nem volt vele túl nagy sikerélményem, aztán félreraktam, hogy ha majd lesz hozzá lelkesedés, akkor fölélesztem. A stuff egy ATmega8-ra épül, ami nem tartalmaz semmilyen USB hardvert. Az USB kezelése szoftveresen van megoldva, ami a µC futásidejének a jelentős részét lefoglalja, emiatt összességében ez egy elég lassú eszköz. (A meghajtóval való kommunikációra csak kevés CPU-idő marad, plusz az USB leglassabb, „Low-Speed” sebességű (1.5Mb/s) módját lehet csak így implementálni.) Két nagy előnye azért van: egyrészt tényleg olcsó, másrészt minden volt hozzá a fiókomban. A hátrány a lassúság mellet, hogy nekem nem működött. :) (Van ismerős, aki néha használ XU1541-et, a sebességén kívül más panasza nincs rá, tehát nem maga az eszköz rossz, csak nekem nem volt a megépítésével / élesztésével szerencsém. Egyszer lehet hogy azért elindítom. :) )

A másik emlegetett eszköz az XUM1541, más néven ZoomFloppy. (Pontosabban fogalmazva a ZoomFloppy egy XUM1541 firmware-rel működő hardver. A ZoomFloppy név – a leírás szerint – onnan jött, hogy sokan az XUM-et Zoom-nak ejtik. :) Ez egy készen megvehető hardver, de minden része publikus.) A firmware-e GPL2, az opencbm forráscsomagjában meg is található. (Mint az XU1541 esetében.) Ez az interfész szintén egy AVR-es µC-re épül, de olyanra, amiben van USB periféria hardver. (Ami – plusz előnyként – tudja a 12Mb/s-es „Full Speed” USB-t.) Mivel ilyen mikrovezérlőm még véletlenül sincs, ezért ennek a megépítését határozatlan időre elnapoltam.

Később ez az alkatrészhiány megoldódott; az egyik ismerősömtől kaptam egy „erősen költség-csökkentett” komplett XUM1541 adatpert. (Innen is köszönet érte!) Az erezeti ZoomFloppy egy ATmega32U2 mikrovezérlőre épül, a kapott cucc meg egy Arduino Pro Micro modul valamilyen klónjára, amiben egy ATmega32U4-es µC-é a főszerep. A két csip között csak a lábak száma a különbség. (Az U4-es verzió nagyobb, több portlába van.) A modul Arduino mivolta semmi jelentőséggel nem bír itt, sehol sincs használva a hozzá tartozó „ökoszisztéma”, csak a megfelelő mikrovezérlő, illetve a portok hozzáférhetősége a lényeg. A választás azért esett erre, mert a komplett, megszerelt modul olcsóbban kijött szállítással együtt, mint amennyiért itthon csak az ATmega32U2-t meg lehetne venni. (Ami azért valahol rendkívül szomorú... Lehet háborogni a modul „klón” mivoltán, de maga a hardver open source, bárki megépítheti.) Mivel a Pro Micro-n minden fent van, az adapter egy modult-fogadó nyákból áll csak, amin van pluszban egy 6 pólusú DIN csatlakozó aljzat a CBM soros kábele számára. A megfelelő lábak meg össze vannak kötve, aztán kész is. A terv az lett, hogy ezt a komplett adaptert felrögzítem a szerelőlapra az 1541-II elektronikája mellé, mivel elég pici, elfér bárhol:

Mint kiderült, azért mégsem annyira pici az a komplett adapter. (Mivel sokáig csak „kallódott” az asztalomon a kacatok között, ezért – megelőzve azt, hogy lecsapjak róla egy-két alkatrészt – kapott némi „védőréteget”. Ugyan beépítve ennek nem lesz szerepe, de rajta hagytam.) Az 1541-II elektronikája előtt nem fér be a mechanika alá, mellette meg nem maradt elég széles hely. :| Egy kicsit furán mutat így, de a gépben nem lesz szem előtt, illetve nem fogja bántani semmi. Mivel az adapterbe + drive elektronikába egyszerre nem lehet bedugni a kommunikációs kábelt (nem is volt tervben, belül nem akartam „kültéri” kábelt használni), ezért ezeket össze kell kötni:

Itt alul azért látni néhány magyarázatra szoruló részletet. :) A zöld keretben levő két vezeték az egyszerű: a mechanika felé menő csatlakozón van két nem kiépített / beszerelt csatlakozó pont. Oda be lett kötve a „drive aktív” visszajelző LED, mivel ez a mechanika előlapjára került, mint normál esetben. (Az 1541-II-ben ez – a Power LED-del együtt – egy különálló nyákon van.) Ez a jel így fölmegy a mechanikára a hozzá tartozó kábelkorbácsban, nem kell máshonnan odavezetni. A piros keretes vezetékezés már érdekesebb. :) A '41-II elektronikája erősen költség-csökkentett, egy kicsit talán túl is tolták ezt a témát. A CPU programját (a DOS-t) egy maszkprogramozott ROM tartalmazza gyárilag, aminek az engedélyező jele egyszerűen az A15-ös címvonal invertálva. Emiatt a – csak 16 KBYTE-os – ROM a címtér felső 32K-jában ($8000..$FFFF) mindig engedélyeződik. Akkor is, ha esetleg erre a címtartományra valamilyen program ír valamit. Ilyenkor a CPU és a ROM az adatvonalakon szépen összehajt. Nem érzem túl egészségesnek... :) Persze: ki és minek írogatná ezt a tartományt? Mivel a meghajtó RAM-jába lehet saját kódot tölteni, a programozók meg bármire is képesek, jobb a békesség. A két vezeték közül az egyik a CPU R/W jele, az megy egy eddig nem használt inverter bemenetére, (ez a bemenet fixen tápra (földre?) van kötve gyárilag, azt természetesen le kell onnan választani, ) ennek a kimenete meg megy a ROM egyik engedélyező jelére. (Ez meg fixen földre van eredetileg kötve, ez is leválasztandó!) Ezek után ha írás történik, akkor a ciklusra a ROM ki lesz tiltva.

A kék keretben látszik a soros vonalak adapterre kötése, ezen meg van pár utólag odaszerelt dióda. Ezek a soros vonalakon vannak védelem gyanánt; ugyan bekapcsolt esetben dugdosni ezeket a csatlakozókat egyáltalán nem tanácsos, de így talán nem megy a µC egyből tönkre. :) Fixen bekötve a nyákot ezek okafogyottakká váltak, de elférnek. (Felragasztott „védőréteg” ezen az oldalon is volt, de a forrasztások miatt le lett szedve.) Összerakva ilyen lett:

A meghajtó és a szerelőlap közötti „távtartó” vezeték-szigetelésből készült, a csavarok meghúzásakor ezek a megfelelő méretűre „összerogynak”. (A csavar meg a menetes furat aljába szorul meg, így nem fog attól kilazulni, hogy az „összerogyott” távtartók „úgy maradnak”. :) ) Közben a meghajtóra visszakerült a gyári (szürke) előlapja, ami rajta volt (fekete) majd megy tovább a következőre.

Viszont bármennyire is nézem, nem tetszik ez a lelógó adapter... Odébb kellene rakni a szerelőlapon a dolgokat. Jájj!™. Az összes furatot odébb kell fúrni... Feltéve, hogy az adott helyen már nincs valamilyen lyuk! :) Éppen, de szerencsére nincs:

Mivel a cucc bekerül a gépbe, az USB kábel így egy belső USB header-re fog csatlakozni. Az „A” dugó helyett a kábel végére egy ehhez tartozó dugó kerül majd. Illetve a drive tápját is jó lenne tudni bekötni... Ez eddig jó is. De ha bekerül ez a gépházba, sokat nem akarom kiszedegetni. :) A mese most ugyan nem az XUM1541 adapter készítéséről szól, de pár infó ide kívánkozik. Ez a „Pro Micro”-s verzió nem teljesen kompatibilis (hardveresen) az eredeti ZoomFloppy-val, ezért a firmware-jében van hozzá pár módosítás. Az adapter ezen projekt alapján készült, és a bekötést ábrázoló kép tanulsága szerint tudja az 1541-et párhuzamos adatátvitellel is kezelni, csak a hozzá tartozó 8 adatvezetéket kell összekötni. Ez egy „gyári állapotú” meghajtónál problémás, de itt a csupasz nyákon nem tart semeddig se... (Egy fix GND-t azért itt is le kell a VIA egyik portlábáról vagdosni.) Akkor jöhet az egész szétborítása ismét, 8 további adatvezeték bekötése:

Nagyjából itt kezdtem el gondolkozni azon, hogy miért is használom én a kapott adaptert..? :) Magát a Pro Micro-t egy prototípus-panelbe is bedughatnám, annak nem kell szükségszerűen szélesebbnek lennie, mint maga a modul. A soros port csatlakozója nem kell úgyse, a mérete meg sokkal kisebb lehetne mint most, elfért volna a komplett modul máshol... Na, de ez már így marad!

Lassan jöhet a beépítés:

A felső kettő üres helyet néztem neki ki, de a gépet kiszedve az asztal alól és szétbontva, hát... Eléggé botrányos belső állapotok uralkodnak! :-D Ami egyrészt szégyen, másrészt tulajdonképpen jó hír ám ez! :) Vajon reális az, hogy utoljára a TV-tuneres mókánál járhattam erre? Az meg már majd' 5 éve (!) volt. Akkor biztos takarítottam, de ha azóta nem volt okom szétszedni, akkor az azt is jelenti, hogy minden rendben volt vele. Így eldugva az asztal alá csak tette a dolgát. Viszont a sima beépítésből egy bő fél napnyi takarítás lett, nyilván ezt így nem hagyom. Még jó, hogy hétvégére időzítettem a dolgot... :)

Némi takarítás meg rendezgetés után már látszik a cél:

A szerlőlap a meghajtó alatt levő hely felét foglalja el kb, oda még egy 2½-es HDD-t be is tudok csavarozni. :) A meglepő mennyiségű hardvert, ami kijött a gépházból (a rengeteg kosz mellett), szépen vissza is kell rakosgatni:

Az 5¼-es helyeket valahogy sikerült feltölteni, a beszerelt 1541 alatt meglepően nagy tumultus alakult ki. Némi ODD/HDD átrendezés után azért egész kulturáltan összeállt (ezt a megjegyzést most tessék a helyén kezelni... :) ), persze lehetne bőven optimalizálni az eszközmennyiségen.

No de működik-e? :) Ezt a kérdést – így vagy úgy – már sok témánál feltettem. A cuccot az említett opencbm kezeli, és – furcsa módon – van ilyen nevű csomagom CentOS7 alatt telepítve. :) Ráadásul ez saját forgatás lesz, mert a használt repókban nem látom nyomát. A forráskód a sourceforge-ról letölthető, abban találni egy .spec fájlt a csomaggeneráláshoz, csak az egy kicsit elavult. De a leírás pontos; a fordítás a következő módon megy:

$ make -f LINUX/Makefile opencbm plugin-xum1541
# make -f LINUX/Makefile install install-plugin-xum1541

Mint látható, meg kell adni, hogy milyen a használt kábel típusa, ez még itt, fordítási időben dől el. (A párhuzamos portos kábeleknél kernel-modul fordulna, szerencsére az USB-s verziókhoz elég a libusb.) Ha minden rendben fordult / feltelepült, akkor egy udev szabály a csatlakoztatott XUM1541 adapter jogosultságait beállítja a megfelelő értékre ahhoz, hogy egyszerű földi halandó is használhassa. Vajon meg van-e az eszköz?

$ lsusb
Bus 005 Device 002: ID 16d0:0504 MCS RETRO Innovations ZoomFloppy

Valami van! Talán érdemes lenne a „buszon” körülnézni:

$ cbmctrl reset
$ cbmctrl detect
 8: 1541-II (XP1541)

Megvan a meghajtó, sőt, a párhuzamos interfésze is! Jöhetne egy RESET + státuszlekérdezés:

$ cbmctrl reset
$ cbmctrl status 8
73,cbm dos v2.6 1541,00,00

A 73,cbm dos v2.6 1541,00,00 válasz konkrétan a meghajtótól érkezett, jó hír! Na de dolgozzon is egy kicsit! Sima lemezformázás, ehhez egy üres / törölhető lemez kell a meghajtóba:

$ cbmctrl command 8 N:TESZT1,QW
$ cbmctrl status 8
00, ok,00,00
$ cbmctrl dir 8
0 ."teszt1          " qw 2a
664 blocks free.             
00, ok,00,00

Ez a klasszikus, CBM DOS-os „lassú” lemezformázást hajtja végre. (Aki ismeri az 1541-et, annak nem idegen: az N:TESZT1,QW parancs lett a meghajtó un. parancs-csatornájára kiküldve, amiből az N a New, azaz új lemezt jelenti, az utána levő TESZT1 a lemez „címkéje” lesz, a QW meg a lemez ID-je.) Viszont formázásra van külön parancs is, ami ennél jóval tempósabb:

$ cbmformat -psv 8 TESZT2,ER

Ez meglehetősen gyorsan :) megformáz egy lemezt. A -p paraméter némi „progressz bárt” húz a képernyőn a folyamat alatt, a -s a formázás végén automatán kér egy status-t a meghajtótól, a -v meg a sávok felírása után vissza is ellenőrzi azt. (Ez azért erősen ajánlott. Ilyen öreg meghajtónál / lemezeknél bármi előfordulhat...) Viszont – ahogy nézem – van valami új stuff a lemezek formázásához:

$ cbmforng -vs 8 TESZT3,TY

Ez valamilyen „új generációs” formázó rutint használ, a végeredmény egy szép kis táblázat:

Benne, hogy melyik sávot hányadik körben sikerült formázni, illetve mekkora a számított lemezforgás (RPM). (Az első sávot valahogy mindig csak a második próbálkozásra sikerül neki formázni... Ez szerintem valami nem lemezhiba lesz. :) ) Az RPM értékek viszont nagyon is tetszenek! Az eltérés 0.2..0.3% összesen! Vajon mennyi lehet az eredeti D500 laposszíjas hajtásánál ez? Egy régi, sima 1541:

A 298.73 - 299.07 tartomány szintén nem túl nagy szórás, de azért látványosan nagyobb az eltérés mint fent.

A lemezem már agyon van formázva, kellene rá fájt másolni:

$ cbmcopy -w -o 41filename 8 pcfilename.prg

Itt a -w paraméter jelenti az írást, de van ehhez „külön” parancs is:

$ cbmwrite -o 41filename 8 pcfilename.prg

A -o 41filename a felírt fájl 1541-es lemezen levő nevét adja meg, ezt kihagyva a pécés fájlnév lesz valamilyen formában a név. A CBM DOS a fájl kiterjesztést nem a név részeként kezeli (nem is lehet akármi), ezért a kiterjesztést itt nem is kell a névhez hozzáírni! A 8 maga az egységszám (ez lehet 8, 9, 10 illetve 11), a többi parancsnál is ugyanez a jelentése. A pcfilename.prg meg a felmásolandó fájl neve. De fájl(oka)t az 1541-es lemezről olvasni is lehet:

$ cbmcopy -r -o pcfilename.prg 8 41filename

Illetve a párja:

$ cbmread -o pcfilename.prg 8 41filename

A 41filename mindig kiterjesztés nélkül értendő, az 1541 oldalán „PRG” típusú lesz a fájl. (Ha más kell, érdemes a parancsok helpjét tanulmányozni.)

A talán leggyakrabban használt két parancs még vissza van; 1541-es lemezről disk-image készítése:

$ d64copy 8 destination.d64

Ezzel a paranccsal – értelemszerűen – a kiválasztott eszközszámú meghajtóról fog disk-image készülni, destination.d64 néven. Visszafele, ehhez formázott lemez kell:

$ d64copy source.d64 8

Itt a source.d64 nevű disk-image lesz az 1541-es lemezre felírva. Viszont nálam egy „anomália” jelentkezett itt, a lemez első felét meglehetősen lassan írta így fel. A parancs módosítása javított a helyzeten:

$ d64copy -i 5 source.d64 8

Ehhez nem árt némi magyarázat. Mivel az eredeti kommunikációs rutinok – hogy is mondjam szépen – nem túl gyorsak, emiatt a fenti parancsok (amik fájl és „imidzs” írást / olvasást végeznek) mindegyike speciális adatátviteli rutinokat használ az XUM1541 ↔ 1541 között. Az teszi ezt lehetővé, hogy a drive memóriájába bármilyen programkódot be lehet tölteni + lehet futtatni. (És ez itt nem kihasznált „bug”, hanem beépített gyári „feature”.) Ezen felül lehetőség lehet több fajta adatátviteli rutint is készíteni a hardver fajtájától / kiépítésétől függően. A legalapabb verzió az 1541 + sima soros kábel, de például az 1571 / 1581 tud egy gyorsabb adatátvitelt is. Mint ahogy a fenti hardver is, ahol bekötöttem ehhez pluszban azt a 8 adatvezetéket. Ezért ezen másolós parancsok mindegyike azzal kezd, hogy kideríti, mik is a hardver lehetőségei, és utána az ahhoz passzoló leggyorsabb kommunikációs rutinokat használja. (Ezt az automatizmust felül lehet bírálni a -t ... / --transfer=... paraméterrel.) Esetemben ez a párhuzamos port használatát jelenti automatikusan, emiatt jóval gyorsabban mozognak az adatok, ezt tényleg kár lett volna kihagyni a konfigurációból. :)

Ezért a fenti disk-image kiírás is (alapból) párhuzamos adatátvitellel zajlik, de ezt lehet tovább boncolgatni. A feladat az, hogy a lemez összes szektorát az összes sávon újra kell írni a megfelelő adattal. Az optimális megoldás nyilván az lenne, ha egy-egy komplett sáv felírandó tartalmát át lehetne tölteni a meghajtó memóriájába, majd onnan „egy lemezfordulat alatt” az összes, a sávon található szektort sorban fel lehetne írni. Ehhez viszont a drive-ban levő 2 KBYTE-nyi memória kevés. (A legtöbb szektor egy sávon 21, ezekhez kellene 21 × 325 = 6825 BYTE, ennyi az összes szektor GCR-be átkódolva. Ha lenne 8 KBYTE RAM, nagy lenne az öröm, de nincs.) Lehetne az is megoldás, hogy amíg az egyik szektort írja a meghajtó a lemezre, azalatt a következőét lehetne már átküldeni egy másik memóriapufferbe. Ezzel két gond is van. Egyrészt ehhez az XUM1541 oldalán kellene ez a 8 KBYTE-nyi memóriapuffer, ami szintén nincs meg. (Az ATmega32U2-ben 1 KBYTE-nyi RAM van...) Másrészt a lemezre írás lefoglalja annyira a meghajtó CPU-ját, hogy nem marad ideje mellette semmilyen adatátvitelre.

Marad az a megoldás, hogy egyesével kell a szektorok új tartalmát átküldeni a drive memóriájába, onnan az felírja, majd jöhet a következő felírandó szektor adatainak az átvitele. Viszont: a lemez forog. Ha megjön egy szektornak az új tartalma, akkor ki kell várni, míg a sávon belül az a szektor ér a fej alá, hogy ezt az új tartalmat fel lehessen oda írni. Majd miután a felírás lezajlott, jöhet a következő szektor tartalmának az áthozása a drive memóriájába. De ameddig ez az adatátvitel zajlik, a lemez az szépen forog tovább, így mire oda jut a CPU újra, hogy az újonnan kapott szektort felírja, az előző szektor végéhez képest már ~sok szektornyit elfordult a lemez.

Ha a sávot a lehető legrövidebb idő alatt újra kellene írni, akkor célszerű következő szektornak olyat átküldeni, ami az adatátvitel után éppen sorra kerül majd a fej alatt. A d64write pontosan ezt teszi. Az, hogy egy ilyen adatátvitel alatt hány szektornyit fordul a lemez, az magától az adatátviteli megoldástól függ. Az itt bekötött párhuzamos port sanszosan a leggyorsabb lesz, de erre rájön még az USB kommunikáció ideje, illetve a drive-ban a felíráshoz tartozó előkészületek hossza. De a lényeg: mindegyik adatátviteli fajtához tartozik egy „szektor-szám”, amennyit tutira fordul a lemez, míg újra írni tud a meghajtó az előző írás után. (Ez az interleave.) Ezeknek van egy default értéke, ahogy nézem, a párhuzamos átvitelnél ez alapból 4 lesz. Ha ez az érték túl kicsi, akkor az adatátküldés után majdnem egy teljes körbefordulást meg kell várni, míg újra a megfelelő szektor kerül a fej alá. Úgy gondolom, a „gyári” értékeket úgy állították be, hogy a leggyorsabb legyen a felírás összességében... (De melyik fajta kábellel / adapterrel..?) Viszont valószínű, hogy a fejlesztők által tesztelt meghajtó egy kicsit lassabban forog, mint a 300 RPM +0.3%-os saját példányom. :) Emiatt a sebesség a 21 szektoros sávokon (a lemez ~fele ilyen...) drasztikusan visszaesik. A kevesebb szektoros sávokon már nincs ilyen gond; ott két szektor között – a lassabb bitsebesség miatt – több idő telik el. A fenti példában az -i 5 / --interleave=5 paraméter ezt a „kihagyási értéket” állítja 5-re. Azzal megfelelő lesz a sebesség.

De ha már méricskélés: a különböző adatátviteli rutinokkal csináltam időméréseket. Mindegyik esetben ugyanaz az image lett kiírva ugyanarra a lemezre. A parancsok a következők:

• Serial1 adatátvitel, alap interleave (6), nagyobbal már lassul:
  $ time d64copy --transfer=serial1 source.d64 8
real 3m10.084s
• Serial1 adatátvitel, 5-ös interleave:
  $ time d64copy --transfer=serial1 --interleave=5 source.d64 8
real 3m3.071s
• Serial1 adatátvitel, 4-es interleave:
  $ time d64copy --transfer=serial1 --interleave=4 source.d64 8
real 2m56.291s
• Serial1 adatátvitel, 3-as interleave:
  $ time d64copy --transfer=serial1 --interleave=3 source.d64 8
real 2m49.287s
• Serial1 adatátvitel, 2-es interleave:
  $ time d64copy --transfer=serial1 --interleave=2 source.d64 8
real 2m42.716s
• Serial1 adatátvitel, 1-es interleave, nagy visszaesés:
  $ time d64copy --transfer=serial1 --interleave=1 source.d64 8
real 4m44.685s
• Serial2 adatátvitel, alap interleave (12), nagyobbal már lassul:
  $ time d64copy --transfer=serial2 source.d64 8
real 1m35.605s
• Serial2 adatátvitel, 11-es interleave:
  $ time d64copy --transfer=serial2 --interleave=11 source.d64 8
real 1m28.671s
• Serial2 adatátvitel, 10-es interleave, nagy visszaesés:
  $ time d64copy --transfer=serial2 --interleave=10 source.d64 8
real 2m31.741s
• Parallel adatátvitel, alap interleave (4):
  $ time d64copy --transfer=parallel source.d64 8
real 1m47.525s
• Parallel adatátvitel, 5-ös interleave, nagyobbal már lassul:
  $ time d64copy --transfer=parallel --interleave=5 source.d64 8
real 0m46.513s
• Elrettentésnek az eredeti adatátvitel, alap interleave (1), bármi mást nincs értelme még kipróbálni se:
  $ time d64copy --transfer=original source.d64 8
real 9m23.067s

Tanulság? Érdemes lehet az interleave értékkel játszani, nem biztos, hogy a default értékek a legjobbak. (Lehet hogy a meghatározásuk óta optimalizálódott az adott adatátviteli rutin, nem biztos, hogy az XUM1541-gyel lettek kimérve, stb.) A párhuzamos írás 47 másodperce szimpatikus. :) Érdekes, hogy a Serial1 interleave 2-re csökkentésig gyorsult, 1-re állítva viszont drasztikusan visszaesett. Viszont! Itt a 2 még véletlenül se azt jelenti, hogy egy szektor ideje alatt átment a következő szektor adatcsomagja, és csak egyet kell kihagyni... Neeeem, itt közben egy teljes fordulatot megtett a lemez, ezen felül meg még több mint egy szektort! :)

Az olvasásra külön nem teszteltem változó interleave-vel, mivel – úgy tűnik – ott nincs jelentősége, ami érthető is. Ez úgy megy, hogy beolvas az 1541 egy szektort, átküldi a gépnek, majd megnézi azt, ami éppen jön. Ha ez a sávon még olyan számú szektor, amit nem küldött át, akkor beolvassa, átküldi, majd ez így addig, ameddig el nem fogy az összes. Így itt is lesz egy ~átlagos interleave, de ez dinamikusan akkora lesz, amekkora az ideális. Azért egy kis táblázat jöjjön erről is:

• Serial1:
  $ time d64copy --transfer=serial1 8 destination.d64
real 2m32.177s
• Serial2:
  $ time d64copy --transfer=serial2 8 destination.d64
real 1m19.963s
• Parallel:
  $ time d64copy --transfer=parallel 8 destination.d64
real 0m35.455s
• Original:
  $ time d64copy --transfer=original 8 destination.d64
real 8m56.044s

Az adatátviteli üzemmódokról részben volt már szó; az „original” felel meg a gyári adatátviteli protokollnak. Annak minden eszközzel működőképesnek kell lennie, ami ehhez a CBM soros buszhoz kapcsolható. A „serial1” már valamivel gyorsabb, a „serial2” meg még ehhez képest is fejlődött. Viszont megvan mindkettőnek a létjogosultsága, a „serial2” csak egy eszközt enged meg egyszerre a buszon. (Volt már szó a CBM soros buszáról; abban említettem, hogy az ATN vonal, amit a host vezérel, az beleszól a DAT vonal hajtásába az eszköz oldaláról. A „gyorsított” adatátvitelnél az szokott lenni az egyik trükk, hogy a CLK és DAT vonalat is adatvezetéknek használják, emiatt egyszerre nem egy, hanem két bit tud közlekedni a buszon. Viszont ha némi handshake-re szükség van, erre az ATN használható, de ezt a másik oldalnak figyelembe kell vennie. Ha több eszköz is lenne a buszon, akkor az(ok), amelyikkel éppen nem folyik kommunikáció, beleszólna(k) a DAT vonal állapotába.) A „parallel” meg a soros vonalak mellett használja még az utólag bekötött 8 adatvezetéket is, aminek a fenti példákban bőven látszik az eredménye.

Pár – nem minden esetben összefüggő – megjegyzés ide a végére:

• A fenti parancsok közül több is „hosszú ideig” fut, hála a nem túl gyors háttértárnak. Ezek futása a pécé oldaláról megszakítható a szokásos (Ctrl+C) módon. Viszont erről a buszon levő eszköz „nem tud”, az továbbra is csinálja a feladatot, vagy vár a pc-s programra. Innentől kezdve nem működik semmi. :) A cbmctrl reset parancs ilyenkor jó szolgálatot tesz, ez a soros buszon egy RESET impulzust generál, ami az eszközök hardveres RESET-jét eredményezi.
• A gépbe beépített meghajtó egy jó dolog! :) Viszont a sima 1541 tesztelésénél egyből előjött mint igény, hogy azt a soros buszt mégis csak jó lenne kívülről is elérhetővé tenni; ahhoz a teszthez szintén ki kellett nyitni a tornyot. Illetve – ha már lesz busz kívül, – jó lenne tudni a beépített meghajtó egységszámát is változtathatóvá tenni. (Mondjuk átállíthatnám fixen 9 / 10 / 11 értékre, így egy 8-ast kívülről simán lehetne még csatlakoztatni, több eszközt nem gondolok ésszerűnek.)
• Az 1541 elektronikája most fixen „jár”, amikor a gép be van kapcsolva. Mértem fogyasztást, a +5V-on ilyen 430mA körüli áram folyik. A +12V az 210mA körül van, de az csak akkor mérhető, ha be vannak kapcsolva a motorok, kikapcsolva 10mA alatt van a fogyasztás. Ez használat közben 5W körüli fogyasztást jelent, „idle”-ben 2.5W alatti ez az érték. Nem túl nagy, de esetleg a későbbiekben lehetne rá valami tápkapcsoló áramkört barkácsolni, mert azért nem egy mindennap használt eszközről van szó, akkor meg minek fogyaszt?
• A CBM soros busz csatlakozói nem hotplug kialakításúak! Bekapcsolt állapotban nem szabad fel/lecsatlakoztatni őket! Az XUM1541 leírásában arról is van szó, hogy mi a helyes sorrend: #1: soros kábel összedugása a meghajtó kikapcsolt + USB kihúzott állapotában; #2: USB kábel bedugása; #3: 1541 bekapcsolása. (A szétcsatlakoztatás ugyanez visszafele.) Nálam ezzel nincs gond; egyrészt közös a táp, másrészt nem lehet rossz sorrendben bekapcsolni. A belső USB csatlakozóra kivezetett táp az ATX StandBy +5V, és ezt ezen az alaplapon nem is lehet állítani. (Ez ilyen, az összes USB táp ezt kapja, nem konfigurálható.) A Pro Micro erről a tápról jár, ez már akkor megvan, amikor a gép még be sincs kapcsolva. Olyan állapot meg nem tud előállni, hogy az 1541-nek már van tápja, az XUM1541-nek meg még nincs. (Ez azért nem lenne szerencsés.)
• A torony legfelső szintjére került a meghajtó mechanikája, viszont a gépház előlapján van egy „hullám” kialakítva. Emiatt a meghajtó karját egy kicsit kényelmetlen kezelni, de nem bánom, annyit nem lesz ez használva, hogy idegesítsen. Hogy máshova át nem logisztikázom, az tuti! :)
• A beépített meghajtó helyére lett volna egy alkalmasabb jelölt is; ha valahonnan kerítek egy jó D500-as mechanikát, az 1541-II-t vissza lehetne állítani nagyjából a gyári állapotra. A másik példány egy sima 1541, aminek nincs meg a burkolata, csak a belső fém váz a komplett tartalmával. Viszont annak az elektronikája jóval szélesebb, mint egy 5¼-es mechanika, így széltében nem férne el a rendelkezésre álló helyen. Egyelőre nincs ötletem, hogy hogyan / hova „tetriszeztem” volna be a toronyba.
• A Pro Micro-ból két fajta is létezik, van belőle +5V mellett +3.3V-os verzió is. Ez utóbbi változat csak 8MHz-es sebességű, az XUM1541-hez a +5V-os, 16MHz-es verzió kell. (Az eddig olvasott dokumentációkban nem találtam erre utalást, de a +5V a CBM soros vonalai miatt biztos. :) ) Néhány helyen olvasni, hogy a klónok közül sok 16MHz-es quartz-cal készül, de alapból +3.3V-os feszültségen üzemel. (A µC specifikációjából ez bőven kilóg. :) ) Ez egy jumper (J1) rövidre zárásával átváltható +5V-ra.
• Akartam morogni egy sort, hogy a .d64 fájlkiterjesztés eléggé szűk látókörű, merthogy egy ilyen „image”-ben nem csak C64-es tartalom lehet. (A későbbi, .d71 illetve .d81 fájlok mintájára ez is lehetne inkább .d41.) De ezt a morgást inkább félrerakom; simán lehet, hogy a kiterjesztést kiötlő úgy gondolta, a .d64 az egy C64-es lemezt fog jelenteni, mindenki más meg használjon sajátot. Így lehetne külön .d20, .d16, .d28... :) Van egy sejtésem, hogy ez már így marad...
• Az opencbm egy jó stuff! A fenti példák csak az alap működésről szólnak, érdemes körülnézni a dokumentációban. A gépen „talált” verzió a 0.4.99.99 számot viseli, amit még 2018-ban forgattam. Az oldalon újabbat nem látni, de a forráskódon látszik, hogy azért foglalkoznak vele, nem egy „befejezett” projekt.
• A gép a takarítás óta mintha kevésbé zajongana... (Na ja, nem akar a CPU megfőni.) A nem használt kártyahelyekre mindenesetre kerestem záróelemeket, így talán kevésbé fog porosodni. (Álom...)

Ez ismét egy olyan projekt, amit így végigcsinálva azon gondolkozok, hogy miért vártam én ezzel eddig? :)

2020.06.07.: Felmerült kérdésként, hogy mennyire bírják nálam ezek a régi eszközök. Erre egy jó példa, hogy tegnap ez a beépített meghajtó megadta magát. :) Olyat csinált, amivel eddig csak egyszer találkoztam: hibakódot villogtatott. Ez azért nagy szó, mert ahhoz, hogy idáig eljusson, egy rakás alkatrésznek „jól” kell működnie, ami meg hibás, az nem „blokkolhatja” a (mindenféle) buszt. A lemorzézott hibakód az „1”-es volt, ami – ha jól nézem a DOS forráskódját – ZeroPage hibára utal. (Ez a 6502 memóriatartományának első 256 BYTE-ja, speciális feladatokra van fenntartva, célszerűen RAM-nak illik lennie.) Ezeket a hibakódokat erős fenntartással szabad csak elhinni; nekem a RAM helyett az első tippem a CPU volt, mint hibás eszköz. A nyákon „szerencsére” be van foglalatozva (a VIA-kkal együtt), így egy gyors CPU-csere után kiderült, hogy a benne levő az jó. VIA-m az nincs kéznél, de a kettő felcserélése nem változtatott semmit, mint ahogy a DOS ROM kicserélése sem. Marad akkor a 2 KBYTE-os SRAM, de az forrasztott… Az SRAM működésébe beleszól még az a „Gate Array” is, ami direkt ehhez a meghajtóhoz készült; annak a hibája valahogy nem lenne túl jó hír… No de először jöjjön csak az SRAM csere:

A RAM kapott maga alá egy „szép” foglalatot, a nyák meg egy csere SRAM-csipet. A végeredmény: simán indul a cucc! (A Gate Array esetleges hibája egy kicsit zűrösebb lett volna… Azon felül csak sima TTL alkatrészeknek van közük az SRAM kezeléséhez, csodálkoztam volna nagyon, ha azok közül lett volna valami „megromolva”.) De ha már ismét szét kellett borítani a tornyot, csináltam még egy képet egy olyan részletről, ami eddig kimaradt:

A fej kábelének a rögzítése; ami azért fontos, mert nagyon nem oda van csatlakoztatva, ahova eredetileg szánták. A fej mögött egy lyukon bújik le az elektronika fejcsatlakozójához, viszont „nem ártana”, ha mozgás közben nem akadna bele semmibe. Egy rézdrótból lett neki hajtogatva egy tartó, ahhoz van hozzárögzítve. A fej mozgása közben úgy „hurkolódik”, hogy nem ér hozzá semmihez.

A RAM-csere szükségessége miatt felmerült, hogy rakjak bele a 2 KBYTE-os helyett valami nagyobb méretűt, de annak végül nem ugrottam neki. A – mondjuk – 8 KBYTE-os SRAM már nem 24 hanem 28 lábú tokban van, amit még viszonylag egyszerűen bele lehetne „operálni” a jelenlegi helyett, de a RAM-kiválasztó logikát egy kicsit meg kellene túrni, ahhoz meg nem volt most lelkesedés. Amúgy is: azóta nagyon ferde szemmel sandítok néha a drive-ra, hogy minden rendben van-e vele… :) Érdemes lesz azt a táp-kapcsolót megcsinálni hozzá, nem kell ennek folyamatosan mennie.

Az elmúlt bő másfél hónap alatt látható mennyiségű port volt képes összeszedni a mechanika, emiatt továbbra is jó ötletnek tűnik a „papírlemezt” bent tartani használaton kívül. Az legalább a fejet nem engedi összeporolni, ami meg jól rákenődne egy frissen behelyezett lemezre. (Ez a „papírlemez” a szállításhoz való egyébként. Létezik ebből olyan fajta, ami a behelyezéskor „hátratolja” a fejet, így azt is rögzíti. Na, ez nem ilyen, nyugodtan tologathat tőle a DOS… :) )

Irodalom:

• Az opencbm oldala
• opencbm forráskódok a sourceforge-n
• Pro Micro-s XUM1541 leírás
• Pro Micro modul anyagai
• Pro Micro kapcsolási rajz

balagesz

---

2020.04.16.
2020.04.17. „maghajtó”→„meghajtó”
2020.06.07. RAM-csere, fejkábel rögzítés