On Fri, Oct 14, 2016 at 10:41 AM, Gerrit Heitsch <firstname.lastname@example.org> wrote: > On 10/14/2016 10:17 AM, Francesco Messineo wrote: >> >> On Fri, Oct 14, 2016 at 9:54 AM, Gerrit Heitsch >> >>> >>> If you have a C64 with all MT4264-xx on it and one goes bad, it's a good >>> idea to replace all of them, it's very likely that more will go bad soon. >> >> >> Maybe, or maybe not. I've never liked to change working parts. >> The C64 in that particular video was used almost daily from 1984 to >> 1990, then once in a while >> from 1990 to 1996 more or less. It will never see much use now, so why >> would I change them all? In case of another failure, I can change the >> failed chip(s) easily anyway. > > > Yes, you can... But I also do repairs for people who don't know how to use a > soldering iron and I had it happen more than once that I changed the > offending DRAM and a few weeks later the next one died. Just replacing all > MT4264 is cheaper than mailing the system back and forth again. I do too, and none of them failed on another DRAM chip so far. It's a matter of luck probably but it would also mean asking a price for a repair of things that aren't broken and anyway a C64 is still so cheap that it's difficult to ask something really worth for spending a few hours on a repair. What if you would find a Fujitsu DRAM chip bad among the 8 on a board? All with the same datecode? Repairing old hardware is always tricky. You can change all the DRAMs and even all working MOS TTL chips (just because they could fail tomorrow or in the next 10 years) on a particular C64 and when the owner gets back the system, one of the ROMs or a CIA goes bad for no particular reason or just because the original C64 power supply is crap. I have a C64 board where someone probably hooked the power supply into the IEC port, or at least that was a possible explanation for all the burned tracks, diodes and all the rest I had to change to repair it. > > You can use 41256 as replacement for 4164 in a C64 BTW, you only need to add > a connection between Pin 1 and Pin 16 of the DRAM. 41256 are easier to get > as NOS and are cheap too (less than a Euro a piece). They use 8Bit refresh > so there is no problem in the C64. I know it. But as I said, I have 4164s left for a couple of lives probably. I keep the 41256 for board where they're really needed. > > >> I've a good collection of failed MOS chips, for some reasons I've >> never kept bad chips from other brands, just discarded them (so I >> sadly don't have a collection of failed DRAMs). > > > Another kind of chip that doesn't age well are the MOS TTL replacement they > made when LS-TTL were in short supply. Especially the MOS 7708 (74LS257) are > known to fail now. yes, I've changed quite a few of them. On the other hand, my collection shows more 7707 failed than 7708. I still have 7708 and 7709 working, no 7707 working left that I'm aware of (maybe inside some 1541/SX-64, I didn't check very well on those). > > > Well, if you have a board with a dead 7708 and the other one has the same > datecode, better think about replacing that one as well. I have precisely a board with a 7708 that failed and the other one that still works. And it will remain there as long as it works. On other boards, both failed and were substituted. If I had to trust my "bad chips" collection, CIAs are by far the most commonly failing chips. But there's a reason for this, this collection started in the '80s when I was already repairing Commodore stuff, and we all hooked things on our computers. And CIAs are right with the pins on the outside world. Once I killed a CIA in my C64 because I was redoing some solder joints inside a joystick and I just forgot to unplug that joystick (or I didn't even bother to unplug it and even to turn off the C64) before grabbing the soldering iron. It was probably 1985 or 1986, replacement chips were cheap :) Most of the CIAs in my collection would "boot" fine in a C64 though, they have one or two bad bits in the ports. But I digress. Frank Message was sent through the cbm-hackers mailing listReceived on 2016-10-14 10:00:08
Archive generated by hypermail 2.2.0.