erd@tut.cis.ohio-state.edu (Ethan R. Dicks) (12/14/88)
[ I wonder if the grue is a cousin to the line ea... ] From all the pleas on the 'net lately, I am considering picking up my long delayed project of working on a serial port expansion thing. I lack sufficient information on writing the device driver. The last time I picked up this project, I was stalled waiting for the mapper.device stuff to be finalized. I have decided to forge ahead and create an incompatible serial expander, mostly because it won't autoconfig, and thus, must be MOUNTed... The hardware is simple... plug a $20 PC/XT (or ESA, if you prefer) Serial card from JameCo (with or without the $10 extra port option) into any PC/XT bus adapter, such as the WEDGE. This gives you the UART registers sitting in a known place in memory. 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? I guess that question 1 is the more important. I see little distinction right now, but I surmise that there _must_ be some distinction, or there would not be both types. If I can get a skeletal structure, and a list of the DOS packet type that a serial port must accept (that _should_ be in the RKM), I can probably get a working driver banged out over Christmas break. Am I missing something? I am assuming that I will pass the address of the UART registers to the device driver via the MASK MountList entry. Is this a no-no? Is there a better way to do this? All the driver should need is the understanding designed in about the UART, and a base address of the registers, passed at MOUNT time, and the MASK entry seems the easiest way to pass a longword. The sooner I get some information, the faster I can get this done and into the world. Thanks in advance, -ethan -- Ethan R. Dicks | ###### This signifies that the poster is a member in Software Results Corp| ## good sitting of Inertia House: Bodies at rest. 2887 Silver Drive | ## Columbus OH 43211 | ###### "You get it, you're closer.
cmcmanis%pepper@Sun.COM (Chuck McManis) (12/15/88)
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.