Skip to content

02-filesystem.md

Latest commit

 

History

History
121 lines (95 loc) · 4.81 KB

02-filesystem.md

File metadata and controls

121 lines (95 loc) · 4.81 KB
Raw

02 - The file system

Plain ISO 9660 level 1. No Joliet, no Rock Ridge, no extended attribute records, no multi-extent files. tools/isofs.py reads all of it in about a hundred lines because there is nothing else to read.

The primary volume descriptor

Field Value
System identifier CDTV
Volume identifier DragonStone
Volume space size 1,635 blocks of 2,048
Path table size 30 bytes; L type at LBA 20, M type at LBA 19
Root directory LBA 22, 6,144 bytes
Publisher Core Design
Data preparer Sajjad Majid - ISOCD 1.04 by Pantaray, Inc. USA -
Application DragonStone
Volume set / copyright / abstract / bibliographic all empty
Creation 1994122212272100 = 1994-12-22 12:27:21 UTC
Modification / expiration / effective all zero
File structure version 1

Two things are worth pointing at.

The system identifier says CDTV, not CD32. That is correct and deliberate: the Amiga CD32 reads CDTV discs, and a CD32 title identifies its volume the way a 1991 CDTV title does. There is no field anywhere in ISO 9660 that says "this is a CD32 game". What marks the disc as an Amiga disc is its content -- an AmigaDOS startup sequence, AmigaDOS commands in c/, and the Commodore trademark block at sector 21.

The string fields are NUL-padded rather than space-padded, and DragonStone uses lower case. ISO 9660 asks for d-characters -- upper case, digits, underscore -- padded with spaces. Every string field on this disc breaks both rules. Nothing cares, because the only thing that ever reads them is a person.

The application-use area

The 512-byte application-use field is normally empty. Here it is not:

offset 883:  00
offset 884:  46 53 00 00        "FS"
offset 888:  54 4D 00 14        "TM", 0x0014 = 20
offset 892:  00 00 08 00        0x0800 = 2048
offset 896:  00 00 00 15        0x0015 = 21

Two two-character tags, FS and TM, and then the numbers 20, 2,048 and 21 -- the LBA of the path table, one sector's worth of bytes, and the LBA of the trademark block. This is the only reference on the entire disc to sector 21: no directory record covers it and the file system treats it as free space. 11-leftovers.md has what is actually in there.

Directories and records

Three directories: root at LBA 22, s at 25, c at 27. The path table has three entries and agrees. All 91 files are single-extent, ;1 versioned, with no XA subheader and no system-use bytes.

Files are laid out alphabetically within each directory, which is why the shared Lx_* files -- written last, as the timestamps show -- sit at low LBAs and the level files sit at high ones.

Timestamps and the AmigaDOS epoch

Every directory record carries a seven-byte recording date. On this disc almost all of them read:

4E 01 01 00 mm ss 00     =  1978-01-01 00:mm:ss +00:00

Year byte 0x4E is 78, so 1978; month 1, day 1; hour always 0. 1 January 1978 is day zero of the AmigaDOS DateStamp. A machine with no battery-backed clock -- or one that has simply never been told the date -- comes up at exactly that instant, and every file written afterwards is stamped with the time since power-on.

Sorting the files by that time reproduces the build session:

Time File Note
00:01:09 L1_GSBlk.cru first file written
00:03:08 L2_XMemI.cru levels 1 and 2 done in two minutes
00:05:19 L3_GSBlk.cru a two-minute pause before level 3
00:15:08 Lc_XMemI.cru all eleven levels written
00:19:43 Lx_ChipI.cru four and a half minutes later, shared data
00:22:30 c/FreeAnim the boot commands
00:26:35 s/Startup-Sequence last file written

Note the ordering: the level data was written before the loader and before the boot sequence. The seconds field never exceeds 59 and the minutes climb monotonically, so this is a clock, not a counter.

There is no L4 anywhere in the sequence. Between L3_XMemI at 00:06:04 and L5_GSBlk at 00:06:26 there is a 22-second gap, no longer than the gaps elsewhere. Level 4 was not written and then removed during this session; it simply was not there.

The three files from 1992

Three records carry a real date:

File Timestamp
Lx_ReloD.cru 1992-08-14 18:26:17
Lx_TPage.cru 1992-08-14 18:26:56
Lx_DataL.exe 1992-08-14 18:28:07

Two minutes apart, on a Friday afternoon, two years and four months before the disc was mastered -- and, unlike everything else, from a machine whose clock was set.

These three files are also, exactly and only, the three files that contain the marker CDIOEND, the end-of-module label of the disc's hand-written CD driver (03-boot-chain.md). The correlation is perfect. The explanation is not established: see 12-open-questions.md.