The wiki page about iNES mapper 1 says emulating mapper 1 is problematic for games with more than 8KB of SRAM or more than 256 KB of PRG ROM.
Also, Neil Baldwin has encountered many problems when he was willing to use such a configuration. Even if he did an iNES 2.0 header and using Nestopia, you can't always get the amount of SRAM you'd specify in the header. And since Nestopia, the only emulator who supports iNES 2.0, has no debugger you'd want to be able to debug your programs with Nintendulator and FCEUltra.
However, because it's simple and available at RetroZone, using Mapper 1 even for larger/complex games is a very good option.
On the Wiki page about mapper 1, I proposed an algorithm that supposedly emulates proprely all MMC1 games that doesn't rely on memory mirroring.
However I'd ask myself, while Nintendo made CNROM boards can only allow 32kb of CHR-ROM, it's iNES counter part, mapper 3, can allow up to 1MB of CHR-ROM (in fact you could even have 255 CHR banks and have almost 2MB, but non power of two sizes aren't recommanded).
So why not go a step further and recreate something similar for mapper 1, which could even include boards that "were never made", with an algorithm that, if followed stricly, would allow to accurately emulate all commercial MMC1 games that doesn't rely on memory mirroring, and to emulate all future MMC1 homebrewn games as long as they don't rely on memory mirroring (no matter if they fit a Nintendo made board or not).
Because even on SXROM, there is still one bit unused for the CHR Registers, maybe it should "officially" be assigned for an additional SRAM banking bit (in a similar fashion as the additional CHR banking bits of mapper 2 or 3) ?
This has the disadvantage of not allowing more than 512kb of PRG ROM, but with so much RAM at your disposal, you could heavily compress a lot of things, allowing in theory really large games.
Also, there should be a way to determine which banks are saved and which aren't, that englobes Nintendo made boards but allow for future expansion.
Of course a game that would write something to SRAM, write something to the CHR registers and exept the SRAM to *NOT* be bankswitched will not work with such a system. Is there any commerical NES/FC games who did that ?
"Mapper 1" emulation & extension
Moderator: Moderators
"Mapper 1" emulation & extension
Useless, lumbering half-wits don't scare us.
You could do a MMC5 game with 512kb PRG + 512kb CHR like Metal Slader Glory. Of course you'd have to burn ROMs to test it, but it would be emulable and you don't have to make your own board.
Or heavily compress everything in 512kb PRG and decompress in a crazily large SRAM (it's what I was talking about above).
Yet there is nothing that "officially" specify what to do if you input amount of PRG-RAM that doesn't exist in existing Nintendo games...
I was just under the impression that having a third bit for SRAM banking would make sense... but the problem is to know what is battery backed and what is not. iNES 2.0 allows you to specify the quantity of battery backed SRAM and non-battery backed SRAM. However, it doesn't allow you to specify HOW it's mapped.
Also maybe emulator authors would be more prone to simply fix a few things in a mapper than fully implement iNES 2.0 that no ROM uses ?
Or heavily compress everything in 512kb PRG and decompress in a crazily large SRAM (it's what I was talking about above).
Mmh yeah I guess you're right...Wouldn't the easiest fix be for emulators to actually use the information in the header properly? There already is a PRG-RAM size field. If the emulator is just ignoring it, it should be fixed. No reason to try to go about fixing it another way.
Yet there is nothing that "officially" specify what to do if you input amount of PRG-RAM that doesn't exist in existing Nintendo games...
I was just under the impression that having a third bit for SRAM banking would make sense... but the problem is to know what is battery backed and what is not. iNES 2.0 allows you to specify the quantity of battery backed SRAM and non-battery backed SRAM. However, it doesn't allow you to specify HOW it's mapped.
Also maybe emulator authors would be more prone to simply fix a few things in a mapper than fully implement iNES 2.0 that no ROM uses ?
Useless, lumbering half-wits don't scare us.
Since 1MB is a lot of space, I bet that a lot of it is data, not code, so I suggest that you get the game working in a smaller ROM size with some of the data missing, but make it easily expandable so that you can later include the rest of the data, which you'll do once the code is done. At that point, your game will be practically ready, and emulator authors will have a motivation to support it.65024U wrote:I want to make a game tat will be 1MB in size. But one problem is testing. Burning a cart for every test is not plausible, and emulation won't happen because of it being not released. I love this idea and hope ALOT that it happens somehow!
My NSF Player on SNES was 4Mbytes, and I had to test it using floppy disks. But echoing what tokumaru said, I had made a cut-down version of it that was easier to test, using some conditional assembly commands (if, else) to simply not include the massive loads of data (just empty labels pointing to the same thing).
The beta version of Nintendulator can load NES 2.0 images.Bregalad wrote:Nestopia, the only emulator who supports iNES 2.0
Interesting.On the Wiki page about mapper 1, I proposed an algorithm that supposedly emulates proprely all MMC1 games that doesn't rely on memory mirroring.
Unless Memblers is about to make some IRQ circuitry that can be added to any MMC1 + CHR RAM board, and it wants a bit to control IRQ generation and acknowledgment.Because even on SXROM, there is still one bit unused for the CHR Registers, maybe it should "officially" be assigned for an additional SRAM banking bit
There are things that won't fit into even 512 KiB. For example, most of the data in Big Bird's Hide and Speak (384 KiB) is Carroll Spinney's voiceover, including much of the CHR ROM. And if you want a lot of voice acting in a game, or a lot of prerecorded music (say for something like Dance Dance Revolution), you'll need lots of space, though like tokumaru said you can test it with less data (in DDR's case three songs at a time). It has uses even other than audio: consider that the HKO port of Final Fantasy VII to Famicom is four times this 512 KiB.This has the disadvantage of not allowing more than 512kb of PRG ROM, but with so much RAM at your disposal, you could heavily compress a lot of things, allowing in theory really large games.
The two most accurate NES emulators are both free software. You can take one of the existing emulators and hack your preferred mapper to allow a 1024 KiB PRG ROM.65024U wrote:emulation won't happen because of it being not released.
The Final Fantasy VII port is a horrible example because it goes down to 467KB when compressed with APLIB, and 347KB when compressed with 7-zip. Look at that file in a tile editor, lots of blank space, and lots of repeated two byte sequences spanning kilobyte after kilobyte.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
I think the idea is to split it up into multiple "discs", each with a part of the game, during development. That way, you have one ROM until Aeris dies, one ROM for most of the second half of the game until Batman pees, and one ROM just to put swords in my knees. The programming techniques to split it up could also be used to make a 1-chapter demo if you plan on selling copies of the whole thing.65024U wrote:Yeah thats true, but it's 1MB ROM, 8K CHR-RAM :/ And I could cut it down to 512K, but that will only support it upto halfway into development IMO. :/
If you use CHR-RAM, graphics is usually an element that can compress well.
If you don't mind using CHR-ROM, MMC3 has support for up to 256k of CHR-ROM, and I think MMC5 can even allow up to 1MB.
You could also distribute it in FDS format, using as many disk sides as you want (although I suspect the Power Pak to only support 2 disk sides so far, but in theory it could load 8 disk sides at a time, and even have support for more, loading them from the CF cart whenever needed, which would probably be about as slow as the real FDS).
(This FF7 pirate is a terrible example as the game was terribly ported. It's a plain insult to one of my favourite games so I don't like it being mentioned. Is's just a bunch of pirate crap.) Anyway, a game that fits ~300k compressed could be put in a 512 k ROM, and being decompressed into 32 or 64k of SRAM at a time, kinda like FDS disk sides once again
(64k is the size of one FDS disk side).
EDIT : Oh an my algorithm still won't work for FF1+2... as the multicart uses bank 0 for FF1 and bank 2 for FF2, it will "think" the cart is SOROM and will save only bank 2. I'm short of ideas here... realying on the PRG size for this (if it's 512k it can't be SOROM) is NOT a good idea.... yet the only way to tell FF1+2 apart from SOROM games in the iNES 1.0 header.
If you don't mind using CHR-ROM, MMC3 has support for up to 256k of CHR-ROM, and I think MMC5 can even allow up to 1MB.
You could also distribute it in FDS format, using as many disk sides as you want (although I suspect the Power Pak to only support 2 disk sides so far, but in theory it could load 8 disk sides at a time, and even have support for more, loading them from the CF cart whenever needed, which would probably be about as slow as the real FDS).
(This FF7 pirate is a terrible example as the game was terribly ported. It's a plain insult to one of my favourite games so I don't like it being mentioned. Is's just a bunch of pirate crap.) Anyway, a game that fits ~300k compressed could be put in a 512 k ROM, and being decompressed into 32 or 64k of SRAM at a time, kinda like FDS disk sides once again
(64k is the size of one FDS disk side).Cool but then it probably shouldn't be assigned to mapper 1 anymore, as it's definitely more than just a simple extension.Unless Memblers is about to make some IRQ circuitry that can be added to any MMC1 + CHR RAM board, and it wants a bit to control IRQ generation and acknowledgment.
EDIT : Oh an my algorithm still won't work for FF1+2... as the multicart uses bank 0 for FF1 and bank 2 for FF2, it will "think" the cart is SOROM and will save only bank 2. I'm short of ideas here... realying on the PRG size for this (if it's 512k it can't be SOROM) is NOT a good idea.... yet the only way to tell FF1+2 apart from SOROM games in the iNES 1.0 header.
Useless, lumbering half-wits don't scare us.
How about we make a standard where if the PRG size is bigger then what is supported via the PRG-ROM bank switching bits, the CHR-ROM bank switching character bits are used from MSB to LSB on the PRG-ROM. So the 512K ROM would be used with the most significant CHR line, while the 1MB bit would be the 2nd most significant CHR-ROM bit available, and so on. I think thats something we should consider maybe getting added to emulators for support of 1MB and bigger ROM's automatically without hacking.
And also, the game I want to do is the pokemon game with 256 pokemon with two 32x32 images for each, so CHR-ROM is out of question, like the battle screens, the pokemon change every time and you just can't use CHR-ROM at all, that'd make the 256K of graphics take up ALOT more in CHR-ROM. Way more then can be used....Thats what I need the 1MB cart for with the CHR-RAM.
And also, the game I want to do is the pokemon game with 256 pokemon with two 32x32 images for each, so CHR-ROM is out of question, like the battle screens, the pokemon change every time and you just can't use CHR-ROM at all, that'd make the 256K of graphics take up ALOT more in CHR-ROM. Way more then can be used....Thats what I need the 1MB cart for with the CHR-RAM.