fceux 2.2.3 not outputting 64kb wram file for mmc5

With the $5113 address of mmc5, you are able to swap out $6000-$7FFF with 8 individual pages of 2000 bytes each, giving the user 64kb of wram.

I wrote a small test rom with a limited gui, where you can view the entire net's cpu ram, and make changes to any address.

I've also made it where you can change the current page number in $5113, to view it's contents within the $6000-$7FFF section.

With the emulator running, all 8 pages are available. Performing either a reset, or power off/on, all 8 pages are available. When closing out the emulator completely, it only creates a 32kb file, thus, when running the emulator again, it will only have the first 4 pages of wram saved.

I toyed around with the ines header, to try to make it display the wram as 64kb. I was able to make the information window of fceux display the battery wram, as 65####(sorry I don't remember the exact number) and once I performed my tests, it still outputs 32kb.

This also happens with the other 2 major nes emulators, Nestopia & Nintendulator.

I will have a link here, directing those to my test rom. The ines header I believe is incorrect with its wram, but as I stated I adjusted it and still got 32kb.

Thank you to any that can help out!

http://acmlm.kafuka.org/uploader/get.php?id=5248

MMC5 with 64kb of WRAM is a theoretical possibility that was never exploited by Nintendo. Actually released games are either 8k, 16k or 32k. Emulators needs not to support 64kb WRAM in order to fully support the library of commercially released NES/Famicom games. If you write your game and require 64kb WRAM with MMC5, then some emus will have to be modified to support your game.

The default behaviour with ETROM, the board that supports 16k WRAM with two 8k chips (as well as the behaviour used by all commercially released games using ETROM boards) is having one chip battery backed and the other not. It is however possible to change solder pads in order to have both chips battery backed. If a board was made to support 64k WRAM, it fully makes sense to "default" to one 32k chip battery backed and the second chip not.

This is my Super Mario All-Stars NES, on an ETROM board. I didn't make this, a friend of mine did.
http://imgur.com/a/16x2f

My game uses 32kb sram. I'm assuming those 2 chips are 16kb's?

So if I wanted 64kb, would I just be able to have 2 32kb's inserted onto this board instead?

I ask because you said 1 chip is saved, the other is not. But there are 2 chips on the ETROM board I have linked here, and the contents are saved and restored.

Definitely not, 16kbx8 SRAM chips basically don't exist.
(Maybe there is some non-standard chips but they are extremely rare if they exist).


Yes, but you'd also have to change some wiring (possibly through solder pads, or cutting traces etc...) to be sure all adress lines are connected to something meaningful.


Please re-read my post, that's not what I said.

In Lamens terms, from what I've read, emulators don't support it because no commercial nes game ever had 64kb. Then I feel it's very misleading to implement into the emulators, "theoretical" options for the user to select, only to have said emulator not actually output the file size you want. That's my frustration and confusion, I've got people online telling me these emulators can, and your reply, paraphrasing, they can't and have to be modified.

Why bother implement the 64kb wram option at all?

No need for further discussion, basically it doesn't exist. I'll just go on with using the additional 32kb on top of my other 32kb, as vanilla prg-ram that is non saveable.

Well, it's not that they do or don't support it, it is they don't have to support it. I have absolutely no idea about which emulator supports what.


The problem is that the original iNES header only has a way to specify whether WRAM is battery-backed. There is NO way to specify how many WRAM is present on the cartridge, nor, if there is two chips, which chip is battery backed and which isn't. So emulators had to rely to heuristics in order to determine the quantify of WRAM and how much is battery backed before the NES 2.0 header was released. Now that the header is released, many emulators barely supports it, most emulators will ignore it and rely on old heuristics. Some will always simulate the maximum WRAM (that is 64k), if this does not break games that would rely on WRAM bank mirroring, then it's fine and I do not see why they would NOT implement this.

So basically using super-accurate emulators like Nestopia and Nintendulators that uses NES 2.0 headers is your best option. I think FCEU is simple to modify (someone modified it to support dendy square-wave duty cycle inversion) so it should be doable to modify it to support NES 2.0 headers and/or 64kb WRAM entierely battery backed if you really need that.

If there is already a version of FCEU which uses NES 2.0 headers, then my whole post should be ignored and that version should be used. I'm sorry I can't be more helpful but I really don't know which emulators supports or do not support which weird/non-standard features.

Thank you for your very in depth explanation regarding this. Nestopia & Nintendulator support NES 2.0 header. But even after editing the ines file of my test rom, both emulators only output the .sav file as 32kb, even though it recognizes my rom as supporting 64kv, and even displaying it in the information windows as having 64kb sram.. :-/

And FCEUX 2.2.3 release notes says that emulator supports NES 2.0

What game are you developing that will need to store more than 32K of persistent data? Because the attitude I've seen on some emulators' issue trackers is that they're more willing to fix compatibility with current and forthcoming games than theoretical issues that don't noticeably affect compatibility with actual NES programs.

You keep mentioning "romantic". Does this have anything to do with a hack of Koei's Romance of the Three Kingdoms?

Oh sorry, no its my phone doing autocorrect, I didn't realize that was happening. I meant "rom"

As of right now, I don't require it, but I do forsee myself exploiting that feature, but have been hesitant due to my failings of getting my rom to output 64kb.

And I've yet to test the theoretical idea with an mmc5 cart. I just thought this was available to use, over the years of studying and working with the mmc5 mapper.

I get intrigued by things that haven't been done or used. So the idea of having 64kb wram, and have it saves, is very intriguing.

Are you sure that the byte 10 of the NES 2.0 header is set to $0a, a.k.a 64k RAM battery backed, 0k RAM not battery backed ? If you have that, and the emu supports NES 2.0 headers, and it outputs only a 32k .sav file, then I guess it's a bug in the emulator, and you should report it to the author(s). But it seems weird 3 unrelated emulators would have the same bug...

If the behavior in all three is "cap .sav size to that seen in extant Game Paks using boards covered by this mapper", then the shared behavior is understandable.

But no Game Pak has 32k saved and 32k unsaved, the largests (EWROM games) have 32k saved only.

My header as of right now is the following.

4E 45 53 1A 02 01 52 08 00 00 A0 00 00 00 00 00

The "A0" was from me setting the prg-ram to 0kb, and setting the battery backed prg-ram to 64kb. (I used Nintendulator to edit the header)

I still get 32kb output when exiting the rom, this happens in both Nintendulator & FCEUX 2.2.3.

I even changed the 10th byte from A0, to 0A, and I still get 32kb output.

I'm surprised all these end up creating 32kb save files - esp. considering even Disch's old notes say this:The Wiki also says the same thing, at the moment.

Mind you, not quite sure how old Disch's notes are compared to FCEUX/Nestopia/Nintendulator.
Mesen forces the size to be 64kb for all games (ideally I'd want to allow NES 2.0 headers to override this behavior, though)

taken from the Message Log of FCEUX 2.2.3. And again, when exiting the emulator it will only output a 32kb.sav file.



EDIT

I have just obtained MESEN, and it actually outputted a 64kb .sav file for my mmc5 test rom.

So FCEUX, Nintendulator, & Nestopia, do not output a proper 64kb .sav file. I don't want to switch emulators, because I've been coding with FCEUX for all of my projects since 2005. But I hope down the road the developers of those 3 major emulators, will revise these emulators to output 64kb .sav files when the users NES 2.0 header says so.

Once you're close to actually needing both 32K halves battery-backed in your project, feel free to file an issue and attach the source and binary of your test ROM. If you have an easily reproducible test and a good reason, Rainwarrior and the rest of the FCEUX dev team are fairly good at acting on enhancement requests.

Looks like zeromus already put in 64k MMC5 SRAM save support yesterday:
https://sourceforge.net/p/fceultra/code/3373/

Sorry my bad it was effectively $a0 that you were supposed to use. So clearly you are right and the current emus are wrong/bugged when it comes to NES 2.0 support.

This code is awful and does not support the NES 2.0 header at all, it just prepares several cases, probably made-up to support existing games, and quickly added infidelity's case as a work arround. They are not caring about future homebrew using different available RAM sizes on MMC5. It also does not output a proper error message if an unavailable RAM size is used.

Sure, but it solves this particular problem that currently more than zero people are interested in.

If you'd like to submit a patch that offers proper iNES 2 WRAM size support, I'm sure it'd be considered.

Well I don't know but I'd code it something like that (pseudocode):



Even this could be largely improved, but at least it show the idea.

It was zeromus who I was originally directed to, about the 64kb issue. However, he was quite snippy after I asked him how to obtain the latest build. I couldn't find it via goggle, and I've never compiled anything from the link rainwarrior posted. Could someone explain how I obtain this latest build of fceux?

And could someone direct me to those I should contact, that take care of Nestopia & Ninrendulator, so those can be updated too?

Can someone please help me, in explaining how or where to obtain fceux r3372? Or is it r3374? Either way I've had no luck finding these build via google.

Click the "buildbot builds" link on fceux downloads page:
https://ci.appveyor.com/project/zeromus ... /artifacts

Thank you.