If we drop the LS145 scheme, here is another suggestion that would be somewhat more flexible than 9.14 (7.1):

-Use a '138 to decode eight blocks of 8K each, but the lower four decodes would go off the board (not to RAM).
-Do the RAM with (NOT A15).
-Add a quad AND gate device, and use it to make four different 16K blocks from the various outputs of the '138. Or, use it to make two 16K blocks, and one 24K block.
-Use a 2nd '138 to do the I/O decoding from one of the 8K blocks.
-Now, depending on which of the above outputs was used, it would be possible to get 8K or 16K (or maybe 24K) blocks when needed.
-To give some flexibility, leave a space on the board for jumpers to connect the CS for RAM and PROM -- each could be connected to one of several decode outputs. Do not connect either of the memory devices directly to a decoder - a jumper would be required. All of the decode signals would also go off-board.
-Do a soft-ground of one of the '138 enables, so that the whole decoding scheme could be turned off by an expansion board.

The above scheme would require 3 chips, plus one more inverter. Maybe there would already be a spare inverter from something else??
By using S-TTL instead of LS-TTL, it would run reasonably fast (if needed). [ Can a 65C02 drive S-TTL inputs? - Come to think of it, HCT devices would be the way to go... ]

Pete

One correction to what I said in 9.16:

I didn't mean to say "do the RAM with (NOT A15)".
Rather, that would be *one* of the jumper-selectable options for the RAM.

So, if you only want 8K of RAM, then use '0' output of the '138. Then the 1, 2, and 3 outputs would be freed up to decode things on an expansion board.
Or, if you want 16K of RAM, then use the AND output that is made from blocks 0 and 1. Then the 2 and 3 outputs are still free.

For 32K RAM space: instead of needing an inverter, sacrifice the AND gate on blocks 4 and 5, and use it to combine the two lower 16K blocks into a single 32K block. The downside here is that the 32K select would come from the '138 *plus* two more gate delays, while some other selects would be just the '138 delay - is that a problem? In some cases, there could be a measurable overlap of some select signals. Using an HCT02 for the AND gates, the overlap (in theory) would be 15-20 ns or so. Is that enough to worry about?

Pete

I'm going to answer my own question from 9.17:

[BTW, that should be HCT08, not HCT02.]

I'm thinking that overlap of CS signals is not such a bad thing. In the VIC-20 schematic, the SRAM CS starts with an LS138, then goes through two gates, then through another LS138, then through one more gate! On the same bus, there are other CS signals that come directly from the first LS138.

It certainly won't affect the RAM, since we are using the RAM-R/W signal, which prevents writes from happening until the second half of the cycle, and by that time the address and CS stuff has had time to settle down.

Anyway, I'm thinking that the scheme in 9.17 is basically sound, if we decide to go with it.
The LS145 method is still simpler, and more flexible.
At 4 Mhz or less, I think either would work just fine.

Now that I've been talking to myself for the last couple of days, does anyone else have any input?

Pete

Here's an e-mail I got today from SLOHANI:

Murphy has struck and I cannot log on to my internet server. Could only connect via this shell account. Could you help post my message to the forum in reply to message no. 13 of discussions(PCB Project). The discussions have got interesting and I wouldn't like to delay them.
Thanks a lot!

TTL/LSTTL totem pole outputs have the following 'Output High' characteristics:
Voh = 3.5V+ at no load current
with a slope of ~150 ohm impedance
Ios (short circuit current) which is a measure of the
ability to charge parasitic capacitance -
25 mA at Voh = 0v
10 mA at TTL high threshold of 2.4V.

As per the TTL specs -"In the HIGH state, a totempole output presents a low impedance and is capable of sourcing considerable current. This peak transient current shows up as a current spike at the Vcc pin". Pl. refer TTL/LSTTL gate Output HIGH characteristics.

With a 2K2 pull up resistance to Vcc, short circuit
current Ios would work out to 2.3 mA at Voh = 0V and 1.2 mA at Voh = 2.4V. The output impedance is of course 2K2 as compared to 150 ohm for totem pole output.

Examination of TTL rise times with a scope will verify the
low totem-pole output impedance. Such gates are designed to generate rise times specified in the data sheets at typical board parasitic capacitances. The case with OC gates is of course different and I have given a calculation of propagation delays earlier.

If you insist, using a 74LS145 will work at upto 4Mhz without problems. I suggest that:
- pull ups of 1K5 are used
- pull up resistor is close to CS pin of IC
- don't cascade LS145s.

The purist argument still holds - why have a hardware limitation in the circuit ;-}

This of course requires syncronising signals RAMR/W and OE to gate all write and bus read operations(these CANNOT be OC).
- RAMR/W = (Phi2 NAND (NOT R/W))
- OE = (Phi2 NAND R/W)
(I used a 3 input NAND with the 3rd input tied to RESET pin of uP)

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

>If you insist, using a 74LS145 will work at upto 4Mhz >without problems.

I agree - Thank you!
BTW, I consulted my office-neighbor on this issue (he has more hands-on hardware experience than I do). He agreed that OC will not be a problem at 4 Mhz, even though it's not an "approved" practice in general. He said the risk is not so much in speed problems, but rather in current spikes (undershoot, overshoot, etc.) - but this only becomes an issue if you try to run it too fast, with small-value pullups.
At high speeds (say 10 Mhz), the prop delay of things like LS138's is just as big a concern (i.e., an LS138 is simply not fast enough unless you have super-fast memory).

If the impedances are matched, an OC-based bus can be made to run *faster* than a normal totem-pole-based signal -- the bus signals have both a pullup and a "pull-down" on them, and each is in the 200 ohm range (roughly - I forget the exact values). The SCSI bus works this way, and it supports 10 Mhz speeds on a 3 meter cable! The down-side? This approach uses a LOT of power at all times.

>I suggest that:

>- pull ups of 1K5 are used

>- pull up resistor is close to CS pin of IC

>- don't cascade LS145s.

Agreed on the above. Pullup values will be a user's choice; if there is no great concern for current consumption, then 1K is certainly fine. Running at slower speeds (i.e. 1 Mhz), something like 4.7K has worked fine for me, and this should be considered by someone planning to run from battery power. The 65C02's current consumption is also closely related to clock speed.

>The purist argument still holds - why have a hardware >limitation in the circuit ;-}

There are *always* hardware limitations - I'm sure that between the two of us, we could make a long list...
This particular limitation would be there for a reason: to reduce parts count, and at the same time give increased flexibility in the memory map.

That said, I noticed in the "spec" on 6502.org that LS245 bus buffers are now a part of the design. It's OK with me, but I wonder if we're moving away from the 'simple' requirement? To buffer address, data, and control signals will require 4 chips, and 3 of them are 20-pinners. I still suggest that the buffers be an expansion-board feature. If we use HCT devices wherever possible (instead of LS), then some limited expansion can be done without buffers. For example, it should be no problem to piggy-back a 2nd board PC/104-style, since that approach would keep lead lengths to a minimum.

>- RAMR/W = (Phi2 NAND (NOT R/W))

>- OE = (Phi2 NAND R/W)

>(I used a 3 input NAND with the 3rd input tied to RESET pin >of uP)

I agree this is a good idea, since we will have battery-backed SRAM.

Pete

The target max speed of the board was agreed in earlier discussions as 4 MHz. This was a practical limitation created by the speed of the chips themselves, if we go higher then greater issues must be faced which will require additional circuitry. Personally, I still like the '145 idea and it will work very well for our situation. I fine Ted's solution acceptable also but not as nice. However, if the group feels this board should run faster than 4 MHz, then the address decoding and other issues need to be carefully considered. I'm voting to stay with this speed limitation because our goal here was to make a nice board for a general audience. Many people will probably not even run it at 4 MHz. Perhaps a super-fast board should be another project. Or, am I wrong? We seem to keep going back on forth on this speed issue and some decisions need to be made. Pete, about the bus drivers. I think that this board has grown much bigger than when we first agreed not to include the drivers. Ted suggested previously that we add them. After examining how big the board has grown (especially with the addition of the second VIA) I think the 74LS245s aren't going to make the board any larger, or not by much. Considering we also have a nice expansion bus system going here, it seems like a good idea to have them on board. What do you think? Nothing's concrete.Speaking of the bus, I'm still trying to assign the pinouts for the expansion connectors. Before we can finish that, we need a memory map. I put up a preliminary one. Everyone please go to the PCB Project Page at http://www.6502.org/pcb.htm and let me know if it is okay.Keep up the good work guys.

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

>However, if the group feels this board should run faster >than 4 MHz, then the address decoding and other issues need >to be carefully considered.

I agree 100%. To go significantly faster, some serious compromises would have to be made, including:
- Only simple address decoding, or a PAL-based scheme.
- Fast memory devices.
- Short bus lengths - real limited expansion, without using special bus drivers and more careful layouts.
- Availability of 65C22's that go fast enough.

>Perhaps a super-fast board should be another project. Or, am >I wrong?

I think it would be an "interesting" project, but not a very "useful" one - what would I use a fast 6502 board for, given that it would likely have very limited expansion possibilities? It seems like raw speed would be it's only redeeming feature...

I think a 65SC134-based board would be a great "2nd project". Perhaps with an emphasis on small size and low power consumption (ideal for robotics projects!).

>Pete, about the bus drivers. I think that this board has >grown much bigger than when we first agreed not to include >the drivers.

>[snip] I think the 74LS245s aren't going to make the board >any larger, or not by much.

>[snip] it seems like a good idea to have them on board. What >do you think?

That sounds fine - count me in. Using HCT245 devices will keep the power consumption down, as I found on my VIC-20 expansion. I assume that we would want the buffers to be right next to the CPU (that is, NOT just for expansion devices). That way, no extra logic is needed to decide when to enable the data bus buffer.

>Everyone please go to the PCB Project Page at >http://www.6502.org/pcb.htm and let me know if it is okay.

Looks fine to me.

Pete

Thanks Mike for posting my email.

I'm in agreement also about the current state of the design. We are not creating an ATX based 6502 motherboard that will work as a consumer PC. We are building a generic, simple 6502 board. We need to wrap up the issues, keep things simple, and if people want something more, they can build their own design with wire wrap or point-to-point soldering.

I think we need to document the different design decisions made. Write up what you would have to change to make it run at 10 MHz or more, so that it can not just be a board for people to build, but an example of design that people can use to see how real computer hardware (instead of abstract stuff in classes) works.

Hi guys,

There's been a significant slow-down in the messages on our forum lately, and I'd like to apologize because I feel it is mostly my fault for dragging my feet getting some of these details rapped up. I've been very busy lately. I now hope to do some work on the www.6502.org site a bit (suggestions?) and this project as well.

I'd like if everyone could please revisit the specifications page at http://www.6502.org/pcb.htm.

You'll notice there is now a memory map, which will be considered finalized if there are no arguments. The only feedback I've heard so far was from Pete who liked it.

Now, the first ("core") expansion connector has chip select lines for three of the 8K decoded memory blocks and also three of the I/O blocks.

Memory select lines are marked as "MCS" (Memory Chip Select).
I/O select lines are marked as "ICS" (I/O Chip Select).

I have placed these selects on the core connector:

MCS3 $6000-7FFF "Reserved for SRAM"
MCS5 $A000-BFFF "Future Expansion"
MCS6 $C000-DFFF "Reserved for ROM"
ICS3 $8C00-8FFF "Future Expansion"
ICS4 $9000-93FF "Future Expansion"
ICS5 $9400-97FF "Future Expansion"

The remaining MCS and ICS selects have been placed on the second connector.

I need to know if everyone likes this arrangement, and if not what changes you would like made. Also, I need to know what signals you'd like to see placed on the second connector and where they should go.

Thanks and keep up the good work!

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

Here's some things for the 2nd connector:

GND - at least two.

Phase 0 clock (if the onboard clock is not stuffed, then this can become the main clock input).

Phase 1 clock.

SYNC.

Set Overflow (has anyone ever tried using this signal?).

LS145 disable (so that all onboard decoding can be turned off).

Any signals that are used to enable the onboard bus buffers, so that it would be possible to use the same signal on an expansion board.

Duplicate the serial port signals on this connector, too - it might be handy for some peripheral that would be mounted on an expansion board (?).

The CA1/2 and CB1/2 signals from one (or both) of the 6522's, especially the ones that can be inputs for interrupt sources. They can be used as separate interrupt signals by peripherals.

Pete

it's a tradeoff between more logic and less performance. The 'LS145 sinks LOTS of current, on the order of 40 ma IIRC, suitably for sinking di)it-selects (e.g. the common cathode of an LED display digit.

However, if you use the '145 as an address decoder, it wil select 8 blocks of equal size. If one of your blocks is an 8Kx8 ROM and another is a 4K block consisting of two 2Kx8 SRAMs, you can see that the OC saves a gate and the associated delay by allowing you to tie four of the outputs together to select the ROM, yet use two of the remaining four to select the RAMs.

The prop. delays will not be so long, and the currents will not be so large, that it has much impact on your system. If you're designing a new board, you should probably use GALs rather than these costly historical artifacts. A GAL16V8-7 costs about a dollar and has about 7 ns prop delay ragardless of how complex (within reason) a decoding function you have. Consequently, you can save an area of board the size of a playing card and costing $5 with one 20-pin part, costing $1, generating 8 precise decodes of various resolution. What's more, you can change the contents, as they're eraseable, and, you can change the programming in response to demands of PCB routing, with no impact on timing or loading.

Uli

I'm curious about what the objective spec for this hobby project is. In case you are unaware, an objective specification is essentially a list of the preliminary REQUIRED features.

It's been a long time since I last looked at the web site for this project, but I'd make a couple of suggestions if nothing has been built so far, at least to the extent of comitting it to PCB.

(1) use a board form factor of 80 x 100 mm. Why? that's the largest board that you can handle with the reasonably effective EAGLE v 3.55 schematic capture/PCB routing package available for free from <www.cadsoft.de> That will provide a tool everyone can use at no cost, a portable medium which will fit in email so various participants can exchange drawings with ease, and a ready means to edit the PCB so it can be manufactured, eventually.

(2) design for maximal flexibility. This means that you should use NO TTL! No LS, no S no L . . . CMOS only! Further, you should use "family" logic only for data transport devices, using programmable logic for everything else. That way, if you need to change something, odds are it can be accomplished in a programmable device. This will also make your board easier to route, as it put the logic where you need it and eliminates the need to share a gate pack between logic on opposite ends of the board. As for WHICH programmable logic to use . . . the XILINX 9500-series offers FREE software to do your design, LOW COST, and ready availability through DIGI-KEY, and these rather largish parts drive 24 mA essentially from every pin. What's more, you won't have to use expensive programming hardware, since the devices are programmable "in-situ" meaning you program them on the board using a circuit you can build yourself from a XILINX-provided FREE schematic into a circuit that attaches to the printer port of your PC and does the deed with some free software. Another interesting flexibility of these devices is that you might decide to build your "too-slow" peripherals yourself in this abundantly fast technology, based on the old data sheets. In fact, I'd be inclined to build the whole board with three connectors and one programmable logic device containing the CPU, RAM, peripheral functions, and a port to a PROM. All you'd need is a crystal and some passives. Now, YOU might not want to go that far. Perhaps just a couple of these CPLD's and a processor, RAM, and ROM would do it, though.

(3) Remember, it's a MICROcomputer. It should be small and light, potentially operable, for a while at least, from a battery.

Now, you may not want to do things this way, but doesn't it give you food for thought?

Uli

SO (set overflow) is potentially useable, though it's awkward because, though it's externally set, it requires code to monitor, by polling, since there's no interrupt generated, and clear the bit before it causes a problem.

Sync is really no help unless you are using a front-panel or even simpler circuit. These are unnecessary if you have a decent debug monitor in ROM.

If you're building a bus-oriented system, the '145-disable should take the form of an address-and-control disable. This is not as simple as it seems, because you have to decide quite early on how you're going to implement it. That will effect how it's capable of being used. One option might be to separate address and control enables, and it would probably be nice to have a data disable as well, just in case you ever neet to "jam" an instruction (front-panel-style) to see what the system does under certain circumstances.

I have been using 6502's since the mid-'70's when they were introduced, and have never "needed" a front panel. I've also only once built a single-step/single instruction circuit.

The single-step circuit is quite a bit more involved than the single instruction circuit, though both are about the same, superficially. SInce the 6502 is not static, you can't just stop him, so the easiest way to monitor single steps is to feed them into a FIFO. Some other register set can be used, but a FIFO with its outputs fed back to its inputs once the sample is taken is pretty easy. It lets you step repeatedly and sequentially through the data and addresses without losing them. Small fifos are pretty rare these days, though.

By the way, have you fellows considered the Samsung AHCT line of family logic? It's faster than HCT or LS/ALS, yet it's CMOS. It's also pretty cheap, though family logic is going away.

ULI

Your suggestions are great (keep it up), but some are beyond the intended scope of the project (using GALs, for example).
Parts need to be cheap and readily available to a hobbyist who doesn't know what a GAL is.

Pete