83Plus:Software:Extended RAM Manager

As of late, there's a proliferation of programs and application that use extra RAM pages. These need the extra RAM pages for data storage, however none of these bother to check to see if somebody else is using that RAM for long-term purposes. In order to prevent an insane mess from being formed from this problem, a system for managing this RAM needs to be made. This system needs to be simple but effective.

My proposal has a table of 16-byte entries that hold information about the allocated RAM. 16 bytes was chosen to make the entries to count in assembly. Each entry stores basic information about the allocated memory, as well as the name of the app or program that allocated it, and possibly an update address to be called so applications and program talk to each other about RAM. (This is needed because pointers may be in a data chunk that may need to be updated if the data is moved.) An entry looks like this:

00       01 02   03 04  05       06 07 08 09 0A 0B 0C 0D  0E 0F
RamPage  offset  size   sect ID  A  P  P     N  A  M  E   update address?

Offsets should have the two MSBs reset. If and when these addresses need to be translated into actual address, the application can do it with simple SET instructions based on wherever the application has decided to map the page into RAM. The size word may be either the end of the allocated section or the size; this will be decided upon later. (My preference is total allcoated size.) The section ID allows apps to have more than memory allocation and makes keeping track of these easy. The app name is up to eight characters long. If the name is less than that, the remaining space should be nulls. The app name should be the name exactly as it appears in the header, or for program, the VAT. The update address is an offset from the base of the app or program that may be CALLed so programs may talk to each other about allocations. This may be zero to denote that the program has no such feature. Applications that wish to have allocations that span pages must make an entry for each page they place data on. The table also begins with a master entry that looks like this:

01       01 02   03 04  05       06 07 08 09 0A 0B 0C 0D  0E 0F
87       00 3F   00 01  00       M  A  S  T  E  R  !  !   00 00

The table is required to be at least 16 entries long (256 bytes long), but it would be nice to leave it at least 32 entries long. Note that the master entry itself is a valid table entry.

At the moment, applications that use this are expected to update the table themselves. I may or may bundle this into a hook mananger. If I do, then apps will be expected to call the application for allocations.

If you feel like moving this, go ahead, find a better place for it. Feel free to de-essayify this page once some more comments have been added.