Enterprise Forever

:HUN => Programozás => Topic started by: Zozosoft on 2008.November.12. 22:38:18

Title: EXOS kompatibilis memória kezelés
Post by: Zozosoft 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 :-)
Title: Re: EXOS kompatibilis memória kezelés
Post by: endi 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.
Title: Re: EXOS kompatibilis memória kezelés
Post by: IstvanV 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.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft 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 :-)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Attus 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ó! :)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi 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...
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi 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).
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft 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 :-)


Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft 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 :-)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft 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...
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi 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...)
Title: Re: EXOS kompatibilis memória kezelés
Post by: MrPrise 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.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft 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 :-)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft 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".

Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi 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?
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.14. 10:44:32
Spectrumon akkor ezek szerint 0000-3FFF között a ROM van?
Így van.
Title: Re: EXOS kompatibilis memória kezelés
Post by: endi on 2008.November.15. 21:08:47
Egy kérdés: volt valami olyasmi, hogy a videó memben lassabban futottak a programok és volt egy port ahol be lehetett állítani hogy a sima mem is ugyanolyan lassú legyen. Jól emlékszem?
Erre nem volt valami Exos rutin hogy ha lehet gyors memóriát kapjak ha kérek? :)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Attus on 2008.November.15. 21:37:37
Egy kérdés: volt valami olyasmi, hogy a videó memben lassabban futottak a programok és volt egy port ahol be lehetett állítani hogy a sima mem is ugyanolyan lassú legyen. Jól emlékszem?
Erre nem volt valami Exos rutin hogy ha lehet gyors memóriát kapjak ha kérek? :)
Nincs rá külön rutin. A videó szegmensek fixek: FC, FD, FE, FF.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.15. 22:26:47
A videó szegmensek fixek: FC, FD, FE, FF.
És mivel az összes többi ennél alacsonyabb számú, így a sima igénylésre, amíg van szabad, nem videó ram-ot fogunk kapni.
Title: Re: EXOS kompatibilis memória kezelés
Post by: IstvanV on 2008.November.15. 22:33:42
Egy kérdés: volt valami olyasmi, hogy a videó memben lassabban futottak a programok és volt egy port ahol be lehetett állítani hogy a sima mem is ugyanolyan lassú legyen. Jól emlékszem?
Nem, a "normál" memóriát ugyan az alapértelmezéshez képest lehet lassítani és gyorsítani is a 0BFh porton, de annyira lassú, mint a video memória, nem lesz semmilyen beállítással. A video RAM sebességére viszont nincs hatása ennek a portnak.
Title: Re: EXOS kompatibilis memória kezelés
Post by: endi on 2008.November.15. 22:35:51
Akkor minek lehetett lassítani? :) Én azt hittem hogy pont azért hogy ne fusson semmi gyorsabban ep128-on mint ep64-en, ahol ügye csak vidmem van. :)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.15. 22:41:18
Akkor minek lehetett lassítani? :)
Azért, hogy olcsóbb, lassabb RAM IC-ket is be lehessen szerelni a gépekbe. Én találkoztam is olyan géppel, amiben olyan 300 nanos RAM IC-k voltak, hogy az OUT 191,12 (vagyis a teljes sebesség) hatására fagyogatott.
Title: Re: EXOS kompatibilis memória kezelés
Post by: endi on 2008.November.15. 22:46:31
Ááááh. :D
Hát igen... Úgy tudom ma is úgy megy, hogy legyártják a procit aztán megnézik "hogy sikerült", azaz mennyit bír, és úgy adják el. :)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.17. 20:04:14
Folytassuk a "mesedélutánt" :-) némi gyakorlatiasabb részekkel, Povi már biztos nagyon várja :-)
Én ezt a rutin használom a Spectrum átirat betöltõimben videó szegmens igénylésre:
Code: ZiLOG Z80 Assembler
  1. VID             LD HL,VEGE
  2.                 LD (HL),0
  3. KER             EXOS 24
  4.                 JR Z,NAMIVAN
  5.                 CP 7FH
  6.                 JP NZ,HIBA
  7. NAMIVAN         EX AF,AF'
  8.                 LD A,C
  9.                 CP 0FCH
  10.                 JR NC,NEMKER
  11.                 INC HL
  12.                 LD (HL),C
  13.                 JR KER
  14. NEMKER          EX AF,AF'
  15.                 PUSH BC
  16.                 PUSH AF
  17. VISSZA          LD C,(HL)
  18.                 EXOS 25
  19.                 DEC HL
  20.                 JR Z,VISSZA
  21.                 POP AF
  22.                 POP BC
  23.                 OR A
  24.                 RET
A rutin a VEGE címtõl (amely logikusan a programkód után helyezkedik el) tárolja el a felesleges szegmenseket. Miután akadt egy (amely lehet megosztott is), a felesleget visszaadja az EXOS-nak.
Elõször a képernyõnek kérünk egy teljes szegmenst:
Code: ZiLOG Z80 Assembler
  1.                 CALL VID
  2.                 JP NZ,HIBA
  3.                 LD A,C
  4.                 CP 255
  5.                 JP Z,HIBA
  6.                 LD (VIDS),A
  7.                 LD DE,0
  8.                 RRA
  9.                 RR D
  10.                 RRA
  11.                 RR D
  12.                 LD (VIDCIM1),DE
A kapott szegmensszámból kiszámoljuk a terület kezdetének címét, erre késöbb az LPT generáláskor szükség lesz.
Késöbb kérünk egy LPT szegmenst is, ami lehet megosztott is, ha elfér benne az LPT tábla (azaz az EXOS határ beállítható a megfelelõ helyre.)
Code: ZiLOG Z80 Assembler
  1.                 CALL VID
  2.                 JR Z,NEMHIBA
  3.                 CP 7FH
  4.                 JP NZ,HIBA
  5.                 LD DE,200*16
  6.                 EXOS 23
  7.                 JP NZ,HIBA
  8.                 LD C,255
  9. NEMHIBA         LD A,C
  10.                 LD (LPTS),A
  11. NEMHIBA1        LD DE,(VIDCIM2)
  12.                 LD HL,0
  13.                 RRA
  14.                 RR H
  15.                 RRA
  16.                 RR H
  17.                 ADD HL,DE
  18.                 LD (VIDCIM2),HL
Itt is kiszámoljuk a videó címet, ezúttal az LPT tábla kezdetét. A figyelmes szemlélõ észreveheti, hogy itt még játékba áll a VIDCIM2-n korábban lévõ érték. Ez alapban nulla, viszont 64K-s gépen úgy fog átrendezõdni a memória, hogy nem a szegmens elejére kerül az LPT tábla, ekkor a szükséges eltolás mértéke került már ekkora a VIDCIM2-re.
Ezekután nézzük meg, hogyan változik a SpV-ban is közölt LPT generáló rutin, ime az eredeti rutin kezdete:
Code: ZiLOG Z80 Assembler
  1.         LD A,0FCH
  2.         OUT (0B1H),A
  3.         LD A,192
  4.         LD DE,4000H
  5.         EXX
  6.         LD DE,4000H
  7.         LD HL,4004H
  8.         LD BC,13
  9.  
És ez lesz belõle:
Code: ZiLOG Z80 Assembler
  1.                 LD A,(LPTS)
  2.                 OUT (0B1H),A
  3.                 LD A,192
  4.                 LD DE,(VIDCIM2)
  5.                 RES 7,D
  6.                 SET 6,D
  7.                 EXX
  8.                 LD DE,(VIDCIM1)
  9.                 LD IX,VIDCIM1
  10.                 LD HL,(VIDCIM2)
  11.                 RES 7,H
  12.                 SET 6,H
  13.                 INC HL
  14.                 INC HL
  15.                 INC HL
  16.                 INC HL
  17.                 LD BC,13
A fix szegmensszám helyett az eltároltat használjuk. A DE fog mutatni az LPT elejére az 1-es lapon, de a korábban említett esetleges eltolás miatt ezt az LPT videócímébõl számoljuk vissza 1-es lapi címre. Az EXX utáni DE a videó memóriánk kezdetére fog mutatni, ez az eredeti rutinban fix 4000H volt, mivel az FDH volt fixen erre a célra használva. A HL pedig szintén az LPT területre fog mutatni, 4 bájt eltolással, õ az LPT sorokba való címbeírásnál van használva.
Nem esett még szó az IX-rõl, õ videó memóriánk címét tároló változóra mutat. Azért mert, még egy helyen hozzá kellett nyulni az eredeti rutinhoz, még pedig az attributtum címek kiszámolásánál:
Code: ZiLOG Z80 Assembler
  1.         LD A,D
  2.         RRA
  3.         RRA
  4.         RRA
  5.         AND 3
  6.         OR 58H
  7.         LD (HL),A
  8.  
Módosítva:
Code: ZiLOG Z80 Assembler
  1.                 LD A,D
  2.                 RRA
  3.                 RRA
  4.                 RRA
  5.                 AND 3
  6.                 OR 18H
  7.                 OR (IX+1)
  8.                 LD (HL),A
  9.  
Ezekután már csak az LPT aktiváló OUT utasításokat kell módosítani, az eredeti nagyon egyszerû, mivel a fix 0000H videó címet használja:
Code: ZiLOG Z80 Assembler
  1.         XOR A
  2.         OUT (82H),A
  3.         LD A,192
  4.         OUT (83H),A
  5.  
És módosítva, hogy a kiszámolt LPT címünket használja:
Code: ZiLOG Z80 Assembler
  1.                 XOR A
  2.                 LD HL,VIDCIM2+1
  3.                 RRD
  4.                 RLCA
  5.                 RLCA
  6.                 RLCA
  7.                 RLCA
  8.                 OUT (82H),A
  9.                 OR 0C0H
  10.                 RRD
  11.                 OUT (83H),A
Megjegyzés, ez a módszer elrontja a VIDCIM2 változó értékét, de erre az adott esetben úgysincs többé szükség.
De itt egy másik módszer is, itt az eredeti EXOS LPT visszaállítására van használva:
Code: ZiLOG Z80 Assembler
  1.                 LD HL,(0BFF4H)
  2.                 SET 6,H
  3.                 LD B,4
  4. FORG4           SRL H
  5.                 RR L
  6.                 DJNZ FORG4
  7.                 LD A,L
  8.                 OUT (82H),A
  9.                 LD A,H
  10.                 OR 0C0H
  11.                 OUT (83H),A
A címet az EXOS LP_POINTER változójából olvassuk ki (tehát legyen belapozva a rendszerszegmens a 2. lapra), az utána következõ SET 6 azért van, hogy videócímre konvertáljuk az EXOS változót, ha saját kiszámolt videócímünket használjuk, akkor erre nincs szükség.

Ha van érdeklõdés, folytathatom azzal, hogyan lesz egy 48K-s átírat számára 3 szabadon használható szegmensünk 64K-s gépen, amikor csak kettõ van szabadon, és még az LPT táblának is kéne egy :-)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.17. 21:09:05

Code: ZiLOG Z80 Assembler
  1.                 CALL VID
  2.                 JR Z,NEMHIBA
  3.                 CP 7FH
  4.                 JP NZ,HIBA
  5.                 LD DE,200*16
  6.                 EXOS 23
  7.                 JP NZ,HIBA
  8.                 LD C,255
  9. NEMHIBA         LD A,C
  10.                 LD (LPTS),A
  11. NEMHIBA1        LD DE,(VIDCIM2)
  12.                 LD HL,0
  13.                 RRA
  14.                 RR H
  15.                 RRA
  16.                 RR H
  17.                 ADD HL,DE
  18.                 LD (VIDCIM2),HL

Itt nekem valami nem tiszta. Ha jól értelmezem a kódot, akkor LPT memória igénylés esetében, ha megosztott szegmenst kapunk, akkor a 255-ös szegmensen lesz az LPT. De miért? Miért van ott az az LD C,255?
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.17. 21:11:08
Miért van ott az az LD C,255?
Az elõtte lévõ EXOS 23 hívás elrontja a C értékét, azt állítjuk vissza.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.17. 21:13:31
Azt én értem, na de megosztott szegmens csak a 255-ös lehet?
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.17. 21:26:31
Azt én értem, na de megosztott szegmens csak a 255-ös lehet?
Jogos a kérdés, a válasz igen is meg nem is :-)
Mivel 5-ös fejlécû programként indulunk, ez esetben minden csatorna le van zárva, nincs mitõl kilógjon az EXOS. Ha mondjuk rendszerbõvítõként ügyködnénk, amikor elõfordulhat megnyitott videólap, akkor lehet lentebb az EXOS határ. (Az Iview ezért modultöltéskor be is zár minden csatornát, ami nem a képfájl, hogy az EXOS "visszahúzodjon")
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.17. 21:32:03
Na jó, ez már csak kötekedés, de mi van, ha alapból teli van már a 255-ös szegmens, pl. van vinyóvezérlő+egér+órakártya EXOS 3.0, SZJA '88 stb.? :)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.17. 21:34:00
De egyébként én is hasonlóan gondolkodom, mint te, mert a saját programjaimban, ha nyitottam egy VIDEO: csatornát, úgy vettem, hogy egy része biztos bele esik a 255-ös szegmensbe...
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.17. 21:38:06
Na jó, ez már csak kötekedés, de mi van, ha alapból teli van már a 255-ös szegmens, pl. van vinyóvezérlõ+egér+órakártya EXOS 3.0, SZJA '88 stb.? :)
Azon a gépen amúgy se mûködik egy program se :-) (fõleg ha az EXOS 3.0-ban is benne van az a hiba ami a 2.0-ban és a 2.1-ben benne van)
De akkor legyen így:
Code: ZiLOG Z80 Assembler
  1. VID             LD HL,VEGE
  2.                 LD (HL),0
  3. KER             EXOS 24
  4.                 JR Z,NAMIVAN
  5.                 CP 7FH
  6.                 JP NZ,HIBA
  7.                 ld a,c
  8.                 cp 255
  9.                 jp nz,hiba
  10.                 ld a,7fh
  11. NAMIVAN         EX AF,AF'
  12.                 LD A,C
  13.                 CP 0FCH
  14.                 JR NC,NEMKER
  15.                 INC HL
  16.                 LD (HL),C
  17.                 JR KER
  18. NEMKER          EX AF,AF'
  19.                 PUSH BC
  20.                 PUSH AF
  21. VISSZA          LD C,(HL)
  22.                 EXOS 25
  23.                 DEC HL
  24.                 JR Z,VISSZA
  25.                 POP AF
  26.                 POP BC
  27.                 OR A
  28.                 RET
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.17. 21:47:42
Most megint egy kis értetlenséget hagytál bennem. Most ha megosztott szegmenst kapunk, de az nem a 255-ös, akkor hiba. De miért? Miért nem kaphatnánk meg a 254-est megosztottként?
Én nem a VID rutint módosítanám, hanem amikor az LPT részére kérünk szegmenst, akkor az EXOS 23 előtt lenne egy LD H,C az LD C,255 helyett pedig egy LD C,H.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.17. 21:55:21
Én nem a VID rutint módosítanám, hanem amikor az LPT részére kérünk szegmenst, akkor az EXOS 23 elõtt lenne egy LD H,C az LD C,255 helyett pedig egy LD C,H.
Igen végül is lehet ez is, csak akkor más program részeket is át kell nézni :-) (amikrõl még nem volt szó)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.17. 22:05:23
Akkor maradjon minden az eredetiben...
Én megyek aludni...
Title: Re: EXOS kompatibilis memória kezelés
Post by: szipucsu on 2008.November.18. 00:40:09
Felraktam a wikire (http://wiki.enterpriseforever.com/index.php?title=EXOS_kompatibilis_mem%C3%B3riakezel%C3%A9s) a disszertáció eddig itt olvasható részét. A copypaste miatt a kódok eléggé rémálomba illõen néznek ki. Kb. a Zozo által írtakat tettem fel. Aki érti is, hogy mirõl szól a disszertáció, finomíthat rajta a wikin, elvehet belõle, hozzátehet. :)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.20. 13:44:43
Késöbb kérünk egy LPT szegmenst is, ami lehet megosztott is, ha elfér benne az LPT tábla (azaz az EXOS határ beállítható a megfelelõ helyre.)

...amikor csak kettõ van szabadon, és még az LPT táblának is kéne egy :-)

Miért kell az LPT-tábla számára külön szegmenst kérni? Nem férne be a video-memória (ha jól tudom csak 6912 byte) mellé?
Title: Re: EXOS kompatibilis memória kezelés
Post by: gafz on 2008.November.20. 13:48:05
Miért kell az LPT-tábla számára külön szegmenst kérni? Nem férne be a video-memória (ha jól tudom csak 6912 byte) mellé?

Szerintem akkor felülírná a program az LPT-t.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.20. 13:52:55
Szerintem akkor felülírná a program az LPT-t.
Így van!
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.20. 14:31:29
Ezt most nem értem...  :oops:
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.20. 14:39:16
A Spectrumos memória kiosztás úgy néz ki, 4000-5AFFH a képernyõ, 5B00-FFFFH az általános RAM, ahol a program fut.
Ha oda tennénk az LPT-t a képernyõ mögé, a program felülírja.
Persze ha olyan alaposan átírjuk a programot, hogy már nem a Spectrumos memória kiosztást használja, akkor megoldható... ill. saját EP-s program írása esetén is úgy pakolgatunk, ahogy jól esik :-)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.23. 10:25:20
Megcsináltam a Spectris-t a Zozo féle útmutatások alapján, hogy EXOS-kompatibilis legyen. Most már gond nélkül fut EP64-en is, viszont a status sorban szemetet jelenít meg.
[attach=#]
Title: Re: EXOS kompatibilis memória kezelés
Post by: geco on 2008.November.23. 11:10:28
EXOS 2.0-ában a státusz sor kezdete el van tolva EXOS2.1-hez képest, és a karaktermemória címe is, ezért jelenik meg a 4 kuka karakter.
EXOS 2.0: 0febch 01edh
EXOS 2.1: 0feb8h 01e9h
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.23. 11:38:49
Igen, de és a status sor címét a BFF6-on eltárolt word alapján veszem, tehát nem emiatt lehet a hiba.
Meg a két alsó pixelsor is hiányzik, itt valami LPT-hiba lehet, de én ahhoz nem értek...  :oops:
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.23. 11:41:45
Megnéztem, hogy csinálja Zozo a Bumpy-ban:
Code: [Select]
                LD HL,(0BFF4H)
                LD DE,STATUS
                LD BC,8
                LDIR

Így már nem hibás, de nem igazán értem, mit csinál ez a pár sor...    :roll:

BFF4 - Sorparaméter-tábla Z80-as címe
Title: Re: EXOS kompatibilis memória kezelés
Post by: geco on 2008.November.23. 12:14:06
Ez tök jó, én eddig mindig kiderítettem, hogy EXOS 2.0-áról van-e szó, vagy 2.1-ről, és az alapján állítottam be az értéket.
betölti a sorparamáter tábla címét HL-be, majd a bemásolja gondolom Zozo LPT-jének státusz részére színinfó nélkül.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.23. 14:06:38
Így már nem hibás, de nem igazán értem, mit csinál ez a pár sor...    :roll:

BFF4 - Sorparaméter-tábla Z80-as címe

Ez kimásolja az EXOS LPT táblából a Status sor LPB-jét, a paletta szinek nélkül. Mivel nem csak maga a status sor van máshol,hanem a karakterkészlet is, így egyben a legegyszerübb.
Ami fontos: a program elején EXOS változó irással kapcsoljuk be a status sort, és gondoskodjunk arról,hogy legalább egy videó megszakitás lefusson, mire ehhez a másolós részhez érünk.
Különben nem biztos,hogy a nekünk szükséges érvényes status sor adatok lesznek ott.(Ezzel szívtam egy darabig,míg rájöttem :)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.23. 17:11:36
és gondoskodjunk arról,hogy legalább egy videó megszakitás lefusson, mire ehhez a másolós részhez érünk.
Magyarul: a másolós rész elé tegyek egy HALT-ot?
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2008.November.23. 17:31:10
Magyarul: a másolós rész elé tegyek egy HALT-ot?
Ez pl egy jó megoldás :-)
Title: Re: EXOS kompatibilis memória kezelés
Post by: Povi on 2008.November.23. 20:46:43
Ami fontos: a program elején EXOS változó irással kapcsoljuk be a status sort
Nekem az a tapasztalatom, hogy a NAP bekapcsolja magának a status sort, nekünk nem kell vele foglalkozni.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Ferro73 on 2009.September.27. 18:23:45
Elolvastam de nem találtam olyan lehetöséget bár már láttam valamely formáit
Elképzelésem
   ld a,255
  out (0b2h),a
  ld hl,(0bf91h)     ;exos  alsó határ
  ld a,(0bf9eh)
  cp 0
  jp z,nincsoszt
  cp 255
  jp nz,nemrencers
 
  ld bc,hl  ;ex hl,bc ; push hl  pop bc
  ld hl,0
  ld de,8000h
  ldir
  ld a,255
  out (0b0h),a
mivel nem találtam utalást az exos mennyi és meik részét használja a 255-ös szegmensböl
gondolok a tape: disk: és egyéb átmeneti tárakra.
A fenn maradó helyen valahol csak elférne az LPT tábla és akkor felszabadul az FC szegmens
Mivel  a 0-3fff között ugy is Rom van a ZX gépeken igy nem fogja semmi zavarni a rendszer memoriát /FF,FD,FC,FE/

ha jól emlékszek akkor a 0.rom visszafejtése könyv a végén taglalja a rendszer szegmens terület használatát megvan valakinek ez a könyv, nem találtam teljes e-könnyvet.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2009.September.29. 10:55:39
Elolvastam de nem találtam olyan lehetöséget bár már láttam valamely formáit
Elképzelésem
Az elképzelés jó, de a gyakorlati megvalósításban több hiba is van.
Quote
 ld a,255
  out (0b2h),a
  ld hl,(0bf91h)     ;exos  alsó határ
  ld a,(0bf9eh)
Pl ezek máshol vannak EXOS 2.0 alatt, így nem érdemes közvetlenül vájkálni az EXOS lelkivilágában :-)
Quote
  ld bc,hl  ;ex hl,bc ; push hl  pop bc
  ld hl,0
  ld de,8000h
  ldir
Hiányzik az ellenõrzés, hogy elférünk-e?
Quote
  ld a,255
  out (0b0h),a
Az EXOS-nak is meg kell mondani a változást, különben pl Reset esetén az eredeti nullás lapot lapozza vissza, és kész az elszállás.
Quote
mivel nem találtam utalást az exos mennyi és meik részét használja a 255-ös szegmensböl
gondolok a tape: disk: és egyéb átmeneti tárakra.
Ez folyamatos változik! Ezért kell lefoglalni megosztott szegmensként, majd megmondani, hogy MI mennyit használunk (felhasználói határ beállítása).
Quote
A fenn maradó helyen valahol csak elférne az LPT tábla és akkor felszabadul az FC szegmens
Mivel  a 0-3fff között ugy is Rom van a ZX gépeken igy nem fogja semmi zavarni a rendszer memoriát /FF,FD,FC,FE/
Így van, ez az amit már megcsináltam a Spectrum átiratos betöltõmben már vagy 3 éve :-)
Itt van kiemelve a lényeg:
Code: ZiLOG Z80 Assembler
  1. PRGSIZE:   EQU 0B00H ;a programunk méretéhez kell választani, de 10H-ra kerek legyen
  2.                 LD SP,100H
  3.                 LD HL,HIBA
  4.                 LD (0BFF8H),HL
  5.                 LD A,12
  6.                 OUT (191),A
  7.                 LD BC,100H+26
  8.                 LD D,0
  9.                 EXOS 16
  10.                 LD BC,100H+28
  11.                 LD D,255
  12.                 EXOS 16
  13.                 LD BC,100H+27
  14.                 LD D,0
  15.                 EXOS 16
  16.                 HALT
  17.                 LD HL,(0BFF4H)
  18.                 SET 6,H
  19.                 LD B,4
  20. ELPT            SRL H
  21.                 RR L
  22.                 DJNZ ELPT
  23.                 LD A,L
  24.                 LD (ELPTL),A
  25.                 LD A,H
  26.                 OR 0C0H
  27.                 LD (ELPTH),A
  28.                 LD HL,(0BFF4H)
  29.                 LD DE,STATUS
  30.                 LD BC,8
  31.                 LDIR
  32.                 CALL VID
  33.                 JP NZ,HIBA
  34.                 LD A,C
  35.                 CP 255
  36.                 JP Z,HIBA
  37.                 LD (VIDS),A
  38.                 LD DE,0
  39.                 RRA
  40.                 RR D
  41.                 RRA
  42.                 RR D
  43.                 LD (VIDCIM1),DE
  44.                 EXOS 24
  45.                 LD A,C
  46.                 LD (P2S),A
  47.                 JP NZ,HIBA
  48.                 EXOS 24
  49.                 JR Z,OKEP3
  50.                 CP 7FH
  51.                 JP NZ,HIBA
  52.                 LD A,C
  53.                 LD (LPTS),A
  54.                 OUT (0B3H),A
  55.                 CP 0FCH
  56.                 JP C,HIBA
  57.                 LD DE,PRGSIZE+200*16
  58.                 EXOS 23
  59.                 JP NZ,HIBA
  60.                 DI
  61.                 IN A,(0B0H)
  62.                 LD (P0S),A
  63.                 LD (P3S),A
  64.                 LD DE,PRGSIZE
  65.                 LD (VIDCIM2),DE
  66.                 LD HL,0
  67.                 LD DE,0C000H
  68.                 LD BC,PRGSIZE-1
  69.                 LDIR
  70.                 IN A,(0B3H)
  71.                 OUT (0B0H),A
  72.                 LD (0BFFCH),A
  73.                 LD A,(P3S)
  74.                 OUT (0B3H),A
  75.                 LD A,(LPTS)
  76.                 JR NEMHIBA1
  77. OKEP3           LD A,C
  78.                 LD (P3S),A
  79.                 OUT (0B3H),A
  80.                 CALL VID
  81.                 JR Z,NEMHIBA
  82.                 CP 7FH
  83.                 JP NZ,HIBA
  84.                 LD DE,200+16
  85.                 EXOS 23
  86.                 JP NZ,HIBA
  87.                 LD C,255
  88. NEMHIBA         LD A,C
  89.                 LD (LPTS),A
  90. NEMHIBA1        CALL LPT
  91.                 LD A,(VIDS)
  92.                 OUT (0B1H),A
  93.                 LD A,(P2S)
  94.                 OUT (0B2H),A
  95.                 XOR A
  96.                 LD DE,(VIDCIM2)
  97.                 LD HL,VIDCIM2+1
  98.                 RRD
  99.                 RLCA
  100.                 RLCA
  101.                 RLCA
  102.                 RLCA
  103.                 LD (LPTL),A
  104.                 OUT (82H),A
  105.                 OR 0C0H
  106.                 RRD
  107.                 LD (LPTH),A
  108.                 OUT (83H),A
  109.                 LD (VIDCIM2),DE
  110.  
Az LPT létrehozás, ami mint lentebb említettem változik az eredeti SpV-ben közöltekhez képest, mivel nem fix helyen van, így kezelni kell a változó videócímeket.
Code: ZiLOG Z80 Assembler
  1. LPT:            LD DE,(VIDCIM2)
  2.                 LD HL,0
  3.                 RRA
  4.                 RR H
  5.                 RRA
  6.                 RR H
  7.                 ADD HL,DE
  8.                 LD (VIDCIM2),HL
  9. LPT2:           LD A,(LPTS)
  10.                 OUT (0B1H),A
  11.                 LD A,192
  12.                 LD DE,(VIDCIM2)
  13.                 RES 7,D
  14.                 SET 6,D
  15.                 EXX
  16.                 LD DE,(VIDCIM1)
  17.                 LD IX,VIDCIM1
  18.                 LD HL,(VIDCIM2)
  19.                 RES 7,H
  20.                 SET 6,H
  21.                 INC HL
  22.                 INC HL
  23.                 INC HL
  24.                 INC HL
  25.                 LD BC,13
  26. L1              EX AF,AF'
  27.                 EXX
  28.                 LD HL,LINE
  29.                 LD BC,16
  30.                 LDIR
  31.                 EXX
  32.                 LD (HL),E
  33.                 INC HL
  34.                 LD A,D
  35.                 RRA
  36.                 RRA
  37.                 RRA
  38.                 AND 3
  39.                 OR 18H
  40.                 OR (IX+1)
  41.                 LD (HL),A
  42.                 INC HL
  43.                 LD (HL),E
  44.                 INC HL
  45.                 LD (HL),D
  46.                 ADD HL,BC
  47.                 INC D
  48.                 LD A,D
  49.                 AND 7
  50.                 JR NZ,L2
  51.                 LD A,E
  52.                 ADD A,32
  53.                 LD E,A
  54.                 CCF
  55.                 SBC A,A
  56.                 AND 0F8H
  57.                 ADD A,D
  58.                 LD D,A
  59. L2              EX AF,AF'
  60.                 DEC A
  61.                 JR NZ,L1
  62.                 EXX
  63.                 LD HL,SYNC
  64.                 LD BC,HOSSZ
  65.                 LDIR
  66.                 RET
  67. LINE            DB 255,14H,15,2FH,0,0,0,0
  68. TABL            DB 0,36,121,88,130,182,219,63
  69. SYNC            DB 0F5H,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0
  70. STATUS          DB 247,8,11,73H,0B8H,0FEH,0E9H,1,0,216,216,0,0,0,0,0
  71.                 DB 217,12H,63,0,0,0,0,0,0,0,0,0,0,0,0,0
  72.                 DB 253,16,63,0,0,0,0,0,0,0,0,0,0,0,0,0
  73.                 DB 252,16,6,63,0,0,0,0,0,0,0,0,0,0,0,0
  74.                 DB 255,90H,63,32,0,0,0,0,0,0,0,0,0,0,0,0
  75.                 DB 252,12H,6,63,0,0,0,0,0,0,0,0,0,0,0,0
  76.                 DB 207,13H,63,0,0,0,0,0,0,0,0,0,0,0,0,0
  77. HOSSZ           EQU $-SYNC
  78.  
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2012.July.28. 23:15:21
Elkezdtem csinálni egy ilyet (http://enterprise.iko.hu/memorymap.htm), hogy a direkt címeket használó programokat is EXOS 2.0 kompatibilissé lehessen tenni. Ha másként nem megoldható, akkor verzió ellenõrzés után a megfelelõ direkt cím használatával.
Title: Re: EXOS kompatibilis memória kezelés
Post by: lgb on 2012.September.30. 21:47:10
Lehet, nem pont ide tartozik, de ... Eppen arra gondoltam egy raero oramban, hogy sok mindent gyorsabb C-ben kiprobalni aztan szepen atirni assembly-be/megirni rendesen. Az sdcc tud is Z80-ra forditani, par kiserlet utan ossze is hoztam valamit, meg irtam hozza sajat crt0-t stb. Egy a baj: ha egy C-ben irt, majd leforditott programot megprobalok betolteni az emulatorba, a Load error: re-starting system jon. Ez mit jelenthet konkretan?

A program fejlece igy nez ki:

00 05 46 22 00 00 00 00 00 00 00 00 00 00 00 00

Amire tippelni tudok: lathato, hogy a program meret viszonylag nagy: 0x2246 byte. Azonban fontos, hogy maga a program merete boven par szaz byte (file-kent) csak. A kulonbseget az okozza, hogy eleg sok csak futas kozben hasznalt plusz memoriaterulet kell neki (illetve hogy hozzacsapok fel K-nyi memoriaigenyt a stack-nek amit inicializalok is ott mielott a _main megkapja a vezerelest ami mar a C forditott kod). Vagy en gondolom rosszul, hogy az 5-os tipusu exos fejlecnel a meretnel az a meret kell amit a program a _memoriaban_ elfoglal, tehat semmi koze ahhoz, hogy a disk-en mennyit?

Ha nem, mi lehet a load error oka? Thx.
Title: Re: EXOS kompatibilis memória kezelés
Post by: Zozosoft on 2012.September.30. 22:13:44
Vagy en gondolom rosszul, hogy az 5-os tipusu exos fejlecnel a meretnel az a meret kell amit a program a _memoriaban_ elfoglal, tehat semmi koze ahhoz, hogy a disk-en mennyit?
Igen, rosszul gondolod!
Annyinak kell lenni, amennyi a betöltendő bájtok. Ha plusz területet szeretnél, akkor töltsd fel 0-kkal, de ha 3FFF-ig akarod csak használni, akkor nem muszáj, a nullás lap mindig az aktuális programé.