Sinclair Spectrum Játék és Program 2.

Bevezetés

A "Sinclair Spectrum játék és program" c. könyv megjelenése után - a nagy érdeklődésre való tekintettel - vetődött fel az újabb kötet elkészítésének gondolata. Ennek tartalmát elsősorban a felhasználók igénye szerint állítottuk össze, követve persze az előző könyv szerkezetét.
A terjedelem viszont csökkent, elsősorban azért, mert úgy érezzük az olcsóbb, de tartalmas könyvek népszerűbbek a felhasználók körében, ugyanakkor igyekeztünk arra vigyázni, hogy az oldalszám csökkentése ne menjen a tartalom rovására, melynek törzsét a játékleírások mellett most is a felhasználói programok és egyéb rutinok alkotják.
Mikrolexikonunk azonban megváltozott! Elmaradtak az egyértelműen "szubjektív" osztályzatok, és nem volt célunk a legutolsó "salátáig" az összes olyan játékot felsorolni, amelyik kimaradt az előző lexikonból. Ebből a megfontoláshól a lexikon nagyobb részét azok a programok alkotják, amelyek zöme a könyv megjelenésével párhuzamosan terjed el a Spectrumosok táborában.
A "Mit játsszunk, hogy játsszunk?" c. fejezet összeállításánál természetesen előnyben részesítettük az 1986-os év legnépszerűbb játékait. Célunk most sem az volt, hogy leírjuk egy-egy játék folyamatát elejétől a végéig, hanem az, hogy lehetőséget biztosítsunk a játékban való nagyobb elmélyedésre. A leírások mélysége - úgy érezzük - ehhez éppen elegendő.
A Mega Basic a Beta Basic után az egyik legelterjedtebb Basic bővítő. A felhasználók igényén túlmenően mi is úgy éreztük, hogy ennek. a programnak az ismertetésére szükség van. A demo lista szemléletesen bemutatja a program néhány fontosabb alkalmazási lehetőségét.
A Spectrumon alkalmazott Compiler-ek ismertetése idáig kimaradt a megjelent szakirodalmakból. Ötödik fejezetünk egy összehasonlító ismertetőt közöl arról az 5 compiler-ről, melyek jelenleg a legelterjedtebbek a felhasználók körében.
A könyv utolsó fejezete azoknak szól, akik számára eddig megközelíthetetlen volt a LOAD/SAVE rutinokba történő beavatkozás. Megismerhetjük a "trükkös" betöltők titkait, és tippeket kapunk a turbósításra is.

• MINILEXIKON
• MIT JÁTSZUNK, HOGY JÁTSZUK: Ace, Alien Highway, Benny, Bomb Jack, Chicken Chase, Critical Mass, Green Beret, Helichopper, Jack the Nipper, Jonah Barrington's Squash, Locomotion, Mikie, Ping-Pong, Saboteur, Sai Combat, Streethawk, The Way of the Tiger, Turbo Esprit, 'V' the Game, Winter Games, Yie Ar Kung Fu
• MEGA BASIC V 4.0
• MI IS AZ A COMPILLER? (Blast toolkit, Blast Compiller, Full Compiller, Integer Compiller, Mcoder II. Compiller, Super C Compiller)
• GÉPI KÓDÚ FURCSASÁGOK A MAGNÓT KEZELŐ LOAD/SAVE RUTINOK KÖRÜL
• FÜGGELÉK (Assembler kezdőknek)

Műveletek a magnetofont kezelő LOAD / SAVE rutinokkal

A fejezet első részében a ROM-ban található LOAD/SAVE rutinok elhelyezkedését, működését, hívási lehetőségeit ismertetjük. A későbbi felhasználás céljából elsősorban a végrehajtó rutinra lesz szükségünk, így annak közöljük a teljes assembly listáját, az utasítás értelmező és vezérlő rutinok részletes ismertetésére nem térünk ki. Tesszük ezt azért, mert bármikor disassemblálható a ROM területről, másrészt a kommentált lista megtalálható a "ZX Spectrum ROM Programja" c. könyvben - Ipari Informatikai Központ 1985.
A fejezet második részében néhány programozástechnikai tanácsot adunk arra, hogyan lehet a LOAD/SAVE rutinokba "belepiszkálni", elérve a játékprogramokból is jól ismert "trükkös" keret-csíkozást, visszafelé töltést, stb.
A harmadik rész a turbósításhoz ad segítséget, lehetőséget nyújt bárki számára, hogy egyszerű módon turbo programot készítsen, és azt alkalmazni is tudja.
A fejezet végén néhány tanáccsal szolgálunk a LOAD/SAVE rutinok felhasználását illetően.

A ROM LOAD/SAVE rutin felépítése

A ROM-ban elhelyezett rutin az 1218-as (HEX 04C2) címtől tart egészen a 2547-es (HEX 09F3) címig, és három eltérő blokkra bontható:

• Az első blokk az 1218-1540 (HEX 04C2-0604) címek között helyezkedik el, és elvégzi az adatok kimentésének ill. betöltésének műveletét, vagyis ez a végrehajtó rész.
• A második blokk az 1541-2464 (HEX 0605-09A0) címek között található, és ez végzi el a LOAD/SAVE/VERIFY ill. MERGE szerkezetek szintaktikai vizsgálatát, valamint ennek megfelelően az adatok és regiszterek tartalmainak helyes beállítását.
• A harmadik blokk rövidebb az első kettőnél, ez a 2465-2547 (HEX 09A1-09F3) címek között van, és a magnetofonnal kapcsolatos üzeneteket tartalmazza.

Most tekintsük át az egyes blokkokat külön-külön.

1. blokk:
A végrehajtó szakasz önmagában is futtatható, de elsősorban csak adott címen és adott hosszon elhelyezkedő adatblokk fejléc nélküli kimentésére/betöltésére. A gyakorlatban ennek a rutinnak a hívását igen sokszor használják főként a játékprogramokban. Mielőtt a konkrét hívási lehetőségeket áttekintenénk, nézzük meg az első blokk részletes assembly listáját (erre még szükségünk lesz a későbbiekben is).

Mint ahogy az a rutinból is szemléletesen látható, az adatok magnetofonra mentéséhez az 1218-as (HEX 04C2) címen kell belépnünk, míg az adatok magnetofonról történő betöltésére az 1366 (HEX 0556) címen van lehetőség.
Az első blokk több különálló szubrutinból tevődik össze, néhány szubrutint (pl. SAVE/LOAD-RETURN) a SAVE és a LOAD művelet is használ. Az adatok elmentéséhez ill. betöltéséhez nem elegendő meghívni a megadott címet, előtte néhány regiszter tartalmát megfelelően be kell állítani.
Ezek sorban:

• 'A' regiszterbe: szinkron-byte;
  hosszú TONE (bevezető-jel) esetén pl. fejléc-blokk előtt értéke zérus;
  rövid TONE esetén pl. program vagy adatblokk előtt pedig 255;
  némely esetben ettől eltérő értéket is megadnak a gyártók a másolók megzavarására;
• IX regiszterpárba: mentés/töltés báziscíme; ahonnantól kezdjük a byte-okat kimenteni, ill. amelyik címtől kezdjük a betöltést.
• DE regiszterpárba: mentendő/töltendő adatblokk hossza.

Ezen kívül betöltés esetén az átviteli jelzőbitet 1-re kell átváltani egy megfelelő SCF utasítással.
Nézzünk egy mintapéldát:

Fejléc nélküli adatblokk formájában akarjuk kimenteni a képernyő-memória tartalmát. A mentő rutint (amely majd a ROM rutint is hívja) helyezzük el a 60000. címtől. A szinkron-byte értéke 255, a startcím (IX tartalma) 16384, a hossz (DE tartalma) pedig 6912. A mentő rutin tehát a következő formájú lesz:

Néhány byte-ról lévén szó, az adatok beolvasása BASIC utasítások segítségével egyszerűen elvégezhető:

10 FOR i=60000 T0 60012
20 READ a: POKE i,a: NEXT i
30 DATA 62,255,221,33,0,64,17,0,27,205,194,4,201

Adjuk ki RUN (ENTER), és a mentő rutin a memóriában van. Készítsünk egy tetszőleges színes grafikát a képernyőre, majd adjuk ki 'RANDOMIZE USR 60000', de még ne nyomjuk meg az ENTER-t! Előbb indítsuk el a magnetofont felvétel üzemmódban, és csak ezután ENTER, mert a kitöltés azonnal indul. Itt egy apró probléma felvetődhet, a kép kimentésekor az alsó két sor lemarad az utasítás kiadása miatt. Ez elkerülhető, ha teljes képernyős (24 soros) grafikánkat előbb eltesszük a memória hátrébb eső területére pl. az LDIR utasítás segítségével, és onnan mentjük ki. Az itt említett műveletre szemléletes példát találunk a "RUTINRÓL-RUTINRA" c. könyvben - LSI ATSz.1986. A képünk most már a magnetofonon található, fejléc nélkül. Behívásához meg kell írnunk a betöltő rutint, az egyszerűség kedvéért ez a mentő rutin után közvetlenül helyezkedjen el.
Formája a következő lesz:

Az előbbihez hasonló módon olvassuk be ezt a rutint is a memóriába, majd csévéljük vissza a kazettát és adjuk ki: RANDOMIZE USR 60013 (ENTER). Indítsuk el a magnetofont, s előzőleg kimentett képünk megjelenik a képernyőn.

2.blokk:
Ez a szintaktikai vizsgáló és vezérlő szakasz. Mind a négy szalag-kezelő utasítás esetén (LOAD/SAVE/VERIFY ill. MERGE) a belépés helye az 1541-es (HEX 0605) cím. A rutinba való belépés előtt az utasításnak megfelelően beállítódik a 23668-as (T-ADDR-lo) rendszerváltozó. Értéke:

• SAVE esetén: 224
• LOAD esetén: 225
• VERIFY esetén: 226
• MERGE esetén: 227

Ez a belépés után automatikusan kiolvasásra kerül, és meghatározza az utasítás jellegét. A 2. blokk a megfelelő ellenőrzések és beállítások után szubrutinként adja át a vezérlést a már előbb megismert 1. blokknak, és az adott művelet elvégződik.
A 2. blokk részletes assembly listáját nem közöljük, csak a fontosabb belépési címeket ismertetjük, megnevezés-decimális cím-hexadecimális cím formában.

3. blokk:
Ebben a blokkban tárolták el a magnetofon kezelésével kapcsolatos üzeneteket. (CR=kocsi vissza-soremelés) Az egyes üzenetek elhelyezkedését az előző felosztáshoz hasonlóan közöljük:

Az üzenettáblázat elején, és az egyes üzenetek után un. delimiter (elhatárolójel) lett elhelyezve.

Manipulációk a LOAD/SAVE rutinnal

Először is ahhoz, hogy a LOAD/SAVE rutinban bármit is megváltoztatnánk, azt ki kell menteni RAM területre. Célszerű a ROM rutint a memória végére átmenteni. Egyenlőre csak az 1.blokkra lesz szükségünk, de mivel a későbbiekben a turbo-manipulációkhoz kell majd a 2. és a 3. blokk is, így célszerű az új területen elhelyezkedő rutin kezdőcímét ezek figyelembevételével megválasztani. Válasszuk kezdőcímnek a 63962-t. Az 1. blokk áthelyezési rutinját pedig olvassuk be az 50000. címtől:

A beolvasáshoz egyszerűen készítsünk egy BASIC programot:

10 FOR i=50000 TO 50011
20 READ a: POKE i,a: NEXT i
30 DATA 33,194,4,17,218,249,1,67,1,237,176,201

Adjuk ki: RUN (ENTER), majd RANDOMIZE USR 50000 (ENTER) és az 1. blokk átíródik a 63962. címtől.

Az 1. blokk az új helyen egyenlőre még futásképtelen, az abszolút címhivatkozásokat át kell írnunk. Gépeljük be és futtassuk az 50. sortól a következőt:

50 POKE 63963,87: POKE 63964,250:
POKE 63998,240: POKE 63999,249:
POKE 64020,31: POKE 64021,250
60 POKE 64036,61: POKE 64037,250:
POKE 64064,44: POKE 64065,250:
POKE 64080,22: POKE 64081,250
70 POKE 64133,255: POKE 64134,250:
POKE 64148,251: POKE 64149,250:
POKE 64155,251: POKE 64156,250
80 POKE 64170,255: POKE 64171,250:
POKE 64180,255: POKE 64181,250:
POKE 64227,251: POKE 64228,250
90 POKE 64238,226: POKE 64239,250:
POKE 64252,255: POKE 64253,250

Adjuk ki: RUN 50 (ENTER)

Az 1. blokk az új helyen most már futtatható. Felvetődhet a kérdés, mi az oka annak, hogy teljesen logikátlanul hol relatív, hol abszolút ugrások lettek elhelyezve a rutinban, amikor mindegyik abszolút hivatkozás kiváltható lenne relatív címzéssel. Erre mi sem tudjuk a pontos választ, de az biztos hogy ezzel megnehezítik azoknak a dolgát, akik a ROM-ból bármit is ki akarnak másolni.
Egy fontos dolog! Ha még idáig nem történt meg, akkor még most feltétlenül adjuk ki: CLEAR 63000 (ENTER), mert a későbbiekben problémába ütközünk.
Ha megvolt a CLEAR a RAMTOP áthelyezéséhez, nyugodt szívvel adjunk egy NEW-t, az eddigi BASIC törléséhez. Első lépésként nézzük meg, hogyan lehetséges a jól ismert piros/világoskék ill. a kék/sárga BORDER csíkok színeinek megváltoztatása.

Ahhoz, hogy a csík-effektus változatlanul maradjon, csak a színek változzanak, a következőket tehetjük.
Feltétlenül helyezzünk el megint a memóriában egy segéd-mentő/töltő rutint, amely beállítja a kezdőcímet és a hosszt a már megismert módon. Az egyszerűség kedvéért helyezzük el ismét az előző fejezetpontban ismertetett rutinokat a 60000-60026. címek között a képernyőmemória mentésére ill. töltésére.
Természetesen most már két sort ki kell cserélnünk:

Ha ezek a rutinok is a memóriában vannak, próbáljuk ki őket:

RANDOMIZE USR 60000
problémamentesen a magnetofonra küldi az adatokat, ill.

RANDOMIZE USR 60013
segítségével ezek visszahívhatók.

Azt, hogy a keret-csíkozás ne a hagyományos színkombinációban, vagy érdekes hatásokkal jelenjen meg, csak a töltő rutinban érdemes kiváltani, hiszen általában egy kész program betöltését színesítik. Annak sok értelme nincs, hogy kész programunk saját magunk szórakoztatására úgy kerüljön kazettára, hogy közben a képernyő-keret a szivárvány színeiben tündököl.
A töltő rutinban (1366-1540 ; HEX 0556-0604) több helyen is eszközölhetünk változtatást.
Az eredeti rutinban az 1384-es címen, az áthelyezett kódban így a 64128-as címen található az a konstans, amelyik a bevezető TONE alaptónusát meghatározza (alapértéke = 2). Próbáljuk megváltoztatni ezt az értéket, és ismételjük meg a betöltést. Láthatjuk, hogy a csíkok színe megváltozik. Pl. 1 esetén a TONE kék/sárga lesz, 0 esetén pedig fekete/fehér.
A ROM rutin 1441-es, így az áthelyezett kód 64185-ös címén az alapérték 3. Próbáljuk meg ezt is megváltoztatni. A két cím együttes változtatása újabb kombinációkat eredményez.
Felvetődik a kérdés, de vajon hogyan lehet megvalósítani azt, amikor betöltés közben a keret egy színű, vagy szivárványosan tölt ?
Tekintsünk vissza ismét a ROM rutin assembly listájára. A BORDER szín végleges beállítása és megjelenítése az 1530-1538 címek között
történik. Az 1532. és 1533. címek közé kell beszúrnunk egy vagy több olyan utasítást, amely a BORDER-t megfelelően módosítja. Ehhez először is az 1. blokk végét az 1533. címtől arrébb kell tolnunk.

Ezt a vágást ennek megfelelően a RAM rutinban a 64276/64277 között kell elvégezni, és az attól jobbra levő byte-okat két byte-tal jobbra pakoljuk.
Ehhez gépeljük be a következőt:

100 POKE 64277,0: POKE 64278,0:
POKE 64279,230: POKE 64280,7:
POKE 64281,246: POKE 64282,8:
POKE 64283,211: POKE 64284,254:
POKE 64285,55: POKE 64286,201

Ezután RUN 100 (ENTER).
Próbáljunk ismét betölteni, egyenlőre semmi változást nem tapasztalunk. A 64277-64278-as címekre tetszés szerint beírhatjuk a megfelelő kódokat.
Csak néhány variációt közlünk, a további próbálgatást az olvasóra bízzuk.

Ezek után bizonyára többekben felvetődik a kérdés. Van-e lehetőség kikapcsolni software úton betöltéskor a belső hangszórót. A belső huzalozás révén erre software oldalról nincs lehetőség, de nem is lenne sok értelme lekapcsolni.
Bizonyára több játékban találkozott már a felhasználó olyan hatással, hogy a képernyő nem hagyományos módon töltődött be, hanem pl. alulról felfelé stb.
A legegyszerűbb variáció az, amikor un. visszafele töltést valósítunk meg, vagyis a memóriában nem a növekvő, hanem a csökkenő címek felé töltjük a programot. Ennek az egyik alapfeltétele, hogy azt már eleve ilyen formában kell kazettára is mentenünk.
Az eredeti ROM rutinban az 1323/24 címeken található INC IX utasítás a kimentéshez, ill. betöltéshez az 1474/75 címeken. Ezt mindkét helyen egy DEC IX utasítással kell helyettesítenünk, vagyis az áthelyezett blokkban a 64068. és a 64219-es címek tartalmát kell 35-ről 43-ra megváltoztatnunk.
Gépeljük be:

POKE 64068,43: POKE 64219,43

Nézzünk a visszafelé töltésre is mintapéldát, látványosan természetesen most is használjuk a képernyőmemóriát. Használjuk fel ismét a 60000. címtől elhelyezett mentő, és 60013. címtől elhelyezett töltő rutint. Most IX-be tehát nem a kezdő, hanem a végcímet kell megadnunk, a többi paraméter nem változik. A változás tehát:

Készítsünk ismét egy tetszőleges grafikát, és mentsük ki:

RANDOMIZE USR 60000

Csévéljük vissza a kazettát, és a RANDOMIZE USR 60013 (ENTER) utasítással töltsük vissza a képet. Láthatjuk, a töltés visszafelé indul meg, ezt még szivárványos kerettel is kombinálhatjuk, úgy mint a HIGHWAY ENCOUNTER c. játékban.
Tegyünk egy próbát is, töltsük be előző képünket, láthatjuk meglehetős zagyvaság jelenik meg a képernyőn. A visszafelé töltést előnyessen alkalmazzák nagyobb kódok töltésére, hogy a "kíváncsiak" a kód önmagában történő betöltésekor csak értelmetlen adathalmazt találjanak. Mielőtt a turbo-ra rátérünk, még egy kitérőt teszünk a betöltök egy speciális változatára.
Több programban (pl. ROMMEL'S REVENGE, MIKIE stb.) találkozunk a képernyő betöltés teljesen szabálytalan megoldásával. A CRYSTAL Software által ismert variáció, amikor a képernyőt képpontsoronként lefelé haladva tölti be a betöltő rutin. Ma a leggyakoribb forma, amikor a karakternek egymás után betöltődik az egymás alatti 8 byte-ja, majd ráhívódik az ATTR byte is, és következik az újabb karakter. Igen látványos, de időigényes manipuláció. Mindenekelőtt szét kell bontani a betöltő rutint ott, ahol az IX (aktuális báziscím) növelése (INC IX) történik. Ez a hely a ROM-ban az 1474-es cím, az áthelyezett kódban tehát 64218. Ezen a ponton meg kell oldani a mindenkori aktuális báziscím előállítását. A báziscímeket célszerű egy adattömb formájában külön eltenni a memóriában, olyan sorrendben, ahogyan majd a kiolvasás történik. Kiolvasáskor a mutató tovább lép a következő báziscímre. Az adattömb elkészítésére célszerű egy egyszerű BASIC programot írnunk. Természetesen a mentő rutint is ennek megfelelően kell módosítanunk, hiszen az adatokat is ilyen sorrendben kell a magnetofonra kiküldeni.

Több fokozatú TURBO készítése

A TURBO program közismert más géptípusra is. A jel-átviteli sebesség (BAUD RATE) megnövelését segíti elő. Ez előnyös a gazdaságos tárolás ill. töltési/mentési idők csökkentése szempontjából, de hátrányos is, mert a kazettás magnetofonnal bizonytalanabbá válik a hibátlan adatrögzítés.
A Spectrum alaphelyzetben 1500 baud (bd) jel-átviteli sebességgel dolgozik. A baud egy mértékegység, a másodpercenként átvitt bitek számát fejezi ki (bit/sec).
Egy turbo csak akkor hatékony, ha lehetővé teszi nem csak a gépi kód, hanem BASIC program ill. adat-és stringtömb gyorsítását is. Ehhez először is ki kell menteni a RAM-ba a 2. és 3. blokkot is. Eddigi rutinunk a RAM-ban a 64286-os címig tart, vagyis a 2. és 3. blokk áthelyezésének startcíme: 64287.
Az áthelyező mechanizmus a következő:

Olvassuk be a kódot, majd adjuk ki: RANDOMIZE USR 51000 (ENTER) és a 2. ill. 3. blokk is a RAM memóriába kerül.

Egyenlőre a 2. és 3. blokk is futásképtelen az új helyen, az abszolút címhivatkozásokat megfelelően át kell írni. Gépeljük be és futtassuk a következő sorokat:

200 POKE 64440,116: POKE 64441,252:
POKE 64633,138: POKE 64634,254:
POKE 64649,110: POKE 64650,250
210 POKE 64734,34: POKE 64735,253:
POKE 64739,208: POKE 64740,253:
POKE 64797,110: POKE 64798,250
220 POKE 64907,28: POKE 64908,253:
POKE 64974,28: POKE 64975,253:
POKE 64997,28: POKE 64998,253
230 POKE 65030,70: POKE 65031,254:
POKE 65090,70: POKE 65091,254:
POKE 65189,218: POKE 65190,249
240 POKE 65209,218: POKE 65210,249

ezután RUN 200 (ENTER).
Az új területen helyet foglaló rutint is a hagyományos Spectrum BASIC utasításokkal fogjuk kezelni, de ezt meg kell előznie egy USR hivatkozásnak, mert máskülönben a ROM-beli rutinokra adódna át a vezérlés.
Az utasítás szerkezete a következő lesz:

LET a=USR xxxx: aaaa "név" stb. (ENTER)

A kettőspont után a hagyományos töltési/mentési parancs szerkezeteket kell alkalmazni (aaaa = LOAD/SAVE/VERIFY/MERGE ). A belépés viszont nem ilyén egyszerű. Egy külön belépési rutint kell írnunk, melynek kezdőcíme az xxxx cím, és innen adjuk át a vezérlést a RAM-beli 2.blokk kezdetének, ami jelenleg a 64287. címen található.
A kiegészítő-belépési rutinnak meg kell oldania a mutatók megfelelő átállítását, és az utasítás típusának megfelelően a T-ADDR rendszerváltozó beállítását. A kiegészítő rutint az 1. blokk elé érdemes elhelyezni. Hossza 57 byte, vagyis xxxx=63905.

A kiegészítő rutin a következő:

Ha a kódot beolvastuk a memóriába, ki is próbálhatjuk a rendszer jelenlegi működését. Pl.:

LET a=USR 63905: SAVE "név"

egy tetszőleges és éppen a memóriában levő BASIC elmentéséhez, vagy pl.:

LET a=USR 63905: SAVE "név" CODE 0,1000

egy tetszőleges memóriaterület kimentéséhez.

A mentés és a töltés ebben a formájában semmiben nem különbözik a ROM-beli állapottól.
Most egy táblázatot közlünk, amely 24 különböző sebességi fokozatra adja meg a megváltoztatandó byte-ok értékeit.
Az egyes oszlopok a baud sebességekre vonatkoznak, a sorok pedig az adott címen beállítandó értéket határozzák meg. Itt zárójelben megjegyeztük a ROM rutinban megfelelő címet is, hogy az ismertetett assembly listában megkönnyítsük az eligazodást.

Az igaz, hogy a 4500 bd. érték 3-szoros, a 7500 pedig 5-szörös sebességgyorsulást eredményez, de ha kipróbáljuk ezeket az értékeket, azt fogjuk tapasztalni, hogy a magnetofon ill. a kazetta minőségétől függően max. csak 2400-2700 baud sebességre tudunk gyorsítani, és sajnos már ezeknél az értékeknél is igen nagy a hibázás lehetősége. A gyakorlat azt mutatja, hogy kisebb hordozható kazettás magnetofonnal még elfogadhatóan visszatölthető a 2000-2200 bd. gyorsítás, jobb minőségű deck + jó minőségű kazetta együttes eredménye "néha" elviszi a 2700 bd. értéket is.
Próbálkozhatunk szalagos magnetofonnal ill. video készülékkel is több kevesebb sikerrel, de nagy eredményeket ne várjunk! Akik úgy gondolják, hogy eddigi programjaik sebességét 1500 bd.-ról 2200-ra kívánják megnövelni igaz hogy nagy helymegtakarítást érnek el (több kazetta felszabadulhat), de jól fontoljuk meg, hogy megéri-e a fáradtságot, hiszen a legtöbb játék memóriabeli méreténél fogva meg sem engedi a turbo használatát, másrészt a megbízhatóság jelentősen romlik.

Egy utolsó javaslat a töltési idő ill. helyigény csökkentésére. Ha fejléccel mentünk ki valamit, a fejléc és a byte-ok között kb. 1 másodperc szünetet hagy a gép. Ezt az időtagot kivehetjük a RAM-beli rutinból:

POKE 65194,1: POKE 65195,0

Ekkor a késleltetés elmarad, és szinte folyamatosan menti ki a byte-okat a fejléccel együtt a rutin.

Néhány hasznos tanács

Gyakran problémába ütközhetünk, ha fejléces blokkokat használunk, és betöltött SCREEN$ file-unk épségét meg akarjuk őrizni. Természetesen azt mondhatjuk, ez kikerülhető, ha a képernyő felrajzolása után a többi blokkot fejléc nélkül hívjuk be.
Ennél viszont van egyszerűbb módszer is, nézzünk egy mintapéldát:

Programunk három részbál áll:
- BASIC betöltő
- SCREEN$ file
- gépi kódú rutin(ok)
A file-ok mind fejléccel rendelkeznek, képünk viszont a teljes képernyőt, vagyis mind a 24 sort kihasználja. Valamilyen módon meg kell akadályoznunk, hogy a harmadik file fejléc információja "belevágjon" a képernyőbe.
A BASIC betöltő legyen a következő:

10 CLEAR xxxx
20 LOAD""SCREEN$
30 POKE 23739,111
40 LDAD""CODE: POKE 23739,244
50 RANDOMIZE USR nnnn

A 30. sorban elhelyezett utasítás a megoldás kulcsa. A 23739/40 címek a CHANNEL INFORMATION (csatorna információk) területéhez tartoznak. Ez a két cím a mindenkori PRINT-OUT mutató. A PRINT-OUT rutin a 2548-as (HEX 09F4) címen kezdődik, vagyis alaphelyzetben a 23739/40 címek tartalma 244/9. Ha a 23739. cím tartalmát 111-re változtatjuk meg, a mutató a 2415-ös ROM címre mutat, ahol 201-es (RET) kód van, és az üzenet nem jelenik meg a képernyőn. Természetesen a mutatót adott helyen célszerű visszaállítani.

Hasonló módszerrel lehetséges a másoló-programokból is ismert auto-kimentés megoldása is. Több programrészt vagy adatblokkot úgy tudunk kimenteni, hogy az egyes blokkok között a gép nem vár billentyű megnyomásra. Igaz egy pillanatra megjelenik a képernyőn a "Start tape..." felirat, de azonnal törlődik is.
Nézzünk erre is egy mintapéldát. Mentsünk ki egymás után egy BASIC-et, egy SCREEN$ file-t és egy gépi kódú rutint egyfolytában, minden beavatkozás nélkül.

9000 SAVE "program" LINE nnnn
9010 POKE 23736,181
9020 SAVE "SCREEN$"SCREEN$
9030 POKE 23736,181
9040 SAVE "kód"CODE nnnn,mmmm

A 23736/37 címek is a csatorna-információk területének elemei. Alaphelyzetben tartalmuk: 168/16, azaz a két cím tartalma a 4264-es (HEX 10A8) KEY INPUT rutin mutatója. Ez a rutin vár egy billentyű megnyomására. Ha ezt átlépjük, vagyis a 4264. helyett a 4277. címen lépünk be a rutinba, akkor a várakozást kikerültük, és minden automatikusan onnan folytatódik tovább, mint amikor a várakozás után egy billentyűt megnyomunk. Kimentés után az alapérték (168) visszaíródik, vagyis minden file kimentése előtt újra és újra át kell írni a cím tartalmát, ha folyamatos mentést akarunk.

Ebben a fejezetben még nagyon sok mindent le lehetett volna írni a LOAD/SAVE rutinokkal megvalósítható trükkökről, reméljük az itt közölt információk lehetőséget adnak a felhasználó számára a témában való bővebb elmélyedéshez.

Vissza