Trace the exact Overall Rating storage/computation mechanism (bytecode interpreter)

[BreakableHoodie]

FINDINGS.md §6 item 1: the Overall Rating formula is solved and live-validated (mean|residual| ≈1.8 across live-read players — see the "Live validation" subsection), and its identity was confirmed early on (exact match against both the Scouting Report and Team Roster screens for the same player/session).

What's still open is the exact in-ROM storage/computation mechanism. Every live trace attempt at the render call site (0x0008562C / 0x00085627) lands inside a bytecode/jump-table interpreter (jmp (a0), not a normal call) — confirmed independently at two separate call sites (Scouting Report and Team Roster), so it's a real architectural feature of the ROM, not a one-off. Ad-hoc live tracing has been tried from multiple angles across two sessions with consistent, well-evidenced negative results (see §7 item 1 for the specifics already ruled out).

Recommended approach, not yet attempted: either (a) properly trace the interpreter's dispatch loop as its own scoped session (map the bytecode opcodes, not just the entry jump), or (b) a VDP/tile-level approach — reading what's actually being blitted to determine the source data path independent of the CPU-side trace.

Low priority now that the formula itself is solved and live-validated — this closes a "how does the ROM actually do it" curiosity, not a "do we trust the numbers" question.

[BreakableHoodie]

Major update: the exact nibble-set (which of the 14 nibbles feed Overall Rating) is now ROM-confirmed, not just statistically inferred.

While doing static recon for issue #3 (faceoffs), decoded a general string-record format used throughout this ROM's UI-widget bytecode and found the exact ROM table backing the Team Roster screen's stat-category cycle (0x085832, skater version; 0x085994, goalie version). Every entry's 2-byte suffix is a one-hot bit selecting which nibble that stat reads from — decoding it independently reproduced all 13 already-known nibble↔stat mappings with zero discrepancy, and identified the two previously-unexplained nibbles: nibble 0 = Weight, nibble 7 = Handed (both non-continuous attributes, which is exactly why they never correlated statistically).

The big one: the Overall widget's own suffix (0x1FBA) is bit-for-bit the OR of the nibble-bits that OR_WEIGHTS (fit via linear regression against 2011 GameFAQs data, in an earlier part of this project with zero awareness this bytecode table existed) assigned nonzero weight to. Verified in code:

OR_WEIGHTS = {1:2, 2:2, 3:3, 4:1, 5:1, 6:1, 8:1, 9:2, 10:1, 11:0, 12:1, 13:0}
mask = 0
for n, w in OR_WEIGHTS.items():
    if w > 0:
        mask |= 1 << (13 - n)
# mask == 0x1FBA, exact match to the ROM's own skater Overall widget parameter

What's now closed: which nibbles matter (10 of them, excluding 11 and 13) — ROM-confirmed, no longer a statistical guess.

What's still open (this issue's original scope, now narrower): the exact integer weight magnitudes, and the actual 68k opcode that consumes this bitmask to produce a number. That bitmask is almost certainly an argument to the same bytecode-interpreter handler already found at 0x0008562C/0x000854B6 — tracing that handler now has a concrete, verified input to look for, rather than being a blind trace of an unknown interpreter.

Full write-up in FINDINGS.md §6 item 6 ("Major breakthrough...").

[BreakableHoodie]

Quick additional data point from a wider `tools/rom_scan.py` sweep: a third `Overall` widget exists at `0x09E37E`/`0x09E390`, with bitmasks `0x1F3A` and `0x1B0F` — close variants of, but not identical to, the skater (`0x1FBA`) and goalie (`0x130F`) ones already decoded.

• `0x1F3A` decodes to nibbles `{1,2,3,4,5,6,8,9,10,12}` minus... wait, decodes to the same 10-nibble set as the skater formula (`{1,2,3,4,5,6,8,9,10,12}`) MINUS nibble 6 (Checking) — i.e. `{1,2,3,4,5,8,9,10,12}`.
• `0x1B0F` decodes to `{2,4,5,10,11,12,13}` — close to the goalie set (`{1,4,5,10,11,12,13}`) but with nibble 2 swapped in for nibble 1.

Not chased further — this suggests there are more than 2 "Overall" contexts in this ROM (maybe a third screen, or a simplified/positional variant), which is useful to know but doesn't change anything already published. Flagging as a data point for whoever picks up the full interpreter trace.

[BreakableHoodie]

New lead, not chased yet: while mapping game modes (see `docs/FINDINGS.md` §8.4), found that the `Trade Players` screen renders every player's exact Overall Rating as plain text for two entire rosters at once (e.g. live-read Belfour 98, Roenick 94 for Chicago), without cycling the Team Roster's stat category one player at a time the way every previous Overall Rating read in this project has worked.

Two possible payoffs if someone picks this up: (1) if this screen's render path turns out to be simpler than the bytecode-interpreter call sites already hit twice (Scouting Report §6/Team Roster), it could be a more tractable trace target for the exact consuming opcode this issue is asking about; (2) even if the render path is just as complex, it's a much faster way to bulk-collect live ground-truth Overall Ratings for future statistical cross-checks (no per-player stat-cycling required). Not traced live this session — flagging as a concrete next thing to try, not a finding.

[BreakableHoodie]

Checked the Trade Players screen as a possible easier trace target (see my last comment) — no shortcut. 0x096C29 ("Trade Player"), 0x096D14/0x096D32 ("RATING") all show zero xrefs, the exact same computed-dispatch pattern as every other UI render path already hit in this ROM (Scouting Report, Team Roster). Doesn't rule it out as a live-tracing target, but it's not statically easier than what's already been tried — a real negative result, not a dead end due to lack of effort.

[BreakableHoodie]

Real progress this session, though still open — narrowed the search space significantly and ruled out a plausible-looking lead by testing it live rather than trusting the static read.

Live-confirmed: the value is already final before the render handler even starts. Team Roster's Overall-Rating render was already known to reach the digit-print routine (0x0007D154) from a call site at 0x0008562C. Disassembling around it shows that call sits inside a short handler starting at 0x8561C:

0008561C  movem.l (SP)+,{D0 D7}     ; restores D0 (and D7) from the stack
00085620  beq.w 0x0008562A
00085624  jsr 0x0007D258.l          ; primitive 5
0008562A  moveq #4,D1
0008562C  jsr 0x0007D154.l          ; digit-print (confirmed formatter)
00085632  jsr 0x0007C6E6.l          ; primitive 2
00085638  jsr 0x0007C810.l          ; primitive 3

Breakpointed 0x00085638 during a genuine Team Roster redraw (Vancouver, cycling Status→Overall to force a fresh render) and read D0 at each hit: 0x41=65, 0x3E=62, 0x2D=45, 0x47=71 — an exact, in-order match for Carson/Craven/McIntyre/Courtnall's displayed ratings, 4/4 checked hits correct. That means D0 already holds the finished rating at the handler's very first instruction, which is a stack restore, not a computation — so the real arithmetic completes before the 0x000854B6: jmp (a0) dispatch is even reached. That's a different, narrower target than the five-primitive chain (0x7C6D4→...→0x7C822) traced in earlier sessions.

A clean-looking static lead, ruled out by direct live testing, not just assumed. Immediately before this handler in ROM (0x000855E4) sits unambiguous, non-self-patching code:

000855E4  add.w D0w,D0w                    ; D0 *= 2
000855E6  move.w (0x34,A2,D0w*0x1),D0w     ; D0 = word at [A2+0x34+D0]
000855EA  ext.l D0
000855EC  divu.w #0x28,D0                   ; D0 /= 40
000855F0  cmp.w #0x64,D0w                   ; compare to 100
000855F4  ble.w 0x0008562A
000855F8  moveq #0x64,D0                    ; clamp to 100
000855FA  bra.w 0x0008562A

A per-player word lookup off the team struct, scaled by 40, clamped at 100 — exactly the shape a "sum weighted nibbles, compress to 0-99" formula would take, and it would've been nice direct proof of the clamp/saturation effect this session's issue #1 work already found indirect evidence for. But breakpointing 0x000855E4 directly across two genuine redraws found it never fires from this render path. Real ROM code, just not reached from here — recorded so nobody re-spends time on the same address without checking it live first.

Next step, concretely scoped: trace backward from the dispatch itself (0x000854B6) to its caller — that's where the stack push producing the final D0 value must happen, not inside the handler. Full writeup in FINDINGS.md §6.

[BreakableHoodie]

Quick follow-up to the comment above, same session: found the actual dispatch mechanism, but hit a genuine wall worth flagging honestly rather than pushing a 4th guess.

`0x000854B6`'s `jmp (a0)` is fed by a real PC-relative jump table:

```
000854AE lea (0xE,PC),A0 ; A0 = table base = 0x000854C0
000854B2 adda.w (0x0,A0,D4w*0x1),A0 ; A0 += word at [A0 + D4]
000854B6 jmp (A0)
```

Indexed by `D4` — not `D0`, which this session had mistakenly been reading (both looked plausible at the breakpoint). Read the table directly from the ROM (static, no live tracing needed): the first several entries land in a tight, plausible cluster near the handler code already traced (one matches a live observation exactly), but several other entries in the same 16-word span resolve to wildly distant, implausible addresses 20,000+ bytes away. Either the real table is shorter than assumed, or `D4` isn't a simple sequential category index.

"Trace the dispatch's caller" (my last comment's recommended next step) turned out to be the wrong framing — `jmp` doesn't push a return address, so there's no caller frame to walk back to.

This is now the third distinct sub-thread this project has chased on this exact question, each narrowing the target without reaching the arithmetic. Treating this as a natural pause point rather than a fourth guess, per this project's own "escalate after repeated attempts" rule. Concretely scoped next step, left for whoever picks this up: breakpoint `0x000854B2` (where `D4` is actually consumed), read `D4` directly during a Team-Roster-Overall redraw, and re-derive the real table entry for that index from the static read above.