Kezdőlap
Vissza

fizetett hirdetés

 

Gyorstöltők

Az IEC busz hibás megvalósítása tragikus mértékben lerontotta a floppy meghajtók adatátviteli sebességét, ezért különböző független fejlesztők már a kezdetektől keresték a lehetőségét annak, hogy legalább a program fájlok töltési idejét lerövidítsék. Erre több eltérő koncepció is született, különböző előnyökkel és hátrányokkal. Alapvetően az alábbi megoldásokat különböztethetjük meg:

Ezek voltak az első megoldások, már 1983-tól találkozhatunk velük. Rengeteg változat született belőlük különböző neveken (Fasload, Quickload, Hypraload, Gigaload, stb.). Mind a megvalósításban, mind a hatásfokban nagy változatosságot mutatnak ezek a programok. Közös viszont bennük, hogy a gyorsítást alapvetően úgy érik el (egyéb, apróbb trükkök mellett), hogy a DATA vonal mellett a CLK jelvezetéken is adatbitet továbbítanak. Ehhez persze rendkívül pontosan időzített, összehangolt programfutás szükséges mind az alapgépben, mind a floppyban. Emiatt a kezdeti megoldások még kikapcsolták a képernyőt töltés közben, később jobban tervezett kóddal (és alacsonyabb töltési sebességgel) ez már elkerülhető volt, míg végül napvilágot láttak olyan megoldások is, melyek már a megszakításokat sem tiltották le, így a sprite-ok is a képernyőn maradhattak, vagy akár zene is szólhatott töltés közben.

Ezen programok egy részét EPROM-ba égetve, cartridge formában is forgalmazták, de ez a kivitel csak a segédprogram betöltését takarította meg, ettől még tisztán szoftveres megoldás maradt. Szintén alapvető kellék volt egy szoftveres gyorstöltő minden törőkártyában is, mint pl. a legendás Action Replay.

Action Replay Plus Mk 7.0 szoftveres gyorstöltő - kb. 8,8 mp / 200 blokk


 

Az előző típusú gyorstöltők egy oldalhajtásának tekinthető ez a megoldás. Ebben az esetben nem egy külön, memóriába töltődő program végzi az adatátvitelt, hanem az alapgép és a floppy ROM-ba égetett  gyári rendszer-szoftverét cserélik le egy, az elvárásoknak jobban megfelelőre. Az átviteli technika továbbra is a CLK vezeték használatára támaszkodik. Ez a megoldás sebességében gyakran még el is marad a korábban tárgyalt szoftveres gyorstöltőktől, ám előnye az állandó rendelkezésre állás, és hogy nem csak a betöltési funkciót lehet ilyen módon meggyorsítani, hanem lényegében minden alapgép és a meghajtó közötti kommunikációt. A koncepció legjellemzőbb példája a JiffyDOS, mely egyfajta szabvánnyá vált (különösen az USA-ban népszerű), és szinte minden meghajtó típushoz elkészült a megfelelő ROM verzió, még a CMD olyan extrém perifériái is ismerik ezt a protokollt, mint a RAMLink.

JiffyDOS kernal gyorstöltő - kb. 23,7 mp / 200 blokk


 

Szintén a szoftveres gyorstöltők szolgáltattak alapot ehhez a típushoz, hiszen még mindig a DATA és a CLK vezetékeket használják adatátvitelre. Viszont időközben megszületett a felismerés, hogy az adatátvitel tovább gyorsításának legsúlyosabb gátja immár a GCR dekódolás időszükséglete. Egymástól függetlenül kidolgozásra került hát néhány megoldás, melyek közösek abban, hogy az adatokat nem valódi GCR formátumban rögzítik a lemezen, hanem egy olyan leképzéssel, mely a GCR kódolás szerint is értelmezhető adatot szolgáltat (így a lemez hagyományos eszközökkel másolható marad), ám lényegesen gyorsabban dekódolható.

Ez a megoldás rendkívül gyors, ám hátránya, hogy nem tölthető be vele tetszőleges fájl, hanem a fájlt, amit vele akarunk betölteni, előtte megfelelő módon preparálva kell rögzítenünk a lemezen. Ha egy ilyen fájlba belepillantunk egy hagyományos lemez monitorral, a fájl olvasható lesz, viszont csak értelmetlen adathalmazt látunk, a valódi tartalom az eltérő kódolás miatt rejtve marad. További hátrány, hogy az alternatív kódolás kevésbé tömör eredményt szolgáltat, így a preparált fájlok mérete némileg megnő.

Jellemző példa erre a technikára a német fejlesztésű Heureka Sprint, vagy az Action Replay kártyákban alkalmazott WARP tárolási mód.

Action Replay Plus Mk 7.0 WARP gyorstöltő - kb. 6,7 mp / 200 blokk (átkódolva 211 blokk, de a hasznos adat 200 blokk)


 

Ezek a megoldások már a hardware módosítását igénylik. Közös bennük, hogy a floppyban lévő, szabadon maradt VIA port kihasználására épülnek. Mivel az említett port egy 8 bites, szabadon programozható I/O port, így lehetőséget ad valódi párhuzamos adatátvitelre, ehhez "csak" a megfelelő vezetékelést kell kialakítani (erről bővebben itt). A párhuzamos kábel többnyire az alapgép user-portjára csatlakozik, ám van olyan megoldás is, ahol egy cartridge-re. Szintén általános, hogy a megvalósítás ROM cserét is igényel mind az alapgépben, mind a meghajtóban.

A párhuzamos gyorstöltőket említve legtöbben a SpeedDOS-ra gondolnak, noha ennek sebessége nem haladja meg egy jól elkészített szoftveres gyorstöltőjét. Sokkal hatékonyabb megoldás, amikor a meghajtóba a párhuzamos kivezetésen és a ROM-on kívül némi RAM bővítés is beépítésre kerül, mint pl. a DolphinDOS esetében. Ezzel a megoldással egy lépésben lehet beolvasni és dekódolni egy egész sávot, ami jelentős időmegtakarítást jelent. További fejlesztések jelentek meg a Prologic DOS-ban és a Professional DOS-ban, ahol talán a CPU órajelének duplázásával, vagy a hardveres GCR dekódolással tudták tovább növelni a sebességet, de ezekről a megvalósításokról sajnos nincsenek konkrét információim.

DolphinDOS V2.0 - kb. 4,9 mp / 200 blokk

(Már a directory beolvasási ideje is impozáns! Az egyéb gyorstöltők ezt és a hasonló műveleteket általában nem gyorsítják.)
 

IDE64 + DolphinDOS másolás - kb. 6,5 mp / 200 blokk

IDE 64 - kb. 1,1 mp / 200 blokk J
 

A párhuzamos adatátvitelre való példaként megemlíthető még a 64HDD is. Erről a PC-n futó .D64 szerverről hajlamosak vagyunk megfeledkezni, ha C64-es adattárolásról esik szó, pedig egy igen rugalmas rendszer, mely XP1541 kábellel felszerelve impozáns adatátviteli sebességre képes! Ráadásul használatához nincs szüksége semmilyen hardware vagy software módosításra a C64-ben.

64HDD XP1541 kábellel - kb. 4,3 mp / 200 blokk

(Ijesztő tempó! A PC párhuzamos portja lazán odaver a DolphinDOS-nak is!)

 

A párhuzamosított meghajtók ROM csere nélkül is hasznosak lehetnek. Jó példa erre a néhány másolóprogram, pl. a "17 sec. 256k copy", mely egy párhuzamosított meghajtó és egy 17xx RAM bővítő segítségével 17 másodperc alatt olvas be és ír ki egy 40 sávos  lemezoldalt.

17 sec. 256k copy - kb. 8,3 mp / 683 blokk

(A felvételen az írás ellenőrzés aktív, ezért a kiírás számottevően hosszabb időt vesz igénybe. Kikapcsolt írás ellenőrzés mellett az írási és olvasási idők kb. megegyeznek.)
 

Nem szorosan ide kívánkozik, de az érdekesség kedvéért megemlíthető a Star Commander párhuzamos adatátviteli üzemmódja is, hiszen itt is egy párhuzamosított meghajtó csatlakozik a PC-hez.

Star Commander XP1541 kábellel - kb. 25,3 mp / 683 blokk


 

Megjegyzés a mérések lefolytatásához

A töltési időt a LOAD leütésétől a READY megjelenéséig mértem. Ez valamivel hosszabb, mint a tényleges adatátvitel ideje, hiszen benne van a directory adatok beolvasása és a sávpozícionálás időigénye is, de egyrészt így egyszerűbb volt a mérés, másrészt a felhasználó szemszögéből nézve ez az a teljes időszükséglet, ami kell az adott program betöltéséhez.

Ha valaki megismétli a méréseimet, ne lepődjön meg, ha esetleg lényegesen más értékeket mér. A fájlok töltési sebessége ugyanis nagyban függ azok szektorainak fizikai eloszlásától a lemez felületén. Így előfordulhat, hogy ugyanaz a program átmásolva egy másik lemezre, lényegesen eltérő töltési időket produkál.

A mérések során ezért ugyanazt a lemezt, és rajta ugyanazt a 200 blokkos fájlt használtam, ahol erre lehetőség volt. Kivétel a WARP töltési mód, hiszen ebben az esetben a fájlt mindenképpen újra kellett rögzíteni a WARP kódolási eljárással. Szintén más a helyzet az egész lemezoldal másolásakor, mivel ekkor lehetőség van a szektorokat az optimális sorrendben olvasni.

 

This site is a member of WebRing.
To browse visit Here.

The C64 Banner Exchange
The C64 Banner Exchange