SMB2J Question About ROM Expansion

In world A-1, the Allstars version adds two star blocks above the last upside-down pipe, but FDS version has the pipe hanging in mid-air (without two star blocks) at the end close to the flagpole, and the last pair of Hammer Bros. have two Horizontal blocks above them. I have found the hex offsets for these areas in FDS ROM and the SNES version's coding is the same, but the SNES version has two more bytes the FDS version is missing, how can I expand the FDS ROM for two bytes after offset 0xc4e9 (headered ROM).

Ok, I'm using Hex Editor Neo and was able to expand the ROM using Insert mode, my next question is the game becomes corrupt after adding the two bytes, the level offset is at hex 0xc498 and the enemy offset is at 0xc0b7, what did I do wrong?

This would be the problem I described in an earlier post.

Let's look at this another way.

The level you want to change is at 0xc498? Okay. Let's say you inserted two bytes before there. That changes where the level's data starts to 0xc49A. But the pointers to the level still point to 0xc498. This means when the game tries to load that level, it's using an offset starting with data you added which could be totally invalid bytes for the subroutine that loads the level. This could crash it or lead to garbage data.

This same thing also affects ALL OF THE DATA after where you inserted the two bytes. You have to update every single pointer that points to an address after the bytes you inserted.

I realize the example was adding bytes before the level not after. I showed what happens here to show you what's going on with known data. But by inserting two (or four or whatever) bytes ANYWHERE, you're destroying everything after it.

I'm admittedly not to familiar with FDS, but there's yet another reason you can't just insert bytes into a rom. Typically, roms are of a fixed size and things are expected to be at a certain byte offset. By inserting bytes into... say the NES version of Super Mario Bros., not only have you made the rom too large, you've also pushed the vectors (addresses stored at the end of the rom that tell the game the address to start at when resetting among other things) meaning the game will likely start at totally garbage data. I can't imagine it'd be much different with an FDS game.

Rom hackers typically find free space in the rom when they want to add stuff. This level, after adding those structures, would be larger than it was before so you can't just put it back where it was. You either have to move the data immediately afterwards to free space in the rom (and update the pointers to it, of course), or find a way to optimize the space the level before it takes up. (Unlikely in Super Mario Bros. Everything is quite compact). Alternatively, you hack it to a different cartridge type that has more space so you can have a field day in the new bank(s).

Now let's go onto why this was probably not difficult for the All Stars programmers. They had source code. Assuming there was enough free space, all they would have had to do is add the data to make those blocks appear. All the pointers afterwards would be updated automatically when the game was assembled. This doesn't happen when you add things in a rom hack, because there's no easy way to tell what's an address, what's data, and what's code. This is the same reason why making a disassembly is difficult, even for really clever programs.

I'm not raining on your parade because I'm a spoilsport. This stuff is actually very difficult, and can't be solved with a total lack of assembly/rom layout/programming knowledge.

Replacing the flying fish behavior with the much simpler fish behavior from the PAL version is probably a good start, unless Nintendo had already done that to the SMB1 source tree before it was forked into SMB2 (J). So I don't know if it'll help a project to hack SMB2 (J), but if you want to squeeze a few more bytes into SMB1, you can always look at the NTSC and PAL disassemblies, and borrow whatever's shorter.


So does doppelganger, who did a heroic job of disassembling and commenting the first Super Mario Bros., and autoreverse, who did the same for the diff to the PAL version. But what makes it really easy for the All-Stars programmers is that their employer owns the copyright, so they don't have to distribute their work as patches in formats that include literal data in the ROM wherever anything has been moved.

Could I just change the area where the game looks for the hex offsets to look for them a couple of bytes later, there are also a bunch of 00's at the end of the ROM. Insectduel's hex offsets Kasumi mentioned has all the level pointers/hex offsets what should I be hex editing to update all the pointers?

The game doesn't really "look for" anything, it goes directly to the specified locations. Maybe you could adjust all pointers, but it would be really hard to find them all without a comprehensive disassembly. There are times when data must be aligned to the addressing space in a certain way though, and moving them could screw things up even if all pointers were fixed.

There must be some option I have here with using hex editor, I have the hex locations to just about everything... I am using Insectduel's hex offset guide for this game. What is can I try changing/adjusting hex-wise?

There is a disassembly by Beneficii, where should I start?

Tepples: What we need is a heroic disassembly of SMB2J. If a decent enough disassembly exists that can be assembled, and there are enough bytes free this is a five minute job. The employer owning the copyright does nothing for how easy the job is to do, which is what I mentioned. It only makes the possibility of consequences less.

Shanem: Hex locations aren't magical keys. Imagine if the rom was completely full. The hex locations wouldn't let you insert a larger level. This probably isn't the case here, but there are a lot of things that can come up despite knowing the hex locations. I keep saying this is difficult, telling you why, and then you ignore it and ask why. Why?

Get beneficii's disassembly to assemble. It includes all the instructions you should need to do so. Find the level in the code. Add the bytes you need. Assemble. If you're lucky, you're done.

We can almost guarantee that if you don't have the disassembly, you will break something else when you change this thing.

To give you a stereotypical /. car analogy, you're asking "I need to move the carburetor 3mm to the left to fit a wire, can I just file off the side?"

It is remotely plausible that, if a large enough empty block currently exists, you might be able to move the block of data you want to modify into it and change the pointers to it. ("that's ok, I'll just move the carburetor into the gap next to the battery")


Since you found the disassembly, start off by finding the data you want to modify; as a first go, see if you can just insert the two bytes in the right place and rebuild.

Ok so what I need to do is locate the data for world a-1 (which is the fourth block of data in the disassembly, and add the two byttes, then what? will the assembler automatically fix the pointers when assembled or do I need to do something else? In hex editor I see a bunch of 00's at the end of the ROM I wish I could use these, though that seems not to be a solution.

How do I rebuild it after, I know through assembly but which assembler is compatible with win7 ult? I have never assembled before.

Also earlier in the ROM there are three unused rooms, it would be nice if I could use one of the objects from one of those unuse rooms.

The pack comes with instructions for like... 100% of your questions. Check the docs. index.htm tells you everything you need to know to get it to assemble. If for whatever reason that's not in your pack, look here: http://sm2.beneficii.net/

To find the world data LOOK FOR THE LABEL IN THE FILES! Take some initiative. Find stuff!

Ok, I am using Windows 7 64x Ultimate OS and will not work with asm6 or any other DOS-based programs, XP Mode environment emulater takes up too much space but I tried and it keeps freezing (too slow cpu?).

Anyways, I have implemented the changes to the .asm file (sm2data4.asm to be exact) and all that needs to be done is to assemble the file... would anybody using an xp computer be so kind as to assemble the .asm files for me, I will send them to you if you PM me?

And yes, I have tried for the last two hours to do this, at least I did the work and added the data to the asm files, so someone please PM me and I would be glad to make a donation through paypal as reward.

Those are not DOS programs, they're command line programs. You just don't know how to use them. Most of them you just point them to the file you want to do stuff to.

I sent along instructions in PM, as well as gave him an .ips with the changes made. The result of the changes was close, but no cigar. (Unless my code to start directly at A-1 is causing the issue.) It boots just fine, and the level does change but not quite as intended.

Kasumi, sent you PM