MMC5 extended RAM and fill mode
Moderator: Moderators
MMC5 extended RAM and fill mode
According to the wiki MMC5 has the PRG RAM at $6000-$7FFF. When you are using the extended RAM modes 0 or 1, what parts of the PRG RAM are used for these features? Mode 1 can also be used as a extended nametable. How does this work with the additional attribute data used in that mode? The wiki mentions that the fill mode can be used for screen transitions. Are there any games/test programs that demonstrate how these screen transitions work?
Avatar is pixel art of Noah Prime from Astral Chain
Re: MMC5 extended RAM and fill mode
The RAM used for nametable expansion is not part of PRG RAM - it is internal to the MMC5 chip itself, since it needs to be dual-port (i.e. writable from the CPU bus and readable from the PPU bus). In fact, one of the modes allows it to be used as general-purpose RAM mapped at $5C00-$5FFF in addition to whatever PRG RAM is available (and mapped anywhere within $6000-$DFFF).SusiKette wrote: ↑Sat Dec 05, 2020 10:58 am According to the wiki MMC5 has the PRG RAM at $6000-$7FFF. When you are using the extended RAM modes 0 or 1, what parts of the PRG RAM are used for these features? Mode 1 can also be used as a extended nametable. How does this work with the additional attribute data used in that mode? The wiki mentions that the fill mode can be used for screen transitions. Are there any games/test programs that demonstrate how these screen transitions work?
As for fill mode, I believe the game "Laser Invasion" uses it during takeoff/landing.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: MMC5 extended RAM and fill mode
The wiki also mentio s that the expansion RAM can only be written while PPU is rendering. Is this right? And does this mean rendering as in rendering begin enabled from PPU registers or while a frame is begin rendered?
Avatar is pixel art of Noah Prime from Astral Chain
Re: MMC5 extended RAM and fill mode
This rendering thing is weird as hell... I always wondered if this information was correct myself, because it makes zero sense.
Re: MMC5 extended RAM and fill mode
I haven't tested this, but it does make sense.
In order to know when it's safe to write to the extended RAM, it needs to know that there's enough time to complete a write. The only way it can know this is when the PPU is doing its normal fetch cadence: after each rising edge of PPU /RD, it knows there's guaranteed to be at least 180ns before the next falling edge of PPU /RD.
Also, you could switch the mode using $5104 during vblank as long as you switch it back before rendering starts.
In order to know when it's safe to write to the extended RAM, it needs to know that there's enough time to complete a write. The only way it can know this is when the PPU is doing its normal fetch cadence: after each rising edge of PPU /RD, it knows there's guaranteed to be at least 180ns before the next falling edge of PPU /RD.
Also, you could switch the mode using $5104 during vblank as long as you switch it back before rendering starts.
Re: MMC5 extended RAM and fill mode
According to my memories, if it is written during VBlank a #$00 is written instead of the desired value. I'm unsure about forced VBlank... be sure to never trust emulators for this kind of thing.
Useless, lumbering half-wits don't scare us.
Re: MMC5 extended RAM and fill mode
Does writing to MMC5 5c00-5FFF memory space have any limitations or is it directly accessible? For example: when I set the $5104 register as "extended attribute data" and tried to copy anything there, under some emulators, eg MESEN, the copied data was invisible at $5C00-5FFF. Only when BEFORE copying I set $5104 as "ordinary RAM" - the copying is done. Is exRAM in "extended attribute data" mode somehow write-protected?
Re: MMC5 extended RAM and fill mode
Presumably connecting it to the PPU means it can only be accessed during vblank.
Re: MMC5 extended RAM and fill mode
It makes sense.
I make changes to exRAM like this - I don't know if it's correct (?), but it works: I set $5104 to 10 (ord. RAM) -> changes to exRAM -> set $5104 to 01 (ext attr table) again.
I make changes to exRAM like this - I don't know if it's correct (?), but it works: I set $5104 to 10 (ord. RAM) -> changes to exRAM -> set $5104 to 01 (ext attr table) again.
Re: MMC5 extended RAM and fill mode
In fact, writing $5c00 - $5fff, then switching exram mode and using it as 3rd NT is no better than directly plug-in a 1KB cxram. Because writing $2006 and $2007 is faster than writing $5xxx, the former address is automatically accumulated. In this usage of dual port RAM, the CPU only writes and the PPU only read, so it is meaningless. It is more stupid than using cxram directly.
I strongly oppose such usage. The recommended usage is to directly set exram to extra NT, and then operate $2006 and $2007 to write
I strongly oppose such usage. The recommended usage is to directly set exram to extra NT, and then operate $2006 and $2007 to write
Re: MMC5 extended RAM and fill mode
So there is no difference whether extended attribute data or extra nametable - it is best to write to this memory through PPU registers?
I tried to use the extended attribute, I wrote a test demo:
I tried to use the extended attribute, I wrote a test demo:
- Attachments
-
- mmc5extendedattributebyte.nes
- (264.02 KiB) Downloaded 43 times
- Jarhmander
- Formerly ~J-@D!~
- Posts: 569
- Joined: Sun Mar 12, 2006 12:36 am
- Location: Rive nord de Montréal
Re: MMC5 extended RAM and fill mode
Well, better it depends... The point aquasnake's made is that writing to exRAM via PPU registers may be faster because of the address auto-increment, but that point is valid for sequential accesses that occurs in VBlank. Outside of (forced) VBlank and for random access, direct access to the exRAM via CPU space is more convenient and/or faster. For attribute data in exRAM columns are 16 bytes apart so random access from CPU may be faster.
((λ (x) (x x)) (λ (x) (x x)))
Re: MMC5 extended RAM and fill mode
There are several ways to access exram:
$5104 = 2, cpu $5C00-$5FFF, cpu R/W
$5104 = 0, $5105 = 0b1010xxxx, ppu $2800-$2BFF, ppu R/W(when v-split enable bit is not set)
or ppu R only at v-split rendering(if v-split enable bit is set)
$5104 = 1, ppu R only at attribute table rendering
Therefore, generally switch to the CPU port and write $5c00 - $5fff.
However, another way is to switch to the PPU port and access the third NT, but exram can not be written in other modes, and the readout is also limited by the time slice (the hardware reads out automatically at a specific time in the in-frame period, meanwhile the software cannot control it)
$5104 = 2, cpu $5C00-$5FFF, cpu R/W
$5104 = 0, $5105 = 0b1010xxxx, ppu $2800-$2BFF, ppu R/W(when v-split enable bit is not set)
or ppu R only at v-split rendering(if v-split enable bit is set)
$5104 = 1, ppu R only at attribute table rendering
Therefore, generally switch to the CPU port and write $5c00 - $5fff.
However, another way is to switch to the PPU port and access the third NT, but exram can not be written in other modes, and the readout is also limited by the time slice (the hardware reads out automatically at a specific time in the in-frame period, meanwhile the software cannot control it)
Re: MMC5 extended RAM and fill mode
Writing in vblank time is not a problem, depending on the ram size. Of course, I wrote more space in vblank ever, such as cxram. It is roughly estimated that 128KB can be written in a secondJarhmander wrote: ↑Wed Dec 29, 2021 9:30 pm Well, better it depends... The point aquasnake's made is that writing to exRAM via PPU registers may be faster because of the address auto-increment, but that point is valid for sequential accesses that occurs in VBlank. Outside of (forced) VBlank and for random access, direct access to the exRAM via CPU space is more convenient and/or faster. For attribute data in exRAM columns are 16 bytes apart so random access from CPU may be faster.
Chr data, whether nt or pattern, are all in sequence and static
Moreover, the 3rd NT is only 1KB, and the loss of write occupied scanline time is negligible