... 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.
Ez volt a fix szegmensek használata szabályosan címû fejezet, majd alvás után folyt köv :-)Szép volt Zozó! :)
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.
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:
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 :-)
Igazából arra voltam kíváncsi, hogy hogyan lehet EXOS-kompatibilis Spectrum átiratokat készíteniRemélhetõleg ma eljutunk idáig a témában :-)
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:
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.
Mindig a legizgalmasabb résznél marad abba a cikk, pont, mint egy brazil jellegû szappanopera! :)Vacsorázni is kell valamikor :-)
kéne csinálni új ENTERPRESS számokat - elég lenne csak pdf-ben isMár javasoltam a Fõszerkesztõ úrnak, hogyha végzett a régi számok bedigitalizálásával, akkor lehetne újakat is csinálni :-)
míg végre megkapjuk pl. a hõn áhított FC szegmensünketEz viszont megint helytelen hozzáállás. Mert áhítozhatunk rá, de EP64-en nem fogjuk megkapni, mivel az csücsül a nulláslapon.
ami egyben a Spectrumos memória elsõ 16K-ja is lesz.
Spectrumon akkor ezek szerint 0000-3FFF között a ROM van?Így van.
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?Nincs rá külön rutin. A videó szegmensek fixek: FC, FD, FE, FF.
Erre nem volt valami Exos rutin hogy ha lehet gyors memóriát kapjak ha kérek? :)
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.
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.
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.
Code: ZiLOG Z80 Assembler
CALL VID JR Z,NEMHIBA CP 7FH JP NZ,HIBA LD DE,200*16 EXOS 23 JP NZ,HIBA LD C,255 NEMHIBA LD A,C LD (LPTS),A NEMHIBA1 LD DE,(VIDCIM2) LD HL,0 RRA RR H RRA RR H ADD HL,DE LD (VIDCIM2),HL
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.
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 :-)
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)
É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ó)
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é?
Szerintem akkor felülírná a program az LPT-t.Így van!
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: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.
BFF4 - Sorparaméter-tábla Z80-as címe
é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?
Magyarul: a másolós rész elé tegyek egy HALT-ot?Ez pl egy jó megoldás :-)
Ami fontos: a program elején EXOS változó irással kapcsoljuk be a status sortNekem az a tapasztalatom, hogy a NAP bekapcsolja magának a status sort, nekünk nem kell vele foglalkozni.
Elolvastam de nem találtam olyan lehetöséget bár már láttam valamely formáitAz elképzelés jó, de a gyakorlati megvalósításban több hiba is van.
Elképzelésem
ld a,255Pl ezek máshol vannak EXOS 2.0 alatt, így nem érdemes közvetlenül vájkálni az EXOS lelkivilágában :-)
out (0b2h),a
ld hl,(0bf91h) ;exos alsó határ
ld a,(0bf9eh)
ld bc,hl ;ex hl,bc ; push hl pop bcHiányzik az ellenõrzés, hogy elférünk-e?
ld hl,0
ld de,8000h
ldir
ld a,255Az 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.
out (0b0h),a
mivel nem találtam utalást az exos mennyi és meik részét használja a 255-ös szegmensbölEz 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).
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Így van, ez az amit már megcsináltam a Spectrum átiratos betöltõmben már vagy 3 éve :-)
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/
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!