Re: Zip Chip programming info / disk image?

[dempson@actrix.gen.nz (David Empson)]

<aiiadict@gmail.com> wrote:

> >then maintain slow mode for a heuristically determined
> >50-or-so milliseconds after a slow slot /DEVSEL reference.
> 
> Interesting...  How do the heuristics work?
> 
> Will a ~50ms slowdown work for all peripheral cards
> that need 1mhz access?

Should do. The 50 ms delay is to allow for any timing-critical code
which is doing I/O operations involving a "slow" slot.

Any access to the slot DEVSEL area will retrigger the timer, and a
typical timing-critical I/O loop (such as disk access) will typically be
accessing I/O locations very frequently. The entire I/O code will run at
1 MHz until about 50 ms after the last I/O access.

For a "fast" slot, the actual I/O access cycles are slowed down to sync
with the motherboard 1 MHz clock, but other cycles can run at the full
speed of the accelerator.  This can only be done if the I/O access code
is not timing critical.

If a peripheral has timing critical access code and it isn't accessing
the I/O registers at least once every 50 ms then this technique will
fail, and that peripheral cannot be used with a Zip Chip unless the Zip
is set to run at normal speed while the peripheral is being used.

> if this is all that the accelerator needs to do, then
> all disk II, 5.25, 3.5 drive access code must work
> like this (?)  :

5.25" drives and the UniDisk 3.5 (and other SmartPort intelligent
devices) are timing critical: bytes must be written exactly 32 cycles
apart (at 1.023 MHz). Read has a few cycles leeway.

Apple 3.5 drives (in the IIgs) are able to be accessed with the IWM
running in an asynchronous mode, which involves an extra buffer stage,
allowing more relaxed read and write timing. As long as the code is
polling the status register to keep track of the read/write progress, it
can run faster than normal (on an acclerator) without causing problems.
In an unaccelerated IIgs, the 3.5" drive access must be done in "fast"
mode in order to keep up with the data rate (16 microseconds per byte),
and the IIgs fast mode (about 2.6 MHz) doesn't have uniform timing due
to regularly inserted refresh cycles for the fast RAM.

In the IIc+, the motherboard has some extra buffer circuitry to support
a 3.5" drive, which also isolates it from the accelerator (which is a
Zip Chip derivative), and the access code is less timing critical.

AppleTalk in the IIgs was another problem area. Apple had some
timing-critical code which ran with the CPU in "fast" mode (2.6 MHz),
which would normally be sped up by an accelerator. In System 6.0, they
changed this code to run in "slow" mode (1 MHz). The ZipGS is normally
configured so that it only accelerates when the motherboard is running
in "fast" mode. Prior to this change, you had to do some extra tricks to
get AppleTalk to work with a ZipGS, which involved slowing the computer
down more than necessary.

> 
> lda $C600  (or STA)
> ..
> ..
> access disk, time with loops
> ..
> ..
> ..
> 
> 
> 
> So the access to the $C600 would tell the
> CPU to slow down, and the timing loops that
> access the hardware will take a maximum 
> of ~50ms ?

The Zip chip reacts to the DEVSEL area (e.g. $C0E0-$C0EF for slot 6). I
forget whether it also slows down for an access to the IOSEL area
($Cn00-$CnFF) but I expect it does.

If the delay was only dependent on the IOSEL area being accessed, then
RAM-based drivers for the disk interface would fail because they only
access the DEVSEL area.

-- 
David Empson
dempson@actrix.gen.nz