It is currently Mon Nov 20, 2017 8:26 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 61 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Tue May 31, 2016 12:25 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19234
Location: NE Indiana, USA (NTSC)
Drag wrote:
The only caveat is that this gives you less time for PPU updates since sprite DMA should ideally be done first thing, followed by all the PPU bus accessing code.

On NTSC NES, where avoiding this glitch actually matters, whether you do OAM DMA before or after VRAM updates doesn't matter so long as it's all done before reenabling rendering.


Top
 Profile  
 
PostPosted: Tue May 31, 2016 12:52 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1392
Drag wrote:
On the other hand, wow, you don't need to reread and compare the controller bytes!

That's especially useful if you're using the SNES Mouse, since you can't reread (it accumulates movement info over the course of a frame, and reading it resets its counters). Similar code could probably be written for the Arkanoid controller (which uses D3/D4 and also does not allow rereading).

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
PostPosted: Tue May 31, 2016 1:14 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10114
Location: Rio de Janeiro - Brazil
Drag wrote:
The only caveat is that this gives you less time for PPU updates since sprite DMA should ideally be done first thing, followed by all the PPU bus accessing code.

Not really. DMA first or VRAM updates first doesn't matter, added up they'd still take the same amount of time either way. And by doing the DMA last you can let the controller code itself spill into the visible frame, no need to deduce that part from the vblank budget.

You do lose a bit of time on PAL, where the DMA must come first, but is that really a problem with a vblank period that long? That would only be a problem in PAL-only games (that can't possibly be converted to NTSC), something I don't think people should be making.


Top
 Profile  
 
PostPosted: Tue May 31, 2016 2:25 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
No, you guys are right. :P Sprite DMA being first is only important on PAL machines, where the DMA glitch is fixed. On NTSC machines, sprite DMA can happen after the PPU update routine, and then controller reading can happen immediately afterwards since all the vblank critical stuff is done.

Though I'm going to pout just a little because I came up with that bit-merging method of doing DMA-corrected joypad reading and felt really clever about it, and now it's obsolete. ;)


Top
 Profile  
 
PostPosted: Tue May 31, 2016 2:38 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
tokumaru wrote:
You do lose a bit of time on PAL, where the DMA must come first, but is that really a problem with a vblank period that long? That would only be a problem in PAL-only games (that can't possibly be converted to NTSC), something I don't think people should be making.

PAL-only games wouldn't even be doing this in the first place anyway.


Top
 Profile  
 
PostPosted: Tue May 31, 2016 2:54 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1012
Location: Gothenburg, Sweden
So the only problem is one that can be fixed - incompability with current versions of some emulators?

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue May 31, 2016 3:28 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Maybe we could try quickly modifying an existing game to use this technique to see how feasible it is in practice?


Top
 Profile  
 
PostPosted: Tue May 31, 2016 6:08 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10114
Location: Rio de Janeiro - Brazil
Sik wrote:
PAL-only games wouldn't even be doing this in the first place anyway.

True, you lose no vblank time on PAL either.


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 8:06 pm 
Offline
User avatar

Joined: Wed Oct 16, 2013 7:55 am
Posts: 130
This is a really awesome find. Can't wait to use this in future projects!

Tested on a Powerpak. At first, neither *_even nor *_odd would turn white without pressing right, until I realized I had my Four Score enabled. Disabled it and then *_odd started turning white immediately. Which makes sense.

Question: is it possible from within the ROM to detect whether the host emulator is doing the wrong thing, by reading the controller on odd cycles while turning DMC on and off? If that were the case, the ROM could switch to using a routine compatible with that host's behavior.


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 8:15 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
Drag wrote:
The only caveat is that this gives you less time for PPU updates since sprite DMA should ideally be done first thing, followed by all the PPU bus accessing code. On the other hand, wow, you don't need to reread and compare the controller bytes! That's really spiffy, especially if you need to read more than 8 bits from each port. Nice finding!

So…forgive me if this is obvious, but why not just put the DMA after the PPU updates? Or is that only in PAL?


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 8:49 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19234
Location: NE Indiana, USA (NTSC)
OAM DMA should be done first in PAL because OAM is not writable in lines 261-310.

Recommended pseudocode:
If PAL NES then OAM DMA
Update palettes, nametables, and CHR RAM as needed
If NTSC or Dendy then OAM DMA
Read controller


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 9:47 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 288
dustmop wrote:
Tested on a Powerpak. At first, neither *_even nor *_odd would turn white without pressing right, until I realized I had my Four Score enabled. Disabled it and then *_odd started turning white immediately. Which makes sense.

I was going to add a test to make sure you have the right kind of controller hooked up, but I figured simpler code with clear instructions would be better for this.

If I were to write a test ROM for emulator devs, though, I would definitely trick it out with every possible failure mode. I'll probably get on that when I have time.

dustmop wrote:
Question: is it possible from within the ROM to detect whether the host emulator is doing the wrong thing, by reading the controller on odd cycles while turning DMC on and off? If that were the case, the ROM could switch to using a routine compatible with that host's behavior.

You could, but breaking incorrect emulators is a feature in my book.


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 11:10 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
It only breaks emulators that are already trying to be accurate hard enough to bother implementing the DMC interference in the first place. Most "inaccurate" emulators are already giving you glitch free reads.


Top
 Profile  
 
PostPosted: Wed Jun 08, 2016 1:56 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
What I find amusing is that the broken emulators seem to be actually doing the correct thing, just with the wrong cycle alignment.


Top
 Profile  
 
PostPosted: Wed Jun 08, 2016 5:37 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19234
Location: NE Indiana, USA (NTSC)
Rahsennor wrote:
breaking incorrect emulators is a feature in my book.

It could be, at least until you hear complaints from a user of your game on a platform for which there is no accurate emulator to recommend. For example, which accurate emulator should I recommend to a user of Android?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 61 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: DRW and 7 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