Home » electronics » When is a ground not a ground?

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

LEO-1 working

12 thoughts on “When is a ground not a ground?

  1. Hello John. You have finished all the hardware part… Congrats ! That’s a great job, even if it took much more time than first expected, the result is very nice.

    About ground, you should read some articles about ground plane and meshed ground. In 2 words : as you said, each signal should be as closed as possible to a ground which follows the same path. But more important than that : your ground traces should be meshed wherever possible. The path for ground between 2 component should always be as short as possible (that’s much more important than for signals), and multiple ground paths is a must inside a PCB. If 2 ground traces are close, you should always try to connect them directly even if they are already connected with an existing longer ground trace (close the loop wherever possible). The ideal situation is with a ground plane on one side of the PCB, only removed in small areas where you need something else on the “ground layer”.

    Last question : Do you plan to code a demo software for your Leo-1? Something which displays interesting things on the CRT, interactions with the keyboard, etc…


  2. Thanks for your response and info. At the start, I did try to do a ground plane, but I found it so confusing; I couldn’t follow what was going on because there were so many traces on both sides and I started to get lots of islands on the ground plane that didn’t go anywhere. So I gave up and just did it without a ground plane. Which turned out to be a bit of a mistake 🙂

    I am planning a few things for software. First I’m writing an assembler (on the PC) to make it easier to write software at all. Then I hope to use that to write some software to make the thing actually do something. Maybe even something useful.

    I still have to make an I/O board for the printer and keyboard — and make the keyboard. The digits board which was planned for debugging doesn’t seem so useful now I have a VDU, but I’ll still add it because the digits look so nice. I also plan on making a nice enclosure for it, probably out of acrylic.

    There’s still plenty to do!


  3. Hi John,
    I like the work, well done!
    Me and a friend still use and modify a Z80 based computer that we built back in the 80’s. But we are having problems with the Epsom RTC-72421 sometimes it partly works, but very unreliable. We can’t work out if it’s software or the hardware. Is there a chance we could see the schematic or your code. Or any other that works well!!

    Many thanks.



    • Hi Mel, thanks for your comment. You can see the schematics here: http://leo1cpu.puntett.net/main.htm . I got most of my RTC knowledge from the Magic-1 schematics here: http://www.homebrewcpu.com/Magic1.pdf . I connected ALE differently though (don’t remember why). Just last weekend I wrote some new RTC code for a 68000 system I’m developing. I can post that code and send you a link, but there are no write routines yet. Here it is: https://github.com/croudyj/Test/blob/master/RTC.X68 .

      Two things I’ve had problems with recently are grounding and timing. You might want to check the timing of the chip enable vs the output enable. I had a terrible problem with that on a UART I was experimenting with. I had to delay the output enable a few nanoseconds. But this didn’t affect the RTC. However, it may be useful to read my notes. I’ve posted them here: https://github.com/croudyj/Test . Please let me know if I can be of any further help. I’d be interested to see your Z80 schematics.


      • Hi John,
        Thanks for your quick reply. Yes it would be good to show you a few pics of my setup. not too sure how I do that “here” If you go to my website http://www.melsaunders.co.uk, there’s some old stuff on there (my son is now 40+), but I have only had my recent system up and running for about a year. It’s in a 19″ rack/case system with PCBs(cards) slotting into a backplane etc. We (that’s me and Alan a friend) now have a 128MB CF card acting as 14 hard drives of 8MB each, on an 8 bit system with only 64Kb of ram that’s a lot of space… If it’s easier I could contact you direct to send pictures, etc. But would be good to share!!!
        Best wishes.

        PS. Alan would like to send you his RTC schematic which includes a hardware random number genarator, that does work, as apossed to the usual pseudo software thing!


      • Hi Mel.

        Your web site is very interesting. I see you had a UK101. I had the actual Superboard II it was based on. I’ve never heard of that Interak system. I wish I had; I expect I might have wanted one. I ended up spending lots of money on Atari 400 and 800 equipment. The floppy disk drive alone cost £300 in 1983. I will use the link on your web page to email you as I think posting my email address here will attract spam robots.




  4. Hi John, very impressed by your design which is inspiring me to look at a 24 bit version and trying to shoe horn it to being a basic 68000 level just to see if I can, Ive grabbed logic sim but being a bit panicked about the availability of dip IC’s at the moment actually spent a tone of money just ensuring I have enough IC’s but I might still come undone and have to resort to using some of the Xilinx 9572s which I happened to get 2000 of for 2c Each. I also brought an deceased estate worth of IC’s, caps, resistors, transistors and various other electronic components, a lot of it I will end up reselling and recouping some of the cost but I ended up with 335 kilos of electronics in 36 boxes on a palette. I found some real gems in there two like Intersils PDP 08 on a chip, I think I have four of them from memory and 780 MCM2114P45 static ram chips 1kx4bit, some 6845s there is all sorts. Even a box of alarm clock IC’s.

    If you need anything specific let me know and Ill see if I have some among all the boxes.

    Cheers, good luck with leo and hopefully your excellent work will help me out with my design.


  5. Thanks for your kind words and offer. Back in 2015 when I started LEO-1, I managed to get a huge pile of various 74HC chips from a vendor on eBay. Prices were as low as $6 for 58 chips. It seems those days are gone now as prices are nowhere near as good today. I’m not sure there’s anything to actually worry about though. At least the modern ones like HC and HCT are still being manufactured in DIP. But with that 335 kilos you might already have everything you need. Good luck with your 24-bit design. I found 16 bits difficult enough!



    • Unfortunately not 🙂 most of the IC’s are 74LS and ALS series, there was a lot of TV, Radio and Video related IC’s but not a lot in the CMOS barring multi vibrators, the number of which made me wonder if there was some strange obsessional kink because they had the word ‘vibrator’ in them. Thanks I’m going to have a good go at logic sim first. Purely out of interest I presume that your instructions are actually decoded through the use of the additional roms, I might start this way but with the huge amount of transistors I have I might have a go at hard coding it too.


  6. Hi, John, this is why most pro stuff is made on 4+ layer boards made, with two of the internal layers being mosty VCC and GND. this makes for a good isolation between the top and the bottom layer (and adds some capacitance to the traces, reducing high frequency noise)


    • Thanks for you comment. After this trouble I learned about power/ground planes, but believe it or not, I didn’t know about them or understand what they were for when I did LEO-1. I knew people used them for something important (!) but I felt I wouldn’t be able to route the board correctly if I tried. I was using a fairly primitive PCB editor which didn’t check for errors. Since then, I’ve started using a better editor and made new (simpler) projects with ground planes and they work really well, no problems at all. So yeah — only now at the end do I understand. I learned a very valuable lesson there.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s