Writing a Human68k Patch to Enable 80-Column Text in Standard Mode

The stock Human68k command interpreter presents its console in a 31-column text arrangement, even though the X68000’s programmable CRT controller and graphics RAM can describe a much wider raster. A wider 80-column console therefore does more than make the screen look wider. It changes the machine’s agreement about character cells, memory addresses, cursor movement and display timing. Learn more about Ubuntupodcast.net.

Here, standard mode means the normal 31-column console, not every 512- or 1024-pixel graphics mode available to software. The safest patch is built against one exact Human68k release, tested from a known disk image and documented so it can be reversed. That discipline matters because valid display-register writes can still produce corrupt text when the command interpreter continues to scroll as though each row were only 31 characters wide.

What the stock text mode assumes

Three layers must agree for the new console to work. The CRTC supplies horizontal and vertical timing. Software places glyph pixels and advances the scan address for the next row. Human68k and the routines it calls maintain the logical cursor, clear lines and scroll text. Altering only the hardware sweep produces either a stretched image, corrupted characters or a cursor that wanders away from the prompt.

The X68000 exposes its HD6845-compatible CRTC through an index register at $E84000 and a data register at $E84002. Its graphics RAM begins at $E00000, while normal memory contains Human68k’s code and console state. CRTC register pairs R0–R3 define horizontal total, displayed width and synchronisation, while R12–R15 hold display and cursor addresses. Exact values and any extension bits must come from the target machine, not a generic PC text preset.

A patch also has to replace every assumption that a row occupies a 31-character span. That includes line addressing, the bottom-right cell, cursor columns, clearing and scrolling. Programs may save or restore the screen through BIOS calls rather than direct graphics-RAM writes, so both paths must be watched during tracing. A useful patch exposes the original geometry as a restore path instead of silently replacing it.

Establishing a safe test system

Begin with a preserved copy of the boot disk and record the Human68k version, executable checksum and normal command-line output. Create a writable duplicate for experiments and keep the master image unchanged. Cold-boot both copies in an X68000 emulator, save a graphics-RAM snapshot and record the CRTC registers after the prompt appears. A clean baseline makes later timing and layout changes measurable rather than anecdotal.

Use a 68000-capable disassembler and an emulator with I/O breakpoints. Break on writes to the two CRTC addresses, then follow callers back to the mode request. Record the index-and-value sequence, nearby constants and any writes to display memory. Repeat with a full-screen program and a return to the shell. This often separates Human68k’s startup code from routines already supplied by the X68000 BIOS.

An emulator also lets you test a narrow timing profile before touching real hardware. For broader preservation practice, discussions around older Unix installations in the Ubuntu Podcast archive are a useful reminder to snapshot first and automate repetitive checks. Return each test to the saved disk image rather than accumulating undocumented changes.

Finding the video path through Human68k

Begin at the routine that writes the stock horizontal values, not at a hexadecimal sequence that merely resembles them. In 68000 code, a MOVE.W immediate to an absolute address is more useful than searching for the data alone. Recover the instruction boundary, read signed branches and tables as signed quantities, and follow any pointer in the mode structure. Nearby code often reveals whether values are copied directly or transformed from a character count.

Map each CRTC write to its register and purpose. Preserve the vertical total, adjustment, displayed rows, interlace mode and cursor scanline unless the selected raster explicitly changes them. Set horizontal total, display start and end, and sync position from one internally consistent profile. The controller counts character cells, and some register conventions store an end position differently from a cell count. Copying isolated values from another machine can shift the raster or place the sync pulse outside the active scan.

Trace output through the installed handler and any higher-level screen abstraction it uses. Capture the cursor address, row pitch in addressable units and values passed to clearing and scrolling code. Do not assume that eighty columns means eighty bytes per line: packed pixels, duplicated scan cells or a different graphics resolution can change the stride. If Human68k redraws the screen with a second mode-set call, patch that central call too.

Building an 80-column replacement

Choose the target raster before writing the hook. An 80-cell line made from 8-pixel glyphs requests 640 active cell pixels, which will not fit the same raster as the stock console in every X68000 display arrangement. A monitor that accepts a wider horizontal mode may retain 8×16 glyphs. A 512-pixel arrangement instead requires a deliberately redesigned glyph, row layout and scan timing. Those are different preservation goals.

For a 512-pixel layout, derive the address stride from the selected pixel format and pack glyph rows accordingly. Generate test glyphs for ASCII symbols and the Japanese characters used by the application, then adjust bold, reverse-video and colour handling if it exists in that text path. Keep the original 8×16 font available for restoration. Vertical row count and cell aspect ratio should be recorded with the patch rather than presented as universal defaults.

Implement the change as a small mode routine plus patched console helpers wherever source or a controlled binary build is possible. A resident sidecar can be useful for testing, although Human68k may overwrite its settings or reclaim memory on a mode change. Keep timing data, geometry values and code in one documented patch record with the original bytes and a stated Human68k version.

video_patch:
    preserve registers, status and old display state
    program the tested horizontal CRTC profile
    set console width to 80 and apply its row stride
    clear the text plane and place the cursor at home
    redraw the prompt through the patched output path
    restore temporary state and return to the caller

For a binary hook, find an instruction-aligned cave in resident or allocated memory. An ordinary code entry can be overwritten with a six-byte absolute JSR—4EB9 followed by a 32-bit address—with the displaced instructions replaced by NOPs. The replacement saves the registers and status it alters, installs the tested CRTC profile and updates console state. Return with RTS for a subroutine hook; use RTE only when replacing an exception vector. Validate the entire overwritten sequence, not just its apparent length, and chain relocated original code when it performs duties beyond mode selection.

Installing and validating the patch

Test first in an emulator with writes to graphics RAM watched. Draw every glyph, full and empty rows, cursor motion, long filenames and Japanese text near cell boundaries. Exercise scrolling in both directions, screen clear, error output and a switch from a full-screen program back to the shell. Compare addresses and visible rows against the intended geometry, not merely whether characters are legible.

On physical hardware, begin with a low-resolution raster and a known-good monitor. Check horizontal centring, sync stability, brightness at the left and right edges, cursor contrast and any wrapping in the final column. Run a sustained scrolling test while watching for instability, then reboot to detect lost state. A stable first line does not prove that memory addressing is correct.

Compatibility failures are expected because some software assumes 31×16 cells, reads the old console dimensions or restores its own CRTC register set. Keep a stock launcher and a patched launcher, and make the patched environment opt-in rather than silently replacing the boot disk. If a program resets the screen, its exit path may need the same hook. Record every fallback in plain text beside the binary.

Finally, reapply the patch to a fresh copy of the intended image and verify the checksum, boot result and prompt width automatically. A reversible binary patch is documentation as well as code: offsets, byte replacements, CRTC values, memory layout, tested Human68k revision and known failures should travel together.

Australian hardware and preservation considerations

An Australian build brings two electrical and video constraints into the test plan. Japanese X68000 sets commonly output NTSC, whereas much of Australia’s legacy television equipment used PAL-B/G at 50 Hz. Many analogue monitors and TVs still lack the required RGB and sync arrangement, and a region-locked digital scaler may reject it. Test video standards and sync polarity separately; PAL compatibility does not guarantee usable text.

The machine also expects 100 V Japanese mains, while Australian supplies are 230 V at 50 Hz. A plug adapter does not convert voltage. For a machine that will be used regularly, a properly engineered 230 V replacement supply is safer than repeatedly changing jumpers or using an isolation transformer as a permanent arrangement. Keep mains work outside the case, discharge and ESR-test capacitors, and use a suitably qualified electrician where local rules require one.

Parts are scarce, and freight is disproportionate to their value on the Australian market. Compare listings on Australian eBay and Gumtree with specialist dealers, then check Japanese sales carefully because condition reports and return options differ. Goods over the A$1,000 low-value threshold can require customs formalities and GST; commercial importers may have additional obligations. Carrying a tested machine to a Sydney or Melbourne retro-computing group can be cheaper than repeated express shipping, while local humidity controls still matter.

The curated community reference links are a better starting point for locating X68000-specific schematics, replacement power supplies, emulators and people preserving similar machines. Add verified part numbers and Australian electrical observations to that record rather than treating a marketplace listing as proof of compatibility. Before applying a modification, reproduce it on a duplicate disk and verify the result under load.

Feature	Standard console	Patched console
Usable text width	31 columns	80 columns
Glyph geometry	Fixed 8×16 cells	Existing or repacked glyphs, explicitly recorded
Display timing	Known X68000 profile	Tested horizontal CRTC profile
Row addressing	Stock stride and boundaries	New stride with boundary checks
Cursor and scrolling	Original Human68k handlers	Width-aware patched handlers
Program compatibility	Best for legacy assumptions	Some software may reset the mode
Recovery path	Original executable and disk	Restorable image plus documented offsets

Start with a reversible, version-specific experiment: preserve the boot image, publish the disassembly notes and CRTC values, and demonstrate an 80-column prompt before adding Japanese glyph or colour work. Keep the first successful build on a write-protected disk image so another Australian owner can test, repair or reject it without damaging the only working copy.