Hello,

I've been trying to add some programs to my Ti-84, and many of them have a complete distortion problem. I have tried ALCDFIX, but it never fixes the problem, and I have tried the built-in retune setting in the development version of Doors CS7, and it doesn't help either.

A list of the problematic programs:
http://tibasicdev.wikidot.com/archives:doodlejump
https://www.cemetech.net/downloads/files/715/x715
Doors CS7.2
A version of Flappy Bird
Sniper 101 and Sniper 202

I have tried emailing the creator of ALCDFIX. However, I quickly realized that the chances of them still being part of the calculator community, even having access to their email 16 years later, is pretty slim.

Is there a way to solve my problem, or should I move on?

Thank you.
A lot of these programs require updates the assembly programs themselves, as TI appears to be using a new LCD controller that doesn't respect the busy status. They could be updated manually if you have to source code, but it might not be worth the time. I think there is a "fixed" version of Doors CS 7 here: https://github.com/KermMartian/Doors_CS_7/files/4302273/dcs7.zip
MateoConLechuga wrote:
A lot of these programs require updates the assembly programs themselves, as TI appears to be using a new LCD controller that doesn't respect the busy status. They could be updated manually if you have to source code, but it might not be worth the time. I think there is a "fixed" version of Doors CS 7 here: https://github.com/KermMartian/Doors_CS_7/files/4302273/dcs7.zip


Ok, are there any calculator vendors that sell calculators without a faulty LCD, or should I bite my losses
SpundoDundo wrote:
MateoConLechuga wrote:
A lot of these programs require updates the assembly programs themselves, as TI appears to be using a new LCD controller that doesn't respect the busy status. They could be updated manually if you have to source code, but it might not be worth the time. I think there is a "fixed" version of Doors CS 7 here: https://github.com/KermMartian/Doors_CS_7/files/4302273/dcs7.zip


Ok, are there any calculator vendors that sell calculators without a faulty LCD, or should I bite my losses

The calculator isn't faulty, the software is?
MateoConLechuga wrote:
SpundoDundo wrote:
MateoConLechuga wrote:
A lot of these programs require updates the assembly programs themselves, as TI appears to be using a new LCD controller that doesn't respect the busy status. They could be updated manually if you have to source code, but it might not be worth the time. I think there is a "fixed" version of Doors CS 7 here: https://github.com/KermMartian/Doors_CS_7/files/4302273/dcs7.zip


Ok, are there any calculator vendors that sell calculators without a faulty LCD, or should I bite my losses

The calculator isn't faulty, the software is?


I was told a while back that this was caused by a lower grade LCD added to the newer calculators, and that the older types would work perfectly, is that true? Also, is there any way to fix this without changing the source code?
Then if you know that why not find an old calc on ebay???
SpundoDundo wrote:
MateoConLechuga wrote:
SpundoDundo wrote:
MateoConLechuga wrote:
A lot of these programs require updates the assembly programs themselves, as TI appears to be using a new LCD controller that doesn't respect the busy status. They could be updated manually if you have to source code, but it might not be worth the time. I think there is a "fixed" version of Doors CS 7 here: https://github.com/KermMartian/Doors_CS_7/files/4302273/dcs7.zip


Ok, are there any calculator vendors that sell calculators without a faulty LCD, or should I bite my losses

The calculator isn't faulty, the software is?


I was told a while back that this was caused by a lower grade LCD added to the newer calculators, and that the older types would work perfectly, is that true? Also, is there any way to fix this without changing the source code?


Pretty much. The CPU sends commands to a chip that controls the LCD, and the CPU can send commands to the LCD controller faster than the LCD controller can process them. Up until 2018 or so, TI's suppliers used LCD controllers that set a bit in the controller's status readout that indicated if it was able to receive a command, and assembly programs check this status bit to see if they need to keep waiting before sending more data to the LCD controller. The new LCD controllers Kinpo started using around 2018, either due to sourcing issues or cost reduction, don't use that status bit, and always report that they are ready to receive commands even if they're not. The 'fix' is to change the code to wait for a prescribed period of time (10 microseconds) before sending more data. When you're executing million(s) of instructions per second, 10 microseconds is a long time to wait, and the LCD controller often finishes much faster than that. It wastes a lot of valuable CPU time. Some assembly programs use more complicated schemes to write to the display, which allows to either make use of wasted time and/or give performance benefits. However, these rely on the LCD controller indicating that it's ready to receive more data. If it's not ready, the command is ignored, so that's why you're seeing garbled columns of screen contents; only some of the rows (arranged as 8 pixel wide columns, usually) are sent when the LCD controller finally goes back into the ready state.

There's a cutoff with hardware revision (the 1-2 letters at the end of the date code) indicating where the switchover to the new LCD controller occurred; on the TI-84 Plus, hardware revisions AD and later are affected, and possibly L-xx18D and later on the TI-83 Plus. Nearly all used calculators on eBay are old enough to contain the old LCD controller, but you can use the date code to verify this.

For the sake of gathering more data on what calculators are affected, what's your calculator's date code? (everything in the red box)
CVSoft wrote:
SpundoDundo wrote:
MateoConLechuga wrote:
SpundoDundo wrote:
MateoConLechuga wrote:
A lot of these programs require updates the assembly programs themselves, as TI appears to be using a new LCD controller that doesn't respect the busy status. They could be updated manually if you have to source code, but it might not be worth the time. I think there is a "fixed" version of Doors CS 7 here: https://github.com/KermMartian/Doors_CS_7/files/4302273/dcs7.zip


Ok, are there any calculator vendors that sell calculators without a faulty LCD, or should I bite my losses

The calculator isn't faulty, the software is?


I was told a while back that this was caused by a lower grade LCD added to the newer calculators, and that the older types would work perfectly, is that true? Also, is there any way to fix this without changing the source code?


Pretty much. The CPU sends commands to a chip that controls the LCD, and the CPU can send commands to the LCD controller faster than the LCD controller can process them. Up until 2018 or so, TI's suppliers used LCD controllers that set a bit in the controller's status readout that indicated if it was able to receive a command, and assembly programs check this status bit to see if they need to keep waiting before sending more data to the LCD controller. The new LCD controllers Kinpo started using around 2018, either due to sourcing issues or cost reduction, don't use that status bit, and always report that they are ready to receive commands even if they're not. The 'fix' is to change the code to wait for a prescribed period of time (10 microseconds) before sending more data. When you're executing million(s) of instructions per second, 10 microseconds is a long time to wait, and the LCD controller often finishes much faster than that. It wastes a lot of valuable CPU time. Some assembly programs use more complicated schemes to write to the display, which allows to either make use of wasted time and/or give performance benefits. However, these rely on the LCD controller indicating that it's ready to receive more data. If it's not ready, the command is ignored, so that's why you're seeing garbled columns of screen contents; only some of the rows (arranged as 8 pixel wide columns, usually) are sent when the LCD controller finally goes back into the ready state.

There's a cutoff with hardware revision (the 1-2 letters at the end of the date code) indicating where the switchover to the new LCD controller occurred; on the TI-84 Plus, hardware revisions AD and later are affected, and possibly L-xx18D and later on the TI-83 Plus. Nearly all used calculators on eBay are old enough to contain the old LCD controller, but you can use the date code to verify this.

For the sake of gathering more data on what calculators are affected, what's your calculator's date code? (everything in the red box)


Well I have nothing that looks similar to the thing on the black box, but ill send the closet thing: B2050280E (this was next to some Hanzi symbols)
Id: 0A2F6-FDC24-8834
Prod #: 0A-3-02-37
SpundoDundo wrote:
B2050280E


Yeah, that's a really new format that Kinpo started using; in this case, the first letter indicates the year of production (A=2019, B=2020, etc.). All of the monochrome calculators with this datecode format are affected, since the switch to this format happened after the LCD controller switch.
CVSoft wrote:
SpundoDundo wrote:
B2050280E


Yeah, that's a really new format that Kinpo started using; in this case, the first letter indicates the year of production (A=2019, B=2020, etc.). All of the monochrome calculators with this datecode format are affected, since the switch to this format happened after the LCD controller switch.


Alright, so I'm planning to start doing some heavy programming on these calculators, and I am planning to buy 2-3 new ones, where should I buy my calculators from so I don't have this problem? Also, I'm planning to buy a Ti84 Plus CE, where should I buy that also?

Thanks.
SpundoDundo wrote:
CVSoft wrote:
SpundoDundo wrote:
B2050280E


Yeah, that's a really new format that Kinpo started using; in this case, the first letter indicates the year of production (A=2019, B=2020, etc.). All of the monochrome calculators with this datecode format are affected, since the switch to this format happened after the LCD controller switch.


Alright, so I'm planning to start doing some heavy programming on these calculators, and I am planning to buy 2-3 new ones, where should I buy my calculators from so I don't have this problem? Also, I'm planning to buy a Ti84 Plus CE, where should I buy that also?

Thanks.


eBay, buy them used. Make sure the screen looks perfect (no pressure damage or missing columns, avoid calculators that aren't shown powered-on) and the date code is suitable. OS version, product ID, and whatnot don't matter. There's a lot that meet those criteria to pick from, especially at this time of year. As far as the TI-83 Plus goes, stay away from S-xxxxE through S-xxxxJ as the screen contrast is miserable, and fair market value for a TI-83 Plus is about $25-$35 total at this time of year. I don't meddle with the 84+/SE much, but pretty much all hardware revisions are equivalent (unless you don't want a [url=https://www.omnimaga.org/other-calculator-discussion-and-news/the-missing-84-extra-ram-pages-(hardware-change)/msg67744/#msg67744]TA1 ASIC[/url] for whatever reason) and the prices are higher.

There's generally no point in owning two identical calculators, so I'd recommend diversifying what models you buy (84+ with OS 2.55MP, 84+SE with OS 2.43, 83+ with OS 1.19, for example) if you're hell-bent on buying a bunch of them.

I'm getting yelled at in SAX that the LCD controller bug is a non-issue, but I feel like this thread wouldn't have been created if it weren't an issue. Just be aware that the bug doesn't come into play until control of the display is taken away from TI-OS, so it'll never be a problem in a pure TI-BASIC context or even in simple assembly language programs.

As far as the CE goes, that's a question for another member as I've never handled one. I know the community is picky about hardware revision.
For the CE, you will want to find one that has OS 5.3.1 or lower, and preferably the Revision M or later.

TI removed native assembly programming without exploits in OS 5.6.0, and Rev M offers a faster serial-based flash chip and cache.
CVSoft wrote:
SpundoDundo wrote:
CVSoft wrote:
SpundoDundo wrote:
B2050280E


Yeah, that's a really new format that Kinpo started using; in this case, the first letter indicates the year of production (A=2019, B=2020, etc.). All of the monochrome calculators with this datecode format are affected, since the switch to this format happened after the LCD controller switch.


Alright, so I'm planning to start doing some heavy programming on these calculators, and I am planning to buy 2-3 new ones, where should I buy my calculators from so I don't have this problem? Also, I'm planning to buy a Ti84 Plus CE, where should I buy that also?

Thanks.


eBay, buy them used. Make sure the screen looks perfect (no pressure damage or missing columns, avoid calculators that aren't shown powered-on) and the date code is suitable. OS version, product ID, and whatnot don't matter. There's a lot that meet those criteria to pick from, especially at this time of year. As far as the TI-83 Plus goes, stay away from S-xxxxE through S-xxxxJ as the screen contrast is miserable, and fair market value for a TI-83 Plus is about $25-$35 total at this time of year. I don't meddle with the 84+/SE much, but pretty much all hardware revisions are equivalent (unless you don't want a [url=https://www.omnimaga.org/other-calculator-discussion-and-news/the-missing-84-extra-ram-pages-(hardware-change)/msg67744/#msg67744]TA1 ASIC[/url] for whatever reason) and the prices are higher.

There's generally no point in owning two identical calculators, so I'd recommend diversifying what models you buy (84+ with OS 2.55MP, 84+SE with OS 2.43, 83+ with OS 1.19, for example) if you're hell-bent on buying a bunch of them.

I'm getting yelled at in SAX that the LCD controller bug is a non-issue, but I feel like this thread wouldn't have been created if it weren't an issue. Just be aware that the bug doesn't come into play until control of the display is taken away from TI-OS, so it'll never be a problem in a pure TI-BASIC context or even in simple assembly language programs.

As far as the CE goes, that's a question for another member as I've never handled one. I know the community is picky about hardware revision.


Oh I'm getting two Ti-84s to connect them to the internet and see if I can transfer data between them
SpundoDundo wrote:

Oh I'm getting two Ti-84s to connect them to the internet and see if I can transfer data between them


If you want to use calcnet2, DONT buy new TI-84+ models. DCS7 displays wrong and you'll never get hem connected to the bridge.
Oxiti8 wrote:
SpundoDundo wrote:

Oh I'm getting two Ti-84s to connect them to the internet and see if I can transfer data between them


If you want to use calcnet2, DONT buy new TI-84+ models. DCS7 displays wrong and you'll never get hem connected to the bridge.


Any LCD controller should be fine when using the questionably-stable Cn2 DCSB Libraries for calcnet2, but ArTICL-like solutions and things like libticables are much more robust ways to go nowadays. There's plenty of documentation on the link protocol. I've done some work with a SilverLink and python+libusb1, and TiLP uses libusb0 to talk with a SilverLink. Graylinks are quite simple (byte goes out serial port and appears on the TRS connector, and vice-versa), but won't fit in an 84+ without adapters due to the angle connector used. Blacklinks are Satan's spawn and should be avoided at all costs. ArTICL connects an Arduino directly to the calculator's I/O port, exposes methods for transferring data between the Arduino and calculator, and doesn't depend on any external TI hardware (just note that some calculators are 5V and some are 3.3V).

The route you choose really depends on your vision for the project and your programming experience, but remember that it's not super difficult to implement the link protocol yourself if you find working with third-party libraries challenging.
CVSoft wrote:
SpundoDundo wrote:
MateoConLechuga wrote:
SpundoDundo wrote:
MateoConLechuga wrote:
A lot of these programs require updates the assembly programs themselves, as TI appears to be using a new LCD controller that doesn't respect the busy status. They could be updated manually if you have to source code, but it might not be worth the time. I think there is a "fixed" version of Doors CS 7 here: https://github.com/KermMartian/Doors_CS_7/files/4302273/dcs7.zip


Ok, are there any calculator vendors that sell calculators without a faulty LCD, or should I bite my losses

The calculator isn't faulty, the software is?


I was told a while back that this was caused by a lower grade LCD added to the newer calculators, and that the older types would work perfectly, is that true? Also, is there any way to fix this without changing the source code?


Pretty much. The CPU sends commands to a chip that controls the LCD, and the CPU can send commands to the LCD controller faster than the LCD controller can process them. Up until 2018 or so, TI's suppliers used LCD controllers that set a bit in the controller's status readout that indicated if it was able to receive a command, and assembly programs check this status bit to see if they need to keep waiting before sending more data to the LCD controller. The new LCD controllers Kinpo started using around 2018, either due to sourcing issues or cost reduction, don't use that status bit, and always report that they are ready to receive commands even if they're not. The 'fix' is to change the code to wait for a prescribed period of time (10 microseconds) before sending more data. When you're executing million(s) of instructions per second, 10 microseconds is a long time to wait, and the LCD controller often finishes much faster than that. It wastes a lot of valuable CPU time. Some assembly programs use more complicated schemes to write to the display, which allows to either make use of wasted time and/or give performance benefits. However, these rely on the LCD controller indicating that it's ready to receive more data. If it's not ready, the command is ignored, so that's why you're seeing garbled columns of screen contents; only some of the rows (arranged as 8 pixel wide columns, usually) are sent when the LCD controller finally goes back into the ready state.



So it turns out that this isn't the case; like the Novatek NT7564H, these new LCD controllers are, in fact, able to be written to so quickly that the CPU (at least at 6 MHz) isn't fast enough to catch the LCD in a busy state. The command set appears to be slightly different, or at least respond differently to certain behaviors specified by the T6A04 datasheet.

I now own one of these calculators (a 2021-manufactured TI-83 Plus), and I'm working on characterizing this new behavior. Unfortunately, this means a simple LCD timing code change may not be sufficient to patch old programs.
CVSoft wrote:
I now own one of these calculators (a 2021-manufactured TI-83 Plus), and I'm working on characterizing this new behavior. Unfortunately, this means a simple LCD timing code change may not be sufficient to patch old programs.


So far, it appears that repeatedly switching between reading from the status port and writing to the data port can cause the LCD controller's internal graphics memory cursor to forget where it is and end up somewhere that should be impossible. In Doors CS, it can be traced back to iFastCopy's use of ld a,($10). At the cost of backwards compatibility, replacing that instruction with cp a \ nop (per calc84maniac) will work, as it processes instructions faster than you can send them. The correct solution is to simply burn 60 or 150 CPU cycles, depending on how fast the calculator is running, and never read the status port. I wrote a few programs to play around with this LCD controller's behavior, and developed it into a yes/no test for the new controller.


Please don't read the status port.
Quote:
I wrote a few programs to play around with this LCD controller's behavior, and developed it into a yes/no test for the new controller.
Where will you be sharing this information? I also hope you'll be adding to WikiTI ASAP.
KermMartian wrote:
Quote:
I wrote a few programs to play around with this LCD controller's behavior, and developed it into a yes/no test for the new controller.
Where will you be sharing this information? I also hope you'll be adding to WikiTI ASAP.


There's binaries, source, and limited documentation in the files I linked in this posf. I'll be updating WikiTI after dinner and before messing with Doors CS source code, particularly since the info on WikiTI isn't correct.
I'd like to check I'm interpreting what you've written correctly, since it seems like this is enough information to fix most programs (or just shells?) to work correctly on all calculators.
  • The new Novatek driver misbehaves if you poll the busy bit on port $10.
  • Every driver that's been used in a calculator meets or exceeds the 10 μs response time specified for the T6A04.
  • On 15 MHz calculators some programs traditionally misbehave because they assume the CPU runs at 6 MHz and don't have a long enough delay, since the CPU runs the same number of cycles in a shorter interval.
  • ALCDFIX and similar programs (is there something similar built into DCS? I'm not sure offhand) adjust the value of port 0x29 and possibly 0x2a to automatically insert a delay after any LCD port access.

While programs that poll the busy bit in their own LCD interface code can't be fixed without patching the programs themselves, it sounds like shells should in general always set ports 0x29 and 0x2a to values sufficient to ensure any access pattern (including back-to-back LCD accesses) will be at least 10 μs apart. This will hurt performance for programs that could otherwise be doing work in that interval, but because it's not generally possible to detect what access patterns a program might use the most pessimistic timing must be assumed.

I suppose a shell might (in its own fastcopy implementation) be able to adjust the timings to allow it to do useful work while waiting for the LCD, but that would be risky since some programs might use both a provided fastcopy and their own LCD interface code for some operations and they would misbehave unless the shell only shortened the port 0x29/0x2a delays while executing fastcopy; the overhead of that might be high enough to be not useful, but perhaps a "LCD fast mode" option could be exposed to users to allow a user to improve performance in programs that can be observed to behave correctly on a given calculator when port 0x29/0x2a delays are reduced.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement