PsNee: a stealth modchip for all PS1-models

UPDATE: PsNee V6 currently is the latest version and works perfectly on a PAL SCPH-102 and has a working NTSC BIOS-patch. All prior versions (V1, V2...) are only partially functional, so use PsNee V6 for the best experience.
The source code is heavily commented, most of the questions you may have can be answered by just reading through the source code. It won't only be scary nerd-speak, I promise ;-)

-------------------------------------------------------
Hi!
A friend asked me if it was possible to mod his PS1 to play games from overseas as Sony region-locked his PAL-Playstation to well... PAL-games. "Of course!" I said, knowing that a plethora of modchips existed for the Playstation that enabled imports and backups. These designs however turned out to be all rather old-fashioned, being written for PIC-parts (specifically the PIC12C508, freaking OTP (One Time Programmable)-parts!) no one ever heard of. This isn't the nineties anymore! I want something modern and easy to program! No fiddling with ports that modern computers deny the existence of. Just program-and-go!
It turned out... no such thing existed. Well, there is the mod-avr project, which uses an Atmel ATTiny13 and some assembler to fool the Playstation. I like the Atmel parts, but I didn't have an ATTiny13 in my parts bin, only ATTiny45's and ATTiny85's. I also can't really fully read and understand (AVR) assembly, so I decided to put some effort in making a very easily understandable modchip with Arduino. I mean, why not?! So, PsNee (Dutch for PsNo, saying no to Sony's protection) was born!
Well, I know Arduino isn't really considered to be as hard core as assembly or pure C, but hey, Arduino code looks a lot more accessible and is a lot easier to read without all the scary and seemingly random codes in an assembly program.
Anyway... I waited for a nice rainy day to do some research on how Playstation modchips work, and was kind of surprised at how uncomplicated they really are. In my program, I achieved the basic functionality of a modchip with just a couple of for-loops!

The code attached is very heavily documented, right down to the point it annoys you with obviousness. This is for the non-nerds in the world, I want my code to be as easy to understand as possible, so even an anthropologist can understand how to break Sony's Playstation protection. ;-)

The nice thing of using Arduino is the variety of hardware the program can run on: just put "Arduino" in eBay and you'll see what I mean. The program is intended and timing-tweaked for an ATTiny45 running on the internal 8MHz oscillator, although it will run on any Arduino-supported platform. Google "Arduino ATTiny" to figure out how to program an ATTiny chip to run the modchip program on it's own.
I really won't have to explain here how the code works, I think the comments in the code explain it very clearly.

I burned my code on a ATTiny45 and checked it with an external pull-up on the data-pin on my Saleae Locic logic analyzer and lo and behold... it worked! Awesome!
Now, you all know the proof of the pudding is in the eating, so I got my friend crazy enough to let me install my Frankenchip in his beloved, virgin Playstation... deep breaths... and it didn't work. Of course. It never works the first time. In this case the lid switch was not being pressed, so the Playstation wasn't reading the discs at all. Some switch taping later... the Playstation indeed played the import from Japan! My modchip worked! Amazing!

On his other Playstation, an SCPH-102 model, the now modded Playstation only accepted PAL-discs (be it original or backup), no imports. I found out this was due to additional region checks in the SCPH-102 BIOS. The OneChip modchip apparently solved this by doing something with an address line and a data line of the BIOS-chip. I unfortunately haven't got a PIC-programmer nor the required PIC12C508, so I can't test for myself what this chip does to make PAL-102's accept NTSC-discs. Could anybody explain this to me or, even better, record the logic signals on the data and address line with a logic analyzer? You can read more about this in the PsNee program.

Well, that's quite a story for something as simple as a modchip. I hope I can help the lone souls that want to mod their Playstation but dislike PIC's (like myself ;-)). Just play with the code! Change it, improve it, add more silly jokes to it! The code is free to use, as long as you don't act like it's yours and credit me for writing it. Basically just a "don't be an arsehole"-license. ;-)

!!!EDIT: PsNeeV2 is released as beta! A changelog and the new source code are found in post #17

 

When you say all consoles....

Have you thought about stealth protection? the fact it differs on the SCPH-1002?

Do you account for other regions (JAP and NTSC) and also that Jap consoles also have an additional check in the bios (like the SCPH-102) that far as I know, didnt have a modchip made to defeat it?

If not, might want to rename the thread

But other than that, good first post!

Edit:

Actually had a glance at the code, seems you have stealth and multi region. Are you just disabling injecting the SCEx string after a fixed time to be "stealth"?

Edit2:
Modchip code also works on the PIC12F508 or 12F509 too, which is flash and not OTP. If you want to get some for experimenting.

 

No, I didn't, but now I do ;-)

EDIT: HEY MAN STOP EDITING ;-)
Yeah, the code stops sending strings after 30 cycles of string outputting, which is about 25 seconds, that seemed quite safe.
@PIC's screw them PIC's when you can AVR ;-) Anyway, I'd need to make a PIC programmer then as well, maybe something for a rainy winter weekend.

 

I was considering doing something very similar to what you have made, but TriMesh had reasons (that I cant remember at the moment) for not using that method.

Im sure he will pop by with his input.

But at the very least, you have made some code that can be built up on, on a platform that is easy to modify and setup.

 

Very cool, new PS1 modchips are always welcomed.

Note that mod-avr does not have stealth, so it wouldn't work anti-mod games, and this does so that's great.

The only real negative is that a quick search on eBay shows that ATTiny45 and ATTiny85 is more expensive than 12F508. ATTiny13 is actually a little cheaper than 12F508 so getting it work on that would be a big advantage.

If I have any PS1s to mod in the future I could give this a try. How do you wire it up compared to other chips?

Might be worth it to include a pre-compiled HEX for those that want to try it out and aren't familiar with compiling Arduino.

Most code designed for 12C508 will work fine on 12F508 but I've read that OneChip is "One" of those exceptions BTW. MM3 and Mayumi for example work fine on 12F508.

Good work, and it would be neat to see this become a truly universal chip as intended.

 

One chip works fine on the f chips.

You don't program hex to arduinos

 

Wherever I read that about the OneChip must have been a user issue then, so nevermind. I don't live in PAL territory so have never needed to deal with the OneChip.

I've never dealt with the chips that OP mentions specifically and didn't know, thanks.

 

Who wrote this in the past have wrote a big bul*****t. I can confirm that onechip works great with F series.

 

To be fair, I actually think it was me.

All tests since have been fine though, so console or bad chip.

Regarding ardunios, you put a boot loader on the chip then you can upload sketches to it. It makes it pretty easy to test stuff as you are doing it. Which is why I see improvements happening from this base work.

Once it's fully developed its possible to generate a "hex" - just upload the sketch then dump the chip in a programmer.

 

@How to wire it up: I forgot to add that part, thanks!
I've made a small and simple conversion table to be able to use most of the common wiring diagrams for PsNee.
Ordinary modchips:
1 - Vdd
4 - reset switch
5 - gate
6 - data
7 - door switch
8 - Ground
(source: http://modchip.aeug.org/)


Pin-out for PsNee on an ATTiny45:
Pin 1: Not connected
Pin 2: Not connected
Pin 3: Not connected
Pin 4: Ground
Pin 5: OUT - Data
Pin 6: OUT - Gate
Pin 7: IN - CD lid
Pin 8: Vcc

So, that translates to:
Ordinary modchips | PsNee
-------------------------------------------------------
1 | 8
2 | X
3 | X
4 | X
5 | 6
6 | 5
7 | 7
8 | 4

I've also included a shot from the Saleae Logic software that captured the waveforms on the data-pin output (note: the gate-pin is not connected to the logic analyzer).

 

The basic problem with just using a timer is that it's very hard to predict what the boot timing is going to be. On all the consoles except the old SCPH-1000, there are two wobble checks, the first one happens just after boot and the second just before the game starts. The length of time this takes is highly variable depending on how good the optical pickup is, the sort of CD-R you are using, the exact model of the console, etc.

The net result of this is that if you set the time to a reasonable value for a good pickup there is a significant chance of the boot process hanging with a bad pickup because by the time the second protection check is hit the modchip has already turned off. There is another issue if you are using a cheat cart to fastboot the console - in this case, there is only one protection check and the game gets control much earlier than it would using the BIOS boot - with the result that the protected games that have the protection check early on will fail the modchip protection test.

On the later machines you can avoid the timing issues by monitoring the XLAT/ signal from the mechacon CPU and exploiting the fact that when the console is reading the ToC it doesn't send any commands to the CD DSP, so XLAT/ just stays high - as soon as it's validated the disc, it issues a seek command, and this is detected to cut off the modchip stream. This approach doesn't work on the PU-7 or PU-8 because the same data link is also used to carry the commands to the RF amp/servo chip, and hence it sends commands even when reading the ToC.

Before that, the standard approach was to monitor the x1/x2 speed control line from the mechacon and use that to try to infer where in the boot process you currently are (sort of like an automatic version of the swap trick) - this actually worked pretty well, but required code to try and identify what sort of boot process was being used and select the correct timing based on that.

The other thing is that the gate/data approach doesn't work very well with the later (PU-22 and on) consoles, because they no longer have the external connection to the mechacon for the SCEx data - connecting the data to the tracking error amplifier input on the CD/SPU chip sort of works, but it also degrades the performance of the tracking servo because when the chip driving low there is no tracking signal. The approach that pretty much everyone eventually settled on was to chop up the data stream with an external clock (normally WFCK) - so that even when you were driving the pin the tracking signal got through 50% of the time, and the digital filtering in the chip then filtered the WFCK signal out. It does still effectively decrease the tracking gain by 3dB during those bits, but there is more than enough gain margin in the system to handle it. The AVR is more than fast enough to handle this, but you might have to write the loop that drives the pin in assembler.

Oh, and you weren't hallucinating about the 12F508s - the early ones really didn't work for OneChip - I have no idea why, because according to the datasheet they should have been fine. Just in case it was a problem with the programmer (Picstart Plus), I also tried programming a bunch of them on Microchip's ProMate production programmer - and they didn't work either. Apparently they do work now, despite the fact that officially there was only ever one version of the chip...

 

Wow, you seem quite knowledgeable on the subject - why? ;-)
It makes sense to "slice up" the modchip signal injected on the tracking signal line, now the modchip indeed, when low, completely masks the tracking signal. I've drawn my interpretation of your text, mixing the modchip data ouput with the WFCK, which, according to a quick Google search, is about 7.35kHz. The drawn signals are high when pulled to ground, low when high-impedance.
Do you think it is required to use the WFCK itself for slicing data, or could I just flicker the modchip output based on the internal AVR clock? I don't think the clock phase does matter much here, that sure does make things easier to program. ;-)
Do you also know how the BIOS NTSC patching for a PAL SCPH-102 works? I really can't find a clear explanation of that online, I'd love to include that as well on PsNee.

 

Yeah, I was involved with this stuff back in the day, and I am blessed (or cursed ) with a good memory.

Using an internal clock would probably work, but you seem to get better results using a clock that is synchronous with the CD controller - possibly because with a free-running clock you can sometimes get artifacts that get into the tracking filter passband. The other reason for using the WFCK from the CD DSP is a practical one - since it uses the same wire as the gate signal the code can establish what type of board it's running on by monitoring this line for a clock signal. If you find the clock there then you are running on a PU-22, PU-23 or PSone, and if you don't then you are running on an older unit - so you can use the same chip on all models.

The OneChip patching is simple, but fiddly - the basic process is like this:

1) Wait for the end of the first protection check (by testing XLAT/)
2) Wait for one of the address lines on the ROM to go high (the section of code that tests the license is about to run)
3) Wait for a bit (NOPs)
4) Pull one data pin down on the ROM data bus
5) Release it again

Your avatar photo is making me want patat oorlog...

 

Interesting read.

Thanks, TheFrietMan for sharing!

 

Good post man. Just for reference, the pic 12f629 is flash and cheap as chips (£1.49 per unit). I have eagle schematics for a pic programmer of my own design is u want to use it and improve upon it. Got it fabbed by osh park in US. Works a treat using ICP. I installed my chip in a pu-23 board. with help from trimesh, I ironed out some kinks. But found it worked best when powering on with reset button. This might point towards trimesh point about boot timing and poor pickup. Does your code deal with anti stealth chop games like dino crisis?

 

Now I have bite marks on my monitor - maybe I should look for another job in Amsterdam

 

I'm back! I've been working on adding features suggested by you, my dear reader! I love reading all your positive comments! A great big "thanks!" goes to TriMesh for all the in-depth info.

PsNeeV2 betters PsNee with:
- Thanks to TriMesh, the gate-pin is now also used to determine in which model of
Playstation PsNee is installed. The modchip algorithm thus can be optimized for
optimal performance on specific Playstation revisions. This works by monitoring
whether a clock signal is present on this pin - when there is one, the modchip is
installed in a PU-22, PU-23 or PSOne Playstation, else it is installed in an older
model Playstation. In this version of PsNee, nothing is actually done with this information.
- Thanks to -again- TriMesh, NTSC support for PAL SCPH-102 Playstations is added! This uses the same method the OneChip modchip used for achieving this:

1. Monitor the XLAT signal from the CD mechanism controller chip. This requires
another connection to the Playstation. When this signal is 0, the first CD copy
protection is passed! After this, there is another one.
2. After this, watch the Address18-pin (pin 31) on the BIOS-chip. When this signal
is high, this means the second CD copy protection is about to run.
3. Wait a short time.
4. Pull the Data2-pin (pin 15) on the BIOS-chip to 0. This effectively blocks the
execution of the region check of the inserted disc.
5. The Playstation plays the inserted disc and doesn't care whether it's PAL or NTSC!
6. Release the 0 of the Data2-pin.
To correctly output a PAL video color signal for a PAL TV on a PAL PSOne with an NTSC disc
inserted, Pin 3 of IC502 must be grounded with an external switch. The modchip also could do
this, although we would need a device with more pins available.​

- The outputted data signal is now "sliced up" to improve (or less distort) the tracking
signal from the CD mechanism: later Playstations use the CD tracking signal for transmitting
the SCEx-string to the Playstation instead of using a seperate connection, so when the modchip
forces a 0 on the data-pin, the tracking signal also is gone temporarily. By slicing the data-
signal up in little pieces at least some of the tracking signal remains and the Playstation can
read discs more easily.
- The two big for-loops are combined into one with an OR-statement describing the two conditions
modchip should be active: when flagFirstCycle = 0 or when flagFirstCycle = 1 and the lid is opened
and closed again. This makes code maintenance easier.
- The pin-out of the modchip is changed slightly to be able to use an interrupt for the PAL=>NTSC
BIOS-patch for PAL SCPH-102. Please use the revised pin-out found below with this code.

The code however is NOT tested on actual hardware - I'm not too keen on the delay values I've used for the SCPH-102 PAL=>NTSC BIOS-patch, these are just educated guesses. As soon as I can get my hands on an actual PAL SCPH-102 again I will test this with the logic analyzer.
Does this mean PsNee is finished? No! Make your own variations! Suggest features! Fix bugs! Code extra things in! Fix the things in the TODO-list!

I would very much appreciate it to get some feedback on the new code! Don't hold yourself back criticizing me! ;-)

 

@PIC programmer: now that TriMesh has explained how the OneChip does it's BIOS trick for PAL SCPH-102's, I no longer have to probe the OneChip itself, so I don't need a programmer anymore. Who uses PIC's anyway ;-)
@Dino Crisis: I haven't tested Dino Crisis itself, but I also still haven't found a game that wouldn't work with PsNee, so I guess it will work fine. Or does Dino Crisis use a different anti-modchip protection than other newer PS1 games? Nothing that can't be fixed with a bit of code (or duct tape) ;-)

 

Very nice, I will have to order an ATTiny45/85 so that the next time I'm doing some PS1 modding I can test it out and post the results.

To my knowledge, the anti-mod protection on Dino Crisis isn't anything special, it's just that it's one of the first (if not the first) games that used it. Spyro 3 is known for having the "toughest" anti-mod protection (and it does checks multiple times throughout the game). It's one of those games that won't pass on certain "partial" stealth modchips.

If you can write out the (modified) pinouts for the chip I could make some diagrams to go along with this. I'd probably just edit some existing ones with the right pinouts. Is it known (or assumed) if it will work on all models?

 

Spyro 3 is one of the games I do have and that works just fine, so I guess PsNee is doing well
It would be very cool if you could make some wiring diagrams! The pin-outs can be found in the source code, along with a lot of other rambling ;-) Don't be scared that the source code only contains scary and unreadable programming commands, I've tried my best to document and comment everything until it gets silly. ;-) About half of the code are comments, anyway.
Please note that the pin-out for PsNeeV2 had to be changed due to having to use ATTiny45 pin 7 for the interrupt for XLAT. I would recommend using the PsNeeV2 pin-out in your diagrams, V2 will be the base for V3, etc.
The pin-out however can very easily be changed/pins can easily be swapped by changing the pin numbers in the source code before compiling, that is very easy. The only pin that can't be changed is the XLAT-pin, because of the hardware interrupt.