Emulator Development

How this emulator was built

The current project is a pragmatic browser game runner: load a user-supplied Jupiter Ace ROM, load a TAP or basic TZX, let the ROM perform the dictionary work, then apply compatibility profiles where specific games need help.

The aim is not yet a perfect cycle-accurate recreation of every Jupiter Ace feature. The aim is to make preserved Ace games easier to try, document what works, and keep the code honest about what remains experimental.

ACEDEVLOG

LOAD ROM ...... USER SUPPLIED

LOAD TAP ...... ROM ASSISTED

LOAD TZX ...... EXPERIMENTAL

KEYS .......... PROFILED

STATE ......... WIP, PLAYABLE _

A work-in-progress emulator made useful through ROM-assisted loading, state isolation and per-game profiles.

Advertisement

Design direction

From full emulator ambitions to a focused game runner

The project began with a broader emulation workbench, including diagnostic probes and manual experiments. The more useful route turned out to be narrower: a simple user flow of loading the ROM, loading a game file, and letting the emulator attempt the safest known launch route automatically.

That decision kept the important machine pieces—Z80 execution, ROM/RAM mapping, screen rendering, keyboard matrix input and beeper output—while moving cassette timing, launch quirks and keyboard convenience into a compatibility layer.

Major implementation choices

What made the current build practical

ROM policy

The site does not include or host the ROM. The user loads an authorised 8K ROM, and the emulator can store that ROM locally in browser storage for later sessions.

ROM-assisted loading

DICT blocks are passed through the Jupiter Ace ROM’s own LOAD routine instead of being blindly copied into memory. This preserves more of the Forth housekeeping the programs expect.

Cold-load isolation

Every new TAP/TZX load is treated like a fresh virtual Ace power-on with the same ROM inserted. This avoids one failed or partial load contaminating the next attempt.

Expansion before boot

Build 60 provisions RAM before the ROM warm-up, so expanded-memory DICT games are not loaded into a ROM session that still thinks it is a stock 3K machine.

Controls and keyboard modes

Arcade profiles can map cursor keys and modern controls to the original Ace keys, while full keyboard mode remains available for text adventures, utilities and menus.

Speed and sound

Fast mode is used for loading, then gameplay is throttled toward the Ace’s normal speed. The beeper support is deliberately first-pass but works for simple speaker-port activity.

Compatibility lessons

Why some games need profiles

Greedy Gobblerscontrols

Works well with remapped controls. It also shows the kind of graphical economy common on tiny machines: the apparent static ghost appears to be a cage or scenery element using the same sprite idea.

Blowing Up the Worldrules

The game needs full number-key access rather than cursor movement: the plane moves automatically, wraps around the screen, and 1–8 select bomb depth.

Ace Invaders and Cavern Attackload sequence

These titles need more than simply loading a final word. The graphics block must be loaded, a setup word such as GR run, temporary code forgotten, and then the main run block loaded.

Centipedelaunch word

The preserved instructions use LOAD centipede go, so Build 61 added a profile that loads the dictionary then launches go; Build 62 maps its unusual I/J/L/M/A controls to cursor keys and Space.

Rocks ’n’ GhostsCPU edge case

Build 63 added the undocumented IXH/IXL/IYH/IYL Z80 register forms needed by this homebrew title, and Build 65 maps its QAOP movement to cursor keys.

TZX filesexperimental

The current parser extracts simple standard-speed TZX blocks and handles the leading tape flag byte found in some files. More elaborate TZX timing and custom loader features remain future work.

Public launch status

Ready as a work in progress

The emulator is now suitable to publish as a clearly labelled WIP: several games run, saved-ROM storage makes repeat use straightforward, and the compatibility table can set expectations honestly. The next useful work is not a dramatic rewrite, but more testing, more profiles, and clearer documentation for each confirmed title.