Amugy ha mar Z80 ... eZ80, 50MHz orajellel, atlagosan 4x gyorsabb meg ugyanazon orajelen is mint a Z80 lenne, de van ahol akar 10x is ... De teny, hogy ehhez total uj EP-t kene mar tervezni

Hat jah, de nem tartom kizartnak hogy valahogy _talan_ ki lehet kapcsolni az "utban levo" integralt i/o hulysegeket, vagy hasonlo. Ha semmi keppen nem megy, akkor gaz ...

A külsõ Nick 1MByte Statikus Ram memóriával rendelkezik. FF (255) szegmenstõl visszafelé fog elterülni a memóriában C0-ig (192).
 Mivel az alap 64KByte memória (FC-FF) kell a belsõ Nicknek, ezért a külsõ egységben ez a memóriaterület csak írható lesz. A külsõ Nick is innen dolgozik. A többi teljes sebességgel fog mûködni.
 A külsõ nick extrája az lesz, hogy az új videomódokban mind az 1MByte memóriát meg tudja címezni, így akár 640x480 / 256 színû felbontást elérhetünk vele. Vagy mégtöbb képet rajzolhatunk ki alacsonyabb memóriaigény esetén.

A külsõ Nick további extrája:
 Tervezek bele még egy elõjeles ofszet regisztert, amely azt hivatott megmondani, hogy vízszintes scrollozáskor az adott sor(ok) kirajzolását hány pixellel korábban/késõbb kezdje el. (ezzel teljesítem Zozo álmát, piszok gyors scroll lehetõséget biztosítva)

 Megcsinálom ugyanezt függõlegesen is, így a sorparméter blokkok LD sorait lehetne ofszetelni.
 Arra gondoltam hogy kiosztanék a Nick-nek plusz I/O címeket ahol ezt lehetne megadni.

Ha valakinek megvan az Enterprise Rom-visszafejtése (0.szegmens) legyen szíves nézze meg, hogy:
 84h-tól 8Fh-ig vannak-e szabad I/O címek?
(9.2 fejezet "IN/OUT címek")

Amennyire en tudom: 80h-8Fh a Nick szamara vann fenntartva, de ebbol a Nick csak 80h-83h portokat hasznalja. Az erdekes kerdes, hogy letezik-e olyan elvetemult software, ami kihasznalja esetleg a "memoriavisszhang" jelenseget, azaz, hogyha igaz az pl, hogy nincs dekodolva a kerdeses tartomanybol a nick szamara hasznos, es 4 cimenkent "ismletodik" a nick regiszer "keszlet". Amugy amikor en csinaltam Nick2-ot (csak sw-esen, sajat emulator kezdmennyel), akkor vmi ilyesmi volt (emlek alapjan, mivel a serverem sajna "megsemmisult" jo par eve, amin ezek a cuccok is voltak ):

84h: keyreg, 76 decimalist ide irva beallitja az extended nick funkciokat (76 szerenyen a szuletesi evszamom)
85h: palette select register; kivalasztja a 256 EP szin kozul azt, amit olvasni/irni akar az ember
86h: palette data register; 2 byte olvashato/irhato minden fenti szinre (16 bit/colour info)
87h: extended nick control
  Itt voltak olyasmik (pontosan mar nem emlekszem), ahol egy 2 bit kivalasztja a "read rate"-et (x1=normal, x2, x4, x8),
  vagy egy masik a nem definialt videomodra engedelyezi a kozvetlen hi-color mode-ot (1 pixel = 2 byte, 65K szin)
  vagy egy masik bit pl azt csinalta hogy beallitotta az std EP palette-at a 256 szinre, masik ertekkel lehetove tette a 85/86h porton custom pal-t
  illetve pl x1 rate folott definialta hogy az egy slot alatt az LPB fetch soran beolvasott extra byte-ok legyenek-e extra infokra ertelmezve,
  vagy sem (sem = 16 byte, original LPB
88-89h: LD1 (?) offset, hozzadja mindig [scroll, stb]
8A-8Bh: LD1 (?) modulo, sor vegen hozzaadja (nagyobb kepben "latszik" a nick "ablaka" ...)

Mondjuk nem tudom mi ertelme volt, hogy leirtam ezeket, hatha otletnek jo valamire Sajnos pontosan mar - mint irtam - nincs meg, de valami ilyesmi volt. Es persze extra LPB byte-okban (>x1 read rate, illetve extended LPB engedve) volt par info pl a "hianyzo" 8 pal color
16 szinu modhoz, illetve annak beallitasa, hogy az extra read rate modban mire forditodik a beolvasott extra info: horizontalis felbontas
novelese, vagy egy uj (LD3) pointer alpapjan noveles, amivel pl DMA szeru dolgra lett volna jo, I/O portrol iras/olvasas iranyaba (pl akar
CPU fuggetlen digi lejatszas, ilyesmik), de ez csak terv volt.