Még egy kisebb hiba a NICK emulációban: a margókat a valódi hardver nem < és > műveletekkel teszteli (ilyen "bonyolult" aritmetikát nem használtak a tervezésnél, és más gépekben sem, pl. a Plus/4-es TED-ben, stb.), hanem csak az egyenlőséget figyeli:
- ha az aktuális slot == jobb margó, akkor a képernyő inaktív (keret) állapotú lesz (akkor is, ha a bal margó értéke azonos)
- egyébként ha az aktuális slot == bal margó, akkor a képernyő aktív állapotba kapcsol
Ennek általában nincs nagy jelentősége, de előfordulhatnak olyan programok, amelyek "szabálytalan" margókat használnak. A 0-7. és 54-56. slot alatt természetesen nem lehet az LD1 és LD2 címekről olvasni, de a számlálókat a NICK ilyenkor is növeli ha a kép nem keret. DRAM frissítéskor a HBLANK előtt az utolsó olvasott video byte ismétlődik (ezt az ep128emu nem tudja, az "érvénytelen" 47. karaktert egyszerűen 0. paletta színnel tölti fel).

További NICK érdekességek:

Az "érvénytelen" 6-os video mód valójában olyan "karakteres" mód, ahol az LD2 cím mindig FFFFh. Ez ritkán hasznos, de könnyen emulálható.

Az LSBALT, MSBALT, ALTIND0, és ALTIND1 minden video módban működik, akkor is, ha a használatuknak nem sok értelme van. Ezek a paletta színekkel végeznek OR műveletet ha az adott bit 1, aminek azonban nincs látható hatása attribútum és 256 színű módokban. Az ALTIND0/1 mindig az LD1 címről olvasott byte-ot használja, és nem törli a bite(ke)t. Az LSBALT/MSBALT mindig a pixel byte-ot használja, és mindig törli a 0. és/vagy 7. bitet.

Az attribútum mód lényege, hogy a paletta szín 0. bitje alapján választ "papír" vagy "tinta" színt, a többi bitet figyelmen kívül hagyja, és 256 színű módban nem működik (ilyenkor gyakorlatilag 256 színű LPIXEL mód az eredmény, az LD1 helyett LD2 címről olvasva). A 4 és 16 színű attribútum mód ezért csak a felbontást csökkenti, de nem eredményez több színt. Az LSBALT stb. a paletta szín attribútum konverzió előtti értékét módosítja, így ezek sem módosítják láthatóan a színeket, az LSBALT és MSBALT azonban ilyenkor is törli a pixel byte 0. vagy 7. bitjét.

A fentiek alapján tehát ez az algoritmus határozza meg a kimeneti színt, ennek alapján minden lehetséges mód definiált:
- ha LSBALT vagy MSBALT, akkor a pixel byte 0. vagy 7. bitjének a törlése
- paletta szín választása a pixel byte alapján (2, 4, vagy 16 színű mód), felbontás csökkentése ha nem 2 színű mód
- ha ALTIND0 vagy ALTIND1, akkor a paletta szín módosítása az LD1 byte megfelelő bitje alapján (OR 2 vagy 4)
- ha LSBALT vagy MSBALT, akkor a paletta szín módosítása az eredeti pixel byte megfelelő bitje alapján (OR 2 vagy 4)
- ha ATTRIBUTE mód, akkor a paletta szín 0. bitje alapján (a többi elveszik) PAPER vagy INK szín választása
- ha 256 színű mód, akkor a fentiek nem számítanak, kimeneti szín = pixel byte (de törölt 0/7. bittel ha LSBALT/MSBALT)

A VSYNC módban csak két lehetséges kimenet van. Ha a kép aktív (nem keret), akkor szinkron (negatív fényesség), egyébként VBLANK (fekete szint, burst jel tiltva).

Eleve vannak ott komolyabb gondok is, a vsync, interlace miegymas.

Ezeket viszonylag egyszerűen meg lehet oldani, ha nem fontos, hogy a nagyon "szabálytalan" LPT is valódi TV-hez hasonlóan jelenjen meg (lehetséges például a vízszintes szinkront "elrontani" megfelelő margó beállításokkal, ezzel Endi próbálkozott valamelyik régebbi demóban). Az alábbiakkal elfogadható minőségű emuláció érhető el:
- ha egy sor VSYNC módú, akkor az egész sor fekete (a keret is)
- ha a sor elég hosszú része (pl. legalább 20 karakter) nem keret, akkor az a sor VSYNC impulzusnak számít
- egy lehetséges megoldás szinkronizációra: egy számláló növelése minden sorban, és ha elér egy bizonyos maximális értéket, vagy ha egyenlő vagy nagyobb egy minimális értéknél és az adott sor VSYNC, akkor az függőleges visszafutást eredményez (számláló nullázása). A számláló egy bizonyos értéke (312 - látható magasság - 3) nullára állítja az aktuálisan rajzolt sort a képernyőn, ami egyébként egy másik számláló amely ha eléri a látható magasságot, akkor a képernyő frissítését eredményezi (a további sorok az újraindításig nem láthatóak és elvesznek). Így - megfelelő minimális és maximális sor számot választva - minden lehetséges LPT hosszúságnál van használható kimenet a teljes képernyőn, a függőleges frekvencia nem lehet nagyon alacsony vagy magas, és szabálytalan LPT-vel a valódi TV-hez hasonlóan "fut" a kép
- interlace: ha a VSYNC kezdete a sor közepéhez van közelebb, akkor a következő képet fél sorral (illetve 2x nagyításnál 1 sorral) felfelé kell eltolni

https://github.com/lgblgblgb/xep128/blob/master/doc/vinttest.asm

Oke, kicsit bena teszt program Most hasonlo kepet ad ep128emu es Xep128. Itt lathato, hogy milyen a INT1 bit szint Dave-rol olvasva (fekete/zold), illetve, hogy az interrupt mikor kovetkezik be (kek sav), ami ugye az LPB vegen ahol INT bit be van allitva (felteve, ha utana levo LPB-ben INT bit nincs ismet beallitva, mert akkor nem lesz "éle" a signalnak ami kell). Persze, talan anno pont IstvanV tollabol mar olvastam, hogy igy a vegen, stb, de erdekes igy latni "szemmel" is. Gondolom valodi EP-n is igy kene kineznie, foleg, ha ep128emu-ban igy nez ki

Zozo, bar nem engem kerdeztel, es nyilvan nem is tudom, mi az igazsag de eszembe jutott, hogy azert ezt nem lenne tul nehez tesztelni, elvileg, egy valodi EP-n. Ha jol tippelek, a busz boviton eleg lenne az EXTC-t fixen (?) a foldre kotni (mivel elvileg alacsony aktiv), a biztonsag kedveert pl ellenallason at. Ezek utan a 4 EC szin info-t hol a +5V-ra, haol a GND-re kotogetni mas-mas sorrendben, ezzel kulonbozo szineket "betaplalva" igy konstans modon kb egy darab drottal (ismet, lehet azert a biztonsag kedveert egy ellenallason at) Lehet en latom rosszul, de mar ekkor eleve kikserletezheto lenne, mi tortenik, pl ket szinu mod LPT, es eljatszani az EC bemenetekkel hogy mit latsz a kepernyon.  Persze gondolva meg a 80h port bit 5/6 ertekere is azert. Elvileg talan a felbontas is kikiserletezheto lenne, ha az EXTC fix kotes helyett a pixel clock-ot kapja (hmm vagy annak felet? na most ebbe belekeveredtem, de az elv gondolom ertheto, meg lehetne probalkozni mas frekvenciakkal is esetleg ha valtoztatni kell a minta "surusseget"), a cel az lenne, hogy akkor egy EP "elemi" pixel idejere a kulso EC bemeneteken levo szin, egy idejere meg nem (nincs engedlyezve) stb minta alakulna ki a kepernyon, vagy eppen nem alakulna, ha az adott LPB szerinti felbontas ott mondjuk kisebb a video (lpixel?) es vagy colour mode miatt.

Ez most azert jutott eszembe, mert minden extra bonyi cucc nelkul elvileg ezt tesztelni is lehetne, igaz ilyen konstans kulso szin, vagy max egyszeru "minta" (negyszogjebol eloallo pl) esetere. Nyilvan normalis felhasznalasra erre vmi  olyasmit kene kotni mint egy CPLD, FPGA vagy kelloen gyors MCU stb Bar mar a konstans dolog is erdekes lehet.

Tovabba: erdekes lenne tudni, hogy pl 256 szinu modban amikor egy pixel "nagy" es palettat sem hasznal, mi tortenik az EC bemenetek hatasra. Akkor is lehet-e az EC bemenetekkel finom (hires 2-nek megfelelo) "rajzolatot" csinalni, illetve akkor az EC-n kodolt 16 szin mi a fene lesz, kozvetlenul paletta nelkul mert a 256 szinu mod azt hasznalja, vagy a 256 szinu mod "alatta" marad paletta nelkul, de az EC bementekkel kodolt szin az LPB-ben levo palettat hasznalja kozben?

Ha jol tippelek, a busz boviton eleg lenne az EXTC-t fixen (?) a foldre kotni (mivel elvileg alacsony aktiv), a biztonsag kedveert pl ellenallason at. Ezek utan a 4 EC szin info-t hol a +5V-ra, haol a GND-re kotogetni mas-mas sorrendben, ezzel kulonbozo szineket "betaplalva"

Arra gondoltam, hogy rá kéne rakni egy számlálót a video clockra, és annak a kimenetét bevinni EC-nek.

Én úgy oldottam meg, hogy a "szabványos" módokhoz külön (optimalizált) renderert írtam, és ezeken kívül van egy általános megvalósítás (NickRenderer_Generic) ami mind az 512 lehetséges szín/mód kombinációt tudja, de lassabb, és ez kezeli a nem dokumentált módokat:

Hmmm, erdekes otlet A modok nekem is tablazatban vannak, csak ugye pl PIXEL2 az egyben ha *BALT, ha nem Ezt kulon venni elvileg tenyleg gyorsabb, mar nem tudom mennyi kulonbseget jelent ... Mondjuk ha en majd aritom ugy is, a generic helyett csinalnek inkabb "generic attribute", stb implementaciokat, hogy azert ne kelljen ott is vegignezni modonkent,
hogy most melyik, vagy most meg hibaba esek, hogy emiatt aggodok, amikor mondjuk egy switch/case cuccos ami valszeg ugyis jump table a forditas utan asm szinten ... ?

Code: C++

1.   DECLARE_RENDERER(NickRenderer_PIXEL_4_LSBALT);
2.   DECLARE_RENDERER(NickRenderer_CH64_4_ALTIND0);
3.   DECLARE_RENDERER(NickRenderer_LPIXEL_4_LSBALT);
4.  

Ezek miert vannak meg "kulon", amikor talan ez se "standard", es inkabb a generic lenne?

Meg egy kerdes, ami nem is kifejezetten emulator fuggo, bar szerintem errol is lehetett szo mar. Eleg csak egy uj LPB elso scanline-janal felolvasni a dolgokat es eltarolni belso valtozokba? Vagy ugyanazon LPB (ha tobb scanline-ra vonatkozik, nyilvan!) eseten is az elso 8 slot-ban mindig ujraolvassa amugy is az LPB-t? Es ha ujraolvassa, mi van ha megvaltozott par parameter a memoriaban kozben? Foleg a scanline counter az erdekes, de persze mas is, ha video/colour mode valtozik, margin, paletta, vagy akarmi. EP-n ha mindig ujraolvassa a Nick valojaban, es hagyja is ervenyesulni, az ugye elvileg lehetoseget adna bizonyos erdekes trukkokre, bar vegulis ertelme nem sok, mert ugye akkor lehet tobb LPB-t megadni es ott megoldani, nem tudom lenne-e ertelme, illetve barmi kihasznalja-e ezt. Ez meg pl a VINT-re is erdekes hatassal lehet, mert mi van, ha LPB-ben be van allitva a VINT bit, es az LPB vonatkozik 10 scanline-ra, de kozben a CPU az 5. scanline-nal meg kinulazza, akkor a kov scanline-nal Nick ujraolvassa, megvaltozik a Dave fele meno INT1 allapota, igy elobb kovetkezik be az INT1 latch set (es ha engedve van a Z80 fele az interrupt keres ...) mint az LPB vege? Szoval, ugy erzem ez eleg sok mindenre kihatassal birhat, mar ha fontos egyaltalan, hogy ennyire pontos legyen az emulacio egyaltalan ...