edit: skip ahead to my later post, as it turns out there is no GTROM glitch.
rainwarrior wrote:pubby wrote:It causes a glitch on GTROM I think, but not most other mappers.
GTROM has a problem with CHR banking?
I remember Memblers mentioning some problems during prototyping, but is there a problem in the finished board?
Yeah, that was an "interesting" time. I'd highly recommend to anyone, if they're going to order 1000 assembled boards that you
first obtain an oscilloscope. I was so perplexed by the OAM issues (which turned out to be nothing, a bad register setting in the Game Genie) that I kinda glossed over the problem that is in there. I should put it in the main GTROM docs, probably isn't due to a combination of laziness, embarrassment, and that it has a software work-around (for the most common uses at least). Or maybe it's part of a conspiracy to make my boards harder to emulate.
haha
What happens is when you write to the mapper, the latch briefly outputs the high byte of the mapper address, and then the actual data written. For one of the pattern and nametable banks this has no effect, it's just 100% normal. But if using the other bank though, it will screw up the PPU fetch for any cycle you write to the mapper. It doesn't affect CPU banks at all, or the LEDs (theoretically it should dim them very slightly if you wrote to the register a lot, I doubt it's perceptible though).
The work-arounds are only somewhat obnoxious:
1) pattern tables - if you're displaying more than 256 BG tiles it's usually either A) a status bar on top of the screen, or B) a static screen or cutscene. Usually this means for the top portion of the screen, the CPU is waiting for sprite zero and/or running cycle-timed code. During this time you would display the "bad" page, avoid doing any CPU bankswitching (shouldn't be too hard at that point). Then write to the register during hblank. Writing during hblank means that glitch will corrupt sprites on the next line, so can't have sprites on the split point. After you've switched to the "good" page, your program can run as normal.
2) name tables - same as above, or alternately you can use the different $5xxx $7xxx mapper addresses matched up with your nametable bit, and you will always have the "good" page. Glitch is based on the high byte of the address, and the nametable bits happen to line up with those.
It was never supposed to happen, but the nametable glitch actually looks kinda cool sometimes. Would be funny to use it as an effect.