Count Errors Test ROM and some new DMC glitch info

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

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

Re: Count Errors Test ROM and some new DMC glitch info

Post by Alyosha_TAS »

Awesome! These tests are exactly what I needed, thanks a lot!

On my console:

explicit test: pass

implicit test: fail, only two 1's in their expected positions. no 4's. I did 10 power cycles and 10 resets.

Emulator: After implementing these cases and the IRQ delay mentioned above, Time Lord TAS now works on console (up to the last boss, which very unfortunately desyncs due to un-initialized RAM of all things.) Tiny Toons 2 now syncs past where it desynced previously, need to make a complete run.(EDIT: complete TAS syncs on console.) Cool!

Great work!
Fiskbit
Posts: 317
Joined: Sat Nov 18, 2017 9:15 pm

Re: Count Errors Test ROM and some new DMC glitch info

Post by Fiskbit »

Glad to hear this is working out!

I've run the tests across a wide range of consoles using my Everdrive N8 for NES consoles and N8 Pro for Famicoms. Results are always consistent across resets and power cycles, and every single console I've tried passes the explicit test. For the implicit test, I get these results:

Famicom (2A03 CPU-03): No 4-cycle blips
Famicom (2A03G CPU-07): No 4-cycle blips
Famicom (2A03G GPM-02): Pass
Twin Famicom AN-500B (2A03E): No 4-cycle blips
Twin Famicom AN-505-BK (2A03G?): No 4-cycle blips
AV Famicom (2A03G CPU-01): Pass
AV Famicom (2A03H CPU-02?): Pass
AV Famicom (2A03H (Laser) CPU-02): Pass
Dendy Junior (UM6561AF-2): Has 4-cycle blips, but results are shifted by 1 APU cycle (4's and 1's are at offsets -8 through -B instead of -6 through -9)
NES-001 (2A03E): No 4-cycle blips
NES-001 (2A03G): No 4-cycle blips
NES-101 (2A03G Hi-Def mod): Pass

It looks to me like the behavior depends on factors external to the CPU, varying by console type. Note that the Famicom that passes is a GPM-02 and I'm not surprised its behavior would differ from the earlier CPU-xx boards. I don't understand how factors outside the CPU could make a difference here, but that looks like what we're seeing.

The Dendy result is somewhat interesting to me. It could mean that load DMAs occur one APU cycle later than on official CPUs, or maybe that disabling DMC after a sample ends occurs 1 APU cycle later than a $4015-write disable. I decided to look at dmc_dma_start_test_v2 test 5, which tries to isolate one DMA alignment, and curiously, the result seems to vary at different locations on the screen; in some spots, I see it flicker between 8 and 11 cycles, and in other spots, I'm seeing 8 cycles solid or flickering between two different 8-cycle positions. Maybe start_test is unreliable on this console because blargg's PPU/NMI sync code isn't working correctly on these timings, but the fact that I see 11 cycles sometimes and also no 4-cycle blips in those cases suggests to me that load DMA timing is the same and that implicit disable timing might be 1 APU cycle later.
Fiskbit
Posts: 317
Joined: Sat Nov 18, 2017 9:15 pm

Re: Count Errors Test ROM and some new DMC glitch info

Post by Fiskbit »

I find myself very dissatisfied with the idea that something external to the CPU is responsible for the DMA unit's decision to perform an extra read. This just doesn't fit with my (admittedly basic) understanding of how this works; I'm not aware of any mechanism that could allow this. An alternative I've been considering is that there are actually two functionally-different revisions both called RP2A03G, with only later ones featuring this bug. All of the G's on which I've seen this bug are in late-era consoles. Swapping CPUs between two consoles with different behavior would determine whether this is the case.

Edit: Another possibility suggested to me is some kind of analog effect, though I have no guesses at this point what the source of that would be.
Alyosha_TAS
Posts: 140
Joined: Wed Jun 15, 2016 11:49 am

Re: Count Errors Test ROM and some new DMC glitch info

Post by Alyosha_TAS »

Just to make sure I understand your results correctly, have you ever gotten different results for the 4-cycle blips on the same condole?
Fiskbit
Posts: 317
Joined: Sat Nov 18, 2017 9:15 pm

Re: Count Errors Test ROM and some new DMC glitch info

Post by Fiskbit »

With the new test ROMs, I have never gotten different results on the same console, and did several resets and around ten power cycles per console. I did with dmc_dma_start_test_v2, but it doesn't make an effort to sync with the DMA period and so may be sensitive to startup timings, which vary significantly in my case because I use Everdrive. I might play around with that more to try to confirm that it can get into a bad sync or something. The stop tests synchronize before proceeding and shouldn't have any timing variance in the results.
Alyosha_TAS
Posts: 140
Joined: Wed Jun 15, 2016 11:49 am

Re: Count Errors Test ROM and some new DMC glitch info

Post by Alyosha_TAS »

Is there a console that got 4 cycle blips with the old test and not the new test?
Fiskbit
Posts: 317
Joined: Sat Nov 18, 2017 9:15 pm

Re: Count Errors Test ROM and some new DMC glitch info

Post by Fiskbit »

I haven't run the old test on as many consoles, but I'm not aware of any results inconsistent with the new test. With the old test, I did not see 4-cycle blips on my 2A03 CPU-03 or Twin Famicom 2A03E consoles and did see them on my AV Famicoms and 2A03G GPM-02 Famicom.
Alyosha_TAS
Posts: 140
Joined: Wed Jun 15, 2016 11:49 am

Re: Count Errors Test ROM and some new DMC glitch info

Post by Alyosha_TAS »

Cool, so at the very least it seems to not be an analog effect on individual consoles, that's reassuring.

Even after I implemented everything learned so far, I still have a consistent desync in Super Mario Bros 3. I also have no further ideas of missing edge cases. The game doesn't use DMC IRQ, the frame sequencer IRQ, or read from $4015 as far as I can tell, so the issue must somehow be DMA related again. The TAS plays through 7 of the 8 worlds correctly only to desync in level 8. I can't identify anything odd around the time the desync happens. Whatever the problem is, it's very rare (and probably the last bug left to identify.)

The challenge continues.
Fiskbit
Posts: 317
Joined: Sat Nov 18, 2017 9:15 pm

Re: Count Errors Test ROM and some new DMC glitch info

Post by Fiskbit »

Interesting that there's still something left. I just checked dmc_dma_start_test_v2 on the current Appveyor build of BizHawk and it looks like the DMA timing and 1-cycle blip behavior is working correctly there, though I couldn't check the bit deletion tests (B-D) because I couldn't figure out how to add a second controller. I don't have any ideas yet for more places to look for new bugs, but here's a couple known things that might be worth double checking:

1. Are you sure that your DMA behavior interacts properly with the triple-write that occurs during interrupts?
2. Could the difference be in the controllers you have attached? Specifically, first-party controllers will return 1's after 8 reads, while no controller or some third party controllers will return 0's. This could matter for the extra joypad clocks.
Alyosha_TAS
Posts: 140
Joined: Wed Jun 15, 2016 11:49 am

Re: Count Errors Test ROM and some new DMC glitch info

Post by Alyosha_TAS »

To change controllers, after you load a NES rom an 'NES' menu will appear in the top row of menues,click that and go to controller settings to change them.

I'm confident attached / unattached controllers behave correctly, but you kow what, there just might be a case where the 3 consecutive writes aren't handled correctly. If a DMA is triggered directly by a write to $4015 and an IRQ / NMI happens on the next instruction, it's possible that there should be two 2-cycles delays in the DMA executing instead of just one. Interesting! is there a way to test this? I might try this out later today regardless, it sounds rare enough yet important enough to be the culprit, nice thinking!
Fiskbit
Posts: 317
Joined: Sat Nov 18, 2017 9:15 pm

Re: Count Errors Test ROM and some new DMC glitch info

Post by Fiskbit »

DMA cannot halt on write cycles and should just keep being delayed one cycle at a time, so my expectation is that a 3-cycles-later DMA should be delayed 3 times and take 4 cycles, while a 4-cycles-later one should only be delayed twice and still take 3 cycles. This should be testable, though I'm not yet practiced at landing an interrupt relative to an event.

For controllers, I was also wondering if the real-hardware playback matches what was used in emulator. For example, if the emulator only had one controller attached, is the playback device smart enough to act like this and not give 1's after 8 reads on that port that should be open?

I'll fiddle with BizHawk controllers again later; I had found a menu for changing controller button mappings, but there didn't seem to be a way to add more controllers there. Can't remember if that's the same menu you're describing here.
Alyosha_TAS
Posts: 140
Joined: Wed Jun 15, 2016 11:49 am

Re: Count Errors Test ROM and some new DMC glitch info

Post by Alyosha_TAS »

Well I fixed the edge case in 3 consecutive writes handling but it didn't make a difference, I suppose that case just wasn't encountered. Still a good catch though.

For TASes that only use one controller, only one controller is connected to the replay device, the other port is open, so that's not an issue.
Last edited by Alyosha_TAS on Fri Jan 07, 2022 6:09 am, edited 1 time in total.
Fiskbit
Posts: 317
Joined: Sat Nov 18, 2017 9:15 pm

Re: Count Errors Test ROM and some new DMC glitch info

Post by Fiskbit »

Would you be willing to write out a cycle-by-cycle breakdown of the edge cases you've identified lately? Specifically, this branch/interrupt/DMA case, the DMC IRQ timing, and the buffer empty/refill? With that, I can try to puzzle out pass/fail test ROMs for the various effects.

I've also been a little confused by you mentioning 2-cycle delays, and I see 2-cycle delays in the NesHawk code, but as far as I know, delays on DMA halting are always a single cycle at a time. Could you explain a bit more what you mean here?
Alyosha_TAS
Posts: 140
Joined: Wed Jun 15, 2016 11:49 am

Re: Count Errors Test ROM and some new DMC glitch info

Post by Alyosha_TAS »

I can try. First of all to avoid confusion, whenever I say cycles I always mean CPU cycles. NESHawk doesn't have an independent concept of APU cycles. So when I have a 2-cycle delay, it's one APU cycle.

Ok, so first of all, for buffer empty / refill, I believe the timing is the same as for the 4 cycle blips, except with a non-zero remaining length. My working hypothesis is that the actual buffer the DMC is using is refilled 2 cycles after DMA finishes (this is also when IRQ is asserted.) So, if a write triggered DMA happens, and then 2 cycles later the DMC buffer is emptied (last bit is used and timer expires) at the same time the byte read from the DMA is transferred to the buffer, it counts as full. This can already be tested with your previous test ROM if a 1 is written instead of a zero to the length counter. In cycles:

Code: Select all

|_____________________|_______________________|______________________|
         ^                                               ^
last DMA cycle                            buffer refilled here (also emptied in this case, so counts as refilled, no additional DMA.)
This is the same timing for the IRQ delay:

Code: Select all

|__________________________________|___________________________________|_________________________________|
       ^                                         ^                                               ^
last DMA cycle        IRQs can still be enabled disabled her (via $4010)!             IRQ (and no further changes possible)

However, disabling the channel via $4015 in the intervening cycle does NOT cancel IRQs.
actually unsure of the details here.
Last edited by Alyosha_TAS on Fri Jan 07, 2022 6:08 am, edited 1 time in total.
Fiskbit
Posts: 317
Joined: Sat Nov 18, 2017 9:15 pm

Re: Count Errors Test ROM and some new DMC glitch info

Post by Fiskbit »

Thanks, I think that makes enough sense. I'll see about getting a more complete suite of pass/fail tests for all this stuff over the next while. Would be good to move the visual tests from dmc_dma_start_test_v2 to something automatic, as well, like verifying that 1-cycle blips are skipped if they land on a write cycle.

I want to make sure we're on the same page with regard to delays. As I understand it, if a DMA halt lands on a CPU write cycle, the DMA should be delayed by just 1 CPU cycle, not 2. You mentioned 2-cycle delays earlier and I see += 2 in the code described as being one cycle of delay, so it feels like you're delaying by an APU cycle rather than a CPU cycle. Perhaps I've got the wrong idea of how DMA delays work or am misunderstanding you and the code.

Another thing I notice in the code is that your DMA address mask is $401F for APU register activation, but should actually just be $1F. This won't matter in probably any normal case because DPCM data is kept in $C000-FFFF, but if one were to have a sample that wrapped past $FFFF back to $8000, then register reads should still be happening in that lower region and would be missed by your checks. zeta0134 may have found a practical use for wrapping samples (MMC5 PCM playback in read mode, having DMC read from $8000-BFFF to set the MMC5 PCM level), so this could matter for a real (non-bug) reason in the future.

I also see a TODO asking whether controllers should be clocked by 1-cycle blips. They should not except on RF Famicoms because the read address remains the same joypad register for both cycles (as described in this post on page 1).
Post Reply