Natalie's Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Pocket 386 LCD Controller ======

===== Overview =====

The Pocket 386's LCD drive board is based on the Realtek RTD2660. This controller in combination with its firmware supports a menu for adjusting basic display settings. However, unlike most similar LCD drive boards, the Pocket 386 does not have any controls directly connected to the board. Instead, key presses are intercepted by the base unit's keyboard controller, which then sends commands to the LCD controller.

The manufacturer has not posted schematics or a PCB design file for the LCD drive board, so we must reverse engineer it to learn more about how it works.

Special note: I found firmware source for the Book 8088's LCD controller [[https://github.com/zhblue/RTD2660|here]]. It's unclear if this is the same as what's used in the Pocket 386. I ignored this and blackbox RE'd everything. A dump of the LCD controller's flash for safekeeping is available [[index|on the main Pocket 386 page here]].

===== Hardware =====

The way this is implemented in hardware seems to be a bit of an afterthought. It's also not fully drawn in the schematics or PCB file.

  * Two IO lines from the keyboard controller MCU run to unpopulated LED footprints, up by the Power/HDD LEDs
  * Two wires are soldered to points on the LED footprints
  * These wires have a breakaway connector in the middle, and then travel through the right-side hinge to the LCD drive board

==== Signals ====

  * **Red wire:** Active-low enable line for the LCD, used in external VGA mode. Bringing this high will disconnect the H/Vsync and RGB lines from the LCD controller, through U7 (TS5V330 analog switch) and U8/U9 (74LVC1G125 buffers). Pulled up to the 3v3 reg's Vin through R5 (4k7)
  * **Black wire:** TTL serial data from the keyboard controller. This is uni-directional to the LCD controller. As far as I know, the KBC is driving it at 5V levels. Tends to float around 4V when driven high. Pulled up to 3.3v through R20 (4k7)

===== Serial protocol =====

**Note:** Transmitted at 19200 baud, 8-n-1, LSB first, normal polarity

==== OSD ====
All OSD commands are transmitted as three bytes. The first appears to be a command type identifier, the second is the actual command, and the third is a checksum. The checksum is a simple one-byte sum of the preceding data.

  * Open OSD: 0xf0 0xa0 0x90
  * Up: 0xf0 0xa1 0x91
  * Down: 0xf0 0xa2 0x92
  * Left: 0xf0 0xa4 0x94
  * Right: 0xf0 0xa0 0x90 (yes, the same as open OSD)
  * Exit OSD: 0xf0 0xa3 0x93 (transmitted 3x, each about 270ms apart)

It seems like these may internally be emulating button presses on the controls that a normal monitor would have. Figuring out if other commands exist which are not used by the KBC is an exercise left to the reader.

==== S-OSD ====

  * Text transmission: 0xf1 {256 bytes text data} {checksum byte}

The S-OSD is transmitted as a 256-character block of text, which gets displayed as 8 lines of 32 chars each. The text buffer is fully assembled in the keyboard controller and then sent in one transmission to the LCD controller. The checksum works the same way as it does for OSD commands.

There is no specific command to open the S-OSD. The KBC simply begins transmitting the full block of text and the LCD controller will open the overlay. The text is updated by transmitting the whole thing again. The overlay can then be closed using the normal OSD's exit command.

The character set here is a bit weird. It's partially compatible with ASCII but has some differences that I haven't been able to personally identify. It may just be custom, but if anyone knows what it actually is, hit me up.

^ Char ^ Code ^
| ( | 0x08 |
| ) | 0x09 |
| + | 0x0b |
| : | 0x1a |
| = | 0x1d |
| A-Z | 0x21-0x3a |
| a-z | 0x41-0x5a |
| Space | 0x5f |

The '%' character is sometimes used by the S-OSD, but I forgot to capture it when it's displayed and my unit is already reassembled, so that will have to remain unknown for now.

===== Bugs =====
A flaw of this unidirectional communication is that the KBC really has no idea what the LCD controller is doing. Both sides are stateful, but neither can sync their state. One annoying bug is that some OSD adjustments like changing the 4:3/16:9 mode will kick you out of the OSD, but the KBC doesn't realize this has happened, and will continue eating your keystrokes until you press the Esc key.

The OSD also randomly goes corrupt in various ways. Sometimes the first time you open the OSD or S-OSD it will already be corrupt and unreadable. It's unclear why this happens... software bugs, power supply glitches, ...?

===== PCB Shots =====
{{ :pocket386:img20240516053820.jpg?300 |}} {{ :pocket386:img20240516053841.jpg?300 |}} {{ :pocket386:img20240516053848.jpg?300 |}}

===== Acknowledgements =====
Thanks caela for your assistance.