Reset Protection of $BC20 - $BFFF - possible?

[flashjazzcat]

I would find it useful to have program code in the $BC20-$BFFF region (under BASIC, which is disabled) and protect it from being overwritten by the default display handler on Reset. Unfortunately the OS seems determined to open the editor at this address regardless of MEMTOP or RAMTOP settings, which are evidently recalculated on Reset based on whether there's a cartridge present. Is there any way to "fool" the OS into opening E: at a lower address, or am I on a hiding to nothing here?

[Rybags]

Set the flag to enable Basic.

 

But then you get $9C20 - $9FFF overwritten.

 

Then use CASINI or DOSINI to switch Basic out again.

 

No other real alternative, either way you get near 1K wiped out.

 

Actually, just or two alternatives - PBI handler could probably get in and change RAMTOP. Or, a cartridge could stop it.

Diagnostic mode cart gets control right away, but you have no OS variables or functions initialised.

Normal mode cart you get the JSR thru $BFFE before "E:" is opened, if you don't return you have a mostly initialised system but no pesky screen.

Alternatively you could return after changing RAMTOP to a lower value.

Edited October 14, 2011 by Rybags

[flashjazzcat]

Hmmm... setting BASIC flag would probably be OK (this is non-cart software), since $8000-$9FFF is buffer space anyway. Problem is, I wanted to make the buffer space dual-purpose: display RAM for the Antic 80 column handler (in which case it's no problem if it gets overwritten after Reset), or text buffer space when the display buffer is in VBXE's RAM. Clearly text buffer space should not be overwritten at any time (note $8000-$9FFF is chosen for its proximity to $4000-$7FFF, since it's essentially an optional "extension" of the text buffer space which is fixed in the banked area).

 

The only other way of doing it is to find some buffers which don't need to retain their data and aren't dependant on the screen driver in use and cram them all into $BC20-$BFFF. Trouble is, such buffers currently reside in pages 4, 5 and 6. I suppose it's safe to fill pages 4 and 5 (we know page 6 is safe) with code providing the FP and cassette handler aren't used (which they aren't). We could put the code at the top of memory into this area, and move the buffers up to the top under the OS screen RAM.

 

Anyway - thanks for the suggestions!

Edited October 14, 2011 by flashjazzcat