Path: utzoo!mnetor!uunet!husc6!hao!hull
From: hull@hao.ucar.edu (Howard Hull)
Newsgroups: comp.sys.amiga
Subject: Re: Is there a new virus?
Message-ID: <1061@hao.ucar.edu>
Date: 29 Dec 87 21:44:21 GMT
References: <522@io.UUCP> <20491@linus.UUCP> <620@mcdsun.UUCP>
Distribution: na
Organization: High Altitude Obs./NCAR, Boulder, CO
Lines: 28
Summary: "movie" exhibits unacceptable behavior

In article <620@mcdsun.UUCP>, fnf@mcdsun.UUCP (Fred Fish) writes:
> In article <20491@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes:
> >Hmmm, I have just encountered *exactly* the same symptoms, immediately
> >after having accessed a new batch of Fred Fish disks (# 111 - 118).
> >In fact, disk # 111 went completely bad, also around tracks 40-41!
> >Fred, if you're out there somewhere, have you noticed any problems
> >with these disks?
> 
> It has been about 3 weeks now since these disks were released, with
> probably several thousand copies in circulation by now.  I have not seen
> any problems with scribbled disks, other than the typical random few
> that always seem to end up unreadable on delivery (typically about 1%

If you were multitasking at the time you started "df1:Movies/movie <whatever>",
and you replaced the fish disk (that has Movies on it) with the one you were
previously using, you could zorch the inserted df1: occupant.  As previously
reported on the net, The movie program is ill behaved on an A1000 [don't know
if this is just with $C00000 memory like I have, or what], and leaves the df1:
light on, indicating a problem of some sort.  What's worse, the movie demos
are so nifty that they could easily hold your attention away from the df1:
indicator - I didn't notice it myself until the third time I ran the demo
(Kahnankas).  This is a good way of getting track 40 "randomly reorganized".

> # Fred Fish    hao!noao!mcdsun!fnf    (602) 438-3614
> # Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282  USA

						Howard Hull
						hull@hao.ucar.edu