How to dump your CDROM BIOS (Firmware)

[nocash]

Download the CD-ROM Firmware Dumps

I've dumped the PSone/PAL CDROM controller BIOS last night, CRC32=2669A1A7h for the 16.5Kbyte ROM-image (IC304 52pin, chip name: "C 3060, SC430943PB, G63C 185, SS0L0130E").
That's been done using Motorola's build-in self-dumping function.

The way how to enter the selftest mode was more or less described in HC05 datasheets (which were a bit unclear since some sections suggested pulling PortC.7 to 2xVCC, and others said PortC.6, which made me feel uneasy, since one should probably avoid strapping the wrong pin to +7V) (anyways, it turned out to be C.7, aka Pin31).
And the datasheet contained some weird drawing that looked like a distorted timing diagram (which turned out to be totally meaningless, the PortC pins can be constant before+during+after /RESET).

The actual data transfer protocol wasn't documented in datasheets, but the decapped PSX/NTSC cdrom controller revealed it's inner workings. The PSone is using identical protocol (with same baudrate constants, ie. older PSX with 4.000MHz oscillator would transfer data at 9600 baud, and PSone transfers data at 10000 baud (apparently derived from around 4.19MHz clock source). The selfdump function is sending data in ASCII format, including spaces and linebreaks and 4-digit address for each byte, plus a request/echo pair for each byte - that looks nice when seeing the data arrive for the first time - but it's also endless slow (in total it takes around 130 bits per byte (ie. around 15 minutes to dump the whole 64Kbytes address space).

For error checking purposes, I've dumped it four times, which was really time consuming. Though there's also a upload & execute custom code function, that way one could transfer bytes in 10bits, and possibly even using something faster than 10000 baud. Maybe it'd be worth writing a custom highspeed dumping function (the programming efforts can't be more time consuming than using the original selfdump function).

The soldering stuff is relative simple & relative difficult: Basically one does need only four wires connected to the chip (two constant voltages: Pin17=3.5V, Pin31=7.5V, and two data lines: Pin50=TX and Pin51=RX with 3.5V levels each). It's a bit challenging because the SMD chip is having really tiny pins, and no solder pads/test points on PSone boards. I ended up using some strings pulled from a flexible wire, attaching that hair-fine strings to the chip, and then connected normal/bigger wires to the strings - and tried to stop breathing and moving... nonetheless I broke some connections 1-2 times. But anyways, after all, it did work fine!

Hope some people will dump some more cdrom bioses! There are probably around 20 different versions (at least five revisions, for each of the three regions, plus devrs versions). I can supply more info on the wiring (basicially that's just the above 4 pins), and on the protocol/software. Of course, the actual implemention depends on what hardware you are using to receive the data (=something that supports serial RX/TX at 3.5V levels).

My approach has been connecting the 3.5V signals to the controller port of another PSone, and then forwarding it to my PC's COM port at +/-9V RS232 levels (don't ask why, it was just the some hardware that I did have at hand).
PS. Should be recommended to lift that Pin31 before wiring 7.5V to it (if you don't: the MIPS CPU refuses to run, and the power LED glows double bright, that sweet effect doesn't affect dumping, but it might damage some other cdrom components, who knows).

[Shadow]

I'll dump some of mine when I get around to it.

I also still need a DTL-H2010 drive to dump its contents.
I've contacted ASSEMbler as I know he has lots of them, but he is useless sorry to say.

[nocash]

Next one dumped: SCPH-1002, PAL, PCB: LATE PU-8 (1-658-467-22)
IC304 52pin "C 3021, SC430917PB, G63C 185, JSAF9623G" - 16.5K ROM CRC32=96A79014h

It's pretty much same as the dump from the psxdev.ru decapping project. Only differences are region specific:
The obvious ones are: Different SCEx string, different Secret Unlock string, different region ID string.
And, the unused "Sony Computer Entertainment of America" string near end of the ROM has also changed to "(Europe)" instead of "of America". Plus two changed bytes at FFDAh/FFDFh, which are probably checksums on the main ROM and/or on the exception vectors.

That dump was really easy. This time I did already knew which pins I needed to connect the wires to, and the PU-8 board has nice test points for all signals, and even better: Pin31 goes to a test point, and then to via (so one can just cut that connection without needing to lift Pin31, and later repair it by adding a new wire between the test point and the via).

And, this time I've really used a custom dumping function, which is about 13 times faster (or 50 times faster when dumping only the ROM region, and just verifying the open-bus region; instead of actually transferring that garbage - though that verification does still fail, I'll need to check more there).

The speed is a huge difference. For the PSone dump I left the room and ate something or smoked a cigarette, and it still wasn't ready when I came back ; -( with the custom code it's more fun to sit there and watch how the data arrives : -) I'll clean up the code a little and probably upload the custom dumper tomorrow.

Aside from speed, the other advantages are that the custom code does really need only 4 wires connected to the chip (the official selfdump needed one more pin pulled to 3.5V), and the protocol is easier, too: Just send 200h bytes (containing the custom dumping function), then receive 4540h bytes (containing a short ASCII string, and dumps for the 16.5K ROM and RAM and I/O ports).

PS.
I've also emulated the low-level CDROM hardware last week - with HC05 CPU, SignalProcessor, Servo Amplifier, Decoder, SCEx signal, Sled motor, etc. Works fine with the SCPH-1000/1002 dumps (but isn't released yet). For the PSone dump it might be more difficult to get it emulated...
Surprisingly, it looks as if the PSone doesn't have SCEx signal wired to the HC05. Instead, the SCEx string seems to be squeezed somehow through the SUB-Q bus, apparently encrypted/bit-shuffled, and somehow also using random numbers in the transmission.
That explains why later mod-chips seem to be connected to some sort of analog cdrom signals, instead of directly connecting them to the HC05 chip.

[nocash]

And the last one from my hardware collection dumped SCPH-5502, PAL, PCB: PU-18 (1-664-537-62)
52-pin "C 3030, SC430929PB, G63C 185, JSBH9716A" CRC32=BA87A3E0h
Credits to Tomas Petto for donating the SCPH-1002 and SCPH-5502.

The PU-18 board did have nice solder pads, too. Only the SCOR pin (Pin31) was a bit difficult (the wire was hidden underneath of the chip, so it wasn't possible to see where it went to) (turned out to reappear between Pin26/Pin27, and then went to a nice solder pad, and onwards to a via near SONY CXD2545Q pin74, knowing that, it was easy to dump, too).

Oh, and PU-18's test mode is using 10000 baud, too. Ie. 9600 baud seems to be used only for PU-7 and PU-8. And all later boards should use 10000 baud.

Still don't know what [FFDAh] is, maybe it's really a checksum, or maybe not. But figured out the meaning of the three bytes at [FFDDh..FFDFh]: They containing the chip's "SCxxxxxxPB" part number, ie. 43h,09h,29h for the "C 3030, SC430929PB" chip. The first two bytes seem to be always 43h,09h, and the last byte seems to increase chronologically for different revisions (including increasing for different regions).

One thing that I've learned yesterday: Avoid lifting pins on 52-pin chip! (I wanted to run the new dumping code on the PSone, and the lifted pin instantly broke off beyond repair before I could even start dumping, grmm. Luckily I already dumped that chip on the previous day).
If possible, locate the SCOR signal on the PCB, and cut that wire (preferably between two vias or solder pads) instead of lifting the SCOR pin.

[nocash]

Here's the custom dumping function:

Dumper.zip

512-bytes binary with source code.

Code: Select all

How to dump the CDROM SUB-CPU BIOS from your PSX/PSone console:

                            .------------ pin31, SCOR, cut the connection
                   39       |   27               to Signal Processor,
                 .-----------------.             then wire Pin31 to 7.5V
              40 |                 | 26
                 |  C 30xx         |
                 |  SC4309xxPB     |
                 |  G63C 185       |
  pin50, TX <--- |                 | ---- pin17, SCEX, wire to 3.5V
  pin51, RX ---> |                 |
              52 | O               | 14
                 '-----------------'
                   1            13

Good places to pick 3.5V and 7.5V from nice solder pads are:
  CN602.Pin1  = 7.5V     ;\on PSX boards (with either 5pin or
  CN602.Pin3  = 3.5V     ;/               7pin CN602 connectors)
  IC601.Pin1  = 7.5V     ;-on PSone boards (3pin 78M05 voltage regulator)
  IC102.Pin32 = 3.5V     ;-on PSone boards (32pin Main BIOS ROM chip)
The SCOR trace on Pin31, connects to Signal Processor...
  CXD2510Q.Pin63  (eg. on PU-8 boards)   ;\either one of these, depending
  CXD2545Q.Pin74  (eg. on PU-18 boards)  ; on which chipset you have
  CXD2938Q.Pin77  (eg. on PM-41 boards)  ;/
cut that trace (preferably on the PCB between two vias or test points, so
you can later repair it easily) (better don't try to lift Pin31, it breaks
off easily)

Dumping Program Usage:
  Connect the four wires to the chip (and also connect GND to your computer)
  Init baudrate to 9600bps for PU-8, or 10000bps for PU-18 and newer
  Init 8-N-1 (1 startbit(0), 8 databits LSB first, no parity, 1 stopbit(1))
  Output 1 (high) to the RX line (=no startbit yet)
  Power-up the PSX, and eventually wait 1-2 seconds
  Send 200h bytes to the chip's RX line (from the DUMPER.BIN file)
  Receive 4540h bytes from the chip's TX line
  Write down chip name/pins (eg. C 30xx, SC4309xxPB, G63C 185, JSAFyymmG, 52pin)
  Write down console and PCB names (eg. SCPH-1002, PU-8, 1-658-467-22)
  Done.

Notes
  Also required: Pin16=Low, and Pin30=High (but that should be so anyways).
  PU-7 and Early-PU-8 have 80pin chips (instead of 52pin) pinouts are unknown.

[Shadow]

So we solder up to it and then send the binary over Rx using Hyper Terminal or something?

[nocash]

Yes, something. Above package covers only the PSX side. There's no software included for the opposite side, since I've no clue what hardware you have... you could use a PC, a PSX, a handheld console, a modded mp3 player, or whatever suitable hardware you might have.

PC with serial COM port might be best & most common solution (for the old regular COM ports you'll need voltage conversion, though in past some years 'low voltage' COM ports seem to have also showed up for direct use with 3.5V signals).

Don't know if hyperterminal can send binary data from files, I thought that it's only send data you type on the keyboard. But with some luck you could probably use some standard tools, like MS DOS "copy /b" command to send/receive data.
Anyways, I would recommend to write a small program that initializes the com port, waits for keystroke (until you have powered on the psx), and then sends 200h bytes, and then receives the 4540h bytes.

[nocash]

80-pin chips: The pinout is probably same as in MC68HC05L16 datasheet (best compare some pins like supply and OSC to be sure). It does support selftest mode via the IRQ1+IRQ2 pins, too. For the mode selection, one may assume that it's using Port B bit0+1, too. The only challenging part would be finding the RX+TX pins (normally on Port F, but the MC68HC05L16 doesn't have that port, so it must use some other pins). Best approach here should be to wire both Port B pins to 3.5V (selecting the slow built-in dumping mode instead of custum upload mode), in that state it should automatically send ASCII strings on TX pin (provided that RX is low - just hope that that is the case - that'll make it believe to receive starts bits and character 00h, so it'll send out more than one ASCII string). Ie.
- Wire Pin31 (PB0), and Pin32 (PB1), and Pin45 (PC6/IRQ2) to 3.5V
- Disconnect Pin46 (PC7/IRQ1), then wire it to to 7.5V
- Find the TX line (should send 9600 baud ascii, with longer HIGH-then-LOW periods after around each 13 characters).
I hope that it's that simple! Otherwise one could mess around with the EPROM version on DTL-H2000 boards to learn more about the chip.

32-pin chips: That's a bit offtopic, but I just noticed that Sony digital joypads use 32pin Motorola SC401800 chips, which might be MC68HC05xxx chips, too. Does anybody know the dimensions & package name of that SC401800 chip?
That'd help to find its datasheet, and figure out if/how it is supporting the selftest mode, too.
EDIT: I've measured it myself: It's square plastic package 7x7mm, with four rows/columns of 8 pins each, and pin-pitch is around 0.77mm (or maybe 0.8mm) - so the package should be "TQFP-32". But I've failed to find any matching datasheet.
Sony's PSX Mouse does also contain a similar 32pin chip, SC442116. And http://nkmm.org/yagura/lib/ tells that newer SCPH-1080 digital pads contain Motolora SC438001 chips. My own SCPH-1080 is having an old SC401800 chip though, with pinouts as so: http://nocash.emubase.de/psx-spx.htm#pi ... italjoypad

cdrom bios versions: The "xx" in the SC4309xx part numbers seems to be BCD, and last known number is 49, so there are probably not more than 49 versions. Maybe less in case some numbers were skipped... or maybe more in case the old 80pin chips used different numbering. There must be at least 6 revisions (for 3 regions each), plus whatever region free devrs versions. So there must be at least around 25 versions. Some of them might be quite rare: Japan is quite small (compared to continents like europe, asia, america), and some pcbs/chips seem to have been in production only for short periods (like PU-7, OLDER-PU-8, and PU-20, PU-22, PM-41(2)).
For PAL, the dumped versions are those from 24 Jul 1995, 10 Jan 1997, and 01 Feb 1999. Known missing PAL versions are:
- Whatever version was used before 1995 (ie. on PU-7 boards, and maybe on OLD-PU-8 boards)
- The version from 10 Jul 1998 (might exist on PU-20 or PU-22 boards) (the date is known from SCPH-9903).
- Whatever version that was used after 1999 (ie. on PM-41(2) boards)
For Japan, there's nothing dumped yet, same for DTL-H consoles/dev boards, and for U/C there's the dump from the decapped chip, dated 24 Jul 1995, but I don't know where it came from exactly (I am afraid that the chip name was destroyed during decapping), so it would be nice to get that one dumped another time, too.

[TriMesh]

This looks interesting - I've just had a look at the machines I have here, and the oldest one is a SCPH-1000 with a 1-655-322-11 PU-7 board in it. I will see if it dumps.

For reference, the CD CPU on this board doesn't have one of those "SC" numbers on it. The markings are as follows;

Sony Computer
Entertaiment
Inc. (C) E35D
424666 185
SSAD9441D

I assume the "9441" in the last line is the date code, so this chip is presumably the first retail revision, since that was before the console launch date. Another later board I have here (with a -13 suffix) has the following chip markings:

Sony Computer
Entertaiment
Inc. (C) E35D
424660 185
SSAK9502A

Not sure what the 6 digit code is, or why the newer chip has a lower number in that position.

I'll let you know how it goes.

Edit:

First results are not very helpful.

I can confirm that applying 2xVdd to PC6 (pin 45) and Vdd to PC7 (pin 46) and asserting reset seems to cause a transition to test mode - or at least stops the CPU from entering it's normal operating mode. However, when I tried grounding PB0 and PB1 (pins 31 and 32) there was no sign of any serial data on any of the output pins, even just after reset, although there were a number of pins that were pulled high that had not been high in the normal operating mode.

These tests don't appear to have caused any hardware damage, though.

[nocash]

Grounding PB0 and PB1 shouldn't output any serial data! Better try to wire both PB0 and PB1 to 3.5V.

If you are lucky (=if RX is low) then you should see serial TX data on one pin.

Otherwise you could try to drag RX to GND while searching the TX pin. Ie. while looking for TX at pin number "N", try to drag pin "N-1" or "N+1" to GND. Of course, don't do that on pins that are wired to 3.5V or 7.5V.

EDIT: Did you say "2xVdd to PC6 (pin 45) and Vdd to PC7 (pin 46)"? Theoretically, they should be vice-versa.

Btw. here's some summary about the test modes...

Code: Select all

CDROM Internal HC05 Motorola Selftest Mode
------------------------------------------

Motorola Bootstrap ROM
The Motorola MC68HC05 chips are including a small bootstrap ROM which gets
activated upon /RESET when having two pins strapped to following levels:
  PortC.6 (/IRQ2) ----> wire to 3.5V (VCC)
  PortC.7 (/IRQ1) ----> wire to 7V (2xVCC)
Moreover, two pins are needed for selecting a specific test mode:
  PortB.0 ----> ModeSelectBit0 (0=GND, 1=3.5V)
  PortB.1 ----> ModeSelectBit1 (0=GND, 1=3.5V)
The selectable four modes are:
  Mode0: Jump to RAM Address 0040h (useless when RAM is empty)
  Mode1: Semifunctional Selftest (useless)
  Mode2: Upload 200h bytes to RAM & jump to 0040h (allows fast/custom dumping)
  Mode3: Download ROM as ASCII hexdump (nice, but very slow)
The upload/download functions are using following additional pins:
  PortF.0  ---> TX output (11bytes: 0Dh,0Ah," AAAA DD ")
  PortF.1  <--- RX input  (1byte: "!" to request next 11 bytes)
  PortF.2  ---> RTS output or so (not needed)
  PortF.3  ---> DTR output or so (not needed)
  Ground   ---- GND for RX/TX
RX/TX are RS232-like serial signals (but using other voltages, 0=0V and
1=3.5V). Transfer format is 8-N-1, ie. one startbit(0), 8 databits LSB first,
no parity, one stopbit(1). Baudrate is OSC/2/208 (ie. 9616 bps for 4.000MHz, or
10176 bps for 4.2336MHz clock derived from CXD2545Q/CXD2938Q).
Note: Above pins may vary on some chips (namely on chips that don't have
PortF). The pins for entering bootstrap mode (PortC in this case) should be
described in datasheets; but transfer protocol and mode selection (PortB) and
transmission (PortF) aren't officially documented.

Mode2: Upload 200h bytes to RAM & jump to 0040h
This mode is very simple and powerful: After /RESET, you send 200h bytes to the
RX input (without any response on TX output), the bytes are stored at
0040h..023Fh in RAM, and the chip jumps to 0040h after transferring the last
byte. The uploaded program can contain a custum highspeed dumping function, or
perform hardware tests, etc. A custom dumping function for PSX/PSone can be
found at:
  http://www.psxdev.net/forum/viewtopic.php?f=70&t=557
After uploading the 200h-byte dumping function it will respond by send 4540h
bytes (containing some ASCII string, the 16.5Kbyte ROM image, plus dumps for
RAM and (banked) I/O port region, plus openbus tests for unused memory and I/O
regions.

Wiring for Mode2 on PSX/PSone consoles with 52-pin HC05 chips
                            .------------ pin31, PC7, SCOR, cut the connection
                   39       |   27               to Signal Processor,
                 .-----------------.             then wire Pin31 to 7.5V
              40 |                 | 26
                 |  C 30xx         |
                 |  SC4309xxPB     |
                 |  G63C 185       |
  pin50, TX <--- |                 | ---- pin17, PB1, SCEX, wire to 3.5V,
  pin51, RX ---> |                 |                  for Mode2 Selection
              52 | O               | 14
                 '-----------------'
                   1            13
Good places to pick 3.5V and 7.5V from nice solder pads are:
  CN602.Pin1  = 7.5V     ;\on PSX boards (with either 5pin or
  CN602.Pin3  = 3.5V     ;/               7pin CN602 connectors)
  IC601.Pin1  = 7.5V     ;-on PSone boards (3pin 78M05 voltage regulator)
  IC102.Pin32 = 3.5V     ;-on PSone boards (32pin Main BIOS ROM chip)
The SCOR trace on Pin31, connects to Signal Processor...
  CXD2510Q.Pin63  (eg. on PU-8 boards)   ;\either one of these, depending
  CXD2545Q.Pin74  (eg. on PU-18 boards)  ; on which chipset you have
  CXD2938Q.Pin77  (eg. on PM-41 boards)  ;/
cut that trace (preferably on the PCB between two vias or test points, so you
can later repair it easily) (better don't try to lift Pin31, it breaks off
easily)
Note: Mode2 also requires Pin16=Low, and Pin30=High (but PSX/PSone boards
should have those pins at that voltages anyways).

Wiring for Mode2 on PSX/PSone consoles with 80-pin HC05 chips
PU-7 and Early-PU-8 have 80pin chips (instead of 52pin), the chip pinouts are
probably same as in MC68HC05L16 datasheet, the chip does support bootstrap
mode, but unknown which pins are used for RX/TX (since that chip doesn't have
PortF).

Wiring for Mode2 on PSX/PSone digital joypad/mouse with 32-pin HC05 chips
Sony's Digital Joypad and Mouse are using 32pin chips (with TQFP-32 package),
which are probably containing Motorola HC05 CPUs, too. Unknown if/how those
chips can be switched into bootstrap/dumping modes.

Mode3: Download ROM as ASCII hexdump
This mode is very slow and not too powerful. But it may useful if you can't get
Mode2 working for whatever reason. Wiring for Mode3 is same as above, plus
PortB.0=3.5V. In this mode, the chip will send one 0Dh,0Ah," AAAA DD " string
immediately after /RESET (with 16bit address "AAAA" (initially 1000h), and 8bit
data "DD"). Thereafter the chip will wait for incoming commands:
  4-digit ASCII HEX address --> change address, and return 0Dh,0Ah," AAAA DD "
  chr(00h) --> increment address, and return 0Dh,0Ah," AAAA DD "
  chr(07h) --> jump to current address (not so useful)
  other characters --> same as chr(00h)
  All digits/characters sent to RX input will produce an echo on TX output.
Basic setup would be wiring RX to GND (the chip will treat that as infinite
stream of start bits with chr(00h), so it will respond by sending data from
increasing addresses automatically; the increment wraps from 4FFFh to FE00h
(skipping the gap between Main ROM and Bootstrap ROM), and also wraps from
FFFFh to 0000h; transfer is ultraslow: 13 characters needed per dumped byte:
chr(00h) to chip, chr(00h) echo from chip, and 0Dh,0Ah," AAAA DD " from chip.

[TriMesh]

Grounding PB0 and PB1 shouldn't output any serial data! Better try to wire both PB0 and PB1 to 3.5V.

If you are lucky (=if RX is low) then you should see serial TX data on one pin.

Otherwise you could try to drag RX to GND while searching the TX pin. Ie. while looking for TX at pin number "N", try to drag pin "N-1" or "N+1" to GND. Of course, don't do that on pins that are wired to 3.5V or 7.5V.

EDIT: Did you say "2xVdd to PC6 (pin 45) and Vdd to PC7 (pin 46)"? Theoretically, they should be vice-versa.

Btw. here's some summary about the test modes...

Thanks for the info - although I don't think the test ROM in the old chips is the same.

I just checked again, and the chip in the PU-7 definitely needs Vtst on PC6 - if you hook it up with the 7.5V on PC7, then the chip boots up in normal mode.

Edit: Ignore this bit, I was obviously smoking crack, or something. The actual connections on the board are pin 45 = 3.5V and pin 46 = 7.5V. Which is, as you said, PC7 pulled to 7.5V / PC6 at 3.5V. Pins 31 and 32 are both strapped to 3.5V.

I actually tried all 4 combinations on PB0/1, and none of them seemed to do anything.

I have managed to dump a SCPH-9001 (PU-23 / NTSC:U/C / SC430944PB) - but that's using the 52 pin CPU, so the connections were exactly as you stated.
Right now, I have a SCPH-7000 (PU-20 / NTSC:J / SC430934PB) wired up, but it doesn't seem to be working - once I get that dumped, I will have another look at the SCPH-1000

[nocash]

Cool. The SC430944PB is also used in PSones, so it's probably same as my PAL dump, aside from part number & region differences. And SC430934PB? That seems to be yet another revision that I wasn't aware that it does exist at all. And the japanese version would be interesting anyways (I don't remember if anybody has ever determined its region string; the one equivalent to "for Europe" and "for U/C") (it might be "for Japan" though the japanese cdrom cpus seem to have been used also in Asia). Hope you get that one dumped!

Looking at the 68HC05L16/68HC705L16 datasheet again, it seems that the EPROM version (68HC705L16) contains a "bootstrap rom", and the normal version (68HC05L16) contains a "self-check rom". Maybe the latter is supporting only boring stuff like blinking LEDs after testing internal RAM and Timers, then it might be impossible to dump the old 80pin chips. Would be a pity since they might contain some intersting relicts like the cdrom "GetClock" and "SetClock" commands that were mentioned in some psx docs.

[TriMesh]

OK, for reference, the reason the SCPH-7000 wouldn't dump (using the built in dump routine) was that PB0 (pin 16) was floating low, and once I pulled it up (I just shorted it to pin 17 using a scope probe during reset), the ROM dumped with no problems. The region string is indeed "for Japan" - and all the device ID strings are "CXD1817Q".

Going to have another go at the SCPH-1000 tonight.

Edit: I can also confirm that Asia variant uses the same Sub-CPU as the Japanese one.

Both SCPH-7500 and SCPH-7503 have SC430938PB
Both SCPH-9000 and SCPH-9003 have SC430942PB
And SCPH-5500 and SCPH-7003 have SC430925PB (both machines are PU-18, despite the model number).

Some other numbers:

SCPH-5000 (Late PU-8, NTSC:J) SC430916PB
SCPH-5501 (PU-18, NTSC:U/C) SC430930PB
SCPH-7501 (PU-22, NTSC:U/C) SC430940PB
DTL-H1202 (PU-8, PAL) SC430920PB (despite being PAL, the CD controller identifies as "for US/AEP").
SCPH-9002 (PU-23, PAL) SC430943PB (same the the PSone you have already dumped)

[TriMesh]

Still no luck with the SCPH-1000 - but I have managed to dump a few more machines from my stack of consoles:

[nocash]

Whew. That are a lot of dumps, including exotic boards like DTL-H. I jump just done looking at the first two dumps:

SC430944 - is just exactly 1:1 as expected - except for the byte at FFDAh. I was thinking that it might be an internal production numbers, and that it might roughly increment along with the SC4309xx number (looked like so on the two "24 Jul 1995" dumps), but on this chip it's total random without relation to the byte in SC430943. That leaves only the checksum theory.
EDIT: Yes, it's a checksum, choosen so that all 16.5Kbytes XORed together will result in value FFh.

SC430934 - from 14 Aug 1997 is something different, settled between the dumps from 10 Jan 1997 and 01 Feb 1999. As you said it's identifying itself as using a CXD1817Q chip (actual chip on PCB appears to be CXD1817R though). That chip combines the three cdrom chips in one chip, but still using a separate SPU chip.
Like the version from 01 Feb 1999, it's using some cdrom commands padded to longer size, eg. 24bit "CX(Ex0000)" instead of the old 8bit "CX(Ex)" form. But unlike the version from 01 Feb 1999 it is still using "unencrypted" SCEx region strings. There are few more small differences.
One odd difference is that the Secret Unlock commands are made non-functional, so this chip couldn't be used without modchip. That does make sense concerning anti-piracy & security. But for some reason the Secret Unlock feature was resurrected in later the 01 Feb 1999 version (which makes less sense to me, but it's just fine for hacking).

[nocash]

Checked the other 4 versions, too.

The debug version's GetDate/Version command responds with version D1h (instead of C1h), somehow I had guessed that it might do that : - ) and it's using a short SCEx timeout. The actual SCEx stuff is handled like this: It does try to read four ASCII SPACEs from the disc (instead of the ASCII "SCEx" string). Obviously that does result in a timeout error since there are no such discs produced, but the timeout error handler is customized to treat any disc with Data track(s) as licensed. Alongsides it's also forcing the SCEx string in RAM to contain four ASCII spaces, so the GetID command will return four spaces as SCEx string (namely it does NOT return "SCEW", which is said to happen on Yarozes) (maybe the Yaroze does really return "SCEW", or maybe the Yaroze is just displaying "SCEW" in the MIPS BIOS, regardless of the GetID command).

The SC430938/SC430940 versions appear to be almost same as the later ones used in SCPH-900x and SCPH-10x.

The Secret Unlock commands seem to be made non-functional in ALL japanese versions (and seem to work in all other versions, ie. U/C, Europe, and also in the Debug version, although the Debug version doesn't need unlocking anyways).

PS. any chance that somebody can dump the late PSone version (from PSones with "PM-41(2)" board)?

[TriMesh]

... so the GetID command will return four spaces as SCEx string (namely it does NOT return "SCEW", which is said to happen on Yarozes) (maybe the Yaroze does really return "SCEW", or maybe the Yaroze is just displaying "SCEW" in the MIPS BIOS, regardless of the GetID command).

I don't have a Yaroze any more, but I'm pretty sure that it displays 4 spaces in the "SCEx" area, just like a debug.

I think that SCEW string was identified using an unmodified retail machine booted into PSX ROMID via caetla, and the characters then read from the CD-controller RAM using the debug commands.

The SC430938/SC430940 versions appear to be almost same as the later ones used in SCPH-900x and SCPH-10x.

That makes a lot of sense, since the hardware is pretty much identical. In fact, I was quite surprised that they had different versions at all.

As you said it's identifying itself as using a CXD1817Q chip (actual chip on PCB appears to be CXD1817R though).

On Sony chips, that last letter just tells you what the package is. Q = Flatpack, R = low profile flatpack (LQFP), M = SOIC. I don't know if there ever was a Q version of that chip or it was just force of habit, though.

Just thinking about it, this is what we have at the moment:

PU-7
Nothing yet

PU-8:
NTSC:U/C (psxdev.ru - decap) (SC430918)
NTSC:J (trimesh) (SC430914)
PAL (nocash) (SC430917)
Debug (trimesh) (SC430920)

PU-18
PAL (nocash) (SC430929)

PU-20
NTSC:J (trimesh) (SC430934)

PU-22
NTSC:U/C (trimesh) (SC430940)
NTSC:J (trimesh) (SC430938)

PU-23 + Early PSone
NTSC:U/C (trimesh) (SC430944)
PAL (nocash) (SC430942)

Later PSone
Nothing yet

So the major omissions are the early 80 pin versions and maybe the late PSones, assuming they had different code. The only PSone I have here (SCPH-101) is an early one that has the same chip as the SCPH-9001 that's already been dumped.

[nocash]

Compiled a list of what is dumped, and what isn't dumped, too:

Code: Select all

  <pin>  <--chip name--------------------------> <--CRC32/dumped----> <date,ver>  <-----console/pcb------------------------>
  80pin  Sony [...]  E35D, 424666 185, SSAD9441D 60BC954E TriMesh     94-09-19,C0 SCPH-1000 NTSC:J   PU-7, 1-655-322-11
  80pin  Sony [...]  E35D, 424660 185, SSAK9502A F82A2A46 TriMesh     94-11-18,C0 SCPH-1000 NTSC:J   PU-7, 1-655-322-13 (also used in SCPH-3000 with PU-7 1-655-322-15)
  80pin  MC68HC705L16CFU   D62P        SSAW9601A ?        -           ..-..-..,.. DTL-H1000 NTSC:J   PU-7, 1-655-322-14
  80pin  ?                                       ?        -           ..-..-..,.. SCPH-100x ...      PU-7 for other regions (if any)
  80pin  ?    prototype?   424688 or so?         ?        -           ..-..-..,.. SCPH-100x ...      Early PU-8 versions for other regions
  80pin  Sony [...]  E35D, 424686 185, SSBP9539B BB134697 Nocash      95-05-16,C1 SCPH-1002 PAL      Early PU-8, 1-658-467-11 (borrowed from J, 2016)
  80pin  Sony [...]  E35D, 424659 185, SSAC9539A 426C05E7 Nocash      95-07-24,C1 SCPH-1001 NTSC:U/C Early PU-8, 1-658-467-11 (borrowed from J, 2016)
  80pin  Sony [...]  E35D, 424684 185, SSAM9542B 84D46B2A Shadow      95-07-24,C1 SCPH-1002 PAL      Early PU-8, 1-658-467-11 (same as SC430917, but with different 80pin-style bootstrap rom)
  52pin  C 2021, SC430911PB                      ?        -           ..-..-..,.. SCPH-?             Late PU-8, 1-658-467-21  (spotted on some photo)
  52pin  C 1021, SC430916PB, G63C 185, JSAB9624F A730082B TriMesh     95-07-24,C1 SCPH-5000 NTSC:J   Late PU-8, 1-658-467-42
  52pin  C 3021, SC430917PB, G63C 185, JSAF9623G 96A79014 Nocash      95-07-24,C1 SCPH-1002 PAL      Late PU-8, 1-658-467-22  (same as 424684, but with different 52pin-style bootstrap rom)
  52pin  C 2021, SC430918PB, G63C 185, JSBM9633B 1617EC6A TriMesh     95-07-24,C1 SCPH-1001 NTSC:U/C Late PU-8, 1-658-467-23 (same as the decapped chip-dump from psxdev.ru)
  52pin  D 2021, SC430920PB, G63C 185, JSAA9810A 7455BB05 TriMesh     95-07-24,D1 DTL-H1202 PAL      Late PU-8, 1-658-467-43 (SC430920PB is also used on DTL-H2500)
  52pin  C 4021, SC430924PB, G63C 185, JSAB9645C AB3E59EB TriMesh     96-08-15,C2 SCPH-5903 NTSC:J   PU-16 1-665-191-11 with sub board MP-45 1-665-192-11 (video cd)
  52pin  C 1030, SC430925PB, G63C 185, JSBK9708C A627277A TriMesh     96-09-12,C2 SCPH-5500 NTSC:J   PU-18, 1-664-537-11
  52pin  W2021,  SC430926PB, G63C 185, JSAA9645A DF333241 CharlesMacD 96-08-18,C1 DTL-H3001 NTSC:U/C Late PU-8, 1-658-467-23 (Yaroze)
  52pin  W3021,  SC430927PB,                     ?        -           ..-..-..,.. DTL-H3002 PAL                              (Yaroze)
  52pin  C 3030, SC430929PB, G63C 185, JSBH9716A BA87A3E0 Nocash      97-01-10,C2 SCPH-5502 PAL      PU-18, 1-664-537-62
  52pin  C 2030, SC430930PB, G63C 185, SSJZ9748A 2A93140F TriMesh     97-01-10,C2 SCPH-5501 NTSC:U/C PU-18, 1-664-537-62
  52pin  C 1040, SC430934PB, G63C 185, SSDG9745D F38341C4 TriMesh     97-08-14,C2 SCPH-7000 NTSC:J   PU-20, 1-668-413-22
  52pin  C 3040, SC430935PB, G63C 185, SSBC9813D 33899F2A Nocash      97-08-14,C2 SCPH-7002 PAL      PU-20, 1-668-413-32 (PCB borrowed from J, 2016)
  52pin  ?       SC........                      ?        -           ..-..-..,.. SCPH-7001 NTSC:U/C
  52pin  ?       SC........                      ?        -           ..-..-..,.. SCPH-7000W PlayStation (10 million model, not for sale, blue, region free)
  52pin  C 1050, SC430938PB, G63C 185, SSAM9850C 191772D1 TriMesh     98-06-10,C3 SCPH-7500 NTSC:J   PU-22, 1-671-858-11
  52pin  C 3050, SC430939PB, G63C 185, SSAY9837A 9EAFB045 Nocash      98-06-10,C3 SCPH-7502 PAL      PU-22, 1-671-858-11 (PCB borrowed from Jackal)
  52pin  C 2050, SC430940PB, G63C 185, SSDL9838A 184D34B6 TriMesh     98-06-10,C3 SCPH-7501 NTSC:U/C PU-22, 1-671-858-32
  52pin  C 1060, SC430942PB, G63C 185, SSAQ9920A 7F90B681 TriMesh     99-02-01,C3 SCPH-9000 NTSC:J   PU-23, 1-674-987-11
  52pin  C 3060, SC430943PB, G63C 185, SS0L0130E 2669A1A7 Nocash      99-02-01,C3 SCPH-102  PAL      PM-41, 1-679-335-51
  52pin  C 2060, SC430944PB, G63C 185, SSBR9924C BD117489 TriMesh     99-02-01,C3 SCPH-9001 NTSC:U/C PU-23, 1-674-987-11
  52pin  ?       SC430947..                      ?        -           ..-..-..,.. SCPH-100  NTSC:J   PM-41(2)
  52pin  C 3070, SC430948PB, G63C 185, SSAE0138D 0E8AD915 Nocash      A1-03-06,C3 SCPH-102  PAL      PM-41(2), P-161125S-31-71 (pcb donated by Squaresoft74)
  52pin  ?       SC430949..                      ?        -           ..-..-..,.. SCPH-101  NTSC:U/C PM-41(2)
  ?      ?       ?                               ?        -           ..-..-..,.. DTL-H100x
  ?      ?       ?                               ?        -           ..-..-..,.. DTL-H110x
  ?      ?       ?                               ?        -           ..-..-..,.. DTL-H1200/DTL-H1201
  32pin  27C256A-15 (EPROM 32Kx8) ("94/11/28")   ?        -           ..-..-..,.. DTL-H2000 (Sony CXP82300 80pin SPC700 CPU with piggyback 32pin EPROM socket, not a Motorola HC05 CPU)
  ?      ?       ?                               ?        -           ..-..-..,.. DTL-H270x
  ?      ?       ?                               ?        -           ..-..-..,.. DTL-H3000 (yaroze/japan) (and, possible later yaroze versions exist, with PCBs newer than PU-8?)
  80pin  M...16, ... (sticker: "7/24, 2.'E")     ?        -           ..-..-..,.. NOT FOR SALE, SONY, PU-9
  ?      ?       ?                               ?        -           98-06-10,C3 SCPH-9903 (region free)
  ?      ?       ?                               ?        -           ..-..-..,.. PS2...

EDIT: Is there a way to disable line-wrapping in above table? If not: Use copy/paste to view it in an external txt editor.
EDIT2: Updated the table with some extra details and info on newer dumps.

The later PSone boards have new chips, so there should be at least some small difference in the ROMs (or maybe huge differences in case they attemped some more SCEx encryption, or completely changed the commands/protocol for the servo amplifier, or whatever).

On the 80pin chips, the "42466x" number sounds a bit like the later "SC4309xx" number. If so, then 424666 and 424660 are probably containing different ROMs - are that chips both from SCPH-1000 consoles, ie. both NTSC-J region?
And do you have the PCBs connected & working? If yes, then you could try some of the test commands to get an idea about what is in the ROMs:

Code: Select all

19h,20h --> INT3(yy,mm,dd,ver)
19h,22h --> INT3(<region string>)
19h,23h --> INT3(<servo amp string>)
19h,24h --> INT3(<signal proc string>)
19h,25h --> INT3(<decoder string>)
19h,60h,FCh,00h --> INT3(databyte)  ;\upper 4 bytes on stack
19h,60h,FDh,00h --> INT3(databyte)  ; (2A,66,10,86 on SC430917)
19h,60h,FEh,00h --> INT3(databyte)  ; (big-endian 16bit retadr's, ie. 
19h,60h,FFh,00h --> INT3(databyte)  ;/2A66,1086)

I wouldn't be surprised if they forgot to update the date/version for command 19h,20h in some chips. The 4 stack bytes may be useful to see if there was some code inserted/removed.

Do you know somebody with a DTL-H2000 and access to an eprom burner? The boards have the old 80pin chips, but with the ROM on a separate 32pin ERPOM (with socket), that should be very easy dump. It would help to know if there are any special changes in the cdrom-bios section.
The selftest/bootstrap-rom is probably not contained in the EPROM (although... at least the exception vectors should be in there). Anyways, I could make a patched EPROM-image that allows to read memory at FE00h..FFFFh, allowing to dump the selftest/bootstrap-rom section, which might help to find out if/how one can dump the 80pin chips on regular PU-7 and old PU-8 boards.
EDIT: Turned out that the DTL-H2000 seems to use a Sony SPC700 CPU, not a Motorola HC05 CPU.

[Shadow]

Okay, I'm dumping my SCPH-102 and 1002.

We can't disable line wrapping I'm sorry.
Maybe if I recoded the PHP logic. I'll have a look into that.

[TriMesh]

Code: Select all

19h,20h --> INT3(yy,mm,dd,ver)
19h,22h --> INT3(<region string>)
19h,23h --> INT3(<servo amp string>)
19h,24h --> INT3(<signal proc string>)
19h,25h --> INT3(<decoder string>)
19h,60h,FCh,00h --> INT3(databyte)  ;\upper 4 bytes on stack
19h,60h,FDh,00h --> INT3(databyte)  ; (2A,66,10,86 on SC430917)
19h,60h,FEh,00h --> INT3(databyte)  ; (big-endian 16bit retadr's, ie. 
19h,60h,FFh,00h --> INT3(databyte)  ;/2A66,1086)

Yes, both boards are PU-7s from SCPH-1000s
424666 is on a 1-655-322-11
424660 is on a 1-655-322-13
Both boards have the original Boot ROM that allows the audio menu swap and doesn't block non-Japanese discs.

Most of the test codes don't work on this version - 19h,22h-25h all return 11h,10h and 19h,60h,xx,xx returns 11h,20h

Edit: That command works fine - it was just that my code was sending random crap instead.

The 19h,20h test code *does* work, however - and they are different versions, but both "C0".
424666 -> 19h,20h --> 94,09,19,C0
424660 -> 19h,20h --> 94,11,18,C0

I have one more SCPH-1000 here, which also has the -13 board and the 424660 chip in it, and returns the same date.