Dom's Advanced SNES ROM Utility

  • Gerade noch herausgefunden, dass bei interleaved ROMs die Berechnung der Checksum noch nicht passt X/


    Habe das anhand einer english gepatchten Version von Tales of Phantasia festgestellt, welche man auf einer gewissen "phantasie Anime" Site schon prepatched herunteladen kann :whistling:


    Experimentell habe ich gerade noch eine Erkennung von interleaved ROMs entwickelt und bin am überlegen, ob ich eine deinterleaving Funktion integrieren soll, da das programmintern sowieso gemacht werden müsste, bevor die Checksum berechnet wird. Was meint ihr dazu?

  • Merkwürdig... Genau mit diesem Patch hatte das bei mir funktioniert 8|

    Benutzt du auch die neueste Version? Oder habe ich etwa eine alte Version hochgeladen? :/

    Muss das auf jeden Fall mal prüfen! Achja, das Tool belässt natürlich den falsch gesetzten ROM size Eintrag im Header.


    Heute Abend werde ich jedenfalls noch eine Deinterleave Funktion einfügen, falls ein interleaved ROM geladen wird.

    Einmal um die Checksum korrekt zu berechnen und einmal um das gesamte ROM zu deinterleaven.

    Muss mal noch genau schauen, aber ich glaube damit sollte man dann auch aus Hi -> LoROMs machen können, sofern man noch das map mode Byte anpasst.

  • Dann kann es auch nicht funktionieren. Wenn der Eintrag falsch ist, kann die Checksum NIE korrekt berechnet werden.

    Das ist ja mein Anliegen gewesen, dass zu ändern und die ROM Größe anzupassen, falls diese falsch ist, bevor die Checksum repariert wird. XD

  • Naja, die Checksum wird korrekt berechnet, aber eben für ein ROM mit einem falschen Wert im Header :P

    Du kannst nicht die Checksum von einem korrigierten ROM mit der Checksum eines nicht korrigierten ROMs vergleichen, die sind zwangsweise unterschiedlich, da gebe ich dir Recht 8o Und trotzdem sind beide Checksums korrekt!

    Ich habe ernsthaft darüber nachgedacht eine falsche ROM size Angabe zu fixen, aber habe es dann gelassen, da ich nicht zu 100% sagen kann, ob es die Absicht eines ROM Hackers war oder es nur vergessen wurde.

    Wäre es denn rein theoretisch möglich, dass eine Änderung dieser Angabe dazu führt, dass das ROM unbrauchbar wird?

    Sollte man tatsächlich zu 100% ausschließen können, würde ich diese Korrektur natürlich machen ;)

  • Ob Absicht oder nicht ist egal, falsch ist falsch. :P


    Unbrauchbar wird die ROM nicht, aber die Checksum wird NIE stimmen, wenn die Angaben falsch sind.

    Probiere es mal in snes9x aus. Die Checksum wird IMMER als falsch erkannt, solange die ROM Größe nicht richtig gesetzt ist. ;)


    Generall ist die Checksum eigentlich unwichtig, da ich kein Spiel kenne, was diese überprüft (außer evtl. Earthbound) und daraus dann irgendwelche Mechanismen bildet, damit das Spiel unspielbar wird.


    Bei der Mega Drive wäre das natürlich ganz anders. :P


    Ich finde es persönlich dennoch schön, wenn ROMs auch die korrekten Angaben und co. haben. ^^

  • Wie gesagt, kenne ich die Intention nicht, welche hinter der falschen ROM size im Header steckt und daher möchte da ungern Einfluss drauf nehmen...

    Ich hoffe, das kann irgendjemand ansatzweise nachvollziehen :rolleyes:


    Wie dem auch sei, zeigen mir ZSNES und uCON64 aber an, dass die Checksum nach dem Fixen und MIT übernommenem "falschen" Wert für die ROM size im Header trotzdem korret ist.


    ZSNES:

    Vor dem Fixen der Checksum

    Nach dem Fixen der Checksum


    uCON64:

    Vor dem Fixen der Checksum

    Nach dem Fixen der Checksum


    Für sowas würde ich dann eher eine generelle Funktion zum fixen des gesamten Headerbereichs integrieren wollen, da die ROM size nicht das einzige ist, was da falsch sein kann ;)


    Kommt jedenfalls mal mit auf die Agenda :thumbup:


    Das weitere Vorgehen sieht demnach stand heute wie folgt aus:

    • Die letzten falsch erkannten DSP-1 Spiele fixen
    • Funktion zum fixen von falschen Werten im Header
    • Deinterleaving implementieren, um 1. die Checksum solcher ROMs korrekt zu berechnen und 2. das gesamte ROM zu deinterleaven
    • Mit einbeziehen von BS-X und NP ROMs inkl. Checksum-Berechnung
    • IPS-Patching Funktion
  • Nicht jeder ROM Hacker kümmert sich darum, dass der ROM Header inkl. Checksum in Ordnung sind. Gibt auch schlampige. :P


    Uuuund..... wer ZSNES benutzt gehört verbannt!

    Im Ernst, der ist alles andere als hardwarenah und akkurat. Zumal auch nicht mal aktuell!

    Snes9x und Mesen-S oder bsnes/higan sind z.Z. mitunter die besten Emulatoren.


    Ist bei Snes9x die ROM Größe im Header inkorrekt kann die Checksum noch so richtig sein, sie ist es nicht, weil die ROM Größe falsch ist...

    ZSNES und uCON64 berücksichtigen das nicht. Demnach ist die Checksum an und für sich ja auch "in Ordnung". Falsch ist es dennoch. :P


    Wenn du schon eine Funktion zur Reperatur des Headers einbringen willst, dann mach es in etwa wie bei diesem Tool:

    http://www.romhacking.net/utilities/1344/

    Würde mich freuen, wenn man damit auch den ROM Namen und co. ändern kann in der Zukunft. :)


    ^^

  • Nicht jeder ROM Hacker kümmert sich darum, dass der ROM Header inkl. Checksum in Ordnung sind. Gibt auch schlampige. :P

    Leider ja :rolleyes:


    Ist bei Snes9x die ROM Größe im Header inkorrekt kann die Checksum noch so richtig sein, sie ist es nicht, weil die ROM Größe falsch ist...

    ZSNES und uCON64 berücksichtigen das nicht. Demnach ist die Checksum an und für sich ja auch "in Ordnung". Falsch ist es dennoch. :P

    Was ich damit (ZSNES und uCON64) eigentlich zeigen wollte war, dass die Checksum an sich korrekt errechnet wird, sofern man mal die Plausibiliät der Headerdaten außen vor lässt ;) Die Checksum wird über ALLE im ROM vorhandenen Daten gebildet! Was die von dir genutzten Emulatoren vermutlich machen, ist den Header beim Ladevorgang zu korrigieren oder aus anderweitigen Infos zusammen zu stellen, was ja auch u.U. Sinn macht, die enthaltene Checksum wird allerdings hierdurch zwangsweise falsch. Also sind wir uns in dem Punkt letztendlich einig, wie ich sehe :P


    Wenn du schon eine Funktion zur Reperatur des Headers einbringen willst, dann mach es in etwa wie bei diesem Tool:

    http://www.romhacking.net/utilities/1344/

    Würde mich freuen, wenn man damit auch den ROM Namen und co. ändern kann in der Zukunft. :)


    ^^

    Sowas ging mir letztens auch durch den Kopf :thumbup:

    Ich denke das werde ich auch noch aufnehmen.

    Änderbar sind dann natürlich nur unrelevante Daten, wie Name, Ländercode usw. und Daten welche nicht plausibel sind, werden hierbei korrigiert.

    Einverstanden? :S

  • Kleineres Update auf v0.5.1!

    • Alle Special Chips (Enhancement Chips) werden jetzt korrekt erkannt! :party:
    • Einige Titel für das Region Unlocking hinzugefügt
    • Logo hinzugefügt :saint:

    Da Thema Deinterleaving etwas komplexer ist als ich dachte, arbeite ich da wohl noch ein paar Tage dran.

    Die Theorie dahinter sitzt aber schon mal :smoking:


    Ich denke, dass als nächstes das Header Fixen dran ist und danach das Header Editieren ;)

  • Einen Wunsch hätte ich:

    Eine Batch ausführung auf Ordner.

    Sozusagen einen Ordner wählen, alle Dateien werden gewählt und alle Checksums werden berechnen und korrigieren.

    Rein theoretisch könnte ich mir vorstellen soetwas über einen Kommandozeilenbefehl abschließend zu realisieren :):thumbup:

    Abschließend, weil ich erst sicherstellen will, dass ROMs wie BS-X , NP Interleaved oder auch Beta-Versionen, für welche noch keine Erkennung und kein Checksum-Algorithmus integriert sind bzw. die ohnehin eine fehlerhafte Checksum haben (Beta-ROMs), nicht kaputt gemacht werden ;)

    Die Idee nehme ich jedenfalls mal auf!

  • Update auf v0.6!

    • Deinterleaving implementiert
    • Code optimiert

    Das Deinterleaving konnte ich nur anhand eines ROMs testen, sollte aber funktionieren, sofern mich meine Quellen nicht belügen :saint:

    Da zum teil widersprüchliche Angaben gemacht wurden, habe ich mich auf die Aussagen der Mehrheit verlassen und so weit es ging meinen "gesunden" Verstand benutzt! :S

    Es wäre hilfreich, wenn jemand ein paar interleaved ROMs durchtesten und berichten könnte :)


    Als nächstes, wie versprochen, geht es dann ans Header fixen / bearbeiten ;)


    (Quellen: Ninja, Raphnet, NSRT, noCash)

  • Das betrifft im wesentlichen nur einen sehr sehr geringen Anteil an ROMs, sofern es überhaupt noch welche gibt :/


    Ich hatte z.b. eine englische Übersetzung von Tales of Phantasia heruntergeladen, welche interleaved war, ansonsten ist mir das bisher auch noch nicht begegnet.


    Der Punkt warum es interleaved ROMs gibt, sind die Super UFO und Game Doctor SF Kopierstationen oder eine falsch konfigurierte Super Wild Card.

    Diese erwarten den Header zwangsweise an 0x7FB0!

    Sobald ein HiROM gelesen werden soll, rearrangieren diese das ROM so, dass der Header statt an 0xFFB0 an 0x7FB0 zu finden ist.

    Genaueres kannst du aber in den genannten Quellen nachlesen ;)


    Erkennen kannst du diese meist über die Dateiendungen *.fig, *.078, *.058 usw.


    Da aber die meisten ROMs über das Super Magicom gedumped (*.smc) wurden, welches ohne Interleaving auskommt, kommt das wie gesagt nur extrem selten vor. Trotzdem wollte ich das ganze mal ausgiebig durchleuchten und als zusätzliche Funktion im Tool haben :saint: