# The UI blend mode is on the disc after all — ✅ **DECODED**: `T8aD +0x04` bit `0x02`

**Status:** ✅ `CONFIRMED`, classification **decoded** — the field, plus a
disc-wide check and an out-of-sample prediction that could have died and did not.
2026-08-31.

> 🔴 **This reverses two of my own published conclusions.**
> [`t32-blend-mode-not-on-disc.md`](t32-blend-mode-not-on-disc.md) said the mode is
> *not on the disc*, and [`ui-blend-mode-measured.md`](ui-blend-mode-measured.md)
> classified it **measured** and told the port to read the table as per-element
> facts because *"which field selects the mode is still unknown"*. Both stand as
> honest records of what was known; neither is current. **The port can derive the
> blend for any element on any screen instead of transcribing a table.**

## The field

> **`T8aD +0x04` bit `0x02` set ⇒ the game draws that sprite ADDITIVE
> (`RB_BLENDCONTROL0 = 0x01010101`, src `ONE` / dst `ONE`).
> Clear ⇒ premultiplied alpha-over (`0x07010701`, src `ONE` / dst `1−SRC_ALPHA`).**

## Why the old refutation was wrong, and why that matters

[`REFUTED.md`](../REFUTED.md) killed this exact claim: *"`T8aD +0x04` bit `0x02`
selects an additive blend" → mine, and refuted. Blending those sprites additively
worsens every measure against the capture.*

**That refutation is a claim about our renderer**, which this corpus's own rule
calls a hypothesis under test — and at the time the renderer had a stale keyframe
association, no leaf geometry and no rotation. The claim was never tested against
the game. It is now, and the field survives.

📌 The lesson is not "the old test was sloppy". It is that **a negative produced by
comparing two renders inherits every defect of both**, and that a field can sit
refuted for weeks because the instrument that killed it was the thing under
repair.

## The evidence

### 1. The fit — 35 elements, three screens, zero errors

Every label is an `RB_BLENDCONTROL0` value read out of the guest command stream
and attributed by quad size ([`data/blend-bit-vs-oracle.txt`](../data/blend-bit-vs-oracle.txt)):

| | count |
|---|---|
| bit set **and** drawn additive | **16** |
| bit clear **and** drawn alpha-over | **19** |
| bit set but alpha-over | **0** |
| bit clear but additive | **0** |

### 2. The control — no rival field

A perfect partition on 35 elements is worthless if half the header partitions
equally well; that is exactly the mistake `+0x08 = 0x8050` was. So every bit of
the first twelve header words was tested against the same 35 labels:

**Exactly one separates them without error, and it is `+0x04` bit `0x02`.**
Nothing ties with it.

### 3. The within-pair case that no confound survives

| element | `+0x04` | drawn |
|---|---|---|
| `ptbtn00.t32` | `0x0110` | alpha-over |
| `ptbtn00f.t32` | `0x0112` | **ADDITIVE** |

The `PRESS Ⓐ` plate and its own highlight variant. Same screen, same bundle,
adjacent in draw order, differing in exactly this bit — and the game blends them
differently. Screen, archive, element family and draw order are all held fixed.

⚠️ And the obvious rival reading dies here too: `ptbtn01f`, `ptbtn11f` — other
`f` highlight variants — are `0x8130`, bit clear, and are drawn **alpha-over**.
It is not "focused variants are additive".

### 4. The prediction, written and committed **before** the capture

[`data/blend-bit-prediction-gp-options.txt`](../data/blend-bit-prediction-gp-options.txt),
committed at `bbd85e9`, said of `GP_OPTIONS` — **a different archive, an entirely
different element set, never captured**:

> *FALSIFIED IF: `po_menu_eff01/02/03` draw alpha-over, or any other `GP_OPTIONS`
> element draws additive.*

The developer splash was considered first and **rejected as a test**: both its
elements predict alpha-over, so it can fail but cannot discriminate.

**Result** ([`data/blend-bit-prediction-result.txt`](../data/blend-bit-prediction-result.txt),
[capture](../captures/ui-draws/blend-options-2026-08-31.log)): the game was driven
to `OPTIONS` and captured — 39 draws over 3 frames. **Exactly three additive quads
per frame, and they are `po_menu_eff01`, `po_menu_eff02`, `po_menu_eff03`.** Entry
19 declares 16 sprites, 3 predicted additive and 13 not. Zero errors.

## Reach, and what is *not* claimed

⚠️ **The alpha-over side of the `OPTIONS` test is a count, not 13 identifications.**
Draw 1 is a 20-index batch of tiled 320×360 background quads, a size several
elements share. What is measured there is that **no draw on that screen carries
`0x01010101` except the three**. That asymmetry is the right way round: the
prediction would have died on a fourth additive draw, and there was none.

⚠️ **Two blend states, not a general mode field.** Every UI draw observed on four
screens is one of `0x01010101`, `0x07010701`, or `0x00010001` for the one
non-UI blit that opens the frame. The bit chooses between the first two. Nothing
here says what a third mode would look like or whether one exists.

⚠️ **`src = ONE` in both states.** The fixed-function stage multiplies the pixel
shader's output by 1, so whatever alpha weighting happens is the shader's. This
says nothing about whether `.t32` texels are stored premultiplied; the shader is
unread.

⚠️ **Untextured primitives (`.prm`) have no `T8aD` header**, so the bit cannot
speak for them. `pteff00.prm` and `pteff02.prm` are observed alpha-over; that is
a measurement, not a decode.

📊 **Disc-wide population:** the bit is set on **4 995 of 14 709** sprites (34 %),
so it is not degenerate in either direction. Prior work established separately
that it is **not** "the name contains `eff`" (`P(eff|set) = 0.468` against
`P(eff|clear) = 0.144`) and **not** premultiplied-alpha storage — both refuted
disc-wide, and both remain refuted. Those were readings of the bit's *meaning*;
this is its *effect*.