blockyard 0.0.9 → 0.1.1

package/docs/INSTALL.md

@@ -12,7 +12,7 @@ machines you choose. Every setting mentioned here is described in full in
 - [6. Run it as a service](#6-run-it-as-a-service)
 - [7. Decide who can reach it](#7-decide-who-can-reach-it)
 - [8. Accounts (optional)](#8-accounts-optional)
-- [9. HTTPS (optional)](#9-https-optional)
+- [9. HTTPS (on by default)](#9-https-on-by-default)
 - [10. Behind a reverse proxy (optional)](#10-behind-a-reverse-proxy-optional)
 - [11. Updating](#11-updating)
 - [12. Uninstalling](#12-uninstalling)
@@ -22,7 +22,7 @@ machines you choose. Every setting mentioned here is described in full in
 
 | need | notes |
 |---|---|
-| **Node.js 22 or newer** | `node -v` must print `v22` or later. Older runtimes fail on syntax at start-up, which looks like a bug in the app. Install from [nodejs.org](https://nodejs.org), your distribution's backports, or a version manager such as `nvm`. |
+| **Node.js 22.2 or newer** | `node -v` must print `v22.2` or later (the index build uses its built-in CRC-32). Older runtimes fail on syntax at start-up, which looks like a bug in the app. Install from [nodejs.org](https://nodejs.org), your distribution's backports, or a version manager such as `nvm`. |
 | **Bitcoin Core 25.0 or later** | [Bitcoin Core](https://github.com/bitcoin/bitcoin) with `server=1` and `txindex=1`, **on the same machine** as BlockYard, which reads the node's block files for the explorer's address index. A node on another machine is not supported. 25.0 is where `getblock` verbosity 3, which the index follower uses, arrived; 29.1 is what the macOS install was done against. `coinstatsindex=1` is optional (without it the UTXO figures are blank and the node is not asked for them). Not a pruned node: the index needs every block file. |
 | **RPC credentials** | Either read access to the node's cookie file (`<datadir>/<chain>/.cookie`, the usual case on the same machine) or an RPC user and password. |
 | **macOS or Linux** | There is nothing to compile, and the server calls no platform-specific API (no `child_process`, no `/proc`, no `systemctl`). Developed on Linux; a real install has been done on macOS (Core 29.1). The test suite runs in CI on Ubuntu, macOS and Windows (Node 22 and 24), but on Windows nothing more than the suite has been tried. Only the *service* instructions in section 6 are Linux-specific (they use systemd); on macOS run it in a terminal, or write a `launchd` plist. The index store opens its files per lookup, so macOS's default limit of 256 open files is enough. |
@@ -70,8 +70,10 @@ while every page keeps working: the Overview's "What this panel cannot tell you"
 progress (phase, files done, rows so far, an ETA that settles after the first few files), the
 address page says the same in place of a history, and an event — which the browser shows as a
 notification — marks the start, the finish and a failure. When it finishes the follower starts
-on the spot, so address pages work without a restart. Stopping BlockYard stops the build; there
-is no resume, so the next start begins it again. Three keys on the node entry control it:
+on the spot, so address pages work without a restart. Stopping BlockYard stops the build, and the
+next start resumes it: the files already scanned and the buckets already sorted are kept, and
+only what was not finished is read again (at most about a minute of scanning). Three keys on the
+node entry control it:
 
 | key | meaning |
 |---|---|
@@ -146,9 +148,10 @@ Balances are checked against the node: 40 of 40 sampled addresses equal `scantxo
 satoshi (`node scripts/index-benchmark.js` runs that check and the lookup timings against your
 own build).
 
-**Outbound network access** is needed only for the Markets and Kiosk tabs and for the
-explorer's dollar figures (HTTPS to five exchanges' public APIs). Everything else talks only
-to your node. See [SECURITY.md](SECURITY.md#outbound-connections).
+**Outbound network access**: none, out of the box — everything talks only to your node. The
+Markets and Kiosk tabs and the explorer's dollar figures need the exchange feed (HTTPS to five
+exchanges' public APIs), which is off until you tick **Display settings → Markets & Price → Enable market polling**
+in the browser. See [SECURITY.md](SECURITY.md#outbound-connections).
 
 ## 2. Get the code
 
@@ -240,8 +243,8 @@ real-time explorer data over RPC was a failed idea.
 
 `rpcUser` / `rpcPassword` are still accepted, for a node that authenticates with `rpcauth` rather
 than the cookie file (see [Configuration](CONFIGURATION.md#nodes)). The web UI's node-connection
-form takes no password on purpose -- taking one over an endpoint that is open by default is not
-something to add quietly -- so credentials go in `config/local.json`.
+form takes no password on purpose -- taking one over a web endpoint is not something to add
+quietly -- so credentials go in `config/local.json`.
 
 ##### `bitcoin.conf` settings worth having
 
@@ -284,17 +287,20 @@ npm run check       # every configured node: RPC, credentials, txindex, getblock
 npm start
 ```
 
-Watch the start-up lines. You should see the addresses it listens on, a line per node,
-and — because accounts are off by default — a warning that names who can read the monitor. If
-the node entry names an `addressIndex` directory with no index in it, `address index: building
-… with N workers -- the Overview shows the progress` follows, and the build runs on in the
-background (see [Building the address index](#building-the-address-index)). Then open
-<http://127.0.0.1:21000>.
+Watch the start-up lines. You should see `listening on https://127.0.0.1:21000` (the first start
+makes the monitor its own self-signed certificate under `data/tls/`; the browser warns once per
+address and remembers it), a line per node, and — because accounts are on by default — `created
+the first admin account (admin)` with a generated password **shown once** (set
+`BLOCKYARD_ADMIN_PASSWORD` before the first start to choose it; `blockyard user` changes it
+later). If the node entry names an `addressIndex` directory with no index in it, `address index:
+building … with N workers -- the Overview shows the progress` follows, and the build runs on in
+the background (see [Building the address index](#building-the-address-index)). Then open
+<https://127.0.0.1:21000> and sign in.
 
-Check it from the shell:
+Check it from the shell (`-k`, because the certificate is self-signed):
 
 ```bash
-curl -s http://127.0.0.1:21000/api/health
+curl -sk https://127.0.0.1:21000/api/health
 ```
 
 If a node shows as offline, see [TROUBLESHOOTING.md](TROUBLESHOOTING.md#a-node-shows-offline).
@@ -330,7 +336,8 @@ If a node shows as offline, see [TROUBLESHOOTING.md](TROUBLESHOOTING.md#a-node-s
    ```
 
    Set `User=` / `Group=` to the account from step 1, `WorkingDirectory=` to where the code
-   lives, and replace the `Environment=` lines that name paths with your own (or delete
+   lives, the two `ReadWritePaths=` lines to that directory's `data` and `config` (and add one for
+   your address index directory; the unit makes everything else read-only to the service), and replace the `Environment=` lines that name paths with your own (or delete
    them and keep everything in `config/local.json`). Point `ExecStart` at an absolute Node
    22 binary — `/usr/bin/env node` can resolve to an older system Node under systemd:
 
@@ -356,10 +363,10 @@ Where the monitor listens is a security decision. Set `server.host` in `config/l
 
 | bind | who can connect | typical use |
 |---|---|---|
-| `"127.0.0.1"` | this machine only | reach it with an SSH tunnel: `ssh -L 21000:127.0.0.1:21000 you@host` |
+| `"127.0.0.1"` (the default) | this machine only | reach it with an SSH tunnel: `ssh -L 21000:127.0.0.1:21000 you@host` |
 | `"192.0.2.10"` (a LAN address) | anything that can route to that address | a home or office LAN |
 | `["192.0.2.10", "198.51.100.7"]` | exactly those addresses | LAN plus a VPN such as Tailscale or WireGuard |
-| `"0.0.0.0"` (the default) | every interface | behind a firewall you control |
+| `"0.0.0.0"` | every interface | behind a firewall you control |
 
 Notes:
 
@@ -377,15 +384,17 @@ Notes:
 - `server.allowCidrs` (or `BLOCKYARD_ALLOW_CIDRS=192.0.2.0/24,2001:db8::/32`) makes the
   monitor itself refuse clients outside those networks, as a second line of defence.
 
-## 8. Accounts (optional)
+## 8. Accounts (on by default)
 
-By default anyone who can reach the port reads the monitor as a `viewer` — charts, the
-explorer, the event stream, the read-only RPC console. User administration, the audit trail
-and every node write stay closed.
+Sign-in is required out of the box. The first start with an empty data directory creates an
+`admin` account and prints its password **once** in the log (under systemd: `journalctl -u
+blockyard`). Set your own instead with `BLOCKYARD_ADMIN_PASSWORD` for that first start.
 
-To require sign-in, set `"auth": { "enabled": true }` or `BLOCKYARD_AUTH=1` and restart. The
-first start with an empty data directory creates an `admin` account and prints its password
-**once** in the log. Set your own instead with `BLOCKYARD_ADMIN_PASSWORD` for that first start.
+To open the monitor to readers with no account, set `"auth": { "enabled": false }` or
+`BLOCKYARD_AUTH=0` and restart: anyone who can reach the port then reads it as a `viewer` —
+charts, the explorer, the event stream, the read-only RPC console — while user
+administration, the audit trail and every node write stay closed. The boot log names the
+addresses that leaves readable.
 
 Manage accounts from the Admin page, or from the shell — for example, to reset the admin
 password:
@@ -398,17 +407,35 @@ Roles: `viewer` reads; `operator` may also run node actions that you have enable
 also manages users and reads the audit trail. Node actions are off unless you enable them
 explicitly — see [SECURITY.md](SECURITY.md#node-writes).
 
-## 9. HTTPS (optional)
+## 9. HTTPS (on by default)
 
-Name a certificate and key and every listener serves HTTPS:
+Every listener serves HTTPS out of the box. With no certificate of your own named, the first
+start makes one: a self-signed certificate and key under `<data>/tls/` (`data/tls/cert.pem` and
+`key.pem`, the key readable by the service account only), naming the addresses the monitor is
+reached on — the bound hosts, this machine's addresses and hostname, `localhost`. It is remade
+by itself when it nears expiry (825 days) or stops naming a bound address. Browsers warn once
+per address about a self-signed certificate and then remember it; the start-up log prints its
+fingerprint so you can compare.
+
+To add a name or address (say, a DNS name you gave the machine) or start over:
+
+```bash
+blockyard tls --san monitor.lan.example        # or: node scripts/tls.js --san ...
+blockyard tls --force                          # a fresh key and certificate
+blockyard tls --print > blockyard.crt          # the certificate, for another machine's trust store
+```
+
+To use a certificate of your own instead, name it and every listener serves that:
 
 ```bash
 BLOCKYARD_TLS_CERT=/etc/blockyard/cert.pem BLOCKYARD_TLS_KEY=/etc/blockyard/key.pem npm start
 ```
 
-or in `config/local.json`: `"server": { "tls": { "cert": "...", "key": "..." } }`.
+or in `config/local.json`: `"server": { "tls": { "cert": "...", "key": "..." } }`. To serve plain
+HTTP — behind a reverse proxy that terminates TLS (section 10) — set `BLOCKYARD_TLS=0` or
+`"server": { "tls": { "enabled": false } }`.
 
-A self-signed certificate is fine on a LAN (expect one browser warning per address):
+If you would rather make the certificate with openssl yourself:
 
 ```bash
 sudo mkdir -p /etc/blockyard
@@ -424,8 +451,8 @@ rather than silently serving plain HTTP.
 
 ## 10. Behind a reverse proxy (optional)
 
-If you already run nginx, Caddy or similar, bind the monitor to `127.0.0.1` and let the proxy
-terminate TLS. The live stream (`/api/stream`) is Server-Sent Events, so the proxy must not
+If you already run nginx, Caddy or similar, bind the monitor to `127.0.0.1`, set
+`BLOCKYARD_TLS=0` so it speaks plain HTTP to the proxy, and let the proxy terminate TLS. The live stream (`/api/stream`) is Server-Sent Events, so the proxy must not
 buffer it. An nginx example:
 
 ```nginx
@@ -468,8 +495,41 @@ Your `config/local.json` and `data/` directory are untouched by updates. Read
 up new front-end files on the next page load; the header shows a notice when the page you
 have open is older than the server.
 
+**Updating from 0.0.9.** The defaults hardened in 0.1.0, and a `config/local.json` written by
+0.0.9's installer does not name them, so the first start after the update behaves like a fresh
+install in three ways:
+
+- **HTTPS.** The monitor makes itself a self-signed certificate under `data/tls/` and serves
+  HTTPS on the same port; `http://…:21000` stops answering. Open `https://`, accept the
+  certificate once. Behind your own reverse proxy, set `BLOCKYARD_TLS=0` (§10).
+- **Sign-in.** Accounts are on. The first start creates the `admin` account and prints its
+  password **once** in the log (`journalctl -u blockyard` under systemd); set
+  `BLOCKYARD_ADMIN_PASSWORD` before that start to choose it. To keep the monitor open as before,
+  put `"auth": { "enabled": false }` in `config/local.json` or start with `BLOCKYARD_AUTH=0`.
+- **This machine only.** With no `server.host` in the config the bind is `127.0.0.1`. A
+  0.0.9 config written by the installer names the host it chose, so a LAN bind stays; if yours
+  does not, add `BLOCKYARD_BIND` or `server.hosts` (§7).
+- **Market polling is off** until someone ticks **Display settings → Markets & Price → Enable
+  market polling** — once, for every screen.
+
 ## 12. Uninstalling
 
+BlockYard touches nothing outside its own directories: it reads `bitcoin.conf` and never writes
+it, and it leaves the node as it found it. Removing it is deleting those directories.
+
+**Installed from npm** (`npm install -g blockyard`): stop it, then
+
+```bash
+npm uninstall -g blockyard
+rm -rf ~/.blockyard               # local.json, data/ (history, accounts, the audit trail) and data/index
+```
+
+**A checkout** run with `npm start`: stop it and delete the checkout; `config/` and `data/`,
+the index included, live inside it. If you pointed the index elsewhere at setup time
+(`addressIndex` in `config/local.json`), delete that directory too.
+
+**The systemd service** of section 6:
+
 ```bash
 sudo systemctl disable --now blockyard
 sudo rm /etc/systemd/system/blockyard.service && sudo systemctl daemon-reload
@@ -484,7 +544,7 @@ sudo userdel blockyard
 - [ ] `npm run check` passes: Core 25.0+, `txindex` synced, the block files readable, no pruning
 - [ ] the index directory has ~125 GB free and is writable by the service account
 - [ ] the start-up log shows the addresses you intended, and no node offline
-- [ ] you have decided who can reach the port (bind, firewall, `allowCidrs`)
-- [ ] accounts on if the port is reachable by people who should not see your node
-- [ ] HTTPS on, or a proxy / tunnel in front, if the network is not trusted
-- [ ] `BLOCKYARD_MARKETS=0` if the machine must make no outbound connections
+- [ ] you have decided who can reach the port: it binds `127.0.0.1` until you say otherwise (bind, firewall, `allowCidrs`)
+- [ ] accounts stay on (the default) if the port is reachable by people who should not see your node; you have the admin password from the first start
+- [ ] HTTPS is on by default with the monitor's own certificate; a certificate of your own, or a proxy / tunnel in front, if you want no browser warning
+- [ ] **Enable market polling** ticked in Display settings if you want the Markets and Kiosk tabs (off by default); `BLOCKYARD_MARKETS=0` on machines that must make no outbound connections at all

package/docs/MEASUREMENTS.md

@@ -1252,3 +1252,150 @@ showing STALLED. Block intervals are close to exponential with a 10-minute mean,
 minutes or more has probability e^-4, about 1.8% -- once in fifty blocks, a few times a day. Stalled
 now means a connected peer reports a higher tip (`getpeerinfo` `synced_headers`); peers agreeing on
 the tip is a long gap and synced; no peer height at all waits two hours.
+
+## 32. The DOOM Diversion's emulated PC (2026-09-15)
+
+Not the node: the i386 and the PC in `public/js/x86.js` and `dospc.js` running the shareware
+`DOOM.EXE` v1.9 (the Diversion). Taken on this box -- AMD Ryzen 9 9950X3D, Node v22.23.2, Chromium
+152 (snap, headless). Reproduce the headless figures with `node scripts/dos-bench.js doom`.
+
+**Speed of the interpreter**, 400 M instructions of DOOM's title and demos on a clock of 30 M
+instructions to the virtual second:
+
+| build | instructions a second |
+|---|---|
+| first cut: unsigned values (`>>> 0`), flag operands in closure variables, a try/catch per instruction | 66-68 M |
+| every value an int32, lazy flags in an `Int32Array`, one try/catch around the loop, 32-bit fast paths | 95 M |
+| the same with the Sound Blaster and OPL3 attached, synthesising at 44.1 kHz per call of `tick` | 73 M |
+| the OPL's per-register work hoisted out of the sample loop | 82 M |
+| `tick` working in batches of at least 128 frames (it had been called every 2,000 instructions: a sample or two each) | **92 M** |
+
+The try/catch alone was 14% of the profile, and the collector 1.5% from doubles boxed in closure
+variables; the rewrite was checked instruction by instruction against the first cut for 40 M
+instructions (identical except the start-up's environment read, which the first cut got wrong).
+
+**In the browser**, the machine in a worker, sound on: **94-110 M instructions a second, 34-37
+frames a second** -- DOOM's own cap is 35. The game needs about a million instructions a frame of
+real work; the rest of each tic it spends in its own busy wait for the timer. The page's CSP forbids
+eval, so a JIT was never an option; a slower machine than this one has roughly a factor of two in
+hand before DOOM drops below 35.
+
+**Start-up**: graphics mode after 8.0 M instructions without a sound card, 17.0 M with one (the
+DMX driver probes the DSP and the OPL); 20 pages flipped by 31 M.
+
+**Correctness of the CPU, measured against the host's own**: a differential fuzzer ran random
+instructions natively (a C harness in 64-bit mode, 32-bit operands, register forms) and in `x86.js`,
+comparing all registers and every flag the instruction defines -- ALU rows, immediates, shifts and
+rotates with counts past the width, MUL/IMUL/DIV/IDIV including divide faults, BT/BTS/BTR/BTC,
+BSF/BSR, SHLD/SHRD, MOVZX/MOVSX, SETcc, BSWAP, XADD, CMPXCHG, SAHF/LAHF. Two seeds, 78,565
+instructions, 2,338 divide faults agreed, **zero mismatches**. The harness needs a C compiler, so it
+is not in `npm test`; `test/x86.test.js` keeps a case from each class it covered.
+
+**The music is in tune**: over 10 s of the title music, 178 notes keyed on, 96 of them within
+2.5 cents of equal temperament; the rest spread to +-50 cents, which is DMX's pitch bends.
+
+## 33. Quake on the same PC (2026-09-15)
+
+`QUAKE.EXE` v1.06 (DJGPP, go32 stub) on the emulated PC, this box, Node v22.23.2. Reproduce with
+`node scripts/dos-bench.js quake`.
+
+**Speed**: 77 M instructions a second headless with the Sound Blaster attached, 72-79 in a Chromium
+worker -- lower than DOOM's 90-105 because Quake's code is FPU-heavy (the x87 was 15% of the profile)
+and every memory operand adds a segment base (DJGPP's DS is at its memory block; `ea` was 13%).
+Moving the FPU stack to a Float64Array with typed-array operand conversion and one base addition
+when DS and SS share it took 74 to 76: the interpreter's dispatch is the rest.
+
+**Frame rate**: `+timedemo demo1` on a clock of 74 M instructions to the virtual second -- the
+emulator's own speed -- reported **969 frames in 33.5 seconds, 28.9 fps**, about 2.6 M instructions a
+frame. In the browser, a new game on the start map drew 26 frames a second. Period hardware for
+comparison: a Pentium 90 ran the same demo at 320x200 at roughly that rate.
+
+**Start-up**: graphics mode after 244 M instructions on a 30 M clock (Quake pages its 27 MB heap in
+and times its hardware), twenty screens drawn by 285 M; 2.8 s of wall time headless.
+
+## 34. The decoded-instruction cache, and Quake's view size (2026-09-15)
+
+This box, Node v22.23.2, `node scripts/dos-bench.js doom 400` / `quake 1500` (M instructions a
+second, headless, Sound Blaster attached):
+
+| build | DOOM | Quake |
+|---|---|---|
+| before (the interpreter, §32-33) | 90 | 77 |
+| a closure per decoded instruction | 68 | 69 |
+| int32 decodings in a typed array per page, one switch; a write drops the whole page | 83 | 90 |
+| ...a write clears only the instructions it overlaps (DOOM patches its span drawer each call) | 100 | 90 |
+| ...the FPU decoded too, and the loop keeps the current page between instructions | 107 | 104 |
+| ...no page check after a cached handler | **111** | **108** |
+
+The page-drop row is the one to remember: 217,660 whole-page drops in 300 M instructions of DOOM,
+every one from `mov [eax],ebx` into the constants of its own span routine at 0x12bdaf.
+
+**Quake's view size**, `+viewsize N +timedemo demo1` (969 frames), on a clock set to the emulator's
+speed:
+
+| viewsize | before the cache (76 M clock) | after (105 M clock) |
+|---|---|---|
+| 100 | 29.7 fps | 40.9 fps |
+| 80 (the new default) | 32.5 | 44.7 |
+| 60 | 40.5 | -- |
+
+In a Chromium worker: Quake 99-106 MIPS and 40-42 frames a second in a new game at `viewsize 80`
+(26 before), DOOM 133 MIPS at its 35 fps cap.
+
+**Checked, not assumed**: both games lock-stepped against the uncached interpreter (DOOM 400 M, Quake
+1.5 G instructions; registers and flags compared every 10,000; memory identical at the end), and the
+native fuzzer re-run through `run(1)` over 118k instructions with no mismatch.
+
+## 35. A second pass on the CPU: what paid and what did not (2026-09-15)
+
+Asked for all five of: split the ALU routine, specialise the hot x87 forms, cheaper dispatch, dead
+flags, and a block copy of the frame into video memory. **Method, after the first readings misled:**
+each build against a copy of the previous one (`oracle4`), pinned to one core with `taskset`, best of
+three; unpinned runs on this shared box moved +-5% between identical runs. Quake throughput as M
+instructions a second over its timedemo, and as **frames a second of wall time** over 600 timedemo
+frames -- the second catches work a MIPS figure cannot, such as a `rep movsd` that is one instruction
+however many bytes it moves. DOOM on `-timedemo demo1` only: its normal MIPS depends on how much time
+lands in its cheap wait loop, which a change to the machine's slice size alone moved by 5%.
+
+| build | Quake MIPS | Quake fps (wall) | DOOM timedemo MIPS |
+|---|---|---|---|
+| before (the cache, §34) | 101 | 37.7 | 103 |
+| ALU split per operation + hot x87 forms decoded to their own handlers | 133 | -- | -- |
+| + fused cmp/test+Jcc dispatch and "no flags" forms by flag liveness | 131 | -- | 110 |
+| the same without the look-ahead (fusion and no-flags off) | 133 | -- | 114.5 |
+| + the address formed inline in the loop instead of a call per handler | 141.5 | -- | 112 |
+| + aligned reads/writes inline in the hottest moves | 141 | 52.5 | 115 |
+| the same without the VGA block copy | 141 | 51 (noise) | -- |
+
+**Kept**: the ALU split, the x87 handlers, the inline address and moves -- Quake's frames a second of
+wall time 37.7 -> 52.5 (+40%). **Removed**: the fused branches and the no-flags forms (nothing gained;
+the look-ahead re-ran on every re-decode of DOOM's self-patching drawer), and the block copy (within
+noise: the frame copy is 64,000 bytes against 140 M instructions a second).
+
+The reason inlining mattered: `run()` is one function with 170-odd cases, V8's cumulative inlining
+budget runs out long before the helpers it calls, and every uninlined `eaOf` was a real call.
+
+**In a Chromium worker** (new game, `viewsize 80`): Quake 115-118 MIPS and 39-49 frames a second on
+screen, once the worker looked for a finished frame every 50,000 instructions instead of once per
+10 ms slice (two frame copies inside one slice had been showing as one). DOOM 139 MIPS.
+
+Checked: DOOM 400 M and Quake 1.5 G instructions lock-stepped identical to `oracle4` (memory equal),
+and the native fuzzer through `run(1)`, 78k instructions, no mismatch.
+
+## 36. Wolfenstein 3D in real mode (2026-09-15)
+
+`WOLF3D.EXE` v1.4 (LZEXE-packed, Borland C, real mode) on the emulated PC, this box, Node v22.23.2,
+pinned to one core. It unpacks itself and reaches the sign-on screen in 1.0 s of wall time (60 M
+instructions on a 20 M clock).
+
+**Speed**: in a game, turning on the first map, **65 M instructions a second** headless (twice the same
+reading) and 68-69 in a Chromium worker. Real-mode code runs through the uncached `step()`, so this is
+the plain interpreter's speed; the game needs about **285 k instructions a frame**, so its 70 frames a
+second (the VGA's refresh, which it waits for) take 20 M a second -- a third of what is there, and the
+browser shows 70 frames a second.
+
+**DOOM and Quake unchanged**: best of three against a copy of the previous build (`oracle5`), DOOM
+timedemo 93.3 vs 93.0 M a second, Quake 126.3 vs 127.7. Quake lock-stepped identical for 600 M
+instructions, memory equal. DOOM lock-steps identical to 175 M and then differs, by design: at 173 M it
+copies between VGA pages in write mode 1, which the previous build wrote as plain data, and reads the
+planes back.