Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: message ports seeing the future?
Message-ID: <21732@cbmvax.commodore.com>
Date: 20 May 91 05:03:46 GMT
References: <24436@know.pws.bull.com>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 26

In article <24436@know.pws.bull.com> pmiller@vttcf.cc.vt.edu (Paul Miller) writes:
>However, now (and this is untested outside of the application I'm using the
>module in), when I tell the task to wait on a particular section, my app gets
>signalled BEFORE the cycles actually complete. This obviously screws up the
>timing in the program, with things happening on-screen before they're supposed
>to, and in some cases, where something is supposed to happen within a given
>interval, the audio will go into an endless loop, cycling the same sample over
>and over, because I've told it to wait on something that's already been played

	Hmmm.  It's hard to have any reasonable ideas without seeing some of
the code, but in general I'd say you should check that you're not relying
on the port signal to always mean that a message is available in the port.
There are several ways (particularily with device IO, but ways exist with
all ports) that signals can be left set after processing messages - you must
handle the no-messages in port case correctly.

	If that isn't it, I advise posting a snippet of code including the
port-handling.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Thus spake the Master Ninjei: "To program a million-line operating system
is easy, to change a man's temperament is more difficult."
(From "The Zen of Programming")  ;-)