looking for mm3 diagrams for scph-1001

I'm pretty sure that Mayumi 2.1 doesn't give 100% stealth on PU-8, either - in fact, I think Spyro is, again, one of the games it has problems with.

I wonder what else we could try - Mayumi 4.0 won't work on PU-7/PU-8 because the clock is wrong (4.00MHz rather than the 4.2336MHz that PU-18 and later use).

I guess we could compare the boot timing and see what's being done differently between PU-8 and PU-18.

 

Just a thought - isn't it possible to change the clock (by replacing it)with one from a PU-18 board?

 

You can't actually replace the clock - it's the signal that's used to run the mechacon CPU, and all the timing will break if it's at the wrong frequency. The basic design change is that PU-7 and PU-8 had a separate 4MHz xtal that just ran the mechacon chip - on PU-18 and later, it's derived from the CD DSP (hence the odd frequency - it's 96 times the CD audio sampling rate) - on the PU-18, this signal is output on pin 68 (FSOF) of the CXD2545Q CD DSP chip - but the PU-8 uses a different CD DSP chip and doesn't appear to have any suitable clock output on it.

The closest thing I've found is HCLK on pin 81 of the CXD1815 CD interface chip - but this is 8.4672MHz, so it will need to be divided by 2 before you can drive the PIC from it.

I guess that might be OK for testing, although it requires some extra parts.

Edit:

And I just realized that my tests were invalid, anyway - this board has a PAL BIOS on it, and some of the later games (like Spyro) have modchip detection code that disables itself when run on a PAL console...

 

Trimesh, sorry to hijack a two month dead thread but I just tried your alternative MM3 wiring diagram on one of my SCPH-1002 consoles and am happy to report it has better stealth support! The 'official' diagram doesn't support stealth. I just tried with a burned copy of Dino Crisis that fomerly came up with a japanese "console modified" warning and now fully works when the MM3 mod is fitted your way. I'm yet to try other anti-mod games but I am really impressed! I am now in the process of opening up my other SCPH-1002 and 1001 models to rewire them as well!

 

Good work, this is good news to get MM3's stealth on 100x... even if it is only partial stealth.

 

I recently came across a bare Net Yaroze console on Yahoo Auctions for cheap- a DTL-H3001. No cables, cards or discs included. The PSU had already been swapped out from a 120V to a 240V so I thought, oh well, it's been opened, the damage has been done. From what I know of the Net Yaroze, it can accept SCEE, SCEI, SCEA and SCEW as a valid region code. SCEW is a unique region code for the Net Yaroze, presumably to allow Sony to publish discs that would not work on an any retail unmodified console unless it was a Net Yaroze. I took the MM3 USA HEX code and modified it to output "SCEW" instead of "SCEA" and burnt it onto a chip with a PIC Programmer. Then I used the diagram in this thread to solder it in. It's a PU8 board just like the SCPH-1001 and 1002 but with both oscillators for NTSC and PAL output factory installed, plus of course additional RAM. Tested with an NTSC disc of Dino Crisis, chip not detected. I've tried with a genuine NTSC disc of Spyro Year of the Dragon, chip not detected! Tested with backed up copies of the PAL versions. Again, nothing detects the chip! Eureka! So now I have a machine capable of both PAL and NTSC video output (without needing to bother with an RGB cable) with full stealth. Not the way most people would want to try with a rare piece of kit but not bad for me considering it was sold as "junk" and it was a gamble anyway. I'm not sure how this has worked, but I think it might be something to do with the fact that the CD Controller returns four empty spaces to the main CPU for "region check" when unlocked with SCEW, causing the boot screen to no longer have the SCEA text. In other words, it behaves more like a debug console. From what I've read on various websites, anti-mod games ask the CD Controller how many times it has received valid region codes beginning with "SCE". Four empty spaces does not equal "SCEx" so it passes the check, I'm guessing.
Thought I'd post this here incase anyone else was thinking of trying this.

 

Interesting experiment - I guess it's possible the modchip detection code disables itself on a debug console in the same way it does on the PAL machines. I need to do some more testing on this - I got a SCPH-1001 from one of my friends a while back, and I was intending to see if I could find out why games like Spyro trigger the mod detection on it, but I haven't got around to it yet.

Incidentally, the Yaroze (and the debugs) have 2MB of RAM, just like a retail console. The only things that had 8MB were the devboards (DTL-H2000, DTL-H2500 and DTL-H2700).

 

That is very interesting, and a rather clever way to get it happening! One question though, do you get the PS logo boot screen with this mod? If I get to mod a Japanese launch model PS and still get that sweet PS logo boot screen (BWAAAAAAAN DO DE DOODLE DOOO....) that'd be awesome since that's one thing that breaks when you try and mod a Japanese launch model PS with a normal modchip. Would save me from having to get a NTSC-U or PAL launch model.

 

Unfortunately, it won't help - the earliest Japanese PSX with a PU-8 in it was the SCPH-3000, and they (like all the later versions) don't boot imports at all.

I did look at patching the SCPH-1000 BIOS so that it would still display that license screen even if the territory data didn't match, but never got far. I should have a look at it again.\