Printing X68000 System Information with a Human68k Tool

The Human68k operating system gives the Sharp X68000 a practical command-line environment, but much of the machine’s most interesting information is scattered across runtime calls, BIOS data, disk configuration and expansion hardware. A small system-information utility can collect those values, format them as plain text and send the result to a dot-matrix printer. That combination is useful for documenting a restored machine, diagnosing changes and creating a durable record before components are moved or modified.

The tool does not need to be a full-screen application. It can print a labelled report containing the Human68k release, X68000 model and clock, memory map, available disks, date and time, plus any expansion identifiers it can query. Keeping the output ASCII avoids the usual mismatch between Japanese character sets and a printer configured for a Western code page. It also makes the report readable on a modern terminal and easy to archive as a text file.

For an Australian hobbyist, the dot-matrix printer is often more than nostalgia: it provides an impact record that does not depend on toner, ink cartridges or a proprietary printer driver. The machine can run unattended, produce continuous-feed pages and remain useful when contemporary software no longer exists. Writing the utility as a narrow Human68k program also creates a reusable diagnostic for the wider X68000 community rather than a one-off display.

Define the report before touching the printer

Start with a fixed report layout so every page can be understood without the computer. Give each field a stable label and value, including the Human68k version, machine identifier, CPU clock, installed memory, disk units and free space, real-time clock and expansion information. Reserve a clearly worded “not reported” or “unknown” value for fields the running system cannot expose. Guessing would turn a useful preservation record into plausible fiction.

Treat the data sources as layers. Human68k runtime calls can provide operating-system facts, while an X68000 BIOS helper can answer machine-model, clock and memory questions. Disk enumeration and remaining space usually come from the Human68k or DOS-compatible interface. The exact prototypes differ between compilers and runtime versions, so keep those details inside one platform file rather than spreading them through the formatter. A timestamp should come from the X68000 when available; the host compiler’s date is only build metadata.

Keep the portable side deliberately plain: a report writer, a text formatter and a platform-specific collector. The account of migrating a monolith on AWS ECS is an unlikely but instructive analogy: large systems benefit from clear boundaries between stable components. Here the stable boundary is the report writer, while a small platform layer owns Human68k and BIOS calls. That structure is easy to test, easy to port to another X68000 and free of any cloud dependency.

Build the Human68k reporting core

A Human68k-compatible C compiler is enough for the portable code, while the collector may need the X68000 BIOS interface from the selected development kit. Build a native command that returns zero on success and reports failures on the screen. The following skeleton shows the important separation; x68k_collect() is the only platform function still to be implemented for the target SDK.

#include <stdio.h>
#include <string.h>

void x68k_collect(FILE *out);

int main(int argc, char **argv)
{
    FILE *out = stdout;
    int close_out = 0;

    if (argc == 2 && strcmp(argv[1], "/PRN") == 0) {
        out = fopen("PRN", "w");
        if (out == NULL) {
            fputs("XREPORT: printer device unavailable\r\n", stderr);
            return 1;
        }
        close_out = 1;
    }

    fputs("X68000 SYSTEM REPORT\r\n", out);
    x68k_collect(out);
    fputc('\f', out);

    if (fflush(out) != 0 || ferror(out)) {
        fputs("XREPORT: output error\r\n", stderr);
        if (close_out)
            fclose(out);
        return 1;
    }

    if (close_out && fclose(out) != 0) {
        fputs("XREPORT: printer close failed\r\n", stderr);
        return 1;
    }

    return 0;
}

Implement x68k_collect() with a Human68k date and time call, disk and volume queries, and a small BIOS routine for the CPU clock and memory layout. Human68k development packages expose these facilities through slightly different headers and names, so consult the documentation shipped with the compiler rather than copying modern PC prototypes. An inline assembly stub or a tiny object module is acceptable when the public C library does not expose the BIOS call.

Default output should go to standard output. Then the operator can inspect it, redirect it with a command such as XREPORT > XREPORT.TXT, and copy the file to an installed printer device when testing. The sample’s direct mode assumes an installed Human68k printer driver has reserved PRN as a device. Do not assume that name across every installation; some systems use another device or treat it as an ordinary filename. Check output errors and the return from closing the device, because opening a spool file successfully does not prove that paper is present or that the head is online.

Connect the dot-matrix hardware

Choose the printer interface before writing more output code. Connect the X68000’s Centronics-style parallel port, where fitted or through the appropriate expansion hardware, and configure the printer’s DIP switches for parallel operation rather than serial. A 9-pin or 24-pin Epson-compatible unit can print the report with plain ASCII, but matching the line endings and character set matters more than its advertised resolution. Use carriage return and line feed for each row and a form feed at the end of the report.

Australian mains is nominally 230 V at 50 Hz, whereas Japanese equipment commonly expects 100 V at 50 or 60 Hz. A Japanese-market printer marked for 100 V must never be connected directly to Australian supply. Use an appropriately rated step-down transformer if the printer lacks a universal input, and check the motor and cooling requirements rather than relying on the wattage printed on the nameplate alone. Importing the unit may also attract GST, customs duty and carrier handling charges, so include those costs before buying through an overseas seller.

Paper is another practical difference. Australian offices commonly use A4 at 210 by 297 mm, while many Japanese dot-matrix printers were supplied for JIS B4 at 257 by 364 mm or continuous fanfold stock. A tractor-feed machine can still print A4 by adding tractor holes to ordinary paper or by using correctly sized continuous stock. Choose a line width and margins that suit the available mechanism, then keep the same paper path for every test.

Local searches on eBay Australia and Gumtree are practical starting points for collectors in Sydney and Melbourne seeking an Epson-compatible dot-matrix printer, tractor feed or genuine Epson service manual. Check the printer under load rather than trusting a listing photograph. In Brisbane’s humid summers, store fanfold paper and spare ribbons in a dry cabinet, and leave ventilation around the power supply.

Verify the output under real conditions

Test the path in three stages. First run XREPORT and compare the fields with known machine facts. Second, redirect the report to disk and inspect it in a text editor for wrapped labels, missing values or stray control characters. Third, send the file to the printer. This sequence separates a reporting bug from a device or interface problem before the old hardware is involved.

During the physical test, print a short sample with letters, digits and punctuation before attempting the full report. Check tractor alignment, head clearance, ribbon tension and line spacing at both the top and bottom of the page. Verify the form feed after the last line, and test paper-out and offline conditions if the printer exposes a status switch. Basic text mode should be repeatable even when an ESC/P driver is unavailable.

Cross-check unusual results against the physical machine and published X68000 references. In particular, compare the memory total, clock setting and any Nereid-X identification with the X68000 community notes and the board layout inside the case. The collector should state how each value was obtained; a BIOS identification and a manually entered label are not the same kind of evidence. Omit serial numbers and personal paths from any report intended for publication.

Package the tool for the X68000 workflow

Package the program as a clearly named Human68k command, such as XREPORT.COM, and keep its source beside it. The source is the durable artefact; a binary on a disk image may be lost, altered or written with a different filesystem convention. Include the compiler version, build options, sample output and known hardware assumptions in a short README. Generate a checksum on a modern host and record it with the preserved files.

Make expansion reporting honest rather than decorative. If the Nereid-X BIOS or configuration block exposes a stable identifier, print the board name and revision and mark other fields as unavailable. Do not identify a board solely because the memory total happens to match an expected configuration. Human68k versions and modified X68000s may expose different data, so the collector needs a clear fallback path for each source.

Use the printed sheet as part of a restoration log, not as a substitute for one. Run the report before and after a memory change, firmware operation or board installation and record the relevant output alongside the date and hardware revision. Keep the text copy on disk, store a clean test print for the printer, and document DIP-switch settings so the setup can be repeated when the machine changes hands.

Create the first usable version today: compile one collector that reports the Human68k version, X68000 model and memory, send it to standard output and verify every label against the running machine. Add disk and expansion data after the basic report survives a console run, a redirected file and a physical print. Then archive the source and sample output with the X68000 notes, label the printer configuration and share the results with other users of the platform, preserving every corrected memory figure, newly identified expansion card and reliable settings printout.