Názory k článku Podpora unifikované práce se zařízeními v operačním systému Atari: CIO

Díky za další luxusní článek!
Snad mě pamět neklame, ale mám za to, že při otevírání zařízení se tabulka zařízení HATABS prohledávala od konce. Takže možnosti, jak udělat vlastní ovladač existujícího zařízení byly vlastně dvě: Přepsat adresu tabulky vektorů operací v HATABS pro již definované zařízení (oblíbené je P pro ovladač tiskárny např. BT-100), nebo vytvořit nový záznam klidně se stejným písmenem zařízení. Více zde: https://www.atarimagazines.com/v8n2/customhandlers.php

Typická kombinace zařízení v ČSSR u běžných ataristů:

T: kazeťák s Turbem 2000
P: BT-100

(ideálně to mít v TurboBASICu).

Po pádu cen pamětí:

T: kazeťák s Turbem 2000
P: BT-100
D8: RAMDisk (potom se to tuším přejmenovalo na jiné zařízení, ale D8 se drželo, protože s tím dokázaly pracovat starší aplikace)

Tak podobně. Dobrý na tohle byl např. TTDOS, protože v něm si člověk mohl namapovat zařízení interaktivně přímo z jeho menu. A tím si zvolit, jestli jako D: bude ramdisk nebo kazeta a jaké číslo ramdisk bude mít. Takže typická práce, co si pamatuju, byla:

1. nahrát TTDOS, ideálně z cartridge
2. navolit, že D: (alias D1:) je ramdisk a tím rázem mit "standardní disketovku" pro aplikace
3. spustit libovolnou aplikaci (hru, editor, programovací jazyk...) a využívat bleskurychlou "disketu" na opakované zápisy - vývoj programu, textu...
4. na konci práce provést teplý reset, proti kterému tu nedávno někdo tak brojil :D
5. opět spustit TTDOS, pokud se nespustil sám (z cartridge)
6. v něm si vykopírovat finální verze souborů z D: na B:, tj. na kazetu v Turbo

Samozřejmě tu bylo riziko vypnutí počítače před uložením na kazetu, takže kdo se toho z nějakého důvodu bál, mohl naopak v TTDOS navolit, že zařízení D: je kazeta v Turbo (původně B:) a zase: aplikace nic při zápisu nepoznaly, prostě nahrávaly na kazetu místo na disk a bylo jim to jedno. Jen jaksi jim nefungovaly ty extra funkce pro disketu jako výpis adresáře...

30. 7. 2026, 09:54 editováno autorem komentáře

Jak funguje turbo, když je FM demodulátor součástí kazeťáku?
Jsou tam jiné nosné frekvence? nebo je jen zkrácena délka symbolu?

Ten FM demodulátor se u Turba nepoužívá. Počítač měří délku trvání nul a jedniček, to je jiný způsob modulace (jak už psali předřečníci, takto to je i u ZX Spectra).

Na CIO jsem se těšil. Dodnes si pamatuju na ten šok, když jsem přišel na MS-DOS a dostal jsem odpověď na svou otázku: "Kde je tady centrální správa zařízení?" :D

Jen přidám pár bodů: jak Pavel rád píše všechny příklady kompletní, tak tady trošku zaniklo, že ty první tři příklady v BASICu jsou úplně stejné a liší se jen tím názvem zařízení, což je jednoduše řetězec, který může být i v proměnné a klidně tentýž kód můžeme zavolat několikrát pro různé řetězce a kopii dat tak poslat na obrazovku, tiskárnu i kazetu...

A dokonce, jak vidíme, v asembleru je to vlastně totéž, jen chybějící syntax pro zápis více proměnných nahradíme vyplněným IOCB blokem. Ony totiž ty příkazy v BASICu jsou jen velmi primitivní wrapper nad CIO systémem - a stačí to, protože je ten CIO systém už tak high-level.

(Malá poznámka: podobně mě fascinovalo na ZX Spectru, když jsem objevil v operačním systému tak high-level kalkulačku s plovoucí čárkou.)

Těším se, že v příštím díle zavedeme vlastní zařízení do tabulky HATABS !

díky!

(popravdě ještě nemám ani čárku o HATABS, ale času dost :-)

Já bych ten MS-DOS tolik nepodceňoval. První verze byla sotva něco víc než port CP/M na 8086.

Ale už od verze 2.0 měl MS-DOS standardizovanou a celkem robustní podporu znakových zařízení (CON, PRN, AUX, cokoliv dalšího) a dalo se k nim přistupovat pomocí služeb souborového systému. Existoval centrální spojový seznam ovladačů těchto zařízení (něco jako HATABS). Stejně tak měl MS-DOS od verze 2.0 standardizovanou podporu blokových zařízení.

akorát když někdo vytvořil adresář nebo soubor se stejným jménem, jako zařízení (nebo jako vnitřní příkaz COMMAND.COM), tak si zadělal na docela velké problémy - a musel nastoupit disk editor. DOSBox to ovšem neumí emulovat (a nebo to v MS opravili později).

Jednou v zahranici behem COVIDu jsem jel do copycentra tisknout nejake dokumenty. Doma jsem si je pohodlne spojil pres pdftk do souboru, ktery jsem dle sveho celkem logicky pojmenoval prn.pdf.

V samoobsluznem copycentry Widle hroznej problem. Soubor ma 0 bajtu a podobne, pritom ve vypisu videt byl a nejake bajty mel. Chvili mi to nedochazelo, nez mi docvaklo, ze je to vzdalene podobne PRN:.

Takze ani v soudobych Widlich neni mozne mit soubor s nazvem treba aux.neco nebo nul.neco. To je opravdu zoufalost. Pominu to, ze nejakej blbec vymyslel, ze ta dvojtecka bude nepovinna. Ale proc to jeste jinej idiot vylepsil tim, ze se ignoruje i to .pdf na konci? Pominu, ze naprosta vetsina techto zarizeni, nejspis vsechny, ani neni implementovana a jen to odmitaji funkce na otevreni souboru.

Nakonec jsem hledal zoufale na netu, jak z toho ven, resenim bylo v PowerShellu zadat naprosto silenej escaping o snad peti znacich pred tim prn* a pak to slo prejmenovat.

já bych v tom žádnou logiku nehledal, protože tam žádná není :-) já si tak naběhl s adresářem CDROM, který fungoval v DOSu (když jsem nabootoval bez podpory CD-ROM), ale Windows to odmítaly (a nastoupil diskeditor).

prostě prakticky od začátku DOSu jen slepě kopírovali zpočátku CP/M a později Unix, aniž by pochopili, proč to v Unixu funguje, jak funguje. Tudíž to "vylepšili" jmény zařízení, potom náhradou - (přepínače) za /. A když došlo na lámání chleba a i v DOSu se objevily adresáře, tak už bylo / obsazeno, takže se nabastlil \ (o koncích řádku nemluvě).

Jo jo, občas je nejjednodušší nabootovat jiný systém z USB klíčenky, např. SystemRescue Linux, a opravit ten disk z něj - tam nemá žádný speciální význam a můžou se prostě "opravit data". A pak jen boot zpátky do původních Windows a voila! Ani šroubovák není potřeba...

Ale souhlasím s hodnocením jak nepovinné dvojtečky, tak ignorování přípon. Navíc nechápu, proč nepomůže úplně obyčejné zadání nějaké delší cesty. To ta wokna neumějí soubor přejmenovat ani např. příkazem 'move C:\adresar\prn.pdf C:\adresar\ne­prn.pdf' ??

Je možné, že si to po letech už nepamatuju, ale nemám pocit, že bych viděl někoho, jak udělá ovladač třeba na svou nestandardní tiskárnu, původní PRN přejmenuje standardním a definovaným způsobem na něco jiného, svůj ovladač zaregistruje jako PRN, také standardním způsobem, a odteď mohl nahrát jakýkoli program a poslat v něm výstup na svou tiskárnu aniž by ten program zpozoroval změnu.

Myslím, že tam byl nějaký neustálý souboj residentů (občas na ostří nože, nekradli si IRQ?) a do toho nekompatibilní způsoby správy paměti definované v SYS, takže měnitelné pouze bootem. A různé programy potřebovaly buď ten nebo onen.

A pak už si pamatuju jenom, že u vedlejšího stolu byli nějací starší kluci, kteří měli zařízení seřazená v /dev ...a tak jsem tady :)

Ano, realita byla poněkud jiná a tak trochu stejná jako u Atari. Programy náročné na výkon zobrazovacího systému (třeba i tabulkové kalkulátory jako Lotus 1-2-3) určitě nebyly psané pro zařízení CON v MS-DOSu, ale přistupovaly k obrazové paměti přímo. Stejně tak hry pro Atari většinou nepoužívaly zařízení S: pro vykreslování.

Zato zařízení P: pro tisk bylo na Atari v kurzu, protože pohodlně poskytlo vhodnou vrstvu abstrakce. V MS-DOSu si to každý pokročilejší textový editor a slovní procesor řešil sám (hromadou ovladačů nebo definičních souborů pro všemožné tiskárny, hoši ze Software602 by mohli vyprávět o DST souborech).

I na Linuxu je to asi všelijaké. Třeba zvuk se pořád dá posílat na /dev/dsp (pokud se neztratíte v hromadě IOCTL na nastavení vzorkovací frekvence atd.), ale myslím, že použití všemožných API dnes převažuje. Zvuk je ale jenom střípek.

Zajímalo by mne, jak něco jako CIO fungovalo na minipočítači, kterým se konstruktéři 8bitové řady inspirovali.

Jo, to sedí na moje vzpomínky - tj. správa zařízení s možností registrace pod jménem, přejmenovat ty "systémové" apod. v MS-DOS prostě nebyla. Ba naopak, dodnes jsou PRN a podobné jen nabastlené výjimky dělající potíže i ve Windows - jak tu vzpomínají další. Přesný opak CIO.

Na Linuxu mi vždycky zase přišlo divné, proč všechna zařízení jsou v /dev kromě síťových...

K písmenkům CIO zařízení pro obsluhu turba. S písmenky se samozřejmě dalo hrát a přemapovávat je. V typickém výchozím nastavení to bývalo takto:

T: Turbo 2000 - Kilobytové bloky. Rychlost 2270 bd. 10bytová hlavička + prosté kilobytové bloky s daty. Jednoduchý formát.

B: TURBO TAPE nebo B-TAPE. Rychlost >= 2725 bd. 1026bytové bloky. Žádná hlavička, v každém bloku byly kromě uživatelských dat úplné informace o souboru ke kterému blok patří (jméno souboru, číslo souboru, sekvenční číslo bloku, příznaky pro zdvojené bloky a dlouhé mezery, zaplnění bloku). První blok byl vždy zdvojený. Pokročilý formát, který umožňoval rychlou orientaci na pásce, nebo pohodlnou funkci "Tape Directory".

U: Turbo 2000 - hlavička + dlouhý datový blok. Původní formát zavedený pro Turbo 2000.

Co bych za to dal, kdybych tohle vsechno vedel, kdy mi bylo 8 - 13 ;-)

Programy, které tato zařízení poskytovaly, tedy primárně TOS a TT-DOS měly vše řádně zdokumentované v uživatelské přiručce.

Ale lepší než tyhle kazetové "vědomosti" bylo vlastnit disketovou jednotku.

jsem si hodně hrál sTurboBasicem XL, pamatuji si, že jsem finální verzi programu ukládal (exportoval) nějak stylem LIST T:, uložilo se to v turbu jako listing, pak reset a znovu načíst zpět. Výhoda byla, že se tímto stylem "vyčistily" zbytečné, smazané proměnné a řádky, a nestrašily pak v DUMPu ...