Hallo! Habe dieses Board vor kurzem gefunden und auch interessante
Beiträge zu dem Thema. In einem Thread ging es um den Aufbau alter
Konsolen wie dem NES und der Ansatz schien mir gut realisierbar mit AVRs
zu sein. Mein Konzept war ein System mit einer GPU, die aus einem SRAM
Grafikkacheln von 8x8 Pixel ließt . Der Hauptcontroller füllt nach dem
Booten diesen RAM mit den Grafiken. So muss die CPU nur noch die
einzelnen Nummern der Kacheln übermitteln und es bleibt genug Raum für
die Spiellogik. Die Grafikeinheit könnte auch aus einem AVR mit etwas
TTL aufgebaut sein und eventuell ein Bild mit 16 Farben bei 128x96
pixeln aufbauen. Wobei die GPU jedoch wohl 6kb RAM allein für die
Bilddaten verbretzeln würde.... Naja so ganz fertiggedacht ist die Idee
noch nicht, aber ich wollte mal wissen was ihr über den Ansatz so denkt?
Schönes Gerät!
Im Grunde könnte man darauf schon gut aufbauen. Die Textzeichen könnte
man durch kleine Grafiken ersetzen die beim Booten ins RAM geschrieben
werden.
In meinen Überlegungen kam noch ein Feature auf, dass ein AVRES ;)
unbedingt benötigt. Das alte NES konnte ja nicht nur Grafikkacheln
anzeigen, sondern auch noch Sprites. Also bewegte, animierte Bilder,
welche man genau wie die Kacheln im RAM ablegen könnte. Dies würde zur
Folge haben, dass eine Grafikeinheit ja 2 mal ein bild berechnen müsste.
Erst die Kacheln und dann die Bildchen darüber. Außerdem müsste man wohl
eine Routine einbauen, die es erlaubt einen bestimmten Farbwert nicht
über die Kacheln zu malen, da ja nicht alle Objekte in einem Spiel aus
Vierecken bestehen :P
So ganz einfach wird das mit einem AVR wohl nicht sein. Ein externes RAM
kann glaub ich auch nur der 8515 ansprechen. Dieses müsste auch ziemlich
schnell sein.
Eventuell könnte man schnell genug ein RGB+Sync-Signal erzeugen, und der
AVR baut intern immer schon eine Bildzeile auf, indem er die Kacheldaten
vom Hauptchip mit den im externen RAM gespeicherten Kachelgrafiken
kombiniert.
Als Ziel setze ich immernoch 128x96 Pixel mit 16 Farben.
RGB+Sync-Signal sollte eigentlich jeder heutige TV verarbeiten können.
Als Nachrichtentechniker bin ich zwar gut auch mit dem FBAS Signal
vertraut, aber performant wird das mit einem AVR nicht ;-)
Erster Testaufbau steht schon kurz bevor. Ich will versuchen so wenig
wie möglich externe Bausteine zu verwenden und das ganze auch noch in
leicht lötbarer Form verwirklichen. Ist sicher besser für Lernzwecke.
Um den ein oder anderen TTL werd ich aber wohl nicht rumkommen.
Ein 8515 als GPU ist mal was interessantes und dazu dann ein Mega32 als
CPU und irgendein SRAM mit min. 16k...liegt hier auch irgendwo rum. Mal
sehen was daraus wird.
Falls ihr noch Tips zu dem Thema habt, immer her damit. Wer genauere
Infos hat wie die alten Konsolen funktionierten, erst recht her damit!
Servus!
Ich habe heute noch etwas geforscht und den Propeller-Chip ausfindig
machen können. Auf den ersten Blick war das natürlich schon sehr witzig,
aber ernsthaft...160MIPS? 8x80Mhz wo bleibt da der Spaß? Und dann
verbraucht er auch noch die meiste Leistung fürs Programminterpretieren.
Nene, sowas macht nich so viel Spaß. Also weiter mit dem AVRES ;) Mein
SRAM braucht knapp 80ns...das geht ganz gut
Wie wäre es denn, wenn ich für die Grafikausgabe 2 ATMega8515 nehme?
Meine Idee entspricht in etwa der Arbeitsweise des Atari 2600.
Die Grafikeinheit zeichnet immer das selbe Bild aus dem RAM. Kommt vom
Hauptprozessor ein Befehl wird der Wert des aktuell zu zeichnenden
Pixels geändert.
D.h. ein Grafikchip ist für das Input eines SRAMs zuständig, während der
andere das Bild immer strikt aus dem SRAM aufbaut.
Ich weiß, dass das ganze sehr sehr zeitkritisch wird, aber was haltet
ihr grundlegend von der Idee?
Möglich wäre es zum Beispiel einen Mega644 zu nehmen. Der hat 4K RAM
zund kann bis zu 20MHz getaktet werden. Für die Sprites müsste man eine
Anzahl von Tiles kopieren und dort die Sprites drüberzeichnen. Zum
Darstellen müssen dann nur die betroffenen Felder neue "Zeiger"
bekommen. Damit wäre bei ungefähr quadratischen Pixeln eine Auflösung
von 144 x 112, entsprechend 18x14 (aus 64) Tiles möglich.
Gruß Jörg
Hallo Jörg,
gehe ich recht in der Annahme, daß der Basic-Computer von Dir ist? Sehr
minimalischtisches Design, sehr elegant, gefällt mir gut.
Vielleicht könnte man als Peripherie meinen emulierten SID anschließen,
( http://www.roboterclub-freiburg.de/atmega_sound/atmegaSID.html )
dann hätte Dein BASIC-Computer C64 Soundqualitäten. Wäre eventuell für
Spiele ganz lustig. Vielleicht wiederspricht es aber auch ein wenig dem
Minimalismusdesign, da ja ein ganzer Prozessor für die Soundausgabe
verbraten wird.
Gruß,
Christoph
Du brauchst einen flotten ARM mit ein paar MB DRAM, als ROM könnte der
interne flash ausreichen.
Dann portierst du dir einen NES/C64/oder ähnliches Emulator auf den ARM
und lädst die ROMs von SD Karten (in deinen RAM).
Mit AVR wird das ganze etwas sehr minimalistisch... vor allem wenn es
dann noch mit Farbe los geht
Hallo Wolfram,
die Version 1.8 des SID kann seriell angesteuert werden (9600,8,n,1
Protokoll: Registeradresse, Registerwert ).
Was den SID und Basic anbelangt, wäre es schön wenn es High-Level
Befehle wie z.B. SetVoice 1,triangle,1000 ( Stimme 1, Dreieck, 1000Hz
oder so ähnlich ) gäbe, so daß man sich nicht unbedingt das Datenblatt
des SID durchlesen muß um die Registerwerte herauszufieseln. Die
Funktionsweise des SID ist zwar nicht unbedingt schwer zu verstehen,
aber es ist halt doch etwas Mühe notwendig.
Ich muss zugeben, daß ich mit I2C und AVR noch keine Erfahrungen habe.
Im Moment bin ich gerade etwas ausgelastet, so daß ich nicht weiß, wann
ich etwas für einen I^C Anschluß tun kann.
Gruß,
Christoph
Der SID-Emulator ist wirklich sehr interessant.
Kommt rein in die "Konsole" ;-)
Ich habe jetzt mein Konzept so weit fertig und habe das Design so
gewählt, dass die CPU entlastet wird.
Vorbild war das NES, bzw. Konsolen der 3. 8-Bit Generation.
Die dort verbaute GPU übernimmt eigentlich fast alles, was mit Grafik zu
tun hat und genauso werde ich es auch machen.
Da es keine fertigen GPUs für soetwas gibt und ich meinen NES nicht
ausschlachten werde, muss ein CPLD herhalten, der dann den Kern der
Konsole bildet. Daran kommt ein flotter SRAM. Dieser enthält dann Tile
und Sprite Grafiken und eben alles was man darstellen will in 8x8
Pixelblöcken.
Im Flash des AVR oder auf einem externen ROM könnten Kartendaten liegen,
die auch ins RAM geladen werden.
Die CPU übermittelt dann nur noch Daten für Sprite-Positionen und
Scroll-Positionen an das CPLD welches sich um die Darstellung kümmert.
Kollisionserkennung zwischen Sprites könnte auch über das CPLD erfolgen
über irgendein IO-Port als Flag. Die CPU startet eine Abfrage aus 2
Adressen für die Sprites und das CPLD setzt das Flag wenn sich die
beiden treffen, oder eben nicht.
Ich denke umso mehr Aufgaben das CPLD übernimmt umso besser, denn
schließlich soll der AVR nur Spiellogik machen, da so viel Programm
nicht drauf passt. Darum finde ich, sollte ein Spielmodul auch immer aus
dem AVR und einem ROM bestehen auf dem Grafikdaten und Kartendaten
ausgelagert sind (eventuell auch Sounddaten?).
Die Auflösung und Farbtiefe hängt dann nur noch vom CPLD ab. Wenn man
den schnell genug taktet sollten 256 Farben gleichzeitig ohne Weiteres
möglich sein; umso größer werden jedoch auch die Grafikdaten zu
Ungunsten der Ladezeiten.
Ein AVR kann so auf jedenfall einer Hydra mit Propeller Konkurrenz
machen.(ich frage mich gerade was Leute über den Satz denken, die keine
Ahnung von sowas haben)
Da ich von CPLDs kaum eine Ahnung habe, wird die Entwicklung wohl etwas
dauern ;) Teuer wird sie jedenfalls sicher nicht. Alle Teile zusammen
kosten weniger als 20 Euro, inklusive Lötzinn und Kupferlackdraht
Mir kam da noch die Idee, man könnte 2 solcher SIDs verwenden. Einer
könnte immer die Daten aus einem ROM bekommen wo ein Song gespeichert
ist, der andere kann von der CPU direkt angesprochen werden um
Soundeffekte für das Spiel zu erzeugen. Wäre das denkbar?
Klar, kann man machen. Der Atmega-SID wird über die serielle
Schnittstelle angesteuert, Du mußt also blos 2 TxD Leitungen bereit
halten.
Die SIDs sind sozusagen "fast" linear skalierbar.
1 SID = 3 Tongeneratoren + 3 Hüllkurven
2 SID = 6 Tongeneratoren + 6 Hüllkurven
Gut. Dann kommen für die Konsole 2 AVR-SIDs zum Einsatz. Muss ich nur
noch sehen wie der Musik-SID (der erste SID) selbstständig seine Daten
aus dem ROM beziehen kann. Man könnte ihn doch sicher auch per Interrupt
steuern, sodass die CPU einen int. schickt und ein neuer Song aus dem
ROM abgespielt wird. Schließlich will ich die CPU ja so viel entlasten
wie möglich. Der 2. SID wird dann seriell angesteuert. Eventuell kann
auch der CPLD die SIDs steuern...?
Wie wäre es 8 AVR SIDs zu nehmen um 8 Soundkanäle zu haben, einen AVR
der das Grafik CPLD ansteuert, dann noch einen AVR der Grafikoperationen
durchführt. Dann hättest du sound und GFX schonmal mit nur 10 AVRs
gelöst.
Die CPU kommt dann mit einem AVR aus, der natürlich von einem AVR
unterstützt wird der den Gamecontroller einliest und entprellt und einen
AVR der ROM-Dateien von einer SD Karte lädt und den CPU-AVR (ISP)
programmiert. Dann brauchst du natürlich noch einen Co-Prozessor AVR auf
den du Berechnungen auslagern kannst.
Hab bestimmt noch ein paar mögliche AVRs vergessen, aber so mit 14 bis
20 AVRs sollte das ganze easy zu handeln sein. Oder man nimmt gleich
einen dafür geeigneten Prozessor. Aber das wäre ja viel zu einfach.
