Raspberry Pi (ARM Linux)

Embedding

The core is arm-js, a pure-JavaScript ARMv7-A / ARM Versatile Express system emulator (no wasm). To embed it self-contained and file://-safe, two things change from the stock project:

1. No network at runtime. Stock arm-js pulls the kernel, initramfs and device tree with $.get. Here they are base64-inlined into assets.js and System.load_binary is overridden to decode straight into guest RAM:

System.prototype.load_binary = function (key, phyaddr, cb) {
  var bin = atob(window.ARMJS_ASSETS[key]);   // base64 -> binary string
  for (var i = 0; i < bin.length; i++)
    this.memctlr.st_byte(phyaddr + i, bin.charCodeAt(i));
  if (cb) cb(this);                        // the kernel Image's cb kicks off run()
};

2. Own the machine, not the page. Instead of the stock HTML's DOM/localStorage-driven config and Boot button, the machine and its parameters are built in code and booted automatically:

window.bitops = new BitOps();
window.options = new Options();
var system = new VersatileExpress(new Configurations(), options);
system.uart0.write_to_terminal = term.write.bind(term);   // serial out -> VT
system.boot(params);                                     // load images, then run()

Serial input is a document-level key listener that feeds bytes into system.uart0.input_char(code) (arrow / Home / End / Ctrl keys become the usual ANSI/DEC escape sequences); serial output is written to a simpleterm VT.

Debugger integration

The debugger drives the emulator's own run loop; nothing about the ARM core is faked. window.EMU_BOOT.transport exposes pause / resume, single-instruction step, execution breakpoints and write watchpoints, all built on arm-js internals:

• Step runs the real pipeline. The loop already supports a stop-after counter, so stepping N instructions sets options.enable_stopper, system.stop_after = N and calls one system.loop() — real fetch / decode / execute / interrupt, then a clean stop.
• Breakpoints wrap cpu.fetch_instruction: if the fetched PC is armed, it throws the core's own "STOP", which the run loop already catches and halts on with the PC intact.
• Watchpoints wrap the three guest store methods (st_byte / st_halfword / st_word on the MemoryController) and throw "STOP" right after a write to a watched address.

// execution breakpoint via the CPU's own fetch path
var orig = cpu.fetch_instruction.bind(cpu);
cpu.fetch_instruction = function (addr) {
  if (bpSet.has(addr >>> 0)) throw "STOP";   // caught by System.loop, PC stays put
  return orig(addr);
};

Registers are read and written live off cpu.regs[0..15] (r15 = PC) and the cpu.cpsr flag object (n z c v q i f t + mode). Two memory views are offered: CPU memory (virtual), translated through cpu.mmu.trans_to_phyaddr so it follows the virtual PC once Linux enables the MMU, and physical RAM. Both feed the shared arm7 32-bit ARM disassembler.

Architecture

The emulated board is an ARM Versatile Express core tile with an ARMv7-A (Cortex-A-class) CPU — the same application-processor architecture family as a Raspberry Pi's SoC, running a stock upstream ARM Linux:

• ARMv7_CPU — an interpreting ARMv7-A core (ARM + Thumb state, banked registers, CPSR/SPSR, the full integer instruction set) with ARMv7_MMU doing real two-level page-table walks and armv7-cp15 as the system coprocessor.
• VersatileExpress — the machine: a PL011 UART (the serial console), a SP804 dual timer, a GIC interrupt controller, system registers and a virtio-mmio slot, all at their real MMIO addresses.
• Boot images — an uncompressed Linux 3.10.29 Image at 0x8000, a BusyBox initramfs.cpio.lzo at 0x800000, and a flattened device tree at 0x100. The CPU starts at 0x8000 in SVC mode with r1 = machine type and r2 = the dtb pointer, exactly as a real ARM boot loader leaves it.

What this is not: it is not a Broadcom BCM2835 and there is no VideoCore GPU, framebuffer or desktop — the exhibit is an authentic ARM-Linux-to-a-shell "Pi-class" machine over a text console, not a photoreal Raspberry Pi.