SCPH-5903s, how do they work?

And I don't mean the daughterboard; that part is well-known. Also, there were several after-market VCD daughterboard mods for regular PS1 models to add VCD playback support.

What I'm curious about is, how was the VCD player on the SCPH-5903 able to read data sectors off a CD-ROM XA disk that didn't pass the PS1 copy protection system without the CD controller rejecting the request? Was the CD controller different somehow to detect Video CDs and allow reading them?

Maybe I'll have to reverse engineer this sometime.

 

These required mod chips or fitting a lid spring and put in a game disc first (they often came with a spring).

 

I figured as much, but that leaves a mystery as to how the SCPH-5903 itself worked, since those don't have mod chips. They must have a weird CD controller as my logic goes.

Why the aftermarket VCD mods would use a swap trick I don't know. You have to solder in the VCD board anyway, so why not just have the VCD board have 2 more places to solder to?

 

I have a VCD mod board in my 7x it replaces the whole bios

 

From what I was told, there were a number of reasons - they didn't want to produce multiple SKUs for different region consoles, they were concerned that Sony might come up with some new anti-mod protection that forced them to rework all their stock and most of all they figured that making a gray market accessory for a Sony console was iffy enough anyway without adding features to it that directly enabled piracy.

As for the SCPH-5903, I thought I had one here, but I can't seem to find it. I can see two ways for them to handle it - one is having a modified CD controller that would allow the console to read the disc even if it didn't have a wobble grove on it - but since this would also have the effect of breaking their copy protection I really can't see them doing it.

The other is to have a Video-CD chip with a built in decoder and just tap into the I2S transport stream and subq signal between the CD DSP and the CD decoder chip - when you play a video CD, put the main PSX transport into audio playback mode. mute the CDDA channel and let the VCD decoder chip decode the raw data off the disc.

The latter is the way I would have done it if I had been responsible for the design, simply because it would have allowed the existing copy protection system to remain intact.

 

Actually you don't. The VCD players for the original PS1 just plugged into the parallel and multi AV ports. I have a psone board that has to be soldered in and that connects to the audio ports, I think that might grab the data by playing the data track as an audio track.

I get repeatedly side tracked by other things, but the sub cpu is something I have on my list to emulate now that one has been dumped.

 

Here's a thought - since Video-CD is bridge format, you could create a specially corrupted disk that had all the data in the right place, but had the pointers in the ISO9660 part messed up. If the video plays correctly, then the player is extracting the video information from the audio stream - if it plays with the altered locations in the ISO part, then it's reading the disc as a data disc.

 

Reading a data track as audio could work if directly attached to the board. But how would it recognize a Video CD in the first place? A pirate PS1 game and a video CD will look the same if you can't read the data track - they're both in mode 2, which is very rare for anything except PS1/PS2 games, CD-I games, and video CDs.

Muting the audio when playing a data track as audio is automatic, by the way. The CD controller sees (I think) the 0x40 bit in (I think) the first byte of sub-Q and knows to mute the output, despite continuing playback. Most players made after 1990 or so will either mute or skip data tracks.

 

OK, I can see I'm going to have to go into boring detail here

There are actually two different "Video CD" formats - the first was the one that came out with the release of the CDi platform, and used CDi formatted discs with a "video" flag bit set in the subheader - the second was the "White Book" Video CD, which had the same basic track structure as the Green Book ones, but also added an ISO data section with video information in it and had discs flagged as "CD-ROM XA".

White Book was specifically designed to be backwards compatible, so all the low-level layout of the disc was the same as the Green Book ones, and the ISO data track just contained pointers to same video data that a Green Book VCD player used. This is why you can get old Video CD disks that won't play on PCs (old Green Book discs), and it's possible to build a disc that looks like a Video CD and plays OK on a PC but won't work when you put it into a standalone VCD player (since it doesn't have the correct low-level structure).

This is also the reason it's a very good idea to mute the audio - Green Book VCDs are not flagged as data discs but as CDi discs and some players will misinterpret the data as audio (thinking about it, the PSX probably won't, since it has a DSP that knows about XA audio and presumably understands the other header codes too) - so muting the audio path falls into "possibly not necessary, but a prudent thing to do anyway" category - it also avoids nasty edge cases like where the first sector in the track has a corrupt subheader and gets misidentified as audio before the decoder chip has a chance to pick up on the fact that this is really a video track, with resulting unpleasant effects on your ears.

I happen to have quite a few of the old Green Book VCDs here (they were very common in HK at one point), and was going to try playing them on my SCPH-5903 - but that experiment was prevented by the fact that I can't seem to find it. I did try playing them on one of the add-on VCD cards (Gamars PSX-002 on a SCPH-7503) and they don't work. The Saturn with VCD card can play them, though.

 

Hmm. I had no idea that CD-i disks weren't flagged as data disks. Are they still encoded as if they were data, or do they have they own encoding entirely separate from CD-ROM?

I wish I had some of these to analyze =) I only have one working video CD pair - Star Trek 7. Looks actually legitimate and not a pirate version. I should look at the raw data to try to understand them.

An old CD burner, HP 9100 or its manufacturer direct variant Sony CRX-140E have an ability that is rather uncommon among CD readers: they honor requests to read lead-in, and they honor requests to read data tracks in audio mode, including with P-W (Karaoke) subcode read mode. If you hack the firmware to bypass the lead-out limit check, it's one of the best CD analysis tools you can get without the professional equipment. I have this drive and can look to see what's going on with them.

No, the PS1's wobble groove does not show up if you read lead-in. The "trademark Sega" part of Saturn and Dreamcast disks' lead-out does, though. =)

 

The lead in is usually (and maybe always on official discs?) flagged as data - the actual information track doesn't have any TOC type at all, since don't have proper TOC entires (there is some CD-i metadata stored under Track/Point 0xa0). The actual sector data format is basically XA Mode 2 (IIRC, there are some extra flags in CD-i, but they can generally be ignored).

The first thing to check is if it plays in a PC - if it does, it's White Book, and it's basically an XA CD-ROM. The old Green Book VCDs don't have any usable file system on them at all - they are just data. There are also some "CD-i Ready" Audio CDs that are quite interesting; they tend to have CD-DA leadin and leadout and just have a hidden track 01 with the CD-i stuff on it. I suspect this format was a large part of the reason that CD-i was made as similar to CD-DA as possible.

If you can dump the ToC, then look for index 0xA0 and check the minute field - it's 0x00 for both CD-DA and Yellow book, 0x10 for CD-i and 0x20 for White book VCD. I think CD-ROM XA uses 0x30 and 0x40 depending on the mode of the first sector in the track.

I expect it would be pretty hard to pick up that wobble - I would guess it was chosen (like the pregroove wobble on a CD-R) specifically to be outside the range of the filtering in the tracking servo. IIRC, the Sega stuff is just written using EFM patterns, though.

 

Writers can read the ATIP, but no manufacturer would have bothered to add support for reading the PS1 protection. I'm not sure that modifying the drive firmware would be enough, but if it were then it would be a lot of effort to do it & I can't see any benefit.

 

It shows up as mostly the capital letter Y, with some other byte for the darker areas (letters). It's a lot like the "weak sectors" of SafeDisc 2. I suppose that that is the point, to induce weird patterns into the EFM. It would be fun to try and copy those with a CD burner, but I doubt that it's feasible.

 

Yeah, but that's a recorder - it's got specific support for reading wobble. Normal drives don't, and the frequency would seem to have been chosen specifically because it's outside the bandwidth required for the tracking servo (hence why the disc validation in the original PSX had to pick the signal off directly from the output of the E-F amp and process it with a bunch of opamps and comparators rather than using the servo DSP to detect it).

I would think it's very similar - writing a data pattern that becomes regular after it's fed through the scrambler. Getting the rotational alignment right (so that the "sega" text lines up when you look at the disc) would be fun, though.

 

More like just the EFM encoder, not scrambler - unlike SafeDisc 2, the Saturn and Dreamcast have the Y's in audio sectors. An interesting question is whether the drive actually cares whether the rotational alignment is correct. The rotational alignment may actually just happen automatically, or close to it, if you get the right size of CD-R. I doubt you can find 63-minute or whatever Saturn used CD-Rs around these days, though. For the Dreamcast, I have no idea what the size of a GD-ROM "would be" if the inner session simply continued out to the full 12 cm.

 

If i'm not wrong, but the scex string was in the part of atip used for cdr info?

 

AFAIK there is always a wobble, it's easier to track if you are constantly moving rather than moving occasionally. The drive knows where the track should be, data is encoded in such a way that a 1 or 0 is produced if the head is where it should be or not. The frequency has to be picked so that it will interfere. I don't think that whether it's handled in the DSP or not gives you any clues as to why it works the way it does. I don't believe that SCEI produced the drive controller, it's likely they used something off the shelf of one of their divisions.

It uses a similar process to ATIP, but AFAIK it's not ATIP.

 

ah, ok

 

It depends on if you are talking about the PS wobble or the one on CD-Rs - the one on a CDR is constant, not least because it's picked off and used as a speed reference. The one on the PS is gated, and that's where the SCEx data is encoded. I suspect the reason that they picked off the signal before it hit the DSP was precisely that it was a standard part used for a CD Player or CD-ROM drive and hence would have simply rejected the wobble because it was far outside the frequency range that would have been of any interest to the tracking servo. I have no idea how they do it in the later (PU-22, PU-23, PSone) versions - the whole detection process is in the CD controller chip and it's not possible to observe.

In fact, thinking about it (although this is going back a long time now...) I'm pretty sure that the main tracking and focus servo loops in the PS models up to (and possibly including) PU-20 were pretty much all analog - they just got more and more digital supervision as time went on. I will try and dig out my notes - back in the day, I did a fairly detailed analysis of how the SCEx detection in the PU-7 worked, and notes are a lot more reliable than memory.

I *think* that the basic circuit consisted of the E-F amp (in the RF chip) driving a pair of filters - one was a LPF that stripped out the wobble and then fed the signal back to the TE servo amp (also in the RF chip) and the second half of which was a BPF with a peak at the wobble freq - this then went into a detector, an integrator and finally a comparator (well, really a slicer, since the reference input on the comparator was just a heavily filtered version of the integrator output.

I do remember doing some tests with original PS CDs and various CD players - and found that the wobble data was ignored by all the ones I tried - hence the comment about the frequency being chosen to be outside the range of interest for a CD player.

 

I remember how I figured out how the PS1 protection worked with nothing but knowledge of modchips, a logic probe (not even a logic analyzer) and some documentation on the CD physical format. I had three copies of the same game - the American version of Rockman Dash, I believe. One was legitimate, one was a so-called "HK silver" (professional pirate version, and from China not Hong Kong), and one was a CD-R I burned from an image of the legitimate one.

I attached a logic probe - a simple device that lighted red when the attached wire had a "1" and lighted green when it had a "0". I connected it to the SCEx data line that a modchip uses, but with no modchip installed. I noticed quickly that the HK silver was always 0 whereas the legitimate disk was always 0 with the exception of short pulses during the protection check - the SCEx data. No surprise there. But when I put in a CD-R, the SCEx data line flashed both green and red the entire time the disk was inserted - it was alternating between 0 and 1 constantly, and not just during lead-in like with legitimate disks.

That CD-Rs differed from legitimate disks was no surprise. But what was interesting was that pressed non-PS1 (or pirate) disks differed from CD-Rs in a way that mattered to the protection system. In other words, there is some difference between pressed disks and CD-Rs, and that the location of this difference is where the SCEx data is stored.

It didn't take much reading about CD-Rs' physical format to find the likely suspect: the wobble groove. Some time later, I saw PS1 hackers online talking about the wobble groove, which is what confirmed that I was right.