How to dump your CDROM BIOS (Firmware)

[nocash]

I've had a look at some PCB pics at http://siliconpr0n.org/map/sony/ and found two more undumped chips (if I've deciphered the part numbers correctly):

http://siliconpr0n.org/map/sony/pu-8_1- ... tm_pop.jpg --> "C 2021, SC430911PB" (weird because "C 2021" should be normally "SC430918PB", not "SC430911PB")
http://siliconpr0n.org/map/sony/pu-8_1- ... tm_pop.jpg --> "424688" (already spotted that one on another photo, where the owner said it was from a prototype board or so)

Going by the photos on the siliconpr0n page, it looks as if the chips were desoldered after taking the pictures... so no idea if the chips do still exist & could be still dumped.

[rama3]

I've searched this thread and the download area but I couldn't find a 16.5kB dump of any debug station. The download thread only has one file but it's in .S19 format. Is there a way to make it compatible with No$psx?

Edit: Actually, all the files in .S19 format would be useful to have in simple dump format for use in emulators.
This would allow people to test weird combinations of BIOS and HC05 and see if they fit on a software level.
I'm wondering how a SCPH-9001 HC05 likes a SCPH-1002 BIOS, for example

[wisi]

Tested some PS1 CD commands on a PS2 SCPH-79004 (DECKARD model) in PS1 mode (if there is a hardware PS1 mode at all):
I wasn't sure exactly how commands are supposed to be sent, which may be why the transfer seemed unreliable at times. The other possibility being that I did the tests from patch code in DECKARD, so the code was running ~10 times faster than the original IOP. The CD PS1 mode registers couldn't be accessed before the (PS1) game started to run for some reason - I think it is because some initialization that I skipped (otherwise the known PS1-mode switching actions were all done - like writing to the corresponding CDVD DSP register and remapping the CDVD DSP to the PS1 CD range).
Another odd things was that when the INTerrupt value in 0x1F801803.Index1 would change from 0 to the actual value (on polling), sometimes it would first become one value and only on the second read does it turn to the expected INT value. This may be explained by the PPC running faster and the default method being waiting for interrupt rather than polling the register directly.
Also adding printing of the values written/read from CD registers would cause processing to stall at some point - maybe the added delay from the (bit-banged) serial printing would result in interrupts missed and that disturbed communication.
The test was done by intercepting the very first write to CD registers and executing the test-code then.
Here is what the first few accesses to CD registers look like ("<=" denotes write, while "=>" denotes read):

Code: Select all

 1F801800 <=  00000001  
 1F801803 <=  0000001F   ISR Interrupt Status Register

 1F801800 <=  00000001   
 1F801802 <=  0000001F   IER Interrupt Enable Register

 1F801800 =>  00000019   

 1F801800 <=  00000001   
 1F801803 <=  00000040   clear param FIFO

 1F801800 <=  00000000    
 1F801802 <=  00000000   write to param FIFO params: 0x00, 0x02, 0x04
 1F801802 <=  00000002   
 1F801802 <=  00000004   

 1F801801 <=  00000002   write to CMD reg

 1F801800 =>  00000038   poll command completion maybe

 1F801800 <=  00000001     
 1F801803 =>  000000E7   read ISR

 1F801800 <=  00000001   
 1F801803 <=  00000007   write to ISR to clear interrupt

 1F801800 <=  00000000   
 1F801800 =>  00000038   

 1F801800 <=  00000001   
 1F801803 =>  000000E0   

 1F801800 <=  00000001   
 1F801803 <=  00000007   

 1F801800 <=  00000000   

Commands:
The secret-unlock commands (0x50 - 0x56) do not seem to work - booting an unofficial disk after issuing them causes loading from it to stall. Responses to them are 0x13 0x40 (0x13 is not 0x11, because the motor was on at that time). (Tried with string "Inc." and "(Europe)"). I didn't test if arguments get cleared from the parameter buffer (my test code always sends a command to clear the arguments after each command).
0x19 0x22 Get Region ID String returns "for Japan", which probably explains why the above do not work.
0x19 0x20 Get Version returns: 98 06 11 C3.
There doesn't seem to be any main commands that respond as valid in the range 0x1F - 0xFF.
From the 0x19 sub-commands in the range 0x77 - 0xFF, unlike on the PS1, commands 0x80 - 0x8F seem to be valid: each takes 2 arguments - the sub-command number and another byte, and each always returns a stat byte (0x12) and zeroes (tested both with argument = 0x00 and 0xFF).
0x19 0x60 RAM Read does not work (sadly) - always returns zeroes for the whole range 0x0000 - 0xFFFF, otherwise the command is accepted as valid.

Doing that test on a non-DECKARD PS2 may be more difficult, as the IOP can't have code loaded from before switching to PS1 mode and the EE can't access its memory either in PS1 mode, so the only ways of loading code on the IOP in PS1 mode are by using a modchip or a PS1 disk. *The PS2 TOOL seems to have an option for *disabling* the EE access to IOP memory in PS1 mode so it is possible that early IOP revisions had support for that. There is also no way of exiting PS1 mode on the IOP once it has been entered (on the other hand, the EE can be switched back), but for a reset. The only known way of triggering PS1 mode is through a dedicated reset line, which is controlled by the EE.
The PS1 mode of the CDVD device should* be available in PS2 mode of the IOP, but that hasn't been tested. *The PS1 mode clock should be used in that mode, which may prevent correct communication with the IOP running with the PS2 mode clock.

Any news on reading the CDROM firmware of the DTL-H2000?

[rama3]

0x19 0x22 Get Region ID String returns "for Japan"

A 79004 returns that? It seems odd for a PAL / EU region model.

[nocash]

I am not familar with PS2. What is a DECKARD?

Another odd things was that when the INTerrupt value in 0x1F801803.Index1 would change from 0 to the actual value (on polling), sometimes it would first become one value and only on the second read does it turn to the expected INT value.

You mean like transition from value 0 to 3 shortly showing up as 1 or 2 (ie. one bit appearing a bit earlier)?
Or, wait, your log showed this: "1F801803 => 000000E7 read ISR" - a value of 7 would be very weird.

I've just tested interrupt polling on PSone... there seem to be no such issues (issuing getstat one million times does always transition from 0 to 3 without dirt effects, so the hardware seems to have the value "double buffered", never changing the read value during read cycles).

Would be worth testing if the PS2 works the same (when running in "real PS1" mode (with correct PS1 clock). Some of my code is relying on dirt-free polling, and might run into problems if the PS2 returns dirtier values.

maybe the added delay from the (bit-banged) serial printing would result in interrupts missed and that disturbed communication.

Theoretically the cdrom interrupts should have no timing restrictions and you could read them as slow as you want (unless you are reading/playing from disc, and the hardware tries to fire sector-read INT1's at faster rate than your serial transfer).

The secret-unlock commands (0x50 - 0x56) do not seem to work
0x19 0x22 Get Region ID String returns "for Japan", which probably explains why the above do not work.
0x19 0x20 Get Version returns: 98 06 11 C3.
0x19 0x60 RAM Read does not work

Interesting.
The date/version is one day "newer" than SCPH-750x (but yet much older than later SCPH-900x and SCPH-10x models).
And region "for Japan" does it actually play japanese PS1 discs? And your PS2 isn't actually japanese, right?

From the 0x19 sub-commands in the range 0x77 - 0xFF, unlike on the PS1, commands 0x80 - 0x8F seem to be valid: each takes 2 arguments - the sub-command number and another byte, and each always returns a stat byte (0x12) and zeroes (tested both with argument = 0x00 and 0xFF).

Then you must also say how many zeroes you get (ie. check the response fifo flag while reading the response bytes).

so the only ways of loading code on the IOP in PS1 mode are by using a modchip or a PS1 disk.

Is that a common thing, installing a PS1-compatible modchip in PS2? Or did anybody do that all yet?
Booting code from disc sounds uncomfortable... just an idea: maybe one could make a bootdisk that loads the actual code from Main RAM (if RAM isn't cleared), or otherwise load from memory card or the like. Just to avoid needing to burn new discs on every test.

Any news on reading the CDROM firmware of the DTL-H2000?

Not yet. But, I am just cleaning up the mess in my flat, and to my surprise I've found a 32pin 32Kbyte EPROM in LCC package on my desk, actually it was within sight, located directly next to my monitor ; )
I must have pulled it from some old peripheral device or ISA card some years ago, I am afraid that I've thrown away the pcb/socket where it came from - but I could use the chip to test if it's really that difficult to dump those LCC chips. I hope that a regular PLCC socket with bend pins should work fine.

Apropos. Any news on dumping more retail psx cdrom firmwares? I had hoped that dozens of people would their firmwares... like people implementing it as "my first serial data transfer project" using an arduino or the like... but now it's more than three years and only 3-4 people managed to dump something : /

[Administrator]

Trimesh actually has one of my H2000 EPROM's. He has two. One was blank because I believe he wiped it by mistake, so I sent him another which he hasn't touched yet. Send him a message and ask for it

I don't care if you solder to it. Just dump it so the data is preserved! When you're finished with it, send it back to me though please NO$CASH. My H2000's will not work via CD-ROM without them

[wisi]

0x19 0x22 Get Region ID String returns "for Japan"

A 79004 returns that? It seems odd for a PAL / EU region model.

It is quite normal, especially for the DECKARD-models. They are known to have a universal BOOT ROM and the region-specific settings are read from (the CDVD) EEPROM (if I remember correctly), and then the BOOT ROM region-specific data is emulated by DECKARD. So it is possible that something similar is done with the PS1 MechaCon firmware.

On the PS2 models after SCPH-75000 included, the MIPS-IOP (the CPU of the PS1) is replaced by a PowerPC CPU running around 5-10 times faster, with an emulator called DECKARD running on it, emulating the MIPS-IOP. http://psx-scene.com/forums/f19/deckard ... ost1215472

You mean like transition from value 0 to 3 shortly showing up as 1 or 2 (ie. one bit appearing a bit earlier)?

Yes, but I usually noticed things like: 0 -> 7 -> 3(the expected value). I think it may be because I was sending the commands incorrectly and would receive the response of the previous command and then the response of the next command would overwrite that.

Or, wait, your log showed this: "1F801803 => 000000E7 read ISR" - a value of 7 would be very weird.

This is what the PS1 code (in the BIOS most likely) first does with the CD registers, but the responses (interrupt) may be incorrect, given that the code hangs at the point where the log ends.

Another potential reason for the changing of the interrupt value may be that the reads were done from the PPC-IOP which runs around 5-10 times faster than the MIPS-IOP. The code does this:

Code: Select all

u8 getIsr(void) { *(vu8*)0xBF801800 = 1; return *(vu8*)0xBF801803; }
u8 isr;
do { isr = getIsr(); } while((isr & 0x7) == 0);
u8 newIsr = getIsr(); //here, newIsr sometimes differs from isr.

I don't know (and have not tested) if the DECKARD-PS2 models actually switch to PS1 mode clock or always use the ~36MHz PS2 mode clock, although given that the same CDVD DSP is used in earlier versions where dedicated clock lines are used for each mode, then ~33MHz clock is most likely used in PS1 mode (and my tests were done in that mode).
BTW the PS2 MechaCon uses the ~33MHz PS1 clock always (AFAIK) (even in PS2 mode).

maybe the added delay from the (bit-banged) serial printing would result in interrupts missed and that disturbed communication.

Theoretically the cdrom interrupts should have no timing restrictions and you could read them as slow as you want (unless you are reading/playing from disc, and the hardware tries to fire sector-read INT1's at faster rate than your serial transfer).

The serial transfer takes quite some time. Also I haven't figured-out how DECKARD emulates interrupts: once the PPC-IOP receives an interrupt from the CDVD (CD) DSP, it probably jumps to (emulating) the interrupt handler on the MIPS-IOP, so it might actually interrupt my printing function and result in executing the handler before other PS1 code that was assumed to have already have been executed (because all this happens under the load/store emulation-handler).

And region "for Japan" does it actually play japanese PS1 discs? And your PS2 isn't actually japanese, right?

I have no idea, as I have neither Japanese nor US discs. My PS2 is European and I only have such discs. Maybe somebody with such a PS2 and PS1 discs from other regions can test if it is PS1-region-unlocked.

Then you must also say how many zeroes you get (ie. check the response fifo flag while reading the response bytes).

Strange - the flags in 0xBF801800 do not change even after reading 32 bytes from the FIFO: 0xBF801800 stays at 0x39: response FIFO not-empty. (read it before reading each of the 32 times.) Reading the response does have the expected effect of the data looping every 16 bytes. So wither this flag isn't implemented on the PS2, or my test-code is causing it to act this way.
Although the initial accesses show that it did change:
1F801800 => 00000019
1F801800 => 00000038

Is that a common thing, installing a PS1-compatible modchip in PS2? Or did anybody do that all yet?

I think it has been done already and for PS1 games, PS2 modchips use the same method PS1 modchips use - the SCEX line. I have done that on a SCPH-30003 and it works (with a slightly modified code, that simply outputs the SCEx strings multiple times, but for longer period of time after power-up).

Booting code from disc sounds uncomfortable... just an idea: maybe one could make a bootdisk that loads the actual code from Main RAM (if RAM isn't cleared), or otherwise load from memory card or the like. Just to avoid needing to burn new discs on every test.

Actually, I already made such a thing - a boot-loader on a (PS1) CD that can load code from SIO0 (Controller & MC port). I works on both PS1 and PS2. It requires an external MCU which transfers data between the SPI (PS1/PS2 SIO0) and RS232 (PC) interface. BTW, the PS2 SIO2 (PS2 mode interface of the Controllers and MCs) can be switched to PS1-mode SIO0 and used successfully even in PS2 mode. The SIO1 (serial port at the back of the PS1) isn't known to be available on the PS2 IOP ASIC, though the registers seem to act as they would on a PS1 (though I didn't test much). It could be just a dummy interface.

Apropos. Any news on dumping more retail psx cdrom firmwares? I had hoped that dozens of people would their firmwares... like people implementing it as "my first serial data transfer project" using an arduino or the like... but now it's more than three years and only 3-4 people managed to dump something : /

Maybe all the people who considered doing that, saw that the firmware of their model was already dumped.
It seems to me like there are SCPH-10x firmwares attached in this thread that are missing from the list at: http://www.psxdev.net/forum/viewtopic.php?f=69&t=573 I have a SCPH-102 C but am a bit reluctant to read the firmware, because I don't have another PS1 (not counting the PS2 models ) if this one gets damaged.

BTW the PS2 MechaCon has a test-mode serial interface, which is used for configuring (service mode) the CDVD system and changing the EEPROM data. Next to the lines for that interface there are around three more lines that are according to the datasheet related to programming flash-versions of the chip. It is unknown if they are left-overs from a prototype flash version or if they are related to additional uses of the serial interface.

[rama3]

The odd thing with a PAL machine saying "for Japan" is that it means that the emulated Mechacon has accepted a PAL disc.
This could only happen on a modchiped NTSC-J PSX and would be detectable by PSX software.
For some reason, PSX games never did this though, at least as far as I know. This simple check would have made PSX modchips much harder and some functions impossible.

The real disc authentification happened on the PS2 side, of course. And it happened before the machine went into PSX mode.
That's why a PSX on PS2 modchip still has to output the correct region string as well.

[rama3]

"Mode2: Upload 200h bytes to RAM & jump to 0040h (allows fast/custom dumping)"

I wonder, is the chip fully functional in this self test mode?
If it is, it'd be very interesting if instead of uploading just a small routine, we could upload a full replacement software.
That software would then have to run things, instead of the inaccessible mask rom.
Opens up some nice possibilities

[TriMesh]

"Mode2: Upload 200h bytes to RAM & jump to 0040h (allows fast/custom dumping)"

I wonder, is the chip fully functional in this self test mode?
If it is, it'd be very interesting if instead of uploading just a small routine, we could upload a full replacement software.
That software would then have to run things, instead of the inaccessible mask rom.
Opens up some nice possibilities

The CPU core seems to run normally - the problem is that the only place you can store code is the work RAM, and there is only a few hundred bytes of that as opposed to 16KB of mask ROM. It's hard to see what useful functionality you can get in that little space.

[rama3]

Yeah, that's a serious limitation.
Definitely rules out using a hacked original software this way.

Do you think the RAM is enough to establish 2 way communication with an external MCU?
It would also have to read and control each of the used I/O.

[TriMesh]

Yeah, that's a serious limitation.
Definitely rules out using a hacked original software this way.

Do you think the RAM is enough to establish 2 way communication with an external MCU?
It would also have to read and control each of the used I/O.

Maybe, but you would need some pretty fast IO to be able to pass the processing off to an external chip - some of it is very time-sensitive. The other problem is that some of the lines you need to tie into specific states to enter the test mode are used in normal operation, so you would also need a circuit to handle that.

Honestly, I think it would be simpler to just remove the HC05 entirely and replace it with something else. Recreating all the code would be a significant amount of work, though. If you used something like an ARM Cortex M then you could probably get away with writing it in C rather than assembler.

[Orion_]

Apropos. Any news on dumping more retail psx cdrom firmwares? I had hoped that dozens of people would their firmwares... like people implementing it as "my first serial data transfer project" using an arduino or the like... but now it's more than three years and only 3-4 people managed to dump something : /

I guess it's because there is no "easy way" to do it, I would gladly try to dump my Net Yaroze CD firmware, but even if I have an arduino and a soldering iron, I'm not that good at doing electronics, and there is no simple schematics on how to do it, nor arduino software already written.
I read your dumper software readme, but it's not easy to set up.
I will try it hopefully in some weeks, but I hope I won't mess up my Net Yaroze, and knowing my success rate at doing working electronics stuff, I'm not very motivated to try, because I know that it will fail 90% of times I try

[TriMesh]

Apropos. Any news on dumping more retail psx cdrom firmwares? I had hoped that dozens of people would their firmwares... like people implementing it as "my first serial data transfer project" using an arduino or the like... but now it's more than three years and only 3-4 people managed to dump something : /

I guess it's because there is no "easy way" to do it, I would gladly try to dump my Net Yaroze CD firmware, but even if I have an arduino and a soldering iron, I'm not that good at doing electronics, and there is no simple schematics on how to do it, nor arduino software already written.
I read your dumper software readme, but it's not easy to set up.
I will try it hopefully in some weeks, but I hope I won't mess up my Net Yaroze, and knowing my success rate at doing working electronics stuff, I'm not very motivated to try, because I know that it will fail 90% of times I try

It's not especially complicated - the biggest issue is that you have to connect pin 31 of the mechacon to +7.5V to force the test mode, and that pin is also connected to the CD DSP, which was never designed to have 7.5V on it's IO pins.

Since I don't like cutting traces, I would recommend lifting pin 74 on the CXD2545Q CD DSP - firstly because it's a longer lead and secondly because even if you end up damaging it you can get a replacement chip from any machine with a PU-8 board in it, unlike the mechacon which is only used in PAL Yarozes.

[Orion_]

ok so it took me about one hour but I eventually got something (after wiring GND from the PSX to GND from the Arduino, else I only got 0xFFs)
But the 3 dumps I got are all different ..
I used my Arduino Uno, but since it only have 2Kbytes of RAM, I can't store the entire CD bios into the RAM, so I need to transmit the data to the PC while getting the data from the PSX.
I used the Software serial library from Arduino to get the data from PSX and the normal Serial to send data to the PC
Here is the beginning of the dump I got (and I get only 5kbytes of data in total, the rest is just 0xFFs, so, something must be wrong ...)


Here is my Arduino program:

Code: Select all

#include <SoftwareSerial.h>

unsigned char DumpPrg[] = {
0xCC,0x01,0x95,0x50,0x53,0x58,0x20,0x43,0x44,0x52,0x4F,0x4D,0x20,0x42,0x49,0x4F,
0x53,0x20,0x44,0x55,0x4D,0x50,0x45,0x52,0x20,0x2D,0x2D,0x2B,0x2B,0x2D,0x2D,0x20,
0x4E,0x4F,0x43,0x41,0x53,0x48,0x20,0x33,0x30,0x20,0x41,0x50,0x52,0x20,0x32,0x30,
0x31,0x34,0x20,0x2B,0x2B,0x2B,0x2B,0x2B,0x2B,0x2B,0x2B,0x2B,0x2B,0x2B,0x2B,0x2B,
0x2B,0x2B,0x2B,0x00,0xC7,0x00,0x8A,0x3F,0x8B,0xC6,0x12,0x34,0xCD,0x01,0x16,0x3C,
0x8B,0x26,0xF6,0x3C,0x8A,0x5A,0x26,0xF1,0x81,0xC7,0x00,0xA0,0xCF,0x00,0xA1,0xC3,
0x12,0x34,0x26,0x0D,0x5C,0x26,0xF5,0x4C,0xA1,0x10,0x27,0x04,0xA1,0xFE,0x26,0xE9,
0x81,0xAE,0x0F,0x6F,0x73,0x5A,0x2A,0xFB,0x81,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x02,0x05,0xFD,0xAD,0x34,0x4F,0x99,0x25,0x03,0x02,0x05,0x00,0xAD,0x29,0x9D,0x46,
0x24,0xF5,0x03,0x05,0x00,0x81,0xB7,0x83,0xCB,0x02,0x3F,0xC7,0x02,0x3F,0x4F,0xC9,
0x02,0x3E,0xC7,0x02,0x3E,0xB6,0x83,0x99,0x9D,0x11,0x05,0x21,0xFE,0xAD,0x08,0x46,
0x24,0xF6,0x98,0x10,0x05,0x26,0xF6,0xAD,0x00,0xAD,0x00,0xAD,0x00,0xAD,0x00,0x81,
0x5F,0xE6,0x40,0xAD,0xD1,0x5C,0x26,0xF9,0xD6,0x01,0x40,0xAD,0xC9,0x5C,0x26,0xF8,
0x81,0x5F,0xF6,0x5A,0x5C,0xAD,0xBF,0x5C,0xA3,0x40,0x26,0xF6,0x81,0x5F,0xF6,0xA5,
0x00,0xAD,0xB3,0x5C,0xA3,0x40,0x26,0xF6,0x81,0x5F,0x10,0x3E,0xF6,0x5A,0x5C,0x11,
0x3E,0xAD,0xA3,0x5C,0xA3,0x40,0x26,0xF2,0x81,0x5F,0x10,0x3E,0xF6,0xA5,0x00,0x11,
0x3E,0xAD,0x93,0x5C,0xA3,0x40,0x26,0xF2,0x81,0xAE,0x00,0xE6,0x43,0xAD,0x87,0x5C,
0xA3,0x40,0x26,0xF7,0x81,0x9C,0xCD,0x01,0x89,0xA6,0x02,0xAE,0x40,0xBD,0x99,0xA6,
0x50,0xAE,0x00,0xBD,0x99,0xA6,0x10,0xAE,0x40,0xBD,0x84,0xA6,0xFE,0xAE,0x02,0xBD,
0x84,0xCD,0x01,0x40,0xCD,0x01,0x51,0xCD,0x01,0x5D,0xCD,0x01,0x69,0xCD,0x01,0x79,
0x20,0xFE,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};

SoftwareSerial mySerial(2, 3); // RX, TX

void setup()
{
  int  i;

  Serial.begin(9600);
  Serial.println("Power Up PSX !");
  digitalWrite(3, HIGH);
  delay(4000);
  Serial.println("Sending Dumping Program");
  mySerial.begin(9600);
  for (i = 0; i < 0x200; i++)
    mySerial.write(DumpPrg[i]);
  Serial.println("Reading BIOS Dump");
  for (i = 0; i < 0x4540; i++)
  {
    Serial.print(mySerial.read(),HEX);
  }
  Serial.println("done");
    Serial.println("done");
}

void loop()
{
}

I verified my soldering and it's all good, no short circuit, I just wired the 7.5v to the 8V from the Power connector of the board, and 3.5V to the 3.5v from the Power connector of the board too.
And I lifted the CXD Pin 74


In other words, definitely not easy to do a dump if you are not an experienced coder and electronic hacker

[TriMesh]

I will dig out my Arduino and see if I can find out what the problem is - my guess is that serial.print() is blocking long enough to miss the start bits coming out of the PSX and the code needs some buffers.

[rama3]

You may also want to remove the modchip connection for dumping. It may interfere.

[Orion_]

You may also want to remove the modchip connection for dumping. It may interfere.

I have no modchip in my net yaroze.

I will dig out my Arduino and see if I can find out what the problem is - my guess is that serial.print() is blocking long enough to miss the start bits coming out of the PSX and the code needs some buffers.

Maybe I could dump the data in multiple part, but if it's 16k that would need 8 transfers at least which is not very practical ...

[TriMesh]

You may also want to remove the modchip connection for dumping. It may interfere.

I have no modchip in my net yaroze.

I will dig out my Arduino and see if I can find out what the problem is - my guess is that serial.print() is blocking long enough to miss the start bits coming out of the PSX and the code needs some buffers.

Maybe I could dump the data in multiple part, but if it's 16k that would need 8 transfers at least which is not very practical ...

One thing you could try is increasing the speed of the hardware serial so the code never has to wait for it for too long. Basically, change Serial.begin(9600); to something like Serial.begin(115200); this should result in the code spending much more of it's time running the software serial.

[Myria]

I still want to get my SCPH-7000W dumped. Who could I send it to? Alternatively, if you tell me how to solder something to it I could do it. I don't know how to program chips to do dumping, though; I'm a software reverse engineer, not hardware unfortunately >.<

Are the Yarozes still undumped? The firmware archive on the first page of the thread seems old.

I have:
SCPH-5501
SCPH-7501
SCPH-5903
SCPH-7000W (midnight blue worldwide)
DTL-H3000
DTL-H1002
DTL-H1101
DTL-H1200