Last week’s adventures with the TI-99/4A’s Graphics Programming Language revolved around relying on features of the system firmware and language runtime to easily manage expensive or time-critical tasks. This week, I’ll attack the flip side of the question: how far can we go without leaving the GROMs, and how do we accelerate it when we need to?
Last year, when I was getting a handle on the TI hardware and trying to devise a sensible programming discipline for it, one of the programs I put together to do that was a test routine for the 16-bit Xorshift PRNG that I’ve relied on for years. I didn’t really go into it at the time, though, since the code was sloppy and more just a proof-of-concept. So this week, we’ll use it as a platform to explore the boundaries between GROM and ROM, between the GPL bytecode and native machine language.
- We will generalize our original programming discipline to include the GROM.
- We will reimplement the original test program to fit purely in GROM, and then test the speed of the results.
- We will accelerate our program by reimplementing parts of it in native code, and calling out to it from the GROM bytecode.
- Last week’s music routine in pure-GROM code was kind of obnoxious—we had to copy some of our data tables into VRAM to actually use them, and we also had to restructure a bunch of code that otherwise would be unrelated. Hybrid ROM/GROM code should be able to help us here, too, so we’ll bring in the same song and play it back more conveniently than it we did last time.
Expanding Our Design Discipline
Here’s the original discipline, mostly quoted from last year’s article: