It’s always a good day when you get a package from the fab. There’s something simultaneously exciting and daunting about unwrapping a shiny new batch of PCBs. On the one hand, there are the possibilities promised by the new device. On the other, you’re wondering whether you made some kind of mistake in the design and if the thing will work.
Short answer: no.
My latest batch of boards from JLCPCB (not sponsored or affiliated – I’ve simply found they do a good job) included four boards. But there was one in particular that I’d been eagerly anticipating.
Followers of the Zolatron 64 project will know that I’m using a Raspberry Pi Zero 2W as both a terminal machine for the homebrew computer and as a form of persistent storage. To date, I’d simply plonked the RPi Zero next to the Zolatron and ran wires from the Pi’s GPIO pins to the I/O pins of one of my standard 65C22 VIA interface boards.
It’s been working a treat. But it is a bit of a mess. And then I thought, the Pi Zero is small, why not create a board of its own, incorporating both the Pi and the 65C22, and plug it straight on to the backplane?
That’s what I did. Simple enough, it seemed.
Nothing, nada, rien
Of course, it didn’t work. I mean, you expect a few minor hiccups, but this thing was, as they say in emergency medicine, unresponsive.
Neither of the two interfaces was producing anything. There is the parallel interface between the Pi and the 65C22. And I’d also broken out the Raspberry Pi’s serial pins, with two resistors forming a voltage divider to bring the Zolatron’s 5V serial signals down to 3.3V for the Pi’s RX pin.
I was especially baffled by the serial interface. It’s so simple. I’ve implented serial connections on all kinds of projects without trouble. What gives?
This was nearly the last of the problems I solved, but I’ll deal with it now because it’s so basic. Essentially, I’d forgotten a lesson I’d already learned (or so I thought).
I managed to confirm that serial communications were working okay by connecting directly to the Pi’s serial pins and connecting to the Zolatron via the voltage shifter board that I’d been using to date.
That meant that suspicion fell on the path between the Pi’s pins and the connectors on the edge of the board. The Pi’s TX pin was just connected directly, so that couldn’t be the issue. The RX pin went via that resistor divider I mentioned, where I’d used 2.2KΩ and 3.3KΩ resistors. A quick squint with the logic analyser told me that this line was always low. And that’s odd, because, when idle, it should be high. Something was pulling down… oh-oh! I’ve been here before.
This resistor divider – specifically, the 3.3KΩ resistor connected to ground – is acting as a fairly strong pull-down, and the signals coming from the Zolatron aren’t strong enough to override it. I changed the values to 22KΩ and 33KΩ and everything started working as planned. It seems some lessons need to be learned more than once.
Wrong signals
The problem with the parallel interface was more perplexing. And it took a while for the first penny to drop.
A good first step in situations like this is to go back to your schematic for the PCB. And that’s where the problem lay. I’d actually laid out the PCB in a slightly different manner to the prototype set-up. Two signals were going to different GPIO pins on the Pi.
I pounced on this, changing pin assignments in the code (actually the Go code on the Pi) with almost breathless antipication. This is it! I gasped. Now it’s going to work!
Nope.
There’s no more crestfallen feeling than when you think you’ve solved a problem only to find you haven’t progressed one iota.
Chip challenged
I’ve had difficulties with the 65C22 in the past – to do with differences with the S and N versions. I was certain this couldn’t be the problem here, but by this time I was grasping at straws.
I grabbed my trusty illuminated loupe and peered hard at the 65C22 chip. Sure enough, I could make out the ‘S’ that I both wanted and expected.
Hmm, but what’s that? Something odd with the rest of the text. It appears to say 65C02, not 65C22. Doh!
Yes folks, I’d inserted a 65C02 CPU instead of the 65C22 VIA. Both are 40-pin DIP chips with identically tiny writing. I’d retrieved the chip from a piece of anti-static foam in the Zolatron project box. The foam held three chips – one that I knew to be a 65C22N, one that was legibly marked (without needing a loupe) as an R6522 (very vintage). I simply assumed that the other – the chip I used – was also some variant of 6522. I’d squinted enough to make out an ‘S’ and that was good enough for me.
Finally, I swapped chips, powered on the machine and everything worked!
Well, not quite.
A bit missing
Yes, the machine booted fine and I could issue commands that involved the Raspberry Pi. There are only two of these – LS to get a listing of files on the Pi and LOAD <filename> to load a file into the Zolatron’s memory.
Neither worked, although the LS command was tantalisingly close. It would print the file listing as expected, but then would add lots of random, garbled text at the end. It seemed as though one side or other of the system was overrunning. Either the Pi was pushing data to the Zolatron or, more likely, the Zolatron was continuing to read data before getting the signal to stop.
I fired up the logic analyser again and pored over the data to see if there was some kind of timing issue. I couldn’t see one, but tried experimenting with changing the sequence of signals, all to no avail.
On a hunch, I took a look at memory contents just after issuing the LS command. The ZolaDOS commands use page 6 ($0600-$06FF) as workspace. The text with the filenames should be there starting at location $0600.
I used the command LP 06. This shows a page’s worth (256 bytes) of memory. (And I love the fact that I’m using a command I wrote to debug a problem.)
Sure enough I could see the ASCII codes for the filenames, each one followed by a $00. However, after that final zero there should have been an $FF, signalling the end of the list. Instead, what I saw was $DF. And that happened every time.
The memory contents showing the data loaded by the LS command (fixed in this case).
A quick spin on my trusty calculator confirmed something that I’d started to suspect. The difference between $DF and $FF is the setting of just one bit – bit 5. All other things being equal, if it’s 0 you get $DF, if it’s a 1 you get $FF. Could it be as simple as a dodgy connection on one bit?
That seemed too simple. After all, all the other text was coming through fine.
But then some memory in the back on my brain kicked into life. I took a look at an ASCII chart and confirmed that, yes, bit 5 is always 0 for uppercase letters, which is all I was dealing with. In fact, the difference between upper- and lowercase letters is just the setting of bit 5.
The data on this interface is sent back and forth via a 74LVC4245 level shifter chip. This is a surface-mount component. Time to squint hard again.
And yes! One of the chip’s little legs had no solder on it. That was easily fixed and finally, finally was it working?
Yes.
Phew!
The good news is that the board design (revision 1 to boot) is fine – except for the markings on the silkscreen showing 2K2 and 3K3 resistors. It’s not worth respinning the board for such a minor aesthetic issue.
The bad news is that I obviously have a problem with learning lessons.