It is currently Thu Dec 14, 2017 6:27 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Wed May 21, 2008 8:35 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
If the loop wrote to $2007 every 13 clocks, then a DMC DMA read occurring somewhere during the loop would have a 1 in 13 chance of affecting it. If there are multiple DMA reads during the loop, then you have to do some math to find out what happens. If for example they are every 432 clocks, you must first subtract 4, since each DMA steals 4 CPU clocks normally. So every 428 non-wait-state CPU clocks the DMA will occur. 428/13 = 32 with a remainder of 12. So each time it will occur 12 clocks later than the last, or 1 clock earlier. So it would be sure to hit the critical clock after 13 iterations. Then when it hits, the DMA takes one clock less, so it would jump back an extra clock that time, resulting in it occurring every 12 iterations, or every 5184 CPU clocks. I guess I should write an actual test of this, which writes lots of data to VRAM, then verifies how often there is a glitch.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 21, 2008 9:25 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Argh, I'm being extremely sloppy today for some reason. This issue is ONLY affecting reads, not writes. $2007 READ at the critical moment results in 2-3 extra reads; $2007 write is not affected at all. So it seems this bug only impacts code which reads from hardware where the read itself has side-effects. That means PPUSTATUS ($2002), PPUDATA ($2007), SNDCHN ($4015), JOY1 ($4016), and JOY2 ($4017).

Tests with hopefully correct conclusion comments at the top of the source files:

dmc_dma_during_read4.zip

Here's bunnyboy's scope trace for when a $2007 read is affected. The first is unaffected, the second the two different effects. The center waveform of each is the PPU's /RD line to VRAM, NOT the /RD line from the 2A03. The $4016 trace is because we were using a $4016 read to trigger the scope's capture; it had no effect on the test.

Image


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 22, 2008 4:50 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
By the time NES games started using DPCM to the fullest, they no longer had the PRG size limitations that required the NROM/CNROM typical method of stuffing data in CHR and reading it back. I guess that's why we never noticed this until now.


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 22, 2008 8:02 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
But reading $2007 can proof extrememly usefull for example to modify attributes even if you don't have to worry about memory contraints.

Also, I've seen "modern" MMC3 games read stuff from CHRROMs, like Tiny Toons Adventures 2, Earthbound proto or Batman - Return of the Jokey (okay it's not MMC3, but it's "modern" and uses DPCM).

Hey, I think that this glitches explain a few things about why does some games use DPCM only under some circonstances. For instance, Fire Emblem uses DPCM on title screen, enemy phase music and during battle, and for all those time no accurate joypad reading is required. During player phase, DPCM is never used, and so joypad reading is accurate.

EDIT : My theory on Fire Emblem above doesn't make sense as sometimes an alternate player phase music with DPCM plays, and input is requesed on stage start where music with DPCM plays.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 10, 2010 7:41 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
blargg wrote:
Tests with hopefully correct conclusion comments at the top of the source files:

dmc_dma_during_read4.zip



Has this test moved somewhere else? Is it still available?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 10, 2010 8:09 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Ripway closed my old site for some reason, but I have everything that was on it. Here it is on the new, stable parodius site: dmc_dma_during_read4.zip


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 10, 2010 8:53 pm 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
blargg wrote:
Ripway closed my old site for some reason, but I have everything that was on it. Here it is on the new, stable parodius site: dmc_dma_during_read4.zip


Ok I pass dma_2007_read.nes, dma_2007_write.nes, and read_write_2007.nes. But, I can't seem to get dma_4016_read.nes to give me any output. Tracing with my emulator set for a breakpoint on $4016 being anything other than $40 when read by the CPU never triggers. I have tried all of the joypad 1 buttons...confused. I can see it stuck in a loop looking to count how many reads of $4016 happen before it gets a 1. It never gets a 1. If I'm thinking straight, lda $4016 shouldn't cause a dummy read that could be throwing the 1 away. I guess I'll next need to check that the joypad read triggering works, but it looks fairly straightforward in the test ROM code, and I *know* joypad read triggering works; I can play plenty of games...

Off to implement the joypad inspector. 8)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 10, 2010 9:09 pm 
Offline

Joined: Sun Sep 19, 2004 11:07 pm
Posts: 154
Are you remembering to have your joypad emulation code switch to producing all 1's after the shift register empties?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 11, 2010 5:57 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
ReaperSMS wrote:
Are you remembering to have your joypad emulation code switch to producing all 1's after the shift register empties?


Hmmm. Where is *that* behavior documented? :o Of course that means I'm not...so that will fix it for sure. Thanks!


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 11, 2010 7:05 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
I just summarized this topic on the wiki.


Top
 Profile  
 
PostPosted: Wed Sep 19, 2012 5:12 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
Hi, I've been trying to reproduce the double-read glitch on my PAL NES (manufactured around 1991, with RP2A07A CPU/APU and RP2C07-0 PPU), but somehow I've failed there: The glitch never occurred. Is it possible that the glitch occurs only in older NES console? Or only in NTSC consoles?

What I've tested is: The above "dmc_dma_during_read4.zip" package - but I don't really understand what the program is meant to do - if it says "Failed" does that mean that glitch has occurred - or that the glitch has failed to occur? And, the tests seems to rely on the "delay 3309+33+time-iter" (in the common.inc file), which looks like hardcoded NTSC DMA delay, so I'd guess that the tests won't work on PAL.

Then I've brewed up my own test program (can be downloaded here viewtopic.php?p=99773#p99773 - "pputest.zip"; contains test for the DMC glitch and some other PPU related tests). The test is quite simple: Reading 2007h and 4016h many thousand times, and hoping that the reads will collide with DMC and do produce the glitch. There might be some risk that DMC occurs only in the gaps between the reads; but I've inserted an extra 1-cycle delay in the first half of each test - so timings should "shift" somehow, and it would very bad luck (if not impossible) if the DMC still fits into gaps.

On my PAL NES, the DMC related results are:
Code:
PPU READ WITH DMC      :OK
JOY READ WITH DMC      :OK
PPU READ WITHOUT DMC   :OK
JOY READ WITHOUT DMC   :OK

With "OK" meaning that no glitch has occurred.

Tepples has run the test on a NTSC NES:
Code:
PPU READ WITH DMC      :FAIL    FAIL    FAIL
JOY READ WITH DMC      :OK      OK      OK
PPU READ WITHOUT DMC   :OK      OK      OK
JOY READ WITHOUT DMC   :OK      OK      OK

Here, the "FAIL" in first line means that the PPU read has collided with DMC, and produced the glitch as expected. I don't know why the JOY read in second line passed OK, maybe I've been doing something wrong there, theoretically the 1st+2nd ones should both fail or both pass.

Anyways, there seems to be different behaviour upon DMC reads on my PAL NES and tepples NTSC NES. The difference might be PAL-vs-NTSC related, or old-vs-new APU chip version related. Or it might be because my test program is crap.
Did anybody else ever notice such differences? And are there are other test programs that could be used to verify this?


Top
 Profile  
 
PostPosted: Wed Sep 19, 2012 5:26 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2982
Location: Tampere, Finland
nocash wrote:
be PAL-vs-NTSC related, or old-vs-new APU chip version related. Or it might be because my test program is crap.
Did anybody else ever notice such differences? And are there are other test programs that could be used to verify this?

Yes, others (me included) have verified that PAL NES doesn't have this bug (assuming none of the early ones have other chip revisions...). See viewtopic.php?p=36661#p36661

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


Top
 Profile  
 
PostPosted: Wed Sep 19, 2012 6:48 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
Argh, if I'd have known that before then it'd have saved me some hours. Well, then it's double-checked that the DMC glitch doesn't occur on all APUs :-) Thanks for confirming that!
But it was never fixed for newer NTSC APUs, or was it?
Would be also interesting if it occurred on old PAL APUs.

The CPU/APU itself doesn't have a clear date code, but CIC and logic chips on the mainboard have YYWW (year/week) date codes, so one can assume that the APU chip was manufactured around the same date. My DMC-glitch-free PAL console has date codes 9122, 9125, 9133.


Top
 Profile  
 
PostPosted: Wed Sep 19, 2012 5:22 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Test it on a toploader, if any system would be fixed it'd be a toploader.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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