piney_apples

"Field 28's held battle flag is event 50's game of tag; Infection's story without god, and what the pilot lacked there"

2026-10-02T00:00:00Z

358 and 359 left two questions open: why in_battle held at 1 in field 28 with no fight, and how the story plays without the survey's aids. Both are answered here; neither found a fault in the port.

Field 28: Stehoney's tag

The hold was reproduced by letting the pilot skip the closed-event rule for events 13 and 15 (a switch since removed). It came back at frame 38,400: Kite alone at field 28's start, one foe 1,928 away. That foe is enemy row 131, put there by an event (ent_root 0), standing (act 0) with Kite as its target.

INF event 50 (SB0020 GOB1-1) is a side event. Once board thread 9's post is read it gate-marks area 28. In field 28 its block 5 sets the place and makes enemy 131 (entry 5 131). Block 7 opens a game of tag, and block 8 ends it once the foe is absent, with a reward (item 6/60). The tagged foe keeps clear of Kite. ccThGameCtrl (gcmn 0x00517c50-0x00517d2c, battle_now) puts the game in battle while an enemy is within inBattleDist (2,200) of a member, so the flag holds as long as Stehoney does. That is the game's own rule. The pilot only went there because it took the last marked area; the closed-event rule of 358 keeps it away. Kite alone, sent straight into field 28 from story start 16 and left idle for 20,000 frames, meets no foe at all; that start's flags for event 50 were not looked at.

On the way, enemy_ai::Out::InBattleDist's comment had the gold goblin's -2.0 backwards. The same function (0x00517c98) sets battle mode when the distance is exactly -2.0, so a goblin shaking off a hold forces battle mode for a frame. The comment now says so; the code was right.

The story without god

PINEY_SURVEY_AIDS picks the aids (Aids in survey.rs):

unset keeps them all: god, the infection held at 0, the hacks' cores, the levels for the bosses;
0 turns them all off;
levels turns off god but levels the party to the foes it meets and stocks Kite in town, as a player grinds and shops (below).

A run without god ends at the first game over, which takes the game to the title. The run then fails, printing the place and the last 20 seconds of the fight (FIGHT lines). PINEY_TRACE_BOSS prints a boss fight a line a second.

No aids. The game is over at frame 40,564, in area 17's dungeon (event 14). Kite (63 HP) and BlackRose (70 HP) are both still level 1; they fall to a level-4 Chicken Hand. The pilot walks straight to each goal and fights only what holds the walk, so nothing levels it.

levels. Each member below the strongest foe standing (bosses excepted: Skeith's row says 99) plus three gets the experience to that level (levels_for_foes, the game's own level-ups). In town, Kite's Healing Potions and Mage's Souls are topped up to five each (supplies). The run ends events 3, 4 and 10-28, then the game is over at frame 242,740 in area 26's dungeon (event 29). Three Armor Shoguns (level 24, 1,010 HP) and a Grand Mage (level 23) wipe Kite (level 75: the boss-level aid's lone-dungeon level, 75, had lifted him) with BlackRose and Mia (27-28).

Earlier settings told the same story:

Matching the foes' level exactly, the party dies to event 14's Data Bug at level 5.
Levelled by the lowest member (Kite overshooting to 99), it reached event 30 and fell to Skeith, whose own Data Drain (act 5, affect 13) fells members with HP left.

What the pilot lacked without god

God's endless SP had hidden three gaps:

A refused skill. With too little SP (or Data Drain barred) the Skills menu opens its info window (process 2-3), which takes OK, not cancel. The pilot gave cancel for ever (80,000 frames in event 14's dungeon).
Data Drain's cost. It cast Data Drain whatever its SP. It now drains only with the SP for it, else a Mage's Soul on Kite first.
No plain blow. With no skill it could pay for, it stood still while the foes hit it. In the last 20 seconds of the area-26 wipe, no foe lost a point. It now gives the action button's blow when the command target is an enemy. With that, one Armor Shogun falls and another drops to 200 of 1,010 HP, but the room still wins.

Where that leaves the measurement

With the aids on, the story runs to its end (359). Without them, the first walls are the pilot's, not the port's: it does not grind, plan its SP, flee or use magic against armour. The damage rules it meets were checked against the game's code earlier (the battle harnesses), and nothing here contradicts them. Area 26's monster room is where a better pilot would have to start.

"Infection's whole story ends under the autopilot: event 22's cure boxes, a ghost Kite under god, board posts first"

2026-10-02T00:00:00Z

358 took infection_whole_story to event 21. It now runs INF's story from its first start to event 31's end: 401,400 frames, 379 seconds headless. Every event from 3 to 31 ends in order, the last on the staff roll. Three more gaps were the pilot's; one was the harness's god.

Event 22's cures are story boxes

Event 22's blocks 21-24 wait on Kite holding items 15/54-57 (Remedy, Custom Remedy, True Remedy, First Remedy). No script gives them; no story room's statue holds them (ROOMDATA.itemID names no E05x). They are in area 31's dungeon (D0171), in four story boxes, one a floor.

D0171_gim  floor room  x      y      type  flag
row 3      0     9     6000   21562  0     0x450036  E054 Remedy
row 4      1     11    18750  12843  0     0x450037  E055 Custom Remedy
row 9      2     7     21046  18093  0     0x450038  E056 True Remedy
row 2      3     11    21000  24890  0     0x450039  E057 First Remedy

SetItemBox gives a type-0 row with a flag that item (box_item_code(flag)). The flag is the item's code as 0x45_0000 | id (E and the id; itemTblE's code for 54 is the text E054).

The pilot gets them:

Want::Item(id). story_wants gives it for a block short only of an important item (category 15, Kite).
item_spot. In a story dungeon it finds the box rows holding a wanted item, nearest floor at or below Kite's first (the walker does not climb). Else a room whose row gives its statue an item, else the statue room (DungeonArea::statue_room, the room built from the type's symroom model).
open_item. In the room it walks to the unopened gimmick nearest the row's x, y (FieldWorld::unopened_gimmick_near: switched on, still on the command list) and gives OK. The box's menus are story_player's. A room counts as done only after 300 frames there with nothing to open, since the boxes switch on with the room.

FieldWorld::unopened_statue (a statue not yet opened) is now its own function; no_active_object uses it.

A ghost walks through boxes; god left Kite one

The pilot reached the First Remedy's box and stood in it. Kite came within 0.63 of the box's centre (radius 40). The box's body was in the list where it stood, and Kite's was not. Traced room by room, Kite's body went at room (0, 10) and in every room after: there hp reached 0 and his cond[DEAD] went 2, 3, 4. With dead 4, ccSpcChar::HitCheck takes the body off the list (kite_hit_check), as in the game: a ghost goes through.

The god console heals the party at the end of each frame, so a hit worth more than Kite's HP still fells him. FieldWorld::revive_party got the members up but not Kite. It now revives Kite too (affect 20, by a member still standing). kite_stops_at_area_31_s_cure_box (with kite_stops_at_a_story_box_on_b2, now sharing kite_stops_at_the_story_box and in_story_dungeon) walks to floor 3, room 11 under god and runs at the box: he stops against it. The game's rule is untouched; only the harness's god changed.

The other two

The cure line. info_lines (the window 355 gave piros_colour's line) is a window every pilot now answers, as it does message_open and announce. Without it the pilot waited on "Piros used the Remedy" for ever.
Event 23's posts. Block 1 waits on four new posts read on the board, and block 2 on the mail they bring, on the desktop. The top page pilot left for the desktop first and never opened the board. New posts (and a post to write) now come before leaving.

Checked

infection_whole_story (ignored, a diagnostic: --ignored --nocapture) passes, events 3, 4 and 10-31 each ending once. The game suite (220) and the world suite (92) pass.

"Infection's whole story under the autopilot: the pilot's gaps up to event 21"

2026-10-02T00:00:00Z

276 ran Mutation's story from its new game to its end under the story autopilot (mutation_whole_story), and Outbreak's followed. Infection, the volume being finished first, had only story_survey: one story start at a time, 4,000 frames each. infection_whole_story now runs INF from its first story start (event 3; 1 and 2 are the desktop's) to event 31's end. Its first runs stopped at once. Each stop was the pilot's, not the port's.

What the pilot lacked

Event 10: Kite's own post. bbs_post7 leaves a post in state 7, which the board writes out on the next visit. The top page player read only new posts (state 1), so it went between the desktop and the top page for ever. It now opens the board first when piney_toppage::bbs::check_write_bbs finds a post waiting.
Event 11: targets that are not town NPCs. The town talk looked every add_target up as an NPC. Event 11's are BlackRose (type 2, a party character) and the Chaos Gate (13). GateGoal::Talk now carries the kind: 2 a party character, 3, 4 and 8-12 an NPC (8-12 are event 16's five merchants), 13 the gate.
Events 12 and 14: a closed event. An event's end_event closes it (bit 63), and it turns done (bit 62) only at the next mode's ccStartThEvent. The next story event opens on done. With the story wanting nothing in town, the pilot took the last marked area (field 28, an old mark) instead. It now logs out whenever a story event is closed and not yet done.
Event 13: a town marker. Block 2 waits on near_marker 31 in Mac Anu. The pilot walked to markers only in fields. GateGoal::Marker walks to World::marker's place first.
Event 21: Elk alone. Block 9 refuses the gate while anyone but Elk is along (in_party 10, party_other 10). The pilot had filled the free slot with Mistral. story_wants now gives Want::Only(pc) for a party_other block; the pilot then sends the others away, re-invites the member, and fills no slots.
Event 22: two towns. Event 22 wants both Mac Anu and Dun Loireag. Each town's goal was the other, so Kite went back and forth. A town that is itself wanted now keeps him.

whole_story now starts at the volume's first story start (crate::start::POINTS). It gives up after PINEY_SURVEY_STALL frames (200,000) with no event ending, and says where. The stall report (whole_state) adds, in a field or dungeon, the event targets, the foes and the nearest one's distance, in_battle, the menu, the phase and the playing block.

Where it stands

Events 3, 4 and 10-21 end, the last at frame 222,600 (with god, the infection held at 0, cores given for the hacks, as the survey's aids do). The run then stops in area 31's dungeon with Piros in the party. Event 22's blocks 21-24 wait on Kite holding the cures (items 15/54-57). In a story dungeon the idol of a story room holds that room's itemID (SetIDOL, ep.param[1]), and the pilot never opens idols.

The stall in field 28 showed one more thing to look at: in_battle stayed 1 for 60,000 frames with Kite idle at the field's start. The pilot's gate_out takes in_battle as busy, so it never left. That run predates the closed-event rule, which keeps the pilot out of field 28; the in_battle reading itself was not explained.

"The port's messages go through tracing: PINEY_LOG filters them, and the console shows warnings and errors"

2026-10-02T00:00:00Z

Not the game's. The user asked for a better logger. The port's diagnostics were 125 bare eprintln!s outside the tests, in nine crates. They had no level, no source and no way to quiet them. A Data Drain trace sat behind its own variable (DBG_DRAIN). Warnings never reached anyone playing without a terminal.

Now

The tracing crate (0.1.44) logs everywhere, and tracing-subscriber (0.3.23, env-filter) prints it. Both are workspace dependencies. Each site took a level by what it reports:

level	what
error	the run cannot go on: bad arguments, no GPU, an unreadable disc or build, a failed `--shot`
warn	a part is missing and play goes on without it: a map, effects, a stream or movie counted as played, a set-up pass that did not settle, an event-host method not ported, a texture not found
info	a replay's progress, the pad log's path, the viewer's model count
debug	the desktop's and top page's script trace, a set-up pass's frame count, a mode change the session did not expect
trace	Kite's skill and act around a field frame (was `DBG_DRAIN`; now `tracing::enabled!`)

piney-game installs the subscriber first thing in main (logging::init). It prints compact lines to stderr, coloured only on a terminal. PINEY_LOG is read as an EnvFilter. The default, warn,piney=info, keeps the port's crates at info (targets are matched by prefix) and wgpu and naga, whose log records now arrive through tracing-log, at warn. The viewer sets up the same filter.

A third layer, ToConsole, keeps every warning and error as one line (WARN: message field=value). The window's frame loop hands those lines to the console's say, so they show in the console (F1) without a terminal. warnings_reach_the_console checks it under a scoped subscriber (info is left out, fields are kept).

piney-gen and piney-build keep eprintln!: their output is a command line tool's answer, not a log. Tests keep theirs too.

"Each arrival in a town draws its own walking PCs: the session counts frames from power-on"

2026-10-02T00:00:00Z

Issue #32: the PCs walking a Root Town were the same on every visit. In the game they change each time the party comes back.

A town's set-up runs ccInitRand (INF SLUS_202.67:0x001d9900). It seeds the game's MT19937 with 4352 and draws it ccSys+0x358 times. ccRegisterRandomNpc then picks the walking PCs' npcTbl rows from that generator (65, docs/engine/field-game.md). The port had the count as an input, World::set_rand_count, but nothing ever set it. So every town drew from a generator drawn 0 times, and picked the same rows.

The count is a frame counter. In ccSystem::Ctrl (0x0010a6bc), after the wait on sceGsSyncV for the frame rate, the game adds one to ccSys+0x358 once per game frame. ccSystem's set-up (0x0010a944) zeroes it at power-on. Session now keeps the same count (sys_frames, one a step from power-on). It hands the count to every town it sets up: on Log in, and on each enter_world into a town. The port's frames cannot equal the game's (its load times differ), but two arrivals now differ as they do in the game.

each_arrival_in_town_has_its_own_pcs goes from event 3's field to Mac Anu, then Dun Loireag, then Mac Anu again, by the console's town. It compares the rows of the walking PCs on the two arrivals. With the count left at 0 the rows are the same and the test fails.

"Event 22's cures and finale: piros_colour's line waits for its window, and a room change disables the event task at once"

2026-10-02T00:00:00Z

Two reports on INF event 22 (PIRO02, the Cursed Piros quest), both fixed.

Issue #30: the cure's line went by unseen

When Kite takes a cure (items 15/54-57), blocks 21-24 delete it, add one to eventStatus[1] and set eventStatus[24] (the save's +0x6510) to the message of the line: 16, 20, 24 or 35. Blocks 25-27 then run piros_colour 0. On statuses 3, 5, 7 (and 9 with operand 0) the case plays sound 74 and shows that message's first line through ccEvent::DispInfo (INF SLUS_202.67:0x001b27b0). In the field, DispInfo blocks:

it waits for ccMenuCtrl::CheckMenuType to be -1;
it calls ChangeInfo, then ccBreathThread(5);
it polls Check(0) a frame at a time until the window is answered;
it calls Close, then ccBreathThread(10).

The case's flash and tint come after. 99 ported the case from an eemu run that stubbed DispInfo as a plain call, so the port opened the window and went on. Five frames later message 17 replaced it.

Now Host::piros_colour(code) sets the case up and answers whether it tells the line (piros::Sequence::tells). If so, the interpreter plays sound 74 and runs DispInfo's wait itself. It reuses the announcements' code (announce_from, which now takes the window's opener), and Host::info_lines opens the window. Then comes the host's Wait::PirosColour. Sequence no longer carries the sound or the line. Its first tick is the instruction's own frame. The fixture test (piros_colour_is_the_games, 66 records) adds the sound and the line back when the case tells one, and still matches.

event_22_tells_piros_used_the_cure (area 31's dungeon, the first cure given) checks the order:

the line (message 16) opens at frame 134, after sound 74;
it is answered at 171;
message 17 opens at 186: 10 frames of DispInfo's tail, then the case's breath of 5.

Issue #31: the finale played on the loading screen, and gave no diary

The fourth cure takes the status to 9. Block 28 then sets eventStatus[0] to 2 and runs room_point 5. Block 29 (eventStatus[0] 2, in point 5, phase 4 or more) is the finale. It ends with item_add_menu 0 12 24 (Piros' Diary) and scene to Mac Anu.

room_point calls WORLD_MAN::RoomSelect (main 0x0019dca0). It always ends in ccGame::ChangeScene, whose ChangeRequest(6, 7) calls ccDisableThEvent at once (phase -1). So in the game, the rest of that pass cannot start block 29. Block 29 waits for the new room's set-up and runs once play begins, in view.

The port's host made the scene change, but the task was disabled only when the area took the request, after the interpreter's frame. In between, block 29 started in the old room, where the scene had already moved to point 5's room. The new room's set-up then held its loading frame (Phase::Hold) through the whole cutscene. Its windows showed over the black screen with the logo, as in the report.

The diary was lost the same way. item_add_menu asks for menu 29, but the held set-up never runs the menus, so field_menu read -1 the next frame. The interpreter took that as the menu closed, and nothing gave the item.

The interpreter now disables itself after room and room_point, as it does at scene. Both run only while playing (level 2 or more; the cases check $s5 < 2), and room_point with no such point does nothing, as the game's loop does. prev_room (127, WORLD_MAN::GoPrevRoom 0x001a40b0) also ends in ChangeScene and is treated the same, though no script on any of the four discs uses it.

tools/test_event_vm.py had stubbed RoomSelect and GoPrevRoom whole, so its run of the game never reached their ChangeScene, and the fixture kept the phase at 4 after a room change. Both are now hooked to disable the task, as its ChangeScene hook already does. The fixture was written again: 5 of its 252 play records changed, all to the port's new counts.

Event 22 block 29 takes 365 frames (was 299) once block 28's room_point has disabled the task: its windows take the set-up screen's shape.
Event 58 blocks 6-8 and event 162 block 8 change the same way, after an earlier block's room. every_block_played_matches_the_game passes on it.

event_22_finale_plays_in_the_room_and_gives_the_diary gives the fourth cure at status 8 and checks four things:

block 29's first line opens in the new room's area, in play;
menu 29 opens;
Piros' Diary (12/24) is in Kite's items back in Mac Anu;
eventStatus[1] ends at 10.

Without the fix, the line opens in the old room and menu 29 never opens. The test helper board_done must stop rewriting eventStatus[0] once the cure is given, or it undoes block 28's 2 in the new room's set-up.

Shots of the fixed finale: the room lit with Kite and Piros under message 32, then "You now have Piros' Diary!" over the same scene.

"A HUD scale: each HUD part shrinks toward its own corner"

2026-10-02T00:00:00Z

Not the game's. The user expected render scale to make the HUD smaller, as a PC game's does at a higher resolution. Render scale adds detail (350) to a picture that always fills the window, so a separate hud_scale (0.5 to 1; console hud_scale, --hud-scale) now does it.

Anchors

One sprite queue can carry several HUD parts. MenuFont, for one, holds the party panels' HP and SP digits and the target window's numbers in a single send. So an anchor has to come from the code that draws each part, not from the queue. Each packet now carries spr::Anchor, a point per axis in the menu's 512 x 448 space, or none. Disp sets it on every sprite before each part:

party panels: bottom left;
target window and new-mail mark: top left;
bracelet gauge: top right;
battle band: its height alone, toward the top;
battle announcement: the centre.

Everything else keeps its size: the menus, the message window, world-anchored marks (enemy bars, the target cursor, balloons, damage numbers) and the dim. The renderer scales a packet's position (its offset folded in) and its size about the anchor. At 1 it leaves the packet untouched, so the game's frames, and the 65 harness tests, are unchanged.

The minimap and two seams

The field's minimap (piney_world::map) draws whole into the layers. Layers::mark and map_since let area.rs shrink just its commands toward the top right: vertices, scissors (the inclusive ends widened to whole pixels) and texture coordinates.

At 0.6 a light line crossed the map. 0.5 and 0.75 were clean, and the line also showed at render scale 1. A dump of the map's primitives found it. The terrain is four tiles, and each stops 1/16 pixel short of the next (the top tile ends at 121.625, the bottom one starts at 121.6875). On whole-pixel positions that gap never covers a pixel's centre. Shrunk to fractional ones it can, and the sky showed through. A shrunk sprite's far edges are now taken from the next tile's start (+1/16 before scaling), so neighbouring tiles share one edge. Clean at 0.55, 0.6 and 0.8.

A shrunk cell's texture coordinates are pulled in by half a texel (Sprite::uv_inset, sprite::inset_uv). A bilinear sample at a fractional edge then stays inside its cell of the atlas.

the_hud_scale_shrinks_the_panels_into_their_corner (piney-fieldui) checks the frame at 0.5: the same primitives in the same order, every panel primitive half as wide and moved toward the corner, and the frame back to the game's at 1. A field shot at render scale 2 with HUD scale 1.0 and 0.6 shows the panels in the bottom left and the map in the top right.

"A Ryu Book reward's flicker is the game's own; the port draws the book once a frame"

2026-10-02T00:00:00Z

The user saw a Ryu Book "glitch out and in" for an instant when it gives a reward. The cause is the game's own loop. ccThBook (INF gcmn 0x0041a990) runs Breath; BOOK::Draw; BOOK::CheckItemGet; and then PadControl unless a reward ran. A reward's windows breathe inside CheckItemGet, each Draw; Breath until Check(0) answers. So:

the frame a reward starts draws the book twice: the loop's Draw, then the first window's;
the frame one ends draws no book: the last Check answers, the window closes, the reward is added, and the loop goes on to its next Breath.

Measured with tools/test_fieldui_rs.py's game run (Book I, 15 areas visited, the scenario of test_book_1). Frame 36 sends 36 bookWin and 2 bookBg packets, against 18 and 1 on the frames around it. Frame 102 sends none of either. The port matched that exactly; that is why the harness passed. On screen the book's translucent background flashes darker on the first frame and vanishes on the last.

Smoothed, by the user's choice: Book::frame draws the book exactly once a frame. It keeps the first frame's first draw (skipping a window step's second) and adds one on the frame a reward ends. Over a whole reward the draw calls are the game's count, one taken away and one added, so the book's state keeps the game's timing.

Book::as_the_game (on the book task, Task::as_the_game) restores the game's draws. fieldui_probe sets it, and the 65 harness tests still match the game frame for frame.

a_ryu_book_reward_draws_the_book_once_a_frame (piney-fieldui) opens Book I with its reward due, dismisses the windows, and requires one background on every frame from the book's first draw. With the game's draws it fails at exactly frames 35 (2) and 102 (0). The book's first frame (BOOK::BOOK, drawn after the loop's first breath) is the game's appearance, not a flicker, and is left out.

"Mutation's recall fades are smooth: its boards are rigid and key on their boxes"

2026-10-02T00:00:00Z

226 described the recall in MUT stream 23 (str0695e). Its pages cross-fade through a black board (MDL_blackbord_a01) one unit in front of them, or a white one for flashes. 226 took both as translucent models without a box and keyed them with the w-row formula. That key put the board first; the page behind it then failed the depth test, and every fade came out as a cut to black. 226 left open whether the PS2 shows them that way, since the page layout suggests smooth fades.

351 found the game's rule. Every model without mtype & 6 keys the sorted group on its own vertex box (ccModel::Init 0x0013a550, ccBbox_SetBox). Read from STREAM/STR2E.BIN::str0695e.tmp, every board is rigid: MDL_blackbord_a01, MDL_whitebord_a01 and all the MDL_bord_* are mtype 0, flag 0. So in the game the page, which is farther, is drawn first and the board over it.

The port now keys them that way (the change of 351). Stream 23 was shot again (English, frames 1000-1144, every 8): the WORLD BOARD page fades smoothly to black over about 32 frames (1096-1128). The fades 226 saw as cuts are smooth, as the layout meant. exact_key stays, now only for bone and skin models, and its comment no longer cites the recall.

"The top page's Key of the Twilight: a rigid model keys the sorted group on its own vertex box, not a Bbox chunk"

2026-10-02T00:00:00Z

Issue #25 and the user's reference: on the top page (INF xdttopen0) the sword carries "Key of the Twilight" in yellow down its blade, lit by an orange glow. The port showed a bare blade.

What the port drew

The text (MDL_xdtworld1, alpha 0.6-0.9) and its glow (MDL_xdthotw, alpha 0.2-0.4, scale 1.0-1.2) are children of the sword (ExtObj parent OBJ_xdtsword). The text sits 2000 units in front of the blade, the glow 3000. Both are translucent (texture flag 0x08) and so go to the layer's sorted group. Both alpha-test GEQUAL trunc(aref * t) with AFAIL FB_ONLY, so each writes Z where its alpha passes. The port keyed both with the w-row formula, M[2][3] / M[3][3], because no Bbox chunk names them. That key is the model's z scale over its depth: the glow (scale over 1) came first, wrote Z over its bright core, and the text behind it failed the depth test. In the opening the text showed at frame 110 and went when the glow came in. Drawn alone, each landed in the right place.

The game's rule

Every rule on the way was checked and agreed:

the w-row formula itself (ccModel::Draw 0x0013ebbc reads offsets 12, 28, 44 over 60);
ccDLSort::Add and the in-order walk (StoreDLNode 0x00108100, ascending);
AREF (ccSetMaterialPacket 0x0013e770, trunc(aref * t));
ZBUF never masked (set once in SetScreenModeMain);
the blend type (flag & 3; bit 3 dropped);
vertex alpha 0x80.

So the game itself was run. tools/test_effect_draw_rs.py's SceneMachine decodes xdttopen0 with the game's own DecodeSetup and builds ANM_xdttop1a with the game's ccAnm. Its matrices match the port's at every step tried (1, 30, 60, 120). Letting ccModel::Draw run natively under the camera's view then stopped in _ccCheckBoundingBoxEx. The game had taken the bounding-box branch.

ccModel::Init (0x0013a550) sets ccModel +4, the box pointer, to the model chunk's own box (ccModelChunk +0x10) for every model without mtype & 6, and to null for a bone or skin model. Decode_Model fills that box for every model through ccBbox_SetBox (0x001388c0). Per axis it takes the integer min and max over all vertices, starting at 0x10000 and -0x10000, doubled about the centre only for mtype & 6. The centre at +0x30 is ((min + max) >> 1) * vertexScale / 4096. Decode_Bbox fills a list of its own and never reaches it.

So a rigid model always keys on the screen Z of its vertex box's centre. The w-row key is only for bone and skin models. The desktop page and the port had it the other way round: a key from a Bbox chunk, and the w row for everything without one. Read from the chunks the game decoded, the centre matches the port's new vertex_box_centre on all 41 models of xdttopen0 and all 138 of xddesk01.

With the real key the text (screen Z 5342) is drawn before the nearer glow (5368). The glow lays its orange over the lettering, as in the reference.

Tests

the_key_of_the_twilight_is_drawn_before_its_glow (piney-toppage) at frames 150, 300 and 421. It fails with the old keying ("the glow drawn before the text").
model_box_centres_are_the_games: the sword, text and glow centres as the game's decoder gives them.

The desktop, demo, stream, world and game suites pass unchanged.

"The console wraps, scrolls with the mouse and lists its help in columns; render scale, vsync and an FPS cap"

2026-10-02T00:00:00Z

None of this is the game's. These are player requests for the port's window: issues #27, #28 and #29, and the user's asks for a scroll bar and a fixed help.

The console

Wrapping (#27). An answer wider than the window ran off its edge. Console::wrapped now breaks each answer into rows at its spaces, and a word wider than a row at its letters. A help line's second column wraps under itself. The typed line scrolls sideways to keep the cursor in view. Page Up / Down count rows as drawn.
Help columns. The description column sat at a fixed 140 pixels. pad_log [FILE|stop] is wider than that and ran into its own text, and deflicker [on|off] had one space where the split needs two, so it never split. The column now starts past the widest command, up to half the window. The window's commands are one list, APP_HELP, each line split by two spaces.
Tab. It took the first word of every help line as a command. At the title, where there are none, the line "no console commands here" made no one. Commands now come only from lines that split. help also left the recorded path: each F1 press used to write a help line into the pad log.
Scroll bar. A track on the band's right edge, with a thumb as tall as the visible share of the history. The mouse wheel scrolls three rows a notch, the thumb drags, and a click on the track pages.
History. Picking a part on the four-part selector (App::boot) made a new Console, so the answers and the lines typed went with the scene. It now keeps the console and only swaps the fonts (set_fonts). The lines typed are also kept between runs, in console_history.txt in the build's folder (the last 200).

long_answers_wrap, tab_completes_the_commands, the_scroll_bar_scrolls and the_history_is_kept hold these. The by-hand console_picture now draws a long line and enough history for the bar.

The window

vsync [on|off] (#29), --no-vsync: the surface's present mode, AutoVsync or AutoNoVsync, reconfigured on the spot.
fps_cap N (#29), --fps-cap N, 0 for none: about_to_wait holds the next redraw until 1/N s after the last picture (ControlFlow::WaitUntil). The game's frames keep their own clock (tick's vblank count), so the cap and vsync change only how often the picture is shown.
render_scale N (#28), --render-scale N, 1 to 8: Gs::set_scale. The frame buffer is N times 512 x 448. The draws keep the frame's coordinates, since convert maps them to clip space by the frame's size and normalizes texel coordinates by the logical size. Five things had to follow the scale:
- the scissor rectangles;
- the frame-buffer copies, both their regions and their textures, and the previous frame;
- the shadow packet's Z copy and composite, which read frame pixels (the uniform's spare slot now carries the scale);
- the composite's scissor;
- the half-pixel move that makes the GS's corner rule meet the GPU's centre rule (PIXEL_CENTRE, now 0.5 / scale). Without it every sprite edge fell one pixel out at scale 2, which the first run of the new test caught.
a_scaled_frame_buffer_draws_the_frame_bigger draws a frame at scale 1 and 2: flat sprites, a scissored one, a frame-buffer copy drawn back and a shadow packet. At 2 every pixel is the scale-1 pixel doubled, within 2 of 255, except along the shadow's bilinear edge, which is checked inside. Story 19's start shot at both scales lines up, sharper at 2. The other 22 GS tests are unchanged at scale 1.

the_tutorial_statue_s_glow_ends read DATA.BIN a second time for its GS. Under the full suite's 8 GB cap, in parallel, that read failed now and then: a read_path unwrap, later a 76 MB allocation abort. It now uses the session's archive.

"A revived member who ignores orders: not reproduced; what was ruled out"

2026-10-02T00:00:00Z

Two reports describe one bug. The user's run (INF, a dungeon's B3, Kite and Elk, a fight with six or more Water Witches, enemyTbl row 37) and issue #26: a member revived after dying several times ignores orders, both strategies and direct ones. Per #26 it lasts only in the room of the fight. In the user's video (work/video_of_bugs/20261002-0701-22.4608026.mp4) Elk is out of battle at 47/190 HP with full SP. He stands still, and says nothing to "Everyone, First Aid!" (16) or to "Elk, use La Repth!" (5 on Kite). His SP regenerates, so he is alive: condition_time_count runs only for dead 0. The run was not reproduced. This entry records what was checked, so the next look starts past it.

Every way an order is refused makes the member speak. ChatCommandFulfilCheck and the same-order branch of ChatCommand each say a line, and the accept lines for 5 and 16 are templates with no chance roll. A silent member means one of these:

The order never reached ChatCommand. Brains calls it only for party_flag 1. ccFellow::Main calls Brains only with an AI and without ghoFlag. A new order waits at chatCmdFlag -2 while goBackFlag is set and distPL is over 1750.
Its lines were dropped. chat_say drops them under manualSW, chat_gate needs party_flag 1, and chat_sender opens nothing while the party reads as wiped out.

manualSW fits the video best. Brains then runs ManualControl: the member stands still, never acts, and its lines are dropped. Its only writers are the registry's boot bit 2 at an area's set-up, events' ManualModeAI, and the tutorial. No death or revival path reaches any of them.

Also ruled out by reading:

dead 5 stuck: the revival count runs in fade every frame, and the member's SP would not regenerate.
A skill status or act left set: death and revival both clear skillID/skillStatus.
PAUSE: no AI decision reads it.
The message bus: entries are withdrawn only for party_flag -2. Down sends 0x1000c and up deletes 0x1000d. That is the game's own pairing, copied as found.
ocarinaUseFlag: set only by order 19 and never cleared in the port, which is worth a check of its own (it blocks messages and targets).
spcBattleCondition: 3 lasts one frame.
The UI's handles map to the right scene index.

Simulated (probes kept out of the tree, the diff in the scratch area), INF, story 19's field:

Elk killed and revived nine times, at the down act, lying and as a ghost, then ordered: he answered and healed each time.
Killed mid-cast, then revived and ordered.
A 40000-frame fight against two Water Witches with 56 deaths. Every order was taken. One was not carried out, for want of SP.
Seven Water Witches with Kite and Elk alone, random revive delays and random orders. All taken.
A monitor over eight seeds of 12000 frames, about 150 deaths, waves of 3-7 witches, random orders 0-18. It watched, while Elk was alive: manualSW, party_flag other than 1, an order parked at -2 over 120 frames, hold over 600, skillStatus over 900, an act of 7 or more over 900, no movement over 3000. Nothing fired.

"A spell holds its targets for its whole run: the effects' copy of holdFlag was never set"

2026-10-02T00:00:00Z

The user's video (work/video_of_bugs/20261002-0643-11.2822681.mp4, B3 of a dungeon, a Water Witch): its ice spell lands on Kite and he runs on under it. In the game a spell or art used against a character holds it where it stands while the skill runs. _ccSkillRequest (INF gcmn 0x00572860) sets the new ccSkill's holdFlag (+0x0d bit 0) for anything but the normal attacks (sids below 6), buffs, debuffs and heals. Each frame ccSkill::Main (0x005731d0) then runs ccSkillHold (0x005752b0), which gives the targets EntryAffect(5), condition hold. Kite's ControlMove, ccFellow's and the enemies' frames all stop on it. The battle crate had all of this.

An attack spell's run lives twice in the port: the battle crate's SkillRun and the effects crate's Spell, the copy its element system (Fall, Tornado, Convergence, Upheaval, Summons) runs on. The systems clear holdFlag at their own ends. So the world takes hold back from the effects' copy after each system frame (combat/mod.rs, r.hold = out.hold). But the copy was made by Spell::new (hold false) and Spell::sync did not carry the flag. The first system frame handed back false, and the hold lasted one frame. A probe showed it: Kite's hold condition 1 on frame 0, then 0, with the run's flag false from frame 1. Arts were not affected: they run no system. A probe of Kite's art 6 on a Mimic held it for its whole run until the art's note 6.

SpellRun now carries hold, and Spell::sync sets it before the system runs. With the fix, a foe's Convergence (213) on Kite holds him for 48 frames, until the system lets go.

Tests (session/tests/spell_hold.rs):

a_foes_spell_holds_kite: Kite runs with the stick held, then is held still under the spell for its whole hold, then runs again.
kites_spell_and_art_hold_the_foe: the foe's hold is 1 every frame of Kite's spell and of his art.

Both fail with the flag left out of the sync ("held only 0 frames").

"Ryu Books IV to VIII: their pages, lists and keys, each run against the game"

2026-10-02T00:00:00Z

317 ported Books I-III and left IV-VIII's pages: their DispNN, CheckItemGetNN, and PadControl04, 05 and 08. The rewards (GetBookNNItem) were already in. A player opened Book IV (issue #23, and the user's own run): an empty window, and the game stuck. BOOK::PadControl closes the book on cancel only once wait is 0, and wait (15 at the start) is counted down only by the page's own keys, which IV-VIII did not have.

All five are now ported (INF gcmn, the reference in field-ui.md). tools/test_fieldui_rs.py gains test_book_4 to test_book_8. Each runs the game's own ccThBook in eemu beside the port, frame by frame, over every sprite packet, kanji row, message state and sound. Every one passes, along with the harness's other 60 tests. A one-pixel change to Book VI's count column fails its test at once.

What the code showed, where it was not what one would guess:

Book IV (Disp04 0x00415790): the list's search for the next enemy slain runs to 304, one past the 303 rows. Row 303's kill count is then BOOK.checkValue[2], which Draw zeroes each frame, so it is never taken. The sub-window shows the enemy's enemyTbl row: base.level, max_hp (10000 or more spelled out of cheatHpStr), max_sp, the spells mag0/mag1 (skill +0x70, +0x74), the three items, and a weakness from the protect points (max_pp -1, else p_def_pp against m_def_pp). Its help line names where one was last slain: enemyKillArea (+0x69f0, server and three words) between #B and #W. The sub-window's column starts 40 higher than the list, which a first try got wrong and the harness caught.
Book V (Disp05, PadControl05): off the list the cursor moves with the held buttons (ccSys +0x2cc), not the pushed ones, keyWait letting a hold through every third frame. The harness's first scenario pushed DOWN and the game did not move; the emulator's BOOK fields showed every gate open, which led to the read of +0x2cc. Book V's help sets BookHelp50's second and third strings to NULL in place.
Book VI, VII (Disp06, Disp07): counter rows like Book II's, the count at a fixed 250 or 182. VII's first two rows say "encountered" (bookEncountMsg), and its third row stands a line lower.
Book VIII (Disp08, PadControl08): a menu with the Grunties (ccGetNpcParam(145 + i)) and their food (gimmickTbl[22 + i]); each page resizes the window by writing the global BookOfs. In the food list's help the count's sprintf is overwritten by the strcpy after it, so the line is the food's name and bookPuchiFood. On the food page the total moves down by repeat and up by the held buttons, and the list's "none above" sets keyWait where IV's and V's do not.

the_later_ryu_books_open_and_close opens each of IV-VIII in Mac Anu through PERSONAL's Key Items and closes it with cancel.

A lone slot file imports with its index record

2026-10-01T00:00:00Z

The user's repro save for 345 is one slot file, work/savecards/repro/dhdata12 (0x8530 bytes, INF). Put on the card, the load screen showed the slot unused. That is the game's rule. A slot is used only through its record in the save directory's index file (BASLUS-20267DOTHACK/BASLUS-20267DOTHACK, twelve 28-byte ccSaveDataInfos; the save page): status 1, and a sum the load checks. A slot file copied in without that record reads as empty. --import-card (338) took only whole save directories, so it refused the file.

card::import now also takes a lone slot file (dhdata01-dhdata12, or a folder holding only such files). import_slots writes each into its volume's directory and rebuilds its record as ccSaveSys's save does (SaveSys::write, 0x00173cf8): status 1, level, clearFlag, parodyFlag, the name from plName, the 16-bit sum of the file's bytes, playTime. A missing directory is first made as make_dir makes it, twelve zeroed slots and a zeroed index. An existing one is copied to the backup- folder first, and the other slots' records are kept.

The size picks the volume. 0x8530 is Infection's. 0x8d84 is any later volume's, and also an Infection slot as a PCSX2 export can hold it (338), so it takes the volume of the running disc (the console) or --volume (the command line) and is refused without one.

a_lone_slot_imports_with_its_record checks the record (check_right_info passes, name, sum), the other slots left empty, the slot read back, the 0x8d84 case with and without a volume, and a size of no save. The user's dhdata12 imported into an empty card: slot 12 used, Kite, level 11, clear 0, sum 0xd4f7 (the file's own), 6.28 hours.

"Three player reports: a node keeps its own transparency, the book's cover every frame, one area a gate trip"

2026-10-01T00:00:00Z

Three issues from the same player, all INF.

#20: the Gott statue vanished once its box was looted

The screenshot shows a dungeon's B3 with the statue gone after "You now have Rainbow Card!". 319 made Body::draw multiply each node's animated transparency by its parents', as it read ccCoord::_GetTransparency (main 0x00138490). That reading was wrong.

_GetTransparency walks to a node's parent (+0x80) only while the node's flag bit 0 (+0x8c) is set. SetAnmCtrlWork (0x001507c8) writes the animated value to the node's local (+0x88). With bit 0 set it marks the node for that walk (bit 2); without it, it writes the value straight to the world transparency (+0x84). Bit 0 comes from the object's Obj2 chunk (flags, "transparency inherits the parent's"): Decode_Obj (0x0014cb30) copies it to ccObjChunk+0xc, and ccClump::Init (0x0013c718) tests it. A node with no Obj2 chunk has flags 0. Every Obj2 chunk in the four volumes' DATA.BIN was read: about 219,000 to 221,000 a volume, and none has bit 0. So a node's transparency is its own animated value and nothing else. ccClump::Init does put the root under the clump itself (0x0013c944), but with bit 0 clear that link is never walked for transparency.

The seven statues (xgs?bod1) show what the product broke. In the d, f, l and w statues, the fall ANM_xgs?dwn0 and ANM_xgs?nut1 key the root OBJ_trall to 0 from frame 0. Multiplied down, that hid the whole statue the moment it began to fall. In a, e and t the root stays at 1, which is why 319's tutorial statue (a) looked right. Body::node_alphas now returns each node's own value. a_fallen_gott_statue_stays_drawn poses all seven at the fall's last frame and at nut1: OBJ_o_god_m0_ at 1, the ring at 0. The enemies' models share the function.

#21: the Ryu Book's cover strobed

The player's video (work/video_of_bugs, not in the repository) shows the cover stream every other frame, with black between. Worklog 336 moved the town's menu task after the event task. The menu task steps the book's stream (ccThBook's ccThExecuteStream) and leaves its frame in st.stream.frame. But the step reads that slot only before the menu task runs, so the frame showed one game frame late. On that later frame the step returned at once, skipped the menu task, and so stepped no stream; the next frame showed the town's own picture, black in the video. The stream thus advanced every other frame. Half the cancel presses landed on frames that never stepped it, which is the "sometimes the button doesn't register" of the report. The town now shows the book's frame as soon as the menu task has made it. read_a_ryu_book (behind a_ryu_book_opens_in_town) checks that the cover's frame moves on every frame it plays. Without the fix, 360 frames stood still.

#22: "Number of areas visited" 141

The player's save (work/savecards/repro/dhdata12) holds 141 at +0x6862, the counter Book I shows (BOOK::Disp01, gcmn 0x00410640). A scan of the code for stores to +0x6862 finds five pairs in GCMN.PRG (a store and its clamp to 10000, at file offsets 0x15d5ec, 0x15e9ec, 0x162708, 0x163770 and 0x16644c; the first is GtRandomMenu's, gcmn 0x0055dde4). MainProccess copies it on load and save, and ccSaveData::Init zeroes it. The port has the same five.

But a gate's leave state (Random's 5, New Keyword's, the lists' 7) stays put once leave returns true. Every frame the menu runs after that, it counts again and asks GoToArea again. In the game the menu task sleeps in the ChangeRequest its SetGenerateCode makes. The port's session runs the town for the 10 frames of the leave's fade, and the town ran its menu task through them. a_random_warp_counts_one_area takes a new game's Random warp from Mac Anu: 10 counted without the fix, 1 with it. The town now skips its menu task once it has asked to leave (leaving). The 141 is about 14 trips. A save already counted stays as it is.

"sound 8 0 256: five uses, and port 0 always takes the SE option"

2026-10-01T00:00:00Z

176 left open "whether the SE port's volume is ever below full when sound 8 0 256 runs". The answer does not change what the instruction does. ccPortVolSet(port, vol) (INF main 0x0017ad70) gives port 0 seVol whatever vol is, so sound 8 0 256 puts the SE port back to the player's SE option from any value. The driver's port_vol_set (crates/piney-audio/src/driver.rs) does the same (0 => se_vol).

The uses, from tools/evscript.py dump of each volume's executable:

volume	tables with `sound 8`	all
INF	M110, M131, M216, M319, M414	`8 0 256`
MUT	the same five	`8 0 256`
OUT	the same five, and S410	`8 0 256`
QUA	the same five, and S410	`8 0 256`

M110's is the first instruction of its block 0. M131, M216, M319 and M414 each run it right after their ending streams and overlay 1. S410 (Mia's event 360) runs it after stream 138 and call_on 1. All but M110's follow a stream. What lowers port 0 before it would be one of ccPortVolSet's 47 calls (ccSndChangeOption, ccSqPlay, ccSqPlayVol, ccSound::ccFade, ccSceneFade, ccSndSQLoad, ccSndChangeData). None of those calls was followed to port 0 here, since each lands on seVol the same way.

sound.md now lists the six places.

A lake's dungeons: every entry goes with the scene, and entryFlag places them again

2026-10-01T00:00:00Z

191 left two questions about a lake's way between its dungeons. The first: come_back builds the room's doors open, where the game asks ccCheckActiveObject. The second: what reads WORLD_MAN+0x58[n], which Enter and GoField clear. Both answers came out of ccThEntryCtrlDelete and WORLD_MAN::EntryGimmick. The port had the lake's portals, boxes and idols wrong on the way back: carried over where the game deletes them, and never placed again.

+0x58[n] is EntryGimmick's entryFlag

WORLD_MAN::EntryGimmick (INF main 0x001a1f20), which ccThEntryCtrl's set-up calls:

WORLD_MAN.flag 1 (a field):   game.field 0: entryFlag[0] (+0x54) 0 ->
                                  WORLD::SetFood, SetMagicCircle, SetSpecialObj
                              else: +0x124 0 and +0x54 0 -> the same
WORLD_MAN.flag 2 (a dungeon): entryFlag[1 + game.dungeon] (+0x58 + 4 n) 0 ->
                                  DUNGEON::SetItemBox,
                                  SetMagicCircle (not with volumeNum 2 and game.field 27),
                                  SetIDOL; then the flag = 1
                              EntryBreakObject every time

A scan of every WORLD_MAN method and every main function that loads worldman finds three other stores to +0x58, all clears of the dungeon being left: Enter on a lake's stairs down (0x0019e240) and on dungeon 1's floor-0 stairs up (0x0019e104), and GoField from dungeon 1 (0x0019e45c). The sw $zero, 0x58 in ccSetupGameCtrl (0x00168c3c) is game's, inBattle.

A new scene keeps nothing

ccThEntryCtrlDelete (gcmn 0x00431d10) keeps the circles and the objects not owned by a circle or a corpse in g_entryList only when ccGame::CheckSceneReplace() (main 0x00167580) is false. That function returns 1 when any of CompArea, CompTown, CompField, CompDungeon finds the value differs from its previous one (+0x14/+0x18, +0x20/+0x38, +0x24/+0x3c, +0x28/+0x40). Otherwise it deletes every object. A room of the same dungeon is not a new scene. A lake's other dungeon is, since game.dungeon changes. So at that change the lists are emptied, and on the way back EntryGimmick sees the cleared flag and places the lake's boxes, portals and idols again.

That also answers the doors. GO(2)'s SetRoom(0, lastRoom) runs before ccThEntryCtrl starts, with the lists empty, so SetDoor's ccCheckActiveObject(0, lastRoom) (gcmn 0x0042e010: 0 when an entry of either list is at that floor and block) answers 1 and builds them open, as come_back does. MoveDoor then shuts them each frame ccCheckActiveObject() finds an entry switched on in the room.

The port

FieldWorld::keep_entries called EntryCtrl::keep(cx, true) (the "left for a moment" case) on every way out of a dungeon. It now passes !Scene::changed(). That function is ccSetupGameCtrl's test and the same four comparisons. DungeonArea::enter clears gimmicks_placed on the lake's two stairs, and FieldWorld::go_field clears it in dungeon 1.

Before, coming back up the lake kept its entries from the first visit and did not place them again. a_lake_keeps_both_its_dungeons now plays each visit of area 33 to Play(3). With the flag cleared as Enter clears it, the lake holds 3 portals and 10 gimmicks on both visits. With the clear but without the replace rule, the second visit had 6 and 20. a_type_4_area_goes_down_into_its_second_dungeon_and_back checks the two stairs' clears.

The opening stream's flashes over the stream: the cancel's and the end's

2026-10-01T00:00:00Z

The title's intro stream has two white flashes, and the port got both wrong. A cancel push's flash was not modelled. The end flash was entered only once the stream had finished, then advanced 20 frames at once. So the stream's last 20 frames never faded to white, and the menu came in partway through the fade-out.

The game

PlayOpeningStream (INF demo.prg:0x004066b0) starts ccThExecuteStream at priority 33 with the stream number in its param +0x14. The count is 410 for volume 1's plain stream and 450 with m_ParoFLG. INF's switch on m_NowVol gives volumes 2-4 450 and 490. It waits for ccGetStreamAdrs() and then the stream's +0x17e bit 3. Then, each frame (0x00406838), before the stream's own task (the same priority, started later):

pad push & saveData.assignPADcancel (+0x8410) and s1   EntryFlash(50, 0x80ffffff), s1 = 0
the stream task's +0x14 == -1                           return
ccGetStreamFrame() == count - 20 and s1                 EntryFlash3(20, 20, 5, 0x80ffffff), s1 = 0
ccBreathThread(1)

The flashes go to scFadeDef over (0, 0, 512, 384). A cancel does not end the stream; the stream's own skip rule does that. It only flashes, and it spends s1, so the end flash never follows it. MUT (demo.prg 0x00419720), OUT (0x004153e0) and QUA (0x00307d40) run the same loop. OUT and QUA keep the count and the flag in swapped registers and load the rectangle's 512.0 and 384.0 from constants (OUT 0x0041db58, 0x0041db50).

The port

Demo keeps the count from its Request::Stream as stream_flash, the port's s1. While PlayOpeningStream holds the title, the session calls Demo::stream_tick(pad, frame) before each of the stream's steps, from its first step on, with StreamPlayer::frame(), the frame the last step drew. After the step, Demo::stream_fade draws scFadeDef over the stream's picture. Phase::Stream now just goes on to the title. The demo's own frame keeps sending the fade, so the flash runs on over the menu. advance_one is gone.

the_opening_stream_flashes: played through, the flash starts on the step that draws the stream's frame 391 (the check saw 390). It lies over the stream's last 20 frames (391-410). The stream then shows frame 0 twice as it ends, and the menu comes out of the white, 47 frames lit in all. With cancel pushed on the 100th step, white starts on that step and lasts 50 frames, the stream ends two steps later, and no second flash comes.

The map button behind ccThGameCtrl's waits, and no map in a fight

2026-10-01T00:00:00Z

77 left two map gaps open. The map button was taken whatever held ccThGameCtrl's other buttons. The field's and dungeon's map was drawn through a battle. Both now follow the game.

Where the map button's test is

ccThGameCtrl's loop (INF gcmn 0x005178f0) runs, each frame, in this order:

Breath(1)
checkPartyAnnihilation() or compulsionGameOver   the game over: the task
                                                 never comes back to its loop
ccCtrlRecoveryReq, ccSortCmnd x3
ccMenu+6 != 66: SetInBattle(...) or inBattle = 0
ccCheckGtHackAnm()   (0x00517d58)               non-zero: back to Breath
menuClrWait > 0      (0x00517d68)               menuClrWait - 1, back to Breath
the map button       (0x00517d84)               assignPADmap and CheckOperate(13, 0)
ccPlayerMenuCheck ... the other buttons

The port's Targeting::frame (piney-world talk.rs) already ran the game over, ghoFlag and menuClrWait in this order for the other buttons. The map button was piney-game's, and it ran before the task with no gate. Now Targeting::map_test is set when a frame gets past menuClrWait. Both worlds clear it at each step_game_ctrl and expose it as map_test(). The town (world.rs) and the area (area.rs) press the map button right after step_game_ctrl, only when it is set. The mode change still lands before the menu task and the draw, as in the game. Nothing between the old place and the new reads the mode.

menu_clear_holds_the_map_button_two_frames checks the gate in a town's Targeting::step. A menu_clear before the second frame holds the test for two frames (true, false, false, true, true). The task's first five frames, which only sort, do not hold it.

No map in a fight

WORLD::Draw calls DrawMiniMap only while ccGame.inBattle (+0x58) is 0 (INF gcmn 0x005a9890-0x005a98a4). DUNGEON::Draw calls MakeMiniMap for the room under the player every frame, and DrawMap only while inBattle is 0 (0x005cef64-0x005cef78). MUT, OUT and QUA test game +0x58 before DrawMiniMap the same way, and step menuClrWait the same way in ccThGameCtrl.

map::area_frame takes in_battle. In a field it draws nothing then. In a dungeon it still enters the room (MakeMiniMap) and draws nothing. Its last is emptied, so a sleeping frame after it draws nothing again, as no packets were made. the_map_is_away_in_a_fight walks to event 3's east portal, fighting its goblins: 237 fight frames, no map in any of them, and the map on the walk before. With in_battle forced false the same run has the map's packets in all 237. In a dungeon, the_minimap_stays_across_floors (area 23's floors down to the shrine) now leaves the fights out of its per-room count and checks them apart: 1,424 fight frames, no map in any. Before, it had counted the fight frames as frames the map must draw in.

The frame-mode deflicker: read circuit 1 a line lower, merged at ALP 127

2026-10-01T00:00:00Z

While working out SetDisplayOffset's units (339), a second pair of DISPLAY values turned up at ccSystem +0xe10 / +0xe20. It is the game's deflicker. In frame mode, the mode the game runs in outside the movies, the GS shows the frame buffer through both read circuits, one a line lower, merged half and half.

The game

SetScreenModeMain (INF SLUS_202.67:0x0010ad40), when the field flag (+0xbd6) is 0, after sceGsSetDefDBuff:

0x0010b4e8  both buffers' PMODE (+0xbe0, +0xc08): bit 0 (EN1) set
0x0010b51c  their ALP byte (+0xbe1, +0xc09) = 127
0x0010b524  +0xe10 = buffer 0's DISPLAY (+0xbf8), +0xe20 = buffer 1's (+0xc20)
0x0010b534  each copy's DY + 1

libgraph's PMODE is 0x66 (sceGsSetDefDispEnv 0x0010dea0): EN2, CRTMD 1, MMOD 1 (the merge's alpha is ALP), AMOD 1, SLBG 0 (circuit 2 is the background). Each frame SwapDoubleBuffer (0x0010ac40) writes, in frame mode, the shown buffer's DISPFB (+0xbf0 + 40 n) to DISPFB1 (0x12000070) and its copy (+0xe10 + 16 n) to DISPLAY1 (0x12000080). sceGsSwapDBuff then puts the buffer's own environment, with DISPFB2 and DISPLAY2. SetDisplayOffset keeps the copies a line lower (339). So both circuits read the same buffer, circuit 1 a line lower, and a screen line comes out as ALP / 255 x the buffer's line above + (1 - ALP / 255) x its own, about half each. On an interlaced TV that softens one-line detail that would flicker between the fields. Field mode (the movies' SetScreenMode(640, 448, 2)) skips all of it and sets sceGsSetHalfOffset instead.

PCSX2's "Anti-Blur" option, on by default, is meant to undo blurs of this kind, so PCSX2 players see the sharp picture. That is from the option's description; it was not tried here.

The port

Frame::field_mode (piney-draw) says how a frame is shown. It is false for the game's frames and true for piney_mpeg::movie::draw. Gs::render remembers it. piney_gs::Pcrtc carries the display offset and deflicker to Presenter::present. The shader's merged() mixes the moved picture with itself one row (1/448) up, at 127/255, before the sRGB conversion: the GS merges the stored values. Above the top row the line above is black, as circuit 1 there has nothing to show.

The port's picture is progressive, so there is no flicker to fight, and the present is kept sharp (its sharp bilinear). So the merge is off by default, like PCSX2's anti-blur. --deflicker and the console's deflicker on|off switch it (README "Play").

present_merges_the_line_above_in_frame_mode draws a one-row white line at row 200. Sharp, rows 199-201 read 0, 255, 0. With the deflicker they read 0, 128, 127, 0. A field-mode frame keeps 255, 0.

Adjust Screen moves the picture: SetDisplayOffset's units, and the presenter's shift

2026-10-01T00:00:00Z

Adjust Screen (the desktop's ScreenMenu, INF SLUS_202.67:0x0016d4d0, and the field Option's, INF GCMN.PRG:0x0053f060) calls ccSystem::SetDisplayOffset(x, y) every frame it is open. The port's menus already asked for it (Request::DisplayOffset), but the game dropped the request, so the option did nothing (50, 51, 196). The picture now moves.

What the offset is in

SetDisplayOffset (INF SLUS_202.67:0x0010ab30) keeps (x, y) at +0x20 / +0x22 and writes base + x (clamped 0..4095) and base + y (0..2046) into the DX and DY of both display buffers' DISPLAY register (+0xbf8, +0xc20). With the field flag (+0xbd6) 0 it also writes them, y + 1, into read circuit 1's pair at +0xe10 / +0xe20, the game's deflicker (340). The base (+0x1c, +0x1e) is DISPLAY's DX and DY as SetScreenModeMain (0x0010ad40) leaves them after sceGsSetDefDBuff (0x0010b57c-0x0010b594).

ccSystem::Init (0x0010a900) asks SetScreenMode(512, 448, 0), which SetScreenModeMain turns into sceGsResetGraph(0, 1, 2, 0): NTSC, interlaced, frame mode, one 448-line buffer. sceGsSetDefDispEnv (0x0010de50) sets, for NTSC interlaced:

MAGH = (2559 + w) / w - 1      4 at 512 wide (5 clocks a pixel), 3 at 640
DX   = 636 + dx * (MAGH + 1)
DY   = 50 + dy
DH   = 2 h - 1 (field mode), h - 1 (frame mode)

So DX counts video clocks (2,560 across the picture at either width), and DY counts lines of the interlaced frame: one row of the 448. Adjust Screen steps x by 3 (-48..48) and y by 1 (-16..16), up to 9.6 pixels across and 16 rows down. An earlier draft of this change took y as half-lines and halved it; DH = h - 1 for the 448-line frame mode shows a DY unit is a whole row.

MUT, OUT and QUA have the same SetDisplayOffset (MUT 0x0010abd0, OUT 0x0010b1a0, QUA 0x0010af70; OUT's and QUA's differ from INF's only in instruction scheduling) and the same constants in sceGsSetDefDispEnv (636, 50, 72, 656).

The port

Event::DisplayOffset { x, y } carries the request out of the desktop, the title and top page (through desktop::event), the town (world.rs) and the fields (area.rs). Two places set it from the save, as the game does through its own SetDisplayOffset(screenX, screenY) (title): the title's boot, where the kept settings (crates/piney-game/src/settings.rs, screen_x / screen_y) are already in the save, and LoadGame.

The app keeps the last offset and hands Presenter::present a shift of (x / 5, y) in pixels of the 512 x 448 picture. The presenter moves the picture in its shader (picture(): the sample point less the shift, black outside the picture), inside the same 4:3 box. A viewport moved by the shift was tried first, but wgpu rejects a viewport that leaves the attachment, which a window with no bars would do at any offset. The console overlay does not move.

present_moves_the_picture_by_the_display_offset presents a cleared frame moved an eighth across and down on a 600 x 450 surface: black left of x 75 and above y 56, the colour from there. options_kept_across_the_parts writes screen_x = -12, screen_y = 7 into the settings file and sees DisplayOffset { x: -12, y: 7 } at power-on.

"Saves from PCSX2: a PS2 card image reader, the import, and Infection slots of 0x8d84"

2026-10-01T00:00:00Z

Players asked to bring their PCSX2 saves over. The port's card is a directory laid out as the PS2 card is: <dir>/icon.sys, the icons, the index <dir>/<dir> and dhdata01-12 (the save page). So a save only has to be taken off PCSX2's card and its files copied across.

PCSX2's cards

PCSX2 keeps a card as one of two things:

a folder card: a directory per save, with PCSX2's own _pcsx2_index (a YAML-like list of each file's order and times) beside the game's files;
a card image (Mcd001.ps2): the PS2 memory card's file system, 8 MB of 528-byte pages (512 bytes of data and 16 of ECC).

The folder form needs copying only. The image needs a reader. piney_data::ps2card (new) reads it:

the superblock: magic "Sony PS2 Memory Card Format ", page size, pages a cluster, alloc_offset, the root's cluster, ifc_list;
the FAT through its indirect clusters;
the 512-byte directory entries (the root's own "." gives its count);
a file through its FAT chain.

ECC is assumed when the image is a power-of-two count of 528-byte pages. a_save_directory_reads_back builds a card with and without ECC (a file over two clusters, an empty one) and reads the directory back. No real .ps2 image was at hand. The reader follows the format as published, and an image from a real card is still to be tried.

The import

piney_desktop::card::import(src, card) finds the four volumes' save directories (own_dir_name of each, from mcDirName) in any of three sources:

a .ps2 image;
a folder card;
one exported save directory.

It copies each found directory whole, leaving out _pcsx2_*. A directory it replaces is moved to a fresh backup-<secs> beside the card. It is reached through piney-game --import-card PATH, which imports and exits, and through the console's import_card PATH. a_pcsx2_save_imports checks a folder card, the backup, a lone save directory and a source with no save. The user's export (work/savecards, not in the repository) imports its 17 files.

Infection slots of 0x8d84

The user's export holds Infection's directory (BASLUS-20267DOTHACK, the icon10/11/12.ico icons), but its twelve slot files are 0x8d84 (36,228) bytes. That is the later volumes' size; Infection's own MakeDir makes them 0x8530 (li 0x8530, INF SLUS_202.67:0x001660d4). Slots 1 and 12 hold a cleared game (level 34, clearFlag 1). The index record's sum covers the whole 0x8d84 bytes (slot 1: 0x599, against 0xc31b over the first 0x8530). The first 0x8530 bytes are the same ccSaveData.

Infection's own load (and the port's) summed 0x8530 bytes and would refuse the slot. At the user's request the port now takes either size. The card's read_slot hands over the whole file, and the load accepts the sum over the volume's size or, for a longer Infection file, over 0x8d84. It copies the 0x8530-byte record as before. an_infection_slot_loads_at_either_size covers both sizes, a wrong sum, and (when work/savecards is present) the user's slot 1.

A member's equipment remark in town

2026-10-01T00:00:00Z

67 left the CHAT menu's ChangeEquipReport dropped in town. In a field, FieldWorld::equip_report has the member answer the settings it was left (ccSpcChar::ChangeEquipReport(n), gcmn 0x0059f4a0):

n 0: ChatMessageEquipOK;
n 7: ChatMessageEquipNOT(1);
n 1-10 otherwise: ChatMessageEquipNOT(0);
Kite, or any other n: nothing.

The town's WorldMode listed the request among those it drops.

The town's party has the same AI. World::equip_report(code, n) now runs chat_line on the member through with_ai, as chat_cmd runs its orders. The line is queued like any line raised outside the frame. The town's frame (Combat::town_frame, drain_chats at its start) sends it the next frame, and WorldMode puts it up over the member, as the field does. The menu's R::ChangeEquipReport goes there.

The test is a_member_reports_his_equipment_in_town (piney-game, event22). In Mac Anu with Piros in the party, Kite's report and an n of 11 put up nothing. Piros's report with 0 puts up his balloon on the next frame.

"The menu task runs in its place: ccThGameCtrl, ccThMenu, then the world"

2026-10-01T00:00:00Z

334 found the cause of 101's late words. The game runs, in this order:

ccThGameCtrl (33);
ccThMenu (34);
the camera (40), the party (48), the entries (64), the effects and the skills.

The town's and the field's modes ran the menu task after every world task. Every request the menus make (a skill, an item, an order) therefore reached the characters, and the sound it leads to the driver, a frame late.

The change

FieldWorld::step_game_ctrl and World::step_game_ctrl (the town) run ccThGameCtrl on its own, under the same condition as before (play from F1, awake). Their frame skips it once it has run (ctrl_done). Anything that only calls step_into behaves as before.
AreaMode::step now runs:
1. the event task, the map button and the ride's slot;
2. step_game_ctrl, then what it raised: the game over's first step, the talks, the attack flag;
3. the new menu_task: Data Drain's movie, the ride's and the Fairy's Orb's slots, ui.step_into and its requests, which carry out item uses and steps at once;
4. world.step_into, the camera on;
5. the shows, the sounds, the menu's rules, the chats and the map.
The menu runs from F1, which is the frame it ran in before (the old test of f >= 2 came after the world had counted the frame). Data Drain's black now keeps the world out of the frame by stepping it into a frame of its own, not by clearing what was drawn, which would have wiped the menus.
WorldMode::step (the towns) does the same. The book's stream and the gate hack's screen go the same way. The walking PCs' and the members' chat lines come from later tasks, so the menus show them the next frame, as in the game.

The tests that moved

Five tests assumed the old order:

a_skill_in_a_fight_names_itself now also requires Kite's SkillWords in the frame the target is confirmed (menu 65's CROSS). The old order fails it (words at 249, confirm at 248). The new one passes.
a_spell_lands_through_the_effects: the blast's noise reads 20 at the frame's end, not 19. SetNoizBs(20) comes from the effects (80), after the menu task's Disp (34) has drawn that frame's noise.
the_last_portal_puts_up_its_banner: 91 frames on, not 90. The entry control (64) starts ccThDfComp after the menu task, so its first Main is the next frame, and it then runs its 90 Mains. Before, the port started and ran it in one frame.
a_scroll_on_a_foe_is_cast_by_kite watched for skill_id 193 at a frame's end. The request sets it, and the party's and the skills' tasks clear it in the same frame, as the cast (act 17) begins. Only the old order left it visible, so the test now takes the cast's act as the use.
chat_a_member_to_heal_in_a_fight recorded the order after scanning the frame's events. The member now names Repth in the order's own frame.

The piney-game (204), piney-world and piney-fieldui suites pass. So do Mutation's and Outbreak's whole stories.