Mid-frame OAMDMA "Bad Things"...are what?

I read you're not supposed to OAMDMA with rendering on, or Bad Things™ happen, but can't find any description of said Bad Things™, and am curious what it looks like.
A bare-bones test NROM-128 is included, which clears OAM at the beginning of VBLANK, waits about half a frame, and then attempts to write a test-pattern of stairstepped rows of 0-7.

I don't have dev hardware to test on; FCEUX and Mednafen appear to act as though this mid-frame change were perfectly normal, and just display no sprites for the top half the frame as expected.

Well, naturally it's not what's displayed BEFORE the DMA that matters, but what's displayed AFTER it. BTW, these emulators are far from being benchmarks of accuracy. If you want better predictions of what the real hardware might do under uncommon situations, try Nintendulator or another emulator that actually simulates the internal logic of the PPU to the letter.

I honestly don't know what to expect visually, but there's no way this will simply work. In the best case scenario you'll get a corrupted OAM, which means garbage sprites until you rewrite the OAM properly, but I guess it could interfere with something else and end up corrupting more than just the OAM.

(emphasis mine). You "should" get garbage on the scanlines during which writes happen, and otherwise nothing else visible.

Thanks.
Searched, looked at OAMDMA, and it's under OAMDATA. Argh.

Where did you read that? I believe Bad Things™ is an ironical and funny word to mean what is more seriously refereed to as "undefined behaviour".

I haven't looked much outside of NesDev for learning about it, so it must have been around here, but I was unable to re-locate it with a forums/wiki search; hence why I asked.

I can test this out a little later today, if you'd like. I'll come back with some results.

We'll want to start with something other than "all empty" in order to be able to see the corruption anyway. Maybe just swap the two tables.

Running DMA mid-frame will produce about 4 lines of glitchy effects. Not exactly useful. I've tested this on an Everdrive cart on the real hardware. Even if you disable sprites and run it, it still visibly glitch (unlike on the GameBoy). Updating DMA mid-frame can be useful, but I'm not sure of a way to do it on the NES without glitches.

If you want to see really "Bad Things", try setting your palette to $0D... gasp. Actually, I HAVE noticed this black to produce a darker black than the regular $0F black on my CRT tv. Looks quite nice... until your TV explodes.

Four lines of glitchy effects, rendered with palette colors? If it's done on an area that is one tile high (8 pixels) could the palette just be quickly written to be all black before the transfer?

If $0D looks darker than $0F, then your TV set is not tuned correctly. $0F should be true black, while $0D should be a signal that the TV would consider "less than black" which will upset the sync circuitry which uses negative voltages for sync information.

How would it be tuned? This is a mid 1980's Sony with contrast, saturation, and brightness. $0F is still black, I'm just saying that on my set $0D makes it even darker, in that there seems to be less glow from surrounding palettes. Probably not noticeable without the lights turned off though.


I recall them being black/white, but I could re-check this with different palettes.