SCPH-1001 with Revision 2.0 BIOS?

[MasterLink]

I thought the SCPH-1001 launched in the US with 2.2, at least according to Wikipedia. But my friend from EA when he worked there, sent me a "special" 1001 and wouldn't clarify what he meant, other than the laser was faulty. Swapped it with my BAM and was blown away, it boots FASTER than a SCPH-5501, so fast that the Unirom disc booted before the P logo music completely even faded out.

But it also identifies itself as a "KT-3"? I've not seen this before at all, and the boot ROM outright pre-dates the US launch, dating in May.

Is this a prototype? There's no sticker on the bottom whatsoever to identify if it's an SCPH or DTL, but it IS booting CD-R's and there's no mod chip to be found. The mechacon is also massive, it's nearly 2x larger than any mechacon I've seen previously, but it isn't PU-7 like he thought, it is indeed a PU-8, subversion -11.

I can't get over how well it works, even my cheap CMC Magnetics CD-R's just simply boot, fast and don't skip whatsoever.

(I've tried to attach a picture from Unirom's status screen but this forum keeps saying the JPG is invalid. Even re-encoding it didn't help so I'll type out what it says:

-1000 KT-3 By S.O.
System ROM Version 2.0 05/07/95 A
BIOS CRC32: 55847D8C)

[MasterLink]

Here's a video of it in operation:

I'm not sure what it is, I guess it's a debug kit that's simply gray? Ironically Unirom can tell it's booting unlicensed discs and will say it's applying the nocash patch, yet it booted the Unirom disc itself without such patch (or any other media for that matter). Which is unlike mod chips that will make Unirom say all discs are licensed (even CD-R's) so it certainly does behave a bit differently.

Either way, it's my first rev A GPU model and I couldn't be happier, it seems to simply be a very early system if not perhaps pre-production. Hoping for more answers on it.

Upon reading this over: https://www.psdevwiki.com/ps1/Motherboards
It appears this must be a pre-production PU-8 then, because inside was a sticker dated 10/4/95, yet it's PU-8 subversion -11. This pre-dates what most sites state.

[MasterLink]

I guess I should have just asked my friend what it was since I had now received it. He had answers. Basically it's a DTL-H1001 that a previous employee removed the sticker on before a trade show event (he doesn't know why since they were locked in kiosks).

So it's not rare, not a prototype, it's just the infamous gray DTL-H1001. Well, guess I officially have a debug kit now. Cool, I totally overanalyzed this thinking it was a SCPH-1001 this whole time, thanks to it not having a sticker. I guess DTL's simply got PU-8 before the SCPH's did.

[nocash]

Interesting anyways. If you are up for some soldering and making some custom transfer software, the cdrom firmware appears to be still undumped,
https://www.psxdev.net/forum/viewtopic.php?t=557 cdrom firmware dumping
The BIOS kernel rom chip part number is also still listed as unknown,
https://www.psxdev.net/forum/viewtopic.php?f=70&t=1065 kernel rom part numbers
Although, going by this thread,
https://www.psxdev.net/forum/viewtopic.php?f=55&t=1603 DTL-H1001H
It's probably some 27xxx prom, unless your board has something different?

[MasterLink]

(Still can't for some reason upload pics here, says my JPG's are an invalid format even though they are JPG and only 600K).

The ROM is luckily marked and not a PROM so I can contribute to this:
(C) SONY COMPUTER
ENTERTAINMENT INC.
KF5202Y 2000
KM23V4100CG-15

I'll link to a picture of the ROM outside the site for now: https://i.postimg.cc/XvvC86Vf/IMG-20250112-160641.jpg
(Hope that helps.)

I can certainly see about dumping the CD-ROM controller (that however is not a Sony part, it's a Motorola part like the person with the DTL-H1001H), it'll just be slightly backburnered for now since I've been having some shaking issues (been a few doctor visits, but that's a story for another time, you probably saw the shaky video in the original post, it's related, and tldr, I "might" have onset parkinsons).

I was wondering if it could be the DTL-H1001H rather than a DTL-H1001, but mine doesn't have S-Video output, and it appears some gray units were marked as H1001 without the trailing H (on Consolevariations website), and they too lack S-Video output it seems. Another difference with mine as compared to the other person with the DTL-H1001H, is their CD decoder is a CXD1199BQ, whereas mine is a CXD1815Q, in case it matters).

[MasterLink]

Well now as I officially own a debug kit, I've learned something about them I didn't know before after using an SCPH-5501 with an MM3 installed: Games that have piracy checks, will fail those checks on a debug kit, but usually pass with a MM3 equipped system.

It makes sense now that I think about it, but it didn't dawn on me that that's the point of "stealth" mods, of which a debug kit only lets you boot them, after that if a game commands to check for the SCEx strings, it won't stop the game from doing it (and thusly, not finding it), whereas a chipped system will pretend to read those strings. I guess in my head I assumed the mechacon in a debug kit pretended too, but that really wouldn't make sense since it boots with the SCEA string omitted when CD-R's are used.

EDIT: Forgot to mention, the sticker actually was in the box. Somehow it fell and lost adhesion, so I re-applied new adhesive. It's serial number is 300134 for reference, and is indeed DTL-H1001H. I found it a few days back and just didn't think of updating the post.

[ViewMan]

It's really interesting that this turned out to be a DTL-H1001 instead of an SCPH-1001. The early PU-8 board and how smoothly it boots CD-Rs is amazing. Even if it’s not a prototype, having such an early debug kit is pretty cool. Thanks for sharing all the details about the ROM and CD decoder

[MasterLink]

Yea I honestly didn't think "debug kit" when I opened the box. When I was told "it's special" and saw gray, and it looked like a normal SCPH-1001 to me, I just thought it was a rev A GPU like was on my wish list of things to own for my collection. I had only heard of the myth about gray debug kits, and with this unit lacking the sticker (before I found it later in the box that is), I just didn't know anything about it. It honestly wasn't until I booted a CD-R and noticed it jumps right in, very unlike a chipped PlayStation (which will say SCEA no matter what), and then I started connecting the dots until I asked my friend to clarify exactly what this unit actually was.

He doesn't know the history on it, but it was used more in kiosks, and might be why its original laser is SHREDDED. I can't get either the sled motor or spindle motor to spin on it, and the tracks are seriously gouged, so it's seen a LOT of run time in its life, but from what I gather, post 97 E3 it was used internally for debugging, and newer trade show models with better GPU's were used on the floor instead.

The only thing that does floor me though is the serial number, 300134. If this was made in August of 1995, I'd assume the serial would be perhaps 1000 more units than that, if a DTL-H1001 I saw on Discord by another user, whom has a serial just 50 units under mine, and was built in the first quarter of 95. So I don't know if the blue units and gray units are numbered differently (as theirs is blue, not gray), or if perhaps this had repair by Sony and the mainboard was simply replaced at some point, as mine would be around 3rd quarter of 95. So in two quarters I don't see only 50 of these being produced, if essentially mine and theres would be assembly line buddies (as I'd assume 50 in a day would be peanuts for a factory). (Ironically their DTL, that's blue, ALSO has a short Japanese style sticker like mine does that too lacks a part number for the sticker itself, so now I know my sticker I found in the box isn't actually fake as I've never seen a US unit with a Japanese style sticker). So Idk, I think maybe the machine had a fault and needed repair, but is still a super early unit even then because the "repair" took place still before the US launch.

I did have to repair it though after a couple days of playing games on it. I heard a nice lovely spark come from the PSU and the LED flicker. Luckily just cracked solder on the AC inlet jack. It's been rock solid again since. I do hate the idea of using it as my daily driver PlayStation being a debug kit, but I have to be honest, it just runs better than my 5501. (And my actual 1001 is completely dead, IC305 needs to be replaced). I was always told by the alex-free site that a 5501 has a better CD controller than these earlier units, but I'm quite frankly finding this to not be true, because if they share the same OPU, the DTL still reads even the cheapest of CMC magnetics discs that my 5501 fails to boot, and with authentic TY media, both will boot, but the 5501 eventually over half an hour starts "giving up", whereas the DTL just keeps going. Same with authentic media, Duke Nukem sits on the P screen for a good 15 seconds on the 5501, but on this older DTL it only sits there for just seconds.

I cannot in my right mind say newer PS1's have better CD controllers, unless my 5501 is going faulty itself (since the OPU isn't the variable in my test).

Either way it's been a fun surprise, it works great, it has some history possibly with repair and tradeshows, who knows where and what it did at this point, but being a part of EA Orlando (as it's now called), I have a few sports title related guesses, since the EA I worked near honestly did more of the licensed sports titles stuff.

[nocash]

I didn't notice that the video was shaky - but all the best healthwise!

Are you sure that the debug console is faster? The missing SCEX check could theoretically make things slightly faster, but that SCEX check happens before displaying the PS logo.

The duration of the PS logo display should mainly depend on size and loading time of the EXE file (and on the SYSTEM.CNF file and exe path, one could artificially create extra-slow disc loading with something like BOOT = cdrom:\1\2\3\4\5\6\7\8\2MBYTE.EXE with all directories and files on opposite locations of the disc surface, yet that's quite unlikely to occur in retail games). More likely, a lot of read/retry and error correction could slowdown loading.

The sound not finishing during the PS logo display time is a known issue, the EXE files (or at least small EXE files) do usually get started with an "undefined" SPU state, with about a handful of the 24 voices still being busy to play the PS logo sound.

[MasterLink]

Indeed, it does seem to be faster, and I've even swapped OPU's just to be sure. Both OPU's are re-lubricated, cleaned, and the motor is oiled (in the proper spot, not in the windings).

5501:

From power on to Konami logo: 52 seconds.

DTL-H1001H:

From power on to Konami logo: 29 seconds.

I guess there is the possibility my SCPH-5501 could be failing, but that extra seek test just makes it take longer to start a game.

The disc used was Taiyo Yuden CD-R's, at 4x from a Pioneer DVR-A06. The same behavior is observed with real pressed games as well. I know this wasn't quite scientific, but I think you can audibly (hopefully) hear that the 5501 just seems to do other checks that the DTL doesn't, beyond just checking SCEx.

SYSTEM.CNF for this game:
BOOT = cdrom:\NAUTS\SLPS_002.15;1
TCB = 4
EVENT = 16
STACK = 801fff00
------------------------------
Just to throw DuckStation in the mix with both consoles dumped BIOS:
DTL-H1001H BIOS on DuckStation with BIN/CUE: 29 seconds (exactly matching the real system)
SCPH-5501 BIOS on DuckStation with BIN/CUE: 29 seconds (not matching the real 5501).

Idk, maybe my 5501 is just failing, or it's the mechacon itself that's different? It's ironic that DuckStation's speed from my SSD matched the real DTL identically which was actually spinning a disc. I honestly didn't expect that. I'm willing to accept the 5501 is just failing since OPU swaps don't change its behaviors.

[MasterLink]

Just as a test, I tried Unirom on the 5501, does the same extra "gotta seek the entirety of this disc first", so I'm not sure then why the 5501 does that, because even Unirom is slower to boot a game. (For giggles I ran Unirom on the DTL even though it's practically useless there, but it still boot faster into the Konami logo.)

(I know the OPU in the 5501 is super noisy, but in the DTL the whistling goes away, so the 5501 is causing that noise. On pressed discs it's quiet on both, so the 5501 only whistles from the coils with CD-R's it seems).

[MasterLink]

(No shame bump above the spam)

I've come to the conclusion two things are happening here after borrowing a friends 5501.

My 5501 must have a mainboard fault, because it is way slower than it should be. My friends 5501, is still slower than the DTL-H1001H or SCPH-1001's I'm comparing them to, however not by 20 seconds. More like 5 seconds.

With that, I'm going to recap my 5501 and see what that does, because the eye pattern on the DSO cannot even maintain the right peak to peak without clipping. This to me usually indicates high ESR caps, which could explain why the OPU works just fine in other systems, but my friends 5501 does do that extra seek/sector counting thing (I don't know what it's actually doing, it does seem to scan the entire disc first before proceeding), it just adds 5 seconds to the boot time, that's it.

[nocash]

Did you use the same disc on the the 1001 and 5501's? And was it a retail disc? And just with the standard BIOS ROM, without any expansion ROM plugged into the connector at the back of the console?

I think, normally it shouldn't 'scan' the whole disc. Or only in unusual cases, like using a patched CDR, or maybe a CDR with faulty TOC, or a multisession CDR, and that somehow combined with a custom ROM bootloader.

PS. If you have the CDROM firmware dumps, you can tweak no$psx to emulate them at low level. I don't know if that could result in 5 second differences.

[MasterLink]

With *some* PS1 retail discs, it does that extra seek on the 5501, but not every game causes it. For example, Duke Nukem Time to Kill does indeed seek like this on a real disc on a 5501, whereas on a 1001 it does not. Same with CD-R's, some games do it, some don't, so it seems to be something about the games themselves that trigger this.

I know the 5501 supposedly added extra protection, and I wonder if this is it? Nothing was inserted in the PIO port whatsoever for these tests with retail discs. (Only a stealth patch ROM was used on the 5501 when testing a CD-R, but the same behavior was still observed with Duke Nukem Time to Kill with it removed since it's pressed, and that's a game I've owned since I bought it new.

I heard about extra protections against swap tricks, and I wonder if this is one of them, but being it seems to depend on the game, I'm not entirely sure then as not every game triggers this. Crash Bandicoot on the 5501 for example, a real disc, does not do this "scan" thing and just boots as fast as the 1001.

[MasterLink]

Better lighting, last day with the friends working 5501 so you can see. The 1001 DOES move the OPU to the end of the disc like the 5501 does (I didn't notice this before) but instead of "counting", it just instantly moves to the end, and back, but the 5501 for some reason is "counting" something which I assume are sectors). This is with Duke Nukem Time to Kill, the one pressed game I know that does do this.

5501 with retail disc under bright lighting:

1001 with retail disc under bright lighting:

While my 5501 is dying and already needs to be torn down, I might be willing to dump it's controller if it's easy enough for me to do. But I just am not willing to chance my DTL, sorry.

[david4599]

So, I just want to bring some information from my experience analyzing the SCEx checks, OPUs and trying to understand their spindle motor lubrication.

In the 5501 videos, the OPUs are clearly reading poorly just by hearing the sound they produce. The FMVs play well but that doesn't mean the OPUs work as intended since there is no seeking or change in disc speed while playing them.
With a perfect OPU, the 1x-2x speed changes and seeking should be smooth (no lens hissing noise when spinning up), there shouldn't be any loud ticks (lens loosing tracking/focus and resetting itself) or the disc suddenly increasing or decreasing a little bit its speed for no reason then going back to normal speed.

This "sector count", as you call it, is simply a seeking in a slow way. The only time it should happen in the normal boot sequence is when the OPU reads a game exe that is located at the middle or end of the disc and then the ReadTOC command (CdControl() 0x1E command) is issued to the CD controller.
This command will slow down the disc to 1x and do this slow seeking until it finds the leadin to read the TOC and do a SCEx check at the same time which will take a few seconds for these games. I guess the fact that some of them have their exe not at the beginning means that the people mastering them didn't know or didn't care to adjust the disc layout (see CDGen doc in PsyQ SDK) for a faster boot and they shipped the master discs to Sony like that which is a shame, unless there is a good reason I'm not aware of.

Another thing, in the videos, just before this "sector count", we can see/hear that the sled starts to move but goes back to home.
What happens is that the PS1 first tried to do a fast seeking to reach the exe but the focus/tracking was too bad while doing it that it resetted and it went back to home position, then it did this slow seeking to reach it probably as a fallback way.

Also, while doing some OPU swapping tests, I noticed that the 550x motherboard was driving the sled more quickly and "aggressively" than the 100x to get less seek latency and that increases the probability of seeking failures.
This explains why the 5501 does the "sector count" but not the DTL no matter the OPU as you say in the 1st DTL video.


To me, that looks like a poor lubrication of the spindle motors, I don't think the high ESR caps have a significant role in these specific seeking issues.

I'm still a noob at mechanics and their maintenance, oiling and stuff but I did some experiments and I think I finally correctly oiled 2 spindle motors from OPUs that had similar issues as yours.

Months ago, I tried spreading WD-40 at the back of the motor and that worked for a bit of time but the WD-40 evaporated and the reading issues appeared again.
Then, I tried fine oil but I put way too much of it and sure, the motor was completely silent but the OPU was reading even worse than before.

Then I learnt that we're supposed to put a tiny bit of oil in the right holes at the back and at the front of the motor like the guy says in this video (which is a motor from an old sewing machine but I guess the advices also work for the OPU motors?):
https://www.youtube.com/watch?v=MvdFrL3GlAU

So I cleaned the motor with isopropyl alcohol (no idea if this is harmful for the motor but that worked, it was rattling again) then I did put one drop in the proper hole at the back of the spindle motor.
I didn't see any improvements, the motor was still rattling even after adding one more drop at that same location. I was then thinking that I should try to add oil at the front.

I've seen this video where the guy puts the oil directly at the base of the shaft output:
https://www.youtube.com/watch?v=L_0SKz8aHRk

I did like him and that actually worked (not really easy to do because I didn't want to remove the fragile ceramic spindle hub to access the area to oil).
My two OPUs are now reading the discs way better and really smoothly even if that's still not perfect. No idea how long that will last though.

The following videos show the KSM-440ACM OPU from SCPH-1002 on SCPH-5502 before and after proper lubrication.
The game exe is located at the end (LBA 232216) and you will see that the OPU also does the "sector count" in the 1st video to reach it but that doesn't happen anymore in the 2nd video. Btw, this disc has almost no scratches.

Poorly lubricated (too much oil in windings):


Properly lubricated:


I should also mention that the caps on both my 1002 and 5502 motherboards are probably bad because the RF signal is lower than my 7502 and 102 with the same audio CD-ROM and OPUs (about 1Vpp on 7502 and 102 but only 900mVpp on 1002 and 5502).


Now, about the debug DTL, I knew they could boot any disc but I never took a closer look until now.
The boot sequence is quicker on those because the ReadTOC commands are simply not sent to trigger the SCEx checks again and these steps take some time to do depending on where the lens is.

Also, I noticed that the DTL has almost the same boot process as a Stealth Unlocker equipped PS1. Even though this ROM allows the normal boot sequence to play, the secret unlock procedure changes the behaviour.
To better understand, this may not be completely exact but I listed the boot steps on a normal 550x with/without Stealth Unlocker and on the DTL based on my own experience and by checking on no$psx with the debug TTY enabled to see the CD commands sent.

Normal 550x boot sequence with legit disc inserted:
1. Start spinning the disc at 1x speed, do automatic servo adjustments, quick sled movement then go back to home position in leadin
2. Read the TOC and do the first SCEx check at the same time (equivalent of ReadTOC command but done automatically, the main CPU is not involved), when success, the OPU goes in program area and pause mode is set
3. Wait end of Sony logo animation stuff
4. Send the ReadTOC command to seek in leadin, read the TOC and do the second SCEx check at the same time, when success, the OPU goes in program area and pause mode is set
5. Speed up to 2x
6. Read the license text and PS logo from disc
7. Display the PS logo screen
8. Slow down to 1x (no idea why, seems useless) then instantly speed up to 2x
9. Read the ISO 9660 filesystem stuff and then fast seek to read the exe
10. Send the ReadTOC command to slow down to 1x, do the slow seeking until reaching the leadin (will last a few seconds if the exe is at the end of the disc), read the TOC and do the third SCEx check at the same time, when success, the OPU goes in program area and pause mode is set
11. Launch the game (which usually triggers the 2x speed)

Stealth Unlocker (version 220814c from Unirom 8.0.K) equipped 550x boot sequence with CD-R inserted:
1. Start spinning the disc at 1x speed, do automatic servo adjustments, quick sled movement then go back to home position in leadin
2. Read the TOC and do the first SCEx check at the same time (equivalent of ReadTOC command but done automatically, the main CPU is not involved), the CPU waits until SCEx check timeout since no SCEx in leadin (usually takes 5-6s), then the OPU goes in program area and pause mode is set
3. Speed up to 2x
4. Read the license text and PS logo from disc
5. Display the PS logo screen (SCEx appears if correct SCEx region on the disc, otherwise no SCEx appears)
6. Slow down to 1x (no idea why, seems useless) then instantly speed up to 2x
7. Read the ISO 9660 filesystem stuff and then fast seek to read the exe
8. Launch the game (which usually triggers the 2x speed but here it is already enabled)

Debug DTL-H1001H boot sequence with CD-R inserted:
1. Start spinning the disc at 1x speed (no servo adjustments like above since they are manual on the board, current position is in leadin)
2. Read the TOC and do the first SCEx check at the same time (equivalent of ReadTOC command but done automatically, the main CPU is not involved), seems to success instantly then the OPU goes in program area and pause mode is set (infered from the multiple ticks in the 1st DTL video at 00:13, otherwise no ticks and waiting 5-6s for the SCEx signal like in retail 1001)
3. Wait end of Sony logo animation stuff
4. Speed up to 2x
5. Read the license text and PS logo from disc
6. Display the PS logo screen (SCEx appears if correct SCEx region on the disc, otherwise no SCEx appears)
7. Slow down to 1x (no idea why, seems useless) then instantly speed up to 2x
8. Read the ISO 9660 filesystem stuff and then fast seek to read the exe
9. Launch the game (which usually triggers the 2x speed but here it is already enabled)

[david4599]

Well, I just saw this video on servicing the PS1 drive, the guy seems to know his stuff and he shows exactly how we should lubricate the motors.


(which means that I still added oil in the wrong hole apparently like he's pointing out at 4:41...)

[MasterLink]

The motors are as lubricated as they can be unfortunately but yes the 5501's usual OPU has play in the spindle shaft itself whereas the OPU in the DTL right now has no play whatsoever. (I did observe play on my friends 5501, but didn't do much beyond that as it really wasn't my console to mess with.)

However the explanation about their differences does help quite a bit in understanding why the initial boot is a little different. In fact, I actually have observed the lower pitch seeking on the console and thought it was an issue, so thank you for basically telling me that's normal, lol. But I do have caps causing issues on the 5501, as the peak to peak on RF cannot be adjusted over 1v (800mV for CD-R, so too low for CD-R's) or the top of it gets flattened. The caps are already confirmed to be quite high ESR. The DTL's caps ironically are "perfect". It doesn't appear to need any re-cap whatsoever.

I've ultimately settled on just using the DTL as the daily driver since I don't want to keep swapping cables between systems, but do have the 5501 in my PlayStation messenger bag as the console to take on trips. Unirom is on a memory could should I want to boot a CD-R with it, but it's not very good with CD-R's in general until the caps are swapped. Pressed games however are good to go.

(In fact, once the games boot on both consoles, there's no speed drift between the two, other than the seek times being slightly slower on the DTL, so ultimately once a game boots, the 5501 ends up performing faster than the DTL in GPU performance (ok so a little speed drift, but this one's expected between the dual ported VRAM and SGRAM GPU's), and seek times. It only seems to struggle when woken up at the P screen, but beyond that it actually runs solid and faster.)

[MasterLink]

As for why the EXE may not be at the beginning and located elsewhere, I have zero idea why they would do that. Maybe they thought it was CAV when in reality of course these drives are CLV? That's the only reason I can think of maybe why they thought putting the EXE elsewhere was a good idea other than ignornace, since if it were CAV, then yes it'd read faster at the end of the disc than the middle (the LP record effect where the first songs sound best, and the inner songs less so). But since these are CLV drives, their data rate is constant, and at the beginning of course is the best. I've been mastering my ISO's with system.cnf first, then the exe. At least up until now since doing an MDEC demo and hello world demo disc. (The only two things I've done with my debug kit thus far really other than just play games on it, since I'm learning C at the same time as learning the PS1, but do come from an Objective C background, though this is a different beast).

[david4599]

Yeah, I don't think there is anything much to do if the shaft or its alignment is faulty.
I also noticed that my 1002 spindle shaft has a slight play but it's reading fine in the 5502 so it's not as bad as yours for now.

As for why the EXE may not be at the beginning and located elsewhere, I have zero idea why they would do that. Maybe they thought it was CAV when in reality of course these drives are CLV? That's the only reason I can think of maybe why they thought putting the EXE elsewhere was a good idea other than ignornace, since if it were CAV, then yes it'd read faster at the end of the disc than the middle

But even if they thought they were CAV, that still wouldn't make sense since they would set graphics and other big resource files at the end for faster reads rather than the exe which is small in comparison. So yep probably just ignorance. I wonder if Sony did inform on that somewhere in the docs btw.