[Diagram]SCPH-1000/3000 PU-7 MM3 Stealth Install

[Traace]

Hi Community, It started when I bought a SCPH-3000 from eBay. Because these Japanese Systems are not that common here in the EU.

I just fell in love with the PU-7 Boards.
Not only the SCPH-1000 runs with a PU-7 Mainboard, also the SCPH-3000 does, they just removed the S-Video.

There was zero information on the net about the rare PU-7 Mainboards, so i traced the board with the help of some schematics. Counting pins on a 80-pin HC05 QFP isn't that easy.

And here I'm now, done and exhausted, but at least we got a hi-res diagram with Stealth support now for all the dirty PU-7 Mainboards out there.

(Click on the pic)



PS1 is love

2x SCPH-3000 were tested now, its worth to note that these Systems don't suffer from FMV Lag at all! Even with the Stock Laser Lens.

I also managed to place in a 230V EU(PAL) PSU into the Japanese SCPH-3000. If someone need that diagram, just let me know

[rama3]

Oh, that's really nice of you. I suppose similar points will be present on the PU-8 series? Up until now, it was thought that those boards wouldn't support full stealth chips.

You didn't get this unit from "h-ecke" by chance?

[Traace]

Here you go, full stealth is also possible on PU-8, you're right. However, the diagram below is not mine. So i didn't test it yet. But it should just work!


(All credits go to an unknown guy from EurAsia forums)

Please Ignore that strange looking chip on the left top of the board, its for some kinda color correction he said.
Only the Numbers are for the Modchip install.


I will do a proper PU-8 diagram in the future, but these boards are pretty expense here.


Edit: Oh and yes "h-ecke" sold them to me.

[rama3]

Awesome, thanks!

There's also many install pics around for the later PSX boards, where they tell you to grab a reset signal from all across the other side of the board. This is so silly, as the same signal is right there at the HC05, near Pin13.

[Traace]

What you call Pin 13 on that 52pin HC05 is pin 20 on a 80pin HC05.

Yes that Pin 13 is connected to the reset lane. So a physical reset actually resets the drive controller too. One of the PS1 PCB reset lanes is like this: PSU-->Reset Signal-->?Diode?-->Resistor-->HC05(Drive controller)
So, in theory it should also be possible to take it straight from the PSU reset signal (As on mine PU-7)

I guess they took another point on newer PS1 because its easier to solder on, or they were lazy who knows

[rama3]

I honestly think they didn't have service manuals and were too lazy to ring out a better connection point :p

[likeabaus]

Hi Community, It started when I bought a SCPH-3000 from eBay. Because these Japanese Systems are not that common here in the EU.

I just fell in love with the PU-7 Boards.
Not only the SCPH-1000 runs with a PU-7 Mainboard, also the SCPH-3000 does, they just removed the S-Video.

There was zero information on the net about the rare PU-7 Mainboards, so i traced the board with the help of some schematics. Counting pins on a 80-pin HC05 QFP isn't that easy.

And here I'm now, done and exhausted, but at least we got a hi-res diagram with Stealth support now for all the dirty PU-7 Mainboards out there.

(Click on the pic)



PS1 is love

2x SCPH-3000 were tested now, its worth to note that these Systems don't suffer from FMV Lag at all! Even with the Stock Laser Lens.

I also managed to place in a 230V EU(PAL) PSU into the Japanese SCPH-3000. If someone need that diagram, just let me know

Thats pretty neat that you were able to figure that out, nice work!

[nocash]

No! I hate modchip diagrams! Can somebody explain why those modchip diagrams always consist of nothing but numbers and arrows? I understand that commercial modchip manufacturers don't want other people to figure out how modchips are working. But if you don't have that kind of commerical interests, and if you know that one of the pins is a Reset signal, why can't you annotate that as "Pin Y = Reset"?

Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.

Oh, and I didn't know that PU-7 did have a 1-655-322-15 revision. The HC05 firmware from the 424660 chip was already dumped by TriMesh (from a SCPH-1000 with 1-655-322-13 board). Do you remember where you got the 1-655-322-15 board from? From a SCPH-1000 or SCPH-3000?

[Traace]

No! I hate modchip diagrams! Can somebody explain why those modchip diagrams always consist of nothing but numbers and arrows? I understand that commercial modchip manufacturers don't want other people to figure out how modchips are working. But if you don't have that kind of commerical interests, and if you know that one of the pins is a Reset signal, why can't you annotate that as "Pin Y = Reset"?

Well this one is made for a public release in mind therefore I didn't make it to "complicated". I understand your point and its a pretty good one. Normal People just don't care what signal comes to what pin/point, they don't care how this chip actually works. It might also to consider that most people just don't have the time to read a couple of ps1_specs pages(thanks for that btw) think about what they read there and apply their new knowledge afterwards.Sad but true. In my opinion we have to change the peoples mind first, so we don't confuse them with more advanced diagrams that nobody can apply.

Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.

I just tested normal anti-modchip games(like The Legend of Dragoon US) in my SCPH-3000 tho, to get it running i had to patch the boot to JPN of course. You refer to them correct?

I hope that helps(80-pin QFP):

Code: Select all

VDD - pin 1 -> Mainbaord VDD
GP5/T1CKI/OSC1/CLKIN - pin 2 -> Unused for MM3
GP4/OSC2/CLKOUT - Pin 3 -> Connected to HC05 Pin 42 (This one has something to do with Stealth support)
GP3/MCLR/VPP - Pin 4 -> Mainboard Reset
VSS - pin 8 -> Mainboard VSS
GP0/CIN+/ICSPDAT - pin 7 -> ? I/O with GP1 ?
GP1/CIN-/ICSPCLK - pin 6 -> ? I/O with GP0 ? -> Connected to HC05 pin 32
GP2/TOCKI/INT/COUNT - pin5 -> Unknown

Oh, and I didn't know that PU-7 did have a 1-655-322-15 revision. The HC05 firmware from the 424660 chip was already dumped by TriMesh (from a SCPH-1000 with 1-655-322-13 board). Do you remember where you got the 1-655-322-15 board from? From a SCPH-1000 or SCPH-3000?

Yes, it comes from a SCPH-3000 System

[rama3]

I'm sure you/we/someone can add a small legend to your diagram, saying what point is what

Are you sure Modchip Pin 3 goes to HC05 Pin 40 (a bit on Port A) though? Isn't it more like Pin 43 (Data)?
It would make sense if it read the Data stream, looking for the getSCEX() command. It's what I had in mind as well ;p

Nocash: Someone surely knows how Multimodes work. It's more like I want to work it out myself, then possibly add something like it to PSNee

[nocash]

Thanks for the pin-outs & confirming that it's a SCPH-3000 board! I've added a note in the http://www.psxdev.net/forum/viewtopic.p ... 4284#p4284 thread, saying that the 424660 cdrom/firmware is also used on that board.
Now that you have that "rare" board around, do you have some tools for dumping it's BIOS or displaying its CRC32 on TV, for adding it in the http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065 thread?

HC05 pin32/80 is PortB,bit1, ie. the SCEx signal transferred at 250 baud, connecting there makes sense for modchips.

HC05 pin40/80 is PortC.bit1, ie. the SPI-bus output, which should be unused in pre-SCPH-9000 consoles. That doesn't make sense to me.
HC05 pin39/80 is PortC.bit0, ie. the SPI-bus input, that would make more sense (to watch the SUBQ signal for knowing the position & when to output SCEx on which sectors).

The other two pins might connect to the BIOS ROM for patching the region byte. I've seen a modchip connecting to D2 and A18, maybe this is chip doing that the same way, too (though it should work only for US-vs-PAL, and shouldn't won't work for Japanese boards).

[Administrator]

Now that you have that "rare" board around, do you have some tools for dumping it's BIOS or displaying its CRC32 on TV, for adding it in the http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065 thread?

I'll write a program to do it. Easy enough. Read the ROM into RAM, CRC32 it and then print the results on screen.

[Traace]

I'm sure you/we/someone can add a small legend to your diagram, saying what point is what

Are you sure Modchip Pin 3 goes to HC05 Pin 40 (a bit on Port A) though? Isn't it more like Pin 43 (Data)?
It would make sense if it read the Data stream, looking for the getSCEX() command. It's what I had in mind as well ;p

Nocash: Someone surely knows how Multimodes work. It's more like I want to work it out myself, then possibly add something like it to PSNee

Yes,true. thanks for the notice
It ain't goes to HC05 40 (my eyes lied:D ). The correct Pin is HC05 42 ( I edit the pinout above)

The other two pins might connect to the BIOS ROM for patching the region byte. I've seen a modchip connecting to D2 and A18, maybe this is chip doing that the same way, too (though it should work only for US-vs-PAL, and shouldn't won't work for Japanese boards).

Seems like that is the reason why we still need to patch the region of a US,EU Game to JPN in order to run them on Japanese systems.

[rama3]

Shadow, those tools already exist. There is a checker tool that displays the BIOS CRC and compares it to a known list.
Another tool can dump the BIOS to memory card or over SIOCONS.
http://forum.redump.org/topic/4991/new- ... l-cd-unit/
http://www.psxdev.net/forum/viewtopic.php?f=66&t=395

Traace: You could use an expansion port cart for bypassing the BIOS boot. Or use a PAL or NTSC-U BIOS chip :p
And to get the correct pin on the HC05, it should be the same as on more modern install pics. Those show the connection to a resistor that connects to the pin on the HC05. I know that the chip will still work if it's connected to the wrong resistor/pin. This is a common mistake in PSOne install pics.

[nocash]

HC05 pin42/80 is PortC.bit3, ie. drive SPEED, the TOC/SCEX is read at single-speed, and other sectors are (normally) read at double speed, so that should actually work for sensing when to output the SCEX signal, but only if the games are really using double speed (which might apply for most or all games, but it would be very easy to produce a game that defeats that kind of modchips by using single speed for SCEX reading).

Ah, and, at double speed, the SCEX signal would be 500 baud instead of 250 baud, and the cdrom firmware won't recognize 500 baud signals at all. Ie. at double speed, the game can't really detect if there's a 500 baud SCEX string coming from the disc (instead, it can only detect if a modchip outputs a 250 baud SCEX signal despite of running in double speed mode).

The CRC32 tools from Shendo and Redump are CUE/BIN only, ie. they are working only if you have a CDR and a modchip installed on all boards that you want to check. An EXE file would be much nicer for CRC32 viewing since it could be booted from expansion port (if present).

[Traace]

Traace: You could use an expansion port cart for bypassing the BIOS boot. Or use a PAL or NTSC-U BIOS chip :p
And to get the correct pin on the HC05, it should be the same as on more modern install pics. Those show the connection to a resistor that connects to the pin on the HC05. I know that the chip will still work if it's connected to the wrong resistor/pin. This is a common mistake in PSOne install pics.

Unfortunately I just bricked my old German "PS Hacker v2" yesterday (Hate those clones anyway ), but yes it should work

HC05 pin42/80 is PortC.bit3, ie. drive SPEED, the TOC/SCEX is read at single-speed, and other sectors are (normally) read at double speed, so that should actually work for sensing when to output the SCEX signal, but only if the games are really using double speed (which might apply for most or all games, but it would be very easy to produce a game that defeats that kind of modchips by using single speed for SCEX reading).

That's interesting, thanks
When I leave HC05 pin42/80 disconnect from the Modchip, Stealth is not given anymore, the rest (beside region patching) works.


Oh, the tool above is pretty nice.

CRC "3539DEF6"
Romstatus "Dumped"
"Sony Computer Entertainment Inc. -1000 KT-3 By S.O."
System Rom "1.1 01/22/1995"

Edit: Both SCPH-3000 were tested now. Same result.

[nocash]

CRC "3539DEF6" ...Romstatus "Dumped" ..."Sony Computer Entertainment Inc. -1000 KT-3 By S.O."

Okay, thanks. The extra-info that I was after is the part number (the whole text on the ROM chip), the package (40pin?), and the board name and mechacon part number (ie. PU-7, 1-655-322-15 and 42660 (unless the other SCPH-3000 board is different)).
Just check here to see how the whole info should look like: http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065
Or, if you could make a photo of the PCB front side would be nice, too. Currently you've only the back side.

[Traace]

CRC "3539DEF6" ...Romstatus "Dumped" ..."Sony Computer Entertainment Inc. -1000 KT-3 By S.O."

Okay, thanks. The extra-info that I was after is the part number (the whole text on the ROM chip), the package (40pin?), and the board name and mechacon part number (ie. PU-7, 1-655-322-15 and 42660 (unless the other SCPH-3000 board is different)).
Just check here to see how the whole info should look like: http://www.psxdev.net/forum/viewtopic.php?f=70&t=1065
Or, if you could make a photo of the PCB front side would be nice, too. Currently you've only the back side.

Ahh I see, It shouldn't be a problem to look that up. You can expect that information this weekend



Update: http://www.psxdev.net/forum/viewtopic.p ... 290#p12290

[Shendo]

The CRC32 tools from Shendo and Redump are CUE/BIN only, ie. they are working only if you have a CDR and a modchip installed on all boards that you want to check. An EXE file would be much nicer for CRC32 viewing since it could be booted from expansion port (if present).

Oh, first I actually only published dumper in the .exe form but I got a bunch of people PMimg me
for instruction on burning a working CD. So instead I published a bin/cue image.

I attached exe in the dumper release thread.

Dumper also shows CRC32 but I haven't included a "already dumped check".
If anyone wants to improve upon it I released the source.

[TriMesh]

Asking because rama just told me that nobody knows how "MultiMode3 and Mayumi4" modchips are working - as far as I understood they can defeat a special protection in Dino Crisis - and knowing where the pins are connected to would certainly help to understand how it works.

It's pretty much a hack. Mayumi (and MM3, since it appears to have been largely copied from Mayumi) there are two different operating modes depending on which sort of board the chip is installed in.

On PU-7 / PU-8 / PU-18 / PU-20, the code attempts to work out where in the boot sequence the console is by monitoring the X1/X2 speed control line. It's not as simple as just switching the data on and off - there are a series of delays for each part of the boot, and the speed line is basically used just as a hint to know exactly where the boot is right now. You can't just gate the data using the speed line because the anti-modchip test is carried out using CD-Audio play mode, and that's X1 too.

Basically the logic is:

After reset or door close, delay for a bit (two different delays for reset or door close) then start looking for the speed to switch to X1 (first protection check) - after this is detected, wait for the speed to switch back to X2 and start another timer. Then wait for the speed line to go back to X1 again (second protection check - this is also why it screws up on the very early boot ROM, since that doesn't have this check). At this point, it just waits for the door switch and then the whole cycle repeats.
That's the basic process - the code also has some code to detect the situation where you are booting using something like Caetla rather than the boot ROM, since that changes the timing and using the same timing as the original boot ROM would make the console fail the second protection check.

On PU-22/PU-23, it's a lot simpler. This is a special mode that's enabled when the chip is installed in a newer console (what used to be the modchip gate line is connected to WFCLK on the newer boards, and the code looks for a clock on this pin and if found enables PU22/PU-23 mode). In this mode, the chip monitors the XLAT line between the control MCU and the servo amp chip and cuts of the SCEx strings when it detects a pulse on it. There is also an initial delay so that it isn't triggered by the setup phase when the chipset is reset. It's basically relying on the fact that the MCU doesn't talk to the servo amp during the read TOC phase, but does as soon as it's finished. Despite (or maybe because of) it's simplicity, this mode works really well.