Arról még nem írtam, hogy nekem milyen ötleteim vannak... Első körben én ezt viszonylag egyszerűnek képzeltem el, ezért is készült a jelenlegi teszthardver. Ami "alapjaiban" meghatározza a lehetséges megoldást, az az, hogy direkt "sprite-generátor"-t nem gondolnám, hogy lehet kapni...

Az elképzelés annyi volt, hogy van egy szép darab RAM, mint most, annak minden egyes BYTE-ja megfelel 1-1 nagy felbontású pixelnek a képen. Persze a 8 bitből csak 4 + 1 van használva, így 16 lehetséges "szín" van, illetve a "láthatóság" kapcsolható. Ez így tulajdonképpen egy sima "frame buffer". Magának a RAM-nak a buszrendszere úgy lenne felépítve, hogy a NICK Dot-Clock (ami 14.xxx MHz) dupláján futna, és 16 bites lenne, emiatt a sávszélesség a NICK felé szükséges adatmennyiség négyszerese. A fennmaradó RAM időben a Z80 dolgozhat, de ebből a sávszélességből csak néha-néha kell neki egy-egy ciklus, szóval marad szabadidő bőven. Ezt eddig egy nagyobb CPLD-vel meg lehet csinálni.

Na de hogy lesz ebből sprite? Ide lehet "csempészni" egy kis EP-s logikát. Mivel a sprite pixel-adatait a bővítés memóriájába kell másolni, ebbe a memóriába létre lehetne hozni egy SPT-t. Ami SPB-kből állna. Azaz: lenne egy Sprite Parameter Table, amik Sprite Parameter Block-okat tartalmaznak. Ezek a blokkok egy-egy sprite adatait írnák le: hol van a "bitmap" a memóriában, milyen pozícióra kell kirakni a képen, milyen üzemmódban, stb. Ezt a SPT-t meg egy combosabb mikrovezérlő dolgozná fel, a RAM sávszélességének a fennmaradó idejében pakolgathatná az adatokat. Beolvasna egy-egy SPB-t, az alapján felszedné a memóriából a sprite "képét", majd a megfelelő helyre odamásolná a "frame buffer"-be. Ennek a felépítésnek van egy olyan előnye, hogy tulajdonképpen nincs maximálisan megjeleníthető sprite-szám, hanem mozgatható adatmennyiség-korlát van csak. Magyarán kis méretű sprite-okból sokat, nagyobbakból kevesebbet lehet egyszerre kezelni. Illetve a sprite-ok mérete dinamikusan változhat, az egyik lehet ekkora, a másik meg amakkora.

A sprite-ok megjelenítési prioritását én meglehetősen egyszerűnek képzelem el: ha több darab is egymásra kerül, az fog a végén látszani, amelyiket utoljára pakolt ki, azaz később következik az SPT-ben.

Természetesen van a megoldásnak "árnyoldala" is. Egyrészt ha meg van jelenítve a kép, a következő frame-et "takarítással" kell kezdeni, illetve a sprite "megjelenítés" maga nem real-time: elindítod az SPT feldolgozását, aztán valamikor kész lesz. De ez tervezhető dolog. Aztán ha kell sprite-sprite ütözést is tudni vizsgálni, akkor az új sprite kipakolása előtt vissza kell olvasni az adott helyen levő adatot a frame-bufferből, ami a RAM sávszélességét fogyasztja.

Nagyjából ennyi volt az elképzelésem, és ekkor jött a teljesen önálló külső kép, mint kívánság... Azt nem mondom hogy borít mindent, de - mondjuk úgy - nem egyszerűsíti a helyzetet. A sprite-háttér ütközést ezzel már lehetne vizsgálni, csak vagy ott is olvasom a "háttér" adatait is, vagy ezt meg a megjelenítéskor tudom csak jelezni, immár real-time. Ami egy kicsit kilóg a logikából.

Ha ezt a µC-es feldolgozást csinálnánk, annyi előnye mindenképpen lenne, hogy tulajdonképpen csak program kérdése, hogy milyen lehetőségek vannak, lehet egy csomó fajta formátuma a sprite-oknak a 2 színűtől kezdve a nagyításon keresztül tulajdonképpen bármeddig.

Maga a hardver viszont a plusz "háttér" layer-rel kezd kilógni egy CPLD "komfort-zónájából", emiatt szóba jön ide egy valamilyen FPGA, csak azt még egyelőre nem "faragtam". De ha már FPGA, ott is van egy csomó lehetőség, akár külső µC felhasználása nélkül is. (Csak még alapabb eszközökkel kell megcsinálni a dolgot.) Jelen pillanatban nem tudom, hogy melyik verzió lenne a célravezető (Kombináltan mindkettő? ), van mit mérlegelni.

Egyébként ha jól értem a dolgot, akkor a legnagyobb gond a párhuzamos memória elérések megoldása.
Amúgy meg csak egy nagy rakás számláló, tól/ig beállításokkal

A fenti megoldás "eliminálja" ezt a problémát, nincs szükség a párhuzamos elérésre. Cserébe persze van más...

Ez az SPB, SPT ötlet nagyon tetszik, az, hogy meg lehet adni a sprite adat kezdetét, meg méretét főleg, sehol se láttam még ilyet, pl CPC-n fix címek vannak, és ha egy nagyobb sprite-ot akarsz, akkor több kisebből kell összepakolni, és gondolom az SPB tartalmazná a sprite x y pozícióját is.
A látható sprite-tal kapcsolatban, ha több sprite van ugyanazon a helyen ,vagy félig takarásban, kirajzolná az összeset, csak az utolsót jól rápakolná a többire, így lenne ami látható lenne a régebbiekből is?
Én úgy gondoltam/nám a sprite-ot, mint full képet, hogy ilyenkor a sprite hw csak a képet adná, esetleg ha van még elég hely a sprite memóriában, akkor lehetne még sprite-okkal is foglalkoznia, és az ütközésvizsgálat ilyenkor a háttér sprite-ban kikapcsolható, ne vizsgálja a háttér és egy sprite ütközését, ha az ütközés vizsgálat sprite pozíció alapján történik majd, ha pedig két sprite aktív pixelének találkozása alapján, akkor maradhat, de gondolom nem ez lesz, mert ehhez egy erőmű kéne.

Azert ne felejtsuk el, hogy itt ez egy hardware Mig emulatornal nagy szivas a sprite utkozes vizsgalat (lassu ...), hardware-nel nem lassit, mivel nem egy emulator/software ugye, es megoldhato, hogy minden parhuzamosan menjen, teljesen mas gondolkodast igenyel Bar ettol eroforrast nyilvan kovetel, ami jelen esetben a komplexitast jelenti inkabb, talan nem veletlen, hogy C64 VIC-II-nel is a chip felulet jo 3/4-et a sprite kezeles viszi el

Azert ne felejtsuk el, hogy itt ez egy hardware Mig emulatornal nagy szivas a sprite utkozes vizsgalat (lassu ...), hardware-nel nem lassit

egy mai pc-nek nem hiszem hogy akár több tízezer ilyen sprite ütközés vizsgálata gondot okozna (pixel pontosan természetesen)

Megis, probalj meg nagyon pontos C64 emulatort irni egyszer, es merd le milyen PC kell hozza Meglepo lesz az eredmeny Pedig az emulalando cucc nem tul 'tapos' egy valami egy modern PC-hez viszonyitva ... Persze ebben nem csak a sprite utkozes van epp benne, de hidd el, sokat elvisz egy gyors CPU-bol is egy olyan muvelet, amit valami megcsinal hw-bol, neked meg egy linearis kodfuttatasra tervezett CPU-n kell emulalni, ami a valodi hw-en tok parhuzamos mukodesu, es hw-bol van megoldva.

hát írtam elég sok játékot, pixelpontos ütközésvizsgálattal is...
a lineáris kódfuttatás sokat nem számít, hiszen brutálisan gyors egy mai pc egy magon is.
meg hát ügye van sok proci mag, meg gpu mag is
c64 emulátorok is régóta vannak, ha jól tudom 100%-osak

jó de remélem lesz emu támogatás
amúgy megint csak azt tudom mondani hogy a konvertálás lehetőségét kéne szem előtt tartani egy ilyen hw készítésekor, mert tuti hogy akkor legalább pár konverzió születne ami használja...

Kicsit ott-topic, de: https://www.youtube.com/watch?v=h42neZVvoMY

A csavonak vannak erdekessegei, amikor pl egy MCU-val csinalt demot, real-time kodbol eloallitva a videojelet is (annyi RAM sincs, hogy frame buffere legyen), stb. Am itt most nem errol  van szo, hanem: vegulis egy Commodore One-bol kiszedte az egyik panelt (de most mindegy is persze, hogy az honnan van), ami lenyegeben magaban egy Cyclone III FPGA (ami nem is tul modern darab ma mar, mondhatni ...). Aztan abban implementalt maganak egy gepet szepen es irt ra demot Nekem tetszik. Persze a latottakbol kikovetkeztetheto, hogy valoszinu egy teljes erosen bovitgetett EP CPU-stul Nick-estul mindenestul is siman beleferne Bar ez mar megint egy masik project, nem epp "csak" a sprite/stb generalas kivulrol.