Skip to content

Latest commit

 

History

1 Commit

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 

Repository files navigation

dc-platformnotes-doc

The canonical Dreamcast platform checklist, to be carried from one documentation pipeline to the next and added to by each.

dc-platform-notes.md

Each Dreamcast title I document will produce two things: a repository about that disc, and whatever it taught me about the format. The second kind of finding does not belong to any one title, and keeping a copy of it in every pipeline is a recipe for three copies that disagree. This repository is the single copy. Pipelines link here rather than fork it.

It covers no discs yet, and says so on every line

This is a scaffold, not a result. The CD-i and Amiga CD checklists in this family were written out of their first pipelines; this one was written before its first pipeline, so it has the sections and the questions but none of the measurements.

Every claim in the notes carries the mark [unverified], which means one thing: it came from public documentation of the platform, not from a disc that was opened. The first pipeline turns each one into a measurement, a correction with the wrong version left visible, or a deletion — and leaves alone whatever it did not test. A mark is never promoted because nothing contradicted it.

This platform needs that rule more than the others do. It is the best-documented machine in this collection by a wide margin — homebrew SDKs, emulator sources, twenty-five years of scene notes — and the temptation is to inherit all of it as fact. Inherited fact is exactly what the neighbouring checklists exist to falsify: on Amiga CD, four widely repeated claims about the .TM block turned out to be wrong, and each was wrong because everyone had copied it from everyone rather than opening a disc.

What it covers

A working checklist for opening an unfamiliar Dreamcast disc: what to look at first, what the numbers should be, which traps look likely to cost real time, and — for now — which of it is documentation rather than measurement.

Section
1 The dump is not the disc. GD-ROM's two areas, the high-density base, and what .gdi, .cdi, .chd and a bare .iso each throw away
2 IP.BIN — sixteen sectors in front of the file system, every header field, the checksum, and hashing the bootstrap across discs
3 ISO 9660 on the high-density area: ordinary tools work, which is the convenience and the trap — fix the LBA convention first
4 Censusing the disc, measuring padding rather than estimating it, and the dummy file that makes a capacity figure meaningless
5 1ST_READ.BIN, SH-4 little-endian, and the scramble — descramble first, then prove that you did
6 Middleware fingerprints — CRI's ADX / Sofdec / AFS, Ninja, Kamui, PRS, Windows CE — as counts, before describing any format
7 PowerVR: tile-based deferred rendering, PVRT textures, twiddling and VQ, and proving a geometry when a wrong guess still draws something
8 The AICA — a second program in a second instruction set, uploaded and almost never read — plus ADX, sample banks, and the warning track
9 Sofdec video, chaining a container to validate it, and what fraction of the disc is video
10 Baselines — empty, fifteen proposed columns, one row per disc
11 A proposed order of work, thirteen steps, none of them tested
12 The hash lists, and stating which bytes a published hash refers to

Discs it is drawn from

None. This table fills in one disc at a time, and when it has entries the full write-up for each will live in the family index: dc-gamelist-doc.

Disc Year What it is

The questions this repository was split out to answer

It was split out before it could answer anything, which is unusual here and worth being explicit about. These are what it is for:

  1. How many generations of the IP.BIN bootstrap and logo are there? This is the CD-i bumper question transplanted onto a machine that puts a fixed, vendor-supplied block in front of every file system on the platform. On CD-i, twenty-nine seconds of authoring-system audio in that same position turned out byte-identical across five discs from four studios three and a half years apart, and hashing it became a thirty-second check that has answered the question outright seven times since.
  2. Is the ARM7 sound driver shared? It is uploaded rather than executed in place, it comes from a small number of sources, and essentially nobody looks at it. If one binary turns up on unrelated titles from unrelated studios, that is a result of exactly the shape of the Amiga CD .TM block.
  3. How much of a typical disc is dummy padding, and did the practice change over a platform that only had three years? Every published "capacity used" figure for this machine is suspect until that question has an answer.
  4. What did the Windows CE titles actually ship? They are a different platform wearing the same case, and the fraction of the library that used them is small enough to enumerate.
  5. Does the header ever lie? Area symbols, peripheral declarations and release dates are assertions made by the build, and all three are checkable against the disc that carries them.

Contributing from a pipeline

When a title turns up something about the format rather than the title:

  1. Add it to the relevant section here rather than to the title's repository.
  2. Convert the mark honestly. [unverified] becomes [1 of 1], [2 of 3] and so on only for claims your disc actually exercised. Everything else stays where it is. Two sessions of postponing a mark turn it into furniture, and a mark promoted without a test is worse than no mark at all.
  3. Cite a disc, not the scene. This platform has an answer available for almost any question, written by someone else, somewhere else. Those answers are leads, not findings, and a lead that enters this document without being re-measured is the failure mode this whole family is built to avoid.
  4. If a finding contradicts what is written, correct the text and say so in place. The neighbouring documents are most useful exactly where a later disc falsified an earlier one.
  5. Update the baseline table in section 10 and the order of work in section 11 — the order of work is a proposal and the first disc has standing to rewrite it — and publish notes/sha1-all.txt for your disc (section 12).
  6. When the preamble's apology is no longer true, delete the preamble.

State what is measured and what is inferred, and keep the measurements in the document. Half of what makes a disc interesting is the list of things that are measurably odd and not yet explained.

About

The canonical Sega Dreamcast platform checklist, to be carried across documentation pipelines: GD-ROM's two areas, IP.BIN in front of the filesystem, the scrambled SH-4 executable, CRI and Sega middleware, PowerVR textures and the ARM7 AICA driver. A scaffold - every claim is marked [unverified] until a disc says otherwise.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors