Crack all remaining eeu.rd header bytes via eeu.mod's own binary field descriptors + DBAL.OUT disassembly
Disassembled db_road.cpp's read_current_record_from_database in DBAL.OUT
to get the real field read order and names (countryID, cityID, prefix,
suffix, rdtype, roadinfo), confirming delta_long/delta_lat get converted
to a max-corner on read. The real unlock was eeu.mod itself: its binary
bytes (not just the field-name strings already extracted) carry a real
per-field width/bit-offset descriptor, cracked this session and
validated byte-exact against eeu.ctr's own known layout.
Applied to eeu.rd's schema block and validated against real file data:
cityID (bytes[1:4], 24-bit) shows 50.3% same-value match among
geographically nearby records vs ~0.025% expected by chance; typeID
(bytes[5:7]) ranges 0-2571, matching eeu.typ's 2,574 real entries almost
exactly; roadInfo bit0 (highway) correlates with route-like names at
89.95% vs 0.10%; suffixID/prefixID (byte[0]'s two nibbles) are
independent and both span the full 0-15 range. All 8 previously
unresolved header bytes are now accounted for, with zero bits wasted in
the roadInfo byte's 6 packed sub-fields.
Explain zone-3c mystery values as a misalignment artifact, not real data
Document new real pronunciation-guide panel row
Confirm eeu.abc (flag_a,flag_b) meaning; document zone-3b refutation
Document route<->destination sign grouping wired into viewer
Document regex fix and Y/ZZ route<->destination pairing crack
Fix off-by-one in WW formula, document fully-cracked X field
Document zone-3a generalization, boundary bug fix, and viewer wiring
Document zone-2 generalization correction and viewer wiring
Partially crack mp0 name-table header -- WW = string length validated
Document mp0 zone 1 crack and the Bulgarian place-name string table find
Document mp0 zone 2 binary flag find and 2 failed idx-localization attempts
Document mp0 zone 3 sub-zone 3a speed-limit crack and one-way refutation
Document first real crack of mp0's seg_list tail structure
seg_list: document the refined bytes1-3 signal, the refuted turn-restriction hypothesis, and the length-field crack
Mirrors the main repo. First field this project can actually name in the
seg_list record: the trailing value field is very likely eeu.mod's own
length field, in decimeters, confirmed via real coordinate distance
comparison on 2 independent tiles.
seg_list: document the real, clean qualitative signal (byte2/3==0) -- strongest lead yet, not confirmed as a full crack
Mirrors the main repo: 0/273 on 2 confirmed-divided tiles, nonzero on both
confirmed non-divided tiles -- a real presence/absence pattern. One more
precisely-matched divided-road ground-truth point would confirm or break
the "0.0% is a hard rule" hypothesis.
seg_list: document the real per-ID-length parser and its refuted divided-status signal, backed by 6 more real ground-truth points
Mirrors the main repo. The parser itself (per-ID-consistent record length,
00-00-terminated records) is real, validated structure. Its 8-vs-9-byte
length-distribution signal was tested against confirmed divided/non-divided
roads from the user's own RNS510 unit and cleanly refuted as a divided
indicator -- honest negative result, not hidden.
seg_list: document real human-verified ground truth (user's own RNS510 unit) refuting 3 shortcut methods
The user has the actual hardware running CD_8555 and identified 3 precisely
located real road segments via the viewer's edge-pick tool: 2 points on the
A1/Trakia motorway near Sofia (divided) and a contrast point on Vladimir
Bashev street, Sofia (one-way, non-divided). All 3 tested shortcut methods
(seginfoID lookup for divided/toll_vignette, positional distribution scan)
were refuted against this real ground truth -- a well-earned wall.
seg_list: single-count-field record-length model exhaustively refuted, computationally
Mirrors the main repo: a joint search over every plausible (base length,
count-byte offset, extension size, id offset) finds zero configurations
that exactly consume the tail, at any count cap. Root cause confirmed: the
most plausible count-byte position reads the same value on 3 consecutive
records of different true lengths (8, 8, 11 bytes) -- no single formula can
explain that. Real format needs multiple independently-variable fields.
seg_list: document the fresh, firmware-informed record-boundary attempt -- suggestive on 1 of 3 tiles, not a crack
Mirrors the main repo's honest account: a dominant-value test for seginfoID
succeeded strikingly on the 83-point reference tile (13708 dominates 74/83
records, plausible eeu.si lookup) but did not replicate on 2 more
independent tiles. Real lead, not a confirmed crack.
vnodeID / global routing-graph topology: firmware reveals a complete, real, named resolution pipeline
db_vid_get_map_id_V000/db_vid_get_pcl_id_V000 (vid = virtual id) resolve a
vnodeID to its owning map/parcel; db_find_node/db_node load a real VNode
struct (confirmed field vsegIDs[]); readNodeMP0 reads it from an .mp0
MAP_COMPRESSED tile while building a RoutePath; a real maneuver-generator
subsystem (mv_*, mv_vnode.cpp) consumes these for turn-by-turn guidance --
confirming VNode is genuinely the cross-tile routing graph node. Distinct
from the already-cracked per-tile local vertex adjacency (resolve_topology_
adjacency()). Names only, byte-level encoding of vnodeID itself still
unrecovered, but gives a concrete new validation path. Cross-referenced on
both eeu-il and eeu-mod pages, which previously disagreed on whether this
lead had even been named consistently.
eeu.mod: document the refuted load-base recovery attempt for the seg_list accessor names
A lis/addi string cross-reference scan (39,715 candidates) found no
consistent load base for the db_seg_* accessor-name strings found in the
firmware image -- most likely because they're DWARF-debug-only data never
referenced by executing code. A real, structural dead end for this
technique, documented so it isn't retried expecting a different result.
Confirm dbal 5-version-diff and eeu.mod seg_list findings from the firmware's own runtime code (separate SWL disc the user provided)
FHDD6.FLI's own 0-24MB native-PowerPC region carries a massive debug-string
table (1,476 distinct source basenames in one 5.3MB slice alone). Two direct
confirmations of prior map-disc-only findings: (1) dbaLib's own runtime log
strings ("best matching dbal.out version on DVD: V%03d_%03d", "now unload
DBAL version...") give the complete, real end-to-end dbal/ dynamic-loading
mechanism, explaining why 5 DBAL builds ship side by side; (2) a 77-function
catalog of real, versioned db_*_V0NN accessor names independently confirms
eeu.mod schema field names from live compiled code, including an exact match
for seg_marker_left/seg_marker_right and the db_tmc_all_headers_V003 vs
_deprecated_V005 pair (2nd independent confirmation of the earlier
db_tmc_deprecated correction). No code was disassembled -- names only.
MAP_COMPRESSED tiles: record-boundary search attempted, inconclusive
Mirrors the main repo's research/map_compressed_reader.py update: a
backtracking constraint search for the seg_list/attr_list record
boundary found a real methodological trap (byte-consumption alone is
not sufficient validation) rather than a crack.
MAP_COMPRESSED tiles: find a real, undocumented 3rd tile region (seg_list lead)
Mirrors the main repo's research/map_compressed_reader.py update:
attempted the eeu.si/seginfoID road-styling link, found genuine new
structure (a 3rd tile region past the topology table, ~8.95 bytes/point)
but did not pin down the exact record layout -- honestly documented as
an open lead, not a crack.
Add eeu.tmc TMC Traffic-Data page; close out final wiki stale references
New page eeu-tmc-TMC-Traffic-Data.md documents the file header + 44-table
directory crack (code, offset_p/offset_n into the bulk payload), found
using ground truth from telemat/tmc2/TMCCONFIG.ini and dbal/'s own
embedded source-file list (db_tmc.cpp), mirroring README S3.25.
Home.md: added eeu.tmc as a proper Road network status-table row (was
sitting in the "Never examined" table); folded zone.cfg's resolution
into the intro text (it never belonged in that table — plain-text
config, not a files.cfg data file); renamed the section "Formerly
'never examined' -- now all resolved" now that every file on the disc
has been examined at least once.
Unexamined-Files.md: added the "Formerly 'still genuinely unexplained'"
section resolving both eeu.tmc and zone.cfg, with the closing statement
that all 1,535 files across db/ and the 5 disc-root subsystems have now
been examined.
eeu-mod-Database-Schema.md: fixed 4 stale table rows that still said
"still unexamined"/plain filename with no link (eeu.tmc, eeu.pmc,
eeu.pmm, eeu.pol, eeu.pot, eeu.pmp) -- all now link to their real
write-ups.
_Sidebar.md: added the missing eeu.tmc link under Road network.
Document config/create_cd: the disc's own build script, plus EDB/POI.DB3 (4.7M real POIs)
config/create_cd is the disc's own mastering/build script, revealing:
- the literal origin of the EEU50530910.84 version string
- ZIP_3kb as the source tree's own real name for block_size=3072
- 5 never-examined disc-root subsystems: config, tpd, EDB, telemat,
speech, dbal
Opens and confirms EDB/POI/POI.DB3, a real standard SQLite database
with 4,733,183 real POIs, full addresses, and real brand-specific
category sets (main vw/seat/skoda/bentley) -- confirming this POI
database is shared across the whole VW Group. Independently confirms
eeu.mod's own 'Arriba' self-identification via the database's own
ClearCase build metadata (arriba2/arriba2_VW).
Also finds telemat/tmc2/TMCCONFIG.ini: real, standard ALERT-C TMC
location-table config for 14 countries, giving eeu.tmc (still
unexamined) a strong new lead -- a quick scan already finds a plausible
sequence of real ALERT-C Location Code numbers in its body.
Adds Disc-Root-Build-Script.md, updates Home.md, _Sidebar.md,
eeu-mod-Database-Schema.md, Unexamined-Files.md.
New eeu.fea lead from eeu.mod's schema; refresh the stale directory-format section
eeu.mod's feature block (never checked against eeuz.fea specifically
before) independently confirms and NAMES the already-cracked 12-byte
directory triple (ParcelHeader{offset,byteCnt,byteCntZip} = the found
offset/declen/complen), and reveals delta_long/delta_lat as the real
per-geometry coordinate fields -- explaining why the absolute-coordinate
search found nothing, though this sits in real tension with the
existing 'hash table, not spatial' conclusion, not yet reconciled.
Tested and refuted: parcel_cnt_x*parcel_cnt_y (929x1052=977308) doesn't
appear anywhere in the directory region.
Also refreshes eeuz-fea-Place-Name-Gazetteer.md's own 'directory format'
section, which was stale (still described the format as uncracked, even
though a prior session in this project already cracked it as
offset/declen/complen big-endian triples).
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.
Partially crack eeuz.pca: record framing at full scale, 2 of 4 trailer fields
188 country/continent phoneme records parsed with zero leftover bytes.
clusterOffset/clusterCount confirmed always-zero (cross-validates
eeu.pcl's empty status). cityOffset/cityCount is a real per-country
constant but its target file wasn't identified -- tested against
eeu.cty (both direct and reversed field order) and eeuz.pct, neither
matched. Also found eeu.cty's own country tag is NOT one contiguous
block per country as previously summarized (441,325 tag transitions
across 939,351 records).
Adds eeuz-pca-Country-Phoneme-Catalog.md, updates Home.md, _Sidebar.md,
eeu-mod-Database-Schema.md.