walter.comunello
@walter-comunello
Forum Replies Created
-
resurrected a Saturn VA0.5 NTSC-J just by replacing 5 capacitors surrounding the PLL: CE18 & CE19 (tantalum polymeric), CE20 & CE21 (tantalum) and CE22 (MLCC).
Extreme jitter on DOTCLK was found before recap. This is a recurring issue with this problem. No jitter was detected after recap. System booted immediately and asked for clock.
No freezes so far.
The system cannot find the medium. Focus is not occurring – I believe because the lens is very dirty, probably corrupted, on the inside.
Next step: replace daughterboard caps and Optima-6.
Seems to be more of a manufacturing defect as older consoles don’t seem to have this issue.
extended rusting was found on the metal parts of the ODD. I suspect it was kept in a very damp place or water poured in at some point, was picked up and dried somewhat and left there. Many joints were completely detached from their copper pads although they still had factory solder on them. Copper was oxidized. I have no idea if factory solder job was good at all.
Whatever happened, humidity crawled under weak points in the solder joints and ate healthy copper away. Luckily a very thin layer of oxide formed and protected the metal underneath – no copper pad was destroyed, they just had to be scraped to expose the healty metal. I was proficient enough to only rip 1 NC pad from a SH-2 footprint, cut another on IC3 (IC3 has extremely long pads so it wasn’t a big deal) and partially rip one while reattaching the VDP2. I still have to reattach the OCU, SH-1, SMPC and IC6 (DRAM controller?).
The laser lens is very dirty (no amount of IPA polishing cleaned it, most likely dirt, grime or humidity gathered inside the pickup body) and I think it will never work again. I have to see IF I can even make the motherboard do anything at all, THEN focus on the ODD daughterboard, THEN see if I can do anything to salvage the ODD frame, THEN see if I can find a replacement laser pickup. Thankfully everything is healthy enough to see what model it was.
I have ordered a Pico PSU and a 12V-5A power supply since its original PSU might be too dangerous to use – I have inspected it and there are no evidence of failure, but I cannot be too sure, it could burst into flames or pump 9V or more on the 5V rail, I don’t want to take the risk after all the work I have already done.
thank you for your words of praise. But Goldilocks should still be considered in “pre-alpha state” since I believe it has somewhat destabilized the SMPC through DOTSEL, and hence should not be used (yet). It does output the correct frequencies though, but it needs a better interface with the Saturn. Maybe it just has to be driven by a transistor but I have no idea what kind of output the SMPC gives – but I’m fairly convinced it stays on a microcontroller GPIO port, which has a specific output impedance that must be followed (at least in a safe zone) to be considered stable. I just ripped Goldilocks out of the system as soon as I realized the PLL was working again.
As far as I could understand, “black screen” can mean a lot of different things. One should first investigate if it is really a “black screen” or a “no display” issue. “Black screen” means the encoder (CXA1645M) outputs a signal that the TV can understand, but there’s no image in it. “No display” however means the encoder does nothing, either because of no/out of spec power (broken/rotten traces, dead caps, faulty PSU) or because the encoder is cack (rare but it can happen). In modern TVs this means no audio either, so the Saturn might appear dead even if it has no ways to communicate its state to the outside world.
“Black screen” instead can imply a communication failure between any of the 8+ chips on the motherboard. Since there are A LOT of connections between chips, A LOT of things can go wrong, and the joint refreshing work on all chips can help tons to fix the issue, since it restores communication. It can also mean that the VDPs or the audio circuitry fail to handle signals for some reason – dead chips could be a cause (very unlikely but not impossible), but a chip cannot work properly if its clock is messed up – it might mishandle a very low rising edge (coming back from an undershoot) for a falling edge or vice versa (getting down from an overshoot). Hence, PLL or impedance matching might be crucial for proper signal transfer. This can happen on data or address bus(es) as well; a falling edge instead of a rising edge at the wrong time can push the wrong instruction in a chip, causing illegal or unknown instruction errors, freezing the machine without warning. The Saturn was not designed to communicate these errors to the user (at least not with standard software) so addressing and diagnosing these kind of issues can be very challenging.
This experience boosted my motivation to deepen my understanding of Saturns though. I would be delighted to explore more systems.
Although I’m not 100% sure of the “PLL gets damaged because of too much heat” thing. Based on what I’ve seen, the Saturn feels so delicate and sensitive that I believe the PLL is just a tiny part of its problems, if anything. I might be incredibly wrong though. Only working on more Saturns will allow me to gather more useful information.
so I have been working on a Model 1 Saturn with the black screen issue. You can see some data here. I did not want to go off topic too much so I’ll just put the rest here.
Long story short:
1-I’ve built a PLL replacement (I’ve named it “Goldilocks”) with a CDCE937 that works. Not perfect, but “just right” (hence the name).
2-Output clock(s) weren’t satisfactory so I worked them a little both on Goldilocks and by handling on-board impedance mismatching (with 18 to 47 ohms resistors and by placing carefully 20pF caps as close as the target chips as possible) and oh boy, there’s plenty of them on older electronics. It’s nuts how much hardware changes at molecular level with time.
3-It had been a bit disheartening at times since the Saturn would STILL be unstable and freeze randomly, even though clock inputs were as close as ideal as I could make them. Then I started to go sideways and scope probed all over the place, because it’s just what I do when I’m out of ideas.
3.5-as a side quest I have found out that not all ground joints are the same.
4-I found nothing significant. Everything worked just fine… until it wouldn’t, and I had ABSOLUTELY NO IDEA why. I would just make wild assuptions like internal ringings, overshoots or undershoots (that reflect on many outputs).
5-In the meantime I started replacing caps here and there and see what would happen. I tried to use the highest quality I could find in house (Nichicon for PSU, Panasonic ECE series for main power caps on board, bought specifically for Saturns) and some Kemet to put in the place of a few 10uF to decouple some stuff. The Saturn would get worse. I began to give up.
6-I used some Taiyo Yuden 100uF MLCCs to feed the two SH-2s and two central caps near the damaged 315-5746. It would make no difference.
7-In a stroke of luck I found some Kemet 1411 tantalum polymeric 100uF 6.3V laying around and I used them in place of the MLCCs I just installed. I thanked the past me for that gift. I had a good feeling about that.
Final point: it’s been standing strong in the boot menu the first test for 1 hour, then it’s been going for at least 10 minutes again after a power cycle.
Model 1 Saturns are EXTREMELY fussy and tricky to work on. There’s a wealth of information to be known JUST to be able to work on them. I’ll operate on it slowly to see what happens next. One of the next moves are to completely remove the 315-5746.
SCSP and VDP1 are conflicting over their clocks. I believe it’s because MCLK1 has a misshapen form. I have to work out the kinks. This goes beyond the PLL, this is a more widespread problem. Clocks are degrading all over the place and to get them back in shape is nothing short of wizardry.
Edit: clocks are good, or at least as good as I can make them. Still the system struggles: after replacing a few caps (the two main elec at the bottom left and two elecs decoupling the SCSP and the VDP1) the system would almost always refuse to boot, or freeze soon after. I’m gonna try reflowing all main chips tomorrow.
I feel like I’m doing one step forward and two steps backwards. These machines are annoying.
will be testing some sort of impedance matching on Goldilocks output, switching to 5V for buffers, then capacitance adjusting on each of the four MCLK zones:
VDP2 (IC14) and the SCU (IC5) are fed with MCLK0;
VDP1 gets MCLK1;
the two Hitachi CPUs chew on MCLK3;
the Toshiba controller has MCLK4.
(MCLK2 goes out through pin B66 of CN1 and has no business with the Saturn itself so I might not consider it an issue – but it’s not terminated by design and it might need some work as well.)
They all come out from the same source, have the same frequency, are driven by the same service signal (DOTSEL) and they switch at the same time, but impedance matching on this level of complexity and years after manufacturing can be tricky. A master clock going all over the place in an old device can pick up all sorts of garbage – and reflect it up the pipes. So a problem on the VDP1 end of the clock might cause the Hitachis to freeze, or vice versa. I wouldn’t be surprised if this happened.
Please let me know if any of you have any information I don’t know of. I consider myself a n00b and always in need of learning something.
