Hi guys,
I've been trying to find info on the graphical enhancements the MMC5 can provide, but couldn't find a thing.
I know it has a mode for writing to the screen while the PPU is rendering, has enhanced attribute handling (assigning paletes to each tile), has a split screen mode, etc. At least I think it does these things.
None of the MMC5 documents I found explain anything about these topics. I've seen people talking about "exGraphics" or something, but I don't know exactly what it refers to.
Do you know of any documents, or maybe know stuff from memory and want to share?
In fact I don't know if I'd be comfortable using such extensions, since they deviate from "classic NES" too much. But in extreme cases, it might come in handy.
Oh, and maybe you could point out some games that actually use the extensions, not just the mapper.
Thanks for the help.
http://tripoint.org/kevtris/mappers/incoming/mmc5.txt <-- covers everything sans the sound in great detail.
Just Breed uses the sound, and Extended attribute mode.
Metal Slader Glory also uses Ex Attribute mode (I think?)
Uchuu Keibitai SDF is the only known game to use split screen mode -- and only for the intro (where it shows the ship stats). This game also uses the sound for sound effects.
Shin 4 Nin Uchi Mahjong - Yakuman Tengoku also uses the sound heavily in the music (it even uses $5011 for sound effects). Also interestingly (though somewhat unrelated), it drives it's music engine by APU frame IRQs rather than by NMI.
I'm not sure if any games use Fill Mode or ExRAM as a 3rd nametable.
Metal Slader Glory does not use extended attributes (it just uses 512KB of CHR ROM), though it does use extra sound (for the "character speaking" sounds).
Laser Invasion/Gun Sight uses both fill mode and 3rd-nametable ExRAM.
All of the Koei games which used the MMC5 used it almost exclusively for its extended attribute mode.
The "extended attribute" mode also includes the ability to address 16,384 different tiles on a single screen without having to bankswitch - each ExRAM byte provides 2 attribute bits and 6 tile bank bits for every 8x8 tile in the active nametable (all nametables use the same ExRAM, so you're better off using single-screen mirroring).
Uchuu Kebatail SDF definitly uses many of MMC5 graphics features.
Just Breed is worth a look, it uses the MMC5 to have much more tiles on screen at the same time. Non-NES devloppers will just say that the game has good graphics, but I myself think that backrgound are really enhenced, allowing more diferent kind of buildings, trees, and many details as most SNES game. It also features all monsters and allies drawn via BG on field, that couldn't be done trough a normal mapper (Fire Emblem does it, but with much less sort of people, and they all watches down when not moving unlike to Just Breed). However, each ally sprite is here twice in the CHROM, once for when it's BG and once for when it's sprite, I would found myself more interesting to use the same tiles for both, allowing an even higher quantity of graphics for the background or effects in battle.
Quietust, does your emulator support the MMC5 accurately?
I'd like to play with the features of MMC5 a little, and would like to know if I can trust Nintendulator for that.
It seems to be a very hard mapper to implement, since it changes almost everything we know about NES graphics...
tokumaru wrote:
Quietust, does your emulator support the MMC5 accurately?
I'd like to play with the features of MMC5 a little, and would like to know if I can trust Nintendulator for that.
It seems to be a very hard mapper to implement, since it changes almost everything we know about NES graphics...
Yes, I've got 99.9% support for the MMC5 in Nintendulator - the only thing missing is that "special" read-triggered raw PCM channel (as described in the patent), and no games ever actually used it.
Guys, I'm having a little trouble trying to figure out how CHR bankswitching on MMC5 actually works... maybe you could help me clear up some stuff?
If you use 8x16 sprites you can have 512 tiles only for sprites, and 256 more for BG, right? And you use the respective set of registers to switch sprites or BG. But the docs say you can use any of the 2 sets of bankswitching registers when using 8x8 sprites. Does that mean that using the second set ($5128 - $512B) will result in duplicated data? I mean, will $0000-$0FFFF and $1000-$1FFF contain the same tiles at all times? Why would anyone want that?
And that also means that to get the "normal" bahaviour with 8x16 sprites (access to both sprite and BG tiles) you'd have to load the BG tiles twice?
Also, the regular NES setting of "wich pattern table to use for sprites and wich to use for BG" has no effect at all when using 8x16 mode, right? Since the BG is duplicated and in 8x16 you can access all 512 tiles with an 8-bit index...
I have another question, not related to bankswitching. I heard you could write to the EXRAM at anytime, even during rendering. Is that true? I guess it may be true when you're using CPU $5C00-$5FFF to do it, right? If it does work like this, what do the results look like on screen? You can actually see a tile cut in half if by any chance you changed it when half of it was already rendered?
Thanks for the help!
EDIT: Oh, and what about "fill mode"? What the hell is that all about? Why would anyone want a screen filled with the same tile using the same colors? Has anyone ever found an use for it? Really? Can you at least change it while rendering? Then it may be useful...
tokumaru wrote:
If you use 8x16 sprites you can have 512 tiles only for sprites, and 256 more for BG, right?
yes
Quote:
And you use the respective set of registers to switch sprites or BG. But the docs say you can use any of the 2 sets of bankswitching registers when using 8x8 sprites. Does that mean that using the second set ($5128 - $512B) will result in duplicated data? I mean, will $0000-$0FFFF and $1000-$1FFF contain the same tiles at all times? Why would anyone want that?
Yes. That's probably not a "feature" as much as it's a side-effect. This will only happen when $5128-512B are the
last set of registers written to. For example, if you want a full 8k of CHR for bg/sprites with 8x8 sprites (like how normal mappers do it)... all you have to do is make sure you don't write to $5128-512B after you write to $5120-5127. If you write to $5120-5127 last... then those regs determine the full 8k to use.
Quote:
And that also means that to get the "normal" bahaviour with 8x16 sprites (access to both sprite and BG tiles) you'd have to load the BG tiles twice?
Not quite sure what you mean here... the BG does not use the same pattern pages as sprites do in 8x16 mode. If you want BG and sprites to share the same tiles, you must swap in the desired CHR page to $5128-512B
Quote:
Also, the regular NES setting of "wich pattern table to use for sprites and wich to use for BG" has no effect at all when using 8x16 mode, right? Since the BG is duplicated and in 8x16 you can access all 512 tiles with an 8-bit index...
As far as I know... yes.
Quote:
I have another question, not related to bankswitching. I heard you could write to the EXRAM at anytime, even during rendering. Is that true?
Depends on the mode. If ExRAM is in mode 3 (mode determined by last write to $5104), the CPU cannot write to it at all... but any other mode (0-2) the CPU can write to it... I
think at any time. It'll probably work in emulators if you write there during rendering... but it might cause problems on the real thing if you're in ExAttribute mode... but I don't really know.
Quote:
Can you at least change it while rendering? Then it may be useful...
I believe so. That'll certainly work on most emulators... but again, I'm not quite sure if it'd fly on the real thing (it probably would though)
Disch wrote:
Quote:
And that also means that to get the "normal" bahaviour with 8x16 sprites (access to both sprite and BG tiles) you'd have to load the BG tiles twice?
Not quite sure what you mean here... the BG does not use the same pattern pages as sprites do in 8x16 mode. If you want BG and sprites to share the same tiles, you must swap in the desired CHR page to $5128-512B
Sorry, I wasn't really clear here... When I said "normal", I meant "not using MMC5". But you answered it anyway! You have to load the tiles once for BG and once for SPR, using both sets of registers at a time, ok.
Quote:
Quote:
I have another question, not related to bankswitching. I heard you could write to the EXRAM at anytime, even during rendering. Is that true?
Depends on the mode. If ExRAM is in mode 3 (mode determined by last write to $5104), the CPU cannot write to it at all... but any other mode (0-2) the CPU can write to it... I
think at any time. It'll probably work in emulators if you write there during rendering... but it might cause problems on the real thing if you're in ExAttribute mode... but I don't really know.
I read in the docs that in some of the modes the PPU will get only 0's when trying to read ExRAM. I don't know if there is a mode where both CPU and PPU can access the ExRAM.
Quote:
Quote:
Can you at least change it while rendering? Then it may be useful...
I believe so. That'll certainly work on most emulators... but again, I'm not quite sure if it'd fly on the real thing (it probably would though)
Logic says it is possible, right? Since we're not messing directly with the PPU, we're messing with what is sent to the PPU... but not always the NES follows any logic. =)
Thanks for the confirmations, Disch!
tokumaru wrote:
I read in the docs that in some of the modes the PPU will get only 0's when trying to read ExRAM. I don't know if there is a mode where both CPU and PPU can access the ExRAM.
That's if you set ExRAM to be a 3rd nametable when the PPU cannot read from ExRAM (ExRAM modes 2, 3). If you keep ExRAM in mode 0 or 1, the PPU will get the proper values from ExRAM when read.
Interestingly, modes 0, 1, and 2 are all CPU writable (but only mode 2 is CPU readable). So that leads me to believe that it
would be possible to easily change tiles around by messnig with $5C00-5FFF during rendering (if you're using ExRAM as a 3rd nametable in mode 0)... although somehow I find it hard to believe that would work.
Quote:
Logic says it is possible, right? Since we're not messing directly with the PPU, we're messing with what is sent to the PPU... but not always the NES follows any logic. =)
I don't really know enough about hardware to really analyze the logic... but the idea of RAM being accessed by two different areas at the same time (worse yet... one read and one write at the same time) would cause conflicts and potentially corrupt one of the accesses.
It wouldn't suprise me at all if the MMC5 contained the hardware to sort all that out and allow you to access everything during rendering. But at the same time it wouldn't suprise me at all if you couldn't write during rendering. I'm afraid I can't give you a definative answer on this one =/
Interestingly enough, ExRAM, while in mode 1, can only be written (via $5C00-$5FFF) while rendering - if you try to write during VBLANK (or while rendering is disabled), the data won't make it through properly.
Regarding Fill Mode, it's a very handy way to instantly produce a solid screen of a particular color (since you can change all of the tiles and all of the attribute bits each with a single write). Laser Invasion/Gun Sight uses this in numerous places where it scrolls an image in from a solid screen - namely, at the titlescreen animation, taking off into the flying areas of levels, and boss battles in said flying areas.
Yeah, writing to EXRAM during rendering works just fine, Just Beed does this A LOT (and my game will too).
Doing it during VBlank will NOT work, all your writes will write the value $00 instead. That's doing it the other way arround than PPU acess. In other words, you can only acess PPU or EXRAM, but never both at the same time.
However, if you change something in EXRAM that the PPU is just displaying, you may get glitches. I'm not sure about that, but the first and last 8 scanlines are safe on a standard NTSC system (however, glitches may still be here on a PAL system).
That must be the most weird thing I've ever heard about the NES (the fact that ExRAM writes work exactly in the opposite way as PPU memory).
Now, I have a somewhat unrelated question to ask. If any of you could answer it, that would be great! The question is about address $5130 of MMC5. I understand it is used for the high bits when you're swiching small CHR banks in, and also used to define wich 256kb bank to get tiles from when in extended attribute mode. But are these related? I mean, the tiles mapped into the pattern tables must be from the same 256kb page as the BG?
The document Disch pointed me to says: "The upper 2 bits are stored when the register is written to, and their value is determined by 5130" wich makes me think that, regarding bankswitching, the value at $5130 is only important at the exact time the switching happens. Is that how it really works? Or must all graphics belong to the same 256kb page?
Thanks for the help, again!
tokumaru wrote:
wich makes me think that, regarding bankswitching, the value at $5130 is only important at the exact time the switching happens. Is that how it really works?
Yes. Since the registers at $5120-512B are actually
10 bits wide (not 8), the value in $5130 gets copied to their high bits on any write to $5120-512B.
The only other time $5130 is significant is in ExAttribute mode, which it's used as the high CHR bits for ALL the tiles.
So would you do it like this?
Code:
lda foo+1
sta $5130
lda foo
sta $5120
lda bar+1
sta $5130
lda bar
sta $5121
OK, Disch, thanks for clarifying this. I thought that maybe $5130 was sort of "active" on the loaded CHR banks. It is a very good thing it works the way you said. Not that it would be so bad if it was the other way around, though. 256 KB at a time would be more than enough on most cases!
So, I can use $5130 when bankswitching small (1 or 2 KB) banks, and then set it to the 256 KB bank I want the BG with extended attributes to use, before rendering starts. It should cause problems if you try to bankswitch CHR midframe, right? Would BG rendering be disturbed if you changed $5130 midframe?
Oh, one more thing: If you're bankswitching larger banks (4 or 8 KB) does the value at $5130 matter at all? I mean, do you have to clear the 2 bits before switching or is the mapper smart enough to know you'll not be using those bits?
tokumaru wrote:
So, I can use $5130 when bankswitching small (1 or 2 KB) banks, and then set it to the 256 KB bank I want the BG with extended attributes to use, before rendering starts. It should cause problems if you try to bankswitch CHR midframe, right? Would BG rendering be disturbed if you changed $5130 midframe?
If you're using ExAttribute mode, you'd have no reason to swap CHR mid-frame... since it's hardly needed for sprites and the CHR registers are not used at all by the BG when in ExAttribute mode (except for $5130)
But yes, changing $5130 during rendering in ExAttr mode would mess with the display.
Quote:
Oh, one more thing: If you're bankswitching larger banks (4 or 8 KB) does the value at $5130 matter at all? I mean, do you have to clear the 2 bits before switching or is the mapper smart enough to know you'll not be using those bits?
The short answer: no, $5130 doesn't really matter when swapping 4k/8k banks.
The long answer: kind of. The CHR regs are all always 10 bit regardless of what swap mode you're in... however how the bits get used changes depending on the mode.
for example:
Code:
LDA #$03
STA $5101 ; enter 1k swap mode
LDA #$01
STA $5130
LDA #$04
STA $5127 ; swap in $104 * 1k .. CHR offset $41000
LDA #$00
STA $5101 ; enter 8k swap mode
; here, $5127 still contains $104, however since we're now in 8k swap
; mode, it swaps in $104 * 8k .. CHR offset $8000 (due
; to 1MB max)
LDA #$00
STA $5130
LDA #$04
STA $5127 ; swap in $004
; here, since we're in 8k swap mode, that write didn't APPEAR to do
; anything because it's still swapped to CHR offset $8000
LDA #$03
STA $5101 ; re-enter 1k swap mode
; here... since we're now in 1k mode and $5127 contains $004, it swaps
; to CHR offset $1000
So as that example tries to demonstrate... the high bits written to the regs are not completely ignored when in coarse swapping modes... however they aren't really used in swapping due to the 1MB limit.
Disch wrote:
If you're using ExAttribute mode, you'd have no reason to swap CHR mid-frame...
Yeah, you're right. With 512 tiles avaliable for sprites why would anyone want to swap... It isn't very usefull anyway. It's just that everytime I'm trying to figure out the logic on something, all kinds of weird questions start to show up for some reason! =)
I think I understand the example on the higher 2 bits thing. Apparently they don't matter because if you go over the 1 MB limit (wich you may if the bits are set and you're using 4 or 8 KB mode) it just wraps around... But when you change the swap mode to smaller chunks you may not get the correct banks if you're not carefull with what's on $5130.
Thank you really much for the help. I know I can be a little annoying on the details sometimes!
no problem at all... glad I could be of help
Wait, no known MMC5 games write more than once at reset to $5100-$5103. I didn't check that myself, but if I remember right J2 told me that, meaning that change PRG bankwitching or CHR bankwitching size any time *may* not work fine. This was just a notice, I'd recomend to make test on hardware to make sure changing CHR banks size cause no problems before doing that.
You mean games will most likely set the bank sizes at startup and never change it through the rest of the program? Well, there is no BIG advantage in doing this anyway...
ExRAM mode ($5104) can be changed at will though, right?
Quietust wrote:
Interestingly enough, ExRAM, while in mode 1, can only be written (via $5C00-$5FFF) while rendering - if you try to write during VBLANK (or while rendering is disabled), the data won't make it through properly.
Can we just do a quick review of ExRAM modes? In mode 0 it works exactly as an extra name table/attribute table, accessed through PPU writes and all, right?
In mode 1 (ExAttribute mode), only writes at rendering time work. But that's if you write through CPU memory only, right? Is it still writable through PPU during vblank?
In mode 2 it works as regular RAM, is that it? What about mode 3? What's the use of it?
Thanks again.
$5104 can be changed as will, and maybe $5100-$5103 also can, but (probably) all known games does change it only on startup, that doesn't mean that it isn't allowed, that means that it could not be allowed.
I'm not totally sure about mode 0 and what it does, but I think that $5c00-$5ffff will just be used as a third nametable, swappable in via $5105 by written logic 2 to one of the four nametable spcace. In that mode, write trough $5c00-$5fff must be done during rendering, but you can also write to it via normal nametable writes via $2006/7 out of rendering. Mode 0 is the most obsure one for me at least, so I'm not very sure about everything.
In mode 1, nametable 2 can also be swapped in for use, but the result isn't usefull, scince the attributes/high 14-bits index will be read from the same loction as the low 8-bit index, so this isn't of any use (exept if you want to write to EXGrafix RAM via $2007 in VBlank, I'm not even sure that would work, but it probably would).
In practice, you'll most probably want to use mode 1 to only have one-screen miroring, and the low values would be done trough one of the normal values, and the high values trough ExGraphix RAM via $5c00-$5ffff.
Mode 2 works for regular RAM, but it can be usefull if you want to write to EXRAM during VBlank, because the PPU cannot acess it it will work, unlike mode 0 and 1.
Mode 3 is read-only RAM, writing to it has no effect. I have no idea about how it could be used in practice, maybe just for read content of EXRam during rendering without risk of corruption with the PPU ?