It is currently Wed Dec 13, 2017 7:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Nov 30, 2005 11:26 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2005 11:50 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2005 12:04 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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).

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2005 12:10 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 01, 2005 9:36 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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...


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 01, 2005 1:36 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 10:02 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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...


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 11:02 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 11:46 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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!


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 12:46 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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 =/


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 13, 2005 12:47 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 14, 2005 10:34 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
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).

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 14, 2005 5:32 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 14, 2005 5:58 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 14, 2005 6:22 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group