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

[Ramsis]

Den GameSaver+ hatte ich ja schon erwähnt. Ich hab sogar einen, und Super Mario World stürzt spätestens beim zweiten Laden eines Savestates komplett ab. Mit den paar anderen Spielen, die ich vor einer Weile ausprobiert habe, sah es nicht besser aus (ob nun mit Code aus der beiliegenden Liste oder nicht). Von daher ist der GameSaver+ meiner Ansicht nach nicht viel mehr als Elektronikschrott. Aber bitte, wenn's bei dir funktioniert ...

PS: Ach ja, meine Super WildCard DX2 hat ja auch eine Savestate-Funktion. Die ist nach meiner Erfahrung ungefähr so brauchbar wie die des GameSaver+. Nämlich überhaupt nicht. Aber dafür hat die DX2 zum Glück ein paar andere coole Features.

[rama]

Naja, das sind die Implementationen, die wir derzeit haben.
Ich behaupte, die Abstürze sind Bugs in den Geräten.
Man kann bei Savestates eine Menge falsch machen, und ein Crash bedeutet nicht gleich, das es an der APU liegt.
Tatsächlich ist die Chance eher gering, genau wegen der Einschränkungen mit dem Chip.

[el_seyf]

Ein weiteres Update im 1. Post
Zu den Savestates:
Der APU kann durchaus dazu führen, dass ein Spiel crasht. Es soll Spiele geben (weiss gerade nicht genau welche), die den APU als Co-Prozessor nutzen, um aufwendige Rechenarbeit aufzuteilen. Das führt dann natürlich zu Problemen, wenn der APU nicht das richtige Programm ausführt.

[rama]

Crashes durch falschen Code in der APU sind möglich aber es werden nur wenige, spezielle Spiele betroffen sein.
In Frage kommen nur solche, die ein Feedback von der APU zur richtigen Zeit erwarten, oder die den Trick mit dem Sample Streaming machen.
In dem Fall wird es trotzdem funktionieren, wenn zumindest das richtige Programm geladen ist. Man müsste also das Spiel vor einem State Load komplett laden lassen.

Ich empfehle, die APU erst mal auszublenden, und die States ansonsten vollständig zu implementieren.
Emulatoren liefern gute Beispiele, was alles gespeichert und wiederhergestellt werden muss.
Man sollte auch keine States speichern oder laden, wenn gerade Daten vom SNES zur APU gesendet werden.
https://en.wikibooks.org/wiki/Super_NES ... 0_programs

Btw: Ein SPC Player? Super!

[el_seyf]

Update zum Memory Viewer. Infos im 1. Post

[el_seyf]

Nach etwas längerer Stille möchte Ich ein relativ kleines Update verkünden (siehe 1. Post)

[Redscorpion]

Nice. Liest sich auf jeden Fall schonmal sehr gut!

Ich kann mir nur zu gut vorstellen, wie dein SNES gerade ausschaut!

Gruß

red

[Ramsis]

*Pfote heb*

@el_seyf, lange nichts gehört! Arbeitest du noch an diesem Projekt? Wäre schön, mal wieder ein Update zu lesen.

[el_seyf]

@Ramsis, vielen Dank für dein Interesse
Ich arbeite leider seit einiger Zeit nicht mehr aktiv an dem Projekt, jedoch habe Ich Updates zum BIOS4SNES. Ich hatte das Interface überarbeitet, alles ist jetzt in schlichtem Schwarz/Weiß. Zudem hatte Ich den HiRes-Mode richtig implementiert, den Memory Viewer soweit fertig, einen Software Debugger geschrieben, einen SPC Player, der halb funktioniert und einen mehr oder weniger hilfreichen "Crash Report Screen" erstellt. Zuletzt wollte Ich mich auch an die Hardware machen. Dafür hatte Ich eine entsprechende Platine entworfen, mit der Ich die SNES Signale an einen FPGA leiten kann. Ich hatte auf dem FPGA auch schon einige Dinge fertig, bspw ein SD Karten Interface, der in der Lage sein sollte, MSU1 kompatibel zu sein. Ich war so weit, Daten mit der 50MHz Schnittstelle von SD Karten zu laden, jedoch gibt es noch einige gravierende Bugs in meinem Controller. Einen SDRAM Controller habe Ich auch, der aber auch nicht wirklich funktionieren will.
Ich kann nicht sagen, wann Ich am Projekt weiter arbeiten kann/werde, aber das Interesse ist nicht erloschen. Aktuell sind andere Dinge auf meinem Plan, die Priorität haben, daher wird in naher Zukunft sich vorerst nichts weiter tun.

bios4snes_07_02_2018_23_55_19-20180207-234545.png (2.86 KiB) 26280 mal betrachtet

Memory Viewer im HiRes-Mode:

bios4snes_07_02_2018_23_55_19-20180207-235101.png (7.97 KiB) 26280 mal betrachtet

Software Debugger (Super Debugger):

bios4snes_07_02_2018_23_55_19-20180207-235123.png (5.07 KiB) 26280 mal betrachtet

SPC Player:

bios4snes_07_02_2018_23_55_19-20180207-235131.png (5.34 KiB) 26280 mal betrachtet

Crash Report Screen:

bios4snes_07_02_2018_23_55_19-20180208-001557.png (6.83 KiB) 26280 mal betrachtet

[rama]

Nicht schlecht!

So größere Projekte bleiben leider oft stecken, gerade wenn es viele Hardwarekomponenten sind.
Vielleicht kann man den Funktionsumfang etwas reduzieren, und den Aufwand mit dem FPGA sparen.

Aktuelle Micros bringen viel Speicher, IO und Rechenpower mit.
Sie sind dazu noch äußerst günstig, oftmals unter 10 Euro für ein komplettes Board.
Man könnte mal schauen, ob die wichtigsten BIOS4SNES Features damit nicht schon machbar sind.
Beispiel ESP32 (Board kostet < 10 Euro bei Ebay): https://en.wikipedia.org/wiki/ESP32

[el_seyf]

Ich hatte anfangs einen µC im Projekt, jedoch gab es ein entscheidendes Problem, weshalb Ich auf den FPGA umgestiegen bin: Der SDRAM Controller. Ich wollte als ROM-Speicher SDRAM nutzen, da dieser der günstigste Speicher ist. Alternativ könnte man PSRAM nutzen (siehe SD2SNES), dieser ist aber um einiges teurer und nur als BGA Package erhältlich, daher für per Hand gelötete Prototypen nicht geeignet. Oder SRAM, der ist aber mit max. 2MB pro IC zu klein bemessen; für mind. 8MB Speicher bräuchte Ich so 4 von denen.
Außerdem habe Ich mit dem FPGA deutlich mehr Flexibilität, was Features angeht (eben bspw Support für MSU1). Der Software Debugger sollte auch zusammen mit dem FPGA arbeiten, und so später ein ordentliches Software Debugging Tool darbieten.
Ich muss auch sagen, dass das Programmieren vom FPGA deutlich einfacher ist, als die Software für die SNES zu schreiben. Ich hatte beim Software-Part oftmals das Problem, das größere Code-Teile einfach mal komplett neu geschrieben werden mussten.
Auch wenn Ich am Projekt selbst nicht aktiv arbeite, bin Ich bspw. für ein Anderes dabei, den SDRAM Controller neu zu schreiben. Es gibt also sozusagen Updates über "Umwege"

[rama]

Alles klar, Features wie MSU1 und ordentliches Debugging gehen mit nur einem Micro eher schlecht.
Ich will es nicht ausschließen, aber bestimmt müsste man dann einen Micro pro Feature opfern :p

versteckter Inhalt:

Wäre aber schon cool, die Flashcart Funktion damit zu machen.
Das SNES ROM käme per WiFi in den Flash, von dort aus in Pages in den Micro RAM, von dort aus an die Datenpins.
Klappt natürlich nur, wenn das SNES tatsächlich irgendwie in Pages (von < ~256kB) liest.