De egy ekkora teljesítményű szutyokkal vagy sprite -ot csinálsz vagy scrollt ... ez egyértelmű ...

A 4+1 láb a külső színbemenet,

Mellesleg hogy lehet 5 bittel sprite -ot csinálni ? Az még egy pixelhez is kevés ... Max egy színkomponens, de hát akkor is max 16 árnyalata lenne egy komponensnek ...

A cuccodnak meg gondolom van ramja, az be tudná fogadni a 256 (minimum! ) színű, 8 bit palettás sprite -okat ...

4 szín módban és felbontásban is 16 színes a sprite?

Na az nem volna sámedi ... 4 színű módban, soronkénti LPT -vel, 16 színű, háttérrel is állítható prioritású, 256 darab, 256x256 pixeles, utközéstesztelt sprite ...

16 színű sprite lehet

Legegyszerubb megoldasban a sprite pl egerkurzorkent is tok hasznos lenne, de ez persze a legelemibb es legegyszerubb feature (nem tudom hogy pl MOUSE.XR-be lehetseges lenne-e beleirni hogy ilyen kulso sprite cuccos eseten rakja ki az egerkurzort, vagy a mouse.xr is relativ koordinatakat kap es csak az sw konvertalja konkret pozicioval? mert ha igen, akkor ez kevesbe menne ...), nyilvan uj dimenziok nyilnanak a rendszer elott

Amugy, ha a kerdeses MCU-nak eleg RAM-ja van ami EXTCOL labakat rangatja, akar teljes kepet is betehet, igy pl akar nagy felbontasu 16 szines mod is menne, es kozben a nick sajat maga is azt csinal amit akar. Erdekes jatekokat lehetne irni, pl hatteret a kulso cucc adja, gorgeti stb, az eloteri dolgokat meg a Nick. Bar ez kb pont nem a sprite feature hanem az ellentete ...

Ez nekem is eszembe jutott, de teljes képhez nincs elég RAM benne. Lehet rá valami soros SRAM-ot tenni, de az nem tudom elég gyors lenne-e...
Majd kiderül. A 2-es verzióba 512K belső RAM-ot igérnek, az már elég lenne

Ez nekem is eszembe jutott, de teljes képhez nincs elég RAM benne. Lehet rá valami soros SRAM-ot tenni, de az nem tudom elég gyors lenne-e...
Majd kiderül. A 2-es verzióba 512K belső RAM-ot igérnek, az már elég lenne

Nem tudom segit-e, de lattam egy allati otletes dolgot, amikor AVR-rel csinaltak pont 16 szinu VGA kepet. Lehet kapni un quad-SPI memoriat. A lenyege, hogy SPI buszon elerheto SRAM (vmi 27L vagy igy kezdodott a neve nem tudom). Ugye egy atlag MCU-nak van SPI busza, nem gond. Az otlet lenyege azonban nem ez, hanem az, hogy hogy ezt a kerdeses memoriat fel lehet ugy programozni hogy "streamelje" szepen a tartalmat az output-ra (csak leptetni kell ugye), es attol "quad SPI" hogy a normal SPI-hoz kepest 4 bitet ad ki magabol parhuzamosan egyszerre, es nem 1-et. Ez ugy mukodott az otlet kitalaloja szerint, hogy a fenti erdekes RAM-ot tudja irni az AVR amikor visszafutas van (azaz kimenet miatt nem kell), amikor meg lathato sor, akkor addig nem nyul persze hozza az AVR, felprogramozza hogy adja szepen az adatokat, amit CLK signal-al nyomat. Nekem nagyon tetszett az otlet, mivel az eredeti AVR-VGA projectnel az AVR hatarait veszegetjuk, itt egy kulso SRAM-al viszont a dolog nagy reszet magatol csinalja! Plusz a RAM kapacitas is lehet nagy, az MCU sajat RAM-ja altalaban limitalt. A 4 bit meg gyanusan pont jo lenne ide is (az igaz, hogy jo lenne egy 5. is, ha nem teljes kepet akarunk, vagy esetleg a 16 kombinaciobol pl a 0-at kinevezni annak hogy ott nincs adat, es akkor color == 0 -> nincs kulso colour info algoritmussal eloallitani egy logikai kapuval a jelet az EP szamara mint 5. bit).

Nem tudom segit-e, de lattam egy allati otletes dolgot, amikor AVR-rel csinaltak pont 16 szinu VGA kepet. Lehet kapni un quad-SPI memoriat.

Izgalmas ötlet!

Van beépítve valami beépített videogenerátor is, VGA módban 8 bitet tol ki, az elég 5 bitre Csak kérdés, hogy rá lehetne-e szinkronizálni a Nickre.
Gondolom, az általad említett megoldást léptethetné a Nick órajel.

Mondjuk te attól még csinálhatnád a programot úgy, hogy a felhasználó mondhassa meg a darabszámot is, meg sprite -onként a szélességet magasságot is,
és majd a felhasználó gazdálkodjon a memóriával ...

Ez már szerintem csak részlet kérdés

Előbb majd el kell jutni oda, hogy legalább egy pixelt sikerüljön kirakni oda, ahova akarjuk