> Orulok neki, hogy van meg egy ember, aki meg mindig kiserletezik ezzal a jo kis geppel! :)

Módjával... :-/

(Hogyan kell rendesen idézni ezzel a döggel?... Nem találtam autoindent :-( ).

>> A lehetőség Plus/4-en inkább $ff1e manipuláció, és ez is leginkább bitmap módban, mert ott >> nem kötött a soronkénti byte-ok száma.

> Ezt nem ertem. Miert nem kotott. Es mi is van $ff1e-n, a vizszintes raszter pozicio?

$ff1e igen, a vízszintes raszter pozíció (ill. annak felsőbb bitjei, kivéve a legfelsőt mert azt kihagyták a drágák :-/ ).

Ugyanúgy mint a függőleges raszter pozíció, $ff1d. Írható-olvasható a reg (bár annyi trükk van benne, hogy olvasásra nem a várt értékeket adja, másképp fogalmazva: valami meg van keverve a hardverben, mert egy ismert, magából a regiszterből előzőleg kiolvasott számot visszaírva (az időzítésre is ügyelve) elmászik a sor időzítése :-O.

Ha írod a regisztert, ugyanaz a helyzet mint a függőleges számlálóval: mivel a TED kép-felépítési műveletei ehhez szinkronizáltak, a kép "manipulálható" :-).

Kötött / nem kötött: amikor a keret leszedésével kísérleteztem, próbaképp "megnyújtottam" a kép karakteres mezőjét (ugyanúgy mint a függőleges keret-leszedésnél: visszaléptetve, majd előreléptetve a regisztert, a megfelelő időpontokban). Működött is :-) (bár nagyon labilis volt; ha elszámítottam valamit, borult az egész, memória-felülírás meg ilyenek :-/, valahogy úgy mint a késői C64-ek amelyek borulnak a durvább D011 trükkökre). Ezzel lehet nyerni vízszintesen néhány karakternyi plusz szöveges mezőt :-). Sokat nem, mert Plus/4-en (a lassabb dotclock miatt) eleve kisebb a keret.

A baj viszont az, hogy a karakter- és színmemória beolvasása továbbra is (a TED-be drótozottan) 40 byte-os per karaktersor :-/. Ahogy a TED felépít egy szöveges rasztersort, a sor elejétől folyamatosan olvassa a belső 40 byte-os karakterkód- és színpuffereit (azokat, amelyeket az utolsó bad line során töltött fel), ill. a karakterekhez tartozó bitmaszkokat. ...Aztán a 40-edik karakter után, "rájön" hogy nahát, még vissza lenne néhány karakter :-). Illetve nem jön rá, és ez a baj. A belső puffer valószínűleg fix 40 byte-os. Ezért a frissen kreált új pozíciókra normálisan nem lehet karaktereket tenni (mert a TED nem tudja hogy ott mi lenne), és a színmemóriával nem lehet befolyásolni a színüket :-(. (Hogy pontosan mi jelenik meg, már nem emlékszem).

A megoldás a bitmap mód. Ott a bitmap beolvasását önálló számlálók vezérlik. Kipróbáltam, és a karakteressel ellentétben, a bitmap móddal nincs baj. A soronkénti bitmap byte-ok száma nincs rögzítve, annyit olvas amennyit kell. Azaz, simán előfordulhat hogy egy bitmap sor hossza nem $140 hanem mondjuk $158 vagy $160 byte hosszú :-). Megcsinálja. Baj még mindig van, az új pozíciók színével -- de ez főleg multicolor módban már egy más súlyú probléma :-).

Asszem érdemes volna meghallgatni Crown-t mert ő mintha kódolt volna egy _valóban_ működő oldalkeret-leszedő rutint.

> Te egyebkent aktiv vagy?

Inkább úgy fogalmaznék hogy "áll az élet".

> Indulsz a mostani 16K compon vagy az 1K mini game compon?

Szinte kizárt.

A 16K compo-ra tavaly úgy gondoltam nevezek, el is készült egy TED zenelejátszó rutin meg némi teszt-zene (két ch négyszögjel mintállat =-) ). Aztán ebben maradtunk :-/.

L.