Subject: Re: IIgs/PC Network Development
From: dempson@actrix.gen.nz (David Empson)
Date: Wed, Sep 30, 1998 06Ç36(H
Message-id: <1dg73nh.1rnpobv7baveuN@dempson.actrix.gen.nz>

Steve Mentzer <!smentzer@ecom.net> wrote:

> Ok, if you are one of those people who continually spews "It cant be done"
> without thinking about the true potential or viability of a IIgs project, then
> close this thread immediately.

Well, I'll run with it, but an advance warning: Sšnke's suggestion (PPP)
sounds like a much more useful solution.

> What do I want from my IIgs the most these days.
> 
> 1 - Ability to access shared network resources w/o having to run a MAC.
> 2 - Ability to download files on the PC and EASILY transfer the files to
>     the IIgs for use
> 3 - Ability to have a partition size > 32MB w/o having to use HFS.
> 
> 
> What is preventing this from happening?
> 
> 1 - Appletalk either requires a MAC or special hardware to implement.

AppleTalk is a protocol stack, and is able to run on multiple physical
network types, assuming the machine has the necessary hardware and
software.  The IIgs happens to support LocalTalk, which is the original
hardware used to implement AppleTalk.

So, strictly speaking, your comment only applies to LocalTalk.  It is
easy enough to run AppleTalk between a Mac and PC without LocalTalk,
e.g. with Linux or Windows NT Server on the PC, using Ethernet between
the Mac and PC.

The catch is that the IIgs has no hardware and/or software support for
other physical networks that can run AppleTalk.

> 2 - Downloading files onto a IIgs from a PC requires you to load a special
>     piece of software (ie proterm) and allows NO additional functionality.
> 3 - HFS is nice, but I am leary of using it because of reported bugs.

Fair enough.  I happen to agree.

> The easiest and most reliable way to connect a PC to a IIgs is via a
> serial port. This limits a theoretical network connection to ~57.6k, but
> that is still plenty fast (unless you are transferring 100MB at a time).

I don't know about "plenty fast".  It is significantly slower than a
floppy disk: the Apple 3.5 Drive can read data at a sustained rate of
about 30KB per second (300 kilobits per second for a standard serial
port, ignoring protocol overhead).

> So, imagine this. Create an INIT (prolly the wrong term, I am not a IIgs
> programmer) for GS/OS that simulates an AppleTalk replacement over the
> standard serial port using a protocol that we define.

Wow.  Big project.

To make it look like a logical disk in Finder and other applications,
you would have to write a GS/OS File System Translator for this virtual
file system.

Well, that puts a major damper on things: Apple have never released any
documentation on how to do this (witness the recent discussion about
ideas for a better native file system).

OK, what alternatives are there?

Several possibilities come to mind:

1. Write a GS/OS block device driver that communicates over the serial
port, and (with help from the PC) implements a fake volume with an
existing file system.

This doesn't help, because you must emulate either ProDOS (32 MB limit)
or HFS (unreliable).  It would also be extremely difficult to coordinate
on the PC side, unless you actually implemented it as a massive disk
image file, which defeats the whole purpose.


2. Use the AppleShare FST.  This would require replacing the low-level
parts of the AppleTalk protocol stack in the IIgs (the DDP/Network and
LocalTalk protocol support layers) with software that did standard
asynchronous communications.  You could use the AppleTalk Remote Access
Protocol over the serial link (it is designed with this in mind, but is
normally used over a dial-up link).

This is technically feasible, as the Ethernet card Apple canned before
release worked exactly like this, except it replaced the low level parts
with Ethernet support instead of LocalTalk (it might have also replaced
some of the high level protocols with implementations on the card).  The
catch is that it isn't documented either, but would be much easier to
reverse engineer given the AppleTalk protocol stack documentation that
is available.

The PC would have to implement a reasonable AppleShare server, which
requires a fair number of the individual AppleTalk protocols: ARAP, DDP,
NBP, ATP, ASP (server side), AFP (server side), the actual file server
implementation, and possibly a stub for a few of the other protocols
(RTMP, AEP, ZIP, PAP if printer support is needed).  The majority of
this is already available on Linux, but a port to Win32 might be tricky.


3. Reduce the scale of the project somewhat by sacrificing the ability
to access the PC as if it was a logical drive, i.e. by using an
application to do the transfers to/from the PC.

I imagine this would work somewhat like Apple File Exchange on the Mac,
or typical parallel port file transfer utilities on the PC: you get
side-by-side lists of files on the two machines, with simple commands to
copy them over.

This could be done with a reasonably powerful communications program
such as Spectrum, possibly with help from plug-in code to provide a
reasonable user interface.  The PC side could be a dumb server.  (You
could run the whole thing the other way around, with the IIgs acting as
the server and the PC providing the user interface.)


4. Reverse engineer the AppleShare FST to find out how it interacts with
GS/OS, and write a derived one that implements a different (simpler)
communications protocol.


5. I don't think the following is a good idea, and I doubt it would be
compatible enough to justify it:

An INIT could patch the entry points to GS/OS, intercepting all
application calls and logically adding a special virtual volume.  This
would mean implementing every single GS/OS call, and somehow identifying
calls that are associated with the virtual volume.

(This is basically how AppleShare support is implemented under
ProDOS-8.)

It would be necessary to interact carefully with GS/OS, e.g. ensuring
that file reference numbers already allocated by GS/OS still work after
the patch is applied, and that newly opened files don't conflict.

The main danger is that there are a large number of documented and
undocumented GS/OS system service calls which can do things behind the
INIT's back.  It isn't feasible to patch these, because the patch code
must live in areas that are inside GS/OS (various bits of bank-switched
memory, particularly $01/D000-FFFF).

In the case of AppleShare with ProDOS-8, the underlying operating system
is simple enough and self-contained, so it was easy to patch AppleTalk
into it.  This is certainly not the case with GS/OS, which is a large
and complex beast with multiple layers of separately written code that
interact in weird and wonderful ways.


For any method which ends up with a logical GS/OS volume (all but number
three above), there is the additional problem of reserving the serial
port in such a way that an application doesn't step on it.  This could
probably be done by simulating LocalTalk ownership of the port, but
would require a fair amount of disassembly to work out how to do this
reliably.

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