The really old TI-83's actually used a physical Z80, coupled with some fancy memory mapping hardware to let it access all of it's "ROM". While this doesn't really apply to our example since the memory isn't Flash, the concept is similar. TI just found cheaper ways to implement these schemes. They kinda ... stuck with us.

I figure that this information is only valid for your good ol' Ti-73's, TI-83+/84+(SE)s and perhaps a select few other calculators. You'd have to ask around for how the Ti-89 calcs work, though I think they work in a similar way. The Nspire is completely different and ... well. I'm not the person to ask.

I don't know whether they used a physical Z80 or not, but the TI-85 and 86 also used similar paging schemes. The 85, IIRC, used paged ROM (RAM was just 32K and not paged), and the 86 used paged ROM and RAM. The 81, being the first TI graphing calculator and very primitive compared to its successors, had no paging at all—it was just straight 32K ROM + 8K RAM, IIRC.

I'm not for sure how the 68K calcs are mapped, but I believe that the whole memory map (RAM, ROM, and ports) is “flat” without paging since the address size is much larger. (At least, I didn't have to deal with bank switching when writing programs like Flash Archive Undelete, which scans the whole archive portion of flash, so that at least isn't bank-switched). Someone more knowledgeable would have to answer this for sure, though.

I just noticed something: SIX SOFT KEYS!  Goodness me, S.A.D. would have been awesome for this.  That lack of a 6th soft-key on the Ti-83+ is really handicapping my soft-key menus.

I didn't notice that. So it's kind of like the HP calcs, which also have six soft keys.

One thing that would have been cool is if they had arranged the alpha keys like the HPs do, so that you can still enter numbers without switching out of alpha-lock.

ticalc.org should be fixed now. Evidently a software update caused the HTML-updating service to somehow not restart automatically like it should have.

My guess is that memcpy is smaller or faster in your program if you're absolutely sure that the source and destination regions to be copied will never overlap in memory (such as when you have two separate buffers for source and destination). If they can overlap (like when you insert/delete bytes in the same buffer and want to shift everything after up or down), then memmove should be used instead.

Happy birthday to our dear Ticalc.org file archiver TravisE!

Thanks, guys! (now that I finally managed to come across this thread )

I also remember the days when I used to use Goto all the time. I also ended up having to figure out myself what was causing the TI-BASIC “memory” error on the Z80 calcs. What's ironic is that it actually had the reason listed right in my manuals where the error message was explained, but I ignored it because I misunderstood and thought it was wrong—I thought it meant that any time you use Goto in a loop, it would immediately give that error, which of course it doesn't. The fact that it has to be done repeatedly before that happens and the manual didn't make this fact clear caused it to be a long time before I finally figured it out.

This was also around my old DOS QBasic programming days, and I remember causing memory leaks at first by using Gotos in terrible places in my code on that platform, too. Later, I discovered how to add debugging code that would print the amount of memory remaining and was shocked watching it decrease steadily the whole time the program ran. In QBasic, it was rarely a real issue, though, because there's so much more memory available on a PC compared to a calc.

Over time, as I read programming books and experimented with different styles, I gradually used Goto less and less. These days, I pretty much never use it at all—it's become natural for me to write code without using it.

There is just one exception currently—in recent C programs (i.e., TIGCC) I do make very occasional use of Goto when dealing with dynamic memory allocation, which is otherwise a ridiculous pain when it comes time to properly free up that memory (especially on the 68K calcs, where nothing cleans up after you and the memory is lost forever until RAM is reset!). Without Goto, I would have to repeat the cleanup code many times everywhere, wasting space and giving countless opportunities for hard-to-reproduce bugs/memory leaks to hide (and making the code actually harder to read). In this particular case, I think Goto is okay because the alternative is far worse.

So I consider Goto as being kind of like alcohol. There's nothing wrong with it as long as you use it responsibly and don't get carried away.

This program looks pretty cool. I've made a note to myself to take a closer look at it when I get a chance.

I've found getkey useful many times for non-game programs that need a more advanced UI than just menus and input lines could provide. But it is interesting that the older Z80 calc manuals I have actually suggest video games as being an application for the getkey function.

Another thing I always thought was kind of funny was how the function reference in the back of my TI-89 manuals has an example for the NewFold command (which creates new folders) where it creates a new folder called ‘games’.

So TI was definitely aware of the idea of playing games on the calc and knowingly allowed it on all those models. But it seems that the Nspire is the one model that they don't want games and third-party programs to be available on.