Beiträge von Dom

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

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

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

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.

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

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

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?

Update auf v0.5!

• Berechnung der Checksum funktioniert nun auch bei Spielen mit falschen Angaben über die eigene ROM Größe (s. Beitrag von @Ice Man)
• Verbesserte Erkennung einiger ROM types (Eine Hand voll DSP-1 Spiele werden aber immer noch als DSP-4 erkannt )
• Kleinere Bugs gefixed

Immer noch dringend gesucht: Tester!

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.

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

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?

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

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!

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!

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

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

Habe ein Problemkind gefunden...

Bei Star Wing (G) wird kein SRAM erkannt, obwohl vorhanden

Im Header sind auch keine Anzeichen dafür vorhanden.

Muss man da eine Ausnahme machen oder gibt es noch andere Arten das zu bestimmen?

Update auf v0.3!

• SRAM/RAM Erkennung funktioniert nun
• Region Unlock Funktion wurde erweitert
  • "Asterix & Obelix" wird nun auch erkannt

  
  

Danke Ice Man für die Hilfe soweit!

Glaub ich hab die Sache mit dem Expanded RAM und dem SRAM durchschaut

Expanded RAM scheint nur bei Spielen mit neuem "erweiterten" Header zu existieren.

D.h. ich muss zuerst prüfen, ob in (40)7FDA / (40)FFDA der Wert 0x33 drin steht, was dann bedeutet, dass es einen erweiterten Header besitzt und dann schauen, ob es Expanded RAM hat

Ich glaube nachher gibts noch ein kleines Update

Zitat von Ice Man

Glaube kaum, dass beides gleichzeitig hinterlegt ist. Zumindest ist nichts bekannt.

Dann werde ich das so handhaben, dass ich dem SRAM Byte eine höhere Bedeutung zukommen lassen werde als dem Expanded RAM Byte. Also erst das SRAM Byte auslesen und wenn dieses 0x00 ist, dann schauen, ob ein Wert größer 0x00 im Expanded RAM drin steht. Ist letzteres auch nicht der Fall, so wird einfach wie bisher auch "No" rein geschrieben. Was meinst?

Zitat von Ice Man

EDIT: Bin mal eben alle PCBs durch. Also folgende ROMs benutzen $7FBD:

Dirt Racer

Doom

Vortex

Cool, vielen Dank für deine Mühe!

Zitat von Ice Man

Wobei StarWing/Star Fox teilweise auch PCBs ohne Batterie haben:

https://snescentral.com/pcbboards.php?chip=SNSP-1C0N5S-01

o_O

Strange...

Zitat von Ice Man

Wenn ein ROM wie z.B. Tales Of Phantasia 6MB ExHiROM ist, wäre ja 27C322 (4MB) + 27C160 (2MB) am sinnvollsten.

Müsste ich mir mal durch den Kopf gehen lassen, würde ich jetzt aber nicht als problematisch sehen

Zitat von Ice Man

Man kann natürlich auch auf 8MB expandieren, also die letzten 2MB mit FF gefüllt am Ende der ROM dran hängen

Das ist wie gesagt nur bis 32 Mbit problemlos möglich, gefüllt wird aber mit 0x00 soweit ich weiß. Bei ExHiROM würde das ja noch gehen, aber bei ExLoROM wird es da etwas schwierig. Habe mich da aber ehrlich gesagt noch nicht weit genug hinein gearbeitet Auf FuSoYa's Niche ist das etwas genauer erklärt.

Zitat von Ice Man

Finde das Tool auf jeden Fall schon mal sehr gut und wird auch ucon64 und den anderen SNES Checksum Fixer bei mir ersetzen

Finde ich extrem nice! Vielen Dank für das Kompliment!

Glaube ich werde das so machen, dass ich das einfach (S)RAM nenne und dann einfach dort den Wert von SRAM oder RAM hineinschreibe

Kann es vorkommen, dass bei ROMs in beiden Felder etwas hinterlegt ist? Also SRAM und Expanded RAM?

Es würde keinen Sinn machen, aber ich würde nicht darauf wetten, dass das 100%ig durchgehend so prakitziert wurde von den Entwicklern

Zitat von Ice Man

Bei der SplitROM Option solltest du noch 4MB (27C322) mit einbauen. Gibt ja schließlich auch größere ROMs.

Diese Option habe ich drin und die würdest du auch angezeigt bekommen, wenn du ein 8MB großes ROM laden würdest

Andererseits ist mir gerade aufgefallen, dass ich das Expandieren auf 8MB noch garnicht drin habe

Fändest du diese Möglichkeit sinnvoll? Wenn ja, würde ich das noch rein machen

Ein ROM auf 8MB zu expandieren ist etwas komplexer und wird stand heute noch nicht unterstützt, weshalb ich das vorerst nicht drin habe.

Interessant

Ist es dann falsch, dies als SRAM anzugeben?

Im Prinzip wäre es ja nur als RAM zu kennzeichnen, oder?

Dann müsste man das also im Programm als separate Angabe aufführen ODER als (S)RAM betiteln?

Wenn der ROM type keine Batterie aufweist sollte das eigentlich einleuchtend genug sein oder was meint ihr?