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

 ( balagesz | 2013. január 27., vasárnap - 22:51 )

Jelenleg két Linux rendszert használok, az egyik a CentOS, a másik meg a Fedora. (Legalább rokonok... :) ) Az első azért jó, mert „csak működik”, a második meg azért, mert lehet benne „homokozni”, egy csomó újdonság belekerül, amivel lehet kísérletezni. A Fedora (jelenleg) utolsó kiadása – ahogy nézem – kap hideget-meleget, még a legrosszabb kiadás címét is kiérdemelte egyesektől. 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 a 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):

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

balagesz

---

2013.01.27.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hat nekem nem lenne turelmem ehhez...

Jelalak kirajzolashoz gnuplot lehet jo, bar nyilvan sokat kell jatszadozni a parameterekkel, hogy ugy nezzen ki, ahogy kene.
---
Régóta vágyok én, az androidok mezonkincsére már!

Turelem... Van aki mondjuk modelleket epit. Nekem peldaul a horgaszat lenne tul stresszes. :)

Ido diagramm rajzolashoz DrawTime. Meg nem hasznaltam, mert amikor kellett volna, meg nem ismertem.

A minap pont ilyen cuccot kerestem. Kiváló.

Ez egesz erdekes, koszi! Eszembe nem jutott volna, hogy ezt a feladatot "szovegesen" is meg lehet oldani, ilyen "kattintgatos izere" gondoltam elso korben, de egy megvizsgalast mindenkeppen meger. (A szoveges leiras sokszor gyorsabb is mint az egereszes...)

A szoveges leiras nagy elonye, hogy az osszes szoveges tool mukodik a leirasra. Szovegfajlra egybol van diff, merge, verzio kovetes, 1000+ fele szkriptnyelv, csinalhatsz template -ket gyakran hasznalt dolgokra, masolhatsz dokumentumok kozott stb...
En kifejezetten szeretem ezeket az eszkozoket.

bookmarked

thumbs up, nagyon ügyes!

Bár szakmailag lila fingom nincs hozzá (mármint elektronikai működésileg), de csak azt mondom:
Még, még, még kérünk!
----
www.retrocomputer.tux.hu

Egy kicsit off:

Ket ev utan lett vegre sajat multimeterem, igy tudtam egy kozelebbi pillantast vetni a sajat kis 1541/II-es eszkozomre, es a legrosszabb almom valt valora: sajnos a tap az tokeletesen uzemel (ki tudtam merni rajta a 5/12 voltot) vagyis valahogy az eszkoz halta meg magat.

Ami azert is furcsa, mert bar majd' tiz eve nincs hasznalatban, mikor el lett csomagolva, elotte valo nap meg hasznaltuk, jatszottunk vele (pontosabban a hozza tartozo C64-gyel, de ez mindegy).

A jelenseg az, hogy power LED sincs. Vagyis a ki/be kapcsolo kattintgatasara semmi sem tortenik, meg egy pillanatra sem villan fel a power LED.

Van valami otleted, hogy mi szallhatott ennyire el benne? Por tud ilyet okozni? Bar dobozban van (az eredetiben!), es zart helyen van tarolva, azert biztos van benne kosz/por.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Szeretem az ilyen "tavgyogyaszatot"... :) Azt tudom leirni, en hogy allnek neki.

Por az ilyet nem csinal, de mondjuk a tapcsatlakozo oxidacio lehet gond. Ezt persze par ki/bedugassal orvosolni lehet, legalabbis annyira hogy kideruljon az, hogy errol van-e szo.

Ha nem kontakthiba, akkor az, hogy a POWER LED sem vilagit, az tulajdonkeppen jo jel is lehet. Ekkor lehet megis a tap a ludas (az a LED kozvetlenul a taprol jar, ha a komplett elektronika kuka, annak akkor is illene vilagitania), terheletlenul jo, de terhelve mar nem mukodik. Ha a tap jo, akkor ez lehet valamilyen alkatresz gond is (Tapkapcsolo kontakthiba? :) ), DE! A tapban az atereszto stabilizator ugy mukodik, ha tul nagy rajta a terheles, akkor aramgeneratort jatszik. Ha valami felvezeto zarlatos, akkor azon a maximalis aramat at fogja hajtani, ami ugy 1, 1.5A. Az meg mar melegszik ettol szepen. Ha ez van, "kezratetellel" megallapithato, hogy mi rossz. :) Ha szetszeded a meghajtot, vedd ki belole az alap elektronikat, es csak a tapot kosd ra. (A mechanikabol semmi se kell, csak a csupasz lap.) Ha igy se vilagit a POWER, de a tap tuti jo, akkor meg kell azt az alkatreszt keresni, ami melegszik. Ha szerencsed van, a DOS-t tartalmazo ROM lesz az, ami foglalatban van, vedd ki, majd kapcsold be ujra. Ha ekkor mar vilagit a LED, akkor az a hunyo. Ha nem, akkor keresgelni kell tovabb.

Annyit azert meg hozzafuznek, hogy a tapot hosszabb ideig azert "ne hajtsd" zarlatban, mert a hutese nem erre van tervezve. De 5-10 masodpercet lehet, annyi ido alatt meg mar erezni, ha valami melegszik.

Koszi, valamikor akkor szetkapom. Mennyire konnyen szerelheto amugy? Mert en elegge bena vagyok e teren, szoval en szet szetszedem a dolgokat, de ossze nem biztos, hogy sikerul... Nem surun csinalok ilyet, na.

A ki-be dugast kb. 3x elvegeztem, nem tudom, az eleg lehet az oxidacio kizarasahoz?

A tappal en nem gondolom, hogy gond lenne, stabil 5 illetve 12 voltokat mertem rajta, a GND-hez kepest, a pin kiosztasnak megfeleloen.

A tapkapcsolo az tobbe-kevesbe mechanikus, ugye? Tehat, ha lenyomom, akkor ugyanugy megszakad az aram, mintha kihuznam? Mert az lehet gyorsabb, mint mindig ki-be rangatni a kabelt - bar szepen kitisztitja a csatlakozot, azert nem biztos, hogy jo jatek az...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ez a tipus (tehat az 1541-II) viszonylag konnyen szerelheto, ettol ne felj. Ha hanyatt dontod, akkor latsz 4 db. csavart. Ha azokat kitekered, akkor talpra allitva lejon a teteje. Az elolap (ahonnan a lemezt lehet berakni) leszedesevel egy kicsit vigyazni kell, mert a POWER meg a DRIVE LED tarto nyakja ahhoz van csavarozva, viszont nincs csatlakozo. A leszedes ugy megy, hogy a lemez lezaro kallantyut le kell huzni a tengelyerol (a forgaspontot fogd meg (kezzel!), majd huzd abba az iranyba, amelyikbe a lemezt huznad ki; ezt leirni hosszabb volt mint megcsinalni). Ha ez megvan, akkor az elolapot egy kicsit megemelve le lehet billenteni / ki lehet forditani (tartja meg a LED-ekhez meno vezetekezes). A LED tarto nyak kozepen van egy csavar, azt kitekered es megszabadultal az elolaptol. Ezutan jon a mechanika, amit 4 csavar fog a helyere. (Felulrol latszanak, a doboz ket oldala meg a mechanika kozott vannak. Ezen a kepen jol latszik belole ketto, alul a mechanika meg a haz szele kozott "melyen" benn. Ezeknek a parjai a tuloldalon, ahol a LED-ek fele meno kabelek mennek.) Ezelott meg a 3 csatlakozot le kell huzni (egy a feje, egy a leptetomotore, ill. egy a lemezforgato/WPS jel csatlakozoja), ezek a "kulvilag fele nezo" csatlakozok ill. a mechanika kozott vannak, siman felfele kell oket lehuzni. Arra figyelj, hogy ezeket rosszul / forditva is vissza lehet dugni (nincs mechanikus pozicionalo rajuk), ha bizonytalannak erzed, lehuzas elott csinalj rola egy fotot! :) Ha a csatlakozok lenn vannak, a csavarok kitakarve, akkor a mechanikat felfele ki lehet emelni a dobozbol. Magat az elektronikat 3 csavar tartja, siman kitekerve oket ki lehet emelni a fem arnyekolobol.

A ki/bedugasbol 3 szerintem eleg, akkor nem ez lesz a gond. A tapot igazabol ugy tudnad kiprobalni, ha egy masik biztosan jo 1541-II-vel teszteled. :) A tapkapcsolo mechanikus, annak a kontaktjai is lehetnek esetleg oxidosak, esetleg erdemes lenne kimerni, hogy kapcsol-e normalisan. Ha zarlatot keresel, termeszetesen annak a kapcsolgatasa tokeletesen megfelelo.

Ha jol ertem, tehat azt mondod, hogy az elektronika van legalul. Azon tunodok, hogy en azt nem is vennem ki. Elvben ha kiveszem a mechanikat, akkor onnantol kezdve mas mar nem surun marad szegeny dobozban, tehat nem kuszkodnek vele feleslegesen. Nem is a kivetel az, ami necces, hanem a visszarakas.

Mindenesetre koszi a tippet, valamikor neki fogok allni megnezni. Sajnos nincs mas 1541-es meghajto a csaladban, igy nincs igazan tesztalany cuccom, hogy jo-e.

A tapkapcsolot megnezem, lehet ott van valami. Azon tunodtem kozben, hogy olyan nagyon nagy bajanak nem kellene lennie, mert nagyon keveset volt hasznalva, a csalad zomeben 10-20 blokkos programokkal volt el egesz nap (Galaga, Reversi, Billard), a legnagyobb jatek is olyan 100 blokk korul volt, egyszer beolvastuk, fel napig az ment. En programozgattam a C64-en, de ott is igazabol 3-4 blokkos BASIC cuccok mentek ki az eszkozre max.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igen, az elektronika van legalul. De odaig eljutni a nagyobb melo (mar amennyire, persze), azt kivenni mar szinte semmi. A "tapizashoz" persze a helyen maradhat.

A hasznalat tulzottan nem kene hogy megartson neki (attol inkabb mechanikai hibai lennenek), persze a bekapcsolt allapotban valo tulmelegedes elofordulhat. (De a '41/II-nek kulso tapja van, ez is inkabb a regi "kozepes meretu" dobozba szerelt meghajtoknal gond.) Viszont az is igaz, hogy a MOS/CSG IC-k nem a strapabirasukrol hiresek... :-|

[troll on]Szakmai cikk blogban!!![troll off]

Amúgy meg, még több ilyen!
Igazi hardware porn!!! Yeah! Még, még, még!

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Imádom az ilyen hardverbuzulást, bár túl sokat nem értek belőle. Nekem igazából a tudásom, de főleg a türelmem kevés.
Viszont itt a törzskocsmámban rám szokták bízni a döglött karácsonyfaégő-sort, a megtaposott LED-fejlámpát, hogy: ugyan má' meg tudnád javítani? Ilyenkor nem tudok ellenállni és elvállalom, mert szeretem az égett gyanta szagát és mert szeretem szétszedni a cuccokat, és rájönni a működés mikéntjére.

Egyébként pedig riszpekt!

(Tudsz ajánlani vmi folyasztószert lágyforrasztáshoz? Olcsó/házi kéne. Az alkoholban oldott fenyőgyanta nem igazán jó. A foszforsavas rozsdamaró (RO-55 és tsai) kiváló, viszont pár hónap alatt szarrá marja a környező alkatrészeket. Tuti gyári szerre meg nem futik pénzileg.)

Reszelő, csiszolópapír, jól beállított páka (nem pillanatpáka), tiszta heggyel, gyantás forrasztóón. Plusz megtanulni rendesen forrasztani.
Lehet mindenféle csoda folyasztószerekkel küzdeni, de az esetek 90%-ban nem ez a hiba oka. Amin nem segít a gyári folyasztószer, ott nem az anyagban van a hiba. A fenyőgyanta sem mindegy, hogy milyen. Víz és szennyeződésmentesnek kell lennie.
Bármelyik elektronikai webboltban kapható no-clean flux, forrasztógyanta vagy savmentes forrasztózsír. 1000-3000 ft között van, évekig elég. Egyszerűen nem éri meg vegyészkedni otthon ennyiért.

http://www.argep.hu/trend/FOLY/Folyasztoszer.html
A legolcsóbb 297Ft. Ennél olcsóbban házilag nem hozod ki.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ez igy kb. +1.

En nem hasznalok (sokat, surun...) plusz folyasztoszert, a hasznalhato forrasztoonban van megfelelo mennyisegu, annyi eleg szokott lenni. Ha megis valami "finom" dolgot kell forrasztani (0.5mm-es labtavolsagu TQFP, pl... :) ) akkor szoktam hasznalni egy "vastag filctoll" kinezetu un. "Flux Pen"-t, (Gyartoja valtozo, sok nem kell belole, igy ritkan kell venni, cserebe viszonylag draga.) de vezetekek forrasztasanal eszembe nem jutna elovenni. :) Ami kell, az egy jo paka megfelelo heggyel! Nalam ez raadasul hatvanyozottan igaz, mert amiota kotelezo (2006 jul. 1, ha jol remlik), azota olommentes forrasztoonnal forrasztok csak. (Pl. ezen a kepen latszik is, a forrasztasok nem olyan szep csillogoak mint szoktak, egy kicsit matt a feluletuk.)

Szoval az olom teszi csillogova? Ezt nem is tudtam... Mindig tanul az ember valamit... :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Lehet hogy az olommentes is csillogna, csak nem olyan szep sima a felulete. Egeszen mashogy dermed meg forrasztas utan, mint az olmos. Annyira nem is vagyok oda erte, dehat a szabaly az szabaly... (Amit lehet hogy csak en tartok be. :) A multkor kellett vennem forrasztoont; egy forrasztastechnikai szakuzletben (!) nem tudtak adni olommentest, mivel senki se keresi, nem tartanak raktaron. :) )

Itt is kösz.

(Jó régen, 10 éve kb. vettem az ménkű nagy Budapestbe', a Konrádba' egy kartonpapírra tekert forrasztóónt, Stannol márkájába, Sn 60, Pb 38, Cu 2. Mindössze 3 méter drót. Akkor azt hittem, hogy ez rohadt drága 500 Ft-ért, de még mindig van belőle és amikor finomabb cuccot kell javítani, érezhetően kezesebben viselkedik, mint a jó öreg cucilista, fene-tudja-honnan származó 30 éves forraszanyag.)

Az a 30 eves "fene-tudja-honnan szarmazo" forrasztoon egyaltalan folyasztoszeres? Mert lehet am kapni anelkulit is, de azt elektronikai forrasztasoknal messzi ivben kell elkerulni. :)

Ja, a közepe gyantás. De valahogy nem úgy terül, nem olyan jó, mint az a decens nyugati Konrádos ;)

Kösz az infót.

Nem sokat értek hozzá, főleg az elektronikai részéhez, de jó ilyet látni... Grat! :)
--
The Community ENTerprise Operating System

Üdvözletem!

Ha jól értelmeztem a a leírást, akkor te a TCBM interfész CN3 csatlakozója és a "drive shema" P1 csatlakozója közti kommunikációt írtad le. Ezt tudtam értelmezni folyamatábra nélkül is, és köszönet a részletes leírásért is. A Plus/4-es romlista c.könyvemben én is visszakövetem majd a folyamatokat.
De mi van ha egy külön meghajtót szeretnék fejleszteni (ami elméletben nagyon megy, csak a prog. háttér hiányzik, habár lelkes forgatója vagyok a Plus/4 gépi programozási könyveknek) és nincs TCBM padle a közelben. Akkor miként módosul a kommunikáció?

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.

Tehát ha a fenti műveletet leszimulálom neki, mint ahogy te is tetted akkor kapok egy "virtuális paddle-t"? Vagy ahogy a fentiekben írtad és csináltad, a teljes hardvert le kell programozni?

Ha jól értelmeztem a a leírást, akkor te a TCBM interfész CN3 csatlakozója és a "drive shema" P1 csatlakozója közti kommunikációt írtad le.

Pontosan.

De mi van ha egy külön meghajtót szeretnék fejleszteni (ami elméletben nagyon megy, csak a prog. háttér hiányzik, habár lelkes forgatója vagyok a Plus/4 gépi programozási könyveknek) és nincs TCBM padle a közelben. Akkor miként módosul a kommunikáció?

Ezt a kerdest viszont nem ertem. A ROM a megfelelo I/O helyen keresi a paddle regisztereit, ha azt nem talalja ott, akkor a soros porti kommunikaciot kezdi meg. (Annak a hardvere a gepbe van epitve gyarilag.)

Tehát ha a fenti műveletet leszimulálom neki, mint ahogy te is tetted akkor kapok egy "virtuális paddle-t"? Vagy ahogy a fentiekben írtad és csináltad, a teljes hardvert le kell programozni?

Hogyan "szimulalsz"? Az eredeti gepben levo processzoron nincs semmi kivetelkezeles vagy ahhoz hasonlo valami, a portra irasokat / portrol olvasasokat nem tudod "elkapni", es kihelyettesiteni. Vagy modositod a ROM-ot, akkor tulajdonkeppen barmilyen feluletet lehet TCBM-nek lattatni (persze csak addig, ameddig a KERNAL-os rutinokat hivogatja a program), vagy - ahogy en csinaltam - implementalni kell a paddle regisztereit. Az elso az SW (addig ameddig EPROM-ot/FLASH-t nem kell egetni, de ahhoz is kell HW, amit a paddle-nek hasznalsz a sajat "meghajtodhoz"), a masodik termeszetesen teljesen HW.