Zolatron 64 6502 homebrew computer & Ben Eater’s project – changes to the ROM

In my previous post, I mentioned how, while I’m following along with Ben Eater’s 6502-based homebrew computer project, I’m also making some revisions of my own. One of these is to use my own address decoding scheme.

So far, things are working okay, but that post included a note about how I’m going to have to make some changes to avoid problems in the future.

Da-do-ROM-ROM

One change I  thought would be easy is the selection of the ROM for reading. My decoding setup, using the four NAND gates of a 74HC00 chip, already provides a ROM enable signal.

I hooked the /ROM_ENABLE output from this chip to the /CE (chip enable) pin of the ROM. And I also connected the /READ_EN output to the /OE (output enable) pin of the ROM. (In Ben’s scheme this is always held low. In mine, the selection is qualified by the clock. I haven’t decided yet which is the best way to go.)

I fired up the machine again and … (regular readers will know what to expect here) … it didn’t work.

Doh!

In Ben’s project, the ROM lives at address $8000 because he’s making available all 32KB of the AT28C256 EEPROM. But I’ve decided to go with 16KB of ROM positioned at address $C000.

Moving the code

In the code we’ve been using so far, the ‘origin’ or start of the code is set using:

ORG $8000

(This is the Beebasm version).

Simply changing this to $C000 isn’t going to work (ask me how I know). If you do that, you end up with a 16KB binary file and the minipro command line program I’m using to burn the EEPROM complains about the file being the wrong size.

Now, I could have used the Minipro GUI program on my Windows machine and set an offset of 4000 bytes, like I did when burning ROMs for my BBC Master. But there were two problems with that: first, it would mean using Windows (ugh!); and second, I wanted to keep all operations on my electronics workbench, using the LattePanda Alpha I’ve set up as the workbench machine.

So I came up with a different option.

The initial  origin is still $8000. I put in a label ‘startrom’ at that point and then immediately change the origin again, this time to $C000 and the code itself starts there. At the end of the code – as we’ve been doing all along – we reset ORG again to put the reset vector bytes at location $FFFC and $FFFD. But this time, the vector points to $C000 (ie, the label ‘startcode’ in the code below), instead of $8000.

ORG $8000
.startrom
ORG $C000
.startcode

; … code goes here …

ORG $fffc
equw code    ; write $C000 to $fffc
equw $0000   ; fill last two bytes with null values to fill ROM

.end

SAVE “hw3.bin”, startrom, end

That last line is a Beebasm thing. It writes out the binary file starting and ending with the location indicated by the labels ‘startrom’ and ‘end’. Note: we use startrom and not startcode.

This produces a 32KB file but with the actual code in the top 16KB. And it works.

Now to decode that VIA.

[UPDATE 19/06/2020] In Ben’s design, address lines A0-A14 are connected to the ROM, in order to address all 32KB of its space. As I’ve been following Ben, I have that configuration too. And that’s fine. I only need A0-A13 to address the 16KB of ROM space that I’m using. As that space starts at address $C000, A14 will be high, meaning the ROM will use the top half of its address space.

However, when the time comes to lay out a PCB for the Zolatron 64, I needn’t worry about running a trace from the A14 line. I could just tie the A14 pin on the ROM chip high. This could save some useful space.

Leave a Reply

Your email address will not be published.

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