[N8VEM: 17029] Increasing of the CPU clock frequency of SBC-V2

[Dr. Wolfgang Kabatzke]

Hi friends,

today I tested my system with SBC-V2, RAM-Floppy, DiskIOV3 and PropIO. This
systems runs actual with 4MHz CPU-Clock. My problem at the moment is that I
have only an 8MHz clock generator in DIP8 format.

So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM, 512kFlash, 82C55-5
and 16C550), but the system never started up. I have no clock generator
with 6MHz. Has anybody checked the maximum clock frequency of such an
system?
Are there any problems known with PropIO and his speed? Normally we hav the
/WAIT-signal to slow down the CPU.

As I remember is on SBC-V2 not WAIT-state logic.

What I must do to improve the system? Normally is LS-TTL usable with such
clock-frequencies...

Best regards


Wolfgang

[Wayne Warthen]

You should have no problem at 8MHz with that hardware. I have run almost
exactly the same configuration up to 16MHz.

--Wayne

Post by Dr. Wolfgang Kabatzke
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy, DiskIOV3 and PropIO.
This systems runs actual with 4MHz CPU-Clock. My problem at the moment is
that I have only an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM, 512kFlash, 82C55-5
and 16C550), but the system never started up. I have no clock generator
with 6MHz. Has anybody checked the maximum clock frequency of such an
system?
Are there any problems known with PropIO and his speed? Normally we hav
the /WAIT-signal to slow down the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is LS-TTL usable with such
clock-frequencies...
Best regards
Wolfgang

[Max Scane]

Except the Prop IO won't go much past 6 MHz ??? Is that still the case?

Cheers!
Max

Sent from my iPad

You should have no problem at 8MHz with that hardware. I have run almost exactly the same configuration up to 16MHz.
--Wayne

Post by Dr. Wolfgang Kabatzke
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy, DiskIOV3 and PropIO. This systems runs actual with 4MHz CPU-Clock. My problem at the moment is that I have only an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM, 512kFlash, 82C55-5 and 16C550), but the system never started up. I have no clock generator with 6MHz. Has anybody checked the maximum clock frequency of such an system?
Are there any problems known with PropIO and his speed? Normally we hav the /WAIT-signal to slow down the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is LS-TTL usable with such clock-frequencies...
Best regards
Wolfgang

--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Wayne Warthen]

Yes, sorry, if the problem is just with the PropIO, then you will have
problems at any speed past 6MHz.

--Wayne

Post by Max Scane
Except the Prop IO won't go much past 6 MHz ??? Is that still the case?
Cheers!
Max
Sent from my iPad
You should have no problem at 8MHz with that hardware. I have run almost
exactly the same configuration up to 16MHz.
--Wayne

Post by Dr. Wolfgang Kabatzke
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy, DiskIOV3 and PropIO.
This systems runs actual with 4MHz CPU-Clock. My problem at the moment is
that I have only an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM, 512kFlash, 82C55-5
and 16C550), but the system never started up. I have no clock generator
with 6MHz. Has anybody checked the maximum clock frequency of such an
system?
Are there any problems known with PropIO and his speed? Normally we hav
the /WAIT-signal to slow down the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is LS-TTL usable with such
clock-frequencies...
Best regards
Wolfgang
--

You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[James Moxham]

Is that because the propIO does not have the latch and wait circuit?

James Moxham

Post by Wayne Warthen
Yes, sorry, if the problem is just with the PropIO, then you will have
problems at any speed past 6MHz.
--Wayne

Post by Max Scane
Except the Prop IO won't go much past 6 MHz ??? Is that still the case?
Cheers!
Max
Sent from my iPad

Post by Wayne Warthen
You should have no problem at 8MHz with that hardware. I have run
almost exactly the same configuration up to >>>16MHz.
--Wayne

Post by Dr. Wolfgang Kabatzke
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy, DiskIOV3 and
PropIO. This systems runs actual with 4MHz >>>>CPU-Clock. My problem
at the moment is that I have only an 8MHz clock generator in DIP8
format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM, 512kFlash,
82C55-5 and 16C550), but the system never >>>>started up. I have no
clock generator with 6MHz. Has anybody checked the maximum clock
frequency of such an >>>>system?
Are there any problems known with PropIO and his speed? Normally we
hav the /WAIT-signal to slow down the >>>>CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is LS-TTL usable with
such clock-frequencies...
Best regards
Wolfgang

--You received this message because you are subscribed to the Google
Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

--You received this message because you are subscribed to the Google
Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Wayne Warthen]

Yup. Respin in the works to address that. Obvioiusly, you have found a
variation to handle that issue in your new design.

--Wayne

Post by James Moxham
Is that because the propIO does not have the latch and wait circuit?
James Moxham
Yes, sorry, if the problem is just with the PropIO, then you will have
problems at any speed past 6MHz.
--Wayne

Post by Max Scane
Except the Prop IO won't go much past 6 MHz ??? Is that still the case?
Cheers!
Max
Sent from my iPad
You should have no problem at 8MHz with that hardware. I have run almost
exactly the same configuration up to 16MHz.
--Wayne

Post by Dr. Wolfgang Kabatzke
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy, DiskIOV3 and PropIO.
This systems runs actual with 4MHz CPU-Clock. My problem at the moment is
that I have only an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM, 512kFlash, 82C55-5
and 16C550), but the system never started up. I have no clock generator
with 6MHz. Has anybody checked the maximum clock frequency of such an
system?
Are there any problems known with PropIO and his speed? Normally we hav
the /WAIT-signal to slow down the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is LS-TTL usable with
such clock-frequencies...
Best regards
Wolfgang
--

You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--

You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Wolfgang Kabatzke]

Hi Wayne,

interesting news...

I have an idea for a WAIT-Logic for You. From my point of view a
WAIT-Logic should synchronized work to the system clock. This depends on
the internal WAIT-mechanism of the Z80 and is undependend from the
CLK-frequency or unknown delays.


Regards

Wolfgang

PS: /MREQ comes in T1, /IORQ in T2... If You use the right Q and /Q of
the FF You may generate an additional /WAIT for more then one T-cycle.
What do You think about this idea? It愀 only an idea, not the 100%
solution...

For an additional WAIT-State at IO-operations we must trigger on the
rising CLK-Edge at the beginning of Tw.

The example shows the WAIT-state generator for Memory access. For
IO-Access we need the same logic with up to 3 FF 74LS74. In this case we
must replace /MREQ with the /CS-Select-Signal of our IO-Logic. Or we can
use 74LS175.

Post by Wayne Warthen
Yup. Respin in the works to address that. Obvioiusly, you have found
a variation to handle that issue in your new design.
--Wayne
Is that because the propIO does not have the latch and wait circuit?
James Moxham
On Mon, 06 Jan 2014 16:53:23 +1030, Wayne Warthen
Yes, sorry, if the problem is just with the PropIO, then you
will have problems at any speed past 6MHz.
--Wayne
Except the Prop IO won't go much past 6 MHz ??? Is that
still the case?
Cheers!
Max
Sent from my iPad
On 6 Jan 2014, at 12:40 pm, Wayne Warthen

Post by Wayne Warthen
You should have no problem at 8MHz with that hardware. I
have run almost exactly the same configuration up to 16MHz.
--Wayne
On Sunday, January 5, 2014 2:56:23 PM UTC-8, Dr. Wolfgang
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy,
DiskIOV3 and PropIO. This systems runs actual with
4MHz CPU-Clock. My problem at the moment is that I
have only an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM,
512kFlash, 82C55-5 and 16C550), but the system never
started up. I have no clock generator with 6MHz. Has
anybody checked the maximum clock frequency of such
an system?
Are there any problems known with PropIO and his
speed? Normally we hav the /WAIT-signal to slow down
the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is
LS-TTL usable with such clock-frequencies...
Best regards
Wolfgang
--
You received this message because you are subscribed to
the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails
Visit this group at http://groups.google.com/group/n8vem
<http://groups.google.com/group/n8vem>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.

--
You received this message because you are subscribed to the
Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from
<javascript:>.
Visit this group at http://groups.google.com/group/n8vem
<http://groups.google.com/group/n8vem>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

--
Dr.-Ing. Wolfgang Kabatzke
Hansastrasse 9

DE - 21 502 Geesthacht
Deutschland / Germany

Phone: [phone] NEW!!!

[Wolfgang Kabatzke]

Hi James, hi Wayne,

I have here an teszed example of an Z80-IO-WAIT-State-Logic. I think
this could help to improve the PropIO. It works up from 6MHz... The
actual design is for maximal 4 WAIT-States. If You use all outputs of
the shift register itŽs for up to 8 WAIT-States. Itßs conform to Z80
system design features (clock synchron).

Best regards


Wolfgang

Post by James Moxham
Is that because the propIO does not have the latch and wait circuit?
James Moxham
Yes, sorry, if the problem is just with the PropIO, then you will
have problems at any speed past 6MHz.
--Wayne
Except the Prop IO won't go much past 6 MHz ??? Is that still the case?
Cheers!
Max
Sent from my iPad

Post by Wayne Warthen
You should have no problem at 8MHz with that hardware. I
have run almost exactly the same configuration up to 16MHz.
--Wayne
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy,
DiskIOV3 and PropIO. This systems runs actual with 4MHz
CPU-Clock. My problem at the moment is that I have only
an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM,
512kFlash, 82C55-5 and 16C550), but the system never
started up. I have no clock generator with 6MHz. Has
anybody checked the maximum clock frequency of such an
system?
Are there any problems known with PropIO and his speed?
Normally we hav the /WAIT-signal to slow down the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is LS-TTL
usable with such clock-frequencies...
Best regards
Wolfgang
--
You received this message because you are subscribed to the
Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from
<javascript:>.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google
Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

--
Dr.-Ing. Wolfgang Kabatzke
Hansastrasse 9

DE - 21 502 Geesthacht
Deutschland / Germany

Phone: [phone] NEW!!!

[Wayne Warthen]

Hi Wolfgang,

If I have understood what you propose correctly, you are talking about a
wait state generator that would be programmed to generate a fixed number of
wait states.

The issue is that there is no good way to predict the wait time required.
Essentially, once the PropIO has accepted a command, it will go off and
doa bunch of work that will very substantially in length of time. I think
the use of a latch on /WAIT which is released by the PropIO is preferable
so that the wait will only last as long as needed for any particular
operation. Additionally, by having the Propeller release the wait state,
it will automatically work with any speed of CPU without configuration.

If I have not understood your solution, please clarify it for me.

Thanks,

Wayne

Post by Wolfgang Kabatzke
Hi James, hi Wayne,
I have here an teszed example of an Z80-IO-WAIT-State-Logic. I think this
could help to improve the PropIO. It works up from 6MHz... The actual
design is for maximal 4 WAIT-States. If You use all outputs of the shift
register itŽs for up to 8 WAIT-States. Itßs conform to Z80 system design
features (clock synchron).
Best regards
Wolfgang
Is that because the propIO does not have the latch and wait circuit?
James Moxham
Yes, sorry, if the problem is just with the PropIO, then you will have
problems at any speed past 6MHz.
--Wayne

Post by Max Scane
Except the Prop IO won't go much past 6 MHz ??? Is that still the case?
Cheers!
Max
Sent from my iPad
You should have no problem at 8MHz with that hardware. I have run
almost exactly the same configuration up to 16MHz.
--Wayne

Post by Dr. Wolfgang Kabatzke
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy, DiskIOV3 and PropIO.
This systems runs actual with 4MHz CPU-Clock. My problem at the moment is
that I have only an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM, 512kFlash,
82C55-5 and 16C550), but the system never started up. I have no clock
generator with 6MHz. Has anybody checked the maximum clock frequency of
such an system?
Are there any problems known with PropIO and his speed? Normally we hav
the /WAIT-signal to slow down the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is LS-TTL usable with
such clock-frequencies...
Best regards
Wolfgang
--

You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--

You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
Dr.-Ing. Wolfgang Kabatzke
Hansastrasse 9
DE - 21 502 Geesthacht
Deutschland / Germany
Phone: [phone] NEW!!!

[Borut]

Hi Wayne,

Such a wait state generator would be a very interesting addition for a Z80
to ECB adapter. It would for example enable Zeta to run at full 20Mhz and
still access
I/O boards on ECB bus at ~10 Mhz.

Cheers,

Bo/

Post by Wayne Warthen
Hi Wolfgang,
If I have understood what you propose correctly, you are talking about a
wait state generator that would be programmed to generate a fixed number of
wait states.
The issue is that there is no good way to predict the wait time required.
Essentially, once the PropIO has accepted a command, it will go off and
doa bunch of work that will very substantially in length of time. I think
the use of a latch on /WAIT which is released by the PropIO is preferable
so that the wait will only last as long as needed for any particular
operation. Additionally, by having the Propeller release the wait state,
it will automatically work with any speed of CPU without configuration.
If I have not understood your solution, please clarify it for me.
Thanks,
Wayne

Post by Wolfgang Kabatzke
Hi James, hi Wayne,
I have here an teszed example of an Z80-IO-WAIT-State-Logic. I think this
could help to improve the PropIO. It works up from 6MHz... The actual
design is for maximal 4 WAIT-States. If You use all outputs of the shift
register itŽs for up to 8 WAIT-States. Itßs conform to Z80 system design
features (clock synchron).
Best regards
Wolfgang
Is that because the propIO does not have the latch and wait circuit?
James Moxham
Yes, sorry, if the problem is just with the PropIO, then you will have
problems at any speed past 6MHz.
--Wayne

Post by Max Scane
Except the Prop IO won't go much past 6 MHz ??? Is that still the case?
Cheers!
Max
Sent from my iPad
You should have no problem at 8MHz with that hardware. I have run
almost exactly the same configuration up to 16MHz.
--Wayne

Post by Dr. Wolfgang Kabatzke
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy, DiskIOV3 and
PropIO. This systems runs actual with 4MHz CPU-Clock. My problem at the
moment is that I have only an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM, 512kFlash,
82C55-5 and 16C550), but the system never started up. I have no clock
generator with 6MHz. Has anybody checked the maximum clock frequency of
such an system?
Are there any problems known with PropIO and his speed? Normally we hav
the /WAIT-signal to slow down the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is LS-TTL usable with
such clock-frequencies...
Best regards
Wolfgang
--

You received this message because you are subscribed to the Google
Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--

You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
Dr.-Ing. Wolfgang Kabatzke
Hansastrasse 9
DE - 21 502 Geesthacht
Deutschland / Germany
Phone: [phone] NEW!!!

[p***@public.gmane.org]

Hi Borut,

As Wayne outlined, different devices will need different WAIT delays. As the
WAIT signal is already available on the ECB bus, you can use it even today
to inject custom WAIT delays for each of your peripherals. The downside is
that each peripheral will need its own WAIT-delay circuit.

If such 1 circuit is built to inject delays to all IO-transfers, there are 2
main troubles:
1. All delays need to be deterministic and precisely known.
2. The circuit will work with the speed of the slowest device.

I personally think that most people would be more motivated to keep the
performance of their fast peripherals and solve the issue only for the slower
ones, which for me means 1 WAIT-delay for each peripheral.

Regards,
picmaster

-------------------------------------
Mail.BG: Безплатен e-mail адрес. Най-добрите характеристики на българския пазар - 20 GB пощенска кутия, 1 GB прикрепен файл, безплатен POP3, мобилна версия, SMS известяване и други. http://mail.bg

[Borut]

@picmaster

Different devices on ECB bus in general don't need separate wait logic,
because they operate
in synchronous mode. Those that don't already incorporate wait cycle logic
(like PropIO).
There is an upper limit to clock speed with systems that work over ECB bus,
somewhere around 10-12 MHz.
Zeta on the other hand, beeing self contained can easily run at 20MHz, i
have one that even runs at 22.1MHz.
If i would extend it with an ECB bus adapter i would prefer it if it would
still run at the same speed internally,
when accessing ram, rom and internal i/o, but for ECB bus access i would
slow it down with a wait cycle or two.
But the bus would still work in synchronous mode.
Because the upper limit to ECB bus speed is probably due to parasitic
capacitances, ringing, signal rise times etc. wait logic on I/O boards
wouldn't solve the problem, since the signals would already arrive at the
board delayed and deformed and wait logic would react too late, much in the
same way that Wolfgang's Propeller on PropIO sets the WAIT line
too late (but that is because it is set in software).
Of course, if the ECB board would set the WAIT signal (asynchronous
cycle), then additional wait cycles
would be inserted, as they are today in SBC board.

Best regards,
Bo/

Post by p***@public.gmane.org
Hi Borut,
As Wayne outlined, different devices will need different WAIT delays. As the
WAIT signal is already available on the ECB bus, you can use it even today
to inject custom WAIT delays for each of your peripherals. The downside is
that each peripheral will need its own WAIT-delay circuit.
If such 1 circuit is built to inject delays to all IO-transfers, there are 2
1. All delays need to be deterministic and precisely known.
2. The circuit will work with the speed of the slowest device.
I personally think that most people would be more motivated to keep the
performance of their fast peripherals and solve the issue only for the slower
ones, which for me means 1 WAIT-delay for each peripheral.
Regards,
picmaster
-------------------------------------
Mail.BG: Áåçïëàòåí e-mail àäðåñ. Íàé-äîáðèòå õàðàêòåðèñòèêè íà áúëãàðñêèÿ
ïàçàð - 20 GB ïîùåíñêà êóòèÿ, 1 GB ïðèêðåïåí ôàéë, áåçïëàòåí POP3, ìîáèëíà
âåðñèÿ, SMS èçâåñòÿâàíå è äðóãè. http://mail.bg

[marko.lukat-948ZrgdBihT+G+]

much in the same way that Wolfgang's Propeller on PropIO sets the WAIT line

Currently that's a 7 cycle delay. I've found a way to get that down to 3. What's the proper way to post code here?

Thanks,
Marko

[Borut]

Hi Marko!

My guess would be to open a new topic and post the code snippet(s) with
some commentary.
Then all those who work on Propeller code could adapt it.

Bo/

Post by marko.lukat-948ZrgdBihT+G+

much in the same way that Wolfgang's Propeller on PropIO sets the WAIT

line
Currently that's a 7 cycle delay. I've found a way to get that down to 3.
What's the proper way to post code here?
Thanks,
Marko

[Wolfgang Kabatzke]

Hi Wayne,

this WAIt-state-generator is implemented in a similiar form on DISKIO
V1. The solution works with jumper and You can say no WAIT, 1 WAIt, 2
WAit etc... And the maximum time of WAIT is limited, automatically
(automatic TIME-OUT for WAIT).

In the other form, I called this "ping-pong" WAIT could the case occur
that an firmware error f.e. on propeller generated an static WAIt and
the system is out of function. So, what is better now. ...

On the actual design of propeller is an output which drives the
WAIT-line for the time which propeller gives. I never saw pulses on the
WAIT-line and thatŽs why I have speed problems with my systems and IŽm
nit sure that Your solution may fix all problems.

ItŽs only my point of view.

This WAIt-state generator I implemented on my personal ECB-CPU for IO-
and Memory-Access (2 circuits). Ok, the best way is to use the system
with fast IC etc. But often we have only slow IC and especially for
testing is such circuit helpful.

It was an idea.

Best regards


Wolfgang

Post by Wayne Warthen
Hi Wolfgang,
If I have understood what you propose correctly, you are talking about
a wait state generator that would be programmed to generate a fixed
number of wait states.
The issue is that there is no good way to predict the wait time
required. Essentially, once the PropIO has accepted a command, it
will go off and doa bunch of work that will very substantially in
length of time. I think the use of a latch on /WAIT which is released
by the PropIO is preferable so that the wait will only last as long as
needed for any particular operation. Additionally, by having the
Propeller release the wait state, it will automatically work with any
speed of CPU without configuration.
If I have not understood your solution, please clarify it for me.
Thanks,
Wayne
Hi James, hi Wayne,
I have here an teszed example of an Z80-IO-WAIT-State-Logic. I
think this could help to improve the PropIO. It works up from
6MHz... The actual design is for maximal 4 WAIT-States. If You use
all outputs of the shift register itŽs for up to 8 WAIT-States.
Itßs conform to Z80 system design features (clock synchron).
Best regards
Wolfgang

Post by James Moxham
Is that because the propIO does not have the latch and wait circuit?
James Moxham
On Mon, 06 Jan 2014 16:53:23 +1030, Wayne Warthen
Yes, sorry, if the problem is just with the PropIO, then you
will have problems at any speed past 6MHz.
--Wayne
Except the Prop IO won't go much past 6 MHz ??? Is that
still the case?
Cheers!
Max
Sent from my iPad
On 6 Jan 2014, at 12:40 pm, Wayne Warthen

Post by Wayne Warthen
You should have no problem at 8MHz with that hardware.
I have run almost exactly the same configuration up to
16MHz.
--Wayne
On Sunday, January 5, 2014 2:56:23 PM UTC-8, Dr.
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy,
DiskIOV3 and PropIO. This systems runs actual with
4MHz CPU-Clock. My problem at the moment is that I
have only an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns
SRAM, 512kFlash, 82C55-5 and 16C550), but the system
never started up. I have no clock generator with
6MHz. Has anybody checked the maximum clock
frequency of such an system?
Are there any problems known with PropIO and his
speed? Normally we hav the /WAIT-signal to slow down
the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is
LS-TTL usable with such clock-frequencies...
Best regards
Wolfgang
--
You received this message because you are subscribed to
the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails
Visit this group at http://groups.google.com/group/n8vem
<http://groups.google.com/group/n8vem>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.

--
You received this message because you are subscribed to the
Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from
<javascript:>.
Visit this group at http://groups.google.com/group/n8vem
<http://groups.google.com/group/n8vem>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
You received this message because you are subscribed to the
Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it,
<javascript:>.
Visit this group at http://groups.google.com/group/n8vem
<http://groups.google.com/group/n8vem>.
For more options, visit https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.

--
Dr.-Ing. Wolfgang Kabatzke
Hansastrasse 9
DE - 21 502 Geesthacht
Deutschland / Germany
Phone: [phone] NEW!!!
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

--
Dr.-Ing. Wolfgang Kabatzke
Hansastrasse 9

DE - 21 502 Geesthacht
Deutschland / Germany

Phone: [phone] NEW!!!

[James Moxham (Dr_Acula)]

Well this has me thinking - what is the *simplest* wait state circuit?

Ok, one circuit we have uses a '74 latch. Why is there a latch? Well it is
to trap an /IORQ to a particular port and then make /WAIT low until it is
reset by another circuit. The latch is there to make sure it traps the Z80
in a wait state no matter what the speed is.

But - what happens next? How does the slave circuit know that the Z80 is in
a wait state? Well, because the decoded port address has gone low.

Now, if the slave is reading the decoded port as being low, the Z80 must
have been trapped in a wait state as soon as the port was addressed. If it
had clocked a few more clocks, the port address would no longer be valid
nor would the data bus.

So, I am thinking that you do not need a latch. All you need is an OR gate.
The decoded address is one input to the OR gate, the slave clear is the
other input, and the output goes to /WAIT. In normal operation the slave
input to the OR gate is low. As soon as the port is addressed, /WAIT goes
low and the Z80 goes into a WAIT state. The Z80 becomes the latch.

If this logic is correct, then the next thing to consider is that the ECB
bus /WAIT pin is not the same as the Z80 pin and has the states LOW and
HiZ, rather than LOW and HIGH. So you need a 7406. But then we need two
chips - '32 and '06. How about a 74LS125. Connect the enable to the input
and it changes L/H to L/HiZ. And looking at the logic, I think you can use
another 125 as an OR gate. Connect one input to the A input, the other
input to the C input, and have a 10k pullup on the output. The only time
the output is low is if both inputs are low.

Maybe I'm missing something, but I think it can be done with one '125 chip,
using two gates.

Am I missing something?

Cheers, James Moxham

[James Moxham (Dr_Acula)]

Can a wait state generator be even simpler again?

I found someone doing something similar with an OR gate here
http://www.blake-foster.com/project.php?p=36 and scroll about half way
down the page.

Next challenge - can we save a propeller pin?

Right now we have one propeller pin detecting that a port has been
addressed and another pin resetting a latch circuit to tell the Z80 to
restart. Maybe these can be the same pin?

Propeller pins can be configured in software as inputs or outputs. When it
is an input it is HiZ. See attached schematic with a description of the
various logic states. The 1k resistor is there because there is a short
time, maybe 1us, during resetting where the propeller pin is high and the
port decode logic is low.

Would it work?

[Wolfgang Kabatzke]

This post might be inappropriate. Click to display it.

[James Moxham]

Hi Wolfgang,

I recognise the font of the PIN DESCRIPTIONS document you attached, I have
that Zilog Data Book sitting right behind me in my office!

I agree we need to work out the Power On status. The propeller boots up
with all pins HiZ, but it can be programmed to poll repeatedly the port
request, transfer data and then release the Z80. It is possible to program
the propeller to always release the /wait line after a short delay, so
there is no problem with the Z80 crashing.

Ok, bouncing on the HC125. I agree that could be a problem. 74LS06 is
good, but it inverts. There are several 'open collector' chips
(01,05,06,07,09,38) ref http://www.futurlec.com/IC74LS00Series.shtml

To decode the I/O port, a LS688 is a generic solution that can be set to
read any port with 8 jumpers. The output is LOW, so we need a non
inverting gate. So use the LS07 instead of the LS06.

Will this work at 10Mhz? If the appropriate port is decoded, the absolute
maximum delay for the LS688 is 30ns
(http://www.futurlec.com/74LS/74LS688.shtml) and the maximum delay for the
LS07 is another 30ns. So max 60ns and typical delay is more like max 32ns.
So this should be fast enough.

Do you see any problems with the attached schematic?

Cheers, James Moxham






On Thu, 09 Jan 2014 04:29:26 +1030, Wolfgang Kabatzke

Post by Wolfgang Kabatzke
Hi James,
"yes".
A FF has two states and itŽs not sure after Power-On that an FF is in
the "right state". It could be in state 1 or in state 2. I "learned"
this >ws I worked as hardware developer. So You need in each case if You
use a FF to control states, RAM etc, an input from /RESET to >guarantee
that the FF is after Power ON in the right state. So it could be that
the computer is after Power On complete blocked by WAIT >from the
WAIT-Logic.
74X125 is nit the good and right solution. Each transition from L/H to
L/Hi is combined with bouncings/debouncings on the signal line.

Normally is on each ECB-CPU the /WAIT-line direct connected to the

Z80-WAIT-Pin. If there is trouble on the line the Z80 may be come >into
confued situations. Ok, in SBC-V2 the WAIt-line is driven by 74x244, but
this is not normal because we have additional delays and >we need
additional resistor(s) on the ECB-Bus because WAIT is Wired-(N)OR.
I use each time 74x06 or 74x03 . And in the CPU-Spec is written "Input,
active low", not "input, active low, 3-state".
I see that I must look for another solution. My idea was the improving
of my ECB-System to minimum 10MHz. PropIO is the "handbrake >for my
Z80-Mercedes / Porsche" and I donŽt like this way. So I ordered the
8563-IC + 82C42 and IŽm switching to Colour-VDU.
A solution could be to leave the polling modus when we use ProIO and use
the Interrupt. So we have an plus in speed because we have >only WAIT if
there is an reals communication between Z80 and PropIO.
What Do You think?
Best regards
Wolfgang

Well this has me thinking - what is the *simplest* wait state circuit?
Ok, one circuit we have uses a '74 latch. Why is there a latch? Well it
is to trap an /IORQ to a particular port and then >>make /WAIT low
until it is reset by another circuit. The latch is there to make sure
it traps the Z80 in a wait state no >>matter what the speed is.
But - what happens next? How does the slave circuit know that the Z80
is in a wait state? Well, because the decoded port >>address has gone
low.
Now, if the slave is reading the decoded port as being low, the Z80
must have been trapped in a wait state as soon as the >>port was
addressed. If it had clocked a few more clocks, the port address would
no longer be valid nor would the data >>bus.
So, I am thinking that you do not need a latch. All you need is an OR
gate. The decoded address is one input to the OR >>gate, the slave
clear is the other input, and the output goes to /WAIT. In normal
operation the slave input to the OR gate >>is low. As soon as the port
is addressed, /WAIT goes low and the Z80 goes into a WAIT state. The
Z80 becomes the >>latch.
If this logic is correct, then the next thing to consider is that the
ECB bus /WAIT pin is not the same as the Z80 pin and >>has the states
LOW and HiZ, rather than LOW and HIGH. So you need a 7406. But then we
need two chips - '32 and '06. >>How about a 74LS125. Connect the enable
to the input and it changes L/H to L/HiZ. And looking at the logic, I
think you >>can use another 125 as an OR gate. Connect one input to the
A input, the other input to the C input, and have a 10k >>pullup on the
output. The only time the output is low is if both inputs are low.
Maybe I'm missing something, but I think it can be done with one '125
chip, using two gates.
Am I missing something?
Cheers, James Moxham
--You received this message because you are subscribed to the Google
Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

--Dr.-Ing. Wolfgang Kabatzke
Hansastrasse 9
DE - 21 502 Geesthacht
Deutschland / Germany
Phone: [phone] NEW!!!

[Wolfgang Kabatzke]

Hi James,

Your first design with the RS-FF was nit so far of my solution...



Your solution with R and 7407 is from my point of is not "glitch-free".




IO-decode could be High again before P0 is LOW...... Trouble may be ....

What do You think about my idea?

Best regards

Wolfgang
--
Dr.-Ing. Wolfgang Kabatzke
Hansastrasse 9

DE - 21 502 Geesthacht
Deutschland / Germany

Phone: [phone] NEW!!!

[James Moxham]

On Fri, 10 Jan 2014 05:40:18 +1030, Wolfgang Kabatzke

Post by Wolfgang Kabatzke
IO-decode could be High again before P0 is LOW...... Trouble may be ....

I don't think that can ever happen.

If IO decode goes high before P0 goes low, that means the Z80 has missed
its own /wait signal. Whether there is a latch, or an 06, or an 07, if the
/wait signal is being missed then the data lines will no longer be valid
so you won't be able to read what is on them. So having a latch does not
help in this situation. In fact, a latch may be worse as it may take
slower to respond compared to an 06.

Think about it with the propeller removed. Of course, if you make the
clock speed too high the ECB bus will ring etc, but that has nothing to do
with the propeller speed.

The propeller has the job of reading/writing to the data bus, and it
resets the wait state. But the setting of the wait state is not done by
the propeller - that is independent of the propeller speed.

I think that is correct, anyway.

Cheers, James

[Sergey]

Just for the record - without PropIO I was able to run my SBC V2 + Disk IO
V3 on 12 MHz... It didn't work on 16 MHz though...

Post by Dr. Wolfgang Kabatzke
Hi friends,
today I tested my system with SBC-V2, RAM-Floppy, DiskIOV3 and PropIO.
This systems runs actual with 4MHz CPU-Clock. My problem at the moment is
that I have only an 8MHz clock generator in DIP8 format.
So I tested with 8MHz (I used a 10MHz Z80, 55ns SRAM, 512kFlash, 82C55-5
and 16C550), but the system never started up. I have no clock generator
with 6MHz. Has anybody checked the maximum clock frequency of such an
system?
Are there any problems known with PropIO and his speed? Normally we hav
the /WAIT-signal to slow down the CPU.
As I remember is on SBC-V2 not WAIT-state logic.
What I must do to improve the system? Normally is LS-TTL usable with such
clock-frequencies...
Best regards
Wolfgang