Official PSIO Development Thread

Stone Age Gamer (for US/Canada) will be selling the PSIO at some time in the fall/winter this year.

To my knowledge, there's no competing project at the moment. If there were, it would have to either utilize the parallel port like this one, or would replace the CD drive entirely.

 

You would think with something that was as popular as the Playstation more people would be working on things
Its almost every other event where one has a lazer that just dies

Damn, I did have one ordered out of the first batch he sent, till the order got screwed up

Then I forgot about it
Not really a big fan of external devices like this as at some events you always get one smeg that will just yank it out to have a look

 

That's good to hear that SAG will sell them soon. I'd like to have one to check out. It would be handy for making some PS1 homebrew without having to burn discs or use emulation. Ofcourse the cdrom functions would be emulated but I don't think that would hide bugs in new software like emulation of the rest of the system might.

I do like the idea of an actual drop-in replacement for the optical assembly. Maybe someday that will be a reality.

 

Did all PS1 drives use the same connector though? I know the system had tons of motherboard revisions.

 

Same connector except the 1001 which is ZIF. They are all backwards compatible (at least 101 works in 1001 as that's all I've tried in there for testing), but with different connector placements so the ribbon/power cable lengths differ to where you can't physically use them in every other model.

 

Yeah, but getting the PS2 and PS3 to play PSX rips on HDD is so much easier, and with almost the exact same controller, with the PS2 you can also use the PSX controller if you prefer that. This solution is pretty much only for hardcore enthusiasts.

 

PS1 compatibility via POPStarter can be spotty as it's emulation. You can't even play Xenogears IIRC.

 

You are looking at the flat cable to the optical assembly, which does no processing. How would that work?
That is not like the CD/DVD drives of the PC, which are connected to ATA busses, which can communicate with other devices like HDDs.

The PIO port offers access to the data bus, so it becomes possible to manipulate how the console worked. It would have been totally mod-free, but it needed some additional help to allow for emulation of the CD-ROM part.

But if you replace any part with something else - you will be doing emulation. The difference is how much is emulated and how it is done. PSIO also does emulation; it's emulating the CD-ROM controller.

POPS was made for only 1 game, so it's already very amazing that it was made to work with a lot of others. Even the PS2's emulation doesn't have 100% compatibility. From the very start, Sony probably already planned to accept that some PS games would not be supported, due to some things that were done.

 

You're absolutely right and it's amazing that it works so well. I'm just saying that overall it isn't perfect and there are games that POPStarter cannot play well in response to Arcadia.

 

It's doable - I did a bit of work on this a while back and got far enough to convince myself that it would work, but also that it was going to take a lot more effort than I cared to expend.

Basically, you have to generate raw EFM data representing the whole CD including the pre and post gaps and the tracks then monitor the drive to the spindle motor to control the rate it's generated at and the sled motor to detect seeks. You also need to fake up the focus, tracking and track 0 signals - but they don't really need to work, just be good enough to keep the mechacon firmware happy.

The biggest problem is seeks - you need to integrate the drive on the sled motor and use that to adjust the simulated playback position - which also means that you need to invert the geometry assumptions that the controller firmware is making about the discs.

 

My train of thoughts as well.
I wrote it off as too big of a project.
I don't even know what MCU would be able to do this. It's going to have to be super quick, like a DSP?
Then there's the whole dealing with iso files thing.

My other thought was that maybe there's a data bus after the decoder, but still 'raw' enough so that the system itself routes the data to the XA-ADPCM decoder if needed.
(That is what I remember of the low level issue: Data can be either code or XA-ADPCM, in which case the decoder needs to process it.)

 

So in theory could I just wire up the PSIO on the inside using some kind of extension cable?

Or a ton of pin sodering

 

TriMesh already addressed this but there's no reason that you couldn't replace the optical assembly with something that provides the same electrical signals. It's just a matter of getting it done and what it would cost to make such a device. Clearly it isn't easy because if it were then someone would have already done it. But that doesn't rule out it happening in the future.

With that said, I still think the PS-IO is a cool solution to the problem of having to burn CD-Rs. I'd rather have that than nothing for sure.

 

I used a STM32 400 series part and a small FPGA - the FPGA was just handling the sync word insertion and the EFM conversion. It was actually a poor choice of architecture, since it put all the load of generating the RS codes onto the CPU, and that's something that's handled much more naturally in a parallel architecture device like an FPGA. If I ever go back to the project, I will put pretty much the entire CD frame handling into the FPGA. Getting the data in there is trivial with modern processors - a single SPI channel is more than fast enough even for 10x speed, let alone the 2x that the PSX runs at. One moderately nasty issue is that the controller expects to be able to adjust the speed of the disc - which in practice means that the hardware that's generating the datastream has to run in it's own clock domain. I didn't take this into account in the initial version, so I ended up having to hack a lot of synchronizers into the logic. I was also generating the clock from one of the MCU timers fed into one of the FPGA PLLs in simple multiplier mode, which degraded the available resolution.

There is - it's the Sony variant of I2S that puts the LRCLK transition in the first bit cell of the current word rather than the last bit cell of the previous one, and also uses a somewhat non-standard LRCLK:BCLK ratio of 1:48. The biggest issue with using this bus is that it effectively went away on the PU-20 and all the subsequent models (OK, it's still there, but it's buried inside a chip and you can't get to it), so if you use this you are restricted to using machines running a PU-18 board or earlier.

 

It definitely is. I'll buy one as well, once I can

@TriMesh
So you already had the EFM working? I believe that's the biggest problem in the system, so nice work!

That sounds sensible, especially if you consider an interesting design aspect of this project:
It should be possible to adapt it to various CD based consoles, and offer the best compatibility of any ODR solution.
To each system, it's as if a real CD was inserted. One that has no scratches and reads perfectly fine.
The drive controller will have no error correction to do, the mechanics will be idle, reducing power consumption and electrical noise.
Data access will be much faster, due to the elimination of (real) seek delays.

One more benefit:
The install will be relatively simple. There's not many connections to solder

On which pins is this bus, if I may ask? I'm just looking for a head start here

 

Since the machine used several different CD DSPs over the years, the most consistent pinout is on the CD decoder chip - this mostly a CXD1815, but they used a CXD1199 on some of the early models - as far as I can see, the pinout is identical.

The signals you want are on pins 84-88 of the CXD1815:

84 - LRCLK
85 - DATA
86 - BCLK
87 - C2PO
88 - EMPH

If you are simulating the datastream, you can just tie C2PO low - it's used for indicating C2 parity errors and we can just pretend our CD is perfect, and leave EMPH low (it's audio emphasis and only counts for audio tracks).

You also have to make a fundamental design decision at this point - which is if you are going to retain the existing mechacon CPU and fake up the signals it needs or lose it and roll your own design that talks to the sub CPU interface ports on the CXD1815.

My feeling is that it's better to use the existing mechacon - in which case you will need to fake up the signals it needs.

You are going to need at least these (I've probably forgotten some...) - all the pin numbers are for the 52 pin mechacon chips

CD DSP control bus
43 - DATA
44 - LATCH
45 - CLK

Subcode
24 - SUBQ in
26 - SQCK out

System management
23 - SENSE (you will have to decode the CD DSP commands to figure out what this should be)
18 - TRK0
18 - DOOR

Obviously, you will need to provide the standard modchip signal, too.


Edit. That was supposed to be C2PO, obviously.

 

Wow, thanks for going the extra mile and look up the relevant Mechacon pins as well!

I didn't realize that the essential bus is just 2 clocks + data!

Maybe there is a state in which Mechacon and CD DSP are happy, while I inject data according to what the PSX software requested (in 0x1F801800 to 0x1F801803).
I may have to capture the Interrupt line as well.

Thinking about it, at some point full capture and injection of the Mechacon, CD FIFO and CD DSP would be required.
That'll be a ton of work.

 

My feeling is that the relatively easiest point of attack would be to replace the CD DSP only - I would also tend to start from the PU-18, since it's relatively simpler and doesn't use a dedicated servo chip (all the servos are in the DSP) - in this case, the implementation comes down to monitoring the commands sent to the CD DSP (CXD2545Q in the case of the PU-18), and making sure you do the right thing. Most of the commands can simply be ignored - like all the stuff for setting servo gains is obviously pointless if you have no physical servos in use.

You need to check for track skip commands and slew commands and move the simulated readpoint around the image file, detect attempts to slew the drive past the start of track 0 and assert the TRK0 switch and make sure the correct signal is being sent out on the SENSE pin, but in most cases just acting like the command (whatever it was) worked OK should do the trick.

After that, it comes down to generating the transport stream and the subcode.

 

Yes, that approach seems best

Have you ever scoped the various clock lines?
Do they change, and if they do, where might it matter?

Dealing with subchannels, there's the issue that many image files don't come with the original data.
I believe a CD burner (or the burner application) recreate the subchannels, so hopefully this isn't too hard.

So I guess the best start would be a CD DSP command set clone.
The clone should talk a little with a real system, even if the DSP was disabled / no drive present

I wonder if such a project fits on a regular microcontroller. I have no experience with CPLD or FPGA, and this would be overwhelming as a first project.

 

There are two different considerations with subcode - neither is especially complicated, but they require separate handling. In most of the disc, the subcode is just a timecode and an indication of track/index changes. In the leadin, it carries the TOC for the whole disc, and this will have to be implemented correctly or none of the track related commands in the mechacon will do the right thing.

Normally BCLK and LRCLK run constantly and are driven by the CD DSP - you could probably get away with just cutting the DATA line and running the MCU in slave transmitter mode using the timing generated by the CD DSP - this would also get around the issue that most MCUs of European or US origin seem not to support the 48Fs BCLK that the PSX uses and tend to use 32 or 64Fs instead.

It's also possible the CD interface chip will accept different frame formats, but I haven't tried this - this is something you could test in isolation, though - just feed the transport stream into the CD interface chip and play an audio CD on the drive - if you get correct audio out, then the format is obviously acceptable to the chip.

The other two serial buses seem to be clocked out under frimware control and don't have constant clocks.