[Update 5½]BIOS4SNES - Ein BIOS für Super Nintendo

[Ramsis]

Wenn du allerdings deinen Gedanken auf eine Kombie von FPGA und MCU erweiterst, dann wärst du sicherlich sehr schnell bei einem 'build-in' sd2snes

Wenn es doch zu kompliziert wird mit dem Umsetzen von einem FAT32 Treiber auf FPGA, kann Ich immernoch auf MCU + FPGA umrüsten, es gibt ja mittlerweile ziemlich gute Low-Cost ARM CPUs.

@el_seyf, in diesem Zusammenhang würde mich mal die genaue Motivation für "BYOS" interessieren.

Wenn ich deine bisherigen Beiträge nochmal lese, so kommt es mir vor, als hättest du dich blindlings in dieses Projekt gestürzt, ohne jemals zuvor von U16 oder sd2snes gehört zu haben. Das ist natürlich kein Hinderungsgrund. Aber darf ich trotzdem so neugierig sein zu fragen, was dich dazu gebracht hat, anscheinend ohne jegliche Vorab-Recherche ein derart (ja, ich bleibe dabei) ambitioniertes SNES-Projekt zu starten?

[el_seyf]

@el_seyf, in diesem Zusammenhang würde mich mal die genaue Motivation für "BYOS" interessieren.

Wenn ich deine bisherigen Beiträge nochmal lese, so kommt es mir vor, als hättest du dich blindlings in dieses Projekt gestürzt, ohne jemals zuvor von U16 oder sd2snes gehört zu haben. Das ist natürlich kein Hinderungsgrund. Aber darf ich trotzdem so neugierig sein zu fragen, was dich dazu gebracht hat, anscheinend ohne jegliche Vorab-Recherche ein derart (ja, ich bleibe dabei) ambitioniertes SNES-Projekt zu starten?

Meine Motivation für BYOS ist, dass Ich einfach mal ein größeres Projekt als "nur" Homebrew Spiele angehen wollte (Ich bin leider kein Game Designer, dementsprechend enttäuschend sind für mich meine angegangenen Game-Projekte für NES ausgefallen... ). Dass Ich das Projekt jetzt auch angegangen bin, lag dann an meinem SuperUfoPro8SD (shame on me...); der hatte mich zuletzt meinen Super Metroid Phazon (übrigens ein sehr gelungener Hack) Save gekostet (der SRAM wurde nicht richtig auf die SD Karte kopiert, nach einem Power-Cycle wollte Ich den SRAM wiederherstellen, was natürlich mit defekten Daten keinen Sinn gemacht hat, damit hatte Ich dann erstmal 8 Stunden Spielzeit verloren). Der SuperUfo hat aber auch generell andere Probleme, die mich davon überzeugt haben, dass Ich's besser hinbekomme
Natürlich hätte Ich mir auch einfach einen sd2snes oder Everdrive besorgen können, aber selber bauen macht mehr Spaß (den SuperUfo hatte Ich schon lange bevor Ich überhaupt mit Programmieren von irgendwas zu tun hatte).
Zusätzlich lerne Ich auch noch ein paar Dinge durch dieses Projekt (So ein Learning-by-Doing Ding ), mit VHDL hätte Ich mich zumindest außerhalb der Uni vielleicht nicht beschäftigt, da Ich generell dem FPGA/CPLD ein MCU vorziehe (wobei Ich eben jetzt merke, wie Vorteilhaft die Arbeit mit einem FPGA sein kann).

Im Bezug auf die Recherche:
Natürlich ist mir die Existenz des sd2snes (als vergleichbares Projekt, wobei das ja schon viel fortgeschrittener ist als meins) bekannt, und auch, dass es OpenSource ist, aber Ich möchte, bevor Ich "abschreibe", zunächst meine eigene Umsetzung versuchen

[el_seyf]

Update im 1.Post

[Redscorpion]

Coole Sache!

[el_seyf]

Kleines Update im 1. Post:
- Font jetzt lesbarer
- Savestates als neues Feature
- Bug beim Button Mapping behoben

Aktualisierte ROM ist auch im 1. Post

[rama]

Auch weiterhin viel Erfolg!
Die Features sehen schon klasse aus.
Wichtig wäre natürlich am Ende die Preisfrage
Das sd2snes ist sicherlich klasse aber viele schrecken vor den Kosten zurück.
Ich habe zum Beispiel in einem Anfall von Wahnsinn mein sd2snes verkauft, und mir ein SuperUfo als Ersatz geholt.
Großer Fehler.. :p

[Redscorpion]

Sieht nun auch besser aus in der Darstellung. Mich würde mal interessieren wie du in Abfrage mit dem FPGA bzw. CPLD dem ROM sagst check das und das?!

Ich arbeite gerade an einem rudimentären Menü was einfach Statusbits setzen soll an einem AVR bzw. einem CPLD. Sinn und Zweck ist so eine Realisierung hier, jedoch nicht mit FX Games:

https://www.youtube.com/watch?v=H-FVYQmo2JU

Momentan fehlt mir da noch ein wenig das Verständnis. Was nutzt du für Quellen bzw. woher kommt dein wissen?!

Gruß

red

[el_seyf]

Auch weiterhin viel Erfolg!
Die Features sehen schon klasse aus.
Wichtig wäre natürlich am Ende die Preisfrage
Das sd2snes ist sicherlich klasse aber viele schrecken vor den Kosten zurück.
Ich habe zum Beispiel in einem Anfall von Wahnsinn mein sd2snes verkauft, und mir ein SuperUfo als Ersatz geholt.
Großer Fehler.. :p

Danke. Sobald Ich einen Prototypen der Hardware habe, kann Ich genaueres zu den Kosten sagen.

Mich würde mal interessieren wie du in Abfrage mit dem FPGA bzw. CPLD dem ROM sagst check das und das?!

Ich arbeite gerade an einem rudimentären Menü was einfach Statusbits setzen soll an einem AVR bzw. einem CPLD. Sinn und Zweck ist so eine Realisierung hier, jedoch nicht mit FX Games:

https://www.youtube.com/watch?v=H-FVYQmo2JU

Momentan fehlt mir da noch ein wenig das Verständnis.

Bisher habe Ich noch kein konkretes Konzept für die Kommunikation, es wird aber höchstwahrscheinlich so sein, dass der FPGA einen bestimmten Addressbereich bekommt (zB. von $6000-$7FFF, wo normalerweise externer SRAM gemapped ist) und je nach Addresse werden verschiedene Parameter übergeben (auf diese Weise kommunizieren zB Super FX und SA-1 mit der SNES).
Das was du vor hast würde mit einem CPLD perfekt funktionieren, da du ja nur einmal Daten von der SNES abgreifen möchtest und dementsprechend Addresspins auf der ROM setzen möchtest. Du müsstest prinzipell alles nur so einrichten, dass beim Einschalten der SNES die Register vom CPLD zurückgesetzt werden (zB mit sowas hier), sodass der CPLD nur einmal Daten von der SNES akzeptiert und danach nichts mehr macht (so müsstest du dir zB keine Gedanken machen, ob ein Spiel in den Open Bus von der SNES schreibt, aus welchem Grund auch immer, und der CPLD fälschlicherweise die Daten akzeptiert weil es in diesen Addressbereich geschaltet ist).
Ich hatte auch etwas ähnliches mit einem µC für die NES gemacht, Details sind in diesem Post.

Was nutzt du für Quellen bzw. woher kommt dein wissen?!

Mein Wissen über die SNES beziehe Ich größtenteils von http://wiki.superfamicom.org/snes/show/HomePage, und http://problemkaputt.de/fullsnes.htm.

[Ramsis]

Hört sich alles gut an!

Als neues Feature setze Ich Savestates auf die Liste, der FPGA hat sowieso ständigen Zugriff auf Address- und Datenbus, daher ist es kein Problem, zu erfassen, welchen Status die verschiedenen Register haben und was im RAM gespeichert ist.

Hmm ... soweit ich weiß, sind "richtige" Savestates, wie sie Emulatoren bieten (z. B. ZSNES ZST-Dateien), auf echter Hardware per se nicht machbar, da APU-Register/RAM nicht in Echtzeit auslesbar sind. Das führt dazu, dass viele Spiele nach kürzester Zeit keinen Sound mehr haben oder komplett abstürzen, wenn man z. B. mit einem GameSaver+ o. ä. einen State wiederherstellt.

Oder meintest du mit "Savestates" etwas anderes (wie etwa SRAM)?

[el_seyf]

Mit Savestates meinte Ich schon ein Realtime Save wie beim Emulator. Die Problematik mit dem APU hab Ich mir schon gedacht (wobei Ich nicht ganz genau weiß, wie das Interface von S-CPU zum APU funktioniert). Ich müsste mal genauer Recherchieren, aber Unmöglich sollte es nicht sein. Ich stell mir das momentan so vor, dass man mit dem S-CPU den Programmfluss vom APU (für Kommunikation zwischen den Prozessoren) unterbrechen kann, demnach könnte man mit etwas Software den Audio-RAM im letzten Zustand dumpen können. Wenn der APU auch ein ähnliches System wie der S-CPU mit den Registern hat, sollte bei einer Unterbrechung mindestens der PgmCounter und Status auf den Stack geschoben werden, das ließe sich dann mit einer kleinen Routine im APU RAM problemlos wiederherstellen. Das ist natürlich nur theoretisch, Ich müsste mich wie gesagt da etwas mehr belesen.
Sollte es absolut nicht möglich sein, kann Ich auf jedenfall aber WRAM und VRAM für Savestates abgreifen.

[rama]

In den meisten Fällen würden die Savestates auch ohne den APU Teil funktionieren.
Man muss das Spiel nur normal starten lassen, so dass der Soundtreiber geladen ist.
Wenn man dann das Level wechselt (die Musik sich ändern soll), passt wieder alles.
Wichtig ist aber, das alle anderen RAMs und der CPU state exakt wieder hergestellt werden.

[Redscorpion]

Bzgl. Savestates... ist mir das hier mal ins Auge geschossen.

http://forums.nesdev.com/viewtopic.php?f=12&t=13290

Gruß

red

[el_seyf]

Ich habe gestern noch den Thread zum SNES-Tap (ein "besseres" Snes-Hook) gelesen, allem anschein nach hat man da auch keine Lösung für den APU gefunden.
Nach meiner Recherche zum APU muss Ich sagen:
Das Interface für S-CPU<->APU ist wohl das am schlechtesten konzipierte, was Ich bisher gesehen habe; man kann dem APU nur nach dem Reset der Konsole Daten zusenden und das auch nur, solange es sich im Bootrom befindet. Sobald man dem APU den Befehl gibt, das zugesandte Programm auszuführen, ist es nicht mehr möglich, den APU anzusteuern, wenn das zugesandte Programm das nicht zulässt.
Es ist auch nicht möglich, den APU per Register im S-CPU zu resetten, oder den APU Programmfluss mittels Interrupt zu unterbrechen (was Ich nicht nachvollziehen kann).
Was heißt das für Savestates: Ich müsste, um den APU RAM auslesen zu können, für jedes Spiel wissen, ob dieses die Kommunikation mit dem S-CPU zulässt und wie es das macht (man war beim Soundtreiber frei, wie die Kommunikation implementiert wird, nachdem der APU die Bootrom verlassen hat, also nicht jeder Soundtreiber muss die Bootrom Methode nutzen).
Ich hätte noch ein paar Ideen, trotzdem an den APU RAM zu kommen:
Beispielsweise könnte Ich ein Register im S-CPU reservieren, was den Reset des APU ermöglicht, so könnte Ich unabhängig vom Soundtreiber schonmal mit dem APU kommunizieren. Problem bei der Sache ist, dass die Bootrom vom APU Page0 initialisiert (240 Bytes), Ich würde also einen wichtigen Teil vom Speicher verlieren. Dem könnte Ich vorbeugen, wenn der APU den Address- und Datenbus beim Reset freigibt, Ich könnte dann den FPGA an den APU schalten und einen Dump vom APU RAM machen. Das größte Problem wäre dann, irgendwie an die Register A, X und Y zu kommen (die werden von der Bootrom auch initialisiert).
Da Ich aber erst noch das Menü fertigstellen und danach die Hardware zum funktionieren bringen möchte, stelle Ich die Savestate-Funktion weiter nach hinten auf der TODO-Liste.

[Ramsis]

In den meisten Fällen würden die Savestates auch ohne den APU Teil funktionieren.
Man muss das Spiel nur normal starten lassen, so dass der Soundtreiber geladen ist.
Wenn man dann das Level wechselt (die Musik sich ändern soll), passt wieder alles.
Wichtig ist aber, das alle anderen RAMs und der CPU state exakt wieder hergestellt werden.

Gesetzt den Fall, dass es tatsächlich so "einfach" wäre, wie du schreibst: Wieso hat dann in all den Jahren niemand eine funktionierende hardwarebasierte Savestate-Implementierung hinbekommen?

Sobald man dem APU den Befehl gibt, das zugesandte Programm auszuführen, ist es nicht mehr möglich, den APU anzusteuern, wenn das zugesandte Programm das nicht zulässt.
Es ist auch nicht möglich, den APU per Register im S-CPU zu resetten, oder den APU Programmfluss mittels Interrupt zu unterbrechen (was Ich nicht nachvollziehen kann).

Willkommen in der wunderbaren Welt der SNES-Programmierung!

[rama]

Ramsis: Hat man doch?
Der SNES Hook macht funktionierende States und mein Super Ufo kriegt das auch hin.. Mehr oder weniger.. Natürlich mit den genannten Einschränkungen beim Sound.
Es gibt auch ein Zusatzgerät für SNES, das nur dafür gedacht ist. Game Saver oder so.

Aber wie gesagt: Alle diese Lösungen lassen den APU state unangetastet und hoffen, das es sich nach einem Load von selbst wieder hinbiegt