I completed all the wiring for the Nibbler and of course, it doesn’t work. I was expecting that. In fact, if it worked correctly, I would have suspected something was up. Here’s what the front and wired side look like so far:
![](https://i0.wp.com/blog.frankdecaire.com/wp-content/uploads/2024/05/IMG_9627.jpg?resize=877.5%2C566&ssl=1)
![](https://i0.wp.com/blog.frankdecaire.com/wp-content/uploads/2024/05/IMG_9628.jpg?resize=877.5%2C717&ssl=1)
![](https://i0.wp.com/blog.frankdecaire.com/wp-content/uploads/2024/05/IMG_9629.jpg?resize=877.5%2C792&ssl=1)
The first thing I did was beep the wires, or rather, check continuity. Then, I verified the substitute chips that I used. I had to make sure I was using the right pin numbers. I managed to find a few errors in my initial wiring, and then I discovered that I had the wrong pin numbers for a few of the connections I needed in my spreadsheet. After several rounds of checking this, then plugging in the chips and verifying it still didn’t work, I finally broke out the oscilloscope and discovered that there were at least two devices that were accessing the data bus. That reared its head as a half-height square wave that merged with the full-height wave. Two circuits were driving the bus at the same time. I also noticed that the input chip (74125) was getting hot. What I discovered was that some of my signals from MICROROM0 were wired wrong, causing two chips to access the bus at the same time. Doh!
There is also a more complicated signal requirement for the RAM that I used. The CY7C199 has a separate output enable that must be held low, but only for read operations. I had to come up with some extra logic to make sure that is held low during the right time. I’ll share that circuit when verify that it is working correctly.
I loaded the RAM test program into another EEPROM and plugged that in for analysis. When I hooked up the logic analyzer (see the right picture above), I can see that the /OEIN is pulsing low at regular intervals. The only instruction that causes that output to go low is the IN instruction (and the RAM test doesn’t use the IN instruction):
![](https://i0.wp.com/blog.frankdecaire.com/wp-content/uploads/2024/05/image.png?resize=877.5%2C366&ssl=1)
Which leads me to believe that there is something shorted or wired wrong. Here’s the logic output:
![](https://i0.wp.com/blog.frankdecaire.com/wp-content/uploads/2024/05/image-1.png?resize=877.5%2C597&ssl=1)
/OEIN is the third one down (green). On the oscilloscope, it looks a bit messy. It’s a regular pulse, but it could be a short someplace. Maybe one of my wraps has a tail that is touching another pin. I’ll have to dig.
![](https://i0.wp.com/blog.frankdecaire.com/wp-content/uploads/2024/05/image-2.png?resize=877.5%2C392&ssl=1)
My next task is to break this down even smaller. I’m going to write a program that does nothing but access the output and then jump back, forming a continuous loop. Then, I can put the logic analyzer on the signals again and see if only the ones I expect show up as active.
Not to worry. I’m nowhere near the end of ideas of how to troubleshoot this. If I need to, I can wire up a 555 timer and set up a single-step operation. Then, I can step one clock cycle at a time and measure everything with a voltmeter, and record what I have. But for now, I think I have enough tools to figure this out.
This project is probably going to take me to the end of the year (primarily because I only have an hour here and there to spend on it). I have plans for this tiny computer. I want to write a few programs to see what I can do with such a tiny machine. Of course, I’ll publish any programs I write right here on this blog, so check back later to see what happens.
Note
I know this article was written back in May, but I haven’t provided an update. Summer months are busy, but I still have the project, and I’ll be completing it this fall. I plan to be back to my troubleshooting in October.