Dom's Advanced SNES ROM Utility

Zitat von Svambo

Hey Dom,

hab mir das Tool grad mal angeschaut. Das sieht doch schon richtig gut aus.

So wie ich das sehe ist das Tool ja in erster Linie für Bastler interessant, daher finde ich deine Idee IPS-patching einzubauen eigentlich sehr passend.

Als Vorschlag: Was ich zu meiner Löter-Zeit spannend gefunden hätte, wäre eine Möglichkeit, sich potentielle Spender-Spiele anzeigen zu lassen. Hab mir damals mit irgendeinem Tool mal eine Liste mit Spieledaten angelegt (s.Anhang). Eine Funktion um da automatisch die passenden rauszusuchen hätte mir damals sehr gefallen...

Hi Svambo,

und erstmal danke für dein Feedback

Wäre es denn eine Option, wenn das IPS-Patching funktioniert, sobald sich die "flips.exe" oder "Lunar IPS.exe" im selben Verzeichnis befindet?

Oder ich frage mal ikari01, ob ich den Code von seinem IPS Patcher implementieren darf, das wäre natürlich die beste Lösung

Das wären zumindest mal die beiden Optionen, die auf die Schnelle realisierbar sind

Eine Liste mit potenziellen Spendermodulen aufzuführen würde das Mitführen einer Datenbank voraussetzen, was den Rahmen des Projekts sprengen würde. Aber ich behalte das mal im Hinterkopf Generell bin ich kein Fan davon Module zu opfern, dafür verwende ich aktuell die Kits von Mr Tentacle bei Tindie (nicht Tinder ). Außer es handelt sich natürlich um Spiele mit einem Special Chip, da lässt sich das leider noch nicht vermeiden Den Punkt notiere ich mal unter den langfristigen Zielen des Tools! Und vielen Dank für deine Liste, die wird sicherlich noch hilfreich sein

Bei Momotarou Dentetsu Happy ist mir auch noch was sehr komisches aufgefallen

Dies wird über die Plausibilitätsprüfung als HiROM zwar korrekt erkannt, da sich der Header auch hier befindet, findet aber im Byte des ROM types den Wert 0x3A.

Weil man das ganze mit einer Bitmaske versehen muss (0x37) kommt am Ende 0x32 heraus, was wiederum aussagt, dass es sich um ein ExLoROM handelt.

So kommt auch die Anzeige des falschen ROM types "ROM+ST-018+RAM+Battery" statt dem korrekten Wert "ROM+SPC-7110+RAM+Battery" zustande.

Das scheint aber, entgegen aller Infos die ich zu dem Spiel habe, falsch zu sein...

Ist das ein Fehler des ROMs oder mache ich da was falsch?

Zitat von Super NES Programming/SNES memory map

The bitmask to use is 001A0BCD, the basic value is $20:

- A == 0 means SlowROM (+ $0), A == 1 means FastROM (+ $10).

- B == 1 means ExHiROM (+ $4)

- C == 1 means ExLoROM (+ $2)

- D == 0 means LoROM (+ $0), D == 1 means HiROM (+ $1), is used with B and C in case of extended ROMs.

Demnach als bitmask 0x37 (0011 0111)

Ich gehe davon aus, dass es ein Fehler im ROM sein wird und nehme das einfach als weitere Ausnahme für dieses Spiel hinzu

Erst braucht es eine Sonderbehandlung bei der Berechnung der Checksum und jetzt auch noch das...

Zitat von Ice Man

$03=ROM+DSP4 (Wenn LoROM)

Das kann irgendwie nicht stimmen

Bei Pilotwings geht das in die Hose.

Wo hattest du diese Tabelle her?

Ich werde die Tage mal alle ROMs mit Special Chips einzeln durchprüfen und mir Notizen machen, wo es noch Probleme gibt

Werde mir das heute Abend oder am Wochenende mal genauer ansehen was da noch nicht stimmt

Zitat von Ice Man

Für $xFD5:

xxAAxxxB; AA==11 means FastROM ($30). If B is set, it's HiROM, otherwise it's LoROM.

Ich glaube du verwendest diese Seite hier als Quelle so wie es aussieht.

Aber da musst du vorsichtig sein! Diese Infos sind alles andere als vollständig bzw. nur teilweise korrekt!

Die haben in ihrer Bitmaske* die Ex-ROMs nicht berücksichtig.

Was ich damit eigentlich sagen wollte war, dass Momotarou Dentetsu Happy im Map Mode Byte an Offset 0xFFD5 einen falschen Wert drin stehen hat.

Hier findet man 0x3A! Wendet man darauf die Bitmaske 0x37 an, also 0x3A & 0x37, so erhält man logischerweise 0x32 als Ergebnis. Schauen wir in dieser Tabelle nach (Achtung! Hier steht in der Überschrift zwar "How do I recognize the ROM type?" aber ist falsch und sollte eigentlich "How do I recognize the map mode?" heißen), welche bei allen anderen Spielen zu stimmen scheint, sagt uns das aber, dass es sich um ein ExLoROM handelt. Das ist aber falsch und somit glaube ich, dass das ROM bereits vom Hersteller verhunzt wurde.

Generell glaube ich aber, dass wir bei der Thematik etwas aneinander vorbei geredet haben

Wie bereits gesagt werde ich das die nächsten Tage mal noch ordentlich aufschlüsseln und darüber nachdenken

*Bitmaske, weil es auch sein könnte, dass, je nach Hersteller, die undefinierten Bits entweder 1 oder 0 gesetzt oder sogar auch für ganz eigene Zwecke genutzt werden konnten.

Zitat von Ice Man

Woher du die #$37 nimmst ist mir dennoch ein Rätsel.. .

Das ist nur eine Bitmaskierung, um zu verhindern, dass die undefinierten Bits keinen Einfluss auf das korrekte Auslesen haben.

Stelle dir vor, der Hersteller bekommt gesagt, dass sie in Byte (40)7FD5 bzw. (40)FFD5 den map mode festzulegen haben und sich dabei an folgendes Muster halten müssen: xx1A xBCD

1 = Fester Wert

A = 0 für SlowROM / 1 für FastROM

B = 1 für ExHiROM

C = 1 für ExLoROM

D = 0 für LoROM / 1 für HiROM

Da x undefiniert ist und rein theoretisch von jedem Hersteller für eigene Zwecke benutzt werden könnte, muss man ja beim Auslesen des Bytes (40)7FD5 bzw. (40)FFD5 irgendwie sicherstellen, dass evtl. gesetzte zusätzliche Bits keinen Einfluss haben. Man weiß ja auch nicht, wie die Hersteller die x Stellen gefüllt haben. Die einen machen da 0 rein, die anderen 1.

Da das Muster für xx1A xBCD (also die relevanten Bits) in Binär dann 0011 0111 ist erhaltet man als Bitmaske den Hexadezimalen Wert 0x37.

Was man dann nur noch machen muss, um diesen "Filter" anzuwenden wäre den map mode an (40)7FD5 bzw. (40)FFD5 auszulesen und diesen logisch mit 0x37 (0011 0111) zu Verunden (&). So erhaltet man den map mode sozusagen wieder in bereinigter Form und kann diesen weiter verarbeiten.

Ich hoffe, ich konnte das soweit verständlich rüberbringen

Wenn nicht, dann darfst du gerne nachhaken!

Zitat von Ice Man

Nachtrag: Wirs dem Programm auch noch ein vernünftiges Icon geben?

Ich bin nicht so gut im Icon Design... Wenn sich jemand findet und ein passendes schickes Icon machen mag, verwende ich das sehr gerne

Kleineres Update auf v0.4!

• Habe das "Momotarou Densetsu"-Phänomen nun gefixed! Sobald das Spiel erkannt wird, gibt die Funktion zum lesen des map mode nun einfach HiROM zurück
  • Falls jemand eine besser Lösung kennt: bitte melde dich!
• Sobald ein DSP-ROM über den ROM type 0x03 erkannt wird mache ich das nun anhand des ROM speeds anstatt dem map mode fest, ob es DSP-1 oder DSP-4 ist
  • Wenn ROM speed != 0x30 dann DSP-1 andernfalls DSP-4
• Die Oberfläche wurde etwas verbreitert, damit auch längere ROM types schöner und vollständiger angezeigt werden

Für die Sache mit nicht bzw. falsch erkanntem (S)RAM bei manchen Spielen habe ich bereits einen Ansatz, aber das wird heute nichts mehr

Bitte testet so viel ihr wollt und könnt und berichtet eure Auffälligkeiten, das würde extrem helfen!

Danke mal, werde ich heute Abend mal rein sehen

Zitat von Ice Man

Übrigens, wieso wurde CHECKSUMS eigentlich C H E C K S U M S geschrieben und FUNCTIONS auch F U N C T I O N S während der Rest ohne Leerzeichen klar kommt? Fällt mir jetzt erst auf, xD.

Gute Frage... Ich fand es anfangs eine gute Idee die Schriftzüge etwas länger zu ziehen und damit auch auffälliger zu gestalten.

Später fand ich das dann irgendwie doch etwas blöd und habe die Schriftzüge lieber unterstrichen

Zitat von Ice Man

Mach alles einheitlich. Sieht sonst doof aus finde ich.

Schon erledigt! Ist mir irgendwie nie aufgefallen

Das "Momotarou Densetsu"-Phänomen konnte ich allerdings bei allen SPC-7110 Spielen feststellen!

Da das alles HiROMs sind, definiere ich nun alles was 0x3A als map mode im header hat zusätzlich einfach als HiROM

Sollte also somit behoben sein

Dann hatte ich noch bemerkt, dass Doom als GSU-1 erkannt wird, obwohl es einen GSU-2 hat.

Bis auf die SA-1 und DSP-1 Spiele, welche ich noch nicht getestet habe, und Doom sieht es momentan richtig aus

Star Wing / Star Fox erkennt eben den RAM auch noch nicht, aber da bin ich noch dran!

Ein Update gibt es heute keines, da die Änderungen heute imho zu geringfügig waren.

Edit: Soll es weiterhin GSU heißen oder sollte man da Super FX drauß machen? Von mir aus kann man GSU belassen, ist kürzer. Aber umgangssprachlich wäre Super FX passender

Und dann ist da immer noch die ethnische Frage nach dem map mode im Raum... Was macht man, wenn ein ROM sich selbst über den map mode als bspw. Hi-/LoROM ausgibt, aber der Größe nach ein Hi-/ExHiROM sein müsste? Oder was ist mit ROMs wie Star Ocean, die den Header an einer LoROM Position haben und sich selbst als ExLoROM ausgeben? Ich habe da schon die unterschiedlichsten Varianten gesehen. Ich persönlich würde nach der Plausibilitätsprüfung auf die Info im Header setzen. Oder wie seht ihr das?

Heute wieder ein geringfügiges Update auf v0.45!

Bis auf wenige Ausnahmen sollte nun ein Großteil aller Special Chips korrekt erkannt werden.

Die Ausnahmen sind:

• Ace wo Neveal
• Ballz 3D
• Lock On
• Michael Adrettis...
• Soukou Kihei...
• Super Air Diver 1 + 2
• Pachi Slot....

Wäre super, wenn sich noch mehr Tester finden würden

Naja, dann würde ich sagen, dass die ROM Hacker nicht sauber gearbeitet haben

Bis jetzt wird nur geprüft, ob die Angabe im Header größer ist als die tatsächliche Dateigröße.

Wenn das der Fall ist, wird das ROM auf die Größe im Header gespiegelt und dann die Checksum berechnet.

Kannst du mal bei so einem ROM eine korrekte Größe eintragen, die Checksum reparieren und schauen, ob die dann stimmt?

Den Fall, dass die Größe im Header kleiner als die tatsächliche Dateigröße ist, habe ich nicht berücksichtigt, da das eigentlich nicht vorkommen darf...

EDIT: In so einer Situation würde ich es bevorzugen die angegebene ROM Größe im Header zu fixen.