Re: Partioning SCSI drives larger than 130 Megs?

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

ISCA AppleII Librarian <apple2pd@ground.ecn.uiowa.edu> wrote:

> Luckily, I am in a position where I have an alternative, and perhaps others
> do too.  My II'es and IIgs are hooked into an Appletalk network with
> an Appleshare 3.0 server (MacSE), MacLCIII, and two MacLC's, plus printers,
> etc.  [snippage]
> The only downside for me is the network is a little slower (well maybe more
> than a little) than a directly connected SCSI drive.

Definitely more than "a little" slower for a IIgs, might not be so bad
for a IIe.

In terms of raw bits on the wire, LocalTalk runs at about the same speed
as a 5.25" drive (230400 bps for LocalTalk, 250000 bps for a 5.25"
drive).  There are speed tradeoffs in each direction, e.g. seek times
and data encoding for the 5.25" drive, protocol overhead for AppleTalk,
which reduce the rate somewhat on each side.

In practical terms, I find that LocalTalk is about the same speed as a
3.5" floppy drive.

A DMA SCSI card can get transfer rates significantly faster than
LocalTalk on a IIgs, somewhat less spectacular for a IIe but still
considerably faster.

> Even Proterm3.1 can use the HFS volumes from the IIgs - but not from the
> IIe's :-(  [As I have complained before, PT3.x is about the only p8 applic
> I have that is _NOT_ network friendly ON A IIe.  PT3.x is very happy with
> a appletalk network on a IIgs.]

Interesting.  It might be doing something special when it detects it is
running on a IIgs, and its "normal" behaviour on a IIe ends up being
incompatible with the Apple II Workstation Card.  There shouldn't be any
detectable difference at the level of calling the ProDOS kernel
(assuming correct using of GS/OS boot sequence for the IIgs, and the
ATINIT file for the IIe).

> PS  Proterm3.x does have a least one problem on a IIgs with an appleshare
> volume, but not serious:  It creates a file with the correct date/time, but
> zaps the date/time when it closes a file.  I haven't found any other other
> p8 applic with this problem.

Probably some kind of interaction between a SetFileInfo call and the
file closing mechanism.  It might even be a bug in AppleShare which is
being exposed by ProTerm doing an unusual sequence of calls.

> PPS  I thought of one other p8 applic that is _not_ appleshare compliant:
> SuperSelector by TC Wilson.  It only 'sees' the first 12/13 files of a volume
> or directory.

That sounds like a bug in its directory reading code.  It is probably
relying on the link fields at the start of each directory block, e.g. to
determine whether more blocks follow.  These fields are faked for an
AppleShare volume, and might contain "illegal" values.  The correct
method is to treat the directory like a normal file and use the GetEOF
call to find out how many blocks it occupies.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand