Tari wrote:
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.


Personally I'm pretty sure the wonky LCD controller in the new calculators is a Novatek-made driver, but we don't have any indication of a manufacturer and I'm not touching that black tape ever again. Yes, polling the busy bit causes issues on the wonky LCD controller; I do not know if the polling itself causes issues, or the rapid switching between inputs and outputs is causing issues. Either way, eliminating the polling makes the problems go away. Novatek NT7564H doesn't show this behavior and acts normally.

Tari wrote:
  • Every driver that's been used in a calculator meets or exceeds the 10 μs response time specified for the T6A04.

Yes. Novatek LCD controllers and this new Kinpo LCD controller can be written to with OTIR at 6 MHz, and possibly even at 15 MHz per some discussion in #ti. Toshiba drivers will miss about half of the lines or more if OTIR is used, as if they weren't sent in the first place. Real timings are faster than 10 us (it seems to be around 40-47 cycles when setting contrast on my T6K04 TI-83 Plus, and similar on T6A04 TI-83s), but the delay is significant and should vary based on what's being done. 10 us is a guarantee.

Tari wrote:
  • 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.

Yes. The lcd_busy code that I use in my testing code is exactly 60 CPU cycles. On a calculator running at 15 MHz and equipped with a Toshiba LCD controller, data will fail to copy to video RAM.

Tari wrote:
  • 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.

I work with the TI-83 Plus so I can't really speak on this issue. It doesn't matter what timing you use on the wonky Kinpo LCD controller, the fact that you're repeatedly reading the status port causes issues. I've tried lcd_busy routines in the ballpark of 15000 us and still got broken behavior. TI-OS never reads the status port in the boot code on my Kinpo TI-83 Plus; the calculator runs at 6 MHz and the boot code lcd_busy (at $5FA9 with the boot code page swapped in; absolute address $7DFA9) is a static time-wasting routine that takes 60 cycles.


User programs got in the habit of polling the status port because was quite compatible with the LCD drivers of the time. Now, almost 20 years later, we can't do that anymore, because there was nothing explicitly telling us we shouldn't. Shells alone won't save us, so patching will ultimately be needed on some programs. In most cases, replacing the in a,($10) instructions (or ld c,$10 \ ld r,(c)) with something like cp a \ nop would make the program work on the wonky Kinpo driver, but will break compatibility with Toshiba drivers (say, if someone sends that patched program to an older calculator). Replacing the routine that checks for LCD business with call lcd_busy_quick (call $000B) will work on all calculators, as long as page 0 is swapped into $0000-$4000; I did this to Doors CS and it fixed the display issues.


In case it was missed, or you (the reader) wasn't in SAX while discussion was active, I updated documentation on WikiTI to match observed behavior, and created a LCD Drivers page to document the new drivers and clarify that there's more than just Toshiba drivers in these calculators.
CVSoft wrote:
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.

So you're saying that should still work no matter the driver type?

Also, thanks a lot for having shared your discoveries on the wiki, especially about the LCD RAM altering effect on the Kinpo.

However, i was a bit surprised to see that you stated the Novateks are actually faster than the Toshibas.
I mean, wasn't ALCDFIX developed because they require a longer delay in the first place?
the_mad_joob wrote:
CVSoft wrote:
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.

So you're saying that should still work no matter the driver type?

Well, it's what TI does. `call lcd_busy_quick` returns in 10 microseconds regardless of CPU speed (if set up right, which TI does), and TI never reads the LCD driver status port (at least in the boot code). Replacing port reads with `call lcd_busy_quick` made Doors CS work properly, but I can't speak for a performance change; it should be about 20-25% slower, since most LCD driver operations seem to complete after around 6-8 microseconds or so. Making things work on the new Kinpo LCD driver would probably make programs work properly on Nspire as well, to a degree.

the_mad_joob wrote:
However, i was a bit surprised to see that you stated the Novateks are actually faster than the Toshibas.
I mean, wasn't ALCDFIX developed because they require a longer delay in the first place?

ALCDFIX was developed before the Novatek drivers were created; the time of program upload appears to correspond with the T6K04 introduction, and I suspect it fiddles with the LCD delay port to give a longer delay. I don't know exactly what ALCDFIX does, since the readme doesn't elaborate on what it does and I don't want to read source code. And personally, I've never had problems with the T6K04.
CVSoft wrote:
Well, it's what TI does. `call lcd_busy_quick` returns in 10 microseconds regardless of CPU speed (if set up right, which TI does), and TI never reads the LCD driver status port (at least in the boot code). Replacing port reads with `call lcd_busy_quick` made Doors CS work properly, but I can't speak for a performance change; it should be about 20-25% slower, since most LCD driver operations seem to complete after around 6-8 microseconds or so. Making things work on the new Kinpo LCD driver would probably make programs work properly on Nspire as well, to a degree.

Actually, The lcd_busy routine waits 60 CC only until OS 1.12.
After that, the delay increases, depending on the context.
In case someone's interested, i took some time to grab some accurate numbers.
Of course, those delays are way too high, but as a reference, we know for sure that they are enough for all models (otherwise the OS itself would be broken).
There you go :

Code:
TI-83+

OS 1.03>1.12         60
OS 1.13>1.19         73

TI-83+SE - OS 1.13>1.19

6 MHz            73
15 MHz            215

TI-84+|TI-84+SE - OS 2.21>2.55

6 MHz            139
15 MHz            339

notes :
That is for a call lcd_busy instruction, which the OS uses (lcd_busy_quick takes a few more cycles).
Valid with ports $29,$2A,$2E,$2F holding system default values.

CVSoft wrote:
ALCDFIX was developed before the Novatek drivers were created; the time of program upload appears to correspond with the T6K04 introduction, and I suspect it fiddles with the LCD delay port to give a longer delay. I don't know exactly what ALCDFIX does, since the readme doesn't elaborate on what it does and I don't want to read source code. And personally, I've never had problems with the T6K04.

According to the source, ALCDFIX only alters port $29 to do its job.
So yes, it basically adds a delay to reads|writes to the LCD, when the CPU is running at 6 MHz (strangely enough, i would have expected a fix for 15 MHz aswell).
That implies the 60|150 CC delays used before those calcs came out weren't sufficient anymore.
Hard to say if a specific driver is involved though.

Anybody would happen to have a calc that requires ALCDFIX so that we can check its driver and required delay?
Thanks for the fix!
Necropost for sure, but, this is the only thread on this topic and the LCD drivers issue isn't going away.

Runer112 told me that the solution here is to flip the calculator back into 6 MHz mode and then wait 71 t-states between writes to ports $10 and $11 (half-inclusive of the writes. So your port $11 loop should be at 71 t-states per cycle). This isn't ideal as sometimes the LCD is ready quicker than that, but, at least it's a simple solution that works across the board. You can flip it back to 15MHz once you're done with the LCD.

If interrupts are enabled, make sure they don't touch the LCD (thinking about the busy indicator).

I'm not 100% sure how ALCDFIX (port $29) plays into all of this. I have a calculator that requires ALCDFIX and I tested and it doesn't need ALCDFIX with 71 t-states per loop (even with port $29 at 0C). I suppose this means it's actually 74 cycles per write with the $29 delay. Looking back at the ALCDFIX code (or at least my own variant of it), it seems that 60 cycles per loop is the "old gold standard" and you start stacking delays on top of that. Port $29 at 0C equates to 63 cycles per loop. My calculator's calculated ALCDFIX number inserts 12 t-states into each write, bringing that fastest-possible loop to 72 t-states.


Here are some keywords for people searching this: DWAIT, ALCDFIX, garbled screen, glitchy LCD driver, delay, broken, FastCopy
  
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 2 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