Re: Anybody aware of the description of a 19pin connector of an Apple 5.25 Disk Drive ?

[Michael J. Mahon <mjmahon@aol.com>]

Phil Tubb <googleplus@w127.com> wrote:
> On Monday, May 6, 2013 8:06:31 AM UTC-7, barrym95838 wrote:
>> I believe that the Disk ][ was one of Woz' proudest moments.  It is a
>> marvel of simplicity, made possible by clever software timing loops that
>> do all of the encoding, decoding, and seeking.  The Apple ][ is unique
>> among many of its contemporaries in that it was possible to disable
>> interrupts with almost no side-effects, making this implementation
>> feasible.  The Ataris and Commodores needed smarter interface hardware,
>> because they couldn't really afford to disable interrupts for any length
>> of time without annoying the user in some way.  The Apple system was
>> primitive, but faster than most of its contemporaries ... credit Woz for
>> that.  It should have been cheaper too, but Apple was responding
>> appropriately to supply and demand at that time.
>> 
> Sorry, I have to disagree. While the Disk II design is very clever in
> terms of minimizing chip count, in every other respect it is unusually
> bad. Personally, I've designed professional duplication equipment for
> pretty much every floppy disk format ever developed, including a unit
> with the world record for copying speed. If you want to see a brilliant
> design, look at the Amiga disk controller.
> 
> Back in the day, Apple had reps that traveled around to visit companies,
> like mine, that made products for the Apple (in our case, music cards at
> that time). Our rep brought an early Disk II to show off. He read some
> files, and I asked him if this unit was broken. He was confused and
> wanted to know why I asked that. I told him, because it's incredibly
> slow... the slowest drive I've ever seen. And of course he responded that
> it was the fastest drive on the market. I read the same size files using
> a floppy drive on an IMSAI 8080, and it was many many times faster.
> 
> As it turns out, the Disk II design was vastly inferior to the prevailing
> designs of the day, except in a few specs. (1) it was a lot cheaper. That
> was good for Apple, but they sold it at a huge markup, so it wasn't much
> cheaper than the other designs (which at that time, were largely for
> S-100 systems like the Altair 8800 and IMSAI 8080 I just mentioned). (2)
> it sort of had more capacity. A lot of disk systems at the time used
> single-sided single-density recording, but everyone who made S-100 floppy
> systems was in the process of moving to single-sided double-density with
> the controller being capable of double-sided double-density (but
> double-sided drives weren't available yet). Once Apple switched from 13
> to 16 sector, they had more storage per disk than the single-density
> systems which were then being phased out in the S-100 world. But the
> Apple formats had LESS storage than the double-density systems. (3) The
> Apple disks were arranged in 35 tracks (even though in S-100 systems
> disks with 40 tracks were coming out), and the recording heads had to
> "step" to the desired track in order to read or write it. On other
> designs, the time it took to step, say, 15 tracks was almost exactly 15
> times what it took to step 1 track. On the Apple design, if the distance
> (number of tracks) you wanted to step was large, the controller could cut
> the step time down significantly. However, well-written operating systems
> are designed to keep files together so you rarely have to step more than
> one track; Apple's design couldn't step one or two tracks any faster than
> any other design. And this was the ONLY parameter that relates to speed
> that Apple improved compared to prevailing designs. It's pretty much the
> single most useless speed parameter to improve.
> 
> On top of that, the Apple design had a lot of disadvantages:
> 
> (1) Although it used group code recording, which was becoming common in
> the hard drive world but not in floppy disks, it used it at a very low
> density (which is why the S-100 system's less-efficient MFM encoding
> none-the-less gave more storage: because it was at a higher density).
> Apple couldn't increase the density easily with their design, unless they
> made an equal increase in processor and peripheral-bus speeds.
> 
> (2) The reason it was originally incredibly slow had to do with the
> software decoding; in other words, all the "stuff" that Apple moved from
> hardware to software in order to reduce the chip count. If you look at
> Wikipedia's article on "Apple DOS", you'll see that originally a track
> had the sectors written in this order:  0 7 14 6 13 5 12 4 11 3 10 2 9 1
> 8 15. This was done to give the software time to decode each sector after
> it was read. Let's say you want to read all the sectors on a track in
> order (a very common operation). In the very best case, with this
> arrangement sector 0 would just happen to be right there ready for you to
> read. In the same single rotation of the disk, you'd wait as sectors 7,
> 14, 6, 13, 5, 12, 4, 11, 3, 10, 2, and 9 go by, then you'd read sector 1.
> (Of course during this "waiting" the software would actually be decoding
> the raw data read from the disk for sector 0.) Then you'd wait while
> sectors 8 and 15 go by, and that's the end of the first spin... each spin
> takes 1/5th of a second. In the next spin, you'd wait while sectors 0, 7,
> 14, 6, 13, 5, 12, 4, 11, 3, and 10 go by, then read sector 2. Again,
> you'd be decoding sector 1 while these sectors go by. Then you'd wait
> while sectors 9, 1, 8, and 15 go by; that's the end of the second spin.
> You can see it's going to take a whole lot of rotations, at 1/5 second
> each, to read the track. In contrast, the hardware on S-100 systems of
> the day easily read all the sectors in one spin (best case); there was no
> need to allow sectors to pass by while the processor decoded the raw data
> because the floppy-controller chip could do that by itself. Worst case,
> the S-100 systems would JUST MISS sector 0 and have to wait one spin for
> it to come around (the same thing can happen to Apple as well), then use
> one spin to read every sector on the track.
> 
> (3) Adding to the slowness, the S-100 systems could use DMA to move the
> data from the disk controller into the computer's memory, leaving the
> computer free to run software. Best case, this means nearly zero computer
> time is used to read the disk; more commonly (back then), accessing DMA
> slows the processor down so it runs at half speed (this all depends on
> the design of the DMA system and the speed of the memory). The S-100
> systems typically used interrupts to summon the processor whenever
> commands needed to be issued to the control circuitry, and as Mike
> mentioned this means if you turn interrupts off for too long it will take
> longer to read the disk. The Apple design not only didn't use DMA, and
> therefore wasted processor time simply moving the data from the card to
> the computer's memory, it also required software decoding of the data,
> another complete waste of processor capability compared to S-100 systems.
> Furthermore, Apple COULDN'T use DMA because, in order to save a single
> gate which would have cost a few cents, they messed up the Apple's DMA
> system rendering it almost completely useless. (Specifically, if you used
> DMA for more than a few memory cycles in a row, all the registers in the
> 6502 were scrambled... including the register telling the processor where
> it's at in the program being run. Had Apple including the inexpensive
> gate, DMA would have been usable with any number of cycles and never
> disrupted the processor's functions.)
> 
> (4) Like the double-density formats (MFM) everyone else was going to,
> Apple's GCR formats were very unreliable unless special circuitry is used
> to overcome certain technical difficulties. The S-100 systems featuring
> double-density had such circuitry; Apple never added it. (The most common
> method was called "write pre-compensation" which used subtle timing
> changes to create a more readable magnetic pattern. In our professional
> duplicators, used such circuitry not only for MFM formats, but for Apple
> formats as well... thus making disks made with our equipment much more
> readable on various drives than a disk written with an Apple. An Apple
> could read a disk written on the same drive fairly well, but not nearly
> as well as standard single-density systems and double-density systems
> with pre-comp; but readability really suffered when the drive reading the
> disk was at one end of the normal range in adjustments and the drive that
> wrote the disk was at the other end of the range.)
> 
> Bottom line, the Apple Disk II design was clever in that it had a low
> chip count and was cheap to manufacture, but it suffered very badly in
> all other respects compared to just using the regular FM/MFM design with
> the standard floppy controller chips. How anyone could claim it was
> faster than the S-100 floppy drives of the same period is beyond me...
> obviously they never tried them side-by-side.

I think it's important not to compare Apples to oranges. ;-)

Pricing aside--since that's a market issue, not a technology issue--the
Disk ][ interface was a technical tour de force of cost reduction and
performance improvement relative to its competitors in the marketplace,
which were certainly not S-100 systems. 

The elegance of the hardware-software tradeoffs and the state sequencer
data separator were, and still are, paragons of cross-domain design and
optimization. 

I have never encountered any practical reliability issues with the
formatting and encoding methods, even with substandard media. 

Finally, the huge contribution of a low-cost, relatively high performance
(c.f.: Commodore, Atari, TI, Radio Shack, etc.) disk subsystem to Apple's
bottom line played a big role in Apple's survival as a company. 

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon