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