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
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.
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
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).
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
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/
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.