Calculator Community > TI Z80

Play it safe with the Ti-83+/Ti-84+ Screen

<< < (2/3) > >>

DJ Omnimaga:
I remember in 2004, some 83+s had the glitched Mario/Ion LCD issue like on the 84+, but due to lack of an ALCDfix, they were screwed. However when I beta-tested xLIB APP in Feb 2005, I saw this happen on my 83+SE too, because tr1p1ea was drawing in 15 MHz mode with no delay or something :P I believe this is what happen with Axe when using grayscale in 15 MHz mode, right?

ralphdspam:

--- Quote from: DJ_O on December 28, 2011, 11:54:56 pm ---I believe this is what happen with Axe when using grayscale in 15 MHz mode, right?

--- End quote ---
Yes, you're correct. 
I've also had problems with Chips Challenge with the screen constantly scrolling.  I had to find another program that adds even more delay for 15 MHz mode.  :P

tpt1234567890:
Well, this is useful info for me! I did not know about this!

Xeda112358:
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).

tpt1234567890:

--- Quote from: Xeda112358 on October 29, 2013, 11:53:45 am ---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).

--- End quote ---

I agree to the last paragraph

Navigation

[0] Message Index

[#] Next page

[*] Previous page