So I started looking into the weirdness in the status bar in Mickey Mouse Safari in Letterland and I discovered my problem.
The game is causing an A12 rising edge via a $2006 write which is borking the status bar:
In my past dealings I have employed two methods of handling CPU triggered A12 rises on $2006 writes. The first (and simplest) was to compare the new PPU addr to the old one and see if bit 12 changed. In this scenario... this method, in effect, compares the new A12 with the least significant bit of vertical scroll (since that is what occupies bit 12 of the PPU address during rendering). This is why the bottom half of the status bar appears to shake depending where the screen is scrolled to vertically.
My newer method is a bit more on point. On the second $2006 write (as well as on $2007 reads and writes) I update a 'ppubus' variable and use this to compare to compare on future writes. I also update this ppubus var when I run my PPU so that it reflects the last fetch the PPU makes.
When employing my new method -- the status bar does not shake! However, the IRQ is occuring 1 scanline too soon. This is apparently because the last fetch made before the PPU was shut off set A12 to be low (either a NT fetch, or a lefthand pattern fetch)... and thus the following $2006 writes will cause a rising edge every time.
Some thoughts of potential solutions that have jumped in my mind are:
- turning off the PPU has some unforseen effect on the address bus (unlikely -- since the only way this would prevent $2006 from causing a rise would be if turning the PPU off caused a rise -- and that would just push the rise forward, not really solving the problem).
- since the address in this case is pointing to a palette range ($3Fxx) it somehow isn't updating the PPU address bus (though I don't see how this would be possible), or the MMC3 just can't see the address bus in this case???
- the status bar is simply fugly in this game -- though I *really* doubt this is the case because the letters you collect are illegible (ICE looks like TCF due to the bottom line being clipped) -- and for a "learn how to read" game, you think they would have spotted that.
I know all these situations are unlikely, but I figured I'd post this anyway in case anyone has any insight. For a long time I figured this was an IRQ timing issue -- but apparently it isn't.
Thoughts / ideas / suggestions / anything welcome and appreciated ^^
The game is causing an A12 rising edge via a $2006 write which is borking the status bar:
Code:
; ROM offset 0x1CBE9
LDY #$3F
LDA #$10
STX $2001 ; X=0 at this point -- turns PPU off
LDX #$0F
STY $2006
STA $2006 ; set Address to $3F10 (potential for rising edge)
STX $2007 ; change palette
LDY #$3F
LDA #$10
STX $2001 ; X=0 at this point -- turns PPU off
LDX #$0F
STY $2006
STA $2006 ; set Address to $3F10 (potential for rising edge)
STX $2007 ; change palette
In my past dealings I have employed two methods of handling CPU triggered A12 rises on $2006 writes. The first (and simplest) was to compare the new PPU addr to the old one and see if bit 12 changed. In this scenario... this method, in effect, compares the new A12 with the least significant bit of vertical scroll (since that is what occupies bit 12 of the PPU address during rendering). This is why the bottom half of the status bar appears to shake depending where the screen is scrolled to vertically.
My newer method is a bit more on point. On the second $2006 write (as well as on $2007 reads and writes) I update a 'ppubus' variable and use this to compare to compare on future writes. I also update this ppubus var when I run my PPU so that it reflects the last fetch the PPU makes.
When employing my new method -- the status bar does not shake! However, the IRQ is occuring 1 scanline too soon. This is apparently because the last fetch made before the PPU was shut off set A12 to be low (either a NT fetch, or a lefthand pattern fetch)... and thus the following $2006 writes will cause a rising edge every time.
Some thoughts of potential solutions that have jumped in my mind are:
- turning off the PPU has some unforseen effect on the address bus (unlikely -- since the only way this would prevent $2006 from causing a rise would be if turning the PPU off caused a rise -- and that would just push the rise forward, not really solving the problem).
- since the address in this case is pointing to a palette range ($3Fxx) it somehow isn't updating the PPU address bus (though I don't see how this would be possible), or the MMC3 just can't see the address bus in this case???
- the status bar is simply fugly in this game -- though I *really* doubt this is the case because the letters you collect are illegible (ICE looks like TCF due to the bottom line being clipped) -- and for a "learn how to read" game, you think they would have spotted that.
I know all these situations are unlikely, but I figured I'd post this anyway in case anyone has any insight. For a long time I figured this was an IRQ timing issue -- but apparently it isn't.
Thoughts / ideas / suggestions / anything welcome and appreciated ^^