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]
Starting a Comprehensive Disassembly of SMB3
Moderator: Moderators
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".
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.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".
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.
Bam, thanks so much. Just ordered a Virtual PC 6 for PowerPC Mac with Windows 98SE on eBay. Thanks for your advice.tokumaru wrote:And you can't find anything to virtualize Windows in this list?beneficii wrote:Unfortunately, I only own a Mac OS X PowerPC laptop and do not have the means to purchase a Windows computer
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.MottZilla wrote:I'm much rather write my own game than try to reverse engineer one.
-
doppelganger
- Posts: 183
- Joined: Tue Apr 05, 2005 7:30 pm
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!
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.
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.
Useless, lumbering half-wits don't scare us.
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).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.
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.
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.
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.
Useless, lumbering half-wits don't scare us.