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
@Christoph Vielleicht ließe sich der SID-AVR ja per I2C anschließen. Dann könnte man schon mal im BASIC testen, was machbar ist. Gruß Jörg
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.