This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Starting a Comprehensive Disassembly of SMB3

Starting a Comprehensive Disassembly of SMB3
by on (#43466)
I think this should be done with the Japanese version, but I think most would want to do the American version, and being as I don't have any real way of doing this myself, I'm going to have to rely on others. Now, I believe I saw some discussion of this earlier, but I think that it is possible to have a real, labelless disassembly done really easily:

CDL all the game as much as you can. If you use something like FCEU ABS, you can use the hex editor to edit the CDL file by guessing which might be code (if it is unused) and then using the menu option on the hex editor to change it to code.

Split the PRG-ROM into separate banks ($2000 bytes long), for both the game file and the CDL file. You'll want the sources for each bank to be a different file, otherwise the source will get too big.

Get CDLDIS and create a batch file that will execute CDLDIS for each bank. CDLDIS takes instructions like so:

cdldis <game-file> <game-startaddr> <cdl-file> <cdl-startaddr> <# bytes> <out-file> <print-addr> <org>

So, for our purposes, do for each line:

CDLDIS BANKNN.BIN 0 BANKNN.CDL 0 2000 BANKNN.XXX M OOOO

Where NN is the bank number, XXX is the extension (ASM for if you're doing a reassembleable disassembly, or DIS or TXT for if you're doing a disassembly that is not reassembleable, but allows you to look at the memory addresses next to each line), M for whether to do a reassembleable disassembly (put "N") or a non-reassembleable disassembly (put "Y"), and 0000 for the slot the bank gets loaded into, which will be either 8000, A000, C000, or E000.

Now run the batch file.

With that, you should be able to get some rough disassemblies going. Now, to consider some good ways of getting the labels organized. I have some ideas, but I'd like to hear others first.[/url]

by on (#43491)
What? No one is going to reverse engineer SMB3 for you. You'll probably have to do it yourself if you want to see it done. And what is the goal in the end? Particularly what is the point of a "rough" disasm? If you can't rebuild it it seems silly. It will take you a long time to go through a game as big as SMB3 and figure out what all the code does and why.

A few days ago I disasmed Donkey Kong, a 16Kb game. It took quite some time to get all the labels back manually, and it would have taken forever to really go through every bit of code and figure out what was going on. But I did make the source buildable. You couldn't move the data around though unless you went and changed all the fixed addresses out of the code for labels.

Anyway, I highly recommend you have an end goal for why you'd want to disasm a game. And the answer shouldn't be something silly like it would be "cool".

by on (#43492)
MottZilla wrote:
What? No one is going to reverse engineer SMB3 for you. You'll probably have to do it yourself if you want to see it done. And what is the goal in the end? Particularly what is the point of a "rough" disasm? If you can't rebuild it it seems silly. It will take you a long time to go through a game as big as SMB3 and figure out what all the code does and why.

A few days ago I disasmed Donkey Kong, a 16Kb game. It took quite some time to get all the labels back manually, and it would have taken forever to really go through every bit of code and figure out what was going on. But I did make the source buildable. You couldn't move the data around though unless you went and changed all the fixed addresses out of the code for labels.

Anyway, I highly recommend you have an end goal for why you'd want to disasm a game. And the answer shouldn't be something silly like it would be "cool".


I would do this step had I the tools. Unfortunately, I only own a Mac OS X PowerPC laptop and do not have the means to purchase a Windows computer, or one where something like Wine or Darwine would work. There are no good emulators with hacking capabilities for the Mac OS X; in fact, there are no good emulators period. You might say it is a cheap excuse, but it is the truth. If someone else would post their CDL file, however, I can take up the rest.

Also, to say that this would necessarily be for my benefit is false, as I have seen discussions by others who wanted to do this as well.

I think that for labels, the best technique would be to create over a long period a symbol list that has corresponding memory and game file addresses for the labels (and perhaps also specifying the number of bytes that piece of data or code runs), and then to update CDLDIS to insert those labels into the code as it disassembles. Once a format is decided, it would be easy to do. But a key point is that a human, as opposed to a computer, would decide what is labelled and grouped together, which I think would allow for a more accurate disassembly (in terms of how close it is to the original source).

The next step would be to, say using my address use logger in FCEU ABS as a guide, determine what lines of code reference what labels and how they reference them. A human would be superior here as well, because they be able to determine if arithmetic is used to get the final address, rather than putting a brand spanking new label where arithmetic would be more likely used as a computer would.

By the way, good job with Donkey Kong. I understand what you are saying with moving data and code around, as I did get on to Doppelganger (a little) about that in his thread with the comprehensive disassembly of SMB1, because there were small sections of code that still used bare address references which caused errors when I shifted the code and data around. (He fixed them all.) Still, both of you did a good job and have attained something I haven't attained, but hope to with SMB2J.

There would be many purposes for such a disassembly: It would be cool, easier to hack, easier to understand, easier to learn from, etc.

by on (#43493)
Gotta get this question out here...
US PRG0 or US PRG1?
They are different, you know...

by on (#43494)
beneficii wrote:
Unfortunately, I only own a Mac OS X PowerPC laptop and do not have the means to purchase a Windows computer

And you can't find anything to virtualize Windows in this list?

by on (#43496)
tokumaru wrote:
beneficii wrote:
Unfortunately, I only own a Mac OS X PowerPC laptop and do not have the means to purchase a Windows computer

And you can't find anything to virtualize Windows in this list?


Bam, thanks so much. Just ordered a Virtual PC 6 for PowerPC Mac with Windows 98SE on eBay. Thanks for your advice.

by on (#43497)
Dwedit wrote:
Gotta get this question out here...
US PRG0 or US PRG1?
They are different, you know...


Well, now that I can do it myself, as soon as that VPC arrives in the mail, it will be the Japanese version! :twisted: :evil:

by on (#43504)
Well I wish you luck. Personally while it's a neat idea to me, I'm much rather write my own game than try to reverse engineer one. ;)

by on (#43505)
MottZilla wrote:
I'm much rather write my own game than try to reverse engineer one. ;)

I got ideas for President's architecture from the DC and DG disassemblies of SMB1: transfer buffers, object-based level data, sprite 0 shaped like rows 6 and 7 of a tile in the status bar, attribute data in upper 2 bits of metatile that also selects which of four metatile tables gets used. I'd bet such "borrowing" happened in the NES's commercial era as well.

by on (#43595)
I actually started working on this a while back, but I've been pretty damn sidetracked...

by on (#43603)
I got some ideas from the RE docs of SMB, even though I don't code for NES. For starters, my GBA game had a collision test loop that ran every object. Even with sorting, it killed performance. Then I decided to structure the object routines more like SMB and only tested collision when an object had to move (it takes place in a large scrolling room with lots of stuff, think SMB2/Doki Doki with 30 mushroom blocks in one room). Also, jump tables!

by on (#43609)
Well, to be honnest I could say a few things.

Dissasembly of games we don't have acess to the souce can be usefull to see how some games did some tricks that you couldn't think off by yourselves. Also it's great to have dissasembly for ROM hackers who wants to change one thing or two in the source code. However, full disasemblies are very hard to provide, and are completely useless. If I were to have to clone SMB3, I think it would probably be easier to re-write everything from scatch than trying to disasebly everthing and to understand how it works. Because some parts of the code (those who are close to the hardware and those who are close to data in a friendly formatted format) are easy to understand, you'll have to admit it would take ages to understand what other piece of code could do.

The fully commented of SMB disassembly is nice, but is completely useless when it comes to developping a game. You can see how the jump table tricks works which is interesting, but you didn't need to disassemble the whole game for that.

So I say if you're bored and want to investigate in some project you may as well do something else cool like programming debugging or developping tools or programming games.

by on (#43610)
Bregalad wrote:
Also it's great to have dissasembly for ROM hackers who wants to change one thing or two in the source code. However, full disasemblies are very hard to provide, and are completely useless.


Completely useless? What could be more useful to a ROM hacker than having complete details on every aspect of the target game? Doppleganger's SMB disassembly has been put to wide use in ROM hacking circles (hell even I've used it on more than one occasion to find a few things and I don't even hack SMB).

ROM hacking isn't really about cloning a game or making a new game from scratch. It's about changing an existing game. I think that's where your views seem to differ. If someone's goal is to code a game from scratch, then yes -- a disassembly of a similar game probably isn't the greatest thing in the world (but I certainly wouldn't call it "useless" in any event). But to a ROM hacker just looking to change one or two things (or even to radically overhaul lots of stuff), there is no greater tool.

by on (#43611)
Very complex games such as Sonic 1 and 2 for the MD/GEN have been disassembled into reassemblable code, and the ROM hackers have a great time with them.

by on (#43612)
Sur a disassembly is great for ROM hacking, but it doesn't need to be complete.
Only the part that are to be ROM hacked, which are usually close to the I/O stuff and far away from the core engine, are worth disassembling.

If you want a complete ROM hack that changes 100% of the ROM then you might as well write a new game.

by on (#43613)
Bregalad wrote:
Sur a disassembly is great for ROM hacking, but it doesn't need to be complete.


Of course it doesn't need to be, but a complete disassembly is certainly more useful. You don't need any disassembly at all.

Quote:
Only the part that are to be ROM hacked, which are usually close to the I/O stuff


Underlined for emphasis. Besides I'm not even sure this statement is true anyway.

Quote:
and far away from the core engine, are worth disassembling.


I'm going to go out on a limb and say you've never made such a ROM hack. I'll even go so far as to say that you've never even really seen/tried any of these kinds of hacks.

It's hard to accurately comment on what is useful to ROM hackers when you're not a ROM hacker. And you clearly don't seem to be one.

Quote:
If you want a complete ROM hack that changes 100% of the ROM then you might as well write a new game.


Agreed. But ROM hacks don't ever change 100%, that's the point. That doesn't mean multiple ROM hacks won't collectively change 100% (ie: what one ROM hacker decides to change, another might decide to keep, and vice versa).


And let's not forget the value disassemblies have to homebrewers. Examining other game's sources can be a very useful tool. I can't tell you how much examining other emulators' sources have helped when making my first emulators. And seeing how a game does a specific effect, or how it handles specific edge cases, or how it stores certain information, etc, etc, can all be useful to know when designing your own game.

by on (#43614)
I did use Dopple's doc to make every Bowser throw hammers. It was just changing one little byte from $05 to $00 but I wouldn't have found it without notating the whole game (well, it wouldn't have been that hard to find but I wouldn't have bothered).

by on (#43616)
Disch, what's a ROM hacker? Bregalad "hacked" Contra's japanese version from Konami VRC to Nintendo MMC3. He also was working on doing a similar hack for Gradius 2. Seems much like real hacking to me.

But I do think that it helps to disasm games and make fully commented and buildable source code, if you can spare the huge amount of time it takes to do that. In the end it's up to who does it if it is worth the effort and time to them. Personally I wouldn't bother with that sort of effort unless I planned to do some huge hack of the game myself.

I do think it is helpful to see how some games did various small parts of the game so that homebrew developers can benefit from that.

by on (#43632)
MottZilla wrote:
I do think it is helpful to see how some games did various small parts of the game so that homebrew developers can benefit from that.


From a homebrewer perspective, If we could extract some of those tricks done in various games in some kind of code repository that we could search about a specific subject, that would be great.

The problem is to take the time to extract that information and what information is really valuable since "valuable" is quite subjective. In brief, something similar to Bootgod database but for coding. I would be reading that site all the time I guess :lol:

by on (#43636)
Bregalad wrote:
Dissasembly of games we don't have acess to the souce can be usefull to see how some games did some tricks that you couldn't think off by yourselves.

Like map compression in a way that supports multidirectional scrolling. Or like efficiently representing music.

tokumaru wrote:
Very complex games such as Sonic 1 and 2 for the MD/GEN have been disassembled into reassemblable code, and the ROM hackers have a great time with them.

How do disassemble-hack-reassemble modders distribute "patches" against the original copyrighted ROM in this case?

by on (#43638)
tepples wrote:
Bregalad wrote:
Dissasembly of games we don't have acess to the souce can be usefull to see how some games did some tricks that you couldn't think off by yourselves.

Like map compression in a way that supports multidirectional scrolling. Or like efficiently representing music.

tokumaru wrote:
Very complex games such as Sonic 1 and 2 for the MD/GEN have been disassembled into reassemblable code, and the ROM hackers have a great time with them.

How do disassemble-hack-reassemble modders distribute "patches" against the original copyrighted ROM in this case?


They just distribute the ROM usually. But you could always write a program to do the patching on an original ROM, moving data around and such. I did that for my Splatterhouse SD mapper hack as massive amounts of data were changed and if I used an IPS patch then the patch itself would have included almost all the CHR.