Spare RAM

[Iambian]

For the TI-83 Plus SE and all TI-84 Plus models.
For some of the larger BASIC projects that needs more RAM than they currently have and does not want to tax Flash by constantly swapping variables between the two areas, I want to design a utility that will swap variables between User RAM into a formatted 64K chunk of the extra RAM that exists on these calculators.

I am aware that the USB drivers use RAM page 2. Since I am using RAM page 4 thru 7, it shouldn't make a difference. I am also aware that other programs and applications would trash this memory without regard to what is actually there, so I'm hoping that the person using this utility in their game won't use other programs or apps that would trash this RAM (Omnicalc). For that reason, a checking feature will be implemented to determine if the RAM has been corrupted. I am also aware that the TI-OS won't be able to use variables in this extra RAM area; that's why there'll be a swapping command.

This utility should only be used in an environment where a single project is using this RAM area, where it can then be cleaned out after the project (possibly a large game) has finished executing. I am aware of all the risks associated with allowing this thing to remain persistent in memory, especially if the user doesn't know of the dangers regarding using this area as "permanent storage". As I said before, I'm also aware of conflicts with other programs and apps.

Having said all the bad stuff, do you think such a "project" would be worth pursuing, however simple it is to do? If so, any suggestions beyond planned "move variables to and from the 64K chunk of RAM, checking the RAM, and formatting/repairing the filesystem" ?

[DigiTan]

Hmmmm.. It should be interesting. I'm not up to speed on 83+ saferams and such. Are you sure those are RAM pages and not ROM pages?

[AlienCC]

Where have I seen this idea implemented before...oh yeah, here it is.

I say go for it.

--AlienCC

[Iambian]

During the planning stage, I've run into a problem regarding memory allocation. I've tried to implement memory allocation similar to what the TI-OS uses, but I've noted that (figuring CC counts) under low memory conditions, allocating or deallocating any memory can take upward to 1.5 seconds per action. I would consider this unacceptable, especially to the end user, but would it still be okay to the BASIC developer?

If not, then I could try changing my filesystem scheme to address chunks of memory (256 bytes or so) instead of allocating memory on a per-byte basis (as the TI-OS does). I understand that this would cause, at best, inefficient usage of this memory, but I also know that dealing with 256 chunks of 256 would be far faster, especially if I allowed and accounted for fragmentation.

What are your thoughts for a filesystem? Also keep in mind that this project isn't designed to allow people to do all the stuff the calculator can do directly from this chunk of RAM. It is simply going to be used to store away variables and programs in, as a quick and temporary alternative to archiving.

[luby]