When diagnosing a problem, remember to check the basics.
I was working with the prototype of the latest (take-home breadboardable) version of the DrACo/Z80 computer, making sure it still worked, when it seemed to develop a problem right at the end of programming before I was going to switch it to Run mode.
to be as breadboardable as possible on a couple weeks’ notice.
I had gone through and cleared out the first few memory addresses, since in this configuration, it’s easier to load a single number into the data latch and then program those locations all at once so you don’t have to reload the data. So addresses 00, 01, and 02 were all set containing 0x00.
I then switched back to address 00, moved the switches to 11000011 to represent the C3 (jump) opcode, and hit Latch Data to latch it in to memory. Nothing happened, which was as expected. I then hit Write to load it into memory, and the display stayed blank. That was not according to plan.
I pulled the schematic out and got about two or three logic gates into debugging it when I noticed that all the logic was at zero. After a brief search, I found a plausible explanation.
If all the logic signals are low, that’s usually a power problem — and it seemed to be, in this case. We may be building a 40-year-old computer, but the chips we’re using are modern CMOS variants — faster, cheaper, and often much more power-efficient. These are not the power-hungry 7400 series TTL chips of yesteryear. They do the same thing, but draw far less current.
In short, a good chunk of the power budget for this computer goes to run the twenty or so LEDs. The chips themselves draw very little current, in comparison. Maybe a few tens of milliamps or so, compared to 10-20mA per LED, depending on a bunch of things.
When switching back to address 00 which had data of 0x00 in it, all of the LEDs were out at the same time while I fiddled with the switches to enter the C3 opcode. This left the whole circuit drawing next to no power for maybe five or ten seconds (and little power for the previous short while, too.) The USB battery running the show had apparently sensed what it thought was no appreciable load, decided that nothing else was connected that needed charging, and gone to sleep, cutting off power to the whole computer.
Or, maybe it hadn’t…?
After powering it back up, re-entering (all three bytes of) the test program, and setting it back to address zero with all LEDs off, the battery isn’t powering off. Maybe the power wire jiggled the other time — but it was connected when I looked, and an interruption in power usually means the memory contents are randomized. It’s noticeable.
Well, we are kind of pushing how complex breadboard projects should get before switching to circuit boards. Sometimes they’re a little wonky.
Note to self: Include a power LED in the next version just in case — as well as an explanation that it may actually be essential if running from a battery.
