[Dr. Floppy]

About a year ago, I inquired as to whether or not any MMC5 games utilized 4-screen mirroring? http://www.romhacking.net/forum/index.php/topic,11050.0.html Of course, the answer was no: only two NES titles utilized this mirroring method, and neither of them were among the eight MMC5 games released in the States. It was also established that 4-screen mirroring probably wouldn't be the best bet for my "Alpha" project, which utilizes bidirectional scrolling in only one dimension at a time (if at all).

However, the estimable Mr. Disch did allude to the technical possibility of adding 4-screen mirroring to an MMC5 cart, effectively creating a special version of that mapper. Without going into interminable details, I now have legitimate use(s) for such a creation. However, my pre-production research has unearthed a number of queries which I now submit:


1) Is there anything about the internal MMC5 layout that would prevent or prohibit the addition of extra RAM for 4-screen mirroring?

I figured I'd study the internals of Gauntlet or Rad Racer 2 to see how the extra RAM linked up to everything, then apply those changes to an MMC5 donor cart. By the looks of this image (Gauntlet's board), there is no direct interfacing between the MMC3 chip and the extra RAM itself:

2) What happens to the native 2k on the NES itself? I'm led to believe that the cart-based RAM (8kB for both Gauntlet and RR2, but A12 is tied to ground making it effectively 4 kB) overrides the native console RAM when it comes to Name/Attribute Tables. So the native stuff just sits there looking pretty...


3) How much interference should I expect from the MMC5's pre-existing ExRAM? Obviously, $5104 Modes 0 and 1 are out the window, but since modes 2 and 3 utilize the CPU space at $5C00-5FFF, I'm hoping that they can stick around.


4) Name Table Mapping at $5105: Assuming Mode 2 or 3 is set at $5104, would setting $5105 as #$A4 allow the extra screen data to register in NT's 2 and 3? Or would the MMC5 just keep everything from $2800-2FFF zeroed-out?


And, assuming all of the above is resolved and the project is completed successfully:


5) Do I submit the documentation to Kevin Horton or Marat Fayzullin?


6) Can I pick my own iNES mapper number? (Which ones are left, anyway?)

[Bregalad]

1) Is there anything about the internal MMC5 layout that would prevent or prohibit the addition of extra RAM for 4-screen mirroring?

Yes. The MMC5 takes total controll of mapping the CHR bus, and has been designed to work with the NES' internal 2k VRAM and MMC5's internal 1k VRAM.

2) What happens to the native 2k on the NES itself? I'm led to believe that the cart-based RAM (8kB for both Gauntlet and RR2, but A12 is tied to ground making it effectively 4 kB) overrides the native console RAM when it comes to Name/Attribute Tables. So the native stuff just sits there looking pretty...

Some carts (such as the unlicenced Gauntlet) contain logic so that 2k NES internal and 2k cartridge VRAM are added together to form 4k VRAM. But others such as Rad Racer or licenced Gauntlet uses half of a 8k RAM in the cartridge, and leave both the other half and the 2k NES internal RAM unused. This might sound wasteful but in fact this solution need less parts (no requirement for an external 74HCxxx chip for logic decoding) and might have been cheaper.

3) How much interference should I expect from the MMC5's pre-existing ExRAM? Obviously, $5104 Modes 0 and 1 are out the window, but since modes 2 and 3 utilize the CPU space at $5C00-5FFF, I'm hoping that they can stick around.

Again the MMC5 has total control over the CHR address lines, and this is part of why it has so many pins. I guess this is what you would call "interference", although this appellation is completely wrong I guess.

4) Name Table Mapping at $5105: Assuming Mode 2 or 3 is set at $5104, would setting $5105 as #$A4 allow the extra screen data to register in NT's 2 and 3? Or would the MMC5 just keep everything from $2800-2FFF zeroed-out?

I think #$a4 would use a configuration such as :

A B
C C

where A is NES internal VRAM bank 0, B is NES internal VRAM bank 1 and C is MMC5' internal VRAM. It would not result in true 4-screen mirroring as C is mirrored twice, it would be "3-screen mirroring".


I think your question is out of the scope. 4-screen mirroring was a simple way to extend the VRAM with little hardware so games could come with possibly better graphics (or could be easier to code). Because it was rarely needed, this technique wasn't used in many games : Guantlet and that Napoleon game use it just because they are terribly badly programed unlicenced games and programers were too lazy to code VRAM updates. Rad Racer II uses it for more VRAM with fake 3D effects, which is a better use of it.

The MMC5 was designed with many complex features to increase graphics, and comes with its own extra VRAM (like games which use 4-screen mirroring), exept that the VRAM is internal to the mapper. Because the mapper takes total control of the memory mapping in real time, switching bank on each memory acess, it was designed to be hooked up a certain way and it's design is not compatible with some more VRAM added externally. In other words what you suggest isn't possible in hardware unless you make a modified MMC5 which has it's own internal 2k of VRAM, and then it wouldn't be a MMC5 any longer.

[Dr. Floppy]

Some carts (such as the unlicensed Gauntlet) contain logic so that 2k NES internal and 2k cartridge VRAM are added together to form 4k VRAM.

Interesting. And this extra logic is found on the 74HCxxx chip, located inside unlicensed Gauntlet carts?

I think #$a4 would use a configuration such as :

A B
C C

where A is NES internal VRAM bank 0, B is NES internal VRAM bank 1 and C is MMC5' internal VRAM. It would not result in true 4-screen mirroring as C is mirrored twice, it would be "3-screen mirroring".

Yes, specifically when ExRAM ($5104) Modes 0 or 1 are selected. But under Modes 2 or 3, the MMC5 uses its 1kB as general-purpose RAM mapped to $5C00-5FFF. According to Disch's documentation on MMC5, "C" Name Tables in PPU are filled with zeroes under these modes. Reads from "D" Name Tables are fed a special "fill" tile by the MMC5. From this, I conclude that even if the NES itself had a full 4kB of VRAM (which isn't and never has been part of this proposal), the MMC5 would intercept/replace all reads from NT's 2 and 3 with either #$00 or #$[filltile]. Quite the pickle, indeed!

Again the MMC5 has total control over the CHR address lines, and this is part of why it has so many pins. I guess this is what you would call "interference"...

Yes, albeit unintentional on the MMC5's part. Is it worth evaluating each of its 100 pins to gauge the possibility of manually relinquishing it of some of this control? Or would that just be driving thru Alaska to get to Mexico City?

I think your question is out of the scope. The MMC5... VRAM is internal to the mapper. Because the mapper takes total control of the memory mapping in real time, switching bank on each memory access, it was designed to be hooked up a certain way and it's design is not compatible with some more VRAM added externally.

If I'm understanding this correctly, the distinction between internal/external VRAM is that:

Internal VRAM is located within the MMC5 casing (the black thing on the lower-left) itself...

...whereas external VRAM is located elsewhere on the board (in this case, the fat black thing on the upper-right).

(I'm pretty sure the skinny black thing is the infamous Lockout Chip of +10 Fail.)

In other words what you suggest isn't possible in hardware unless you make a modified MMC5 which has it's own internal 2k of VRAM...

And I'm guessing swapping the 1k internal VRAM for 2k is only the tip of that particular iceberg? That is to say, certain program registers are still going to behave under the assumption that only 1k of EXRAM exists? Half of it would be applied to the 1k of CPU RAM space at $5C00-5FFF, the other half would wind up in Cthulu's lunchbox and "D" Name Tables would probably still act as 32x30 floodfills of a single tile instead of utilizing the expansion. Or would the MMC5 be "smart" enough to apply the internal VRAM to $5800-5FFF, thus setting the stage for accurate 4th Name Table reads after the "floodfill" mechanism is somehow disabled?

...and then it wouldn't be a MMC5 any longer.

Can I call it a MMC7?    I say that only half in-jest, as there's already a strong precedent of mappers which are knock-offs, clones and/or derivatives of earlier ones. (MMC3 --> MMC6 comes to mind.) I'd just like a chance to offset that trend by creating something that earns a spot on the iNES mapper list, and exists because an original game concept was best realized through its use.

~*~*~*~*~

Out of curiosity, how are the mapper chips themselves programmed/produced?

[Bregalad]

Interesting. And this extra logic is found on the 74HCxxx chip, located inside unlicensed Gauntlet carts?

Yes, the extra logic is here to select which chip to select when $2000-$2fff is acedded. It should select the NES chip for half of that, and the cart chip for the other half. Rad Racer II would simply deselect completely the NES chip and select its own chip. A normal cart would just select the internal NES chip automatically. In fact if you open a normal cart (one which isn't MMC5 nor 4-screen mirror) you'll probably notice two pins being connected together on the back : It's exactly what they do, they connect CIRAM /CE to CHR /A13, which enables the NES chip for reads at adresses $2000-$3fff (though $3000-$3fff is normally never read by the PPU I think, if it would be read then it would return mirrors of $2000-$2ffff).

It's also why MMC5 and 4-screen mirror games typically don't work on famiclones, these two pins which are connected on 99% of NES cartridges are already connected internally (and probably not even output to the cart edge) so that games which make another use of NES internal VRAM simply doesn't work.

Yes, specifically when ExRAM ($5104) Modes 0 or 1 are selected. But under Modes 2 or 3, the MMC5 uses its 1kB as general-purpose RAM mapped to $5C00-5FFF. According to Disch's documentation on MMC5, "C" Name Tables in PPU are filled with zeroes under these modes. Reads from "D" Name Tables are fed a special "fill" tile by the MMC5. From this, I conclude that even if the NES itself had a full 4kB of VRAM (which isn't and never has been part of this proposal), the MMC5 would intercept/replace all reads from NT's 2 and 3 with either #$00 or #$[filltile]. Quite the pickle, indeed!

On an electronic bus, only one device should be "selected" to "talk" when the processor reads form an adress. The MMC5 has enable control of all chips (CHR-ROM, internal VRAM and Ex-RAM) and will use it accordingly. Typically when acessing a 'A' or 'B' nametable it will send a signal to select the NES internal VRAM, which will be read or written to. Same for it's own Ex-RAM, exept that in some situations the Ex-RAM can't be read or written to for some reason which I guess returns $00 (I'm not too sure here).

Because the Ex-RAM is mapped both on the PPU and CPU bus, there should be some complex logic making sure both acess doesn't conflict, so I guess yet another logic part inside the MMC5 will stop the read from Ex-RAM and return $00 instead if you happen what you say.

In the end you could connect the CIRAM CE line to another chip, which would split it in two for the NES internal VRAM and your extra VRAM like Gauntlet. Then each 'A' and 'B' nametable could be splitted in halves, and that would make safe 4-screen mirroring possible on the MMC5 (therefore I was wrong with my other post haha).

In other words with such a configuration, a some A' and B' nametables would be created, and whenever A or A' is acceded would depend on the adress. In addition to that, C and D would work as usual with MMC5.

However, emulator support for this is probably nonexistent, and Nintendo never produced any cart with that either, and it would be kinda hard to modify one to add a 74HCxxx chip AND a 2k SRAM.

If I'm understanding this correctly, the distinction between internal/external VRAM is that:



Internal VRAM is located within the MMC5 casing (the black thing on the lower-left) itself...



...whereas external VRAM is located elsewhere on the board (in this case, the fat black thing on the upper-right).

(I'm pretty sure the skinny black thing is the infamous Lockout Chip of +10 Fail.)

Yes this is 100% correct.