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

Több alkalommal írtam már retró mikrogépes témában, de eddig az adatmozgatás valahogy kimaradt. Ez elsőre rendkívül triviálisnak tűnik, de van egy rakás „kellemetlen” körülmény, ami – fogalmazzunk úgy – nem segíti megoldani a feladatot. Mivel manapság már minden is megtalálható az interneten, tartalmat beszerezni nem kaland. Viszont ha az ember nem csak emulátorban akarja „élvezni” a letöltött BYTE-halmazt, valahogy bele kellene juttatni a kiválasztott masina memóriájába. Ugyanez igaz egy esetleges fejlesztésnél is, amit rendes, valódi gépen is ki akarna próbálni.

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? :)

Irodalom:

balagesz

---

2020.04.16.
2020.04.17. „maghajtó”→„meghajtó”

Hozzászólások

Szép munka, gratula! Jó ilyesmit olvasni néha, az ember közben elnosztalgiázik a „régi szép időkön”...

Volt a C-64 -ben rengeteg jó lehetőség, a Commodore ott szúrta el hogy a következő gépe lényegében nem lett kompatibilis vele. (Az Amiga-ra gondolok).

Pedig gondolj bele, emlékszem, a C-64 RAM-jában a $0002 bájt "Not used" volt. Semmire se használta... Ha ezt beállította volna lapozásra, lehetett volna így megcímezni 256*64K memóriát... Ezt simán megléphette volna a Commodore cég a következő verzióban. És teljesen kompatibilis maradhatott volna a régi gépekkel, felülről...

A C-64 gépi kódjában is volt egy rakat kód ami hivatalosan semmire se használt a masina. Oké, VALAMIT azokra is művelt, de a legtöbb esetben teljesen felesleges dolgokat. Hivatalosan ezek nem voltak használva semmire. Ide feltölthetett volna szuperjó utasításokat. Szóval volt a gépben még potencia rendesen, de a cég elhanyagolta.

Obsessed commandline-maniac.

Az Amigát külön banda fejlesztette, csak a C megvásárolta a bandát. Az Amiga fényévekkel jobb és másabb volt rendes multitaskos, GUI-s OS-sel. C64 utódnak meg ott volt a C128. Ha a töketlen marketinges banda nem szúrja el, és tartották volna fejlesztésekkel a technikai előnyt, Mac mellett még lehetne hivatalos, nem kisipari Amiga is a már hanyatló PC piacon. De a hivatalos életút végén a PC izomból tudta azt, amit az Amigák már 8-10 éve.

Volt lapozás a C64-ben, hiszen volt benne 64k RAM, meg 20k ROM, meg 4k IO; ezek egyszerre nem férnek el 64k-nyi címterületen.
Amúgy egyszerre lapozni mind a 64k-t nem lehet, hiszen akkor az éppen futó programodat is kinyírod lapozáskor. Lapozni kisebb szeleteket szoktak. Egyébként volt RAM bővítő C64-hez, többféle is, a legnagyobb 16 MB-os volt, utóbbira még demot is írtak.

Ezt én mind tudom, programoztam azt a gépet is assemblyben... De simán meg lehetett volna csinálni, hogy mondjuk egy 8K szelet kivételével a többit lapozza mind.

Annak idején megcsináltam, hogy írtam egy Basic bővítést hozzá, úgy hogy az használta a BASIC ROM és a KERNAL ROM alatti RAM területeket, s ezt úgy oldotta meg hogy amikor olyan utasítást kellett volna végrehajtania amiről tudta (egy táblázat alapján) hogy ebben az „árnyék RAM”-ban van, akkor onnan felmásolta a kódot a $C800-$CFFF területre (ez 2 kilobájt ugye) és végrehajtotta. Persze figyelte azt is ha a kód már épp fel lett másolva oda korábban, akkor nem másolja újra feleslegesen... Maga az ezt végző rutin a $C000-$C7ff területen volt, elég volt neki bőven az a 2 K.

Remekül működött... Mint látod ehhez még csak el se vettem semmi területet a Felhasználónak elérhető RAM területből!

Szval ilyesmit simán lehetett volna nagyban is megjátszani. Voltak potenciák a C-64 -ben bőven, csak hagyták az egész architektúrát „lepusztulni”, elavulni.

Obsessed commandline-maniac.

Konkrétan a $02-re címzett lapozóra reagáltam, amiről azt mondtad, hogy 256*64k-t lehetett volna megcímezni vele. Ami igaz, csak az úgy épp nem működött volna. Bár egyébként kissé sántít, a többi lapozó jelenléte miatt. Ha belegondolsz, hogy a BASIC/KERNAL/IO részek magukban is lapozhatóak voltak, azok rögtön lejönnek a címtartományból, hiszen azok a lapozók mindenképpen a saját tárterületeiket cserélgetik, tehát valójában csak 256x44k-t lehetett volna így címezni. A több kisebb lappal egyébként rugalmasabb memóriakezelést lehet megcsinálni; valahol lefoglalhattak volna 8 byte-ot és akkor az Upper RAM 4k-s címterületét felosztják vele 16 db 256 byte-os szegmensre és a 8 byte nibbljei döntik el, hogy a 16 db Upper RAM közül az adott szegmensben melyik megfelelő szegmens látszik. Ez újabb 60 kB RAM terület lett volna.

A C64-ben valóban volt még potenciál, a mai napig van (ld. mit hoznak ki belőle a scenerek), de mint felhasználói gép a 90-es évek elejére - amikor már voltak 32-bites gépek is - tényleg elavult.

Jó, hát nézd, igyekeztem röviden fogalmazni mert tudod hogy állandóan belekötnek abba hogy bőbeszédűen írok... Szóval nem tértem ki minden részletre. Sokféleképp meg lehetett volna oldani. Például mit szólsz egy olyan megoldáshoz, hogy a következő generációs C-64 -et (nevezzük mondjuk C-2020 -nak, hehehe...) úgy csinálták volna meg, hogy a $02 bájt foglalt speciális célra, de egyébként minden ugyanolyan mint a régiben, csak beleraknak néhány plusz utasítást! (A nem használt kódok helyére). Ilyeneket például:

SLDA $akármi,y

Az SLDA a ShadowLDA rövidítése. És úgy működne, hogy a $02 által mutatott sorszámú 64K méretű lapból tölti be az adatot a $akármi címről, az y regiszterrel indexelve...

Lehetne ennek mintájára SSTA utasítás is.

Meg olyan hogy

SLDA ($FB),y

Ezt nem magyarázom, tuti érted már hogyan működne.

Szóval ezt a lapozásos izémizét elintézné maga a fejlettebb processzor a gépben. Ezen utasítások függetlenek lennének attól, épp mi van betöltve a $00 és főleg a $01 memóriacímekre. Szóval a „lapozás” ebben az esetben csak addig működne amíg behozza vagy kiírja onnan az adatot.

Oké, így maga a programkód nem lehetne ezeken az extra tárterületeken, de még így is megérné, mert akkor ezeken az extra adatterületeken levő adatokat lehetne használni programként úgy, hogy azt egy interpreter hajtja végre... Szóval, a Basic programok attól még lehetnének ott, a basicet úgyis interpreter hajtja végre...

És ez csak egy hirtelen ötlet tőlem, biztos lehetne még ennél sokkal jobb dolgokat is kitalálni.

Obsessed commandline-maniac.

> És úgy működne, hogy a $02 által mutatott sorszámú 64K méretű lapból tölti be az adatot a $akármi címről, az y regiszterrel indexelve...

Ez leginkább sehogy sem működne, hiszen te itt egy elemi CPU utasítástól azt várod, hogy férjen hozzá egy olyan laphoz, ami be sincs lapozva, az utasítás pedig ezt nem tudhatja. Ha a $02 a lapozóregiszter a memóriában, akkor meg egyébként is teljesen mindegy, hogy a CPU mit olvas be onnan, mert úgyis arról a lapról fog olvasni, ami épp be van lapozva a $02 által. Ha meg csak egy indikátor a CPU-nak, akkor meg az utasításnak ki kell írnia arra a címre, amit talált rajta, ahol a lapozóregiszter van. Azaz normál 6502-esül

LDA $02
STA paging_register
LDA $akármi, y

Namármost, ez utóbbit ugyan még lehetne kivitelezni, viszont az utasításfeldolgozást megbonyolítaná; a 6502-es feldolgozórendszerének elemi lépéseivel ez még 4 lépés lenne a valódi utasítás előtt, ráadásul olyan lépés nincs is, hogy fix címet tegyünk a címbuszra, tehát akkor az már plusz egy belső utasítás lenne. Ennél sokkal egyszerűbb beírni a fenti plusz két utasítást.
De ettől függetlenül is, itt a memóriamenedzsmentet akarjuk megcsináltatni a CPU-val utasításszinten, ami nem igazán működhet, hiszen az utasítások számára a memórialapozás nem létezik és nem létezhet. Az egy dolog, hogy van olyan, hogy MMU és vannak CPU-k felszerelve vele, de az egy külön egység és az utasítások számára transzparens módon működik, mert ha nem így lenne, akkor az utasítások megkerülhetnék az MMU-t. Az egésznek az a lényege, hogy a CPU utasításai "azt hiszik", hogy ide vagy oda vannak becímezve és nem tudják, hogy fizikailag melyik lapon vannak.

Ebből a szempontból a C64 utódja, a C128 pontosan arrafelé fejlődött, amerre lehetett, abban van external MMU, plusz memória, két CPU, két videochip és a többi. A C128 egyike a legtáposabb 8-bites gépeknek, csak mivel volt benne C64 kompatibilis üzemmód is, ami kb. 95+%-os kompatibilitást adott, így nem nagyon foglalkozott senki a gép saját lehetőségeivel.

Ugyan már, azt ne mondd nekem hogy amit írtam, nem lehet megcsinálni ha nagyon meg akarnák csinálni...

Eleve, miért abból indulsz ki, hogy ezt a létező 6502-essel kéne megoldani?! Én egy FEJLETTEBB csipről beszéltem, ami azonban felülről kompatibilis a C-64 -ben levő cókmókokkal, legalábbis 99% erejéig!

De tessék, itt van egy másik megoldási lehetőség. Az új gép, a C-2020 egyáltalán nem lapoz. Van benne azonban

$FFFFFF bájt memória (illetve eggyel több mert a nulladik is).

A régi utasítások azonban, minthogy 16 bitesek, e sok memóriának csak az első 64K szegmensét érik el (meg amik ezek fölé vannak mappelve, ROM, I/O terület, karakter ROM stb). Az új utasításopk azonban amikről korábban beszéltem, az SLDA stb, azok azonban úgy működnek, hogy figyelembe veszik a $02 tartalmát is. Azaz tegyük fel a $02 tartalma $AE. Ekkor mondjuk az

LDA $C020

az mindig a $00C020 címről tölt be adatot, akármi is a $02 tartalma. Ellenben az

SLDA $C020

utasítás ekkor már igazából a $AEC020 címről töltene, mert ő figyelembe veszi a $02 tartalmát is a címzésben...

Nem látom be, ezt miért volna olyan borzasztó megcsinálni! Oké, talán nem az eredeti 6502 chippel, de egy olyat szerintem nem volna ördöngösség csinálni, ami ezzel a lehetőséggel kibővített. Ez fényévekkel egyszerűbb, mint ami manapság van a mai PC gépekben. Ez még csak nem is védett üzemmód. Hallottam, állítólag van FPGA alapokon összedobott C-64, bár nem tudom mennyire élő vagy halott a project, elkészült-e teljesen... de szerintem megoldható, és azt simán ki lehetne bővíteni ezzel is.

Oké, nem nekem, én nem vagyok annyira penge az ilyesmiben. De annak aki amúgy szokott ilyesmivel foglalkozni rendszeresen, még ha csak hobbyból is.

Szoftveresen emulálni meg még én is képes lennék. Gondoltam is rá egy időben, de aztán mégis inkább a saját programnyelvembe kezdtem bele.

Obsessed commandline-maniac.

Egy fejlettebb 6502-re gondoltál, viszont azt mi másra alapozva csinálnák meg, mint a 6502-re magára?

Egyébként ha már 16 MB-ig bővítünk, ennél van jobb megoldás is, mert ez, amit leírtál, ez egy meglehetősen konvulensen implementált, belülről drótozott, külső lapozást feltételez, míg a 65816-ban van két 8-bites offset kiterjesztés regiszter, amivel simán lehet 16 MB-ig címezni; ezt nem csak programozni egyszerűbb (lévén külön program és adatbank regiszter is van), de a CPU-ban megvalósítani is az volt. És ez is 6502-kompatibilis (bár nem 100%-ig) és volt C64-be is.

Amit leírtál, ha a PC-s megoldásokhoz mérjük, akkor nyilván nem ördöngősség, de itt most nem a mai x86-osokhoz viszonyítottunk, hanem az akkori 6502 related technológiákhoz és azoknak a limitált felépítéséhez. Egy FPGA alapú emulátort persze, hogy ki lehetne bővíteni, csak akkor minek, ha már így is van 16-bites 6502-es? Én most a 80-as évek fejével próbáltam gondolkodni.

Én viszont írtam 6502 (ill. 1541) emut (épp balagesz volt benne a tettestársam) és ez cikluspontos emuláció, tehát nem úgy megy, hogy megcsinál mindent, majd vár valamennyit, hanem ténylegesen a 6502-es elemi lépéseire van szétbontva a dolog belül. Úgyhogy hidd el, tudom, hogy mit beszélek, amikor azt mondom, hogy így nehezebb lett volna bővíteni a 6502-őt, mint ahogy végül bővítették. A WDC mérnökei sem azt az utat választották a 6502-es kiterjesztésekor, amit te leírtál, hanem azt, amit egyszerűbben meg lehetett csinálni és flexibilisebb is volt.

Ügyes!

Kiegészítésképpen ha régi hardvereket akarsz meghajtani vagy pl. C64-hez emulálni, akkor az SBC-k GPIO-ja méginkább barátod lehet.
IEC emuláció (eszköz és host emuláció): https://github.com/Flogistoni/raspbiec

REU-t elvinne a MiST is simán (SDRAM-ban lenne rá hely, FPGA-n se hiszem, hogy sokat foglal). A 4 SID viszont elviszi a felét :) Amúgy 25k LC van a MiST-ben (EP3C25). De mondjuk ez a Xilnix számaival nem állítható párba.

Melyik lenne ez a konkurens? A Replay2? Mert az sose lesz kész.

Jó, ez egy FPGA, de ebből kéne is valami terméket csinálni, aztán portolni rá azt a rengeteg coret, ami a MiST-en már működik. Ezen egyébként már nem csak C64-et, de valószínű PS1 szintű hardwaret is létre lehetne hozni (mint a MiST-en sem a C64 a határ, hanem Genesis, SNES, 68020-as Amiga, pedig ha azt nézzük, már jó öreg, 7-8 éve készült az első).

Ja, most nézem, ez a Vitrex+ nem kifejezetten consumer termék, 7-8000$ egy devkit :) Inkább a Zynq Ultrascale+, ami szóba jöhetne. De az az igazság, hogy mióta a DE10-nano 130$-ért kapható (és csak az FPGA rajta 230$ lenne, ha külön veszed), azóta most ez a sláger a retro FPGA felhasználói körben.

Nem consumer persze. Csak a kérdésedre írtam, hogy melyik az. Ez a DE10 nano tényleg jó. Nem mindegy mi a cél. Rertro hardverhez mindenképpen az Altera a nyerő. Jobb áraik vannak és tovább támogatják a termékeiket, sokkal tovább mint a Xilinx. 

Xilinx inkább a professzionális felhasználást célozza. Elég undorító szokásuk, hogy pár éves termékeik támogatását is képesek nyugdíjazni, vedd a következőt. Viszont elég jók a fejlesztésed védelmében. MicroSd kártya ebből a szempontból nem jó, hobbira viszont pont megfelelő. 

Nekem Basys3 van. Eddig fpga programozás tanulására kellett, üzleti célra még nem volt ilyen projektem.

Ide írom az egész szálra a választ: Jók ezek az új cuccok, de... :) Az olyannal semmi kifogásom, amikor az eredeti cucc bővül valamivel, amit mai modern alkatrészekből raknak össze. (Van akinek már ez is cinkes: az úgy „nem elég autentikus!”) Meg azzal sincs bajom, ha valami nem beszerezhető alkatrészt váltanak ki modern helyettesítőkkel. De hogy a komplett gépet..? :) Ezek a cuccok olyan tudásúak, hogy a régi gépnél sokkal jobbat is lehetne csinálni. :) Na de erről is lehetne beszélni sokat.

Szépen összeraktad. :)
Valahogy nem lep meg, hogy gyorsabban megy a lemezírás, mint Amiga alól IEC-kel... (Az Amigás lemezeket egyébként tényleg nem lehet olvasni PC-n, de az Amiga viszont bármilyen floppyt tud kezelni (PC, Mac, Atari, stb.), ha van hozzá szoftvered, pl. a FAT12-höz a CrossDOS.)

Az 1541 címterébe amúgy nem lehetne valahogy bekapuzni azt a +3x2kB RAM-ot? Utána csak a szoftvereket kell átírni, hogy detektálni és használni tudják.

BTW, a "maghajtó" szóvicc volt, vagy typo? :)

Az Amigás lemezeket egyébként tényleg nem lehet olvasni PC-n

Valaki mintha mesélte volna, hogy látott már ilyet... Valahogy úgy ment, hogy két floppy-drive-ot kellett a pécére kötni, az egyikbe egy pécés formázású lemezt ment, a másikba meg az AMIGÁs. Az olvasó program azt csinálta, hogy kiválasztotta a pc-s lemezű meghajtót, majd beolvastatott vele egy szektorfejlécet. Amikor az megvolt, akkor átváltott az AMIGÁs lemezre. Erről a meghajtóváltásról a floppy-vezérlő mint sem sejtett, az csak olvasta az adatokat... Utána a nyers adathalmazból már valahogy vissza lehetett állítani az AMIGÁs lemez tartalmát. Persze ezzel az olvasás mehet, írni így is esélytelen. :)

Az 1541 címterébe amúgy nem lehetne valahogy bekapuzni azt a +3x2kB RAM-ot?

Az eredeti SRAM helyett mondjuk 8K-t berakni nem lenne nagy feladat. De a szoftveres részhez valahogy „nem fűlik a fogam”. :) Kérdéses, hogy mondjuk az XU/XUM1541 kódjához hozzá kellene-e nyúlni? Mert abban sejtek érdekességeket. (Van benne pl. egy rakás avr-gcc peccs. Ezek mik? :) Bekerültek azóta az upstream-be, vagy csak ehhez kellenek, vagy..?)

"maghajtó"

A helyesírás-ellenőrző szerint van ilyen szó. :) (Természetesen elírás, javítom.)

Valaki mintha mesélte volna, hogy látott már ilyet... Valahogy úgy ment, hogy két floppy-drive-ot kellett a pécére kötni, az egyikbe egy pécés formázású lemezt ment, a másikba meg az AMIGÁs. Az olvasó program azt csinálta, hogy kiválasztotta a pc-s lemezű meghajtót, majd beolvastatott vele egy szektorfejlécet. Amikor az megvolt, akkor átváltott az AMIGÁs lemezre. Erről a meghajtóváltásról a floppy-vezérlő mint sem sejtett, az csak olvasta az adatokat... Utána a nyers adathalmazból már valahogy vissza lehetett állítani az AMIGÁs lemez tartalmát. Persze ezzel az olvasás mehet, írni így is esélytelen. :)

Ez valahogy nem áll össze... Az Amiga a floppy-t a legalacsonyabb szinten kezelte, bármilyen sűrűséggel tudta írni és olvasni, ezért lehet bármilyen formátumot használni rajta, viszont tudtommal a PC-k csak a szabvány sűrűséggel dolgoztak. Nem magáról a meghajtóról van szó, hanem ahogy a PC-k kezelték a meghajtót. Vagy meg lehet valahogy kerülni a dolgot?

Az eredeti SRAM helyett mondjuk 8K-t berakni nem lenne nagy feladat. De a szoftveres részhez valahogy „nem fűlik a fogam”. :) Kérdéses, hogy mondjuk az XU/XUM1541 kódjához hozzá kellene-e nyúlni?

Az attól függ, hogy mit értesz ez alatt: a PC felőli részt passzolom, de az 1541-es felőli részt biztos, ha azt szeretné az ember, hogy ki legyen használva az extra RAM és - ahogy írtad - egyszerre legyen a sáv a memóriában, hogy egy fordulat alatt ki lehessen írni. De hogy pontosan hol kell ehhez módosítani a XU/XUM1541 "ökoszisztémán", azt megint passzolom. :)

(Van benne pl. egy rakás avr-gcc peccs. Ezek mik? :) Bekerültek azóta az upstream-be, vagy csak ehhez kellenek, vagy..?)

Hát ezt meg végképp nem tudom. :)

Ez valahogy nem áll össze... Az Amiga a floppy-t a legalacsonyabb szinten kezelte, bármilyen sűrűséggel tudta írni és olvasni, ezért lehet bármilyen formátumot használni rajta

Kissé régiek már ezek az emlékek... De – érdekes módon – most barátom volt a kereső: ezt a linket az elsők között találtam. Itt pontosabban leírják, mi is volt ez.

Az AMIGA floppy-vezérlője tényleg elég rugalmas, de a „bármilyen sűrűség” azért költői túlzásnak tűnik. Én még nem találkoztam olyan programmal, amivel például egy sima 5¼-es szabvány meghajtóval 1541-es lemezt lehetne olvasni. (Szerintem nem véletlenül emlegetted te se fentebb az IEC-et. :) ) A vezérlő az ugyan tud GCR-es lemezt olvasni, de ha jók az emlékeim, csak a „szokásos” 250000bps-es sebességet támogatja. (Így pl. értelmetlen is; az 1541-nek ez a leglassabb bitsebessége.) MFM-ben meg ez a DD-s lemeznek felel meg, HD-s lemezt az A4000 is egy ronda trükkel tud olvasni / írni. (A meghajtó ott fele sebességen pörgeti a lemezt. :) )

Az attól függ, hogy mit értesz ez alatt:

Pont a köztes részt: hogy az XU1541 / XUM1541 interfészen található mikrovezérlő programját kell-e ehhez módosítani. A pc és a '41 oldala mindenképpen módosítandó lenne, az nem is kérdés.

Kissé régiek már ezek az emlékek... De – érdekes módon – most barátom volt a kereső: ezt a linket az elsők között találtam. Itt pontosabban leírják, mi is volt ez.

Nocsak, ezt jó tudni! Bár ahogy nézem, óvatosan kell ezzel bánni, mert csak 98%-os a dolog, a maradék 2% adatvesztésbe torkollik.

Az AMIGA floppy-vezérlője tényleg elég rugalmas, de a „bármilyen sűrűség” azért költői túlzásnak tűnik.

Jó, nyilván nem azt jelenti, hogy húsz gigát is fel tud rá írni. :P Úgy értettem, hogy bármilyen fizikailag lehetséges sűrűség. Kezelni tudja a 720k-s FAT12-es lemezeket, az 1581-es 800k-s lemezeit, a Mac 800k-s lemezeit, stb, a felső határ kb. valahol 1200k körül van. Valamint ugyanezeknek a felét, egyoldalú DD lemez esetén és a dupláját HD lemez esetén, ill. ha tudod illeszteni, a négyszeresét ED-s lemez esetén.

Én még nem találkoztam olyan programmal, amivel például egy sima 5¼-es szabvány meghajtóval 1541-es lemezt lehetne olvasni. (Szerintem nem véletlenül emlegetted te se fentebb az IEC-et. :) ) A vezérlő az ugyan tud GCR-es lemezt olvasni, de ha jók az emlékeim, csak a „szokásos” 250000bps-es sebességet támogatja.

Mivel nincs is ilyen program, azért IEC. :) Ha a lemezmeghajtó maga fizikailag képes hozzáférni úgy a lemezhez, ahogy az 1541-es, akkor ha van programod, akkor menni fog. Ez a sebességre is vonatkozik. Ha túl lassú, akkor sajnos nem fog működni a dolog.

MFM-ben meg ez a DD-s lemeznek felel meg, HD-s lemezt az A4000 is egy ronda trükkel tud olvasni / írni. (A meghajtó ott fele sebességen pörgeti a lemezt. :) )

Ez speciel nem volt meg, mert sosem volt HD-s meghajtóm Amiga alá, 4000-esem meg pláne nem. :(

Pont a köztes részt: hogy az XU1541 / XUM1541 interfészen található mikrovezérlő programját kell-e ehhez módosítani. A pc és a '41 oldala mindenképpen módosítandó lenne, az nem is kérdés.

Hát, ha az csak a kommunikációért felel, akkor szerintem nem, mert az nem változik, hogy hogyan kommunikál, csak azt, hogy mit. De ezt most csak úgy hasból írtam, ne vedd készpénznek.

MFM-ben meg ez a DD-s lemeznek felel meg, HD-s lemezt az A4000 is egy ronda trükkel tud olvasni / írni. (A meghajtó ott fele sebességen pörgeti a lemezt. :) )

Ez speciel nem volt meg, mert sosem volt HD-s meghajtóm Amiga alá, 4000-esem meg pláne nem. :(

 

Atariék  inkább16MHz-en járatták a WD FDC-t a HD-s lemezhez

Ez gondolom a Falcon volt, nem az ST. Az nagyon ütős gép volt, látszott, hogy az Atari még ki akar valamit hozni a dologból, az AGA-s Amigákat a C= meg direkt csúsztatta 3 évig, hátha elavulnak addigra, mire megjelennek és még ezen felül is felemás munkát végzett, egy csomó dolgon nem változtattak, úgy maradt bennük, ahogy '85-ben az A1000-esben.

a maradék 2% adatvesztésbe torkollik.

Mondjuk azt a hozzászólást nem teljesen értem. (Mintha másról is szólna, nem erről a dupla-meghajtós trükkről.) Ez csak olvassa a lemezt, írni nem kell sosem. (Illetve ha áthúzod írásvédetté a 3½-es floppy-t, akkor arra a vezérlő nem fog tudni írni, ha megfeszül, akkor se. :) )

Kezelni tudja a 720k-s FAT12-es lemezeket, az 1581-es 800k-s lemezeit, a Mac 800k-s lemezeit, stb, a felső határ kb. valahol 1200k körül van. Valamint ugyanezeknek a felét, egyoldalú DD lemez esetén és a dupláját HD lemez esetén, ill. ha tudod illeszteni, a négyszeresét ED-s lemez esetén.

Az előbb segített a kereső, most itt nincs nagy szerencsém. Egy regisztert találtam, ami releváns lehet, az pedig ez. Illetve egy másik leírás ugyanerről, de tovább ködösíti az amúgy se tiszta képet. :) A sebesség állítása összesen 1 bit! Abból meg túl sok variáció nem hozható ki. Ködös, mert 4 illetve 2 µSec-ről beszél. Ezek a 250000 illetve 500000 bps-nek felelnek meg. De! Az 500Kbps az a HD-s lemez bitsűrűsége lenne, viszont az olyan lemezt nem tudja kezelni a hardver alapból. (Csak a fent említett fél-sebességű trükkel, ott a bitsebesség is visszaesik 250Kbps-re.) Szóval a 250Kbps-es GCR és MFM lemezek azok rendben vannak, de a többi sebesség..? Az az 1200K-s lemezméret úgy talán összejöhet, hogy még több szektort raknak egy sávra (kisebb gap-ek, esetleg nagyobb szektorméret, hogy kevesebb legyen a másra használt hely), illetve több sávot használnak, mint a hivatalos 80. (A gyári AMIGA floppy-k is jó eséllyel tudnak 82-t, de vannak olyanok, amik még ennél is jóval többet (!) tudnak. (Akár 90? :) ))

Mivel nincs is ilyen program, azért IEC. :) Ha a lemezmeghajtó maga fizikailag képes hozzáférni úgy a lemezhez, ahogy az 1541-es, akkor ha van programod, akkor menni fog.

Nincs ilyen program, mert valószínűleg nem is lehet ilyet csinálni. :) A sima DD-s 5¼-es floppy-meghajtó tudhatja olvasni az 1541 lemezeit (valószínűleg nem mindegyik, de egy részük biztosan), csak a megfelelő bitsebesség nem állítható be az AMIGA oldalán. (Ha lehetne, tuti megcsinálták volna már régen...) De várom Charlie-t, hogy jön és „szétcsap köztünk”, hogy hülyeséget beszélünk. :)

Hát, ha az csak a kommunikációért felel, akkor szerintem nem

Gyanítom én is, hogy az a rész a lehető legrugalmasabbra van csinálva, de ki tudja? :) A meghajtóval való kommunikációt (a mindenféle gyorsított rutinokkal együtt) ez a µC végzi, azért akadhatnak ott érdekességek. Jelenleg nem érzek hozzá lelkesedést, hogy belemélyedjek; amit most tud sebességre, az bőven jó. (Az előző verzióhoz képest meg pláne, amikor egy másik lemezen kellett a másik gépre az adatokat átmásolnom, amivel írtam a „céltárgyat”. :) )

Mondjuk azt a hozzászólást nem teljesen értem. (Mintha másról is szólna, nem erről a dupla-meghajtós trükkről.) Ez csak olvassa a lemezt, írni nem kell sosem. (Illetve ha áthúzod írásvédetté a 3½-es floppy-t, akkor arra a vezérlő nem fog tudni írni, ha megfeszül, akkor se. :) )

Szerintem úgy értette, hogy a beolvasott adatok 2%-a veszik el.

Az előbb segített a kereső, most itt nincs nagy szerencsém. Egy regisztert találtam, ami releváns lehet, az pedig ez. Illetve egy másik leírás ugyanerről, de tovább ködösíti az amúgy se tiszta képet. :) A sebesség állítása összesen 1 bit! Abból meg túl sok variáció nem hozható ki. Ködös, mert 4 illetve 2 µSec-ről beszél. Ezek a 250000 illetve 500000 bps-nek felelnek meg. De! Az 500Kbps az a HD-s lemez bitsűrűsége lenne, viszont az olyan lemezt nem tudja kezelni a hardver alapból. (Csak a fent említett fél-sebességű trükkel, ott a bitsebesség is visszaesik 250Kbps-re.) Szóval a 250Kbps-es GCR és MFM lemezek azok rendben vannak, de a többi sebesség..?

Jó kérdés... Én egy topicot találtam, ahol a sebességet próbálják állítani, de ettől sem leszünk okosabbak. Azt írják az Amiga default átvitele 253360 bps, azaz, ha van olyan, hogy "default", akkor csak lehet szabályozni valahogy...de aztán ki tudja.

Az az 1200K-s lemezméret úgy talán összejöhet, hogy még több szektort raknak egy sávra (kisebb gap-ek, esetleg nagyobb szektorméret, hogy kevesebb legyen a másra használt hely), illetve több sávot használnak, mint a hivatalos 80. (A gyári AMIGA floppy-k is jó eséllyel tudnak 82-t, de vannak olyanok, amik még ennél is jóval többet (!) tudnak. (Akár 90? :) ))

Azt nem tudom, hogy hogy csinálják, de van egy tool, ami 1200k-s lemezképet tud készíteni, csak épp most baromira nem találom, de itt egy másik, ami 1120k-t tud.
82 trackes lemezt amúgy már az ősöreg XCopy is tudott (asszem ez volt az a bizonyos "long track"?), 90-esről még nem hallottam, de pl. ez az 1120k-s cucc már kb. 100 fölött kéne, hogy dolgozzon.

Nincs ilyen program, mert valószínűleg nem is lehet ilyet csinálni. :) A sima DD-s 5¼-es floppy-meghajtó tudhatja olvasni az 1541 lemezeit (valószínűleg nem mindegyik, de egy részük biztosan), csak a megfelelő bitsebesség nem állítható be az AMIGA oldalán. (Ha lehetne, tuti megcsinálták volna már régen...)

Én feltételes módban beszéltem; írtam, ha a hardware nem teszi lehetővé, akkor nyilván nem lehet megoldani. (Amúgy nem biztos, hogy ha lehetne, akkor már megoldották volna, láttunk mi már olyat, amire korábban azt mondták, hogy lehetetlen, aztán mégsem volt az, nem? :) )

Gyanítom én is, hogy az a rész a lehető legrugalmasabbra van csinálva, de ki tudja? :) A meghajtóval való kommunikációt (a mindenféle gyorsított rutinokkal együtt) ez a µC végzi, azért akadhatnak ott érdekességek. Jelenleg nem érzek hozzá lelkesedést, hogy belemélyedjek; amit most tud sebességre, az bőven jó. (Az előző verzióhoz képest meg pláne, amikor egy másik lemezen kellett a másik gépre az adatokat átmásolnom, amivel írtam a „céltárgyat”. :) )

Gondolom, hogy jó ez így most; én csak elméleti érdeklődésből kérdeztem, hogy be lehet-e valahogy kapuzni az extra RAM-ot. :)

Szerintem úgy értette, hogy a beolvasott adatok 2%-a veszik el.

Az lehet. (Nekem az „adatvesztés” azt jelenti, hogy az adat elveszik. :) Szóval nem marad meg az eredeti helyén sem.)

Azt írják az Amiga default átvitele 253360 bps

Érdekes a linkelt topik. Hogy a sebesség nem pontosan 250000bps, az még érthető is. A gépben – a CBM jó szokásához híven – egy órajel van, ebből a 28.xxxMHz-ből osztódik le minden. Mivel ez nem „kerek” érték, így csak közelítőleg jönnek ki belőle a „szabvány” bitsebességek. Ebből mintha az AGNUS/ALICE csinálna valamilyen osztással órajele(ke)t, amiket a PAULA használ, de ezeknek fix értéknek illene lenniük. :) Szóval csak a PAULA tud ebből „változó” sebességet leosztani, de ott meg csak azt az 1 bitet találtam mint konfigurálási lehetőséget. Most már én is kíváncsi lettem, hogy ez hogyan is van. :) (De jól szétoffolom a témát.)

Az lehet. (Nekem az „adatvesztés” azt jelenti, hogy az adat elveszik. :) Szóval nem marad meg az eredeti helyén sem.)

Nekem is, de lehet, hogy ő másképp értelmezi.

Érdekes a linkelt topik. Hogy a sebesség nem pontosan 250000bps, az még érthető is. A gépben – a CBM jó szokásához híven – egy órajel van, ebből a 28.xxxMHz-ből osztódik le minden. Mivel ez nem „kerek” érték, így csak közelítőleg jönnek ki belőle a „szabvány” bitsebességek. Ebből mintha az AGNUS/ALICE csinálna valamilyen osztással órajele(ke)t, amiket a PAULA használ, de ezeknek fix értéknek illene lenniük. :) Szóval csak a PAULA tud ebből „változó” sebességet leosztani, de ott meg csak azt az 1 bitet találtam mint konfigurálási lehetőséget. Most már én is kíváncsi lettem, hogy ez hogyan is van. :)

Igen, a(z) ((BIG) FAT) AGNUS és az ALICE csinálja a 7.14, ill. 14.28 MHz-et, de az a floppyt nem érinti, közvetlenül legalábbis nem.
Én is kiváncsi vagyok, feltettem a kérdést az EAB-on, hátha lesz válasz. :)

(De jól szétoffolom a témát.)

Sajátod, megteheted. :)

Igen, a(z) ((BIG) FAT) AGNUS és az ALICE csinálja a 7.14, ill. 14.28 MHz-et, de az a floppyt nem érinti, közvetlenül legalábbis nem.

Abból a szempontból érintenie kell, hogy a PAULA azokból az órajelekből tud bitsebességet osztani.

feltettem a kérdést az EAB-on, hátha lesz válasz.

Ahogy nézem, túl nagy diskurzus nem alakult ki... :) Végül is mindegy, egyszer majd csak kiderül.

Abból a szempontból érintenie kell, hogy a PAULA azokból az órajelekből tud bitsebességet osztani.

Nyilván, ezért emeltem ki, hogy közvetlenül nem.

Ahogy nézem, túl nagy diskurzus nem alakult ki... :) Végül is mindegy, egyszer majd csak kiderül.

Hát az az egy válasz a te gyanúdat erősítette meg, szóval valószínűleg ezt így tényleg nem lehet variálni.

Szerkesztve: 2020. 04. 16., cs - 16:44

Szép!

A pro micro-t ha 3.3 voltról hajtod, akkor szerintem a csipen a fuse biteket be lehet állítani úgy, hogy felezze az órajelet. Tehát a 16MHz kvarccal 8MHz lesz a CPU órajele. Így lesz minden specifikáción belül. Biztos nem vagyok ebben, csak hasonló csipek adatlapjait szoktam böngészni, ezt pont nem.

Esetleg lehetne olyat is csinálni, hogy a floppy-t szimulálod egy mikrovezérlővel, ami valójában végsősoron SD kártyán tárolja az oxigént.

Mechanikailag hogy bírják neked ezek a régi vasak? Nekünk volt egy magnónk, ami jópár évre le volt állítva, és egyszer nosztalgiából be akartam kapcsolni. Totál megszorult az egész mechanikája. Belenéztem, és egy csomó gumi alkatrész volt benne, ami felváltva olvadozott és repedezett. Fel is adtam...

Ja, és még egy dolog eszembe jutott: nem lehet a floppyból csak a vasat megtartani, és a vezérlőjét teljesen kicserélni valami modern mikrovezérlőre, amiben van rendesen RAM, és közben USB-zni is tud? Vagy az az átépítés extrán bonyolult volna?

szerintem a csipen a fuse biteket be lehet állítani úgy, hogy felezze az órajelet

Nekem csak egy /8-as beállítási lehetőség rémlett, de belenézve az adatlapba, a 32U4-ben van erre szoftveres lehetőség is. (/8-cal indít a core, de vissza lehet kapcsolni akár /2-t is.) Lehet hogy valami ilyen trükközés megy, ezt a fajtát közelről nem ismerem.

Mechanikailag hogy bírják neked ezek a régi vasak?

Tulajdonképpen meglepően jól. :) Mondjuk magnót azt régen próbáltam, ott azért illúzióim nincsenek. A meghajtóknál az eredeti D500-as mechanikával vannak gondok; ott a lemez forgatása egy laposszíjjal történik, azok el tudnak öregedni. Amiket itt használok, azok dierktmotorosak, ezekben szerencsére nincs olyan alkatrész, ami „elérik”. De ami igazán furcsa: magukkal a floppy lemezekkel se nagyon van gond! Eddig összesen 1 vagy 2 olyan lemezzel találkoztam, amit nem bír formázni a meghajtó. (Nyilván ezek DD-s lemezek.)

Vagy az az átépítés extrán bonyolult volna?

Átépíteni sok értelmét nem látom, akkor már nincs értelme meghagyni semmit. Ilyen projekt van sok, itt fent is linkeltek párat. :)

Húsvét utáni meglepetés! Köszönöm a kiemelést! :)

HW pron újra! Végre nem [KV]... csak lenne időm nekiállni a szerzeményeimnek. A C=128D-t már szétkaptam, kipucoltam, de sajnos a floppy meghajtóra DEVICE NOT PRESENT ERROR-t dob.

DEVICE NOT PRESENT ERROR-t dob.

Egyáltalán elindul? (Mármint a meghajtó.) Tápja van?

a kis összekötő szalagkábelt is kicseréltem

Ebből arra következtetnék, hogy ez nem egy C128DCR, hanem egy „rendes” C128D. Ilyennel közelről még nem találkoztam: ebben egy teljes 1751 van? Amúgy mind a C128, mind az 1571 „buszmeghajtója” eléggé komplikált. Úgy ránézésre nem is derül ki, hogy ki kivel van. :)

Sub és kössz!..

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség