Re: How many floppies can I use with a Apple IIe

Warren Ernst <wernst@xxxxxxxxx> wrote:

On Oct 8, 4:19 pm, Rusty <rdek...@xxxxxxxxx> wrote:
On Oct 8, 6:54 pm, Linards Ticmanis <ticma...@xxxxxx> wrote:
Other than needing a different controller, what are the differences
between the "smart" 800k drive and the "dumb" 800k drive. Is it that
the "smart" drive had more of the control electronics onboard so as to
need a less-sophisticated controller, or was it something else
entirely?

The drive *mechanism* is identical. I've swapped drive mechanisms
between Unidisk 3.5's and Apple 3.5's without problems. So that's not
it.

The difference is in the electronics. The UniDisk has its own 6502
processor and (I think) 2 kb of RAM to act as a buffer for the
relatively slow and dumb //c (with newer ROMS) and //e (with Liron
card) . The Apple 3.5 Drive has no smarts or buffer, and it is
expected the host computer (A GS or early Macintosh) has enough speed
and smarts to handle the data stream. The SuperDrive uses its own RAM
and "smarts" to handle an Apple 3.5 Drive in a //e.

Minor correction: The SuperDrive _Card_ (i.e. "Apple II 3.5 Disk
Controller Card") uses its own processor to handle an Apple 3.5 Drive in
a IIe.

It is really only a question of performance, not intelligence. 8-bit
Apple II models running at 1 MHz simply aren't fast enough to keep up
with the data stream to/from a 3.5" drive mechanism, which uses 2
microsecond bit cells, compared to 4 microseconds for the 5.25" drive.
The computer has to keep up with transferring bytes every 16
microseconds for a 3.5" drive, or 32 microseconds for a 5.25" drive.

The UniDisk 3.5 introduced the SmartPort protocol, which involves the
drive's internal controller reading the sector (with 2 microsecond bit
cells), turning it into a SmartPort data packet, then using the
SmartPort protocol to transfer it to the Apple II via the disk connector
(using 4 microsecond bit cells). The same process is used (in reverse)
for writing.

This means that a UniDisk 3.5 is able to run on a IIe or IIc, with the
same timing as a 5.25" drive and without requiring special support
hardware (other than the Liron controller card, which has an IWM disk
controller but no other support hardware, or the IIc's built-in IWM).

The Apple IIgs has a fast enough CPU that it can keep up with the 3.5"
drive mechanism, so it can use one natively.

The SuperDrive card has its own processor (running at 2 MHz) and a fair
amount of RAM, so it is able to keep up with 16 microseconds per disk
byte and is also able to do more extensive buffering for transferring
data through the 1 MHz interface to the Apple II.

The IIc+ has two solutions: Apple introduced some buffering hardware
which allows it to keep up with a 3.5" drive, and they also added an
accelerator, so it could probably keep up with the 3.5" drive in
software even without the extra hardware support.

Otherwise, the UniDisk is slightly slower. It has a 4:1 sector
interleave while the Apple 3.5 has a 2:1 sector interleave.

This is entirely due to the "double buffered" nature of the UniDisk 3.5
and its limited internal RAM. By the time it has read a sector into
internal RAM, converted it and sent it to the host computer, and the
host has asked for the next sector, three sectors have already gone by,
so a 4:1 interleave is required for maximum performance. The UniDisk 3.5
doesn't have enough RAM to pre-emptively read ahead an extra sector.

On a Mac or a ROM 3 IIgs (or a ROM 1 IIgs running GS/OS), it is possible
to keep up with a 2:1 interleave on a 3.5" disk. A ROM 1 IIgs running
ProDOS-16 or ProDOS-8 isn't quite fast enough, so it is best to use 4:1
interleave there as well. (2:1 should be OK if you have an accelerator.)

The ROM 3 IIgs improved the disk controller firmware to add a track
buffer, and GS/OS has a similar technique, so either of these allows
fast reads and writes.

The Superdrive card also has enough RAM to buffer entire tracks, so it
can handle 1:1 interleave for read, but gets best write performance at
2:1 interleave.

Each can read and write disks formatted in the other, but the speed
degrades slightly when this happens.

I dispute "slightly".

Using a 4:1 interleave disk with a drive and computer capable of 2:1
will result in half the performance compared to using a 2:1 disk (apart
from track seek times, which are the same).

Using a 2:1 interleave disk with a drive and computer which can only
keep up with 4:1 will result in a huge drop in performance, because an
entire revolution of the disk is required to access sequential sectors,
resulting in about 1/8 to 1/12 of the performance compared to using a
4:1 disk.

You will mainly notice this effect when doing things like block-level
disk copies, but it will affect all operations on the disk with software
which is trying to read or write as fast as possible.

If the software is too slow and reads or writes individual sectors with
moderate delays, then you are no worse off with either interleave, as it
will need entire revolutions to get to the next sector anyway.

For shared disks that might be used on a slower computer, use 4:1.

If your computer and drive are capable of 2:1, then use it for your own
disks and for those which will be shared with other "fast" computers.

--
David Empson
dempson@xxxxxxxxxxxxx
.

Relevant Pages

  • Re: Tandy 2000 hard drive replacement
    ... It never changes the interleave to anything faster than the ... Step 2 is to format the track with a new sector interleave order, ... of controller, the heads will have moved into the start of the next sector ... leaving this on all the time, many of the earlier drives would malfunction ...
    (comp.sys.tandy)
  • Re: Prime 2550
    ... Records are allocated clockwise on a disk ... physical sector 1 in time before it spins past the head, ... physical sectors are passing under the heads. ... controller will do the seek to the correct cylinder, ...
    (comp.sys.prime)
  • Re: Higher than expected disk write(2) latency
    ... If you could get them queued at the disk level, things that would need to be watched were if the disk can queue things up, and how many things the disk can queue up, and how large each of those things can be, if they aren't queued at the disk, there is the chance that the machine cannot get the data to the disk faster enough for that next sector. ... Back in a long time ago, before disks had cache RLL and MFM drives used a trick called interleave, instead of writing to sector n, n+1,n+2 with a interleave of 2 would write to n,n+2,n+4 as once they got the message that n was written the machine had enough time to setup and send the next write to sector n+2 before the head got there, the question with your hardware would be how many sectors need to be skipped to be able to write immediately, and this assumes that can you live with the lower sequential read performance-interleave ... It would take a fairly intricate program to sort out what reality was, but it would seem to be possible to figure out exactly what reality is, and work with it. ...
    (Linux-Kernel)
  • Re: Reading old 3.5 CP/M diskettes using an actual USB floppy drive?
    ... Back in the olden days this was called sector interleaving, ... read/write the disk in as few rotations per track as possible. ... Regardless of the interleave factor, the disks were compatible from machine ... to machine (presuming both machines had the same density, number of sides, ...
    (comp.arch.embedded)
  • Re: Transfer floppy files to CDROM?
    ... sector size and interleave factor from the data on the disk. ... ZSDOS uses virtual tables for disk formats, ...
    (comp.os.cpm)