Big RAM on FME-7: I have a test ROM

[tepples]

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:

• FME-7 pin 36: PRG A13 output
• 62256 pin 26: A13 input (+CE on 6264; you'll need to cut this)
• FME-7 pin 34: PRG A14 output
• 62256 pin 1: A14 input (not connected on 6264)

(See also SRAM pinout and FME-7 pinout.)

Expected result with 6264

Code: Select all

00: C0 C0 C0 C0 C0 C0 C0 C0
08: C0 C0 C0 C0 C0 C0 C0 C0

Expected result with 62256

Code: Select all

00: C0 C1 C2 C3 C0 C1 C2 C3
08: C0 C1 C2 C3 C0 C1 C2 C3

[rainwarrior]

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?

[lidnariq]

The 32 KiB is an artifact how the powerpak has 512 KiB + 32KiB RAM attached to the CPU bus.

If we're just modifying a board to make sure that the I/O lines values haven't changed, using a 74'244 (or any other tristateable buffer) might make more sense.

(The "little bit of extra logic" is moderately obnoxious: two 74'138s, a 74'74, a 74'174)

[rainwarrior]

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?

[tepples]

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.

[lidnariq]

Since you've already suggested cutting a trace, it seems easiest to me to add an AND gate (74'08) and do rainwarrior's final suggestion.

[l_oliveira]

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 <- $6000
1110000000000000 <- $E000

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

[tepples]

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.

[l_oliveira]

Right on the money:


And 128K too:

[tepples]

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
• BizHawk 1.9.3: Not supported (tested by freem)
• FCEUX SVN: Supported since r3220 (r3218 test result; bug report)
• Mednafen 0.8.D.3: Not supported (tested by tepples)
• nesemu2: <Dead_Body> its on todo list
• Nestopia UE: Not yet tested
• Nintendulator: Not supported (tested by zzo38) but zzo38 claims a new version with the fix is forthcoming
• NO$NES 1.1: Not supported (tested by freem)
• puNES 0.93: Reported fixed by FHorse
• RockNES 5.142: Refuses to load the ROM; confuses NES 2.0 with "DiskDude!" crap (tested by freem)

And for the record, l_oliveira was also able to get CHR RAM working on FME-7.

[rainwarrior]

NES 2.0 support is required

I'm a little confused on this one...

8: Size of PRG RAM in 8 KB units (Value 0 infers 8 KB for compatibility; see PRG RAM circuit)

...

The PRG RAM Size value (stored in byte 8) was recently added to the official specification; as such, virtually no ROM images in circulation make use of it.

When did this happen? Who uses this? It seems to conflict with iNES 2's byte 8.

[tepples]

Most of iNES 2 didn't catch on. NES 2.0 has more support in practice.

[rainwarrior]

What is that even supposed to mean?

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?)

[tepples]

SOROM and SXROM are official MMC1 boards with more RAM than a standard SNROM or SUROM board. ETROM and EWROM are official MMC5 boards with more RAM than a standard MMC5 board.

[rainwarrior]

Is it a problem for any games using these boards if too much RAM is assumed by emulators? What necessitated the revision to byte 8 of iNES 1?