Neon64 emulator fails in ./N64 System/Mips/Dma.cpp about project64 HOT 3 CLOSED

does one of your pull request fix this or it still needs to be investigated?

from project64.

It looks like a breakpoint in SP DMA address unaligned write.

My pull request was for PI DMA so no it does not fix it.
I can try to look into a third consecutive pull request to fix this.

from project64.

I've changed my mind. I no longer want to look at this as an issue or send a pull request.
In fact it seems the wiser course of action is to leave this "issue" unfixed.

"Fixing" it is easy enough. All you have to do is remove this breakpoint from Project64 dma.cpp:

    if (((g_Reg->SP_RD_LEN_REG + 1) & 3) != 0) { g_Notify->BreakPoint(__FILE__,__LINE__);  }

However, how do we know that simply removing the breakpoint is the correct fix? I've tried replacing the g_Notify->BreakPoint with other things, like g_Reg->SP_RD_LEN_REG += 0, or += 1, or += 2 ... the ROM seems equally frozen no matter how I handle the unaligned address, and this goes for 1964 0.8.5 as well since that also does not support all the cart peripherals of the N64 hardware needed to emulate a NES cartridge. (The closest thing to documenting this that I have seen is that neither 1964 nor Mupen64 care if SP_RD_LEN_REG isn't 32-bit aligned like Project64 does, but that doesn't prove that they shouldn't care like Project64 does.)

Neon64 is open-source and was written in plain MIPS assembly, so you would think that this unaligned DMA address could have been intended. Using some basic skimming across the entire source and doing Ctrl+F for "sp_base_reg" and "404" (the high prefix of SP_BASE_REG in the RCP memory map, possibly 0xA404 or 0x0404), I could only find four files even accessing this register: neon64.asm, inits.inc, and write.inc.

The only direct reference to SP_RD_LEN_REG is in inits.inc:

                ; Load the PPU data (mostly the page table)
                la      a0,0x0
                la      a1,rspdataa
                li      a2,0x1000-8
                lui     t0,$a404
                sw      a0,0(t0)        ; a0=rspdest
                sw      a1,4(t0)        ; a1=dram
                sw      a2,8(t0)        ; a2=size
...
                ; Load the PPU microcode
                la      a0,0x1000
                la      a1,rsptext
                li      a2,0x1000-8
                lui     t0,$a404
                sw      a0,0(t0)        ; a0=rspdest
                sw      a1,4(t0)        ; a1=dram
                sw      a2,8(t0)        ; a2=size

Neither of these fragments suggest that Project64 is even supposed to have an unaligned SP_RD_LEN_REG. Here, a2 stores a 32-bit word to 8(t0), or SP_RD_LEN_REG, which is set to the expression 0x1000-8 in both cases, which IS 32-bit aligned, even though Project64 complains a breakpoint that this register had an unaligned address. Perhaps there is some external interference causing an indirect update to this register, but as I do not own an actual N64 console anymore, I cannot verify whether this happens on the real N64 hardware as well.

I think the best course of action is to wait for a different (hopefully playable) demo ROM to raise this breakpoint message to Project64 and then test based off that how it should be handled.

from project64.