Well the Zolatron 64 homebrew 6502 computer is getting spiffed up in all sorts of ways. So here’s a quick catch-up before the next big challenge.
The original backplane has been working fine. But I decided to upgrade it anyway. The connectors for the boards were a little further apart than they needed to be. And the new backplane is a four-layer PCB, so the interior ground and power planes should help with signal integrity. I also broke out all the signal lines from the main bus.
In the picture above, you can see the main clock signal (yellow) and the /RD_EN (read enable) line on the backplane. Clearly, there’s a bit of overshoot and ringing, but nothing a 1MHz computer can’t accommodate.
By squeezing the connectors a little closer together I managed to get eight on the backplane board (against the original’s six) without increasing the board size.
Also, I was clever. All the plug-in boards are designed around a common template, which means the four mounting holes in them line up. I carefully spaced the connectors 20mm apart so that I could use my stock of 20mm standoffs to tie the boards together, for greater stability?
Have you spotted the problem? Yup, I’d forgotten to allow for the thickness of the PCBs. Maybe not so clever. Anyway, my new set of 18mm standoffs has just arrived and work perfectly.
The current 6551 ACIA-based serial board was working fine. But I updated it anyway so that it now has LEDs that blink when data’s flowing. (I’ve also added power LEDs to all the boards. Can’t have too many LEDs.)
I intend to continue to use the 6551 ACIA-based board for communicating with the Zolatron via a terminal. However, it has some downsides, though. One is that it’s reliant on an obsolete part. (Well, you can buy the WDC 65C51 new, but if you want a version of the 6551 with the fewest annoying bugs, then you have to go retro.)
The classic 6551 chip came in a variety of versions – seemingly each with its own bug. But regardless of which one you choose, getting a genuine part is tricky. My hit rate in buying from eBay was not good.
And so I’ve turned to the NXP SC28L92. This chip provides two independent UARTs, plus some handy general-purpose I/O, all in one small package. More to the point, it’s a modern chip that’s still in production. I’ve made up the board and am just starting to get to grips with coding for it (so far, I’ve got it transmitting). This will have at least one future blog post to itself, probably more.
This version has more signals broken out and also has the option of connecting via IDE-like HE-10 connectors as an alternative to the DuPont header pins on the back edge.
One is still controlling the LCD display. Another is linked to a small breakout board I designed, which I’ll cover in a minute. And a third has all the connections on the two eight-bit data ports hooked up (via 5V-3V3 level shifters) to the Zolatron’s dedicated Raspberry Pi companion, which I’ve named Imp. I intend to use the IMP as a mass storage for the Zolatron – but that’s a topic for another time.
Main processor board
We’re now up to version 4 of the main processor board – and the damn thing still has a bodge wire on it. -=sigh=-
I spotted the problem even before the new board was delivered. While still using version 3, I developed PEEK and POKE commands for the operating system. These read and write the contents of a specific memory address. But there was a problem. They worked fine for some addresses in RAM, but not others. It dawned on me that something was going wrong with all addresses in the top half of RAM – locations $4000-$7FFF. Huh.
In the ROM/RAM decoding logic, I push the signals from address line A14 and A15 through a NAND gate so that the /ROM_ENABLE signal goes low (active) only when both address lines are high.
At least, I do now. It turned out that, while drawing up this schematic, I’d attached the A14 label to pin 10 and then copied it for pin 9, intended to rename it to A15. Except that I forgot to do the renaming. Doh!
The amazing thing is that the computer has been working fine with this error. I’m not using much of the RAM yet, so this addressing issue wasn’t evident – until I tried addressing the upper half of RAM. At that point, the ROM would be enabled at the same time as the RAM, producing unpredictable effects.
Oh well, I was ready with the bodge wire when the boards turned up and everything’s working fine now.
The other two new boards don’t connect directly to the computer. One is a simple board to hold the LCD display. I’d hacked up something with stripboard for this purpose but desired something neater.
As well as holding the LCD panel and its required trim potentiometer, I also added five LEDs with power-limiting resistors. It’s amazing how much debugging you can do just by turning on or off an LCD at certain parts of your code. Currently, I have these LEDs hooked up to the five spare I/O signals on the VIA board that runs the LCD.
Finally, I’ve added the all-important blinkenlights. This board is actually intended as a general-purpose debugging tool. It has 16 LEDs (two 8-unit bar LEDs), fed via 74HC573 chips to provide buffering and latching (some options for doing the latter are built into the board but I’ve not experimented with them yet).
At the moment, I have this board mounted to the front of the Zolatron. It’s being driven by one of the VIAs. I used it to learn about using the 6522’s timer functions and how to use them with interrupts. (A blog post is coming on that.) The LEDs are currently just counting from 0-65535 in binary. But they’re doing that while the computer happily gets on with other things. Yes folks, that’s right – this machine is multitasking!
And that’s about it for now.
One problem remains. And it’s barrelling down the road in this direction. What, exactly, am I going to do with this machine?
Answers on a postcard, please…