>this is problematic.
>
>you cannot add a new element before the pending firing because you can't
>tell how far into the present trigger you are.
This is not a problem for readable counters like the i8254. The problem
for the i8254 is that reading and writing it takes a long time (perhaps
5 usec
From: Julian Elischer
Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works
under New Midi Driver Framework with a Fine Timer)
Date: Thu, 8 Jul 1999 11:23:42 -0700 (PDT)
Message-ID:
julian> this is problematic.
julian> you cannot add a new element before the p
this is problematic.
you cannot add a new element before the pending firing because you can't
tell how far into the present trigger you are.
On Thu, 8 Jul 1999, Doug Rabson wrote:
> On Thu, 8 Jul 1999, Seigo Tanimura wrote:
>
> > On Wed, 7 Jul 1999 19:46:38 -0700 (PDT),
> > Julian Elischer
On Thu, 8 Jul 1999, Seigo Tanimura wrote:
> On Wed, 7 Jul 1999 19:46:38 -0700 (PDT),
> Julian Elischer said:
>
> julian> With your scheme the clock needs to be always running at elevated
> speed.
> julian> Possibly you might have a startup routine that turns on the elevated
> julian> frequen
On Wed, 7 Jul 1999 19:46:38 -0700 (PDT),
Julian Elischer said:
julian> With your scheme the clock needs to be always running at elevated
speed.
julian> Possibly you might have a startup routine that turns on the elevated
julian> frequency, (basically does an 'aquire_timer0()' ) I would say t
On Wed, 7 Jul 1999 19:46:38 -0700 (PDT),
Julian Elischer <[EMAIL PROTECTED]> said:
julian> With your scheme the clock needs to be always running at elevated speed.
julian> Possibly you might have a startup routine that turns on the elevated
julian> frequency, (basically does an 'aquire_timer0(
On Thu, 8 Jul 1999, Seigo Tanimura wrote:
>
> Ow, I thought it was in the mailing list archive, turned out not.
> I will attach the paper below. Sorry for a long mail.
>
>
> --- v --- cut here --- v ---
> Unlike 16550, MPU401 does not generate an interrupt on TX-ready.
> So we have to choose o
On Wed, 7 Jul 1999 19:18:57 -0700 (PDT),
Julian Elischer said:
>> Sorry, finetimer(9) is the new timer implemented in my latest midi driver.
>> You can read the short paper describing the feature and principle in:
>>
>> Message-Id: <199907060959.saa05...@rina.naklab.dnj.ynu.ac.jp>
julian> how
On Thu, 8 Jul 1999, Seigo Tanimura wrote:
> On Wed, 7 Jul 1999 19:06:48 -0700 (PDT),
> Julian Elischer said:
>
> julian> uh...
> julian> [phaser.whistle.com] 536 man 9 finetimer
> julian> No entry for finetimer in section 9 of the manual
>
>
> Sorry, finetimer(9) is the new timer implement
On Wed, 7 Jul 1999 19:06:48 -0700 (PDT),
Julian Elischer said:
julian> uh...
julian> [phaser.whistle.com] 536 man 9 finetimer
julian> No entry for finetimer in section 9 of the manual
Sorry, finetimer(9) is the new timer implemented in my latest midi driver.
You can read the short paper descr
uh...
[phaser.whistle.com] 536 man 9 finetimer
No entry for finetimer in section 9 of the manual
On Thu, 8 Jul 1999, Seigo Tanimura wrote:
> Another idea has come to my mind...
>
>
> pca(4) currently uses acquire_timer0(), which changes the timer
> frequency directly, breaking finetimer(9).
Another idea has come to my mind...
pca(4) currently uses acquire_timer0(), which changes the timer
frequency directly, breaking finetimer(9). I am considering to
move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4)
comes to work again. Furthermore, we can get rid of acquire_timer0()
On Wed, 7 Jul 1999 19:06:48 -0700 (PDT),
Julian Elischer <[EMAIL PROTECTED]> said:
julian> uh...
julian> [phaser.whistle.com] 536 man 9 finetimer
julian> No entry for finetimer in section 9 of the manual
Sorry, finetimer(9) is the new timer implemented in my latest midi driver.
You can read t
uh...
[phaser.whistle.com] 536 man 9 finetimer
No entry for finetimer in section 9 of the manual
On Thu, 8 Jul 1999, Seigo Tanimura wrote:
> Another idea has come to my mind...
>
>
> pca(4) currently uses acquire_timer0(), which changes the timer
> frequency directly, breaking finetimer(9)
Another idea has come to my mind...
pca(4) currently uses acquire_timer0(), which changes the timer
frequency directly, breaking finetimer(9). I am considering to
move acquire_timer0()s in pca(4) to finetimer(9), so that pca(4)
comes to work again. Furthermore, we can get rid of acquire_timer0()
this is really cool, and i look forward to making use to this.
(perhaps it might be time to change the name of the patch subdir from
serial-midi to something else?)
thankyou so much for your diligent efforts!
On Tue, 6 Jul 1999, Seigo Tanimura wrote:
> Hi!
>
>
> MPU401, the most widely-used m
Ouch...
On Tue, 06 Jul 1999 18:59:23 +0900,
Seigo Tanimura said:
tanimura> You can try the patch at:
tanimura> http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/patch/
tanimura> newmidi-19990706.diff.gz
s/patch/patches/
Seigo Tanimura
To Unsubscribe: send mail to majord...@fr
Ouch...
On Tue, 06 Jul 1999 18:59:23 +0900,
Seigo Tanimura <[EMAIL PROTECTED]> said:
tanimura> You can try the patch at:
tanimura> http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/patch/
tanimura> newmidi-19990706.diff.gz
s/patch/patches/
Seigo Tanimura <[EMAIL PROTECTED]>
To
Hi!
MPU401, the most widely-used midi interface now works under
my midi driver framework. Another new thing is a fine timer
at a period of 156us, called directly from hardclock().
You can try the patch at:
http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/patch/
newmidi-19990706.diff.
Hi!
MPU401, the most widely-used midi interface now works under
my midi driver framework. Another new thing is a fine timer
at a period of 156us, called directly from hardclock().
You can try the patch at:
http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/patch/
newmidi-19990706.diff
20 matches
Mail list logo