When is a ground not a ground?

The control board PCB design was finished but I had a nagging feeling there was something wrong with it. So one last time, I checked that every single trace was connected to all the right places. I found a nasty collision where some weeks back I had moved a chip sideways and not noticed that two traces were now overlapping. I fixed it and eventually got to the end of the checking and had the board manufactured. When it arrived, I started at the oscillator section, and populated it bit by bit, testing each bit as I went. If something was wrong, I would have a good chance of knowing where the problem was. But everything was working, so far. In the end I just went ahead and added all the remaining components. I tested it with just the memory board connected and confirmed that it could fetch instructions from ROM. I could see the PC and instruction register on the lights, confirm that the other signals were doing the right things, and I could see it doing jumps and branches. It was time to connect the whole thing together and see what happened.

I was using the test routine that I had written for the simulator. It seemed to be working, but sometimes it would halt, meaning a test had failed. This was random. Sometimes it would run from reset and sometimes it would halt, or crash. I couldn’t understand what was going on. It was so close to working, but randomly didn’t. Around this time I noticed that two of the lights, data bus bits 0 and 1 were flickering in a way that was not normal. I discovered while single stepping, that these two bits were doing something very weird. If I pressed reset, they would go off, but after a few seconds, one of them would come on. Or not. It was random. I couldn’t understand how this was possible when the machine was not freely running as nothing should happen until I pressed the step button. I removed some chips and did some multimeter testing, and that was when I noticed that there was a current path between the reset line and those two bits. There is no deliberate connection between the reset signal and the data bus, but I was seeing a 300kΩ resistance between them. And that was when I finally noticed that the reset signal was running right alongside the data bus ribbon cable connector, so close that it actually passed under the plastic connector block. I knew there had to be some foreign body under this component that I had missed while soldering. I had to take the thing off. Luckily, these are split into two sections and one is only 8 pins wide. I desoldered it, and found a tiny pool of brown goo which was touching both the data bus pins (0, and 1) and the reset line. This goo was conductive! It turned out to be dirt and flux that had oozed under the connector out of sight while I was soldering it. What was happening was that the reset signal (which is high normally and low during reset) was applying a certain amount of voltage to the data bus pins; just enough to upset the input to whatever chip was reading them. I cleaned the goo off, resoldered the connector, put everything back together — and the glitching was gone. Unbelievable! The lesson here is never to run a trace so close to a connector that it goes under the plastic, because then it is obscured and you can’t see if there’s something bad touching it.

Things started to get better after that, but the machine still sometimes crashed after reset. It was like starting a car; if it got started it ran for ages, but if not, it didn’t work at all. I started writing some more test routines, including a memory test. But I was still seeing some weird random problems. This time I homed in on register R7 which I was using as a stack pointer for subroutine calls. It seemed as if it was randomly being reset to zero. I was able to confirm this with the scope. It seems that sometimes, R7 got cleared when it was not supposed to. I soon discovered that this happened when R0 was counting down in a loop, in particular it happened when R0 went from 0000 to FFFF. I put a scope on R7 ‘s reset pin and this is what I saw:

Bear in mind that this pin is supposed to be high all the time! If you know how to look at this, you can actually see the fact that something is counting down, and at the point where that goes from 0000 to FFFF there is a sudden jump in the interference. That was just enough to trigger the reset pin. At this time, I couldn’t understand why there was so much interference on this line. There was much less on R1 and R2, so why was R7 so bad? It was almost as if the physical distance of the register from the top of the board had something to do with it. In fact, I discovered that R6 was suffering from the same problem. At this point, the simplest solution seemed to be to get rid of the reset function on the registers. There’s no need for it anyway and I don’t know why I bothered with it. Much safer is to just tie them high so they can never be activated. So I cut the traces and added little bridge wires to tie all the reset pins high. The problem went away. But I had fixed a bug without understanding it, and this was going to come back and bite me in the arse one more time.

I had almost got the memory test working but something odd was still going on. I narrowed this one down to R7 being cleared again, except this time only the high byte of it. And this time, it wasn’t being reset, it was being written to when a different register was the destination. But only the high byte. I put the scope on its write pin and saw the same kind of noise as earlier. Where was this noise coming from? I had been extremely careful with the write strobes because they are clocks and you have to be careful to keep clocks away from other traces so they don’t pick up noise. But here was a ton of noise coming out of nowhere. Could it be power supply noise? Ground bounce? Something else? I had organized the chips in groups of eight, with careful separation of power and grounds, each group having its own supply capacitor and each chip having its own bypass capacitor. I thought I had followed all the best practices. But I’d missed something. It was something to do with the distance of R7 from the other end of the board, I was sure. Perhaps the clock trace was too long? Well, no. It was only about 5 inches away from the chip that creates the clock signal. I looked at that chip and put the scope on the output pin that generated the noisy signal. It was clean. But when I measured it at R7, it wasn’t. But it was the same signal. How could it be clean at its source yet dirty 5 inches away? Then it hit me. It all depended on where I connected the scope’s ground; which ground I was referencing it to. The generator creates the signal referenced to its own ground, but when R7 receives it, it’s referenced to R7’s ground. These grounds are not the same, not at all the same. I’d seen this before on breadboards but thought it was just because breadboards are crappy and have bad connections. I’d assumed that proper PCBs would have a solid clean consistent ground. What a naive fool!

I had a flash of inspiration. I was able to see the problem happening in real time and I would know if it was fixed. What would happen if I just connected a wire from R7’s ground pin to the source chip’s ground pin? I tried it. Instantly, the problem was gone. Even though these two chip grounds were already electrically connected together, another dedicated connection solved the problem. And then, finally, I remembered something I’d read once but didn’t understand. When you have a clock signal that has to go a long way, it’s a good idea to run the ground return alongside it. I had been concentrating on power ground rather than signal ground. The ground return path from R7 back to the clock source had to go all the way around the edge of the board and then back down into the middle. Providing a direct path back fixes the problem. Now I think that this was exactly the reason for the reset problem as well. If I had fixed the reset glitch by doing this, I wouldn’t have had this problem at all.

Later I started getting a similar problem on R2 which drove me almost nuts, until I realized that just fixing R7 was a bit dumb. So I added dedicated ground returns to all the register chips. Since that moment, LEO-1 has been working flawlessly, even after reset. It just doesn’t crash anymore. And it’s working at 4MHz when my design goal was only 1MHz.

I almost gave up on this project so many times and all for the want of a bit more knowledge. I started doing it because I thought I knew enough about electronics to pull it off. But now I feel like I’ve learned everything I know about electronics by doing it!

LEO-1 working

Advertisement

The Good, the Bad and the Ugly

The next thing I got obsessed with was the keyboard. At first I had planned to get an old keyboard off eBay and reverse engineer it. So I bought an old VT-260 keyboard and removed its circuit board to expose the raw key matrix connections and I spent a fair bit of time with a multimeter working out how that matrix was organized. I got as far as having my own microcontroller reading the keyboard and displaying simple scan codes. But by the time I had done that, I had decided that the keyboard itself was not really what I wanted LEO-1 to have. I wanted something special.

You may recall my admiration of the ICL 2900 series mainframes. Well, the keyboards those things had were absolutely gorgeous and nothing like anything I’ve seen before or since. I wanted LEO-1 to have a keyboard like that, but sadly, not everything is available on eBay. The closest I could come to that would be to make my own keyboard with a similar layout and similar keycaps. So I started reading about custom keyboards and found that there is a whole subculture of people who are really into keyboards. I found a great YouTube channel by this funny bloke who calls himself Chyrosran22 and watched all his videos. After a month or two of this I think I knew more about keyboards than I know about my own mother so it was time to take a step back and regroup.

ICL 2900 keyboard

While looking for keyboards on eBay, I had discovered a cool device called a Rubidium Frequency Standard which piqued my clock-obsession — and so I spent a few months building my own atomic clock! I already have enough clocks in this room and didn’t need another one, but I couldn’t resist. I had lost my way. It seemed that I was just finding excuses to postpone finishing LEO-1 and looking back I can now see that I was terrified that I wouldn’t be able to make it work. If it didn’t work, it would be the biggest waste of time and money and I would look like such an idiot for even attempting something as absurd as trying to build a contraption as complicated as this.

Even so, I had been working on the PCB design for the Memory Board and the Control Board during the autumn and they were pretty much finished. Eventually after obsessively checking it over and over again, I had the Memory Board manufactured and I populated it. My initial tests with switches were promising, but then something terrible happened. In 2015 I had seen a very weird problem when testing the ROMs where the data bus would go into continual oscillation for no apparent reason. I thought I’d solved it with bus termination resistors, but now this problem came back to bite me in the arse once again, this time on my nicely made PCB. I couldn’t understand why all these people out there could build entire CPUs on breadboards with loads of untidy wires and have it all work perfectly, but I couldn’t even get a ROM to work on a neat PCB. At one point I just considered picking the whole thing up and placing it into the trash, but of course that was only a fleeting thought. I tried all kinds of hacks and guesses but really had no idea what was going on. This problem only happened on ROM not on RAM or any of the other devices. I blamed the ROM chips; they must be buggy. I managed to crowbar an old-school EPROM into the socket and would you believe it, the problem happened on those too. I checked the data sheet over and over again and couldn’t see anything that could explain it. Then I realized what I was doing. I was using switches to change the address bus for testing, and I was doing it while the ROM was chip-enabled and also output-enabled. My VDU does that and doesn’t have any trouble, but I wondered what would happen if I followed the process that the real CPU would. The address bus would only change when the ROM was not enabled, and the output-enable would only be on for a moment. Well, when I started testing it like that, the problem went away. I visualized the problem as this: when you change the address, the internal circuitry of the ROM will ‘rattle’ as the device finds the correct cell to output. If the device is output-enabled, this rattling will appear on the data bus as a randomly changing mess lasting some tens of nanoseconds. This is high-frequency business; you don’t want that noise getting onto the data bus in the first place. Possibly, the length and layout of the PCB traces could cause frequencies like that to start an oscillation, and if the changes are ‘evil’ enough, it could create power supply glitches, ground bounce or such, which would upset the ROM, cause it to rattle some more… and around you go, ad infinitum. This is all speculation. The real cause is still somewhat of a mystery, but the important thing was that I found that as long as the rattling doesn’t get onto the data bus, you’re safe. Unfortunately, I also found that this happens if the ROM’s chip-enable and output-enable are asserted at the same moment, and my CPU design actually did that. The only way it would work properly would be if the chip-enable came first, then the output-enable, on a different tick. I was going to have to change the design of the CPU’s sequencer. It was an easy fix, and a lucky catch at the eleventh hour, especially since I had not ordered the PCB yet.

Ugly things on the data bus

 

You may recall that I have a terrible habit of going off at a tangent and ordering things that I hope to be able to use in the future, even when I’m not sure that any of it will work. Well, I had ordered a small thermal receipt printer a month before, so with the memory board working, I decided to try it out. This also enabled me to test the device expansion ports. I hooked up a UART to the memory board and the printer, and manipulated it as a device using the test switches. I was able to manually make the printer print a single character. So this means LEO-1 will almost certainly be able to use that printer too. Finally happy with these results, I decided to press on and finish the control board.

“You’re all clear kid, now let’s blow this thing and go home!” — Han Solo

The quick brown fox

Seems it’s been 10 months since I wrote a blog post so once again it must look like I’ve forgotten about LEO-1. In fact, plenty has happened and I finally have half a CPU core running on breadboards. But it took a long time to get this far, mainly due to being distracted by things that were ‘more interesting’ for a while.

I finished the ALU board back in December and my tests indicated that it was working fine. Then I decided that I would need to test the Control Board design before committing it to a PCB. This is by far the most complicated part of the system and although it was working in Logisim, I didn’t really know if I had transcribed it to an electronic schematic correctly. I had to at least prototype the major parts of it like the state machine and the program counter to verify that I had not made a huge mistake. So I started building it on my PB-503 workstation, starting from the oscillator section and proceeding to the state counter and combinational logic that would generate the main control signals. I managed to generate a few signals but it was already obvious that I was running out of room on the board. I needed a larger work space and far more than 8 LEDs and 8 switches to test this monster properly. So I designed a test board consisting of 16 LEDs , 3 eight-position DIP switches and a rotary DIP switch, and I had four copies of the PCB made. I hoped that would give me enough inputs and outputs to do almost anything.

LED & Switch Test Board

I also ordered a huge breadboard and started putting down the parts again. But again, I ran out of space — and wires — and the whole thing was already a horrible mess due to using jumper wires.  So I ordered another huge breadboard and a few boxes of those nice little pre-cut wire pieces. But while I was waiting for that order to arrive, something happened that made me put this project on the floor in the corner with a dust cover on it for five months.

I don’t remember what started it, but something got me reading about simple video generators; the kind that used a bunch of TTL chips and a character generator and produced displays like this:

These kinds of displays were seen on home computers of the late 1970s and early 1980s such as the Ohio Superboard II and UK 101. I was seized with a great desire to make such a VDU for LEO-1. I had already decided that I was going to use a simple LCD display, but this VDU idea got hold of me and wouldn’t let go. I just had to find out how it was done and give it a try. So I read everything I could about generating video signals and also studied the schematic of the Superboard II, a computer I had actually owned in 1981 or so. I started by bread-boarding a circuit based on the counter chain in that schematic to generate the video signal, and then started improvising the rest of it myself. I spent five months working on this and it drove me absolutely nuts. During this time I found that I was even starting to understand how the game Pong must have worked without actually reading about it. I got so obsessed with this thing that I couldn’t think about anything else — except my day job, of course 😉

By March I had a working display of what was essentially a bitmap of pixels, and I could draw on it using a micro-controller. But then I had to leave it for two weeks and go on holiday in Europe with my wife, during which time I got very ill and had a pretty horrible time, even though my friends and colleagues laid on some nice events for us. But travelling while sick is no fun (actually for me, travelling while not sick is no fun) — so it was rather awful and I managed to lose my phone while I was at it. When I got back home and looked at my breadboard, I found that I couldn’t remember a bloody thing about how it worked! I had to stop and draw the whole thing as a schematic so I could remember what all the wires were for. It looked like this:

I must have built and re-built this thing about three or four times as I refined the design, eventually having to abandon the graphics display as it was too slow to draw all the pixels. I finally settled on a character-based display which would be good enough for text and simple graphics. I also found it necessary to complicate everything by making it possible for the host computer to change the character height and horizontal resolution by writing to a special register. That final detail is why it took so long to finish. Once it was working on a breadboard, I set about designing the PCB. I had it made and put the parts on, and would you believe it… it worked first time.

This is not a very good picture and the display looks much nicer than that. In fact, the quick brown fox picture above is a good photo of my earlier prototype’s display. The board generates a monochrome composite video signal suitable for a CCTV monitor. I found a nice little monitor on eBay brand new and used it for testing, and it’s just the right size to sit on top of the finished LEO-1. Here’s the PCB. Cool things include the use of a real old EPROM for the character font and the fact that the D/A converter is just a bunch of resistors, something I didn’t know was possible before I started researching this.

The finished VDU board

So when you’ve got a screen, you also need a keyboard. It was already apparent that my original idea of a hex keypad wasn’t going to be enough. I needed a real keyboard, and so began the next project that kept my control board prototype gathering dust in the corner…

 

Taking the easy way out

Another six months has passed and I’m still not that much further along with the LEO-1. In the summer I started building the control board and tested a small section of it with good results. The oscillator, counter and first decoder plus some logic gates successfully generated some of the more important control signals. It’s a sad fact that it took a huge amount of time to get that section of the control board hooked up, and that only accounts for about a quarter of the whole board. Building the LEO-1 was starting to get seriously tedious.

Control board generating its first signals

At this point I chanced upon a distraction. I saw on eBay a 32 x 16 flip-dot display which was amazingly cheap, and always having wanted to play with one, I decided to buy it. This kept me busy from August until October while I built a really cool clock out of it. I had to reverse engineer it, figure out how it worked, and then design my own micro-controller and driver boards to make it work. And I had to write the software. It’s not finished yet, but it tells the time. It automatically sets itself from a GPS module too so it doesn’t even need any buttons.

Flip-dot clock

So, once again, LEO-1 took the back stage while I did something less tedious. But something happened while I was building the clock that changed my mind about the way I was building the LEO-1. For the first time, I actually had professional quality printed-circuit boards made. I used Express PCB which has reasonable pricing for small boards as long as you don’t bother with the silk screen and solder mask. When they arrived I was so impressed with the quality and speed of assembly that I started thinking about using them for LEO-1 as well.

PCB on flip-dot display

Now, earlier in this blog I had sadly stated that it would be too expensive to build the LEO-1 with PCBs, because the boards would have to be very large. If I hadn’t thought so I would have gone for it straight away and never looked back. But somehow I had convinced myself that I couldn’t justify spending large amounts of money on just the PCBs. What I didn’t realize was that instead, I was going to spend large amounts of time soldering individual wires, far more than the amount of time I would have to work to pay for PCBs. Besides, if I don’t accelerate the process I’ll never finish the blasted thing. So I did an experiment — I decided to build one of the LEO-1 boards in the PCB designer and see how it came out.

I chose the register board as it’s very repetitive. I then proceeded to spend two weeks working on it until I had painted myself into a corner and couldn’t place the last few traces. I had been so fixated on the register chips that I had forgotten to leave room for the traces to the LED drivers. This is what it looked like when I decided I was screwed:

Register board FAIL

I started again from scratch and spent another three weeks doing it right. When I wasn’t working on it, I was dreaming about it. I literally had dreams that involved trying to find efficient red and green routes from one place to another. I finally finished it yesterday. I had checked it and double-checked it constantly during the design process, but I was still unsure that it was correct. I checked it again. I printed it and checked it on paper, making sure everything would physically fit. I printed it to PDF and checked it at 800% zoom. This morning I finally decided to send it for manufacturing. As expected it’s quite big at 10.4″ by 13.3″. This is how it looks:

Register board

I’ve decided to keep the (almost finished) memory board as it is. I’m now working on the PCB design for the ALU and my experience with the register board has made it a lot easier to get it right. I’m already about half way through it. For a long time I couldn’t decide if I should keep working on the control board as it is, or ditch it and make a PCB for that too. I’m pretty sure that if the register board works out, I’ll do that. It’s annoying that I will have to desolder a bunch of stuff but at least I had the foresight to not solder all the pins of all the sockets and headers, just enough to keep them from falling out. It’s almost as if I knew…

Of course, I now have this nagging voice in my head telling me that I’m cheating. There I was, all set to build a CPU with my bare hands, but now I’m taking the easy way out. I just want to get it working so I can program it. Did the mainframe designers of the 1970s think they were cheating when they starting making their CPUs with PCBs instead of wire-wrapping? Hell no, they had simply found a way to save time. That’s how I’m justifying it to myself. I’m just saving time 😎

Slow motion

I can’t believe it’s almost the end of May and the memory board is still not finished. LEO-1 has taken a bit of  a back-burner position, it seems. This started in January when my wife and I moved to a new apartment. For several weeks before and after the move, I had precious little time for soldering, with packing and organizing taking priority. During the move I managed to hurt my back very badly by lifting my AKAI X-355 tape recorder incorrectly. The thing is built like a tank and weighs a ton. I was in terrible pain for about 3 weeks and couldn’t face any hobby stuff at all.

Somehow, I managed to not do any LEO-1 work during March either, having got out of the habit of even thinking about it. Then, towards the end of March I bought an old Conn organ from a charity shop and spent several weeks fixing it up. During April, I decided I needed a proper amplifier and speakers in the living room, and took it upon myself to build the amplifier myself. It came out beautifully and sounds great, but this project once again kept me away from the LEO-1.

I got back to it a couple of weeks ago, doing something that I should have done right at the start. I went through the schematics and labelled all the ICs with their numbers. The software I’m using, ExpressSCH, doesn’t do this in a very useful way when there are gates involved, because it numbers all the gates as separate ICs, which they are not. So I had to do it manually. When I finally finished, I found that I had 282 ICs in total, including the RAM, ROM and ZIF sockets. At the start, I had estimated there would be about 200. Believe it or not, I had actually gone ahead and ordered all the chips I thought I was going to need back last autumn, without actually doing a proper count. Obviously I had counted certain chips like the bus drivers and registers, but for AND, OR, NOT gates, etc., I had not bothered; I just bought a load of them cheap on eBay. This means that I now have a large quantity of surplus chips, in particular 74HC14. I had bought 50 of them for about 6 bucks and it turns out I only need three. I laughed out loud at that mistake and I still can’t really work out how it happened.

I also found I needed to change an important design decision, the decision to not use IC sockets for the numerous small chips. I had initially decided to not use sockets because they are so expensive and I need a couple of hundred of them. But while working on the memory board, I saw the glaring truth. If one of those 74HC32s for example were to fail, either due to an error on my part or for some other reason, I would simply not be able to replace it without desoldering all the wires connected to it first, and soldering them back afterwards. What is the likelihood that a chip would fail? Well, probably not very high, but accidents do happen; it’s easy to drop a screwdriver and short something out. I decided it just wasn’t worth the risk, so I bit the bullet and ordered sockets for all the chips on the Control, ALU and Register boards. I don’t trust the really cheap sockets that use blades so I had to get machine tooled ones that have nice round holes with grips inside. I also decided to get the best quality I could afford so I got ones with gold-plated contacts. By buying Jameco ValuePro parts I managed to cut the cost in half over what Mouser wanted for the real brand-name parts. It sucks that in some cases a single socket can cost over a dollar when I was able to buy nine ICs for the same money, so I wanted to try and cut the cost without sacrificing quality too much.

Toil and trouble

My worst fears have come to pass and for a while I thought the LEO-1 was not going to make it. I had made a test board to act as a fake control board so that I could test the memory board. I had tested it with the Real Time Clock chip and everything was working great. So I carried on building the memory board and connected up the two ZIF sockets. I burned some test data to one of the EEPROMs and put it in one of the sockets, connected up a couple of digits to one half the data bus and used the test board to address the ROM. Lo and behold, the digits showed the correct data coming out of the ROM. It was working as expected. Here’s a picture of the set-up. The digits on the protoboard are showing 3 4 which is the first byte in the ROM.

Memory board displaying data

I switched various addresses and watched the data come out and everything seemed fine, when suddenly the digits went all weird, like a square 8 which is an impossible display. It was pretty clear that the display was oscillating between two values at such a high speed that it looked like all the dots were on at the same time.

And so began several weeks of pure hell trying to figure out what was going on and what caused it. I was able to reliably repeat the problem by setting a certain address and then changing to the next address so that the data changed from 0 0 to  0 1. Often, but not always, the thing would start oscillating. I put my scope on it and found an 8Mhz oscillation on the data bus. I suspected the ROM was faulty but all the ROMs had the same behaviour. I suspected the test board because I had forgotten to buffer the address bus lines. That was a dumb mistake which I decided to fix, so I spent a week adding 74244 buffers to the test board. That didn’t fix the problem. Then I realised I had forgotten to buffer the control signals too, so I used a few spare gates on the board’s 7400 to do that. Didn’t fix it. Weeks had gone by and this random oscillation was still happening. I remembered that you can get this kind of problem if you forget to connect an unused input on a gate, so I checked the schematics and scoured the board for disconnected pins. No luck. Everything was as it should be. One night in early December as I sat there with my head in my hands, I realised that if I couldn’t solve this, there would be no chance of the LEO-1 working at all. My fairly trivial memory board wasn’t even stable at manual switching speeds! I thought about giving up — all that time, effort and money down the drain. By the time I went to bed, I was pretty depressed.

Trying to figure out the oscillation problem

The next day I took one last crack at solving the problem. I had been studying all the data signals on my scope’s logic analyzer and had not had any ideas beyond unconnected pins and faulty chips.

You can see in the picture above that the test board’s ribbon cable was sticking up in the air. It was like that because I was using a short cable for the address bus and the long data bus cable had to be bent in order to be plugged in. Well, for some reason, while the oscillation problem was happening, I just happened to push the cable a bit flatter — and the oscillation stopped. That didn’t seem like a coincidence, so I tried changing the address with the cable flat — no oscillation. I bent the cable again and then next time I switched addresses, the oscillation started again. I could control whether the oscillation would happen or not by bending and straightening the cable. What’s more, the scope showed that the oscillation frequency was changing between about 7 and 8 MHz depending on how the cable was folded.

Then it hit me. Was the ribbon cable suffering from transmission line problems? Those problems that I had been obsessing over right back at the start? Things like reflections and ringing and all that annoying stuff? And did folding the cable do something random like perhaps change the impedance or cause cross-talk? And could that make the bus transceiver chip go into some kind of oscillation? Well, I was not sure and I’m still not sure now, but I have a theory. When reading data out of the ROM, the test-board end of the 12″ cable was not connected to anything. That meant that when the data bus switched from 00 to 01, that 1 bit went down to the other end of the 12″ and reflected back. Ordinarily I would have expected the reflection to die out pretty quickly and just cause a bit of ringing. But something about the folded cable caused it to keep bouncing, perhaps amplified by the bus driver itself. After reading up a bit about line termination, I did an experiment. I added a bunch of 82 ohm resistors at the memory board end of the cable, just before the 74245 transceiver. After that, I couldn’t repeat the problem any more. No amount of switching addresses or folding the cable in any way caused the oscillation and I haven’t seen the problem since. I don’t really understand why it works except that possibly the resistors absorb the reflection and damp it so that it doesn’t turn into an oscillation, but I still don’t understand why I got full permanent oscillation in the first place. I’d love to hear from any experts out there who can explain what the heck was going on.

As if that wasn’t enough trouble, the next thing that went wrong was that I discovered that I had not left nearly enough room between the address bus header and the first bunch of chips. There was no room left to solder any more wires and I still had a couple of busses to connect there. I found I had no option but to move the address bus header to the other side of the board. I had to disconnect all the wires, desolder the header, re-solder it and redo all the work of connecting the 24 address lines to the ZIF sockets. While I was at it, I bit the bullet and removed the majority of the thick annoying wires and replaced them all with magnet wire. I learned a valuable lesson there. You have to leave plenty of room between headers and the chips they connect to so that there’s room to solder multiple busses to the same header pins. From now on, I’m only going to use regular wire for power connections. Everything else will be done with thin magnet wire.

Address Bus connections

So, the LEO-1 lives on after all and right now I’m in the process of wiring up the main RAM and ROM sockets. After that it’s the I/O chips and then board number 1 of 4 is complete.

Memory board as of New Year 2016

Emitting Light

Even though I really had no idea if I was going to be able pull this off, I couldn’t resist thinking about what the completed LEO-1 would look like. I had all kinds of grand visions of switches and flashing lights that all the best CPUs have had over the decades since they were invented and I wanted LEO-1 to look like my favourite, the ICL 2900 series. Well, that wasn’t going to happen, was it? A nice dream, but that’s all.

I had originally considered making the enclosure out of wood and mounting individual LEDs on a hardboard front panel. I also investigated the idea of obtaining some kind of heavy-duty metal enclosure but decided it would be too difficult to drill all the holes. Then I discovered a company called Tap Plastics which lets you order various kinds of plastic sheet cut to the sizes you need. I got a few samples from them and decided that this was the way to go. I should be able to make the whole enclosure out of 1/8″ thick acrylic sheets.

A while after I had begun construction of the memory board, I had a brainwave which invalidated the whole front panel design and sent a ton of prematurely-ordered components into the spare parts bin. Instead of mounting the LEDs on the front panel with clips and rings, why not mount them along the edges of the circuit boards? Then I could make the front panel out of a piece of red transparent plastic and mask off the unwanted areas with black paint on the back of the sheet. The LEDs would shine through from the stack of boards behind. This was such a great idea in so many ways I’m surprised I didn’t think of it earlier. There would be no need for any wires flying from the boards to the LEDs, no need to drill loads of holes, and no need to mount loads of LEDs with clips and rings. The best part of this was the ease with which I would be able to make sure all the LEDs were exactly the same distance apart and in precisely horizontal rows. I was already using circuit board indicators for showing that boards have power and I knew they would be really easy to line up straight.

There was just one problem: I could only fit 32 such indicators across a board. That would allow 128 LEDs for the whole CPU which is exactly how many I was originally thinking of using, but the trouble was that some of them would be on the wrong boards. To display the address and data buses on the memory board I would need 40 right there. 32 just wasn’t going to be enough on any particular board. The solution I found was bi-level LEDs (or ‘double-deckers’ as I like to call them). When you run out of room in a city, you build upwards. With these you can do the same on a circuit board. As soon as I had figured this out I had to figure out how to drive that many LEDs without needing a private power station. Standard LEDs run bright at about 10mA so, say, 200 of them, would consume two amps. What’s more, they need resistors and drivers. It was getting a bit complicated. Then I found these (and evidently ordered a bucket-load of them):

Double-decker LEDs

They are super-bright bi-level LEDs. That means that at the ‘normal’ current of 10mA, they would be too bright to look at. As it turns out, each LED can run brightly from as little as 1mA which reduces the total power consumption by an order of magnitude to about 200mA. The best part of this is that special drivers are not needed; I can just use 74HC240 or 74HC244 bus drivers.

If I stick to my current layout idea, I should end up with front panel lights that look a bit like this:

Which, surprisingly, looks a little tiny bit like this:

Part of an ICL 2970

I’ve reached a milestone

After writing the previous post, I realized that I was at a point where I could actually test one of the memory board devices, the real-time clock. This chip will allow LEO-1 to keep track of the date and time. It supports a battery backup so it can remember the date and time even when the power is turned off. Since all this was already soldered up and I had tested the address decoding, I put the chip in its socket, set up the test probes and set my test DIP switches to the address of the chip. Then I switched the test switch called /OE to off, which is the signal to the addressed unit that it must be output-enabled and put its data on the data bus. I switched on the power and the LEDs on the breadboard started flashing… 0001, 0010, 0011, 0100… a sign that the real-time clock was outputting the seconds onto the data bus as it should. It was working!

The chip I chose is the RTC 72421 which is made by Epson. The data sheet for this is one of the good ones; it’s really well written and explains everything completely. I was able to use my test board to visit each of the chip’s 16 registers and set it to 24-hour mode, and set the date and time. After that I put the battery in and switched off the main power. The chip outputs a pulse called STD.P on pin 1 which works even when it’s on standby. I set it to one-second-per-pulse mode. You can feed it to an LED driver or a piezo speaker to hear the clock ticking. I plan to leave the battery in overnight and check in the morning if it kept the right time. You can tell that I’m nuts about dates and times. That’s one of my ‘special things’.

So, my first proper test was successful. That’s a good sign.

Real-time clock test

I glimpse the fullness of it now

Well, I have started construction of this monster… and a monster it indeed is. I am reminded of the joke in The Hitchhiker’s Guide to the Galaxy about the terrible error in scale which caused an entire battle-fleet to be eaten by a small dog. I have made such an error myself, a huge error in scale on several levels.

First of all, I made a bit of a mistake with the scale of the whole project. This project is colossal. I started to get a sense of this while I was drawing the schematics, but I really had no idea until I noticed it was taking me a couple of minutes to solder a single wire and then decided to estimate how many wires I was going to need. Well, although I haven’t finished numbering the chips on the schematics, I think there’s going to be around 200 chips. Average number of pins per chip… about 18. So that makes about 3600 solder joints just for the chip pins and there are many other things to consider besides those. Working at one joint every 3 minutes for 4 hours a day, that will take about 45 days just for the soldering. Not to mention all the other things that need doing. In reality, I can at least double that, so about 3 months soldering time. Some time next May I think I will laugh at that estimate. I had originally decided to use PCBs since that would be the easiest way to build it. Simply solder the parts onto the board and you’re done. No need for masses and masses of individual wire connections. I did a test for one register and it came to over $100 for a small 5″ board. Even using a cheap Chinese PCB house, the large boards I need would probably cost an absolute fortune which is why I went with prototyping boards. I just couldn’t justify spending that kind of money on the boards alone.

So, I’m now locked into using prototyping boards and the second error I made was how much space this stuff takes up. I had done a number of layout tests and was able to pack a lot of chips into a small space. My boards are 10.6″ square and I can sensibly fit about 80 or 90 chips on a board (or non-sensibly, about 150). But even being sensible about it, I’m finding I’m needing a lot more space between the chips than I have allowed for, due to the thickness of the wires and the fact that a lot of signals are bussed and therefore need 16 wires. The 24 AWG wire I’m using has quite thick insulation which means you can only fit about 12 wires side-by-side in an inch. With my planned distance of only about ½ an inch between the chips, there simply isn’t enough room.

I started construction on the memory board since that is the simplest of the four main boards. This board has some trivial address decoding, a real time clock, I/O ports, DIP switches and some rows of RAM and ROM chips. By starting with this, I figured I could get something testable pretty quickly. In reality, it took 2½ weeks before I was able to test anything at all. To test one board without relying on another board, one needs a method of testing. I decided to build a ‘throw-away’ test board (which turned out quite nice so I won’t be throwing it away). This board is basically a fake control board to fool the memory board into thinking it’s being controlled by a CPU. This board has 6 DIP switches on it (24 for the address bus, 16 for the data bus and 8 for other control signals). It also has a few bus drivers and so on to make sure I can get it off the data bus when it’s telling a memory unit to be on the data bus. It took me a couple of weeks to get the parts and build this board. This was the first inkling I had that I had underestimated the scale of the project and the scale of the required space. Here’s a picture of the finished test board.

Test Board

It looks quite tidy until you turn it over.

Test Board – back

Clearly the wires are taking up far too much space and I confirmed that when I started soldering the memory board itself. There is simply no way with my planned layout that I will be able to fit all the wires in such that I can actually still get to the board to solder it. I’ve already run into problems with wires getting in the way of chip pins and I haven’t even started on anything that uses the whole data bus. Looking around online for how other people do this kind of thing, the solution seems to be to use thinner wire. I have ordered a couple of reels of ‘magnet’ wire, the kind that is used for making coils in motors and power supplies. This wire is very thin (mine will be 28 and 32 AWG) and you can solder through the insulation which burns away. I’m planning to switch to this wire for all the busses and possibly more. I’ll continue to use my current thicker wire for power and ground lines and for other odd connections here and there.

Thick wire problem

In other news, I have finished drawing all the schematics including the ALU. It was a bit tricky, especially the shifter section. It’s pretty easy to make a shifter that shifts by a single bit, but my design calls for the ability to shift by 1 to 8 bits instantly. I used a 1-of-8 selector (mux) to choose the signals based on the shift amount and then had to wrap my head around how to choose the single-bit signals to route to each of the eight inputs on each of the 16 chips. I suddenly realized that it should be possible to make a generalized shifter that shifts one way and then re-use it to shift the other way by rearranging the signals as they go in and out of it. A few hours and a lot of brain twisting later, I had drawn the schematic and found that I had saved myself ten chips. That doesn’t save any money because I had already bought the chips in bulk, but it saves on a couple of hundred solder joints that I won’t have to do. I verified this optimization by knocking it up in Logisim and found that it does indeed work. I went to bed that night feeling ever so clever, like I had invented something. But later I found, as I usually do, that this technique is pretty much standard for shifters and I had simply reinvented the wheel.

ALU – Shifter

Finally, I had a very hard time deciding how to connect the four main boards together. The connections require rather a lot of wires. I had already decided to use ribbon cables because I had found a supplier that would make the cables to my requested size at a very reasonable cost. But the layout had me stumped for weeks, I just couldn’t seem to nail it down. Eventually, with the help of Google Drawings, I made the final plan. As you can see, this is going to need a lot of soldering and a lot of wiring.

Ribbon cables

There’s these two things my mum used to say all the time when I was a kid that seem appropriate now. “Patience is a virtue.” and “Little by little a bird builds his nest.”

I can do this. There is no ‘try’.

Prior planning and preparation…

I haven’t updated this for ages and anyone reading it would be forgiven for thinking I had given up on the LEO-1. Nothing could be further from the truth. I finally got some answers about the worrying stuff I mentioned earlier, partly from some friendly guys on the Electronics Point forum. You can read the thread here.

To cut a long story short, it seems I have been overthinking this issue a little bit too much. I shouldn’t run into any trouble at the speeds my circuit will be running at. Some of the spiky stuff I was worried about even seems to be generated by the act of measuring it, due to reflections inside the scope’s probes. Some of it is also caused by doing tests on a breadboard with long ratty wires all over the place. When I build the real thing on real boards with short wires, it should be fine. I’m going to go on that assumption for now.

During this time I’ve also been figuring out what other parts I’ll be needing and getting them together. You may recall that I was worried that HCT parts were not the best parts to use and I actually did decide to back up on that and switch over to HC parts. It just wasn’t worth the risk of buying hundreds of chips only to find they don’t work the way I expected. So I counted my losses and reordered the original prototyping parts in HC. I now have a bunch of HCT chips that I won’t use but I’ll hold on to them for a rainy day. Once I had figured out what I was going to need, I ordered a ton of chips. There’s a company on eBay that sells unused surplus parts amazingly cheaply. For example, I was able to get about fifty 74HC32s for about $7. The rest of the stuff I’ve been getting from Mouser and some (like the circuit boards) from DigiKey. The EEPROM I’ve chosen is the Greenliant GLS29EE010 which is a 1Mbit device organised as 128 x 8 bits. They only cost $2 each; two of those in parallel and I’ve got a 16-bit ROM for the monitor program. At this point I decided I was going to have to get a reliable EEPROM programmer. I’d seen cheap Chinese device programmers on eBay but I’d also read appalling things about their reliability and usability. It sounded like a false economy that I couldn’t risk. Perhaps when I was a poor teenager but not now. So I bought a Phyton ChipProg 40, mainly because it has the GLS29EE010 on its supported device list, but also because it was available, and I could afford it. I’m happy to report that it works perfectly and I was able to burn some test garbage into my ROM chips. I was also able to use it to have a look at the old PICs that I’d programmed in 2008 on a PIC development board. The code was all still there. An amazing thing is Flash memory.

In other news, I wanted to have some red LED digits on the front panel for debugging and discovered some really nice smart hex display chips (HP 5082 7340) — but they turned out to be obsolete, very expensive and difficult to get. They look so nice that I don’t know why they would be obsolete. I’ve never seen these kind of things on any equipment before and wonder where they were used. Everything has the ubiquitous seven-segment displays, but not these. The last time I saw anything like them was on my first digital watch in 1978, but they were much tinier. Anyway, I found something similar, TIL311, on eBay and acquired four of them. That’s enough to display a 16-bit value. Here’s a couple of pictures:

TIL311 smart display

TIL311 in action

When I haven’t been experimenting with the actual parts, I’ve been drawing the schematics. So far I have drawn two of the four boards and I’ve been finding design flaws while doing it. As soon as I started drawing with real components I noticed I had missed a line driver here and there. I also found a potential race hazard that meant I had to revise the simulation. I hadn’t realised that the memory address decoding will take a finite amount of time to settle and that during that time, it will be possible to select multiple devices onto the data bus. If that happens even for 10 nanoseconds, it won’t be good for the devices or the power consumption, not to mention the stability of the machine. The solution is to wait an extra tick for the decoding to finish and only then actually assert the chip select signal. When I spotted this I found another similar issue and realised my instruction cycle of only 4 states was too simple. I had to increase it to 8 states for memory operations and 5 states for non-memory operations. Very disappointing, but makes sense since I haven’t seen any other designs out there with only 4 states for an instruction. This means that all instructions no longer take the same amount of time to execute which seems a bit weird. Still, I think it will work just fine.

I also figured it would be nice to have a means to switch off the main clock and be able to single step instructions with a button. I spent some time experimenting with ways to achieve that and added it to the schematic for the clock section. During this time I revisited the 555 timer, a familiar friend from my early digital learning days. I still have my old ‘Babani’  book IC 555 Projects by the very drole Mr. E.A. Parr B.Sc, C.Eng, M.I.E.E — that’s a lot of letters 🙂 In the end, I used a 555 for the ‘slow’ clock (a crystal oscillator will be used for the ‘fast’ or normal clock) and didn’t need one for the single step circuit.

Prototyping single step