AVR Spielekonsole Kapitel 2

Hallo! Vor 7 Monaten habe ich mal einen Thread gestartet zum Thema Spielekonsole mit AVR. Quintessenz war am Ende ein Konzept mit einem ARM und ein wenig TTL, dass ich schnell fallen lassen musste. Bin nach Berlin umgezogen und Zeit fehlte auch. Nun bin ich wieder am Thema und auch um einiges schlauer. Ich habe recherchiert wie die alten Konsolen (Atari 2600) oder NES mit weit weniger Leistung als ein AVR das alles hinbekommen haben. Der Atari2600 ist wohl einer der genialsten Vertretern. Die Idee von vor 7 Monaten beinhaltete noch ein memory-mapped konzept. Also ein Bild das im RAM fertig ist darzustellen. Das klappt mit AVRs einfach nicht oder nur bei winzigen Auflösungen und Monochrom. Der Atari2600 macht das anders. Hier gibt es kein RAM das irgendwelche Bilddaten enthält, sondern nur ein paar register. Die GPU malt strikt ein TV-Bild vor sich hin und die CPU schubst es immer an wenn mal ein Pixel kommen soll oder eine bestimmte Farbe. Genauso kann man eine einfache Konsole mit 2 AVRs realisieren. Ein AVR malt immer ein Bild. Es gibt immer einen austausch zwischen CPU und GPU wenn z.B. das Bild neu gezeichnet wird, oder eine Farbe gesetzt wird. Das kann man mit wenigen Bits realisieren und ist verdammt schnell. Damit sind große Auflösungen und Farbtiefen möglich...z.B. 128x96 Pixel bei 8 Farben. Man muss eben nur beide ICs immer gut synchronisieren und man muss wissen wo die GPU zu welcher Zeit im TV-Bild rumwuselt. Man hat dann immernoch genug Raum für ein paar Sprites (bewegte Bildchen) oder Textzeichen. Mehr Zeit spart man noch wenn man kein FBAS sondern ein langweiliges RGB+Sync Signal erzeugt. Das läuft eigentlich auf jedem moderneren (ab 1995 sicher) TV-Gerät. Was haltet ihr von der Idee? Seht ihr große Stolperfallen?

so etwas habe ich vor. da ich hardwaremässig nichts am hut habe, lasse ich mir zur zeit eine gesamtplatine anfertigen , wo drauf ist : 2x atmega644 20mhz , 1x atmega8, 1x ps2-tastaturstecker, 1x fbas-steckbuchse, 1x mc/sd-kartensteckplatz, 1x display 2x16zeilen, 1x rs232-schnittstelle zum pc. das wars.
daran werde ich meine video-kenntnisse oder nichtkenntnisse austoben lassen.

mfg

Hallo,
ich bin vor wenigen Wochen mal auf den Propellerchip gestoßen. Mit diesem Chip gibt es auch eine Spielekonsole mit Namen Hydra. Vielleicht ist die ja was für Euch - es sei denn ihr steht mehr auf die eigentliche Entwicklung.
Leider sind mir die Links verloren gegangen. Aber googeln dürfte helfen.
Gruß
Stefan

das hydra board für den propeller chip wird auch in (ich glaube) der neuesten elektor vorgestellt
ist ein set mit handbuch und erklärung wie man denn spiele programmiert und natürlich dem chip auf nem board mit vga-anschluss und tastatur und maus und noch viel mehr

Ich muss gestehen, ich hab den letzten Thread nicht verfolgt.

Aber mir brennt grade eine Frage: Wie soll denn das mit der Programmierung der Spiele funzen?
Ergo, wie lädt man ein Programm von einer externen Datenquelle zur Laufzeit in den AVR? Die Dinger führen ihr Programm ja direkt vom Flash aus, also müsste man ja bei einem neuen Spiel quasi den AVR sich selbst neu flashen lassen, und das gäbe irgendwann sicher Probleme wenns zu häufig passiert.
(Na gut... mindestens 10000 mal verschiedene Spiele spielen, wird ne Weile halten)
Aber Prozessorarchitekturen ohne integrierten Flash wären ja doch wesentlich praktischer.
(Spiel von Speicherkarte/Datasette O:) etc ins Ram laden -> Programm vom Ram aus laufen lassen)

Ich denke mal, dass z.B. auf ner SD-Karte die Spieledaten gespeichert sein sollen (Grafiken, Welt, Figur, etc). Der AVR liest dann erstmal die Grafikdaten ein und verarbeitet sie um sie auszugeben auf dem Monitor/Fernseher/Display. Dann nimmt er die Daten des Eingabegerätes an (zb. Tastatur oder Joystick) und verändert entsprechend den Daten aus dem Eingabegerät die Anzeige.

Also z.B:

Zeichne Figur an Pos. X --> Nimm Tastaturdaten (pfeil nach vorn) --> lösche bildschirm --> zeichne Figur an Pos. X + 1

usw. So oder so ähnlich könnte ich mir das vorstellen...

Mfg.
Lemon

Hehe ihr denkt schon ein bisschen zu weit. Spiele von einer SD-Karte zu lesen ist einfach nicht performant genug, da die Befehle ja interpretiert werden müssen.
Die Konsole könnte aber aus nur einem AVR bestehen, nämlich den Grafikchip, und ein Spielmodul enthält dann eben die CPU.
Ich denke die GPU könnte aus einem ATMega8515 bestehen mit 16kb SRAM welchen man nach dem starten mit Sprite-daten befüllen kann.
Schaut euch ruhig mal die funktionsweise des Atart 2600 an.
Mit 256 Byte RAM kamen da schon ne Menge guter Spiele bei raus.

Mein Ziel ist es mit winzigem Aufwandt eine gute Plattform zu entwickeln.
Kein SMD-Löten und auch kein Propeller Chip ;)

Der Propeller ist ein guter Multi-Core Controller, allerdings ist die Technik einfach nicht ausgereift. Man bendenke er besteht aus 8 Cores (Cogs) die man mit bis zu 80Mhz Takten kann.
Das sind astronomische Leistungen, und viel zu schade für einen Atari-Clon. Als DSP oder ähnliches sollte man so einen guten Chip einsetzen.
Noch dazu ist es einfach...zu einfach eine Konsole damit zu bauen. Paar Widerstände, Kondensatoren und Buchsen dran und fertig...fertige Libs für VGA und FBAS? Wo bleibt denn da noch der Spaß?
Aber wer daran Spaß hat gern. Aber bitte dann mit Assebler programmieren und nicht mit Sp!n.

Das größte problem macht eigentlich der Aufbau der GPU.
Ein Bild 128x96 Pixel bei 16 Farben ergo 4 bit ist 6kb groß.
Es gibt, glaube ich, keinen AVR mit einem so großen internen RAM.
Folglich kann nur ein Mega8515 mit externem Speicherinterface eingesetzt werden an dem dann ein entsprechendes SRAM dranhängt. Jede Operation der GPU muss aber schnell genug sein um min. alle 5 µs ein Signal an den TV geben zu können (und das ist auch fast schon zu lahm).
Ein SRAM mit 100ns wäre schon kritisch. 55ns gerade noch im Bereich des möglichen. Einen SRAM mit 35ns Ansprechzeit für normale Preise habe ich noch nicht gesehen.

Ich bin mir nicht ganz sicher wie der TIA im Atari2600 die Bilddaten speichert. Schließlich muss das Bild ja auch wenn die CPU mal keine Befehle schickt angezeigt werden.
Auch die Speicherung der Bilddaten stellt wieder ein performance Problem dar. Den SRAM schnell genug ansprechen und einen Pixel im 6kb großen Bild zu speichern und dann noch das Signal an den TV schicken...uiuiui.
Hat jemand eine Idee?

Zitat:

---

Hehe ihr denkt schon ein bisschen zu weit. Spiele von einer SD-Karte zu lesen ist einfach nicht performant genug, da die Befehle ja interpretiert werden müssen.

---

ihr sollt nicht rumlabern, kauft euch ein board oder baut euch mal eins zusammen, dann können wir uns wieder unterhalten. so aber vorläufig nicht.
es gibt auf der welt zuviel theoretiker , die vor geiz alles kaputtreden.


dieses hydarboard habe ich. geht gut ab. musste 220 euro dafür hinlegen. wenn ihr es testen wollt kauft euch das ding und lasst euch vor geifer nicht immer die spucke im mund zusammenlaufen. wer ein hobby hat redet nicht, sondern führt es aus und kauft sich einfach die teile...pong..

...lol...

.....Der Propeller ist ein guter Multi-Core Controller, allerdings ist die Technik einfach nicht ausgereift. Man bendenke er besteht aus 8 Cores (Cogs) die man mit bis zu 80Mhz Takten kann......

ich habe es.
die technik ist ausgereift und mit den 8 core kannste dinge machen, die du noch nicht ein mal im traum erlebt hast.

aber ich möchte es mit meinem board und dem atmega machen.

Hallo junk_sandy,

ich glaube das hier würde Dich interessieren : http://www.mikrocontroller.net/topic/54562#new
So kann man sogar die ganze Konsole mit nur einem Controller realisieren.

MfG Mark

@roboterheld:

das ist ja schön was du alles hast. du bist auch sicher nicht der einzige der mal mit dem propeller chip gearbeitet hat.
ich kann sehr wohl sagen, dass dessen technik nicht ausgereift ist.
Man kann sehr viel damit anstellen. Aber von 8 Cores bei 80Mhz, die pro Takt 2 Befehle verarbeiten, sprich 160MIPS erwarte ich mehr als eine Konsole die gerade mal einem C64 oder NES oder so, das Wasser reichen kann.
Echtzeitmessung + Ausgabe kann man damit wirklich gut realisieren. Einen DSP hab ich mal damit gebaut und das war nen Traum, da fast alles von Software lief.
Aber das Ding ist einfach noch zu sehr Spielzeug, und mit einem FPGA hab ich für die Bereiche immernoch mehr Freiheiten.

Wer aber einfach nur schnell ne Konsole klöppeln will und lieber schnell ergebisse sehen will ist mit dem Propeller besser beraten.

Wenn du versuchen willst ein Programm von SD-Karte zu interpretieren, wünsche ich dir viel Glück.
Ich bin gespannt wie du die wenige Performace die du hast so weit auszureizen willst, dass du Spiellogik und Grafikausgabe (und evtl. noch sound) gleichzeitig relaisierst.

Das mag ein wenig zynisch klingen, aber ich habe das Gefühl, nimms bitte nicht persönlich, dass du jemand bist der schneller Geld ausgibt für etwas, an dem er schnell die Freude verliert und es liegen lässt. Das ist kein Hobby!
Hobby ist wenn du trotz aller Schwierigkeiten mal zum Lötkolben greifst und dein Board selber lötest, äzt, verdrahtest usw. Wenn du trotz aller Umstände der Liebe zum Hobby Vorrang gegenüber dem Aufwandt gibst.

Hier eine Spielekonsole mit nur einem Atmega32:
http://instruct1.cit.cornell.edu/cou...kfm9/index.htm
Und ein schöner kleiner Computer mit Farbausgabe:
http://www.jcwolfram.de/projekte/avr...sic32/main.php
auch mit Atmega32

Wie man sieht:
Mit Gehirnschmalz geht's auch mit weniger Aufwand als mancher "roboterheld" sich so denken kann.

Und ohne Ausprobieren, Basteln, Denken und darüber diskutieren, macht doch das ganze hobby keinen Spaß.

Gerümpel zusammenkaufen und im steckkastenprinzip zusammenbauen heißt LEGO (nix gegen lego jetzt an der Stelle), aber das kann jeder ...

Selbermachen, vor probleme stoßen, diese diskutieren und lösen, dass ist doch der Spaß an der Sache hier, oder!?!

Sorry, dass ich das jetzt hier so "OT" in deinen Thread reinschrei, @junk_sandy, aber das musste mir jetzt einfach mal von der Zunge ;)

Mfg.
Lemon

Zurück zum Hobby :

Dieses BASIC-Gerät ist wirklich klasse! Mich würde interessieren wie schnell das läuft.
In Farbe und bunt ;)

Sicherlich eine gute Grundlage für eine Spielkonsole.

Was denkt ihr über den Mega8515 als GPU? Ich habe bedenken, dass er den SRAM schnell genug ansprechen kann um noch ein Bildsignal zu generieren.

http://www.atari-gamer.de/atari_2600.htm

Hier wird der Aufbau und die Programmierung des Atari2600 beschrieben.
An dem Gerät soll sich das Projekt ja orientieren.
Das dumme ist nur, dass das Tutorial zur Programmierung da aufhört wo es anfängt Spannend zu werden, nämlich was man tun muss um einen Pixel darzustellen.
Ich werde weiter recherchieren und dann gibt es bald die AVR-Spielkonsole.

Mich würde interessieren was ihr über mein Konzept denkt.

Also:

Mega8515 + 55ns - SDRAM-Chip als Grafikeinheit

Die CPU ist dann sozusagen auf der Spielkasette und enthält Spieldaten + Zeichensatz oder Grafiken.
Beim Booten werden die Grafiken im RAM der GPU abgelegt.
Man bräuchte einen kleinen Befehlssatz um die GPU anzusteuern.
Wir gehen davon aus, dass CPU und GPU genau synchronisiert sind, und wir wissen immer wann eine Bildschirmzeile anfängt und wo wir uns überhaupt im Bild befinden muss man eben ausrechnen.
Da ich als Ziel ja 16 Farben angestrebt habe, müssen wir immer Timing-Genau einen 4 bit Wert übermitteln. Also verbauchen wir einen halben Port für die Dateneingabe.
Kommt dann so ein halbbyte an, malt die GPU den Pixel und müsste im RAM ebenfalls den Wert dafür setzen.
Kommen keine Daten von der CPU malt sie einfach weiter das was im RAM gesetzt ist. Jetzt merkt man schon, dass der RAM verlflucht schnell sein muss. Wieviel Takte man für so eine Aktion braucht weiß ich nicht genau. Aber es darf höchstens 64 µs dauern ;)

Der TIA-Chip im Atari hat das irgendwie über interne Register gelöst. So viel ich weiß hat das ding 32 8byte register.
Ich kann mir nicht vorstellen, dass darin ein Bild gespeichert wird.

Wenn ein Pixel nicht schnell genug gelesen-gemalt-geschrieben werden kann, könnte man auch einfach 2 Mega8515 nehmen. Die kommunizieren über irgendein bit und wenn der eine noch in den speicher schreibt kann der andere schon den nächsten pixel malen.
Das wäre aber eine ziemlich umfangreiche Arbeit, vor allem dann noch die CPU zu Synchronisieren und Daten für 2 GPUs bereit zu stellen.

Wenn ihr dazu noch Spinnereien habt oder irgendwas was euch dazu einfällt, immer her damit.
Ich brauch nen fertiges Konzept, die Teile liegen hier schon so erwartungsvoll rum ;)

Mir ist grade eingefallen:

Man kann tatsächlich 2 GPUs verwenden. Ein Chip malt das Bild der andere Schreibt in den RAM.
Sind beide fertig geht ein Signal an die CPU. So ist die Synchronisation auch recht einfach. Wird ein paar TTLs benötigen, multiplexen müsste man auch ein wenig, denn 32 IOs pro Chip gehen schnell zur neige ;)

Noch ein paar Anregungen mit den "Klassikern":

• PacMan
• Pong
• Bingo...
• oder auch Tetris (allerdings mit LCD)

Gibt sicherlich noch viel mehr davon... Nicht dass ich Dir die Motivation nehmen will :cheesy:

Gruß,
Tom

Ich überlege ob es sich nicht auch lohnen würde einen kleinen CPLD zu nehmen, der einfach das Bild malt und die Daten von der CPU ins RAm schreibt. Da ja die Funktionen darin sozusagen verdrahtet sind, wäre das eine schnelle lösung und da es die dinger ja auch im PLCC44 Gehäuse gibt wäre es noch gut realisierbar. Leider gibt es glaub ich nur 72 Macrocells in der Variante. Hoffentlich reicht das. Was meint ihr?

Bei der "Konkurrenz" gibt's einen Artikel zu den verschiedenen Möglichkeiten mit jeweils Links dazu, ganz unten auch was mit 'nem CPLD:
http://www.mikrocontroller.net/articles/TV-out

Gruß,
Tom

Was denkt ihr? Nen CPLD als GPU wär doch recht flott, oder?

Ich frage mich, was Dich noch aufhält... Du scheinst mehr Ahnung zu haben als die meisten, die hier antworten (mich eingeschlossen)... :cheesy:

In oben erwähntem Artikel ist ja auch eine CPLD-Lösung verlinkt, es geht also definitiv:
http://www.jcwolfram.de/projekte/vhdl/fbas_enc/main.php

Ok, hier wird der CPLD "nur" für die Erzeugung des FBAS-Signals verwendet, die Daten müssen dann trotzdem zeitgerecht angeliefert werden, aber eine komplette Grafikkarte mit RAM zu bauen geht prinzipiell schon auch:
http://www.ulrichradig.de/home/index...d/8bit_c_graka

Gruß,
Tom

Naja ich bin mir vor einem Projekt immer ein wenig unsicher.
Deswegen brauch ich immer etwas Feedback.
Ich werd erst einmal mit einem kleinen 72 Cell CPLD so ein Grafikdingens bauen nach meinem jetzigen Konzept.
Die Ergebnisse werd ich dann natürlich öffentlich stellen und ihr müsst euch das dann alle nachbauen und spiele dafür entwickeln ;)

Ich hab mir grad noch den alten Thread von Dir angeschaut, da stand das ja alles schon drin - inklusive der Grafikkarte von Ulrich Radig...
Nur hattest Du damals wohl noch eine gewisse Abneigung gegen CPLDs oder generell SMDs... :)


Ach ja, zum Thema was man noch so alles machen kann...

Die komplette Amiga-500-Hardware in einem FPGA:
http://en.wikipedia.org/wiki/Minimig
http://home.hetnet.nl/~weeren001/

Gruß,
Tom

Also ich persöhnlich finde die Lösungen ohne FPGA und nur mit Atmels ( vielleicht 1-2 ) besser, da man keinen spezielen Programmierer für das FPGA braucht.
Der Aufbau des Basic Computers aus den obigen Links find ich nicht schlecht: den kann jeder innerhalb von wenigen Stunden auf einer Lochrasterplatine aufbauen. Vielleicht lassen sich mehr Mitprogrammierer begeistern, wenn die Hardware sehr einfach und billig ist.

Gruß,
robo

Da ich mich gerade im Ideenrausch befinde, kam in mir ein weiterer Gedanke. Eine gescheite Konsole braucht eine gute CPU. Das ganze soll noch Lötbar sein und es gibt schöne PLCC-ICs wie z.B. den Motorolla 68000. Zwar würde man dann wohl Fädeltechnik nutzen müssen, aber immerhin ist es machbar. Ich bin immer ein wenig abgeneigt gegenüber SMD. Ich will immer alles auf Lochraster aufbauen, außerdem find ich sehen SMDs einfach doof aus wenn man ne Retro-Like-Sache macht ;) Achso...den 68000 kann man mit GCC programmieren, ist eine 16bit-CPU und läuft bei 10Mhz. Ihr kennt den IC bestimmt aus dem Sega Mega Drive oder dem Amiga. Grafikausgabe kann man mit kleinen CPLDs realisieren, die auch im PLCC-Gehäuse kommen. Auf das Board müssten nur noch ein paar RAM- und Cache-Bausteine und ein UART.

Achja in Sachen Kosten ist die idee mit dem 68000 natürlich mist. Die Dinger sind teuer. Eventuell wäre ein Z80 eine alternative. Der ist billig und verlässlich. Aber egal, ist ja nur der Ideen Rausch ;) In wie weit eine Grafikkarte mit einem oder 2 AVRs möglich ist weiß ich gar nicht. Ich kenne kein ähnliches Projekt. Wenn man nur 4 Farben statt 16 verwendet wäre man bei 3 kb pro bild. Ein Mega644 könnte damit umgehen. Allerdings sind 4 Farben etwas mikrig ;)

Nach einem entspannenden Wochenende ist die Idee nun komplett, und geht jetzt in die heiße Phase ;)

Hautpkern der "Konsole" wird ein CPLD. Dieser soll ähnlich funktionieren, wie die PPU im alten NES. In einem RAM werden Daten für Kacheln und Sprites hinterlegt.
Die CPU muss nur noch Daten für die Tile-Karte und positionen der Sprites an die GPU übermitteln. Da reicht ein I²C BUS aus, oder man nehme den SPI und hat immernoch viele IOs frei für jedweiligen Blödsinn \:D/

Wenn man sieht wie die alten Konsolen funktioniert haben, ist ein AVR schon fast zu viel für eine CPU ;) Wirklich.
Ein bisschen Reverse Engeneering kann manchmal nicht schaden.

Ich werde den Aufbau so gestalten, dass wirklich jeder das Teil nachbauen kann. Bislang reichen 3 Chips. Der 1.AVR, ein schneller 2.RAM für den 3.CPLD. Die Adressierung für den VRAM kann der AVR selbst vornehmen, oder ich werde eine Routine dafür in den CPLD packen.
Die einzige beschränkung im Design für die GPU sind die 72 macrocells im größten lötbaren CPLD den es derzeit gibt. D.h. man hat gerade mal 9 8-bit Register zur verfügung.
Die PPU im NES hatte nur 8, aber ich werd wohl die 9 ganz verbrauchen.

Ein Grafikleistung wie die des NES sollte machbar sein. Ich schätze die gesamte Entwicklung wird ca. ein Jahr dauern, oder auch mehr, da ich nur am Wochenende Zeit dafür habe.

Die erste Zielsetzung für die Grafikleistung sieht wie folgt aus:

NES Auflösung 224x192 Pixel bei 16 - 64 Farben gleichzeitig. Eine hardware Palette von 256 Farben oder mehr ist aber ohne Probleme machbar. Der CPLD erzeugt ja jedes Signal das man haben will.
Ausgegeben wird das Signal per RGB+Sync. Ein FBAS Signal wäre auch möglich oder VGA.
Hintergrundscrolling wird ein Kernfeature der GPU.
Für Sprites könnte man einen extra Bereich im RAM festlegen.
Ein Sprite also ein bewegliches Objekt benötigt min. 3 Byte : 2 Byte Position und 1 Byte der Grafikkachel.
Die ganze Arbeit wird vom CPLD gemacht.
Empfängt er keine Daten von der CPU, malt er das Bild auf den TV.
Synchronisation mit der CPU kann über einen oder zwei einfache IO-Ports erfolgen.

Wenn ihr Anregungen habt bleibt nicht stumm. Ich werd jede Entwicklung der GPU hier im Board dokumentieren.

http://www.innovativedevice.com/console/GameStation.asp

Witzig, aber immer wenn man denkt man hat eine gute Idee, kommt einem einer zuvor!!! >:(

Die Idee mit nem z80 halt ich persönlich für Rückschrittlich da ein z80 auch nicht schneller ist als ein atmega, eher langsamer (atmega ist ja ein RISC usw), außerdem braucht man beim z80 standardmäßig "externen" speicher dh viele adress- und Datenleitungen. Beim 68000er ist das sicher ähnlich, obwohl ich da nicht weiß wie schnell der ist im Vergleich zum atmega

So ist es, mit dem Z80 bewegt man sich 25 Jahre in die Vergangenheit ( Wahnsinn, schon ein viertel Jahrhundert! ). Die erreichbare Geschwindigkeit eines Z80 dürfte so ca. Faktor 5-10 unter einem Atmega liegen.

Das mit dem Z80 war ja auch nur eine Idee zum Thema externe Programme.

Der AVR stellt schon die beste Wahl für eine CPU dar. Schnell, günstig und einfach zu programmieren.
Ich arbeite zur Zeit an einem Entwurfsmuster, bzw. 2 oder 3. Die werde ich hier vorstellen und hoffe, dass ihr dazu euren Senf gebt.

Wenn ich schon so ein Projekt mache, muss wohl auch noch nen batzen Software entwickelt werden, denn das soll nicht nur eine einfache Konsole zum vorzeigen werden, sondern ich hoffe darauf, dass es eine Plattform bilden wird. Darum muss es auch so einfach wie möglich aufzubauen sein und gut supportet, also werd ich noch eine Art Grafikeditor und Karteneditor schreiben müssen, Beispielsoftware und ne Internetpräsentation...ich denk gerade zu weit ich weiß ;)

Kurz zur Planung : Anstatt eines SRAMs wird die Grafikeinheit mit 1 oder 2 schnellen Cache-Bausteinen versehen. Es gibt 64kb Typen noch ganz günstig, die 15ns schnell sind. Damit könnte man auch einen AVR als Grafikchip einsetzen, leider würden dann zuviele IOs für den Cache draufgehen, und es müsste noch ein Demultiplexer zwischengeschalten werden, aber eine Überlegung wäre es schon Wert.
Was meint ihr?

Mir ist aufgefallen, dass man die Grafik noc hsimpler mittels eines AVRs und ein wenig TTL aufbauen könnte. Ein CPLD kann dann wegfallen, oder man nimmt es anstatt der TTL-Bausteine.

Mit TTL wird die Platine etwas größer. Um IOs zu sparen könnte man einen 64kb-Cache als Videospeicher nehmen, der demultiplext wird.
Man kann dafür dann wirklich den kleinsten CPLD nehmen den es gibt.
Mit TTL sieht das natürlich Arcade-Mäßiger aus ;)

Ein Mega8515 könnte das VRAM direkt ansprechen, aber ich glaube dann bleiben nur noch 8 IOs.
Man müsste überlegen wie die CPU dann den VRAM ansprechen kann. Eventuell baut man einen kleinen Seriell-Parallel Umwandler der die Daten dann von der CPU, oder einem ROM, ins VRAM überträgt.

Mal sehen. Eine Lösung mit nur AVRs würde mir am besten gefallen.
Achja für Sound ist auch schon gesorgt. Ich kenne den Link jetzt nicht, aber es gibt einen AVR-SID Simulator. SID ist der Soundchip des C64. Realisiert ist das mit einem Tiny.
Also Sound geht auch!

zum Thema sound:

wie wärs mit nem soundchip wie er zb auf alten adlib karten drauf ist? Yamaha YM3812 (OPL2)

Der ist imho ganz einfach anzusteuern und klingt dann auch gut (zb so: MI1 Hörbeispiel von hier), nur weiß ich nicht woher man den kriegt

Sehr cooler Chip. Klar kann man den verwenden, nur wo bekommt man ihn her? Wichtig ist, dass alle Bausteine für die Konsole günstig uns leicht beschaffbar sind.
Der Vorteil des SIDs ist auch, dass es massig Tracker dafür gibt und mehr Informationen.