I took the liberty to copy "TEDM9"'s reply here - I think he accidentally started a new thread - Pete

I've read through the various suggestions for the address decoding and thought I'd add my thoughts on it.

With the size of available memory devices, I believe one RAM and one ROM socket will be enough. This would put ALL memory on the Main PCB. This could simplify the decoding question. RAM needs to be at the bottom of the memory map & ROM needs to be at the top of memory. I suggest the following memory map.

A15 --------------- /RAMCS $0000 - $7FFF 32K

Jumper selectable 2K (6116), 8K (6264), or 32K (62256)

-------

A15 ----| \

| 7400 ()--- /ROMCS $C000 - $FFFF 16K

A14 ----| /

--------

Jumper selectable 2K (2716), 4K (2732), 8K (2764), 16K (27128)

--------

A15 ----| \

| 7400 ()--- /IOCS $8000 - $BFFF 16K

/A14 ----| /

--------

This could then go to a '138 or '154 to give 8 @ 2K or 16 @ 1K or to a '138 with one select going to another '138 giving 8 @ 256 for the Main PCB with the other 7 from the first '138 going to the BUS. I really don't believe there will be many systems that would be larger than seven Expansion PCB's. Then further decoding could be done on the Expansion PCB, if it was needed.

The following logic will givee the needed Read & Write signals for the RAM, ROM, & 16550.

--------

R/W ----| \

| 7400 ()--- /WR This would be the Write for RAM & 16550

PHI2 ----| /

--------

-------

R/W ----| \ _______

| | 7400 ()------| \

|--| / | 7400 ()--- /RD This would be the Read for

------- PHI2---| / RAM, ROM, & 16550

--------

Regarding "TEDM9" in note 2.30 :

Your scheme is fine, and is very similar to Chris Ward's design, but it has the same chip count as what we've been talking about, and I think is somewhat less flexible.

Using a 145 and a 138 doesn't require any random gates, and the use of the 8K blocks can be shuffled around somewhat, if need be. Or, the 138 can be moved to *any* of the 8K blocks...

Given that we need (I think) on the board the following:
A "RAM-R/W" and an "OE" signal, plus a 'fix' for IRQ outputs on the 65C22's; we can do all of this with a single LS00 (the O.C. version).
Other than the clock and reset stuff, we wouldn't need any other small chips.

Pete

Regarding the signals on the 'main' 40-pin header, Tennessee suggested:

D0..D7

A0..A15

/NMI

/IRQ

R/W

Phi 0

Phi 2

I/O decodes 1 to 8 (From one of the 8k I/O ports)

50/60hz clock.

I would suggest the following changes:
Add "RAM-R/W" and "OE" - with these signals, nearly any type of memory-oriented device will work without any extra logic.
Delete "Phi 0" - normally not needed.
Add at least a couple of the 8K decoded blocks (from the 145). If needed, delete the 1K blocks that are used for the UART and one or both of the 6522's (but include all of the unused 1K blocks).
Add a couple of grounds, and also possibly a couple of +5V, so that the 'main board' could provide power to a small expansion board.
If we're short on pins, delete A15 and A14.

Pete

Thanks . I didn't realize I'd put it in the wrong thread.

Ted

I think after several debates that everyone is in agreement on using Pete's suggestion for the address decoding. If anyone disagrees, speak now. To recap, Pete's scheme is breaking up the memory map into eight 8K spaces which can be wire-ORed together using a 74LS145, and then taking one of these blocks further down into 1K areas using a 74LS138.

If we have indeed reached a decision on the address decoding logic, let's now move on to specify the exact format of the expansion connectors.

Please reference "http://www.6502.org/pcb.htm" now.

There you will find a breakout for the two 40-pin connectors. I have not touched the "Extended" connector yet. An initial layout suggestion for the "Core" connector has been defined with the following signals:

Vcc and GND
A0-A15
D0-D7
R/W
PHI2
/IRQ
/NMI

Assuming we want to keep all of these signals, this leaves pins 31-40 open for discussion.

Keep up the good work guys.

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

Here's an e-mail I received from one Richard Erlacher regarding our 6502 printed circuit board project. Many of his points seem to miss some of the key ideas about it being made from parts easily obtainable by anyone and geared towards beginners as well as more advanced users. Remember, this is a hobbyist project and made to be fun for everybody. Perhaps I should develop these ideas into more descriptive paragraphs on the PCB web page. He does, however, bring up some valid questions about bus timing should we decide to use higher speed parts, which some of you have talked about in the past. I'll let you guys address these issues if you choose, and don't forget to visit the web page and submit your ideas for the bus pinout.

---snip snip---
I have noted that you are using what looks like a pair of 2x20 IDC headers for possible board interconnection. Perhaps it might be easier to manage this with a single DIN41612 (e.g. VME) 96-pin connector. These are inexpensive and ubiquitous, and, if one is clever enough to use the wire-wrap version, allows boards to be plugged into one another at will.

It puzzles me that you're using the 6522 on the board. This circuit is almost useful, but seldom fully so. In dozens of 6502 applications that I turned out in the '70's and '80's, I

found the 6522 seldom offered an advantage over logic which was smaller, cheaper, and faster, and that it almost always got in the way of doing the job at hand. It was always "almost" but never "right." What's more, it couldn't drive anything requiring, therefore, that one provide buffers which really meant that using them in place of the 6522 was a better alternative.

Is there an objective specification for this board, i.e. a spec indicating what its purpose is intended to be? What is the intended clock rate? Are the peripherals limiting the rate at which the CPU can operate? I've seen spec's on a 14 MHz CPU. Is there peripheral support for this processor?

Why was it decided that bus drivers were not needed? If a cable is to be attached to the board, that represents significant capacitance. What's supposed to drive that capacitance?

I notice there's no Phase-1 or Phase-0 clock, nor is there a RDY signal on the "bus" you've tentatively designed. I guess this means that you can't run your CPU any faster than the

slowest device on the bus. Since performance is of no concern, why use the 16C550?

In place of two 32Kx8 SRAMS, have you considered a single 64Kx8? These were once common as dirt, and I'd bet that nearly everyone likely to build or use this board has a few old '486 boards lying about with several of them on board. That will save on parts count and complexity.

Just to be safe, I'd suggest you consider timing the read and write operations from the CPU circuit rather than having the I/O circuits do it at each locale. What needs to be considered is the requirement for data hold time on writes. This is difficult (see the spec's) if you have only phase-2 available. Phase-0 leads phase-2 by an interval generally quite close to the hold time requirement for most devices. If you put a set of more pragmatic strobes out on your

bus, i.e. MemRd, MemWr, IORd, and IOWr, more peripherals become available, and it's possible to time them such that all the strobes are comfortably provided with the desired margins. If you create your memory and IO write strobes by gating the memory and IO identification signals with PHASE-0 (the input clock) it will lead the equivalent read strobes, similarly generated by gating those identificaton signals with PHASE-2. Many classic peripherals can't do without

this data hold time.

One of the silliest things that makers of the '70's vintage 6502 application boards, e.g. KIM, SYM, AIM, etc, did was to use address lines as part of the decoding scheme for their LSI's, e.g. 6530, 6522, etc. This chopped up the memory map, and while they, probably correctly, assumed that no one would ever really need more than 1K of RAM space, but the stupid decoding made that a self-fulfilling prophecy. If you simply use an I/O input to your CPU circuit, the fact that valid addresses significantly preceed the rising edge of phase-0 will allow the presence of a peripheral to make itself observable by its assertion of that signal, thereby causing the CPU circuitry to produce IORd instead of MEMRd. That can be a really handy function.

Why don't you let me know how you see these items. It would be interesting to see your viewpoint.

regards,

Richard Erlacher

---snip snip---

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

And while I'm busy crossposting, here's something Ted Melton asked me to put up also. It's a description of Rockwell's RM65 bus, we thought it might be useful to get ideas from while designing our expansion connectors. It wouldn't fit nicely into the forum, so you can grab the textfile from

http://www.6502.org/hardware/rm65bus.txt

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

>Many of his points seem to miss some of the key ideas about it being made from parts >easily obtainable by anyone and geared towards beginners as well as more advanced >users.

I agree Mike.

>I have noted that you are using what looks like a pair of 2x20 IDC headers for possible >board interconnection. Perhaps it might be easier to manage this with a single DIN41612 >(e.g. VME) 96-pin connector. These are inexpensive and ubiquitous,

I would say that a VME connector is not nearly as cheap and easy to find as a Berg type (which I guess is the same as what he calls "IDC").

>It puzzles me that you're using the 6522 on the board. This circuit is almost useful, but >seldom fully so. In dozens of 6502 applications that I turned out in the '70's and '80's, I

>found the 6522 seldom offered an advantage over logic which was smaller, cheaper, and >faster, [ snip ]

I'm sure it's not bug-free, but it does several useful things.
Also, it's a "65xx"-series part, which has some appeal for me, whether it works very well or not. If the goal was to make something that was 100% 'practical', then we should just buy an off-the-shelf CPU card with a more modern CPU and all the goodies built-in (like one of the many 68HC11 boards, for example).

>Is there an objective specification for this board, i.e. a spec indicating what its purpose is >intended to be?

No. If there was, then most of the basic design criteria are automatically 'wrong'. Again, the point (I think) is "6502", not "best design". Our criteria for low chip count, low cost, etc., *are* valid in any case.
The spec could be summarized as "simple, low-cost, 6502" - that's it.

>Why was it decided that bus drivers were not needed? If a cable is to be attached to the >board, that represents significant capacitance. What's supposed to drive that capacitance?

Getting too 'practical' again. I believe that for *most* apps that this board will be used for, 1 Mhz is fine. At that speed, the bus can be (probably) a foot or two without doing anything special. Some (perhaps "many") apps will not use the expansion connector at all.

>I notice there's no Phase-1 or Phase-0 clock, nor is there a RDY signal on the "bus" >you've tentatively designed. I guess this means that you can't run your CPU any faster >than the slowest device on the bus. Since performance is of no concern, why use the >16C550?

As we've discussed before (Mike and I), I tend to agree with him here - the 16550 is perhaps overkill. *But*, if we can't get our hands on 6551's faster than 2 Mhz (I think it's iffy at best, without doing a bulk order from WDC), then the 16550 still makes sense.

>In place of two 32Kx8 SRAMS, have you considered a single 64Kx8?

Unless I'm mistaken, we were only considering *one* 32K X 8, not two. Also, total RAM must be less than 64K, to leave room for PROM and I/O. On a board of this scale, with the likely apps for it, the difference between 32K of RAM and (say) 56K is minor.

>Just to be safe, I'd suggest you consider timing the read and write operations from the >CPU circuit rather than having the I/O circuits do it at each locale.

I think he's misinterpreted something here. If we generate what I'm calling RAM-R/W, OE (inverted R/W), and Chip Selects on-board, then no other logic is needed for most I/O and memory devices.

>If you put a set of more pragmatic strobes out on your

>bus, i.e. MemRd, MemWr, IORd, and IOWr, more peripherals become available, and it's >possible to time them such that all the strobes are comfortably provided with the desired >margins.

I think these are high-end considerations that don't really concern us. And, it sounds suspiciously like an x86 design (we should probably ban him from the group for that ).

>[snip] Many classic peripherals can't do without this data hold time.

I don't see what peripherals he's talking about here - we're not going to be plugging disk drives and things directly to our CPU bus...

>One of the silliest things that makers of the '70's vintage 6502 application boards, e.g. >KIM, SYM, AIM, etc, did was to use address lines as part of the decoding scheme for >their LSI's, e.g. 6530, 6522, etc. This chopped up the memory map, and while they, >probably correctly, assumed that no one would ever really need more than 1K of RAM >space, but the stupid decoding made that a self-fulfilling prophecy. If you simply use an >I/O input to your CPU circuit, the fact that valid addresses significantly preceed the rising >edge of phase-0 will allow the presence of a peripheral to make itself observable by its >assertion of that signal, thereby causing the CPU circuitry to produce IORd instead of >MEMRd.

I don't really follow the relevance of what he's suggesting here. It sounds like he's wanting to convert a memory-mapped-I/O architecture to the x86 style.
And, some of his statements in the above paragraph sound "just plain wrong" to me.

Pete

One more thing, while I'm up on my "high horse":
There's nothing "silly" or "stupid" about the early designs like the KIM-1. They were *not* limited to 1K RAM, but in those days expansion RAM was expensive, power-hungry, and bulky. Those old designs have reasonable flexibility and are fairly simple (simpler than equivalent 8080 or 8085 designs!).
[Ever studied an 8080 design? What a mess!]

How can 65xx or 68xx peripheral chips avoid using the CPU's address lines? Maybe he's confusing x86 architecture with memory-mapped I/O architectures.

All of the basic stuff found on a lowly KIM-1 is still found on the more complex implementations (like C64). If the concepts were seriously flawed, I'd think that companies like Commodore would have changed things - but they didn't. They mostly just added more memory and peripherals to the same basic architecture, and it worked fine!

Whew, I feel better now!

Pete

- Clip

>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.

Yes, it would take an extra chip ( 7474) + three jumpers tp give 4 Mhz, 2 Mhz, & 1 Mhz. To also have a plain cyrstal would require another chip (7404 or 7400) plus some resistor & caps to make an oscillator. The 6502 doesn't work with just a crystal like some other processors.Ted

Quote:

>Here's one idea for how to make a 60 Hz signal:

> Years ago I built a freq. counter from scratch, and so I needed an >accurate 1 Hz time base. I used an MM5369 (?), which runs with a 3.579
> Mhz (TV colorburst) crystal, and it outputs 60 Hz. If desired, the CPU >could be run from a 3.579 crystal, then just use the CPU clock to drive
> the MM5369

I checked in Jameco & Digikey for this part. I know they used to carry it, but it's not available anymore.
Ted

-- snip

>It puzzles me that you're using the 6522 on the board. This circuit is >almost useful, but seldom fully so. In dozens of 6502 applications that I
> turned out in the '70's and '80's, I

> found the 6522 seldom offered an advantage over logic which was >smaller, cheaper, and faster, and that it almost always got in the way of
> doing the job at hand. It was always "almost" but never "right." What's >more, it couldn't drive anything requiring, therefore, that one provide
> buffers which really meant that using them in place of the 6522 was a >better alternative.

The 6522 is simple to interface into the design, has 2 16 bit timers that are quite useful. I've ran into problems interfacing the 6522 to Opto-22 type modules in Industrial Control type applications. It won't directly drive the LED in the solid state relays. It requires a buffer & some jumpers or DIP switches so that each bit can be either Input or Output. A better solution was the WDC W65C29 ( it could drive the LED's directly ) , but it is no longer available.

--snip

>Why was it decided that bus drivers were not needed? If a cable is to be >attached to the board, that represents significant capacitance.What's supposed to drive that capacitance?

I really think would should have buffers on the bus connectors if anyone is going to use ribbon cable to connect the boards. The 6502 really won't drive all the parts on the board and the ribbon cable reliable, even at 1 MHZ.

-- snip

>I notice there's no Phase-1 or Phase-0 clock, nor is there a RDY signal on >the "bus" you've tentatively designed. I guess this means that you
> can't run your CPU any faster than the

> slowest device on the bus. Since performance is of no concern, why >use the 16C550?

The RDY signal really should be on the core 40 pin connector.

--snip

>Just to be safe, I'd suggest you consider timing the read and write >operations from the CPU circuit rather than having the I/O circuits do it at
> each locale. What needs to be considered is the requirement for data >hold time on writes. This is difficult (see the spec's) if you have only
> phase-2 available. Phase-0 leads phase-2 by an interval generally quite >close to the hold time requirement for most devices. If you put a set
> of more pragmatic strobes out on your

> bus, i.e. MemRd, MemWr, IORd, and IOWr, more peripherals become >available, and it's possible to time them such that all the strobes are
> comfortably provided with the desired margins. If you create your >memory and IO write strobes by gating the memory and IO identification
> signals with PHASE-0 (the input clock) it will lead the equivalent read >strobes, similarly generated by gating those identificaton signals with
> PHASE-2. Many classic peripherals can't do without

> this data hold time.

Maybe for those xx86 parts (ugh : ( ), but all the 65xx peripherals use Phase 2. I think we shouls be alright at 4 MHz.

-- snip

>One of the silliest things that makers of the '70's vintage 6502 application >boards, e.g. KIM, SYM, AIM, etc, did was to use address lines as
> part of the decoding scheme for their LSI's, e.g. 6530, 6522, etc. This >chopped up the memory map, and while they, probably correctly,
> assumed that no one would ever really need more than 1K of RAM >space, but the stupid decoding made that a self-fulfilling prophecy. If you
> simply use an I/O input to your CPU circuit, the fact that valid >addresses significantly preceed the rising edge of phase-0 will allow the
> presence of a peripheral to make itself observable by its assertion of >that signal, thereby causing the CPU circuitry to produce IORd instead
> of MEMRd. That can be a really handy function.

I think he's probable referring to the fact that the KIM-1, etc didn't fully decode the address bus resuting in mirroring and areas of memory you couldn't use. What we're using doesn't have this "problem". We don't have the seperate I/O and Memory space that the xx86 parts have. I don't see that we have a problem.

Ted

Regarding signals on the 1st 40-pin connecter:

>Vcc and GND

>A0-A15

>D0-D7

>R/W

>PHI2

>/IRQ

>/NMI

I suggest that the remaining 10 signals be:
"RAM-R/W".
"OE" (R/W inverted).
3 of the 5 unused 1K chip selects.
RESET.
Three of the 8K chip selects covering the range: $8000-$DFFF.
RDY.

Including those two 8K CS's means that memory can be expanded (either RAM, PROM, Flash, etc.) without any off-board logic at all. If that's all you want to add, you could even make a real cute little daughter card that plugs directly into the 40-pin header.

Pete

I agree with your selection of signals for the primary 40 pin connector. However, I have one question. I usually make "OE" or "RD" by NANDing PHI2 and R/W. R/W is only valid when PHI2 is "High". I guess what you call "RAM-R/W" is what I call "WR", which is PHI2 NANDed with Inverted R/W. How do you generate your "OE" and "RAM-R/W" signals.
Ted

>I'm sure it's not bug-free, but it does several useful things.

Also, it's a "65xx"-series part, which has some appeal for me, whether it works very well or not. If the goal was to make something that was
100% 'practical', then we should just buy an off-the-shelf CPU card with a more modern CPU and all the goodies built-in (like one of the
> many 68HC11 boards, for example).

Newer, maybe, but not necessarily more modern . It has more onboard "stuff", but there are versions of the 6502 that do also. Like the 65C134, 65C265 by Western Design Center and the 740 Family & 37700 Family by Misubishi. Rockwell also had controller chips, but they're no longer available.I guess we'll look at that (65C134) for the next board.

>Getting too 'practical' again. I believe that for *most* apps that this board will be used for, 1 Mhz is fine. At that speed, the bus can be
(probably) a foot or two without doing anything special. Some (perhaps >"many") apps will not use the expansion connector at all.

I disagree on this one. I think we should have bus drivers in the design. It'll be about three chips. You can leave them out & jumper across if you don't want to use them, but if you you have two or three boards on a ribbon cable, I think you'll really need them. The outputs ( Data, Address, Control) of the 6502 really can't drive that much. I don't believe I've seen a design that was designed as an expansion bus that didn't use drivers (ok, the KIM-1, but I used buffer on the expansion cards I built) to go off the CPU card. I think you'll be asking for intermittents that will be hard to fix.

>As we've discussed before (Mike and I), I tend to agree with him here - the 16550 is perhaps overkill. *But*, if we can't get our hands on
6551's faster than 2 Mhz (I think it's iffy at best, without doing a bulk >order from WDC), then the 16550 still makes sense.

The last info I have from WDC, they no longer make any 6551's. The 16550 is the best solution, now.

>I think these are high-end considerations that don't really concern us. And, it sounds suspiciously like an x86 design (we should probably ban
> him from the group for that ).

I sure agree with you here.

I think we should proceed on the direction we're going.
Ted