PS1 PU-22 Modchip Install (Causes disc drive to stop working)

Hello all,

I've been trying to install a socket on two different PU-22 boards in order to test some modchips. Which chips I'm using is irrelevant as I'm not currently using the socket (it should theoretically be out of circuit).

Using the MayumiV4 wiring diagram for PU-22 boards (link here), if I solder to points 2 and 7, the optical drive becomes inoperable. It will spin the disc for a short while (about 8s), but the head will not track horizontally, and then it will spin down. The laser is getting power and it will return to the neutral position if I manually move the head before turning the console on.

I have not tested points 2 and 7 individually, I have only narrowed the problem down to them. Once again, all of these points are currently connected to a socket for the modchip which is not inserted during any of these tests. It should not affect the console, but evidently it does.

There are no shorts, no instances of faulty wiring, no improper solder connections, and no other physical anomalies with the install. I have reproduced this symptom on two different boards, three separate times on the latter. I have not floated any pads as the boards work as expected if I remove the socket. The former of the two boards is virgin; I am the first to install a chip on it. The latter of the two boards I removed an unknown chip from. They both function flawlessly without modification.

A good place to start is identifying what points 2 and 7 correspond to. Some of the other points I was able to test and confirm, or to infer the use of, but I am unsure of the purpose of these two points in the scheme of things.

My hope is that someone much more experienced has already confronted this problem and either not documented it, or has documented it somewhere I was unable to find and could point me in the right direction.

 

Here you go. This is the first board. Second one is identical except the socket is moved left about 10mm.
Note that the ground connection (pin 8) is under the socket. It is electrically and mechanically sound, and the drive only stops working when I have 2 and 7 soldered to the socket. There is no short between them.

 

Pin 2 is the mechacon clock line - it carries a constant 4.2336MHz clock signal to drive the microcontroller. Pin 7 is the door switch line - so it should have a constant DC level under normal operation.

The first thing I would try is moving the socket - the place you have put it has some very low-level signals from the CD pickup, and it's quite possible that the signals on the wires are coupling enough noise into the RF amplifier (which is that chip to the left of your socket with the wires running over it) to corrupt the signal coming from the disc.

 

That's a good suggestion. The symptoms I'm seeing seem to correlate with the door switch being released. It always happens with the same timing.

I'll try rigging up shielding to see if I can avoid moving the socket, and if that doesn't work I'll rig up another board with the socket elsewhere.

 

The shielding I rigged up allows the console to run properly without the chip installed (although it seems to read more slowly), but now when the chip is installed I get the "Please Insert a PlayStation CD-ROM" message.

I'm sure there's still a bit of crosstalk (the slow reading seems to point to this), so I'm going to repeat the shielding experiment on the other board in order to rule out some other variables.

Here's a shot of the shielding. It's a scrap of aluminum foil which I isolated parts of (the bottom and near the socket) with scotch tape. There's no isolation near the screw, so when the RF shield is screwed down it will ground the entire sheet.

 

Likewise, many of my consoles have no shielding. These two are special cases because as TriMesh said I'm placing a socket/wiring directly on top of an amplifier. I've deduced it was causing upsets on the door switch line and the shielding has mitigated that issue.

All of my wiring is 30AWG, and according to this table I have 142mA to work with before things start going wrong. This chip should be drawing current on the order of ~1.2mA based on the current configuration (at this voltage and clock speed) and it isn't capable of drawing more than ~90mA in any configuration so there's nothing to worry about.

I'm going to probe supply voltage and the door switch line to see if that presents any more clues.

 

I've wired PS1 modchips many times using only 30AWG and had no issues with it.

Are you still having the issues as in your original post after the changes you've done?

 

No, it will now run without a chip in the socket, but when the chip is inserted it will not recognize retail discs or backups ("Please insert a PlayStation...").

The code happens to be your port of Mayumi 4.0 for the 12F683, although that's not the problem I'm sure.

 

I would like to think that it's not the problem but I have not tested that port specifically on a 7500 model PS1 so I can't be 100%. If I had one I'd test it. Are you certain you also programmed it correctly? I've had chips that appeared to be programmed correctly but then don't end up working in the past for whatever reason and then have to redo it.

Just curious, what are you using to program them?

 

I'm using the Microchip IDE and also the PicKit3 standalone programmer. Both seemed to work just fine and were able to verify the code.

When I finish rigging up the second board I'll burn another chip to test with.

 

I installed a better shielding and now retail discs will boot, but backups will not.

Going to burn another chip now to verify that I didn't damage the current one with ESD or somesuch (though it is rather hardy, as I read in the datasheet).

------------------------------------------------------------------------------------------------------------------------

Edit: Burned a second chip which worked on and off. I noticed my chips were pretty oxidized so I cleaned them up, which helped. After a few more tests one console completely stopped trying to read. It will spin the disc about 1/4 turn twice, then completely stop.

After probing the door open line, I found it reads high (3.5V) when the door is "open" and low when it is closed. Should I be seeing 5V on that line instead? 3.5V seems suspicious, and was on two of the other signals as well. The remainder of the signals were clearly 1.8V logic, except for ground of course.

Still no shorts on my wiring. Checked that again too.

I think I'm going to sleep on this, there's a lot to consider and I don't want to do anything rash.

Let me know if you have any ideas.

 

All the signals should be 3.3V - both the mechacon CPU and the CD control/DSP chip are running in a 3.3V power domain.

For reference, here is what all the signals do:

1 - VCC - Connect to any 3.3V supply
2 - CLK - Clock signal for MCU (4.2336 MHz from CD DSP)
3 - XLAT/ - Normally high, pulses low at the end of each command sent to the CD DSP
4 - RESET/ - Normally high, goes low when reset is asserted
5 - WFCK - Subcode write-frame clock. Synchronized with the subcode frames on the disc, used to chop the data signal up
6 - DATA - Transmitted modchip data - basically NRZ anded with the WFCK signal
7 - DOOR/ - Normally high, pulls low when the CD door is closed
8 - GND

The way the data line is handled is a bit nasty, but seems to be fairly reliable in practice - it's injected into the external passives used as part of the tracking error amplifier / filter. Obviously, this overrides the actual tracking error signal, which is why it's chopped up using WFCK so that 50% of the time the tracking error still gets through. This may sound like a problem, but it only produces a 3db decrease in servo gain, and the tracking servo has lots of margin.

The XLAT/ line is used to turn the modchip data stream off - basically, it has a timer that waits until the console should be reading the leadin then sends SCEx strings until XLAT/ is asserted - this works because at this point the mechacon isn't talking to the CD DSP because all the information it needs to build the ToC for the disc is coming over the SUBQ interface.

 

Having taken the socket out of the equation, it now boots retail discs reliably, but not backups.

When a backup is loaded, it appears to attempt to read it. The head tracks rapidly (significantly moreso than it would normally) for about 4 seconds, then it stops suddenly and returns to the BIOS/Main Menu. It doesn't seem like the DOOR signal is an issue anymore.

I'll do the same install on another board to make sure it wasn't a random error caused by my work. I'll also try shielding the top of the chip, and the surrounding wires, although I'm unsure that would provide significantly more protection.

Here it is:

 

Electrical tape will not shield and help with cross talk. This is an electronics issue, not just "use some insulating tape".

 

Okay, now that I've been able to recreate this problem 4 times, I can conclude that it seems to work only the first time a chip is installed. This same behaviour occured while using the sockets, and also while soldering the chip directly. Makes me think the socket has little or no influence on this circuit. Impedance in the socket is not an issue either. The contacts are clean and I found negligible difference in resistance between the two configurations.

The second time I booted the console to test a different retail disc (which was known working) it threw the "Please Insert a PlayStation CD ROM" screen and now does this consistently.

 

My guess is that you have a combination of induced noise from the wiring and a weak optical pickup that is producing a low signal. I would start by removing all the wiring and testing to see if the chip will boot retail discs reliably in it's stock configuration. If it doesn't then clearly you have an actual faulty console and should fix that first.

If it will boot originals, then try booting a CD-R using the swap trick or a game enhancer type cart - if you can't get them to work, then you have an optical pickup that's just sensitive enough to work with pressed discs, but not from the slightly weaker signal from a CD-R.

If you can boot CD-Rs this way, then you know it's 100% a modchip problem. All I can suggest is that you try relocating the chip to get it away from the low-level optical pickup signals. You might also consider using the MM3 code instead of Mayumi, since that uses the internal oscillator, and doesn't require you to run a wire with a ~4MHz signal on it across the board (although the raw data rate on a 2x CD-ROM is only about 2.8Mbit/s, the EFM conversion and the merging bits mean that you need about 5.5MHz of RF bandwidth in the amplifier, so that clock is inside the passband).

If you have a scope, then try looking at the eye pattern out of the RF amp - I can't remember the testpoint number, but it's connected to pin 13 on the RF amp chip. You should get about 1.1V p-p (although anything over 900mV is normally OK) - if it's much lower than this, then you have a bad pickup. If the signal looks good, also check for how clean the zero crossings are - if there is a lot of jitter, this is a sign of a bad motor - it might not stop the unit from working, but it makes it harder for it to read marginal media.

 

Testing with a burned audio CD would also verify whether it can read burned discs or not.