Múzeum - Enterprise könyvek - Gépi Kódú Programozás

Bevezetés

Minden személyi számítógéppel ismerkedő, a gépet kreatívan használni akaró alkalmazó eljut - előbb vagy utóbb - arra a szintre, hogy érezni kezdi a BASIC programozási rendszer korlátait. Akár az elérhető működési sebességet érzi túl kicsinek, akár olyan különleges hatások keltik fel a figyelmét, amelyekkel gyári programokban, esetleg más gépeken találkozott - a felhasználók jelentős része érdeklődni kezd a gépi kódú programozás iránt.
Így van ez az ENTERPRISE esetén is. Ki kell emelni azonban, hogy nemigen találkozhattunk még a home computer (házi számítógép) kategóriájú, nálunk is elterjedt gépek között ennyire komfortos, a látványos, dinamikus programozást ilyen mértékben segítő BASIC értelmezővel.
Mire számíthat az, aki rászánja magát erre az útra, a gép mikroprocesszorának közvetlen utasításokkal való vezérlésére, programozására? Először bizony meglehetősen sok buktatóra, nem éppen kellemes meglepetésre. Az a baki, amit a BASIC rendszer ilyen-olyan (pl. szintaktikai) hibának minősített, a gépi kódú program futtatása során sajnos gyakran a rendszer összeomlásához vezethet, esetleg lefagy a gép (olyan végtelen ciklusba kerül, amiből csak a kikapcsolás menti ki). A gépi kódú programokat tehát sokkal fegyelmezettebben, körültekintőbben kell megírni, a tárban elhelyezni, majd futtatni, mint pl. a BASIC programokat. De a haszna is megvan a többletenergia ráfordításának. Ha csodákat nem is várhatunk a programok gépi szinten való megírásától (hiszen adott á fizikai háttér, az ún. hardver: a processzor működési sebessége, címzési kapacitása, a képmegjelenítés technikája stb.), azt mindenképpen mondhatjuk, hogy így sokkal hatékonyabb programokat tudunk készíteni.
Mit jelent ez a hatékonyság? Három fő területet lehet kiemelni:

1. A gépi kódú program jóval tömörebb, mint a BASIC. Egy-két kilobájtnyi gépi programmal már egészen összetett feladatokat lehet megoldani.
2. A futási sebesség egyes területeken nagyságrendekkel nagyobb, mint a hasonló feladatot megoldó BASIC program esetén. Van persze más magas szintű nyelv is (pl. a PASCAL), ami egyesíti a programozási komfortot és a nagy működési sebességet, de a mikroprocesszor közvetlen programozásával a lehető leggyorsabb programfutás érhető el.
3. A közvetlen programozással semmiféle olyan szoftverkorlátozást nem kötelező figyelembe vennünk, amit a rendszer tervezői - pl. az egységes kezelés érdekében - szabtak. Hogy egy példát mondjunk erre: a képmegjelenítést végző - hallatlanul sokoldalú - NICK-chip lehetővé tenne akár pont-soronként különböző video üzemmódokat (szöveges vagy grafikus módok, színválaszték stb.), de az operációs rendszer beépített VIDEO kezelője csak karaktersoronként engedélyez módváltást. Ez is sokkal több a COMMODORE vagy ZX gépek lehetőségeinél. Mindenesetre igen vonzó lehetőség, hogy gépi kódú programozással elérhetjük a fizikai lehetőségek elvi határait. Mindezeken kívül vannak a szoftvernek olyan területei, amelyek elvileg is elérhetetlenek magas szintű nyelvekből (ilyen pl. a megszakítási rendszer), amelyek programozása csakis gépi kódban képzelhető el.

A gépi szintű programozáshoz rendelkezésre álló szakirodalom meglehetősen felemás. Míg bőven találunk a Z80-as mikroprocesszor utasításkészletével, programozásával foglalkozó könyveket, cikkeket, addig ezek ENTERPRISE gépen való alkalmazásával alig foglalkozik kiadvány. Nagyon sokat segített ezen a helyzeten a számítógép operációs rendszerének (EXOS 2.1-es verzió) leírása, amely nagyon sok hasznos információi nyújt az operációs rendszer felhasználásával kapcsolatban. Példákat azonban nem közöl, így a gépével most ismerkedő Olvasó számára viszonylag nehezen követhető az igényes, magas színvonalú leírás. Sokaknak hiányzik - tapasztalataink szerint - a gép működési logikájának leírása is, annak követése, hogy mi miért és hogyan történik a gépben. Nem foglalkozik a leírás a BASIC értelmezővel sem (hiszen ez már felhasználói program), pedig ennek bővítése, rutinjainak felhasználása ugyancsak hálás területe a gépi kódú programozásnak.
Mindezek alapján érthető, hogy könyvünket ezen hiányok pótlására, az érezhető igények kielégítésére szántuk. Mivel feltevésünk szerint az országban elterjedt többezer gép tulajdonosa - a BASIC-et már többé-kevésbé ismerő, de a gépi kódú programozással most ismerkedő fiatal - veszi elsősorban kezébe a könyvet, az 1. fejezetben röviden összefoglaljuk a gépi kódú programozáshoz szükséges alapismereteket. Ezután végigkövetjük előbb á háttérrendszer - az EXOS - majd a BASIC rendszer működését, felhasználását (sok példával, végig az alkalmazást, saját elképzeléseink megvalósítását, rutinjaink beillesztését tartva szem előtt).
A kényszerűség néha pozitív mellékhatásokkal is jár. A szakirodalom hiánya arra ösztönzi a felhasználókat, hogy kísérletezve, próbálkozva fedezze fel gépe tulajdonságait. Azt tanácsoljuk az Olvasónak, hogy kövesse azt az utat, amit - többek között - mi is követni kényszerültünk. Kísérletezzen, próbálja ki a példákat, a változtatási lehetőségeket, azok hatásait. Ez az út talán egy kicsit időigényes, nem zárja ki a tévedés lehetőségét sem, de minden bizonnyal a gép alapos megismeréséhez vezet.

1. A gépi kódú programozás alapjai

Mint a bevezetőben írtuk, az ENTERPRISE személyi számítógépek mikroprocesszoráról - a Z80-asról -, annak programozásáról igen sok színvonalas szakkönyv jelent meg. Ezen a területen tehát nincs szükség hiánypótlásra. A következő összefoglalással inkább azt szeretnénk biztosítani, hogy összeállításunk önmagában is használható legyen, akár a gépével, a számítástechnika e területével most ismerkedd felhasználó számára is. Aki tehát jól ismeri a Z80-as utasításait, alkalmazását, át is lapozhatja ezt a fejezetet - legalábbis első nekifutásra.
A gépi kódú programozás iránt kétségtelenül sokakban meglevő idegenkedést - tapasztalataink szerint - az alapfogalmak tisztázatlansága is erősíti. Mindeneke1őtt foglaljuk össze a gépi szintű programozás alapvető fogalmait, kifejezéseit.

1.1 Alapfogalmak
A számítógép működése során minden utasítást, adatot a különböző memóriák tárolnak. A memóriák elemi egységei, cellái egyetlen információt, egy bitet képesek megőrizni, aminek értéke 0 vagy 1 lehet. Valójában két jól megkülönböztethető fizikai állapotról van szó (pl. nincs feszültség van feszültség), amit a 0 és 1 kódokkal jelölünk. A memória törlése azt jelenti, hogy 0 állapotba hozzuk, beírása pedig az 1 állapotba billentést jelenti. Az olyan memóriát, amelynek rekeszeibe tetszés szerint írhatunk 0 vagy 1 értéket, RAM-nak nevezzük (Random Access Memory - tetszés szerint elérhető, azaz írható, olvasható memória). Vannak olyan memóriák is, amelyek celláinak állapotát gyárilag beégették, ezek a ROM-ok (Read Only Memory - csak olvasható memóriák). Ezek alkalmasak a gépet működtető alapprogramok, belső adatok (pl. PI) stb. tárolására.
A memória bitjei - a Z80-as fizikai sajátosságainak megfelelően - 8-as csoportokba, ún. bájtokba (gyakori a byte írásmód is) vannak rendezve. Egyetlen utasítással egy ilyen 8-bites blokk olvasható vagy írható. Egy bájt értéke már természetesen sokkal többféle lehet: az alkotó bitek értékétől függően 00000000-tól 11111111-ig 256 különféle értéket vehet fel. Jól látható, hogy a bájtok megadására, kezelésére kínálkozó egyik segédeszköz a kettes számrendszer. A bájtok által képviselt bináris (kettes számrendszerbeli) érték meghatározásánál a legutolsó bitet tekintjük a legalacsonyabb helyi értékűnek (ez a 0. bit), és előre haladva az egyes bitek egyre magasabb helyi értéket képviselnek. A bájtot alkotó legnagyobb értékű bit lesz a 7. Szokásos még az LSB (Least Significant Bit - legkisebb értékű bit), ill. az MSB (Most Significant Bit - legnagyobb értékű bit) megjelölés is.
Az n. bit értéke a bájtban 2^n:

Így lesz pl. a 00000101 bájt értéke decimálisan (azaz a megszokott tízes számrendszerben) 1*2^2 + 1*2^0 = 5. A bináris-decimális átalakítást segíti az ENTERPRISE BASIC-je (BIN(x)), de a decimális számok kettes számrendszerbe alakításához nekünk kell segédrutint készítenünk:

100 PROGRAM "bin.bas"
110 DEF BIN$(X)
120   LET B$=""
130   LET B=128
140   FOR N=0 TO 7
150     LET BN=INT(X/B)
160     LET B$=B$&STR$(BN)
170     LET X=X+B*(BN=1)
180     LET B=B/2
190   NEXT
200   LET BIN$=B$
210 END DEF
220 DO
230   INPUT PROMPT "Atirando szam? ":SZ
240   IF SZ>=0 AND SZ<=255 THEN PRINT "Binaris alak: ";BIN$(SZ)
250 LOOP

Érdemes ezt a rutint (vagy hasonlót) beírni a gyakorlás lehetőségén kívül azért is, mert jól használhatjuk majd a gépi kódú programok nyomkövetésénél.

A bináris alak nagyon praktikus akkor, ha egy-két kiemelt bit értékét kell figyelnünk, vagy pl. a grafikában, ahol a megjelenő alakzat pontjai egy az egyben megfeleltethetőek a bitek értékeinek, de túlzottan körülményes az átlagos számolásokhoz, kódok, címek megadásához stb. A gépi kódú programozásban igen elterjedt a bájt felépítését továbbra is tükröző, de a binárisnál jóval tömörebb tizenhatos számrendszerbeli (hexadecimális) megadás. A hexadecimális számjegyek jelölésére - jobb híján - a decimális jegyeket (0-9) és az A-F betűket használjuk:

Egy hexadecimális jegy tehát 4 bit minden lehetséges értékét képes leírni. A bájt értékét ezek szerint két hexadecimális jegy adja meg. Az első a tizenhatosok számát, a második az egyesek számát tartalmazza (mint ahogy a tízes számrendszerben pl. 35 esetén 3 a tízesek száma, 5 az egyesek száma). Így pl. az A5 hexadecimális szám értéke tízes számrendszerben:

10*16^1 + 5*16^0=165

A továbbiakban az egyértelműség érdekében a hexadecimális alakot a szám után írt H betűvel jelöljük. Például:

32H = 3*16^1 + 2*16^0=50

Megjegyezzük, hogy a téma szakirodalmában gyakori a #32 vagy $32 típusú jelölés is. A 0 és 255 közötti számok hexadecimális alakját (00H-FFH) az 1. függelék tartalmazza.
A memóriák elérésére, megcímzésére a Z80-as processzornak 16 vezetéke van, amelyek mindegyike 0 vagy 1 állapotú lehet. Egy-egy memóriahely címét (ahol 1-1 bájt adat van elhelyezve) ezek szerint egy 16 bites bináris szám (az ún. "szó", "word") határozza meg. A processzor tehát 2^16 = 65 536 memóriahelyet tud megkülönböztetni, megcímezni (és oda adatot írni vagy onnan olvasni). Hogy az ENTERPRISE gépek esetén ennél jóval nagyobb memóriát is képes kezelni, az már egy technikai trükknek köszönhető (erről a következő fejezetben részletesebben is írunk).
Hogyan lehet egy címet megadni? Alapvetően természetesen egy 16 bites bináris számmal. A előbbiek alapján logikusan következik, hogy jóval praktikusabb, tömörebb két bájttal (4 hexadecimális jeggyel) megadni ugyanazt az értéket. Például:

1100 0010 0101 0100B = C254H

(a bináris értéket B-vel jelöljük)
Az első 8 bitet szokás felső (High) bájtnak, a második 8 bitet alsó (Low) bájtnak nevezni. A felső bájt tulajdonképpen a kétszázötvenhatosok számát adja. Így az előbbi cím decimális értéke:

C2H = 194
54H = 84
cím = 194*256 + 84 = 49 748

A decimális-hexadecimális oda-vissza konverzióra feltétlenül érdemes rutint készíteni, olyan gyakran lesz szükség az átszámításra:

1 PROGRAM "DEC-HEX.bas"
100 DEF H$(N)=CHR$(INT(N/16)+48-7*(INT(N/16)>9))&CHR$(MOD(N,16)+48-7*(MOD(N,16)>9))
110 DEF W$(WORD)=H$(INT(WORD/256))&H$(MOD(WORD,256))
120 DEF DEC(H$)
130   LET D=0:LET Q=1
140   FOR N=LEN(H$) TO 1 STEP-1
150     LET D=D+ORD(HEX$(H$(N:N)))*Q
160     LET Q=Q*16
170   NEXT
180   LET DEC=D
190 END DEF

A program lefuttatása után próbáljuk ki a következőket:

PRINT H$(127)
7F

PRINT W$(16383)
3FFF

PRINT DEC("F"),DEC("FF"),DEC("FFFF")
15     255     65535

Az egyszerűség (és gyorsaság) érdekében a H$(N), ill. W$(N) rutin nem ellenőrzi az argumentum értéktartományát (0-255, ill. 0-65 535). Szükség esetén ezt a hívónak kell megtennie.
A bit, a bájt és az összetartozó kétbájtos érték a gépi kódú programozás leggyakrabban használt egységei. Nagyobb memóriatartományok meghatározására gyakori még a kilobájt (kbyte, 1024 bájt) egység is. A számítógép minden műveletet (a gyökvonástól az ellipszisrajzolásig) ilyen egy- és kétbájtos adatok mozgatásával, rajtuk és közöttük elemi műveletek elvégzésével valósít meg. Tekintsük át az alapműveleteket is. A bájtok között elvégzett minden (logikai, aritmetikai) művelet a bitek közötti műveletekből származtatható. Ezeket a legegyértelműbben az ún. igazságtáblázattal adhatjuk meg: az összes lehetséges esethez megadjuk a művelet eredményét. Elsőként nézzük a logikai műveleteket, amelyeknél a művelet eredménye mindig 1 bit:

A bájtok közötti műveletet az azonos helyi értékű bitek között külön-külön elvégzett műveletek valósítják meg. A műveletek használhatóságáról majd az utasításkészlet tárgyalása során ejtünk még néhány szót. Az ún. aritmetikai műveletek haszna egészen nyilvánvaló, a számtani alapműveletekről van szó:

Az utolsó sorra érdemes felhívni a figyelmet: 1+1 = 0 és marad 1. A túlcsorduló 1-es már a magasabb helyi értékű bitek értékeit növeli (hasonlóan, mint a tízes számrendszerbeli összeadásnál). Több bites számok (pl. két bájt) összeadásánál először a legkisebb helyi értékű biteket kell összeadni, majd sorra a nagyobb értékűeket, mindig hozzáadva az összeadandó bitekhez az előző összeadás átvitelét is. Magától értetődő, hogy - ha az összeg nagyobb 255-nél - a legmagasabb helyi értékű bitekről is keletkezhet átvitel. Valójában tehát a 8 bites számok összeadásához szükség van még egy 9. bitre is, amely az esetleges átvitelt, a túlcsordulást jelzi. Mint látni fogjuk, a processzor rendelkezik is ilyen bittel.

kivonás x = a - b
A kivonás az első problematikus művelet. A nehézségét az adja, hogy az eredmény negatív is lehet, ami nem illik bele a számábrázolás eddigi rendszerébe. Ha szükség van a negatív számok kezelésére is - márpedig ez a számítógép alkalmazások legtöbbjében elengedhetetlen -, meg kell egyezni a negatív értékek ábrázolásának módjában.
A Z80-as mikroprocesszornál választott megoldás az ún. kettes komplemens ábrázolás: az egybájtos számok tartományában a -b érték helyett a 256-b értéket tárolja és használja a rendszer. Ez már újra egy bájton ábrázolható pozitív érték. Az így megadható számok értéke -128, és +127 között lehet:

Ez a megoldás több szempontból praktikus:

• a szám előjele az első bit (MSB) alapján egyszerűen megállapítható (ha ez 1, azaz a tárolt érték nagyobb mint 127, a szám negatív);
• a műveletek következetesen alkalmazhatók:
  07H - 07H = 04H helyett 07H + FDH = 104H
  az egy bájton kapott 04H érték a helyes végeredmény;
• a kettes komplemens értéket egyszerűen megkaphatjuk a szám invertálásával (ez az 1-es komplemens) + 1 hozzáadásával:
  (-b) tárolt értéke: 256 - b = b + 1.

Most már csak az a kérdés, hogy ha pl. egy memóriacímről FEH értéket olvasunk be, honnan tudjuk, hogy ezt 254-nek vagy -2-nek kell-e tekintenünk. Ha tömören akarunk válaszolni, azt mondhatnánk, hogy sehonnan. Valójában ezt csak az érték előélete szabhatja meg. Lényegében mi döntjük el, hogy egy művelet operandusait és eredményét előjeles számoknak vagy egybájtos pozitív egészeknek tekintjük-e. A processzor mindkét értéktartományt egyformán kezeli, figyeli és jelzi mindkét esetre a határátlépéseket (átvitel, túlcsordulás), lehetőséget adva ezzel a tetszés szerinti kiértékelésre. Az elmondottakból logikusan következik, hogy ha kétbájtos értékek esetén akarunk előjeles számokat ábrázolni, -nn helyett ennek kettes komplemense (65 536 - nn) a megadandó érték (így -32 768 és 32 767 közötti számokat ábrázolhatunk).
Az eddigiek szerint a memóriaterület egy-egy címén tárolt egybájtos adat jelenthet 0 és 255 közötti egész értéket, vagy -128 és +127 közötti előjeles számot. Ezenkívül a rendszer még két kódolási formát alkalmaz az adatok tárolásánál, feldolgozásánál.

A tízes számrendszerbeli számok ábrázolására az ENTERPRISE általában az ún. BCD-kódrendszert alkalmazza (Binary Coded Decimal = binárisan kódolt decimális). Ennek lényege, hogy a tárolt érték hexadecimális alakja magukat a számjegyeket adja meg (a két hexadecimális karakter két számjegyet):

Ez a kódolási forma tehát csak annyiban tér el a már megismert hexadecimálistól, hogy tiltja annak A-F karaktereit. Így a lehetséges 256 különböző érték helyett egy memóriacímen csak 100-féle értéket tárolhatunk (0-99), de a memóriapazarlásért kárpótol minket az aritmetikai műveletek, a kijelzés egyszerűsége, sebessége, pontossága.
A következő program egy, az operációs rendszer által BCD-ben kezelt értéket olvas és ír ki folyamatosan: az óra másodperc értékét. A decimális alakon jól láthatók a BCD logika ugrásai (a tiltott állapotok átlépései), a hexadecimális kiírás viszont tökéletesen követhető:

1 PROGRAM "BCD.bas"
100 DEF H$(N)=CHR$(INT(N/16)+48-7*(INT(N/16)>9))&CHR$(MOD(N,16)+48-7*(MOD(N,16)>9))
110 LET CIMSEC=49010
120 TEXT
130 DO
140   LET SEC=SPEEK(255,CIMSEC)
150   PRINT AT 1,1:SEC,H$(SEC)
160 LOOP

A szövegek, karakterek tárolásának alapja az ENTERPRISE-on az ASCII kódrendszer. Itt egy bájton egyetlen karaktert tárolunk, pontosabban annak kódját. Az alfanumerikus jegyek (számjegyek, matematikai jelek, az angol ABC betűi) nemzetközi szabvány szerinti kódjait (pl. A kódja 41H = 65Dec) az ENTERPRISE speciális karaktereinek kódjai egészítik ki. A kódokhoz tartozó karakterek kísérletként közvetlenül is megjeleníthetők a képernyő legfelső sorában. (az állapotsorban) a programfutás idejére (leállás után a BASIC rendszer felülírja ezt a területet):

100 LET CIM=48830
110 LET K=64
120 FOR I=0 TO 31
130   POKE CIM+I,K+I
140 NEXT
150 GOTO 150

Próbálja ki a rutint különböző K kezdőértékekkel! A kódokhoz rendelt karaktereket az 1. függelék is tartalmazza.

Az általános fogalmak összefoglalása után nézzük meg, hogy maga a Z80-as mikroprocesszor milyen feltételeket biztosít a gépi kódú programozáshoz.
Bár a processzor működésének lényege a külső memóriacímek olvasása, tartalmuk átírása, módosítása, de ennek segítésére jó néhány belső memóriarekesze (ún. regisztere) is van. Ezek a regiszterek általában 8-bitesek, de egy részüket párban - mint 16-bites regisztert - is képes használni a processzor.

Regiszterek:
A 8-bites aritmetikai és logikai műveletek alapja az A-regiszter, az ún. akkumulátor. Ebbe kell tölteni a műveletek előtt az (egyik) operandust és ez tartalmazza a művelet eredményét.

A flagregiszter (F) a művelet eredményére jellemző egybites információkat tartalmaz. Hat értékes bitje:

• BIT 0: C (Carry = átvitel) -értéke 1, ha az elvégzett művelet során átvitel keletkezett a 8. bitről a 9-re és fordítva (pl. A0H + B0H után).
• BIT 1: N (kivonásjelző) -belső használatú bit; az elvégzett művelet típusát jelzi.
• BIT 2: P/V (paritás vagy túlcsordulás)
  -logikai műveletek után: az akkumulátor paritását jelzi (0, ha A-ban páros számú bit 1-es),
  -aritmetikai műveletek után: a kettes komplemens számábrázolási tartományátlépését jelzi (a 7. bitről a 8-ra és fordítva).
• BIT 4: H (Half-Carry = fél-átvitel) -ugyancsak belső használatú bit az alsó 4 bitről keletkezett átvitel jelzésére; a BCD számábrázolási módban az értékek korrekciójához használja a processzor.
• BIT 6: Z (Zero) -értéke 1, ha a művelet eredménye 0.
• BIT 7: S (Sign, előjel) -értéke 1, ha a művelet eredménye negatív (a kettes és egyes komplemens ábrázolási logikában ez tulajdonképpen az eredmény 7. bitjének másolata).

• A bitek a művelet eredményét, és nem az akkumulátor értékét tükrözik (pl. az összehasonlító utasításban (1. CP) az akkumulátor értéke nem változik, de a státusz lehet Z, C stb.).
• Sok művelet nem változtatja meg a jelzőbiteket (vagy nem mindegyiket). A ROM-programokban is gyakran látunk majd olyan esetet, hogy egy művelet után egy jóval későbbi utasítás kérdez rá a művelet eredményére.

A regiszterkészlet további elemei:

• Általános célú regiszterek: B, C, D, E, H és L. Ezek mint BC, DE és HL regiszterpárok is használhatók. Az univerzális felhasználhatóság mellett a B, C regisztereknek számlálóként lesz külön jelentőségük (ciklusok), míg a HL regiszterpárt sok utósítás használja 16-bites akkumulátorként, ill. a külső memória megcímzésére, a cím H (felső) és L (alsó) bájtjának megadására. Az A és F, valamint a B, C, D, E, H, L regiszterekből még egy teljes készlete van a processzornak; ezek a háttérregiszterek (AF', B'-L'), amelyek teljesen egyenértékűek az elsődleges megfelelőikkel és egyetlen utasítással kicserélhetők azokkal (1. EX AF, AF ill. EXX utasítások). A processzor mindig az éppen "előtérbe hozott" regiszterekkel dolgozik.
• A IX és IY 16-bites indexregiszterek elsősorban a memória (pontosabban egy 256 bájtnyi memóriaintervallum) címzésére használhatók. Megjegyezzük, hogy (bár ez általában nem szerepel a leírásokban) az indexregiszterek alsó, ill. felső 8 bitje - az L, ill. H regiszterekre vonatkozó adatmozgató, logikai és aritmetikai utasítások kiterjesztéseként - külön is használható. Az IX és IY regiszterek - HL kiterjesztéseként - 16-bites akkumulátorként is használhatók.
• A veremmutató (SP = Stack-Pointer) ugyancsak 16-bites és egy külső RAM-területre kell mutatnia. Ez a terület, az ún. verem igen jól használható nagyobb regiszterigény esetén a belső regiszterek külső memóriába mentésére (l. PUSH és POP utasítások). A processzor szubrutinok hívása esetén itt tárolja a visszatérési címet. Az SP regiszterpár mindig a használható veremterület fölé (az utoljára letárolt érték alsó bájtjára) mutat. Értékét a processzor automatikusan beállítja a veremműveleteknél.

A további regiszterekkel nekünk közvetlenül nemigen lesz dolgunk. Csak felsorolásszerűen:

• a programszámláló (PC = Program Counter) 16-bites, mindig a végrehajtandó utasításra mutat. Ennek értékét módosítják az ugróutasítások (CALL, JP, JR, RST, DJNZ, RET).
• Interrupt regiszter (I) 8-bites, csak IM2-es módban használatos.
• Frissítő regiszter (R = Refresh regiszter). 7 bites; értéke minden utasítás beolvasása után 1-gyel nő. A hardver rendszer a memóriaterület folyamatos pásztázására (és ezzel szüntelen frissítésére) használja. Mivel egy gyorsan pörgő érték, akár véletlenszám generálásához is felhasználható.

Az utasítások áttekintése előtt (a bemutatandó példák érdekében) nézzük meg, hogy miként lehet egyáltalán az ENTERPRISE-on gépi kódú rutinokat betölteni és futtatni. Itt - éppen az egyszerűség érdekében - a BASIC rendszeren belül maradunk.
A program tárolásának, a kódok memóriába töltésének viszonylag kényelmes eszköze a CODE utasítás. Ez egy füzér (string) karaktereit helyezi el a memóriában. A tárolás kezdőcímét a 021C/DH BASIC rendszerváltozó tartalmazza. Ez alaphelyzetben a BASIC munkaterület kezdete. Óvatosan kell tehát bánni az utasítással, hiszen a BASIC program elejét felülírhatjuk vele. Ezt akadályozza meg egy a program elején kiadott ALLOCATE n utasítás, ami n bájttal hátracsúsztatja a programot, helyet csinálva a gépi kódú rutinunknak. Az utasítás törli a változókat, tehát valóban a program elején praktikus kiadni. A lefoglalt hellyel nem érdemes különösebben takarékoskodni. Az összecsúszás veszélye miatt, a bővítések, alakítások érdekében mindig lefoglalunk legalább 100 bájtot (ezért ne is csodálkozzon az Olvasó, ha egy néhány bájtos rutin előtt ALLOCATE 100 utasítást lát).
A 021C/DH rendszerváltozó (decimálisan 540/1) közvetlen átírásával a tárolási cím máshová is állítható. Például:

POKE 540,0
POKE 541,48

utasítások után a következő CODE már -a 3000H (12288Dec) címtől tárolja a bájtokat. Ezt is használjuk, ha pl. rögzített címén lévő adatmezőre vagy rutinra van szükség. Ez azért is fontos lehet, mert a rendeltetésszerűen elhelyezett gépi kódú rutin nincs teljes biztonságban a BASIC munkaterület kezdetén: a program szerkesztéskor visszacsúszhat erre a területre, felülírva a rutint. Ez nyilván megengedhetetlen egy olyan gépi kódú program esetén, amit az operációs rendszer hív a BASIC-tő1 függetlenül (pl. megszakításkezelő).
A példaként írt 3000H kezdőcím praktikus, mert külön védelem nélkül is viszonylag biztonságban van a BASIC terület közepén (de csak ha nem használunk nagy memóriaigényű 0-s BASIC programot).
A 0-16 383 címtartományban (nulláslap) kisebb szabad területet találhatunk még a 0180H címtől (ha BASIC-ben maradunk, 128 bájt) vagy néhány bájtot a memória legelején is (0000-0004). A programok elhelyezésére - legalábbis az egyszerűbb esetekben - használjuk ezt a nulláslapot, hiszen a memóriakonfiguráció további tartományairól nincs mindig biztos információnk (l. pl. 2. fejezet).
A CODE utasítás - mint írtuk - egy füzért vár operandusként

CODE = karakterkifejezés

alakban. Például a

CODE=CHR$(6) &"VIDEO:"

utasítás a szöveg hosszát, majd karaktereit helyezi el az aktuális tárolási címtől a memóriában (így várja ezt pl. a csatorna megnyitáskor a rendszer).
Sokat egyszerűsít a beírás munkáján a HEX$ függvény, amely az argumentumában megadott (vesszővel elválasztott) hexadecimális értékeket alakítja bináris számokká és fűzi karaktersorozatba.

CODE = HEX$ ("21,00,00,C9")

utasítás végrehajtása után pl. a 33,0,0,201 (decimális) értékeket találjuk a memóriában. Ha egy változónevet is megadunk a CODE után, az értelmező a változóba tölti a füzér aktuális tárolási címét. Esetünkben pl.:

ALLOCATE 3
ok
CODE M1=HEX$("01,02")
ok
CODE M2=HEX$("03")
ok
PRINT M1,M2
4827 4829
ok

Praktikus ezt a lehetőséget kihasználni, hiszen gyakran szükség lehet a rutinok, adatmezők kezdőcímére (pl. szubrutinhívásnál). A kezdőcímek felhasználását is támogatja az értelmező a WORD$ függvénnyel: ez az argumentumot (0-65 535 közötti érték) alakítja kétbájtos egésszé

A$=WORD$(12288)
ok
PRINT LEN(A$)
2
ok
PRINT ORD(A$(1:1)),ORD(A$(2:2))
0 48
ok

Mint a megadott esetben (3000H) is látható, a füzérben elöl az alsó bájt áll (0) azt követi a felső bájt (48Dec = 30H). Ez a forma - mint látni fogjuk - általános a gépi kódú programokban a címek megadására. A memóriában elhelyezett gépi kódú program futtatására a USR függvény alkalmas. Hívható pl.:

CALL USR(cím,hl)

alakban, de alkalmazható akár

PRINT 12*USR(cím,hl)+5

formában is. Az argumentumba természetesen a rutin kezdőcímét kell írni, valamint egy 0-65 535 közötti paramétert. Az értelmező a cím meghívása előtt a paraméter értékét (hl) a processzor HL regiszterébe tölti. Ezt felhasználhatjuk bemenő adatként rutinunkban. Ugyanígy vissza is adhatunk egy értéket (HL-ben) az értelmezőnek, amit az majd függvényértéknek tekint. A meghívott rutint "RET' utasítással kell zárnunk (C9H kód). Ennek hatására tér vissza a vezérlés a BASIC értelmezőhöz. A BASIC a visszaadott értéket előjeles kettes komplemens számnak tekinti. Jó tudni még azt is, hogy a felhasználói rutin meghívásakor a 3. lapra (a 0000H-FFFH tartományba) az 1. ROM-szegmens van lapozva (erről bővebben írunk a 2. fejezetben), tehát a megadott tartományban ennek a szegmensnek a rutinjait, adatait találjuk.

1.2 Az utasításkészlet

A Z80-as mikroprocesszor több száz utasítást különböztet meg és hajt végre. Ez csak úgy lehetséges, hogy a gyakori, egyszerű utasítások egybájtos kódjai mellett több-bájtos utasításkódok is vannak. Hogy ne vesszünk el ebben a kódtengerben, most általában nem is foglalkozunk az utasítások-kódjaival (ezt az 1. és 2. Függelék táblázataiban megtalálja az Olvasó). Bár a gépi kódú program valójában kódok egymásutánját jelenti, mi az áttekinthetőség érdekében egyszerű, a funkcióra utaló néhány betűs neveket adunk meg: a, gépi kódú programozás assembly nyelvének ún. mnemonikjait. A kódokkal való megadást mindenhol példaszerűen tekintjük át. Ebben a fejezetben minden kódot és operandust hexadecimális alakban adunk meg, ezért ezt most külön nem jelöljük.

1.2.1 Adatmozgató és -cserélő utasítások

A processzor talán legalapvetőbb utasítástípusa nagy területet ölel fel. A regisztereket konstanssal (vagy egy másik regiszter tartalmával) feltöltő utasítások a BASIC "LET" parancsával analógak (LET A = n, LET A = B stb.). Ugyanakkor a külső memóriát célzó adatmozgató utasításokban találhatjuk a "POKE" és "PEEK" analógiáit.

8 bites adatmozgatás - (LOAD)
Egy regisztert vagy memóriacímet tölt fel egy bájttal. Az érték forrása változatlan marad. A forrás és a cél igen sokféle lehet. Tekintsük át az első utasításnál részletesen a megadható módokat, hiszen ezzel ismerhetjük meg a processzor címzésmódjait. Először azokat az utasítástípusokat vegyük sorra, amelyek a A regiszterbe töltenek egy bájtot:

Az előbbiekkel analóg módon fordított irányú adatmozgatást is kérhetünk:

LD B,A
LD (nn),A
LD (HL),A
LD (IX+d),A

Ezekkel az utasításokkal természetesen az A regiszter tartalmát tölthetjük a célregiszterbe, ill. a memóriacímre. A következő táblázat összefoglalja a 8-bites LD utasítás lehetséges (x) címzésmódjait:

Valamint

LD A,I
LD A,R
LD I,A
LD I,R

Fontos hangsúlyozni, hogy a LD utasítások nem változtatják meg az F regiszter bitjeit, kivéve a LD A,I és LD A,R utasításokat. Attól tehát, hogy kiadunk egy
LD A,00
utasítást, még nem lesz Z a státusz.
Nézzünk egy-két elemi példát az utasítások alkalmazására. Egyelőre írjuk a mnemonikok mellé az utasítások kódjait is:

Ez a rutin áttölti a HL regiszterpár alsó bájtját a felsőbe, tehát tulajdonképpen 256-tal szorozza azt. BASIC programban betöltve és futtatva:

100 ALLOCATE 100
110 CODE M1=HEX$("65,2E,00,C9")
120 DO
130   INPUT PROMPT "L=? ":L
140   PRINT USR (M1,L)
150 LOOP

START
L=? 1
256
L=? 2
512
L=; 100
25600
L=? 128
-32768

A 2. rutin a HL-ben megadott címről olvas be egy bájtot és ezt adja vissza a BASIC-nek (tehát tulajdonképpen a BASIC "PEEK" utasítását hajtja végre):

100 ALLOCATE 100
110 CODE M2=HEX$("7E,6F,26,00,C9")
120 DO
120   INPUT PROMPT "CIM=? ":CIM
130   LET A=USR(M2,CIM)
140   PRINT "GEPI:";A,"PEEK:":PEEK(CIM)
150 LOOP

START
CIM=? 512
GEPI: 163 PEEK: 163
CIM=? 0
GEPI: 0 PEEK: 0
CIM=? 49152
GEPI: 178 PEEK: 178

16-bites adatmozgató utasítások
A kétbájtos adatátvitel a regiszterpárok tartalmát együtt mozgatja. Mnemonikja ugyancsak LD. Típusai:

Itt is foglaljuk össze táblázatosan a megengedett címzésmódokat:

A 16-bites adatmozgató utasítások közé tartozik két különleges csoport: a PUSH és a POP utasítás. Az utasítások célja egy regiszterpár taralmának külső memóriába (a verembe) töltése, ill. visszaolvasása onnan. Specialitásuk abban áll, hogy a külső memóriára mutató regiszterpár (SP) értéke automatikusan állítódik minden művelet után:

A verem tehát egy olyan tárterület, amelyet felülről lefelé vesz igénybe a processzor, miközben az SP veremmutató mindig a szabad terület fölé mutat.
Amellett, hogy a processzor számára más műveletnél (szubrutinhívások) nélkülözhetetlen a verem, a most megismert utasításokkal is igen jól használható:

• regisztertartalmak tárolására (pl. egy olyan rutin előtt, amely maga is használja a regisztereket)
• regiszterpácok cseréjére, csak így lehet pl. hozzájutni az F regiszter teljes tartalmához (p. a
  PUSH AF
  POP HL
  utasítások után F tartalma L-be kerül

A PUSH és POP utasítások az AF, BC, DE, HL, IX, IY regiszterpárokra alkalmazhatók.
A processzor státuszát (F) a 16-bites adatmozgató utasítások egyike sem változtatja meg.

Először itt is nézzünk két igen egyszerű példát az utasítások alkalmazására. Az M3 rutin a képernyő első sorának tárolási címét olvassa be a sorparaméter táblából.

A cím felhasználható közvetlen képernyőíráshoz. Ehhez előbb a VIDEO cím tartománya alapján meg kell határoznunk a tárolószegmens számát (erről pl. a 2.1 alfejezetben lesz bővebben szó). Az utolsó sor a bal felső sarokba ír egy A betűt:

100 ALLOCATE 100
110 CODE M3=HEX$("2A,14,B9,C9")
120 TEXT 40
130 PRINT
140 LET VID_C=USR(M3,0)
150 IF VID_C<0 THEN LET VID_C=65536+VID_C
160 PRINT "Video-cim: ";VID_C
170 LET SGM=252+INT(VID_C/16384)
180 SPOKE SGM,VID_C,65

A második rutin felhasználásával lekérdezhetjük az állapotsor tetszőleges karakterét. Ehhez az IX indexregisztert is felhasználjuk, tehát gondoskodnunk kell a regiszter BASIC-beli értékének tárolásáról, majd visszaállításáról:

A BASIC program a gépi rutin a LD L,(IX+0) utasításába, az index helyére írja be a kiolvasandó karakter sorszámát. Így a futtatáskor ezen a részen mindig a konkrét indexérték (az indexregiszterbe töltött báziscímhez képest relatív eltolás) lesz (pl. LD L,(IX+2)). A program a visszakapott kódot - a színinformáció letakarása után - karakterként ki is írja.

100 ALLOCATE 100
110 CODE M4=HEX$("DD,E5,DD,21,BE,BE,DD,6E,00,DD,E1,C9")
120 DO
130   INPUT PROMPT "Hanyadik karaktert olvassam? ":D
140   POKE M4+8,D
150   LET C$=CHR$(USR(M4,0) BAND 127)
160   PRINT D;". karakter: ";C$
170   PRINT
180 LOOP

START
Hanyadik karaktert olvassam? 0
0 - karakter: I

Hanyadik karaktert olvassam? 1
1 . karakter: S

Hanyadik karaktert olvassam? 23
23 . karakter: 0

Hanyadik karaktert olvassam? -6
-6 . karakter: C

Az indexregiszter a megadott értékkel az állapotsor "IS-BASIC ..." szövegének első karakterére mutat, így adódnak a kiolvasott karakterek. A (-6) érték a futtatáskor éppen érvényes CAPS üzemmód-szöveg C karakterét adta vissza.
Az előző rutinokat tulajdonképpen csak a kódbeírás, paraméterátadás, rutinmeghívás bemutatására szántuk. Ezek még nem végeztek olyan feladatot, amit BASIC-ben meg ne tudtunk volna oldani. Írjunk most egy olyan rutint a megismert utasítások alkalmazásával, amelyet jól tudunk majd használni a gépi kódú utasítások funkcióinak, sajátosságainak bemutatásához, megértéséhez.
A gépi kódú programozás egyik - sokakat távoltartó - problémája a folyamatok követhetetlensége. Egy jó segédprogram (monitor) egyik legfőbb szolgáltatása éppen az, hogy lépésenként tudjuk az egyes utasítások regiszterekre és jelzőbitekre való hatását követni. Lényegében arról van szó, hogy bármely utasítás után ki tudjuk íratni a (számunkra érdekes) regiszterek tartalmát.
Ezt gyári monitorprogram nélkül, saját rutin segítségével is megoldhatjuk. Írjunk egy olyan befejezést későbbi programrészleteinkhez, amely a regiszterek tartalmát a memória rögzített helyére tölti. Innen majd BASIC-ben kiolvashatjuk és kiírhatjuk a minket érdeklő paramétereket, jelzőket. A feladatot legegyszerűbben a veremműveletek segítségével oldhatjuk meg. Nem szabad megfeledkeznünk arról, hogy a rutin befejezése előtt visszaállítsuk az SP veremmutató eredeti tartalmát:

Természetesen SP visszaolvasása előtt szükség esetén más regisztereket is kivihetünk (pl. PUSH IX). A rutin futtatása után a memóriaterületről kiolvashatjuk a Z80-as regiszterek visszatérés előtti tartalmát:

A vizsgálandó rutin előtt praktikus a flagregisztert is törölni (így egyértelmű a vizsgált szakasz hatása). Erre egy lehetséges megoldás:

Itt egy 0-val feltöltött regiszterpár tartalmát írjuk át a verem közvetítésével AF-be.
A betöltő BASIC program tartalmazza az előkészítő (250. sor) és a befejező programszakaszokat (270. sor). Mivel a CODE utasítás folyamatosan tárolja a bájtokat a memóriában, a program így is életképes, de valódi haszna a két szakasz közé, a 260. sorba beírt utasítás- vagy rutinrészlet tesztelésében van. A program végrehajtó része a státusz könnyebb kiértékelése érdekében bitekre bontja a flagregisztert (szükség esetén ezt a többi regiszterrel is megtehetjük). A már ismert decimális-bináris átalakító rutint kissé módosítottuk, hogy az F regiszter határozatlan bitjei helyett egy-egy pont jelenjen csak meg. A további regisztereket - jelen formában - hexadecimális alakban írja ki a program.
Például a LD DE, 3322 (11,22,33) utasítás hatása:
Az A, F, B, és C regiszter az előkészítő szakaszban töltődik fel 0-val, H és L értéke a CALL USR (M,0) hívás paramétere (0), a D = 33H, C = 22H értékek pedig a tesztelt utasítás eredményei.

1 PROGRAM "Register.bas"
100 ALLOCATE 100
110 DEF H$(N)=CHR$(INT(N/16)+48-7*(INT(N/16)>9))&CHR$(MOD(N,16)+48-7*(MOD(N,16)>9))
120 DEF BIN$(X)
130   LET B$=""
140   LET B=128
150   FOR N=0 TO 7
160     LET BN=INT(X/B)
170     IF N<>2 AND N<>4 THEN LET B$=B$&STR$(BN)
180     IF N=2 OR N=4 THEN LET B$=B$&"."
190     LET X=X+B*(BN=1)
200     LET B=B/2
210   NEXT
220   LET BIN$=B$
230 END DEF
240 !
250 CODE M=HEX$("01,00,00,c5,f1")
260 !
270 CODE VEGE= HEX$("ed,73,90,01,31,90,01,f5,c5,d5,e5,ed,7b,90,01,c9")
280 !
290 CALL USR(M,0)
300 LET F=PEEK(398)
310 PRINT ,,"SZ,H,PNC"
320 PRINT " F:";,,BIN$(F)
330 PRINT " A=";H$(PEEK(399))
340 PRINT "B,C=";H$(PEEK(397));",";H$(PEEK(396))
350 PRINT "D,E=";H$(PEEK(395));",";H$(PEEK(394))
360 PRINT "H,L=";H$(PEEK(393));",";H$(PEEK(392))

Adatcserélő utasítások
16-bites regiszterpárok tartalmát cserélik meg egyetlen utasítással.

A regisztercserék után a processzor az eddigi háttérregiszterekkel dolgozik, míg az eredeti regiszterek értéke megőrződik a háttérben.

Blokkmozgató utasítások
A Z80-as mikroprocesszor talán leghatékonyabb utasításai a blokkutasítások. A gépi kódú programozásban gyakori feladat egy kisebb-nagyobb memóriaterület feltöltése egy rögzített adatterületről vagy egy adott bájttal. A Z80-as processzornál ezt egyetlen utasítással is elérhetjük.

A blokkmozgató utasításoknál HL mindig a forrás, a DE a cél címe, BC pedig az átviendő bájtok számát adja meg.
A mnemonikok betűjelei a funkciókra diainak:

• I: Increment - növelés
• D: Decrement - csökkentés
• R: Repeat - ismétlés

Az F regiszter jelzőbitjeit a négy utasítás azonos módon állítja:

• az N és a H bit törlődik,
• a P/V bit itt egy speciális jelentést kap: akkor válik 0-vá, ha BC értéke 0 lett a végrehajtáskor (ez az LDIR, LDDR utasításoknál mindig így van)
• a többi bit változatlan.

Alkalmazási példaként vigyük át az 1. szegmens E70FH címén kezdődő üzenet szövegét az állapotsorba (a BEBEH címtől). A szöveg ("1985 Intelligent Software Ltd") hossza 29 (1DH).

A rutint illesszük be az előzőekben megismert regiszterkiírató programba és úgy futtassuk le:

260 CODE M=HEX$("21,0F,E7,11,BE,BE,01,1D,00,ED,B0")

(A programot célszerű végtelen ciklusban tartani, pl. egy 370 GOTO 370 sorral, hogy ne íródjon felül az állapotsor.)
A futtatás után természetesen
BC = 0
DE = BEDB = BEBE + 1D
HL = E72C = E70F + 1D

A forrás- és célmutató (HL, ill. DE) az átvitt, ill. feltöltött terület utáni bájtra mutat, tehát szükség esetén folytatható az átvitel, esetleg más területre (vagy területről).
Az LDIR és LDDR utasítások különbsége akkor válik lényegessé, ha a forrásterület és a feltöltendő blokk átlapolódik (van közös területük). Ekkor ui. előfordulhat, hogy az utasítás "beleír" a forrásterületbe. Hogy ezt elkerüljük:

• ha DE < HL, az LDIR utasítást alkalmazzuk,
• ha DE > HL, válasszuk az átvitelre az LDDR-t.

Ezt természetesen nem kötelező alkalmazni. Ha pl. egy terület adott bájttal való feltöltése a célunk, nagyon is jól jön ez a tulajdonság: a karaktert csak az első címre kell betöltenünk, és DE = HL + 1 választással az LDIR ezt a karaktert töltögeti végig a blokkba:

Az állapotsor elejére a * karakter ASCII kódját (2AH) töltjük. A még ismeretlen INC DE utasítás a DE = DE + 1 műveletet végzi el.

260 CODE M=HEX$("21,BE,BE,36,2A,E5,D1,13,01,1D,00,ED,B0")

1.2.2 Logikai utasítások
A logikai alapműveleteket végzik el az akkumulátor és egy másik 8-bites adat (regiszter- vagy memóriatartalom) bitjei között. Az eredmény az A regiszterben képződik.

A megengedett címzésmódok:

Értelmes tehát pL. az OR (HL), de nem létező az OR(nn) utasítás. A logikai utasítások hatása a jelzőbitekre:

• a C és N bit törlődik (0);
• a H bit
  • AND után 1-be áll,
  • OR és XOR után törlődik;
• az S és a Z bit az A művelet utáni értékének megfelelően áll be:
  • Z = 1, ha A=0,
  • S = 1, ha A >= 80H.

A logikai utasítások egyik gyakori alkalmazási területe a grafika. Például a HL címen lévő bájt bitjei felelnek meg a képpontoknak. Ekkor:

Az AND utasítást jól használhatjuk egy adat minket érdeklő bitjeinek kiemelésére, maszkolására, az OR A utasítást igen gyakran alkalmazzák a ROM-rutinok, általában csak az átvitelbit (C) törlését várva tőle, a XOR A utasítás a legegyszerűbb módja az A = 0 értékadásnak stb.

1.2.3 Aritmetikai utasítások

8-bites utasítások
A Z80-as processzor az összeadást és a kivonást tudja elvégezni. A művelet egyik operandusa mindig az A-regiszter. Az eredmény is az akkumulátorban képződik. Típusai (ugyancsak a B operandus példáján):

A lehetséges operandusok mind a négy utasításra:

A műveletek akkumulátorban keletkező egybájtos eredménye mellett fontos a jelzőbitek figyelembevétele is:

• C = 1, ha az eredmény túllépett az ábrázolási tartomány határán, azaz
  összeadásnál: ha A + x > 255
  kivonásnál: ha A - x < 0
• P/V: az aritmetikai műveleteknél túlcsordulás-jelzőként viselkedik (V), azaz V = 1, ha a kettes komplemens számábrázolási tartományból (-128 <= x <= 127) kiesd eredmény keletkezett
• Z = 1, ha a művelet után A = 0
• S = 1, ha a művelet után A >= 80H, azaz (kettes komplemens ábrázolásnál) negatív
• N = 0, ha összeadás történt (ADD, ADC)
  N = 1, ha kivonást hajtottunk végre (SUB, SBC)
• H = 1, ha a BCD számábrázolási tartományban történt túlcsordulás (ezt az információt a DAA korrekciós utasítás veszi figyelembe)

Érdemes egy kicsit gyakorolni a regiszterkiírató programunkkal az aritmetikai műveleteket, hatásukat a jelzőbitekre. Például:

Csak az érintett regisztereket íratva ki:

260 CODE M$=HEX$("3E,40,C6,50")
F : 10,0,100
A=90

Az eredmény 40H + 50H = 90H helyes, ha pozitív egészeknek tekintjük az értékeket (C = 0), de hibás (P = 1, itt helyesebb lenne V = 1-et írni), ha előjeles számokként értelmezzük az operandusokat és az eredményt, hiszen
40H + 50H <> -70H
Ugyanakkor A = 40H, n = E0H esetén

260 CODE M$=HEX$("3E,40,C6,E0")
F : 10,0,001
A=20

Az eredmény tehát hibás (C = 1) pozitív számábrázolásnál, hiszen
40H + E0H = 120H <> 20H
de helyes (P/V = 0) előjeles számábrázolásnál, hiszen
40H + (-20H) = 20H

Speciális aritmetikai utasításnak tekinthető az összehasonlító utasítás (CP), amely a SUB utasítással azonos módon állítja be a jelzőbiteket, de az eredményt nem tárolja (az akkumulátor változatlan marad). Például:

A jelzőbitek:

• P/V = 0, ha BC = 0 kilépéskor (blokk végéig ért)
• Z = 1, ha A = (HL) volt
• S és H a CP művelet eredményének megfelelő
• N = 1
• C változatlan

A CP utasítások leggyakrabban a feltételes elágazások kérdései (IF A = N...).
Igen praktikus, hogy a processzor képes az operandusok közvetlen (akkumulátortól független) növelésére és csökkentésére. Például:

Az operandusok köre megegyezik az aritmetikai utasítások címzésmódjaival, kivéve a nyilván értelmetlen INC n típust:

A jelzőbitek:

• fontos (és talán kissé ellentmondásos is), hogy az INC, DEC utasítások nem változtatják az átvitelbitet (C-t),
• az S, Z, H, P/V bitek értéke a művelet eredményének megfelelően áll be,
• N = 0 INC esetén
  N = 1 DEC esetén,

A két utasítás elsősorban számlálásra, ciklusszervezésre használható.

16-bites aritmetikai utasítások
A Z80-as processzor kétbájtos operandusokon is képes az elemi aritmetikai műveletek elvégzésére. Ilyenkor az alsó bájtról keletkező átvitelt automatikusan figyelembe veszi a felső bájtok összeadásánál, kivonásánál. A művelet egyik operandusa mindig a HL regiszterpár (ill. ennek kiterjesztéseként az ADD utasításnál IX vagy IY) és az eredményt is az első operandusban kapjuk. Típusai:

Címzésmódjai:

Az utasítások hatása a jelzőbitekre:

• ADD
  • C = 1, ha az eredmény átlépett a kétbájtos tartomány határán (HL + xx > FFFFH);
  • N = 0, H határozatlan;
  • a többi jelzőbit változatlan.
• ADC és SBC
  • C = 1, ha HL + xx > FFFFH
    vagy HL - xx < 0000H;
  • P/V: túlcsordulásjelző, a kétbájtos előjeles kettes komponens számábrázolási tartomány (-32768 <= x <= 32 767) határának átlépését jelzi;
  • S: előjelbit: S = 1, ha HL >= 8000H (azaz előjeles számnak tekintve negatív);
  • Z = 1, ha az összeg 0;
  • N = 0 összeadásnál (ADC);
    N = 1 kivonásnál (SBC);
  • H: határozatlan.

Itt is nézzünk meg egy-két esetet. Például:

Általában a C-bit törléséről is gondoskodni kell az ADC utasítás előtt (ha nem éppen az, átvitel figyelembevétele a célunk), pL. egy OR A utasítással. Itt ezt elhagyhattuk, a bevezető szakasz törölte az átvitelbitet. Az adott értékekkel:

260 CODE M=HEX$("21,E0,7F,11,40,00,ED,5A")
F: 10,1,100
A=00
B,C=00,00
D,E=00,40
H,L=80,20

Itt is mi dönthetjük el, hogy milyen számábrázolási tartományban dolgozunk és ennek megfelelően helyes-e az eredmény, történt-e átvitel. Kétbájtos pozitív egészként az eredmény elfogadható, hiszen C = 0,
7FE0H + 0040H = 8020H
Előjeles számnak tekintve azonban már hibás az eredmény, hiszen
7FE0H + 0040H <> 7FE0H
Ezt a P/V = 1 érték jelzi.

HL = FFE0H és DE = 0040H értékekkel viszont:

260 CODE M=HEX$("21,E0,FF,11,40,00,ED,5A")
F: 00.1.001
A=00
B,C=00,00
D,E=00,40
H,L=00,20

Itt átvitel keletkezett (C = 1), tehát pozitív egészként az eredmény hibás:
FFE0H + 0040H = 10020H <> 0020H
A P/V = 0 érték viszont azt jelzi, hogy az előjeles számok tartományában helyes a művelet eredménye:
(-0020H) + 0040H = 0020H

A természetes aritmetikai alkalmazásokon kívül a fenti utasítások alkalmasak pl. két regiszterpár értékének összehasonlítására is. Például az
OR A
SBC HL,DE
ADD HL,DE
utasítások elvégzése után a regisztertartalmak változatlanok, de az átvitelbit:
C = 1, ha DE > HL
C = 0, ha DE<-HL

A processzor a 16-bites regiszterpárokon is képes az inkrementálás (növelés) és dekrementálás (csökkentés) elvégzésére. Például:
INC BC: BC = BC + 1
DEC BC: BC = BC - 1
A lehetséges operandusok a két műveletre:

A jelzőbiteket a 16-bites INC és DEC utasítások nem változtatják (nincs tehát átvitel (carry) az FFFFH-0000H átlépésnél sem!).

Kiegészítő, általános célú utasítások

Például a
LD A,08
ADD A,04
utasítások után az akkumulátorban a binárisan elvégzett összeadás eredménye van (0C)
Ha kiegészítjük a rutinrészletet egy DAA utasítással:

az átalakított eredmény (12H) a tízes számrendszerben elvégzett összeadás jegyeit adja.
Jelzőbitek:

• C: a 7. bitről keletkező átvitelt jelzi
• Z, S, H: a művelet utáni A-értéknek megfelelő
• P/V: paritást jelöl
• N: nem változik.

1.2.4 Bitléptető és -rotáló utasítások
A bájtot alkotó bitsort léptetik balra vagy jobbra, pontosabban a magasabb vagy alacsonyabb helyi értékek felé. Attól függően, hogy mi történik a szélen kilépő bittel, ill. milyen bit lép be a szélen, több típusa van.

Valamennyi utasítás a következő operandusokkal alkalmazható:

Jelzőbitek:

• az N és H bitek törlődnek,
• a többi jelzőbit az operandus művelet utáni értékének felel meg, P/V paritást jelez.

Az első 4 utasításnak van egy egyszerűbb (csak az akkumulátorra használható, egybájtos, kevesebb jelzőbitet kezelő) -változata is:
RLCA
RRCA
RLA
RRA
Ezek funkcionálisan az RLC A, RRC A, RL A ill. RR A utasításokkal egyeznek meg, de érdemben csak az átviteljelző bitet állítják be (emellett itt is törlődik N és H).
A biteltoló utasítások elsődleges alkalmazási területe az aritmetika, a kettővel való szorzás, osztás. Egyértelmű az analógia, ha belegondolunk, hogy pL. tízes számrendszerben is úgy szorzunk tízzel, hogy a számjegy karaktereit egy helyi értékkel balra léptetjük, az utolsó helyre pedig 0-t írunk.
Több bájtos számok osztásánál, szorzásánál egyszerűen fel lehet használni az előző bájtról keletkezett átvitelt is. Osszuk el példaként a HL bemenő paramétert 2-vel:

A regiszterkiírató programot az osztórutin beírásán túl egy kissé ki is kell egészíteni az osztandó paraméter beviteléhez:

260 CODE M=HEX$("CB,3C,CB,1D")
285 INPUT PROMPT "HL=? ":HL
290 CALL USR(M,HL)

START
HL=? 256

F: 10. 0. 000
H,L=00,80

START
HL=? 9

F: 00.0.001
H,L=00,04

Az első bevitt érték 256 (100H), fele valóban megfelel a HL = 0080 kiírásnak. A második értékkel a helyes túlcsordulásjelzést szemléltetjük: 9/2 = 4,5, ennek felel meg a

HL = 0004 CY = 1

kijelzés.
Az utasítások másik gyakori alkalmazási területe a grafika, a képpontok jobbra-balra görgetése lehet.
A léptető utasítások kőzött két olyan is van, amely a BCD számok műveleteit segíti. Ezek nem biteket, hanem BCD számjegyeket (félbájtokat) léptetnek. Az operandus itt csak (HL) lehet (tehát a HL értéke által meghatározott memóriarekesz), átvitelként pedig az A regiszter alsó félbájtja (0-3. bit) szolgál.

Jelzőbitek:

• C nem változik,
• N és H törlődik,
• Z és S az akkumulátor tartalmának megfelelően áll be,
• P/V az A paritását jelzi.

1.2.5 Bitkezelő utasítások
A Z80-as mikroprocesszor képes egybájtos operandusok tetszőleges bitjének lekérdezésére, törlésére vagy beírására. Nézzük meg példaként a B regiszter 3. bitjére vonatkozó utasítások mnemonikjait:

A lehetséges operandusok mindhárom utasításra azonosak:

A kijelölt bit sorszáma (n) 0 és 7 közötti érték lehet.
Jelzőbitek:

• a BIT utasítás:
  • a Z bitet értelemszerűen állítja
  • N=0,H=1
  • P/V és S határozatlan
  • C változatlan
• a RES és SET utasítások nem változtatják a jelzőbiteket

Az utasítások a különböző jelzőfunkciójú bitek tesztelésén, beállításán túl jól használhatók pl. egy memóriacím tartományának megállapítására. A 2. fejezetben foglalkozunk részletesebben a memóriakiosztás, a lapozás kérdéseivel. Mint látni fogjuk, a 64 kbájtnyi címzési tartományt négy 16 kbájtos lapra osztjuk fel:

Természetesen a tényleges lekérdezés (vagy beállítás) a kétbájtos cím felső bájtjainak 7. és 6. bitjén történik.

1.2.6 Ugróutasítások
A BASIC GOTO analógiája megtalálható a gépi kódú utasítások között is. Létezik feltétel nélküli ugróutasítás, amely egyszerűen a processzor programszámlálóját (PC) írja át, így a következő utasítást már az új memóriacímről olvassa a Z80-as, de a legnagyobb jelentősége a feltételes ugróutasításoknak van. Eddig számtalan utasítást láttunk, amely megfelelő módon beállította a státuszregiszter jelzőbitjeit, de most találkozunk az első olyan utasításcsoporttal, amely lekérdezni is képes ezeket a biteket (legalábbis egy részüket).

Például a JP Z,0000 utasítás hatására a processzor - bárhol tartott is a programban - a 0000H címen folytatja a végrehajtást, de csak akkor, ha a státusz az utasítás beolvasásakor Z volt (zero, pl. egy kivonás eredményeként). Ez az utasítás tehát a BASIC
IF A = 0 THEN GOTO cím
analógiája. Ezzel az utasításcsoporttal lehet tehát feltételes elágazásokat létrehozni a gépi kódú programban, ami gyakorlatilag minden programhoz nélkülözhetetlen.
Az ugróutasítások másik csoportja nem a folytatás címét adja meg (két bájton), hanem az előre vagy visszafelé átlépendő utasítások számát. Ezek a relatív ugróutasítások. Mivel ezek argumentuma egyetlen bájt (egy előjeles kettes komplemens számnak tekintett érték), ezért így az utasítást követő CIM körüli (CIM - 128, CIM + 127) intervallumba lehet csak ugrani. Ez a kis hatósugár egy erős korlátozó tényező, de mégis gyakran alkalmazzuk ezt az ugrástípust a relatív címzésmód előnyei miatt:

• az operandus csak 1 bájt, így helyet takaríthatunk meg
• még fontosabb, hogy ennél a címzésmódnál nem kell tudnunk a cél abszolút címét a memóriában, az ilyen utasításokkal megírt programok tehát a memória tetszőleges címén elhelyezhetők, futtathatók (relokálhatók).

A relatív ugrások is lehetnek feltétel nélküliek vagy feltételhez kötöttek, de itt kevesebb feltételt adhatunk meg:

Az ugrás relatív címét elemi módon az átlépendő bájtok leszámolásával határozhatjuk meg (visszafelé ugrásnál a JR utasítás, az operandus és a következő utasítás 3 bájtját is figyelembe kell venni). Például:

Az utóbbi rutinban (amely egyébként a memóriát pásztázza végig a belépési HL címtál egy A karaktert keresve) az átlépendő bájtok száma 6 (visszafelé: C9, FA, 20, 41, FE, 7E), tehát a relatív ugráscím: n = -6
Kettes komplemens ábrázolásban: n = 256 - 6 = 250 = FAH
Egy speciális - és igen hasznos - relatív ugróutasítás a DJNZ (Decrement and Jump if Non Zero), amely igen egyszerű ciklusszervezést tesz lehetővé:

Mindezeken kívül a Z80-as processzor ismer egy igen hatékony ugrástípust is, amikor az ugrás abszolút címét egy regiszterpár tartalmazza. Így lehet kiszámított ugrásokat végezni, vagy egy ugrástáblázatból kiolvasott rutincímre ugrani:

Alkalmazási példaként írjuk át az állapotsor üzenetszövegének nagybetűs karaktereit (pl. 32 bájt hosszon) kisbetűkre. Egy blokkdiagram jól foglalja össze a megoldandó feladatokat:

	Ennek megfelelően a gépi rutin:
	M11 CIM NEXT	LD HL,BEBE LD B,20 LD A,(HL) AND 7F CP 40 JR C,NEXT CP 5B JR NC,NEXT SET 5,(HL) INC HL DJNZ CIM RET	21 BE BE 06 20 7E E6 7F FE 40 38 06 FE 5B 30 02 CB EE 23 10 F0 C9

BASIC betöltővel:

100 ALLOCATE 100
110 CODE M= HEX$("21,BE,BE,06,32,7E,E6,7F,FE,40,38,06,FE,5B,30,02,CB,EE,23,10,F0,C9")
120 CALL USR(M,0)
130 GOTO 130

1.2.7 Szubrutin utasítások
Egy összetettebb feladat áttekinthető, strukturált megoldásának feltétele a szubrutinok (a program más részeiből tetszés szerint hívható alprogramok) rendszerbe illeszthetősége. A Z80-as processzornál a szubrutin hívását a CALL, a szubrutinból való visszatérést a RET utasítások szolgálják. Mindkét utasítás alkalmazható feltétel nélkül vagy státuszfeltételhez kötötten.

A feltételes utasítások:
CALL cc,nn
RET cc
ahol cc a JP-utasításnál megismert 8-féle státuszfeltétel valamelyikének rövidítése:

Például a RET PO utasítás hatására a végrehajtás visszatér a veremben tárolt címre, ha az F regiszterben P/V = 0 (ami az előző művelet függvényében jelentheti azt, hogy az operandus páratlan paritású, de azt is, hogy érvényes előjeles egész).
A visszatérési cím az előbbiek szerint egy szubrutin futása alatt a veremtár legutoljára betárolt eleme. Ez a szubrutinkezelési mód a verem igen fegyelmezett használatát követeli meg. Egy pár nélküli PUSH vagy POP utasítás a rendszer összeomlását okozhatja, hiszen a legközelebbi RET hatására a Z80-as mindenképpen visszatérési címnek értelmezi a verem tetején talált kétbájtos értéket. Másrészt azonban programjainkban fel is használhatjuk ezt az információt: kiolvashatjuk, hogy honnan hívták a rutinunkat, onnan akár paramétereket is olvashatunk be (így működnek pl. a RST 30H (EXOS) és RST 10H (BASIC) funkcióhívások), esetleg tudatosan meg is változtathatjuk a visszatérési címet. Anélkül, hogy túlzottan előre akarnánk ugrani (a BASIC rendszerhez), elmondhatjuk, hogy a sokszor használt USR(CIM,HL) gépi kódú programhívó függvény egy olyan alprogram címével (mint visszatérési címmel) lép ki a felhasználói rutinba, amely alaphelyzetbe állítja a BASIC munkaterületét, majd HL értékét (mint előjeles kétbájtos konstanst) tölti oda. Így lehetséges, hogy pl. a PRINT USR ( ) hívás esetén a PRINT utasítás ezt az értéket írja ki. Ha ezt a visszatérési címet egyszerűen töröljük a tárból (egy POP utasítással), a BASIC munkaterületen a mi rutinunkban betöltött érték maradhat mint kiírandó (vagy máshogy felhasználható) érték. Például az 1. szegmens CA0BH rutinja a PI értékét tölti a munkaterületre. Használjuk fel ezt a ROM-programot szubrutinként:

A program futtatása után PI értékét írja ki a rendszer:

100 ALLCATE 100
110 CODE M=HEX$("CD,0B,CA,E1,C9")
120 PRINT USR(M,0)

Folytatva a csoport további utasításainak bemutatását, két olyan RET típusú utasítással találkozunk (RETI és RETN), amelyeket az ENTERPRISE nem használ. Ezek a megszakításból, ill. nem maszkolható megszakításból való visszatérést kiváltó utasítások az alapfunkción túl még belső jelzőket is állítanak, ami az ENTERPRISE megszakítási rendszerében érdektelen.
A processzor rendelkezik néhány egybájtos szubrutinhívó utasítással is. Ezek a memóriaterület legelején, rögzített címen kezdődő rutinokat hívnak meg, hatásuk egyébként azonos a CALL utasításéval. Például:
RST 30H = CALL 0030H
A megengedett RST-utasítások (hexadecimális címekkel):

Ezeket a hívásokat igen hatékonyan használja az operációs rendszer: az RST 30H utasítást az EXOS sajátította ki, az RST 08H, 10H, 18H, 20H utasításokat pedig a BASIC. Segítségükkel igen egyszerűen hívhatók a rendszerek nagybonyolultságú funkciói.

1.2.8 Input/Output (I/O) utasítások
A Z80-as processzor a 64 kbájtnyi memóriaterület elérése mellett 65 536 különböző Input/Output cím - ún. port - olvasására, írására is képes az IN és OUT utasításokkal. Az ENTERPRISE azonban fizikailag lényegesen kevesebb I/O portot használ. Ilyenek pl. a nagy bonyolultságú kiegészítő áramkörök (a NICK és a DAVE chip) különböző regiszterei. Ilyen regisztereket használ a gép az elérhető memóriaterület kiterjesztéséhez (a memória 16 kbájtos szegmenseinek a Z80-as címtartományába való lapozásához), a nyomtató kezeléshez, a videokijelzés bizonyos funkcióihoz, billentyűzet letapogatáshoz stb. Ezek címzéséhez bőségesen elegendő 1 bájt (256 I/O cím). A továbbiakban így adjuk meg az utasításokat (a Z80-as teljes I/O címzési lehetőségeit bármelyik Z80-as szakirodalom tartalmazza).

Jelzőbitek:
az IN A,(n), OUT (n),A és OUT (C),r utasítások nem változtatják a státuszt, míg az IN r,(C) utasítás végrehajtása után a Z, P/V (paritás), S és H bitek a beolvasott értéknek felelnek meg; N = 0 és C változatlan.

Az I/O utasításoknak van (a tömbmozgató utasításokkal analóg) adatsorozat átvitelét segítő változatuk is. Ezekben a kijelölt port címét mindig a C regiszter tartalmazza, míg az adat a HL címre kerül, ill. a HL cím tartalmát viszi ki a processzor a portra. Számlálóként a B regiszter szolgál.

Jelzőbitek:

• Z = 1, ha B = 0 a művelet után
• P/V, S és H határozatlan
• C változatlan
• N = 1

Alkalmazási példaként olvassuk be a billentyűzetmátrixot. Ehhez a mátrix tíz sorának számát sorra kiírjuk a B5H portra, mert ezzel jelöljük ki az olvasandó sort, majd az onnan beolvasott adatot (minden 0 bit egy lenyomott billentyűnek felel meg) kiírjuk az állapotsorba (ott természetesen az érték valamilyen karakterként jelenik majd meg):

BASIC betöltővel:

100 ALLOCATE 100
120 CODE M=HEX$= ("21,BE,BE,0E,00,06,0A,79,D3,B5,DB,B5,2F,77,0C,23,10,F5,C9")
120 CALL USR(M,0)
130 GOTO 120

1.2.9 A processzor vezérlőutasításai

Maga a megszakításkérés a processzor INT vagy NMI csatlakozási pontjára (lábára) érkező impulzus. A kérést a processzor az első esetben csak akkor fogadja el, ha előzőleg a program engedélyezi a megszakítást, a második esetben pedig feltétel nélkül (NMI = Non Mascable Interrupt - nem maszkolható megszakítás).

A két utasítás természetesen csak a maszkolható megszakításokra vonatkozik. A pillanatnyi állapotot egy belső flag őrzi, amelynek értéke 1, ha a megszakítás engedélyezett, 0, ha tiltott. Az LD A,I vagy LD A,R utasítással olvashatjuk a státuszregiszterbe (P/V bit).
Hogy mit jelent az, hogy a processzor elfogadja a megszakításkérést, azt a pillanatnyi megszakítás üzemmód határozza meg. Maszkolható megszakításkérésnél először letiltja a további megszakításokat, majd a kérést a legutóbbi üzemmód-beállító utasítás szerint kezeli:

Nem maszkolható megszakításkérésnél a processzor egy RST 66H utasítást hajt végre.
Az ENTERPRISE megszakítás rendszere az IM 1-es módot használja. Ez ugyan önmagában nem a leghatékonyabb (hiszen minden megszakításkérést a 0038H szubrutin szolgál ki), de a hardver megoldás még az IM 2-es módnál is nagyobb hatásfokúvá teszi. A megszakításkérések ui. nem közvetlenül, hanem egy kiegészítő áramkör (a DAVE chip) közvetítésével jutnak a processzorra. A megszakítás forrását a DAVE regiszterei alapján szoftver úton lehet megállapítani, sőt - ami minőségileg újat jelent - külön-külön is le lehet tiltani az egyes források kéréseit. A megszakítás rendszerről a 2.4 alfejezetben írunk bővebben.

A Z80-as mikroprocesszor megismert utasításkészletével nekivághatunk a gépi kódú programozásnak. Az eddig közölt példák megmutatták, hogy a közvetlen, kódokkal való programozás meglehetősen körülményes (főleg a relatív ugrások számítása nehézkes). Néhány tucat, esetleg 1-200 utasítás fölött már feltétlenül érdemes a gépi kódú programozást igen megkönnyítő segédprogramot, assemblert alkalmazni.
A mintapéldákban eddig is megadtuk a kódsorozat mellett az utasítások mnemonikjait. Például egy az akkumulátorba az A kódját töltő, majd vissztérő rutin gépi kódban:

3E 41 C9

Ennek assembly nyelvű kifejezése:

LD A,41 H
RET

Az assembly nyelven megírt programot gépi kódok sorozatára lefordító segédprogram az assembler. Valójában egy jó assembler lényegesen többet nyújt a mnemonikok kódokkal való helyettesítésénél. A relatív ugrásokat, szubrutinhívásokat stb. segítő címkéket használhatunk, operandusként paraméterek is megengedettek, sőt az aritmetikai műveletek egy részét is használhatjuk stb. A nyújtott szolgáltatásokat mindig a kiválasztott assembler leírása adja meg. Mi a talán legelterjedtebb SIMON (ASMON) (editor, assembler és monitor) programot használtuk. Ennek szabályait a 9. Függelékben foglaljuk össze. Most nézzünk meg egy-két olyan szintaktikai szabályt, amely a következő fejezetek mintapéldáinak, leírásainak megértéséhez szükséges.

• Az assembler (megfelelő beállítással) a memória kijelölt címére tölti a lefordított kódokat. A kívánt kezdőcím az ORG direktívával adható meg. Például:
  ORG 0180H
• Egy sorba csak egy utasítást írhatunk. Az első pozíción csak címke kezdődhet. Ha nincs címke, legalább egy szóköznek kell állnia a Z80-as utasítás előtt.
• A numerikus operandusokat a SIMON assemblere decimálisan értelmezi. Ha hexadecimális értéket akarunk megadni, ezt a konstans után írt H betűvel kell jelezni. Egy megkötés: konstans csak számjeggyel kezdődhet (ez különbözteti meg a címkétől). Innen a néha körülményesnek tűnő alak:
  LD HL, 0BEB8H
• A programokba tetszés szerint írhatunk - pontosvessző után - megjegyzéseket.

• 0. szegmens (00H): belső ROM
  (elsősorban EXOS rendszerprogramok; video, hang, szerkesztő és billentyűzetkezelők)
• 1. szegmens (01H): belső ROM
  (matematikai rutinok; nyomtató, kazettás magnetofon, soros hálózati kezelők; szövegszerkesztő stb.)
• 4. szegmens (04H): külső ROM BASIC-BRD
  (elsősorban a német nyelvű verzióhoz szükséges kiegészítéseket tartalmazza)
• 5. szegmens (05H): külső ROM BASIC-UK
  (BASIC értelmező)

• milyen környezetet, hátteret épít fel számunkra az EXOS;
• hogyan használhatjuk fel a rendszer rutinjait, funkcióit (akár közvetlenül is, a kényelmes, de időigényes főágak megkerülésével, átlépésével).

Mindenekelőtt tekintsük át az EXOS alapfeladatait.

1. Bekapcsolása után inicializálja a rendszert (ezt kissé részletesebben áttekintjük a 2.3.1 pontban):
   -ellenőrzi a különböző memóriaterületeket és típusokat (ROM vagy RAM) az eredménynek megfelelően könyvtárazza azokat,
   -kijelzésre alkalmas állapotot hoz létre a VIDEO áramkör (NICK-chip) számára;
   -alapértéket ad a rendszerváltozóknak, RAM-ba helyez bizonyos nélkülözhetetlen rendszerrutinokat;
   -listát készít a rendszer-ROM-ban és a bővítőkben talált perifériakezelőkről.
2. Lehetőséget ad a bővítőben csatlakoztatott alkalmazói programnak a vezérlés átvételére (ha nincs ilyen program, a szövegszerkesztő kapja meg a vezérlést).
3. A háttérben továbbra is ellát minden olyan feladatot (az alkalmazói programban kiadott funkcióhívások útján), amely a memóriaszervezéssel, a perifériák írásával, olvasásával és a csatornaműveletekkel kapcsolatos.

A két belső ROM-ban tárolt alapszoftver a következőket tartalmazza:

• egy inicializáló szakaszt a rendszer egyértelmű alaphelyzetbe állításához;
• egy sokrétű funkcióhívás kezelőt, ennek főágát és alprogramjait, köztük a megszakítás-kezelővel;
• a géphez csatlakozó be- és kiviteli alapelemek kezelőit:
  • a 0. szegmensen:
    • VIDEO (képernyőkezelés)
    • SOUND (hangkezelés)
    • KEYBOARD (billentyűzetkezelés) (ezt a feladatot a német BASIC-ROM átveszi a német karakterkezelés érdekében)
    • EDITOR (szerkesztés) (ezt is felülírja a BASIC-BRD szegmens a BASIC-ben)
  • az 1. szegmensen:
    • PRINTER (nyomtatókezelés)
    • TAPE (magnetofonkezelő)
    • SERIAL (soros adatátvitel)
    • NET (hálózatkezelő)
• egy szövegszerkesztőt (Word Processor);
• ezen kívül tartalmaz még adatokat is; változók alapértékeit, 10-es szorzótáblát, üzenetek (és hibaüzenetek) szövegét, a karakterkészletet, a matematikai rutinok egy részét stb.

2.3 Az EXOS működése

Az EXOS - operációs rendszer létére - szokatlanul sokoldalú, meglepően sok feladatot lát el. Ezek között vannak természetes alapfeladatok, pl. a különböző memóriaterületek ellenőrzése, alaphelyzetbe állítása stb., de - különösen a képernyőkezelés területén - ellát olyan feladatokat is, amelyek egy alkalmazói programnak is becsületére válnának. Elég azt megemlíteni, hogy ez a rendszer tartalmaz pl. ellipszisrajzoló vagy a zárt grafikus alakzatokat kitöltő alprogramokat is (a VIDEO perifériakezelőben). Tulajdonképpen a gép - igen komfortos - BASIC-jének alig van olyan (perifériákkal kapcsolatos) utasítása, amit ne támogatna az EXOS.
Ez a tény nagyon leegyszerűsíti a gépi kódú programozás bizonyos területeit is, hiszen bonyolult feladatokat oldhatunk meg egyetlen funkcióhívással (pl. képernyőlap kijelzése) anélkül, hogy akár a végrehajtó rutinok, akár az érintett memóriaterületek címeit ismernünk kellene.
Az EXOS bemutatása során - bár nem ROM-fejtés közlése a célunk - néhány belső rutint is elemzünk, részben a profi gépi kódú programozás tanulságai érdekében részben a felhasználás feltételeinek megismeréséhez. A megértéshez, felhasználáshoz példákat is adunk, általában BASIC-ben felépítve, hogy a gép elé leülő, a rendszerrel most ismerkedő Olvasó azonnal kipróbálhassa, ellenőrizhesse a leírtakat.
Ez annál is fontosabb, mert a forgalmazott gépek között több változat is előfordult. Az operációs rendszer alaptulajdonsága - nevéhez méltóan - a kiterjeszthetőség, bővíthetőség. A személyi számítógépek körében szinte páratlan mértékben képes memóriamérethez, verzióhoz alkalmazkodni. Ez a nagyfokú rugalmasság természetesen azzal jár, hogy a memóriakiosztás is képlékeny. Igazán hordozható, minden verzióban működő programot tehát csak az EXOS rendszer, a funkcióhívások felhasználásával építhetünk fel. Egy adott gépen dolgozva azonban mindenképpen praktikus a gép megismerése, feltérképezése, hiszen a konkrét adatok birtokában gyakran sokkal hatékonyabban (rövidebb programokkal és gyorsabban) oldhatjuk meg a feladatokat. A mi példáink - mint leírtuk - a 128 kbájtos, angol/német változatra vonatkoznak. A saját gépén az Olvasónak feltétlenül érdemes a közös báziscímekből kiindulva megállapítani (és rögzíteni) a konkrét adatokat és címeket.

2.3.1 Inicializálás

A bekapcsolás után az EXOS hidegindítási főága hozza létre azt a jól definiált hátteret, amelyben minden felhasználói program dolgozhat. Gépi kódú programot írva számunkra is ez lehet a munkánk bázisa, ez szabja meg a lehetőségeket és a korlátokat. Kövessük tehát végig a rendszer felépítésének folyamatát, természetesen azokat a részeket, elemeket kiemelve, amelyek valamilyen szempontból fontosak lesznek a későbbiekben.
A feszültség rákapcsolásakor a processzor a 0. szegmens legelső utasításait kezdi végrehajtani. Még a 0. LAP-on letiltja a megszakításokat és egyszer s mindenkorra az 1. megszakítási módba kapcsolja a processzort (részletesebben l. a 2.4 alfejezetben). Ezután elugrik a 3. LAP-ra, ahol - bekapcsolás után - szintén a 0. szegmens van belapozva, és most már itt folytatja a futást.
Érdemes megjegyezni, hogy a továbbiakban a különböző rendszerprogramok tartózkodási helye szinte kizárólag a 3. LAP lesz. Ide lapoz be minden programot, kezelőt is az EXOS, mielőtt átadná nekik a vezérlést. Ezért mi is a 3. LAP-on értelmezett címeket használjuk, pl. egy disassemblált ROM-részletben. Így lesz a 0. szegmens legelső bájtja a 0000H című utasítás, a szegmens végcíme pedig a FFFFH.

Memóriaellenőrzés és könyvtárazás
A 3. LAP-on elvégzett első érdemi funkció azonnal érdekes lehet a felhasználó számára. A 0. LAP-ra lapozott 4. szegmensen (ide, a bővítő cartridge-ban lévő EPROM-ba elvileg saját beégetett programunkat is tehettük) ellenőrzi, hogy nem a TEST-ROM szöveggel (54H, 45H, 53H, 54H, 5FH, 52H, 4FH, 4DH bájt-sorozat) kezdődik-e. Ha igen, azonnal el is ugrik a szöveget követő bájtra. Az EXOS rugalmasságára jellemző, hogy már az inicializálás pillanatában hajlandó átadni a vezérlést a felhasználónak, aki így akár egy teljesen más karakterű gépet is kihozhat az adott hardverből.
Mi azonban az ENTERPRISE alaphelyzetét, memóriakiosztását szeretnénk megismerni. Kövessük tehát tovább a főágat, a hidegindítás folyamatát.
Az EXOS külön ellenőrzi a később fontos célra szánt 255. szegmenet (FFH). Az ellenőrzés módszerét érdemes áttekinteni a később valamennyi RAM-szegmens vizsgálatára felhasznált rövid ROM-részletben. A vizsgált szegmens az 1. LAP-on van (4000H-7FFFH címtartomány), a teszteléshez felhasznált értékek a 0. szegmens (ROM) C000H-FFFFH bájtjai.

Azt láthatjuk, hogy a tesztelés utolsó mozzanataként minden RAM-címre 0-t tölt a rutin. A RAM-szegmensek tehát törölve kerülnek ki az ellenőrzésből.
Ha a szegmens hibátlan, ez lesz a rendszerszegmens, ez tartalmazza majd a rendszerváltozókat, a báziscímeket, az EXOS futása alatt a Z80-as-vermet stb. Érthető tehát, hogy ha hibát talált az ellenőrzés, a rendszer ezen a ponton lefagy; pörgő keretszínnel végtelen ciklusba kerül:

Ezt igen könnyen kipróbálhatjuk, akár BASIC-ben is:

(itt még szerencsére segít a RESET gomb).

A Z80-as veremmutató (Stack Pointer) az ellenőrzés alatt ideiglenesen a még ellenőrizetlen 254. szegmensbe kerül, de a továbbiakban (és általában az EXOS-ban) SP = B217H-ról indul a 255. (rendszer-) szegmensben.
A további ellenőrzés már kijelzés mellett folyik, de ennek még vannak előfeltételei: ebben a szakaszban még nincs meg a NICK-chip működéséhez nélkülözhetetlen sorparaméter-tábla (LPT), sőt a karaktergenerátor (a kijelezhető karakterek alakját, pontmátrixát tároló memóriaterület) sem. Mindezt a VIDEO perifériakezelő inicializálás rutinjának meghívásával (0. SZG. D260H belépési cím) hozza létre az EXOS.
A rutin hívása után a képernyő sötét, a képernyő legfelső sorában (az ún. állapotsorban) megjeleníthető memóriaterület pedig a belapozott rendszerszegmens BEB8H címén kezdődik. Ide tölti be a program közvetlenül a kijelzendő karaktereket, miután az állapotsort láthatóvá tette.
A következő lépésben a saját ROM-jait (0. és 1. szegmens) ellenőrzi az EXOS (ellenőrző összeg 0). Természetesen itt sem léphet tovább, ha hibát talál (ebben az esetben az "INTERNAL CHEKSUM ERROR" feliratot ír az előkészített állapotsorba).
Ezek után a RAM-szegmensek ellenőrzése következik, a már megismert módon. Felülről lefelé (a 254.-től a 8.-ig) végigvizsgál minden szegmenst (részletesen csak azokat, ahol legalább az első címen írható memóriát talált). Ez a kulcsa annak, hogy tetszőleges memóriakiterjesztés esetén korrekt RAM-könyvtárat készíthessen a rendszer.
Eközben az állapotsorban az

EXOS 2.1 TESTING ERROR

felirat látható (ill. az "ERROR" remélhetőleg nem, hiszen jó RAM-ok esetén ez fekete színű). A látható sor végére viszont kiírja (hexadecimális alakban) az ellenőrzött szegmens számát.
Az ellenőrzés során számlálja a jó és rossz RAM-okat és elkészíti a jó RAM-szegmensek táblázatát: az ABD0H címtől lefelé sorra bejegyzi minden jónak talált RAM szegmensszámát. Az eljárás végére ki is alakul néhány fontos rendszerváltozó értéke (zárójelben a vizsgált verzióban, hibamentes esetben adódó értékek):

A RAM-tábla:

A szabad és rendszerszegmensek kezelésekor az EXOS nem veszi figyelembe a. legalsó jó RAM-ot (esetünkben a 248. (F8H) szegmens), ami igencsak kötött felhasználású: ez lesz majd a 0. LAP gyakorlatilag állandóan belapozott szegmense. Így érthető, hogy a rendszer leállásához vezet, ha az ellenőrzés nem talál legalább még egy jó szegmenst a már ellenőrzött 255. szegmens mellé.
Ezzel alakul ki a felsorolt változók értéke: a talált nyolc RAM-szegmensből hetet vehet figyelembe az EXOS (F9H-FFH), ebből a legmagasabb sorszámút (FFH) a rendszer már igénybe vette, tehát hat szegmens marad a felhasználó számára szabadon.
Mielőtt továbbmennénk, álljunk meg egy pillanatra egy terminológiai problémánál. Az előbbiekben megismert RAM-szegmens táblázathoz hasonlóan szinte minden táblázat, lánc felülről lefelé épül fel. Egy táblázat utáni bájt címe tehát (a táblázat végcíme -1).
Hogy elkerüljük a fogalmakban rejlő ellentmondást - és ezzel a félreértéseket -, a továbbiakban az előtti, utáni megjelölések helyett az adott esetekben az alatti, fölötti kifejezéseket használjuk (a "fölső" alatt természetesen mindig a magasabb címet értve).

A ROM-szegmensek könyvtárazása
Az inicializálás folyamatában a RAM-ok ellenőrzése után a következő lépés a ROM-ok nyilvántartásba vétele. Először a - tizenhatos számrendszerben - kerek értékű szegmenseket (F0H, E0H, ... 10H) vizsgálja végig a rendszer: ellenőrzi, hogy EXOS-ROM karakterekkel (45H, 58H, 4FH, 53H, 5FH, 52H, 4FH, 4DH bájtokkal) kezdődik-e az adott szegmens.
Ha igen, könyvtárazza azt. A RAM-szegmensek táblázata alatt felépített ROM-szegmens táblázatban 4-4 bájt tartozik minden bejegyzett ROM-hoz: a legfelső bájt a ROM-szegmens száma, alá majd később jegyzi be a rendszer a ROM számára esetleg kiosztott RAM-terület szegmensszámát és címét. Ha - pl. címdekódolási okok miatt - több szegmensszámon is megjelenik az adott ROM, az EXOS csak a legalsó számot veszi fel a nyilvántartásba.
Ezekre a kerek címekre vagy a 7.-4. szegmensre kell tehát dekódolni (és a fenti bájtokkal kezdeni) az IS-BASIC melletti további kiterjesztésre szánt esetleges EPROM-okat.
A következő lépésben a 7.-4. szegmenseket ellenőrzi és könyvtárazza a rendszer (esetünkben), végül bejegyzi a táblázatba az 1. szegmensszámot is. Az elkészített táblázat ebben a fázisban a vizsgált alapkiépítésű gép esetén:

Az EXOS beállítja a tábla két végét jelző rendszerváltozókat is:

Egyelőre ezzel azonos értékűre állítja a rendszer munkaterületének kezdőcímét is (BF95/6H, értéke ekkor ABB9H).
A táblázatok, elkészítése után az EXOS alapértéket ad néhány rendszerváltozónak:

Rendszerrutinok kiépítése
Az inicializálás következő lépése a rendszer működése szempontjából alapvető fontosságú két RAM-terület feltöltése:

• a rendszerszegmensre másolja (a B217H címtől) a 0. ROM C3AAH-C3E4H területét
• a 0. LAP-ra lapozott F8H-as szegmensre másolja (a 0030H címtál) a C3E7H-C40FH ROM-területet.

A nullás lapon kialakított terület lesz az EXOS n funkcióhívások belépési és visszatérési ága.
A rendszerszegmens B217H-B33DH területén kialakított alprogram az EXOS lapozási technikájának alaprutinja. Mint már említettük, a különböző rendszerek programjai általában a 3. LAP-on futnak. Ha tehát át akarunk térni egy másik szegmensre (vagy meg akarjuk hívni annak valamelyik alprogramját), meg kell oldanunk a lapozás alapproblémáját: az OUT (B3H),A utasítás nem lehet a 3. LAP-on futó program része, hiszen a végrehajtás után a következő bájtot (utasítást) már az átlapozott szegmensről olvassa be a CPU. Nincs tehát időnk a JP vagy CALL utasítás kiadására. Az átlapozásnak feltétlenül másik szegmensen kell történnie.
Az EXOS erre a célra a 2. LAP-on látszó rendszerszegmenst - abban az előbb bemásolt rutint - használja:

B217H belépésekor A-ban és HL-ben a célrutin szegmensszáma és belépési címe van, AF'-ben paramétert és státuszt adhatunk át, a visszaadott paramétert és státuszt az AF-ben kapjuk meg. A többi regiszter szabadon használható.
A B223H belépés tetszőleges JP(HL), a B226H-B22DH szakasz pedig az EXOS n funkcióhívások visszatérési ágát szolgálja ki.
A rutinokkal együtt a rendszerszegmensbe másolt további bájtok copyright jellegű üzenetet hordoznak: a BF30H-BF51H területen a "Written by: Mrl BT NMV GNH CGE AEL" szöveg található, amit meg is jeleníthetünk az állapotsorban a POKE 49119,42 utasítással (l. a 2.4 pontot).
A lapozó rutin alapvető fontossága alapján érthető, hogy a rendszer fokozottan védi ezt a memóriaterületet: megváltoztatása azt eredményezi, hogy még a melegindítási kísérlet is (RESET) hidegindításba fordul. Már kevésbé indokolt a terület végének (a szövegtartománynak) ez a nagyfokú védelme. Ellentmondásban is áll a gép - egyébként minden ízében érezhető - felhasználó-centrikusságával, hiszen ezzel egy igen kényelmesen használható képernyőüzenet területet tettek problematikussá.
A rendszer felépítésének folytatásához az EXOS átugrik az 1. szegmens C00DH címére az előbbiekben tárgyalt lapozórutin segítségével, miután az egyébként sokoldalú belépési ponthoz a hidegindítást biztosító paramétert állított be (A = 6).
Az 1. szegmensen a vezérlés azonnal az E40FH címre, innen - A értéke alapján - az E66EH címre adódik. Itt folytatódnak a hidegindítás funkciói.
Itt a rendszer mindenekelőtt egy EXOS 0 funkcióhívást ad ki, C = 20H RESET jelzővel. A funkcióhívásokról a következő pontban írunk részletesebben, de mivel ez a hívás hozza létre azt a háttérállapotot, memóriakiosztást, amivel a felhasználó gazdálkodhat, kövessük itt is a hidegindítás folyamatát!
A funkcióhívások közös bevezető szakasza után az EXOS 0 végrehajtása (újra a 0. szegmensen) a C653H címen kezdődik. A rendszer mindenekelőtt törli (0-ra állítja) a

BFF8/9 RST ADDR
003D/EH SOFT-ISR
BFED/EH USER-ISR

rendszerváltozókat. Ezután a végrehajtás szétválik a RESET jelzők alapján. Esetünkben (C = 20H) a C23AH rutin következik.

A RAM-igények kielégítése
Az első érdemi funkció, amit itt a hidegindítás során elvégez, további EXOS változók alapértékének beállítása (ezeket a funkcióhívás leírásánál adjuk meg). Ezután viszont a RAM-felhasználást alapvetően érintő lépés következik: az EXOS végigkérdezi az előbbiekben felépített ROM-táblázat bekönyvtározott ROM-jait, hogy igényelnek-e RAM-ot a rendszertől. Mivel ez fontos lépés a memóriatérkép kialakításában, másrészt az igénylés és a kielégítés módja is fontos lehet a gépi kódban programozó számára, tekintsük át az eljárást. Az áttekinthetőség érdekében azt az utat kövessük, amit a rendszer az eddig tárgyalt alapkiépítés esetén jár be:

A rutinból is látható, hogy a táblázatban tárolt ROM-ok belépési pontja a C00AH cím. A táblából megállapított szegmensszámú és a B217H lapozórutin által a 3. LAP-ra kapcsolt és meghívott ROM-ok a C = 7 akciókód hatására megadhatják a RAM-igényüket (a DE regiszterpárban a nagyság, B-ben a helye: B = 1 esetén a 2. LAP-on, B = 2 esetén az 1. LAP-on). Ha megvizsgáljuk a bejegyzett ROM-ok (sorrendben az 5., 4., 1) belépési pontjait (erről még lesz szó a továbbiakban), megállapíthatjuk, hogy közülük csak a BASIC-BRD (esetünkben a 4.) szegmens reagál a C = 7 akciókódra, innen C = 0: kell RAM; B = 0: a 2. LAP-on; DE =04B3H értékekkel tér vissza a rendszer).
Ezek szerint a ROM-okat lekérdező ciklusból csak a 4. szegmensnél lép ki a rendszer, és mivel ez a rendszerszegmensben kér RAM-ot, a C303H programrészletben kapja meg. A rendszerterület kezdő címe (BF95/6H) belépés előtt a ROM-táblák aljára mutatott (ABB9H), a kiosztott RAM lefoglalása után tehát a munkaterület az ABB9H - 04B3H = A706H cím alatt kezdődik. Ezzel alakul ki az érintett rendszerváltozók BASIC-ben is lekérdezhető értéke, valamint a ROM-tábla megváltozott eleme:

ABBEH 06 A7 FF 04

A beépített perifériakezelők könyvtárazása
Az EXOS 0 inicializálási folyamatában ezután a periférialánc felépítése következik. A rendszerszegmensben elkészülő lánc elemeit, a periférialeírókat a ROM-okban tárolt perifériainformációk (álleírók) alapján alakítja ki az EXOS.
Minden ROM-szegmens elején a 0008/9H címen található az a kétbájtos cím, ami az adott ROM első perifériájának adatmezőjére mutat (a cím az 1. LAP-on értelmezett cím kell legyen, mint látni fogjuk). Ez az adatmező is tartalmaz egy pointert (mutatót) a következő perifériára stb., a lánc végéig, amit a pointer 0000 értéke mutat (ha az adott ROM-ban nincs perifériakezelő, már a C008/9H címen 0 van). Lássunk egy konkrét példát (az EXOS leírás terminológiájával) az álleírók most figyelembe vett elemeire: a 0. szegmens C008/9H címén az 5780H pointer érték található. Ez a VIDEO periféria álleírójának méretmeghatározó (SIZE) mezőjére mutat. Az 1. LAP címtartományában az álleíró:

Az EXOS a munkaterület kezdőcímétől (BF95H értéke, eddig követett példánkban A706H) lefelé tárolja a leírókat. A leírók alatti szabad terület kezdőcímét (BF93H értéke) minden lépésben a befejezett leíró alá állítja.
Először a 0. szegmens periférialáncát követi (és könyvtárazza) végig, majd a ROM-táblázat alapján végigvizsgálja az összes - bejegyzett - ROM-ot és azok perifériáit is nyilvántartásba veszi. Az eljárás érdekessége, hogy ebben az esetben alulról felfelé veszi sorra a ROM-szegmenseket (0-1-4-5 sorrendben), tehát a magasabb sorszámú bővítőknek mindig lehetőségük van felülírni a beépített kezelőket.
Egy leíró bejegyzését a rendszer a következő lépésekben végzi:

• a vizsgált ROM-szegmenst az 1. LAP-ra lapozza;
• beolvassa a láncmutatót (a SIZE mezőre mutat). Ha a mutató értéke 0, a következő szegmenst vizsgálja;
• az álleíró elemeit (a típusbájttól a nevéig) áttölti a munkaterületre a BF93H aktuális értéke alá;
• beolvassa a ROM-ból az álleíró RAM-igényét, és ennyi helyet szabadon hagy a bejegyzett leíró és az alá írandó 3-bájtos mutató alatt. BF93H-at az utolsó lefoglalt bájtra állítja;
• beolvassa a BFC0H báziscím alatti 3 bájtot és helyére az éppen bejegyzett leíró szegmensszámát (báziscím-l) és tárolási címét tölti (báziscím-3/-2 a leíró TYPE-bájtjára mutat). A báziscím alól kiolvasott pointert letárolja a bejegyzett leíró alá. Mivel a legelső bejegyzés előtt a BFC0H báziscím alatti bájtok értéke 0 volt (a hidegindításnál minden RAM törlődött), egy későbbi bejegyzésnél pedig itt az előzőleg felvett leíró tárolási címe és szegmensszáma található, az eljárás folytatásával egy lánc alakul ki. A láncban a BFC0H báziscím alatti pointer a legutoljára felvett leíróra mutat, e leíró előtti pointer az előtte felvett leíróra stb. a legelőször felvett leíróig, aminek pointere 0;
• ezután - ha a leíró UNIT-COUNT eleme 0, azaz nem lehet több leíró ilyen néven - végigvizsgálja a már bejegyzett leírókat a láncban és, ha az éppen felvett perifériára talál másik bejegyzést, érvényteleníti azt (a TYPE-bájtot FF-re állítja). Ilyen bejegyzést találhatunk a vizsgált konfigurációnál is (mint a fejezet végén, az ellenőrző programmal látni fogjuk);
• a leíró felvételének befejező lépéseként a TAB-SEG mezőre azt a szegmensszámot írja, amelyen megtalálta az érintett periféria álleíróját. A felhasználónak tehát egy ilyen perifériakezelő (és annak álleírója) elkészítésekor - a rendszert kifejlesztők jól érezhető koncepciójának megfelelően - akár nem is kell tudnia, konkrétan melyik szegmensre kerül az adott részszoftver.

A láncszemek felfűzését jól követhetjük a ROM - minden láncépítési folyamatban hívott - rutinján:

Ezt az eljárást folytatja az EXOS egy ROM-on belül addig, amíg a periférialánc végére nem ér (NEXT = 0000H), a ROM-ok során pedig addig, amíg el nem éri a ROM-táblázat végét, amíg a ROM-szegmens száma helyéről 0-t nem olvas be.

A csatornaterület
A felülről lefelé kiépített periférialánc alatt kezdődhet az igazi EXOS munkaterület: a csatornák leíró és puffermemóriái. A periférialánc legalsó bájtjára a, BF93H redszerváltozó mutat. Erre állítja az EXOS a BFBDH alatti 3-bájtos mutatót (cím + szegmens). A BFBDH báziscím tehát a felhasználók által felépített csatornalánc kiindulási pontja lesz. Maga az EXOS 0 a hidegindítás folyamatában nem nyit tényleges csatornákat, csak egy töredék leírót (az alapértelmezés szerinti 0-s csatornához tartozó néhány bájtot) helyez el, ami alá kerülhet majd a hozzárendelt periféria mutatója és a munkaterület. Egyelőre ide - mint az EXOS munkaterület alsó határára - állítja be a rendszer a BF91/2H rendszerváltozó, az EXOS határ értékét (0-16 k közötti értékre transzformálva).
Ezzel lényegében kialakult a rendszermemória. Az EXOS legalábbis már csak az alapértelmezésű periféria nevét (TAPE) helyezi el rögzített munkaterületen (BF18H: hossz, BF19H-tól a karakterek), és a megszakítás engedélyezést állítja be a BFC5H rendszerváltozóban és a DAVE-chip B4H-es regiszterén.
A felhasználócentrikus logikára jellemző módon azonban még megadja a lehetőséget a perifériáknak, majd a rendszerbővítőknek a saját inicializálásra is.
A perifériakezelők - funkciójuknak, működési logikájuknak megfelelően - különböző feladatokat látnak el, amikor az EXOS meghívja belépési-cím táblázatuk 12. (inicializálás) címét. A VIDEO-kezelő pl. újra beállítja a sorparaméter-táblát (LPT), az 'EDITOR' csak egy bájttal jelzi saját munkaterületén, hogy megtörtént az inicializálás, a nyomtató-kezelő pedig semmit nem csinál.
A rendszerbővítők lekérdezésénél egy olyan báziscímhez is fordul az EXOS, amiről eddig még nem volt -hidegindításnál nem is lehetett - szó. A BFC3H báziscím alá írja majd a rendszer a magnetofonról beolvasott, vagy általunk kreált bővítők (pl. PASCAL, ASMON stb.) láncának mutatóját. A bővítők ui. ugyanolyan láncba fűzhetők, mint a periférialeírók vagy a csatornák. Mivel az így könyvtárazott bővítők státusza egészen különleges a gép életében, ezzel a kérdéssel még érdemes foglalkozni.
Az EXOS C = 8 akciókóddal (Inicializálás) először ezeket a bővítőket kérdezi le (de természetesen a hidegindítás alatt a bővítők lánca még üres), majd a ROM-táblázat alapján végigkérdezi a ROM-szegmenseket is. Az alapkonfigurációban egyedül a 4. szegmens lát el tényleges feladatokat ennél a hívásnál (előkészíti a német nyelvű hibaüzenetek kiírását, a német karakterkészletnek megfelelően állítja be a karaktergenerátort stb.).
Ezzel tulajdonképpen be is fejeződött a rendszer inicializálása; kialakult a jellemző memóriatérkép. Ez a rendszer azonban még nem képes kapcsolatot tartani a környezetével, nincsenek meg a gép és perifériái (pl. billentyűzet, képernyő stb.) közötti utak: a csatornák. Ezeket a felhasználónak kell igényei szerint kialakítani. Ezt teszi meg - ideiglenesen - az 1. szegmens is a bejelentkezés érdekében, miután az inicializálás után ide tér vissza a rendszer.

Bejelentkezés
A csatornaparaméterek beállítása, a csatornák megnyitásának módja számunkra is érdekes lehet. Kövessük hát ezt az eljárást.
A felhasznált F745H rutin a HL címen kezdődő táblázat alapján dolgozik. A 80H-nál kisebb beolvasott értékeket EXOS változó sorszámnak tekinti és beírja a következő táblaelemet. A nagyobb értékeket csatornaszámként kezeli és megnyitja azt arra a perifériára, amelynek nevére a tábla következő két eleme mutat:

Ezt a rutint felhasználva állítja be az E69DH rutin a bejelentkezéshez szükséges paramétereket, megnyit egy hardver szöveglapot az "1985 Intelligent..." üzenethez, egy 256 színű grafikus lapot a nagybetűs, villogó "ENTERPRISE" felirathoz és a billentyűzetcsatornát, hogy kiléphessünk ebből a végtelen ciklusból:

A felhasznált táblázatok:

A "VIDEO:" és "KEYBOARD:" szövegek az 1. lap FE34H, ill. FE4CH címén találhatóak. A rutinokat felhasználni kívánó Olvasónak jó tudni, hogy ezek mellett le vannak tárolva az "EDITOR:" (FE3BH) és "printer:" (FE43H) periférianevek is.
A megnyomott billentyű hatására a rendszer lezárja az ideiglenesen megnyitott csatornákat, majd (0-t írva a műveleti kód tárolóba (BF78H)) felkínálja a vezérlést a bővítőknek: egy EXOS 26 hívást hajt végre.
Ennek hatására az EXOS C=1 (Hidegindítás) kóddal meghívja minden rendszerbővítő, majd minden ROM belépési pontját (C00AH). Ekkor az alkalmazói program átveheti a vezérlést. Ha minden bővítőbő1 visszatérne a rutin (változatlan C-regiszterrel), a sor végén ott áll az 1. szegmens, annak WP alkalmazói programja (a szövegszerkesztő), ami csak erre a hívásra vár (ha nincs bővítőmodul a gépben, akkor éppen ez a helyzet áll elő: a bejelentkezés után a szövegszerkesztő kezd dolgozni). A vizsgált kiépítésben azonban a ROM-tábla első szegmense (az 5. BASIC-ROM) azonnal átveszi a vezérlést és kialakítja a BASIC rendszert.
Ezzel végre végetért az inicializálás (legalábbis az EXOS-é), a szó ettől a pillanattól az alkalmazóé. Mielőtt azonban továbblépnénk, beszéljünk még egy inicializálás vonatkozású folyamatról: a melegindításról. A felhasználó beavatkozásával ui. a tárgyalt indítási folyamat - a felépített rendszer és a felhasználói memóriák védelmében - lényegesen enyhébb irányba is fordítható. Ehhez az alkalmazónak egy 0-tól különböző értéket (praktikusan saját inicializáló belépési címét) kell betölteni a RST-ADDR rendszerváltozóba (BFF8/9H, 49144/5). A RESET gomb megnyomására a hidegindítási pontról elinduló programág ui. - mielőtt még "drasztikusabb" lépéseket tenne - megvizsgálja ezt a címet. Ha ez nem 0 (valamint a védett rendszerterületet (B217H-B251H) is épnek találja), akkor csak egy lényegesen kevesebb változással járó EXOS 0-t hajt végre, C = 10 RESET jelzővel. Előtte PUSH utasítással tárolja a talált RST-ADDR címet (így majd az EXOS 0 végén álló 'RET' hatására a felhasználó melegindítási rutinjára fog ugrani) és - ideiglenesen - 0-t ír a RST-ADDR cím helyére. Ezért, ha mégegyszer megnyomjuk a RESET gombot, mielőtt a melegindítással újraéled a rendszer, ez már valódi hidegindítást vált ki.

Befejezésként, az eddigiek szemléltetésére, rendszerezésére nézzünk meg egy-két programot, példát.
A 3. Függelékben összefoglalóan megadjuk a memória megismert térképét, a fontosabb rendszerváltozókat, mutatókat, de valószínűleg nem fog ártani egy konkrét példán (az eddig vizsgált verziójú gépen) megvizsgálni és értelmezni a ténylegesen kialakuló rendszermemóriát.
Ehhez készítsünk egy DUMP programot, egy olyan segédeszközt, amely (az áttekinthetőség érdekében hexadecimális formában) kiírja egy tetszőleges memóriaterület tartalmát. A program felhasználja a hexa-decimális és decimális-hexa konvertáló rutinokat (1. pl. az 1. fejezetet):

100 PROGRAM "Dump.bas"
110 NUMERIC D
120 DEF H$(N)=CHR$(INT(N/16)+48-7*(INT(N/16)>9))&CHR$(MOD(N,16)+48-7*(MOD(N,16)>9))
130 DEF DEC(H$)
140   LET D=0:LET Q=1
150   FOR N=LEN(H$) TO 1 STEP-1
160     LET D=D+ORD(HEX$(H$(N:N)))*Q
170     LET Q=Q*16
180   NEXT
190 END DEF
200 INPUT PROMPT "Kezdocim? ":A$
210 CALL DEC(A$)
220 LET KC=D
230 INPUT PROMPT "Vegcim? ":A$
240 CALL DEC(A$)
250 LET VC=D
260 INPUT PROMPT "Szegmens? ":A$
270 CALL DEC(A$)
280 LET SG=D
290 FOR N=KC TO VC STEP 8
300   LET A$=H$(N/256)&H$(MOD(N,256))
310   PRINT N;" ";A$;" ";
320   FOR I=0 TO 7
330     LET DT=SPEEK(SG,N+I)
340     PRINT H$(DT);" ";
350   NEXT
360   PRINT
370 NEXT
380 END

A program hexadecimális alakban kéri a kiírandó memóriaterület kezdő- és végcímét, valamint szegmensszámát. A kiíratásnál a kezdőcímek decimális alakját is megadja, így egy-egy cím közvetlenül is írható, olvasható.
Alkalmazásként próbáljuk ki programunkat az előzőekben felépített rendszerterületen, a rendszerváltozók tartományában:

Értelmezzük együtt ezt az - első látásra talán áttekinthetetlen - adattömeget, megadva a fontosabb változók, pointerek funkcióját:

A rendszerszegmens verem alatti, viszonylag állandó táblaterülete és az ez alatti mozgó csatornaterület a 8 hibátlan RAM-szegmenssel rendelkező, angol/német BASIC modullal felszerelt gép esetén a következőképpen alakul:

Tovább vizsgálva a rendszerváltozókat

(A fenti 7 adat a rendszerállapotként lekérdezhető adatsor). Ezután a 3 legutóbb használt (legkönnyebben elérendő) csatorna adatait találjuk:

A különböző láncok pointerei:

A láncokat egy külön programmal érdemes végigkövetni, de egyelőre nézzük végig a rendszerváltozókat:

Ez a rengeteg rendszerváltozó szinte ingerel a kísérletezésre, próbálgatásra. Mi biztatjuk is erre az Olvasót, hiszen - mint a bevezetőben is írtuk - ez a legbiztosabb módja a gép megismerésének. Biztatásként nézzünk egy-két példát együtt is az EXOS memóriaszervezésére!
Nézzük meg külön a szegmenskiutalások nyilvántartását (a rendszerállapot-területet):

Tehát 6 szabad szegmens van. Nyissunk meg most egy új BASIC programot (EDIT), majd lapozzunk vissza a DUMP programhoz, hogy megnézzük, milyen változások történtek:

Látható, hogy az EXOS egy szabad szegmenst kiutalt a felhasználó (jelen esetben a BASIC rendszer) számára, és be is könyvelte ezt a változást.
Lássunk most egy olyan változást, amely az EXOS területét érinti. Például egy nagy grafikus lap nyitása sok helyet igényel, és ezt az EXOS biztosítja:

Ismét csökkent tehát a szabad szegmensek száma, és a lefoglalt szegmensi saját magának utalta ki az EXOS. Ha nagyobb területet íratunk ki, azt is láthatjuk, hogy most előbbre (a RAM-tábla FEH szegmensére) mutat a BF9A/B (hiszen ebbe a szegmensbe került az EXOS határ).
Egy másik érdekes területe a rendszermemória "böngészésének" a különböző láncok követése. A lánc felépítési logikáját láttuk e fejezetben, de nézzük meg a 0. szegmens rutinján, hogyan keresi vissza maga a rendszer az elemeket:

A báziscím ismeretében mi is követhetjük ezt a logikát, akár egy BASIC programmal is.

100 PROGRAM "Lanc.bas"
110 NUMERIC D
120 DEF H$(N)=CHR$(INT(N/16)+48-7*(INT(N/16)>9))&CHR$(MOD(N,16)+48-7*(MOD(N,16)>9))
130 DEF DEC(H$)
140   LET D=0:LET Q=1
150   FOR N=LEN(H$) TO 1 STEP-1
160     LET D=D+ORD(HEX$(H$(N:N)))*Q
170     LET Q=Q*16
180   NEXT
190 END DEF
200 LET SGE=255
210 INPUT PROMPT "Baziscim? ":A$
220 CALL DEC(A$)
230 LET SG=SPEEK(SGE,D-1)
240 IF SG=0 THEN STOP
250 LET HL=SPEEK(SGE,D-3)+256*SPEEK(SGE,D-2)
260 LET A$=H$(HL/256)&H$(MOD(HL,256))
270 PRINT H$(SG);"/";A$;": ";
280 CALL LEIRO
290 LET SGE=SG
300 GOTO 220
310 DEF LEIRO
320   FOR N=HL-3 TO HL+7
330     LET DT=SPEEK(SG,N)
340     PRINT H$(DT);" ";
350   NEXT
360   CALL NEV
370 END DEF
380 DEF NEV
390   FOR N=1 TO DT
400     PRINT CHR$(SPEEK(SG,HL+7+N));
410   NEXT
420   PRINT
430 END DEF

A program a hexadecimális alakban beírható báziscím alól kiolvassa a következő láncelem szegmensszámát (a lánc végét jelzi, ha ez 0) és tárolási címét (HL), azaz a láncelem pointerét. Kiírja a pointert, majd a periférialeíró elemeit és a periféria nevét. Ezután a pointer értékét tekinti báziscímnek és így keresi a következő elemet. A LEIRO rutin ilyen formában kifejezetten a periférialeíró kiolvasására alkalmas.
A futtatás eredménye:

A rutin a pointer által címzett adat (a leíró TYPE-eleme) előtti 3 értéket is kiírja. Így pl. az 1. sor elemei:

• az első 3 adat (FF/6674) mutató az EDITOR perifériára
• 4.: TYPE (0, tehát ez a bejegyzés érvényes),
• 5.: IRQFLAG (20H, tehát a videomegszakításokat kezeli)
• 6.: FLAGS (0, nem VIDEO típus)
• 7/8.: TAB (04/5F8F, a billentyűzetkezelő belépési pontjainak táblázata)
• 9.: TAB-SEG
• 10.: UNIT COUNT (0, nem lehet több ilyen nevű leíró)
• 11.: NAME (8, a név betűinek száma)

A TYPE-elemek áttekintésével látható, hogy a 0. szegmens beépített KEYBOARD és EDITOR kezelőit a bővítőben csatlakoztatott 4. szegmens felülírta, érvénytelenítette. Ez a táblázat minden perifériaművelet alapja, tehát igen praktikusan felhasználható az esetleges átírásokra. Most csak egy durva beavatkozással szemléltetjük ezt a lehetőséget: érvénytelenítsük pl. a PRINTER-leírót, azaz írjunk 0-tól különböző értéket a TYPE mezőre. A mi példánkban a PRINTER-leíró (és egyben a TYPE adat) címe FF/66B3, azaz 255/26291. Írjuk be

SPOKE 255,26291,1

Ezután minden nyomtatóművelet "Gerat nicht vorhanden" ("Device does not exist") hibajelzéssel áll le, amíg vissza nem állítjuk az érvényes típust.

SPOKE 255,26291,0

A hasonló láncba felfűzött csatornák végigkövethetők ugyanezzel a programmal, de a leírók kilistázásához alakítsuk át a LEIRO rutint, hogy csak a pointer által megadott cím előtti 16 bájtot írja ki:

100 PROGRAM "Lanc2.bas"
310 DEF LEIRO
320   FOR N=HL-16 TO HL-1
330     LET DT=SPEEK(SG,N)
340     PRINT H$(DT);" ";
350   NEXT
360   PRINT
370 END DEF

A BASIC bejelentkezés után a következő (alapértelmezésűnek tekinthető) csatornák élnek a gépen:

A csatornákról még lesz szó, most a 16-bájtos csatornaleírók három elemére hívjuk fel a figyelmet (a kapott lista értelmezéséhez):

• A pointer által megadott tárolási cím előtt (itt a sorok utolsó 3 adata) itt is a következő elem mutatóját találjuk.
• A csatornaszámot (a belső kezeléshez 1-gyel megnövelve) a (báziscím - 5) mezőn (hátulról az 5.) tárolja az EXOS
• A -12., -13., -14. elemek - már az alakjukból is látszik, hogy ezek is pointerek - a csatornához rendelt periféria leírójára mutatnak.

Hogy még itt is kísérletezzünk, egy kicsit, nyissunk meg egy csatornát, és figyeljük meg, hogyan jelenik ez meg a láncban.

Az 5. csatornát (6-os belső értékkel) a kialakult lánc aljára vette föl az EXOS (ezzel érdemes egy kicsit kísérletezni: mi történik kisebb vagy nagyobb pufferigényű csatorna nyitásakor, egy csatorna lezárásakor stb.).
A pointer alapján megfigyelhetd, hogy a hozzárendelt periféria (FF/66B3) valóban a PRINTER.
Érdemes még egybevetni az új láncelem adatait a rendszermemóriáról készült legelső DUMP-pel. Ott láthattuk, hogy az igénybevett rendszerterület alsó határa az EXOS határ; (BF91) (13C7) volt, ill. 1. LAP címként értve: 53C7H. Látható, hogy az új láncelemet éppen ettől a címtől illesztette a rendszermemóriához az EXOS (és a határt nyilván lefelé mozgatta).

Befejezésül próbálkozzunk egy-két olyan beavatkozással, aminek még hasznát is vehetjük a továbbiakban. Vessünk egy pillantást a rendszer által használható memóriaterületek könyvtárára, a ROM- és RAM-szegmensek táblázatára. A fejezetben leírtak és a rendszerváltozók aktuális értéke alapján a ROM-tábla alsó címe (BF97/8H értéke) ABB9H, a RAM-tábla felső címe pedig ABD0H (ez rögzített érték).

Láthatjuk a bejegyzett ROM-ok szegmensszámát (1,4,5), előttük a számukra kiutalt RAM-terület mutatóját (itt csak a 4. szegmens kért RAM-ot; az FFH szegmens A706H címén kezdődő területet kapta), majd a RAM szegmensszámokat.
Hogy szemléltessük, milyen nagy biztonsággal kezeli a rendszer a rendelkezésére álló memóriákat, próbáljunk ki egy drasztikus beavatkozást. Próbáljuk meg egyszerűen kitörölni az egyik RAM-szegmenst a táblázatból.
Nézzük meg ismét a rendszerállapotot és a RAM-táblázatot:

Írjunk 0-t pl. az FCH szegmens helyére:

POKE 43981,0

majd lássuk újra a két területet:

Láthatjuk, hogy az EXOS túltette magát az összezavart táblázattal elékerülő problémán. A START után elénk kerülő memóriakép már ismét egy egészséges táblát mutat, csak éppen hiányzik a listáról a kiiktatott szegmens. A rendszerállapot azt mutatja, hogy a változásnak megfelelően csökkent (5-re) a szabad szegmensek száma is. A hiányzó szegmenst az EXOS mint "felhasználónak kiutaltat" könyvelte el.
Ha BASIC programok nyitásával (alulról) vagy grafikus lapok nyitásával (felülről) megterheljük a memóriakezelést, meggyőződhetünk róla, hogy az EXOS valóban nem számol a törölt szegmenssel. Igen egyszerű módon - szinte hályogkovács módjára - hozzájutottunk tehát egy olyan szegmenshez, amely általunk szabadon használható, a rendszer viszont nem bolygatja a továbbiakban (a készítők persze nem ezt a módszert képzelték el a szegmensigényléshez; erről is lesz szó a következő pontban).
Reméljük, hogy kellőképpen felkeltettük az Olvasó érdeklődését. Szinte kínálkozik a következő lépés: a ROM-tábla! Abba nem nyúlhatnánk bele? Dehogynem, csak egy kicsit óvatosabban. Azonnal végrehajtható, előkészületet nem igénylő próbálkozásként iktassuk be a (rendszertől az imént elorzott) FCH szegmenst a BASIC-BRD (4.) ROM-szegmens helyére (lemondva persze ezzel a német verzió minden előnyéről). Előzőleg csak annyit tegyünk meg, hogy egy 'RET' utasítást helyezzünk az új ál-ROM belépési pontjára, hiszen valójában még semmilyen program nem fogadja a hozzá forduló EXOS-t:

SPOKE 252,10,201

Ezután már következhet a szegmensszámcsere:

POKE 43969,252

majd adjunk ki egy olyan utasítást, amely inicializálja a rendszert (pl. :BASIC).
Az újonnan induló rendszer már nem tartalmazza a 4. szegmens szolgáltatásait (erről meggyőződhetünk pl. a periférialánc kiolvasásával vagy egy :HELP utasítással), tartalmazhat viszont mindent, amit mi írunk a szegmensbe. Ha meggondoljuk, hogy ezzel a lépéssel egy teljes értékű ROM-hoz jutottunk, ami részt vehet a rendszer inicializálásában, saját perifériái lehetnek (amik megmaradnak akkor is, ha egy másik alkalmazói programba, pl. szövegszerkesztőbe lépünk) és ráadásul - az előéletnek köszönhetően - még egy védett, könnyen elérhető RAM-területtel is rendelkezhetünk, beláthatjuk, hogy a lehetőségeknek valóban csak a fantázia szab határt.

2.3.2 A funkcióhívások

Az EXOS rendkívül kényelmes lehetőséget ad a felhasználónak a rendszerszolgáltatások elérésére. Minden EXOS funkció - az inicializálástól a memóriagazdálkodáson át a perifériakezelők által megvalósított csatornaműveletekig - elérhető egy kétbájtos gépi kódú utasítással. Még ha hozzávesszük is ehhez, hogy a műveletek esetleges paramétereit (pl. kiíratandó szöveg kezdőcímét, igényelt memóriaterület nagyságát stb.) természetesen be kell állítanunk a hívás előtt a megfelelő regiszterekben, nyilvánvaló, hogy ennél tömörebb gépi kódú programírási lehetőséget semmilyen rendszer nem kínálhat. Minden alkalmazói program (pl. a BASIC értelmező is) rendszeresen él a funkcióhívások lehetőségével. Mi sem mellőzzük ezeket. Annyi mindent elvégez a rendszer a funkcióhívások végrehajtása során - végrehajtó rutinok és pufferterületek kikeresése, memóriaellenőrzés és rendezés, lapozás stb. -, hogy fölmerülhet a kérdés: érdemes-e egyáltalán a funkcióhívás megkerülésének, a végrehajtó rutinok közvetlen hívásának gondolatával foglalkozni. Nos, ha valóban mindazt meg kell csinálnunk, amit az EXOS elvégez, akkor nem érdemes! Lehetnek azonban olyan esetek (pl. egy kialakított képernyőlap és állandósult csatornaállapot), amikor a báziscímek egyszeri megkeresése után, a végrehajtó rutinok címeinek ismeretében túl körülményesnek (és főleg időigényesnek) tűnik a hosszadalmas ágak bejárása minden egyes műveletnél. Ez az érzésünk még valószínűleg fokozódik is, ha végigkövetjük azt az utat, ahogy az EXOS a funkcióhívás kiadásától eljut a konkrét végrehajtásig. Mégis érdemes ezt az elemzést megtennünk, ha mélyebben meg akarunk ismerkedni gépünkkel. Akkor is ismernünk kell a működés egyes részleteit, ha saját perifériakezelőt akarunk a rendszerhez illeszteni, amit viszont majd az EXOS hív a funkcióhívások során.
Ha fel akarjuk használni a háttérrendszer szolgáltatásait, feltétlenül ismernünk kell az alkalmazás korlátait és lehetőségeit, feltételeit és várható eredményeit. Ezekről a kérdésekről magas színvonalon ír az EXOS műszaki leírása is, mi viszont a működés követésével és konkrét információkkal próbálunk meg újat mondani. A következőkben a programozástechnikai szempontból talán legérdekesebb bevezető és záró szakaszt a ROM rutinjainak elemzésével követjük, a kevésbé áttekinthető, hosszadalmasabb ágakat pedig funkcionálisan írjuk le.
Kezdjük az alapproblémával: kétbájtos utasításról beszéltünk, ugyanakkor sokféle összetett funkcióról. A gépi kódú programozással esetleg most ismerkedő Olvasó talán ellentmondást érez a két állítás között. A rendszer kifejlesztőinek valóban egy trükköt kellett alkalmazniuk a megoldáshoz. A továbbiakban "EXOS n"-ként emlegetett funkcióhívás valójában egy. RST 30H Z80-as utasítás, amelyet a memóriában az argumentum: n követ (n értéke 0 és 11 vagy 16 és 34 közötti lehet). Az egybájtos utasítással hívható szubrutinnak (a 0030H címen kezdődő programnak) kell majd az őt hívó memóriaterületről az argumentumot beolvasni, és az értéknek megfelelően különböző funkciókat végrehajtani. Bonyolítja a helyzetet, hogy a hívások különböző csoportjait eltérő módon kell kezelni: egy részüket közvetlenül végrehajtja az EXOS, a csatornaműveleteket viszont a perifériakezelőknek kell átadni. Látható tehát, hogy a formai egyszerűségnek ára van, mind helyfoglalásban (ez a kevésbé érdekes, hiszen a gép készítői szokatlanul bőkezűen bántak a memóriával), mind futásidőben.
Hogy a továbbiakban tudjunk mire hivatkozni, megadjuk a funkcióhívások egyszerű felsorolását:

Ezek után lássuk, mi történik, ha az alkalmazó programja egy EXOS hívást tartalmaz:

A processzor a 0030H címre ugrik, az őt követő (a processzor feltevése szerint a visszatérési) cím pedig a verembe kerül.

A vezérlés tehát a 0. ROM-szegmensre kerül. Itt

• tárolja a hívó 2. LAP szegmensét és HL regiszterét,
• a belapozott rendszerszegmensről beolvassa a jelzőbájtot.

Ennek kettős funkciója van. Ha 7. bitje 1, az EXOS verem rendezett. További bitjein csak akkor van 0-tól különböző érték, ha valamilyen perifériaművelet közben történt a hívás. Ez lesz majd a tiltó feltétel bizonyos (perifériák számára tilos) funkcióknál (pl. csatornanyitás, -zárás).

A kialakuló státuszban az átvitelbit csak akkor lehet 1, ha a vezérlés máshonnan (konkrétan a 0038H címen induló megszakításkezelőről) került ide. Ez a bit téríti majd el a közös előkészítés után a megszakítás rutint.
Ezután a hívó rendszerállapotának további mentése és a saját visszatérési ág előkészítése következik:

Ennyi előkészítés után az EXOS végre előveszi a tárolt funkciókódot és elkezdi a szétválogatást. Az egyetlen funkció, amit azonnal lekérdez és minden feltétel nélkül végre is hajt, a rendszerváltozók elérése (EXOS 16):

Az összes további funkciót már csak akkor végzi el, ha a beállított CY bit sértetlenül túléli a saját visszatérési ágban való megfordulást:

A C580H rutin ui. - mint látni fogjuk - mindenekelőtt a CY bitet ellenőrzi, és ha törlődött, ILLFN hibára fut. De vajon mi történhet ezzel a bittel a visszatérési ágban? Alapesetben itt csak egy EI:RET utasítássort talál, tehát nem változik. Ha azonban éppen megszakításkezelés folyik, a kezelő átírta ezt a címet OR A:RET-re. Megszakítások kezelése közben tehát az EXOS nem fogad el funkcióhívásokat (kivéve az EXOS változók írását, olvasását).
Egyelőre fogadjuk el, hogy megtörténik a funkcióhívások szétválogatása és végrehajtása. Most azt nézzük meg, hogyan tér vissza a rendszer a hívóhoz. Mindenekelőtt visszaállítja a hívó regisztereit és LAP-konfigurációját:

Ezután pedig ellát egy - a felhasználó számára igen érdekes - feladatot: a szoftver megszakítás kezelését (pontosabban indítását). A rutin a BFF2H rendszerváltozó (FLAG-SOFT-IRQ) értékét teszteli. Ide pl. valamelyik megszakításkezelő (billentyűzet, hálózat) írhatott be értéket. Ha a rendszer 0-tól különböző értéket talál itt, és a 003D/E címen is értelmes (0-tól különböző) érték (a felhasználói szoftver megszakításkezelő címe) van, úgy változtatja meg saját visszatérési ágát, hogy onnan majd egy JP nn-re kerüljön:

Egy kis kitérőként próbáljuk ki ezt a lehetőséget:

10 PRINT 1
20 POKE 49138,33
30 GOTO 10

A szoftvermegszakítás egy EXOS funkcióhívás után történik meg, tehát a rendszer a második kiírásnál vette észre a megszakítási kódot. A megszakítás BASIC-ben való kezeléséről később lesz szó.
Térjünk vissza a funkcióhíváshoz és kövessük a befejezés lépéseit:

A visszatérési ág változhat az előzményektől függően. Egy átlagos funkcióhívásnál már csak a hívó 2. LAP szegmensének visszalapozása van hátra a teljes rendszerállapot visszaállításához. Itt kapja meg az A egy ügyes trükkel azt az értéket, amit a végrehajtó rutin adott vissza (a hibakódot vagy 0-t), és a C46DH című utasítással tárolt le a rendszer éppen a LD A,n utasítás argumentumaként.

Ha szoftvermegszakítás történt, a rutin legvége másként alakul:

Áttekintettük tehát az EXOS funkcióhívás főágát, működési logikáját. Nem láttuk viszont még a funkciók tényleges szétválogatását (kivéve az EXOS 16-ot). Térjünk tehát vissza ehhez a mozzanathoz.
A rutin először (az EXOS 0 kiemelése mellett) a hibás argumentumokat szűri ki (a törölt CY bit jelentésével már foglalkoztunk).

Mint látható, az EXOS 1-11 hívásokat egy csoportban kezeli a rendszer. Az EXOS 0 végrehajtási címe C653H, a 17-34 közötti funkcióhívások belépési pontjait pedig egy ROM-táblázatból határozza meg a program:

A táblázat:

Ezzel tehát megismertük a 0. és 16-34. funkcióhívások belépési pontjait. Foglaljuk össze, milyen feltételekkel indul ezeknek a rutinoknak a végrehajtása. A regiszterek általában eredeti értékükkel lépnek be. Kivétel ez alól a HL és az A, ezeket használta a rendszer a belépésig. Fontos viszont, hogy az AF' regiszter milyen értéket tartalmaz. A'-ben a hívás előtti akkumulátorértéknek kell lenni (pl. csatornaszám), F' pedig a C430H-n leírt hívási státusz.
Keményebb dió az 1.-11. funkciók csoportjának kezelése, a végrehajtókhoz való eljuttatás követése. Néhány dolgot érdemes összefoglalóan elmondani a perifériakezelőkről és a csatornákról, hogy jobban megérthessük a rendszer működését. Mi a közös az egy csoportban kezelt funkcióhívásokban? A felsorolásból láthatjuk, hogy ezek kivétel nélkül csatornákkal kapcsolatos műveleteket végeznek: nyitás, zárás, kivitel, beolvasás, vezérlés. Nyilvánvaló hogy a csatornaművelet önmagában értelmetlen dolog, a csatornáknak mindig valamilyen perifériához kell kapcsolódniuk. Ha pl. egy karaktert írunk a 104-es csatornába, ennek csak akkor van értelme, ha ehhez a számhoz egy perifériakezelő kötődik (jelen esetben a PRINTER), ami tudja, hogy mit kell kezdenie a kapott karakterrel.
Természetes tehát, hogy a csatornák élete a csatornaszám és perifériakezelő egymáshoz rendelésével (és az ezt nyilvántartó leíró elkészítésével) kezdődik és az összekapcsolás megszüntetésével fejeződik be. Ezt a funkciót még el tudná végezni belső rutinjaiban is az EXOS (pusztán az előző pontban megismert periférialánc adatai alapján), de a rendszer a csatornanyitási művelet során nemcsak ezt a (16-bájtos) leírót hozza létre. A csatornaműveletek egyszerűsítésére az EXOS közvetlenül a leíró alá illeszti a periféria által az adott esetben igényelt RAM-területet: a csatornapuffert (aminek felső határát meg is adja a perifériakezelőnek - mint látni fogjuk - minden híváskor az IX regiszterpárban). Azt pedig, hogy az adott csatorna létezéséhez, működtetéséhez mekkora pufferterületre van szükség, ismét csak a hozzárendelt perifériakezelő tudhatja. A PRINTER-kezelő pl. nem igényel külön RAM-ot a munkájához, a VIDEO rendszer viszont a legkülönbözőbb méretű puffereket kérheti, amit saját maga számol ki a kijelzési módot és a videolap méreteit meghatározó rendszerváltozók alapján.
Ezek alapján a csatornanyitási és -zárási műveleteket is a perifériakezelőkre kell bízni - legalábbis ami a szükséges pufferméret meghatározását illeti. A puffer kiutalását és nyilvántartásba vételét természetesen ismét a - minden memóriamenedzselési feladatot magára vállaló - rendszerprogramtól kell kérni (EXOS 27), majd a megkapott RAM-területtel ismét a kezelő rendelkezhet saját igényei szerint (pl. bejegyezheti a megnyitott videolap paramétereit).
A rendkívül felhasználócentrikus EXOS több lehetőséget is ad tetszőleges perifériakezelők létrehozására és rendszerbe illesztésére. Az egységes elérhetőség érdekében azonban ezeknek a kezelőknek - bizonyos pontjaikon - szabványosnak kell lenniük. Ilyen a periféria álleírója, amivel a 2.5 alfejezetben még foglalkozunk, és a kezelő végrehajtó rutinjainak belépési pontjait is egy egységes táblázatba kell rendezni. Ez a táblázat - kétbájtos címek egymásutánja - adott sorrendben tartalmazza a csatornaműveletek teendőit ellátó rutincímeket (és még néhány más alprogramot). Az EXOS 1, 2, ... stb. funkciók tényleges végrehajtóinak címe ezen táblázat 1., 2. stb. eleme. Az általában közvetlenül az álleíró után elhelyezett táblázat kezdőcímét a leíró TAB eleme adja meg (3. LAP címként).
Ahhoz, hogy az EXOS n funkcióhívás ebből a táblázatból megállapíthassa a végrehajtó kezelő alprogram címét, előbb a csatornaszám (a funkció hívásakor az A regiszterben megadott érték) alapján meg kell keresnie a hozzárendelt periférialeírót. Erre szolgál - többek között - a csatornaleírók lánca.
Mint az előbb már utaltunk rá, egy csatorna megnyitásakor a szükséges paramétereket az EXOS egy 16-bájtos csatornaleíróban könyvtárazza be. Ezeket a leírókat láncszerűen kapcsolja egymáshoz (erről az előbbi pontban már írtunk, és ki is olvastuk az aktuális leíróláncot). A BFBDH báziscím alatti pointer az első csatornaleíró fölé mutat. Ehhez az új báziscímhez képest a -1., -2. és -3. elem a következő csatornaleíró mutatója: a leírót tartalmazó szegmens számát (-1:) és címét (LO:-3., HL-2.) adja meg. A -5. bájt a belső csatornaszám (a hívó által megadott csatornaszám +1). Ezután a rendszer belső paramétereket tárol (pl. az igényelt területék nagyságát a puffer mozgatásához), majd egy újabb pointer következik: a csatornához rendelt periféria mutatója; szegmensszám a -12., leírócím a -13. és -14. bájton.
Hogy egy konkrét példát is lássunk, vizsgáljuk meg az előző fejezetben példaként kiíratott csatornalánc első leíróját. A BFBDH bázisszám alatti pointer: FF/665C. Az e cím előtti 16 bájt:
00 00 F9 66 FF 00 00 80 04 C0 00 67 00 DC 61 FF.
A leíró említett elemei:

665C - 01 FF
665C - 02 61
665C - 03 DC: a következő leíró báziscíme: FF/61 DC
665C - 05 67: a leíró a 66H csatornához tartozik (ez a BASIC £102-es VIDEO csatornája)
665C - 0C FF
665C - 0D 66
665C - 0E F9: a periférialeíró pointere.

A kijelölt periféria (ugyancsak az előző fejezet példájaként kiírt periférialánc alapján) a VIDEO.
A pointer alatti két bájtot ugyancsak a rendszer használja a csatornaátirányítások bejegyzésére. Mint az EXOS 17 és 18 funkcióknál látni fogjuk, az adott csatorna helyett használandó másodlagos csatorna számát a báziscím -15. (átirányítás olvasáshoz), ill. báziscím -16. (átirányítás íráshoz) címen jegyzi be a rendszer.
A csatornaterületeket a rendszermemória alján építi fel az EXOS. Ha a perifériakezelő az adott csatorna nyitásához nem igényel RAM-ot, a 16-bájtos leíró alsó címe lesz az új EXOS határ. Ha puffer is tartozik a csatornához, az itt kezdődik (az EXOS a (báziscím -16) értéket adja meg a kiutalt pufferterület báziscímeként az IX regiszterben). A következő csatornanyitáskor az új leíró már a lefoglalt csatornapuffer alatt kap helyet.
A csatornakezelés meggyorsításához még egy fogást alkalmaz az operációs rendszer. A rendszerváltozók területén, a BFA5H címtál kezdődően néhány bájtot fenntart azoknak a csatornáknak a paramétereihez, amelyekkel a legutóbb foglalkozott (és így feltételezhetően a leggyakrabban használt, leggyorsabban elérendő csatornák). Minden csatornához 4 bájtot rendel: a csatorna (belső) számát és a leíró pointerét. Három ilyen blokkot kezel ezen az aktuális csatornaterületen. Ha egy új csatornával kell foglalkoznia, egy blokkal (4 bájttal) feljebb tolja ezt a tartományt (ezzel a legrégebben használt csatornaparaméter blokkja kiesik) és felveszi az új csatorna paramétereit. Ez a 3 blokk éppen elég a számítógép működési idejének jelentós részét kitevő szerkesztési műveletekhez (EDITOR, KEYBOARD, VIDEO), így az alapcsatornákat nem kell a leíróláncban keresgélnie, mindig kéznél vannak (ezt az állapotot láthattuk az előző pont végén a rendszerváltozókról készített DUMP értelmezésénél).
Ezek után kövessük végig: milyen lépéseket tesz meg az EXOS, amíg a vezérlést átadja a funkcióhívást végrehajtó perifériakezelőnek.

• Verembe menti a háttérregisztereket.
• A csatorna nyitás-zárás funkcióknál ellenőrzi, hogy nem egy perifériakezelőből jött-e a hívás (hívási státusz!), ez ui. tiltott funkció.
• A hívott csatornaszámot (az akkumulátorban átadott értéket) megnöveli 1-gyel. Ez lesz a belső csatornaszám. Ha a hívás az FFH csatornára vonatkozott, helyettesíti azt a DEF-CHAN rendszerváltozó (BFC9H) aktuális értékével (kivéve, ha az is FFH volt, ez az eset ICHAN hibát eredményez).
• Ezután a funkciókezelés két részre válik szét.

1. A csatornanyitási, létrehozási funkció (EXOS 1, 2) esetén

• a BFBDH báziscímről induló csatornaláncot végignézi, nincs-e már megnyitva a kérdéses csatorna. Ha megtalálja, CHANX hibajelzéssel tér vissza;
• ezután a csatornához rendelt periféria nevével foglalkozik. A DE regiszterpárt erre a névre (pontosabban a név előtti hosszbájtra) állította a hívó, saját memóriakonfigurációjának bármely LAP-ján. Az EXOS a DE címet az 1. LAP-ra transzformálja és (a USER-P1, ..., P3 rendszerváltozók alapján) idelapozza a nevet tartalmazó szegmenet.
  A név karaktereit az első kettőspontig - nagybetűsítve és ellenőrizve - átviszi a BF54H címen kezdődő pufferbe. Ha a név 0 hosszúságú vagy nem tartalmaz kettőspontot (ilyen pl. az OPEN £1:"ADATFILE" típusú megnyitás), az inicializálás során beállított alapértelmezésű eszköznevet (esetünkben: TAPE) írja a pufferbe (l. még: EXOS 19);
• a következő lépésben a pufferben tárolt periférianevet keresi meg a periférialáncban. Ha nem talál ilyen eszköznevet, ":NODEV" hibával tér vissza;
• munkaterületre tölti a funkciók elvégzéséhez szükséges paramétereket:

• az előkészítés után meghívja az adott perifériakezelő megfelelő (1. vagy 2.) rutinját. A meghívás konkrét módját érdemes végigkövetni a 0. szegmens - minden csatornakezelő funkcióhívásban alkalmazott - rutinján. A rutin a veremméret és a perifériaérvényesség ellenőrzésével kezdődik.

A rendszer ezután beállítja a perifériakezelőnek átadandó IY és B' paramétereket, majd a belépési pont-táblázatból beolvassa az A-ban hozott funkciószámhoz tartozó címet.

Az előkészítés után meghívja a perifériakezelő végrehajtó rutinját a B217H lapozórutin közvetítésével. Előtte átállítja a hívási státuszt meghatározó BF79H jelzőbájtot, hiszen ezután perifériaprogram fut. Ez a bájt egészen a visszatérésig (amikor újra alapértékre áll) tilt bizonyos funkcióhívásokat.

A perifériakezelő végrehajtó rutinjából való visszatérés után - az 1. és 2. funkcióhívások szétválogató ágának befejezéseként még ellenőrzi a BF89H jelzőbájton (amit maga állított FFH-re a kezelő hívása előtt), hogy nem feledkezett-e meg a periféria csatornanyitásért felelős rutinja a pufferigénylésről (EXOS 27 hívás). Ez akkor is kötelező, ha a periféria nem igényel puffert, mert a csatornaleírót is ez a funkcióhívás hozza létre, majd - jelezve, hogy feladatát ellátta - 0-ra állítja a fenti jelzőbájtot. Erre tehát nekünk is ügyelnünk kell egy esetleges új periféria létrehozásakor.

2. A fennmaradó csatornaműveleteket (EXOS 3-11) másképp készíti elő rendszer.

• Mindenekelőtt megkeresi a szóban forgó csatorna leíróját. Először az aktuális csatornák között keres (BFA5H-tól). Ha itt nincs bejegyezve az adott csatorna, végigvizsgálja a BFBDH báziscímről induló csatornaláncot is (ha itt sem találja, ICHAN hibával visszatér). Ha megtalálja a leírót, azt bevezeti az aktuális területre is, mint legfrissebb csatornát.
• A csatorna leírójában ellenőrzi, hogy a funkcióhívásnak megfelelő irányban (írás vagy olvasás) nincs-e átirányítva az adott csatorna egy másik csatornaszámra. Ha igen, újrakezdi a keresést erre a másodlagos csatornára. A csatornakeresés mechanizmusának mi is hasznát vehetjük. Nézzük meg, hogyan csinálja ezt a 0. ROM CD3AH rutinja:

Ha a rutinból (Z) státusszal tér vissza a program, nem találta meg a keresett csatornaszámot. Ha viszont megtalálta, HL-ben a leíró báziscíme, A-ban a szegmense található. Érdemes megjegyezni, hogy ezt a pointert a BF81/2H, ill. BF83H munkaterületre is letárolta a keresőrutin.
Az előkészítés befejezéseként az EXOS beállítja a végrehajtó rutinnak átadandó paramétereket. Az IX regiszterbe a csatornaleíró báziscíme -16 értéket tölt. Így IX a leíró legalsó bájtjára mutat, alatta kezdődik a csatorna RAM-területe. A perifériaművelet kezelése során tehát IX-ben van az adott csatornához kiutalt puffer báziscíme. Ezt tehát feltétlenül be kell állítanunk egy esetleges közvetlen hívás előtt is.
Ezután a leíróból beolvassa a csatornához rendelt periféria báziscímét, és a már megismert módon (a C53EH rutin felhasználásával) belapozza és meghívja a belépési címtáblázat funkcióhívásnak megfelelő sorszámú rutinját (tehát pl. EXOS 7 esetén a 7. rutint).
Ezzel gyakorlatilag be is fejezte az EXOS a csatorna I/O műveletek kezelését. A csatornát lezáró (EXOS 3, 4) funkcióhívásoknál még elvégzi a memóriarendezési feladatokat, majd a háttérregiszterek visszaállítása után innen is rátér a rendszerhívások - már megismert - visszatérési ágára.

Foglaljuk végül össze, milyen feltételeket biztosít, milyen paramétereket ad át az EXOS a funkcióhívások végrehajtóinak, a perifériakezelőknek:

• A memóriakonfiguráció:

• A regiszterek:

A kezelőtől az EXOS nem várja el egyik regiszter -megőrzését sem, de maga megőrzi és a hívónak továbbadja a kezelőtől visszakapott A, BC és DE regisztereket.
Végül a funkcióhívások konkrét áttekintése előtt még egy közös vonatkozású megjegyzés. A leírás során többször említettük, hogy adott esetben az EXOS valamilyen hibával tér vissza. Valójában maga az EXOS nem ad semmilyen hibaüzenetet, kizárólag az A visszaadott értékében (ill. a státuszban) jelzi, ha valami rendellenesség történt. A hívó feladata, hogy a visszatérés után ellenőrizze a státuszt és NZ esetén megtegye a szükséges lépéseket. A hibakódokat a 4. Függelékben soroljuk fel.
Ezek után vegyük sorra az EXOS funkcióhívásokat, konkrét adatokkal, példákkal segítve az alkalmazásukat. A példákat általában BASIC-ben építjük fel, hogy segédeszköz nélkül, könnyen kipróbálhatók legyenek. A kimenő adatok között nem említjük külön a minden hívásnál visszaadott (esetleges hibára utaló) státuszt.

A funkció közvetlen hívása nehezen megoldható (a sajátos visszatérési út miatt), de nem is igazán indokolt: a rendszerinicializálás nem az a terület, ahol a megtakarítható mikro- (vagy akár mili-) szekundumoknak jelentősége lenne. Szokásos úton való hívása viszont egyszerű:

LD C,XX
EXOS 00
RET

BASIC-ből betöltött gépi kódú rutinnal:

100 ALLOCATE 100
110 CODE M=HEX$("0E,XX,F7,00,C9")
120 CALL USR(M,0)

Természetesen "XX" helyére az inicializálási lépéseket kiváltó biteket tartalmazó hexadecimális értéket kell írni. A kísérletezve megismerés jegyében javasoljuk az Olvasónak, hogy próbálja ki a hívást különféle beavatkozások után a 00, 10, 20, 40, 60, 80 értékekkel (ez utóbbival csak akkor, ha nincs a gépben féltett program).
Hogy az első komolyabb beavatkozásunkat megtegyük (aminek még sok hasznát vehetjük a továbbiakban), próbáljuk meg saját igényeinknek megfelelően átalakítani a memóriatérképet. Építsünk be a ROM-szegmensek táblázatába egy új elemet valamelyik RAM-szegmens számával. Egy ilyen könyvtárazott ál-ROM előnyeiről már írtunk a 2.3.1 pontban, de ott csak egy igen drasztikus lépéssel, 4. szegmens feláldozásával, értünk el ilyen hatást. Ha valaki nem akar lemondani a 4. szegmens szolgáltatásairól (pl. mert a billentyűzet adott kiosztását szokta meg), vagy egyszerűen nincs is a gépén ilyen helyettesíthető szegmens (egynyelvű verzió), fölvetheti a hidegindítás folyamatának követése alapján: nem lehetne-e a ROM-táblát annyival lejjebb tolni, hogy a tetejére beírhassuk a felvenni kívánt szegmens számát, az így kialakult új táblahatártól pedig újra felépíttetni a rendszermemória ez alatti részeit (ROM-szegmensek RAM-területe, periférialánc, csatornalánc).
Nos, mindennek semmi akadálya, csak a konkrét végrehajtáshoz figyelmesen szemügyre kell venni a beavatkozás előtti rendszerállapotot (kinek-kinek a saját gépén). Az érintett változóterület listája (a 2.3.1 pontban ismertetett DUMP programmal):

A RAM- és ROM-táblák területe pedig:

Esetünkben az ABB9H-ABC9H közötti bájtokat kellene eltolni lefelé (helyet csinálva egy új 4-bájtos táblaelemnek). A konkrét címek ismeretében ezt egyszerűen megoldhatjuk, de nem különösebben bonyolult az általános (a mozgatandó terület határait és méretét a rendszerváltozók alapján megállapító) megoldás sem.
Milyen változókat kell figyelembe venni:
BF97/8H: a mozgatandó terület alsó címe (ROM-tábla alja)
BF9C/DH: a mozgatandó terület felső címe + 1 (RAM-tábla alja).
A két cím különbsége adja a mozgatandó terület nagyságát. Ezek alapján felírhatjuk a program mozgató részét.
A blokk eltolása után már csak két feladatunk maradt:

• a bejegyezni kívánt szegmens számát (példánkban FCH) beírjuk a volt legfelső elem helyére,
• a ROM-tábla új alsó címére állítjuk a megfelelő rendszerváltozókat, majd meghívjuk az EXOS 0 funkciót, hogy végigvezesse a memóriában a változásokat. A blokkmozgatással belecsúsztunk a 4. szegmensnek kiutalt RAM-területbe, ezért úgy állítjuk be a funkcióhívás jelzőit, hogy a ROM-ok RAM-igényét is újra elégítse ki.

Ezek után a feladatokat ellátó assembly program:

ill. ugyanez BASIC betöltővel:

100 POKE 540,0
111 POKE 541,48
120 CODE M=HEX$("ED,5B,97,BF,2A,9C,BF,B7,ED,52, E5,C1,EB,E5,11,04,00,ED,52,EB, E1,D5,ED,B0,11,04, 00,ED,52,36, FC,E1,22,97,BF,22,95,BF,AF,32, 78,BF,0E,60,F7,00, C9")
130 SPOKE 252,10,201
140 CALL USR(M,0)

A rutin tárolására választott 3000H cím a BASIC terület közepén van ugyan, de - éppen ezért - kis programok esetén különösebb védelem nélkül is megfelel a rutinok ideiglenes tárolására.
Az EXOS 0 kiváltotta inicializálási folyamatban már az újonnan bejegyzett ROM-szegmens is részt vesz, ezért ne feledkezzünk meg a rutin végrehajtása előtt a szegmens belépési pontját (C00AH a 3. LAP-on) megfelelően kialakítani. Ennek legegyszerűbb módját láthatjuk a BASIC betöltőprogram 130. sorában, ami - egyelőre - egy RET utasításkódot ír a szegmens 10. bájtjára.
Az EXOS 0 hívás törli a melegindítási címet, szoftvermegszakítási címet. Hogy egyértelművé tegyük a BASIC alaphelyzetet, a rutin futtatása után adjunk ki egy BASIC utasítást. Ez ugyan törli a betöltőprogramot is, de az már ellátta a feladatát.
Ellenőrizzük a rendszermemória területeit, változóit, hogy rendben megtörtént-e a változás a teljes rendszerben.

Örömmel láthatjuk, hogy a ROM-tábla alatti területekhez tartozó összes cím, mutató értéke 4-gyel csökkent. Lejjebb csúszott a periférialánc, a csatornaterület és - természetesen - az EXOS határ is. Maga a megváltoztatott ROM-tábla:

Ez tartalmazza (az 5. szegmens előző helyén) a bejegyezni kívánt ál-ROM-ot (FCH), a többi blokk pedig lefelé tolódott. A 4. szegmens blokkjában jól látható, hogy a rendszer újra kiutalta számára az igényelt RAM-területet (természetesen 4-gyel kisebb kezdőcímmel).
Végül ellenőrizzük, hogy a periférialánc hogyan épült újra. A 2.3.1 pontban leírt LANC program futtatásával (az ott kapott listával egybevetve) láthatjuk, hogy a ROM-tábla valamennyi perifériája beláncolódott a hidegindítással analóg módon, csak kisebb báziscímekkel:

A könyvtárazott ROM-szegmens most már a rendszerhez tartozik kikapcsolásig. Ha komoly feladatokat akarunk vele elláttatni, akkor persze a bejegyzett szegmenst védeni kell, meg kell akadályozni, hogy a rendszer felhasználhassa (pl. az EXOS 24 funkcióhívás segítségével).
Egyszerűbb kísérletezéshez azonban így is felhasználhatjuk a szegmenst. Érdekességként - a géppel való ismerkedést segítendő - írjunk pl. a belépési pontra egy egyszerű rutint, amely a hívási kód értékét (C regiszter) minden hozzáforduláskor kiírja az állapotsorba (az egyszerűség kedvéért egy nem törlődő, szabadon használható karakterhelyre).
A feladat megoldása igen egyszerű:

BASIC betöltővel:

100 ALLOCATE 100
110 CODE M=HEX$("C9,21,BD,BE,3E,30,81,77,C9")
120 FOR N=0 TO 10
130   SPOKE 252,10+N,PEEK (M+N)
140 NEXT

A 252. szegmens belépési pontjára áttöltött rutin továbbra is RET tel kezdődik. A kijelzési funkció így egy

SPOKE 252,10,0

utasítással aktivizálható és

SPOKE 252,10,201

utasítással kapcsolható ki. Érdemes kipróbálni a különböző - bővítőket is hívó - utasításokat (:HELP; :SZÖVEG; hibát okozó EXOS hívás, pl. nem létező csatornára írás; a RESET gomb megnyomása stb.). Az indítási kódokról még lesz szó a 2.6 alfejezetben.
Még figyelemfelkeltőbb a ROM-ok lekérdezése, ha valamilyen hanghatással is jár. Erre igen egyszerűen felhasználható pl. a BASIC PING utasítás végrehajtó rutinja (5. szegmens, D3BFH cím), csak azt a problémát kell megoldani, hogy a 3. LAP-on hívott bővítő hogyan hívja egy másik szegmens rutinját ugyanezen a lapon. Az egyik lehetséges megoldás, hogy a bővítő programja ellapozza saját magát (az 1. LAP-ra) és ott folytatja a futást:

Ennek megfelelően kiegészítve a BASIC betöltőt:

100 ALLOCATE 100
110 CODE M=HEX$("C9,21,BD,BE,3E,30,81,77,3E,FC, D3,B1,C3,19,40,D5,C5,3E,05,D3, B3,CD,BF,D3,C1,D1,C9")
120 FOR N=0 TO 26
130   SPOKE 252,10+N,PEEK (M+N)
140 NEXT

Jó kísérletezést!

EXOS 1-11

A csatornakezelő utasítások belépési pontjai csak közvetve adhatóak meg, hiszen ezeket - mint láttuk - az EXOS előkészítése után a csatornához rendelt perifériakezelők hajtják végre. A perifériakezelők belépési pontjait az 5. Függelék tartalmazza. A közvetlen hívás lehetőségével itt csak az EXOS 7 esetén foglalkozunk, ahol ennek a legnagyobb jelentősége lehet.

A periférianév a hívó lapkonfigurációjában bármelyik LAP-on lehet, azt az EXOS megtalálja az előkészítés során. A név végén kettőspontnak kell állnia, különben a rendszer file-névnek tekinti és periférianévként a TAPE-t állítja be (alapértelmezésű periférianév).
Használatára egy egyszerű példát mutat a következő BASIC rutin:

100 ALLOCATE 100
110 CODE NEV=CHR$(8)&"RINTER:"
120 CODE M=HEX$("11")&WORD$(NEV)&HEX$("3E,01,F7,01,C9")
130 CALL USR(M,0)
140 PRINT £1:"SZOVEG"

Ez a

LD DE,NEV
LD A,1
EXOS 1
RET

gépi programot tölti a memóriába és hívja meg. A rutin futtatása után ugyanúgy írhatunk a nyomtatóra az £1-es csatornán, mint ha OPEN £1:"PRINTER:" BASIC utasítással nyitottuk volna meg. A név beírása helyett persze kihasználhatjuk azt is, hogy a ROM-szegmensekben is megtalálhatók a nyitáshoz szükséges periférianevek (mint ezt már említettük a 2.3.1 pontban):

100 ALLCLATE 100
120 CODE M=HEX$("11,43,FE,3E,01,F7,01,C9")
130 CALL USR(M,0)
140 PRINT £1:"SZOVEG"

Ebben az esetben az 1. szegmens FE43H címén tárolt névre állítottuk DE-t, felhasználva azt a tényt, hogy a USR függvény kiértékelésekor az 1. szegmens van belapozva a 3. LAP-on.
Ilyen névtárolási pontok:

• 1. szegmens:
  • FE34: VIDEO:
  • FE3B: EDITOR:
  • FE43: PRINTER:
  • FE4C: KEYBOARD:
• 5. szegmens:
  • F9E5: EDITOR:
  • FA98: KEYBOARD:
  • FADF: PRINTER:
  • FB16: SOUND:
  • FB50: VIDEO:

A példaként választott PRINTER perifériakezelőhöz viszonylag egyszerűen nyitható csatorna. Itt ui. nem kell előkészíteni a megnyitást az EXOS változók területén. A VIDEO kezelő viszont ezekből a változókból szerez tudomást a megnyitandó csatorna (VIDEO lap) méretéről, kijelzési módjáról. A MODE-VID, COLR-VID, X-SIZ-VID és Y-SIZE-VID EXOS-változók beállítására és a csatorna nyitására már láttunk példát a 2.3.1 pontban, a bejelentkezési üzenet előkészítésénél. Most gyorsítsuk egy kicsit ezt az eljárást a változók közvetlen beírásával! Nyissunk meg egy 32*16 karakternyi méretű grafikus lapot 16 színű módban az EXOS 1 funkcióhívás segítségével (pl. az 5. csatornára), majd - egyelőre BASIC-ben - jelezzük ki az új lapot és rajzoljunk is rá, hogy ellenőrizzük a beállított paramétereket.

100 ALLOCATE 100
110 CODE NEV=CHR$(6)&"VIDEO:"
120 CODE M=HEX$("11")&WORD$(NEV)&HEX$("21,01,02,22,DB,BF,21,20, 10,22,DD,BF,3E,05,F7,01,C9")
130 CALL USR(M,0)
140 SET BORDER 10
150 DISPLAY £5:AT 5 FROM 1 TO 10
160 PLOT £5:500,400,ELLIPSE 150,150,

A változás a PRINTER-csatorna nyitásához képest:

Megjegyzendő, hogy ha ezt a közvetlen módszert egy olyan programban alkalmazzuk, ahol határozatlan a 2. LAP tartalma, a rendszerszegmenst is be kell lapozni a változók letárolása előtt.
Végül még egy megjegyzést. A TAPE perifériakezelő megkülönbözteti az EXOS 1 és EXOS 2 hívásokat. Egy nem létező csatorna megteremtése, pufferfoglalás stb. az EXOS 2 funkcióhívással kérhető, míg az EXOS 1 egy már létező csatornát nyit meg az adatforgalomnak.

A két funkciót minden beépített perifériakezelő azonos módon kezeli. Maguk a perifériák csak - a saját működésükhöz tartozó - részleges funkciókat látnak el (jelzőbájtok nullázása, a VIDEO-kezelőnél a lezárt csatornához tartozó éppen kijelzett sorok letakarása stb.). A nyilvántartásból való törlést, az ezzel járó memóriarendezést az EXOS végzi.
A funkció előkészítés nélkül hívható:

LD A,CSAT
EXOS 3

BASIC betöltővel (egyben ellenőrizve is, hogy valóban megtörtént-e a csatorna lezárása):

100 ALLOCATE 100
110 OPEN  £1:"VIDEO:"
120 CODE M=HEX$("3E,01,F7,03,C9")
130 CALL USR(M,0)
140 PRINT £1: "OK?"

(Német gép! # = £ csatorna hivatkozás!) A futás hibajelzéssel áll le a szóban forgó csatornára írni próbáló utasításnál, igazolva ezzel a lezárást.
Ha olyan csatornát próbálunk meg lezárni, amelyik nincs is nyitva (nincs benne a csatornaláncban), az EXOS hibakóddal tér vissza. Ellenőrizzük ezt a kódot, felhasználva, hogy a HL értékét a USR kiértékelő rutinja visszaadja a BASIC-nek. Az EXOS-ból való visszatérés után írjuk a hibakódot hordozó A értékét HL-be:

LD H,0
LD L,A

100 ALLOCATE 100
110 CODE M=HEX$("3E,01,F7,03,26,00,6F,C9")
120 PRINT "Hibakod:";USR(M,0)

Az indítás után kapott hibakód (FBH) ICHAN ("csatorna nem létezik") hibát jelez (l. a 4. Függeléket).

Az olvasott értékre csak a csatornák egy részénél illik a karaktermegnevezés, pl. grafikus módú csatornánál a VIDEO-kezelő a kurzorkoordináta pontjának palettaszínét adja vissza a hívás eredményeként.
Fel kell hívni a figyelmet, hogy egyes perifériák (a kezelőkön belül) várakoznak, amíg a karakter nincs készen az olvasásra (pl. a KEYBOARD kezelő vár addig, amíg meg nem nyomunk egy billentyűt).
Az első felhasználási példánk legyen a billentyűleolvasás. Az alapértelmezésben megnyitott 69H csatornáról olvassunk be egy karaktert és értékét adjuk vissza a BASIC-nek:

LD A,69H
EXOS 5
LD H,0
LD L,B
RET

A BASIC programban írjuk ki ezt az értéket, mint a megnyomott billentyű kódját és térjünk vissza az újabb karakter olvasására:

100 ALLOCATE 100
110 CODE M=HEX$("3E,69,F7,05,26,00,68,C9")
120 PRINT "A lenyomott billentyu kodja: ";USR(M,0)
130 GOTO 120

A rutinnal kiolvashatunk minden billentyűkódot (különböző shiftelési módok mellett). Figyelemre méltó a funkcióbillentyűk hatása. Azt láthatjuk, hogy a kezelő (saját pufferjéből) a billentyűhöz rendelt összes karaktert kiadja (egyenként) a megismételt olvasási funkcióhívások hatására (és akkor áll le újabb várakozásra, amikor a puffere kiürült).
Igen érdekes a funkció felhasználása egy magnetofonról beolvasható file letapogatására:

100 ALLOCATE 100
110 OPEN £1:""
120 CODE M=HEX$("3E,01,F7,05,26,00,68,C9")
130 PRINT USR(M,0)
140 GOTO 130

A program elindítása után állítsuk a kazettát egy tetszőleges rögzített file-ra és indítsuk el a lejátszást.
Befejezésül lássunk még egy példát a funkcióhívás felhasználására grafikus VIDEO-csatorna esetén. A program beolvassa - és a képernyő alsó sávjában kiírja - a pillanatnyi kurzorkoordináták palettaszínét.

1 PROGRAM "Paletta.bas"
100 ALLOCATE 10
110 CODE M=HEX$("3E,65,F7,05,26,00,68,C9")
120 LET X,Y=100
130 GRAPHICS
140 PRINT AT 2,1:"Palettaszin:"
150 PLOT 200,200,ELLIPSE 100,100,
160 PLOT 350,200,ELLIPSE 100,100,
170 SET INK 1
180 PLOT 200,200,PAINT
190 SET INK 2
200 PLOT 275,200,PAINT
210 SET INK 3
220 PLOT 350,200,PAINT
230 PLOT X,Y,
240 LET P=USR(M,0)
250 PRINT AT 2,15:P
260 SET INK 3+3*(P=3)
270 PLOT X,Y
280 SET INK P
290 PLOT X,Y
300 GET A$
310 IF A$="" THEN 230
320 IF ORD(A$)=176 THEN LET Y=Y+4
330 IF ORD(A$)=180 THEN LET Y=Y-4
340 IF ORD(A$)=184 THEN LET X=X-4
350 IF ORD(A$)=188 THEN LET X=X+4
360 GOTO 230

A villogó pontkurzor a beépített botkormánnyal vezérelhető pontonként a képernyő adott helyére. A rajzolás és a kurzorbeállítás egyelőre a BASIC program feladata, ezek gépi kódú megoldására a 8. Függelék ad információt.

A DE-t egy szabad RAM-terület kezdőcímére kell állítani (itt is tetszőleges LAP-on). Az EXOS ettől kezdve tárolja az olvasott blokkot. A visszaadott értékek olvasási hiba esetén használhatók fel a továbbolvasáshoz.
A funkció szemléltetésére alakítsuk át az előző pont valamelyik példaprogramját. A kiolvasás szemmel követhető lesz, ha pufferterületként az állapotsorban kijelzett memóriaterületet jelöljük ki (amíg a program fut, ezt tetszőlegesen használhatjuk, csak a leállás - pl. STOP - hatására írja felül az operációs rendszer).
A pufferterületet hívás előtt törölni is kell. Így az assembly rutin:

Használjuk ezt a rutint pl. a kazettafile beolvasására:

100 ALLOCATE 100
110 OPEN £1:""
120 CODE M=HEX$("21,BE,BE,E5,06,20,36,20,23, 10,FB,D1,01,20,00,3E,01,F7,06,C9")
130 CALL USR(M,0)
140 PING
150 GOTO 130

A rutinból való visszatérést hangadás jelzi, majd továbbolvassuk a csatornát. Érdemes más csatornák olvasásával is próbálkozni.

Az EXOS számunkra legsokoldalúbban használható hívása (a blokkíró EXOS 8-cal együtt). A számítógép szinte minden látható és hallható kijelzési, sőt adatátviteli funkciója elérhető ezen keresztül. A kiírandó karakter (az EXOS főágában előkészített egyéb paraméterekkel együtt) a perifériakezelőhöz kerül. Itt dől el - a kezelő feladatának és a kivitt értéknek megfelelően -, hogy a kiírt bájt (bájtsorozat) a képernyő egy adott részén jelenik-e meg alfanumerikus karakterként, vagy magnetofonkazettára kerül-e, esetleg egy grafikus alakzat kitöltését indítja-e el stb. A funkció értelmezése tehát csak egy-egy adott periféria esetén lehetséges.
A hangkezelő (SOUND) pl. a képzendő hangok paramétereit és vezérlőkaraktereket vár ilyen formában. Van azonban egy olyan karakter (a 7-es) amelynek kiírása egymagában kiváltja egy alapértelmezésű hang megszólalását (PING):

LD A,67H
LD B,7
EXOS 7
RET

BASIC-ből betöltve és elindítva:

100 ALLOCATE 100
110 CODE M=HEX$("3E,67,06,07,F7,07,C9")
120 CALL USR(M,0)

Ezt is felhasználhatjuk gépi kódú programjainkban.

Ezek után nézzünk egy példát a perifériakezelő közvetlen hívására. Természetesen olyan példát, amelyben kézzel fogható ennek előnye. Legyen a feladat pl. 255 db azonos karakter (mondjuk A) kiírása a képernyőre.
A feladat az EXOS 7 hívással könnyen megoldható:

A BASIC betöltő programot kiegészítettük, hogy a rutin futásidejét mérhetővé tegyük. A 140. sor folyamatosan átírja a kiírandó karakter kódját (így jobban tudjuk követni a képernyőn a folyamatot).

100 ALLOCATE 100
110 CODE M=HEX$("06,FF,C5,3E,66,06,51,F7,07,C1,10,F6,C9")
120 TIME "00:00:00"
130 FOR N=65 TO 90
140   POKE M+6,N
150   PRINT AT 1,1:
160   CALL USR(M,0)
170   PRINT AT 10,1:
180 NEXT
190 PRINT "Ido: "TIME$

Ezek után térjünk rá a VIDEO perifériakezelő kiírató rutinjának (0/D4D0H, l. 5. Függelék) közvetlen hívására.
Az EXOS főág követésével megállapítottuk, hogy a végrehajtó rutinnak átadandó, előkészítendő paraméter a kiíratandó karakteren kívül (B) a szóban forgó csatorna pufferének báziscíme (IX) is. Ugyanitt láttuk azt is, hogy milyen módon keresi ki az EXOS a csatorna leíróját. Ehhez a kereséshez használjuk mi is a 0. szegmens CD3AH rutinját. Ez az alprogram a BFCDH báziscímmel induló csatornaláncból kikeresi a csatornát a belső csatornaszámot tartalmazó A alapján. Belapozza a leíró szegmensét az 1. LAP-ra és HL-ben a leíró báziscímét adja vissza (ill. Z státusszal tér vissza, ha nem találja a keresett csatornát a láncban).
Mivel tudjuk, hogy maga a leíró 16 bájt hosszú, a leíró báziscíméből már könnyen meg tudjuk határozni a közvetlenül alatta kezdődő puffer báziscímét. Ezt IX-be töltve már hívhatjuk a végrehajtó rutint. Megjegyezzük, hogy - az egyszerűség kedvéért - itt most elhagytuk az EXOS által ugyancsak átadott periférialeíró pointer előkészítését, (B', IY), ezt ui. nem igényli az adott végrehajtó rutin.
A következő rutin az előbbi lépések szerint oldja meg a feladatot:

Ill. ennek BASIC betöltője és hívója:

1 PROGRAM "Kiras.bas"
100 ALLOCATE 100
110 CODE M=HEX$("DD,E5,DB,B3,F5,AF,D3,B3,3E,67,CD, 3A,CD,28,12,01,F0,FF,09,E5,DD, E1,06,FF,C5,06,51,CD,D0,D4,C1, 10,F7,F1,D3,B3,DD,E1,C9")
115 TEXT
120 TIME "00:00:00"
130 FOR N=65 TO 90
140   POKE M+26,N
150   PRINT AT 1,1:
160   CALL USR(M,0)
180 NEXT
190 PRINT "Ido: ";TIME$

A BASIC program a gépi kódokat tartalmazó (110) és a kiírandó karakter kódját váltogató (140) sortól eltekintve megegyezik a feladat előző megoldásának programjával. Így összemérhető a két futásidő. Az EXOS funkcióhívással dolgozó rutin futásideje kb. 2-3-szor akkora, mint a közvetlen hívó második megoldásé. Nyilvánvaló tehát, hogy - legalábbis egyes feladatoknál - érdemes a formailag rendkívül egyszerű EXOS hívás helyett egy kicsit többet fáradni a közvetlen hívással.

Nagyobb tömegű adat, összetartozó karaktercsoport stb. ideális kiviteli eszköze.
Egyszerű alkalmazási példaként írassuk az 1. szegmens egyik copyright-üzenetét az aktuális csatornára:

100 ALLOCATE 100
110 CODE M=HEX$("11,80,F5,01,21,00,3E,FF,F7,08,C9")
120 CALL USR(M,0)

Olyan csatorna esetén praktikus az alkalmazása, amely olvasásnál várakozna a készenlétig (pl. KEYBOARD). Így várakozás nélkül is információt szerezhetünk arról, van-e olvasható karakter a perifériakezelő pufferében. A készenléti státuszt C hordozza:

• C = 0: a periféria készen (van olvasható karakter)
• C = 1: a periféria nincs kész (nincs olvasható karakter)
• C = FFH: file vége

A BASIC rendszerben a GET utasítás használja pl. ezt a hívást, mielőtt megkísérli az olvasást (nehogy bennragadjon a kezelőben).
A készenléti jelzőt írja ki a következő program az 1. sorba a billentyűzet csatornájáról a

LD A,69H
EXOS 9
LD H,0
LD L,C
RET

gépi rutin felhasználásával. A kész karaktert folyamatosan ki is olvassuk, mert különben egyetlen billentyű leütése után csak az állandó készenlétet látnánk.

100 ALLOCATE 10
110 CODE M=HEX$("3E,69,F7,09,26,00,69,C9")
120 LET KOD=USR(M,0)
130 PRINT AT 1,1:KOD;
140 IF KOD=0 THEN
150   GET A$
160   PRINT A$;
170 END IF
180 GOTO 120

Az alapkiépítésű gépen nem használt funkció: egyetlen beépített perifériakezelő sem fogadja (NOFN hibakódot küldenek vissza). Saját perifériakezelőnkben tetszés szerint használhatjuk (a funkció pl. lemezkezelő bővítés esetén nyer értelmet).

A perifériák vezérlőfunkciója. A beépített perifériák egy része (SERIAL, TAPE, PRINTER) nem kezeli ezt a hívást (ISPEC - Érvénytelen speciális funkcióhívás - hibakódot küld válaszként). A többi kezelő elfogadja a hívást a B értékének egy-egy tartományában:

A várhatóan leggyakrabban hívott képernyő-, ill. billentyűzetkezelés esetén nézzük meg egy kicsit részletesebben az elérhető funkciókat és hívásuk módját:

B = 1: videolap kijelzése

BASIC-ben
DISPLAY £csat: FROM kezdősor TO végsor AT képernyősor
utasítással elvégezhető funkciót látja el: a képernyő adott sorától kezdődően kijelzi a szóban forgó csatornán felépített videolap kezdő- és végsor közötti részét.
Paraméterei:

A: kijelzendő csatornaszám
C: kezdősor
D: kijelzendő sorok száma (végsor - kezdősor + 1)
E: képernyősor

Lássunk egy rövid rutint a funkció alkalmazására:

Egy kis BASIC kiegészítéssel jól látható a funkció hatása. A kijelzendő laprészlet (10 sor) kezdő sorszámát BASIC-ből adjuk meg (a USR második argumentuma L-be, onnan a rutinban C-be kerül).

10 PROGRAM "Disp.bas"
100 ALLOCATE 100
110 CODE DISP=HEX$("3E,65,4D,06,01,11,05,0A,F7,0B,C9")
120 DISPLAY GRAPHICS
130 PLOT 600,350,ELLIPSE 400,300,
140 PLOT 0,700,
150 PRINT £101:"Felso resz:"
160 PLOT 0,100,
170 PRINT £101:"Also resz:"
180 DISPLAY TEXT
190 CALL USR(DISP,1)
200 WAIT 1
210 CALL USR(DISP,11)
220 WAIT 1
230 GOTO 190

A következő két speciális funkcióhívás az adott csatornához tartozó videolap paramétereit olvassa ki és adja vissza a hívónak.

B = 2: üzemmód lekérdezése

Kimenő adatai:
B: a videolap szélessége karakterekben (X)
C: a videolap magassága karakterekben (Y)
D: a kijelzési mód
E: a színmód

A négy regiszterben visszaadott érték tulajdonképpen az
X-SIZ-VID
Y-SIZ-VID
MODE-VID és
COLOR-VID
EXOS változók értéke a szóban forgó csatorna megnyitásakor.

B = 3: tárolási cím lekérdezése

Kimenő adatai:
BC: fő tárolási cím
DE: másodlagos tárolási cím

A video adatok tárolásáról (és közvetlen eléréséről) a 8. Függelékben írunk még. Példaként most alkalmazzuk ez utóbbi két speciális funkcióhívást TEXT 80 üzemmódban az alapértelmezésű VIDEO-csatorna lekérdezésére (66 H). A visszakapott paramétereket tároljuk a BASIC által nem használt 0180H-0187H területeken (decimálisan 384-391)

A BASIC betöltőprogramban egyúttal kiolvassuk és ki is íratjuk a funkcióhívás tárolt eredményeit.

100 ALLOCATE 100
110 CODE M=HEX$("3E,66,06,02,F7,0B,ED,43,80,01,ED,53,82,01")
120 CODE =HEX$("3E,66,06,03,F7,0B,ED,43,84,01,ED,53,86,01,C9")
130 TEXT 80
140 CALL USR(M,0)
150 PRINT "A"
200 FOR N=384 TO 391
210   PRINT N;PEEK(N)
220 NEXT

Értelmezzük együtt a futtatással kapott adatokat:

• sorok száma (Y-SIZ-VID): 24
• karakterek száma a sorban (X-SIZ-VID): 80
  (TEXT 80!)
• színmód (COLR-VID) : 0
  (két szín)
• kijelzési mód (MODE-VID): 2
  (szoftver szövegmód, ez is a "TEXT 80"-nak felel meg)
• fő tárolási cím (jelen esetben a bittérkép tárolási kezdő címe):
  LBS: 156=9CH
  MSB: 154=9AH
• másodlagos tárolási cím (jelen esetben az ASCII-kódokból felépített térkép)
  LBS: 28 =1CH
  MSB: 222= DEH

Itt is felhívjuk a figyelmet, hogy a két tárolási cím VIDEO cím. Az adatokat tároló szegmens száma a cím MSB tartományából határozható meg.
1. 80H < 9AH < BFH a fő cím az FEH szegmensben van
2. C0H < DEH < FFH a másodlagos cím az FFH szegmensben van.
Ezt a két kezdőcímet kérdezi le a fenti képernyőmásolat két sora. A fő címen lévő érték 24 (00011000) a képernyő bal felső sarkába kiíratott A karakter pontmátrixának felső sora. A másodlagos cím tartalma (65) ennek az A betűnek az ASCII kódja.

B = 4: karakterkészlet-inicializálás

A funkciónak külön be- és kimenő adata nincs. Még a megadott csatornaszám is csak annyiban kritikus, hogy VIDEO perifériához megnyitott csatorna legyen (ez biztosítja, hogy a hívás a VIDEO kezelőhöz jusson el).
A ROM-adatmezőből - hidegindítási folyamathoz hasonlóan - újratölti a RAM karaktergenerátor területet. Hatása - a hívott csatornától függetlenül - valamennyi videocsatornára kiterjed.

A következő két speciális funkcióhívás a billentyűzetkezelőé:

B = 8: funkcióbillentyűk programozása

Bemenő adatok:
A: a billentyűzetcsatorna száma (BASIC alapértelmezésben 69H)
C: a programozni kívánt funkcióbillentyű száma - 1 (0-7, ill. shiftelt gombokhoz 8-15)
DE: a beprogramozandó szöveg előtti hosszbájtra mutat

Példaként írjuk át a F8 funkciógombot (C = 7) úgy, hogy megnyomására AUTO üzemmódba kerüljön a gép, és a 100-as sorba írja is be a programjainkban igen gyakran használt ALLOCATE utasítást, de argumentum nélkül:

100 ALLOCATE 100
110 CODE SZOVEG=HEX$("10,A5")&"AUTO"&HEX$("A1,0D")&"ALLOCATE "
120 CODE FK=HEX$("3E,69,01,07,08,11")&WORD$(SZOVEG)&HEX$("F7,0B,C9")
130 CALL USR(FK,0)

A beprogramozott szövegben a hosszbájt 10H (16 karakter következik), az első kiírt bájt (A5H) visszatöröl a sor elejéig. Ezután következik az AUTO szöveg, törlés a sor végéig, majd a sor bevitele (0DH = ENTER). Az ezt követő ALLOCATE karakterekkel befejezzük a beprogramozott szöveget, nem zárjuk le a sort, így a kurzor a szöveg utáni pozíción marad; a programozó beírhatja a lefoglalni kívánt bájtok számát.

B = 9: a botkormányok olvasása

Bemenő adatok:
C: botkormány-választás
C = 0: belső
C = 1: külső 1.
C = 2: külső 2.

Kimenő adat:
C = olvasott érték

A botkormány és a tűzgomb (a beépített joystick esetén SPACE) pozícióját a C regiszter bitjei reprezentálják (1, ha megnyomott):

JOBB: BAL: LE: FÖL: TŰZ:

BIT 0,C BIT 1,C BIT 2,C BIT 3,C BIT 4,C

Végül a további (várhatóan ritkábban igényelt) speciális funkcióhívások (részleteket az EXOS leírás tartalmaz):

NET

• B = 16: kiviteli puffer ürítése (FLUSH)
• B = 17: pufferek törlése (CLEAR)

EDITOR

• B = 24: lapszélmargók beállítása
• B = 25: dokumentum betöltése
• B = 26: dokumentum kivitele

Ez az egyetlen EXOS hívás, amit még megszakításkezelés közben is elfogad a rendszer. Tulajdonképpen rögzített címen kezdődő változó táblázat adatainak kezelését végzi.
Ha a változó száma 39-nél nagyobb, E-ben a változó számával, C-ben az "EXOS változó" kóddal (4) végigkérdezi a rendszerbővítőket, lehetőséget adva így új változók bevezetésére, kezelésére.

A 0 és 39 közötti (alapértelmezésű) változó hívása esetén megállapítja a hozzá tartozó táblázatcímet: HL = BFC5H + n. Az 1. változót külön kezeli (FLAG_SOFT_IRQ), ezt a BFF2H címen keresi és manipulálja. Az EXOS változók táblájának azonos nevű eleme voltaképpen csak ennek másolata lesz.

A kiszámított címen elvégzi a kért műveletet:

REM 1 és REM 2 - hívó esetén (36., ill. 37. változó) a megfelelő PORT-okon is beállítja az aktuális értéknek megfelelő szinteket, majd - a RET hatására - elugrik a belépéskor PUSH utasítással tárolt címre: az EXOS funkcióhívások visszatérési ágára:

A funkció közvetlenül is hívható (természetesen a visszatérési címet verembe töltő bevezető utasítások átlépésével, a C8FDH címen), de igazi jelentősége inkább a változók közvetlen elérésének van. Az ehhez szükséges címeket (és az inicializálás utáni értékeket) a 3. Függelék tartalmazza. Az alkalmazásra már láttunk példát az EXOS 1, 2 tárgyalásakor.

A két funkció érdekessége, hogy - bár csatornákat érintő utasításokról van szó - a rendszer nem a csatornautasítások között (1-11) kezeli őket. Ennek oka, hogy itt a perifériakezelőket nem kell bevonni a végrehajtásba. A rendszer a hívások hatására csak a főcsatornák leírójának egy-egy bájtját állítja át: