OAM/DMC DMA tests

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Drag
Posts: 1308
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: OAM/DMC DMA tests

Post by Drag » Sun Apr 24, 2016 8:43 pm

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!

fred
Posts: 64
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: OAM/DMC DMA tests

Post by fred » Mon Apr 25, 2016 1:52 am

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?

User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Re: OAM/DMC DMA tests

Post by cpow » Mon Apr 25, 2016 6:48 am

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!

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: OAM/DMC DMA tests

Post by thefox » Mon Apr 25, 2016 7:20 am

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: fo.aspekt.fi

User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Re: OAM/DMC DMA tests

Post by cpow » Mon Apr 25, 2016 7:38 am

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..

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Re: OAM/DMC DMA tests

Post by Disch » Mon Apr 25, 2016 8:34 am

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

User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Re: OAM/DMC DMA tests

Post by cpow » Mon Apr 25, 2016 9:04 am

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: Select all

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: Select all

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.

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Re: OAM/DMC DMA tests

Post by Disch » Mon Apr 25, 2016 9:23 am

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.

User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Re: OAM/DMC DMA tests

Post by cpow » Mon Apr 25, 2016 9:52 am

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.

Alyosha_TAS
Posts: 102
Joined: Wed Jun 15, 2016 11:49 am

Re: OAM/DMC DMA tests

Post by Alyosha_TAS » Tue Jun 28, 2016 5:27 pm

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:
; 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: Select all

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.

Post Reply