modemwars/swiftlink/rate1200Report.md

1200 baud: two machines in real time, and the CONNECT 1200 auto-baud path

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.

1200 is the rate most likely to matter in practice. It is the other speed the stock user-port module can produce, so it is the only place besides 300 where a SwiftLink player and an unmodified user-port player can meet, and it is the rate a real Hayes modem's CONNECT 1200 result code puts the driver on by itself. Until now it had never been driven at all: testReport.md records that the only control-register values the module had ever been seen to write were $1E (the probe), $15 (300) and $18 (2400).

Everything below 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 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 their own cycle counters are read at every window edge to prove it.

Short answer:

• 1200 baud works, in both directions, on both machines, for the whole of six 75-second windows over three boots. 452 seconds of measured link time, 13121 bytes one way and 12109 the other, and not one second in either direction carried zero bytes.
• The transmitter never parked in the old deadlock state. Thirty state readings at the window edges: txCharActive $E5BB and aciaCommandShadow $E5BE were only ever seen as the two self-consistent pairs, $00/$09 (idle) and $01/$05 (a byte of ours in the chip). The pair that defined the fault - $E5BB set while $E5BE bit 2 is clear - did not occur once, and the script's deadlock probe never fired.
• 1200 is the first rate at which the 20-byte receive ring has been seen to overflow. Thirty-two overflows across the six windows. Every one of them was a ring overflow, not a bad character - a conditional tracepoint proves that for the nineteen in the four windows it was live in, and the other thirteen carry the same fingerprint - and every one of them was on the same machine. The link resynchronised and carried on each time; it never wedged, and connectionPhase was back at 2 or 3 at every edge with isLinkActive $E03B = $01.
• The auto-baud path really does select 1200. A fake Hayes modem answered the module's AT string with CONNECT 1200; the driver sniffed it and wrote ACIA control $17. Driving $E7B2 directly with X = 0, 3 and 6 gave $15, $17 and $18 - the three-byte stride of baudEntryTable $E6FD behaving, not just the one index.

Scripts: testRealtime.py (unchanged in method, three small additions noted in section 6) and the new test1200AutoBaud.py. Logs: testLogs/rate1200Run1.txt, testLogs/rate1200Run2.txt, testLogs/rate1200Run3.txt, testLogs/autoBaud1200Run4.txt (and the three failed attempts that preceded it, autoBaud1200Run1..3.txt). Per-second byte counts in testLogs/realtime.r12*.run1200.w*.samples.txt, tracepoint output in the matching *.trace.txt, screenshots shots/rtr12*.png and shots/abab4*.png.

---

1. How 1200 was selected, and what the chip was given

baudIndex $E055 comes off the disk as 0 every time the module is loaded, so 1200 has to be asked for. Both machines were given C= + 1 at the "PRESS A OR O" prompt, before the link was ever opened - the order README.md tells the player to use - with the Commodore key on Tab, which is where VICE's default symbolic keymap puts it.

The hot key took on the first press on both machines in all three runs, and it programmed the 6551 immediately rather than waiting for the link:

Reading, at the A/O prompt, before the link opened	A	B
baudIndex $E055	3	3
ACIA control register $DE03	$17	$17
bitPeriodLo $E056 (the live control byte)	$17	$17
connectionPhase $E040 / isLinkActive $E03B	0 / $00	0 / $00
aciaCommandShadow $E5BE	$00	$00

$17 is $10 (8 data bits, one stop bit, internal baud-rate generator) OR rate bits $7, which on a SwiftLink's doubled 3.6864 MHz crystal is 1200 baud. It matches baudEntryTable+1 at $E701 in the built image, where the seven entries read

$E6FD: B3 15 00   B1 17 00   B2 18 00   B4 1A 00   B9 1C 00   B0 1E 00   B8 1F 00
       C=+3 300   C=+1 1200  C=+2 2400  C=+4 4800  C=+9 9600  C=+0 19200 C=+8 38400

One thing worth writing down because it looks alarming in a log: at that same pre-link edge linkErrorCount $E047 reads 72 on both machines. 72 is $48, the H of the leftover junk bytes 44 54 48 ("DTH") the module ships at $E045-$E047; nothing has cleared it yet because the link has not been opened. It goes to $00 when the link comes up and stays there.

Both machines reached connectionPhase 3 - the game's own packet protocol - in every run, and the side-0/side-1 negotiation completed: one machine ends on "OPPONENT PICKING GAME/MAP." and the other on the GAME TYPE menu. That is the same game state the 300- and 2400-baud runs in realtimeReport.md were measured in, which is what makes the three rates comparable.

---

2. Bytes each way, per window

conn0 is machine A (answer, the first to open its ACIA); conn1 is machine B (originate). "speed" is each emulator's own free-running cycle counter over the window against the wall clock - the check that this was measured at true C64 speed and not on a machine that could not keep up.

Run	Window	Wall	A speed	B speed	A -> B	B -> A
1	1/2	75.67 s	100.9%	100.5%	1675 B = 22.14 B/s	1584 B = 20.93 B/s
1	2/2	75.58 s	101.3%	100.9%	3042 B = 40.25 B/s	2577 B = 34.10 B/s
2	1/2	75.09 s	101.0%	100.6%	773 B = 10.29 B/s	760 B = 10.12 B/s
2	2/2	75.36 s	101.2%	100.8%	792 B = 10.51 B/s	802 B = 10.64 B/s
3	1/2	75.67 s	101.0%	100.5%	3433 B = 45.37 B/s	3248 B = 42.92 B/s
3	2/2	75.14 s	100.9%	100.5%	3406 B = 45.33 B/s	3138 B = 41.76 B/s
all six		452.51 s			13121 B = 29.00 B/s	12109 B = 26.76 B/s

The 8N1 ceiling at 1200 baud is 120 bytes/s. The six-window average is 24% of it in one direction and 22% in the other, but the average is not the interesting number, because the line does get saturated in bursts: the per-second buckets run from 6 to 119 bytes/s, and 119 is 99% of what 1200 baud can carry in a second. What sets the average is the game, not the wire - the frame layer starts at most one thing per raster IRQ and the packet layer exchanges one packet per lock-step turn.

Per-second buckets, from testLogs/realtime.r12*.run1200.w*.samples.txt, one line per second per window:

Run	Window	conn0 (A -> B)	conn1 (B -> A)	seconds at zero
1	1/2	15 to 79 B/s	14 to 100 B/s	none
1	2/2	15 to 88 B/s	13 to 88 B/s	none
2	1/2	6 to 47 B/s	6 to 69 B/s	none
2	2/2	6 to 61 B/s	6 to 84 B/s	none
3	1/2	19 to 89 B/s	18 to 99 B/s	none
3	2/2	15 to 74 B/s	13 to 119 B/s	none

Not one second, in either direction, in any of the six windows, carried zero bytes. That is the single most important line in this report: the failure mode this driver has to avoid is a machine that stops talking, and at 1200 baud it never did, not even in the windows where the receive ring was overflowing.

$55 ARQ lead bytes

The frame layer's lead byte is $55. These are raw occurrences in the window's byte stream, so a $55 that happens to be payload is counted too - the number is a floor on the frame rate, not an exact frame count.

Run	Window	$55 A -> B	per second	$55 B -> A	per second
1	1/2	553	7.3	580	7.7
1	2/2	713	9.4	733	9.7
2	1/2	279	3.7	254	3.4
2	2/2	297	3.9	291	3.9
3	1/2	786	10.4	751	9.9
3	2/2	758	10.1	688	9.2
all six		3386	7.5	3297	7.3

Every window carried real ARQ frames in both directions. For comparison, the 2400-baud windows in realtimeReport.md section 8 carried about 250 $55 per direction per window - roughly 3.4 frames a second - so 1200 baud in this same game state is doing between one and three times as much frame traffic as 2400 did, which is a statement about how much the two games had to say to each other in each run rather than about the rates.

Byte-sync floods

beginByteSyncPhase pours out $00 until the peer answers, so a run of eight or more $00 in the stream is the signature of a link that has dropped out of the packet phase and is resynchronising.

Run	Window	A -> B runs of >= 8 zeros / longest	B -> A runs / longest
1	1/2	3 / 42	2 / 25
1	2/2	18 / 87	17 / 54
2	1/2	0 / 6	1 / 42
2	2/2	0 / 1	0 / 1
3	1/2	33 / 48	30 / 39
3	2/2	33 / 57	33 / 50

Runs 1 and 3 resynchronised repeatedly and run 2 barely at all. The resyncs track the error counts in section 3 exactly, and every one of them ended - the longest flood in 452 seconds was 87 bytes, under a second of line time at 1200 baud. Compare the pre-fix 2400-baud failure in realtimeReport.md section 4, where one direction carried 4495 bytes of $00 and nothing else for an entire 75-second window and never came back.

---

3. Errors: all thirty-two were receive-ring overflows, all on the same machine

The NMI receiver pushes two different things through reportLinkError $E3BC into countLinkError $E403: a character whose status shows overrun, framing or parity error, and a good character that had nowhere to go because the 20-byte receive ring was already full. linkErrorCount $E047 cannot tell them apart and cannot even be trusted as a total, because restartByteSync clears it at $E814

• which is why it reads $00 at every window edge in this report while errors were plainly happening.

So a second tracepoint was added, conditional so that it fires only on the overflow case:

trace exec $e403                 # every character the receiver threw away
trace exec $e505 if x > $13      # ... and the subset thrown away because the ring was full

$E505 is the CPX #$14 inside pushUartRxRing, and X was loaded with uartRxCount three cycles earlier at $E502, so X > $13 means the ring already held all twenty characters. (The monitor reads condition numbers as hex - x > 19 would have meant X > $19 - which is why the constant is written $13.) A tracepoint prints and carries on; it never stops the emulator.

Machines were told apart afterwards by the free-running cycle counter each trace line carries: the two emulators start seconds apart and their stopwatch ranges never overlap.

Run	Window	$E403 total	of which ring-full $E505	on machine A	on machine B
1	1/2	7	not instrumented	0	7
1	2/2	6	not instrumented	0	6
2	1/2	8	8	0	8
2	2/2	3	3	0	3
3	1/2	7	7	0	7
3	2/2	1	1	0	1
all six		32	19 of 19, in the four windows it was live in	0	32

In runs 2 and 3, where both tracepoints were live, the two counts are equal in every window: 8 and 8, 3 and 3, 7 and 7, 1 and 1. Not one character was rejected for a bad status. Run 1 had only the $E403 tracepoint, but its trace lines carry the same fingerprint - X reads $14 at $E403 on all thirteen hits, which is uartRxCount = 20 left in X by the ring-full exit - so those thirteen were overflows too.

That is the ceiling the task brief suspected, and it is real at 1200 baud, not only at 38400. The raw receive ring is 20 bytes, only the once-per-frame tick drains it, and awaitWholePacket will not copy a packet out until the whole payload and its check byte are resident - up to 17 bytes - so the real headroom is about three bytes. At 1200 baud a video frame is about 2.0 character times, so a steady 1200-baud stream cannot overflow it; a burst that arrives while the tick is not draining can, and did. There is no RTS throttling anywhere in this driver.

What the driver does about it is the answer that matters. A non-zero linkErrorCount makes runLinkStateMachine restart the byte sync whatever phase it was in, and that is exactly what the $00 floods in section 2 are. Every one of them completed, the link came back to phase 3, and the per-second byte counts never dropped to zero in either direction. It degrades and recovers. It does not wedge.

Two honest caveats. First, every overflow in all three runs was on machine B, the originate side and the second emulator to be started, and machine A recorded not a single one in 452 seconds. That is not explained. It is not the game screen - B was on the GAME TYPE menu in runs 1 and 3 and on "OPPONENT PICKING GAME/MAP." in run 2, and it overflowed in all three. Both machines held 100.5% or better of real time throughout, so it is not one emulator falling behind. Second, VICE's ACIA is byte level: it paces whole bytes at the rate the control register asks for but does not shift them bit by bit, so the framing and parity errors a real noisy line would produce cannot appear on this rig at all. "Zero bad characters" is a statement about this emulation, not about a real cable.

---

4. The transmitter: the deadlock state never occurred

txCharActive $E5BB and aciaCommandShadow $E5BE were read on both machines at the open of each series and at the close of each window, with both emulators stopped.

txCharActive	aciaCommandShadow	Readings	Meaning
$00	$00	6	at the A/O prompt, before the ACIA was ever programmed
$00	$09	10	idle: transmit interrupt disarmed, nothing believed to be in the chip
$01	$05	14	busy: transmit interrupt armed, a byte of ours in the chip
$01	$09	0	the deadlock - never seen

Thirty readings, only the two self-consistent pairs. testRealtime.isTxDeadlocked reported False at every edge and its repair probe - which would have written $00 over $E5BB from the monitor and said so in the log - never ran, so nothing in these numbers is the test rig patching the driver up.

The full edge table, all three runs, in order (open of the series, close of window 1, close of window 2). err is linkErrorCount $E047, pend is uartPendingCount $E0A5:

Run	Edge	A: phase / active / err / $E5BB / $E5BE / pend	B: phase / active / err / $E5BB / $E5BE / pend
1	before the link opened	0 / $00 / $48 / $00 / $00 / $00	0 / $00 / $48 / $00 / $00 / $00
1	open of the series	3 / $01 / $00 / $00 / $09 / $00	3 / $01 / $00 / $00 / $09 / $00
1	close of w1	2 / $01 / $00 / $01 / $05 / $01	3 / $01 / $00 / $01 / $05 / $03
1	close of w2	3 / $01 / $00 / $00 / $09 / $00	2 / $01 / $00 / $01 / $05 / $01
2	before the link opened	0 / $00 / $48 / $00 / $00 / $00	0 / $00 / $48 / $00 / $00 / $00
2	open of the series	2 / $01 / $00 / $01 / $05 / $01	3 / $01 / $00 / $01 / $05 / $03
2	close of w1	3 / $01 / $00 / $00 / $09 / $00	3 / $01 / $00 / $01 / $05 / $03
2	close of w2	3 / $01 / $00 / $01 / $05 / $01	3 / $01 / $00 / $01 / $05 / $03
3	before the link opened	0 / $00 / $48 / $00 / $00 / $00	0 / $00 / $48 / $00 / $00 / $00
3	open of the series	2 / $01 / $00 / $01 / $05 / $01	3 / $01 / $00 / $01 / $05 / $02
3	close of w1	3 / $01 / $00 / $00 / $09 / $00	2 / $01 / $00 / $01 / $05 / $01
3	close of w2	3 / $01 / $00 / $01 / $05 / $03	2 / $01 / $00 / $00 / $09 / $00

isLinkActive $E03B was $01 at every edge after the link came up and $00 at every pre-link edge. linkErrorCount $E047 read $00 at every edge after the link came up - which, as section 3 explains, means "no error since the last resync" and not "no errors", and is the reason the tracepoints exist. connectionPhase $E040 moves between 3 and 2 as the link drops into and out of a byte-sync round, exactly as it did in the healthy 300-baud run of realtimeReport.md section 3. uartPendingCount never rose above $03, so neither transmitter ever had a backlog.

The ACIA control register $DE03 and bitPeriodLo $E056 read $17 and baudIndex $E055 read 3 at all thirty readings on both machines. Nothing reprogrammed the rate behind the driver's back and nothing drifted.

---

5. The auto-baud path: CONNECT 1200 really does select 1200

switchTo1200Baud $E7B2 is reached from $E7B0 (LDX #$03) when serviceModemInput sees a CR whose preceding character was '0' - the last digit of a verbose CONNECT 1200. That caller predates the SwiftLink table, so the question is whether X = 3 still lands where the table says it does. It was tested twice, once through the real path and once by driving the entry point directly. Script: test1200AutoBaud.py. Log: testLogs/autoBaud1200Run4.txt.

5.1 Through a fake Hayes modem

One machine, its serial line wired not to a peer but to a TCP listener in the test script that behaves like a modem far enough to answer the AT string. The emulator was left completely alone across the critical window - the answer timer at $E7D5 gives the reply about 121 frames, two emulated seconds, and every monitor command stops the emulated clock.

What the fake modem saw and said, from its own timestamped log:

+100.757  the emulator opened the serial line
+100.787  from the C64: '\r'
+101.870  from the C64: 'A' 'T' 'Q' '0' 'V' '1' 'X' '1' 'A'      (answer-mode Hayes string)
+102.201  from the C64: '\r'
+102.202  answered '\r\nCONNECT 1200\r'
+104.780  from the C64: '\x00' ... the byte-sync flood of connection phase 2

The $00 flood starting 2.58 s after the AT string's CR is the 121-frame answer timer expiring and the state machine falling out of terminal mode into byte sync, which is what should happen. What it left behind:

Reading	Value
ACIA control register $DE03	$17	8N1, internal baud generator, rate bits $7 = 1200 baud
bitPeriodLo $E056	$17	the driver's own mirror of the live control byte
baudIndex $E055	0	unchanged - see below
lastModemChar $EB02	$20	the space $E7B5 substitutes for the CR after the sniff
connectionPhase $E040 / isLinkActive $E03B	2 / $01	in byte sync, link up
linkErrorCount $E047	$00

$17 with baudIndex still 0 can only have come from switchTo1200Baud. The only three callers of loadBaudParameters are openCommLink $E2C9, which loads X from baudIndex and would therefore have written $15; the speed hot keys, which do STX baudIndex at $E350 on the way in and would have left $E055 = 3; and $E7B2, which loads X immediately and touches $E055 never. No hot key was pressed in this run.

5.2 Driving $E7B2 directly

With the emulator stopped, the ACIA was forced back to 300 baud, $E056 cleared, txCharActive $E5BB set to $01 by hand, PC put on $E7B2 and X loaded through the monitor; n then steps over the JSR and its whole subroutine. Doing it for three indices exercises the three-byte stride rather than the single value the sniffer uses:

X	$DE03 before	$DE03 after	$E056 after	$E5BB after	$E055 after	Expected
0	$15	$15	$15	$00	0 (untouched)	$15, 300 baud - PASS
3	$15	$17	$17	$00	0 (untouched)	$17, 1200 baud - PASS
6	$15	$18	$18	$00	0 (untouched)	$18, 2400 baud - PASS

So the behaviour matches the table, and matches the built image, where baudEntryTable+1 at $E701 is $17. Two side effects of the current loadBaudParameters show up in that table and are worth recording:

• txCharActive is cleared. $E5BB was set to $01 before each entry and read $00 after, which is aciaSetControlIdle $E04C doing its job - the third of the three deadlock fix sites in realtimeReport.md section 8. A CONNECT 1200 that arrives while a character is half way out of the chip cannot strand the flag.
• baudIndex $E055 is not updated. loadBaudParameters writes the control register and bitPeriodLo and nothing else. This is faithful to the stock driver, which behaved the same way, but it has a consequence: openCommLink $E2C6 reloads the rate from baudIndex whenever it finds isLinkActive = 0, so a link that is torn down and re-opened after a CONNECT 1200 comes back at 300 baud, silently. A re-open on a live link (C= + RETURN, which reaches openCommLink with isLinkActive already set) skips loadBaudParameters entirely and keeps 1200.

5.3 What the source said about it

The comment on $E7B0/$E7B2 was wrong in two ways and has been corrected - comments only, the assembled image is byte-for-byte identical before and after, and checkAbi.py still passes:

• $E7B0 ended "so this caller still selects 120053 cycles = 1200 baud". The 53 cycles is wreckage from the stock driver's comment, where the number really was a CIA timer value.
• $E7B2 said "copy that entry into the live bit period $E056/$E057 and the pacing divisor $E058", which is what the stock loadBaudParameters did. The SwiftLink one writes $E056 and the ACIA control register; $E057 and $E058 have been dead since the software UART was replaced. It now says what it does, and records the baudIndex trap above.

---

6. What was changed in the test rig, and what went wrong in it

Three additions to testRealtime.py, all additive:

• each machine's tracepoint output is now kept separately (tracedBy), so a hit can be attributed to one end;
• the conditional overflow tracepoint trace exec $e505 if x > $13 is set alongside $e403;
• the hit counter's regular expression was wrong and is fixed. The monitor announces a hit as #1 (Trace exec e403) and disassembles the line as .C:e403 ... - no dollar sign on either - so a pattern of C:\$e403 matches nothing. The consequence is in the logs of runs 2 and 3: their own printed summaries say "0 tracepoint hits" and that is false. The counts in section 3 are from the saved *.trace.txt files, re-counted afterwards, and they are the real ones. Run 1's log predates the change and counted (Trace instead, which was right while $e403 was the only tracepoint.

test1200AutoBaud.py is new. Three attempts failed before the one reported above, all for rig reasons rather than driver reasons, and two of them are worth passing on:

• answerModemPrompts can return before the link could possibly have opened. It uses "$E5BE is non-zero" as its test, and at true C64 speed the 1541 takes the best part of a minute to fetch the opponent module off track 34. Until it lands, $E000-$EFFF still holds the previous overlay - $E5BB-$E5BE read E8 84 18 AC in the first attempt, and $AC was taken for an open link while the screen still said "WORKING...". The module's stored bytes there are all $00, so the test is sound once the module is resident; the fix is to wait for residency first.
• $E013/$E014 is not a safe residency test either, although testRealtime.selectRate uses it: the pre-load wreckage read B7 0D - exactly the patched value - in the second attempt. test1200AutoBaud.waitForModule waits on all sixteen bytes of the $E000 jump table instead, and re-offers the fire button every six polls, because in the third attempt the press that starts the load simply did not land.

One self-inflicted loss: ./build.sh was run to rebuild the disk while a measurement run was in flight, which rewrites the .d64 the running emulators have attached. That run was killed and restarted rather than trusted, and its emulators and Xvfb displays were cleaned up by hand. The three runs reported here all ran against a stable image.

---

7. What this does not show

• VICE, not hardware. No physical SwiftLink, no real cable, no real modem. The CONNECT 1200 in section 5 came from fifteen bytes written into a TCP socket by a Python script.
• VICE's ACIA is byte level. It cannot produce framing or parity errors, so "every error was a ring overflow" is a result about this rig. On a real line the same tracepoints would be expected to show bad characters as well.
• The overflows are unexplained. Thirty-two of them, all on machine B, none on machine A, over three boots. What burst produces them, and why only one end sees them, was not chased - doing it needs the NMI instrumented, which stops the emulator and destroys the timing being measured.
• No stock user-port peer. 1200 is where a SwiftLink player and an unmodified user-port player would meet, and that pairing still has not been run. Both machines here were SwiftLink builds.
• No complete game. Same as every earlier report: the two machines reach the GAME TYPE menu and stay there.
• Six windows is not a long soak. 452 seconds at 1200 baud is enough to say the deadlock did not recur and the link recovers from overflow, and not enough to say it never will.
• The auto-baud path was exercised once end to end, in answer mode, on a link with no peer behind the fake modem. The originate string ATQ0V1X1D and a CONNECT 1200 arriving on a link that then goes on to play a real game were not tried.

---

8. Files

File	What it is
test1200AutoBaud.py	new: one machine, a fake Hayes modem that answers CONNECT 1200, then $E7B2 driven directly with X = 0, 3 and 6
testLogs/rate1200Run1.txt	run 1 - C= + 1 at the A/O prompt, two 75 s windows
testLogs/rate1200Run2.txt	run 2 - a second boot, same sequence
testLogs/rate1200Run3.txt	run 3 - a third boot, same sequence, with both tracepoints live
testLogs/realtime.r12*.run1200.w*.samples.txt	per-second byte counts, both directions, every window
testLogs/realtime.r12*.run1200.w*.trace.txt	raw $E403 and $E505 tracepoint output, with the cycle counter that attributes each hit to a machine
testLogs/autoBaud1200Run4.txt	the auto-baud run reported in section 5
testLogs/autoBaud1200Run1.txt, ...Run2.txt, ...Run3.txt	the three rig failures described in section 6
testLogs/autoBaud1200.ab4.modem.txt	the fake modem's own timestamped event log
shots/rtr120*.png, shots/rtr12b0*.png, shots/rtr12c0*.png	the menu, the linked pair and the end of each window, runs 1 to 3
shots/abab401Menu.png, shots/abab402AfterConnect.png	the auto-baud run