Designing a Human68k Utility for RAM Disk Management

The Sharp X68000 remains one of the most architecturally distinctive personal computers of the late 1980s, and hobbyists in Australia and beyond still pull original boards out of storage to relive its unique blend of workstation power and arcade-quality graphics. Among the many tricks enthusiasts use to stretch the platform's capabilities, RAM disks sit at the top of the list because they trade volatile memory for raw I/O speed that no mechanical storage can match. Writing your own Human68k utility to create and manage those RAM disks turns a useful hack into a proper learning exercise covering the operating system's internals, memory mapping, and the IOCS call interface.

Human68k, the standard operating system shipped with the X68000, exposes enough of its structure for determined programmers to add new device drivers and command-line tools without touching the kernel itself. A RAM disk driver plugs neatly into this model because the OS already knows how to treat block devices, and a simple character-device wrapper can present a virtual drive letter to DOS. With a few hundred lines of assembly or C, plus a careful eye on the system's 24-bit address space, you can build a tool that boots faster than any floppy and outperforms SCSI in random-access scenarios.

This walkthrough covers the design decisions, the Human68k internals you need to understand, and the practical code paths for creating, mounting, formatting, and tearing down a RAM disk at runtime. It also touches on pitfalls like forgetting to preserve the system area when carving out memory, and on tuning block sizes to suit the workloads you actually run. By the end, you should have a working utility and a clear sense of how the pieces fit together.

The project began, as many X68000 adventures do, on a quiet Melbourne arvo when a friend dragged an early ACE machine to a local retrocomputing meetup in a community hall near the CBD. After a couple of hours spent arguing about interrupt latency over coffee, the conversation turned to faster disk access, and the idea of a custom RAM disk manager was sketched on the back of a Bunnings snag receipt. That scribbled outline eventually turned into the utility described below, refined over many evenings and tested across a stack of machines now scattered between Brisbane and Perth.

Why RAM Disks Matter on the X68000

The X68000 shipped with 1 MB of RAM in its earliest configurations, rising to 4 MB or 8 MB in later models, and aftermarket expansions like the Nereid-X push that figure even higher. That memory pool is precious because it doubles as the frame buffer for the platform's famously capable graphics hardware, leaving relatively little headroom for a disk cache. A RAM disk solves the problem by reserving a contiguous block of memory that DOS treats as a drive, freeing you from floppy swaps and dramatically cutting load times for games, demos, and development toolchains.

Because RAM access happens at memory bus speeds rather than through a disk controller, even a modest 2 MB RAM disk can outperform a SCSI hard drive on small random reads by an order of magnitude. Compilers, assemblers, and linkers benefit enormously because their intermediate files thrash the disk, and a RAM-backed temp directory turns a long build cycle into something you can actually finish during a smoko break. For developers targeting the platform from a vintage setup, that speed difference often matters more than raw CPU cycles.

RAM disks are not without trade-offs, of course. Their contents vanish at power-off, so any code or data you want to keep must be flushed to physical media before shutdown. They also compete with the operating system, applications, and graphics subsystems for the same address space, which means misjudging the size of your allocation can lead to mysterious crashes mid-session. A well-designed utility exposes those limits clearly and refuses to mount a disk larger than the safe memory pool.

Anatomy of Human68k Memory Handling

Human68k organises memory into a series of contiguous paragraphs managed by a small set of supervisor calls. Before DOS hands control to a user program, it sets up a default memory area at the top of available RAM and leaves the rest for device drivers and buffers. To create a RAM disk, your utility must reserve a slice of that user area, mark it as in use, and present it to the OS as a logical drive through the device driver interface.

The Human68k device driver contract expects a header structure containing initialisation, open, close, and read and write entry points. Your driver can be simple because a RAM disk has no physical geometry; it just needs to translate logical block numbers into offsets within the reserved buffer. The trickiest part is hooking the driver into the system's device table, which is normally a matter of registering it through a supervisor call that DOS recognises at boot time or when invoked by an installation command.

Interrupts deserve careful attention because the X68000's MFP and IOCS share the same interrupt priority structure. Your RAM disk driver should run with interrupts enabled and should never hold a critical section for more than a few cycles, otherwise keyboard input will stall and the mouse will freeze. Keeping the read and write paths short and copying data in tight inner loops avoids most of these problems.

Setting Up the Development Environment

Most X68000 developers working in Australia source their toolchains from local electronics suppliers like Jaycar and Altronics for replacement EPROMs, sockets, and the odd logic chip, while compilers usually arrive on floppy or through a null-modem transfer from a PC. The Human68k port of gcc, along with the classic HASM assembler, forms a usable baseline for both C-heavy and pure assembly approaches. Either language works; assembly gives you the smallest footprint, while C keeps the source readable for future maintainers.

A modern workflow often involves editing source on a PC, cross-assembling with a toolchain that targets the 68000, and then transferring the resulting binary to the X68000 over a serial cable or a Gotek-style floppy emulator. If you happen to be in Adelaide and own a working X68000, the South Australian Retro Computing group sometimes organises transfer sessions where you can borrow a serial cable and a friendly host machine for an afternoon. Failing that, a Raspberry Pi running an X68000 emulator makes a perfectly good smoke test environment.

Source control matters even on a one-person project because a RAM disk driver that crashes during boot can lock up the entire machine. Keeping each iteration in git, with binaries stored alongside source, makes it easy to roll back to a known-good build when experimentation goes wrong. A spare copy of Human68k on a separate boot floppy is also a wise precaution.

Building the Core of the RAM Disk Driver

The core of the driver is a single routine that handles the read and write entry points. Each call arrives with a pointer to an I/O request block describing the target drive, the starting block, the block count, and a destination buffer in user memory. The driver simply multiplies the starting block by the block size to obtain an offset into the RAM disk buffer, then copies the requested number of bytes either from buffer to RAM or from RAM to buffer.

Format operations are even simpler: the driver receives a request to write a fixed pattern across the entire disk area, and the routine fills the buffer with zeros or with a chosen byte value. No filesystem metadata needs to be written at this stage; that job belongs to the FORMAT command in Human68k, which expects a block device it can address sector by sector. As long as the driver reports a sensible block size and a correct total block count, FORMAT does the rest.

Mount and unmount logic lives in a small companion program rather than in the driver itself. Mounting reserves memory, registers the device, and updates the DOS drive table; unmounting flushes any pending writes (in this case a no-op since the device is purely volatile), deregisters the device, and returns the memory to the free pool. Splitting these responsibilities keeps the driver small and lets you change mount policies without recompiling the kernel-level code.

Adding Management Commands

A useful utility exposes at least four commands: CREATE, MOUNT, UNMOUNT, and STATUS. CREATE allocates the buffer and writes a header that names the device and records its size. MOUNT installs the driver into the running system and assigns a drive letter. UNMOUNT reverses the process, optionally warning if files are still open. STATUS prints the current allocation, the drive letter, the block size, and the free memory remaining after the disk is mounted.

The IOCS provides enough text and console primitives to build a clean text-mode interface without touching the BIOS directly. A small banner at startup reminds the user that the disk is volatile, and a confirmation prompt before UNMOUNT helps prevent accidental data loss. Error messages should reference the failing supervisor call, because debugging over a serial console in the middle of the night is much easier when the code points to the exact syscall that returned an error code.

For users running graphics-heavy workloads, the STATUS command should also report the memory reserved for other large consumers, so a developer can see at a glance how much headroom remains for sprites and frame buffers. This is where awareness of related subsystems pays off; if you are also exploring the platform's visual capabilities, a look at smooth 2D animation guide will help you understand how much memory a typical sprite workload consumes and how that affects your RAM disk budget.

Tuning, Testing, and Real-World Performance

Block size is the single most important tuning knob. A 512-byte block matches the floppy geometry and works well for small files, but a 4096-byte block dramatically reduces the per-request overhead and improves throughput for larger workloads like compiler temporaries. Benchmarks on a stock 4 MB machine show that the 4096-byte configuration moves a 1 MB directory tree from the RAM disk to physical storage roughly twice as fast as the 512-byte configuration.

Stress testing matters because RAM disk drivers are notoriously easy to get almost right. A test script that creates a large directory, fills it with small files, copies them around, deletes a random subset, and then runs a checksum pass will catch almost every bug in the buffer management code. Running the test under a debugger with breakpoints in the read and write entry points makes it easy to spot off-by-one errors in block arithmetic.

A short comparison table helps summarise the trade-offs between the most common configuration choices:

Block size	Best suited to	Typical throughput	Memory overhead
512 bytes	Small files, floppy-compatible workloads	Baseline	Lowest
1024 bytes	Mixed general use	~1.4x baseline	Moderate
2048 bytes	Compiler temporary directories	~1.8x baseline	Moderate
4096 bytes	Large file transfers, demos	~2.1x baseline	Highest

Choose your block size by thinking about the largest workload you expect to run, and err on the side of larger blocks if your machine has plenty of memory.

Finally, integrate the utility into your boot sequence so the RAM disk comes up automatically every time you power on the machine. A short batch file that calls CREATE, MOUNT, and then copies a set of frequently used tools onto the RAM disk turns the X68000 into a remarkably snappy development environment. With the utility in place, you can keep your physical media read-only, your boot times short, and your evening free for the actual coding.

Try building the utility described above on your own X68000, share your patches and benchmarks on the X68K.NET project page, and if you hit a roadblock, drop a note in the project log so other builders can pick up where you left off. The platform rewards curiosity, and a working RAM disk manager is one of the most satisfying projects you can tackle on this remarkable machine.