Writing a Human68k Mailer for a Serial Modem Emulator

A Sharp X68000 can still perform useful network tasks when modern services are placed behind a simple serial interface. A serial modem emulator presents the familiar Hayes-style command set, then carries the resulting connection across Ethernet or Wi-Fi. To a Human68k program, the process looks much like using a dial-up modem: open the RS-232C port, issue AT commands, wait for CONNECT, and exchange text with a remote mail server.

Sending email this way is a valuable exercise in retrocomputing because it joins old and new systems without hiding the original machine behind a contemporary operating system. The X68000 remains responsible for the user interface, file handling and protocol logic, while the modem emulator supplies the modern network transport. With careful buffering and conservative SMTP commands, even a modest C program can deliver a message from an X68000 desktop.

Why This Project Fits The X68000

Human68k was designed around a practical command-line environment, compact utilities and direct access to hardware. An email sender can follow that tradition: accept a destination, subject and text file, establish a serial session, and report each server response in plain language. There is no requirement for a graphical client, a large TCP/IP stack or a hard disk filled with dependencies.

The project also suits the preservation goals of X68K.NET. A program that speaks SMTP over a modem-style connection documents an important transition between standalone computers and networked services. It can be used for sending notes from a restoration bench, transferring diagnostic logs, or reporting the result of a hardware test to another machine.

The same workflow can support digital preservation. If an X68000 is being used to catalogue scanned negatives, the message could contain a small inventory or a checksum report rather than the image itself. A related example is this guide to a custom slide adapter, which illustrates how specialised scanning hardware often benefits from carefully documented, small-scale modifications.

Choosing The Serial Hardware

The simplest arrangement uses the X68000’s RS-232C connection and a modem emulator configured for a known speed, such as 9,600 or 19,200 bits per second. Begin with 8 data bits, no parity and one stop bit. Hardware flow control can be useful, but it should be enabled only when the cable and emulator both support RTS and CTS correctly.

A USB modem emulator is convenient on a modern network, although the X68000 should see a genuine serial interface rather than a USB protocol presented directly to Human68k. A small network appliance with an RS-232 port is often easier to configure. It may expose an Ethernet client connection, Wi-Fi bridge or remote TCP socket while retaining an AT command interface on the serial side.

Australian builders can usually find DB9 cables, gender changers and null-modem parts through Jaycar, RS Components Australia or local electronics suppliers. Second-hand listings on eBay Australia and Gumtree can also be useful, but cable wiring should be checked with a multimeter rather than assumed from a photograph. Australia’s 240-volt mains supply makes an isolated, properly enclosed power adaptor especially important when a bench contains both imported Japanese equipment and modern network hardware.

Designing The Human68k Program

The application should be divided into four layers: serial input and output, modem session control, SMTP conversation handling, and command-line or file processing. This separation makes the code portable between compiler libraries. Human68k development environments vary, including GCC ports, Lattice C and older commercial toolchains, so direct IOCS calls should be isolated in a small source file.

The serial layer needs functions resembling serial_open, serial_puts, serial_getline and serial_close. Their implementation may use the compiler’s device functions or X68000 IOCS serial routines. The rest of the program should not care whether a byte was sent through an IOCS call, a DOS device handle or a locally written driver.

Line handling deserves particular attention. SMTP uses lines terminated by carriage return and line feed, while a terminal may display only one of those characters. Store incoming bytes in a bounded buffer, convert the server’s line ending to a convenient internal form, and reject overlong responses. A fixed 512-byte buffer is ample for normal SMTP replies and avoids the memory-management surprises that can complicate older C libraries.

Preparing The Modem Session

The program should reset the emulator into a known state instead of trusting its previous configuration. A typical sequence is ATZ, followed by a short delay and ATE0 to disable command echo. If the emulator requires a network destination, commands such as ATD mail.example.net or a vendor-specific TCP command may follow. The exact syntax belongs in a configuration file or command-line option rather than being scattered through the source.

After the emulator reports CONNECT, the program must stop sending modem commands and begin treating the serial stream as a remote SMTP session. This boundary is easy to mishandle. A delayed echo, an extra carriage return or a modem status message can be mistaken for an SMTP greeting. The session code should drain expected modem output, then wait for a line beginning with a three-digit SMTP status code.

SMTP responses can be multiline. A line such as 250-example.net is followed by additional capability lines, and the final line uses 250 with a space after the code. The response reader should continue until the fourth character is a space. Checking only the first response line may cause the X68000 to send credentials or message data before the server is ready.

Sending The Message

The SMTP conversation normally begins with EHLO x68000, although a small server may accept HELO x68000. The client then issues MAIL FROM:<sender@example.net>, one or more RCPT TO:<recipient@example.net> commands, and DATA. The message headers and body follow, ending with a line containing a single full stop.

A minimal message might look like this:

From: x68000@example.net
To: archive@example.net
Subject: Bench report

Power supply inspection completed.
Serial modem link is operational.
.

Every transmitted line should end in CRLF. SMTP also uses dot-stuffing: if a body line begins with a full stop, transmit two full stops. Without this rule, a line containing only . could terminate the message prematurely. The program should convert the input file’s Human68k line endings while it reads, rather than loading the entire document into memory.

Modern hosted mail services generally require TLS and authenticated submission, which is beyond a basic serial SMTP client. The modem emulator might provide a secure tunnel, or a local gateway can accept plain SMTP from the X68000 and relay through an authenticated account. This arrangement keeps certificates and encryption on a maintained machine while leaving the Human68k application small and inspectable.

A Practical Implementation Skeleton

The following pseudocode shows the structure without pretending that every Human68k compiler exposes identical serial APIs:

int main(int argc, char **argv)
{
    char line[512];

    serial_open(19200, 8, 0, 1);
    modem_command("ATZ", 3000);
    modem_command("ATE0", 1000);
    modem_connect("mail-gateway.local", 25);

    expect_smtp(220);
    smtp_command("EHLO x68000", 250);
    smtp_command("MAIL FROM:<x6800@example.net>", 250);
    smtp_command("RCPT TO:<archive@example.net>", 250);
    smtp_command("DATA", 354);

    send_line("From: x6800@example.net");
    send_line("To: archive@example.net");
    send_line("Subject: X68000 report");
    send_line("");

    while (read_text_line(line, sizeof(line))) {
        if (line[0] == '.')
            serial_putc('.');
        send_line(line);
    }

    send_line(".");
    expect_smtp(250);
    smtp_command("QUIT", 221);
    serial_close();
    return 0;
}

In real code, smtp_command should write a CRLF, read a complete response and compare the numeric status. It should also handle temporary failures, such as 421 or 451, without sending the next command. A clear error message such as RCPT rejected: 550 is much more useful on a 1980s monitor than a generic 通信 error.

Credentials should not be placed directly in the executable or mailed configuration file. If authentication is unavoidable, use a gateway on the local network and restrict it by IP address or serial device. A small configuration file can contain the gateway address, sender and recipient, while the message body remains an ordinary Human68k text file.

Testing The Link Safely

Testing should start without sending real mail. Connect the serial emulator to a local SMTP test service or a gateway that records the conversation. Confirm that ATZ and ATE0 receive expected responses, then check that the program recognises 220, 250 and 354 replies. A terminal program is useful for observing the exact byte stream before debugging C code.

Use a short subject and a body containing blank lines, long lines and a line beginning with a full stop. Test a recipient that the gateway deliberately rejects, then verify that the program stops rather than continuing to DATA. Disconnect the network during the session and check that a timeout returns control to Human68k instead of leaving the machine apparently frozen.

Performance can be measured with a simple timestamp or byte counter. At 9,600 bits per second, a plain text report transfers comfortably, but a large attachment would be slow and difficult to encode. Avoid MIME at first; send plain text and place binary files on a better-supported transfer service. For Australian users working from regional areas, this also reduces dependence on an unstable NBN or mobile connection during the modem gateway’s network leg.

Preserving The Complete System

A working mailer is more valuable when its environment is recorded. Keep the source code, compiler version, serial settings, modem emulator firmware, wiring diagram and gateway configuration together. Note whether the cable is straight-through or null-modem, which port is selected, and whether the X68000 expects hardware flow control.

Hardware preservation can include small additions that make repeated testing safer. Battery-backed SRAM, for example, can retain configuration or diagnostic state across power cycles; the SRAM expansion project demonstrates the kind of expansion-bus work that complements a network utility. Any battery modification should be documented with its cell type, isolation method and replacement procedure.

Area	Recommended starting point	Reason
Serial speed	9,600 or 19,200 bps	Reliable on old cables and easy to diagnose
Framing	8 data, no parity, 1 stop bit	Common modem-emulator configuration
SMTP mode	Plain text through a trusted gateway	Keeps TLS and authentication off the X68000
Message size	Short reports and logs	Avoids slow transfers and complex MIME handling
Error handling	Check every status code and timeout	Prevents corrupted or half-sent messages
Documentation	Save source, wiring and settings	Makes the setup reproducible years later

The finished utility can become part of a broader X68000 toolkit: a diagnostic reporter, a restoration log sender or an archival notification client. Start with a local gateway, a conservative serial speed and plain text. Once the byte-level conversation is reliable, add command-line options, multiple recipients and formatted reports while keeping the original minimal mode available.

Build the program around transparent serial I/O, test it against a controlled SMTP endpoint, and preserve the source alongside the machine. That approach turns a modem emulator into more than a novelty: it becomes a dependable bridge between Human68k software and today’s networked world.