The Incomplete SMB2 Disassembly Project
Moderator: Moderators
The Incomplete SMB2 Disassembly Project
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!
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!
- Hamtaro126
- Posts: 823
- Joined: Thu Jan 19, 2006 5:08 pm
Re: The Incomplete SMB2 Disassembly Project
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?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!
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".
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".
-
- Posts: 76
- Joined: Sun Sep 30, 2007 9:54 pm
- Location: Corneria
- Contact:
Compliation on Linux
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.
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.
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.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.
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?
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. ^_^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.
That's part of why some developers use API wrappers such as wxWidgets or Allegro.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.
- Hamtaro126
- Posts: 823
- Joined: Thu Jan 19, 2006 5:08 pm
Can you mix this with FCEUABS?
http://www.angelfire.com/nc/ugetab/fceu ... 07_NSF.rar
It helps you debug NSFs.
http://www.angelfire.com/nc/ugetab/fceu ... 07_NSF.rar
It helps you debug NSFs.
- Hamtaro126
- Posts: 823
- Joined: Thu Jan 19, 2006 5:08 pm