The 1984 Timex Computer 2048 that [Drygol] recently got his hands on was in pretty poor shape. Not only did it have the mangled exterior that comes from several decades of hard use and furious typing, but the internals appeared to be shot as well, with the machine showing nothing but vertical lines when powered up. Thankfully, this retro computer virtuoso was more than up to the challenge of bringing it back from the brink.
After a good cleaning and the installation of a reproduction front panel, the Timex was already looking much better. Unfortunately [Drygol] says he doesn’t currently have the equipment necessary to touch up the graphics and lettering on the key caps, but the fact that he had to qualify that statement with “currently” has us all sorts of excited to see what he’s planning down the line.
Of course beauty is only skin deep, and this particular TC-2048 was still bad to the bone. [Drygol] had a hunch its Z80 processor was dead, but after swapping it and its socket out, the machine still wouldn’t start. Though he did note that the garbled graphics shown on the screen had changed, which made him think he was on the right track. He then replaced all the RAM on the board, but that didn’t seem to change anything.
There isn’t a whole lot else to go wrong on these old machines, so the final step was to try and replace the ROM. Sure enough, after installing a new Winbond W27C512 chip with the appropriate software burned onto it, the nearly 40 year old computer sprang back to life.
Another classic computer saved from the trash heap, but it’s all in a day’s work for [Drygol]. Over the years we’ve seen him perform meticulous repairs on computer hardware that any reasonable person would have given up on. Even if you’re not into retro hardware, his restorations are always full of fascinating tips and tricks that can be applied when repairing gadgetry from whatever era happens to tickle your fancy.
Since EPROM is a form of dynamic memory (just with very (very) long refresh times), it’s not a big surprise that 40 year old chips are losing their data. It’s quite likely that even if it was a one-time-programmable (i.e., an EPROM without the window to erase it through), if the exact same code was reprogrammed into the chip, it would probably run for a couple more decades.
+1
So eventually, the crystals “grow” back so to say ?
IMHO, I do imagine ROMs as a hi-tec simulation/emulation of a diode-matrix.
Before ROM/EPROMs existed, telegraphy beacons (morse keyer) use diode-matrices.
And before that, core memory. The permanent one as used in early space exploration, not the RAM type that looses its information during a read.
And before that, they used mechanical wheels with short/long slices – a light barrier then scanned the them.
PS: Sorry for my poor English.
Even simpler than that: EPROMS work by using a high voltage to overcome an insulating layer to charge a capacitor, and believe it or not, that capacitor stays charged for the life of the chip, kind of like the capacitive element in an electret microphone.
So it really IS a dynamic memory cell, but with a very well insulated capacitor. Same with flash memory, and this is why they wear out over time – as I understand it, each time one of these capacitors is charged, it damages the insulation a tiny amount, so after a large number of write cycles, the leakage current gets high enough to cause bits to get lost.
The original was a PROM that (probably) used fusible links not an EPROM with charged isolated gate memory cells. PROM retain data much longer than EPROM although I’ve heard of stories about what Joshua above alluded to where silicon migration messes with the links. Now [Drygol] did replaced it with an EPROM which has an expected data retention period of around 10 – 15 years so chances are it’ll need to be re-burned once or twice before another 40 years passes.
ROM Rot is a very real problem on gear of this era. In my repair rotation is a microprocessor controlled Tektronix Oscilloscope (a 7854), and the Mostek mask ROMs are notoriously flaky. Thank god there’s enough people out there who love dumping & preserving these ROM images!
I think the same my fellow vintage friend! 🙂👍 Many users of the vintage society are essentially, um, “software archeologists”. Together, they (we) will preserve the roots of the digital age. Thanks to them, future generations don’t have to worry about loosing knowledge about the foundation of their culture. Geeks like them/us will silently guard old technology of yesterday and tomorrow, so there’s nothing to worry. The future will be bright, because there will always a few involved people which will keep stuff running, no matter what silliness (softw. pat., copyrgh., drm, software as a service etc) is there to come. :)
Seems like a rather ham-fisted approach to repairing what is, effectively, an upgraded Spectrum. Starting with DiagROM and a logic probe would have told him if the CPU was shot, and then if the RAM was a problem. Plenty of vids on YouTube on the procedures to follow.
Disagree. This is classic top down troubleshooting and is much more efficient than starting from the bottom. If he was working on the CPU pins he’d have to verify that each one was operating properly and within spec. If he found a problem, he’d replace the CPU, just as he did first.
Also, you can see that the major chips are socketed. Much quicker to just swap in a known-good chip than to do a lot of analysis.
So you’re saying that since you have a different solution, this invalidates his solution. Good to know.
What I’m saying is that his method may have worked, but it results in what may be perfectly good parts being discarded. Better to locate actual faulty components before pulling them. What’s more, the Z80 may have been socketed, but that was replaced also. The DRAM chips were not socketed. Both risked damaging the PCB when the CPU may have responded to some DeoxIT and the DRAM chips may have been fine.
“Better to locate actual faulty components before pulling them. ”
You can say that, but in fact it is not always possible to properly test such components (did you methodically check each machine language opcode? Did you test every bit of the RAM ?) in which case you are better off just replacing stuff on principle (looking at old electrolytic caps here, they test fine today and then they die tomorrow). It also depends heavily on how difficult it is to replace them, again for old caps the job is easy so just do it. If you have good gear and good technique then pulling parts can be very low risk.
If you’ve got the wherewithal to burn a copy of DiagROM then, once the CPU is functioning and you’ve got a video signal then you can test the rest of the system. The CPU may have been functioning, but it had tarnished pins and a tarnished socket. Nothing more than pulling it from the socket and cleaning both would have given you enough info to decide if it really needed replacing.
Wholesale replacement of parts based on a guess is, at best, kack-handed. Likewise pulling capacitors with out any indication that they have gone bad (or are so likely to do so that it is preventative maintenance) is poor form.
@[Sweeney]
I used to repair computers from this era professionally and this is how it was done. The focus is the time it takes to repair.
None of this is about guessing, it’s about experience. If a component is the most frequent failure then you replace it first. Then other components that are socketed as it only takes a moment to replace them with known good parts.
Something else you have to consider, how much is your time at the bench worth? The priorities are quite different in a production setting or if there are other things you want to accomplish with your own limited time. When I was working, it was frowned on to spend an hour analyzing four chips to find a defect rather than spend $2 and 10 minutes to shotgun all of them. The removed parts went in the “questionable” pile to perhaps be swapped into service to see if they still worked but more likely just discarded. It generally wasn’t worth the time to exhaustively test especially if it was an intermittent problem with an inexpensive component.
There’s plenty of help on https://spectrumcomputing.co.uk/forums/index.php