A running checklist, carried from one 3DO documentation pipeline to the next and added to by each.
It covers seven discs. Every claim below carries a mark:
[5 of 5],[4 of 4]— measured on all the discs that have exercised the claim, independently, with the measurements in the text. The strongest marks in the document.[3 of 3]— measured on the three discs that existed when it was written, and the fourth did not exercise it. Still a rule made of three points, and it has NOT been promoted for silence.[2 of 2]— measured on two discs and the third did not exercise it. Still a rule made of two points.[1 of 1]— measured on one disc only. One disc is not a platform.[1 of 2],[1 of 3],[2 of 3]— measured on more than one and it differed. The values are given. These are the most useful lines here, because each one is a place where somebody would otherwise have generalised.[corrected]— this document said something else, and the wrong version is left visible beside the right one.[deleted]— a disc showed the claim was never true of this platform.[unverified]— it came from public documentation of the platform, not from a disc anyone opened.
A mark is never promoted because nothing contradicted it. With six discs
that temptation is at its worst: every line a disc did not touch looks
confirmed five times over. It is not. The third disc broke six claims that
were marked [2 of 2], and every one of the six had gone uncontradicted for
fourteen months. The fourth broke four more, and one of them was a rule
about where the mastering fill goes that had already survived being refuted
once. The fifth broke two that were [4 of 4] — the strongest mark this
document had — and it broke them in the same place: there is a disc with no
mastering fill at all, and its sector map does not close.
The sixth broke the one line in this document that was written as a
contrast with another platform, and it broke it by a factor of a thousand.
[2 of 2] said the redundancy is in the index, not in the data, with CD-i
named as the opposite result. Doctor Hauzer presses 90,050,560 bytes —
34.2712 % of itself — as second and later copies of file CONTENT, and the
unit of duplication is not even the file: it is a contiguous run of files
drawn from different directories, and twenty-four such runs are pressed
sixty-seven times between them. §3.
The seventh broke the strongest surviving claim about what a studio does NOT
do, and it broke a tool rather than a disc. [4 of 4] said no studio
asserts copyright in text on any of these discs; the studio's name is a
picture. FIFA International Soccer carries Copyright (C) Electronic Arts Canada Inc. 1993. All rights reserved. in /launchme and in /playlist
— and the name is also a picture, because stream.easports is an
eight-megabyte logo film. §5.
And it is the disc that shows what a format looks like without its own
header. All 43 of its Data Streamer films begin CTRL, 24 bytes, and there
is no top-level SHDR anywhere on the disc — so the stream block size, the
subscriber tag count and the tag list are declared nowhere, and the builder
honoured the block size anyway on 43 files of 43. Two tools that selected
Data Streamer files by SHDR in the first four bytes therefore reported, with
four decimal places, that 64.7915 % of the object had no derived format. §9.
The discs:
| Crash 'n Burn, Crystal Dynamics, 4 October 1993, a launch title | 3do-crashnburn-doc |
| Super Street Fighter II Turbo, Capcom, late 1994, an arcade port | 3do-superstreetfighter2turbo-doc |
| Wolfenstein 3D, Logicware / Interplay, 1995, a port of a 1992 PC game | 3do-wolfenstein3d-doc |
| AD&D Slayer, Lion Entertainment / SSI, 1994, a dungeon crawler under licence | 3do-adndslayer-doc |
| Alone in the Dark, Krisalis / Infogrames / Interplay, Europe, December 1994, a port of a 1992 PC game, bilingual | 3do-aloneinthedark-doc |
| Doctor Hauzer, Riverhill Soft, Japan, April 1994, a fully polygonal horror game, and the first Japanese disc | 3do-doctorhauzer-doc |
| FIFA International Soccer, Electronic Arts Canada, Europe, September 1994, a football game two thirds of which is licensed World Cup footage | 3do-fifainternationalsoccer-doc |
They were chosen to be as unlike each other as possible: seven studios that never spoke, twenty-four months of pressings apart, 3D against sprites against a raycaster against a first-person dungeon against a fixed-camera adventure against a fully polygonal house against a sports title, 92.33 %, 45.45 %, 45.56 %, 17.03 %, 57.90 %, 38.53 % and 90.80 % of a CD, and 0.32 %, 67.41 %, 86.25 %, 59.79 %, 77.19 %, 25.73 % and 28.62 % recorded sound.
And the seventh is the first published by a company rather than by a
studio, which turned out to matter to the platform in three specific ways
worth naming here: it is the first disc that asserts a copyright in text
(§5) and does so from a library banner in two binaries, dated a year before
the pressing; the first that ships a development tool — a movie player
and a shape browser that prints EXIT TO DOS (Y/N) on a console with no DOS;
and the first that forks the SDK's DSP instrument bank into its own tree
(§8), which changes what a hash crossing between two 3DO discs means.
And the sixth is the first Japanese disc, which turned out to matter to the platform in three specific ways it is worth naming here: it is the first disc whose filenames are not ASCII and therefore the first that breaks a reader's output rather than its parser (§2); the first that ships its own script as readable text, in Shift-JIS, in a directory named after the person who wrote it (§6); and the first whose copyright notice is a picture carrying a second company's name — Matsushita, the console's manufacturer — on the title screen rather than inside a font (§7).
And the fifth is the first non-USA disc and the first bilingual one, which turned out to matter to the platform in one specific way: it is the first disc on which the same programme exists twice in two encodings, and the comparison says something about SDX2 that no single-language disc could (§8).
And the fourth disc reordered them. Every earlier version of this document
ordered the discs by copyright line and release year. §4 now derives a
pressing date from each disc's own /rom_tags, and on that clock Slayer
was pressed on 1994-08-16 and Super Street Fighter II Turbo on 1995-01-10 —
147 days apart, in the opposite order to the one the release years imply, and
on an SDK build the two share to the second.
The fifth disc lands between them, on 1994-12-19, and it shares that same
SDK build to the second as well. Three discs on one SDK drop, 147 days
apart, with 116 of 116 /System files identical between two of them — which
makes every difference between them legible and turns the one changed file into
a clock (§3, §5).
The marks, reconciled. Counting a mark only where it opens a claim.
And this time the count was made by a command rather than by eye, with the
rule stated so it can be run again: a mark opens a claim when it is written
bold and code-quoted at the head of a paragraph, ** + backtick + the mark
- backtick, which is the form this document has always used for an opening mark and never for a mark mentioned in prose.
python -c "import re,collections,sys; s=open(sys.argv[1],encoding='utf-8').read();
print(collections.Counter(re.findall(r'\*\*\`\[(\d of \d|corrected|deleted|unverified|verified)\]\`', s)))" 3do-platform-notes.md
after two three four five six AFTER SEVEN
[7 of 7] -- -- -- -- -- 2
[6 of 6] -- -- -- -- 1 1
[5 of 5] -- -- -- 2 5 5
[4 of 5] -- -- -- 3 3 3
[4 of 4] -- -- 11 5 6 6
[3 of 3] -- 12 4 11 9 10
[2 of 3] -- 2 2 2 2 3
[1 of 3] -- 11 11 11 12 12
[1 of 4] -- -- 3 7 7 7
[1 of 5] -- -- -- 1 1 1
[1 of 7] -- -- -- -- -- 5
[2 of 2] 50 41 38 40 39 39
[1 of 2] 16 10 9 9 9 9
[1 of 1] 10 14 14 16 23 25
[corrected] 11 18 22 21 24 28
[deleted] 4 3 3 3 3 3
[unverified] 5 4 4 4 4 4
[verified] -- 1 1 1 1 1
---
164
The last column was produced by the command above and pasted, not tallied. Fifteen more opening marks than after six discs, and the shape of the increase says what kind of disc the seventh was:
- five new
[1 of 7]lines, which is a mark this document did not have before. Every one is a claim that six discs agreed on and the seventh did not: theiamaduckstraddle count, the relocation exception, the SDK instrument bank being in/Systemand nowhere else, the stream fraction and the sample rate; - four new
[corrected], of which two — the copyright rule and theCPORT49.ROMdifference — correct this document's conclusions and two correct its searches, which is this document's oldest recurring mistake and now has instances on four separate discs; - the
[2 of 2]count did not move at all. Thirty-nine claims have been measured twice and agreed, and a seventh disc touched none of them. That is not thirty-nine confirmations: it is thirty-nine claims the seventh disc did not exercise, and the first rule of this document is that they do not move for it.
And one line moved because a mark was made STRONGER by being made weaker.
The [3 of 3] on the top bit of a 16-bit pixel became [4 of 4] on the bit
is not part of the colour and [1 of 4] on the bit is zero — because the
seventh disc has 64 palette entries of 192 with it set, in a pattern that says
what the bit is for. A count that goes up and a claim that gets sharper are
the same event here.
The last column disagrees with the fourth in places, and the reason is the
rule and not the discs. The earlier columns were counted by hand under a
looser reading — a [4 of 4] written mid-paragraph beside a [corrected] was
sometimes counted as opening a claim and sometimes not. The command's rule is
stricter and is applied to the whole document at once, so the fifth column is
internally consistent and the first four are the previous sessions' arithmetic
left where it stands. Re-count the earlier columns if you want them
comparable; do not average across the change.
What the fifth disc actually did to the marks: two claims reached
[5 of 5], three fell from [4 of 4] to [4 of 5] — the sector map, the
iamaduck fill and the label's fill offset — four [1 of 4] lines became
[1 of 5] or gained a fifth value, and two new corrections were written,
and both of them are corrections to this document's own searches rather than
to its conclusions: @(#) was counted in the wrong place and Copyright was
counted before a fifth disc had a third one (§5). A search run where it could
not have found the thing is this document's oldest recurring mistake.
Twelve claims were promoted to [3 of 3] out of fifty that were [2 of 2],
and thirty-eight were not. Seven more corrections were written, six of them
against claims that had been [2 of 2]. Six claims that had been measured twice
and agreed were measured a third time and differed, which is what [1 of 3]
and [2 of 3] are for.
After the fourth disc: eleven claims are [4 of 4] and four remain
[3 of 3]. Four more corrections were written. Three claims that had agreed
on three discs were measured a fourth time and differed — that is what
[1 of 4] is for — and one of the three is a rule that had already been
refuted once and re-formed.
Nothing was promoted for silence, on any pass. Thirty-eight [2 of 2]
lines were still [2 of 2] after four discs: no .PAL files, no ProTracker
modules, no IMAG descriptor, no BRGR archive, no banner screen, no second
track. The fifth disc has none of those either — no .PAL, no M.K., no
IMAG, no BRGR, no APPSCRN, one track — so they do not move. Being
uncontradicted a fifth time is not evidence.
And the sixth disc is the reason that rule exists. It has no .PAL, no
M.K., no BRGR, no APPSCRN and one track, so five of those lines still do
not move after six discs. But it has 77 IMAG files, and the moment
somebody could finally test a claim that had gone uncontradicted for five discs,
that claim turned out to be a fact about one disc rather than about the chunk.
Five silences and one measurement, and only the measurement was worth
anything.
What the third disc was for. Two discs produce rules; a third disc is the
first thing that can break one. This one broke the block_count rule, the
relocation-target identity, the compression test, the toolchain-banner zero,
the junk byte-identity claim and the [deleted] on Cinepak — and it deleted
an explanation. It also exercised three formats neither previous disc had: the
Data Streamer (§9), the banner screen (§7) and an archive format that is
nobody's but the studio's (§7).
What the fourth disc was for. It is the twin of the second — 364 sectors
shorter, the same SDK build to the second, and 115 of 116 /System files
byte-identical with it, which was the closest pair this document had and
makes every difference between them legible. It broke the Red Book
line (it is the first disc with no audio track at all), the root-copy
layout, the relocation-target identity in a new place, and the mastering-fill
placement. It supplied the fourth point the /rom_tags date question asked
for. And it opened a container none of the first three had: ANIM / CCB ,
370 files, 2,516 frames, all of them decoded (§7).
What the fifth disc was for, and it is not what any of the first four was
for. It is closer to the second than the fourth was — 116 of 116 /System
files identical, zero changed — and it is the disc that shows what the
mastering tool does when it is not there. It broke:
iamaduck, which was[2 of 2]on presence and implied by a[4 of 4]sector map. This disc has zero occurrences over 394,876,928 bytes;- the sector map closing at zero unowned, which was
[4 of 4]and is the strongest kind of claim this document makes. This disc leaves 16,689 sectors — 8.6556 % — owned by nothing; - and it made a new claim possible that four discs of four had hidden: what a 3DO disc's builder leaves behind when it does not overwrite. §13.
It also supplied the fifth /rom_tags date, a fifth root-copy layout,
a five-block root directory where four discs had one, a second use of the
Data Streamer with a film shared byte-for-byte with the third disc, and
the first side-by-side comparison of SDX2 against uncompressed PCM at the same
byte cost (§8).
What the seventh disc was for, and it is the first that was asked for by title rather than by shape. FIFA International Soccer was opened because the owner of the machine wanted to know what a 1994 football game does with 590 mebibytes. The answer is that it spends 63.3481 % of itself on 43 Cinepak films, 21:52 of them, 19,597 frames at exactly fifteen a second — and that the football is 1.6791 %. It broke:
- "no studio asserts copyright in text",
[4 of 4], above and in §5; - "the first chunk is
SHDR", which this document derived on the third disc and never doubted. 43 of 43 beginCTRLand noSHDRexists at the top level, and the format still works because everything a decoder needs is one level down inFHDRandSNDS/SHDR. What is missing is what a multiplexer would need. §9; - the
[2 of 3]on the frame count, which the sixth disc broke on its three longest films. This disc agrees on 42 of 43, and its one exception goes the other way and is the second-shortest film. §9; - and it corrected this document's account of
CPORT49.ROM, where a 68-byte difference had been attributed to akprintfand is the signing pass. §3.
It also supplied a seventh /rom_tags date, a seventh root-copy
layout, a fourth disc on one SDK drop with 116 of 116 /System files
identical to two of them, four independent confirmations of open question 10
on one object, and the first decoder defect this document has had to
record — one that every census in the pipeline passes. §11.
What the sixth disc was for, and it is the first one that was not chosen for its differences. Doctor Hauzer was asked for by the owner of the machine because of a question about the game — whether it is a clone of Alone in the Dark — and it turned out to break more of this document than any disc since the third. It broke:
- "the redundancy is in the index, not in the data",
[2 of 2], which was written with an explicit contrast against CD-i. This disc is the CD-i result, at 34.2712 % of its own pressing, and the unit of duplication is a run of files across directories rather than a file (§3); - the
IMAGpixel ordertrap, which had been[1 of 1]and untestable since the 1993 launch title because four discs of five had noIMAGchunk. This disc has 77, and the descriptor agrees with the measurement on 77 of 77 where the launch title's lied on 31 of 61. The trap is now[1 of 2]and is a fact about one disc rather than about the chunk (§7); - the Data Streamer's frame count encoded twice,
[2 of 2].FHDRdeclares 313, 767 and 525 where the files hold 2,149, 2,594 and 848FRMEchunks, on the three longest films (§9); - the 20,480-byte stream block quantum,
[1 of 2]. This disc's eight films declare 32,768 atSHDR+24 and all eight are a whole number of 32,768 byte blocks with remainder zero, 8 of 8 (§9).
And it closed two open questions outright — 8 bits per pixel, on 729 cels, and the SDX2 false economy, counted for the first time — and gave a fourth term to the fill arithmetic that no earlier disc could supply (§4).
[4 of 4] A 3DO title is a CD-ROM with Mode 1, 2,048-byte data sectors,
in a single MODE1_RAW track, SUBTYPE:NONE, no pregap, no postgap.
Crash 'n Burn 307,446 sectors 723,112,992 raw 629,649,408 user
FIFA Int. Soccer 302,380 sectors 711,197,760 raw 619,274,240 user
Alone in the Dark 192,811 sectors 453,491,472 raw 394,876,928 user
SSF2T 151,704 sectors 356,807,808 raw 310,689,792 user
Slayer 151,340 sectors 355,951,680 raw 309,944,320 user
Doctor Hauzer 128,300 sectors 301,761,600 raw 262,758,400 user
Wolfenstein 3D 56,702 sectors 133,363,104 raw 116,125,696 user
[7 of 7], and it is worth its own line because seven discs is enough to say
it. Every sector of every one of these tracks passes its own integrity
checks. On the seventh, measured because 63 % of the disc is somebody else's
footage and is this a pressing had to be settled before anything was said
about the footage: sync, header MSF, EDC, ECC P, ECC Q and the eight reserved
bytes, clean on 302,380 of 302,380 on all six checks. On the fifth disc, measured explicitly because 8.6 % of it belongs to
no file: sync correct on 192,811 of 192,811, header MSF equal to LBA + 150 on
192,811 of 192,811, zero EDC mismatches, zero ECC P mismatches, zero ECC Q
mismatches, and the eight reserved bytes zero on every sector. On the sixth,
measured because a third of the disc is duplicated content and the question
was this pressed or was this a dumper had to be settled at the sector before
anything was said about it: 128,300 of 128,300 on every one of the same six
checks, and zero mismatches of any kind. That is what makes "the disc
contains X" a statement about a pressing rather than about a dump, and it costs
one pass. §13.
[corrected], and now [4 of 4] This document expected Red Book audio
tracks beside the data track "on a large fraction of titles", on the grounds
that the console plays CD-DA and Amiga CD and CD-i studios used it. Both
discs have zero. Each CHD metadata chain has one entry and it is the data
track.
The second disc makes the correction much sharper than the first could, because it is the disc that would obviously have used Red Book if Red Book were the answer: 86.25 % of it is 44,100 Hz stereo music, and it puts that music in the data track as AIFF-C. See §8 for the arithmetic, which shows the music would have fitted as CD-DA — 70.93 % of a 74-minute disc including everything else — so capacity was not the constraint. On this platform, sound in the data track is the norm and not the exception.
[corrected], and the seventh disc is the first that cannot testify. This
document has said since the second disc that capacity was never the constraint
on any of them — six discs of six could have put their sound on a Red Book
track and did not. FIFA International Soccer could not have. 45:00.01 of
AIFF sound as CD-DA is 202,501 sectors, 60.8111 % of a 74-minute CD, on a
pressing that already uses 90.8048 % of one; the hypothetical Red Book pressing
is 399,088 sectors, 119.8462 % of 333,000.
A disc that could not have used Red Book tells you nothing about whether anybody would have. The claim is about a choice, so the mark is
[6 of 6]on the discs that exercise it and the seventh is recorded as not exercising it — which is a different thing from breaking it. Six studios had the option and none took it.
And the seventh disc supports the REASON more strongly than any of the six. It runs 43 interleaved films off a single-speed drive at 15 frames a second while the game loads, and its sound is 22,050 Hz stereo SDX2 on 53 of 54 files and on 43 of 43 films — 44,100 bytes per second against the drive's 153,600. Choosing half the CD sample rate was not a capacity decision: the disc had 30,620 sectors free. On this platform the bandwidth is the constraint and the capacity is not, and this is the disc where the two can be told apart.
The fourth disc is the strongest single case for that line and it is a
different case. Slayer is 67.41 % recorded sound, all of it uncompressed
AIFF, codec NONE on 81 files of 81 -- twenty-two and a half minutes, most
of it at 44,100 Hz sixteen-bit stereo, in the data track, with zero audio
tracks. Its own arithmetic says Red Book would have fitted at 39.68 % of a
74-minute CD, and the platform's own SDX2 would have freed 102,379,300
bytes. It used neither. Four discs, four studios, zero Red Book tracks
between them.
[7 of 7] Record, before the image: how many tracks, the data track's
length, and the fraction of a 74-minute CD (333,000 sectors) it occupies.
92.3261 %, 90.8048 %, 57.9012 %, 45.5568 %, 45.4474 %,
38.5285 % and 17.0276 % — and the second is the one that made the
seventh disc's whole shape predictable before a file was read: a disc at
90.80 % of a CD is not going to have room for anything it did not plan for, and
this one does not.
All five set expectations correctly for what followed: the first disc was
nearly full and a third video, the second half empty with one directory at
86 % of it, the third a fifth of a disc of which a quarter is filler, and the
fifth a disc 58 % of a CD that is 91 % full — which was itself the clue,
because a disc that is 58 % of a CD and 91 % full has almost no free space for
a mastering fill to occupy, and the 8.6 % it does have is not fill at all.
[unverified] Where a dump is a bare .iso, treat the missing tracks as a
fact about the dump. A CHD or a .cue/.bin pair carries the whole pressing;
an .iso carries 2,048 bytes per sector and has already discarded the sync, the
header and the ECC.
[2 of 2] The CHD is worth reading by hand before trusting a tool: 124
bytes of header, MComprHD, version 5, the compressor list, and a metadata
chain. Fifteen lines of Python give the track count with no intermediary, and
chdman info then agrees or does not. chdman extractcd produces a .cue and
a .bin of sectors × 2,352. All four discs are v5 with cdlz cdzl cdfl.
[1 of 3] Check units == frames. The CHD's logical size divided by
its unit size need not equal the declared frame count:
Crash 'n Burn 307,448 units 307,446 frames 2 padding units
SSF2T 151,704 units 151,704 frames none
Slayer 151,340 units 151,340 frames none
Wolfenstein 3D 56,704 units 56,702 frames 2 padding units
Alone in the Dark 192,812 units 192,811 frames 1 padding unit
Doctor Hauzer 128,300 units 128,300 frames none
FIFA Int. Soccer 302,380 units 302,380 frames none
Three of seven carry padding units and the counts are 2, 0, 0, 2, 1, 0 and
0, so a reader that assumes the container is exactly the track is wrong three
times in seven and the padding is not a constant either. [1 of 7].
And the sixth value deletes the explanation the fifth column had. This
document said the two that do not pad are the twins — SSF2T and Slayer, which
share an SDK build to the second. Doctor Hauzer is nobody's twin: its SDK is
eight months older, its /System shares only 38 files with either of them, and
it pads not at all. Three discs of six pad and it is not a property of the SDK
drop. [corrected], and the padding count is left described.
[2 of 2] 3DO discs do not use ISO 9660. They use the file system of
the console's operating system, generally called Opera. The volume label is
in sector 0 and the layout in the first edition of this document was right,
offset for offset:
+0 u8 record_type 1
+1 u8[5] sync 'ZZZZZ'
+6 u8 record_version 1
+7 u8 flags 0
+8 char[32] comment
+40 char[32] label
+72 u32 identifier
+76 u32 block_size 2048
+80 u32 block_count the blocks the volume claims
+84 u32 root_dir_id
+88 u32 root_dir_blocks
+92 u32 root_dir_block_size
+96 u32 root_dir_last_copy copies = this + 1
+100 u32[] root_dir_copies absolute block numbers
[5 of 5], and the fourth disc had to rediscover it while the fifth read it
here first and spent no prediction on it. Two additions:
- the record is 132 bytes, four more than a seven-copy list needs, and the
extra word at +128 is zero on all five. On four discs of four the
mastering fill begins at offset 132 of sector 0, phase-aligned to the sector,
so it starts mid-word with
duck. On the fifth there is no fill, and what begins at offset 132 is whatever the medium held:/Disc label's two copies, at blocks 0 and 225, differ in 1,905 of their 2,048 bytes and agree on the 132-byte record exactly. That is the cheapest possible detector for a disc with no fill and it fires at block 0, 176,000 sectors before anybody would think to look. Compare the label's copies on every disc. Note the trap this line is for.opera.py --labelcomputes100 + 4 * (last_root_copy + 1)and prints 128, correctly, becauselast_root_copyis 6 on every one of the four discs;opera.py --listreports the/Disc labeldirectory entry as 132, also correctly. Two fields, two definitions, four bytes apart, both right. The fourth disc's session brief presented that as an unreconciled contradiction and the fourth disc's session spent a prediction on it before reading this line; - the label is also a file.
/Disc label, 132 bytes, type*lbl, whose directory entry has type byte 6 — not the 2 of a file or the 7 of a directory — and points at block 0. The volume contains its own header under a name.
[2 of 2] Byte order is big-endian, on every field of the label, every
field of every directory record, and inside the executables. Confirmed on a
field whose value was predictable: block_size reads 2048 big-endian and
524,288 little-endian — on both discs.
[2 of 2] Generic ISO tools do not open this, and the failure mode is
the dangerous one. There is no Primary Volume Descriptor at sector 16, so a tool
that looks for one does not report a broken image — it reports a convincing
nothing. Write the reader; it is about 200 lines.
[2 of 2], and this is the line to act on — the reader written against
the first disc opened the second without one line changed. 26 directories,
373 files, the sector accounting closing to 151,704 of 151,704 with zero
unowned sectors, and the negative control still failing on blocks 0 and 1.
Opera is a format and not one studio's habit, and a 200-line reader is a
permanent asset rather than a per-disc cost.
[corrected], and now [3 of 3]. This document said the volume's
block_count is a round multiple of 2,048 blocks, on 307,200 = 150 × 2,048
and 151,552 = 74 × 2,048. The third disc declares 56,320 and
56,320 mod 2,048 = 1,024. Two even multiples of 4 MiB in a row had been
mistaken for a rule.
The rule that survives is one level up and it is exact:
Crash 'n Burn 307,200 blocks x 2,048 = 629,145,600 bytes = 600 MiB exactly
FIFA Int.Soccer 302,080 blocks x 2,048 = 618,659,840 bytes = 590 MiB exactly
SSF2T 151,552 blocks x 2,048 = 310,378,496 bytes = 296 MiB exactly
Wolfenstein 3D 56,320 blocks x 2,048 = 115,343,360 bytes = 110 MiB exactly
Doctor Hauzer 128,000 blocks x 2,048 = 262,144,000 bytes = 250 MiB exactly
The volume declares a whole number of mebibytes, which in blocks is a
multiple of 1,024. [5 of 5], and the fifth value is 590 — not a round
multiple of 4 MiB either, which is the thing the third disc already deleted,
and not a multiple of 8, 16 or 32 MiB. Five values and the only common factor
is the mebibyte.
[1 of 1], and it is a warning about the READER and not about the format.
The sixth disc is the first with non-ASCII filenames: three files under
/OrgData/mes/MES by HAYASHI/ are named in Shift-JIS. The directory parser
handles them without a change — the names are bytes and the format has always
said so — but every tool in a pipeline that prints a path dies:
UnicodeEncodeError: 'charmap' codec can't encode character '\x92'
And one of them dies after writing a truncated result and exiting in a way a
caller does not notice: a hash census wrote 199 records of 366 and the
sweep that consumed it would have reported a confident, wrong number.
PYTHONIOENCODING=utf-8 fixes both. Check the record count against the file
count before using any generated list on any disc, and expect the first
non-ASCII disc of a platform to break output rather than parsing.
[3 of 3] The shape around it is untouched: block_count need not equal
the pressing, and the surplus is contiguous, at the end, and all zero.
Crash 'n Burn 246 sectors past it, all zero
SSF2T 152 sectors past it, all zero
Wolfenstein 3D 382 sectors past it, all zero, one run, 56,320..56,701
A reader that trusts block_count loses the tail; it has cost nothing three
times and it is still a thing to know.
[corrected] The first edition of this document listed the directory record
as flags, id, blockSize, byteCount, burst, gap, filename[32], copyCount, list.
The field list is right, the offsets are wrong, and one field is missing.
Measured:
+0 u32 flags low byte = type: 2 file, 6 special, 7 directory
bit 31 marks the last entry in the block
+4 u32 id unique across the volume
+8 char[4] type four characters
+12 u32 block_size 2048
+16 u32 byte_count
+20 u32 block_count <- MISSING from the first edition
+24 u32 burst
+28 u32 gap
+32 char[32] name <- at +32, not at +28
+64 u32 last_copy copies = this + 1
+68 u32[] copies absolute block numbers
size = 72 + 4 * last_copy
[2 of 2] ceil(byte_count / block_size) == block_count on 451 files of
451 and on 373 of 373. That is an arithmetic identity and not a proof that
the reader is right — it closes just as well on a subset of the files as on all
of them, which is exactly how the first disc's pre-briefing satisfied it while
missing 125 files.
[2 of 2] The four-character type field is not semantic. It is the
filename's extension, right-padded with spaces, case preserved: .3do gives
3do , .3DO gives 3DO , .BGM gives BGM , no extension gives four
spaces. A handful of files on each disc are exceptions and carry small integers
there instead, and /Disc label carries *lbl on both.
[1 of 3] byte_count is not necessarily the same in every copy of the
directory. The fourth disc does not do it: five of its 27 copy groups
disagree and every difference is a case fold and nothing else -- no length,
no block, no type. So one disc of three that has multiple copies patches a
length, and two do not. On the second disc, /System/Drivers/CPORT49.ROM is 1,332 bytes
according to copy 0 and 1,400 according to copies 1 and 2. Copy 0 is right —
the file's own header declares 1,332, as every .ROM on that disc declares its
own length — and the 68-byte difference is a four-byte terminator plus a
512-bit signature appended after the driver ends. See the copy-comparison
section below: the copies record the volume at two moments of its own build.
[2 of 2] A directory block opens with five 32-bit fields:
+0 i32 next_block -1 when last
+4 i32 prev_block -1 when first
+8 u32 flags
+12 u32 first_free_byte entries live in [first_entry_offset, this)
+16 u32 first_entry_offset 20
next_block and prev_block are block indices INSIDE the directory, not
absolute block numbers. A two-block directory has next_block 1 in its first
block and the second block is the one after the block the copy list points at.
This is the single most expensive trap on the platform, on both discs. Reading that field as an absolute address sends the walk to block 1 of the disc. On the first disc it cost a reader 125 files, 244,934,656 bytes and 119,642 sectors, which then appeared as "38.87 % of the disc belongs to no file" — a spectacular finding that was an artefact. Four directories of 38 spanned more than one block.
[2 of 2], and the second disc raises the price. Six directories of 26
span more than one block there — /BGM three, /System/Audio/dsp three,
/DEM, /ENDING, /SND and /System/Programs two — and /BGM is
86.2468 % of that disc. The same bug would lose most of it. Multi-block
directories are not an edge case on this platform: they were 10.5 % of
directories on one disc and 23.1 % on the other.
A reader for this format must have a negative control that fails: hand the directory-block parser sector 0 and sector 1, neither of which is a directory, and require rejection before censusing anything. That control turned the same bug into a crash in ninety seconds.
[2 of 2] first_free_byte is real and must be honoured: the bytes after
it are whatever was in the block before. Zero stale entries after it on both
discs — 451 files and 373 — so its cost has been nothing twice; but a reader
that walks to the end of the block is reading deleted records on any disc that
has them, and two discs without them do not make a third.
[2 of 2] The format keeps the redundancy in the directory record, and
reading it turns an investigation into a field read. The same structure on
both discs, including which two files get a second copy:
Crash 'n Burn SSF2T Wolfenstein 3D
root directory 7 copies 7 copies 7 copies
every directory 3 copies (38 of 38) 3 copies (26 of 26) 3 copies (22 of 22)
files 1 copy 1 copy 1 copy
files with 2 copies /Disc label /rom_tags same same
blocks on later copies 98 = 0.0319 % 76 = 0.0501 % 58 = 0.1023 %
... per group 2.58 2.62 2.52
The fraction moved and the behaviour did not, and the third disc makes that
unarguable. 0.0319 % → 0.0501 % → 0.1023 % looks like redundancy tripling.
Per directory group it is 2.58 → 2.62 → 2.52 blocks: flat, and the disc
with the largest fraction has the lowest per-group figure. What changed is the
denominator — the third disc is a fifth the size of the second with the same
kind of directories. A ratio that moves because its bottom moved is not a
finding, [3 of 3].
[3 of 3] Seven copies of the root, three of every directory, one of every
file, and the same two files with a second copy on all three discs.
[1 of 3] Where the root's copies sit is not fixed, and there is no
rule.
Crash 'n Burn 5 + 2 179,734..179,738 and 296,872..296,873
SSF2T 7 + 0 139,509..139,515, after the last file, before the fill
Wolfenstein 3D 6 + 1 42,934..42,939 and 48,271
Slayer 4 + 3
Alone in the Dark 1 + 4 + 2 64,165 | 128,295..128,310 | 176,137..176,142
Doctor Hauzer 1+1+1+1+1+1+1 85, 19675, 38475, 57690, 79779, 100363, 109741
FIFA Int. Soccer 3 + 2 + 1 + 1 100038,100043,100048 | 201265,201270 |
255814 | 258925
Seven discs, seven layouts, [1 of 7], and the sixth is the first in which
no two copies are adjacent at all. The seventh is the second disc with a
multi-block root and both have exactly five blocks, so its copies inside a
group sit five apart — 100038, 100043, 100048 — which is what makes the
arithmetic in §4 close to the block on four independent joins. The gaps are 19,590 / 18,800 / 19,215 /
22,089 / 20,584 / 9,378 across a 128,300-sector pressing — five of the six
within 3,300 sectors of each other and the last one short.
And on that disc the layout is not decoration, because the file copies do the same thing. A disc that spreads its root evenly and presses forty-seven files' worth of runs sixty-seven times across the same span is doing one thing twice, and it is the only disc of six that does either.
The fifth disc is the first in three parts and the first with a root directory of more than one block: five blocks, where five discs had one, so its seven copies occupy 35 blocks rather than 7 and the copies within a group sit five apart.
And the fifth disc says what the placement is for, which four discs could not. Open question 10 asked whether the mastering fill always begins where a run of root copies stops. This disc has no fill — but it has holes, and they begin in exactly those places:
the four copies at 128,295..128,310 end at block 128,314
the first sector owned by nothing is 128,315 (a run of 25)
the two copies at 176,137..176,142 end at block 176,146
the next sector owned by nothing is 176,147 (16,664 sectors, §13)
Both joins close to the block. So the rule is not about iamaduck at all:
the builder writes up to the end of a run of root copies and stops, and
what follows is fill on four discs and the medium's previous contents on the
fifth. Restated that way, open question 10 is answered rather than open.
[deleted] This document offered an explanation: the builder places them
in whatever free space exists and the second disc has exactly one such region.
The third disc has exactly one free region — 42,940..56,319, 13,380 blocks —
and still splits its copies 6 + 1, with the odd one 5,331 blocks in. The
explanation is refuted rather than unsupported and it is deleted.
Seven relations between that block and the disc's landmarks were tried on the third disc and none holds: it is not a midpoint, not a round block, not a whole mebibyte, not a fixed distance from the first group, from the declared volume or from the pressing's end, and not a round fraction of the free region. Three layouts, published as three offsets, unexplained.
[corrected], and this is the largest single correction in this document.
It said, at [2 of 2] and with a contrast against another platform built into
it:
The redundancy is in the index, not in the data. That is the opposite of the CD-i result and a difference in kind: CD-i discs duplicated content to keep a single-speed drive near its working set, and Opera duplicates metadata so that a scratch cannot cost the volume.
On five discs of five it was true, and the two files with a second copy were
the same two on all five — /Disc label and /rom_tags, the two the console
reads before there is a file system to read them with.
The sixth disc duplicates ninety megabytes of content.
Doctor Hauzer
files declaring more than one copy 80 of 366
second or later copies of FILE content 43,970 blocks = 90,050,560 bytes
= 34.2712 % of the pressing
the histogram 1 copy 286 2 copies 24 3 copies 13 4 copies 13
5 copies 18 6 copies 2 7 copies 10
So the corrected claim is [5 of 6] on the behaviour and the exception is
enormous, and the useful part of the correction is what the sixth disc lets
anybody measure that five discs could not.
One — are the copies of a FILE identical? Nobody had asked, because there
had never been more than two files to ask about. 79 of 80 groups are
byte-identical across every copy, including all ten seven-copy groups. The one
that differs is /rom_tags, and it differs by the signing pass described below
— which means the file duplication is not a versioning artefact and not a
build accident.
Two — and this is the finding: the unit of duplication is not the file. Sort every copy of every file by block address and join runs that touch:
file placements (every copy of every file) 597
contiguous runs, joining gaps of <= 4 blocks 192
distinct run contents 149
contents that occur once 125
contents that occur more than once 24
the repeated runs hold 47 distinct files and are pressed 67 times
The runs cross directories:
pressed 4 times, 6 files, 105 blocks each, at 41421, 43838, 48091, 64339
/OrgData/etc/NowLoading.cel /OrgData/etc/colcel.cel
/OrgData/human/HumanPol.bin /OrgData/images/image.scp
/OrgData/mes/mes.scp /OrgData/stream/stream.scp
and two files that travel together keep their offset in every copy:
/OrgData/window/pen.cel 5734, 7432, 57948, 84212, 84236, 119708, 120227
/OrgData/window/cursor.cel 5737, 7435, 57951, 84215, 84239, 119711, 120230
+3 +3 +3 +3 +3 +3 +3
When an Opera disc duplicates content, the unit is a contiguous run of files drawn from whatever directories a scene needs, and a file's copy count is how many times its run was written.
[1 of 1].
That is the CD-i result in its exact form, and it is worth being precise about which half transfers. The content duplication is measured. The working set is measured, because the runs cross directories and hold the kinds of file one scene needs at once. The drive's behaviour is not measured and this document does not assert it: what can be computed from a disc image is that a bundle pressed seven times at roughly even spacing cuts the worst-case seek to reach it from 128,300 sectors to about 18,329, and that is arithmetic rather than a designer's reasoning.
And the root directory says the same thing a second way — see the layouts below, where this disc is the first of six whose root copies are not clustered.
[2 of 2], and this is the most productive pass on the platform.
Compare the copies. They disagree, on both discs, in the same two ways.
The first disc had two disagreeing groups of 41; the second has five of 29. Every differing byte on the second was classified rather than sampled:
| group | differing bytes | a case bit | not case |
|---|---|---|---|
/System/Drivers |
41 | 40 | 1 |
/System/Folios |
18 | 18 | 0 |
/System/Programs |
138 | 138 | 0 |
/System/Scripts |
10 | 10 | 0 |
/rom_tags |
77 | 0 | 77 |
Kind one — case. 206 of 207 differing bytes in the four directory groups
are a case bit, and copy 0 holds the upper-case letter 206 times of 206.
Copy 0 writes BLINK.ROM, AUDIOFOLIO, STARTOPERA; the later copies write
blink.rom, audiofolio, startopera and agree with each other. Exactly what
the first disc showed in /System/Folios, now in four directories on a
different studio's disc.
[4 of 4], on a third disc that looked like a counterexample and is not, and
on a sixth that looked like an older naming convention and is not either.
The third disc's system directory is spelled /system, in lower case, in
all seven copies of the root, which are byte-identical. Its five disagreeing
directory groups give 272 differing bytes, 272 of them case bits, and copy 0
holds the upper case 272 times of 272.
And the seventh disc runs the test on a /System that is byte-identical
with the second's on 116 files of 116, which makes it a control rather than a
sample. Its four disagreeing directory groups give 41, 18, 138 and 10
differing bytes — 207, of which 206 are a case bit and copy 0 holds the upper
case 206 times of 206 — which is Super Street Fighter II Turbo's table
reproduced entry for entry, on a different studio's disc pressed 117 days
earlier. The one byte that is not a case bit is at +255 and it is a length:
00 00 05 34 = 1,332 in copy 0 against 00 00 05 78 = 1,400 in copies 1 and 2.
CPORT49.ROM, the signing pass, caught in the directory on a third disc.
The sixth disc is the cleanest run of this test yet. Its /System reads
OPERAMATH, GRAPHIX, AUDIOFOLIO, ALLOCATE, CHKNVRAM, GDBUG in copy 0,
where the 1994-95 discs read operamath and graphix, and a session that read
one copy would conclude the 1994 SDK used upper-case names. It did not:
Doctor Hauzer, over all 33 directory groups
/System/Folios copy at 44,136 26 differing bytes, 26 are a case bit
/System/Programs copy at 44,139 154 differing bytes, 154 are a case bit
/System/Scripts copy at 44,141 10 differing bytes, 10 are a case bit
--- ---
190 190
190 of 190, copy 0 upper on every one. Counted across the discs that have disagreeing directory groups: 272 of 272 on the third and 190 of 190 on the sixth, and 206 of 207 on the second — where the one byte that is not a case bit is the signing pass appending a signature after a driver's declared end. Reading a single copy is what makes this look like a naming convention, and it is why the pass exists. So the rule is about the case of the entries inside a block, never about a directory's own name — a directory's name lives in its parent's record, and the root is written once.
The folding is not tolower(), and the third disc says what it is instead.
Copy 1 of /System/Drivers on the second disc writes cport4D.rom with the
capital D left standing; the third disc has that again and four names no
case function produces:
copy 0 copies 1 and 2
LANGUAGES Languages
TUNERS Tuners
INTERNATIONAL International
WALKER Walker
CPORT4D.ROM cport4D.rom
type type (unchanged: already lower case in copy 0)
And there is a referee outside the file system. The SDK's own boot script,
/System/Scripts/STARTOPERA, writes alias languages $drivers/Languages and
alias tuners $drivers/Tuners — agreeing with copies 1 and 2 against copy 0.
The later copies carry the names as the build tree had them; copy 0 is the one
that has been through something, and the console finds the files either way
because lookup folds case.
Kind two — the patch pass. /rom_tags disagrees on all three discs, in the
same fields, with the same values. The third disc derived the file, which
makes the statement exact.
/rom_tags is a table of 32-byte records — 96, 128, 128 and 192 bytes
declared on the four discs, so 3, 4, 4 and 6 records declared, and every one
lines up field for field:
+0 u8 0x0f constant on 13 records of 13, across three discs
+1 u8 type 0d, 07, 0c, 02, 10, 05
+2 u16 flags
+4 u32 zero on 13 of 13
+8 u32 type-specific 1
+12 u32 type-specific 2
+16..+31 zero on 13 of 13
[1 of 4], and it is a trap in the extraction and not in the disc. The
declared length is not the number of records the block holds. The fourth
disc's /rom_tags directory entry says 128 bytes and its block holds
six records, 192 bytes, the last two — types 0x10 and 0x05 — lying
past the declared end where opera.py --extract will never write them. Its
twin does the same, at the same offsets. So the line above that reads
"rec 4 (type 10) ... third disc only" is wrong: types 0x10 and 0x05 are
on three discs of four and only the third one declares them. Read the BLOCK,
not the file.
[5 of 5], and the fifth value is the one that turns it into a clock.
Two of the record types carry a kernel file's size in their +12 word.
pressed record 0x07 field B /System/Kernel/os_code
Crash 'n Burn 1993-09-09 78,852 78,852
Doctor Hauzer 1994-04-15 79,692 79,692
Slayer 1994-08-16 85,896 85,896
FIFA Int.Soccer 1994-09-15 85,896 85,896
Alone in the D. 1994-12-19 85,896 85,896
SSF2T 1995-01-10 85,896 85,896
Wolfenstein 3D 1995-09-06 115,520 115,520
record 0x10 field B /System/Kernel/misc_code
Doctor Hauzer 2,912 2,912
Slayer 2,912 2,912
FIFA Int. Soccer 2,912 2,912
SSF2T 2,912 2,912
Wolfenstein 3D 2,908 2,908
Five discs, five exact matches, and now five DISTINCT os_code sizes —
and the fifth arrived on a disc pressed between the two values that bracket it,
so os_code grows monotonically with the 0x0c date on six discs of six.
Nothing inside os_code knows what date is in /rom_tags. Two unrelated
numbers agreeing on an ordering is the cheapest corroboration this document has
for the epoch, and it costs one ls.
Four exact matches on misc_code, Crash 'n Burn having no 0x10 record.
Record 0x0d is NOT the same thing for boot_code, [1 of 6]: it matches
on Crash 'n Burn alone (2,076), misses by exactly +118 on four discs —
SSF2T, Slayer, Alone in the Dark and Doctor Hauzer, all at 5,168 against 5,050 —
and by -1,744 on Wolfenstein 3D. A constant miss of 118 on four discs whose
SDKs span eight months is a field with a fixed overhead in it, and it is
described rather than named.
[5 of 5]. Record 0x05's +8 word is one less than /signatures'
first block: 74,440 against 74,441 on the fourth disc, 139,344 against
139,345 on the second, 42,766 against 42,767 on the third, and 126,134
against 126,135 on the sixth. An identity with an off-by-one in it, which is
the shape a last block before field has, and it is stated as the arithmetic.
Note that this is one of the words the signing pass patches, so take it from
copy 0.
Every word the signing pass patches is the +8 word of a record, and no
other byte of any record changes:
copy 0 copy 1
rec 0 (type 0d) 00000001 ffffff20 <- identical on all three discs
rec 1 (type 07) 00000005 ffffff24 <- identical on all three discs
rec 4 (type 10) 00000045 ffffff64 <- also 2nd and 4th, undeclared
rec 5 (type 05) 0000a70e 0000a62d <- also 2nd and 4th, undeclared
So the third disc does not patch more and does not have more tags: it is
the only one that declares the tags it has. The fourth disc's two copies
patch the +8 word of records 0x0d, 0x07, 0x10 and 0x05 and leave
0x0c and 0x02 alone, which is the same four-of-six pattern.
[2 of 2], and the offset is fixed. Sixty-four bytes of high-entropy data
sit at offset +224 of the /rom_tags block, wholly different between the
two copies. The second disc's tag table is 128 bytes and the third's is 192, so
+224 is 96 bytes past the end on one and 32 on the other: it is a fixed
offset in the block, not something appended after a declared end. 64 bytes is
512 bits, and the same 512 bits appear appended after CPORT49.ROM's declared
end on the second disc, which is the one non-case byte in the table above.
So the disagreement is the SDK's disc builder and not either studio, and it is not corruption. One copy is written before the volume is signed and one after: before, the type-specific words are small integers and a driver ends where its header says; after, the words are patched and the driver's entry has grown by a terminator and a signature.
The redundancy Opera keeps in its index records the state of the disc at two different moments of its own build, and reading both copies is how you watch the build happen. This closes open question 2, and it is the strongest reason to run this pass on every 3DO disc.
[unverified], and it stays that way after two discs. burst and gap
look like interleave parameters for streaming reads. The first disc sets them
to 1 and 0 on all 489 entries, including on its 188-megabyte streamed movie
archive. The second sets them to 1 and 0 on every entry of all 29 groups,
including on 63 streamed AIFF-C files totalling 268 megabytes — which is
precisely the case that should have exercised an interleave parameter, and did
not.
862 entries across two SDKs, one value. Either they are not interleave parameters or neither SDK used them. A field that is constant tells you nothing about its meaning, and this mark is deliberately not promoted: being measured twice and found constant twice is not evidence about what it means.
[corrected], and it was never checked with a hash. This document said:
four one-byte ones, all identical, all called junk, all holding 0x0d — and
the four on the second disc are byte-identical to the four on the first. They
are not.
Crash 'n Burn 4 files, 1 byte, b'\n' (0x0a) sha1 adc83b19e793491b…
SSF2T 4 files, 1 byte, b'\r' (0x0d) sha1 11f4de6b8b45cf80…
Wolfenstein 3D 1 file, 1 byte, b'\r' (0x0d) sha1 11f4de6b8b45cf80…
The first disc's hold a line feed and the other two a carriage return. Same name, same length, different byte, different hash. Two of three are identical to each other and the earliest is not identical to either.
[3 of 3] What survives: zero zero-length files on all three discs, and the
disc builder will not make an empty directory — it drops a one-byte placeholder
in instead.
[1 of 3] And whether the placeholder is removed once the directory has
contents is not settled and the three discs disagree:
Crash 'n Burn /System/Drivers empty, junk present
SSF2T /System/Drivers holds six drivers AND a junk
Wolfenstein 3D /system/Drivers holds four drivers and two subdirectories,
NO junk; the only junk left is in /system/Daemons, which is empty
The second disc's the builder makes one pass and never revisits is contradicted by the third, where every directory that gained contents lost its placeholder. Count went 4, 4, 1.
[deleted], and the deletion survives a third disc. Timestamps in the
file system. This document asked what epoch the format's dates use and whether
directory records carry a date at all. They do not. There is no date field
in the directory entry, none in the block header and none in the volume label.
Every field of the 72-byte record is accounted for. No build-schedule
histogram is possible from this file system on any disc, and this instruction
stays deleted.
[4 of 4] on the field and [1 of 1] on the outside check — the fourth
disc came and it narrowed this without closing it.
There is a date on the disc, and it is in /rom_tags. The tag record of
type 0x0c carries one 32-bit value in its +8 word, zero everywhere else,
identical in both copies — the signing pass does not touch it. Across the
three discs:
Crash 'n Burn 0xa8b496ae = 2,830,407,342
Doctor Hauzer 0xa9d42b59 = 2,849,254,233
Slayer 0xaa763794 = 2,859,874,196
FIFA Int. Soccer 0xaa9e2711 = 2,862,491,409
Alone in the Dark 0xab1b6151 = 2,870,698,321
SSF2T 0xab382bd6 = 2,872,585,174
Wolfenstein 3D 0xac737cff = 2,893,249,791
Monotonically increasing, in press order. Read as seconds since 1 January
1904 — the epoch this platform already uses for the 80-bit extended floats in
every COMM chunk on every one of these discs — they are
Crash 'n Burn 1993-09-09 08:15:42 released 4 October 1993
Doctor Hauzer 1994-04-15 11:30:33
Slayer 1994-08-16 09:29:56
FIFA Int. Soccer 1994-09-15 16:30:09
Alone in the Dark 1994-12-19 16:12:01
SSF2T 1995-01-10 12:19:34
Wolfenstein 3D 1995-09-06 16:29:51
Seven values, monotone in every pairwise comparison, and the seventh lands
30 days after Slayer inside a cluster of four discs that share one SDK drop
— Slayer, FIFA, Alone in the Dark and Super Street Fighter II Turbo, spanning
147 days, with FIFA byte-identical to two of them on 116 /System files of
116. A wrong epoch preserves the ordering; it does not preserve a date that
has to fall thirty days after one identical operating system and ninety-five
before another.
[1 of 1], and the sixth disc adds a route no earlier disc could: the epoch
is checked against a PICTURE. /OrgData/images/CopyRight.img, rendered,
reads
Doctor Hauzer
(C)1994 Riverhill Soft Inc.
(C)1994 Matsushita Electric Industrial Co.,Ltd.
Under the 1904 epoch that disc's 0x0c word is 1994-04-15, which agrees.
Under a 1900 epoch it is 1990-04-19, and a disc pressed in April 1990
cannot carry a 1994 copyright notice. Under a Unix epoch it is 2060. The
rendered art refutes the 1900 epoch from inside the object, and it is the
first check on this question that came from decoding rather than from
arithmetic. It is not the outside check open question 8 asks for — that wants
a disc whose pressing date is documented independently, and this one does not
have one either.
And the sixth disc lands where three independent series say it should. Its
pressing date puts it second of six; its /System file count (102, between 94
and 116), its DSP instrument bank (56, between 53 and 63) and its os_code size
(79,692, between 78,852 and 85,896) each put it second of six as well, and none
of the four measurements can see any of the others.
The fifth value adds a constraint the first four could not. Slayer, Alone
in the Dark and Super Street Fighter II Turbo carry the same SDK build stamp
to the second, and this clock places all three of them inside 147 days —
125 days from the first to the second and 22 from the second to the third —
with the second and third sharing 116 of 116 /System files byte for byte.
An epoch that is wrong by any amount preserves the ordering, but the fifth
disc has to land between two discs whose operating system is identical, and
it does.
And it reorders two discs that share an SDK build to the second. Slayer and
Super Street Fighter II Turbo both carry
operamath.dev 21.10.603 05/10/94 21:49:54 stan port1_3 and both carry
startopera,v 1.16 1994/04/05; their /System trees are 115 files identical
of 116. On this clock they are 147 days apart, Slayer first. No release
year could have said that.
The first is twenty-five days before its disc's documented release date.
Under a Unix epoch they land in 2059–2061; under a 1900 epoch in 1989–1991.
Four points, monotone, in the right years, with one checkable against an
outside fact — but the second falls a few months after the date usually given
for its release, which is what a repressing looks like and also what a wrong
epoch looks like. Marked [5 of 5] on the reading and [1 of 1] on the outside check,
because it has now been observed five times and checked against a documented
release date once. The fifth disc was asked for and delivered — a fifth
monotone point, a fifth positive gap against its own SDK stamp, and the
between-two-identical-/System-trees constraint above — and it has no
documented pressing date of its own either, so the outside check has not
moved. The request in this document was under-specified: what closes this is
not a fifth disc, it is a disc whose pressing date is documented
independently. Restated that way for the sixth.
A second, mechanised argument for the epoch, from the fourth disc's
repository. Two constraints, both internal to the objects: (1) each disc's
date must fall after that disc's own SDK stamp, and (2) the gap must be under
five years. The first alone settles nothing — 1904, 1970 and 1980 all pass
it — and only 1904 passes both, on four of four. romtags.py --epochs in
3do-adndslayer-doc prints the
table. The COMM-chunk argument above is the better one and it came first;
this one is independent and reproducible and that is all it is for.
[1 of 2], and it is what to do instead. Dates exist inside files, put
there by the development tools, and they date the SDK rather than the game.
On the second disc there are exactly three, one occurrence each over
310,689,792 bytes:
/System/Scripts/STARTOPERA $Id: startopera,v 1.16 1994/04/05 22:18:25 vertex Exp $
/System/Folios/operamath Tue May 10 21:49:54 PDT 1994
/DEM/E_GOU_G.HCH SPT v0.54 (a tool's version, not a date)
$Id: 1, Exp $ 1, $Revision 0, $Date 0, $Author 0. The first disc had
none of these. Three artefacts are not a histogram — they are three
artefacts, and they put a floor under the pressing: no earlier than 10 May
1994. Grep for $Id:, PDT, PST, GMT and version strings; do not build a
distribution out of what you find.
[4 of 5], and this is the strongest mark this document ever lost.
Sector map. Attribute every sector to a file, a copy, a directory, the
mastering fill, or nothing, and refuse to print a total that is not the sector
count. Four discs closed with zero unowned sectors and zero double claims on
the first pass. The fifth does not close, and it is not close to closing:
Alone in the Dark
file 176,034 91.2987 %
second copy 2 0.0010 %
directory 22 0.0114 %
directory copy 64 0.0332 %
iamaduck fill 0 0.0000 % <- NONE, on a disc 91 % full
all zero 521 0.2702 %
owned by nothing 16,168 8.3854 % <- in 29 runs
-------
192,811 100.0000 % double claims: 0
Zero double claims is [5 of 5]. Everything else about this line is now
[4 of 5], and §13 is what is in the 16,168.
What still holds on all five, and it is worth separating from what broke: the map must still be run, it must still refuse to print a wrong total, and it is still the thing that tells you a disc is unusual before you know why. On this disc it was the first measurement anybody took and it is what the whole session turned out to be about.
The five that close:
Crash 'n Burn SSF2T Wolfenstein 3D Slayer
file 271,669 88.3632 % 139,405 91.8928 % 42,857 75.5829 % 133,224 88.0296 %
second copy 2 0.0007 % 2 0.0013 % 2 0.0035 % 2 0.0013 %
directory 46 0.0150 % 35 0.0231 % 26 0.0459 % 40 0.0264 %
directory copy 96 0.0312 % 74 0.0488 % 56 0.0988 % 45 0.0297 %
iamaduck fill 35,387 11.5100 % 12,036 7.9339 % 13,379 23.5953 % 17,729 11.7147 %
all zero 246 0.0800 % 152 0.1002 % 382 0.6737 % 300 0.1982 %
owned by nothing 0 0.0000 % 0 0.0000 % 0 0.0000 % 0 0.0000 %
------- ------- ------- -------
307,446 100.0000 % 151,704 100.0000 % 56,702 100.0000 % 151,340 100.0000 %
And the sixth, whose second copy row is the reason this document has a §3
correction:
Doctor Hauzer
file 79,010 61.5822 %
second copy 43,970 34.2712 % <- 90,050,560 bytes of FILE content
directory 40 0.0312 %
directory copy 84 0.0655 %
iamaduck fill 4,896 3.8161 %
all zero 300 0.2338 %
owned by nothing 0 0.0000 %
-------
128,300 100.0000 % double claims: 0
And the seventh, which is the control the sixth disc's second copy row
needed:
FIFA International Soccer
file 254,952 84.3151 %
second copy 2 0.0007 % <- back to two, on 90.8 % of a CD
directory 33 0.0109 %
directory copy 86 0.0284 %
iamaduck fill 47,007 15.5457 % in FOUR regions
all zero 300 0.0992 %
owned by nothing 0 0.0000 %
-------
302,380 100.0000 % double claims: 0
Five discs of seven close at zero unowned, so the mark is [6 of 7] and
Alone in the Dark remains the single exception. Zero double claims is
[7 of 7].
And the second copy row is the seventh disc's best negative result. It is
90.8048 % of a CD with 43 films to seek between — exactly the working set
the sixth disc's seek-distance reading would predict content duplication for —
and it duplicates two sectors: /Disc label and /rom_tags, the behaviour
of six discs of seven. Doctor Hauzer's 34.2712 % is an exception of seven and
not a rule of two, and this is the disc that says so, because it is the one
that had the motive.
Note what the map does to a coverage figure, because it is a trap the earlier
five could not set. bytes in files is 61.4050 % here against the fifth
disc's 91.2301 %, and the disc is not emptier — a third of it is copies, which
belong to files and are not bytes in files. On any disc with a second copy
row above a fraction of a per cent, say explicitly whether a published coverage
figure counts the copies, because the two answers differ by 34 points.
[2 of 2], on the second disc and the fourth, and the fourth makes it
enormous. Count the all-zero sectors twice, once for the map and once for
the truth. A pass over every sector of the second disc finds 17 runs of
all-zero sectors, not one: sixteen of them, 159 sectors, are inside files as
internal padding and are correctly attributed to those files; only the
seventeenth, the 152 past the declared volume, belongs to nobody. "152 zero
sectors" and "311 zero sectors" are both true and only one answers what does no
file own.
On the fourth disc the two numbers differ by a factor of ten. A raw pass
finds 2,928 all-zero sectors in 684 runs; the map's zero bucket says
300. The other 2,628 -- 1.7365 % of the pressing -- are inside files:
silence in a 209-megabyte uncompressed soundtrack, transparent runs in cels,
padding in the films. A tool that counted zero sectors without asking who owned
them would have called 1.9347 % of that disc empty and been out by an order of
magnitude. The 300 that are free are exactly the 300 past the declared
volume, contiguous at 151,040..151,339, so on that disc "the zero tail" and
"the undeclared sectors" are one fact stated twice.
[2 of 2] The fourth pass — compare the copies — is the one that paid,
on both discs and more on the second. One pass over 146 blocks found the best
structural result on the first; one pass over 113 blocks on the second found
the signing pass, a file with two lengths, and the answer to open question 2.
Cheapest high-value pass on this platform. §3.
[4 of 5], and the fifth disc is the one that says what the fill is FOR.
The Opera mastering tool fills unused space with the repeating ASCII string
iamaduck, phase-aligned to the start of each sector, 256 repetitions per
2,048-byte block. It begins in sector 0, at offset 132, immediately after the
volume label record.
Alone in the Dark has zero occurrences of iamaduck over 394,876,928
bytes. Not one, anywhere, and the search was run where it could have found
something — sequentially over the whole user area, which is the search that
found 9,121,860 of them on the first disc.
And the consequences are visible in three places at once, which is what makes this more than a missing feature:
- at the end of the pressing, 16,664 contiguous sectors hold a PC's Watcom C/C++ 10.0 installation (§13);
- at block 0,
/Disc label's two copies differ in 1,905 of 2,048 bytes — everything after the 132-byte record — where on four discs of four both copies wereiamaduckand the comparison found nothing; - inside files, in every fixed-size buffer the build wrote without filling: 24,419,372 bytes of a Macintosh's memory, one 1,515,520-byte block of it pressed sixteen times (§13).
So the fill is not decoration and it is not only about free space. iamaduck
is what stops a 3DO disc from publishing whatever the master was written over,
and a disc without it publishes all of it.
Crash 'n Burn 9,121,860 occurrences 72,974,880 bytes 11.5896 % two runs
SSF2T 3,133,752 occurrences 24,649,728 bytes 7.9339 % ONE run
Wolfenstein 3D 3,455,165 occurrences 27,400,192 bytes 23.5953 % ONE region
Slayer - 36,308,992 bytes 11.7147 % TWO regions
Alone in the Dark 0 occurrences 0 bytes 0.0000 % NONE
Doctor Hauzer 1,344,484 occurrences 10,027,008 bytes 3.8161 % scattered
FIFA Int.Soccer 12,089,962 occurrences 96,270,336 bytes 15.5457 % FOUR regions
[1 of 7] on the straddle count, and the seventh value is zero. This
document says to read the fill sequentially with an overlap because matches
straddle sector joins: the first disc's two counts differ by 58, the second's
by 26, the sixth's by 1. On the seventh they are equal — 12,089,962 both
ways — because the fill is phase-aligned to the sector and 2,048 is exactly
256 x 8, so a run can only straddle a join where the fill begins mid-sector,
and on this disc it never does except at block 0. A difference of zero is
still worth the command, because it is the check that transfers and not the
number.
[1 of 1], and it is this document's own lesson arriving in a new place:
COUNT THE FILL TWICE, exactly as you count the all-zero sectors twice. The
sixth disc's sequential count is 1,344,484 and its duck bucket is 4,896
sectors, which is 4,896 × 256 = 1,253,376. The other 91,108 are not
unaccounted for and they are not free space:
sectors containing iamaduck at all 5,481 of 128,300
sectors that are 256 repetitions (pure fill) 4,896 <- the map's duck bucket
sectors with a PARTIAL run 585 holding 91,107
per-sector total 1,344,483
sequential total, with an overlap 1,344,484
difference: one match straddling a sector join 1
The 585 are blocks the FILE SYSTEM owns — the round-up slack in files' last
blocks and the space past first_free_byte in directory blocks — where the
master's fill was allocated over and never overwritten. Zero occurrences are
inside any extracted file, because the extractor truncates to byte_count.
So 4,896 sectors of this disc are fill and 5,481 sectors of this disc contain fill are both true and only the first answers what does no file own. The mistake this prevents is exactly the one the zero-sector rule prevents, one level along, and it is worth one command on every disc.
On the third disc a per-sector reader reports two runs of fill; there is one free region, 42,940..56,319, and the thing between the two runs is the seventh copy of the root directory. Count regions, not runs.
[1 of 4], and the fourth disc breaks the "one free region" story a second
time and suggests a rule instead. Slayer has two regions, of 911 and
16,818 sectors, and neither is an artefact of counting:
74,609 .. 75,519 911 sectors
134,222 .. 151,039 16,818 sectors
-------
17,729 = the sector map's `duck` bucket exactly
Each region begins at the block immediately after a run of root-directory copies. The first four copies sit at 74,605-74,608 and fill starts at 74,609; the last three sit at 134,219-134,221 and fill starts at 134,222.
And the fifth disc turns that candidate rule into a statement about the BUILDER rather than about the fill. It has no fill and it has two regions of sectors owned by nothing, and both of them begin at the block immediately after a run of root-directory copies: copies at 128,295..128,310 end at 128,314 and a hole opens at 128,315; copies at 176,137..176,142 end at 176,146 and the 34-megabyte region opens at 176,147. Both joins close to the block. So:
The builder writes up to the end of a run of root-directory copies and stops. On four discs the mastering tool then fills what follows. On one it did not, and what follows is whatever the medium already held. §13.
And the SEVENTH disc closes it, with four independent joins on one object. Its root is five blocks and its seven copies sit at 100038/100043/100048, 201265/201270, 255814 and 258925, so the runs of copies END at 100,052, 201,274, 255,818 and 258,929. Its fill:
100,053 .. 100,692 640 sectors run of root copies ends 100,052
201,275 .. 201,385 111 sectors 201,274
255,819 .. 258,924 3,106 sectors 255,818
258,930 .. 302,079 43,150 sectors 258,929
--------
47,007 = the sector map's `duck` bucket exactly
Four of four, every join closing to the block, on one disc. The fourth disc gave two joins and the fifth two holes; this gives four, and the fill region between 255,819 and 258,924 ends immediately before the next root copy, which the rule also predicts.
[4 of 4]on the joins, across three discs and eight independent instances: the builder writes up to the end of a run of root-directory copies and stops. What follows is fill on five discs and the medium's previous contents on one. Open question 10 is answered.
Five discs, one region, one region, one region, two and four, so the count is not a rule and was never going to be — it is the number of runs the root copies happen to be split into, which §3 shows is different on every disc.
Why it matters beyond the count: because the fill is a known string rather than zeros, any sector that is not exactly 256 repetitions of it is a sector somebody wrote. Every other optical format in this family needs a pass to work that out.
[corrected], and now [4 of 4] with an arithmetic instead of a story.
This document said the fill fraction is the complement of how full the disc
is — 11.59 % on a disc 88.28 % full, 7.93 % on one 91.76 % full. On the third
disc, 75.3750 % full, that predicts 24.6250 % and the fill is 23.5953 %: out
by a whole point.
The rule was stated in bytes and has to be stated in sectors. The gap is 1.0297 points = 583.85 sectors, and it is exactly three things:
round-up slack in files' last blocks 42,857 - 87,529,786/2,048 = 117.85 sectors
the index: 2 copies + 26 dirs + 56 dir copies = 84
the zero tail past the declared volume = 382
------
583.85
583.85 against 583.85, difference 0.0000. And on the fourth disc, which is 87.8269 % full and 11.7147 % fill against a predicted 12.1731 %, the same three terms close again:
round-up slack in files' last blocks 133,224 - 272,214,595/2,048 = 306.72 sectors
the index: 2 copies + 40 dirs + 45 dir copies = 87
the zero tail past the declared volume = 300
------
693.72
693.72 against 693.72, difference 0.0000. So:
The fill is the complement of the sectors the file system uses, and the file system uses more sectors than the files use bytes.
[3 of 3], and the sixth disc adds a FOURTH term that no earlier disc could
supply — which is a better test than a third confirmation would have been.
Doctor Hauzer is 61.4050 % full and its fill is 3.8161 %, and the gap is
enormous because a third of the disc is second copies of files:
round-up slack in files' last blocks 79,010 - 161,346,866/2,048 = 227.35 sectors
the index: 40 directories + 84 directory copies = 124
FILE SECOND COPIES = 43,970 <- new
the zero tail past the declared volume = 300
--------
44,621.35
predicted fill = 100 - 61.4050 - (44,621.35 / 128,300) x 100 = 3.8161 %
measured fill = 4,896 / 128,300 = 3.8161 %
difference = 0.0000 points
= 0.00 sectors
0.00 sectors, on a fourth disc, with the biggest term being one nobody had written down. The rule survives being handed a case it was not built for, provided the copies are counted as use — which is the same decision a coverage figure has to make, stated once and applied in both places.
Count it as waste and attribute it to the mastering tool rather than to the studio: if a studio could drive it down, the studio with the fullest disc would have driven it further, and instead the three numbers are one number seen three times.
Read the fill count over the track sequentially with an overlap, not per sector. On the second disc a per-sector count gives 3,133,778 and a sequential one gives 3,133,752; the 26 are matches straddling sector boundaries. Same effect on the first disc, same direction, and the same applies to every four-character marker.
[corrected] twice — and the second correction is that the first was about
one studio. This document originally expected the boot chain to start from a
root file named LaunchMe. The first disc appeared to show that it starts from
/AppStartup, a shell script that sets an alias and runs another script, and
this document wrote that up as the platform's boot chain. It is not.
On the second disc /AppStartup is 160 bytes and every one of them is a
comment: it is the SDK's template with nothing added. There is no runme1,
no runme2, no /ex, and the root holds five files instead of thirteen.
The platform's chain, [3 of 3]:
ROM
-> /System/Scripts/STARTOPERA the SDK's own script, on both discs
-> /AppStartup the studio's, and it may do nothing
-> the root program
STARTOPERA is the part that is the platform, and its contents changed a
great deal between the discs while the chain did not:
| 1994, rev 1.16 | 1995, rev 1.27 | |
|---|---|---|
| kills kernel debug printing | yes | yes |
the ROM fallback alias {/rom2/…|$boot/…} |
yes | yes, character for character |
mounts NVRAM with lmadm -a ram 3 0 nvram |
yes | no |
| backgrounds the maths folio | yes | no |
| loads the audio folio | yes | no |
| starts the event broker | yes | yes |
runs a filesystem check first (fg $c/fscheck) |
no | yes |
| aliases for languages and tuners | no | yes |
ends by running /AppStartup |
yes | yes |
[1 of 2], and it explains a count. The NVRAM mount left the script between
the two revisions. On the second disc nvram counts 10 and NVRAM 8, all in
/System/Programs/; on the third, nvram counts 1 — inside FSCHECK's own
usage text — and NVRAM counts 6, all six in the game, which writes saved
games to the console's memory. A count that falls by a factor of ten because a
mount moved out of a shell script is not a finding about the title.
What a studio does in /AppStartup is the studio's business, [3 of 3],
and of the three studios measured two did nothing at all: one built a circle
of two scripts alternating between a game and a preview, and the other two
shipped the SDK's template with only comments in it (160 bytes and 335 bytes).
[1 of 4] The root program's name.
LaunchMe Launchme launchme
Crash 'n Burn 1 1 7
SSF2T 0 8 0
Wolfenstein 3D 1 0 7
Slayer 7 1 0
Four discs, three spellings, and no two of the four agree: the fourth
disc's root file is LaunchMe in all seven root copies and its /AppStartup
comment says Launchme, which is the second disc's pattern with the case
inverted. On the third, all seven launchme are in
directory blocks and none is inside any file — it is the root's filename and
the root has seven copies — and the single LaunchMe is in /AppStartup, in
the SDK's own comment. So the disc says launchme, the template says
LaunchMe, and the folding is what makes the console start the game.
The dependence on the folding in the root is [2 of 3]; the second disc's
single spelling did not need it.
[corrected], and the fourth disc says the folding is not what starts the
game. The console does not look the program up by name at all on three of the
four discs: /rom_tags record type 0x02 addresses it by BLOCK. Field A is
a first block and field B a length in blocks, and it equals the boot binary's
own directory entry exactly:
Slayer 74,291 / 147 == /LaunchMe 74,291 / 147
SSF2T 139,161 / 166 == /Launchme 139,161 / 166
Wolfenstein 42,713 / 47 == /launchme 42,713 / 47
Crash 'n Burn no 0x02 record -- /launchme 179,520
Three discs, three different spellings of one filename, one identity that
closes on all three. That is why four studios could spell it four ways
without consequence, and why the case mismatch between a shipped /AppStartup
comment and a shipped filename costs nothing: nothing in the chain compares
the two.
And the launch title is the exception, which is the interesting half.
Crash 'n Burn has three /rom_tags records and no 0x02, so on the 1993 disc
something does have to find /launchme by name. On the 1994 and 1995 discs a
block pointer does it. The platform moved from a name to a block between its
launch title and its second year, and this document had the chain as
[3 of 3] without it. [3 of 3] on the 0x02 identity, [1 of 4] on its
absence.
[corrected] This document said to expect "a linked, relocatable object
rather than a flat binary; identify the header, the section table and the entry
point". That was right and the format is not a 3DO invention. The
executables are ARM Image Format (AIF) — the output of the ARM Software
Development Toolkit's linker:
0x00 BL decompress_code or NOP (0xE1A00000)
0x04 BL relocation_code or NOP
0x08 BL zero_init_code or NOP
0x0C BL entry_point
0x10 SWI &11 0xEF000011 <- the signature
0x14 u32 read-only size
0x18 u32 read-write size
0x1C u32 debug size
0x20 u32 zero-init size
0x24 u32 debug type
0x28 u32 image base
0x2C u32 work space
0x30 u32 address mode and flags
0x34 u32 data base
Measured on 164 AIF images across three discs, including the operating system's own:
| 34 | 93 | 37 | |
|---|---|---|---|
SWI &11 at 0x10 |
34 of 34 | 93 of 93 | 37 of 37 |
| flags at 0x30 == 32 | 34 of 34 | 93 of 93 | 37 of 37 |
| image base at 0x28 == 0 | 34 of 34 | 93 of 93 | 37 of 37 |
| debug size at 0x1C == 0 | 34 of 34 | 93 of 93 | 35 of 37 |
entry point from the BL at 0x0C |
0x100 on 34 | 0x100 on 93 | 0x100 on 37 |
relocation target from the BL at 0x04 |
ro+rw on 31, +4 on three |
ro+rw on 93 |
ro+rw+debug on 37 |
Entry point 0x100 on 164 images of 164 was the strongest single number in
this document at three discs. Counted across every disc that has published a
figure — 164 on the first three, 41 on the fourth, 41 on the fifth, 36 on the
sixth and 41 on the seventh — it holds on 323 images of 323, [7 of 7].
[corrected]. The relocation branch points at ro + rw + debug, not at
ro + rw. The first two discs shipped debug size 0 on every one of their
127 images, so the two expressions were the same number and the shorter one got
written down. The third disc has two images with a debug area and they land on
the longer sum to the byte:
FMVVIDEODEVICE.PRIVDEVICE ro 31,536 + rw 6,788 + debug 44,580 = 82,904 = 0x143d8
COMPRESSION.FOLIO ro 4,332 + rw 376 + debug 3,204 = 7,912 = 0x1ee8
reloc target == ro + rw + debug holds on 164 of 164 across three discs and
the earlier form is a special case of it.
[2 of 3]. Symbols do get shipped. Debug size 0 on 127 of 127 — no symbols
shipped is no longer general: two of the third disc's 37 images carry a debug
area. Both are the SDK's, and no studio has shipped symbols on any disc.
[1 of 7], and the seventh disc turns the exception into a rule about
studios. It is the first disc with three studio binaries and all three
break reloc target == ro + rw + debug:
FIFA International Soccer
/PlayMovieOvl ro 42,524 rw 2,668 debug 0 target 45,196 = sum + 4
/launchme ro 369,752 rw 63,036 debug 0 target 432,792 = sum + 4
/playlist ro 76,032 rw 9,068 debug 0 target 85,104 = sum + 4
/System's 38 images 38 of 38 ON the rule
Across four discs that have published the split, 148 SDK images are 148 of 148 on the rule and every exception anybody has found is a title's own binary — 1 of 3 studio binaries on the fourth disc, 2 of 3 on the fifth, 1 of 1 on the sixth and 3 of 3 here. Open question 11.
[corrected] The +4 on three of the first disc's images is not a
property of the format. Ninety-three images built against a later SDK land on
ro + rw exactly. Three anomalies on one disc and none on another: whatever
produced those three did something the toolchain does not normally do. The
claim that the branch points at the start of the relocation data holds on both.
read-only + read-write never equals the file size. The remainder is the
self-relocation code and its table, appended after the image, and the branch at
offset 4 points at exactly where it starts. Do not treat the difference as
unexplained.
[2 of 2] ARM6, 32-bit, big-endian, no Thumb — confirmed by the header
flags and by every instruction decoding correctly big-endian, on both discs.
[corrected] — the test had two halves and the second one is wrong. This
document said: compressed images have a BL at offset 0 where the others have
a NOP, and their declared sizes exceed the bytes on the disc. On the third
disc the BL fires on 20 images of 37 and the size relation contradicts
it on eleven of the twenty, which no decompressor can do.
The BL is right. The size relation is not a test, because ro + rw + debug is not the whole decompressed image: the relocation table is compressed
with it and is counted in no header field.
Two structural tests decide it instead, and neither uses a size:
- the appended routine. Past its relocation data a compressed image carries
the decompressor the
BLat offset 0 branches to. On the third disc that tail is 392, 456 or 464 bytes on 20 images of 20, and 0 of the 17 with a NOP have one. Two of them are byte-identical to each other; - the body does not look like ARM code. 32-bit ARM is overwhelmingly
unconditional, so the top nibble of the first byte of each word is
0xEfar more often than chance. Over the body: compressed images run 0.0796 to 0.1806 and uncompressed 0.5308 to 0.7717, with Shannon entropy 6.7969–7.2013 against 5.2731–6.0369. Two statistics, two populations, no overlap, 37 of 37.
[3 of 3] With that correction the finding stands and is stronger:
Crash 'n Burn 4 of 34 AUDIOFOLIO GRAPHIX eventbroker shell
SSF2T 5 of 93 AUDIOFOLIO GRAFMATH graphix eventbroker shell
Wolfenstein 3D 20 of 37 every one under /system
FIFA 5 of 41 AUDIOFOLIO GRAFMATH graphix eventbroker shell
Seven studios, and not one compresses a single one of its own binaries.
The seventh disc has three studio binaries — /launchme, /playlist and
/PlayMovieOvl — and all three carry the e1 a0 00 00 NOP at offset 0, so
the count of compressed images across the collection is 4, 5, 20, 5, 5, 4 and
5, every one an operating-system component.
Twenty-nine compressed images across three discs and every single one is an
operating-system component. Three studios, and not one compresses a single one
of its own binaries — the third disc's /Playmovie, /launchme and /logo
all carry the e1 a0 00 00 NOP at offset 0. That answers open question 5 for
three discs.
OPERAMATH is compressed, then not, then compressed again — [1 of 3], a fact
about three builds rather than a policy. The audio folio, the graphics folio,
eventbroker and shell are compressed on all three.
[corrected] — there is a banner, and it took the right title to find it.
This document said: Norcroft 0, armcc 0, armasm 0, armlink 0, @(#) 0
… ten zeros; stop looking for a banner.
On the third disc @(#) counts 2, both inside /launchme, and they are
SCCS what-strings:
@(#) music.lib/soundfile
(port2_5) stan@warrior
@(#) music.lib/soundspooler
soundfile and soundspooler are the audio folio's streaming library — the
one the second disc's error strings named without naming
(CreateSoundFilePlayer: could not create spooler). The first two discs have
zero because neither of them linked it: one wrote its own codec, the other
spooled through the folio without pulling those objects into its own image. The
third disc has thirteen minutes of music to get off the disc while the game
runs, links music.lib, and the library brings its own banner, a port tag and a
build login.
[corrected], and the fifth disc found it by counting on a tree instead of
on a binary. This document said the first two discs have zero [@(#)]
because neither of them linked it. That is wrong about the second disc, and
about the fourth, and it was wrong when it was written. Counted over each
disc's extracted tree:
Crash 'n Burn @(#) 0
Super Street Fighter II Turbo @(#) 7 in 6 files, all under /System
Wolfenstein 3D @(#) 2 both in /launchme
Slayer @(#) 7 in the same 6 files
Alone in the Dark @(#) 7 in the same 6 files
FIFA International Soccer @(#) 8 7 in the same 6 files,
and ONE inside a Cinepak payload
And the eighth is the lesson about reading a context. On a 619-megabyte
object a four-byte string is expected 0.1656 times, so a count of 8 against 0.1656
looks overwhelming — and one of the eight is four bytes of compressed video
inside stream.1986Eng2. Seven of the eight are the SDK's, in the same six
files as on the three discs that share this SDK build.
The six are /System/Folios/AUDIOFOLIO, GRAFMATH, graphix, operamath,
/System/Kernel/os_code (twice) and /System/Tasks/eventbroker. Four discs
of five carry them and only the 1993 launch title does not, so the what-string
is a property of the SDK drop rather than of what a studio linked. Three of the
six are compressed images, which is why the strings read as garbage until the
one uncompressed instance is found:
@(#) operamath.dev 21.10.603 05/10/94 21:49:54 stan port1_3
That is the same build stamp §4 uses to date the SDK, and it is an SCCS
what-string, which nobody had noticed because the search had been run in the
wrong place. The third disc's two remain the interesting ones — they are
music.lib's, in the studio's binary, not the SDK's.
[4 of 5], and the fifth disc is the exception in the most enjoyable way.
The four compiler names were zero over 1.06 gigabytes on three discs and are
zero on the fourth. On the fifth, armlink counts 1.
It is not in a binary. It is inside camera02.pics, in the 1,148 bytes of
uninitialised Macintosh memory that every camera-background block carries
(§13). The first appearance of an ARM toolchain name on five 3DO discs is in
a buffer nobody meant to write, on a machine whose MPW folder the same
leftovers name. Norcroft, armcc and armasm are still zero over 1.45
gigabytes.
The compiler is identifiable only structurally, from the AIF header it
emits. The libraries are not: if a disc links an SDK library that carries a
what-string, grep for @(#) — and grep the whole tree, not the title's own
binary.
[corrected], and the fifth disc makes it three. Copyright occurs
three times on this disc's own bytes, not twice, and the third is the
fourth party again:
/System/Folios/operamath Copyright 1993,1994 The 3DO Company
/System/Kernel/boot_code Copyright 1993 The 3DO Company
/System/Graphics/Fonts/Kanji16.4 Copyright (C) Matsushita Electric
Industrial Co.,Ltd. 1994
A fourth occurrence is in camera05.pics, and it is the C identifier
CopyrightNotice in a Macintosh's leftover memory (§13) — which is what a
count of four looks like before it is read.
So the shape of the claim survives and its number does not. No studio asserts copyright in text on any of the five discs. The count is 2, 2, 2, 2 and 3, and the third one is a Japanese font on a European disc, which is the same Matsushita line the third disc found on a USA disc.
[corrected], and this is the seventh disc breaking a [4 of 4] — the
strongest mark this claim ever had. FIFA International Soccer carries, twice:
/launchme offset 9,601,222 Copyright (C) Electronic Arts Canada Inc. 1993.
All rights reserved.
/playlist offset 10,472,094 the same line
Electronic Arts counts 2 over 711,197,760 bytes and both are that line;
ELECTRONIC ARTS 0, EA Sports 0, EASPORTS 0. Copyright counts 6 and
it is three different things: two are the 3DO Company's, two are Electronic
Arts', and two are the bare word Copyright\0 in ARM code with no assertion
attached to it. Read the context before reporting a total; a count of six is
not six assertions.
And the useful part of the correction is what the seventh disc says the rule was ABOUT, which no counting produces:
- the name is ALSO a picture here.
stream.easportsis 8,192,000 bytes — 29.3 seconds — of publisher logo film, the eighth-largest file on the disc. Electronic Arts did not choose text instead of art; it did both. So the rule was never studios do not put their names on discs: every studio does, and six of the seven did it only in pixels; - the text is in a place the other six had nothing in. The line is in
/launchmeand in/playlist, and/playlistis a development tool — a movie browser and shape dumper that printsEXIT TO DOS (Y/N). It is a library banner, emitted by whatever built both binaries, not a title sequence; - the year is wrong for the disc and right for the library. The line says
1993 and
/rom_tagssays 1994-09-15. A 1993 line on a 1994 pressing in two unrelated binaries is exactly the shape of the SDK's ownCopyright 1993 The 3DO Companyinboot_code.
The corrected claim,
[6 of 7]: on this platform a studio's identity reaches the disc as art, on seven discs of seven. On one of the seven it ALSO reaches it as a copyright line, and that line is in a cross-platform library's banner rather than in the game. Counted as a habit it is six of seven; read as a mechanism it is not broken at all.
What would separate the two readings: an eighth disc from a publisher of this size with no text line, or a studio's copyright line in a game binary and nowhere else.
[3 of 3], and it was true when it was written. Copyright occurs
exactly twice on each of the first three discs, and all six are
inside files that belong to the platform, not to the title. First disc:
/System/Kernel/boot_code and /System/Folios/OPERAMATH, both Copyright 1993 The 3DO Company. Second disc: boot_code and operamath again. Third disc,
and the files are different:
/system/Scripts/STARTOPERA Copyright (C) 1995, an unpublished work by
The 3DO Company. All rights reserved.
/system/Graphics/Fonts/Kanji16.4 Copyright (C) Matsushita Electric
Industrial Co.,Ltd. 1994
No studio asserts copyright in text anywhere on any of the three discs, and the third disc adds a fourth party — the console's manufacturer — inside a Japanese font nobody on a USA disc will read. Look at where a count of 2 is before calling it noise, and expect it to belong to somebody other than the studio.
[2 of 2] Filenames, both directions. See §6.
[2 of 2] Library and OS call sites. The question this document was
built around — does anything actually use the console's headline feature? —
has a different shape here than on the Amiga CD, and it is worth stating so no
later pipeline wastes six discs on it.
On the 3DO, the CEL engine and the audio DSP are not optional. They are the only way to draw and the only way to make sound. There is no framebuffer to write to by hand and no DAC to feed. So the answer to does anything use them is yes, necessarily, and the productive question is how: through the folios, or by touching hardware.
On the first disc it is through the folios, and the counts say so: Folio 17,
AudioFolio 6, GraphicsFolio 3, plus cnbOpenGraphics, InitHardware,
DrawObjects, DrawMiniHUD and — decisively — FMV's CCB buffer, which means
even the movie decoder hands its output to a cel control block. Count the
folio symbols, not the hardware register writes.
[2 of 2] The second disc says the same thing in its error strings:
Error opening GraphicsFolio (%d), CreateSoundFilePlayer: could not create spooler, CreateSoundFilePlayer: too few buffers requested, %d < 2,
ssplCreateSoundBufferNode: AttachSample, RewindSoundFile, ReadSoundFile nothing left to read, LoadCode() failed.
And those strings name the mechanism for streaming audio, which is the
second disc's whole thesis: CreateSoundFilePlayer with a spooler and a
buffer count is the audio folio's streaming interface. A disc that is 86 %
music does not load it; it spools it through a ring of buffers while the drive
does other things. If a 3DO disc is mostly sound, look for
SoundFilePlayer before looking for a container format — there is not one.
[3 of 3] Print the chance expectation beside every count. On a
629,649,408-byte object a three-byte string is expected 37.53 times and a
four-byte string 0.1466; on a 310,689,792-byte one, 18.5186 and
0.0723; on a 116,125,696-byte one, 6.9218 and 0.0270. On the first disc CEL counts 82 and CCB counts 57, both
indistinguishable from noise, while PDAT counts 1,818 and PLUT 1,349, both
overwhelming. On the second, CCB at three characters counts 801 and CCB at
four counts 774 — and the difference between those two numbers is the only
way to know that 774 is not noise.
[1 of 2], and it is a correction to how this document reasons. A count of
one against an expectation of 0.0723 is not "fourteen times the noise".
For a Poisson process with λ = 0.0723, P(X ≥ 1) = 6.97 % — one occurrence is
unremarkable. Ratios of counts to fractional expectations are meaningless
below about five occurrences; use the tail probability. The second disc's single
FILM looked like a signal by the ratio and turned out to be the word film
inside the victory line RE-DIZZY COMBO ON FILM!.
[2 of 2] The denominator is the pressing, not the file tree. A tool
that walks files misses the sectors no file owns — 11.6 % of one disc and
8.2 % of the other — and it also misses the directory blocks, which is
where filenames live.
The decisive demonstration is on the second disc: GOUKI counts three over
the track and zero inside any file. It is the name of /MAP/GOUKI_ST.DAT,
and a directory has three copies. A file-tree search finds nothing; a pressing
search finds a character's name three times.
And read the track sequentially with an overlap, not per sector: matches
straddle sector boundaries and the counts differ. First disc, iamaduck
9,121,860 against 9,121,802 and PDAT 1,818 against 1,817; second disc,
iamaduck 3,133,752 against 3,133,778 and PDAT 851 against 852.
[2 of 2] Case. This is the first disc's signature and it will cost
somebody an afternoon. The file system, or the layer above it, folds case,
and the first disc depends on that in at least 23 places:
executable disc
$exdir/CNB/carbitmaps/baracuda.3DO /CNB/CarBitmaps/baracuda.3DO
$exdir/CNB/tracks/clouds /CNB/Tracks/clouds
CNBMOD/utopia16.mod /CNBMOD/UTOPIA16.MOD
$boot/Launchme /launchme
It also folds inside the file system's own copies (§3), inside one directory's
own filenames, and — most expensively — on the studio's name:
Crystal Dynamics occurs zero times on the first disc and
Crystal dynamics occurs seven. Search names case-insensitively, or
search every spelling.
[2 of 2] The second disc depends on the folding in 66 of the 124
path-shaped strings in its main executable — it says chr/19.chr,
dem/S_DISP60.R, map/00.dat and the disc holds /CHR/19.CHR,
/DEM/S_DISP60.R, /MAP/00.DAT. Two discs, two studios, both depending on a
case-insensitive file system. This is the single most transferable thing to
know about writing an Opera reader, and it now applies to the directory
copies, the executables' path tables and the root file lookup.
[2 of 2], and searching every spelling is not enough. On the second disc
Capcom counts zero, and so do CAPCOM and capcom, over 310,689,792
bytes. The studio's name is on the disc drawn in pixels —
PRESENTED BY CAPCOM, in the seventeenth cel of /ENDING_S/1C_NAME.DAT — and
so is the game's title: Street Fighter counts zero and
STREET FIGHTER II is painted six times across the background of
/DEM/MVDM_PIC.DAT.
On this platform the studio's name is a picture. [3 of 3], and the third
disc makes it emphatic: id Software 0, Logicware 0, Interplay 0,
MacPlay 0, Macintosh 0, Burger 0 — six company names, zero occurrences
between them, over 116,125,696 bytes — and every one of the six is on the disc
as a picture. Wolfenstein counts 2 and both are the NVRAM label
Wolfenstein 3D prefs file; the game's title does not appear as text either.
The third disc adds a second route and it is not a cel. The publisher and
the developer are Cinepak video: /Movies/Logo.Cine burns the word
Interplay into a slab of marble over 409 frames, and /Movies/logic.cine
draws Logicware over 141. Nineteen more names, three company names, a
copyright year and the string Macintosh Version - MacPlay are painted into
three 320 x 200 cels inside an archive. Decode the art, decode the film, and
look. See §7 and §9.
[1 of 2] A name can be findable on the pressing and absent from every
file: GOUKI counts three over the second disc's track and zero inside any
file, because it is the filename /MAP/GOUKI_ST.DAT and directories have
three copies. That is the clearest possible demonstration of why the
denominator is the pressing.
[2 of 2] The two-way cross-reference, and both discs give the same
answer.
Crash 'n Burn SSF2T Wolfenstein 3D
path-shaped strings 114 124 42
resolve exactly 84 38 1
resolve case-folded 23 66 7
resolve to nothing 7 20 34
files named by nothing 335 of 451 295 of 373 189 of 197
Zero cut content on any of the three. On the third disc all 34 misses
dissolve: nine are alias targets the SDK's own boot script defines, five are
prefixes the program concatenates a number onto (Music/Song,
tSound/Sound, NVRAM/PrefsForWolf3D), two are the music.lib what-strings,
one is an RCS date, and the rest are English words with a slash in them.
[1 of 1], and it is how a resource system announces itself. A binary that
holds Music/Song and no Song128 is building filenames at run time. That is
also how its archive members are addressed — by number, with no name table
(§7). Every one of the second disc's twenty
misses was examined individually: seventeen are the extractor keeping one
non-printable byte of context (dCHR/00.PAL is CHR/00.PAL), three are
interface text containing a slash (RANKING/0, 3RD/0, 4TH/0, from the
high-score screen's labels), one is a false split.
Look at every miss one at a time. A count of misses is not a finding, and on both discs every single one dissolved on inspection. The files named by nothing are opened by names the program builds at run time or belong to the operating system.
[1 of 1] The best cross-reference result was not in an executable. It
was in a container header: the movie archive declares 136 members, holds 131,
and names five continuation files of which the disc has three. EXTRA.3 and
EXTRA.4 are named by the tool that built the archive and were never pressed.
Cross-reference containers against the file system too, not only binaries.
[2 of 2] Anything in the root that nothing references: on neither disc
a symbol file, a read-me or any source. On both, a whole operating system —
/System/, 94 files and 435,110 bytes on the first, 116 files and 487,585
bytes on the second — referenced by nothing on the disc because the console
boots from it.
[1 of 2], and it is worth a look on every disc. By late 1994 that
operating system includes a debugger (/System/Programs/GDBUG), a
filesystem administration tool with its own usage screen (lmfs, LMADM), an
EEPROM utility and a hello.rom — developer tools pressed onto a CD sold at
retail. None of them is the studio's doing: the disc builder writes /System/
wholesale. The first disc, built against the 1993 SDK, has none of the six.
[2 of 2] 16-bit pixels are 5-5-5 plus one unused bit, MSB first, not
5-6-5. Proved twice, by two independent routes, on two discs:
-
first disc: over the 76,800 pixels of a 320 × 240 image the top bit is set zero times, while the low bit of another image's words is set on 48.70 %;
-
second disc: over the 43,520 palette entries in its four
.PALfiles the top bit is set zero times, while the low bit is set on 37 %, 93 % and 53 % of the three files' words. -
fifth disc: over the 800,000 pixels of its ten 320 × 250 sixteen-bit full-screen pictures the top bit is set zero times, while the low bit is set on between 6.5 % and 61.7 % of them depending on the picture.
If the format were 5-6-5 the top bit would be red's most significant bit and
would be set constantly. Zero of 76,800 pixels, zero of 43,520 palette entries
and zero of 800,000 pixels, by three routes on three discs. [3 of 3].
[corrected] on the SEARCH and not on the conclusion, from the seventh
disc. Ten of its 60 SHPM art containers carry a palette block between the
directory and the first member, and over their 192 entries the top bit is set
64 times — 33.3333 %, on eight files of ten. So the top bit is zero on
every sixteen-bit value on a 3DO disc is now false.
The conclusion survives and gets a fourth route, because the pattern says
what the bit is. hexes.3sh's sixteen entries are one eight-step grey ramp
written twice:
0c63 1ce7 2d6b 3def 4e73 5ef7 6f7b 7fff
8c63 9ce7 ad6b bdef ce73 def7 ef7b ffff
Entry n + 8 is entry n with bit 15 set and nothing else changed, on
eight files of eight; and the two 32-entry palettes, which have no duplicated
half, set it zero times of 64. If bit 15 were red's most significant bit it
would be set on roughly half of arbitrary colours, not on exactly the second
half of a deliberately duplicated table. The bit is a flag a studio's own
blitter reads, and it is not part of the colour.
The corrected statement: the top bit is not part of the colour,
[4 of 4]by four independent routes. It is not always zero,[1 of 4], and a search that only counts it will call a flag a format.
[corrected], and the container is [2 of 2] while its contents are not.
This document expected the extensions .cel and .anim. Neither disc uses
them as this document meant. What exists is:
Crash 'n Burn .3do .3DO .img .IMG 108 files chunks: IMAG PDAT PLUT
SSF2T .CEL .cel .CE6 .BAK and cels inside .DAT, .dat and executables
chunks: CCB PLUT XTRA PDAT
The container is the same on both: char[4] id + u32 length including the header, big-endian, chaining. What differs is the descriptor chunk, and
that is the important discovery of the second disc:
IMAG an image descriptor, 28 bytes, a wrapper the program reads
CCB the Cel Control Block itself, 80 bytes -- the hardware's own structure
IMAG counts zero on the second disc and CCB counts 774; CCB at
three characters counted 57 on the first disc, indistinguishable from noise,
and IMAG counted 61. The two discs use opposite ends of the same stack:
one ships a portable descriptor and builds the control block at run time, the
other ships the control block.
[1 of 3], and the third disc is off the stack entirely.
IMAG CCB PLUT PDAT XTRA what the game's art is in
Crash 'n Burn 61 57 1,349 1,818 0 .3do/.img: IMAG + PDAT
SSF2T 0 774 770 851 643 .CEL/.DAT: CCB + PLUT + PDAT
Wolfenstein 3D 1 2 1 3 0 BRGR archives
On the third disc the only real cel chunks on the whole pressing are the two
in /3do.logo.cel; the single IMAG is four bytes inside a Cinepak frame and
the single PLUT is a constant in an ARM binary. The game's own graphics are in
an archive format the platform does not define, and inside it a cel is stored as
three words of a control block and the packed pixels, with the other sixteen
fields thrown away:
BRGR archive +0 'BRGR' +4 u32 count
+8 per member: u32 id, u32 offset, u32 length
members contiguous, first at 8 + 12 * count
-- 8 archives, 368 members, last member ends at EOF, slack 0
a member that +0 0x477EC620, then a 48-byte header whose word at +8 is 48
holds a cel +48 PIXC, PRE0, PRE1, then the packed rows
height = PRE0 bits 6..15 + 1 width = PRE1 bits 0..9 + 1
8 + 12 * count equals the first member's offset on 8 archives of 8 — the
member count encoded twice in two unrelated places — and the last member ends at
end of file on 8 of 8.
So: count cels, not files, and do not assume the platform's containers. Three discs, three answers: a portable descriptor, the hardware control block, and neither. 108 image files with 61 decodable; 31 files with 733 cels; 8 archives with 20 cels.
Chain validation still works and still pays: 107 of 108 files chain to the last byte on the first disc; on the second, 7 of the 51 cel-bearing files chain cleanly and the rest are multi-section containers where a signature scan is needed instead — and a tool that scans by signature must report how many bytes it did not account for, every time, rather than calling itself a chunk walk.
[1 of 1] The IMAG chunk:
+8 u32 width
+12 u32 height
+16 u32 bytes per row
+20 u8 bits per pixel
+21 u8 components
+22 u8 planes
+23 u8 colour space
+24 u8 compression
+25 u8 hv format
+26 u8 pixel order
+27 u8 version
[corrected], and the correction took five discs to become possible. This
document said, and meant it as a property of the chunk:
The trap stands for the
IMAGchunk: on the first discpixel ordersays LRform on 30 of 61 files and says the opposite on the other 31, and a decoder that reads it produces 31 wrong pictures. Do not trustpixel order.
That was one disc, and four discs of five since had no IMAG chunk at all
— zero on the second, one false positive inside a Cinepak frame on the third,
ANIM on the fourth and no platform container on the fifth — so the claim sat
at [1 of 1] and untestable for the length of this document's existence.
The sixth disc has 77 of them, and the trap does not fire.
Doctor Hauzer, censused by first four bytes over the whole tree
files beginning IMAG 77
parsed / refused 77 / 0
chunk chain closes to the last byte 77 of 77
bytes_per_row x height == PDAT payload 77 of 77
distinct (w, h, bpp) shapes 1 -> 320 x 240, 16 bpp
the descriptor's pixel-order byte 1 on all 77
THE ORDER AS MEASURED lrform on all 77
files where the descriptor DISAGREES 0
The order was measured the way this document settles orders — vertical
roughness against horizontal, over the whole picture, under each candidate —
before anything was rendered: gameover.img gives linear 3.2604 against lrform
0.5531, mado.img gives 10.0929 against 1.0992. Then a person looked, and
CopyRight.img de-interleaved is the title screen.
[1 of 2]: theIMAGdescriptor'spixel orderbyte lies on one disc of the two that have the chunk and tells the truth on the other, on 31 of 61 and 0 of 77 respectively. The prescription is unchanged and is now better founded: measure it. A field that is right on one disc and wrong on another is exactly a field you cannot read.
And census the chunk by its first four bytes. This disc's seventy-seventh
IMAG file is /OrgData/images/MADO3, which has no extension, and a census
by name finds 76.
[1 of 1] — four IMAG chunk types this document had never seen. Eleven of
the 77 files are 88 bytes longer than the other 66, and the 88 bytes are the
SDK image tool's metadata block, obeying the platform's chunk rule:
IMAG at 0 len 28
CPYR at 28 len 24 "No Copyright"
KWRD at 52 len 20 "No KeyWord"
CRDT at 72 len 20 "No Credit"
DESC at 92 len 24 "No Description"
PDAT at 116 len 153608
Every field holds the tool's placeholder on all eleven, and this is why
Copyright counts 28 on that pressing where it counts 2, 2, 2, 2 and 3 on the
other five. Read the context of a string count before reporting it — eleven
of the thirteen in-file occurrences are the word used as a field label whose
value is No Copyright, which is the opposite of an assertion.
The result does not stand. This document recorded every image on the first
disc is LRform as if it were a fact about the machine. The second disc has no
pixel order byte — the equivalent is PRE1 bit 11 in the CCB — and not one
of its 733 cels sets it. Decoding in plain linear order produces correct
pictures, and a person looked at one and it was the 3DO logo.
LRform is a mode, not the platform's pixel layout. One studio's art pipeline used it throughout and the other's used it nowhere. This closes open question 3, and the correct statement is:
[2 of 2]The framebuffer supports an interleaved order and a linear one. Which one a disc uses is a studio decision, it is recorded in the descriptor (IMAGpixel order, orPRE1bit 11), and on one of the two discs measured the descriptor lies. Render and look.
[2 of 2], and the second disc makes it emphatic. Cels are not files,
they are pieces inside files. 61 of the first disc's 108 image files are a
single IMAG + PDAT; the other 47 are runs of PDAT, or of PLUT PDAT
pairs, with up to 110 PDAT and 100 PLUT in one 35-kilobyte file. Those
carry no geometry, because on that disc the dimensions live in a control block
the program builds at run time — so they can be chained and counted and not
decoded, and that should be said rather than glossed.
On the second disc 733 cels live in 31 files, up to 196 in one, and they do carry their geometry, because the control block is what is stored. Two discs, two answers to can this be decoded — and the difference is entirely which chunk the studio chose to ship.
So: count cels, not files. A 3DO disc's image count is meaningless; the two discs here have 108 files against 31 and 61 decodable images against 733.
[2 of 2], and it decided something on both discs. Prove a geometry
before believing it, and finish with a person looking. On the first disc,
320 × 240 × 2 = 153,600 = the PDAT payload and
28 + 8 + 153,600 = 153,636 = the file, on 30 files of 30 — and the arithmetic
was still consistent with the wrong pixel order. Only rendering both and
looking settled it.
On the second disc the arithmetic closed on /DEM/OVERFACE.DAT to the byte,
and the picture that came out was a dithering pattern of two greys — a
darkening veil, correct and useless as a check. The check came from
/CHR/TITLE.CEL, which rendered as the 3DO logo and thereby settled the
pixel order, and from /ENDING_S/1C_NAME.DAT, which rendered as sixteen
character names and PRESENTED BY CAPCOM and thereby found the studio.
Choose what to render. A decode that is arithmetically perfect can produce an image with nothing in it to recognise. Render something that must look like something.
[1 of 2] Cels can be frames. On the second disc,
/TITLE/syukyakuDEMO.dat holds four consecutive 288 × 224 six-bit cels that
are four frames of one animation, and /TITLE/titleDEMO.dat holds 196 cels.
An attract-mode movie on this platform can be full-screen packed cels, one
per frame, in 470,960 bytes — where the other disc spent 188 megabytes and a
home-made codec. Before concluding a 3DO disc has no moving pictures, look
for a run of same-sized full-screen cels.
[2 of 2] — ALL OF IT EXISTS, and the second disc is made of it.
This line was [unverified]: coded and uncoded cels, bit depths of 1, 2, 4, 6,
8 and 16, and packed cel data, expected but not exercised by the first disc,
whose images are all 16-bit uncoded.
The second disc's 733 cels:
bits per pixel 1: 70 2: 41 4: 448 6: 171 16: 3
coded (with a PLUT) 730 of 733
packed (run-length, CCB flag bit 9) 719 of 733
16-bit direct colour 3 of 733
Four of the five sub-8-bit depths, 99.6 % coded, 98.1 % packed. The one depth still unseen is 8 bpp. Open question 4 is answered.
[1 of 1], and it CLOSES the last part of that question: eight bits per pixel
arrives on the sixth disc, and it arrives as the dominant depth.
Doctor Hauzer, censused by CCB signature with BOTH width encodings required
cels found : 1,157
width == PRE1 bits 0..9 + 1 == word 16 : 1,157 of 1,157
height == PRE0 bits 6..15 + 1 == word 17 : 1,157 of 1,157
depths : 1 bpp x1 8 bpp x729 16 bpp x427
packed (flag bit 9) : 231 of 1,157
coded (PLUT ptr set) : 0 of 1,157
by directory : /OrgData/room 1,066, /OrgData/human 48,
/OrgData/item 33, etc/menu/window 10
729 cels at 8 bpp, and every depth the platform defines has now been seen on
some disc. The six standalone .cel files decode individually and confirm it
— 3DOlogo.cel 77 × 155 at 8 bpp, NowLoading.cel 200 × 21, pen.cel
64 × 64 — so the depth is not an artefact of a signature scan.
And coded is 0 of 1,157, which is new and is not explained here. Every one
of the second disc's 733 cels carried a PLUT pointer; not one of these does,
on a disc whose commonest depth is eight bits and therefore cannot draw without
a palette. The palette is supplied by whatever draws the cel rather than
stored with it — the same division of labour this document derived for the
pixel order, arriving in a second field. Nobody has followed it further.
+0 'CCB ' +4 u32 length = 80 +8 u32 version = 0
+12 flags +16 next ptr +20 source ptr +24 PLUT ptr
+28 x +32 y
+36 hdx +40 hdy +44 vdx +48 vdy +52 hddx +56 hddy
+60 pixc +64 pre0 +68 pre1
+72 width +76 height
[1 of 1], and it is the method worth copying. Width and height are each
stored twice, in two places with different layouts:
width == pre1 bits 0..9 + 1 733 of 733
height == pre0 bits 6..15 + 1 733 of 733
Two independent encodings of one quantity agreeing on every occurrence cannot
be satisfied by a wrong field assignment, and that is a different and much
stronger kind of evidence than width × height × bpp / 8 == payload, which
closes on a subset — exactly the identity that let a bad reader miss 125 files
on the first disc. When a structure encodes something twice, check it against
itself before checking it against arithmetic.
Row stride: rowbytes = (offset + 2) × 4, where the offset field is pre1
bits 16..25 for bpp >= 8 and bits 24..31 for bpp < 8. Which one is
right was settled by closing the arithmetic on an unpacked cel — 96 pixels at
6 bpp gives 72 bytes per row, × 112 rows = 8,064 = the PDAT payload exactly —
and it holds on 13 of the 14 unpacked cels on the disc.
Packing, per row, each row starting on a 32-bit boundary:
offset field u8 when bpp < 8, u16 when bpp >= 8 = (words in this row) - 2
then MSB-first: 2 bits type, 6 bits (count - 1)
0 end of row (rest transparent) 1 literal 2 transparent 3 repeat
For a 6-bit coded cel only the low five bits index the PLUT — palettes are
32 entries — and the sixth bit selects a half of the PIXC word. A decoder that
treats it as a palette bit reads 64 entries off a 32-entry table.
The last row of a packed cel can run to the last bit of its PDAT and a
packet header that would follow is simply absent. Keep the row as far as it
decoded, count it, and say so; do not silently complete it, and still raise
on a non-final row that overruns.
[unverified], still: 8 bits per pixel, and the XTRA chunk — 643
occurrences on the second disc, always 16 bytes, always zero. A field that is
constant tells you nothing about its meaning.
[1 of 4] A fourth studio, a fourth answer to "how does a title store its
pictures". The first used IMAG, the second bare CCB , the third a BRGR
archive of headless cels, and the fourth uses ANIM — the same chunk rule
as CCB , with an eight-byte outer header and multiple frames inside one file.
The chunk rule is the platform's and it is [4 of 4]: four printable
characters, big-endian u32 length including the eight-byte header, chunks
tiling the file to its last byte.
370 containers on the fourth disc — 180 begin `ANIM`, 190 begin `CCB `
closing at residue zero : 370 of 370
chunks : 3,782, tiling 11,586,376 bytes
tags seen : ANIM CCB PLUT XTRA PDAT CTPT
The shape, derived on that disc: one CCB chunk, one optional PLUT, one
optional XTRA, then one or more PDAT, and a PDAT is a frame. 2,516
frames over 370 files, 229 of the files holding exactly one, and one file
holding 198.
All 2,516 render. That matters for a reader written on an earlier disc:
celdecode.py decodes the Nth cel of a file, a cel is a CCB chunk, and
there is exactly one per container — so on a 198-frame animation it reports
"1 of 1 cels decoded" and is not wrong, it is answering a different question.
Pair the single CCB and PLUT with each PDAT in turn. animwalk.py in
3do-adndslayer-doc does it.
[4 of 4] The CCB chunk is 80 bytes, and the two independent encodings
of width and height — word 16 against PRE1 bits 0..9, word 17 against PRE0
bits 6..15 — agree on 370 of 370 here.
[1 of 4] XTRA is 16 bytes and it is not always zero-and-absent. The
second disc had 643 occurrences, always 16 bytes, always zero; the third had
none; the fourth has 360, always 16 bytes. This does not move the [2 of 2]
on its contents, which nobody has read.
And a warning that cost the fourth session a whole premise: the extension
does not tell you which. On that disc 39 of the 219 files with a .cel,
.celA or .celB extension begin ANIM, not CCB , and ten more
containers have no extension at all — they are named 3DO Cel, Alert Cel,
Help Cel, with a space. Census by first four bytes, never by name.
[1 of 4] The ANIM chunk is 0x20 or 0x30 bytes — six 32-bit words or ten,
the longer being the shorter plus four. Words 0, 1, 4 and 5 are constant at
0, 1, 0, 0 across all 180. Word 2 equals the number of PDAT chunks on 159 of
180, and the 21 exceptions are every one of them a wall texture in one
directory with a single frame claiming five or seven. The field is described
and not named, and words 3 and 6 to 9 are printed and named by nobody. In one
file words 8 and 9 read IsWall in ASCII where they are 0x7fff7fff elsewhere,
which is what uninitialised memory looks like.
ANSWERED by the third disc. The banner screen exists, its magic is
APPSCRN, and its format is:
+0 u8 1
+1 char[7] 'APPSCRN'
+8 u32 153,600 = width x height x 2, checked against the next two fields
+12 u16 240 height
+14 u16 320 width
+16 u32 0x10000000
+20 u32 0
+24 ... 320 x 240 pixels, 16-bit 5-5-5, top bit unused (0 of 76,800 set)
+153,624 64 zero bytes
The pixel order is LRform — a 32-bit word of the buffer holds one pixel of display row 2n and one of row 2n+1 at the same column — and it was measured, not chosen: of five candidate orders rendered side by side, that one collapses the vertical roughness from 4,278,149 to 1,620,860 against a horizontal 1,437,671, a ratio of 1.13 where linear gives 2.48. Then a person looked.
Every cel on the same disc is linear. One disc, both orders, chosen per asset by whatever reads it: the ROM blits the banner straight to the display and the CEL engine draws the cels.
[2 of 2] — a second disc uses both orders, and the split is somewhere
else. The fifth disc has no banner screen and no APPSCRN, and it still
uses both:
149 camera backgrounds, 320 x 250, 8-bit paletted, in .pics LINEAR
10 full-screen pictures, 320 x 250, 16-bit 5-5-5, in .cel LRform
7 real cels, CCB -- PRE1 bit 11 is 0 on 7 of 7 linear
Measured the same way as the banner: vertical roughness against horizontal,
over each whole picture. Linear gives ratios of 2.709 to 11.510; LRform
gives 0.463 to 1.355; LRform wins on 10 of 10 and the two ranges do not
overlap. Then a person looked, and the de-interleaved players.cel is the
game's character-selection screen and inftitle.cel is its title screen.
So the rule is confirmed and sharpened. The order belongs to whatever draws the asset, and on this disc that is the framebuffer for the sixteen-bit screens and the title's own eight-bit blitter for the rooms. Two discs, two different pairs of consumers, the same rule. Neither disc's order can be guessed from its depth, its extension or its neighbours — render both and look.
And the other two discs genuinely do not have one. With the magic known the
search can be run where it could have found something: APPSCRN counts zero
over 723,112,992 bytes and zero over 356,807,808. Not found has become not
present.
What this disc's banner actually is: the SDK's untouched placeholder —
FICTIONAL DEVELOPER / presents / BOGUS TITLE, with the 3DO logo. Nobody
replaced it, on a disc sold at retail. So the asset is a slot the SDK fills
with a dummy, which is worth knowing before concluding anything from a disc
that has one.
[corrected], [2 of 2] Red Book tracks: zero on both discs. See §1.
[2 of 2] AIFF and AIFF-C. Read the COMM chunk, not the extension,
and decode the sample rate from its 80-bit IEEE extended float — it is the
field people skip.
Crash 'n Burn 12 AIFF + 5 AIFF-C all mono 407,786 bytes 9.65 s
SSF2T 1 AIFF + 63 AIFF-C 63 stereo 267,958,934 bytes 50:38.08
Wolfenstein 3D 43 AIFF + 9 AIFF-C 9 stereo 69,439,948 bytes 13:47.12
[2 of 2], and the second disc proves it a different way. SDX2 is
exactly 2:1. The first disc ships five sounds twice, as .aiff and .aifc,
at the same rate with the same frame count and exactly half the sample bytes.
The second ships no such pair, so the ratio is derived from the header instead:
for SDX2: SSND payload == frames * channels * 1 63 of 63, then 9 of 9
for PCM: SSND payload == frames * channels * 2 the control, sinewave.aiff
Derive the ratio from COMM when the disc does not hand it to you, and say
which of the two you did. [4 of 4].
[1 of 1], and it is the most useful new thing about this codec since the
rule itself. SDX2 stores one signed byte per sample per channel and
expands it to a sixteen-bit sample. Eight-bit PCM stores one byte per sample
and expands it to nothing. The two encodings cost identical bytes, and one
of them delivers eight more bits of resolution for free.
Nobody could see that on a disc with one language. The fifth disc has the same twenty recordings twice:
ENGLISH 20 files AIFF-C 44,100 Hz 16-bit SDX2 155,588,105 B 58:48.07
FRENCH 20 files AIFF 10,000 Hz 8-bit NONE 25,942,520 B 43:14.25
and the byte ratio, 5.9974 : 1, factorises exactly into the two decisions that are not the codec:
sample rate 44,100 / 10,000 = 4.4100
running time 3,528.07 / 2,594.25 s = 1.3600
------
5.9974 against a measured 5.9974
The codec's factor is 1.0000. French at 10,000 Hz with SDX2 would have occupied 25,942,500 bytes against the 25,942,520 pressed — twenty bytes' difference over twenty-five megabytes — and would have been sixteen-bit.
So, for any 3DO disc:
A file with codec
NONEat eight bits is not a saving. It is the same bytes as SDX2 at sixteen. If a disc ships both, the eight-bit half was not made smaller by dropping the codec; it was made smaller by dropping the sample rate, and the lost resolution bought nothing.
And there is a measurable trace of somebody knowing that. The fifth disc's French files are mastered 2.008 times louder than its English ones — mean RMS 0.1757 against 0.0875, a shade over six decibels — with every French file inside a band of 0.166 to 0.219 and the English spread from 0.066 to 0.110. That is what an engineer does to eight-bit audio: eight bits give 48 dB of range against sixteen bits' 96, so the signal is pushed up off the quantisation floor and normalised to a target. It does not work — it lifts the noise with the signal — and the owner of that disc, listening, described the result as "almost like a badly tuned radio" against an English recording where "you can barely hear the microphone's own noise floor."
Measure the RMS of both halves of any bilingual or dual-encoding disc, and publish it beside the rates. It is one line and it separates an encoding decision from a mastering one.
[1 of 1], and 36.97 % of a disc sat unread for want of it. The fifth
disc's music is thirty files with a .samp extension, 145,995,096 bytes, and
they have no header of any kind: no FORM, no COMM, no magic number. The
first four bytes are the first four samples. aiffread.py and sdx2dec.py
both correctly refuse every one of them, and the refusals are why nothing read
them.
A headerless SDX2 stream is testable without a header. The relative mode is a random walk and saturates on anything that is not SDX2, so the measure is the clipping rate with a control chosen inside the same object:
the thirty .samp files 0.0000 % .. 0.9542 % clipped
an imploded archive on the disc 9.2319 %
an 8-bit picture on the disc 15.9441 %
the ARM boot binary 2.4420 %
Two populations, no overlap. But the test is necessary and not sufficient, and this disc is where that bites: fifteen of the thirty files pass it at 0.9542 % and are not audio at all — they are a Macintosh's uninitialised memory (§13). The real music clips on 0.0005 %, two thousand times less. A clipping rate that is under the threshold and a thousand times the rest of the population is a thing to follow, not a pass.
And the rate is not in the file, because there is no file header. Say so in the output of whatever reads it.
[1 of 1], and it is worth checking on every disc. The third disc's 42
uncompressed sound effects have every SSND payload a multiple of 1,024, 42
of 42, totalling 501,760 = 490 x 1,024, with exactly 54 bytes of container
overhead on 42 of 42 — so 501,760 + 42 x 54 = 504,028 is the folder's byte
total to the byte. The padding is a transfer quantum, not an artistic choice.
The codec, for whoever needs to decode rather than count:
v = d × |d| × 2 with d read signed; bit 0 of d clear means the sample
is v, set means previous + v; one running predictor per channel.
Sanity check by counting clipped samples: a wrong sign or a missing doubling
saturates constantly, and a correct decode of a 30-second stereo track clips
zero of 2,646,000 samples.
[1 of 3] Sample rates are not round — sometimes. The first disc has
32,253 and 22,254 beside 22,050 and 44,100: hand-set Amiga period rates that an
80-bit float preserves and an assumption destroys. The second disc is
44,100 on 63 of 63, because it is an album rather than a sample bank. The
third is 44,100 on 9 of 9 music tracks and 11,025 on 42 of 42 effects —
every rate in the CD family, 44,100 and 44,100/4.
Decode the float; do not assume either answer. And note what the third disc's rates rule out: 11,025 is not a Macintosh rate. The Macintosh family is 22,254.5454 and its half 11,127.27, which is what the first disc's odd numbers look like. A resample destroys that evidence in both directions, so a claim of Macintosh parentage is neither corroborated nor refuted by rates.
[2 of 2] DSP instrument data ships as object code with a name in it.
/System/Audio/dsp/ holds 53 files, 46,808 bytes on the first disc and
63 files, 54,158 bytes on the second, and every one is FORM 3INS — a 3DO
instrument — with a NAME chunk carrying its own filename and a DSPP chunk
beginning DSPPDHDR. Not source.
[1 of 7], and it changes what a hash crossing between two 3DO discs
means. Six discs of seven hold the SDK's FORM 3INS bank in
/System/Audio/dsp and nowhere else. The seventh holds it twice:
/System/Audio/dsp 63 files 54,158 bytes the SDK's, as on six discs
/audio/dsp 58 files 61,696 bytes the GAME's own
names common to both : 55
byte-identical : 32 of 55
only in /audio/dsp : 3 setmem sinesamp thru
only in /System/Audio/dsp : 8
And what the 23 "different" instruments differ by is a cmp, and it is
almost nothing:
differing bytes across all 23 files : 24
22 of the 24 are the PAD byte after an odd-length DNMS chunk
2 of the 24 are one number inside a DKNB chunk, in one file
DNMS is the name-string chunk — Entry\0Ticks\0Amplitude\0 — and when
its payload has an odd length the IFF rule requires one pad byte after it. That
byte is uninitialised, and its values across the 22 are uncorrelated garbage
in both directions. Twenty-two of the twenty-three are byte-for-byte the
SDK's and were never edited: the two banks were written by two runs of the
same tool with different memory under them.
One instrument was genuinely changed, and it is one number. In
triangle.dsp, immediately before the string Amplitude:
game : 00 00 7f ff 00 00 60 00 00 00 00 01 Amplitude
SDK : 00 00 7f ff 00 00 7f ff 00 00 00 01 Amplitude
A default amplitude taken from full scale to 0x6000. That is the whole of what a studio changed in the console SDK's instrument bank, and finding it took a byte-for-byte compare and a chunk walk — not a hash census, which reports 23 files "modified".
Two consequences. First,
§13's theme reaches a third place: not mastering fill, not a leftover sector, one byte inside a good file, 22 times. Second, a hash crossing between two 3DO discs no longer implies the SDK: on the seventh disc 56 of the 57 crossings outside/Systemare the studio's own/audio/dspmatching other discs'/System/Audio/dsp. Read the path before reporting the count.
[3 of 3], and this is the platform's CD-i moment. Twenty-five files are
byte-identical across the first two discs and twenty across all three —
19 FORM 3INS instruments and sinewave.aiff, 31,186 bytes, pressed unchanged
by three studios twenty-seven months apart. Every one of the twenty is under
/system/Audio/; nothing in the kernel, the folios or the programs survived.
pairwise identical 1993-1994 25 1993-1995 22 1994-1995 36
three-way core 20 files, 31,186 bytes
collection-wide sweep 38 of my 197 = 22 + 36 - 20, and three tools agree
That answers open question 2, it took two discs where CD-i took five, and it
costs one grep. /System/ is the first thing to hash on any new 3DO disc.
The instrument bank itself grows, and on the pressing-date clock it is monotone on seven of seven: 53, 56, 63, 63, 63, 63, 77 files. The seventh disc is the fourth 63 — and its own second bank of 58 sits outside the series entirely and is not a point on it.
[1 of 3] ProTracker modules turn up on this platform, and there is no
Paula. The first disc has nine, four-channel, 31-instrument, M.K. at offset
1080, samples 90.2295 % of their bytes, played by ARM code walking the patterns
with varmono8 and mixer4x2 doing the mixing. Validate with
1084 + patterns + samples == file size; eight of nine miss by exactly +9
bytes, a tool's signature.
The second and third discs have none. M.K. counts zero on both.
Tracker music is one option on this platform, not the platform's music.
[1 of 2], and it is the personal-data lesson. Look inside the
instrument-name slots. A module's 31 instrument records are 22 bytes of free
text each and a zero-length instrument is a line of a message. On the first
disc seven of nine modules carry a conversion credit there — including the
studio's name, which occurs nowhere else on that disc as text — and five
carry a telephone number.
The second and third discs have zero contact details on either denominator, and the reason is structural rather than lucky: there are no modules, so there are no comment fields. Fifty minutes of AIFF-C, and then thirteen minutes of it plus 11.6 megabytes of Cinepak, have nowhere for a person to write. Where personal data lives on a 3DO disc depends on the music format, and that generalises off this platform.
[1 of 1], and it is where to look instead. The third disc's personal data
is in two places neither previous disc had: a credit screen drawn in pixels
inside an archive with no name table — nineteen names, findable by no string
search — and an SCCS what-string in the game's own binary carrying a build
login and hostname (§5). Grep for @(#), and decode the art.
[2 of 2] Do the duration arithmetic in the document. Rate, channels,
frames, minutes and seconds. It is what makes an audio claim checkable by
somebody without the disc — 9.65 seconds on one disc and 50:38.08 on the other,
and the second number is that disc's entire thesis.
[1 of 7], and the seventh disc is the one that chose the RATE. Six discs
argued about the codec; this one argues about the sample rate. 53 of its 54
AIFF files are 22,050 Hz — the exception is the SDK's own 44,100 Hz test tone
— and so are all 43 of its films, at 22,050 Hz stereo SDX2. One rate, one
codec, one channel count, over 177,263,598 bytes = 28.6244 % of the disc,
never varying.
The arithmetic that makes it a decision rather than an observation: 22,050 stereo SDX2 is 44,100 bytes per second against a single-speed drive's 153,600, so the sound uses 28.7 % of the drive while 43 films play at fifteen frames a second and the game loads. At 44,100 it would have used 57.4 % and the video could not have been there. This disc had 30,620 sectors free, so it was not short of space: it was short of drive.
[1 of 4], and it is the fourth disc's whole thesis. Sound on this
platform is not necessarily compressed sound. Three discs used the platform's
2:1 SDX2 codec for their music; the fourth shipped 81 AIFF files, codec
NONE on 81 of 81, 22:30.04, 67.4093 % of its pressing, of which
97.9986 % is eighteen files at 44,100 Hz sixteen-bit stereo. SDX2 would have
freed 102,379,300 bytes and taken the disc from 45.4474 % of a CD to
30.4357 %.
The control is next door and it is as close as controls get. Super Street Fighter II Turbo is 364 sectors longer, shares the SDK build to the second, and put 50:38.08 on its disc in SDX2. Capacity was not the variable; the fourth disc is 45 % full and nothing had to fit.
So: .aiff on a 3DO disc does not imply a codec, and the codec field has to
be read. aiffread.py prints it. A session that assumed SDX2 because two
earlier discs used it would have halved a 209-megabyte number.
And the extension is not the format either. 63 files in
/System/Audio/dsp carry a .dsp extension, sit one directory from the AIFF,
and are the same FORM container; they are the audio folio's DSP
instrument patches and are not audio. aiffread.py opens 144 files on that
disc and correctly refuses 63 of them with no COMM. Forty-four per cent of
what the audio reader opens on a 3DO disc may not be audio; the refusal is
the measurement.
[1 of 1], and it is new. The second disc is 86.2465 % recorded music
and puts all of it in the data track. The arithmetic that makes that a finding
rather than an observation:
50:38.08 as CD-DA = 3,038.08 x 176,400 = 535,917,868 bytes = 227,856 sectors
cross-check: 227,856 / 75 = 3,038.08 s
plus everything else on the disc, 8,355 sectors
= 236,211 sectors = 70.93 % of a 74-minute CD <- IT WOULD HAVE FITTED
So capacity is not why. What is: a single-speed drive delivers 153,600 bytes per second, PCM stereo at 44,100 needs 176,400 — 114.84 %, impossible — and SDX2 needs 88,200, which is 57.42 %. The codec is not a space optimisation; it is the difference between streaming and not streaming, and it leaves 43 % of the drive for the game's own loading. Add that the drive cannot serve a CD-DA track and read data at the same time, and a fighting game loads between every round.
Do this arithmetic on any 3DO disc whose sound is a large fraction, and publish the drive bandwidth beside the capacity, because on this platform the bandwidth is the binding constraint and the capacity is not.
[1 of 3], and the third disc has it. This document carried
there is no Data Streamer as [deleted] for two discs. FILM, STRM,
SNDS, SHDR, CTRL and MDAG occur zero times on the first disc; on the
second, only FILM occurs, once, inside the victory line
RE-DIZZY COMBO ON FILM!. On the third:
FILM 555 SNDS 253 FILL 570 SHDR 6 CTRL 4 STRM 1 MDAG 0
chance expectation for four bytes on that object: 0.0270
The prediction this document made was right: a third disc that wants interleaved video should be expected to have a Data Streamer whatever its date. The format existed all along and the first two titles had no use for it.
+0 char[4] chunk type
+4 u32 chunk size, INCLUDING these eight bytes
+8 u32 timestamp (every chunk but SHDR)
+12 u32 channel (every chunk but SHDR)
chunks end to end; the last one ends at end of file
Big-endian, and the same id + length shape as the CEL container and the
BRGR archive. 1,000 chunks and 373 chunks, both chaining to their last
byte.
[corrected], and the seventh disc is the correction: THE FIRST CHUNK IS NOT
ALWAYS SHDR, AND A STREAM CAN HAVE NO STREAM HEADER AT ALL.
FIFA International Soccer
files whose FIRST chunk is CTRL 43 of 43
top-level SHDR chunks, anywhere 0
CTRL chunks in total 43 = 43 x 24 = 1,032 bytes exactly
4354524c 00000018 00000000 00000000 53594e43 00000000
C T R L size 24 timestamp 0 channel 0 S Y N C 0
identical on 43 of 43
One CTRL chunk per film, always first, 24 bytes: the sixteen-byte chunk
header plus a payload of the four-character subscriber tag SYNC and one word
that is zero on every film. CTRL is the subscriber-control chunk this
document already derives — four of them appear inside the third disc's streams,
which have headers — and here it is instead of a header.
What that costs and what it does not. An SHDR carries the stream block
size, the subscriber tag count and the tags. Without one:
- the block size is declared nowhere and is honoured anyway. All 43 files are a whole number of 32,768 bytes with remainder zero. See the quantum section below;
- the four subscriber tags —
CTRL,FILM,SNDS,FILL— are not declared, so a player must have them already built; - the geometry is not missing, because it is one level down:
FHDRinside the firstFILMchunk carriescvid, 240, 320 and a frame count, andSHDRinside the firstSNDScarries bits, rate, channels, codec and a total sample count.SHDRthe sub-chunk is present on 43 of 43;SHDRthe stream header is present on none. The name is reused at two levels and only one of them is optional.
The information a DECODER needs is in the film; the information a MULTIPLEXER needs is in the stream header, and a disc with one film player written against its own 43 files does not need it. Nothing is missing: something was never written. The chain closes to the last byte on 43 of 43, every sector passes its EDC and both ECC parities, and every macroblock of all 19,597 frames decodes.
AND IT IS A TRAP FOR TOOLS RATHER THAN FOR READERS. Two tools in the
pipeline selected Data Streamer files by d[0:4] == b"SHDR". On this disc one
of them printed
? UNKNOWN: no format derived 401,237,223 64.7915 %
— sixty-five per cent of the object, in a table with four decimal places,
for a format this document derived on the third disc — and the other refused
all 43 files. A third tool, which looks for FILM/FHDR, read them unchanged.
Select a container by walking it, not by its first four bytes. A Data Streamer file is one whose chunk chain closes to its last byte with known tags in it, which is a measurement; it begins with
SHDRwas a habit of two discs.
On the discs that HAVE one, the first chunk is SHDR, 244 bytes, and three
of its fields are forced by measurements rather than named by hope:
+24 u32 20,480 the stream block size
+48 u32 3 the number of subscriber tags
+116 char[4] + u32, repeated: FILM 7 SNDS 10 CTRL 11
-
[1 of 3], and the sixth disc says the quantum is not 20,480 either. On the third disc both files are an exact whole number of 20,480-byte blocks — 499 and 71, remainder zero — and the fifth disc'sinterplay.logois 499 blocks with 499FILLchunks, remainder zero, a third point for the rule. Itskris.cineis 1,048,576 bytes — one mebibyte exactly — which is 51.2 blocks. It has 32FILLchunks and its last chunk is aFILLof 29,776 bytes ending on the file's last byte. So the chunks still tile the file, and the block quantum was broken to hit a round number. A one-megabyte budget beats the format's own alignment.The sixth disc declares a different quantum and honours it exactly. All eight of its films read 32,768 at
SHDR+24, not 20,480, and:EDDS 30,146,560 / 32,768 = 920 r 0 SLDS 10,551,296 / 32,768 = 322 r 0 OPDS 27,918,336 / 32,768 = 852 r 0 TRDS 8,683,520 / 32,768 = 265 r 0 MESDS 10,584,064 / 32,768 = 323 r 0 STDS 4,063,232 / 32,768 = 124 r 0 PADDS 1,146,880 / 32,768 = 35 r 0 GODS 491,520 / 32,768 = 15 r 0Eight of eight, remainder zero. So
SHDR+24 is a real field that a builder reads and honours, its value is not fixed across SDKs, and "20,480" was two discs' value mistaken for the format's. Read the field; never assume the quantum — 20,480 is 2^12 x 5 and 32,768 is 2^15, so their greatest common divisor is 4,096 and a file that is a whole number of one is almost never a whole number of the other;and the seventh disc honours 32,768 with NO FIELD TO READ IT FROM, on 43 files of 43. It has no top-level
SHDR, declares the quantum nowhere, and its 43 films are every one a whole number of 32,768 bytes with remainder zero. The total, 392,298,496, is 32,768 x 11,972 and in fact 131,072 x 2,993, so the greatest common divisor of the 43 sizes is at least 2^17. The quantum is a property of the SDK drop and of whatever multiplexed the stream, not of the file — the field records it where a field exists, and where none does the value is the same anyway.[2 of 3]on 32,768, three value-bearing discs; -
SHDR244 + theFILLchunk that follows it, 20,236, = 20,480 exactly, on 2 of 2; -
the tag count equals the number of tags, on 2 of 2;
-
one
FILLchunk per stream block, padding each to the drive's read quantum.
What makes it interleaved is the word at +8: it rises monotonically and never falls, across both chunk types, in both files. Video and audio for one moment sit next to each other on the disc.
And the clock is derivable without anything declaring it. One audio chunk of
20,448 bytes at 22,050 Hz stereo 8-bit is 0.463673 s and spans 111 ticks, so the
stream clock is 240 ticks per second; a video frame spans 24 ticks on one
file and 20 on the other, so the two films run at exactly 10 and 12 frames per
second. The field at FHDR +36 reads 30 on one file and 0xDBED8C00 on the
other and is not the frame rate.
[3 of 3] on the clock, and the seventh disc checks it against a quantity
with no clock in it. Its 43 films give 16 ticks between consecutive video
frames on 19,554 steps of 19,554 — 240 / 16 = 15.0000 frames per second,
uniform across 63 % of a disc. And SDX2 stores one byte per sample per channel,
so its 58,188,632 sound bytes are 58,188,632 / 2 / 22,050 = 1,319.47 seconds
with the stream clock not involved at all, against 1,312.30 seconds from the
timestamps — the two agree to 0.5434 %. Two derivations sharing no field is
what makes 240 a measurement rather than a convention.
And FHDR +36 reads 30 on 43 of 43 while the true rate is 15, which is
exactly double. A field that is a round number and twice the answer is the
most believable wrong field there is, and it would have been believed on any
disc read alone.
FILM +16 'FHDR' +20 u32 0 +24 char[4] compression +28 u32 height
+32 u32 width +36 u32 (not derived) +40 u32 frame count
FILM +16 'FRME' +20 u32 duration +24, +28 lengths
+32 u16 width, u16 height, u16 strips +44 the codec payload
SNDS +16 'SHDR' +40 u32 bits +44 u32 rate +48 u32 channels
+52 char[4] compression +60 u32 total sample bytes
SNDS +16 'SSMP' +20 u32 length +24 the samples
The sample byte count is a quantity encoded twice, [3 of 3]: SHDR
declares 1,799,872 and 641,024 on the third disc and the SSMP payloads
concatenate to the same; on the sixth disc it holds on 8 of 8 films with
difference zero, and it is what caught that disc's one defective film before
the walk did.
[2 of 3], and the seventh disc is a point the OTHER way, so the mark needs
both discs and neither alone.
FIFA International Soccer
FHDR declared frames 19,613
FRME chunks measured 19,597
declared == measured 42 of 43
Forty-two of 43 agree exactly, where the sixth disc agreed on four of seven. And the one exception goes the other way and is the second-shortest film, not the longest:
stream.attack, 1,703,936 bytes
FHDR declares 100 frames 100 at 15 fps = 6.67 s
FRME measured 84 frames 84 at 15 fps = 5.60 s
its SDX2 sound runs 6.60 s
The declared count matches the SOUND and the multiplexed video is sixteen frames short of it. So the field is not right on short films and low on long ones: it is what the film was authored to be, and it disagrees wherever a track was cut after the header was written. Both discs' behaviour follows from that reading and neither follows from the other's. Described, not named.
[corrected] — the FRAME count is NOT encoded twice, and the sixth disc
breaks it. This document said FHDR declares 409 and 141, and the files hold
exactly 409 and 141 FRME chunks, at [2 of 2].
Doctor Hauzer FHDR declares FRME measured
EDDS 313 2,149
OPDS 767 2,594
MESDS 525 848
GODS 131 131 equal
SLDS 585 585 equal
STDS 330 330 equal
PADDS 11 11 equal
Four of seven equal and three not, and the three that disagree are the three
longest films. [2 of 3]. The field is described and not named: it is right
on short films and low on long ones, and a reader that trusts it will stop
early on exactly the files worth walking.
[1 of 1] — a Data Streamer file can carry a bare tag with no length field,
and it is a defect on the pressing. /OrgData/stream/TRDS holds, at offset
7,995,388:
46 49 4c 4c | 46 49 4c 4d | 00 00 0f 78
F I L L F I L M
A FILL tag immediately followed by the FILM tag of the next chunk, with no
length between them. A walker stops there and reports 688,132 bytes it cannot
explain; stepping four bytes chains 104 more chunks to the file's last byte
exactly. Every sector of the file passes its own EDC and both ECC parities, so
the four bytes were written that way by whatever multiplexed the stream.
Report the resync, never perform it silently. A tool that repairs a stream without saying so converts a defect on a retail pressing into a clean number, and the number is then wrong about the object rather than about the reader.
[corrected] — and this is the worst kind of mistake this document has
made. It said:
Cinepak is not there either.
Cinepak0,CVID0,MPEG0,Indeo0, on both discs.
The compression type in FHDR is four lower-case characters and it reads
cvid. CVID in upper case is still zero on all three discs; cvid counts
2 on the third, one per stream, at a fixed offset in a chunk whose height,
width and frame count all check out against independent measurements. Cinepak
as a word appears nowhere on any of the three discs, because the codec is named
by its FourCC and by nothing else.
A [deleted] mark produced by a search that could not have found the thing is
worse than no mark, and this one stood for fourteen months. Search
case-insensitively, or search every case.
The payload is standard Cinepak and this document says so: strips of
u16 id, u16 size, u16 y0, x0, y1, x1 with the rectangle relative to the
previous strip, and inside each strip four-byte sub-chunk headers whose size
includes the header — settled by walking both readings over every strip:
818 of 818 chain to the last byte one way and 0 of 818 the other. Two strips
of 100 rows per frame, summing to the declared height on 409 of 409, every
macroblock accounted for on 550 frames of 550.
[1 of 1], and it is a correction owed backwards to three discs. The
seventh disc's 43 films were decoded frame by frame — 19,597 of them — and the
census this document prescribes passed:
strip heights sum to the height FHDR declares 43 of 43 films
chunk chain closes to the last byte 43 of 43
coded + skipped == macroblocks, every frame 19,597 of 19,597
frames with a sub-chunk overrun 0
That output is byte-for-byte identical before and after a defect that made
every inter-coded frame wrong. The decoder built fresh Cinepak codebooks on
every frame. Cinepak's 0x2100 and 0x2300 sub-chunks are sparse codebook
updates — a 32-bit mask per group of 32 entries, rewriting only the entries
whose bit is set and expecting every other entry to be the one it had. Reset
the book and those entries read [0,0,0,0,0,0], which decodes to black.
- intra frames — full codebook, all vectors coded — came out perfect;
- inter frames came out correct wherever a block happened to reference an entry the update rewrote, and black in isolated 4 x 4 squares everywhere else.
Every check in this document is a check on bookkeeping and every one of them closes either way, because every block is still decoded. It is decoded from the wrong entry.
stream.1966Ger1 before ~33-65 % near-black per frame after 0.70 % over 465
all 43 films, 19,597 frames after 3.8719 %
What caught it was a person looking at 43 contact sheets. No two tools disagreed, because both were the same tool.
When a container encodes STATE that persists between records — a codebook, a predictor, a running palette — a per-record census cannot check it. Every bookkeeping identity closes on a wrong state exactly as well as on a right one. Render, and put it in front of somebody.
The debt. That decoder produced the third disc's 550 frames, the fifth disc's shared logo film and the sixth disc's eight. No published finding in any of those repositories depends on a decoded pixel value — the claims are about frame counts, macroblock accounting, chunk chains and payload identity, and all of those close identically either way — so nothing published is wrong, and every picture rendered from those discs was. Their contact sheets should be re-rendered and have not been.
[1 of 3] MPEG is not the title's. It counts 10 on the third disc and
all ten are inside /system/Devices/FMVVIDEODEVICE.PRIVDEVICE, the driver
for the console's optional MPEG cartridge, which the SDK ships whether or not a
title uses it. Ten against 0.0270 is an overwhelming signal about the SDK and
says nothing about the video.
[corrected] — and this is the correction that matters most. This document
explained the absence like this:
The first disc is from the console's launch day, and the Data Streamer and the Cinepak decoder belong to a later SDK than the one it was built against.
That explanation was wrong and the third disc proved the replacement right. The replacement, written after the second disc:
Neither disc needed a general interleaved stream container. One wrote its own codec because it was showing footage the platform could not decode; the other has no footage at all… Absence of a format is a fact about what the title is doing, not about the toolchain's calendar. A third disc that wants interleaved video should be expected to have a Data Streamer whatever its date.
[verified]. The third disc wants interleaved video and has the Data
Streamer, in an SDK five months newer than the second disc's. The format did not
arrive; the need did.
Four discs, four ways of putting moving pictures on a 3DO — and three that repeat one of them:
FIFA Int. Soccer the Data Streamer with Cinepak, 392.3 MB, 63.3481 %
Crash 'n Burn a home-made codec in a home-made archive, 188 MB, 33.50 %
SSF2T full-screen packed cels, one per frame, 470,960 bytes
Wolfenstein 3D the platform's own Data Streamer with Cinepak, 11.6 MB, 10.05 %
Slayer ANIM containers, 2,516 frames
Alone in the Dark the Data Streamer with Cinepak, 11.3 MB, 2.8536 %
Doctor Hauzer the Data Streamer with Cinepak, 93.6 MB, 35.6165 %
[1 of 7] on the fraction, and the spread is two orders of magnitude:
63.35 %, 35.62 %, 33.50 %, 10.05 %, 2.85 %, 0 %, 0 %. The two discs that use
the format hardest are the two fullest, and four of seven put no moving
pictures on themselves at all — two of those four using less than half a CD.
So the CD-ROM was not for video on this platform: the video went in where
there was a reason and room, and on the seventh disc the reason was a licence.
[1 of 1], and it is a method rather than a fact about one film. The fifth
disc's /interplay.logo and the third disc's /Movies/Logo.Cine are
10,219,520 bytes each, to the byte, both 409 Cinepak frames at 320 × 200,
both declaring 1,799,872 bytes of 22,050 Hz eight-bit stereo sound. Their
SHA-1s differ, so a hash census across 84 repositories finds nothing.
Compared payload by payload:
FILM chunks 410 and 410, identical sizes on 410 of 410
FILM payloads byte-identical on 410 of 410
SNDS payloads byte-identical on 90 of 90
bytes differing 10,642 = 0.1041 %, all of it padding
the difference one extra CTRL chunk on the fifth disc, and the FILL
around it
One publisher's logo film, pressed on two 3DO discs fourteen months apart by two unrelated developers, remultiplexed rather than re-encoded. §12 already argues that a file-level hash list cannot answer is this the same movie. This is the same argument one level deeper: a member list would not have found it either, because the members are identical and it is the container's framing that differs. Strip the eight-byte tag and length and the eight bytes of timestamp and channel, and compare what is left.
A shared asset survives remultiplexing and does not survive a hash. Add a payload-level comparison to the list in §12.
Do not conclude anything about a 3DO disc's moving pictures from the absence
of a container. Look for a run of same-sized full-screen cels, for a
studio-written archive, and for SHDR — in that order of cheapness.
[1 of 1] And the disc is still a third video. 188 megabytes of it, in
a container the studio wrote itself, named bigfile in the executable and
opened by FMV_Open, FMV_DecompressFrame, FMV_Close, StartMovie,
StopMovie, ServiceMovie and FMV's CCB buffer. Do not infer the absence
of content from the absence of a format. On a launch title the studio writes
its own.
What was derived of it, so a second disc starts further along:
archive +0 u32 total members, this file and its named continuations
+4 u32[12] 0 / 0x80000000 alternating
+52 (u32 length, u32 offset) per member
+... u32 length of the name table, then char[8] names
members are contiguous and 2,048-aligned
member +0 u32 type: 0 is video, 4 is something else
+4 u32 block width 4
+8 u32 block height 4
+12 u32 dictionary size in blocks
+16 u32 bytes per pixel 2
then a 16-bit stream:
0xFFFF <u16 id> <32 bytes> define dictionary entry
0x0000 / 0xFFFD codes, meaning not derived
else <u16 id> draw that entry in this cell
cells raster-scan a grid given once as (1, 32, 24)
the 32 bytes are sixteen 5-5-5 pixels in a BOUSTROPHEDON:
row 0 left to right, row 1 right to left, and so on
[1 of 1] Validate a container by chaining it, and this platform
rewards it: on the first disc the grammar above consumes 76 of 76 video
members to their last byte, and 32 is the only definition payload length in
24..64 for which any member parses at all. The archive's own arithmetic closes
too — the last member's end rounds up to exactly the file's length.
[1 of 1] How much of a disc is stream? On the first disc: 131 members
plus 3 continuation files, 210,914,892 bytes, 33.50 % of the pressing. Of
that, 65,709,328 bytes are proved to be 7,239 frames of 128 × 96 video and
145,083,544 bytes are of undetermined kind. The recorded fraction is published
as a band, 10.73 %–33.77 %, rather than as a number.
[1 of 3] On the second disc: zero. No archive, no members, no video.
The moving pictures are cels (§7) and the sound is 63 separate AIFF-C files read
through the audio folio. On the third: 10.0526 %, two files, 550 frames of
Cinepak at 320 x 200 and 280 x 200, and 55.35 seconds of 22,050 Hz stereo PCM
interleaved with them — all of it derived and every frame decoded, which is
the first time this branch has fully accounted for a 3DO disc's video.
[2 of 2], and it is how to close a disc honestly. Publish the fraction
of the user area whose format you actually derived, in a table that must sum
to the user area:
Crash 'n Burn about 77 % identified, ~23 % of undetermined kind
SSF2T 87.3403 % identified, 4.4169 % in a file with no format
derived, 8.2428 % not in any file
Wolfenstein 3D 71.1132 % identified, 4.2619 % in a file with no format
derived, 24.6250 % not in any file
The third number went down and that is the honest direction: a quarter of
that disc is mastering fill, and 3.02 % of it is archive members whose own
format was not derived. /Levels/ is 0.94 % of the pressing whose index is
airtight and whose contents are not known, and it is counted as unknown.
A sector map that closes says every sector belongs to a file. It does not say
anybody knows what the file is. Two different numbers, both worth printing,
and the second is the one that says how much of the day's work was real. A
name is not a format: on the second disc, .CHR is 2.58 % of the pressing
whose index is derived and whose leaves are not, and it is counted as unknown.
| Disc | Year | Studio | Tracks † | Data track | Files | Dirs | Copies ‡ | FS † | Stream % | Fill ‡ | Compression | Red Book † | Recorded | Image | Cels | Binaries | Identified |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Crash 'n Burn | 1993 | Crystal Dynamics | 1 | 307,446 sectors, 92.33 % | 451 | 38 | 0.0319 % | Opera | 33.50 % | 11.59 % | 4 of 34, all OS | 0 | 0.3230 % | IMAG |
0 | 34 | ~77 % |
| SSF2T | 1994 | Capcom | 1 | 151,704 sectors, 45.56 % | 373 | 26 | 0.0501 % | Opera | 0 % | 7.93 % | 5 of 93, all OS | 0 | 86.2465 % | CCB |
733 | 93 | 87.34 % |
| Wolfenstein 3D | 1995 | Logicware / Interplay | 1 | 56,702 sectors, 17.03 % | 197 | 22 | 0.1023 % | Opera | 10.05 % | 23.60 % | 20 of 37, all OS | 0 | 59.7896 % | BRGR |
20 | 37 | 71.11 % |
| Slayer | 1994 | Lion / SSI | 1 | 151,340 sectors, 45.45 % | 582 | 24 | 0.0297 % | Opera | 0 % | 11.71 % | 5 of 41, all OS | 0 | 67.4093 % | ANIM |
2,516 | 41 | 87.6184 % |
| Alone in the Dark | 1994 | Krisalis / Infogrames | 1 | 192,811 sectors, 57.90 % | 251 | 14 | 0.0342 % | Opera | 2.85 % | 0.00 % | 5 of 41, all OS | 0 | 77.1890 % | none of them | 7 | 41 | 90.79 % |
| Doctor Hauzer | 1994 | Riverhill Soft | 1 | 128,300 sectors, 38.53 % | 366 | 32 | 34.2712 % | Opera | 35.62 % | 3.82 % | 4 of 36, all OS | 0 | 25.7313 % | IMAG+CCB +ANIM |
1,157 | 36 | 95.39 % ‡‡ |
| FIFA Int. Soccer | 1994 | Electronic Arts Canada | 1 | 302,380 sectors, 90.80 % | 395 | 21 | 0.0007 % | Opera | 63.3481 % | 15.55 % | 5 of 41, all OS | 0 | 28.6244 % | SHPM, and 0xC0FB |
0 | 41 | 82.7447 % |
Eighteen columns and seven rows.
The seventh row is where the Stream % column stops being a curiosity. Its
seven values are 63.35 %, 35.62 %, 33.50 %, 10.05 %, 2.85 %, 0 % and 0 % — two
orders of magnitude, no clustering, and the two highest are the two fullest
discs. It is now the second-best separating column in the table after
Recorded.
And Cels reads 0 on a disc that is not short of art. FIFA has 3,891
SHPM members and 349 0xC0FB members and not one platform cel, so the
column measures use of the platform's graphics stack rather than how much
art a disc has — which was already half-true of the fifth disc and is now
unambiguous. Two discs of seven use none of the platform's containers.
Eighteen columns and six rows. The fifth row is where two of them stop meaning what they meant, and the sixth is where a deleted column comes back.
-
Copies‡ was DELETED after three discs on the grounds that 0.0319 %, 0.0501 % and 0.1023 % was one behaviour seen through three denominators. The sixth disc's value is 34.2712 % and the column is restored, with the deletion left visible: three points that agree are not a rule, and a column that fails to separate five discs can still separate the sixth. That is the same mistake as promoting a mark for silence, made in a table instead of in a paragraph; -
‡‡
Identifiedon the sixth row is not comparable with the other five without saying which denominator it uses. Counting every sector of every file whose format is derived — which is what the other five rows measure, on discs where the copies were 0.03 % — it is 95.3886 %. Counting distinct bytes only it is 61.1173 %. The two differ by 34 points and both are in that disc's chapter 15. On any disc with aCopiesvalue above a per cent, print both. -
Fillwas promoted to a finding after three discs on the strength of an arithmetic that closed to the sector. The fifth disc's value is 0.00 %, and the arithmetic cannot be run at all. The column stays and the finding is now conditional: when a 3DO disc has fill, the fill is the complement of the sectors the file system uses. Some discs have none; -
Image— what the game's own graphics are in — has now been answeredIMAG, bareCCB, aBRGRarchive,ANIM, and none of the above: the fifth disc's 149 room backgrounds are a raw 320 × 250 eight-bit raster in a 40-sector block with a VGA palette, and its ten full-screen pictures are a raw 320 × 250 sixteen-bit raster with no header. Five discs, five answers, and one of the answers is that the studio used no platform container at all. There is still no reason to think the list is closed; -
Identifiedat 90.79 % is the highest in the collection, and 6.18 points of it are another computer's memory whose kind is derived but which is not the game's data. The honest reading for comparison with the other four rows is 84.60 %, and both numbers are in that disc's chapter 01.
Three columns are deleted. With two discs this document kept four that had failed to separate anything, on the grounds that a column which fails to separate two discs has not been shown to separate none. Three discs is enough:
Tracks† — deleted. 1, 1, 1. Every 3DO disc has one data track and this is now an identity check rather than a column;Red Book† — deleted as a column and promoted to a finding. 0, 0, 0, and the third disc is the one that makes the zero mean something: it uses 17 % of a CD and would have needed 21 % with its music as CD-DA, so capacity was never the constraint on any of them. See §8;Copies‡ — deleted. 0.0319 %, 0.0501 %, 0.1023 % is 2.58, 2.62, 2.52 blocks per directory group. Three points and the trend is flat while the fraction triples. It is the denominator, three times.
FS stays as an identity check, marked, because it is what tells you the
disc is a 3DO disc at all.
Fill stays and is now a finding rather than a warning, because §4 turned
it into an arithmetic that closes to the sector.
The columns that earn their place, after three discs: Recorded (0.32 %,
86.25 %, 59.79 % — two orders of magnitude across three consecutive objects),
Data track (92.33 %, 45.56 %, 17.03 % — halving each time and predicting most
of the others), Stream %, Image, Cels and Identified. Six columns, and
the three deletions cost nothing.
One column would have been worth having from the start: what the game's own
graphics are in, which is IMAG, then CCB , then an archive the platform
does not define. The Image column answers it by accident and only because
the first two discs happened to use platform containers.
[corrected] The original order was a proposal. This is what the first disc
actually rewarded, with the two changes that matter marked.
- Read the CHD or cue by hand first. Track count, type, length, and the fraction of a 74-minute CD. Fifteen lines, no tools.
- Sector 0. The label, the block size, the block count, the root's copy list. If this does not parse, stop.
- Write the directory reader, and write its negative control first. Two blocks that are not directories must be rejected before anything is censused. ← moved up from step 6. On the first disc this is what turned a catastrophic misreading into a ninety-second bug.
- Walk the tree, and check that the block accounting closes to the sector
before believing the file count.
ceil(byte_count/2048) == block_countis not enough: it holds on a subset. What does not hold on a subset is every sector attributed exactly once, totalling the sector count. ← new step, and the one this platform most needs. - Compare the copies. One pass, and on the first disc the best structural finding on it.
- Extract, hash, entropy. In that order, because none of them means anything before step 4 closes.
- Strings over the pressing, with chance expectations printed, case-folded, and with the file tree as a second denominator rather than the only one.
- The executables: AIF header, sizes, entry point, relocation target. Do not disassemble before the address model is proved.
- Both directions of the filename cross-reference, case-folded, and look at every miss individually.
- Prove one geometry end to end and look at the picture. Do not trust
pixel order. - Chain one container end to end, and require the last chunk to end at end-of-file.
- Publish
notes/sha1-all.txt, hash first, plus a per-member list for any archive, a per-copy list from the directory records, and a per-cel list if the disc has cels (§12). - Fill in one row of §10 and re-mark every claim in this document the disc exercised.
Three steps the second disc added, and where they go:
- after step 5, hash
/System/against every previous disc. It is one command and on the second disc it produced 25 byte-identical files, 67 changed and 24 added — a version diff of the SDK, which dates the pressing on a file system that has no dates. This is now the highest-value single check on the platform, and it gets cheaper with every disc; - after step 10, account for every byte by KIND, not by owner. The sector map says every sector belongs to a file; it does not say what the file is. Publish a second table that sums to the user area and puts every byte in exactly one bucket, with format not derived as an honest bucket. Second disc: 87.34 % identified, 4.42 % in a file with no derived format, 8.24 % not in a file;
- and before step 13, ask of every mark you are about to promote: did this
disc EXERCISE it? Two discs make everything look confirmed and three make it
worse. The third disc broke six
[2 of 2]claims, every one of which had gone uncontradicted for fourteen months, and it exercised barely half the document.
Four steps the fifth disc added, and the first of them goes at the very top:
- before step 1, count
iamaduckover the whole user area. One command, sequentially, over the extracted track. Zero is a finding: it means the disc is publishing whatever its master was written over, and it changes what every later step is for. One disc of five; - after step 5, compare
/Disc label's two copies as well as the directories'. On a disc with fill they are identical past byte 132; on a disc without one they differ in 1,905 of 2,048 bytes, at block 0, long before anything else says so; - after step 6, census every file for FOREIGN instruction pairs. 68000
LINK A6/UNLK A6, x86PUSH BP;MOV BP,SP, against the ARM0xEshare as a control, with a printable-share guard. A hash census cannot see another computer's memory inside a good file, and on the fifth disc there are 24 megabytes of it. §13; - and when a container is shared with another disc, compare PAYLOADS and not files. The fifth disc's logo film is byte-identical with the third disc's in all 410 video payloads and all 90 sound payloads, and their SHA-1s differ because one has an extra control chunk. §9.
Four steps the sixth disc added, and the first of them is free:
- before anything, set
PYTHONIOENCODING=utf-8. The first disc of this platform with non-ASCII filenames broke two tools' output and left one of them writing a truncated hash list with no error a caller notices. Then check the record count against the file count before any generated list is consumed by anything; - after step 5, hash every copy of every FILE, not only of every directory. On five discs that is two files and costs nothing; on the sixth it is eighty files, ninety megabytes and the object's whole subject. And when a disc does duplicate content, sort every copy of every file by block address and join the runs: the unit of duplication may not be the file at all. §3;
- after step 10, measure the pixel order before rendering, and render
anyway. The
IMAGdescriptor lies on one disc of two. Vertical roughness against horizontal picks the order without a reference picture, and then a person has to look at something that must look like something — on the sixth disc that was the title screen, which also settled the copyright, the publisher, a second company and the epoch; - and when a chunk walk stops early, look at the four bytes where it
stopped. The sixth disc's largest unexplained region — 688,132 bytes — was a
FILLtag with no length field, and four bytes of resync turned 3.30 % of the user area from unknown into derived. Report the resync in the output.
Four steps the seventh disc added, and the first of them is the one this document most needed:
- after step 10, RENDER, and put the picture in front of a person — even when the census closes. A Cinepak decoder that rebuilds its codebooks every frame passes strips sum to the declared height, chain closes to the last byte and coded + skipped == macroblocks on every frame, and produces pictures peppered with black. When a format carries state between records, no per-record census can check it. §9;
- before step 4, select a container by WALKING it, not by its first four
bytes. Two tools selected Data Streamer files on
SHDRand one of them reported 64.7915 % of a disc as no format derived, in a table with four decimal places, for a format this document derives. A tool that is right about its own test and wrong about the object says nothing about the disagreement; - after step 7, locate every occurrence of a magic number before concluding
anything from its count.
SHPMcounts 387 on the seventh disc against 60 files beginning with it, and 312 of the 387 are in the clear inside twelve files an external reference called compressed — which is what refuted the external reference. The same pass showedCCBcounting 6 with three of them the stringCCB Managerinside two ARM binaries on a disc with zero cel control blocks; - and when a disc could not have done the thing, do not count it as having declined to. The seventh disc's sound would not have fitted as CD-DA, so it is the first of seven that cannot testify about the Red Book question rather than the first that refutes it. A claim about a choice needs discs that had the choice. §1, §8.
Three more steps the third disc added:
- after step 7, search every string case-insensitively, or search every
case. A
[deleted]mark in §9 stood for fourteen months becauseCVIDwas searched and the field sayscvid. A search that could not have found the thing is worse than no search, and this is the cheapest possible guard; - after step 8, decide compression structurally and never by a size relation. §5. A test that has never been contradicted has never been tested;
- before step 13, run the previous discs' searches again with anything the new
disc taught you.
APPSCRNwas an open question for two discs and closed in one command once the magic was known — not found became not present on a search that could have found it.
[2 of 2] Every disc repository publishes notes/sha1-all.txt: one record
per file, with path, size and SHA-1. 451 records on the first disc, 373 on the
second.
[corrected] — and the omission cost a run. This document did not say in
what order the columns go, and the collection's cross-referencing tools
require the SHA-1 first:
<40 hex digits> <size> <path>
Writing it as path, size, hash makes crossall.py report
my distinct sha1: 0 and CROSSINGS: 0 of my 0 — a clean, confident,
completely empty answer. It was caught only because the expected answer was
not zero. A tool that finds nothing is not a tool that says zero, and a
format ambiguity in this document is what produced the silent one.
[2 of 2] A file-level list is not enough on this platform either, and it
needs two companions rather than one:
notes/bigfile.txtor equivalent — one record per member of any archive, with offset, length and type word. The first disc's movie archive is 33.5 % of the pressing in a single file, and is this the same movie is a member-level question;notes/copies.txt— one record per copy the directory declares, with a hash each. This costs nothing on this format because the copies are declared, and on the first disc it is how the two disagreements were found and on the second how the signing pass was;notes/ccb-list.txtor equivalent — one record per cel, with the file, the offset, width, height, depth and the packed and LRform flags. The second disc has 733 cels in 31 files and is this the same sprite is a cel-level question, exactly as is this the same movie was a member-level one. A file-level list cannot answer either;- and a per-member list for any archive that is not a movie archive. The
third disc's eight
BRGRfiles hold 368 members, of which the ninety maps and the credit screens are individually interesting and none of which has a name. One record per member — id, offset, length, first four bytes, hash — is what makes is this the same level answerable.
[1 of 1] Hash the right bytes: a decoded frame against a raw region reports
a new recording for ever.
[1 of 1], and it is the fifth disc's addition: a hash list of any kind can
miss a shared asset entirely. Two 3DO discs carry the same 409-frame Cinepak
film, byte-identical in 410 of 410 video payloads and 90 of 90 sound
payloads, and their file hashes differ because one has an extra four-byte
control chunk and the padding moved. A per-member list would have missed it
too, because the members are the same and it is the container's framing that
differs. When a container is shared across discs, publish a per-chunk list of
PAYLOAD hashes — the bytes after the tag, the length and the timestamp — and
not of chunks.
[1 of 1], and the seventh disc adds a fourth companion list. Publish
notes/copies.txt with EVERY copy of every directory AND every file, not
only the ones that disagree. On the seventh disc that is 467 records — 7
root copies, 21 directories x 3, 395 files and 2 specials — and it is what
makes which copy did the extractor read answerable afterwards. It has to be,
because the seventh disc's CPORT49.ROM is 1,332 bytes by copy 0 and 1,400 by
copies 1 and 2, and a comparison against another disc that reads different
copies compares two different things. Hash the whole BLOCK range, not
byte_count, precisely because the two lengths disagree.
[1 of 1] And publish notes/pak-members.txt or its equivalent for any
archive whose members have no names, with offset, length, type and a hash each.
The fifth disc's twenty archives hold 2,072 nameless members and is this the
same floor is a member-level question.
[1 of 5], and this section exists because the fifth disc is the first that
could have written it. Four discs of four filled every unwritten block with
iamaduck and closed their sector maps at zero. The fifth wrote no fill at
all, and the result is that 58,547,244 bytes — 14.8267 % of a retail
CD-ROM — are the contents of two other computers.
Both are recoverable with two tools and neither needed a guess.
Sectors 176,147..192,810 — 16,664 sectors, 34,127,872 bytes, 8.6427 % of the
user area — belong to no file. They hold Watcom C/C++ Version 10.0: the
compiler, its linker, its debugger, its manuals, its libraries, the DOS/4GW
extender (Rational Systems, 1990-1994), Phar Lap's 386|DOS-Extender, IBM's SOM
toolkit (SOMLINK 5,014, .IDL 169 distinct names, .XH 133), and 2,894
distinct filename tokens.
Two questions have to be settled in this order, and both are settleable.
One — pressing or dump? Settle it at the sector, never at the content. A
MODE1_RAW sector carries a twelve-byte sync pattern, a header whose first
three bytes are its own address, a CRC-32 EDC over bytes 0..2,063 and two
interleaved Reed-Solomon parity blocks. Over the fifth disc's whole track:
sync correct 192,811 / 192,811
header MSF == LBA + 150 192,811 / 192,811, zero non-BCD
EDC mismatches 0 / 192,811
ECC P and Q mismatches 0 each
reserved field non-zero 0 / 192,811
Not one sector fails, the 16,664 included. A dumper that padded a short read gives zeros with no parity; injected data would need a regenerated CRC-32 and two Reed-Solomon codes per sector. It is on the pressing.
Two — one object or a heap? Measure whether the sector boundaries are visible to the content. Count how often a printable run of six or more characters spans a block join, against how often it spans an arbitrary interior offset of the same blocks — the interior rate is the control and it is taken from the same bytes:
runs spanning the join 3,449 of 16,663 = 0.2070
runs spanning four interior offsets mean 0.2100
ratio 0.9856
0.9856: the joins are invisible. One contiguous object, read straight through, in runs of up to 679 consecutive blocks of one kind. The image was laid over a medium that already held a Watcom installation, the builder wrote 176,147 sectors and stopped, and the tail was pressed.
This is the harder one and no sector map will find it. The bytes are inside files the file system accounts for and that hash cleanly. On the fifth disc:
- one 1,515,520-byte block pressed sixteen times — 24,248,320 bytes, 5.7570 % of the pressing — under fifteen filenames the game builds by concatenation plus one more. No second music variant was ever recorded and the build wrote the buffer out anyway;
- the 1,148-byte tail of every one of 149 camera-background blocks, 171,052 bytes, where each picture rounds up to forty sectors.
The test is instruction pairs that a real program emits in matched
quantities, against the console's own architecture as a control. 68000 LINK A6 (0x4E56) opens a stack frame and UNLK A6 (0x4E5E) closes it:
LINK UNLK balance MPW strings verdict
the sixteen copies 367 365 0.997 49 68000 + MPW
the PC region 531 35 0.124 4 x86
Balance 0.997 against 0.124. And the instructions read: 4e56 fffc 48e7 0118 is LINK A6,#-4; MOVEM.L D7/A3/A4,-(SP), a 68000 prologue.
A guard this needs, learned the hard way. 0x4E, 0x56 and 0x5E are the
ASCII letters N, V and ^, so a file that is mostly printable bytes
produces LINK/UNLK pairs by accident. A 320 × 250 sixteen-bit picture on
the same disc — 74.71 % printable — scored LINK 357, UNLK 410, balance 0.931
and was reported as 68000 until a printable-share guard was added. Require
the data not to be text-shaped and require MOVEM or JSR to corroborate.
The strings say what was running: {ShellDirectory}, MPW.Errors,
Dev:StdOut, _xflsbuf, _filbuf,
_Static_Constructor_Destructor_Pointers, Monaco, Find what?,
ExtendWordSet, SADE, /<CODE, /<DLOG — the Macintosh Programmer's
Workshop, which is what 3DO development was hosted on.
And Macintosh paths are findable because no other system writes
Volume:Folder:File. Twenty-five distinct ones reconstruct the build
machine:
KeithsIntHD:MPW Folder:Worksheet
KeithsIntHD:Alone:game:sources: :PALSource: :EngDemo:
KeithsIntHD:Alone:game:JapSources: :JapDemo:
KeithsIntHD:Alone:lib:lib_256: :lib_jeu: :lib_3d:
KeithsIntHD:ALONE:GAME:SOUND:SAMPLES:rawsamples:s12.VOC
KeithsIntHD:3DO:Interfaces:1p1:Includes: :Libs:
KeithsIntHD:3DO:Interfaces:1p3:Includes:
KeithsIntHD:3DO:3DO_OS:1p1:Remote: 1p3:Remote:
Three of those check against something else on the same disc, which is what makes them evidence rather than colour:
Interfaces:1p3:against the SDK banner in a shipped file,... stan port1_3— the same version named twice, by a shipped string and by a leftover;game:JapSources:andgame:JapDemo:against/System/Graphics/Fonts/Kanji16.4, a 925,312-byte Japanese font which is the only file that disc's/Systemhas and Super Street Fighter II Turbo's does not. A Kanji font on a European disc stops being an anomaly;SOUND:SAMPLES:rawsamples:s12.VOCagainst six Creative Voice Files stored uncompressed inside that disc'sLISTSAMP.PAK.
The volume name carries a first name, and the disc's own credit sequence
names the same person in text (PROGRAMMING / KEITH BIRKETT in
/LaunchMe), so the leftover publishes no identity the shipped game does not.
No contact detail accompanies either.
- Run the sector map first. It is the cheapest thing that tells you a disc is unusual before you know why;
- Count
iamaduckover the whole user area, sequentially. Zero is a finding, not a null result; - Compare
/Disc label's two copies. On a disc with fill they are identical; on a disc without one they differ in everything after byte 132, and they are at block 0; - Census every file for foreign instruction pairs — 68000
LINK/UNLK, x86PUSH BP;MOV BP,SP, against the ARM0xEshare as a control — with the printable-share guard. A hash census cannot see a leftover inside a good file; - Search for
Volume:Folder:paths. They are the cheapest possible description of somebody's build machine and they cross-check against shipped strings; - Keep the two denominators apart. On the fifth disc,
Operacounts 621 in the PC region and every one is inside Operators or Operating System;stancounts 1,810 there and every one is inside constant, instance or distance. Print the chance expectation on each denominator separately, and read the context before reporting a count.
1. Does anything use the CEL engine the way the marketing said?
Answered, and the question was the wrong shape. On this machine the CEL
engine and the DSP are the only way to draw and the only way to make sound, so
yes is not a finding. The productive form is through the folios or through
the hardware, and all three discs say folios — the first hands even its
movie decoder a cel control block, the second names GraphicsFolio and
CreateSoundFilePlayer in its error strings, and the third links the audio
folio's music.lib into its own binary and leaves the library's SCCS banner
behind (§5). Closed [3 of 3].
2. Is there an asset pressed byte-identical on unrelated discs?
ANSWERED: yes, and after three discs the core is twenty.
/system/Audio/aiff/sinewave.aiff and 19 FORM 3INS DSP instruments, 31,186
bytes, byte-identical on all three discs across twenty-seven months and three
studios. Pairwise: 25, 22 and 36. Three tools agree on the total — two direct
tree diffs and a collection-wide sweep of 274 hash lists across 69
repositories — and they reconcile as 22 + 36 − 20 = 38.
And the other half is still the better half: the diffs are a version series
of an SDK, which no platform in this collection has ever had. /System/ is
the first thing to hash on any new 3DO disc.
3. How much of a disc is copies of itself? Answered: 0.0319 %, 0.0501 % and 0.1023 %, which is 2.58, 2.62 and 2.52 blocks per directory group — the same behaviour, three different denominators, and the fraction tripling while the behaviour falls. The redundancy is in the index, not the data, the opposite of CD-i, and reading it is a field read rather than an investigation. §3. The column is deleted from §10 for this reason.
4. What is in the sectors that belong to no file? Answered, and it is the platform's best cautionary tale. On the first disc the answer looked like 244 megabytes, 38.87 % of the disc, in eighteen runs and was in fact nothing, because those sectors were files a reader could not see. Zero unowned sectors on all three discs, 11.59 %, 7.93 % and 23.60 % signed mastering fill, and on the third disc the fill fraction closes against the file system's sector usage to 0.00 sectors. §4.
5. Does the format compress anything at all? Answered [3 of 3]: almost
nothing, and only its own. Four of 34, five of 93 and twenty of 37 — 29
images across three discs and every one an SDK component. Three studios, none
of which compresses a single one of its own binaries. And the test had to be
corrected on the third disc: the BL at offset 0 is the test and the size
relation is not. §5.
1. burst and gap. STILL OPEN after three, and it is now a stronger
result than it looks. 1 and 0 on all 489 entries of the first disc, on every
entry of all 29 groups of the second, and on all 219 entries of the third —
which includes the two Data Streamer files, 11.6 megabytes of a container whose
entire purpose is interleaving. 1,107 entries, three SDKs, one value. The
case that should have exercised an interleave parameter has now arrived twice
and not exercised it. These are probably not interleave parameters, and that
is as far as constancy can take anybody.
2. Are the two copy disagreements the SDK's? ANSWERED, and the third disc
supplies a referee. Same case split in five directories, copy 0 upper-case 272
times of 272 — and the SDK's own boot script writes $drivers/Languages,
agreeing with copies 1 and 2 against copy 0. The later copies carry the build
tree's real names. /rom_tags disagrees in the same field of the same record
types with the same values on all three. §3.
3. Is pixel order wrong on every disc? Answered, in a form no single
disc could give. The trap belongs to the IMAG chunk, which two discs of
three do not have. What the third disc adds is a positive statement: one disc
uses both orders, LRform for the banner screen the ROM blits and linear for
every cel the CEL engine draws. The order is a property of what reads the
asset, not of the disc or the studio. §7.
4. Coded cels, sub-8-bit depths and packed cel data. Answered by the second disc; not exercised by the third. All 20 of the third disc's cels are 16-bit direct colour and packed, so 1, 2, 4 and 6 bits per pixel go unexercised there and 8 bits per pixel is still unseen after three discs.
5. The banner screen. ANSWERED, three ways. It exists; its magic is
APPSCRN and its format is derived (§7); one disc of three has one and it is
the SDK's untouched placeholder reading FICTIONAL DEVELOPER presents BOGUS TITLE; and the other two have zero occurrences of the magic over 1.08
gigabytes, so not found has become not present.
6. The signature algorithm. Advanced, not answered. The 64 bytes sit at
offset +224 of the /rom_tags block on two discs whose tag tables are 128 and
192 bytes — so it is a fixed offset, not something appended after an end.
Still 512 bits, still wholly different between the two copies, still unverified
and still unnamed.
7. Whether /signatures is always 335,872 bytes. ANSWERED: yes. Three
discs, 335,872 bytes, to the byte. 164 blocks is the SDK's fixed
reservation. How much of it is used is not fixed at all: the third disc's is
83.23 % the byte 0x55 with only 28 blocks of 164 not pure padding, against
the second disc's 4.62 bits of entropy. Two files agree on 54 % of their bytes
and 99.26 % of that agreement is one 180,224-byte run of shared padding.
8. Whether a 3DO disc exists with more than one track. STILL OPEN, and the third disc turned the zero into a finding. Three zeros — but this is the disc that uses 17 % of a CD and whose music would have needed 21 % as CD-DA. Capacity was free by a factor of five and the sound is still in the data track. The constraint is the drive, not the disc: 176,400 bytes per second for PCM against 153,600 available, and no way to serve a Red Book track and read data at once. §8.
-
NEW, and it is the fifth disc's whole contribution: how many 3DO discs have no mastering fill? One of five, and it is 14.83 % somebody else's computer. Counting
iamaduckover the user area is one command and it should be run on every disc before anything else. §13. -
burstandgap— 1,107 entries on three discs plus every entry of the fifth, one value. The case that should have moved them did not. -
The first disc's two codec opcodes — untouched. Neither later disc has a home-made codec.
-
ANSWERED and CLOSED by the sixth disc: 8 bits per pixel. Doctor Hauzer has 729 cels of 1,157 at 8 bpp, and it is the dominant depth on that object rather than a curiosity. Every depth this platform defines — 1, 2, 4, 6, 8 and 16 — has now been seen on some disc, so the question closes rather than narrowing. What it left behind is a new one: every one of those 1,157 cels has a null
PLUTpointer, on a disc whose commonest depth cannot be drawn without a palette. §7. -
The
XTRAchunk — 643 occurrences on the second disc, always 16 bytes, always zero; zero occurrences on the third; 360 on the fourth, always 16 bytes. Three discs of four have it and nobody has read one. -
The signature algorithm — see above.
-
A disc with more than one track — see above.
-
NEW: what the 349 undecoded
BRGRmembers are. 3.02 % of the third disc's pressing, including its ninety maps. The archive's index is airtight and its leaves are not; four attempts are listed in that disc's repository. -
NARROWED again, and the question was mis-specified: is the
0x0crom_tagsrecord a pressing date? Now five values, monotone, all five landing in 1993–1995 under the 1904 epoch and nowhere possible under any other, each one after its own disc's SDK stamp — and the fifth lands between two discs whose/Systemtrees are identical on 116 files of 116, which is a constraint no wrong epoch survives comfortably. But the fifth disc has no documented pressing date of its own either, so the outside check is still Crash 'n Burn's alone. This document asked for a fifth disc and got one. What it should have asked for is a disc whose pressing date is documented independently. Restated for the sixth. §4. -
ANSWERED four times over, and the fifth answer is "no container at all": what a studio does with the graphics stack.
IMAG, bareCCB, aBRGRarchive,ANIM— and on the fifth disc a raw 320 × 250 eight-bit raster in a 40-sector block with a VGA palette, plus a raw 320 × 250 sixteen-bit raster with no header at all. Five discs, five answers, and one of the answers is that the platform's containers were not used. §7. -
ANSWERED, and restated: the builder stops where a run of root copies stops. On the fourth disc both
iamaduckregions start at the block immediately after a run of root-directory copies. On the fifth there is no fill — and both regions of unowned sectors start at the block immediately after a run of root-directory copies, at 128,315 and at 176,147, both joins closing to the block. So the rule is not about the fill: it is about where the builder stops writing, and the fill is only what four discs put there afterwards.CLOSED by the seventh disc, which supplies four independent joins on one object. FIFA International Soccer has a five-block root split 3 + 2 + 1 + 1, so its copy runs end at 100,052, 201,274, 255,818 and 258,929, and its four fill regions begin at 100,053, 201,275, 255,819 and 258,930. Four of four, every join closing to the block, and one fill region ends immediately before the next root copy — which the rule also predicts. Eight independent instances across three discs, zero exceptions. §3, §4, §13.
-
ANSWERED on three discs: the relocation-target exception is always the title's own binary. On the fourth disc 3DO's 38 images are 38 of 38 on the rule and the studio's 3 are 1 of 3. On the fifth, 3DO's 38 are 38 of 38 and the studio's exception is
/playmovie. On the sixth,/System's 34 are 34 of 34 and the one exception on the disc is/OrgData/program/sramtools— the studio's save-game utility, in the studio's own directory, atro + rw + 4.The seventh disc is the strongest test the question has had, because it is the first with THREE studio binaries and all three break the rule.
/launchme,/playlistand/PlayMovieOvlall land onro + rw + debug + 4;/System's 38 images are 38 of 38 on the rule. Earlier discs had 1 of 3 studio binaries exceptional, 2 of 3, and 1 of 1; this has 3 of 3.Four discs, four independent confirmations, and zero exceptions among 148 SDK images. It is a fact about how a studio invoked the linker and not about the format. §5.
A warning for whoever tests it next. Decoding the
BLat offset 4 requirestarget = PC + 8 + offset x 4wherePCis the instruction's own address, i.e.offset x 4 + 12. Using+ 8reports every image on the disc as an exception, which on the sixth disc produced a spectacular and entirely false finding for as long as it took to compare it againstaifcensus.py's 35 of 36. Two tools disagreeing is what caught it. -
NARROWED: what are
/rom_tagstypes0x0dand0x05, and what is0x05's+12word?0x07and0x10carryos_code's andmisc_code's sizes on every disc that has them;0x05's+8word is/signatures' first block minus one, now on four of four.0x0dis the interesting one: it equalsboot_code's size on the launch title and misses by exactly +118 on the second, fourth, fifth, sixth and SEVENTH discs — 5,168 against 5,050 on every one. A constant miss on five discs is a field with a fixed overhead in it, not a coincidence, and it is still described rather than named. The seventh disc adds a second undescribed word: record0x05's+12reads 303,104 there, which is 148 blocks on a disc whose/signaturesis 164. Written down so an eighth disc has something to compare it with. -
ADVANCED to FOUR points, the bracket narrowed from 125 days to 30, and
[corrected]on how the two versions differ: whichCPORT49.ROMis the original?This document said they differ by 68 bytes — one
kprintfcall and its format string. That conflates two things and the number belongs to the other one. Measured on the seventh disc, which carries the clean version:FIFA 1,332 bytes against Slayer 1,400, as extracted common prefix identical for 3 bytes differing bytes over the common 1,332 891 strings only in Slayer 'Stamped event pod %d position %d generic %d' Slayer's extra 68 bytes ff ff ff ff + 64 high-entropy bytes and on FIFA's OWN pressing, bytes 1,332..1,400 of block 1,206: ff ff ff ff + 64 high-entropy bytes, then iamaduckiamaduckThe 68 bytes are the signing pass — a four-byte terminator and 512 bits — and they are on BOTH discs. The extracted lengths differ because the two extractions read different directory copies, which is the trap this document derives four hundred lines earlier and then fell into. The two compilations differ in 891 bytes of 1,332. The conclusion — separate compilations, one carrying a debug string — is unaffected and better founded.
AD&D Slayer 1994-08-16 1,400 as extracted the debug build FIFA Int. Soccer 1994-09-15 1,332 sha1 e132b48e... clean Alone in the Dark 1994-12-19 1,332 sha1 e132b48e... clean SSF2T 1995-01-10 1,332 sha1 e132b48e... cleanThree later pressings byte-identical against one earlier, and the gap from the debug build to the first clean one falls from 125 days to 30. It still does not prove removal rather than addition — a disc pressed before 1994-08-16 that has a
CPORT49.ROMwould, and none of the seven does. §3, §12 of 3do-fifainternationalsoccer-doc, §14 of 3do-aloneinthedark-doc. -
ADVANCED to two answers, and they have nothing in common: how does a 3DO disc store a room? The fifth disc's answer is a 40-sector block — 81,920 bytes holding a four-byte header, a 768-byte palette, 320 × 250 pixels and 1,148 bytes of slack — so the game seeks to a sector rather than reading a file.
The sixth disc's answer is a three-word big-endian offset table over four sections, on 33 of 33 rooms, and the sections plus 33 × 12 bytes of header sum to the directory's 7,955,696 bytes exactly:
section 0 797,148 B 10.02 % 0 cels section 1 6,157,032 B 77.40 % 882 cels section 2 797,676 B 10.03 % 184 cels section 3 203,444 B 2.56 % 0 celsSo a room on that disc is 1,066 platform cels behind an index, where a room on the fifth disc is a raw raster the game blits itself. Two discs, two answers, neither a variation of the other, and no alignment to the drive's quantum on the second one at all. Sections 0 and 3 are not derived. §7.
-
NEW: does any other disc's
.PAK-equivalent turn out to be a rewritten PKZIP? The fifth disc's twenty archives are PKZIP files whose per-entry headers were replaced and whose tails were left in place, so the compression type is stored twice in two vocabularies and agrees 2,050 times of 2,050. Look at the sixteen bytes after every member of any archive on this platform, and look forPK. -
ANSWERED for one disc, and the count is the first the question has had: how much of the 3DO's SDX2 usage is a false economy? §8 shows the codec costs the same bytes as eight-bit PCM. Doctor Hauzer ships 48 files at eight bits with codec
NONE, 638,903 bytes, 0.2432 % of its user area — identical in cost to sixteen-bit SDX2, eight bits of resolution thrown away — on a disc that uses SDX2 on all twelve of its music files and on all seven films that carry sound. The studio had the better encoder loaded in the same folio. It is not an oversight about compression; it is a decision to spend nothing on sound effects. One disc counted, five to go. -
NEW, from the sixth disc: what determines the CONTENT of a duplicated run? §3 establishes that when an Opera disc duplicates content the unit is a contiguous run of files across directories, that 24 such runs are pressed 67 times on that disc, and that a file's copy count is how many times its run was written. What is not derived is how the runs were chosen — the 47 files in them include four SDK instrument patches, a cursor and a music track, which is consistent with what one scene needs resident and does not demonstrate it. Comparing a run's contents against the disc's own room tables would settle it and nobody has.
-
NEW: what are the
IMAGcontainer'sCPYR,KWRD,CRDTandDESCchunks for? Eleven files of 77 on the sixth disc carry them, 88 bytes between them, and every field on every one holds the SDK tool's placeholder — No Copyright, No KeyWord, No Credit, No Description. A field that is constant tells you nothing about its meaning, and nobody has seen one filled in. §7. -
NARROWED, and the question was the wrong one: is
SHDR+24 ever anything but 20,480 or 32,768? Two discs say 20,480 and one says 32,768, all of them honoured exactly by the builder — and the seventh disc honours 32,768 on 43 files of 43 with noSHDRto read it from. So the value is a property of whatever multiplexed the stream and not of the file, and the better question is what sets it. Read the field where there is one, divide where there is not, and write the value down either way. §9. -
ANSWERED for one disc, and it is the seventh's contribution to open question 16's neighbourhood: what does a 3DO title choose when the constraint is the DRIVE rather than the disc? FIFA International Soccer is 90.8048 % of a CD with 30,620 sectors free — not short of space — and it puts 53 of its 54 AIFF files and all 43 of its films at 22,050 Hz, half the CD rate, in SDX2. At 44,100 the sound alone would have wanted 57.4 % of a single-speed drive's 153,600 bytes per second and 43 films at fifteen frames a second could not have run beside it. A sample-rate decision on this platform is a bandwidth decision, and the free space is the thing that proves it was not a capacity one. One disc counted. §1, §8.
-
NEW: what packs an
SHPMmember, and what are the0xC0FBarchives' 229PLUTmembers? The seventh disc's own art is 60SHPMcontainers holding 3,891 members and 150xC0FBarchives holding 349, and both containers are derived on 100 % of their files while neither raster is decoded. Six geometry identities were tried against every member's body length and the best closes on 16 of 3,891. The disc names the fields itself, in a shipped debugger:type %02x, next %05x,bytes = %3d, rows = %3d, x/y = %3d/%3d, cx/cy = %3d/%3d,packed/unpacked, and — the foothold —unpack - INVALID PACK CODE (%x), which means the codes are small integers a walker can enumerate. §12 of 3do-fifainternationalsoccer-doc lists the four attempts so nobody repeats them. -
NEW: what is
/rom_tagsrecord0x05's+12word? It reads 303,104 on the seventh disc — 148 blocks — on a disc whose/signaturesis 164 blocks and 335,872 bytes. Nobody has written the value down on any other disc, which is the whole of the problem. Read it and record it. §4. -
NEW, and it is a debt rather than a question: the third, fifth and sixth discs' Cinepak contact sheets were rendered by a decoder that reset its codebooks every frame and should be re-rendered. No published finding depends on a decoded pixel value, so nothing in those repositories is wrong — but every picture in them is. §9, §11.