MSP430 LaunchPad

Embedding

There is no upstream runtime to vendor here — the MSP430 is written from scratch as three plain-global JavaScript modules, loaded in order:

// 1. the assembled firmware, 2. the chip core, 3. the debugger plug-in
<script src="firmware.js"></script>   // window.MSP430_FW: original CC0 programs, real MSP430 words
<script src="msp430.js"></script>     // window.MSP430: the MSP430G2553 SoC + LaunchPad board
<script src="msp430-debug.js"></script> // EmuKit.defineMachine(...)

Boot. Construct the chip on a <canvas>, load a firmware image (code + reset vector) and run your own loop. One frame is a burst of instructions; you own it, so the debugger can pause and step it:

var chip = new MSP430(canvas, MSP430_FW.blink, { speed: 24000 });
(function loop(){
  var hit = chip.run(chip.speed, bps); // bps = breakpoint Set (byte addresses)
  chip.render();
  if (!hit) requestAnimationFrame(loop);
})();

The chip is plain objects — no wasm heap — so the debugger reaches everything directly:

Debugger integration

The debugger plug-in (msp430-debug.js) reads window.EMU_BOOT and calls EmuKit.defineMachine. Because the whole chip is ordinary JavaScript, single-stepping is just chip.stepInsn(), registers are read and written straight off chip.r (R0=PC, R1=SP, R2=SR, R3..R15) with the C/Z/N/V/GIE flags decoded from SR, and execution breakpoints are a host-side Set the loop checks against the program counter at each instruction boundary. Write watchpoints wrap the memory write path and pause when a watched byte address is written.

A new msp430 disassembler (/debugger/src/cpus/msp430.js) decodes the three MSP430 instruction formats — the double-operand ops (MOV, ADD, SUB, CMP, BIS, XOR, …), the single-operand ops (RRC, SWPB, RRA, SXT, PUSH, CALL, RETI) and the conditional jumps — with .B/.W, every addressing mode and the constant generator, so instructions decode to their real 2/4/6-byte lengths from the flash at 0xC000.

Architecture

The MSP430 is Texas Instruments' 16-bit ultra-low-power microcontroller family; the MSP-EXP430G2 "LaunchPad" is its iconic 0 development board, carrying an MSP430G2553. This emulator is a from-scratch model of the whole chip:

• MSP430 CPU — a von-Neumann 16-bit machine: 16 registers (R0=PC, R1=SP, R2=SR, R3=constant generator, R4..R15), the double-operand, single-operand and jump instruction formats, .B/.W byte/word operations, the seven addressing modes (register, indexed, symbolic, absolute, indirect, autoincrement, immediate) including the constant generator, and the C/Z/N/V status flags.
• Memory map — the real MSP430G2553 layout in one 64 KB space: 16-bit peripherals and special-function registers below 0x0200, 512 bytes of RAM at 0x0200, 16 KB of flash at 0xC000, and the interrupt-vector table at 0xFFE0 (the reset vector at 0xFFFE seeds the PC).
• Digital I/O — ports P1/P2 with their direction (PxDIR), output (PxOUT), input (PxIN), pull (PxREN) and function-select registers. The on-board LEDs are LED1 (red) on P1.0 and LED2 (green) on P1.6; the S2 button is on P1.3 (active-low with pull-up).
• Timer_A — Timer0_A3 with its clock divider and up / continuous modes, counting the instruction clock and setting the TAIFG overflow flag in TA0CTL.
• USCI UART — the UCA0 USCI used by the LaunchPad's ez-FET emulation as the backchannel UART. Every byte written to UCA0TXBUF is captured onto the on-screen serial console; the UCTXIFG transmit-ready flag stays set so real polling transmit code runs.
• Watchdog — the WDTCTL watchdog register; the firmware feeds/holds it (WDTPW | WDTHOLD) at start-up, as every MSP430 program does.
• Content — five original CC0 hand-assembled MSP430 programs: Blink LED1, Alternate LEDs, Button toggles LED1, Timer_A blink, and UART hello + counter. No third-party firmware.
• Honest limits. The MSP-EXP430G2 LaunchPad has no on-board audio, so this emulator is silent by design. Interrupt delivery is not modelled (the bundled firmware polls, as MSP430 examples commonly do — GIE and the flags are present); the DCO/BCM clock system, the ADC10/comparator, SPI/I2C USCI modes and flash self-programming are not modelled. Everything the bundled firmware exercises — the full instruction execution with all addressing modes, digital I/O, Timer_A, and the backchannel UART — is modelled faithfully.