It always bugged my OCD tendencies to have VRC1-4 + VRC6-7 support, so of course I had to add this for the heck of it.
Thanks for the Wiki article, NewRisingSun! I'll try to help out a bit in return: here's an implementation of the VRC5 in C++ code:
https://github.com/byuu/higan/blob/mast ... i-vrc5.cppIt should be nicer than the FCEUX version to read, as FCEU hides a *ton* of details about how the mappers actually work behind FCEU-only abstractions. But maybe my .bit() stuff will confuse people, so YMMV.
Things from the Wiki:
1. "Character Translation Output ($DC00/$DD00, read). Mask: probably $FF00 (ROM data filled with $FF from $D400-DFFF)"
Bank $c000-dfff can be remapped, so it *can* be something other than $FF. I didn't bother to check if the games ever set it to something where $d400-dfff aren't $FF. But, whatever.
It'd probably be nice if we can ask CaH4e3 to please verify the address masks for this mapper.
2. "Character Translation Operation"
I may well have made a mistake, but try as I might, I couldn't get your formula to work and had to use the FCEUX version.
Code:
tile =glyph *4;
ciramByte =(tile &0xFF) | (reg[0xDB00] &3);
qtramByte =(tile >>8) |
// Indicate CHR-ROM
qtramByte |=0x40;
// Indicate alternate attribute
if (reg[0xDB00] &0x04) qtramByte |=0x80;
The third line is cut off. Presuming you want to turn the | into a ; here, which is what I tried. Didn't work.
3. "CHR Banking Operation" -- "The Konami VRC5 ASIC intercepts this process: Whenever the NES PPU fetches a background nametable byte from CIRAM, the VRC5 fetches an additional byte from QTRAM that indicates whether the next CHR pattern data that will be fetched should come from CHR-ROM or CHR-RAM and from which 4 KiB bank."
I always wonder *how* these ASICs do this. I'm aware there's a clear pattern to fetches for each scanline: $2xxx, $23xx, $(0000-1fff), $(0000-1fff) -- repeat 32 times; sprite stuff for a bit; two more tile fetches; some end-of-line stuff.
But let's say a game enables force blanking for a time, how would these ASICs react?
I wasn't in the mood for trying to guess how the VRC5 did this (it was quite a lot of pain with my MMC5 emulation, and is likely wrong there too), so I just made it steal the PPU cycle position to intercept these fetches for now.
Still, it'd be lovely to know for sure, if it could be determined without decapping and destroying priceless carts.
4. "1: Force CHR pattern data to $FF if CHR A3=1, only if CHR-ROM is used (C=1)"
The reason for this is to control the background color behind kanji. On the title and space screens, this isn't done so you get black backgrounds. In the game menus it does this so you get the blue background behind the kanji. Such a weird way of doing things, but ... yeah that's what it's for.