In the Apple IIe #2 tech notes for DMA, they state the following:

"...there will be some skew between edges of the 7 M clock and the timing signals from the PAL, such as the edges of 0o or 01. This skew means the 7 M clock edge may rise as much as 20 ns before, or 5 ns after, the 0o falling edge. "
Is this skew only at the 0o falling edge? I ask because I'm using the 7m for timing when to read/write.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/4/2022 7:52 AM, Anthony Ortiz wrote:

In the Apple IIe #2 tech notes for DMA, they state the following:

"...there will be some skew between edges of the 7 M clock and the timing signals from the PAL, such as the edges of 0o or 01. This skew means the 7 M clock edge may rise as much as 20 ns before, or 5 ns after, the 0o falling edge."

Yeah, that's a pretty ambiguous note.

Is this skew only at the 0o falling edge? I ask because I'm using the 7m for timing when to read/write.

It is my understanding that skew means that one clock signal is delayed
in relation to another. In other words 7M and phase0 had at one time
been in sync with each other (that is, the rising edge of phase0 happens
at exactly the same time as a rising edge of 7M) but phase0 became
delayed because it went through more circuitry than 7M.

People who know more about hardware than me should jump in here if I'm
wrong.

Anyway, to answer your question, I think that both the rising and
falling edges of phase0 would be skewed.

Charlie

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <tchp0p$2um30$[email protected]>,
Charlie <[email protected]> wrote:

On 8/4/2022 7:52 AM, Anthony Ortiz wrote:

In the Apple IIe #2 tech notes for DMA, they state the following:

"...there will be some skew between edges of the 7 M clock and the

timing signals from the PAL, such as the edges of 0o or 01. This skew
means the 7 M clock edge may rise as much as 20 ns before, or 5 ns
after, the 0o falling edge."

Yeah, that's a pretty ambiguous note.

Is this skew only at the 0o falling edge? I ask because I'm using the

7m for timing when to read/write.

It is my understanding that skew means that one clock signal is delayed
in relation to another. In other words 7M and phase0 had at one time
been in sync with each other (that is, the rising edge of phase0 happens
at exactly the same time as a rising edge of 7M) but phase0 became
delayed because it went through more circuitry than 7M.

People who know more about hardware than me should jump in here if I'm
wrong.

Anyway, to answer your question, I think that both the rising and
falling edges of phase0 would be skewed.

Charlie

Clock signals are not meant to capture each other, and it's tricky to
use the "wrong" clock signal to capture data driven by a different clock.
By specifying skew, Apple's reminding people about these basic rules.

I think it's just a hint that you should be careful trying to latch
bus data using 7M instead of ph0. Also, one popular suggestion was to delay ph0 using 7M to latch it to create a new clock edge for better timing (I
think for hold time reasons)--and this note is basically saying you need to
use the falling edge of 7M to do that since the rising edge of 7M cannot capture ph0 properly.

It's best if you use ph0 to capture bus data, possibly delayed for hold
time. Directly using 7M is problematic, and you'll need to qualify it
to avoid metastability issues, and to properly qualify it would seem to
take a lot of TTL logic.

Kent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/7/2022 11:24 PM, Kent Dickey wrote:

In article <tchp0p$2um30$[email protected]>,
Charlie <[email protected]> wrote:

On 8/4/2022 7:52 AM, Anthony Ortiz wrote:

In the Apple IIe #2 tech notes for DMA, they state the following:

"...there will be some skew between edges of the 7 M clock and the

timing signals from the PAL, such as the edges of 0o or 01. This skew
means the 7 M clock edge may rise as much as 20 ns before, or 5 ns
after, the 0o falling edge."

Yeah, that's a pretty ambiguous note.

Is this skew only at the 0o falling edge? I ask because I'm using the

7m for timing when to read/write.

It is my understanding that skew means that one clock signal is delayed
in relation to another. In other words 7M and phase0 had at one time
been in sync with each other (that is, the rising edge of phase0 happens
at exactly the same time as a rising edge of 7M) but phase0 became
delayed because it went through more circuitry than 7M.

People who know more about hardware than me should jump in here if I'm
wrong.

Anyway, to answer your question, I think that both the rising and
falling edges of phase0 would be skewed.

Charlie

Clock signals are not meant to capture each other, and it's tricky to
use the "wrong" clock signal to capture data driven by a different clock.
By specifying skew, Apple's reminding people about these basic rules.

I think it's just a hint that you should be careful trying to latch
bus data using 7M instead of ph0. Also, one popular suggestion was to delay ph0 using 7M to latch it to create a new clock edge for better timing (I think for hold time reasons)--and this note is basically saying you need to use the falling edge of 7M to do that since the rising edge of 7M cannot capture ph0 properly.

Okay, thanks for the clarification.

It's best if you use ph0 to capture bus data, possibly delayed for hold
time. Directly using 7M is problematic, and you'll need to qualify it
to avoid metastability issues, and to properly qualify it would seem to
take a lot of TTL logic.

Kent

By 'qualify' do you mean synchronizing the signals?
I use two flip-flops to synchronize an Apple II slot signal such as
phase0 to the card's 'system' clock (which is the Carte Blanche II 'on
board' clock).

For what it is worth, I would try to avoid using DMA if I was designing
a card to work on all slotted Apples. There seems to be a number of differences in the way the different models need to do DMA. I doubt it
is worth the effort. But then I don't know anything about accelerators.

Charlie

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For what it is worth, I would try to avoid using DMA if I was designing
a card to work on all slotted Apples. There seems to be a number of differences in the way the different models need to do DMA. I doubt it
is worth the effort. But then I don't know anything about accelerators.

Charlie

Is there a way to make a slottable replacement processor that didn't use DMA?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/9/2022 9:41 PM, Anthony Ortiz wrote:

For what it is worth, I would try to avoid using DMA if I was designing
a card to work on all slotted Apples. There seems to be a number of
differences in the way the different models need to do DMA. I doubt it
is worth the effort. But then I don't know anything about accelerators.

Charlie

Is there a way to make a slottable replacement processor that didn't use DMA?

Apparently there is.
This link shows several accelerators. Most are not DMA compatible.

https://en.wikipedia.org/wiki/Apple_II_accelerators

I believe the only one that is DMA compatible and uses a slot is a ZipGSX.

Anyway, what I meant is that since you stated that you wanted your card
to be usable on all slotted Apple II models, DMA would make designing it
more difficult.

Charlie

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Apparently there is.
This link shows several accelerators. Most are not DMA compatible.

https://en.wikipedia.org/wiki/Apple_II_accelerators

I believe the only one that is DMA compatible and uses a slot is a ZipGSX.

Anyway, what I meant is that since you stated that you wanted your card
to be usable on all slotted Apple II models, DMA would make designing it more difficult.

Charlie

I think what they mean by 'DMA compatible' is that the cards are compatible with other cards that use DMA. For now, my accelerator isn't DMA compatible either because I have DMA active all the time and don't respect any of the other cards that want to
use DMA. To make mine DMA compatible I would have to listen to other cards DMA requests and share the bus with them according to the DMA sharing protocols. I believe that's what they mean by 'DMA compatible', because Transwarp definitely uses DMA but I
know they went the distance to share the bus with other DMA cards, thus earning the 'DMA compatible' seal of approval.

This is a partially educated guess on my part though, so someone correct me if I'm wrong here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/9/2022 10:53 PM, Anthony Ortiz wrote:

Apparently there is.
This link shows several accelerators. Most are not DMA compatible.

https://en.wikipedia.org/wiki/Apple_II_accelerators

I believe the only one that is DMA compatible and uses a slot is a ZipGSX. >>
Anyway, what I meant is that since you stated that you wanted your card
to be usable on all slotted Apple II models, DMA would make designing it
more difficult.

Charlie

I think what they mean by 'DMA compatible' is that the cards are compatible with other cards that use DMA. For now, my accelerator isn't DMA compatible either because I have DMA active all the time and don't respect any of the other cards that want to

use DMA. To make mine DMA compatible I would have to listen to other cards DMA requests and share the bus with them according to the DMA sharing protocols. I believe that's what they mean by 'DMA compatible', because Transwarp definitely uses DMA but I
know they went the distance to share the bus with other DMA cards, thus earning the 'DMA compatible' seal of approval.

This is a partially educated guess on my part though, so someone correct me if I'm wrong here.

I won't argue the point since I don't really know how they work.

Charlie

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <tcuuk4$1h6sc$[email protected]>,
Charlie <[email protected]> wrote:

On 8/7/2022 11:24 PM, Kent Dickey wrote:

In article <tchp0p$2um30$[email protected]>,
Charlie <[email protected]> wrote:

On 8/4/2022 7:52 AM, Anthony Ortiz wrote:

In the Apple IIe #2 tech notes for DMA, they state the following:

"...there will be some skew between edges of the 7 M clock and the

timing signals from the PAL, such as the edges of 0o or 01. This skew
means the 7 M clock edge may rise as much as 20 ns before, or 5 ns
after, the 0o falling edge."

[snip]

It's best if you use ph0 to capture bus data, possibly delayed for hold
time. Directly using 7M is problematic, and you'll need to qualify it
to avoid metastability issues, and to properly qualify it would seem to
take a lot of TTL logic.

Kent

By 'qualify' do you mean synchronizing the signals?
I use two flip-flops to synchronize an Apple II slot signal such as
phase0 to the card's 'system' clock (which is the Carte Blanche II 'on
board' clock).

"Qualify" means using logic gates (for example) to avoid capturing data
in a flip-flop when the data might be changing. Imagine you have a fast
clock, and want to capture data from a slower domain, but which lines up
with one of your edges. Have logic create a qualifier signal that is
0 during this fast clock period, and AND the data with it. Now, we avoid latching a signal when it could be changing.

Metastability is not well understood by most people since almost every
detailed description of how to avoid metastability that I've read has
had at least a small bug. A common flaw is if you synthesize logic and
don't have a set of timing constraints between clock domains, you may
not be avoiding metastability. Paths can (and do) take "scenic routes"
if you have no constraints. "Synthesis" is not an issue with TTL since
you're hand placing components.

Sometimes you just have to capture data as its changing, and that's
when the 2-3 flip-flops in a row rule come into play. Note you can really
only do one bit like this, to move a counter requires gray coding and more care.

The thing about metastability is it's rare--if you have a problem, it may
be hard to detect in practical testing.

Kent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/11/2022 12:16 AM, Kent Dickey wrote:

In article <tcuuk4$1h6sc$[email protected]>,
Charlie <[email protected]> wrote:

On 8/7/2022 11:24 PM, Kent Dickey wrote:

In article <tchp0p$2um30$[email protected]>,
Charlie <[email protected]> wrote:

On 8/4/2022 7:52 AM, Anthony Ortiz wrote:

In the Apple IIe #2 tech notes for DMA, they state the following:

"...there will be some skew between edges of the 7 M clock and the

timing signals from the PAL, such as the edges of 0o or 01. This skew
means the 7 M clock edge may rise as much as 20 ns before, or 5 ns
after, the 0o falling edge."

[snip]

It's best if you use ph0 to capture bus data, possibly delayed for hold
time. Directly using 7M is problematic, and you'll need to qualify it
to avoid metastability issues, and to properly qualify it would seem to
take a lot of TTL logic.

Kent

By 'qualify' do you mean synchronizing the signals?
I use two flip-flops to synchronize an Apple II slot signal such as
phase0 to the card's 'system' clock (which is the Carte Blanche II 'on
board' clock).

"Qualify" means using logic gates (for example) to avoid capturing data
in a flip-flop when the data might be changing. Imagine you have a fast clock, and want to capture data from a slower domain, but which lines up
with one of your edges. Have logic create a qualifier signal that is
0 during this fast clock period, and AND the data with it. Now, we avoid latching a signal when it could be changing.

Metastability is not well understood by most people since almost every detailed description of how to avoid metastability that I've read has
had at least a small bug. A common flaw is if you synthesize logic and
don't have a set of timing constraints between clock domains, you may
not be avoiding metastability. Paths can (and do) take "scenic routes"
if you have no constraints. "Synthesis" is not an issue with TTL since you're hand placing components.

Sometimes you just have to capture data as its changing, and that's
when the 2-3 flip-flops in a row rule come into play. Note you can really only do one bit like this, to move a counter requires gray coding and more care.

The thing about metastability is it's rare--if you have a problem, it may
be hard to detect in practical testing.

Kent

Thanks for your detailed answer. I've learned some things from it.

Charlie

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)