Akkor sorban...
256 szín módban mit csinál?
GRAPHICS HIRES 256 és utána a SET PALETTE és SET BIAS utasításoknak van-e hatása a téglalapokra? Vagyis ezeket használja, vagy fixen az első 16 színt?
#0: Itt a tegnapi első kép:
#1: GRAPHICS HIRES 256 (Ez, és a többi kép már FullHD
(920×576 pixel) felbontású, ekkora a digitalizáló maximális felbontása.)
#2: SET BIAS 55
#3: SET PALETTE 11,22,33,44,55,66,77,88
Kíváncsian várom a végét Ha lesz kész hw, egyre beneveznék.
Hehe...
Ez egyelőre csak egy teszt. Ha lesz kész HW, annak egyelőre a funkcióit is ki kellene találni.
Nincs szó 256 színű módról. Ez csak azt a 16 (8+bias) paletta színt tudja használni, ami az éppen megjelenített LPB-kbe van programozva. Viszont – gondolom én – a Z80-at ez nem fogja lassítani a memóriájához hozzáféréskor a NICK-kel ellentétben.
Innen nem lesz 256 színű mód, ez tulajdonképpen várható is volt, viszont ettől függetlenül ez egy picit csalódás a számomra.
Ugyanis a sprite-ok egyik lényege pont az lenne, hogy az alap háttértől teljesen független pixeleket lehet kipakolni, és ez vonatkozik a színekre is...
Így viszont minden külső pixel színe függ a beállított palettától / biastól. A tökéletes megoldás (
szerintem) az lett volna, ha a kívülről bepakolt szín-információ kikerüli a NICK egész palettázós részét, és közvetlenül ki is jut a megfelelő szűrések után a színkimenetre. Ez persze úgy lenne az igazi, ha 8 színbemenet lenne, lehet hogy nincs +4 szabad láb már a NICK-en. De akár a felbontás felezését is el tudnám fogadni, hogy a 4 vezetéken 2 lépésben lehetne betolni a 8 bitet... Sőt, ezt ennél egyszerűbben is el tudom képzelni: a NICK-ből csak egy "csere" vonal jönne ki, és egy egyszerű külső logika cserélné a gépen kívülről jövő színre a NICK színét. Na de ez a hajó elúszott, vagy hogy is fogalmazzak.
Amúgy igen, ennek a memóriának a Z80 felőli elérése nem lassítja a CPU-t. Most ronda módon ha a Z80 ír/olvas, akkor a videótól egyszerűen elveszem a RAM-ot arra az időre, így ilyenkor a kép szépen "havazik", ha már a természet nem képes erre Karácsony után, legalább a feeling legyen meg.
Ezzel a programmal meg lehet jeleníteni ilyen képet, de természetesen nem tudtam kipróbálni azon kívül, hogy nem fagy le:
(Attachment Link)
(Attachment Link)
Konvertálás:
epimgconv -mode 4 -size 184 276 -quality 1 -scale 4 1 -outfmt 1 file.jpg 736x276.pic
Az egyik paletta szín átlátszóvá is tehető a forráskód elején a TRANSPARENT_COLOR állításával.
Egy gyors teszt, bár lehet (?) hogy nem a legjobb képet választottam alanynak:
A lila-hibát ezen is mintha látnám...
Itt is zizeg néhány pixel a képen, nem csak a RAM-szemétnél, de ez is várható volt tulajdonképpen. Viszont a tippelt időket tologatva, továbbra is változatlan a zizegés, amit azért furcsállok. Lehet hogy a géppel is van valami nyűg? (Annak idején nézegettem ezt, mintha Zozo rakott volna fel egy olyan tesztprogramot, ami sima 1 pixeles pöttyöket pakolt volna ki a képre. Mintha ott is "hunyorogtak volna a csillagok", de ezt betudtam a sok D/A-A/D átalakításnak, nem rendes CRT-n néztem.)
Az is egy lehetőség, hogy a háttér legyen külső, a sprite pedig normál NICK grafika (szerk.: ez csak 16 színű módban működne jól, ahol a NICK pixelek átlátszóak lehetnek ha a felső 8 színt használnák). A már meglevő hardvert valószínűleg könnyen lehetne módosítani, hogy a kép scrollozható legyen, ha a számlálókat 0 helyett programozható értékekkel töltené újra.
Ez a "pixel-prioritásos" dolog is tesztelendő amúgy.
A szkrollozást pofon-egyszerű lenne megcsinálni (mint ahogy a kiírási pozíció visszaolvashatóságát is), csak most csináljak látványos finom-szkrollt egy teszthardverben a többiek idegeinek a borzolására?
