badline 0.10.1 → 0.11.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: e82b9f5bb012d15fd7744f164b82420c3b71c00b14b43843093e1a2b3722beeb
-  data.tar.gz: cf94f9a74e8c9d5d6b9d3a94a5404d29376a4c57da7f18b78c9dd87da4a7c880
+  metadata.gz: c2e262f4dbf07ef2d84f3a5eb673302102ecc9d4a5aa3ac87a908c6f0323c041
+  data.tar.gz: 026b7b26ce4cad94cf386a4b944c4ce34d34635e8dd8a568a352090320deabd9
 SHA512:
-  metadata.gz: 14986d25fea5add5cecf4c10001b4f9cf9e087023f07bf8a8fc27d950f799ff41ae086518165ca67b840c440e5f56cf661d335ac5d4f5de347260c0bd44864bb
-  data.tar.gz: 12ba3fa5d2276efb1003edaa884e8f1c58ee7d2e2ac5e05b0f7d927e6d8b5a37869893f012d92560772b3adf18ea2d886c058737bf9e10aac25aec54e36afe6b
+  metadata.gz: d99d4042bdb920cfbaa9501a2fff2a6cc155dda76518b28a58e863d95bd18ef3d891f7dff5d935cc726ae380c9659bc09f5f11f7cefda657a4926bfc06974e76
+  data.tar.gz: 670579ee105286f5b5c04aaa63d5ae6a9fee9161f6735ccd9f7764152c43e421f6024a1ba7cfead0da92a7b87cab6f03b1b53a2d2e44693a62807b4f52ab81a3

data/CHANGELOG.md

@@ -1,5 +1,28 @@
 # Changelog
 
+## [0.11.1](https://github.com/elektronaut/badline/compare/v0.11.0...v0.11.1) (2026-10-09)
+
+
+### Features
+
+* emulate the C128D's 1571 drive in 1541 and 1571 mode ([2c32d99](https://github.com/elektronaut/badline/commit/2c32d993a0449b4b537d5f82e9711b0e14604f95))
+* fast serial between the C128 and its 1571 ([34fe02f](https://github.com/elektronaut/badline/commit/34fe02f2098664c94233da9e40828b40e41b6b1a))
+
+## [0.11.0](https://github.com/elektronaut/badline/compare/v0.10.1...v0.11.0) (2026-10-09)
+
+
+### Features
+
+* add the C128 in C64 mode, headless ([17462eb](https://github.com/elektronaut/badline/commit/17462ebb94b27fe59c7cee8c51e82be340158979))
+* boot badline c128 in C128 mode, with --c64 holding C= through the reset ([fbb57e5](https://github.com/elektronaut/badline/commit/fbb57e5e46bd1178bb63b2feedee6776a5e4cc57))
+* boot the C128 in C128 mode through its own MMU and KERNAL ([8bdd810](https://github.com/elektronaut/badline/commit/8bdd810c03cb916b3484fabbf84172098af26835))
+* bundle the C128's BASIC 7.0, KERNAL and character ROMs ([25329f8](https://github.com/elektronaut/badline/commit/25329f83e7a5e07c4df3ea49b85528184fd7f313))
+* follow the C128 between its 40 and 80 column screens, with 40/80 DISPLAY on F6 and ESC on Esc ([4099600](https://github.com/elektronaut/badline/commit/4099600d413fa617dc7cea63ac80302b759c9f08))
+* give the C128's VDC its 80 column display ([80b0831](https://github.com/elektronaut/badline/commit/80b083138629c6410c18a55b48f3e59d22d466f1))
+* run the C128 in the window as badline c128, in both builds, with its VDC, keys and snapshots ([d58eaf6](https://github.com/elektronaut/badline/commit/d58eaf606932527fda9fd5de308c4010bd9fc4cf))
+* run the C128's 2 MHz mode and TEST bit cycle by cycle ([9a0a483](https://github.com/elektronaut/badline/commit/9a0a483f775b2d06fabb32bd99988c1976753fa3))
+* serve device 8 and CHROUT through the C128 KERNAL's traps in C128 mode ([76c1764](https://github.com/elektronaut/badline/commit/76c1764a54d68960194126e50d228a979ace93a2))
+
 ## [0.10.1](https://github.com/elektronaut/badline/compare/v0.10.0...v0.10.1) (2026-10-08)
 
 

data/CLAUDE.md

@@ -49,8 +49,9 @@ requires only the namespace file.
 | --- | --- | --- |
 | rspec (`spec/`) | `bundle exec rspec` | Unit behaviour, all of `lib/` |
 | SingleStepTests 65x02 | `rake test` (100 sampled cases per opcode) | CPU, per-cycle bus traces |
+| SingleStepTests z80 | `rake test` (the first 100 cases per opcode, `Z80_SAMPLE=all` for all 1,604,000) | `Z80`: registers, flags, ports and the bus pins on every T-state |
 | Wolfgang Lorenz suite | `bin/lorenz` | CPU, CIA, interrupts |
-| VICE testbench | `bin/testbench <subtree>` | `VICII/`, `CIA/`, `interrupts/`, `CPU/`, cartridges with `--carts`, the true 1541 drive with `--drive`, and the VIC-20 with `--vic20` |
+| VICE testbench | `bin/testbench <subtree>` | `VICII/`, `CIA/`, `interrupts/`, `CPU/`, cartridges with `--carts`, the true 1541 drive with `--drive`, the VIC-20 with `--vic20`, and the C128 in C64 mode with `--c128c64` |
 | VICE SID testprogs | `bin/sidtests` | SID |
 | Drive scenarios | `bin/drive_scenarios` | The true 1541 running the DOS ROM: save, format, the error channel, idle, write protect and autostart |
 | CIA offline grids | `bundle exec rspec --tag slow spec/badline/cia` | CIA timers and shift register, against a bare CIA in about 2 min |
@@ -103,7 +104,7 @@ worktree and owns a different set of files.
 - The external suites under `vendor/` are gitignored, so a new worktree has
   only `vendor/.gitkeep`. From the worktree root, symlink the main
   checkout's suites into it:
-  `for d in 65x02 VICE-testprogs; do ln -sfn ../../../../vendor/$d vendor/$d; done`.
+  `for d in 65x02 z80-sample VICE-testprogs; do ln -sfn ../../../../vendor/$d vendor/$d; done`.
   The main checkout also has `vendor/OneLoad64-Games-Collection-v5`, which
   `rake vendor:checkout` doesn't fetch. Link it the same way only for
   `.sid` or media work. Don't re-run `rake vendor:checkout` there, and
@@ -129,12 +130,28 @@ worktree and owns a different set of files.
 
 ## Testing and baselines
 
-- `rake vendor:checkout` fetches SingleStepTests and VICE-testprogs into
-  `vendor/`
+- `rake vendor:checkout` fetches SingleStepTests 65x02, the Z80 sample
+  and VICE-testprogs into `vendor/`
 - `bundle exec rspec`: line coverage is about 97%. `spec/spec_helper.rb`
   fails a whole-suite run (every spec file, no filters) below 90%, while
   single-file and filtered runs skip the floor. `:slow` specs are excluded
   by default: run them with `bundle exec rspec --tag slow`
+- CI splits the spec files into shards, plain and `:slow`, by the run times
+  in `test/spec_times.json` (`bin/spec_shard`), and holds the plain shards'
+  merged coverage to the same 90%. After adding or moving expensive specs,
+  re-record the times with `bin/spec_shard --record` (its header says how)
+- Keep each plain example to a few hundred ms. A million cycles of a C64 or
+  a C128 cost 3 to 5 s of CPU, and about three times that under coverage,
+  so an example that boots a machine or runs more than about a million
+  cycles goes under `:slow`
+- Don't boot per example. Restore a machine from a State taken once
+  (`spec/support/taken_once.rb`), and share one machine between examples
+  that only read it. Assert on the cheapest oracle that proves the point: a
+  register or a RAM byte over a booted screen, a bare chip over a whole
+  machine, and the fewest cycles that reach the state
+- Before opening a pull request, run `bundle exec rspec --profile 10` (with
+  `--tag slow` for `:slow` ones) on the spec files you added or changed,
+  and hold them to that budget
 - `rake test`: SingleStepTests, plus the Minitest tests for the regression
   runners in `test/`. Run it for any CPU change
 
@@ -144,7 +161,7 @@ overrides that, capped by the core count, but keep the default, because
 other worktrees share the machine. Whole runs at 4 shards on an M-series
 laptop take 15 min for `testbench` (`VICII/`), 11 for `testbench-cia`, 1 for
 `testbench-interrupts`, 37 for `testbench-irqdma`, 11 for
-`testbench-cpu`, 2 for `testbench-carts`, about 25 for `testbench-expansions` and under 1 for `testbench-vic20`. `sid` takes about 12 min. `lorenz` chains itself and takes
+`testbench-cpu`, 2 for `testbench-carts`, about 25 for `testbench-expansions`, under 1 for `testbench-vic20` and about 30 for `testbench-c128c64`. `sid` takes about 12 min. `lorenz` chains itself and takes
 about 2.5 h on CI whole. `rake regression:lorenz-1` to `lorenz-4` run it as
 four stretches of about 40 min each, and they can run side by side.
 `test/baselines/README.md` has the full table. A killed `bin/testbench` run
@@ -196,7 +213,9 @@ the 6526A) for anything the interrupt register or the CIA model reaches; cartrid
 `testbench-carts`, plus `testbench-expansions` for banking; GEO-RAM, +60K,
 +256K, the REU or the VIC's BA line the REU follows → `testbench-expansions`; the 1541 drive, VIA or IEC bus →
 `testbench-drive` (`bin/testbench --drive`) and `drive-scenarios` (`bin/drive_scenarios <filter>`), plus `testbench-vic20` for the VIA; the VIC-20 (`vic20/`) →
-`testbench-vic20` (`bin/testbench --vic20`); SID → `sid`, plus `sid-8580` for anything the 8580
+`testbench-vic20` (`bin/testbench --vic20`); the C128 (`c128.rb`, `c128/`), or
+the VIC-IIe, CPU or PLA code it shares with the C64 → `testbench-c128c64`
+(`bin/testbench --c128c64`); SID → `sid`, plus `sid-8580` for anything the 8580
 model reaches (`bin/sidtests --sid 8580`). Leave the Lorenz chain to CI,
 unless your code has a rule in `doc/pinned-behaviour.md` that names Lorenz
 tests: the interrupt polling, CPU port and CIA timer rules. Run just the

data/CONTRIBUTING.md

@@ -68,12 +68,17 @@ boot the whole machine and are skipped by default. Run them with
 `bundle exec rspec --tag slow`.
 
 The CPU is verified separately against the
-[65x02 single step tests](https://github.com/SingleStepTests/65x02).
-`rake test` checks the fixtures out into `vendor/65x02` first, which
-takes a moment the first time:
+[65x02 single step tests](https://github.com/SingleStepTests/65x02), and
+the Z80 against the [Z80 ones](https://github.com/SingleStepTests/z80).
+`rake test` checks the 65x02 fixtures out into `vendor/65x02` first,
+which takes a moment the first time. For the Z80 it fetches only the
+first 100 cases of each opcode's file into `vendor/z80-sample`.
+`Z80_SAMPLE=all` checks the whole Z80 suite out into `vendor/z80`
+(about 1.5 GB) and runs every case:
 
 ```sh
 bundle exec rake test
+Z80_SAMPLE=all bundle exec rake test
 ```
 
 Check style before pushing:

data/README.md

@@ -13,7 +13,7 @@ are modelled at the cycle level.
 It runs programs, disk and tape images, cartridges and SID tunes, and
 the SDL2 front end supports the keyboard, joysticks, game controllers,
 paddles and a 1351 mouse. It also runs a PAL VIC-20, as
-`badline vic20`. See [What's emulated](#whats-emulated) for the details.
+`badline vic20`, and the C128, in C128 mode on 40 or 80 columns and in C64 mode, as `badline c128`. See [What's emulated](#whats-emulated) for the details.
 
 It comes in two builds of the same emulator:
 
@@ -69,7 +69,8 @@ from it.
 
 The first argument can name the machine, as in `badline c64 game.prg`.
 The C64 is the default, and `--model` picks which C64. See
-[The VIC-20](#the-vic-20) for `badline vic20`.
+[The VIC-20](#the-vic-20) for `badline vic20` and [The C128](#the-c128)
+for `badline c128`.
 
 `badline-ruby` takes the same media and the same options, with the
 differences noted in the table. `--help` lists the options for either.
@@ -87,6 +88,7 @@ differences noted in the table. `--help` lists the options for either.
 | `--reu SIZE` | Plug in a RAM Expansion Unit of `SIZE` K: 128, 256, 512 (a 1750) or up to 16384 |
 | `--model NAME` | Run another model of the machine, named as in VICE. For the C64: `c64` (the default, a PAL C64 with the 6569 VIC-II, 6526 CIAs and the 6581 SID), `c64c` (the PAL C64C, with the 8565, 6526As and the 8580), `ntsc` (the 6567R8), `newntsc` (the NTSC C64C, with the 8562, 6526As and the 8580), `oldntsc` (the first NTSC C64s' 6567R56A), `drean` (the Drean C64 of Argentina, PAL-N with the 6572), `sx64` (the portable SX-64, with its own KERNAL and no datasette), `pet64` (the PET 64 or Educator 64, a PAL C64 in a PET's case with its own KERNAL and a green monochrome monitor) `c64gs` (the C64GS games console, a PAL C64C with its own BASIC and KERNAL, and no keyboard or datasette) or `ultimax` (the MAX Machine of Japan, NTSC with 2K of RAM, one CIA and no ROMs, which runs only a cartridge). `--sid` or a `.sid` tune's own SID takes the model's place |
 | `--ntsc` | Run an NTSC C64, as `--model ntsc` does |
+| `--c64` | Start a C128 in C64 mode, holding `C=` at power-on. See [The C128](#the-c128) |
 | `--no-sound` | Don't play the SID (`badline` only, where sound is on by default) |
 | `--sound` | Play the SID (`badline-ruby`, where sound is off by default) |
 | `--no-vsync` | Pace the window by a timer, or by the sound while it plays, instead of the display's vsync |
@@ -163,6 +165,56 @@ goes in as a `.crt` does. Disks go through the KERNAL traps or, with
 save and load the VIC-20 too, in badline's own snapshots: xvic's `.vsf`
 files don't load.
 
+## The C128
+
+`badline c128` runs a C128 in C128 mode, with BASIC 7.0, and takes the
+same media as the C64:
+
+```sh
+badline c128              # READY., in BASIC 7.0
+badline c128 game.prg     # Load and run a program
+badline c128 game.d64     # Mount a disk image as device 8 and LOAD"*",8,1 it
+badline c128 --c64        # Hold C= at power-on to start in C64 mode
+badline c128 --model c128dcr game.crt
+```
+
+`--c64` holds `C=` down through the reset, so the C128 KERNAL starts C64
+mode, as on a real C128. A program that loads at `$0801`, where C64 BASIC
+starts, and a `.sid` tune start C64 mode the same way, and so does a C64
+cartridge, through the KERNAL. `GO64` gets there from BASIC 7.0. A
+program that loads at `$1C01`, where BASIC 7.0 starts, runs, and other
+programs load at their own address. The disk in device 8 is served
+through the KERNAL traps in either mode, or with `--true-drive` by the
+C128D's 1571. The C128's Z80 isn't emulated:
+the 8502 starts the machine. `--model` picks the board: `c128` (the default, the flat C128
+and the plastic C128D, PAL, with the 6581 SID and a VDC with 16K of
+RAM), `c128dcr` (the metal C128DCR, with the 8580, 6526As and a VDC with
+64K), and `c128ntsc` and `c128dcrntsc` for their NTSC versions. `--sid`
+takes the model's place. Without `c128`, a program that loads at
+`$1C01`, where C128 BASIC starts, picks the C128 too, and a `.d71`
+stays on the C64.
+
+The window shows the screen the C128 prints to, and follows it when
+it moves: to the VDC's 80 columns after `GRAPHIC 5`, `ESC X` or a reset
+with `40/80 DISPLAY` locked down, and back to the VIC-IIe's 40 columns
+after `GRAPHIC 0` or `ESC X` again. In C64 mode it shows the VIC-IIe.
+`F8` switches the window to the other screen, as a monitor's 40/80
+switch does, until the C128 next moves. The window takes the VDC's
+size, which its registers set, a dot to a pixel with its lines doubled.
+Only the chip shown is drawn.
+
+Besides the C64's keys, the C128's own keys sit on their host keys: the
+keypad on the keypad, `HELP` on `Insert` (or `Help`), `ALT` on the right
+`Alt`, `NO SCROLL` on `Scroll Lock`, `CAPS LOCK` on `Caps Lock` and
+`40/80 DISPLAY` on `F6` or `Pause`, both of which lock it down and up
+like the real key. In C128 mode `Esc` is `ESC` and `RUN/STOP` is on
+`Page Down` (`Fn`-`Down` on a Mac), and in C64 mode `Esc` stays
+`RUN/STOP`. In C64 mode only a program that scans the C128's keys
+itself sees them. `TAB`, `LINE FEED` and the separate cursor keys have
+no host key yet: `Tab` and the arrows keep their C64 uses.
+`F11`, `F12` and the pause menu save and load the C128 in badline's own
+snapshots, and x128's `.vsf` files don't load.
+
 ## Snapshots
 
 `F11` quicksaves the whole machine to the next of five slots in
@@ -200,7 +252,7 @@ types `"`. These keys have no same-named host key:
 
 | C64 | Host |
 |-----|------|
-| `RUN/STOP` | `Escape` |
+| `RUN/STOP` | `Escape`, or on the C128 `Page Down` (`Esc` is `ESC` in C128 mode) |
 | `CLR/HOME` | `Home` |
 | `INST/DEL` | `Backspace` |
 | `CRSR ⇔` / `CRSR ⇕` | `Right` / `Down`, and `Left` / `Up` for the shifted directions |
@@ -258,7 +310,7 @@ too.
 | Expansion port | The cartridge: insert, remove, and its freeze button if it has one |
 | Ports | The device in each control port, and where the keys go |
 | Sound | Mute, and the SID's model |
-| Power | Reset, power cycle and quit |
+| Power | Reset, power cycle and quit, and on a C128 its model and mode |
 
 INSERT opens a file browser. A disk's set is the `.m3u` or `.vfl` list it
 was opened from, or one in its folder that lists it. Without one, it comes
@@ -294,7 +346,14 @@ program or `.sid` dropped on it opens the menu to ask first.
   both 6522 VIAs, the keyboard, the joystick and RESTORE, RAM
   expansions up to 35K (`--ram`), cartridges, the datasette and the
   serial bus to device 8 (`badline vic20`).
+- **C128**: C128 mode with BASIC 7.0 and C64 mode, on the 8502 with its
+  port, FAST mode, the VIC-IIe with its extra keyboard lines, the 8722
+  MMU, the 8563 or 8568 VDC with its 80 column display, and 128K of RAM
+  (`badline c128`). The Z80 isn't emulated yet.
 - **1541**: an emulated drive running its own DOS (`--true-drive`).
+- **1571**: the C128D's drive running DOS 3.0, in 1541 mode and in 1571
+  mode at 2 MHz with both sides of a `.d71` or `.g71`, and fast serial
+  (burst) to a C128 in C128 mode (`badline c128 --true-drive`).
 - **Cartridges**: standard 8K, 16K and Ultimax, Simons' BASIC, Ocean,
   Fun Play / Power Play, Super Games, Epyx FastLoad, Westermann
   Learning, Rex Utility, C64 Game System / System 3, Dinamic, Zaxxon /

data/doc/pinned-behaviour.md

@@ -25,6 +25,7 @@ only catches the rows that happen to move.
 - [VIC phi1 bus](#vic-phi1-bus)
 - [VIC light pen](#vic-light-pen)
 - [VIC-II 8565](#vic-ii-8565)
+- [VIC-IIe 2 MHz and TEST bit](#vic-iie-2-mhz-and-test-bit)
 - [VIC-II NTSC](#vic-ii-ntsc)
 - [VIC-II 6572 (Drean)](#vic-ii-6572-drean)
 - [CIA 6526 timer pipeline](#cia-6526-timer-pipeline)
@@ -926,6 +927,80 @@ What the 8565 references don't settle, and so what stays as it is:
   6569's idle access, without the 6569's `$38ff` read where a DMA delay
   starts.
 
+## VIC-IIe 2 MHz and TEST bit
+
+The C128's VIC-IIe (`:mos8566`, `:mos8564`) adds $D030: bit 0 (FAST)
+runs the 8502 at 2 MHz, and bit 1 (TEST) clocks the raster counter in
+every cycle. `C128#cycle!` and `#clock_fast` drive both, through
+`VIC#take_cpu_bus`, `#test_step!` and `#refresh_cycle?`. The oracles are
+the testprogs' own references for `c128/2mhzVIC` (3 rows, from the
+author's machine) and `c128/d030tester` (33 rows), and the real-machine
+photos in `c128/2mhztest`. Those are C128-mode programs that switch to C64
+mode as they start, so no testbench list runs them yet: `spec/badline/
+c128_2mhz_spec.rb` runs six d030tester builds from their machine code at
+$1C0E and checks the readings they print.
+
+- FAST and TEST take hold in the second cycle after the write that sets
+  or clears them. Pinned by d030tester's "Lines cut": STA/STX $D030 keeps
+  TEST on for 4 cycles, but for 3 when the STA also sets FAST, because
+  the STX then runs its operand fetches at 2 MHz. With the delay at 0
+  the FAST builds cut 2 lines, not 3. Spec guard: `c128_spec.rb`.
+- In FAST mode the CPU runs in both halves of every cycle but Bauer's
+  refresh cycles 11-15, whose phi1 stays with the VIC: 121 CPU cycles a
+  PAL line. BA doesn't halt it. Pinned by `2mhz-vic-hires`,
+  `-multicolor` and `-extended`, whose drawing code assumes 121 cycles a
+  line.
+- An access to $D000-$DFFF waits for phi2: one in phi1 takes the whole
+  cycle. Pinned by `timing-change0`, whose `INC $D020` takes 8 half
+  cycles (its comment says "6 cycles + 2"). The machine finds out after
+  the CPU's step that it reached I/O, so `CPU::Core` needn't say where
+  its next access goes.
+- The VIC's accesses in a FAST cycle latch the CPU's bytes: the g-access,
+  or idle access, the byte of phi1, and a c-access the byte of phi2, as
+  one made before AEC does on the C64: $FF for the video matrix and the
+  byte's low nibble for colour. Pinned by `2mhz-vic-*` (the operands are
+  the pixels and the opcodes' low nibbles the colours) and by the "VIC
+  internal data" row of d030tester, which shows char $FF's glyph in
+  slow-mode lines after a FAST bad line.
+- A c-access in a cycle where the CPU reads or writes a VIC register
+  takes that byte for the video matrix as well. Pinned by d030tester:
+  `STX $D030` with X=0 leaves an `@` (McCabe's readme: "the `@`
+  represents a 0 written to $D030"), and the `DEC $D030` build (2mhzdec)
+  leaves char $FD, the byte it reads.
+- In the phi1 an I/O access waits through, the VIC sees the byte the CPU
+  writes, or the last byte the bus held for a read. Pinned by d030tester
+  and 2mhzdec, whose g-access there shows $00 (X) and $D0 (the operand's
+  high byte).
+- AEC can't follow BA down in FAST mode, so on a bad line it falls three
+  cycles after the last FAST cycle, and the c-accesses before it read
+  $FF and the halted CPU's nibble (`DisplayState#keep_bus`). Pinned by
+  d030tester's "VIC internal data" row, where three cells after the FAST
+  cycles show colour 0 (the halted read's $D0) and the rest the screen.
+- The TEST bit steps the raster counter ahead of each cycle it is set
+  in, except the line's last cycle, which steps it anyway, and the step
+  from the frame's last line to line 0 takes two cycles. Pinned by
+  d030tester: TEST across the line end (`32c_02_00`, `32c_03_00`) cuts
+  one line fewer, and the frame it keeps 312 lines long with two TEST
+  windows of a whole frame each reads 19656 cycles ($4CC8) only with the
+  two-cycle wrap. A step into a bad line's raster halts the CPU through
+  BA for the one cycle the raster matches: `2ae_02_00` and `2ed_02_00`
+  cut 5 lines for 4 cycles. Spec guard: `vic_iie_spec.rb`.
+- The beam doesn't follow the raster counter's steps: it draws the next
+  display line after the last one (`VIC#output_line`), so the lines TEST
+  skips move the picture up, until a line that ends in the vertical sync
+  (PAL lines 303-305, three lines from the fourth blanked one) puts the
+  beam back on the raster line. A blanked line the beam draws off the
+  raster line shows black. Pinned by d030tester's `vadjust` builds, which
+  move the picture up a line per cycle of TEST, `vadjust1` included,
+  where the first window leaves the raster counter on line 304, and by
+  the colour bar that `173_02_00` draws four lines taller.
+- Not matched: the d030tester references come from an emulator that
+  models PAL decoding. A line cut an odd number of times flips the colour
+  phase, so every row below it shows other hues (all 11 builds whose cut
+  is odd), and lines drawn while TEST runs show alternating hues and
+  per-cycle blanking. Their 8566 shows no grey dots. The 2mhzVIC
+  references have none either.
+
 ## VIC-II NTSC
 
 The 6567R8 (`Region::NTSC`) and the 6567R56A (`Region::NTSC_OLD`) run

data/doc/snapshots.md

@@ -80,6 +80,21 @@ it, and badline doesn't open xvic's. Restoring a
 VIC-20 snapshot while a C64 runs, or a C64 one while a VIC-20 runs,
 swaps the machine in the window.
 
+## The C128
+
+`badline c128` saves and restores the same way too. A C128 snapshot
+holds its 128K of RAM, both colour RAM banks, the CPU port, the MMU's
+registers and the page pointer writes it holds, the VIC-IIe, both CIAs,
+the SID, the VDC with its RAM and registers, the CPU, a cartridge, the
+tape, the disk device 8 serves through the traps and a true 1541, and
+restores into a C128 of the same model with the same SID, built for the
+same mode. The VDC's picture is left out and painted again while the
+window shows it, and the window shows the VIC-IIe after a restore. Its
+file names its machine `C128`, as x128's do, and holds only the
+`BADLINE` module, so x128 doesn't open it, and badline doesn't open
+x128's. Restoring a C128 snapshot while another machine runs swaps the
+machine in the window, as for the VIC-20.
+
 ## VICE
 
 Snapshots use VICE's `.vsf` format. badline writes VICE's modules for

data/lib/badline/address_bus/pla.rb

@@ -5,8 +5,9 @@ module Badline
     # The C64's PLA: what each page of the CPU's view maps to, from the
     # CPU port's LORAM, HIRAM and CHAREN lines and the cartridge's EXROM
     # and GAME. The bus that includes it supplies the page tables, the
-    # ROMs, the chips, and #map_ram_pages, which lays out the RAM that the
-    # ROMs, the cartridge and I/O map over.
+    # ROMs, the chips, #map_ram_pages, which lays out the RAM that the
+    # ROMs, the cartridge and I/O map over, and #map_io_pages, which lays
+    # out the chips at $D000-$DFFF, with #map_cartridge_io for I/O 1 and 2.
     module PLA
       # A chip's registers seen at another page, which reads and writes
       # them as at the page the chip starts at.
@@ -108,20 +109,6 @@ module Badline
         @write_pages.fill(bank, first_page, 0x20) if bank.is_a?(Cartridge::RAMBank)
       end
 
-      def map_io_pages
-        {
-          vic => 0xd0..0xd3, sid => 0xd4..0xd7, color_ram => 0xd8..0xdb,
-          cia1 => 0xdc..0xdc, cia2 => 0xdd..0xdd, @open_bus => 0xde..0xdf
-        }.each do |chip, pages|
-          pages.each { |p| @read_pages[p] = @write_pages[p] = chip }
-        end
-        @ram_expansion.map_io(@read_pages, @write_pages)
-        @read_pages[0xd7] = @write_pages[0xd7] = @debug_register if @debug_register
-        @read_pages[0xdf] = @write_pages[0xdf] = @reu if @reu
-        map_cartridge_io if @cartridge
-        map_extra_sids unless @sid_slots.empty?
-      end
-
       def map_cartridge_io
         @write_pages.fill(@cartridge, 0xde, 2)
         @cartridge.readable_io_pages.each { |p| @read_pages[p] = @cartridge }

data/lib/badline/address_bus.rb

@@ -217,5 +217,19 @@ module Badline
     def map_ram_pages
       @ram_expansion.map(@read_pages, @write_pages)
     end
+
+    def map_io_pages
+      {
+        vic => 0xd0..0xd3, sid => 0xd4..0xd7, color_ram => 0xd8..0xdb,
+        cia1 => 0xdc..0xdc, cia2 => 0xdd..0xdd, @open_bus => 0xde..0xdf
+      }.each do |chip, pages|
+        pages.each { |p| @read_pages[p] = @write_pages[p] = chip }
+      end
+      @ram_expansion.map_io(@read_pages, @write_pages)
+      @read_pages[0xd7] = @write_pages[0xd7] = @debug_register if @debug_register
+      @read_pages[0xdf] = @write_pages[0xdf] = @reu if @reu
+      map_cartridge_io if @cartridge
+      map_extra_sids unless @sid_slots.empty?
+    end
   end
 end

data/lib/badline/c128/banks.rb

@@ -0,0 +1,35 @@
+# frozen_string_literal: true
+
+module Badline
+  class C128
+    # The RAM the C128 KERNAL's bank numbers 0-15 reach, as its INDFET and
+    # INDSTA reach it for LOAD, SAVE and the file name: the RAM bank of the
+    # CR value the KERNAL's table at $F7F0 holds for the bank, with common
+    # RAM in bank 0. The ROMs and I/O some of those CR values map are left
+    # out.
+    class Banks
+      CONFIGURATIONS = 0xf7f0
+
+      def initialize(ram, mmu, kernal_rom)
+        @ram = ram
+        @mmu = mmu
+        @kernal_rom = kernal_rom
+      end
+
+      def peek(bank, addr) = @ram.peek(physical(bank, addr))
+
+      def write(bank, addr, bytes)
+        bytes.each_with_index { |byte, i| @ram.poke(physical(bank, (addr + i) & 0xffff), byte) }
+      end
+
+      private
+
+      def physical(bank, addr)
+        page = addr >> 8
+        common = page < @mmu.common_low_pages || page >= @mmu.common_high_start
+        ram_bank = common ? 0 : (@kernal_rom.peek(CONFIGURATIONS + (bank & 0x0f)) >> 6) & 0x01
+        (ram_bank << 16) | addr
+      end
+    end
+  end
+end