MMC5's capabilities

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

MMC5's capabilities

Post by Great Hierophant »

Simply put, what are the MMC5's capabilities? Here is my doubtless inaccurate list. I know it can support 1MB of PRG-ROM in 32, 16 or 8KB banks. It can switch CHR-ROM in 8,4,2 or 1KB banks. According to the mapper document it can support 512KB for background tiles and 2MB for sprite tiles, separately. It supports two extra pulse and one PCM sound channels. It can do 4-screen nametable mirroring if extra VRAM is on the board. It supports up to 64KB of W-RAM.

It also has a built-in multiplier to speed up mathematical calculations (how often do programs multiply?) It has three graphic extension modes, ExGrafix, ExRAM and Split Screen Mode. ExRAM is 1KB in the chip. ExGrafix can extend the selection of background tiles from 256 to 16384 and allows the programmer to eliminate the attribute table limitations on background colors. Split screen allows multiple sets of nametables to be used and can be enabled after any horizontal tile. The chip uses scanline-based IRQs.
doynax
Posts: 162
Joined: Mon Nov 22, 2004 3:24 pm
Location: Sweden
Contact:

Re: MMC5's capabilities

Post by doynax »

Writing games from an MMC5 chip feels kinda like cheating, you might as well do PC-Engine or SNES development instead.
It IS an interesting chip though but wheter the resulting hardware qualifies as a real NES or not is a matter of opinion..

I guess you should check out some emulator sources. That's what I generally do when the documentation is lacking and I'm uncertain of how something really works.
And since I have no useful information to contribute to this topic I'll seize this opportunity to ask something myself: how good is the emulator support for the chip anyway?
Guest

Post by Guest »

OK, the MMC5s capabilities:


-Up to 1 MB of PRG and CHR ROM (of course the most ever used was 512 KBs of each in Metal Slader Glory) according to Kevin Horton. Both of which are bankswitched in various modes (making in compatible with many games/maooers in a way....one reason why Konami chose this mapper for CV3).


--Bankswitching:
PRG can be bankswitched in 1 32KB bank, 2 16KBs banks, 1 KB 16KBs bank + 2 8KBs banks, and 4 8KB banks. All of the modes are able to span accross 1 MB of data thus if a game did have 1MB of PRG data the game could put any of the banks in any of the areas in any of the bankswitching modes (CHR data cannot do this according to what's known now)

CHR can be bankswitched in 1 8KB bank, 2 4KB banks, 4 2KB banks, or 8 1KB banks. And also there *is* 1 more pattern table in the case of 8x16 sprites. In the case that 8x16 sprites are activated harwarely by $2000 the third pattern table is activated. It's not physically there, but the MMC5 messes with the PPU and makes it available. So PPUs $0000 will contain sprite data, $1000 will contain sprite data, and the MMC5 will contain the background data and trick the PPU into putting it on the screen (sonm PPU $1000 will sort of contain both sprite and backkground depending on what the PPU is doing).

The problem with CHR switching is that in some switching modes i can't span accross the whole 1MB of data (if it was there). 8KB switching can, 4KBs can, 2KBs can only access 512 KBs, and 1KB can only access 256KBs.


-Up to 64KB of onboard SRAM (the most ever used was 32KBs by Romance of the Three Kingdoms 2) according to Kevin.

--The RAM was bankswitched. It could be switched in 8KB banks in the areas of $6000-$7FFF, $8000-$9FFF, $A000-$BFFF, or $C000-$DFFF. Thus you could have either PRG-ROM or PRG-RAM depending on what you want. Although tt could not be switched into $E000-$FFFF probably because of the importance of the last 6 bytes (?). Also the RAM could be battery packed and was very well protected (thus you didn't have to hold the reset button while shutting the power off, although I think it still told you to on the back of the cartridges) because it is "the cartridge that never forgets".

-It has an 8-bit x 8-bit = 16-bit multiplier built into the mapper.

-A very accurate scanline counter, which would generate an IRQ (could be disabled) *exactly* at the set scanline no matter what the settings of the PPU are. The MMC5 knows exactly where the PPU is at all times so (it needs to for all the graphics expansions it does) it can generate an IRQ exactly at the begginning of the scanline set regardless of any settings (unlike the MMC3, although you could set up the MMC3 scanline counter to trigger during HBLANK, which is a little more useful then at the begginning of a scanline). It also let you poll a bit instead of generating IRQs, which might be useful in some very timing sensitive cases.

-It has 1 KB of RAM within the MMC5 chip.It could be use for:


--General Purpose Ram
--3rd NameTable Data + it could be vertically split onto the screen
--ExGrafix Mode (improves colors and graphic capabilities)


-It supported 3 extra sound channels. I believe that the extra channels were desingned for the main purpose of sound effects (so you wouldn't have to interrupt NES channels to play sound efects).

--It had 2 pulse channels just like the internal NES's 2A03 chip (although they don't have frequency sweeps like the NES pulse's do), and the pulse channels were highly used for sound effects in games.

--It also had an 8-bit or 7-bit PCM channel (I havn't studied the only game that uses it...Shin 4 Nin Uchi Mahjong - Yakuman Tengoku, I believe it's 8-bit though). It seems it also has 2 ways to play the data. One is just writing RAW data to an internal register, while the other has to do with "quantized data?" within the region of $8000-$BFFF (the NES's internal DPCM channel delt with memory values in the $C000-$FFFF region (although it could loop into $8000). It seems if you load a byte within the $8000-$BFFF region it would automatically be put into the PCM channel for some reason (I don't see how that's beneficial anyway), but only if a a certain bit in $5010 is set (although no known MMC5 games ever used this method of data transferring, they only used the RAW data way).


-It also supported 4-nametables (sort of...) all of which could be switched into any of the PPU's internal RAM. The nametables were:

--NES's internal Nametable A
--NES's internal Nametable B
--MMC5's internal 1KB of RAM (this 1KB of data could be used for ExGrafix mode instead (which graphically inhanced Nametables A and B together), but I believe you could use Exgrafix mode and 3rd nametable at the same (even split mode as well I believe), even though each would have to have sacrifices depending on how you set it up.)
--MMC5's internal 2 bytes which select 1 character + 1 attribute and fills an entire 960 tiles with the 1 character + 4-color palette.


-An option to vertically split the screen and show another nametable vertically independant of whatever is being displayed (horizontally it is fixed every 8 pixels scrolled horizontally). You could set what area of the screen it would take up (what columns and such) and you could also set another 4KB bank for it to use (I believe it was originally designed for vertical shooters so they could display a status bar with text graphics on the right of left side of the screen indepentally from the other graphics and scrolling on the other side).

-ExGrafix Mode:


--This mode extends the NESs internal graphics capabilties by inputting custom data from the MMC5s internal RAM when the PPU requests certain data. The MMC5 monitors everything the PPU is doing so that when it requests certain data it can give certain data to it. It extends the range of tiles to use in a nametable from 256 tiles to choose from to 16384 tiles. It also lets there be a higher color defition in a smaller amount of area (instead of 16x16 attributes, it reduces to 8x8 attributes).

-The ExRAM in general:

--The internal EXRAM the MMC5 has is very touchy about when and how it's accessed so:

---EXRAM Mode ($5104 = 2, or 3): It is just standard general purpose 1KB of RAM. It can be accessed any time. It can be read or written to at any time (unless it is write protected, in which case it can't be written too). This is the only mode of which the data can be read. It is also the only mode in which it can be written to while the screen is not drawing rendering (although it's possible I could be wrong). In EXRAM mode the MMC5 does not allows EXRAM to be written or read via $2006/7 PPU registers (since the PPU R/W goes to the MMC5 it can write to the data if it's in the nametable memory, but only if it's in split mode (1)). I'm unsure if in EXRAM mode the EXRAM is still allowed to be the 3rd nametable, but I believe it is.

---Split Mode ($5104 = 0): This is a way to display the 3rd nametable's data perpendicularly on the screen with it's own 4KB tile page and it's own vertical scroll value. It can scroll in 1 pixel increments if the board is set to SL, or only in 8 pixel increments if MMC5 board is set to CL (the same way horizontal or vertical mirroring is set on NROM games). You see setting it to SL mode passes the bottom 3 address lines into the MMC5 and then the MMC5 can determine which line of the tile to display based upon the $5201 (vertical scroll value of split mode nametable), while without the 3 bottom address line of the CHR-ROM (CL mode) it can't determine the correct line of the 8 lines and thus can only scroll in 8 pixel increments. Oddly enough though, every MMC5 board I know of it set to CL mode (I havn't seen any board set too SL mode, although I havn't seen them all just like 4 of them).

If scrolled horizontally, the nametable will scroll for 7 (or 8?) pixels and then reset back to it's original position (which is why I think it was designed for vertical shooters). In this mode it can be written to via PPU registers $2006/7 in conjunction with the right nametable settings of $5105 (I believe this is the only mode in which this writing is allowed). I know reading is not allowed in this mode, but I'm unsure of *when* writing is allowed. It should only be allowed during screen drawing as it can only be written while it is being read by the NES (or so it seems, if you write to it while the screen is not drawing and it's in this mode a 0 is written instead, but that's only if you write to it with direct write to $5C00-$5FFF, I'm unsure if it is the same with $2006/7 writes (maybe Brian Pro knows?)).

-- ExGrafix mode + Split mode ($5104 = 1): I've already explained what ExGrafix mode is. I do believe though it can be used in conjuction with Split mode though (you can use split mode and ExGrafix mode at the same time even tough they'd both be dependant on the same 1KB of RAM, it'd still be quite useful though). You cannot read this directly (I'm unsure about $2006/7 reading, but I'm pretty sure you wouldn't be able to). If you directly write to it while the screen is not drawing/rendering then a 0 will be written instead of the value you wrote. You can write to the screen only while it is rendering, and I'm unsure if you can write to it via $2006/7, but I believe you cannot (Brian Pro prolly knows).

--I believe in all the modes the 1KB still acts as the 3rd nametable data (in which you can swap it into the PPU memory via $5105).



Writing games from an MMC5 chip feels kinda like cheating, you might as well do PC-Engine or SNES development instead.
It IS an interesting chip though but wheter the resulting hardware qualifies as a real NES or not is a matter of opinion..
Of couse it's still NES, that's like saying mapper chips make an NES game not NES. The MMC5 just gives the programmer extra functions to use, the NES still dictates everything so it's still NES. The MMC5 really does help out, but the SNES is much more flexible and graphically enhanced so it's the MMC5 isn't that good, It's not like cheating, it's actually (in some ways) much harder to code for, but it doesn't extend the graphic, but not that much as to rival higher consoles.
how good is the emulator support for the chip anyway?
Well, it seems many accurate emulator are able to emulate all of the commercial MMC5 with no hacks (although CRC checks are needed for the amount of RAM an MMC5 game has, Nintendulator allows you to choose in the options for homebrewn games), but homebrewn games seem to act differently in each emulator. Bregelad has made a few demos and I've run them on variuos emulators and each give different results. Nintendulator seems to be the best altough (it's IRQ generating is a bit off though). There are a few uknown things about this chip (it still needs to be fully REed, it seems Brian Pro is going to do it after he finishes his game probably, although I do belive loopy has an MMC5 devcart and has been testing things out with it, Bananmos also has one and his one's PAL, and I think PAL MMC5 chips were marked 'MMC5A').


Uknown:


--Registers:

---$5103: Used in many MMC5 games in their startup code, they just write a 0 to it and that's the only time they ever touch it. It could have something to do with the inability for ExGrafix mode to access modes to access more than 256KBs (also some bankswitching themes can't access the whole 1MB). So it could select the 256KB bank (that'd make sense since it's right next too all the other CHR-ROM bankswitching registers). No games have ever had more than 256KBs (besides Metal Slader Glory, but it didn't use ExGrafix mode) so it'd make sense to write a 0 to the register. It could be a setting for PAL or NTSC timing (who knows, I'll prolly have to check some PAL MMC5 games to see what they write).

---$5800: Just Breed access this register (I forget the values) in the beggining of it's VBLANK routine (after it manually messes with the stack for some reason). I have no idea what this could be for. It's nowhere near any of the other registers.

--Why SL mode is never used. It could have made some other MMC5 function unusable or something.

--The MMC5s PCM channel mode 2 playback (and whether it is 8-bit or 7-bit) is very odd. It's explained in a patent on NESDEV and is quite confusing.

--Accessability of EXRAM. When and how to read and write (not too big of a deal though). It was just recently discovered that you can't write to EXRAM via $2006/7 while in mode 2, but you can in mode 0.

--What the different in revisions of the MMC5 chip are. Theres:

---'MMC5' - NTSC games
---'MMC5A' - I think this chip is used only in the PAL region MMC5 games.
---'MMC5B' - NTSC games




All-in-all I believe the emulation for this chip is pretty accurate, although it could be better.
J2

I'm a horrible writer...heh

Post by J2 »

I'm not at all good at writing (as that really long and hard to read...sry :-) so for an easy to read overview:

http://nesdev.com/wiki/?page=Nintendo+MMC5
doynax
Posts: 162
Joined: Mon Nov 22, 2004 3:24 pm
Location: Sweden
Contact:

Post by doynax »

Of couse it's still NES, that's like saying mapper chips make an NES game not NES. The MMC5 just gives the programmer extra functions to use, the NES still dictates everything so it's still NES. The MMC5 really does help out, but the SNES is much more flexible and graphically enhanced so it's the MMC5 isn't that good, It's not like cheating, it's actually (in some ways) much harder to code for, but it doesn't extend the graphic, but not that much as to rival higher consoles.
Yes, it's still a NES. What I meant was that it's a matter of developing software in the spirit of the console. And coming from the C64 world with 20 MHz CPUs, dozens of megabytes of ram and IDE hard drives I feel the need to draw the line somewhere.

The SNES is arguably in another league. However the PC-Engine really isn't all that different from an MMC5 equipped NES (6502 cpu, a single playfield, 8 kB of W-RAM) - without relying on any non-standard (i.e. rare) expansions.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Major differences between NES+MMC5 and TG16:
  • TG16's PPU allows for 15 colors per tile (in exactly the same way as the Super NES).
  • TG16's PPU allows faking a layer with sprites (as the NES limits sprites to 64 pixels per scanline, or 0.25x overdraw).
  • TG16 has DMA to VRAM, making dynamic tile updating feasible.
  • TG16 has a better sound chip, as nobody commercially sold an adapter to let the 72-pin NES play Famicom style expansion sound.
J2

Wow! New Info

Post by J2 »

I was looking at the wiki today and it seems theres new info on the MMC5. Some of the "uknowns" have been discovered. I'm sure the info wasn't there before so it must have been updated by Quietust recently (probably info from Kevin Horton):

-$5130: As I suspected this register allows ExGrafix + 1K/2K CHR bankswitching regs to extend to the whole 1MB of data. I figured thats what this register did because it was near all the other CHR banking registers + ExGrafix and 1K/2K switching couldn't extend to the whole 1MB chip. So you can scratch that of the "uknown" list (although I accidentally put $5103...typo).

-It was sort of confusing how he explained this register so it could be either:


--1)You write to $5130s lower 2-bits to specify the high 2-bits of whatever banking register you write to next ($5120-$512B) and thus the register you write to next uses the 2-bits you just wrote to $5130 (this may allow each register ($5120-$512B) to have it's own high to bits although I'm not sure). I'm positive though that whatever value that is currently in $5130 while in ExGrafix mode, it'll use the 256KB bank stored within $5130 (every tile).

--2)Every single CHR bank register + ExGrafix mode uses $5130 as the 2 high bits (this seems rather limiting for the bankswitching regs).



-It has also been discovered that $5011 is indeed 8-bits. I figured as much as in Goroh's doc it showed it was 8-bits as well, but now it's been verified.


-It's been discovered that $5010 is readable. I already knew this was readable due to the MMC5 sound patent doc, which states it's readable. Based on the patent though (after re-readin it a a little bit), it seems to me that readin $5010 has something to do with IRQs (as its directly connected to the IRQ generating circuit in the diagram).


--It seems that when $5010 = %xxxxxxx1, then $5011 (8bits) is used to RAWly produuce a waveform (like $4011, just with 8-bits). When $5010 = %xxxxxxx0 it allows another method of producing a waveform using "quantitized data." Well, with this method if the value that is stored in the DAC (from $8000-$BFFF) is %00000000 (silence) then "the stop code detecting circuit" generates an IRQ and I believe $5010-R is to acknoledge this IRQ. Well, thats just speculation based upon a quick read of the MMC5 sound patent on NESDEV so don't think much of it.


-It's also been discovered that $5105 option #2 is only the EXRAM data if $5104 = 0, or 1, and it is NameTable B (Internal to NES NT 2) if $5104 = 2, or 3. Yeah, I'm glad that was verified, I was completely lost how option #3 would act in the different modes.


-$5113 (D2) selects the chip which is already known, but now it's been discovered that it affects the other PRG bankswitching ram regs as well.


-"(coarse horizontal scrolling is ignored in the split region)." It seems that in split mode horizontal scrolling via $2005 doesn't affect the split screen. It was thought before that it scrolled for 7 pixels and then reseted or something like that. I guess it's been disproven.


Wow, that's a lot that has been updated. It answered almost all the questions I had :-) Hmmm as for EXRAM accessing. Brian Pro wrote this quite recently:

http://www.bripro.com/low/mappers/index ... es-mmc5_nt
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Wow! New Info

Post by Quietust »

J2 wrote:-It was sort of confusing how he explained this register so it could be either:[/size]

--1)You write to $5130s lower 2-bits to specify the high 2-bits of whatever banking register you write to next ($5120-$512B) and thus the register you write to next uses the 2-bits you just wrote to $5130 (this may allow each register ($5120-$512B) to have it's own high to bits although I'm not sure). I'm positive though that whatever value that is currently in $5130 while in ExGrafix mode, it'll use the 256KB bank stored within $5130 (every tile).

--2)Every single CHR bank register + ExGrafix mode uses $5130 as the 2 high bits (this seems rather limiting for the bankswitching regs).
As I explained in the wiki entry, method '1' is how it works.
J2 wrote:-"(coarse horizontal scrolling is ignored in the split region)." It seems that in split mode horizontal scrolling via $2005 doesn't affect the split screen. It was thought before that it scrolled for 7 pixels and then reseted or something like that. I guess it's been disproven.[/size]
Not quite - I said COARSE horizontal scrolling (i.e. multiples of 8) - if you scroll one pixel at a time, the split region will move slowly to the right, but once you scroll one entire tile, it will snap back to its original position. If you scroll by multiples of 8, the split area will not scroll at all - it always displays the left/right N columns of the ExRAM nametable.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
J2

Re: Wow! New Info

Post by J2 »

As I explained in the wiki entry, method '1' is how it works.
I was unsure if that was what you really meant. So then it uses the 2 bits in $5130 at the time of writing to the CHR banking register ($5120-$512B), but then stores it so that $5130 doesn't always need that value, which effectively lets every CHR banking register have it's own upper 2-bits. And ExGrafix mode uses whatever is in the 2 lowest bits of $5130 while it is rendering, so quick bankswitching can be achieved, even in the middle of a frame :-)

Not quite - I said COARSE horizontal scrolling (i.e. multiples of 8) - if you scroll one pixel at a time, the split region will move slowly to the right, but once you scroll one entire tile, it will snap back to its original position. If you scroll by multiples of 8, the split area will not scroll at all - it always displays the left/right N columns of the ExRAM nametable.
Ahh, yes your right. I read that wrong :?. OK, so when you scroll it will deviate from it's original position by 7 pixels and then reset on the 8th pixel scrolled horizontally. Well, I'll remember to keep the scrolling horizontally a multiple of 8)...I mean 8 :-)...so that it will effectively move the non-split side nametable, but not the split mode nametable. thx :-)
L0p1N
Posts: 29
Joined: Mon Nov 01, 2004 7:33 am

Post by L0p1N »

Are there any developement tools (e.g. nametable/sound editor) for the MMC5?
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

Nope. I know that J2 was going to make some, but I haven't seen him for a while.
Useless, lumbering half-wits don't scare us.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

There's a version of MCK that supports MMC5 sound.
Post Reply