Running the thermometer把溫度計跑起來

The tool工具A temperature knob in a real emulator在真模擬器裡裝一個溫度旋鈕

For a fast, iterative verification we used AprNes, the user's fast, cycle-accurate (master-clock) NES emulator, as the test bench. AprNes already tracked an open-bus latch but never actually decayed it (a leftover countdown that expired in ~14 ms, far too fast). We replaced that with the physical model from deep dive #3:

為了能快速、反覆地驗證,這個實驗用AprNes(使用者那顆快速、cycle-accurate 的 master-clock NES 模擬器)當測試台。AprNes 本來就追蹤一個 open-bus 閂鎖,但從沒真的讓它衰減(一段殘留的倒數 ~14ms 就到期、太快)。我們把它換成深入專文 #3 的物理模型:

• a lazy-timestamp decay: the latch is stamped with the current PPU-dot time whenever a PPU access drives it, and reads back as 0 once the elapsed time passes the decay period — zero cost in the hot loop;
• 懶惰時戳衰減:每次 PPU 存取驅動閂鎖時蓋上當下的 PPU-dot 時間,一旦經過的時間超過衰減週期,讀回就是 0 —— 熱路徑零成本;
• the decay period follows the Arrhenius law t(T) = t0·exp(Ea/k·(1/T − 1/Tref)), with t0 = 600 ms at 25 °C — so it is temperature-controlled;
• 衰減週期依 Arrhenius t(T) = t0·exp(Ea/k·(1/T − 1/Tref)),25 °C 時 t0 = 600ms —— 所以受溫度控制;
• only the PPU latch decays — the CPU external bus is re-driven by every instruction fetch, exactly as on hardware.
• 只有 PPU 閂鎖衰減 —— CPU 外部匯流排每次取指都被重驅動,和硬體一模一樣。

Then two headless CLI flags expose it:

再用兩個無頭 CLI 旗標把它露出來:

--openbus-temp <°C>   ; set the die/ambient temperature for the run (default 25)
--dump-mem <hexaddr>   ; print 8 bytes + the little-endian u24 at that CPU address at exit

So the temperature is a literal knob (hard-coded 25 °C by default; wire it to a UI later), and --dump-mem lets us read the ROM's result numerically instead of squinting at a screenshot.

於是溫度就是一個字面的旋鈕(預設寫死 25 °C,以後可接 UI),而 --dump-mem 讓我們用數值讀出 ROM 的結果,不用瞇著眼看截圖。

The test ROMTest ROMPrime, poll, count, invert, print充電、輪詢、計數、反推、印出

The ROM (tools/thermo_rom/, a plain NROM cart assembled with WLA-DX) is a five-step pipeline:

這顆 ROM(tools/thermo_rom/,用 WLA-DX 組譯的一般 NROM 卡帶)是一條五步管線:

1. Prime — write $FF to $2002 (PPUSTATUS is read-only, so the write is ignored as a register op but still fills the open-bus latch, with no side effect).
2. 充電 —— 寫 $FF 到 $2002(PPUSTATUS 唯讀,所以寫入被當暫存器操作忽略、但仍填進 open-bus 閂鎖,無副作用)。
3. Poll & count — tight-loop LDA $2001 / CMP #$FF (reading a write-only register returns the full 8-bit open bus), incrementing a 24-bit counter until the first bit drops. That count is the decay time, measured in loop iterations.
4. 輪詢計數 —— 緊迴圈 LDA $2001 / CMP #$FF(讀寫入專用暫存器回傳完整 8 位 open bus),遞增一個 24-bit 計數器,直到第一個位元掉下來。那個計數就是衰減時間,以迴圈次數為單位。
5. Invert — turn the count into a temperature (see §below).
6. 反推 —— 把計數轉成溫度(見下節)。
7. Print — write NN DEGREE CELSIUS to the name table and turn rendering on.
8. 印出 —— 把 NN DEGREE CELSIUS 寫進 nametable、打開渲染。

The one non-obvious thing (the whole reason the trick works) is that we watch the PPU's I/O latch, not a CPU open-bus address — the polling opcodes travel over the CPU bus and would overwrite it every fetch, so you'd read the last opcode, never the decay. The ROM's source is heavily commented as a tutorial.

唯一不明顯、也是整個訣竅成立的關鍵:我們看的是 PPU 的 I/O 閂鎖,不是 CPU open-bus 位址 —— 輪詢的 opcode 走 CPU 匯流排、每次抓取都會把它覆寫掉,你會讀到最後那個 opcode、永遠讀不到衰減。ROM 原始碼有大量教學註解。

Usage用法Build it, run it, read it建置、執行、讀取

# build the ROM (generates the lookup table, assembles, wraps as iNES)
python tools/thermo_rom/build.py

# run headless at 25 °C, dump the result, screenshot at ~5 s
AprNes.exe --rom thermo.nes --openbus-temp 25 --time 6 \
           --dump-mem 0013 --timed-screenshots "c_25.png:5.0"
;  MEM_DUMP 0013: ...  u24_le=25      -> 25 °C   (--dump-mem 0010 = raw decay count)

Two gotchas. (1) Cold runs decay slowly (0 °C ≈ 4.4 s of emulated time), so give --time headroom and screenshot a later frame — the screen stays black until the measurement finishes. (2) Under Git Bash, MSYS mangles the path:seconds argument (the : looks like a unix path-list separator) — use PowerShell for --timed-screenshots.

兩個雷。(1) 冷溫衰減慢(0 °C 約 4.4 秒模擬時間),--time 要留裕度、截更晚的幀 —— 量測完成前螢幕是黑的。(2) Git Bash 下 MSYS 會搞壞 path:秒數 參數(: 被當成 unix 路徑清單分隔符)—— 截圖那類指令請用 PowerShell。

It works它成功了The readout, across temperatures跨溫度的讀值

Real frame captures from the headless emulator: feed the knob a temperature, and the ROM — which only ever measured a decay count — reads it back on screen. Sweeping all 101 integer degrees, every one reads back exactly (0 mismatches / 101). A sample of the round-trip (set °C → displayed °C):

來自無頭模擬器的真實幀截圖:給旋鈕一個溫度,而這顆只量了一個衰減計數的 ROM,就把它讀回螢幕上。掃過全部 101 個整數度,每一度都精確讀回(0 誤差 / 101)。Round-trip 抽樣(設定 °C → 顯示 °C):

Exact across the whole range — no warm-end blur. (An earlier build wobbled above ~44 °C; that turned out to be a non-monotonic host clock in the emulator, now fixed — see below.) And remember: this "round-trip" only inverts the emulator's own model — see the note on circularity below.

整個範圍都精確 —— 沒有暖端 blur。(較早的 build 在 ~44 °C 以上會抖,後來發現是模擬器裡一個非單調的 host 時鐘,已修 —— 見下方。)也別忘了:這個「round-trip」只是把模擬器自己的模型反過來 —— 見下方關於循環的說明。

Calibration diagnostics校準診斷How the curve actually looks (for the statisticians)曲線實際長怎樣(給統計的人)

Because a calibration expert asked — and rightly noted you can't do a chemistry-style spike/blank pair for temperature — here is exactly how the calibration behaves. First, one thing that changes all the statistics: the emulator is deterministic. Running the same temperature five times gives the identical integer count (25 °C → 67001 every time), so per-point %RSD is strictly 0 — the uncertainty here is quantization (integer counts), not stochastic dispersion, and σ-based metrics (prediction intervals, LOD/LOQ) are degenerate.

因為一位校準專家問了 —— 而且正確指出溫度沒辦法做化學那種 spike/blank 對照 —— 這裡把校準的實際行為攤開。先講一件會改變所有統計的事:模擬器是確定性的。同一溫度跑五次得到完全相同的整數計數(25 °C → 每次 67001),所以per-point %RSD 嚴格為 0 —— 此處的不確定度是量化(整數計數),不是隨機散布,基於 σ 的指標(預測區間、LOD/LOQ)在此退化。

Raw data and the reproducible fit/residual/check script are in the repo: counts_by_degree.json · calib_stats.py. All of this validates the software pipeline on a deterministic emulator, not the physics — on real silicon %RSD becomes non-zero and proper chemometrics (replicates, thermal-chamber high/low, a fit that survives a lack-of-fit test) would apply.原始資料與可重跑的擬合/殘差/檢查腳本在 repo:counts_by_degree.json · calib_stats.py。這一切驗證的是確定性模擬器上的軟體管線、不是物理 —— 真矽晶上 %RSD 會非零,才需要正規 chemometrics(重複量測、thermal-chamber 高/低、通過 lack-of-fit 檢定的擬合)。

Count → Celsius, on a 65026502 上 count → 攝氏No multiply, no divide, no float不乘、不除、不浮點

Inverting an Arrhenius curve means a logarithm and a reciprocal — miserable on a 6502. So we do none of it at runtime. On the PC side, build.py precomputes the whole curve as an integer-°C lookup table: thr[i] = the count you would measure at temperature i − 0.5 °C, for i = 0..100 (so the index is the temperature in whole degrees; entries 101–127 are 0 padding so the fixed-width search clamps at the hot end). The table decreases (cold = big count).

反推 Arrhenius 曲線要對數和倒數 —— 在 6502 上很痛苦。所以我們在執行期一個都不做。PC 端 build.py 把整條曲線預先算成一張 整數 °C 查表:thr[i] = 在溫度 i − 0.5 °C 會量到的計數,i = 0..100(所以 index 就是整數度;101–127 是 0 padding,讓固定寬度的搜尋在熱端 clamp)。表遞減(冷 = 計數大)。

The ROM then finds "the largest index whose threshold is still ≥ our count" with a 7-step power-of-two binary search — building the 7-bit index (0–127) one bit at a time, no division. Finally it formats the index as a decimal integer with repeated-subtraction BCD (subtract 100s and 10s, count the subtractions) and leading-zero blanking. The approach — lookup + radix search + subtraction BCD — was the division-free path recommended by a 6502 consult.

ROM 再用 7 步 2 的冪次二分搜找「門檻仍 ≥ 我們計數的最大 index」—— 一次組一個 bit 出 7-bit index(0–127),不用除法。最後用連減法 BCD(反覆減 100、10 數次數)+ 前導零消隱把 index 格式化成十進位整數。這條路 —— 查表 + radix 搜尋 + 連減 BCD —— 是一次 6502 諮詢推薦的免除法做法。

; the whole search — 7 iterations, no MUL/DIV
    lda #0 / sta idx      ; idx = 0, step = 64
rx_loop:
    ; test = idx + step ; if thr[test] >= count: idx = test
    jsr read_thr          ; fetch the 24-bit threshold (SoA: thr_lo/mid/hi)
    lda tblL / cmp cnt0     ; 24-bit compare via CMP + SBC chain
    bcc rx_next           ; thr < count -> don't set this bit
    ...                     ; else idx = test
    lsr stp               ; step >>= 1, loop until 0
    ; idx (0..100) == temperature in whole degrees C

Where it's rough哪裡粗糙Honest limits — it's a validation, not a product誠實極限 —— 這是驗證,不是產品

• The warm-end blur was a bug, and it's fixed. An earlier build lost resolution above ~44 °C — adjacent degrees shared a count (43 and 44 °C both read the same), which we almost wrote off as "fast decay = coarse count, real physics." It wasn't. The emulator's time helper (NowDots()) derived the clock from frame_count/scanline/x, and frame_count++ fires at scanline 240 (a host-side render boundary), so the clock jumped a whole frame there and tripped the decay early whenever the decay period fell near one frame — exactly the warm end. Deriving NowDots() from the monotonic CPU-cycle counter (mcCycleCount × 3) fixed it; the change touches only the open-bus helper, not any game-visible timing, so AccuracyCoin/blargg are unaffected (ppu_open_bus + ppu_read_buffer still PASS). Now every degree 0–100 °C has its own count and the round-trip is per-degree exact; the only residual error is the ±0.5 °C of integer rounding (uniform cold-to-hot). A good reminder to distrust a too-convenient "it's fundamental physics" explanation.
• 暖端 blur 是 bug,而且修好了。較早的 build 在 ~44 °C 以上失去解析度 —— 相鄰度共用一個計數(43 和 44 °C 讀到相同值),我們差點把它當成「衰減快 = 計數粗,真物理」寫掉。它不是。模擬器的時間輔助函式(NowDots())用 frame_count/scanline/x 算時鐘,而 frame_count++ 在 scanline 240(一個 host 端渲染邊界)進位,所以時鐘在那裡跳了一整幀,只要衰減週期接近一幀就把衰減提早觸發 —— 正好是暖端。把 NowDots() 改用單調的 CPU-cycle 計數器(mcCycleCount × 3)就修好了;這個改動只碰 open-bus 輔助函式、不碰任何遊戲可見時序,所以 AccuracyCoin/blargg 不受影響(ppu_open_bus + ppu_read_buffer 仍 PASS)。現在 0–100 °C 每一度都有自己的計數、round-trip 逐度精確;唯一殘留誤差是 ±0.5 °C 的整數捨入(冷熱端一致)。這是個好提醒:別太快接受一個太方便的「這是根本物理」解釋。
• Range is clamped. The table covers 0–100 °C; anything colder or warmer pins to the ends (and reads -- when colder than the range or when open bus never decays).
• 範圍會 clamp。表涵蓋 0–100 °C;更冷或更熱都夾到端點(比範圍冷、或 open bus 完全不衰減時讀 --)。
• It's a per-model calibration. The count depends on the emulator's exact loop timing, so the lookup table is calibrated to this build of AprNes. On real silicon the absolute offset differs per console (a one-point calibration fixes it — the Arrhenius slope is universal, only the offset moves).
• 這是逐模型校準。計數依賴模擬器確切的迴圈時序,所以查表是對這個 AprNes build 校準的。真矽晶上絕對 offset 逐台不同(一點校準即可修正 —— Arrhenius 斜率普世,只有 offset 會動)。
• Emulator ambient ≠ hardware room. Here the knob is literal ambient temperature. On a real NES the PPU self-heats +30–40 °C, so the same ROM would read the die temperature unless cold-booted and read within seconds. The emulator sidesteps that — which lets us exercise the software mechanism cleanly (but doesn't prove the real-hardware model — see below).
• 模擬器的環境溫度 ≠ 硬體室溫。這裡旋鈕是字面的環境溫度。真 NES 上 PPU 自體發熱 +30–40 °C,同一顆 ROM 會讀到晶粒溫度,除非冷開機幾秒內讀。模擬器繞過這點 —— 這讓我們乾淨地跑通軟體機制(但不證明真硬體模型 —— 見下)。
• The round-trip is circular — this is the key caveat. The emulator sets decay = f(T); the ROM computes T = f⁻¹(decay). Recovering the input temperature is therefore guaranteed by construction — it proves the software (measure → invert → display) is correct, and nothing about whether the model is right on real silicon. A real validation needs real hardware and an external reference thermometer, which is future work.
• round-trip 是循環的 —— 這是最關鍵的但書。模擬器設 decay = f(T);ROM 算 T = f⁻¹(decay)。拿回輸入溫度是先天保證的 —— 它只證明軟體(量測 → 反推 → 顯示)正確,完全不證明模型在真矽晶上對不對。真正的驗證需要實機 + 外部參考溫度計,是未來的工作。
• Arrhenius is a first-order model. Ea ≈ 0.56 eV ≈ Eg/2 is the generation–recombination leakage that dominates near room temperature; above ~80–100 °C diffusion current (Ea ≈ Eg) kinks the slope, and the measured time also depends on C(V), the read-buffer threshold-voltage drift (~−2 mV/°C), and V_DD. Our emulator uses the single-Arrhenius law; a faithful model would layer these in.
• Arrhenius 是一階模型。Ea ≈ 0.56 eV ≈ Eg/2 是室溫附近主導的 generation–recombination 漏電;~80–100 °C 以上擴散電流(Ea ≈ Eg)讓斜率折點,量到的時間還取決於 C(V)、讀取緩衝閾值電壓漂移(~−2 mV/°C)、V_DD。我們模擬器用單一 Arrhenius;忠實模型要把這些疊進去。
• No ground truth for calibration. On real hardware the die self-heats and there's no on-chip thermal sensor, so software can never read the true junction temperature to check its calibration against — external package temperature is only a thermal-gradient-error proxy. This is a fundamental limit; the honest framing is a relative instrument.
• 校準沒有 ground truth。真硬體上晶粒自體發熱、又沒片上溫度感測器,軟體永遠讀不到真接面溫度去對照校準 —— 外部封裝溫度只是隔著熱梯度誤差的 proxy。這是根本限制;誠實的定位是一把相對儀器。

So, honestly: this shows a physical model of an emulator "bug" (open-bus decay) given a temperature dependence, and a stock 6502 program reading that dependence back out as a number. The software pipeline works end-to-end. Whether the underlying model matches real silicon is a separate, unproven question — one deep dive #3's corrections now spells out, with thanks to the NESdev reviewer who pushed on exactly these points.

所以,誠實地說:這展示了一個模擬器「bug」(open-bus 衰減)的物理模型被給了溫度相依,以及一支原廠 6502 程式把那個相依讀回成一個數字。軟體管線端到端可運作。底層模型是否符合真矽晶,是另一個、還沒被證明的問題 —— 深入專文 #3 的更正現在把它講清楚了,並感謝那位正好戳中這些點的 NESdev 審閱者。

← back to deep dives · the theory: deep dive #3← 回深入專文 · 理論篇:深入專文 #3