Free Ram Areas

KermMartian · Site Admin (Posts: 64054)

1) If you use no libraries, other than maybe the Ion libraries, you can do whatever you want. If you leave the stack in the proper place when you quit, Doors CS will properly recover using the DCS7 appvar, where it cached some important info.

2) If you use the Doors CS GUI or Associated Program system, then the following page from the Doors CS wiki describes your caveats:
http://dcs.cemetech.net/index.php?title=GUI_Memory_Areas

3) If you use CALCnet2.2, then StatsVars (for the interrupt vectors) and the first 570 bytes or so of SavesScreen become unavailable.

KermMartian · Site Admin (Posts: 64054)

As far as Mirage's routines go, I think that only the interrupt-setup ones (and of course their associated semipermanent interrupts) take up significant memory. All the others work on registers or existing memory or do thing like re-order the VAT.

Edit: I'm curious what the end-goal of the questions is; it sounds to me like perhaps you're creating something that needs to peacefully coexist with shells?

KermMartian · Site Admin (Posts: 64054)

Definitely! The main caveat would be an inability to use anything with interrupts if the StatsVar RAM was being used for other things, correct?

KermMartian · Site Admin (Posts: 64054)

Well, part of the problem is that because interrupts indicate their address with an 8-bit value (say $MM), but addresses are two bytes (such as $SSTT), you need to have an interrupt table at some other address $NN00, containing 257 total bytes, each of then $MM. This will then lead to an interrupt stored at $MMMM (note that this address has to take the for $9898 or $8080 or the like).