I guess we're still not sure about the bus structure,yet. But I have a connevtor I'd like to recommend for the stacking bus. It is made by Aries Electronics, Inc. Their website is http://www.arieselec.com. The connector is Series 9X5 Pres-Lok Stackable Connector. It's available in 1 thru 20 single row and 2 thru 40 dual row. There is Tin & Gold plating available. The spacing between boards is .500 " or .600". There is a solder tail available for the bottom board in the stack, also.

Take a look at at and offer comments.

Concerning the 50/60 HZ signal some are requesting. The simplest way is to us a 8 Pin PIC. The 4 MHZ clock for the 6502 could be used as the clock. It could have a Jumper to select 50 or 60 HZ Output. There are no external passive components. I know we don't want any special custom parts, but this is a common part now. I have a programmer for the PIC parts. We could supply one with each board. They're only about $2.00.

Ted

That's an intriguing idea, to use a PIC to generate a fixed 50/60 Hz signal. That would give crystal-control stability, plus the option of changing it. Perhaps a couple of other "useful" signals could be synthesized at the same time; such as a power-up reset for the 6502? Maybe the PIC needs an external reset of it's own, though???
Something to think about...

As for that connector: I haven't looked at the one you've suggested; but is it commonly available?
Mike and I had talked about a normal Berg-type header because a matching cable can be found anywhere, often for free.
If the connector you're suggesting has pins on 0.1" centers, then either one will work - the user can solder in whichever connector they like best.

Pete

The PIC doesn't require an external reset. I had thought about using a Maxim MAX691 to generate the Reset and also take care of the power off backup of the Ram using a large value ( ,47 or 1 F) capacitor.

Yes, the connector is on 0.100" centers like the Berg connector. It has the advantage of not needing the ribbon cables. I think this would help at higher clock speeds. Digikey is an Aries distributor, but they don't show this connector in their catalog. I'll see if I can run down a source for them. The price list I have is from 1991, the price for the 40 pin ( 2 x 20 ) is $3.31.
Ted

I checked out the current price on the connector & it's about $6.00 dollars each, now. The minimum order is $100.00 and about 6 weeks delivery. Not astock item. It would be nice, but ?? The board layout will work with it or the Berg type connector so it would be an option, if anyone is interested.
Ted

Happy new year everyone!

Our discussions of the printed circuit board project have considerably slowed down due to the holidays. I've reread many of the messages and it seems that we have a great deal of this thing ironed out. In the next few days I'm going to go over everything again, update the web page and our latest specifications, and we can then fill in the gaps of our design. So, keep visiting the forum and I'll hope to give an update very soon.

I'd also like to take this opportunity to express how pleased I am with this forum and the website. The response to both has been more that I would have ever hoped and I've met a great bunch of enthusiasts. I'm hoping that these coming months will lead to large expansion of the website and completion of our first prototype for this project. Keep your fingers crossed and keep up the good work guys.

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

I have recently designed a 65C02 based Single Board Computer.
Here are my specs:

Microprocessor
65C02. Clock speed upto 4 Mhz.
A clock control connector is available for edge- by edge

clock control for experimentation.

Address Decoding

Here I disagree strongly in using a 74LS145.This is because
a OC chip produces slow edges(L->H). An address decoder
should be fast so that there is min. overlap of select

signals.

I use a 74LS139 decoder and discrete logic to generate the
following memory map:

0000 - 7FFF (32K) - RAM 62256
8000 - 9FFF (8K) - External select signal(Exp)
A000 - BFFF (8K) - System I/O - see below
C000 - FFFF (16K) - E(E)PROM 27(8)256

The 'System I/O' is further split into:
A000 - A7FF (2K) - External A
A800 - AFFF (2K) - External B
B000 - B7FF (2K) - STPLED
B800 - BFFF (2K) - System I/O Chip (VIA/RIOT)

(The STPLED out is connected to a LED via a 1K resistor.This

serves as a simple output port:
Here: STA- $B000
JMP Here )
The entire address decoder is disabled at RESET and by a master signal.

Bus:
Unbuffered bus connects the following on the main board :
CPU 65C02
RAM 62256
E(E)PROM 27(8)256
PIA/RIOT/VIA chip
Expansion Connector 64 pin

Thus only one dedicated I/O chip of 6500 family is used.

5 lines of the I/O chip are used to form a SPI interface on the peripheral side:
DOUT
DIN
SCLK
CS
CONTROL
The CONTROL line drives a MAXIM MAX 349 SPI MUX chip and MUXes
the CS to 4 SPI devices and also provides 4 general purpose I/O lines.I use MAX 3100 UART- 230Kbaud on one of the SPI ports (also IrDA compatible) and Serial ADC/DACs on other ports.

The SPI port based peripheral card is universal and can be

attached to any microprocessor/microcontroller independent of
its bus speed.A lot of SPI EEPROMS, RTCs etc are available.

I will make one of the SPI ports fully opto-isolated for use as a interface with other controllers

Misc:
The entire RAM is battery backed with MAX 1691 chip. This also
provides RESET signal,powerfail NMI and watchdog functions and has a builtin Li battery.

Since I use battery backed RAM, RAM-R/W and OE signals are
gated via RESET.I use a 3 input NAND gate HCT10 type so that the signals remain unasserted at RESET and are valid right from Vcc=2V+.

The upper RAM (16K) can be made 'write protect' by hardware(jumper)- it is assumed to be storing OS patches.

A single - stepping circuit based on SYNC signal (single stepping in LOWER RAM) is provided for monitor assisted debugging.

I also use the I/O chip for providing a 6 digit hex display and a 21 key scanned keyboard.

>Address Decoding

>Here I disagree strongly in using a 74LS145.This is because

>a OC chip produces slow edges(L->H). An address decoder

>should be fast so that there is min. overlap of select

>signals.

Why would an OC output automatically produce slow rise times? Or, why is a totem-pole output automatically faster?
At the speeds we are talking about, I don't believe that there's a significant difference. With OC, you can use smaller pullup R's to speed things up (rise time at least, maybe not fall time).
To gain a little advantage, a 74S part could be used, but I doubt that it would be needed in the 4 Mhz range.

It's true that OC parts are generally intended for things like display-drivers, where speed is not important, but again, at the speeds we're talking about, I don't think it matters.

Pete

>Since I use battery backed RAM, RAM-R/W and OE signals are

>gated via RESET.I use a 3 input NAND gate HCT10 type so that >the signals remain unasserted at RESET and are valid right >from Vcc=2V+.

This is a good idea. I think we should consider doing this in our design.
It might require one more 14-pin device altogether than before (since there are only 3 gates in the xx10 package, instead of 4), but it might be good insurance against corrupted SRAM during power up/down.

What do we think?

Pete

I tried to do a little research on rise/fall times for OC outputs. I didn't find anything real specific in the databooks - they only quote propagation delay.

However, for devices with OC outputs, their prop delay numbers *do* include the OC output driving a particular load (such as 2K ohms and 45pf capacitance). Comparing an LS138 with an LS145, worst-case in the data books say that the LS145 has an extra 15ns delay or so.

It's unknown whether that extra delay is because of the OC output, or because the entire device is 'slower' (since it's usually used for driving display lamps).

They do say that the prop delay is the same for L-H and H-L, which implies that the outputs will not overlap.

In any case, it is clear that using a smaller pullup R will speed up the rise time - it can probably be made *faster* than a non-OC device (if you don't care about current consumption).

The *real* disadvantage of OC devices for an application like ours is:
- The pullup Rs are required.
- A "low" output will use measurable extra current (about 5mA with a 1K pullup) compared to a normal output. But, we would only have one output low at a time, so it's not a big deal. At slow speeds, use a larger pullup to save power - at higher speeds use a smaller pullup to get faster rise times.

Pete

The delay in OC outputs comes from the parasitic capacitance of the board.You need to compromise between power drain and propagation delay. A low impedance totem-pole/push-pull output is more elegant and improves bus-management.

I want to keep all signals fast,low impedance and clean for future expansion.Select signals need to be available on the Exp connector to enable bus drivers(a must!!) on expansion boards when selected in the memory map.

I don't think 74LS145 will satisfy the purists.

>The delay in OC outputs comes from the parasitic capacitance >of the board.

Hmm?? Do you mean the extra 'wiring' associated with the pullup R and such? If this were the case, I think the data books would say so (they would want to blame the slowness on something outside of their chip, if that was possible).

I would be more inclined to believe that the difference is in the high-current output transistor that is used in an OC output - the LS145 can sink 80mA, I believe (it has a 'fan-out' of 250!). The transistor would be physically large, and have greater inherent capacitance.
In any case, it doesn't matter (to this project) - a smaller pullup R will easily overcome the extra C, at the expense of current consumption.

>You need to compromise between power drain and propagation >delay.

Yes. But at 1-4 Mhz speeds, the compromise is very easy. With projects I've built so far (3 of them), I've used 4.7K pullups and run at speeds of either 1 or 1.8432 Mhz. All work fine. Since only one of the outputs is low at a time, there is only a 1 mA current drain added by the OC outputs.
If it were running at 4 Mhz, then *perhaps* I would need to go to 1K pullups, with a 5 mA drain. No problem!

This "compromise" can also be viewed as "flexibility".

>A low impedance totem-pole/push-pull output is more elegant >and improves bus-management.

Agreed that it's more elegant (simpler). I disagree that it would improve bus management. It locks you into the capabilities of whatever drives the bus, and an LS138 or LS139 is not a "bus driver" type of device. You cannot change the bus characteristics by changing a pullup R, because the 'pullup' is fixed inside the device.

>I want to keep all signals fast,low impedance and clean for >future expansion.

This board has never been intended to be an 'ultimate' design.
- The signals will be "fast enough" for the purposes outlined originally by Mike.
- It will certainly be expandable, within some reasonable limits (true with any bus).
- Since the board (currently?) will not have on-board bus buffers, it is expected that a 'major expansion' would include buffers on the first external card (as you said below).

>Select signals need to be available on the Exp connector to >enable bus drivers(a must!!) on expansion boards when >selected in the memory map.

Agreed. And, we've discussed in earlier replies that there should also be a pin to disable the on-board selection logic altogether (by using a 'soft ground' on the LS145's 'D' input), so that an expansion board can "take over" the entire address space if needed.

>I don't think 74LS145 will satisfy the purists.

I think that's OK - a purist will want to change *lots* of things in this design, right?. There has never been an intention to do a 'pure' design, but rather something that is simple and functional. A 'purist' solution would be to use actual bus-driver chips for all signals that go off the board.

The bottom line is that the LS145 approach gives the most functionality and flexibility with the lowest chip count (I think).

As you can tell, I'm rather "defensive" about the LS145 issue, mostly because I suggested it . I've used it on 3 successful implementations so far...

Pete

The parasitic capacitance to consider is:
i- Chip lead capacitance (5-7pF)
ii- Board parasitic capacitance
To give an idea of the board parasitic capacitance,the 65C02 outputs are designed to drive 1 TTL load at 130pF board capacitance. Thus 5-6 LSIs can be bussed without problems.

The 74LS145 data sheets give L->open timings because there is no H state for a OC device.The tpLH if specified considers the chip lead capacitance only.

A conservative estimate of 25pF parasitic capacitance and 2.2K pullup gives T=RC of 55nS. Take 1.5 -2 time periods depending on nature of input and the delay is of the order of 100 nS.Note that this is EXTRA delay over the normal delay of a decoder. Of course this will not matter at upto 4 Mhz as long as RAMR/W and OE are used to gate Write and Enable functions but does not fit in with the discussions of 14Mhz clock and 20nS RAMs.Moreover this gives an overlap between L->H and H->L states of the decoder.

When one considers an Expansion board, the select signal will serve to control the data bus buffers on the Expansion board.The bus timing requirements for the Exp board devices will then vary with those given in the 65C02 datasheet.A Schmitt trigger gate(buffer control or logic) is very fussy with such rise timings.

Elektor designed a Junior Computer(similar to KIM-1) in early 80s.They used 74(LS)145 decoder in main board(one chip for all decoding).The outputs were pulled up by 3K3. Worse,The RAMR/W was generated by a 74LS01 NAND OC gate pulled up by 4K7. This board gave all sorts of RAM access problems. In book 3 ,Elektor asked to change the pull up to 820 Ohm to effectively 'buffer' the RAMR/W signal.The clock speed of 6502 was only 1 Mhz and the board was a compact double sided PTH!!If you try to implement the single stepping circuit of this board on your design using fast decoders, you will have to gate the decoder select with phi2 signal because you also have to consider the time that the address bus is stabilising.

I would still suggest a 74LS145-less design.

>The parasitic capacitance to consider is:

>i- Chip lead capacitance (5-7pF)

>ii- Board parasitic capacitance

But these factors exist with *all* device types, not just OC.
OC adds a little extra C, but again, it's trivial at these speeds.

>The 74LS145 data sheets give L->open timings because there >is no H state for a OC device.

No, as I said yesterday, the data books give prop delays for outputs going both ways, and the values are the same (50ns max). A L->open timing is not meaningful since the pullup R would be 'infinity', so in theory the rise time would also be infinity. Looking at 3 different maker's data books, they all specify the timings with a certain pullup R, and a certain C load.

>A conservative estimate of 25pF parasitic capacitance and >2.2K pullup gives T=RC of 55nS. Take 1.5 -2 time periods >depending on nature of input and the delay is of the order >of 100 nS.Note that this is EXTRA delay over the normal >delay of a decoder.

Even assuming that the above analysis is correct (I don't think so, because the maker's prop delay spec has already taken it into account), a normal LS-TTL totem-pole output has the same problems! The pullup R still exists inside the chip, but it's in series with another transistor - it could be argued that there is additional switching delay added by the extra transistor (there is, but I'm not sure how significant it would be).

>...but does not fit in with the discussions of 14Mhz clock >and 20nS RAMs.

If we wanted to run that fast, the entire decoding scheme would have to re-thought. Even a single LS138 would probably not be fast enough. Decoding and memory access *combined* would have to be done in about 35ns.

The bottom line is still that using an OC decoder does not *significantly* change the timings.
I think the flexibility offered is well worth it.

>Elektor designed a Junior Computer(similar to KIM-1) in >early 80s.They used 74(LS)145 decoder in main board(one chip >for all decoding).The outputs were pulled up by 3K3. >Worse,The RAMR/W was generated by a 74LS01 NAND OC gate >pulled up by 3K3. This board gave all sorts of RAM access >problems. In book 3 ,Elektor asked to change the pull up to >820 Ohm to effectively 'buffer' the RAMR/W signal.

I would suggest that they had some other fundamental design problems... Why did they use OC for RAM-R/W? Maybe they were trying to do 'cycle stealing' on their RAM?
I can't believe that OC alone was their problem.
Are schematics available on the web for this board?

>I would still suggest a 74LS145-less design.

I will go along with whatever the group decides...

Pete

Here's the problem: the '145 provided a very elegant address decoding solution. It allowed for a simple design with easy expandability. Say we drop it, what do you suggest the we replace it with?

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

re: 9.14
If the '145 idea is dropped, then I would suggest doing basically what TEDM9 suggested back in note 7.1.
The highlights are:

- Use (NOT A15) for the RAM decode. (32K)
- ROM decode would be (A14 NAND A15). (16K)
- Make an 'I/O' signal from (A15 NAND (NOT A14)).
Use this signal to enable an LS138, thus making eight I/O
decodes of 2K each.

A single LS00 and LS138 would do it.

What we would lose is:
- The first 32K is always RAM, whether you need it or not, and it must be a single device (without additional logic).
- The top 16K is always PROM, and it must be a single device (without additional logic).
- There is no obvious way to disable the RAM or ROM decode (it would still be possible to disable the I/O decode). Expansion boards would have to 'live with' the memory map as-is. The I/O space would still be flexible.
- We wouldn't be able to connect a second board (of the same etch) to the first board, and then put additional RAM or PROM on that second board. A second board would only be useful for adding two more 6522's.

So, if we go this way, I'll be sad , but I'll live with it...

The next best thing would be to add 2 or 3 more chips, and implement some more flexible decoding logic (without the evil OC outputs ).

Pete