The Incomplete SMB2 Disassembly Project

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
beneficii
Posts: 127
Joined: Tue Jul 12, 2005 4:37 pm

The Incomplete SMB2 Disassembly Project

Post by beneficii »

Because of other demands, I must delay working on this, but I would like to help others to work on this too, if they would like. If anyone wants to provide any input on this (particularly modifications adding labels), then go here:

http://beneficii.net/smb2/

This isn't begging or anything, this is just a heads-up to those who want to assist. I provide a number of tools to assist those who want to provide a helping hand. Thank you!
User avatar
Hamtaro126
Posts: 823
Joined: Thu Jan 19, 2006 5:08 pm

Re: The Incomplete SMB2 Disassembly Project

Post by Hamtaro126 »

beneficii wrote:Because of other demands, I must delay working on this, but I would like to help others to work on this too, if they would like. If anyone wants to provide any input on this (particularly modifications adding labels), then go here:

http://beneficii.net/smb2/

This isn't begging or anything, this is just a heads-up to those who want to assist. I provide a number of tools to assist those who want to provide a helping hand. Thank you!
Good job, one problem about FCEUXD ABS: You did not put in the EXE file, There is only the source code. Can you please make a EXE file?
User avatar
beneficii
Posts: 127
Joined: Tue Jul 12, 2005 4:37 pm

Post by beneficii »

Hamtaro126,

I agree, that is an issue. It's now been fixed, so you can download and get the EXE. ^_^
User avatar
beneficii
Posts: 127
Joined: Tue Jul 12, 2005 4:37 pm

Post by beneficii »

Just so you know, I've made some more updates of the file. Excepting most of its subroutines, I've finished the NMI and IRQ so far. I also updated the CDL and DIS files with new code set ("sm2main_" 61dd-61e0 range set to code logged).

Thus far, I've finished the main routine, the sound engine, and the victory music (at the end when you rescue the princess) sound engine that is in file "sm2data3".
Karatorian
Posts: 76
Joined: Sun Sep 30, 2007 9:54 pm
Location: Corneria
Contact:

Compliation on Linux

Post by Karatorian »

I was pointed to your tools from a posting at romhacking.net and had hoped to use them for a project I recently began working on. Unfortunatly, FCEU-ABS doesn't compile cleanly on Linux.

The first problem I ran into was that the Makefiles had all been renamed to "makefile", which is not only non-standard, but causes compilation to fail on a case sensitve OS (such as un*x) unless they are changed back.

However, that was just the first issue. When I attempted to compile (using Makefile.unixsdl), the compilation failed due to not having some Windows headers. It appears that whatever changes you made to the build system where in the wrong Makefile (Makefile.base or Makefile.common), rather than in Makefile.win where they belong. This is quite unfortunate as it breaks one of FCEU's greatest strenghts, it's wide portability and cross platform nature.

CDLDIS did compile, but without FCEU ABS, I have no way of using it. This is sad because from what I've read, it looks like you've developed some solid tools.

Just so you know, I'm using GCC 4.1.2 and GNU Make 3.80, on Debian.

I'd be willing to help you restore the code to portability, so please respond. Thanks in advance and keep up the good work.
User avatar
beneficii
Posts: 127
Joined: Tue Jul 12, 2005 4:37 pm

Post by beneficii »

I was pointed to your tools from a posting at romhacking.net and had hoped to use them for a project I recently began working on. Unfortunatly, FCEU-ABS doesn't compile cleanly on Linux.

The first problem I ran into was that the Makefiles had all been renamed to "makefile", which is not only non-standard, but causes compilation to fail on a case sensitve OS (such as un*x) unless they are changed back.

However, that was just the first issue. When I attempted to compile (using Makefile.unixsdl), the compilation failed due to not having some Windows headers. It appears that whatever changes you made to the build system where in the wrong Makefile (Makefile.base or Makefile.common), rather than in Makefile.win where they belong. This is quite unfortunate as it breaks one of FCEU's greatest strenghts, it's wide portability and cross platform nature.
I expected this if someone attempted to compile the program on another system, but I did not break the cross-compatibility. FCEU ABS is descended directly from FCEUXD SP v1.07 and so inherited all its problems. I did notice that many of the added features (perhaps since FCEUD, perhaps FCEUXD) did not seem to also be implemented on any of the other operating systems (if you look under "drivers," you'll find unique files for each OS). I recognized the problem, but at the time I did not consider it worth it to do anything about it.

As for the problem with the makefiles, the Windows compiles did not make use of anything but makefile.base, makefile.win, and makefile.common (I believe). Because I resigned myself to compiling in Windows, I did not pay the other makefiles much attention and did not make any modifications to them. I inherited a pretty messy emulator. ^_^

The issue with a lot of the tools that use Windows is that other operating systems most certainly do not use the same API and therefore each of the windows would have to be reprogrammed. Windows imposes a system that isn't very cross-compatible.

Perhaps we should look up the line of precession for this emulator to find out where the cut-offs occurred?
CDLDIS did compile, but without FCEU ABS, I have no way of using it. This is sad because from what I've read, it looks like you've developed some solid tools.

Just so you know, I'm using GCC 4.1.2 and GNU Make 3.80, on Debian.

I'd be willing to help you restore the code to portability, so please respond. Thanks in advance and keep up the good work.
I think those would be the same that I used. As for restoring the code to portability: I would be willing to provide assistance where I can on it. It would be an interesting lesson for me, as I don't believe that I am as knowledgeable about makefiles as I should be. Let's see what you have in mind. ^_^
tepples
Posts: 22819
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

beneficii wrote:The issue with a lot of the tools that use Windows is that other operating systems most certainly do not use the same API and therefore each of the windows would have to be reprogrammed. Windows imposes a system that isn't very cross-compatible.
That's part of why some developers use API wrappers such as wxWidgets or Allegro.
User avatar
beneficii
Posts: 127
Joined: Tue Jul 12, 2005 4:37 pm

Post by beneficii »

Well, someone should have told the people who went and made FCEU non-compatible in the first place. Still, with enough work and patience, we can probably reimpliment something like that on FCEU ABS.
User avatar
Hamtaro126
Posts: 823
Joined: Thu Jan 19, 2006 5:08 pm

Post by Hamtaro126 »

Can you mix this with FCEUABS?

http://www.angelfire.com/nc/ugetab/fceu ... 07_NSF.rar

It helps you debug NSFs.
User avatar
Hamtaro126
Posts: 823
Joined: Thu Jan 19, 2006 5:08 pm

Post by Hamtaro126 »

Can you please disassemble Doki doki panic, so me and Disch could figure something out?
User avatar
beneficii
Posts: 127
Joined: Tue Jul 12, 2005 4:37 pm

Post by beneficii »

A bump for an important update, in which the use of relative labels within functions becomes allowed. This may make it a bit easier to do this project.
Post Reply