Retró rovat IV/B: Az 1551-II projekt folytatása

Először arra gondoltam, hogy megosztom én is a frissítés alatt átélt kálváriát, de ez igencsak rövid lesz, belefér egy bekezdésbe. Az update parancs:

yum --releasever=18 --disableplugin=presto distro-sync

Ez sajnos nem futott le, az RPM Fusion tárolóval volt némi gondja, amit az update idejére ki kellett tiltani, ill. az mplayer meg a VLC csomagokat le kellett szedni. Utána már lefutott a frissítés. Röpke 1.7 giga letöltött anyag... A kitiltott tárolók visszakapcsolásánál volt még annyi bökkenő, hogy az új verzióhoz (18) hiányoztak a hitelesítő kulcsok. Vagyis, maguk a kulcsok ott voltak a helyükön, csak az architektúrához (x86_64) tartozó szimlinkek nem voltak meg, ezeket kézzel létrehozva minden működőképes lett. Mindez a történet a megjelenés napján este. Pedig megígértem magamnak, hogy várok vele pár napot... :)

Szóval erről írjak egy blogbejegyzést? Maradok inkább az előző téma folytatásánál.

Tavaly (elképesztő...) odáig jutottam, hogy maga a drive módosítása elkészült, de a géphez kapcsolás még egy gyári 1551 paddle segítségével volt megoldva. Persze azt is meg kell csinálni „sk”, ami újra okot ad a forrasztópáka meg a régi CPLD-im előszedésére. A gyári paddle egy igen egyszerű jószág: van benne egy 6523T, ami egy csonka 6523 TPI. A csonkítás abból áll, hogy az eredeti 6523 24 db. I/O vonallal rendelkezik, a 6523T ennek a felével, 12-vel. A mínusz 12 I/O-hoz tartozik mínusz 12 kivezetés is, így ez az IC egy 28 lábú DIP tokozásban elfér. Emellett van még egy PLA (251641-03 típusjellel, ami NEM ugyanaz mint a 251641-02, ez utóbbi a C16 ill. plus/4 saját PLA-ja), ami a címdekódolást végzi. A terv az, hogy ezt a két IC-t egy darab XC9572-be belevarázsolom. Ebből a tokból van pár maradék példányom, ilyen helyekre pont jól el lehet majd használni ezeket. (A komplett széria gyártását befejezi a gyártó (ezt a táblázatot rossz nézni, gyakorlatilag 5V-os CPLD nélkül maradnak a „hobbisták”), így más helyre nem tervezhetem már be őket...) Arra viszont oda kell figyelnem, hogy nincs több XC95108-am, így nincs mese, a kisebb tokba BELE KELL FÉRNEM.

Megvan akkor a „terv”: egy „egy csipes” TCBM interfészt kell készítenem. De ha már itt tartunk, erről a TCBM interfészről is illene pár szót írni... A wikipedia szerint ezt az interfészt a Commodore tervezte a C64-hez is elkészíteni, de nem lett belőle semmi. Így maradt a 264-es széria „kiváltsága”. Hogy ez jó-e vagy sem, azt mindenki döntse el maga... :) Az interfész 12 (+2) jellel operál, egy bit-párhuzamos byte-soros működésű, egyszerű programozott I/O-ról van szó, sajnos semmilyen DMA-s trükk nincs benne. A +2 jel közül az egyik a _RESET, ami arra szolgál, hogy a gép RESET eseményekor a meghajtó is induljon újra. A másik a DEV, ami egy „rafinált” jel. Ezt a meghajtó állítja elő, és tulajdonképpen nem más, mint az egységszám. Az 1541-et négy fajta egységszámra lehet beállítani (8, 9, 10 ill. 11), az 1551-et csak kettőre (8 ill. 9). A TCBM interfész nem olyan mint a Commodore soros busza (vagy az IEEE-488, amiről a logikát „kölcsönvették”), ez egy egyszerű pont-pont kapcsolat. Tehát a TCBM egyik oldalán a számítógép, a másikon a meghajtó van. Ennyi. Ha két meghajtó kapcsolódik a géphez, mindegyikhez tartozik egy saját interfész. De hogy ezek „ne vesszenek össze”, más címeken kell elérnie a gép processzorának őket. Itt jön képbe a DEV jel, ugyanis ez a paddle PLA egyik bemenetére van kötve, amivel a dekódolt címtartományt kapcsolja át. A 8-as egységszám kiválasztásakor ez a vonal talán magas, ekkor a paddle fél TPI-je $FEE0..$FEFF tartományban látszik, 9-es esetén a vonal alacsony, a címtartomány meg $FEC0..$FEDF. A KERNAL egy kicsit „érdekesen” használja a címeket, a 8-as egységszámú eszközt $FEFx-en keresi, a 9-es számút meg $FECx-en. A csonka TPI is 8 (pontosabban 6) regisztert tartalmaz, a 32 BYTE-nyi terület egy kicsit túlzás, tippem sincs, hogy miért lett ekkora...

A „maradék” 12 I/O vonal a tényleges busz, ebből 8 vezeték maga a párhuzamos adat (DATA7..0). Hogy ezt „ki hajtja”, a gép vagy a meghajtó, az változó... Általában a gép hajtja, de egy kicsit kacifántos. Van még két STATUS vonal, ezt a drive hajtja, a gép oldalán ez mindig bemenet. A maradék két vonal neve érdekes: úgy hívják őket, hogy DAV (Data Valid) ill. ACK (ACKnowledge). Hogy melyik melyik? Az attól függ, honnan nézem... Egy biztos: az ACK a kimenet, a DAV a bemenet. Ez a két jel „keresztbe van kötve”; a paddle ACK kimenete a drive DAV bemenetére van kötve, és viszont. Működés (mármint a gyári...) közben csak a DATA 8 vezetékének az adatiránya változhat, a többi jel iránya fix. Tulajdonképpen azon jelek adatirány-regiszterét meg se kellene valósítani, de ezen nem érdemes spórolni, mivel az eredeti konfigurációban szabadon programozhatók, a „kóderek” meg jó kérdés, hogy milyen galádságokat követtek el eddig... :)

A TPI regiszterkiosztása megvan a doksijában; a csonka TPI meg úgy néz ki, hogy a PORTA/DDRA regiszter teljes (ez a DATA), a PORTB/DDRB regiszterpárból a B1/B0 van megvalósítva (STATUS vonalak), a PORTC/DDRC párból meg a B6/B7 „él” (DAV és ACK), a többi bit nincs kiépítve, iránynak és adatnak is „0”-át ad vissza. A hardver elkészítéséhez ennyi információ elég is.

Első lépésnek kellene valami nyák, amin a kívánt alkatrészeknek elférnek, ill. ennek a cuccnak a megfelelő helyre oda kellene férnie. A helynek a gépben az „USER PORT” csatlakozó fölötti rész van kinézve, a nyák meg valami ilyesmi lesz:

A „gépépítős” blogban emlegetett csatlakozó párja van itt, az akkor pontosan azért került oda beépítésre, hogy ez a belső bővítés (ill. még egy másik tervezett) legyen hova csatlakoztatható. A TCBM busz csatlakozója a másik oldalra került:

Egyrészt a csatlakozók olyanok, amik a fiókban voltak, egy kicsit „faragni” kellett rajtuk, hogy a megfelelő méretűek legyenek. Másrészt ebből a kettőből most a CPLD foglalatához közelebbi a lényeges, az lesz a TCBM csatlakozója. Ez annak a párja lesz, ami a meghajtó hátuljára került, a kettőt egy sima 20 eres szalagkábel köti össze. (Ugyan elektromágneses szempontból nem éppen szerencsés, de sorozat nem lesz belőle... :) ) A másik csatlakozó egy másik busz (ami ténylegesen busz), nevezetesen egy IEEE-488 interfészé lesz, de az a következő rész tárgya.

Ahhoz, hogy ez a tervezett helyére majd beférjen, egy kicsit alakítani kell a gép alaplapján:

A biztosíték, meg a foglalata túl „nagy”, az most egy „sima” rövidzárral lett helyettesítve.

FIGYELEM! ATTENTION! WARNUNG! POZOR!

Ezt a módosítást otthon ne csináld meg! :) A gép gyári tápegysége egy egyszerű transzformátoros áteresztő táp. A transzformátor primer oldala egy biztosítékkal van védve, a gép fele egy stabilizált DC 5V-os táp ill. egy stabilizálatlan AC 9V-os táp megy. A stabilizátor IC-ben van rövidzárvédelem, de az AC 9V az nincs védve sehogy. A gépben fent emlegetett biztosíték erre a célra szolgál. Tehát kell az... Én azért szedhettem onnan ki, mert nem a gyári tápegységet használom, hanem egy kb. 100W körüli kapcsolóüzemű tápot (erről megy a meghajtó is, így nem kell ahhoz se külön doboz). A gép DC 5V-jára a táp DC 5V-ja van kötve, az AC 9V-ra meg a táp DC 12V-ja. A gépben ez a táp (mármint az AC 9V) két dologra kell. Az egyik: ki van vezetve az „USER PORT”-ra. Ha használnék olyan eszközt (de nem használok), amihez kell, akkor ott van. Vagyis most a DC 12V van helyette ott. Szóval ez nem lényeges. A másik: egy egyenirányítás után az 1531-es „Datasette” motor tápja ebből állítódik elő, de az működik a DC 12V esetén is. Szóval ez itt simán megengedhető a részemről... (A C64-ben „használva van” a táp AC mivolta, egyrészt a SID tápját előállító feszültségkétszerező elektronika DC-vel nem működik, ill. a CIA-k TOD bemenetét 50 (vagy 60) Hz-es jellel ellátó elektronika is „ebből él”.) És ennek a kapcsolóüzemű tápnak minden kimenete rövidzárvédett, emiatt hagyhatom ki azt a biztosítékot „nyugodtan”.

Az áramkör építésének további részletei – mondjuk úgy – nem lettek túldokumentálva, a körülbelül elkészült cuccról van csak képem:

Ezen már ott van az IEEE-488 interfészhez kellő alkatrészmennyiség is, de a szépség a túloldalt rejtőzik:

Egyszer tuti szétszedek egy ilyet, és megmérem hogy hány méter drót van beleforrasztva... :) Az „egy csipes” felépítés annyiban módosult, hogy az IEEE-488 interfész már nem fért teljesen bele az XC9572-be (hogy miért nem az XC95108-ból van egy marékkal...), úgyhogy abból egy rész „kiszerveződött”. No de hogyan is kerül ez bele a gépbe? Hát valahogy így:

A két nyákot egy szalagkábel köti össze, ami – ha majd elkészül a másik „hack” is – nem így lesz elvezetve, de ez most részletkérdés. A csatlakozó(k) a „külvilág” fele meg ilyen(ek):

A gép dobozán – a rögzítő furatokat kivéve – semmit sem kellett „faragni”, a csatlakozók elférnek az „USER PORT” fölötti résben. A nyákra az élcsatlakozó még simán rá tud csúszni, emiatt a használhatóság sem csorbul. Abszolút meg vagyok elégedve a végeredménnyel! (Fejben ez a rész úgy nézett ki, hogy a dobozt itt szépen ki kell majd vágni... Ahhoz képest szinte semmit nem kellett igazítani.) Persze egy matrica pár felirattal ide is elfér (mint a drive esetében), de az már csak a kozmetikázás. Ami szintén fontos, de ráér... :) A csatlakozókból egy-egy érintkező ki van húzva, ha a párjában ezek helyét „bevakolom”, akkor rossz helyre nem is lehet csatlakoztatni. Ez azért fontos, mivel mindkét csatlakozó 20 pólusú, de egészen más a bekötésük. Ha lesz energiám, lehet hogy összeírom, hogy mivel lehet ilyenkor gond... (Táp nincs kint rajtuk, még az is lehet hogy semmivel.)

Eddig a gyakorlat. Most jöhet egy kis TCBM elmélet... :) A kommunikációval tüzetesebben még nem foglalkoztam. Eddig. De majd most! :) Ebben segítségemre lesz a plus/4 BASIC+KERNAL listája, meg az 1551 DOS. Ill. ez a rész elég „száraz”, ez inkább jegyzet magamnak.

Első körben egy kis érdekesség: a gép tudja használni a „régi” Commodore soros buszon levő perifériákat, ill. a TCBM buszos perifériákat is. De a TCBM interfész gyárilag nincs a gépbe építve, viszont a feladat adott: a ROM-nak el kell döntenie, hogy van-e paddle vagy nincs. A megoldás azért nem triviális, mert ha nincs interfész, akkor a neki fenntartott I/O területen a CPU a „semmit” olvassa/írja. Az adatbuszt ilyenkor szó szerint semmi sem hajtja, a CMOS logikából fakadóan a busz „előző állapota” ill. bármilyen „szemét” „van rajta”. Tehát „sima olvasással” nem eldönthető biztonságosan, hogy ott van-e az eszköz vagy nincs. A ROM ezt az ellenőrzést ($EDA9-en kezdődő rutin) úgy valósítja meg, hogy kiír $55-öt a TCBM adatregiszterébe, (A DATA alapból kimenetre van konfigurálva, tehát ha ott van a paddle akkor kimenet, ha nincs, akkor „semmi”.) majd visszaolvasva ellenőrzi, hogy az-e. Ha nem, akkor nincs interfész, a sima sorost kell használni. Ezután még ellenőrzi a STATUS B1-et is, hogy 0-e (alapból az, ez a paddle-n belül egy ellenállással magasra van húzva, ha a meghajtó nem megy, akkor 1), ha nem, akkor sem használható a TCBM. Nem túl bonyolult, de azért elég „nyögvenyelős” megoldás. Amikor valamilyen eszköz „felcímzését” végzi a KERNAL (listen vagy talk módra), akkor hajtódik ez végre. Szerencsére a végeredményt eltárolja, a későbbiekben már ennek a tárolt állapotnak megfelelően választ a Serial vagy a TCBM mód között.

Ha van TCBM interfész, akkor van jelentősége az összes többinek, ekkor az alapállapot a következő:

A TCBM DATA kimenetre van állítva (a gép oldaláról, a meghajtó oldalán bemenet és olvassa), és $00-val van feltöltve. A két STATUS vezetéket 0-án tartja a meghajtó (ez a gép oldaláról természetesen bemenet). A DAV és az ACK vonalak magasak, az ACK kimenet, a DAV bemenet.

A gépből a meghajtó fele az adatküldés a következő módon zajlik ($ECE6 körüli rutinok...):

Első lépésben a DATA vonalakra (ami alapállapotban $00, és kimenet) a gép kirak egy BYTE-ot. Ennek az a lényege, hogy $80..$FF között kell lennie. A DOS „levágja” a felső 4 bitet, majd a kapott érték alapján dönti el, hogy mi a ciklus folytatása, tehát mit kell tennie. Az érvényes kódok így $80..$8F tartományba esnek, de ebből is csak négy használatos ($81, $82, $83 ill. $84), a többi érvénytelen. (A TCBM ellenőrzésénél kiírt $55 7-es bitje 0, így az nem kelt itt semmilyen zavart.) A sima adatkivitel kódja a $83. (A $81 az eszköz fel- / lecímzése: listen, talk, unlisten, untalk. A $82 a másodlagos cím küldése. A $84 az adatfogadás a meghajtótól.)

Tehát kikerült a „módjelző” BYTE ($83) a DATA-ra. Amikor a drive ezt „észreveszi”, akkor kiválasztja a megfelelő üzemmódot a folytatáshoz. Ezután a meghajtó az ACK vezetékét, ami a gép oldaláról a DAV bemenet, alacsonyra húzza. (Alapból ez a vezeték magas.) Ezzel jelzi, hogy átvette a „módjelzőt”, jöhet a folytatás. Most a gép fogja a küldendő adatot (amit ténylegesen át akart adni a meghajtónak), majd kirakja a DATA-ra, majd a saját ACK-ját, ami a meghajtó DAV bemenetére van kötve, alacsonyra rakja, jelezve, hogy „ott az adat fiam”. Ezután a gép megvárja, míg a saját DAV-ja újra magas nem lesz. Ha ez megtörténik (jelezte a meghajtó hogy átvette az adatot), akkor a gép beolvassa és eltárolja a STATUS vezetékek állapotát (itt kiabálhat a meghajtó, ha valami „nyűgje” van), majd $00-át rak ki a DATA-ra (visszaáll az alapállapot), és a legvégén visszaállítja az ACK-ját magasra. Ezzel az utolsó lépéssel visszaáll a TCBM busz az alapállapotra. Fel- / lecímzésnél $81, másodlagos címnél meg $82 a bevezető kód, a többi ugyanez. És ez egy (!) BYTE átvitele. Minden egyes BYTE küldésénél az egész protokoll ismétlődik...

A meghajtóból az adat fogadása a gép oldaláról a következő ($EC96):

A DATA vonalakra kikerül a $84-es kód (adatot fogadna a gép). Amikor ezt a meghajtó észreveszi, akkor az ACK-ját (gép oldaláról DAV) alacsonyba húzza. Ha a gép „észreveszi” ezt az alacsony vonalat, akkor bemenetre állítja a DATA irányát, majd a saját ACK-ját (a meghajtó oldalán DAV) alacsonyra állítja. Ezt a meghajtó figyeli, ha alacsonyra került a vonal, kimenetre állítja a DATA vonalait (tehát MOST a drive hajtja kivételesen...), kirakja rá a gépnek szánt adatot, beállítja a két STATUS vezetéket, majd magasra állítja az ACK-ját (gép felől DAV). Amikor ezt a magas szintet a gép észreveszi, akkor beolvassa a STATUS-t illetve a DATA-t, majd magasra rakja az ACK-ját (a meghajtóban DAV). A mostani állapot „problémás”, mert a két vezérlőjel magas, ami olyan mint az alapállapot, DE a meghajtó hajtja a DATA vonalakat, nem pedig a gép. Ahhoz, hogy visszaálljon a „régi rend”, kell még egy „kézfogás”. Amikor a meghajtó érzékeli a saját DAV-jának (a gép ACK-ja) magas szintjét, akkor bemenetre állítja a DATA-t (vége a drive általi hajtásnak...), majd a saját ACK-ját újra alacsonyba húzza. Ha ezt a gép érzékeli, akkor kimenetre állítja a DATA-t majd $00-át ír bele (visszaáll alapállapotba az irány ill. az értéke), majd a saját ACK-ját alacsonyba rakja. Ekkor a meghajtó a saját ACK-ját magasra állítja, a STATUS vezetékeit meg vissza alacsonyra (ezek is alapállapotba kerülnek így), amit a gép megvár. Ha ez bekövetkezik, akkor a gép is magasra húzza a saját ACK-ját, ezzel befejeződik az átvitel. Az adatfogadás meglehetősen körülményesre sikerült, ez még az adatküldésnél is gázosabb... Ráadásul pont ennek az iránynak illene „gyorsnak” lennie, mivel az ember azért többet tölt mint ment. (Itt is igaz az mint küldésnél; ez a protokoll BYTE-onként ismétlődik.)

A kommunikáció azért szerencsére még így is gyorsabb mint az 1541 soros átvitele, de messze nem annyival, mint lehetne. Az biztosítva van, hogy nincs az adatiránnyal gond („nem hajt össze” a két eszköz a DATA vonalakon), de ehhez rendkívül sok kört szaladgál a kommunikáció során a gép is meg a meghajtó is. Ha ehhez a mókához lenne valami hardveres segítség, akkor teljesen rendben lenne, de így, hogy mindkét oldal bit-banging módon „küzd egymással”, már nem nevezném annyira csodálatosnak... :) Nem meglepő, hogy nem lett ebből C64-es TCBM interfész.

A kommunikációról egyelőre ennyit, elég volt az elméletből... Egyszerűbb lett vona, ha rajzolok valami folyamatábrát. Vagy legalább a jelalakokat lefestem a komm közben... (Apropó: mivel lehet ilyeneket kényelmesen csinálni? Linuxon, természetesen.)

A végére legyen egy kép a „konfigurációról” is:

Ezen látszik már a következő alany is, egy SFD-1001 meghajtó, „neki” készül az IEEE-488 interfész. Mivel ez önmagában megér egy bejegyzést, így a témának lesz még folytatása...

„Irodalom” (Ugyanaz mint az előző részben):

• Kapcsolási rajz – Drive
• Kapcsolási rajz – Paddle
• ...ill. itt is a komplett internet. :)

balagesz

---

2013.01.27.
2019.12.07. D8.