7-dmc_basics (Test 19) on real NES

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
johnmph
Posts: 13
Joined: Fri Feb 28, 2020 8:17 am

7-dmc_basics (Test 19) on real NES

Post by johnmph » Wed Apr 08, 2020 6:10 am

Hello all,

I am working on the APU of my emulator and to complete the informations on NesDev Wiki, I do some tests on Visual2A03.
But there is a test result which is strange (scroll horizontally to see all the log) :

Code: Select all

cycle	ab	db	rw	Fetch	pc	a	x	y	s	p	c_ab	c_db	rdy	pcm_bits	pcm_t	pcm_l	pcm_lc	pcm_en	pcm_on
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
...
2033	0035	2c	1	BIT Abs	0035	10	c0	00	bc	nv-BdIzC	0035	2c	1	3	111	00	000	1	1
2033	0035	2c	1	BIT Abs	0035	10	c0	00	bc	nv-BdIzC	0035	2c	1	3	111	00	000	1	1
2034	0036	15	1	 	0036	10	c0	00	bc	nv-BdIzC	0036	15	1	3	022	00	000	1	1
2034	0036	15	1	 	0036	10	c0	00	bc	nv-BdIzC	0036	15	0	3	022	00	000	1	1
2035	0036	15	1	 	0037	10	c0	00	bc	nv-BdIzC	0036	15	0	3	022	00	000	1	1
2035	0036	15	1	 	0037	10	c0	00	bc	nv-BdIzC	0036	15	0	3	022	00	000	1	1
2036	c000	00	1	 	0037	10	c0	00	bc	nv-BdIzC	0036	00	0	3	044	00	000	1	1	; DMC sample buffer is filled here
2036	c000	00	1	 	0037	10	c0	00	bc	nv-BdIzC	0036	00	0	3	044	00	000	1	1
2037	0036	15	1	 	0037	10	c0	00	bc	nv-BdIzC	0036	15	1	3	044	00	000	1	1
2037	0036	15	1	 	0037	10	c0	00	bc	nv-BdIzC	0036	15	1	3	044	00	000	1	1
2038	0037	40	1	 	0037	10	c0	00	bc	nv-BdIzC	0037	40	1	3	088	00	000	1	1
2038	0037	40	1	 	0037	10	c0	00	bc	nv-BdIzC	0037	40	1	3	088	00	000	1	1
2039	4015	1f	1	 	0038	10	c0	00	bc	nv-BdIzC	4015	80	1	3	088	00	000	0	0	; DMC is disabled here
2039	4015	1f	1	 	0038	10	c0	00	bc	nv-BdIzC	4015	00	1	3	088	00	000	0	0
...
I didn't save the log with IRQ but it has the same delay : IRQ flag is set (if not disabled) when DMC is disabled (pcm_on/en -> 0), not when sample buffer is filled.

On the APU DMC wiki, it is say that once the sample buffer is filled
The bytes remaining counter is decremented; if it becomes zero and the loop flag is set, the sample is restarted (see above); otherwise, if the bytes remaining counter becomes zero and the IRQ enabled flag is set, the interrupt flag is set
And also on the main APU wiki :
$4015 read IF-D NT21 DMC interrupt (I), frame interrupt (F), DMC active (D), length counter > 0 (N/T/2/1)
...
D will read as 1 if the DMC bytes remaining is more than 0.

Based on the wiki informations, read on $4015 immediately after DMC sample is filled must have D bit = 0 (if there is no more remaining bytes for the sample), but based on the Visual2A03, there is a little delay of 2 cycles.

When my emulator worked in the same way that the wiki said, it passed successfully the apu_test test rom but since I added the delay like in Visual2A03, it fail on test 19 of dmc_basics (There should be a one-byte buffer that is filled immediately if empty).

Before searching elsewhere, I tried the dmc_basics single test rom in VisualNES and it fail also on test 19 :

DMC.png

So the question is : Does this test rom pass on real hardware ?

User avatar
Quietust
Posts: 1557
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: 7-dmc_basics (Test 19) on real NES

Post by Quietust » Wed Apr 08, 2020 8:30 am

I just tested it against my CopyNES and I'm pretty sure it worked (I don't have video hooked up, but I heard a single low "beep" which usually means it passed).

It's very possible that the test is failing in Visual2A03 (and VisualNES) due to a bug in the simulation - when I originally made Visual 2A03, I had to make several changes to the circuit definitions to make things work correctly, and I vaguely recall that DMC is one thing that was broken and which I never got a chance to fix.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

johnmph
Posts: 13
Joined: Fri Feb 28, 2020 8:17 am

Re: 7-dmc_basics (Test 19) on real NES

Post by johnmph » Wed Apr 08, 2020 12:35 pm

Thank you very much for the test, yes a single beep indicates that it passed the test.

Do you know if the DMC DMA and Sprite DMA timing are correct in Visual2A03 ? Because I mainly use it to try my emulator to pass the sprdma_and_dmc_dma test rom.

johnmph
Posts: 13
Joined: Fri Feb 28, 2020 8:17 am

Re: 7-dmc_basics (Test 19) on real NES

Post by johnmph » Thu Apr 09, 2020 9:40 am

It seems that the sprdma_and_dmc_dma test rom fails also on Visual2A03 :

sprdmadmcdma.png

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: 7-dmc_basics (Test 19) on real NES

Post by Sour » Thu Apr 09, 2020 10:06 am

If I recall correctly, there is a bug in the 2a03 core's sprite DMA that causes it to always DMA from page 0 (rather than using the page specified by the write to 4014), which is probably why you're getting the "OAM differed" message, but I think the cycle counts are also wrong?

Generally speaking, there are a lot of issues (e.g palette RAM has issues in visual nes, unsure if this is visual nes' problem or if the bug comes from the 2a03/2c02 cores.), I wouldn't rely on them too much when it comes to running test roms. They are useful for checking some specific behavior (e.g when are some flags set/reset, what happens when you toggle flag X at a specific time, etc.), but you can't assume that the result is always 100% correct.

johnmph
Posts: 13
Joined: Fri Feb 28, 2020 8:17 am

Re: 7-dmc_basics (Test 19) on real NES

Post by johnmph » Thu Apr 09, 2020 2:02 pm

Thank you, yes it seems that Visual2A03 always does the sprite DMA on page 0 but I didn't make the link with the OAM differed message.

User avatar
Quietust
Posts: 1557
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: 7-dmc_basics (Test 19) on real NES

Post by Quietust » Thu Apr 09, 2020 2:26 pm

Sour wrote:
Thu Apr 09, 2020 10:06 am
If I recall correctly, there is a bug in the 2a03 core's sprite DMA that causes it to always DMA from page 0 (rather than using the page specified by the write to 4014), which is probably why you're getting the "OAM differed" message, but I think the cycle counts are also wrong?
It turns out that, during Sprite DMA, the simulator was very briefly causing a bus conflict between the CPU address lines and the sprite page register - ab_use_spr_r (node 11099, which connects spr_a[8..15] to the DMA page) was going high before ab_use_cpu (node 11567, which connects CPU __ab[8..15] to spr_a[8..15]) went low.

Reordering the transistor definitions so that t14982 comes before t13266 (to better match the signal propagation order) seems to have fixed it.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Post Reply