Õszintén szólva el nem tudom képzelni, hogy képzelték, hogy ezeket az ISSUE3-as gépeket osztogassák, mint bemutató példányokat...
Valószínûleg nagyon kétségbe voltak esve, hogy valamit mutatni kéne már a népnek, de csak gyári selejtek vannak 

Annak ellenére, hogy van borda a Nicken, az összes létezõ hibát produkálja egyszerre (pedig a borda mûködik, kb 10 fokkal hidegebb így, mint egy fedetlen Nick! El nem tudom képzelni milyen lehetett borda nélkül... de ezért nem fogom meghámozni )

Itt egy kis Eat it Up bemutató, miközben a mágikus potmétert csavargatom.
Ami érdekes, hogy amikor kezd el tûnni a Text 80-as szöveg, akkor mintha kevesebb hiba lenne a fal karakterekben. Bár lehet, hogy csak feketére váltanak a pöttyök, és azért nem olyan feltûnõek

Arról most nincs videó, de Text 40-ben is produkálja a hibákat.

Esetleg emlékszel olyan dologra amit így derítettél ki?

Néhány példa:
 - nem dokumentált video módok (pl. milyen a 16 színű ATTR mód + MSBALT, vagy az "érvénytelen" 6-os mód ? )
 - a 83H port felső két bitjének a működése
 - időzítés, video memória várakozás, bemeneti órajel pontos értéke (14237536 Hz az alkatrészek szórása nélkül)
 - I/O címdekódolás (84H-8FH portokon ismétlődik), port olvasás (a NICK adatbuszról az utolsó értéket adja vissza)
 - különböző kisebb hibák, elírások, pontatlanságok a leírásban (ha jól emlékszem, az LSB/MSBALT és/vagy ALTIND0/1-nél valami fel volt cserélve, a megszakítás kimenet az igazi gép tesztelése előtt invertált volt az emulátorban, stb.)

Ettõl függetlenül felmerült már bennem, hogy kidobni az egész videó memóriát, a címmultiplexerekkel együtt, és egy 486-os alaplapról kiszedett 64K SRAM IC-vel (ott cache volt) helyettesíteni, amely 15 nanos, vagyis 10x gyorsabb mint az eddig használt leggyorsabb RAM IC
Viszont ezután elég buhera kinézete lesz a lapnak

Ráment vagy 3 este... és baromira nem változtat semmit a dolgon 
[ Guests cannot view attachments ]

Ettõl függetlenül meglepett, hogy bekapcsoltam, és elindult a gép
Azt majd még megnézem, hogy így hány Mhz-ig lehet eljutni tunningban de ez már egy másik téma.

A 16 színű ATTR mód érdekelne, emlékszem volt szó róla korábban, de nem találom, segítségedet kérném ,

Az attribútum mód alapvetően azt jelenti, hogy a paletta szín alsó bitje alapján kicseréli a színt az attribútum byte-ban választott "papír" vagy "tinta" színre, kivéve a 256 színű módot, ahol nincs hatása. Ez a konverzió az LSBALT és hasonló módosítások után történik, tehát azok nem változtatják a színt (mert csak az 1. és 2. bitet állítják, amit az ATTR figyelmen kívül hagy), de azért az LSBALT/MSBALT levágja a pixel byte megfelelő bitjét.
Ez alapján a 16 színű ATTR módban tehát ez történik:
  b1,b5,b3,b7 b0,b4,b2,b6
A karakteren belül két négyszeres szélességű pixel lesz, amelyeket a 7. és 6. bit határoz meg, a többi bitnek nincs hatása. Az MSBALT bekapcsolása azt eredményezné, hogy a bal oldali pixel mindig "papír" színű lenne.

Az LSBALT, MSBALT, ALTIND0, és ALTIND1 egyébként minden módban működik, nem csak ott, ahol dokumentálva van:
 - az LSBALT/MSBALT nullázza a pixel byte megfelelő bitjét, és a paletta szín 2. vagy 1. bitjét 1-re állítja (OR művelet) a bit eredeti értéke alapján, de a 256 színű módokban a szín nem változik, és attribútum módban sem, mert az attribútum konverzió később történik, és csak az alsó bitet veszi figyelembe
 - az ALTIND0/ALTIND1 mindig az LD1 címről olvasott érték alapján működik (függetlenül attól, hogy az éppen pixel adat, karakter kód, vagy attribútum byte), és nem nullázza azt a bitet, amely a színeket vezérli (tehát pl. 256 karakteres módban az ALTIND0-t és az ALTIND1-et is bekapcsolva továbbra is 256 karakter marad, csak 4 64 karakteres csoportra osztva, amelyek különböző színűek); az LSBALT/MSBALT-hoz hasonlóan szintén OR művelet történik a paletta szín megfelelő bitjével, az esetleges attribútum konverzió előtt, és csak 2, 4, vagy 16 színű módban

és mostmár az érvénytelen 6-os mód is piszkálja a fantáziám

Annyira azért nem érdekes, gyakorlatilag olyan karakteres módnak tekinthető, amely a pixel adatot mindig az FFFFh video címről olvassa.

Még egy érdekesség: a VSYNC módban a keret is más (ezzel kapcsolatban korábban Zozosoft tévedett ): itt az aktív (nem keret) részeken szinkron (a feketéhez képest "negatív" világosság), a keret helyén pedig mindig fekete szín (VBLANK) van, és nem generálódik színsegédvivő jel (nincs burst a sor elején).

Amirõl még nagyon nincs fogalmam: ezen a rajzon, mi a fenét csinál a lap alsó-közepén található bonyolult ellenállásos tranzisztoros kondenzátoros komplexum???
Annyit tudok tippelni, hogy ebbõl lesz a 14 Mhz-es videó órajel, mivel az U37 10-es lába kimenet. De hogyan lesz itt óra jel? Az egész indul a Nick ismeretlen H/2 és H2REF kimeneteivel...

Annyi biztos, hogy az ISSEU3-as alaplapokon az R81 lett kicserélve egy 470 ohmos potméterre, amivel rendkívül látványosan és érdekesen lehet befolyásolni a Nick mûködését. (Eltûnõ Text 80 karakterek/elmosódó 256 szín)

Azt hiszem ezt a részt Tigrian érthetné, de õt évek óta nem láttuk 

De hogy lesz a H2 kimeneteken jel bekapcsoláskor, amikor még áll a Nick? És ameddig nincs H2 jelek, addig mibõl csinál a az áramkör órajelet?
Vagy az magában is rezeg, ez a H2 csak a finomításra szolgál?

Köszönöm szépen az ismertetőt, egyelőre még 100%-osan nem értem, kúrűnak forralt bort használtam , arra gondoltam, hogy esetleg ki lehet csiholni a Nick-ből C64 lo-res üzemmódot is

Az L2 feltehetõen éppen azért hangolható

Ennek a tekergetésével hullámozni kezd a kép egy idõ után, ha túl sokat tekerünk

Kipróbáltam az ISSUE3-ból ismert dolgot, az R81 potméterre cserélését is: érdekes módon egy újabb alaplapon nem jön elõ az a effekt, hogy eltünik a Text 80 vagy a 256 szín elszínezõdik! A pixelhibára viszont csak minimális hatása van, inkább csak úgy sûrûségében látszik egy pici különbség. Kipróbáltam a "testvérellenálláson" is, az R82-n, hasonló eredménnyel.