A Native Disassembler for Human68k Executables

Human68k gave the Sharp X68000 a command-line environment that still feels familiar, yet its .EXE files are not generic disk images. A header describes the program, while the body may contain executable code, initialised data, relocation records and optional symbols. A dependable disassembler must understand that container before it can turn bytes into meaningful Motorola 68000-family instructions or expose what a suspect executable is really doing.

Building a native utility is a practical way to inspect software without modifying disks or relying on a particular emulator. The program can parse the file, establish a code range, decode instructions and send the result to a screen or text file. For hobbyists in Melbourne and Sydney, that means a small tool that can be tested on original software and shared with other collectors rather than one more obscure desktop package.

Build strategy	Benefits	Constraints	Best fit
Host-native parser	Quick bulk analysis, simple fuzzing, easy scripting	Does not itself run on X68000	Building and testing the decoder core
Native Human68k build	Runs on real or emulated X68000 systems	Human68k toolchain, constrained memory	Inspecting original media at the bench
Shared-core hybrid	One decoder, different I/O and output adapters	More build and release work	A maintained community tool

Separate the Container from the Code

Start by defining an input contract. Accept a file as an opaque byte stream, then decode the documented Human68k header fields for load address, entry point, text and data extents, BSS size, and relocation, symbol or line information where present. Header variants matter: a utility intended for later X68000 models should not assume every file uses the same optional fields. Keep format knowledge in one module so it can be extended without disturbing the instruction decoder.

The CPU profile is a separate decision. The original X68000 uses a 68000, while later models provide 68010, 68020 and 68030 processors, with 68040 and 68060 systems appearing at the high end. These generations share the core encoding but differ in reserved instructions, extensions and system instructions. A file may not identify its target processor, so let the user select a profile and refuse unknown encodings instead of inventing a mnemonic.

Treat every length and offset as untrusted input. Human68k stores multibyte values in Motorola big-endian order, so decode them explicitly instead of overlaying a packed C structure on the buffer. Check every addition and subtraction for overflow, confirm that ranges lie within the file, and distinguish a BSS allocation from bytes that are actually present. Missing relocation or symbol data should produce a warning, not an excuse to read unrelated data as code.

Give Every Byte a Logical Address

A file offset is not automatically a runtime address. Build a map from file ranges to the addresses at which the loader would place them. For a simple segment, the relationship is load address + (file offset - segment start), but using explicit segment records prevents errors when text and data occupy different ranges. Anchor automatic analysis at the declared entry point, and let the user supply start and end addresses when the header is incomplete.

Relocation information must be treated as metadata about address operands, not as a sequence of instructions. It can reveal which absolute references the loader will adjust, while symbol records can supply labels for routines and variables. A static view should preserve the original bytes and optionally show the effect of relocation at a chosen base. PC-relative branches generally need different handling because their target is calculated from the instruction’s own address.

The output should place a logical address, the exact source bytes, the mnemonic and decoded operands on one line, for example 00001000: 4E B9 00 00 10 00 JMP $00001000. Labels, relocation notes and confidence markers belong in separate columns. For Japanese-language format notes and period software references, the TFO Sorcim resources can be a useful cross-check, but every documented field should still be verified against local sample files.

Build a Conservative 68k Decoder

A 68k instruction is rarely encoded in a single 16-bit word. The opcode selects a row in the processor’s instruction matrix, while extension words describe an immediate value, displacement, bit number, register list or effective address. Construct the decoder from that matrix rather than a collection of pattern matches. Each opcode entry should return the instruction length, the mnemonic and enough operand detail to reproduce the original encoding.

Effective-address handling is where many naive disassemblers fail. They must decode register direct, register indirect, postincrement, predecrement, displacement, index, absolute and PC-relative forms, including 16-bit and 32-bit extensions where the processor permits them. PC-relative targets depend on the complete instruction length. Extensions introduced by the 68020 and later processors must be enabled only for the selected profile; otherwise emit the raw data and identify it as an unknown opcode.

A stable output format makes later work much easier. Keep the original bytes, use fixed-width hexadecimal addresses, and separate the mnemonic from operand annotations. For example, 4E 71 should decode as NOP, while bytes that do not form a valid instruction in the active profile should appear as literal data. Never guess a branch target from a nearby address, and never follow a pointer automatically; linear disassembly has no way to prove that the next bytes belong to code.

Test the decoder at the opcode level before trying whole programs. Build vectors for every supported mnemonic and addressing mode, including boundary conditions such as a displacement at the end of a file. Golden output files should make changes visible, while malformed-input tests should confirm that the parser stops cleanly instead of reading beyond its buffer. An emulator trace can then validate selected addresses, but it should complement rather than replace the decoder’s own tests.

Package the Decoder as a Human68k Program

Keep the decoding core independent of the user interface. A portable layer can define addresses as 32-bit values, decode big-endian words and expose an instruction structure; a Human68k layer can handle command-line arguments, file reads, screen output and text-file writing. This split lets most edge cases be tested quickly on a modern development machine, then run the same logic in an emulator or on the target hardware. Because early X68000 memory configurations are small, stream the input rather than loading the whole file.

A useful native command line should stay simple: H68DIS -CPU 68020 -START 00001000 -END 00002000 GAME.EXE. The exact switches can vary, but the utility needs a CPU profile, an input file, an optional address range and an optional output file. Report a malformed header, unsupported instruction or truncated range as a specific error, and return a non-zero status so scripts can react. Buffer output by line to keep memory use low.

Watch the executable format produced by the build chain. Many modern cross-compilers produce ELF objects or executables, which are not Human68k .EXE files merely because they target a 68000. Use a compiler and linker whose final output uses the Human68k executable format, or a verified converter, and inspect the resulting header before distribution. The same care applies to source paths and case handling; Shift-JIS filenames copied from Japanese disks can be silently altered by a naive host tool.

Real-hardware testing adds a familiar Australian constraint. Australian mains is 230 V with Type I plugs common on many older computers, while many Japanese X68000 units expect 100 V. Check the label on every machine and use an appropriately rated step-down or isolation transformer where needed. A travel plug changes the shape of the connection, not the voltage, and an unsuitable supply can destroy more than the operating system.

Validate the Tool and Publish It

Validation should cover more than clean compiler output. Test hand-written assembly, commercial software, freeware, data-heavy utilities, executables with missing symbols and deliberately damaged headers. Copy-protected or packed code may look like noise; the correct behaviour is to identify the unreadable region, not to pretend it is valid 68000 code. Keep hashes of every sample and never modify the only copy of a disc or tape.

Crash analysis is where static output becomes especially valuable. For a fault, compare the disassembly with the runtime image described by X68K.NET’s memory dump tool, which helps map a bad address back to live code and data. The disassembler should annotate those addresses, while the dump supplies the values that existed when the crash occurred.

Australian collectors also need a preservation-friendly workflow. Imported Japanese systems may attract customs duty and GST, with thresholds and concessions changing over time, so check current Department of Home Affairs and Australian Border Force guidance before using a courier. Local listings on eBay Australia and Gumtree can be useful, but compare model numbers and voltage requirements before buying. When posting media or boards, use a sturdy padded mailer, antistatic protection and dry packing; Sydney’s humid summers are a good reason not to skip moisture control.

The first release should have a deliberately narrow promise: support the 68000 profile, parse the common Human68k header variants, produce address-and-byte listings and pass the documented test corpus. Document unsupported fields and damaged-file behaviour beside the command examples, then publish the source, sample files and checksum list. Release that build with its known limitations stated plainly, and collect crash cases that expose header variants the initial parser has not yet handled.