snesfreaks.com

Coole Sache! Vielleicht kann ich dich irgendwann in ein paar Monaten dich auch noch mit etwas ganz speziellem für dein Projekt unterstützen... ich lass es dich wissen, sobald es soweit ist.

Na jetzt machst du mich aber neugierig Ich bin gespannt

Ein kleines Update, wenn auch leider noch kein Meilenstein erreicht wurde:

http://gaiathecreator.blogspot.de

Hallo manafreak (komischer name für einen IoT Editorenprogrammierer, nicht? )

Wenn du möchtest, kann ich mir die kaputte ROM mal angucken... ich kann aber erst am Wochenende schauen

Ist es evtl so, dass du beim wiedereinfügen der daten irgendwelche codebytes überscbreibst? Ich achätze, das eingefügte wort "test" wird die komprimierten grafikdaten um einive bytes vergfößert haben.

Ich befürchte auch, dass die Editierung der Tiles Einfluss auf die Größe der komprimierten Daten haben könnte. Da die Kompressions-Routine aber auch bei nicht-editierten Grafiken bislang nicht die korrekte Größe an komprimierten Daten erzeugt vermute ich erstmal hier noch einen Fehler.
Deshalb werden wohl auch noch nicht alle Grafiken richtig angezeigt. Wenn ich diesen Fehler behoben habe und das Spiel dennoch abstürzt werde ich die ROM-Datei mal hochladen

Der Fehler scheint aber nur minimal zu sein, denn die Grafiken sind ja nur marginal beschädigt; wenn ich den Screenshot richtig in Erinnerung habe, war ab der Hälfte die oberste Pixelreihe zerschossen. Kann ja sein, das bloß irgendein einzelner Byte zuviel eingefügt wird und sich dann damit alles verschiebt. Wenn der Überschusy am Ende noch in eine Codesektion geschoben wird, ist auch der Crash erklärt.

Vielleicht ist dieses Wissen irgendwann mal irgendwie nützlich: Laut dieser Seite wissen wir jetzt folgendes über folgende RAM-Register:

7E0ACE - Energie
7E0AD4 - Figur (#$00 Will, #$01 Freedan, #$02 Shadow)
7E0AA2 - Abilities (Flagregister: #$01 Psycho Dash, #$02 Psycho Slide, #$04 Spin Dash, #$10 Dark Friar, #$20 Aura Barrier, #$40 Earth Quaker)
7E0AB0 - Anzahl gesammelter Juwelen

Zumindest die Abilities könnten interessant werden, vielleicht kann es mit diesem Hintergrundwissen vergleichsweise einfach in den Editor einarbeiten, wann die Dinger an (oder evtl. auch wieder aus?) getriggert werden.
Interessant fand ich, dass der Code für 50 Juwelen den Wert "#$50" in das Register schreibt. Entweder, das ist BCD, oder, was ich eher vermute, die Leute, die den Code rausgefeudelt haben, haben kein Verständnis von Hexzahlen, und das Spiel interpretiert alles über fünfzig als fünfzig.

Spam Spam SPAAAAAAAAM... noch mehr gefunden!

Hier einige andere Cheats, von einer anderen Seite. Interessant ist, dass es alles keine RAM, sondern ROM-bezogene Codes sind. Interessant (zweitens) ist ferner, dass die alle mit 8 anfangen... da IoT ja HighROM UND FastRom ist, müsste das doch eigentlich C sein... oder!?!

80807150
Always have infinite energy.
83C41BAD
Always have infinite energy.

(Keine Ahnung, wie das funktioniert)

80807163
Will starts with 99 strength.

#$63 = #99. Folglich ist das die Stelle, wo wohl das "Setup" der Startwerte ist. Interessant, dass eine #$50 (= 80) unendliche Energie bedeutet. Vielleicht ist dort eine Ausnahme für A = #$50 programmiert?

82B81500
No charge time for Psycho Dash.
82B81505
Less charge time for Pyscho Dash.

$82B815 (in der ROM müsste das bei 2B815 sein) enthält wohl einen Counter Value/Vergleichswert für einen Loop.

83889F10
Get 2X the energy from herbs.
83889F18
Get 3X the energy from herbs.

Das hier ist wohl das, was man am ehesten in einen Editor eintragen könnte: $83889F ($3889F) enthält die Menge der Energiepunkte, die die Heilkräuter heilen. Logischerweise müsste #$08 der Standardwert sein, und die Zählung in Energie-Halbpunkten erfolgen.

EDIT: HAbe noch ein paar, Moment.

Nächste Seite

Anscheinend wird auch 7E0AA3 für Dark Powers verwandt. Das müsste den Phönixschlag für Shadow enthalten.

7E0A1F: Die Anzahl der erhaltenen Statuen. Interessant, dass der Code für alle Statuen #$BF ist (=#%1011.1111). Eventuell ist das ein Fehler, oder Bit 7 wird für was anderes gebraucht. Ansonsten schätze ich, adss Bit 0 bis 5 für die Statuen gut sind. Werde ich mal beizeiten testen.

$7E0ADE - Angriff, Maximum = #$63/$99
$7E0ADC - Abwehr, Maximum = #$63/$99

$7E09AE - Counter für die Wartezeit bis zum nächsten Angriff?
Cool shit! Eine Liste der Items und das Register, in dem die ausgewählten Items stehen! $7E0AB4 könnte wohl auch der Anfang des Inventars sein.

Erkenntnisse des Abends:

Die ganze Zeit arbeitet das Spiel ganz schön heftig mit seinem Koprozessor. Seinem, äh, Koprozessor? Interessant, dass das Spiel so häufig den COP-Befehl nutzt, wobei es doch keinen Zusatzchip hat. Ich hätte da eine Vermutung, aber auf die kann man sich meist kräftiglich ein Ei pellen, also schweige ich und gucke mal beizeiten nach.

Der Tempstore für den CGRAM erstreckt sich von $7F0A00 bis $7F0BFF. Also, alles, was da liegt, wird so 1:1 in den Palettenspeicher transferiert.

Außerdem sind $7F0C00 bis $7F0C02 Color-Math-related, die werden in Register $2132 gespeichert.

Ferner hatte ich recht, $7E0AB4 ist der *erste* der Item-Slots im Menü. Der letzte ist $7E0AC3.

Außerdem steht beim letzten Link ganz unten was bezüglich der roten Juwelen, dass das in der Tat ein BCD-Wert ist. (Er wird offensichtlich nämlich so 1:1 nybbleweise gesplittet und dann für die Ausgabe (d. h. Tilenummerberechnung) genommen).

Ich bin im Bett, horrido.

Sehr coole Sache, das alles habe ich noch nicht finden können, vielen Dank
Da werde ich demnächst mal ein paar Dinge in den Editor einbauen und schauen was passiert

Ich befürchte, dass dir das meiste hiervon vorerst nix nützen wird, weil es RAM bezogen ist, und damit nur von Nutzen, wenn du in den ASM-Code des 5A22 (~= 65816) eintauchen willst. Fürs erste ist wohl nur aller Kram nützlich, der nicht mit 7E oder 7F anfängt.

Also, ich habe mal ein wenig im Handbuch des 65816 nachgeschlagen, und da steht zum COP-Befehl folgendes (das muss jetzt keiner wirklich lesen):

Execution of COP causes a software interrupt, similarly to BRK, but through the separate COP vector. Alternatively, COP may be trapped by a co-processor, such as a floating point or graphics processor, to call a co-processor function. COP is unaffected by the i interrupt disable flag.
COP is much like BRK, with the program counter value pushed on the stack being incremented by two; this lets you follow the co-processor instruction with a signature byte to indicate to the co-processor or coprocessor handling routine which operation to execute. Unlike the BRK instruction, 65816 assemblers require you to follow the COP instruction with such a signature byte. Signature bytes in the range $80-$FF are reserved by the Western Design Center for implementation of co-processor control; signatures in the range $00-$7F are available for use with software-implemented COP handlers.
6502 Emulation Mode (65802/65816, e=1): The program counter is incremented by two and pushed onto the stack; the status register is pushed onto the stack; the interrupt disable flag is set; and the program counter is loaded from the emulation mode co-processor vector at $FFF4-FFF5. The d decimal flag is cleared after a COP is executed.
65802/65816 Native Mode (e = 0): The program counter bank register is pushed onto the stack; the program counter is incremented by two and pushed onto the stack; the status register is pushed onto the stack; the interrupt disable flag is set; the program bank register is cleared to zero; and the program counter is loaded from the native mode co-processor vector at $00FFE4-00FFE5. The d decimal flag is reset to 0 after a COP is executed.

Folglich ist das nur eine alternative Art und Weise, einen Software-Break herbeizuführen. Gerade mal im SNES-Header geguckt: Die ROM hat folgende Vektoren:

Emulation Mode - RESET (natürlich): $8000
Native Mode - COP: $8007
Native Mode - BRK: $800F
Native Mode - NMI: $800B

Liegen alle ziemlich dicht beieinander, was?

Also gucken wir mal in den Code ab $8000:

78 18 FB 5C 14 80 80 5C 6D 84 80 5C F8 82 80 5C 13 80 80 40 D8 C2 30 A9 00 00 5B A9 FF 01 1B E2

RESET: ; $8000
SEI
CLC
XCE ; (Enable Native Mode)
JMP $808014 ; Jump

COP: ; $8007
JMP $80846D ; Jump

BRK: ; $800B
JMP $8082F8 ; Jump

NMI: ; $800F
JMP $808013 ; Jump

;808014 [Spielbeginn]

Gut, also, das hat mich jetzt nicht weitergebracht. $(80)846D fängt an mit:

C2 20 9B A3 04 85 0C A3 02 3A 85 0A A7 0A E6 0A 29 FF 00 0A AA 7C 85 84 4E 86 89 86 A0 86 B7 86

REP #$20
TXY
LDA #$04,s
STA $0C
LDA #$02,s
DEC A
STA $0A
LDA [$0A]
...

Hah, kuhl. Jetzt weiß ich, wie die das machen:

Da oben im Auszug aus dem 65816-Handbuch steht ja, dass der COP-Befehl immer einen Argument-Byte hat. Der Kram, den ich da oben mehr schlecht als recht per Hand disassembled habe, macht folgendes:
Der COP-Befehl schmeißt sich die Adresse, wo er herkommt, auf den Stack, damit er nach Beendigung seines Handlers dahin zurückspringen kann. Der Kram daoben zieht Daten vom Stack und nutzt die als Adresse, um einen Datenbyte zu laden. Logischerweise lädt sich das Ding so den Argumentbyte. Folglich sind die COP-Befehle, die nicht zwangsweise ihrem Namen gemäß etwas mit einem COProzessor zutun haben (siehe Handbuch), auch nur eine bestimmte Art und Weise, einen Handler aus einer Liste von Handlern zu laden.

Das kann man sich ja mal beizeiten angucken, aber evtl. schließt das zumindest einige weiße Flecken in deiner ROM-Map.

Es gibt Fortschritte:
Die Komprimierung der Grafiken funktioniert jetzt so weit, dass die ROM nicht mehr abstürzt.
Ich habe nun wie angekündigt eine erste Version des Editors hochgeladen, in der die Grafiken editiert werden können:

http://gaiathecreator.blogspot.de/

Hammercoole Sache! Endlich ist es soweit!

Wie funktioniert das mit der Wolkengeschwindigkeit? Behältst du die Multiplikatoren der Streifen bei ("also, Streifen 1 ist immer doppelt so schnell wie Streifen 2"), oder ist das bisher nur ein Platzhalter?

Anscheinend klappt da aber was mit der Dekompression der Tilesets 1 und 2 nicht richtig, überall in den ersten Reihen sind diese komischen Striche: Mal ein doofer Gedanke: Versuch mal, am Anfang der Daten einen Byte früher oder später anzufangen, vielleicht behebt es sich damit. Dunkel meine ich mich entsinnen zu können, dass das so oder so ähnlich aussieht, wenn man um einen Byte verrutscht... ich kann mich aber auch irren.

Spannend, spannend, ich spiel mal noch ein bisschen damit rum.

EDIT: Tileset 14, dasselbe Problem.

Die Wolkengeschwindigkeit ist in der Version noch nicht implementiert, da bin ich gerade erst dabei das umzusetzen
Das Problem mit den falsch angezeigten Tilesets werde ich auch als nächstes angehen, ein Bit/Byte-Offsetfehler ist auch meine Vermutung
Die ersten 15 Tilesets sind übrigens die nicht komprimierten Tilesets
Viel Spaß beim herumspielen

Hier noch ein paar Sachen, die mir aufgefallen sind:

• Palette 45 ist sicherlcih irgendeine Charakter-Palette. Die sieht halbwegs stimmig mit Tileset 127 aus, auch wenns nicht hunnatpro passt.
• Wenn man das Fenster minimiert und wieder vergrößert, wird bei mir nicht mehr das Tileset angezeigt, alle Felder mit Grafiken bleiben weiß
• Tileset 83 ist kein Tileset, würde ich sagen.
• Guckt euch mal Tileset 72 mit Palette 4 an, und dann mit Palette 3.
• Wo wir gerade beim Thema sind: Palette 4 ist Lances Palette, oder?
• Der alte Knabe aus Itory und Lola in Tileset 48 sehen damit aber auch ganz proper aus...