Ezután jön a betöltõ megszerkesztése, ismét a már jól ismert betöltõmet használtam fel. A memória lefoglalás, ennek függvényében videócím kiszámítás, a rendszerhez való visszatérést biztosító HIBA eljárás a szokásos, "100% EXOS kompatibilis"
Amit most megemlítenék, hogy az elmúlt félórában tovább fejlesztettem memóriakezelést, így most már nemcsak, hogy EXOS 2.0 kompatibilis, hanem RAM bõvítés nélküli EP64-en is fut a program!
Gyakorlati értelme nincs sok, de szeretem a kihívásokat, a vajon hogyan lehetne megoldani problémákat
De hátha majd elõkerül a világból egy EP64 tulajdonos, és nagyon fog örülni, hogy végre egy játék ami az õ gépén is fut.
Gyakorlatilag a hivatalosan kiadott néhány játékon kívül nincs egyetlen program se ami menne EP64-en.
Egyik ok, a közvetlen szegmenscímek használata, ami megakadályozza azt is, hogy felbõvített EP64-en fussanak a programok (kivéve, ha F8-FB címeken is van bõvítés).
Másik ok, hogy nincs elég RAM egy 64K-s gépben ami elsõ hallásra elég furcsa, hiszen egy 48K-s program miért ne férne el egy 64K-s gépben?
Egy átlag Spectrum átírat 4 szegmenst használ: egy videó szegmens az alsó 16K Spectrum memóriának, amiben található a képernyõ memória is. Két másik szegmenst a felsõ 32K Spectrum memóriának, és kell még egy videó szegmens az LPT tábla számára.
Viszont egy 64K-s gépen csak 2 szabad szegmens van... a másik kettõ a nullás lap ill. a rendszerszegmens céljára van felhasználva.
Azt már eddig is tudta a betöltõm, hogy az LPT tábla akár lehet megosztott szegmensben is, tehát ha van elég hely benne, a rendszerszegmens elejére kerül az LPT tábla, így máris megspóroltunk egy szegmenst.
De még mindig kéne egy...
Egyszerû a megoldás: a nullás lapról tegyük át az EXOS cuccait, no meg a saját programunkat a rendszerszegmensbe, állítsuk be a rendszerszegmenst nullás lapnak, és máris miénk az eddigi nullás lap szegmens!
Gyakorlatban így mûködik ez a fejlesztett betöltõ:
-lefoglal egy videószegmenst, ami majd az 1-es lapra kerül mint alsó 16K Spectrum RAM, ha nem sikerül, akkor HIBA rutinon át kilépés
-lefoglal egy akármilyen szegmenst a 2-es lapra, ha nem sikerül, HIBA...
-megpróbál lefoglalni egy akármilyen szegmenst a 3. lapra, ha nem sikerül, akkor jön az EP64 probléma...
-megpróbál lefoglalni egy videószegmenst az LPT táblának, ez lehet megosztott is, ha van benne elég hely (EXOS felhasználói határ beállítással ellenõrizve)

Ha a 3. szegmens lefoglalásánál EP64 problémával találkozik, akkor a következõ történik:
-ellenõrzi, hogy ez a 3. szegmens megosztott, és van-e benne elég hely a nullás lap eleje+LPT tábla számára, ha nincs akkor HIBA...
-ha van elég hely, akkor jön a trükk: a nullás lap elsõ 800H bájtja (ebbe benne van az EXOS rutinja a lap elején, plusz a 100H-tól kezdõdõ programunk) át lesz másolva megosztott szegmens elejére, természetesen az felhasználói határ ennek megfelelõen lesz beállítva, hogy EXOS ne tudjon lefele terjeszkedéssel bajt okozni. Átmásolás után a rendszerszegmens BFFC címén átállítjuk a nullás lap számát. Az eredeti szám természetesen el lesz tárolva. Ezután a felszabadult nullás lap szegmens kerül a 3. lapon felhasználásra. Az új nulláslap szegmens száma kerül majd bejegyzésre az LPT szegmensnek is.
Az LPT készítõ rutin számára pedig bejegyezzük, hogy 800H-tól készítse majd a szegmensben az LPT-t.
Ennek megfelelõen módosult egy kicsit az LPT készítõ rutin is, hogy az elõre megadott címen kezdje készíteni az LPT szegmensben az LPT-t. Ez normál esetben nulla, ha EP64 módban fut a program akkor lesz 800H. Természetesen ezzel módosult egy kicsit az LPT cím kiadása is a NICK-nek, hiszen így a 8-11-es címbitekkel is kell foglalkozni.

A HIBA eljárás is bõvítve lett, ha lett eltárolva nulláslap szegmensszám, akkor kilépés elött helyreállítja azt, visszamásolva az elsõ 800H bájtot. Ily módon még EP64 módban futva is megõriztük a rendszer teljes épségét, töltési hiba, vagy meleg reset esetén szépen kilép az EP logóhoz a program!
Kisebb módosítások voltak az EXOS 2.0 kompatibilitáshoz (Amit már a CPC betöltõmben is megcsináltam), a kép alján lévõ státuszsor az EXOS-tól lesz átvéve, ill kilépéskor a rendszerszegmensbõl lesz kiolvasva a visszaállítandó EXOS LPT címe.

Neki EP64-e van?! Ide vele, adok érte két 128-at

Az EP64-es kitérõ után vissza a betöltõhöz.
Miután sikerült a szükséges memóriát megszerezni, elkészíti az LPT táblát (részletesen lásd az SpV cikkben), majd betölti az SCR fájlt, ami az SCOPY-s kicsomagolás után kapott BUMPY.3FF átnevezésével készült. A kép betöltése után átkonvertája az attribútum terület minden egyes bájtját EP formátumra. Egy bájt konvertálása a következõ módon történik: egy 256 elemû táblázatra rácímezve (H a cím felsõ 8 bitje, L a konvertálandó attributum) kiolvasható a Spectrumos attribútum bájt EP-s megfelelõje, amire le lesz cserélve az adott bájt.
Ez a táblázat az Emulátor új ROM-jának fejlesztésekor készült, ebben benne van az is, hogy az elvileg villogó kombinációk inverzek legyenek, legalább így különbözve a flash nélküli  azonos kombinációtól. Az Emulátor eredeti programja, meg sok átírat nem foglalkozik ezzel a problémával, így akad jó pár játék, ahol nem tudni, hol áll a menüben a kurzor, mert az eredetileg villogna... ezzel a módszerrel inverz lesz a kurzor, és így már használható lesz

Hogy a táblázatra címezni tudjunk, annak xx00H címen kell kezdõdni. Eredetileg úgy mûködött a betöltõm, hogy a programban lévõ táblázatot 1000H címre másolta induláskor, és itt volt használva. Most az EP64 kompatibilitás miatt helyspórolás okán lekerült 100H-ra. Így viszont induláskor hiányzik az elsõ három bájt, mivel ott a táblázatott átugró JP található, így ez a 3 bájt az elsõ konvertálás elött lesz kitöltve.

Miután a betöltõ kép attribútumai át lettek konvertálva, átkapcsolunk a Spectrumos LPT-re, ezután következik a PRG betöltése (ami eredetileg a BUMPY.5FF fájl volt). A sikeres betöltés után jön még egy nagyon fontos dolog
Mivel a letöltött TAP fájl mellett rögtön ott volt egy örökélet POKE is, így ezt is beletettem, hátha valaki élni akar ezzel a lehetõséggel
A kérdést a státuszsorba kiírva tesszük fel, majd az Y és N billentyûk figyelése következik végtelen ciklusban. Y válasz esetén elvégezzük a POKE-t, és ezután jöhet a program indítása.
(Melesleg ennek a kérdésnek az is a mellékhatása, hogy floppyról töltve is meg lehet nézni alaposan a betöltõ képet, nem tünik el egybõl. Ezért más programoknál ha nincs is ilyen kérdés, akkor is be szoktam rakni egy billentyûre várakozást.)

Gépeli a nyavalya... Van itt egy feltört Omnipage... Mondjuk az OCR korrektúrával el lehet bíbelõdni...  

A cikk felkerült 6. részéhez megjegyzés: itt az egyik randa sajtóhiba, az EP billentyû mátrixban a C és a V fel lett cserélve.

A program módosításához már készen állnak a betöltõben a kész rutinok, az elv hasonló az SpV-ben leírtakhoz. A fontos rutinok címeit én a nem használt RST rutin belépési pontokra teszem, így 3 bájtos CALL helyett elég egy bájtos RST utasítás a meghíváshoz, így mindenhova befér
Jelen esetben minket a PORTFE rutin érdekel elsõként, ezt szint a Spectrum Emulátor új ROM-jához fejlesztettem ki eredetileg. Ez nemcsak a FEH port olvasását tudja emulálni, hanem annak írását is, azaz a hang generálást, ill. a keretszín (konvertált tehát színhelyes beállítását is).
Paraméterként felhasználja az RST utasítás utáni bájtot is, 0DBH jelenti az IN A-t, 0D3H az OUT A-t, 0EDH az IN A,(C)-t, de szükség esetén más kombináciok is legyárthatók (IN B,(C), stb)
Beolvasásnál a megadott sor(okat) olvassa be, és adja vissza, teljesen Spectrumos módon. A szám billentyûknél be van keverve a dologba az Internal+ALT is, a Sinclar joystick illesztõt szimulálva. Az Emulátoros verzióban az External joy-ok is itt voltak bekeverve, az átírásos verzióban azokat a Kempston illesztõ szimulálására tartogatjuk, JOY névre hallgató rutinban.
Bumpy indulásakor a PORTFE az RST 28H-ra kerül a betöltõben, a JOY pedig az RST 8-ra.
Így csak annyit kell tenni, hogy B423H címen található IN A,(0FEH) utasítást kicseréljük:
B423 EF     RST 28H
B424 DB    DB 0DBH


A joystick olvasó IN A,(0DFH)-t pedig:
B42B CF     RST 08H
B42C 00     NOP

Ezekután már lehet is játszani, csak hang nincs még, és itt-ott színhibás a program

Az átírás utolsó fázisa pedig az attribútumok kijavítása... ez a legnehezebb, legidõigényesebb mûvelet.
Itt nincs semmilyen általános módszer, minden programban más és más módszert alkalmaznak. A felderítésre a SpV cikk 9. része ad útmutatást. A lényeg az, hogy az 5800H-5AFFH közti memória területekre irányúló mûveleteket kell figyelni.
Ahol fix érték beírását találjuk, ott kinézzük a konvertáló táblánkból (ami a betöltõ forrászszövegének elején található) a megfelelõ értéket, és kijavítjuk.
Ennél sokkal gyakoribb, az amikor egy regiszterben megkapott érték kerül beírásra, leggyakrabban egy LD (HL),A utasítás formájában. Itt a legegyszerübb kicserélni ezt az utasítást egy olyan rutin meghívására, ami már a konvertált értéket írja be. Erre szolgál a KONV nevezetû rutin a betöltõben, ami RST 10H-re kerül, tehát a megtalált ilyen LD (HL),A utasításokat RST 10H-ra kell cserélni.
Az adott programtól függõen persze más módszerek is elõfordulnak, a KONV alapján könnyen legyárthatóak. Pl. a BUMPY esetén elõfordul LD (HL),C variáció, ez KONV2 néven található meg a betöltõben, és az RST18H-ra kerül.
Szintén nagyon gyakori, még az LDIR, LDI (néha LDDR, LDD) alkalmazása, általában akkor amikor a játék valamely elõre elkészített grafikai eleme (falak, tárgyak,stb) kerül a képernyõ memóriába másolásra.
Bumpy esetén LDI fordul elõ, ez KONV4 néven kerül megvalósításra, ez az RST 20H-ra kerül. Ha a KONV4-ben a kipontosveszõzött JR utasítást visszatesszük, akkor LDIR-t kapunk, az INC HL, INC DE utasítások DEC-re cseréjével pedig az LDD, LDDR állítható elõ.
Konkrétan:
B471   LD A,07H
B473   LD HL,5800H
B476   LD DE,5801H
B479   LD BC,2FFH
B47C   LD (HL),A
B47D   LDIR

Könnyen felismerhetõ, hogy ez egy attribútum terület törlés, ráadássul 7-es értékkel, ami EP-n is 7-es, így ezzel nincs további dolgunk.

B4F8   LD HL,5800H
B4FB   LD B,18H
B4FD   PUSH BC
B4FE    LD (HL),06H
B500    INC HL
B501   PUSH HL
B502   POP DE
B503   INC DE
B504   LD (HL),A
B505   LD BC,1CH
B508   LDIR

Az LD (HL),06H szintén maradhat, viszont az LD (HL),A-t ki kell cserélni egy RST10H-ra

B6F1-en meg van egy LD DE,5803H és utána egy nagy rakás LDI, amit most lusta vagyok ide bemásolni ezeket mind RST 20H-ra kellett kicserélni.
F0D8-on pedig szintén egy attributum terület törlés megadott értékkel, itt az F0E4-en lévõ LD (HL),A-t kell RST 10H-ra cserélni.

E799   LD DE,5800H
E79C   ADD HL,DE
E79D   LD (HL),C

Ezt az LD (HL),C-t kell RST 18H-ra cserélni, E7A8-on ven még egy.

E2E4-en van még egy LD DE,5800H, ADD HL,DE címû rész, amihez végül E30E címen tartozik egy LD (HL),06H. 6-os attributum tehát lehet békén hagyni...