Allow POKE copy beneath I/O and Kernal ROM - #3

but found that device and Kernal memory can still be called from a NMI (non maskable IRQ)

I couldn't find a work-around for that issue either.

Last year I tried a quick fix test by overriding the NMI standard handler (which I'd rather not touch). The new handler ensured the Kernal was available by checking the bits at register 01ドル and if so execute as normal, if not, skip the whole event. For some reason that did not work so I gave up on it. I figured it is unlikely to happen anyway. It took me many years before I even noticed it (I began MDBASIC when I was 15) by pressing the Run/Stop-Restore key combo.

I really wanted to be able to safely PAINT and move bitmap content with POKE's copy operation. I'm sure I was on the right track to fixing this by having a new NMI handler in RAM that could first save the state of register 01,ドル ensure Kernal & devices are available, execute original NMI handler routines, then restore register 01ドル. I am considering sacrificing the TRACE command to have enough RAM to do this.

I think there will always be tradeoffs. I've experimented with a cartridge-only menu that hooks into ctrl+restore, and I moved the renum command there, and all of that stays out of the 16k, which I think freed up about 300 bytes of ram which I tried to use to build an irq-driven sprite movement routine so I could move multiple sprites at the same time. I decided it was better (and more fun) to program within the constraints of the system and use the stock MDBASIC that everyone else would be using. Being able to copy the ram under the kernal would be neat but not required.