Rotozoomer, drawn by hand in a few lines of JavaScript

The machine that never was

Intuition Engine

Six rival home computers on one bus.

Six CPUs share one memory bus: IE64, IE32, 68020, Z80, 6502 and x86. Pair any of them with video and sound hardware from the worlds of Commodore, Atari, Sinclair, BBC, Amstrad and IBM, plus Mode 7 affine texturing, a copper, a blitter and a 3dfx Voodoo.

Intuition Engine is a demoscene platform for combinations no original computer could run: a 6502 playing SID music while an x86 drives Atari ANTIC graphics, or a 68020 using a copper with PC VGA. It is free and open source, built for people who still write rotozoomers by hand and people writing their first. I have been building it since 1991.

Launch IE64 BASIC in your browser Download the Intuition Engine 1.0.8 live image YouTube Source

Requires an x86-64-v3 processor: Intel Haswell (2013) or newer, or a compatible AMD processor.

IE64 BASIC showing the source listing for the wobble zoom demo
IE64 BASIC running directly on the machine. Load, inspect and change the supplied examples from the Ready prompt.

Your first minute, and the first thing on screen is yours, not a demo off the disk. Launch the browser demo and type this at the Ready prompt:

10 SCREEN &H13
20 PALETTE 1, 63, 0, 0
30 PLOT 160, 100, 1
40 POKE32 &HF0800, 1 : REM switch the sound chip on
50 SOUND 0, 440, 200, 0, 128
60 GATE 0, ON : REM play the note
RUN

A red dot appears in the middle of the screen and a tone plays. Your programme has written directly to the video and sound hardware. From here, RUN AOT compiles the same BASIC to native IE64 code, while DIR "Demos" lists the supplied rotozoomers. Two ways in: make your first effect, or see the hardware.

Six architectures, one bus IE64, 68020, Z80, 6502, x86 and IE32 can run at the same time, each in its own thread, reaching the same RAM and MMIO devices.
Chips that never met A demo can run its CPU on one maker's silicon, its video on a second and its music on a third.
CPU workers BASIC, assembly, and C start worker CPUs through the coprocessor service and pass requests through mailbox rings.
IE Mon / IEScript IE Mon and IEScript inspect CPU state, MMIO views, snapshots, and frame output through the running machine. 
caller CPU
  -> MMIO register, monitor action, script call, or BASIC command
  -> MachineBus
  -> device, worker, or runtime service
  -> response through RAM, ticket, IRQ, or status

Impossible machine demos

Each demo is a CPU, a video chip and a sound chip that never shared a board. An Intel x86 driving Atari ANTIC graphics with Commodore SID music. A 6502 painting a ZX Spectrum screen while an Amiga tracker plays. Several run the music on a second CPU entirely, and the copper reprograms display hardware that never had a copper. Grouped by what they prove, not by the CPU behind them.

One effect, every way in

Fourteen implementations of one effect

Fourteen versions produce the same picture through different CPUs, languages and guest operating systems. Six CPUs perform the same calculations and write the same VideoChip registers. IE64 BASIC and IEScript reach those registers through their own interfaces, while EmuTOS and AROS use guest drivers and applications. The fourteenth version halts IE64 after setup, then Copper and the blitter calculate and render every later frame. The IE64 version plays a stereo SAP tune through two Atari POKEY chips.

IE64 · rotozoomer_ie64.asm IE32 · rotozoomer.asm M68K · rotozoomer_68k.asm Z80 · rotozoomer_z80.asm 6502 · rotozoomer_65.asm x86 · rotozoomer_x86.asm BASIC · rotozoomer_basic.bas IEScript · rotozoomer_ies.ies EmuTOS GEM · rotozoomer_gem.asm AROS asm · rotozoomer_aros_api.asm AROS asm · rotozoomer_aros_hw.asm AROS C · rotozoomer_aros_api.c AROS C · rotozoomer_aros_hw.c No CPU after setup · rotozoomer_nocpu.asm

3D through the Voodoo

Guest CPUs feed a 3dfx-style rasteriser: Gouraud shading, Z-buffering, texture upload, and fog.

voodoo_mega_demo.iex
IE32

IE32 CPU driving a 3dfx-style Voodoo, while a second CPU, a 6502 core, plays the C64 SID soundtrack.

Source

Separate video systems and their signature modes

The machine implements VGA, the TED 121-colour model, the ZX Spectrum ULA and ANTIC/GTIA as separate video systems. Each runs in one of its characteristic modes under a CPU that was never originally paired with it.

vga_text_sap_demo.ie80
Z80

A Z80 fills all 2,000 VGA Mode 03h cells with a four-wave plasma, palette fades, an integrated logo and a persistent scroller while Atari POKEY plays an embedded SAP tune.

Source

ted_121_colors_68k.ie68
M68K

Motorola 68020 CPU on the Commodore TED's 121-colour mode, with a Spectrum AY chip in Plus mode.

Source

ula_boing_ie64.ie64
IE64

A 64-bit IE64 RISC CPU uses its FPU to render a red-and-white chequered Boing ball through ZX Spectrum ULA video, with synthesised SFX, reverb and real-time MIDI music.

Source

antic_plasma_x86.ie86
x86

Intel x86 CPU driving Atari ANTIC/GTIA graphics, with Commodore SID music. A plasma from three rival makers at once.

Source

rotating_cube_copper_68k.ie68
M68K

Motorola 68020 CPU on PC VGA, while a second CPU, a 6502 core, plays the C64 SID soundtrack. The native IE Video Copper rewrites the VGA palette registers in step with the beam as it sweeps the screen, for raster bars real VGA silicon never had a copper to make.

Source

Hardware effects from BASIC

Effects without leaving IE64 BASIC. COMPILE turns any of them into a standalone .ie64 image.

wobble_zoom.bas
IE64 BASIC

A texture wobble-zoom over a MIDI soundtrack, written entirely in IE64 BASIC.

Source

resonance.bas
IE64 BASIC

IE64 BASIC locked to a MIDI orchestral track: raster bands, stars and scroll all synchronised to the music.

Source

One old-school intro, four CPUs

The same RoboCop intro, identical down to the IE Video Chip blitter and copper effects and the AY theme in Plus mode, rebuilt for four different instruction sets: IE32, 68020, Z80 and 6502.

robocop_intro.iex
IE32

The RoboCop intro on the IE32 CPU.

Source

robocop_intro_68k.ie68
M68K

The RoboCop intro on the Motorola 68020.

Source

robocop_intro_z80.ie80
Z80

The RoboCop intro on the Zilog Z80.

Source

robocop_intro_65.ie65
6502

The RoboCop intro on the MOS 6502.

Source

Full games on the live image

The live image includes complete, playable ports. Mario Kart 64 divides its work between four processors and a Voodoo. The same Chocolate Doom engine runs on x86 and the 68020, exercising the shared bus through two instruction sets. Part VIII of the Reference Guide covers the full porting process.

Coprocessor case study

Mario Kart 64

4 CPUs + Voodoo

mk64-ie runs four processors at once inside a single mariokart64.ie68: a main 68020 building each display list, a second 68020 translating it into draw calls, a third 68020 running the audio sequencer, and an IE64 worker doing transform and lighting, with the geometry feeding a Voodoo. The two additional 68020 CPU cores use the M68K worker type's two available instances. How the four CPUs split the work.

Source

Texture-mapped 3D

Alien Breed 3D 2: The Killing Grounds

M68K (68020)

Team17's texture-mapped 3D shooter (Redux High Overdrive) running as a bare-metal 68020 flat programme, ab3d2_ie68.ie68. Ships in redux low and high builds, a high-overdrive build, and optional SID-audio variants.

Source

id Software Doom

Chocolate Doom (x86)

x86

Chocolate Doom compiled to a freestanding x86 image, iedoom.ie86, drawing straight to the framebuffer and loading doom1.wad from the disk volume.

Source

id Software Doom

Chocolate Doom (M68K)

M68K (68020)

The same engine as a bare-metal 68020 flat programme, iedoom.ie68, a true ELF-to-flat build with no hosted OS. Same doom1.wad, same renderer, a different CPU.

Source

YouTube channel.

Write your own demo

Start at the BASIC prompt and use the same machine throughout. RUN interprets your programme, RUN AOT compiles it to native IE64 code, and TRANSPILE writes readable assembly. You can then target any of the six CPUs through the same MachineBus devices. The copper, blitter, Mode 7, Voodoo and music players are available from BASIC. Part VII of the Reference Guide builds a complete intro from its first frame loop.

Start in BASIC

From idea to moving pixels

This is a whole programme: the copper paints sixteen raster bands down the frame, a red gradient brightening band by band, while a SID from the demo disk plays. Type it into the browser demo, RUN it, then RUN AOT to run the same programme compiled to native IE64 code.

10 COPPER LIST
20 FOR Y=0 TO 15
30 COPPER WAIT 200+Y*8
40 COPPER MOVE &HF0048, 200+Y*8
50 COPPER MOVE &HF004C, 8
60 COPPER MOVE &HF0050, 40+Y*13
70 COPPER MOVE &HF0054, 1
80 NEXT Y
90 COPPER END
100 COPPER ON
110 SOUND PLAY "ODDNB.SID",0
Drop to assembly

Readable source, both ways

TRANSPILE writes your BASIC out as IE64 assembly you can read and edit; ASSEMBLE turns source back into a flat .ie64 image. Hand-write with ie64asm or ie32asm, and read an IE64 image back with the ie64dis disassembler.

Pick your CPU

Six instruction sets, one target

Build for any core: .ie64, .ie32, .ie65, .ie68, .ie80 or .ie86. Carry IE32 source across with ie32to64. Run the music on a worker CPU with COSTART and COCALL while another core draws the screen.

Effects

Copper, blitter and Voodoo

A copper that rewrites registers in step with the beam, and can point itself at any chip on the bus, not just the video registers; a blitter with copy, fill, line, masked and alpha copy, colour expand, scale, Mode 7 and raw memory copy; and the Voodoo for textured 3D. Mix a CPU, a video chip and a sound chip that never shared a board. Watch the same rotozoomer written fourteen ways, including one which halts its CPU after setup.

Chip music

Play the real formats

Put real chip music in your own demo with one command. The machine plays the real thing from every camp: Commodore's SID and the Plus/4's TED, Atari's POKEY with its SAP tunes, the ST's SNDH and YM, Amiga MOD and AHX, AY files from the Spectrum and the Amstrad CPC, each on its own hardware protocol, with VTX and the Spectrum's whole tracker family from Pro Tracker to ASC, VGM from Sega, MSX, the BBC Micro and the rest of the SN76489 and AY worlds, and WAV, MIDI and Doom MUS besides. A stereo SAP drives two POKEY chips at once, a MultiSID .sid runs on two or three SIDs together, up to nine voices at once, and five of the classic engines carry a Plus mode: the authentic chip, or an enhanced render, one command apart. Play a SID, AY, POKEY, TED or AHX file and switch that engine's Plus mode on for an enhanced render of the same tune.

SOUND PLAY "DEMO_MOD.MOD"
SOUND PLAY "DEMO_AHX.AHX",1
SOUND PLAY "SHADOWOFTHEBEAST.MID"
SID PLUS ON
SOUND PLAY "DEMO_SID.SID"
SID PLUS OFF
SOUND STOP
Debug it like hardware

Freeze, step, rewind

IE Mon freezes every CPU, single-steps one core while the rest stay frozen, sets conditional breakpoints and watchpoints, and steps back through recorded history, rewinding the whole machine, every CPU, chip and register, then replaying it one instruction at a time to any breakpoint, watchpoint or fault. IEScript drives the same machine from Lua for repeatable tests.

IE Mon and IEScript

Make one, then release it

A finished production can be shared as source and assets. wobble_zoom.bas is one complete example.

A complete demo, start to finish

wobble_zoom.bas

A compact BASIC source file. It wobbles a splash image line by line, rotozooms it through the blitter's Mode 7, and rides it on a MIDI score. Its splash and its tune ship on the browser demo's disk, so you can watch it now with nothing to install: open the demo, load the file, and it plays. A few lines of it, an excerpt to read rather than paste:

110 SOUND PLAY "sdk/examples/assets/music/enjoythesilence.mid"
310 BLOAD "sdk/examples/assets/splash_640x92.rgba",SR
420 FOR Y=0 TO 91
440 X=OX+INT(24*SIN(T+Y*0.12))
510 BLIT COPY SA,DA,CW,1,ST,TS
520 NEXT Y
660 BLIT MODE7 TX,BB,640,480,U0,V0,DC,DS,0-DS,DC,1023,511,TS,ST
710 BLIT MEMCOPY BB,FB,1228800
720 VSYNC
760 GOTO 400

Open the browser demo, type LOAD "sdk/examples/basic/wobble_zoom.bas", then RUN. Or type RUN AOT to compile the same BASIC to native IE64 code and run that instead. Chapter 52 of the Reference Guide explains how it works, buffer by buffer. To pass your own work to someone else, send them the source and its assets: they open the browser demo, add the files to the disk, and it runs, with nothing installed either side. Programmes that keep to the compiled core of BASIC also COMPILE to a standalone .ie64 you can hand to anyone who has the machine. The source and examples are on GitHub.

Launch IE64 BASIC in your browser Download the Intuition Engine 1.0.8 live image Source and examples

The browser build is the real machine compiled to WebAssembly: the same IE64 BASIC with a disk volume of demos. IE64, IE32, 68020, Z80, 6502 and x86 code use WebAssembly JITs, with x86 JIT compilation available when the browser supports WebAssembly SIMD. The live image requires an x86-64-v3 processor: Intel Haswell (2013) or newer, or a compatible AMD processor. It bundles worked examples in BASIC, assembly and C, together with the Linux x86-64, Linux ARM64 and Windows x86-64 Host SDK archives. When your demo sticks to the compiled core of BASIC, COMPILE writes it out as a standalone .ie64 you can hand to anyone with the machine.

The Programmer's Reference Guide

A from-zero tutorial and a reference in one book. It starts at the BASIC prompt because that is the quickest way to touch the machine: you type short programmes, inspect memory with PEEK, change hardware with POKE, and later enter machine code directly in IE Mon. No assembler, no build system and no second computer are needed to follow it. Sixty-six chapters and twelve appendices later, it ends with a complete game port, and every register, opcode and memory map along the way is written down.

Why this book exists

The manual that comes in the box

The 8-bit Commodore under the Christmas tree in 1988 came with a manual that assumed an eleven-year-old could learn to program the machine, and it was right. This guide is written in that spirit: for kids starting from nothing, for sceners who want every register, and for anyone who wants to learn game and demo programming from scratch, on the machine, for the machine.

Never programmed before

Five milestones, not sixty-six chapters

You do not read the whole book first. You climb it, one finished thing at a time:

  1. First command: Chapter 1 starts you at the Ready prompt.
  2. First picture on screen: Chapters 3 and 4.
  3. First moving effect: Chapter 46, Your First Frame Loop.
  4. First effect locked to music: Chapter 53.
  5. First complete intro: Chapter 55.

Everything between the milestones is there for the day you want it, not a prerequisite.

Need every register

The full reference underneath

The same book documents the whole machine: all six CPUs with their opcodes, every video and sound chip, the memory model and MMIO maps, timing and traps, coprocessors, IE Mon and IEScript, and the Part VIII game-port case study. Twelve appendices hold the tables you will keep open while you code.

Part Chapters What you learn
I. Intuition Engine BASIC1 to 2The BASIC dialect and its full keyword vocabulary.
II. Programming Graphics3 to 10The display model, VideoChip, VGA, TED, ANTIC/GTIA, ULA, Voodoo, and tile and sprite layers.
III. Programming Sound and Music11 to 23Every sound chip and player, from SoundChip and SID to MOD, MIDI/MUS and Paula DMA.
IV. BASIC to Machine Language24 to 34The memory model, all six CPUs, timing and traps, coprocessors, IE Mon and IEScript.
V. Input / Output Guide35 to 39Disk and file I/O, the HOST command, keyboard, mouse and controller input, serial, and network sockets.
VI. Whole-Machine Project40 to 45Interrupts, raster timing, programme layout, and two cookbooks, built into a working machine.
VII. Demo Programming46 to 56A guided build from a first frame loop to a complete intro.
VIII. A Full Game Port Case Study57 to 66A complete game port, from Fast3D to hardware T&L and native IE audio.
Appendices

Twelve reference appendices

  1. A. IE64 BASIC keyword abbreviations and token map
  2. B. Screen and character codes
  3. C. ASCII and CHR$ tables
  4. D. Per-engine MMIO maps
  5. E. Music note and frequency tables
  6. F. Maths and derivative helpers
  7. G. Per-CPU opcode quick reference
  8. H. Per-CPU symbol index
  9. I. Error message index
  10. J. Full memory map
  11. K. Block diagrams
  12. L. Index
Start with the preface Read a chapter: Your First Frame Loop Download the whole book

The guide is written to be read in order, one finished thing at a time. The preface and the frame-loop chapter each read on their own if you want a taste before the full download.

Six CPU views, one bus

A profile boots the machine into one of six instruction sets and sets its loader and RAM ceiling. Any CPU can then start the others as concurrent workers, and every core reaches the same MachineBus RAM, SYSINFO, MMIO devices, video and audio engines, files, debug state, and coprocessor services. None of these details is required before starting at the BASIC prompt.

CPU views

CPU view matrix

Every CPU keeps its native idioms, and they all reach the same bus. A Z80 port write, an x86 IN/OUT, a 6502 paged or banked access, and a 68020 absolute address all land on the same MachineBus devices and RAM that IE64 sees. Guest code keeps the access patterns natural to its own CPU while reaching the same devices.

IE64 ISA and IE32 ISA

Byte order

One value, any CPU

The bus normalises every MMIO access. A big-endian 68020 running MOVE.L and a little-endian IE64 running STORE.L deliver the same value to the same device register. Plain RAM keeps each CPU's natural order: big-endian for the 68020, little-endian for the rest.

Concurrency

Many CPUs at once

A profile boots the machine into one instruction set, then any CPU can bring the others online as workers, up to nine at once across the six types, all running at the same time on the same bus. M68K, x86 and IE64 each run two worker instances; IE32, the 6502 and the Z80 run one each. CPUs have their own interrupt lines, and each device uses its defined target and delivery path.

Coprocessor model

MachineBus

RAM sizing for guest code

Guest RAM is sized at boot from the host's own usable memory, less a platform reserve. Backing size, total guest RAM, active RAM, low-window bounds, and profile ceilings live on the bus. SYSINFO publishes those values; IE64 also reads CR_RAM_SIZE_BYTES.

Architecture PDF

Bus services

Runtime services as address ranges

Bus address ranges cover file I/O, media load, Program Executor, terminal, keyboard, mouse and USB gamepad input, CPU wait, Voodoo apertures, Bootstrap HostFS, and SYSINFO.

Service map

CPU view Programme form Hardware contract x86-64 execution
IE64 .ie64, BASIC AOT, IntuitionOS images 64-bit PC, data, stack, control registers, and optional paged MMU. JIT-backed, with FPU native/helper paths.
IE32 .iex, .ie32 Fixed 8-byte 32-bit RISC-like instruction stream. JIT-backed.
6502 .ie65 Byte-oriented code uses mapped helpers for MachineBus devices. JIT-backed.
Z80 .ie80 Register-pair and port idioms drive MachineBus memory and MMIO. JIT-backed.
M68K .ie68, EmuTOS, AROS 68020-class integer code uses absolute bus addresses and profile bridges. JIT-backed, including 68881-style FPU native/helper paths.
x86 .ie86 32-bit flat guest binaries can use MachineBus file, video, audio, and coprocessor devices. JIT-backed, including x87 FPU paths. The interpreter also supports x87 environment save and restore.
Lifecycle

Reset and reload

Reset and load routines quiesce scripts, render loops, media, the CPUs, EmuTOS and AROS, then rebuild CPU and profile state, rewire the monitor and Program Executor, and reload the configured coprocessor services.

IE64 CPU

The native 64-bit core

A 64-bit RISC load-store CPU with 32 general-purpose registers (R0 hardwired to zero), fixed 8-byte instructions and a 16-register control bank. Integer branches compare registers directly, so there is no flags register. The x86-64 live image JIT-compiles it to native x86-64 code, while the browser build compiles hot blocks to WebAssembly.

The FPU adds 16 IEEE-754 registers, single precision with double precision on even and odd pairs. A six-level paged MMU brings address translation, page-level access control and supervisor access guards, with a hardware trap-frame stack that preserves the fault-control registers across nested traps, so a handler survives a second fault without saving them by hand. Six sequentially-consistent 64-bit atomics, compare-and-swap, exchange, fetch-and-add and the bitwise operations, each act as a full memory barrier: the lock-free backbone for six CPUs on one bus. IntuitionOS and BASIC AOT both target it.

JIT

JIT compilers for six CPUs

In the x86-64 live image, IE64, IE32, M68K, x86, Z80 and 6502 compile guest code to x86-64 machine code as it runs. In the browser, all six CPUs have WebAssembly JITs. The x86 JIT requires WebAssembly SIMD. Every available JIT starts enabled, including programmes launched from BASIC and JIT-capable coprocessor services. If a backend is unavailable, execution stays with the relevant interpreter. Instructions and accesses that cannot stay in compiled code use the relevant interpreter or helper path with guest state preserved. The compilers handle self-modifying code and include CPU-specific floating-point paths for the IE64 FPU, M68K 68881 and x86 x87.

Even with the paged MMU enabled, IE64 code stays JIT-compiled: the dispatcher keys native blocks by translation state, and data, stack, floating-point and control-flow accesses that need address translation take a helper exit and resume in native code instead of bailing the whole block.

MMIO hardware map

Device services live at fixed bus ranges. Low-level code can talk to them by writing to registers rather than calling a host API.

Common ranges

SYSINFO publishes RAM and feature bits. File I/O adds the IE64 FILE_DATA_PTR64 extension. Media load, Program Executor, terminal, keyboard, mouse and USB gamepad input, CPU wait, shared network sockets, Voodoo apertures, Bootstrap HostFS, and the gated host-command helper map as bus services. The socket block gives machine-language programmes IPv4 TCP and UDP in every recognised non-BASIC mode. Through the host-command helper, a booted image becomes an appliance you drive from BASIC: HOST NET configures WiFi, HOST UPDATE updates the installed appliance packages from the signed Intuition Engine repository, verifying the engine checksum and version and restoring the previous binary if validation or the restart check fails, and HOST REBOOT and HOST POWEROFF restart or shut it down.

SYSINFO FILE_DATA_PTR64 MEDIA EXEC WAIT HOST_SOCKET VOODOO BOOT_HOSTFS GAMEPAD

USB gamepads

A read-only gamepad block sits at 0xF25C0-0xF25FF. 0xF25C0 reports a connected-pad mask and a pad count, then up to four twelve-byte pad records follow from 0xF25D0. Each record holds a seventeen-button bitfield and two signed sixteen-bit analogue sticks. Any CPU reads it as plain MMIO, native M68K access included, and it is filled on the desktop and in the browser build alike, the latter through the browser's own Gamepad API. From BASIC, PAD(n) returns pad n's button bits and PADX(n) and PADY(n) its left stick, with the shipped joydefs.bas naming each button.

0xF25C0 4 pads 17 buttons 2 sticks

Profile bridges

AROS maps DOS packets, Paula-style audio DMA, clipboard access, IRQ diagnostics, and live MIDI through a CAMD driver (DEVS:Midi/ie) under camd.library. It also supplies guest-side integration for the shared network-socket block. EmuTOS uses an Atari MIDI ACIA shim that feeds the live-MIDI engine.

AROS_DOS AROS_AUDIO_DMA HOST_SOCKET AROS_CLIPBOARD camd.library IRQ_DIAG AtariMIDIACIA

An Atari OS, an Amiga OS, and one of its own

The machine boots real operating systems that drive its hardware through their own drivers. EmuTOS and AROS are established systems ported to the machine; IntuitionOS is the machine's own operating system, written from scratch and still in development. Each boots through its own loader, and their graphics, input, file, MIDI and audio routes write to MMIO registers and mapped bus memory, then use the relevant interrupt and device-state paths.

Guest CPU view Graphics route Other device routes
EmuTOS M68K Hardware-accelerated IE VideoChip driver; EmuTOS runs a 1920 x 1080 CLUT8 desktop with direct VRAM and blitter-backed drawing. Keyboard, mouse, terminal, timer IRQs, PSG writes, GEMDOS mapping, Atari MIDI ACIA bridge.
AROS M68K Hardware-accelerated iegfx.hidd; defaults to 1920 x 1080 scanout, direct VRAM, and blitter drawing. AmigaDOS packet bridge, Paula-style audio DMA, kernel-ie-m68k-ahidrv, Devs/AHI/ie-audio.audio, host socket bridge, clipboard bridge, IRQ diagnostics.
IntuitionOS IE64 graphics.library requests CHIP and VRAM grants, maps them with SYS_MAP_IO, and opens VideoChip mode 7. hardware.resource brokers access to CHIP registers and monopoly VRAM grants.
EmuTOS

EmuTOS VideoChip driver

EmuTOS gets a hardware-accelerated IE VideoChip driver through the IE target. The implementation runs a 1920 x 1080 CLUT8 desktop over direct VRAM and uses the VideoChip blitter for screen and VDI drawing. It reads keyboard and mouse MMIO, and drives timer IRQ level 5 and VBlank IRQ level 4.

IE_VIDEO_CTRL  0x000F0000
IE_VIDEO_MODE  0x000F0004
IE_VRAM_BASE   0x00100000
EmuTOS mode    1920 x 1080 CLUT8, stride 1920
IE_PSG_BASE    0x000F0C00
EmuTOS GEM

A rotozoomer in a GEM window

Proof of the driver at work: rotozoomer_gem.prg is a rotozoomer written in m68k assembly as an ordinary windowed GEM application. It runs on the EmuTOS desktop and drives the VideoChip blitter's Mode 7 affine texture unit for the rotation and zoom, a stock GEM programme reaching hardware no Atari ever shipped. Its soundtrack is an Amiga AHX module, played with no Paula emulation at all: the AHX oscillators and envelopes are rebuilt as voices on the machine's own subtractive SoundChip synth.

Source

AROS graphics and filesystem

AROS graphics target

AROS maps a 64 MiB VideoChip VRAM slice and supports big-endian VideoChip reads. Its hardware-accelerated iegfx.hidd defaults to 1920 x 1080 scanout and uses the VideoChip blitter for accelerated drawing. The system-tree build includes Libs/cybergraphics.library and installs ScreenMode and palette preferences. Filesystem packets use the AROS DOS handler block, and a configured host directory is served to the guest as real files through the AROS DOS handler. AROS boots all the way through to the Wanderer desktop.

AROS direct VRAM: 0x1E00000 + 0x4000000
AROS gfx driver:  Devs/Drivers/iegfx.hidd
AROS_DOS:         0xF2220-0xF225F
AROS audio, AHI, socket, clipboard

audio.device to SoundChip

Four guest DMA channels run through the AROS Paula-style DMA shim at 44.1 kHz, become SoundChip FLEX DAC writes, and complete with M68K level-3 IRQs. The AROS build also runs kernel-ie-m68k-ahidrv, validates Devs/AHI/ie-audio.audio, and maps host sockets and clipboard access through MMIO.

CHn: PTR LEN PER VOL
DMACON  0xF22A0
STATUS  0xF22A4
INTENA  0xF22A8
IntuitionOS · native OS

The machine's own OS, in development

IntuitionOS is the machine's own operating system, written from scratch in IE64 assembly and modelled on the Amiga OS, down to Amiga-style volumes such as C:, S: and LIBS:. Its core is IExec, a protected capability-based microkernel inspired by Amiga Exec and QNX Neutrino, where services and drivers are separate protected modules that talk through named message ports. It is a work in progress, not a finished system. Today it boots to a shell with real DOS commands (dir, list, type, assign and more), runs up to 255 pre-emptive tasks that talk through Exec-style message ports, discovers libraries with OpenLibrary and a protected module registry, and loads ELF programmes. It brokers hardware through a grant model, with graphics.library opening 960 x 540 scanout in VideoChip mode 7, and reports faults the old way, with a GURU MEDITATION.

CHIP PPN: 0xF0
VRAM PPN: 0x100
Mode: 960 x 540 RGBA32, stride 3840
IntuitionOS · security

Capability-based isolation

A task only reaches the memory and hardware it was granted. Each task has separate limits for private pages, message ports, waiters, shared-memory pages and grants. Shared memory is handed out as opaque capability handles, reference-counted and scrubbed to zero when the last mapping drops, and MMIO maps only through explicit grants. The IE64 MMU gives every task its own page tables with separate code, stack and data and W^X enforcement, guard pages catch overruns, and the kernel validates every user pointer before it reads across the supervisor boundary.

At build time, programmes are position-independent for ASLR, no segment may be both writable and executable, and the ELF loader rejects dynamic linking, external-symbol relocation and text relocations. Kernel ASLR and a stack canary are in progress.

MIDI split

Live MIDI by profile

Raw byte-stream registers for live MIDI sit at 0xF0BF4-0xF0BF6. EmuTOS uses an output-only MC6850 ACIA shim at $FFFC04 and $FFFC06, feeding the live-MIDI parser. AROS uses an ie-m68k CAMD driver (DEVS:Midi/ie) under camd.library. The current source tree has no IntuitionOS MIDI driver path.

Driver-level demos

AROS rotozoomer demos

The live image includes EmuTOS rotozoomer_gem.prg plus AROS RotoAPI, RotoHW, RotoAPIc, and RotoHWc. The AROS pairs separate API drawing from direct-hardware access in assembly and C.

Demo gallery

CPUs can be devices for another CPU

Type COSTART at the BASIC prompt and a separate processor starts working while your programme continues. The worker executes 6502, Z80, 68020, x86, IE32 or IE64 instructions and communicates through shared RAM, mailbox rings and tickets. One CPU can therefore provide a service to another without reducing the worker to a host library call.

There is no guest-visible central bus arbiter. Every CPU carries its own interrupt lines, while devices use their defined targets and delivery paths. The processors cooperate over shared RAM and the same devices rather than through a master. Any CPU can bring the others online: M68K, x86 and IE64 each run two worker instances and IE32, the 6502 and the Z80 run one, for up to nine workers at once, all executing concurrently. A caller queues a request and polls or waits on a ticket; BASIC drives it through named commands, while assembly and C write the coprocessor MMIO block and mailbox rings directly.

Request flow

Caller COSTART / COCALL or MMIO Per-worker mailbox ring Worker CPU Response or ticket 
COSTART cpuType, instance, "serviceFile"
ticket = COCALL(cpuType, instance, op, reqPtr, reqLen, respPtr, respCap)
COWAIT ticket, timeoutMs
status = COSTATUS(ticket)
COSTOP cpuType, instance

The instance argument selects worker 0 or 1 and defaults to 0, so the shorter forms without it still work. COCAPS, COINSTANCE and COSELSTATE report how many instances a type supports, which one is selected, and whether it is running.

Worker CPU Service suffix Instances
IE32.iex, .ie321
6502.ie651
M68K.ie682
Z80.ie801
x86.ie862
IE64.ie642
What it is for

One job per processor

Split a demo across real cores: a 6502 running a sound routine, a 68020 drawing while an x86 grinds a plasma, each on its own instruction set, all feeding one screen. The same service image runs on either instance of a dual-instance type, so you can fan out two 68020 or two IE64 workers over the same code. For a first programme it takes one line: COSTART wakes the worker, COCALL hands it a job, and your own program never stops to wait.

Case study

Mario Kart 64: four CPUs on one bus

The IE port of Mario Kart 64 runs four processors at once. A main 68020 runs the game and builds each display list, a second 68020 worker translates that list into draw calls, a third 68020 worker runs the audio sequencer, and an IE64 worker handles transform and lighting; the geometry the IE64 and translation workers produce feeds a Voodoo that rasterises the frame. The two 68020 workers are the M68K type's two instances, live in the same title.

It maps the Nintendo 64 cleanly: the main 68020 stands in for the CPU, the IE64 and gfx workers for the RSP, the audio worker for its sound microcode, and the Voodoo for the RDP. The whole pipeline packs into one mariokart64.ie68 and runs at the native N64 framerate.

Mario Kart 64 case study

Audio, video, bus registers

Guest-facing audio and video entry points are bus registers. The tables below name the ranges used by the chip engines, players, Paula-style DMA, SoundChip/SFX, and video systems. The sound chips trace the classics, including SID from the Commodore 64, POKEY from the Atari 8-bits, the AY/YM from Spectrum, Amstrad and Atari ST, the SN76489 from the TI and Sega machines, and Paula from the Amiga.

IE SoundChip

The native SoundChip synthesiser

The native SoundChip is not a retro clone. Ten FLEX voices and 32 SFX sample channels, each voice with its own oscillator (square/pulse, triangle, sine, sawtooth and nine noise modes), ADSR envelope, sweep, PWM, ring modulation, hard sync and signed 8-bit DAC input. A global stage adds filter, overdrive and reverb, then auto-levelling, compression and limiting, ahead of the block-rendered mixer.

It also carries RawlandMini, a built-in GM-style patch table, so Standard MIDI Files, Doom MUS and live MIDI play straight through the chip across 16 MIDI channels and 10 active voices, with GM-style programme families and a drum channel.

FLEX ch0-3   0xF0A80-0xF0B7F
SID2 ch4-6   0xF0C40-0xF0CFF
SID3 ch7-9   0xF0D40-0xF0DFF
SFX ch0-31   0xF2600-0xF29FF
Clocking and samples

Separate chip clocks

Final output renders at 44100 samples per second with global filter, overdrive, reverb, and limiting. PSG defaults to 2000000 Hz. SN76489 uses 3579545 Hz NTSC and 3546893 Hz PAL; SID uses 985248/1022727 Hz; TED audio runs at 110840/111860 Hz; Paula/MOD period timing uses 3546895 Hz.

SoundChip/SFX mixer   44100 Hz
AHX song ticks         50/100/150/200 Hz
MOD and Paula periods  3546895 Hz source clock
WAV and MIDI/MUS       parsed, scheduled, mixed
Format coverage

Over twenty chiptune formats

Point the media loader at a tune and it works out the format, then feeds the right chip. Tunes that call for more than one chip get more than one: a stereo SAP drives two Atari POKEY chips at once, and a MultiSID .sid runs on two or three independently emulated SID chips, up to nine SID voices together.

MOD 4/6/8ch WAV MIDI SMF Doom MUS AHX/THX SID PSID/RSID/MultiSID TED/TMF SAP B/C YM2 to YM6 AY VGM/VGZ SNDH VTX PT1/PT2/PT3 STC SQT ASC FTC
Plus mode

Optional enhanced rendering

Five classic engines, PSG, SID, POKEY, TED and AHX, each have an optional Plus mode. Leave it off for the authentic chip, or switch it on for an enhanced render path with drive, stereo spread, room and per-voice balance, straight from BASIC with PSG PLUS ON, SID PLUS ON and the rest. The sound registers do not change; only the rendering does.

Audio block MMIO registers Guest behaviour
SoundChip and SFX 0xF0A80 FLEX, SID2/SID3 FLEX ranges, SFX ext 0xF2600-0xF29FF Ten FLEX synth channels, 32 SFX sample-trigger channels, square/pulse, triangle, sine, noise, sawtooth, nine noise algorithms, ADSR, sweep, PWM, hard sync, ring modulation, signed 8-bit DAC input, global filter, overdrive, reverb, limiter, and block-rendered mixer output.
PSG/AY and SN76489 PSG 0xF0C00-0xF0C0F, PSG player 0xF0C10-0xF0C1C, SN76489 0xF0C30-0xF0C3F AY-style tone/noise/envelope registers, PSG-family file playback, SN76489 latch/data writes, ready/status reads, and selectable LFSR mode.
SID, TED, POKEY SID 0xF0E00-0xF0E1C, TED audio 0xF0F00-0xF0F05, POKEY 0xF0D00-0xF0D0A SID voice, pulse, ADSR, sync/ring, filter, and model state; TED two-voice sound and DAC mode; POKEY four channels, AUDCTL pairing, distortion modes, and readable polynomial tap.
Music and media players AHX 0xF0B80, MIDI 0xF0BA0, MOD 0xF0BC0, WAV 0xF0BD8, SAP 0xF0D10, TED player 0xF0F10, media loader 0xF2300 Pointer, length, control, status, position, subsong, tempo, volume, and loader registers for AHX, MOD, WAV, MIDI/MUS, SID, PSG-family, SAP, and TED data.
Paula DMA and live MIDI Paula 0xF2260-0xF22AF, live MIDI 0xF0BF4-0xF0BF6 Four DMA sample channels into SoundChip DACs, completion status, interrupt enable, raw MIDI byte input, active status, and all-notes-off reset.

Live MIDI

Live MIDI maps a byte-stream port on MachineBus. EmuTOS reaches it through an output-only Atari ACIA bridge. AROS uses an ie-m68k CAMD driver (DEVS:Midi/ie) under camd.library. The current source tree has no IntuitionOS MIDI driver path.

Cadences and compositing

CPU execution, the 60 Hz compositor and the 44.1 kHz audio mixer run on separate cadences. At 60 Hz the compositor sorts sources by layer, and video engines publish frames through dirty rectangles, retained leases and triple-buffer handoff; hardware layers carry dimensions, position, opacity and dirty rectangles. Several of the real chips can be on screen at once, each on its own layer, stacked into one frame.

CRT presentation

CRT presentation after composition

CRT presentation is off by default in the live image and browser build. Compositor layers retain their source resolution for scanline spacing, while phosphor persistence, glow, bloom, a colour mask and deconvergence shape the completed frame. Several composited video chips appear as light on one display rather than as separately filtered screens. Press F7 to cycle between flat CRT, curved CRT and unfiltered output. Pictures fill the output by default. When the active picture has a different aspect ratio, press F11 to switch between stretch and aspect-fit presentation.

IE VideoChip

Framebuffer, blitter and copper

Layer 0 of the compositor and the native display. A framebuffer up to 1920 x 1080 in RGBA32 or CLUT8, fed straight from main memory, with a nine-operation blitter: copy, fill, line, masked and alpha copy, colour expand, nearest-neighbour scale, memory copy, and SNES-style Mode 7 affine texture mapping, plus sixteen raster-op draw modes such as AND, OR and XOR for combining pixels with the destination.

The copper is a scanline-driven register writer. Every frame it walks a display list and writes to MMIO registers across the machine, so it can reprogram the VideoChip or any other chip mid-screen, one scanline at a time.

Voodoo 3D

A 3dfx-style 3D accelerator

Voodoo is a hardware triangle rasteriser: flat and Gouraud shading, textures up to 256 x 256 in paletted, intensity, alpha and ARGB formats, a depth buffer, alpha test and blend, per-pixel fog, chroma key, stipple and dithering, published through a double-buffered swap. It renders 640 x 480 by default, up to 800 x 600.

The live image runs Voodoo on the GPU, while the browser build uses the software rasteriser. Swap jobs run asynchronously. Guest CPUs feed it triangles directly, or an IE64 coprocessor runs the transform and lighting first, as in the Mario Kart 64 game port.

Video source Register and memory range Guest behaviour
VideoChip Registers 0xF0000+, VRAM aperture, direct-VRAM modes RGBA32 and CLUT8 modes, copper control, raster bands, blitter copy/fill/line/masked copy/alpha copy/colour expand/scale/memcopy, SNES-style Mode 7 support, and direct framebuffer scanout.
VGA Registers 0xF1000-0xF13FF, VRAM 0xA0000, text 0xB8000 Text mode, Mode 12h, Mode 13h, Mode X, sequencer, CRTC, graphics controller, attribute controller, DAC, palette RAM, planar and chain-4 memory behaviour.
TED video Registers 0xF0F20-0xF0F6B 40 x 25 text, 320 x 200 bitmap, multicolour text, hardware cursor, border colour, raster line registers, VBlank status, 121-colour TED palette model.
ANTIC/GTIA Registers 0xF2100+ Display-list DMA, scanline-aware render path, GTIA colour and priority registers, player/missile buffers, hardware collision detection, VBI and DLI status.
ULA Registers 0xF2000-0xF2017, VRAM aperture 0xFA000+ ZX Spectrum bitmap and attribute layout, border register, flash/bright attributes, auto-increment data port, VBlank status, and optional VBlank IRQ enable.
Voodoo Registers 0xF8000-0xF87FF, texture memory, command stream, fog/table/upload apertures Triangle rasterisation, Gouraud colour, Z-buffering, alpha test/blend, texture enable and upload, fog colour/mode, chroma key, clipping, swap buffers, status bits, and 640 x 480 default output.

IE Mon at hardware level

IE Mon is a whole-machine debugger. It switches focus between every registered CPU and disassembles all six instruction sets. When a running CPU is listed or selected, IE Mon briefly freezes it to capture coherent state, then restores its previous running state. From a frozen machine it single-steps one core while the rest stay frozen, or thaws chosen cores to run alongside it, sets conditional breakpoints and watchpoints, intercepts faults, edits memory in a hex editor, reads named I/O registers, and walks reverse history across every registered device.

Execution control

CPU state, live

IE Mon switches focus between registered CPUs and disassembles all six instruction sets natively, from IE64 and x86 to Z80 and 6502. It single-steps one core while the rest stay frozen, or thaws chosen cores to run alongside it, evaluates address expressions such as pc+$20, interleaves source when available, sets conditional breakpoints, intercepts faults, and assembles one IE64 instruction at an address.

cpu
r
d /s pc 8
b main+0x10 if R1==$10 && hitcount>2
s
g
Bus diagnosis

Memory and MMIO traces

SoftICE-style bpm* watchpoints cover byte, word, long, and quad accesses in read, write, or read/write mode. Page guards, access logs, who, bfirst, and trace mmio identify bus activity from recorded access data. A built-in hex editor edits memory in place, memory regions export to and import from disk, and a stack-trace command shows the call chain.

bpmqw $f0000
pg add $f0000 $f0fff rw cpu=current
accesslog on 1024
who wrote $f0004
trace mmio mmio 16
Reverse history

Back through snapshots

rs restores the focussed CPU from local step history. rg, rt, tl, and history horizon use retained whole-machine snapshots for registered CPUs, bus RAM, sparse IE64 backing pages, and versioned device blobs. A whole-machine restore reports any missing registered device rather than passing over it in silence.

history horizon
tl 12
rg
rt PC==$2000
ss checkpoint.ie64state
sl checkpoint.ie64state
Device views

Named register groups

io reads named I/O views at native width: audio, video, SYSINFO, cpu_wait, Voodoo, live and player MIDI, and other MMIO devices. Trusted .iemonrc files, aliases, macros, scripts, and the IEScript dbg.* API reuse those monitor commands.

io all
io sfx
io voodoo
rc list
rc trust .iemonrc
macro frame d pc 8; r
Always one key away

Press F9

Press F9 to freeze the running machine, including every CPU and the current audio state. IE Mon then opens over the frozen display. Press Esc to close the monitor and resume execution.

Symbols and source

Names and source lines

IE Mon loads symbols for guest binaries and weaves source into disassembly: VICE label files, .iesym sidecars and ELF symbol tables, kept per CPU and rebased to the load address. Drop a .lbl beside a SID, AY, MOD or PRG and it loads on its own, so a raw retro binary disassembles with real names.

IE Mon PDF Reference guide bundle

IEScript drives the whole machine

IEScript is the machine's own scripting engine, a Lua layer over the whole machine. Scripts launch programmes, inject keyboard and mouse input, read and write memory and MMIO, freeze and step CPUs, drive each audio and video chip, capture screenshots and video, and run a full debugger. Waits on frames, timers and settled frame hashes give deterministic synchronisation.

Launch

Script launch paths

.ies files run from BASIC with RUN "demo.ies", through Program Executor dispatch, or from the F8 IEScript REPL overlay. Frame and timer waits provide synchronisation points.

RUN "demo.ies"
Visual checks

Frames, hashes, recordings

Scripts wait on compositor frames, pixels, settled frame hashes, or custom visual predicates, so a demo can be automated and then verified pixel-for-pixel across runs. Scripts can select flat, curved or off CRT presentation, and fit or stretch scaling. They can capture either the composed guest image before CRT and host overlays or the final displayed frame after presentation. The recording module captures screenshots in pure Go with no external dependencies, and MP4 video with audio when FFmpeg is on the PATH, for demo clips and visual regressions.

sys.wait_frames(2)
video.wait_stable(3, 120)
hash = video.frame_hash()
video.set_crt_mode("curved")
rec.screenshot_composed("guest.png")
rec.screenshot_screen("screen.png")
rec.start_screen("run.mp4")
rec.stop()
Hardware automation

MMIO from IEScript

IEScript reaches memory and MMIO directly, plus dedicated modules for each chip: PSG, SID, TED, POKEY, AHX and MIDI on the audio side, and VGA, ULA, ANTIC, GTIA, TED and Voodoo, with the copper and blitter, on the video side. It also injects keyboard input through term.key_press with the keys scancode table, and mouse movement and clicks through term.mouse_press and term.mouse_click. The shipped rotozoomer script stages data with mem.write_block, writes VideoChip and blitter registers, and starts MIDI through MMIO.

cpu.freeze()
mem.write_block(texturePtr, texture)
cpu.resume()
video.write_reg(983040, 1)
video.blit_fill(1048576, 320, 200, 255, 1280)
video.blit_wait()
Debugger API

Monitor API

With dbg, scripts open the monitor, step or continue, set breakpoints and watchpoints, add page guards, intercept faults, read registers and memory, disassemble and trace, inspect I/O views, snapshot devices, save and load CPU-local snapshots, and switch between CPUs. Raw RAM access requires an explicit freeze; MMIO access does not. cpu.jit_stats() exposes backend-specific JIT statistics for the selected CPU across all six CPU types, including native execution, fallbacks, invalidations and cache activity where recorded.

dbg.open()
dbg.set_bp(0x2000)
dbg.step()
regs = dbg.get_regs()
io = dbg.io("midilive")
snap = dbg.device_snapshot("video")
dbg.close()
IEScript PDF IEScript demo card

IE64 BASIC, C and assembly

IE64 BASIC runs on the native 64-bit core. The same stored programme can run through the interpreter, compile ahead-of-time to native IE64 machine code and run at once, write itself out as a standalone .ie64 image, or transpile to readable IE64 assembly that you can inspect, edit and assemble again. The separate bare-metal C toolchain compiles C, assembly, ELF objects and static archives into the same flat .ie64 programme format. BASIC and C can both reach the machine's MMIO hardware.

Path What BASIC does Hardware or file interface
Stored programme LOAD, SAVE, BLOAD, DIR, and TYPE use the machine disk volume. BLOAD puts raw assets into guest memory. File I/O MMIO, including IE64 FILE_DATA_PTR64.
Native execution RUN AOT compiles the stored programme to native IE64 code inside the machine and runs it immediately. IE64 AOT mode, matching the visible result contract of RUN.
Standalone image COMPILE "DEMO" writes DEMO.ie64 and a matching IE64 assembly listing. Flat IE64 image plus self-contained assembly text.
Assembly round-trip TRANSPILE writes IE64 source only; ASSEMBLE reads IE64 source and writes a standalone .ie64. In-machine assembler at PROG_START.
Device control PEEK8/16/32/64, POKE8/16/32/64, WAIT, VSYNC, BLIT MODE7, and the direct sound commands. MMIO registers for video, blitter, audio, media loader, and timing.
Worker CPUs COSTART, COCALL, COSTATUS, COWAIT, and COSTOP call the coprocessor service block. Shared coprocessor MMIO and mailbox rings.

Compiler and transpiler

RUN AOT
COMPILE "name"
TRANSPILE "name"
ASSEMBLE "name"

RUN AOT compiles the stored programme to native IE64 code and runs it straight away. COMPILE writes a standalone .ie64 image with a matching assembly listing. TRANSPILE emits IE64 assembly text on its own, and ASSEMBLE turns that source back into a flat image. COMPILE rejects direct-mode-only commands and stored forms a standalone image cannot support.

Hardware from BASIC

10 POKE32 &H000F0800,1
20 SOUND 0,440,200,0,128
30 ENVELOPE 0,50,100,200,100
40 GATE 0,ON
50 VSYNC

BASIC vocabulary covers mixer initialisation, FLEX channel setup, envelope gates, video cadence waits, and later blitter, sprite, tile, Voodoo, file, or media-loader work.

Audio from BASIC

Direct BASIC audio covers SOUND, envelopes, filters, waveform/noise control, chip-specific commands such as PSG, SID, POKEY, and TED, plus raw SFX POKE32 writes.

SOUND PLAY "TITLE.MOD"
SOUND PLAY "INTRO.SID",0
SOUND PLAY "TUNE.AHX",1
SOUND PLAY "SONG.MID"

SDK and debug tools

The live image carries the full Host SDK archives and checksums under SDK/Toolchains. They are the supported downloads for the first-party assemblers, converter and IE64 C toolchain. IE Mon supplies the debugger.

Companion tools

Host SDKs

C is not limited to IE64. You can use any freestanding C compiler that targets 68020, Z80, 6502 or 32-bit x86, provided you link or convert its output to the flat image format expected by that CPU: .ie68, .ie80, .ie65 or .ie86. The SDK supplies the public intuitionengine.h hardware header for video, audio, media, input, file, network, coprocessor and Voodoo access. IE32 is the only CPU without a C compiler target.

Each Host SDK includes ie64-cproc, a freestanding C23 toolchain for the ie64-unknown-none target. It uses cproc, QBE and Picolibc, with the V3 IE64 ABI, scalar floating point, static archives and C atomics. It is not a hosted POSIX environment and does not provide dynamic linking, threads or C++.

ie64-cproc -o demo.ie64 demo.c

Copy demo.ie64 to the machine's file area, then type this at the BASIC prompt:

RUN "demo.ie64"

The downloadable Linux x86-64, Linux ARM64 and Windows x86-64 Host SDKs include ie32asm, ie32to64, ie64-cproc, QBE, ie64asm, ie64dis, ie64ld, ie64-ar, ie64-ranlib, headers, documentation and the bare-metal libraries.

Download Linux x86-64 Host SDK Linux x86-64 SHA-256 checksum Download Linux ARM64 Host SDK Linux ARM64 SHA-256 checksum Download Windows x86-64 Host SDK Windows x86-64 SHA-256 checksum
Assembly

Native assembly for all six CPUs

Every CPU has its own hardware-definition include, so you write assembly straight against the machine: ie32.inc and ie64.inc for the IE cores, and ie65.inc, ie68.inc, ie80.inc and ie86.inc for the 6502, M68K, Z80 and x86. IE32 and IE64 use their own assemblers, ie32asm and ie64asm; the retro cores use the standard ca65, vasm and NASM.

ie64dis disassembles IE64 and ie32to64 translates IE32 source towards IE64. Both are included in the Host SDK with the relevant documentation.

Manuals and register maps

Five manuals and the reference-guide bundle, each with a specific job. Every ISA table, monitor command, IEScript call and MMIO map is written down, including the Part VIII full game-port case study.

How the machine is built

The whole system in one document: the shared bus, all six CPUs, MMIO, the audio and video engines, and the tooling. Start here to see how the parts fit together.

The IE64 instruction set

The 64-bit RISC core in full: addressing, the FPU, control registers, the timer, privilege levels and MMU behaviour. The manual for the machine's native CPU.

How to debug it

The machine monitor: breakpoints, watchpoints, whole-machine reverse history, device views and scripted access. Freeze the machine and read it at hardware level.

How to automate it

The IEScript API: drive programmes, poke MMIO, capture screenshots and video, wait on frame hashes, and reach into the debugger, all from Lua.

Learn it from zero

The Programmer's Reference Guide: a from-zero tutorial and the full reference in one book, ending with the Part VIII game-port case study.