🚀 go-pugleaf

:The source of the problem appears to lie with WaitTOF().  I had a couple of
:subtasks running which the main program would kill off with RemTask() when
:theprogram exited.  The subtasks were set up to be higher or equal priority to
:the main program,andit was likely that they were waiting with a WaitTOF() when
:the main program did RemTask().  This apparently set a time bomb which would
:go off the second time the program was run.  I fixed the problem by not
:killing off the subtasks using RemTask() from the main program, but by 
:signalling the subtasks to kill off themselves.
:
:The reason I'm pretty certain that WaitTOF() was the culprit was that I tried
:the following two versions of the subtask:

	No need to go further!  I suggest that you always allow a task to
kill itself instead of a parent killing it.  Use some kind of signalling 
or message arrangement to signal the task that it should exit.

	Whatever gave you the idea that you could RemTask() right in the middle
of a WaitTOF() call!  Or just about any other call for that matter!  The only
call I ever trust a RemTask() to interrupt without destroying anything
is a Wait(0) (wait forever)!

	In anycase, the reason WaitTOF() dies when you RemTask() a task in
the middle of one is that I believe it adds a vertical retrace interrupt
handler or something like that to signal the task when the video beam has
gotten to the right point.  The task goes away, the video beam comes around
and the interrupt tries to signal the now very dead task.  *boom*.  Why the
behavior doesn't appear till you try to run the program again is probably
a side effect of the way WaitTOF() works ... probably *ANY* task trying to
WaitTOF() after the first one got removed will crash the machine.

						-Matt