How to dump your CDROM BIOS (Firmware)

Members research, findings and information that can be useful towards the PlayStation 1.
User avatar
nocash
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » June 16th, 2014, 5:54 am

Orion_ wrote:ok so, I have located the chip at the back of the board, here are the numbers on it: W3021, SC430927PB, G63C 185, JSAB9705B - My Yaronet is a DTL-H3002 PAL
Good to know, thanks! The manfucturing date code (9705) seems to be only 12 weeks newer than Charles' dump (the actual ROM is probably same built/date), but W3021, SC430927PB does look as if the "region-free" yarozes are still containing some small region specific differences, maybe just something different than the "for NETNA" region string. The "30" in "W3021" is also hinting that the chip is something "PAL" specific.
Would be interesting if somebody could dump that chip. The PU-8 board should have nice solder pads, so it should be quite easy (as long as you have some PC or other computer hardware that can deal with 3.5V serial data transfers).
Michele133 wrote:http://www.freescale.com/webapp/sps/sit ... 4684498633
this is a list of hc05 legacy-product maybe there is the psx version of cpu-microcontroller?
or this?
http://www.datasheetarchive.com/MC68HC0 ... sheet.html
Datasheetarchive.com is my favorite source. For the PSX chips:
For 80pin (old cdrom controller): The MC68HC05L16/MC68HC705L16 datasheet should be the perfect choice, the psx appears to be using exactly that chip (only drawback is that it doesn't go into detail about bootstrap mode, but TriMesh has figured out how it works anyways).
For 52pin (new cdrom controller): The chip should be called "MC68HC05G6" but I haven't found an exact datasheet for it. However, the pinouts can be found in PSX service manuals, and the I/O ports are resembling that in MC68HC05L16/MC68HC705L16 datasheet (but without the LCD feature) or MC68HC05G3 (705G4) datasheet (but without Port G,H,J).
For 32pin (digital joypad): I haven't found any Motorola datasheet nor Sony service manuals :- / Pinouts would be very interesting for dumping purposes - especially the "/IRQ" pin(s) for entering test mode (at the moment I only know four pins: Pin12=GND, and Pin28=3.5V, Pin26/27=OSC).
Motorola's MC68HC05P6FBE and MC68HC05P6FB chips appear to have 32pins - maybe those chips were used in joypads - the chips are also mentioned to exist on freescale.com (but unfortunetly, they are just redirecting to 28pin MC68HC05P6 datasheets).
Last edited by nocash on July 2nd, 2014, 8:13 am, edited 3 times in total.

Michele133
Interested PSXDEV User
Interested PSXDEV User
Posts: 5
Joined: May 26, 2014

Post by Michele133 » June 16th, 2014, 7:44 am

http://www.freescale.com/search?q=MC68H ... rc=1&hl=en
There two version of that chip it's called "MC68HC05G6PB"

User avatar
nocash
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » June 19th, 2014, 12:56 pm

Just found 300dpi DTL-H2500 pcb scans: http://lorezan.free.fr/ps1/scans%20dtl- ... -h2500.rar
The DTL-H2500 is using a SC430920PB chip, too (ie. the same chip as in DTL-H1202 (which was already dumped by Trimesh)).

User avatar
nocash
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » June 29th, 2014, 12:08 am

I just realised that Shadow has discovered and dumped one more chip: 80pin "Sony Computer Entertainment Inc. (C) E35D, 424684 185, SSAM9542B" from a SCPH-1002 PAL, Early PU-8, 1-658-467-11 mainboard: http://www.psxdev.net/forum/viewtopic.php?f=60&t=573 CRC32 is 84D46B2Ah, the first 4000h bytes of the 424684 ROM are same as in SC430917, but the bootstrap ROM in last 200h bytes differs for 80pin/52pin chips accordingly.

User avatar
TriMesh
PSX Aptitude
PSX Aptitude
Posts: 225
Joined: Dec 20, 2013
PlayStation Model: DTL-H1202
Location: Hong Kong

Post by TriMesh » October 29th, 2014, 9:37 pm

From one of my friends:

SCPH-1001 late PU-8, PCB number 1-658-467-23 - chip markings are C 2021, SC430918PB, G63C 185, JSBM9633B

Dumped it - and it's exactly the same as the psxdev.ru dump.

OK, maybe not that useful, but I thought I would pass it on.

User avatar
nocash
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » October 30th, 2014, 3:38 am

Knowing the chip name & pcb name for that dump is great!

Myria
Curious PSXDEV User
Curious PSXDEV User
Posts: 17
Joined: Nov 05, 2014

Post by Myria » November 5th, 2014, 3:43 am

Wow, it's been more than a year since it happened, and I didn't hear =). Congrats no$ on finding the Holy Grail of PSX CD-ROM research! I didn't think there would actually be back doors to unlock the drive in it, hehe.

I have an SCPH-7000W, the Japanese "Midnight Blue" sweepstakes model, of which only 100 exist. It has a CPU BIOS version that had never been seen before and it acts like a Yaroze in booting imports but not unlicensed disks. I don't know whether the Yaroze boot disk will run on it, because I don't have that disk, and it's hard to find. I imagine that its CD-ROM controller's BIOS is unique, being a Yaroze in SCPH-700x hardware. Would you want to dump it?

Similarly, I also have an SCPH-5903. I've always wondered how those are able to read video CD disks with the drive's refusal to read unlicensed disks. One theory is that they play in audio mode (see below about GameShark).

Due to their rarity, it's important that we consider risk versus reward. I am American and presume you're Australian; that would make for some fun in getting them to you.

PSX's can read part of Dreamcast disks. The PSX CD controller doesn't refuse requests to read into lead-out like most CD drives. To read Dreamcast disks, seek to 10 minutes or perhaps a bit after and start reading. Unfortunately, the read will fail after 99:59:74, because the encoding used for minutes 100-122 on GD-ROMs is fake-BCD 0xA0 through 0xC2, which the PSX CD controller dislikes. Obviously, don't try seeking anywhere but to ~11:00:00 or earlier on GD-ROMs, because the distance calculation for seeking will screw up due to the higher density, leading to either read errors or to smacking the drive head against the wall.

Another CD-ROM trick that I'm not sure is documented is that you can indirectly read off unlicensed disks (without unlock back door) by asking the drive to mute and play audio, then execute sector buffer reads. GameShark/Action Replay v3.x used this for its update disks before Datel figured out how to make self-booting disks and switched to making GameShark CDX.

By the way, where exactly does 19 58...5F jump to? Is there any chance that it jumps to a part of RAM that we could control somehow, such as by seeking to a part of the disk that contains particular data?

I'm curious whether the PSX mode of PS2 has this back door. That would have interesting consequences: a soft mod could support DVD-R booting via video read mode, and support CD-R by sending the PS1 unlock commands (the PS2 allows PS2 software to read PSX games).

Melissa

User avatar
Shadow
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » November 5th, 2014, 1:41 pm

Dumping the 7000W BIOS and CD-ROM SUB-CPU would be pretty interesting, but I really have a keen eye on the VCD player. NO$CASH is from Germany. You can send the systems to either NO$CASH, Trimesh (Hong Kong) or myself (Australia).
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

User avatar
nocash
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » November 10th, 2014, 2:44 am

Command 19 50..57 jump to an 8x3 byte jump table (at 3A5Bh..3A72h in the SC430918PB firmware version).
Command 19 58..5F should have another 8x3 byte table (at 3A73h and up), but that region does contain ASCII text "Licensed bySonyComputerEntertainment" instead of jump opcodes. Many of those ASCII characters are invalid opcodes, so it's unknown what happens when executing them. Chances are probably quite bad that they might jump to a RAM location, and even if so: It would be useful only if one could write code/data to that specific RAM location.

Dumping the 7000W and 5903 would be interesting, especially the 5903 should have a bunch of nonstandard details. The 7000W firmware might be same/similar as in the yaroze, or maybe some newer revision of it. Photos of the mainboards would be also interesting, especially of the cdrom controller chip with the firmware in it (should have that "SC4309xxPB" text on it, or some sticker if it's containing a real rare EPROM version instead of mass produced ROM), and seeing the 5903 daughterboard would be also very interesting.

User avatar
Shadow
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » November 10th, 2014, 6:44 pm

Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

Myria
Curious PSXDEV User
Curious PSXDEV User
Posts: 17
Joined: Nov 05, 2014

Post by Myria » November 11th, 2014, 3:11 am

nocash wrote:Command 19 50..57 jump to an 8x3 byte jump table (at 3A5Bh..3A72h in the SC430918PB firmware version).
Command 19 58..5F should have another 8x3 byte table (at 3A73h and up), but that region does contain ASCII text "Licensed bySonyComputerEntertainment" instead of jump opcodes. Many of those ASCII characters are invalid opcodes, so it's unknown what happens when executing them. Chances are probably quite bad that they might jump to a RAM location, and even if so: It would be useful only if one could write code/data to that specific RAM location.
I doubt much research has been done into the behavior of illegal opcodes on a 68HC05, too, unlike Z80 and 6502.

Wasn't there a command that would keep writing bytes to the command buffer if you keep sending them from the CPU? That would be cute, overwriting some important data areas...

I wonder whether the PS2 is exploitable. Its CD controller has way more complex CD controller commands, thus having a nice, big surface area for attacks.
nocash wrote:Dumping the 7000W and 5903 would be interesting, especially the 5903 should have a bunch of nonstandard details. The 7000W firmware might be same/similar as in the yaroze, or maybe some newer revision of it. Photos of the mainboards would be also interesting, especially of the cdrom controller chip with the firmware in it (should have that "SC4309xxPB" text on it, or some sticker if it's containing a real rare EPROM version instead of mass produced ROM), and seeing the 5903 daughterboard would be also very interesting.
The 5903 may not actually have a special CD-ROM controller - it could be using audio read mode. However, if that's the case, I don't know how it works - my understanding is that the 68HC05 only supports reading 2340 (or 2336?)-byte sectors, rather than the full 2352. Perhaps the VCD player doesn't need that, though. :roll:

Melissa

User avatar
nocash
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » November 11th, 2014, 8:50 am

Writing to the command/parameter buffer isn't useful: You can write to the buffer (and higher memory locations, within 256 byte range), until the parameter FIFO becomes empty (which is no real limit because you you could feed more data to the FIFO before it gets empty). Anyways, it's only allowing to write to the buffer & higher addresses, but not to real important addresses (such like writing to stack).
I've spent some time on searching for possible exploits, and as far as I can tell: There are none. Except, yeah, the undocumented opcodes might do anything - but I doubt that they can do anything useful (there are only a handful of undoc opodes executable via command 19 58..5F, chances that one of them is writing something useful to stack, or doing a jump to a useful ram address aren't really good).
If anybody wants to reverse-engineer the behaviour of undoc HC05 opcodes: One could use the motorola bootstrap mode to run any kind of tests.

I don't know anything about PS2. My PS2 newbie questions:
Does anybody know if it's using a HC05 or some other CPU as cdrom controller?
And did anybody dump the PS2 cdrom firmware?

Can you check the "SC4309xxPB" chip names on the mainboards? If they are already known & dumped, then there's really nothing special about them. I would assume that they are different as in yaroze/retail consoles. The 7000W is probably yaroze-like, but with newer firmware matched to newer chipset. And the 5903, I would guess that it does somehow detect video CDs by examining the sector sub-header, and allow to read them in data mode, and use DMA to decompress them via external hardware similar as for MDEC decompressions. Though it might also pickup "analog" signals at some lower level, completely bypassing the HC05 and MIPS processors.

Do you have some camera or scanner for taking pictures of the PCBs? Currently, the best photos of the 5903 are barely showing that it does have a daughterboard, but the picture resolution is so bad that one couldn't decipher any part numbers.

For dumping the firmwares: I could do so (or else ask Trimesh or Shadow). We would probably only need the mainboard (and 5903 daughterboard of course), but not the case, power supply, or cdrom drive (unless they are totally different as in other models). I could also check the wiring of the 5903 daughterboard to see where it is connected to. Oh, and I really couldn't afford the postage for returning the boards to you though.

Gradius
Extreme PSXDEV User
Extreme PSXDEV User
Posts: 220
Joined: Sep 09, 2012
I am a: IT Consultant, Systems Integrator
PlayStation Model: 7501
Location: Chile

Post by Gradius » November 11th, 2014, 9:19 am

Why we're talking about PS2 at all ?!

User avatar
Shadow
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » November 11th, 2014, 4:35 pm

Gradius wrote:Why we're talking about PS2 at all ?!
Touching the PS2 subject is okay so long as it has to do along the lines of the PSX side of it.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

User avatar
nocash
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » November 19th, 2014, 11:40 am

The PS2's cdrom firmware would be very interesting for PSX programming. Theoretically, the PS2 should be backwards compatible with PSX games. But the firmware is probably quite different, supporting both dvd+cdrom, maybe using a different processor, and different chipset. There are probably a lot of subtle differences in logic & timing. And I wouldn't be surprised if the PS2 would be just crashing when trying to use Test commands on it.

-----

And something else: New theory for identifying cost-down PSone models:
After spotting this picture: http://i.ifreeads.ru/2013/08/19/125880/ ... 5223_2.jpg
That PSone has tiny rubber feet.
Smaller feet might mean reduced production cost...
So...
Could that be one of the mysterious cost-down models with PM-41(2) mainboards?
Does anybody have such a console and could check its mainboard type?

For reference, here's another picture with big and small feet: http://dchester.pwp.blueyonder.co.uk/im ... screen.jpg (the left one is said it be SCPH-102A, and the right one SCPH-102B, hmmm, although the photo doesn't really look as if there are any suffices after the 3-digit number) (and rather unrelated: the right one has an LCD screen attached at the back side).

Myria
Curious PSXDEV User
Curious PSXDEV User
Posts: 17
Joined: Nov 05, 2014

Post by Myria » November 22nd, 2014, 5:37 am

nocash wrote:The PS2's cdrom firmware would be very interesting for PSX programming. Theoretically, the PS2 should be backwards compatible with PSX games. But the firmware is probably quite different, supporting both dvd+cdrom, maybe using a different processor, and different chipset. There are probably a lot of subtle differences in logic & timing. And I wouldn't be surprised if the PS2 would be just crashing when trying to use Test commands on it.
The PS2 in PS1 mode knows at least some of the test commands. It responds with a chip name, the mod chip detection code works to actually detect PS1 mods in a PS2, etc. I think the *real* tests would be to see whether the undefined test commands crash the chip and also whether the back door is there.

User avatar
TriMesh
PSX Aptitude
PSX Aptitude
Posts: 225
Joined: Dec 20, 2013
PlayStation Model: DTL-H1202
Location: Hong Kong

Post by TriMesh » December 10th, 2014, 10:18 pm

OK, here's another one for the collection:

SCPH-9000 (NTSC-J)
PCB: PU-23 1-674-987-11
Chip markings:
C 1060 SC430942PB G63C 185 SSAQ9920A

Edit: the archive file name (and the name of the file inside) was wrong, and has been changed - the actual file contents were correct however.
You do not have the required permissions to view the files attached to this post.

Yuri^Cybdyn
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » December 26th, 2014, 2:47 am

i did see ps2 mother boards , cdvd-drive has most coomon things in theory of working of cd-dvd drives. like DSP-fifo ic, mcu or "mecha con" based on sony's mcu , not hc05. and servo part.
to interface w/ main cpu (IOP) cdvd-dsp uses more lines : 16bit bus, more addr lines, and real dma i/f (DMACK/DREQ)
it means, it's more complex then what we got in ps1. addditional scheme is power-off. as you know we press buttons to pow-on/off or reset, which connects to mechacon pins.

but i think, in ps1 mode it uses same i/f and registers for back compatibility w/ ps1.

to see how drivers on IOP interacts w/ cdvd- dsp, we can see from dis-asm of CDVDMAN/CDVDFSMAN drivers, but also, EE can access to IOP bus)) so some commands come from/read to EE directly...

like ps1, the history of ps2 cdvd ic's was changing from multy chip to on big chip(all in one, even maybe spu w/ dram was ijected there!!) - cxd3098 and mcu.

big advantage of ps2 - on sw level - it uses drivers, so we can reload drivers lib w/ our functions to re-target reading of data from usb or expansion port(hdd and eth )....

Yuri^Cybdyn
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » January 30th, 2015, 12:42 am

no$cash: THANKS for amazing work in ps1 cdrom bios disassembling. it's awesome!!!

very interesting if you can do same for ps2))) ? .not sure, but sony used another mcu (not hc05, maybe 32bit),
all chip models have "CXD" prefix .
but from service schemes, we can see how it attached to cdvd-dsp, in same way - addr/data lines and cs/rd/wr contril signals.

Yuri^Cybdyn
Cybdyn Systems
Cybdyn Systems
Posts: 406
Joined: Jan 13, 2012
I am a: Embedded Developer (MCU & FPGA)
PlayStation Model: 5502
Location: Belarus (Minsk)

Post by Yuri^Cybdyn » February 5th, 2015, 8:39 pm

no$cash: can you tell more if you found any signs about extra INT bits. i mean, normally it uses mask of 0x7 (for int1,2, 3,4,5). but there are two last bits (0x8 and 0x10). you told about one of them, used as cmd-acknowledge flag. did you see something about it in dis-asm code?

i saw in Resident evil 1 (jpn), anti-mod code (mips cpu side) set 0x18 as INT flag. so i 'm trying understand how handle such event. as i see , w/ such combination (0x18 of INT'S bits) cd-dsp wont fire CD_INT line to mios-cpu. so i guess the anti-mode code check and handle int manually? and the question if i need use this 0x8 / 0x10 bits for responds?

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests