#: 11564 S10/OS9/6809 (CoCo)
    31-Jul-91  23:56:51
Sb: #11563-#Timer Thoughts
Fm: PaulSeniura 76476,464
To: PaulSeniura 76476,464 (X)

..

Our discussions on Delphi have concentrated on how best to get that user task
kicked in or "goosed" once the timer pops.  I need to know more about lots of
things before we can even do some tests.  Those questions were brought up in
the second Timer article update.

If we did the pseudo-driver method, we already described what the record
formats would look like: not much different than the way MFConv/MFPlay does it,
but we'd need an extra field at the head of the record to specify the path# of
the real physical device to send the data when the timer pops.  But Jason
Bucata brought up the points I covered in that article: We have too much
overhead here, where the user pgm I$Writes to the pseudo-driver via SCF,
wherein the pseudo-driver buffers the data until the timer pops, at which time
another I$Write is issued with D.Proc saved/set to the user task# and writes
the buffered data to that passed path#, more SCF overhead.  You, Kevin, gave us
a response this last time concerning using P$DATImg, which I assume will
replace the act of I$Writing data from the user pgm to the pseudo-driver the
first time around.  *That* is an idea worth reconsidering this method of using
the timer.

But then some people on Delphi had an honest concern to not make the Timer
Driver be so ridged to do only Timed I/O like this.  Make it flexible and
usable in a variety of ways.  So I'm still very swayed about ditching the
pseudo-driver method.

Then came the SVC ideas, two of them (rounding out the three methods as
mentioned).  When we found out about F$Send, what you typed this last time, all
pretty much matched.  We tossed F$Icpt/F$Send out the door.  Too inaccurate to
base this 12-bit timer's resolution on.

..

There is 1 Reply.