Runer and I talked about using statVars as a fourth buffer. It looks like it should be clear to use. Starting at statVars, you have about 830 bytes to work with that really shouldn't cause any problems unless you do stat operations or graph something.

To see the complete list of what you are destroying head over here and look at everything between 8A3Ah and 8D3A.

Edit:
   $8000 is also free to use as long as you don't archive/unarchive anything, just be sure to call bcall(_fillBasePageTable) when you are done.

   $8000 is also free to use as long as you don't archive/unarchive anything, just be sure to call bcall(_fillBasePageTable) when you are done.

Why do you need the bcall routine afterwards?

$8000 is also free to use as long as you don't archive/unarchive anything, just be sure to call bcall(_fillBasePageTable) when you are done.

I think using Copy() from an archived file would also destroy stuff in that area, because that uses bcall(_FlashToRam). Also, isn't the base page table only required if you're running a multi-page app with the custom bcall system?

I think using Copy() from an archived file would also destroy stuff in that area, because that uses bcall(_FlashToRam). Also, isn't the base page table only required if you're running a multi-page app with the custom bcall system?

Yeah, really, anything related flash will destroy $8100. If you destroy the base page table, most likely, you'll never notice. The only time it matters is when you run something before the base page table is built, for instance: a hook to a multipage application (CtlgHelp). So to be safe, just call the bcall.

Remember that if you want it to be compatible with MirageOS, don't use statVars at all.

That's only if you want it to be compatible with the MirageOS interrupt system. Do an IM 1 and you can trash statVars.

I just ran a program under MirageOS that disables interrupts and then sets 733 bytes starting at statVars to $FF. Upon returning, I notice no errors with MirageOS and no changed options. So it certainly seems like you can trash as much of statVars as you want, just make sure you disable MirageOS's interrupt handler. Maybe MirageOS uses a few bytes for options, like the return location, but setting them to $FF doesn't appear to mess up MirageOS anyways as far as I can tell. Perhaps I need to set a certain byte to a certain value to cause bugs in MirageOS, but I don't know of any such byte.

EDIT: You were the one who told me that O.o

Ok, so StatVars is free to destroy, however, what you leave there can have negative effects.

The only one I've ever found was leaving a 01 at $8A4A.

I think writing 00's to the whole thing should be safe though.