Dom's Advanced SNES ROM Utility

Das kann man so pauschal nicht sagen...

Bad Dumps sind per Definition von GoodSNES:

Quote from GoodSNES | Psych0phobiA

: [b] A bad dump often occurs with an older :\

: game or a faulty dumper (bad connection). :\

: Another common source of [b] ROMs is a :\

: corrupted upload to a release FTP. :\

Wie ich das verstehe handelt es sich dabei um ROMs, welche überhaupt nicht funktionieren, da entweder beim Dumpen oder Uploaden ein Fehler unterlaufen ist. Da diese trotzdem in Umlauf gekommen sind, wurden diese zwecks Identifizierbarkeit (CRC32) trotzdem in das ROM Set aufgenommen,

Interleaved bedeutet ja letzten Endes nur, dass das ROM durch die Kopierstation intern etwas verdreht wurde

Das heißt nicht automatisch, dass diese auch fehlerhaft sein müssen, man muss nur richtig mit ihnen verfahren.

Viele Emulatoren erkennen so etwas jedoch und können mit diesen ROMs umgehen.

Quote from Ice Man

Wenn es wirklich nur ein ROM betrifft, bzw, heutzutage gar keine mehr, stellt sich mir die Frage, ist die Funktion dann nötig?

Für mich schon, ich lerne dadurch

Es gibt schließlich auch andere Tools, in denen die Funktion integriert ist, warum dann auch nicht in meinem?

Es muss nur die richtige Situation auftreten, dann bist du wahrscheinlich froh, wenn du sie hast

Angenommen du bist zufällig an eine Cartridge gekommen, die noch undumped ist, aber du hast nur einen Game Doctor oder ein Super UFO zum dumpen

Update auf v0.6.5!

• Funktion zum Editieren von ROM Informationen integriert
  • Titel und Land/Region können bereits geändert werden
  • Hersteller und Version folgen noch
• Fix bei falscher Angabe von interner ROM-Größe
• Kleinere Optimierungen des Codes

Kleines Update auf v0.6.6!

• Version kann nun editiert werden (von 1.0 - 1.255)

To Do:

• Funktion zum Ändern des Herstellers (company code / maker code)
  • Ist etwas leider etwas umfangreicher
• Verhalten bei Umgang mit dem Header ändern
  • Bisher wird dieser immer entfernt, sollte aber zumindest bei "Fix Checksum" und "Region Unlock" beibehalten werden
• IPS Patching Funktion
• Code optimieren und struktuieren

Noch ein kleines Update auf v0.6.7!

• Umgang mit vorhandenen Headern verbessert

To Do:

• Funktion zum Ändern des Herstellers (company code / maker code)
  • Ist etwas leider etwas umfangreicher
• Handhabung von BS-X & NP ROMs
• IPS Patching Funktion
• Code optimieren und struktuieren

Die ganzen Hersteller Codes sind mir bekannt, sonst könnte ich die ja nicht anzeigen, aber danke trotzdem

Das Problem ist, dass diese, je nach Header, an unterschiedlichen Positionen stehen und unterschiedlich codiert sind...

Nach dem alten Header-Format ist es einfach ein Byte und beim neuen Header 2 ASCII-Zeichen, also 2 Bytes.

Stand jetzt bereche ich einen einheitlichen 2 Byte Code und zeige dann entsprechenden Hersteller an.

Nun geht es eben darum, die Berechnung dieses einheitlichen Codes in die andere Richtung zu machen.

Ist zwar kein Hexenwerk, aber trotzdem etwas aufwändiger...

Mal abwarten, was die nächsten Tage bringen.

Evtl. darf sogar ich im anbetracht der aktuellen Lage mal daheim bleiben und habe dann etwas mehr Zeit

blackerking Das Video erklärt schon mal ganz gut die Theorie, vielen Dank! In der Praxis haben sich leider nicht alle Entwickler ganz so vorbildlich daran gehalten...

Kleineres Update auf v0.6.8!

• Funktion zum editieren / fixen von Header Infos wurde benutzerfreundlicher gestaltet
  • Es wird nun vor dem Speichern geprüft, ob sich Infos geändert haben und nicht einfach drauf los gespeichert
• Bei Momotarou Dentetsu Happy kann nun auch nach dem Expanden die Checksum korrekt gefixed werden
• "About"-Text inkl. Erklärung der Funktionen wurde eingefügt
• Version wird nun in der Kopfzeile mitgeführt

To Do:

• Handhabung von BS-X & NP ROMs
• IPS Patching Funktion
• Code optimieren und struktuieren
• Funktion zum Ändern des Herstellers (company code / maker code)
  • Ist etwas leider etwas umfangreicher

Die Reihenfolge der To Do's spiegelt auch die Prioritäten wieder, welche ich mir gesetzt habe.

P.S.: Wenn jemand nicht in den Credits erwähnt werden will, bitte natürlich bescheid geben, dann nehme ich das raus

Kleineres Update auf v0.6.9!

• Behandlung von japanischen Schriftzeichen
  • Anzeige von japanischen Titeln
  • Editieren dieser Titel somit auch möglich
• Kann intern nun feststellen, ob das geladene ROM ein BS-X ROM ist
• Kleinere Fixes

To Do:

• Handhabung von BS-X
• IPS Patching Funktion
• Code optimieren und struktuieren
• Funktion zum Ändern des Herstellers (company code / maker code)
  • Ist leider etwas umfangreicher

  
  

Das nächste Release wird dann aller Voraussicht nach vollständig mit BS-X ROM ungehen können

Update auf v0.7!

• Handhabung von BS-X ROMs
  • Berechnen / fixen der BS-X Checksum
  • BSX-ROM types hinzugefügt
  • BS-X Titel sind nur 16 Zeichen lang und können auch nur bis zu dieser Länge bearbeitet werden
    • Es kann vorkommen, dass es jap. Zeichen gibt, welche 2 Bytes lang sind; geht der eingegebene Text aufgrund dessen über 16 Bytes hinaus, wird gekürzt!
  • BS-X ROMs sind alle für Japan bestimmt und haben deshalb keinen eigenen country / region code: Dieser kann somit auch nicht geändert werden
  • Da die interne ROM size anders als in normalen ROMs angegeben wird, kann diese auch nicht (so einfach) gefixed werden (sollte aber imho auch nicht notwendig sein)
  • Auf das Ausgeben der BS-X Datumangaben verzichte ich aus folgenden Gründen:
    
    • Dies ist kein BS-X ROM Utility
    • Der Platz auf dem GUI ist ziemlich begrenzt
    • Interessiert das sowieso niemanden

To Do:

• IPS Patching Funktion (evtl. auch über externes Tool?)
• Code optimieren und struktuieren
• Funktion zum Ändern des Herstellers (company code / maker code) (?)
  
  • Ist leider etwas umfangreicher

Viel Spaß!

Quote from Ice Man

Vorschlag:

Ich habe mir eben die neuste Final Fantasy Ultima Version geladen und die ROM Größe im Header ist nach wie vor falsch.

Ich dachte, du hast das automatisiert, wenn man die Checksum repariert.

Also ROM Header Fix -> Checksum Fix -> ROM Output

Dass ich den ROM Size erst reparieren muss, dann die ROM laden um den Checksum zu reparieren, ist doppelte Arbeit.

Ich hatte das korrigiert, dass die Checksum entsprechend dem Resultat vom Higan entspricht.

Was du da andeutest würde im Endeffeekt auf einen Workflow-Designer hinauslaufen, weil man darauß ja die wildesten individuellen Kombinationen schlussfolgern könnte: Tue dies, wenn das usw... Und jeder will was anderes... Da das mit jeder Menge Arbeit verbunden ist und den Umfang des Tools sprengen würden, lass ich das lieber sein.

Für die nächste Version werde ich aber EXTRA FÜR DICH eine Funktion integrieren, mit der man ein automatisches Fixen der ROM size aktivieren oder deaktivieren kann.

Wie wäre das?

Quote from Ice Man

Oh, und nache eine Sache.

Wenn die ROMS expandiert werden, füllst du ja mit 00.

Leere EPROMs bzw. leere stellen sind immer FF.

Wäre es da nicht sinnvoller mit FF zu füllen?

Das habe ich auch nur so gemacht, weil LunarExpand das so handhabt.

Wusste auch nicht genau wieso, aber ich dachte mir, dass das schon seinen berechtigten Sinn haben wird