Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!hplabs!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: Things to do with devices
Message-ID: <3726@well.UUCP>
Date: Tue, 11-Aug-87 15:32:16 EDT
Article-I.D.: well.3726
Posted: Tue Aug 11 15:32:16 1987
Date-Received: Thu, 13-Aug-87 06:39:06 EDT
References: <3866@garfield.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: The NSC (North's Shredding Continues)
Lines: 68
Keywords: devices handlers

[ Of course I know UNIX.  Some of my best friends are UNIX. ]

In article <3866@garfield.UUCP> john13@garfield.UUCP writes:
>--
>Chuck McManis, in an article I read a couple of minutes ago, suggested the
>need for a SYNTH: and a MIDI: device. I would like to suggest a more
>generalized series of devices [ ... ]
>
>MUSIC: - you send it write commands in an understandable form, specifying
>         pitch, duration, optional pointer to waveform, etc and it plays it
>         for you.

	I like this one.  However, if you think about it *real* hard, this
is how the existing audio.device works.  Granted, it isn't very
straightforward.  I think the design of the audio.device was motivated more
by the hardware it was running on than by a more abstract, easily
programmable concept.

	I would have liked to see an interface that needed: Wavetable,
sampling rate (samples/sec), and volume (0-63).  Instead, we have to do all
this weird conversion.  Sigh.

>	  You could use DoIO, SendIO [ ... ]

	Not with a DOS handler, you can't.  You have to "packetize"
everything, and you can't (according to DOS manuals) have more than one
outstanding packet on a handler port at any time.  Can you say, "Extra layer
of software"?

>ANIM:  - you give it the sorts of parameters that you can specify in the new
>         IFF Anim formats and it does it for you. [ ... ]

	Sounds to me this would be better as a seperate program running in a
pipe stream.  DPaint tosses ILBMs at the pipe.  This program picks them up,
does the anim magic, and tosses the anim stream out another file (which
could be another pipe, like, the input to ShowANIM for example).

>DRAW:  - all the left-out functions like arcs, and the ones that require a lot
>         of rastport-twiddling could go in here.
>
	Nope, better as a shared library.  Having half your drawing code
doing library calls, and the other half doing I/O requests could be very
messy.

>PRT:   - well, it exists, but it could be greatly improved in future OS
>         releases. [ ... ]

	Hear, hear!  I think the current implementation is too limited.  I
think it should have been done like this:

	You open PRT: and write to it.  DOS takes the data and tosses it at
the printer.device.  The printer.device massages the data, and then tosses
it at a filename in AmigaDOS space.  This filename would be specified via
"Preferences".  Typically, you'd tell it to write to SER: or PAR:  However,
you could also tell it to write to SYS:printout.

	There are problems with this idea, though.  The main one I can think
of is that the printer.device would *have* to be written as a DOS process,
not a task (since it's making DOS I/O requests).  I don't know how
complicated that would be.  However, I think the benefits would far outweigh
the initial problems of making it happen.  It would make the printer.device
much more flexible.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_	 Bike shrunk by popular demand,	      dual ---> !{well,unicom}!ewhac
O----^o	 But it's still the only way to fly.  hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor