Page 4 of 5

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

Posted: Fri Jan 07, 2022 6:21 am
by Alyosha_TAS
Actually forget that stuff I had written about branch and DMA (I already removed it) I was just confusing which conditions are being checked, nothing unusual is happening there.

I'm pretty certain any delay in the DMA event (the actual read) is two cycles. The Halt always occurs as soon as the write cycles stop, but any delay in the DMA event itself is two CPU cycles, I'm pretty confident this is correct, and indeed your dmc_dma_start_test_v2 test relies on this.

I was actually going to look at the masking a bit later this week, because for some reason I still have DMA addresses wrapping to 0xC000 instead of 0x8000 in my code. I forget why exactly, it could be I just never updated it with new information. It's on my todo list.

And thanks for the info on the other TODO, I'm not sure I'll implement complete famicom behaviour yet, but it's good to keep in mind all the cases.

Good luck with the test ROMs. Oh and one final good test to have would be DMA while reading $2002. It seems like it should behave as a reread similar to $2007, but would be good to verify.

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

Posted: Fri Jan 07, 2022 4:44 pm
by Fiskbit
Thanks, that mostly clears up my confusion; I've been referring to delays with regard to the halting cycle, not the DMA read cycle. While a write cycle will always cause the halt to delay by 1 CPU cycle, it doesn't always cause a delay in the DMA itself. For a reload DMC DMA, landing on 1 write cycle will delay the halt by 1 cycle and shorten the length to 3 cycles total, keeping the DMA read on the same CPU cycle. But yes, any movement of the DMA read itself is always in multiples of 2 cycles because it has to occur on a get cycle, so anything that would move it to a put cycle will force an alignment cycle to push it one further.

For the branch stuff: By the sounds of it, IRQs are not detected while the CPU is rdy-halted, so for a normal instruction halted on its last cycle, the IRQ should be detected when the last cycle is executed after the DMA read and serviced before the next instruction. For halts on the 3rd cycle of a 3-cycle branch, though, the IRQ should be missed when the cycle is executed post-DMA and so the IRQ should be delayed an instruction. (I think.) With your branch changes backed out, does the behavior match the above or are you doing something different? Are you having desyncs again in SMB3?

Good idea on a test for $2002, as well; I guess that means DMA makes $2002 vblank loops even less reliable.

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

Posted: Sat Jan 08, 2022 3:55 pm
by Alyosha_TAS
Yes that it what I am doing for branch. I got confused because normal instructions check for interrupts, but that case is written to check for the absence of interrupts. I should probably change things to be uniform. SMB3 works correctly in this way. Actually, there are no longer any TASes I have that desync on console due to DMC (or any other) emulation issue. I need to find more games that use the DMC IRQ. (EDIT: looks like it's a short list, only fire hawk and Mig 29.)

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

Posted: Sat Jan 08, 2022 4:33 pm
by Fiskbit
Was about to post both of those, but was checking some other Codemasters games to see if I could find others. Not sure if it's useful because I can't imagine it has a TAS, but I used it in Atmo Sphere.

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

Posted: Sun Jan 09, 2022 4:25 pm
by Alyosha_TAS
Neat game, but yeah no TAS. Unfortunately most existing TASes desync pretty badly on the updated emulator and I don't have time to make entirely new ones. Looks like my own testing will be slowing down significantly for now (but I think we got nearly all the important cases anyway.) I'll need to come up with a plan with somehow picking out games where I can get maximum utility from them.

Also it occurs to me that NESHawk is not well suited to re-reading $2002 because currently I lump re-reads at the end, but this isn't correct for $2002 when possibly cancelling an NMI. Depending on how things actually work on console this could trigger a pretty significant re-wrtite of the code. It's pretty amazing to me just how easy it is still to break the emulator.

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

Posted: Mon Jan 10, 2022 4:30 pm
by Fiskbit
The timing on rereads of $2007 can also matter, since during rendering, it does increments on fine y and coarse x, which could affect sprite 0 timing. (I guess it could also matter for something like A12 edge detection outside of rendering.) Aside from situations caused by bugs, I don't know if this would realistically ever matter for execution, since using $2007 reads to scroll is probably usually done after sprite 0 hit (such as in Zelda 1).

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

Posted: Thu Jan 13, 2022 1:27 am
by Fiskbit
lidnariq took some measurements today on a simple test ROM and found the when DMC DMA interrupts OAM DMA, the address on the bus on the OAM DMA alignment cycle before accesses resume is the CPU address. It seems that every halted cycle where DMA is not actively accessing uses the CPU address.

I should be able to construct a test ROM that can verify this, though this particular case (interrupted OAM DMA) probably never matters for real workloads because it's hard to have a vulnerable address on the CPU bus the cycle after a $4014 write.

I'm hoping we'll have some results within a couple weeks showing the implicit disable test on a range of G CPUs to try to narrow down the source of the extra DMA.

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

Posted: Thu Jan 13, 2022 4:18 pm
by Alyosha_TAS
Yikes, I definitely can't account for that with the current architecture I have, time to start rethinking things I guess. Even if irrelevantall to real world work loads, I welcome all emulator breaking test ROMs.

i do have a question though, if it's always the cpu address on the bus except for the read in the DMA, how does the famicom get the extra controller clocks?

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

Posted: Thu Jan 13, 2022 4:55 pm
by lidnariq
On the NES, the controller ports are directly connected to the CPU - the signal is true for the entire time that the address bus is stable, and φ0/φ2/M2 aren't a factor.

On the Famicom, the same signal is instead shaped by M2 - the joypads' CLOCK inputs are connected to the 40H368 that drives NOT(M2) strongly during /RD4016 or /RD4017 and is weakly pulled up by a resistor the rest of the time.

In practice, this means that /RD4017 and /RD4017 on the NES are asserted for close to 560ns, and multiple cycles with the same address will remain asserted for the whole time. In contrast, on the Famicom, the signals are asserted for roughly 350ns or 400ns depending on CPU revision, and the signal will flap repeatedly even if the address is constant.

The multiple bit deletions on the Famicom controller ports have the same cause as multiple byte deletions on reads from $2007 - but PPU read deletions happen on all consoles, because M2 is always included by the 74'139.

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

Posted: Thu Jan 13, 2022 5:01 pm
by lidnariq
Relatedly, here is the tiny test ROM that Fiskbit specified to record bus activity of:

Code: Select all

;;; public domain (fiskbit+lidnariq 2022)
;;; assemble with cl65 -t none -o colliding-dma.bin colliding-dma.asm
        .setcpu "6502x"

        .CODE
        .org $E000
        .include "constants.ca65.inc"

reset:  
        lda #$0F
        sta APU_PERIOD_DMC
        lda #$00
        sta APU_DAC
        sta APU_DMC_OFFSET
        sta APU_DURATION_DMC
        
        ldx #$10
infi:
        stx $4015
        sta $4014
        jmp infi

vectors:
        .repeat ($fffa-*)
        .byte $FF
        .endrep
        .word reset, reset, reset
And here's the logic analyzer recording of same, showing that the address bus snaps back to $E018 during the DMA "put" cycle after the "get" that fetched the DPCM byte.

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

Posted: Thu Jan 13, 2022 5:19 pm
by Fiskbit
Note that because CPU/APU alignment is random on power-on, that test isn't guaranteed on the first pass to have DMC DMA occur during OAM DMA, but will settle into the desired arrangement forevermore afterward.

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

Posted: Fri Jan 14, 2022 5:37 am
by Alyosha_TAS
I see, interesting architectural difference there, thanks for the replies.

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

Posted: Mon Sep 26, 2022 12:51 am
by Fiskbit
Lockster has run my dmc_dma_implicit_stop_test on different 2A03G's in the same console. He found that his 1987 and 1989 G's fail (no 4-cycle blips) and two 1991 G's pass (yes 4-cycle blips). This confirms that the behavior is definitely caused just by differences in the CPU and that there are at least two meaningfully-different revision G CPUs. It appears that the bug was introduced into later-produced chips.

We still don't know what address is being read when this glitch occurs or whether it gets played.

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

Posted: Thu Dec 08, 2022 7:51 pm
by Alyosha_TAS
Recently I had been working on testing a TAS of Castlevania III on console and found that it didn't work. Originally I thought it was probably something to do with MMC5 since its emulation hadn't been updated in the emulator in some time.

I had some time to dig into it again, and now think that this isn't the case. The game really isn't doing much with the MMC5. It just makes an IRQ once per frame. I tested a wide range of potential IRQ timings and none of them worked on console.

So I thought maybe it was DMC issues again, but none of the other DMC nuances effected this game.

What I did find though is a single instance where the game was checking the DMC length counter via reading $4015 at the same time the length counter would be decrementing to zero.

So, is this case currently tested by anything? It seems if I change the result it is enough to influence Castlevania 3 but I can't tell if it is correct yet. A stand alone test would help narrow things down. If anyone is interested in making a test ROM I would very much appreciate it.

EDIT: I tested a bit more and it does seem that if reading from $4015 and decrementing to 0 on the same cycle, it should read as length counter zero, where as I had it read back non-zero before. This gives correct results in Castlevania III

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

Posted: Fri Dec 09, 2022 1:39 pm
by Fiskbit
Here is a really quick-and-dirty hack of my earlier tests that I believe does what you're asking. It shifts the position of an LDA $4015 around the time that the last DMA of a sample will happen. On hardware (and Mesen), I see 5 0's and then 5 1's. NesHawk from earlier this year gives 3 0's and 7 1's.

At some point, I'll try to make another version of this that tests for IRQ timing.


Edit: Just for fun, I also tried a version of this with looping enabled to see if the counter is ever visibly 0, and it gave all 1's. I also realize I probably should've made this sweep across in the other direction (so it'd give 1's and then 0's), but quick-and-dirty, as I said!