Transwarp - How do they work?

[Anthony Ortiz]

I've searched for information on how the Transwarps actually work but can only find the manual and some repair info. What I would like to understand is how it's able to not only intercept the on-board CPU but take over completely, preventing the on-board CPU from operating. Does anyone have any knowledge in this area?

[John Brooks]

Post by Anthony Ortiz
I've searched for information on how the Transwarps actually work but can only find the manual and some repair info. What I would like to understand is how it's able to not only intercept the on-board CPU but take over completely, preventing the on-board CPU from operating. Does anyone have any knowledge in this area?

The Transwarp & Zip accelerators plug into the CPU socket, replacing the original CPU.

Since the accelerator board contains it's own faster CPU, and there is no longer a CPU on the motherboard, there is no problem 'taking over completely'.

-JB
@JBrooksBSI

[geoff body]

For the slot based accelerators which don't use the CPU socket, it is most likely they are using the DMA signal to disable the on board 6502. This allows the 6502/65c02 on the card to control the system. This can limit the use of other DMA based cards in the system.

Regards
Geoff B

[Anthony Ortiz]

Post by geoff body
For the slot based accelerators which don't use the CPU socket, it is most likely they are using the DMA signal to disable the on board 6502. This allows the 6502/65c02 on the card to control the system. This can limit the use of other DMA based cards in the system.
Regards
Geoff B

Yes, it seems DMA is how it's accomplishing the disabling of the on-board CPU. I happened to come across some info on it earlier today but you and Michael Mahon (who messaged me privately) are indeed correct.

Thanks!

[STYNX]

Post by Anthony Ortiz
I've searched for information on how the Transwarps actually work but can only find the manual and some repair info. What I would like to understand is how it's able to not only intercept the on-board CPU but take over completely, preventing the on-board CPU from operating. Does anyone have any knowledge in this area?

There are 2 concepts being used in Apple II accelerators.

1. Caching
2. Shadowing

The ZIP CHIP and McT SpeedDemon use caching and all other accelerator use shadowing.

Caching is 'relatively' simple. It has a small full speed cache-memory that allows full speed access for data that has already been read at least once. Every memory-write is done into the cache as well as the A2-memory (there may be some exceptions like the zero-page). Reading a byte can be done from the cache at full speed or from the memory at 1Mhz. Emptying the whole cache is not problematic as it will get filled again by normal usage. The main problem are the rules that map the memory locations to the cache. The zip-chip has 8kb of cache and must map up to 128k of memory locations. This needs highly optimized logic to allow a good acceleration.

Shadowing replaces some memory locations completely with full speed shadow-memory. Some memory locations must be written into the A2-memory (video, text...) and bank switching must be mapped as well. The whole process can get a bit complicated but allows relatively linear acceleration. A memory-shadow must have at least the same amount of memory as the host-system. (128k for the Apple //e)

-Jonas

[Anthony Ortiz]

This brings up another question... how are they able to slow down to 1mhz speeds every time they access the peripherals (ie. memory mapped IO addresses) and maintain that speed during critical timing loops that it may know nothing about (such as disk access code) and speed up to full acceleration the rest of the time? I wonder what happened to those guys at AE, would love to see them in the groups and pick their brain.

[Tom Greene]

Post by Anthony Ortiz
This brings up another question... how are they able to slow down to 1mhz speeds every time they access the peripherals (ie. memory mapped IO addresses) and maintain that speed during critical timing loops that it may know nothing about (such as disk access code) and speed up to full acceleration the rest of the time? I wonder what happened to those guys at AE, would love to see them in the groups and pick their brain.

For disk access most (if not all?) accelerators watch for access to the disk motor on/motor off soft switches and slow down to 1MHz whenever the drive is spinning.

Tom

[Anthony Ortiz]

Post by Tom Greene

Post by Anthony Ortiz
This brings up another question... how are they able to slow down to 1mhz speeds every time they access the peripherals (ie. memory mapped IO addresses) and maintain that speed during critical timing loops that it may know nothing about (such as disk access code) and speed up to full acceleration the rest of the time? I wonder what happened to those guys at AE, would love to see them in the groups and pick their brain.

For disk access most (if not all?) accelerators watch for access to the disk motor on/motor off soft switches and slow down to 1MHz whenever the drive is spinning.
Tom

Ahhhhh, good one.... that makes sense, for the disk drive at least. I wonder what scheme they used for the serial port and other timing-critical peripherals.

[James Davis]

Post by Anthony Ortiz
Ahhhhh, good one.... that makes sense, for the disk drive at least. I wonder what scheme they used for the serial port and other timing-critical peripherals.

IIRC, with my Zip-Chip, I could configure it to slow down for any slots I needed it to do so for.

[Anthony Ortiz]

Wait a second... I would think that *any* access to the address bus would need to slow down to 1mhz, otherwise how would, say, a 16 MHz transwarp access data on a 1mhz bus at 16mhz?

[Michael J. Mahon]

Post by Anthony Ortiz
Wait a second... I would think that *any* access to the address bus would
need to slow down to 1mhz, otherwise how would, say, a 16 MHz transwarp
access data on a 1mhz bus at 16mhz?

Of course it slows down on any bus access. But accelerators work by
minimizing accesses to the slow bus.

For software controlling timing-sensitive devices, not just bus access, but
instruction execution needs to be slowed down to 1MHz, even though the
instructions are running from the accelerator's fast memory. This is why
the slots containing such devices need to be "marked" as slow.

[Anthony Ortiz]

Yes, that I understand, but what I've been hearing here is that only certain IO locations are monitored for a slow-down, such as the disk motor on/off switches, paddle, speaker, etc... however, I would think that *any* address bus access due to it not being cached/shadowed by the transwarp (that includes all of the IO address space right?) would need to slow down to 1mhz, so it's not just a select few locations that slow it down.

Or am I missing something?

[awanderin]

Post by Anthony Ortiz
Yes, that I understand, but what I've been hearing here is that only
certain IO locations are monitored for a slow-down, such as the disk
motor on/off switches, paddle, speaker, etc... however, I would think
that *any* address bus access due to it not being cached/shadowed by
the transwarp (that includes all of the IO address space right?) would
need to slow down to 1mhz, so it's not just a select few locations
that slow it down.
Or am I missing something?

I think the missing piece is that when an accelerator detects a
reference to the "slow-down" I/O locations, it actually turns off
acceleration for a certain amount of time. The amount of time depends
upon the I/O location accessed. I think the ZipChip documentation would
make clear how long these delays are before the accelerator returns to
full speed.

--
Jerry awanderin at gmail dot com

[Michael J. Mahon]

Post by awanderin

Post by Anthony Ortiz
Yes, that I understand, but what I've been hearing here is that only
certain IO locations are monitored for a slow-down, such as the disk
motor on/off switches, paddle, speaker, etc... however, I would think
that *any* address bus access due to it not being cached/shadowed by
the transwarp (that includes all of the IO address space right?) would
need to slow down to 1mhz, so it's not just a select few locations
that slow it down.
Or am I missing something?

I think the missing piece is that when an accelerator detects a
reference to the "slow-down" I/O locations, it actually turns off
acceleration for a certain amount of time. The amount of time depends
upon the I/O location accessed. I think the ZipChip documentation would
make clear how long these delays are before the accelerator returns to
full speed.
--
Jerry awanderin at gmail dot com

Exactly, and these times are determined heuristically based on the maximum
time that a driver can be active without another access to one of the
"magic" device addresses.

For example, during a 5.25" disk operation, the Zip Chip slows down to 1MHz
for about 50 milliseconds anytime an address in the /DEVSEL range ($C0sx)
is referenced, and, empirically, there will always be another reference
before the 50 milliseconds expires as long as data is being transferred.

For references to the speaker toggle ($C030), the slowdown is only a few
milliseconds (it's in the Zip Chip documentation), which means that audio
tones that toggle the speaker less than a few milliseconds apart will have
their correct "1MHz" pitch, but a slow "tick, tick" will be partially
accelerated.

[Steven Hirsch]

Post by awanderin

Post by Anthony Ortiz
Yes, that I understand, but what I've been hearing here is that only
certain IO locations are monitored for a slow-down, such as the disk
motor on/off switches, paddle, speaker, etc... however, I would think
that *any* address bus access due to it not being cached/shadowed by
the transwarp (that includes all of the IO address space right?) would
need to slow down to 1mhz, so it's not just a select few locations
that slow it down.
Or am I missing something?

I think the missing piece is that when an accelerator detects a
reference to the "slow-down" I/O locations, it actually turns off
acceleration for a certain amount of time. The amount of time depends
upon the I/O location accessed. I think the ZipChip documentation would
make clear how long these delays are before the accelerator returns to
full speed.

Not sure about ZipChip, but on the original (IIe) TransWarp the length of the
slowdown is determined by RC time constant. I recall fiddling with this on
one of mine to minimize slow time.

[Michael J. Mahon]

Post by Steven Hirsch

Post by awanderin

Post by Anthony Ortiz
Yes, that I understand, but what I've been hearing here is that only
certain IO locations are monitored for a slow-down, such as the disk
motor on/off switches, paddle, speaker, etc... however, I would think
that *any* address bus access due to it not being cached/shadowed by
the transwarp (that includes all of the IO address space right?) would
need to slow down to 1mhz, so it's not just a select few locations
that slow it down.
Or am I missing something?

I think the missing piece is that when an accelerator detects a
reference to the "slow-down" I/O locations, it actually turns off
acceleration for a certain amount of time. The amount of time depends
upon the I/O location accessed. I think the ZipChip documentation would
make clear how long these delays are before the accelerator returns to
full speed.

Not sure about ZipChip, but on the original (IIe) TransWarp the length of the
slowdown is determined by RC time constant. I recall fiddling with this on
one of mine to minimize slow time.

Interesting.

The lengths of the Zip Chip's "synchronous sequences" are set by a digital
timer on the ASIC--more reliable and much more compact. This is, of course,
the implementation of the IIc+ as well.

[Ralf Kiefer]

Post by Steven Hirsch
Not sure about ZipChip, but on the original (IIe) TransWarp the length of the
slowdown is determined by RC time constant. I recall fiddling with this on
one of mine to minimize slow time.

Why do you want to do that? The Transwarp can slow down each slot if
necessary. You switch the accelerated mode on or off with the DIP
switches. So you won't loose too much performance if you shorten the
time for a single slot e.g. the disk controller. But you must be sure
that the driver code must not be accelerated too early.

My accelerator board is hard wired to slow down only for slot 6. No
jumpers, no DIP switches. So I cannot add a second disk controller
without changing driver code. This doesn't matter. Other slots are
filled with printer card, SSC, 80col, RamFactor, other RAM cards, 6522
card. There is no problem.

RWTS must be slow, the other drivers may be fast.

- Ralf

[Michael J. Mahon]

Post by Anthony Ortiz
Yes, that I understand, but what I've been hearing here is that only
certain IO locations are monitored for a slow-down, such as the disk
motor on/off switches, paddle, speaker, etc... however, I would think
that *any* address bus access due to it not being cached/shadowed by the
transwarp (that includes all of the IO address space right?) would need
to slow down to 1mhz, so it's not just a select few locations that slow it down.
Or am I missing something?

Yes, *all* bus accesses are slow, all the time.

The issue is how the accelerator determines that it must *keep* running
*everything* slow for a while for speed-critical devices. This is done
heuristically by detecting references to certain I/O locations.

So they always slow down to access anything on the bus, but only when they
detect "magic" address references do they *keep* running slow (even from
fast memory) until a certain amount of time has passed or until some other
"magic" address is referenced.

Accelerators (or at least their bus interface logic) must always access the
bus at 1MHz, but they have to be told (somehow) whether to stop
accelerating for a while when running driver software for certain slot
devices. The only reason that accelerators accelerate is that they can
avoid accessing the Apple bus most of the time.

[Anthony Ortiz]

Okay, thanks for clarifying, this is in accordance with my thought process as well; the accelerator must slow down for all bus accesses but will stay slow a bit for a select few locations. Does the Transwarp document these locations as well? If not I'll check out the Zip Chip docs.

[Ralf Kiefer]

Post by Anthony Ortiz
Okay, thanks for clarifying, this is in accordance with my thought process
as well; the accelerator must slow down for all bus accesses but will
stay slow a bit for a select few locations.

Every accelerator must do that. The fast processor must synchronize to
the applebus and wait for the beginning of the 500nsec window to access
anything on the mainboard. Probably the fast processor has to wait
900nsec because a bit too late to fetch the previous window.

Post by Anthony Ortiz
Does the Transwarp document these locations as well?

That's not necessary. There are DIP switches. You can select every slot
to slow down the code as long as the build-in timer is running. Read the
manual! Applied Engineering described the functions of the DIP switches
well.

In detail: if the code which is running accelerated by the Transwarp's
processor wants to access any address from $C0En (the registers of the
disk controller in slot 6) and slot 6 is set to "slow" the code will run
at 1MHz as long as the internal Transwarp timer is counting. Every
following access to any address from $C0En will restart this timer.

If a slot is set to "fast" the code slows down just for the single
access of one cycle which reads from or writes to the slot. The slot
interface must wait until the beginning of a new 500nsec cycle to do the
slow bus cycle.

My accelerator board (a very rare one from West Germany) slows down just
for reading. Write access to the apple bus is buffered and is done in
background and parallel without interaction of the fast processor. Just
in case of too many accesses to the apple bus the fast processor must
wait until the bus interface has finished the old "order". This happens
from time to time because the fast processor runs at 12.5MHz.

- Ralf

[Michael J. Mahon]

Post by Ralf Kiefer

Post by Anthony Ortiz
Okay, thanks for clarifying, this is in accordance with my thought process
as well; the accelerator must slow down for all bus accesses but will
stay slow a bit for a select few locations.

Every accelerator must do that. The fast processor must synchronize to
the applebus and wait for the beginning of the 500nsec window to access
anything on the mainboard. Probably the fast processor has to wait
900nsec because a bit too late to fetch the previous window.

Post by Anthony Ortiz
Does the Transwarp document these locations as well?

That's not necessary. There are DIP switches. You can select every slot
to slow down the code as long as the build-in timer is running. Read the
manual! Applied Engineering described the functions of the DIP switches
well.
In detail: if the code which is running accelerated by the Transwarp's
processor wants to access any address from $C0En (the registers of the
disk controller in slot 6) and slot 6 is set to "slow" the code will run
at 1MHz as long as the internal Transwarp timer is counting. Every
following access to any address from $C0En will restart this timer.
If a slot is set to "fast" the code slows down just for the single
access of one cycle which reads from or writes to the slot. The slot
interface must wait until the beginning of a new 500nsec cycle to do the
slow bus cycle.
My accelerator board (a very rare one from West Germany) slows down just
for reading. Write access to the apple bus is buffered and is done in
background and parallel without interaction of the fast processor. Just
in case of too many accesses to the apple bus the fast processor must
wait until the bus interface has finished the old "order". This happens
from time to time because the fast processor runs at 12.5MHz.
- Ralf

The Zip Chip (and IIc+) also buffer writes. Of course, if the write buffer
is not empty by the time the next read occurs, it stalls until the write
buffer is empty (to preserve ordering).

One note, apparently the "slowdown" delay on the Transwarp is a
retriggerable monostable rather than a counter.

[Ralf Kiefer]

Post by Michael J. Mahon
One note, apparently the "slowdown" delay on the Transwarp is a
retriggerable monostable rather than a counter.

Ok, Steven Hirsch mentioned that before. If you write or analyze code
there's no difference. You cannot change the delay with code.

It seems to be the 74LS123 near the left edge connected to the resistor
at the left corner (150kOhm) and the capacity (10uF) nearby. Reading
this document (page 9)
http://www.ti.com/lit/an/sdla006a/sdla006a.pdf

means: the delay is valid for about 650msec? Hm, anything wrong with my
observation?

I've got a photo (from the Apple II Documentation Project) and I looked
onto my own TransWarp: the resistor and the capacity are the same.

650msec are very long. More than 3 rotations of the floppy disk ...

- Ralf

[Michael J. Mahon]

Post by Ralf Kiefer

Post by Michael J. Mahon
One note, apparently the "slowdown" delay on the Transwarp is a
retriggerable monostable rather than a counter.

Ok, Steven Hirsch mentioned that before. If you write or analyze code
there's no difference. You cannot change the delay with code.
It seems to be the 74LS123 near the left edge connected to the resistor
at the left corner (150kOhm) and the capacity (10uF) nearby. Reading
this document (page 9)
http://www.ti.com/lit/an/sdla006a/sdla006a.pdf
means: the delay is valid for about 650msec? Hm, anything wrong with my
observation?
I've got a photo (from the Apple II Documentation Project) and I looked
onto my own TransWarp: the resistor and the capacity are the same.
650msec are very long. More than 3 rotations of the floppy disk ...

Yes, that's *way* too long.

I suspect that the 10uF capacitor is a filter/bypass capacitor on the +5v,
not a timing capacitor.

[Ralf Kiefer]

Post by Michael J. Mahon
I suspect that the 10uF capacitor is a filter/bypass capacitor on the +5v,
not a timing capacitor.

Sorry, no. "-" of that capacitor is connected to GND, but "+" is
connected to Vcc via the resistor (150kOhm) and to pin 7 of the LS123.
You can recognize this connection on the component side.

Pin 6 of the LS123 is connected to GND. This is the "traditional" usage
of the LS123 as described in the TI documentation mentioned before.

There is just one question: is this the delay generation?

It's a bit more complicated :-( The first half of the LS123 is used
also in this context. Pin 4 and pin 5 of the LS123 are connected to the
LS32, pin 1 and pin 2. The next question: the function of that first
half LS123. Pin 15 is connected to the capacitor nearby marked with
"330" (nF ?). This capacitor is connected to Vcc via 110kOhm if switch 8
of block 1 is open (3.6MHz) or connected to Vcc via 10kOhm if switch 8
of block 1 is closed (1.7MHz).

That's too curious, so I'm probably wrong :-(


BTW the capacitor between the processor and the EPROM is also used for
timing purpose.

- Ralf

[Michael J. Mahon]

Post by Ralf Kiefer

Post by Michael J. Mahon
I suspect that the 10uF capacitor is a filter/bypass capacitor on the +5v,
not a timing capacitor.

Sorry, no. "-" of that capacitor is connected to GND, but "+" is
connected to Vcc via the resistor (150kOhm) and to pin 7 of the LS123.
You can recognize this connection on the component side.
Pin 6 of the LS123 is connected to GND. This is the "traditional" usage
of the LS123 as described in the TI documentation mentioned before.
There is just one question: is this the delay generation?
It's a bit more complicated :-( The first half of the LS123 is used
also in this context. Pin 4 and pin 5 of the LS123 are connected to the
LS32, pin 1 and pin 2. The next question: the function of that first
half LS123. Pin 15 is connected to the capacitor nearby marked with
"330" (nF ?). This capacitor is connected to Vcc via 110kOhm if switch 8
of block 1 is open (3.6MHz) or connected to Vcc via 10kOhm if switch 8
of block 1 is closed (1.7MHz).
That's too curious, so I'm probably wrong :-(
BTW the capacitor between the processor and the EPROM is also used for
timing purpose.
- Ralf

I agree, that's curious.

Perhaps the long delay is the reset for the card.

[Michael J. Mahon]

Post by Michael J. Mahon

Post by Ralf Kiefer

Post by Michael J. Mahon
I suspect that the 10uF capacitor is a filter/bypass capacitor on the +5v,
not a timing capacitor.

Sorry, no. "-" of that capacitor is connected to GND, but "+" is
connected to Vcc via the resistor (150kOhm) and to pin 7 of the LS123.
You can recognize this connection on the component side.
Pin 6 of the LS123 is connected to GND. This is the "traditional" usage
of the LS123 as described in the TI documentation mentioned before.
There is just one question: is this the delay generation?
It's a bit more complicated :-( The first half of the LS123 is used
also in this context. Pin 4 and pin 5 of the LS123 are connected to the
LS32, pin 1 and pin 2. The next question: the function of that first
half LS123. Pin 15 is connected to the capacitor nearby marked with
"330" (nF ?). This capacitor is connected to Vcc via 110kOhm if switch 8
of block 1 is open (3.6MHz) or connected to Vcc via 10kOhm if switch 8
of block 1 is closed (1.7MHz).
That's too curious, so I'm probably wrong :-(
BTW the capacitor between the processor and the EPROM is also used for
timing purpose.
- Ralf

I agree, that's curious.
Perhaps the long delay is the reset for the card.

BTW, capacitors under 1uF marked with three digits (nne) are usually nn x
10^e pF, which is much too small for the expected use. If it were 330nF
with 110k, the time constant would be a reasonable 36 milliseconds, but
that would be an unusual way to mark a 0.33uF capacitor.

Weird.

[Steven Hirsch]

Post by Michael J. Mahon
BTW, capacitors under 1uF marked with three digits (nne) are usually nn x
10^e pF, which is much too small for the expected use. If it were 330nF
with 110k, the time constant would be a reasonable 36 milliseconds, but
that would be an unusual way to mark a 0.33uF capacitor.

I may still have my notes somewhere. The information came from one of the
hardware designers at AE: Steven Malachek.

[Ralf Kiefer]

Post by Michael J. Mahon
BTW, capacitors under 1uF marked with three digits (nne) are usually nn x
10^e pF, which is much too small for the expected use.

That's what I thought.

But now I found components like this:
https://www.digikey.com/products/en?keywords=%20%09338-1047-ND%20

The unusual lead spacing is the same, the size is nearly the same (+/-
0,5mm), the shape is the same. Even the color seems to be the same
(extreme dark red, nearly black).

Technical data from this manufacturer, not the manufacturer of the part
on my TransWarp ("SAN"):
http://www.cde.com/resources/catalogs/STD-DIPPED.pdf

They use the typical numbering system: "330" = 33pF.

Post by Michael J. Mahon
If it were 330nF
with 110k, the time constant would be a reasonable 36 milliseconds, but
that would be an unusual way to mark a 0.33uF capacitor.

If it is 33pF and 110kOhm, the formula says 2,2usec. 2,2usec (2 cycles
@1MHz) are too short. I remember my analysis of the disk controller
driver: I would expect a delay of min. 300usec/0.3msec (300 cycles) for
disk controllers. 50msec (50000 cycles, as mentioned before concerning
the Zip chip) could be good value for communication cards and drivers.

Actually I don't have the chance to test with my hardware. Is there
anybody who has a running TransWarp and wants to verify that? Connect
some LEDs (low current with resistors) to pin 12 and 13 of that LS123.
The idea is to observe the activities of this LS123.


- Ralf

[Anthony Ortiz]

Somewhere I read that the DMA line is pulled up by a 3300 ohm resistor. I am putting together a proto-board that needs to pull this down at startup because my chip takes a few seconds to initialize. Normally I'd just pull this down with a 10k resistor but seeing that this already has a pull-up on it I don't know what the consequences would be (eg. will it act as a voltage divider?). Would anyone know what the best approach to this is?

[James Davis]

Post by Anthony Ortiz
Somewhere I read that the DMA line is pulled up by a 3300 ohm resistor. I am putting together a proto-board that needs to pull this down at startup because my chip takes a few seconds to initialize. Normally I'd just pull this down with a 10k resistor but seeing that this already has a pull-up on it I don't know what the consequences would be (eg. will it act as a voltage divider?). Would anyone know what the best approach to this is?

Yes, I believe it would act as a voltage divider. You probably need a transistor circuit to pull it down. But, I am not an electronics engineer, just a retired electrician. MJM would know better.

[Michael J. Mahon]

Post by James Davis

Post by Anthony Ortiz
Somewhere I read that the DMA line is pulled up by a 3300 ohm resistor.
I am putting together a proto-board that needs to pull this down at
startup because my chip takes a few seconds to initialize. Normally I'd
just pull this down with a 10k resistor but seeing that this already has
a pull-up on it I don't know what the consequences would be (eg. will it
act as a voltage divider?). Would anyone know what the best approach to this is?

Yes, I believe it would act as a voltage divider. You probably need a
transistor circuit to pull it down. But, I am not an electronics
engineer, just a retired electrician. MJM would know better.

James is correct, a 10k resistor won't pull the line to logic low.

You should use an open collector output to drive the line low, and you are
never permitted to drive it high--after all, anyone can pull it low (of
course, anyone pulling /DMA low should have permission).

[Anthony Ortiz]

Thanks Michael, I read up on what that is and it makes sense; I'll get myself an SN7407N.

[Anthony Ortiz]

Oh, and for the initial state during startup, should I pull input low (of the SN7407N) using a 10k resistor? I checked data sheet and logic table doesn't say what output would be if input is floating (as would be the case during startup).

[geoff body]

Anthony instead of pulling DMA low , you could hold reset low until your circuit is ready.

Regards
Geoff B

[Anthony Ortiz]

Hmmmm... that may be an acceptable alternative, I'll have to think about that, thanks!

[Michael J. Mahon]

Post by Anthony Ortiz
Oh, and for the initial state during startup, should I pull input low (of
the SN7407N) using a 10k resistor? I checked data sheet and logic table
doesn't say what output would be if input is floating (as would be the
case during startup).

The reset circuitry of the Apple is based on a fixed RC delay, so you
should let the Apple reset itself before pulling on /DMA.

[Anthony Ortiz]

Hmmm... then how do I determine when it's time to pull DMA low?

[Bobbi]

A longer fixed RC delay? ;)

[Anthony Ortiz]

I don't want to have the drive spin so I guess I have to experiment and find the right delay; I thought perhaps there might be a more 'scientific' approach.

[Anthony Ortiz]

Anyone know if the Transwarp handled the mouse and keyboard IO any differently? That is, I'm sure you don't want a fast running program slow down to a 1mhz crawl every time your mouse pointer moves or as you scan for a potential keypress or both. If it doesn't handle it, I wonder if there's any way they could have avoided the hit.

[Ralf Kiefer]

Post by Anthony Ortiz
Anyone know if the Transwarp handled the mouse and keyboard IO any
differently?

The code from UCSD BIOS can run without any change at 1MHz, 3.6MHz or
12.5MHz. When code is idling the keyboard is asked very often (lda
$C010). But this is just one slow cycle.

When modifying this BIOS I wanted to add a keyboad driver which is
triggered by a timer (6522). But you need an additional timer chip.

Post by Anthony Ortiz
That is, I'm sure you don't want a fast running program slow down to a
1mhz crawl every time your mouse pointer moves or as you scan for a
potential keypress or both.

Changing the mouse pointer can theoretically slow down the fast CPU to
run the write cycles in video screen buffer on the main board. But just
the write cycles if they are too often. This never happens with a 3.6MHz
Transwarp.


Regards, Ralf

[Anthony Ortiz]

Post by Anthony Ortiz
Anyone know if the Transwarp handled the mouse and keyboard IO any
differently?
The code from UCSD BIOS can run

Pardon my ignorance, what is UCSD? Link?

Post by Anthony Ortiz
When modifying this BIOS I wanted to add a keyboad driver which is

triggered by a timer (6522). But you need an additional timer chip.

I would imagine that even if you did do this it would still need to poll the keyboard strobe for key presses periodically and I presume send an interrupt?

Post by Anthony Ortiz
Changing the mouse pointer can theoretically slow down the fast CPU to

run the write cycles in video screen buffer on the main board. But just
the write cycles if they are too often. This never happens with a 3.6MHz Transwarp

This last paragraph lost me. I would think there is a definite guaranteed slow down since, even though the mouse may trigger an interrupt, that interrupt needs to be processed and eventually read the x and y coordinates from the mouse card which slows it down to 1mhz, no? I also didn't understand what you meant by the write cycles, nor why the Transwarp would not be affected by any of this. I'm no Sathers so I would appreciate an education. :)

In my mind I would have the Transwarp constantly poll the keyboard when it's not performing other IO and keep the last state ready for quick access; I don't know if it does that. I would also do the same for the mouse.


Regards,

Anthony

[Ralf Kiefer]

Post by Anthony Ortiz

Post by Ralf Kiefer
The code from UCSD BIOS can run

Pardon my ignorance, what is UCSD? Link?

Sorry, UCSD-p-System, often called "Pascal".

Post by Anthony Ortiz

Post by Ralf Kiefer
When modifying this BIOS I wanted to add a keyboad driver which is

triggered by a timer (6522). But you need an additional timer chip.
I would imagine that even if you did do this it would still need to poll
the keyboard strobe for key presses periodically and I presume send an
interrupt?

Yes, this is independant from CPU frequency. An interrupt every 50msec
(20Hz) seems to be sufficient.

Post by Anthony Ortiz

Post by Ralf Kiefer
Changing the mouse pointer can theoretically slow down the fast CPU to

run the write cycles in video screen buffer on the main board. But just
the write cycles if they are too often. This never happens with a 3.6MHz Transwarp
This last paragraph lost me. I would think there is a definite guaranteed
slow down since, even though the mouse may trigger an interrupt, that
interrupt needs to be processed and eventually read the x and y
coordinates from the mouse card which slows it down to 1mhz, no?

Ok, there is a firmware ROM on the mouse card. This driver in ROM will
slow down the fast cpu to 1MHz exactly when this code is running. But
code in RAM runs at full speed, if you set the DIP switch to fast (OPEN
#7 in block 2, means the right DIP switch, if your mouse card is in slot
#7). And that's what I meant: the code which moves the mouse pointer on
the screen is typically located in the language card and is running at
fast speed.

Post by Anthony Ortiz
I also didn't understand what you meant by the write cycles, nor why the
Transwarp would not be affected by any of this.

I assumed that it's clear that code from any ROM on a slot card is
always running at 1MHz. The code from the local RAM of the Transwarp is
always running fast except there was an access to a slot card which
forces slow execution for some msec like the disk controller code.

Post by Anthony Ortiz
In my mind I would have the Transwarp constantly poll the keyboard when
it's not performing other IO and keep the last state ready for quick
access; I don't know if it does that. I would also do the same for the
mouse.

I expect that the driver which polls the keyboard is always part of the
operating system. This code is located in the language card, means it's
fast. If you move the mouse driver code from the slot to the RAM onto
the Transwarp this code will also be fast.


Regards, Ralf

[Anthony Ortiz]

Thanks for the explanation! What I still don't get are the write cycles... what's being written? We were talking speed, mice, keyboard, etc... and then you mentioned writes and I don't know what you mean

[Ralf Kiefer]

Post by Anthony Ortiz
What I still don't get are the write cycles... what's being written? We
were talking speed, mice, keyboard, etc... and then you mentioned
writes and I don't know what you mean

You find my description here:
Message-ID: <1nbbzln.lq7u64gicudyN%***@gmx.de>

Additional info: The screen buffer is part of the mainboard, means that
this RAM is accessed by the slow speed of the mainboard. I'm not sure if
the Transwarp works in the same way my 12.5MHz accelerator does: write
access to the mainboard is done simultanously and in background by
special buffers on the board. Read access of the screen buffers is done
without access to the slow mainboard RAM because this RAM is also
available on the accelerator board.

Summary: access to the screen buffers is typically as fast as local
access on the accelerator board.


Regards, Ralf

[Anthony Ortiz]

Does anyone know if AE had a license to use the Apple II Roms for both II and IIgs Transwarps or did it do a one time copy of ROMs to RAM at initialization?

[Ralf Kiefer]

Post by Anthony Ortiz
Does anyone know if AE had a license to use the Apple II Roms for both II
and IIgs Transwarps or did it do a one time copy of ROMs to RAM at
initialization?

The code from the preboot ROM copies the Apple ROMs to the local and
fast RAM. So does the Transwarp 1 and the Schaetzle&Bsteh DC65.

Regards, Ralf

[Anthony Ortiz]

Thanks Ralf, ever the source of knowledge for all things TransWarp!

[MG]

Post by Anthony Ortiz
Hmmm... then how do I determine when it's time to pull DMA low?

You might watch the bus for the 6502's RESET sequence, the same way Sather describes the IIe MMU as doing on page 4-14 of _Understanding the Apple IIe_. Three sequenced page 1 addresses followed by read of $FFFC. That lets you know the CPU has reset and is ready to start executing code.

MG

[Jorge]

Post by Anthony Ortiz
needs to pull this down at startup because my chip takes a few seconds to initialize.

On a real Apple II you can't pull down DMA for so long, the 6502 is not static. In most of the (rubbish) IIs that came later, with 65c02s and beyond, yes you can.

[Anthony Ortiz]

You should be able to hold DMA for as long as you want, otherwise how do accelerators such as the Transwarp work? I realize that the 6502 will lose all state but that's fine with me, whenever I want to relinquish control I'll release the DMA line and restart the computer.

[Ralf Kiefer]

Post by Anthony Ortiz
You should be able to hold DMA for as long as you want, otherwise how do
accelerators such as the Transwarp work?

The Transwarp and other accelerator boards use their own processor. The
65[C]02 from the mainboard doesn't start and won't be used.

Regards, Ralf

[Anthony Ortiz]

What I'm saying is that the only reason why the Transwarp is able to take over is by dropping the DMA line low; the 6502 is then disconnected from the system and you now have full control until you release the DMA line (and restart the system if DMA control duration lasted more than just a few cycles). That's what this thread answered a while back.

[Ralf Kiefer]

Sorry for the late answer, but there was a small problem with internet
access.

Post by Michael J. Mahon

[650msec]

Perhaps the long delay is the reset for the card.

Sound generation, but disabled? Another hidden feature?

Initial startup to slow down the preboot code of the Transwarp?

But the code could start at *any* speed. This code has the control using
the softswitches. So it's not necessary to have some hardware for this
job.


- Ralf

[STYNX]

Post by Tom Greene

Post by Anthony Ortiz
This brings up another question... how are they able to slow down to 1mhz speeds every time they access the peripherals (ie. memory mapped IO addresses) and maintain that speed during critical timing loops that it may know nothing about (such as disk access code) and speed up to full acceleration the rest of the time? I wonder what happened to those guys at AE, would love to see them in the groups and pick their brain.

For disk access most (if not all?) accelerators watch for access to the disk motor on/motor off soft switches and slow down to 1MHz whenever the drive is spinning.
Tom

There are several memory-locations to be monitored. Speaker and Paddle fro example, to name two. The method to slow down itself is dependent on the developer of the accelerator. You could simply 'stop' the cpu on the accelerator for a part of the 1Mhz cycle or add a delay of a bunch of nanoseconds (200-300ns). If you want to go all out, you can implement a buffer for some memory locations (audio, paddles for example) or even use a dual port memory with intelligent synchronization.

-Jonas

[Michael J. Mahon]

Post by Anthony Ortiz
This brings up another question... how are they able to slow down to 1mhz
speeds every time they access the peripherals (ie. memory mapped IO
addresses) and maintain that speed during critical timing loops that it
may know nothing about (such as disk access code) and speed up to full
acceleration the rest of the time? I wonder what happened to those guys
at AE, would love to see them in the groups and pick their brain.

It's not AE. Cache technology for the Apple II was developed first for the
SpeedDemon plug-in card, and later applied by the same folks in the Zip
Chip.
Apple eventually adopted the Zip Chip design (but not packaging) for the
IIc+.

TransWarps (at least in the beginning) shadowed all of Apple RAM, a much
less elegant solution than caching, since smaller SRAMs can always be made
faster than large ones (which is why multi-level caches are now universal).


The card/multi-chip package detects accesses to certain I/O addresses, like
slot 6, and then runs synchronously with the 1MHz clock for a certain
length of time. Since the timing-critical code regularly accesses /DEVSEL
addresses, the processor remains slowed down until (in the case of slots)
about 50 milliseconds after the last access to a "slow" address.

This is documented in the Zip Chip documentation text file on the utility
disk.

[Anthony Ortiz]

Post by Michael J. Mahon
It's not AE. Cache technology for the Apple II was developed first for the
SpeedDemon plug-in card, and later applied by the same folks in the Zip
Chip.
Apple eventually adopted the Zip Chip design (but not packaging) for the
IIc+.
TransWarps (at least in the beginning) shadowed all of Apple RAM, a much
less elegant solution than caching, since smaller SRAMs can always be made
faster than large ones (which is why multi-level caches are now universal).
The card/multi-chip package detects accesses to certain I/O addresses, like
slot 6, and then runs synchronously with the 1MHz clock for a certain
length of time. Since the timing-critical code regularly accesses /DEVSEL
addresses, the processor remains slowed down until (in the case of slots)
about 50 milliseconds after the last access to a "slow" address.
This is documented in the Zip Chip documentation text file on the utility
disk.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Wow, thanks Michael! They don't call you the "Woz Humbler" for nothing! :P A friend of mine and I didn't know how they did it, so I thought about it a bit and figured that if I had to do this myself I would synchronize to the slow clock until x amount of time from the last access to a slow location, so I'm happy that we came about the same solution.

They must synchronize to the same 1mhz clock right? Otherwise I don't see how they would get an exact match since Apple does that elongated cycle thing every 65th cycle. I figure the various DOS's must factor that elongated cycle into their timings, but I don't know anything about that subject yet as my Beneath Apple DOS and ProDos books have yet to arrive.

[Michael J. Mahon]

Post by Anthony Ortiz

Post by Michael J. Mahon
It's not AE. Cache technology for the Apple II was developed first for the
SpeedDemon plug-in card, and later applied by the same folks in the Zip
Chip.
Apple eventually adopted the Zip Chip design (but not packaging) for the
IIc+.
TransWarps (at least in the beginning) shadowed all of Apple RAM, a much
less elegant solution than caching, since smaller SRAMs can always be made
faster than large ones (which is why multi-level caches are now universal).
The card/multi-chip package detects accesses to certain I/O addresses, like
slot 6, and then runs synchronously with the 1MHz clock for a certain
length of time. Since the timing-critical code regularly accesses /DEVSEL
addresses, the processor remains slowed down until (in the case of slots)
about 50 milliseconds after the last access to a "slow" address.
This is documented in the Zip Chip documentation text file on the utility
disk.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Wow, thanks Michael! They don't call you the "Woz Humbler" for nothing!
:P A friend of mine and I didn't know how they did it, so I thought about
it a bit and figured that if I had to do this myself I would synchronize
to the slow clock until x amount of time from the last access to a slow
location, so I'm happy that we came about the same solution.
They must synchronize to the same 1mhz clock right? Otherwise I don't see
how they would get an exact match since Apple does that elongated cycle
thing every 65th cycle. I figure the various DOS's must factor that
elongated cycle into their timings, but I don't know anything about that
subject yet as my Beneath Apple DOS and ProDos books have yet to arrive.

It's even simpler.

Transitions in digital systems are driven by clock edges, so if it's time
to run synchronously with the 1MHz clock, you just switch to the slow
clock.