Welcome, Guest. Please login or register.


Author Topic: EXOS kompatibilis memória kezelés (Read 22490 times)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
EXOS kompatibilis memória kezelés
« on: 2008.November.12. 22:38:18 »
Povi kérdezte, de talán másnak is hasznos lehet, így ime bõvebben kifejtve a memória kezelési téma, amolyan ENTERPRESS cikk pótlóként :-)

Az ENTERPRISE a maga korában, sõt talán a 8 bites gépek történetében nézve összességében is egyedülálló módon rugalmasan bõvíthetõre lett megtervezve, így pl a maximálisan kezelhetõ memória méret az akkoriban szinte elképzelhetetlen 4 megabájtban lett meghatározva.
Mindez ráadásul nagyon tisztán, áttekinthetõen lett megoldva: a Z80 64K-s címtartományát felosztjuk 4 db 16K-s lapra, a 4 megabájtot pedig 256 db 16K-s szegmensre. És bármelyik szegmenst belapozhatjuk bármelyik lapra, sõt még azt is megtudhatjuk, hogy melyik lapra melyik szegmens lett belapozva. Sok más gépen csak irigykedni lehet egy ilyen egyszerûen használható rendszerre, majd egyszer a Spectrum programok átírása kapcsán részletezem, hogy milyen "barkácsolással" lett a Spectrum 48-ból 128-as gép, ill. milyen további ronda barkácsolásokkal érték el az oroszok, hogy 256K esetleg 1 mega memória használatát... de a szocialista kistestvér, azaz a TVC esetén is jelentõsen lebutítani és egyben bonyolítani a rendszert, csak, hogy pár logikai kaput megspóroljanak...

Persze a hw lehetõség kevés, kell mindehhez egy olyan operációs rendszer, ami mindezt tudja kezelni, kihasználni. Szerencsére mi egy igazán remek rendszert kaptunk, amely teljességgel rászolgált az Enterprise eXtendable Operating System névre!
Az EXOS feladata az aktuális konfiguráció felderítése, a használható memória leltárba vétele, majd pedig a felhasználói programok ill. különbözõ rendszer összetevõk által támasztott memóriaigények kiszolgálása, nyílvántartás vezetése az aktuálisan foglalt ill. szabad memória területekrõl.
Akárcsak egy mai modern operációs rendszer esetén!
A kortárs gépeken nem is igazán lehet operációs rendszerrõl beszélni, memóriakezelés is gyakorlatilag csak a BASIC interpreteren belül létezik, változók stb-k nyilvántartása. Így pl egy Spectrum program se tudhatja meg rendszerszinten, hogy 48-as, 128-as vagy netán egy orosz Scorpion 256-os gépen fut.
Itt ha nem érdekel minket a BASIC, gyakorlatilag nincs semmi más amire figyelni kéne, ráadásul minden fix, és változatlan, a képernyõ memória is teljesen rögzített helyen van, semmi akadálya a "POKE-PEEK" stílusú programozásnak :-)
Enterprise esetén egyrészt alapból is több többé-kevésbé különbözõ géptípus került kiadásra (64, 128, EXOS 2.0 és 2.1, angol és német), másrészt a különbözõ bõvítésekkel számtalanra növekedett a különbözõ létezõ konfigurációk száma.

Sajnos a cég sikertelensége azzal is járt, hogy nem volt hivatalos támogatás, oktatás, cikkek, könyvek, arra vonatkozóan, hogy ezt a kitûnõ rendszert hogyan is kell helyesen kihasználni, hogyan kell megfelelõen programozni. Így a géppel foglalkozó programozók leginkább a más gépeken megszokott fix környezetet használó stílust vették át, az elérhetõ dokumentációkból csak annyit hasznosítva, hogy egyes fix(nek gondolt) pontokat megkeressék. Ez nálunk különösen jellemzõ volt, egyrészt mivel a legjobban eltérõ EP64-es nálunk nem került forgalomba, másrészt a hivatalos dokumentációk is csak késve és nem túl jó minõségben fordítva jelentek meg. Ráadásul a megjelent könyvek, cikkek nagyrésze is ezt a fix memória konfigurációs "POKE-PEEK" stílust hirdette.

Milyen problémák adódnak ebbõl?
- az anno hírhedt angol-német gépek közötti inkompatibilitás, mind ennek volt köszönhetõ. Ez különösen a BASIC-gépi kód keverék programokra volt jellemzõ. Ennek köszönhetõ sok össsze-vissza barkácsolt, kapcsolóval megspékelt cartridge...
- olyan programok amik nem futnak memóriabõvítõvel ellátott gépen (ha jól emlékszem a Jano féle átíratok élen jártak ebben...)
- olyan programok amik összeakadnak egyes ROM bõvítésekkel
- külön kiemelve, hogy volt olyan is, ami a közismert TAPE: problémán túl se mentek lemezes géppel, mert egész egyszerûn beleírt az EXDOS-nak kiutalt területbe. Ezek ugyan már át lettek bütykölve, de a dolog most fokozottan megismétlõdik a vinyóvezérlõvel, hiszen itt még több terület lesz lefoglalva a rendszerszegmensben, és itt különösen nem egészséges ha beleírunk a lefoglalt memóriába, akár nagyobb adatvesztés is lehet a vége!
A "Világ EP tulajdonosai egyesüljetek" :-) mozgalmunk keretében került elõtérbe az a probléma, hogy a létezõ EP programok kb 98%-a nem fut EP64-en, annak ellenére, hogy jelentõs részük fizikailag beférne a 64K-ba! És hiába vesz mondjuk egy MICROTEAM kártyát az EP64 tulajdonos, az így 576K-ra növelt memóriával se fog futni a 128-as programoknak még mindig vagy 96%-a... mivel az F8-FB szegmensek nem léteznek egy ilyen gépen. (Sajnos az ep128emu egyik hiányossága, hogy ilyen "lukas" memória konfigurációkat nem lehet emulálni, ezt csak EP32-ben lehet megcsinálni.) F8-FB szegmensek megvalósítása után még mindig sok programnak gondot okozna az EXOS 2.0

És amire nem került sor, de hatalmas balhé lett volna: ha kijött volna a tervezett szuper EP az EXOS 3.0-val, várhatóan szintén rengeteg program nem mûködött volna vele...
Szintén lettek volna problémák, ha anno kiadják a vinyóvezérlõt (amit az eladatlan SZJA '88 készletek miatt visszatartottak...)

Ennyi áttekintés után mindjárt jönnek a részletek :-)

Offline endi

  • EP addict
  • *
  • Posts: 7298
  • Country: hu
  • grafikus, játékfejlesztõ, programozás, scifi, tudományok, vallás
    • Honlapom
Re: EXOS kompatibilis memória kezelés
« Reply #1 on: 2008.November.12. 22:45:35 »
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.
Vigyázat! Szektás vagyok! :)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EXOS kompatibilis memória kezelés
« Reply #2 on: 2008.November.12. 22:57:49 »
... mivel az F8-FB szegmensek nem léteznek egy ilyen gépen. (Sajnos az ep128emu egyik hiányossága, hogy ilyen "lukas" memória konfigurációkat nem lehet emulálni, ezt csak EP32-ben lehet megcsinálni.)
Valóban :oops: Meglepő módon azonban lehet olyan snapshot file-t készíteni, amelyet betöltve átmenetileg a fenti konfiguráció jönne létre, tehát bármelyik szegmens lehetne ROM, RAM, vagy üres, csak a GUI és a konfigurációs file nem teszi lehetővé a beállítását.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: EXOS kompatibilis memória kezelés
« Reply #3 on: 2008.November.13. 01:05:01 »
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:
Code: ZiLOG Z80 Assembler
  1.         LD C,0FAH
  2.         EXOS 25
  3.         LD A,0FAH
  4.         OUT (0B2H),A
  5.  
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)
Code: ZiLOG Z80 Assembler
  1.         EXOS 24
  2.         JP NZ,HIBA  
  3.         LD A,C
  4.         OUT (0B2H),A
  5.  

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:
Code: ZiLOG Z80 Assembler
  1.                 LD BC,5FAH
  2. SZABAD          PUSH BC
  3.                 EXOS 25
  4.                 POP BC
  5.                 INC C
  6.                 DJNZ SZABAD
  7.  
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:
Code: ZiLOG Z80 Assembler
  1. FOGLAL          EXOS 24
  2.                 JP NZ,HIBA
  3.                 LD A,C
  4.                 CP 0F9H
  5.                 JR NZ,FOGLAL
  6.                 LD BC,5FAH
  7. EZKELL          PUSH BC
  8.                 EXOS 24
  9.                 LD A,C
  10.                 POP BC
  11.                 CP C
  12.                 JP NZ,HIBA
  13.                 INC C
  14.                 DJNZ EZKELL
  15.                 EXOS 24
  16.                 CP 7FH
  17.                 JP NZ,HIBA
  18.                 LD DE,3200
  19.                 EXOS 23
  20.                 JP NZ,HIBA
  21.                 LD L,0F9H
  22. VISSZAAD        LD C,L
  23.                 EXOS 25
  24.                 DEC L
  25.                 JR NZ,VISSZAAD
  26.  
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 :-)
« Last Edit: 2008.November.13. 01:14:18 by Zozosoft »

Offline Attus

  • EP addict
  • *
  • Posts: 1225
  • Country: hu
Re: EXOS kompatibilis memória kezelés
« Reply #4 on: 2008.November.13. 15:03:36 »
Ez volt a fix szegmensek használata szabályosan címû fejezet, majd alvás után folyt köv :-)
Szép volt Zozó! :)

Offline Povi

  • EP addict
  • *
  • Posts: 2296
  • Country: hu
    • http://povi.fw.hu
Re: EXOS kompatibilis memória kezelés
« Reply #5 on: 2008.November.13. 20:28:33 »
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.

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...
*** Speicherplatz zu klein

Offline Povi

  • EP addict
  • *
  • Posts: 2296
  • Country: hu
    • http://povi.fw.hu
Re: EXOS kompatibilis memória kezelés
« Reply #6 on: 2008.November.13. 20:43:43 »
Povi kérdezte, de talán másnak is hasznos lehet, így ime bõvebben kifejtve a memória kezelési téma, amolyan ENTERPRESS cikk pótlóként :-)
Kicsit OFF:
Igazából arra voltam kíváncsi, hogy hogyan lehet EXOS-kompatibilis Spectrum átiratokat készíteni, mert az SpV-ben megjelent cikk nem az. :) Főleg a képernyő emulálás probléma nekem (sose voltam LPT guru, az összes programom VIDEO: eszközt használ), nem igazán értem, mit miért lapozgatnak a kódban. Először FA a 2-es lapra, aztán FC az 1-esre. Majd később FB a 3-asra, majd FD az 1-esre. Most melyiken van a video-memória?!?! Az FC-n, vagy az FD-n?

Maga a memóriakezelés nem problémás, nézzétek meg az Atomix-et, EP64-en is elindul, EXOS 2.0 alatt, ha van elég memória (a 64kB nem elég :)), különben meg hibaüzenettel kilép. Anno ki is próbáltuk Zozoval igazi EP64-en is, persze memóriabővítéssel. (Az más kérdés, hogy EXOS 2.0 alatt soha nem jár le az idő, mert az EXOS 2.0 nem kezeli a felhasználói megszakítási rutint, de ez itt már tényleg OFF).
*** Speicherplatz zu klein

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: EXOS kompatibilis memória kezelés
« Reply #7 on: 2008.November.13. 20:49:03 »
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 :-)



Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: EXOS kompatibilis memória kezelés
« Reply #8 on: 2008.November.13. 20:50:45 »
Igazából arra voltam kíváncsi, hogy hogyan lehet EXOS-kompatibilis Spectrum átiratokat készíteni
Remélhetõleg ma eljutunk idáig a témában :-)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: EXOS kompatibilis memória kezelés
« Reply #9 on: 2008.November.13. 23:06:51 »
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:
Code: ZiLOG Z80 Assembler
  1.                 LD HL,RAMLISTA
  2.                 LD A,4
  3. FOGLAL          EX AF,AF'        
  4.                 EXOS 24
  5.                 JP NZ,HIBA
  6.                 LD (HL),C
  7.                 INC HL
  8.                 EX AF,AF'
  9.                 DEC A
  10.                 JR NZ,FOGLAL
Késöbb pedig pl a 3. szegmensre így hivatkozhatunk:
Code: ZiLOG Z80 Assembler
  1.                 LD A,(RAMLISTA+2)
  2.                 OUT (0B3H),A
  3.  

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ó:
Quote from: Spectrum Világ
EXOS 24 - Szegmens kijelölés. Memóriát célszerû az EXOS-tól kérni, mivel így biztosan nem kezd el más program is az általunk használni kívánt memóriában dolgozni. C regiszterben a kiutalt szegmens száma lesz. Programunk 3 db szegmenst foglal le, ez 48k, így minden SPECTRUM program belefér a tárba.
Sajnos a gyakorlati megvalósításba becsúszott egy kis hiba:
Code: ZiLOG Z80 Assembler
  1.           EXOS 24            ;Egy 16 kbyte meretu RAM szegmens lefoglalasa
  2.           LD A,C             ;es belapozasa
  3.           OUT (0B1H),A       ;az 1. lapra (4000H-7FFFH cimtartomany)
  4.           EXOS 24            ;Meg ket szegmens lefoglalasa
  5.           LD A,C             ;es belapozasa
  6.           OUT (0B2H),A       ;Ezekre fog toltodni a program
  7.           EXOS 24
  8.           OUT (0B3H),A
  9.  
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...

Offline Povi

  • EP addict
  • *
  • Posts: 2296
  • Country: hu
    • http://povi.fw.hu
Re: EXOS kompatibilis memória kezelés
« Reply #10 on: 2008.November.13. 23:12:24 »
Mindig a legizgalmasabb résznél marad abba a cikk, pont, mint egy brazil jellegű szappanopera! :)
(kéne csinálni új ENTERPRESS számokat - elég lenne csak pdf-ben is - hogy az ilyen cikkeket lehessen olvasgatni később is; a legjobb dolgok fél év múlva mindig elvesznek a fórum mélyén valahol...)
*** Speicherplatz zu klein

Offline MrPrise

  • Administrator
  • EP addict
  • *
  • Posts: 2755
  • Country: hu
    • Enterprise Forever
Re: EXOS kompatibilis memória kezelés
« Reply #11 on: 2008.November.13. 23:20:45 »
a legjobb dolgok fél év múlva mindig elvesznek a fórum mélyén valahol...)
Ezért javasoltam már régebben, hogy a hasznos dolgokat össze kellene gyűjteni (egyelőre) a wiki-n.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: EXOS kompatibilis memória kezelés
« Reply #12 on: 2008.November.13. 23:21:39 »
Mindig a legizgalmasabb résznél marad abba a cikk, pont, mint egy brazil jellegû szappanopera! :)
Vacsorázni is kell valamikor :-)
Quote
kéne csinálni új ENTERPRESS számokat - elég lenne csak pdf-ben is
Már javasoltam a Fõszerkesztõ úrnak, hogyha végzett a régi számok bedigitalizálásával, akkor lehetne újakat is csinálni :-)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14723
  • Country: hu
    • http://enterprise.iko.hu/
Re: EXOS kompatibilis memória kezelés
« Reply #13 on: 2008.November.14. 00:23:10 »
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.

Quote
míg végre megkapjuk pl. a hõn áhított FC szegmensünket
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".


Offline Povi

  • EP addict
  • *
  • Posts: 2296
  • Country: hu
    • http://povi.fw.hu
Re: EXOS kompatibilis memória kezelés
« Reply #14 on: 2008.November.14. 10:30:33 »
ami egyben a Spectrumos memória elsõ 16K-ja is lesz.

Hülye kérdés, de én nem tudom. Spectrumon akkor ezek szerint 0000-3FFF között a ROM van?
*** Speicherplatz zu klein