Science of Cambridge (Sinclair) MK14 restoration

[mpk]

Salvaged this from my parents' attic recently - my brother's Science of Cambridge MK14. Clive Sinclair's first computer, and predecessor to the ZX80. It's really grungy from 30 years or so in the (non temperature-controlled) loft. I have a vague memory of messing about with it trying to get it working decades ago and blowing up the voltage regulator (which made my brother unhappy), but as this is 2018 and it runs from a 5V supply it can be powered simply enough by USB.

It is, however, fairly dead. I have to wonder if I blew up anything else while blowing up the voltage regulator, and there's very little troubleshooting documentation out there (even the original manual just says you can send it to Science of Cambridge and they'll fix it for a few quid, but I don't think that option is available any more. There's definitely a clock, and poking around the CPU with a scope reveals some strobing on a few pins which suggests that at least the CPU is intact, but right now I decided to unsocket all the chips (while silently thanking my brother for using sockets 40 years ago instead of just soldering'em in) and give it a clean to make it easier to see what's going on.

Unusually, I've also got the VDU card - a famously useless device that took up 512 bytes of the MK14's 640 bytes of RAM, thus leaving you a whole 128 bytes in which to write your fully-featured word processor. I guess it had hack value, at least. The jumper wires all over the back of the PCB are connecting the CPU bus to the bottom half of the MK14 edge connector as SoC for some reason didn't think that would be a worthwhile thing to do (more likely it would have involved a complete redesign of the PCB to fit the extra tracks in). The keypad is a third-party unit that's installed over the (classic Sinclair..) metal dome clicky "keyboard" and hooks into some undocumented edge connector tracks to the right.

Once it's back together.. hm, no idea where to go next. Almost all the chips are still in production, so I'm shopping for a few spares (thank you for the SC/MP, eBay) and I guess that if I end up not needing them all I'll have the parts sitting around to build another MK14 on one of the modern clone PCBs that are floating around out there!

[CJay]

Ooh nice, I'm not sure you'll run it from a 500mA USB supply though, maybe a high current USB PSU...

[mpk]

The manual claims that 480mA will do it, but I'm not convinced. Should maybe try something with a little more oomph, yes.

[mpk]

I've been doing a lot of poking around with the 'scope, and while there are definitely signs of life coming from the CPU (there's a clock, and bus activity) I suspect it's not getting further than powering up. Starting to wonder if the PROM chips are duff (can PROMs lose their mind over time?), and beginning to wonder if there's any way to get hold of a replacement pair of PROMs. The good news is that the machine is an issue 5 board, so much improved over the earlier versions, but the bad news is that it doesn't work..

In the meantime, I guess I'll start doing some tedious continuity testing to make sure there aren't any bad traces or (more likely) knackered old IC sockets.

[MK14]

My post may sound like I'm stating the obvious. So my apologies in advance, and anyway, I'm not clear on how experienced/learned in Electronics/debugging, you are.

You basically have something (MK14), which normally works just fine.

So if it is NOT working correctly, one or more of the following has occurred. Or something else!

One or more of your connections has failed (you seem to have a VERY CRUSTY example, and I'm sort of  when I look at it, sorry).
It even seems to have extensive modifications done to it, which cause me to go  multiplied by x1000. Because I DON'T know what those modifications are, and they could easily stop it from working.

One or more of your integrated circuits has failed (ebay China ICs, can be fake/faulty, so take care). Some ICs (in my experience), seem to be able to break (go bad), all by themselves, just because they are suddenly, 20/30/40+ years old. ESPECIALLY old dram chips, which fortunately, are absent, from the MK14's, at least a standard, non-expanded one.
Old PROMS in theory, should keep their contents (despite approx being 40 years old) just fine, because they are suppose to use burnt links (rumored to be something like breakable weak diodes, via excessive/bad voltage and current), but in practice they could break and/or be more modern ones (probably NOT for an ancient MK14), which are rumored to really be one time use, flash like memory (OTP).

Your power supply and/or the on board regulator is problematic/faulty. I DON'T (my opinion), like NOT having an on board regulator. Because the older ICs, need/wanted tight 5V, well regulated supplies.
The MK14, is not really designed to cope, with 5V supplies, which have 1 metre (wild estimate) leads, along with the associated, possible voltage drops and problems with switching noise, ground voltage variation etc etc.
The common, USB power supplies, are usually/often (but NOT all, best is properly isolated ones), based on some kind of mains voltage dropper. Which can mean the 5V rail, is not very accurate and/or noisy, and it can even have significant, voltages, between it and ground.

E.g. 100V at around 500 microamps (again, a wild estimate), which could (in theory), mean that when your hand is close to the circuit board, enough of that stray voltage maybe could blow the NMOS (and similar) ICs. Especially as a rule of thumb, says that relatively old technology, such as the MK14, made from very old, 1970's technology, either didn't have ESD protection (i.e. input protection diodes) and/or had very weak ones (because it was the 1970s), which don't help that much.
Although it (MK14) has a lot of TTL, which tends to cope with ESD, quite well.

Although I (would expect) to be able to fairly easily fix it myself and/or with the help of equipment (some of which I may only obtain, when needed), which you may or may not have or want (such as 2 or 4 channel, ideally digital storage scopes and/or logic analyzers, if it gets really nasty to fix, which it SHOULDN'T).
I find it very difficult to try and advice people, across forums, how to fix/debug, their microprocessor computers. Even though I can fairly easily do it, when the equipment is in front of me.

Partly, because I can rapidly get test results, within minutes. Whereas I can say, please take a trace of the  Address lines, and post a picture of it. Then, 10 days later, they come up with completely different test(s) reports, and I've forgotten what was going on, as well.

If I had it in front of me now. I'd probably make sure it had a decent on board regulator, that the decoupling capacitors, are all present and don't look like they have aged too much and/or I'd test them (very especially old electrolytic capacitors, which tend to fail, as they get older).
Then observe the address lines (and other things), starting from the lowest address bit, and see to what extent it is trying to work.
I.e. Is it almost fully working, or has it got major issues.

Sorry if my post is too long and/or I'm NOT helpful enough.

[Gyro]

Your power supply and/or the on board regulator is problematic/faulty. I DON'T (my opinion), like NOT having an on board regulator. Because the older ICs, need/wanted tight 5V, well regulated supplies.
The MK14, is not really designed to cope, with 5V supplies, which have 1 metre (wild estimate) leads, along with the associated, possible voltage drops and problems with switching noise, ground voltage variation etc etc.
The common, USB power supplies, are usually/often (but NOT all, best is properly isolated ones), based on some kind of mains voltage dropper. Which can mean the 5V rail, is not very accurate and/or noisy, and it can even have significant, voltages, between it and ground.

Supply decoupling on the MK14 was pathetic. Just look at those few long leaded ceramic caps.... and as for that long leaded bulk electrolytic in the middle of the board, just 

You might do better with a more 100nF caps tacked across the supply pins of major IC (stick them on the back for cosmetics).


P.S. I remember that old bipolar PROMs had a failure mode where fused junctions tended to regrow (dendritic), I don't know if that applies to the ones in the era of the ones used in the MK14.

[mpk]

One or more of your connections has failed (you seem to have a VERY CRUSTY example, and I'm sort of  when I look at it, sorry).
It even seems to have extensive modifications done to it, which cause me to go  multiplied by x1000. Because I DON'T know what those modifications are, and they could easily stop it from working.

The mods are the jumpers required to bring the bus out to the edge connector in order to drive the VDU card. I've already reversed them to return the machine to "base" state. Other than that there's a jumper to row 8 on the 7445 to allow it to address the ninth digit on the LED.

If I had it in front of me now. I'd probably make sure it had a decent on board regulator, that the decoupling capacitors, are all present and don't look like they have aged too much and/or I'd test them (very especially old electrolytic capacitors, which tend to fail, as they get older).
Then observe the address lines (and other things), starting from the lowest address bit, and see to what extent it is trying to work.
I.e. Is it almost fully working, or has it got major issues.

Well, the state of the thing so far (especially now I've given it a thorough clean to make it easier to work on) is more or less "working, almost". The CPU seems fine - poking at it with the scope there's bus activity and strobing away on NENOUT and NBREQ, and just powering the CPU without any memory it looks like it's walking through the address space trying to find something to tell it what to do. A couple of leads in the LED flex cable (my, what a horrible part that is) have broken, but they're replaceable. Putting the memory back in there's plenty of bus chatter but no action. I spent yesterday evening hacking together an Arduino to read the PROMs - there is clearly *something* on there, which is a start. It didn't match at all with the hex listing in the manual for the (new version) monitor, but it's quite possible that all that means is I screwed up the bus addressing.

I agree with you that power supply is the one thing I want to get right before anything else - should have a replacement regulator in the next day or two (DHL willing). Once that's taken care of, we'll see..

My parallel project at the moment is building a clone MK14 (on one of Martin Lukasek's issue V boards, as that matches the original machine) using the almost-complete set of parts I've acquired. Once that's done I'll hopefully have a known working machine to swap chips into, which should make troubleshooting of the original way easier. If a chip's duff, replace it, and if not - time to get back to the multimeter and scope.

Sorry if my post is too long and/or I'm NOT helpful enough.

Helpful is great! And better too much than too little information, as all this will get ingested by the Googlebot and searchable for future reference.

[MK14]

Great.
I think you have made really good progress! 

The mods are the jumpers required to bring the bus out to the edge connector in order to drive the VDU card. I've already reversed them to return the machine to "base" state. Other than that there's a jumper to row 8 on the 7445 to allow it to address the ninth digit on the LED.

I see.
I'm glad you returned it (for now), to "base state", because otherwise, it can cause confusion, while you are trying to debug/fix/diagnose it.
Especially, when the modifications are unknown/undefined and/or it is not even known if it was still working, 40 years ago, after the mods had taken place.
But as you have explained, you did know what the modifications were.

jumper to row 8 on the 7445 to allow it to address the ninth digit on the LED

That makes a lot of sense.
It seems a bit silly to have 9 digits on the "screen/display", on board circuitry, which is ready to drive the ninth digit. Then just leave it unconnected.

(especially now I've given it a thorough clean to make it easier to work on)

That is a very good idea.

LED flex cable (my, what a horrible part that is)

It can be handy, because you can use its sturdiness, to move it to the ideal viewing position.
But I can understand, why some people, would dislike it.

hacking together an Arduino to read the PROMs

That's a good idea.
I considered (for you), to use a modern/cheap (ebay/China) EPROM etc, type of reader/programmer device. But off-hand, I'm not sure if they can cope with such an old PROM device, from around 40 or so, years ago. Without researching it.

I'm not sure if there is one version of the "PROM" software, per board issue, or if they regularly updated the version of the firmware in the PROMS, a number of times, per board issue. The answer to that question, might be available somewhere.

Speaking about electronics in general. If a component is 40 or 50 years old. It is a matter of luck/experience/conjecture, if it has/will survive that long. Many parts do and will, but not all of them.
So I would not be surprised if the PROMS are 100% fine (hopefully), or if bit rot, has set in.

As you seem to already know, later EPROM/FLASH type chips, are known to potentially lose their contents, after a number of decades. So, ironically, PROMS may be a saving grace here (although proper mask ROMS, would probably be the safest long term bet).

[mpk]

After a little more work, here's how the machine now looks - much cleaner, and with the caps replaced. Now with a voltage regulator and a heatsink - got a nice smooth 5V from a 12V wall wart (need to find a 9V to save heating the LM340 too much, but all I had to hand was 12V). The keypad's mounted again for the photo, but I'll be unmounting it again shortly as it's not connected yet. The original SoC keypad overlay was underneath, but it's in a very gnarly state and not suitable to be presented to the world.

A couple of traces from the 'scope too - one's the low bit of the data bus, the other's (if I remember correctly - my mind's gone blank) from the address bus.

Still no response from the machine but hey, at least it looks the part now, right?

I think my next step will be to start swapping out logic ICs with new ones. I don't have replacement 7408s (got some on the way from an eBay seller in the UK which I *hope* will be decent), but the rest I have to hand now. Unlikely to provide a magic fix, but it can't hurt to try while I'm waiting for a couple of other bits.

[MK14]

Thinking out loud (probably completely wrong)...

The first trace (data line), seems to be repeating the same pattern, over and over.
Is it continually resetting for some reason or crashing, and restarting ?
I.e. It should really be continuous (no gaps), and NOT repeating, if it was working, correctly.

The second trace (address line), if it is an address pin, doesn't seem right. It seems to not be sticking to logic 1's and 0's (taking into account, possible tri-state phases).

Alternatively, it could be because the scope is not set fast enough, and so the signals look funny.

I wonder how the chip select/enable/output-enable pins are looking (Ram/Proms etc) ?
They may be showing some kind of fixed, patterns, while this is going on ?

EDIT: To save time, I guess just one or two of the chip select lines (one trace with the RAM, the second trace with the PROM), and maybe use the second channel, to show something useful, like the data line, at the same time, would give more information.

Clips like these can be handy (easy, semi-permanent probe attachments):

[glarsson]

If the trace was without PROM installed then the Z80 is reading the opcode FF, rst 38h, over and over again.

[mpk]

Here are some more traces. The first two are CS on PROM (yellow) vs D0 (purple) and the same for a RAM chip. The third (just a bit of fun, don't cha know) is chip select on PROM (purple) vs RAM (yellow).

[mpk]

(by the way - one interesting point is that I have no idea whatsoever if the PROM chips are the right way round as they were completely unmarked. I can easily work around that by swapping them over to check both combinations when debugging..)

[glarsson]

You can't just turn chips around willy-nilly. The probability of a blown chip is high depending on where the power pins are located.

[mpk]

You can't just turn chips around willy-nilly. The probability of a blown chip is high depending on where the power pins are located.

Yes, I know that. What I mean is that there are two 4-bit PROMs - one has the high nibble of the monitor code, the other the low - and they may (or may not) be swapped over.

[glarsson]

Ok.

[MK14]

If the trace was without PROM installed then the Z80 is reading the opcode FF, rst 38h, over and over again.

The MK14, uses a National Semiconductors, SC/MP cpu (SCAMP), there is no Z80, here.

https://en.wikipedia.org/wiki/National_Semiconductor_SC/MP

[MK14]

(by the way - one interesting point is that I have no idea whatsoever if the PROM chips are the right way round as they were completely unmarked. I can easily work around that by swapping them over to check both combinations when debugging..)

I was going to suggest labeling them (PROMs) to you. But then thought I was being silly, and would just keep quiet, as you would realize and/or they were already marked differently (I hoped).

If you have got the hex dumps from the chips (via your Arduino project), you should be able to recognize valid instructions, values (stored numbers, e.g. via immediate instructions) and start addresses, contained in the dumps.
Hence be able to work out, which has the high nibble and which has the low nibble.

Or feel free to post the hex dumps here, and I/we can take a look.

[MK14]

Here are some more traces. The first two are CS on PROM (yellow) vs D0 (purple) and the same for a RAM chip. The third (just a bit of fun, don't cha know) is chip select on PROM (purple) vs RAM (yellow).

Thanks!
Those traces look good. I can't immediately see major faults.

Can I suggest a, hopefully fairly quick experiment.
Take traces, just like you just did, with the same pins, setting etc.

Except, remember the first set of oscilloscope traces you posted, in this thread. Where the data line, seemed to have a bunch of data, then a long gap, then the same pattern was repeating, around three times, altogether.

It would be very interesting, to try and get, exactly (similar would be fine as well), the same trace (it may need repeated triggering, and/or messing with the triggering and/or changing the timebase etc), but have the extra chip select information on it as well. Maybe check out other signals, if you like to play around.
E.g. Check the reset pin, as well. Has it settled down, or is it changing, in alignment with the data pin ?

i.e. Like the first trace, in this post https://www.eevblog.com/forum/projects/science-of-cambridge-(sinclair)-mk14-restoration/msg1916483/#msg1916483 , but with the other channel, attempting to show more information about the possible fault. E.g. Chip select, Reset pins etc.

Please DON'T take what I just said as a rigid, firm set of test(s). Rather, feel free to play around and look at signals, and if you see any which look funny/suspicious/odd etc, feel free to post them.

tl;dr
Where you have bursts of databus activity, then apparently too long gaps, is very interesting, because it is likely to show faulty activity. Seeing other pins, can then help to pinpoint why, it is doing it.

Also, trying faster and slower timebase settings can help, because it can spot possibly faulty patterns in the signals.

[MK14]

If I can make a suggestion. It is, that getting the PROMS, high and low nibbles, the right way round is the first priority (BEFORE taking further traces).
Because, otherwise, that alone could be why the earlier datatraces, looked suspicious/faulty.

I.e. As I think you know anyway, if they are the wrong way round. It will just crash all the time, and produce relatively nonsense traces. The traces would be understandable, but they would just show it haphazardly doing crazy things (i.e. crashing).

[MK14]

My apologies. 

I realized afterwards, that I had not given you the best of advice.

It dawned on me that people who made these MK14 computers by hand, must have had a reliable way of identifying, which PROM was the high nibble and which was the low nibble.

Scratching my head, as it is around 40 years, since I made a MK14. I vaguely remembered either a slightly different number, on the right of the IC part number, or a coloured spot or something. But I was not sure, as it was too long ago.

I've checked with the manuals, and apparently, there is a WHITE SPOT, on the PROM, which belongs in IC socket IC2 (which is in the corner). Obviously, the other one, goes in the other position.
Please see the very end of the manual, where the schematics and parts lists, are located.

Source:
http://s400081762.websitehome.co.uk/manuals/mk14ManualV1.pdf

[mpk]

Any white spot on one of the PROMs is long gone, although I had noticed a vague smear on one which might have been 39 year-old glue residue so thought that might be IC2.
However, I now have a working MK14! Okay, it's not the same one I've been debugging - my Issue V replica PCB and PROMs arrived so I populated it today with the various spares I'd been accumulating, powered it up and it worked first time (I know, deeply suspicious).

I've tested all the chips from the old machine in the new one, and from that I've learned that the PROMs are, indeed. duff. The machine interprets enough garbage from them at startup to throw some junk onto the LED before looping back and doing it again. This must be the repeating pattern I saw in the traces I took a few days ago. The lack of display of that mess on the old machine might well be explained by the broken lines on the display flex. So, new PROMs installed (lucky I got two sets), and now I just need to repair the display flex and get hold of a crystal to replace the one I "borrowed" to get the new machine working and we can take it from there. Today's experiment has shown that the rest of the ICs are working just fine, so if the machine doesn't work after this we're probably looking at a worn IC socket or some subtle PCB damage.

[MK14]

Congratulations.
You have made really good progress 

I think the MK14 clone/copy/modern-PCB version, is looking really good (apart from the keyboard/keypad), but that is just because it hasn't been labeled yet.

That's why I wanted to find out more about the "suspicious" repeating scope trace(s) you were apparently getting. So, as you have just explained, it was getting to at least one of the causes of your malfunctioning original MK14.

I guess the failure of the PROM(s), could be through what Gyro suggested ("P.S. I remember that old bipolar PROMs had a failure mode where fused junctions tended to regrow (dendritic)"), or some other reason.
I vaguely imagine in my mind, the weaknesses of the structures which allow bits to be stored in it, may have meant they don't always survive, approximately 40 years of aging.

Sadly, the PROMS can be harder and more costly to replace than some of the more common components. But anyway, you were already able to source some PROMS, so no problem for you.
Especially if they need programming, as that can be tricky, these days.

[mpk]

It works! Took a bit of effort to get there but here's a shot of a cleaned up, fully functional Issue V MK14 complete with external keypad.

It turned out to be a couple of problems working together, but having identified that the PROMs were duff and replaced them I at least had a starting point to work from. The data bus on the machine looked pretty healthy when powered, but only the lower half of it. D4-D7 were full of junk. This pointed me towards the high nibble side of the board, where a bit more poking around with a scope showed the data lines on that side's PROM looking suspiciously quiet. This looked to be because CS was held high. Tracing the line back to where it came from (CS on the low-nibble PROM) everything looked fine, which meant it had to be the socket the PROM was plugged into not making decent contact any more. Replaced the IC socket and the machine came *mostly* to life but with a couple of display quirks - one digit was missing and the decimal point was stuck on on every digit. Traced the DP back and found another dodgy IC socket - replaced that and all that remained was the missing digit. Poking at the display flex it turned out that the relevant wire had snapped - whole thing was just worn out even thought I'd stripped it back and reterminated it - a small wiggle broke another 2 or 3 lines so I sighed, reached for the desolder wick again and replaced the flex with a more resilient but less flexible (and less prototypically accurate!) SIL header.

So that's it - now back in full working order with *almost* all the original parts still present. I'm trying to decide if I feel brave enough to tackle the VDU card next. Thanks for all the advice!

[MK14]

You have done a great job. It is looking really good now 
Just like (I remember) a MK14 should look like.

I number of things which I thought would be a good idea, but I did not mention them, you have done anyway. So, I'm pleased about that (there must be some relevant saying, but I would feel too boastful to mention, such as "great minds think alike").

Especially, (apparently) changing all the electrolytic capacitors (I hinted about them, but did not go as far as saying, definitely change them because they are so old, because opinions differ about it).
I also had the idea of using the new PCB MK14 to test/help fix the old one.
Putting on that small/sensible heatsink on the voltage regulator. I did similar, a very long time ago, but it needs care.
As, I would occasionally accidentally knock the top of the heatsink, potentially eventually metal fatiguing the voltage regulators leads.

It is a pity, some of your IC sockets, have gone bad and needed replacing. I presume it was the (somewhat) poor storage, that did it. But, after around 40 years, even if well stored, things can still oxidize and go bad.

I'm glad you were able to diagnose the digital issues, with the digital oscilloscope. You seem to have made sensible progress, with the checks, conclusions and repairs.
This is where the age of the MK14, actually helps a lot.
All the data and address bits come out on the board (unlike most microcontrollers), the PCB is not multi-layer, and there are no abnormally complicated chips on it.
Such as custom ICs (ASICs), FPGAa, ULAs, Gate arrays, Pals, specialist sound or graphics/video chips, etc etc. Which can make things much trickier to diagnose/fix and find replacement chips.
All of the MK14 is just standard (off the shelf, around 40 years ago) logic chips, Microprocessor, Memory and PROM.

It would be nice to get the video (card) thing working. Although the 128 bytes of free available memory, you mentioned earlier as regards when you use the VDU, is a total joke these days. It is still a fun and interesting project to get working.
The old ZX80/81 only had as standard 1K of ram, which was shared with the screen memory. Yet there was a very wide range of software produced for it. So I guess even 128 bytes, could be used to do something.
Ironically, machine code can do quite well, even with only 128 bytes.

These days, of high speed (digital) HDMI, in full 4K, is getting well beyond what a hobbyist constructor could easily do with some pieces of TTL logic. But I refrain from saying it is impossible to do, because there can always be someone out there who does it.