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

[Ramsis]

Hi, el_seyf!

BYOS läuft mittlerweile im Native-Modus, die Register arbeiten aber alle im 8-Bit Modus (im Moment noch). Grund sind die Interrupt-Vektoren, im Native-Modus stehen mehr zur Verfügung. Ich werde wahrscheinlich doch noch auf 16-Bit Programmierung umsteigen, wenn es die Hardware erfordert.

Nach ein wenig Research über die SNES Hardware (hauptsächlich über den Prozessor) habe Ich eine interessante Entdeckung gemacht: Die SNES hat einen ungenutzen "BUS ENABLE" Pin, der es ermöglicht, den Adress- und Datenbus in einen "High-Impedance State" zu bringen, wenn der Pin LOW gesetzt wird (im Normalfall ist dieser auf Vcc gelegt).

Sehr cool. Was bedeutet "High-Impedance State" genau? Und wie hast du die Funktion dieses Pins entdeckt?

Je nach Arbeitsaufwand werde Ich eine VWF-Routine (Variable Width Font) für das Menü programmieren, damit eine Datei mit mehr als maximal 32 Zeichen auch auf dem SNES angezeigt werden kann.

Aber ist eine VWF-Routine denn nicht zu langsam, um z. B. eine bildschirmfüllende Dateiliste innerhalb von ein oder zwei Frames anzuzeigen? Schließlich hat ja bestimmt kaum jemand Lust, auf das Ende einer Laufschrift zu warten.

Alternativ könntest du übrigens auch den Horizontal-Hi-Res-Modus des SNES benutzen. Nachteil: Dazu bräuchtest du im einfachsten Fall beide verfügbaren BG-Layer, ein scrollender Hintergrund wäre also nicht möglich.

Lieben Gruß,
Ramsis

[el_seyf]

Hey Ramsis,
Erst zu deinen Fragen:

Was bedeutet "High-Impedance State" genau? Und wie hast du die Funktion dieses Pins entdeckt?

Der "High-Impedance State" (wird auch "Z" genannt) verhindert einen Bus Conflict, sprich wenn du 2 Outputs an einen Input schaltest, würden diese einen Kurzschluss verursachen (auf lange Zeit für die SNES nicht gesund). Wenn du jetzt aber einen der Outputs in "Z" State versetzt, kann der andere Output ohne Probleme gelesen werden.
So werden beispielsweise RAM und ROM mithilfe von einem 74xx139 in einem SNES Modul gesteuert, beide sind an den Datenbus der SNES angeschlossen (D0-D7 von ROM, RAM und SNES sind alle jeweils untereinander verbunden). Der 74xx139 Baustein steuert die /OE Pins von ROM und RAM, dieser Pin setzt, wenn er HIGH ist, D0-D7 in "Z" State, wenn er LOW ist, werden valide Daten ausgegeben.
Du kannst hier zum Thema "Tri-State" ("0", "1" und "Z" als möglicher Zustand für einen Output) nachlesen.
Ich selber hab die Funktion des BE Pins nicht entdeckt, die wurde im Datenblatt vom 65816 erläutert (65816 ist der Prozessor, aus dem dann der S-CPU entstanden ist). Nachdem Ich das im Datenblatt gesehen hatte, hab Ich das Pinout des S-CPU überprüft und den BE Pin gefunden, der zudem noch ungenutzt ist (also durch keine Logik gesteuert wird sondern einfach immer auf HIGH gesetzt ist).

Aber ist eine VWF-Routine denn nicht zu langsam, um z. B. eine bildschirmfüllende Dateiliste innerhalb von ein oder zwei Frames anzuzeigen? Schließlich hat ja bestimmt kaum jemand Lust, auf das Ende einer Laufschrift zu warten.

Alternativ könntest du übrigens auch den Horizontal-Hi-Res-Modus des SNES benutzen. Nachteil: Dazu bräuchtest du im einfachsten Fall beide verfügbaren BG-Layer, ein scrollender Hintergrund wäre also nicht möglich.

Ich habe mich, um ehrlich zu sein, nicht allzu viel mit VWF beschäftigt... Ich hab das Thema mal schnell überflogen (wurde SNES spezifisch erläutert), und es sah mir eigentlich nach einer nicht allzu komplizierten Aufgabe aus, die mit dem richtigen Code schnell abgearbeitet ist.
Vom Hi-Res Mode habe Ich auch mal gelesen, mit der Funktion müsste Ich mich aber noch auseinandersetzen, klingt eigentlich nach einer sehr guten Alternative.


Ich wollte eigentlich nichts neues zum BYOS posten, da Ich einfach keinen Fortschritt gemacht habe...
Problem ist hierbei der mC, der wird ohne viel extra Logik-ICs nichts taugen. Ich werde mit dem Projekt auf FPGA umsteigen (habe hier noch ein Board liegen). Mitunter ein Grund für den Umstieg ist auch die Wahl des Speichers, nach langer Recherche ließ sich kein (bezahlbarer) SRAM-Speicher finden, der groß genug ist (größte war 1MB, und Stückpreis lag bei 20€, bei 8MB viel zu teuer, und am Ende zu viele ICs). Besser geeignet ist daher ein DRAM, die gibt es auch in 8MB Ausführung, nur das Ansteuern wäre mit dem mC ohne viel Logik-ICs nicht möglich. Natürlich kann man den DRAM Controller in einen CPLD packen, aber Ich dachte, dass ein FPGA als Ersatz für CPLD und mC dann besser wäre (zumal der FPGA dann noch eine riesige Palette an Funktionen bietet).
Ich muss hier aber mal erwähnen, dass VHDL (die Sprache der CPLD und FPGA) relativ neu ist für mich, Ich habe nur ein wenig in der Uni damit bisher zu tun gehabt, es kann also dauern bis Ich die ersten Fortschritte mit dem FPGA mache.
Um die Überraschung nicht kaputt zu machen, verrate Ich erstmal nicht die weiteren geplanten Features, aber Ich bin mir sicher, dass die ziemlich nützlich sein werden (zumindest sind das Features, die Ich gerne bei einer SNES gesehen hätte ).

[Redscorpion]

Grüße,

technisch kann ich hier kaum eine Hilfe sein Hört sich aber schon sehr gut an.

DIe CPLD - VHDL Geschichte ist auch ein Teil der U16 Realisierung gewesen. Ich glaub Borti hätte da auch ein offenes Ohr bei deinem Projekt.,

Gruß

red

[Ramsis]

Hi, el_seyf,

ah, danke für die Erklärungen zum Z-State. Eine wirklich clevere Idee, den BE-Pin mittels Interrupt selber zu steuern.

Ich habe mich, um ehrlich zu sein, nicht allzu viel mit VWF beschäftigt... Ich hab das Thema mal schnell überflogen (wurde SNES spezifisch erläutert), und es sah mir eigentlich nach einer nicht allzu komplizierten Aufgabe aus, die mit dem richtigen Code schnell abgearbeitet ist.

byuu hatte vor einiger Zeit mal einen interessanten Artikel zum Thema 8×8-VWFs auf seiner Homepage. Ein Ausschnitt daraus:

Traditionally, nobody has attempted 8x8 proportional fonts. There are worries about poor performance, redrawing artifacts, trouble keeping track of allocated tiles, limited VRAM space, etc.
(...)
The biggest limitation is speed. Rendering an entire screen full of item names at 2bpp on a 2.68MHz CPU is indeed painful. Combined with limited Vblank time to transfer the tile data, you can find yourself needing up to 2000ms to render a full screen. And during this time, you will see the new items slowly replacing old items as you flip through screens, with significant lag.

Sein Lösungsvorschlag -- statisches Rendern, also Item-Namen etc. als Grafiken im ROM abzuspeichern -- ist für ein Projekt wie dieses natürlich ungeeignet; es geht mir auch nur um seine Aussagen zur Geschwindigkeit einer VWF-Routine im Hinblick auf bildschirmfüllende Listen, die möglichst verzögerungsfrei dargestellt werden sollen. Da ich kürzlich erst eine 8×8 VWF-Routine in meinem RPG implementiert habe, sei ergänzend dazu gesagt, dass das nötige Bit-Shifting/Puffern der Tile-Daten in der Tat einen nicht zu unterschätzenden Rechenaufwand bedeutet.

Vom Hi-Res Mode habe Ich auch mal gelesen, mit der Funktion müsste Ich mich aber noch auseinandersetzen, klingt eigentlich nach einer sehr guten Alternative.

Falls du dazu Tipps brauchen kannst, sag gerne Bescheid.

Um die Überraschung nicht kaputt zu machen, verrate Ich erstmal nicht die weiteren geplanten Features, aber Ich bin mir sicher, dass die ziemlich nützlich sein werden (zumindest sind das Features, die Ich gerne bei einer SNES gesehen hätte ).

Och, sag ruhig mal. Einige hier (mich eingeschlossen) sind ja sd2snes- und Ultra16-verwöhnt und daher nicht so leicht zu beeindrucken.

Lieben Gruß,
Ramsis

[Nio]

Kann man schon vorbestellen?

[el_seyf]

@Ramsis

byuu hatte vor einiger Zeit mal einen interessanten Artikel zum Thema 8×8-VWFs auf seiner Homepage. Ein Ausschnitt daraus:

Traditionally, nobody has attempted 8x8 proportional fonts. There are worries about poor performance, redrawing artifacts, trouble keeping track of allocated tiles, limited VRAM space, etc.
(...)
The biggest limitation is speed. Rendering an entire screen full of item names at 2bpp on a 2.68MHz CPU is indeed painful. Combined with limited Vblank time to transfer the tile data, you can find yourself needing up to 2000ms to render a full screen. And during this time, you will see the new items slowly replacing old items as you flip through screens, with significant lag.

Sein Lösungsvorschlag -- statisches Rendern, also Item-Namen etc. als Grafiken im ROM abzuspeichern -- ist für ein Projekt wie dieses natürlich ungeeignet; es geht mir auch nur um seine Aussagen zur Geschwindigkeit einer VWF-Routine im Hinblick auf bildschirmfüllende Listen, die möglichst verzögerungsfrei dargestellt werden sollen. Da ich kürzlich erst eine 8×8 VWF-Routine in meinem RPG implementiert habe, sei ergänzend dazu gesagt, dass das nötige Bit-Shifting/Puffern der Tile-Daten in der Tat einen nicht zu unterschätzenden Rechenaufwand bedeutet.

Danke für diesen Ausschnitt, damit hat sich dann auch die Idee von VWF durch SNES erledigt. Ich werde mal schauen, dass Ich das ganze durch den FPGA in SNES Format render und dann einfach an die SNES durch einen Zwischenspeicher übergebe (das Anspruchsvollste wäre dann die Logik für VWF in VHDL zu definieren, deswegen stell ich das einfach mal ganz weit nach hinten auf der TODO-Liste).
Wird daraus auch nichts, bleibt ja immernoch der HiRes-Mode.

Um die Überraschung nicht kaputt zu machen, verrate Ich erstmal nicht die weiteren geplanten Features, aber Ich bin mir sicher, dass die ziemlich nützlich sein werden (zumindest sind das Features, die Ich gerne bei einer SNES gesehen hätte ).

Och, sag ruhig mal. Einige hier (mich eingeschlossen) sind ja sd2snes- und Ultra16-verwöhnt und daher nicht so leicht zu beeindrucken.

Ich möchte noch nichts zu den weiteren Features sagen, da Ich den Aufwand zum Implementieren noch nicht abschätzen kann (bin VHDL noch am vertiefen, bisher ist es nicht allzu schwer zu verstehen, wenn man wie Ich nur ein paar Inputs, Outputs und interne FlipFlops nutzt, um LEDs mit einem Knopf zu steuern ).
Wenn Ich mir ganz sicher bin, dass Ich die Features mit in den BYOS packen kann, werde Ich das entsprechende Update im 1. Post machen .

@Nio:

Kann man schon vorbestellen?

Vorbestellungen nehme Ich noch keine entgegen, da der BYOS im Prinzip noch nicht existiert (im Sinne eines richtigen Produkts).
Solange Ich noch keinen Prototypen zum BYOS habe (sprich, es müsste mindestens die Features im 1. Post unterstützen), wird von mir auch nichts angeboten (man kann ja schlecht etwas anbieten, was nicht existiert).

[Nio]

Dann warst du noch nie auf kickstarter. Aber gute Einstellung von dir, ich verfolge das Projekt gerne weiter.

[borti4938]

@el_seyf:

Ich bin mir nicht sicher, ob ein wirklich ein FPGA sein muss. Wenn man mal auf die Everdrives von Krikkz schaut, dann ist dort jeweils 'nur' ein CPLD (meist ein EPM240T100C5N) drauf.
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

DIe CPLD - VHDL Geschichte ist auch ein Teil der U16 Realisierung gewesen. Ich glaub Borti hätte da auch ein offenes Ohr bei deinem Projekt.

Dazu müsste es open source sein.

[Tommy]

Dazu müsste es open source sein.

Als alter OpenSource-Entwickler finds ich ne gute Einstellung

[el_seyf]

@el_seyf:

Ich bin mir nicht sicher, ob ein wirklich ein FPGA sein muss. Wenn man mal auf die Everdrives von Krikkz schaut, dann ist dort jeweils 'nur' ein CPLD (meist ein EPM240T100C5N) drauf.
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

In den Everdrives (NES,SNES,N64) sind immer ein CPLD und ein FPGA verbaut. Wenn Ich mich recht entsinne, wurde der CPLD nur eingebaut, um den FPGA on the fly mit der richtigen Firmware zu beschreiben, ohne dass ein serieller Flashspeicher genutzt wird (Firmware wird von SD Karte geladen).
Ein Problem das Ich bei CPLD sehe ist die sehr geringe Gate-Anzahl, bei dem, was Ich alles an Funktionen vom iC brauche, denke Ich nicht, dass alles dort Problemlos reinpasst (Ich möchte jetzt völlig vermeiden, dass die SNES irgendwie Dateisystem-Zugriffe machen muss oder Speicher auslesen/schreiben muss, um alles so schnell wie nur möglich zu machen).
Ein beispiel für "SNES regelt Dateisystem-Zugriffe, liest und schreibt Daten von/auf SDKarte" ist der SuperUfoPro8, der hat nur einen CPLD verbaut, der im Prinzip den SNES Datenbus von Parallel in Seriell konvertiert, damit die SD Karte angesteuert werden kann, ansonsten (so wie Ich das verstanden habe) regelt die SNES die Zugriffe auf das Dateisystem (FAT32). (Hauptsächlich besteht die Firmware vom CPLD aus einem DRAM Treiber, damit die SNES den DRAM wie eine normale ROM lesen kann).
Der SuperUfo ist dementsprechend auch langsam, da die SNES für Datenverarbeitung zuständig ist (von SD kopieren ist mit 30 sek langsam, aber etwas auf die SD karte kopieren dauert ewig).

Ich hab auch überlegt, MCU und FPGA zu wählen, aber Ich bin mir sicher, dass Ich das ganze auch nur auf einen FPGA packen kann (größte Herausforderung wäre eine Firmware für FAT32 Zugriffe für den FPGA zu schreiben, das dürfte etwas Zeit in anspruch nehmen).

[borti4938]

@el_seyf:

Ich bin mir nicht sicher, ob ein wirklich ein FPGA sein muss. Wenn man mal auf die Everdrives von Krikkz schaut, dann ist dort jeweils 'nur' ein CPLD (meist ein EPM240T100C5N) drauf.
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

In den Everdrives (NES,SNES,N64) sind immer ein CPLD und ein FPGA verbaut. Wenn Ich mich recht entsinne, wurde der CPLD nur eingebaut, um den FPGA on the fly mit der richtigen Firmware zu beschreiben, ohne dass ein serieller Flashspeicher genutzt wird (Firmware wird von SD Karte geladen).

Sorry - ich hätte präzisieren sollen: ich meine Super Everdrive V2.1 Beim Super Everdrive V2.3 ist dann ja n FPGA drauf, um bei Bedarf DSP-Funktionen bereit zu stellen.

Ich hab auch überlegt, MCU und FPGA zu wählen, aber Ich bin mir sicher, dass Ich das ganze auch nur auf einen FPGA packen kann (größte Herausforderung wäre eine Firmware für FAT32 Zugriffe für den FPGA zu schreiben, das dürfte etwas Zeit in anspruch nehmen).

Generell - das was in Post Nr.1 steht - halte ich n Kombi aus MCU und FPGA am sinnvollsten.

[Ramsis]

(größte Herausforderung wäre eine Firmware für FAT32 Zugriffe für den FPGA zu schreiben, das dürfte etwas Zeit in anspruch nehmen).

Die gute Nachricht ist, dass du das Rad nicht neu erfinden musst -- denn wie die sd2snes-Sourcen verraten, gibt es FatFS.

[borti4938]

[klugscheißermodus]
Das ist für n MCU.
[/klugscheißermodus]
*duck und weg*

[ikari_01]

Man könnte ja am FPGA ne CPU laufen lassen, für die es nen C-Compiler gibt

[el_seyf]

Man könnte ja am FPGA ne CPU laufen lassen, für die es nen C-Compiler gibt

Das war auch meine Idee, als Ich auf FPGA umgestiegen bin. Ich konnte nur bisher keinen CPU finden, der sich Problemlos auf ein Cyclone 2 packen lässt .
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.