Build a Human68k tool for sound test sequences

An X68000 sound check becomes far more useful when its timing is repeatable. A small Human68k utility can read a plain-text test, convert it into a Standard MIDI File, and hand the result to the machine’s sound software. That approach avoids pretending the computer’s FM and PCM paths are laboratory instruments while still exposing missing channels, distortion, clipping, and timing faults. Learn more about Obs Studioで垂直配信 9 16 用にレイアウトを切り替えるショートカットの活用方法.

The utility can accept fixed tones, short bursts, silence, and stepped or continuous frequency sweeps. It should report every conversion error and emit a companion log containing the requested frequency, MIDI note, start time, and duration. This turns a casual keyboard test into a maintenance artefact that can be rerun after a repair, modification, or long period in storage.

Keeping the generator separate from playback also preserves choice. An owner can use XMIDI, test another installed player, capture the output through an interface, or inspect the file on a modern workstation. That division of labour suits a preservation-minded X68000 site, where the aim is to keep the original hardware understandable rather than hide it behind an opaque modern replacement.

Define a repeatable test format

Start with a narrow script grammar. Lines such as tone fm-soft 440 2.0, silence 0.25, and sweep fm-bright 200 8000 8.0 are enough for most checks. Each command needs a fixed field order, documented units, and predictable handling of decimal points. Comments should begin with a character that cannot be confused with a minus sign or command name.

Treat names such as fm-soft as configuration rather than magic. A lookup file can map them to MIDI program and control-change numbers for the selected X68000 sound player. This is essential because program banks differ between the built-in synth, optional sound hardware, and user configurations. The tool should refuse an unknown name and list valid choices instead of silently playing another patch.

Record limits before writing code. MIDI divides time into ticks and expresses frequency as discrete notes, so a request for 437 Hz will normally be rounded to the nearest equal-tempered note. The log should show the resulting frequency at the chosen tuning. Duration and event-count ceilings also prevent a mistyped sweep from exhausting memory on an expanded machine that still has far less RAM than a current desktop.

Generate MIDI without hiding X68000 constraints

Standard MIDI File format 0 gives this project a well-defined output: one header chunk, one track chunk, and an end-of-track event. The 68000 is big-endian, so write 16-bit lengths, tempo values, and note numbers byte by byte in MIDI order rather than copying host integers directly. Delta times use MIDI’s variable-length quantity encoding, including the correct continuation-bit rules for values above 127.

Build the stream incrementally. Convert each duration to ticks using the chosen pulses per quarter note and tempo, maintain an absolute event position, and store pending note-offs in a small queue. At 120 BPM and 960 pulses per quarter note, one second represents 500 ticks. Continuous sweeps need denser events than audible pitch steps require, but an event cap and minimum interval should prevent unmanageable files.

Emit the tempo as the meta-event FF 51 03 followed by three big-endian tempo bytes, and finish the track with FF 2F 00. Program changes select timbre; note-on and note-off events control pitch and duration. Do not label a MIDI program as a laboratory waveform unless the X68000 patch actually has that character. Built-in FM synthesis has its own noise and harmonic profile, and some configurations may ignore velocity.

The Human68k program can remain a conventional command-line executable. Support an output path, tempo, tuning reference, and pulses-per-quarter-note value, while sending normal status and errors to the console. Compile it with the X68000 toolchain used by the collection, or cross-compile and test the result on the original machine. Prefer bounded buffers, explicit byte writes, and removal of a temporary file after a failed export.

Route the sequence through real hardware

Connect the chosen output to headphones or low-gain amplified speakers before running a full-volume test. Start with the X68000 system volume and player volume low, then raise them in stages while listening for asymmetry, periodic clicks, hum, or notes that continue after their scheduled stop. A line input on a modern USB interface can provide a recording, but its automatic gain control and noise removal should be disabled during level checks.

Australian benches add a power-supply detail that Japan’s original 100 V context does not. Australian mains is 230 V at 50 Hz, so a Japanese-market X68000 needs a suitably rated, securely wired step-down transformer and an appropriate Type I Australian plug. A travel adaptor changes the pin shape, not the voltage. CRT work, internal power supplies, and mains wiring should be left to someone qualified.

Modern peripherals can help with diagnosis, but they should not complicate the audio path. For another example of connecting new hardware responsibly to an X68000 peripheral, the site’s WiFi Classic dongle installation is a useful serial-bridge reference: it records connector, baud-rate, and power details instead of hiding them behind an undocumented adapter. A sound utility follows the same principle by naming the output route and every assumed device setting.

Check timing, level, and repeatability

A useful report combines listening with measurement. First, run a short low-level sequence and confirm that each event starts and stops in the expected order. Next, alternate left and right tests if the installed player supports stereo panning. Finally, repeat the same file after a reboot. Stable results distinguish a missed software event from thermal instability, marginal supply voltage, or a worn analogue output stage.

Keep a plain-text log beside the MIDI file. It can include the generator version, X68000 model, selected sound configuration, player name, tempo, tuning, event counts, and calculated duration. On a modern system, open the MIDI in a tracker or digital audio workstation to inspect its tempo map and event order. Any disagreement between that view, the generator log, and the sound heard through the speaker should be resolved before the sequence becomes a reference test.

A captured test can also support online demonstrations and hobby-group recordings without turning the desktop into the subject. When preparing a phone-first clip, the vertical OBS layout guide shows how OBS can switch layouts for a 9:16 stream. Keep the tone sweep audible and the X68000 clearly visible, then archive the original capture settings with the test log.

Automate the workflow and preserve the source

Once single tones work, let a Human68k batch file run the generator, invoke the selected player, and redirect diagnostic output to a timestamped log. Avoid assuming every command-line convention from MS-DOS or Linux applies to Human68k; test quoting, wildcard behaviour, and error handling on the target installation. Keep generated MIDI in a separate output directory so repeated runs never overwrite the source script by accident.

Version the parser, format description, patch map, and example scripts together. Store text files with the encoding used by the collection while keeping command names ASCII, so Japanese filenames do not become a hidden dependency. Sample scripts should cover a basic channel check, stereo alternation, a slow sweep, and a short diagnostic burst. Generate fresh files rather than shipping copyrighted MIDI material.

Parts and documentation are often easier to find in Japan than in the Australian market. When ordering from an overseas seller, Australian GST, carrier handling, and customs paperwork may apply to low-value imports; confirm current treatment with the seller or carrier. Melbourne and Sydney retro-computing groups can also provide local knowledge about X68000 ownership, display service, and second-hand pricing.

Method	Repeatability	Hardware coverage	Best use	Main limitation
Generated MIDI sequence	High for timing and event order	FM, optional PCM, and the selected player configuration	Repeatable listening and channel checks	Frequencies are quantized and timbre is patch-dependent
Direct PCM export	Very high	PCM path, DAC, and analogue output stage	Level, noise, and distortion testing	Requires the correct sample format, rate, and X68000 playback software
Manual MIDI keyboard	Low	Broad but inconsistent hardware coverage	Initial diagnosis and familiarisation	Human timing and changing patches make comparisons unreliable

Create a minimal sound-test package with the generator source, a short script, its generated MIDI file, and a playback log. Run it on the original X68000, capture the result, and attach the exact files to the project notes. Publish the package on X68K.NET or a suitable retro-computing archive so owners in Australia and Japan can compare readings, configurations, and repair histories. A documented Human68k generator keeps the platform audible, testable, and useful for future experiments.