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 »

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.
Fiskbit
Posts: 318
Joined: Sat Nov 18, 2017 9:15 pm

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

Post 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.
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 »

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.)
Fiskbit
Posts: 318
Joined: Sat Nov 18, 2017 9:15 pm

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

Post 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.
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 »

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.
Fiskbit
Posts: 318
Joined: Sat Nov 18, 2017 9:15 pm

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

Post 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).
Fiskbit
Posts: 318
Joined: Sat Nov 18, 2017 9:15 pm

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

Post 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.
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 »

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?
lidnariq
Posts: 10712
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

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

Post 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.
lidnariq
Posts: 10712
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

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

Post 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.
Attachments
colliding-dma.zip
(2.36 KiB) Downloaded 12 times
Fiskbit
Posts: 318
Joined: Sat Nov 18, 2017 9:15 pm

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

Post 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.
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 see, interesting architectural difference there, thanks for the replies.
Post Reply