nesdev.com

So, I began implementing scrolling to replace just simply showing a nametable with sprites on it. After awhile, donkey kong continues to run and a lot of test roms continue to function, but now some test roms and mario flash and then blank out.

So, for example, blaarg's test roms, for example on testing vblank (01-vbl_basics), I will see the text flash momentarily and then blank out. I can see that the nametable has the valid data. And looking at $6000 shows that the test passed. But nothing is showing on screen. Again, donkey kong runs, other single screen roms like balloon fight run. But these test roms and mario simply do not.

In the source code for 01-vbl_basics, I see blaarg's code do this:

lda #0 ; BG off
sta $2001

Which indeed would turn off background rendering. However, nothing I see in the code turns it back on again. Am I missing some other operation triggering background rendering again?

Thanks for any thoughts! Boggling me.

Did you really sift through all the code? Somehow I doubt it. :-) The code in question is abstracted and split up across several files with tons upon tosn of .include statements, making it difficult to follow linearly or "grep for things" throughout the source. You literally cannot look at just one .s file. Odds are one of the other code shims located in source/common is re-enabling it. There is a global equate of PPUMASK = $2001 and PPUMASK is indeed touched throughout several helper functions, but as I said, there's so much abstraction that it cannot be quickly followed through source review.

A better approach would be to assemble 01-vbl_basics.s yourself -- see source/readme.txt for how to do that -- then disassemble the resulting ROM and see what happens from the RESET vector onwards. If the screen never gets turned back on to display the results of post-BG-disable tests (there are two) then it could be an oversight of some kind, or a bug in your emulator (likely hence your question). There are several calls that tweak PPUMASK with console.s, but whether that code is called is dependent upon aforementioned mess, ditto with some compile-time conditionals.

Thus: I would suggest reading (not skimming) the readme.txt in the root directory, specifically sections "Alternate output" and "Output at $6000". The information there combined with whatever debug capability you have in your emulator should suffice for determining the state of things. This readme has a minor typo: memory location $6003 will contain $61 not $G1 (there is no "G" in base 16; the 3 hex values are supposed to represent the cute string "DEBUG1").

There's nothing magical like that in the NES. You can set a breakpoint in your emulator's PPU register write handler to see where it's turning background rendering back on. (And if it's not, you can use a verified working emulator like FCEUX or Nintendulator to find out where it should happen.)

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi