QuoteBegin-Sonata+12 Apr, 2007, 11:58-->QUOTE (Sonata @ 12 Apr, 2007, 11:58) |
Definately. Great for BASIC RPGs when you need more memory. Could you store programs in there? Theoretically Id say yes... |
You would be able to store programs, but not run them directly from "ExRAM".
Also, I was thinking of keeping track of the last address allocated in memory, so that allocation and deallocation would run faster by moving only what is needed. That is with the first TI-OS style memory allocation method. I still haven't developed anything for the second scheme, so that's still iffy.
I'm still planning this thing out on paper, since it wouldn't be the easiest thing to debug. Know that I can't use PTI to emulate this since PTI doesn't have support for the memory I'm trying to use, so development will naturally be slower than if I had an emulator that would work with this.
Any suggestions for commands that might be useful for interfacing with this move-only filesystem program? Maybe filesystem ideas?
So far, these are the specifics of the idea:
In addition to ROM pages 0 thru 7F (logically), there are RAM pages 0 thru 7, addressable as-is on port 5, or addressable through port 6 as $80 thru $87. Because of logic simplicity and the fact that the TI-OS on the TI-84 series uses RAM page 2 (for USB protocol), my program will use RAM pages 4 thru 7 and address it as if it was a single 64KB chunk. For that, I have a routine that transparently translates an address in a register (usually HL) to reflect a page and position in the $400-7FFF memory bank.
Programs are allocated from $0000 up to the end of the table, the table starts at $FFEF and grows downward. The spare 16 bytes beyond the table is reserved for filesystem variables, so they need not be stored in user RAM, and is then safe from other utilities that will use the standard saferam areas.
At the start of the table, each entry will be allocated 12 bytes per entry, irrespective of the variable's type. This is to ensure that traversing the table will happen as quickly and painlessly as possible, although a dynamic table size is certainly probable. Each entry is written backwards in memory, but each entry, shown forwards is as follows in offsets:
+0 : Data type
+1 : LSB of memory location
+2 : MSB of memory location
+3 : Reserved (possible use is a name size byte or something.
+4 to +11 : 8 bytes allocated to data's name. Null-padded.
Upon formatting this memory, one entry will be already on the table, and the variable created contains four bytes, two for its size and two for the data itself. It's name will be "!", and it serves the purpose of being a placeholder so there won't be a table with zero entries. Using the memory routines, an error will be generated if one attempts to delete "!" out of the memory.
At memory location $FFFE will reside a two-byte entry showing how much "Free RAM" there is. Although it could be calculated each time, I would like to keep it to verify the integrity of the filesystem.
At memory location $FFFC will contain a two-byte entry showing how many symbol table entries there are. This is used as a loop counter as the symbol table is traversed.
At memory location $FFFA will be the address of the last piece of data allocated in ExRAM. This value is used to calculate where the end of ExRAM is so that memory allocation and deallocation can run much more efficiently, so that they don't try to move unused memory (which would cause a massive slowdown if there was a large enough chunk between the end of the symbol table and the end of ExRAM).
More variables will be inserted into this "reserved" space as I see fit.
QuoteBegin-Super Speler+12 Apr, 2007, 16:41-->QUOTE (Super Speler @ 12 Apr, 2007, 16:41) |
How safe (or un-safe) would this be to use? |
Lots of other programs (Virtual Calc, Omnicalc, msd8x, probably others) will use this RAM as scratch space, so that would mean your data is corrupted when you try to get those variables back. You can check to make sure your data's valid, but not recover it.
But if you know you don't use those, then you're safe.
The OS also doesn't touch these RAM pages when the calculator resets, so it's a good way of keeping RAM variables after reset, too.
QuoteBegin-Jon+23 Oct, 2007, 23:31-->QUOTE (Jon @ 23 Oct, 2007, 23:31) |
cuz it's the SE and they were just too lazy to edit the TIOS to utilize those pages. the 84+(SE) OS is almost identical to the 83+(SE) OS with the exception of USB code and some minor revisions. The OS was designed to be universal, which is why it checks bit 7 of port 2 in alot of its routines. (that bit is reset for 83+ BE, set for everything else) |
More like TI was too lazy to remove the "if 83+BE, do this, otherwise do that" checks from the 84+/SE OS, and the 83+SE has no use (at the moment) for the extra RAM pages (in TI's view). It's there for future expansion, nothing else. USB later ended up being the expansion.
They can't change how the VAT's page byte works because that would break everyone's 83+ code, and they strive for compatibility between all four calculators.
QuoteBegin-DJ Omnimaga+23 Oct, 2007, 23:42-->QUOTE (DJ Omnimaga @ 23 Oct, 2007, 23:42) |
haha yeah this is kinda contradictory to the usual %) but he has a good point tho
btw is there anyone who ever managed to get a TI-73 OS to run on a 83+ or vice versa? Or a 84+ OS on a 83+SE or vice versa for that matter? |
You can put the 73 OS on an 83+ and the 83+ OS on a 73. Lots of people have put the 73 OS on an 83+ before...as far as the latter... http://brandonw.net/calcstuff/73.wmv.
Off the top of my head, I don't see why the 84+/SE OS can't run on an 83+SE, but I don't have one so I can't test.