| 1 |
|
| 2 |
<p align="center"> |
| 3 |
<img src="./.gh/logo.png" /> |
| 4 |
</p> |
| 5 |
|
| 6 |
## Releases |
| 7 |
|
| 8 |
**X16Emu ADD** is the Advanced Disassembler and Debugger, a fork of the |
| 9 |
[official Commander X16 emulator](https://github.com/X16Community/x16-emulator). |
| 10 |
|
| 11 |
Releases are named `R<major>.<nnn>`: |
| 12 |
|
| 13 |
* **`R<major>`** names the official Commander X16 release line the build follows. That half of the |
| 14 |
number is upstream's, and so are its release notes — they are not reproduced here. Read them at |
| 15 |
[X16Community/x16-emulator/releases](https://github.com/X16Community/x16-emulator/releases), |
| 16 |
e.g. [r49 ("Pyrite")](https://github.com/X16Community/x16-emulator/releases/tag/r49). |
| 17 |
* **`nnn`** counts the ADD builds on top of that line. Those are the changes listed below. |
| 18 |
|
| 19 |
`R49` means the build follows the R49 line, not that it is byte-for-byte official R49: the emulator |
| 20 |
core tracks upstream's ongoing development after that release, so a build may include upstream |
| 21 |
fixes made since R49 was cut. Each release package ships the `rom.bin` it was built and tested |
| 22 |
against — use that one. |
| 23 |
|
| 24 |
### R49.001 |
| 25 |
|
| 26 |
The first ADD release, following the upstream R49 line. Everything here is new relative to the |
| 27 |
official emulator. |
| 28 |
|
| 29 |
**Graphical debugger (`-imgui`)** |
| 30 |
|
| 31 |
* New Dear ImGui debug window with a dockable, rearrangeable layout that is saved between runs |
| 32 |
* Disassembly panel with effective-address tooltips, run-to-here and breakpoint toggling |
| 33 |
* CPU panel: registers with 65C816-aware widths, decoded flags, the stack, the X16 virtual |
| 34 |
registers R0–R15, and user-defined address watches |
| 35 |
* Memory panel: hex editor over CPU space, banked RAM and VRAM, with range selection, hex/ASCII |
| 36 |
search, changed-byte highlighting, and break-on-write straight from a selection |
| 37 |
* Source panel: original cc65 source in tabs, current line highlighted and centred on each stop, |
| 38 |
breakpoints settable before the PC ever reaches the code |
| 39 |
* VERA panel: palette, tile, sprite, bitmap and tilemap viewers, plus all 32 registers decoded |
| 40 |
per scanline so raster splits are visible rather than flattened |
| 41 |
* PSG, YM2151 and PCM panels with scope traces that keep drawing while the machine is paused |
| 42 |
* Symbols, Call Stack and Breakpoints panels; the call stack names frames by nearest label, so |
| 43 |
code without debug info still reads sensibly |
| 44 |
* Toolbar with run/step controls, an absolute clock-speed readout (red above native speed) and a |
| 45 |
warp toggle; status line showing run state, IRQ nesting depth, 24-bit PC, cycles and instructions |
| 46 |
|
| 47 |
**Remote debugging (`-debugport`)** |
| 48 |
|
| 49 |
* New Debug Adapter Protocol server over TCP, default port 9009, for VS Code, Visual Studio or |
| 50 |
any other DAP-compliant client |
| 51 |
* Breakpoints, stepping, stack traces, scopes, variables, memory read/write and disassembly |
| 52 |
* VRAM read and write through `readMemory`/`writeMemory` with a `vram:` reference, reaching VERA's |
| 53 |
17-bit space that the CPU map cannot address |
| 54 |
* Conditional breakpoints on registers and memory (`A == $05`, `byte[$1234] != 0`), bank-pinned |
| 55 |
conditions (`bank == 2`), and hit counts |
| 56 |
* Expression evaluation covering registers, memory, cc65 labels and equates, VRAM, and VERA |
| 57 |
registers — including `vera_line`, which reports the registers that actually rendered a given |
| 58 |
scanline |
| 59 |
* Scriptable keyboard, text and joystick input, making automated regression runs practical. The |
| 60 |
virtual SNES controllers need no gamepad attached and no `-joy1`..`-joy4` flag, so a headless CI |
| 61 |
machine can drive a game that reads the controller ports |
| 62 |
* `tools/x16dbg`, a .NET command-line DAP client with one-shot and interactive modes |
| 63 |
|
| 64 |
**Source-level debugging (`-dbgfile`, `-srcpath`)** |
| 65 |
|
| 66 |
* cc65 `.dbg` parsing: addresses map back to source files, lines, labels and equates |
| 67 |
* `.dbg` files auto-load alongside the program they belong to, including for modules the running |
| 68 |
program `LOAD`s at runtime, so debugging follows execution into overlays |
| 69 |
* Breakpoints are invalidated when a module unloads and re-resolved when one loads back in |
| 70 |
* Banked code in `$A000`–`$BFFF` is attributed to the correct RAM bank at runtime, so source |
| 71 |
mapping and breakpoints stay correct across bank switches |
| 72 |
|
| 73 |
**Debugger capacity** |
| 74 |
|
| 75 |
* Memory write watchpoints, up to 64 of them |
| 76 |
* 65C816 / GS support throughout: 24-bit bank:address browsing and mode-correct register widths |
| 77 |
|
| 78 |
**Windows** |
| 79 |
|
| 80 |
* Statically linked MSVC builds for x64, x86 and ARM64 — a single self-contained `x16emu.exe` |
| 81 |
with no SDL2, zlib or Visual C++ redistributable to install |
| 82 |
* Separate MIDI builds shipping FluidSynth, for those who want it |
| 83 |
* The emulator keeps running and painting while its window is dragged or resized, instead of |
| 84 |
freezing for the duration |
| 85 |
|
| 86 |
**Build and release** |
| 87 |
|
| 88 |
* Every push is built for all platforms; pushing an `R<major>.<nnn>` tag stages a draft release |
| 89 |
with every platform asset attached, ready for a human to publish, and the default branch keeps a |
| 90 |
rolling `dev` prerelease |
| 91 |
* ROM images are fetched with a fallback to the latest release when the upstream build artifact |
| 92 |
has expired |
| 93 |
|
| 94 |
**Known limitations** |
| 95 |
|
| 96 |
* The debugger and DAP server are experimental — expect keys, layouts and DAP details to change |
| 97 |
* The WebAssembly build is not tested with the debugger or the DAP server |
| 98 |
* MSVC builds have no `-trace`; use a `-mingw` package if you need it |
| 99 |
* Upstream's original `-debug` debugger is still present but is not extended by ADD |