[WORKING] Simple 6502 SBC from scratch (Deck65)

[and3rson]

UPDATES:

• Link to my first successful test run: viewtopic.php?f=12&t=7501&start=75#p98622
• Link to important Ф2 fix with successful LCD operation: viewtopic.php?f=12&t=7501&start=90#p98645

*** Original message ***

Hi,

Being inspired by C64 and living in the age of cheap (well, mostly) hardware, I've finally decided to build a simple SBC!

I'm currently going through 6502 Primer to get some more details on implementation, but I've started planning a prototype to try and see 6502 in some simple action.

<s>My SBC will have two 32x8 SRAMs, 1 8KB ROM (or a larger EEPROM), and 74x138 address decoder. I'll get into I/O later. Decoder seems like overkill now, but I'm planning to have more stuff in the lower memory segment, including I/O and possibly SID (I'm lucky to have a whole bunch of good 6581s & 8580s).</s> EDIT: Nope - I'll have 128KB SRAM, 8KB ROM, 8-channel I/O address decoder via 74x138, 6522 VIA, and a 2004 LCD. I want to also include SID, EEPROM, & 6551 ACIA in my future build.

I'd like to know if I there are any important flaws in my design. In addition to that, I have few specific questions:
- Is there any major difference between CE & OE in 32x8 SRAMs? Can I connect Ф2 to either of them? (To prevent 6502 from accidentally writing to SRAM during low clock cycle as mentioned in the Primer)
- Is it OK to join outputs of 75x138? It makes address mapping so easy (since all my chips are aligned to 8K). It could all probably be achieved with a single NAND, but I've decided to keep things simple for now.
- Is it OK to keep address decoder enabled all the time?
- Am I missing any other important glue logic? My current design feels pretty simple, but... It feels too simple. I feel like I'm missing something very important. (EDIT: Yeah, I was missing a LOT of stuff.)

Thanks in advance!

EDIT: I'll keep my first post updated with the most recent version of the schematic. I'll also keep my very first version there to remind myself how dumb I was in the beginning.

All my stuff & sources are available here: https://github.com/and3rson/65ad02

Memory Map

Code: Select all

+-------+-----+------------------------+
| RANGE | TYP | Notes                  |
+-------+-----+------------------------+
| $0000 | RAM | A14 || A15             |
| $BFFF | 48k |                        |
+-------+-----+------------------------+
| $C000 | n/a | Reserved for future    |
| $CFFF | 4k  |                        |
+-------+-----+------------------------+
| $D000 | I/O | !RAM && !ROM && A12    |
|  ...  | 4k  | $D000-$D0FF - LCD      |
|  ...  |     | $D100-$D1FF - 6522 VIA |
|  ...  |     | $D200-$D2FF - EEPROM?  |
|  ...  |     | $D300-$D3FF - EEPROM?  |
| $DFFF |     | $D400-$D4FF - SID?     |
+-------+-----+------------------------+
| $E000 | ROM | !RAM && A13            |
| $FFFF | 8k  |                        |
+-------+-----+------------------------+

Latest version (V0.11):

V0.10:

V0.9:

V0.7:

V0.6:

V0.5:

V0.4:

V0.3:

V0.2:

V0.1:

My (terrible) first version

[GARTHWILSON]

Welcome.

You'll need a reset circuit.  It's not optional.  The 6502 primer has a chapter on it.

You'll also need some sort of clock-generation circuit. The 6502 primer covers that, too.

A major difference between CS\ and OE\ on the SRAMs is the response time.  CS\ gets it going but takes a while, while the OE\ is faster to enable the outputs once the preliminary stuff is set up.  (That may or may not matter, depending on how fast you want to run the system, and how fast your SRAM is.)  OE\ of course is for reading, not writing.

Note that the CS\ ("chip-select-not") on the RAM has the overbar over it, meaning it's negative logic.  (Unfortunately phpBB forum software doesn't provide any way to put it that way in a post.  WDC, in their early years, used software to make their data sheets which did not offer any way to do the overbar, so they added a "B" on the end of negative-logic signals, like NMIB for "non-maskable interrupt bar.")  The RAM will be active when this input is low, which is the opposite of how you have it.

If you don't use the NMI and IRQ or any other (negative-logic) inputs, you'll need to tie them high.  It's good to do it through a resistor so that if you later want to use them, you don't have to cut a trace on your board.  RDY will need to be high also, except if slow memory pulls it low to mean it's not ready to move on, that it needs more time to dish up the information.  Don't leave it floating.  This stuff is all in the 6502 primer.

You cannot join '138 outputs.  They'll fight each other.  In some cases, you can keep the '138 enabled all the time; but you'll want to make sure two things cannot be enabled at the same time, for example a VIA and a RAM trying to put data on the bus at the same time, as they'll fight each other.

If you want that much RAM (which you'll never get anywhere close to filling with program material, only data, if you ever have that much), I would go for a single 128KB SRAM instead of two 32KB ones.  It will reduce the parts count, make decoding easier, and you can just tie one of the address lines permanently high or low to only use 64KB of it.  You'll probably save money, too.

Note that on the WDC W65C02S, pin 1 is not ground, but a vector-pull output.  It's good to make your board with a jumper so you have the option.  Also, WDC's pin 36 is a bus-enable input (positive logic this time), and must be high for the processor's outputs to work, and pin 5 is a memory-lock output.

Obviously you'll have to have some kind of I/O, or the computer won't be any good for anything at all.  Plan accordingly.

I would encourage posting your schematics in black and white.  We have a couple of forum members who are colorblind, and for one of them, the light-green lines may be just about invisible, and the green against yellow is problematic too.  In B&W, everyone can read it.

[richardc64]

GARTHWILSON wrote:

Note that the CS\ ("chip-select-not") on the RAM has the overbar over it, meaning it's negative logic.  (Unfortunately phpBB forum software doesn't provide any way to put it that way in a post.  WDC, in their early years, used software to make their data sheets which did not offer any way to do the overbar, so they added a "B" on the end of negative-logic signals, like NMIB for "non-maskable interrupt bar.")

No one thought of simply using "/"? 

Quote:

...and pin 5 is a memory-lock output.

Not to thread-jack, but I've read WDC's description over and over and don't get what its intended purpose is, how it would be used, or of what use -- if any -- it would be in a one processor system.

[GARTHWILSON]

richardc64 wrote:

No one thought of simply using "/"?

...possibly in the absence of a backslash character too, to put at the end?  The "/" is sometimes put in front of the signal name, like /CS.  Maybe it really rubbed Bill Mensch wrong to put the "not" in front.  In my 1982 class in 6502, we were taught to put the "not" at the end, like "chip-select-not," and then my first exposure to CAD was OrCAD in the late 1980's, and OrCAD used the trailing backslash...But then, what can you expect from a company whose product had more bugs than an ant hill, and which to this day still doesn't know how to draw a resistor correctly.

Quote:

Quote:

...and pin 5 is a memory-lock output.

Not to thread-jack, but I've read WDC's description over and over and don't get what its intended purpose is, how it would be used, or of what use—if any—it would be in a one-processor system.

Maybe DMA?  (I suppose that in a way, the DMA controller kind of qualifies as another processor though.)

...now back to your regularly scheduled programming...

[BigEd]

and3rson wrote:

Being inspired by C64 and living in the age of cheap (well, mostly) hardware, I've finally decided to build a simple SBC!

Welcome!

GARTHWILSON wrote:

You'll need a reset circuit. It's not optional.

I don't think everyone is in agreement on that: it's a matter of opinion and judgement, and of course it's a function of how the SBC is supposed to be used. We've discussed this many times, and I'm surprised if you've forgotten. Edit: oops, this is an overreaction on my part - see my correction downthread.

[GARTHWILSON]

BigEd wrote:

GARTHWILSON wrote:

You'll need a reset circuit. It's not optional.

I don't think everyone is in agreement on that: it's a matter of opinion and judgement, and of course it's a function of how the SBC is supposed to be used. We've discussed this many times, and I'm surprised if you've forgotten.

You cannot leave the RST\ pin open!

[BigDumbDinosaur]

and3rson wrote:

Hi,

Welcome to 6502.org!

Quote:

...I’ve finally decided to build a simple SBC!

Before I go further, may I request you post your schematics in monochrome?

Quote:

My SBC will have two 32x8 SRAMs, 1 8KB ROM (or a larger EEPROM), and 74x138 address decoder. I’ll get into I/O later. Decoder seems like overkill now, but I’m planning to have more stuff in the lower memory segment, including I/O and possibly SID (I’m lucky to have a whole bunch of good 6581s & 8580s).

Just to reiterate what Garth said, a single 128K SRAM will be cheaper than the two 32K parts, will require less board space and will simplify your glue logic. You can tie A16 on the SRAM to ground or VCC and wire the remaining address lines to the rest of your circuit, which will make the SRAM look like 64K. Glue logic would then select the SRAM when the address on A0-A15 is in the range where RAM should appear.

You didn’t mention whether you are going to use an NMOS 6502 or a 65C02. The latter is highly recommended for a number of reasons, not the least of which is the 65C02 doesn’t have the hardware errata of the 6502. Also, the 65C02 has strong output drive that swings rail-to-rail, whereas the 6502 has weak fanout that works at TTL levels. The output characteristic difference can give you grief.

Both versions of the SID are also TTL devices, so that is something else to consider. Of the two, the 8580 will be the much better choice. The 6581 needs a 12 volt supply, runs hot, is easily damaged by ESD and doesn’t follow the written specs for the device as well as the 8580. The 8580 can get by with a 9 volt supply, has less THD in its output and is less ESD-sensitive.

Quote:

- Is there any major difference between CE & OE in 32x8 SRAMs? Can I connect Ф2 to either of them? (To prevent 6502 from accidentally writing to SRAM during low clock cycle as mentioned in the Primer)

Garth answered this, but I’ll add a bit more to it.

Most SRAMs are designed to interface to Intel x86-style buses, which means they have three control inputs of interest (aside from the address and data pins): /CS (chip select), /OE (output enable) and /WE (write enable). /CS is controlled by your address bus decoding logic and is driven low (asserted) when the device is selected for access. When asserted, /CS, also referred to as /CE (chip enable), brings the SRAM out of hibernation and causes it to set up an internal data path to the cell that is to be accessed.

As the SRAM’s internal setup process is relatively slow, I always recommend /CS be asserted as soon as the MPU drives a valid address onto A0-A15. The 65C02 does this during Ø2 low, which means /CS should not be qualified by the clock (Ø2), since you will be unnecessarily giving up some timing margin.

Once /CS has been asserted, /OE would be asserted during a read cycle. The SRAM will drive the data bus one setup time after /OE goes low—that setup time is typically shorter than the /CS setup time. The MPU will sample the data bus near the end of the Ø2 high phase and latch the data at the fall of the clock. Although not essential in a 65C02 system, good practice will not assert /OE until Ø2 goes high, a hedge against data bus contention in some applications.

If a write cycle, /WE must be asserted, but only after the rise of Ø2. Qualifying /WE with the clock prevents data corruption due the buses momentarily being unstable shortly after the fall of Ø2. If writing is enabled while Ø2 is low, there’s the chance that two different cells in the SRAM might be “touched” as the address bus settles. Needless to say, debugging something of that nature would difficult.

Below is a circuit that fully qualifies reads and writes, and is suitable for use with hardware that has an Intel or Zilog interface, e.g., a typical SRAM or other non-65xx output device.

The circuit uses a 74AC00, but acceptable substitutes are 74AHC00 or 74HC00. /RD is equivalent to /OE and /WD is equivalent to /WE.

Quote:

- Is it OK to join outputs of 75x138? It makes address mapping so easy (since all my chips are aligned to 8K). It could all probably be achieved with a single NAND, but I’ve decided to keep things simple for now.

As Garth said, no. When the 74x138 is active, seven of its outputs will be high and one will be low. Wire them together and sooner or later, contention will occur that will most likely damage the device.

Quote:

- Is it OK to keep address decoder enabled all the time?

Probably not. As a fairly general rule, the decoder should be enabled only when the address bus is addressing a device controlled by the decoder. If the decoder is constantly enabled, the door is open to a contention issue, since one output of the decoder will always be driven low.

I should add that before you start picking and choosing parts, you should work out a memory map for your machine. The memory map will dictate how your glue logic should work, which will then help you determine which gates are needed. Be realistic about your first build. The more complicated you make it, the greater the likelihood of it being DOA.

Quote:

- Am I missing any other important glue logic? My current design feels pretty simple, but... It feels too simple. I feel like I’m missing something very important.

Well, Garth mentioned the need for a Ø2 generator—a can oscillator is a good choice for that—and a reset circuit. Something has to be driving RESB high if the MPU is to run. Also, you’ll need some means of cycling RESB at power-on to actually get the MPU running.

As for whether it’s “too simple,” I’m afraid one man’s simplicity is another man’s complexity.

Study the below and see if you can get some ideas from it.

Simple 65C02 Glue Logic

[BigDumbDinosaur]

BigEd wrote:

GARTHWILSON wrote:

You'll need a reset circuit. It's not optional.

I don't think everyone is in agreement on that: it's a matter of opinion and judgement, and of course it's a function of how the SBC is supposed to be used. We've discussed this many times, and I'm surprised if you've forgotten.

As Garth said, a reset circuit is not optional. Something has to drive RESB high in order for the MPU to run. Something has to be able to toggle RESB at power-on in order to get the MPU running.

[and3rson]

Wow, thank you for so many responses, I really appreciate this!

GARTHWILSON wrote:

Welcome.

You'll need a reset circuit.  It's not optional.  The 6502 primer has a chapter on it.
You'll also need some sort of clock-generation circuit. The 6502 primer covers that, too.

Sure - I've omitted the plumbing part for the sake of brevity. This is my first time using KiCad and I'm still getting used to it.

GARTHWILSON wrote:

The RAM will be active when this input is low, which is the opposite of how you have it.

Not sure if I'm following: all 74x138 outputs & SRAM /CE & /OE are active-low, aren't they? (So the decoder will only ever select one RAM or ROM at a time)

GARTHWILSON wrote:

You cannot join '138 outputs.  They'll fight each other.  In some cases, you can keep the '138 enabled all the time; but you'll want to make sure two things cannot be enabled at the same time, for example a VIA and a RAM trying to put data on the bus at the same time, as they'll fight each other.

Can the outputs of 74x138 be joined via diode OR gate to mitigate this?

GARTHWILSON wrote:

Obviously you'll have to have some kind of I/O, or the computer won't be any good for anything at all.  Plan accordingly.

Definitely. But for now, I'm trying to avoid anything other than CPU/ROM/RAM & glue logic for now to keep it as simple as possible, and my IO will be an oscilloscope and a bunch of LEDs.

GARTHWILSON wrote:

I would encourage posting your schematics in black and white.  We have a couple of forum members who are colorblind, and for one of them, the light-green lines may be just about invisible, and the green against yellow is problematic too.  In B&W, everyone can read it.

BigDumbDinosaur wrote:

Before I go further, may I request you post your schematics in monochrome?

Of course, I didn't think of this. Thanks for pointing this out!

BigDumbDinosaur wrote:

You didn’t mention whether you are going to use an NMOS 6502 or a 65C02. The latter is highly recommended for a number of reasons, not the least of which is the 65C02 doesn’t have the hardware errata of the 6502. Also, the 65C02 has strong output drive that swings rail-to-rail, whereas the 6502 has weak fanout that works at TTL levels. The output characteristic difference can give you grief.

Yes - I'm going to use 65C02 as it's still being manufactured, I've already ordered few of them from Mouser.

BigDumbDinosaur wrote:

Both versions of the SID are also TTL devices, so that is something else to consider. Of the two, the 8580 will be the much better choice. The 6581 needs a 12 volt supply, runs hot, is easily damaged by ESD and doesn’t follow the written specs for the device as well as the 8580. The 8580 can get by with a 9 volt supply, has less THD in its output and is less ESD-sensitive.

Yes, 8580 is definitely more reliable. I have few from new old stock (tested them with my C64C), I'll probably play with them.

BigDumbDinosaur wrote:

Garth answered this, but I’ll add a bit more to it.

Most SRAMs are designed to interface to Intel x86-style buses, which means they have three control inputs of interest (aside from the address and data pins): /CS (chip select), /OE (output enable) and /WE (write enable). /CS is controlled by your address bus decoding logic and is driven low (asserted) when the device is selected for access. When asserted, /CS, also referred to as /CE (chip enable), brings the SRAM out of hibernation and causes it to set up an internal data path to the cell that is to be accessed.

As the SRAM’s internal setup process is relatively slow, I always recommend /CS be asserted as soon as the MPU drives a valid address onto A0-A15. The 65C02 does this during Ø2 low, which means /CS should not be qualified by the clock (Ø2), since you will be unnecessarily giving up some timing margin.

Once /CS has been asserted, /OE would be asserted during a read cycle. The SRAM will drive the data bus one setup time after /OE goes low—that setup time is typically shorter than the /CS setup time. The MPU will sample the data bus near the end of the Ø2 high phase and latch the data at the fall of the clock. Although not essential in a 65C02 system, good practice will not assert /OE until Ø2 goes high, a hedge against data bus contention in some applications.

If a write cycle, /WE must be asserted, but only after the rise of Ø2. Qualifying /WE with the clock prevents data corruption due the buses momentarily being unstable shortly after the fall of Ø2. If writing is enabled while Ø2 is low, there’s the chance that two different cells in the SRAM might be “touched” as the address bus settles. Needless to say, debugging something of that nature would difficult.

Below is a circuit that fully qualifies reads and writes, and is suitable for use with hardware that has an Intel or Zilog interface, e.g., a typical SRAM or other non-65xx output device.

This has been extremely informative & helpful, thank you!

[BillO]

and3rson wrote:

Wow, thank you for so many responses, I really appreciate this!
Can the outputs of 74x138 be joined via diode OR gate to mitigate this?

An AND gate is what you need. It's output will go low when any one or more inputs go low.

[and3rson]

BillO wrote:

and3rson wrote:

Wow, thank you for so many responses, I really appreciate this!
Can the outputs of 74x138 be joined via diode OR gate to mitigate this?

An AND gate is what you need. It's output will go low when any one or more inputs go low.

Oh, I think I finally got it. For some reason I kept thinking 74x138 outputs are X when inactive. Thanks for the pointer!

[BillO]

and3rson wrote:

Oh, I think I finally got it. For some reason I kept thinking 74x138 outputs are X when inactive. Thanks for the pointer!

Right, it's inactive outputs are high.

A diode AND gate would be fine. I use 1N60 / 1N60P diodes for this. They have very low forward voltage (at low current), very low reverse leakage and they are fast and they are cheap. Use them with an around 3K pullup resistor.

[and3rson]

Thanks for all your responses! Here's my second take.

RAM is mapped to 0000-DFFF, ROM is mapped to E000-FFFF. I used 512Kx8 RAM since I didn't have 128K RAM in my KiCad parts.

I've used 74AC08 to select ROM when A13-A15 are high, and RAM otherwise.

[Paganini]

You might find these articles useful, particularly the one about stealing bytes for I/O:

https://www.atarimagazines.com/computei ... /page9.php
https://www.atarimagazines.com/computei ... page17.php
https://www.atarimagazines.com/computei ... page15.php

Since your address space is totally full, you'll have to steal some from someplace if you want any I/O ports!

[GARTHWILSON]

and3rson wrote:

GARTHWILSON wrote:

The RAM will be active when this input is low, which is the opposite of how you have it.

Not sure if I'm following: all 74x138 outputs & SRAM /CE & /OE are active-low, aren't they? (So the decoder will only ever select one RAM or ROM at a time)

It's that you have the RAM's CS\ (pin 20) wired to Φ2.  You'll need to read or write the RAM (or any other device) while Φ2 is high, not low.  The 65xx bus cycle starts with Φ2 low, and it gets the address and other things set up during this first half cycle, then the read or write happens in the second half, when Φ2 is high.