akkor a két borderünk "egyben lesz", magyarul a reload elött a megszak jöhet a teljes (alsó/felső) border alatt, nem pedig csak az alsó alatt, ahogy a "hagyományos" LPT layout -nál.

Úgy emlékszem, hogy amikor rátér a megszakítás bitet beállított LPB utáni LPB-re, akkor generálódik a megszakítás, ezért kell minden megszakítást tartalmazó LPB után egy megszakításmentes.

Quote

Leteszteltem, ha egy helyre teszed a reload-ot a megszakítással, akkor már megtörtént az LPT reload, amikor jön a megszakítás.

Hát azt nem tom hogy tesztelted le, azt meg pláne nem, hogy hihetünk -e vajon az emunak esetleg ilyen dolgok időzítése kapcsán is,

de ha így van, akkor most összetörted szívem ...

Bár végülis ha belegondolunk ... valami szinkron mindíg lesz ... tehát idő az mindíg lesz átírni az alsó(/felső) borderek alatt ... az meg hogy en a borderre is úgy gondolok, mint a "kép része mindaddig, amíg át nem váltódott az LPT a NICK betöltése által" az nem annyira számít ...

Csak nagyon szélsőséges esetben lenne értelme annak amit mondok, hogy a teljes LPT is az "aktuális képünknek" számítson, és igenis meg kell várni a tényleges teljes kirajzolást mielőtt bonthatjuk a képet, ez a szélsőséges eset pedig az, hogyha magát az LPT -t is "törölni", újragenerálni akarnám.

Tehát most akkor valóban megtehetjük, hogy a hasznos kép tartalmát már töröljük a border(ek) alatt,

de magát a képernyőn még aktuálisan látszódó LPT -t még nem kezdhetjük letörölni, és újragenerálni,
mert azt TÉNYLEGESEN csak akkor tehetjük meg, ahogy először gondoltam, vagyis a NICK LPT újratöltés után,
amiről viszont akkor most NINCS jelzésünk, hiszen a jelző megszak már elsült a border alatt, és felhasználtuk a cím beírására ...

Na az ilyen esetekhez viszont elvi megoldást most nem is látok ...

Ilyenkor 22 -es csapdája van. Ahhoz hogy átírhassam az LPT címet, ahhoz tudnom kell hogy biztonságos időpillanat van -e éppen. Ehhez más eszközöm nincs, csak hogy megszakítást kell kapjak. Ezért várok a megszakra, de a megszak már csak az UTÁN fog megérkezni hogy a NICK újratöltötte a RÉGI LPT címet, hisz nem írtam bele az újat, mert vártam a biztonságos pillanatra.
A megszak meg ugye a reload mellé van téve, mert a teljes LPT ki kell rajzolódjon, mielőtt újra lenne generálva.

Ezt az ellentmondást sikeresen feloldja a borderes módszer a korábbi esetben, ahol ezt alkalmazni lehet.

De ha jól gondoltam végig, akkor ezt a problémát ebben a TELJESEN ÁLTALÁNOS / LPT ÚJRAGENERÁLÓS esetben feloldani nem lehet. Tehát van egy csomó kerülő megoldásunk, amik közül választanunk lehet és/vagy kell, de NINCS teljesen általános módszer. Trükközni, hekkelni, kompromisszumokat kötni kell ahhoz, hogy biztosak lehessünk abban, hogy a NICK egyszer csak nem fog elszállni az egyébként teljesen korrekt programunk mellett ...

( Tényleg ilyen nehéz lehetett volna megoldani, hogy éppúgy mint a forced reload -ot, jelezni tudjam a NICK -nek, hogy én most mindkét portot érintő címmódosítást hajtok végre ? )

Sztm. ez durva ... (Ha jól látom át. Ilyenkor szokott jönni valaki, és egy 117. eddig a gondolkodásba be nem vont körülménnyel értelmét veszi a problémának. )

Eredeti véleményedben az állt, hogy a videómegszakot oda rakhatom, ahol csak az stabilan lehet LPT címet váltani, és abból írjak LPT címet.
Ez így nem igaz, mert a képernyő látható részéről is lehet LPT címet váltani biztonságosan, de az előző (kintlevő) képet még nem kezdhetem lebontani, mindaddig míg nem olvasta be a NICK a címet a kép alján.
A priviben a megszaknak azonban már ki volt jelölve a helye a látható kép és az alsó border határára. Így már valóban jó lehet, bár erre csak a privi olvasgatása közben jöttem rá. Hogy azért mégsem kell teljes egészében megvárni a beolvasást a kép végén, elég csak az alsó border tetejéig várni, és ha ide tesszük a megszakot, akkor két legyet üthetünk vele egy csapásra, mert itt egyrészt biztonságosan írhatjuk az LPT címet, másrészt ez jelzési pontnak is jó a kirajzolásnak, hogy ennél tovább már nem kell várnia, mert innentől a border van, vagyis a szinkron LPB -k, amiket ugysem módosítunk a kirajzolással.

Magyarul mikor készvagyok a képpel (éppúgy, ahogy eddig, és az most mindegy, hogy milyen állapotgéppel, vagy milyen biteken jelzem ezt melyik program szálnak), akkor az LPT címet nem szabad beírnom egyből, úgy ahogy most, hanem várnom kell időzítésre a video megszak formájában.

Továbbra is tartom azt a véleményemet, hogy oda rakod a VINT-et, ahová akarod. Természetesen az akarásba beleértettem azt is, hogy azért van némi fogalmad arról, hogy minimum/maximum mennyi időt vesz igénybe a képgenerálásod, illetőleg az lineárisan fentről lefelé vagy össze-vissza történik. Ha tudod, hogy a tartalom újraírása soha nem fogja beelőzni a tényleges Nick által végzett képgenerálást, akkor megteheted azt, hogy a látható területre időzíted a szinkronizáló mechanizmusodat.

Amit a PM-ben írtam - bár tettem bele felkiáltójeleket - az nem kötelező jellegű utasítás, hanem egyszerűen a példa része a magyar nyelvtan szabályai szerint ("Legyen" kezdetű mondat az felszólítás, így a végére kell a "!".) leírva. Bár most elbizonytalanítottál a helyességét illetően. (Lehet, hogy egyszer erre jár majd egy nyelvtan náci és jól kijavít. ) Amit írtam, az csak a klasszikus változat volt. Az egész lényege a helyes szinkronizáció. Az állapotgép pedig csak egy eszköz.

A video megszakítás egyébként a VINT lefutó élénél történik, tehát valóban csak a következő LPB elején.

Akkor ha az utolsó kijelzendő LPB-re tesszük a VINT-et, akkor jön a megszakítás amikor már utána bordert kezdi kirajzolni, és a border/üres sorok/szinkron alatt bőven van idő beírni az új címet, jól gondolom?

Akkor ha az utolsó kijelzendő LPB-re tesszük a VINT-et, akkor jön a megszakítás amikor már utána bordert kezdi kirajzolni, és a border/üres sorok/szinkron alatt bőven van idő beírni az új címet, jól gondolom?

Igen.

Továbbra is tartom azt a véleményemet, hogy oda rakod a VINT-et, ahová akarod. Természetesen az akarásba beleértettem azt is, hogy azért van némi fogalmad arról, hogy minimum/maximum mennyi időt vesz igénybe a képgenerálásod, illetőleg az lineárisan fentről lefelé vagy össze-vissza történik. Ha tudod, hogy a tartalom újraírása soha nem fogja beelőzni a tényleges Nick által végzett képgenerálást, akkor megteheted azt, hogy a látható területre időzíted a szinkronizáló mechanizmusodat.

Igen, ez egy újabb módosítás, ahhoz képest mindenképp, ahogy én gondolkodok a dologról,

viszont míg a borderes dologra még boldogan rábólintok, mert nem tudok jobbat,

addig ezt már határozottan vissza kell utasítsam, biztos vannak olyan feladatok, amiknek a kirajzolásánál ilyeneket figyelembe lehetne venni,

de egy sprite -os grafikánál, vagy egy csillagmozgásnál felülről lefele rendezni a grafikát, és mindíg a videó sugár mögött tartani magam minden sugár pozíció kiolvasási lehetőség nélkül sztm túl sokat lassítana, ez maximum valami komondoros raszter trükknél, vagy ilyesminél lehetne sztm. gazdaságosan alkalmazható.

Azon kívül vegyük észre hogy mind a borderes módszer is (csak az még kevésbé), de ez a "sugárral szinkronizálom magam" módszer pláne, PONT AZ ELLENTÉTE a backbuffer lényegének.

A doublebuffer pont azért lenne, hogy 100% -ban független lehessek a sugártól, egyedül a képváltás van szinkronizálva (elvileg a függöleges visszafutásra, EP- n egy jelentéktelennek tűnő dolog miatt úgy tűnik csak a borderre), és a rajzolás pedig innentől kezdve teljesen szabad a backbufferen, ahogy a legszebbet a leggyorsabban ki tudjuk rajzolni.

Ha én tudom magam a sugárhoz szinkronizálni, akkor rajzolhatok mindent úgy, hogy szinkronizálva vagyok a sugárhoz, és kész, nem kell semilyen doublebuffer.

De mi nem akarunk ilyennel bíbelődni, ezért doublebuffert használunk, csak nem tudjuk a doublebuffert biztonságosan váltani, ezért elkezdünk szinkronizálni a sugárhoz ? Sztm ez értelmetlen. Újabb manifesztálódása csak a 22 -es csapdája problémának.

Egy kérdés, lehet, hogy a témához semmi köze: vannak olyan lpt animok amik z80-tól függetlenül is működnek, tehát pl. a Scroll demó töltője, NasaGuy demók stb. Ezek hogy is működtek? Képernyő magasságánál*frame magasságú lpt volt csinálva? Asszem így.