snesfreaks.com

Hallo an alle SNES-Optimisten!
Ich präsentiere euch ein Projekt (auch wenn es noch im Anfangsstadium ist), an dem Ich seit einiger Zeit arbeite.
BYOS BIOS4SNES ist ein BIOS für den SNES, und soll beim Anschalten der SNES geladen werden. Zusammen mit einem MicroController (µC) und einem FPGA sollen mehrere Features bereitgestellt werden.
Die Hardware selbst wird aus einem µC (ARM-Prozessor), einem FPGA, einem SD-Karten Slot, 8MB RAM-Speicher und ein paar Steuer-ICs bestehen, und wird dann in der SNES installiert/verbaut.
Bisher geplante Features sind:

ROM-Speicher eines Moduls im Slot auslesen und anzeigen
RAM-Speicher (falls vorhanden) eines Moduls im Slot anzeigen und modifizieren
ROM und RAM eines im Slot eingesteckten Moduls auslesen und auf eine SD-Karte dumpen oder in den internen Speicher laden
RAM-Dumps von einer SD-Karte laden und auf ein im Slot eingestecktes Modul laden
Spiele von einer SD-Karte auf den internen Speicher laden und diese dann starten
Stealth-Modus (direktes Booten eines eingesteckten Moduls)
Cheats
Savestates (bedingt)
SPC Player (bedingt)
Theme-Support

Bedingt werden Special-Chip Module unterstützt, ähnlich wie beispielsweise bei einem SuperUfoPro 8, bei dem man zwar die Spiele im Slot des Moduls starten kann oder ROM und RAM kopieren kann, aber es werden keine Cheats unterstützt, da der Special-Chip direkt mit der ROM verbunden sein muss und mit meinem Setup ist das unmöglich.
Bei den Savestates gibt es ein Problem mit dem APU und dessen RAM, dieser lässt sich nicht einfach dumpen. Ich werde schauen, was sich mit der Hardware machen lässt, um trotzdem daran zu kommen.
Der SPC Player ist funktionstüchtig, spielt aber manche SPC Dateien aus einem unbekannten Grund nicht ab. Ich werde dahingehend noch etwas recherchieren müssen.

Soweit zu den Funktionen, die 100%ig programmierbar sind und auch von mir implementiert werden. Ich bin offen für weitere Features

Update:

Mittlerweile wurde der Name zu "BIOS4SNES" geändert (weil "BYOS" als Name schon anderweitig verwendet wird).
Unterdessen habe Ich mir auch endlich mal eine Hilfsplatine für meinen FPGA designt, da die losen Drähte, die Ich dürftig an meiner SNES hängen hatte, immer wieder gebrochen sind.
Ich werde noch ein Update zu den Funktionen geben, da Ich weitere realisieren konnte (bzw. kann; das Fundament für diese steht zumindest).

Hi, el_seyf, und willkommen im SNESFreaks-Forum!

Ui, das klingt nach einem ambitionierten, äußerst lohnenswerten Projekt! Werde ich auf jeden Fall im Auge behalten.

Und neugierig, wie ich bin, hab ich auch gleich ein paar Fragen zu den Features: Verstehe ich das richtig, dass BYOS hardwareseitig einen internen Speicher mitbringen wird, in den man Modul-ROMs kopieren kann? Wie groß wird dieser Speicher sein? Und bleibt der Speicherinhalt auch nach dem Ausschalten der Konsole erhalten? Was die Unterstützung von SD-Karten betrifft, würde mich interessieren, ob dazu ein Extra-Adapter-Modul benötigt wird oder ob der SD-Slot direkt in der Konsole angebracht wird? Zu guter Letzt natürlich die obligatorische Frage, ob der Lockout-Chip deaktiviert bzw. durch einen Super CIClone ersetzt wird und ob eine wie auch immer geartete 50/60-Hz-Umschaltung geplant ist?

el_seyf hat geschrieben:Bedingt werden Special-Chip Module unterstützt, ähnlich wie beispielsweise bei einem SuperUfoPro 8, bei dem man zwar die Spiele im Slot des Moduls starten kann oder ROM und RAM kopieren kann, aber es werden keine Cheats unterstützt, da der Special-Chip direkt mit der ROM verbunden sein muss und mit meinem Setup ist das unmöglich.

Zumindest bei DSP-Modulen wie Mario Kart sollten Cheats theoretisch schon möglich sein.

el_seyf hat geschrieben:Der BYOS wird koplett im 8-Bit Emulation-Mode laufen, da Ich keinen allzu großen Vorteil sehe in 16-Bit zu programmieren.

Nee! Ernsthaft jetzt?

el_seyf hat geschrieben:Außerdem war der Compiler den Ich nutze ursprünglich nur für den NES gedacht (asm6) und Unterstützt daher keine 16-Bit Opcodes (mit einer Liste von Macros habe Ich ein paar wichtige Opcodes eingebunden).

Da darf ich dir den Umstieg auf einen neueren, 16-Bit-fähigen Compiler dringend ans Herz legen. Der würde nämlich u. a. auch den -- vermutlich unbeabsichtigten -- BRK-Opcode in deiner Start-Routine vermeiden helfen …

Code: Alles auswählen

$00/8000 78          SEI                     A:0042 X:0005 Y:00FF P:EnvMXdIzc
$00/8001 C2 30       REP #$30                A:0042 X:0005 Y:00FF P:EnvMXdIzc
$00/8003 18          CLC                     A:0042 X:0005 Y:00FF P:EnvMXdIzc
$00/8004 FB          XCE                     A:0042 X:0005 Y:00FF P:EnvMXdIzc
$00/8005 A2 FF       LDX #$FF                A:0042 X:0005 Y:00FF P:envMXdIzC
$00/8007 01 9A       ORA ($9A,x)[$00:5555]   A:0042 X:00FF Y:00FF P:eNvMXdIzC
$00/8009 A9 00       LDA #$00                A:0057 X:00FF Y:00FF P:envMXdIzC
$00/800B 00 48       BRK #$48                A:0000 X:00FF Y:00FF P:envMXdIZC
*** BRK
$00/8008 9A          TXS                     A:0000 X:01FF Y:00FF P:envmxdIzc
$00/800C 48          PHA                     A:0000 X:01FF Y:00FF P:envmxdIZc
$00/800D 48          PHA                     A:0000 X:01FF Y:00FF P:envmxdIZc
$00/800E AB          PLB                     A:0000 X:01FF Y:00FF P:envmxdIZc
$00/800F 2B          PLD                     A:0000 X:01FF Y:00FF P:envmxdIZc
$00/8010 E2 30       SEP #$30                A:0000 X:01FF Y:00FF P:envmxdIZc
$00/8012 38          SEC                     A:0000 X:00FF Y:00FF P:envMXdIZc
$00/8013 FB          XCE                     A:0000 X:00FF Y:00FF P:envMXdIZC

Ernsthaft, bei einem derart ambitionierten Projekt wie BYOS wirst du meines Erachtens nicht durchweg auf die Vorteile von 16-Bit-Operationen verzichten wollen. Davon abgesehen: Wenn du deine Kenntnisse erst einmal auf die zusätzlichen 65816-Befehle ausdehnst, werden dir Tricksereien wie diese hier erspart bleiben:

Code: Alles auswählen

$00/81B4 48          PHA                     A:00C2 X:0040 Y:00FF P:EnvMXdIzc
$00/81B5 8A          TXA                     A:00C2 X:0040 Y:00FF P:EnvMXdIzc
$00/81B6 48          PHA                     A:0040 X:0040 Y:00FF P:EnvMXdIzc
$00/81B7 98          TYA                     A:0040 X:0040 Y:00FF P:EnvMXdIzc
$00/81B8 48          PHA                     A:00FF X:0040 Y:00FF P:ENvMXdIzc

Dann benötigst du nämlich nur noch folgende Instruktionen, um exakt dasselbe zu erreichen:

Code: Alles auswählen

pha
phx
phy

el_seyf hat geschrieben:Ich habe auch schon vom Ultra16-BIOS gelesen, Ich konnte nur keine richtige Feature Liste finden, sah mir so aus als würde mithilfe von einem CPLD die SNES den Header von einem Modul lesen und dann so im richtigen Modus (50/60Hz) starten, Regionlocks umgehen, und einen Memory Viewer zum Speicher modifizieren haben.

Eine Feature-Liste des ursprünglichen Ultra16 habe ich hier für dich rausgesucht.

el_seyf hat geschrieben:Ich hänge auch die SNES Rom an, wer möchte, kann es mal auf einer SNES testen und kurze Rückmeldung geben, ob es so aussieht wie im GIF .

Zumindest unter higan-accuracy scheint irgendetwas mit der Bildschirmhelligkeit nicht zu stimmen -- aber ich teste das Ganze gerne heute Abend nochmal auf echter Hardware.

Lieben Gruß,
Ramsis

hört sich interessant an, bin gespannt was dabei rauskommt.

mfg md

Und neugierig, wie ich bin, hab ich auch gleich ein paar Fragen zu den Features: Verstehe ich das richtig, dass BYOS hardwareseitig einen internen Speicher mitbringen wird, in den man Modul-ROMs kopieren kann? Wie groß wird dieser Speicher sein? Und bleibt der Speicherinhalt auch nach dem Ausschalten der Konsole erhalten?

Ja, richtig verstanden. Ich plane SRAM Speicher zu nutzen, also bleibt nach dem Abschalten nichts erhalten, dafür wird aber eine unendliche Lebensdauer vom Chip gewährleistet (größere Flash Chips, die als Alternative dienen könnten, haben eine sehr kurze Lebensdauer wenn Ich mehr als 32MBit nutzen will).
Zur Größe plane Ich mindestens 8MByte (64Mbit), damit alle offiziellen Titel unterstützt werden (Je nach Preis für die ICs werde Ich mich entscheiden, wie viel Speicher es wird, aber das wird noch etwas dauern bis Ich mich damit auseinandersetze).

Was die Unterstützung von SD-Karten betrifft, würde mich interessieren, ob dazu ein Extra-Adapter-Modul benötigt wird oder ob der SD-Slot direkt in der Konsole angebracht wird?

Ich plane den SD-Slot direkt in der Konsole zu verbauen. Ist meiner Meinung nach das einfachste, schnell mit einer Feile ein Rechteck ins Gehäuse und den SD-Slot befestigen.

Zu guter Letzt natürlich die obligatorische Frage, ob der Lockout-Chip deaktiviert bzw. durch einen Super CIClone ersetzt wird und ob eine wie auch immer geartete 50/60-Hz-Umschaltung geplant ist?

Damit hab Ich mich ehrlichgesagt nicht beschäftigt (Funktion eines solchen Mods), wobei es eigentlich nur Sinn machen würde, solch ein Feature miteinzubinden. Ich werde mich sobald ich das Menü stehen hab mit der Hardware eingehender beschäftigen.

Zumindest bei DSP-Modulen wie Mario Kart sollten Cheats theoretisch schon möglich sein.

Stimmt, der DSP1 ist (soweit Ich weiß) nicht mit der ROM verbunden. Aber es wird wahrscheinlich noch mehr Hardware, als geplant, nötig sein, um das möglich zu machen (hauptsächlich Buffer- und AND-Gates, die zwischen eingestecktem Modul und internem Speicher wechseln, wenn die richtige Adresse angesteuert wird). Sollte so etwas nötig sein (Ich muss mich wie gesagt noch etwas eingehender mit der Hardware beschäftigen), damit DSP Spiele von internem Speicher zusammen mit Cheats funktionieren, werde Ich es vorerst nicht auf die Feature-Liste nehmen.

Da darf ich dir den Umstieg auf einen neueren, 16-Bit-fähigen Compiler dringend ans Herz legen. Der würde nämlich u. a. auch den -- vermutlich unbeabsichtigten -- BRK-Opcode in deiner Start-Routine vermeiden helfen …

Code: Alles auswählen

$00/8000 78          SEI                     A:0042 X:0005 Y:00FF P:EnvMXdIzc
$00/8001 C2 30       REP #$30                A:0042 X:0005 Y:00FF P:EnvMXdIzc
$00/8003 18          CLC                     A:0042 X:0005 Y:00FF P:EnvMXdIzc
$00/8004 FB          XCE                     A:0042 X:0005 Y:00FF P:EnvMXdIzc
$00/8005 A2 FF       LDX #$FF                A:0042 X:0005 Y:00FF P:envMXdIzC
$00/8007 01 9A       ORA ($9A,x)[$00:5555]   A:0042 X:00FF Y:00FF P:eNvMXdIzC
$00/8009 A9 00       LDA #$00                A:0057 X:00FF Y:00FF P:envMXdIzC
$00/800B 00 48       BRK #$48                A:0000 X:00FF Y:00FF P:envMXdIZC
*** BRK

Der BRK Opcode (der mich zuerst auch sehr verwirrt hat) wird nicht ausgeführt, denn vorher werden die A,X und Y Register in den 16 Bit Modus gesetzt (REP #$30) und der Emulation-Mode ausgestellt.
Damit werden die Bytes anders interpretiert (für LDA werden dann 3 Bytes eingelesen

).
Der Code wird so von der SNES eingelesen (wenn Ich dem no$sns Debugger glauben darf):

Code: Alles auswählen

$00/8000 78          SEI                    
$00/8001 C2 30       REP #$30;wechselt A,X,Y in 16 Bit Modus               
$00/8003 18          CLC                     
$00/8004 FB          XCE;Emulation-Mode aus                    
$00/8005 A2 FF 01    LDX #$01FF                
$00/8008 9A          TXS;stellt Stack auf $01FF (ähnlich wie bei der NES) 
$00/8009 A9 00 00    LDA #$0000              
$00/800C 48          PHA

Ich kann mir wirklich nicht vorstellen, dass Ich den 16 Bit Modus zu irgendwas gebrauchen kann, außer Daten schneller von A nach B zu kopieren, wenn ich den DMA Controller nicht nutze (Man kann mich aber gerne auch eines Besseren belehren).
Also bisher komme Ich sehr gut mit dem 8-Bit-Programmieren zurecht

Ernsthaft, bei einem derart ambitionierten Projekt wie BYOS wirst du meines Erachtens nicht durchweg auf die Vorteile von 16-Bit-Operationen verzichten wollen.

Also, um ehrlich zu sein, finde Ich, dass es nicht wirklich allzu schwer ist, ein solches Projekt auf die Beine zu stellen (zumindest nicht schwerer als ein komplettes Spiel von Grund auf zu programmieren). Das liegt aber auch wahrscheinlich daran, dass Ich den µC die meiste Arbeit machen lasse (Die SNES wird im Prinzip nur für Eingabe über das Pad und Ausgabe über den Bildschirm genutzt). Im Moment plane Ich einen AVR µC zu nutzen, je nachdem, wie schnell dieser Daten von einem externen Speicher und SD Karten überträgt (es soll nicht so lahm wie beim SuperUfo werden).

Davon abgesehen: Wenn du deine Kenntnisse erst einmal auf die zusätzlichen 65816-Befehle ausdehnst, werden dir Tricksereien wie diese hier erspart bleiben:
Code: Alles auswählen
$00/81B4 48          PHA                     A:00C2 X:0040 Y:00FF P:EnvMXdIzc
$00/81B5 8A          TXA                     A:00C2 X:0040 Y:00FF P:EnvMXdIzc
$00/81B6 48          PHA                     A:0040 X:0040 Y:00FF P:EnvMXdIzc
$00/81B7 98          TYA                     A:0040 X:0040 Y:00FF P:EnvMXdIzc
$00/81B8 48          PHA                     A:00FF X:0040 Y:00FF P:ENvMXdIzc
Dann benötigst du nämlich nur noch folgende Instruktionen, um exakt dasselbe zu erreichen:
Code: Alles auswählen
pha
phx
phy

Ok, das war wirklich unnötig von mir

Ich habe, bevor Ich dieses Projekt gestartet habe, nur für NES (und ein bisschen auch für den Gameboy) programmiert. Ich hatte eine Vorlage für NES Programme, die Ich schnell für SNES umgeschrieben habe, und das ist in meiner NMI Routine wohl so geblieben.
Natürlich habe Ich die PHX/PHY Opcodes auch in den Macros.

Eine Feature-Liste des ursprünglichen Ultra16 habe ich hier für dich rausgesucht.

Danke. Von den Features her, so denke Ich mal, steht BYOS dem Ultra16 in nichts nach (außer den Satellaview Features, aber die scheinen nicht allzu interessant).

Zumindest unter higan-accuracy scheint irgendetwas mit der Bildschirmhelligkeit nicht zu stimmen -- aber ich teste das Ganze gerne heute Abend nochmal auf echter Hardware.

Ich Debugge mit no$sns (und teilweise auch bsnes-debugger), da schien mir alles einwandfrei. Ich werde aber den Test auf richtiger Hardware noch abwarten

Immer wenn ich in einem Thread mal so zu 99% gar nichts verstehe bin ich davon überzeugt das an irgend etwas ganz tollem gearbeitet wird. Also, Daumen hoch!

Ein wirklich interessantes Projekt. Ich werde es mit Spannung verfolgen.

ein kleiner Tipp und guter Rat vorab:
Nimm einen CPLD anstelle des Mikrocontrollers. Mit dem wirst du zu hohe Latenzen haben, da du ja zwischen BYOS und Modul n Bankswitch realisieren musst. D.h., dass die Steuersignale über den Mikrocontroller nahezu Verzögerungsfrei laufen müssen.
Oder wie willst du zwischen den Speichern umschalten?

Auf jeden Fall viel Erfolg

borti4938 hat geschrieben: ein kleiner Tipp und guter Rat vorab:
Nimm einen CPLD anstelle des Mikrocontrollers. Mit dem wirst du zu hohe Latenzen haben, da du ja zwischen BYOS und Modul n Bankswitch realisieren musst. D.h., dass die Steuersignale über den Mikrocontroller nahezu Verzögerungsfrei laufen müssen.
Oder wie willst du zwischen den Speichern umschalten?

Danke für den Tipp, aber ein µC wird mehr als genug sein, um zwischen BYOS, eingestecktem Modul und internem SRAM zu wechseln.
Die Latenzzeiten sind mir auch bewusst, der µC wird auch nicht zwischen SNES Daten- oder Adressbus und ROMs geschaltet, sondern alles wird gleichzeitig am gleichen Bus hängen (zumindest sieht so mein Plan aus). Der µC wird dann zusammen mit einem IC (zB. einem einfachen 74HC139) die /OE Signale (oder /CE, je nachdem, welches die SNES bei ROM Access nutzt) steuern.
Ich muss mich noch etwas mehr mit der SNES Hardware beschäftigen, um mehr über die geplante Hardware reden zu können. Im Moment nehme Ich an, dass diese sehr ähnlich in der Funktionsweise zur NES ist (da der Prozessor nur ein Upgrade ist).
Das einzige, was meiner Meinung nach gegen einen µC sprechen könnte, wäre die Zeit,die zum Kopieren von Daten von einer SD-Karte auf den internen SRAM benötigt wird. Ich werde dazu aber noch Tests machen.
Ich habe schon so etwas in der Richtung für den NES gemacht. Es war ein Modul mit mehreren Spielen auf einer 4MByte ROM und einem Menü auf einer 2. ROM, und einem µC, der von der NES angesteuert wurde (ein ATMega328). Ich habe ein AND-Gate genutzt, um einen bestimmten Adressbereich (in dem Fall $6000-$7FFF) für den µC und einen 8-Bit FlipFlop zu reservieren, und wenn die NES in diesen geschrieben hat, wurde auf einem Pin vom ATMega328 ein Interrupt ausgelöst, der signalisiert hat, dass Daten empfangen werden sollten. Der 8-Bit FlipFlop hat dafür gesorgt, dass der µC keine falschen Daten einliest (der µC war für den NES Datenbus zu langsam, um die Daten synchron einzulesen, der hat manchmal einfach das nächste oder übernächste Byte auf dem Bus eingelesen). Wenn ein Spiel ausgewählt wurde, hat die NES die Spielnummer zum µC (über den FlipFlop) geschickt und der µC hat am 4MByte Rom die entsprechenden Adresspins gesetzt, das /OE Signal vom Menü HIGH gesetzt und das /OE Signal vom 4MByte Spiele Rom LOW gesetzt, da die NES aktiv nur das /CE Signal einer ROM steuert, im "Normalfall" ist /OE immer auf GND gelegt. Zuletzt wurde ein interner Reset von der NES ausegführt und das gewählte Spiel wurde gestartet. (...Ich hoffe die Funktionsweise vom Modul ist halbwegs klar geworden..)
So ähnlich werde Ich es dann auch beim BYOS machen.

Kurzes Update zum BYOS:
Ich habe mittlerweile auch ein Prototyp-Menü programmiert. Bilder werden in den 1. Post gehangen, sobald es ansehnlich ist (Bisher nur ein einfacher Textparser mit Font vom Gameboy Tetris, ließ sich direkt im richtigen Format dumpen

).
Die Arbeit an der Firmware für den µC hat auch schon begonnen:
Bisher habe Ich den Zugriff auf eine SD-Karte programmiert, inklusive Datenverwaltung (also ein vollwertiger Datenbrowser, mit dem Daten gelesen, modifiziert, gespeichert, gelöscht, erstellt usw. werden können. Interface läuft bis jetzt nur über eine serielle Schnittstelle, sieht so aus und lässt sich bedienen wie Command unter Windows oder Shell unter Linux).
Dateinamen werden mit LongFileNames angezeigt (sprich eine ROM kann bis zu 255 Zeichen im Dateinamen haben). 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.
SNES Header wird vom µC im Dateibrowser erkannt und der Headername von einer ausgewählten ROM wird angezeigt.
Je nachdem, welcher µC am Ende zum Einsatz kommt, wird es eine Einschränkung im Bezug auf maximale Dateieinträge pro Ordner geben (hat mit dem µC internen RAM zu tun). Im Moment liegt die bei 1024 Einträgen pro Ordner, mehr Dateien werden nicht angezeigt.
Der Browser ist auch schon SNES-Freundlich geschrieben, es wird für das Interfacing nur wenig Code von der SNES benötigt.
Als nächstes steht der Bau von einem Debug Modul auf dem Plan, mit dem Ich den µC und eine ROM gleichzeitig an den SNES Datenbus hänge und dann mal das Menü zusammen mit dem Datenbrowser teste.

Hey, el_seyf,

was du schreibst, klingt alles sehr, sehr zuversichtlich und entschlossen, von daher will ich dir gar nicht weiter dreinreden, sondern sage einfach nur: Daumen hoch und weiter so.

Nur eine kleine Anmerkung zum Thema Debugging: no$sns ist nicht gerade der akkurateste Emulator. Benutz lieber Geiger's SNES9x Tracer oder -- noch besser -- bsnes plus, das ist der momentan aktuellste und Feature-reichste Debugger.

Lieben Gruß,
Ramsis

Ramsis hat geschrieben:Hey, el_seyf,

was du schreibst, klingt alles sehr, sehr zuversichtlich und entschlossen, von daher will ich dir gar nicht weiter dreinreden, sondern sage einfach nur: Daumen hoch und weiter so.

Nur eine kleine Anmerkung zum Thema Debugging: no$sns ist nicht gerade der akkurateste Emulator. Benutz lieber Geiger's SNES9x Tracer oder -- noch besser -- bsnes plus, das ist der momentan aktuellste und Feature-reichste Debugger.

Lieben Gruß,
Ramsis

Ramsis, Ich muss dir für deine Empfehlung vom bsnes-plus Emulator danken.
Du hattest Recht mit dem BRK, der am Anfang vom Code ausgeführt wurde, und Ich hab auch herausgefunden, woran es lag, dass der in no$sns nicht ausgeführt wurde (und in meiner Version von bsnes, die ziemlich alt ist):
Wenn die SNES im Emulationsmodus ist, werden die SEP und REP Befehle ausgeführt, haben aber keinen Effekt auf die Register, sprich die bleiben im 8-Bit Modus. In meinem Code habe Ich zuerst REP #$30 ausgeführt und danach den Emulationsmodus ausgeschaltet, daher blieben die Register im 8-Bit Modus und der BRK wurde ausgeführt.
In no$sns haben SEP und REP auch im Emulationsmodus einen Effekt auf die A,X,Y Register, in bsnes nicht (was in diesem Fall dem Verhalten der SNES entspricht).
Ich habe mein Menü auch auf meiner SNES zum laufen bekommen (nachdem sie mir zunächst ständig eingefroren ist durch den Fehler, habe Ich einen BSOD programmiert, der ein paar Daten über den letzten Zustand der SNES auspuckt, wenn sie crasht), Tests mit dem µC stehen jetzt an. Update zum letzten Stand von BYOS im 1. Post.

Grüße,

das Projekt ist wirklich interessant. Ich hoffe du verlierst nicht das Interesse wenn es schwierig wird. Vor allem die Realisierung des SD Features wird wohl sehr lang dauern.

Das Menü schaut schon sehr gut aus. Hast du eine Quelle wie man sowas macht? Oder kannst du auch deine Source eventuell releasen? Ich will mir auch etwas mit einem Menü realisieren, jedoch fehlt mir der Ansatz beim Menü selbst schon.

Hat aber nix mit BIOS zu tun!

Gruß

red

el_seyf hat geschrieben:Ramsis, Ich muss dir für deine Empfehlung vom bsnes-plus Emulator danken.

Don't mention it.

Redscorpion hat geschrieben:Hast du eine Quelle wie man sowas macht? Oder kannst du auch deine Source eventuell releasen? Ich will mir auch etwas mit einem Menü realisieren, jedoch fehlt mir der Ansatz beim Menü selbst schon.

[hust] sd2snes- und/oder PowerPak-Sourcen anschauen und (bei Unklarheiten) Fragen stellen ... [/hust]

Redscorpion hat geschrieben: Vor allem die Realisierung des SD Features wird wohl sehr lang dauern.

Also das ist im Prinzip schon fertig (vorausgesetzt Ich entscheide mich nicht doch für einen anderen µC). Das war aber auch keine wirkliche Herausforderung, dank vorgefertigter Bibliotheken zum ansteuern einer SD-Karte (Die SNES wird nicht direkt die SD-Karte ansteuern, sondern Befehle an den µC geben und der kümmert sich dann um die SD-Karte).

Das Menü schaut schon sehr gut aus.

Ehrlich?!

Ich finde nicht, dass mein Menü optisch viel her macht... Besonders die schwarze Font auf dem scrollenden Hintergrund ist nicht gut lesbar. Ich werde das später aber noch verbessern.

Hast du eine Quelle wie man sowas macht? Oder kannst du auch deine Source eventuell releasen? Ich will mir auch etwas mit einem Menü realisieren, jedoch fehlt mir der Ansatz beim Menü selbst schon.

Eine Quelle habe bzw. nutze Ich nicht. Der Code für die SNES ist im Moment 100% selbst geschrieben (erarbeitet).
Das Menü an sich besteht hauptsächlich nur aus einem Textparser, und einer Font im SNES Format, bei der die Zeichen-Offsets denen von ASCII Codes entsprechen (so hab Ich es zumindest gemacht, damit Ich in meinem Code den Text direkt abtippen kann und nicht erst in HEX-Werte umrechnen muss

).
Die Source kann Ich dir gerne geben (ist eigentlich kein komplizierter Code):

Code: Alles auswählen

load_text:
stz $2116;LOW byte VRAM addr
lda #$74
sta $2117;HIGH Byte VRAM addr
ldx #$00
ldy #$20;32 Tiles per row
ld_title:
lda _text,x
cmp #$FE
beq end_title
cmp #$FF
bne no_next_line4
lda #$00
next_line4:
sta $2118;VRAM DATA LOW Byte
lda #$20; Set Priority Byte
sta $2119;VRAM DATA HIGH Byte
dey
cpy #$01
bne next_line4
no_next_line4:
sta $2118;VRAM DATA LOW Byte
lda #$20; Set Priority Byte
sta $2119;VRAM DATA HIGH Byte
inx
dey
bne no_reload_y4
ldy #$20
no_reload_y4:
jmp ld_title
end_title:
rts

_text:
DB "", $FF, $FF, $FF
DB "       BYOS - A SNES BIOS ", $FF
DB "     - by Yasin (el_seyf) -", $FF
DB "", $FF, $FF, $FF
DB " MENU:",$FF
DB "  PLAY GAME",$FF
DB "  OPTIONS",$FF
DB "  BSOD TEST",$FF

DB $FE;;End of Menu TEXT

Ich glaub, ein Bug ist noch im Code, wenn eine Zeile 32 Zeichen hat oder mehr, aber ist ja nur zum Testen, der wird später mit einem besseren ersetzt.
Wenn ein $FF in einer Zeile steht, bedeutet das, dass eine neue Zeile angefangen werden soll. $FE signalisiert der Routine das Ende vom Text (steht $FE nicht am Ende, hängt sich das Programm auf). Wie man auch schnell merken wird, kann man maximal nur 256 Zeichen pro Text haben. Ich muss zur Routine noch sagen, dass Ich sie 1:1 aus einem meiner NES Programme kopiert habe, und nicht wirklich SNES-Optimiert habe.
Vor Aufruf der Routine müssen noch ein paar Register eingestellt werden:
A,X,Y müssen alle auf 8-Bit gestellt werden, sonst funktioniert die Routine nicht (um sie im 16-Bit Modus zu nutzen, müsste man ein paar Befehle ändern). Dann muss $2115 auf #$80 gestellt werden, um den VRAM nach dem Schreiben von $2119 zu inkrementieren. Zuletzt noch die Background Register einstellen (Font ist 2bpp, nutzt die 1. Palette im CGRAM und die Map wird in VRAM $7400 geschrieben, wie man der Routine entnehmen kann). Ich nutze die Routine im BG Mode 1 auf BG3, mit BG3 Priority-Flag gesetzt, das heißt, dass alle Tiles mit Priorität im BG3 auf dem obersten Layer gerendert werden.
Ich hoffe, Ich habe nichts vergessen, was noch zu erwähnen wäre.

el_seyf hat geschrieben:Ich habe mein Menü auch auf meiner SNES zum laufen bekommen (nachdem sie mir zunächst ständig eingefroren ist durch den Fehler, habe Ich einen BSOD programmiert, der ein paar Daten über den letzten Zustand der SNES auspuckt, wenn sie crasht)

Tolle Idee übrigens! Werde die BRK/COP-Vektoren wohl demnächst auch in meinem RPG als Error-Handler nutzen.

el_seyf hat geschrieben:
Redscorpion hat geschrieben:Das Menü schaut schon sehr gut aus.
Ehrlich?! Ich finde nicht, dass mein Menü optisch viel her macht...

Da sind wir schon zu zweit!

Habe aber ganz ehrlich keine Zweifel daran, dass das noch Form annimmt, insbesondere wenn irgendwann Themes/Skins unterstützt werden.

Ähm ich verstehe ja allg. nicht viel wenn es um programmierung geht, aber was mich mal interessieren würde (kann auch sein, dass ich es grad überlesen hab), wie soll das ganze später funktionieren? Soll das eine Cartridge werden wie das SD2SNES oder soll das ganze direkt im SNES passieren? Bei letzterem ist dann die Frage, wie man den SD-Slot verbauen soll?

Sry falls die Fragen blöd sind

kolwe-x hat geschrieben:Ähm ich verstehe ja allg. nicht viel wenn es um programmierung geht, aber was mich mal interessieren würde (kann auch sein, dass ich es grad überlesen hab), wie soll das ganze später funktionieren? Soll das eine Cartridge werden wie das SD2SNES oder soll das ganze direkt im SNES passieren? Bei letzterem ist dann die Frage, wie man den SD-Slot verbauen soll?

Sry falls die Fragen blöd sind

Der BYOS wird in der Konsole installiert/eingebaut, der SD-Karten Slot kann befestigt werden, wo einem lieb ist (ich dachte über dem Controller Port an der Front). Ich werde den 1. Post mit dem nächsten Update um weitere Details erweitern (Die Frage wurde nämlich schon beantwortet

).

Neues zum BYOS:
Momentan habe ich Probleme, den mC und die SNES miteinander reden zu lassen (stellt sich als schwieriger raus, als ich gedacht hätte). Ich habe mit viel Mühe gerade einmal eine Datei-Liste schicken können (was 30sek. für 10 Dateieinträge gedauert hat... Das muss auf jedenfall schneller werden). Bis zum nächsten Update kann es etwas dauern.
Was Ich schonmal vorab zu den Features sagen kann: es wird keine Dateisortierung unterstützt. Mein Algorithmus zum Sortieren der Datei Einträge auf der SD Karte während dem Einlesen braucht einfach zu lang (ein Ordner mit 100 Dateien braucht 1min, und Ich hab weitaus mehr als nur 100 Dateien pro Ordner). Die Dateien werden in der Reihenfolge angezeigt, in der sie auf die SD-Karte kopiert wurden, dh. aktuell kopierte Datei als letztes (das hat mit dem FAT Dateisystem zu tun, oder generell wie Dateisysteme funktionieren). Es gibt aber glücklicherweise eine andere Möglichkeit als "Live-Sortierung" durch den mC: man kann die FAT Dateieinträge einfach auf dem Computer alphabetisch mit einem kleinen Programm sortieren, welches Ich dann dem BYOS beilegen werde.

snesfreaks.com

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

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

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo

Re: BYOS - Ein BIOS für Super Nintendo