It is currently Fri Mar 24, 2017 12:53 pm

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: Mon May 30, 2016 9:54 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2778
Location: Tampere, Finland
Rahsennor wrote:
Slapped together the simplest test I could come up with, and to my surprise, it works perfectly in Nestopia... but on odd cycles instead of even. None of the other emulators I tested emulate DMC conflicts at all.

Same result in Nintendulator. Definitely should test on real hardware though (I don't have mine hooked up right now).

Just so this is clear to everybody:
- You have to have a standard controller plugged in, and shouldn't press Right.
- If screen stays black => no corruption
- If screen goes white => was corrupted
- (You might want to press Right in the end to force white to make sure that the ROM was properly loaded.)

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Last edited by thefox on Mon May 30, 2016 12:14 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon May 30, 2016 10:26 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1348
Just ran it on my NTSC CopyNES, and the "even" test appears to pass (screen only goes white when I press Right on either controller), while the "odd" test fails (goes white immediately).

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


Top
 Profile  
 
PostPosted: Mon May 30, 2016 10:31 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 17974
Location: NE Indiana, USA (NTSC)
I saw the same results on my NTSC NES + PowerPak: odd started white, and even started black but turned white when I pressed Right.

I will report this finding to the wiki as a way that the mouse (and other controllers that can't just be reread) can possibly be used with DPCM.


Top
 Profile  
 
PostPosted: Mon May 30, 2016 11:18 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5410
Location: Seattle
I just tested on a bare flashcart, and saw the same results as both of the above.


Top
 Profile  
 
PostPosted: Mon May 30, 2016 1:02 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 97
Source code for the ROM that works please. :)
It should be posted on the wiki.

thefox wrote:
Rahsennor wrote:
Slapped together the simplest test I could come up with, and to my surprise, it works perfectly in Nestopia... but on odd cycles instead of even. None of the other emulators I tested emulate DMC conflicts at all.

Same result in Nintendulator.

So if I understand correctly, Nestopia and Nintendulator are handling this behavior incorrectly?


Top
 Profile  
 
PostPosted: Mon May 30, 2016 1:14 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 342
Location: Gothenburg, Sweden
thefox wrote:

Just so this is clear to everybody:
- You have to have a standard controller plugged in, and shouldn't press Right.
- If screen stays black => no corruption
- If screen goes white => was corrupted
- (You might want to press Right in the end to force white to make sure that the ROM was properly loaded.)


oh! in that case, both were black until i pressed right on PAL through powerpak.

tepples wrote:
I will report this finding to the wiki as a way that the mouse (and other controllers that can't just be reread) can possibly be used with DPCM.

Would it be sound to suggest it as an alternative in general, with a list of known benefits/applications following? As to not suggest it is for this only

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


Last edited by FrankenGraphics on Mon May 30, 2016 1:27 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon May 30, 2016 1:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5410
Location: Seattle
The 2A07 CPU in the PAL NES is known to have had the relevant bug fixed, so unfortunately tests on PAL will give you the results you found.


Top
 Profile  
 
PostPosted: Mon May 30, 2016 1:21 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 4899
Location: Canada
Ah, this finally explains how I once accidentally made a DPCM-using ROM that failed to compensate for the glitch, but somehow never had the problem!

I had never understood why the problem never showed up, and it always bothered me; I kept looking through my input logic to find something that would filter out a spurious right press, but couldn't find anything that would explain it. I never thought about OAM DMA vs DPCM even-cycle alignment.


Top
 Profile  
 
PostPosted: Mon May 30, 2016 1:32 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9411
Location: Rio de Janeiro - Brazil
I have to say, this is a very ingenious solution to the dreaded DPCM controller glitch. Definitely better than reading the controller's twice, plus an occasional third time.


Top
 Profile  
 
PostPosted: Mon May 30, 2016 1:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 17974
Location: NE Indiana, USA (NTSC)
pubby wrote:
Source code for the ROM that works please. :)
It should be posted on the wiki.

Is my description any good?


Top
 Profile  
 
PostPosted: Mon May 30, 2016 2:05 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5410
Location: Seattle
The implementation in the NES files is so simple that you can just throw the NES file into da65 to get something correct out.


Top
 Profile  
 
PostPosted: Mon May 30, 2016 5:44 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 230
Okay, here's an updated test with source! Please check that it still works, in case I've done something stupid like post the odd ROM instead of the even one.

The ROM should be run with a standard NES controller in both ports. The expected output is that the screen should remain black until right is pressed on either controller. If it fails, it should do so almost instantly, producing a white screen. PAL NES does not have DPCM conflicts so this test is not meaningful on PAL.

For quick reference, here's the important code:
Code:
   lda #OAM
   sta $4014          ; ------ DMA ------
   ldx #1             ; even odd          <- strobe code must take an odd number of cycles total
   stx controller1    ; even odd even
   stx $4016          ; odd even odd even
   dex                ; odd even
   stx $4016          ; odd even odd even
 read_loop:
   lda $4017          ; odd even odd EVEN <- loop code must take an even number of cycles total
   and #3             ; odd even
   cmp #1             ; odd even
   rol controller2, x ; odd even odd even odd even (X = 0; waste 1 cycle and 0 bytes for alignment)
   lda $4016          ; odd even odd EVEN
   and #3             ; odd even
   cmp #1             ; odd even
   rol controller1    ; odd even odd even odd
   bcc read_loop      ; even odd [even]

Yes, it really is that simple. (Do note that I read the controller bits in big-endian order; most other implementations I've seen use little-endian. Conversion between the two should be a simple exercise.)


Attachments:
dma_sync_test_v2.zip [1.2 KiB]
Downloaded 54 times
Top
 Profile  
 
PostPosted: Mon May 30, 2016 8:27 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2778
Location: Tampere, Finland
pubby wrote:
thefox wrote:
Rahsennor wrote:
Slapped together the simplest test I could come up with, and to my surprise, it works perfectly in Nestopia... but on odd cycles instead of even. None of the other emulators I tested emulate DMC conflicts at all.

Same result in Nintendulator.

So if I understand correctly, Nestopia and Nintendulator are handling this behavior incorrectly?

Yes.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Tue May 31, 2016 8:08 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1348
Previously, Nintendulator didn't implement proper DMC cycle-stealing (it was hardcoded to 4 cycles and didn't care about alignment). It tries to do so now, though I'm pretty sure it isn't 100% correct (specifically for the case of DMC fetch happening one cycle after a $2004 write).

_________________
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 12:00 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1217
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!


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: Yahoo [Bot] 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