Extra Ram

[Reapex]

As a lot of people know, there is a lot of RAM on the actual TI-84/SE.
But there is only 24kb that are actually usable.

Is it possible to modify the OS so that there is support for all the RAM?

[DarkerLine]

Possible, of course. Although with the amount of changes required I wouldn't really consider it "modifying" so much as "totally rewrite everything about the way variables are stored and accessed". And then it will totally wreck most assembly programs, so it's not worth it. Not to mention I think it's illegal.

Now if you wrote your own OS it would certainly be a good idea to provide OS support for that extra ram from the start... but that is a different story.

For now the best thing to do with the extra RAM is to have assembly programs use it (the way OmniCalc does with a few of its features, for instance) and keep the OS out of the picture.

[ztrumpet]

[DarkerLine]

You're modifying the OS which is copyrighted software, the license of which does not allow you to modify it.

[panyan]

[Graphmastur]

It doesn't matter if you have the skills to do it. You are talking about rewriting a calculators OS to simply get a little bit more ram. It is simply not worth it, and anyone who does have the expertise will probably say that it is simply not worth it.

[simplethinker]

[panyan]

[DarkerLine]

The "modification" required to use the extra RAM would be complicated enough that rewriting would be easier. I mean, for one thing, you can't even address all 128 KB of it with a single 16-bit pointer.

The best way I see of handling the problems is to split the RAM into four 2-page parts, with the VAT duplicated in each one, and have the code for variable-lookup routines like _ChkFindSym switch in the appropriate part. This still has the disadvantage of breaking assembly programs that look variables up in the VAT on their own (and wouldn't know to switch out the RAM) or that use more than one variable at once (there is no guarantee that they'd be in the same part). Also, a sort of "defragmenting" would be required: you might have 6000 bytes of RAM available, but with only 1500 bytes in each part, and be unable to allocate memory for a 2000-byte variable. This is in contrast to the current setup, where by shifting all the variables back, all the free RAM can end up in one location. Also, as a price for making most of the OS think that everything is working normally, you'd have to allocate RAM four times for certain things, and end up with maybe 96 KB of RAM, as opposed to the 128 KB we want (still more than 24, though).

The real way of doing such things is to have a 128KB virtual address space that assembly programs (and most of the OS) think is physical RAM, and use 9-bit pointers to address it. Then, every time they want to access that memory, they call a paging routine that converts the virtual pointer to an actual address in actual RAM, switches in the appropriate page, and hands that back to the caller. There are two problems with doing this. First, the OS currently doesn't work anywhere close to this. Second, this sort of thing is usually partly done through hardware, and on a calculator it would 1. be slow and 2. be stupid (no longer can you use actual LD instructions with actual pointers).

[panyan]

^thats a shame

[brandonw]

[calc84maniac]

Well, it's stupid if we're going to have any sort of compatibility with existing programs.

[DarkerLine]

Actually, that might not be so bad. All you need to do is add a syscall type of thing wherever there's an instruction changing or jumping to a memory address. That sort of thing could be automated: let the OS know it's trying to emulate TIOS and it goes through the program checking for such instructions and modifies as necessary. There is some nastiness here: you don't want to end up changing the length of the program (since that messes even more stuff up) and you don't want to accidentally overwrite data that just happened to look like a ld (hl), a opcode.

So here's one way to do it: whenever you find one of these bytes, replace it with something like rst 28h or what have you. But also keep a buffer where you record the point in the program at which this happened, and the byte that was there before. You'll also need to replace every opcode representing a command that uses an immediate value, for reasons I'll get to. Do this in the same way, why not. You might as well record all actual uses of rst 28h in the buffer, for the sake of completeness.

When the program is running, every time it would normally hit a command that accesses memory, it would hit an rst 28h command, and so some OS routine gets called. The OS knows we're emulating a TIOS program, it knows the previous value of the program counter, and it checks the buffer used above (do this in log time). Sure enough: that rst command was replacing some different command, and we know what it was. So do all the virtual memory mojo and emulate the command that was there, then return control to the program.

So what if what we replaced with rst 28h was actually a piece of data? Not to worry: accessing data is done entirely through the OS anyway. So if the OS is asked to retrieve a byte, it can check if it's $EF (the hex for rst 28h) and located in the program space. If it is, the original data was backed up, so we search through the buffer and retrieve the original value of the byte instead. Same for writing to the data.

Finally, the immediate value problem, which is that if you had a ld a, $7E (fairly innocent, right?) the $7E, which happens to be the opcode for a memory access, will get replaced by $EF. Which is why we do the syscall mojo for commands that take immediate values as well. In this case, the OS will see that it's supposed to emulate a ld a, XX and check what the value of XX was, which it will have to look up.

This is obviously slower than running the program in TIOS would be, but this might only matter only if the program was doing precisely-timed greyscale or something. Anyway, a lot of this you'd have to do anyway, since your new OS probably wouldn't keep a graph buffer at $9340 or have conveniently-placed safe RAM at the right locations: when emulating a TIOS program, you'd have to catch accesses to those on the fly. I'm fairly sure this method is robust against almost anything, including relative jumps, jump tables, and even most instance of SMC. The only problem is if an innocent opcode like nop got modified into a memory-accessing one, but you could catch that too if you tried.

I still say that this would be a stupid thing to do in the original situation: it's appropriate for a completely different OS which wants to keep some of the functionality of the old. A modification would want to keep things going much the same way that they were, which the other method accomplishes with more flair.

[brandonw]

[FloppusMaximus]

You know, that's a really interesting idea. There are a lot of other things you could do with the ability to quickly and temporarily patch page 0. For one thing, you could emulate any of the other Z80 calculators (and perhaps other Z80 devices) in near-real time. Maybe the Nspire isn't quite as worthless as I thought.

[Graphmastur]

Ya know, I just thought of something. If you where to add "extra ram" to it, by whatever means necessary, you could simply have a function that loads in a particular page or section of it. That way, all user memory would be at page 1, or the first X bytes in memory, and a simple command would change that page. It would only require a semi-minor OS patch, but all asm programs would work fine, and if you where to do this as a call included in your asm program, you could have it say that this OS is not patched, and therefore, the asm program will use memory in a different way, or simply will not work. An interesting idea though. The sector idea would allow normal programs to be run, but allow "special" programs to access even more memory. The only problems that I can foresee are having variables overlap memory, which shouldn't be too bad of a problem, and having a vat issue. Both of those things can be solved if each sector had it's own VAT, but I don't know if that's possible.

[AnneDayton]

thank you so much for the post....