Spectrum Világ
ENTERPRISE melléklet
Halló! Itt az emulátor!
Ismét az emulátor-ról
Enterprise billentyűkódok
A képernyő szerkesztése
A Sprite kezelés elmélete
Az Enterprise file formátumai
POKE beviteli módszer
Programok
Halló! Itt az emulátor!
Emulátornak hívják azt az eszközt amely egy másik berendezés működését képes utánozni, annak ellenére, hogy felépítése teljesen különböző. A Spectrum emulátor egy olyan szerkezet, amely a Spectrumtól eltérő hardware és software környezetben képes futtatni Spectrum programokat. Az Enterprise esetében ez annyit jelent, hogy egy ún. emulátor kártya csatolásával, ennek tulajdonosa Spectrum programokat is tud futtatni a számítógépén. Minden emulátorral felmerül azonban egy lényeges kérdés: Mennyire tökéletes az utánzás?
Amikor az Enterprise-ok hazánkba érkeztek, beharangozták, hogy a Spectrum emulátor hamarosan kapható lesz (még árat is mondtak). Annál is inkább, mivel egy magyar szabadalomról van szó. Eltelt egy év, de sehol sem jelent meg ezzel kapcsolatos érdemleges információ, pedig egyesek még Münchenben is keresték a magyar fejlesztést. Érdekes módon mi rátaláltunk a nem is olyan távoli Zuglóban.
A rendelkezésünkre bocsátott Spectrum emulátor-t egy héten keresztül nyúztuk; az alábbiakban szeretnénk közre adni a szerzett tapasztalatokat. A Spectrum emulátor-túgy tervezték, hogy megjelenésében ne térjen el az angol tervezésű import perifériáktól, ezért ugyanúgy néz ki, mint az Enterprise EXDOS lemezvezérlő kártya. A mintegy 1000 betöltött programból 843 futott tökéletesen, a fent maradó programok három részre oszthatóak:
Ezen kívül a Spectrum emulátornak még egy "óriási" hiányossága, nem ismeri a FLASH-t. Eddig leírtuk azt, hogy a Spectrum emulátor mit nem tud, de az igazsághoz hozzá tartozik az is, hogy mennyivel tud többet a Spectrum-nál. Nos, lehetőség van a DAVE hangchip, a CENTRONICS printer-port, a soros port, a két joystick port, valamint az RGB video kimenet használatára.
Mi az igazán jó hírt a végére hagytuk! Annak ellenére, hogy a Spectrum emulátort eddig négyszer tervezték át az éppen kapható elektronikai alkatrészek, illetve a gyártók igényeinek megfelelően, a tavasz BNV-n már kapható lesz, és remélhetőleg hozzájárul ahhoz, hogy ugrásszerűen megnövekedjen a Spectrum felhasználók népes tábora.
A Spectrum örök és elpusztíthatatlan!
Ismét az emulátor-ról
A Sinclair ZX Spectrum számítógépről mindenkinek megvan a saját pozitív tapasztalata, ezért ezt nem kell különösebben részleteznünk. Az emulátor egy olyan eszköz, amely egy másik berendezés működését képes utánozni, annak ellenére, hogy felépítése teljesen más.
Az Enterprise gépre készült Spectrum emulátor majdnem "Spectrummá" változtatja a gépet. Ezúttal az emulátor folyamatos használata közben szerzett tapasztalatainkat szeretnénk megosztani Olvasóinkkal, hiszen az okos más kárán (is) tanul.
Az első problémák a csatlakoztatásnál jelentkeznek. A SYSTEM BUS BRIDGE-dzsel viszonylag könnyen tudjuk "összedugni", mert nemigen tud elcsúszni a kártyáról, vuiszont könnyen előfordulhat, hogy a BRIDGE és a gép közötti csatlakozással megszenvedünk. Biztos módszer nincs, de idővel majd belejövünk!
Nagyon vigyázzunk, mindig feszültségmentesítsük a gépet, mielőtt "dugunk", vagy "lehúzunk", mert ha ezt elmulasztjuk, mindent tönkretehetünk!
Ha esetleg nem sikerül a pontos csatlakoztatás, legfeljebb nem jelentkezik be az emulátor, vagy "se kép, se hang" játékot űz velünk a gép, de hibát nem okozunk.
Az emulátor BASIC-ben teljesen Spectrum kompatibilis, kivéve a FLASH utasítást, de ha egy programban ilyet talál, nem zavarja meg, hanem átugorja. Ez a játékoknál nem túl érdekes, de az kifejezetten kellemetlen, ha a szerkesztő sorban "elvész" a kurzor! Ha legalább inverz volna!
A funkció billentyűkre kirakott HELP funkció a kezdő emulátor-használóknak jelent nagy segítséget, hiszen nem kell mindig a leírás után kaparászni.
Gépi kódban a programok kb. 85-90 százaléka fut. A "kiakadás" oka lehet pl. "illegális" belépési cím használata, saját loader, vagy néha "spéci" hangeffektek. Ha az emulátor-nak nem tetszik valami, akkor vagy egy karakter méretű kis fehér négyzetet tesz ki a bal vagy jobb sarokba, vagy egyszerűen lefagy. Néhány program erről vagy nem tud, vagy dafke csak azért is fut, miközben vígan virít a négyzet valamelyik felső sarokban. Találkoztunk több olyan programmal is, amelyek nem jeleztek hibát, de a játék közben a harmadik-negyedik pálya után lefagytak. Az ilyen programok elsősorban a többrészes, ún. utántöltős játékok, de gyakran előfordul ilyen "lemerevedés" az egyrészes programok esetében is.
Sajnálatosan a régi (1983-84 kiadású) programok - amelyek jórészt BASIC-ben íródtak - esetenként egyáltalán nem működnek az emulátor kártyával.
Vannak olyan programok, melyeket ha MULTIFACE-szel előzetesen Spectrum-on "átrántjuk", "felélednek halottaikból", és kifogástalanul működnek, mert a MULTIFACE-szel történő lementéskor a "krakkolás" nyomai eltűnnek.
A Spectrum programok sajátossága, hogy a "jugoszláv illetőségű crackerek", a MULTIFACE tulajdonosok, valamint a rengeteg másolás és magánerőből történő feltörés hatására egy programból igen sokféle változat létezik. Könnyen előfordulhat, hogy sikerül egy működő verziót találnunk, valamely használhatatlannak vélt programból.
Találkoztunk egy érdekes jelenséggel is, melynek nem értjük az okát. Gyakran előfordul, hogy az alsó sor a "C" billentyűtől kezdődően "elhal". A dolog érdekessége, hogy időnként a felettük lévő billentyűk (pl. az "M"-nél a "K", az "N"-nél a "J", a "SPACE" helyett az "ENTER", stb.) kezdtek el jól, máskor pedig "tudathasadásosan" működni. Eme jelenséget nem egy emulátoron tapasztaltuk, tehát az kizárható, hogy a mi példányunkban, vagy a gépünkben volna a hiba! Megint csak érdekes, hogy ez csak a gépi-kódú programok futtatásakor jött elő!
Vonjuk le a tanulságot: ha valamelyik billentyűnk nem akar működni, akkor próbálkozzunk a környező billentyűkkel, esetleg a SHIFT billentyűkkel együtt nyomjuk meg őket. Ha a makacs kis programunk még ennek ellenére sem áll kötélnek, úgy ajánljuk a "KOPEXY SYSTEM" által bevezetett módszert, nevezetesen, hogy a tenyerünkkel óvatosan az elérhető billentyűkre nehezedünk, vagyis több billentyűt nyomunk le egyszerre. Sok programot sikerült már ilyen módszerrel elindítani. Az ok az, hogy az indításhoz valóban több billentyű együttes lenyomása szükséges! Az itt ismertetett trükkök ellenére mégis elég sok programtól estünk el, pl. FIGHTER PILOT, MERCENARY.
A programoknak van egy része, melyek a használhatatlanságig lelassulnak, pl. a WHAM! THE MUSICBOX. Némelyik software éppenséggel gyorsul, ami nem volna baj, ha sak a játék sebessége változna, ám nagyon zavaró lehet, ha az irányítás beállításánál nem csak az aktuális irány, hanem az összes opció egy billentyűre definiálódik a felgyorsult billentyűzet-lekérdezés miatt. Ha már végképp nem tudunk olyan rövid ideig lenyomni (pöccinteni) egy billentyűt, hogy csak egy helyre történjen a definiálás, akkor - ha erre lehetőség van a menüben - válasszuk ki valamelyik billentyűvel párhuzamos botkormány-illesztőt. Ilyenek lehetnek:
| CURSOR | 5, 6, 7, 8, a tűz gomb sokféle lehet, pl. SHIFT, SPACE, 0, 9, M, stb |
| AGF / PROTEK | Az előzőhöz hasonló, de az irányok más kombinációban lettek összeállítva. |
| SINCLAIR 1 | 1, 2, 3, 4, tűz: 5 |
| SINCLAIR 2 | 6, 7, 8, 9, tűz: 0 |
| INTERFACE II. | ld. SINCLAIR 2 |
Az egyéb Interface-ek (pl. KEMPSTON) nem billentyűzet párhuzamosak, ezért ne válasszuk ezeket, mert a kiválasztást követően a klaviatúra nem él, és nincs lehetőségünk módosítani.
Sajnos az emulátor használatával elesünk mind a belső, mind a külső botkormányok, valamint a tényleg jól használható EXDOS-kártya használatától is. Értesüléseink szerint kifejlesztés alatt áll egy KEMPSTON típusú botkormány illesztő, az emulátort használók számára, de amíg megjelenik - ha nem kósza híresztelés - addig is a nem tú strapabíró billentyűzetet kell "gyötörnünk". Nagy kár, hogy az EXDOS-t nem használhatjuk, pedig milyen klassz is volna, ha a Spectrum programokat lemezről is töltögethetnénk!
|
|
A képernyő szerkesztése
A 8 bites számítógépek körében az Enterprise rendelkezik a legkifinomultabb, legösszetettebb képernyőkezeléssel. Milyen a felbontása, és a képernyőmérete? Nos, ebben a tekintetben szinte korlátllanok a lehetőségei. Vízszintesen és függőlegesen a kép méreteit csak a TV fizikai képernyőjének a széle korlátozza. A maximáis felbontás horizontálisan 928 képpont, vertikálisan pedig 625; ez utóbbit csak 'interlace' grafikával lehet elérni.
A különböző színüzemmódokban az egy soron belül előforduló színek száma maximálisan 256 lehet. Lehetőség van arra is, hogy a legnagyobb elérhető felbontás mellett az összes szín egyszerre szerepelje a képernyőn.
A képernyő szerkesztését a NICK chip végzi, amely nevét alkotójáról Nick Troop-ról kapta. A chip a 80h-tól 83h-ig terjedő port-okat használja.
Az első port a 80h.
Ennek a feladata elsődlegesen a FIX-BIAS beállítása. Erre 5 bit áll rendelkezésre, amiből következik, hogy a maximálisan kikeverhető színkombinációk száma 32. A FIXBIAS-t BASIC-ből is állíthatjuk a
SET BIAS n
Utasítással, ez annyiban különbözik a 80h-s port közvetlen címzésétől, hogy a BASIC az 'n' értékét 8-al szorozza.
A FIXBIAS funkciója csak a 16 színt használó színmódok esetében érvényesül. Ilyen esetekben a 16 szín a paletta 8 byte-jából, valamint a BIAS által meghatározott 8 színből áll. A 80h-s port másik két funkciója közül a külső video-bemenet vezérlését az 5-ös és 6-os bit látja el, a 7-es bit pedig a belső hangszórót kapcsolja ki / be.
A második videochip-port a 81h.
Ennek a feladata a képernyő keretének színezése. Mivel a teljes byte-ot, tehát mind a 8 bitet erre a célra használja, ezért a keret színe 256 féle lehet.
A harmadik és negyedik port összetartozik.
Eze ketten határozzák meg, hogy hol helyezkedjen el a tárban a LINE PARAMETER TABLE (LPT). Tudni kell azonban, hogy a NICK chip által kezelt címek a saját video-memóriájára vonatkoznak (0000h = FCh, 4000h = FDh, 8000h = FEh, C000h = FFh), függetlenül attól, hogy a Z80 ezeket a szegmenseket hol látja.
Az LPT kezdőcímeinek átszámítása olyan formára, hogy azt közvetlenül ki lehessen küldeni a 82h, 83h-s portokara, úgy történik, hogy a kezdőcímet el kell osztani 4096-tal. Ennek kell venni az egészrészét, majd a 6-os és 7-es bitjét 1-be kell állítani, végül pedig kiküldhető a 83h-s portra. A másik byte-ot úgy kell kiszámítani, hogy a kezdőcím 4096-tal osztott értékének törtrészét be kell szorozni 256-tal. Ezt már ki lehet küldeni 82h-ra. Ezzel az LPT helyét behatárolta, nincs más hátra , mint felépíteni...
Folytatva az előző eszmefuttatást a képernyő szerkesztéséről, célunk az, hogy közelebbi ismereteket nyújtsunk erről a területről, amiről a mai napig nagyon kevés információ látott napvilágot.
Egy LPT tetszőleges számú LPB-ből állhat. Az LPB-k határozzák meg a kép sorainak tulajdonságait, és 16 byte-ból állnak. Most a 16 byte szerkezetét tekintjük át:
2. byte: Un. MODEBYTE, amely megadja, hogy az adott sor milyen üzemmódban legyen.
Az LPB-k után helyezkednek el a szinkronbyte-ok. Ezek is tizenhatossával következnek egymás után, de itt csak az első byte tartalmaz hasznos információt.
A szinkron kiszámításához tudni kell, hogy a TV a képet 625 sorból építi fel (legalábbis hazánkban). Ez két félképből áll, tehát a szinkronizációt 312,5 sorra kell elvégezni. Az INTERLACE kép készítésénél azt kell elérni, hogy a két félképre különböző információ kerüljön. A 312,5 sornál a félsor szinkronizálásának módja bonyolult. Ennek magyarázatába nem bocsátkoznék, a többi sor kiszámítása úgy történik, hogy össze kell adni az LPB-okban definiált rasztersorok számát, hozzá kell adni 25-öt, majd ezt az eredményt ki kell vonni 312-ből, osztani kell kettővel, és a legvégén ki kell vonni 0100h-ból. A kapott értéket be kell helyettesíteni az 'X' helyére, és már el is készült az LPT!
X, 146, 63, 0, DEFS 12
253, 16, 63, 0, DEFS 12
254, 16, 6, 63, DEFS 12
255, 16, 63, 28, DEFS 12
237, 18, 6, 63, DEFS 12
X, 19, 63, 0, DEFS 12
A Sprite kezelés elmélete
Az utóbbi időkben több levelet kaptunk, melyben azt kérik tőlünk, hogy szóljunk néhány szót az Enterprise-on megvalósítható sprite kezelés lehetőségeiről. A sprite kezelés ismertetésének két véglete van, rövid tájékoztató, és mélyreható okfejtés részletes gépi kódú mintaprogramokkal. Az utóbbi egyenlőre helyszűke miatt nem fér bele a mellékletbe, de a témára természetesen még vissza fogunk térni. Így hát most következzék az elmélet:
A sprite kezelés az akciójátékok legfontosabb alkotóeleme. Ha bármely számítógépen alakokat akarunk mozgatni a képernyőn, meg kell írnunk a sprite-kezelő rutint. Ez alól csak azok a gépek kivételek, amelyeken a manó-manipulációt a video-chip végzi, hardware úton (pl. C64, MSX, ATARI XL).
A sprite kezelésnek is megvan a maga történelme. Az idő múlásával, ahogy a programozók fejlődtek, egyre újabb módszereket találtak ki a sprite-ok mozgatására.
Az első legklasszikusabb példa az, amikor az ablakot kitesszük a képernyőre, majd várunk, műveleteket végzünk, s amikor már minden kész, letöröljük a képernyőt. BASIC-ben ez elég elterjedt megoldás, ennek megfelelően lassú, nehézkes és rendkívül villog.
A második verzió működési elve az, hogy a sprite szélein egy egységnyi széles, üres területet hagyunk. Ha ezt úgy tesszük rá az előző fázisra, hogy az elhelyezkedése csak egy egységnyivel térjen el az előzőtől, akkor a régi fázis kilógó része az üres keret darabja lesz. Ennek a módszernek az a legnagyobb hátránya, hogy a sprite-ot csak kis egységekben lehet mozgatni.
A következő lehetőség, amikor az ábrát úgy másoljuk a képernyőre, hogy össze XOR-oljuk vele. A levétele roppant egyszerű, mindössze meg kell ismételni az előző műveletet. Egyébként ez az első olyan módszer, amikor a sprite-kezelés két fázisban történik: kirakás, letörlés. Használata egyszerű, de az eredmény nem mindig esztétikus.
A legszebb módszer az un. maszkolós sprite-kezelés. Két új dolgot is tartalmaz. Az egyik a maszk, a másik a sprite-puffer. Egy sprite maszkolása úgy történik, hogy a sprite körvonalán belül eső résznek megfelelő biteket kioltjuk, a külső rész bitjeit kigyújtjuk. Ez a rajzolóprogramok FILL utasításával könnyen végre lehet hajtani.
A sprite kezelés a következőképpen zajlik: a régi képernyőcímre vissza kell másolni a sprite-puffer tartalmát. Ez tulajdonképpen a törlés. Az új képernyőcímre át kell másolni a képernyő tartalmát. Ez a tárolás. Ki kell venni a képernyő egy byte-ját, össze kell AND-elni a maszk megfelelő byte-jával, majd 'bele' kell OR-olni a sprite adatot. Ezt azután vissza kell tenni a képernyőre. Ez a kirakás.
Mint látható ez a folyamat három részből áll, emiatt lassabb is, mint az eddigiek. Azonban ha valaki jól tud programozni, egyetlen ciklusban végrehajthatja mind a hármat, s ez jelentős időmegtakarítást jelent. Hátránya azonban az, hogy a sprite-ok nem mehetnek egymásra. Ha viszont ellentétes sorrendben tároljuk le őket, mint ahogy kitesszük, akkor ez a probléma is megoldódik. Ekkor viszont túl sok lesz az idő, amíg sprite nincs a képen. Minél nagyobb ez az időtartam, annál jobban fog a sprite villogni.
Ezt meg lehet próbálni úgy kiküszöbölni, hogy a sprite kezelést kiszinkronizáljuk. Ez vagy úgy történik, hogy kiadunk egy HALT utasítást, vagy úgy, hogy a sprite kezelést az interrupt rutinban helyezzük el. Mindkét esetben az elektronsugár a képernyő tetején van, ill. az Enterprise gépben abban a rasztersorban, ahol video interrupt-ot kértünk. Ekkor , ha szerencsénk van, vagy kevés sprite-ot kellően gyors rutinnal kezelünk, a villogás elmarad. Ha nincs szerencsénk, akkor megeshet, hogy a sprite egy darabja, vagy akár az egész, úgy ahogy van, eltűnik. Ez akkor következik be, amikor az elektronsugár akkor ér oda a sprite-hoz, mikor éppen törlés stádiumban van, tehát nincs ott semmi, csak a háttér. Ez az oka egyébként az összes sprite-kezelés villogásának is.
A villogás kiküszöbölésére kitaláltak egy módszert, melynek lényege a háttérképernyő. Ez lehet akkora, mint a rendes kép, kisebb vagy akár nagyobb is, mindig a célnak megfelelő. Ezen kell megszerkeszteni a képet, majd a kellő nagyságú darabot, vagy akár az egészet is nagy sebességgel átmásolni az eredeti képernyőre. Ha mindez video interrupt-hoz szinkronizálva történik, akkor végre elmarad a villogás. Hátránya azért ennek is van: a program futásából sok időt vesz el a háttérkép előremásolása. Az Enterprise gépen ezt a hibát könnyen ki lehet küszöbölni, Készíteni kell két ugyanolyan képernyőt, de a kezdőcímüket különböző memóriacímekre kell tenni. A kettőből természetesen egyszerre csak az egyik látszik. Amelyik láthatatlan, azon kell megszerkeszteni a képet, hasonlóan, mint a háttérképernyőnél. Ha a kép kész, átkapcsoljuk, hogy ez legyen aktív. Ezután folytatjuk a következő fázis rajzolását a másik képen, miközben ezen látszik az előző fázis. Ezzel megtakaríthatjuk azt az időt, amit a háttérképernyő rendes képre való másolásánál elvesztenénk...
Az Enterprise file formátumai
Az Enterprise a különböző típusú file-ok felismerésére -legyenek ezek lemezről, vagy kazettáról betöltve - 10h hosszú fejléceket használ, amelyek második byte-jának (típus-bye) tartalmától függően az EXOS azonnal tudja, hogy mi a teendője. Az alap KERNEL-ben definiált file-típusok a következőek:
00 - ASCII vagy adat-file
01 - fenntartva (jelenleg nem használt)
02 - USER relokálható modul
03 - BASIC programlánc
04 - BASIC program
05 - NAP file
06 - SYSTEM abszolút modul
07 - SYSTEM relokálható modul
08 - EDITOR dokumentum file (tokenizált)
09 - LISP program
10 - file vége
11-31 - fenntartva (jelenleg nem használt)
Vegyük sorra az öt leggyakrabban használt fejléc típust:
00 - Ez a fejléc típus azért szükséges, hogy az EXOS még véletlenül se tudjon adatállományokat futtatni.
03 - Ez a fejléc BASIC programláncok előtt található, mivel ezeket másképp kell a rendszernek betöltenie, mint egy normál BASIC programot.
04 - Ez a fejléc normál BASIC programok előtt található
05 - NAP file, ami annyit jelent, hogy a fejléc után következő programot a rendszer töltse be 100h-ra, majd adja át a vezérlést 100h-ra.
06 - Abszolút modul, amely az EXOS bővítését teszi lehetővé, de a modul hosszúságától függetlenül teljes szegmenst foglal le számára.
07 - Ugyanaz, mint a 06-os, azzal a különbséggel, hogy az EXOS relokálható formátumban több ilyen modult egy szegmensre elhelyezni.
10 - file vége fejléc, ebből tudja meg az EXOS, hogy a file végéhez ért.
A különböző típusú fejléceknél a típusbyte-ot követően az adott modulokra vonatkozó adatok találhatók. Most a BASIC file-ok sajátosságaira térünk ki. A típus byte-ot követően a file fejlécek nélküli hosszát találhatjuk két byte-ban kifejezve. A fejléc többi byte-ja 00. Számunkra még a hatodik byte lehet érdekes, mivel ha ennek értéke nem egyenlő zérussal, akkor a program betöltését követően automatikusan elindul. Programláncok esetén a 0-s program fog elindulni.
Sokszor szükség lenne BASIC programunk ASCII formátumban történő kimentésére, a SAVE parancs azonban tokenizálva menti ki a programot. A dráma leküzdésére az alábbi megoldást javasoljuk:
OPEN £106:"file_nev" ACCESS OUTPUT
LLIST £106
CLOSE £106
Az így kimentett programot már bármilyen szövegszerkesztőben editálhatjuk, sőt a BASIC-be vissza is tudjuk tölteni.
A játékprogramok megjelenése óta léteznek cracker-ek, ők azok, akik feltörik a játékokat. Tevékenységük három csoportra osztható:
A legártalmatlanabb krakkolás (örökéletesítés) sajnos a legtöbb esetben igen nehéz, mert ahhoz, hogy meg tudjuk keresni a programban az ehhez szükséges részeket, előbb ártalmatlanná kell tenni a játék másolása ellen elhelyezett bombákat. Ez a védelemtől és a programozóktól függően 1 óra és két hét közötti munkát jelenthet a krakkolóknak. Miután a védelmet lerobbantottuk, elkezdhetünk turkálni a kódban, megkereshetjük az életek levonásáért felelős rutint. Megjegyzendő továbbá az a tény is, hogy egy ilyen vállalkozás előtt nem árt tisztában lenni az ENTERPRISE felépítésével, valamint a BASIC programozási nyelvről le kell mondani, és a gépi kódot kell előnyben részesíteni. Határozottan érdemes felfegyverkezni különböző programokkal (monitor, debugger, tracer, stb.).
Jó hír az ENTERPRISE tulajdonosoknak, hogy a legtöbb, a gépükre készült program (döntő többsége SPECTRUM átirat), nem lett ellátva másolás elleni védelemmel! Ugyanakkor a POKE bevitele egy kicsit nehezebb, mint SPECTRUM-on, mert a programok nem BASIC betöltővel indulnak, hanem 5-ös fejlécű gépi kódú programmal, amiket nehezebb módosítani.
A POKE bevitelhez feltétlenül szükség van egy ASSEMBLER programra. A módszert az ASMON V1.5 assembler program felhasználásával fogjuk bemutatni. Először töltsük be a program LOADER-jét az 'R' billentyű megnyomásával. A Start kérdésre válaszoljunk 8000-rel, az End kérdésre írjunk BFFF-et.
Ezután listázzuk ki a LOADER-t az 'L' billentyű megnyomásával, a Start kérdésre válaszoljunk a kezdőcímmel, vagyis 8000-rel. Addig listázzuk a programot, amíg egy EXOS 1 utasítást fel nem fedezünk (ez általában sikerül). Ha ezt megtaláltuk, akkor utána az LD DE.xxxxh és az LD BC,xxxxh utasítás áll. Ezekben az utasításokban a programblokk kezdőcíme és hossza található: DE-ben a kezdőcím, BC-ben a hossz. Ha a programnak van screen-je, akkor DE-ben 4000h-nak, BC-ben 1B00h-nak kell lennie. Listázzuk tovább a programot a következő EXOS 1 utasításig. Az ezután lévő értékekben már a minket érdeklő programblokk kezdőcíme és hossza található.
Legyen például a kezdőcím 5B00h, a hossz pedig A500h. Most töltsük be a programblokkot 4000h-val alacsonyabb címre, vagyis 5B00h helyett 1B00h-ra. Erre ezért van szükség, mert az ASMON-ba csak BFFFh-ig tudunk file-okat tölteni. A betöltés után el kell helyeznünk a POKE-ot, de előbb ebből le kell vonnunk 4000h-t. A POKE legyen pl. a B4D0h címen, ebből levonva a 4000h-t megkapjuk a beírandó POKE címét. Nyomjuk meg az 'M' billentyűt, és a Start kérdésre válaszoljunk 44D0h-val. Most már nincs más hátra, mint az ezen a címen lévő adatot módosítani. Módosítás után mentsük ki a programot a kezdőcímtől a végcímig, az eredeti névvel. Ha a betöltés után még sincs a várva várt örökélet, vagy a program elszáll, akkor ennek vagy az az oka, hogy más verziócol lett átírva a program, vagy pedig a program átírója változtatta meg a program felépítését.
Most két program esetében konkrétan szemléltetjük a beviteli módszert:
AMAUROTE
Töltsük be a programnak a screen után lévő blokkját ASMON-ba a 27E8h címre, BFFFh-ig. Ezután a 65D8h címre helyezzünk el 00H-t. Most ki kell menteni a programot az eredeti címmel, 27E8h-1ól BFFFh-ig. A játék betöltése után nem emelkedik a DAMAGE műszer, ha hozzánk ér egy méh.BOBBY BEARING
Töltsük be a program screen után következő blokkját az ASMON-ba 1800h-1ól BFFFh-ig. Ezután írjunk a 33F8h címre AFh-t, majd mentsük ki a régi névvel 1B00h-tól BFFFh-ig. Betöltés után az energiánk fogyni fog, de zérust elérve nem ér véget a játék.
A következő Spectrum POKE-ok az itt ismertetett módszerrel működnek az EP verzión is:
| ENDURO RACER | POKE 43647,0: POKE 43648,0 | (örök idő) |
| THE GREAT ESCAPE | POKE 41953,183 | (vételen energia) |
| THE LAST NINJA 2 | POKE 36578,0 POKE 35993 0 POKE 36751,0 POKE 36514,0 POKE 36393,0 POKE 36822,0 |
(1. rész örökélet) (2. rész örökélet) (3. rész örökélet) (4. rész örökélet) (5. rész örökélet) (6. rész örökélet) |
| LEGEND OF THE AMAZON WOMAN | POKE 57960,0 | (örökélet) |
| MAGNETRON | POKE 42671,235: POKE 42672,160 | (örökélet) |
| NORTHSTAR | POKE 44433,0 | (nincsenek idegenek) |
| REVOLUTION | POKE 35652,182 | (örökélet) |
| RETURN OF THE JEDI | POKE 52140,0 | (örökélet) |
| SABRE WULF | POKE 43575,255 | (255 élet) |
| SPINDIZZY | POKE 48401,201 | (vételen energia) |
| SUPER HANG ON 1. | POKE 49913,0 | (örök idő) |
| UNDERWURLDE | POKE 59376,0: POKE 59377,0 POKE 38041,0: POKE 38042,0 POKE 59591,0 |
(örökélet) (egy tárgy felvétele után sérthetetlenség) (bárhol használhatunk fegyvert) |
| WAR | POKE 37033,0 | (örökélet) |
| HENGER.BAS | Animáció: henger forgatása |  |
| SZINUSZ.BAS | 3D szinuszoid | |
| BALLS.BAS | Ütköző labdák. Indítás RUN 10 paranccsal! | |
| PLANET.BAS | Bolygók keringése. | |
| TRIANGLE.BAS | Térbeli demo: egy 3D térben megjelenő háromszög idomot mozgatunk háttérképernyő-technikával | |
| 3D.BAS | Térbeli demo: az előző program továbbfejlesztése | |
| VEKTOR.BAS | 3 db térbeli nyíl forgatása | |
| SPIRAL.BAS | Spirál grafika: spirál grafikai hatást mutat be különböző méretű háromszögek szögben elforgatott felrajzolásával. | |
| MEGLEP.BAS | Meglepetés... |
POKE beviteli módszer