[comp.sys.apple] SmartPort on a card.

brianw@microsoft.UUCP (Brian Willoughby) (04/11/89)

Well, I've done some more research into what would stop me from having the
faster Apple 3.5 Drive with my II+. (In review, the UniDisk 3.5 is the earlier
3.5 drive designed for the II, but is slower than the Apple 3.5 Drive due to
its design).

Someone suggested that a Disk II card, with the proper software burned into
the ROMs, would work if only a 20-pin Disk II to DB15 SmartPort Bus adaptor
were used. But, after glancing at the pinouts of the SmartPort Bus connectors,
there are two signals needed by the Apple 3.5 that are not generated by a
standard Disk II card. One line selects the head (800K 3.5's are dual head
drives) and the other selects between 5.25 and 3.5 drives. Now I understand
why the IIgs is limited to two of each. There are four combinations of the
signals: Drive 1 or Drive 2 and 5.25 or 3.5. After flipping through the
IIgs Hardware Reference, I noticed that $C031 contains a register for these
extra outputs. There is another problem because the Integrated Woz Machine
(used in the Mac, //c and IIgs) is more complicated than the standard Disk II
state-machine logic: it is a superset of this hardware (that's why the old
Disk II's still work [almost] when an adaptor cable is used). When the higher
density 3.5's are accessed, the clock rate for the magnetic bits on the disk
is doubled to twice the speed of the Disk II. The IWM has the proper registers
to select all these options, but it can't be done with a Disk II card.

Actually, it seems like the software in the UniDisk 3.5 controller (there is
a 65C02 inside every UniDisk 3.5 Drive) could be rewritten to acheive the same
performance as an Apple 3.5 Drive (with the advantage that the main processor
of the Apple II wouldn't have to compute everything). Of course, if the UniDisk
controller had more than 2K of RAM, then perhaps it could do on-board cacheing
to help speed up accessing. The newer 3.5" disk routines in the Macintosh ROMs
buffer an entire track every time a read is requested, and this approach helps
avoid problems due to interleave being too fast or slow for the main CPU. Apple
only put 2K in the UniDisk to prevent software bit copying (according to the
Apple IIgs Firmware Reference), but what is more important Apple? Do we want
performance, or do we want an imperfect protection scheme which only prevents
the maiximum value of the software?

Conclusions:
I've decided that an Apple 3.5 Drive interface card for the II, II+ and //e
would be no more expensive than the UniDisk Controller. It would need to have
some means of generating the 2 extra SmartPort Bus signals, it would obviously
need an IWM chip (or better yet, a SWIM) and the card's firmware would need to
provide the standard SmartPort Interface routines.

I doubt that I could build one myself, since Apple doesn't sell the IWM, and
they don't market the SWIM chip in anything but the Mac. So perhaps I could
leave this idea in their heads for an improved 3.5 interface card for the
Apple II series which would even support the new 1.2M format that new
Macintosh owners have access to.

One question remains:
If the Central Point Software Drives work with the Macintosh, then I assume
they are bare Drives without any on-board controller like the UniDisk 3.5
Drive. Can someone tell me if I purchase the Central Point interface card and
their Drive, will I get the higher speed interleave like the Apple 3.5 Drive?
I would prefer the quality of the Apple equipment, because I know it will
continue to work year after year. But, if the only way to get acceptable access
speeds is to go with the Central Point Drive, then I'm ready to start using
3.5" media!


Brian Willoughby                        microsoft!brianw@uunet.UU.NET
                or                      uw-beaver!microsoft!brianw
                or just                 microsoft!brianw