MMC5 Fill-mode question

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Post Reply
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

MMC5 Fill-mode question

Post by Ben Boldt »

I am wondering something about MMC5's Fill-mode using registers $5105,5106,5107. $5107 is akin to the extended attribute mode, where you can arbitrarily select a palette for each 8x8. However, it is different.

Extended attribute table byte format:

Code: Select all

7  bit  0
---- ----
AACC CCCC
|||| ||||
||++-++++- Select 4 KB CHR bank to use with specified tile
++-------- Select palette to use with specified tile
$5107 format:

Code: Select all

7  bit  0
---- ----
xxxx xxAA
       ||
       ++- Specify attribute bits to use for fill-mode nametable
$5107 apparently uses the bottom 2 bits for the palette instead of the top 2 bits? And it does not specify a CHR bank? That is strange; why not behave just like a normal extended attribute byte?

This brings up another question: which CHR bank does it use? Does it follow any of the bank selection from $5120-$512B or $5130? Or, is $5106 actually the bank# and it grabs always the first tile in the bank or something? The wiki doesn't explain it. Let me know if anyone knows this, or else I may need to figure out how to test it.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Fill-mode question

Post by Ben Boldt »

Another question, kind of related but not really. I remember an MMC5 demo where the point of it was to execute code from the MMC5's internal RAM ($5C00-5FFF). I seem to recall that demo had to work around whether the RAM could be readable to the CPU or not, depending if PPU rendering was in-frame or not. Do I remember that right? Is $5C00-5FFF not readable depending on "in-frame" status? I don't see anything pertaining to this in the wiki.

If true, we definitely should check MMC5A $5800-$5BFF's effect on CL2/SL2 whether it is in-frame or not. My test setup at the time did not have a PPU attached, so it probably would have always thought we were not in-frame. Since krzysiobal's CL2/SL2 bits never worked at $5800, we thought his pins were burned out, but I wonder if our different setups may have had different "in-frame" detection. I think it would be huge if we discover $5800 <-> CL2/SL2 depends on in-frame.


Edit:
No, I don't remember it right. I found the demo was from Quietust: "Executable ExRAM".

https://www.qmtpro.com/~nes/?news=all

The demo executes from ExRAM each VBlank, but not apparently due to ExRAM not being readable outside of VBlank. So never mind that.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: MMC5 Fill-mode question

Post by Quietust »

Ben Boldt wrote: Sat Dec 18, 2021 3:27 pm $5107 apparently uses the bottom 2 bits for the palette instead of the top 2 bits? And it does not specify a CHR bank? That is strange; why not behave just like a normal extended attribute byte?

This brings up another question: which CHR bank does it use? Does it follow any of the bank selection from $5120-$512B or $5130? Or, is $5106 actually the bank# and it grabs always the first tile in the bank or something? The wiki doesn't explain it. Let me know if anyone knows this, or else I may need to figure out how to test it.
Fill Mode isn't a graphics mode - it's a nametable selected by the value you write to $5105, so it uses the exact same CHR banks as all of the other nametables. As its name should imply, it consists of a single tile repeated 960 times (specified by the value written to $5106) all using the exact same attribute bits (specified by the value written to $5107).

This is stated as follows on the wiki:
Fill-mode tile ($5106)

Code: Select all

All eight bits specify the tile number to use for fill-mode nametable
Fill-mode color ($5107)

Code: Select all

7  bit  0
---- ----
xxxx xxAA
       ||
       ++- Specify attribute bits to use for fill-mode nametable

If you were to map it to $2000-$23FF, then writing any value to $5106 would be equivalent to copying that value to $2000-$23BF, and writing to $5107 would be equivalent to mirroring the value to 8 bits (x &= 3; x |= x << 2 | x << 4 | x << 6;) and copying the result to $23C0-$23FF.

Its "intended use" is to provide a "blank screen" nametable (for scrolling another nametable into view) that can be instantly updated at a moment's notice and does not require sacrificing any of the other nametables' contents.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Fill-mode question

Post by Ben Boldt »

Thank you for the explanation Quietust.

Here is my understanding based on what you have said:

There are 16 chunks of 64 tiles that can be banked independently with the 16 corresponding pattern table bank registers $5120-5127. So, if you had a normal nametable (no extended attributes) and a fill mode nametable mapped in $5105, whichever chunk contains your desired fill tile, you would select the bank for that chunk with the corresponding $512x register. But at the same time, your normal nametable would be forced to use that same pattern table bank if wanted to use any of the tiles in that 64-tile chunk. However, using extended attributes would not have this limitation, and in fact $5120-5127 would then only have an effect on the bank of the selected fill mode tile. Is this all correct?

Screen transitions happen at precisely the same time that you are likely to want to swap to different tilesets due to changing scenes. That seems like a pretty obvious limitation to me to be stuck with one of your CHR banks the same through the transition... Maybe I still don't get it but it seems like they should have let you arbitrarily select the bank for the fill mode tile. They let you pick the tile and the attribute/palette, why not the bank? Realistically, though, you probably do have a blank (i.e. totally background/transparent) tile in each bank hopefully at the same spot anyway.

I have to admit that this question comes from a bit convoluted source, just brainstorming, if MMC5 was to contain the ability to do ROM nametables. And assuming that my power analysis a long time ago found all of the registers that are writable and readable. All 4 possibilities for nametable types are accounted for in $5105. There isn't a way to do a 5th type for ROM nametable, so that's the 2nd assumption, would be that one of the existing modes has a special case. Would it be realistic that there would be a special case value for $5106 in fill mode that triggers ROM nametable mode (i.e. 80, ff, etc)? Somehow you would have to tell it where to get the ROM nametable, coming full circle and specifying a CHR bank of size $400 with $5107. A bit convoluted, but that is where I was coming from poking for a CHR bank in $5107...

I am aware that none of that is likely but it is nonetheless interesting to entertain possibilities.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 Fill-mode question

Post by lidnariq »

It's an extra complication. You no longer have to just make a fake nametable - you have to keep track of when the PPU is fetching from that fake nametable and then change the upper address lines of the pattern table fetch accordingly. It's certainly not hard, but it's easy to see why it didn't occur to them to extend this
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Fill-mode question

Post by Ben Boldt »

Boy I was really confused by what you just said lidnariq. I think I figured out what you are saying, and here is were my confusion was.

I had the incorrect understanding how it substituted the fill tile address byte from 5106. I was thinking that the MMC5 was changing the CHR address bus during tile fetches from fill-mode nametables. If that was the case, Why not substitute all of the address lines, which would include the bank? However, it becomes obvious that the MMC5 does not have any possibility to control CHR A3-A9 due to those pins not existing on the MMC5, and the signals connecting directly to the PPU. So I spent more time being confused how it does that, only to realize that the MMC5 is in fact substituting the values in the nametable fetches, which the PPU remembers and then later directly request that particular tile in its tile fetch. Sheesh. Pretty sure you guys were trying to tell me that... Oh well, I understand now.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: MMC5 Fill-mode question

Post by aquasnake »

In fill mode, all tiles are mapped to one location. For hardware implementation, it is necessary to monitor the PPU address, isolate the PPU data bus, and place the latched value on the data lines. Although fill mode simplifies the nametable space and software operation, it increases the hardware complexity.


I don't recommend using this function in homebrew games. If you really want to achieve the effect of fill mode, you can write one screen of nametable data. Although VRAM is wasted, it is very friendly to the universality of hardware
Post Reply