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

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

Post Reply
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

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

Post by Myask »

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
How Mednafen handles it.
How Mednafen handles it.
DMAMess-screenshot.png (8.28 KiB) Viewed 6765 times
DMAmess.nes.gz
(1.9 KiB) Downloaded 241 times
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

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.
(emphasis mine). You "should" get garbage on the scanlines during which writes happen, and otherwise nothing else visible.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

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

Post by Myask »

:oops: Thanks.
Searched, looked at OAMDMA, and it's under OAMDATA. Argh.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

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

Post by Bregalad »

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".
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

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

Post by Myask »

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.
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

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

Post by mikejmoffitt »

I can test this out a little later today, if you'd like. I'll come back with some results.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

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.
psc
Posts: 41
Joined: Tue Dec 11, 2012 1:02 pm

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

Post by psc »

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.
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

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

Post by mikejmoffitt »

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.
psc
Posts: 41
Joined: Tue Dec 11, 2012 1:02 pm

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

Post by psc »

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.
Four lines of glitchy effects, rendered with palette colors?
I recall them being black/white, but I could re-check this with different palettes.
Post Reply