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 :S

    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.

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

    Für mich schon, ich lerne dadurch 8o

    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 :D

  • 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 X/
    • 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 X/
    • 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 8)

  • blackerking Das Video erklärt schon mal ganz gut die Theorie, vielen Dank! :thumbup: 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 :saint:
    • 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 ;)

  • Man lernt immer so langsam ein paar Dinge dazu. Ich hab auch bei weiten nicht alles kapiert. Eher sehr wenig bisher. :P Deswegen sind solche Videos echt super. Danke dafür!

    Meine Lieblings SNES-RPGs:


    1. Lufia II
    2. Final Fantasy VI
    3. Terranigma, Seiken Densetsu III
    4. Tengai Makyō Zero, Dragon Quest III SNES-Remake
    5. Star Ocean, Shiren the Wanderer
    6. Chrono Trigger
    7. Final Fantasy V, Magical Land of Wozz
    8. Seiken Densetsu II, Zelda: A Link to the Past


    Lieblings-Charaktere: Terra & Shadow (FF 6), Tia & Dekar (Lufia), Carlie (Seiken III), Subaru (TMZ), Schala (CT)

  • Passt schon mit den Credits. ;) Danke dir!


    Nintendo Power ROMs sind eigentlich auch nur normale ROMs eigentlich.

    Haben keinen speziellen Header, soweit ich weiß.

    Werden nur über das Nintendo Power ROM/Menü (BIOS) geladen.


    Konnte nämlich schon erfolgreich ein NP Modul mit stinknormalen ROMs neu beschreiben. ;)


    BS-X haben soweit ich weiß, den Extended Header für Zeit, wie oft man noch spielen kann, etc.

    Außerdem auch im normalen Header einen anderen Eintrag für ROM Typ, glaube ich.

    Habe leider nicht mehr alles auf dem Schirm aber vielleicht hilft das hier:

    https://satellaview.fandom.com/wiki/Satellaview_ROM_header

    https://wiki.superfamicom.org/bs-x-satellaview-header

  • 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 :smoking:
        • Der Platz auf dem GUI ist ziemlich begrenzt
        • Interessiert das sowieso niemanden 8o

    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ß! :party:

  • 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. :P

  • 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. :P

    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 :saint: eine Funktion integrieren, mit der man ein automatisches Fixen der ROM size aktivieren oder deaktivieren kann.

    Wie wäre das?

    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 :/