Re: GS Appletalk troubles

[Rubywand <rubywand@swbell.net>]

ISCA AppleII Librarian writes ...
> 
> From article <3619F5C4.DDA93C8@swbell.net>, by Rubywand <rubywand@swbell.net>:
> > John E. Townsend writes ...
> >>
> >> I'm trying to set up my IIgs to do Appletalk once again, and am about at
> >
> >  ....
> >
> >
> >      A 'hardware problem' with your motherboard is a possibility; but,
> > it is pretty near the bottom of the list of suspects. Mainly, AppleTalk
> > is a known source of problems (pretty much like ScreenSaver NDAs).  A
> > good first step after installing any version of GS/OS is to delete any
> > driver, init, text file, etc. which looks like it may have anything to
> > do with AppleTalk.
> >
> 
> Jeff, not a good suggestion for John :-)  He is trying to get Appletalk
> working, not removed.
>

     Steve, John has my best wishes for a successful quest.


 
> I have used Appletalk on my GS (system 6.0.1, Rom1, ZipGS8/64, 4Meg RamGS,
> HS scsi, Superdrive & controller) with an Appletalk network (printers,
> Appleshare 3.0 server, and personal file-sharing on Mac system 7.x) without
> problems.  System is stable, 7d/wk, 24h/d.  Only problem is some possible
> character loss with PT3.1 or Spectrum during z-modem downloads.  (But my
> Mac LC III is even worse with character loss!).  So John should be able
> to get a reliable system running with Appletalk.
> 
> Please list the known problems with Appletalk on a IIGS.  I am not familiar
> with them.

     The statement said that AppleTalk is a known problem-causer. That
is, a user has all sorts of strange problems with his/her GS and someone
says: "Hey, you need to get rid of AppleTalk". He/she gets rid of
AppleTalk and the problems disappear.

     In terms of the kind of nuts & bolts information one needs to
identify problems, virtually every piece of popular add-on hardware with
its accompanying firmware is undocumented. If we knew the timing
requirements-- access delays, R/W times, timeout period which produces
an error, etc.-- for SuperDrive or RamFAST or or Focus or whatever, it
would be much easier to identify and, possibly, eliminate likely
conflicts and problems with interrupt-driven subsystems like AppleTalk.  

     It's too bad that the makers of the ZipGS accelerator, RamFAST SCSI
interface, etc. havn't considered slapping together schematic, etc.
'tech paks' for their products and selling them. Plenty of users would
be interested.
   

>  I'll list a few concerns:
> 
>   1)  Net-work booting off a Appleshare 3.0x server is S..L..O..W..!
> 
>   2)  More interrupts - software used must be interrupt friendly.
> 
>   3)  PT3.1 works with Appletalk on a GS, but does not work for file-access
>       on a IIE. :-(  PT3.1 works on a Appletalk IIe as long as one does
>       NOT access the network.
> 
>   4)  Perhaps an accelerator may be recommended  (I've never tried without one).
> 
>   more...?
>
 ....

     Information like the above is sure to help those who wish to use
AppleTalk. Unfortunately, I do not recall what specific situation led to
pulling it. In any case, we scrapped AppleTalk years ago; so, any
associated problems/limitations have not plagued our IIgs.

     The above leads to a natural question: What am I missing? What is
it that you or John or anyone else does with AppleTalk which makes it
worth the bother.

     For example, unless one is especially thrilled by pretty animations
at random intervals, putting up with screen saver-related limitations
and glitches makes no sense. The 'cure' is to treat any screen saver as
though it were a virus.

     Obviously, AppleTalk is a potential crash causer. So, what is the
pay-off for getting it to work on a GS?



Rubywand