Yep, with the 83+/84+/SE models, there is a delay that is usually not constant. Even on my newer calculators that often write immediately (so have a much tinier delay), occasionally the delay bumps from <12 clock cycles up to around 40. This happens sporadically but seems to happen every few hundred writes. There are times when you can be fairly certain that you have enough of a delay, though, and for some graphics routines, I like to interleave the algorithm with the LCD updates (so essentially compute the new value of the byte, then write the updated byte to RAM and then the LCD). If the operations take a long time, to compute, this can save up to about 35000 t-states at 6MHz.

As an example, say it takes 100 t-states to transform a byte into its updated value. It takes about 45000 t-states to update the LCD on a typical calculator at 6MHz, (longer at 15MHz). So to change the whole LCD buffer, it would take about 76800+45000 t-states per frame or about 120000 t-states (50FPS). By interleaving the routines, you can use the transformation time of 100 t-states as a long enough delay between LCD writes and shave off about 35000 t-states of wasted cycles. This updates the LCD about every 87000 t-states or about 69FPS.

An advantage to this is more consistent timings for LCD updates. I usually only do this when I know that the the byte conversions take much longer than the typical needed delay (I interleave routines in some of the fire animation, plasma animation, some cellular automata programs and a few others that I have written to boost performance).