Allow POKE copy beneath I/O and Kernal ROM

[rscottfree]

This updates MDBASIC’s range-copy POKE operation so it can access RAM hidden beneath I/O and the Kernal ROM. I want to load sprite data under Kernal and copy it into VIC space later.

During range-copy operation 5, MDBASIC now:

• Disables interrupts before changing the memory layout.
• Banks out I/O and the Kernal by changing $01 from $36 to $34.
• Performs the copy with all RAM visible.
• Restores the normal memory configuration and re-enables interrupts.

The copy loop and operation handling were rewritten to use fewer bytes. The MDBASIC image still fits exactly but it now uses the two padding bytes that were previously free.

Tested in VICE 3.10, including:

• Copies to and from normal RAM.
• Copies to and from RAM beneath I/O at $D000–$DFFF.
• Copies to and from RAM beneath the Kernal at $E000–$FFFF.
• A copy crossing the $DFFF/$E000 boundary.
• A copy ending at $FFFF.
• A 256-byte copy to test the counter rollover.
• Restoration of $01 and normal BASIC execution after a copy.
• Existing range-POKE AND, OR, and EOR operations.

[bowren]

I tried this approach (disabling IRQs) the way you did here but found that device and Kernal memory can still be called from a NMI (non maskable IRQ). If the restore key is pressed while copying bytes in the bitmap area the entire system will freeze. This is an existing problem (bug) with the PAINT statement since it reads before it writes. I decided to leave it alone since instructions for disabling/enabling NMI needed more bytes than are available. I will test your branch this weekend.

[rscottfree]

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.

[bowren]

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.

[rscottfree]

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.