Creating A Human68k Utility For Multiple Boot Configurations

A Sharp X68000 can serve very different purposes depending on the software loaded at startup. A game-oriented environment may need maximum free memory and a carefully selected sound or disk driver, while a development setup may require a compiler, editor, debugger and resident utilities. Rebooting and manually replacing CONFIG.SYS and AUTOEXEC.BAT works for a while, but it becomes slow, error-prone and difficult to document.

A small Human68k utility can turn that process into a predictable boot manager. The program can display named profiles, select the required configuration, validate the choice, and then restart the machine using the appropriate files. The design is especially useful for Australian owners who may be preserving imported Japanese hardware, working with ageing SCSI devices, or sharing one X68000 between games, programming and restoration tasks.

Approach	Strengths	Weaknesses	Suitable use
Manual file swapping	Simple and requires no program	Easy to overwrite files or mistype commands	Occasional experiments
Separate boot disks	Physically clear and easy to recover	Requires several disks and a working floppy drive	Small profile collections
Batch-file selector	Fast to create and easy to modify	Limited validation and awkward menus	Basic home setups
Human68k boot manager	Named profiles, checks and consistent behaviour	Requires programming and testing	Regular multi-purpose systems
Dedicated hardware or drive partitions	Strong separation between environments	Costly, harder to maintain and document	Large collections or laboratories

Define what a boot profile contains

Begin by deciding which settings actually belong to a profile. A useful record might include a profile name, a source CONFIG.SYS, a source AUTOEXEC.BAT, optional driver files, a default directory, and a short description. Avoid treating every file on the disk as part of the boot profile. Personal data, save files and source code should remain separate so that changing modes cannot damage them.

For example, a “Games” profile could load only essential memory and device drivers. A “Development” profile could add a compiler path, text editor and debugging tools. A “Music” profile might start a sequencer, MIDI utility or specialised resident driver. On a machine with limited RAM, the profile should state exactly why each driver is loaded rather than silently accumulating old utilities.

Store the profile definitions in a plain directory such as \BOOTCFG. Each profile can have a subdirectory containing its two startup files and a small metadata file:

\BOOTCFG\GAMES\CONFIG.SYS
\BOOTCFG\GAMES\AUTOEXEC.BAT
\BOOTCFG\GAMES\PROFILE.TXT

Plain text is valuable for preservation. It can be inspected from another computer, copied to a modern storage device and understood decades later without a proprietary editor.

Choose a safe file-switching method

The least risky design keeps the active startup files in the root directory and treats profile files as read-only templates. When the user selects a profile, the utility copies the selected CONFIG.SYS and AUTOEXEC.BAT into temporary files first. It then checks that both copies exist and have the expected size before replacing the active versions.

A safer sequence is to preserve the current files as CONFIG.OLD and AUTOEXEC.OLD, write the new files, and create a marker such as BOOTCFG.OK. If power is lost during the operation, the next launch can detect the missing marker and offer a recovery profile. This matters on old X68000 systems with repaired power supplies, loose connectors or storage devices that take time to spin up.

Human68k command behaviour can vary between versions and installed utilities, so avoid relying on undocumented shell extensions. A compact C program can use DOS file functions for copying, opening and renaming files, while a small assembly routine may be useful where precise low-level control is needed. Keep the file operation logic independent from the menu so it can be tested without rebooting.

Do not overwrite the only known-good configuration. A recovery profile should load the minimum drivers needed to access the boot disk and display a message explaining how to restore another profile. If a particular SCSI driver or RAM-disk utility causes a crash, the user should still be able to start the selector and choose a simpler environment.

Build a Human68k menu that stays practical

The interface should fit an ordinary Japanese X68000 display and remain usable with a keyboard. A numbered list is sufficient:

Human68k Boot Profiles

1. Games
2. Development
3. MIDI
4. Recovery

Select a profile:

Display the profile description before committing to a change. For example, show the expected memory requirements, required device and intended software. A user choosing “Development” on a machine without the relevant compiler disk should receive a warning rather than discover the problem after rebooting.

The selector should accept only one digit or a clearly delimited command. Reject blank input, letters outside the menu and numbers beyond the available profile count. If the program is launched from AUTOEXEC.BAT, it should return a useful error level when the user cancels or when a profile is incomplete. That lets the batch file fall back to a shell instead of blindly restarting.

A reboot command should be the final step, not the first. Give the operator a short confirmation window, then write a log containing the selected profile and date if a real-time clock is available. A log is helpful when diagnosing intermittent failures, particularly when testing an expanded machine in Melbourne or Sydney where replacement parts and workshop time may be expensive.

Keep drivers and paths profile-specific

Many boot conflicts come from environment assumptions rather than the selector itself. One profile may set a PATH containing a compiler directory, while another may load a resident utility that occupies memory required by a game. Keep environment variables in each profile’s AUTOEXEC.BAT, and avoid leaving global settings in a shared file unless every mode needs them.

Use explicit paths for important commands. A profile that launches GAME.X should identify its directory rather than depending on the current drive and directory. This makes the configuration more portable between internal SCSI disks, CompactFlash adapters and modern replacement storage. It also reduces confusion when an X68000 has several logical partitions.

Memory reporting should be part of the diagnostic screen. The utility does not need to understand every driver; it can simply record the expected configuration and let the booted environment display its actual free memory. If a profile needs a RAM disk, specify its size and purpose. A large cache may speed up development but leave too little memory for a game or compiler.

Australian users often work with imported Japanese systems connected to local 240-volt power through correctly rated equipment. The boot utility should never assume that a hardware expansion is present just because a profile was copied from another machine. Record optional hardware in the profile description, and include a conservative configuration for systems with stock memory, repaired power supplies or ageing expansion boards.

Make failure recovery part of the program

A boot manager earns trust through its recovery behaviour. Include a timeout that selects the recovery profile if no key is pressed, and allow a known key such as R to bypass the last selected profile. The recovery environment should use the smallest practical driver set and avoid launching resident applications automatically.

Keep at least one untouched backup on a separate medium. A floppy disk, write-protected storage card or verified disk image can restore the startup files when the main drive becomes unreadable. For Australian collectors, this is more than a convenience: replacement floppy media and specialist repair services may involve postage from another state, while local computer shops are unlikely to stock X68000-compatible parts.

Checksums can detect accidental changes to profile files. A simple 16-bit checksum is adequate for identifying an unexpected edit, although it is not a security feature. The utility can compare stored values when the menu starts and mark a profile as modified. Store the checksum in a plain text index so it can be regenerated with a separate maintenance command.

Never present a checksum as proof that a file is safe. It only shows whether the bytes match the recorded version. If software is exchanged through forums, chat groups or file-sharing pages, keep a local archive of the source, version and checksum. Community resources such as X68K.NET are useful places to document hardware assumptions and preservation notes alongside the program.

Test across real storage and display setups

Testing should begin in an emulator or with disk images, then move to the actual machine. Confirm that the selector runs from the intended Human68k version, that filenames use the expected character handling, and that the program behaves correctly when a profile directory is missing. Test a full disk, a read-only file, a failed copy and a cancelled selection.

Physical testing should cover the storage combinations commonly found in the enthusiast community: original floppy drives, SCSI hard disks, CompactFlash adapters and newer solid-state replacements. A profile that works on an emulator can fail on real hardware because a device takes longer to initialise or reports a different capacity. Record each result instead of relying on memory.

Display timing also deserves attention. Japanese X68000 software may be used with displays or converters that handle 15 kHz and 31 kHz signals differently. The boot utility should use conservative text output and avoid decorative graphics until the basic workflow is reliable. This is particularly practical in Australia, where replacement monitors and video converters are often sourced through specialist importers rather than ordinary electronics retailers.

Document the exact machine, ROM or Human68k version, storage device and adapter used in each test. If a profile depends on a Nereid-X board, extra RAM, MIDI hardware or a particular SCSI driver, state that clearly. A short hardware matrix prevents another owner in Brisbane, Adelaide or Perth from assuming that a copied configuration will behave identically.

Package the utility for long-term use

Release the program with source code, a compiled binary, sample profiles and a recovery disk image. Include a plain text manual explaining installation, directory layout, command-line options and the meaning of each error message. Human68k preservation benefits from files that remain useful even when modern packaging tools disappear.

Keep version numbers visible in both the executable and the documentation. A profile format such as v1 or v2 helps the utility reject incompatible metadata rather than interpreting it incorrectly. If the program later supports environment variables, checksum records or automatic hardware detection, document the change and provide a migration example.

Distribution should respect copyright and local legal obligations. Do not bundle commercial games, proprietary drivers or ROM images without permission. Australian users may also encounter consumer and import issues when buying hardware or media from overseas: GST treatment, delivery insurance and Australian Consumer Law remedies can differ depending on whether the seller is local or international. Keep the utility itself separate from questionable software bundles, and preserve clear licensing information.

A community release can include optional links to related software resources, but verify files before putting them on archival media. A site offering mod downloads is not automatically an authoritative source for X68000 software, so treat unrelated downloads cautiously and rely on documented checksums and known community archives. The boot manager should make provenance easier to track, not encourage indiscriminate copying.

Turn daily switching into preservation

A well-designed selector changes the X68000 from a machine with fragile startup files into a set of clearly labelled working environments. Each profile says what it loads, why it exists and how to recover from failure. That clarity helps when the computer is used after months in storage, demonstrated at a retrocomputing event or handed to another enthusiast.

Start with three profiles: Recovery, Games and Development. Implement file validation, backups and a keyboard menu before adding automatic hardware detection or graphical presentation. Test every profile on real hardware, keep a verified recovery disk, and publish the source with examples so future users can adapt the program rather than rebuild it from memory.

Create the directory structure, write the smallest working selector and test it against a copy of your current startup files. Then add one profile at a time, record the hardware assumptions, and share the finished utility with the X68000 preservation community so reliable multi-boot workflows remain available for the next generation of Human68k users.