Building a Human68k FAT file recovery utility

Deleting a file from an X68000 disk usually changes metadata rather than erasing every sector. On FAT12 and FAT16 volumes, the first byte of its directory entry becomes 0xE5, while name fragments, timestamps, size and starting cluster can remain. The FAT may also preserve the old cluster chain. That residue gives a Human68k undelete utility a basis for recovering deleted files without starting with blind file carving.

A useful utility performs a read-only scan, identifies deleted directory records, reconstructs plausible FAT chains, and writes recovered output to another device. It should separate strong candidates from guesses, retain original timestamps, and report clusters it cannot prove. This approach suits rare software, family archives and working disks, not merely directories with obvious filenames.

Australian collectors face a particular preservation problem. Sydney and Melbourne hobbyists often combine imported Japanese machines with disks acquired through online auctions or local car boot sales, and Australian day-month-year habits can make valid FAT timestamps appear incorrect. A recovery report should therefore show an unambiguous date alongside the raw values, while every recovered byte remains traceable to its source image.

Why deleted files still matter

Many X68000 programs created temporary files, saved data under short names and assumed that deleting a file merely released its space. That assumption worked until the clusters were reused. A disk passed between collectors could also contain duplicates with slightly different names, making a mistaken deletion harder to notice until an important program or document failed to load.

Recovering those files can return lost source code, configuration data and unique copies of early software. Specialist forums, software archives and preservation contacts are gathered in the X68000 community links collection, providing a practical place to compare recovery techniques before releasing a new tool.

Mapping the FAT partition safely

Before searching for deleted entries, the utility must distinguish a logical drive letter from the physical storage layout. Human68k can present partitions through drive letters and device drivers, but a recovery program needs the partition offset and BIOS Parameter Block to interpret the bytes correctly. Probing should establish sector size, reserved sectors, FAT count, FAT size, root-entry count and total sector count.

The low-level reader should calculate the first data sector and translate a cluster number into an absolute sector address. For conventional FAT layouts, cluster two begins at the partition’s first data sector, with each subsequent cluster consuming a fixed run of sectors. Storage reached through an expansion such as Nereid-X also needs its adapter and device mapping documented. Every probe and read operation must remain read-only so a geometry error cannot damage the evidence.

Recovering directory entries and clusters

A deleted file’s 32-byte directory record can retain most of its useful metadata. Clearing the first filename byte marks the record as deleted without necessarily erasing the remaining ten bytes, attributes, creation and modification times, starting cluster and recorded size. Scanning the fixed root-directory area and every live or deleted subdirectory can therefore recover names even when the file contents remain scattered.

Chain reconstruction is harder. FAT12 stores cluster links as packed nibbles, while FAT16 uses explicit 16-bit entries. Surviving links can reveal contiguous or fragmented sequences, but some links may have been cleared when clusters were reused. The utility should combine recorded size, timestamp order, adjacent cluster numbers and the shape of free runs to rank candidates, while preventing two files from claiming the same clusters.

Deleted subdirectories require another pass. Their directory records and allocated clusters must be recovered before child entries can be interpreted, and corrupted allocation links can make unrelated files appear to share a directory. Shift-JIS filenames also need careful decoding: Japanese characters should be displayed correctly, while invalid or ambiguous bytes should remain available in an escaped form for later identification.

Comparing recovery strategies

No single recovery method can handle every damaged directory, overwritten cluster or misidentified chain. The utility should offer several layers and clearly report which method produced each candidate.

Method	What it can recover	Advantages	Weaknesses
Metadata-first undelete	Names, attributes, timestamps, size and starting cluster	Fast and precise when records survive	Cannot recover overwritten data or prove a complete chain
FAT-chain reconstruction	Fragmented contents using surviving FAT entries and adjacency rules	Can restore multi-cluster files	Heuristic links may join unrelated clusters
File carving	Payloads from unallocated sectors using known file signatures	Works after directory metadata is destroyed	Names and boundaries remain uncertain, and false positives occur
Image-first analysis	Everything available from a verified duplicate image	Safest option for the source medium	Requires spare storage and careful image verification

A practical utility should begin with metadata recovery, use the FAT and allocation table to strengthen chain estimates, then offer carving only when normal reconstruction fails. Contiguous candidates deserve priority because they can often be proved from the recorded size and a clear run of free clusters.

Fragmented files need stricter verification. A candidate chain should be checked against free-cluster boundaries, conflicts with other candidates and known file signatures. The report can label results as confirmed, probable or uncertain instead of presenting every reconstruction as equally reliable. Recovered output must always be written beyond the source partition’s allocated area.

Implementing the Human68k utility

The sector reader should form a thin layer over Human68k disk or BIOS services, keeping physical reads separate from FAT interpretation. The Motorola 68000 has a 16-bit external data bus, so the implementation should use byte arrays and explicit little-endian decoding rather than relying on unaligned structure casts. A small sector cache can reduce repeated reads, but every access needs an error result, retry limit and media-change check.

The recovery engine can expose commands such as XREC SCAN, XREC RECOVER and XREC VERIFY. A scan should list deleted records with their confidence, while recovery should select records or clusters individually and write them to a separate drive. Verification can calculate checksums for recovered blocks and compare them with expectations stored in file headers. Path handling must also respect Human68k conventions rather than assuming modern host separators or unrestricted filenames.

Period software is a useful oracle for expected behaviour. Original Human68k programs and operating-system references can be checked through the Japanese software archive, helping a developer confirm command syntax, disk-driver behaviour and the assumptions made by contemporary software.

Testing recovery against copies

Create FAT12 and FAT16 test images containing intact entries, deleted names, fragmented chains and deliberately overwritten clusters. Include files in the root directory, nested directories and directories that were themselves deleted. Fault-injection tests should cover bad sectors, incorrect geometry, unsupported FAT variants and media removal during a read. Running the same cases through a modern implementation provides a useful reference for expected results.

For an original X68000 disk, copy it before attempting recovery. Australian mains supplies 230 volts at 50 hertz, unlike the 100-volt supply commonly expected by Japanese X68000 equipment, so restored hardware in a Sydney workshop needs its power supply checked before use. It is worth having a punt with an image copy first; adapters sold through Australian electronics suppliers can assist, but the geometry presented to the utility must still be verified.

Preserving and sharing recovered data

A safe workflow begins with a sector-for-sector copy or verified image, followed by a read-only scan. Inspect the report, recover only selected candidates to separate storage, and verify the resulting files before releasing any copy as authentic. Keep the source image unchanged and record the tool version, adapter details, source hash and recovery decisions so another hobbyist can repeat the work.

Recover data only from media the operator is authorised to examine, especially when a disk contains personal material. A report stating “probable” or “unallocated” is more useful than false certainty, and uncertain clusters should be retained for comparison with known software rather than silently discarded.

Build the smallest read-only scanner first, validate it against copied images, then share tested recovery code and field notes with the wider X68000 community. Preserve the source bytes, publish verified results and keep every recovered file in the hands of the community rather than allowing another important disk to disappear silently.