nesdev.org

Oh, goddamnit. These things are coming out of the woodwork.

Yeah, I went ahead and fixed that. Then I ran a complete check on every branch and jump in the file, and could find no others. But anyway, thanks again for finding those bugs.

My methodology was simple: I ran a disassembler on the program rom, then started at the beginning (reset vector) and traced out all the code. The first version of this file I uploaded was full of gaping code and data holes.

Anyway, sometimes I would trace out more code, sometimes I would go over the code with both FCEU and my intuition to figure out what the code did, and sometimes I did both at the same time. I was able to expedite the process of figuring out the level data format by comparing notes with others who had done SMB1 hacking in the past, and I was able to actually verify that, for the most part, their own ideas were correct. Some other parts, like enemy data, I had sparse information on. For the rest of the code, however, I was for the most part completely on my own.

It became fully functional (meaning it could be assembled) sometime in February I believe. But although it was filled with comments, it was almost completely devoid of labels. So I went back and replaced all the memory locations with addresses. Some of the values which would have led to confusion I replaced with constants. This was the part I call the clean-up phase. Still, I'm only human, and even I overlooked some of them, apparently.

Anyway, that's pretty much how I did it. It's not something that anyone else with a lot of free time and a shitload of patience couldn't do.

Can it be reassembled and still work even if you move parts of the program and data around within the 32 KiB PRG space? If so, rom hackers will have a new tool for making even more total conversions. Imagine moving all the level data and enemy logic to $8000-$BFFF so that S*ROM or U*ROM can switch it out when needed.

tepples,

Yes. I converted it to being assembleable with CA65 and then modularized it and then moved the modules around. This was how I discovered those bugs. But once I fixed the 2 bugs I mentioned here, it's a good build! ^_^

EDIT: Additionally, I wonder what is the best method for modularizing so that you could add in extra switchable banks so that you can add more data in?

-----------------------------------------------

doppelganger,

I've been eying doing disassemblies of smb2J and smb3 (Japanese version), but I realize they would be much tougher because of the bank switching. Nevertheless, though I'm still trying to figure out the data loading/saving mechanisms of the FDS, I think I'm making decent progress in planning how I'm going to do the smb3 disassembly.

Basically, I made some modifications to FCEUXD SP v1.07 having added an Address Use Logger, which among other things logs the exact PRG (as opposed to just ROM) addresses accessed by opcodes. I'm not done obviously, but I think that if used in conjunction with the Code/Data Logger you can get a pretty good idea of how this is to be disassembled and how you're going to apply labels to each of the referenced addresses.

Good job. Now all we have to do is write a freely licensed replacement for each of the modules, like LAME did, and we'll have bootstrapped ourselves a complete side-scroller engine free of Nintendo copyright. Who's up for the task? Or is it too big?

tepples,

Or just use it for a ROM Hack--though the IPS file for that would probably contain a lot of the original game code--, or just use it as a guide to learn how to write your own sidescroller.

EDIT:

For a ROM Hack, you might just want to distribute the source code and the INES header (with possibly the CHR-ROM if it's heavily modified) along with instructions for how to assemble it.

I am curious to see how you modularized it. It was pretty chaotic to do, I bet.

I've tried everything to get it to assemble.

X112F doesn't do anything, when I try to use it it says "not enough memory"

And I tried the other assembler and did all the changes, but it still gets errors.

CKY-2K/Clay Man wrote:And I tried the other assembler and did all the changes, but it still gets errors.

Which "the other assembler", and which errors?

Clay Man,

X112F doesn't do anything, when I try to use it it says "not enough memory"

If you're using Windows XP, then you probably want to get something like DOSBox (Google it) so that you can have an environment under which the assembler can be run.

All,

Has the source code to the assembler been released?

CKY-2K/Clay Man wrote:X112F doesn't do anything, when I try to use it it says "not enough memory"

I don't think you need DOSbox for this. I can run it in 2k just fine... after I change its memory settings.

Right click on the exe and go to properties. In the Memory tab, you have to change one of the settings to give it more mem (I forget which kind of mem, though).

Disch,

I was having the issue on my school's computers (which have XP) and I had set the memory settings to max. So in response I got DOSBox. But whatever gets it working for the person... ^_^

Perhaps I should break this thing up into smaller pieces.

Yeah, Windows XP seriously pisses me off. I can only run pure DOS things under command promt.

One of the reasons why I was urging my mom to install Windows 98 on our old computer.

Make it for the CA65 toolchain, and everyone will be happy. CA65 is ported to Linux, to Windows, and to PC DOS.

It works fine. Perfectly done. This is my first time really trying out compilers/assemblers and all. Same exact hex.

All I need to do after I compile it is add an iNES header and the graphics.

Good job.