This is the second in a series on improving our understanding of the FME-7, the first being IRQ acknowledgment. So let's do some big RAM yoga (not to be confused with Bikram Yoga).

As of March 2015, NES emulators disagree on how much RAM at $6000 a game using Sunsoft's FME-7 mapper IC can see.

FME-7 register 8 sets both the PRG ROM bank at $6000 and whether $6000 is ROM or RAM. It's been speculated that even if this register is set to RAM, the FME-7 will still drive the PRG ROM bank output lines based on the selected bank number. If this is true, the 6264 (8Kx8 SRAM) on the NES-BTR or JSROM PCB can be replaced with a 62256 (32Kx8 SRAM), and an NES program can use all four 8K banks. This would provide ample space for a Z-machine or BASIC interpreter.

Run this test on a Batman: Return of the Joker or other FME-7 board with PRG ROM, CHR ROM, and WRAM. I have no experience modding carts myself, but these signals should be relevant for rewiring a cart to use a 62256:

If you're already modifying the board by adding 2 bank select lines to your SRAM, couldn't you add a little bit of extra logic to make it work whether or not those lines function with RAM selected in-mapper? Like, if you're already willing to go as far as rewiring the boards, what the "mapper" becomes is really up to you.

It seems more like we're proposing to extend mapper 69 than trying to figure out whether it supports bankable RAM. The extant boards clearly don't. This is really more a question of whether this is a logical extension of the mapper that emulators should support. (My opinion on that is: yes, it does seem sensible enough.)

Also, why did you limit it to a 62256? Why wouldn't we use/try all 6 lines?

For the purposes of the hardware test, since the address lines we are testing are already connected to a PRG-ROM, maybe it would be easier to just do the test without RAM, and rewire the board to keep PRG-ROM enabled when RAM is "supposed" to be in use?

Would it be easier to put LEDs from PRG A13 and A14 to ground, sort of like the "8-Bit XMAS" board, and just jump into a tight loop in RAM? I could make a second test ROM that does that.

That particular test can be done with the cartridge board alone, you don't need the NES to perform it if you can perform the signaling that correspond to the actual register writes (Kazzo for example could be used for that).

I'll wire up a 32KB SRAM on my FME-7 cart tomorrow and have your program a run.

Pretty much aligned with what rainwarrior said, this arrangement could be attempted with another mappers, including the popular MMC3. The only thing that worries me is the fact that a lot of mappers uses A14 and A13 to judge which bank of ROM it's supposed to map into and at $6000 A13 and A14 will be at 1 the same way they would be at $E000...

0110000000000000 <- $60001110000000000000 <- $E000

Meaning the mapped address lines will always be stuck at 1 at these memory ranges.

Pretty much aligned with what rainwarrior said, this arrangement could be attempted with another mappers, including the popular MMC3. The only thing that worries me is the fact that a lot of mappers uses A14 and A13 to judge which bank of ROM it's supposed to map into and at $6000 A13 and A14 will be at 1 the same way they would be at $E000

True. I think I mentioned this earlier in #nesdev, that the bank switching part of the MMC3 can't tell $6000 from $E000. That's why I've been pushing for more FME-7 testing: I have an application in mind that needs more than 8K of RAM and a raster timer* but not all the complexity of MMC5. I imagine that if the existing hardware behavior supports the long-proposed extension of mapper 69, emulator authors are more likely to warm up to the extension.

* Or some extremely clever use of DPCM Split that'd be a pain to get right seeing as I own no PAL NES nor PAL TV.

Thank you for confirming that the FME-7 works exactly as loopy had speculated. I've updated the wiki with these findings, and the next step is to get it into emulators. It may be a little tougher than last time because NES 2.0 support is required for an emulator to know when to apply this.

FME-7 big RAM status whiteboard

PowerPak loopy mappers: Supported (tested by tepples)

EverDrive: Not supported (tested by tpw_rules)<tpw_rules> can you work on bothering krikzz please

Do any emulators support byte 8 of an iNES header as PRG-RAM size? Should the wiki even suggest this? Does anyone know of an example ROM that uses this rather than the default 0 value? (How many mappers had variable sizes of WRAM in practise? Is it only needed for homebrew?)

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum