It is currently Sun Dec 17, 2017 12:57 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Sun Apr 24, 2016 8:43 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
I see! I thought the CPU's clock signal was also used for the logic, but considering rams and roms aren't synchronous, they don't need to know the CPU's clock, and same with the controller ports. It makes sense now, thanks!


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Mon Apr 25, 2016 1:52 am 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 43
Location: Sweden
I didn't think about the fact that INC 4014 also reads from 4014, hah. What's the expected return value? Visual2A03 returns whatever was written there last, but is this an "open bus" case?


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Mon Apr 25, 2016 6:48 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
I tested DEC -- and posted about it long ago. Not INC, but similar behavior.

viewtopic.php?f=3&t=9033&hilit=+Visual2A03

The RDY is triggered by the first write but the address given to the DMA engine is based on the second write -- which in INC and DEC case happens to be the "result write". The "dummy write" is the first one because the CPU needs a cycle to do the increment/decrement of A.

However, having said all of that, I just went back through my programs and adjusted the URL to accomodate the new location of the simulator.

Something's changed/BROKEN? The program I used in the above post provides DIFFERENT RESULTS than what I reported back then??

This is the program.

The difference? The original post shows the sprite DMA occurring from the DEC result address ($FF00...). But the new simulator shows the sprite DMA occurring from the DEC dummy address ($0000...).

What? The earlier result didn't confuse me because it made sense. This one confuses me because it doesn't!


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Mon Apr 25, 2016 7:20 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
cpow wrote:
The difference? The original post shows the sprite DMA occurring from the DEC result address ($FF00...). But the new simulator shows the sprite DMA occurring from the DEC dummy address ($0000...).

I think there's a bug that it's forcing the OAM source address to $00. Probably just coincidental that it happens to be the DEC dummy address, would be better to DEC a non-zero value. (I'm not sure if Visual 2A03 is mapping readable RAM under the $4014 address, might be hard to change the value if not.)

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


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Mon Apr 25, 2016 7:38 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
thefox wrote:
I think there's a bug that it's forcing the OAM source address to $00. Probably just coincidental that it happens to be the DEC dummy address, would be better to DEC a non-zero value. (I'm not sure if Visual 2A03 is mapping readable RAM under the $4014 address, might be hard to change the value if not.)

Confirmed with this program that attempts to DEC sprite DMA with A set to $02. Instead of DMAing from $01xx... the simulator DMAs from $00xx...

This is a new bug because clearly the DMAing previously worked as I described in the simulator. With $00 in A the DMAing occurred from $FF..


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Mon Apr 25, 2016 8:34 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
There's other bugs with the OAM DMA, too. If the DMC cuts in during the OAM DMA, it mangles the OAM source address, possibly adding or removing reads. I had one OAM DMA run over 700 cycles because the DMC would interrupt and move the OAM source back like $40 places


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Mon Apr 25, 2016 9:04 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
Disch wrote:
There's other bugs with the OAM DMA, too. If the DMC cuts in during the OAM DMA, it mangles the OAM source address, possibly adding or removing reads. I had one OAM DMA run over 700 cycles because the DMC would interrupt and move the OAM source back like $40 places


I've confirmed there are indeed "other bugs" but they are "new bugs" not "always there bugs.

RE my DMC DMA during Sprite DMA testing, discussed here, the DMC DMA occurs on cycles 40 and 822. In the latest simulator the same program has a DMC DMA at cycle 38, 1404, 1836, and 2268. So it seems the engine skips a couple of cycles but then "rights itself"?!?

Additionally, I noticed that previously the DMA cycles were two half-cycles of the same "clock cycle". In other words, the DMA occurs on both half-cycles of CPU cycle 40. In the new simulation it's like this:

Code:
39   0017   8d   1   STA Abs   0018   01   c0   00   bd   nv&#8209Bdizc   1
39   c000   00   1   BRK   0018   01   c0   00   bd   nv&#8209Bdizc   0
38   c000   00   1   BRK   0018   01   c0   00   bd   nv&#8209Bdizc   0
38   0017   8d   1   STA Abs   0018   01   c0   00   bd   nv&#8209Bdizc   0


The DMC DMA occurs on one half-cycle of CPU cycle 38 and one half-cycle of CPU cycle 39. I'm not sure which way is properly representative of what actually happens, but something VERY strange in that it's now *different*.

Here's what it looked like originally:

Code:
39   0018   14   1      0019   01   c0   00   bd   nv-Bdizc   0
39   0018   14   1      0019   01   c0   00   bd   nv-Bdizc   0
40   c000   00   1      0019   01   c0   00   bd   nv-Bdizc   0
40   c000   00   1      0019   01   c0   00   bd   nv-Bdizc   0
41   0018   14   1      0019   01   c0   00   bd   nv-Bdizc   1
41   0018   14   1      0019   01   c0   00   bd   nv-Bdizc   1


RE the simulator crashing, have you hidden the chip display? It runs much faster when not bothering with that, but still slows down once I get to ~800 cycles. But no crash.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Mon Apr 25, 2016 9:23 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
I got the crashing problem sorted a while ago.

Also it looks like Visual2a03 has had this OAM problem since at least November, as in the thread you linked, thefox mentions he's having the same problem when he tried to reproduce your tests.

Anyway, cpow, were you ever able to test what happens when DMC DMA occurs on the last few cycles of OAM? That's really the last piece of the puzzle as far as I can tell.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Mon Apr 25, 2016 9:52 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1058
Location: Minneapolis, MN
Disch wrote:
Anyway, cpow, were you ever able to test what happens when DMC DMA occurs on the last few cycles of OAM? That's really the last piece of the puzzle as far as I can tell.

I'm not confident in the simulator given the recent observations. I'll wait until it's "fixed". If ever. Too bad.


Top
 Profile  
 
 Post subject: Re: OAM/DMC DMA tests
PostPosted: Tue Jun 28, 2016 5:27 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 65
Hi,

I am working on DMC DMA currently and found this thread immensely helpful, thanks for all the wealth of knowledge.

I do have a question though about something Disch wrote in his dropbox notes in the opening post of this thread:
Quote:
; LDX starts at cycle 8 (after reset)
; $4015 write happens on cycle 23
; first DMA takes 3 cycles @ 26, 27, 28 (ignoring this because
; APU hasn't fully primed yet apparently)


I found this interesting, so I did a test on Visual 2A03. Instead of performing STA $4015 early on, I performed it on cycle 1400 (where the second DMC DMA usually occurs in Disch's code. )

The result is also 3 DMA cycles instead of the normal 4:

Code:
cycle   ab   db   rw   Fetch   pc   a   x   y   s   p   c_rdy
1406   0089   ea   1   NOP   0089   1f   a2   00   bd   nv&#8209BdIzc   1
1406   0089   ea   1      0089   1f   a2   00   bd   nv&#8209BdIzc   1
1405   0089   ea   1      0089   1f   a2   00   bd   nv&#8209BdIzc   1
1405   0088   ea   1   NOP   0088   1f   a2   00   bd   nv&#8209BdIzc   1
1404   0088   ea   1   NOP   0088   1f   a2   00   bd   nv&#8209BdIzc   1
1404   0088   ea   1      0088   1f   a2   00   bd   nv&#8209BdIzc   1
1403   0088   ea   1      0088   1f   a2   00   bd   nv&#8209BdIzc   1
1403   c000   00   1      0088   1f   a2   00   bd   nv&#8209BdIzc   0 
1402   c000   00   1      0088   1f   a2   00   bd   nv&#8209BdIzc   0  vvvvv three dead cycles instead of usual 4
1402   0088   ea   1      0088   1f   a2   00   bd   nv&#8209BdIzc   0
1401   0088   ea   1      0088   1f   a2   00   bd   nv&#8209BdIzc   0
1401   0088   ea   1      0088   1f   a2   00   bd   nv&#8209BdIzc   0
1400   0088   ea   1      0088   1f   a2   00   bd   nv&#8209BdIzc   1
1400   0087   ea   1   NOP   0087   1f   a2   00   bd   nv&#8209BdIzc   1  ^^^^ Dummy read
1399   0087   ea   1   NOP   0087   1f   a2   00   bd   nv&#8209BdIzc   1
1399   0087   ea   1      0087   1f   a2   00   bd   nv&#8209BdIzc   1
1398   0087   ea   1      0087   1f   a2   00   bd   nv&#8209BdIzc   1
1398   0086   ea   1   NOP   0086   1f   a2   00   bd   nv&#8209BdIzc   1
1397   0086   ea   1   NOP   0086   1f   a2   00   bd   nv&#8209BdIzc   1
1397   4015   1f   0      0086   1f   a2   00   bd   nv&#8209BdIzc   1
1396   4015   40   0      0086   1f   a2   00   bd   nv&#8209BdIzc   1
1396   0085   40   1      0085   1f   a2   00   bd   nv&#8209BdIzc   1
1395   0085   40   1      0085   1f   a2   00   bd   nv&#8209BdIzc   1
1395   0084   15   1      0084   1f   a2   00   bd   nv&#8209BdIzc   1
1394   0084   15   1      0084   1f   a2   00   bd   nv&#8209BdIzc   1
1394   0083   8d   1   STA Abs   0083   1f   a2   00   bd   nv&#8209BdIzc   1
1393   0083   8d   1   STA Abs   0083   1f   a2   00   bd   nv&#8209BdIzc   1
1393   0083   8d   1      0083   1f   a2   00   bd   nv&#8209BdIzc   1


Could it be that DMC DMA's are seperately triggered by writes to $4015 and the DMC bits remaining counter reaching zero? The latter seems to take 4 cycles, but does the former take 3?

I also noticed a few cycles between when the write occurs and when the DMA starts, a few NOPs worth actually.

So is this behaviour correct? I am trying to get sprdma_and_dmc_dma test to pass but I cannot for the life of me make it work. I always end up with exactly 1 more cycle happening for each step then I should. I think this is the reason but am not sure how to implement it.

Any more experienced people have any ideas?

Thanks!

EDIT: I implemented this behaviour and now pass sprdma_and_dmc_dma perfectly. I a pretty confident it is correct.


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

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