Érdekes, én a 82h portot írom csak a képváltós programoknál, és az se villog, azt tapasztaltam, hogyha váltok, akkor szépen lefut az aktuális LPT, és csak a reload bitnél tér át az új LPT-re.

Zozo, elhozod ezt az új demo-t a klubba? Még nem láttam, ott nézném meg...

A konvertáláshoz a következő epimgconv paramétereket kell használni (a -mode 3 helyett természetesen lehet 2 vagy 4 is):

-mode 3 -outfmt 7 -size 288 192 -palres 0 -scalemode 1

Hatékonyabb tömörítés érhető el "egyszerűbb" dither használatával (például -dither 1 0.5, a második érték - amelynek az alapértelmezése 0.95 - csökkentése általában javítja a tömörítést, de rontja a kép minőségét). Ha így sem elég a memória 128K-s gépen, akkor még lehet próbálkozni a -mode 2 -dither 4 0, vagy esetleg -mode 2 -dither 0 0 használatával. A csökkentett (vagy kikapcsolt) dither mellett hasznos lehet a -chromaerr 1 a minőség javítására.

A kép mérete is módosítható a scroll2.s szerkesztésével és újrafordításával. A következő 3 változó állítható:
SCROLL_WIDTH    equ     576
VIDEO_HEIGHT    equ     192
VIDEO_WIDTH     equ     80
A VIDEO_HEIGHT a kép magassága, amely csak 16 egész számú többszöröse lehet, és legfeljebb 240. A VIDEO_WIDTH az ablak szélessége fél karakterekben, ennek természetesen párosnak kell lennie. A SCROLL_WIDTH pedig a scroll teljes szélessége fél karakterekben, ez is csak páros lehet. A scroll méretét korlátozza a memória, és a tömörítés hatásfoka. Konvertálásnál -size SCROLL_WIDTH/2 VIDEO_HEIGHT paramétert kell megadni. Egy további korlátozás, hogy az "ablak" csak 16K méretű területen mozgatható, ezért a következő feltételnek is teljesülnie kell:
VIDEO_WIDTH * VIDEO_HEIGHT + SCROLL_WIDTH - VIDEO_WIDTH <= 16384

Bővített gépen lehet sokkal szélesebb is a kép?

Elvileg igen, de kisebb módosításokra lehet szükség:
- az epimgconv fenti változata 511 karakterre (SCROLL_WIDTH = 1022) korlátozza a szélességet, illetve a bemeneti kép mérete legfeljebb 20480x8192 lehet; ezek az értékek valójában egyszerűen növelhetők a forráskódban
- a scroll2.s csak 8 szegmenst (ebből egy a 0. lap, tehát a tömörített méret kb. 124.4K lehet, 128K-s gépen pedig 76.4K + ami szabad hely van a rendszerszegmens elején) tud használni a file tárolására; ennek a növeléséhez a dataSegments táblázat méretét kell módosítani a forráskód végén

Gondolkodtam itt a nick cím váltáson ... nem passzol ez össze nekem ...

Ha úgy lenne ahogy mondom, hogy mikor a nick -nek érkezik egy reload parancs bármelyik forrásból, akkor feltölti a 82/83 port tartalmát a belső regisztereibe, akkor Zozo módszere nem működne, hisz ő éppen azt csinálja, hogy csak a 83 -as portot írja, reload flag -gal.

Ha igaz lenne amit írok, akkor a reload flag hatására (83 -as porton) mind a 82 mind a 83 -as port tartalma feltöltődne a nick -be. De Zozo módszerében épp az volt a felfedezés, hogy ilyenkor csak a 83 -as port tartalma töltődik fel, és az alsó rész az marad a nick -ben, ami volt. (Zozo szerint.)

Szóval akkor én most nem értem, hogy a különböző (két) reload módszer esetén mi a pontos nick működés. Ki tudja ezt ?

Használsz b6 -ot is a 83 -on, vagy csak b7 -et ? Nem lehet hogy a b6 jelenti a 82 reload -ot, b7 a 83 reload -ot, és az lpb reload flag meg mondjuk mindkettő újratöltését jelenti, implicit ?

Hmmm ... tehát akkor ha LPB reload flag van, akkor újratölti mindkettőt, hisz elejére ugrás, loop -olás van, függetlenül attól, hogy a portokon frissült -e valami, vagy már sok reload óta ugyanaz az érték van bennük.

Ha meg 83 -as reload flag -et kap, akkor amelyik írva lett a 2 port közül (és 83 mindenképp írva lett, mert abban van a reload bit aminek a hatását tárgyaljuk ), csak azt töltené fel ?

De mindkét esetben az aktuálisan már beolvasott és futó LPB tiszteletben lenne tartva ?

Ja ... ez így végülis elég valószínűnek látszik.

Mitől maradna bármi a képernyőn? Eltekintve attól, ha radarhoz való CRT-t használsz, amin még ott van fél percig a kép