PS1:Modchips

The modchips on a PS1 are various different devices that defeat the licensed media detection that the console has. Note that strictly speaking this isn't "copy protection" - it doesn't care what the data on the disc is, it just tries to ascertain if the media itself has a fingerprint that identifies it as a licensed disc. This is why swap tricks work - as long as the correctly licensed media is present during the test it can be swapped out for a copy later and the console will boot the media (later boot ROMs added another media test to the process, which is why later consoles need a double swap.

The media validation information is stored in the disc-lead in - this is the same part of the disc that holds the disc table of contents - but the validation information is not actually in the ToC, it's just stored as a radial wobble in the same area of the disc that the ToC is in. If you examine regular CD under a powerful microscope you will see that the pattern of pits on the disc (which appear as bumps from the readout side) form a spiral - on a PS1 disc, the same spiral is present, but the lead-in section of the disc (nearest the hub) has an intermittent radial offset position wobble - it's too high frequency to seriously affect the tracking and the mean position of the spiral doesn't change, so it the tracking servo doesn't actually move the lens as a result, but it can be detected - this tracking signal is amplified, filtered and detected, and can be decoded as a series of 4 ASCII characters, which change based on the region the disc was intended for - "SCEI" for NTSC:J, "SCEA" for NTSC:U/C, "SCEE" for PAL and "SCEW" for Yaroze. Yes, these are the same 4 character strings you see on the black boot screen, and they are actually being read from the CD controller by the boot ROM.

Sadly, you can't just patch the boot ROM to bypass the test, because the CD mechacon also contains an internal test for the correct region string and will disable all read related commands if it doesn't see it.

The early modchips

The first modchips came out quite shortly after the console was released, although their availability was largely in Asia. Some time afterwards, the SCPH-1000s with the new boot ROM and then the SCPH-3000 was released, and the chips became a lot more popular. These early chips were quite expensive, and some effort was made to obfuscate what they actually were, presumably to discourage attempts at reverse engineering them. They were typically supplied in what appeared to be 16-pin DIP packages with all the identification numbers erased. However, this didn't last long because people quickly worked out that it was actually a Microchip PIC16C54 microcontroller with the 4 pins at one end of the package chopped off and the numbers sanded off the package. Once this became commonly known, attempts at disguising the chips were abandoned.

These early chips had quite complicated connections and used a fair amount of logic to time the SCEx injections, i.e., they waited for the door to close, then for the limit switch to come on, then started a timer when FOK was asserted and turned on the SCEx injection shortly after that. Various later models dispensed with most of the clever tricks when it became obvious that you could just time everything from reset to the door switch and it would work anyway.

Old Crow and the first open-source chips

As knowledge of how to make these things spread, the prices dropped, but there were still no publicly released designs. This changed, however, when a developer with the handle "Old Crow" managed to reverse engineer one of the existing chips and implement his own version. This was originally written for Zilog's Z8 MCU, simply because it was the part he was most familiar with, but since the source was available, versions were quickly produced for the PIC 16C5x series chips and then the cheap, low-pin-count PIC 12C50x series.

Design proliferation

Since the basic information about what a modchip needed to do was now public, a lot of people started tweaking the code; this also coincided with Sony making attempts to defeat the chips, so a lot of the developments were associated with attempts to defeat the modchip detection. Around the same time, there were also a large number of people making very low-cost chips; a lot of these were effectively ASICs that had no function except to act as a modchip and often came in very low-cost packaging, like a 4-pin transistor-style package, COB (i.e., glob-top) packages, and a bunch of confusing devices that had numbers that were sort of like the ones used on PICs and used the same pinout as the 8-pin PICs but were in fact either ASICs or some completely different MCU flashed with modchip code.

Later Sony countermeasures

While all this was happening, Sony had been developing various different hardware revisions, and initially the licenced disc detection was largely unchanged. The PU-7 and PU-8 machines implemented the circuit using multiple chips, and the PU-18 and PU-20 boards changed this to using a semi-custom analog processing IC that basically took in the wobble signal and output NRZ data, but the net result was the same: a serial data stream that went to the CD mechacon and carried the demodulated version of the disc wobble. This was the signal that all the modchips connected to in order to inject their fake SCEx signal. Starting with the PU-22, this all changed: the whole side chain that processed the wobble was removed, and the only place the tracking signal was sent to was the CD processing chip (which in these models was also merged with the CD interface and SPU chips); at the same time, the SCEx signal had been merged into the SUBQ data stream (with a bit of scrambling to hide it) - since the other stuff on this line was critical to the functioning of the CD drive, you couldn't simply override it. Since the only place you could now get, the tracking info was the line coming from the RF amp chip to the CD processor, the SCEx data was injected there, but since the chip was expecting the tracking signal and not a demodulated baseband version, you couldn't just inject the NRZ into the tracking signal. The solution was to create a fake carrier signal that was close enough to the wobble signal to get through the filter, and it turned out that the WFCK signal from the CD processor could be used. This led to the "3 wire + link" mods, which took the WFCK signal, injected it into the tracking amp, and then used the open drain output of the PIC to drag it to ground to encode the SCEx data. This was admittedly not a great solution; it worked, but it also reduced the tracking gain and hence the tracking servo performance. The fixed wire link also injected WFCK into the tracking servo all the time, although this was somewhat mitigated by the fact that when the disc was reading data, it was in 2x mode, and WFCK was then well outside the passband of the tracking filter since it followed the data rate. A later improvement to this was to gate WFCK inside the chip so it could drag the TE signal low for a logic '1', allow TE to float, inject WFCK for a '0' and leave both floating when the chip was idle. A later variation put both the pulldown and the injection on the same pin, and although experimentally this seems to degrade the tracking performance slightly more than the older 3-wire solution, it's generally negligible.

Modern Chips

Although there are a large number of modchip designs out there most of them can honestly be ignored because they don't do anything special or especially useful. I'm including the "Old Crow" type chips here because although they are certainly historically relevant, there really isn't any reason to use one of them now except possibly nostalgia.

Mayumi V4

This was notable because it was the first chip that provided really good stealth on the PU-22 and later machines - as you might guess from the "V4" in the name, Mayumi made a bunch of other chips - and they were all good designs - but the V4 incorporated an (at the time) unique design feature, which was using the XLAT signal to shut off SCEx injection - this was a very smart move, because it's a stealth mechanism that relies entirely on the code inside the mechacon, which can't be changed once it's been manufactured, so it's not something that Sony could patch around.

• Works on PU18 and up.
• Uses timing on PU18/PU20 and XLAT on PU22 onwards.
• Two timing options on PU18/PU20.
• Does NOT support PU7/PU8 (uses mechacon clock, and this is different on PU7/PU8).
• Uses mechacon clock, so timing is highly consistent between chips.

MultiMode3 (MM3)

This seems to be a modified and patched version of the Mayumi V4 code. The main changes are that the clock has been switched to internal (so it will work on PU7/PU8 boards), simplified mode switching and (partial stealth) PU7/PU8 support.

• Supports PU7/PU8, although the stealth operation is not perfect
• Will support 4-wire non stealth mode
• One less wire (mechacon clock) to connect than Mayumi.

PSNee

This is a later chip - it was designed to run on Atmel based Arduinos, although it can also run on standalone ATTINY chips. It uses a unique stealth method that decodes the SUBQ data from the CD drive and controls the SCEx injection based on that, and may be the only chip that provides 100% stealth on the PU7 and PU8 boards.

• New universal stealth method.
• Only 6 wires on most boards.
• Also supports boot ROM patch for PAL PSone.
• Floats all I/O pins when not injecting data (this eliminates or greatly reduces the PM41(2) pickup noise issue).

OneChip

This is a modchip specifically for the PAL PSone, code wise it looks similar to the Mayumi V4 or the MM3 except some features have been removed (like mode selection - the PSone doesn't have a reset button) and the addition of a boot ROM patch that bypasses the PAL PSone territory check. One thing to be aware of is that the test is bypassed by fooling the boot ROM into thinking this is an NTSC:U/C machine (the same is true of the PSNee), and hence the menu will run in 60Hz mode - if you have a real Sony PAL PSOne screen this will be a problem since it won't accept 60Hz.

• Has PAL PSone ROM patch.
• Otherwise pretty much like MM3.

Summary

If you are looking for "which chip to use" then the general answer is "PSNee", simply because it will work on any model of console, has extremely good (in my experience, perfect) stealth capabilities and is simpler to install. If you have a SCPH-102 PAL PSone, then the Onechip is also a good choice, as long as you don't have the official screen. PU7/PU8 are also PSNee, since that's the only chip with decent stealth on these models. On PU18-PU23, then any of these chips are basically equivalent in terms of what they will do.