Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: Hot_Dog on April 16, 2011, 03:57:09 pm
-
For those of you annoyed by multiple-page applications, I know that some of you are probably wondering why you need to go through all this trouble when you have to write a big application. Well, here's the deal.
There's at least 32 KB of RAM (sometimes more) on the Ti-83+/Ti-84+, and there's at least 160 KB of user ROM on the calculator (again, sometimes more.) However, The Ti-83+ and Ti-84+ can work with only 64 KB of memory at a time. This can be ROM or RAM, but only up to 64 KB at once.
There are 16 KB of ROM that the calculator must ALWAYS have access to because of the operating system. So the 64 KB of memory must always include these 16 KB. That means there are only 48 KB of memory left for reading stuff all at once.
For the average user, the calculator must ALWAYS have access to 32 KB of RAM. 8 KB are needed by the operating system, and of course, 24 KB are available for the user. So 48 - 32 = 16 KB left.
That's only 16 KB left to access all the rest of the ROM on your calculator--all 160 KBs. So this is divided into ten 16 KB sections (or pages), and the calculator can only read from or write to one section at a time--IT CANNOT READ TWO SECTIONS AT ONCE! With a one page application, the calculator only needs to look at one page. But with a bigger application, there's more than 16 KB to work with, and again, the calculator can't read the whole application at once. So it needs to switch between different sections.
-
Nice explanation, Hot_Dog. It does a good job of how multi-page apps work. For those of you who need to write such big apps, I have two solutions:
1. If your apps can easily be seperated into multiple parts, split them into seperate pages. Then, stick a subroutine in your RAM that accepts a page and a jump vector, and switches to that page.
2. Place all your data on the first page along with a routine to copy it to RAM. Run that routine, then switch to the second page where your program is stored, offset by the size of the RAM copy routine.
-
Thanks a lot Hot Dog! That cleared some things out.
Nice explanation, Hot_Dog. It does a good job of how multi-page apps work. For those of you who need to write such big apps, I have two solutions:
1. If your apps can easily be seperated into multiple parts, split them into seperate pages. Then, stick a subroutine in your RAM that accepts a page and a jump vector, and switches to that page.
2. Place all your data on the first page along with a routine to copy it to RAM. Run that routine, then switch to the second page where your program is stored, offset by the size of the RAM copy routine.
I had no idea about that, nice tricks (I guess).
-
Thanks for the explanation. By the way I often read that it is hard to do page swapping, right? Is that true in all cases?
-
Nice explanation, Hot_Dog. It does a good job of how multi-page apps work. For those of you who need to write such big apps, I have two solutions:
1. If your apps can easily be seperated into multiple parts, split them into seperate pages. Then, stick a subroutine in your RAM that accepts a page and a jump vector, and switches to that page.
Isn't it also possible for an app to have its own B_CALLs?
-
That made sense after I read it enough. My brain just had a buffer overflow though.