modemwars/swiftlink/highRateReport.md

# The high rates: 4800, 9600, 19200, 38400, and a rate mismatch

> **Note on addresses.** This report records a run made before the probe-hardening pass, which
> relocated six internal helpers. Addresses quoted below are the ones those routines had at the
> time of the run. See `ADDRESS_CHANGES.md` for the mapping onto the current source.
>
> **Note on the recommendation: "must not be selected: 38400" has been overturned.** It was written
> from the four wedges in sections 5 and 6, on a build whose NMI handler could be re-entered without
> bound. `wedgeDiagnosis.md` then established that mechanism - 34 nested handler frames decoded off a
> live page 1, three timed stack descents, and the cycle budget behind them - and the driver now
> carries a re-entrancy guard. On that build 38400 is selectable again and did not wedge in seven
> boots, and 9600 and 19200 produce no receive errors and no lost transmit characters at all
> (`portCompatReport.md` sections 3 and 4, `testReport.md` section 11). The measurements below are
> left exactly as they were taken: they are the record of the build that had the fault.

The reason to care about the top of the baud table is not speed.  It is **hardware compatibility**: a
C64 Ultimate's SwiftLink emulation may hand this driver a much faster line than *Modem Wars* was ever
written for, and the question that matters is not how much the driver can carry but whether it
**survives** what it is handed - stays in sync, or degrades and recovers, and never wedges.

Everything here is VICE 3.7.1 (`x64sc`), NTSC, `-acia1mode 1 -acia1base 0xDE00 -acia1irq 1`, on
**2026-08-22**, against a disk built from the current source with `./build.sh` (`checkAbi.py` prints
`ABI CHECK PASSED`).  Both emulators in every pair run at **true C64 speed** - warp is used only for
the loader and switched off through the monitor's `warp` command before the options menu - and each
emulator's own free-running cycle counter is read at both edges of every measurement window to prove
it.  **Every window in this report ran at 100.5% of real time or better on both machines.**

Script: the new `testHighRates.py`, which reuses `testRealtime.py` (the socket null modem, the boot,
the hot-key rate selection, the stopwatch check, the transmitter-deadlock probe) and adds what this
question needs.  Logs: `testLogs/highRate4800.txt`, `highRate9600.txt`, `highRate19200.txt`,
`highRate38400.txt`, `highRate38400run2.txt`, `highRate38400run3.txt`, `highRate38400run4.txt`,
`highRateMismatch.txt`, with per-second byte counts and raw tracepoint output in
`testLogs/highRate.*.samples.txt` / `*.trace.txt` / `*.ring.txt` and screenshots in `shots/hrh*.png`.

---

## The answer, in one table

| Rate | Hot key | Control | Both reached phase 3 | Sampling intervals carrying nothing | Receive-ring overflows | Transmit characters lost | Byte-sync rounds | Outcome |
|---|---|---|---|---|---|---|---|---|
| 4800 | C= + 4 | `$1A` | yes | **none**, 0 of 450 | **0** in 20 s of tracing | 0.8% / 1.5% | ~1.0/s, 98% completed | **healthy** |
| 9600 | C= + 9 | `$1C` | yes | **none**, 0 of 442 | 8 and 41 in 20.6 s | 2.1% / 2.1% | ~1.7/s, 79% completed | **degrades, recovers** |
| 19200 | C= + 0 | `$1E` | yes | **none**, 0 of 450 | 128 and 74 in 20.4 s | 2.2% / 2.3% | ~1.6/s, 76% completed | **degrades, recovers** |
| 38400 | C= + 8 | `$1F` | 3 of 4 boots, briefly | **every interval**, one or both directions, for the whole 170-246 s of every boot | 1259 in 21 s on the stuck machine | - | it stops resyncing | **WEDGES, 4 of 4 boots**, once by crashing the CPU |
| 38400 vs 300 | - | `$1F` / `$15` | yes | **none**, 0 of 474 | **0** | 0.0% / 0.1% | 0.2-0.5/s, completions >= entries | **healthy** - but see section 7 |

**Plain recommendation.**

* **Safe to advertise: 300, 1200, 2400, 4800.**  4800 behaved the way 2400 does after the transmitter
  fix: continuous traffic in both directions every second, not one receive-ring overflow, not one bad
  character, the ring never more than a third full.
* **Document as degrading but usable: 9600 and 19200.**  Both keep the link alive and both keep the
  game moving.  Both also spend a visible part of every second re-synchronising: the 20-byte receive
  ring overflows, `linkErrorCount` forces a byte-sync round, the round completes, the packet layer
  carries on.  Nothing is lost that the ARQ layer does not recover.  What they do **not** buy is
  throughput - the extra line time goes into resync floods, not into frames.
* **Must not be selected: 38400.**  *(Overturned - see the note at the top of this file.)*  Four
  consecutive boots, four wedges, every one inside the first
  minute after the link came up, none of which recovered in the 170 to 246 seconds each was then
  watched for.  On the fourth boot VICE reported `*** Main CPU: JAM at $0007` on one machine - the
  6502 executing an illegal opcode in zero page.  It is not the old 2400-baud transmitter deadlock, and
  the driver's own self-heal cannot reach it.  Sections 5 and 6 have the stuck bytes.
* **The rate table itself is fine.**  Every hot key programmed the chip correctly, first press, every
  time: `$1A`, `$1C`, `$1E` and `$1F` all appeared in `$DE03` with the matching `baudIndex`.  38400
  fails at the protocol, not at the register.

---

## 1. What actually limits this driver, arithmetically

The raw receive ring at `$E430` holds **20 characters**, only the once-per-frame link tick drains it,
and `awaitWholePacket` `$E9D9` refuses to copy a packet body out until the whole payload **and** its
check byte are resident - up to 17 bytes - so the genuine headroom is about three bytes.  There is no
RTS throttling anywhere in the driver.  So the number that decides everything is how many characters
can arrive between two drains:

| Rate | Characters/s | Characters per video frame | A full 22-byte transmit ring emptied onto the wire takes |
|---|---:|---:|---:|
| 300 | 30 | 0.50 | 733 ms = 43.9 frames |
| 1200 | 120 | 2.01 | 183 ms = 11.0 frames |
| 2400 | 240 | 4.01 | 91.7 ms = 5.5 frames |
| 4800 | 480 | 8.02 | 45.8 ms = 2.7 frames |
| 9600 | 960 | 16.05 | 22.9 ms = 1.4 frames |
| 19200 | 1920 | 32.09 | 11.5 ms = 0.69 frames |
| 38400 | 3840 | 64.19 | 5.7 ms = 0.34 frames |

Two figures in the existing documents are wrong and are worth correcting here, because the size of
the problem depends on them.  The brief for this work said a video frame is "roughly 640 character
times" at 38400 and `spec_uart.md` hazard 2 says "about 200"; at 3840 characters a second and 59.826
frames a second it is **64.2**.  The ring is therefore about three times too small at 38400, not
thirty times - which is why 19200, at 32 characters a frame, still works.

The second column is the one that decides where the overflows start.  The frame layer fills the
22-byte **transmit** ring and the NMI empties it at line rate, so a peer's ARQ frame arrives as a
burst.  At 300 baud that burst is spread over 44 video frames and cannot overflow anything.  At 9600
it lands inside one and a half frames, at 19200 inside one, and at 38400 three of them can land
inside a single frame.

**Relay direction, and how machines are told apart.**  The null modem counts bytes per connection;
`conn0` is whichever emulator opened its serial line first, which is machine A (the answer side, the
one the script drives first).  That is an inference, the same one every earlier report in this
directory makes, and where it matters below it is corroborated by something machine-specific - each
emulator's own log, or its own monitor socket, or a rate that only one of the two was set to.

---

## 2. 4800 baud: healthy

Both machines took **C= + 4** at the "PRESS A OR O" prompt; `baudIndex` `$E055` went to 9 and the
ACIA control register `$DE03` to `$1A` on both, and both reached `connectionPhase` 3.  Four windows,
246.5 seconds of measured link time.

| Window | Wall | A speed | B speed | A -> B | B -> A | resync floods | `$55` lead bytes |
|---|---:|---:|---:|---|---|---|---|
| clean 1 | 75.19 s | 101.0% | 100.6% | 681 B = **9.06 B/s** | 687 B = **9.14 B/s** | 0 / 0 | 255 / 258 |
| clean 2 | 75.15 s | 100.9% | 100.5% | 3418 B = **45.48 B/s** | 3053 B = **40.62 B/s** | 44 / 23 | 629 / 761 |
| sync tracepoints | 76.06 s | 100.9% | 100.5% | 2764 B = 36.34 B/s | 2678 B = 35.21 B/s | 32 / 36 | 622 / 659 |
| error tracepoints | 20.06 s | 103.5% | 102.0% | 866 B = 43.18 B/s | 996 B = 49.66 B/s | 8 / 8 | 140 / 165 |

* **Not one of the 450 sampling intervals - 225 in each direction - carried zero bytes.**  The
  per-second buckets ran 6 to 12 B/s in the quiet window and 12 to 175 B/s in the busy one.
* **Not one receive error of any kind.**  The `countLinkError` `$E403` tracepoint recorded **zero**
  hits on either machine in the 20-second instrumented window, and so did the conditional ring-full
  tracepoint `trace exec $e505 if x > $13`.
* **The resyncs that do happen are the packet layer's own, not the UART's.**  With no `$E403` hits at
  all, the 44 and 23 byte-sync floods in window 2 came from `receivePacket`'s `unwindAndResync` paths
  (two `$00` in a row, an invalid length code, a bad check byte), not from a dropped character.
* **They complete.**  Tracepoints on `beginByteSyncPhase` `$E805` and on the instruction that
  finishes a sync, `sta ackPending` `$E855`, counted 78 entries / 76 completions on A and 80 / 78 on
  B in 76 seconds.
* **The ring stays nearly empty.**  `uartRxCount` `$E42D`, sampled 24 times per machine with the
  emulator stopped: A min 0, max 7, mean 1.1; B min 0, max 5, mean 0.8.  Never at the 20-byte limit.
* `connectionPhase` `$E040` was seen at both 2 and 3 on both machines, `isLinkActive` `$E03B` = `$01`
  at every edge, and `txCharActive` `$E5BB` / `aciaCommandShadow` `$E5BE` were only ever the two
  self-consistent pairs `$00`/`$09` and `$01`/`$05`.  The deadlock probe never fired.

## 3. 9600 and 19200: they degrade, and they recover

Same method, one boot each, four windows each.  These two are reported together because they differ
only in degree.

### 9600 baud (`$DE03` = `$1C`, `baudIndex` 12)

| Window | Wall | A -> B | B -> A | resync floods | `$55` | per-second range |
|---|---:|---|---|---|---|---|
| clean 1 | 75.18 s | 3122 B = **41.53 B/s** | 2734 B = **36.37 B/s** | 28 / 28 | 652 / 617 | 6-345 / 6-276 |
| clean 2 | 75.23 s | 3647 B = **48.48 B/s** | 3985 B = **52.97 B/s** | 32 / 43 | 700 / 705 | 12-200 / 12-275 |
| sync tracepoints | 75.53 s | 4313 B = 57.11 B/s | 4214 B = 55.79 B/s | 31 / 59 | 810 / 730 | 14-259 / 14-228 |
| error tracepoints | 20.61 s | 1017 B = 49.35 B/s | 884 B = 42.90 B/s | 9 / 9 | 223 / 164 | 12-68 / 13-72 |

### 19200 baud (`$DE03` = `$1E`, `baudIndex` 15)

| Window | Wall | A -> B | B -> A | resync floods | `$55` | per-second range |
|---|---:|---|---|---|---|---|
| clean 1 | 75.13 s | 4702 B = **62.59 B/s** | 5377 B = **71.57 B/s** | 72 / 47 | 717 / 980 | 12-306 / 14-377 |
| clean 2 | 75.14 s | 4885 B = **65.01 B/s** | 4406 B = **58.64 B/s** | 58 / 50 | 770 / 808 | 14-371 / 12-300 |
| sync tracepoints | 75.78 s | 4623 B = 61.00 B/s | 4014 B = 52.97 B/s | 66 / 30 | 749 / 659 | 12-237 / 12-142 |
| error tracepoints | 20.35 s | 1188 B = 58.38 B/s | 1292 B = 63.49 B/s | 21 / 10 | 207 / 312 | 18-170 / 18-217 |

**The three things that decide the verdict, at both rates:**

* **No sampling interval carried nothing.**  0 of 442 at 9600 and 0 of 450 at 19200, counting both
  directions, including inside the windows where the ring was overflowing.
* **The errors are real, and every one is a ring overflow.**  In the instrumented windows the
  unconditional `$E403` tracepoint and the conditional `$E505 if x > $13` one returned **identical
  counts**: 8 and 8 on A, 41 and 41 on B at 9600; 128 and 128 on A, 74 and 74 on B at 19200.  Not one
  character was rejected for a bad status.  That is the 20-byte ring being outrun by a burst, exactly
  as `spec_uart.md` hazard 2 predicts, and it is the same signature `rate1200Report.md` found at 1200
  - there are simply far more of them.
* **Every degradation was followed by a recovery.**  `$E805` / `$E855`: 124 entries / 101 completions
  on A and 128 / 100 on B at 9600; 100 / 87 on A and 135 / 91 on B at 19200 - roughly 1.3 to 1.8
  byte-sync rounds a second, two thirds to seven eighths of which reached `sta ackPending` and went
  back to the packet phase inside the same window (81% and 78% at 9600, 87% and 67% at 19200).  (A round that does not reach `$E855` is not a
  loss; the next one starts immediately, and `$E855` under-counts anyway, because `restartByteSync`
  `$E80F` re-enters a sync without passing `$E805`.)  `connectionPhase` was found at both 2 and 3 on
  both machines, and `uartRxCount` sampled with the emulator stopped never once read the 20-byte
  limit: A max 14 / B max 4 at 9600, A max 10 / B max 4 at 19200.

**And they buy nothing.**  The `$55` frame-lead counts, a floor on how many ARQ frames crossed the
wire, are 629-761 per window at 4800, 617-705 at 9600 and 717-980 at 19200.  The *bytes* on the wire
climb from 45 B/s to 65 B/s as the rate goes up, and what climbs with them is the `$00` byte-sync
flood.  Counting only the three 75-second windows of each run, so that the lengths are comparable:
0 to 44 floods per window at 4800, 28 to 59 at 9600, 30 to 72 at 19200.  Above 4800 the extra line
rate is spent re-synchronising, not playing.

## 4. The other degradation: the driver overwrites its own outgoing characters

VICE logs `Acia1: ACIA: data register written although data has not been sent yet.` every time the
data register is written before the previous character has left - one transmitted character lost
each time, on emulation and on a real 6551 alike.  Each emulator writes its own log, so the loss
counts below belong to a named machine with certainty; the denominators come from the relay and so
inherit the `conn0` = A inference of section 1.  `realtimeReport.md` saw a handful of these at 2400;
they scale hard with rate:

| Rate | A lost | of offered | B lost | of offered |
|---|---:|---|---:|---|
| 4800 | 132 | 16207 = **0.8%** | 226 | 14689 = **1.5%** |
| 9600 | 387 | 18829 = **2.1%** | 403 | 19054 = **2.1%** |
| 19200 | 542 | 24165 = **2.2%** | 528 | 22600 = **2.3%** |
| 38400 vs 300 | 1 | 14769 = 0.0% | 6 | 9719 = 0.1% |

(The 38400/38400 boots produced 0 to 52 apiece, but they went silent within a minute, so their totals
mean nothing.)  Every one of these is a byte the peer never sees, so it is a checksum failure and a
retransmit at the far end - which is a large part of why the resync rate in section 3 climbs the way
it does.  **How the driver comes to write a busy data register was not traced**; the documented
`commNmiHandler` re-entrancy race is the obvious suspect and nothing measured here confirms it.

## 5. 38400 baud: it wedges, four times out of four

**Four boots, four wedges, no recoveries.**  Every one happened within about a minute of the link
coming up - before the first 75-second window opened - and none showed any sign of coming back
during the 170 to 246 seconds of measurement that followed.  The four are not identical, which is
itself worth recording: this is not one reproducible bug with one signature.

| Boot | Both reached phase 3? | A -> B, per window | B -> A, per window | How it ended up |
|---|---|---|---|---|
| 1 `h384` | no (`{'A': 2, 'B': 2}` after 180 s) | 998 / 1000 / 998 / 272 B, all `$00`/`$FF`, **no `$55` at all** | **0 / 0 / 0 / 0** | A stuck in byte sync; B's game back on the plain OPTIONS menu, its ring full at 20/20 |
| 2 `h384b` | yes | **0 / 0 / 0 / 0** | **0 / 0 / 0 / 0** | both frozen in phase 3, both rings full at 20/20, total silence both ways for 245 s |
| 3 `h384c` | yes | 4494 / 4495 / 4495 / 1259 B, **every byte `$00`**, 59.83 B/s = exactly one byte per video frame | **0 / 0 / 0 / 0** | A flooding byte sync for ever; B frozen in phase 3 on "OPPONENT PICKING GAME/MAP." |
| 4 `h384d` | yes | **0 / 0 / 0** | 1000 / 1000 / 266 B of `$00`/`$FF` at 13.3 B/s | **A's CPU jammed**; B alone in byte sync for ever |

Boot 3's error window is the clearest measurement of what the line does to a stuck machine: in 20.4
seconds machine B's receiver counted **1259** rejected characters and the conditional tracepoint says
**1259** of them were the 20-byte ring being full.  `linkErrorCount` `$E047` is useless as a total
here because it is one byte that simply wraps - across boot 3's four window edges it read 208, 21,
94, 206.

## 6. The stuck bytes

`realtimeReport.md` pinned the 2400-baud fault to one byte: `txCharActive` `$E5BB` = `$01` while
`aciaCommandShadow` `$E5BE` said the transmit interrupt was off.  **This is not that fault.**  In
every 38400 wedge those two bytes were self-consistent - `$00` / `$09`, "idle, nothing in the chip" -
`testRealtime.isTxDeadlocked` reported `False` at every edge, and the repair probe that would have
written `$00` over `$E5BB` never ran.  The driver's own `healStuckTransmitter`, added for the 2400
fault, has nothing to heal here.

### 6.1 Boot 3: `uartPendingCount` out of range

Machine B, read through the monitor with the emulator stopped, six times over six seconds, every
reading identical, and unchanged across four windows spanning 245 seconds:

| Byte | Value | What it means |
|---|---|---|
| `uartPendingCount` `$E0A5` | **`$FF`** | 255 characters "queued for the UART that have not finished transmitting" |
| `uartTxCount` `$E414` | `$00` | ...while the 22-byte transmit ring is **empty** |
| `uartRxCount` `$E42D` | **`$14`** = 20 | the receive ring is full, and stays full |
| `uartRxReadIndex` / `uartRxWriteIndex` `$E42E`/`$E42F` | `$06` / `$0D` | frozen - nothing pushed, nothing popped |
| `connectionPhase` `$E040` | `3` | frozen in the packet phase |
| `isLinkActive` `$E03B` | `$01` | the link is still "up" |
| `txCharActive` `$E5BB` / `aciaCommandShadow` `$E5BE` | `$00` / `$09` | self-consistent: not the 2400 deadlock |
| `nmiSuspendRequest`/`nmiSuspendAck` `$E039`/`$E03A` | `$00` / `$00` | the disk-load suspend handshake is **not** stuck |
| `$DE03` / `$DE02` | `$1F` / `$09` | the 6551 is correctly programmed at 38400, receiver interrupt on |
| `$0BA5` | `$00` | still a modem game, not switched to solo |
| `$01` | `$35` | I/O banked in - the module is reachable |
| PC | wanders (`$41C5`, `$C4EF`, `$C4F6`) | the CPU is running game code, not spinning in the driver |

**`uartPendingCount` `$E0A5` = `$FF` with an empty transmit ring is the byte that is stuck**, and it
is exactly the failure `spec_uart.md` hazard 1 warns about: *"make sure it can reach 0.  If it never
reaches 0, `serviceLinkTick $E76E` never clears `$E0A4`/`$E0A6`, `sendPacketFsm $E26E` never
completes an exchange, and the game locks in lock-step forever."*  Machine B's screen agrees - it
sits on "OPPONENT PICKING GAME/MAP.", waiting for a peer that can never satisfy it.  Boot 2 shows the
same byte out of range on both machines at once, `$39` on A and `$79` on B, both rings full, both
ends silent.

The driver has a mechanism meant to prevent exactly this.  `startNextTxChar` `$E607` resynchronises
the count whenever it runs with the ring dry:

```
        lda     uartTxCount             ; E60C  is there really something in the ring?
        bne     L_E616                  ; E60F  yes - decide whether it may go out
        sta     uartPendingCount        ; E611  the ring is dry: A = 0 resynchronises the count
```

and the once-per-frame `$E00C` service falls into it from `$E604` on every raster IRQ the link is up.
On the wedged machine the ring **is** dry and the count is **not** zero, and it stayed that way for
245 seconds - so that resynchronisation was not running, which means the game above had stopped
calling `$E00C`.  Which of the two stopped first was not determined.

### 6.2 Boot 4: the CPU jammed

Machine A, six readings over six seconds, then two more after the repair probe - every one identical:

```
  ADDR A  X  Y  SP 00 01 NV-BDIZC
.;0007 00 01 00 4a 5e 15 00110100
```

and its own emulator log says so outright:

```
***    Main CPU: JAM at $0007
```

The program counter is in **zero page**, it does not move between samples while the cycle counter
advances by 1.38 million, and the two processor-port bytes have been overwritten: `$00` (the data
direction register) reads `$5E` instead of `$2F` and `$01` reads `$15`.  None of the other fifteen
emulator logs in this report records a JAM.

The rest of that machine at the same moment:

| Byte | Value |
|---|---|
| `uartRxCount` `$E42D`, read/write index | `$14` = 20 (full), `$10` / `$10`, frozen |
| `uartTxCount` `$E414` | `$00` - transmit ring empty |
| `uartPendingCount` `$E0A5` | `$00` |
| `$DE01` status / `$DE02` command / `$DE03` control | `$9C` / **`$05`** / `$1F` |
| `aciaCommandShadow` `$E5BE` / `txCharActive` `$E5BB` | **`$09`** / `$00` |
| `$E039` / `$E03A` | `$00` / `$00` |

The line worth staring at is the command register.  **The chip says `$05` - the transmit interrupt is
armed - while the driver's shadow says `$09`, transmit interrupt off, and `txCharActive` says nothing
of ours is in the chip.**  Status `$9C` has bit 7 (IRQ), bit 4 (TDRE) and bit 3 (RDRF) set.  A 6551
with the transmit interrupt enabled and TDRE true asserts `/IRQ` again as soon as the status read
releases it, and this driver's NMI is the only thing that reads that status.  That the CPU ended up
executing zero page with its bank register smashed is consistent with runaway NMI re-entrancy - the
race the source documents at `commNmiHandler` - but **nothing here measures the path from one to the
other**, and this shape occurred once in four boots.

### 6.3 The repair probe: nothing in the driver brings it back

`realtimeReport.md` proved its diagnosis of the 2400 deadlock by writing a single `$00` over `$E5BB`
from the monitor and watching the machine come back to life.  The same probe was run here, on boot 4:
`$00` written over `uartPendingCount` `$E0A5`, twenty seconds observed, then `$00` over `txCharActive`
`$E5BB` as well and another twenty seconds.

```
  20 s after clearing uartPendingCount $E0A5: conn0 0 bytes, conn1 288 bytes
  20 s after clearing txCharActive $E5BB too: conn0 0 bytes, conn1 294 bytes
```

`conn1` is the machine that was still talking; 288 and 294 bytes in twenty seconds is the 13.3 B/s it
was already producing, unchanged.  `conn0`, the wedged machine, produced **nothing** either time.
That is the honest result and it is a negative one: on this boot the wedged CPU had jammed, and no
value written into any driver byte can restart a jammed 6502, so the probe could not have worked.
**The boot-3 shape - `uartPendingCount` = `$FF` on a machine whose CPU is still running - is the one
worth probing, and it has not been.**  That run predates the probe, and the shape did not recur in
the boot that had it.

## 7. The rate mismatch: 38400 against 300

One machine given **C= + 8**, the other left at the disk default of 300, a link opened between them,
245.8 seconds measured.  Confirmed at every window edge: `$DE03` = `$1F` on A and `$15` on B,
`baudIndex` 18 and 0.

| Window | Wall | A (38400) -> B | B (300) -> A | overflows | `$55` | resync floods |
|---|---:|---|---|---|---|---|
| clean 1 | 75.18 s | 2274 B = **30.25 B/s** | 2226 B = **29.61 B/s** | 0 | 950 / 738 | 0 / 0 |
| clean 2 | 75.21 s | 2335 B = **31.05 B/s** | 2160 B = **28.72 B/s** | 0 | 787 / 834 | 0 / 1 |
| sync tracepoints | 75.34 s | 2701 B = 35.85 B/s | 1900 B = 25.22 B/s | 0 | 824 / 502 | 14 / 0 |
| error tracepoints | 20.04 s | 750 B = 37.43 B/s | 590 B = 29.45 B/s | **0** | 299 / 62 | 0 / 0 |

**Both ends reached `connectionPhase` 3, not one of the 474 sampling intervals carried nothing,
there was not a single receive-ring overflow or bad character at either end, and neither machine
wedged.**  It is
the healthiest run in this whole report.  `uartRxCount` sampled 24 times per machine read max 0 on
the fast side and max 2 on the slow side.  The byte-sync tracepoints counted 12 entries / 13
completions on A and 35 / 35 on B - the lowest resync rate of any pair measured here.  (Completions can exceed
entries because `restartByteSync` `$E80F` re-enters a sync without passing `$E805`.)

Two things explain that, and the second is why the result must be read carefully.

* **The pair simply ran at the slower of the two rates.**  The slow side is pinned at 28.7-29.6 B/s,
  which is 300 baud's 8N1 ceiling to within a byte, and the fast side tracks it at 30-37 B/s.  The
  fast side never actually floods, because the packet layer is lock-step - it will not send the next
  thing until the previous exchange completes, so the peer's rate paces it.  That is genuine
  backpressure, and it is worth knowing that the ARQ layer throttles a fast end for free.
* **VICE's ACIA is byte level.**  It paces whole characters at whatever rate the control register
  asks for but does not shift them bit by bit, so two ends set to different rates do **not** garble
  each other here.  On real hardware a 300-baud receiver sampling a 38400-baud line would raise
  framing and overrun errors on nearly every character; every one of those goes through
  `reportLinkError` `$E3BC` into `countLinkError` `$E403`, and a non-zero `linkErrorCount` makes
  `runLinkStateMachine` restart byte sync whatever phase it was in.  The symptom on hardware would be
  the one `README.md` section 4 already describes: a link stuck in phase 2 for ever, border red,
  never green.

So the honest statement is: **on this rig a rate mismatch does not wedge either end and does not even
hurt - it degrades to the slower rate and keeps playing.**  What it cannot tell you is whether a real
38400-baud line into a real 300-baud receiver wedges, because the error storm that would drive it
cannot be produced here.  What it does establish is that the slow side survives being handed a peer
whose timing is nothing like its own, and that neither state machine falls over on the mismatch
itself.

For the Ultimate specifically, that splits the worry in two.  If the device honours the control
register - as VICE and a real SwiftLink do - the two ends agree and this test says nothing bad
happens.  If it ignores the baud bits and runs at its own default, the failure mode is the
garbage-on-the-line case above, which this rig cannot reproduce; the mitigation is the same either
way, and it is the recommendation at the top: do not offer 38400 at all, and treat 9600 and 19200 as
degraded modes.

---

## 8. What went wrong in the rig, and what it cost

* **Two runs were lost to the module-residency trap `rate1200Report.md` section 6 documented**, and
  it is worth repeating because it bit again.  `testTwoMachines.answerModemPrompts` uses "`$E5BE` is
  non-zero" as its "the link is open" test and `testRealtime.selectRate` uses "`$E013/$E014` reads
  `B7 0D`" as its "the module is resident" test, and while the 1541 is still fetching track 34 at
  true C64 speed, `$E000-$EFFF` still holds the previous overlay.  The first 19200 and 38400 attempts
  read `$E5BB-$E5BE` = `E8 84 18 AC` on machine A and took `$AC` for an open link; that machine then
  never selected its rate and never opened a link at all.  Both runs were killed, their emulators and
  Xvfb displays cleaned up by hand, and `testHighRates.moduleResident` now waits for all sixteen
  bytes of the `$E000` jump table first - which is what `test1200AutoBaud.waitForModule` already did.
  Neither lost run is used for anything above.
* **4800 and 9600 were measured with two emulator pairs on the box at once**, as were 38400 boot 2
  and the mismatch; the rest ran alone.  This is recorded because it is the sort of thing that
  invalidates a real-time measurement - but it did not: every window in the report, parallel or not,
  reports both machines at 100.5% of real time or better against their own cycle counters.  The
  residency failures above came from the *fixed sleeps* in the boot sequence being too short when the
  host was loaded, not from the measurement windows.
* **The instrumented windows are not free, and are kept separate for that reason.**  A clean window
  carries no tracepoints at all, so its byte counts are the honest throughput; the `$E805`/`$E855`
  window and the short `$E403`/`$E505` window carry theirs.  The error windows consistently read
  102-103.5% of real time rather than 100.5-101%, which is pause-and-resume overhead landing inside a
  shorter window, not the emulator running fast.
* **`$DE03` sometimes reads `$00` and `$DE01` `$FF` on a machine that is running perfectly well.**
  That is not the chip being reprogrammed; it is the monitor reading through a CPU that happens to
  have the I/O area banked out at that instant - `readFilmByte`, `writeFilmByte` and `copyPageUnderIo`
  set `$01 = $34` for up to 2600 cycles at a time.  Two of the four 38400 boots caught a machine that
  way at every window edge, which briefly looked like a driver fault and is not one.  Any future test
  that reads the cartridge page through the monitor should read `$01` alongside it; `wedgeDump` does.

## 9. What this does not show

* **VICE, not hardware.**  No physical SwiftLink, no real cable, and above all no C64 Ultimate - the
  device this whole exercise is about is one this report has never touched.
* **VICE's ACIA is byte level**, so no framing or parity error can occur on this rig at all.  "Every
  error was a ring overflow" is a statement about this emulation; on a real line the same tracepoints
  would be expected to show bad characters too, and section 7 is limited by this more than anything
  else here.
* **One boot per rate for 4800, 9600 and 19200.**  245 seconds each is enough to say the link keeps
  moving and recovers, and not enough to say it always will.  38400 got four boots because it failed.
* **The 38400 wedge is characterised, not explained.**  What is established is which bytes are stuck
  at what values in two of the four shapes, that the driver's own `uartPendingCount` resynchronisation
  is not running while they are, that one boot ended in a CPU JAM, and that the 2400-baud repair does
  not apply.  How `uartPendingCount` leaves the range the layers above wait on was not traced - `$FF`
  is what a `dec uartPendingCount` produces from zero and the NMI has such a decrement at `$E6C9`, but
  nothing measured connects the two.  Nor was the path from `$DE02` = `$05` against a `$09` shadow to
  a jammed CPU traced.  Both need the NMI instrumented, which stops the emulator and destroys the
  timing being measured.
* **The `uartPendingCount` repair probe has not been run against the shape it was written for.**  See
  section 6.3.
* **No stock user-port peer, and no complete game.**  As in every earlier report, both machines are
  SwiftLink builds, and they reach the GAME TYPE menu and stay there.
* **Nothing was fixed.**  This report characterises; no driver source file was changed, and
  `checkAbi.py` passes on the image every run above was made against.

## 10. Files

| File | What it is |
|---|---|
| `testHighRates.py` | the test: per-machine rate selection, clean and instrumented windows, `uartRxCount` sampling, the wedge dump and the `uartPendingCount` probe |
| `testLogs/highRate4800.txt`, `highRate9600.txt`, `highRate19200.txt` | the three rates above 2400 that survive |
| `testLogs/highRate38400.txt`, `...run2.txt`, `...run3.txt`, `...run4.txt` | the four 38400 boots, in the order of section 5 |
| `testLogs/highRateMismatch.txt` | 38400 on one machine, 300 on the other |
| `testLogs/highRate.*.samples.txt` | per-second byte counts, both directions, every window |
| `testLogs/highRate.*.trace.txt` | raw tracepoint output, with the cycle counter that attributes a hit to a machine |
| `testLogs/highRate.*.ring.txt` | the `uartRxCount` / phase / transmitter samples behind sections 2, 3 and 5 |
| `shots/hrh*.png` | the menu, the linked pair and the end of every window, for each run |