Jó írás, várom a többit.
Az IM2 megszakításról is írhatnál, ugyanis ott is voltak különbözõ gépek. Ha jól emlékszem valami porton jött, hogy az IM2 rutin hol van, és ezen a porton a legtöbb gépen 0 volt. Azonban volt pár gép (pl. az enyém) amelyen ez a port random(!) értéket adott, ha jól emlékszem 255 és 254 érték váltakozott rajta. Emiatt aztán el is szálltak bizonyos átiratok.
Vagy valami ilyesmi volt, már nem emlékszem.

Akkor menjünk bele a részletekbe, elõször egy kis összefoglaló:
Van 4MB címtartományunk, ez fel van osztva 256 db 16K-s szegmensre. Meglepõ módon 0-255-ig számozzuk õket, hexában 00-FF
Alapvetõen bármelyik lehet RAM vagy ROM vagy maradhat üresen, kivéve amit maga az alaplap határoz meg: 00-03 az alaplapi ROM-hoz van rendelve, FC-FF pedig a szintén az alaplapi RAM-hoz, aminek kiemelt szerepe van, hiszen egyben a Nick chip által látott videómemória.
04-07 tartozik a cartridge foglalathoz, de itt akár RAM-ot is elhelyezhetünk. A 128-as gépekben helyett kapott egy plusz 64K-s bõvítõpanel, ami F8-FB szegmenseket tartalmazza.
Ami még nagyon elterjedt: a MICROTEAM kártya 512K bõvítése a 40-5F területet foglalja el. 320K-ra bõvített gépben pedig EC-FB található a bõvítõpanelen.
Itt érdekességként megjegyzem, hogy az egyik NASA&GUY demo (asszem valami Jean Michell Jarre digi zenét játszik), ilyen "EC-s" gépre íródott eredetileg, amin nagyon csodálkoztam anno, akkor még nem jelent meg az Enterpressben a 320K átalakítós cikk. És hiába volt MICROTEAM kártyával 640K-s gépem, mégse játszotta le a teljes zenét, hála a fix címes programozási stílusnak... aztán én meg átírtam, hogy a MICROTEAM kártyára esõ szegmenseket használja, így végre meghallgathattam a teljes zenét

Ha a RAM-ot nézzük, egy 64K-s gépben van FC-FF. 128-asban F8-FF.
Ha a korábban emlegetett MICROTEAM+EP64 konfigot nézzük, akkor pedig 40-5F, FC-FF, ami darabra bõven jó, csak hiányzik az a bizonyos F8-FB, amire az EXOS-t nem használó 128-as gépen programozók által írt programok nagyrésze hivatkozik közvetlenül.

A helyes programozáshoz felejtsük is el ezeket a számokat, egyedül az FC-FF-et kell megjegyezni, kitüntetett videó memória mivoltuk miatt. A többirõl csak annyit kell tudnunk, hogy nekünk hány darabra van szükségünk, a konkrét szegmensszámokat majd megmondja az EXOS!

Most nézzük az EXOS szerinti RAM felosztást: két szegmensnek van kitüntett szerepe, az egyik az FF ami a rendszerszegmens, és a legalacsonyabb sorszámú RAM szegmens ami a nulláslap szegmens. Itt található meg az EXOS hívások, ill a megszakítási program belépési pontja. És ide kerülnek 100H címtõl töltve az 5-ös fejlécû programok is.
Egy 128-as gépen az az F8 szegmens. De ha pl van egy MICROTEAM kártyánk, akkor már a 40-es lesz az.
És ez máris gondot okoz sok programnak (általában a komplett módosított Spectrum ROM-ot tartalmazó béna átíratoknak)...
De bõvítõs gépen is lehet F8 a nulláslap, ha VENUS-t használunk, ill. az EPDOS 2.1-nek is van ilyen lehetõsége.
Ez az eset meg egy másik adag programnak okoz gondot...

A maradék RAM négy csoportba tartozhat: rendszer, eszköz, felhasználói, szabad.
Ha pl csatornákat nyitunk meg, különösen ha nagy RAM igénnyel járó videó lapokat, akkor az EXOS elkezd lefelé terjeszkedni, és ha kihízza az FF szegmenst, akkor további szegmensek válhatnak rendszer által lefoglalttá.
A különbözõ beláncolt EXOS periféria kezelõk által igényelt teljes RAM szegmensek az eszköz (device) kategóriában kerülnek lefoglalásra. Erre típikus példa a RAMDISK. Szintén ebben a kategóriába kerülnek lefoglalásra a betöltött rendszerbõvítõk által elfoglalt szegmensek is.
És végül van az aktív felhasználói program, ez lehet egy rendszerbõvítõ vagy egy 5-ös fejléccel betöltött "új alkalmazói program". Az ezek által igényelt szegmensek a felhasználói kategóriában kerülnek lefoglalásra.

Ami nagyon fontos: a felhasználói program csak felhasználói szegmenst tud felszabadítani, eszköz vagy rendszer szegmens felszabadításához nincs joga!

És ezzel el is érkeztünk ahhoz a bizonyos Spectrum Világ-os hibás módszerhez:

        LD C,0FAH
        EXOS 25
        LD A,0FAH
        OUT (0B2H),A
 

Egyrészt a szándék dicséretes, hiszen nem csak bumm belapozza a szegmenst, hanem szabaddá teszi... csak sajnos a nem túl sikeres fordítású EXOS leírást félreértelmezve
Mert az EXOS 25 hívás csak akkor lesz sikeres, ha elötte az a szegmens nekünk, azaz felhasználóiként ki lett utalva. Ha az FAH már mondjuk a RAMDISK része, vagy egy betöltött EXOS bõvítõ van ott, akkor mivel eszköz szegmensnek van lefoglalva, hibajelzést kapunk vissza, hogy a szegmens nem szabadítható fel. A program viszont ennek ellenére nyugodtan neki áll használni.
És ott van még az a eset is, hogy nem is létezik ez a szegmens az adott konfigurációban, mert pl EP64-rõl van szó...
A helyes megoldás itt az, hogy kérünk kiutalni egy szegmenst az EXOS-tól, és azt használjuk. Ha hibajelzést kapunk vissza, mert elfogyott a szabad memória, akkor azt a programtól függõ módon le kell kezelni (pl kilépés, vagy lehet folytatni korlátozott funkcionalitással a program futását)

        EXOS 24
        JP NZ,HIBA  
        LD A,C
        OUT (0B2H),A
 

Kicsit macerásabb, ha egy konkrét számú szegmensre vágyunk: ekkor ciklusban kell ismételgetni az EXOS 24 hívást, mindaddig amíg meg nem kapjuk a kívánt szegmenst, vagy pedig elfogy a memória, és ekkor megyünk a HIBA rutinra.
De erre a módszerre új program írása esetén csak egy esetben lehet szükség: ha videó szegmensre van szükség. Ekkor addig ismételjük a hívást ameddig FC vagy nagyobb szegmenst nem kapunk.
És akkor kell még ehhez a módszerhez folyamodni, ha egy régebbi fix címzéses programot akarunk kibõvíteni úgy, hogy amit a program használ, az legyen szabályosan lefoglalva, mint ahogy ezt tettem tegnap a TUSKER-rel.
Ez volt Attus eredeti rutinja, amely az SpV módszeren alapult:

                LD BC,5FAH
SZABAD          PUSH BC
                EXOS 25
                POP BC
                INC C
                DJNZ SZABAD
 

Ebbõl kiderül, hogy az FA-tól kell nekünk 5 szegmens, ill. késöbb kiderült, hogy az LPT táblát az FF szegmens elejére helyezi el.
És ime mindez helyesen:

FOGLAL          EXOS 24
                JP NZ,HIBA
                LD A,C
                CP 0F9H
                JR NZ,FOGLAL
                LD BC,5FAH
EZKELL          PUSH BC
                EXOS 24
                LD A,C
                POP BC
                CP C
                JP NZ,HIBA
                INC C
                DJNZ EZKELL
                EXOS 24
                CP 7FH
                JP NZ,HIBA
                LD DE,3200
                EXOS 23
                JP NZ,HIBA
                LD L,0F9H
VISSZAAD        LD C,L
                EXOS 25
                DEC L
                JR NZ,VISSZAAD
 

Az elején addig foglalunk, amíg az F9-ig el nem jutunk. Ha közben kifogyunk a memóriából, akkor ugrás a HIBA-ra.
Ezután kérünk még 5 szegmenst, aminek FA,FB,FC,FD,FE-nek kell lennie, különben HIBA...
És még egyet igényelünk, itt már csak az FF jöhet, és "megosztott szegmens" hibajelzést kell kapnunk (ez a 7F hibakód), különben hiba.
És itt jön még egy fontos dolog: megosztott szegmens használata esetén meg kell mondanunk az EXOS-nak, hogy mi meddig akarunk terjeszkedni, erre szolgál az EXOS 23: felhasználói határ beállítása. Ha itt hibajelzést kapunk, akkor nincs annyi szabad hely amennyire nekünk szükségünk van, tehát ugrás a HIBA-ra.
Ha minden ok, akkor egy nem túl szép, nem túl gyors, de egyszerû módszerrel visszaadjuk a felesleges szegmenseket. Vagyis F9-tõl lefelé mindet megpróbáljuk felszabadítani, úgyis csak az fog sikerülni amit felhasználónak utaltak ki
A teljesen korrekt megoldás természetesen az, ha az elején eltároljuk sorban a kapott felesleges szegmenseket, és ezen lista alapján szabadítunk itt fel. Erre akkor van szükség, ha az 5-ös fejlécû programunk már nem fér el a nulláslapon, mert ekkor a további programszegmensek is felhasználóiként kerülnek lefoglalásra, és ezzel a primitív módszerrel azokat is felszabadítanánk, pedig azt nem lenne szabad. A TUSKER betöltõ esetén nincs ilyen gond, jó így is

Ez volt a fix szegmensek használata szabályosan címû fejezet, majd alvás után folyt köv

Konkrét szegmens igénylésére nincsen valami elegánsabb módszer? Mert így szélsőséges esetben akár 249 szegmenst is lefoglalhatunk magunknak, míg végre megkapjuk pl. a hőn áhított FC szegmensünket. És akkor ezután még fel kell szabadítani a fölöslegesen lefoglalt szegmenseket is, hátha kellenek még azok valamire...

Látom kapisgálod már a dolgot
Sajnos nincs ez egy pici hiányosság az EXOS-ban. Jó lenne ha külön lehetne jelezni, hogy videó szegmenst szeretnénk kérni.
Erre egyedül a periféria kezelõ programon keresztül van lehetõség, ha videó periféria típust állítunk be.

Így jobb híján marad ez a ciklusos megoldás. Lehetséges még közvetlenül az EXOS rendszerterületeiben matatni, ezt több könyvben, cikkben tárgyalták is. De az ilyen programok máris elszállnak EXOS 2.0 esetén... esetleg meg lehetne írni külön két szubrutint EXOS 2.0 ill. 2.1 esetére. De mi van ha véletlenül mégis elõkerül az a szuper EP, amit állítólag Kopácsy rejteget? Azon megint csak nem fognak futni az ilyen "kotorászós" programok...
Szóval szerintem jobb maradni a szabályos megoldásnál, az a pár tizedmásodperc futásidõ amibe legrosszabb esetén kerülhet, nem egy nagy veszteség a kompatibilitás oltárán

Ott tartunk, hogy szeretnénk megszabadulni a fix szegmensszámoktól, ily módon a különbözõ konfigurációkhoz maximálisan alkalmazkodó programot írni. Nézzük mi a teendõ ha memóriára van szükségünk?
Kezdetnek ott van a korábban emlegetett nulláslap. Ebbõl az EXOS a 0030-005BH területet használja, ill. az 5-ös fejlécû program ide kerül betöltésre 0100H címtõl. A többi szabadon felhasználható az éppen aktív felhasználói program számára.
Mint korábban már említettem, a nulláslap szegmensszáma különbözõ lehet a különbözõ konfigurációkban, az aktuális számot megtudhatjuk a B0H  portról beolvasva, ill. a BFFCH címen lévõ EXOS rendszerváltozó* is tartalmazza. Ez késõbb még fontos lesz, amikor majd kicsit trükközünk a nulláslappal , de alapesetben nem szokás piszkálni
* a rendszerváltózók címe úgy érvenyes, ha az FFH rendszerszegmens a 2. lapra van lapozva.

Nézzük tovább, mi van ha a nulláslap már nem elég, vagy nem felel meg az igényeinknek?
Nagyon egyszerû, kérünk további szegmenseket az EXOS-tól. Mivel már nem ragaszkodunk a fix szegmensszámokhoz, sokkal egyszerûbb a dolog, minden amit kapunk, az jó nekünk Célszerû a kapott szegmensek számát eltárolni, késõbbi lapozási mûveletekhez nem árt tudni melyik szegmensekrõl van szó ill. majd kilépéskor fel kell szabadítanunk ezeket.
Egy lehetséges módszer, például foglaljunk le 4 szegmenst:

                LD HL,RAMLISTA
                LD A,4
FOGLAL          EX AF,AF'         
                EXOS 24
                JP NZ,HIBA
                LD (HL),C
                INC HL
                EX AF,AF'
                DEC A
                JR NZ,FOGLAL

Késöbb pedig pl a 3. szegmensre így hivatkozhatunk:

                LD A,(RAMLISTA+2)
                OUT (0B3H),A
 

Itt megemlítem azt is, hogy a Spectrum Világ cikksorozatának az elején, amikor a Spectrum kazetta beolvasó programot tárgyalják, még a helyes memóriakezelésrõl van szó:
Sajnos a gyakorlati megvalósításba becsúszott egy kis hiba:

          EXOS 24            ;Egy 16 kbyte meretu RAM szegmens lefoglalasa
          LD A,C             ;es belapozasa
          OUT (0B1H),A       ;az 1. lapra (4000H-7FFFH cimtartomany)
          EXOS 24            ;Meg ket szegmens lefoglalasa
          LD A,C             ;es belapozasa
          OUT (0B2H),A       ;Ezekre fog toltodni a program
          EXOS 24
          OUT (0B3H),A
 

Kimaradt a hibakezelés, így kevés memória esetén, hiába szól az EXOS, hogy elfogyott, a program nem veszi észre, és hibásan fog mûködni.

Ezzel a sima szegmens igényléses módszerrel már remekül el lehet lenni, ha nincs szükségünk képernyõ kezelésre, ill. ha megoldjuk az EXOS videó kezelõjén keresztül. Ha viszont magunk akarjuk a képet létrehozni, saját LPT táblával, ahhoz saját videó szegmens(ek)re lesz szükségünk!
Itt kezdõdnek a bonyadalmak...

Ezért javasoltam már régebben, hogy a hasznos dolgokat össze kellene gyűjteni (egyelőre) a wiki-n.

Mi is a bonyadalom a videó szegmensekkel? Az egyik az amire Povi már rákérdezett: nem tudunk közvetlenül videószegmenst igényelni, így kénytelenek vagyunk a már megismert ciklusos igényelgetéses módszerhez folyamodni.

Ez viszont megint helytelen hozzáállás. Mert áhítozhatunk rá, de EP64-en nem fogjuk megkapni, mivel az csücsül a nulláslapon.
Tehát a helyes hozzáállás az, hogy FC vagy nagyobb ami elfogadható. Jól eltesszük ennek is a számát, hol itt a gond? Az, hogy lesz itt még egy kis pluszmunkánk!
Általános célú szegmenseknél teljesen mindegy, hogy melyiket is kaptuk meg. Videó szegmens esetén ez már nem teljesen igaz!
A miérthez nézzük meg a Nick chip memória kezelését, amirõl eddig még nem volt szó:
Azt már tudjuk, hogy az alaplapi 64K egyben a videómemória is. Ezt a Nick saját maga is címzi, az általa használ címeket nevezzük videócímeknek. Természetesen ezek is 0000-FFFFH tartományban lehetnek. De ezek a címek teljesen függetlenek a Z80 címeitõl! A 0000-3FFFH tartomány jelenti az FCH szegmenst, 4000-7FFFH az FDH, 8000-BFFFH az FEH, C000-FFFFH az FFH. És ezek függetlenek attól, hogy a kérdéses szegmensek a Z80 számára hova vannak lapozva, vagy hogy egyáltalán be vannak-e lapozva.
Így amikor a videómemóriával végzünk mûveleteket, szükséges lehet azt a címet amivel a Z80 érte el a kérdéses területet átszámolni videócímre a Nick számára.
És van még egy számolgatás, amire akkor van szükség amikor az LPT tábla címét adjuk meg a Nick chipnek, mivel itt csak 12 bitet adunk át.
Ezt legegyszerübben úgy lehet megspórolni, ha a 0000H videócímre tesszük az LPT táblát, vagyis az FC szegmens elejére, ahogy teszi ezt pl az SpV féle Spectrum átírat betöltõ is.
Az LPT táblában pedig meg kell adnunk a képernyõ adatok videócímét is. Az egyszerûség kedvéért az említett betöltõ erre a célra az FD szegmenst használja, így 4000H videócímtõl fog kezdõdni a képernyõ, ezt a kezdõcímet használja fixen az LPT generáló rutin.
Nekünk viszont pont az a célunk, hogy a fix szegmensszámoktól megszabaduljunk!

Az említett Spectrum képernyõ elõállításához két videószegmensre lesz szükségünk, egy kell az LPT táblának, egy pedig a Spectrum képernyõnek, ami egyben a Spectrumos memória elsõ 16K-ja is lesz.
Mivel az LPT tábla nem tölt ki egy teljes szegmenst (szokásos Spectrum LPT tábla 3200 bájt), így ezt akár megosztott szegmensben is el lehet helyezni. Ezért a célszerû folyamat az, hogy az ismert módszer szerint addig igényelgetünk szegmenseket, amíg egy videó szegmenst nem kapunk, ezt eltesszük képernyõnek, a következõt pedig LPT-nek. Ha fordítva csinálnánk, akkor elõfordulhatna, hogy a nem teljes szegmensnyi LPT tábla kap egy teljes szegmenst, a teljes szegmenst igénylõ videómemória pedig lehet, hogy márt csak megosztottat kap, ami hibához vezet...

128-as gépen ezzel pont fordított konfiguráció jön létra, mint az SpV betöltõben: az FCH lesz a videószegmens, míg az FDH az LPT szegmens. Ezzel az eredeti Spectrum LPT építõ rutin máris mûködésképtelenné vált, módosítani kell.

De errõl majd holnap

Még annyit befejezõül, hogy hogyan számoljuk a videócímeket: kelleni fog a Z80-as cím, ill. a szegmensszám.
A Z80-as címbõl a legfelsõ két bitet "dobjuk ki", és helyére a szegmensszám alsó két bitjét kell betenni.

Amikor pedig az LPT címét mondjuk meg a Nick-nek, akkor az alsó 4 bitet kell "eldobni".