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.


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.


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.


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.

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?

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.


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.

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:


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