Trinity-11 / FoenixIDE

Development and Debugging Suite for the C256 Foenix Family of Computers
GNU General Public License v3.0
48 stars 14 forks source link

Block attempt to write read-only memory on F256 #46

Closed clandrew closed 1 year ago

clandrew commented 1 year ago

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.

dtremblay commented 1 year ago

Thanks for the PR. It would be nice if you could explain how to test it.

clandrew commented 1 year ago

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.