Falsified RE readings - do not re-walk

Plausible: a content scan for "starts at zero, climbs to 0x1FF, 2048 halfwords" matched it, and the overlay leaves do index a 2-byte table by Z >> 5. But that table is the curvature buffer behind gp-0x2BC, allocated at run time by FUN_800271A8, and the leaves add it to SY. From file 0x5FCC8 the SCUS ramp is round(atan(k / 2048) * 2048 / pi) to within 1 for all 2049 entries: the arctan LUT FUN_80019B28 (atan2) reads at 0x8006F4C8. The world-overview "fog" toggle mixed toward a hand-set tint by it at under 4%, which is why it looked inert (world-overview-viewer.md).

Plausible: the word sat in an overworld actor's tick slot in one capture and +0x74 holds a colour. Its only reference is a jal at 0x801E450C inside FUN_801E4470, the tick of the op-0x34 sub-1 attached light; +0x74 / +0x88 are the light pool's two colours, and 0 of 98 states hold the word in RAM. It was already live as field_actor_billboard::attached_sprite_script_tick.

Plausible: the emitter reads its colour from that scratch word and sets no far colour itself. 0x1F800398 is RGBC, rewritten per frame from 0x8007B7B0; the far colour is SetFarColor(0x100, 0x100, 0x100) at 0x801F729C. The fitted value near 0xEF was low because a bucket is keyed on the cell's farthest corner while IR0 reads corner (x1, z0) (inference).

Plausible: two resident overworld states held two different pitch / depth pairs, and the top-view controller has a zoom input. The overworld is a mode-0x03 field-run scene; on all three resident overworld states the live camera words equal the zone composer FUN_801DAB90's staging descriptor at 0x801F3580, and the two "anchors" are two region records' compositions (world-map.md).

Plausible: the arm is named for the ocean and lives on the kingdom path, so a ladder into map01 looks like the way to enter it. All three retail kingdoms ship a slot-5 table, and all three install the CLUT walker; only a modified or damaged disc reaches the fallback.

There is no slot-4 → cluster-A converter. The cluster-A pool (DAT_8007C018) is filled exclusively by FUN_80026B4C, reached only from FUN_8001f05c case 0x02 (TMD pack) and case 0x09 (bare TMD). Slot-4's type byte is 0x05, whose FUN_8001f05c case merely allocates the MOVE buffer _DAT_8007B888 and never calls FUN_80026B4C. So slot-4 bytes never become cluster-A TMDs; the DAT_8007C018 kingdom entries are the scene's own type-0x02 field-file TMD pack(s), installed by the single FUN_80020224 descriptor-walk.

Visual inspection plus the slot-4 record-semantic work refuted the "world-map overlay outlines / coastline wireframe" interpretation. The replacement guess - "small object-local 3D meshes" - is falsified too: slot 4 is the scene's animation bank (below). Treat any future "kingdom border lines" claim with suspicion.

Plausible: every tree / prop cell carries both bits, and the one family the walk-bit sweep wrongly admitted (record 408, a wall down every river) happened to lack flag 0x2, so a flag test "fixed" it. But the resident kernel (FUN_801F69D8, PROT 0901, andi 0x2000 at 0x801F6ECC) tests only the draw bit, never +0x12 & 0x2 - and the big enterable mountains sit on cells with 0x2000 and no 0x1000 (the mesh is the ground there), so the walk-bit sweep drew every tree and dropped every mountain while looking complete (world-map.md).

Plausible: the resolver is the routine that turns a model id into a pool pointer, so the id space's one discontinuity looks like its business. It does no splitting. Two callers do - 0x800393B8, and 0x8003A2DC inside the placement installer FUN_8003A1E4 - each picking DAT_8007B824 or the scene base DAT_8007B6F8 before the call. A port tag naming the resolver for the split describes a routine that never sees the fork.

Plausible: the registrar is the only routine that installs an entry, and every install path does go through it, so "only writer" and "only installer" predict the same thing everywhere an install happens. 0x801CF1E0 in PROT 0976 stores a zero into a slot without it. A liveness rule that enumerates the registrar's calls therefore has a hole exactly where a slot was cleared rather than filled.

Plausible: the rays differed between retail's two framebuffers, and the battle draw does deal rand() words to jittered rings. The rays are a library-mesh part whose program never moves it (record 0x801F5628); the two buffers hold the same fan under two camera depths. Seating the part on the RAM's position and banks takes minigame_muscle_dome_retail_skeleton_hyper_arts from .874 to .980 (settled).

Plausible: the same disc, the same seat, another colour. In a retail recording's RAM the orb is the opaque POLY_GT4 0x3C, CLUT 0x76C2, page 0x0006, and the port's packet carries the same three. Record 0x801F9F2C's colour word 0x48000000 cues toward black, and its level walks 4096, 0, 1364, 2728, 4092, 4096 a frame at a time on both sides. The dark disc is an orb on 4096. Where the orbs and the additive glows (0x801F9E28, page 0x0026) stand is the arms' rand() scatter (cast-module.md).

Plausible: the Zenoir and Gimard films from battle_kor_spoon_strike lag in 0x34 while the solo-Vahn films do not. Retail's fade actor appears on the 0x34 entry pass in both fights with delay 0x14, which FUN_80020c14 drains by the frame step (lbu 0x393 at 0x80020C34). It ends 20 vsyncs after entry both times: 17 at vsync 966 to -1 at 986 in kor, 18 at 373 to 0 at 393 in the solo fight. The port's ends there too. The residual is the film's display lag on fade frames: --retail-lag 0 lifts the kor 0x34 segment from .437 to .802 (cast-sequence oracle).

Plausible: the index is the low byte of the entry's RAM address, the block "moves with the fight", and the first two fights measured read 0. The heap starts empty, ids load in ascending order (0x800543EC..0x800549F0) and each block is carved from the top of the free node, so the address is fixed by the seated count, the ids and the block sizes; 145 placements and 22 reads in 86 retail states match. Demon Fly's attack reads 209 (monster-animation.md).

Plausible: a measured window ran 22 vsyncs against a computed 20, and a 12.4 cursor has a fraction to carry. FUN_8004AD80 stores sh zero,0x68(s5) at 0x8004B068; the overrun is the pass grid - the cursor advances (step * speed * rate) >> 1 a pass (0x80047730..0x80047764), so the byte drops on the first pass boundary past the formula (battle-formulas.md).

Plausible: it sits in the commit beside the reaction-entry compares and reads the juggle byte, so it read as a timing window for a counter. The store it gates is sb v0,0x1f6(s1) at 0x8004B05C, and +0x1F6 is the cursor FUN_800508DC walks the entry's +0x54 cue track with; no damage or guard path reads it. (settled)

Plausible: its first half takes extents over the actor table, the shape a camera-bounds helper has, and it runs at the action seed beside the framing calls. The second half subtracts the box's centroid from each included slot's +0x34 / +0x38 and adds it onto the focus pair; the port that carried it as an inert event let a melee open off retail's ground. A retail position capture of the Cort fight pins the move (settled).

Plausible: the loader writes both words, and the battle draw's FUN_800495C8 reads entry+4 right before the pose decode. The words hold indices on 313 entries, and FUN_800495C8 walks the target as envelope keys plus [object, first_vertex, count] vertex-delta runs it blends into the mesh (0x800497DC); its sibling FUN_80049858 is the restore, not a second pose copy.

Plausible: a word-level sweep of SCUS_942.54 and every static overlay found only clears. The setter lives in a slot-B cast image loaded at 0x801F69D8, which that sweep never covered: lhu v0,0x16e(s0) at 0x801F8CF4, ori v0,v0,0x400 at 0x801F8CFC, sh v0,0x16e(s0) at 0x801F8D04. A negative over code images says nothing about the images it did not decode.

Plausible: it opens and closes like a pause-menu window. FUN_801D8DE8 ids index the placement table 0x80076C10, not the menu's descriptor table, and 0x41 / 0x42 share one record shape.

Battle tests > 0x800 (slti 0x801), the field helper >= 0x800, so the battle blend has its own kernel.

FUN_800480D8 raises it only around the after-image walk (0x80048258) and clears it before the body draw unless +0x5A == 7; a battle body's +0x5A is its pool slot (0..6), so bodies always cast a shadow and ghosts never do. Ported as body_shadow_skip.

The byte is the battle-load stage 0x8007B648; it reads 0xFF in 59 and 0x84 in 1 of 60 battle states, negative for the lb at 0x800470EC in all of them. The two misses remain unexplained.

Plausible: one status word per actor reads as one slot. The applier ORs into +0x16E at 0x801E173C; a tracker that overwrites makes the special-battle wipe rule's 0x38 test unreachable.

Plausible: most scripted fights refuse Run. The arm (0x801E070C..0x801E0788, PROT 0897) writes sys+0x8A, sys+0x94 and _DAT_8007B5FC and requests mode 0xE, nothing else; ctx+0x287 comes from the row's record[+0], and three 3E FF rows (the Rim Elm ambush, the Tetsu spar, deene row 11) carry 0.

Plausible: it zeroes gold. It is non-zero only in an arena leg and the two Ra-Seru-forbidden fights - a boss row leaves it alone - and it also zeroes EXP and suppresses drops, steals, absorb, spell XP and monster flee.

Plausible: the call passes 1. FUN_80048A08 passes a1 = 1 (0x80049234) and a2 = 0x18; the shape index is (a1 >> 3) & 0xF = 0 and the 1 is the plane. 73 of 73 captured shadow blocks reproduce as the ordinary shape-0 ring with inner radius 0.

Plausible: it sets semi-transparency bits on bodies near one point during actions. The point is on the camera's view axis - the focus pulled back by dist*25/128 along the yaw - and bodies within dist/4 go to blend 3; during a cast it ghosts the caster's side. A RAM replica matches 277 of 279 seated slots.

Plausible: it follows the knockdown and the files carry negative root speeds. Entries 7 and 8 have speed 0 in every file; the negative speeds are the knockdown's, the block's and some flinches'. Three states read a dead member at +0x1D9 = +0x1DA = 8, and no action-SM store names 7 or 8.

Plausible: the latch holds a downed body still. The tag-8 commit raises it (0x8004BF28..0x8004BF4C); the knockdown's own commit clears +0x1DC.

Plausible: the engine compacts monsters after the party. Retail's pool slots are fixed - monster k sits at slot 3 + k whatever the party size - and the resolver adds the literal (addiu a0,v1,0x3 at 0x801E73B8).

Plausible: the label sits over its monster on screen. FUN_801D9D3C reads lhu a0,0x34(v0) at 0x801D9E00 / 0x801D9ED4 on the monster's pool actor - world X, which the engine already had.

Plausible: templates B are stage meshes and the ambient runtime seats move-VM records. Template A's op 0x23 makes a draw-kind-4 node on FUN_8002A5A4's sprite arm (a 0xA0-square quad stepping 16 cells), and FUN_801D4DF8 passes rodata addresses straight to FUN_80021B04, which the scene-stager-only ambient runtime never sees.

Plausible: ops 0x0D / 0x0F / 0x11 write them from operands like a tween seed. FUN_80021DF4's default motion block adds them into the depth-cue level, render scale and +0x7A (0x80022B18..0x80022B7C); under dispatch 3 the same words are the CLUT-cell HSV channels.

Plausible: a byte cleared at every round's start reads like a counter of rounds, and a census of sb ...,0x25 stores in PROT 0898 finds dozens. All but two store a GPU packet's u / v byte; the context byte's writers are the clear at 0x801DAB84 and the dead-slot sweep's bump at 0x801DAC2C.

Plausible: the refill at 0x801E3A20..0x801E3A64 is the obvious Attack x2 counter write and sits by itself at the end of the stream. The stage site's tail also re-reads record +0xF4 & 0x2000 and increments the byte at 0x801E37AC..0x801E37BC, but only when it is already non-zero (beqz at 0x801E37B4), which is what lifts it to 2 on the second pass (battle-action.md).

Plausible: the routine was known as the auto-combo assembler and its tail was undecoded. The store is the first instruction past the +0x16E & 0x404 veto (bnez at 0x801F0508), so it runs for every party slot the auto-fill arm takes; the art insertion tail starts at 0x801F0B4C (battle-action.md).

Plausible: 0x800 is the AP-Used-Down passive, and the pool arm spends the AP gauge actor[+0x154]. The routine's only andi 0x800 is at 0x801F0D00, inside the art insertion tail, and halves that tail's per-arrow Spirit cost (srl s1,v0,1 at 0x801F0D0C); the pool arm never tests the bit.

Plausible: the divide is the 0x66666667 reciprocal, which is /10 in its usual form. Here the high word is shifted by one more (sra a0,t4,1 at 0x801F0BB0), which makes it /5; the walk starts at bank record rand() % 5 + 0xB.

Plausible: the Miracle arm's li v0,1 pair sits there. 0x801EF5A8 is sb v0,0x28d(v1); the flag's sw v0,0x696c(v1) is the delay slot of the j at 0x801EF5B4. The head clear (0x801EED88) and the one reader (0x801E3840) were not on the old row at all.

Plausible: the credit reads actor[+0x1DF] behind an actor[+0x1DE] == 1 test, and a capture is the obvious reason a monster's slot would hand over an item. 0x801F138C is a mis-based print of PROT 0898's recompute_battle_order; +0x1DE == 1 is the Item category, and the refund returns a fallen fighter's committed item (0x801DAC44..0x801DAC5C).

Plausible: "reselect" reads as starting over. By 0x6E the forward walk has moved the cursor past the party, and FUN_801D32BC(1) steps one member back - the capture holds ctx[+0x13] = 1, ctx[+0x1F] = 1 on a one-member party.

Plausible: the port committed an art straight to its default target. 0x5A walks +0x1DD with Left / Right through FUN_801D8D00 (0x801D21D4..0x801D2268).

Plausible: the port drew it after every arts entry. It is raised once, from any command, when FUN_801DB81C equals the party count - so it followed no one's Magic or Item in the port.

Plausible: the steal table is per-monster like the drop table, and "steal" reads as an action a character takes. The roll lives in FUN_8004AD80's knockdown-end arm, and the latch it sets before looking at the killer means an action's first kill spends that action's attempt (settled).

Plausible: a byte scan for a store to +0x27 finds exactly one sb. The clear is sb zero, 0x16(s5) at 0x801E3A84 with s5 = ctx + 0x11, in the delay slot of the 0x1E -> 0x1F arm - a displacement no 0x27(reg) scan matches. A write-watch caught it going 1 -> 0 at the chain's end.

Plausible: the envelope has the banner's shape and timing. Arms 4 / 5 call FUN_801D042C; arm 6 only drains the backdrop and starts the load.

Plausible: the two wrappers are near-identical and sit next to each other. The stat each loads decides it: +0x168 (INT) in 801DD4B0, +0x158 (ATK) in 801DD6B4.

Plausible: the capture holds +0x21C = 1 on it and the body reads dark on screen. It is Lippian's own dark texture, drawn plainly, and the sweep's word has moved only two ease steps. The RAM holds it under the ghost's +0x08 = 0x83000000, node word 0x87808080.

Plausible: both run around the art commit, where a gauge would be re-armed. Neither touches the AP gauge's fields.

Plausible: the four raises in FUN_8004AD80 were found by a SCUS scan; the clear at 0x801E263C is a sb zero inside the overlay's banner tick, which that scan never read.

Plausible: the still's loader (FUN_801F6B24, PROT 0978) is traceable without its consumer. The draw is the contest hub's FUN_801D00F8 (PROT 0977); port engine_ui::ringside_backdrop (ringside-still.md).

Plausible: all six decode as clean 51 42 / 61 42 arms in shipped carriers, and a flag-writer census cannot tell a story beat from a menu row - same opcode, same operand. Four are rows of a developer flag-setting menu: rikuroa P1[10..12] is a nine-flag Set ladder with its mirrored Clear ladder, and dolk2 P1[1] / dolk P1[26] have the same shape. The story writers are rikuroa P2[50] and dolk2 P1[0].

Plausible: one arm does drain by that product, and a second that agrees makes it look like the band's rule. Each arm carries its own multiplier of the frame byte at 0x1F800393 - the product, twice it, or once it - so arms measured as "constant 4" and "constant 8" are 1x and 2x a byte that happened to read 4. A per-arm constant and a per-arm multiplier of a varying byte are indistinguishable in a single fight.

Plausible: twelve neighbouring arms in the band gate on a frame count, and a run that stops two ticks short of expiry looks like a gate firing. The arm tests nothing; the countdown runs out. The image's real fault is a different arm walking the actor table past a one-monster seat fill.

Plausible: every other healing module routes through the band's one heal fold, so a module that also has the amount looks like a caller. Vera stores the restored HP in its own tick as well, so a port that runs both applies the heal twice per frame. With a single owner, amount = 0 on the fold's side is correct, not a missing value.

Plausible: a pointer arriving in a saved register does defeat the lui/addiu recovery, and the image has no record the parser can bound - "the parser cannot see it" and "there is nothing to see" predict the same output. Both sites sit in 0952's inherited tail and their pairs resolve to 0x801F8348 / 0x801F836C - two of PROT 0951's records, past 0952's own image end. 0952 has no band because it has no records.

Plausible: [i16 model_sel][u16 ?] is the shape of a record header, and a halfword beside a selector reads as flags. It is zero in all 1027 of the band's records and nothing on the disc reads it.

Plausible: the block's two exits do reach the same tail. They are beqz 0x801E6158 and bnez 0x801E6168, and their not-taken edges are the tail's only entry - which matters because the second gate reads the byte 0x801E6210 / 0x801E6214 increments. The LATCHED verdict on the block stands.

Plausible: it takes a small packed argument and is called from the Baka Fighter round SM, where a positional cue would fit. It blits a 6 x 0x18 VRAM RECT from (0x340 + (byte0 >> 2), 0x80 + byte1) to (0x340, 0x86) through MoveImage - the same error class as FUN_80058490: an id-shaped argument into a graphics routine.

Plausible: the 0x200 bit's SCUS writers key on the first enemy monster id, the dome ladder tops out at monster 0xAA, and FUN_801D0088 writes only the low byte - all true, and not the whole writer set. FUN_801CEA6C seeds the word itself - 0x101 / 0x111 / 0x321 over a zero at 0x801CEBA0 / 0x801CEBB4 / 0x801CEBC8 on story flags 0x536 / 0x537 / 0x538, last match winning - so retail bars Item on every seeded course and crosses out the Ra-Seru chip on the top one. Enumerating one bit's writers is not enumerating the word's.

Plausible: every other dome command is an AP spend, and the pennant geometry is linear in AP cost. The cast path 0x801D1408..0x801D1528 writes +0x1DF[0], +0x1DE = 2, +0x1E7 = 9 and phase 0x46 and touches no AP field; the cost is the spell table's +3 byte discounted by the record's +0xF4 bits.

Plausible: the two known whole-row bodies both clamp, so "whole row" and "clamped" look like one property. Three tick bodies - 0x801F726C, 0x801F69EC and 0x801F69D8 - sweep the whole row with the kill-capable shape A.

Plausible: an out-of-range phase index looks like a terminal state. The saved register is seeded 1, and 0949's beqz at 0x801F6AA4 lands past the move s7,zero that would clear it, so retail leaves the body busy. The port returns Done on all eleven bodies as a disclosed anti-softlock divergence.

Plausible: 0955 is the module whose whole choreography is buffs, so it looked like the band's designated stat writer. Also writing +0x150..+0x16D: 0940 (0x801F78B8), 0942 (0x801F7D34), 0943 (0x801F69D8), 0945 (0x801F69F8), 0954 (0x801F6A58), and 0925 / 0956 at +0x16C only.

Plausible: a documented sentence named the address as remaining work, the shape a worklist row has. It is a latched arm the port implements as battle_action::done, and a five-form reference sweep over 84 images finds nothing that reaches the address.

Plausible: the cast-module page's per-entry verdicts say "data" for PROT 0903..0913 - but those verdicts describe each module's stager, and the 0x801CF4EC table's arms are a different routine in the same image. They are 3396..7260-byte ctx+0x279 phase machines with damage wrappers; ports seru_magic_ticks (0903..0908) and seru_magic_ticks (0909..0913).

Plausible: every other per-actor routine in the file takes the actor it acts for. FUN_801EED1C's character-id-4 arm reads actor_table[0] and writes actor_table[1], so a table built around the acting actor describes the wrong seat's stats.

Plausible: a 132-slot jump table with decoded arms at the bottom reads as a large opcode space with an undecoded upper half. The table at 0x80014FA0 has 15 distinct targets, and 116 slots point at the shared epilogue 0x800421A8. The only body above 0x0E is slot 0x82 (0x800421A0), the Incense window top-up (see the Incense row under field / locomotion).

Plausible: a head insert is the cheap implementation and would explain "newest first" in a menu. The party-slot learned-Arts list (+0x74D, selector 0x0B) and the displayed-skill list (+0x186, arm 0x80041FB4) both walk to an ascending position first.

Plausible: the routine sits beside the equip helpers and the block it indexes is eight slots wide. Its counter starts at li v1,0x5 and runs while slti v1,0x8, so it reads char +0x19B..+0x19D - the accessory ("Goods") slots only.

Plausible: the dump is named overlay_cast_curse_0943_801f7d34. The bytes are 0942's: an 876-byte four-arm tick for action 0x52 that writes the caster's +0x156 AGL base as record[+0x0E] * 3/2. A dump filename prefix is not evidence of which image a routine belongs to.

Plausible: the call sits in a teardown-shaped neighbourhood, and no corpus state has its gate up. The arm requires _DAT_8007BD71 == 0xFF - battle running; 0xFE is the ending state - and fires per frame while PROT 0920's effect budget is non-zero (123 hits on one victory ladder, all before the end signal).

Plausible: the fade template ramps black -> white, and the ramp's end colour reads as the screen's. The template is kind 2, and the fade actor's tick passes the kind as FUN_80024EE4's second argument, which the emitter folds into the draw-mode packet's ABR bits (sll a3,a1,0x5; ori a3,a3,0xe at 0x80024FB0) - the law the intro styles obey (abr == 1 white-out, abr == 2 to black). Kind 2 is B - F, so a rising ramp subtracts more each frame and the scene, result windows included, darkens to black.

Plausible: FUN_8003CE08(0x35) at 0x8004EECC in FUN_8004E568's results frame looks like a music start. It is the story-flag setter (DAT_80085758[idx >> 3] |= 0x80 >> (idx & 7)). The frame's only cue is FUN_8004FCC8(0x50) behind the level-up test; the hero's "fanfare" is a monster.snd voice clip streamed into slot 7.

FUN_801E295C addresses the context as s5 = ctx + 0x11 (0x801E2994), so its victory arm's sb v1,0x2(s5) stores (0x801E66EC, 0x801E6740, 0x801E6760) write ctx[+0x13], the seat the results sequencer poses (0x8004E5A4). A search for 0x13( offsets misses them. noa_levelup_banner's ctx[+0x13] == 0 is a fight Vahn finished.

Plausible: plain strikes read about .6 where casts read about .97, with ids missing on both sides. Dealt retail's queue, approach terms, ATK and hit words, most of the same recordings match cue for cue: the oracle.

Plausible: it reads +6..+49 while other lines read +1. It fires on the commit state 0x3D waits for, and that waits out the idle clip; the recording's cursor and the child's start apart (256 and 16), and the clip is the same: the oracle.

Plausible: the sting is the loudest cue on a strike, and the decompiled C flattens the fork into "grunt first, sting dropped behind its CD read". FUN_801EC3E4 selects one of the two on _DAT_8007BD84: zero takes the grunt at 0x801EEB44 and the re-read at 0x801EEB60 then skips the cue; non-zero branches over the grunt into the 0x10C path (bne v0,zero,0x801EEB70 at 0x801EEAC8). The word is an effect handle, zeroed by the battle-start sweep and the round reset and set only by PROT 0940's stager (details ↓).

Plausible: the call VA is fixed, and every slot-A overlay loads there. Every other mapped slot-A overlay and the title overlay carry unrelated bytes at the call VA and no JT at 0x801CE868, so op 0x2F runs only while 0897 is resident and battle-side move records cannot use it. The capture-derived _801d362c dumps (world-map / dialog / cutscene labels) are identical to each other; the 0897 static dump is a strict subset of them (Ghidra does not follow the JT flow). See move-vm-overlay-ext.md.

Plausible: a dump exists at that entry and its body is a damage roll. The overlay_0897_801f3894 dump is FUN_801DD0AC byte-for-byte under a double VA shift. The real state-0x3D callee FUN_801F3990 is a cast audio-cue dispatcher; spirit damage is state 0x3E's inline formula. 801Exxxx dumps are suspect too, not just the 0x801F band: 801f0348 and 801e23ec are aliased (the latter's reading drops all three initiative modifier terms); 0x801F1ED4 holds (verified from the 0898 image); 0x801F45A4 is unverified. See battle-formulas.md.

details ↓

FUN_8004AD80 resolves the staged raw anim index down two arms, and the party one (DAT_801C9360[slot]) carries the indices PROT 960 stages. The module's only monster-block touch is a hardcoded seat-0 write unrelated to the caster. details ↓

details ↓

details ↓

details ↓

0x80108EA4..0x80109550 is per-scene GPU primitive scratch, not a 24-byte stride navmesh. Pointer hunts find zero RAM cells pointing into the window. Real per-scene region / collision / event-trigger data lives in the field-file preamble (a count + u16 offset table + records - not the scene texture pack at block +4 (the former "field-pack schema", which is a container-formats::pack of TIMs); see field-pack); the collision grid is the +0x4000 MAP region; the encounter-record path lives at actor[+0x94].

details ↓

Plausible: a bare-VA catalog key aggregates every overlay's references into two top blockers. The two addresses host different code in different overlays (byte-verified: 80/228/124/308/1 B and 208/1036 B across 0897/baka/cutscene/debug-menu/fishing/slot/dance). They are tracked per overlay as overlay_<label>_<addr> identities; catalog ignore category va_aliased_overlay_local.

Plausible: the party gate is committed slot >= 0x11 ("an art is playing"), so "ring id = clip tag + 0x10" reads as the same idea. The anim tick stamps record[+0x77] + 0x10 (+0x87 == 1 forces 0x11); +0x77 is the attach-key byte, zero on almost every monster entry, and no idle entry on the disc qualifies. Gating on "a clip is staged" ghosts every monster through its approach walk and idle loop. When retail reads a record byte, port the byte, not the state that usually accompanies it (battle-action.md).

Plausible: the reroll loops are unbounded in isolation. Every reachable caller state has an exit: the scheduler FUN_801DABA4 never seeds a dead actor (predicate +0x14C != 0 && !(+0x16E & 0x4)), the acting 0x380 monster is itself an in-band self-pick exit (0x801E73E8 clears +0x1DE), and a band with zero living members means the previous 0x5A already fired the wipe. The defect is downstream, in the 0x5A victory arm's roster indexing (battle.md).

details ↓

details ↓

details ↓

details ↓

details ↓

details

details ↓

details ↓

details ↓

details ↓

Plausible: the seat-0 write is the whole damage path in the three Delilas modules. The band splits: the capture-class ticks read the caster's own +0x1DF through the 0x801CF56C trampoline and clamp per victim, and two images apply damage to a row of seats. The rule is per-module, not per-band - cast-module.md.

Plausible: the sweep FUN_801F85A8 caps each roll at HP - 1 (slt at 0x801F8790), so it leaves every seat alive. The same image's tick 0x801F6A84 clamps with sltu against live HP (0x801F7E38), like every other capture-class tick, and kills. One routine is not the whole spell - cast-module.md.

Plausible: they are called stagers, they run from the move script rather than the phase machine, and "never kills" reads as "never damages". FUN_801F85A8 stores +0x14C -= roll at 0x801F87C0..0x801F87C4 and FUN_801F8D64 at 0x801F8F68..0x801F8F6C, each behind a wrapper jal (0x801F8758, 0x801F8F08). PROT 0966's loop is bounded by ctx[+0] from actor_table[0] (0x801F8FB4..0x801F8FC0): the party row, not the whole table.

Plausible: the victim-side writes are all ori or literal stores. The caster-side stage is lbu / addiu 1 / sb beside the +0x1DA store - 0x801F7364..0x801F7374 (PROT 0903), 0x801F71AC..0x801F71C0 (0904), 0x801F6F50..0x801F6F60 (0906), 0x801F77D8..0x801F77F4 (0908). The byte carries flag bits on a reacting seat and a restage bump on a casting one.

Plausible: the arms compose exactly as two bits would for the values the game writes, and 0x400 is 0x100 below the default the reading assumed. FUN_801D5854 tests equality (0x801D6510..0x801D6540), so a value above 3 does nothing, and the arm stores TR.y = 0x400 outright (0x801D6564..0x801D6568).

Plausible: it sits beside the counter latch _DAT_801F6970 and moves once per turn. FUN_801E295C zeroes it at 0x801E2ABC and 0x801E2E08 and increments it in the turn-seed arm (0x801E2C24..0x801E2C38); its one read in the dumped corpus (0x801E2B9C) is a zero test that picks a camera yaw step.

Plausible because variant 1 is a 0x800 yaw and a per-action camera that yaws would naturally also roll. The byte is two independent bits, not an enum: bit 0 adds 0x800 of yaw and bit 1 adds 0x80 of pitch and drops TR.y by 0x100. Nothing in the arm writes a Z angle. See battle-action.md.

+0x16E is where every other per-battle affliction bit lives, so a "Spirit is halved" bit reads as belonging there. It does not: the halving is passive 0x2B (AP Used Down), an accessory bit in the persistent per-character ability bitfield at record +0xF8, tested at 0x801EF364 in the queue builder and again by the status panel at 0x801D4520. A per-battle bit could not survive the save, and this one does.

The chain is real and it is the monster-special damage path, so a dome swing entering it looks like the answer. What travels is an index into the move-power table, and the dome's four direction commands map 0x0C..0x0F to row 0, whose power bytes are zero - the chain would deal nothing. The dome resolves its own exchange; see minigame-muscle-dome.md.

The census that produced the exception was over shipped monster names, and no shipped name happens to carry ^H; absence from the corpus read as absence from the encoding. The escape decoder has no special case: badge index = letter - 'A' for the whole 0x8B..=0x92 strip, and element -> caret is the fixed permutation [4, 3, 0, 2, 1, 5, 6, 7]. Parser MonsterRecord::plaque_badge.

The acting-actor plaque top-left reads Gimard, the pill readout is Vahn at 154/180 after DAMAGE 16, and the states' loader-B id is 5 (PROT 0900, the move-FX module), not a stager. A party summon draws no label (and no readout while its seats are hidden); its frames are the *_summon_mid_cast states. Reading these two as the player-summon reference put the enemy's chrome on the player's cast.

No store in it reaches HP, MP or a target; it writes +0x1E0..+0x1E2 (9, 0x12, 0xFF) for any id >= 0x25 and copies an overlay anim-pair list below that. The outcome is the streamed module's - the summon stager's strike for a Seru id. details

The summon band calls it with 0x12 every frame of 0x33 / 0x34 while the caster's +0x1D9 reads 9 (gimard_summon_start); the clip stage is the SM's own +0x1DA store at 0x29 / 0x2A.

Those are the rolled arm swings a basic Attack queues, and a retail mid-swing Attack state reads the same band. 0x1A..=0x2D - the per-art camera's band - is reached by action-constant queue bytes, i.e. an arts chain, so the camera not arming on two arm swings is retail. details

The 60-70 frames a sample shows is one action's countdown plus the HP-bar settle freeze; a multi-action sample sums several of them. Counting frames in a band without splitting them by action reads a per-action budget as a park. details

The session is reopened only on a rejected resolution. What pins the cursor on screen is retail's own ctx[+0x6B2] box guard, which the port reproduces. details

Plausible: the formation is authored, so a home seat reads as the rest position. Two library states of one solo fight read the authored formation 1600 apart; two later ones read the same pair ~300 apart and both far off it, with every actor's +0x3C/+0x40 pair within ~110 units of its live +0x34/+0x38. The port commits the seat from the live pair at DoneCleanup. details

details ↓

Plausible: the tick's own extent holds no jal into the damage family and no +0x14C store. FUN_801F81DC is the applier - three jal sites in the tick, the wrapper call li a0,0x12 / li a1,7 / jal 0x801DD0AC at 0x801F8874, and the HP store at 0x801F8910. A function extent bounds the measurement, not the module.

Plausible: the phase byte is ctx + 0x279, and a census keyed on the displacement is exact wherever the base is the incoming argument. Most modules form the context pointer once into a saved register and store through that: PROT 0908 reads as zero phase stores this way and has six. Counting both forms, the eleven player-Seru bodies run 3..10 stores each.

Plausible: a census that windows each jal finds two shapes, differing in whether the clamp precedes or follows the store. A third caps at HP - 1 with an unsigned compare - neither killing nor healing - and all seven of its sites are tick bodies. Two of them park the roll in a saved register more than a hundred instructions before the apply, outside any window.

Plausible: every other body in the band stores the wrapper's return through its clamp unchanged. srl s1,s1,2 at 0x801F8898 rewrites the register the clamp and the stores use, so the applied figure is wrapper_return >> 2 - a live capture reads 427 from the wrapper and 106 into the victim.

Plausible: the arm rolls twice and ends in two different phases, so pairing the second roll with the second phase is the economical reading. The beqz at 0x801F7E04 tests the kill roll 0x801F8534; the confuse leg's sb 0xF,0x279(...) at 0x801F7E28 is unconditional. 0x801F853C only suppresses the victim writes, so a resisted cast still advances to phase 15 - captured twice as 13 -> 15.

Plausible: three summon ticks read it before an instant-death roll and force the resist when it is set, and 37 of 186 records carry it - bosses plus the Evil Fly / Death Wings / Demon Fly family. Its primary reader is the model upload at 0x801F1D0C, which widens the VRAM rect from 0x20 to 0x40 through FUN_80055468; the ticks borrow it as a "big model" proxy. A field's meaning is its primary reader's, not its most interesting reader's.

Plausible: the band's arms are overwhelmingly damage bodies, and an enemy Steal that also hurts is an ordinary design. Its outcome is an inventory consume through FUN_80042310 - against a party victim by rejection sampling over the 256-slot bag at 0x80085958, against a monster victim by rand() % 100 versus 0x80077828 + id*2, the table the player's Steal rolls on.

Plausible: 0x801F69D8 is the slot-B load base, six other images really do put a tick body there, and a table of code pointers disassembles. In 0943 the base holds the 0xB5 body's head table; the writer is the body at 0x801F6A04. Head tables are not pinned to the base either - 0943's 0x40 and 0944's 0x53 read 0x801F69F0, 0950's 0x5A reads 0x801F6A10.

Plausible: s0 holds the caster on entry and the stores are a short run of zeros. s0 is reassigned to 0x801C9370 at 0x801F7648; the blanked bytes are actor_table[3]'s +0x1EF..+0x1F3. A backward-only scan for the base misses a reused register.

Plausible: the word is zero before the arena runs and the seeding arms fire only on a set story flag, so the unflagged path reads as "leave it alone". sw $s2 at 0x801CEB8C stores 1, with $s2 loaded 43 instructions and three jals earlier. That is course 0 with no bans, not "no seed"; "every seed carries 0x100" holds for the three flagged seeds only.

Plausible: a scoreboard that lists its lanes in order and totals underneath is the expected shape. Retail's six rows are [lane0, lane1, lane2, the HP accumulator 0x801D1AC8, lane3, the running tally 0x80084440], at brightnesses [0, 1, 2, 0, 3, 3] - four steps, not six. FUN_801D1184 re-forms the 0x801D base into a different register between the product and the store, which is what mis-attributes the lanes.

Plausible: the capture half does load it - lbu a1,0x13(...) - and one rule for both halves is the tidy reading. The player-half sites bake the literal: addiu a1,zero,7 at 0x801F74A8 and 0x801F8880. The summon always occupies seat 7 on that half, so constant and field agree in retail and disagree once a port seats a summon elsewhere.

Plausible: $s5 is the battle-context pointer in most of the band, so lbu v1, 1($s5) reads as a context field. In this module $s5 is formed at 0x801F77B0 as 0x8007BD10, the present-party list, so the gate at 0x801F77E8 is DAT_8007BD10[1] == 4 - battle seat 1 holding roster character 4, the split-bag condition. PROT 0941 makes no access at +0x11; its context pointer is *(0x8007BD24). Read the register's own formation, not its usual meaning.

Plausible: the routine does compare a word against 2, game mode 2 is the scene-load mode, and the mode word takes that value across a load at the right moment. The compared word is gp+0x6AC = 0x8007B9C4, the pack's own load-state; 0x8007B83C is gp+0x524. The three-state reading of the arm depends on which word it is.

Plausible: the emulator pauses on an unmapped read with no module frame on the stack, in every post-turn state of the corpus. Both arms stage clip 0x0B, and SCUS's anim commit indexes the caster's spell-entry array with it, so a caster with ten entries reads its own name text as a pointer. Logging the access instead of pausing on it shows both bodies walking all five arms.

Plausible: the summon modules test it before their head cue. Its writers are the applier SM and two battle routines; the modules only poll it, so it is open by construction when a cast wants it. Nothing on the disc writes it from a tutorial flag, and a port that does silences the melee sting in exactly those battles.

Plausible: a one-second decay after key-off is what a wrong ADSR shift sounds like. The envelope is tick-exact - shift 0 linear is -0x4000 per tick, pinned against an independent model for shifts 0, 15 and exponential - and the dry SPU is silent four samples after key-off. The tail is the room: every voice is routed through a retail reverb preset the resampler installs.

Plausible: the mode-INIT core reset reloads it in the same breath as 0x1F800393, and at a steady 60 fps both bytes sit at small constants. 0x80055FBC writes it the literal 8 and nothing touches it per frame; 0x1F800393 is written every frame by the pacer, which picks 1 to 4 off elapsed time. Elapsed time is their product, so a countdown read against either byte alone reads as a constant multiple of the other.

Plausible: it is a separate entry with its own frame. Its arithmetic matches the shared kernel's non-summon arm instruction for instruction - driving both against one seat returns 251 against 251, so no capture separates them. FUN_801DD6B4 is the one that differs: a physical-stat kernel that bypasses defence.

Plausible: the move VM has a dense opcode space and both numbers fall inside it. They are entries in the battle action queue, a different id space with a different dispatcher; the move VM's arms at those numbers are unrelated.

Plausible: an absolute-address sweep over SCUS_942.54 and every overlay image really does find nothing, and that sweep is the instrument these questions are usually settled with. Every access to the byte is gp-relative, a form the word scan cannot see; the gp-relative sibling finds 14. FUN_801DA51C clears it at 0x801DA69C and raises 1 at 0x801DA6A8 off system flag 0x19, and battle latches 3 at 0x801E6D2C (settled).

Plausible: the arm's own exit store is the next state, so reading the store as the arm's identity is off by one. The jump table settles it: base 0x801CED44, the word holding the arm at 0x801CEE38, index 0x3D. The band is not spell-reachable: the Magic category arm sets the predecessor state only for spell ids below 0x65, which the player Seru block 0x81..0x8B fails, while the Item arm sets it unconditionally. Fifteen injected casts reach the arm zero times.

Plausible: the scans sit beside the action state machine, run per seat, and compare a per-seat byte against a small constant - a state enum by shape, with 4 = removed / done a state nothing writes. DAT_8007BD10 holds the per-slot roster character id: FUN_801DA34C indexes it and subtracts one to reach a character record. 4 is the AI-companion seat, so the term excludes a seat the player does not command (settled).

Plausible: every capture that catches it is a dome one, five differently-prefixed dumps of it carry the dome label, and its arms are the arms a dome round needs. The routine has exactly one jal disc-wide - 0x80047014 in the SCUS battle frame driver FUN_80046A20, with no test in front of it - so every battle frame steps it, and three non-dome battle states enter it hundreds of times over 700 vsyncs each. A routine named from the contexts of its captures is named after its callers (settled).

Plausible: 33 sites disc-wide form 0x180, none paired with y = 0. A textured primitive addresses VRAM through the packed tpage halfword, where the x coordinate is a page index - 384 / 64 = 6 - so the emitter's constants are 0x106 and 0x109, and no search for the pixel column can hit it. It is FUN_801D00F8 in the contest hub PROT 0977, an image that is not resident when the upload runs (settled).

Plausible: the address sits in a group of wiring rows that are retail-unreachable. Two lui materialisations and three branches reach it across PROT 0913 / 0927 / 0928 / 0934 / 0951. What blocks the port is image ownership - which module the code belongs to - not reachability.

Plausible: the banner's reader FUN_801E2524 and everything around it are overlay code, so the overlay is where a raiser is looked for. Every sb ...,0x28b on the disc is at 0x8004ADDC / 0x8004B774 / 0x8004B80C / 0x8004B87C. "Unfound in X" is a statement about where the search ran, not "no raiser".

Plausible: three stores of three constants in three arms of one routine read as a selection. 0x8004B774 stores 3 and falls through to 0x8004B7D8, which reads the queue-builder side array 0x801F6990 at 0x8004B804 and stores over it at 0x8004B80C.

Plausible: the four buffers are text, one per display slot, and the routine pairs with a panel opener. Resolving the pool strings its two arms copy and append (0x801F4C38..0x801F4CC4) gives a victory line with spoils, a defeat line and the two escape outcomes; the 0xC1 call returns an offset the roster arm then patches with a participant id, not a width. Every patch reads the first seat, so a per-seat reading of the caption ids is wrong too.

Plausible: it steps a seat index over living actors, which is what a turn order does. Its six call sites are the round reset 0x801D8910 and FUN_801D388C's cases 0x10, 0x11, 0x21 and a tail pair - command input. Initiative is the execution order; the command order is the slot scan. Port battle_cursor_pose (both directions; the backward step drives world::battle::member_step).

Plausible: the digit strips were the visible gap and the cluster sits in the same image. The anchors are anim_slot_install / delete over DAT_801DBF44, impact_effect_pair (FUN_801D4DF8), sprite_blit (FUN_801D65F8, a MoveImage), mirrored_sprite_pass (FUN_801D49E8) and editor_tick (FUN_801D4FC8); they need an eight-slot key array, per-action keyframe TRS and an actor pool, not digit art.

Plausible: the anchor names say "sprite" and the rows sit beside MoveImage blits. FUN_801D49E8 is the afterimage of a 3D fighter and FUN_801D6310 a 3D walk-on. The editor rows are unreachable on a retail disc and tagged REPLACED-BY (minigame-baka-fighter.md).

Plausible: the routine re-sums the container and reloads on a mismatch, so corrupting the container looks like the way to fire it. Four XOR'd words of the resident copy left the sum byte-identical (0x7BF74962): the words summed come back from VRAM through StoreImage (0x8005842C). Only VRAM at (0x180 + 0x40i, 0) or the boot sum at gp+0x6B8 can break it.

Plausible: each record carries its own item and chance byte, so a per-record roll is the natural reading. FUN_8004E568 rolls every seat but keeps only the last winner's item, a zero one included, and then clears the drop on rand() & 3 != 0 unless a seat reads 100 or Items Up applies - a lone 10% enemy drops 2.5% of the time (battle-formulas.md, settled).

Plausible: it returns a 1-based position in a per-character byte list gated on ctx[+0x25F + slot], which is what a command-token search looks like. The list it scans is the learned-spell list at +0x704 that FUN_801E92DC prepends to, compared as id - 0x80; the gate byte is the Ra-Seru marker; and its one caller is the killing-blow Seru absorb in FUN_801EC3E4 (settled).

Plausible: the byte is set only when a Seru is involved and the capture states sit next door. The Done band reads it at 0x801E6224 and calls FUN_801E92DC at 0x801E6234 to teach it; nothing branches to 0x68 on it. The absorb roll reads record +0x3E / +0x3F; the port's field is absorbed_seru (settled).

Plausible: it bumps the spirit gauge and sits in the state the table labels "Spirit - fire". The arm is taken on committed effect class 5 (0x801E3E80..0x801E3E88), the item class that extends the gauge for a battle, and what it stages is min(0x120, base * 7 / 5 + 8) plus a spirit bump; its (rand() % 2) * 2 camera draw is unconditional, so a port without the arm desynchronises every later battle draw (settled).

Plausible: they are short nudges in the run and spell-exit states, and the failed-run message wobbles the view. The words are the GTE rotation trio's pitch and yaw and the eye trio's Y (memory-map.md): the failed run (0x65) and the run's Done arm (0x50) turn the yaw 2 * step a pass, the escape backs the eye Z off 32 * step, and the spell exit (0x2E) snaps a camera left pitched past 400 back to pitch 0, eye Y 0x500 (battle-action.md).

Plausible: the rows sit beside MoveImage blits and a pair of copies reads as a mirror. The two words are the scene's type-0x05 / 0x0B clip banks the clip selector FUN_800204F8 reads, so every one of these rows drives a 3D model; +0x78 is a depth-cue level FUN_8001B964 reads at 0x8001BC7C, and the two copies are ghosts three and six frames behind the thrower (settled).

Plausible: the prototype record's +0x04 half is 0 on the disc, and FUN_80020DE0 copies it into the model word. The cabinet init stamps scene-bank base + 3 into that half at runtime (0x801CF2C8..0x801CF2D8), and a Triangle-held capture sees the spawn store at 0x80020E70 write 3: PROT 1203's fourth TMD, a ring girl whose cell blit is a wink. The earlier "effect-actor arc" reading of FUN_801D6310 falls with it (settled).

Plausible: three values on a move's lifecycle read as its phases. The resolver's arms require 1 before booking an exchange (0x801D36DC, 0x801D3730, 0x801D378C), the damage kernel writes 2 (0x801D3EB0), and a commit zeroes it; 1 means the winner's strike keyframe has been crossed (settled).

Plausible: several ids coincide with effect-script ids. FUN_801D8DE8 never reaches the pool spawner FUN_801DFDF0; the id indexes the placement table 0x80076C10, so raises such as 0x43, 0x4C, 0x0F, 0x52 and 0x59 are HUD elements, not spawns (battle-action.md).

Plausible: a learn is the kind of event a text line announces. The build loop marks every accepted art (0x801EF788) and the learn result only becomes queue byte 0x19 / 0x1A (0x801EF6F0); a 0x1A commit raises the NEW ARTS!! sprite banner. A "Learned X!" string has no retail source.

Plausible: the log disappears around the round's start. The flow tail table at 0x801CE948 calls the copy loops on steps 5 / 7 / 9 / 0x2A / 0x30 (out) and 0x2B / 0x31 / 8 (in); Begin exits without one.

Plausible: FUN_801DA34C reloads the record's string on the Attack confirm, and the review screen shows it. The fighter's swings come from FUN_801F0450's rebuild under ctx[+0x266 + seat] at every round's state 0x00.

Plausible: the label keeps its visual width. The routine truncates the instance letter and strcats the rodata string at 0x801CECA8 (0x801D9E60).

Plausible: walked back on the re-arm's widening share, zora_glare_petrify_pre's displayed TR z read worse than on the table's increment. The state calls FUN_801D5854(actor, 6) at 0x801E501C, right after it ramps ctx[+0x6D0] down by 16 * step; the zora miss was the endpoint the ramp moves, and the re-arm walk with that endpoint shift places both zora and battle_map01_gomboo_steal_mid_cast (retail-compare.md).

Plausible: the formation arm reads like battle setup. Begin sets flow 0xFE, whose arm clears ctx[7] at 0x801D3224.

Plausible: the band moves between the framebuffers and the packets at one of its pixels were cave wall. Rasterised whole, the tables carry it as textured ABR-3 packets of a mesh whose owner +0x230 names: the second monster's semi-transparent wing panels in battle_rikuroa_party_vahn_chain_open, Gala's body in battle_ropeway_party_vahn_slash_kick_mid, each with +0x08 = 0x83000000. It moves because the recover glide turns the camera 70 yaw a pass beside it (battle-actor-rendering.md).

Plausible: the capture is genuinely mixed content, and 0897 and 0899 share slot A's base, so short fingerprints and address ranges placed overlapping regions. Comparing every 256-byte block of overlay_title.bin with the PROT entries: 0x0E818..0x33818 equals PROT 0899 over its whole 0x25000 bytes except 33 runtime-written data bytes, no block matches 0897, and the other two sources are the tail of PROT 1053's stream at 0x00000..0x00D88 and PROT 0891's head at 0x08980..0x09180 (overlay-capture.md).

Plausible: it sits among routines a cutscene exercises. Its only reference is the move VM's op-0x2F arm; sub-op 0x2F (0x801D45D4) stores the frame-step floor, which is how opdeene's prescript installs its cadence of 3 (actor-vm.md).

Plausible: a pixel capture fits each scene's window and speed, and opdeene's lines measure about 18 px apart. The roller reads *0x801C6EA4 +0x4C..+0x52, which FUN_8003A024 resets and a CC F8 E8 op seeds before each block; the pitch is addiu s3,s3,0x10, and no retail store produces 18.

Plausible: the port's TitleOutcome enum carries an Options arm. The tick wraps the cursor with andi v1,v1,0x1 at 0x801DDC00 and the confirm branches on row 0 against everything else; retail reaches Options from the pause menu.

Plausible: two copies of one screen is a common host-drift shape. The defect is a single unframed draw: a bare session painted at a fixed pen that never reaches the framed screen.

Plausible: a three-form scan for stores to the mode word finds one for every other INIT handler and none for this one. The store is li v0,0x13 at 0x801CE8D4 and the store at 0x801CE8DC, inside 0x801CE844; the scan's corpus has to reach PROT 0902 to see it.

Plausible: 0x10 is a real mode on the path from boot to the title, so a trace that samples the mode word early sees it. 0x10 is one frame of logo INIT. The chain is six stores, each written by the handler that hands off rather than by any table's next field: 0x8001D5B8 -> 0x10, 0x801CEC94 -> 0x11, 0x801CF4D4 -> 0x16, 0x80025974 -> 0x17, 0x801DFC00 -> 0x02, 0x80025E50 -> 0x03.

Plausible: a dome fight is an ordinary battle under the battle mode. The dome hub - the contest screen between fights - is PROT 0977, sub-id 5, game mode 24, the OTHER-game mode.

Plausible: three of the four sit adjacent at gp+0x538 and gp+0x55C and read as one cleared block. The edge at 0x800161F4 also clears 0x8007B938; gp+0x564 and gp+0x494 are mode copies and are not cleared.

Plausible: the extraction index starts at raw entry 2, which the +2 label shift files as 0000_init_data, so the region looks unnamed. Raw entries 0 and 1 are CDNAME's init_data 0 / gameover_data 1. Arm 2 of PROT 0895's FUN_801CECD0 reads raw 0 (0x801CEDA8 / 0x801CEEF8); PROT 0902 reads raw 1 (0x801CE94C), and 98 retail field / battle / menu states hold none of raw 1's CLUT (boot.md).

Plausible: SCUS_942.54 never names title.pak, and the title art the overlay draws is fingerprinted to PROT 0890 / 0899. The string is FUN_8003E6BC's operand at 0x801CEED8 in arm 6 of FUN_801CECD0, on the dev side of the gate whose retail side calls FUN_8003EB98(2, ..); raw 2 is extraction 0.

Plausible: the screen visibly changes between a "press start" prompt and a two-row menu. Retail's 0x10 is a single state that polls the card, polls Start and runs the cursor; the prompt-vs-menu split is a port-side phase and is not retail's.

Plausible: the word sits behind a 0xFF-fill run, the two words after it look like constants, and the 28 that follow ascend without landing on a TMD. Read as a pack, 0x1D is the count, 0x1E is member 0's word offset, and the 28 are the other word offsets, each landing on a 0x80000002 header once multiplied by four; the fill is the preceding TIM_LIST chunk's pixels. The copy in raw TOC entry 1 is registered by the GAME OVER overlay through FUN_80026B4C (0x801CEA20) (effect.md).

Plausible: the bytes repeat on a short period. The consumer indexes (n + 1) * 10 and wraps on the last row's 'X' sentinel.

Plausible: the run is full of in-image words. They are eight-byte [i16 opcode][i16 window][u32 operand] instructions for the overlay's own interpreter FUN_801E9B3C, and the operands are what look like pointers.

Plausible: its donor routine's three spawn calls resolve to nothing when read at the call. 0x801F7F2C completes each pair in the call's delay slot; read there, they resolve to three of the donor's records, which the content-end cut drops.

Plausible: the shape classifier calls the window plausible_mips, and the image is a slot-B module outside the dumped band. The window is mostly another module's bytes, visible as such once the inherited tail is cut; disc-coverage.py reports no un-dumped code there.

Plausible: one run of in-image VA words after a string pool reads as one table. Two of the nine runs have a bound jr consumer (0x801EA9FC over 179 arms, 0x801EB558 over five). Nine is itself a run count, not a table count - see the twenty-two-table row below.

Plausible: both are slot-A images at the same base, and both sit in a CDNAME block whose labels inherit forward. 0970's own operands are the STR play loop's - the decode context at 0x801D19A0, the two slice buffers, the STRv2 VLC table - and 0981's are the world map's.

Plausible: the run is legible text with separators, and the text is Japanese in a USA-build image, which suggests a foreign build on top. The loop operands in FUN_801CED68 walk a fixed stride from 0x801CEF40, and 34 of the image's 37 SCUS jal targets land on this disc's function heads (a genuinely foreign image scores 0 of 42). Shift-JIS stored as LE u16 is evidence of an encoding only.

Plausible: each reading fits one property of the run - no prologue, no jr ra, no caller. The packer's buffer is indexed by file offset and never cleared, so a short entry ends in the previous image's bytes at the same file offset: the 1,760 bytes from 0x5920 are byte-identical to 0972 there. Byte accounting does not cut such a tail the way disc coverage does, so the run reads as this image's residue.

Plausible: the routine re-sums PROT 0x36C and compares against the boot-time sum at gp+0x6B8. It sums the VRAM read-back it is about to decompress from, not the pack the registrar walks; and the register-only arm never reaches it, because bne v1, v0 at 0x8001E974 jumps past the sum whenever the load word is 1. The gate's writers are what keeps the walk safe.

Plausible: the symptom shows on a rebuilt container, and "make the section bigger" is what a size-sensitivity test looks like. The LZS decode is length-driven by the descriptor and FUN_8001ED60 sizes the section-0 / section-1 buffers from the container header words at gp+0x69C / gp+0x6C8, so a header-byte-exact rebuild whose decoded size differs yields a truncated pack. No shipped patcher path changes that size. The producer to bracket is retail's own unclamped registrar over a battle-load pointer.

Plausible: a format that stores absolute offsets into a streamed container produces exactly that. The out-of-range offsets are measured against the over-reading entry-size expression; against the corrected extent every descriptor in all 102 tables lands inside its own entry.

Plausible: the battle loader does walk a flat [count][offsets] pack through FUN_8001FBCC, and the character pack does carry a second meta word shaped like an offset. The loader's constants 0x368..0x36B are raw TOC 872..875 = extraction 870..873, so the pack it walks is vdf (extraction 872), while the character pack is extraction 874 = raw 0x36C. And 0x2CBA0 is the sum of the descriptors' decompressed sizes (0xB49C + 0x41E0 + 0x1D524). See character-mesh.md.

Plausible: a 320-wide destination and a y-stepped upload is how the neighbouring int.tim family (0x4C7 / 0x4C8) loads. The measured upload is four LoadImage calls of 64x256 at x = 384 / 448 / 512 / 576 - texture pages 6..9 - keyed on raw TOC 0x36C.

Plausible: the three-file read is in the routine, and nothing in it is marked dev. The fork is on _DAT_8007B8C2 at 0x8001F87C, and retail takes the other leg: one FUN_8003E800 read of 0x28 sectors from 0x8001F9A4. FUN_800608F0, reached from the dev leg, is the break 0x103 host trap.

Plausible: the two hits sit close together in a window read as one entry. One is past 0900's real end and belongs to 0901 - the entry-size over-read. A sweep of 518,656 words across 84 images finds no reader of that displacement on a record[0] at all.

Plausible: the address holds no call, which is a clean negative. The call is at 0x801F78CC and 0x801F78D0 is its delay slot; three slot-B images hold one. The conclusion the negative supported happens to survive.

details ↓

details ↓

details ↓

details ↓

details ↓

details ↓

details ↓

Plausible: the entry really is 2 sectors. Only file 0x00..0xA28 is 0968's; the trailing 1496 bytes are 0967's bytes at the same file offsets, cut mid-string at the sector boundary, and nothing in 0968's own window references them - no jal, no j, no materialisation. The quoted structural figures span both modules. Full accounting on re-settled-threads.md.

Plausible: it is the only literal-word hit outside the shared-base band, so an aliasing argument cannot dismiss it. It is the SCUS global 0x80010390 holding the slot-B overlay load address, twin of 0x8001038C for slot A, read by FUN_8003EC70 and never written - it names the slot, not a tenant. The real callsite is not findable by constant: the stage-overlay parameter is computed (stage_id + 0x47), so 0x49 occurs nowhere.

Plausible: spell 0xB5 is Lapis Wave, and Cort is its caster. Formation 0xB5 is monster-archive 181, Cort. The byte the branch reads is *(u8 *)0x8007BD0C, the formation id array, and its guard is an HP-reached-zero test on the first enemy actor - a form-transition trigger, not a cast.

A first-visit intermission is koin1's own scene, with no primitive sampling a page at x = 384. Visits two and three of a dome run read latch _DAT_801D1AE0 = 1, hub arm 0x0A, level 8, with both still packets (tpages 0x106 / 0x109, colour 0x2C080808) in the primitive pool, emitted by FUN_801D00F8 in PROT 0977 (settled, ringside-still.md). Anchor kept: minigame-muscle-dome.md.

Plausible: five plausible TIM headers parse out of the region. The fifth sits inside logo 3's pixel data, where image data produces a header-shaped run. Counting parseable headers counts images only if each parse consumes what it claims.

Plausible: every count-4 and count-5 bundle in a small sample carries the FLAG slot last. Across all 105 descriptor tables the FLAG slot appears on 28, whose counts run 4 to 7, and in all 28 it is the last entry. The position is the rule, not the count.

Plausible: the run is smaller than a sector, sits at the end of the entry, and the pack's payload hashes identically to the standalone copy either way. The payload claim holds exactly: the pack's last member's TIM closes on byte 343,480, the same SHA-256 as 0456_urudre1.BIN. What follows is the packer's buffer, an earlier entry's bytes at the same offset (settled).

Plausible: nine runs of in-image VA words is what a scan of the bytes shows. Tables that abut with no pad word merge into one run; read off their dispatches - each sltiu bound times four - twenty-two bases tile the head, 850 arms.

Plausible: the bytes sit right after the last stream the walker parses. Byte k of that run is byte k of the nearest earlier TOC entry whose extent reaches k, for 80,337 of 80,337 bytes across 90 bundles, and the same holds for the lzs_container, pack and bse_bank tails. The donor need not be an overlay.

Plausible: every scene bundle's run fits its last sector. Searching the suffix over the whole entry reproduces 82 of the sibling rule's 83 cuts.

Plausible: the image has a real .bss hole just below, and the shape classifier calls the run plausible_mips. 0x801D0D58 is the quant packet (0x40000001), 0x801D0DDC the IDCT packet (0x60000000), and 0x801D0E60..0x801D0E9B fifteen DMA / MDEC register pointers.

Plausible: two sixteen-word destinations filled from a caller pointer look like a rect pair. They are the luma and chroma matrices of the quant packet behind the header at 0x801D0D58. Nor does it copy both packets: only the quant packet is written; the IDCT packet at 0x801D0DDC is static and is sent as is.

Plausible: a long zero run inside an overlay usually is .bss (0970's is). No instruction in any image forms an address inside this one; it lies between the save-menu atlas and the save-slot icon sheet.

Plausible: no literal pointer word names it. The module's own code forms each string address with lui/addiu between file 0x278 and 0xA7C.

Plausible: it holds across the cast band, which is why function extents there are recovered by frame matching. 0967 reaches its frameless leaf FUN_801F7628 by jal from 0x801F7184 and 0x801F7460.

Plausible: a byte comparison of the two matches. It compares 0901 with itself through the over-reading entry size; 0901's own content ends at file 0x252A, where 0900's bytes begin.

Plausible: 0x26B0 is the sibling rule's cut. 0901's code ends at jr ra on 0x24DC, and the run from 0x252A opens mid-routine on 0900's epilogue and is referenced only from 0900.

Plausible: the class is right and the bytes are unclaimed. Its prescript holds two records, below the standalone count floor, so a content-only walker refuses the entry; the loader reads the records positionally, and so does record_ranges_positional.

Plausible: a leading size word larger than the entry, with every object range inside it, reads as the prefix of a larger resource. On the corrected extraction all 182 entries that open with a type-0 chunk header and the TMD magic hold the whole chunk in their own sectors, and the class matches nothing (scene-bundles.md).

Plausible: the field pool's head is the five party / savepoint meshes, and the low ids look like a reserved band. FUN_80020f88 stores actor+0x64 = record[+0x10] + DAT_8007b6f8 with no id test (0x80020FDC..0x80020FF0), and live conc2 / concnow / rikuroa / retona actor lists hold records 1 / 2 at +0x64 = +0x10 + 5, drawn. The reading left conc2's archway double door out (field-locomotion.md).

Plausible: the routine does copy two short stack tables, and the old reading fits one small triple. The tables are SCUS 0x8007B3A4 = {3, 2, 3} and 0x8007B3A8 = {3, 5, 3}, and the old group 0 was Vahn's head, which read as an open question about his row. Live TMD groups in eight retail states follow the Ra-Seru bytes, both ways (character-mesh.md).

Plausible: 512 bytes beside the bag. The loop base is 0x80084140 + 0x1618, so it clears 0x80085758..0x80085958, the flag bank exactly; the shipped sites sit behind dev pickers (rikuroa P1[13]: "Clear all flags").

Plausible: the ladder report prints a parked pc for each scene. That pc is the entry script's, not the pad holder's. In korb3 the holder is P2[15], sign text at the picker seat (the first-visit P2[1] at retail's arrival tile); in edlast it is P2[1], a credits record of about 14100 vsyncs that ends on a held-pad poll. Neither is a port stall.

Plausible: a route round the beat bands, or a seeded flag, would skip the turn-back. P2[7] has no header gate and every arm pushes the player back out; a flood that avoids the beat bands reaches no second door from any of the four mouths.

Plausible: Circle is the port's cast binding and a confirm on many PSX screens. The cast start (0x801CF99C) and the power lock (0x801CFBA4) test & 0xC0; Circle appears only in the shared tail's abandon edge & 0x21 at 0x801D0318. The port keeps Circle as a port binding.

Plausible: the rows open the point-exchange screens. They copy the lure index _DAT_80084450 into the shared sub-screen cursor 0x801D90DC (0x801D0680); the port field keeps its old snapshot_points name.

Plausible: the port locked the pad only under a modal timeline, and a helper record looks like background work. The per-actor tick steps every spawned record with +0x100 through FUN_80039B7C, which holds the engaged bit the pad controller tests; being modal decides only the camera.

Plausible: two ops that each move an actor along one axis. Both land in one arm of the walk kernel FUN_8003774C (0x8003789C..0x800379F8): the axis pair comes from the table at 0x80073F14[b0 & 7], the rate is 0x80 or 0x40, and the budget is (b1 & 0x3F) * (4 << sel).

Plausible: it sits where the walk starts and names the player channel. It only selects the clip; the move is B7 F8 00 81, a compass walk of 16 vsyncs.

Plausible: the rung passes when keikoku P2[7]'s inner-doorway band is crossed. That record's first-visit arm ends in B7 F8 00 C1 at +0x12D - a compass walk one tile back - and the pass depends on playing it as a one-tick yield. With the walk played the run stops at (56, 28).

Plausible: it fires when an interaction engages and reloads +0x5C / +0x88 on every moving-class actor. It copies byte 0 of the actor's 0x801C6470 record - the standing move - into the requested-move pair, and FUN_8003BC08 runs the scripted VM before the clip consumer FUN_800204F8, so a walker mid-step asks for its walk clip again before the request is read. The engine's patrol pause during dialogue is its own choice.

Plausible: the arm skips on it and nothing in the motion ops writes it. FUN_801D79E8 rewrites it on every call - set outside the region box or the view window, clear inside (0x801D7B08..0x801D7B30) - and a write-watch sees both stores fire for every town01 placement.

Plausible: 0x1F800393 has been catalogued among the pad words. It is the per-frame tick byte, read by lbu 0x393 at 0x8003BCAC.

Plausible: the two dumps named after the address show glyph-cell calls and a digit field. Neither holds this routine: funcs/801d79e8.txt is FUN_801D6E18, and overlay_0897_801d79e8.txt starts mid-instruction. The real body - matching overlay_cutscene_dialogue_801d79e8.txt and the PROT 0897 image at 0x801CE818 - tests the region box and view window and writes +0x10 bit 1.

Plausible: no word or lui/addiu pair anywhere on the disc references their id-table slots. The table at 0x801F33B4 is indexed by value (FUN_801F159C, jalr at 0x801F1634 on +0x50): the pause-menu session FUN_801ED308 installs 0x29 / 0x2B from its phases 6 / 7 after a Door's Use screen returns code 4 / 5.

Plausible: the scan looks up a map number and prints UNFIND MAP NUMBER on a miss. FUN_80019788 returns 0x80088758, the count is 0x8007B806, and each 0x10-byte record is a scene name with its s16 define at +0xC; a retail image holds 125 of them, init_data through other7.

Plausible: from a cave the destination is next to the entrance. It is 0x80084628 / 24 / 2C, which the region record wrote - 0x55 @ (37, 109) in cave01, though the party entered from (37, 110) - refreshed by FUN_801F1278 at 0x801F12F8 when the menu button is pressed; the capture sees the triple change on that frame.

Plausible: the actor reads the scene name _DAT_801C6EA0 right beside the script call. The script is one op 5 (close every panel) and a terminator; the actor copies the name into _DAT_8007B44C for the save screen. The banner is the 4C E1 balloon FUN_8003AEB0 spawns at 0x8003BB40..0x8003BBDC, armed by system flag 2.

Plausible: the range follows the dispatch compare ladder. Arms 3 and 5 both branch past it (beq to 0x80022B80 at 0x800228A8 / 0x800228B0); arm 5 is 0x80021FB4..0x800226D8. The handler reading also runs the block for dispatch 3 whenever +0x9C is zero, which retail does not.

Plausible: a cold entry sets it, a post-chain capture holds it clear, and a probe watching a retail entry sees no set. P1[2]'s SET 0x619 sits before its first 0x21, so FUN_8003A1E4 runs it at each MAN-loading entry; FUN_8003AEB0 skips the spawn loop on a same-scene reload (0x8003B8A0). Re-running the section on every talk is wrong.

Plausible: read from a dump printed at the phantom VA 0x801C36AC. The timer half tags an actor and subtracts the frame delta; the landing seats the player once. 0x8007BDD8 is the clip base.

Plausible: four sw ...,-0x4228 stores sit together from 0x801D21AC. Three are in the hop phase machine FUN_801D2298 (6 / 7 / 1). The pad controller (0x801D0424..0x801D04A4) and the system channel (0x80039D94) also write it.

Plausible: the controller reads +0x5C as a gate and raises the bit on moving frames. FUN_800204F8 binds +0x5C as a 1-based record id and tests the bit at 0x8002053C to pick the party bundle.

Plausible: the pad controller is skipped for the warp, so the last clip it picked looked like it would stay bound. The system channel stores base 2 every tick at 0x80039D94, so the settle binds idle; a capture holds clip id 2 for the whole warp with Down held (field-locomotion.md).

Plausible: a locomotion capture held a run and saw the walk record throughout. It held Square and Circle; the run mask is 0x48, Cross or R1, and a watch under R1 or Cross sees base 3 and clip id 3.

Plausible: 0x801D5718 is a real instruction inside the sampler, so a citation at it reads correctly. It is FUN_801D56C4's row-index sll; the routine other images carry at 0x801D5718 is the battle image's placement landing copy, which copies +0x02 / +0x04 from src+0x0A / +0x0C plus +0x06, +0x0A, +0x14.

Plausible: advancing past the op keeps a script moving. A failed acquire branches to 0x801DEE4C (move s8,s4), leaving the PC on the op.

Plausible: the record's tail loops back over the acquire, and a refusing acquire leaves the caller halted. In retock_innkeeper_talk_open the cursor parks on the loop-back when the last page closes, and the next talk's acquire at 0x801E2148 succeeds (s7 = 5). 0x801E1ECC..0x801E1F54 is sub 0's arm, not this one.

Plausible: it gates the dispatcher's halted-target early-out, which a conversation needs skipped. Across both retock conversations it reads 0 on every sampled vsync; its writers set it only around a placement's spawn-section pre-run (SCUS 0x8003B73C / 0x8003B928, 0x801E2820 / 0x801E2BBC).

Plausible: the dumps carry different capture labels, and the world map reads like its own overlay. The world map is a subsystem of PROT 0897; the world_map, dialog and cutscene_dialogue dumps have one extent and the same calls (0x801D1470, 0x801D15B0, 0x801D16F4) - the player actor's tick.

Plausible: a native reference frame disagrees with the page. field_walk_host_parity.rs drives both hosts from one script to the same stop; the disagreeing reference came from a stale binary (inference).

Plausible: 0x3E with op0 >= 100 is a door and 0xFF a boss fight, so the remaining range looks like the talk case, and the pointer it stores in sys[+0x94] looks like a script. The arm reads op0 only at 0x801E06FC / 0x801E0704 to fork off the door-warp; the pointer is a MAN formation-table row, and the body ends in the reroll and the battle mode request. None of the ten non-0xFF sites opens dialogue (settled).

Plausible: +0x5C looked like a count and _DAT_8007B8F8 like a page count. The value lands in the word the clip selector FUN_800204F8 binds, the same arithmetic ends FUN_801D1BA0 on the player, and _DAT_8007B8F8 is the party leader, whose times-7 is the stride into the locomotion clip bank.

Plausible: a second allocation after a motion helper reads like a particle trail (the port routine keeps the name spawn_arc_with_emitter). The second template 0x801F22AC carries handler FUN_801D5D60, which clears the halt bit 0x400 when the arc lands and optionally runs the follow-camera ease.

Plausible: a probe run stalls that long without the write. Its !464 leg counts its own pokes instead of reading the flag, so after the battle's reload it pokes the trigger tile again, re-dispatches P2[4] over the running P2[5] and locks the player.

Plausible: the per-scene control-block reset zeroes _DAT_8007B450 and never touches DAT_801F35C0. The walk SM's state 0xE calls FUN_80017B94 on the cell buffer and the tile-actor table (0x801EFE78 / 0x801EFE88).

Plausible: the records are player-raised and sit next to talk scripts. All ten sites run before the record's first 0x21 park. A run that seats only one of three controllers is a port defect - a channel stepper that moves the channel list out while a script runs makes every cross-context id resolve to nothing - not evidence of a press.

Plausible: pokes made while the player is locked fail, and a crossing under the lock is consumed, not deferred. A poke after the lock clears dispatches P2[4] at once, and korb2 -> kor -> korout -> map03 -> doman crosses by pokes alone. The 0x6C4 writer is P2[8], not P2[4] / P2[5].

Plausible: index 7 lands on the player. +0x00 is the free-stack top, +0x04..+0x24 seven list sentinels written by FUN_8001E1B4, +0x1C the player (written by field MAIN_INIT at 0x801D6D7C), +0x28 on the 143-entry free stack.

Plausible: each moves the actor toward something, and a one-axis reading produces plausible walks. The step comes from the compass table at 0x80073F14.

Plausible: the camera path reads it every frame. PROT 0901 restamps its low two bytes at 0x9A0..0x9AC on the world map, which a camera word would not survive.

Plausible: outer nibble 1 advances s8 by seven in its own prologue, so every arm under it looks fixed-width. The 0x14 arm at 0x801E0E80 reads lbu a0,6(s6) and exits j 0x801E3624 with addiu s8,s8,1 in the branch delay slot, so the eighth byte is consumed even when the source id resolves to nothing. A seven-byte executor desyncs 94 sites in six scenes from their first occurrence (the disassembler decodes eight, so listings never show it), and 0x08 is not an opcode the VM has an arm for.

Plausible: FUN_8003CF40 takes an actor list and a handler VA, the shape of a registration API. The routine walks the list and ORs 8 into +0x10 on every match - a retire sweep that writes nothing else - and the shared exit 0x801E2DC4 carries addiu s8,s8,2 in the call's delay slot, so the advance has already run. Fifteen scenes issue 4C 9F, 140 times; a parked reading strands every one.

Plausible: the two arms are the same five instructions. The VA each forms differs - 0x801E2548 forms LAB_801DA930, the floor-height-ladder oscillator, and 0x801E2284 forms 0x801E5154, the reflection controller's tick. Reading 4C 87 as a ladder retire attributes a scene's mirror teardown to an elevation LUT.

Plausible: the spawner's argument order puts the executing context first and the resolved actor second, and six s16 into consecutive halfwords read as a transform. The tick decides which end is which: FUN_801E5154 loads +0x90 into a3 and +0x94 into a2, reads a2 and writes a3. The named actor is the source, the executing script is the image, and the six words are the controller's mirror line and tracking rect.

Plausible: a reference scan for 0x801F2950 finds nothing. That is the descriptor's handler word; the descriptor base 0x801F2948 is materialised at 0x801E5780 by an ordinary lui/addiu pair. Scan for a table's base, not a word inside it.

Plausible: the bit is set on exactly the contexts a player-facing beat runs in, so "this context is the player" gives the right answer wherever one actor is involved. Every shipped 4C 86 sits in a player-raised talk record naming 0xF8, so that reading pairs the player with themself and the reflection tick walks them onto the mirror line each frame (two cold spawns end inside a wall). The destination is the executing channel's placement; the bit only decides when no channel executes.

Plausible: the arm's other operands are an RGB target, so all-zero reads as "target black", which is also what a fade-out looks like. The arm stores zero to the live-actor cell instead (sw zero,-0x49d4) and leaves without spawning, so the beat ends rather than ramping. A white target under blend 2 also loses an eighth of its duration: a capture reads 57 frames for the word 0x41.

Plausible: a ramp is the representation a renderer would naturally consume. No renderer reads such a ramp, so swapping one representation for the other repairs nothing - neither has a reader. The measured beat is a (kind, blend, packed) triple, and that push is the model the port keeps.

Plausible: the screen fades, the camera cuts and the player is somewhere else, as in every scene change. The scene name word does not move - town0c stays across the door - so a capture staged on one says nothing about scene boundaries.

Plausible: the script census, a native flag-helper sweep, the move-VM ext sub-ops and the motion-VM census all come back clean. The census walk stops at the record's first 0x1F text segment, and a raw scan for the bytes D6 05 misses the encoding 55 D6. Behind the text sit 48 and 55 D6, with a P2[3] twin. The native negative stands.

Plausible: the value is read off a live walk, so it is a real retail window - but not the entry one. A poll across a map01 -> town0c door catches the entry stamp at (-7, -6, 5, 7), 78 vsyncs after the scene word flips, with (-8, -6, 6, 10) arriving later as the player crosses into another region.

Plausible: an all-forms reference sweep returns clean. Run --tables-only, it drops hits classed as incidental code - and these two are data words, the +0x08 handlers of the field-overlay templates at 0x801F227C and 0x801F22AC, spawned through FUN_80020DE0 at 0x801D245C / 0x801D2634 / 0x801D57C0 and 0x801D2760.

Plausible: the hedge rows carry object-grid bit 0x0800 and not the 0x1000 ground-draw bit, the port's ground pass gates on 0x1000, and the result is visible black under the hedges - so an unfound emitter keyed on 0x0800 explained the symptom exactly. A live teien field pass visits 1536 window cells and emits 370: every 0x1000 cell and none of the 42 0x0800-only cells. Only 8 of 84 images touch *(0x1F8003EC) at all, only PROT 0900 / 0901 hold a per-cell pass, and each one's andi 0x800 reads an object record's +0x12, not a cell bit.

Plausible: the routine is a two-input ease inside the camera controller, and a yaw is the camera quantity most often eased. 0x801DA3B4 reads ctrl[+0x4A], 0x801DA3B8 reads the actor's +0x16, and +0x16 is the Y of the position triple, so the target is a height difference. Port: ease_camera_offset.

Plausible: three consumers of the field each suggest a different quantity from their own context. Nothing on the disc masks +0x16 as an angle: 0 of 77 accesses in PROT 0897 are angle-masked, and SCUS's four masked accesses are actor[+0x96].

Plausible: the markers are per-cell field actors and field_actor_plan is the per-cell actor planner, so a missing marker draw looks like a missing plan row. The markers come from their own per-cell pool; a planner row for them draws nothing.

Plausible: it is reached from a spawn table and its +0x1A arm looks scene-scripted. It is the +0x08 handler of the plain descriptor at 0x801F271C, spawned exactly once by the field MAIN INIT FUN_801D6704 at 0x801D6FD8 and gated on _DAT_8007B8B8 == 0.

Plausible: the field is set on exactly the instructions that have a sub-op, so a census keyed on it returns a plausible site list. The value is 0x80, a marker meaning "this op targets another context"; the sub-op is InsnInfo::ActorCtrl. Counted by sub-op the family has 311 sites across ten ending scenes.

Plausible: two nearby routines each probe a small band of bag items and each rewrite a persistent index, so one description covered both. FUN_801CF070 walks 0xA0 + _DAT_80084454 (rods); FUN_801D712C walks 0x9D..0x9F and rewrites _DAT_80084450 (lures). Two indices, two item bands.

Plausible: the header is a runtime-fixup header and the words are zero on disc, which is what an unfilled fixup slot looks like. All 97 on-disc tables carry zero there and no writer exists, so the words are reserved, not deferred.

details ↓

details ↓

Plausible: the modal slot is a 4-byte count = 0 filler (85 of 97 bundles), and the three kingdom tables read as a "kingdom slot 5" special. The 80 / 172 / 516-byte type-6 payloads (garmel, dohaty, the geremi / rayman / tunnel / son / edson family) parse as the same CLUT-walk table, installed identically for every bundle - the water / waterfall shimmer. The rayman-family carrier is the count-4 MAN-less variant the strict detector rejects; resolve by type byte (field-ambient-fx.md).

Plausible: the decompiled C renders it that way. The raw arm (80023070.txt 0x800235DC + the 0x80024150 epilogue) loops while the decremented count has not underflowed, retires on underflow with size 1, and loops back to saved + 2 (the epilogue adds a2 = 2 after the PC store) - re-running the 0x18 would re-seed the counter forever. jou's 15-instance cycler fan-out is the disc witness. Likewise ext 0x1E returns size 4, hidden behind a func_0x801d4a3c() label-call return (move-vm-overlay-ext.md).

Plausible: the handler tail (0x801E3178..0x801E31AC) does refresh the camera-scroll globals, but that tail is a player-ctx-only side path. The op body (0x801E3108) copies the operand-resolved actor's +0x14/16/18 position and +0x26 facing into the executing ctx - the seat primitive of every mid-visit crowd swap (dolk2 P2[11]'s eight CC <crowd> E3 <day> pairs). See script-vm.md.

Plausible: 6 of 6 pause captures hold the variant, and its 3 words equal row 273's content, which reads as a +2-row scroll park. The whole pause walk issues zero image transfers (DMA2 chain-walk + GP0 PIO hook) and plain field saves carry the variant; the strip is not shift-invariant and the wrap-scroll installer ops never fire across the s2 -> s3 flip window, so the row-273 equality is coincidence. The writer is the town01 opening record's one-shot 4C 60 face-frame stamp (settled).

details below

Plausible: FUN_8002735C does load per-node DPCS far colour + IR0, and the motion / move VMs carry op 0x0C writers of those fields. The opening never uses them: a live recomp capture reads node +0x78 (IR0) = 0 on every node at every beat, and the opdeene MAN motion section has no op 0x0C. The grade is a load-time CLUT / TMD palette collapse L=max(r,g,b) -> (L, max(L-1,0), L>>1) (cutscene.md); the far-field crush is that law seen through dark authored gouraud.

Plausible: the tick eases two full-width bars in from the top and bottom of the screen, as a letterbox does. The bars do not stop: they meet in the middle and hold, and the template it ticks is 0x801F2858, the one the field VM installs for a scene-change blackout.

Plausible: the address ticks a small monotone value toward a target, the shape of every fade in this overlay, and sits in the band the fade actors are allocated from. The tick writes 0x1F800314 + 0x48 + actor[+0x50] * 2 = 0x1F80035C + rung * 2, the scene's 16-entry elevation LUT, so what oscillates is a floor height. Installed by field-VM op 0x4C nibble-9 subs 0..2 via FUN_801DDE34; see script-vm-menuctrl.md.

Plausible: the dump writes +0x54 / +0x9E and the operand triple exactly as the known spawner does, and a second spawner (a scene-entry default) is a reasonable shape. It is the known spawner: 0x801DE754 - 0x801CFF3C = 0xE818, the field overlay's base-offset re-key, and the two dumps match instruction for instruction. The bar template has one spawn site, field-VM op 43 0C.

Plausible: it is called once per dancer per frame and reads the dancer record, so a facing update fits. It indexes the marker actor's +0x50 - the clip - 6 value the floor pass stamps when it spawns a step marker - and selects a mesh row from it. Dancers are posed elsewhere. See minigame-dance.md.

Plausible: the routine sits between the hall's enter and leave paths and touches the globals both do. It runs on the exit edge only, and it is a restore - it puts back what entering the hall displaced. Nothing in it names other1.

Plausible: the word changes every frame while a player is dancing, as a latched pad word does. The judge reads the ordinary per-frame pad edge words; 0x8007B880 is written by the hall's own animation clock and read by nothing that resolves a note. Gating a note on it accepts and rejects the wrong beats.

Plausible: the cell holds an otherN string while the dance overlay is resident. The slot is where the entry path parks whichever venue name last passed through it, so it reads other1 in a state that entered from elsewhere. The dance venue is other7, block base 0x4CC.

Plausible: it walks a rectangular region of BGR555 halfwords and rewrites each one, a cell-grid emitter's inner loop. The halfwords are palette entries: the routine rotates hue / saturation / value over one CLUT cell block and pushes the result with a single LoadImage at 0x8001A030, where a grid emitter would emit primitives. Port engine-field::clut_cell_fx; see field-ambient-fx.md.

Plausible: the world map animates through the same overlay-resident helpers the extension sub-ops wrap, so a direct call is a short path. The address has one reference on the whole disc - SCUS 0x80023AE0, inside the move VM's op-0x2F arm. The world map reaches the dispatcher only by running a move-VM script. See move-vm-overlay-ext.md.

Plausible: a per-actor byte tested at the top of a VM tick reads as an enable, and the actors that move do carry a non-zero byte. The gate is a beq at 0x80038194, so a zero byte runs the bytecode; the bit gates the player-engaged / actor-busy / off-map early returns at 0x8003819C..F4. The inverted polarity makes every un-flagged actor inert instead of ordinary.

Plausible: the arm reads a live input-shaped source and writes a direction, which is the shape of a follow-the-player op. It draws rand() & 6 and steps within a box of signed 7-bit tile deltas taken from the actor's home at +0x8C / +0x8D, so it never leaves one tile of where it was placed.

Plausible: the op schedules a two-word ramp on the actor, and the neighbouring ops ramp position. The words are +0x74, the packed RGB tint, and +0x78, the draw mode - scheduler kind 3. The speed multiplier the locomotion code reads is +0x72, one field away.

Plausible: the arm is gated on a word a fresh boot leaves zero, so the gate reads as a boot-time discriminator. FUN_801D6704's own epilogue clears the word at 0x801D750C, so the next scene entry finds it zero again. The seat (0xA40, 0, 0xA40) is not the player's - it is the spawn of the one plain ambient template at 0x801F271C; the player is seated on both arms, at 0x801D6F64 and 0x801D6F7C, from the door operand.

Plausible: the ops are decoded, dispatched and ported, and a decoded op with a table slot reads as a used op. Over all 573 MAN tail-section-1 variants, 0x0E appears 215 times in four scenes and 0x13 and 0x16 in one scene each; 0x15 appears zero times, as do 0x00, 0x06, 0x0F, 0x10..0x12, 0x1A..0x1F and 0x20. No disc data reaches them, so a missing consumer is not a port gap.

Plausible: a five-form reference sweep returns nothing. There is a writer - sw zero,-0x4534($v0) at 0x801D6F50, in the delay slot of the jal 0x800567A8 before it, a position a call-target sweep steps over. The arm stays unreachable for a different reason: the only store is a zero.

Plausible: the arrival actor does run the query, load the hit and install the miss defaults, a complete and self-consistent camera account. The query sits behind _DAT_8007B868 != 0, the dev / dual-mode gate, which is zero in retail. Retail's query is the script-driven FUN_801DE3E0, reached from three field-VM arms and the op-0x45 LOAD.

Plausible: it is the routine a camera-region record is handed to, and the globals change after it runs. It writes 0x8007B607..0x8007B627 and nothing else. The live globals are written by the ease FUN_801DB510 and the snap FUN_801DB8EC, off a staging descriptor a third routine composes; loading the record alone yields a block, not a pose.

Plausible: the two arms share the tile arithmetic exactly, and one host hook keyed on the sub-op byte gives the right answer for sub-8. Sub-8 is FUN_801DE3E0, the camera-zone query; sub-D is FUN_800180EC, the walk-region attribute refresh, which never touches the camera.

Plausible: the caller passes two coordinate bytes somewhere. The arm at 0x801E2878 calls FUN_801DE3E0(x & 0x7F, z & 0x7F), the same query-and-load as nibble-3 sub-8, so a scene can frame a shot from a camera-region record the player is not standing in.

Plausible: the arm resolves each operand byte to a world coordinate, a tile centre or zero, as a position broadcast would. The values go to _DAT_8007B628 / _DAT_8007B62A, and the focus clamp FUN_801DAA50 stores their negation into the camera focus at 0x801DAB68 / 0x801DAB84 when non-zero - zero is "no override", which is why the arm clears both before writing either.

Plausible: an absolute-word reference scan returns nothing for either address. Both forms are lui+sh pairs, which a word scan cannot see; the gp-relative sweep finds all eight references - six stores in the [4C CF] arm and two lh reads in the clamp.

Plausible: a pad remap quantised to four cardinals does produce heading error, and zeroing the camera focus moves the failing figure. At orbit 0 the residual is a pure +Z world walk, which no heading quantisation can bend; what bends it is town01's roughly 14.8-degree camera offset acting through the camera pitch. The 45-degree pad ring is correct and does not remove it.

Plausible: fifteen scene MANs carry a word whose low five bits decode to 0x16. Only eight carry the literal [2E 16] operand in a coherent record - ropeway, station, tunnela, tunnelb, tunnelc, nilboa, nilboa2, noaru - and the other seven sit inside desynced records. Count operand bytes, not decoded bits.

Plausible: it stores into gp+0x2D8 like the walker's two other sites. 0x801EF320 saves the octant into 0x801F35C4 on board entry and 0x801EFE7C puts it back on exit; the walker's real second band is cells 0x0B..0x0E, whose delay-slot sll v0,v1,1 at 0x801EF8C8 re-uses v1 = cell - 3 and lands on octants 0/2/4/6 after the & 7.

Plausible: rewriting a door's inline name does load the named bundle - the load trace's VAB, BGM and packet count all move with it - so a frame taken afterwards looks like a frame of that scene. A hijack into bylon, a scene the game draws brightly, measures identically black over 1000 vsyncs (non-black fraction 0.005 vs 0.003, the player sprite). From a world-map door the frame says nothing about the destination.

Plausible: the srl v1,s3,4 that forms the nibble is at 0x801E0C44, and a reader citing the arm's first instruction lands there. The sltiu v0,v1,0x10 is at 0x801E0C48, its beqz exit lands on the nibble-B error arm, and the table base 0x801CEE60 is the lui+addiu pair at 0x801E0C50/54.

Plausible: both print through jal 0x8001A068 with one string each, so one shared head looks like the natural shape. Each arm forms its own string pointer (0x801CEC98 for nibble F, 0x801CECAC for B) and F jumps into B's last three instructions at 0x801E3558. No scene carries a coherent 4C Bx; the 27 4C FF totals are all decode-desynced.

Plausible: both reads happen once per frame in the same tick, both take the lure's position, and 0x4000 appears in both - once as a cell-word bit and once as a buffer displacement. The water gate is bit 0x4000 of the +0x8000 per-tile cell halfword (andi v1,v1,0x4000 at 0x801D3374), and its class word is rebuilt by FUN_800180EC at 0x801D3384. FUN_801D7030's probe over the +0x4000 walk grid feeds the credit nothing: its hit drifts the lure's x accumulator by frame_delta << 11, signed by the low bit of the lifetime cast counter.

Plausible: a record's 0xFFFF0000 filler reads as its head, and 0x801D7618 - the fourth record's +0x0C - as a band start. Eight 0x18-byte records tile 0x801D75DC..0x801D769C, bounded below by an 8-byte-stride action-name string table and above by the Vahn roster pool, carrying FUN_801CF388 / 801D3468 / 801D3390 / 801D6310 / 801D3F44 / 801D6F18 / 801D4FC8 / 801D49E8. FUN_80020DE0 spawns one per site: 0x801CF184 takes 0x801D75DC, 0x801D01C4 takes 0x801D7624.

Plausible: the cell sits between the lure's x and a third halfword, so it reads as the second of a planar pair. The store is sh a0, 2(a2) at 0x801CFCEC, and it writes the spawning actor's +0x16 less 0x80 - a Y. The lure's z is the halfword at 0x801D9190, whose 24.8 copy is 0x801D917C.

Plausible: retail stamps the default at scene entry and then one of two writers replaces it. A default stamped once in Camera::new is only ever overwritten, so a scene that scripts a wide window hands it to the next scene's clamp. The port restamps on each scene entry (test scene_entry_restamps_the_field_draw_context_view_window).

Plausible: a resolver that widens a held direction moves where a player rests against a wall, and wall-press oracles pin those rests. At both pinned rest positions the resolver returns exactly the held cardinal, so the oracles sit where the two models agree. Retail's slide fires in ordinary free-roam - 15 widenings in 276 calls down one town wall - and the port's locomotion step calls the resolver (settled).

Plausible: the writer set is entirely field-overlay, and so are the two readers an absolute-word scan finds. The SCUS pad remapper func_0x800467E8 loads the word twice (0x800467E8, 0x80046840), which is what makes the octant a rotation; the walker's restore at 0x801EFE7C is a writer the same scan misses. Both forms - imm(gp) and lui+load - are invisible to an absolute-word scan.

Plausible: a fresh engine entry executes them and the clear is in their bodies. A write watch across retail's card-boot entry sees the clears come from P1[1]'s spawn prologue and the P1[0] entry script, and then P1[0]'s per-frame body re-SETs the flag every other frame from a player bounding-box test - so a state holding it set says where the party stood.

Plausible: the player does not move during a load, so one seed looks sufficient. The script install resets the ctx-0xFB context's anchor to the origin (a seed survives only in three opening scenes' load-frame pre-run), so with a one-time seed every per-frame CD F8 box test disc-wide answers from tile (-1, -1). Retail resolves 0xF8 to the live player on each evaluation.

Plausible: a two-scene pad walk is long and encounters break it. conc2 P2[20] and its spawners carry C1 = [0x3E1] / C2 = [0x3E5], and the only card save that reaches conc2 already holds 0x3E1 set, so no budget reaches the door; a tile poke crosses a door in about ninety vsyncs anyway.

Plausible: FUN_801D77F4 reads DAT_8007C018[slot] with no adjustment. The op's arm has already added *(u16 *)0x8007B6F8 at 0x801E2DE0..0x801E2DE8, and read that way all seventeen blocks fit their mesh vertex for vertex. Read as raw slots, jagaroom / garmel bind battle effect models on seven of eight sites.

Plausible: a record array is normally walked with one stride. The spawner's size sum steps 0xC, its rest-pose copy n_vert * 8, and the apply pass n_vert * 0x60; they agree only when a block holds one record, which every shipped block does.

Plausible: an identity index list under a top index is a generic free-list seed, and the name was picked from a neighbour. Its only jal is MAIN INIT's at 0x801D7384 (PROT 0897), passing (pool, pool + 4, 0x50).

Plausible: the 192 bytes share one row shape and the locomotion reads only the first four rows. Three consumers form three bases - the actor probes at 0x801F21B4, the wall probes at 0x801F2214 and the facing compass at 0x801F2254 - and the "uncalled" rows were the second and third tables.

Plausible: in the captured inn talk the bind 0x33 is the innkeeper's own, so turning the player toward the speaker looks right. The kernel resolves the bind like any cross-context id (0x80037E00..0x80037EA8), and a disc census finds 40 of the 146 placement-record acquires naming another actor, and 885 more in object and cutscene records with no own actor at all (settled).

Plausible: _DAT_8007B850 sits among the display globals and the op's other mode tests a flag. It is the packed held pad, compared & 0xF000 against a compass table at 0x801F28D0 and against the face buttons for op1 8..11 (settled).

Plausible: the byte is the follow camera's enable, and a disabled camera doing nothing is the natural reading. beq at 0x801DB558 goes to the pin leg 0x801DB820, which sets the focus to the negated player position and falls into the shake tail; only composing and easing are skipped (settled).

Plausible: the routine adds 0x40 to a word and caps it at 0x100, a fade's shape. It is item class 0x82's arm (0x800421A0), the walk tick drains the word, and the region encounter roll skips entirely while it is non-zero (0x801DA174) - Incense suppresses encounters outright rather than lowering a rate (settled).

Plausible: no jal reaches its operands' writer from the menu. The template 0x801E4700 is resident menu-overlay data, and FUN_80035C00 - two stores into gp+0x858 / gp+0x860 - is called by the Hyper-Art book arm at 0x8004208C with the roster slot and the art id (settled).

Plausible: small constants passed to a picker read as flags. 0x30 is patched into bytes +5 / +9 of the script at 0x801E4E08 as the settings window's id, and 1 is stored as the sub-screen on exit - the root command picker (settled).

Plausible: the motion gate reads it and dialogue is the obvious modal state. Every writer is a set-1 / clear-0 pair around a single call - FUN_8003AEB0 (0x8003B73C / 0x8003B928) and the field VM in PROT 0897 (0x801E2820 / 0x801E282C around jal 0x8003CF7C, 0x801E2BBC / 0x801E2BD8 around jal 0x8003A1E4) - and nothing holds it across a frame.

Plausible: the op stages a child-looking block. It writes +0x5A = 2 and +0x56 = 4; +0x56 is the draw kind FUN_8001ADA4 switches on (lhu v0,0x56(s0) at 0x8001AE60), and +0x5A the part-tick mode. The +0x9E bits then pick the emitter (0x4000 -> 0x8002A5A4, 0x2000 -> 0x801CFA48).

Plausible: each store's displacement reads as an actor offset. Six arms of FUN_80023070 (0x13, 0x1F, 0x23, 0x24, 0x26, 0x42) address the block through s1 = actor + 0x80 (0x80023088); an offset wrapped to 8 bits (0xFC for +0xA8) sends every store below +0xAC to a slot nothing reads. Take the offsets from the sh / sw stores.

Plausible: the value is what the ported decoder reads back after a tick. A summon translation glide applied to every node treats +0x9C / +0x9E as its clock, adding 0x400 to the cap per tick and clearing the 0x2000 ribbon flag at its latch; retail reads those words as a glide only inside the mode-3 arm (0x800226E8..0x800228A0).

Plausible: the lateral offset shifts by 13. The tables are the standard 1 << 12 pair and lw v1,-0x4808(t8) at 0x801CFD0C walks X on the cosine, so the >> 13 halves the offset rather than normalising it.

Plausible: the dialog renderer has 0xCE / 0xCF escapes, and the walker runs where text actors draw. Its disassembly compares no byte against 0xCC..=0xCF. It walks the gp+0x148 drawable list - the one FUN_80032434 builds and FUN_80031AE4 tweens - and dispatches each node on its +0x1C byte, clamped to 0x23, through the jump table at 0x80010DC0 (jr v0 at 0x800321AC). see ghidra/scripts/funcs/80031d00.txt.

0x801E328C..0x801E32E4 adds a signed 24-bit value to the coin bank 0x800845A4, caps it above at 9999999 with no lower clamp, sets system flag 8 and advances 5. A host that leaves the op a no-op never charges cabinet fees or the Earth egg's price.

The record's +0x18 word is 0x801E6F70, the entry panel; the prize exchange's windows draw through it, not through a host-invented layout.

Plausible: the pair it writes sits beside battle-reaction state. All three calls are in FUN_800402F4 - two after a menu-cast spell-level bump (+0x729, threshold table 0x8007656C), one after a Hyper-Art book's art insert, skipped in battle - and the pair feeds menu windows 7 and 8. The port carries it as values (SpellLevelNotice, pending_art_notice).

Plausible: the bounds tests are slti 5 and slti 3, the shape of a clamp. Past either end the stepper stores the opposite end - col < 0 -> 4, col >= 5 -> 0, row < 0 -> 2, row >= 3 -> 0 (0x801E0170..0x801E01CC). The reachable cells are the same fifteen, so view mode 4 stays dead.

Plausible: no caller measures a line and nothing wraps. The loop leaves when a counter reaches a2 (0x80036908..0x80036910), and the counter steps per glyph (0x80036B9C), per numeric escape (0x80036B20) and per 0x7C (0x80036938). The pager passes its reveal counter _DAT_801F2748 for the typing row (0x801D9720); every other call passes 0. "No text surface wraps" stands.

Plausible: the first increment a reader meets is the 0x7C arm's, right under the exit test, and most call sites clear a2. Two more increments sit further down the loop, and FUN_801D84D0 loads a2 from _DAT_801F2748 before the typing row's call (0x801D9720..0x801D9758). Read every write of a counter before naming what it counts.

Plausible: the box appears at a different place and size from the reading box it follows, and the state sits between the press and a usable menu. Width and height are fixed from the first drawn frame; the state counts the origin in from off screen (0x801D92F4, 0x801D9350, shared tail 0x801D93F4), and the pager skips the box while the count holds the 0x309 sentinel.

Plausible: it lives in the menu overlay beside the card code, draws a two-choice stack with the unselected row dimmed, and PROT 0899 carries no TIM for its page. The records address the title TIM's wordmark, NEW GAME, CONTINUE, TM and copyright strips; the page is PROT 0890's title TIM, byte-equal in VRAM, and the routine is gated on _DAT_8007BB00 (the Load window opened from the title).

Plausible: 0xFF reads like a sentinel. FUN_80042F4C counts a matching bag slot, an empty slot is id 0, and item 0xFF is the Platinum Card, which no mednafen library state carries in an equipment block; a capture on Retock's Items Shop emits 13 rows with it and 10 without. The "new in this town" reading of the band falls with it.

Plausible: the casino prize list has its own ink rule. FUN_80032A44 inks class-0xA000 rows 5 even over a dimmed row (0x80033548..0x800335A0).

Plausible: the menu overlay writes them near the save code. FUN_801D8A58 consumes item 0x88 and stores 4 (0x801D8B6C); FUN_801D8B90 consumes 0x89 and stores 5 (0x801D8D3C). FUN_801ED308 is the pause-menu session, not a brightness fade.

Plausible: the menu atlas is the obvious glyph sheet, and 0x80074050 sits beside the width table. 0x80074050 is the 0xCE escape table, and the dialog font already carries 32 inked high cells.

Plausible: FR / IT capitals sit near there. Lifted text writes  0xB6, È 0xD4, Î 0xD7, Ì 0xDE, Ô 0xE2.

Plausible: the chips sit on blue plate art beside a D-pad glyph. Each chip's word is the +0x14 payload of its screen-element placement record: Attack, Item, Run, Begin, Auto, Command in the executable's small-data pool 0x8007B658..0x8007B690, the Ra-Seru names in the battle overlay (battle.md).

Plausible: the page composed fishing_exchange_draws every frame and a unit test drew it. Nothing held the exchange open across a frame, so the compose always returned empty. Both hosts drive the screen through engine-core::fishing_exchange_input.

Plausible: the port's own shop screen was that list, and a screen read back off the port looks like a screen read off retail. FUN_801DB7F4 and FUN_801DBD94 step a single value at DAT_801E46B4 by +1 / -1 / +10 / -10, clamped, with the bound min(gold / price, 99, 99 - held). The list reading caps every purchase at 9, the list's own row count.

Plausible: 72 is what a cheat database's item page enumerates, and a UI page is easy to mistake for a capacity. The array at 0x80085958 is 256 slots and every accessor checks the window pair gp[+0x2D2] / gp[+0x2D4], which FUN_8004313C alone writes; a lone character sees one 128-slot half. A real three-member memory-card block carries items up to index 159, so a 72-slot bound drops 88 of them on a lift (inventory.md).

Plausible: the table read returns on -1 (0x801F1468..0x801F1470) before it installs a handler, and a standing park explains the kind-0x0D screens. FUN_801F1278 has already stored +0x50 = 7 (0x801F140C) and +0x54 = 0 (0x801F141C) by then, and handler 7 is the state pick that opens the pause-menu session. A PCSX-Redux capture at the town01 save point shows the menu (game mode 23) open with no Start press. A close-tick fallback for sub-op 1 built on the standing-park reading makes every save point save nothing.

Plausible: it zeroes the park and the window-list head side by side, which is what a menu teardown would do. find-address-word-refs.py 8003540c --prot finds no word, jal, j, branch or lui pair for it; its twin FUN_800353E0 runs only from the scene loaders. The park is resumed by the submode dispatcher's retire arm, which writes Done while it is live.

Plausible: the sprite-VM framing suggests a "trigger animation" op. FUN_801D6628 is resident in PROT 0899 (the menu overlay), and its base materialisation lui 0x801e / addiu 0x4738 indexes the window descriptor table - instruction byte 1 is a window id, not a sprite-actor slot. No arm of the 13-way dispatch hands off an ANM id (see ghidra/scripts/funcs/overlay_menu_801d6628.txt). Programs are overlay-resident data (window-script.md), so there is no per-scene carrier to find.

Plausible: the three subs are one protocol, and the C renders the arms in a shape that supports one gate over all of them. Sub 0 and sub 2 halt at PC unless _DAT_8007BABC == _DAT_8007BAA0 (0x801E0340, 0x801E03A8); sub 1 stores only when the pair is equal or the acknowledge cell reads the idle sentinel -1 (0x801E0374..0x801E037C); sub 3 - the teardown FUN_801D8450 - is ungated and yields the frame rather than falling through. A script that waits on the wrong arm deadlocks. See script-vm.md.

Plausible: a single "disable" flag matches the first arm met - non-zero skips the whole bit-15-set sub-switch and advances the op (bnez v0,0x801DF898 at 0x801E031C). On the bit-15-clear arm the same word bypasses the equality test instead of adding one (0x801E03E8..0x801E0410). Retail boots the word 0, so the asymmetry never shows in a capture.

Plausible: the builder dims unaffordable rows, which is a real retail rule. Retail's builder (case 0x0B) also splits the walked rows at record_count - 3, stages the rows below the split into 0x801C6220 tagged 0x3000, writes the last three straight out tagged 0xA000 (ink 5), and appends the staged group afterwards - so the on-screen order is not the record order and the top strip is highlighted. The dim rule is purse < price or held >= 99. See shop.md.

Plausible: the entry-context byte reads by position, and 0x02 is what the sentinel row produces. The byte is keyed on the record kind: 0x00 shop -> 0x1A, 0x01 save -> 0x19, 0x07 casino -> 0x20, 0x0D -> 0x04, and the sentinel 1 -> 0x02, the debug character-parameter editor. See save-screen.md.

Plausible: a port that renders only a segment's first line has unexplained box geometry, and an unparsed header would supply it. The box's rect, pens and advance hand belong to the pager (FUN_801D84D0, row capacity _DAT_801F2740 = 3), and consecutive 0x1F lines pack into one window. See field-menu.md.

Plausible: a jal sweep of the battle overlay finds nothing, and the overlay really does not call it. FUN_80031D00 (SCUS) drives the window emitter with jal 0x800323E4 off the retained widget list every frame a battle is up, so the report chrome is the same nine-slice as every other window. A sweep scoped to one image cannot answer a question about a shared driver. See level-up.md.

Plausible: the prompt reads as binary on screen, so a dedicated two-way confirm widget is the natural guess. The script emits 3E FF <row>, the standard option-picker sequence of the field VM; only the row indices are specific to it. Its install coordinate is on encounter.md.

Plausible: the five helpers are the whole add / remove / query surface and all respect the active window. The pause menu's Throw Out confirm FUN_801D8734 stores zero straight into the bag at 0x801D88FC and 0x801D8910. A port that models the bag as "whatever the five helpers did" keeps a thrown-away item.

Plausible: the cursor drives a list, and on an unholed bag row and slot are the same number - which is every bag a fixture builds. The list hides empty slots while the payload does not: on a bag holed at slots 1/3/6 the cursor takes 0, 2, 4, 5, 7, 8, and removing by row throws away the wrong stack.

Plausible: a port tag named the counter as missing. World::minigames.point_card is the 0x800845B4 bank. The arm stays unentered for a different reason: no item on the disc carries the class that reaches it.

Plausible: a builder that cannot answer "is this sellable" looks table-shaped. Sell price is the item record's +2 through shop_catalog::ShopItemData, and the discard gate is the equipment record's +7 bit 0 plus the item-effect not-discardable kind. The defect under that reading was a sell list drawn id-sorted while the commit walked slots.

Plausible: the two windows draw the same shape of stat comparison, and the recipient flow does draw a compare panel. Window 25 is named by one open command only - the Equip screen's candidate step, sub-screen 0x14, script 0x801E4DC8 - and window 41 by the shop-entry script 0x801E4E64; the recipient sub-screen adds only window 36 over the set already up. Under the merged reading window 25 has no place on the Equip screen at all.

Plausible: every equipment bonus row on the disc carries 0x40 at +5, so the sentinel reproduces the equip screen on every equipment id. The category byte has two sources, and only one is that table: 151 of the 255 non-zero ids take the item-effect arm, 80 of them carrying a real passive index at +3. A host feeding the sentinel unconditionally loses the HP / MP and SPD / INT / AGL row sets.

Plausible: the port's slot list is the equip-byte array in order, and a leading row that is not one of the four gear slots reads as a convenience entry. Row 0 takes a per-character halfword from 0x8007B42C (2, 3, 2 - Vahn and Gala's weapon byte is 2, Noa's 3), and rows 1 and up index 0x801E43E8, 00 01 00 04 05 06 07. The order is weapon, helmet, body, footwear, three Goods, and the slti v0, s0, 4 guard silences exactly the four gear rows (settled).

Plausible: the armament rows are masked - cases 0xE / 0xF / 0x10 read a per-character mask of their own. The three Goods rows go to different builder cases (0x1C / 0x1D / 0x1E, selected by the eight-byte content-id table the browse step writes), and their filter is item class 2 plus an item-effect byte, with no character term. Copying the armament rule onto all seven slots offers the wrong candidates for three of them.

Plausible: a shop quantity prompt printing two numbers over a running total reads as unit price times count. The second number is DAT_801E46B8, the purchase bound the picker's phase 0 fills with min(gold / price, 99, 99 - held), and the glyph between the pair is a separator, not a multiplication sign. The price appears once, in the total, beside the currency pictogram (settled).

Plausible: 00 01 02 04 looks like the gear indices again, as a longer array would. The run is seven bytes; 0x801E43EF is alignment with no word, no lui/addiu pair and no branch anywhere in the corpus; 0x801E43F0 is a four-byte character equip mask and 0x801E43F4 eight halfwords of slot pictograms, each with three materialisation sites of its own (settled).

Plausible: one number, one menu system, and a scanner that reports both. Window 0x15 is the Equip screen's party window, opened by the slot-browse's own script 0x801E4DA0 at 0x801D9ACC. The reorder page is sub-screen 0x15, written into DAT_801E46A4 by exactly one site disc-wide, 0x801D6C4C in the root picker's row-3 arm. State the id space when searching for a bare id.

Plausible: it sits in the submode driver's slot table beside real menus and runs three states. Entry kind 0x0B reaches it from the walk tick's Incense zero edge (0x801D0CEC..0x801D0D24); it shows one window naming Incense and hands back (script-vm.md).

Plausible: a port's world map can run with no walk tick at all. Retail's kingdom maps run PROT 0897's FUN_801D1344, which calls the walk tick at 0x801D16EC; the sebucus_overworld_resident state holds the walk tick, the Incense encounter test and the notice byte-identical to the 0897 image (world-map.md).

Plausible: a camera row would print camera coordinates. Neither address is formed in the row's draw (0x801EB3D8..0x801EB560); it prints the switch 0x8007B606 as OFF / ON (strings at 0x801F318C) and, while on, the centre of the region box 0x1F800384 (000 000 for the 0x7F7F0000 sentinel). The port is DevMenuRow::Camera.

Plausible: it draws a numbered list. Its only descriptor is 0x801F3304, installed at 0x801EF144 by submode slot 0x23 (FUN_801EF014, op-0x49 sub-op 4) - a flag-backed numbered picker that only kor, kor3 and kor4 reach.

Plausible: a host can write the raw word into World::input and tests that feed the packed constant directly still pass. The handlers test Legaia's packed mask (Cross 0x40, the d-pad in the high byte); on the raw word Cross does nothing, Down accepts and Right backs out.

Plausible: the box shows three rows and _DAT_801F2740 = 3. The pager tests for another line after each row (0x801D8AB4) and scrolls a full window in state 0x0C without a press; a capture sees page 2's fourth line scroll in with the press column at zero.

Plausible: the states are consecutive. 0x0D (0x801D8C64) is entered on a confirm, 0x0E (0x801D8D28) scrolls rows through at speed 0x25, and the wait is 0x19.

Plausible: the draw adds a y term. In FUN_8002C69C(x, y + d, 0xF4, h - 8) the d / h terms come from the collapse ramp 0x274C (0x801D9970..0x801D99A0); the rows alone add scroll >> 4, clipped by two draw-area packets on the same ordering-table entry.

Plausible: the records read from there parse cleanly, and two cross-check against known painters - inside the same shifted frame, so the check cannot see the shift. FUN_801E9B3C forms the base at 0x801E9B70 with stride 0x1C; name entry is records 13 / 14, not 9 / 10.