Domluvili jsme se s Pavlem, že pro ty, kdo by si chtěli zařízení G: vyzkoušet rychle a snadno, nabídneme předchystaný disk. Zároveň si můžete přečíst zkrácené readme - je určené pro ty, kdo už mají za sebou tento článek s podrobným vysvětlením a chtějí jen stručný sumář a pár technických detailů:
https://atari.caputu.cz/g_device/
Jako ukázku práce se zařízením pak uvádím využití na editaci souboru na disku, když nemáme editor a jen jsme v BASIC. Soubor nakopírujeme do G3:, prohlédneme, upravenou kopii vyrobíme v G4: a až jsme spokojení, uložíme zpět na disk. Tak jsem upravil STARTUP.BAT , aby používal Pavlem zavedené názvy souborů místo mých provizorních.
https://atari.caputu.cz/g_device/usage.png
Užívejte, hrajte si, posílejte zpátky patche!
13. 8. 2026, 01:20 editováno autorem komentáře
Ještě jednou Milane dík za skvělou spolupráci. Když to porovnám se systémem spolupráce, který používám v mé profesi... nebe a dudy :)
Kdysi hodně dávno jsem dělal úpravy a opravy driveru zařízení pro Windows NT a Windows 95. To byly doslova tuny kódu zkopírovaného z nějakého stub driveru (ten kód tam být musel). Navíc musel být nainstalován nějaký Windows Device Development Kit pro vývoj (další tuna kódu do Visual studia). A aby toho nebylo málo, to céčko, které se používalo, bylo nestandardní. Ladění - z druhého počítače přes sériovou linku!
Na atárku je driver nového zařízení doslova na pár stovek bajtů, jak osvěžující.
A abych nezapomněl: to "konkurenční" zařízení N: používejte opatrně. Ne že bych chtěl pomlouvat, ale... :)
Vrtalo mi hlavou, že přeci musí "zabít" celý počítač, ale až teď jsem se dostal k tomu to vyzkoušet a ověřit. Ano, je to tak, už vám nepomůže ani monitor v emulátoru...
Takže otázka pro zvídavé hlavy: jak si shodit atárko a zničit na něm náhodně svůj program pomocí zařízení N: ?
už je pozdě - AI se to naučila špatně a teď to bude nabízet jako řešení napořád :-)
Je chyba v tom originálním kódu z minulého tisíciletí? Tam bych věděl (protože jsme to předevčírem řešili)..
V zásadě to není přímo jeho chyba, ale je to známá chyba někoho jiného, kterou on neošetřil - a jako na potvoru zrovna to, co má ty nejhorší možné důsledky.
Dál ať čte jen ten, kdo už nechce pátrat:
V jeho i vašich příkladech se vždy testuje jen zápis, ale ne čtení. A tam se narazí na jednu šílenost BASIC: on si řídí čtení sám a pokaždé pokračuje až do nalezení "enteru" (9B). Možňá má limit 256 bajtů, ale nevím jistě. A teprve pak příp. ořízne data z bufferu do proměnné na její max. alokovanou délku. A jak dlouho tedy bude číst ze zařízení, které nikdy nevrací bajt 9B ani nikdy neohlásí konec souboru? A pak už je to o náhodě, co zrovna kde přepíše těmi bajty s kódem 01. Hned napoprvé se mi povedlo přepsat i kód programu v BASIC, zatuhnout počítač na neznámé instrukci a i po RESET pak zkolaboval znova po pokusu o příkaz LIST... Jindy můžete mít větší štěstí...
Mimochodem, tím je ovlivněná práce v BASIC s de facto jakýmkoliv zařízením a je jen otázkou, jak moc to koho rozhodí. Zařízení G: nikdy neskončí mimo svoje limity a korektně ohlásí chybu, když se dojde na konec dat, ale také jde napsat v BASIC překvapivý kód...
Ještě k těm chybám... Ono když vím, jaký problém byl se dostat k jakékoli dokumentaci a kolik jí bylo jen amatérské a tudíž i s chybami, tak se nedivím, že třeba autor nevěděl o standardním zavádění zařízení rutinou OS nebo že má popletené návratové hodnoty (v akumulátoru se nikdy žádný status nevrací).
Já se s tím potýkal i teď v roce 2026 a s veškerou pomocí internetu. Např. když jsem hledal volné buňky v nulté stránce, raději jsem si vzal čtyři různé popisy paměti Atari a zkombinoval jsem je. A bylo to potřeba, protože každý autor přišel s jinými zkušenostmi i třeba na základě jiného HW periférií.
Navíc jsem těch buněk v nulté stránce původně potřeboval pět. Ale to jsem se tak styděl za své plýtvání, že jsem raději program celý od základu přepsal a přeorganizoval, abych vystačil se dvěma. A tu plýtvající verzi jsem raději smazal a nikomu neukázal, a není ani v mém soukromém gitu, raději nikde. Tak jsem se styděl :)