eZ80 vs Z80 timing differences

[Dean Netherton]

 Hello,

I am experimenting with the eZ80 (eZ80F92) processor within my RC2014 platform.

I am having issues with the compact flash module. I only have Spencer’s older V1 module, without the additional delays for RD/WR – not sure if that will help or not.

My understanding is that the non compliance timing issue with CF module, is that the time between IORQ(CF chip-select) and the RD/WR lines when they activate, is way to short to be compliant:

Extracted from the analysis at: https://www.vtsys.pl/interface-compact-flash/

As per Tadeuzd Pycio’s explanation, there needs to be at least 70ns between CS and IORD.

In my design, I have mapped the eZ80 CS2 line for IO to the RC2014 bus’s IORQ line. This line only activates when the eZ80 wants to access an external I/O device. I have also configured more than sufficient wait states and bus-cycle counts. Its configured to drive the bus in Z80 compatible mode.

One interesting aspect of using the CS2 as the signal for IORQ, is the fact that this line goes low way before RD/WR signals go low.

Given this delay, the effective duration between the Compact flash’s CS and IORD is well beyond the 70ns minimum. Also the lines are both held low for more than 160ns.

But it don't work! I seem to get garbled values back.

I am wondering if the issue I have, is as the signals transition to high state. For the eZ80 configuration, both of these lines go high at the same time. No delay at all.

I think there is a subtle difference between Z80 and eZ80, in the timing of the control signals when they transition from low to high. For the eZ80 they seem to go high at the same time, but I think for the Z80 there is a small delay. Not sure though?

I can keep experimenting with this, but I do wonder if anyone here as some insights that might help me – I could be going down the wrong path with my analysis – and completely misunderstood something (I am certainly no expect here – just an amateur for the last few years)

Cheers
Dean

PS: project is on hackaday.io – but they seem to be having a major outage this weekend.

[Tadeusz Pycio]

Hi Dean,

You don't have to suggest just the times for PIO 0 for a fast CPU clock. Fairly new CF cards support PIO 0-4 modes, and they are respectively for this chart:
-PIO 0 70-165-20ns
-PIO 1 50-125-15ns
-PIO 2 30-100-10ns
-PIO 3 30-80-10ns
-PIO 4 25-70-10ns

Therefore, my design maintains PIO 0 timings because the 7.38MHz clock allowed me to do so. When using it with the Z180 clock and 18.432MHz, the higher PIO mode is used.

I would submit that the key time is the delay between /CS and /IORD.

Tadeusz Pycio

[Dean Netherton]

Hi Tadeusz,

Thanks for the reply.

I am sorry, but I am not sure I fully understand what you are saying.

I am using the RomWBW IDE driver - i think its only using the default PIO mode - I guess PIO 0.

The timing summary, though, is handy - thanks

Here is an image from my scope, with the eZ80 doing a repeating I/O Read.  This was generated with the eZ80 running on just a 7Mhz clock. (at 18.432Mhz I can also get much the same timing sequence/periods with the appropriate bus-cycle and wait states)

The Green line is the eZ80 CS2 line that is sent to the RC2014 BUS IORQ line -- so would map to the CS of the CF module

The Blue line is the RD line -- would map to IORD of the CF module

And the Yellow line is the address line from the eZ80 (A0).

The purple line is not currently connected in my logic - This is the IORQ line from the eZ80.  

I am guessing the problem is there is not sufficient setup time for the address line - If I am reading the CF specification right, (tsu) it needs to be min of 30ns

I assumed (without double checking on the spec for the eZ80) I would not need to be combined CS2 with IORQ.

Confusing thing for me is that the CS2 line, is configured to activate for I/O requests and use the Z80 bus mode timings.   The timing of the IORQ line is changed to align with Z80 bus sequencing, but the actual CS2 timing is not impacted by the selected bus mode.

I guess I need to change my design and combine the CS2 signal with IORQ before sending to the RC2014 bus...  (Although I wonder if this might introduce the timing issue common with Z80 builds??)

And I think another potential issues, is that all the signals are deactivated at or near the same time.

Bugger - I already have a new PCB with previous changes on the way... #sad-face

I am not sure I can further 'bodge' my current PCB to hack this design and confirm - already have a lot of bodge wires!  Oh Joy.

Anyway -- interested to know what other think of my analysis - do you think I am on the right path?  

Dean.

[Alan Cox]

On Sun, 9 Jun 2024 at 09:30, Tadeusz Pycio <ta...@wp.pl> wrote:
>
> Hi Dean,
> You don't have to suggest just the times for PIO 0 for a fast CPU clock. Fairly new CF cards support PIO 0-4 modes, and they are respectively for this chart:

You are not in specification unless commands are issued in PIO 0. In
addition PIO modes above 0 are supposed to be negotiated at PIO0 and
the high ones require IORDY.

Most CF cards let you get away with all sorts of out of spec stuff. In
fussier cases with Z180 at least mucking with wait states often lets
you hit suitable timings (especially if you turn on memory refresh
cycles temporarily) not sure about ez80. You've got a fast SPI port
anyway on an ez80 so I doubt it matters, or you could use the PPIDE
which you'll be able to drive at PIO0 speed without trouble.

[Wayne Warthen]

As far as I know, the RomWBW IDE driver does nothing to go beyond PIO mode 0.

I have always been a bit confused about this... Is there some documentation on how you are supposed to negotiate the higher PIO modes?  I have been through the ATA spec and I don't see anything.  It seems to just be a matter of timings that are acceptable depending on the ATA device's PIO mode capability.

Thanks, Wayne

[Bill McMullen]

Wayne: I believe what you're interested in looking at is the SET FEATURES command within the ATA specifications.  After doing an IDENTIFY, you can then find the highest PIO and DMA rates supported by the ATA device then use SET FEATURES to update the PIO & DMA modes.  Note that different devices on the same channel may have different maximum modes.

Some CF cards can support up to PIO-6 but PIO-0 is very slow with a 600ns cycle time and 290ns rd/wr pulse width for registers & 165ns for data.  One of the issues the thread initiator may be dealing with is the long address setup times (70ns) and long write hold time (30ns) in PIO-0.  The setup/hold times in PIO-6 are still 10/5ns which are much longer than the eZ80.

[Alan Cox]

On Sun, 9 Jun 2024 at 19:25, Wayne Warthen <wwar...@gmail.com> wrote:
>
> As far as I know, the RomWBW IDE driver does nothing to go beyond PIO mode 0.
>
> I have always been a bit confused about this... Is there some documentation on how you are supposed to negotiate the higher PIO modes? I have been through the ATA spec and I don't see anything. It seems to just be a matter of timings that are acceptable depending on the ATA device's PIO mode capability.

The theory:

All commands must be sent in PIO0 always
Data transfer rates may be negotiated by set features commands (and
reset on an error reset) after having checked they are available using
IDENTIFY (if IDENTIFY fails as it may do for ATA-1 you have no set
features)

The reality

It's really complicated and pointless doing all the exact PIO timings
in modern hardware when you can build a device that just accepts the
signals anywhere between PIO 0 and 5, so whilst old stuff cares,
random CF cards generally do not. DMA modes are a different kettle of
fish, and UDMA is quite different.

[Wayne Warthen]

On Sunday, June 9, 2024 at 11:48:08 AM UTC-7 mcmull...@gmail.com wrote:

Wayne: I believe what you're interested in looking at is the SET FEATURES command within the ATA specifications.  After doing an IDENTIFY, you can then find the highest PIO and DMA rates supported by the ATA device then use SET FEATURES to update the PIO & DMA modes.  Note that different devices on the same channel may have different maximum modes.

Ah, yes, there it is.  Thank you Bill. 

[Wayne Warthen]

On Sunday, June 9, 2024 at 11:52:50 AM UTC-7 etched...@gmail.com wrote:

The theory:

All commands must be sent in PIO0 always
Data transfer rates may be negotiated by set features commands (and
reset on an error reset) after having checked they are available using
IDENTIFY (if IDENTIFY fails as it may do for ATA-1 you have no set
features)

The reality

It's really complicated and pointless doing all the exact PIO timings
in modern hardware when you can build a device that just accepts the
signals anywhere between PIO 0 and 5, so whilst old stuff cares,
random CF cards generally do not. DMA modes are a different kettle of
fish, and UDMA is quite different.

Thanks Alan. 

[Bill Shen]

As Alan has said, the reality is if a CF disk is capable of PIO 4, it is not going to modify its timings to conform to PIO 0.  In fact, it is quite difficult to alter device’s inherent setup and hold times.  This is why various brands of CF disks have these varying setup, acess, hold timings while all in the default power-on PIO 0 mode.  I’m guilty of running many CF disks in PIO 4 mode and never bothered negotiate for PIO4 mode.

Return to the original issue.  The problem is probably not setup/access/hold times, but rather the signal integrity issue associated with many data line switching at the same time that spiked the control signals.  The solution is in board layout, signal terminations, and filtering.

  Bill

[Dean Netherton]

Hi Bill,

> Return to the original issue.  The problem is probably not setup/access/hold times, but rather the signal integrity issue associated with many data line switching at the same time that spiked the control signals.  The solution is in board layout, signal terminations, and filtering

Sorry?  Why do U think there is  an integrity issue? The times seems to me to align with the ez80 spec.  The control signals  are sequencing as per the z80 bus mode.  I don't see any spiking. If you are referring to all the signals raising at the end at the same time, I think this is as per the spec.  The iorq does go high about 10-15ns before RD and CS2.

Is there something I am not seeing?

Dean

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/c8ab50b0-a745-41a5-9e37-12ce954a0da7n%40googlegroups.com.

[Bill Shen]

 If you look over the past postings, there are numerous issues with CF interface, even with Z80.  Some problem is due to inadequate or even negative setup time, but that can be solved with specific brands of CF, most problems are signal integrity issues which can not be solved with setup timing, but can be partially solved with older, slower brand of CF.  Troubleshooting CF signal integrity issues are a long drawn out process.  Solutions I arrived with has a 100 ohm/100pF filter for CF read strobe, operating CF in 8-bit mode, and 100-ohm source termination resistors for each data lines.  These are my solution, but others have different approaches.  There are no consensus.  I do think now the CF problems are mostly solved for Z80/z180/Z280, but we’ll need to revisit with eZ80.  For my 68K and 6502 systems, I do find hold time an issue that need to be addressed for general solution, but SanDisk brand seems less sensitive to hold time violation.

Bill 

[Bill McMullen]

<All commands must be sent in PIO0 always>

I believe that may be just a mis-interpretation of what you really meant.  I agree that it's best to always assume PIO-0 after power-on, but if the above is true then sending a command  to change to a higher PIO mode would prevent all further commands, including going back to PIO-0.

ATA-ATAPI specs from 2 to 7 have a statement similar to the one in spec 4 where 10.2.1 states "Peripherals reporting support for PIO mode 3 or 4 shall power up in a PIO mode 0, 1, or 2."  Likewise there are separate timing tables for PIO register transfers (Table 29) and data transfers (Table 30) in each of the different modes.  I've used CPLDs to implement PIO 0-4 & DMA 0-2 transfers without any issues sending commands after setting the rates to PIO-4 & DMA-2.

By using a CPLD interface that adheres to the ATA-ATAPI timing specs, I haven't had any issues with various CF cards and 2.5" hard disks, both with and without series resistors.  The ATA-ATAPI spec is very clear about the requirements for pull-up / down & terminations.

[Tom Storey]

For my 68k project I have recently built a CF interface that uses a CPLD to generate timing for modes 0/1, 2/3 and 4 according to spec. It has its own oscillator to be able to guarantee such timing independent of the CPU. The short version of the story is that using this method I was able to interact with some CF cards that didnt work using simpler CPU cycle driven signalling.

I am interested in what Alan says about commands always needing to be issued in PIO mode 0. I hadnt seen this written anywhere, but its probably somewhere in the spec and I have just missed it. I'll have to go digging. Ive been trying to build an "as compatible as possible" CF interface, and since I have an ability to switch the CPLD between PIO modes in software, this would not be too difficult to implement in my driver.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/00e7a6f8-c1c8-481d-bcf4-91c262353683n%40googlegroups.com.

[Alan Cox]

On Mon, 10 Jun 2024 at 08:49, Tom Storey <t...@snnap.net> wrote:
>
> For my 68k project I have recently built a CF interface that uses a CPLD to generate timing for modes 0/1, 2/3 and 4 according to spec. It has its own oscillator to be able to guarantee such timing independent of the CPU. The short version of the story is that using this method I was able to interact with some CF cards that didnt work using simpler CPU cycle driven signalling.
>
> I am interested in what Alan says about commands always needing to be issued in PIO mode 0. I hadnt seen this written anywhere, but its probably somewhere in the spec and I have just missed it.

Yep ... didn't say it very clearly

You always send command bytes in PIO 0 timing until you negotiate a
different timing. If you get a reset on the channel you send in PIO0
and put the timing back. The theory there being that if you set say
PIO4 and for some reason it fails, you get a timeout/errors then you
get the interface back in PIO0 so you can talk to it and try something
else.

In DMA modes commands are still sent in PIO format.

[Tadeusz Pycio]

It seems that the question of mode of operation is a contractual concept. Not every card supports the SET FEATUERES 0x03 command, and there are some CF cards that operate in higher PIO modes without supporting the /IORDY signal (e.g. SunDisk), although the specification for PIO modes 3 and above requires this, correctly operating with timings compatible with higher PIO modes. I don't know how it used to be implemented, but I suspect that the maximum PIO mode and its timing that is included in IDENTIFY DEVICE is always available, regardless of the mode set in SET FEATURES.

[Alan Cox]

On Mon, 10 Jun 2024 at 09:44, Tadeusz Pycio <ta...@wp.pl> wrote:
>
> It seems that the question of mode of operation is a contractual concept. Not every card supports the SET FEATUERES 0x03 command, and there are some CF cards that operate in higher PIO modes without supporting the /IORDY signal (e.g. SunDisk), although the specification for PIO modes 3 and above requires this, correctly operating with timings compatible with higher PIO modes. I don't know how it used to be implemented, but I suspect that the maximum PIO mode and its timing that is included in IDENTIFY DEVICE is always available, regardless of the mode set in SET FEATURES.

The CF specification and ATA specification deviate in a few spots.
PIO6 for example I think is only in CF.

Do not assume the maximum mode listed in identify is always going to
work - it won't for old stuff

[Tom Storey]

I did some digging into IORDY too. I was thinking it would play very nicely into DTACK generation in a 68k system, but the basic conclusion I came to (based on what a number of people told me) is that IORDY may never even be negated by the card unless you are really hammering it at the maximum possible rate, which is probably somewhat impossible to do with a software read/write loop. So even though I can support up to PIO mode 4 which requires IORDY, I dont actually pay any attention to it (could come back to bite me at some point, because you never quite know when the card might negate it...)

And even if I did pay attention to IORDY, I couldnt find any details on how long the card would negate it for and whether this would, for example, run out my bus watchdog timer resulting in a Bus Error. IORDY details seem to be quite thin on the ground.

I have further lofty goals to design and build a CF interface that can do DMA, and in that case I would very likely need to keep an eye on IORDY because I'll be able to read or write to the card much quicker than in a software loop.

On Mon, 10 Jun 2024 at 09:44, Tadeusz Pycio <ta...@wp.pl> wrote:

It seems that the question of mode of operation is a contractual concept. Not every card supports the SET FEATUERES 0x03 command, and there are some CF cards that operate in higher PIO modes without supporting the /IORDY signal (e.g. SunDisk), although the specification for PIO modes 3 and above requires this, correctly operating with timings compatible with higher PIO modes. I don't know how it used to be implemented, but I suspect that the maximum PIO mode and its timing that is included in IDENTIFY DEVICE is always available, regardless of the mode set in SET FEATURES.

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/cf59a310-ec1c-4759-ac85-a4935986a25cn%40googlegroups.com.

[Stefan V. Pantazi]

Interesting discussion! A few months ago I have also struggled with a CF card interface, naively using only a GAL to synthesize the /CS and /IORD and /IORW signals. I was unsuccessful and suspected problems with timing but did not figure out a solution. I went as far as comparing some of the CF signals (/CS, /IORD) timing diagrams with those of a known, working design, namely Bill's Simple80. Despite my attempts to make sure the /CS stays active well before (e.g., more than the critical 70 ns) and after /IORD, that was not enough. I was never able to properly read from the CF card the way Simple80 does. Occasionally the card would respond, but with garbage. As you can see from the attached LA screens, Simple80 has /CS go low over 1ms before /IORD, while in my GAL project I could only make the GAL delay the /IORD only by about 270 ns (a full 3.6 Mhz clock cycle) using registered mode synchronized with the 3.6 MHz clock. So the timing differences are still significant despite being well above the cited limits. Tried different cards too but without much luck. I do not see a way without additional delay flip-flops as done in other designs.

Stefan

[Bill Shen]

The timing looks good.  We’re you able to interface to the CF correctly?  A 100 ohm/100pF filter at CF read strobe may help if you still having problem.

  Bill

[Stefan V. Pantazi]

Yes, I have the 100R and 100pF filter on the CF read signal. /CF_IORD,  /CF_IORW and /CF_CS0 are synthesized by a GAL22V10. GAL inputs are CLK (3.6 Mhz),   A0-A7,  /IORD (/IORQ or /RD), /IOWR  (/IORQ or /WR) and /M1. The GAL is also responsible with decoding additional ports for a SIO, for an AY-3 as well as for a Kempston joystick interface and they all work, so wiring and address line input to the GAL must be ok. I naively thought I could make the CF card interface work as in Simple80 with this setup and fully decode CF card IO ports, especially since the clock was half that of Simple80. When this failed, my workaround for this project was to just add a a SC715 (RCBus) CF card and reprogram everything to work with CF card on port 0x10 and move SIO on 0x84 which is common on RomWBW systems but different than what Simple80 has. What I did not get to try was to add 100R on all data bus lines, but Simple80 did not have those either and it worked. 

I attached images with some pages of the project schematics.

[Stefan V. Pantazi]

OMG, I just noticed a big blunder on my schematic. Looks like A0, A1 and A2 on the CF card interfaces were left unconnected to the corresponding address bus lines. This would explain everything! Sorry about the confusion this created but looking at it again made me realize the error.

[Bill Shen]

 Good, I’m glad you’ve found the most likely source of your problem because your CF timings look good and the filter for CF read is good, too.  I normally designed with CPLD, but Simple80 was a challenge to design to the part list of the cheap $7 kit.  The CF interface was the bare minimum that worked only because the inherent timings of 7.37Mhz Z80.  It turns out Simple80 is the most stable CF design I have, worked with all brands of CF and worked at 14.7Mhz, some even worked at 29.5 Mhz by substituting faster RAM. Interestingly, it also worked down to 3.3V at 7.37Mhz.

Bill

[Stefan V. Pantazi]

Many thanks Bill! If it wasn't for this discussion and for you to confirm the timings, I would not have taken another look at my project schematic. After connecting A0-A2, the  CF card interface seems to work perfectly now. One of my usual tests is to run your bad apple animation from it as the 4 Mb file is long enough requiring continuous reads for a couple of minutes. I guess, after half a year, my project is fixed now and works as originally intended. Better late than never! And thank you all for the interesting discussion that prompted all this.

Stefan

[Bill Shen]

 Great!  Another good test of CF interface is while in CP/M, copying contents of one drive to another drive with verify.

  Bill