Building a live Human68k memory map utility

Creating a Human68k utility that displays a system memory map in real time starts with separating the physical address map from the operating system’s allocator. The Sharp X68000’s 68000-family processor exposes a 24-bit address space, yet RAM, video RAM, ROM, I/O and optional expansion hardware occupy different, partly board-specific regions. The heap visible to programs is a different layer again.

A useful screen should therefore pair a stable address census with changing allocation data. It can expose which ranges exist, which are reserved, how much memory the allocator can still satisfy and when a requested block exceeds the largest free block. That combination turns a diagnostic curiosity into a practical tool for debugging software, testing expansions and preserving scarce machines.

What the view represents	Example content	Refresh trigger	Main caveat
Physical address census	RAM, ROM, I/O and expansion windows	Hardware or profile change	Board revisions differ
Allocator overview	Total free, largest block and requested size	Timer or allocation event	Not a physical map
Block detail	Base, end, owner and state	Coherent snapshot	Requires safe instrumentation
Fault overlay	Unstable range or failed request	Error event	Must preserve context

Start with the machine’s address-space model

The X68000 uses a 16.8 MHz Motorola 68000 with a 16-bit data bus and a 24-bit address bus. Human68k normally presents a 16-bit process environment, so values must be widened and treated as unsigned when addresses cross a 64 KiB boundary. Store ranges as 32-bit base and end values even if the first release displays only six hexadecimal digits.

Begin by recording the machine revision, ROM set, video configuration and installed expansion cards. Standard RAM, palette or graphics areas, I/O windows and optional memory are easy to conflate. Do not paste a generic internet chart into the program: verify each claimed window against the manual for that revision, boot behaviour and the board’s own diagnostics. Mark uncertain ranges instead of presenting guesses as fact.

The first release can call this layer the physical census. It changes only when the hardware configuration changes, so it should be cached and redrawn on demand. Keep board data in a separate profile, allowing the same executable to serve an unmodified X68000, a memory-expanded machine and a board fitted with the Nereid-X without rebuilding a hard-coded table.

Choose a native-friendly Human68k toolchain

Compile for the real machine whenever possible. A Human68k C compiler keeps the source close to the host APIs and makes timing faults easier to reproduce; a cross compiler is convenient for rapid development, but its runtime, startup code and file conventions must match Human68k. A small command-line build, packaged as a normal executable and optionally a disk image, is easier to share than an installer.

Use the documented Human68k memory-control interface for total free memory and allocation limits. Block ownership usually needs a tiny instrumentation layer around allocation, release and resize calls, because the native system does not promise a stable public owner table. Where a primary manual is difficult to locate, the community reference archive offers another route into period documentation.

Keep the sampler independent of the renderer. Collect into fixed static buffers, then copy a finished snapshot to the screen. Avoid allocating memory while measuring it, terminate collection cleanly when a requested block fails, and keep an ASCII export path for boards whose display output is awkward. The utility should remain useful even if its fancier graphics mode cannot start.

Sample state without disturbing the system

Model two clocks: allocator state and screen redraw. The physical census can be refreshed only after a configuration event, while allocator totals may be sampled every 250 milliseconds. Displaying at that rate feels immediate without turning a diagnostic into a benchmark. Schedule redraw work during vertical retrace and retain the previous frame until the next one is complete.

Take a coherent snapshot at a safe task boundary. If the allocator is cooperative, query it outside interrupt handlers; if the operating environment permits preemption, copy only the small set of counters it exposes. A timer interrupt should never call complex runtime services. For direct reads of diagnostic registers, briefly mask interrupts, copy the minimum data, restore them, and do the formatting later.

Hardware activity can invalidate a naïve scan. Video memory may change during a frame, and some expansion windows can be sensitive to access timing. Reading every byte at full speed can itself disturb the board or trigger a fault. Poll a known status register or use a short diagnostic interval, and treat an unstable sample as unknown rather than repeatedly hammering the range.

Give every region a record containing base, limit, kind, source, status and confidence. Include a generation counter so stale records cannot be mistaken for fresh data. Preserve errors with timestamps and the operation that caused them. This structure supports more than a pretty display: the same snapshot can drive a log, a board profile comparison or a warning when a mapping changes unexpectedly.

Design the display for rapid interpretation

Use X68000 text mode as the dependable default. Show physical ranges in one pane and allocator activity in another, with six-digit hexadecimal addresses, decimal sizes, readable labels and explicit units. A compact status line can show refresh rate, last sample time and whether the view is live, frozen or exporting. Text remains legible on period monitors and through composite output.

Colour should encode state rather than decoration: green for normal, amber for reserved or uncertain, red for a fault and blue for expansion memory. Avoid changing the palette globally, because the program may run beside other software. A direct graphics mode can add bars or an address ruler, but it needs a palette backup and a clean return to text after errors.

Offer simple keyboard commands to freeze the display, take one sample, toggle allocator detail, toggle hexadecimal and decimal sizes, and save the current snapshot. For Australian users, default timestamps to day, month and year and identify AEST or AEDT where daylight saving applies. Keep key labels on screen; an obscure command system makes a useful diagnostic frustrating at a swap meet.

Validate the map against real hardware

Test against observations, not assumptions. Boot known software, run a controlled allocation loop and compare the utility’s figures with Human68k’s own reports. The practical probing method is described in logic analyzer field notes. It is particularly useful for expansion-port activity, where access timing and decoded address lines can reveal a mapping that software cannot safely probe.

Repeat the tests with each relevant configuration: standard RAM, added memory, different video modes and any Nereid-X or other expansion fitted. Record the exact board revision and jumper settings. A range that works on one machine may be reserved on another, so the project should publish profiles rather than a single universal chart. Unknown regions must remain visibly unknown.

Power is a major Australian preservation issue. The X68000’s original Japanese supply is commonly specified for 100 V, while Australian mains is 230 V at 50 Hz. A plug adaptor changes the pin arrangement, not the voltage. Use a correctly rated isolating step-down transformer, check the supply’s voltage, fuse and current rating, and have the machine’s power supply serviced before repeated use.

Climate also changes the test plan. Humidity in coastal Sydney and Brisbane encourages leakage and corrosion, while Melbourne’s summers can heat a densely packed console. Work on a non-carpeted surface, protect stored boards from dust, and inspect older capacitors and connectors before powering up. For interstate moves, pack the machine separately from accessories and insure the shipment.

Release the utility as a preservation tool

Publish the utility on X68K.NET as source, a build guide and a collection of board profiles. Include a checksum for each release, the Human68k compiler version used, and a short method for reproducing a captured map. Screenshots should show the exact revision under test. A plain-text snapshot is valuable when the website’s host is unavailable or a future maintainer needs to compare results without running X68000 software.

Plan for the Australian market rather than treating it as an export afterthought. List expected costs in Australian dollars, distinguish Australian-held stock from Japanese seller stock, and explain that used Japanese imports may arrive through Australia Post or a courier. Low-value GST can apply, so buyers should check current customs thresholds, duty rules and required descriptions rather than assume an old de minimis applies.

Local hobbyists can then test releases at retro-computing gatherings and swap meets in Sydney, Melbourne, Brisbane and other Australian cities, while sellers on eBay Australia or Gumtree can offer locally serviced units. Share a labelled photo of the board and utility output with each machine. Those small observations often reveal regional hardware quirks that no general manual records.

Build the first release with text output, a physical census, allocator totals and one export command. Test it on an unmodified machine, publish the results, then invite verified profiles and failure logs. Carry the next unit to a local meetup, demonstrate the live map beside the running system, and keep every confirmed range in the project’s permanent documentation.