128 byte RAM, 76 ciklus, 90 nap – Gary Kitchen és David Crane az Atari 2600 határait feszegetve

Mai fejlesztői szemmel az Atari 2600 inkább tűnik programozói rejtvénynek, mint videojáték-konzolnak. Mindössze 128 byte RAM állt rendelkezésre, framebuffer és hagyományos grafikus chip pedig nem volt; a processzornak a televízió raszterével szoros szinkronban kellett dolgoznia.

Gary Kitchen és David Crane azonban nem egyszerűen megtanultak együtt élni ezekkel a korlátokkal. Olyan trükköket találtak ki, amelyekkel jóval többet hoztak ki a hardverből, mint amire azt eredetileg tervezték. Kitchen az Atari 2600-as Donkey Kong portján dolgozott, Crane pedig többek között a Pitfall! alkotója volt, és az Activision egyik alapítójaként az egész videojáték-ipar működésére hatással volt.

Évtizedekkel később ismét Atari 2600-ra fejlesztenek – és mint kiderül, a 6502-es assemblyt sem felejtették el.

---

Gary Kitchen – Donkey Kong 90 nap alatt

A videojátékok előtt egészen más területen dolgoztál. Hogyan jutottál el az Atari 2600-ig?

Hardver- és szoftvermérnöki háttérrel indultam, és pont akkor kerültem egy kis céghez, amikor a mikroprocesszorok az Apollo-programhoz hasonló csúcstechnológiai területekről kezdtek megjelenni a fogyasztói termékekben. Egy Parker Brothers számára készülő elektronikus játékon tanultam meg 4 bites mikroprocesszort programozni.

Fogalmam sem volt róla, milyen nehéz feladatra vállalkoztam. Talán éppen ezért sikerült. Ha előre tudtam volna, milyen bonyolult, lehet, hogy bele sem kezdtem volna.

Aztán megjelent az Atari, én pedig eldöntöttem, hogy erre a gépre akarok programozni.

Csakhogy akkoriban nem lehetett egyszerűen elővenni egy fejlesztői dokumentációt.

Nem volt internet, ahonnan letölthettél volna egy kézikönyvet. Az Atari dokumentációjához lényegében az Atari és az Activision emberei fértek hozzá. Én viszont mindenképpen meg akartam érteni a gépet, ezért vettem egy Atari 2600-at, szétszedtem, és elkezdtem visszafejteni.

Körülbelül hat hónapig tartott.

Ebben óriási szerencsém volt az Apple II-vel. Ez volt az egyik első saját számítógépem; körülbelül 1300 dollárt kapartam össze rá. Az Apple II-ben és az Atariban is 6502-es processzor dolgozott, így össze tudtam kötni a két gépet, ROM-okat olvastam ki, és vizsgáltam a hardver, valamint a tévéjel időzítésének működését.

Így tanultam meg Atari 2600-ra játékot írni.

Az első játékom a Space Jockey lett.

„Nem tudtam, hogy amit csinálok, az ennyire nehéz. Egyszerűen megcsináltam.”

Gary Kitchen

Miért volt ennyire nehéz platform az Atari 2600?

128 byte RAM volt benne. Nem kilobyte. Byte.

Szeretjük inkább bitben mondani, mert akkor nyolcszor többnek hangzik, de attól még csak 128 byte.

Nem volt framebuffer, nem volt bitmap, és nem létezett a mai értelemben vett grafikus alrendszer sem. Egy modernebb gépen a képet előbb összeállítod a memóriában, majd a megjelenítést rábízod a grafikus hardverre. Az Atari 2600-on erre nem volt lehetőség.

A 6502-es kódnak szinkronban kellett futnia a televízió raszterével.

Egy képsor alatt 76 processzorciklus állt rendelkezésünkre. Ez nagyjából 15–20 utasítás. Ezalatt kellett beállítani mindent, amit azon a soron látni akartál.

Ha például túl későn frissítetted Mario grafikai adatait, a raszter addigra már elhaladt azon a ponton, így Mario egyszerűen nem jelent meg.

Ráadásul minden lehetséges kódágnak ugyanannyi ciklus alatt kellett lefutnia és visszatérnie, különben elvesztetted a szinkront. Mindig tudnod kellett, melyik scanline-nál és melyik pixelnél jársz.

Ez őrületnek hangzik, de akkor egyszerűen így dolgoztunk.

És erre a gépre kellett átültetned a Donkey Kongot. Mit szóltál, amikor megkaptad a feladatot?

Azt mondtam: persze, meg tudom csinálni.

Nem sokkal korábban játszottam a Donkey Kong arcade változatával. A feleségemmel együtt ámultunk rajta, szinte olyan volt, mint egy rajzfilm.

Aztán jött a telefon: ezt kellene Atari 2600-ra megcsinálni.

Kilencven napot kaptam.

Le kellett gyártani a ROM-chipeket, össze kellett állítani a cartridge-eket, majd a kész terméket el kellett juttatni a boltokba. Ha a játéknak ott kellett lennie a boltokban az 1982-es karácsonyi szezonra, május végére késznek kellett lennie.

Februárban hívtak fel.

Ma egy grafikus Photoshopban megrajzol valamit, és bekerül a játékba. Te mivel kezdtél?

Milliméterpapírral.

Nem voltak ilyen eszközök. Leültem a papír elé, és négyzetről négyzetre megrajzoltam, hogyan nézzen ki a képernyő.

Jumpmant – akkor még így hívták, nem Mariónak – ugyanígy rajzoltam meg. Megrajzoltam, aztán a grafikát bináris adattá, majd hexadecimális formává alakítottam, mert végül ebben a formában kellett az adatokat a 6502-es kódba beírni.

Ezután minden grafikai sorhoz színt rendeltem.

A normál Atari objektumok egyszínűek voltak, én viszont azt akartam, hogy jobban nézzenek ki. Ez azt jelentette, hogy nemcsak a grafikai információt kellett eltárolnom, hanem a színinformációt is.

Több időt és több ROM-helyet igényelt, de úgy döntöttem, valahogy megoldom.

A hordókhoz állítólag külön történet is kapcsolódik.

Mondták már, hogy úgy néznek ki, mint a Ritz kekszek.

Be kell vallanom: tényleg úgy rajzoltam meg őket.

De azok hordók.

Az eredeti Donkey Kong ferde platformjait viszont különösen nehéz lehetett visszaadni az Atari 2600-on.

Ez komoly probléma volt.

A playfield alapvetően úgy működött, hogy a képernyő jobb fele a bal oldal másolata vagy tükörképe volt. Ezzel a megoldással viszont nem lehetett rendesen ferde rámpákat rajzolni.

A fejlesztés körülbelül kétharmadánál még vízszintes platformjaim voltak.

Beszéltem az Activision egyik alelnökével, és megmutattam neki, min dolgozom. Tetszett neki, de távozáskor odaszúrt:

„Ha az Activisionnél dolgoznál, azok a rámpák ferdék lennének.”

Ezt egyértelmű kihívásnak vettem.

Elkezdtem azon gondolkodni, mi történne, ha a raszterrel szinkronban, még a képsor kirajzolása közben átírnám a playfield regisztereit.

Normál esetben beállítod a PF0, PF1 és PF2 értékeit, a képernyő másik felét pedig a hardver automatikusan kirajzolja. Én viszont még ugyanazon képsor kirajzolása közben újra átírtam a PF0, PF1 és PF2 regisztereket.

Lényegében a raszterrel szinkronban, menet közben módosítottam a megjelenítéshez használt regisztereket.

A hardver alapvetően ugyanazt a hátteret rajzolta volna ki a képernyő mindkét felén, de a regiszterek menet közbeni átírásával a bal és a jobb oldal eltérhetett egymástól.

És működött.

A képernyőn viszont jóval több figura látszott annál, mint amennyi sprite-ot a gép támogatott.

Az Atari ugyanazt a hardveres sprite-objektumot a képernyő különböző magasságaiban újra fel tudta használni.

Ha két karakter nem ugyanazon a scanline-on jelent meg, ugyanaz az objektum rajzolhatta ki mindkettőt, csak a megfelelő pillanatban át kellett írni az adatait.

A képernyő tetején például ott volt a hatjegyű pontszám. A hardver ugyanannak az objektumnak több példányát is ki tudta rajzolni, és ha a másolatok között a megfelelő pillanatban átírtam a grafikai adatokat, hat különböző számjegyet jeleníthettem meg.

Ezt a trükköt egyébként nem én találtam ki, hanem David Crane.

Aztán ugyanazokat az objektumokat lejjebb újra fel lehetett használni. Donkey Kong, a lány és a hordók megjelenítése is erre a gondolkodásmódra épült.

A programnak persze folyamatosan nyilván kellett tartania, hogy az adott képernyősoron melyik hardveres objektumnak mit kell kirajzolnia.

Teljes őrület volt.

És amikor már azt hitted, minden erőforrást elhasználtál, még hiányzott a kalapács.

Erre csak a végén gondoltam.

Megnéztem a játékot, és rájöttem: a fenébe, a kalapácsot is bele kell raknom.

Csakhogy elfogyott mindenem.

Elfogytak a ciklusok. Elértem a 76-ot. Nem volt több objektumom sem, mert ugyanazon a scanline-on ott lehetett Jumpman és egy hordó is.

Végül egy „ball” és egy „missile” objektumból raktam össze a kalapácsot. Emiatt a kalapács színeit más képernyőelemek már használt színbeállításaihoz kellett igazítanom.

Valahogy sikerült a két további regiszterírást is bepréselnem a képsoronként rendelkezésre álló 76 ciklusba.

Őszintén szólva, ha nem nézem meg a forráskódot, ma már fogalmam sincs, hogyan csináltam.

A 90 napos határidőből ekkor már nagyjából a 87. napnál járhattam.

Ez már egyszerűen kétségbeesés volt.

De bekerült.

---

David Crane – egy egész világ 31 byte-ból

Te hogyan kerültél az Atarihoz?

Alan Millerrel rendszeresen párosoztunk teniszben, ő pedig már az Atarinál dolgozott.

Egyik este játék után elővett egy papírt, és megkért, hogy nézzem át az álláshirdetést, amelyet a San Jose Mercury Newsban akart feladni. Játékfejlesztőket kerestek.

Elolvastam, és arra gondoltam: ez egész szórakoztató munkának tűnik.

Visszamentem a National Semiconductorhoz, az egyik általam épített számítógépen megírtam az önéletrajzomat, másnap reggel tízkor bevittem az Atarihoz.

Délután kettőkor állásajánlatot kaptam.

Kevesebb mint 24 óra alatt elektronikai mérnökből főállású szoftverfejlesztő lettem.

Volt bennem némi bizonytalanság ezzel kapcsolatban.

Aztán rájöttem: játékot készíteni jobb, mint egyszerűen programozni.

Később négyen elhagytátok az Atarit, és létrehoztátok az Activisiont. Mi volt az alapgondolat?

Úgy gondoltuk, hogy a játék készítőjének a neve is jelenjen meg a terméken.

Az Activision volt az első olyan vállalat, amely a játéktervezők nevét ugyanúgy feltüntette, ahogy a könyveken a szerzőét.

Ezzel gyakorlatilag megteremtettük a független, úgynevezett third-party játékkiadás modelljét is.

Addig az Atari az Atarihoz készített játékokat, a Mattel pedig a saját rendszeréhez. Az Activision viszont arra a platformra készíthetett játékot, amelyre akart.

Egyszer egy játékfejlesztői konferencián megkérdeztem a körülbelül hatszáz fős közönséget, hányan dolgoznak third-party kiadónál.

Szinte mindenki feltette a kezét.

Ma már alapvetően így működik az iparág.

Az Atari a saját sikeres arcade játékaira támaszkodhatott, az Activisionnek viszont nem volt ilyen katalógusa.

Pontosan.

Amikor az Atari 2600 készült, az Atarinak rengeteg sikeres arcade játéka volt. A gondolat egyszerű volt: készítünk programozható otthoni konzolt, és az arcade slágereket bevisszük az emberek otthonába.

Amikor létrehoztuk az Activisiont, nekünk nem voltak arcade sikereink.

Minden játékötletet nekünk kellett kitalálnunk.

Ez egy kicsit nehezebb feladat.

Leülsz, és azt mondod: rendben, játékot akarok készíteni. De mit csináljon?

Ráadásul egy elképesztően korlátozott gépen.

Így született a Pitfall!?

A Pitfall oldalnézetes játék lett, amelyben ha kifutsz az egyik képernyő jobb szélén, a következő képernyő bal oldalán jelensz meg.

Így a világ képernyőről képernyőre, vízszintesen tárult fel a játékos előtt.

És ennek az volt a szépsége, hogy nem tudtad, mi következik.

El tudtad képzelni, hogy kijutsz a dzsungelből, beérsz egy városba, onnan egy kikötőbe, felszállsz egy hajóra és átkelsz az óceánon.

Persze ehhez nem volt elég ROM.

De elképzelhetted.

A valódi probléma tehát az volt, hogyan lehet elég nagy világot tárolni 4K-ban.

Tegyük fel, hogy 255 képernyőt akarok. Binárisan ez különösen kézenfekvő szám.

Ha egyetlen képernyő leírására csak 30–35 byte-ot használok, máris elfogy a teljes 4K ROM, és akkor még egyetlen byte sem marad grafikára, programkódra vagy hangeffektekre.

Valami teljesen más megoldást kellett találnom.

Így lett a Pitfall világa procedurálisan generált.

Egyetlen byte RAM definiálta a világot.

Ez volt az LFSR?

Igen. Egy maximális hosszúságú LFSR-t, vagyis linear feedback shift registert használtam.

A regiszter minden lépésben új bitet generált, így egy reprodukálható számsorozat jött létre.

A nyolcbites érték alsó három bitje választotta ki a nyolcféle alapvető útvonal egyikét. A következő három bit határozta meg a további elemeket: például azt, hogy legyen-e mocsár, víz vagy aligátor.

Az utolsó két bit a fák mintázatát módosította.

Ez apróságnak tűnik, de fontos volt. Amikor átmész a következő képernyőre, a fák egy kicsit megváltoznak, és ettől azt érzed, hogy valóban eljutottál egy új helyre.

A képernyők adatait tehát nem kellett egyenként eltárolni.

A játék menet közben, az aktuális nyolcbites értékből generálta az éppen látható képernyőt.

„Egyetlen byte definiálta a világot.”

David Crane

Ez remekül működik, amíg a játékos csak egy irányba halad. De mi történik, ha megfordul?

Pont ez volt a probléma.

Ha kifutsz a képernyő jobb oldalán, generálok egy új értéket, abból pedig létrejön a következő képernyő.

De ha rögtön megfordulsz, ugyanazt a képernyőt kell visszakapnod, ahonnan érkeztél.

És nincs memóriám arra, hogy eltároljam.

Ezért olyan maximális hosszúságú LFSR-re volt szükségem, amely előre és visszafelé is működik.

Ha például C4-ből 89 lesz, akkor visszafelé haladva 89-ből újra C4-nek kell lennie.

Ez volt az igazán őrült része.

Ma már arra sem emlékszem pontosan, hogyan csináltam. 1982 volt.

Mennyi kód kellett végül a teljes Pitfall-világ meghatározásához?

Harmincegy byte.

Ez a 31 byte önmagában nem rajzolja ki a világot – természetesen rengeteg kirajzoló kód és más rutin tartozik hozzá –, de ez határozza meg, hogy az egyes képernyők milyenek legyenek.

Így nem kellett az egész ROM-ot a világ leírására elhasználni.

---

„Olyan, mint biciklizni”

Évtizedekkel később ismét Atari 2600-ra készítetek játékokat. Nem kellett újratanulni a 6502-es assemblyt?

Nem igazán.

Több száz játék kiadásában vettünk részt, én személyesen körülbelül 25 különböző nyelven programoztam, de a 6502 annyira természetessé vált, hogy akár a bináris kódot is el tudom olvasni.

Olyan, mint a biciklizés.

Amikor azt mondtuk, hogy vágjunk bele újra, kiderült, hogy ugyanolyan könnyen írok 6502-es assemblyt, mint angol szöveget a billentyűzeten.

Viszont gyakorlatilag újra fel kellett építenünk mindazt a gyártási hátteret, amely egykor az Activisionnél is kellett: fröccsöntött műanyag alkatrészeket, kézikönyveket, dobozokat és áramköri lapokat kellett készítenünk.

És a modern grafikai eszközök nagy része sem segít.

Ma megrajzolsz valamit Photoshopban, megnyomsz egy gombot, és bekerül a játékba.

Itt ez továbbra sem így működik.

Legalább a ROM-mal már bőkezűbben lehet bánni.

A ma könnyen beszerezhető ROM-ok lehetővé teszik, hogy 128K-s ROM-mal dolgozzunk.

Ez harminckétszer akkora, mint a Pitfall! 4K-s ROM-ja.

És ha már ott van, használjuk is.

Olyan dolgokat is beleteszünk, amelyeket régen egyszerűen pazarlásnak tartottunk volna.

Most viszont van helyünk rá. Ha jól néz ki, miért ne?

Más szempontból ugyanaz a munka, mint régen.

A 128 byte RAM mellett még egy egyszerű szubrutin-hívás is luxusnak számított?

Igen.

A változókat a RAM aljától felfelé helyeztük el, a processzor stackje viszont ugyanennek a RAM-nak a tetejéről lefelé terjeszkedett.

Minden újabb szubrutin-szint tovább csökkentette a játéknak maradó RAM-ot.

Használtam szubrutinokat, de két szintnél mélyebbre nem mentem. Így tudtam, hogy a 128 byte tetején négy byte gyakorlatilag elveszett a stack számára.

Ráadásul nemcsak memóriát, hanem processzoridőt is fogyasztott.

Egy szubrutin-hívás körülbelül 12 többletciklust is jelentett.

Mi pedig minden egyes ciklust számoltunk.

Miért áldoznál 12 ciklust csak azért, hogy szebb legyen a program szerkezete?

A későbbi játékaid között mennyi kódot lehetett újrahasznosítani? Például a Pitfall és az A Boy and His Blob között?

Egyetlen azonos kódsor sincs bennük.

Nagyon ritkán használtam újra akár egyetlen sort is egyik játékból a másikban.

A kód annyira szorosan az adott hardverhez igazodott, hogy szinte lehetetlen volt általánosítani.

Az A Boy and His Blob koncepciójában persze van rokonság. A korabeli PC-s kalandjátékokhoz hasonló, eszközhasználatra épülő játékot akartam készíteni, de zavart, hogy meg kell szakítani a játékot egy menü kedvéért, valahányszor a kard helyett másik eszközt akarsz választani.

Ezért találtam ki az alakváltó blobot.

Ő lett a szerszámosládád.

Így a Pitfallhoz hasonló oldalnézetes kalandot össze tudtam kötni az eszközhasználattal anélkül, hogy az eszköz kiválasztásához meg kellett volna szakítani magát a játékot.

---

Amikor minden byte számított

Gary Kitchen és David Crane története jól mutatja, mennyire más gondolkodást követelt a korai konzolfejlesztés. Nem az volt a kérdés, hogy melyik engine-t vagy grafikai API-t válasszák, hanem az, hogyan lehet néhány byte-nyi helyet felszabadítani egy újabb változó számára, hogyan lehet két sprite-ból egy teljes jelenetet felépíteni, vagy miként lehet minden egyes képsort legfeljebb 76 processzorciklus alatt előkészíteni.

Kitchen a Donkey Kong fejlesztésekor a raszter futásával szinkronban írta át a playfield regisztereit, így olyan hátteret tudott megjeleníteni, amelyre a hardver alaphelyzetben nem volt képes. Crane pedig 31 byte-tal írta le a Pitfall 255 képernyős világát.

És több mint négy évtizeddel később megint ugyanarra a gépre írnak játékokat.

Csak most már 128K-s ROM mellett néha megengedhetik maguknak azt a luxust is, hogy elpazaroljanak néhány byte-ot.