Question about memory

[CobyWalker]

[tr1p1ea]

You can put data in certain RAM areas, but yeah you do have to be careful. There are special places known affectionately as 'saferam' areas. Here is some info on them courtesy of MV:

[Liazon]

if you're writing an app, there's also the _insertmem _delmem trick. just insert the mem at $9d95, which is pretty convenient.

[FloppusMaximus]

Well, that works, but you can't just call InsertMem, you also have to check for free memory, and set up a putaway handler to clean up when you're done. Memory leaks are no fun.

I tend to prefer simply using the free space between the FPS and OPS, or placing data in the FPS itself if I need to be able to do math or variable manipulation.

I'd also like to add to what Michael wrote, not to take anything away from his brilliance:

- appData is the area used for ONSCRPT and OFFSCRPT; you must disable scripts if you want to use this area and you use GetKey in your app.

- ramCode is used by a lot of system routines. If you're using more than the most basic B_CALLs in your app, expect ramCode to be overwritten often.

- cmdShadow, of course, is the homescreen. If you use it, overwrite it with spaces and set (cmdShadCur) to 0,0 when you're done.

- tmpSwapArea is a funny one. I'm pretty sure someone at TI made a mistake at some point, and it was intended to be only 232 bytes, not 323. With that said, pretty much the entire area from 8251 to 83E8 is probably about as safe to use as is tempSwapArea proper (i.e., not during archiving, linking, BASIC interpreting, or other advanced OS functions.)

- Michael didn't mention what I'm sure is the most commonly used "saferam" area - plotSScreen, the graph buffer. Of course you may be using it for a screen buffer of some kind, but it's another 768 bytes that shouldn't be ignored.

[sgm]

You can also just plop a bunch of bytes down into your program as a sort of BSS section. Which is pretty much like using the free RAM area anyway, but less clean up is involved.

[calc84maniac]

[DarkerLine]

[FloppusMaximus]

Whereas if you are using a shell and you don't need to save the data, you have to clear it when you're done, or the shell will detect it as write-back, resulting in unnecessary re-archiving of the program.

I wouldn't recommend using that method for non-write-back data. If it's just a few variables, you should be able to put them in saferam. If it's a large buffer, then even adding the necessary code to allocate it dynamically, the program will still be smaller in the end.

As a side note, the TI-83 had a feature vaguely similar to TSE, whereby the OS would automatically allocate an extra (uninitialized) data segment at the end of the program code. Of course, that was only for unsquished programs... talk about wasting memory

[asdf]

[Liazon]

[fourchanb]

I always make temporary appvars, then use these as safe RAM areas. The downside is that you never know where they will show up, but that is usually not a problem with buffers and such.

[Iambian]

I recall that there was a special romcall that needed to be used if one were to use all 1087 bytes starting at appData if a FlashAPP needed to quit afterward.

Since I'm trying to write such an application, I'd appreciate it if someone could tell me what that is (if even necessary), since I've grown frustrated searching this forum and Detached Solution's forums, not to mention several fruitless Google searches.

( I don't have access to the IRC logs that would contain the information I'm looking for. )

[FloppusMaximus]

To use 1087 (decimal, I assume) bytes from 8000 to 843F? I would assume you can't. That includes baseAppBrTab and arcInfo. (While the OS presumably does have code to regenerate them when the calculator is reset, and for all I know there's even a B_CALL to do so, it sounds like a bad idea. For one thing, isn't baseAppBrTab needed to look up the app header whenever a hook is called?) It also includes ramCode, which (as I noted above) gets overwritten all the time.

ONSCRPT and OFFSCRPT are appvars that you can create which will be run when the OS turns the calculator on and off. ONSCRPT is enabled by 0,(iy+33h) and OFFSCRPT by 1,(iy+33h). ONSCRPT is run only when waking up from APD; OFFSCRPT is run both after 2nd+Off and before APD. In both cases the OS copies the contents of the appvar to 8001 (if I remember correctly) and runs it. Thus, if APD is enabled, there's a possiblity that these scripts could be run at any time. (This isn't just a theoretical question; TI's Start-Up app uses OFFSCRPT, as does Krolypto, so many users will have these scripts installed and enabled.)

Anyway, if you save, clear, and restore (with a putaway handler if necessary) those two flags, using appData should be just fine. The area is also used for cryptography stuff, which most apps will never run into. I use appData fairly often -- it's very convenient for a lookup table.

Inserting memory at the end of your program: I think there's a way to do this safely; I don't remember how, but I believe the OS stores the size of the assembly program somewhere, so you can find that value and update it. Needless to say it won't work if you're running in a shell; every shell handles program loading differently.

[brandonw]

[FloppusMaximus]

In other words, if you use your own ISR and never use any OS code, ever.

[Iambian]

Thanks for the info, brandonw. As far as the code is going, I will be using my own ISR and I won't be using using any OS code for the duration of what I'll be needing the buffer for, save for that one romcall to put it all back together when I'm finished.

btw, this application is going towards a game that I haven't really announced anywhere but on a channel on IRC.

[brandonw]

[FloppusMaximus]

Off the top of my head, the ISR can call the cursor hook, the USB hook, and can APD. Even if you turn all those things off, you're still betting that TI never adds any new functionality to the ISR.