How to dump your CDROM BIOS (Firmware)

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

Post by nocash » May 15th, 2014, 10:50 pm

Interesting, good to know the 19h,29h date/version values. And very good to know that the old chips didn't support all test commands! Sounds as if the old ROMs are quite different (at least concerning test commands... which aren't too important for normal use).

And you have a DTL-H1000 with MC68HC705L16CFU chip, too? Going by the datasheet, that HC705 chip should really support bootstrap mode, unlike the HC05 ones which might not support it.

I've searched for more info... seems that they are calling the input RXD (not RX)... oh, and this looks useful:
MC68HC705L28 dataheet page 23..27 http://pdf.datasheetarchive.com/datashe ... 544232.pdf

The program/verify modes seem to be using parallel 8bit data transfers, so no surprise that you couldn't see serial data (and that L28 chip does only seem to have a verify function with LED result, unlike the L16's dump function).

But the upload to RAM and execute function use 9600 bps serial transfer (one-way, only RXD, without TXD, unless of course the uploaded program does choose to output a TXD signal on some pin).

The memory map seems to be a bit different. The L16 does have a LCD function, too. But I don't think that it has LCD RAM at 0040h - instead, general purpose RAM seems to start at 0040h. So the L28's address 0081h would be probably 0041h on the L16. But the CPU supports relative jump/call opcodes anyways, so it doesn't really matter where the program is uploaded to.

Unlike on the 52pin chips, it seems that the uploaded program must be preceeded by a length byte (or maybe a length word or whatever since L16 has more RAM than L28). The L28 bootstrap info says that one may not destroy stack (which is don't care on the 52pin chip; and would only matter for bigger programs anyways). And, the uploaded program doesn't seem to autostart on L28, so you may issue a separate /RESET with changed PortB bits on L16, too.

I guess this might work, hopefully with same PortA/PortB wiring as in L28 datasheet. I'll upload a small dumping function for it later today.

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

Post by nocash » May 16th, 2014, 12:43 am

Here's a miniature dumping function, binary with source code:
80pin.zip
The binary is only 83 bytes (53h) in size, so it shouldn't collide with stack even if it's loaded to 81h.
The code is fully relocatable, so it could be loaded to any RAM address.

The binary begins with two NOP opcodes (9Dh,9Dh), so you can probably send the file as-is (either the chip stores that bytes in RAM, or it treats them as length=9Dh or length=9D9Dh or whatever, which is more than enough (ie. longer than the actual 53h bytes - just stop sending data after 53h bytes so that the chip won't happen to overwrite bytes at some point).

Data is output at 9600 baud, 8-n-1, as usually. But, with TX output on PortD.Bit1 (ie. on pin50 on 80pin chips). Transferred data is 4000h bytes Main ROM plus 200h bytes Bootstrap ROM (4200h in total), in plain binary format (non-ASCII).

I hope that I didn't got any bugs in it. Theoretically it should work - as long as figure out a way to load it into RAM and execute it.
You do not have the required permissions to view the files attached to this post.

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

Post by nocash » May 16th, 2014, 1:23 am

Better use this updated version:
80pin2.zip
The old version stored self-modifying code at 0040h, which is supposedly overwriting the first bytes of the uploaded program, which is normally no problem --- unless you have switch bounce when triggering /RESET for starting the uploaded program.
The new version allocates 4 bytes on stack, and stores the self-modifying code at that location, so there should be no problems in case of switch bounce. Filesize is now 87 bytes (57h), so transfer much (forget about what I said about not transferring more than 53h bytes in previous post)
You do not have the required permissions to view the files attached to this post.

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

Post by TriMesh » May 16th, 2014, 1:53 pm

OK, I will have a go with it tonight.

I'll also expain the situation with that OTP chip - I removed it from the board years ago, and then tried to dump it using the verify function on the Motorola programmer (well, by abusing the verify function - basically, I connected an EPROM emulator to the programmer board and then wired the reset switch, and the error LED to the PC and then changed the first byte in until it matched, then the second, then the third..).

This worked fine (if a little slowly) on the chips I had programmed, but i could never get the verify function to start at all on the one I took from the PS1.

All that stuff (the original chip, the blank ones, the ones I programmed for testing and the programmer board) is still around here somewhere, so I will try to dig them out.

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

Post by TriMesh » May 17th, 2014, 2:09 am

OK, it sort of worked - I did manage to get one dump out of it, but it was the wrong length and I couldn't get it to dump again.

Having said that, there was a block of 512 bytes at the end of the dump that looked pretty valid, and seems to be the test ROM. I've had a quick look at it, and come to the following conclusions:

1) The upload function is designed to take a fixed-length block of 256 bytes, which are loaded at RAM location $40
2) PA0 is serial data in
3) PA1 is serial data out
4) PA3,4 & 5 are used for mode selection
5) It does have a built-in serial dump function, but it's raw binary.

Anyway, here it is - and I just checked and the chip is still working, so it should be dumpable once we figure out what the right settings are.

Edit:

OK, it looks like it does the following:

if (PA5 == 0) [
run_downloaded_code(); }
if (PA4 == 0) {
run_bogus_selftest(); }
if (PA3 == 0) {
binary_dump_rom(); }
download_and_run_code();



2)
You do not have the required permissions to view the files attached to this post.

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

Post by nocash » May 17th, 2014, 5:17 am

Great. The testrom looks good. I guess now nothing can stop you getting the remaining bytes out of that chip.
Oh, and it's from the normal SCPH-1000 board? That's even better - the datasheet sounded as if it would lack dumping function - but it seems to be fully supported.

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

Post by TriMesh » May 17th, 2014, 4:14 pm

OK, here's the first one - this is the ROM from the -11 board

This is just the raw binary data - I haven't bothered packing it up in S-record format.

16K rom data + 512B of test ROM

Edit: And the one from the -13 board. Same format.

And for anyone else planning to try this, these are the connections:

PC7/IRQ1 (Pin 46) goes to Vtst (7.6V)
PC6/IRQ2 (Pin 45) goes to Vdd (you have to solder to the pin)

PA1 (Pin 24) is the serial data output
PA3 (Pin 26) wires to Vss
PA4 and PA5 (Pins 27 and 28) wire to Vdd

Output format is binary, and seems to be 9600,N,8,2
You do not have the required permissions to view the files attached to this post.

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

Post by nocash » May 18th, 2014, 9:40 am

Fantastic. I guess that wasn't easy to find the correct pins for that chips - the pins for MC68HC05L28 are quite different, so that datasheet wasn't too useful, glad that figured out the correct pins anyways!

The 424666 and 424660 versions are nearly identical. There are only two changes:
1) added two calls in reset handler (cancel_auto_sequence and stop_spindle_motor)
2) moved the opcode-pair for marking "disc missing" closer to the end of the "check_door" function
And of course, bcd date, chip name, and chksum have also changed.

But there a lot of differences compared to the later SC430916 chip:
Alltogther there are around 125 changed details (the overall code skeleton is same, but there are various added/moved/removed/changed opcodes - that was a lot of work to locate all those differences). I guess there are a bunch of problems concerning calibration & error handling in the older PSX consoles, plus some situations where they do work, but behave slightly different than later versions.
Concerning the "user interface", the following commands are missing in 42466x chips:
- lacks command 1Dh GetQ
- lacks command 1Eh ReadTOC
- lacks command 50h..57h (SecretUnlock, but it's a Japanese chip, so it would be nonfunctional anyways)
- lacks test command 19h,7xh (CXD1815Q test commands)
- lacks test command 19h,22h..25h (region/chipset strings)
The other commands are same as in later versions, namely:
- does NOT HAVE commands 17h or 18h (no relicts of "GetClock/SetClock" commands)
- does HAVE command 19h,60h,xxh,xxh (hey, TriMesh, the RAM Read command should be working!)

The BIOS does seem to check the SCEI string, I can't see anything that makes it accepting non-japanese discs - unless you meant that it accepts them only when doing that disc-swap trick in the audio menu? And... then it should also work with completely unlicensed CDRs?

Bootstrap ROM is (obviously) different as in 52pin chips. But the 1-byte chksum and 3-byte chip-name (42h,46h,6xh for "42466x" chips) do exist in the "bootstrap" memory region as in later chips, moved to slightly different locations though.

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

Post by TriMesh » May 18th, 2014, 1:02 pm

nocash wrote:does HAVE command 19h,60h,xxh,xxh (hey, TriMesh, the RAM Read command should be working!)
I will have to check again - maybe I screwed up my test code.

Edit: yes, I did.

It works much better when I send the command I built rather than the contents of uninitialized memory.
nocash wrote:The BIOS does seem to check the SCEI string, I can't see anything that makes it accepting non-japanese discs - unless you meant that it accepts them only when doing that disc-swap trick in the audio menu? And... then it should also work with completely unlicensed CDRs?
Yeah, I probably wasn't being that clear - this was a reference to the MIPS boot ROM, and basically just saying "It's the first version" - and yes, on these consoles you can boot CD-Rs from the CD-Player screen using a swap. On the later boot ROM, they fixed this, and also put a territory check into the main BIOS to only allow Japanese discs (like the one in the PAL PSone) so even if you install a chip they will still only boot Japanese discs.

Incidentally, that DTL-H1000 I removed the MCU from was like that - since it was a debug, it would read CD-Rs, but since it had the later boot ROM it wouldn't read any NTSC:U/C or PAL discs (either original or copied).
Last edited by TriMesh on May 19th, 2014, 3:21 am, edited 1 time in total.

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

Post by TriMesh » May 19th, 2014, 1:32 am

OK, here's one more - SCPH-5500 NTSC:J from a PU-18

Dumped from SCPH-5500 (NTSC:J)
Chip markings: C 1030 / SC430925PB / G63C 185 / JSBK9708C
Board Type: PU-18 / 1-664-537-11

Having problems with the SCPH-5501, though - I've tried 2 of them so far, and neither of them seem willing to dump.
You do not have the required permissions to view the files attached to this post.

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

Post by nocash » May 19th, 2014, 7:28 am

Whew, you have still more boards in stock - or are you already plundering the neighborhood?

The japanese SC430925 chip for PU-18 is a bit different than the european version: It's a few months older, and does still contain the debug status feature, and also has some sled values adjusted differently, and the secret unlock buffer is moved to a nonsense memory address (23Dh, making it only 3 bytes in size; but as for all japanese versions, the secret unlock stuff is nonfunctional anyways).
Going by PU-18 service manual, the first some PU-18 revisions have been used only in japan, and later PU-18 revisions have been used worldwide - explains why the japanese PU-18 chip is older. Judging from the service manual, even newer japanese PU-18 boards seem to have kept using that old chip version.

I didn't have problems dumping the PAL PU-18 version, except locating the SCOR trace was a bit difficult. On my board it appeared between between Pin26/Pin27 at the edge of the chip, though that might vary on different PU-18 revisions.
Did you try to dump the MC68HC705 "PROM" version with same wiring as for the normal 80pin chips? Plus supply and 4.000MHz oscillator (as you've desoldered it from the PCB), plus whatever other important pins, like NDLY maybe (I've no clue what that pin is good for).

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

Post by TriMesh » May 20th, 2014, 2:35 am

nocash wrote:Whew, you have still more boards in stock - or are you already plundering the neighborhood?
This is pretty much it - I will keep my eyes open for versions that haven't been dumped, though. All that's left now is that chip off the DTL-H1000 and a couple of consoles I was sure I had but can't find (SCPH-9003, SCPH-5903).

I suspect the DLT-H1000 chip in in with it's programmer in a box of old dev boards (I'm the sort of person that never throws away dev hardware no matter how old it is...) - I didn't get a chance to look for it last weekend, though.
nocash wrote:I didn't have problems dumping the PAL PU-18 version, except locating the SCOR trace was a bit difficult. On my board it appeared between between Pin26/Pin27 at the edge of the chip, though that might vary on different PU-18 revisions.
The two boards I tried were a -62 (same as your PAL model) and a -63 - in both cases, that track was in the same position as the Japanese -11 that dumped with no problems. I have managed to get a dump now - the problem seems to be that the current leaking through from the serial interface was stopping the chip from resetting properly, since it worked fine if I disconnected the serial lines when resetting the board. I have no idea why this cased a problem on these two SPCH-5501 boards and not on anything else, though.

Out of curiosity, I tried restarting the board with the serial port connected and disconnected - with it connected, it did nothing 5/5 times, and with the serial line disconnected, it went into dump mode 5/5 times.

On the -11 SCPH-5500 board the dump mode was entered correctly irrespective of if the serial lines were connected or not. Strange.

Anyway, here's the dump from the SCPH-5501 (finally!).
SCPH-5501 PU-18 SC430930PB
nocash wrote:Did you try to dump the MC68HC705 "PROM" version with same wiring as for the normal 80pin chips? Plus supply and 4.000MHz oscillator (as you've desoldered it from the PCB), plus whatever other important pins, like NDLY maybe (I've no clue what that pin is good for).
As I said, I haven't found it yet - and on the EPROM version the NDLY pin is used for Vpp :)
You do not have the required permissions to view the files attached to this post.

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

Post by nocash » May 22nd, 2014, 7:04 am

Great that you got the SC430930 dumped. Aside from region differences, that BIOS is 100% same as the japanese and european SCPH-550x / PU-18 versions. No nasty surprises in there.
I didn't need disconnecting the serial wires to get the PU-18 PAL chip into reset state (but who knows, maybe the PAL version would have had the same problem if my serial would have injected more amps to the rx/tx pins).

Jackal borrowed me a PU-22 board from a SCPH-7502 PAL console - just dumped that chip, too:
52pin, "C 3050, SC430939PB, G63C 185, SSAY9837A", CRC32=9EAFB045h.
This one also turned out to be 100% same as JAP/US versions (aside from expected region differences).

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

Post by nocash » May 22nd, 2014, 7:29 am

NB. I am keeping the list of what is dumped & what is missing updated, see here: http://www.psxdev.net/forum/viewtopic.php?p=4284#p4284
Currently missing are:

Japanese OLD-PU-8 boards (ie. PU-8 boards with 80pin chips), though maybe they have same chips as PU-7.

USA/EUR versions for PU-7 and OLD-PU-8 (if they do exist at all - PSX was released on 9 Sep 1995 in USA, and 29 Sep 1995 in EUR - so theoretically they might be all using the new 52pin chips from 24 Jul 1995 - but dunno if it would be realistic that the production, assembly, and shipping could have been done in a few weeks). Does anybody have one of the first US/EU psx models?

Then there are SCPH-7002 and SCPH-7001 missing, as well as SCPH-9000 (or SCPH-100, which uses the same chip). And, all PU-41(2) boards - are those late cost-down PSone boards exceptionally rare? And does somebody know how to separate them from older PSone models? Different sticker at bottom side would be nice. And at software-side, they should probably return a newer BCD date code for the 19h,20h test command, with year 00 or later?

And there's lots of uncommon stuff missing: Most debug DTL-Hxxxx consoles/devboards, and uncommon non-retail SCPH-xxxx consoles, and the SCPH-5903 Video CD version.

org
Curious PSXDEV User
Curious PSXDEV User
Posts: 10
Joined: Sep 11, 2013

Post by org » May 22nd, 2014, 5:17 pm

Is there any place to keep all dumps together?

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

Post by Shadow » May 23rd, 2014, 2:20 am

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
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » May 29th, 2014, 1:22 am

I've just released no$psx v1.9, which includes low-level cdrom emulation using the new cdrom bios dumps. Some more info on how to use the low-level stuff can be found here: http://ngemu.com/threads/no-psx-v1-9-re ... 14.162481/

The dumps need to be 16.5kbyte .ROM files in plain binary format. The ASCII format .S19 files won't work. I am puzzled why Trimesh used that format anyways. That .S19 format is a Motorola format - but it isn't used anywhere on psx cdrom cpus (the 52pin chip bootstrap roms do support ASCII output, but even that ASCII data isn't in .S19 format).

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

Post by TriMesh » May 29th, 2014, 12:43 pm

nocash wrote:I've just released no$psx v1.9, which includes low-level cdrom emulation using the new cdrom bios dumps. Some more info on how to use the low-level stuff can be found here: http://ngemu.com/threads/no-psx-v1-9-re ... 14.162481/

The dumps need to be 16.5kbyte .ROM files in plain binary format. The ASCII format .S19 files won't work. I am puzzled why Trimesh used that format anyways. That .S19 format is a Motorola format - but it isn't used anywhere on psx cdrom cpus (the 52pin chip bootstrap roms do support ASCII output, but even that ASCII data isn't in .S19 format).
Because I wanted a format with address information, and SREC seemed the natural choice because it was the one that the original Motorola tools used. Personally, I don't like the raw binary format because it has memory dumps from two different areas of ROM just concatenated together, so the loader has to be specially written to handle it.

Yuri^Cybdyn
Verified
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 » May 30th, 2014, 7:39 am

oh, no$cash, it's super interesting to see how you research what inside of sub-cpu of cd-rom. in result you leave tons of information on your page.
but it's hard to gather all pieces in one ))) especially asm code of motorolla.

is any chance if you make in result some kind if macro or high level interpretation of how how sub-cpu works?
something like: make from asm of Moto to "C", or any macro definition.
in result someone can use it, for example we can try such code in PSIO, as we actually make cd-rom emu in hardware it's fpga side, and software by ARM.
but of course, i tried make algorithm from high level point of view, or how it defined in most cd libraries.
in result , not all games works properly. or doesn't work at all.

just my 2 cent how to use a lot of your information in real. are you interesting in this, or you prefer hide details in secret. i can report all my tests or leave all sources somewhere if you wish. as our goal is to make cd-rom emualtor from SD (or HDD in future). your researches can really help for it.

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

Post by nocash » May 31st, 2014, 4:32 am

Charles MacDonald dumped a DTL-H3001 (Yaroze) NTSC:U/C version Late-PU-8 board (1-658-467-23) with 52pin chip "W2021, SC430926PB, G63C 185, JSAA9645A" and CRC32=DF333241.

Concerning the BCD date (18 Aug 1996), it's much newer than for normal Late-PU-8 boards, it's almost as new as the later PU-18 version (or concerning the chip number (SC430926), it's even newer than PU-18, despite of using a PU-8 board).

The actual BIOS is nearly identical to the Late-PU-8 chip version (makes sense since PU-18 used different chipset). Main difference is a small bugfix (that bug did exist in PU-8 version, and was also fixed in PU-18 and later versions). And and of course there are some region differences:

It does accept SCEA,SCEE,SCEI discs, and SCEW discs (dunno if any such discs do actually exist - maybe the Yaroze boot disc has a SCEW string on it - if so, then it should be visible when using cdrom test command 19h,60h,01h,D0h..D3h to read the SCEx string from RAM at 1D0h..1D3h).

One odd gimmick is that the GetID command returns "SCEA" for SCEA discs, but for SCEI/SCEE/SCEW discs it's returning only four ASCII spaces (20h).

The region test command returns "for NETNA" (instead of "for Europe" or "for U/C" etc.) and the Secret Unlock commands want "World wide" as region ID for unlocking unlicensed CDRs.

Does anybody know if there other Yaroze versions? Theoretically, as it's region-free, the SC430926PB chip might be also used in Japan/Europe, would be nice if anybody could verify that! And does anybody know the Yaroze's Lifetime? Wikipedia only mentioned the yaroze-based games were released on demo-discs until 2004. But I don't know if the console was kept in production until that year, too? And if it was kept production for several years: Are all Yaroze's using the relative old Late-PU-8 mainboards?
Last edited by nocash on June 15th, 2014, 10:14 pm, edited 2 times in total.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest