Reverse Engineering the X68000 Keyboard Protocol

The Sharp X68000 keyboard is more than a collection of switches connected to a game-port-style plug. It is a dedicated peripheral with its own electronics, timing behavior, scan-code conventions, and communication rules. Understanding that interface makes it possible to repair original keyboards, build adapters, diagnose intermittent faults, and connect modern input devices without losing the character of the original system.

A useful investigation begins by separating the problem into layers. The connector and electrical signals form the physical layer. Bit timing and frame structure belong to the link layer. Key transitions, modifier states, commands, and acknowledgements make up the protocol layer. Treating these as separate questions prevents a misleading voltage measurement from being mistaken for a complete protocol description.

Reverse engineering should also be approached as preservation work. An original keyboard may contain custom chips, aging capacitors, worn cable conductors, and membrane contacts that are difficult to replace. A careful protocol record can therefore be as valuable as a repaired unit, especially when it is supported by captures, photographs, schematics, and reproducible test code.

Why the keyboard interface deserves careful study

The X68000 keyboard handles more responsibility than a passive matrix. A local controller scans the keys and presents events to the computer in a serial form. This arrangement reduces the number of conductors required in the cable and lets the keyboard manage debouncing, rollover behavior, indicator lamps, and special keys independently of the main CPU.

That intelligence creates several practical complications. A keyboard may send a code when a key is pressed and another when it is released, while modifier keys may alter the interpretation of later events rather than changing the code itself. The computer may also issue commands during startup or when it changes keyboard LEDs. A capture made during ordinary typing can therefore reveal only part of the conversation.

Different X68000 keyboard revisions should be treated as related hardware rather than assumed-identical devices. Connector wiring, controller revisions, clock tolerances, and initialization behavior may vary. The safest documentation records the exact keyboard model, cable, computer revision, and test conditions for every observation.

The goal is not simply to produce a modern USB keyboard that happens to work. A useful reverse-engineering result explains how the original device behaves, which signals are essential, how errors are handled, and which parts of the implementation are model-specific. That distinction matters when designing a replacement controller or debugging a machine that accepts keystrokes only intermittently.

Mapping the connector and electrical layer

Begin with the keyboard unplugged. Photograph the connector, identify its orientation, and trace each conductor to the keyboard PCB before applying power. Continuity tests can reveal ground and cable shielding, but they cannot establish whether a remaining conductor carries data, clock, power, or a bidirectional signal. Record resistance to ground and to the supply rail, then compare readings with the keyboard connected and disconnected.

An oscilloscope or logic analyzer is more useful than a multimeter for the active lines. Probe through a high-impedance connection, keep the ground lead short, and avoid attaching an analyzer configured to drive signals. If the interface uses open-drain or open-collector signaling, an external pull-up and a push-pull probe can distort the waveform or damage a driver.

Power measurements should be made before protocol decoding. Check the supply voltage at the keyboard connector during idle, startup, and rapid key activity. A substantial dip can produce false conclusions about framing because a controller may reset or lose state while the analyzer continues recording. Aging connectors and fractured cable solder joints deserve attention as well; an apparently mysterious protocol fault may be a mechanical fault.

A second stage uses a sacrificial breakout cable or an interposer board. Bring every conductor to labeled test points, add current limiting where appropriate, and provide a switch for isolating the computer. This arrangement permits captures without repeatedly stressing the original connector. It also leaves room for a replacement keyboard controller, level shifter, or microcontroller interface once the electrical behavior is understood.

Capturing traffic without changing its behavior

Capture several operating conditions separately. Record power-on, a single key press, a single release, repeated presses, simultaneous modifier and letter keys, indicator changes, and a long period of idle time. Each recording should include the logic analyzer sample rate, voltage thresholds, probe arrangement, keyboard model, and computer model. Without this metadata, a useful waveform becomes difficult to reproduce.

Look first for idle levels and transitions rather than assigning meaning to individual bits. Determine whether a line supplies a clock, whether data changes on rising or falling edges, and whether the sender releases the line between bytes. Measure the interval between edges and between frames. A serial protocol can look plausible when decoded with the wrong polarity, especially if the signal has a regular idle state and short bursts.

A logic analyzer’s built-in UART decoder is only a hypothesis generator. Try multiple baud rates, bit orders, parity settings, and idle polarities, then compare decoded values against known physical actions. If no asynchronous configuration produces stable results, the link may be synchronous or use a custom framing scheme. Export the raw transitions so later analysis does not depend on one decoder’s assumptions.

The strongest evidence comes from repeated experiments. If pressing the same key ten times creates the same event sequence, confidence in the scan code increases. If the first event after startup differs from later events, it may be an initialization response rather than a key report. If a command from the computer causes a predictable keyboard response, capture both directions and preserve the delay between them.

Research on the surrounding machine can also clarify what the keyboard is expected to do. For example, the VDG replacement work demonstrates why X68000 hardware repair benefits from documenting signals, chip roles, and revision-specific behavior instead of treating a failing subsystem as a black box.

Turning waveforms into protocol rules

Once the physical signals are known, divide captures into candidate frames. Look for a start condition, a fixed or variable number of clock pulses, a data field, and a stop or acknowledge period. Count bits from the waveform itself rather than from a presumed standard. A protocol may use seven or eight data bits, a separate parity bit, or a command prefix that changes the length of the following message.

Key events should be catalogued in a structured way. A useful record includes the physical key, press or release state, raw bytes, time from the previous event, modifier state, and any computer response. Avoid naming a byte “A” merely because it appeared after pressing the A key. Confirm the mapping with shifted, unshifted, locked, and simultaneous combinations.

Debouncing deserves special attention. A mechanical switch may produce several physical transitions, while the keyboard controller emits one clean event. Conversely, a keyboard may deliberately report a held key repeatedly after a delay. Measure the interval from press to repeat, the repeat period, and the behavior when another key is pressed during repetition. These details affect compatibility with games and software that read keyboard input directly.

The comparison below separates observations that can usually be made with basic tools from conclusions that require broader captures. It is useful when organizing a protocol notebook or reviewing an existing reverse-engineering report.

Investigation area	Evidence to collect	Likely result	Common mistake
Connector wiring	Continuity, voltage, idle state	Power, ground, clock, and data candidates	Assuming connector pin numbers are universal
Bit timing	Edge-to-edge measurements	Clock frequency or baud estimate	Trusting a UART decoder without raw captures
Frame structure	Repeated press and release captures	Start, payload, parity, and stop fields	Mixing startup commands with key reports
Key mapping	Physical key matrix and event logs	Scan-code map and modifier rules	Inferring meaning from one key press
Host commands	LED changes, reset, and startup traffic	Command and acknowledgement behavior	Capturing only keyboard-to-host traffic
Fault handling	Cable interruption and invalid input tests	Timeout, retry, or reset behavior	Testing on an irreplaceable original

A protocol description becomes dependable when it states both positive and negative findings. “The keyboard sends code 0xXX for this event” is less useful than “this code appeared after a press, disappeared on release, remained stable across three keyboards, and was not generated by startup traffic.” Negative tests, such as unplugging the keyboard during initialization or sending an invalid command to a test controller, reveal state-machine behavior that ordinary typing never exposes.

Building a safe analyzer and replacement controller

A microcontroller test harness should begin as a passive monitor. Use a suitable logic-level input, protect the board with series resistance where necessary, and keep the original computer responsible for bus timing. Once captures are repeatable, add a controlled transmitter that can reproduce one known-good response at a time. A harness that immediately emulates the entire keyboard makes it difficult to identify which assumption caused a failure.

Firmware should represent the protocol as an explicit state machine. Useful states may include power-on, idle, receiving a host command, sending a key event, waiting for acknowledgement, and recovering from a timeout. Store raw frames separately from interpreted key events so an unusual byte sequence is not silently discarded. Include a diagnostic mode that reports timing errors, unexpected edges, and checksum or parity failures.

Testing should use a matrix of cases rather than a single successful boot. Try every modifier, rapid alternating keys, multiple held keys, keyboard reset, cold and warm starts, and cable reconnection. Test the LEDs and any special keys that may use a command path different from ordinary scan codes. Compare the replacement controller’s electrical idle behavior with the original before connecting it to a valuable computer.

Recommended practices for a reliable investigation include:

• Preserve raw analyzer files alongside decoded text and photographs.
• Identify every keyboard, computer, cable, and controller revision used in testing.
• Use a breakout or sacrificial cable before probing an original connector repeatedly.
• Separate verified protocol rules from working hypotheses in firmware and documentation.
• Test startup, key release, repetition, indicators, and error recovery as separate features.

A replacement controller should also respect the original power budget and signal timing. USB-capable microcontrollers are convenient, but their default GPIO behavior may be unsuitable for a bus that expects released-high signaling or a particular startup level. When in doubt, reproduce the line driver electrically before optimizing the code.

Preserving hardware knowledge alongside the protocol

Protocol work is most valuable when it is connected to the physical artifacts it explains. Keep PCB scans, controller markings, cable dimensions, connector drawings, and repair notes with the capture archive. A scan-code list without a photograph of the keyboard revision can become misleading when another enthusiast applies it to a later model.

Mechanical preservation matters too. A replacement controller is of limited use if the keyboard shell, cable strain relief, or expansion covers are missing. The practical details in reproducing the expansion cover illustrate the broader principle: accurate measurements and documented fabrication steps help keep original systems usable without sacrificing scarce parts.

Shared documentation should distinguish measured facts from interpretation. Include screenshots of waveforms with scale markers, annotated pin diagrams, sample raw captures, and the tool versions used to decode them. If a value is uncertain, say what evidence would confirm it. This makes later corrections constructive rather than forcing another researcher to repeat every experiment from the beginning.

The wider X68000 community can then build on the work in several directions. A keyboard-to-USB adapter may translate original scan codes for modern hosts. A USB-to-X68000 bridge may let a contemporary keyboard behave like the original peripheral. Diagnostic firmware can test a computer’s keyboard port, while an emulator can reproduce the keyboard’s startup conversation and timing for software development.

From reverse engineering to durable tools

A complete result should describe the interface at three levels: electrical, temporal, and semantic. The electrical section identifies connector functions and voltage expectations. The temporal section explains edge order, bit timing, frame boundaries, and delays. The semantic section maps events and commands to their meaning. Keeping these sections distinct allows a future repairer to substitute a component without confusing hardware behavior with software interpretation.

Version control is especially useful for protocol research. Store firmware, decoding scripts, pin definitions, and documentation in a repository with tagged releases. Add regression captures so a change to the decoder can be checked against known startup and key-event sequences. A small command-line tool that turns raw captures into annotated events may be more valuable than a polished graphical application because it can run on old maintenance systems and modern workstations alike.

The finished documentation should make safe experimentation possible. Explain where to connect probes, what voltages are expected, which tests require an isolated keyboard, and how to recover from a failed emulation attempt. Include warnings about connecting two active transmitters to the same line. Clear limits protect both the hardware and the researchers who will continue the work.

A careful study of the X68000 keyboard protocol therefore becomes more than a scan-code chart. It preserves the behavior of a specialized peripheral, gives repairers a route around unavailable parts, and creates a foundation for adapters and emulators. Publish the captures, schematics, firmware, and revision notes together so the next generation of X68000 enthusiasts can verify the findings, extend them, and keep original keyboards communicating with original machines.