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

Pěkné vysvětlení!

Líbí se mi ta kombinace příkladů v BASIC a assembleru, ještě jak navíc směřuje k BASIC příkazu XIO - postupně tedy víc a víc ukazujeme, že je celé I/O implementované v operačním systému, BASIC dělá jen úplně primitivní wrappery. Což je skvělé a v tomto díle vidíme proč: volání z assembleru je totiž úplně stejné. A kdybychom udělali na malou chvilku výjimku a jednou nepoužili z atari.inc ty symbolické názvy příkazů CIO, tak bychom viděli to 100% podobu s BASIC příkazem XIO. Ale i tak je to myslím každému čtenáři jasné.

Po příkazu FILL jsem se také pídil. A dozvěděl jsem se zajímavosti z historie, jako např. jak šetříli každý bajt pro BASIC, protože se nemohli vejít do vyhrazených 8 kB. Proto jim také pomohl každý přesun nějaké části do OS. Nejen CIO, ale např. i matematické rutiny v plovoucí řádové čárce. A tak jsme tím jako vedlejší efekt získali právě tu snadnou možnost to samé používat v assembleru, resp. strojovém kódu. Jestli to bylo vyhrocené tak, že museli škrtat mezi příkazy i FILL, se mi nepodařilo dohledat přesně konkrétně zmíněné, ale z kontextu mi vyplynulo, že je to velmi pravděpodobné.

Abych Atari BASIC nekřivdil: všechno nejsou jen wrappery. Nejen zpracování formátování příkazu PRINT (převod číselné proměnné na text apod.), ale třeba i to, že příkaz INPUT dělá čtení až po EOL ($9B, 155). To není vlastnost CIO příkazů ani get_byte, ani get_record.

K Atari BASICu: to procházení HATABS má o 1 vyšší limit, ale díky STEP 3 se neprojeví, ne?

K BASIC a FILL: jelikož BASIC používá jen CIO v OS, tak by se dalo říct, že ten lepší algoritmus chybí v OS spíš než v BASIC...

A jedna zajímavost: funguje i opačná legrácka k tomu využití S:. Stejně jako lze používat PRINT v grafických režimech, tak lze používat i PLOT a DRAWTO v režimech textových! Číslo barvy je pak znak, kterým se "kreslí". Opravdu:

GRAPHICS 2 : REM textový režim se čtyřbarevnými znaky
COLOR 65 : REM Budeme kreslit znakem A
PLOT 0,0
DRAWTO 10,5

Ptáte se jakou barvou budou ta A vykreslená? Tak si zkuste zvolit postupně v tom prográmku:

COLOR 65
COLOR 97
COLOR 192
COLOR 225

Užitečnost této fíčury nechám na posouzení kvalifikovanějších :)

Zejména na funkci FILL je vidět, že CIO nebylo navrženo úplně dokonale. Výplňová barva by se měla nastavovat jako parametr CIO volání, ne na nějaké pevně dané (byť zdokumentované) adrese. Stejné je to pro náhradu příkazu POSITION. Pomocí volání CIO jej nelze nahradit (zase jen přímým zápisem na pevně dané a zdokumentované adresy).

Podobně, pro zařízení E: se používá adresa 766, kde je příznak, zda se speciální znaky pro pohyb kurzoru, mazání obrazovky a bzučák (říkejme tomu emulace dálnopisu) mají interpretovat nebo ne. Taky by to chtělo spíš udávat jako parametr při CIO volání.

jj, ale to by AUX1 a AUX2 musely mit 16 bitu nebo neco takoveho. Tak, jak je XIO navrzeno (a odpovida to strukture IOCB) to asi rozumne nejde udelat :/

Těch navázaných dat ale bylo ještě víc... Ale to by nemusel být problém: AUX1 a 2 by při OPEN obsahovaly adresu konfiguračního segmentu v nějakém standardizovaném tvaru. A k tomu volání, která by měla get/set na ty atributy. Jenže základní problém všech osmibitů: RAM.

Mám pocit, že na všech osmibitech to končívalo podobně: s rychlostí procesoru by se člověk ještě jakž-takž smířil, ale omezení na velikost RAM bylo to zásadní, minimálně z pohledu nějakých designově pěkných řešení na API jednotlivých částí OS a tak. Na Atari jsem koukal, že třeba u disket to byl pak už veliký problém. Když se k tomu přidaly ještě nutné buffery, tak z toho pak právě vznikalo to omezení na reálný počet současně připojených disketových jednotek, ačkoliv teoreticky to bylo tak pěkné...

Beru to tak, že to byl úkol těch stroječků: lehce ukázat, nechat nahlédnout do praxe a tím přivést k oboru další lidi. A pokud to tak bylo, tak si myslím, že splnily svůj úkol tak dokonale, jak jen mohly...

RAM mohlo být nakonec dle libosti, i do 8bitového Atari se dá nacpat i 1 MB, ale ten 16bitový adresní prostor byl prostě malý. U IBM PC tam hodili rovnou 20bitový, což bylo pro běžné činnosti postačující celou dekádu, byť užití segmentových registrů nebylo nejpohodlnější. Do příchodu Windows 3.0.

U Atari mi taky přišlo, že datová oblast v nulté stránce využívaná firmwarem je až zbytečně velká. Proč tam byl třeba příznak, jestli se nabootovalo z diskety nebo kazety?

O (ne)systematické organizaci paměti na Atari a o míře její dokumentace, natož dostupnosti té dokumentace, bychom se mohli bavit hodiny... Nezapomeňme, že firma Atari nebyla žádný spolek lidumilů - od začátku se netajili tím, že jejich záměrem je ke klíčovým informacím o HW nikoho nepustit. A jak se vztekali a soudili, když pak přišla Activision...

Takže od začátku tento seriál beru právě jako poctu amatérům, co z této platformy dokázali vydolovat!

Škoda, že tenhle seriál nevycházel tak před pětatřiceti lety. :)

V Amáru :-)

Jo, v Abicku by to decka nepobrala :) A pritom jsem cetl oboji.

Já bych nepodceňoval ABC mladých techniků a přírodovědců! Jen zkrátka byli zvyklí používat jiný materiál, no... :)

http://litildivil.cz/sbirka/pocitace/CGS.htm

(dole je dokonce odkaz na článek na root.cz o tomto fenoménu)

6. 8. 2026, 18:33 editováno autorem komentáře

Ja se skrz synovo ABC dostal k arduinu.

Mne nějak ABC nikdy nechytlo, zato Amatérským rádiem jsem listoval a četl jen tak pro radost. I když jsem nebyl schopen většinu zapojení postavit, i tak mne bavilo číst návody. Více ale červené, modré už bylo příliš detailní. Já si snad budu muset otevřít nějaký online archiv a zase si polistovat.