db_page_pcl_V000

Part of Firmware Reversing.

• String location: file offset 0x9f8620 (plain debug-string scan, not the symbol table)
• Status: ⚪ Name only — no code address found
• Also known as: fp_db_page_pcl / _fp_db_page_pcl (the external function-pointer name DBAL.OUT itself uses — see below)

Resolves a parcel/tile reference to the actual decompressed in-memory "parcel" structure — the function this project's own on-disc MAP_COMPRESSED reader would need in order to directly compute where a feature's topology table starts, instead of searching for it (see Tile Geometry and Topology).

New this session: confirmed as a real, heavily-used external callback from DBAL.OUT

DBAL.OUT (the map-disc-shipped database library, decompiled separately — see the main README) calls this exact function via an external, never-locally-assigned pointer, _fp_db_page_pcl, from ~30 call sites across its own db_find.cpp, db_succ.cpp, db_vid.cpp, db_turn.cpp, and more. Confirmed by grepping every occurrence in the decompiled source: the pointer is only ever called, never assigned, anywhere in DBAL.OUT's own ~1,900 functions. This firmware (FHDD6.FLI) is confirmed to be the thing that loads DBAL.OUT dynamically at runtime (real strings: "dbaLib: DBAL version is dynamic linked", "loadModule for dbal.out") — so db_page_pcl_V000 is almost certainly the real firmware-side implementation DBAL.OUT's _fp_db_page_pcl resolves to at module-load time, not a coincidentally-similar name.

Two sibling DBAL.OUT functions that index into the same "parcel" structure this call returns were compared side by side: db_copy_node (used via db_page_pcl, copies a topology node's fields with a branchless clamp capping degree at 8) and gcopy_node (reached from db_succ_main, reads the full degree nibble uncapped, up to 15, with no clamp at all). This independently confirms — from the DBAL source itself, not just this project's own empirical ground-truth testing — that _topology_record_fields()'s existing min(degree, 8) cap is correct for the function this project actually needs. No code change required; see Tile Geometry and Topology for the format itself.

Why there's no address

Same structural reason as every other db_*_V0NN accessor name (see db_vid_get_map_id_V000): this string lives in a debug-only pool never referenced by executing code, confirmed by a lis/addi absolute-address correlation sweep and a dedicated DWARF2 parser finding zero real compiler debug info anywhere nearby.

A second, different-looking lead was also checked and ruled out: a nearby function literally named db_upack_nodes_compressed_fast decodes node records with a genuine LEB128-style variable-length integer (readZValue), which looked at first like it might be the real on-disc node-table encoding. Tested directly against this project's own validated ground-truth tile bytes (mg2 tile 20597, real table_start) — decodes to garbage (an 835,445 "segment id" on the very first record). Confirmed to route through the same mapView_o/DBFView named-field schema abstraction already identified as a different physical data source, not an alternate decode path for the bytes this project reads directly off the map disc.

Closing this further would need the original unstripped firmware build or a debugger on real hardware — not more searching of the files already in this project's possession (every firmware-adjacent binary across 3 real builds spanning 2012-2014 has been checked; see Firmware Reversing).