SCPH-1001 that is booting shy

[MasterLink]

I obtained a unique SCPH-1001 from eBay with the knowledge it was already broken, but I'm left dumbfounded by this fault. It refuses to boot anything, and I mean anything. But here's the kicker, while the laser is rather noisy, it does actually work just fine in my SCPH-5501, and likewise, my functional BAM laser does also work in the SCPH-1001, but the same issue happens, it simply will not boot.

I'm going to attach a picture from the eBay listing, as it's precisely what it's doing here. Notice the corrupt "Licensed by" text, repeating the second half in the first half, and the stray Polygon on the P logo itself. I thought perhaps it could be a RAM issue, but I'm not entirely sure.

bafkreidvwlzilwynrav5iintkq2sznqcowdtnrngqmum6tmz25fxt2e6wy.jpg

What I have done to troubleshoot: I tried the BAM laser, no chance, same corrupt line and stray Polygon. I then tried using Unirom, and here's where things take a very odd turn: Unirom cannot boot discs either, be it CD-R or original games, the error is the same, it claims the disc is unreadable or the drive is locked. But with real discs before it states this, it'll say it's a licensed disc, yet the drive refuses to unlock itself, so we get nowhere fast. Again this is true with either laser I try, it just won't unlock its drive.

I'm not entirely sure where to go, but I have a DSO and probing RAM doesn't show any unusual bits being stuck high, low, or floating. Everything is seemingly working, so I think this may be a fault potentially in the Mechacon itself? I did notice a massive amount of flux residue on the bottom, so it clearly was reworked from the factory at Sony, yet when I opened it up, the self-tapping screws made the distinct snapping sound, indicating I'm the first inside the machine since it was built.

Any ideas that would cause this? Some games can progress past the license screen, and the drive will move to one position then lock up. Or some games it just says at the license screen. But with Unirom also unable to coax the drive into doing anything either with legit or CD-R's, I really am starting to suspect a failing Mechacon itself, unless anyone has ideas?

The unit has BIOS revision 2.2, and is a PU-8 subversion 22 (so a revision C GPU with SGRAM). It's otherwise a remarkably pristine unit, better shape than my personal SCPH-5501, so hopefully I can figure this one out. I just don't know where to begin since RAM wise it appears fine, so the corruption in the P logo and license text is happening elsewhere. (And no matter what disc I use, the stray polygon in the P is always the same, it doesn't change, same with how the Licensed by text shows up as " ed by ed by", it's always the same no matter the disc.

(I'd like to add that it is functioning just fine as a CD audio player. Though, not sure why people call these models "audiophile" grade, it sounds rather standard to me, but it doesn't skip, and plays through whole albums just fine.)

[MasterLink]

After removing the mainboard, there's a LOT of rework and flux residue around the CD-ROM controller (and rear of the board as well). I'm going to clean this all up, try again, and if it still fails, reflow solder. It sounds like it wants to work, but with Unirom thinking the disc is unreadable or the drive is locked, yet the actual boot ROM can at least get somewhere before locking up, there's got to be something lose somewhere, or maybe the residue itself has become semi conductive. I'll report back later.

Basically, if it involves the CD-ROM drive, something weird is happening when it's data or involving reading the licensea.dat, but NOT with CDDA (which is strange but I guess could make sense partially).

UPDATE: Cleaning and reflowing the area did not change anything. I'm a bit blown by this, it clearly can see CD's just fine, but Unirom can't read any contents of any CD no matter what laser I have in stock is used (and the eye pattern on my scope looks great!). However, borrowing a PSIO proves the console CAN boot and run games.

I guess the CD-ROM controller is just shot somehow, I don't know where to go from here or if there's any test points I can go with.

EDIT: Nevermind, I guess the CD-ROM controllers are just failing then. viewtopic.php?t=846

Found that thread here just last year with an identical fault. Great and wonderful. I bought something with a part I cannot replace.

[MasterLink]

Probing the 32K FIFO SRAM's IO lines, correct me if I'm wrong, that ain't a square wave.

dso_01_01_00_34_36.jpg

[nocash]

Are that the SRAM data lines, D0..D7, and all eight of them looking like that?

The falling edge looks fine. The rising edge not so. But I am not sure if that's wrong: If the cpu is neither reading nor writing data, then the databus may be floating high-z, which could look about exactly as on your scope picture.

Can you measure /OE and /WE on the second scope channel, to see if the low pulses correspond with those signal, and if the weak rising edges occur even while /OE or /WE are low?

Or, if you have another (working) console disassembled, check if the signals look like that there, too.

PS. From the HC05 cpu info in psxpsx, "For PSX, OSC is 4.0000MHz (PU-7/PU-8), 4.2336MHz (PU-18 and up). SysClk is usually set to OSC/2, ie. around 2MHz."
That, I assume that one memory cycle is 2MHz (0.5us). Your scope seems to be set to 5us per divider, which doesn't have enough precision. Better use 1us per divider (then one memory cycle should be a half divider tall).
If the cpu is doing a 16bit read or write with 0 and 1 bits in first and second half, then you should see nice rising edges (as opposed to the weak rising edges, which might occur when no data is transferred).

[MasterLink]

Indeed, from the points I could probe from the upperside of the board (due to the SRAM being on the bottom of the board), all data lines looked like this with slow rising edges.

I'll try later to re-adjust the scope and involve the second channel to see what /OE and /WE are doing. Last I checked (but no CD drive attached so the test was highly likely invalid), at least /WE was simply high the whole time.

I'm guessing this SRAM isn't used in any way for CD audio playback, since that sounds just fine.

I have an SCPH-5501 which I am fairly certain uses the same CD controller (though a very smaller package SRAM), so I should be able to test off that one as well to see if it's different or the same.

[MasterLink]

Ok here's an update. Had to locate where OE and WE were on the top side of the board. Luckily the via's are RIGHT there just under (and beside) the IC305 silkscreen itself. Ignore channel 2's voltage per division, had the wrong X setting on the channel as I last used it with x100 probes, in reality it's healthy and where it should actually be. (I'm also aware after the fact I had both traces laid on top of each other when I should have separated the traces, I just woke up and wanted to get this done, but I can verify that when low, there's no "laziness" observed, confirming what you had stated).

Based on what I see, it does appear that when either WE or OE are low, there are good square waves, but whenever high, it turns into a sawtooth, so I can see what you were saying.

/WE

we with slow rise.jpg

we with fast rise.jpg

we with fast and slow rise.jpg

/OE

oe with sawtooth.jpg

oe no activity.jpg

oe high activity.jpg

It was shockingly hard to capture this as it seems it only once in a while uses WE/OE and occasionally reads or writes data during the boot attempt, but after it crashes at the "ed by ed by" screen, it does continue to go low on WE and OE both even when seemingly frozen, so I guess it goes in a loop or it's just an invalid state at that point.

(I'm willing to probe anything else, but I'm also ready to accept the fact that IC305 is simply dead. I did observe that /WE is barely ever held down long enough, it just pulses as the screenshot shows. If it does do anything more than just a pulse here and there, I certainly didn't see it, but my DSO refreshes every half-second, it's not entirely fast.)

[MasterLink]

After chatting with a friend of mine who worked at EA Tiburon during the development of Madden and other sports titles in the late 90's (I worked in the same area when he still worked there, but this was PS3 era, we frequented the same Subway for lunch), he offered to send me a "special 1001" that he confirmed is a PU-7 revision that does read CD's just fine (albeit when upside down, which I can fix, we all know that symptom).

I asked what's special about it other than being a PU-7 and he won't clarify, simply saying "you'll see".

Either way, I have a functional SCPH-1001 on the way. So I guess this 1001 will just be a CD player unless we can determine why IC305 failed, but I doubt it's worth troubleshooting any further if a working console is en route. Whatever this thing is.

[MasterLink]

Just wanted to update you nocash, IC305 really was the fault. I didn't have another CXD1815Q to replace with, however I did have a CXD1199BQ which appeared to be pin-compatible. Sure enough it was a drop in replacement despite being an older part, and worked out just fine. It boots now. (Didn't need to adjust the bias or anything, but I'm assuming that's because I didn't replace the DSP.)

[aaronramsdale]

If you have a spare PU-8 board, swapping components like the Mechacon or GPU might help confirm the failure point. Otherwise, checking board traces for damage,Block Blast cold solder joints, or any suspect capacitors near the Mechacon could be a good next step.

[MasterLink]

Swapping the GPU would do nothing, it's not a GPU failure.

It's already diagnosed as IC305. The scope already proved /WE is only being pulsed, not properly held down so the FIFO can ever properly be written to. This is already a diagnosed issue and needs no further assistance.

[nocash]

Does the console still work with the replaced CXD1199BQ chip?
(The repair was interesting. But, as far as I remember, a few days after replacing that chip, you had mentioned eleswhere that you don't have a working SCPH-1001 cnnsole? I am a bit confused on whether it's working or not.)

And did you try to reflow the old chip before replacing it by the new CXD1199BQ chip?

I don't see anything wrong with /WE in the scope pictures.

Uhm and, sorry to say that: What I had said about the 2MHz and 0.5us access time for HC05 cpu wasn't very well thought (the SRAM isn't wired to the HC05 cpu at all). And my suggestion to measure 1us per divider wasn't very good.

Going by the CXD1199AQ datasheet https://datasheet4u.com/datasheet-pdf/S ... ?id=199640 you would have probably needed 100ns per divider to measure that signals.

The datasheet has a timing diagram for Host DMA cycles. That suggestes DMA transfer rate timings with... something more than 100ns.

And the datasheet has some obscure note about DMA having a "XSLOW" option (for fast or slow SRAMs). The PSX supports double speed CDROMs, so it must use fast SRAMs. And it says that fast DMA takes "4 clocks". But without going into detail about what kind of clock that is referring to (maybe 16.9 MHZ clock, but there are also other clocks that could be up to 33.3 or 35 MHz). Anyways, the DMA is probably somewhere beteeen 120ns and 250 ns.

But that's all for DMA timings. The datasheet doesn't seem to describe the acrual SRAM buffer timings at all.
The SRAM access time might be yet faster than DMA.
And the /OE durations might be yet shorter than the total SRAM access time.
In your last scope picture, there seem to be eight /OE pulses per 1us. So one memory cycle would be abour 120ns.
And /WE might be even shorter than /OE, perhaps only half of it, or even less (as far as I remember, /WE should applied only once when the data on the databus is stable, not for the whole memory access duration).
The SRAM datasheet should have details on the minimum /WE duration.

[MasterLink]

So this SCPH-1001 was purchased to fix and re-sell (was going to keep, but once the DTL came in, there was no need to keep it), but at the time I didn't know the issue. It's good to know that /WE was actually correct (though I incorrectly felt it wasn't), though indeed replacing IC305 did actually work. That console was then sold. To date, I haven't heard any complaints about it, as I did warranty it for a year (and in general, even if past warranty I'll still help out for free just for good business). I even gave it a burn in test, constantly streaming a disc full of video via the PIMP player, and it never failed. Then played some games as well, no issues. I never even needed to touch the POTs whatsoever. (I don't think this IC is the one that would be sensitive to RF, bias or push-pull adjustments anyway.)

I did try reflowing it, including the 32K FIFO on the bottom, but neither helped. It wasn't until 305 was replaced that it started working. (Though I need to be honest here, the first reflow of IC305 caused the PSX to stop booting the BIOS entirely, but nothing was bridged under a microscope. When reflowed a second time, it came back to life, but again "ed by ed by". I consider this a fluke though, as perhaps the first reflow wasn't perfect and never bothered to blame the IC for it, but myself.)

After it was sold I obtained another SCPH-1001 with the same issue as I wanted to see if this was indeed a common failure mode with IC305 always being the culprit with "ed by ed by" as the issue is 100% identical, down to only being capable of booting Unirom (via swap trick), but like the other system, it claims the drive is locked or unreadable (despite being the very Unirom disc it just booted). Since obtaining the second 1001 with the same issue, I haven't bothered yet to find a donor board for it, but did reflow this one as well, and no dice.

I did however discover, it appears the Sony "Data Discman" not only uses the same OPU as a PSX (the plastic type), it also has the same CD Decoder IC as well. Though I'm not keen on taking parts from a Data Discman, being those are a bit more rare than a PSX. As the SRAM is far easier to obtain, I will be trying that first, but I have a suspicion it's IC305, especially since someone on Reddit (to be taken with a grain of salt of course) did claim their issue as well was IC305 who also had the "ed by ed by" problem.
--------------------
I should have clarified there was two SCPH-1001's being referenced, this one which was sold, and now another one in my possession with the same fault. (So technically as far as SCPH-1001's are concerned, I am back in square one, but not with the initial unit, though I'm 90% confident it's the same IC). Wish I knew why Unirom is the only thing that boots though, perhaps because it's very small and squeezes through whatever issue is happening.

EDIT: I just realized my signature NEVER reflected any of this. Perhaps that's where the confusion came from? Either way it's not wrong right now since there is indeed another 1001 in the home, but the one in my signature technically was referring to the original in this post. I just forgot to ever change it.

[MasterLink]

Just to avoid confusion:
This is the original one that started this post, which I no longer have since it was re-sold.

Screenshot 2025-02-12 195218.jpg

And this is the one that has the same issue that's also an SCPH-1001, that is still in my possession. I *was* going to sell it to someone who asked for a for parts PSX, but they meant the PS2 DVR, not PS1 apparently, so it's still in my possession.

Screenshot 2025-02-12 195422.jpg

[nocash]

Thanks, sounds as reflow didn't help, and that new chips are needed. And if it was sold, that's fine, I just wondered what happened to it.

I've no experience with buying old chips, but it looks as if you buy them online. There are some CXD1199BQ's. And CXD1815Q seems to be available en masse. But I don't know how much they cost, and if the chips are really intact and working.

There also many CXD1199AQ's but those were probably never used in PSX, I don't know if they are compatible with CXD1199BQ, going by the datasheet they are only 99% same, so they probably won't work).

And of course one could replace the cdrom drive by SD card based PSX drive emulators, which should completely bypass the old cdrom chips, so it shouldn't matter if they are broken or not.

[MasterLink]

I was actually wondering about the SD options, such as Xstation or PSIO. To be truthful, I wouldn't mind having a PS1 that is using SD cards. I was highly tempted to install an Xstation in the DTL just because I really don't want to burn so many CD-R's, but apparently as per someone on Discord who tried this, they don't work on DTL's. (It was either Xstation or PSIO, I can't remember now).

I might be willing to try a CXD1199AQ in a PS1 just to see in case it does actually work (as long as there's no possibility of a ground or vcc pin causing a short somewhere), but in general I source the chips from donor boards by buying for parts machines. Either state side or overseas, whichever is cheaper. I also nit-pick my purchases by selecting those who've at the very least, explain what is actually wrong rather than just saying "junk" and nothing else.

EDIT: I was curious to be sure that the customer that got sold the repaired PS1 from this initial post hadn't returned to the game store that sold it, and called to ask, no complaints, in fact earlier in the week they bought 9 more games for it. So it seems to really be holding up rather nicely.

[blockblastonlinefree]

I love how Block Blast challenges my mind without being too complex.

[leque126]

That particular corruption — especially the consistent nature of it — is incredibly suspicious and likely points to VRAM corruption or GPU bus issues, rather than main subway surfers RAM. The consistent “ed by ed by” duplication hints at a data handling failure (DMA or buffer misalignment) — not random bit rot.
Also, given the stray polygon on the “P”, that tells us the GPU is not interpreting or rendering data correctly — or is being fed corrupted commands.

[MasterLink]

Piss off bots, both of you. Especially the GPT based one pretending to answer the post while sneaking in a random URL to a nefarious site.

[snaptubedla]

The SCPH-1001, one of the original models of the Sony PlayStation, is known for its high-quality audio output and nostalgic value among collectors. If it's booting shy—meaning it's hesitant to start up or inconsistently loads games—it’s often due to age-related wear, particularly in the laser assembly or power supply capacitors. Pikashow is a Third Party Application that is to Enjoy Free Streaming App Download Any Movies, Web Series, Anime Tv Shows and Live Cricket.

[snaptubedla]

Common symptoms include the system freezing at the startup logo, struggling to read discs, or needing to be tilted or warmed up to function. These early units are beloved, but they often need a bit of cleaning, realignment, or part replacement to fully revive their classic charm. ReVanced App is the patched version of Vanced App to continue its legacy after discontinuation of the ancestor app. This new version has all those powers and features to patch YouTube and other Vanced apps.