Ismét továbbgondoltam a fejlesztést, összegyűjtöttem ezeket a gondolatiamat.

A grafikában egy objektum ráhelyezése egy meglévő háttére úgy történik, hogy az alakzat pl. labda  egy téglalap alakú vászonra van rárajzolva, és ugye az alakzaton kívüli pixeleket nem akarjuk a háttérre másolni. Ezért létezik egy ún maszk, amely ugyanolyan pixel méretű mint az eredeti kép, és azt adja meg melyik pixeleket kell másolni.
 Fejlettebb rendszereknél ez a maszk nemcsak 0 és 1 lehet, hanem áttetszőséget is lehet szabályozni: pl. kék vízesés átlátszik. Ennek a szakkifejezése "alpha blending".
 Vannak rendszerek ahol megspórolták a maszkot, és kijelölték az egyik színt láthatatlannak, a többi pedig felülírja a hátteret.

 Azokon a rendszeken, ahol nincsen beépített sprite vezérlés, a processzor elkészíti vagy átmásolja a hátteret a video memóriába, majd erre rámásolja a mozgó tárgyakat akár maszkot használva. A probléma az, hogy a felülírt hátteret vissza kell állítani a következő képen, hogy újra rákerülhessenek a tárgyak az új pozícióban. Minél magasabb a háttér felbontása és bitmélysége, annál több időt igényel a visszaállítás.

 Az már egy előrelépés lenne ha lenne egy scrollozható háttér, és egy olyan előtér amire felmásolhatóak lennének a tárgyak, így csak törölni kellene az előteret a következő képváltás előtt. Csak törlés alatt azt értem hogy nem kellene fenntartani a memóriában a háttérből egy érintetlen példányt amivel felülírjuk a módosított képet. A nick 2.0 pedig ezt a hátteret és előteret rajzolná fel egymásra.
 Nem gondolnám hogy két sorparaméter táblát kellene fenntartani előtérnek és háttérnek, de az is baj, hogy nem nagyon van hely LD3 adatmezőnek a sorparaméter táblában.
 Esetleg a nem használt módban az utolsó 8 byte szín mezőt lehetne felhasználni LD3 és akár további pointereknek.

 

Igazad van Zozo, csakhogy Tubynak azt a sprite kezelő logikát is meg kell valahogyan valósítania. Vagy legalábbis nekem úgy jött le, hogy nem egy kiegészítőt tervez az eredeti gépekhez, hanem egy teljesen új hardvert.

Kiderült, hogy nem azért sárga. Azért volt sárga, mert elrontottam a PC-re C-ben írt kép konverter programot.

A hétvégén kicsit programozgattam. Találtam egy képet a neten, ami 24 bites színmélységű, és gondoltam átkonvertálom. Először borzasztó lett (lásd csatolmány). Ennek az az oka, hogy ahol 24 biten színátmenet van, ott a 8 bitesre levágás miatt sima egyszínűt ad.
 Ekkor kezdtem keresgélni, hogy milyen matematikai megoldással lehet "dithering"-ezni. Kétféle megoldás van, az egyik a 2x2 vagy 4x4-es mátrix alapú (mint kiderült nekem nem jó, mert sormintát hagy a képen), vagy pedig a Floyd-Steinberg eljárással, amit szerintem mindenki ismer.

 Már majdnem elkezdtem írni a programot hozzá, amikor kiderült, hogy ha Photoshop megkapja az "indexelt színlistát", melyet az EP tud, akkor ő is elő tudja állítani a ditherelt képet.
 Elkezdtem kézzel felvenni az EP színeket a phtoshop-ba, majd a 19. szín után (237 van még hátra) rájöttam, hogy az úgyis egy fájlba menti, megnézem a formátumát. Kiderült hogy nagyon egyszerű, mert egy indexelt színhez 3 darab Byte tartozik (piros-zöld-kék), majd a lista legvégén megadja hogy hány valid (használt) szín van. Írtam rá egy kis programocskát, ami létrehozta az EP 256 színét.
 Ezután a 320x240-es (lekicsínyített, de továbbra is 24bites) képre elkészítettem a dither-elt változatot. Ezt utána betöltöttem a módosított EP emulátorba.
 Kicsit változtatni kellett a Basic betöltőmön, mert a kép 320*240*1byte= 76800 Byte =  75kB, ami már nem fér el 4db "video" lapon, a basic betöltőm nem állt készen a 5. 16kB lapra. De pár órás hibakeresés után megcsináltam.

 Rendszer:
Enterprise Emulátor 256 kB (F0-FF szegmensek) - RAM amely a NICK 2.0-nak teljes mértékben címezhető a Graphics hires 4 képpont méretű, de 256 színű módban.
A képet az F4 szegmenstől F7 szegmensekig tároltam, majd amikor növeltem a függőleges megjelenítést, akkor az F8 szegmenset is felhasználtam.
Alapvetően a rendszer az 1. szabad szegmenst használja (az én esetemben a F0) ezért azt nem is bántottam.
A video memóriába sem akartam írni (FC-FF), mert azt felül szokták írni a grafikai rutinok.
 Azt csinálja a Basic betötőm, hogy nyit egy video lapot a képernyőre (mint helyfoglalót, amit nem változtat meg a rendszer) majd ennek módosítja a sorparaméter tábláját.
Ennek előnye, ha bármi gond van, akkro nyomok egy SHIFT+F5-öt és visszakapom a szöveges módot, látom a hibaüzeneteket stb.

Újabb dolgon töröm a fejem, a scrollozást kellene javítani hardveres támogatással a NICK 2.0-ban.

Abból indulok ki, hogy egy teljes képernyős grafikus képet az LPT egyetlen blokkjában mint 240 soros grafikus kép deklarálnám.
Az adatmező memóriacíménél megadom, hogy hol kezdődik a memóriában, ahogyan a klasszikus NICK ezt tudja is.

Szeretném viszont megrajzolni a pályát a memóriában sokkal nagyobbra, mint amennyit a képernyő mutatni tud. Majd a látható képet mozgatnám "eltolás" byte-okkal. Az elotlás max akkora lehet mint a megrajzolt "nagy kép". Ezt sem x sem y irányban nem tudom 1 byte-on ábrázolni, legalább 1 byte és 1 bit kellene, de akkor már lehet 2 byte.

 A csatolmányba tettem néhány képet. A fekete vonalak a byte-okat jelentik a memóriában, ami egy hatalmas "hátteret" ír le. Minden új sor a kép új pixelsorát jelent, az egyik sor vége és a másik eleje egymás mellett vannak a memóriában. (mintha Asmon dump lenne).
 A piros négyzet a képernyő mérete által megjelenített byte-okat mutatja. Minden ami a piros négyzeten belül van, az meg lesz mutatva a képernyőn. Ami kívül esik, az nincs megmutatva, de elő van készítve.
 Azért lenne jó így csinálni, mert a piros képernyő mozgásakor a Z80-nak egy ideig semmi dolga nem lenne azon kívül, hogy lépteti a NICK eltolás vektorát. Közben előkészítheti a képernyőtartalmat a háttéren annak tudatában, hogy a játékban éppen merre járunk. Ezzel sokkal finomabb mozgást érnénk el, illetve csökkentenénk a Z80 munkáját.

 Az első képet megnézve látszik, hogy a klasszikus Nick ezt nem tudja a poszt elején említett egysoros deklaráció mellet, mert nem "ugorja át" a piroson kívül eső sorokat. Van ugyan rá lehetőség, de akkor sajnos minden pixelsort egyenként kellene a sorparaméter táblában deklarálni, ami akkor 240sor * 16byte = 3,75KB lenne. Ezt a 240 sort írogatni is kellene. Sok munka a Z80-tól.
 Másik dolog, hogy amikor a háttér egy sorának végéhez ér, akkor nem az utána következő sort kellene betölteni, hanem ugyanazt. (2. és 3. kép a csatolmányban)

Tehát az egyik újítás a NICK 2.0-nál ez lenne, hogy meg lehetne adni teljes háttér-szélességet, hogy a következő sor kezdőcímét ki tudja számolni az előző alapján: hozzáadná a háttér szélességet az előző sor kezdőcíméhez.
Ugyanezt megadjuk az pixel oszlopok miatt.

Tehát a sorparaméter tábla blokkja így nézne ki:

F900: x00 x01 x02 x03 x04 x05 x06 x07 x08 x09 x10 x11 x12 x13 x14 x15

x00: sor magassága (2-es komplemens) - innen jön a látható kép magassága
x01: sor módja (Nick 2.0 hires 4, 256 színnel -- 1 képpont=1byte)
x02: bal margó
x03: jobb margó (ebből a két értékből kapja meg a NICK a látható kép szélességét)
x04: kép kezdőcíme memóriában alsó byte
x05: kép kezdőcíme memóriában középső byte
x06: kép kezdőcíme memóriában felső byte (összesen 24byte - de nincs mind használva)
x07: foglalt/tartalék
--- itt kezdődnek a színdeklarációk, mivel 256 színnel dolgozunk, nincs szükség színre, elhasználjuk másra
x08: kép kezdőcím eltolása x irányba alsó byte
x09: kép kezdőcím eltolása x irányba felső byte (ezt kell növelni/csökkenteni a Z80-nak ahhoz hogy vándoroljon a látható kép X irányban)
x10: kép kezdőcím eltolása y irányba alsó byte
x11: kép kezdőcím eltolása y irányba felső byte (ezt kell növelni/csökkenteni a Z80-nak ahhoz hogy vándoroljon a látható kép Y irányban)
x12: háttér kép x mérete szorozva 2
x13: háttér kép y mérete szorozva 2 (azért kell a szorzás, hogy 8 biten ábrázolni lehessen max: 512-t)
x14: foglalt/tartalék
x15: foglalt/tartalék


Gyors számítás: ha háttér kép mérete 512x512 és képpontonként 1 byte (256 szín), akkor a háttérhez 512*512*1= 256k memória kell
Ez rengeteg, de a címbusz kiterjesztésével lehetséges.
SRAM használatával pedig a Z80 késleltetés nélkül képes a videomemóriába írni, ezzel minden követ elgörgettünk, hogy gyönyörű EP játékokat játszhassunk.

... ezzel minden követ elgörgettünk, hogy gyönyörű EP játékokat játszhassunk.

A CPU meg legyen min 10MHz és legalább 2db.
Talán a bírnák az a mennyiségű másolást bájt mozgatást.
~LDIR (bájt*5)+4 /CLK 256*1024*5 1310720 clk , 4MHz 1sec 1000000

Sajnos nem. Legfeljebb gyönyörű EP 2.0 játékokat. Kérdés, hogy hogyan lesz mindenkinek ilyen gépe és ki fogja írni azokat a játékokat?

Igazad van. Még ha lehetséges is lenne Nick és Dave továbbfejlesztett verzióit elkészíteni, csak néhány demó használná ki ezeket.

Nézd meg például a gigantikus Spectrum jelenetet, az ULA+ és az alternatív videomódokkal, amelyeket FPGA magokon lehetne megjeleníteni. Szinte nincs olyan program vagy játék, ami hasznot húzna belőlük.

És mégis, több trükköt húznak ki a stock gépből, mint valaha.

---

You are right. Even if it were possible to make improved versions of Nick and Dave, only a few demos would take advantage of them.

Look at the gigantic Spectrum scene for example, with ULA+ and alternative video modes that could be displayed on FPGA cores. There are almost no programs or games that could take advantage of them.

And yet, more tricks are being pulled out of the stock machine than ever before.

A CPU meg legyen min 10MHz és legalább 2db.
Talán a bírnák az a mennyiségű másolást bájt mozgatást.
~LDIR (bájt*5)+4 /CLK 256*1024*5 1310720 clk , 4MHz 1sec 1000000

Nem értetted meg szerintem a dolgot.

Ezeknél a régi gépeknél a max képfrissítés 25Hz (nem muszály ilyen gyorsan, lehe ennek a fele is). Ha 25Hz-zel scrollozza a képet 1 pixellel, akkor csak 1024 pixelt kell kirajzolni oszloponként erre van 1/25Hz=40ms ideje.
 Ha nem így csinálnám, hanem a teljes kép átírást választanám, akkor a CPU-nak 320x240 kép esetén 76.800 pixelt kellene kirajzolnia.
 Melyik a jobb 76k pixel kirajzolása vagy 1024db ?