Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's Calculator Hardware subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.

This forum is locked: you cannot post, reply to, or edit topics. Calculator Modifications => Calculator Hardware
Author Message
Reapex


Newbie


Joined: 13 Jun 2009
Posts: 7

Posted: 25 Jun 2009 04:54:40 pm    Post subject:

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?
Back to top
DarkerLine
ceci n'est pas une |


Super Elite (Last Title)


Joined: 04 Nov 2003
Posts: 8328

Posted: 25 Jun 2009 09:41:48 pm    Post subject:

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.
Back to top
ztrumpet


Active Member


Joined: 06 May 2009
Posts: 555

Posted: 26 Jun 2009 09:57:04 am    Post subject:

DarkerLine wrote:
Not to mention I think it's illegal.

Why?
Back to top
DarkerLine
ceci n'est pas une |


Super Elite (Last Title)


Joined: 04 Nov 2003
Posts: 8328

Posted: 26 Jun 2009 10:08:59 am    Post subject:

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

Last edited by Guest on 26 Jun 2009 10:09:34 am; edited 1 time in total
Back to top
panyan


Member


Joined: 29 Dec 2007
Posts: 142

Posted: 26 Jun 2009 05:04:52 pm    Post subject:

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


thats just a technicality, but is it possible (in not talking theoretically) to rewrite the OS? is it possible with todays united-ti coders or do we not have an advanced enough skill set?
Back to top
Graphmastur


Advanced Member


Joined: 25 Mar 2009
Posts: 360

Posted: 26 Jun 2009 05:09:10 pm    Post subject:

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.
Back to top
simplethinker
snjwffl


Active Member


Joined: 25 Jul 2006
Posts: 700

Posted: 26 Jun 2009 05:14:39 pm    Post subject:

panyan wrote:
thats just a technicality, but is it possible (in not talking theoretically) to rewrite the OS? is it possible with todays united-ti coders or do we not have an advanced enough skill set?

It's possible. Over the years there have been many attempts, but none of them were ever finished. The biggest problem wasn't programmer skill, but the shear magnitude of what's needed for an OS.
Back to top
panyan


Member


Joined: 29 Dec 2007
Posts: 142

Posted: 27 Jun 2009 02:15:01 am    Post subject:

simplethinker wrote:
panyan wrote:
thats just a technicality, but is it possible (in not talking theoretically) to rewrite the OS? is it possible with todays united-ti coders or do we not have an advanced enough skill set?

It's possible. Over the years there have been many attempts, but none of them were ever finished. The biggest problem wasn't programmer skill, but the shear magnitude of what's needed for an OS.


OH really? i didnt think of it like that, wouldnt it be possible then just to "modify" rather than rewrite?

*i know it is illegal, i am just asking feasibility*
Back to top
DarkerLine
ceci n'est pas une |


Super Elite (Last Title)


Joined: 04 Nov 2003
Posts: 8328

Posted: 27 Jun 2009 11:05:19 am    Post subject:

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).


Last edited by Guest on 27 Jun 2009 11:12:14 am; edited 1 time in total
Back to top
panyan


Member


Joined: 29 Dec 2007
Posts: 142

Posted: 27 Jun 2009 12:16:37 pm    Post subject:

^thats a shame Sad
Back to top
brandonw


Advanced Member


Joined: 12 Jan 2007
Posts: 455

Posted: 01 Jul 2009 08:45:47 pm    Post subject:

DarkerLine wrote:
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).


It's not all that stupid, or slow. The 86 does it and the OS contains dedicated routines like _MM_LDIR (if I remember correctly) to make things like that easier, for them and for us.
The 86 OS is a perfect example of how to properly deal with 128KB of RAM, and any attempt at an OS rewrite should take that into account.
Back to top
calc84maniac


Elite


Joined: 22 Jan 2007
Posts: 770

Posted: 01 Jul 2009 09:20:13 pm    Post subject:

Well, it's stupid if we're going to have any sort of compatibility with existing programs.
Back to top
DarkerLine
ceci n'est pas une |


Super Elite (Last Title)


Joined: 04 Nov 2003
Posts: 8328

Posted: 01 Jul 2009 10:52:26 pm    Post subject:

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.


Last edited by Guest on 05 Jul 2010 08:29:14 am; edited 1 time in total
Back to top
brandonw


Advanced Member


Joined: 12 Jan 2007
Posts: 455

Posted: 02 Jul 2009 03:17:49 pm    Post subject:

DarkerLine wrote:
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.


I think there's too much potential for instability with that, but I was going to do something similar by writing a Flash application shell that could launch programs and other applications on the Nspire, for compatibility. It would dynamically replace undocumented instructions (which reset the Nspire emulator) with "rst 00h", and then there would be an OS patch to modify the jump at 0000h to go to my code which would perform the same function through documented instructions, and then return.


Last edited by Guest on 05 Jul 2010 08:27:19 am; edited 1 time in total
Back to top
FloppusMaximus


Advanced Member


Joined: 22 Aug 2008
Posts: 472

Posted: 11 Jul 2009 12:36:08 am    Post subject:

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. Smile
Back to top
Graphmastur


Advanced Member


Joined: 25 Mar 2009
Posts: 360

Posted: 11 Jul 2009 02:33:08 pm    Post subject:

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.
Back to top
AnneDayton


Newbie


Joined: 02 Aug 2011
Posts: 2

Posted: 02 Aug 2011 10:46:40 pm    Post subject:

thank you so much for the post.... Smile
Back to top
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
    »
» View previous topic :: View next topic  
Page 1 of 1 » All times are GMT - 5 Hours

 

Advertisement