It's TI's display routine or the LCD or something like that. It's not the command itself though. Blame TI (I could be wrong, though I feel like like that is what the general consensus is )

why does dispgraph have too be so slow?

Is there not anyway to have the code continue to run while its updating?

It would require interrupts because the z80 doesn't do parallel processing. Think about it: every pixel on the LCD has to be updated. That's 6144 pixels. That's a lot of data to transfer for the z80. Using interrupts would slow down your code, increase the code size a lot, and not display as quickly.

That, and the LCD driver is slow.

To quote Sean McLaughlin from Day 26 of his Learn TI-83 Plus Assembly in 28 Days:

The TI-85 and higher-number calculators have a memory mapped screen. That means a section of the calculator's RAM that holds a bit image of the screen is constantly being monitored. Whenever a byte in this area is changed, the display changes immediately. It is also possible to change the RAM area the driver looks at with a single port output. By switching the buffer location back and forth rapidly, you could create Game Boy-style flickerless 4- or 8-level grayscale.
Unfortunately, the "crap series" (everything lower than a TI-85) uses a driver that stores the screen image in its own RAM. In order to change the display, you have to send each byte in the image to the driver. It is also a very slow driver which needs a delay every time it is accessed.

The next line, although not applicable to answering your question, is my favorite line in the whole tutorial.

Hopefully you are sufficiently depressed now, so let's look at how to make the Toshiba T6A04 (that's the name of the driver) our bitch.

I think on newer 89s it's not as great, though. For the 83+ you have to not update the screen too often. If a game of yours requires a fast speed, you may be forced to update the LCD only every 2 or 3 frames. In Axe tunnel, the faster speed modes are done by updating the LCD less often, even though stuff is drawn on the buffer. That's how slow DispGraph is.

Do you mean GRAPH?

Quote from: Runer112 on December 04, 2010, 08:34:33 pm

The next line, although not applicable to answering your question, is my favorite line in the whole tutorial.

Quote

Hopefully you are sufficiently depressed now, so let's look at how to make the Toshiba T6A04 (that's the name of the driver) our bitch.

Mine too.

I haven't even read the tutorial and that's my favorite line

hum... just a thought here, but would it be possible to make a graphing screen that would still allow allow the user to use trace, but only update after all functions have been drawn.
I am assuming this would work because it says the screen info is stored into the calculators ram.

Trace works by computing the function at every point that would be used during graphing. So it would take at least as long to trace as to graph the function.