Hello everyone,

Instead of trying to individually respond to the floods of e-mail I have recieved about the PCB project and try to coordinate everything myself, I've set up this folder for discussions of the PCB design. Now everyone can interact with each other. As parts of the design are finalized the PCB Project Page on www.6502.org will be updated accordingly.

You can check the project page to see what has already been established and what needs to be decided on.

One major thing that is undecided is the address decoding. What goes where, and how?

I look forward to your ideas.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

It seems that the big design issue at this point is the address decoding and the expansion connector. Everyone has their own idea of how the address decoding should be, so I'll let you present your ideas here.

Several people have expressed an interest in having a bus connector, but there has been some debate on how to implement it.

Andre Fachat has released his "CS/A" bus format under GNU Public License and has suggested that we implement it. You can find more information on this bus on Andre's pages inside www.6502.org.

Ted Melton took a look at Andre's board and has suggested that we use Rockwell's RM-65 instead. I'll let Ted explain more about it that format.

Another thing to consider is what format the connector itself will have. Some have suggested a backplane, Pete McCollum and I were talking about using a stackable board system.

Ideas? Comments?

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

Here are my suggestions for some of the issues that Mike has mentioned:

Bus connector.
I like the idea of using two 40-pin "Berg type" headers. It is cheap, simple, and the matching ribbon cables can be found anywhere for near-nothing (they are the same as used for disk drive cabling in nearly every PC).
With a slightly different connector on the 2nd board, two boards can be 'stacked' in a fashion similar to the PC/104 bus (no cable needed).
If two of 'our' boards are used, then the 1st board would have the CPU, clock, basic memory, serial port, etc. The 2nd board would have expansion I/O or memory - at worst, only some chip selects would need to be changed on the 2nd board.
As for the signals on the bus connector: I don't think it's important which bus spec we follow, since I think we should have a *superset* anyway. That is, just bring out all sorts of signals to the bus, even if we can't think of a good use for all of them. Especially, include lots of options related to Chip Selection and address decoding - this is where flexibility can be a real plus.

Address decoding.
I suggest the following: use an LS145 (BCD-to-dec decoder with O.C. outputs) to decode eight blocks of 8K each. With the O.C. outputs, multiple 8K blocks can be "wire-ORed" together without any extra logic. For example, tie the lower
three blocks together to form the chip select for a 32K SRAM.
Each addressed memory segment would require a pullup resistor - this is the only extra components needed to take advantage of the flexibility of using O.C. outputs. A SIP 10K resistor pack could be used to provide all the pullups in one package.
Next, use an LS138 to decode one of the 8K blocks ($A000-BFFF for example) into eight smaller segments of 1K each. This would give adequate chip selects for the UART, VIAs, etc.
Next, I would suggest that at least some of the above-mentioned CS lines be routed through another Berg header, so that each of them can be 'enabled' with a push-on jumper. If multiple boards are stacked/cabled together, this would allow chip selection to be worked out *without* any modifications to the 2nd board. Folks who don't need this much flexibility could simply solder a jumper wire in place of the header for each CS being used.

CPU clock.
I saw from Mike's description that the clock would be selectable. I assume this means using (for example) a 4 Mhz clock can, plus another chip with some flops in it to derive 2 Mhz and 1 Mhz. I don't mind this, but why not just let folks plug in whatever clock can they want to use? That is, if it's going to require an extra chip, I don't think it's worth it.
Meanwhile, it would be desireable (to me) to run the clock from a plain crystal instead of from an oscillator can - the cans use a lot of power.

Pete

Some notions...

1) Instead of supporting a 65816 in a daughtercard, why not just leave the socket and traces for the extra chip or two in to decode the top 8 bits of the address bus. If I remember the 65816 design properly, it is just one or two extra chips. If I'm wrong, then it should probably be left alone -- we don't want too many features in the card.
2) Perhaps there should be a processor direct connector on one end of the board (probably a 40 pin IDE cable that shows all 40 signals of the 65816) and a seperate expansion bus for other perepherals.
3) The 6502 is available in speeds of up to 14 mHz. I'd like to see 14 mHz instead of 4 mHz be the maximum speed.

Regarding reply -.1 :
Did I miss a discussion about a 65816 daughterboard?
Other than 2.4, I don't see any mention of it.

As for clock speed, I don't see that there would be any "built-in" limitation on speed - it's just a matter of what speed do the various chips support. Can you get 65C22's that run at 14 Mhz? What bus speed does the 16550 allow? If you run really fast, the memory chips (PROM and SRAM) might get expensive.

Pete

Don't wory -- no, you didn't miss out on a discussion of a 65816 daughtercard. I just had to add my own two cents. Heck, it would be nice to have an external segment register that could let a 6502 access more than 64k of RAM if it's not gifted like a 65816.

Left to my own devices, I'd just put a 65816 in. University prices for a 65816 are a $2 or so more than a 6502 (which is only $3 or so), so I'd opt for the cooler chip that is much much much closer to my heart (I still remember the day that assembley language made sense to me, after years of trying to figure out what I was doing)

From my often wrong and slightly twisted memory, I recall the design speed being 4MHz as the max, given the oscilator and the clock chip. I'd rather see 14 MHz or so as the design speed. I know that you can get a 8 MHz 6522, but I dono if there's anything faster than that.

As for memory, it's really hard to find memory that isn't fast enough these days, especially given that you can put 64k of really fast SRAM for not much money in your design. 80 ns ram will give you enough for 25 MHz and no wait states, if my memory serves -- I think the 6502 only accesses memory every other clock cycle. Plus, with a properly synchronized memory system, even if the memory is too slow, it won't matter.

Dono. I see the problem with the board project as being that everybody's going to be like me and want their own personal nifty features added to it, and the board becomes unweildly. Especially if some individual is going to sell the boards to hobyists, you don't want to have a lot of boards.

Dono. The project interests me, mostly because I want to build my own computer. I'm debating weather I should make a 6502 or 65816 based computer with the premade boards or get a wirewrap kit and a CPU and start hacking...

I'm quoting reply -.1 here:

>As for memory, it's really hard to find memory that isn't >fast enough these days, especially given that you can put >64k of really fast SRAM for not much money in your design. >80 ns ram will give you enough for 25 MHz and no wait >states, if my memory serves --

I won't swear to it, but I believe with 80ns memory you can only run at about 5.5 Mhz or so with a 6502-type bus. Addresses are not valid on the bus for an entire cycle, only for a *half-cycle*. So, at a 1 Mhz clock, you have 500 ns of time, but that doesn't allow for any logic delays - realistically, you only have about 450 ns. To run 14 Mhz, you would need around 25-30 ns memory.

>I think the 6502 only accesses memory every other clock >cycle.

For the reasons outlined above, it doesn't help...

>Plus, with a properly synchronized memory system, even if >the memory is too slow, it won't matter.

I don't follow you here...?

>Dono. I see the problem with the board project as being that >everybody's going to be like me and want their own personal >nifty features added to it, and the board becomes unweildly.

Agreed. But I'm still interested in whatever we come up with.

>Dono. The project interests me, mostly because I want to >build my own computer. I'm debating weather I should make a >6502 or 65816 based computer with the premade boards or get >a wirewrap kit and a CPU and start hacking...

If you're comfortable with WW, then it's a good way to get whatever you want. It's *much* faster than other hand-wiring techniques, and it's vibration-resistant.

Pete

Here are my thoughts on a few of these issues.

Construction Techniques:
A little off the topic, but sorry Pete, I like a lot of your ideas but wirewrap isn't one of them. I'll take point-to-point soldering any day.

65816 vs. 6502:
I sort of asked for trouble when I put that "65816 daughterboard" comment in the initial specs for the board on the www.6502.org site. I did this because I knew that someone would ask for it. I don't think it is of general interest to put the 65816 on the board itself. It's a *much* harder chip to find and more difficult for beginners to work with. I say let's consider making a 65816 board later (after the 65C134 board <grin>). Or, with the expandability we're designing into the address decoding and bus connectors, you can leave the 6502 off of this board add a 65816 easily on a separate card. Of course, if the majority feels differently about this matter we could put the 65816 in instead. It doesn't seem right to me at this stage though.

Address Decoding:

I really like Pete's ideas about the address decoding and expansion connnectors. The decoding into 8K blocks with one block divided into 1K segments for I/O makes a lot of sense. With three I/O devices on the card (two 65C22s and the 16550) that leaves five decoded I/O selects to stick on the expansion connector for easy expandability. And with the chip selects for every chip going into a jumper block the address decoding has unlimited expansion potential. We need to look at these existing busses (RM-65, CS/A) and start making some preliminary bus pinouts.

Clock Crystal vs. Oscillator:
Chris Ward suggested the jumper-selectable clock frequencies and I like the idea a lot. It's nice for experimenting, especially in a classroom setting. How about we have holes for the regular crystal and also for a dividable oscillator circuit? Considering the size of the board already (four forty-pin chips) it won't add much if anything to the footprint.

High Speed Operation:
I originally wanted a super high speed board myself, and so far there is nothing in the design that limits your potential speed other than the parts you plug into the sockets. The 65C22 is available up to at least 8 MHz. I'm sure the 16550 is available in that speed and higher.

Anything I forgot? Comments, suggestions?

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

> I won't swear to it, but I believe with 80ns memory you can only run at about
>5.5 Mhz or so with a 6502-type bus. Addresses are not valid on the bus for

> an entire cycle, only for a *half-cycle*. So, at a 1 Mhz clock, you have 500 ns
> of time, but that doesn't allow for any logic delays - realistically, you only have
> about 450 ns. To run 14 Mhz, you would need around 25-30 ns memory.

Hmmmm.. Probably means you want to have a set of D flipflops to maintain the address bus to hold the address stable, which would let you run it at a nice fast speed.

But then again, you may be right. I only have two college semesters of electronics behind me, so I don't consider myself to be anything close to an expert. This is why I am merely wanting to build a computer instead of already having built it....

Could somebody who knows what they are doing verify if I'm off my rocker or not?

>Hmmmm.. Probably means you want to have a set of D flipflops >to maintain the address bus to hold the address stable, >which would let you run it at a nice fast speed.

I think that still won't work: addresses become valid at the beginning of a half-cycle, and data is expected to bee valid at the end of the *same* half-cycle.
What you suggest *could* be made to work if you treated memory like an I/O device. That is, latch the address into a register, then go away and do something else for awhile to give the memory the time it needs, then come back and read the memory data. For reading, it would require a tri-state buffer that is enabled by the CS signal. For writing, you would also need an outgoing latch on the data bus (to keep the write data stable while the memory is catching up).
*However* (and this is a BIG however), you would *not* be able to execute code out of memory this way, since opcode fetches and such have to be completed in the same half-cycle.

>But then again, you may be right. I only have two college >semesters of electronics behind me, so I don't consider >myself to be anything close to an expert. This is why I am >merely wanting to build a computer instead of already having >built it....

Great idea. You can learn a lot of practical details by building something yourself.

Mike: BTW, I definitely wasn't suggesting that WW should be part of the PCB project - just agreeing with 'Wirehead' that's it's a good way to build a one-of-a-kind board.
Your suggestion about the clock stuff sounds fine to me.

Pete

Okay, I finally get what you were saying about half-cycles. According to the spec sheet, the speed for the RAM at 14 MHz is 30 ns, if I'm reading it all right (which I may not be).

If you have slower RAM (now I'm actually looking things up on the 65c02 data sheet), you can pull the RDY signal down for as long as you need to get the data out. However, since the 6502 would be stopping in its tracks, that would make no sense.

But 20 ns SRAM is avalable, and isn't too pricey for a processor with a maximum memory size of 64k.

I hate soldering because it involves a soldering iron. Which means that I gotta heat it up and wory about not ending up with a scar on my hand from it (like my dad's got -- I'm second generation computer geek) and all that jaz. Plus, I dono if the campus athorities would be happy if I were to start soldering in my dorm room -- kinda a fire hazard and the flux does kinda smell funny.

Of course, the problem is, given my current time allocatiuon, it's highly unlikely that I'd get ANY part of computer construction done. Other than, of course, assembling the average PC clone out of parts. I've lost track of how many times I've done that. I've got 1.51 years left of college, so I figure that I'd best get some idea about what I want to do before I leave college so that I can buy parts from the ECE stores on campus.

Dono. The 65816 just needs two latches on the D bus to get the top 8 bits of the address bus. Which leads me to think that you /could/ do your design where you can put either jumpers or a latch, depending on if you use the 65816 or not. But that may get too complicated.

Besides, the 65816 has the ABOR pin, so you could do virtual memory, so maybe a higher-end board should be created at some point in the future that is designed for the 65816.

Now, I'd suggest that the CS/A bus be modified to include 24 bit addressing, so that there's no changes to support a 65816. I like the stackable idea, like the PC/104, however that would require a standardization of mechanical fitting that would destroy some of the hobyist appeal. IDE cables would also be nice, but how bad would the signal delay be at 14 MHz across a long bus?

Pete: I know about what you mean about wirewrapping, I just have to voice my hatred for it every chance I get.

As for the 65C816 discussion: as I see it very fast SRAM is indeed available and would be the best solution to your RAM speed dilemma. You have a bigger problem than the SRAM: the EPROM. Accessing memory through latches like I/O is an interesting idea, but when you consider the programming involved and extra hardware I think you'd be better off using the RDY input. As for the 14 MHz ribbon cable, I don't think you'll have much luck past a few inches. These issues (and many more) are why I feel that the 65C816 and super high speed operation is beyond the scope of this (our first) project. Most applications of this board won't require 4 MHz, let alone 14 MHz.

That's not to say that we can't develop a more advanced board later, or that this 6502-based board couldn't be modified by the user later. Remember the original design goals: simplicity, usable by beginners and also more advanced users, easily accessible standard parts. It seems to me that at some point we should make a high-power 65816 board, but not for the first one. What do you think? We've already talked about a 65C134 board, so a 65C816 could round out a nice series of three boards.

In the next post I'm going to post our preliminary specifications for the board so far and we'll take a deeper look at the bus connector implementation.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

>Now, I'd suggest that the CS/A bus be modified to include 24 >bit addressing, so that there's no changes to support a >65816.

Yes, we would certainly have enough pins left over out of a total of 80. Going with Mike's suggestion to "keep it simple" with the first board, it would be just a matter of documenting that pins xx thru yy are intended for additional address lines, etc.

>I like the stackable idea, like the PC/104, however that >would require a standardization of mechanical fitting that >would destroy some of the hobyist appeal.

I'm thinking that we're OK here, if we assume that the "2nd board" is another one of "our" boards (the same etch as the "1st board"). That is, our boards are guaranteed to plug into each other. There's no need to follow the actual PC/104 spec. If we can track down the female connectors that have WW-style pins on the bottom, then it's a 'done deal' - the boards will plug together.

>IDE cables would also be nice, but how bad would the signal >delay be at 14 MHz across a long bus?

I'm *guessing* that it would be OK for a few inches or so; especially if the cable was the shielded variety. This just points out another advantage of the boards 'plugging together' - signal lengths are short.
After the boards exist, it will interesting to experiment and see just what the limitations really are.

As Mike pointed out, *most* of us really don't need the high CPU speeds for the type of applications that a board like this would be used for; and/or most folks won't want to track down the high speed parts that would be needed.

Pete

>Now, I'd suggest that the CS/A bus be modified to include 24 >bit addressing, so that there's no changes to support a >65816.

I've mentioned this before, but I'd like to re-iterate again: I suggest that we *not* get all wrapped up in any particular bus spec. Just put every signal that we can think of out there on the two 40-pin connectors - even signals that (today) don't seem very useful. It would be a real shame to later decide "...if only we included the XXX signal too, then we could implement a YYY...".

We probably have enough pins to implement a working equivalent to 2 or 3 different "buses" at the same time, since all bus designs consist mainly of address, data, and a few control and clock signals.
I haven't looked at the CS/A spec, etc. - are they doing anything 'unique'?
Just talking off the top of my head, the *minimum* control signals would be: phase2 clock, R/W, RAM-R/W, OE, RDY, SYNC, RESET, and a bunch of pre-decoded Chip Selects. Did I leave out any obvious ones?

Pete

I'd say, for the bus, we should make sure that we have every signal that is supported by the 6502/65816 processors. I mean, the 6502 and 65816 are both 40/44 pin parts, so we'll have plenty of pins to spare! The CS/A bus is nice because it has plenty of stuff for timings and such -- although I'd put a 60hz clock in as well as a 50hz clock and various and other sundry details.

I'd also have the bus provide all of the different powers -- 3.3v, 5v, and 12v -- that would be needed.

It would be nice to have a signaling protocal for what MHz speed the bus is running at, but I think the range is too variable. Perhaps just two pins so we could signal a 0-1 MHz, 1-2 MHz, 2-4 MHz, and 4+ MHz bus.

As far as stacking, I suppose we just need to define that you have the connector in one corner of the board and three drill holes that are x inches/cm offset from the connector. That sets the minimum board size as being x by x inches/cm but doesn't give a maximum board size, outside of tensile strength. Somebody else had best decide what that value of x should be. That'll be much better than trying to build slots.