Crack eeu.iof's type field via real DBAL.OUT disassembly Disassembled 5 real functions (unpack_intersection_offset_rec, db_get_minor_road_list_type/_offset/_count, db_get_crossstreet_offset) directly from dbal/V010_015/DBAL.OUT using capstone -- this small unlinked ET_REL object has full .text content in-file, unlike FHDD6.FLI's disassembly wall. Confirms the real struct IOF_Record and the real in-memory field mapping, and cracks type's actual role: a validity gate (type must be 0 for offset to be valid) plus a tri-state cache-resolution flag (type==1 means the stored count is provisional and gets recomputed from a live IntersectionList cache). Also refutes the natural "type selects minor-road vs cross-street list" guess -- cross-street lookups go through a completely separate in-memory hash cache.
Close eeu.iof's anchor-list-ordering question: comprehensively refuted Tested 5 more orderings beyond the earlier alphabetical check, on a real 60-anchor random sample: distance from the anchor, the list's own eeu.rd index (ascending/descending), compass bearing, and name length (ascending/descending). Every one scores 0/60 exact matches. List order is most likely a construction-time artifact rather than anything recoverable from the entries' own content.
eeu.iof: narrow anchor selection (route-numbered roads 7.5x enriched) Mirrors the main repo's research/iof_reader.py update. Anchor names (the 31,318 records with a "nearby street names" pointer) match a route-code-like pattern (B215/SP246/L1-shaped) 44.80% of the time vs. 5.86% for non-anchors at full file scale -- a real 7.5x enrichment, but not a clean 1:1 rule (only 2.66% of all route-like-named records are anchors), consistent with anchors being a deduplicated subset rather than one per road segment. Also documents a 3rd count-field correlation hypothesis tested and refuted: eeuz.rl's own per-eeu.rd reference count correlates slightly NEGATIVELY with the common-case count (r ~ -0.08), the wrong sign, despite covering 95% of eeu.rd vs. eeu.il's 8.4%.
Advance eeu.iof: eeu.mod schema names, il-reference-count correlation, correct eeu.rd bytes[1:5] eeu.mod names the table intersectionOffsetFile with real fields offset/ type/count, confirming and renaming zero4/vb/c80. type's value shape (0x80 default vs {0,1} for real anchors) now reads as a clean bit-7 discriminator. New lead for the long-unresolved common-case count field: correlates moderately (r~0.21) with how many eeu.il entries reference the same eeu.rd record -- a real signal, not an exact formula. Two other hypotheses (eeu.rd's own bytes[1:5]; local road density as a literal intersection-count proxy) were tested and refuted. Major correction found along the way: eeu.rd's bytes[1:5] has 6,174 distinct values at full file scale, not '~5 distinct patterns' as previously reported from a small sample. Also refutes the direct-embed hypothesis against eeu.si's own bit layout. Fixed across eeu-rd-Road-Routing-Graph.md, eeu-si-Segment-Classification-Table.md, eeu-mod-Database-Schema.md, eeu-iof-Parallel-Road-Array.md, Home.md.
Document the eeu.iof nearby-street-names pointer crack
Add full file-format wiki: home status table + per-file detail pages Documents every file on the CD_8555 map disc (db/ folder): byte layouts, decode status (cracked/partially cracked/not examined), and validation evidence for each, distilled from the main repo's README research log. Covers the road graph (eeu.rd/.il/.iof/.typ), the road/city name-search catalogs (rt/rl/prl, cty/cl/ct, ctr), the MAP_COMPRESSED tile format (mp0/mg1-mg4) including tile geometry and the topology/adjacency table, the eeuz.fea gazetteer, the FLAT_COMPRESSED container, ISO handling, and a first-look triage of the 16 files never examined at all. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>