JSVecX

Embedding

jsvecx is a set of plain JavaScript files (no modules). Vendor them and load them in dependency order — utils, globals, the BIOS fastromdata, the e6809 CPU, the e8910 sound chip, the osint vector renderer, vector_t and vecx — but skip upstream's jQuery page driver. That driver owns a setTimeout loop and status UI that can't be paused or single-stepped, which the debugger needs. Instead replicate its main(): build the machine, point its renderer at a <canvas id="screen">, reset it, and drive it from a loop you control.

var vecx = new VecX();
vecx.osint.init(vecx);          // analog vector generator -> canvas#screen
vecx.e6809.init(vecx);          // 6809 core bound to the machine bus
vecx.vecx_reset();             // loads the BIOS; with no cart it boots Mine Storm
var CPF = (Globals.VECTREX_MHZ / 50) | 0;    // ~30000 cycles = one 50 Hz frame
(function loop(){ vecx.vecx_emu(CPF); requestAnimationFrame(loop); })();

The machine is plain objects. Everything the debugger needs is a method or field on the machine or its CPU:

Because the CPU and memory are ordinary JavaScript, the debugger single-steps with vecx_emu(1), reads and writes the registers directly on e6809, and implements breakpoints and watchpoints as host-side checks around the loop — no changes to the emulator.

Debugger integration

The debugger plug-in reads the live machine from window.EMU_BOOT and hands the shared framework a description of the Vectrex. Nothing is patched into the emulator; the whole surface is ordinary field access.

• Registers are read straight off vecx.e6809 each refresh — A B D X Y U S DP PC CC plus the E F H I N Z V C condition flags decoded from reg_cc — and written back the same way.
• Memory is exposed as four chips: a side-effect-free 64K CPU bus (the $C000–$DFFF VIA I/O window is skipped so auto-polling never trips a timer), plus the raw RAM, BIOS and cartridge. Disassembly uses the shared m6809 decoder.
• Single step is vecx_emu(1) — one 6809 instruction with its VIA and video cycles.
• Breakpoints are host-side: with any set, the loop steps one instruction at a time and compares e6809.reg_pc before each. Watchpoints wrap vecx.write8 and pause on a write to a watched address.
• Input is a 4-button keypad plus the analog stick shown as a D-pad; press/release set the held-direction flags and the button port the run loop feeds to the machine each frame.

Architecture

The Vectrex is unusual: it has no framebuffer. A Motorola 6809 drives a 6522 VIA whose ports feed a set of integrators and a digital-to-analog converter that steer the electron beam directly, drawing crisp vectors on a tall built-in CRT. jsvecx keeps each block as its own object hanging off VecX:

• e6809 — the Motorola 6809 core, single-stepped by e6809_sstep.
• vecx — the machine: the 6522 VIA, its timers and shift register, the DAC/integrator maths that turn port writes into beam movement, and the read8/write8 bus.
• osint — the "analog" vector generator: it accumulates drawn line segments and rasterises them to the 2D canvas, fading like phosphor.
• e8910 — the General Instrument AY-3-8910 sound chip; each video frame it renders EmuAudio.sampleRate/60 samples and pushes them to the shared audio sink.
• fastromdata — the 8K system BIOS, which contains the built-in Mine Storm game the console runs with no cartridge inserted.

Each vecx_emu chunk runs the 6809 while ticking the VIA and integrating beam motion, then hands the accumulated vectors to osint to draw — a complete, inspectable machine that boots straight to Mine Storm.

Sound

Upstream e8910 opened its own AudioContext and pulled the AY-3-8910 through a ScriptProcessorNode. We removed that context entirely and instead feed the shared EmuAudio sink (/debugger/src/audio.js): each video frame the run loop pulls the same AY renderer for exactly round(EmuAudio.sampleRate / 60) samples, converts them to interleaved-stereo Int16 (the AY is mono here, so each sample is duplicated to L and R) and calls EmuAudio.push. No second AudioContext is left running; the sink owns the only one.

The renderer has no built-in sample rate — it advances the chip a fixed four ticks per output sample and uses the tone-period registers directly, so a tone comes out at f = 2 * sampleRate / Period while the real chip is f = AY_CLOCK / (16 * Period). To get correct pitch at whatever rate the sink reports, start() computes a scale factor and every derived period counter (tone A, B and C, the noise and the envelope) is multiplied by it:

this.AY_CLOCK = 1500000;                       // AY-3-8910: 6 MHz crystal / 4
this.rateScale = 32 * EmuAudio.sampleRate / this.AY_CLOCK;
this.psg.PeriodA = (regs[0] + 256 * regs[1]) * this.rateScale;   // same for B, C, noise, envelope

Programming a known period and measuring the generated fundamental confirms the tones land within 0.15% of f = 1.5 MHz / (16 * Period) at both 48 kHz and 44.1 kHz. The Sound button is wired through the transport: transport.isMuted and transport.setMute delegate straight to EmuAudio, and playback starts muted (browsers block audio before a gesture) until the first click unmutes it.