PSNee is an open source PSX modchip code for Atmel AVR microprocessors like the ATTiny and ATmega (Arduino boards).
It was coded by "THE FRIENDLY FRIETMAN" and released on the assemblergames.com forums a while back.

Right now, assemblergames is down and PSNee is not yet finished.
From what I can tell, it is missing stealth functionality and it does not gate the original SCEX string for original discs on consoles newer than the 550x series.

Stealth is somewhat implemented by a timeout. But modchip protected games work by asking for the SCEX string at an arbitrary time after the game has booted. A proper stealth mechanism will provide the string only when the drive controller put the laser on sector 4 of the disc. It must not send it when reading sectors where an original would not have the string.

Gating on older consoles should work (but I have not tested it yet). On newer consoles, I don't know which point to solder a gate signal to, and how the gating should be implemented. I do know that the old "link wire" method will work though.
This method connects points 5 and 6 in this picture with a wire: http://www.fatcat.co.nz/psx/install/750 ... m3pu22.jpg

A minor detail: The lid detection is missing its digitalRead() ;p

Let's use this thread to try and finish this project. I will add my findings as well

So about the stealth:
We know that the SCEX string can only be found on the earliest sectors on the CD. The read head has to be at almost the innermost position for reading it. There's a small pin on the read head that signals when it reached the innermost position.

One simple method to implement stealth is then to put a little bit of tape on the tray, so that the detector triggers even when the read head is at about the position to read sector 4 on the disc. Then we just watch that signal on the Arduino, kill all timing related injections and replace them with injections only when the signal says so.
I have tried this method and it does not interfere with normal operation. It allows Dino Crisis (which is modchip protected) to boot. It is very simple and effective: It doesn't even require timing anymore. We simply send the SCEX string whenever the read head is on the innermost position, just like it would happen on real disks.

The only problem with this that I can think of: Some games might deliberately put the read head to that position, but then not actually read the data there. My method would send the SCEX string and the game would know about the modchip.
Unfortunately, I don't know if any games used such a method.

You're overthinking it. As far as ik, the only reason the earlier 4 wire chips were detectable by certain "anti-mod" games is because they literally spam the authentication code endlessly . Normal, the hardware would ignore the extra code injections after initial boot, but sony eventually figured out how to pick up on the endless spamming using software. If you can get the PSNee to go into sleep mode after initial boot, you're halfway there. Then you just need to make sure, the chip reactivates when a new disc is inserted (lid closed) so multi-disc games work as well

That's true until you start Dino Crisis
As an old readme from the 90s said, the game is a deliberate attack on (then) stealth modchips (that used a signal to detect the pad init function, normally triggered when the game exe loaded).
It boots as normal, but then does an additional check that consists of the following phases:
- Clear the SCEX status
- Move read head to the SCEX area and try to read SCEX string
- Move read head to a different (data) area
- Clear the SCEX status
- "Read" SCEX string
To pass the check, it has to get the first string, but not the second.
It will fail if it gets 2 strings, or if it gets no string.

Which sector 4, counted from where? From 00:02:00 or 00:00:00 or from begin of TOC?

The SCEx signal is transferred at 250bits/second, so four characters with 11bit each would take around 1/5 seconds for transferring the SCEx string - so storing the whole string on a single sector isn't be possible.

From what I know the SCEx string is believed to be stored in the "wobble" signal somewhere at the "begin" of the disc (=presumably in the TOC area).

But if it's reading the string - from the TOC area: The PSX doesn't allow to seek into the TOC area (via SetLoc), so that it could be done only via something like Reset/Init/SetSession commands, which should be using the POS0 sensor to find the TOC (and the SCEx area), so the modchip could simply use the POS0 pin as is. Without needing to put tape on the POS0 sensor (doing that wouldn't work to well anyways, if you tweak it to trigger on 00:02:04, then the drive couldn't read the TOC any longer (which is located at "negative" MM:SS:FF addresses, prior to 00:00:00)).

Nocash, it could be some other *very early* sector as well. But I remember reading somewhere that the wobble starts at sector 4.
It is indeed close enough to the POS0 sensor that it sometimes triggers it without any tape added. But it's not reliably doing it.
I've verified that adding the tape makes it reliable and doesn't cause issues seeking to early sectors on bootup (I guess Sony left some slack in this, to account for manufacturing differences).

So another thing that'd be cool if it could be done: Capture the drive commands and just look for the one that reads the SCEX string. Timing injections to that would take all "heuristics" out of the way.

I am not absolutely sure where SCEX/wobble starts. I was always thinking that it starts at the begin of the TOC (or even shortly before the TOC), as far as I remember, the TOC is about 3-4 minutes long, ie. it would start at sector -15000 or so.
And "sector 4" sounds more like the "Licence String" at 00:02:04. More info: http://problemkaputt.de/psx-spx.htm#cdr ... escriptors
I guess that somebody just confused the 4-byte "SCEX string" with the "Licence string" on sector 4.

rama3 wrote:It is indeed close enough to the POS0 sensor that it sometimes triggers it without any tape added. But it's not reliably doing it. I've verified that adding the tape makes it reliable and doesn't cause issues

Hmmmm, I wonder what is happening there. POS0 should trigger somewhere at sector -15000, which would be miles away from the normal ISO sectors (ie. sectors that are seekable without using the POS0 switch). How thick is your tape? Several miles?

Another theory would be that the game is seeking to POS0, but your hardware setup might miss the POS0 signal (maybe because it's too short, or because the switch contacts are a bit dirty and don't reach a clean 0 volt level). And the tape might change the mechanical behaviour to produce a better/longer POS0 signal.
Though concerning timing, the PSX must first poll the POS0 signal, then stop the sled motor, and then start TOC reading with sled getting moved in opposite direction - so the POS0 signal should be long enough for getting sensed by modchips.

rama3 wrote:So another thing that'd be cool if it could be done: Capture the drive commands and just look for the one that reads the SCEX string. Timing injections to that would take all "heuristics" out of the way.

The TTY Debug Mesage Window in no$psx includes options for logging CDROM commands (and IRQs), maybe that could be useful.

Apropos, Dino Crisis, are there already any modchips that can play that game? And if yes, do they connect to POS0 or DOOR or the like?
Oh, and is the game working in no$psx? I've just noticed that no$psx still leaves the 19h,04h and 19h,05h test commands unemulated, as far as I remember Dino Crisis does use that test commands - if it's working even without emulating that commands then the proctection doesn't seem to be very strict.

I thought the wobble is where the ATIP would usually be. Since the discs are pressed, that data segment is useless on pressed discs (it's only relevant to have on CD-R's) so Sony pressed the wobble in this area for PlayStation games.

Anyway,

To read the SCEx counter, you have to seek to somewhere in the data area of the disc, start CD play mode, reset the protection counter (send commands 0x19, 0x04 to the HC05), wait, and read the results (send commands 0x19, 0x05). You have to make sure the drive isn't in the Lead-In/TOC area though or you will pick up protection symbols even if there is no modchip.

Nocash, I hooked up my scope to the POS0 readout (and everything else as well. It really is nice to see what exactly is going on ).
When the protection routine in Dino kicks in, it first moves the read head to the SCEX area. The scope sometimes shows a blip (POS0 activated), and sometimes it doesn't. It probably depends on the momentum the sled had this particular run.

The game reads data for a second, then moves the read head forward a bit and reads data again. If it got what it wanted, it continues. Otherwise it will spit out an error screen and stop.
An emulator will pass this test if:
- it clears the SCEX string on request
- it puts it back in when the SCEX read function is called, but *only* if it's on the correct sectors
- (alternatively, it could do all kinds of high level workarounds :p )

I agree that the protection isn't very strong, but this is only the first NTSC-U release with it. Other games might be better.
As far as I know, there is no comprehensive list of protection schemes used in games.

The TTY Debug Mesage Window in no$psx includes options for logging CDROM commands (and IRQs), maybe that could be useful.

It almost certainly would be useful. The tricky question is where one could reliably grab these commands from on real hardware

Oh, just as a note, I tested "Dino Crisis" the (German) PAL version on PSIO and it too crashes if the HC05 does not have "SCEE". Even if it's blank (like a debug station) it fails. It's a 1:1 check. We've had to update the logic in our firmware now to compensate for this annoyance

EDIT: Okay, unless there's a bug in our code, Dino Crisis actually works with SCEE, SCEA or SCEI. It fails if it does not match any of these things. I haven't tried SCEW yet though, but I doubt they added that. I think only the Yaroze's had that in their HC05 and the wobble contained SCEW itself on pressed Yaroze CD-ROM's (such as the "Net Yaroze Boot Disc" (DTL-H3000)).

I'll add titles to this thread as I find them, then some day compile a nicer list

Vandal Hearts 2 NTSC-U: unknown if antimod, but stops on white Konami screen if (guessing) the BIOS region doesn't match the game's. It only works on my NTSC-U BIOS machines.
Update: This game requires the antimod code to run, else it will freeze. However, since the antimod routine doesn't run on PAL machines, it effectively cannot run on those. (The game can be patched, of course.)

Last edited by rama3 on May 8th, 2017, 8:23 am, edited 1 time in total.

Could it be that NTSC-U games on a PAL / EU BIOS skip over the antimod protection routines?
I'm having trouble getting the protection screen on nearly all NTSC-U games.
Unfortunately, I only have 1 good NTSC-U console. I don't want to mess it up :p

Edit:
Yes, they do. Antimod kicks in on an NTSC-J BIOS as well, so I changed consoles and now I get them

Here's my work in progress. It uses the position 0 switch on the laser assembly. To make this work, a bit of sticky tape is required, so that the switch closes even when the read head is a little further out. I use 2 layers of electrical isolation tape.

, "PlayStation", , , "DUALSHOCK", "Net Yaroze" and "PSone" are registered trademarks of Sony Computer Entertainment Inc. .
This page is for informational use only. The user of this software, assumes full responsibility ensuring its use in accordance with local and federal laws.
The software and hardware on this site is provided "as-is", without any express, implied warranty or guarantees.