MMC5 extended RAM and fill mode

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
User avatar
SusiKette
Posts: 147
Joined: Fri Mar 16, 2018 1:52 pm
Location: Finland

MMC5 extended RAM and fill mode

Post by SusiKette »

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
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: MMC5 extended RAM and fill mode

Post by Quietust »

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?
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).

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.
User avatar
SusiKette
Posts: 147
Joined: Fri Mar 16, 2018 1:52 pm
Location: Finland

Re: MMC5 extended RAM and fill mode

Post by SusiKette »

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

Re: MMC5 extended RAM and fill mode

Post by tokumaru »

This rendering thing is weird as hell... I always wondered if this information was correct myself, because it makes zero sense.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 extended RAM and fill mode

Post by lidnariq »

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.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: MMC5 extended RAM and fill mode

Post by Bregalad »

SusiKette wrote: Sun Dec 06, 2020 9:36 am 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?
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.
sdm
Posts: 412
Joined: Tue Apr 11, 2006 4:08 am
Location: Poland

Re: MMC5 extended RAM and fill mode

Post by sdm »

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?
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: MMC5 extended RAM and fill mode

Post by calima »

Presumably connecting it to the PPU means it can only be accessed during vblank.
sdm
Posts: 412
Joined: Tue Apr 11, 2006 4:08 am
Location: Poland

Re: MMC5 extended RAM and fill mode

Post by sdm »

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.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: MMC5 extended RAM and fill mode

Post by aquasnake »

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
sdm
Posts: 412
Joined: Tue Apr 11, 2006 4:08 am
Location: Poland

Re: MMC5 extended RAM and fill mode

Post by sdm »

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:
Attachments
extattr.jpg
mmc5extendedattributebyte.nes
(264.02 KiB) Downloaded 43 times
User avatar
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

Post by Jarhmander »

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)))
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: MMC5 extended RAM and fill mode

Post by aquasnake »

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)
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: MMC5 extended RAM and fill mode

Post by aquasnake »

Jarhmander 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.
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 second

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
Post Reply