i was designing a new 6502 system in which the CPU's data bus is directly
connected to a 74LS245 data bus buffer. the buffered data bus is then
distributed to the rest of the system from the 74LS245.

the following signals have to be generated:
- RD\
an active low signal that will be connected to a 62256 RAM's OE\.
this signal will also be used everywhere an RD\ is needed.

- WR\
an active low signal that is connected to the 62256 RAM's WR\.
this signal will also be used everywhere a WR\ is needed.

- Data Bus Buffer Enable
this signal will be used to enable the 74LS245 and remove the buffered
data lines from tristate condition during every cycle.

- Data Bus Buffer Direction
this signal will simply be a buffered version of the CPU's R/W\. in
other words, the CPU's R/W\ will determine the direction of the
74LS245 data bus buffer.



Questions
- my first question was this:
RD\ is negated as soon as p2 goes low. so, the RAM's OE\ will also
be negated as soon as p2 ends. now, the CPU latches in data from RAM
on the falling edge of p2. the CPU has a requirement that the data be
held valid for the minimum hold time after p2 ends.

therefore, won't there be a problem if RD\ is used to drive OE\?
what else can be done to ensure that the data is held valid for the
hold time required by the CPU? is there some guaranteed, foolproof
way to solve the problem that does not rely on gate propagation delays
and bus capacitance?

- second question:
a similar situation exists for WR\. WR\ will start being negated with
the falling edge of p2. after the data hold time from the end of p2,
the CPU will remove the data from the data bus. so, if WR\ is not
negated before valid data ends, the RAM device might latch in invalid
data due to the delayed WR\.

won't there be a problem in the write cycle if WR\ is delayed for more
than the data hold time after p2 ends? what can be done to ensure that
WR\ ends before the data hold time ends? is there some guaranteed,
foolproof way to solve the problem that does not rely on gate propagation
delays and bus capacitance?

your answers, especially those from Garth Wilson, will be sincerely
appreciated.

_________________
--
{tel: +91-20-6526-7076; cell: +91-9970-591-079; fax: +1-413-638-2021}

Welcome to the forum. It's nice to see a legitimate new user.

As far as asking for my response, I should say there are at least a half dozen very knowledgeable people here, although as usual, the areas of expertise don't totally overlap. I know that as soon as I give names, I'll probably forget a couple of important ones. Various members have different strengths in operating systesm, algorithms, hardware, languages, vintage, etc.. There's a good group here.

Between bus capacitance and the output-buffer and timing specifications of WDC's 65c02 being quite conservative, actual use becomes much easier than one might expect. What you are proposing and asking is rather common for newcomers to the 6502, but far more complex than necessary. The bus buffer for example will only slow things down, and it's not needed even for DMA since WDC's 65c02 has a BE (bus-enable) input pin (pin 36 on the DIP), ML (memory lock) output pin (pin 5 on the DIP), and VP (vector pull) output pin (pin 1 on the DIP) so you can tri-state the processor's buses at appropriate times for DMA.

DMA aside, if you can get away with 32KB of ROM and 16KB of RAM (or vice-versa with a small change) and up to 10 I/O ICs, the diagram at http://www.6502.org/users/garth/project ... chematic=2 will do the job using only a single 74xx00 for address decoding, and even leave one section available for something else. Gate delays are minimal, so you can achieve high clock rates. I need to update my pages on my workbench computer to reflect recent expansion, but I am still using this glue logic scheme. With 4MHz parts, the first problems show up at just over 7MHz at room temperature, so I run it at 5MHz for some margin. I have hundreds of systems flying in aircraft with the same scheme, and none has ever had a problem.

To answer your questions slightly more directly, SRAM usually takes some time to stop outputting data after it is de-selected, but it does not usually require any hold time on write. Add the effects of bus capacitance with CMOS-only inputs, and you're in the clear. As for the 65xx I/O ICs, they and the processor are made to work with each other directly.

For your ASCII diagrams and code segments, remember to uncheck the "Disable BBCode in this post" box before posting. Otherwise the [code] and [/code] directives won't do anything and all your extra spaces get removed and it goes to proportional spacing.

In response to your first question (READ\ going low with p2, causing the rams OE\ to go low...)

There will be some propagation delay through your RD\ generation circuit. This, along with the propagation delay in the ram chip from OE\ going high to the outputs being disabled means that the data will be present for some time after the falling edge of p2 - far longer than the data hold time requirements of the 6502. I know this relys on gate propagation delays but this is what makes it foolproof - the longer the gate delays, the longer the RAM data persists after p2 goes low!

With the write pulse, you do have to make sure the write pulse terminates before the end of the CPUs data hold time. With the older NMOS and CMOS chips this wasn't much of a problem, the write hold time was 1/5 of a cycle at the processors maximum clock speed - this gave you 200nS with a 1MHz chip and 50nS with a 4MHz chip - plenty of time for the write pulse logic. The current WDC devices are not as generous, however, and you only get 40nS of hold time with the slowest versions (2MHz) of their chips. This means your write pulse logic needs to be fairly quick. The buffer helps here - the hold time is extended by the propagation delay of the buffer.

If you are really worried, or are running at high clock speeds, may I suggest the following.

Buffer the data bus with a 74LS245 as you are planning to.

Buffer the processor's R/W\ and p2 lines with another 74LS245, 74LS541 or similar.

Generate the RD\ and WR\ signals with a 74LS139 connected to R/W\ and p2 BEFORE the buffers - R/W\ to input A, p2 to input B, enable input grounded. Then output 2 is WR\ and output 3 is RD\

This way, all your signals are delayed by one propagation delay and so maintain their timing relationships, including the RD\ and WR\ lines.

Finally, don't be afraid to rely on gate propagation delays - many circuits wouldn't even work if there were no such delays!

_________________
Shift to the left, shift to the right,
mask in, mask out,
BYTE! BYTE! BYTE!

i would like to thank SmilingPhoenix and GarthWilson for their feedback.

here is a reference to an article on 6502 Read/Write Timing that you may
find interesting. note the circuit for extending Data Write Hold Timing. also,
the information on Read Timing is useful.

Nuts and Volts
http://www.atarimagazines.com/computeii/issue1/page9.php

even though the article is quite old, the information in it is still useful.

thank you once again.

_________________
--
{tel: +91-20-6526-7076; cell: +91-9970-591-079; fax: +1-413-638-2021}

Well I also thought this would be so easy. It may work for simple designs like SRAM. I am in the process of designing a RAMdisk using old 30-pin SIMM dRAM modules. The timing is essential and you need to do the math using minimum and maximum gate delays to find the range where transitions happen. This range expands with each gate until you run into timing violations, meaning that minimum/maximum times run into an area where "the other end" runs out of time :-)

Also you should test with higher/lower supply voltages, and applying heat fans and cold spray (not at the same time though ;-)

Interesting information. Did not know about the long hold times.

Please know that "gate delays" are not equal among members of even a single TTL family (like 'LS). A 74LS139 has different gate delays than a 74LS00.


Ah, well. I thought so too.....
Now I've gotten some interesting notes from Bil Herd on that topic that changed my mind.

André

With regard to the long hold times, the data sheets I've got are all Rockwell or WDC - they may be different for other makes of processor. It might be useful to check.

I am aware that not all gates in a single family have the asme propagation delay. With regard to the suggestion I was making, the difference will be only a few nanoseconds and won't upset the performance of the circuit unles a very high clock speed is being used.

DRAM timing is a right royal headache - the only time I've ever used it I got a DRAM driver chip which did it all for me. Makes life MUCH easier The problem of compounded gate delays is why I try and make everything only one gate (or whatever) in fast circuits. This is where PLDs come in handy.

_________________
Shift to the left, shift to the right,
mask in, mask out,
BYTE! BYTE! BYTE!

What DRAM controller chip did you use?

I used the 74S409. Its a nice chip, contains all the address multiplexors, refresh circuitry, timing and bus drivers for DRAM arrays of up to 1M x 16 bits using 1-bit DRAMs. I used it to drive 4 256kx9 SIMMs to make a 1MByte RAM card for a 65C02 based system. With a 2MHz chip, I was able to perform refresh cycles in phase 1 time and avoid refresh getting in the processor's way. With todays faster chips, this might present a problem.

_________________
Shift to the left, shift to the right,
mask in, mask out,
BYTE! BYTE! BYTE!

I have a question related to this discussion. I want to build a little exapnsion board for my SBC which is based on Daryl's design. In his design, raw CPU signals and some decoded I/O are brought out to a connector in addition to PHI2 and MEMR/MEMW. The MEMR and MEMW signals are already qualified by PHI2 and R/W.

My question is this. If I build a little expansion board with four connectors on it, do I need buffering? I'm somewhere between NO and MAYBE on that answer.

Now, if I do have to buffer the signals, I'm figuring I could use an HCT245 for the address bus and an HCT541 for the data bus. Let's say there's no DMA capability, so the HCT245s are enabled all the time. What do I use to enable the HCT541? I guess I could use an LS133 and tie all of the decoded I/O selects and PHI2 to it so that the expansion peripherals can only jam data onto the bus when it's their turn.

Any thoughts on this?

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

It really depends on several things:

1) How fast is your CPU running. At 1 or 2 MHz a 6502 can directly drive its busses over a fairly large board. For example, look at the circuit of the Acorn Atom, where the 6502 drove 15 memory devices plus several LSI I/O devices on a PCB 16 inches wide. As the clock frequency increases, however, the capacitance and inductance involved with long busses require more powerfull drivers than those built into the 6502. I havn't yet gone over 3MHz so I can't speak from experience about high clock speeds but I suspect that at over 5MHz you might start running into problems without buffers.

2) What do you plan to connect to the bus? If each expansion slot is going to only conect one or two inputs to the bus, the 6502 will probably cope. If you are planning large expansion cards buffers will be needed to drive all those inputs. Early TTL PC expansion cards used to include buffers on the card - so that each card only presented one TTL load to the bus.

3) How long is your bus going to be. A long bus will need buffers to overcome its capacitance and inductance. With buffers, a 2MHz 6502 bus can easily be connected via a 1 metre length of ribbon cable without any problems.

To summurise, a short, slow bus with only a few devices on it won't need buffers. Fast busses, long busses and busses driving lots of devices all need buffers.

In addition, buffers provide protection for the CPU against mistakes and misconnections on the bus. A short to something nasty on a buffered bus will usually only blow out the buffer. Shorting a data line to something nasty on an unbuffered bus will usually destroy the CPU and could, if you are unlucky, take out the memories and VIAs as well.



It should be the other way round - HC245 for the data bus and HC541 for the address bus. The 245 is bidirectional and the 541 is unidirectional.

The buffers can all be enabled all the time if you have no DMA. Connect the direction input on the HC245 data bus buffer to the CPU's R/W\ line. This will make the buffer's direction match that of the processor and avoid any bus contentions. (It's worked for me in two systems I've built.)

You will also have to buffer the p2 clock and the R/W\ line if you are buffering the bus. On my bench computer I have address decoder lines running to the bus slots, so I don't need to take the high-order address lines (A15, A14, etc) to the bus slots. I used the spare buffers in the address-bus HC541 to buffer these signals.

By the way, unless your system uses NMOS or TTL devices it is better to use HC rather than HCT. HCT was designed to interface to the older TTL logic levels but this decreases its noise immunity. In an all-CMOS design HC is to be prefered.

_________________
Shift to the left, shift to the right,
mask in, mask out,
BYTE! BYTE! BYTE!

I hope I got this block quoting right, so here it goes. I appreciate your input on this. I penned out the design at lunch today so I want to get it firmed up so I can have some boards built-up.

1) How fast is your CPU running:: conventional 1MHz 6502

2) What do you plan to connect to the bus?:: I designed a 4-connector expansion board. I'm thinking a speech synthesizer on one slot, an AY38912 on another. Other two slots are open but I might make an analog input card and maybe an output card of sorts.

3) How long is your bus going to be.:: The interconnect cable might be 3", the expansion card is 4"x5" plus the length of each card, which might only be a few inches each.




Yes, indeed. I had them written right on my schematic but transposed them when typing. Thanks for the catch.



Ok, following the advice from way above, buffer everything to keep the propagation delays in sync. Gotcha.



I would have to go back to the data sheets on some of the chips to determine process type, but I would expect some 65xx family chips and there may be some TTL glue around too.

Thanks again for the "input" (so to speak). I really appreciate it. When the design is done, I'll post it to my Web site.

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

If your "TTL glue" happens to be 74AC or 74HC logic, then you can safely consider them to be pure CMOS devices (because they are. ).

Then you can get away with murder.

As far as output current goes, I found the WDC VIA to be able to pull down to a valid TTL logic-low level with about 24mA, and up to a valid TTL logic-high level with about 40mA; and I think the processor has the same output drivers as the VIA. The drivers are much stronger than the old NMOS ones were. However, I must point out that stronger bus drivers cannot overcome problems presented by inductance and transmission-line effects. Fairchild's ap. note AN-393 at https://www.onsemi.com/pub/Collateral/AN-393-D.PDF tells about transmission-line effects on CMOS logic. AN-317 at http://www.fairchildsemi.com/an/AN/AN-317.pdf#page=1 shows the effects of load capacitance and other factors on total propagation delay.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Last night I was thinking back to the kinds (and numbers) of things I used to connect to my VIC-20 and none of it was buffered and I didn't have a lick of trouble.

Ok, I think I have enough to go on for now. Let me see how things go and I'll report back.

Thanks to all!

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

thank you fellows for your help with this. i sincerely appreciate your
help. the answers were very illuminating. thank you.

btw, i used to live in San Mateo, CA before i came to Pune.

GO California, both NorCal and SoCal!
God bless America!

_________________
--
{tel: +91-20-6526-7076; cell: +91-9970-591-079; fax: +1-413-638-2021}