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.

Advertisements

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 working

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.

Diagnostics

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

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

Memory board as of New Year 2016

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

Test Board

It looks quite tidy until you turn it over.

Test Board - back

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

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

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

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 smart display

TIL311 in action

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

Prototyping single step

I smell a mistake

Using the PB-503 proto-board I did a bit of testing with the 74HCT parts that I had ordered. Things worked very well. I got a 4-bit counter going and was able to feed 4-bit data into a register and use the bus drivers to get the data out. Doing it in slow-motion (1 to 5 Hz clock) I could see the data was correct on a row of LEDs. Then I did something that I have never done with digital chips before; I connected an output to my oscilloscope, and my jaw hit the ground. This is what I saw:

Output of 74HCT chip at 100KHz

Output of 74HCT chip at 100KHz

Now I didn’t get into university to study electronics like I wanted to, I’m self-taught by experimentation and the Internet, so I didn’t get a very rounded education. I always thought digital signals were… well… digital. Like, square waves. That thing on my screen was not a proper square wave. It had spikey things in it. What troubled me was the max and min voltage readings. Almost seven volts from a 5V power supply? Where was that coming from? And what the hell was that -1.68V negative spike? I had used bypass capacitors like you’re meant to. I never really understood why you needed them but always did it anyway. Wasn’t that meant to prevent this kind of thing? Just for fun I increased the clock to 1MHz and got this:

Output of 74HCT chip at 1MHz

Output of 74HCT chip at 1MHz

This made my blood run cold. How was this possible? If you are an experienced digital electronics engineer, you are laughing at me because you know why this was happening. Well, I didn’t, and I had to find out. Zooming in, I recognised the effect as a kind of ‘ringing’ which I am used to seeing coming out of my analogue synth – but my synth is meant  to do that; it has filters in it designed to muck up your square wave so it sounds cool. I want my digital square waves to be perfect. Why was there analogue stuff in them? I Googled something like “TTL output ringing” and over the next few days I read a lot about things I had never even dreamed of existed. ‘Ringing’, ‘ground bounce’, ‘noise’, ‘crosstalk’, ‘stray capacitance’ and a few other horrors that I forget. I also found out why you need bypass caps, which is nothing to do with this ringing problem. I realised I was in for a ton of random problems if I didn’t learn how to avoid those things. It seems you can’t just plug a load of digital stuff into each other without considering all kinds of weird analogue stuff that can happen to your signals. But I had done that. I had built digital stuff before, clocks and things. I had no scope to show me scary stuff and I always visualised the pulses as perfect square waves. What a poor fool I had been all these years. But wait — my circuits had worked, right? So my circuit would still work; just pretend I’d never looked at the waveform and move on. But I couldn’t. That would be like me pretending my variables were properly initialised in my code. No way, I couldn’t ignore this. I was going to have to find out and try to follow all the established rules for minimising this and any other horrors that were waiting for me. After I calmed down a bit it started to seem rather straightforward. Keep wires as short as possible, don’t run signal wires too close to each other, separate ribbon cable signals with interleaved ground signals, and so on. But this test was on a single output. It wasn’t crosstalk, it was most likely an impedance mismatch from what I could understand. Apparently fixable with resistors. But you don’t see tons of resistors in digital circuits preventing this kind of thing so that couldn’t be it either.

After a while I found that this particular ringing issue is probably nothing much to worry about. I’ve read other people’s CPU blogs and no one seems to care or mention this stuff. I’m probably over-analysing it as I have a tendency to do. For one thing, the evil-looking negative spike is dealt with by internal diodes in the chip inputs. I’m still not sure how the over-supply spike is handled by the chip, if at all. Still, maybe I’ll just have to ignore it and follow best practises.

My reading led me to find out a lot more things that I wouldn’t have known. Without some understanding of these issues I might have ended up with a CPU that kind of worked a bit, sometimes, at slow clock speeds or something equally useless. At least now I have a fighting chance of making it work properly. But all the reading led me to a new issue, the issue of choosing HCT chips over HC. I read a paper by Texas Instruments entitled SN54/74HCT CMOS Logic Family Applications and Restrictions and found, at the end, the following: “…employing HCT instead of HC devices in pure CMOS systems cannot be recommended. […] Due to the lower noise margin, there is an increased risk of interference caused by crosstalk, especially when the lines on the printed circuit board exceed a certain length. Moreover, the reduced switching threshold no longer ensures faultless operation of advanced bus systems used in microprocessor applications today.” I started to think I had made a mistake choosing HCT parts, as I had suspected earlier. My decision was stupid. I should have just found out if I could get all the parts in HC and then built the whole thing with HC instead of wondering if I would be able to, or if I would need to fall back on LS parts. I’m kind of troubled by how I let this happen. It’s not like me to plan something so badly. I had become a bit excited and got carried away. Not the sign of a good engineer. I had to stop and think about this all some more. I went to bed and slept on it.

Design decisions: Electronics

By the time I had finished the first draft of the simulation, I really felt like it would be possible to implement LEO-1 with real electronics. I had tested the simulator by spending a few days writing an assembler so that it would be easier to test by copying and pasting the assembler output into Logisim instead of having to work it out on paper and type the 16-bit instruction codes in. Now I had a simple assembler which I could use to program the real thing. I had to try and build it for real.

As I’ve mentioned before, I’m not totally new to digital electronics. I designed and built a digital clock in 1978 or so and I designed and built a decoder and display for the (now defunct) ‘Maplin Rugby Clock receiver’. I felt confident that I could get back into this fairly easily. I already had a soldering iron, multimeter, wire, basic tools and a cabinet full of spare electronic parts that I’d collected over the years. How hard could it be? I decided to find out by seeing if I could come up with a design for a single one of the 16-bit registers LEO-1 needs.

I had already decided that the 74 series chips was the way to go, just because I’ve always liked them (after I got over hating them), I’ve never really felt comfortable with the 4000 series CMOS parts, and many mini and mainframe computers like the ones I worked with in the 80s were made out of them. I read through this page to refamiliarise myself with some of the parts I was going to need and started to realise that in the last 20 years, things have changed a bit. Originally, in the 70s, I used plain old 74xx parts. These were the real TTLs. They got warm during use and were rather robust. Some were even made of ceramic instead of plastic.

Pictures I took of the clock project I did in 1993 show that I used 74HCxx parts. I’m not sure that at the time I knew that these parts are actually implemented with CMOS and are not really TTL compatible. The project worked because I used all the same kind (HC) and 5 volts (the standard TTL supply)  works for CMOS as well. What’s changed for the better is that there now also exist 74HCTxx parts which are implemented as CMOS but have a completely TTL-compatible interface. By using these, you get compatibility with old TTL parts like 74LSxx but they use less power. I needed to choose between HC and HCT. My decision was influenced by something (that I should have, but didn’t) expect: many of the 74 series are now obsolete and either very difficult or impossible to get. If I went with HC parts (which are ‘preferred’ for new designs), I would be locked into them and if a part was not available, I would be royally screwed. If however, I went with HCT parts, I would have the option of falling back on LS for difficult-to-get items. I decided to go with HCT for this reason. The only downside I could see was HCT’s ‘lower immunity to noise’. I’m not sure if that will affect what I’m doing; I hope not. In retrospect I think I may have made a mistake as I probably won’t need to interface to any LS chips and HC would have been a better choice, but I’m not going back now.

Anyway, after choosing 74HCT chips I ordered a few parts for prototyping the register board. While I was at it I looked into the kind of memory (RAM, ROM) I might want to try. I found a static RAM chip which provides 512k x 8 bits and figured I could use two of those to make a 16-bit memory. As for ROM, I’d like to try EEPROM (i.e., Flash memory in a chip) but I’m still doing research on that because of the need for a programming device to get the code into the chip. There are two options for this: build my own, or buy one. I think I’m going to have to go for option 2 on that. Still thinking about it though. Once I know which device I want to use, I can try and find an affordable programmer that supports it.

So, what do I need for a single register? It turns out that a pair of 74273 octal registers will do the trick. They latch the data in on a positive-going clock edge which is what my design needs, and they have two-state outputs. LEO-1 has four internal register buses which I called RIN, ABUS, BBUS and CBUS. The RIN bus is the register input bus and it will be constantly connected to all register inputs. The other three are the register output buses. ABUS and BBUS go to the inputs of the ALU and CBUS is used for writing a register to memory. This means that the output of every register has to be connected to three bus drivers which will enable any register value to be output to any of the A, B or C buses. The instruction decoder will ensure that only one register at a time can get onto a bus by selecting only one of the eight registers for each case of A, B and C. I chose the 74244 octal bus driver chip for this purpose. The 273 and 244 being octal (8-bit) chips means I have to ‘bit-slice’ to get 16-bits from pairs of 8-bit chips. So, one half (low 8 bits) of a register will need a 74273 register and three 74244 bus drivers, and the other half (high 8 bits) will need the same. This gives a total of eight chips per register for a total of 64 chips across all eight registers. While I was designing LEO-1 in the simulator, I didn’t give this kind of thing much thought. I’m now glad I didn’t try to design a 32-bit machine! Here’s a picture of the chips attached to a bit of static-proof foam:

Register chips

Register chips