Még egy ötlet optimalizálásra, ami nem biztos, hogy jó: ha karakteres szervezésű a grafika, akkor lehet, hogy érdemes lenne valamilyen Spectrumhoz hasonló címzést használni, ahol karakteren belül a sorok közötti távolság 256 byte, például: bal felső sarok = D800h, utána soronként +0100h, majd túlcsordulásnál (40 sor, azaz 5 karakter után) D828h következik, újabb 40 sor, D850h, és így tovább. Karakteres felbontású attribútumok pedig elférhetnek a nem használt területeken, pl. D8D8h..D8FFh = első sor, D9D8h..D9FFh = második sor, stb. Így az animált karaktereknél az ADD HL, DE utasítások helyére egyszerű INC H kerülhet. A sprite megjelenítésnél viszont nehezebb az ilyen címzés, ezért nem biztos, hogy megérné.
A grafika karakter szervezésű volt teljes egészében, csak átalakítottam a sprite mozgást, hogy kevesebbet kelljen írni a képernyőre, így játék közben függőlegesen 4 pixeles mozgás van, és 4 sorral kisebb lett a sprite, és a játék legvégén meg pixeles mozgás van felfelé, ilyesmire gondoltam én is, egyszerűbb kivitelben 00h- n kezdődnek a páratlan sorok, és 80h-n a páratlanok, ez viszont marha sok memória, és a sprite rajzolás se lett volna gyorsabb.
Jelenleg 8x1-es attributumokat használok, a szebb függőleges mozgás érdekében, és a villogáshoz is csak a sprite tartózkodási helyének megfelelő LPB-ket módosítom (20 sor)
Az animált karaktereknél még külön lehetne kezelni azt az esetet, amikor sok található egymás mellett vízszintesen, ilyenkor ugyanazt a pixel byte-ot kell kiírni növekvő címekre.
Ez is jó ötlet, ha már az első, és utolsó sor így van kirajzolva, sokat gyorsít sztem, és lehet csak 4 ellen esetén lassulna be az EP64 verzió.
A space nekem nem működik, csak az enter. 
Ha az irány is le van nyomva, akkor nem működik, legalábbis én csak a space-t használtam tesztelés közben
