Test Lab Proof History

TEST LAB proof history

Inventory-HUD TEST LAB line — 2026-10-05

This is a separate version namespace from the older room/materializer proofs below. Inventory-HUD v08 confirms room entry; v09 adds the synchronous pickup-bootstrap startup failure; v13 independently overwrites the still-called 0x800742E0; v14 restores its trampoline but retains the older startup failure and introduces the compacted HUD null-load allocation bug. v16 disables only pickup startup and Runtime-confirms room entry plus immediate Inventory hang. v17 used the wrong effective stage-resource address; v18 corrected two high halves and confirmed room entry/nine pickups but Inventory still hung. v19 confirmed the same with two live pickups and all nine resource records: 9→2 did not fix the hang. v16 proved the later manager/resources were unnecessary to reproduce it.

v20 — Runtime-confirmed bounded fix: exact v19 plus one word at ROM 0x00074F08 / VA 0x80074308, NOP → addiu a0,zero,0x1200. The user reports the TEST LAB Inventory hang is fixed. Static tracing shows v14's compacted ensure helper 0x800742F0 skipped size initialization on its null/first-load branch and passed the incoming label pointer to allocator 0x8006643C. The v20 delay-slot initialization restores the intended 0x1200 request without changing allocation ownership. Exact v20 SHA-256 3461ed86540d51881f5f7d1b45c17dee9113484889370c8af750b819a11b1daa, CRC1/CRC2 479EDF13 / E1BE6C34. A separate ordinary-item fifth font/palette argument forwarding defect remains Pending. Earth horizontal wall spikes are difficulty-gated on the bounded 2→4 test, not broken. Correct effective current-stage resource slot is 0x802E82B8. See exact binary comparisons, callers, and allocation trace.

v21 — Runtime-confirmed completed HUD proof: exact accepted v20 architecture with nine Power Upgrade pickups restored, ordinary-row fifth font/palette forwarding fixed, and the final Inventory status row changed to REQUIRED POWERS X/Y plus right-aligned XX/85. The user reported “Everything working.” Exact v21 SHA-256 1a39e51bcbac6c0ce35098ae3c5bade3387e1740850e34efb17474cd73d0e055, CRC1/CRC2 479EDF13 / E1BE6C34. Historical qualification: those exact v21 strings are retained here as artifact history, but they are not the final production wording. PR #146 mistakenly promoted the slash forms; deployed webapp testing exposed the known-bad / glyph. PR #148 restores the earlier accepted REQ. POWERS X-Y + CHKS XX-85 forms; the maintainer subsequently Runtime-confirmed the corrected production wording in a ROM generated from the deployed webapp.

v22/v23 — Runtime-confirmed rapid-Power closure: v21 exposed a dense-layout-only lifecycle edge: rapidly collecting adjacent Power pickups could prevent all later pickup interactions. v22 removed only the yielding white-flash wrapper and used the direct progression award; the user reported rapid pickup healthy, isolating the flash wrapper. v23 restores the accepted three-pulse feedback in one guarded asynchronous visual child while keeping the award callback non-yielding. The user reported it “worked perfectly.” Exact v23 SHA-256 09a87ca87fb6f81146bff45eeb6467644aa3bfca7b92f23a34cca3f8ff4dae3f, CRC1/CRC2 479EDF13 / E1BE6C34.

Scope: This page owns the detailed disposable-proof chronology for the hidden Fire God Room / selected-Test-Characters composition that became the MKMSZR TEST LAB, including the 2026-09-28 pickup-placement and cross-stage materialization stress line. Current product state remains on Project status; current materializer design remains on Global item materialization and solvability. These proofs are not production allocations or browser/CLI features.

Power Upgrade Herbs presentation — 2026-10-02

• v01 — Runtime-confirmed visual proof: TEST LAB placed ordinary brown Herbs beside the selected Ice Blue Herbs presentation. Both rendered and collected normally; the user accepted the Ice Blue look.
• v02 — Runtime-confirmed visual-feedback proof: built directly on accepted v01. Only the Ice Blue pickup wrapped its normal Herbs callback with the stock-eel-style player flash: white 2 ticks -> normal 2 -> white 2 -> normal 2 -> white 2 -> normal. The user reported the result looked fantastic. The proof imported no damage, reaction, stun, or input-lock behavior.
• Production direction: selected progression Herbs keep their stage-local Herbs model/resource, use stock-resident Ice Blue descriptor 0x800B1E68, and wrap the existing progression award with the accepted v02 white-pulse helper using an MKMSZR-owned copy of the stock eel all-white 64-color palette.

Current conclusion

Runtime-confirmed bounded result: the hidden room can be composed as a stable empty TEST LAB by reusing the healthy Fire selector-5 shell, selected-Test-Characters helper behavior, and suppressing the test-fighter allocation. The room supports normal lighting, HUD, movement, attacks, Pause/Inventory, ordinary pickup-manager execution, controlled pickup placement, and bounded cross-stage resource experiments.

The strongest current materialization result is v33:

• 15 simultaneous non-Earth key pickups enter the room without the Mission Objective corruption seen on the rejected 21-item line;
• Wind, Water, Fire, Prison, and Bridge families are present;
• native Fire icons retain stock animation;
• imported families use a low-RAM coherent static native frame chosen for recognizable width;
• the user reported all displayed items recognizable;
• Earth resource data may be resident in the resource file in some proofs, but direct cross-stage Earth-key rendering/award is still Pending;
• no universal safe simultaneous-pickup count is established;
• no 21-live-item composition is accepted.

The proof line also establishes a negative architectural rule: the destination stage's native resource-file architecture must be preserved. The custom standalone-gallery route from v22-v25 is rejected for this workstream.

Stable room construction

The successful room does not use native Stage-7 initialization as-is. Earlier Stage-7 experiments exposed missing lifecycle/setup behavior. The accepted proof composition instead keeps the healthy normal Fire selector-5 shell and uses selected Test Characters as a bounded helper route.

Key milestones:

• v06 — Runtime-confirmed positive control: stock Fire selector-5 composition enters cleanly, including the Fire God.
• v07 — Rejected: native Stage-7/debug-helper path reproduces the broken-control state.
• v08 — Runtime-confirmed bounded control restoration: normal lighting/HUD/controls/Pause/Inventory with selected test character index 0 and Fire-God stream suppressed; MONK1 death still hung.
• v09 — Runtime-confirmed bounded terminal correction: the MONK1 terminal route was redirected from the Fire selector-10 terminal choice to the native Stage-7 terminal helper; killing MONK1 no longer hung.
• v10 — Runtime-confirmed empty TEST LAB baseline: the selected fighter allocation JAL at VA 0x80065928 / ROM 0x00066528 was NOPed while preserving the healthy helper/common tail. The user reported an empty, stable room with normal controls and no hang. Disposable ROM SHA-256: 3a5bef3491daabd28a8610aba80521302117d8eb1d8e772be4b411ec216136d2.

The floating background amulet stopped spinning once boss-specific scheduling was removed. That is presentation-only and is not a TEST LAB functional blocker.

Pickup-manager bring-up and placement

Normal Fire selector 5 skips ordinary overlay entry 0x802ECE30, so it does not naturally install the ordinary pickup manager/resource composition used by standard Fire routes. The TEST LAB proofs therefore had to materialize file ID 0x3C and allocate an isolated class-0x19 pickup manager explicitly.

Rejected setup attempts

• v11 — Rejected / failed: overwrote parent +0x6F4/+0x6F8 without safe restoration; hung at Mission Objective after music.
• v12 — Rejected / failed: moved three stock Fire records but no pickup manager existed; no pickups appeared.
• v13 — Rejected / failed: patched an ordinary-overlay manager wrapper that selector 5 never entered; no pickups.
• v14 — Rejected / failed: coordinate changes could not matter while the manager remained absent.

Successful manager and visual controls

• v15 — Runtime-confirmed actor construction, visual failure: explicitly loaded Fire resource file 0x3C, published it through 0x802E82B8, saved/restored the parent controller fields, and allocated an isolated three-record manager. Three pickup actors appeared. Their external-resource-backed Potion/Formula/Extra-Life visuals were corrupted vertical strips. ROM SHA-256: 477f383a43c50f4cf343eefff320ad4b45825bebe13daa4533d47bfafec4bdb0.
• v16 — Runtime-confirmed embedded visual control: copied the complete stock Fire Herbs identity slice into all three test records. All three Herbs rendered correctly, proving the manager/resource composition itself was healthy. They were still vertically unreachable. ROM SHA-256: c35df94b1a8a95044c00981f81d9b236ca31f0ddb2d166dd594a71bbf91053b0.
• v17 — Rejected placement: an incorrect large fixed-point Y value moved the pickups out of the visible/reachable plane.
• v18 — Runtime observation / insufficient placement: keeping live depth and setting the third coordinate to zero did not fix vertical pickup reachability.
• v19 — Rejected placement inference: using 0xFFFFCA00 from the Fire-God actor conversion moved the items even higher, proving the sign/direction interpretation was wrong for this placement purpose.
• v20 — Runtime-confirmed calibration: three different values on record/actor +0x30 established the reachable neighborhood. The left Herbs at +128 world units / 0x00008000 was collectible; +192 and +256 were not.
• v21 — Runtime-confirmed pickup baseline: all three Herbs used +128 world units and 96-world-unit horizontal center spacing. The user collected all three successfully. ROM SHA-256: 7a70089478420ad5f1d8f56103336ed2a8a5b1047e949a0cff153d00849b8b34.

Later materialization proofs moved the row slightly upward to +120 world units while preserving the accepted 96-unit spacing.

Standalone-gallery experiment — rejected

v22-v25 attempted to replace the Fire resource representation with increasingly compact custom standalone galleries.

• v22 — Rejected / failed: 21 unique ordinary key/crystal visuals, expanded gallery 0xE4E8; hung at Mission Objective. ROM SHA-256: 83ee6bf0e95ceb2e419d8122801c09cf8e92f3c4ff4831240e51a6c10ee08b02.
• v23 — Rejected / failed: deduplicated compact gallery 0x98BC; same Mission Objective hang despite a 19.5 KiB reduction. ROM SHA-256: aa7d04294848106b0d7c4b6f124a434a2ba22495c55ebc50591c005137758959.
• v24 — Rejected / failed: deferred gallery installation until the Fire finalizer had written gameplay-active state 0x802ECE18=2, left ROM file-table entry 0x3C stock during entry, and reduced the gallery to one frame per item. It still hung. ROM SHA-256: 34abd5490a09942494c507b59aa3c0a07cf3b4ef2b063d2f9065540407b98300.
• v25 — Rejected / failed: reduced the same custom path to ten representative unique items; still hung. ROM SHA-256: b84a355f1487f54e13c9dc058d3287ddc95447adc0d147da82d3c518e20c71ed.

Conclusion: neither raw item count nor raw gallery byte size explains these failures. The common custom standalone-gallery representation/path is rejected for the TEST LAB materialization line.

Return to native Fire resource architecture

v26 — proven foreign-key control

v26 returned to the Runtime-confirmed v21 room and used the previously proven Fire→Prison Level-1-key materialization architecture:

• preserve the complete stock Fire resource-file layout;
• relocate/expand file 0x3C;
• populate stock-empty Fire selector 5 with the full Prison L1 key bundle;
• use the dedicated destination-safe proof callback that awards inventory ID 0x1A;
• retain two ordinary Herbs controls.

The room entered and the imported key rendered alongside the controls. This ruled out TEST LAB itself and Fire resource relocation as the cause of v22-v25. ROM SHA-256: 9a7411b356cd6d3c4c9ef0f39d8c9e54a39a101c1142059ad2dc9d3d01f26dae.

v27 — ten distinct items, Runtime-confirmed

v27 scaled the native Fire-file architecture rather than the rejected standalone gallery. It preserved Fire's native key selectors and populated stock-empty Fire selectors with full foreign embedded bundles. Ten distinct key/crystal visuals entered and rendered in TEST LAB.

The user reported the composition worked. The Fortress crystals looked visually wrong because their records were temporarily given the generic Fire-icon presentation shell rather than the Fortress crystal presentation pointer.

ROM SHA-256: 6d1eb8ba5d355b275caeb292e2545401813bef68b79815a2b7ac43c9a3aa8ffa.

v28-v30 — unsafe 21-item line

• v28 — Rejected / failed: all 21 unique ordinary key/crystal tokens were composed through the Fire-file architecture with a resource size of 0x8F0C. The emulator core reported Unknown SI DMA PIF address: 00000000; treat this as severe runtime corruption, not a normal gameplay hang. ROM SHA-256: 5cce9aca2086523525ec57a09f47796d1f396749f115b047179cf3a8577a61fe.
• v29 — Rejected / failed: reduced the 21-item resource to 0x4634 by reusing one image per imported item. It no longer produced the emulator-core crash, but hung at Mission Objective and the user reported music speeding up after several seconds, a repeated project symptom of memory/runtime corruption. ROM SHA-256: ddda99b32c3d01c4de950f6c90d0eb11186963460210cb6d9ea0ff3ab1040b02.
• v30 — Rejected / inconclusive actor-threshold test: kept the v29 resource bytes and instantiated only the first 15 records. It still hung, but those first 15 included all three Earth keys, so it did not cleanly isolate actor count. ROM SHA-256: c35a910aeafca8f4f311005dd21bad976c8cf200d9f110a2336c950686486b66.

No production or generic safety threshold should be inferred from 10 working and 21 failing. Resource payload, frame grammar, dynamic texture/render allocations, actor count, and stage-entry composition all contribute.

Fifteen-item non-Earth closure

v31 — Runtime-confirmed stable composition, corrupted art

v31 retained the same low-RAM 21-item resource payload but reordered the dedicated proof records so the 15 live actors excluded Earth:

• Wind ×3
• Water ×3
• Fire ×3
• Prison ×3
• Bridge ×3

Earth ×3 and Fortress crystals ×3 remained resident but uninstantiated. TEST LAB entered without the Mission Objective hang. Several imported pickups rendered as striped/glitched graphics.

This proves that 15 live pickups alone are not sufficient to reproduce the v29/v30 corruption on this route. It does not establish a universal 15-actor safety ceiling.

ROM SHA-256: 32e2ada08fc631a5aa8e6b970118ccf40a769b83b3342deef09c1db342d9ad23.

v32 — coherent static frame

The low-RAM importer had reused each item's first image payload while preserving later frames' metadata. That paired incompatible frame geometry/presentation metadata with one image and explained the v31 striping.

v32 repeated the complete first native frame — metadata plus image block — across the donor's original frame count. The corruption was removed, but most imported spinning keys froze on an edge-on first frame and looked like similar narrow slivers.

ROM SHA-256: 187eac6a3469dce698558c806e2049793f2634829dd2ef9144e76f8f3e9295e4.

v33 — Runtime-confirmed recognizable static presentation

v33 selects one static native poster frame independently per imported item:

1. maximize the first big-endian u16 in the native frame metadata, used here as the display-width discriminator;
2. break equal-width ties by larger native image payload;
3. repeat that entire selected frame — metadata and image — across the original descriptor frame count.

The user reported that all displayed pickups were recognizable. The three items still visibly animating were the native Fire-stage keys, whose stock selectors/resources were intentionally left untouched.

v33 resource size: 0x4BE4 / 19,428 bytes. ROM SHA-256: b09a254a173a77f2f41f60ccaa5c5a1f8c45d22dd8b858c2fab7bed75e53e0c8.

This static-poster technique is proof evidence / possible low-memory fallback, not yet a 1.0 product decision. 1.0 still requires the randomized pickup to visually represent its actual item; whether imported keys must retain full native spin animation is a separate presentation/capacity decision.

Earth boundary

Earth's three keys are ordinary logical pickups, but their native image-block framing differs from the convenient little-endian embedded-size grammar used by the generic non-Earth extractor. Their descriptors are normal embedded-data bundles with native frame counts:

• Earth Square: 12 frames;
• Earth Four Squares: 9 frames;
• Earth Triangle: 9 frames.

The stage catalog already owns exact Earth frame/image bounds. Some later TEST LAB resource files included Earth resource data, but no accepted proof directly instantiated all three Earth keys outside Earth. The next bounded materialization task is therefore a three-Earth-key TEST LAB proof using the proven native Fire-file architecture and cataloged Earth bounds.

No new deep Ghidra trace is required unless that bounded proof fails.

Earth-key closure — v34-v38

The first Earth-key TEST LAB attempt exposed a catalog/source error rather than a special pickup format.

• v34 — Rejected / failed: imported all three apparent Earth bundles from file 0x88; hung at Mission Objective.
• v35 — Rejected / failed: corrected pickup record +0x0C from Earth value 6 to Fire destination value 4; still hung. This correctly preserved destination-attached location metadata but did not address the actual visual-source error.
• v36 — Rejected / failed: kept all three apparent bundles resident but instantiated only Earth Square + Herbs; still hung. This ruled out live actor count and the other two Earth keys as the primary cause.
• v37 — Runtime-confirmed award / Rejected visual source: converted the apparent Earth Square Type-5 frame to a self-contained raw Type-0 image. TEST LAB entered, Earth Square and Herbs were both collectible, and Earth Square awarded correctly in inventory. The rendered pickup was corrupted and visibly contained MONK1 imagery.
• The v37 visual was the decisive clue: file 0x88 is the Earth MONK1 fighter resource, not the ordinary-pickup resource.
• Static stage-setup tracing then resolved the real ordinary-pickup resource as global file 0x30, file-table entry 0x000A5250, ROM 0x00305A30..0x0030A9FF. Earth setup publishes the allocated file-0x30 base through 0x802E82B8 before the ordinary pickup manager consumes selectors.
• File 0x30 selectors 0,1,2 are the real Earth Square / Four Squares / Triangle visuals: 8 native Type-4 embedded frames each.
• v38 — Runtime-confirmed Earth donor closure: imported all three real file-0x30 Earth key bundles into Fire selectors 5,6,7, with one untouched native Herbs control. The user reported the result “Perfect. Just perfect.” The screenshot shows all three recognizable Earth symbols plus Herbs, and inventory shows the tested Earth key awarded correctly. The proof uses the native eight-frame Earth descriptors; animation cadence itself was not separately instrumented.

v38 disposable ROM SHA-256: db7431256a7ff7fdb95c71ce386db35ce102f32f5488df0113665f2b11757fb4.

Conclusion: Earth is not a special Type-5 pickup family. The v34-v37 failures came from using the wrong global file. Earth is now Runtime-confirmed as a normal cross-stage ordinary-item visual donor family at the bounded v38 scope.

Production implications

The TEST LAB line changes the implementation guidance for the global materializer:

• preserve the destination stage's native resource-file/table grammar;
• distinguish logical selector capacity from physical payload storage;
• use stock-empty selectors only as selector indices; relocate/expand the file for payload bytes;
• use extension selectors where stock selector capacity is exhausted;
• normalize external-resource-backed visuals to self-contained embedded form where required;
• deduplicate only when descriptor/frame/data semantics remain coherent;
• never reuse an image payload with incompatible frame metadata;
• budget the loaded resource together with dynamic pickup actors, texture/render allocations, stage-entry temporaries, and other arena users;
• do not treat the clean-era allocator-headroom number as a per-file safe budget;
• retain explicit negative controls for corruption symptoms such as Mission Objective hangs, music-speed anomalies, and emulator-core DMA failures;
• keep Earth as a separate donor-family runtime gate until its cross-stage proof passes;
• keep checkpoint suppression, foreign-key inventory masking, Fortress boss-reward trigger ownership, and Temple Map behavior as separate composition gates.

Related owners

• Stage flow and selector — hidden-stage/Fire composition and TEST LAB route.
• Global item materialization and solvability — current materializer design and 1.0 gates.
• Memory and allocation map — ownership and runtime-allocation safety.
• Stage catalog — Fire and Stage catalog — Earth — stage-specific selector/resource facts.
• Experiments, failures and superseded findings — rejected approaches index.
• Runtime validation status — concise evidence matrix.

Remaining-key no-checkpoint proof v01 — Runtime-confirmed

This bounded proof was added after the 1.0 key policy was clarified explicitly: collecting a key/icon/crystal must not create a checkpoint.

Nine pickups were instantiated in the stable TEST LAB harness, left to right:

1. Water Triangle
2. Water Three Bars
3. Water Moon
4. Earth Square
5. Earth Four Squares
6. Earth Triangle
7. Prison Level 1 Key
8. Prison Level 2 Key
9. Prison Level 3 Key

Each record used one destination-safe callback that inserted the intended inventory ID through 0x80075448 and played normal pickup sound 0x3B. The callback deliberately did not request checkpoint presentation through 0x80062D60 and did not write the respawn selector 0x802C18F8.

Runtime result: the user reported that no key created a checkpoint and that everything looked correct in inventory.

ROM SHA-256: d6b9fa9bb8db645968faca1243337fe94b33258efd9351eac89648a415c9016a
CRC1/CRC2: F1DF1662 / 130E7BDD

Scope: this closes checkpoint-free logical award behavior for the nine tested Water/Earth/Prison rewards. It does not synthesize Prison's native acquired/door bits inside TEST LAB; those remain destination/progression semantics to preserve separately in production wrappers. Native Prison L1 v08 remains the positive control that its credential bit can coexist with checkpoint suppression.