Idő az van, csak ha a 82h-t is átírod, akkor az új LPT-t az elejétől kezdi olvasni.

Hát ha az elejét írom bele ... nem ?





Na próbálom akkor összefoglalni a szabályokat:

Van a nick, annak a 2 LPT cim regisztere. 82h alacsony, 83h magas helyiérték. Ezek a regiszerek maguktól nem változnak egyáltalan. A szerepük csak annyi hogy egy LBP reload flag, vagy egy 83h reload bit (melyek tök ugyanazt a hatást érik el, csak első z80 független, második z80 függő módon) hatására ezekből a regiszterekből inicializálódik újra a nick LPT olvasása.

Tulajdonképp a nick JP utasítása a reload, és az operandusa meg ez a két regiszter, nem ?

Tehát magyarul ha ebbe a két regiszterbe barmit beleírunk, a prímszámokat akár, vagy a születési dátumunkat, az égvilágon semmi nem történik mindaddig, míg fenti két módszer valamelyike ki nem váltja a nick reload mechanizmusát, na ekkor ami épp benne van a fenti 2 regiszterben, az betöltődik a nick- be valahova belülre, és a következő lpb -t a nick onnan kezdi olvasni, és punktum.

Ebből akkor számomra valami olyan is következne, hogy a z80- nal 83h -n kezdeményezett force reload SEM AZONNAL-AZONNAL tölt újra, hanem igenis az aktuális LPB kirajzolásának be kell fejeződnie a nick által, ami ugye nagy is lehet, sok rasztersor, és csak utána fog megtörténni az a reload. Gondolom persze a z80 ettol nem fog blokkolódni, ő fut tovább, legrosszabb esetben valami 256 sor után majd tényleg bekovetkezik a reload a nick -ben. Ad abszurdum az is lehet, hogy ezen idő alatt akar módosíthatunk még a nick regiszterein ...

Namost akkor fentiekből az következik, hogy a két regiszerünkbe NEM KÖTELEZŐ az LPT kezdőcíme legyen, csak az "kötelező" hogy mikor a két okunk közül valamelyik kiváltja az LPT reload -ot, akkor "belepasszoljon" az új címen lévő LPB a szinkronunkba, és ha ez teljesül, akkor normál, rezzenéstelen képet fogunk kapni.






Ha mindez igaz, akkor viszont amit csinálsz azt nem csak 1000h- s váltogatással lehet elérni, hanem egy tetszőleges pixelsornál bekövetkező valamelyik forrásból származó reload -dal, a MEGFELELŐ LPB címével a regisztereinkben. Nem feltétlenül az LPT -nk elejével, és nem feltétlen 1000h -s határon, nem ?

Viszont ha igazakat irkáltam, nem nagyon értem miért kéne a szinkronom elején váltanom át a videomegszakban az LPT- met, hisz épp hogy meg kell várjam míg a teljes lpt- m feldolgozódott, és a legutolsó LPB -m kirajzolása közben kell váltsak a megszakból, ez esetben a masik LPT -m legelejére, nem ?

Azt ki kell próbálni, hogyha az utolsó reloados sorban van az INT, akkor még elég gyorsan beíródik az új cím, mielőtt reloadol a Nick.

Ha mindez igaz, akkor viszont amit csinálsz azt nem csak 1000h- s váltogatással lehet elérni, hanem egy tetszőleges pixelsornál bekövetkező valamelyik forrásból származó reload -dal, a MEGFELELŐ LPB címével a regisztereinkben. Nem feltétlenül az LPT -nk elejével, és nem feltétlen 1000h -s határon, nem ?

Nem 1000h-s különbséggel nem működik. Ha a 82h-t is írod oda az LPT eleje kell, különben a következő reloadnál már csak csonka LPT-t fog olvasni. Ha meg az elejét írod, akkor ugrani fog a kép reloaddal. Reload nélküli írásnál meg csak az LPT végén lévő reloadnál vált át, így kép közben nem lehet többször váltani.

Eredetileg én is onnan indultam, hogy egymás mögött volt a két LPT

Feltéve persze, hogy nincs olyan, hogy ha a 82- be írsz, akkor automatikus reload van, egy harmadik reload forrásként, vagy ilyesmi ...

Tehát ha igaz az összefoglalásom.

Nem kötelező de ez esetben jönne a következő probléma, hogy mit is írjunk 82h-ra? Tudni kéne, hogy éppen melyik sorban jár a Nick, hogy a másik LPT következő LPB-jének a címét kiszámoljuk.

Igen, de természetesen ez is megoldható lenne, kombinálva a video megszakokat, reload flag -eket az LPB -kben, illetve a megszakkezelőkben a címátírásokat esetleg force reload- okat.

De pont attól olyan elegáns az 1000H -s módszered, mert az egy huszárvágással minden szinkront a nick -re bíz, neked csak azzal kell törődj, hogy hol akarod a másikra kapcsolni a képet, és azt egyetlen byte átírásával tetszőleges időpillanatban megteheted.

Poén a kép kicsit ütősebb mint a demó kazettán lévő berepülünk a gépbe grafika!

jaja, ütős lett volna ezt kazettáról betölteni

Nasa&Guy demók is voltak ekkorák (fájlméretre) , és azokat bőven töltögettük magnóról.

Az vajon miért van, hogy az exos leírásban az szerepel, hogy a 83h port -ra először írjuk ki simán az értéket, majd az értéket a b6 -tal megtolva, és utána előzőt b7 -tel megtoldva ?