Skip to content
RetrogamingDeep Dive Published Updated 5 min readViews unavailable

Dreamcast GD-ROM GDI Track Maps: FAD, Sector Size, and File Offsets

Inspect Dreamcast GDI track maps through Flycast FAD and sector boundaries, validating files without claiming a Sega-published format specification.

A Dreamcast GDI image is not just one opaque disc file. It is a text manifest plus the track data files named by that manifest. The manifest is operationally important: it maps track numbers and starting positions to track types, sector sizes, file paths, and byte offsets. A missing track file, a misunderstood offset, or a reader that applies a different interpretation can shift every later read while still leaving the directory superficially plausible.

There is an important source limitation. This guide describes the behavior visible in the pinned Flycast GDI parser and its tests, with MAME and Linux GD-ROM code used as implementation comparisons. I did not locate a public Sega GDI specification in the sources below. These code paths are evidence of how particular projects load or communicate with GD-ROM media; they are not normative statements from Sega about every valid dump.

Treat the manifest as a file map

Flycast’s parser reads a track count, then expects one record per track with fields it labels TRACK FADS CTRL SSIZE file OFFSET. The parser reads each path relative to the directory containing the .gdi file. Quoted filenames are supported, which matters when a track name includes spaces. A valid manifest therefore depends on the adjacent file set, not just on its text contents.

For a practical audit, capture the manifest and directory listing before opening an image in an emulator. Confirm that the number of records matches the declared count, each referenced filename resolves with the exact case and spelling present on the target filesystem, and all source files remain unchanged. A filename that resolves on a case-insensitive desktop may fail when the same set is copied to a case-sensitive filesystem. Never “fix” a manifest by renaming a track without also recording which bytes changed or moved.

FAD and byte boundaries in Flycast

In the reviewed Flycast implementation, FADS is converted to the track’s StartFAD by adding 150. The project tests assert that the sample track starts become FAD 150 for a first-track input of zero, FAD 600 for the next sample input, and FAD 45150 for the third input value 45000. This is a statement about this parser and test fixture. It should not be generalized into a rule for every disc-image format or every historical tool.

The parser accepts CTRL values 0 and 4, with its checked-in rules requiring track 1 to be data, track 2 audio, and track 3 data at the expected FADS position. It accepts sector sizes 2048 and 2352 bytes. For a well-formed nonnegative offset no greater than the file length, it passes the byte offset and sector size to its raw-track reader, then derives the end FAD from the file length remaining after the offset. Treat those validity conditions as input-validation requirements, not guarantees from the parser: in the reviewed revision, Flycast reads OFFSET into a signed s32 and does not explicitly reject negative or beyond-file-length values before calculating the remaining length. A separate manifest validator should reject both cases before arithmetic or file access; do not treat parser acceptance as evidence that an untrusted offset is safe.

track_start_fad = FADS + 150
usable_track_bytes = track_file_size - OFFSET
whole_sectors = floor(usable_track_bytes / SSIZE)
track_end_fad = track_start_fad + whole_sectors - 1

The final floor is a boundary warning, not a content repair. Flycast logs a warning if the post-offset length is not divisible by the sector size; its parser code does not report that check as a fatal error. A successful open therefore does not mean every track file ends on a clean sector boundary. A forensic workflow should report the remainder explicitly instead of silently truncating or padding source data.

The distinction between 2048-byte and 2352-byte records also changes how many sectors a given byte range represents. Do not infer track length from a file’s size without the manifest’s offset and sector size. Keep the raw file and manifest together, record cryptographic hashes for each, and use a read-only copy for parser experiments.

Use parser tests as evidence, not as a format standard

Flycast’s GDI tests verify a three-track sample disk, its data/audio classifications, and the computed starting FAD values. One test sets a French locale before parsing, and the parser explicitly imbues a classic locale for the manifest stream. These are useful regression cases: they show that this implementation tests locale-independent numeric parsing and more than one fixture layout. They do not establish coverage of corrupt offsets, duplicate track numbers, missing files, every valid disc arrangement, or cross-emulator compatibility.

MAME’s GD-ROM device code implements drive packet commands, while Linux’s gdrom.c talks to the Dreamcast drive through platform registers. They sit at different layers from a desktop emulator’s GDI manifest parser. Comparing them can help keep image-loader behavior separate from emulated or physical device behavior, but agreement among implementations is still not a substitute for a published normative image-format document. If two emulators disagree, record each application version, manifest, and track-file hashes before changing a preservation master.

A safe validation sequence

  1. Preserve an untouched source copy and record the .gdi and track-file hashes.
  2. Parse the manifest as data first: count, field values, quoted paths, offsets, and sector-size divisibility.
  3. Test a duplicate set with a pinned emulator build, then compare track types and start/end ranges from its logs or debugger if available.
  4. Repeat with a second implementation only when that comparison is relevant, and report implementation-specific differences rather than selecting a winner by assumption.
  5. Keep emulator saves, metadata, and extracted files outside the preservation source directory.

There is no physical Dreamcast drive or optical-disc verification in this environment. The article is based on source review and parser tests, not a claim that any real disc or particular dump was validated. The existing preservation guide covers image identity and hashes more broadly; this article stays focused on Dreamcast GDI track mapping and read boundaries.

Related:

Sources:

Comments