Zolatron: RTC, SRAM and SD board

After my fun with real-time clock chips (here and here) I figured it was time to add one to the Zolatron 64. But there was a catch.

The previous experiments had involved microcontrollers with built-in SPI capabilities. That was something the Zolatron sadly lacked. Luckily, someone else has already come up with a solution.

The 65SPI project by Daryl Rictor is a very easy way to add an SPI interface to a 6502 homebrew computer – so long as you’re comfortable working with CPLDs. He provides the necessary code to write to an ATF1504. This needs to be addressable within the address space of your computer. I’ve put mine at address $BF00. Starting at that address, I then have three registers for reading and writing:

  • $BF00 – Data Register: data to be read or written
  • $BF01 – Status/Control Register.
  • $BF02 – Device Select Register.

Let’s start with the last one. The CPLD outputs include eight device select lines. You set the state of these lines by writing a byte to the Device Select Register, with each bit determining the state of each line. So, for example:

LDA %01111111
STA $BF02

This will take the device select 7 output low while all the other outputs are high. The device select 7 line is connected to the chip select pin of our DS3234 real-time clock chip (which is active low). It’s that easy selecting a device with 65SPI.

The bits in the Status/Control Register have different functions depending on whether you are reading (when it’s the Status Register) or writing (Control Register). You connect the 65SPI CPLD to the system’s R/W line to determine the mode.

Writing to the Control Register allows you to set things like the SPI mode. Reading from the Status Register tells you things like whether the latest transmit has completed.

A full description of how to use 65SPI would take too long here – and besides, the code and documentation come with clear instructions. Essentially, though, you set up interrupts as desired, write a command code to the Data Register, wait for a certain bit in the Status Register to be set and then read the response (if needed) from the device in the Data Register.

With SPI, you always send and receive at each step. Sometimes you send a code and ignore what comes back. Sometimes you need to read multi-byte data, and you do so by sending a dummy value (typically 0) before retrieving each byte. It’s a very simple protocol.

Addressing

To date, my approach to address decoding on the Zolatron has been to do it on the individual boards, using a 74HC138.

But for this board I wanted to try something different. My initial approach was to have eight 1K spaces in the address map for I/O. But I then decided to increase that.

I’m now using the top 1K slot to create a further eight addressable I/O slots, each of 32 bytes. Having sacrificed that top slot, that now gives me 15 addresses for I/O devices. I don’t need that many, I just wanted to experiment.

The addressing is now done with another ATF1504 CPLD. This is intended for a future project – a single board version of the Zolatron – but I figured this RTC board was a good chance to try it out. If you’re interested in the CPLD code, let me know in the comments.

Not just time

And while we’re at it, with the ability to control up to eight SPI-based devices, it seemed a waste to have just the RTC chip on this board. So I thought, what else can I add?

Battery-backed Serial RAM felt like a good choice. This would be a good place to store configuration data for the Zolatron. As it happens, the DS3234 RTC chip has some RAM on board – a whole 256 bytes of it – but why not have a bit more? My chip of choice is the tiny 23LCV512 offering, you guessed it, 512Kbits (64Kbytes) of storage. If there’s interest, I’ll do a separate post on how to use this.

An SD card was another obvious candidate. So it’s there. I just haven’t got around to writing any code for it yet.

I couldn’t think of anything else, so I’ve added five sets of headers allowing me to experiment with other devices in the future.

The following is the Kicad schematic for the board.

Kicad schematic.

And this is what it actually looks like.

The final board.

In case you’re wondering where the CR2023 battery has gone – it’s on the back.

If you want me to expand further on any of the elements of this board, just ask in the comments.

As usual, the code for all this is in the GitHub repo.

By the way, it has been a long time since my last post. Life does that to you sometimes. I’ve been dealing with some stuff, including major surgery. I hope to post more frequently in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.