Writing A Human68k Driver For A PS/2 Keyboard Via The Serial Port

The Sharp X68000 was designed around a keyboard that is increasingly difficult to replace. Original keyboards can be expensive, fragile and awkward to ship to Australia, while compatible units often appear on Japanese auction sites only briefly. A PS/2 keyboard is far easier to find, so a serial-port adapter offers a practical way to keep an X68000 usable without altering its front-panel keyboard connector.

The important detail is that this is a protocol conversion project, not a passive cable. PS/2 uses a clocked, bidirectional two-wire interface with scan codes, whereas the X68000 serial port expects asynchronous RS-232 data with defined voltage levels. A small microcontroller must translate between those electrical and logical systems before Human68k can receive meaningful keystrokes.

The software side is equally interesting. A useful solution needs a resident Human68k program, a serial input routine, buffering, key-state handling and a clean interface for applications. It also needs to coexist with the machine’s normal console services rather than merely printing characters to the screen. The result is closer to a small keyboard subsystem than a simple terminal utility.

For Australian owners, this approach can be cheaper and more serviceable than hunting for an original keyboard in Sydney, Melbourne or Brisbane. It also suits preservation work: the adapter can be documented, repaired and rebuilt from ordinary components available through local electronics suppliers, while the original X68000 hardware remains untouched.

Define The Adapter Boundary

The most reliable architecture divides the project into two clearly defined parts. The external adapter handles PS/2 electrical signalling, keyboard initialisation and scan-code translation. The X68000-side driver handles serial reception, buffering, translation into Human68k key events and the interface exposed to software. Keeping those responsibilities separate makes testing much easier.

A small AVR, PIC, STM32 or similar microcontroller can read the PS/2 clock and data lines. PS/2 keyboards generally use open-collector signalling, so the adapter must provide suitable pull-up resistors and must never drive the bus high actively. The microcontroller should also tolerate the keyboard’s five-volt logic or use proper level conversion. A USB-only keyboard cannot be substituted without a USB host controller, so the shopping list must specify a genuine PS/2 keyboard or a known active USB-to-PS/2 converter.

The serial connection needs its own electrical check. A microcontroller UART usually produces TTL or CMOS levels, while an X68000 RS-232 port uses voltage swings and polarity associated with the RS-232 standard. A MAX232-compatible transceiver or equivalent is therefore required. TX and RX must be crossed correctly, ground must be shared, and modem-control lines should either be implemented or explicitly handled by the driver. A null-modem cable may be required depending on the adapter connector and wiring.

Start with a conservative serial format such as 9600 or 19200 baud, eight data bits, no parity and one stop bit. The exact rate is less important than reliability. A compact binary protocol is preferable to sending translated ASCII because it preserves extended keys, releases and modifier states. For example, one packet could contain a key-down flag, a translated key code and modifier bits. Add a reset command and an error marker so the driver can recover after a keyboard reconnect.

Decode PS/2 Events Before Human68k

A PS/2 keyboard does not send ASCII. It sends make and break scan codes, with prefixes for extended keys and a special sequence for releases. The adapter should consume those bytes, track prefixes such as the extended-key marker, and emit a stable event format. This avoids forcing the 68000 processor to reproduce low-level PS/2 timing and makes the serial stream easy to inspect with a logic analyser.

Key rollover and typematic behaviour deserve deliberate treatment. The keyboard may repeat a key while it is held, or it may report several simultaneously pressed keys in quick succession. A practical first version can forward make and break events and let the Human68k driver decide whether to implement repeat timing. That gives the driver control over the local clock and avoids duplicated repeats when the keyboard itself is already generating them.

The adapter should also answer basic PS/2 commands during startup. Many keyboards expect a reset command, an acknowledgement and a successful self-test response before they behave normally. Set the desired scan-code set if necessary, disable unwanted features, and request the keyboard’s current LED state. Caps Lock, Num Lock and Scroll Lock indicators should be updated when the driver changes modifier state, rather than being treated as a cosmetic afterthought.

Use a packet format that can survive lost bytes. One possible design is a synchronising byte followed by event type, key code, modifier mask and checksum. Escape the synchronising value when it appears in payload data. The driver can then discard a damaged packet and search for the next valid boundary. This is more robust than assuming every three serial bytes remain aligned forever, particularly when the X68000 is busy or the adapter is connected through a long cable.

Build A Human68k Input Layer

On the X68000, the driver should be a resident program loaded from CONFIG.SYS or started during the boot sequence, depending on the chosen integration method. It must initialise the serial hardware, install an interrupt routine, allocate a circular buffer and preserve the previous interrupt vectors. The uninstall path matters: a driver that cannot restore vectors safely is difficult to test and risky to load repeatedly.

The interrupt routine should do very little. Read the received byte, clear or acknowledge the serial interrupt according to the hardware documentation, place the byte in the ring buffer and return quickly. Packet assembly, checksum validation and key-state changes can occur in a foreground routine. This limits interrupt latency and reduces the chance of losing characters when another device or application temporarily disables interrupts.

Human68k integration can be approached at several levels. The least invasive version provides a resident API or command that applications call to fetch translated key events. A deeper implementation hooks the console or keyboard-related IOCS path so ordinary Human68k programs see the PS/2 device as a normal keyboard. The latter is more convenient, but it requires careful study of the ROM interface, vector ownership and how existing software reads function keys and modifier combinations.

A useful driver should expose status operations as well as input. Include commands to flush the queue, query modifier state, change repeat timing, send keyboard LED updates and report framing or checksum errors. Define return values consistently: empty queue, valid event, adapter offline and malformed packet should not be confused. These details make diagnostic utilities possible without modifying the main driver.

Component	Responsibility	Typical failure
PS/2 keyboard	Generates scan codes and receives LED commands	Stuck key or unsupported converter
Microcontroller	Samples PS/2 and creates serial packets	Lost clock edge or incorrect scan-code state
RS-232 transceiver	Converts UART levels to serial voltage levels	TTL connected directly to RS-232
X68000 serial hardware	Receives bytes and raises interrupts	Wrong port settings or vector handling
Human68k resident driver	Buffers, decodes and exposes key events	Overrun, bad hook or incompatible API
Test utility	Displays packets and driver status	Misleading results from cached state

Handle Key Maps And Compatibility

A Japanese X68000 keyboard layout will not map perfectly to a modern Australian-market PC keyboard. The physical legends may differ, and software may expect special X68000 keys for kana, editing, function-key combinations or graphic applications. The driver should therefore distinguish physical key identity from generated character data wherever possible.

Keep a translation table in the driver or in a separate configuration file. A table can map PS/2 scan codes and modifier combinations to Human68k key codes, while a second layer handles character conversion. This is preferable to hard-coding ASCII in the interrupt routine. It allows an owner to use a compact US-layout keyboard, an ISO keyboard sold in Australia, or a Japanese keyboard without rebuilding the entire driver.

Pay particular attention to left and right Shift, Control and Alt, the Windows or Command key, keypad Enter, navigation keys and the extended arrow-key sequences. Some older Human68k applications care about function-key scan values rather than the resulting character. Preserve those events instead of converting everything to printable text. A text editor and a game may interpret the same physical key through entirely different paths.

Caps Lock and Num Lock are common sources of confusion. Decide whether the host or the keyboard owns the state, then make the policy explicit. The adapter can report raw transitions while the driver maintains logical state and sends LED commands back through the serial protocol. During development, a diagnostic screen showing raw scan code, translated code and modifier flags will save considerable time.

Australian availability can influence the layout choice. Office keyboards from local retailers often use an ISO Enter key and include an extra key beside left Shift, while inexpensive imported boards may use the US layout. Document the selected mapping and avoid assuming that the legends match the scan-code positions. This is especially useful when sharing disk images or configuration files with enthusiasts in Perth, Adelaide or regional areas.

Test Hardware Timing And Recovery

Begin testing without connecting the adapter to an expensive X68000. Use a USB-to-serial interface, a logic analyser and a terminal program to confirm packet framing. Then test the microcontroller with several PS/2 keyboards, including an older mechanical model and a basic membrane unit. Some modern boards advertise PS/2 support but behave differently during reset, while active converters can hide useful low-level details.

Once the packet stream is stable, write a small Human68k diagnostic utility. It should display hexadecimal bytes, decoded events, queue depth, checksum failures and the current modifier mask. Press every function key, hold combinations such as Control-Alt-Delete, test rapid typing and unplug the keyboard during operation. A diagnostic program is more valuable than debugging through a full-screen application that may intercept or discard unusual events.

Serial overruns need an explicit recovery path. The driver can discard the current packet after a timeout, flush the receive queue and request a fresh keyboard status report. The adapter should periodically send a heartbeat or respond to a poll command, allowing the driver to distinguish a silent keyboard from a disconnected serial cable. Never spin indefinitely inside an interrupt routine while waiting for the next byte.

Power and isolation deserve attention in Australian installations. Many Japanese X68000 units were designed for Japan’s nominal 100-volt supply, while Australian mains is nominally 230–240 volts. A keyboard adapter must not be used as a reason to connect an imported computer through an unsuitable transformer or travel adaptor. Keep the low-voltage adapter separate, use a properly rated supply and check earth, polarity and connector wiring before applying power.

Document each revision as carefully as the code. Record the microcontroller firmware version, serial settings, keyboard model, cable pinout and Human68k driver checksum. The project diary can hold failed experiments and repair notes alongside successful builds, which is useful when returning to the hardware months later; the X68K.NET diary is a natural model for that kind of practical record.

Package And Share The Driver

A finished release should contain more than a binary. Include source code, an assembler or compiler version, build instructions, a sample configuration, adapter firmware and a wiring diagram. Human68k users may be working from floppy disks, hard-drive images or CompactFlash replacements, so provide a small executable and a plain-text README that can be copied using older tools.

Separate the stable protocol from experimental features. Version the packet format and reserve unused fields for future capabilities such as mouse events, macro keys or host-to-keyboard commands. A version query at startup prevents a new driver from silently interpreting an old firmware stream incorrectly. If the adapter reports its capabilities, the driver can disable unsupported functions gracefully.

Compatibility testing should include games, text editors, command shells and software that reads the keyboard through different IOCS paths. Test cold boot, warm reset, resident-program removal and a machine that already has a serial driver loaded. Keep a record of which applications use standard console input and which access hardware more directly. That record will prevent claims of universal compatibility based on a single successful command prompt test.

Community documentation is part of preservation. Publish the pinout, protocol, source and known limitations in a format that can be mirrored easily. A focused collection of related projects and technical references, such as the X68000 resource links, helps future builders find compatible tools without relying on a single commercial seller or disappearing forum attachment.

For Australian builders, local sourcing can make maintenance simpler: RS-232 transceivers, headers, resistors and microcontroller boards are commonly available through electronics distributors, while replacement PS/2 keyboards may turn up at computer recyclers or weekend markets. Imported parts can attract GST and delivery delays, so designing around standard components reduces the risk of one discontinued board stopping the project.

Build the adapter in stages, label every cable and keep the original keyboard interface unmodified. Then publish the firmware, Human68k driver and test results so another X68000 owner can reproduce the work. A well-documented serial keyboard bridge turns an ageing Japanese computer into a usable daily machine while preserving the hardware and knowledge that make the platform worth maintaining.