TIP: Click on subject to list as thread! ANSI
echo: cis.os9.6809.coco
to: Kevin Darling 76703,4227 (X)
from: Kevin Darling 76703,4227
date: 1991-07-28 09:12:58
subject: #11515-#you better read this

#: 11516 S10/OS9/6809 (CoCo)
    28-Jul-91  09:12:58
Sb: #11515-#you better read this
Fm: Kevin Darling 76703,4227
To: Kevin Darling 76703,4227 (X)



I asked before what speed you intended to run the timer at.  I'm a little dense
these days, so it's taken me a while to figure out you meant for MIDI? (None of
your postings have really indicated the purpose, which is important to what
can/can't be done.  I thought you meant for sound, to tell the truth).
Vagueness doesn't help here :-)

 "Write it like a Device Driver." [pass output path, delay, data]

This method appeals to me a lot.  However, if it's for MIDI (!), then wouldn't
you also want to embed control bytes to indicate how much data to send out
within a certain time period?  Apologies, but I'm not a MIDI guru, and you'd
know more about the requirements here (another reason you may not get answers).

By passing just the data address, the driver could look up the P$DATImg in the
calling process descriptor to find out which block(s) the data is in.

 "Write it like a SuperVisor Call (SysCall, whatever)."

DEPENDS on the use.  For MIDI... no, the pseudo-driver above sounds better. For
other applications (like an alarm call), the syscall makes more sense.

 "Or *will* OS9 immediately swap it in & branch to the code, upon a F$Send?"

No, it doesn't always.  Bruce Isted tried a kernel which did this at one time,
tho.  But not having anything that critical, we couldn't test it much :-)



There is 1 Reply.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.