Closed clandrew closed 1 year ago
Thanks for the PR. It would be nice if you could explain how to test it.
Thanks for the PR. It would be nice if you could explain how to test it.
Sure thing! I tested it with some code that does
; Define IRQ_Handler as some function in your code
LDA #<IRQ_Handler
STA $FFFE ; VECTOR_IRQ
LDA #>IRQ_Handler
STA $FFFF ; (VECTOR_IRQ)+1
LDA #$FF
STA INT_MASK_REG1
AND #~(JR0_INT00_SOF)
STA INT_MASK_REG0
In a PGZ launched by MicroKernel. When you launch an application from MicroKernel, the last bank of CPU address space is mapped to flash, not RAM. So those stores to $FFFE and $FFFF would be attempted writes to flash.
On hardware, those attempted writes would be blocked, so the SOF handler would not be set. On emulator, I saw the writes go through and set the SOF handler. I verified this behavior in the debugger.
It's generally an application bug to attempt write to ROM. Like here, this is an application bug. It would be good if the emulator could help users catch these bugs.
Before this fix: if you have a program that accidentally attempts to CPU write flash memory, you'll see different behavior between emulator and hardware. Hardware will block the write, emulator allows it.
This fixes it so that emulator also blocks the write.
The fix works by designating a separate MemoryMap called "FLASHJR". It's initialized through loading the kernel, and then CPU writes afterward are blocked.