PS2 SCPH-30004 R not booting with HDD, RGB issues.

Hi!

I just got a PS2 SCPH-30004 R and it's not booting when I insert a HDD. I have the official Sony IDE network adapter and it's working fine in my PS2 SCPH-50004 with the same HDD. It starts up fine with no HDD and is working, but when HDD is inserted it boots the Sony screen and then turns black as it should but then it stays black. The HDD is spinning and the HDD led blinks once fast but nothing more.

I have checked all the fuses on the motherboard and they are all fine. I have also cleaned all the connections with isopropyl alcohol and inspected them for dust or damage.

Most of the times when I start it up with no HDD the picture is blurry and not centered on the monitor. After some resets the picture is fine again. I'm using a RGB-scart cable and it's working perfectly on my SCPH-50004 and PS One.

Does anyone have any tips on what to check next?

Thanks!

 

Does it have a modchip installed?

 

No it's all original.

 

Have you tried simply connecting the HDD to a PC and making sure the PC can see it first? Remember it won't show up under My Computer or anything because of incompatible file systems, but it should show up in the BIOS.

 

The HDD shows up in WinHIIP and it works in my other PS2 (SCPH-50004). I can boot from it and play my backups from it.

Maybe I should try to find another HDD just in case the SCPH-30004 R is incompatible with this one.

 

Don't you find it odd that the HDD unit can somehow affect the video output?
I know that there are HDDs that aren't compatible with the PlayStation 2, but I have never heard of such a thing happening before. How is it even supposed to happen?

Does the PSU look normal? Maybe it has developed some fault that is preventing it from producing sufficient current.

 

I got another HDD yesterday. A Seagate just like the old one, but a 300GB one instead of 40GB. And it works! The video is still messed up after cold start, but after some resets it´s fine again.

The PSU is visually fine but I have not measured anything. I guess it could be a cap that needs some extra time to "warm up"?

Thanks!

 

The IOP reaches the video output DAC through a I2C serial communication channel. That I2C interface interface is part of the DEV9 hardware. (It's inside the CXD9611 IC)

If DEV9 is faulty in a way that prevents the IOP from communicating with it, will be impossible to change the video settings. Also that's why COH boards have their AVE (Analog Video Encoder) chip configured with resistor jumpers as it does not have a DVE (digital video encoder) chip nor a DEV9 chip.

 

So his mainboard has some fault around the CXD9611R?
But shouldn't result in some other more predictable graphical glitch instead? I'm curious to know how it could cause blurness.

 

I saw he complain that component video (both RGB and YCbPr qualify as component video signals) were not working properly. And AVE/DVE being not properly set up can cause that issue. Those are configured at boot time by the IOP. Was just "connecting dots" based on what he said. Of course I could be wrong and the issue being elsewhere. But I've seen units with such faults and turned out to be problems with the DEV9. In my case the RGB/YCbPr selection were having no effect.

 

Okay, thanks.

Although I have to say that such configuration should be done by the EE (EE kernel writes to the interface at 0xBA000000), although it will go over the IOP via SBUS (due to the peripheral being connected to the IOP). Unless you have seen something else?

 

I believe both the IOP and EE can access it. Well, Matrix Infinity (I dunno why it does it that way) exploits a obscure CDVDMAN call to install a "forwarder" which in turn allow EE to send commands to the I2C port on the SBUS chip directly through RPC.

Edit: I forgot to mention why it does that... It's for the mechanism which disables macrovision when running the DVD player (It does patch even when games are playing and games using the exploited function on CDVDMAN actually break lol).

 

I thought that kHn marked out the part of the EE kernel that was patched out, to disable the Macrovision protection? It was one of the calls to SyncHParam or something.
So in the end, he deemed that the CDVDMAN function that was modified, was necessary to complete the Macrovision-disabling patch?

@wisi has determined (based on the available SCE documents) that the EE and IOP have different buses. The subsystem that the EE is connected to is the SBUS (EE <-> SBUS <-> IOP), while the IOP is connected to the SSBUS (which most peripherals are connected to). Both have different read/write enable lines.
The CXD9566R/CXD9611x/CXD9686x is more of a SSBUS I/F chip rather than the SSBUS controller (which is probably a mistake on some of the service manuals) because the SSBUS controller is the IOP.

 

I believe his patch only bypassed obligatory YCbPr setup.