Path: utzoo!utgpu!watmath!att!ucbvax!pasteur!cory.Berkeley.EDU!johnhlee
From: johnhlee@cory.Berkeley.EDU (Vince Lee)
Newsgroups: comp.sys.amiga.tech
Subject: Re: timer device problems
Message-ID: <16167@pasteur.Berkeley.EDU>
Date: 9 Aug 89 22:27:48 GMT
References: <16074@pasteur.Berkeley.EDU> <13041@well.UUCP>
Sender: news@pasteur.Berkeley.EDU
Reply-To: johnhlee@cory.Berkeley.EDU.UUCP (Vince Lee)
Distribution: comp
Organization: University of California, Berkeley
Lines: 21

In article <13041@well.UUCP> farren@well.UUCP (Mike Farren) writes:
>johnhlee@cory.Berkeley.EDU.UUCP (Vince Lee) writes:
>>The samples are stored in fast RAM, and instantaneously copied to a
>                                         ^^^^^^^^^^^^^^^
>>chip buffer (which is allocated on the fly) before playing.
>
>Boy, howdy!  I'd sure like to know how that one works!  Ramdisks will
>never be the same...  :-)

Yes, there is an undocumented timer device command which allows you to
do this;  which is another reason I use the timer device instead of making
the program interrupt-driven.

The command, CMD_STOPTIME is little-known, but will be in the 1.4 RKM's.
It temporarily pauses the timestream allowing copying operations to 
occur with no time delay.  Unfortunately, it requires the ECS, and will
therefore not work on an A1000.  A side effect of the command, however is
that if called frequently, it makes interlace jitter considerably worse.

>-- 
>Mike Farren 				     farren@well.sf.ca.usa