6502.org

I've always wanted to build a computer. So lately I've been working on a design for a simple 6502 based machine. As I don't have a whole lot of electronics experience, I'm trying to keep things simple for now.

I've started working on a design, which you can download here. The generic logic gates are supposed to be high speed CMOS 74xx series chips. I didn't like the ones in gschem's default library, so I made my own. However, I've yet to properly set up the pin numbering and lables. (Just call me lazy.)

It's pretty basic at the moment, with 32K of SRAM at the bottom of the address space and 8K of FRAM at the top. The rest of the top half of the address space is currently unoccupied, but I plan to add IO space there (and possibly more RAM).

Clearly, there's some work still to be done. In particular, I cheated and black boxed the clock and reset circuits. Any pointers to resources on solid designs for them would be appreciated. I've noticed a lot of you start with a slower clock speed and then crank it up until it stops working. Do you just use a fixed clock and then swap out the crystals, or is you use a variable clock speed design? If the latter, how do you build one?

I'll appreciate any feedback you can give me, but I have a few specific questions.

Firstly, what should I do with the unused output pins? I know it's not a good idea to just let them float, but I don't know how to properly tie them off.

Secondly, the FRAM's datasheet says that, unlike an SRAM, /CE is edge triggered. On the falling edge, it latches /OE, /WE, and the address lines. So, to make sure /OE is in the proper state when latched, I used two AND gates in the FRAM's address decode. Is this proper design, or just overkill? I originally had one four input AND tied to both /CE and /OE, but then I changed it.

My current address decoding is pretty ad-hoc. I think it'll work alright, but as I start adding IO and stuff, it's sure to get more complicated. Is there a more systematic way of address decoding that's better, or should I just keep going with the random logic gate approach?

Finally, real computers have blikenlights. I want to add LEDs so you can see the state of the buses and stuff. (Probably more useful once I add a single stepping mode.) What's the proper way to do that and avoid causing problems?

Anyway, that's what I'm working on and wondering about. Any input you have would be greatly appreciated.

Hi Karatorian
your link to http://static.karatorian.org/hardware/mainboard.pdf doesn't work for me.

Cheers
Ed

Unused outputs should be ok. Unused inputs should be tied to a defined logic level. You could for example define a "logic 1" signal with a single 10kOhm to VCC and use that for all inputs. OTOH I normally connect them directly to VCC, but that has bitten me because I wasn't able to cut a trace and re-use that logic gate when I found a bug in the first draft board.

André

An easy circuit I'v used in the past uses a VCO (voltage controlled oscillator) using a 74S124. You can change the values to get it down to slower speeds.

Cool idea with the FRAM. It'll probably be your speed limiter at this point. What access time?

I just get a "404 - Not Found" error message.
Clock oscillator cans are the easiest. You can get half-size ones that fit in an 8-pin DIP socket to save space. To get the best symmetry, you could put it through a flip-flop to divide by 2. For the reset circuit, as long as it's a CMOS (not NMOS) 6502, you can just hang an RC on the RST pin since it's a Schmitt-trigger input, but that can cause problems with your I/O circuitry since it may not all have Schmitt-trigger RST inputs or their thresholds may be different so they might not be ready for business yet when the processor addresses them in the RST routine. You can put the RC on a gate with Schmitt-trigger inputs, and run its output to the RST\ line to the processor and other ICs that need it. My circuit is here.
B. I made a variable-frequency oscillator, and measure the frequency with my frequency counter. Here's the first one I made:



I made a much smaller and faster one later, but this will do the job for beginning construction, and the faster stuff (100MHz) is more of a challenge to build and make it well behaved.
Unused outputs can be left unconnected. Unused inputs usually need to be connected to a valid logic level though.
Sounds unlikely. How do you get it out of enable?
You can do it all with a single quad NAND and keep the propagation delays low if you don't need more than 16K of RAM and 32K of ROM (or vice-versa) and ten I/O ICs, this way. (You can substitute a NAND section for the inverter section to get it all in one IC. I used the inverter because the IC was already on the board for other things.)
Lights for the buses won't do you any good unless you can use a pushbutton to advance the clock one cycle at a time and record all the bus status to substitute for the expensive logic analyzer you don't have. In thoser rare situations, I've just used the oscilloscope probe. A logic probe would do just as well. The LEDs will add a lot of unwanted bus loading. Even if they're fed by buffers, the buffers will add capacitive loading to the buses. I'd say skip it. I do like to have a few annunciator lights, but they're not so much for debugging. See my tips #35, 36, and 37 at viewtopic.php?t=342&start=35 . I brought some common oscilloscope probe points out to the front of the computer for easy access: IRQ\, NMI\, A/D input, D/A output, A/D CS, #4 LED, VIA3_PB6, and VIA3_PB7. They are the eight hooks with the light-blue bases along the bottom in this picture:



with the legend:



There's more about this computer on my project pages, at http://www.6502.org/users/garth/projects.php?project=1 . They're outdated and don't show the mezzanine, but you'll get more info.

Edit: I have a series of articles now on building your own 6502 computer, at http://wilsonminesco.com/6502primer/index.html.

Sorry about the 404, I'm such a scatter brain sometimes. It's fixed now.
I've read about hooking unused inputs through a resistor, rather than straight to Vcc, but I've never understood the point. Is there some situation where it's actually needed, or is it just a waste?
Access time is 70ns. It'll be a cool idea if I can get one. Nowhere I looked had them in stock, so I just requested a sample from the company. The eventual idea is to put in a switch to enable FRAM writing, which will allow the computer to do it's own "ROM" updates, but protect the boot code from getting scribbled on by buggy code.
You can get the datasheet from the manufacturer's website: http://ramtron.com/files/datasheets/FM16W08_ds.pdf Maybe "edge triggered" isn't the right terminology, but they go into detail about how it differs from SRAM. Basically, /CE needs to be clocked, it can't be held low.

Ok, maybe the blinkenlights aren't such a good idea. Although, I do plan on implementing single-stepping. Hacker folklore about old dinosaurs with lots of lights is somehow appealing to me. I guess I'll have to make an LED bank IO device instead. In retrospect, it'd probably be more useful anyway as then they'd be under software control, rather than just flickering away at imperceptible speed.

Thanks for the pointers to the clock circuits, I'll look into them and expand my schematic. Thanks for the rest of your advice as well, I'll let you know what comes out of it.

The theory behind using resistors to tie unused gate inputs to Vcc is in the event you suddenly need the gates you can make a simple patch to the board. If you wire the inputs directly to Vcc or ground then you are faced with cutting traces so you can use the inputs. I suggest tying the unused inputs to Vcc through a 10K resistor. Allowing CMOS gate inputs to float can result in a noisy circuit.
Here's a copy from the data sheet:

/CE Input Chip Enable: /CE selects the device when low. Asserting /CE low causes the address to be latched internally. Address changes that occur after /CE goes low
will be ignored until the next falling edge occurs.

Functionally translated, pulling /CE low selects the chip, without regard to the clock cycle. Sounds like a level-sensitive input to me, just like any other RAM or ROM.

I can only partly agree with you, BDD. "/CE selects the device when low" does indeed sound entirely conventional. But it is not usually the case that "Address changes that occur after /CE goes low will be ignored." Myself, I'd treat this as a wakeup call, and be sure to give the data sheet a careful perusal.
I found the following remark in my ancient, dog-eared reference volume from Texas Instruments, "The TTL Databook for Design Engineers" (c) 1976. On pg 5-4 it has the following suggestion: However, the resistor is superfluous with MOS and CMOS logic chips (4000 series, HC, HCT, AC etc). I suspect modern TTL processes (eg: ALS, FAST) likewise don't need the the resistor, but I don't use TTL anymore and am not an expert. Might be worth checking... or, failing that, simply include the resistor as a precaution. BTW the resistor only becomes an issue if the unused input is to be tied high. In cases (eg, as with an OR gate) where an unused input would be tied low, no resistor is used.
Interesting observation! I tend to suspect this is just a spin-off benefit, but who knows. Anyway, another nice thing about the resistor pullup is you can safely short the pin low for testing purposes

-- Jeff

Actually, ignoring address bus changes after chip select has been asserted is not totally uncommon behavior. Presumably, a properly functioning circuit would have stabilized the address bus at the time the device is selected. If not, all bets are off. I wouldn't be surprised to discover that other devices we use act in a hinky fashion if the address bus changes after being selected.

I haven't been working on my mainboard design much. (I got distracted with ideas for a USB FRAM/EPROM programmer.) However, I came up with a new address decoding scheme (using a '138), which lead to a more organized (if still unpopulated) memory map.

As before, the low 32k is the SRAM. The high 32k is now split into eight banks of 4k each, the seventh and eighth of which are occupied by the boot FRAM. So it's the same layout as before, but now IO space (or whatever else) has (course grained) address decoding.

Once I got that laid out I started thinking about IO devices. I've got a lot of ideas, but I figured I'd keep the main board pretty bare bones. So I decided to throw a bus on it instead. I've been interested in passive backplanes (like the S100) ever since I first heard of them. However, rather than the traditional edge connectors and separate backplane, I borrowed an idea from the Arduino and sketched out a plan for stackable mezzanine boards.

The bus is pretty dumb, it's mostly just the native interface of the 65C02. After drawing up various concepts and looking at available connectors, I decided to go with two rows of 24 pin sockets. I plan to place the sockets at opposite ends of the board and organized their pinouts accordingly.

The first connector (which I've dubbed the X bus) consists of everything needed for address decoding. Namely, the address bus, write enable, and the clock. Additionally, it has the six available decode lines from the '138, which select 4k banks in the open space between the SRAM and FRAM.

The other connector (the Y bus) has everything else. Which means, the data bus, power rails (+5 and +12), and most of the CPU pins (missing are PHI1O, PHI2O, and /SO). With two grounds (one next to each power rail), this leaves four reserved pins. (Or five if I give up one ground. However, this may not be enough as I've already got extra ideas brewing.)

Originally, I only planned on using twelve bit addressing on the bus (the higher bits are all decoded by the mainboard already), which would've saved a few pins, but then I had a eureka moment that made me change my mind. I realized that, if the bus supported it, I could use the programmer I've been designing in circuit! (I just realized that it could also be used to drive IO boards directly from the PC).

Once I made that change, other good reasons for having the full address bus came to mind, like DMA, and remote debugging. Some of these ideas require additions to the bus that haven't been fully developed. In circuit programming wants to run the clock on it's own terms, so it'd need some method of disabling the mainboard's clock. One of my more sophisticated debugging ideas requires the PC emulating potentially any address, which would require some way of avoiding the onboard address decoding. Simple DMA ought to work with what I've already got defined though.

Another idea contending for the few remaining pins is some sort of reset line. The /RES line is exposed on the bus, so any device that wanted to could conceivably pull it high if it wanted, but that seems like a dirty hack. Furthermore, if that device has a reset connected to /RES, it may not even work at all.

Since it's the device pulling /RES high, it'll reset itself and then it's anybody's guess what state the /RES line'll be in. The reset period may not be long enough for other devices on the bus to properly reset, or, worse, the /RES line may be pulled up indefinitely. Having any output lines connected to /RES is probably a bad idea, as I'm sure the state of said line during a reset is undefined for a great many devices, which could reek all kinds of havoc.

What's needed is a dedicated reset output (from the daughter board's POV) the instructs the mainboard's reset circuitry to cleanly reset the machine. So there goes another pin.

One more thing that could be really nice to have once I start developing IO devices would be a programmable interrupt controller. That would require adding additional IRQ lines, so It's likely the bus is going to get larger before I actually implement this.

Anyway, you can check out the latest version of the schematic here. It's still got no clock and reset sub-circuits. That's my next mission (thanks again for the tips), but before then, I've got a few questions.

First up is another question about unused inputs. For completely unused inputs, things are pretty simple, just tie them to the proper logic level. However, what's I'm wondering about is how to handle inputs that aren't used on the mainboard, but might be used by a mezzanine. Then again, they might not...

For instance, the mainboard doesn't do anything involving interrupts, so it wants /IRQ tied to ground. If the mainboard ties it to ground, what happens when some device tries to bring it high? And if it doesn't work, how do you do it correctly?

It's a similar situation with RDY and BE. However, in this case, for normal operation, the mainboard wants them tied high. So, can they be driven low by something else? It seems to me that one way (tied low or tied high) ought to work and the other one won't. (Unfortunately I don't know enough to be sure which. I wish I could remember more of that electronics class I took (years ago) in high school.)

Either way, you'd end up with some non-functioning inputs. How do you solve this? Use inverters so that the default state is the one that can be driven by others on the bus? Or is there a simpler way?

And now for my other question. I added a simple write protection jumper for the FRAM. All it does is tie /W to Vcc or /RW, depending on if you want write protection or not. If it's enabled, this means when the CPU tries to write to the FRAM, it ends up doing a read instead. So both the CPU and the RAM will be driving the DATA bus.

Is this safe or could it let the magic smoke out? It's much simpler to just disable the write line than to conditionally disable the select lines, but I don't want to blow anything up in the process.

Finally, one more RAM question. What's the real difference between the E (or CE) and G (or OE) lines? I know what the basic difference is, but I don't understand why they're separate lines. Essentially, I don't see the point of G.

I look forward to any comments, critiques, suggestions, answers, and questions you might have. (And I apologize for being so long winded. Had a lot of ideas today.)

I think I've figured (at least part of) my question about (potentially) unused inputs on my bus. Basically, I need pull-up or pull-down resistors to set the default state of these inputs. However, I don't know exactly what size of resistors to use.

I came across an informative article Implications of Slow or Floating CMOS Inputs, from which I learned some useful things. It talks about how floating inputs can lead to unstable results, or even worse, component damage if the floating voltage falls into the critical 0.8 to 2.0 volt range. It also discusses minimum rise times to avoid the same problem.

They give an equation:

V(t) = Vcc - (e ** (-t / (CT * R) * (Vcc - Vi))

Which can be used to calculate the voltage at time t, V(t), given the total bus capacitance, CT, the resistance of the pull-up, R, and the initial voltage Vi. This allows you to figure out the size of pull-up you need to satisfy the rise time requirements of the devices on the bus.

In their example, they give Vi as 0.5 volts, but they don't say where this number comes from. Anyone got any ideas? Wouldn't it be safer to assume zero?

They also give a table of the rise time requirements for various logic families. They vary pretty widely, but all but the fastest devices (some ABT) are satisfied with 10ns/v. This means that I've got 20ns to get the line to a safe level of two volts. (Maybe less if I want to leave some headroom. Their example uses 15ns for 10ns/v parts.)

So I started looking at the datasheets I had handy to see what sort of input capacitances I could expect. With what's already on my bus, I have the CPU at 5pF, the SRAM at 7pF, and the FRAM at 6pF (inputs) and 8pF (IOs). So that gives a total of about 20pF. That's not including various bits an pieces in the address decoding, but that's the easy part. (I can go dig up the datasheets.)

The hard part is estimating the capacitance of the bus itself. I'm planning on using printed PCBs for the cards themselves, and wirewrap headers for the bus connectors. I don't know how to estimate the capacitance of the traces. The capacitance of the headers isn't in the datasheet, but I've read elsewhere on the forum that it's kinda high.

So I was wondering if someone could point me towards a good reference for these sorts of things. Or some formulas to figure them out.

Of course, just the bus capacitance of the mainboard isn't much help, but it should allow me to estimate an average per card. By punching numbers into the above equation, I've determined that I can select a specific "max permitted bus" capacitance and then derive the size of my pull-up resistors from there.

Basically, as the capacitance goes up, the max value of the resistors goes down. However, there's got to be some sort of drawback to that, because most of the designs I've looked at (in the hardware projects section) use large values, like 4.7k and 3.3k, whereas the numbers I'm coming up with are much lower. For instance, 375 ohms for a 100pF (kinda' random value), and under 100 ohms for 400pF (the specified limit for I2C). So what's the downside?

Finally, I figure that pull-down resistors can be figured in a similar manner. However, I'm sure there's some difference that must be figured into the formula. Anyone got any hints for figuring that?

I've made some more changes to my design. I added a power connector, some pull-up resistors, clock generation, and a reset controller. I also fixed and improved the address decoding, rearranged the bus headers, and redid the whole layout using bus lines, which makes it a lot less messy.

The power connector is going to be a standard Molex type so I can use the spare PC power supply I currently use as a workbench power supply.

I've got pull-up resistors on all the CPU's input lines that connect to the bus. I've also got pull-ups on two new control lines I added, /REST (reset trigger), and CLKE (clock enable). I haven't worked out the exact values yet. Does anyone know what sort of rise and fall times the W6502S requires? The datasheet gives numbers for the clock pulse (5ns max), but it's unclear whether that's intended for all inputs as well. (Which seems unlikely, at 1ns/v, it'd be the pickiest CMOS around.)

I've got the clock generator setup so it can use full or half size can oscillators. I added a flip-flop to handle any symmetry issues, but I wonder if it's really needed. Since the CPU is fully static, and you can stretch or even stop the clock, does a 40-60% (max) duty cycle really matter? Speaking of stopping the clock, there's now a bus line to do just that. (However, when the clock output is high impedance, the flip-flop's clock input is floating. I'd better fix that.)

Reset control is handled by a simple MAXIM voltage monitor. The one I selected has a minimum of features, but does include a manual reset input (which is now on the bus), with switch debouncing. I also added power and reset LEDs. I'm a little concerned about the reset LED. It's not by any chance going to pull down the reset line, is it?

Address decoding has been much improved. I fixed the FRAM's write protection scheme so that it no longer causes bus contention. I also split it into two banks of 4k, with individual write protection. The idea is to store the critical boot code in the top 4k (normally protected) and use the lower 4k (normally writeable) for general non-volatile storage. However, if I end up wanting to protect all 8k, I have the option.

I also fixed the SRAM so that it won't be subject to spurious writes. Thanks to Garth's explanation of /CE vs /OE, I think I've got chip selection straightened out as well.

Despite Garth's admonition not too, I'm still planning on running the CPU's bus lines off the board and placing the IO on mezzanine cards. Perhaps I'm just naive, but it doesn't seem like the stack will be the speed limit. The bus I'm designing is very similar to the PC/104 bus, and it runs at 6 and 8 MHz (perhaps it can't handle the full 14 plus the CPU can, but I don't really expect to be able to go that fast anyway). I wish I could get better docs on the PC/104 bus. The standard is available, but it mostly just references the ISA standard, which IEEE never finalized and I can't find. Anyone know of a good reference? All the ones I found just covered the basics (little more than the pinout).

I decided to increase the number of bus pins to sixty-four. This gives me a common header size (2x32, of which I found some nice stackable ones), and more room for expansion in the future. With more pins, I rearranged some things. Moving from two single row headers to one double row header also gives me more flexibility with the form-factor, as there's now no need to make expansion boards a specific size.

I think the mainboard design is just about wrapped up, so now I'm gonna start on the PCB layout. (I've experimented a bit with the earlier layouts.) I'm also thinking about a basic IO board and want to get back to working on the in-circuit programmer.

A few things that pop out:

The SRAM's OE\, CS\, and WE\ inputs are just that, meaning active low, not active high. This is pretty normal. A low voltage on OE\ enables the output (if the chip is selected and you're not in write-enable), a low on the CS\ selects the chip (ie, makes it respond), and a low on WE\ enables writing to it (if the chip is selected). You'll need to change some logic.

Although the 65816's Φ2 pin is an input, on the 6502 it's an output. Input must come through Φ0 on the 6502. It looks like you don't have any clock input.

The FRAM's enable circuit has an awful lot of gate delays. See if you can reduce it.

just a note: Some I/O ICs like the 6522 require that the RS and CS lines be valid and stable before Φ2 rises; meaning you can't select them with a circuit that goes through your '138 which is enabled by Φ2.

As to whether the RST\ line will be pulled down by the LED: That depends on the resistor value you choose for it. Even with no resistor at all, the LED will not pull the line down low enough to be a valid 0, but the MAX6804 may hardly be able to pull it up hard enough to get a valid 1 to let the processor run. (I have not looked up the current-- I'll let you do that.)

For low operating speeds, the rise and fall times for most things are not very critical since they are level-sensitive. The Φ0 input is a Schmitt-trigger input, so even an RC between Φ0, Φ1, and Φ2 will work for an oscillator (I did that for hundreds of something we have flying in aircraft cockpits), and by the time the signal gets to the Φ2 output, it will have a good rise and fall time. The '816 OTOH requires a really clean clock input since the same signal feed everything.

Having the oscillator's duty cycle at 50% is not necessary if you're well below the maximum operating speed anyway.

For the connectors to another board, it would be good to have more grounds sprinkled in, or at least move the ground pins you do have to a quarter of the way in from the ends (ie, half way to the middle of the connector) so that the return path for any given signal is not so far from the signal pin.

Also, be sure to verify the behavior of the device if /OE and /WE are simultaneously asserted. In some cases, such an input combination produces undefined behavior. A quick read of the data sheets should clarify that.
Yes it does. If you absolutely must have all that logic in the circuit, you should use 74ABT or 74F glue to keep the prop delays out of the stratosphere.
I've often said it, with some here disagreeing, but will reiterate. Device selection should not be qualified by Ø2. Doing so needlessly limits the maximum speed at which the circuit can run. As Garth pointed out, you must have the 65C22 selected before Ø2 goes high. Otherwise, the device's behavior is technically undefined. On the 65C02, the address bus is in a state of transition during the first half of Ø2 low, after which a valid address will be present if the MPU is in a read or write cycle. What this means is your decoding logic can make the chip select starting at the second half of Ø2 low. If you wait until Ø2 goes high you're simply wasting time.

On the other hand, R/W should be qualified by Ø2 so a write only occurs while Ø2 is high. Otherwise you run the risk of a wild write hitting the wrong register in a device—or even the wrong device—as the MPU sets up the address lines. Also, in all members of the 65xx family, D0-D7 is invalid during the first half of Ø2 low, which is also why R/W should occur only when Ø2 goes high. The 65C02 timing diagram makes this all pretty clear.

incidentally, the VDA and VPA outputs of the 65C816 make address qualification a bit less onerous than with the 65C02, as the VDA and VPA outputs are asserted only when the address bus is valid.
Perhaps you can take a cue from "narrow" SCSI. In that layout, every other line is a ground. Hence each signal is separated from the next by a ground, making for a stable, high performance bus that will easily run at 20 MHz.

Lastly, and I'm sure Garth and others will agree with me on this, try not to let too much creeping featurism get into your first effort. Sometimes folks who are venturing forth with their first 65xx-based computer try to do too much and end up with a complicated design that doesn't initially work and is beyond their skill level to debug. You really want to use a minimalist approach for your first design. In other words, it's best to learn how to make a single-engine plane fly before building that four-engine jumbo jet.