SMB2J Disassembly Help

[bMatSantos]

(Let me preface this by saying I have some sort of experience in coding but I'm completely lost when it comes to asm, so I ask for a bit of patience.)


So I'm looking into translating the Lost Levels fds, and I'm following doppelganger's disassembly to edit the title screen. As an assembly noob, so far most of the logo was quite simple to edit, except for the 3rd row of the "Mario Bros. 2" part.



Almost every row corresponding to the logo in TitleScreenGfxData follows the same order: the first 2 bytes are the position of the row's 1st tile in the PPU, the 3rd is a value related to the following tiles (that I still don't know what it is), and from then on the tiles indexes of the CHR are called. Usually they're broken in 2 lines of code.

Code Select Expand


    .db $21, $25, $17, $d8, $de, $d1, $d0, $e8, $d1, $d0, $d1, $26, $26
    .db $d0, $e8, $d1, $d0, $d1, $de, $d1, $d8, $d0, $d1, $26, $d0, $d1

However, in the case of that 3rd row, since the first 6 tiles in "MARIO" use the same index ($db), they made it so that $db was called only once and kept repeating itself until the tiles of the 2nd line started (and the 3rd byte seems to indicate this to the program):

Code Select Expand


    .db $21, $65, $46, $db
    .db $21, $6b, $11, $e4, $e5, $26, $26, $db, $db, $db, $db, $db, $db
    .db $df, $db, $db, $db, $26, $ec, $ed

I'd need to put the R ligature index ($df) on position $21 $67, but editing the position bytes at the second line above creates a 4-tile gap in the logo, leaving me 4 bytes short of editing it properly:



If I try to just copy the logic of the former code, the game crashes because there are 4 more bytes in the data. Keeping the first line as is and adding those bytes by the end also crashes it - even when I update the pointers in fdswrap.asm.

Is there any way I can solve this?

[KingMike]

It looks like a pretty typical NES PPU write macro:
first two bytes are the nametable VRAM address, third byte the length of the data and then the data itself.

What is probably doing is using some of the high bits of the length byte as an RLE-compression flag.
That "problem" line looks like address $2165, length $46.

0x46 is way longer than necessary (the screen is only 0x20 tiles wide) so more than likely that means a value over 0x40 will simply be a flag to use RLE, and that the length is the remainder (6) followed by, I'm guessing DB is the repeated tile.

[bMatSantos]

Oh yeah, that's exactly how it is! Thank you!

OK, one more thing - I finished editing the texts, and then when I went to test it, the game crashed at 5-1:



I did put strings bigger than the original, but there is some free space right after the last message block on smdata3.asm, so I don't think that's it - I checked the original data bins and the new ones have the same size. I even went ahead and updated the pointers in sm2main.asm, but it still crashes the same way. What am I missing?

EDIT: Nevermind! Turns out I did miss more external pointers for other blocks that got shifted along.