Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!munnari.oz.au!bruce!monu1!vaxc!phs172m
From: phs172m@vaxc.cc.monash.edu.au (Stephen Harker)
Newsgroups: comp.sys.apple2
Subject: Re: AE 1.6 MB 3.5" drive
Message-ID: <83286.277df96c@vaxc.cc.monash.edu.au>
Date: 30 Dec 90 03:27:56 GMT
References: <263@generic.UUCP>
Organization: Computer Centre, Monash University, Australia
Lines: 36

In article <263@generic.UUCP>, taob@pnet91.cts.com (Brian Tao) writes:
> 
>     Aren't Smartport devices simply block storage devices as far as GS/OS is
> concerned?  That is, it doesn't matter how big or small the device is, just as
> long as the block size is 512 bytes.  I assume that is true since you can set
> your RAM disk to anything you want and GS/OS won't mind.  So instead of
> putting the SWIM chip on the GS, why not equivalent circuitry on the drive
> itself?  It would return a volume size of 2880 blocks and any OS-level calls
> should work fine.  Even low-level block reads and writes should work, as long
> as the software uses Smartport calls.
> 
	Sure, that would work as would a number of other possibilities such as
having a controller card with a MFM controller chip, or using a SCSI floppy
controller on the drive itself (some companies make them).  Together with
appropriate drivers any of these options would work.  Indeed with the
appropriate FST you could then read/write MS-DOS and Mac high density drives.

	However all of these cost extra money to the user and would probably
stay non standard eg software is unlikely to be shipped in this format.  This
is a factor in a lot of people's purchase of hardware.  Personally I would be
likely to buy any solution to the problem of read/writing MS-DOS disks as
I don't have a modem at present, and we use PC clones almost exclusively in
this department (one Mac "owned" by a lecturer), hence it is a matter of
relative cost/usefulness.

	It would be simplest (from my point of view anyhow) if Apple put the
SWIM on the GS motherboard as the AE external drive would then be able to write
in the 1440K MFM format with a appropriate driver.  Then all we would need
would be the FST's (once again).  There may be other issues that make it more
difficult, but this would be *my* preferred solution at present.  Given the
lack of a (released?) HFS FST for 800K formats at present I don't think the
prospects are all that good.

-- 
Stephen Harker				phs172m@vaxc.cc.monash.edu.au
Monash University