mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik [Spielekonsole] Form der Spiele


Autor: Chuu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich entwickle gerade eine einfache kleine Spielekonsole auf Basis eines
MSP430F1611. Gamepad, Audio, SDC und Text-LCD (jaja) habe ich schon.
Mein einziges Problem ist, in welcher Form ich die Spele entwickle.

Ich habe diverse Möglichkeiten gefunden:
- Nativer Code: Da der MSP430 eine von Neumann-Architekur ist, könnte
ich das Spiel (oder Teile davon) in den RAM laden und dort ausführen.
Aber wie soll das Spiel auf meine I/O Routinen zugreifen? Selbst wenn
ich die Addressen der Funktionen in die Spiele hardcode: Wenn ich das
OS modifieziere ist alles fürn A****. Dynamic Linking muss her. Das
erscheint mir aber sehr kompieliert und DOS-like Software-Interrupts
gibt es ja nicht, oder?
- Byte Code: Dieverse Sprachen (LISP z.B.) lassen sich ja in ByteCode
übersetzen. Nur müset ich dafür einen Interpreter schreiben oder
portieren. Das erscheint mir aber auch recht schwer und hört sich nach
viel Code an, für den ich möglicherweise keinen Platz habe. Oder gibt
es möglicherweise (für LISP z.B.) einen Bytecode-Interpreter, der
klein, erweiterbar und einfach zui portieren ist?
- Interpreter: Ich könnte einen kleinen Interpreter für z.B. LISP
schreiben. LISP scheint mir nicht sonderlich schwer zu interpretieren
sein. Hört sich aber dennoch nach einem längeren Projekt an. Oder gibt
es vielleicht ein kleinen erweiterbaren, einfach zu portierenden
LISP-Interpreter? In lex/yacc wär mir hier natürlich am liebsten.
- externer Controller: Ich könnte auch einen externen Controller (hab
hier noch ein paar atmega8 rumfliegen) über z.B. SPI anschließen, der
der Konsole Befehle gibt. Da wär aber mit Hardwareaufwand verbunden.
Außerdem habe ich doch schon die SDC-Ansteuerung fertig.

Was würdet ihr tun?

MfG

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das habe ich mich auch schonmal gefragt... Wie auch immer, der Gameboy
hat native Assembler Befehle in einem EEPROM in der Cartridge
gespeichert. Wird dieses eingesteckt und der Gameboy angeschaltet, wird
ins EEPROM immer an Adresse XYZ gesprungen und von dort aus das Programm
mit den nativen Befehlen gestartet.
I/O Geräte liegen beim Gameboy direkt am Daten/Adressbus.
Dementsprechend wird auch so auf diese Geräte zugegriffen. Sprich:
Wirkliche I/O Routinen gibts hier nicht.

Autor: Eckhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Du könntest einfach eine Spruntabelle zu deinen I/O Funktionen
benutzen. So liegt die Adresse der Funktion immer an der selben Stelle
egal wo die Funktion sich wirklich befindet. Eine andere Variante sind
Software Interrupts oder Traps, weiß nicht ob der MSP430 sowas hat. Als
Bytecode Interpreter würde ich eher in richtung FORTH gehen. LISP halte
ich bei den resourcen doch für nichtz so geeignet.

Eckhard

Autor: さくら (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Traps oder Software-Interrupts hat der MSP430 leider nicht. Die Idee
meiner Vorposters mit der Sprungstabelle ist nicht schlecht, allerdings
muss man dann zur Kompilier-Zeit irgendwie wissen wo welche Funktion
liegen wird und diese Informationen an einem bestimmten Ort ablegen.
Außerdem müsste man den Code der Spiele in ein spezielles Format
bringen, befreit von Interrupt-Vektoren und anderem Overhead. Und
schließlich darf der Code der Spiele nicht in den RAM-Bereich
schreiben, in dem das 'OS' seine Daten hat. Das halte ich für ein
Ein-Mann-Projekt für viel zu kompliziert.

Bytecode-Interpreter sind 'ne schöne Sache. Allerdings etwas langsam,
wenn man nicht gerade einen ARM verwendet. Wenn es bei dir aber nicht
auf Geschwindigkeit ankommt, kann man das machen. Du könntest zum
Beispiel NanoVM auf den MSP430 portieren. Ich hab mir den Sourcecode
mal genauer angesehen, so schwer ist das nicht.

Von einem Richtigen Interpreter kann ich nur abraten. Das ist für einen
MSP430 wirklich zu langsam und zu Speicherfressend (RAM und ROM).

Die Sache mit dem Externen Controller halte ich für eine gute Idee. Das
bedeutet zwar etwas mehr Hardwareaufwand, ist aber schnell. Die SD-Karte
kannst du ja zum speichern von Speilständen od.Ä. verwenden (wie bei der
PS).

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

machs wie beim guten alten C64: das OS kopiert als erstes eine
Vektorliste mit den Startadressen der OS- und IRQ-Routinen in
festgelegter Form an eine feste Position ins Ram.
Alle Aufrufe gehen indirekt über diese Vektoren.
Das Spiel kann diese Vektoren benutzen und auch ändern, um z.B. eigene
Routinen für die gleiche Funktion zu benutzen oder IRQ-Handler
einzuhängen. Bei den IRQ muß das Game dann klären, ob es ein IRQ ist
und sonst in den Originalaufruf des Vektors springen.

Dazu noch eine Modulkennung vereinbaren (muß ja nicht CBM64 sein...),
auf die das OS testet und dann dort in eine feststehende Vektoradresse
verzweigt.

Gruß aus Berlin
Michael

Autor: Michael König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für Spiele bietet sich normalerweise immer nativer Code an, da es in
diesem Anwendungsbereich meist auf Geschwindigkeit ankommt.

Ausnahmen bestätigen natürlich die Regel, allerdings würde ich kein
LISP verwenden (obwohl es mit "Abuse" mindestens ein Spiel gibt, das
in LISP geschrieben wurde). Falls es unbedingt so ähnlich sein soll,
würde ich eher Scheme nehmen, da das kompakter und vom Konzept her
etwas sauberer ist. Allerdings frage ich mich, wozu man bei einem Spiel
eine funktionale Sprache erster Ordnung brauchen sollte.

Recht beliebt bei professionellen Spieleentwicklern scheint Lua zu
sein, mit dem Beispielsweise das Lucas-Arts-Spiel "Grim Fandango" und
die Addons in "WoW" realisiert sind:
http://www.lua.org/

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.