Using a Saleae Logic Analyzer with the X68000 Keyboard

The Sharp X68000 keyboard looks familiar to anyone who has worked with late-1980s Japanese computers, yet its communication method is unusual enough to reward proper measurement. A Saleae Logic analyser can reveal the electrical timing, serial frames, reset behaviour and command exchange without relying on incomplete pinout notes or guesses based on modern USB keyboards. Learn more about Google Adsenseの収益が急落したときの原因特定と復活策.

This makes the analyser useful for repairs, replacement keyboard projects and software preservation. The same process also applies when checking an original keyboard after a power-supply fault, developing an adapter for a Raspberry Pi, or documenting the protocol for future X68000 owners in Australia and elsewhere.

Approach	Best use	Main advantage	Main risk
Passive Saleae capture	Learning the protocol	No firmware changes required	Incorrect voltage or ground connection
UART decoder	Testing a suspected asynchronous link	Fast first view of bytes	May hide non-UART timing
Raw digital capture	Unknown or bidirectional traffic	Shows every transition	Requires manual interpretation
Logic analyser plus oscilloscope	Electrical fault finding	Adds voltage and signal-shape evidence	More equipment and setup time
Microcontroller sniffer	Repeated testing and automation	Can log long sessions cheaply	Firmware may introduce assumptions

Preparing the keyboard and analyser

Begin with the connector pinout, service notes and a continuity check. Do not assume that a pin carrying a serial-looking signal is safe for a Saleae input. Identify ground first, then determine the keyboard supply voltage and the idle state of each communication line. The original X68000 hardware is old enough that a damaged regulator, corroded connector or replacement power supply can produce readings that differ from the published specification.

A Saleae Logic device should normally share ground with the X68000 or keyboard under test. Connect one ground lead close to the keyboard connector and use short signal wires. Long jumper leads can act as antennas, especially near switching power supplies and video circuitry. Begin with a high sample rate, such as 4 to 10 MHz, then reduce it only after the signal is understood. At least ten samples per shortest pulse is a sensible starting point, while twenty or more gives a more comfortable margin for decoding.

Use the analyser as a passive observer. Do not connect an output channel, probe, or USB-to-serial adapter until the electrical interface has been identified. Some vintage computer ports use open-collector or otherwise non-standard signalling, and a modern interface can force a line high or low. A cheap logic-level shifter from an Australian electronics retailer such as Jaycar or Altronics may be useful later, but it should not replace the initial voltage check.

Capturing the first keypress

The first recording should be simple: power the system, allow the keyboard to initialise, press one key, release it, and stop the capture. Save the original Saleae session before adding decoders or filters. Include several seconds of idle time before the keypress because startup traffic often reveals the direction of communication, reset sequence and keyboard identification exchange.

Look at the waveform at several time scales. A keyboard protocol may appear to be asynchronous UART traffic, synchronous clocked data, or a mixture in which the computer sends commands and the keyboard returns scan information. If there is a separate clock line, measure the relationship between clock edges and data changes. If there is only one changing line, estimate bit duration from repeated transitions and compare it with common baud rates such as 1,200, 2,400, 4,800 and 9,600 baud.

Avoid treating a plausible byte stream as proof. A UART decoder can display convincing values even when the actual protocol is inverted, uses an unusual bit order, or has a different framing arrangement. Try normal and inverted polarity, 7- and 8-bit data, and likely parity settings, but keep the raw trace visible. A decoded sequence that changes predictably when you press different keys is more useful than a neat-looking stream produced by an arbitrary decoder setting.

For a reliable comparison, capture the same key several times, then record neighbouring keys, modifier keys and a held key. A press may generate a make code, while release generates a break code or a second status byte. Holding a key can produce repeats, although the repeat may be generated by the computer rather than the keyboard. These distinctions matter when writing an emulator or diagnosing a stuck key.

Finding the frame structure

Once clean captures exist, mark the idle level, start condition, data bits, stop condition and inter-frame delay. Saleae’s measurement cursors are valuable here because they allow the bit period to be compared across many frames. If the period is consistent, calculate the approximate baud rate from the bit width rather than selecting a standard value by habit.

Group repeated bytes into possible packets. Look for values that remain constant across ordinary keypresses, positions that change with the key, and bytes that appear only after the computer sends a request. A checksum or complement byte may be present at the end of a packet. Test this by comparing the final byte against simple sums, XOR operations and two’s-complement totals over the preceding data. Do not publish a checksum theory until it survives captures from several keys and keyboard states.

Bidirectional traffic deserves special care. Configure separate analyser channels for the keyboard-to-computer and computer-to-keyboard paths where possible. If the interface uses a shared line, inspect whether the keyboard releases the line before the computer responds. A response that begins a fixed number of bit periods after a command may indicate a polling protocol rather than spontaneous key reporting.

Timing can expose faults that byte decoding misses. A keyboard with a failing oscillator may transmit valid-looking values at the wrong speed, while a tired connector can create narrow glitches that produce occasional framing errors. Compare the original keyboard with a known-good unit if one is available. Australian owners may find suitable hardware through eBay Australia, Gumtree or local retro-computing groups, although condition and shipping from Japan vary widely.

Using captures for repair and emulation

A protocol trace becomes genuinely useful when it is tied to a physical action and a test condition. Name files with the computer model, keyboard revision, capture rate and test performed. For example, a session can record startup, Escape press, held Space key and release. Keep both the Saleae project and an exported CSV or binary capture so that future tools can reanalyse the signals.

Document electrical observations alongside decoded bytes. Record the measured supply voltage, ground reference, logic-high level, idle state and approximate baud rate. A keyboard may work on the bench but fail when connected through a long cable or an adapter with a different pull-up arrangement. These details help distinguish protocol errors from signal-integrity problems and make a later replacement controller much easier to validate.

This wider preservation mindset is useful across X68000 repair work. When a replacement component is difficult to source, the investigation may involve comparing board revisions and documenting compatible parts, much like the work described in video encoder IC sourcing. A keyboard capture should receive the same level of care: identify the hardware, preserve the original evidence and clearly separate measured facts from interpretation.

For emulation, start with a small receiver that logs bytes without acting on them. Compare its output against the Saleae capture, then add command handling and key mapping one feature at a time. A microcontroller should not drive the original computer until its voltage levels, reset behaviour and line direction have been verified. An adapter that reads correctly but holds the data line at the wrong level can damage an interface or prevent the X68000 from booting normally.

Avoiding common measurement errors

The most common mistake is probing the wrong reference. A Saleae input connected to a signal without a shared ground can show convincing but meaningless transitions. The next is sampling too slowly. If the analyser records only a few samples per bit, the decoder may shift edges and report random bytes. Increase the rate before changing protocol settings, and capture enough idle time to establish the baseline.

Power-up deserves separate attention. Some keyboards send an identification or readiness sequence immediately after receiving power, so attaching the analyser after boot can hide important traffic. If the system behaves differently when the probe is attached, check the ground lead, input capacitance and any accidental connection to a power pin. Never use the keyboard connector as a convenient power source for an adapter unless its current capacity and polarity are confirmed.

Do not repair a suspected keyboard fault by changing software assumptions first. Clean the connector, inspect solder joints, check the cable for intermittent continuity and verify the keyboard supply under load. A 240-volt mains supply in Australia requires particular caution when testing an X68000 power supply or an imported step-down arrangement; keep mains work isolated from the low-voltage logic investigation and use a qualified technician where necessary.

It is also easy to lose valuable evidence through poor project organisation. Keep an untouched capture, a working copy with decoders and a written interpretation. If the project is published online, include screenshots at both full-session and bit-level scales. Website maintenance can matter here as well: changes in search traffic or advertising performance can obscure which technical pages are actually being found, so separate traffic recovery notes from the hardware documentation rather than mixing the two.

Building a reusable keyboard protocol reference

A useful reference should explain the connector, electrical levels, timing, packet examples and uncertainty. Include captures for startup, an ordinary key, a modifier, key release, repeated input and any command sent from the computer. Annotate each waveform with the physical action that produced it. If a byte has not been identified, label it as unknown instead of assigning a speculative meaning.

Screenshots alone are not enough for long-term preservation. Export raw captures in a format that another tool can read, and store a text log of decoded bytes with timestamps. Saleae project files are valuable, but a future enthusiast may use different software. A concise protocol summary can therefore include the original sample rate, channel names, threshold settings, decoder configuration and any inversion or bit-order assumptions.

Physical documentation benefits from the same discipline. If an adapter or replacement board is developed, record cable strain relief, connector orientation and enclosure dimensions. A carefully designed enclosure can protect a fragile expansion or interface board; the practical considerations are illustrated by the 3D-printed X68000 case. For Australian builders, allowing for local 3D-printing tolerances, threaded inserts and Australia Post packaging can prevent a working prototype from becoming a damaged shipment.

The finished result should let another owner reproduce the capture without specialist knowledge. State which Saleae model was used, show where the ground clip was attached, list the tested keyboard revision and identify any differences between units. That turns a one-off reverse-engineering session into a practical repair resource for the X68000 community, whether the next reader is working in Sydney, Melbourne, Perth or a workshop far from Japanese replacement parts.

A careful Saleae capture can preserve far more than a sequence of key codes. It records how an original keyboard starts, communicates and responds under real conditions, giving repairers and emulator authors evidence they can revisit years later. Save the raw sessions, document the electrical details and publish the verified findings so another X68000 can keep running.