Buffering Address, Data and Control signals

[davi...@gmail.com]

I wanted to put the RC2014 in a case, but because it doesn't have buffered signals, a soon as I put the CF card too far away from the CPU it stops working.

So I thought about adding buffers. I'm surprised I haven't found anybody yet that has done it or at least published.

I have read some posts on the Net from people claiming that it's not possible, because the timings will be affected. But On Steve Ciarcia's Build Your own Z80, he's using 74367 to buffer the Address Bus, 8212 to buffer the Data Bus and 7404 to buffer the Control Lines. His computer is running at 2.5 MHz. Maybe is not possible for a computer running at 7.3728 MHz?

Also, I don't have 74367s nor 8212s, so I thought about substituting them by 74244s and a 74245.

I came across with this first design. Any thoughts?

[Dylan Hall]

Assuming your focus is just on buffering the CF card module, there have been a couple recent threads that touched on the subject that are well worth a read.

https://groups.google.com/g/retro-comp/c/zaj2bV3ZUvk/m/esB4K5wsAQAJ?utm_medium=email&utm_source=footer

https://groups.google.com/g/rc2014-z80/c/DGMJNdVuo3Q/m/SlPK01LaAQAJ?utm_medium=email&utm_source=footer

I can't find the specific message, but this repo was linked to which has a design (along with some excellent notes) for a buffered version of the CF card. https://github.com/PickledDog/rc-cfcard

All of that said, if I wanted to mount a CF card away from the rest of the system I'd use the IDE module (https://z80kits.com/shop/rc2014-ide-hard-drive-module/) with a standard IDE ribbon cable and something like this:

https://www.amazon.com/gp/product/B0026OYEEQ

I think Owen has been struggling to get the 82C55's for the IDE module, but hopefully they're not too far away.

Dylan

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/49580094-6731-4357-a42c-ff9a9efabe3dn%40googlegroups.com.

[Mark T]

There have been quite a few posts on design changes to improve the compact flash interface so you should probably take a look at the most recent of those that give some options for address decoding and timing of read and write.

If you are buffering the compact flash then use a 74HCT245 or 74AHCT245 close to the compact flash card. Avoid the 74ACT245. One of the issues with compact flash is the fast transition time of its outputs, not the bus speed, which causes a lot of ringing at the transitions between logic levels.

[Alan Cox]

Also, I don't have 74367s nor 8212s, so I thought about substituting them by 74244s and a 74245.

You will probably need HCT or AHCT parts to get the full voltage range. Certainly on classic systems with TTL logic you often end up also having to use a diode on Vcc to run the card at 4.3v or so to make it work.

It's not just the signal lines though - a lot of the CF adapters have very sharp fast edges so need a good power feed and clean backplane too. The buffers may well help there as you'll keep the extremely sharp edges off the backplane.

[Spencer Owen]

On Wed, 3 Aug 2022 at 21:23, Dylan Hall <dy...@deedums.com> wrote:

I think Owen has been struggling to get the 82C55's for the IDE module, but hopefully they're not too far away.

A couple of tubes of 82C55 came through from Mouser recently, so the IDE Hard Drive Module is currently back in stock. https://z80kits.com/shop/rc2014-ide-hard-drive-module/

There's not a lot left, though, and it looks like the balance of my order won't be here until March 2023. So grab 'em while you can!

Spencer

[davi...@gmail.com]

Thanks a lot Dylan. Looks like that design you gave me is exactly what I was looking forward. I just need to get hold of a 74HC245 as I only have HCTs, and then I'll try.

Thanks Mark and Alan. I now understand better the issue. I was indeed going to use HCT, but I was going to put the buffer close to the CPU instead of close to the CF as Mark suggested. I thought the issue was just lack of current from the Z80 pins, not the CF card itself.

[Tadeusz Pycio]

Personally, I think the main problem is not in the buffering of the data bus, but in the control of the CF. So far I have only found one card that required HC buffers - the 32MB included with Canon cameras. Next week I'll get a PCB with the usual full decoding /CS and buffer and I'll be able to confirm my guess, as my problematic SD to CF adapter shouldn't work on this module. My earlier CF module, which turned out to be a faithful copy of this one has one flaw, the unnecessary activation of the card's CE signal during memory accesses with addresses xx10h

[Laszlo Szolnoki]

I think buffering should be part of the Rc2014 bus specification. In the 80's we used P8282 and P8216 for buffering. The basic principle was: 1 load unit per connected unit on the bus. So if there are multiple parts on the same bus line, buffering makes sense. Otherwise it is wasted space.
As for the issues with CF, I'm pretty sure there is a timing issue on the bus and the IO addressing I usually see in the RC2014 environment could be the reason. The address space for a device should be well defined. That is, all the address lines involved must be accounted for. Some boards leave the address lines out. This creates phantom pulses on /CS signals. I suspect that many devices cannot digest this. I created a buffered CF board with strict addressing. Since then I can use romWBW to handle almost all CF cards. However, there are still more open issues. After some time, one of my CF cards is no longer addressable under CP/M, but still works fine with a PC card reader. What could be the difference between the interfaces? 8/16 access, timing? If a CF card works with a PC reader, it should also work in the RC2014 environment. We need to investigate further.
Cheers

Laszlo

[David Asta]

On Thu, 4 Aug 2022 at 12:38, Laszlo Szolnoki <lgszo...@gmail.com> wrote:

I think buffering should be part of the Rc2014 bus specification. In the 80's we used P8282 and P8216 for buffering.

I'm glad at least somebody else thinks the same as me. My main concern now is the CF card, but I guess having a proper buffering wouldn't hurt.

8282 are indeed the ones that Steve Ciarcia uses in his book.

I thought it would be difficult to get hold of those now. Actually on eBay they go for about 15-20 euros. That's why I substituted them by 245. Do you think it would be better a different chip?

[Laszlo Szolnoki]

Everything is fine. It should be a Tristate device and care must be taken with /CS and DIR for the data bus. Address and control signals are not so critical. Signal delay can be a problem. I have some old parts left, Intel, DDR and Russian. Sometime I'll put together a 2.5MHz system, just for fun.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/Aakw0_ipV_c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CA%2BEOkQ95mcD2Xm-8C8iHP809SYpPrRJV_X1tYtwFZrAxM3LLrA%40mail.gmail.com.

[Alan Cox]

On Thu, 4 Aug 2022 at 11:38, Laszlo Szolnoki <lgszo...@gmail.com> wrote:
>
> I think buffering should be part of the Rc2014 bus specification. In the 80's we used P8282 and P8216 for buffering. The basic principle was: 1 load unit per connected unit on the bus. So if there are multiple parts on the same bus line, buffering makes sense. Otherwise it is wasted space.

In the 1980s things like S100 were using a mix of 74 series devices
including 74F parts on a bus that wasn't so much designed as an
accident and so they needed buffering. On the other side of the fence
the 1802 based systems were CMOS and using all CMOS parts so didn't
because the signal levels are far better, the parts properly matched
for properties and the power consumption vastly lower.

RC2014 can run at 36MHz reliably it seems, so there is plenty of
headroom for more normal speeds. Not all the cards can run anywhere
near that - the 512K/512K card in particular is quite slow and I had
to swap one IC for a 74AHC part to run at 7.3MHz with a 65C816 (about
equivalent in bus cycle length to a Z80 at 20MHz+). Some of the 82C55
and 16x50 parts also get uppity once the write hold drops below about
20ns. The bus however is fine.

> As for the issues with CF, I'm pretty sure there is a timing issue on the bus and the IO addressing I usually see in the RC2014 environment could be the reason.

If you stick a good scope on it you'll see a few things aside from
some actual timing violations in the card versus the official ATA PIO0
(ie ISA bus) timings.

1. The power to the CF is critical (and the adapter just uses the 5v
from the bus). A modern era CF device is designed to drive 30cm of
cable between 0 and 5v fast enough for a 33MHz or higher transfer
rate. On a typical device the CF is on the same power as other high
current high noise devices not directly on the same thin power lines
as the logic.

2. Related to this you get a huge ground bounce when you switch
between things like 00 and FF so that also needs proper power
smoothing.

3. Because the signal edges are very very sharp and driving the bus
you've got a lot of other noise and mess and the CF is fast enough to
see bounces and glitches the other slower devices simply won't respond
to.

Buffering the CF at the CF end should help - the edges on the bus are
now the edges from the far slower 74HC(T) parts and any very short
bounces on the signals will not be seen by the slower drivers. Power
however is critical, proper capacitors and possibly even running
actual wire links.

[Mark T]

In the 80s systems were mostly 74ls ttl and nmos. The nmos outputs are normally limited to drive two 74ls inputs. As the address decoding was 74ls and each card contains its own address decoding this forces any card using nmos outputs to include buffers. This then has the knock on effect of every other card needing buffers to drive the inputs of every other card.

RC2014 is a much simpler system, most cards are not much more than a breakout board for the IC providing the main function of the module. All address decoding is 74hct, though the simple system can tolerate one or two 74ls devices. Instead of nmos most of the major ICs are cmos with better drive outputs than the old nmos parts. There are a few exceptions, for example the TMS9918A is nmos and not available as cmos, but this also seems to have no problem driving the databus in a system with mostly 74hct or cmos loads.

Buffering the data bus adds the complication of buffer direction control, especially if interupt mode 2 is implemented. If every card buffers address and data bus this is a huge increase in the number of ICs in the system, increasing the risk that an inexperienced builder will be unable to get the system running.

The RC2014 is intended to be a simple low cost starter system but has a lot of scope for expansion and experimenting. Including adding buffers if thats what you want to play with.