Zolatron 64 6502 homebrew computer – new address mapping and decoding

Although it is possibly the slowest computer development programme in history, my Zolatron 64 6502-based homebrew design has made some progress. And this is largely due to the fine folks over at the 6502.org forum.

Specifically, I have made changes to how I’m mapping the 64KB address space and the decoding I’m using to do that.

I’ve been following along with Ben Eater’s 6502 project and actually thought I’d try to get ahead of him. I’d worked out that he would add RAM to the project is order to be able to use sub-routines and I was already on the case finding my own way to do that. Then life intervened, I was left without an office/lab for some months, and Ben posted a video showing how to add and address RAM.

But at least it prompted me to think about how I was planning to tackle this. I posted my plan on 6502.org where it was gently, politely and knowledgeably taken to pieces. It was pointed out that I wasn’t ‘qualifying’ important signals using the clock pulse. The clock, after all, is what tells everything ‘everything’s set up now, do your work’.

Also, my original plan had a 16KB ROM space and a separate 8KB space that I was vaguely thinking could be used for another ROM or maybe some specialised RAM. But I was never very clear what it was there for. It actually makes far more sense to make the 8KB space contiguous with the 32KB RAM. That way, I always have the option (maybe in the ‘plus’ version) of using a 64KB RAM chip and using 40KB of it. And I still have the option of using it for ROM (although 16KB is likely to be more space than I’ll ever need).

New map

So here’s the new memory map [corrected 21/10/2021].

Two parts of it remain the same – the 32KB RAM at $0000-$7FFF and the 16KB ROM at $C000-$FFFF.

The 8KB space and the eight 1KB slots are swapped around.

This doesn’t make any real practical difference other than that the 8KB space is in a more flexible position now.

Signal logic

In my original address decoding plan, the decoding for ROM and RAM was achieved using a couple of 74HC138 three-line to 8-line decoder/demultiplexer chips.

I then amended this using NAND gates and the PHI2 signal to qualify some signals. But with the new address layout, things have to change again.

Let’s think about some specific signals.

The RAM has three signals we need to control. There’s the chip enable (/CE), output enable (/OE) and write enable (/WE), all active low.

The ROM has two signals (ie, not counting write enable which isn’t used when the chip is in action in the computer). There’s a /CE and an /OE.

The /CE lines are what select the chip we want to interact with, and therefore these need to be separate signals. However, the /OE could be the same signal. And this is the way I’m planning to go.

I’m using a single NAND gate. The inputs are the clock signal and the state of the R/W pin on the 6502.

When R/W is high, we’re in read mode. When the clock is high too, the output from the NAND gate goes low and we can connect that signal to any chip we’re addressing that has an /OE signal – RAM, ROM, whatever.

Setting a write enable (/WE) signal for the RAM (and maybe other things like a VIA) is slightly more complicated.

When the 6502 wants to write, it sets R/W low. So, first, we attach this signal to both inputs of a NAND gate, turning it into a simple inverter. The output from this gate is an input to another, with the second input being the clock. That means the /WE signal is low whenever the clock is high and R/W is low.

Address decoding

So far, we’ve only tackled the /OE and /WE signals, although we have at least qualified both with the clock signal. What about addressing the ROM and RAM.

Let’s take RAM first, as it’s the simplest. We tie the A15 address line to the /CE pin. Job done.

A15 will be low whenever we’re addressing the bottom 32KB of the address space, where RAM lives, and high when we’re in the top half. We’re still qualifying the signals to RAM because the relevant /OE or /WE input won’t be taken low until the clock goes high.

For the ROM, we use another NAND gate. We use the A14 and A15 address lines as inputs. When both are high, this gives a base address of $C000, which is what we want. The output of the NAND will be low only when both inputs are high.

The largest number of gates we have to traverse in order to get our signals is two. This is generally a good thing but, to be honest, isn’t critical in this design. The Zolatron is not going to be a high-performance computer. I’m reckoning on a clock speed of 1MHZ, although I may toy with 4MHZ if I’m feeling brave.

You’ll notice that we’ve used four NAND gates and, by good fortune, the handy 74HC00 chip contains exactly that many gates.

This is how it looks on the schematic.

Now for those eight 1KB slots.

1KB decoding

Here we’re back to using the 74HC138, although the inputs are different from the original plan.

The slots now start at $A000. With that address, A13 will be high, A14 low and A15 high. You can see how A15 is connected to G1, which is active high, and A14 is connected to /G2B, which is active low. So that’s simple. A13, however, goes to /G2A which is active low. Because A13 will be high in this case, we first invert it using a NAND gate.

Address lines A10, A11 and A12 are then used to select which of the eight outputs is active (these are active low outputs).

There’s no clock signal here. I’m assuming the outputs will go to the /CE inputs of whatever they’re connected to (eg, a VIA). Clock qualification will happen on other signals, such as the /OE and /WE signals we already have.

The use of another NAND gate means having another chip. However, the Zolatron is going to be a backplane design. I/O devices like VIAs and serial are likely to be on separate boards, so I’ll probably do the decoding there.

Now I just need to try it out on the breadboard.

3 thoughts on “Zolatron 64 6502 homebrew computer – new address mapping and decoding

  1. Alard Eales

    The memory map Address has an error.
    $ACOO – $A9FF. should be $AC00 – $AFFF


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.