I see, mmk. That works for me. I can't think of any others, atm.

No, nor me. So is that one memory area enough for all your safeRAM and temporary routine storage, or will you also be using some of the other safeRAM areas?

I'll probably be using the 9D95 area. That's 8011 bytes, right?

If you're running under the TI-OS, you have to InsertMem at $9D95 in order to use that memory, since when no non-Apps are running, user programs may exist starting at $9D95, and you certainly don't want to overwrite them! _InsertMem will push them up to higher memory, but you of course need to use _FreeRAM to see exactly how much memory you can insert and use.

Oh, so that's what insertMem does. I've never really understood that. Thanks for the advice. Any advice on how to instantly clean up the stack? I'm think about storing the original SP somewhere, and when the program finishes, instead of trying to figure out how many pushes it did, just set it back to the stored SP and exit. Should work, no?

EDIT: Also, how exactly do I do appvars. If I open one up (correct term?), should I then use insertmem? I know I have to find it, but I want it in archive, and then a temporary copy moved to ram. That way, it doesn't save unless you archive it back. (Granted the app would do that when you hit save)

Yes, and it's extensively used. Doors CS uses that to escape from awkward failure situations in the GUI, in Celtic III's argument-parsing, and much more. Regarding your question on IRC, _InsertMem affects pictures, AppVars, programs; basically anything stored in RAM gets moved.

I edited my post above, btw, Kerm.

Also, update, I got displaying a picture to work with a variable buffer location. I didn't have a picture ready to display, so I just pointed the buffer to $4000 in my app, and did this:

So far, I have page swapping and now drawing routines done off-page. e.g, in ram. Next up is to try and work on the appvar.

Very nice. For what it's worth, for DCS ASM coders, FastCopyB from the MOS libs acts like iFastCopy with hl=buffer.

Yeah, I just did safecopy, but instead of "ld hl,PlotScreen", I did:
ld hl,(CurGrfBuf)
or something to that effect.

Anyway, I noticed Safecopy used $70ED, which is apparently in f,(c). Now that works on my calculator, but will it work for all the Z80 calcs?

I'm pretty sure that that's an unofficial instruction that will crash on the TI-Nspire. Where did you get that SafeCopy routine from?

It is this one:
http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:Fastcopy#Safe_Copy

Yeah, that. Is there a way to re-write it? I'm not too good with LCD commands, and such. Although, if it only doesn't work on an emulator, I'm okay with it.

Also, can you answer this from above?:
Also, how exactly do I do appvars. If I open one up (correct term?), should I then use insertmem? I know I have to find it, but I want it in archive, and then a temporary copy moved to ram. That way, it doesn't save unless you archive it back. (Granted the app would do that when you hit save)

Emulators have no problems with undocumented instructions in my experiences, because emulator writers are, in general, not stupid. However, if you're TI, and you decide to write an emulator for your Nspire, it turns out you're not very intelligent, and don't bother including widely-used undocumented instructions.

You don't really open up AppVars at all; they just exist. InsertMem works without any sort of "opening up", but you do need to manually update the size field of the appvar once you perform the InsertMem operation so that future memory operations will work properly.

So this is my code. It's supposed to go from the 1st to the 28 row. (Starting with 0) and set a random bit. But it's not random! Please advise. Also, a good generic 2 bytes random routine would be well thanked.

EDIT: I changed this to use irandom, and will make corrections later. The randomness is fixed.

Code: