Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site amdahl.UUCP
Path: utzoo!decvax!decwrl!sun!amdahl!howard
From: howard@amdahl.UUCP (Howard C. Simonson)
Newsgroups: net.micro.mac
Subject: Re: Thunderscan and Appletalk
Message-ID: <1615@amdahl.UUCP>
Date: Wed, 5-Jun-85 23:27:33 EDT
Article-I.D.: amdahl.1615
Posted: Wed Jun  5 23:27:33 1985
Date-Received: Thu, 6-Jun-85 23:01:05 EDT
References: <3155@dartvax.UUCP>
Distribution: na
Organization: Amdahl Corp, Sunnyvale CA
Lines: 27

> 
> We just got a Thunderscan. According to a brief note in the package,
> Thunderscan has difficulties on a Macintosh which has been used on
> Appletalk. Apparently Appletalk leaves some information in nonvolatile
> memory (I guess the parameter ram/clock chip) which Thunderscan relies
> on in some way. The suggested "work around" is to turn off the
> Macintosh, remove the battery for the clock, wait thirty seconds for
> the charges to trickle away and then put everything back together.
> Although Thunderscan claims to be coming out with a version of their
> software which will interact properly with Appletalk, I thought an easy
> patch in the mean time would be to write a program that flips those
> magic bits to something benign -- it appeals to me more than taking the

Now there is the idea for a very useful peace of software to write.
Essentially it is the battery-changer application.  All it does is write
parameter ram into a file, you change the battery, and you run it to restore
the locations from the file.  Then this little problem could be solved by
saving P-ram before using appletalk and restoring it after.  A nice option
would be to ignore clock bytes so the time doesn't get futzed.  Any takers?
I'm on vacation...

-- 
Time for a new catchy phrase in my                           Howard C. Simonson
 .signature, now if I could only     ...{dragon,hplabs,ihnp4,nsc}!amdahl!howard
  think of one...

[ Opinion? What opinion.  I think you have the wrong guy... ]