Finden des ersten aktuellen Tilesets im VRAM

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Finden des ersten aktuellen Tilesets im VRAM

      Habe mir das Tut von haefele und driver hier angeschaut, da ich wieder ein bisschen Interesse am Stöbern in ROMs bekommen hab.

      Mit dem Tile Viewer nun das Offset rausgesucht:


      Dann erst über den VBA Logger versucht, findet keinen passenden Eintrag. Dann die VBA-SDL-H Lösung probiert und entsprechend einen Breakpoint gesetzt, einmal bei 0x06000000 und bei 0x06000040, nachdem auch ersteres nicht geklappt hat.
      Folgendes spuckt der Debugger aus:

      Quellcode

      1. Breakpoint (on write) address 06000040 old:0011 new:0000
      2. Breakpoint (on write) address 06000200 old:ffff new:0000
      3. R00=8100c000 R04=030022c0 R08=00000000 R12=02020674
      4. R01=040000d4 R05=030022b4 R09=00000000 R13=03007e0c
      5. R02=00000012 R06=030022b4 R10=00000000 R14=080010ef
      6. R03=00000000 R07=030022c0 R11=00000000 R15=08136e96
      7. CPSR=0000003f (......T Mode: 1f)
      8. 08136e92 6088 str r0, [r1, #0x8]
      9. > 08136e94 6888 ldr r0, [r1, #0x8]
      10. 08136e96 2400 mov r4, #0x0
      11. debugger> c
      12. Breakpoint (on write) address 06000040 old:0000 new:0000
      13. Breakpoint (on write) address 06000200 old:0000 new:0000
      14. R00=03007dec R04=03007dec R08=00000000 R12=81000000
      15. R01=040000d4 R05=00001000 R09=00000000 R13=03007dec
      16. R02=06000000 R06=00000000 R10=00000000 R14=08086805
      17. R03=00018000 R07=81000800 R11=00000000 R15=0808683e
      18. CPSR=8000003f (N.....T Mode: 1f)
      19. 0808683a 608f str r7, [r1, #0x8]
      20. > 0808683c 6888 ldr r0, [r1, #0x8]
      21. 0808683e 1952 add r2, r2, r5
      22. debugger> c
      23. Breakpoint (on write) address 06000040 old:0000 new:eddd
      24. Breakpoint (on write) address 06000200 old:0000 new:dddd
      25. R00=80000800 R04=040000d4 R08=03000010 R12=03000811
      26. R01=00004000 R05=00000780 R09=00000000 R13=03007da8
      27. R02=06000000 R06=00001000 R10=03000014 R14=08000791
      28. R03=02002de0 R07=040000d4 R11=00000000 R15=08000d62
      29. CPSR=2000003f (..C...T Mode: 1f)
      30. 08000d5e 60a0 str r0, [r4, #0x8]
      31. > 08000d60 68a0 ldr r0, [r4, #0x8]
      32. 08000d62 199b add r3, r3, r6
      33. debugger>
      Alles anzeigen
      Keines der Source-Offsets beginnt mit 08xxxxxx (also aus der ROM). Wenn ich selbiges aber mit einem anderen Char Base Offset vom VBA, wie z.B. dem vierten (0x0600c000) ausführe, finde ich das entsprechende Offset, das ich auch über bspw. Tile Molester finden/öffnen kann.


      Werden die ersten Tilesets ab 0x60000000 woanders in den RAM geschrieben, obwohl der VBA Tile Viewer was anderes sagt?

      LG
    • Huhu,

      Also wenn es darum geht, dass du das Zeug selbst researchen willst: Es ist höchstwarscheinlich so, dass die Tilesets in einen RAM Buffer dekomprimiert werden, bevor sie dann geladen werden. Das wird dann vermutlich ein LZUncompWram sein. Wenn du das Source Offset vom Tileset wissen willst kannst du einfach in den Tileset Header schauen, AM zeigt das etwas kryptisch an, aber dort steht einfach das Offset des Tilesets drinnen (U.a. GFX und Palette)

      ~Sturmvogel
      Wandering on Horizon Road
    • Neu

      Hey Sturmvogel,

      danke mal für die Antwort. Habe das bei AM leider nicht gefunden ( :( ), dafür aber eine Tabelle online mit allen Startoffsets des Tileset 0 für die entsprechenden Editionen. Ich gehe jetzt einfach mal davon aus, dass die Tileset-Header alle direkt aufeinanderfolgen (?).
      Auch habe ich durch stöbern und vergleichen der Tiles mit AM herausgefunden, dass bei den Blockdaten der Block eines Tile je zwei Byte besitzt, wobei (nach Umdrehen der Bytes) die ersten 4 Bit des ersten Bytes die Palette des Blocks, die restlichen 12 Bit die Nummer des Blocks in der Grafik darstellt.

      02 20 => 20 02 => 2 002 => Block 002, Palette 2

      Hätte es dazu irgendwo ein Tutorial oder etwas in der Research Sammlung gegeben? Habe verzweifelt gesucht, bis ich das Zeug selbst gesucht habe x(
    • Neu

      Hallo,

      Mit deinen Offsets kann ich dir auf die schnelle nicht so wirklich helfen, ich habe in meinem Repository den Main Map Footer Pointer, mit dem kannst du vllt noch am ehesten was anfangen (gitlab.karathan.at/Karathan/so…aster/patches/maps.asm#L6) - Der Pointer dort zeigt auf eine Liste mit Map Footer Pointern, im Map Footer steht unter anderem auch das Tileset. Wie so ein Map Footer aufgebaut ist kannst du dir auch ansehen: github.com/SBird1337/g3headers…eagb/overworld/map.h#L183


      Was du jetzt am Ende meintest sind die Blockdaten deines Tilesets selber, die erzeugen dir halt dein `Tileset` mit dem du dann am Ende des Tages auch wirklich mappen kannst - Das ist im Endeffekt einfach eine Tilemap, so wie jede andere auch, die schaut so aus: github.com/SBird1337/g3headers…keagb/overworld/map.h#L29


      Ich hoffe du kannst mit dem ganzen C Code ein bisschen was anfangen, die structs zu lesen sollte gehen ohne sich zu viel mit der Sprache auszukennen, ansonsten einfach fragen. In den meisten Fällen sind das Bitfields, die Zahl nach dem : gibt in dem Fall dann an wie viel vom BitArray das jeweilige Feld in der Struktur einnehmen wird.


      ~Sturmvogel
      Wandering on Horizon Road
    • Neu

      Der C-Code war zwar sehr hilfreich (danke), ehrlich gesagt hat mir da deine Single.NET Lib aber um einiges mehr geholfen (kann es sein, dass du vorher in Java programmiert hast? ;) ).
      Du liest dort die Blockdaten folgendermaßen aus (Dezimalzahlen ersetzt durch Hex):


      Java-Quellcode

      1. TileNumber = Convert.ToUInt16(data & 0x03FF)
      2. Palette = Convert.ToByte((data & 0xF000) >> 12)
      3. MirrorHorizontal = Convert.ToBoolean(data & 0x0400),
      4. MirrorVertical = Convert.ToBoolean(data & 0x0800)
      Scheinbar war ich gar nicht so weit weg mit der Palette und der Blocknummer, habe mich allerdings aber immer gefragt, wo er die beiden Flip-Bits speichert. Hätte nicht gedacht, dass das ganze nicht byteweise, sondern bitweise gespeichert ist, danke!

      Frage mich jetzt natürlich allerdings, wie du auf diese Tatsache (und die Nummern der Shift bzw. &-Verknüpfungen) gekommen bist?