Metroid ported to use the MMC3.
Moderator: Moderators
Re: Metroid ported to use the MMC3.
Replacing sound engines is generally not too hard, they tend to be fairly self-contained.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: Metroid ported to use the MMC3.
An update: I'm continuing to reformat the disassembly so that all the code and data could be moved anywhere and still referenced by any other code. Basically, this goal could be divided into two separate sub-problems:
1. Code in the switchable banks ($8000-$BFFF) reference data and routines in the fixed game engine bank ($C000-$FFFF).
2. Code in the fixed bank ($C000-$FFFF) references data and routines in the title bank (0), area banks (1-5) and the graphics bank (6), which are switched in at runtime ($8000-$BFFF).
The eight banks are assembled separately, and the assembler used by the original disassembly (Ophis) does not have any easy ability to export address/label mapping*. So I wrote my own quick and dirty C# console app that can output a list of addresses, mapped to labels. This solved the first problem from above: at this point, code from banks 0-6 can call any labeled routine in the fixed game engine bank - and these routines can be relocated anywhere (I've seriously reorganized bank 7 - the assembled binary no longer resembles the original METROID ROM). This reorganization has left 303 bytes of contiguous free space in the fixed bank - enough for a few small extra routines.
Now I'm starting to move code around in the other banks. This presents a new problem: the fixed bank references addresses in the switchable banks, and the switchable banks reference addresses in the fixed bank. Mutual dependancies! I decided to solve this problem by adding 'address tables' at the beginning of the switchable banks: instead of the fixed bank jumping to direct addresses in the switchable banks, it will instead jump to indirect addresses from an address table at $8000. Here's an example of what the address tables look like.
I've found that there's a ton of addresses in the switchable banks that haven't been labeled, so at this point I'm going through the code, labeling things, and building the address tables. Once this task is done, I think I will have solved the second problem I listed above - and my "main goal" from the first sentence in this post will be complete.
* A quick note - changing to an assembler that has label exporting capabilities (CA65, perhaps) is beyond the scope of this project. Further, this would not solve the problem of mutual dependancies between the banks. So: more work, problems not solved, sticking with Ophis. As an aside, I've included the assembler as a windows executable within the repository on github, to make assembling the project easier. If anyone using Linux or OSX wants to experiment with it, you can build Ophis from source on those platforms. I'm sure you're used to experimenting.
1. Code in the switchable banks ($8000-$BFFF) reference data and routines in the fixed game engine bank ($C000-$FFFF).
2. Code in the fixed bank ($C000-$FFFF) references data and routines in the title bank (0), area banks (1-5) and the graphics bank (6), which are switched in at runtime ($8000-$BFFF).
The eight banks are assembled separately, and the assembler used by the original disassembly (Ophis) does not have any easy ability to export address/label mapping*. So I wrote my own quick and dirty C# console app that can output a list of addresses, mapped to labels. This solved the first problem from above: at this point, code from banks 0-6 can call any labeled routine in the fixed game engine bank - and these routines can be relocated anywhere (I've seriously reorganized bank 7 - the assembled binary no longer resembles the original METROID ROM). This reorganization has left 303 bytes of contiguous free space in the fixed bank - enough for a few small extra routines.
Now I'm starting to move code around in the other banks. This presents a new problem: the fixed bank references addresses in the switchable banks, and the switchable banks reference addresses in the fixed bank. Mutual dependancies! I decided to solve this problem by adding 'address tables' at the beginning of the switchable banks: instead of the fixed bank jumping to direct addresses in the switchable banks, it will instead jump to indirect addresses from an address table at $8000. Here's an example of what the address tables look like.
I've found that there's a ton of addresses in the switchable banks that haven't been labeled, so at this point I'm going through the code, labeling things, and building the address tables. Once this task is done, I think I will have solved the second problem I listed above - and my "main goal" from the first sentence in this post will be complete.
* A quick note - changing to an assembler that has label exporting capabilities (CA65, perhaps) is beyond the scope of this project. Further, this would not solve the problem of mutual dependancies between the banks. So: more work, problems not solved, sticking with Ophis. As an aside, I've included the assembler as a windows executable within the repository on github, to make assembling the project easier. If anyone using Linux or OSX wants to experiment with it, you can build Ophis from source on those platforms. I'm sure you're used to experimenting.
Re: Metroid ported to use the MMC3.
A github user named Adam D. has ported the various MetroidMMC3 make scripts to *nix. You'll need WINE and the python environment to run them. https://github.com/ZaneDubya/MetroidMMC3