[solved] PS1 ECC is incorrect (or my code is wrong)

[Misteek]

http://jce3000gt.com/forum/showthread.p ... 04#pid6504

Code: Select all

94 81 88 0b 00 00 00 00 00 00 00 00 00 00 fb 00 00 00 fb 00 00 00 00 00 // big endian
0b 88 81 94 00 00 00 00 00 00 00 00 00 fb 00 00 00 fb 00 00 00 00 00 00 // lil endian
0B 88 81 94 00 00 00 00 00 00 FB 00 00 00 FB 00 00 00 00 00 00 00 00 00 // game disc

yy yy yy yy ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
            01 02 03 04 05 06 07 08 09 10

Why is the ECC on an ISO missing the first few digits? This was the first sector of a disc image btw.

[TriMesh]

Try checking sector 16 or higher - a lot of PSX CDs genuinely do have broken ECC/EDC in the system area of the disc due to a bug in Sony's mastering tool.

[Misteek]

I think it's something in my code that's wrong: a lot of sectors throw an index out of bounds exceptions and my code produces correct ECC, except that it is prefixed with four zeros. Sectors 24 and 32, even.

edit

Yep, my code was wrong. I assigned the EDC to the wrong indices. It seems that every serious problem has at it's root CS 161 tier mistakes.

The IOOB exceptions disappeared too, but I still need to write a little for loop to test the entire disc image and deal with form 2 sectors as well.

When I'm done with that I need to integrate it with my editor and then I should be done unless there are hidden files or LBA tables somewhere. If file loading is done with LBAs, it won't be an issue until my editor can either change filesizes or edit tables of varying length (such as scripting systems, null-terminated pointer tables, and compressed files). Though if entire files are loaded and I never increase the size of a file, the latter shouldn't be an issue.

If anyone is interested I came up with a clever system that should make developing editors for PS1 games much easier. It can be applied to any system that uses disc images.

[TriMesh]

Glad to hear you got your code working - but if you find incorrect EDC/ECC in the system area of a PSX disc then it's quite possible it's just corrupt so you were right not to immediately jump to blaming your code

[Misteek]

Other than the directory sectors I would never patch the system area, so it doesn't matter until I move files around and change file sizes.

How does the EDC/ECC bug work, and does it matter? Is it used for anti-piracy protections in any games or the system itself? Can I patch the affected sectors without any problems?

[TriMesh]

Other than the directory sectors I would never patch the system area, so it doesn't matter until I move files around and change file sizes.

How does the EDC/ECC bug work, and does it matter? Is it used for anti-piracy protections in any games or the system itself? Can I patch the affected sectors without any problems?

It's not used for anything, and it appears to be simply an error - the only things in that area of the disc is the license info and the PSX logo that's displayed on the black boot screen. The mastering tool writes out the sectors with bit 5 of the submode field clear (I.E. it's flagged as an XA Mode 2 Form 1 sector) but the EDC field is zero - the boot ROM doesn't care about this because it's only checking the 0x800 bytes of sector data that would be present in a form 1 sector and ignoring the header, P/Q parity and EDC fields.

If you fix the ECC/EDC values and write it out to a CD-R then it still boots, so it's pretty clearly not a copy protection measure. My guess is that it was just a bug in the mastering software that nobody noticed because the old CDU-920 they used for mastering didn't understand XA formats and just treated it as a mode 2 track containing arbitrary data and because the boot ROM in the PSX would accept it anyway. By the time this was discovered, there were a large number of discs out in the wild that were written like that and hence all the later boot ROMs had to remain compatible with them.

[Misteek]

Apropos of nothing, some questions.

1. What would you need to move a file from one area of a disc image to another? Here's what I think I'd need to do.

* Check the directories to see if there's enough space to do it.
* Update the relevant directory entries
* Go through the disc image and from all the relevant sectors grab all the info you need in the header and subheader fields
* Store that info and the data fields
* Verify that the new locations are correct and unoccupied (assuming I care if the user makes a mistake)
* Store the old locations of the data so they can be zeroed out later (or now, if you prefer)
* Zero out the data in the old locations, recalculate EDC/ECC for those sectors, and write both to those sectors
* Go to new locations, use relevant header/subheader/data fields to calculate EDC/ECC, write all to new sectors

Seems doable. Doesn't seem to require much from me either - I don't need to know which are form 1 or 2, as it's a direct copy and paste.

Importing files is basically the same - actually easier, since no moving occurs - provided the files are the same size. If the file size is different we need to know which are data and which are video/audio.

---

2. Are images stored in form 1 or form 2?

---

3. Video and audio is stored in form 2, correct?

---

4. For moving files/directories, what do I need, in terms of parameters? I think I only need:
* Path/name of file
* Path/place it's being moved to
* Are sectors supposed to be organized alphabetically? If that's the case, you need to move all other files around to do so. If not, who cares?

---

5. Are files and directories supposed to be stored sequentially? What bad things happen if they aren't - long seek times?

---

6. If I wanted to insert new files into a disc image, what would I need as parameters? My guess:
* Which files or parts of the files that are audio, video, and maybe images
* The path/name to insert the file.
* The rest is the latter half of what I need to do to move files.

---

7. What do I need to do to create a disc image from a directory, or just a blank disc image?

---

8. What is the maximum size of a PS1 disc?

---

9. Is there any reason I can't increase the size of a disc to it's max and then move files around so every file has room to expand, provided the actual game uses the directories to navigate to files and load them into memory?

---

10. Is the info in chapter 2 of the Phillips CD-i spec correct? Especially the information regarding the structure of sectors.

---

11. What obscure and esoteric information exists regarding directories on PS1 disc images?

[TriMesh]

1) Looks plausible - you don't have to do anything special because a PSX CD is entirely standards compliant (which I guess is something you would expect from one of the companies that originated the CD standard in the first place). One thing you do need to watch is that CD-ROM directories are a little unconventional - in addition to the directory there is also another structure called the path table that is used to improve access performance. Failing to keep them in synch can result in strange and random behaviour.
2) Generally, images are data and data is stored in form 1 - there is nothing that actually prevents them (or any other data) from being written in form 2, however - you just need to write your own code to handle it, in which case they will probably be in some private format anyway.
3) Yes. Both the MDEC stuff and XA audio are stored in form 2 - the CD controller does implement the XA filtering functions so you can interleave streams using them.
4) Not sure what you mean... If you mean do directory entries have to be alphabetical then no - you can put them in any order you like.
5) In ISO9960, everything has to be stored in an unbroken sequence of incrementing logical block numbers. You can't have gaps in files. You can leave unused space on the disc, or move other stuff around to fit into the space and adjust the directory to match.
6) Pretty much - just write the data to some series of blocks and update the directory to include it.
7) Best thing to do is download the SDK and have a look at "cdgen" - this is the original Sony program used to create PSX CDs and obviously produces compatible images
8) The CD controller doesn't do anything special with FADs and will in theory accept up to 99 minutes - the catch is that it uses hard-coded skew tables for seeks and hence the seek performance degrades as the disc size gets further away from the 74 minute CDs it was designed for.
9) No, but see the but about seek performance above
10) Yes, the PSX uses standard CD-ROM XA discs, although some of the flags are ignored by the CD controller. All the stuff about the subheader is accurate. Note that the PSX does have a raw read mode (0x924 long sectors) and if you use that the CD controller just gives you the data.
11) You can treat the PSX disc format as being ISO9960 - the only strange thing is that the STR files are written in form 2, so systems that don't support XA will either error out reading them or return corrupt information. This is obviously much less of an issue than it used to be since XA support is close to universal now. Even a non-XA compliant system can copy the discs OK, since according to the TOC the tracks are mode 2, and since the first 12 bytes of an XA sector are the same as the first 12 bytes of a mode 2 sector this works with no problem. The only catch is that if you read a raw dump of a track using tools that don't understand XA format then the data is extracted from the wrong place because of the subheader.

I think that's basically it - all the information you need should be in ECMA-119 (for the file system) and the CD-i Green Book (for the XA stuff).

[Misteek]

If anyone is interested, I got I/O working. Look the last two methods in DataHandler.java for most of it.

https://bitbucket.org/Mithridates/snakeoil/src