- ninja edit
- 15 Sep 2021 02:33:23 am Permalink
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.
- 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.
- 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.
- 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.