Nem szakértek hozzá, de... Ebből nem lenne gubanc (itt-ott fagyás) a "lefelé kompatibilitás" témában? Avagy hogy oldanád meg, hogy a memória olyan részeihez férjen hozzá, amik esetleg már egy adott programon belül foglaltak?

Ep128:
 Alapvetően tudni kell, hogy a NICK csak olvas sosem ír. Ez azt jelenti, hogy betekintése bárhova lehet. Ahova pedig lát, onnan képes byte-okat olvasni és a képernyőre tenni.
A nick módosítása nem járhat fagyással, mert nem ír felül semmit, csak olvas.
 Alapvetően ha elindul egy EP a nick 2.0-val akkor ugyanúgy fog működni mint addig. Az újdonság akkor lesz, ha a sorparaméter táblában nem használt biteket átállítunk 1-be.

 Egy dolgot elfelejtettem megemlíteni. Ha kiterjesztem a NICK címbuszát 16-ról 22 bit-re (2^22=4MB), amivel az EP összes szegmensét látni fogja, akkor a videomemória régi címtartománya (0000-FFFF) ami az EP-nél pont az utolsó 4 szegmens (FC-FF) átkerül  a (3F)0000-(3F)FFFF címre. Ez a kompatibilitás miatt nem jó, de ha NICK 2.0-ban letükrözöm ezt a (00)0000-(00)FFFF címtartományra, ahol az EP-ben egyébként a 00.-03. szegmensek vannak (ROM, EXOS etc.) akkor már minden ugyanúgy működik ahogyan eddig. A NICK nem akar hozzáférni a ROM-hoz.

Ergonomik:
 Azért kell a 8bit-nél több adatbusz, hogy minden 2. pixel-órajel (14Mhz/2= 142ns) legyen ott neki az 1 byte. (256 szín).
 Jelenleg a régi Nick kb 6-7 clockpixel után olvas ki 1 byte-ot; Ami 3x-4x lassabb a fenti dolognál, és a régi NICK-nél az is gondot okoz, hogy a Z80 nem akármikor fér hozzá. Ha több bites a NICK adatbusza, akkor a Nick 2.0 egy olvasással több adatot tud betárolni a cache-be (24-32bit), így a memória hozzáférést át tudja adni másnak (pl Z80-nak).

 A dolog nagy kihívása az osztoszkodás a 4MB RAM memórián. Hogy a Z80 is és a NICK 2.0 is időben hozzájusson az információhoz, ahol a NICK 2.0 a legmemóriaéhesebb.

 A közös memóriahozzáférés (Z80 és NICK 2.0) a DAVE lapozó logikáját be kell vinni a Z80-ba.

 Ez EP32 emulátor forráskódját nézegettem. Azt gondolom, módosításokkal le lehetne szimulálni rajta az elképzelésemet. Sajnos Kevin Thacker (a program írója) sok x86 Assembly betétet használt, és alig van komment, ezen előbb át kell rágnom magam, és jegyzetelnem.

Gflorez:
 Nincs hardvare sprite kezelés a NICK-ben. Nem lehet a z80-másolgatás nélkül mozgatni sprite-okat.
 Tanulságos, hogy az Amiga 1000-ben volt Sprite kezelés, de nem használták, mert a beépített memória mező másolás (BLOCK COPY=BLITTER) a video ramba olyan gyors volt, hogy megfelelt a programozóknak. Emiatt én is inkább ebben a második irányban indulnék el.

=EN
 There is no HW based sprite handling in the old NICK. There is no possibility to move a spite without Z80 block copy.
 Interesting thing, that the Amiga 1000 has a Sprite handling, but was rarely used, because the built-in memory field copy (BLOCK COPY=BLITTER) was fast enough, that the programmers used that instead of sprite. I would also go this second way.

Ez EP32 emulátor forráskódját nézegettem.

Nem biztos, hogy azt érdemes nézegetni, mivel az nagyon messze van a tökéletestől. Időzítéseket sem kezeli rendesen, és a Nick összes videómódját sem ismeri rendesen.
Nem is értem miért rángatod folyton elő ezt a régi, kezdetleges emulátort.

Nincs hardvare sprite kezelés a NICK-ben.

Ki mondta, hogy van? Azért van rajta a külső színbemenet, hogy odadugod a gép oldalába a sprite kártyát, abban ott izegnek-mozognak a sprite-ok, a Nick meg szépen rákeveri a képre. Ez volt az eredeti terv, csak előbb csődbe mentek, mintsem, hogy ez elkészülhetett volna.

Nyilván nem értek a mögöttes dolgokhoz, amik a tényleges hardverben intéznék az ügyeket, de valamiért nekem nem tűnik ennyire problémásnak. De legfeljebb majd kijavítod mit látok rosszul. A bővítő csatlakozón ott van a NICK órajele és a két szinkronjel is kivezetve. Ezekből azért elég pontosan lehet tudni éppen merre jár a képalkotás.

Egy képpontsor mindig 57*16=912 NICK órajel ciklus. Lehet tudni, hogy a /HSYNC utáni első 8*16=128 ciklusban nem érdemes rajzolni, mert ott olvassa be az LPB-t. Az is tudható, hogy a /HSYNC előtti 3*16=48 ciklusban szintén nem érdemes rajzolni, mert ott a VRAM frissítés folyik. (Úgy kb., mert most nem ugrik be hogyan van pontosan ezeknek az egymáshoz képesti időzítése. )

Négy regiszterben megadható, hogy a /VSYNC-et követő hányadik sorban (függőleges 0 pozíció) kezdjen sprite-okat szintetizálni és hányadikban fejezze be, illetve a bal és jobb képhatártól mennyivel beljebb legyen a sorban a szintetizálás be- (vízszintes 0 pozíció) és kikapcsolása. Szóval órajelek számolgatásával elég pontosan meghatározható a képalkotás pillanatnyi pozíciója, amit "csak" össze kell vetni a sprite szintézis paramétereivel.

Ha pedig a programozó összevissza alkot az LPT módosítgatásával, akkor legyen szíves erről tájékoztatni a sprite generátort is, mert a megjelenítés menedzselése az ő feladata.

Teljesen jól írod le én is ezt olvastam ki a sorokból, így történik ahogyan mondod.

 Semmilyen szoftver nem támogatta soha, mivel hogy nem létezett ilyen eszköz. Ha az EP-vel együtt meg jelent volna, mondjuk az exdos dobozába integrálva, és nem egy vagyon lett volna, akkor biztos lett volna rá fejlesztve. Habár a legjobb az lett volna, ha a nick tartalmazza ezt mint a C64-ben, akkor nem kellene számolgatni a pixeleket.