Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Information requested to construct extra serial ports (kinda long)
Summary: Our first Merit Badge recipient?
Keywords: more ports newserial.device HELP!
Message-ID: <81638@sun.uucp>
Date: 14 Dec 88 18:59:10 GMT
References: <29527@tut.cis.ohio-state.edu>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 72

In article <29527@tut.cis.ohio-state.edu> (Ethan R. Dicks) writes:
>The device driver is where I am a little confused.  I can easily write the
>register twiddling, it is the DOS interface and overall design which
>confuses me...
>
>1)  What is the difference between a handler (as in port-handler) and a 
>	device (as in serial.device)?  Which one (or both) will I want to
>	write, to add the new device names COM1:, COM2: ...?
>
>2)  Can I use Matt Dillon's generic DOS device, or must I wade through the
>	RKM to pluck all the information myself?
>

This is one of the less well documented area of the Amiga (which is why
it is a merit badge :-)) and learning it will give you some additional
insights into what you can do with this machine. To start you off, I
can offer you what I know about the subject which is less than I would
like, specifically :

	The Amiga is a bicameral OS, part Exec, part TripOS, and depending
on where the task lives depends on what it is. A Handler, is the DOS 
equivalent to a device driver. It communicates with DOS via a series
of packets. These packets are documented in an article by Carolyn
called DOS Packets in 1.2 and to some extent in the AmigaDOS Technical
Reference manual (part of the Bantam book). All "high level" I/O on the
Amiga goes through handlers, and these are the things that are "Mounted"
and show up in the devices list when you type Assign with no arguments.
In the serial world you talk to "port-handler" when you open the device
SER:. (It is kind of kludgey the way it works, a good source of info on
this is the Washington DC DevCon notes. If you know someone that has
them great, otherwise I believe they will be available soon from CATS
(I'm sure I'll be corrected if this isn't so :-)). 

However, and this is where it gets ugly, there is another thing which
is referred to as the "Exec device." That is the thing called 
``serial.device'' that lives in your DEVS: directory. When you call
OpenDevice() that is what you will want to use as a name. This piece
is the one that actually talks to the hardware (and gave everyone
problems when it came time to add more serial ports). You communicate
with this task with Exec Messages. (Using our pals SendIO, DoIO, WaitIO, etc)
and it is set up more like a library. These kinds of devices are described
in the ROM Kernel Manual (under Devices). Generally, they stick to a 
standard format for the first few entries (OPEN, CLOSE, READ, WRITE0
but can have some non-standard ones as well (ETD_RAWREAD for trackdisk
comes to mind). Writing one is described in the back of the RKM and
there is a sample one around somewhere too. 

Now the another piece to the puzzle is the way in which they interact.
When you "Mount" something you include a device name. That tells the 
mount command which "Exec" device you want to use, and the Handler
which tells the Mount command where DOS should send packets to get
service from. (Question : what is the default handler when one isn't
specified?) Of course if you are just going to open the exec device
like VT100 does you don't even need to mount it, just put your device
into the DEVS: directory. When someone opens MYSER: they will connect
to your handler, when they open ethan.device they will connect to your
Exec device. In the case of the Handler they should be able to call
Read(), and Write() on it to get data, and on the exec device they
will use DoIO() to accomplish the same thing. 

So hopefully that is enough light to get you started, I really will
give you the first Handlers/Devices merit badge if you send me a copy
of what you did. The way the Merit Badge system will work is that after
completing a short questionairre about the subject, and having
submitted an original (and complete) code example that demonstrates
knowledge of the subject you will get the merit badge. The previous
recipients code samples will be available to keep duplication of
efforts to a minimum.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.