PlayStation Development Network

All credit for these images goes to Trimesh.

http://imgur.com/a/45bk5/

Notes from Trimesh:

Wow. Didn't expect anybody to be able to take photos of that hardware! And I guess TriMesh will even do some more stuff with it than just taking pictures ; - )

The 44pin ROM chip is funny, even bigger than the 40pin ones. Analog output is unexpected. Sounds as if it could only output either one: Video or GPU? Hopefully without picture rolling when switching between the modes.
Does it have any OSD functions implemented, for showing the current video playback time, or play/pause symbols?

Just looked for datasheets... CXD1862AQ...? Hey, no, Typo! the chip is called CXD1852AQ (as seen on the photo), a datasheet exists at datasheetarchive.

And CXP10224... can't find any datasheet... could it be something resembling CXP1021Q, in smaller package, without the LCD & button pins?

If it isn't too much work: Pin-outs of the 30pin socket would be nice (to get an idea what signals it can output, and to know if it's controlled via serial or parallel bus).

Oh, and a photo of the mainboard front side with daughterboard removed would be nice, too. That's somehow missing in the photo-set.

nocash wrote:Oh, and a photo of the mainboard front side with daughterboard removed would be nice, too. That's somehow missing in the photo-set.

Added.

nocash wrote:The 44pin ROM chip is funny, even bigger than the 40pin ones.

The first 512k is mostly the same as the standard v2.2j, with just a few changes patched in to call code in the second 512k. Probably to avoid any compatibility issues.

IIRC I had to dump it using a boot cd and memory cards because the xplorer didn't work on it, I think the rom was visible but the bios didn't look for it.

nocash wrote:Sounds as if it could only output either one: Video or GPU?

The mpeg chip can "genlock" (sync to an external video source). I haven't investigated, but my guess would be it's chromkey'd onto the GPU output (blue or green where video is to be displayed).

Some findings on the SC430924 firmware...

The version/date is "15 Aug 1996, version C2h", although the "C2h" is misleading: The firmware is nearly identical to version "C1h" from PU-8 boards (the stuff added in normal "C2h" versions would be for PU-18 boards with different cdrom chipset).

Compared to the original C1h version, there are only a few changes: A initialization function for initializing port F on power-up. And new command (command 1Fh, inserted in the various command tables), with two subfunctions (01h and 02h):
- Command 1Fh,01h,a,b,c,d,e --> INT3(stat,a,b,c,d,e) Serial 5-byte read-write (via Port F.bit0,1,2)
- Command 1Fh,02h,v,x,x,x,x --> INT3(stat,0,0,x,x,x) Toggle 1bit (port F.bit3)
Whereas,
x = don't care/garbage
v = toggle state (00h=normal=PortF.3=LOW, 01h..FFh=special=PortF.3=HIGH) (toggle gpu vs mpeg maybe?)
a,b,c,d,e = five bytes sent serially, and five bytes response received serially (send/receive done simultaneously)

The Port F bits are:
Port F.Bit0 = Serial Data In
Port F.Bit1 = Serial Data Out
Port F.Bit2 = Serial Clock Out
Port F.Bit3 = Toggle (0=Normal, 1=Special)

And that's about all. Ie. essentially, the only change is that the new command controls Port F. There is no interaction with the remaining firmware (ie. reading, seeking, and everything is working as usually, without any video-cd related changes).
The SCEx stuff is also not affected (ie. Video CDs would be seen as unlicensed discs, so the PSX couldn't read anything from those discs, aside from Sub-Q position data, of course). The SCEx region is SCEI aka "Japan" (or actually for Asia in this case).

Oh, and there was one other thing I missed in my summary - there is another mux (4053) on the board located next to the audio DAC (it's visible in the photo of the boot ROM). From the look of it, it switches the DAC from the PSX SPX to the I2S output on the VCD decoder chip.

And I don't think it's chromakeyed - I can't see any sign of the PSX video being fed into the VCD board, so my guess is that once it switches over to VCD mode everything (including the OSD) is generated by the Video CD controller chip.

I'm just tracing the signals on the interboard connector and will post a list soon.

And it's interesting that SMF couldn't get the Xplorer to work either - I just tried multiple cheat carts and they either did nothing or crashed the machine. I was wondering if this unit had a bad expansion port, but I guess not.

TriMesh wrote:And I don't think it's chromakeyed - I can't see any sign of the PSX video being fed into the VCD board, so my guess is that once it switches over to VCD mode everything (including the OSD) is generated by the Video CD controller chip.

The PSX video wouldn't need to be fed to the VCD board for chromakey, if both are sync'd then chromakey is a switch controlled by one of the inputs and that could be done simply on the motherboard. The PSX video must go to the switch, so it could control the switch.

The vsync/hsync pins from the mpeg chip must be connected from the daughterboard to the motherboard and they can be configured as inputs to sync to an external signal, or outputs if the mpeg chip is generating it's own sync. In the later case the vsync/hsync would also need to be switched externally, that is probably the easiest clue you could get from the hardware. It should be possible to figure out from the configuration sent to the mpeg chip whether they are inputs or outputs, but you'll probably need the register manual as I don't think it's in the datasheet.

The parallel port might have been "broken" on purpose to stop people in asia from using springs & cheat cartridges to play pirate games.

smf wrote:

TriMesh wrote:And I don't think it's chromakeyed - I can't see any sign of the PSX video being fed into the VCD board, so my guess is that once it switches over to VCD mode everything (including the OSD) is generated by the Video CD controller chip.

The PSX video wouldn't need to be fed to the VCD board for chromakey, if both are sync'd then chromakey is a switch controlled by one of the inputs and that could be done simply on the motherboard. The PSX video must go to the switch, so it could control the switch.

Something would need to decode the colors, since otherwise you really aren't using chromakey, you seem to be talking about just using a single component as the key channel. I'm not quite sure what you would call that - bogokey, maybe?

Anyway, it doesn't do that - the control signal for the muxes isn't derived from the video at all - it comes from pin 1 on the CD mechacon, and (presumably) is switched over by the 0x1f subcommand 2 that nocash found in the mechacon dump.

smf wrote:The vsync/hsync pins from the mpeg chip must be connected from the daughterboard to the motherboard and they can be configured as inputs to sync to an external signal, or outputs if the mpeg chip is generating it's own sync. In the later case the vsync/hsync would also need to be switched externally, that is probably the easiest clue you could get from the hardware. It should be possible to figure out from the configuration sent to the mpeg chip whether they are inputs or outputs, but you'll probably need the register manual as I don't think it's in the datasheet.

Yeah, I got the purpose of one of the muxes wrong - it's actually switching over Hsync, Vsync and Fsc from the PSX GPU to the outputs of the VCD decoder chip - the other one (the JRC part) is handling the video. The composite and Y/C are being generated downstream.

That also means that my theory about the 6230 is wrong too - it clearly isn't a video encoder. I'll try and figure out what it actually is later.

Based on poking around with a scope, the VCD board seems pretty much self-contained. The only inputs I can see are a standard looking I2S transport stream coming from the CD DSP (CXD2510Q) (BCLK, LRCLK, DATA and C2FLG), another clock coming from the SPU (16.9344Mhz, 384fs) a 3-wire interface coming from the mechacon (CLK, DATA and LOAD) and two power rails.

The outputs are another I2S stream (for the DAC), and RGB, sync and Fsc for the video encoder.

smf wrote:The parallel port might have been "broken" on purpose to stop people in asia from using springs & cheat cartridges to play pirate games.

Yeah, possibly - but it seems strange, since this model most mostly sold in Hong Kong, and by the time they released it the market was flooded with mod chips, which made the cheat carts somewhat irrelevant.

TriMesh wrote:Something would need to decode the colors

It would just need to be fed the r/g/b and output a signal based on whether (for example) there is blue and no red and no green. It's cheap to do, but not as cheap as the actual design. It was only a guess

TriMesh wrote:That also means that my theory about the 6230 is wrong too - it clearly isn't a video encoder. I'll try and figure out what it actually is later.

What is the Philips chip? I'd have guess that was video related. I'd laugh if it's an osd generator that outputs composite and the 6230 decodes that to rgb. One of the chips might be an amp or voltage convertor, which should be pretty simple to figure out if you stick a scope on it.

TriMesh wrote: Yeah, possibly - but it seems strange, since this model most mostly sold in Hong Kong, and by the time they released it the market was flooded with mod chips, which made the cheat carts somewhat irrelevant.

Again it was a guess, it's possible that something changed by accident that the cheat cartridges relied on and none of the cartridges that either of us tested were made to work around the issue. With no official products to test then it could just not work, although I do wonder if they used the parallel I/o port for factory testing. I'm surprised it stayed for so long.

O/T do you have a list of motherboards, list of cpu/gpu/spu/cd/bios etc that were used on each and what model numbers they were sold as? IIRC you mentioned either that you were compiling that or thinking about it a while back.

What 6230 are you talking about? You didn't mention any such thing yet.
EDIT: Ah, the "6230FV 649 115" chip (that you referred to as BA7230LS Video encoder in the 1st post)

Yes, per-pixel video source switching won't work. Certainly not if it's switched by the HC05 PortF.3 output. And even if it would use some switching method: It would screw up the NTSC color clock of the composite signal (the daughterboard is probably generating the color clock from the 28.636MHz oscillator).

But, the other way around, the chromakey theory doesn't sound impossible: The mpeg chip does have some sort of 4bit RGBA (1:1:1:1) input, and that could be in fact fed by the GPU. For example, using the MSBs of the PSX's digital R,G,B outputs as RGB bits, and some other bit from the PSX's R,G,B signals as A bit (ie. as alpha, aka transparency, aka OSD on/off flag).

But that kind of theories depend on what signals you will find on the 30pin socket. Would be great if you could release the pin-outs soon! Even if they are still incomplete, they are probably already good enough to scrap some theories (like whether there is a 16bit databus on the connector).

nocash wrote:Yes, per-pixel video source switching won't work. Certainly not if it's switched by the HC05 PortF.3 output. And even if it would use some switching method: It would screw up the NTSC color clock of the composite signal (the daughterboard is probably generating the color clock from the 28.636MHz oscillator).

If the composite signal is generated on the motherboard it wouldn't be a problem.

But when mixing video from two video chips you have to run them from the same clock because otherwise it won't be stable. The mpeg chip can run from an external clock which would easily allow the video to be mixed (like on the Amiga), but it does appear Sony decided not to use it in that way. I guess they didn't feel that it was worth doing anything better as games were already able to use FMV using MDEC.

smf wrote:What is the Philips chip? I'd have guess that was video related. I'd laugh if it's an osd generator that outputs composite and the 6230 decodes that to rgb. One of the chips might be an amp or voltage convertor, which should be pretty simple to figure out if you stick a scope on it.

The Philips chip is the video DAC - I actually suspect that the 6230 might be an OSD generator, since it's being driven with what looks like a serial bus from the CPU and outputs to the MPEG chip (which has a dedicated input for OSD). Hopefully I can find some time to look at it this week, or failing that at the weekend.

nocash wrote:But that kind of theories depend on what signals you will find on the 30pin socket. Would be great if you could release the pin-outs soon! Even if they are still incomplete, they are probably already good enough to scrap some theories (like whether there is a 16bit databus on the connector).

Well, I can tell you there isn't anything like that - it's all serial. Right now, I have a good handle on what the various groups of signals do, but I want to verify them.

10 pins are used for ground and power
6 connect to the video output (R,G,B, H and V sync and Fsc) (muxed)
4 connect to the DAC (LRCLK, BCLK, DATA) (muxed) + MCLK (constant)
3 connect to the mechacon (seem to be DATA / CLOCK / LOAD)
4 connect to the CD DSP (LRCLK, BCLK, DATA, MCLK)

Yes, that's only 27 pins - there are a few others I haven't figured out yet

Where's the incoming CD data transferred from? Are the CD DSP signals, with the LRCLK,BCLK,DATA,MCLK signals following the notation for Audio Discs (but having different meaning for video discs)?

The three Port F serial bits are definitely Clock, DataIn, DataOut. There should be also fourth signal for XHCS (to invoke a serial command, see page 18 in the CXD1852 datasheet), this should be absolutely required, but I can't see it being generated in the firmware. Maybe they have misused some other already existing signal for it (like some signal that gets pulsed when the MIPS communicates with the HC05, and that stays LOW when the HC05 communicates with the daughterboard).

The Vsync exists only in daughterboard to mainboard direction? Then I would expect the picture to roll when switching between GPU and MPEG. I've never seen the SCPH-5903 in action, could somebody give a short overview how it looks like? Does it switch smoothly between GPU and MDEC, without rolling and blackscreen delays? And it does have some OSD function, or doesn't it?

For the MIPS BIOS (and Expansion ROM support): There are Pre-Boot, Post-Boot Functions, and Mid-Boot Hooks, see http://problemkaputt.de/psx-spx.htm#exp ... nromheader
The Pre-Boot should work as usually. The Post-Boot may work, too, but's kinda useless. The important part would be working Mid-Boot hook, that part isn't an official kernel feature, so it works only via some hacks, like using COP0 breakpoints - which might be incompatible if the cheat device places breakpoints at addresses that are incompatible with the SCPH-5903.
Moment, I have some more notes on it here http://problemkaputt.de/psx-spx.htm#cop0debugregisters - the variant with BPC=80030000h should work with SCPH-5903, too. The one with BPC=BFC06xxxh might fail (as far as I remember, the cheat bios searched for known opcodes at BFC06xxxh, and when finding those opcodes, placed the breakpoint at that address, which might fail since the SCPH-5903 has changed some opcodes in that area).

Btw. the changed bytes in first 512Kbytes of SCPH-5903 compared to SCPH-5000 are:
BFC00000h --> changes the ROM size from 512K to 1024K
BFC06FFC..BFC07009h --> changes the source address and length of the GUI code ROM-to-RAM relocation

The funny thing is that the 1Mbyte ROM does contain the complete original GUI from SCPH-5000, but it doesn't use it, and uses a different GUI, stored in upper 512K instead. An odd side-effect is that the version string at BFC7FF32h is same as for japanese SCPH-5000, whilst other asian consoles should normally have the 'american' BIOS version.

Oh, and I am adding dynamic BIOS ROM allocation in no$psx, for support ROMs bigger than 512K. It doesn't work stable yet, but what I can see is that the SCPH-5903 outputs some stuff in the TTY window: It doesn't output that special cdrom command (1Fh,sub,a,b,c,d,e) anywhere, probably because it didn't find any VCD disc.
Between the "Check VideoCD" and "Not found" strings, it's issuing a number of cdrom commands, name GetID, used to detect the disc type.

Question would be, what values does one get returned for GetID command when inserting VCDs into the disc drive? Can somebody test that? You won't need a SCPH-5903 console for that test, you could use any PSX model you have, and you would only need VCD disc.

nocash wrote: Question would be, what values does one get returned for GetID command when inserting VCDs into the disc drive? Can somebody test that? You won't need a SCPH-5903 console for that test, you could use any PSX model you have, and you would only need VCD disc.

I don't know if I have any pressed VCD discs, but IIRC it can play them from cdr. If you want anything run on a 5903 then put together a bootable iso and I'll dig out the console and boot cd.

smf wrote:

nocash wrote:If you want anything run on a 5903 then put together a bootable iso and I'll dig out the console and boot cd.

At the moment, I wouldn't know of any software tests that would be interesting to run on a real 5903. But it would be nice if you could test it with a normal VCD, for confiming if it does accepts CDRs, and if it does have an OSD layer.

Having a VCD disc-image would be also nice for testing in emulators; just some short trailer/video should be enough (ideally a disc image that was confirmed to work as CDR on real 5903 hardware).

For emulating it, I'll probably add some limited support in no$psx: Something that emulates the sub-channel (so that the bios would be able to detect VCD images). But probably without actually emulating the MPEG decoding (instead showing only some dummy image with snow).

Actually, I don't know anything about MPEG decompression. I would assume that it's more complicated than Playstation's MDEC format - but I might wrong there. Does anybody have some (compact) info on how to decompress VCDs?

nocash wrote:

smf wrote:

nocash wrote:Actually, I don't know anything about MPEG decompression. I would assume that it's more complicated than Playstation's MDEC format - but I might wrong there. Does anybody have some (compact) info on how to decompress VCDs?

IIRC MDEC is effectively MJPEG, which is MPEG only using I-frames.

http://en.wikipedia.org/wiki/MPEG-1 lists all the frame types.

I did wonder whether it was possible to do MPEG video using MDEC and handle the other frames using the CPU/GPU, but you'd still have to decode the audio and I'm not sure there is enough CPU to decode MP2 on the PS1. Plus you'd need to be able to read the CD, although you might be able to do that by playing the CD as an audio track and then reading the data from SPU. Ultimately VCD is pretty horrible quality anyway though, so figuring out how to play them has never been something I've been that interested in. However playing VCD and DVD is something that I need to do for a different project.

I'll see what I can do for a test image.

Cool, a test image would be great!

MDEC and JPEG are similar concerning the macroblocks (with same DC,AC values and zigzag ordering, etc). The difference is that MDEC uses RLE compression, and JPEG uses huffman compression. One could probably use the PSX hardware to decode the macroblocks by hardware (combined with doing the JPEG/huffman compression by software, and converting them to "un-compressed" RLE format).

Good that you mention the I-frames. If they are essentially same as JPEGs, then it should be easy to support I-frames in emulators.
Of course, sticking with I-frames wouldn't look too good if they appear only every some seconds, but it would be still better than showing a dummy picture with snow/noise.

I have two VCD's. Let me know if you want me to rip them...

Shadow wrote:I have two VCD's. Let me know if you want me to rip them...

Sure, it would save me some time.

Any particular ripping software you would like me to use?