This has bothered me quite awhile now, and I'm really interested in the challenge if it would be possible.
Some FDS-games only consists of a 32K PRG-data and 8K CHR-data. In theory this might run on a mapper 0 setup (assuming all code is remapped to $8000 instead of $6000 and assuming PRG-RAM is treated as ROM).
The problem is, of course, the code-remapping. I haven't come up with a solution for this that doesn't involve tons and tons of work.
The reason I'm typing this, I am currently out of ideas, perhaps someone else have some clever ideas?
There's always the NROM-368 proposal, which has linear ROM from $4800 to $FFFF.
I just hacked a game to be MMC1, copied the code to RAM at 6000, then ran the game. This is fine for tiny games like Ice Climber.
I converted Almana no Kiseki (Miracle of Almana) from FDS to MMC1 awhile back. It really depends on the game and what you're going to put into a cartridge to run it. If a game doesn't actively write to above $8000 then many cartridges could work. But some games write all over the available space making the only viable existing cartridge a MMC5 with 32KB of SRAM.
If someone made a wla-6502 compatible disassembler, that could simply generate labels which would be remapped to the 8000 space.
That's true for any assembler ... the hard part is the disassembler correctly identifying jump and data tables, &c. After that, relocating it is trivial.
Patch to MMC1, that's brilliant.
I just converted "New Clu Clu Land"(FDS) to run as an INES file instead. Works great!
Can anyone point me in the direction of some documentation that would explain how to convert an FDS title to MMC1 ?
I want to achieve what Mottzilla did, convert Almana no Kiseki (Miracle of Almana) from FDS to MMC1. Unfortunately he hasn't shared his patch publicly.
Any help would be greatly appreciated. Thank you!
"How do I do the same thing Intelligent Systems did to Zelda 1, Metroid, Kid Icarus, and initially Doki Doki Panic before it was ported to MMC3?"
Before you begin, it helps to have substantial 6502 assembly language experience. First you need to produce a commented disassembly. Then you need to rearrange the data used by the game into 16K banks and make sure writes are confined to $6000-$7FFF, not $8000-$DFFF.
A long, long, long time ago, I tried this with 32k games simply by filling a .SAV file with $6000-$7FFF, and the PRG-ROM portion with $8000-up as usual. Those small NROM-like games worked fine. (Not on real hardware, of course.)
A mapper that allows RAM at $6000-$FFFF (perhaps MMC5 is somewhat capable but the documentation is really a nightmare for us mortals) would be pretty nice in terms of porting FDS-games to NES.
No mapper allows mapping RAM into $E000-$FFFF. Obviously one could be designed, but then emulator support would be a pain.
Only the MMC5 supports mapping RAM into $8000-$DFFF. What can we do to help make the MMC5's documentation more approachable?
Maybe combine NROM-368 and FDS stuff, also make it so only ram is mapped at 4800-DFFF.
EDIT: Typo Corrected