Search options

Cool. I don't know what dumping tools you have, but most should work as-is, or with minor modifications.

1) Dump the sub-channel data from the whole disc, and create a list that shows which subchannel bytes are wrong on which sectors. You are probably already having hardware & software tools that can do that? I don't have an exact sub-channel dump with all data and CRCs for that disc yet.

2) Detecting subchannel patterns. Yeah, something might become visible after dumping.
There are probably only 6 changed sectors on minute 03 (or maybe twice as many if it contains backup copies 5 sectors apart, but even the newer MediEvil didn't have that), and probably no changes on minute 09 (or it would be difficult to dump them, as that'd be ways in the Lead-Out of the yaroze disc). And there might be some other patterns like CRC's being XORed with something other than 0080h.
But if there are other similar old discs, it's hard to predict if they follow the same pattern.

3) Detecting EXE patterns. A simple way would be to scan the boot EXE (or also other EXEs or the whole Track 1.BIN) for values from the old and new "libcrypt_msf_list". Like searching these values in hex editor:

NewLibCrypt:  03 08 02 05 03 09 53 56 03 13 07 10 03 14 26 29 03 15 21 24 03 18 46 49 03 20 53 56 03 21 52 55 03 23 14 17 03 24 09 12 03 25 00 03 03 28 25 28 03 32 16 19 03 33 53 56 03 34 48 51 03 35 39 42
or
OldLibCrypt:  03 08 02 05 03 08 01 04 03 09 53 56 03 09 52 55 03 13 07 10 03 13 06 09 03 14 26 29 03 14 25 28 03 15 21 24 03 15 20 23 03 18 46 49 03 18 45 48 03 13 07 10 03 13 06 09 03 14 26 29 03 14 25 28

That should work in most cases (unless the EXE is compressed, or the bytes are crossing a sector boundary in the BIN file).

Yes, the "SC4309xx" names on the 52pin chips seem to be unique for each version/region. The older 80pin chips do probably also have some unique names (current rule-of-thumb is that 80pin chips aren't dumped, not matter of their name). The dev-board EPROM version http://upload.wikimedia.org/wikipedia/c … PU1_01.jpg has some sticker saying '94 11/28, that's also undumped, despite of the EPROM socket).

NB. when looking at the mainboards: It would be very nice to take photos/scans of their front & back sides. Such pictures are still quite hard to find in the internet.

The long answer is that the cdrom bios (or "drive firmware") controls this stuff: http://nocash.emubase.de/psx-spx.htm#cd … controller
PSX games are sending commands like ReadN, SetLoc, GetStat to the cdrom sub-cpu: http://nocash.emubase.de/psx-spx.htm#cd … andsummary Currently, PSX emulators are using high-level emulation to reproduce that commands, although nobody really knew what those commands were doing internally. Using low-level emulation for the 8bit CPU and the attached cdrom chipset should make emulators much more accurate...
But, in practice, most PSX games seem to be happy with high-level emulation either (I've emulated the whole stuff in no$psx last week (99% finished, but not yet released), and the overall effect was that it did make the the emulation slower, especially due to longer spin-up & sled-move times, but it didn't fix problems with game that did hang during cdrom loading - at least I do now know that those problems seem to be related to something else than cdrom emulation).

Rather not. The built-in dumping function is spitting out the whole binary in form of a "hexdump.txt" file, but I guess there's some copyright envolved nonetheless. Anyways, it's a pretty simple DIY project to dump it.

If somebody wants to send PSX mainboards to hamburg/germany, I could dump them for you (and return the boards... as long as I don't have to bother about the postage).

Yes, that would work. But only if the .MDF files does contain subchannel data (which is optional, it could also contain raw sector data). And it won't work for stuff located in lead-in (namely CD-TEXT) (and I think EAN and maybe even ISRC could be also stored in lead-in, although the typical PC cdrom drives may be unable to extract that data).

Yeah, guess I should support that, too. It isn't my first choice though - I'd much prefer fileformats where all data is stored in one file. And the required filenames are looking quite fragile to me (like: somebody renames the files, but doesn't edit the names in the .CUE accordingly).
At the moment I am completely ignoring the filename(s) inside of the .CUE (and just expect file.CUE to refer to file.BIN with same name).

Okay, then maybe I won't really need it in no$psx. Anyways, just for curiosity... trying to understand what scrambling means:

http://www.icdia.co.uk/cdprosupport/cdi … ambled.htm tells that data sectors are scrambled, and audio sectors aren't scrambled.

http://club.myce.com/f61/unscramble-sec … ost1267339 tells that scrambling and unscrambling is done by XORing some constants.

So, in the emulation, all I would need to do is:
Do the XORing when doing a DATA-READ on an AUDIO sector.
Do the XORing when doing an AUDIO-PLAY on a DATA sector.
Sounds easy... if I got that right.

Rok (the libmirage guy) has tested .mds files with more than 9 tracks some days ago. The track numbers are non-BCD (which solving my main question about the format).

He has also made some .mds/.ccd sample images with ean/catalog, isrc, cdtext, more than 2 indices and multiple sessions (which is interesting, although not so important to me; for my psx emulator).

According to Rok's tests, Alcohol .mds images don't have any support for EAN (catalog), ISRC, and CD-TEXT. The html manual on the Alcohol webpage doesn't mention that features either. So far it looks as if they unsupported - although that's hard to believe.
The thing that Rok has tested was: Creating a CD-image as .toc/.bin files, mounting it as virtual cdrom-drive, and then recording it via CloneCD and Alcohol. The resulting .ccd image did have the EAN/ISRC/CD-TEXT stuff. But the .mds image didn't.

> I also think MDS files can contain additional data from a disc, such as ATIP info.
Then it'd be even stranger if it really doesn't support basic features like ISRC... maybe things like ISRC do work too, but need to be enabled via special options.
Seeing a .MDS file with ATIP info would be interesting. Even if it's only to resolve some of the "unknown" MDS file entries; libmirage/mds source code doesn't seem to handle ATIP.

> DPM measurement is used for a lot of things, SecuROM,
> Starforce, Tages, both CD and DVD.
I really hope that I won't need DPM for my PSX emulation! At least, I've never heard about PSX games using DPM.
And for DPM in general, there seems to be a lot of confusion, at least, on wikipedia :-)
For example, http://en.wikipedia.org/wiki/Data_position_measurement claims that SecuROM uses DPM, but in the same sentence, they are referencing to http://www.encrypt.ro/cd-encryption/cd- … curom.html which tells that it uses Data Density (not Position) Measurement.

> iirc Alcohol mdf which are 2448 also store the subchannels
> scrambled in the image. Where as .sub files from CloneCD
> are unscrambled. However 2448 images can have the
> subs either way...
In the formats that I've looked at yet, I've seen the unscrambled variant only in .SUB files. All other formats (with 930h+60h bytes per sector) seem to use scrambled subchannels. But I guess, sooner or later, I'll come across a format that does it the other way.

> Also for ECM encoded images, they are meant to be decoded back
> into a .bin/.img/.mdf image before use.
Yes, seems to be the only way to deal with them. I've added a ECM "decompression" function doing that in no$psx v1.1 (released yesterday) bundled with some cautions about typical ECM-related problems (like .BIN.ECM files without .CUE files).

Oh, and my http://nocash.emubase.de/psx-spx.htm#cdromdrive specs have been updated yesterday, too. The new chapters contain info on .CCD, .CDI, .MDS, .ECM, .SBI, .M3S. The CDI format contains a lot of useless garbage entries (apparently filled with meaningless constant values), but it's easy to implement when ignoring that garbage.

I've also had brief look at mame/mess source code, hoping to find out more about compressed .CHD images... the "chdman" source code looked like a good place to start with... but, after reading it, I didn't learn anything about the file-structure, compression-filters, and compression-algorithm :-/ maybe I didn't study it carefully enough, or the relevant info hides in other libraries/include files.

For .MDS files, this is what I have figured out:

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 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)

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   Zero (for DVD?: Offset to DPM data blocks)  (from begin of .MDS file)

Session-Blocks (18h bytes)
  00h 4   Pregap correction. ALBA. (0=TAO, FFFFFF6Ah=-150=DAO)
  04h 4   Total number of sectors (in Pregap, plus in .MDF file)
  08h 2   Session number (starting at 1)
  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 ? Unknown (01h) (total number of sessions in image?)
  0Eh 2   Last Track ? Number of Data Blocks with Point<A0h (Normal Track info)
  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   Zero (probably Track, which is alwas 0 in Lead-in)               Q1?
  04h 1   Point (BCD? Track, or A0h and up=Lead-in)                         Q2
  05h 4   Zero (probably dummy MSF and reserved byte from Q channel)   Q3..Q6?
  09h 1   Minute (Non-BCD!) (if track >= 0xA0 -> info about track ###)      Q7
                            (if track = 0xA2 -> min. @ lead-out)
  0Ah 1   Second (Non-BCD!) (if track = 0xA2 -> sec. @ lead-out)            Q8
  0Bh 1   Frame  (Non-BCD!) (if track = 0xA2 -> frame @ lead-out)           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:00: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 8 bytes in size (two 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).

Missing
Unknown if/how this format supports EAN-13, ISRC, CD-TEXT.
Unknown if Track/Point/Index are BCD or non-BCD.

For the "Missing" parts, it would be interesting how they do work. For audio discs & games with more than 9 tracks it'd be absolutely important to know if Tracks are BCD or non-BCD... or if the file format does support than many tracks at all :-)
But I am giving up there for now, I've asked in this forum, and in another forum, but finding somebody who has some .MDS files for examing them seems to be pretty impossible.

Many thanks! Good to know!

Ah, okay... then the correct way to support sbi files in my psx emu would be:
Ignore all Q channel data in the sbi file, and replace by Q channel data from previous sector.
Easy to do that. Although it's a bit surreal :-)
Was that sbi format designed specially for psx/libcrypt? Or was it originally for other computers/consoles?

Yes, looks so. LC1 and LC2 are fine. But "Other sectors" could either mean LC3 or other/broken/scratched sectors.
NB. the links on the http://redump.org/guide/libcrypt/ page are a all broken/corrupted: The "psxt001z 0.20" links return the .7z as text document instead binary, and the "PSXCPLIST" is completely gone.

Oh, and aside from .sbi, the 'PSEmu Pro CDR plugin interface' source code does also mention .m3s files: containing all subchannel Q data from all sectors with minute=03 (the sectors where normal libcrypt data is found). It doesn't support the backup (on minute=09).
The source code says m3s contain 10 bytes from Q channel plus 6 garbage bytes, but that isn't exactly right: there are 12 bytes (including the crc bytes) plus 4 garbage bytes, as seen in this files: http://www.ngemu.com/forums/showpost.ph … ostcount=8
The 4 garbage bytes seem to be set to 00,00,00,00 or FF,FF,FF,FF (randomly containing either value on this or that sector). The "garbage" doesn't make any sense to me... unless it's meant to contain 32bit timing offset ranging from -1 to +0 or so.

Oops, yes, I meant that CCD has constant sectorsize+pregap, not MDS.

I wasn't succesful finding MDS collections. And no info on StarForce+DPM, does that combination really exist? Wikipedia does only mention SecuROM+DPM.

How well is CHD working? Does it allow random access (without needing to decompress the whole cdrom-image)? And does it reach a good compression ratio?