Hello, I just wanted to ask you what the name of these is. When i tried to install the mm3 i accidentally removed one. Now i have to replace it... Is it even possible to find this part?
It's an smd resistor, but now i don't remember the exactly value, but it's the same value of the other two near it
The marking is 220, so the value is 22 ohms (the last digit is a multiplier) - the part is a standard 0603 (or 1608 in metric designations) SMT resistor, so there are many possible replacements for it - this one, for example: http://www.digikey.de/product-detail/de/ERJ-3EKF22R0V/P22.0HCT-ND/1746745 It's also worth pointing out that the machine will very likely still work (although with reduced noise margin) if you just replace it with a piece of wire.
Thanks for your help. I will try to replace it with a piece of wire and if there are any problems i will replace it.
Yuo can use also a normal carbon film resistor, not the best visional fix but better than nothing, no? In this case i'm not sure if a wire can broke something else, but we can trust of @TriMesh
I wouldn't normally recommend replacing a resistor with a piece of wire, but in this case it's a series damping resistor used to reduce the slew rate of the signal, so the only effect of shorting it out is to increase the amount of ringing on the signal. As the PSX is a 3.3V system with pretty decent noise margins, you should be able to get away with this. But yes, it would be better to replace it - people don't put parts into a circuit for no reason
Talking of noise in the psone, i've see that some psone modded with onechip introduces some "udible" noise on the laser.. Like this topic: http://www.assemblergames.com/forums/showthread.php?50846-PSOne-laser-louder-after-mod-chip-install Can you explain why or give me a solution? seems pretty strange.... I know that modchip introduces noises, but with psone the case is even "louder"
It's basically interference from the chip getting into the tracking servo - this is something that every PSX model since the PU-22 suffers from to some extent, but the PM41(2) board seems to get it a lot worse than the others do. One of the install diagrams also had the PIC running from the 7.5V output of the AC adapter, which seemed to make things a lot worse. All you can really do is try both ends of the cap, and if you have a especially difficult unit try putting a small value resistor (say 100 or 220R) in the data line. Sometimes it just doesn't work at all, though.
Already tried, but nothing new, even with a decoupling cap The problem seems resolve if i try the other side of the cap, but the CDR boot sometimes fails. Seems that the PIC sometimes sends noises even in the Video (if you see very carefully some frames appairs distorted). And yes, seems that only v2 of pm41 suffers of this problem, on the V1 noises aren't so evident.... Maybe if the code wil be ported to a new and beter pic (like 12f629) problem can disappear? Yeah PIC 7.5 V directly from the main AC its very smart idea XD
I honestly doubt that changing the chip is going to make much difference - it's a fundamental problem with the way the mod works on these later machines. From the PU-7 to the PU-20, the wobble signal was processed by a analog circuit connected to the tracking error signal, and then fed into the mechacon CPU. The actual tracking signal used by the CD pickup servo was picked off at the start of this process, so you could inject signals in to the later parts of the wobble detection circuit, and they would have no effect on the rest of the system. With the PU-22 (and all the subsequent models), the CD controller logic was made much more integrated - and that analog path for the wobble signal went away. Instead, it was made part of the tracking servo and the resultant data buried as part of the overhead data in the subcode stream. That basically left you with two points of attack - you could either hook into the subcode and rewrite it on the fly to put the correct data into it, or actually inject something that looks like wobble data into the tracking error path. At the time, the first approach was simply too expensive and complicated to be seriously considered, so everyone went with the second one. The first versions of the mod actually injected the wobble data into the F-E amp on the RF front end chip, which worked, but had some serious stability issues and was associated with the same lens clicking you are seeing on the PM41(2). Later on, someone came up with the idea of using one of the local clocks on the CD controller to produce a fake tracking wobble and just use the modchip to gate it (this was the "3 wire + link" method) - this also tended to cause tracking problems, because although the clock was theoretically outside the passband of the filter in the tracking servo, it had intermod products that weren't (which was why it worked in the first place...), and these could cause servo disturbances. This was followed up by the 5 method, which was basically the same, but gated the clock off when the mod was not sending data. Finally, it was realized that you could just gate the clock together with the signal in the PIC, and send that out - this became the standard method for these chips because it caused the least interference with normal operation. This is the method that the Mayumi chips, MM3 and the new Old Crow chips use. The problem is that it's still basically a hack - when you send a "1" bit you are shorting down the tracking error signal to ground 50% of the time and relying on the filter in the tracking servo to throw away the resulting signal components - which it mostly does, but it looks like the new CD chip in the PM41(2) doesn't manage it as well as the older ones did.
