search

n64dev / cen64

Cycle-Accurate Nintendo 64 Emulator
BSD 3-Clause "New" or "Revised" License
803 stars 70 forks source link

RSP set halted PC is broken again #216

Open hcs64 opened 2 years ago

hcs64 commented 2 years ago

Issue #151 has reappeared after 87ebca00b51747db09f7bceefc14537bda06c284. That issue included a test ROM which now shows red again. The mechanism the test ROM uses is:

  1. CPU starts the SP at 0 (which fills the screen with red)
  2. CPU waits for SP to break
  3. CPU sets the SP PC to a nonzero address (which would fill the screen with green)
  4. CPU clears SP halt

write_sp_regs2() stores the value written for the SP PC in ifrd_latch.pc, and now zeroes out the pipeline. But when rsp_status_write() saves the PC across SP_CLR_HALT, it now reads the PC from rdex_latch.common.pc (which will be 0) and writes that to ifrd_latch.pc, so we resume at 0 (and the screen turns red). I don't understand the pipeline well enough to understand which part of this is wrong.

hcs64 commented 2 years ago

My tests indicate that the CPU should be able to read back the SP PC it has written while the SP is halted. Given that the SP PC is currently read from dfwb_latch.common.pc, but written to ifrd_latch.pc, cen64 doesn't currently do this right. I wonder if there's a separate register for the SP PC that gets used to init the pipeline when halt is cleared, rather than it being one of these regs directly in the pipeline.

@rasky I wanted to bring this to your attention as I don't think I understand the pipeline as well as you...

I'm attaching two new versions of the test ROM, rsp_halt_test.n64 now does some additional verification about executing instructions around a break, and rsp_halt_test_read_back.n64 (built with READ_BACK_PC defined) has the aforementioned checks that the CPU reads back the right addresses. Both of these turn the screen green on hardware, I documented the error colors in the header of the assembly source.

rsp_halt_test_1_1.zip

rasky commented 2 years ago

Honestly, I don't understand why the pipeline is reset on UNHALT. The commit message cites "fix a bug" without details, so I don't know. Maybe it was the wrong fix for the fact that the pipeline was not being reset on SP PC write? I can try testing removing the pipeline reset on UNHALT.