### Author Topic: Play it safe with the Ti-83+/Ti-84+ Screen  (Read 11567 times)

0 Members and 1 Guest are viewing this topic.

#### Hot_Dog

• If you can't find a cat, look for its tail.
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2966
• Rating: +445/-10
##### Play it safe with the Ti-83+/Ti-84+ Screen
« 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.

« Last Edit: December 28, 2011, 08:04:24 pm by Hot_Dog »
There are people who can speak two languages, and they are called bilingual.  There are people who speak three languages and are therefore trilingual.  Then there are people who speak one language, and these people are called Americans.

#### ralphdspam

• Posts: 841
• Rating: +38/-1
• My name is actually Matt.
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #1 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?
ld a, 0
ld a, a

#### Hot_Dog

• If you can't find a cat, look for its tail.
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2966
• Rating: +445/-10
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #2 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.
There are people who can speak two languages, and they are called bilingual.  There are people who speak three languages and are therefore trilingual.  Then there are people who speak one language, and these people are called Americans.

#### Xeda112358

• they/them
• Moderator
• LV12 Extreme Poster (Next: 5000)
• Posts: 4657
• Rating: +718/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #3 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).

#### ralphdspam

• Posts: 841
• Rating: +38/-1
• My name is actually Matt.
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #4 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.
« Last Edit: December 28, 2011, 11:02:15 pm by ralphdspam »
ld a, 0
ld a, a

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55847
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #5 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 I believe this is what happen with Axe when using grayscale in 15 MHz mode, right?
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### ralphdspam

• Posts: 841
• Rating: +38/-1
• My name is actually Matt.
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #6 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.
ld a, 0
ld a, a

#### tpt1234567890

• LV3 Member (Next: 100)
• Posts: 45
• Rating: +0/-0
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #7 on: October 28, 2013, 11:46:26 pm »

#### Xeda112358

• they/them
• Moderator
• LV12 Extreme Poster (Next: 5000)
• Posts: 4657
• Rating: +718/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #8 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).

#### tpt1234567890

• LV3 Member (Next: 100)
• Posts: 45
• Rating: +0/-0
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #9 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

• LV6 Super Member (Next: 500)
• Posts: 317
• Rating: +45/-0
##### Re: Play it safe with the Ti-83+/Ti-84+ Screen
« Reply #10 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).
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. #### Xeda112358 • they/them • Moderator • LV12 Extreme Poster (Next: 5000) • Posts: 4657 • Rating: +718/-6 • Calc-u-lator, do doo doo do do do. ##### Re: Play it safe with the Ti-83+/Ti-84+ Screen « Reply #11 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 .__. #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 317 • Rating: +45/-0 ##### Re: Play it safe with the Ti-83+/Ti-84+ Screen « Reply #12 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).
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...