Mid-frame OAMDMA "Bad Things"...are what?
Moderator: Moderators
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.
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.
- Attachments
-
- How Mednafen handles it.
- DMAMess-screenshot.png (8.28 KiB) Viewed 6765 times
-
- DMAmess.nes.gz
- (1.9 KiB) Downloaded 241 times
Re: Mid-frame OAMDMA "Bad Things"...are what?
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.Myask wrote: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.
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.
Re: Mid-frame OAMDMA "Bad Things"...are what?
(emphasis mine). You "should" get garbage on the scanlines during which writes happen, and otherwise nothing else visible.Ulfalizer's contribution to nesdevwiki:PPU registers#OAMDATA wrote: Writes to OAMDATA during rendering (on the pre-render line and the visible lines 0-239, provided either sprite or background rendering is enabled) do not modify values in OAM, but do perform a glitchy increment of OAMADDR, bumping only the high 6 bits (i.e., it bumps the [n] value in PPU sprite evaluation - it's plausible that it could bump the low bits instead depending on the current status of sprite evaluation). This extends to DMA transfers via OAMDMA, since that uses writes to $2004. For emulation purposes, it is probably best to completely ignore writes during rendering.
Re: Mid-frame OAMDMA "Bad Things"...are what?
Thanks.
Searched, looked at OAMDMA, and it's under OAMDATA. Argh.
Searched, looked at OAMDMA, and it's under OAMDATA. Argh.
Re: Mid-frame OAMDMA "Bad Things"...are what?
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".Myask wrote:I read you're not supposed to OAMDMA with rendering on, or Bad Things™ happen.
Re: Mid-frame OAMDMA "Bad Things"...are what?
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.
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: Mid-frame OAMDMA "Bad Things"...are what?
I can test this out a little later today, if you'd like. I'll come back with some results.
Re: Mid-frame OAMDMA "Bad Things"...are what?
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.
Re: Mid-frame OAMDMA "Bad Things"...are what?
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.
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.
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: Mid-frame OAMDMA "Bad Things"...are what?
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?psc wrote: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.
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.
Re: Mid-frame OAMDMA "Bad Things"...are what?
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.If $0D looks darker than $0F, then your TV set is not tuned correctly.
I recall them being black/white, but I could re-check this with different palettes.Four lines of glitchy effects, rendered with palette colors?