for your next edition of "TI's constantly been smoking crack since the 80s and has no intention of ever stopping":

the TI-8x calculators have a hardware buffer and an OS-provided buffer for screen data, effectively being an "immediate" buffer in hardware, to be displayed next VBlank, and a "slower" buffer, being what's copied to the "immediate" buffer when the OS decides it's time to update the screen. All well and good, maybe a little weirdly done but all in all makes sense. (You can even define a third buffer in RAM if you need to triple-buffer your shit.)

The problem arises when you use TI-BASIC and try to draw to the screen:
If you do something like, say, draw a circle, you'll notice that it's visibly drawn to the screen one pixel at a time. However, looking through what bits of the SDK I can find, the OS' "draw circle" assembly routine *doesn't update the immediate buffer!*

This means that, in TI-BASIC, the "draw circle" routine doesn't use the ACTUAL circle-drawing routine the OS provides, but instead individually calculates and plots a pixel, then updates the hardware buffer (an ENTIRE 768 bytes are copied EVERY TIME) and waits for VBlank to pass before repeating for the next one. In other words, it's deliberately slow as fuck.

Why? All the drawing commands, outside of like 2 or 3, do this. Why would you deliberately slow down the process of drawing to the screen on a system that you KNEW would be popular for people to code on???