nesdev.com
http://forums.nesdev.com/

Mid-frame OAMDMA "Bad Things"...are what?
http://forums.nesdev.com/viewtopic.php?f=21&t=12850
Page 1 of 1

Author:  Myask [ Thu May 28, 2015 7:47 pm ]
Post subject:  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.

Attachments:
File comment: How Mednafen handles it.
DMAMess-screenshot.png
DMAMess-screenshot.png [ 8.28 KiB | Viewed 2214 times ]
DMAmess.nes.gz [1.9 KiB]
Downloaded 59 times

Author:  tokumaru [ Thu May 28, 2015 8:01 pm ]
Post subject:  Re: Mid-frame OAMDMA "Bad Things"...are what?

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.

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.

Author:  lidnariq [ Thu May 28, 2015 8:08 pm ]
Post subject:  Re: Mid-frame OAMDMA "Bad Things"...are what?

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.
(emphasis mine). You "should" get garbage on the scanlines during which writes happen, and otherwise nothing else visible.

Author:  Myask [ Fri May 29, 2015 2:11 pm ]
Post subject:  Re: Mid-frame OAMDMA "Bad Things"...are what?

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

Author:  Bregalad [ Sat May 30, 2015 7:20 am ]
Post subject:  Re: Mid-frame OAMDMA "Bad Things"...are what?

Myask wrote:
I read you're not supposed to OAMDMA with rendering on, or Bad Things™ happen.

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".

Author:  Myask [ Sun May 31, 2015 12:54 am ]
Post subject:  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.

Author:  mikejmoffitt [ Mon Jun 01, 2015 9:33 am ]
Post subject:  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.

Author:  lidnariq [ Mon Jun 01, 2015 12:30 pm ]
Post subject:  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.

Author:  psc [ Mon Jun 01, 2015 1:57 pm ]
Post subject:  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.

Author:  mikejmoffitt [ Mon Jun 01, 2015 2:46 pm ]
Post subject:  Re: Mid-frame OAMDMA "Bad Things"...are what?

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.


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.

Author:  psc [ Mon Jun 01, 2015 3:00 pm ]
Post subject:  Re: Mid-frame OAMDMA "Bad Things"...are what?

Quote:
If $0D looks darker than $0F, then your TV set is not tuned correctly.


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.

Quote:
Four lines of glitchy effects, rendered with palette colors?

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

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/