OAM/DMC DMA tests
Moderator: Moderators
Re: OAM/DMC DMA tests
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!
Re: OAM/DMC DMA tests
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?
- cpow
- NESICIDE developer
- Posts: 1097
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
Re: OAM/DMC DMA tests
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!
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!
Re: OAM/DMC DMA tests
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.)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...).
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- cpow
- NESICIDE developer
- Posts: 1097
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
Re: OAM/DMC DMA tests
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...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.)
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..
Re: OAM/DMC DMA tests
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
- cpow
- NESICIDE developer
- Posts: 1097
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
Re: OAM/DMC DMA tests
I've confirmed there are indeed "other bugs" but they are "new bugs" not "always there bugs.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
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‑Bdizc 1
39 c000 00 1 BRK 0018 01 c0 00 bd nv‑Bdizc 0
38 c000 00 1 BRK 0018 01 c0 00 bd nv‑Bdizc 0
38 0017 8d 1 STA Abs 0018 01 c0 00 bd nv‑Bdizc 0
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: OAM/DMC DMA tests
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.
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.
- cpow
- NESICIDE developer
- Posts: 1097
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
Re: OAM/DMC DMA tests
I'm not confident in the simulator given the recent observations. I'll wait until it's "fixed". If ever. Too bad.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.
-
- Posts: 173
- Joined: Wed Jun 15, 2016 11:49 am
Re: OAM/DMC DMA tests
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:
The result is also 3 DMA cycles instead of the normal 4:
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.
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:
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. ); 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)
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‑BdIzc 1
1406 0089 ea 1 0089 1f a2 00 bd nv‑BdIzc 1
1405 0089 ea 1 0089 1f a2 00 bd nv‑BdIzc 1
1405 0088 ea 1 NOP 0088 1f a2 00 bd nv‑BdIzc 1
1404 0088 ea 1 NOP 0088 1f a2 00 bd nv‑BdIzc 1
1404 0088 ea 1 0088 1f a2 00 bd nv‑BdIzc 1
1403 0088 ea 1 0088 1f a2 00 bd nv‑BdIzc 1
1403 c000 00 1 0088 1f a2 00 bd nv‑BdIzc 0
1402 c000 00 1 0088 1f a2 00 bd nv‑BdIzc 0 vvvvv three dead cycles instead of usual 4
1402 0088 ea 1 0088 1f a2 00 bd nv‑BdIzc 0
1401 0088 ea 1 0088 1f a2 00 bd nv‑BdIzc 0
1401 0088 ea 1 0088 1f a2 00 bd nv‑BdIzc 0
1400 0088 ea 1 0088 1f a2 00 bd nv‑BdIzc 1
1400 0087 ea 1 NOP 0087 1f a2 00 bd nv‑BdIzc 1 ^^^^ Dummy read
1399 0087 ea 1 NOP 0087 1f a2 00 bd nv‑BdIzc 1
1399 0087 ea 1 0087 1f a2 00 bd nv‑BdIzc 1
1398 0087 ea 1 0087 1f a2 00 bd nv‑BdIzc 1
1398 0086 ea 1 NOP 0086 1f a2 00 bd nv‑BdIzc 1
1397 0086 ea 1 NOP 0086 1f a2 00 bd nv‑BdIzc 1
1397 4015 1f 0 0086 1f a2 00 bd nv‑BdIzc 1
1396 4015 40 0 0086 1f a2 00 bd nv‑BdIzc 1
1396 0085 40 1 0085 1f a2 00 bd nv‑BdIzc 1
1395 0085 40 1 0085 1f a2 00 bd nv‑BdIzc 1
1395 0084 15 1 0084 1f a2 00 bd nv‑BdIzc 1
1394 0084 15 1 0084 1f a2 00 bd nv‑BdIzc 1
1394 0083 8d 1 STA Abs 0083 1f a2 00 bd nv‑BdIzc 1
1393 0083 8d 1 STA Abs 0083 1f a2 00 bd nv‑BdIzc 1
1393 0083 8d 1 0083 1f a2 00 bd nv‑BdIzc 1
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.