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 »

Great write-up!

I'm glad you also got cases where you didn't see any 4-cycle blips, at least it seems like it's not some console dependent race condition or something out there like that (I'm guessing it's due to the Everdrive somehow anyway.) I tested a few times with resets instead of power cycles as well but still didn't see any 4-cycle blips. I'm content with simply setting that case aside for the time being.

I guess the next step for me is to get a working model of one cycle blips in emulator.

Also when I run the version that writes one in emulator I do not get correct results (the dma runs instantly.) Probably enabling the channel shouldn't immediately allow automatic DMAs to take place, there is a couple cycle delay. Maybe this would make an interesting test ROM?

Everything you wrote about the controllers definitely makes sense though. I'm not sure I'll try to get every detail of the bus conflicts correct right now, but I have confirmed that the extra reads of the opposite controller are important for TASes. One step closer to correct emulation!
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 »

So one other effect that I realized is necessary for everything to work is that if the buffer is emptied and simultaneously filled on the same cycle then it counts as full and does not trigger a new DMA. It also does not decrement the sample length counter an extra time. (Maybe this was already known but I hadn't implemented it until now.)

This combined with polling the opposite controller is enough to get TASes of both Tiny Toons and Ninja Turtles working for the first time. Cool stuff!

This is not enough however for Time Lord, which I'm pretty sure encounters some edge cases when turning off the channel instead of turning it on.

I also still haven't gotten the 1-cycle blips correct yet, but they haven't mattered for a TAS yet.

Making progress!
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 did some more testing, and right now TASes all seem to desync around times when the DMC channel is turned off at the same time a DMA should occur.

I don't yet know what the correct resolution is in this situation. My current implementation is to just turn off the channel immediately so no DMA occurs and the channel is disabled. Obviously this is wrong since everything desyncs, so figuring this out is definitely the next step.
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 had guessed before that the blips are from doing DMC DMA near the end of a DMC period, but now I'm wondering if it's instead caused by DMC disabling near the end of a DMC period. With one-byte samples, the initial DMA is the last one and it should turn off after that, which might be the same as disabling via a $4015 write. Feels like these could be the same issue. Based on the results from my tests, I wonder if you get a full DMA if the disable happens on the same cycle and a 1-cycle halt if it happens an APU cycle before. [Edit: To be more specific, if the $4015 write disabling DMC occurs on CPU cycle n, I'd guess a DMA can probably happen on n+1 or a 1-cycle halt on n+3. Not sure about the n+2 case.]


I didn't quite follow a couple things in your recent posts:
Alyosha_TAS wrote: Sun Dec 19, 2021 12:52 pm Also when I run the version that writes one in emulator I do not get correct results (the dma runs instantly.) Probably enabling the channel shouldn't immediately allow automatic DMAs to take place, there is a couple cycle delay. Maybe this would make an interesting test ROM?
Are you saying that, in emulator, the first DMA occurs earlier than 3-4 cycles after the $4015 write? But this doesn't happen on console? What is the DMC setup you're using here? Is the proposed test something to check real hardware behavior or is it an emulator correctness test?
Alyosha_TAS wrote: Mon Dec 20, 2021 5:33 pm So one other effect that I realized is necessary for everything to work is that if the buffer is emptied and simultaneously filled on the same cycle then it counts as full and does not trigger a new DMA. It also does not decrement the sample length counter an extra time. (Maybe this was already known but I hadn't implemented it until now.)
I'm also not quite following this. Can you explain this case a little more and how it differs from other cases?


Excited to hear we're getting more TASes running properly. Definitely chipping away at this problem.
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 disregard the first quote, I misinterpreted the results.

For the second I mean that, if the DMC channel is enabled (and the buffer is empty so it immediately triggers a DMA), if the fetch for the DMA happens at the same time as buffer is being reloaded by the DMC unit (in other words the timer is at 0 and the there are zero bits remaining) then the buffer will still be considered full, there will not be an additional DMA directly after the write triggered one. Thinking about it, it seems like this should be what triggers the 4-cycle blips as well, but for me it never does. By the way, one thing I noticed in using that test ROM is that sometimes the test resets itself on console. I don't notice this with any other test ROM. Perhaps the times I would ordinarily be seeing the 4-cycle blips something goes awry instead which eventually results in a rest and different alignment? Just speculation, seemed worth mentioning.

Anyway, I think the first part of your post makes sense. At least for disabling the channel 2 cycles before a DMA would occur, I can see it generating the one cycle blip in the same way as before. For disabling closer then that, I'm not sure what to expect, and several games disable the channel on exactly the same cycle as a DMA would occur, so all cases seem to be important,
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 »

So if I'm understanding right, if the sample buffer is being both filled and emptied on the same cycle, the result is that it is full. That's an interesting edge case and I wonder what the output unit is receiving during that time. Does it play the first byte of the sample twice? Does it do a byte of silence? Does it matter if it was previously playing something or not?

If the $4015 disable and the DMA happen on the same cycle, the $4015 write should push the DMA to the next cycle and I would guess that you maybe then get a normal, 3-cycle DMA (the n+1 case, but on the other cycle parity). That's very speculative at this point, though.

Regarding dmc_dma_start_test_v2, I've never seen it reset and I don't understand why that would happen. IRQs are disabled, but the IRQ vector is the same as the reset vector, so a BRK from going off the rails could do it, but I'm not sure why that would happen. It just happens randomly while the test is running with no input?
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'm only inferring that is the case based on the results of test 5 in the version of dmc_dma_start_test_v2 where I write one instead of zero. In that test there are no 4 cycle blips on console, and this only possible if this is what is happening. Also when I implement this behaviour some TASes sync much further then before. Note that they still desync later, but Tiny Toons and Ninja Turtles are both timing sensitive so it must be close to correct at least.

I don't really have any way of testing the disable cases. Somehow, TASes that encounter this case are surprisingly resilient to any changes I make. Time Lord in particular stubbornly behaves the same no matter what I do.

So basically, I'm really in need of your test ROM wizardry!

As for the resets, yeah I don't know. For example it will reset within 1 second of power on, but then remain stable there after. This happens maybe 25% of the time. Normally I would just assume it's a board problem, but it doesn't happen when I load up other test ROMs. It always happens very soon after power on also, not randomly while running.
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'll review my code to see if I can find any reason why it might crash. I'm currently stumped, though, and have no guess as to why you see this and I don't.

I think we should be able to make a test for disable that is very similar to the test for enable, but I haven't yet thought of a good way to read out the results. The test ROM I posted in this thread already perfectly times a DMC DMA, so we can move $4015 writes around relative to it, but while dmc_dma_start_test's enable occurs at a fixed location on the screen such that we can see the timings as the width of a greyscale bar, this disable test will be moving around, stretching into hblank, etc. We would probably need to read it out from a 60 FPS video rather than right off the screen. I'll see if I can think of something more elegant.
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 »

My current best idea is that I can start DMC playback up again afterward and search for how far the DMAs have drifted from their expected timing by using carefully timed reads from open bus. I still have to figure out the specifics, but I think this can provide all the data we need on its own.

The other thought I had is that I can see if an odd number of cycles was stolen by checking if the CPU/APU synchronization has inverted using single-cycle joypad strobes. This almost certainly wouldn't be enough information to identify all of the DMA timing behavior, though, so other methods of measurement would be needed.
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 »

Good luck!

In the mean time I think i've tracked down some issues with IRQ handling around DMC DMA that seem to effect Time Lord and probably MMC3 games that use that IRQ as well. Originally I was extending the results of Blargg's cpu_interrupts_v2 tests (which act around an OAM DMA) to DMC DMA as well, but this appears to be not quite correct.
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 »

One thing I found out is that there is about a 4 cycle delay between end of DMC DMA and IRQ happening. Somehow this escaped testing before, but this is important for Time Lord.
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 »

Another new finding. NMI timing is effected by DMA. Blargg's test 4-irq_and_dma.nes demonstrated this already for IRQ's but the same seems to be true for NMI as well. (Basically, an IRQ will be recognized if it occurs on the first cycle that the DMA starts, but will otherwise be delayed by one cycle after the DMA ends.) This is important for Tiny Toons. This is something that could also use a test ROM, it's possible I don't have the details quite right as the NMI could occur in different places relative to the CPU cycle (compared to frame IRQs that the original test used.)
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 »

Following up on the fact that IRQ occurs a few cycles after DMA finishes, it turns out you can cancel an IRQ by writing to $4010 in between the time the DMA finishes and the IRQ occurs (checked in visual NES.) Not yet sure about other effects like enabling and the loop flag. I'll check disabling via $4015 as well. Maybe something in there effects Time Lord.

Tiny Toons TAS now beats the game on console after some additional bug fixes, but doesn't encounter any disable cases and doesn't use IRQs.

EDIT: You can also enable IRQs via $4010, but you cannot disable them via $4015. I'm not sure what writing to $4015 is actually doing in between whena DMA happens and when the IRQ happens, it almost seems to be ignored until after the process is complete.
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 »

Attached is a test ROM that demonstrates the delay between DMC DMA and IRQ execution. It uses the value stored in the Y register to set the volume of the pulse channel that is enabled in the IRQ handler. Y has a value for 0 volume before DMA, then the following instrucitons occur:

STA $4015 (enable DMC channel and trigger immediate DMA)
NOP
NOP
LDY $3F

On (my) console, this plays a tone about 50% of the time, consistent with the finding that the CPU starts randomly on a get or put cycle.

Note that on Visual NES another NOP can be fit in as well, I'm not sure what revision it is based on but possibly this is revision dependent as this would be inconsistent with constraints of TASes on my console.
Attachments
DMC_IRQ.nes
(40.02 KiB) Downloaded 11 times
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've put together a couple pass/fail test ROMs for this. They're still WIP and there's a lot of cleanup, commenting, and documentation I need to add to make them release-ready, but they should be fully functional for the purposes of testing your hardware and emulator. Note that while I'm pretty sure about the offset numbers in the left column, that's the part of the test I'm most likely to have screwed up by miscounting.

The explicit version writes to $4015 to disable DMC DMA at various cycle offsets relative to the cycle on which DMA would have engaged. It then attempts to find how many cycles the CPU lost relative to the APU by seeing how far future DMAs have drifted from their expected position. We find that when the disable write occurs 2 or 3 cycles before the DMA, we get 1-cycle blips.

The implicit version writes to $4015 to enable DMC DMA with a 1-byte, non-looping sample at various cycle offsets relative to the cycle on which DMA would normally engage. We then measure the lost CPU cycles through the same mechanism as before (though with some mildly different code). This tests the same behavior as dmc_dma_start_test test 1, but with careful, programmatic measurement. Here, we see 4 cycle blips if the $4015 write is 6 or 7 cycles before when DMA ('reload' DMA) would have occurred, and 1-cycle blips if it's 8 or 9 cycles before. The $4015-initiated DMA ('load' DMA) occurs 3 or 4 cycles after the write and is 3 cycles in length, so the 4-cycle blip appears to be an erroneous reload DMA that occurs if a possible reload DMA lands immediately after a DMC-disabling load DMA. It is not yet known what address the DMA comes from nor which byte(s) are played, though we may be able to determine if both bytes are played by checking if a followup $4015 write causes a load DMA, telling us the status of the sample buffer. Notably, I do not see 4-cycle blips on my letterless Famicom, so this test currently claims to fail there.

In my testing, these results have been consistent; resets and power cycles do not appear to change them. If the tests do not pass on your console, please share the actual numbers.
Attachments
dmc_dma_implicit_stop_test_wip1.nes
(24.02 KiB) Downloaded 14 times
dmc_dma_explicit_stop_test_wip1.nes
(24.02 KiB) Downloaded 11 times
Post Reply