3do-platformnotes-doc

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

→ 3do-platform-notes.md

Each 3DO title I document produces 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 six discs

Crash 'n Burn	Crystal Dynamics, 4 October 1993, a launch title sold with the console
Super Street Fighter II Turbo	Capcom, pressed 10 January 1995, an arcade port
Wolfenstein 3D	Logicware / Interplay, 1995, a port of a 1992 PC game
AD&D Slayer	Lion Entertainment / SSI, pressed 16 August 1994, a dungeon crawler under TSR licence
Alone in the Dark	Krisalis / Infogrames / Interplay, pressed 19 December 1994, Europe, bilingual, a port of a 1992 PC game
Doctor Hauzer	Riverhill Soft, pressed 15 April 1994, Japan, a fully polygonal horror game

They were chosen to be as unlike each other as possible: six studios that never spoke, 92.33 %, 45.56 %, 45.45 %, 17.03 %, 57.90 % and 38.53 % of a 74-minute CD, and 0.32 %, 86.25 %, 67.41 %, 59.79 %, 77.19 % and 25.73 % recorded sound.

What the sixth disc changed, and it broke the one line written as a contrast

[2 of 2] said the redundancy is in the index, not in the data, and named CD-i as the opposite result. Doctor Hauzer is the CD-i result.

• 80 files declare up to seven copies each, where five discs of five had exactly two, and 90,050,560 bytes — 34.2712 % of the pressing — are second or later copies of file CONTENT;
• 79 of the 80 copy groups are byte-identical, so it is not versioning; the one that differs is /rom_tags and it differs by the signing pass;
• and the unit of duplication is not the file. Sorting every copy of every file by block address and joining the runs gives 24 contiguous runs of files — drawn from different directories — pressed 67 times between them. Six files from five directories laid down end to end and written four times over. A file's copy count is how many times its run was written.

Three more claims fell. The IMAG pixel order trap had been [1 of 1] and untestable since 1993 because four discs of five had no such chunk; this disc has 77 and the descriptor tells the truth on 77 of 77, so the trap is a fact about one disc rather than about the format. The Data Streamer's frame count is not encoded twice — FHDR declares 313, 767 and 525 where the files hold 2,149, 2,594 and 848. And the 20,480-byte stream quantum is not the format's: this disc declares 32,768 and honours it on 8 of 8.

Two open questions closed. Eight bits per pixel, the one cel depth no disc has used, is 729 cels of 1,157 here — every depth the platform defines has now been seen. And the SDX2 false economy was counted for the first time: 48 files, 638,903 bytes of eight-bit uncompressed audio at the identical byte cost of sixteen-bit SDX2, on a disc using SDX2 everywhere else.

And the fill arithmetic survived a case it was not built for. It closes to 0.00 sectors on this disc — with a fourth term, the 43,970 sectors of file copies, that no earlier disc could supply.

What the fifth disc changed, and it broke the strongest mark in the document

What the fifth disc changed, and it broke the strongest mark in the document

Two [4 of 4] claims fell, and both in the same place:

• there is a 3DO disc with no mastering fill at all. iamaduck counts zero over 394,876,928 bytes, where four discs of four had it;
• and therefore its sector map does not close. 16,689 sectors — 8.6556 % — belong to nothing, where four discs of four closed at zero.

What is in them is the point. 34,127,872 bytes at the end of the pressing are a Watcom C/C++ 10.0 installation — a PC's disk, showing through where nobody wrote — and a further 24,419,372 bytes inside ordinary files are a Macintosh's uninitialised memory, one 1,515,520-byte block of it pressed sixteen times. Together that is 14.83 % of a retail CD-ROM that is two other computers. Both are proved on the pressing rather than on the dump — every one of 192,811 sectors passes its own sync, address, EDC and both ECC checks — and the new §13 is the method, so the next disc is checked in five commands rather than in a session.

Two of this document's own searches were wrong, and both were run where they could not have found the thing: @(#) counts 7 on the second disc, in six /System files, not the zero recorded here; and Copyright counts three on a disc that has a Kanji font, not two.

And it answered three open questions and re-specified a fourth: the builder stops writing where a run of root copies stops (not where the fill starts); the relocation-target exception is the studio's binary on a second disc; the CPORT49.ROM debug trace is now one earlier pressing against two later clean ones; and the pressing-date question needed a disc with a documented pressing date, which a fifth disc was not.

And the fourth disc dated them. Each disc's own /rom_tags carries a pressing date, and on that clock Slayer was pressed before Super Street Fighter II Turbo, not after — 147 days apart, on an SDK build the two share to the second, with 115 of 116 /System files byte-identical between them.

Every claim carries a mark. [5 of 5] and [4 of 4] are measured on every disc that exercised the claim, independently, with the measurements in the text. [1 of 4], [1 of 3] and [2 of 3] mean it was measured more than once and differed — those are the most useful lines in the document. [corrected] leaves the wrong version visible beside the right one, and [deleted] means a disc showed a claim was never true of this platform.

Nothing is promoted because nothing contradicted it. After the fifth disc forty claims are still [2 of 2] — no IMAG, no BRGR, no APPSCRN, no .PAL, no ProTracker module, no second track — and the fifth disc has none of those either, so none of them moved. The mark counts are now produced by a command with a stated rule rather than by eye, and the document says where that disagrees with the previous session's hand count and why.

What the fourth disc changed

Four more claims that had agreed were broken, and one of them had already been refuted once and re-formed:

• there is no Red Book on this platform at all. The fourth disc is the first with zero audio tracks and it is 67.41 % recorded sound — the strongest case that would have used them. Four discs, four studios, zero. §1;
• the mastering fill goes in two regions again, of 911 and 16,818 sectors, and each begins at the block immediately after a run of root-directory copies. The "one free region" story is broken a second time and replaced by a candidate rule nobody has checked backwards. §4;
• the relocation-target exception has a side. 3DO's 38 ARM images are 38 of 38 on ro + rw; the studio's 3 are 1 of 3. §5;
• the root-copy layout is a fourth arrangement — 5+2, 7+0, 6+1 and now 4+3. The count of seven survives at [4 of 4]; the arrangement is refuted a fourth time. §3.

And two things this document already knew were rediscovered the hard way, which is worth recording because it is the failure mode the marks exist to prevent: the 132-byte volume label and its zero word at +128 (§2), and the /rom_tags date itself (§4). Both were published here before the fourth disc was opened. Read this file first.

What the fourth disc added:

• §7 has a fourth graphics format. ANIM — 370 containers, 3,782 chunks, 370 of 370 closing at residue zero, one CCB per file and one PDAT per frame, 2,516 frames, all 2,516 decoded;
• /rom_tags is three record types richer. 0x02 addresses the boot binary by block — which is why four discs spell its filename four ways without consequence, and why the launch title, which has no 0x02, is the exception. 0x07 and 0x10 carry os_code's and misc_code's sizes, on four of four and three of three. And the declared length of /rom_tags is not the number of records in its block: two discs hide two records past it;
• a fourth point on the pressing date, and a mechanised epoch test. It narrows question 8 and does not close it: the fourth disc has no documented release date of its own.

What the third disc changed

Six claims marked [2 of 2] were wrong, and every one of them had gone uncontradicted for fourteen months:

• block_count is not a multiple of 2,048 blocks. It is a whole number of mebibytes — 600, 296, 110 — which in blocks is a multiple of 1,024. Two even multiples of 4 MiB had been mistaken for a rule. §2;
• the relocation branch points at ro + rw + debug, not ro + rw. The first two discs shipped debug size 0 on all 127 of their images, so the two sums were the same number. 164 of 164 across three discs. §5;
• compression is not decided by a size relation. The BL at offset 0 is the test; the declared sizes are below the stored size on eleven of the third disc's twenty compressed images, which no decompressor can do. Replaced by two structural tests that separate the populations with no overlap on 37 of 37. §5;
• @(#) is not zero. It counts 2, in the game's own binary, in SCCS what-strings from the SDK's audio library. The first two discs simply did not link it. §5;
• the four junk files are not byte-identical across discs. The 1993 disc's hold 0x0a and the later ones 0x0d. A claim of byte-identity that was never checked with a hash. §4;
• and the worst one: Cinepak was deleted on a search that could not have found it. CVID is zero on all three discs; the compression field says cvid, in lower case, and the third disc has 550 frames of it. §9.

And one explanation was deleted rather than rewritten. The second disc's seven consecutive root copies were explained by the builder puts them in whatever free space exists and this disc has one region. The third disc has one region and splits them 6 + 1. §3.

What the third disc added

§9 went from [deleted] to a derived format. The Data Streamer exists, its container is id + length chaining like everything else on the platform, its SHDR declares a block size the files are exact multiples of, its timestamps make it interleaved, and the stream clock runs at 240 ticks per second — so the two films on that disc run at exactly 10 and 12 frames per second, which nothing on the disc declares.

The banner screen is answered, after two discs of not found. Its magic is APPSCRN, its format is derived, one disc of three has one, it is the SDK's untouched placeholder reading FICTIONAL DEVELOPER presents BOGUS TITLE, and the other two discs have zero occurrences of the magic over 1.08 gigabytes.

/rom_tags is derived: a table of 32-byte records, 3, 4 and 6 of them across the three discs, with the signing pass patching exactly one word per record. And one of those records is a date — three values, monotone in press order, all three landing in 1993–1995 under a 1904 epoch, with the first twenty-five days before its disc's documented release. §4.

A third answer to what are the graphics in. IMAG, then CCB , then neither: the third disc's art is in an archive format the platform does not define, holding cels with sixteen of their twenty control-block fields thrown away. §7.

What is still open

Thirteen questions after four discs, of which five are new. The oldest is burst and gap — 1 and 0 on 1,107 directory entries across three SDKs, including on 11.6 megabytes of a container whose entire purpose is interleaving. The case that should have exercised them has now arrived three times and did not.

The newest are whether the mastering fill always begins where the root copies stop, whether the relocation-target exception is always the title's own binaries, what three of the six /rom_tags record types are, and which of the two twins' CPORT49.ROM is the original — they differ by 68 bytes and the difference is a single kprintf left in one of them.

bin/

chdman.exe and its DLLs, for extracting a CHD to a .cue and a .bin. The notes tell you to read the CHD header by hand first anyway; it is fifteen lines and it gives the track count with no intermediary.