Re: Apple //c smartport compact flash adapter

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

Eric Rucker <bhtooefr@gmail.com> wrote:

> On Feb 3, 7:02 pm, mdj <mdj....@gmail.com> wrote:
> > Interesting - sounds like there's a handshake between bytes that
> > limits its throughput.
> >
> > The Rev C. SCSI (from memory, I think we did this once before) is
> > around 35kb/s on my accelerated IIe. I'd say they're both slow
> > compared to other options, and certainly slow compared to what's
> > achievable in a bus connected card.
> >
> > My marketing skills aren't the best, but I'd guess the majority of
> > people wanting such a thing on a IIc would be more than satisfied with
> > SmartPort speeds. The 'power users' are already using IIe's or IIgs's
> > anyway.
> 
> Theoretical maximum transfer rate on a UniDisk 3.5 is 500 kb/s. (From
> http://docs.info.apple.com/article.html?artnum=1307&coll=ap)
>
> So, that's 62.5 kB/s.

That's the raw data transfer rate to/from the disk surface.

The UniDisk 3.5 suffers from several bottlenecks:

1. SmartPort is fixed at 250 kbps (4 microseconds per bit), same as the
5.25" drives.

2. The disk controller requires all data transferred to have bit 7 set,
thus there are only 7 usable bits per byte. This reduces the transfer
rate for user data to 250 * 7/8 = 218.75 kbps.

3. The UniDisk 3.5 has a single IWM, which needs to switch between two
roles: exchanging data with the host, and accessing the drive mechanism.
This means it needs to do all transfers in two stages, using a very
small RAM buffer as a go-between. Since the drive interface is twice as
fast as SmartPort, this gives a 3/2 increase in transfer time, so the
effective data transfer rate is reduced by 2/3, thus 145.8 kbps.

4. The actual data format used on the 3.5" disk requires 6-and-2
encoding. Since SmartPort has already done a 7-and-1 encode/decode, this
is effectively another 1/7 drop in throughput, now down to 124.97 kbps.

5. Seek time to locate the appropriate track (variable).

6. Rotational latency for the desired sector to arrive under the head
(variable).

Ignoring seek and rotational latency, the theoretical maximum transfer
rate for user data to/from a UniDisk 3.5 is about 125 kbps, or 15.625
KB/s.

That's all without any overhead on the Apple II side of the interface.

> However, that theoretical maximum can only be approached on a IIGS, I
> believe.

Nope. The SmartPort and UniDisk 3.5 IWM switching and buffering have
exactly the same overhead on every Apple II model.

The IIgs is able to use an Apple 3.5 Drive, which has the same mechanism
as the UniDisk 3.5 but is able to be accessed by the computer at a raw
transfer rate of 500 kbps (still have 6-and-2 encoding overhead, seek
and rotational latency).

With good drivers (e.g. GS/OS, or ROM 3 firmware), the IIgs is able to
read from an Apple 3.5 Drive with 2:1 interleave twice as fast as it can
read from a UniDisk 3.5 with 4:1 interleave.

(2:1 interleave on a UniDisk 3.5 is horribly slow as it needs an entire
rotation per sector. 4:1 interleave on an Apple 3.5 Drive is just as
slow as the UniDisk due to having to wait for the sector to arrive.)

> (Even the accelerated 8-bits will likely stay at 1 MHz the
> whole time.) There's lots of SmartPort overhead to deal with, and the
> 8-bit machines will have to deal with that overhead, whereas a IIGS
> can speed up to 2.8 MHz and go past all of that overhead, between
> transfers.

Not significant. The data can't get through SmartPort and the UniDisk
internal buffer any faster, so the faster IIgs CPU is twiddling its
thumbs waiting for the next byte to be transferred.

The inter-block rotational delay is sufficient to cover any software
delays getting ready for the next block (at 4:1 interleave) on an 8-bit
Apple II, so the IIgs is just wasting CPU time if it is running in fast
mode.

-- 
David Empson
dempson@actrix.gen.nz