A Human68k File Copy Utility for Floppy and Hard Disk

The Sharp X68000 remains unusually rewarding to maintain because its hardware and software are accessible at the same time. A small command-line program can make a major difference: copy a disk image or working file from a floppy drive to a hard disk, move a patched executable back to floppy, and preserve the original media without relying on a modern PC every time.

A Human68k utility for this job should feel native rather than act as a crude raw-sector tool. It needs to understand drive letters, Japanese filenames, disk-change errors, file attributes, and the practical limitations of ageing floppy hardware. With a careful design, the result can be useful on an original X68000, an accelerator-equipped machine, or a compact restoration bench in Australia.

Define The Copying Job

The simplest use case is a one-way file transfer such as XFCP A:\GAME\*.X C:\BACKUP\. The program opens files through the Human68k DOS interface, reads them in manageable blocks, and writes them to the hard disk. The reverse direction is equally valuable when preparing a boot disk, transferring a configuration file, or testing a newly compiled program on real hardware.

It is safer to treat the filesystem as the main interface instead of reading floppy tracks directly. Human68k and its disk drivers already know the media geometry, directory layout, allocation units, and device-specific behaviour. A file-level copier can therefore work with floppy formats supported by the installed system, while a raw imaging program should remain a separate tool with a different purpose.

A useful command syntax might include:

XFCP source destination
XFCP A:\TOOLS\*.* C:\TOOLS
XFCP C:\PATCHED\GAME.X A:\GAME.X
XFCP A:\DISK1\ C:\ARCHIVE\DISK1 /S /V

Options such as /S for subdirectories, /V for verification, and /R for replacing existing files are enough for a first release. Avoid making the syntax depend on modern Windows conventions. Short, predictable switches suit a machine normally operated from a monochrome monitor, a small CRT, or a serial console.

The destination rules should be explicit. If a source path names a single file, the destination can be either a new filename or an existing directory. If a wildcard is used, the destination must be a directory. Refusing ambiguous operations is preferable to silently overwriting a valuable save file or a hard-won patched binary.

Use Native Human68k File Operations

The implementation should use the DOS file-handle functions exposed by the selected Human68k compiler. Different development environments may give these calls different names or wrappers, so the source should isolate them behind a small portability layer. Typical operations are open, create, read, write, close, seek, enumerate directory entries, obtain attributes, and set the file date and time.

A binary copy loop is deliberately unglamorous:

open source for binary read
create temporary destination
repeat
    read a block
    stop at end of file
    write the complete block
    report read or write errors
close both handles
verify when requested
rename temporary file to final name

A buffer between 8 KB and 32 KB is a sensible starting point. It reduces DOS call overhead without consuming an unreasonable portion of conventional memory. The utility should check the number of bytes returned by every read and write. A successful write of fewer bytes than requested is an error, not an invitation to continue.

Writing to a temporary name is particularly important on floppy media. A power interruption, accidental disk removal, or failing drive can leave a partially written destination. A name such as FILE.XCP can be removed after a successful copy, while the temporary file is renamed only after the final flush and optional verification. This leaves a clear recovery path when something goes wrong.

For verification, seek back to the start and compare the destination with the source in blocks, or close both files and reopen them before comparison. A simple byte comparison catches most transfer errors. A checksum displayed at the end is also helpful for records, although it should not replace direct verification when preserving rare software.

Handle X68000 Media Sensibly

Floppy drives deserve conservative treatment. A utility should open the source only when needed, display a clear message before a disk change, and make it obvious whether the program expects drive A: or B:. Human68k systems can be fitted with different drive arrangements, and a user may have a single internal drive plus an external unit. Do not assume that every machine has the same device names or capacity.

The program should preserve useful metadata where the filesystem provides it: filename, extension, attributes, date, and time. Read-only files should not be overwritten unless /R is supplied. Hidden and system files should be copied when the user explicitly names them, while wildcard operation can offer an /A option to include every attribute. This is relevant to boot disks, where a file that appears unimportant may be required by a startup script.

Japanese text handling requires care. A filename may contain Shift-JIS characters, and a compiler or terminal may not display them correctly. The copier does not need to translate names into Unicode. It should preserve the byte sequence supplied by the Human68k filesystem and avoid assuming that every character is printable in the status line. Logging the path in hexadecimal or quoting unprintable characters can help diagnose a troublesome disk.

Do not confuse a file copier with a disk duplicator. Copying COMMAND.X and a collection of game files does not reproduce boot sectors, hidden system areas, unused sectors, or copy protection. A complete floppy archive needs a sector-level imaging method. The file utility is best for moving selected content, extracting a program from a disk, and transferring working data to a hard disk.

That distinction is useful in Australia, where replacement media can be expensive and inconsistent. A Japanese X68000 found through eBay Australia or Gumtree may arrive with only one readable disk, and freight from Sydney or Melbourne to a regional town can cost more than expected. Copying every readable file to a hard disk before experimenting gives the owner a practical safety net.

Build For Real Hardware

Error messages should describe the operation and the likely remedy. “Write failed” is less useful than “cannot write C:\ARCHIVE\GAME.X: disk full” or “read failed on A:, check that the disk is inserted and the drive door is closed”. Distinguish media errors, access errors, invalid paths, insufficient space, and user cancellation wherever the DOS API makes that possible.

The utility should also check free space before beginning a batch. It can estimate the total size of selected files, compare that value with available destination space, and still handle the possibility that another process changes the directory later. When a disk becomes full halfway through a copy, leave the temporary file and report its name rather than pretending the operation completed.

A progress display need not be elaborate. Show the current source path, destination path, bytes copied, and percentage when the source length is known. For a floppy drive, a rotating character or periodic “reading” message can reassure the operator that the machine has not frozen. Keep output compatible with ordinary Human68k command windows and avoid assuming a colour display.

Testing should begin with small files and disposable disks. Exercise zero-byte files, files larger than the available memory buffer, nested directories, read-only destinations, duplicate names, Japanese filenames, and a destination with less space than required. Then test the awkward cases: remove the floppy during a read, press reset during a write, use a disk with a damaged directory, and copy between two floppy drives if the hardware supports it.

Power deserves attention on restored machines. Australian mains supply is 230–240 V, while many Japanese X68000 units were designed around 100 V input. A suitable step-down transformer or a correctly converted power supply is essential before a long copy session. Replacing tired capacitors and checking the PSU rails is sensible too; an unstable supply can look like a software or floppy fault.

Expansion hardware can change the workflow. A network or storage board may make hard-disk transfers faster, but it should not be required for the basic utility. When documenting a build that uses the Nereid-X project, record the driver version, memory configuration, and device names so another enthusiast can reproduce the environment rather than guess which volume is being used.

Make The Utility Useful For Preservation

A good program should support repeatable archival work. Let the user specify a destination directory, preserve the source directory structure, and write a plain text log containing filenames, sizes, timestamps, and return codes. Logs can be kept beside disk images or uploaded with a software archive, making it easier to identify which files came from which physical disk.

For preservation, never modify the source by default. Open floppy files read-only, reject source and destination paths that resolve to the same file, and warn when the destination already exists. A /Y switch can suppress overwrite prompts for scripted jobs, but interactive use should ask before replacing a file. This protects the original disk while still allowing fast batch transfers.

The utility can also include a manifest mode. Before copying, /L might list matching files and their sizes without changing anything. A later command can use that list as a record of the transfer. If the machine has enough memory and the compiler supports it, a checksum such as CRC-32 can be calculated for each file; otherwise, a smaller CRC-16 or simple rolling checksum still provides a useful identity marker.

Historical references can help resolve unusual formats and software behaviour. The SMB Research archive is a useful place to consult when investigating Sharp computer documentation, technical details, or related preservation material. A utility’s manual should cite the sources used for filesystem assumptions and explain where its behaviour intentionally differs from a sector copier.

Australian users often work in a mixed environment: an original machine in a spare room, a modern PC for writing disks, and perhaps a Raspberry Pi or networked storage box nearby. A Human68k-native copier fills the gap between those systems. It lets the X68000 read its own media and makes the transfer process observable, rather than hiding every step behind a modern disk-imaging application.

Compare Practical Transfer Modes

The final program should be small enough to fit comfortably on a boot floppy and simple enough to run without a resident network stack. A command-line executable with conservative defaults is easier to trust than a large menu-driven package. Include a compact help screen, a version number, compiler information, and an exit status suitable for batch files.

Transfer method	Best use	Strengths	Limitations
Human68k file copier	Selected files and folders	Native paths, metadata handling, clear errors	Does not preserve raw sectors or copy protection
Sector imaging tool	Complete floppy preservation	Captures filesystem and non-file areas	Requires more storage and careful hardware support
Modern PC disk writer	Moving images between systems	Convenient image management	Needs compatible drive hardware and an image format
Network transfer	Frequent large transfers	Fast and avoids repeated floppy access	Requires drivers, expansion hardware, and configuration
Manual DOS commands	Occasional single-file copies	Already available on many systems	Weak batch control, verification, and logging

A practical release might consist of the executable, a short Japanese-and-English command reference, sample batch files, and a source archive. Include examples for copying a single program, mirroring a directory, verifying a transfer, and recovering after a failed write. Australian owners using a step-down transformer, an external floppy drive, or a Nereid-equipped system should be able to adapt those examples without changing the program itself.

The strongest design is deliberately modest: native DOS calls, binary-safe transfers, sensible buffering, preserved metadata, verification, and honest limits. It should help an enthusiast spend less time swapping disks and more time running software, repairing hardware, and documenting the platform.

Build the first version around file handles and a reliable copy loop, test it on expendable media, then publish the source, binaries, and test results with your X68000 notes. That small contribution can make future repairs, software transfers, and preservation work considerably easier for the wider community.