On the LCD board is a big TQFP that some might think to be the "LCD Controller"... That's not quite the case. That chip is a T6A40, NOT T6K04: the latter is apparently used in TI-83+ and others, and is an entirely different concept.

Consider it, the one in the TI-83+, a bit like a graphical version of HD44780 Text displays, or a bit like the infamous Nokia LCD, or a parallel-interfaced version of the SPI interfaced displays most folk use these days. That'd be a great one to use with a microcontroller project. They have a framebuffer built-in and you can send commands to turn on or off individual pixels.

THIS LCD, with the T6A40 row driver, (and T6A23 column driver), however, is much more like interfacing a VGA monitor... It has no memory, you have to send all the pixels, in order, all the time, "refreshing" the screen before the pixels fade (or get damaged by DC, in the case of liquid crystals).

So, frankly, all matrix LCDs need this interface: the first row is selected, the columns are loaded sequentially, the next row, all those cols, again, repeat for every row, then start again at the top... 

That's apparently what the TI-86's CPU sends to the LCD, very similarly to VGA, with something like hsync to select the next row and vsync to select the first. Thus most LCDs always have essentially two [types of] chips, row drivers and column drivers. Huge LCDs with a lot of pixels have many of these daisychained. They're often on the ribbon cables that go to the glass. The display driver (the CPU, in this case) typically only interfaces with the first row-driver and first column-driver chips. 

The display in the TI-83+, however, has the display driver built-in. Think of it a bit like a VGA monitor which has the VGA card built-in, so instead of sending it a VGA signal, you send it VGA /commands/... but it still has that VGAish signal in there somewhere to scan the electron beam across the screen in raster-fashion.

So the TI-86's LCD is refreshed pixel-by-pixel, line-by-line, frame-by-frame... just like a VGA monitor. It's not easy to interface with that... usually requiring a constant stream of pixel data and a framebuffer.

BUT, it has a few great advantages. At least, as far as the sorts of hackery I tend toward. It's possible for the CPU to know and control intimate details about the screen. 

For instance, the CPU can know When the screen has fully-refreshed so that new data can be loaded into the framebuffer /between/ drawing two frames. Imagine a movie's playing and you load frames at a different rate than the screen refresh rate... there'd be sometimes where the display would show half of one frame and half of the next.

Similarly, it's my understanding that this is how the 1337 h4x0rz can display grayscale on these screens; do one frame black, the next white.

OR, another (though this isn't really feasible with LCDs since the pixels are slow and don't /activate/ one-by-one, but row-by-row), think of how the NES's "gun" or old "light pens" worked... that isn't possible without knowing exactly which pixel is being /displayed/ and when.

Now, I had an idea for other hackery that could take advantage of the LCD interface to make general-purpose outputs... by extending the resolution sent to the display. This display is 128x64. The TI-86 allegedly has the ability to change the display configuration to 160x64. The display itself would still only display the first 128 pixels on each row, but the data is sent from the framebuffer for all those extra pixels... and because the row drivers and column drivers are physically accessible on the panel, those extra pixels could be used for other purposes, such as turning on a bunch of LEDs, or maybe even producing sound waveforms, or possibly even attaching a sound-chip (SID?) etc.

Now, unfortunately for that goal, the column-driver chip on the LCD panel is designed to handle 160 columns, so it won't "daisychain" the extra pixels out its output port... but it's /plausible/ the display driver in the CPU could be far more configurable than the few options I've read about... If we could, say, bump it to 168x64, the column-driver will output a daisy-chain "enable" after pixel 160, so with a few wires from there and a tiny bit of glue logic, an 8-bit latch, a shift register, or even just a buffer with output-enable, we'd have 8 general-purpose outputs which can be updated at the hsync rate... say it's 168x64x60Hz, then 60x64=1.2ish khz.

More thoughts over at: https://hackaday.io/project/8146-ridiculous-lcd-display-hacks/log/193007-extra-pixels-as-outputs-or-display-doubling

Another alternative I just thought of would be accessing the row-driver's outputs. If we could bump the display driver up to 65x128, we could have 8 output bits refreshing at e.g. 60Hz. By tapping off one the unused row output 65 as a clock-pulse for an 8-bit latch. It has 68 row outputs... so 4x8 bits would be an easy extension, and a tiny bit of glue logic could discern each column-load, too... up to 128 (or160?)*4 outputs... that'd be a lot of chips, but think of it differently... a lot of chips have decoding circuitry just like that built-in... An HD44780 compatible LCD has several parallel-load registers. Row65 could handle character loads, Row 66 could handle commands.... 128/8=16 characters could be loaded with each LCD frame refresh... or even 16x4... now you've got a debugging or "stderr" console, or a CPU load meter, etc. 

This display, I think, loads 8 adjacent pixels simultaneously... (though the column driver is also capable of 4, and 1), if the display controller in the CPU could be configured to send 1 pixel at a time (seems unlikely) then adding SPI devices (output-only) would be a breeze. The Row65 output goes to the chip-enable, the "pixel load" clock is the SPI clock, and data-out is the pixel data. And even if the thing can't be changed from 8pixel parallel, still one full SPI packet could be sent with each refresh... now you can attach an SPI OLED.

Yah see where I'm going with this? Outputs, lots, on a system which otherwise only has two (really weird ones).

Unless, of course, I'm right about the 128k of unpopulated memory, which would, of course, be far more versatile, and maybe easier, to do memory-mapped I/O. OTOH, I wanna stick FLASH there ;)