# Omnimaga

## Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Hot_Dog on December 28, 2011, 07:45:11 pm

Title: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: Hot_Dog on December 28, 2011, 07:45:11 pm
If you're programming in ASM, you probably know that the Ti-83+ screen is slow, and requires time between each byte of data that you output to it.  If you draw to the screen too fast, your game will have issues and go berserk.

There are two ways to take care of this.  One way is to read port \$10 after you output a byte to the screen.  If bit 7 of port \$10 is equal to 1, the LCD is busy, and it's dangerous to put a byte to the screen.  If bit 7 equals 0, you can output another byte to the screen.

The other method is to know the maximum amount of time it takes the screen to be ready, and then you can wait that long after displaying one byte of data before you output the next byte.  This method is faster than the first one, but it's not as safe (read on!)

When the Ti-83+ first came out, people knew that it takes a maximum of 65 T-States for the screen to be ready after a game outputs a byte.  (~165 on the Ti-83+ SE and the Ti-84+)  Many games, therefore, used the second method for timing because it would produce faster games.  However, many of the new calculators have screens that take longer than 65 / 165 T-states to display information.  So the old games created for old calculators display graphics too fast to work with the new screens.

If you want to program a game that is guranteed to work on all Ti-83+ calculators--then, now and will be--you should use the first method.  It may be slower, but it's fool-proof.  You can always try to time your game with these new screens, but it doesn't mean that your game will work well with future calculators.

Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: ralphdspam on December 28, 2011, 10:33:23 pm
Doesn't alcdfix fix this problem by adding delay to port access to the screen, or is there a new problem?
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: Hot_Dog on December 28, 2011, 10:39:52 pm
Doesn't alcdfix fix this problem by adding delay to port access to the screen, or is there a new problem?

That doesn't work on Ti-83+ BE calculators.
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: Xeda112358 on December 28, 2011, 10:47:31 pm
Hmm, how does alcdfix work? And I know Donkey Kong did not work for my TI-84+, but worked fine for the TI-84+SE (even after I used alcdfix).
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: ralphdspam on December 28, 2011, 10:55:57 pm
That doesn't work on Ti-83+ BE calculators.
Wait...
So now they're making 83+ BE calcs but with worse screen drivers?  Wow...

Hmm, how does alcdfix work? And I know Donkey Kong did not work for my TI-84+, but worked fine for the TI-84+SE (even after I used alcdfix).
There are a couple of ports in the SE hardware that control the amount of clocks the graphics driver stops the CPU.   (\$29 - \$2F)   Alcdfix changes the values in these ports (I'm not sure which ones) so there is enough delay for the driver to catch up.
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: DJ Omnimaga on December 28, 2011, 11:54:56 pm
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?
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: ralphdspam on December 29, 2011, 02:19:16 am
I believe this is what happen with Axe when using grayscale in 15 MHz mode, right?
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
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: tpt1234567890 on October 28, 2013, 11:46:26 pm
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: 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).
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: tpt1234567890 on October 29, 2013, 05:09:12 pm
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).

I agree to the last paragraph
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: the_mad_joob on August 27, 2020, 05:10:42 am
Hello there.

Apparently, the method of checking bit 7 of port \$10 isn't reliable on all hardwares anymore =[
That means, only the following methods remain :

# busy state check : all models except TI-83+ non-SE - CPU speeds 1|2|3 only
Check bit 1 of port \$02 (0=busy|1=ready).
Note that though it doesn't mean the LCD is actually ready, the bit will always be set on the TI-83+ non-SE, or if using CPU speed 0.
The busy state duration is defined through port \$2F.

# automatic delay : all models except TI-83+ non-SE
The delay duration is defined through ports \$29|\$2A|\$2B|\$2C (CPU speeds 0|1|2|3 respectively).

# manual delay : all models
Actually the only remaining method for TI-83+ non-SE.
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: Xeda112358 on August 27, 2020, 06:33:39 am
Oh, thank you for adding this update! It's annoying that these new calcs don't work the same .__.
Title: Re: Play it safe with the Ti-83+/Ti-84+ Screen
Post by: the_mad_joob on August 27, 2020, 09:18:20 am
Oh, thank you for adding this update! It's annoying that these new calcs don't work the same .__.
Definitely.
TI probably invested in new LCDs or controllers, cheaper than the ones we had back in the days.
However, no matter which new hardware TI decides to use, it can't be slower than the delays used by the OS, otherwise they would need to update it.
Following such logic, i inspected the TI-OS a bit, in order to know which minimum delays it uses, as a reference :

# TI-83+BE
# TI-83+SE @ CPU speed 0
-> 73 T-states from lcd_busy on last compatible OS (1.19)

# TI-84+BE @ CPU speed 0
# TI-84+SE @ CPU speed 0
-> 123 T-states from lcd_busy on last compatible OS (2.55)
That value is probably higher than necessary, because the routine strangely includes what appears to be an additional USB-related delay of 50 T-states.

# TI-83+SE @ CPU speed 1|2|3
-> 221 T-states
That's 176 guarenteed by port \$2F, and 45 from lcd_busy on last compatible OS (1.19).
I'm not sure how far the time spent by the routine should be taken seriously though.

# TI-84+BE @ CPU speed 1|2|3
# TI-84+SE @ CPU speed 1|2|3
-> 335 T-states
That's 240 guarenteed by port \$2F, and 95 from lcd_busy on last compatible OS (2.55).
Again, the time spent by the routine is probably a total waste.
What's for sure is that by setting port \$2F that way, TI definitely anticipated new hardware...