We like the ugly ones! The deeper the dive, the more we thrive! Gives us a chance to see more of the circuit, inspect the schematics, get a feel for 'what's cooking in the oven'. 😁 Keep it going!
Not sure why you keep apologizing for the ugliness of the repair. I loved watching you go through all the steps and really fleshing out what could or did go wrong. I have a breadbin is in a similar situation and I feel like I could watch this series as a how to on how to fix it. Thank you so much!
I'm glad you enjoyed it! I was just frustrating that I kept moving on to the next most likely thing... and that wasn't it. And next thing... and no, not that either. Argh! 😃 But it happens.
The ugly repairs can be the best repairs because we can learn so much about them as so many things go through troubleshooting. The more unexpected things the better because it adds to the collective knowledge of Commodore repair.
This is basically how I fixed my C64, just kept desoldering, socketing and replacing IC's until it started to work 😂 I didn't have an oscilloscope to help me at that point.
My dad was a typewriter repairman in the 70's and 80's (well he still is!). I lost one of my joystick controllers on my C64. I had no idea how to fix it, I was 14. My dad opened it up and figured out which part it was. I was amazed. I mean I knew my dad did know electronics to a certain degree but how he figured out it was that chip, was beyond me. Hindsight, he worked with a guy who was working as a typewriter repair guy temporarily while he got his engineering degree. That guy went on to work at IBM labs or something like that, so my dad might have had a little help, but Im pretty sure the C64 never left our house, it was unbuttoned in my room for a few weeks. Im an engineer now so Im pretty sure you can trace the closest chip to the broken port and just shotgun replace it. But still, my dad nailed it. Hero achievement UNLOCKED!!!
I've had uglier. last week I socketed everything, recapped. I even replaced the user port socket. Checked every single line. It turned out to be a short thinner than a hair under one of the ram sockets between two data lines. It was so thin that my equipments did not pick it up. I discovered it by "inspection by eye" method. Took my 8 weeks. nice to know even proffesionals can have hard time :) Please keep sharing even something goes wrong. That is how I learn.
Whoa! That's crazy! Glad you were able to find it. Sometimes repairs get really hard, but the great thing about this level of technology is that I feel I can always eventually track it down.
It wasn't ugly sir, you were learning. It's easy to jump to the common problems you're used to seeing first, but iv learned to always do a thorough visual inspection of anything new I'm working on first. Visuals are free.
That is one of my favorite videos so far! While I don't want you to suffer through difficult repairs, it's heartening to see that other people get to the point where a machine starts to drive them a little crazy! Great job!
Haha, yes, it's not all sunshine and roses in the Retro Lab. Sometimes you just get some annoying faults that have you chasing down all over the place!
The trick to writing code that uses no RAM, in addition to not trying to store, i.e. STA, STX, STY, is that you cannot use any operations that require the stack (which is in RAM). If you need to hold a value temporarily you only have registers to use which are few on a 6502.
I agree with everyone Noel. These harder ones are just more fun to watch! Your content is great.. keep up the good work! According to the schematics and the datasheets for the 6510 and 6567 (VIC-II) that second AND gate at 21:00 is actually pretty important I think. As you discovered the output (CAEC) goes to the processor AEC pin (5). The processor needs to free up the address bus in two conditions: 1. When the VIC-II needs to access memory, 2. when DMA is used (for example by REU's). the AEC pin (16) on the VIC-II is an output pin and was designed to attach to the AEC input pin on the 6510 directly. As the name suggests the processor can drive the address bus as long as the AEC is high. When AEC is low the processor enters high impedance on the address bus. The DMA is active-low and in normal conditions pulled up to 5V, therefore pin 5 on the 74LS08 is normally always high. The VIC-II will switch it's AEC output pin low when it wants to access memory. If cartridges like REU's want to perform DMA, they have to adhere to very strict rules: BA from the VIC-II to the cart must be high and in the right clock phase the cart can then pull DMA low to take control over the address bus. So this second gate is crucial in bringing these two very important lines to the 6510. If this gate fails and outputs a high then you will get fighting on the address bus, if it is stuck low then the processor will not do anything. It runs of course... but cannot do any storage or stack operations. Obviously any garbage signal in between will mix those two behaviours. So that second gate might not have an issue after all... it looks like and your determination on the color ram select is the exact problem. The lesson learned, I think: When you do your normal routine of checking for clocks, ready, etc on the processor, also scope the AEC on 5; it should be pulsing. And scope the CS on the color ram.
Hi Noel, I just recently run into your channel (algorithm is working) and I really had a great time. Your videos are very well done, the topics are so captivating and you transmit the concepts with a teacher's perfection. I used to spend my life playing with Commodore 64's, CZ Spectrum's, Talent MSX and TI99's, 35 years ago, and have never touch one since then. Anyways, your channel restarted a sparkle I thought it was gone for ever. I wish I had a C64k again. Sorry about my English, I am not a native English speaker. Thank you.
@Noel While this video was a year ago, being someone who does low-level electronics servicing like this I can say with confidence that it was not an "ugly" fix up. Some repairs are not as simple or easy as others. This was interesting every step of the way and I could not see anything you did wrong. Complex repairs are complex, it's the way life is sometimes. Carry on good sir!
Thanks for finally, unlike others, stating the obvious that perhaps because of the manufacturing process they used that MOS chips are such common culprits in failed machines. And I don't mind "ugly" repairs. They are more interesting than more routine ones.
This was really fun. One thing I see Chris from GadgetUK do is to clean boards very meticulously giving himself a chance to inspect every part of the board closely. That might have helped in finding the cap and power connector issues. The broken logic chips etc were a nightmare to find. Fun to watch though.
That's a really good approach. Normally I don't do anything that thorough, especially when they're really clean like this one was, but I do a quick check looking for previous repairs and things like that. I completely missed the cap since it was bent covering its leg though. Haha!
@@NoelsRetroLab I couldn't do it that way but I take inspiration from Chris in that sense. It's a lot of elbow grease but I think it might just pay off often enough.
It is a very good video. I had a similar issue and narrow down to the CPU itself. The address bus was stuck. I prefer debugging the circuit compared to randomly replacing ICs
Noel, wow that was a slog. That being said even though fixes like this are hard and painful, you learn way more from them. Great pair of videos, makes us amateurs feel a lot better when you gurus sometimes have a hard time of it.
Thanks Jim! My understanding is that the semiconductor "sandwiches" end up failing over time from general stress from usage. So suddenly you have something that's always conducting or never conducting anymore. The better the fabrication techniques (and maybe the more material there is in the substrates) the longer it lasts.
There a a number of failure modes, one common problem is where the tiny gold wires that link from the metal pins to the silicon die fracture or become unwelded. This can be due to physical vibration or thermal stress. Sometimes the gap is so small that the IC will work until it heats up then it fails causing an intermittant fault. Similarly the actual silicon can fracture with changes in temperature - if the computer is kept in a poorly ventilated loft or shed the temperature can swing from freezing at night to red hot during the day - also if the sealing of the chip inside the cavity breaks down over a period of years moisture can get in and cause corrosion. Also again, chips like the voltage regulatiors, SID or VIC run hot and this can cause deterioration of the junctions in time as any silicon device that runs hot which is why cooling is important.
One should try the removed chip in another working machine, if possible. That way you know instantliy if this was the broken part. In my opinion putting another working chip in a machine of which you don't know what is wrong you can end up with two broken chips because you don't know what has caused the problem in the first place. Thank you for the video, I really enjoyed it - like always. I highly recommend subscribing to this channel.
Lol I watched a video whe Bil Herd said he is surprised MOS chips are stiill functioning after 40 years they had a 5 year life based on the materials used with NMOS technology available at the time.
Oh.my.god! I have the same eeprom programmer and never knew you could check logic chips. I've been manually testing them on this massive project. It just never crossed my mind that the batronix could do it.
Don't feel bad, I don't think I realized it had that feature for the first year I had it either. I was testing NAND gates by setting up a little breadboard... Much more convenient this way! 😃
It may still be power related. I have broken identical NMOS DRAMs that all consume different (and pretty high) idle currents when powered. If your two VIC revisions also differ in power consumption that may explain the differences in behavior. You could measure the two 5V rail currents with both DRAM sets and both VICs and compare them. And you could also compare the rail stabilities with your scope to solve the mystery.
I repaired one of such boards last year. A tool that appeared to be most usefull was the IR camera - I was able to identify faulty chips immediately without any doubt.
I've been looking into that for a bit, but haven't decided on one. It probably wouldn't have worked here, but it can be extremely useful. Which IR camera did you get?
@@NoelsRetroLab I used a Vigo V50 but it is a tool which you cannot buy now - not that it's so superb, it's simply discontinued and was produced by a Polish company. And it's not too handy. There are better tools to be used by professionals (I'm just an amateur enthusiast).
"I promise you that the next one will not be such a mess" ... but but I want it to be a mess, that way I can enjoy you squirm :-) Very good video, great content. Thank you.
I been dealing with a similar ugly as fork repair. memory faults galore & corrupted video on dead test / diagnostics cart. Even the case was mega dirty from being in a barn for years & having a craptasticle dust cover glued on.
I had a similar experience with a C-16 and a Plus/4 with exact same startup issue. Took 2 or 3 years before I finally solved the issue. Went through the standard TED, CPU, PLA replacements etc. In the end it was a similar MOS logic chip and a RAM chip that was bad. The TED, CPU and PLA were all good. The one really ugly repair was my Commodore PC-10-III. I literally ended up socketing 95% of the components before I finally resolved the issue. Unfortunately I think it was the one of the early replaced ICs that was the problem, but because the board was difficult to desolder (even with a Hakko gun) I ended up lifting some traces. My "repair" wasn't quite correct, and it was only late in the game that I revisited it to discover that. I do believe there were multiple component failures however. Even after fixing that, it didn't fire up. I discovered is that replacing "74S" logic chips with "74LS" chips sometimes doesn't work. I ended up replacing those with "74S" versions that were called for in the original design and it finally fired up. Lots of red herrings, lots of hair pulling, but lots of good learning as well. I was very happy to see the machine working again.
Yikes! Yes, things can turn ugly. And when something you've checked turns out to be faulty, that's the worst, because you're convinced it has to be something else. I've had a Dragon 64 repair that took a year and a half (on and off obviously) because of that exact same reason!
The reason why a cartridge needs RAM is the zero page and the stack - memory from $0000 to $01FF is required for operations that keep track of things through memory with short 6502 opcodes (two instead of three bytes) and call subroutines (stack), and you need screen memory (which is not color memory), usually from $0400 to $07FF. Without zero page is not impossible with fixed sequence of events, and without stack, you'd be using a lot of branching (which for a test cartridge is not impossible), but you'd have issues with interrupts which use stack. Without screen memory, all characters on the screen would be random or very fixed (I remember VIC 20 had a specific pattern derived from part of the address).
The second part was even better than the first. Loved the "further tests" on min 20, checking why the 4xAND prevented it from booting. What an evening!. Watching the second part of one of the best-ever Noel's videos and, to conclude a nice evening, waiting for the Perseverance Mars rover landing in (near) real-time (here: ruclips.net/video/w23gC0WhXdI/видео.html). I guess that the Perseverance testing level is quite similar to Noel's.
... until they don't come out nicely one day 😃 Seriously, had I been stumped in the end, I would have still made a video about it showing the process. So you can never be sure with my videos!
Funny fact is that after some C64 repairs you end up with a whole bunch of MOS ICs that deserve to be preserved in some form. I am trying to make some keychains of epoxy with broken SIDs, VIC-II, CPUs, ROMs, 7801 as the bag I originally used to keep them is almost full.
Memory Error Report that I read from NEC notes that data error rates increased unexpectedly from 16K bits to 64K bits. Apparently one of the materials used to make the chips was radioactive. Fixed for 256Kbit Ram chips.
It's hard to explain, one possible cause maybe the passive component like capacitors are not working well with that chip, to find out real cause involve probing many places with scope, will take a lot of time. Actually I doubt if only the capacitor are really near dead, the value will cause weird thing happening to the chips.
Regarding the TMS4164 issue, it may come down to how the OKI and TMS expect to be refreshed. Both are 64 x 1 but one may require 128 count (2^7) cycles and the other 256 count (2^8) cycles. I am not experienced with C64 enough to know how how it manages refresh, apart from it being done with the VIC II.
I was suspecting the newly socketed ram for the ram-errors, but maybe that’s just because I myself did a pretty bad soldering job on my own C64, so some of the sockets didn’t connect properly on the top-side of the board, causing weird ram-errors, until I added some budge-wires!
Yes, it was a dangerous thing to put that RAM and assume it would work. If I had put the old one back at least I would have considered it a possibility that it was faulty. Fortunately there were no problems with broken traces or I would have gone out of my mind! 😃
@@NoelsRetroLab Possible. I don't know what the internals of that epoxy encased power supply has in it and if it has any type of varistor or transient voltage protection? My guess is that it is nothing more than a transformer with multi tap voltages and the rectification/regulation happens in the case. It has been a while since I have messed with a C64 repair. I am more of a D128 guy now.
Thanks! In all seriousness: Do you know what really, really helps? Having another C64 next to me that's working. As long as I have that, I know I can at least swap enough things to get it to work and from there narrow down the problem. On the other hand, having just one machine that you're trying to diagnose can be really nerve wracking!
I get that one of the VIC II revisions could have different tolerances and it causes video corruption while the other one doesn't. But the really weird thing is that the VICII shouldn't have an effect over the Dead Test Cartridge RAM tests, yet they pass with one and they fail with the other. So weird!
Next time you run into a black screen just hang your t-shirt over the screen and you are immediately fine! :-D That was another fine fault finding video, although it wasn't as strait as you are used to. I enjoyed it a lot. And the beginning was quite funny!
@@NoelsRetroLab its catch 22 really, you could spend hours diagnosing the problem or remove every chip till you find the problem , also you eliminate dry or fractured solder joints. i loved the repair :) very interesting
It was actually a very interesting and well explained two part series. I enjoyed it a lot and I did learn quite a bit from it. In future when using the Oscilloscope could you show viewers what settings you used for testing?
I use to repair computers back in the 80's and during that time I must have repaired several hundred C 64's. Whenever I had a unit with multiple bad IC's I always suspected the crappy PS which came with those units. Unfortunately, they were potted with no air circulation and would drop a bunch of ripple into the unit. I would explain to the customer what had happened and offer to sale a repairable PS at just above my cost to help them NOT have to pay for a subsequent repair. As I recall, everyone was glad to buy the new supply. So, if you are using that original supply, you might want to trash it after you save the cords in case you want to roll your own supply and sell them. Good luck OH. one beef I have with most of the guys repairing C 64's now is this biz of tossing the RF shields for the unit. If any of you looked at the electrical Racket and wide band noise which gets emitted from an unshielded C64 on a decent Spectrun Analyzer, you would know why those shields are there. It was part of the FCC certification process to have those shields. That same noise can cause interference in other home devices like sound systems, sensitive receivers ect. Shame you guys do this !!
You can absolutely use an 8-bit computer with NO RAM. However, you have to do things differently. The ROM code cannot use things like RTS or anything that pushes values to the stack. No RAM means no stack. The dead test cart must use explicit branching and probably detects the missing RAM and jumps to the flashing routine.
Right, you need to be very careful. With some CPUs is harder than others though. On a Z80 it's pretty easy, on the 65xx it's harder, and I imagine on the TMS9900 it would be close to impossible (OK, OK, technically not an 8-bit CPU 😃).
i guess the vic-chip generates the timing for the ram chips. the never one might be a bit faster which then results in errors when the ram chips. slightly different timing the 6502/6510 has 256 bytes of internal static ram. that is the reason why a simple program can run without external dynamic ram. but the bit detection of the rams really seems to be wrong. on the other side, different boards could have different routings on different board revisions.
TBH if you do enough repairs, you will eventually have ugly ones. I was actually starting to wonder if you had a bad VIC II socket or something weird like that.
I hadn't thought of that until now, but no, that's not it. Remember that the VIC II is on a separate 5V line (the one coming from the 7805) but the RAM is on the 5V from the power supply.
The best way to repair digital circuits is using logic pulser / probe (to find open or shorted tracks / terminals to source or ground) and curve tracer... :-)
Instruments such as HP 545a (Logic Probe), 546a (Logic Pulser) and 548a (Logic Clip) are really awesome. The HP 547a (Current Tracer) is also an excellent tool for finding dead chips. For Curve Tracer, take a look at Octopus Curve Tracer circuits (there is a nice example on w2aew Channel) ... ;-)
so whenever you turned it on (at the black switch), it was lighting up black on a black background, so you know that you had done it... sounds familiar...
Hi Noel, did you go back to check that 'ugly' data bus signal after the machine was working again? Methinks that was just a (not atypical) oscilloscope measurement artifact related to the triggering mechanism. Data buses are notoriously tricky to measure. Unlike address buses -- which should always look text-book -- data buses can display very strange traces on the oscilloscope, while working perfectly, because the lack of periodicity in the signal screws with the oscilloscope's trigger mechanism.
I didn't but I should! Data busses are definitely odd, but you eventually get used to the patterns of each one. The ZX Spectrum one looks like a total hot mess! I wonder if what causes the oscilloscope to have a hard time triggering is the tristate switches, but the address bus stays mostly driven by the CPU? Not sure. On the other hand the Amstrad CPC data bus usually looks pretty reasonable (but the RAM chips don't have Din and Dout tied and they have an extra flip flop, so that might be related).
That is just fine repair, its ugly when you need to pull out ten times logic cards & power cards from a machine that isnt repair friendly. Just did one of those, bilion connectors at the floor level, plus 1K screws PH0, real party, as usual suspects did it, electrolitic capacitors and a shorted mosfer
Thanks! Yes, it could be a lot worse. At least the C64 is easy to work with. I can't say the same thing about the TI99 or those SVI machines with the ribbon cables you can't remove! 😃
I'm very interested in that USB EEPROM programmer that can test logic chips? Ive never seen one like that. Could you drop a Model number or some reference for us please.? With that amount of determination, you were going to get there eventually. Very educational and enjoyable, Thank you.
El nivel de detalle y buen trabajo que haces merece que junto con los otros restauradores (Adrian Black, 8-bit guy, Jan Beat, etc) forrmen una alianza que tenga su propio sello de calidad: las maquinas que reparan y dejan a la perfeccion que luego son revendidas o donadas deberian llevar un sticker de la alianza de calidad, asi de esa forma el que las recibe esta 100% seguro que es un equipo que funciona perfecto y fue tratado por verdaderos artesanos de 8 bits
The ugly ones are the most interesting IMO...
Absolutely my opinion!
Apologies for the conclusion confusion! Great video 👍🕹️
You didn't tell me that HE was turning up... ;-)
Thanks for playing along! 😃
I see a missed opportunity here..... Lady Fractic's screw noise missing.
Eeee ooo eeee ooo... Cris Blyth has obviously secured exclusive rights to it for his "Building a Fairlight CMI" series :D
@@davidkgame Correct! But only for 100 years.
We like the ugly ones! The deeper the dive, the more we thrive! Gives us a chance to see more of the circuit, inspect the schematics, get a feel for 'what's cooking in the oven'. 😁 Keep it going!
Not sure why you keep apologizing for the ugliness of the repair. I loved watching you go through all the steps and really fleshing out what could or did go wrong. I have a breadbin is in a similar situation and I feel like I could watch this series as a how to on how to fix it. Thank you so much!
I'm glad you enjoyed it! I was just frustrating that I kept moving on to the next most likely thing... and that wasn't it. And next thing... and no, not that either. Argh! 😃 But it happens.
So NOT ugly. There is beauty and wisdom in each step...especially the, "Start by replacing the MOS chip" part :)
Haha, thanks! It's amazing how much they fail those MOS chips!
I like your new announcer, he sounds like a real chip dipper 😉
He does sound awfully familiar, doesn't he? 😃
@@NoelsRetroLab 😆
He flew in on PCB waaaaaay airlines :p
@@mbob4337 Afterall, PCB stands for "Perifractic Can Be in 2 places at once.", right?
The ugly repairs can be the best repairs because we can learn so much about them as so many things go through troubleshooting. The more unexpected things the better because it adds to the collective knowledge of Commodore repair.
This is basically how I fixed my C64, just kept desoldering, socketing and replacing IC's until it started to work 😂 I didn't have an oscilloscope to help me at that point.
I loved this series! It's so cool to see things go wrong and watch the thought process and troubleshooting steps taken. These are my favorite videos!
Glad you enjoyed it! Sometimes real life is messy 😃
@@NoelsRetroLab No, this is real life actually. :)
Thanks for the tip about testing logic chips with the Minipro, so glad I have another use for it now! 👍
You're welcome! It took me a bit to figure out that it did that too. Haha!
My dad was a typewriter repairman in the 70's and 80's (well he still is!). I lost one of my joystick controllers on my C64. I had no idea how to fix it, I was 14. My dad opened it up and figured out which part it was. I was amazed. I mean I knew my dad did know electronics to a certain degree but how he figured out it was that chip, was beyond me. Hindsight, he worked with a guy who was working as a typewriter repair guy temporarily while he got his engineering degree. That guy went on to work at IBM labs or something like that, so my dad might have had a little help, but Im pretty sure the C64 never left our house, it was unbuttoned in my room for a few weeks. Im an engineer now so Im pretty sure you can trace the closest chip to the broken port and just shotgun replace it. But still, my dad nailed it. Hero achievement UNLOCKED!!!
I've had uglier. last week I socketed everything, recapped. I even replaced the user port socket. Checked every single line. It turned out to be a short thinner than a hair under one of the ram sockets between two data lines. It was so thin that my equipments did not pick it up. I discovered it by "inspection by eye" method. Took my 8 weeks. nice to know even proffesionals can have hard time :) Please keep sharing even something goes wrong. That is how I learn.
Whoa! That's crazy! Glad you were able to find it. Sometimes repairs get really hard, but the great thing about this level of technology is that I feel I can always eventually track it down.
It wasn't ugly sir, you were learning. It's easy to jump to the common problems you're used to seeing first, but iv learned to always do a thorough visual inspection of anything new I'm working on first. Visuals are free.
That is one of my favorite videos so far! While I don't want you to suffer through difficult repairs, it's heartening to see that other people get to the point where a machine starts to drive them a little crazy! Great job!
Haha, yes, it's not all sunshine and roses in the Retro Lab. Sometimes you just get some annoying faults that have you chasing down all over the place!
The trick to writing code that uses no RAM, in addition to not trying to store, i.e. STA, STX, STY, is that you cannot use any operations that require the stack (which is in RAM). If you need to hold a value temporarily you only have registers to use which are few on a 6502.
Right. It seems much harder than I thought initially coming from the Z80 perspective.
Ugly or not, it was a beautiful repair. 99% of all C64 repairs is "It must be this or must be that... Oh, it is the PLA!"
You did great work here.
Thanks! Glad you liked it in the end 😃
I actually love it when things don't go to plan. It's fascinating to watch. Thank you for sharing this.
Col. Hannibal Smith disapproves your comment :p
I agree with everyone Noel. These harder ones are just more fun to watch! Your content is great.. keep up the good work!
According to the schematics and the datasheets for the 6510 and 6567 (VIC-II) that second AND gate at 21:00 is actually pretty important I think. As you discovered the output (CAEC) goes to the processor AEC pin (5). The processor needs to free up the address bus in two conditions: 1. When the VIC-II needs to access memory, 2. when DMA is used (for example by REU's). the AEC pin (16) on the VIC-II is an output pin and was designed to attach to the AEC input pin on the 6510 directly. As the name suggests the processor can drive the address bus as long as the AEC is high. When AEC is low the processor enters high impedance on the address bus.
The DMA is active-low and in normal conditions pulled up to 5V, therefore pin 5 on the 74LS08 is normally always high. The VIC-II will switch it's AEC output pin low when it wants to access memory.
If cartridges like REU's want to perform DMA, they have to adhere to very strict rules: BA from the VIC-II to the cart must be high and in the right clock phase the cart can then pull DMA low to take control over the address bus.
So this second gate is crucial in bringing these two very important lines to the 6510. If this gate fails and outputs a high then you will get fighting on the address bus, if it is stuck low then the processor will not do anything. It runs of course... but cannot do any storage or stack operations. Obviously any garbage signal in between will mix those two behaviours.
So that second gate might not have an issue after all... it looks like and your determination on the color ram select is the exact problem.
The lesson learned, I think: When you do your normal routine of checking for clocks, ready, etc on the processor, also scope the AEC on 5; it should be pulsing. And scope the CS on the color ram.
Hi Noel, I just recently run into your channel (algorithm is working) and I really had a great time. Your videos are very well done, the topics are so captivating and you transmit the concepts with a teacher's perfection. I used to spend my life playing with Commodore 64's, CZ Spectrum's, Talent MSX and TI99's, 35 years ago, and have never touch one since then. Anyways, your channel restarted a sparkle I thought it was gone for ever. I wish I had a C64k again. Sorry about my English, I am not a native English speaker. Thank you.
You're very welcome. I'm really glad you're enjoying the videos!
Ugly? I love this type of reparation, we learn a lot. Thanks!
Thanks! Glad it was useful!
I appreciate these repair videos as I'm curious of what makes the Commodore 64 tick.
Fear, fear of Jack. They’re starting to figure out he’s gone so they start slacking.
@Noel
While this video was a year ago, being someone who does low-level electronics servicing like this I can say with confidence that it was not an "ugly" fix up. Some repairs are not as simple or easy as others. This was interesting every step of the way and I could not see anything you did wrong. Complex repairs are complex, it's the way life is sometimes. Carry on good sir!
Thanks for finally, unlike others, stating the obvious that perhaps because of the manufacturing process they used that MOS chips are such common culprits in failed machines. And I don't mind "ugly" repairs. They are more interesting than more routine ones.
MOS was famous for repairing defective chip wafers, giving them high yields for cheap prices. Looks like the repairs were not always super quality!
This was really fun. One thing I see Chris from GadgetUK do is to clean boards very meticulously giving himself a chance to inspect every part of the board closely. That might have helped in finding the cap and power connector issues.
The broken logic chips etc were a nightmare to find. Fun to watch though.
That's a really good approach. Normally I don't do anything that thorough, especially when they're really clean like this one was, but I do a quick check looking for previous repairs and things like that. I completely missed the cap since it was bent covering its leg though. Haha!
@@NoelsRetroLab I couldn't do it that way but I take inspiration from Chris in that sense. It's a lot of elbow grease but I think it might just pay off often enough.
Noel, it is always the last thing you look at, as we stop looking once its found! great video of a frustrating repair.
Haha, exactly! Always the last one! 🤣
-15 I believe is 150ns. For static ram often it's what it says -15 -20 15 and 20 ns. Dynamic 15 ns back then would have been awesome.
Seems like Adrian had a board like this, you definitely did a great job running this down!!!
Yes, that's true. Glad you liked it!
Very nice video! Thanks for putting the effort in showing us what exactly you are probing! Highly appreciated. Greets from DE
Glad it was helpful! Thanks!
I had the same issue with U27 on a C64 repair last year (bad MOS 7712). That seems to be a fairly common fault.
Just starting to watch, hope no angry bird will scare me later in video. :-)
No, you're safe this time. Watch away 😃
It is a very good video. I had a similar issue and narrow down to the CPU itself. The address bus was stuck. I prefer debugging the circuit compared to randomly replacing ICs
Thanks! Yes, ideally I always like to examine something, run some tests, and figure out what's wrong with it. But this one... ouch! 😃
Noel, wow that was a slog. That being said even though fixes like this are hard and painful, you learn way more from them. Great pair of videos, makes us amateurs feel a lot better when you gurus sometimes have a hard time of it.
Thanks! It's not like I'm a professional either! But yes, we all get those kind of projects/repairs where nothing goes right. It happens.
Hello Noel, Perifractic and Adrian! Great to see everyone working as a team haha
one of the best C64 repair videos I have seen in a while. Learnt more than ever on this one
Really glad to hear that! 👍
The patience of a saint.
Thx Noel, no waste of time to see you do a repair and diagnost a c64......
Thank you! 😃👍
Great video! Question: What causes these chips to fail as they age? Just a breakdown of their material or something else? Love your work Noel!!!
Thanks Jim! My understanding is that the semiconductor "sandwiches" end up failing over time from general stress from usage. So suddenly you have something that's always conducting or never conducting anymore. The better the fabrication techniques (and maybe the more material there is in the substrates) the longer it lasts.
There a a number of failure modes, one common problem is where the tiny gold wires that link from the metal pins to the silicon die fracture or become unwelded. This can be due to physical vibration or thermal stress. Sometimes the gap is so small that the IC will work until it heats up then it fails causing an intermittant fault. Similarly the actual silicon can fracture with changes in temperature - if the computer is kept in a poorly ventilated loft or shed the temperature can swing from freezing at night to red hot during the day - also if the sealing of the chip inside the cavity breaks down over a period of years moisture can get in and cause corrosion. Also again, chips like the voltage regulatiors, SID or VIC run hot and this can cause deterioration of the junctions in time as any silicon device that runs hot which is why cooling is important.
One should try the removed chip in another working machine, if possible. That way you know instantliy if this was the broken part. In my opinion putting another working chip in a machine of which you don't know what is wrong you can end up with two broken chips because you don't know what has caused the problem in the first place.
Thank you for the video, I really enjoyed it - like always. I highly recommend subscribing to this channel.
Great job Noel! I like going back to verify fixes and I think the end was good you did this too. It helps us understand diagnosing these issues.
Yeah, it felt unsatisfying not going back and at least trying to get a better understanding of what was going on. Glad you liked it!
Lol I watched a video whe Bil Herd said he is surprised MOS chips are stiill functioning after 40 years they had a 5 year life based on the materials used with NMOS technology available at the time.
"Always the last place you look..." LOL. Always loved that saying. Great video!
Thanks! Yes, such a true saying! 😃
The patient was very sick but is now going to live again - good work!
Recently discovered your channel, I am really enjoying all the repair videos and learning alot from the techniques you use.
Oh.my.god! I have the same eeprom programmer and never knew you could check logic chips. I've been manually testing them on this massive project. It just never crossed my mind that the batronix could do it.
Don't feel bad, I don't think I realized it had that feature for the first year I had it either. I was testing NAND gates by setting up a little breadboard... Much more convenient this way! 😃
The opening should be, "PREVIOUSLY on Noel's Retro Lab..."
It may still be power related. I have broken identical NMOS DRAMs that all consume different (and pretty high) idle currents when powered. If your two VIC revisions also differ in power consumption that may explain the differences in behavior. You could measure the two 5V rail currents with both DRAM sets and both VICs and compare them. And you could also compare the rail stabilities with your scope to solve the mystery.
I repaired one of such boards last year. A tool that appeared to be most usefull was the IR camera - I was able to identify faulty chips immediately without any doubt.
I've been looking into that for a bit, but haven't decided on one. It probably wouldn't have worked here, but it can be extremely useful. Which IR camera did you get?
@@NoelsRetroLab I used a Vigo V50 but it is a tool which you cannot buy now - not that it's so superb, it's simply discontinued and was produced by a Polish company. And it's not too handy. There are better tools to be used by professionals (I'm just an amateur enthusiast).
"I promise you that the next one will not be such a mess" ... but but I want it to be a mess, that way I can enjoy you squirm :-) Very good video, great content. Thank you.
I been dealing with a similar ugly as fork repair. memory faults galore & corrupted video on dead test / diagnostics cart. Even the case was mega dirty from being in a barn for years & having a craptasticle dust cover glued on.
I had a similar experience with a C-16 and a Plus/4 with exact same startup issue. Took 2 or 3 years before I finally solved the issue. Went through the standard TED, CPU, PLA replacements etc. In the end it was a similar MOS logic chip and a RAM chip that was bad. The TED, CPU and PLA were all good.
The one really ugly repair was my Commodore PC-10-III. I literally ended up socketing 95% of the components before I finally resolved the issue. Unfortunately I think it was the one of the early replaced ICs that was the problem, but because the board was difficult to desolder (even with a Hakko gun) I ended up lifting some traces. My "repair" wasn't quite correct, and it was only late in the game that I revisited it to discover that. I do believe there were multiple component failures however. Even after fixing that, it didn't fire up. I discovered is that replacing "74S" logic chips with "74LS" chips sometimes doesn't work. I ended up replacing those with "74S" versions that were called for in the original design and it finally fired up. Lots of red herrings, lots of hair pulling, but lots of good learning as well. I was very happy to see the machine working again.
Yikes! Yes, things can turn ugly. And when something you've checked turns out to be faulty, that's the worst, because you're convinced it has to be something else. I've had a Dragon 64 repair that took a year and a half (on and off obviously) because of that exact same reason!
Haha! I thought I clicked the wrong thumbnail there for a second! :D Hello Retro Recipes!
Hello chip dipper!
I abstractly love frilling concussions!
The reason why a cartridge needs RAM is the zero page and the stack - memory from $0000 to $01FF is required for operations that keep track of things through memory with short 6502 opcodes (two instead of three bytes) and call subroutines (stack), and you need screen memory (which is not color memory), usually from $0400 to $07FF.
Without zero page is not impossible with fixed sequence of events, and without stack, you'd be using a lot of branching (which for a test cartridge is not impossible), but you'd have issues with interrupts which use stack. Without screen memory, all characters on the screen would be random or very fixed (I remember VIC 20 had a specific pattern derived from part of the address).
The second part was even better than the first. Loved the "further tests" on min 20, checking why the 4xAND prevented it from booting. What an evening!. Watching the second part of one of the best-ever Noel's videos and, to conclude a nice evening, waiting for the Perseverance Mars rover landing in (near) real-time (here: ruclips.net/video/w23gC0WhXdI/видео.html). I guess that the Perseverance testing level is quite similar to Noel's.
Thank you! Glad you enjoyed it and had a great evening! 😃
I like those ugly repairs, because they came out nicely at the end... ;)
... until they don't come out nicely one day 😃 Seriously, had I been stumped in the end, I would have still made a video about it showing the process. So you can never be sure with my videos!
Funny fact is that after some C64 repairs you end up with a whole bunch of MOS ICs that deserve to be preserved in some form. I am trying to make some keychains of epoxy with broken SIDs, VIC-II, CPUs, ROMs, 7801 as the bag I originally used to keep them is almost full.
That sounds fun! Do you have any pictures?
@@NoelsRetroLabSure! I will send you some :)
Ha! I'm here for the mess ;-))
Lots to be had! 😬
Memory Error Report that I read from NEC notes that data error rates increased unexpectedly from 16K bits to 64K bits. Apparently one of the materials used to make the chips was radioactive. Fixed for 256Kbit Ram chips.
I think Adrian had a wild goose chase like this too, the c64 is a weird system 😂
I'm not surprised. The C64 is very interesting and logical, but at the same time it can lead to crazy chases like this. Oh well.
you probably would have at least avoided the ram socketing if you spotted that bad capacitor or mos chip before.
It's hard to explain, one possible cause maybe the passive component like capacitors are not working well with that chip, to find out real cause involve probing many places with scope, will take a lot of time. Actually I doubt if only the capacitor are really near dead, the value will cause weird thing happening to the chips.
Regarding the TMS4164 issue, it may come down to how the OKI and TMS expect to be refreshed. Both are 64 x 1 but one may require 128 count (2^7) cycles and the other 256 count (2^8) cycles. I am not experienced with C64 enough to know how how it manages refresh, apart from it being done with the VIC II.
Ooohhh! You're right! That would explain why things changed when I used the different revision VIC II. Very good observation! I bet that's it!
I was suspecting the newly socketed ram for the ram-errors, but maybe that’s just because I myself did a pretty bad soldering job on my own C64, so some of the sockets didn’t connect properly on the top-side of the board, causing weird ram-errors, until I added some budge-wires!
Yes, it was a dangerous thing to put that RAM and assume it would work. If I had put the old one back at least I would have considered it a possibility that it was faulty. Fortunately there were no problems with broken traces or I would have gone out of my mind! 😃
Noel, awesome repair! I bet that board was hit with a power surge. Usually the case when u get a slew of bad components like that.
Thanks. Yes, I think that's really likely. What would cause that though? Bad PSU?
@@NoelsRetroLab Possible. I don't know what the internals of that epoxy encased power supply has in it and if it has any type of varistor or transient voltage protection? My guess is that it is nothing more than a transformer with multi tap voltages and the rectification/regulation happens in the case. It has been a while since I have messed with a C64 repair. I am more of a D128 guy now.
I wouldn't have been as calm as you were! 😁
Thanks! In all seriousness: Do you know what really, really helps? Having another C64 next to me that's working. As long as I have that, I know I can at least swap enough things to get it to work and from there narrow down the problem. On the other hand, having just one machine that you're trying to diagnose can be really nerve wracking!
awesome start of the weekend Noel! Thanks for again a brilliant episode.
Glad you enjoyed it!
Theory: the newer VIC-II chip might have tighter tolerances for RAM responsiveness.
I get that one of the VIC II revisions could have different tolerances and it causes video corruption while the other one doesn't. But the really weird thing is that the VICII shouldn't have an effect over the Dead Test Cartridge RAM tests, yet they pass with one and they fail with the other. So weird!
@@NoelsRetroLab Thing is, the VIC-II doubles as the RAM refresh circuitry.
Next time you run into a black screen just hang your t-shirt over the screen and you are immediately fine! :-D That was another fine fault finding video, although it wasn't as strait as you are used to. I enjoyed it a lot. And the beginning was quite funny!
There's an idea!! 😃 Glad you enjoyed it though.
you nearly rebuilt it ! but less likely to have a dry joint now , someone's getting a great machine nice job hehe
Seriously! If I didn't like my board revision better I would keep that one 😃
@@NoelsRetroLab its catch 22 really, you could spend hours diagnosing the problem or remove every chip till you find the problem , also you eliminate dry or fractured solder joints. i loved the repair :) very interesting
The more mess the better, a lot can be learned from mess.
Great video Noel. Well done.
"Sometimes it's the last thing you look at..." Absolutely!
Well, usually because afterwards things start working, which is why he said "after a lot of other things tried" :)
@@oleimann I knew what he meant!
Also, you brought a dead C64 to life with detailed analysis. Not so ugly to me.
Decebuary 97th, I have seen the wasteland and I fear I may go mad any day now......
It was actually a very interesting and well explained two part series. I enjoyed it a lot and I did learn quite a bit from it. In future when using the Oscilloscope could you show viewers what settings you used for testing?
Excellent video, Noel! Thanks.
My pleasure!
I use to repair computers back in the 80's and during that time I must have repaired several hundred C 64's. Whenever I had a unit with multiple bad IC's I always suspected the crappy PS which came with those units. Unfortunately, they were potted with no air circulation and would drop a bunch of ripple into the unit.
I would explain to the customer what had happened and offer to sale a repairable PS at just above my cost to help them NOT have to pay for a subsequent repair. As I recall, everyone was glad to buy the new supply.
So, if you are using that original supply, you might want to trash it after you save the cords in case you want to roll your own supply and sell them. Good luck
OH. one beef I have with most of the guys repairing C 64's now is this biz of tossing the RF shields for the unit. If any of you looked at the electrical Racket and wide band noise which gets emitted from an unshielded C64 on a decent Spectrun Analyzer, you would know why those shields are there. It was part of the FCC certification process to have those shields.
That same noise can cause interference in other home devices like sound systems, sensitive receivers ect.
Shame you guys do this !!
ahahah - great journey as usual, Noel! I enjoyed the repair videos!
Thank you!! Glad you enjoyed them.
Thanks for the video Noel, I sure enjoyed it (mess or not :P)
Progress is socketing the entire mobo (lol!).
You can absolutely use an 8-bit computer with NO RAM. However, you have to do things differently. The ROM code cannot use things like RTS or anything that pushes values to the stack. No RAM means no stack. The dead test cart must use explicit branching and probably detects the missing RAM and jumps to the flashing routine.
Right, you need to be very careful. With some CPUs is harder than others though. On a Z80 it's pretty easy, on the 65xx it's harder, and I imagine on the TMS9900 it would be close to impossible (OK, OK, technically not an 8-bit CPU 😃).
i guess the vic-chip generates the timing for the ram chips. the never one might be a bit faster which then results in errors when the ram chips. slightly different timing
the 6502/6510 has 256 bytes of internal static ram. that is the reason why a simple program can run without external dynamic ram.
but the bit detection of the rams really seems to be wrong. on the other side, different boards could have different routings on different board revisions.
Awesome Noel - thanks a lot for sharing all this!
You're welcome! Glad you enjoyed it!
This is every computer repair I've ever done.
This was probably the most educational video you've done. Going through the detective work was excellent.
Good Catch.. shes running..
TBH if you do enough repairs, you will eventually have ugly ones. I was actually starting to wonder if you had a bad VIC II socket or something weird like that.
You’re a Saint, I would have yeeted that board into a fire. :D
Hahaha, I actually enjoy tough problems to solve. They make me dig even deeper.
I wonder if the old VIC pulls more from the 5V line, so the broken cap had more of an impact.
I hadn't thought of that until now, but no, that's not it. Remember that the VIC II is on a separate 5V line (the one coming from the 7805) but the RAM is on the 5V from the power supply.
Excellent video
Thank you very much!
Hahaha !... The title would be: "... How to kill a rabbit with random shots ..." !... Just kidding... well done, bro !... ^_^
The best way to repair digital circuits is using logic pulser / probe (to find open or shorted tracks / terminals to source or ground) and curve tracer... :-)
Instruments such as HP 545a (Logic Probe), 546a (Logic Pulser) and 548a (Logic Clip) are really awesome. The HP 547a (Current Tracer) is also an excellent tool for finding dead chips. For Curve Tracer, take a look at Octopus Curve Tracer circuits (there is a nice example on w2aew Channel) ... ;-)
You're not totally wrong! 🤣
great job yet again Noel...
want an ugly CPC464 fix?! ill send you my board with a few dead vias under the CRTC!
I doubt it'll be uglier than this! instagram.com/p/CIsi96VHDMZ/ 😳
@@NoelsRetroLab wow! yeah nowhere near that ugly!
so whenever you turned it on (at the black switch), it was lighting up black on a black background, so you know that you had done it... sounds familiar...
Thanks for the video, loved the repair methodology =)
Hi Noel, did you go back to check that 'ugly' data bus signal after the machine was working again? Methinks that was just a (not atypical) oscilloscope measurement artifact related to the triggering mechanism. Data buses are notoriously tricky to measure. Unlike address buses -- which should always look text-book -- data buses can display very strange traces on the oscilloscope, while working perfectly, because the lack of periodicity in the signal screws with the oscilloscope's trigger mechanism.
I didn't but I should! Data busses are definitely odd, but you eventually get used to the patterns of each one. The ZX Spectrum one looks like a total hot mess! I wonder if what causes the oscilloscope to have a hard time triggering is the tristate switches, but the address bus stays mostly driven by the CPU? Not sure. On the other hand the Amstrad CPC data bus usually looks pretty reasonable (but the RAM chips don't have Din and Dout tied and they have an extra flip flop, so that might be related).
Replace all the old electrolitic capacitors at first, man! Then do the service job. ;) Nice videos, btw.
That is just fine repair, its ugly when you need to pull out ten times logic cards & power cards from a machine that isnt repair friendly.
Just did one of those, bilion connectors at the floor level, plus 1K screws PH0, real party, as usual suspects did it, electrolitic capacitors and a shorted mosfer
Thanks! Yes, it could be a lot worse. At least the C64 is easy to work with. I can't say the same thing about the TI99 or those SVI machines with the ribbon cables you can't remove! 😃
The RAMs. They are from TI. The Unholy Spirit of Jack Tramiel doesn't like TI.
I'm very interested in that USB EEPROM programmer that can test logic chips? Ive never seen one like that. Could you drop a Model number or some reference for us please.? With that amount of determination, you were going to get there eventually. Very educational and enjoyable, Thank you.
El nivel de detalle y buen trabajo que haces merece que junto con los otros restauradores (Adrian Black, 8-bit guy, Jan Beat, etc) forrmen una alianza que tenga su propio sello de calidad: las maquinas que reparan y dejan a la perfeccion que luego son revendidas o donadas deberian llevar un sticker de la alianza de calidad, asi de esa forma el que las recibe esta 100% seguro que es un equipo que funciona perfecto y fue tratado por verdaderos artesanos de 8 bits
Gracias! Me parece un poco pasado lo del sello, pero muchas gracias por ponerme al nivel de mis héroes retro 😃
You say ugly some of us say beautiful. She's working again.