mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Idee für AVR Entertainment System ;-)


Autor: Dosenöffner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: ajax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Dosenöffner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Dosenöffner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ajax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Dosenöffner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/at... )
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

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dosenöffner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dosenöffner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christoph H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dosenöffner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...?

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dosenöffner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer hat dich denn gebissen?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.