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

The Incomplete SMB2 Disassembly Project

The Incomplete SMB2 Disassembly Project
by on (#27085)
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!
Re: The Incomplete SMB2 Disassembly Project
by on (#27267)
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?

by on (#27270)
Hamtaro126,

I agree, that is an issue. It's now been fixed, so you can download and get the EXE. ^_^

by on (#27271)
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".
Compliation on Linux
by on (#27311)
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.

by on (#27318)
Quote:
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?

Quote:
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. ^_^

by on (#27320)
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.

by on (#27371)
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.

by on (#27416)
Can you mix this with FCEUABS?

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

It helps you debug NSFs.

by on (#27605)
Can you please disassemble Doki doki panic, so me and Disch could figure something out?

by on (#29487)
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.