It is currently Tue Dec 12, 2017 4:55 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 11 posts ] 
Author Message
PostPosted: Thu May 28, 2015 7:47 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
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 2211 times ]
DMAmess.nes.gz [1.9 KiB]
Downloaded 59 times
Top
 Profile  
 
PostPosted: Thu May 28, 2015 8:01 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu May 28, 2015 8:08 pm 
Online

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


Top
 Profile  
 
PostPosted: Fri May 29, 2015 2:11 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
:oops: Thanks.
Searched, looked at OAMDMA, and it's under OAMDATA. Argh.


Top
 Profile  
 
PostPosted: Sat May 30, 2015 7:20 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
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".


Top
 Profile  
 
PostPosted: Sun May 31, 2015 12:54 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
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.


Top
 Profile  
 
PostPosted: Mon Jun 01, 2015 9:33 am 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1311
I can test this out a little later today, if you'd like. I'll come back with some results.


Top
 Profile  
 
PostPosted: Mon Jun 01, 2015 12:30 pm 
Online

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


Top
 Profile  
 
PostPosted: Mon Jun 01, 2015 1:57 pm 
Offline

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


Top
 Profile  
 
PostPosted: Mon Jun 01, 2015 2:46 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Mon Jun 01, 2015 3:00 pm 
Offline

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group