TURBO - Z80 CPU Module

[Phillip Stevens]

Was thinking that it might be nice to have 80's TURBO 2x CPU Module for my RC2014, without requiring software changes.

The design scope would be just the CPU, but with an integrated Reset DS1233, and 2x CLOCK, and fully drop in replacement module for original.

Perhaps to replace the departed Tynemouth Software CPU Module, as a design goal.

Both of the RAM / ROM Modules would be quite OK with the CPU at 14MHz, but of course the serial I/O Modules rely on the CLOCK being correct at 7MHz.

So having the clock circuit on the CPU Module would allow us to have the CPU running 14MHz, but generate and distribute a 1/2 clock at 7MHz on the bus.

What is missing then is a way to generate an IORQ linked WAIT state to allow the peripherals to think they are seeing a half speed transaction.

Would have to experiment as to whether one or two (or more) WAIT states are required...

Interesting idea?

Thoughts on generating wait states?

Cheers, Phillip

[karlab]

Why complicate things?

Run Z80 at any speed up to 20mhz (Turbo 3x) and beyond but change the serial board to eg. MC68B50 or 16C550.

Cheers 

Karl

[Phillip Stevens]

karlab wrote:

Why complicate things?

A little more complicated in hardware for one person to solve, but a lot easier for everyone because no software changes would be  needed.

The essence of a true "TURBO" Button.

 

Run Z80 at any speed up to 20mhz (Turbo 3x) and beyond but change the serial board to eg. MC68B50 or 16C550.

Yes, that is easy probably the most sound way of running everything faster. But, it does mean software changes.

I think just generating some wait states for IORQ is enough, but not certain. Will have to look into the details.

Have you looked at this?

Cheers, Phillip

[Alan Cox]

On Tue, 18 Aug 2020 at 08:35, Phillip Stevens <phillip...@gmail.com> wrote:

I think just generating some wait states for IORQ is enough, but not certain. Will have to look into the details.

Have you looked at this?

Not everything scales neatly off \WAIT with frequency. Things like the write hold time do not and some of the devices do care about write hold times as I found out with the 65C02/65C816 boards.

The 68B50 can handle the speed and needs no software changes (neither does 16x50 for ROMWBW nowdays)

Alan

[Phillip Stevens]

Phillip Stevens wrote:

I think just generating some wait states for IORQ is enough, but not certain. Will have to look into the details.

Have you looked at this?

 

 Alan Cox wrote:

Not everything scales neatly off \WAIT with frequency. Things like the write hold time do not and some of the devices do care about write hold times as I found out with the 65C02/65C816 boards.

Yes, you've nailed the "challenging" feeling I get from this thought bubble. The /RD /WR /IORQ timing will be twice as fast as the clock, and therefore may be too tight (even with WAIT states in the middle).

For example with the Am9511A it needs 30ns off the back of /WR with valid /CS (which is set by valid ADDR). At 7MHz it is about 86ns measured, so it should still be OK at 14MHz with 43ns (guesstimate).

I've not read the SIO & 68B50 datasheets enough to see. Homework... 

 

The 68B50 can handle the speed and needs no software changes (neither does 16x50 for ROMWBW nowdays)

I'm confident it can handle 14MHz of "normal" signals, but can it handle those signals when CLK running at half rate?

I guess that question is really "Is the clock signal used at all on the data side of the device?"

If you say NO, then there is no problem at all. Don't even need to think about wait states (at least for the 68B50 and 16x50). The design is trivial.

But if you YES, then comes the work of understanding what happens when ratio of CLK oscillation to other signals is wrong.

Hmmm..

Cheers, Phillip

 

 

[Mark T]

Why complicate things?
To make it more fun.

At 2 x clock speed its probably ok to just overclock the peripheral chips.

At 3 x clock speed using z80 peripheral chips might be a problem. To use mode 2 interupts the peripheral would need to monitor instructions during M1 fetch, so you might need wait states in both M1 fetch and IORQ. Also IEI/IEO chain would have less time and might need a look ahead circuit.

It might be interesting to try overclocking the cmos z80 peripherals to see how far they will go without wait states.

Wait states in M1 fetch starts to become a problem at 12-14 MHz, due to set up time prior to falling edge of T2 clock cycle. Though I was using an ‘ls156 which is equivalent to two gate delays.

Mark

[mik...@houseofmyrrh.org]

Yes a look ahead would probably be indicated if issues are encountered.

I was thinking that you could decode the addresses involved and set a
latched wait state that is reset at an appropriate time.

Alternately, you could use a one-shot, but, it would have to be "quick".
:)

But, I can't play that game myself until *after* I get my first "Pro"
built and running.

So, what version of the Z80 Processor family would you be running at 14+
MHz?

I thought 8 Mhz was the top end for an "H"?

Mike Sr.

[Mark T]

Cmos z80, z84c0020 is up to 20MHz, and Bill Shen has recently overclocked to 33MHz with faster ram and using cpld for serial.

The z80 peripheral chips only seem to be rated up to 10MHz, but I don’t remember seeing anything about how far they can be overclocked.

I think Karl has run the 6850b with z80 at 20MHz without wait states.

Mark

[karlab]

Thats correct.

I have been using the 68b50 with 33mhz z180.

The thing is that the 68b50 run by ITS own  clock at 7,3mhz .

No wait states because they run asynchronous, unlike sio/2 which needs to be synchronized.

No software modifications is needed. The 16c550 is maybe more flexible.

Karl

Karl

[Bill Shen]

I have a SBC design based on 20Mhz CMOS Z80 and 12.5mhz KIO that overclocked to 4X turbo (29.5mhz) reliably. I believe I've successfully overclocked it to 32Mhz, (passing zexall.com) but CF interface became flaky above 32Mhz. One caveat is I have not exercise mode 2 interrupt during these overclocking experiments. https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:k80
Bill

[Bill Shen]

Another z80 part that can be overclocked recklessly is the intelligent peripheral controller, Z84C1516, which is a Z80 with KIO built in. 4X turbo is achievable.

https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:microz

https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:micro80

Bill

[karlab]

Here is my RED HOT system; Z80 at 20Mhz, can probably overclock to 24mhz without issues, with a MC68B50 at 7,3Mhz onboard.

Karl

[Phillip Stevens]

It is really good to see just how far Bill and Karl have pushed the performance envelope with overclocking Z80s.

But, I'm sure that all of those systems would not work with the standard Grant Searle MS Basic ROM, or with the standard CP/M ROM for SIO/2 provided to RC2014 customers.

The main point to this thought bubble is to work out what would be required to make a TURBO CPU Module that can be dropped into a bog standard RC2014 system with no other changes, and everything just works.

I would have liked to go for a 3x multiply on the CPU to 21MHz, but I know already that option won't work with all the modules. So it is ruled out. We're left with 2x.

Mark T wrote:

At 3 x clock speed using z80 peripheral chips might be a problem. To use mode 2 interrupts the peripheral would need to monitor instructions during M1 fetch, so you might need wait states in both M1 fetch and IORQ. Also IEI/IEO chain would have less time and might need a look ahead circuit.

There is some comforting text in one of the early Z80 manuals (1976) which says paraphrased, the Z80 generates its own timing relationships internally, and all the signals are asynchronous to the clock (edges). I think that means that while the clock is always represented in timing measurements, it doesn't matter if there is skew. I've not seen similar text in any of the Z80 peripheral documents, so it is hard to say whether they need to keep to the correct timing relationships with respect to the clock, or not. Thoughts?

I think Mark has captured the need to (potentially) stretch the clock during the address fetch part of the M1 cycle for Mode 2 interrupts, which I wasn't thinking about at all. So then there could be two cases where the clock might need to be stretched.

What I think is worth doing is building a test mule that has two delay options for each of the situations. Both 1/2 clock (from point of view of the bus) and whole clock delays are easy to generate, just by feeding the correct clock into pairs of D flip-flops. And the two situations where delay is needed are /M1 and /IORQ combined for the interrupt address fetch, and the standard /IORQ for both READ and WRITE.

That will give four options to test with. And, as Mark pointed out, at 2x everything may just work without any additional delays.

Cheers, Phillip

[Phillip Stevens]

Phillip Stevens wrote:

There is some comforting text in one of the early Z80 manuals (1976) which says paraphrased, the Z80 generates its own timing relationships internally, and all the signals are asynchronous to the clock (edges). I think that means that while the clock is always represented in timing measurements, it doesn't matter if there is skew. I've not seen similar text in any of the Z80 peripheral documents, so it is hard to say whether they need to keep to the correct timing relationships with respect to the clock, or not. Thoughts?

From the Z80-CPU Technical Manual (1976) page 70.

 

[Mark T]

To some extent the z80 peripherals need to be referencing the clock and not just the asynchronous signals. For example the pio does not have a WR pin, and uses the missing RD to decode an IORQ.WR, but the timing of IORQ and RD may not be synchronized exactly and probably needs to trigger off one edge of the clock. Also M1 alone indicates the start of an interrupt acknowledge cycle, but during M1 fetch the M1 is earlier than RD by half a clock period so is probably also qualified by clock. 

M1 alone indicates to peripherals to resolve the IEI/IEO chain, prior to M1 and IORQ together to place the interrupt vector on the data bus. Note that doesn’t seem possible to insert wait states in the M1 cycle prior to IORQ. Though it may be possible to stretch the clock.

Mark

[karlab]

Regarding overclocking.

When running the Z80 at 20Mhz, it is within speck for the Z84C0020 CPU, and is not regarded as overclocking.

However the MC68B50 is rated for 2Mhz, but runs happily at 7,3Mhz same as in RC2014 classic.

It is no all about speed, but using the capability of the components.

There is no need to rewrite or modify the code for the Z80@20Mhz/68B50 since it is already supported by some of the RC2014 rom variants, SCMonitor and ROMWBW.

Pushing the Z80 to 30Mhz and beyond, is clearly overclocking. Bill is able to do this because he has full control of the whole system. This can be more troublesome in a modular system.

Karl

[Alan Cox]

On Wed, 19 Aug 2020 at 12:45, karlab <ka...@brokstad.no> wrote:

Regarding overclocking.

When running the Z80 at 20Mhz, it is within speck for the Z84C0020 CPU, and is not regarded as overclocking.

However the MC68B50 is rated for 2Mhz, but runs happily at 7,3Mhz same as in RC2014 classic.

The 68B50 is rated for a 2MHZ 6800 bus cycle (E clock) not a Z80 one so it's not really that overclocked (if at all I've not done the math) at 7.3Mhz with a Z80 as the Z80 bus cycle is stretched over multiple CPU clocks, whilst the 680x, 6502, 65C816 one is completed over a single cycle.

Alan

[Phillip Stevens]

karlab wrote:

Regarding overclocking.

However the MC68B50 is rated for 2MHz, but runs happily at 7,3MHz same as in RC2014 classic.

 Alan Cox wrote:

The 68B50 is rated for a 2MHz 6800 bus cycle (E clock) not a Z80 one so it's not really that overclocked (if at all I've not done the math) at 7.3MHz with a Z80 as the Z80 bus cycle is stretched over multiple CPU clocks, whilst the 680x, 6502, 65C816 one is completed over a single cycle.

Yes, at 7.3MHz we have 135ns per cycle and with about 2.5 cycles for the /IORQ to complete in 220ns, there's no overclocking at all in the normal environment.

I think if 1x 7.3MHz (135ns) wait cycle is added, then it will also not be overclocked if the signals are generated by a 14.6MHz CPU clock.

Looking through the data sheets for standard RC2014 Modules the only one that I've still got a concern about is the SIO/2 serial module, as I don't know how the IM2 address fetch will work with the clocks "odd"***, even if the IM2 IORQ address fetch is wait stated too. On first pass, every other Module should just work, provided there is an extra 7.3MHz wait state, and stay within their respective specifications.

*** by odd I mean that the signals are running to 14.6MHz timing, but the clock is running to 7.3MHz timing, so there will be fewer clocks in a particular transaction than the peripheral expects.

Phillip

[Alan Cox]

Looking through the data sheets for standard RC2014 Modules the only one that I've still got a concern about is the SIO/2 serial module, as I don't know how the IM2 address fetch will work with the clocks "odd"***, even if the IM2 IORQ address fetch is wait stated too. On first pass, every other Module should just work, provided there is an extra 7.3MHz wait state, and stay within their respective specifications.

I will be really interested to know what you find out as I simply couldn't get the Z80 peripheral chips to even co-exist peacefully with non Z80 processors on RC2014 and it might give clues as to what they rely on.

[Phillip Stevens]

Mark T wrote:

At 3 x clock speed using z80 peripheral chips might be a problem. To use mode 2 interrupts the peripheral would need to monitor instructions during M1 fetch, so you might need wait states in both M1 fetch and IORQ. Also IEI/IEO chain would have less time and might need a look ahead circuit.

Starting to think about this further, and I believe that it will be sufficient to add one 7.3MHz cycle wait state when the /IORQ is low. This will be equivalent to two 14.6MHz wait states, but since the divided clock is synchronous with the original clock there shouldn't be a problem. I don't think there's a need to worry about the daisy chain with the RC2014 too much, so I'm prepared to forego that in my solution. But, the SIO can't be ignored as it is part of the RC2014 Plus.

I found this picture which describes the addition of IM2 response wait states in the IORQ section of the cycle, rather than in the M1 section of the cycle which is normally shown. I hadn't been sure this was possible until now. i.e. whether the /WAIT line was sampled during the automatic wait states, or whether it was just sampled during T2 state. But now I've more confidence that just stretching the /IORQ during the automatic wait states will be sufficient.

But, here's a question for the logic gurus. What is wrong with using the first circuit below for that purpose?

I don't see why the 9.0.3 solution is not sufficient (assuming /IORQ  is substituted for /M1 and /MREQ in each option).

Why do Zilog propose the other option 9.0.4 for inserting wait states?

[Samuel Falvo II]

On Tuesday, September 1, 2020 at 6:31:52 AM UTC-7 Phillip Stevens wrote:

Why do Zilog propose the other option 9.0.4 for inserting wait states?

I think it's because M1# is low for only 1.5 cycles during an instruction fetch while MREQ# is low for two (three) cycles for memory (resp. I/O).

[Mark T]

I don't see why the 9.0.3 solution is not sufficient (assuming /IORQ  is substituted for /M1 and /MREQ in each option).

Why do Zilog propose the other option 9.0.4 for inserting wait states?

I think the first circuit would also activate /wait during T3 if used with /mreq or /iorq, though the z80 would ignore wait during T3, so I don’t think it would matter. 

Also i don’t think those circuits would work to insert a wait state in an interrupt acknowledge cycle. The time from iorq active to rising edge of clock for the second TWA is too long according to the spec. Due to set up time of the 74x74. 

Wait input is active only during T2 of a memory access or fetch or the last automatic wait state of IO or intack cycles.

Mark

 

[mik...@houseofmyrrh.org]

I had thought about the 7474 and running the clock through a Gate (have
not looked at it in sim, yet) and coupling the /IORQ to the /CLR on the
F/F through a capacitor to lengthen one cycle paralleling the clk input
to the clk on the F/F?

Type of gate would depend on whether we want to hold the clock high or
bring it low and hold it there.

Basically the /IORQ would reset the F/F and the next rising edge of the
main clock would set it.

While this would work for the I/O, timing gets really tight for Memory.

(Forgive me if I'm off base, it's been quite a while since I've "played"
with this stuff.)

Mike Sr.

> --
> 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/3d71ef09-6a61-4868-a01c-ce6ed6319838n%40googlegroups.com
> [1].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/rc2014-z80/3d71ef09-6a61-4868-a01c-ce6ed6319838n%40googlegroups.com?utm_medium=email&utm_source=footer

[Mark T]

Attached a couple of ideas aimed at using wait states on a z80 at higher clock frequencies, both still untested.

The first is using a 74F395, which clocks on the falling edge, and can be configured as a pseudo open collector output by using the none tri-state output to control the tri-state output. This is configured to hold /WAIT low for all clock cycles and releases wait for /IORQ or /MREQ cycles. I figured this might be fail safe as it could insert wait states when not required, instead of failing to generate wait state when it is required. 74LS395 would possibly work at lower clock frequencies.

Similar method might be possible with other flip flops, releasing wait when wait is not required, instead of activating wait when it is required. This is to try and compensate for the short setup time on /WAIT active to T2 fall

The second uses a 2 x clock through a 74ACT163, running as a divide by 2 on regular clock cycles but adds one more cycle when /M1 is active. Timing is quite critical in this case, I've used measurements off one z80 rather than the zilog spec. I think the timing might work at 20MHz to 25MHz, probably not at lower clock rates. Plan is to extend /M1 by half a z80 clock cycle, so M1 fetch matches timing of MREQ access. I've included my timing sketches at the top of the sheet.

With the second method it might also be possibly to connect /WAIT from the bus to the 74ACT163 instead of to the Z80, then the time that /WAIT needs to be asserted could be later in the cycle.

Mark

[Phillip Stevens]

Mark T wrote:

Attached a couple of ideas aimed at using wait states on a z80 at higher clock frequencies, both still untested.

Looking at the falling edge clock solution as the most practical I think. 

The first is using a 74F395, which clocks on the falling edge, and can be configured as a pseudo open collector output by using the none tri-state output to control the tri-state output. This is configured to hold /WAIT low for all clock cycles and releases wait for /IORQ or /MREQ cycles. I figured this might be fail safe as it could insert wait states when not required, instead of failing to generate wait state when it is required. 74LS395 would possibly work at lower clock frequencies.

 

Similar method might be possible with other flip flops, releasing wait when wait is not required, instead of activating wait when it is required. This is to try and compensate for the short setup time on /WAIT active to T2 fall

I tried to find a D flip-flop that was clocked on the falling edge for the APU Module, but ended up using a JK flip-flop 74HCT107 as the only viable alternative. Using a couple of falling edge triggered JK flip flops (in a single device) might be another way to do this?

 

The second uses a 2 x clock through a 74ACT163, running as a divide by 2 on regular clock cycles but adds one more cycle when /M1 is active. Timing is quite critical in this case, I've used measurements off one z80 rather than the zilog spec. I think the timing might work at 20MHz to 25MHz, probably not at lower clock rates. Plan is to extend /M1 by half a z80 clock cycle, so M1 fetch matches timing of MREQ access. I've included my timing sketches at the top of the sheet.

It is now obvious (in hindsight after you pointed it out) that if the 1/2 clock is used as the source, then there is no chance for the Zilog solutions to work. There is a very strong chance that there will be no 1/2 clock positive edge between /IORQ falling and the full speed clock TWa fall in the interrupt acknowledgement cycle. So, that cunning plan has to be abandoned.

This means, at least a two wait state delay (at the full speed clock) is needed. And, a therefore new solution to generate 2x wait states is needed.

What I'm seeing generally is at least 4 or 5 logic chips being needed to generate the two wait state solution and the half rate clock solution, so it sounds like a small GAL16V8 could be the best answer.

Then, I just need to cook up the logic descriptions. The end to end delay is also bounded to much lower than with individual logic.

Another abandoned idea was using a 74ABT245 Transceiver on the data lines to increase the data line drive from 1.8mA to 64mA, hopefully making CompactFlash interface more reliable. I abandoned the idea because the logic for data direction got complex once IM2 interrupt and /BUSACK were taken into account.  But, if a GAL16V8 were on the board, then the idea of including a buffer transceiver would become possible again.

Hmm.

[Bill Shen]

For my ZRC Z80 SBC, I used a relatively slow 2meg x8 DRAM for main memory.  The memory is too slow to support zero wait access at 14.7MHz, so I have a simple sub-circuit in CPLD to add a wait state for instruction fetch.  WAIT is driven directly without open collector or tri-state buffer because CPLD is the only driving source for WAIT.
  Bill

[Mark T]

I tried to find a D flip-flop that was clocked on the falling edge for the APU Module, but ended up using a JK flip-flop 74HCT107 as the only viable alternative. Using a couple of falling edge triggered JK flip flops (in a single device) might be another way to do this?

There does seem to be a lack of falling edge flip flops in the ttl range, but there is always the possibility of using an inverter on the clock to a 74x74, though there is then some uncertainty in the propagation delay of the inverter. 

Whenever you need more than one flip flop it’s worthwhile considering counters, registers and shift registers, as you often get some additional logic that can be useful to reduce ic count, as in the case of the 74x395, though sometimes there are limitations on the ttl variants available. There are quite a few shift registers with negative edge clocking. Then there is the issue of availability of some of these less common parts.

Don’t forget to consider the possibility of holding wait active and releasing it at appropriate times instead of trying to activate wait after decoding other control signals.

You don’t need to drive wait with an open collector. If the wait state generator is on the processor module you could either ignore wait from the bus or use an and gate between the wait state generator and the z80.

Mark

[mik...@houseofmyrrh.org]

Every gate you add, adds to the delay involved in arriving at your
desire.

Why not forget the CLK input and capacitively couple to a /CLR or /SET
input?

A lowly 7474 would work, wouldn't it?

At 14.745 Mhz half a clock is only 33.9 nSec that isn't a lot to play
with unless everything else is delayed the same amount.

Mike Sr

> --
> 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/f056f046-ca66-45e2-b0b0-4498ca8e63d1n%40googlegroups.com

> [1].
>
>
> Links:
> ------
> [1]

> https://groups.google.com/d/msgid/rc2014-z80/f056f046-ca66-45e2-b0b0-4498ca8e63d1n%40googlegroups.com?utm_medium=email&utm_source=footer

[Phillip Stevens]

I tried to find a D flip-flop that was clocked on the falling edge for the APU Module, but ended up using a JK flip-flop 74HCT107 as the only viable alternative.

Mark T wrote: 

There does seem to be a lack of falling edge flip flops in the ttl range, but there is always the possibility of using an inverter on the clock to a 74x74, though there is then some uncertainty in the propagation delay of the inverter.

Off topic, but in the special circumstance I needed for the APU module 1/3 clock generator, the JK flip-flop was actually better, as I could feed it with Q and /Q from the prior D flip-flop thus saving an inverter pm the K input. Small win.

 

Don’t forget to consider the possibility of holding wait active and releasing it at appropriate times instead of trying to activate wait after decoding other control signals.

Yes, I think (also Mike Sr said too) that's the best idea. Grab /WAIT asap, and then release it.

I'll use combinational logic to hold /WAIT together with /IORQ (which should give no more than 15ns delay), and then use clocked flip-flops to release /WAIT after a certain number of cycles. Can't see any holes in that plan right now.

 

You don’t need to drive wait with an open collector. If the wait state generator is on the processor module you could either ignore wait from the bus or use an and gate between the wait state generator and the z80.

True but the APU Module needs the /WAIT signal, as it issues (from its point of view) /PAUSE every time it receives data or a command. So I'll need to read /WAIT from the bus too if the TURBO CPU Module is going to be transparent to all Modules.

If I can reduce the logic real estate down to one GAL16V8, then there should be space on a standard size Module to add a 74x241 buffer for control signals, and a 74x245 transceiver for data signals, and have them controlled by some combination of /RD and /BUSACK. I think that has become the stretch goal.

P.

[Phillip Stevens]

Phillip Stevens wrote:

If I can reduce the logic real estate down to one GAL16V8, then there should be space on a standard size Module to add a 74x241 buffer for control signals, and a 74x245 transceiver for data signals, and have them controlled by some combination of /RD and /BUSACK. I think that has become the stretch goal.

Status shot. Coming along, but still some cleaning up to do. 

P.

[Mark T]

I was wondering if the use of 74abt series might be a problem driving the RC2014 bus. They have faster transition time than 74act series and I have seen a few warnings about driving busses using 74act without adding 100 ohm series resistors in the drive circuit or proper bus terminations. 74ahct might be a safer option.

You could possibly use a 74x245 in place of the 74x541, just to avoid stocking two different types.

Mark

[Phillip Stevens]

Mark T wrote:

I was wondering if the use of 74abt series might be a problem driving the RC2014 bus. They have faster transition time than 74act series and I have seen a few warnings about driving busses using 74act without adding 100 ohm series resistors in the drive circuit or proper bus terminations. 74ahct might be a safer option.

Good point. I've used ABT before, but it was within a SBC so who knows if there was really an issue...

AFAIK the pin outs are the same so any technology would be good to test.

You could possibly use a 74x245 in place of the 74x541, just to avoid stocking two different types.

Another good point. I've done it with the 74x541, but no reason why a 74x245 wouldn't be equally as good.

So, I've finished the layout and the design now. The best thing is that the board will be very flexible, and by configuring the GAL it will be possible to the bus at any rate, with the crystal providing the base.

I've just occupied all the inputs on the GAL, in case something interesting comes up to study. But, on the output is is just the /CPU_WAIT,  the /BUS_ENABLE for the buffers, and the /BUS_CLOCK with the divided (or not) base clock.

I can get things going at 7.3728MHz by using the GAL as a pass-through or NOT device. Then play with different solutions with quite a lot of logic to hand.

I've ordered some boards tonight from Seeed Studio.

If anyone wants the Gerbers, let me know and I'll mail them.

Cheers, Phillip

[Phillip Stevens]

Mark T wrote:

I was wondering if the use of 74abt series might be a problem driving the RC2014 bus. They have faster transition time than 74act series and I have seen a few warnings about driving busses using 74act without adding 100 ohm series resistors in the drive circuit or proper bus terminations. 74ahct might be a safer option.

 

Phillip Stevens wrote:

Good point. I've used ABT before, but it was within a SBC so who knows if there was really an issue...

AFAIK the pin outs are the same so any technology would be good to test.

Just digging into this bus termination thing a little more, I found a paper from Leventhal (son of z80 Leventhal???) which draws some scary diagrams at 50MHz, for unterminated ABT devices, and points strongly at AHCT as being much better (at least at these frequencies on unterminated busses).

But digging deeper I found a reference to internally terminated ABT devices, designated with a "2" in the number eg. 74ABT2xxx, which have 25 ohm internal series resistors.

Supposedly these provide the performance characteristics of ABT, but without ringing artifacts present on unterminated busses.

So interestingly there is only a 74ABT2245 device available in 20-DIP. The equivalent 74ABT2541 device doesn't come in through-hole version.

I'll have to redesign the board to allow for 2x 245 devices. Trying to get the order cancelled now.

[Mark T]

It’s probably worth noting that the problem with act and abt devices is the fast transition time between logic levels, and not the frequency, combined with the length of transmission lines that are the cause of the problem. I’m sure you already read this in your research but thought I’d mention this for the benefit of others following this discussion.

I was wondering if this might actually be a problem that could be solved by the cray style backplane :)

Mark

On Monday, September 7, 2020 at 2:39:55 AM UTC-4 Phillip Stevens wrote:

Mark T wrote:

I was wondering if the use of 74abt series might be a problem driving the RC2014 bus. They have faster transition time than 74act series and I have seen a few warnings about driving busses using 74act without adding 100 ohm series resistors in the drive circuit or proper bus terminations. 74ahct might be a safer option.

Just digging into this bus termination thing a little more, I found a paper from Leventhal (son of z80 Leventhal???) which draws some scary diagrams at 50MHz, for unterminated ABT devices, and points strongly at AHCT as being much better (at least at these frequencies on unterminated busses).

But digging deeper I found a reference to internally terminated ABT devices, designated with a "2" in the number eg. 74ABT2xxx, which have 25 ohm internal series resistors.

Supposedly these provide the performance characteristics of ABT, but without ringing artifacts present on unterminated busses.

So interestingly there is only a 74ABT2245 device available in 20-DIP. The equivalent 74ABT2541 device doesn't come in through-hole version.

I'll have to redesign the board to allow for 2x 245 devices.

Found this very clear analysis of the topic (attached), published by TI quite recently. I've only had 23 years to find it.

So the TURBO CPU Module has been redesigned for 2x 74ABT2245 buffer devices across data, control and low address lines.

And as all the signals relevant to the Compact Flash Module are now properly driven and terminated it will be interesting to see if it is more reliable.

Gerber and Eagle files attached.

Phillip

[Phillip Stevens]

Mark T wrote:

It’s probably worth noting that the problem with act and abt devices is the fast transition time between logic levels, and not the frequency, combined with the length of transmission lines that are the cause of the problem. I’m sure you already read this in your research but thought I’d mention this for the benefit of others following this discussion.

Mark T wrote:

I was wondering if the use of 74abt series might be a problem driving the RC2014 bus. They have faster transition time than 74act series and I have seen a few warnings about driving busses using 74act without adding 100 ohm series resistors in the drive circuit or proper bus terminations. 74ahct might be a safer option.

Just digging into this bus termination thing a little more, I found a paper from Leventhal (son of z80 Leventhal???) which draws some scary diagrams at 50MHz, for un-terminated ABT devices, and points strongly at AHCT as being much better (at least at these frequencies on unterminated busses).

But digging deeper I found a reference to internally terminated ABT devices, designated with a "2" in the number eg. 74ABT2xxx, which have 25 ohm internal series resistors.

Supposedly these provide the performance characteristics of ABT, but without ringing artefacts present on un-terminated busses.

So the TURBO CPU Module has been redesigned for 2x 74ABT2245 buffer devices across data, control and low address lines.

And as all the signals relevant to the Compact Flash Module are now properly driven and terminated it will be interesting to see if it is more reliable.

Gerber and Eagle files attached.

Thanks for your input on this, and driving in the right direction.

I think it has lead to an outcome that drives the RC2014 bus more "professionally" than using the raw Z80 I/O, and hopefully the design including a DS1233 reset & voltage supervisor, and crystal oscillator ticks all the boxes for a stable CPU Module.

With the GAL available to manage Wait States and Clock division / distribution, there will be enough of a "sand-pit" to either experiment with weird timing and wait state options, or just to configure it for stable non-TURBO operation.

I'm quite looking forward to playing with the outcome now.

Phillip

[Bill Shen]

Termination of RC2014 bus may also help with the CF interface problem.  What you are wrestling with ABT buffers is the same kind of problem with CF board.  The modern CF devices are fast and swing from 5V to ground, it is like having ABT drivers.  This is why CF board may or may not have problem at certain backplane position (reflection) and why its errors are data pattern dependent (ground bounce); CF having a FIFO-like buffer compounds the problem because a glitch on the read line can clock out the next data causing current data to disappear without being read.
 Bill

[Phillip Stevens]

Bill Shen wrote:

Termination of RC2014 bus may also help with the CF interface problem.

What you are wrestling with ABT buffers is the same kind of problem with CF board.  The modern CF devices are fast and swing from 5V to ground, it is like having ABT drivers.  This is why CF board may or may not have problem at certain backplane position (reflection) and why its errors are data pattern dependent (ground bounce).

If I can remember transmission line theory (from quite a few decades ago) then putting a serial resistor against an output interface effectively doubles in impedance because the undamped reflection comes back through the resistor too. So, it behaves as a 50ohm termination on the bus for long (end of line) ringing.

So if that is the situation, having the ABT2xxx devices attached to the bus will act to dampen the bus whether the transmitting or not, right? I guess it depends on whether ABT2xxx leaves the terminating resistor in circuit when in Rx (B->A) mode. Hmm back to the data sheet.

If the Tx terminating resistor stayed in circuit then that would be the best outcome. 

Phillip

[Bill Shen]

Life is more complicated with bidirectional tranceiver; on the transmit side, the sum of transmitter impedance plus the series terminating resistor should match the bus impedance.  My guess is the ABT driver has an effective internal impedance of 50 ohm, so adding the 25 ohm serial resistor give you 75 ohm terminating resistance.  However, RC2014 backplane is not designed with control impedance, so it has more likely 100 to 150 ohm characteristic impedance.  You'll see some reflection driving RC2014 bus with ABT drivers.  On receiving data, the receiver is high impedance, much higher than the 25 ohm series resistor, so it is effectively un-terminated and depending on the driver on the other end of the bus to have proper series termination.  If you drive both ends of control impedance bus with ABT tranceivers, everything works out, but in the reality of RC2014 world, there'll be ringing and reflection.  The question is whether they are severe enough to cause problems.  Fewer boards and shorter bus will always help.
  Bill

[Phillip Stevens]

So, after a few thoughts and revisions, I've finished a board which will be the test bed.

In the end, I decided to use the 74AHCT245 devices, because 74ABT2245 devices weren't available from my preferred supplier in quantity 10x.

I'll build it first using a 7.3728MHz oscillator, to check that the bus buffering and management works properly. Releasing the bus and reading the bus at the right times.

Then, experiment with options for 14.7456MHz and the different wait state options. I hope that having all the options as inputs to the GAL will enable most solutions for /WAIT.

Watching the board production clock now.

Phillip

[Phillip Stevens]

Phillip Stevens wrote:

So, after a few thoughts and revisions, I've finished a board which will be the test bed.

In the end, I decided to use the 74AHCT245 devices, because 74ABT2245 devices weren't available from my preferred supplier in quantity 10x.

I'll build it first using a 7.3728MHz oscillator, to check that the bus buffering and management works properly. Releasing the bus and reading the bus at the right times.

Then, experiment with options for 14.7456MHz and the different wait state options. I hope that having all the options as inputs to the GAL will enable most solutions for /WAIT.

Watching the board production clock now.

Here's the first 1x version of the TURBO CPU Module.

Currently set up to run precisely like an OEM CPU Module, to make sure there are no issues.

 But, even without being faster than other CPU Modules, it makes me feel happy because it supports:

• a buffered CLOCK from an oscillator.
• RESET timer and brown-out protection using a DS1233 device (like some other boards).
• AHCT transceivers for relevant address lines A2,A1,A0, and the rest of the Z80 control signals.

Over the next few weeks, I'll play with the 16V8 GAL to enable a 2x and perhaps a 3x clock solution.

Also, will do a layout revision to give the oscillator a bit more breathing space.

But, it is good enough for now.

Cheers, Phillip

[Dean Netherton]

I not quite sure why i find this so cool - i want one now....  Love your work.

Very interesting.  I have been reading and trying to understand how WAIT state processes works. Will the wait states only happen when accessing IO?  And memory access is at full speed?  

Sorry - got to stop myself asking a million questions....

Cheers

Dean

--

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/cf2837e8-d9a9-4d25-b3b8-76f659f629d6o%40googlegroups.com.

[Phillip Stevens]

Dean Netherton wrote:

I not quite sure why i find this so cool - i want one now....  Love your work.

Drop me an email with your mailing address (Australia, right?). Easy to send you a spare board.

(Note the oscillator is a bit crowded, but not a problem to bend the cap/resistors out of the way a bit).

 

Very interesting.  I have been reading and trying to understand how WAIT state processes works. Will the wait states only happen when accessing IO?  And memory access is at full speed?

The Z80 isn't very smart about /WAIT. It can't control how many wait states are inserted, whereas the Z180 can control how many wait states are inserted into either memory or I/O cycles.

All Z80 can do is monitor the /WAIT line, and insert a wait state when it sees that it is low on T2 low transition.

So it is up to the logic to manage the /WAIT line to make sure that enough wait states are inserted. For this conversation, it is all around wait states for the I/O cycles, for peripherals. And, specifically for the SIO/2 that uses IM2, and needs to put the interrupt address on the bus at the right time. It is possibly the "worst case" to manage for a software transparent TURBO Module. Hopefully the GAL will have enough macro-cells available to enable the 1/2 clock from the oscillator to bus, and to count enough clock cycles to insert enough wait cycles.

Cheers, Phillip

[Bill Shen]

I was helping a forum member debugging his RC2014 Pro.  As I look over the dual clock module I noticed the pin assignment of U1 is just right such that a full size oscillator can replace the original 74HCT04.   The reset function can be restored with a  jumper from pin 1 to pin 4 of U1.  So here is a simple way to do 2x Turbo Z80:
1.  Remove U1 of dual clock module
2.  Solder a jumper from pin 1 to pin 4
3.  Replace U1 with full size 14.7456MHz oscillator.

Now RC2014 Pro is running at 14.7MHz with serial port at 230400.   It really works!

It is important the SIO/2 is CMOS version, Z84C42xx, because CMOS SIO/2 can be recklessly overclocked (I had successfully overclock it to 29.5MHz) but not NMOS SIO/2
  Bill