It is currently Thu Dec 14, 2017 11:44 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sat Apr 23, 2016 5:57 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Rahsennor wrote:
fred wrote:
Isn't it easier to say that a DMA (and only one DMA) starts after an instruction finishes? Did I miss something here or is it referring to something else?

The DMA starts after the writes finish. The DMA unit has no knowledge of where instructions start and end. It can only watch the bus to see if the CPU is writing or reading, and it can only pause the CPU after a read, so it always waits for a single read to complete before it starts. The result of that read is then discarded, turning it into a dummy read.


Almost. From previous posts, the DMA won't start before the next CPU read. As I said, it doesn't trigger in the 1st write because the following cycle is the operation + another write to $4014. So, the opcode fetch (instruction read) triggers the DMA.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sat Apr 23, 2016 6:04 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 297
That's what I just said. One read, then the DMA.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sat Apr 23, 2016 8:11 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Here is the ambiguous part:
Quote:
The DMA starts after the writes finish.

It's after the second write and on the next CPU read. Just to be crystal clear, sorry.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sat Apr 23, 2016 8:39 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
I like examples!

Code:
        This code:
INC $4014
NOP

        Yields these cycles
       
read:   'INC' opcode
read:   #$14
read:   #$40
read:   $4014
write:  $4014           <- trigger
write:  $4014           <- DMA attempts to halt, can't because it's a write
read:   'NOP' opcode    <- DMA attempts to halt, success!  This becomes a dummy read
  -rd:  'NOP' opcode    <- 'alignment' dummy read **ONLY IF** DMA unit is on a 'put' cycle
read:   $xx00           <- DMA starts here .. this is a DMA read
write:  $2004           <- DMA write
...


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sat Apr 23, 2016 9:06 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 297
Zepper wrote:
Here is the ambiguous part:

fred asked if the DMA occured after the instruction finishes. That's true, but misleading; it's the write cycles the DMA is actually waiting on. That's what the statement you just quoted was addressing.

The rest of my post explained exactly the same thing you just felt the need to correct, twice, although my choice of words was admittedly very poor. I do that a lot, and from what I gather English isn't your first language, so the miscommunication is understandable. I'll shut up now.

This is why I don't help people. :roll:


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sat Apr 23, 2016 9:19 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Ah.

In that case, it's worth nothing that on BRK/interrupt, the writes are NOT the end of the instruction. That is why the distinction is important. While a $4014 write can't happen during an interrupt, a DMC fetch certainly can.

More examples!

Code:
        This code:
BRK

        Can yield these cycles, assuming DMC wants to fetch on the indicated cycle:
       
read:   'BRK' opcode
read:   byte following opcode
write:  $01xx push PCH      <- DMC DMA tries to halt here, fails
write:  $01xx push PCL      <- tries to halt here, fails
write:  $01xx push status   <- tries to halt here, fails
read:   $FFFE               <- tries to halt here, success -- this is a dummy read
read:   $FFFE               <- another dummy read for DMC
--rd:   $FFFE               <- 'alignment' dummy read only if DMA unit is on a put cycle
read:   $xxxx               <- DMC DMA fetch
read:   $FFFE               <- normal BRK read
read:   $FFFF


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 1:22 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
Is it only the halting read cycle that shows up outside the 6502? Do the DMA's dummy reads not cause actual pin activity?


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 1:30 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
There shouldn't be any functional difference between dummy reads and normal reads.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 2:45 am 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 43
Location: Sweden
Quote:
That's true, but misleading; it's the write cycles the DMA is actually waiting on.

Oh, I see! I just assumed it worked similarly to interrupts. Thanks for explaining it.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 10:59 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
If the CPU is interrupted during a $4016 read, it was only a single bit deletion. Is that information incorrect or is there another explanation for it? Would this also mean that an interrupted $2007 read triggers up to three extra PPU address increments?


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 11:11 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
the wiki wrote:
For the controller registers, this can cause an extra rising clock edge to occur, and thus shift an extra bit out. For the others, the PPU will see multiple reads, which will cause extra increments of the address latches, or clear the vblank flag.


Sounds like controller ports only process 1 extra read, but the PPU processes all of them. That suggests multiple reads do in fact take place, but 4016/7 process them in a way where some of them get ignored. Maybe they ignore successive reads similar to how MMC1 ignores successive writes?


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 11:18 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6526
Location: Seattle
Disch wrote:
Sounds like controller ports only process 1 extra read, but the PPU processes all of them. That suggests multiple reads do in fact take place, but 4016/7 process them in a way where some of them get ignored. Maybe they ignore successive reads similar to how MMC1 ignores successive writes?
$4016 and $4017 have no special logic to that effect. If you're seeing different behavior between $2007 and $4016, there's got to be something else going on.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 12:07 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
Knowing the logic involved in generating the CLK pulse sent to the controller ports would help. /OE1 and /OE2 might be involved, though it's hard to imagine that the DMA disconnects those (seemingly unrelated) signals as well. The wiki could also be wrong, and we might be misremembering the effects of the conflict.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 12:11 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6526
Location: Seattle
The clock pulse is exactly

NOT(A15…A0 = h'4016' AND M2 = 1 AND R/W = 1)

You can trace it in visual2a03, it's called "r4016"


Last edited by lidnariq on Sun Apr 24, 2016 4:54 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 2:44 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
If a $4016 read is triggered on r4016 going low, then it would ignore successive reads because r4016 stays low for the entire duration (it does not toggle with phi2):


http://www.qmtpro.com/~nes/chipimages/v ... 4010fe30fe
Code:

cyc      ab  db rw               pc   a  x  y  s    p          r4016
=======================================================================
1398    0084 ad 1 LDA&nbsp;Abs  0084 00 a2 00 bd Nv&#8209BdIzc   1      <- LDA $4016
1399    0084 ad 1 LDA&nbsp;Abs  0084 00 a2 00 bd Nv&#8209BdIzc   1
1399    0085 16 1               0085 00 a2 00 bd Nv&#8209BdIzc   1
1400    0085 16 1               0085 00 a2 00 bd Nv&#8209BdIzc   1
1400    0086 40 1               0086 00 a2 00 bd Nv&#8209BdIzc   1
1401    0086 40 1               0086 00 a2 00 bd Nv&#8209BdIzc   1
1401    4016 00 1               0087 00 a2 00 bd Nv&#8209BdIzc   0      <- DMA halt
1402    4016 00 1               0087 00 a2 00 bd Nv&#8209BdIzc   0
1402    4016 00 1               0087 00 a2 00 bd nv&#8209BdIZc   0
1403    4016 00 1               0087 00 a2 00 bd nv&#8209BdIZc   0
1403    4016 00 1               0087 00 a2 00 bd nv&#8209BdIZc   0
1404    4016 00 1               0087 00 a2 00 bd nv&#8209BdIZc   0
1404    c001 00 1               0087 00 a2 00 bd nv&#8209BdIZc   1      <- actual DMA read
1405    c001 00 1               0087 00 a2 00 bd nv&#8209BdIZc   1
1405    4016 00 1               0087 00 a2 00 bd nv&#8209BdIZc   0      <- proper 4016 read
1406    4016 00 1               0087 00 a2 00 bd nv&#8209BdIZc   0
1406    0087 10 1 BPL&nbsp;     0087 00 a2 00 bd nv&#8209BdIZc   1      <- next instruction


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

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