Általában elég az "EXOS 2.1 Műszaki Leírás"-ból másolni. 

Ha tudod hogy létezik, és ha tudsz egyet szerezni ...

Igen, meg úgy általában a programok 99%-a. Geco CPC átirataiban van olyan, hogy kellett a 300Hz-es CPC megszakítás is, így több videó megszakítás lett egy LPT-n belül.

Illetve az én átirataim jelentős részében. Azonban sokszor így is egyszerre csak egy megszakítást használtam az LPT-ben, mert különben nehéz megállapítani, hogy a 6 közül éppen melyik történt. Tehát a program minden megszakításnál módosítja az LPT-t a következő megszakítás pozíciójának megfelelően.

Ha tudod hogy létezik, és ha tudsz egyet szerezni ...

A hiányában nehéz lehetett a gépi kódú programozás (a csak EXOS-on keresztül történő hardver kezeléstől eltekintve, de akkor is kellene ez a könyv az EXOS hívások dokumentációjához), mert ebben volt található a DAVE és NICK programozásának a leírása is. És még ebben a könyvben sem volt információ a hardver szintű billentyűzet kezelésről.

Hmmm, a 28 karaktersoros EXOS kép (status+27 sor) az 252 sor, még pont belefér. Lehet, hogy erre is kalkuláltak?

Így azonban csak 10 sor marad a VBLANK+VSYNC-re, ami ugyan elég lehet (különösen fekete kerettel), de nem szabványos, illetve az NTSC TV-ken gyakran nem lett volna látható minden sor, mert a "szabványos" látható függőleges felbontás interlace módban csak 480 (2 * 240) sor.

Most én úgy írtam meg az LPT beváltómat, hogy van egy bool falg -je hogy forced vagy nem forced,

ha nem forced, akkor betolja a 0x82 -t, 0x83 -at a címmel és mást nem csinál, de ha forced, akkor 0x83 -ra beírja a címkomponens + 64, aztán a címkomponens + 64 + 128 -at is ...

forced esetben jól működök,

nem forced esetben meg az egész kép border lesz.

Nem forced esetben sem csak simán a címkomponenseket kell kiírni, vagy csak valamit elrontok ?

Na most mondja meg nekem valaki, hogy miért nem jelent az LPT újratöltésének módja időzített atombombát nem forszolt reload esetén ...

Az egész forszolás ugye azért lett kitalálva, hogy egy invalidus memóriát szkennelő NICK -et ki lehessen billenteni az elszálltságból.

Ha ilyen nem lehetne, akkor nem is kéne forszolás.

Az egyik mód, ahogy a NICK invalidus memóriát szkennelhet, az az, hogy a Z80 nem forszolt LPT címváltáskor beírta a 0x82 -es portot, és mielőtt beírná a 0x83 -mast is, a NICK pont reload -os LPB -t kezel, és újratölti a félig beírt címet.

Ezt írják is, hogy videó megszakkal kerüljem el.

Nade mi van, ha a programom nem frame -es, és nem is tudom hány frame -mel megy, sőt mondjuk 0 és 5 frame között változik az ideje.

A videómegszak megtörténtekor ( korábbi megállapodás szerint az a reload -ot jelölte egyben ) nem írhatom egyből át az LPT címeket nem forszolt módon, mert a frame végén a NICK be fogja tölteni, az én programom meg lehet 3 frame -ig fut.

Tehát backbufferbe le kell generáljam a képet, majd csak azután írhatom be az új LPT -t (ami a backbuffer -emre mutat), és majd annak a (mondjuk épp harmadik) frame -nek a végén fogja a NICK így újratölteni.

Igen ám, de mivel a programom ákármennyi ideig is tarthat, ezért bármikor lehet a fél beírás miatt NICK halál.

Tehát vígan fut a programom, majd egy pillanatban mikor pont úgy jön ki, akkor a NICK megbolondul, amiből egy forszolt írás kihozná, de hát az egyrészt ronda, ráadásul nem is tudom mikor bolondult meg ...

Magyarul egy időzített, kivédhetetlen NICK elszállás lebeg a programom feje fölött végig ... nem ?

Nincs megoldás ?

Nem értem ezt az aggódásodat az LPT elszálláson.

Nagyon nem aggódom, de azért tudni szeretem mi a stejsz, és nem is tetszene ha tényleg úgy lenne, ahogy problémázok rajta.

Ha a programod nem "frame-es", akkor egy sima osztott állapotgéppel kezeled a szinkronizációt.

Na ez túl absztrakt volt, nem végeztem progmatot, szal ez nekem dzsiberis.

Ahogy javasolják, oda teszel egy VINT-et, ahol biztonságos az LPT váltás.

Hát az LPT váltás nagyjából mindenhol biztonságos, ha megszakhoz van szinkronolva, nem? De maradjunk a végénél, mert azt alkudtuk ki Zozo -val.

A megszakításkezelő megvizsgál egy flaget, hogy a rajzolásod elkészült-e már? Ha úgy találja igen, akkor átírja az LPT mutatót, és jelzi egy flagben, hogy a rajzolás kezdje meg a másik buffer feltöltését.

Nem oda buda. Ha arra várok, hogy a megszakkezelő írja át a címet (aki mellesleg figyeli hogy már kész -e a rajzolás, ahogy írod), akkor lemaradhatok egy frame -ről.

Tehát a megszakítás (és az általa kezelt flag) csak azt jelzi a főprogramnak, hogy a NICK már betoltotte a főprogram által korábban megadott új LPT címet, ezért már a főprogram pusztíthatja az előző LPT által mutatott képet.

Ha megszakra várnék az átírással, akkor valóban biztosan stabil lenne, de mikor 2.5 frame alatt megvan egy kép, akkor 3/4 frame határon nem töltődne be a cím a NICK -be, hiszen nem írtam bele, mert várok a megszakra, hanem a megszaknál írnám be a 3/4 frame határon, és majd a 4/5 frame -nél töltené csak be a NICK.

Ha meg nem várok megszakra a beírással, ahogy most van, hanem csak a regi kép lebontásával várok a megszakra, akkor pedig előfordulhat NICK elszállás ... sztm.