diff --git a/harness/mame/DUART_REPORT.md b/harness/mame/DUART_REPORT.md index 6231109..ff8b759 100644 --- a/harness/mame/DUART_REPORT.md +++ b/harness/mame/DUART_REPORT.md @@ -546,3 +546,90 @@ Final state of the acceptance instrument (900 frames): 'LEVEL1/2 ERROR -> HOST PORT - 15 ' <-- unchanged regression (no VT1200_* env): PC=3FDCE400 samples=199 HOLD ``` + +--- + +# CAUSALITY AUDIT (four-config A/B) — the failure is PRE-EXISTING + +Reviewed after the owner flagged that "the failure moved backwards" and that my two +MAME edits are both *timing* changes while the newly-blamed sub-test is a *timer* test. +Method: four configurations of the MAME tree (IRQ wiring kept in all four — without it +the test fails even earlier), built with `harness/mame/hp_ab.sh `: + +| cfg | IRQ | TxRDY edit | overrun edit | console | L3FA6E4B0 return | +|---|---|---|---|---|---| +| 1 | on | on | on | `HOST PORT - 15` | 6 | +| 2 | on | reverted | on | `HOST PORT - 15` | 6 | +| 3 | on | on | reverted | `HOST PORT - 15` | 6 | +| 4 | on | reverted | reverted | `HOST PORT - 15` | 6 | + +**Verdict: PRE-EXISTING.** The console line and the caller's return are identical in all +four configurations, including cfg 4 where both MAME edits are reverted to stock. Neither +`mc68681` edit causes or relocates the failure; they only change `RXCHECK`'s own flag +word (Section UPDATE). Variant files are kept in `harness/mame/mame_edits/` (`*.cfg1`, +`*.cfg2`, `*.cfg3`, `*.upstream`). + +## Methodology correction (important) + +My earlier `hp_ret.lua` attached labels to the **wrong `rets` addresses**, so the return +values I quoted were mis-attributed. Verified against the disassembly, the correct +`rets` sites and their owning functions (prologue register mask) are: + +| `rets` | function | return | +|---|---|---| +| `3FA71BB0` | **`L3FA6E4B0`** (the generic port-test routine) | 6 | +| `3FA753C0` | `L3FA71BC0` (baud/timer sub-test) | `0x00900040` | +| `3FA767D0` | `L3FA753D0` (RXCHECK sub-test) | `0x00000408` | +| `3FA77800` | `L3FA767E0` (XMITPASS sub-test) | 0 | + +`harness/mame/hp_ret2.lua` uses the corrected addresses. So the owner's premise "6 comes +from `L3FA71BC0`" is off: **`L3FA71BC0` returns `0x00900040`**; the `6` is +`L3FA6E4B0`'s own return. + +## What `6` actually is — not a failure code + +`L3FA6E4B0` (the routine the level-1 host-port caller invokes) ends its body by reducing +five descriptor fields to a 5-bit value (`3FA718D0`–`3FA71B50`) and returning it: + +``` +bit0 <- (struct+0x60 != 0) bit3 <- (struct+0xc0 != 0) +bit1 <- (struct+0x80 != 0) bit4 <- (struct+0xe0 != 0) +bit2 <- (struct+0xa0 != 0) +``` + +with `struct+0x80`/`struct+0xa0`/`struct+0xc0`/`struct+0xe0` set from the four +sub-test calls (`L3FA71BC0`, `L3FA753D0` x2 each). So: + +* **`6` = `0b00110`** — a *bitmap of which sub-tests returned nonzero*, not a device + status code: `L3FA71BC0` non-zero and `L3FA753D0` non-zero; `L3FA767E0` returned 0, and + the second-trio fields were never written (the caller aborts after the first trio). +* The host-port caller (`3FA85000`) is `move a8,a8 ; jreq `: **any** nonzero + value takes the error path, which returns `0x400` (`3FA853A0`). `0x400` is what the + status dispatcher turns into `LEVEL1/2 ERROR -> HOST PORT - 15`. + +**Unresolved, and flagged:** the polarity is suspicious. `L3FA753D0` (RXCHECK) returns +`0x408` *while all four of its own checks pass* (flag word 0 — see UPDATE), so "sub-test +returned nonzero" is **not** the same as "sub-test failed its checks". Either its success +path leaves a stale `a8`, or the five fields are pass flags and the caller's test is +inverted relative to my reading. I could not settle this, so `6` should **not** be +treated as a plain failure code until it is. + +## The two leads + +1. **Counter spuriously active — checked, not the cause.** `ISR` bit `0x08` + (`COUNTER_READY`) is set from frame 1, but MAME sets it in the *Start Counter Command* + read path (`mc68681.cpp` `case 0x0e: start_ct(); set_ISR_bits(INT_COUNTER_READY)`), + and the firmware itself performs that read at boot (`R 0640000E pc=3F200150`). It is + **not** masked into the IRQ (`IMR` = 7 = TxRDYA|RxRDYA|DeltaBreakA, no bit 3), and the + DUART ISR `L3FA78D90` does not handle ISR bit 3, so it cannot disturb the test. `ACR` + reads `0x0000` except when the sub-test writes `0x60`. +2. **DUART clock — unverified.** The service guide has no crystal/baud figure for the + DUART (`grep -i '3.6864|crystal|oscillator' docs/EK-V1000-SV-002_service-guide.txt` + → nothing; its only "baud" hit is test 16 "Test all baud rates", a level-2+ test). + 3.6864 MHz is the 68681 datasheet's nominal and remains the only evidence; **I could + not confirm it** against the guide. + +## Acceptance / regression (cfg 1, committed state) + +* Console: `LEVEL1/2 TESTING **` then `LEVEL1/2 ERROR -> HOST PORT - 15` — **unchanged**. +* Regression (no `VT1200_*`): `PC=3FDCE400 samples=199` — **holds**. diff --git a/harness/mame/hp_ab.sh b/harness/mame/hp_ab.sh new file mode 100755 index 0000000..cc6dbd0 --- /dev/null +++ b/harness/mame/hp_ab.sh @@ -0,0 +1,25 @@ +#!/bin/sh +# hp_ab.sh