🚀 go-pugleaf

In article <3210@amiga.UUCP>, kodiak@amiga.UUCP (Robert R. Burns) writes:
> ...If you *were* going to do that, you should set up
> an interval to wait for, using the UNIT_MICROHZ that you know works.
> But I think you just need a time *stamp* with higher granularity.  You
> will need to allocate another of the available CIA timers for that --
> CIA timers are allocated by acquiring the associated interrupt (even
> though you're not going to use that in this instance) from the cia.resource
> for CIAB (note that the timers on CIAA are hard allocated, only timers
> A & B on CIAB are available to allocate).

You mean there is a CIA timer we can grab that isn't used for the serial
port or timer.device?

A problem with timer.device is that there isn't a "periodic schedule"; that is,
I can get a mesage, signal, etc, in a certain number of milliseconds but there
is no auto-reschedule, consequently I have to reschedule and it induces timing
delays, even if I'm quick about it.  Compensation is possible if I were to
count vertical blanks and examine the vertical and horizontal beam position
to see how late I was, and compute an offset, but this is kludge-city.

The application is a MIDI sequencer and I need more accurate and more precise
timing than I can currently get through timer.device, too.  

I am considering timestamping incoming events when recording by reading the 
video beam's vertical and horizontal positions.  It's a pain to pass this
through the midi library, though, so I don't know if I'll do recording as
a "back door" thing or take a certain accuracy hit to gain consistency --
I currently have a midi module that generates midi clock messages as the
sequencer timing source and, by not connecting the clock module to the
sequencer, the sequencer can accept timing clocks from midi in.  blah blah blah
-- 
-- "We've been following your progress with considerable interest, not to say
-- contempt."  -- Zaphod Beeblebrox IV
-- uunet!sugar!karl, Unix BBS (713) 438-5018