cdromfileformats.md

# Cdromfileformats

> Source: https://problemkaputt.de/psx-spx.htm
> Section: Cdromfileformats

[CDROM File Formats](./reference.md#cdromfileformats)
**Official PSX File Formars**

CDROM File Official Sony File Formats

**Executables**

[CDROM File Playstation EXE and SYSTEM.CNF](#cdromfileplaystationexeandsystemcnf)

CDROM File PsyQ .CPE Files (Debug Executables)

[CDROM File PsyQ .SYM Files (Debug Information)](#cdromfilepsyqsymfilesdebuginformation)

**Video Files**

CDROM File Video Texture Image TIM/PXL/CLT (Sony)

[CDROM File Video Texture/Bitmap (Other)](#cdromfilevideotexturebitmapother)

CDROM File Video 2D Graphics CEL/BGD/TSQ/ANM/SDF (Sony)

[CDROM File Video 3D Graphics TMD/PMD/TOD/HMD/RSD (Sony)](#cdromfilevideo3dgraphicstmdpmdtodhmdrsdsony)

CDROM File Video STR Streaming and BS Picture Compression (Sony)

**Audio Files**

CDROM File Audio Single Samples VAG (Sony)

[CDROM File Audio Sample Sets VAB and VH/VB (Sony)](#cdromfileaudiosamplesetsvabandvhvbsony)

CDROM File Audio Sequences SEQ/SEP (Sony)

[CDROM File Audio Other Formats](#cdromfileaudiootherformats)

CDROM File Audio Streaming XA-ADPCM

[CDROM File Audio CD-DA Tracks](#cdromfileaudiocddatracks)

**Virtual Filesystem Archives**

PSX titles are quite often using virtual filesystems, with numerous custom file
archive formats.

CDROM File Archives with Filename

[CDROM File Archives with Offset and Size](#cdromfilearchiveswithoffsetandsize)

CDROM File Archives with Offset

[CDROM File Archives with Size](#cdromfilearchiveswithsize)

CDROM File Archives with Chunks

[CDROM File Archives with Folders](#cdromfilearchiveswithfolders)

[CDROM File Archives in Hidden Sectors](#cdromfilearchivesinhiddensectors)

More misc stuff...

[CDROM File Archive HED/DAT/BNS/STR (Ape Escape)](#cdromfilearchiveheddatbnsstrapeescape)

CDROM File Archive WAD.WAD, BIG.BIN, JESTERS.PKG (Crash/Herc/Pandemonium)

[CDROM File Archive BIGFILE.BIG (Gex)](#cdromfilearchivebigfilebiggex)

[CDROM File Archive BIGFILE.DAT (Gex - Enter the Gecko)](#cdromfilearchivebigfiledatgexenterthegecko)

[CDROM File Archive FF9 DB (Final Fantasy IX)](#cdromfilearchiveff9dbfinalfantasyix)

CDROM File Archive Ace Combat 2 and 3

[CDROM File Archive NSD/NSF (Crash Bandicoot 1-3)](#cdromfilearchivensdnsfcrashbandicoot13)

CDROM File Archive STAGE.DIR and *.DAT (Metal Gear Solid)

[CDROM File Archive DRACULA.DAT (Dracula)](#cdromfilearchivedraculadatdracula)

[CDROM File Archive Croc 1 (DIR, WAD, etc.)](#cdromfilearchivecroc1dirwadetc)

[CDROM File Archive Croc 2 (DIR, WAD, etc.)](#cdromfilearchivecroc2dirwadetc)

CDROM File Archive Headerless Archives

Using archives can avoid issues with the PSX's poorly implemented ISO
filesystem: The PSX kernel supports max 800h bytes per directory, and lacks
proper caching for most recently accessed directories (additionally, some
archives can load the whole file/directory tree from continous sectors, which
could be difficult in ISO filesystems).

**Compression**

[CDROM File Compression](#cdromfilecompression)

**Misc**

CDROM File XYZ and Dummy/Null Files

**FILENAME.EXT**

The BIOS seems to support only (max) 8-letter filenames with 3-letter
extension, typically all uppercase, eg. "FILENAME.EXT". Eventually, once when
the executable has started, some programs might install drivers for long
filenames(?)

The PSX uses the standard CDROM ISO9660 filesystem without any encryption (ie.
you can put an original PSX CDROM into a DOS/Windows computer, and view the
content of the files in text or hex editors without problems).

**Note**

MagDemoNN is short for "Official U.S. Playstation Magazine Demo Disc NN"

<a id="cdromfileplaystationexeandsystemcnf"></a>
## CDROM File Playstation EXE and SYSTEM.CNF

**SYSTEM.CNF**

Contains boot info in ASCII/TXT format, similar to the CONFIG.SYS or
AUTOEXEC.BAT files for MSDOS. A typical SYSTEM.CNF would look like so:

```
BOOT = cdrom:\abcd_123.45;1 arg ;boot exe (drive:\path\name.ext;version)
TCB = 4                         ;HEX (=4 decimal)   ;max number of threads
EVENT = 10                      ;HEX (=16 decimal)  ;max number of events
STACK = 801FFF00                ;HEX (=memtop-256)
```

The first line specifies the executable to load, from the "cdrom:" drive, "\"
root directory, filename "abcd_123.45" (case-insensitive, the real name in the
disk directory would be uppercase, ie. "ABCD_123.45"), and, finally ";1" is the
file's version number (a rather strange ISO-filesystem specific feature) (the
version number should be usually/always 1). Additionally, "arg" may contain an
optional 128-byte command line argument string, which is copied to address
00000180h, where it may be interpreted by the executable (most or all games
don't use that feature).

Each line in the file should be terminated by 0Dh,0Ah characters... not sure if
it's also working with only 0Dh, or only 0Ah...?

**ABCD_123.45**

This is a normal executable (exactly as for the .EXE files, described below),
however, the filename/extension is taken from the game code (the "ABCD-12345"
text that is printed on the CD cover), but, with the minus replaced by an
underscore, and due to the 8-letter filename limit, the last two characters are
stored in the extension region.

That "XXXX_NNN.NN" naming convention seems to apply for all official licensed
PSX games. Wild Arms does unconventionally have the file in a separate folder,
"EXE\SCUS_946.06".

**PSX.EXE (Boot-Executable) (default filename when SYSTEM.CNF doesn't exist)**

**XXXX_NNN.NN (Boot-Executable) (with filename as specified in SYSTEM.CNF)**

**FILENAME.EXE (General-Purpose Executable)**

PSX executables are having an 800h-byte header, followed by the code/data.

```
000h-007h ASCII ID "PS-X EXE"
008h-00Fh Zerofilled
010h      Initial PC                   (usually 80010000h, or higher)
014h      Initial GP/R28               (usually 0)
018h      Destination Address in RAM   (usually 80010000h, or higher)
01Ch      Filesize (must be N*800h)    (excluding 800h-byte header)
020h      Unknown/Unused ;Addr         (usually 0)  ;\optional overlay?
024h      Unknown/Unused ;Size         (usually 0)  ;/(not auto-loaded)
028h      Memfill Start Address        (usually 0) (when below Size=None)
02Ch      Memfill Size in bytes        (usually 0) (0=None)
030h      Initial SP/R29 & FP/R30 Base (usually 801FFFF0h) (or 0=None)
034h      Initial SP/R29 & FP/R30 Offs (usually 0, added to above Base)
038h-04Bh Reserved for A(43h) Function (should be zerofilled in exefile)
04Ch-xxxh ASCII marker
"Sony Computer Entertainment Inc. for Japan area"         ;NTSC
"Sony Computer Entertainment Inc. for Europe area"        ;PAL
"Sony Computer Entertainment Inc. for North America area" ;NTSC
(or often zerofilled in some homebrew files)
(the BIOS doesn't verify this string, and boots fine without it)
xxxh-7FFh Zerofilled
800h...   Code/Data                  (loaded to entry[018h] and up)
```

The code/data is simply loaded to the specified destination address, ie. unlike
as in MSDOS .EXE files, there is no relocation info in the header.

Note: In bootfiles, SP is usually 801FFFF0h (ie. not 801FFF00h as in
system.cnf). When SP is 0, the unmodified caller's stack is used. In most cases
(except when manually calling DoExecute), the stack values in the exeheader
seem to be ignored though (eg. replaced by the SYSTEM.CNF value).

The memfill region is zerofilled by a "relative" fast word-by-word fill (so
address and size must be multiples of 4) (despite of the word-by-word filling,
still it's SLOW because the memfill executes in uncached slow ROM).

The reserved region at [038h-04Bh] is internally used by the BIOS to memorize
the caller's RA,SP,R30,R28,R16 registers (for some bizarre reason, this
information is saved in the exe header, rather than on the caller's stack).

Additionally to the initial PC,R28,SP,R30 values that are contained in the
header, two parameter values are passed to the executable (in R4 and R5
registers) (however, usually that values are simply R4=1 and R5=0).

Like normal functions, the executable can return control to the caller by
jumping to the incoming RA address (provided that it hasn't destroyed the stack
or other important memory locations, and that it has pushed/popped all
registers) (returning works only for non-boot executables; if the boot
executable returns to the BIOS, then the BIOS will simply lockup itself by
calling the "SystemErrorBootOrDiskFailure" function.

**Relocatable EXE**

Fade to Black (CINE.EXR) contains ID "PS-X EXR" (instead "PS-X EXE") and string
"PSX Relocable File - Delphine Software Int.", this is supposedly some custom
relocatable exe file (unsupported by the PSX kernel).

**MSDOS.EXE and WINDOWS.EXE Files**

Some PSX discs contain DOS or Windows .EXE files (with "MZ" headers), eg.
devkit leftovers, or demos/gimmicks.

<a id="cdromfilepsyqsymfilesdebuginformation"></a>
## CDROM File PsyQ .SYM Files (Debug Information)

PsyQ .SYM Files contain debug info, usually bundled with PsyQ .MAP and Psy .CPE
files. Those files are generated by PsyQ tools, which appear to be still in use
for homebrew PSX titles.

The files are occassionally also found on PSX CDROMs:

```
Legacy of Kain PAL version (\DEGUG\NTSC\KAIN2.SYM+MAP+CPE)
RC Revenge (\RELEASE.SYM)
Twisted Metal: Small Brawl (MagDemo54: TMSB\TM.SYM)
Jackie Chan Stuntmaster (GAME_REL.SYM+CPE)
SnoCross Championship Racing (MagDemo37: SNOCROSS\SNOW.TOC\SNOW.MAP)
Sled Storm (MagDemo24: DEBUG\MAIN.MAP)
E.T. Interplanetary Mission (MagDemo54: MEGA\MEGA.CSH\* has SYM+CPE+MAP)
```

**Fileheader .SYM**

```
00h 4  File ID ("MND",01h)
04h 4  Whatever (0,0,0,0)    ;TOMB5: 0,02h,0,0
08h .. Chunks (see below)
```

```
_______________________________ Symbol Chunks ________________________________
```

**Chunk 01h: Symbol (Immediate, eg. memsize, or membase)**

**Chunk 02h: Symbol (Function Address for Internal & External Functions)**

**Chunk 05h: Symbol (?)**

**Chunk 06h: Symbol (?)**

```
00h 4   Address/Value
04h 1   Chunk ID (01h/02h/05h/06h)
05h 1   Symbol Length (LEN)
06h LEN Symbol (eg. "VSync")
```

```
__________________________ Source Code Line Chunks ___________________________
```

**Chunk 80h: Source Code Line Numbers: Address for 1 Line**

```
00h 4   Address (for 1 line, starting at current line)
04h 1   Chunk ID (80h)
```

**Chunk 82h: Source Code Line Numbers: Address for N Lines (8bit)**

```
00h 4   Address (for N lines, starting at current line)
04h 1   Chunk ID (82h)
05h 1   Number of Lines (00h=None, or 02h and up?)
```

**Chunk 84h: Source Code Line Numbers: Address for NN Lines (16bit)**

```
00h 4   Address (for N lines, starting at current line)
04h 1   Chunk ID (84h)
05h 2   Number of Lines (?)
```

**Chunk 86h: Source Code Line Numbers: Address for Line NNN (32bit?)**

```
00h 4   Address (for 1 line, starting at newly assigned current line)
04h 1   Chunk ID (84h)
05h 4   Absolute Line Number (rather than number of lines) (?)
```

**Chunk 88h: Source Code Line Numbers: Start with Filename**

```
00h 4   Address (start address)
04h 1   Chunk ID (88h=Filename)
05h 4   First Line Number (after comments/definitions) (32bit?)
09h 1   Filename Length (LEN)
0Ah LEN Filename (eg. "C:\path\main.c")
```

**Chunk 8Ah: Source Code Line Numbers: End of Source Code**

```
00h 4   Address (end address)
04h 1   Chunk ID (8Ah)
```

```
__________________________ Internal Function Chunks __________________________
```

**Chunk 8Ch: Internal Function: Start with Filename**

```
00h 4    Address
04h 1    Chunk ID (8Ch)
05h 4    Whatever (1Eh,00h,20h,00h)  ;or 1Eh,00h,18h,00h
09h 4    Whatever (00h,00h,1Fh,00h)
0Dh 4    Whatever (00h,00h,00h,C0h)
11h 4    Whatever (FCh,FFh,FFh,FFh)  ;mask? neg.offset?
15h 4    Whatever (10h,00h,00h,00h)   0002h
0Fh DIM*4 Array Entries per Dimension     ;eg. [3][4] --> 00000003h,00000004h
xxh 1     Internal Fake Name Length (LEN1) (0=none)
xxh LEN1  Internal Fake Name  (eg. ".1fake")
xxh 1     Symbol Name Length (LEN2)
xxh LEN2  Symbol Name (eg. "r")
```

```
______________________________ Class/Type Values _____________________________
```

**Class definition (in chunk 94h) (and somewhat same/similar in chunk 96h)**

(looks same/similar as C_xxx class values in COFF files!)

```
0001h = Local variable              (with Offset = negative stack offset)
0002h = Global variable or Function (with Offset = address)
0008h = Item in Structure           (with Offser = offset within struct)
0009h = Incoming Function param     (with Offset = index; 0,4,8,etc.)
000Ah = Type address / struc start? (with Offset = zero)
000Dh = Type alias                  (with Offset = zero)
```

**Type definition (in chunk 94h/96h)**

(maybe lower 4bit=type, and next 4bit=usage/variant?)

(looks same/similar as T_xxx type values in COFF files!)

```
0000h =
0001h =
0002h =
0003h =                (16bit signed?)
0004h = int            (32bit signed?)
0005h =
0006h =
0007h =
0008h = (address)      (32bit unsigned?) (with Definition=000Ah)
0009h =
000Ah =
000Bh =
000Ch = u_char         (8bit unsigned?)
000Dh = u_short,ushort (16bit unsigned?)
000Eh = u_int          (32bit unsigned?)
000Fh = u_long         (64bit unsigned?) (or rather SAME as above?)
0021h = function with 0 params, and/or return="nothing"?
0024h = main function with 2 params, and/or return="int"?
0052h = argv           (string maybe?)
0038h = GsOT           (huh?)
00F8h = GsOT_TAG       (huh?)
00FCh = PACKET         (huh?)
??    = float,bool,string,ptr,packet,(un-)signed8/16/32/64bit,etc
??    = custom type/struct (using value 000xh plus "fake" name, or so?)
```

```
__________________________________ .MAP File _________________________________
```

**PsyQ .MAP File**

The .SYM file is usually bundled with a .MAP file, which is containing a
summary of the symbolic info as ASCII text (but without info on line numbers or
data types). For example:

```
Start     Stop   Length      Obj Group            Section name
80010000 80012D5B 00002D5C 80010000 text             .rdata
80012D5C 800C8417 000B56BC 80012D5C text             .text
800C8418 800CDAB7 000056A0 800C8418 text             .data
800CDAB8 800CFB63 000020AC 800CDAB8 text             .sdata
800CFB64 800D5C07 000060A4 800CFB64 bss              .sbss
800D5C08 800DD33F 00007738 800D5C08 bss              .bss
```

```
Address  Names alphabetically
800CFE80 ACE_amount
800CFB94 AIMenu
800CDE5C AXIS_LENGTH
8005E28C AddClippedTri
8005DFEC AddVertex
...
```

```
Address  Names in address order
00000000 _cinemax_obj
00000000 _cinemax_header_org
00000000 _cinemax_org
00000000 _mcardx_sbss_size
00000000 _mcardx_org
...
```

<a id="cdromfilevideotexturebitmapother"></a>
## CDROM File Video Texture/Bitmap (Other)

Apart from Sony's TIM (and PXL/CLT) format, there are a bunch of other
texture/bitmap formats:

**Compressed Bitmaps**

```
.BS used by several games (and also in most .STR videos)
.GIF used by Lightspan Online Connection CD
.JPG used by Lightspan Online Connection CD
.BMP with RLE4 used by Lightspan Online Connection CD (MONOFONT, PROPFONT)
.BMP with RLE8+Delta also used by Online Connection CD (PROPFONT\ARIA6.BMP)
.PCX with RLE used by Jampack Vol. 1 (MDK\CD.HED\*.pcx)
```

**Uncompressed Bitmaps**

```
.BMP
.BMP used by Mat Hoffman's Pro BMX (MagDemo39: BMX\BMXCD.HED\*)
.BMP used by Mat Hoffman's Pro BMX (MagDemo48: MHPB\BMXCD.HED\*)
.BMP used by Thrasher: Skate and Destroy (MagDemo27: SKATE\ASSETS\*.ZAL)
.BMP used by Dave Mirra Freestyle BMX (MagDemo36,46: BMX\ASSETS\*.ZAL)
.VRM .IMG .TEX .TIM .RAW .256 .COL .4B .15B .R16 .TPG - raw VRAM data
"SC" memory card icons
```

**Targa TGA and Paintbrush PCX**

CDROM File Video Texture/Bitmap (TGA)

CDROM File Video Texture/Bitmap (PCX)

**PSI bitmap - Power Spike (MagDemo43: POWER\GAME.IDX\*.BIZ\*.PSI)**

```
000h 10h   Name 1 ("FILENAME.BMP", zeropadded)
010h 10h   Name 2 ("FILENAME.PSI", zeropadded)
020h 4     Bits per pixel (usually 4, 8, or 16)
024h 2     Bitmap VRAM Dest.X ?
026h 2     Bitmap VRAM Dest.Y ?
028h 2     Bitmap Width in pixels
02Ah 2     Bitmap Height in pixels
02Ch 2     Palette VRAM Dest.X ?   ;\zero for 16bpp
02Eh 2     Palette VRAM Dest.Y ?   ;/
030h 2     Bitmap Width in Halfwords (PixelWidth*bpp/16)
032h 2     Palette Size in Halfwords (0, 10h, 100h for 16bpp,4npp,8bpp)
034h 4     Maybe Bitmap present flag (always 1)
038h 4     Maybe Palette present flag (0=16bpp, 1=4bpp/8bpp)
03Ch ..    Bitmap pixels
...  ..    Palette (if any, for 4bpp: 16x16bit, for 8bpp: 256x16bit)
```

**JumpStart Wildlife Safari Field Trip (MagDemo52: DEMO\DATA.DAT\*.DAT+*.PSX)**

This game does use two different (but nearly identical) bitmap formats (with
either palette or bitmap data stored first).

```
000h 4     Total Filesize (Width*Height+20Ch)
004h 2     Bitmap Width
006h 2     Bitmap Height
008h 4     Unknown, always 1 (maybe 1=8bpp?)
In .DAT files (512x192 or 256x64 pix), palette first:
00Ch 200h  Palette data
20Ch ..    Bitmap data
In .PSX files (64x64 pix), bitmap first:
00Ch ..    Bitmap data
...  200h  Palette data
```

To detect the "palette first" format, check for these conditions(s):

```
Filename extension is ".DAT"
Bitmap Width<>Height (non-square)
[00Ch..20Bh] has AllMSBs>=80h, and SomeLSBs 512x205pix, 16bpp (Apocalypse warning.rle)
3C008h bytes --> 512x240pix, 16bpp (most common)
96008h bytes --> 640x480pix, 16bpp (tony hawk's pro skater)
```

Most of the older BMR files (in Apocalypse) have valid 8-byte headers:

```
000h 2     Unknown (FFA0h) (ID for files with valid headers?)
002h 2     Dest.Y (usually 0) (11h=(240-205)/2 in Apocalypse warning.rle)
004h 2     Width  (usually 200h=512pix)
006h 2     Height (usually F0h=240pix) (CDh=205pix in Apocalypse warning.rle)
008h ..    Bitmap data, 16bpp (width*height*2 bytes)
```

Most or all newer BMR files (in Apocalypse "loadlogo.rle", and in all files in
Spider-Man 1, Spider-Man-2, Tony Hawk's Pro Skater) have the 8-byte header
replaced by unused 8-byte at end of file:

```
000h ..    Bitmap data, 16bpp (width*height*2 bytes)
..   8     Unused (garbage or extra pixels, not transferred to VRAM)
```

BUG: The bitmaps in all .BMR files (both with/without header) are distorted:
The last 4-byte (rightmost 2pix) of each scanline should be actually located at
the begin of the scanline, and the last scanline is shifted by an odd amount of
bytes (resulting in nonsense 16bpp pixel colors); Spider-Man is actually
displaying the bitmap in that distorted form (although it does mask off some
glitches: one of the two bad rightmost pixels is replaced by a bad black
leftmost pixel, and glitches in upper/lower lines aren't visible on 224-line
NTSC screens).

**Croc 1 (retail: *.IMG) (retail only, not in MagDemo02 demo version)**

**Croc 2 (MagDemo22: CROC2\CROCII.DIR\*.IMG)**

**Disney's The Emperor's New Groove (MagDemo39: ENG\KINGDOM.DIR\*.IMG)**

**Disney's Aladdin in Nasira's Rev. (MagDemo46: ALADDIN\ALADDIN.DIR\*.IMG)**

Contains raw 16bpp bitmaps, with following sizes:

```
25800h bytes = 12C00h pixels (320x240)  ;Croc 1 (retail version)
3C000h bytes = 1E000h pixels (512x240)
96000h bytes = 4B000h pixels (640x480)
```

Note: The .IMG format is about same as .BMR files (but without the 8-byte
header, and without distorted scanlines).

**Mat Hoffman's Pro BMX (MagDemo39: BMX\FE.WAD+STR\*.BIN) (Activision)**

**Mat Hoffman's Pro BMX (MagDemo48: MHPB\FE.WAD+STR\*.BIN) (Shaba/Activision)**

```
000h 2     Bits per pixel (4 or 8)
002h 2     Bitmap Width in pixels
004h 2     Bitmap Height in pixels
006h 2     Zero
008h N*2   Palette (with N=(1 SHL bpp))
...  ..    Bitmap (with Width*Height*bpp/8 bytes)
...  (..)  Zeropadding to 4-byte boundary (old version only)
```

The trailing alignment padding exists only in old demo version (eg. size of
78x49x8bpp "coreypp.bin" is old=10F8h, new=10F6h).

**E.T. Interplanetary Mission (MagDemo54: MEGA\MEGA.CSH\*)**

```
000h 2     Type (0=4bpp, 1=8bpp, 2=16bpp)
002h 2     Unknown (usually 0000h, or sometimes CCCCh)
004h 2     Bitmap Width in pixels
006h 2     Bitmap Height in pixels
008h 200h  Palette (always 200h-byte, even for 4bpp or 16bpp)
208h ..    Bitmap (Width*Height*bpp/8 bytes)
```

Palette is 00h-or-CCh-padded when 4bpp, or CCh-filled when 16bpp.

Note: Some files contain two or more such bitmaps (of same or different sizes)
badged together.

**EA Sports: Madden NFL '98 (MagDemo02: TIBURON\*.DAT\*)**

**EA Sports: Madden NFL 2000 (MagDemo27: MADN00\*.DAT\*)**

**EA Sports: Madden NFL 2001 (MagDemo39: MADN01\*.DAT\*)**

This format is used in various EA Sports Madden .DAT archives, it contains
standard TIMs with extra Headers/Footers.

```
000h 4     Offset to TIM (1Ch) (Hdr size)    (1Ch)               ;\
004h 4     Offset to Footer    (Hdr+TIM size)(123Ch,1A3Ch,1830h) ;
008h 2     Bitmap Width in pixels      (40h or 60h or 30h)       ;
00Ah 2     Bitmap Height in pixels     (40h)                     ;
00Ch 4     Unknown, always 01h         (01h)                     ; Header
010h 4     Unknown, always 23h         (23h)                     ; 1Ch bytes
014h 2     Unknown, always 0101h       (101h)                    ;
016h 1     Bitmap Width in pixels      (40h or 60h or 30h)       ;
017h 1     Bitmap Height in pixels     (40h)                     ;
018h 4     Unknown, always 00h         (0)                       ;/
01Ch ..    TIM (Texture, can be 4bpp, 8bpp, 16bpp)               ;-TIM
...  4     Unknown, always C0000222h   (C0000222h)               ;\
...  2     Unknown, always 0001h       (0001h)                   ;
...  1     Bitmap Width in pixels      (40h or 60h or 30h)       ; Footer
...  1     Bitmap Height in pixels     (40h)                     ; 12h bytes
...  4     Unknown, always 78000000h   (78000000h)               ;
...  6     Unknown                     (0,0,80h,0,0,0)           ;/
```

Purpose is unknown; the 8bit Width/Height entries might be TexCoords.

The PORTRAITS.DAT archives are a special case:

```
Madden NFL '98 (MagDemo02: TIBURON\PORTRAIT.DAT) (48x64, 16bpp)
Madden NFL 2000 (MagDemo27: MADN00\PORTRAIT.DAT) (96x64, 8bpp plus palette)
Madden NFL 2001 (MagDemo39: MADN01\PORTRAIT.DAT) (64x64, 8bpp plus palette)
```

Those PORTRAITS.DAT don't have any archive header, instead they do contain
several images in the above format, each one zeropadded to 2000h-byte size.

**989 Sports: NHL Faceoff '99 (MagDemo17: FO99\*.KGB\*.TEX)**

**989 Sports: NHL Faceoff 2000 (MagDemo28: FO2000\*.TEX)**

**989 Sports: NCAA Final Four 2000 (MagDemo30: FF00\*.TEX)**

```
000h 0Ch  ID "TEX PSX ",01h,00h,00h,00h    ;used in 989 Sports games
00Ch 4    Number of Textures
010h 4    Total Filesize
014h 4    Common Palette Size    (0=200h, 1=None, 2=20h)
018h (..) Common Palette, if any (0,20h,200h bytes)
...  ..   Texture(s)
Texture format:
000h 10h  Filename (eg. "light1", max 16 chars, zeropadded if shorter)
010h 4    Width in pixels  (eg. 40h)
014h 4    Height           (eg. 20h or 40h)
018h 4    Unknown          (always 0)
01Ch 4    Number of Colors (eg. 10h, 20h or 100h)
020h ..   Bitmap (4bpp when NumColors10h)
...  (..) Palette (NumColors*2 bytes, only present if Common Palette=None)
```

The .TEX files may be in ISO folders, KGB archives, DOTLESS archives. And, some
are stored in headerless .DAT/.CAT archives (which start with ID "TEX PSX ",
but seem to have further files appended thereafter).

**Electronic Arts .PSH (SHPP)**

FIFA - Road to World Cup 98 (with chunk C0h/C1h = RefPack compression)

NCAA March Madness 2000 (MagDemo32: MM2K\*.PSH)

Need for Speed 3 Hot Pursuit (*.PSH, ZLOAD*.QPS\RefPack.PSH)

ReBoot (DATA\*.PSH) (with chunk 6Bh)

Sled Storm (MagDemo24: DEBUG,ART,ART2,ART3,SOUND\*.PSH) (with Comment, Mipmap)

WCW Mayhem (MagDemo28: WCWDEMO\*.BIG\*.PSH) (with chunk C0h/C1h = RefPack)

```
000h 4    ID "SHPP"
004h 4    Total Filesize (or Filesize-0Ch, eg. FIFA'98 ZLEG*.PSH)
008h 4    Number of Textures (N)
00Ch 4    ID "GIMX"
010h N*8  File List
...  ..   Data (each File contains a Bitmap chunk, and Palette chunk, if any)
File List entries:
000h 4    Name (ascii) (Mipmaps use the same name for each mipmap level)
004h 4    Offset from begin of archive to first Chunk of file
Caution: Most PSH files do have the above offsets sorted in increasing order,
but some have UNSORTED offsets, eg. Sled Storm (MagDemo24: ART3\LOAD1.PSH),
so one cannot easily compute sizes as NextOffset-CurrOffset.
Note: Mipmap textures consist of two files with same name and different
resolution, eg. in Sled Storm (MagDemo24: ART\WORLD0x.PSH)
Bitmap Chunk:
000h 1    Chunk Type (40h=PSX/4bpp, 41h=PSX/8bpp, 42h=PSX/16bpp)
001h 3    Offset from current chunk to next chunk (000000h=None)
004h 2    Bitmap Width in pixels (can be odd, pad lines to 2-byte boundary)
006h 2    Bitmap Height
008h 2    Center X   (whatever that is)
00Ah 2    Center Y   (whatever that is)
00Ch 2    Position X (whatever that is, plus bit12-15=flags?)
00Eh 2    Position Y (whatever that is, plus bit12-15=flags?)
010h ..   Bitmap data (each scanline is padded to 2-byte boundary)
...  ..   Padding to 8-byte boundary
Compressed Bitmap Chunk:
000h 1    Chunk Type (C0h=PSX/4bpp, C1h=PSX/8bpp, and probably C2h=PSX/16bpp)
001h 0Fh  Same as in Chunk 40h/41h/42h (see there)
010h ..   Compressed Bitmap data (usually/always with Method=10FBh)
...  ..   Padding to 8-byte boundary
Palette Chunk (if any) (only for 4bpp/8bpp bitmaps, not for 16bpp):
000h 1    Chunk Type (23h=PSX/Palette)
001h 3    Offset from current chunk to next chunk (000000h=None)
004h 2    Palette Width in halfwords (10h or 100h)
006h 2    Palette Height             (1)
008h 2    Unknown (usually same as Width) (or 80D0h or 9240h)
00Ah 2    Unknown (usually 0000h)         (or 0001h or 0002h)
00Ch 2    Unknown (usually 0000h)
00Eh 2    Unknown (usually 00F0h)
010h ..   Palette data (16bit per color)
Note: The odd 80D0h,0001h values occur in Sled Storm ART\WORKD00.PSH\TBR1)
Unknown Chunk (eg. ReBoot (DATA\AREA15.PSH\sp*))
000h 1    Chunk Type (6Bh)
001h 3    Offset from current chunk to next chunk (000000h=None)
004h 8    Unknown (2C,00,00,3C,03,00,00,00)
00Ch -    For whatever reason, there is no 8-byte padding here
Comment Chunk (eg. Sled Storm (MagDemo24: ART\WORLD0x.PSH))
000h 1    Chunk Type (6Fh=PSX/Comment)
001h 3    Offset from current chunk to next chunk (000000h=None)
004h ..   Comment ("Saved in Photoshop Plugin made by PEE00751@...",00h)
...  ..   Zeropadding to 8-byte boundary
Unknown Chunk (eg. Sled Storm (MagDemo24: ART\WORLD09.PSH\ADAA))
000h 1    Chunk Type (7Ch)
001h 3    Offset from current chunk to next chunk (000000h=None)
004h 2Ch  Unknown (reportedly Hot spot / Pix region, but differs on PSX?)
```

The whole .PSH file or the bitmap chunks can be compressed:

CDROM File Compression EA Methods

Variants of the .PSH format are also used on PC, PS2, PSP, XBOX (with other
Chunk Types for other texture/palette formats, and for optional extra data).
For details, see: http://wiki.xentax.com/index.php/EA_SSH_FSH_Image

**Destruction Derby Raw (MagDemo35: DDRAW\*.PCK,*.FNT,*.SPR)**

This format can contain one single Bitmap, or a font with several small
character bitmaps.

```
000h 2     ID "BC"                                        ;\
002h 1     Color Depth (1=4bpp, 2=8bpp, 4=16bpp)          ; Header
003h 1     Type        (40h=Bitmap, C0h=Font)             ;/
...  (2)   Palette Unknown (0 or 1)                       ;\only if Bitmap
...  (2)   Palette Unknown (1)                            ; 4bpp or 8bpp
...  (..)  Palette data (20h or 200h bytes for 4bpp/8bpp) ;/
...  2     Bitmap Number of Bitmaps-1 (N-1)               ;\
...  2     Bitmap Width in pixels                         ;
...  2     Bitmap Height in pixels                        ; Bitmap(s)
...  N*1   Bitmap Tilenumbers (eg. "ABCDEFG..." for Fonts);
...  N*1   Bitmap Proportional Font widths? (0xh or FFh)  ;
...  N*BMP Bitmap(s) for all characters                   ;/
...  (20h) Palette Data (20h bytes for 4bpp)              ;-only if Font/4bpp
```

All bitmap scanlines are padded to 2-byte boundary, eg. needed for:

```
INGAME1\BOWL2.PTH\SPRITES.PTH\ST.SPR    30x10x4bpp: 15 --> 16 bytes/line
INGAME1\BOWL2.PTH\SPRITES.PTH\STOPW.SPR 75x40x4bpp: 37.5 --> 38 bytes/line
```

The BC files are usually compressed (either in PCK file, or in the compressed
DAT portion of a PTH+DAT archive).

**Cool Boarders 2 (MagDemo02: CB2\DATA*\*.FBD)**

```
000h 2    ID ("FB")                                ;\File Header
002h 2    Always 1 (version? 4bpp? num entries?)   ;/
004h 2    Palette VRAM Dest X (eg. 300h)           ;\
006h 2    Palette VRAM Dest Y (eg. 1CCh,1EDh,1FFh) ; Palette Header
008h 2    Palette Width in halfwords (eg. 100h)    ; (all zero when unused)
00Ah 2    Palette Height (eg. 1 or 0Dh)            ;/
00Ch 2    Bitmap VRAM Dest X (eg. 140h or 200h)    ;\
00Eh 2    Bitmap VRAM Dest Y (eg. 0 or 100h)       ; Bitmap Header
010h 2    Bitmap Width in halfwords                ;
012h 2    Bitmap Height                            ;/
...  ..   Palette Data (if any)                    ;-Palette Data
...  ..   Bitmap Data                              ;-Bitmap Data
```

The bitmap data seems to be 4bpp and/or 8bpp, but it's hard to know the correct
palette (some files have more than 16 or 256 palette colors, or don't have any
palette at all).

CDROM File Video Texture/Bitmap (PCX)

**PC Paintbrush .PCX files (ZSoft)**

Default extension is .PCX (some tools did use .PCX for the "main" image, and
.PCC for smaller snippets that were clipped/cropped/copied from from a large
image).

```
000h 1    File ID (always 0Ah=PCX/ZSoft)
001h 1    Version (0,2,3,4,5)
002h 1    Compression (always 01h=RLE) (or inofficial: 00h=Uncompressed)
003h 1    Bits per Pixel (per Plane) (1, 2, 4, or 8)
004h 2    Window X1   ;\
006h 2    Window Y1   ; Width  = X2+1-X1
008h 2    Window X2   ; Height = Y2+1-Y1
00Ah 2    Window Y2   ;/
00Ch 2    Horizontal Resolution in DPI  ;\often square, but can be also zero,
00Eh 2    Vertical Resolution in DPI    ;/or screen size, or other values
010h 30h  EGA/VGA Palette (16 colors, 3-byte per color = R,G,B) (or garbage)
010h 1    CGA: Bit7-4=Background Color (supposedly IRGB1111 ?)
013h 1    CGA: Bit7:0=Color,1=Mono,Bit6:0=Yellow,1=White,Bit5:0=Dim,1=Bright
014h 1    Paintbrush IV: New CGA Color1 Green  ;\weird new way to encode CGA
015h 1    Paintbrush IV: New CGA Color1 Red    ;/palette in these two bytes
040h 1    Reserved (00h) (but is 96h in animals.pcx)
041h 1    Number of color planes (1=Palette, 3=RGB, or 4=RGBI)
042h 2    Bytes per Line (per plane) (must be N*2) (=(Width*Bits+15)/16*2)
044h 2    PaletteInfo? (0000h/xxxxh=Normal, 0001h=Color/BW, 0002h=Grayscale)
046h 2    Horizontal screen size in pixels  ;\New fields, found only
048h 2    Vertical screen size in pixels    ;/in Paintbrush IV/IV Plus
04Ah 36h  Reserved (zerofilled) (or garbage in older files, custom in MGS)
080h ..   Bitmap data (RLE compressed)
...  1    VGA Palette ID (0Ch=256 colors)                      ;\when 8bpp
..   300h VGA Palette (256 colors, 3-byte per color  = R,G,B)  ;/
```

Decoding PCX files is quite a hardcore exercise due to a vast amount of
versions, revisions, corner cases, incomplete & bugged specifications, and
inofficial third-party glitches.

**PCX Versions**

```
00h = Version 2.5 whatever ancient stuff
02h = Version 2.8 with custom 16-color palette
03h = Version 2.8 without palette (uses fixed CGA/EGA palette)
04h = Version ?.? without palette (uses fixed CGA/EGA palette)
05h = Version 3.0 with custom 16-color or 256-color palette or truecolor
```

NOTE: Version[01h]=05h with PaletteInfo[44h]=0001h..0002h is Paintbrush IV?

**Known PCX Color Depths**

```
planes=1, bits=1  P1        ;1bit, HGC 2 color (iview and paint shop pro 2)
planes=1, bits=2  P2        ;2bit, CGA 4 color (with old/new palette info)
planes=3, bits=1  RGB111    ;3bit, EGA 8 color (official samples)  ;\version
planes=4, bits=1  IRGB1111  ;4bit, EGA 16 color (paint shop pro 2) ;/03h..04h
planes=1, bits=4  P4        ;4bit, BMP 16 color (iview)
planes=1, bits=8  P8        ;8bit, VGA 256 color palette
planes=1, bits=8  I8        ;8bit, VGA 256 level grayscale (gmarbles.pcx)
planes=3, bits=8  BGR888    ;24bit, truecolor (this is official 24bit format)
;planes=1, bits=24 BGR888 ?  ;24bit, reportedly exists? poor compression
;planes=4, bits=4  ABGR4444  ;16bit, wikipedia-myth? unlikely to exist
;planes=4, bits=8  ABGR8888  ;32bit, truecolor+alpha (used in abydos.dcx\*)
```

**Width and Height**

These are normally calculated as so:

```
Width  = X2+1-X1      ;width for normal files
Height = Y2+1-Y1      ;height for normal files
```

However, a few PCX files do accidentally want them to be calculated as so:

```
Width  = X2-X1        ;width for bugged files
Height = Y2-Y1        ;height for bugged files
```

Files with bugged width can be (sometimes) detected as so:

```
(Width*Bits+15)/16*2) > BytesPerLine
```

Files with bugged height can be detected during decompression:

```
BeginOfLastScanline >= Filesize (or Filesize-301h for files with palette)
```

Bugged sample files are SAMPLE.DCX, marbles.pcx and gmarbles.pcx. RLE
decompression may crash when not taking care of such files.

**Color Planes and Palettes**

The official ZSoft PCX specs are - wrongly - describing planes as:

```
plane0 = red         ;\
plane1 = green       ; this is WRONG, NONSENSE, does NOT exist
plane2 = blue        ;
plane3 = intensity   ;/
```

The 8-color and 16-color EGA images are actually using plane0,1,2,(3) as
bit0,1,2,(3) of the EGA color number; which implies plane0=blue (ie. red/blue
are opposite of the ZSoft document).

The truecolor and truecolor+alpha formats have plane0..2=red,green,blue (as
described by ZSoft), but they don't have any intensity plane (a few files are
using plane3=alpha).

**Mono 2-Color Palette**

This format was intended for 640x200pix 2-color CGA graphics, it's also common
for higher resolution FAX or print images. The general rule for these files is
to use this colors:

```
color0=black
color1=white
```

There are rumours that color1 could be changed to any of the 16 CGA colors
(supposedly via [10h].bit7-4, but most older & newer 2-color files have
that byte set to 00h, so one would end up with black-on-black).

Some newer 2-color files contain RGB palette entries [10h]=000000h,
[13h]=FFFFFFh (and [16h..3Fh]=00h-filled or FFh-filled).

Iview does often display 2-color images with color1=dark green (somewhat
mysteriously; it's doing that even for files that don't contain any CGA color
numbers or RGB palette values that could qualify as dark green).

**4-Color Palettes**

This format was intended for 320x200pix 4-color CGA graphics, and the palette
is closely bound to colors available in CGA graphics modes. Color0 is defined
in [10h], and Color1-3 were originally defined in [13h], and later in
[14h,15h]:

```
color0=[10h].bit7-4  ;(Color0 IRGB)  ;CGA Port 3D9h.bit3-0 (usually 0=black)
bright=[13h].bit5                    ;CGA Port 3D9h.bit4    ;\
palette=[13h].bit6                   ;CGA Port 3D9h.bit5    ; old method
if [13h].bit7 then palette=2         ;CGA Port 3D8h.bit2    ;/
if [01h]=05h and [44h]=0001h then                           ;\new "smart"
if [14h]>200 or [15h]>200 then bright=1, else bright=0    ; method used in
if [14h]>[15h] then palette=0 else palette=1              :/Paintbrush IV
if palette=0 and bright=0 then color1..3=02h,04h,06h  ;\green-red-yellow
if palette=0 and bright=1 then color1..3=0Ah,0Ch,0Eh  ;/
if palette=1 and bright=0 then color1..3=03h,05h,07h  ;\cyan-magenta-white
if palette=1 and bright=1 then color1..3=0Bh,0Dh,0Fh  ;/
if palette=2 and bright=0 then color1..3=03h,04h,07h  ;\cyan-red-white
if palette=2 and bright=1 then color1..3=0Bh,0Ch,0Fh  ;/
```

Palette=2 uses some undocumented CGA glitch, it was somewhat intended to output
grayscale by disabling color burst on CGA hardware with analog composite
output, but actually most or all CGA hardware is having digital 4bit IRGB
output, which outputs cyan-red-white.

The new "smart" method is apparently trying to detect if [13h-1Bh] contains RGB
values with Color1=Green or Cyan, and to select the corresponding CGA palette;
unfortunately such PCX files are merely setting [14h,15h] to match up with the
"smart" formula, without actually storing valid RGB values in [13h-1Bh].

**8-Color and 16-Color, with fixed EGA Palettes (version=03h or 04h)**

These images have 3 or 4 planes. Plane0-3 correspond to bit0-3 of the EGA color
numbers (ie. blue=plane0, green=plane1, red=plane2, and either intensity=plane3
for 16-color, or intensity=0 for 8-color images).

Some 8-Color sample images (with version=03h and 04h) can be found bundled with
PC Paintbrush Plus 1.22 for Windows. A 16-color sample called WINSCR.PCX can be
found elsewhere in internet.

Caution 1: Official ZSoft specs are wrongly claiming plane0=red and
plane2=blue; this is wrong (although Paint Shop Pro 2 is actually implementing
it that way) (whilst MS Paint for Win95b can properly display them) (most other
tools are trying to read a palette from [10h..3Fh], which is usually garbage
filled in version=03h..04h).

Caution 2: The standard EGA palette is used for version=03h..04h (many docs
claim it to be used for version=03h only).

**16-Color, with custom EGA/VGA Palettes (version=02h or 05h)**

These can have 1 plane with 4 bits, or 4 planes with 1 bit. Header[10h..3Fh]
contains a custom 16-color RGB palette with 3x8bit per R,G,B.

Classic VGA hardware did only use the upper 6bit of the 8bit values.

Classic EGA hardware did only use the upper 2bit of the 8bit values (that, only
when having a special EGA monitor with support for more than 16 colors).

**256-Color VGA Palettes (version=05h)**

These have 1 plane with 8 bits. And a 256-color RGB palette with 3x8bit per
R,G,B appended at end of file.

The appended 256-color palette should normally exist only in 256-color images,
some PCX tools are reportedly always appending the extra palette to all
version=05h files (even for 2-color files).

**256-Level Grayscale Images (version=05h and [44h]=0002h)**

The most obvious and reliable way is to use a palette with grayscale RGB
values. However, Paintbrush IV is explicetly implementing (or ignoring?) an
obscure grayscale format with following settings:

```
[01h]=version=05h, and [44h]=0002h=grayscale
```

That settings are used in a file called gmarbles.pcx (which does contain a
256-color RGB palette with gray RGB values, ie. one can simply ignore the
special settings, and display it as normal 256-color image).

**Default 16-color CGA/EGA Palettes**

```
Color  Name                     IRGB1111 RGB222 RGB888   Windows
00h    dark black               0000     000    000000   000000
01h    dark blue                0001     002    0000AA   000080
02h    dark green               0010     020    00AA00   008000
03h    dark cyan                0011     022    00AAAA   008080
04h    dark red                 0100     200    AA0000   800000
05h    dark magenta             0101     202    AA00AA   800080
06h    dark yellow (brown)      0110     210!!  AA5500!! 808000
07h    dark white (light gray)  0111     222    AAAAAA   C0C0C0!!
08h    bright black (dark gray) 1000     111    555555   808080!!
09h    bright blue              1001     113    5555FF   0000FF
0Ah    bright green             1010     131    55FF55   00FF00
0Bh    bright cyan              1011     133    55FFFF   00FFFF
0Ch    bright red               1100     311    FF5555   FF0000
0Dh    bright magenta           1101     313    FF55FF   FF00FF
0Eh    bright yellow            1110     331    FFFF55   FFFF00
0Fh    bright white             1111     333    FFFFFF   FFFFFF
```

Some notes on number of colors:

```
CGA supports 16 colors in text mode (but only max 4 colors in graphics mode).
EGA supports the same 16 colors as CGA in both text and graphics mode.
EGA-with-special-EGA-monitor supports 64 colors (but only max 16 at once).
VGA supports much colors (but can mimmick CGA/EGA colors, or similar colors)
```

CGA is using a 4pin IRGB1111 signal for up to 16 colors in text mode (max 4
colors in graphics mode), and CGA monitors contain some circuitry to convert
"dark yellow" to "brown" (though cheap CGA clones may display it as "dark
yellow").

EGA can display CGA colors (with all 16 colors in graphics mode).
EGA-with-special-EGA-monitor uses 6pin RGB222 signals for up to 64 colors (but
not more than 16 colors at once).

Windows is also using those 16 standard colors (when not having any VGA driver
installed, and also in 256-color VGA mode, in the latter case the 16 standard
colors are held to always available (even if different tasks are trying to
simultanously display different images with different palettes).

However, Windows has dropped brown, and uses non-pastelized bright colors.

**PCX files in PSX games**

```
.PCX with RLE used by Jampack Vol. 1 (MDK\CD.HED\*.pcx)
.PCX with RLE used by Hot Wheels Extreme Racing (MagDemo52: US_01293\MISC\*)
.PCX with RLE used by Metal Gear Solid (slightly corrupted PCX files)
```

**PCX files in PSX Metal Gear Solid (MGS)**

MGS is storing some extra data at [4Ah..57h] (roughly resembling the info in
TIM files).

```
04Ah 2    Custom MGS ID (always 3039h)
04Ch 2    Display Mode? (08h/18h=4bit, 09h/19h=8bit)
04Eh 2    Bitmap X-coordinate in VRAM (reportedly "divided by 2" ???)
050h 2    Bitmap Y-coordinate in VRAM
052h 2    Palette X-coordinate in VRAM
054h 2    Palette Y-coordinate in VRAM
056h 2    Palette number of actually used colors (can be less than 16/256)
058h 28h  Reserved (zerofilled)
080h ..   Bitmap data (RLE compressed)
...  1    VGA Palette ID (0Ch=256 colors)                      ;\when 8bpp
..   300h VGA Palette (256 colors, 3-byte per color  = R,G,B)  ;/
..   ..   Padding to 4-byte boundary, ie. palette isn't at filesize-301h !!!
```

MGS has filesize padded to 4-byte boundary. That is causing problems for files
with 256-color palette: The official way to find the palette is to stepback
301h bytes from end of file, which won't work with padding. To find the MGS
palette, one must decompress the whole bitmap, and then expect the 301h-byte
palette to be located after the compressed data.

As an extra oddity, MGS uses non-square ultra-high DPI values.

**DCX Archives**

DCX archives contain multiple PCX files (eg. multi-page FAX documents). The
standard format is as so:

```
0000h 4     ID (3ADE68B1h) (987654321 decimal)
0004h 4000h File List (32bit offsets) (max 1023 files, plus 0=End of List)
1004h ..    File Data area (PCX files)
```

However, some files have the first PCX at offset 1000h (ie. the list is only
3FFCh bytes tall). Reportedly there are also files that start with yet smaller
offsets (for saving space when the file list contains fewer entries).

The PCX filesize is next-curr offset (or total-curr for last file).

**References**

https://www.fileformat.info/format/pcx/egff.htm

<a id="cdromfilevideo3dgraphicstmdpmdtodhmdrsdsony"></a>
## CDROM File Video 3D Graphics TMD/PMD/TOD/HMD/RSD (Sony)

```
____________________________________ TMD _____________________________________
```

**TMD - Modeling Data for OS Library**

```
000h 4     ID (00000041h)
004h 4     Flags (bit0=FIXP, bit1-31=Reserved/zero)
008h 4     Number of Objects (N)     ;"integral value" uh?
00Ch N*1Ch Object List (1Ch-byte per entry)
...  ..    Data (Vertices, Normals, Primitives)
```

Object List entries:

```
000h 4    Start address of a Vertex     ;\Address values depend on the
004h 4    Number of Vertices            ; file header's FIXP flag:
008h 4    Start address of a Normal     ;  FIXP=0 Addr from begin of Object
00Ch 4    Number of Normals             ;  FIXP=0 Addr from begin of TMD File
010h 4    Start address of a Primitive  ;
014h 4    Number of Primitives          ;/
018h 4    Scale (signed shift value, Pos=SHL, Neg=SHR) (not used by LIBGS)
```

Vertex entries (8-byte):

```
000h 2    Vertex X (signed 16bit)
002h 2    Vertex Y (signed 16bit)
004h 2    Vertex Z (signed 16bit)
006h 2    Unused
```

Normal entries (8-byte) (if any, needed only for computing light directions):

```
000h 2    Normal X (fixed point 1.3.12)
002h 2    Normal Y (fixed point 1.3.12)
004h 2    Normal Z (fixed point 1.3.12)
006h 2    Unused
```

Primitive entries (variable length):

```
000h 1    Output Size/4 of the GPU command (after GTE conversion)
001h 1    Input Size/4 of the Packet Data in the TMD file
002h 1    Flag
0   Light source calculation (0=On, 1=Off)
1   Clip Back (0=Clip, 1=Don't clip) (for Polygons only)
2   Shading (0=Flat, 1=Gouraud)
(Valid only for the polygon not textured,
subjected to light source calculation)
3-7 Reserved (0)
003h 1    Mode (20h..7Fh) (same as GP0(20h..7Fh) command value in packet)
004h ..   Packet Data
```

Packet Data (for Polygons)

```
000h 4   GPU Command+Color for that packet (CcBbGgRrh), see GP0(20h..3Fh)
... (4)  Texcoord1+Palette (ClutYyXxh)               ;\
... (4)  Texcoord2+Texpage (PageYyXxh)               ; only if Mode.bit2=1
... (4)  Texcoord3         (0000YyXxh)               ;
... (4)  Texcoord4         (0000YyXxh) ;-quad only   ;/
... (4)  Color2 (00BbGgRrh)                          ;\
... (4)  Color3 (00BbGgRrh)                          ; only if Flag.bit2=1
... (4)  Color4 (00BbGgRrh) ;-quad only              ;/
... (2)  Normal1 (index in Normal list?)  ;always, unless Flag.bit0=1
...  2   Vertex1 (index in Vertex list?)
... (2)  Normal2 (index in Normal list?)             ;-only if Mode.bit4=1
...  2   Vertex2 (index in Vertex list?)
... (2)  Normal3 (index in Normal list?)             ;-only if Mode.bit4=1
...  2   Vertex3 (index in Vertex list?)
... (2)  Normal4 (index in Normal list?) ;\quad only ;-only if Mode.bit4=1
...  2   Vertex4 (index in Vertex list?) ;/
... (2)  Unused zeropadding (to 4-byte boundary)
```

Packet Data (for Lines)

```
000h 4   GPU Command+Color for that packet (CcBbGgRrh), see GP0(40h,50h)
... (4)  Color2 (00BbGgRrh)                          ;-only if Mode.bit4=1
...  2   Vertex1 (index in Vertex list?)
...  2   Vertex2 (index in Vertex list?)
```

Packet Data (for Rectangle/Sprites)

```
000h 4   GPU Command+Color for that packet (CcBbGgRrh), see GP0(60h..7Fh)
...  ..  Unknown, reportedy "with 3-D coordinates and the drawing
content is the same as a normal sprite."
```

Note: Objects should usually contain Primitives and Vertices (and optionally
Normals), however, N2O\SHIP.TMD does contain some dummy Objects with Number of
Vertices/Normals/Primitives all set to zero.

Used by Playstation Logo (in sector 5..11 on all PSX discs, 3278h bytes)

Used by ...???model???... (MagDemo54: MODEL\*.BIN\*.TMD)

Used by Alice in Cyberland (ALICE.PAC\xxx_TM*.FA\*.TMD)

Used by Armored Core (MagDemo02: AC10DEMP\MS\MENU_TMD.T\*)

Used by Bloody Roar 1 (MagDemo06: CMN\EFFECT.DAT\0005h)

Used by Deception III Dark Delusion (MagDemo33: DECEPT3\K3_DAT.BIN\056A,0725\*)

Used by Gundam Battle Assault 2 (DATA\*.PAC\*)

Used by Hear It Now (Playstation Developer's Demo) (*.TMD and FISH.DAT).

Used by Jersey Devil (MagDemo10: JD\*.BZZ\*)

Used by Klonoa (MagDemo08: KLONOA\FILE.IDX\*)

Used by Legend of Dragoon (MagDemo34: LOD\DRAGN0.BIN\16xxh)

Used by Macross VF-X 2 (MagDemo23: VFX2\DATA01\*.TMD)

Used by Madden NFL '98 (MagDemo02: TIBURON\MODEL01.DAT\*)

Used by No One Can Stop Mr. Domino (MagDemo18: DATA\*, .TMD and DOT1\TMD)

Used by O.D.T. (MagDemo17: ODT\*.LNK\*)

Used by Parappa (MagDemo01: PARAPPA\COMPO01.INT\3\*.TMD)

Used by Resident Evil 1 (PSX\ITEM_M1\*.DOR\0001)

Used by Starblade Alpha (FLT\SB2.DAT\* and TEX\SB2.DAT\*)

Used by Tiny Tank (MagDemo23: TINYTANK\TMD*.DSK\*.TMD)

Used by WCW/nWo Thunder (MagDemo19: THUNDER\RING\*.TMD)

Used by Witch of Salzburg (the MODELS\*.MDL\*.TMD)

Used by Scooby Doo and the Cyber Chase (MagDemo54: MODEL\*\*)

```
____________________________________ PMD _____________________________________
```

**PMD - High-Speed Modeling Data**

This is about same as TMD, with less features, intended to work fasrer.

```
000h 4    ID (00000042h)
004h 4    Offset to Primitives
008h 4    Offset to Shared Vertices (or 0=None)
00Ch 4    Number of Objects
010h ..   Objects         (4+N*4 bytes each, with offsets to Primitives)
...  ..   Primitives
...  ..   Shared Vertices (8-bytes each, if any)
```

Vertex entries (8-byte):

```
000h 2    Vertex X (signed 16bit)
002h 2    Vertex Y (signed 16bit)
004h 2    Vertex Z (signed 16bit)
006h 2    Unused
```

Objects:

```
000h 4    Number of Primitives
004h N*4  Offsets to Primitives ... maybe relative to hdr[004h] ?
```

Primitives:

```
000h 2    Number of Packets
002h 2    Type flags
0    Polygon   (0=Triangle, 1=Quadrilateral)
1    Shading   (0=Flat, 1=Gouraud)           ;uh, with ONE color?
2    Texture   (0=Texture-On, 1=Texture-Off) ;uh, withoutTexCoord?
3    Shared    (0=Independent vertex, 1=Shared vertex)
4    Light source calculation (0=Off, 1=On)  ;uh, withoutNormal?
5    Clip      (0=Back clip, 1=No back clip)
6-15 Reserved for system
004h ...  Packet(s)
```

Packet entries, when Type.bit3=0 (independent vertex):

```
000h 4   GPU Command+Color for that packet (CcBbGgRrh), see GP0(20h..7Fh)
004h 8   Vertex1 (Xxxxh,Yyyyh,Zzzzh,0000h)
00Ch 8   Vertex2 (Xxxxh,Yyyyh,Zzzzh,0000h)
014h 8   Vertex3 (Xxxxh,Yyyyh,Zzzzh,0000h)
01Ch (8) Vertex4 (Xxxxh,Yyyyh,Zzzzh,0000h) ;
CDROM File Video Streaming STR (Sony)

**.STR Sectors (with 20h-byte headers) (for MDEC Movies, or User data)**

```
000h 2    StStatus (0160h) (RV6Rh; R=Reserved=0, V=Version=1, 6=Fixed ID)
002h 2    StType (0000h..7FFFh=User Defined, 8000h..FFFFh=System; 8001h=MDEC)
004h 2    StSectorOffset (Sector number in the frame, 0=First)
006h 2    StSectorSize   (Number of sectors in the frame) (eg. 4 or 5)
008h 4    StFrameNo      (Frame number, 1=First) (except Viewpoint=0)
00Ch 4    StFrameSize    (in bytes, in this frame, excluding headers/padding)
When StType=0000h..7FFFh:
010h 10h  StUser         (user defined data)
020h 7E0h User data      (more user defined data)
When StType=8001h=MDEC (the only system defined type) (with StStatus=0160h):
010h 2    StMovieWidth                  (eg. 0140h)
012h 2    StMovieHeight                 (eg. 00F0h)
014h 4    StHeadM (reserved for system) (eg. 38000720h) ;\same as [020h-027h]
018h 4    StHeadV (reserved for system) (eg. 00020001h) ;/from 1st STR sector
01Ch 4    Unspecified                   (eg. 00000000h) (except Viewpoint<>0)
020h 7E0h Data (in BS format) (or padding, when image is smaller than frame)
```

The default file extension .STR is used by various games (though some games use
other extensions, the .FMV files in Tomb Raider do also contain standard
20h-byte .STR sector headers).

**Video Frames**

The video frames consist of BS compressed images (that is, all sectors have STR
headers at 000h..01Fh, and the first sector of each frame does additionally
contain a standard BS fileheader at offset 020h..027h).

```
See "CDROM File Video BS Compression" chapters
```

Less common, there is also a format for streaming polygon animations instead of
BS compressed bitmaps:

CDROM File Video Polygon Streaming

**STR Resolution**

The Width/Height entries are almost always multiples of 16 pixels. But there
are a few exceptions:

```
Height=260 (104h) in Star Wars Rebel Assault II, NTSC (S1\L01_PLAY.STR)
Height=200 (0C8h) in Perfect Assassin (DATA.JFS\CDV\*.STR)
Height=40  (028h) in Gran Turismo 1 (TITLE.DAT\*, MagDemo10 and MagDemo15)
Width=232  (0E8h) in Gran Turismo 1 (TITLE.DAT\*, MagDemo10 only)
```

For such videos, the width/height of MDEC decompression buffer in RAM must be
rounded up to multiples of 16 pixels (and the decompressed picture should be
cropped to the STR header width/height before forwarding it to VRAM).

Note: The extra scanlines are usually padded with the bottom-most scanline
(except, Gran Turismo 1 has gray-padding in lower/right pixels). Ideally, one
would repeat the bottom-most pixels in zigzag order.

**Subtitles**

Metal Gear Solid MGS\ZMOVIE.STR contains subtitles as text strings: The first
sector of the .STR file is something custom (without STR header), the remaining
movie consists of STR sectors with StType=0001h for subtitles and StType=8001h
for picture frames.

Unknown if other games are using the same method, or other methods.

Obviously, subtitles could be also displayed as part of the compressed image,
but text strings are much smaller, have better quality, and would also allow to
support multiple languages.

CDROM File Video Streaming Framerate

According to Sony, BS encoded 320x240pix videos can be played at 30fps (with
cdrom running at double speed).

**STR Frame Rate**

As a general rule, the frame rate is implied in CDROM rotation speed (150 or 75
sectors per second, minus the audio sectors, divided by the number of sectors
per video frame).

**Fixed/Variable Framerates**

The frame can drop on video frames that contain more sectors than usually.
Video frames that require fewer sectors than often padded with zerofilled
sectors. However, some games don't have that padding, so they could end up
reeceiving up to 150 single-sector frames per second; the actual framerate is
supposedly slowed down to 60Hz or less via Vblank timer (and with the CDROM
reading getting paused when the read-ahead buffer gets full).

**Audio Samplerate**

XA-ADPCM audio contains samplerate info (in the FORM2 subheader), the
samplerate versus amount of audio sectors can be used to compute the CDROM
rotation speed.

There are two exceptions: Some movies don't have any audio at all, and some
movies use SPU-ADPCM instead of XA-ADPCM. In the latter case, the SPU Pitch
(samplerate) may (or may not) be found somewhere in the audio sector headers.

**CDROM Rotation speed**

As said above, the speed can be often detected via audio sample rate.
Otherwise, the general rule is that most PSX games are used 2x speed (150
sectors/second). But, there are a few games with 1x speed (see below).

**CDROM Single speed (75 sectors/frame)**

Here are probably most of the USA games with videos at 1x speed.

```
007 - The World Is Not Enough
1Xtreme
Arcade Party Pak
Atari Anniversary Edition Redux
Blast Radius
Blue's Clues - Blue's Big Musical
Chessmaster II
Chronicles of the Sword
Civilization II
Colin McRae Rally
Creatures - Raised in Space
Cyberia
Demolition Racer
Dune 2000
ESPN Extreme Games
FIFA Soccer 97
Fade to Black
Family Connection - A Guide to Lightspan
Fear Effect
Fox Hunt
Interactive CD Sampler Volume 1
Jade Cocoon - Story of the Tamamayu
Jeopardy! 2nd Edition
Juggernaut
Krazy Ivan
MTV Sports - Skateboarding featuring Andy Macdonald
MTV Sports - T.J. Lavin's Ultimate BMX
Medal of Honor
Medal of Honor - Underground
Official U.S. PlayStation Magazine Demo Disc 23
Planet of the Apes
PlayStation Underground Number 2
Shockwave Assault
Starblade Alpha
Starwinder - The Ultimate Space Race
Str.at.e.s. 1 - Match-A-Batch
Str.at.e.s. 5 - Parallel Lives!
Str.at.e.s. 7 - Riddle Roundup!
The X-Files
Top Gun - Fire at Will!
Um Jammer Lammy
Uprising X
Wheel of Fortune - 2nd Edition
Williams Arcade's Greatest Hits
```

CDROM File Video Streaming Chunk-based formats

**Newer Electronic Arts videos (EA)**

EA videos are chunk based (instead of using 20h-byte .STR headers). The next
chunk starts right at the end of the previous chunk (without padding to sector
boundaries).

```
STR Sector Header:
No STR Sector header (first sector starts directly with "VLC0" chunk)
VLC0 Chunk (at begin of movie file):
000h 4     Chunk ID "VLC0"
004h 4     Chunk Size (always 1C8h)     (big-endian)
008h 1C0h  16bit MDEC values for E0h huffman AC codes (little-endian)
MDEC Chunks (video frames):
000h 4     Chunk ID "MDEC"                           ;\
004h 4     Chunk Size (...)             (big-endian) ; custom chunk header,
008h 2     Bitmap Width in pixels       (big-endian) ; instead of STR header
00Ah 2     Bitmap Height in pixels      (big-endian) ;
00Ch 4     Frame Number (starting at 0) (big-endian) ;/
010h ..    Data (in BS v2 format, but using custom Huffman codes from VLC0)
...  ..    Zeropadding to 4-byte boundary
Audio Chunks (au00/au01):
000h 4     Chunk ID ("au00"=normal, "au01"=last audio chunk)
004h 4     Chunk Size (...)                                   (big-endian)
008h 4     Total number of 2x4bit samples in previous chunks  (big-endian)
00Ch 2     Unknown (always 800h) (maybe Pitch: 800h=22050Hz)  (big-endian)
00Eh 2     Unknown (always 200h)                              (big-endian)
...  ..    SPU-ADPCM audio data, left  (0Fh bytes per sample block)
...  ..    SPU-ADPCM audio data, right (0Fh bytes per sample block)
...  ..    Garbagepadding to 4-byte boundary
Note: SPU-ADPCM does normally have 10h-byte blocks, but in this case,
the 2nd byte (with loop flags) is omitted, hence only 0Fh-byte blocks.
Zero Chunk (zeropadding at end of file, exists only in some EA videos):
000h ..    Zeropadding
```

**Older Electronic Arts videos**

Crusader: No Remorse (1996 Origin Systems) (MOVIES\*.STR)

Soviet Strike (1996 Electronic Arts)

Battle Stations (1997 Electronic Arts)

Andretti Racing (1996 Electronic Arts)

```
STR Sector Header:
000h 4    ID (DDCCBBAAh) (aka AABBCCDDh big-endian)
004h 4    Sector number within STR file (0=First, up to Filesize/800h-1)
008h 7F8h Data (video and audio chunks, see below) (first chunk is "ad20")
Video Chunks (MDEC):
000h 4    Chunk ID "MDEC"                           ;\
004h 4    Chunk Size (...)             (big-endian) ;
008h 2    Bitmap Width in pixels       (big-endian) ; custom chunk header
00Ah 2    Bitmap Height in pixels      (big-endian) ;
00Ch 4    Frame Number (starting at 0) (big-endian) ;/
010h ..   Data (in BS v2 format)                    ;-standard BS v2 data
Audio Chunks (ad20/ad21) (22050Hz stereo):
000h 4    Chunk ID ("ad20"=normal, "ad21"=last audio chunk)
004h 4    Chunk Size (1A50h or 1A70h)                        (big-endian)
008h 4    Total number of 2x4bit samples in previous chunks  (big-endian)
00Ch 2    Unknown (always 800h) (maybe Pitch: 800h=22050Hz)  (big-endian)
00Eh 2    Unknown (always 200h)                              (big-endian)
010h ..   SPU-ADPCM audio data, left  (10h bytes per sample block)
...  ..   SPU-ADPCM audio data, right (10h bytes per sample block)
Last STR Sector:
000h 18h  FFh-filled (aka 8-byte STR header and 10h-byte Chunk header)
018h -    Nothing (total STR filesize is N*800h+18h bytes)
```

**Oldest Electronic Arts videos**

Wing Commander III: Heart of the Tiger (MOVIES1.LIB\*.wve) (1995, EA/Origin)

```
STR Sector Header:
No STR Sector header (first sector starts directly with "Ad10" chunk)
Video Chunks (MDEC):
000h 4    Chunk ID "MDEC"                           ;\
004h 4    Chunk Size (2xx0h)           (big-endian) ;
008h 2    Bitmap Width in pixels       (big-endian) ; custom chunk header
00Ah 2    Bitmap Height in pixels      (big-endian) ;
00Ch 2    Unknown (7FFFh)              (big-endian) ;
00Eh 2    Unknown (AD14h or AD24h)     (big-endian) ;/
010h ..   Data (in BS v2 format)                    ;-standard BS v2 data
...  ..   Padding, up to circa 20h bytes, FFh-filled
Audio Chunks (Ad10/Ad11) (22050Hz stereo):
000h 4    Chunk ID ("ad20"=normal, "ad21"=last audio chunk)
004h 4    Chunk Size (D38h or D28h) (or less in last chunk)  (big-endian)
010h ..   SPU-ADPCM audio data, left  ? (10h bytes per sample block)
...  ..   SPU-ADPCM audio data, right ? (10h bytes per sample block)
```

Audio seems to be 22050Hz stereo, however, chunks with size=D38h have odd
amounts of sampleblocks, so it isn't as simple as having left/right in
first/second half.

**Policenauts (Japan, 1996 Konami) (NAUTS\MOVIE\*.MOV)**

```
STR Sector Header:
No STR Sector header (first sector starts directly with "VMNK" chunk)
First chunk (800h bytes):
000h 4     ID "VMNK" (aka KNMV backwards, maybe for Konami Video/Movie)
004h 4     Unknown (01h)
008h 4     Unknown (01h)
00Ch 4     Unknown (F0h)
010h 4     Size of KLBS chunks?          (40000h)
014h 4     Bitmap X1 (aka left border)?  (16pix, 10h)
018h 4     Bitmap Y1 (aka upper border)? (16pix, 10h)
01Ch 4     Bitmap Width                  (288pix, 120h)
020h 4     Bitmap Height                 (144pix, 90h)
024h 7E4h  Zerofilled
Further chunks (40000h bytes, each):
000h 8     Zerofilled
008h 4     Chunk ID "KLBS" (aka SBLK backwards, maybe for Stream Block)
00Ch 4     Chunk Size (usually 40000h)
010h 4     Number of Name List entries
014h 4     Number of Name List entries (same as above)
018h 8     Zerofilled
020h N*30h Name List
...  ..    Data (referenced from Name List)
...  ..    Zeropadding (to end of 40000h-byte chunk)
```

The Name List does resemble a file archive, however, the "filenames" are just
Type IDs (eg. all picture frames do have the same name).

```
Name List entries:
000h 8     Zerofilled
008h 8     Data Type Name (eg. "SCIPPDTS")
010h 4     Time when to play/display the frame (0 and up)
014h 4     Time duration for that frame (usually 14h for Picture frames)
018h 4     Data Offset in bytes (from begin of chunk)
01Ch 4     Data Size in bytes
020h 10h   Zerofilled
```

Data Formats for the different Data Types...

```
Type "SDNSHDTS" aka SNDS,STDH - SoundStdHeader (Size=800h, Duration=0)
000h 4     Maybe Pitch? (800h)                            (big-endian)
004h 4     Maybe Pitch? (800h)                            (big-endian)
008h 4     Total SPU-ADPCM size in bytes (for whole .MOV) (big-endian)
00Ch 4     Unknown (FFFFFFFFh)                            (whatever)
010h 4     Unknown (00007FFFh)                            (big-endian)
014h 7ECh  Zerofilled
Type "SDNSSDTS" aka SNDS,STDS - SoundStdStream (Size=10h..4000h, Duration=9Ch)
000h 4000h SPU-ADPCM data in 10h-byte blocks (last chunk is less than 4000h)
Type "SCIPPDTS" aka PICS,STDP - PictureStdPicture (Size=3xxxh, Duration=14h)
000h 3xxxh Picture Frame (in BS v1 format)
Type "SCTELLEC" aka ETCS,CELL - ExtraCells? (Size=0Ch, Duration=1)
000h ..    Maybe subtitle related...?
Type "SCTEGOLD" aka ETCS,DLOG - ExtraD-log? (Size=19h..31h, Duration=27h..44h)
000h ..    Maybe subtitle related...?
```

Note: Total number of 10h-byte SPU-ADPCM blocks can be odd (so the audio seems
to be mono).

Apart from the .MOV files, there's also one standard .STR file for the Knnami
Intro (with normal STR headers and BS v2 data).

**Best Sports Games Ever (DD\*.VLC and MOVIES\*.VLC) (Powerline Demo Disc menu)**

This format is used for still images with only frame, and for looping short
animation sequences in the Demo Disc Menu. There's no audio.

```
Header Chunk:
000h 4    Fixed ID (74h,55h,89h,08h aka 08895574h)
004h 2    Bitmap Width           (140h)
006h 2    Bitmap Height          (100h)
008h 2    Video Frame Size/4     (17A0h or 13B0h)
00Ah 2    Number of Video Frames (01h or 32h)
00Ch 4    Frame End ID (eg. 62DCCACEh) (random?, but stays same within movie)
Video Frame Chunk(s):
...  ..   Data (in BS v1/v2/v3 format)         ;\size = hdr[008h]*4
...  ..   FFh-filled (padding to Frame Size)   ;/
...  4    Frame End ID (eg. 62DCCACEh)         ;-same value as in hdr[00Ch]
```

For random access, best is seeking "fpos=N*(Framesize+4)+10h", alternately one
could search "fpos=LocationAfterFrameEndID".

**Sentient (FILMS\*.FXA)**

This is having neither per-sector STR headers nor Chunk headers, instead it's
having raw data with fixed size of 10 sectors per frame.

File Header (sector 0, 800h bytes):

```
000h 4    File ID (01h,"XSP") (aka PSX backwards)
004h 2    Unknown (0001h)
006h 2    Unknown (0040h) (this is used for something...)
008h 2    Bitmap Width  (0140h)
00Ah 2    Bitmap Height (00F0h)
00Ch 4    Total number of video frames
010h 4    Number of video sectors per frame (always 8)
014h 4    Total number of video sectors, excluding audio/dummy (=NumFrames*8)
018h 1    Zero
019h 1    Sector List size (28h) (ie. each 4 frames)  ;\or zerofilled when
01Ah 28h  Sector Types (2=Video, 1=Audio, 0=Dummy)    ;/not present
042h ..   Zerofilled
7xxh ..   Unknown, maybe just garbage ...?
...  ..   Zerofilled
```

The frame rate is 15fps with 10 sectors per frame (8xVideo and either 2xAudio
or 1xAudio+1xDummy). The Video/Audio/Dummy sector arrangement does repeat each
40 sectors (aka each 4 frames):

```
vVvvvvv--vvVvvv--vvvvVv--vvvvvv-Vvvvvvv-  Video
-------A-------A-------A-------A-------A  Audio
--------D-------D-------D---------------  Dummy
V = 1st sector of video frame
v = 2nd..8th sector of video frame (or fileheader in case of sector 0)
A = Audio (each 8th sector, ie. sector 07h,0Fh,17h,1Fh,etc.)
D = Dummy (occurs after some (not all) audio sectors)
Some files have that sector arrangement stored in header[019h..041h], but
other files have that header entries zerofilled (despite of using the same
arrangement).
```

Video frames are 8 sectors (4000h-byte), first and last 8 bytes are swapped:

```
0000h 8     Last 8 bytes of BS v1 bitstream   ;\or garbage padding
0008h 3FF0h First 3FF0h of BS v1 bitstream    ;/
3FF8h 8     Footer (64bit, with squeezed BS header and other info)
The footer bits are:
0-4    5bit   Quant (00h..1Fh) (only 5bit, not 6bit)
5-15   11bit  MDEC Size in 20h-word units (80h-byte units)
16-23  8bit   Unknown (lowbits are often same as bit48 and up?)
24-31  8bit   BS ID/100h (3800h/100h)
32-47  16bit  Frame Number (0=First)
48-63  16bit  Next Sector Number (start of next video frame)
To decrypt/convert the frame to standard BS v1 format:
x=[3FF8h]                      ;get footer
[3FF8h..3FFFh]=[0000h..0007h]  ;last 8 bytes of bitstream
[0000h]=(x AND FF00FFE0h)      ;size and ID=3800h
[0004h]=(x AND 1Fh)+10000h     ;quant and version=v1
The next_sector number is usually current_sector+1 (or +2 if that would be
audio), in last frame it does point to end of file.
Bitstreams smaller than 3FF8h are garbage padded (initially some 32bit garbage
values, and in later frames leftovers from previous bitstream sectors).
```

Dummy sectors contain 800h bytes:

```
000h 4     Always FFFFFFFFh (unfortunately, this isn't a unique ID)
004h 7FCh  Garbage (zeroes, random, or even leaked ASM source code)
Dummy sectors have the same Subheader as video sectors, the leading FFFFFFFFh
could also occur in BS bitstreams or frames with garbage padding, so one must
use the sector arrangement pattern to identify dummy sectors.
```

Audio sectors are XA-ADPCM and can be filtered via Subheader, or via sector
arrangement pattern.

CDROM File Video BS Compression Versions

**STR/BS Version Summary, with popularity in percents (roughly)**

```
Version         .STR movies   .BS pictures
BS v2            60%           6%            Most games
BS v3            20%           4%            Some newer games
BS v1            15%           0.1%          Old games
BS ea            2%            - (?)         Electronic Arts titles
BS iki           0.5%          0.1%          Several games
BS fraquant      0.2%          0.1%          Rare (X-Files, Eagle One)
BS v0            0.1%          -             Rare (Serial Experiments Lain)
BS v2/v3.crypt   0.2%          -             Rare (Star Wars games)
BS iki.encrypted 0.1%          -             Rare (Panekit)
Wacwac MDEC      0.1%          -             Rare (Aconcagua)
Polygon Streams  0.x% (?)      -             Some titles
Raw MDEC         -             -             Was never used in files?
MPEG1            -             -             VCD Video CDs
None             ?%   (?)      90%           No videos or BS pictures
```

Most games can decrypt v1/v2/v3 videos (no matter which of the three versions
they are actually using), newer games do occassionally use v3 for picture
compression, but often stick with v2 for video streaming (perhaps because v3
does require slightly more CPU load; unknown if the higher CPU load has been an
actual issue, and if it has been solved in the later (more optimized)
decompressor versions) (unknown if there are other benefits like v2 having
better DC quality or better compression in some cases?).

**BS v0 (used by only one known game)**

```
v0 used by Serial Experiments Lain
```

This game is apparently using a very old and very unoptimized decoder (although
it was released in 1997, when most or all other games did already have decoders
with v1/v2/v3 support).

The v0 decoder has different header, lacks End of Frame codes, and uses Huffman
codes with different AC values than v1/v2/v3/iki.

**BS v1 (used by older games, some of them also having v2 videos)**

```
v1 used by Wipeout 2097 (MAKE.AV, XTRO*.AV)
v1 used by Viewpoint (MOVIES\*.STR) (oddly with [08h]=FirstFrame=0 and
[1Ch]=Unspecified=Nonzero) (the game also has ".str" files in
VIEW.DIR\streams, but that isn't MDEC/STR stuff)
v1 used by Ridge Racer Revolution (MOVIE\*.STR)
v1 used by Policenauts
v1 used by Final Fantasy VII (FF7)
v1? used by Tekken 2
v1/v2 used by Final Fantasy Tactics (OPEN*.STR)
v1/v2 used by Project Horned Owl (*.STR)
v1/v2 used by Gex (*.FMV)
(and probably more)
```

v1 and v2 can be decoded with the same decompressor. The only difference is
that v1 was generated with an older compressor (which did accidently store
nonsense 22bit escape codes with run=N, level=0 in the bitstream; whereas one
could as well use run+N+1 in the next code, or omit it completely if next code
is EOB).

**BS v2 (most games)**

```
v2 used by Gex - Enter the Gecko (*.STR)
v2 used by Tomb Raider (FMV\*.FMV)
v2 used by Alone (STR*\*.STR)
v2 used by Kain (*.STR)
v2 used by Fear Effect (BOOT.SID, LOGO.SID, ABGA\ABGA.FLX)
v2 used by Parasite Eve 2 (INTERx.STR, and in .CDF's eg. stage1\folder501)
v2 used by Witch of Salzburg (MOVIE\*.STR)
v2 used by Breath of Fire III (LOGO\*.STR)
v2 used by Hear it Now (MOVIE\*.STR)
v2 used by Legend of Mana (MOVIE\*.STR)
v2 used by Misadventures of Tron Bonne (STR\*.STR)
v2 used by Rayman (VIDEO\*.STR)
v2 used by Resident Evil 1 (PSX\MOVIE\*.STR)                ;\although v3 is
v2 used by Resident Evil 2 (PL0\ZMOVIE\*.STR, ZMOVIE\*.STR) ;/used in *.BSS
v2 used by Tokimeki Memorial 2 (VX*.STR)
v2 used by Spider-Man (CINEMAS\*.STR)
v2 used by Perfect Assassin (CDV\*.STR)
v2 used by Pandemonium 2 (*.STR)
v2 used by Die Hard Trilogy 2 (MOVIE\*.STR)
v2 used by Need for Speed 3 (MOVIES\*.STR) (oddly with [14h,18h]<>[20h,24h])
v2 used by Wild Arms (STR\*.STR)
v2 used by Wild Arms 2 (STR\*.STR)
v2 used by Frogger (*.STR)
v2 used by Gundam Battle Assault (XA\*.STR)
v2 used by Alundra (MOVIE\*.MOV)
v2 used by Spec Ops (file 95h,96h within BIGFILE.CAT)
v2 used by Crash Team Racing (file 1E1h..1F8h,1FAh within BIGFILE.BIG)
(and many more)
```

Same as v1, but without the compressor bug.

**BS v3 (used by some newer games, some of them also having v2 videos)**

```
v2/v3 used by Lemmings Oh No More Lemmings (ANIMS\*.STR)
v2/v3 used by Castlevania (*.STR)
v3 used by Heart of Darkness (CINE\*.STR, SETUP\*.STR)
v3 used by R-Types (MV\*.STR)
v3 used by Black Matrix (MOVIE\*.STR)
v3 used by Nightmare Creatures II (INTRO\*.STR, LEVEL*\*.STR)
(and many more)
```

Same as v2, but using Huffman compressed DC values.

**BS ea (Electronic Arts)**

Used by many EA Sports titles and several other titles from Electronic Arts:

```
Castrol Honda Superbike Racing
EA Sports Supercross 2000, 2001
Future Cop - L.A.P.D. (retail and MagDemo14: FCOPLAPD\*.WVE and *.FSV)
Hot Wheels - Turbo Racing
Jampack Vol. 2
Knockout Kings 99, 2000, 2001
Madden NFL 99, 2000, 2001, 2002, 2003, 2004, 2005 (eg. MADN00\FMVIDEO.DAT\*)
NASCAR 98, 99, 2000, 2001 (and 98 Collector's Edition, and 99 Legacy)
NASCAR Thunder 2002, 2003, 2004 and NASCAR Rumble
Nuclear Strike
Official U.S. PlayStation Magazine Demo Disc 39 (...XXX which game?)
PlayStation Underground Jampack - Winter 2000
Road Rash Jailbreak, and Road Rash 3D
Tiger Woods PGA Tour Golf, and Tiger Woods USA Tour 2001
```

Uses VLC0 and MDEC chunks (instead of STR headers), the MDEC chunks contain
standard BS v2 data, but using custom MDEC values from VLC0 chunk.

**BS fraquant**

```
X-Files (Fox Interactive/Hyperbole Studios, 1999)
Eagle One: Harrier Attack (Infogrames/Glass Ghost, 2000)
Blue's Clues: Blue's Big Musical (Mattel/Viacom/TerraGlyph, 2000)
```

This replaces the 6bit quant value by a 16bit fixed-point quant value (done by
manipulating the Quant Table instead of using QuantDC, apart from that extra
feature it's internally using normal BS v1/v2/v3 decoding).

**BS iki**

```
iki: Gran Turismo 1 (STREAM.DAT)   ;\with uncommon STR header
iki: Gran Turismo 2 (STREAM.DAT)   ;/
iki: Hot Shots Golf 2 / Everybody's Golf 2 (MagDemo31: HSG2\MINGOL2X.BIN)
iki: Legend of Legaia (MagDemo20: LEGAIA\MOV\MV2.STR)
iki: Legend of Dragoon (STR\*.IKI)
iki: Omega Boost (MOVIE\*.IKI)
iki: Um Jammer Lammy (MagDemo24: UJL\*.IKI) (retail: *\*.IKI and CM\*.IK2)
iki: plus a dozen of japanese-only titles
```

This might have been used between v2 and v3, iki is using uncommon BS headers
and LZ compressed Quant/DC values (whilst v3 is using Huffman compressed DC
values).

**Encrypted iki**

```
Panekit - Infinitive Crafting Toy Case (first 13Mbyte in PANEKIT.STR)
```

Same as normal iki, with some SWAP/ADD/XOR-encrytion in first 20h-bytes.

**Encrypted v2/v3**

```
v3.xor used by Star Wars Masters of Teras Kasi (MagDemo03: MASTERS\*.STR)
v2.xor supported (but not actually used) by Star Wars Masters (MagDemo03)
v3.swap used by Star Wars Rebel Assault II (*.STR, *.SED, Stills)
v2.swap used by Star Wars Rebel Assault II (*.STR)
v3.swap used by BallBlazer Champions (*.STR)
```

Same as normal v2/v3 with simple XOR-encryption or SWAP-encryption.

**Wacwac MDEC**

```
Aconcagua (JP) (2000 Sony/WACWAC!) (STR_01_00.STR and STR_09_01.STR)
```

Similar to v3, but uses completely different Huffman codes than BS video.

**Polygon Streaming (instead of MDEC picture streaming)**

```
Ape Escape (DEMO\*.STR, STR\*.STR, and KKIIDDZZ.HED\STR\0006h and up)
Aconcagua (most STRs are Polygon Streams, except two are Wacwac MDEC streams)
Panekit - Infinitive Crafting Toy Case (last 150Mbyte in PANEKIT.STR)
```

Polygon streams contain vertices (for textures that are stored elsewhere).
Usually needing only one sector per frame. This can be useful for animations
that were recorded from real actors. Drawbacks are more edgy graphics and lower
color depth (although that may fit in with the game engine).

CDROM File Video Polygon Streaming

**MPEG1 (on VCD Video CDs)**

MPEG1 uses I/P/B-Frames, the I-Frames may reach similar compression as BS
files. However, P-Frames and B-Frames do compress much better than BS files.

CDROM Video CDs (VCD)

MPEG1 isn't used in any PSX games, but VCDs can be viewed on SCPH-5903 consoles
(or via software decoder in nocash PSX kernel clone).

**Titles without movies**

Most PSX titles do include movies, exceptions are some early launch titles and
educational titles:

```
Ridge Racer 1 (1994)
Lightspan Online Connection CD
```

CDROM File Video BS Compression DC Values

**DC v0**

```
nnnnnnnnnn        DC Value (signed 10bit, -200h..+1FFh)
```

This is similar as v1/v2, except there is no End code for End of Frame, and the
.BS header contains two separate quant values (for Cr/Cb and Y1-Y4).

```
If output_size=NumberOfMdecCodes*2 then EndOfFrame
If BlockIsCrCb then QuantDC=DC+QuantC*400h else QuantDC=DC+QuantY*400h
```

**DC v1/v2/ea**

```
nnnnnnnnnn        DC Value (signed 10bit, -200h..+1FEh)
0111111111        End of Frame (+1FFh, that, in place of Cr)
```

This is similar as v0, except there is only one Quant value for all blocks, and
the header lacks info about the exact decompressed size, instead, compression
end is indicated by a newly added end code:

```
If DC=+1FFh then EndOfFrame
QuantDC=DC+Quant*400h
```

**DC v3**

Similar as v1/v2, but DC values (and End code) are now Huffman compressed
offsets relative to old DC, with different Huffman codes for Cr/Cb and Y1-Y4:

```
For Cr/Cb         For Y1..Y4      Offset (added to old DC of Y/Cr/Cb block)
00                100             +(00h)                      ;\
01s               00s             -(01h)*4     ,+(01h)*4      ;
10sn              01sn            -(03h..02h)*4,+(02h..03h)*4 ; required
110snn            101snn          -(07h..04h)*4,+(04h..07h)*4 ; codes
1110snnn          110snnn         -(0Fh..08h)*4,+(08h..0Fh)*4 ; for 10bit
11110snnnn        1110snnnn       -(1Fh..10h)*4,+(10h..1Fh)*4 ; range
111110snnnnn      11110snnnnn     -(3Fh..20h)*4,+(20h..3Fh)*4 ;
1111110snnnnnn    111110snnnnnn   -(7Fh..40h)*4,+(40h..7Fh)*4 ;/
11111110snnnnnnn  1111110snnnnnnn -(FFh..80h)*4,+(80h..FFh)*4 ;-11bit (!)
-                 11111110        Unused                      ;\
111111110         111111110       Unused                      ; unused
1111111110        1111111110      Unused                      ;/
1111111111        1111111111      End of Frame                ;-end code
Note: the "snnn" bits are indexing the values in right column,
with s=0 for negative values, and s=1 for positive values.
```

The decoding works as so (with oldDcXxx=0 for first macroblock):

```
If bits=1111111111 then EndOfFrame
If BlockIsCr then DC=DecodeHuffman(HuffmanCodesCbCr)+oldDcCr, oldDcCr=DC
If BlockIsCb then DC=DecodeHuffman(HuffmanCodesCbCr)+oldDcCb, oldDcCb=DC
If BlockIsY1234 then DC=DecodeHuffman(HuffmanCodesY1234)+oldDcY, oldDcY=DC
If older_version AND DC>=0 then QuantDC=Quant*400h or (DC)       ;\requires
If older_version AND DC=NumBlocks then EndOfFrame
QuantDC = DCbuf[BlockNo]*100h + DCbuf[BlockNo+NumBlocks]
```

As shown above, the Hi- and Lo-bytes are stored in separate halves of the DC
buffer (which may gain better compression).

CDROM File Video BS Picture Files

**BS Picture Files**

A couple of games are storing single pictures in .BS files:

```
Alice in Cyberland (ALICE.PAC\*.BS)
BallBlazer Champions (BBX_EXTR.DAT\Pics\*) (SWAP-encrypted)
Bugriders: The Race of Kings (*\*.BS and STILLS\MENUS.BS\*)
Die Hard Trilogy 2 (DATA\*.DHB, DATA\DH*\L*\*.DHB, MOVIE\*.DHB)
Dino Crisis 2 (PSX\DATA\ST*.DBS\*)
Duke Nukem (MagDemo12: DN_TTK\*)
Final Fantasy VII (FF7) (MOVIE\FSHIP2*.BIN\*) (BS v1)
Gran Turismo 1 (retail TITLE.DAT\* and MagDemo10/15) (in BS iki format)
Jet Moto 2 (MagDemo03: JETMOTO2\*)
Mary-Kate and Ashley Crush Course (MagDemo52: CRUSH\SCRN\*.BS)
Mat Hoffman's Pro BMX (MagDemo48: MHPB\STILLS.BIN\*) (with width/height info)
NFL Gameday '99 (MagDemo17: GAMEDAY\FE\GD98DATA.DAT)
Official U.S. PlayStation Magazine Demo Disc 01-02 (MENU\DATA\*.BSS)
Official U.S. PlayStation Magazine Demo Disc 03-54 (MENU.FF\*)
Parasite Eve 2 (INIT.BS, and within .HED/.CDF archives)
Resident Evil 1 (PSX\STAGE*\*.BSS, headerless archive, 8000h-byte align)
Resident Evil 2 (COMMON\BSS\*.BSS, headerless archive, 10000h-byte align)
Rugrats (MagDemo19: RUGRATS\*)
Rugrats Studio Tour (MagDemo32: RUGRATS\DATA\RAW\*.BS)
Starwars Demolition (MagDemo39+MagDemo41: STARWARS\SHELL\.BS+.TBL\*)
Star Wars Rebel Assault 2 (RESOURCE.000\Stills\*) (SWAP-encrypted)
Ultimate Fighting Championship (MagDemo38: UFC\CU00.RBB\390h..3E2h)
Vigilante 8 (MagDemo09: EXAMPLE\*)
Witch of Salzburg (PICT\PIC*\*.BS and DOT1 archives *.BSS, *.DAT, *.BIN)
X-Files (LOGOS\*.BS and GRAPHICS\GRAPHICS.BIN and GRAPHICS\PACKEDBS.BIN\*)
You Don't Know Jack 2 (MagDemo41: YDKJV2\RES\UI\*.BS)
```

Note: Those .BS files are usually hidden in custom file archives.

**BS Picture Resolution**

Movies have Width/Height entries (in the .STR header). Raw .BS picture files
don't have any such information. However, there are ways to guess the correct
resolution:

```
For BS iki format, use resolution from iki header (eg. Gran Turismo 1)
For MHPB\STILLS.BIN, there's width/height in chunk headers
Count the number of blocks (EOB codes) during Huffman decompression
Divide that number by 6 to get the number of Macroblocks
Search matches for Height=NumBlocks/Width with Width>=Height and Remainder=0
If Height=300..400, assume double H-resolution, repeat with Width/2>=Height
And/or use a list of known common resoltions (see below examples)
Search arrangements with many similar colors on adjacent macroblocks
```

Common resolutions are:

```
Blocks Pixels   Example
F0h    256x240  any?
12Ch   320x240  Resident Evil 2 (COMMON\BSS\*.BSS)
1E0h   512x240  Demo Disc 03-54 (MENU.FF\*), Duke Nukem (MagDemo12)
1E0h   640x192  Less common than above (but used by Witch of Salzburg)
4B0h   640x480  Vigilante 8 (MagDemo09), Jet Moto 2 (MagDemo03)
var    random   Witch of Salzburg has various random resolutions
iki    ikihdr   Gran Turismo 1 has A0hxA0h and odd size (!) E8hx28h
?      ?        Final Fantasy VII (FF7)
?      ?        Ultimate Fighting Championship (UFC\CU00.RBB\3B7h..3E2h)
118h   320x224  Alice in Cyberland (most files; or two such as panorama)
230h   ?        Alice in Cyberland (AD_115.BS and AD_123A.BS)
```

Some other possible, but rather unlikely results would be:

```
C8h    320x160  Unlikely for pictures (but used for STR videos, eg. Alone)
F0h    320x192  Unlikely for pictures (but used for STR videos, eg. Wipeout)
1E0h   384x320  Very unlikely to see that vertical resolution on PSX
```

Witch of Salzburg has many small .BS files with various uncommon resolutions
(most of them are bundled with 16-byte .TXT files with resolution info).

**Extended BS with Width/Height**

Starwars Demolition (MagDemo39: STARWARS\SHELL\DEMOLOGO.BS+RESOURCE.TBL\*)

Starwars Demolition (MagDemo41: STARWARS\SHELL\DEMOLOGO.BS+RESOURCE.TBL\*)

```
000h 2    Width  (280h)       ;\extra header
002h 2    Height (1E0h)       ;/
004h 2    MDEC Size/4 (after huffman decompression) (rounded to 80h/4 bytes)
006h 2    File ID (3800h)
008h 2    Quantization step/factor (0000h..003Fh, for MDEC "DCT.bit10-15")
00Ah 2    Version (1, 2, or 3) (2 is most common)
00Ch ...  Huffman compressed data blocks (Cr,Cb,Y1,Y2,Y3,Y4, Cr,Cb,Y1,Y2..)
```

CDROM File Video Polygon Streaming

**Ape Escape - Polygon Streaming**

Used by Ape Escape (Sony 1999) (DEMO\*.STR and some STR\*.STR files and
KKIIDDZZ.HED\STR\0006h and up).

The files start with zerofilled sectors (without STR headers), followed by
sectors with STR headers with [00h]=0160h, [02h]=8001h (same values as for
MDEC), but with [10h..1Fh]=zero (without resolution/header info). And the data
at [20h] starts with something like 14h,00h,03h,FFh,2Ah,02h,00h,00h.

That data seems to consist of polygon coordinates/attributes that are rendered
as movie frames. The texture seems to be stored elsewhere (maybe in the .ALL
files that are bundled with some .STR files).

**Panekit - Polygon Streaming**

Panekit STR seems to use Polygon Streaming (except 1st some Megabytes are
MDEC).

**Aconcagua - Polygon Streaming**

Aconcagua STR does use Polygon Streaming (except first+last movie are MDEC).

**Cyberia (1996) (TF\STR\*.STR)**

Cyberia is using Software-rendering for both movies and in-game graphics. That
is, PSX hardware features like MDEC, GTE, and GPU-Polygons are left all unused,
and the GPU is barely used for transferring data from CPU to VRAM.

The STR header for software-rendered movie frames looks as so:

```
000h 2    STR ID   (0160h)
002h 2    STR Type (0002h=Custom, Software rendering)
004h 2    Sector number within current Frame (0..num-1)
006h 2    Number of Sectors in this Frame    (varies)
008h 4    Frame Number (1=First)
00Ch 4    Frame Size in Bytes/4 (note: first frame in MAP*.STR is quite big)
010h 2    Rendering Width  (0140h)
012h 2    Rendering Height (00C0h)
014h 0Ch  Unknown (zerofilled or random garbage)
020h 7E0h Custom data for software rendering
```

Note: First sector of First frame does usually have byte[22h]=88h (except
FINMUS.STR). The Custom data part is often have garbage padding (such like
ASCII strings with "c2str" command line tool usage instructions).

**Croc 1 (CUTS\*.AN2)**

Probably cut-scenes with polygon animations. The files seem to contain
2300h-byte data frames (plus XA-ADPCM sectors inserted here and there).

```
000h 4     Number of remaining frames
...  22FCh Unknown data (zeropadded if smaller)
```

```
_______________ Unknown Streaming Data (Polygons or whatever) ________________
```

**Custom STR - 3D Baseball (BIGFILE.FOO)**

This is used for several files in 3D Baseball (BIGFILE.FOO):

```
BIGFILE.FOO\0151h\0005h,0009h,000Fh,0017h,001Bh, 02E5h,02E9h,..,0344h,0348h
BIGFILE.FOO\0152h\0186h,018Ch,0192h,0198h)
BIGFILE.FOO\0153h\029Ah,02A0h,02A6h,02ACh)
```

The files contain some kind of custom streaming data, with custom STR header,
and data containing increasing/decreasing bytes... maybe non-audio waveforms?

```
000h 2    STR ID   (0160h)
002h 2    STR Type (0001h=Custom)
004h 2    Sector number within current Frame (always 0)
006h 2    Number of Sectors in this Frame    (always 1)
008h 4    Frame Number (1=First)
00Ch 4    Frame Size (6FAh or 77Ah, sometimes 17Ah or 1FAh or 20Ah)
010h 2    Unknown (280h, or sometimes 300h or 340h)
012h 2    Frame Time (0=First, increases with step [19h], usually +5 or +7)
014h 2    Unknown (280h, or sometimes 300h or 3C0h, or 0)
016h 1    Frame Time (same as [012h] AND FFh)
017h 1    Unknown (0 or 1)
018h 1    Unknown (40h, or 80h, or C0h)
019h 1    Duration? (5 or 7, or sometimes less, step for Frame Time)
01Ah 1    Unknown (3, or less in last some frames)
01Bh 5    Zerofilled
020h 7E0h Data (increasing/decreasing bytes... maybe non-audio waveforms?)
```

**Army Men Air Attack 2 (MagDemo40: AMAA2\*.PMB)**

```
000h 2     STR ID   (0160h)
002h 2     STR Type (0000h=Custom)
004h 2     Sector number within current Frame (0..2)
006h 2     Number of Sectors in this Frame    (always 4) (3xSTR + 1xADPCM)
008h 4     Frame Number (1=First)
00Ch 4     Frame Size? (800h, despite of having 3 sectors with 7E0h each?)
010h 2     Unknown (00h or 01h)
012h 2     Unknown (A3h or ABh ... 6Ch or 7Bh ... or 43h or 49h)
014h 2     Sector number within current Frame (0..2) (same as [004h])
016h 0Ah   Zerofilled
020h 7E0h  Data (polygon streaming or so?)
```

Note: The .PMB file is bundled with a .PMH file, which might contain header
info?

**Bits Laboratory games (Charumera, and True Love Story series)**

```
Charumera                  ENDING.XA     (with dummy/zero data)
True Love Story            TLS\MULTI.XA  (with nonzero data)
True Love Story 2          TLS2\ENDING.STR and TLS2\MULTI.XA
True Love Story Fan Disc            ;\probably use that format, too
True Love Story: Remember My Heart  ;/(not verified)
```

The STR headers have STR ID=0160h and STR Type=0001h, STR header[10h..1Fh]
contains nonsense BS video info (with BS ID=3800h, although there isn't any BS
data in the actual data part at offset 20h and up).

The files do mainly contain XA-ADPCM sectors, plus some STR sectors in non-MDEC
format. Unknown if that STR sectors are separate channels, or if they are used
in parallel with the XA-ADPCM channel(s).

Unknown what the STR sectors are used for (perhaps Polygon Streaming, audio
subtitles, or simple garbage padding for unused audio sectors). In some files,
the STR sectors appear to be just dummy padding (STR header plus zerofilled
data area).

**Nightmare Project: Yakata**

This game has normal MDEC Streams, and Special Streams in non-MDEC format (eg.
Disc1, File 0E9h-16Eh and 985h-B58h), perhaps containing Polygon Streams or
whatever.

There are two channels (file=1/channel=00h-01h), each channel contains data
that consists of 5 sectors per frame (1xHeader plus 4xData). The sectors have
STR ID=0160h, and STR Type as follows:

```
0000h=Whatever special, channel 0 header (sector 0)
0400h=Whatever special, channel 1 header (sector 1)
0001h=Whatever special, channel 0 data   (sector 2,4,6,8)
0401h=Whatever special, channel 1 data   (sector 3,5,7,9)
```

**Eagle One: Harrier Attack STR files**

```
\*.STR            MDEC movies  ;\BS fraquant (except, demo version
\DATA*\*.STR      MDEC movies  ;/            on MagDemo31 uses mormal BS v2)
\DATA*\M*\L*.STR  Multi-language TXT files with STR header on each sector
\DATA*\M*\I*.STR  unknown binary data (whatever and SPU-ADPCM)
\LANGN.STR        unknown binary data (whatever)
```

All of the above have STR Type=8001h (but only the MDEC movies have BS ID
3800h; the MDEC movies start with 13 zerofilled sectors that are all zeroes
without any STR/BS headers).

CDROM File Audio Sample Sets VAB and VH/VB (Sony)

**VAB vs VH/VB**

```
.VAB  contains VAB header, and ADPCM binaries   ;-all in one file
.VH   contains only the VAB header              ;\in two separate files
.VB   contains only the ADPCM binaries          ;/
```

PSX Perfect Assassin has some v7 .VH/.VB's (in \DATA.JFS:\SND\*.*)

PSX Resident Evil 2, COMMON\DATA\*.DIE (contains .TIM+.VAB badged together)

PSX Spider-Man, CD.HED\l2a1.vab is VAB v5 (other VABs in that game are v7)

PSX Tenchu 2 (MagDemo35: TENCHU2\VOLUME.DAT\5\* has VAB v20h, maybe a typo)

**VAB Header (VH)**

```
0000h 4       File ID ("pBAV")
0004h 4       Version (usually 7) (reportedly 6 exists, too) (5, 20h exists)
0008h 4       VAB ID (usually 0)
000Ch 4       Total .VAB filesize in bytes (or sum of .VH and .VB filesizes)
0010h 2       Reserved (EEEEh)
0012h 2       Number of Programs, minus 1 (0000h..007Fh = 1..128 programs)
0014h 2       Number of Tones, minus? (max 0800h?) (aka max 10h per program)
0016h 2       Number of VAGs, minus? (max 00FEh)
0018h 1       Master Volume (usually 7Fh)
0019h 1       Master Pan    (usually 40h)
001Ah 1       Bank Attribute 1 (user defined) (usually 00h)
001Bh 1       Bank Attribute 2 (user defined) (usually 00h)
001Ch 4       Reserved (FFFFFFFFh)
0020h 800h    Program Attributes 10h-byte per Program 00h..7Fh   (fixed size)
0820h P*200h  Tone Attributes 200h-byte per Program 00h..P-1  (variable size)
xx20h 200h    16bit VAG Sizes (div8) for VAG 00h..FFh            (fixed size)
xx20h (...)   ADPCM data (only in .VAB files, otherwise in separate .VB file)
```

Program Attributes (10h-byte per Program, max 80h programs)

```
000h 1      tones        Number of Tones in the Program (Yaroze: 4) (uh?)
001h 1      mvol         Master Volume   (Yaroze: 0..127)
002h 1      prior                        (Yaroze: N/A)
003h 1      mode                         (Yaroze: N/A)
004h 1      mpan         Master Panning  (Yaroze: 0..127)
005h 1      reserved0
006h 2      attr                         (Yaroze: N/A)
008h 4      reserved1
00Ch 4      reserved2
```

Tone Attributes (20h-byte per Tone, max 10h tones per Program)

```
000h 1      prior        Tone Priority   (Yaroze: 0..127, 127=highest)
001h 1      mode         Mode            (Yaroze: 0=Normal, 4=Reverberation)
002h 1      vol          Tone Volume     (Yaroze: 0..127)
003h 1      pan          Tone Panning    (Yaroze: 0..127)
004h 1      center       Centre note (in semitone units) (Yaroze: 0..127)
005h 1      shift        Centre note fine tuning         (Yaroze: 0..127)
006h 1      min          Note limit minimum value     (Yaroze: 0..127)
007h 1      max          Note limit maximum value     (Yaroze: 0..127)
008h 1      vibW                                      (Yaroze: N/A)
009h 1      vibT                                      (Yaroze: N/A)
00Ah 1      porW                                      (Yaroze: N/A)
00Bh 1      porT                                      (Yaroze: N/A)
00Ch 1      pbmin        Max? value for downwards pitchbend  (Yaroze: 0..127)
00Dh 1      pbmax        Max value for upwards pitchbend     (Yaroze: 0..127)
00Eh 1      reserved1
00Fh 1      reserved2
010h 2      ADSR1        Attack,Decay    (Yaroze: 0..127,0..15)
012h 2      ADSR2        Release,Sustain (Yaroze: 0..127,0..31)
014h 2      prog         Program number that tone belongs to (Yaroze: 0..127)
016h 2      vag          VAG number                          (Yaroze: 0..254)
018h 8      reserved
```

**VAB Binary (VB) (ADPCM data) (to be loaded to SPU RAM)**

This can contain max 254 "VAG files" (maybe because having two (?) reserved
8bit numbers?).

Sony wants the total size of the ADPCM data to be max 7E000h bytes (which would
occupy most of the 512Kbyte SPU RAM, leaving little space for the echo buffer
or additional effects).

Note: The "VAG files" inside of VAB/VB are actually raw SPU-ADPCM data, without
any VAG file header. The first 10h-byte ADPCM block is usually zerofilled.

CDROM File Audio Other Formats

```
__________________________ .SQ .HD .HD (SSsq/SShd) ___________________________
```

This is a newer Sony format from 1999 (resembling the older .SEQ .VH .VB
format).

Used by Alundra 2, Ape Escape, Arc the Lad 3, Koukidou Gensou - Gunparade
March, Omega Boost, PoPoLoCrois Monogatari II, The Legend of Dragoon, Wild Arms
2.

```
.SQ Sequence Data (with ID "SSsq")
.HD Voice Header  (with ID "SShd")
.BD Voice Binary  (raw SPU-ADPCM, same as .VB)
```

**Sequence Data (*.SQ)**

```
000h 2       Unknown (always 64h)
002h 2       Unknown (always 1E0h)
004h 1?      Unknown (varies)
005h 7       Zerofilled
00Ch 4       ID "SSsq"
010h 10h*10h Unknown Table
110h ..      Unknown Data
```

**Voice Header (*.HD)**

```
000h 4     Size of the .HD file itself
004h 4     Size of the corresponding .BD file
008h 4     Zero
00Ch 4     ID "SShd"
010h 1Ch*4 Offsets to data (or FFFFFFFFh=None)
080h ..    Data
```

**Voice Bonary (*.BD) (same as .VB files)**

```
000h ..    SPU-ADPCM data (usually starting with zerofilled 10h-byte block)
```

```
____________________________ DNSa/PMSa/FNSa/FMSa _____________________________
```

There are four four file types:

```
"DNSa"  (aka SouND backwards)         ;sequence data
"PMSa"  (aka SaMPles backwards)       ;samples with small header
"FMSa"  (aka SaMples-F... backwards)  ;samples with bigger header   ;\Legacy
"FNSa"  (aka SouNd-F... backwards)    ;whatever tiny file           ;/of Kain
```

Used by several games (usually inside of BIGFILE.DAT):

```
Akuji (MagDemo18: AKUJI\BIGFILE.DAT\*) (DNSa,PMSa)
Gex 2 (MagDemo08: GEX3D\BIGFILE.DAT\*) (DNSa)
Gex 3: Deep Cover Gecko (MagDemo20: G3\BIGFILE.DAT\*) (DNSa,PMSa)
Legacy of Kain 2 (MagDemo13: KAIN2\BIGFILE.DAT\*) (DNSa)
Legacy of Kain 2 (MagDemo26: KAIN2\BIGFILE.DAT\*) (DNSa,PMSa,FNSa,FMSa)
Walt Disney World Racing Tour (MagDemo35: GK\BIGFILE.DAT\*) (DNSa,PMSa)
```

Note: The exact file format does reportedly differ in each game.

**"PMSa"  (aka SaMPles backwaords)**

```
000h 4     ID "PMSa"
004h 4     Total Filesize
008h 8     Zerofilled
010h ..    SPU-ADPCM data (usually starting with zerofilled 10h-byte block)
```

**"DNSa"  (aka SouND backwards)**

```
000h 4      ID "DNSa"   ;aka SND backwards
004h 2      Offset from DNSa+4 to 8-byte entries (can be odd)
006h 1      Unknown (3)
007h 1      Number of 8-byte entries   (N1)
008h 1?     Number of 10h-byte entries (N2)
...  ..     Unknown (..)
...  N1*8   Whatever 8-byte entries
...  N2*10h Whatever 10h-byte entries
...  ..     ... circa 40h 4-byte entries...?
...  ..     Unknown (..)
...  ..     Several blocks with ID "QESa" or "QSMa"  ;supposedly MIDI-style?
```

**"FNSa"  (aka SouNd-F... backwards)**

These are whatever tiny files (with filesize 1Ch or 2Ch).

```
000h 4     ID "FNSa"
...  ..    Unknown
```

**"FMSa"  (aka SaMples-F... backwards)**

```
000h 4     ID "FMSa"
008h ..    Unknown..
...  ..    SPU-ADPCM data (usually starting with zerofilled 10h-byte block)
```

```
____________________________________ AKAO ____________________________________
```

There a several games that have sound files with ID "AKAO".

```
XXX does that include different AKAO formats... for Samples and Midi?
```

AKAO is also used in several streaming movies:

CDROM File Video Streaming Audio

```
___________________________________ Others ___________________________________
```

Alone in the Dark IV has MIDB and DSND chunks (which contain sound files).

**See also**

The page below does mention several PSX sound formats, plus some open source
& closed source tools for handling those files.

github.com/loveemu/vgmdocs/blob/master/Conversion_Tools_for_Video_Game_Music.md

CDROM File Audio CD-DA Tracks

The eleven .SWP files in Wipeout 2097 seem to be CD-DA audio tracks.

The one TRACK01.WAV in Alone in the Dark, too?

Other than that, tracks can be accessed via TOC instead of filenames.

CDROM File Archives with Offset and Size

**Crash Team Racing (retail: BIGFILE.BIG, and MagDemo30/42: KART\SAMPLER.BIG)**

```
000h 4     Zero
004h 4     Number of Files (260h)
010h N*8   File entries
...  ..    Zeropadding to 800h byte boundary
...  ..    File Data
```

File Entries:

```
000h 4   Fileoffset/800h (increasing)
004h 4   Filesize in bytes
```

Filetypes in the archive include...

```
MDEC v2 STR's  (file 1E1h..1F8h,1FAh)
TIM textures  (file 01FBh..0200h and others)
empty files   (file 01F9h and others)
small archives with named entries (file B5h,124h,125h,126h and others)
stuff with date string and names (file 253h,256h)
there seem to be no nested BIG files inside of the main BIG file
```

**Black Matrix (*.DAT)**

```
000h 4    Number of files (N) (eg. 196h)
004h 4    Unknown (always 0Bh) (maybe sector size shift?)
008h N*4  File List
...  ..   Zeropadding to 800h-byte boudary
...  ..   File Data
```

File List entries:

```
000h 2    Offset/800h (increasing)
002h 2    Size/800h (can be zero)
```

The "files" might actually contain small child folders? Or the whole stuff is
just some kind of data structure, not an actual file system archive.

**Charumera (*.CVF)**

```
000h N*4  File List
...  ..   Zeropadding to 800h-byte boundary
...  ..   File Data area
File List entries:
000h 1    Size/800h   (8bit)
001h 3    Offset/800h (24bit, increasing)
```

**Vs (MagDemo03: THQ\*) has .CDB archives**

```
000h  N*8   File List
...   ..    Zeropadding to 800h-byte boundary
...   ..    File Data
...   ..    Garbage padding (can be several megabytes tall)
```

File List entries:

```
000h 2     Offset/800h (increasing)
002h 2     Size/800h (same as below, rounded up to sector units)
004h 4     Size in bytes
```

Note: The files may consist of multiple smaller files badged together (eg.
DISPLAY.CDB contains several TIMs per file).

Some CDB archives have garbage padding at end of file: BIN.CDB (2Kbyte),
CSEL.CDB (80K), DISPLAY.CDB (70K), MOT.CDB (10648Kbyte). Maybe that's related
to deleted files in the Vs demo version and/or to updating the CDB archives
with newer/smaller content, but without truncating the CDB filesize
accordingly.

**Monster Rancher (MagDemo06: MR_DEMO\*.OBJ)**

**Deception III Dark Delusion (MagDemo33: DECEPT3\K3_DAT.BIN)**

**Star Trek Invasion (MagDemo34: STARTREK\STARTREK.RES)**

Similar as .CDB archives (but with 32bit offset, and without duplicated size).

```
000h  N*8   File List
...   4     File List end marker (00000000h)
...   ..    Garbage padding to 800h-byte boundary
...   ..    File Data
```

File List entries:

```
000h 4     Offset/800h (increasing)
004h 4     Size in bytes (often zero; for unused file numbers)
```

Note: Files are usually padded with 0..7FFh bytes to 800h-byte boundary, but
STARTREK.RES does append additional 800h-byte padding after each file (ie.
800h..FFFh padding bytes in total).

**Einhander (MagDemo08: BININDEX.BIN/BINPACK0.BIN/BINPACK1.BIN)**

```
000h X*4  File List for BINPACK0.BIN                   ;\
...  ..   Zeropadding                                  ; BINPACK0
410h ..   Unknown (some/all of it looks like garbage)  ;/
800h Y*4  File List for BINPACK1.BIN                   ;\
...  ..   Zeropadding                                  ; BINPACK1
C10h ..   Unknown (some/all of it looks like garbage)  ;/
```

File List entries:

```
000h 2    Offset/800h in BINPACK0.BIN or BINPACK1.BIN
002h 2    Size/800h
```

**SO98 Archives (NBA Shootout '98, MagDemo10: SO98\..*.MDL *.TEX *.ANI *.DAT)**

Resembles .BZE (in terms of duplicated size entry).

```
000h 4     Number of Files
004h 4     Size of File Data area (total filesize-N*0Ch-8)
008h N*0Ch File List
...  ..    File Data area
```

File List entries:

```
000h 4   Offset (zerobased, from begin of File Data area)
004h 4   Size in bytes
008h 4   Size rounded to mutiple of 4-bytes
```

.DAT contains .TIM .SEQ .VB .VH and nested SO98 archives

.MDL contains whatever (and empty 0-byte files)

.TEX contains .TIM

.ANI contains whatever

**Gran Turismo 1 (MagDemo10: GT\*.DAT) GT-ARC**

**Gran Turismo 1 (MagDemo15: GT\*.DAT) GT-ARC**

**Gran Turismo 2 (GT2.VOL\arcade\arc_fontinfo) GT-ARC**

```
000h 0Ch   ID "@(#)GT-ARC",00h,00h
00Ch 2     Content Type (8001h=Compressed, 0001h=Uncompressed)
00Eh 2     Number of Files (eg. 0Fh)
010h N*0Ch File List
...  ..    File Data area
File List entries:
000h 4     Offset in bytes (increasing, unaligned)
004h 4     Compressed File Size (can be odd)  ;\both same when uncompressed
008h 4     Decompressed File Size             ;/(ie. when [00Ch]=0001h)
```

MESSAGES.DAT, SOUND.DAT, TITLE.DAT which are completely uncompressed GT-ARC's.
Most other GT-ARC's contain LZ compressed files. In case of CARINF.DAT it's
vice-versa, the files are uncompressed, but the GT-ARC itself is LZ compressed
(the fileheader contains 00h,"@(#)GT-A",00h,"RC",00h,00h; it can be detected
via those bytes, but lacks info about decompressed size).

CDROM File Compression GT-ZIP (Gran Turismo 1 and 2)

**O.D.T. (MagDemo17: ODT\*.LNK and ODT\RSC\NTSC\ALLSOUND.SND and nested LNK's)**

**Barbie Explorer (MagDemo50: BARBIEX\*.STR and nested therein)**

```
000h 4     Number of Files (N)
004h N*8   File List
...  ..    File Data area
```

File List entries:

```
000h 4     Offset in bytes (increasing, 1/4-byte? aligned)
004h 4     File Size in bytes (usually N*4, TXT's in ODT are padded as so)
```

Quirk: Instead of rounding only Offsets to N*4 byte boundary, all Sizes are
rounded to N*4 bytes (eg. TXT files in ODT\RSC\NTSC\GFILES.LNK\01 with odd
number of characters are are zeropadded to N*4 bytes).

Note: The PADBUG archives in Final Fantasy VIII (FF8) are very similar (but
have a different alignment quirk).

**Bust A Groove (MagDemo18: BUSTGR_A\*.DFS and BUSTGR_B\*.DFS) (DFS)**

**Bust-A-Groove 2 (MagDemo37: BUSTAGR2\BUST2.BIN\*) (main=DF2 and child=DFS)**

Same as in O.D.T. with extra "DFS_" ID at start of file.

```
000h 4     ID "DFS_" (with align 4) or "DF2_" (with align 800h)
004h 4     Number of Files (N)
008h N*8   File List
...  ..    File Data area
File List entries:
000h 4     Fileoffset in bytes (4-byte or 800h-byte aligned, increasing)
004h 4     Filesize in bytes (can be odd, eg. in BUSTGR_A\SELECT.BPE\*)
```

The game does use uncompressed DFS archives (in .DFS files) and compressed DFS
archives (in .BPE files):

CDROM File Compression BPE (Byte Pair Encoding)

The game does also use .DBI files (which contain filenames and other strings,
whatever what for).

**Monaco Grand Prix Racing Simulation 2 (MagDemo24: EXE\*\*.SUN)**

Same as DFS, but with Total Filesize instead of "DFS_".

```
000h 4     Total used filesize (excluding zeropadding to 2EE000h)
004h 4     Number of Files (N)
008h N*8   File List
...  ..    File Data area
...  (..)  In some files: Zeropadding to 2EE000h (3072Kbytes)
```

File Entries:

```
000h 4     Offset (increasing, 4-byte aligned, see note)
004h 4     Filesize in bytes (can be odd in Monaco)
```

Note: The alignment in Monaco is a bit glitchy:

```
If (Size AND 3)=0 then NextOffset=Offset+Size             ;Align4
If (Size AND 3)>0 then NextOffset=Offset+Size+Align800h   ;Align800h
Namely, Monaco has files with Size=3BC5h.
```

The first file starts with unknown 32bit value, followed by "pBAV".

**Rollcage (MagDemo19: ROLLCAGE\SPEED.IMG) (2Mbyte)**

**Rollcage Stage II (MagDemo31: ROLLCAGE\SPEED.IDX+SPEED.IMG) (3Kbyte+9Mbyte)**

**Sydney 2000 (MagDemo37: OLY2000\DEMO.IDX+DEMO.IMG) (1Kbyte+2Mbyte)**

```
Rollcage 1 uses a single IMG file that contains both directory and data:
000h 4     Header offset (0)          ;\
004h 4     Header size (10h+N*10h)    ; this seems to be a File List entry
008h 4     Header size (10h+N*10h)    ; for the header itself
00Ch 4     Zero                       ;/
010h N*10h File List                  ;-File List for actual files
...  ..    Zeropadding to 800h-byte boundary
...  ..    File Data area
Number of files is "IMG[04h]/10h" (minus 1 for excluding the header itself)
The other titles have seaparate IDX and IMG files for directory and data:
SPEED.IDX = Directory (N*10h bytes File List with offsets into SPEED.IMG)
SPEED.IMG = File data
Number of files is "Filesize(SPEED.IDX)/10h"
```

File List entries:

```
000h 4     Fileoffset in bytes (800h-byte aligned, increasing)
004h 4     Filesize in bytes
008h 4     When compressed:   GT20 Header [004h] (decompressed size)
When uncompressed: Same as filesize
00Ch 4     When compressed:   GT20 Header [008h] (overlap, usuallly 3, or 7)
When uncompressed: Zero
```

The compression related entries allow to pre-allocated the decompression buffer
(without needing to load the actual GT20 file header), and then load the
comprssed file to the top of the decompression buffer.

CDROM File Compression GT20 and PreGT20

**Ultimate 8 Ball (MagDemo23: POOL.DAT) (5.5Mbyte)**

```
000h 4      Number of Entries
004h N*0Ch  File List
...  ..     Zeropadding to 800h-byte boundary
...  ..     File Data area
File List entries:
000h 4      Unknown (random/checksum?)
004h 4      File Offset (800h-byte aligned, increasing)
008h 4      File Size in bytes
```

Notes: The LAST file isn't zeropadded to 800h-byte boundary. The File List
includes some unused entries (all 0Ch-bytes zerofilled).

**BIGFOOL - 3D Baseball (BIGFILE.FOO)**

```
000h N*0Ch  File List                                   (154h entries)
...  N*4    Filename Checksums (?)                      (154h entries)
...  ..     Zerofilled (padding to 800h-byte boundary)
...  ..     File Data area
```

The 1st list entry describes the current directory itself, as so:

```
000h 4      Number of entries (including the 1st entry itself)
004h 4      Offset/800h (always 0, relative from begin of directory)
008h 4      Type        (always 3=Directory)
```

Further list entries are Files or Subdirectories, as so:

```
000h 4      For Files: Size in bytes, for Directories: Number of entries
004h 4      Offset/800h (from begin of current directory, increasing)
008h 4      Type        (0=File, 3=Directory)
```

**Spec Ops - Airborne Commando (BIGFILE.CAT and nested CAT files therein)**

```
000h 4     File ID                                 (always 01h,02h,04h,08h)
004h 4     Maybe Version?                          (always 01h,00h,01h,00h)
008h 4     Header Size (18h+N*8+ArchiveNameLength)    ;eg. 4ECh
00Ch 4     Sector Alignment (can be 4 or 800h)
010h 4     Number of Files (N)                        ;eg. 99h
014h 4     Length of Archive Name (including ending 00h)
018h N*8   File entries (see below)
...  ..    Archive Name, ASCII, terminated by 00h     ;eg. "bigfile.dir",00h
...  ..    Zeropadding to Sector Alignment boundary
...  ..    File Data
```

File Entries:

```
000h 4   Fileoffset (with above Sector Alignment) (increasing)
004h 4   Filesize in bytes
```

Filetypes in the archive include...

```
nested CAT archives (file 07h,0Ch,11h,16h,1Bh,20h,25h,etc)
empty files         (file 3Eh,5Ah-5Fh,62h-67h,etc)
MDEC v2 STR's       (file 95h-96h)
XA-ADPCM's          (inside of nested CAT, in file94h\file*)
```

There are "strings" in some files, are those filenames, eg. Icon_xxx etc?

**Hot Shots Golf 2 (retail: DATA\F0000.BIN, MagDemo31/42: HSG2\MINGOL2.BIN)**

The DATA directory is 13800h bytes tall. But, the PSX kernel supports max 800h
bytes per ISO directory (so the kernel can only see the first 33 files in that
directory). The game isn't actually trying to parse the ISO directory entries,
instead, it's using the 2800h-byte offset/size list in F0000.BIN to access the
directory content:

```
0000h+N*4 1     Sector MM in BCD      ;\based at 00:06:00 for file 0
0001h+N*4 1     Sector SS in BCD      ; (unused files are set to 00:00:00)
0002h+N*4 1     Sector FF in BCD      ;/
0003h+N*4 1     Size MSB in hex (Size/800h/100h)
2000h+N   1     Size LSB in hex (Size/800h AND FFh)
2800h     (..)  Data area for file 001h..590h (demo version only)
```

Retail Version disc layout:

```
Sector 000ADh  SCUS_944.76       ;exefile     ;\
Sector 00130h  SYSTEM.CNF                     ; iso root folder
Sector 00131h  DATA (sub-folder, 27h sectors) ;/
Sector 00158h  (padding)                      ;-padding to 00:06:00
Sector 001C2h  DATA\F0000.BIN    ;file 000h   ;\
Sector 001C7h  DATA\F0001.BIN    ;file 001h   ;
...                                           ; iso data folder
Sector 00B54h  DATA\F0032.BIN    ;file 020h   ;
Sector 00B9Bh  DATA\F0033.BIN    ;file 021h   ;  ;\files exceeding the 800h
...            ...                            ;  ; directory size limit, not
Sector 1A0C9h  DATA\F1907.BIN    ;file 773h   ;/ ;/accessible via PSX kernel
Sector 1AAF1h  DUMMY.BIN                      ;-iso root folder (padding)
```

Demo version in Playstation Magazine is a bit different: It has only two large
.BIN files (instead of hundreds of smaller .BIN files). The directory is stored
in first 2800h bytes of MINGOL2.BIN. The MM:SS:FF offsets are numbered as if
they were located on sector 00:06:00 and up (to get the actual location:
subtract 00:06:00 and then add the starting sector number of MINGOL2.BIN).

```
Sector 07148h  HSG2\MINGOL2.BIN  ;file 000h..590h  ;demo binary files
Sector 0AC1Dh  HSG2\MINGOL2X.BIN ;file 76Ch        ;demo streaming file(s)
Sector 0B032h  HSG2\SCUS_944.95  ;exefile          ;demo exe file
```

Note: File 000h is a dummy entry referring to the 2800h-byte list itself
(retail file 000h has offset=00:06:00 but size=0, demo file 000h has offset and
size set to zero). File 001h is the first actual file (at offset=00:06:05, ie.
after the 2800h-byte list)

**Threads of Fate (MagDemo33: TOF\DEWPRISM.HED+.EXE+.IMG)**

The demo version uses "Virtual Sectors" in HED+EXE+IMG files. Apart from that,
the format is same as for the "Hidden Sectors" in retail version:

CDROM File Archives in Hidden Sectors

**WWF Smackdown (MagDemo33: TAI\*.PAC\*, and nested therein)**

These "PAC " files are found in the main archives (which use a separate archive
format, with ID "DPAC").

```
000h 4     ID ("PAC ")                                        ;\
004h 4     Number of files (N)                                ; Header
008h N*8   File List                                          ;/
...  ..    File Data area                                     ;-Data area
```

File List entries:

```
000h 2     File ID (inreasing, but may skip numbers, ie. non-linear)
002h 3     File Offset (increasing, relative to begin of Data area)
005h 3     File Size
```

Bug: TAI\C.PAC\EFFC\0001h has TWO entries with File ID=0002h.

**Tyco R/C Racing (MagDemo36: TYCO\MAINRSRC.BFF)**

```
000h 4     Unknown (1)
004h 4     Filelist Offset          (800h)
008h 4     Filelist Size (N*8+4)    (7ACh)
...  ..    Padding to 800h-byte boundary (see note)
800h 4     Number of files (N)      (F5h)
804h N*8   File List
...  ..    Padding to 800h-byte boundary (see note)
...  ..    File Data area
```

File List entries:

```
000h 4     File Offset in bytes (increasing, 800h-byte aligned)
004h 4     File Size in bytes
```

Padding Note: Padding after headers & files is weirdly done in two steps:

```
Step 1: Zeropadding to 200h-byte boundary    (first 0..1FFh bytes)
Step 2: Garbagepadding to 800h-byte boundary (last 0..600h bytes)
```

**Team Buddies (MagDemo37: BUDDIES\BUDDIES.DAT)**

```
000h 2     ID ("BD")
002h 2     Number of files (N)
004h N*8   File List
...  ..    Zeropadding to 3000h
3000h ..   File Data area
```

File List entries:

```
000h 4     File Offset/800h (increasing)
004h 4     File Size in bytes
```

**Gundam Battle Assault 2 (DATA\*.PAC, and nested therein)**

```
000h 4     ID ("add",00h)
004h 4     Fixed (4)
008h 4     Offset to File List (usually/always 20h)
00Ch 4     Number of Files (N)
010h 4     Fixed (10h)
014h 0Ch   Zerofilled
020h N*10h File List
...  ..    File Data area
```

File List entries:

```
000h 4     Offset (increasing, 4-byte aligned)  ;\or both zero
004h 4     Size (can be odd)                    ;/
008h 4     Unknown (0) (or 00h,10h,11h,20h,30h,40h when Offset/Size=0)
00Ch 4     Zero (0)
```

**Incredible Crisis (MagDemo38: IC\*.CDB)**

```
000h 4     Number of files (N)
004h N*4   File List
...  ..    Zeropadding to 800h-byte boundary
```

File List entries:

```
000h 2     File Offset/800h (increasing)
002h 2     File Size/800h
```

**Ape Escape Sound Archive (MagDemo22:KIDZ\KKIIDDZZ.HED\DAT\1Bh-1Dh,49h-53h,..)**

**Ape Escape Sound Archive (MagDemo44:KIDZ\KKIIDDZZ.HED\DAT\1Bh-1Dh,4Fh-59h,..)**

```
000h 5*4   File Sizes   (can be odd) (can be 0 for 2nd and 5th file)
014h 5*4   File Offsets (28h and up, increasing by sizes rounded to N*10h)
028h ..    File Data area (first file usually/always contains "SShd")
```

**Ultimate Fighting Championship (MagDemo38: UFC\CU00.RBB)**

```
0000h 4    ID "siff"                                  ;\Header
0004h 4    Total Filesize (DADB1Ch)                   ;/
0008h 4    ID "RSRC"                                  ;\
000Ch 4    String Size (70h)                          ; ASCII string
0010h 70h  String "RC ver1.0 Copyright",...,00h       ;/
0080h 4    ID "RIDX"                                  ;\
0084h 4    File List Size     (1F78h) (3EFh*8)        ; Directory
0088h N*8  File List (Offset, Size1)                  ;/
2000h 4    ID "EXIX"                                  ;\
2004h 4    Extended List Size (FBCh)  (3EFh*4)        ; Extended
2008h N*4  Extended List (Size2)                      ;/
2FC4h 4    ID "GAP0"                                  ;\Alignment Padding
2FC8h 4    Padding Size (2Ch)                         ; (so that next chunk
2FCCh 2Ch  Padding (1Ah-filled)                       ;/starts at boundary-8)
2FF8h 4    ID "RBB0"                                  ;\
2FFCh 4    File Data area Size (DAAB1Ch)              ; Data area
3000h ..   File Data area                             ;/
```

File List entries (RIDX):

```
000h 4     File Offset (increasing, 4-byte aligned, from ID "RBB0" plus 8)
004h 4     File Size in bytes (can be odd)
```

Extended List entries (EXIX):

```
000h 4     File Size in bytes (always the same size as in RIDX chunk)
```

**Ultimate Fighting Championship (MagDemo38: UFC\CU00.RBB\183h,37Bh..3EBh)**

```
000h 4     ID "OIFF"                                  ;\Header
004h 4     Total Filesize                             ;/
008h 4     ID "TIMT" or "ANMT"                        ;\
00Ch 4     Size (N*4)                                 ; Directory Table
010h N*4   File List (offsets from begin of Data ID+8);/
...  4     ID "TIMD" or "ANMD"                        ;\
...  4     Data Area size (SIZ) (Filesize-18h-N*4)    ; Data area
...  SIZ   Data Area                                  ;/
```

**E.T. Interplanetary Mission (MagDemo54: MEGA\MEGA.CSH+.BIN)**

```
MEGA.CSH:
000h N*0Ch File List
MEGA.BIN:
000h ..    File Data area
```

File List entries:

```
000h 4     Offset (in MEGA.BIN file, 800h-byte aligned, increasing)
004h 4     Unknown (32bit id/random/checksum/whatever)
008h 4     Filesize in bytes
```

**Driver 2 The Wheelman is Back (MagDemo40: DRIVER2\SOUND\*\*)**

```
000h 4     Number of entries (1 or more)
004h N*10h File List
...  ..    File Data area (.VB aka SPU-ADPCM)
File List entries:
000h 4     Offset from begin of Data area, increasing
004h 4     Filesize in bytes
008h 4     Unknown (0 or 1)
00Ch 4     Unknown (AC44h, 0FA0h, 2EE0h, 2710h, 2B11h, 3E80h, 1F40h, etc.)
Note: Above AC44h might 44100Hz, or just file number 44100 decimal?
```

**Thrasher: Skate and Destroy (MagDemo27: SKATE\ASSETS\*.ZAL) (Z-Axis)**

**Dave Mirra Freestyle BMX (MagDemo36: BMX\ASSETS\*.ZAL) (Z-Axis)**

**Dave Mirra Freestyle BMX (MagDemo46: BMX\ASSETS\*.ZAL) (Z-Axis)**

```
000h 4     ID (always 2A81511Ch)
004h 0Ch   Zerofilled
010h 1     Unknown (1)
011h 1     Compression Flag for all files (00h=Uncompressed, 80h=Compressed)
012h 2     Number of files (bit0-13?=N, bit14=Unknown, can be set)
014h N*0Ch File List, 12 bytes/entry      ;
<a id="cdromfilearchiveswithsize"></a>
## CDROM File Archives with Size

**Disney-Pixar's Monsters, Inc. (MagDemo54: MINC\*.BZE)**

```
000h 4     Zero (0)
004h 4     Type/ID (27100h=160000, 2BF20h=180000, 30D40h=200000 decimal)
008h 4     Number of files
00Ch N*0Ch File List
...  ..    Zeropadding to 7FCh
7FCh 4     Checksum (32bit sum of SIGN-EXPANDED bytes at [000h..7FBh])
...  ..    File Data
```

File List entries:

```
000h 4     File Type/ID or so (roughly increasing, eg. 1,3,6,5,7,8,9,A,B)
004h 4     Filesize in bytes
008h 4     Filesize rounded up to multiple of 800h bytes
```

**Bugs Bunny: Lost in Time (MagDemo25: BBLIT\*.BZZ) (without extra entry)**

**The Grinch (MagDemo40: GRINCH\*.BZZ) (with extra entry)**

Resembles .BZE, but without the Type entry in Header.

```
000h 4     Fixed 1 (maybe version, or compression flag)
004h (4)   Unknown (000xxxx0h)   ; always size 10h
Dino Crisis 2 --> usually size 20h
Dino Crisis 2 --> sometimes size 10h (eg. SC24.DAT, SC48.DAT, WEP_*.DAT)
```

File List entries:

```
File List entries, type 0 and 7:
000h 4     Type (0=Data (or .BS pictures), 7=CompressedData)
004h 4     Size
008h 4     RAM Addresss (80000000h..801FFFFFh)
00Ch 4     Zero
010h (10h) Zerofilled
File List entries, type 1 and 2 and 8:
000h 4     Type (1=Bitmap, 2=Palette, 8=CompressedBitmap)
004h 4     Size (see below Size Notes)
008h 2     VRAM Address X     (0..3FFh)
00Ah 2     VRAM Address Y     (0..1FFh) (or 280h in Dino 2 ST703.DAT)
00Ch 2     Width in halfwords (1..400h)
00Eh 2     Height             (1..200h)
010h (10h) Zerofilled
File List entries, type 3 and 4:
000h 4     Type (3=VoiceHeader("Gian"), 4=VoiceData(SPU-ADPCM))
004h 4     Size
008h 4     SPU Address (0..7FFF0h)
00Ch 2     Unknown (0..7)  ;\usually both same (or val1=0, val2>0)
00Eh 2     Unknown (0..7)  ;/
010h (10h) Zerofilled
File List entries, type 5 (eg. ME*.DAT):
000h 4     Type (5=Unknown... maybe Midi-style or so)
004h 4     Size
008h 4     Load Address (0, or on next 4-byte boundary after previous file)
00Ch 2     Unknown (0..2)  ;\always both same
00Eh 2     Unknown (0..2)  ;/
010h (10h) Zerofilled
File List entries, type 6 and 9:
The EXE code does also accept type 6 and 9 (type 6 is handled same as
type 0, and type 9 is ignored), but the actual archives don't seem to
contain any files with those types.
File List entries, padding for unused entries:
000h 10h   Type ("dummy header    ")
010h (10h) Zerofilled
```

Size Notes:

```
Bitmaps and Palettes can have following sizes:
Width*Height*2                       ;normal case
Width*Height*2 + Align(1000h)        ;eg. Dino Crisis 1 DOOR*.DAT
Width*Height*2 + Align(800h)         ;eg. Dino Crisis 2 DOOR27.DAT
CompressedBitmaps can have following sizes in compressed form:
Less than Width*Height*2             ;normal case
Less than Width*Height*2 + 1000h     ;eg. Dino Crisis 2 M_RESULT,ST002.DAT
CompressedBitmaps can have following sizes after decompression:
Width*Height*2 + 8                   ;normal case
Width*Height*2 + Align(1000h?) + 8   ;eg. Dino Crisis 2 M_RESULT,ST002.DAT
```

Note: Dino Crisis DEMO version (MagDemo28: DINO\TRIAL.DAT) does also contain
"dummy header" DAT archives (but, unlike as in retail version, they are hidden
somewhere inside of the headerless 14Mbyte TRIAL.DAT archive).

Type 7 and 8 are using LZSS compression:

CDROM File Compression LZSS (Dino Crisis 1 and 2)

Apart from LZSS, Type 4 is using SPU-ADPCM compression, and some Type 0 files
contain .BS compressed pictures (eg. Dino Crisis 2 PSX\DATA\ST*.DBS\*).

<a id="cdromfilearchiveswithfolders"></a>
## CDROM File Archives with Folders

There are several ways to implement folder-like directory trees:

```
- Using multiple archive files nested within each other
- Using filenames with path string (eg. "path\filename.ext")
```

Other than that, below are special formats with dedicated folder structures.

**Archives with Folders**

CDROM File Archive HUG/IDX/BIZ (Power Spike)

CDROM File Archive TOC/DAT/LAY

CDROM File Archive WAD (Doom)

CDROM File Archive WAD (Cardinal Syn/Fear Effect)

CDROM File Archive DIR/DAT (One/Viewpoint)

CDROM File Archive HED/CDF (Parasite Eve 2)

CDROM File Archive IND/WAD (MTV Music Generator)

CDROM File Archive GAME.RSC (Colonly Wars Red Sun)

CDROM File Archive BIGFILE.DAT (Soul Reaver)

CDROM File Archive FF8 IMG (Final Fantasy VIII)

CDROM File Archive FF9 IMG (Final Fantasy IX)

CDROM File Archive GTFS (Gran Turismo 2)

CDROM File Archive Nightmare Project: Yakata

CDROM File Archive FAdj0500 (Klonoa)

See also: PKG (a WAD.WAD variant with folders)

**Perfect Assassin (*.JFS)**

```
Overall File Structure
JFS for root                                   ;\
JFS for 1st folder   ;\these are dupicated,    ; header with complete list
JFS for 2nd folder   ; also stored in below    ; of all file/folder names
JFS for 3rd folder   ; data area               ;
etc.                 ;/                        ;/
JFS for 1st folder, plus data for files in that folder  ;\
JFS for 2nd folder, plus data for files in that folder  ; data area
JFS for 3rd folder, plus data for files in that folder  ;
etc.                                                    ;/
```

JFS Headers (0Ch+N*14h bytes)

```
00h 4     ID "JFS",00h
04h 4     Size in bytes (for root: including nearby child JFS's)
08h 4     Number of file/folder entries in this folder (N)
0Ch N*14h File/Folder entries
```

File Entries (with [10h].bit31=0):

```
00h 12  "FILENAME.EXT" (or zeropadded if shorter)
0Ch 4   Offset from begin of JFS in data area (without any alignment)
10h 4   Size in bytes, plus 00000000h=File
```

Folder Entries (with [10h].bit31=1):

```
00h 12  "DIRNAME.EXT" (or zeropadded if shorter)
0Ch 4   Offset to child JFS in data area
10h 4   Offset to child JFS in header area, plus 80000000h=ChildFolder
```

The JFS format is almost certainly unrelated to IBM's "Journaled File System".

**Alone in the Dark The New Nightmare (FAT.BIN=Directory, and DATA.BIN=Data)**

```
FAT.BIN:
00h 2     Number of folders (X) (43h)
02h 2     Number of files   (Y) (8F0h)
04h 4     Unknown               (1000h)
08h X*10h Directory Entry 0000h..X-1 (entry 0000h is named "ROOT")
..  Y*10h File Entry 0000h..Y-1
DATA.BIN:
00h ..    File Data area
```

Directory Entries (10h bytes):

```
00h 8    Name (terminated by 00h if less than 8 chars)
08h 2    First Subdirectory number (0001h and up, 0000h would be root)
0Ah 2    Number of Subdirectories  (0000h=None, if so above is usually 00FFh)
0Ch 2    First File number         (0000h and up)
0Eh 2    Number of files           (0000h=None, if so above is usually 00FFh)
```

File Entries (10h bytes):

```
00h 8    Name (terminated by 00h if less than 8 chars)
08h 4    Offset/800h to DATA.BIN
0Ch 4    Size in bytes (when compressed: decompressed size+02000000h)
```

Compressed files (in LEVELS\*\* with Size.bit25=1) can be decompressed as so:

CDROM File Compression Darkworks

The files include some TIM images, WxH images, binary files, and chunks:

CDROM File Archive Darkworks Chunks (Alone in the Dark)

**Interplay Sports Baseball 2000 (MagDemo22: BB2000\* HOG.DAT and HOG.TOC)**

```
HOG.TOC:
000h N*14h Folder/File List (starting with root folder)
HOG.DAT:
000h ..    File Data (referenced from HOG.TOC)
```

Folder entries:

```
000h 1     Type      ("D"=Directory)
001h 8     Name      ("FILENAME", zeropadded if shorter) (or "\" for root)
009h 3     Extension (usually zero for directories)
00Ch 4     Folder Offset/14h in .TOC file (aka 1st child file/folder index)
010h 4     Folder Size/14h                (aka number of child files/folders)
```

File entries:

```
000h 1     Type      ("F"=File)
001h 8     Name      ("FILENAME", zeropadded if shorter)
009h 3     Extension ("EXT", zeropadded if shorter)
00Ch 4     File Offset/800h in .DAT file (increasing)
010h 4     File Size in bytes
```

**Tenchu 2 (MagDemo35: TENCHU2\VOLUME.DAT)**

```
000h 4     Unknown (demo=A0409901h, us/retail=A0617023h)
004h 4     Unknown (0h)
008h 4     Number of files   (F) (demo=B7h, us/retail=1294h)
00Ch 4     Number of folders (D) (demo=0Fh, us/retail=3Eh)
010h D*8   Folder List
...  ..    Zerofilled (padding to 800h-byte boundary)
800h F*10h File List
...  ..    Zerofilled (padding to 800h-byte boundary)
...  ..    File Data area
```

Folder List entries:

```
000h 4     Folder ID (Random, maybe folder name checksum?)
004h 4     First file number in this folder (0=first, increasing)
```

File List entries:

```
000h 4     File Offset/800h
004h 4     File Size in bytes
008h 4     Folder ID (same as Parent Folder ID in Folder List)
00Ch 4     File ID (Random, maybe file name checksum?)
```

**Blasto (MagDemo10: BLASTO\BLASTO.DAT and BLASTO\BLASTO.LFS)**

```
LFS:
000h N*18h File/Folder List
DAT:
000h ..    File data
```

File entries (with [10h]=Positive):

```
000h 10h   Filename ("FILENAME.EXT", zeropadded)
010h 4     Offset in bytes, in BLASTO.DAT
014h 4     Size in bytes
```

Folder entries (with [10h]=Negative):

```
000h 10h   Foldername ("DIRNAME", zeropadded)
010h 4     Index to first child (at Offset=(-Index)*18h in BLASTO.LFS)
014h 4     Zero
```

Folder end marker (with [00h]=00h or 80h):

```
000h 1     End marker, at end of root & child directories (00h or 80h)
001h 17h   Unknown
```

**Twisted Metal 4 (MagDemo30: TM4DATA\*.MR and *.IMG)**

These are relative small archives with hundreds of tiny chunks (with registry
style Symbol=Value assignments), and a few bigger chunks (with .mod .vab .bit
.clt files).

```
000h 4     Fixed ID (CCCC0067h)
004h ..    Root Folder (with Name="Root",00h,FDh,FDh,FDh)
Folder Chunk format:
000h 1     Length of Name (including 4-byte padding)
001h 1     Number of Child Folders
002h 2     Number of Child Files
004h ..    Name ("name",00h, CDh-padded to 4-byte boundary; Root=FDh-padded)
...  ..    Child File(s)
...  ..    Child Folder(s)
File Chunk format:
000h 1     Length of filename (including 4-byte padding)
001h 1     Filetype           (see below)
002h 2     Array Size         (or FFFFh for non-array filetypes)
004h 4     Filesize (SIZ)     (including 4-byte padding)
008h 4     Decompressed Size  (or 0=Uncompressed)
00Ch ..    Filename/Symbol    ("name.ext",00h, CDh-padded to 4-byte boundary)
...  SIZ   Data/Value         (CDh-padded to 4-byte boundary)
```

Some filenames have trailing non-ascii characters, for example:

```
"AXEL.MR\display\resolution\r3\Groups\Combined_Polyset",1Ah,01h,04h,00h
"CALYPSO.MR\display\resolution\r3\Groups\Combined_Polyset",A8h,00h, CDh,CDh
```

Filetypes:

```
Typ Size  Expl.
02h var   Text String (terminated by 00h, garbage-or-00h-padded to 4-byte)
03h 8     Misc (*.IMG\textures\*)                          ;\
03h 20h   Misc (*.MR\display\resolution\r*\Groups\*)       ; these are all
03h var   Misc (*.MR\display\resolution\*List)             ; filetype=03h
03h file  Misc (*.MR\display\*.bit) (same as type=0Ch)     ;/
04h 4     Numeric 32bit
05h 8     Numeric 4x16bit point (X,Y,Z,CDCDh)
06h file  Model (*.mod) (DOTLESS archive with model data)
0Bh 4     Numeric 32bit repeat,light
0Ch file  XYWH Bitmap/Palette (*.bit, *.clt) (in GAME.IMG, MENU\menu)
0Dh 4     Numeric 32bit delay
0Eh 4     Numeric 32bit color (maybe 24bit RGB plus 00h-padding?)
0Fh 10h   Whatever 10h-byte "pos"
10h file  Sony .VAB file (*.vab)
12h N*1   Array? (with Arraysize=0014h)
16h N*??  Array Text Strings (with Arraysize=0001h) (in MAIN.MR\worlds)
1Ah N*10h Array Guns,startpoints (RCCAR.MR\*, NEON.MR\world)
1Bh 4     Numeric 2x16bit (X,Y) (in MENU.MR)
1Ch N*4   Array lloc (in MENU.MR\menu\screens) (with Arraysize=04h or 1Fh)
25h 8     Whatever 8-byte (in GAME.MR\dualShock)
26h N*8   Array CollideArray (in GAME.MR\dualShock) (with Arraysize=4 or 6)
```

Compressed Data (when [008h]<>0):

```
000h ..    ZLIB compressed data (usually starting with big-endian 789Ch)
(compression is used for almost all files, except VERY small ones)
```

CDROM File Compression ZIP/GZIP/ZLIB (Inflate/Deflate)

CDROM File Archive TOC/DAT/LAY

Used in PSX Lightspan Online Connection CD (CD.TOC, CD.DAT, CD.LAY).

```
CD.TOC contains File/Folder entries
CD.DAT contains the actual File bodies
CD.LAY devkit leftover (list of filenames to be imported from PC to TOC/DAT)
```

The .TOC file doesn't have any file header, it does just start with the first
File/Folder folder entry in root directory. The directory chains with
file/folder entries are sorted alphabetically, each chain is terminated by a
final entry which does point to parent directory.

**File Entries**

```
00h 4   Offset to next Sibling File/Folder/Final entry
04h 4   Filesize in bytes
08h 4   Filedata Offset/800h in CD.DAT
0Ch ..  Filename (ASCII, terminated by 00h)
... ..  Padding to 4-byte boundary (garbage)
```

**Folder Entries (with Filesize=FFFFFFFFh)**

```
00h 4   Offset to next Sibling File/Folder/Final entry
04h 4   Filesize (always FFFFFFFFh in Folder entries)
08h 4   Offset to first File/Folder in Child directory
0Ch ..  Name of Child directory (ASCII, terminated by 00h)
... ..  Padding to 4-byte boundary (garbage)
```

**Final Entries (with Name="",00h and Filesize=FFFFFFFxh)**

```
00h 4   Offset to next Sibling entry (00000000h=None)
04h 4   Filesize (FFFFFFFFh in child folders, FFFFFFFEh in root folder)
08h 4   Offset to first File/Folder in Parent directory (or to self for root)
0Ch 1   Empty Name ("",00h)
0Dh 3   Padding to 4-byte boundary (garbage)
```

CDROM File Archive WAD (Cardinal Syn/Fear Effect)

**.WAD files (Cardinal Syn/Fear Effect)**

This format exists in two version:

```
Old format: Without leading Header Size entry (Cardinal Syn MagDemo03: SYN\*)
New format: With leading Header Size entry    (eg. Fear Effect)
```

Version detection could be done somewhat as so:

```
if [04h]*1Ch+8 >= [00h] then OLD version
```

For loading the Old Header, one must guess the max header size (4000h should
work, in fact, most or all Old Headers seem to be max 800h), or load more data
on the fly as needed.

```
000h (4) Header Size (including folder/type/file directories) (new version)
...  4   Number of Folders
...  ..  Folder List (root)
...  ..  Type Lists  (for each folder)
...  ..  File Lists  (for each folder\type)
...  ..  File Data   (for each folder\type\file)
Folder List Entries:
000h 14h Folder name (ASCII, zeropadded)
014h 4   Offset to Type List
018h 4   Number of different Types in this folder
Type List Entries:
000h 4   Offset to file entries (of same type, eg. .TIM files)
004h 4   Number of file entries (of same type, eg. .TIM files)
008h 4   Sum of all Filesizes with that type
00Ch 4   Group Type (0000000xh)
File List entries (Files within Type list):
000h 14h Name (ASCII, terminated by 00h, plus garbage padding)
014h 4   Offset to File Data  (seems 4-byte aligned... always?)
018h 4   File Type (000x00xxh)
01Ch 4   Filesize in bytes  ;\maybe compressed/uncompressed, or rounded,
020h 4   Filesize in bytes  ;/always both same
```

Note: The Type List for one folder can contain several entries with same Group
Type, eg. Fear Effect GSHELLE.WAD\CREDIT has 5 type list entries (with
2xGroup0, 2xGroup1, 1xGroup2).

The Type List, Group Type and File Type stuff seems to have no function, apart
from faster look up (the types are also implied in the filename extension).
Except, Fear Effect .RMD .VB .VH have some unknown stuff encoded in File Type
bit16-19.

Group Type is usually 0 (except for .TIM .VB .VH .MSG .SPU .OFF).

The .TIM .VB .VH .SEQ files are using standard Sony file formats. The .PMD file
seems to be also Sony standard (except that it contains a 00000000h prefix,
then followed by the 00000042h PMD format ID).

**Cardinal Syn Types**

```
.BGD FileType=00000001h
.ANM FileType=00000003h
.TIM FileType=00000004h (GroupType=1)
.SP2 FileType=00000005h
.PMD FileType=00000007h
.MOV FileType=00000008h
.SPR FileType=0000000Ch
.PVT FileType=0000000Dh
.DB  FileType=0000000Eh
.VH  FileType=00000010h (GroupType=1) ;only in OLDER demo version MagDemo03
.VB  FileType=00000011h (GroupType=1)
.MSG FileType=00000012h (GroupType=1) (actually, this is .TIM, too)
.KMD FileType=00000013h
.OC  FileType=00000018h
.EMD FileType=00000019h
.COL FileType=0000001Bh
.CF  FileType=0000001Ch
.CFB FileType=0000001Dh
.CL  FileType=0000001Eh
.SPU FileType=0000001Fh (GroupType=1) ;added in newer demo version MagDemo09
.OFF FileType=00000020h (GroupType=1) ;added in newer demo version MagDemo09
.RCT FileType=00000021h               ;added in newer demo version MagDemo09
```

**Fear Effect Types**

```
.TIM FileType=00000000h (GroupType=1)
.RMD FileType=000x0001h
.DB  FileType=00000002h
.ANM FileType=00000003h
.SYM FileType=00000004h
.VB  FileType=000x0008h (GroupType=1)
.SEQ FileType=00000010h
.BIN FileType=00000012h
.SFX FileType=00000013h
.VH  FileType=000x0014h (GroupType=2)
.TM  FileType=00000015h
.NRM FileType=00000017h
.WPD FileType=00000018h
```

CDROM File Archive Darkworks Chunks (Alone in the Dark)

**Alone in the Dark The New Nightmare (FAT.BIN\*)**

The files in FAT.BIN are using a messy chunk format: There's no clear ID+Size
structure. There are 7 different chunk types (DRAM, DSND, MIDB, G3DB, VRAM,
WEAP, HAND), each type requires different efforts to compute the chunk size.

**VRAM Chunks (Texture/Palette) (in various files)**

```
000h 4     ID "VRAM"
004h 4     With Tags (0=No, 1=Yes) (or "DRAM" when empty 4-byte chunk)
008h (4)   Number of Tagged items (N) (0=None)  ;\only when [4]=1
00Ch N*10h Tagged Item(s)                       ;/(not so in LEVELS\*\VIEW*)
...  ..    Scanline Rows(s)
...  4     End code (00000000h) (aka final Scanline Row with width=0)
Tagged Item(s) (IMG, LINE, GLOW, FLARE, BALLE, BLINK, COURIER7, BMP_xxx):
000h 8     Tag (ASCII, if less than 8 chars: terminate by 00h, pad by FDh)
008h 8     Data
Scanline Row(s) (bitmap scanlines and palette data):
000h 4     Header (bit0-8=Width, bit10-18=Y, bit20-29=X, bit9,19,30,31=?)
004h W*2   Data (Width*2 bytes, to be stored at VRAM(X,Y))
```

Empty VRAM chunks can be either 4 or 10h bytes tall. The 4-byte variant is
directly followed by another chunk name (eg. "VRAMDRAM"), the 10h-byte variant
contains four words ("VRAM",WithTags=1,NumTags=0,EndCode=0).

Note: Some files contain two VRAM chunks (eg. LEVELS\*\VIEW*).

**G3DB Chunks (Models) (in various files)**

```
000h 4   ID "G3DB"
004h 4   Unknown (0, 1, or 2)
008h 4   Size of Data part (SIZ)
00Ch 4   Number of List entries (eg. 6 or 0Ah or 117Ch) (N)
010h SIZ Data (supposedly LibGDX models in G3DB format)
...  N*4 List
```

**DRAM Chunks (Text and Binary data) (in various files)**

```
000h 4   ID "DRAM"
004h 4   Size of Data part (SIZ) (can be odd)
008h 4   Number of List entries (N)
00Ch SIZ Data (raw data, and/or tags TEXT, SPC, COURIER7)
...  N*4 List
```

**WEAP Chunks (Weapons) (in WEAPON\*\*)**

```
000h 4   ID "WEAP"
004h 4   Size-10h?
008h ..  Data
```

Followed by VRAM and DSND chunks.

**HAND Chunks (Hands) (in LEFTHAND\*\HAND*)**

```
000h 4   ID "HAND"
004h 4   Size-0Ch?  (18h)
008h 8   Zerofilled
010h 4x4 Unknown (FFh,FF00h,xF0000h,FF3232h,FF6464h,FFDCDCh,FFFFFFh,..)
020h 4   Unknown (0, 1, 101h, or 201h)
```

Followed by VRAM and G3DB chunks.

**MIDB Chunks (Music) (in MIDI\*\*)**

```
000h 4      ID "MIDB"
004h 1      Unknown (0 or 1)
005h 1      Number of SEQ blocks              (1..4) (S)
006h 1      Number of Unknown 80h-byte blocks (1..2) (U)
007h U*80h  Unknown Blocks (mostly FFh-filled)
...  S*Var  SEQ Block(s)
...  ..     VAB Block
SEQ Blocks:
Probably some MIDI sequence data, similar to Sony's .SEQ format.
000h 4      Size-0Ch (can be odd)
004h 8      Name (zeropadded if less than 8 chars)
00Ch 4      ID "DSEQ"    ;\Size
010h ..     Data         ;/
VAB Blocks:
Apparently inspired on Sony's .VAB format (but the ID is spelled other way
around, Lists have variable size, and entries have different format).
000h 4      ID "VABp"  (this is: not pBAV, unlike normal .VAB files)
004h 4      Unknown (0)
008h 4      Unknown (0)
00Ch 4      Size of all SPU-ADPCM samples (SIZ)
010h 2      Number of List 1 entries (N1)
012h 2      Number of List 2 entries (N2)
014h 2      Number of Samples        (N3)
016h 6      Unused? (CCh-filled)
01Ch N1*10h List 1
...  N2*10h List 2
...  N3*2   Sample Size List (size of each SPU-ADPCM sample)
...  SIZ    SPU-APDCM Sample(s)
```

**DSND Chunks (Sounds) (in various files)**

```
000h 4   ID "DSND"
004h 4   Unknown (0 or 2)
008h ..  VAB Block (same as in MIDB chunks, see there)
```

**Note**

DRAM and MIDB chunks can have odd size; there isn't any alignment padding, so
all following chunks can start at unaligned locations.

CDROM File Archive HED/CDF (Parasite Eve 2)

Crazy Data Format (CDF) is used by Parasite Eve 2, on Disc 1 and 2:

1: PE_Disk.01 Stage0.hed Stage0.cdf Stage1.cdf Stage2.cdf Stage3.cdf Inter0.str

2: PE_Disk.02 Stage0.hed Stage0.cdf Stage3.cdf Stage4.cdf Stage5.cdf Inter1.str

**STAGE0.HED and STAGE0.CDF**

This uses separate header/data files. The directory is stored in STAGE0.HED:

```
0000h 78h   Streaming List (03h entries, 28h-bytes each, all entries used)
0078h 1B00h File List (360h entries, 8 bytes each, all entries used)
1B78b 8     File List End Code (FFFFFFFFh,FFFFFFFFh)
```

The actual data for the files (and audio stream) is stored in STAGE0.CDF.

**STAGE1.CDF .. STAGE5.CDF**

```
0000h 800h  Root: Folder List (100h entries, 8-byte each, unused=zeropadded)
0800h ..    1st Folder (File/Streaming List and Data)
...   ..    2nd Folder (File/Streaming List and Data)
...   ..    etc.
```

Folder List entries:

```
000h 4  Folder ID (usually N*100+1 decimal, increasing, eg. 101,201,301,etc.)
004h 4  Folder Size/800h (of whole folder, with File/Stream List and Data)
The Folder List ends with unused/zeropadded entries with ID/Size=00000000h.
```

Folder format:

```
0000h 510h  File List      (A2h entries, 8-bytes each, unused=zeropadded)
0510h 4     Zero           (padding to decimally-minded offset 1300 aka 514h)
0514h 2D0h  Streaming List (12h entries, 28h-bytes each, unused=zeropadded)
07E4h 1Ch   Zero           (padding to end of sector)
0800h ...   Data (for Files, Audio streams, and sometimes also Movie streams)
```

**File List entries (in STAGE0 and STAGE1-5)**

```
000h 4  File ID (increasing, eg. 0,1,2,3,4,etc.) (or 99) (or N*100+x)
004h 4  File Offset/800h in in .CDF (from begin of current Folder)
```

For STAGE0, file list ends with ID/Offset=FFFFFFFFh at end of HED file. For
STAGE1-5, file list ends with unused/zeropadded entries with
ID/Offset=00000000h.

The filesize can be computed as "NextOffset-CurrOffset" (at 800h-byte
resolution). Whereas, "NextOffset" can be:

```
The offset of next File in File List (same as CurrOffset for 0-byte files)
The offset of next Audio stream in Streaming List
The offset of next Movie stream in Streaming List (if it's in .CDF, not .STR)
The size of the current Folder (for STAGE1-5)
The size of the whole .CDF file (for STAGE0)
```

For STAGE1-5, audio streams are usually stored at the end of folder (after the
files). However, for STAGE0, audio streams are oddly inserted between file21000
and file30100.

**File Chunks (for files within File List)**

Most CDF files in STAGE0 and STAGE1-5 do contain one or more chunks with
10h-byte chunk headers (this can be considered as an additional filesystem
layer, with the chunk data being the actual files).

```
000h 1  Chunk Type (see below)
001h 1  End Flag (01h=More Chunks follow, FFh=Last Chunk)
002h 2  Unknown (usually 800h, sometimes 500h or 600h)
(eg. 500h in stage0\file30301\chunkX)
(eg. 600h in stage1\folder1201\file0\chunkXYZ)
004h 4  Chunk Size/800h
008h 4  Unknown (usually zero) (or 80xxxx00h in Chunk Type 0 files?)
00Ch 4  Zero (0)
010h .. Data (Chunk Size-10h bytes)
```

Chunk Types:

```
00h=Room package            .pe2pkg
01h=Image                   .pe2img
02h=CLUT                    .pe2clut
04h=CAP2 Text               .pe2cap2
05h=Room backgrounds        .bs
06h=SPK/MPK music program   .spk  ;stereo/mono, sound/music, single/multiple?
07h=ASCII text              .txt     (eg. stage0\20101..20132)
;Reportedy also (but wrong):
;60h=Sounds                  .pe2snd  (but nope, that's wrong, see below)
;60h is a MDEC movie from Streaming List (unrelated to File List chunks),
;60h is 20h-byte .STR header each 800h-bytes (occurs in "stage1\folder501")
```

There are some chunkless files:

```
stage0\40105...40198 are raw hMPK files without chunks
stage0\11000, 20213, 20214, 20300, .., 660800 and 900000 are empty 0-byte
```

**Streaming List Movie entries (stream type 1)**

```
000h 2    Stream Type (0001h=Movie)
002h 2    Unknown (8000h or 0000h)
004h 4    Offset/800h in current Folder of .CDF file ;0
00Ch 2    Unknown (0000h)
00Eh 2    Stream ID (increasing, usually starting at 64h aka 100 decimal)
010h 2    Stream sub.ID (usually 0, increases +1 upon multiple same IDs)
012h 2    Picture Width  (0140h = 320 decimal)
014h 2    Picture Height (00F0h = 224 decimal)
016h 2    Unknown (0000h)
018h 2    Unknown (0000h or 0018h)   maybe 24bpp or 24fps
01Ah 2    Unknown (73Ah or 359h or 3DCh)  (Size? but it's slighty too large?)
01Ch 6    Unknown (zero)
022h 2    Unknown (0 or 1) (often 1 when [024h]>0, but not always)
024h 2    Movie number in INTERx.STR, 1 and up? (or 0=Movie is in STAGEx.CDF)
026h 2    Unknown (0 or 1)
```

The size of movie streams in .CDF can be computed in similar fashion as for
File List entries (see there for details).

The size of movie streams in .STR cannot be computed easily (the next stream
isn't neccassarily stored at the next higher offset; even if it's within same
folder). As workaround, one could create a huge list with all streams from all
Folders in all STAGEx.CDFs (or scan the MDEC .STR headers in .STR file; and
check when the increasing frame number wraps to next stream).

The dual offsets are oddly computed as: [004h]=[008h]+EndOfLastFileInFolder
(that gives the correct value in the used entry, and a nonsensical value in the
other entry).

**Streaming List Audio entries (stream type 2)**

```
000h 2    Stream Type (0002h=Audio)
002h 2    Unknown (806Ah or increasing 0133h,0134h,0135h)
004h 4    Offset/800h in STAGEx.CDF file (increasing offsets)
008h 4    Unknown (0 or 13000h or E000h)
00Ch 2    Stage Number (0..5 = STAGE0-5)
00Eh 2    Stream ID (1, or increasing 3Ah,3Bh,3Ch)
010h 4    Stream sub.ID (usually 0Bh, increases +0Ah upon multiple same IDs)
014h 2    Unknown (0 or 2B0h or 3ADh or 398h) (Size/800h minus something?)
016h 2    Unknown (usually 20h, sometimes 0Fh)
018h 4    Unknown (2 or 1)              ... maybe num channels ?
01Ch 2+2  Unknown (0,0 or 800h,800h)
020h 8    Unknown (0)
```

The size of audio streams can be computed in similar fashion as for File List
entries (see there for details).

**Audio Stream Data (stored alongsides with file data in STAGEx.CDF file)**

This contains a 800h-byte header a list of 32bit indices:

```
000h 800h Whatever increasing 32bit index/timing values? FFFFFFFFh=special?
;That header exists in stage0\ and stage3\folder101\
;That header doesn't exist in all files (eg. not in stage1\folder301\)
```

then followed by several chunk-like STM blocks with 10h-byte headers:

```
000h 4  Chunk Index (increases each second chunk, from 0 and up)
004h 4  Number of Chunk Indices
008h 4  Fixed (02h,"STM")                                  ;2-channel Stream?
00Ch 1  Chunk Subindex (toggles 00h or 01h per each chunk) ;ch left/right?
00Dh 1  Chunk Size/800h
00Eh 4  Unknown (can be 00h, 01h, 11h, 20h, 21h)
00Fh 4  Unknown (can be A0h or C0h)
010h .. Data (Chunk Size-10h bytes) (looks like SPU-ADPCM audio)
```

After the last STM chunk, there is more unknown stuff:

```
000h 0   Number of ADPCM blocks?            (eg. 28h    or 49h)
004h 4   Size of extra data block in bytes  (eg. 13900h or 24200h)
008h 38h Zerofilled
040h 8   Zerofilled (maybe 1st sample of 1st SPU-ADPCM block)
048h ..  Looks like more SPU-ADPCM block(s), terminated by ADPCM end flag(s)
...  ..  Zerofilled (padding to end of last 800h-byte sector)
```

**Movie Stream Data (stored in .CDF, or in separate INTERx.STR file)**

The movies are usually stored in INTERx.STR (except, some have them stored in
STAGEx.CDF, eg. stage1\folder501, stage1\folder801, stage2\folder2101,
stage2\folder3001).

The data consists of standard .STR files (with 20h-byte headers on each
800h-byte sector), with the MDEC data being in huffman .BS format (with .BS
header... per frame?).

And, supposedly interleaved with XA-ADPCM audio sectors...?

**PE_DISK.01 and PE_DISK.02**

The presence of these files is probably used to detect which disc is inserted.
The file content is unknown (looks like 800h-byte random values).

**Note**

Reportedly "Files inside archive may be compressed with custom LZSS
compression" (unknown if/when/where/really/which files).

CDROM File Archive GAME.RSC (Colonly Wars Red Sun)

**Colony Wars Red Sun (MagDemo31: CWREDSUN\GAME.RSC, 13Mbyte)**

```
0000h 4     Offset to Bonkers List (2794h)
0004h F*8   Folder List                      (80h bytes, 10h entries)
0084h N*14h File List(s) for each folder     (2710h bytes, 1F4h entries)
2794h 4     Number of Bonkers     (FE3h)
2798h B*8   Bonkers List                     (7F18h bytes, FE3h entries)
A6B0h 8     Unknown (zerofilled)
A6B8h ..    File Data area
```

Folder List entries:

```
000h 4     Offset to File List for this folder   ;\both zero when empty
004h 4     Number of Files in this folder        ;/
```

File List entries:

```
000h 10h   Filename ("FILENAME_EXT", zeropadded)
010h 3     Index (in Bonkers list) (000h..Fxxh)
013h 1     Folder Number where the file is stored (00h..0Fh)
```

Bonkers List entries:

```
000h 4     File Offset (to Data, inreasing, 4-byte aligned, A6B8h and up)
004h 4     Folder Number where the file is stored (00h..0Fh)
```

Offsets/Indices in Folder/File list are unsorted (not increasing).

Offsets in Bonkers List are increasing (so filesizes can be computed as
size=next-curr, except, the LAST file must be computed as size=total-curr).

There is no "number of folders entry" nor "folder list end marker", as
workaround, while crawling the folder list, search the smallest file list
offset, and treat that as folder list end offset.

In the demo version, all File List entries for Folder 5 are pointing to files
with filesize=0, however, the Bonkers List has a lot more "hidden" entries that
are marked to belong to Folder 5 with nonzero filesize.

Note: Older Colony Wars titles did also have a GAME.RSC file (but in different
format, without folder structure).

CDROM File Archive FF8 IMG (Final Fantasy VIII)

FF8 is quite a mess without clear directory structure. Apart from SYSTEM.CNF
and boot EXE, there is only one huge IMG file. There are at least two central
directories: The Root directory (usually at the start of the IMG file), and the
Fields directory (hidden in a compressed file that can be found in the Root
directory). Moreover, there are files that exist in neither of the directories
(most notably the Movies at the end of the IMG file).

**IMG File**

The IMG file doesn't have a unique file header, it can be best detected by
checking the filename: FF8DISCn.IMG with n=1-4 for Disc 1-4 (or only
FF8DISC1.IMG or FF8.EXE+FF8TRY.IMG for demo versions).

The directories contain ISO sector numbers (originated from begin of the ISO
area at sector 00:02:00). Accordingly, it's best to extract data from the whole
disc image (in CUE/BIN format or the like). When having only the raw IMG file,
one most know/guess the starting sector number (eg. assume that the first Root
File is located on the sector after the Root Directory, and convert sector
numbers ISO-to-IMG accordingly).

Another oddity is that many files contain RAM addresses (80000000h-801FFFFFh),
unknown how far that's relevant, and if there are cases where one would need to
convert RAM addresses to IMG offsets.

**Root Directory**

The Root Directory is found at:

```
Offset 0000h in FF8DISCn.IMG in NTSC retail versions
Offset 2800h in FF8DISCn.IMG in PAL retail versions
Offset 0000h in FF8DISC1.IMG in french demo version
Offset ?????h in FF8.EXE in MagDemo23 (...maybe offset 3357Ch ?)
Offset 33510h in FF8.EXE in japanese demo version ?
Offset 33584h in FF8.EXE in other demo versions   ?
```

For detection:

```
if FF8DISCn.IMG starts with 000003xxh --> assume Root at IMG offset 0
if FF8DISCn.IMG starts with xxxxxxxxh --> assume Root at IMG offset 2800h
if FF8TRY.IMG starts with "SmCdReadCore" --> assume Root somewhere in EXE
```

File List:

```
000h N*8  File List entries
...  ..   Zeropadding to end of 800h-byte sector
```

File List entries:

```
000h 4    ISO Sector Number (origin at 00:02:00) (unsorted, not increasing)
004h 4    Filesize in bytes
```

The file list does usually end with zeropadding (unknown if that applies to all
versions; namely the Demo version might end with gibberish instead of having
800h-byte sector padding).

**Fields Directory**

The Fields Directory is located in Root file 0002h. First of, decompress that
file, then search the following byte sequences to find the start/end of the
directory:

```
retail.start  040005241800bf8f1400b18f1000b08f2000bd270800e00300000000
retail.end    0000010002000300
demo.start    76DF326F34A8D0B863C8C0EC4BE817F8
demo.end      0000000000000000000000000000000000100010
```

The bytes between those start/end pattern contain the Directory, with entries
in same format as Root directory:

```
000h 4    ISO Sector Number (origin at 00:02:00)
004h 4    Filesize in bytes
```

Notes: Root file 0002h is about 190Kbyte (decompressed), of which, the Fields
Directory takes up about 8Kbytes, the remaining data contains other stuff.

The sector numbers in the Fields Directory refer to other locations in the IMG
file (not to data in Root File 0002h).

**Movie List**

There is no known central directory for the movies (unknown if such a thing
exists, or if the movie sector numbers are scattered around, stored in separate
files). However, a movie list can be generated by crawling the movie headers,
starting at end of IMG file:

```
sector = NumSectors(IMG file)
@@lop:
seek(sector-1), read(buf,08h bytes)
if first4byte[buf+0]=("SMJ",01h), or ("SMN",01h) then
num_sectors=(byte[buf+5]+1)*(halfword[buf+6]+1)
sector=sector-num_sectors
AddToMovieFileList(sector, num_sectors)
goto @@lop
endif
```

That should cover all movies, which are all at the end of the IMG file (except,
there's one more movie-like file elsewhere in the middle of IMG file, that file
has only SMN/SMR audio sectors, without any SMJ video sectors).

**PADBUG archives**

PADBUG archives are used in Root files 001Eh..007Fh, most of them contain two
AKAO files (except file 004Bh contains one AKAO and one TXT file).

```
000h 4     Number of Files (N) (usually 2)
004h N*8   File List
...  ..    File Data area
```

File List entries:

```
000h 4     Offset in bytes (increasing, 4-byte aligned, see Quirk)
004h 4     File Size in bytes (can be odd)
```

Quirk: All files are zeropadded with 1-4 bytes to 4-byte boundary (ie. files
that do end on a 4-byte boundary will be nethertheless padded with 4 zeroes).

Note: The PADBUG archives resemble LNK archives in  O.D.T. (though those LNK
archives have a different unique 4-byte padding quirk).

**Compression**

CDROM File Compression LZ5 and LZ5-variants

FF8 does reportedly also use GZIP (unknown in which files).

**Known/unknown sectors for US version FF8DISC1.IMG**

```
root sectors:       27CBh ;\
field sectors:      D466h ; total known sectors: 36D13h
movie sectors:     270E2h ;/
unknown sectors:   14F49h
total IMG sectors: 4BC5Ch
```

**See also**

https://github.com/myst6re/deling/blob/master/FF8DiscArchive.cpp

https://ff7-mods.github.io/ff7-flat-wiki/FF8/PlaystationMedia.html

CDROM File Archive GTFS (Gran Turismo 2)

**Gran Turismo 2 (MagDemo27: GT2\GT2.VOL, GT2.VOL\arcade\arc_carlogo) - GTFS**

```
000h 4     ID "GTFS"                                             ;\
004h 4     Zero                                                  ;
008h 2     Number of 4-byte File Offset List entries (N)         ; File(0)
00Ah 2     Number of 20h-byte File/Folder Name List entries (F)  ;
00Ch 4     Zero                                                  ;
010h N*4   File Offset List (see below)                          ;/
...  ..    Zeropadding to 800h-byte boundary
...  F*20h File/Folder Name List (see below)                     ;-File(1)
...  ..    Zeropadding to 800h-byte boundary
...  ..    File Data                                             ;-File(2)
...  ..    Zeropadding to 800h-byte boundary
...        File Data                                             ;-File(3)
...  ..    ...
...        File Data                                             ;-File(N-2)
...  ..    Zeropadding to 800h-byte boundary
EOF  0     End of File                                           ;-File(N-1)
```

That is, for N files, numbered File(0)..File(N-1):

```
File(0) and File(1) = Directory information
File(2)..File(N-2)  = Regular data files
File(N-1)           = Offset List entry points to the end of .VOL file
```

File Offset List entries, in File(0):

Contains information for all files, including File(0) and File(1), and
including an entry for File(N-1), which contains the end offset for the last
actual file, ie. for File(N-2).

```
Bit0-10  = Number of padding bytes in last sector of this file (0..7FFh)
Bit11-31 = Offset/800h to first sector of this file (increasing)
To compute the filesize: Size=(Entry[N+1] AND FFFFF800h)-Entry[N]
```

File/Folder Name List entries, in File(1):

Contains information for all files, excpet File(0), File(1), File(N-1), plus
extra entries for Folders, plus ".." entries for links to Parent folders.

```
000h 4     Unknown (379xxxxxh) (maybe timestamp?)
004h 2     When Flags.bit0=0: Index of File in File Offset List (2 and up)
When Flags.bit0=1: Index of first child in Name List, or...
When Flags.bit0=1: Index of 1st? parent in Name List (Name="..")
006h 1     Flags (bit0:0=File, 1=Directory; bit7:1=Last Child entry)
007h 19h   Name (ASCII, zeropadded)
```

The game does use several archive formats: GTFS (including nested GTFS inside
of main GTFS) and WAD.WAD and DOT1.

The game does use some GT-ZIP compressed files, and many GZIP compressed files
(albeit with corrupted/zeropadded GZIP footers; due to DOT1 filesize 4-byte
padding and (unneccessarily) GTFS 800h-byte padding).

CDROM File Compression GT-ZIP (Gran Turismo 1 and 2)

CDROM File Compression ZIP/GZIP/ZLIB (Inflate/Deflate)

To extract the decompressed size from the corrupted GZIP footers, one could
compute the compressed "size" (excluding the GZIP header, footer, and padding),
and search for a footer entry that is bigger than "size".

```
size=gz_filesize
size=size-GzipHeader(including ExtraHeader, Filename, Comment, HeaderCrc)
size=size-GzipFooter(8)   ;initially assuming 8-byte footer (without padding)
i=gz_filesize-4
@@search_footer:
if buf[i]
CDROM File Archive FAdj0500 (Klonoa)

**Klonoa (MagDemo08: KLONOA\FILE.IDX+FILE.BIN)**

```
FILE.IDX
000h 8     ID "FAdj0500"
008h 38h   RAM addresses       (80xxxxxxh, 0Ch words)
038h 4     Zero
03Ch 4     RAM address         (80xxxxxxh)
040h N*10h File List (including Folder start/end markers)
FILE.BIN
000h ..    File Data area (split into filesizes from FILE.IDX)
```

File List entries:

```
Type 0 (Folder End):
000h 4     Type (0=Folder End)
000h 4     Zero
008h 4     RAM address         (always 801EAF8Ch)
00Ch 4     Zero
Type 1.a (Folder Start):
000h 4     Type (1=Folder Start)
000h 4     Folder Offset/800h  (offset of FIRST file in this Folder)
008h 4     RAM address         (always 801EAF8Ch)
00Ch 4     Folder Size/800h    (size of ALL files in this Folder)
Type 1.b (Force Offset, can occur between Files within a Folder):
000h 4     Type (1=Same as Folder Start)
000h 4     Folder Offset/800h  (offset of NEXT file in this Folder)
008h 4     RAM address         (always 801EAF8Ch)
00Ch 4     Folder Size/800h    (zero for Force Offset)
Type 2 (File entries, within Folder Start/End):
000h 4     Type (2=File)
004h 4     Filesize in bytes   (4-byte aligned?)
008h 4     RAM address 1       (80xxxxxxh, or zero)
00Ch 4     RAM address 2       (80xxxxxxh)
```

File Offsets are usually 4-byte aligned (at offset+filesize from previous
entry). Except, the first file after Folder Start (and Force Offset) is
800h-byte aligned.

The archive contains DOT1 archives, OA05 archives, Ulz compression, and TIM,
TMD, VAB, SEQ, VB files.

CDROM File Archive HED/DAT/BNS/STR (Ape Escape)

**Ape Escape KKIIDDZZ.HED/.DAT/.BNS/.STR**

```
000h 52Ch List for .DAT file    ;value 0000h..6FFFh = sector 0..6FFFh in DAT
52Ch D4h  Zerofilled
600h C4h  List for .BNS file    ;value 7000h..71AFh = sector 0..1AFh in BNS
6C4h 3Ch  Zerofilled
700h 50h  List for .STR file(s) ;raw CDROM sector numbers from 00:02:00
750h B0h  Zerofilled
```

List entries, for all three lists (32bit values):

```
0-19   File Offset/800h (20bit)
20-31  File Size/800h   (12bit)
```

The sector numbers in DAT and BNS are basically counted from begin of the .DAT
file (which has 7000h sectors in retail version, and the .BNS file does follow
right thereafter on the next sector) (the demo version (MagDemo22: KIDZ\*) has
only 105Ah sectors in .DAT, and the BNS entries at offset 600h start with 105Ah
accordingly).

There are 29 STR files in DEMO\*.STR and STR\*.STR, and 20 of them (?) are
referenced in HED ? There are also several .ALL files in above folders.

Note: Most of the STR files in Ape Escape contain polygon animation streams
rather than BS compressed bitmaps. Ape Escape is (c)1999 by Sony.

```
.HED is 2048 bytes
.DAT is 58720256 bytes = 3800000h bytes  ;div800h would be 7000h
.BNS is 884736 bytes = D8000h bytes      ;div800h would be 1B0h
.STR's: 7D3Bh+150 = 7DD1h = sector for STR\LAB.STR
```

Some files contain RLE compressed TIMs:

CDROM File Compression TIM-RLE4/RLE8

Some files contain raw headerless SPU-ADPCM (eg. DAT file 00Ah).

CDROM File Archive BIGFILE.BIG (Gex)

**Gex (GXDATA\BIGFILE.BIG and nested BIG files therein)**

```
000h 4     Number of Files (eg. F4h)
004h 0Ch   Zero
010h N*10h File entries
...  4     Archive ID (eg. 00000000h, FF53EC8Bh, or 83FFFFFFh)
...  ..    Zeropadding to 800h byte boundary
...  ..    File Data
```

File Entries:

```
000h 4   Archive ID (same value as in above header)
004h 4   Filename checksum or so (randomly ordered, not increasing)
008h 4   Filesize in bytes
00Ch 4   Fileoffset (800h-byte aligned) (increasing)
```

Filetypes in the archive include...

```
looks like a lot of raw data without meaningful file headers...
file C3h,ECh are raw SPU-ADPCM
file 08h,09h are nested BIG archives, but with FileEntry[00h]=FF53EC8Bh
file D9h,DAh are nested BIG archives, but with FileEntry[00h]=83FFFFFFh
```

FileEntry[04h] sometimes has similar continous values (maybe caused by similar
filenames, and using a simple checksum, not CRC32).

CDROM File Archive FF9 DB (Final Fantasy IX)

**DB Archive**

```
000h 1   ID (DBh)
001h 1   Number of Types
002h 2   Zero (0)
004h N*4 Type List
...  ..  File Lists & File Data for each Type
```

Type List entries:

```
000h 3   Offset to File List (self-relative, from current entry in Type List)
003h 1   Data Type (00h..1Fh)
```

File List:

```
000h 1   Data type (00h..1Fh) (same as in Type List)
001h 1   Number of Files
002h 2   Zero (0)
004h N*2 File ID List (unique ID per type) (different types may have same ID)
...  ..  Zeropadding to 4-byte boundary
...  N*4 Offset List (self-relative, from current entry in Offset List)
...  4   End Offset  (first-relative, from first entry in Offset List)
...  ..  File Data (referenced from above Offset List)
```

**Data Types**

```
00h  Misc (DOT1 Archives, or other files)
01h  Unused?
02h  Reportedly 3D Model data (vertices,quads,triangles,texcoords)
03h  Reportedly 3D Animation sequences
04h  TIM Texture
05h  Reportedly Scripts (hdr="EV")              (eg. dir04\file32\1B-0001)
06h  ?                                          (eg. dir02\file*)
07h  Sound "Sequencer Data" (hdr="AKAO")        (eg. dir09\file*)
08h  Sound? tiny files (hdr="AKAO")             (eg. dir04\file32\1B-0001)
09h  Sound Samples (hdr="AKAO")                 (eg. dir0B\file*)
0Ah  Reportedly Field Tiles and Field Camera parameters
0Bh  Reportedly Field Walkmesh                  (eg. dir04\file32\1B-0001)
0Ch  Reportedly Battle Scene geometry           (eg. dir06\file*)
0Dh  ?                                          (eg. dir01\file01)
0Eh  Unused?
0Fh  Unused?
10h  ?                                          (eg. dir05\file*)
11h  ?                                          (eg. dir05\file*)
12h  Reportedly CLUT and TPage info for models  (eg. dir04\file32\1B-0001)
13h  Unused?
14h  ?                                          (eg. dir05\file*)
15h  Unused?
16h  ?  (eg. dir04\file32\1B-0001)
17h  ?  (eg. dir04\file32\1B-0000)
18h  Sound (hdr="AKAO")  (eg. dir04\file32\1B-0001)
19h  ?  (eg. dir04\file32\1B-0001)
1Ah  ?  (eg. dir06\file*)
1Bh  DB Archives (ie. further DB's nested inside of the parent DB archive)
1Ch  ?  (eg. dir04\file32\1B-0001)
1Dh  ?  (eg. dir03\file2328\1B-0001)
1Eh  ?  (eg. dir04\file32\1B-0001)
1Fh  ?  (eg. dir04\file32\1B-0001)
20h..FFh Unused?
```

CDROM File Archive NSD/NSF (Crash Bandicoot 1-3)

**NSD/NSF versions**

```
v0  Crash Bandicoot Prototype (oldest known prototype from 08 Apr 1996)
v1  Crash Bandicoot 1         (retail: S*\*.NSD and .NSF)
v2  Crash Bandicoot 2         (MagDemo02: CRASH\S0\*.NSD and .NSF)
v3  Crash Bandicoot 3 Warped  (MagDemo26,50: (S0\*.NSD and .NSF)
```

```
____________________________________ NSD _____________________________________
```

**Overall NSD Structure (v0 contains only the Lookup entries)**

```
0000h 100h*4  Lookup Table, using index=((Filename/8000h) AND FFh) ;\
0400h 4       Number of Chunks in .NSF file                        ; Lookup
0404h 4       Number of Files in Lookup File List (N)              ;/
0408h 4       Level Data Filename (eg. 4F26E8DFh="DATh.L")         ;-LevelDat
040Ch 4       Bitmap Number of Colors (100h) (P) (0=None)          ;\
0410h 4       Bitmap Width    (200h or 1B0h) (X) (0=None)          ; Bitmap
0414h 4       Bitmap Height   (0D8h or 090h) (Y) (0=None)          ;/
0418h 4       Compression: Offset/800h of first uncompressed chunk ;\
041Ch 4       Compression: Number of compressed chunks (0..40h)    ; Compress
0420h 40h*4   Compression: Compressed Chunk List (0=unused entry)  ;/
...   N*8     Lookup File List                                     ;-Lookup
...   ..      Level Data (size/format varies, see below)           ;-LevelDat
...   P*2     Bitmap Palette (16bit values, 8000h..FFFFh)          ;\Bitmap
...   X*Y     Bitmap Pixels  (0D8h*200h)                           ;/
```

There are four .NSD versions, which can be distinguished via filesize:

```
v0  NSD Filesize=408h + N*8                           ;-Lookup only
v1  NSD Filesize=520h + N*8 + P*2+X*Y + 210h          ;\
v2  NSD Filesize=520h + N*8 + P*2+X*Y + 1DCh+S*18h    ; with extra stuff
v3  NSD Filesize=520h + N*8 + P*2+X*Y + 2DCh+S*18h    ;/
```

Note: v0 is mainly used by the Crash Bandicoot prototype, but the Crash
Bandicoot 1 retail version does also have a few v0 files.

**NSD Lookup**

The lookup table allows to find files (by filenames) in the NSF files. It does
merely contain the NSF chunk number, so one must load/decompress that chunk to
find the file's exact size/location in that chunk.

One can create a complete file list by scanning the whole NSF file without
using the NDS lookup table.

```
Lookup File List entries (indexed via Lookup Table):
00h 4   Chunk Number in .NSF file
04h 4   Filename (five 6bit characters)
```

Filenames:

```
0     Type (always 1=Filename) (as opposed to 0=Memory Pointer)
1-6   5th character ;-Extension  ;\character set is:
7-12  4th character ;\           ; 00h..09h="0..9"
13-18 3rd character ; Name       ; 0Ah..23h="a..z"
19-24 2nd character ;            ; 24h..3Dh="A..Z"
25-30 1st character ;/           ;/3Eh..3Fh="_" and "!"
31    Always zero?
```

Special name: 6396347Fh="NONE.!"

**NSD Level Data**

Level Data exists in NSD v1-v3 (v0 does also have Level Data, but it's stored
in NSF file "DAT*.L" instead of in the NSD file). There are two major versions:

```
Level Data in NSD v1 (or NSF v0 file DAT*.L):
000h  4       01h                                                  ;\
004h  4       Level Number (xxh) (same as xx in S00000xx.NSD/NSF)  ;
008h  4       3807C8FBh = "s0_h.Z" ?                               ; LevelDat
00Ch  4       Zero                                                 ; v1
010h  4       Zero                                                 ;
014h  L*4     Namelist (40h*4)                                     ;
...   4       5Ah                                                  ;
...   F8h     Zerofilled                                           ;/
Level Data in NSD v2-v3:
000h  4       Number of Spawn Points (S)                           ;\
004h  4       Zero                                                 ;
008h  4       Level Number (xxh) (same as xx in S00000xx.NSD/NSF)  ; LevelDat
00Ch  4       Number of Objects? (can be bigger than below list)   ; v2/v3
(eg. 1BDh or A5h or E4h)                           ;
010h  L*4     Namelist for Objects?  (v2=40h*4, or v3=80h*4)       ;
...   4       Unknown, always 5Ah (maybe just list end marker?)    ;
...   C8h     Zerofilled                                           ;
...   S*18h   Spawn Points                                         ;/
```

**NSD Bitmap**

This bitmap is displayed while loading the level.

**NSD Compression Info**

Compression is only used in v1 (v2-v3 do also have the compression entries at
[418h..51Fh], but they are always zerofilled).

```
Compressed Chunk List entries at [420h..51Fh]:
0-5   Compressed Chunk Size/800h (1..1Fh=800h..F800h bytes, 20h..3Fh=Bad?)
6-31  Compressed Chunk Offset/800h
```

Note: Crash Bandicoot 1 retail does also have a few uncompressed files (either
v0 files without compression info, or v1 files with zerofilled compression
info).

```
____________________________________ NSF _____________________________________
```

NSF files consist of 64Kbyte chunks (compressed chunks are smaller, but will be
64Kbyte after decompression). Each chunk can contain one or more file(s). That
implies that all files must be smaller than 64Kbyte (larger textures or ADPCM
samples must be broken into multiple smaller files).

All files (except Textures) are NSF Child Archives which contain one or more
smaller files/items.

**NSF Chunk Types**

```
N*8Kbyte-Compressed-chunks:
000h 2    ID, always 1235h (instead of 1234h)
002h 2    Zero
004h 4    Decompressed Size (max 10000h) (usually 9xxxh..Fxxxh, often Fxxxh)
008h 4    Skip Size (max 40h or so, when last LZSS_len was 40h)
00Ch ..   Compressed data
...  SK   Unused (Skip size)
...  ..   Final uncompressed bytes (10000h-compressed_size-skip_size)
64Kbyte-Texture-chunks:
000h 2    ID, always 1234h
002h 2    Chunk Family (1=Texture)
004h 4    Filename (five 6bit characters)
008h 4    File Type (5=Texture)
00Ch 4    Checksum (sum of bytes ar [0..FFFFh], with initial [0Ch]=00000000h)
010h ...  Zerofilled
020h ...  Texture data (raw VRAM data, FFE0h bytes?)
64Kbyte-NonTexture-chunks:
000h 2    ID, always 1234h
002h 2    Chunk Family (0=Misc or 2..5=Sound)
004h 4    Chunk Number*2+1
008h 4    Number of Files (N) (can be 0, eg. prototype S0000003 chunk21h)
00Ch 4    Checksum (sum of bytes ar [0..FFFFh], with initial [0Ch]=00000000h)
010h N*4  File List (Offsets from ID=1234h to entries) (4-byte aligned)
...  ..   Offset for end of last File
...  ..   File Data (NSF Child Archives) (includes Type/Filename)
...  ..   Padding to 10000h-byte boundary
```

**NSF Child Archives**

```
000h 4    ID, always 0100FFFFh
004h 4    Filename (five 6bit characters)
008h 4    File Type (01h..04h, or 06h..15h)
00Ch 4    Item Count (I)
010h I*4  Item List (Offsets from ID=0100FFFFh to items) (...unaligned?)
...  ..   Offset for end last item
...  ..   Data (Items)
```

**NSF Chunk Loading and Decompression**

The compression is a mixup of LZSS and RLE. Compressed chunks are max F800h
bytes tall (10000h bytes after decompression).

```
dst=chunk_buffer_64kbyte
if chunksize is known (from NSD file)
src=dest=dst+10000h-chunksize
diskread(fpos,src,chunksize)
else (when parsing raw NSF file without NSD file)
src=temp_buffer_64kbyte
diskread(fpos,src,10000h)
dst_start=dst, src_start=src
if halfword[src+00h]<>1234h then   ;check ID (1234h=raw, or 1235h=compressed)
dst_end=dst+word[src+04h]
skip_size=word[src+08h]
src=src+0Ch
while dstdst then
while dst
<a id="cdromfilearchivedraculadatdracula"></a>
## CDROM File Archive DRACULA.DAT (Dracula)

**Dracula - The Resurrection - DRACULA.DAT (180Mbyte)**

```
000h 4     Zero
004h 4     Number of Entries (503h)
008h 4     Zero
00Ch 4     Random
010h 10h   Zero
020h N*10h File List
...  ..    Zeropadding to 800h-byte boundary
...  ..    Fild Data area
```

File List entries:

```
000h 4     Offset/800h
004h 4     Type (see below for info on different file types)
008h 4     Filesize in bytes
00Ch 4     Random (or 0 when Filesize=0)
```

Most of the .DAT file consists of groups of 3 files (with type 01h/40h, 20h and
400h; of which the files with type 20h and 400h may have Size=0=empty).

```
Type=00000001h Cubemap           ;\either one of these
Type=00000040h Cubemap.empty     ;/
Type=00000020h Cubemap.overlay?  ;\these have size=0 when unused
Type=00000400h Cubemap.sounds    ;/
```

There are some general purpose files with other types at end of .DAT file:

```
Type=00000000h Archive with TIMs         (Size=AB74h)  (" RSC3.1V")
Type=00000004h Unknown                   (Size=16164h) (00000064h)
Type=00000008h Related to DRACULA1.STR   (Size=1000h)  (" RTS1.1V")
Type=00001000h Unknown                   (Size=2000h)  ("BXFS1.1V")
Type=00008000h Unknown                   (Size=71Dh)   ("  CM1.1V")
Type=00020000h Unknown                   (Size=3B9h)   (" GSM0.1V")
Type=02000000h Unknown                   (Size=0h)     (empty)
Type=00000100h Related to DRACULA1.XA    (Size=1000h)  ("RAAX1.1V")
Type=00000010h Unknown                   (Size=450h)   (" HYP0.1V")
Type=00100000h Unknown                   (Size=4014h)  (" xFS1.1V") (x=A1h)
Type=00000080h Unknown                   (Size=258F4h) (00000010h)
Type=00000200h TIM (gui charset)         (Size=6E9Eh)  (TIM)
Type=00010000h TIM (gui buttons)         (Size=10220h) (TIM)
Type=00040000h Unknown                   (Size=2C4h)   (" TES0.1V")
Type=00002000h TIM (gui book pages)      (Size=1040h)  (TIM)
Type=00000800h Cubemap ;\as Type 01h,    (Size=4092Ch) (" RIV3.1V")
Type=00004000h Cubemap ;/but [10h,14h]=0 (Size=4092Ch) (" RIV3.1V", too)
```

Type 01h - Cubemap:

```
000h 8     Name, ASCII, padded with leading spaces (eg. " RIV3.1V")
008h 4     Something (0, 1 or 2) (unknown, this isn't number of list entries)
00Ch 4     Zero
010h 4     Offset to Ext data (ACh)                       ;\ext data
014h 4     Size of Ext data (eg. 0 or 84h)                ;/
018h 6*4   Offsets to Side 0-5                            ;\cubemap sides
030h 6*4   Sizes of Side 0-5 (0, 10220h, or 10820h)       ;/
048h 44h   Zerofilled
08Ch 20h   Name, ASCII (eg. "DEBUT0.VR", zeropadded)
0ACh ..    Ext Data (if any)
...  ..    Cubemap TIM sides (if any)
Note: The cubemap TIMs have 100h or 400h colors (in the latter case: 100h  colors for each quarter of the 8bpp bitmap).
Note: The TIMs can be arranged as 3D-cubemap with six sides, or as hires
2D-bitmap (composed of four TIMs, and 2 empty TIMs with size=0).
```

Type 40h - Empty Cubemap:

```
Same as Type 01h, but size is always 0ACh (and all seven Size entries are 0)
```

Type 400h - Sound VAG's:

```
000h 8     Name, ASCII, padded with leading spaces (eg. " XFS0.1V")
008h 4     Zero
00Ch 4     Number of Files (N) (max 10h)
010h N*10h File List (100h bytes, zeropadded when less than 10h files)
110h ..    File Data (VAG files)
File List entries:
000h 4     Unknown (55F0h, 255F0h or 20000h)
004h 4     File ID (01010000h, increasing, or other when above=2xxxxh)
008h 4     Offset in bytes                                ;\.VAG files
00Ch 4     Filesize in bytes                              ;/
```

Type 20h - Cubemap overlays, polygons, effects or so?:

```
000h 8      Name, ASCII, padded with leading dot (eg. ".MNA4.1V")
008h 4      Zero
00Ch 4      Random
010h 4      Unknown 01h
014h 4      Total Number of 40h-byte blocks (01h..[018h]) (H)
018h 4      Total Number of 120h-byte blocks (eg. 1Fh,31h) (N)
01Ch 4      Total Number of 1Ch-byte blocks (eg. 1Eh, 50h, F7h) (M)
020h 4      Unknown 0 or 1 (in file 4EAh)
024h 4      Unknown 01h
028h 6*4    Offsets to Side 0-5 (at end of file and up) (or 0)  ;\cubemap
040h 6*4    Sizes of Side 0-5   (10220h, or 10820h)     (or 0)  ;/sides
058h H*40h  40h-byte blocks
...  N*120h 120h-byte blocks (related to offsets in 40h-byte blocks)
...  M*1Ch  1Ch-byte blocks  (related to offsets in 120h-byte blocks)
...  ..     Unknown data     (related to offsets in 1Ch-byte blocks)
...  ..     Ext data         (related to Ext offsets in 40h-byte blocks)
FILE DOES END HERE!
(below is allocated in above header, but not actually stored in the file)
(maybe allocated as rendering buffer?)
...  -      Cubemap TIM sides
The 40h-byte blocks are:
000h 20h    Name (eg. "FLAMMES", zeropadded)
020h 4      Unknown 01h or 00h
024h 4      Offset to 120h-byte blocks (usually 98h, or higher)
028h 4      Unknown 00h
02Ch 4      Number of 120h-byte blocks (01h..[018h])
030h 4      Unknown 01h
034h 4      Ext Offset                ;\usually all zero
038h 4      Ext Size (3C000h)         ; (except, nonzero in file 4EAh)
03Ch 4      Ext Random (checksum?)    ;/
The 120h-byte blocks are:
000h 18h*4  List with Offsets to 1Ch-byte blocks (usually 4 entries nonzero)
060h 18h*4  List with Zeroes
0C0h 18h*4  List with Numbers of 1Ch-byte blocks (usually max 4 entries)
The 1Ch-byte blocks are:
000h 4      Unknown 04h
004h 4      Width   20h or 10h
008h 4      Height  20h or 10h or 30h
00Ch 4      Unknown 60h or 10h
010h 4      Unknown 00h or 30h
014h 4      Offset to Unknown Data
018h 4      Size of Unknown Data (Width*Height*1)
```

Type 00h - TIMs:

```
000h 8      Name (" RSC3.1V")
008h 8      Zerofilled
010h 4      Number of used entries (1Fh) (max 80h)
014h 80h*4  Offset List    (offsets to files) (A14h and up)
214h 80h*4  Zero List      (zerofilled)
414h 80h*4  Size List      (filesizes)
614h 80h*4  Width List     (0Ch,18h,34h,2Ch) (in pixels)
814h 80h*4  Height List    (0Ch,24h,34h,2Ch)
A14h ..     Data (TIM files, with mouse pointers)
```

<a id="cdromfilearchivecroc2dirwadetc"></a>
## CDROM File Archive Croc 2 (DIR, WAD, etc.)

**Croc 2 (MagDemo22: CROC2\CROCII.DIR\T*.WAD+DEM)**

**Disney's The Emperor's New Groove (MagDemo39: ENG\KINGDOM.DIR\T*.WAD+DEM)**

**Disney's Aladdin in Nasira's Rev. (MagDemo46: ALADDIN\ALADDIN.DIR\T*.WAD+DEM)**

**Alien Resurrection, and Harry Potter 1 and 2 ... slightly different format?**

Overall .WAD format:

```
000h 4      Total Filesize+/-xx (-4 or +800h or +1800h)
004h 4+4+.. XSPT Chunk        ;Textures
...  4+4+.. XSPS Chunk        ;SPU-ADPCM Sound (if any, not in all .WAD's)
...  4+4+.. XSPD Chunk        ;...whatever Data...?
...  4+4    DNE Chunk         ;End marker (in Harry Potter: with data!)
```

XSPT Chunk (Textures):

```
000h 4        Chunk Name "XSPT" (aka TPSX backwards)
004h 4        Chunk Size (excluding 8-byte Name+Size)
008h 4        Chunk Flags (02h or 06h or 0Eh)  ;02h in Croc 2
00Ch (20h)    Name (eg. "Default new map", zeropadded)  ;\if Flags bit2=1
...  (804h)   Unknown ... SAME as in XSPD chunk !!!     ;/
...  4        Number of List 1 entries (N1) (xxh..xxxh) ;\
...  4        Number of Texture Pages (1..4)            ; List 1 and NumPages
...  N1*0Ch   List 1 Whatever (6B 2F xx 00..)           ;/
...  4        Number of List 2 entries (N2) (0..xxh)    ;\
...  4        Unknown (2 or 7)                          ; List 2
...  N2*04h   List 2 Whatever (halfwords?) (if N2>0)    ;/
...  (5*C00h) Whatever, 5*C00h, Palette+Stuff?          ;-if Flags bit3=1
...  ..       RLE16 compressed Texture Pages            ;-Texture bitmap
RLE16 Texture notes:
Compressed data consists of signed little-endian 16bit LEN+DATA pairs:
LEN=0000h        --> invalid/unused
LEN=0001h..7FFFh --> copy LEN halfwords from src
LEN=8000h..FFFFh --> load ONE halfword as fillvalue, fill -LEN halfwords
Compressed size is everything up to end of XSPT chunk
Decompressed size is 20000h*NumTexturePages (=20000h,40000h,60000h or 80000h)
That is: Width=256 halfwords, height 256*NumTexturePages lines. There seems
to be only one RLE16 compression block for all Texture Pages, rather than one
RLE16 block for each Page.
BUG #1: Decompressed data in Aladding/Emperor does often contain only
1FFFEh,3FFFEh,5FFFEh,7FFFEh bytes (the decompressed data has correct size
when appending ONE halfword with random/zero value).
BUG #2: Compressed data in Croc 2 ends with a RLE16 length value (-LEN), but
lacks the corresponding RLE16 filldata (the decompressed data is 7FFFEh when
filling those LEN halfwords with random/zero values).
```

XSPS Chunk (SPU-ADPCM Sound) (if any, isn't present in all .WAD files):

```
000h 4      Chunk Name "XSPS" (aka SPSX backwards)       ;\
004h 4      Chunk Size (excluding 8-byte Name+Size)      ; header
008h 4      Chunk Flags (0 or 3 or 7)                    ;/
00Ch 4      Number of Sounds (N1) (1..xxh)               ;\always present
010h N1*14h Sound List                                   ;/
...  (4)     VAB/VH Size                                 ;\if Flags=3 or 7
...  (..)    VAB/VH Header                               ;/   (bit0 or bit1?)
...  (4)     Unknown (2 or 4)                            ;-if Flags=3 or 7
...  (4)     Whut (N2)                                   ;\if Flags.bit2=1
...  (N2*10h) Whut List (4 words: xxh,10h,xxxx00h,xxxx0h);/
...  4       Size of all Part 1 Sound Data blocks               ;\always
...  ..      SPU-ADPCM Sound Data (referenced from Sound List)  ;/
...  (4)     Size of all Part 2 Sound Data blocks (+8)          ;\if Flags=
...  (..)    SPU-ADPCM Sound Data (referenced from Sound List?) ;    3 or 7
...  (8)     Zero                                               ;/
Sound List entries (as in FESOUND.WAD):
000h 4    Sample Rate in Hertz (AC44h=44100Hz, 5622h=22050Hz, 3E80h=16000Hz)
004h 2    Sample Rate Pitch    (1000h=44100Hz, 0800h=22050Hz, 05CEh=16000Hz)
006h 2    Unknown (7Fh)
008h 4    Unknown (1)          (1)               (8)
00Ch 4    Unknown (42008Fh)    (1FC0001Fh)       (40008Fh)
010h 4    Filesize             (xxx0h)           (xxx0h)
```

XSPD Chunk:

```
000h 4     Chunk Name "XSPD" (aka DPSX backwards)
004h 4     Chunk Size (excluding 8-byte Name+Size)
008h 4     Flags-and/or-other stuff ? (eg. 00000094h or 0A801094h)
00Ch 804h  Unknown ... SAME as in XSPT chunk !!!
810h ..    Unknown ...
```

DNE Chunk (End marker):

```
000h 4     Chunk Name " DNE" (aka END backwards)
004h 4     Chunk Size (0)           (except, in Harry Potter: nonzero)
...  ..    Data (usually none such) (except, in Harry Potter: with data!)
```

Additional DEM files (always 1774h bytes) (if any, not all .WAD's have .DEM's):

```
000h 4     Number of entries (N) (always 2EEh, aka 750 decimal)
004h N*8   Whatever entries... maybe data for demonstration mode?
```

See also:

http://wiki.xentax.com/index.php/Argonaut_WAD

<a id="cdromfilecompression"></a>
## CDROM File Compression

**Compressed Bitmaps**

```
.BS used by several games (and also in most .STR videos)
.GIF used by Lightspan Online Connection CD
.JPG used by Lightspan Online Connection CD
.BMP with RLE4 used by Lightspan Online Connection CD (MONOFONT, PROPFONT)
.BMP with RLE8+Delta also used by Online Connection CD (PROPFONT\ARIA6.BMP)
.PCX with RLE used by Jampack Vol. 1 (MDK\CD.HED\*.pcx)
.PCX with RLE used by Hot Wheels Extreme Racing (MagDemo52: US_01293\MISC\*)
.PCX with RLE used by Metal Gear Solid (slightly corrupted PCX files)
```

**Compressed Audio**

```
.XA uses XA-ADPCM (and also used in .STR videos)
.VAG .VB .VAB uses SPU-ADPCM
```

**Compressed Files**

CDROM File Compression LZSS (Moto Racer 1 and 2)

CDROM File Compression LZSS (Dino Crisis 1 and 2)

CDROM File Compression LZSS (Serial Experiments Lain)

CDROM File Compression ZOO/LZSS

CDROM File Compression Ulz/ULZ (Namco)

CDROM File Compression SLZ/01Z (chunk-based compressed archive)

CDROM File Compression LZ5 and LZ5-variants

CDROM File Compression PCK (Destruction Derby Raw)

CDROM File Compression GT-ZIP (Gran Turismo 1 and 2)

CDROM File Compression GT20 and PreGT20

CDROM File Compression HornedLZ

CDROM File Compression LZS (Gundam Battle Assault 2)

CDROM File Compression BZZ

CDROM File Compression RESOURCE (Star Wars Rebel Assault 2)

CDROM File Compression TIM-RLE4/RLE8

CDROM File Compression RLE_16

CDROM File Compression PIM/PRS (Legend of Mana)

CDROM File Compression BPE (Byte Pair Encoding)

CDROM File Compression RNC (Rob Northen Compression)

CDROM File Compression Darkworks

CDROM File Compression Blues

CDROM File Compression Z (Running Wild)

CDROM File Compression ZAL (Z-Axis)

CDROM File Compression EA Methods

CDROM File Compression ZIP/GZIP/ZLIB (Inflate/Deflate)

CDROM File Compression LArc/LHarc/LHA (LZS/LZH)

CDROM File Compression UPX

CDROM File Compression LZMA

CDROM File Compression FLAC audio

Some other archvies that aren't used by any PSX games, but, anyways...

CDROM File Compression ARJ

CDROM File Compression ARC

CDROM File Compression RAR

CDROM File Compression ZOO

CDROM File Compression nCompress.Z

CDROM File Compression Octal Oddities (TAR, CPIO, RPM)

CDROM File Compression MacBinary, BinHex, PackIt, StuffIt, Compact Pro

**Compressed Archives**

Some Archives have "built-in" compression.

CDROM File Archive WAD (Doom)

<a id="cdromfilearchivebigfiledatgexenterthegecko"></a>
## CDROM File Archive BIGFILE.DAT (Gex - Enter the Gecko)

CDROM File Compression LZSS (Dino Crisis 1 and 2)

**Dino Crisis 1 and 2 (PSX\DATA\*.DAT and *.DBS and *.TEX, File type 7,8)**

Dino Crisis LZSS Decompression for files with type 7 and 8:

```
@@collect_more:
flagbits=[src]+100h, src=src+1    ;8bit flags
@@decompress_lop:
flagbits=flagbits SHR 1
if zero then goto @@collect_more
if carry=1 then
[dst]=[src], dst=dst+1, src=src+1
else
disp=[src]+[src+1]*100h AND FFFh, len=[src+1]/10h+2, src=src+2
if disp=0 then error
for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
endif
if src
CDROM File Compression ZOO/LZSS

**Jarret & LaBonte Stock Car Racing (MagDemo38: WTC\*.ZOO)**

```
0000h 4     Decompressed Size                          ;\1st sector
0004h 7FCh  Garbage                                    ;/
0800h 4     Decompressed Size (same as above)          ;\2nd sector
0804h 7FCh  LZSS compressed data, part 1               ;/
1000h 800h  LZSS compressed data, part 2               ;-3rd sector
1800h 800h  LZSS compressed data, part 3               ;-4th sector
...   ..    etc.
```

Note: The file format & compression method is unrelated to ZOO archives (to
distinguish between the formats: ZOO archives have [0014h]=FDC4A7DCh, the
ZOO/LZSS files have [0014h]=Garbage).

The decompressed WTC\*.ZOO files can contain large TIMs, or chunk-based
archives (where each chunk can contain one or more small TIMs), or other stuff.

**Decompression function**

```
decompress_file:
if LittleEndian32bit[src+14h]=FDC4A7DCh then goto error ;refuse ZOO archives
if LittleEndian32bit[src]<>LittleEndian32bit[src+800h] then goto error
curr=src+800h
src=curr+4
@@sector_lop:
call decompress_sector
curr=curr+800h
src=curr
if src
CDROM File Compression SLZ/01Z (chunk-based compressed archive)

SLZ/01Z files are Chunk-based archives with one or more compressed chunk(s).

Used by Hot Shots Golf 2 (retail: DATA\F0000.BIN\*, MagDemo31/42:
HSG2\MINGOL2.BIN\*)

**SLZ/01Z chunk headers**

The archive consists of Chunk(s) in following format:

```
000h 3     ID (either "01Z" or "SLZ", both are used)
003h 1     Method (00h=Uncompressed, 01h=LZSS, 02h=LZSS+FILL)
004h 4     Compressed size (SIZ) (same as decompressed when Method=0)
008h 4     Decompressed size
00Ch 4     Distance to next chunk, if any (SIZ+10h+Align4, or 0=None)
010h SIZ   Compressed data
```

**SLZ/01Z  decompression function:**

```
method=byre[src+3]
len=word[src+8]
src=src+10h
if method=0 then
for i=1 to len, [dst]=[src], dst=dst+1, src=src+1, next i
goto @@decompress_done
dst_end = dst+len
@@collect_more:
flagbits=[src]+100h, src=src+1    ;8bit flags
@@decompress_lop:
if method=2 AND dst=dst_end then goto @@decompress_done
flagbits=flagbits SHR 1
if zero then goto @@collect_more
if carry=1 then
[dst]=[src], dst=dst+1, src=src+1
else
disp=([src]+[src+1]*100h) AND 0FFFh, len=([src+1]/10h)+3, src=src+2
if method=1 AND disp=0 then goto @@decompress_done
if method=2 AND len=12h then     ;special fill mode...
len=disp/100h+3, val=disp AND FFh               ;len=3..12h
if len=3 then len=val+13h, val=[src], src=src+1 ;len=13h..112h
for i=1 to len, [dst]=val, dst=dst+1, next i    ;len=4..112h
else
for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
endif
goto @@decompress_lop
@@decompress_done:
ret
```

CDROM File Compression PCK (Destruction Derby Raw)

**Destruction Derby Raw (MagDemo35: DDRAW\*.PCK,EXE,DAT)**

```
000h 3     Decompressed size (24bit, little-endian)
003h 1     Unused (0)
004h ...   LZSS compressed data, starting with 30bit+2bit flags
```

The compression is used in some ISO files, which can be detected as:

```
[03h]=00h, [04h]=00h, [08h]="PS-X EXE"                ;DDRAW\*.EXE
[03h]=00h, [04h] AND FCh=00h, [08h]="BC",04h,40h,0,0  ;DDRAW\LDPICS\*.PCK
```

The compression is also used in nested PTH+DAT archives (where the whole DAT is
compressed), which can be detected by checking if the sum of the PTH filesizes
exceeds the DAT filesize.

**Self-decompressing GUI code in PSX BIOS for SCPH-7000 and up**

The PSX BIOS seems to use the same LZSS format for the self-decompressing GUI
code (with GUI/decompression starting at 80030000h).

**Decompression function**

```
dst_end=dst+LittleEndian24bit[src], src=src+4
@@collect_more:
flagbits=BigEndian32bit([src]), src=src+4
dispbits=14-(flagbits AND 03h), flagbits=(flagbits OR 3)-1
dispmask=(1 SHL dispbits)-1
@@decompress_lop:
flagbits=flagbits SHL 1    ;32bit shift with carry-out/zeroflag
if zero then goto @@collect_more
if carry=0 then
[dst]=[src], dst=dst+1, src=src+1
else
disp=BigEndian16bit[src], src=src+2
len=(disp SHR dispbits)+3
disp=(disp AND dispmask)+1
for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
endif
id dst
CDROM File Compression GT20 and PreGT20

**GT20 Compressed Files**

Used by Rollcage (MagDemo19: ROLLCAGE\SPEED.IMG\*)

Used by Rollcage Stage II (MagDemo31: ROLLCAGE\SPEED.IDX\*)

Used by Sydney 2000 (MagDemo37: OLY2000\DEMO.IDX\* and OLY2000\GTO\*.GTO)

Reportedly also Chill (PS1) (*.GTO)

Reportedly also Ducati World: Racing Challenge

Reportedly also Martian Gothic: Unification (PS1) (*.GT20)

```
000h 4     ID ("GT20"=Compressed) (or reportedly "NOGT"=Uncompressed)
004h 4     Size of decompressed data in bytes
008h 4     Overlap for in-situ decompression (usually 3, or sometimes 7)
00Ch 4     Size of Leading Zeropadding in bytes (0..7FFh)
010h ..    Leading Zeropadding (0..7FFh bytes)
...  ..    Compressed Data
```

The Leading Zeropadding can be used to arrange the data to end on a sector
boundary (useful when loading the file in units of whole sectors, and wanting
to load it to the end of the decompression buffer).

```
DecompressGT20:
src=src+word[src+0Ch]+10h      ;skip header and any leading zeropadding
collected=00000001h  ;end-bit
@@lop:
if GetBit=0
[dst]=[src], dst=dst+1, src=src+1               ;uncompressed byte
else
if GetBit=0
disp=byte[src]-100h, src=src+1                ;disp=(-100h..-1)
len=(GetBit*2)+(GetBit*1)+2                   ;len=(2..5)
else
tmp=halfword[src], src=src+2
disp=(tmp/8)-2000h                            ;disp=(-2000h..-1)
len=(tmp AND 7)+2                             ;len=(2..9)
if len=2
tmp=byte[src], src=src+1
if (tmp AND 80h) then disp=disp-2000h       ;disp=(-4000h..-1)
len=(len AND 7Fh)+2                         ;len=(2..81h)
if len=3 then goto decompression_done
if len=2 then len=halfword[src], src=src+2  ;len=(0..FFFFh)
for i=1 to len, [dst]=[dst+disp], dst=dst+1, next i
goto @@lop
;---
GetBit:
collected=collected SHR 1
if zero then collected=(word[src] SHR 1)+80000000h, src=src+4
return carry (from shift right)
```

Note: Uncompressed files can reportedly contain "NOGT" in the header, however,
Rollcage does have compressed files (with GT20 header), and raw uncompressed
files (without any NOGT header).

See also: https://zenhax.com/viewtopic.php?t=13175
(specs)

See also: http://wiki.xentax.com/index.php/GT20_Archive
(blurp)

**Pre-GT20 Compressed Files**

Used by Bloody Roar 1 (MagDemo06: BL\*.DAT\*)

Used by Bloody Roar 2 (MagDemo22: ASC,CMN,EFT,LON,SND,ST5,STU\*.DAT\*)

```
000h 4    Compression Method (0=None, 2=Compressed, Other=Invalid)
004h 4    Compressed Size (SIZ) (same as decompressed when method=0)
008h 4    Decompressed Size
00Ch SIZ  Compressed Data
...  ..   Garbagepadding to 4-byte boundary (in 4-byte aligned DAT files)
```

This is apparently on older version of what was later called GT20. The PreGT20
decompression works as so:

```
DecompressPreGT20:
src=src+0Ch                    ;skip header
collected=80h  ;end-bit
@@lop:
if GetBit=1
[dst]=[src], dst=dst+1, src=src+1               ;uncompressed byte
else
if GetBit=0
len=(GetBit*2)+(GetBit*1)+2                   ;len=(2..5)
disp=byte[src]-100h, src=src+1                ;disp=(-100h..-1)
else
tmp=bigendian_halfword[src], src=src+2
disp=(tmp/8)-2000h                            ;disp=(-2000h..-1)
len=(tmp AND 7)+2                             ;len=(2..9)
if len=2
len=byte[src]+1, src=src+1                  ;len=(1..100h)
if len=1 then goto decompression_done
for i=1 to len, [dst]=[dst+disp], dst=dst+1, next i
goto @@lop
;---
GetBit:
collected=collected SHL 1    ;8bit shift
if zero then collected=(byte[src] SHL 1)+01h, src=src+1
return carry (from 8bit shift left)
```

Note: Uncompressed files with Method=0 exist in Bloody Roar 2 (CMN\SEL01.DAT).

Bloody Roar 1 (MagDemo06) has decompressor at 8016DD64h (method 0 and 2).

Bloody Roar 2 (MagDemo22) has decompressor at 8015C8C0h (method 0 and 2).

CDROM File Compression LZS (Gundam Battle Assault 2)

**Gundam Battle Assault 2 (DATA\*.PAC\*, with ID="lzs")**

```
000h 4     ID ("lzs",00h)
004h 4     Zerofilled
008h 4     Fixed (must be 1) (method/version?)
00Ch 14h   Zerofilled
020h 2     Fixed (must be 3) (method/version?)
022h 2     Offset to Compressed Data minus 20h (usually 38h-20h)
024h 4     Decompressed Size
028h 2     Flagsize (must be 08h, 10h, or 20h) (usually 20h=32bit)
02Ah 2     Lensize  (must be 02h..07h)         (usually 05h=5bit)
02Ch 4     Compressed Size (total filesize, including "lzs" header)
030h 8     Name? (always "000000",00h,00h)
038h ..    Compressed data (usually at offset 38h)
```

decompress_gundam_lzs:

```
dst_end = dst+littleendian32bit[src+24h]
flg_bits = littleendian16bit[src+28h]   ;8,16,32
len_bits = littleendian16bit[src+2Ah]   ;2..7
len_mask = (1 shl len_bits)-1           ;03h..7Fh
src=src+littleendian16bit[src+22h]+20h
collected_bits=0
@@collect_more:
for i=0 to flg_bits/8-1    ;read 8bit/16bit/32bit little-endian
collected_bits=collected_bits+([src] SHL (i*8)), src=src+1
num_collected=flg_bits
@@decompress_lop:
if dst=dst_end then goto @@decompress_done
if num_collected=0 then goto @@collect_more
num_collected=num_collected-1
flagbits=flagbits SHR 1
if carry=1 then
[dst]=[src], dst=dst+1, src=src+1
else
temp=bigendian16bit[src], src=src+2
len=(temp AND len_mask)+3
disp=(temp SHR len_bits), if disp=0 then goto @@decompress_error
for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
endif
goto @@decompress_lop
@@decompress_done:
ret
```

CDROM File Compression RESOURCE (Star Wars Rebel Assault 2)

**Star Wars Rebel Assault 2 (RESOURCE.*\*)**

**BallBlazer Champions (*.DAT)**

```
decompression function:
base=src, method=[src], dst_end=dst+BigEndian24bit[src+1], src=src+4
@@decompress_lop:
if dst>=dst_end then goto @@decompress_done
if [src] AND 80h then
if method=01h then
len=([src]-80h)/8+3, disp=(BigEndian16bit[src] AND 7FFh)+1, src=src+2
else  ;method=02h
len=([src]-80h)+4, disp=(BigEndian16bit[src+1])+1, src=src+3
for i=1 to len, [dst]=[dst-disp], dst=dst+1
else    ;uncompressed
len=[src]+1, src=src+1
for i=1 to len, [dst]=[src], src=src+1, dst=dst+1
goto @@decompress_lop
@@decompress_done:
src=(src+3) AND NOT 3
if LittleEndian32bit[src]<>crc(base, src-base) then error
ret
```

Note: Compression is (normally) used only in Top-level RESOURCE.* and *.DAT
archives (not in Nested archives). The Top-level archives do also contain some
uncompressed files (which contain data that is compressed on its own: SPU-ADPCM
audio, or encrypted BS bitmaps).

**Special case for BallBlazer Champions**

Normally only Top-level archives contain compression, however, there are also
some Nested archives with compression in BallBlazer Champions:

```
STD_BBX.DAT\s*t\tp_a\*    ;\double compression, Top-level is ALSO compressed
BBX_INTR.DAT\data1\pics\* ;/
BBX_INTR.DAT\Stad\pics\*  ;\
BBX_INTR.DAT\Stad\wire\*  ; Nested archives with compression
BBX_INTR.DAT\Subtitl\*    ;
BBX_INTR.DAT\Subtitl\sub\*;/
```

The Nested archives don't have any compression flag or decompressed size
entries (so there's no good way for detecting compression in nested files).

CDROM File Compression RLE_16

**Apocalypse (MagDemo16: APOC\CD.HED\*.RLE)**

**Spider-Man (MagDemo31,40: SPIDEY\CD.HED\*.RLE)**

**Spider-Man 2 (MagDemo50: HARNESS\CD.HED\*.RLE)**

```
000h 8     ID "_RLE_16_"
008h 4     Decompressed Size (usually 3C008h) (33408h=Apocalypse warning.rle)
00Ch ..    RLE Compressed Data (usually a .BMR bitmap)
```

This is using simple RLE compression with 16bit len/data units (suitable for
16bpp VRAM data). The compression ratio ranges from not so bad to very bad.

**Decompression**

```
src=src+0Ch                                       ;skip ID and size
@@decompress_lop:
len=halfword[src], src=src+2
if len=0000h then goto @@decompress_done          ;end-code
if (len AND 8000h)=0 then
for i=1 to len, halfword[dst]=halfword[src], dst=dst+2, src=src+2, next i
else
fillvalue=halfword[src], src=src+2
for i=1 to len-8000h, halfword[dst]=fillvalue, dst=dst+2, next i
goto @@decompress_lop
@@decompress_done:
ret
```

**Other RLE16 variants**

A similar RLE16 variant is used in Croc 1, and another variant in Croc 2.

CDROM File Archive Croc 1 (DIR, WAD, etc.)

CDROM File Archive Croc 2 (DIR, WAD, etc.)

CDROM File Compression BPE (Byte Pair Encoding)

Byte Pair Encoding (BPE) does replace the most common byte-pairs with bytes
that don't occur in the data. That does work best if there are unused bytes
(eg. ASCII text, or 8bpp bitmaps with less than 256 colors).

**Bust A Groove (MagDemo18: BUSTGR_A\*.BPE)**

**Bust-A-Groove 2 (MagDemo37: BUSTAGR2\BUST2.BIN\*)**

```
000h 4     ID "BPE_"
004h 4     Total Filesize of compressed file including header (big-endian)
...  ..    Compression block(s)
Each compression block contains:
000h ..    Dictionary info
...  2     Size of compressed data (big-endian)
...  ..    Compressed data
```

The decompression function in Bust A Groove (MagDemo18) is at 80023860h, the
heap is in 1Kbyte Scratchpad RAM at 1F800208h, so heap size should be max 1F8h
bytes (assuming that the remaining Scratchpad isn't used for something else).
The fileheader lacks info about the decompressed size.

**Legend of Dragoon (MagDemo34: LOD\OVL\*.OV_ and LOD\SECT\*.BIN\*)**

```
000h 4     Decompressed size (little-endian)
004h 4     ID "BPE",1Ah
008h ..    Compression block(s)
...  ..    End code (00000000h) (aka last block with Blocksize=0)
Each compression block contains:
000h 4     Size of decompressed block (little-endian) (or 0=End code)
004h ..    Dictionary info
...  ..    Compressed data
...  ..    Padding to 4-byte boundary
```

Max nesting appears to be 2Ch, the decompression function allocates a 30h-byte
heap on stack, and fetches source data in 32bit units (occupying 4 heap bytes),
the decompressor does then remove 1 byte from heap, and adds 2 bytes in case of
nested codes.

**BPE Decompression for Bust-A-Groove and Legend of Dragoon**

```
if [src+0]="BPE_" then type=GROOVE                                    ;\
if [src+4]="BPE",1Ah then type=DRAGOON                                ;
if type=GROOVE then src_end = src+BigEndian32bit[src+4]               ; hdr
if type=DRAGOON then dst_end = dst+LittleEndian32bit[src+0]           ;
src=src+8                                                             ;/
@@block_lop:
if type=DRAGOON then                                                  ;\blk
dst_blk_end = dst+LittleEndian32bit[src]+4, src=src+4               ; len
if dst=dst_blk_end then goto @@decompress_done                      ;/
for i=00h to FFh, dict1[i]=i, next i                                  ;\
i=00h                                                                 ;
@@dict_lop:                                                            ; dict
num=[src], src=src+1                                                  ;
if num>7Fh then i=i+(num-7Fh), num=0, if i=100h then goto @@dict_done ;
for j=0 to num                                                        ;
a=[src], src=src+1                                                  ;
if a<>i then b=[src], src=src+1, dict1[i]=a, dict2[i]=a             ;
i=i+1                                                               ;
if idst_end then error
ret
```

**Electronic Arts**

Electronic Arts games support several compression methods, including a BPE
variant. That BPE variant is a bit unusual: It does have only one compression
block (with a single dictionary for the whole file), and uses escape codes for
rarely used bytes.

CDROM File Compression EA Methods

CDROM File Compression Darkworks

Used by Alone in the Dark The New Nightmare (FAT.BIN\LEVELS\*\chunks)

**Decompression**

The decompressor is designed to hook the sector loading function: It does
decompress incoming sectors during loading, and forwards the decompressed data
to the original sector loading function. The decompressed data is temporarily
stored in two small Dict buffers (which do also serve as compression
dictionary).

```
decompress:
dictsize=1000h, dict0=alloc(dictsize), dict1=alloc(dictsize)
src=load_next_800h_byte_sector  ;load first sector
dst=dict0                       ;temp dest in current dict
dst_base=dst                    ;memorize start of newly decompressed data
@@decompress_lop:
if [src]=00h then                                             ;\
esc=[src+1], src=src+1                                      ;
forward_to_actual_dest(source=dst_base, len=dst-dst_base)   ; escape
if esc=0 or esc>4 then esc=2 (or warn_invalid_escape_code)  ;
if esc=1 then goto @@decompress_done                        ;
if esc=2 or esc=4 then src=load_next_800h_byte_sector       ;
if esc=3 or esc=4 then swap(dict0,dict1), dst=dict0         ;
dst_base=dst                                                ;/
elseif ([src] AND 03h)=0 then                                 ;\
len=[src]/4+2, dat=[src+1], src=src+2                       ; fill 8bit
for i=1 to len, [dst]=dat, dst=dst+1                        ;/
elseif ([src] AND 03h)=1 then                                 ;\
len=[src]/4+([src+2] AND 40h)+4                             ;
ptr=[src+1]+([src+2] AND 3Fh)*100h                          ; LZ compressed
if ptr+len>dictsize then error (exceeds allocated dictsize) ;
if ([src+2] AND 80h) then ptr=ptr=dict1 else ptr=ptr=dict0  ;
src=src+3                                                   ;
for i=1 to len, [dst]=[ptr], ptr=ptr+1, dst=dst+1           ;/
elseif ([src] AND 03h)=2 then                                 ;\
len=[src]/4+3, dat0=[src+1], dat1=[src+2], src=src+3        ; fill 16bit
for i=1 to len, [dst]=dat0, [dst+1]=dat1, dst=dst+2         ;/
elseif ([src] AND 03h)=3 then                                 ;\
len=[src]/4+1, src=src+1                                    ; uncompressed
for i=1 to len, [dst]=[src], src=src+1, dst=dst+1           ;/
goto @@decompress_lop
@@decompress_done:
dealloc(dict0), dealloc(dict1)
ret
```

There are one or more escape codes per sector (one to indicate the of the
sector, plus further escape codes to swap the Dict buffers whenever the current
Dict is full).

The original decompressor is doing the forwarding in 800h-byte units, so Dict
swapping may be only done when dict0 contains a multiple of 800h bytes (aka
dictsize bytes).

For whatever reason, there are only 4Kbyte per Dict allocated (although the
14bit LZ indices could have addressed up to 16Kbyte per Dict).

CDROM File Compression Z (Running Wild)

**Running Wild (MagDemo15: RUNWILD\*.BIN\*.Z and *.z)**

```
decompress_z:
src=src+4            ;skip 32bit decompressed size entry
@@reload_lop:
load_table1          ;table for first 9bits
load_table2          ;table for codes longer than 9bits
@@decompress_lop:
sym=get_symbol()
if sym0 then for i=0 to num-1, table2[i]=GetBits(9), next i
ret
;-----
get_symbol:
;returns a value in range 0..140h:
;  00h..FFh   = data 00h..FFh   (or unused for disp codes)
;  100h       = escape          (or unused for disp codes)
;  101h..140h = length 05h..44h (or 6bit fraction of 12bit disp)
;  141h..3FFh = would be possible for short codes, but shouldn't be used
x=table1[PeekBits(9)]
if (x and 8000h)=0 then SkipBits(x/400h), return (x and 3FFh)  ;-short code
SkipBits(9)   ;skip first 9 bits, and process futher bit(s)..  ;\
x=x-0C000h    ;change C000h..C1FFh and up to 000h..1FFh        ; long code
@@lop:                                                          ; (with more
x=table2[x*2+GetBits(1)]             ;branch node0/node1       ; than 9bit)
if x>=141h then x=x-141h, goto @@lop                           ;
return x                                                       ;/
```

The bitstream is fetched in little endian 16bit units (the first bit is in bit7
of second byte). PeekBits returns the next some bits without discarding them,
SkipBits does discard them, GetBits does combine PeekBits+SkipBits.

Note: The decompression function in Running Wild (MagDemo15) is at 80029D10h.

CDROM File Compression EA Methods

**Electronic Arts Compression Headers**

The files start with a 16bit big-endian Method value, with following bits:

```
0-7     ID (usually FBh) (or 31h for Method 4A31h with 16bit sizes)
8       Extended Header (usually 0) (or 1 for headers with extra entries)
9-14    Used to distinguish different methods
15      Extended Size (usually 0 for 24bit sizes) (or 1 for 32bit sizes)
```

The most common Method values are:

```
10FBh = LZSS Compression (RefPack)
90FBh = LZSS Compression (RefPack, with 32bit size) (not on PSX)
30FBh = Huffman Compression
32FBh = Huffman Compression with filter
34FBh = Huffman Compression with dual filter
46FBh = BPE Byte-Pair Encoding
4AFBh = RLE Run-Length Encoding
4A31h = RLE Run-Length Encoding, with 16bit size
C0FBh = File Archive (not a compression method)
```

Most or all PSX files have Bit8=0, but anyways, the decompressor does support
skipping extra header entries in files with Bit8=1 (with all methods except
RLE).

Most or all PSX files have Bit15=0, games for newer consoles can reportedly
have Method=90FBh (unknown if anything like B2FBh or CAFBh does also exist).

Most or all PSX files have Bit0-7=FBh (supposedly short for Frank Barchard),
the 16bit mode with Bit0-7=31h is supported for Method=4A31h only (the
decompressor would also accept invalid methods like 1031h or 3431h, but doesn't
actually support 16bit mode for those).

**Compression Formats**

CDROM File Compression EA Methods (LZSS RefPack)

CDROM File Compression EA Methods (Huffman)

CDROM File Compression EA Methods (BPE)

CDROM File Compression EA Methods (RLE)

**Usage in PSX games**

The compression can be used to compress whole files:

```
PGA Tour 96, 97, 98 (*.* and *.VIV\*) (with method 10FBh)
Need for Speed 3 Hot Pursuit (*.Q* with method 10FBh, 30FBh, 32FBh)
```

Or to compress texture bitmaps inside of .PSH file chunks:

```
FIFA - Road to World Cup 98 (*.PSH chunk C0h/C1h with method 10FBh)
Sled Storm (MagDemo24: ART3\LOAD*.PSH chunk C0h/C1h with method 10FBh)
WCW Mayhem (MagDemo28: WCWDEMO\*.BIG\*.PSH with chunk C0h/C1h with 10FBh)
```

The decompressor supports further methods (like 34FBh, 46FBh, 4AFBh), but there
aren't any files or chunks known to actually use those compression formats.

Note: Some compressed files are slightly larger than uncompressed files (eg.
filesizes for PGA Tour 96, 97, 98 COURSES\*\*.VIV\*.mis are compressed=58h,
uncompressed=50h).

**See also**

http://wiki.niotso.org/RefPack
- LZ method

CDROM File Compression EA Methods (Huffman)

**Huffman**

```
000h 2    Method (30FBh..35FBh) (big-endian)
...  (3)  Extra 3 bytes (only present if Method.bit8=1)
...  3    Decompressed Size     (big-endian)
...  1    Escape code
...  ..   Number of codes per width
...  ..   Data placement for each code
...  ..   Compressed Data
```

**Huffman**

```
decompress_ea_huffman:
method=GetBits(16)    ;3xFBh                     ;-get method (30FBh..35FBh)
if method AND 100h then dummy=GetBits(24)        ;-skip extra (if any)
dst_size=GetBits(24)                             ;-get uncompressed size
ESC=GetBits(8)                                   ;-get escape code
huffwidth=0, huffcode=0, totalnumcodes=0         ;\
while (huffcode shl (10h-huffwidth))0  ;search Nth notyet defined entry    ;
dat=(dat+1) AND FFh  ;wrap in 8bit range!    ;
if data_defined_flags[dat]=0 then n=n-1      ;
data_defined_flags[dat]=1                      ;
data_values[index]=dat, index=index+1          ;/
huffcode=0000h, index=0                          ;\
InitEmptyHuffTree(data_tree)                     ;
for width=1 to huffwidth                         ;
for i=1 to numcodes_per_width[width]           ; create huffman tree
dat=data_values[index], index=index+1        ;
CreateHuffCode(data_tree,dat,huffcode,width) ;
huffcode=huffcode+(1 shl (10h-width)         ;/
@@decompress_lop:                                 ;\
dat=GetHuffCode(data_tree)                       ;
if dat<>ESC                                      ;
[dst]=dat, dst=dst+1                           ; decompress
else                                             ;
num=GetVarLenCode                              ;
if num=0 then                                  ;
if GetBits(1)=1 then goto @@decompress_done  ;
[dst]=GetBits(8), dst=dst+1                  ;
else                                           ;
dat=[dst-1]                                  ;
for i=0 to num-1, [dst]=dat, dst=dst+1       ;
goto @@decompress_lop                            ;/
@@decompress_done:
if (dst-dst_base)<>dst_size then error                 ;-error check
dst=dst_base, x=00h, y=00h                             ;\
if (method AND FEFFh)=32FBh                            ; optional final
for i=0 to dst_size-1, x=x+[dst+i], [dst+i]=x        ; unfiltering
if (method AND FEFFh)=34FBh                            ;
for i=0 to dst_size-1, x=x+[dst+i], y=y+x, [dst+i]=y ;/
ret
;------------------
GetVarLenCode:
num=2
while GetBits(1)=0, num=num+1
return (GetBits(num)+(1 shl num)-4)
GetBits(num):
return "num" bits, fetched from big-endian bitstream
GetHuffCode(data_tree):
...
InitEmptyHuffTree(data_tree):
...
CreateHuffCode(data_tree,dat,huffcode,width):
...
numcodes_per_width[10h]   ;9bit numcodes per width 0..15 (entry[0]=unused)
data_values[100h]         ;8bit data values for up to 100h huffman codes
data_defined_flags[100h]  ;1bit flags for data(00h..FFh)
```

CDROM File Compression EA Methods (RLE)

**Run-Length Encoding**

```
000h 2    Method (4AFBh=24bit or 4A31h=16bit) (big-endian)
...  2/3  Decompressed Size (24bit or 16bit)  (big-endian)
...  ..   Compressed Data
```

Compression codes are:

```
00h..3Fh  Copy 0..3Fh uncompressed bytes
40h..7Fh  Load new fillbyte and fill 0..3Fh bytes
80h..BFh  Use old fillbyte and fill 0..3Fh bytes (initial fillbyte=00h)
C0h..FFh  Copy 0..3Fh bytes with constant value in upper 4bit
```

decompress_bpe:

```
method=BigEndian16bit[src], src=src+2
if (method AND 00FFh)=31h then dst_size=BigEndian16bit[src], src=src+2
if (method AND 00FFh)<>31h then dst_size=BigEndian24bit[src], src=src+3
fillbyte=00h  ;initially zero
@@decompress_lop:
type=[src]/40h, len=[src] AND 3Fh, src=src+1, dst_size=dst_size-len
if type=0 then                                          ;\uncompressed bytes
for i=1 to len, [dst]=[src], src=src+1, dst=dst+1     ;/
elseif type=1 then                                      ;\
fillbyte=[src], src=src+1                             ; fill with new dat
for i=1 to len, [dst]=fillbyte, dst=dst+1             ;/
elseif type=2 then                                      ;\fill with old dat
for i=1 to len, [dst]=fillbyte, dst=dst+1             ;/
elseif type=3 then
x=[src], [dst]=x, src=src+1, dst=dst+1, x=x AND F0h
for i=2 to len      ;0 then goto @@decompress_lop
ret
```

Inflate - Core Functions

**tinf_uncompress(dst,src)**

```
tinf_init()                    ;init constants (needed to be done only once)
tinf_align_src_to_byte_boundary()
repeat
bfinal=tinf_getbit()          ;read final block flag (1 bit)
btype=tinf_read_bits(2)       ;read block type (2 bits)
if btype=0 then tinf_inflate_uncompressed_block()
if btype=1 then tinf_build_fixed_trees(), tinf_inflate_compressed_block()
if btype=2 then tinf_decode_dynamic_trees(), tinf_inflate_compressed_block()
if btype=3 then ERROR         ;reserved
until bfinal=1
tinf_align_src_to_byte_boundary()
ret
```

**tinf_inflate_uncompressed_block()**

```
tinf_align_src_to_byte_boundary()
len=LittleEndian16bit[src+0]                             ;get len
if LittleEndian16bit[src+2]<>(len XOR FFFFh) then ERROR  ;verify inverse len
src=src+4                                                ;skip len values
for i=0 to len-1, [dst]=[src], dst=dst+1, src=src+1, next i    ;copy block
ret
```

**tinf_inflate_compressed_block()**

```
repeat
sym1=tinf_decode_symbol(tinf_len_tree)
if sym1256
len  = tinf_read_bits(length_bits[sym1-257])+length_base[sym1-257]
sym2 = tinf_decode_symbol(tinf_dist_tree)
dist = tinf_read_bits(dist_bits[sym2])+dist_base[sym2]
for i=0 to len-1, [dst]=[dst-dist], dst=dst+1, next i
until sym1=256
ret
```

**tinf_decode_symbol(tree)**

```
sum=0, cur=0, len=0
repeat                         ;get more bits while code value is above sum
cur=cur*2 + tinf_getbit()
len=len+1
sum=sum+tree.table[len]
cur=cur-tree.table[len]
until cur
Inflate - Headers and Checksums

**tinf_gzip_uncompress(dst, destLen, src, sourceLen)**

```
src_start=src, dst_start=dst                 ;memorize start addresses
if (src[0]<>1fh or src[1]<>8Bh) then ERROR   ;check id bytes
if (src[2]<>08h) then ERROR                  ;check method is deflate
flg=src[3]                                   ;get flag byte
if (flg AND 0E0h) then ERROR                 ;verify reserved bits
src=src+10                                                 ;skip base header
if (flg AND 04h) then src=src+2+LittleEndian16bit[src]     ;skip extra data
if (flg AND 08h) then repeat, src=src+1, until [src-1]=00h ;skip file name
if (flg AND 10h) then repeat, src=src+1, until [src-1]=00h ;skip file comment
hcrc=(tinf_crc32(src_start, src-src_start) & 0000ffffh))   ;calc header crc
if (flg AND 02h) then x=LittleEndian16bit[src], src=src+2  ;get header crc
if (flg AND 02h) then if x<>hcrc then ERROR                ;verify header
tinf_uncompress(dst, destLen, src, src_start+sourceLen-src-8)  ;----> inflate
crc32=LittleEndian32bit[src], src=src+4   ;get crc32 of decompressed data
dlen=LittleEndian32bit[src], src=src+4    ;get decompressed length
if (dlen<>destLen) then ERROR                              ;verify dest len
if (crc32<>tinf_crc32(dst_start,dlen)) then ERROR          ;verify crc32
ret
```

**tinf_zlib_uncompress(dst, destLen, src, sourceLen)**

```
src_start=src, dst_start=dst         ;memorize start addresses
hdr=BigEndian16bit[src], src=src+2   ;get header
if (hdr MOD 31)<>0 then ERROR        ;check header checksum (modulo)
if (hdr AND 20h)>0 then ERROR        ;check there is no preset dictionary
if (hdr AND 0F00h)<>0800h then ERROR ;check method is deflate
if (had AND 0F000h)>7000h then ERROR ;check window size is valid
tinf_uncompress(dst, destLen, src, sourceLen-6)      ;------> inflate
chk=BigEndian32bit[src], src=src+4                   ;get data checksum
if src-src_start<>sourceLen then ERROR               ;verify src len
if dst-dst_start<>destLen then ERROR                 ;verify dst len
if a32<>tinf_adler32(dst_start,destLen)) then ERROR  ;verify data checksum
ret
```

**tinf_adler32(src, length)**

```
s1=1, s2=0
while (length>0)
k=max(length,5552)    ;max length for avoiding 32bit overflow before mod
for i=0 to k-1, s1=s1+[src], s2=s2+s1, src=src+1, next i
s1=s1 mod 65521, s2=s2 mod 65521, length=length-k
return (s2*10000h+s1)
```

CDROM File Compression UPX

**UPX Compression (used in AmiDog's GTE test)**

UPX is a tool for creating self-decompressing executables. It's most commonly
used for DOS/Windows EXE files, but it does also support consoles like PSX. The
PSX support was added in UPX version 1.90 beta (11 Nov 2002).

```
000h 88h      Standard PS-X EXE header
088h 20h      Unknown
0A8h 4        ASCII ID "UPX!"
0ACh 1Eh      Unknown
0CAh 9Ah      ASCII "$info: This file is ..."
164h 69Ch     Zerofilled
800h ..       Leading zeropadding (to make below end on 800h-byte boundary)
...  ..       Decompression stub
...  ..       Compressed data (ending on 800h-byte boundary)
```

CDROM File Compression XZ

**Overall Structure of .xz File**

```
000h ..  Stream(s)
```

Note: To determine the total uncompressed size, one must process the file
backwards, starting at footer of last stream.

**Stream**

```
000h 6   Header ID (FDh,"7zXZ",00h) (FDh,37h,7Ah,58h,5Ah,00h) ;\
006h 2   Checksum Type (0000h, 0100h, 0400h or 0A00h)         ; Header
008h 4   Header CRC32 on above 2 bytes                        ;/
00Ch ..  Compressed Block(s)                                  ;-Block(s)
...  ..  Index List                                           ;-Index
...  4   Footer CRC32 on below 6 bytes                        ;\
...  4   Index List Size/4-1                                  ; Footer
...  2   Checksum Type (must be same as in Header)            ;
...  2   Footer ID ("YZ") (59h,5Ah)                           ;/
...  ..  Optional Zeropadding (multiple of 4 bytes)           ;-Padding
Checksum Type (for Block checksums):
0000h=None
0100h=CRC32 (little-endian)
0400h=CRC64 (little-endian)
0A00h=SHA256 (big-endian)
Other=Reserved
```

**Index List**

```
000h 1    Index Indicator (00h) (as opposed to 01h..FFh in Block Headers)
001h VL   Number of Records (must be same as number of Blocks in Stream)
...  ..   Index Record(s)
...  ..   Zeropadding to 4-byte boundary
...  4    CRC32 on above bytes
Index Record:
000h VL   Unpadded Block Size (BlockHeader + CompressedData + 0 + Checksum)
...  VL   Uncompressed Block Size
```

**Compressed Block**

```
000h 1    Block Header Size/4-1 (01h..FFh = 8..400h bytes)           ;\
001h 1    Block Flags                                                ;
002h (VL) Compressed Size     ;present if Flags.bit6 = 1             ; Header
...  (VL) Uncompressed Size   ;present if Flags.bit7 = 1             ;
...  ..   Filter Info 0 (LAST filter when DECOMPRESSING)             ;
...  (..) Filter Info 1       ;present if Flags.bit0-1 = 1,2,3       ;
...  (..) Filter Info 2       ;present if Flags.bit0-1 = 2,3         ;
...  (..) Filter Info 3       ;present if Flags.bit0-1 = 3           ;
...  ..   Zeropadding to 4-byte boundary                             ;
...  (..) Optional Zeropadding (multiple of 4 bytes)                 ;
...  4    CRC32 on above bytes                                       ;/
...  ..   Compressed Data                                            ;-Data
...  ..   Zeropadding to 4-byte boundary                             ;-Pad
...  (..) Checksum on uncompressed Data (None/CRC32/CRC64/SHA256)    ;-Check
Block Flags:
0-1  Number of filters-1                (0..3 = 1..4 filters)
2-5  Reserved (0)
6    Compressed Size field is present   (0=No, 1=Present)
7    Uncompressed Size field is present (0=No, 1=Present)
Filter Info:
000h VL   Filter ID
...  VL   Size of Filter Properties
...  ..   Filter Properties
Filter IDs:
03h                        Delta Filter       (with 1 byte param)
04h..09h                   Executable Filters (with 0 or 4 byte param)
21h                        LZMA2 Compression  (with 1 byte param)
300h..4FFh                 Reserved to ease .7z compatibility
20000h..7FFFFh             Reserved to ease .7z compatibility
2000000h..7FFFFFFh         Reserved to ease .7z compatibility
xxxxxxxxxxxxxxxxh          Custom Registered IDs (obtained from Lasse Collin)
3Frrrrrrrrrriiiih          Custom Random IDs (40bit random+16bit filterno)
4000000000000000h and up   Reserved for internal use (don't use in xz files)
```

Note: The first decompression filter must be LZMA2, which reads from compressed
data stream, and writes to decompressed data (and also implies the size of
compressed/decompressed data). The other filters (if any) are unfiltering the
decompressed data.

**Filter 21h: LZMA2 Compression Method**

This "filter" is the actual compression method (XZ supports only one method).

It can be combined with BCJ/Delta filters (whereas, LZMA2 must be always used
as LAST compression filter, aka FIRST decompression filter).

```
The filter parameter is 1 byte tall:
Dictionary Size byte (00h..28h = 4K,6K,8K,12K,16K,24K,..,2G,3G,4G)
The compressed data contains:
LZMA2 chunks (with LZMA-compressed data and/or uncompressed data)
```

**Filter 03h: Delta Filter**

The filter parameter is 1 byte tall:

```
Distance-1 (00h..FFh = distance 1..100h)
**unfilter_delta(buf,len,param_byte):**
dist=byte(param)+1, i=dist   ;init dist and skip first some unfiltered bytes
while i
CDROM File Compression ARJ

**ARJ archives contain several chunks**

```
Main header chunk
Local file chunk(s)
Chapter chunk(s), backup related, exist only in newer archives
End Marker
```

**ARJ main "comment" header, with [00Ah]=2**

This is stored at the begin of the archive. The format is same as for local
file header (but with file-related entries set to zero, or to global security
settings).

```
000h 2   ARJ ID (EA60h, aka 60000 decimal)
002h 2   Header size (from 004h up to including Filename+Comment) (max 2600)
004h 1   Header size (from 004h up to including Extra Data) (1Eh+extra)
005h 1   Archiver version number (01h..0xh)
006h 1   Minimum archiver version to extract (usually 01h)
007h 1   Host OS
008h 1   ARJ Flags (bit0-7, see below)
009h 1   Security version (2 = current)
00Ah 1   File Type        (must be 2=ARJ Comment in main header)
00Bh 1   Reserved/Garbage (LSB of Archive creation Date/Time, same as [00Ch])
00Ch 4   Date/Time when archive was created
010h 4   Date/Time when archive was last modified
014h 4   Zero  (or Secured Archive size, excluding Security and Protection)
018h 4   Zero  (or Security envelope file position) (after End Marker)
01Ch 2   Zero  (or Filespec position in filename) (0) (what is that??)
01Eh 2   Zero  (or Security envelope size in bytes) (78h, if any)
020h 1   Zero  (or >2.50?: Encryption version, 0-1=Old, 2=New, 4=40bit GOST)
021h 1   Zero  (or >2.50?: Last chapter (eg. 4 when having chapter 1..4)
022h (1) Extra data: ARJ Protection factor                         ;\extra,
023h (1) Extra data: ARJ Flags (bit0=ALTVOLNAME, bit1=ReservedBit) ; if any
024h (2) Extra data: Spare bytes                                   ;/
...  ..  Filename, max 500 bytes ("FILENAME.ARJ",00h)
...  ..  Comment, max 2048 bytes ("ASCII Comment",00h)
...  4   CRC32 on Header (from 004h up to including Comment)
...  2   Size of 1st extended header (usually 0=none)
...  (0) Extended Header(s?) (usually none such)
```

**ARJ local file header, with [00Ah]=0,1,3,4**

This occurs at the begin of each file in the archive.

```
000h 2   ARJ ID (EA60h, aka 60000 decimal)
002h 2   Header size (from 004h up to including Filename+Comment) (max 2600)
004h 1   Header size (from 004h up to including Extra Data) (1Eh+extra)
005h 1   Archiver version number
006h 1   Minimum archiver version to extract (usually 01h)
007h 1   Host OS
008h 1   ARJ Flags (bit0,2-5)
009h 1   Method
00Ah 1   File Type (0=Binary, 1=Text, 3=Directory Name, 4=Volume Name)
00Bh 1   Reserved/Garbage (LSB of Archive update Date/Time?)
00Ch 4   Date/Time modified
010h 4   Filesize, compressed (max 7FFFFFFFh)
014h 4   Filesize, uncompressed
018h 4   CRC32 on uncompressed file data
01Ch 2   Zero  (or Filespec position in filename) (what is that??)
01Eh 2   File access mode (aka MSDOS file attribute) (20h=Normal)
020h 1   Zero  (or >2.50?: first chapter of file's lifespan)
021h 1   Zero  (or >2.50?: last chapter of file's lifespan)
022h (4) Extra data: Extended file position (maybe for split?)  ;\extra,
026h (4) Extra data: Date/Time accessed                  ;\ARJ  ; 0,4 or 10h
03Ah (4) Extra data: Date/Time created                   ; 2.62 ; bytes
03Eh (4) Extra data: Original file size even for volumes ;/     ;/
...  ..  Filename, max 500 bytes ("PATH/FILENAME.EXT",00h)
...  ..  Comment, max 2048 bytes ("ASCII Comment",00h)
...  4   CRC32 on Header (from 004h up to including Comment)
...  2   Size of 1st extended header (usually 0=none)
...  (0) Extended Header(s?) (usually none such)
...  ..  Compressed file data
```

Entry 3Eh might be meant to contain Original Size of TEXT files (with CR,LFs),
however, the entry is just set to 00000000h in ARJ 2.75a. Or maybe it's meant
to mean size of whole file (in split-volumes)?

**ARJ backup "chapter" header (ARJ >2.50?) (exists in 2.75a), with [00Ah]=5**

This is rarely used and supported only in newer ARJ versions. The format is
same as for local file header (but with file-related entries being nonsense in
TECHNOTE; in practice, those nonsense values seem to be zero).

```
000h 2   ARJ ID (EA60h, aka 60000 decimal)
002h 2   Header size (from 004h up to including Filename+Comment) (max 2600)
004h 1   Header size (from 004h up to including Extra Data) (1Eh+extra)
005h 1   Archiver version number (eg. 0Ah=2.75a)
006h 1   Minimum archiver version to extract (usually 01h)
007h 1   Host OS
008h 1   ARJ Flags (usually 00h)
009h 1   Method (usually 01h, although chapters have no data)  what file???
00Ah 1   File Type (must be 5=ARJ Chapter)
00Bh 1   Reserved/Garbage (LSB of Chapter Date/Time, same as [00Ch])
00Ch 4   Date/Time stamp created
010h 4   Zero  (or reportedly, ?)                              what question?
014h 4   Zero  (or reportedly, ?)                              what question?
018h 4   Zero  (or reportedly, original file's CRC32)          what file???
01Ch 2   Zero  (or reportedly, entryname position in filename) what file???
01Eh 2   Zero  (or reportedly, file access mode)               what file???
020h 1   Chapter range start (01h=First chapter?)              what range???
021h 1   Chapter range end   (contains same value as above)    what range???
022h (4) Extra data: Extended file position (usually none such)what extra???
...  ..  Filename (">>",00h for First chapter)
...  ..  Comment  ("",00h)
...  4   CRC32 on Header (from 004h up to including Comment)
...  2   Size of 1st extended header (usually 0=none)
...  (0) Extended Header(s?) (usually none such)
```

**ARJ End Marker (with [002h]=0000h)**

This is stored at the end of the archive.

```
000h 2   ARJ ID (EA60h, aka 60000 decimal)
002h 2   Header size (0=End)
```

Note: The End Marker may be followed by PROTECT info and Security envelope.

**ARJ Method [009h]**

```
0 = stored (uncompressed)
1 = compressed most (default) (Window=6800h=26Kbyte, Chars=255, Tree=31744)
2 = compressed medium         (Window=5000h=20Kbyte, Chars=72, Tree=30720)
3 = compressed less           (Window=2000h=8Kbyte, Chars=32, Tree=30720)
4 = compressed least/fastest  (Window=6800h? or 8000h?)
8 = no data, no CRC  ;\unknown if/where that is used (maybe only used
9 = no data          ;/internally, and never stored in actual files?)
```

**ARJ File Type [00Ah]**

```
0 = binary file (default)
1 = text file (with converted line breaks, via -t1 switch)
2 = ARJ comment header (aka ARJ main file header)
3 = directory name
4 = volume label (aka disc name)
5 = ARJ chapter label (aka begin of newer backup sections)
```

**ARJ Flags (in Main [008h])**

```
0  GARBLED
1  OLD_SECURED   has old signature (with signature in Main Header?)
1  ANSIPAGE      ANSI codepage used by ARJ32 (for what? for "FILENAME.ARJ"?)
2  VOLUME        presence of succeeding volume
3  ARJPROT
4  PATHSYM       archive name translated ("\" changed to "/")
5  BACKUP        obsolete
6  SECURED       has new signature (in security envelope?)
7  ALTNAME       dual-name archive
```

**ARJ Flags (in Local [008h])**

```
0  GARBLED       passworded file
1  NOT USED
2  VOLUME        continued file to next volume (file is split)
3  EXTFILE       file starting position field (for split files)
4  PATHSYM       filename translated ("\" changed to "/")
5  BACKUP_FLAG   obsolete
```

**ARJ Flags (in Chapter [008h])**

```
0  GARBLED                          ;\
1  RESERVED                         ;
2  VOLUME                           ; what does that mean in Chapters???
3  EXTFILE                          ;
4  PATHSYM                          ;/
5  BACKUP        obsolete =dst_end then goto @@decompress_done
width=count_ones(max=7), len = get_bits(width) + (1 shl width)+1
if len=2 then
[dst]=get_bits(8), dst=dst+1
else ;len>=3
width=count_ones(max=4)+9, disp = get_bits(width) + (1 shl width)-1FFh
for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
goto @@decompress_lop
@@decompress_done:
ret
;---
count_ones(max):
num=0
@@lop:
if get_bits(1)=1 then
num=num+1, if num
CDROM File Compression RAR

RAR is a compression format for enthusiastic users (who love to download the
latest RAR version before being able to decompress those RAR files).

**RAR v1.3 (March 1994, used only in RAR 1.402)**

This format was only used by RAR 1.402, and discontinued after three months
when RAR 1.5 got released.

```
File Header:
000h 4     ID "RE~^" (aka 52h,45h,7Eh,5Eh)
004h 2     Header Size  (usually 0007h, or bigger when Comment/Ext1 exist)
006h 1     Archive Flags (80h or xxh)
...  (2)   Archive Comment Size   ;\Only present when ArchiveFlags.bit1=1
...  (..)  Archive Comment Data   ;/
...  (2)   Ext1 Size              ;\Only present when ArchiveFlags.bit5=1
...  (..)  Ext1 Data              ;/
...  ..    Unknown (TECHNOTE hints sth can be here, when bigger HeaderSize?)
Archive Flags:
0   Volume   (maybe related to split-volume on several floppies?)
1   Comment
2   Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
3   Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
4   Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
5   EXT1
6   Unspecified (maybe unused)
7   Unspecified (maybe unused, but... it's usually 1)
File Data blocks:
000h 4     Filesize, compressed
004h 4     Filesize, uncompressed
008h 2     Checksum on uncompressed? file (sum=LeftRotate16bit(sum+byte[i])
00Ah 2     Header Size (usually 0015h+FilenameLength)
00Ch 4     File Modification Timestamp in MSDOS format
010h 1     File Attribute in MSDOS format (20h=Normal)
011h 1     Flags
012h 1     Version (0=0.99, 1=1.00, 2=1.30) (always 2 in public version)
013h 1     Filename Length
014h 1     Method (00h=m0a=Stored, 03h=m3a=Default) (1..5 = fastest..best)
...  (2)   File Comment Length        ;\Only present if FileFlags.bit3=1
...  (..)  File Comment Data          ;/
...  ..    Filename ("PATH\FILENAME.EXT", without any end marker)
...  ..    Unknown (TECHNOTE hints sth can be here, when bigger HeaderSize?)
...  ..    Compressed file data
File Flags:
0   Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
1   Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
2   Unknown? (non-english description is in 1.402's TECHNOTE.DOC)
3   Comment  (non-english description is in 1.402's TECHNOTE.DOC)
4-7 Unspecified (maybe unused)
```

**RAR 1.5 (June 1994) and newer**

Overall Chunk Format:

```
000h 2    Chunk Header CRC; Lower 16bit of CRC32 on [002h..HdrSize-1 or less]
002h 1    Chunk Type (72h..7Ah)
003h 2    Chunk Flags
005h 2    Chunk Header Size
007h (4)  Data block size    ;
CDROM File Compression nCompress.Z

nCompress is some kind of a Gzip predecessor. The program was originally called
"compress" and later renamed to "ncompress" (and sometimes called
"(n)compress"). Compressed files have uppercase ".Z" attached to their original
name.

**nCompress.Z**

The header is rather small and lacks info on decompressed size (ie. the one
must process the whole bitstream to determine the size, and accordingly, the
fileformat doesn't allow padding to be appended at end of file). To detect .Z
files, examine the first three bytes, and best also check that the leading 9bit
codes don't exceed num_codes (with num_codes increasing from 101h and up for
each new code).

```
000h 2    ID (1Fh,9Dh)
002h 1    Mode (MaxBits(9..16) + bit7=WithClearCode) (usually 90h)
003h ..   ClearGap LZW compressed data (or raw LZW when mode.bit7=0)
```

Compression is relative straight LZW, resembling 8bit GIFs, with 9bit initial
codesize, with preset codes 000h..0FFh=Data and (optional) 100h=Clear code
(there is no End code). Codes are allocated from 101h and up (100h and up if
without Clear code).

The bitstream is fetched LSB first (starting in bit0 of first byte). The
decoder is prefetching groups of eight codes (N-bytes with eight N-bit codes),
the odd part is that Clear codes are discarding those prefetched bytes (so
Clear codes will be followed by Gaps with unused bytes).

ClearGap LZW is also used by ARC Method 8 and 9.

CDROM File Compression MacBinary, BinHex, PackIt, StuffIt, Compact Pro

Below are related to MAC filesystems (where the file body consists of separate
Data and Resource forks), and file type/creator values (resembling filename
extensions).

**MacBinary I,II,III format (v1,v2,v3)**

MacBinary contains a single uncompressed file, used for transferring MAC files
via network, or storing MAC files on non-MAC filesystems.

PackIt/StuffIt archives do often have leading MacBinary headers. MacBinary
doesn't have any unique filename extension (.bin may be used, more often it's
using the same extension as the enclosed file, eg. .sit if it contains a
StuffIt archive).

Also, archives without explicit MAC support may use MacBinary format within
compressed files (eg. LZH archives created with LHA MAC version).

```
000h 1   Old version number, must be kept at zero for compatibility
001h 1   Length of filename (1..63) (though v3 says 1..31)
002h 63  Filename (only "length" bytes are significant)
041h 4   File type    (normally expressed as four characters)
045h 4   File creator (normally expressed as four characters)
049h 1   Finder flags, bit8-15 (see [065h] for bit0-7)
04Ah 1   Zero (must be 00h for compatibility)
04Bh 2   File Vertical position within its window
04Dh 2   File Horizontal position within its window
04Fh 2   File Window or folder ID
051h 1   Protected flag (bit0=Protected, whatever that is)
052h 1   Zero (must be 00h for compatibility)
053h 4   Filesize, Data Fork     (0=None)
057h 4   Filesize, Resource Fork (0=None)
05Bh 4   File Timestamp, creation
05Fh 4   File Timestamp, last modification
063h 27  v1:    Reserved (zerofilled)
063h 2   v2/v3: Length of Get Info comment (if any, usually 0000h)
065h 1   v2/v3: Finder Flags, bit0-7 (see [049h] for bit8-15)
066h 6   v2:    Reserved (zerofilled)
066h 4   v3:    ID ("mBIN"=MacBinary III)
06Ah 1   v3:    Script of file name (from fdScript field of an fxInfo record)
06Bh 1   v3:    Extended Finder flags (from fdXFlags field of fxInfo record)
06Ch 8   v2/v3: Reserved (zerofilled)
074h 4   v2/v3: Length of "total files" when "packed files are unpacked", uh?
078h 2   v2/v3: Extended Header size (reserved for future, always 0000h)
07Ah 1   v2/v3: MacBinary II uploader version           (81h=v2, 82h=v3)
07Bh 1   v2/v3: MacBinary II downloader minimum version (81h=v2)
07Ch 2   v2/v3: CRC16-XMODEM on [000h..07Bh]
07Eh 2   Reserved for computer type and OS ID (0000h)
...  ..  Extended Header (if any, maybe stored here? when [078h]>0)
...  ..  Padding to 80h-byte boundary
...  ..  Data Fork (if any)
...  ..  Padding to 80h-byte boundary
...  ..  Resource Fork (if any)
...  ..  Padding to 80h-byte boundary
...  ..  Get Info comment (if any, usually none)
```

CRC16-XMODEM: http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

**BinHex 4.0 (.hqx) (ASCII, RLE90, big-endian)**

Decoding binhex files is done via following steps (in that order):

```
1) ASCII to BINARY conversion (similar to BASE64)
2) RLE90 decompression of whole file (header+data+resource+crc's)
3) Processing the header+data+resource from the decompressed binary
4) For Multipart files, repeat above steps for each part
```

ASCII to BINARY:

```
The file may start with some text message, comments, description. Skip any
such text lines until reaching a line that contains this 45-byte ID string:
(This file must be converted with BinHex 4.0)
That line should be followed by following characters (each char representing
6bit binary value, MSB first, first char is bit7-2 of first byte):
!"#$%&'()*+,-    char(21h..2Dh) --> bin(00h..0Ch)
0123456          char(30h..36h) --> bin(0Dh..13h)
89               char(38h..39h) --> bin(14h..15h)
@ABCDEFGHIJKLMN  char(40h..4Eh) --> bin(16h..24h)
PQRSTUV          char(50h..56h) --> bin(25h..2Bh)
XYZ[             char(58h..5Bh) --> bin(2Ch..2Fh)
`abcdef          char(60h..66h) --> bin(30h..36h)
hijklm           char(68h..6Dh) --> bin(37h..3Ch)
pqr              char(70h..72h) --> bin(3Dh..3Fh)
:                char(3Ah)      --> start/end marker
CR/LF            char(0Dh/0Ah)  --> linebreaks per 64 chars (CR and/or LF)
SPC/TAB          char(09h/20h)  --> blanks (reportedly in some files)
```

RLE90 Decompression:

```
RLE90 decompression is same as in ARC files, except, code 90h,00h is handled
differently: ARC keeps prevbyte=unchanged, BinHex sets prevbyte=90h.
RLE90 compression is somewhat optional: 90h must be encoded as 90h,00h,
but many encoders don't bother to compress repeating bytes (eg. many files
contain "!!!!!!!!" chars aka uncompressed 00h-filled bytes).
There is no way to know the decompressed size before decompression (either
decompress the whole file and allocate more memory as needed, or decompress
only the header (filename+16h bytes) and then compute decompressed size as
filename+16h+data+2+resource+2 bytes).
```

Decompressed Binary (big-endian):

```
The decompressed binary contains following data (similar as MacBinary):
00h   1    Length of Filename (1..63)
01h   ..   Filename ("FILENAME.EXT")
01h+N 1    Version (00h)
02h+N 4    File Type
06h+N 4    File Creator
0Ah+N 2    Finder Flags
0Ch+N 4    Filesize, uncompressed, Data Fork
10h+N 4    Filesize, uncompressed, Resource Fork
14h+N 2    Header CRC16-XMODEM on uncompressed 14h+N bytes
16h+N ..   Data Fork
...   2    Data Fork CRC16-XMODEM on uncompressed Data Fork
...   ..   Resource Fork
...   2    Resource Fork CRC16-XMODEM on uncompressed Resource Fork
...   ..   Padding (might reportedly occur in some files)
Caution: There is a document that does claim that the CRC field should be be
set to 0000h before CRC calculation, and that the CRC would be computed on
Size+2 bytes (up to including he CRC field), that appears to be nonsense,
the CRC is computed on Size+0 bytes, not Size+2.
```

Multipart files:

```
Emails or other text documents may contain multiple binhex files, if so,
each part should be reportedly followed by a line containing:
--- end of part NN ---
Unknown if there are any .hqx files with such multipart stuff.
Unknown if the next part starts with "(This file must.." or just with ":".
```

Note: Many files with .hqx extension are actually raw .sit or .cpt files (maybe
because somebody had removed the binhex encoding without altering the filename
extension).

**PackIt (.pit) (Macintosh) (1986) (big-endian)**

MAC File Type,Creator IDs = "PIT ","PIT " <-- normal (=uncompressed?)

MAC File Type,Creator IDs = "PIT ","UPIT" <-- other (=compressed?)

```
Bitstream for Uncompressed File Entries:
32bits    Uncompressed Header[000h..003h] (Method/Crypto="PMag")
..bits    Uncompressed Header[004h..061h] (uncompressed size = 5Eh)
..bits    Uncompressed Data+Resource+CRC  (uncompressed size = Data+Rsrc+2)
Bitstream for Compressed File Entries:
32bits    Uncompressed Header[000h..003h] (Method/Crypto="PMa4")
..bits    Compressed Huffman Tree         (for decoding following bits)
..bits    Compressed Header[004h..061h]   (uncompressed size = 5Eh)
..bits    Compressed Data+Resource+CRC    (uncompressed size = Data+Rsrc+2)
..bits    Padding to 8bit-boundary        (byte align next File Entry)
Bitstream for Archive End Marker (after last file):
32bits    Uncompressed Header[000h..003h] (Method/Crypto="PEnd")
File Entry Format:
000h 4    Method/Crypto (usually "PMag"=Uncompressed, "PMa4"=Huffman)
004h 1    Filename length
005h 63   Filename ("FILENAME", garbage padded)
044h 4    File Type
048h 4    File Creator
04Ch 2    Finder flags
04Eh 2    Locked?
050h 4    Filesize, uncompressed, Data fork
054h 4    Filesize, uncompressed, Resource fork
058h 4    Timestamp, creation
05Ch 4    Timestamp, modification
060h 2    CRC16-XMODEM on [004h..05Fh]
...  ..   Data Fork
...  ..   Resource Fork
...  2    CRC16-XMODEM on uncompressed Data+Resource forks
Method/Crypto:
"PEnd" = Archive End marker (4-byte end marker, without filename etc.)
"PMag" = Uncompressed
"PMa1" = Uncompressed, Encrypted Simple
"PMa2" = Uncompressed, Encrypted DES
"PMa3" = Uncompressed, Encrypted reserved
"PMa4" = Huffman
"PMa5" = Huffman, Encrypted Simple
"PMa6" = Huffman, Encrypted DES
"PMa7" = Huffman, Encrypted reserved
Decompression:       ;for PackIt (and also for StuffIt method 03h)
InitBitstreamMsbFirst(src)             ;-src is after "PMa4" PackIt ID
tree=GetMem(200h*4)                    ;-alloc tree (probably less needed)
num_entries=0                          ;\init tree
root=GetTreeEntry                      ;/
while dst82h)
xxh               Output xxh (unless it is 81h)
Note: prevbyte is the previous output byte (ie. that stored at [dst-1]).
If the uncompressed file ends with 81h, then the compressed file MUST contain
a dummy padding byte (the RLE decoder in macutils sets a prefix flag upon 81h,
but doesn't output it to dst until receiving the padding byte, which could be
81h, or any value other than 82h).
```

LZSSHUF Compression:

```
This uses LZSS-style flag bits (to distinguish between data and len/disp),
combined with three Huffman trees (for data, len, disp values). The sliding
window is 2000h bytes (8Kbytes). The format appears to be a simplified variant
or LHA compression (but gets complicated by inventing weird corner cases).
```

DecompressLzsshuf:

```
if uncompressed_size=0 then goto @@all_done   ;-empty (eg. for unused forks)
[dst+0000h..1FFCh]=uninitialized              ;\
[dst+1FFDh..1FFFh]=00h,00h,00h                ; prefill sliding window
dst+dst+2000h                                 ;/
@@block_lop:
InitBitstreamMsbFirst(src)
GetLzsshufTree(data_tree,100h)  ;tree for data=00h..FFh
GetLzsshufTree(len_tree,40h)    ;tree for len=00h..3Fh (0,1 usually unused)
GetLzsshufTree(disp_tree,80h)   ;tree for dispUpper7bit=00h..7Fh
block_org=src, blocksize=0      ;block origin (after above trees)
@@decompress_lop:
if src>=src_end then goto @@all_done  ;=out_end then goto @@all_done  ;=1FFF0h AND type=CompactPro then goto @@block_done
if blocksize>=0FFF0h AND type=Disc Double then goto @@block_done
if GetBits(1)=1 then
[dst]=GetHuffCode(data_tree), dst=dst+1, blocksize=blocksize+2
else
len=GetHuffCode(len_tree)+0, blocksize=blocksize+3
disp=GetHuffCode(disp_tree)*40h+GetBits(6), if disp=0000h then disp=2000h
for i=1 to len, [dst]=[dst-disp], dst=dst+1, next i
if RleOnTheFly then forward above byte(s) to RLE (which advances "out" ptr)
goto @@decompress_lop
@@block_done:
;the decoder does prefetch data in 16bit units, and it does always have
;16..31 bits prefetched, these bits are discarded at block end...
src=src+2+((src-block_org) AND 1) ;discard 16..31 bits (till 16bit-boundary)
goto @@block_lop                  ;start next block, with new trees
@@all_done:
ret
```

GetLzsshufTree(tree,max):

```
num=GetBits(8)*2, if num>max then goto error ;number of symbols (00h and up)
for i=0 to num-1, codesizes[i]=GetBits(4)    ;sizes (1..15 bits, or 0=unused)
lzh_explode_tree(tree,codesizes,num)         ;alike LHA trees
ret
```

Minor Corner cases:

```
Disp=0 acts as Disp=2000h (don't care when using ringbuf[index AND 1FFFh])
Len=0..1 could be definied in the len_tree (but are usually size=0bit=unused)
Unknown if disp_tree & len_tree can be empty (when using data_tree only)?
RLE ending with 81h,padding should only output 81h (see RLE8182 description)
```

Incomplete Trees

```
A few .cpt files (eg. ABC's-1.09.cpt.hqx\..\Colin's ABC's\Message.h) have
incomplete trees (like only one disp code, "0"=DispUpper7bit=00h, without
defining any further huffman codes like "1" or "1xxx").
This isn't much of a problem (except, one may need to remove incomplete tree
error checking in the "lzh_explode_tree" function).
```

End of Last Block

```
End of Last Block is usually determined by forwarding the LZSSHUF output
directly to the RLE8182 decompressor (which does then check if uncompressed
size is reached) (marked "RleOnTheFly" in above sample code).
Alternately, one could decompress in separate steps (LZSSHUF to tempbuf, and
then tempbuf to RLE8182), but that requires to deal with padding bits.
- padding seems to be 16..31 bits (?) alike at end of blocksize
- padding bits are (always?) zeroes, which act as flag=0=compressed
- compressed data occupies at least flg(1),len(1),disp(1),displsbs(6)=9bits
That can lead to decoding a few extra codes (with lengths up to 3Fh each),
so the tempbuf must have trailing space for writing that garbage padding.
And, those padding bits tend to translate to disp=0000h (aka disp=2000h),
which can cause reads from the whole sliding window, so tempbuf requires
2000h leading bytes to avoid page faults (not just the 3 initialized bytes).
```

See also:

https://github.com/dgilman/macutils/blob/master/macunpack/cpt.c
- source code

https://github.com/MacPaw/XADMaster/wiki/CompactProSpecs
- confused anti-specs

**Self-Extracting Archives (SEA)**

The abbreviation SEA (and extension .sea) is used for several self-extracting
MAC archives. The Resource fork contains an executable (as indicated by
Type="APPL") which contains the decompressor, and the Data fork contains the
archive.

```
MAC File Type,Creator IDs = "APPL","aust" (StuffIt).
MAC File Type,Creator IDs = "APPL","EXTR" (CompactPro).
MAC File Type,Creator IDs = "APPL","DSEA" (DiskDoubler).
```

There are some oddities for .sea files found in internet:

```
StuffIt .sea files: These are often raw StuffIt archives (apparently
somebody had removed the MacBinary header and the resource fork with
the decompressor).
CompactPro .sea files: These are often stored as MacBinary without 80h-byte
padding appended to the Data and Resource forks.
That applies to "Santa.sea" but other such files have OTHER corruptions,
which may include wrong Size and/or garbage in reserved MacBinary fields?
```

Note: Not to be confused with ARC archives from System Enhancement Associates
(SEA).

**Mac OS Data forks**

The Data fork contains the "normal data" part of the file (eg. anything like
.TXT .DOC .GIF .JPG .WAV .ZIP .LZH .SIT .PIT .CPT etc).

**Mac OS Resource forks**

The Resource fork can contain executable code resources (similar to .EXE files;
with File Type="APPL"), and various other resources (fonts, icons, text strings
for dialog boxes, etc). Those resources are stored in a filesystem-style
archive and can be accessed with IDs and/or name strings.

```
Resource fork Header:
000h 4    Offset to Resource Data section (from start of file) (100h)
004h 4    Offset to Resource Map section  (from start of file) (100h+DataSiz)
008h 4    Size of Resource Data section (can be 0=None)
00Ch 4    Size of Resource Map section
010h F0h  Unknown (can contain filename/type.. MAYBE just garbage padding?)
100h ..   Resource Data section, contains Data Record(s)
...  ..   Resource Map section
Data Record(s) in Resource Data section (usually at offset 100h and up):
000h 4    Size of Data for this record
004h ..   Data for this record
Resource Map section:
000h 4    Offset to Resource Data section (from start of file) ;\
004h 4    Offset to Resource Map section  (from start of file) ; same as in
008h 4    Size of Resource Data section                        ; header
00Ch 4    Size of Resource Map section                         ;/
010h 4    Zero (internally used by Resource Manager, nextResourceMap)
014h 2    Zero (internally used by Resource Manager, fileRef)
016h 2    Map Attributes
0-4  Zero (reserved)
5    Zero (internally used by Resource Manager, changed)
6    Zero (internally used by Resource Manager, need compression)
7    Resource map is read-only
8-15 Zero (reserved)
018h 2    Offset to Type List (from start of resource map) (usually 1Ch ?)
01Ah 2    Offset to Name List (from start of resource map)
...  ..   Type List
...  ..   Resource List (with one or more entry for each entry in Type List)
...  ..   Name List (each name consists of 8bit NameLength, plus name string)
Type List follows the header and contains an array of resource type records.
000h 2    Number of Type Records, minus one (FFFFh=None, 0000h=One, etc.)
002h N*8  Type Records
Type Record format:
000h 4    Resource Type (four-character constant)
004h 2    Number of Resource List entries, minus one (0000h=One, etc.)
006h 2    Offset to first Resource List entry (from start of Type List)
Resource List entries:
000h 2    Resource ID (C000h..FFFFh=Special/Owned)
002h 2    Offset to Resource Name (from start of Name List) (FFFFh=None)
004h 1    Attributes
0    Resource data is compressed             (0=No, 1=Compressed)
1    Zero (internally used by Resource Manager, changed)
2    Load Resource as soon as file is opened (0=No, 1=Preload)
3    Resource is read-only                   (0=No, 1=Protected)
4    Resource may not be moved in memory     (0=No, 1=Locked)
5    Resource may be paged out of memory     (0=No, 1=Purgeable)
6    Load Resource to        (0=Application heap, 1=System Heap)
7    Zero (reserved)
005h 3    Offset to Resource Data (from start of Resource Data section)
008h 4    Zero (internally used by Resource Manager, resourcePtr)
Note: Some (or all?) 16bit offsets are reportedly signed (max 32Kbyte), the
24bit offsets are reportedly unsigned (max 16Mbyte).
```

Compressed Resources (when Attributes.bit0=1)

```
Compressed resource have a standarized header, the decompression function(s)
are supposed to be stored in separate "dmcp" resource (unknown if the OS is
also providing standard decompression functions).
000h 4      ID (always A89F6572h for compressed resource)
004h 2      Always 0012h (maybe compression header size)
006h 1      Type (08h=Type8, 09h=Type9)
007h 1      Always 01h
008h 4      Uncompressed resource size
00Ch 1      For Type8: workingBufferFractionalSize               ;\
00Dh 1      For Type8: expansionBufferSize                       ; Type8
00Eh 2      For Type8: dcmpID (ID in "dmcp" decompress resource) ;
010h 2      For Type8: Zero (reserved?)                          ;/
00Ch 2      For Type9: dcmpID (ID in "dmcp" decompress resource) ;\Type9
00Eh 4      For Type9: decompressor_specific_parameters_with_io  ;/
012h ..     Compressed Resource Data
http://formats.kaitai.io/compressed_resource/
```

Owned Resources (with Resource ID=C000h..FFFFh):

```
https://github.com/kreativekorp/ksfl/wiki/Macintosh-Resource-File-Format
```

The upper 5bit (mask F800h) indicate the resource type of the owner, the middle
6bit (mask 07E0h) indicate the resource id of the owner, and the lower 5bit
(mask 001Fh) indicate the "sub-id" of the owned resource.

```
ID MSBs    Owner Type  Notes
C000h      DRVR        driver or desk accessory
C800h      WDEF        window definition: code to draw windows
D000h      MDEF        menu definition: code to draw menus
D800h      CDEF        control definition: code to draw UI widgets
E000h      PDEF        printer driver
E800h      PACK        utility code package/library used by the Mac OS
F000h      cdev        control panel; owner id is set to 1
F800h      reserved    reserved for future use
```

The Mac OS Resource Manager used this scheme to ensure that certain types of
programs, themselves stored in resources, could find the other resources they
needed even if the resources had to be renumbered to avoid conflicts. Utilities
such as Font/DA Mover that were used to install and remove these programs used
this scheme to ensure that all associated resources were installed or removed
as well, and renumber the resources if necessary to avoid conflicts.

CDROM Protection - SCEx Strings

**SCEx String**

The heart of the PSX copy-protection is the four-letter "SCEx" string, encoded
in the wobble signal of original PSX disks, which cannot be reproduced by
normal CD writers. The last letter varies depending on the region:

```
"SCEI" for Japan
"SCEA" for America (and all other NTSC countries except Japan)
"SCEE" for Europe (and all other PAL countries like Australia)
```

If the string is missing (or if it doesn't match up for the local region) then
the PSX refuses to boot. The verification is done by the Firmware inside of the
CDROM Controller (not by the PSX BIOS, so there's no way to bypass it by
patching the BIOS ROM chip).

**Wobble Groove and Absolute Time in Pregroove (ATIP) on CD-R's**

A "blank" CDR contains a pre-formatted spiral on it. The number of windings in
the spiral varies depending on the number of minutes that can be recorded on
the disk. The spiral isn't made of a straight line (------), but rather a
wobbled line (/\/\/\), which is used to adjust the rotation speed during
recording; at normal drive speed, wobble should produce a 22050Hz sine wave.

Additionally, the CDR wobble is modulated to provide ATIP information, ATIP is
used for locating and positioning during recording, and contains information
about the approximate laser power necessary for recording, the last possible
time location that lead out can start, and the disc application code.

Wobble is commonly used only on (recordable) CDRs, ie. usually NOT on
(readonly) CDROMs and Audio Disks. The copyprotected PSX CDROMs are having a
short CDR-style wobble period in the first some seconds, which seems to contain
the "SCEx" string instead of ATIP information.

**Other Protections**

Aside from the SCEx string, PSX disks are required to contain region and
licence strings (in the ISO System Area, and in the .EXE file headers), and the
"PS" logo (in the System Area, too). This data can be reproduced with normal CD
writers, although it may be illegal to distribute unlicensed disks with licence
strings.

CDROM Protection - Modchips

**Modchip Source Code**

The Old Crow mod chip source code works like so:

```
entrypoint:                   ;at power_up
gate=input/highz
data=input/highz
wait 50 ms
data=output/low
wait 850 ms
gate=output/low
wait 314 ms
loop:
wait 72 ms                  ;pause (eighteen "1=low" bits)
sendbyte("S")               ;1st letter
sendbyte("C")               ;2nd letter
sendbyte("E")               ;3rd letter
sendbyte(...)               ;4th letter (A, E, or I, depending on region)
goto loop
sendbyte(char):
sendbit(0)                  ;one start bit (0=highz)
for i=0 to 7
sendbit(char AND 1)       ;output data (LSB first)
char=char/2
next i
sendbit(1)                  ;1st stop bit (1=low)
sendbit(1)                  ;2nd stop bit (1=low)
return
sendbit(bit):
if bit=1 then data=output/low elseif bit=0 then data=input/highz
wait 4 ms           ;4ms per bit = 250 bits per second
return
```

That is, 62 bits per transfer at 250bps = circa 4 transfers per second.

**Connection for the data/gate/sync signals:**

For older PSX boards (data/gate):

```
Board        data             gate
PU-xx        unknown?         unknown?        ;older PSX boards
```

For newer PSX and PSone boards (data/sync):

```
Board        data             sync
PU-23, PM-41 CXD2938Q.Pin42   CXD2938Q.Pin5   ;newer PSX and older PSone
PM-41(2)     CXD2941R.Pin36   CXD2941R.Pin76  ;newer PSone boards
```

On the mainboard should be a big SMD capacitor (connected to the "data" pin),
and a big testpoint (connected to the "sync" pin); it's easier to connect the
signals to that locations than to the tiny CXD-chip pins.

gate and data must be tristate outputs, or open-collector outputs (or normal
high/low outputs passed through a diode).

**Note on "data" pin (all boards)**

Transfers the "SCEx" data. Note that the signal produced by the modchip is
looking entirly different than the signal produced by original disks, the real
signal would be modulated 22050Hz wobble, while the modchip is simply dragging
the signal permanently LOW throughout "1" bits, and leaves it floating for "0"
bits. Anyways the "faked" signal seems to be accurate enough to work.

**Note on "gate" pin (older PSX boards only)**

The "gate" pin needs to be LOW only for use with original licensed disks
(reportedly otherwise the SCEx string on that disks would conflict with the
SCEx string from the modchip).

At the mainboard side, the "gate" signal is an input, and "data" is an inverted
output of the gate signal (so dragging gate to low, would cause data to go
high).

**Note on "sync" pin (newer PSX and PSone boards only)**

The "sync" pin is a testpoint on the mainboard, which does (at single speed)
output a frequency of circa 44.1kHz/6 (of which some clock pulses seem to be
longer or shorter, probably to indicate adjustments to the rotation speed).

Some modchips are connected directly to "sync" (so they are apparently
synchronizing the data output with that signal; which is not implemented in the
above source code).

Anyways, other modchips are using a more simplified connection: The modchip
itself connects only to the "data" pin, and "sync" is required to be wired to
IC723.Pin17.

**Note on Multi-Region chips**

Modchips that are designed to work in different regions are sending a different
string (SCEA, SCEE, SCEI) in each loop cycle. Due to the slow 250bps transfer
rate, it may take a while until the PSX has received the correct string, so
this multi-region technique may cause a noticeable boot-delay.

**Stealth (hidden modchip)**

The Stealth connection is required for some newer games with anti-modchip
protection, ie. games that refuse to run if they detect a modchip. The
detection relies on the fact that the SCEx signal is normally received only
when booting the disk, whilst older modchips were sending that signal
permanently. Stealth modchips are sending the signal only on power-up (and when
inserting a new disk, which can be sensed via SHELL_OPEN signal).

Modchip detection reportedly works like so (not too sure if all commands are
required, some seem to be rather offtopic):

```
1.  Com 19h,20h   ;Retrieve CDROM Controller timestamp
2.  Com 01h       ;CdlNop: Get CD status
3.  Com 07h       ;CdlMotorOn: Make CD-ROM drive ready (blah?)
4.  Com 02h,1,1,1 ;CdlSetloc(01:01:01) (sector that does NOT have SCEx data)
5.  Com 0Eh,1     ;CdlSetmode: Turn on CD-DA read mode
6.  Short Delay
7.  Com 16h       ;CdlSeekP: Seek to Setloc's parameters (4426)
8.  Com 0Bh       ;CdlMute: Turn off sound so CdlPlay is inaudible
9.  Com 03h       ;CdlPlay: Start playing CD-DA.
10. Com 19h,04h   ;ResetSCExInfo (reset GetSCExInfo response to 0,0)
11. Long Delay    ;wait until the modchip (if any) has output SCEx data
12. Com 19h,05h   ;GetSCExInfo (returns total,success counters)
13. Com 09h       ;CdlPause: Stop command 19h.
```

If GetSCExInfo returns nonzero values, then the console is equipped with a
modchip, and if so, anti-modchip games would refuse to work (no matter if the
disk is an illegal copy, or not).

**NTSC-Boot BIOS Patch**

Typically connects to two or three BIOS address/data lines, apparently watching
that signals, and dragging a data line LOW at certain time, to skip software
based region checks (eg. allowing to play NTSC games on PAL consoles).

Aside from the modchip connection, that additionally requires to adjust the
video signal (in 60Hz NTSC mode, the PSX defaults to generate a NTSC video
signal) (whilst most PAL screens can handle 60Hz refresh, they can't handle
NTSC colors) (on PSone boards, this can be fixed simply by grounding the /PAL
pin; IC502.Pin13) (on older PSX boards it seems to be required to install an
external color clock generator).

**MODCHIP Connection Example**

Connection for 8pin "12C508" mod chip from fatcat.co.nz for a PAL PSone with
PM-41 board (ie. with 208pin SPU CXD2938Q, and 52pin IC304 "C 3060,
SC430943PB"):

```
1 3.5V        (supply)
2 IC304.Pin44 (unknown?) (XLAT)
3 BIOS.Pin15  (D2)
4 BIOS.Pin31  (A18)
5 SPU.Pin5    ("sync")
6 SPU.Pin42   ("data")
7 IC304.Pin19 (SHELL_OPEN)
8 GND         (supply)
```

The chip can be used in a Basic connection (with only pin1,5,6,8 connected), or
Stealth and NTSC-Boot connection (additionally pin2,3,4,7 connected). Some
other modchips (such without internal oscillator) are additionally connected to
a 4MHz or 4.3MHz signal on the mainboard. Some early modchips also connected to
a bunch of additional pins that were reportedly for power-on timings (whilst
newer chips use hardcoded power-on delays).

**Nocash BIOS "Modchip" Feature**

The nocash PSX bios outputs the "data" signal on the A20 address line, so
(aside from the BIOS chip) one only needs to install a 1N4148 diode and two
wires to unlock the CDROM:

```
SPU.Pin42 "data" -------|>|------ CPU.Pin149 (A20)
SPU.Pin5  "sync" ---------------- IC723.Pin17
```

With the "sync" connection, the SCEx signal from the disk is disabled (ie. even
original licensed disks are no longer recognized, unless SCEx is output via A20
by software). For more variants, see:

CDROM Protection - Chipless Modchips

CDROM Protection - LibCrypt

LibCrypt is an additional copy-protection, used by about 100 PSX games. The
protection uses a 16bit decryption key, which is stored as bad position data in
Subchannel Q. The 16bit key is then used for a simple XOR-decryption on certain
800h-byte sectors.

**Protected sectors generation schemas**

There are some variants on how the Subchannel Q data is modified:

```
1. 2 bits from both MSFs are modified,
CRC-16 is recalculated and XORed with 0x0080.
Games: MediEvil (E).
2. 2 bits from both MSFs are modified,
original CRC-16 is XORed with 0x8001.
Games: CTR: Crash Team Racing (E) (No EDC), CTR: Crash Team Racing (E)
(EDC), Dino Crisis (E), Eagle One: Harrier Attack (E) et al.
3. Either 2 bits or none from both MSFs are modified,
CRC-16 is recalculated and XORed with 0x0080.
Games: Ape Escape (S) et al.
```

Anyways, the relevant part is that the modified sectors have wrong CRCs (which
means that the PSX cdrom controller will ignore them, and the GetlocP command
will keep returning position data from the previous sector).

**LibCrypt sectors**

The modified sectors could be theoretically located anywhere on the disc,
however, all known protected games are having them located on the same sectors:

```
No.
Bit15  14105 (03:08:05)  14110 (03:08:10)  42045 (09:20:45)  42050 (09:20:50)
Bit14  14231 (03:09:56)  14236 (03:09:61)  42166 (09:22:16)  42171 (09:22:21)
Bit13  14485 (03:13:10)  14490 (03:13:15)  42432 (09:25:57)  42437 (09:25:62)
Bit12  14579 (03:14:29)  14584 (03:14:34)  42580 (09:27:55)  42585 (09:27:60)
Bit11  14649 (03:15:24)  14654 (03:15:29)  42671 (09:28:71)  42676 (09:29:01)
Bit10  14899 (03:18:49)  14904 (03:18:54)  42813 (09:30:63)  42818 (09:30:68)
Bit9   15056 (03:20:56)  15061 (03:20:61)  43012 (09:33:37)  43017 (09:33:42)
Bit8   15130 (03:21:55)  15135 (03:21:60)  43177 (09:35:52)  43182 (09:35:57)
Bit7   15242 (03:23:17)  15247 (03:23:22)  43289 (09:37:14)  43294 (09:37:19)
Bit6   15312 (03:24:12)  15317 (03:24:17)  43354 (09:38:04)  43359 (09:38:09)
Bit5   15378 (03:25:03)  15383 (03:25:08)  43408 (09:38:58)  43413 (09:38:63)
Bit4   15628 (03:28:28)  15633 (03:28:33)  43634 (09:41:59)  43639 (09:41:64)
Bit3   15919 (03:32:19)  15924 (03:32:24)  43963 (09:46:13)  43968 (09:46:18)
Bit2   16031 (03:33:56)  16036 (03:33:61)  44054 (09:47:29)  44059 (09:47:34)
Bit1   16101 (03:34:51)  16106 (03:34:56)  44159 (09:48:59)  44164 (09:48:64)
Bit0   16167 (03:35:42)  16172 (03:35:47)  44312 (09:50:62)  44317 (09:50:67)
```

Each bit is stored twice on Minute=03 (five sectors apart). For some reason,
there is also a "backup copy" on Minute=09 (however, the libcrypt software
doesn't actually support using that backup stuff, and, some discs don't have
the backup at all (namely, discs with less than 10 minutes on track 1?)).

A modified sector means a "1" bit, an unmodified means a "0" bit. The 16bit
keys of the existing games are always having eight "0" bits, and eight "1" bits
(meaning that there are 16 modified sectors on Minute=03, and, if present,
another 16 ones one Minute=09).

**Example (Legacy of Kain)**

Legacy of Kain (PAL) is reading the LibCrypt data during the title screen, and
does then display GOT KEY!!! on TTY terminal (this, no matter if the correct
16bit key was received).

The actual protection jumps in a bit later (shortly after learning to glide,
the game will hang when the first enemies appear if the key isn't okay).
Thereafter, the 16bit key is kept used once and when to decrypt 800h-byte
sector data via simple XORing.

The 16bit key (and some other related counters/variables) aren't stored in RAM,
but rather in COP0 debug registers (which are mis-used as general-purpose
storage in this case), for example, the 16bit key is stored in LSBs of the
"cop0r3" register.

In particuar, the encryption is used for some of the BIGFILE.DAT folder
headers:

CDROM File Archive BIGFILE.DAT (Soul Reaver)

CDROM Disk Images CDI (DiscJuggler)

**Overall Format**

```
Sector Data (sector 00:00:00 and up)          ;-body
Number of Sessions (1 byte)
CDROM Disk Images MDS/MDF (Alcohol 120%)

**File.MDF - Contains sector data (optionally with sub-channel data)**

Contains the sector data, recorded at 800h..930h bytes per sector, optionally
followed by 60h bytes subchannel data (appended at the end of each sector). The
stuff seems to be start on 00:02:00 (ie. the first 150 sectors are missing; at
least it is like so when "Session Start Sector" is -150).

The subchannel data (if present) consists of 8 subchannels, stored in 96 bytes
(each byte containing one bit per subchannel).

```
Bit7..0 = Subchannel P..W (in that order, eg. Bit6=Subchannel Q)
```

The 96 bits (per subchannel) can be translated to bytes, as so:

```
1st..8th bit  = Bit7..Bit0 of 1st byte (in that order, ie. MSB/Bit7 first)
9st..16th bit = Bit7..Bit0 of 2nd byte ("")
17th..        = etc.
```

**File.MDS - Contains disc/lead-in info (in binary format)**

An MDS file's structure consists of the following stuff ...

```
Header              (58h bytes)
Session block(s)    (usually one 18h byte entry)
Data blocks         (N*50h bytes)
Index blocks        (usually N*8 bytes)
Filename blocks(s)  (usually one 10h byte entry)
Filename string(s)  (usually one 6 byte string)
Read error(s)       (usually none such)
```

**Header (58h bytes)**

```
00h 16  File ID ("MEDIA DESCRIPTOR")
10h 2   Unknown (01h,03h or 01h,04h or 01h,05h) (Fileformat version?)
12h 2   Media Type (0=CD-ROM, 1=CD-R, 2=CD-RW, 10h=DVD-ROM, 12h=DCD-R)
14h 2   Number of sessions (usually 1)
16h 4   Unknown (02h,00h,00h,00h)
1Ah 2   Zero (for DVD: Length of BCA data)
1Ch 8   Zero
24h 4   Zero (for DVD: Offset to BCA data)
28h 18h Zero
40h 4   Zero (for DVD: Offset to Disc Structures)   (from begin of .MDS file)
44h 0Ch Zero
50h 4   Offset to First Session-Block (usually 58h) (from begin of .MDS file)
54h 4   Offset to Read errors (usually 0=None)      (from begin of .MDS file)
```

**Session-Blocks (18h bytes)**

```
00h 4   Session Start Sector (starting at FFFFFF6Ah=-150 in first session)
04h 4   Session End Sector     (XXX plus 150 ?)
08h 2   Session number (starting at 1) (non-BCD)
0Ah 1   Number of Data Blocks with any Point value (Total Data Blocks)
0Bh 1   Number of Data Blocks with Point>=A0h      (Special Lead-In info)
0Ch 2   First Track Number in Session (01h..63h, non-BCD!)
0Eh 2   Last Track Number in Session  (01h..63h, non-BCD!)
10h 4   Zero
14h 4   Offset to First Data-Block (usually 70h) (from begin of .MDS file)
```

**Data-Blocks (50h bytes)**

Block 0..2 are usually containing Point A0h..A2h info. Block 3..N are usually
TOC info for Track 1 and up.

```
00h 1   Track mode (see below for details)
01h 1   Number of subchannels in .MDF file (0=None, 8=Sector has +60h bytes)
02h 1   ADR/Control (but with upper/lower 4bit swapped, ie. MSBs=ADR!)    Q0
03h 1   TrackNo (usually/always 00h; as this info is in Lead-in area)     Q1
04h 1   Point  (Non-BCD!) (Track 01h..63h) (or A0h and up=Lead-in info)   Q2
05h 4   Zero (probably dummy MSF and reserved byte from Q channel)   Q3..Q6?
09h 1   Minute (Non-BCD!)  ;\MM:SS:FF of Point'ed track                   Q7
0Ah 1   Second (Non-BCD!)  ; (or disc/lead-out info when Point>=A0h)      Q8
0Bh 1   Frame  (Non-BCD!)  ;/                                             Q9
```

For Point>=A0h, below 44h bytes at [0Ch..4Fh] are zero-filled

```
0Ch 4   Offset to Index-block for this track    (from begin of .MDS file)
10h 2   Sector size (800h..930h) (or 860h..990h if with subchannels)
12h 1   Unknown (02h) (maybe number of indices?)
13h 11h Zero
24h 4   Track start sector, PLBA (00000000h=00:02:00)(or 00000096h=00:02:00?)
28h 8   Track start offset                      (from begin of .MDF file)
30h 4   Number of Filenames for this track (usually 1)
34h 4   Offset to Filename Block for this track (from begin of .MDS file)
38h 18h Zero
```

Trackmode:

```
(upper 4bit seem to be meaningless?)
00h=None (used for entries with Point=A0h..FF)
A9h=AUDIO       ;sector size = 2352    930h  ;bytes 000h..92Fh
AAh=MODE1       ;sector size = 2048    800h  ;bytes 010h..80Fh
ABh=MODE2       ;sector size = 2336    920h  ;bytes 010h..92Fh
ACh=MODE2_FORM1 ;sector size = 2048    800h  ;bytes 018h..817h (incomplete!)
ADh=MODE2_FORM2 ;sector size = 2324+0? 914h  ;bytes 018h..91Bh (incomplete!)
ADh=MODE2_FORM2 ;sector size = 2324+4? 918h  ;bytes ??..?? (contains what?)
ECh=MODE2       ;sector size = 2448    990h  ;(930h+60h) (with subchannels)
```

**Index Blocks (usually 8 bytes per track)**

```
00h 4  Number of sectors with Index 0 (usually 96h or zero)
04h 4  Number of sectors with Index 1 (usually size of main-track area)
```

Index blocks are usually/always 8 bytes in size (two indices per track, even
when recording a CD with more than 2 indices per track).

The MDS file does usually contain Index blocks for <all> Data Blocks (ie.
including unused dummy Index Blocks for Data Blocks with Point>=A0h).

**Filename Blocks (10h bytes)**

```
00h 4  Offset to Filename (from begin of .MDS file)
04h 1  Filename format (0=8bit, 1=16bit characters)
05h 11 Zero
```

Normally all tracks are sharing the same filename block (although theoretically
the tracks could use separate filename blocks; with different filenames).

**Filename Strings (usually 6 bytes)**

```
00h 6  Filename, terminated by zero (usually "*.mdf",00h)
```

Contains the filename of the of the sector data (usually "*.mdf", indicating to
use the same name as for the .mds file, but with .mdf extension).

**Read errors aka DPM data blocks (present if errors occured during recording)**

```
00h 4   Unknown (1)
04h 4   Offset to following stuff
08h 4   Unknown (2)
0Ch 4   Unknown (7)
10h 4   Unknown (1)
14h 4   Number of read errors (E)
18h E*4 LBA's for sectors with read errors (0 and up)
```

Instead of (or additionally to) read errors, there may be also hundreds of
Kbytes of unknown stuff appended (text strings in 8bit or 16bit format, binary
numbers, and huge zerofilled blocks).

**Missing**

Unknown if/how this format supports EAN-13, ISRC, CD-TEXT.

CDROM Disk Image/Containers CDZ

.CDZ is a compressed disk image container format (developed by pSX Author, and
used only by the pSX emulator). The disk is split into 64kbyte blocks, which
allows fast random access (without needing to decompress all preceeding
sectors).

However, the compression ratio is surprisingly bad (despite of being
specifically designed for cdrom compression, the format doesn't remove
redundant sector headers, error correction information, and EDC checksums).

**.CDZ File Structure**

```
FileID ("CDZ",00h for cdztool v0/v1, or "CDZ",01h for cdztool v2 and up)
One or two Chunk(s)
```

**.CDZ Chunk Format**

Chunk Header in v0 (unreleased prototype):

```
4    32bit Decompressed Size (of all blocks) (must be other than "ZLIB")
```

Chunk Header in v1 (first released version):

```
4    ZLIB ID ("ZLIB")
8    64bit Decompressed Size (of all blocks)
```

Chunk Header in v2 and up (later versions):

```
4    Chunk ID (eg. "CUE",00h)
8    Chunk Size in bytes (starting at "ZLIB" up to including Footer, if any)
4    ZLIB ID ("ZLIB")
8    64bit Decompressed Size (of all blocks)
```

Chunk Body (same in all versions):

```
4    Number of Blocks (N)
4    Block 1 Compressed Size (CS.1)
4    Block 1 Decompressed Size (always 00010000h, except last block)
CS.1 Block 1 Compressed ZLIB Data (starting with 78h,9Ch)
...  ...                                     ;\
4    Block N Compressed Size (CS.N)          ; further block(s)
4    Block N Decompressed Size               ; (if any)
CS.N Block N Compressed ZLIB Data            ;/
```

Chunk Footer in v0 (when above header didn't have the "ZLIB" ID):

```
4*N       Directory Entries for N blocks     ;-this ONLY for BIN chunk
```

Chunk Footer in v1 and up:

```
BPD*(N-1) Directory Entries for N-1 blocks   ;\this ONLY for BIN chunk
1         Bytes per Directory Entry (BPD)    ;/(not for CUE/CCD/MDS)
```

The "Compressed ZLIB Data" parts contain Deflate'd data (starting with 2-byte
ZLIB header, and ending with 4-byte ZLIB/ADLER checksum), for details see:

CDROM File Compression ZIP/GZIP/ZLIB (Inflate/Deflate)

**.CDZ Chunks / Content**

The chunk(s) have following content:

```
noname+noname       --> .CUE+.BIN (cdztool v1 and below)
"BIN",0             --> .ISO      (cdztool v2? and up)
"CUE",0+"BIN",0     --> .CUE+.BIN (cdztool v2 and up)
"CCD",0+"BIN",0     --> .CCD+.IMG (cdztool v2 and up)
"CCD",0+"BIN",01h   --> .CCD+.IMG+.SUB (930h sectors, plus 60h subchannels)
"MDS",0+"BIN",0     --> .MDS+.MDF (cdztool v5 only)
```

Note: cdztool doesn't actually recognize files with .ISO extension (however,
one can rename them to .BIN, and then compress them as CUE-less .BIN file).

**Cdztool.exe Versions**

```
cdztool.exe v0, unrelased prototype
cdztool.exe v1, 22 May 2005, CRC32=620dbb08, 102400 bytes, pSX v1.0-5
cdztool.exe v2, 02 Jul 2006, CRC32=bcb29c1e, 110592 bytes, pSX v1.6
cdztool.exe v3, 22 Jul 2006, CRC32=4062ba82, 110592 bytes, pSX v1.7
cdztool.exe v4, 13 Aug 2006, CRC32=7388dd3d, 118784 bytes, pSX v1.8-11
cdztool.exe v5, 22 Jul 2007, CRC32=f25c1659, 155648 bytes, pSX v1.12-13
```

Note: v0 wasn't ever released (it's only noteworthy because later versions do
have backwards compatibility for decompressing old v0 files). v1 didn't work
with all operating systems (on Win98 it just says "Error: Couldn't create
<output>" no matter what one is doing, however, v1 does work on later
windows versions like WinXP or so?).

CDROM Subchannel Images

**SBI (redump.org)**

SBI Files start with a 4-byte FileID:

```
4 bytes FileID ("SBI",00h)
```

Then followed by entries as so:

```
3 bytes real absolute MM:SS:FF address where the sub q data was bad
1 byte Format: the format can be 1, 2 or 3:
Format 1: complete 10 bytes sub q data            (Q0..Q9)
Format 2: 3 bytes wrong relative MM:SS:FF address (Q3..Q5)
Format 3: 3 bytes wrong absolute MM:SS:FF address (Q7..Q9)
```

Note: The PSX libcrypt protection relies on bad checksums (Q10..Q11), which
will cause the PSX cdrom controller to ignore Q0..Q9 (and to keep returning
position data from most recent sector with intact checksum).

Ironically, the SBI format cannot store the required Q10..Q11 checksum. The
trick for using SBI files with libcrypted PSX discs is to ignore the useless
Q0..Q9 data, and to assume that all sectors in the SBI file have wrong Q10..Q11
checksums.

**M3S (Subchannel Q Data for Minute 3) (ePSXe)**

M3S files are containing Subchannel Q data for all sectors on Minute=03 (the
region where PSX libcrypt data is located) (there is no support for storing the
(unused) libcrypt backup copy on Minute=09). The .M3S filesize is 72000 bytes
(60 seconds * 75 sectors * 16 bytes). The 16 bytes per sector are:

```
Q0..Q9   Subchannel Q data (normally position data)
Q10..Q11 Subchannel Q checksum
Q12..Q15 Dummy/garbage/padding (usually 00000000h or FFFFFFFFh)
```

Unfortunately, there are at least 3 variants of the format:

```
1. With CRC (Q0..Q11 intact) (and Q12..Q15 randomly 00000000h or FFFFFFFFh)
2. Without CRC (only Q0..Q9 intact, but Q10..Q15 zerofilled)
3. Without anything (only Q0 intact, but Q1..Q15 zerofilled)
```

The third variant is definetly corrupt (and one should ignore such zerofilled
entries). The second variant is corrupt, too (but one might attempt to repair
them by guessing the missing checksum: if it contains normal position values
assume correct crc, if it contains uncommon values assume a libcrypted sector
with bad crc).

The M3S format is intended for libcrypted PSX games, but, people seem to have
also recorded (corrupted) M3S files for unprotected PSX games (in so far, more
than often, the M3S files might cause problems, instead of solving them).

Note: The odd 16-byte format with 4-byte padding does somehow resemble the "P
and Q Sub-Channel" format 'defined' in MMC-drafts; if the .M3S format was based
on the MMC stuff: then the 16th byte might contain a Subchannel P "pause" flag
in bit7.

**CDROM Images with Subchannel Data**

Most CDROM-Image formats can (optionally) contain subchannel recordings. The
downsides are: Storing all 8 subchannels for a full CDROM takes up about
20MBytes. And, some entries may contain 'wrong' data (read errors caused by
scratches cannot be automatically repaired since subchannels do not contain
error correction info).

If present, the subchannel data is usually appended at the end of each sector
in the main binary file (one exception is CloneCD, which stores it in a
separate .SUB file instead of in the .IMG file).

```
CCD/IMG/SUB (CloneCD)  P-W  60h-bytes Non-interleaved (in separate .SUB file)
CDI (DiscJuggler)      P-Q  10h-bytes Non-interleaved (in .CDI file)
""                     P-W  60h-bytes Interleaved (in .CDI file)
CUE/BIN/CDT (Cdrwin)        N/A
ISO (single-track)          N/A
MDS/MDF (Alcohol 120%) P-W  60h-bytes Interleaved (in .MDF file)
NRG (Nero)             P-W  60h-bytes Interleaved (in .NRG file)
```

Interleaved Subchannel format (eg. Alcohol .MDF files):

```
00h-07h   80 C0 80 80 80 80 80 C0   ;P=FFh, Q=41h=ADR/Control, R..W=00h
08h-0Fh   80 80 80 80 80 80 80 C0   ;P=FFh, Q=01h=Track,       R..W=00h
10h-17h   80 80 80 80 80 80 80 C0   ;P=FFh, Q=01h=Index,       R..W=00h
18h-1Fh   80 80 80 80 80 80 80 80   ;P=FFh, Q=00h=RelMinute,   R..W=00h
20h-27h   80 80 80 80 80 80 80 80   ;P=FFh, Q=00h=RelSecond,   R..W=00h
28h-2Fh   80 80 80 80 80 80 80 80   ;P=FFh, Q=00h=RelSector,   R..W=00h
30h-37h   80 80 80 80 80 80 80 80   ;P=FFh, Q=00h=Reserved,    R..W=00h
38h-3Fh   80 80 80 80 80 80 80 80   ;P=FFh, Q=00h=AbsMinute,   R..W=00h
40h-47h   80 80 80 80 80 80 C0 80   ;P=FFh, Q=02h=AbsSecond,   R..W=00h
48h-4Fh   80 80 80 80 80 80 80 80   ;P=FFh, Q=00h=AbsSector,   R..W=00h
50h-57h   80 80 C0 80 C0 80 80 80   ;P=FFh, Q=28h=ChecksumMsb, R..W=00h
58h-5Fh   80 80 C0 C0 80 80 C0 80   ;P=FFh, Q=32h=ChecksumLsb, R..W=00h
```

Non-Interleaved Subchannel format (eg. CloneCD .SUB files):

```
00h-0Bh   FF FF FF FF FF FF FF FF FF FF FF FF  ;Subchannel P (Pause)
0Ch-17h   41 01 01 00 00 00 00 00 02 00 28 32  ;Subchannel Q (Position)
18h-23h   00 00 00 00 00 00 00 00 00 00 00 00  ;Subchannel R
24h-2Fh   00 00 00 00 00 00 00 00 00 00 00 00  ;Subchannel S
30h-3Bh   00 00 00 00 00 00 00 00 00 00 00 00  ;Subchannel T
3Ch-47h   00 00 00 00 00 00 00 00 00 00 00 00  ;Subchannel U
48h-53h   00 00 00 00 00 00 00 00 00 00 00 00  ;Subchannel V
54h-5Fh   00 00 00 00 00 00 00 00 00 00 00 00  ;Subchannel W
```

Non-Interleaved P-Q 10h-byte Subchannel format:

```
This is probably based on MMC protocol, which would be as crude as this:
The 96 pause bits are summarized in 1 bit. Pause/Checksum are optional.
00h-09h   41 01 01 00 00 00 00 00 02 00        ;Subchannel Q (Position)
0Ah-0Bh   28 32    ;
CDROM Disk Images CHD (MAME)

All numbers are stored in Motorola (big-endian) byte ordering.

**V1/V2 header (hdcomp):**

V1/V2 contains harddisk related header entries (and apparently does't support
cdroms).

```
000h 08h  ID "MComprHD" (MAME Compressed Hunks of Data)
008h 4    Header size    (4Ch=V1, 50h=V2)
00Ch 4    Header version (probably 01h=V1, 02h=V2)
010h 4    Flags (bit0=DriveHasParent, bit1=AllowWrites)
014h 4    Compression type (0=None, 1=ZLIB)
018h 4    Number of sectors per hunk
01Ch 4    Total number of hunks represented
020h 4    Number of cylinders on hard disk
024h 4    Number of heads on hard disk
028h 4    Number of sectors on hard disk
02Ch 10h  MD5 checksum on raw data
03Ch 10h  MD5 checksum on parent file
N/A  -    V1: Uses fixed 200h-byte Sector size
04Ch (4)  V2: Number of bytes per sector
...  ?    Supposedly followed by map and/or data at whatever locations
```

**V3/V4 header (chdman):**

V3/V4 are inventing new "metadata" for info about harddisks or cdroms.

```
000h 08h  ID "MComprHD" (MAME Compressed Hunks of Data)
008h 4    Header size    (78h=V3, 6Ch=V4)
00Ch 4    Header version (03h=V3, 04h=V4)
010h 4    Flags (bit0=DriveHasParent, bit1=AllowWrites)
014h 4    Compression type (0=None, 1=ZLIB, 2=ZLIB_PLUS) (V4: 3=AV)
018h 4    Total number of hunks represented    (N)       (92h)
01Ch 08h  Total size of all uncompressed hunks (N*2640h) (15D080h)
024h 08h  Offset to the first blob of metadata
02Ch 10h  V3: MD5 checksum on raw data                ;\
03Ch 10h  V3: MD5 checksum on parent file             ;
04Ch 4    V3: Number of bytes per hunk (2640h=990h*4) ; V3
050h 14h  V3: SHA1 checksum on raw data               ;
064h 14h  V3: SHA1 checksum on parent file            ;/
02Ch 4    V4: Number of bytes per hunk (2640h=990h*4) ;\
030h 14h  V4: SHA1 checksum on raw+meta               ; V4
044h 14h  V4: SHA1 checksum on raw+meta of parent     ;
058h 14h  V4: SHA1 checksum on raw data               ;/
...  N*10h Map entries (for each hunk)
...  10h   Map end marker ("EndOfListCookie",00h)
...  ..    Metadata Chunk(s)
...  ..    Compressed Sectors (aka hunks)
```

**V5 header (chdman):**

```
000h 8    ID "MComprHD" (MAME Compressed Hunks of Data)
008h 4    Header size    (7Ch=V5)
00Ch 4    Header version (05h=V5)
010h 4    Compressor 0 (usually "cdlz"=cdrom/lzma)
014h 4    Compressor 1 (usually "cdzl"=cdrom/zlib)
018h 4    Compressor 2 (usually "cdfl"=cdrom/flac)
01Ch 4    Compressor 3 (usually 0=none)
020h 8    Total size of all uncompressed hunks    (N*4C80h-HunkPadding)
028h 8    Offset to Map                           (3D797h)
030h 8    Offset to first Metadata chunk          (7Ch)
038h 4    Number of bytes per hunk (512k maximum) (990h*8) (4C80h)
03Ch 4    Number of bytes per sector              (990h)   (30h+60h)
040h 14h  SHA1 on raw data
054h 14h  SHA1 on raw+meta
068h 14h  SHA1 on raw+meta of parent (0=No parent)
...  ..   Metadata Chunk(s)
...  ..   Padding to BytesPerHunk-boundary    ;\when uncompressed
...  ..   Uncompressed Sectors (aka hunks)    ;/
...  ..   Compressed Sectors (aka hunks)      ;-when compressed
...  ..   Map
________________________________ CHD Metadata ________________________________
```

**V3/V4/V5 Metadata**

Overall Metadata chunk format:

```
000h 4   Chunk ID (aka Blob Tag) (eg. "CHT2" for each CDROM track)
004h 1   Flags (00h=V3, 01h=V4/V5)  ;maybe some kind of flag/type/version?
005h 3   Chunk Data Size (24bit)
008h 8   Offset to next Chunk (or 0=Last chunk)
010h ..  Chunk Data (eg. "TRACK:1 TYPE:MODE2_RAW ... POSTGAP:0",00h for CHT2)
```

There can be one or more chunks (eg. CHT2 chunk(s), one for each CDROM track).

```
Summary of Chunk IDs and corresponding Data entries:
ID_______Data_______________________________________________________
"GDDD"   "CYLS,HEADS,SECS,BPS"         ;-hard disk standard info     ;\
"IDNT"   ?                             ;-hard disk identify info     ; HDD
"KEY "   ?                             ;-hard disk key info          ;/
"CIS "   ?                             ;-pcmcia CIS info             ;-PCMCIA
"CHCD"   94Ch-byte binary (4+99*24 bytes)                            ;\
"CHTR"   "TRACK TYPE SUBTYPE FRAMES"                                 ; CD-ROM
"CHT2"   "TRACK TYPE SUBTYPE FRAMES PREGAP PGTYPE PGSUB POSTGAP"     ;/
"CHGT"   ?                                                           ;\Sega
"CHGD"   "TRACK TYPE SUBTYPE FRAMES PAD PREGAP PGTYPE PGSUB POSTGAP" ;/GD-ROM
"AVAV"   "FPS WIDTH HEIGHT INTERLACED CHANNELS SAMPLERATE"           ;\AV
"AVLD"   ?   (A/V Laserdisc frame)                                   ;/
```

**V3/V4/V5 Metadata in ASCII format**

The ASCII items are separated by spaces as shown above (or commas for GDDD).

The last item in each chunk is terminated by 00h (at least so for CHTR/CHT2).

Most items are followed by a colon and decimal string (eg. TRACK:1), except,
TYPE,PGTYPE,SUBTYPE,PGSUB are followed by text strings (eg. TYPE:MODE2_RAW).

```
CYLS:#          Hard disc number of cylinders
HEADS:#         Hard disc number of heads
SECS:#          Hard disc number of sectors
BPS:#           Hard disc bytes per sector
TRACK:#         CDROM current track number (1..99)
TYPE:string     CDROM sector type/size
SUBTYPE:string  CDROM subchannel info (usually "NONE")
FRAMES:#        CDROM number of sectors per track (with/without pregap?)
PAD:#           Sega GDROM only: whatever pad value?
PREGAP:#        CDROM ... maybe number of pregap sectors? (can be HUGE !!??)
PGTYPE:string   CDROM ... whatever type?                  (usually "MODE1"??)
PGSUB:string    CDROM ... whatever subchannel             (usually "RW"??)
POSTGAP:#       CDROM ... maybe number of pstgap sectors? (usually 0)
FPS:#.######    AV Video(?)-frames per second? with 6-digit fraction? (.avi?)
WIDTH:#         AV Width      (maybe in pixels?)
HEIGHT:#        AV Height     (maybe in pixels?) (with/without interlace?)
INTERLACED:#    AV Interlace  (maybe a flag that might be maybe 0 or 1?)
CHANNELS:#      AV Channels   (maybe audio mono/stereo or so?)
SAMPLERATE:#    AV Samplerate (maybe audio samplerate, maybe in Hertz?)
For SUBTYPE and PGSUB:
"RW"      60h-byte interleaved   ;normal "cooked" 96 bytes per sector
"RW_RAW"  60h-byte uninterleaved ;raw uninterleaved 96 bytes per sector
"NONE"    0-byte                 ;no subcode data stored (default)
(unknown how RAW and RW_RAW differ, one format does probably store 8 bits
for 8 subchannels per byte... but unknown which format is doing so?)
For TYPE and PGTYPE (and CHCD numeric type 0..7):
"MODE1/2048" or "MODE1"                   CHCD=0  800h-byte ;\Data Mode1
"MODE1/2352" or "MODE1_RAW"               CHCD=1  930h-byte ;/
"MODE2/2336" or "MODE2"          ;\dupe?  CHCD=2  920h-byte ;\
"MODE2/2336" or "MODE2_FORM_MIX" ;/       CHCD=5  920h-byte ;
"MODE2/2048" or "MODE2_FORM1"             CHCD=3  800h-byte ; Data Mode2
"MODE2/2324" or "MODE2_FORM2"             CHCD=4  914h-byte ;
"MODE2/2352" or "MODE2_RAW" or "CDI/2352" CHCD=6  930h-byte ;/
"AUDIO" (stored as big-endian samples!!!) CHCD=7  930h-byte ;-Audio CD-DA
```

Caution:

AUDIO sectors are conventionally stored as 16bit little-endian samples, but CHD
is storing them in big-endian (unlike formats like CUE/BIN).

Caution:

Older CHDMAN versions (eg. v0.146) did use nonsense "PGTYPE:MODE1" for all
tracks (including audio tracks), later versions (eg. v0.246) did fix that
issue; those newer files include a "V" prefix to indicate that the entry
contains "valid" info (eg. "PGTYPE:VAUDIO") (except, Track 1 keeps using
"PGTYPE:MODE1" without "V" and it's "MODE1" even on MODE2 discs).

**CHCD Metadata (94Ch bytes, plus 10h-byte metadata header)**

```
000h 4     Number of tracks (N) (1..99)
004h N*18h Track entries
...  ..    Zeropadding to 94Ch-byte size (when less than 99 tracks)
Track entries:
000h 4     Track Type       (0..7, CHCD=# in above table) (eg. 6=MODE2_RAW)
004h 4     Subchannel Type  (0=RW, 1=RW_RAW, 2=None)
008h 4     Sector Size      (800h, 914h, 920h or 930h)
00Ch 4     Subchannel Size  (0 or 60h)
010h 4     Number of Frames (aka number of sectors)
014h 4     Padding Frames   (0..3) (to make Total Frames a multiple of 4)
```

```
__________________________________ CHD Maps __________________________________
```

The Maps contain info (offset, size, compression method, etc.) for the separate
compression blocks.

**V1/V2 map format (64bit entries with 44bit+20bit):**

```
44bit     Offset to compressed data
20bit     Size of compressed data (or uncompressed data when size=hunksize)
```

Unknown if offset is in upper or lower 44bit.

**V3/V4 map entries (per hunk):**

```
000h 8    Offset to compressed data  (64bit big-endian)
008h 4    CRC32 on uncompressed data (32bit big-endian)
00Ch 3    Size of compressed data    (24bit mixed-endian: Mid, Low, High)
00Fh 1    Flags, indicating compression info (=whut? maybe below V34 stuff?)
```

V34_MAP_ENTRY_FLAG_TYPE_MASK = 0x0f;     // what type of hunk

V34_MAP_ENTRY_FLAG_NO_CRC    = 0x10;     // no CRC is present (which CRC?)

V3-V4 entry types

```
V34_MAP_ENTRY_TYPE_INVALID        = 0  invalid type
V34_MAP_ENTRY_TYPE_COMPRESSED     = 1  standard compression
V34_MAP_ENTRY_TYPE_UNCOMPRESSED   = 2  uncompressed data
V34_MAP_ENTRY_TYPE_MINI           = 3  mini: use offset as raw data
V34_MAP_ENTRY_TYPE_SELF_HUNK      = 4  same as another hunk in this file
V34_MAP_ENTRY_TYPE_PARENT_HUNK    = 5  same as a hunk in the parent file
V34_MAP_ENTRY_TYPE_2ND_COMPRESSED = 6  compressed with secondary algorithm
```

Note: Secondary algorithm is NEVER used (it seems to have been intended for
FLAC CDDA, but that was apparently never actually implemented in V3/V4).

Blurp: Secondary algorithm is "usually FLAC CDDA" (unknown where that is
defined, and if one could also select other algorithms) ("usually FLAC" might
mean "always FLAC" for cdroms, and "not used" elsewhere).

**V5 Map Formats**

```
V5 uncompressed map format (when [filehdr+10h]=00000000h):
000h N*4  Hunk List (32bit offsets: Offset/BytesPerHunk) (usually 1,2,3..)
V5 compressed map format (when [filehdr+10h]<>00000000h):
000h 4    Length of compressed map
004h 6    Offset of first block (48bit)     (E4h, after meta)
00Ah 2    CRC16 on decompressed map entries
00Ch 1    bits used to encode complength
00Dh 1    bits used to encode self-refs
00Eh 1    bits used to encode parent unit refs
00Fh 1    Reserved for future use (probably zero)
010h ..   Compressed Map entries (bitstream with Huffman/RLE encoding)
The decompressed map entries should look as shown below (one could store them
differently, eg. as 32bit little endian values; however, they must be stored
exactly as shown below when computing the CRC16 on decompressed map entries):
000h 1    Compression type (0..3=Codec0..3, 4=Uncompressed, 5=Self, 6=Parent)
001h 3    Compressed length (24bit big-endian)
004h 6    Offset to compressed data (48bit big-endian)
00Ah 2    CRC16 on decompressed data (big-endian)
V5 compression codecs:
0,0,0,0 = CHD_CODEC_NONE        ;-unused (when using less than 4 codecs)
"zlib" = CHD_CODEC_ZLIB         ;\
"lzma" = CHD_CODEC_LZMA         ; general codecs
"huff" = CHD_CODEC_HUFFMAN      ;
"flac" = CHD_CODEC_FLAC         ;/
"cdzl" = CHD_CODEC_CD_ZLIB      ;\
"cdlz" = CHD_CODEC_CD_LZMA      ; general codecs with CD frontend
"cdfl" = CHD_CODEC_CD_FLAC      ;/
"avhu" = CHD_CODEC_AVHUFF       ;-A/V codecs
```

**Uncompressed V5 Map loading (when [filehdr+10h]=00000000h)**

```
readfile(src,NumberOfHunks*4)                            ;\
i=0                                                      ; load uncomoressed
while i00000000h)**

```
readfile(hdr,10h)                                        ;\read map hdr and
readfile(src,bigendian32bit[hdr+0])                      ; compressed map
InitBitstream(src,BigEndianMsbFirst)                     ;/
i=0                                                      ;\
while i01h then num=GetBits(4)+3                    ;
for j=1 to num, codesizes[i]=val, i=i+1                ;
nonlzh_explode_tree(codetree,codesizes,10h)              ;/
i=0, typ=0, num=0                                        ;\
while inoncrc16(map,i*0Ch) then error ;-final crc check
```

noncrc16: Uses the same polynomial as for CDROM subchannels, but with initial
value FFFFh (instead 0) and with final value left un-inverted (instead of
inverting it).

nonlzh_explode_tree: Uses the same concept as for LZH/ARJ huffman trees (it's
storing only the number of bits per each codes, and the codes are then
automatically assigned). But CHD is doing that backwards: It's starting with
the biggest codes (instead of smallest codes). For example, if you have three
codes with size 1, 2, 2. The traditional standard assignment would be 0, 10,
11. But CHD is instead assigning them as 00, 01, 1.

```
______________________________ CHD Compression _______________________________
```

**Compression V1-V4 format 0 (uncompressed)**

**Compression V5 0,0,0,0 (uncompressed)**

```
000h ..   Uncompressed data
```

Uncompressed format can be selected in CHD Map entries (per hunk), and in CHD
file header (per whole file).

**Compression V1-V4 format 1 (zlib) (Generic Deflate)**

**Compression V1-V4 format 2 (zlib+) (Generic Deflate)**

**Compression V5 "zlib" (Generic Deflate)**

```
000h ..   Deflate-compressed data
```

**Compression V5 "lzma" (Generic LZMA)**

```
000h ..   LZMA-compressed data (with lc=3, lp=0, pb=2) (without EOS end code)
```

**Compression V5 "flac" (Generic FLAC)**

```
000h 1    Output format for 16bit samples ("L"=Little-endian, "B"=Big-endian)
001h ..   FLAC-compressed data frame(s)
```

**Compression V5 "huff" (Generic Huffman)**

```
000h ..   Huffman-compressed data (small tree, large tree, plus data)
```

**Compression V5 "cdzl" (CDROM Deflate+Delate)**

```
000h ..   ECC Flags, (SectorsPerHunk+7)/8 bytes ;little-endian, bit0=1st flag
...  2/3  Size of compressed Data part (SIZ)    ;big-endian, 16bit or 24bit
...  SIZ  Deflate compressed Data part          ;uncompressed=930h*N bytes
...  ..   Deflate compressed Subchannel part    ;uncompressed=60h*N bytes
```

**Compression V5 "cdlz" (CDROM LZMA+Deflate)**

```
000h ..   ECC Flags, (SectorsPerHunk+7)/8 bytes ;little-endian, bit0=1st flag
...  2/3  Size of compressed Data part (SIZ)    ;big-endian, 16bit or 24bit
...  SIZ  LZMA compressed Data part             ;uncompressed=930h*N bytes
...  ..   Deflate compressed Subchannel part    ;uncompressed=60h*N bytes
```

**Compression V5 "cdfl" (CDROM FLAC+Deflate)**

```
000h ..   FLAC-compressed Data Frame(s)         ;uncompressed=930h*N bytes
...  ..   Deflate compressed Subchannel part    ;uncompressed=60h*N bytes
```

**Compression V5 "avhu" (A/V mixup with Huffman and FLAC or so)**

This isn't used on CDROMs and details are unknown/untested. It does reportedly
exist in different versions, and does combine different compression methods for
audio and video data.

**Compression V4 format 3 (AV)**

Unknown, maybe same/similar as "avhu".

**Compression V3-V4 secondary compression method (FLAC CDDA)**

CHD source code claims that V3-V4 maps support "FLAC CDDA", but it doesn't
actually seem to support that (audio discs compressed with chdman v0.145 are
merely using Deflate).

```
_________________________ CHD Compression for CDROMs _________________________
```

**CDROM "cdzl" and "cdlz"**

If the sector's ECC flag is set:

```
Fix the 0Ch-byte Sync mark at [000h..00Bh]
Fix the 114h-byte ECC data at [81Ch..92Fh] in relation to Mode at [00Fh]
Fixing just means to overwrite those values (there's no XOR-filter or so).
CHD doesn't filter EDC values, MM:SS:FF:Mode Sector headers, nor  Subheaders.
```

The Size entry is 16bit (when N*990h<10000h) or 24bit (when
N*990h>=10000h), the size entry has no real purpose, however, it may be
useful for:

```
decompressing the subchannel part without decompressing the whole data part,
and for using libraries that don't return the end of the compressed data part
```

**CDROM "cdfl"**

There are no ECC flags (since Audio sectors don't have ECC).

There is no size entry (one must decompress the whole FLAC part to find the
begin of the Subchannel part).

The FLAC output is always stored in BIG-ENDIAN format (because CHD likes to use
big-endian for audio sectors, unlike formats like CUE/BIN).

**CDROM Subchannel data**

The Data part and Subchannel part must be interleaved after decompression (to
form 990h-byte sectors with 930h+60h bytes). The CHD map's CRC is then computed
on that interleaved data.

Most CHD files use metadata SUBTYPE:NONE which means that the 60h-byte
subchannel data is simply zerofilled and one must replace it by default
Index/Position values (AFTER the above CRC check). The CHD metadata lacks
accurate info about Index values; the PREGAP part is supposedly meant to have
Index=0 and the remaining sectors Index=1).

Although CHD files can contain subchannel data, CHDMAN has very limited support
for creating such files (the most practical way seems to be to convert
CCD/IMG/SUB to TOC/BIN and then convert that to CHD format).

```
___________________________ CHD CDROM Sector Sizes ___________________________
```

Decompressed CHD CDROM Sectors are always 990h bytes tall (930h+60h). However,
the Metadata TYPE/SUBTYPE entries may specify smaller sizes (corresponding to
the format of the original TOC/BIN or CUE/BIN image). CHD does arrange that
data as so:

```
000h  Sector Data                    (800h, 914h, 920h or 930h bytes)
...   Subchannel Data                (0 or 60h bytes)
...   Zeropadding to 990h-byte size  (0..190h bytes)
```

That is somewhat okay for V3/V4 files, but involves two design mistakes that
conflict with the V5 format:

```
- The ECC-Filter works only for 930h-byte sectors (920h does also contain
ECC, but CHD can't filter that, resulting in very bad compression ratio)
- The last 60h-byte are supposed to be Deflate-compressed Subchannel Data
(but 800h..920h+60h sectors actually contain Zeropadding in that location)
```

Note: The CHD Map CRC checks are done on the above arrangement (including
zeropadding, and any prior ECC-unfiltering).

After the CRC check, one most relocate the Sector/Subchannel parts to their
actual locations (and replace zeropadding by actual Sync marks, header,
sub-header, ECC/EDC, and Subchannel data as needed).

```
__________________________ CHD Compression Methods ___________________________
```

**Deflate**

This is raw Deflate (despite of being called "zlib" in chd headers and source
code; there aren't any ZLIB headers nor Adler checksums). V1-V4 does
distinguish between "zlib" and "zlib+" (both are using normal Deflate) (V3/V4
are always using "zlib+") (the "+" does probably just mean that file was
compressed with improved compression ratio).

CDROM File Compression ZIP/GZIP/ZLIB (Inflate/Deflate)

**LZMA**

This contains a raw LZMA bitstream (without .lzma or .lz headers). The LZMA
bitstream starts with 8 ignored bits, if Normalization occurs after last
compression code, then it will also end with 8 ignored bits (those ignored bits
aren't CHD-specific, they do also occur in other LZMA-based formats).

CDROM File Compression LZMA

**FLAC**

The data consists of raw FLAC Frames (without FLAC file header or FLAC metadata
blocks), the format is always signed 16bit/stereo (NumChannels=2
SampleDepth=16), the sample rate is don't care for compression purposes (the
FLAC Frame headers have it set to 09h=44100Hz).

Each FLAC Frame starts with a 14bit Sync mark (3FFEh), and ends with 16bit CRC.
There are usually several FLAC frames per CHD hunk (one must decompress all
FLAC frames, until reaching the decompressed hunk size).

Each FLAC Frame contains Left samples, followed by Right samples. After
decompression, CHD does store them in interleaved form (L,R,L,R,etc.)

CDROM File Compression FLAC audio

**Huffman**

This is using some custom CHD-specific Huffman compression.

```
decompress_chd_huffman_hunk:
InitBitstream(src,BigEndianMsbFirst)                               ;-init
codesizes[0..17h]=00h                     ;initially all unused    ;\
codesizes[0]=GetBits(3)                   ;get first entry         ;
i=GetBits(3)+1                            ;leading unused entries  ; small
@@small_tree_lop:                                                   ; tree
val=GetBits(3)                                                     ;
if val=07h then goto @@small_tree_done    ;trailing unused entries ;
codesizes[i]=val, i=i+1                   ;apply entry             ;
if i=00h then                                                   ; tree
data=val, codesizes[i]=data, i=i+1                               ;
else                                                               ;
len=GetBits(3)+2                                                 ;
if len=7+2 then len=GetBits(8)+7+2                               ;
for n=1 to len, codesizes[i]=datal, i=i+1                        ;
if i
Section      Index0 IndexN TrackPad Index0 IndexN TrackPad HunkPad
Real Disc    Yes    Yes    -        Yes    Yes    -        -
CHD Header   -      Yes    Yes      -      Yes    Yes      -
CHD Data     -      Yes    Yes      -      Yes    Yes      Yes
```

That is, the critical parts are:

```
Index0/pregap:  Metadata PREGAP:sectors isn't stored in compressed data
Track padding:  Metadata FRAMES:sectors is rounded up to N*4 sectors
Hunk padding:   The last hunk is additionally rounded up to hunksize
```

Missing Index0 might be a problem if a disc contains nonzero data between
tracks (like audio discs with applause in Index0 periods).

Track padding is total nonsense. The final hunk padding makes sense (but
confusingly that extra padding isn't included in the uncompressed size entry in
CHD header).

**Parent references**

Parent files are only used for writeable media like harddisks. The idea is to
store the original installation and operating system in a readonly Parent file,
and to store changes that file in a writeable Child file.

Unknown what determines which parent belongs to which child, and if parents can
be nested with other grandparents. Anyways, Parents aren't needed for CDROMs
(except, one could theoretically store CDROM patches in child files).

**Self references**

This can be used to reference to another identical hunk in the same file (eg.
zerofilled sectors or other duplicated data). There are some restrictions for
CDROMs: Data sector headers contain increasing sector numbers, so there won't
be any identical sectors. However, Audio sectors can be identical (unless they
are stored with subchannel info, which does also contain increasing sector
numbers).

**Mini**

Mini is only used in V3/V4 maps. It does apparently store the "data" directly
in the 8-byte Map offset field.

```
XXX Unknown what kind of "data" that is
(probably "normal compressed data", that happens to be 8 bytes or smaller).
```

Mini isn't used in V5 because the compressed V5 map doesn't contain any offset
fields (and things like zerofilled sectors could be as well encoded as Self
instead of Mini).

**CHDMAN versions**

CHD files can (cannot) be generated with the CHDMAN.EXE tool:

```
chdman hdr meta  features/requirements/bugs/quirks/failures...
v0.58  -   -     -   ;-CHD didn't exist in older MAME versions
v0.59  V1  -     -   ;\
v0.71  V2  -     -   ; supports harddisk CHD files only, not cdrom
v0.78  V3  xxxx  -   ;/
v0.81  V3  CHCD  bad ;-crashes after creating the CHD file header
v0.90  V3  CHCD  ok  ;\
v0.110 V3  CHCD  ok  ; requires cdrdao TOC/BIN as input (CUE/BIN does crash)
v0.111 V3  CHTR  ok  ; (warning: BIN filenames may not contain space chars!)
v0.112 V3  CHTR  bug ;    ;\works, but compression is somewhat bugged (files
v0.118 V3  CHTR  bug ;    ;/are BIGGER instead of SMALLER after compression)
v0.120 V3  CHTR  ok  ;
v0.130 V3  CHTR  ok  ;
v0.131 V4  CHTR  ok  ;/
v0.140 V4  CHT2  ok  ;\requires "unicows.dll" (=Quintessential Media Player)
v0.145 V4  CHT2  ok  ;/
v0.146 V5  CHT2  bad ;\says output file already exists (crashes on -f force)
v0.154 V5  CHT2  bad ;/
v0.155 V5  CHT2  bad ;\crashes instantly (shortly before CreateEventW)
v0.160 V5  CHT2  bad ;/
v0.161 V5  CHT2  bad ;\says output file already exists (crashes on -f force)
v0.169 V5  CHT2  bad ;/
v0.170 V5  CHT2  bad ;\missing KERNEL32.DLL:AddVectoredExceptionHandler
v0.217 V5  CHT2  bad ;/
v0.218 V5  CHT2  bad ;\requires "newer version of windows" (64bit)
v0.247 V5  CHT2  bad ;/
```

Note: The compression tool was originally called HDCOMP (V1/V2), and later
renamed to CHDMAN (V3/V4/V5).

**References**

CHD source code (see files cdrom.*, chd*.*, etc):

```
https://github.com/mamedev/mame/tree/master/src/lib/util
```

CHDMAN commandline tool for generating chd files:

```
https://github.com/mamedev/mame/blob/master/src/tools/chdman.cpp
```

CHD decompression clone with useful comments:

```
https://github.com/SnowflakePowered/chd-rs/tree/master/chd-rs/src
```

CHD format reverse-engineering thread:

```
http://www.psxdev.net/forum/viewtopic.php?f=70&t=3980
```

CDROM Internal Info on PSX CDROM Controller

PSX software can access the CDROM via Port 1F801800h..1F801803h (as described
in the previous chapters). The following chapters describe the inner workings
of the PSX CDROM controller - this information is here for curiosity only -
normally PSX software cannot gain control of those lower-level stuff (although
some low level registers can be manipulated via Test commands, but that will
usually conflict with normal operation).

**Motorola MC68HC05 (8bit single-chip CPU)**

The Playstation CDROM drive is controlled by a MC68HC05 8bit CPU with on-chip
I/O ports and on-chip BIOS ROM. There is no way to reprogram that BIOS, nor to
tweak it to execute custom code in RAM.

CDROM Internal HC05 Instruction Set

CDROM Internal HC05 On-Chip I/O Ports

CDROM Internal HC05 I/O Port Usage in PSX

CDROM Internal HC05 Motorola Selftest Mode

The PSX can read HC05 I/O Ports and RAM via Test Commands:

CDROM - Test Commands - Read HC05 SUB-CPU RAM and I/O Ports

**Decoder/FIFO (CXD1199BQ or CXD1815Q)**

This chip handles error correction and ADPCM decoding, and acts as some sort of
FIFO interface between main/sub CPUs and incoming cdrom sector data. On the
MIPS Main CPU it is controlled via Port 1F801800h..1F801803h.

CDROM Controller I/O Ports

On the HC05 Sub CPU it is controlled via Port A (data in/out), Port E
(address/index), and Port D (read/write/select signals); the HC05 doesn't have
external address/data bus, so one must manually access the CXD1815Q via those
ports.

CDROM Internal CXD1815Q Sub-CPU Configuration Registers

CDROM Internal CXD1815Q Sub-CPU Sector Status Registers

CDROM Internal CXD1815Q Sub-CPU Address Registers

CDROM Internal CXD1815Q Sub-CPU Misc Registers

The PSX can read/write the Decoder I/O Ports and SRAM via Test commands:

CDROM - Test Commands - Read/Write Decoder RAM and I/O Ports

The sector buffer used in the PSX is 32Kx8 SRAM. Old PU-7 boards are using
CXD1199BQ chips, later boards are using CXD1815Q, and even later boards have
the stuff intergrated in the SPU. Note: The CXD1199BQ/CXD1815Q are about 99%
same as described in CXD1199AQ datasheet.

**Signal Processor and Servo Amplifier**

Older PSX mainboards are using two separate chips:

CDROM Internal Commands CX(0x..3x) - CXA1782BR Servo Amplifier

CDROM Internal Commands CX(4x..Ex) - CXD2510Q Signal Processor

Later PSX mainboards have the above intergrated in a single chip, with some
extended features:

CDROM Internal Commands CX(0x..Ex) - CXD2545Q Servo/Signal Combo

Later version is CXD1817R (Servo/Signal/Decoder Combo).

Even later PSX mainboards have it integrated in the Sound Chip: CXD2938Q
(SPU+CDROM) with some changed bits and New SCEx transfer:

CDROM Internal Commands CX(0x..Ex) - CXD2938Q Servo/Signal/SPU Combo

Finally, PM-41(2) boards are using a CXD2941R chip (SPU+CDROM+SPU_RAM), unknown
if/how far the CDROM part of that chip differs from CXD2938Q.

Some general notes:

CDROM Internal Commands CX(xx) - Notes

CDROM Internal Commands CX(xx) - Summary of Used CX(xx) Commands

The PSX can manipulate the CX(..) registers via some test commands:

CDROM - Test Commands - Test Drive Mechanics

Note: Datasheets for CXD2510Q/CXA1782BR/CXD2545Q do exist.

**CDROM Pinouts**

Pinouts - DRV Pinouts

Pinouts - HC05 Pinouts

CDROM Internal HC05 On-Chip I/O Ports

**HC05 Port 3Eh - MISC - Miscellaneous Register (R/W)**

```
0    OPTM  Option Map Select (bank-switching for Port 00h..0Fh)
1    FOSCE Fast (Main) Oscillator Enable (0=Disable OSC, 1=Normal)
2-3  SYS   System Clock Select (0=OSC/2, 1=OSC/4, 2=OSC/64, 3=XOSC/2)
4-5  -     Not used (0)
6    STUP  XOSC Time Up Flag   (R)
7    FTUP  OSC Time Up Flag    (R)   (0=Busy, 1=Ready/Good/Stable)
```

Note: For PSX, OSC is 4.0000MHz (PU-7/PU-8), 4.2336MHz (PU-18 and up). SysClk
is usually set to OSC/2, ie. around 2MHz.

**HC05 Port OPTM=0:00h - PORTA - Port A Data Register (R/W)**

**HC05 Port OPTM=0:01h - PORTB - Port B Data Register (R)**

**HC05 Port OPTM=0:02h - PORTC - Port C Data Register (R/W)**

**HC05 Port OPTM=0:03h - PORTD - Port D Data Register (R/W)**

**HC05 Port OPTM=0:04h - PORTE - Port E Data Register (R/W)**

**HC05 Port OPTM=0:05h - PORTF - Port F Data Register (R) (undoc: R/W)**

These are general purpose I/O ports (controlling external pins). Some ports are
Input-only, and some can be optionally used for special things (like IRQs,
SPI-bus, or as Timer input/output).

```
PA.0-7  PAn   Port A Bit0..7 Input/Output            (0=Low, 1=High) (R/W)
PB.0-7  PBn   Port B Bit0..7 Input        /KWI0..7   (0=Low, 1=High) (R)
PC.0    PC0   Port C Bit0    Input/Output /SDI1 (SPI)(0=Low, 1=High) (R/W)
PC.1    PC1   Port C Bit1    Input/Output /SDO1 (SPI)(0=Low, 1=High) (R/W)
PC.2    PC2   Port C Bit2    Input/Output /SCK1 (SPI)(0=Low, 1=High) (R/W)
PC.3    PC3   Port C Bit3    Input/Output /TCAP (T1) (0=Low, 1=High) (R/W)
PC.4    PC4   Port C Bit4    Input/Output /EVI  (T2) (0=Low, 1=High) (R/W)
PC.5    PC5   Port C Bit5    Input/Output /EVO  (T2) (0=Low, 1=High) (R/W)
PC.6    PC6   Port C Bit6    Input/Output /IRQ2      (0=Low, 1=High) (R/W)
PC.7    PC7   Port C Bit7    Input/Output /IRQ1      (0=Low, 1=High) (R/W)
PD.0-7  PDn   Port D Bit0..7 Input/Output            (0=Low, 1=High) (R/W)
PE.0-7  PEn   Port E Bit0..7 Input/Output            (0=Low, 1=High) (R/W)
PF.0-7  PFn   Port F Bit0..7 Input/Undoc  A/D-input  (0=Low, 1=High) (R)(R/W)
```

**HC05 Port OPTM=1:00h - DDRA - Port A Data Direction Register (R/W)**

**HC05 Port OPTM=1:02h - DDRC - Port C Data Direction Register (R/W)**

**HC05 Port OPTM=1:03h - DDRD - Port D Data Direction Register (R/W)**

**HC05 Port OPTM=1:04h - DDRE - Port E Data Direction Register (R/W)**

**HC05 Port OPTM=1:05h - DDRF - Port F Data Direction Register (undoc)**

```
DDRX.0-7  DDRXn Port X Data Direction Bit0..7 (0=Input, 1=Output) (R/W)
```

Officially, there are no DDRB and DDRF registers (Port B and F are always
Inputs). Although, actually, Motorola's Bootstrap RAM <does> manipulate
DDRF.

**HC05 Port OPTM=1:08h - RCR1 - Resistor Control Register 1 (R/W)**

**HC05 Port OPTM=1:09h - RCR2 - Resistor Control Register 2 (R/W)**

```
RCR1.0    RAL   Port A.Bit0-3 Pullup Resistors (0=Off, 1=On)
RCR1.1    RAH   Port A.Bit4-7 Pullup Resistors (0=Off, 1=On)
RCR1.2    RBL   Port B.Bit0-3 Pullup Resistors (0=Off, 1=On)
RCR1.3    RBH   Port B.Bit4-7 Pullup Resistors (0=Off, 1=On)
RCR1.4    RGL   Port G.Bit0-3 Pullup Resistors (0=Off, 1=On) ;\
RCR1.5    RGH   Port G.Bit4-7 Pullup Resistors (0=Off, 1=On) ; on chips
RCR1.6    RHL   Port H.Bit0-3 Pullup Resistors (0=Off, 1=On) ; with Port G,H
RCR1.7    RHH   Port H.Bit4-7 Pullup Resistors (0=Off, 1=On) ;/
RCR2.0-7  RCn   Port C.Bit0-7 Pullup Resistors (0=Off, 1=On)
```

**HC05 Port OPTM=1:0Ah - WOM1 - Open Drain Output Control Register 1 (R/W)**

**HC05 Port OPTM=1:0Bh - WOM2 - Open Drain Output Control Register 2 (R/W)**

```
WOM1.0   AWOML Port A.Bit0-3 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
WOM1.1   AWOMH Port A.Bit4-5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
WOM1.2   GWOML Port G.Bit0-3 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
WOM1.3   GWOMH Port G.Bit4-5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
WOM1.4   HWOML Port H.Bit0-3 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
WOM1.5   HWOMH Port H.Bit4-5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
WOM1.6-7 -     Not used (0)
WOM2.0-5 CWOMn Port C.Bit0..5 Open Drain Mode when DDR=1 (0=No, 1=Open Drain)
WOM2.6-7 -     Not used (always both bits set)
```

==== Interrupts =====

**HC05 Port OPTM=0:08h - INTCR - Interrupt Control Register (R/W)**

```
0-1  -     Not used (0)
2    IRQ2S IRQ2 Select Edge-Sensitive Only (0=LowLevelAndNegEdge, 1=NegEdge)
3    IRQ1S IRQ1 Select Edge-Sensitive Only (0=LowLevelAndNegEdge, 1=NegEdge)
4    KWIE  Key Wakeup Interrupt Enable (0=Disable, 1=Enable)
5    -     Not used (0)
6    IRQ2E IRQ2 Interrupt Enable (0=Disable, 1=Enable)
7    IRQ1E IRQ1 Interrupt Enable (0=Disable, 1=Enable)
```

**HC05 Port OPTM=0:09h - INTSR - Interrupt Status Register (R and W)**

```
0    RKWIF Reset Key Wakeup Interrupt Flag (0=No Change, 1=Reset) (W)
1    -     Not used (0)
2    RIRQ2 Reset IRQ2 Interrupt Flag       (0=No Change, 1=Reset) (W)
3    RIRQ1 Reset IRQ1 Interrupt Flag       (0=No Change, 1=Reset) (W)
4    KWIF  Key Wakeup Interrupt Flag (PB/KWI)       (0=No, 1=IRQ) (R)
5    -     Not used (0)
6    IRQ2F IRQ2 Interrupt Flag (PC6)                (0=No, 1=IRQ) (R)
7    IRQ1F IRQ1 Interrupt Flag (PC7)                (0=No, 1=IRQ) (R)
```

**HC05 Port OPTM=1:0Eh - KWIE - Key Wakeup Interrupt Enable Register (R/W)**

```
0-7  KWIEn Port B.Bit0..7 Key Wakeup Interrupt Enable (0=Disable, 1=Enable)
```

==== SPI Bus ====

**HC05 Port OPTM=0:0Ah - SPCR1 - Serial Peripheral Control Register 1 (R/W)**

```
0    SPRn  SPI Clock Rate (0=ProcessorClock/2, 1=ProcessorClock/16)
1-3  -     Not used (0)
4    MSTRn SPI Master Mode Select      (0=Slave/SCK.In, 1=Master/SCK.Out)
5    DORDn SPI Data Transmission Order         (0=MSB First, 1=LSB First)
6    SPEn  SPI Enable (SPI1:PortC, SPI2:PortG) (0=Disable, 1=Enable)
7    SPIEn SPI Interrupt Enable (... ack HOW?) (0=Disable, 1=Enable)
```

**HC05 Port OPTM=0:0Bh - SPSR1 - Serial Peripheral Status Register 1 (R)**

```
0-5  -     Not used (0)
6    DCOLn SPI Data Collision Occurred         (0=No, 1=Collision)
7    SPIFn SPI Transfer Complete Flag          (0=Busy, 1=Complete) (R)
```

Note: SPSR1.7 appears to be reset after reading SPSR1 (probably same for
SPSR1.6, and maybe also same for whatever SPI IRQ signal).

**HC05 Port OPTM=0:0Ch - SPDR1 - Serial Peripheral Data Register 1 (R/W)**

```
0-7  BITn  Data to be sent / being received
```

==== Time Base / Config ====

**HC05 Port 10h - TBCR1 - Time Base Control Register 1 (R/W)**

```
0-1  T2R   Timer2 Prescaler (0=SysClk, 1=SysClk/4, 2=SysClk/32, 3=SysClk/256)
2-3  T3R   PWM Prescaler    (0=CLK3, 1=CLK3/2, 2=CLK3/8, 3=Timer2compare)
4-6  -     Not used (0)
7    TBCLK Time Base Clock (0=XOSC, 1=OSC/128) ; returns LAST byte of current opcode (=nn)
[x]                         --> returns FIRST byte of following opcode
```

CDROM Internal HC05 I/O Port Usage in PSX

**Port A - Data (indexed via Port E)**

```
porta.0-7 i/o  CXD1815Q.Data (indexed via Port E)
porta.0   in   debug.dta.serial.in  ;\normally unused (exists in early bios)
porta.1   out  debug.dta.serial.out ; (prototype/debug_status stuff)
porta.2   out  debug.clk.serial.out ;/(with portc.5 = debug.select)
```

**Port B - Inputs**

```
portb.0   in   F-BIAS  ;unused
portb.1   in   SCEx input (serial 250 baud, received via 1000Hz timer2 irq)
portb.2   in   LMTSW  aka /POS0        ;\pos0 and door switches
portb.3   in   DOOR   aka SHELL_OPEN   ;/
portb.4   in   TEST2
portb.5   in   TEST1 (CL316) enter test mode (instead of mainloop)
portb.6   in   COUT   ;
CDROM Internal HC05 Motorola Selftest Mode (52pin chips)

**Motorola Bootstrap ROM**

The Motorola MC68HC05 chips are including a small bootstrap ROM which gets
activated upon /RESET when having two pins strapped to following levels:

```
Pin30 PortC.6 (/IRQ2) (/XINT) ----> wire to 3.5V (VCC)
Pin31 PortC.7 (/IRQ1) (SCOR)  ----> wire to 7V (2xVCC)
```

Moreover, two pins are needed on /RESET for selecting a specific test mode:

```
Pin16 PortB.0 ----> ModeSelectBit0 (0=GND, 1=3.5V)
Pin17 PortB.1 ----> ModeSelectBit1 (0=GND, 1=3.5V)
```

The selectable four modes are:

```
Mode0: Jump to RAM Address 0040h (useless when RAM is empty)
Mode1: Semifunctional Selftest (useless)
Mode2: Upload 200h bytes to RAM & jump to 0040h (allows fast/custom dumping)
Mode3: Download ROM as ASCII hexdump (nice, but very slow)
```

The upload/download functions are using following additional pins:

```
Pin50 PortF.0 ----> TX output (11bytes: 0Dh,0Ah," AAAA DD ")
Pin51 PortF.1  RTS output or so (not needed)
Pin1  PortF.3 ----> DTR output or so (not needed)
Ground ------------ GND for RX/TX
```

RX/TX are RS232-like serial signals (but using other voltages, 0=0V and
1=3.5V). Transfer format is 8-N-1, ie. one startbit(0), 8 databits LSB first,
no parity, one stopbit(1). Baudrate is OSC/2/208 (ie. 9616 bps for 4.000MHz, or
10176 bps for 4.2336MHz clock derived from CXD2545Q/CXD2938Q).

Note: Above pins may vary on some chips (namely on chips that don't have
PortF). The pins for entering bootstrap mode (PortC in this case) should be
described in datasheets; but transfer protocol and mode selection (PortB) and
transmission (PortF) aren't officially documented.

**Mode2: Upload 200h bytes to RAM & jump to 0040h**

This mode is very simple and powerful: After /RESET, you send 200h bytes to the
RX input (without any response on TX output), the bytes are stored at
0040h..023Fh in RAM, and the chip jumps to 0040h after transferring the last
byte. The uploaded program can contain a custum highspeed dumping function, or
perform hardware tests, etc. A custom dumping function for PSX/PSone can be
found at:

```
http://www.psxdev.net/forum/viewtopic.php?f=70&t=557
```

After uploading the 200h-byte dumping function it will respond by send 4540h
bytes (containing some ASCII string, the 16.5Kbyte ROM image, plus dumps for
RAM and (banked) I/O port region, plus openbus tests for unused memory and I/O
regions.

**Wiring for Mode2 on PSX/PSone consoles with 52-pin HC05 chips**

```
.------------ pin31, PC7, SCOR, cut the connection
39       |   27               to Signal Processor,
.-----------------.             then wire Pin31 to 7.5V
40 |                 | 26
|  C nnnn         |
|  SC4309nnPB     |
|  G63C 185       |
pin50, TX  |                 |                  for Mode2 Selection
52 | O               | 14
'-----------------'
1            13
```

Good places to pick 3.5V and 7.5V from nice solder pads are:

```
CN602.Pin1  = 7.5V     ;\on PSX boards (with either 5pin or
CN602.Pin3  = 3.5V     ;/               7pin CN602 connectors)
IC601.Pin1  = 7.5V     ;-on PSone boards (3pin 78M05 voltage regulator)
IC102.Pin32 = 3.5V     ;-on PSone boards (32pin Main BIOS ROM chip)
```

The SCOR trace on Pin31, connects to Signal Processor...

```
CXD2510Q.Pin63  (eg. on PU-8 boards)   ;\
CXD2545Q.Pin74  (eg. on PU-18 boards)  ; either one of these, depending
CXD1817R.Pin49  (eg. on PU-20 boards)  ; on which chipset you have
CXD2938Q.Pin77  (eg. on PM-41 boards)  ;
CXD2941R.Pin85  (eg. PM-41(2) boards)  ;/
```

cut that trace (preferably on the PCB between two vias or test points, so you
can later repair it easily) (better don't try to lift Pin31, it breaks off
easily)

Note: Mode2 also requires Pin16=Low, and Pin30=High (but PSX/PSone boards
should have those pins at that voltages anyways).

**Mode3: Download ROM as ASCII hexdump**

This mode is very slow and not too powerful. But it may useful if you can't get
Mode2 working for whatever reason. Wiring for Mode3 is same as above, plus
PortB.0=3.5V. In this mode, the chip will send one 0Dh,0Ah," AAAA DD " string
immediately after /RESET (with 16bit address "AAAA" (initially 1000h), and 8bit
data "DD"). Thereafter the chip will wait for incoming commands:

```
4-digit ASCII HEX address --> change address, and return 0Dh,0Ah," AAAA DD "
chr(00h) --> increment address, and return 0Dh,0Ah," AAAA DD "
chr(07h) --> jump to current address (not so useful)
other characters --> same as chr(00h)
All digits/characters sent to RX input will produce an echo on TX output.
```

Basic setup would be wiring RX to GND (the chip will treat that as infinite
stream of start bits with chr(00h), so it will respond by sending data from
increasing addresses automatically; the increment wraps from 4FFFh to FE00h
(skipping the gap between Main ROM and Bootstrap ROM), and also wraps from
FFFFh to 0000h; transfer is ultraslow: 13 characters needed per dumped byte:
chr(00h) to chip, chr(00h) echo from chip, and 0Dh,0Ah," AAAA DD " from chip.

CDROM Internal CXD1815Q Sub-CPU Configuration Registers

**00h - DRVIF - Drive Interface (W)**

```
0-1 "L"     Reserved (should be 0)
2   LSB 1st CD DSP DATA order               (0=MSB first, 1=LSB first)
3-4 BCK MD  CD DSP Number of BCLKs per WCLK (0=16, 1=24, 2=32, 3=Reserved)
5   BCK RED Strobe DATA on BLCK Edge        (0=Falling Edge, 1=Rising Edge)
6   LCH LOW Channel on LRCK=Low             (0=Right, 1=Left)
7   C2PL1st      ... C2PO lower byte 1st
```

**01h - CONFIG 1 - Configuration 1 (W)**

```
0   HCLKDIS  HCLK Pin Output (0=8.4672MHz, 1=Disable; Fixed Low)
1   CLKDIS   CLK Pin Output (0=16.9344MHz, 1=Disable; Fixed Low)
2   9BITRAM  SRAM Databus width (0=8bit/normal, 1=9bit)
3-4 RAM SZ   SRMA Address bus (0=32K, 1=64K, 2=128K, 3=Reserved)
5   PRTYCTL      ... Priority Control
6   XSLOW    Number of clock cycles per DMA cycle (0=12, 1=4) (for SRAM)
7   "L"      Reserved (should be 0)
```

**02h - CONFIG 2 - Configuration 2 (W)**

```
0   "L"      Reserved (should be 0)
1   DACODIS        .... DAC Out Disable
2   DAMIXEN  Digital Audio Mixer Enable (0=Attentuator/Mixer for CD-DA, 1=No)
3   SMBF2    Number of Sound Map Buffer Surfaces (0=Three, 1=Two)
4   SPMCTL   Sound Parameter Majority Control (0=?)  ;\for ADPCM params
5   SPECTL   Sound Parameter Error Control    (0=?)  ;/
6-7 "L"      Reserved (should be 0)
```

**03h - DECCTL - Decoder Control (W)**

```
0-2 DECMD    Decoder Mode (0-7)
0 or 1  Decoder Disable            ;-disable sector reading
2 or 3  Monitor-only Mode          ;\no error correction
4       Write-only Mode            ;/
5       Real-time Correction Mode  ;\with error correction
6       Repeat Correction Mode     ;/
7       CD-DA Mode                 ;-audio
3   AUTODIST Auto Distinction (0=Use MODESEL/FORMSEL bits, 1=Use Sector Hdr)
(Error Correction is done according to above MODE/FORM values)
4   FORMSEL  Form Select (0=FORM1, 1=FORM2) (must be 0 for MODE1)
5   MODESEL  Mode Select (0=MODE1, 1=MODE2)
6   ECCSTR   ECC Strategy (0=Normal, 1=Use Error Flags; requires 9bit SRAM)
7   ENDLADR  Enable Drive Last Address    ...
```

**07h - CHPCTL - Chip Control (W)**

```
0   "L"      Reserved (should be 0)
1   DBLSPD   Double Speed Mode (0=Normal, 1=Double) (init CD DSP first)
2   RPSTART  Repeat Correction Start (0=No, 1=Start) (automatically cleared)
3   SWOPEN   Sync Window Open (0=SyncControlledByIC, 1=OpenDetectionWindow)
4   CD-DA    CD-DA Play     (0=No, 1=Playback CD-DA as audio)
5   CDDAMUTE CD-DA Mute     (0=Normal, 1=Mute CD-DA Audio)
6   RTMUTE   Real-time Mute (0=Normal, 1=Mute CDROM ADPCM)
7   SMMUTE   Sound Map Mute (0=Normal, 1=Mute Sound Map ADPCM)
```

CDROM Internal CXD1815Q Sub-CPU Address Registers

Drive Address -- used for storing incoming CDROM sectors in Buffer RAM

Host Address -- used for transferring Buffer RAM to (or from) Main CPU

ADPCM Address -- used for Real-time ADPCM audio output from Buffer RAM

**05h - CMADR - Drive Current Minute Address (R)**

```
0-6   CMADR    Address bit10-16 (in 1Kbyte steps)
7     -        Reserved (undefined)
```

Indicates the start address of the most recently decoded sector (called "Minute
Address" because it points to the MM byte of the MM:SS:FF:MODE sector header).
Normally, CMADR should be forwarded to Host:

```
HADR = (CMADR AND 7Fh)*400h+offset
HXFR = length OR 4000h
```

Whereas, offset would be usually 00h, 04h, or 0Ch (to start reading from the
begin of the sector, or to skip 4-byte MODE1 header, or 12-byte MODE2 header).
And length would be usually 800h (normal data sector), or 924h (entire sector,
excluding the leading 12 sync-bytes). Length bit14 is undocumented/reserved,
but the PSX CDROM BIOS does set that bit for whatever reason.

Alternately, the sector can be forwarded to the Real-time ADPCM decoder:

```
ADPMNT = (CMADR AND 7Fh) OR 80h
```

**19h - ADPMNT - ADPCM "MNT" Address (W)**

```
0-6   ADPxxx  ADPCM source Address bit10-16 (in 1Kbyte-steps)
7     RTADPEN Real-time ADPCM Enable (0=Disable, 1=Enable Real-time ADPCM)
```

**04h - DLADR-L, Drive Last Address, bit0-7 (W)**

**05h - DLADR-M, Drive Last Address, bit8-15 (W)**

**06h - DLADR-H, Drive Last Address, bit16 (W)**

```
0-16  DLADR  Addr. bit0-16     ...
17-23 "L"    Reserved (should be 0)
```

**10h - DADRC-L - Drive Address Counter, bit0-7 (W)**

**11h - DADRC-M - Drive Address Counter, bit8-15 (W)**

**12h - DADRC-H - Drive Address Counter, bit16 (W)**

```
0-16  DADRC    Incrementing Drive-to-Buffer Write Address, bit0-16
17-23 "L"      Reserved (should be 0)
```

**0Eh - DADRC-L - Drive Address Counter, Bit0-7 (R)**

**0Fh - DADRC-M - Drive Address Counter, Bit8-15 (R)**

```
0-15  DADRC Address bit0-15  ;bit16 is in Port 0Bh            ...
```

**0Ch - HXFR-L - Host Transfer Length, bit0-7 (W)**

**0Dh - HXFR-H - Host Transfer Length, bit8-11 and stuff (W)**

```
0-11  HXFR     number of data bytes, bit0-11 (0..FFFh)       ...
12    HADR.16  HADR  bit16
13    "L"      Reserved (should be 0)
14    "L" ??   Reserved (should be 0)   ;
CDROM Internal Commands CX(0x..3x) - CXA1782BR Servo Amplifier

**CXA1782BR - CX(0x) - Focus Servo Control - "FZC" FocusZeroCross at SENS pin**

```
23-20 4bit  Command (00h)
19    1bit  FS4 Focus Servo (0=Off, 1=On)
18    1bit  FS3 DEFECT
17    1bit  FS2 Enable Focus Search Voltage (0=Off, 1=On)
16    1bit  FS1 Select Focus Search Voltage (0=Falling, 1=Rising)
15-0  16bit Unused (don't care)
```

For Focus Search: Keep FS1=on, and toggle FS2 on and off (this will generate a
waveform, and SENS will indicate when reaching a good focus voltage).

**CXA1782BR - CX(1x) - Tracking/Brake/Sled - "DEFECT" at SENS pin**

```
23-20 4bit  Command (01h)
19    1bit  TG1,TG2 ON/OFF Tracking Servo Gain Up/Normal (hmmm?)
18    1bit  Brake Circuit ON/OFF
17-16 2bit  PS Sled Kick Height (0=+/-1, 1=+/-2, 2=Undoc, 3="Don't use"?)
15-0  16bit Unused (don't care)
```

Note: The PSX CDROM BIOS does use the "Undoc" setting (ie. bit17=1), but the
effect is undoc/unknown?

Note: CX(1x) works different on CXD2545Q (some bits are moved around, and the
"SledKickHeight" bits are renamed to "SledKickLevel" and moved to different/new
CX(3X) commands.

**CXA1782BR - CX(2x) - Tracking and Sled Servo Control - "TZC" at SENS pin**

```
23-20 4bit  Command (02h)
19-18 2bit  Tracking Control (0=Off, 1=Servo On, 2=F-Jump, 3=R-Jump) ;TM1,3,4
17-16 2bit  Sled Control     (0=Off, 1=Servo On, 2=F-Fast, 3=R-Fast) ;TM2,5,6
15-0  16bit Unused (don't care)
```

**CXA1782BR - CX(3x) - "Automatic Adjustment Comparator Output" at SENS pin**

```
23-20 4bit  Command (03h)
19    1bit  Value to be adjusted (0=Balance, 1=Gain)
18-16 3bit  New Balance or Gain value (depending on above bit)
15-0  16bit Unused (don't care)
```

Note: CX(3x) is extended and works very different on CXD2545Q.

**CXA1782BR Command 4x..7x - "HIGH-Z" at SENS pin**

```
N-N   4bit  Command (04h..07h)
```

**CXA1782BR Command 8x..Fx - "UNSPECIFIED???" at SENS pin**

```
N-N   4bit  Command (08h..0Fh)
```

**Note**

The Servo Amplifier isn't directly connected to the CPU. Instead, it's
connected as a slave device to the Signal Processor. There are two ways to
access the Servo Amplifier:

1) The CPU can send CX(0X..3X) commands to the Signal Processor (which will
then forward them to the Servo Amplifier).

2) The Signal Processor can send CX(0X..3X) commands to the Servo Amplifier
(this happens during CX(4xxx) Auto Sequence command).

CDROM Internal Commands CX(0x..Ex) - CXD2545Q Servo/Signal Combo

**CXD2545Q - CX(0x) and CX(2x) - same as CXA1782BR Servo Amplifier**

CDROM Internal Commands CX(0x..3x) - CXA1782BR Servo Amplifier

**CXD2545Q - CX(4x..Ex) - same as CXD2510Q Signal Processor**

CDROM Internal Commands CX(4x..Ex) - CXD2510Q Signal Processor

One small difference is that the CXD2545Q supports a new "M Track Move"
function as part of the CX(4xxx) command. And, some "don't care" bits are now
reserved (ie. some commands need to be padded with additional leading "0"
bits).

**CXD2545Q - CX(1x) - Anti Shock/Brake/Tracking Gain/Filter**

```
23-20 4bit  Command (01h)
19    1bit  Anti Shock (0=Off, 1=On)
18    1bit  Brake      (0=Off, 1=On)
17    1bit  Tracking Gain (0=Normal, 1=Up)
16    1bit  Tracking Gain Filter (0=Select 1, 1=Select 2)
15-0  16bit Unused (don't care)
```

**CXD2545Q - CX(30..33) - Sled Kick Level**

```
23-20 4bit  Command (03h)
19-18 2bit  Subcommand (0)
17-16 2bit  Sled Kick Level (0=+/-1, 1=+/-2, 2=+/-3, 3=+/-4)
15-0  16bit Unused (don't care)
```

**CXD2545Q - CX(34xxxx) - Write to Coefficient RAM**

```
23-16 8bit  Command (34h)
15    1bit  Zero (0)
14-8  7bit  Address (00h..4Fh = Select Coefficient K00..K4F)
7-0   8bit  Data    (00h..FFh = New value)
PLUS  8bit  Eight more bits on PSone (!)
```

Allows to change the default preset coefficient values,

CDROM Internal Coefficients (for CXD2545Q)

**CXD2545Q - CX(34Fxxx) - Write to Special Register**

```
23-12 12bit Command (34Fh)
11-10 2bit  Index (0=TRVSC, 1=FBIAS, 2=?, 3=?)
9-0   10bit Data (for FBIAS: bit0=don't care)
```

**CXD2545Q - CX(35xxxx) - FOCUS SEARCH SPEED/VOLTAGE/AUTO GAIN**

```
23-16 8bit  Command (35h)
15-14 2bit  FT  Focus Search-up speed 1
13-8  6bit  FS  Focus Search limit voltage (default 011000b) (+/-1.875V)
7     1bit  FTZ Focus Search-up speed 2
6-0   7bit  FG  AGF Convergence Gain Setting (default 0101101b)
```

**CXD2545Q - CX(36xxxx) - DTZC/TRACK JUMP VOLTAGE/AUTO GAIN**

```
23-16 8bit  Command (36h)
15    1bit  Zero (0)
14    1bit  DTZC DTZC Delay (0=4.25us/Default, 1=8.5us)
13-8  6bit  TJ   Track Jump voltage (default 001110b) (+/-1.09V)
7     1bit  Zero (0)
6-0   7bit  TG   AGT Convergence Gain Setting (default 0101110b)
```

**CXD2545Q - CX(37xxxx) - FZSL/SLED MOVE/Voltage/AUTO GAIN**

```
23-16 8bit  Command (37h)
15-14 2bit  FZS              XXX pg. 84
13-8  6bit  SM    Sled Move Voltage
7     1bit  AGS
6     1bit  AGJ
5     1bit  AGGF
4     1bit  AGGT
3     1bit  AGV1
2     1bit  AGV2
1     1bit  AGHS
0     1bit  AGHT
```

**CXD2545Q - CX(38xxxx) - Level/Auto Gain/DFSW (Initialize)**

```
23-16 8bit  Command (38h)
15    1bit  VCLM VC level measurement on/off
14    1bit  VCLC VC level compensation for FCS_In Register on/off
13    1bit  FLM  Focus zero level measurement on/off
12    1bit  FLC0 Focus zero level compensation for FZC Register on/off
11    1bit  RFLM RF zero level measurement on/off
10    1bit  RFLC RF zero level compensation on/off
9     1bit  AGF  Focus automatic gain adjustment on/off
8     1bit  AGT  Tracking automatic gain adjustment on/off
7     1bit  DFSW Defect switch disable (1=disable defect measurement)
6     1bit  LKSW Lock switch (1=disable sled free-running prevention)
5     1bit  TBLM Traverse center measurement on/off
4     1bit  TCLM Tracking zero level measurement on/off
3     1bit  FLC1 Focus zero level compensation for FCS_In Register on/off
2     1bit  TLC2 Traverse center compensation on/off
1     1bit  TLC1 Tracking zero level compensation on/off
0     1bit  TLC0 VC level compensation for TRK/SLD_In register on/off
```

VCLM,FLM,RFLM,TCLM are accepted every 2.9ms.

**CXD2545Q - CX(39xx) - Select internal RAM/Registers for serial readout**

```
23-16 8bit  Command (39h)
15    1bit  DAC Serial data readout DAC mode on/off
14-8  7bit  SD  Serial readout data select (see below)
7-0   8bit  Unused (don't care)
```

Serial Readout Addresses:

```
Addr    Data  Content
00h     8bit  VC input signal
01h     8bit  SE input signal
02h     8bit  TE input signal
03h     8bit  FE input signal
04h-07h 9bit  TE AVRG register (mirrored to 04h-07h)
08h-0Bh 9bit  FE AVRG register (mirrored to 08h-0Bh)
0Ch-0Fh 9bit  VC AVRG register (mirrored to 0Ch-0Fh)
12h     8bit  RFDC envelope (peak)
13h     8bit  RFDC envelope (bottom)
1Ch     9bit  TRVSC register
1Dh     9bit  FBIAS register
1Eh     8bit  RFDC input signal
1Fh     8bit  RF AVRG register
20h-3Fh 16bit Data RAM        (M00-M1F)
40h-7Fh 8bit  Coefficient RAM (K00-K3F) (note: K40-K4F cannot be read out)
```

**CXD2545Q - CX(3Ax000) - Focus BIAS addition enable**

```
23-16 8bit  Command (3Ah)
15    1bit  Zero (0)
14    1bit  FBON: FBIAS register addition (0=off, 1=Add FBIAS to FCS)
13-0  14bit Zero (0)
```

**CXD2545Q - CX(3Bxxxx) - Operation for MIRR/DFCT/FOK**

```
23-16 8bit  Command (3Bh)
15-14 2bit  SFO  FOK Slice Level (...depends on SFOX)
13-12 2bit  SDF  DFCT Slice Level (0=89mV, 1=134mV, 2=179mV, 3=224mV)
11-10 2bit  MAX  DFCT Maximum Time (0=No Limit, 1=2ms, 2=2.36ms, 3=2.72ms)
9     1bit  SFOX FOK Slice Level (...depends on SFO)
8     1bit  BTF  Bottom Hold Double-Speed Count-Up mode for MIRR (0=off)
7-6   2bit  D2V  Peak Hold 2 for DFCT (0=22.05kHz, 1=44.1, 2=88.2, 3=176.4)
5-4   2bit  D1V  Peak Hold 1 for DFCT (0=176.4kHz, 1=352.8, 2=705.6, 3=1411)
3-0   4bit  Zero (0)
```

**CXD2545Q - CX(3Cxxxx) - TZC for COUT SLCT HPTZC (Default)**

```
23-16 8bit  Command (3Ch)
15-0  16bit Unused (don't care)
```

**CXD2545Q - CX(3Dxxxx) - TZC for COUT SLCT DTZC**

```
23-16 8bit  Command (3Dh)
15-0  16bit Unused (don't care)
```

**CXD2545Q - CX(3Exxxx) - Filter**

```
23-16 8bit  Command (3Eh)
15-14 2bit  F1NDM FCS servo filter 1st stage (1=normal, 2=down)
13-12 2bit  F3NUM FCS servo filter 3rd stage (1=normal, 2=up)
11-10 2bit  T1NDM TRK servo filter 1st stage (1=normal, 2=down)
9-8   2bit  T3NUM TRK servo filter 3rd stage (1=normal, 2=up)
7     1bit  DFIS  FCS hold filter input extraction node (0=M05, 1=M04)
6     1bit  TLCD  Mask TLC2 set by D2 of CX(38) only when FOK low
5     1bit  RFLP  Pass signal from RFDC pin through low-pass-filter
4-0   5bit  Zero (0)
```

**CXD2545Q - CX(3Fxxxx) - Others**

```
23-16 8bit  Command (3Fh)          ... XXX pg. 89
15-14 2bit  Unused (0)
13-12 2bit  XTD
11    1bit  Unused (0)
10-8  3bit  DRR
7     1bit  Unused (0)
6     1bit  ASFG
5     1bit  Unused (0)
4     1bit  LPAS
3-2   2bit  SRO
1-0   2bit  Unused (0)
```

**CXD2545Q feedback on 39xx: see pg. 77 (eg. 390C = VC AVRG)**

XXX

**CXD2545Q - SENS output**

```
Index          ASEQ=0  ASEQ=1           Length
$0X            Z       FZC              -
$1X            Z       AS               -
$2X            Z       TZC              -
$38            Z       AGOK*1           -
$38            Z       XAVEBSY*1        -
$30-37,$3A-3F  Z       SSTP             -
$3904          Z       TE Avrg Reg.     9 bit
$3908          Z       FE Avrg Reg.     9 bit
$390C          Z       VC Avrg Reg.     9 bit
$391C          Z       TRVSC Reg.       9 bit
$391D          Z       FB Reg.          9 bit
$391F          Z       RFDC Avrg Reg.   8 bit
$4X            Z       XBUSY            -
$5X            Z       FOK              -
$6X            Z       0                -
$AX            GFS     GFS              -
$BX            COMP    COMP             -
$CX            COUT    COUT             -
$EX            OV64    OV64             -
$7X-9X,DX,FX   Z       0                -
```

*1 $38 outputs AGOK during AGT and AGF command settings, and XAVEBSY during
AVRG measurement.

SSTP is output in all other cases.

CDROM Internal Commands CX(xx) - Notes

**Serial Command Transmission (for Signal Processor and Servo Amplifier)**

Commands are sent serially LSB first via DATA,CLOK,XLAT pins: DATA+CLOK are
used to send commands to the chip, command execution is then applied by
dragging XLAT low for a moment.

Commands can be up to 24bits in length, but unused LSBs (the "don't care" bits)
can be omitted; the PSX BIOS clips the length to 8bit/16bit where possible (due
to the LSB-first transfer order, the chip does treat the most recently
transferred bit as MSB=bit23, and there's no need to transfer the LSBs if they
aren't used).

Aside from being used as command number, the four most recently transferred
bits are also used to select SENS status feedback (for the SENS selection it
doesn't matter if the four bits were terminated by XLAT or not).

**Sled Motor / Track Jumps / Tracking**

The Sled motor moves the drive head to the current read position. On a Compact
Disc, the term "Track" does normally refer to Audio tracks (songs). But the
drive hardware uses the terms "Track" and "Tracking" for different purposes:

Tracking appears to refer to moving the Optics via magnets (ie. moving only the
laser/lens, without actually moving the whole sled) (this is done for fine
adjustments, and it seems to happen more or less automatically; emulators can
just return increasing sectors without needing to handle special tracking
commands).

Track jumps refer to moving the entire Sled, one "track" is equal to one spiral
winding (1.6 micrometers). One winding contains between 9 sectors on innermost
windings, and 22.5 sectors on outermost windings (the PSX cdrom bios is
translating the sector-distance to non-linear track-distance, and emulators
must undo that translation; otherwise the sled doesn't arrive at the intended
location; the cdrom bios will retry seeking a couple of times and eventually
settle down at the desired location - but it will timeout if the sled emulation
is too inaccurate).

The PSX hardware uses two mechanisms for moving the Sled:

Command CX(4xxx) Forward/Reverse Track Jump: allows to move the sled by
1..131070 tracks (ie. max 210 millimeters), and the hardware does stop
automatically after reaching the desired distance.

Command CX(2x) Forward/Reverse Fast Sled: moves the sled continously until it
gets stopped by another command (in this mode, software can watch the COUT
signal, which gets toggled each "N" tracks; whereas "N" can be selected via
Command CX(Bxxxx), which is configured to N=100h in PSX).

The PSX cdrom bios is issuing another Fast Sled command (in opposite direction)
after Fast Sled commands, emulators must somehow interprete this as "sled
slowdown" (rather than as actually moving the sled in opposite direction, which
could move the sled miles away from the target). For some reason vC1 BIOS is
using a relative short slowdown period, whilst vC2/vC3 are using much longer
slowdown periods (probably related to different SledKickHeight aka
SledKickLevel settings and/or to different Sled Move Voltage settings).

**Focus / Gain / Balance**

The hardware includes commands for adjusting & measuring
focus/gain/balance. Emulators can just omit that stuff, and can always
signalize good operation (except that one should emulate failures for Disc
Missing; and eventually also for cases like Laser=Off, or Spindle=Stopped).

Focus does obviously refer to moving the lens up/down. Gain does probably refer
to reflection level/laser intensity. Balance might refer to tracking
adjustments or so.

CDROM Internal Coefficients (for CXD2545Q)

The CXD2545Q contains Preset Coefficients in internal ROM, which are copied to
internal Coefficient RAM shortly after Reset. CX(34xxxx) allows to change those
RAM settings, and CX(39xxxx) allows to readout some of those values serially.

**CXD2545Q - Coefficient Preset Values**

```
Addr Val Expl.
K00  E0  Sled input gain
K01  81  Sled low boost filter A-H
K02  23  Sled low boost filter A-L
K03  7F  Sled low boost filter B-H
K04  6A  Sled low boost filter B-L
K05  10  Sled output gain
K06  14  Focus input gain
K07  30  Sled auto gain
K08  7F  Focus high cut filter A
K09  46  Focus high cut filter B
K0A  81  Focus low boost filter A-H
K0B  1C  Focus low boost filter A-L
K0C  7F  Focus low boost filter B-H
K0D  58  Focus low boost filter B-L
K0E  82  Focus phase compensate filter A
K0F  7F  Focus defect hold gain
K10  4E  Focus phase compensate filter B
K11  32  Focus output gain
K12  20  Anti shock input gain
K13  30  Focus auto gain
K14  80  HPTZC / Auto Gain High pass filter A
K15  77  HPTZC / Auto Gain High pass filter B
K16  80  Anti shock high pass filter A
K17  77  HPTZC / Auto Gain low pass filter B
K18  00  Fix (should not change this preset value)
K19  F1  Tracking input gain
K1A  7F  Tracking high cut filter A
K1B  3B  Tracking high cut filter B
K1C  81  Tracking low boost filter A-H
K1D  44  Tracking low boost filter A-L
K1E  7F  Tracking low boost filter B-H
K1F  5E  Tracking low boost filter B-L
K20  82  Tracking phase compensate filter A
K21  44  Tracking phase compensate filter B
K22  18  Tracking output gain
K23  30  Tracking auto gain
K24  7F  Focus gain down high cut filter A
K25  46  Focus gain down high cut filter B
K26  81  Focus gain down low boost filter A-H
K27  3A  Focus gain down low boost filter A-L
K28  7F  Focus gain down low boost filter B-H
K29  66  Focus gain down low boost filter B-L
K2A  82  Focus gain down phase compensate filter A
K2B  44  Focus gain down defect hold gain
K2C  4E  Focus gain down phase compensate filter B
K2D  1B  Focus gain down output gain
K2E  00  Not used
K2F  00  Not used
K30  80  Fix (should not change this preset value)
K31  66  Anti shock low pass filter B
K32  00  Not used
K33  7F  Anti shock high pass filter B-H
K34  6E  Anti shock high pass filter B-L
K35  20  Anti shock filter comparate gain
K36  7F  Tracking gain up2 high cut filter A
K37  3B  Tracking gain up2 high cut filter B
K38  80  Tracking gain up2 low boost filter A-H
K39  44  Tracking gain up2 low boost filter A-L
K3A  7F  Tracking gain up2 low boost filter B-H
K3B  77  Tracking gain up2 low boost filter B-L
K3C  86  Tracking gain up phase compensate filter A
K3D  0D  Tracking gain up phase compensate filter B
K3E  57  Tracking gain up output gain
K3F  00  Not used
K40  04  Tracking hold filter input gain
K41  7F  Tracking hold filter A-H
K42  7F  Tracking hold filter A-L
K43  79  Tracking hold filter B-H
K44  17  Tracking hold filter B-L
K45  6D  Tracking hold filter output gain
K46  00  Not used
K47  00  Not used
K48  02  Focus hold filter input gain
K49  7F  Focus hold filter A-H
K4A  7F  Focus hold filter A-L
K4B  79  Focus hold filter B-H
K4C  17  Focus hold filter B-L
K4D  54  Focus hold filter output gain
K4E  00  Not used
K4F  00  Not used
```

VCD ISO Basic Files (INFO, ENTRIES, AVSEQnn, ISO Filesystem)

**Primary Volume Descriptor (00:02:16)**

VCDs are having a standard ISO Primary Volume Descriptor, with some VCD
specific entries:

```
008h 32  System Identifier (always "CD-RTOS CD-BRIDGE" for VCDs)
028h 32  Volume Identifier (often nonsense, eg. "" or "__" or "VolumeLabel")
23Eh 128 Application Identifier ("CDI/CDI_APPL.VCD;1" or "CDI/CDI_VCD.APP;1")
400h 8   CD-XA Identifying Signature ("CD-XA001" for PSX and VCD)
```

There are some more differences to normal CDROMs:

```
VCDs are using MODE2 (with 800h-byte and 914h-byte sectors)
MPEG videos are on extra data tracks (outside of the ISO area on Track 1)
Files in VCD or SVCD folders use fixed sectors numbers (00:04:00 and up)
All 16bit/32bit values in files in VCD,SVCD,EXT,etc are BIG-ENDIAN
```

Due to the fixed sector numbers, VCDs players can completely ignore the ISO
filesystem with filenames and folders, and just address everything via sector
numbers (though accessing files in EXT and CDI folders seem to require using
the filesystem).

**VCD\INFO.VCD or SVCD\INFO.SVD (00:04:00) (800h bytes, one sector)**

```
000h 8    ID "VIDEO_CD" for VCD (or "SUPERVCD"/"HQ-VCD  " for SVCD)
008h 1    Version             ;Version Major (01h) (or 02h for VCD 2.0)
009h 1    System Profile Tag  ;Version Minor (00h) (or 01h for VCD 1.1 or HQ)
00Ah 16   Album ID/Desc (name in ASCII, padded with SPC) (usually empty)
01Ah 2    Total Number of CDs in Album (1..N) ;\usually always 1,1 (even
01Ch 2    Number of this CD in Album   (1..N) ;/for movies with 2 discs)
01Eh 13   PAL Flags, 98x1bit, for each Track? (0=NTSC, 1=PAL)
02Bh 1    InfoStatusFlags (see below)
Below is usually zero-filled when not using PBC
02Ch 4    Size of PSD.VCD file (or PSD.SVD?) (0=None)
030h 3    First segment addr MM:SS:00 in BCD    (00:02:00 ???)
033h 1    Offset Multiplier for "PsdOffset" values in PSD.VCD (must be 8)
034h 2    Number of ListIDs in LOT.VCD file (1..7FFFh, plus 1 in some discs)
036h 2    Number of ITEMnnnn.DAT files (plus nonsense in some discs?)
Below is usually zero-filled (maybe exists on SVCD only?)
038h 1980 SegmentContent[1..1980] (b0-1=Audio, b2-4=Video, b5=Cont, b6-7=OGT)
7F4h 5*2  volume start time[0]: 5x16bit  ;aka playing_time[5] in seconds (?)
7FEh 2    Reserved (0)
```

InfoStatusFlags at [02Bh] describes certain characteristics of the disc:

```
bit0   Reserved, must be zero
bit1-2 Restriction (0=No, 1..3=Restricted category 1..3) (eg. "not for kids")
bit3   Special Information is encoded in the pictures, uh?
bit4   MPEG User Data is used for Closed Caption (user_data_cc) (0=No, 1=Yes)
bit5   Next Disc with PBC     (0=Start at ListID#1, 1=Start at ListID#2)
bit6   Next Disc without PBC  (0=Start at Track #2, 1=Start at Track #3)
bit7   Extended PBC available (0=No, 1=Yes... aka EXT\PSD_X exists?)
```

Note: Bit5/6 are used only if the next disc has the same Album ID (eg. the
feature allows to skip copyright messages if the same message was already shown
on another disc).

First_segment_addr: The location of the first sector of the Segment Play Item
Area [that is... the first ITEMnnnn.DAT file?], in the form mm:ss:00. Must be
00:00:00 if PSD size is zero. If PSD size is nonzero, but no segments used:
Usually set to 00:02:00.

**VCD\ENTRIES.VCD or SVCD\ENTRIES.SVD (00:04:01) (800h bytes, one sector)**

```
000h 8     ID "ENTRYVCD" for VCD and SVCD (or "ENTRYSVD" for VCD30)
008h 1     Version               ;\same as in INFO.VCD/SVD
009h 1     System Profile Tag    ;/
00Ah 2     Number of Entries/Chapters (1..500)
00Ch 4*500 Entry[N] (Track 02h..99h, and MM:SS:FF) (all 4 bytes in BCD)
7DCh 36    Reserved (0)
```

Version;

```
0x02 --- VCD2.0
0x01 --- SVCD, should be same as version in INFO.SVD
```

Sys_prof_tag;

```
0x01 if VCD1.1
0x00 else
```

**MPEGAV\AVSEQnn.DAT (pointers to max 98 MPEG-1 Tracks, nn=01..98) (for VCDs)**

**MPEG2\AVSEQnn.MPG (pointers to max 98 MPEG-2 Tracks, nn=01..98) (for SVCDs)**

**MPEGAV\AVSEQnn.MPG (pointers to WHATEVER) (as so on some SVCDs or VCD30?)**

These filesystem entries contain pointers to the video tracks (that is, outside
of the ISO area on Track 1).

Commercially made SVCDs can reportedly contain 7 folders: Autorun, Data, Ext,
Mpegav, Segment, Svcd and Vmp (ie. there's no MPEG2 folder on all SVCDs? though
that MPEGAV folder is said to contain a .MPG file instead of .DAT file).

VCD ISO Search Files (SCANDATA, SEARCH, TRACKS, SPICONTX)

Below files can help searching I-frames, and provide some info about the
content of Tracks and Segments.

Essentially, searching I-frames is possible without these files - however, if
present, then the files may be useful in two cases: For discs with variable
bitrates (which isn't allowed on VCDs though), and, for CDROM firmwares that
don't support "inaccurate" seeking (like telling it to start reading anywhere
NEAR some MM:SS:FF value, so one could skip sectors till reaching an I-frame)
(ie. if the firmware insists on a "accurate" seek position, then it's best to
give it a known I-frame address).

**Caution: Overlapping Sectors (!?!)**

Reportedly the new SVCD files TRACKS.SVD and SEARCH.DAT are on these sectors:

```
TRACKS_SVD_SECTOR = (PSD_VCD_SECTOR+1)    ;aka 2nd sector in PSD.SVD?
SEARCH_DAT_SECTOR = (TRACKS_SVD_SECTOR+1) ;aka 3rd..Nth sector in PSD.SVD?
```

If that's correct, then the files would overlap with PSD.SVD (when PSD.SVD is
bigger than one sector), that would be weird, but possible (ie. the "PsdOffset"
in PSD.SVD would need to "skip" the region used by those two files).

**EXT\SCANDATA.DAT (12+3*N bytes for VCD 2.0) (or 16+3*N+2*X+3*Y+3*Z for SVCD)**

This file fulfills much the same purpose of the SEARCH.DAT file except that
this file is mandatory only if the System Profile Tag of the INFO.SVD file is
0x01 (HQ-VCD) and also that it contains sector addresses also for each video
Segment Play Items in addition to the regular MPEG tracks.

```
SCANDATA.DAT Format for VCD 2.0 (12+3*N bytes):
000h 8    ID "SCAN_VCD"
008h 1    Version (02h for VCD 2.0)
009h 1    Reserved (0)
00Ah 2    Number of scan points (in 0.5s units) (max FFFFh = ca. 9.1 hours)
00Ch 3*N  Scan Point[0..N-1]  ;MM:SS:FF of closest I-frame
SCANDATA.DAT Format for SVCD (16+3*N+2*X+3*Y+3*Z bytes):
000h 8    ID "SCAN_VCD"
008h 1    Version (01h for SVCD)
009h 1    Reserved (0)
00Ah 2    scandata_count ;number of 3-byte entries in the table
00Ch 2    track_count    ;number of MPEG tracks on disc
00Eh 2    spi_count      ;number of consecutively recorded play item segments
; (as opposed to the number of segment play items).
010h 3*N  msf_t cum_playtimes[N]  ;cumulative playing time up to track N.
; (track time just wraps at 99:59:74)
xxxh 2*X  spi_indexes[X]          ;Indexes into the following scandata table
xxxh 2    mpegtrack_start_index   ;Index into the following scandata table
; (where the MPEG track scan points start)
xxxh 3*Y  The scandata table... [Y]  ;8bit Track Number and 16bit Index
uint8_t  track_num;      /* Track number as in TOC
uint16_t table_offset;   /* Index into scandata table
xxxh 3*Z  msf_t scandata_table[Z]  ;MM:SS:FF
```

**SVCD\SEARCH.DAT (13+3*N bytes)**

This file defines where the scan points are. It covers all mpeg tracks
together. A scan point at time T is the nearest I-picture in the MPEG stream to
the given time T. Scan points are given at every half-second for the entire
duration of the disc.

```
000h 8    ID "SEARCHSV"
008h 1    Version (01h)
009h 1    Reserved (0)
00Ah 2    Number of scan points
00Ch 1    Time_interval (in units of 0.5 seconds) (must be 01h)
00Dh 3*N  Scan Point[0..N-1]  ;MM:SS:FF of closest I-frame
```

Note: This SVCD file is about same as the old EXT\SCANDATA.DAT file on VCDs
(with one extra entry for Time Interval). Whilst, SVCDs are storing some
different stuff in EXT\SCANDATA.DAT (despite of the identical filename).

**SVCD\TRACKS.SVD (11+4*N bytes) (or rarely:11+5*N bytes)**

The TRACKS.SVD file contains a series of structures, one for each track, which
indicates the track's playing time (in sectors, not actually real time) and
contents.

SVCD\TRACKS.SVD is a mandatory file which describes the numbers and types of
MPEG tracks on the disc.

```
SVCD\TRACKS.SVD Format for SVCD (11+4*N bytes):
000h 8   ID "TRACKSVD"
008h 1   Version (01h)
009h 1   Reserved (0)
00Ah 1   Number of MPEG tracks (N)
00Bh 3*N Track playing_time[N]  (MM:SS:FF, in BCD)(in sectors, not real time)
0xxh 1*N TrackContent[N]  ;bit0-1=Audio,bit2-4=Video,bit5=Reserved,bit6-7=OGT
SVCD\TRACKS.SVD Format for VCD30 (11+5*N bytes) (some sort of SVCD-prototype):
000h 8   ID "TRACKSVD"
008h 1   Version (01h)
009h 1   Reserved (0)
00Ah 1   Number of MPEG tracks (N)
00Bh 5*N Cum_Playing_time and Content (MM:SS:FF in BCD, and OGT, Audio)
```

**SVCD\SPICONTX.SVD (1000h bytes, two sectors)**

Unknown if/when/where/why this file exists, possibly only on VCD30?

Note: The same info can be stored in INFO.SVD at offsets [038h..7F3h].

```
0000h 8       ID "SPICONSV"
0008h 1       Version (01h)
0009h 1       Reserved (0)
000Ah 2*1980  Segment Content[1..1980] (1st byte=OGT, 2nd byte=Audio)
0F82h 126     Reserved (0)
```

**Content Flags for Segments and Tracks**

For SVCD\INFO.SVD and SVCD\TRACKS.SVD (on SVCD) these are encoded in 1 byte:

```
bit0-1  Audio characteristics:
0 = No MPEG audio stream
1 = One MPEG1 or MPEG2 audio stream without extension
2 = Two MPEG1 or MPEG2 audio streams without extension
3 = One MPEG2 multi-channel audio stream with extension
bit2-4  Video characteristics:
In TRACKS.SVD this must be 0,3,7 (no still pictures)
0 = No MPEG video data
1 = NTSC still picture
2 = NTSC Reserved (NTSC still pic hires?)
3 = NTSC motion picture
4 = Reserved
5 = PAL still picture
6 = PAL Reserved (PAL still pic hires?)
7 = PAL motion picture
bit5    Indicates segment is continuation of an item
In TRACKS.SVD this must be 0 (reserved)
0 = First or only segment of item
1 = Second or later segment of item
bit6-7  Overlay Graphics/Text (OGT):
0 = No OGT substream
1 = Sub-stream 0 available
2 = Sub-stream 0 & 1 available
3 = All OGT sub-substreams available
```

For SPICONTX.SVD and SVCD\TRACKS.SVD (on VCD30) these are encoded in 2 bytes:

```
1st byte = Audio characteristics        ;\probably same values as
2nd byte = Overlay Graphics/Text (OGT)  ;/in above bitfields?
```

VCD MPEG-1 Multiplex Stream

**Multiplex Stream & Sector Boundaries**

The Multiplex stream is some higher level stream, intended to help to
distinguish between Audio- and Video-streams (which are enclosed in the
Multiplex stream). MPEG's are somewhat organized in "sectors", with sector size
varying for normal .mpg files and VCDs:

```
VCD discs   --> Sector Size = 914h bytes (the discs MODE2/FORM2 sector size)
.mpg files  --> Sector Size = 800h bytes (regardless of physical sector size)
```

Sectors are always beginning with a Multiplex Packet (and Multiplex Packets are
never crossing sector boundaries). If the amount of video data exceeds the
sector size, then it's split into several Multiplex packets, whereas, that may
happen anywhere in the video stream (ie. there can be Multiplex Headers
occurring even in the middle of Video packet).

**MPEG-1 Multiplex Pack (sector header) (12 bytes)**

The Pack Header is found at the begin of the stream (on VCDs, it's also found
at the begin of each sector). The SCR values might help on identifying the
current playback position, and, with the bitrate value, this could be also used
to compute the distance to another position (though there are other ways to
determine the position/bitrate, so the Pack is kinda useless).

```
32bit PACK_START_CODE (000001BAh)                                      ;-4byte
2bit Fixed (00b for MPEG-1) (would be 01b for MPEG-2)                 ;\
2bit Fixed (10b)                                                      ;
3bit System Clock Reference, bit32-30  ;\                             ;
1bit Marker (1)                        ; System Clock Reference (SCR) ;
15bit System Clock Reference, bit29-15  ; (intended Time,              ; 5byte
1bit Marker (1)                        ; in 90kHz clock cycles)       ;
15bit System Clock Reference, bit14-0   ;/                             ;
1bit Marker (1)                                                       ;/
1bit Marker (1)                                                       ;\
22bit Multiplex Rate (total bitrate of the stream, in 400bit/s units)  ; 3byte
1bit Marker (1)                                                       ;/
```

**MPEG-1 Multiplex System Header (12+N*3 bytes)(optionally)(at start of stream)**

The System Header is usally found after the first Pack at the begin of the
stream.

```
32bit SYSTEM_HEADER_START_CODE (000001BBh)                             ;\6byte
16bit Header Length minus 6 (in bytes) (0006h+N*3)                     ;/
1bit Marker (1)                                                       ;\
22bit Rate bound (max multiplex rate of all packs in the stream,       ; 3byte
1bit Marker (1)                              in 400bit/s units)       ;/
6bit Audio Bound (max number of audio streams in this ISO stream)     ;\
1bit Fixed Flag (1=Fixed bitrate)                                     ; 1byte
1bit CSPS Flag  (1=Constrained)                                       ;/
1bit System Audio Lock Flag  XXX                                      ;\
1bit System Video Lock Flag  XXX                                      ; 1byte
1bit Marker (1)                                                       ;
5bit Video Bound (max number of video streams in this ISO stream)     ;/
8bit Reserved (FFh)                                                   ;-1byte
```

Followed by N*3 bytes for the streams (each with first bit=set):

```
8bit Stream ID (C0h..DFh=Audio, E0h..EFh=Video)                       ;\
2bit Fixed (11b)                                                      ; 3byte
1bit STD buffer scale (0=Mul128/audio, 1=Mul1024/video)               ;
13bit STD buffer size  (largest required buffer over all packets)      ;/
```

Terminated by a value with first bit=cleared (eg. next 000001xxh value).

**MPEG-1 Multiplex Video/Audio/Special Packets (7..24 bytes, plus data)**

These packets are encapsulating the lower-level Video/Audio streams.

```
32bit  START (000001xxh BDh-BFh=Special, C0h-DFh=Audio, E0h-EFh=Video);\6byte
16bit  Packet Length minus 6 (in bytes) (1..18, plus data)            ;/
```

If (and while) next two bits are 11b (0..16 padding bytes):

```
(2bit) Fixed (11b, indicates presence of stuffing)       ;\optional 0..16byte
(6bit) Fixed (111111b)                                   ;/
```

If next two bits are 01b (buffer size info):

```
(2bit) Fixed (01b, indicates presence of buffer size)        ;\
(1bit) STD Buffer Scale (0=Mul128/audio, 1=Mul1024/video)    ; optional 2byte
(13bit) STD Buffer Size (for decoding, in above scale units)  ;/
```

Always:

```
2bit  Fixed (00b, indicates no further stuffing/buffer info);\
1bit  PTS Flag (Presentation Time Stamp)                    ; 0.5 bytes
1bit  DTS Flag (Decoding Time Stamp)                        ;/
```

If PTS Flag set:

```
(3bit) Presentation Time Stamp, bit32-30       ;\
(1bit) Marker (1)                              ; optional 4.5 bytes
(15bit) Presentation Time Stamp, bit29-15       ; (time when to output the
(1bit) Marker (1)                              ; the packet to audio/video
(15bit) Presentation Time Stamp, bit14-0        ; hardware, in 90kHz cycles)
(1bit) Marker (1)                              ;/
```

If DTS Flag set (in this case PTS Flag must be also set):

```
(4bit) Fixed (0001b)                           ;\
(3bit) Decoding Time Stamp, bit32-30           ; optional 5 bytes
(1bit) Marker (1)                              ; (recommended time when
(15bit) Decoding Time Stamp, bit29-15           ; to decode the block,
(1bit) Marker (1)                              ; in 90kHz cycles)
(15bit) Decoding Time Stamp, bit14-0            ;
(1bit) Marker (1)                              ;/
```

If PTS and DTS Flags are both zero:

```
(4bit) Fixed (1111b)                           ;-optional 0.5 bytes
```

Always:

```
...  packet data bytes                         ;-data...(not crossing sector)
```

Note: The first Multiplex Video Packet would usually start with a Sequence
Header Code (000001B3h), and the first Multiplex Audio Packet should always
start with an Audio Sync Word (FFFh).

However, the size of the Multiplex packets does usually differ from the size of
the packets in the audio/video stream, so new Multiplex Packets may occur
anywhere in the middle of those streams (eg. in the middle of a video slice,
the next Multiplex Video packet would then begin with the remaining slice
bytes, rather than with a 000001xxh code; it's also possible that a Multiplex
Audio packet gets inserted in the middle of the video slice).

The best (or easiest) way to get continous data for the lower level streams
might be to memcopy the data from Multiplex packets to separate Audio &
Video buffers.

**MPEG-1 Multiplex End Code (4 bytes)**

```
32bit END_CODE (000001B9h)                                             ;-4byte
```

This should occur at the end of the video. On a VCD it does also occur at the
end of each video track.

VCD MP2 Audio Stream

VCD video discs and .mpg movie files are having the MP2 Audio Stream enclosed
in the Multiplex stream (whilst .mp2 audio files may contain raw MP2 data
without Multiplex stream).

Each MP2 frame is starting with a FFFh syncword (which is always located on a
byte boundary). Unfortunately, the value FFFh can also occur anywhere in the
audio data (eg. a 16bit sample with value 3FFCh).

So, when starting mid-stream, one will need some guessing when searching a
valid syncword. The best method is to compute the frame size (based on the
supposed frame header), and then to check if supposed frame begins AND ends
with a sync word. Moreover, one could check for invalid sample rate values in
the frame header, or invalid "groupings" in the frame's data part.

VCDs are conventionally having three audio frames encoded in one CDROM sector,
so the first syncword can be simply found right after the multiplex packet
header (though that might differ in some cases: VCD2.0 allows different audio
bitrates, and a CDROM sector could be theoretically shared for Audio and Video
data).

**Overall MP2 Frame Format**

```
Header (32bit)
Optional CRC (16bit) (or 0bit if none)
Allocation Information
Scale Factor Selector Information
Scale Factors
Data
```

**MP2 Header**

```
12bit Syncword (FFFh)                                         ;\
1bit  Revision (0=MPEG-2, 1=MPEG-1)                           ; 2 bytes
2bit  Layer (2=Audio LayerII)                   ;for VCDs     ;
(3=LayerI, 1=LayerIII, 0=reserved)  ;not on VCDs  ;
1bit  Protection_bit (1=no crc)                               ;/
4bit  Bitrate_index (1..14)                                   ;\
(0=free format, 15=reserved)                          ;
2bit  Sampling_frequency                                      ; 1 byte
1bit  Padding_bit                                             ;
1bit  Private_bit                                             ;/
2bit  Mode                                                    ;\
2bit  Mode_extension (aka bound)                              ;
1bit  Copyright                                               ; 1 byte
1bit  Original/home                                           ;
2bit  Emphasis                                                ;/
```

**MP2 Checksum (optional)**

```
16bit CRC
```

**Allocation Information**

**Scale Factor Selector Information**

**Scale Factors**

**Data**

```
XXX...
```