peter@sugar.UUCP (Peter da Silva) (01/05/88)
AmigaDOS already HAS a method for binding names to devices. It's called
AmigaDOS. You can get the device info for any open file from the file
system.
#include <libraries/dosextens.h>
fh = Open("SER:", ACCESS_WRITE);
FH = (struct FileHandle *)(fh<<2);
Hmmm. The documentation is a mite skimpy on where to go from there. It seems
like it should be possible to go with it... send serial port messages to the
fh_Port in the structure. But what's the fh_Type feild?
If this works, this should be the way to go. I believe it's a bad idea to
duplicate a system that already exists. Anyone know more?
--
-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.jesup@pawl21.pawl.rpi.edu (Randell E. Jesup) (01/09/88)
In article <1359@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >AmigaDOS already HAS a method for binding names to devices. It's called >AmigaDOS. You can get the device info for any open file from the file >system. > >#include <libraries/dosextens.h> > fh = Open("SER:", ACCESS_WRITE); > FH = (struct FileHandle *)(fh<<2); > >Hmmm. The documentation is a mite skimpy on where to go from there. It seems >like it should be possible to go with it... send serial port messages to the >fh_Port in the structure. But what's the fh_Type feild? >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter Unfortunately, AmigaDos handlers are not designed to be a means of access to the underlying devices. In fact there may not BE an underlying device (ex: Ram:), or there may be different ones at different times (prt:), or there may be multiple devices at the same time (none presently). The fields in a filehandle structure, while named, are not documented and I believe most of the values are private to the handler. The fh_Port field is the MsgPort to send HANDLER requests to. P.S. I am crossposting this to BIX // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// lunge!jesup@beowulf.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup)
daveh@cbmvax.UUCP (Dave Haynie) (01/12/88)
in article <1359@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) says: > AmigaDOS already HAS a method for binding names to devices. It's called > AmigaDOS. That's absolutely true, and something I've been trying to get know for awhile. As I've pointed out before, though, it's not always simple to get EXEC level device and unit data from a DOS level name. At least, the method for this isn't documented, and damned if I haven't been able to figure it out completely. > You can get the device info for any open file from the file system. To a degree, perhaps. What I really want is the name of the EXEC device and the logical unit associated with any EXEC device, so I can use the low level EXEC I/O routines. What I get is sometimes the EXEC info and sometimes pointers to DOS level handlers instead, depending on the device in question. > #include <libraries/dosextens.h> > fh = Open("SER:", ACCESS_WRITE); > FH = (struct FileHandle *)(fh<<2); > Hmmm. The documentation is a mite skimpy on where to go from there. It seems > like it should be possible to go with it... send serial port messages to the > fh_Port in the structure. But what's the fh_Type feild? I would expect that the fh_Port structure is likely to be a message port to the device's handler, not the device itself. For most applications, especially things like serial port driving, you want real EXEC level access to the EXEC level device. DOS shouldn't get in the way. > If this works, this should be the way to go. I believe it's a bad idea to > duplicate a system that already exists. Anyone know more? Don't know much more myself. But I do agree that DOS does provide a standard and complete level of device abstraction, and it should be exploited in favor of any other system, providing the translation from abstrat to concrete is going to be a standard thing that I can do without special, inside information. > -- > -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter > -- Disclaimer: These U aren't mere opinions... these are *values*. -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
peter@nuchat.UUCP (Peter da Silva) (01/12/88)
In article <202@imagine.PAWL.RPI.EDU>, jesup@pawl21.pawl.rpi.edu (Randell E. Jesup) writes: > In article <1359@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >#include <libraries/dosextens.h> > > fh = Open("SER:", ACCESS_WRITE); > > FH = (struct FileHandle *)(fh<<2); > >Hmmm. The documentation is a mite skimpy on where to go from there. It seems > >like it should be possible to go with it... send serial port messages to the > >fh_Port in the structure. But what's the fh_Type feild? > Unfortunately, AmigaDos handlers are not designed to be a means of access to > the underlying devices. In fact there may not BE an underlying device > (ex: Ram:), or there may be different ones at different times (prt:), or > there may be multiple devices at the same time (none presently). So how do people get hold of their own console.device from Input()? Also... even if the existing handler isn't guaranteed to work for ALL devices, is there some way of making it work for the serial.device and to get people writing new devices to work in concert. The idea of having so many disparate name spaces on the machine is beginning to gibe me the heebie-jeebies. How hard would it have been to make all the devices accessible through AmigaDOS? That way you could ALWAYS map ports around just by using Assign.
ain@s.cc.purdue.edu (Patrick White) (01/13/88)
In article <3127@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >But I do agree that DOS does provide a standard >and complete level of device abstraction, and it should be exploited in favor >of any other system, providing the translation from abstrat to concrete is >going to be a standard thing that I can do without special, inside information. I agree. Now why don't we use this to implement multiple serial ports? eg: physical devices ---------------- mulitser: origser: <-- origional ser: device renamed logical mapped to ------- --------- ser0: origser: ser: multiser:1 <-- ser: mapped to multiser port ser1: multiser:1 ser2: multiser:2 multiser:0 origser: <-- can I do this? If I can, I could also use it for creating a hierarchical file system from a bunch of separate disks. Differing hardware (and names of device drivers to drive it) can be transparent to the user if the logical name is used. This allows reassignment of ser: to another port, and programs accessing the default port without realizing it. Also eliminates the need for device drivers calling device drivers, or one device driver knowing about all hardware designs. Ok, I think this sounds nice and elegant.. anybody want to point out why it won't work (or better yet.. figure out how to get around those obstacles)? -- Pat White UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906
jesup@pawl23.pawl.rpi.edu.UUCP (01/16/88)
In article <530@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: ... >Also... even if the existing handler isn't guaranteed to work for ALL >devices, is there some way of making it work for the serial.device and >to get people writing new devices to work in concert. What existing handler are you taking about????? >The idea of having so many disparate name spaces on the machine is beginning >to gibe me the heebie-jeebies. How hard would it have been to make all the >devices accessible through AmigaDOS? That way you could ALWAYS map ports >around just by using Assign. Acutally, my latest proposals for serial port expansion include a new handler, XSER:. This would tend to unify the device-level name-mapping for serial ports and the dos-level file-naming. You would open XSER:modem, for example, and the XSER: device would have the name-mapper get it a free serial port with a modem attached. This would even allow things like list to tell you which names exist, and allow assign to work. P.S. I'll x-post this to Bix. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup
jesup@pawl17.pawl.rpi.edu.UUCP (01/16/88)
[ This is cross-posted from BIX - Sorry, no quotes from original ]
Joanne -
It seems your sole motivation in calling them 'serialN.device' is
for pattern matching directory scans of devs:. One problem: it makes it
hard to remember which 'serialN.device' applies to which board. (if you
for example remove a board, which driver do you remove?)
The expansion drawer doesn't have to mean the device is loaded.
It would be easy to have them create just a memory-resident structure, ala
manx envirionment variable, saying what the name of the driver is if it is
not already loaded, and what types of things it is, from the Tool Types in it's
icon. (psuedo-code:
get tooltypes
if (library doesn't exist)
create it
get a new node
set it up (
driver = devs:mbserial.device
units = 2
attached devices[0] = <names from tooltypes>
attached devices[1] = <names from tooltypes>
<whatever else, flags, etc>
)
add to memory-resident list
cleanup and shutdown.
). This would take almost no memory, and wouldn't require the devices to
be loaded when there are not needed. The mapper would use this to find the
devices and what their names are. Not having to have all the serial devices
in memory is one of the reasons why I prefer it to the unit number approach
to serial expansion.
Parameters files are ok, but it can cause confusion for icon-oriented
users. Think of joe user: he removes the icon for the expansion product
from the expasion drawer, and gets all confused because it keeps trying
to open the device. They aren't totally evil, but I think a expansion
drawer file/icon will be needed anyway, so why not put them in there? You
can still have a single program that allows you to edit them all, ala prefs.
Requesters for remapping the serial.device are easy. (Should also
have a 'force' to another port option.) Just write a fake device to replace
serial.device that does the requester, and move serial.device to
oldserial.device. A bit reminicient of SetAlert.
I do thank you for your input, Joanne. Remember, I'm not doing
anything official here, I'm just concerned about making whatever becomes
'standardized' something _I_ don't feel obliged to re-write as well. :-)
Randell Jesup
P.S. I will x-post this to usenet...
// Randell Jesup Lunge Software Development
// Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180
\\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942
\/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesupjesup@pawl17.pawl.rpi.edu (Randell E. Jesup) (01/16/88)
[ This is cross-posted from BIX, and is (I hope) very thorough. It mainly
addresses using icons in the expansion drawer, but also weighs the pros
and cons of my proposals, and gives example code and data structures. ]
[These are taken from drivers.doc of the gamma readmes.]
...
< your driver code:
< Find the list of boards. Mark them a configured, and record
< your driver in them (for system debugging). return non-zero
< value if everything went ok. If something went wrong (or you
< just want to be unloaded) then return NULL.
...
< 4. Attempt to load in the driver. The driver may be a device, library,
< task, process, or anything else that you may want. The only requirement
< is that it have a Resident structure in its first hunk. (By the
< way, this means that you can not directly use startup.obj). This
< is why we refer to loading a "driver" rather than a "device" -- you
< can write any sort of code you want to handle your device.
<
< 5. Binddriver will search the first hunk for a Resident structure.
< If it cannot find one, it will assume some awful mistake has
< been made, and will unload the segment.
<
< 6. Finally we get to running some of YOUR code. InitResident() is
< used to start you off and running. The return value from
< InitResident (and therefore the return value from your init
< entry point) will be checked on exit. If it is zero then the
< segment will be unloaded. This can be useful if you only
< need to do a bit of initialization and then can go away, such
< as allocate additional expansion memory for a non-expansion
< architecture board.
<
< You should (among everything else you might be doing) open
< the expansion.library and ask for the current bindings
< (GetCurrentBinding()). In this structure will be the head
< of a singly linked list of ConfigDev structures. The structures
< are linked via the cd_NextCD field. You should deal with
< each member of the list -- they are for you!
<
< There are two actions that you MUST take. One is to unset
< the CDB_CONFIGME bit in the cd_Flags. If you do not do this
< then the board is still available for other drivers (of course,
< you may actually want this...). If you do unset the CONFIGME
< bit, please also record your "node" in the cd_Driver structure.
< It is assumed that this is an exec node, whose LN_NAME field
< points your your name, and LN_TYPE field is your type of "thing" --
< libarary, resource, device, task, etc. I know that this will
< not always hold, but try it anyway. It will help the rest of
< us debug the system when something goes wrong.
<
< You have now done everything you wanted to. Your init routine
< is about to return. If you return a zero, then your code
< will be unloaded. If you return non-zero then you will stay
< around.
[end insertion]
It looks like it's quite easy to set up a small program that
will be unloaded after it adds your device to the list of serial
devices. Just return NULL and you are unloaded. I would suspect that
any hardware manufacturer would want to have some sort of expansion drawer
code anyway, if only to watch for multiple boards so they can be handled by
one driver.
So the code attached to the icon would look like this:
<startup>
<find boards, do any magic required>
<if serial_exp.library doesn't exist:>
<create it>
<create handler entry for XSER:, to be loaded on reference>
/* This avoids using the mountlist, requires no code loaded */
For each board you are handling...
<get the disk object>
<make a node for the board, record any info needed>
For each unit...
<look for tooltypes describing the names bound to the units>
<add them to the node>
<if your driver is not in ROM and not here, exit NULL>
<else start driver up, return appropriate non-null>
The idea is that the driver could live in devs, and not be forced to
be loaded at boot, only when needed. The hardware manufacturer could decide
otherwise, if they wished.
These next two lists refer to the proposal to add a name-mapper
with expansion drawer icons/programs to set up the mapping, as discussed.
One could use a config file instead of expansion drawer icons, but I
consider that sub-optimal. The advantages listed are for my proposals,
as elaborated, over increasing unit numbers via a high priority serial
device, and over a config file for namings.
Advantages:
1. The resident data on serial ports/units means that when you
open a serial port, no searching of directories has to be done
(glacial on floppies).
2. It (resident data) means no naming conventions for drivers are
needed, which should make maintenance easier.
3. The resident data has very small overhead compared to a whole
driver.
4. If you remove a board, there is no need to remove it from
any master config files, or even remove the drivers or files
in the expansion drawer, as expansion drawer programs are only
run if the matching board is present.
5. Expansion ports are always known by name or function, not
by user-obtuse or volitile numbers. Less programs will need
to be configured by the user, as they can just, for example,
open a modem, and the user doesn't have to remember that
unit 5 is a modem, for example.
6. No overhead after the OpenDevice, as the IOExtSer passed is
initialized with the device address by the driver that is
eventually opened.
7. No confusion over how unit numbers are assigned.
8. No naming conflicts with serial.device (Bryce states that his
serial.device links in at higher priority. This works, but
only if his serial.device is loaded AFTER the old serial.device
AND if it is created by a program (you can't have two files
named "serial.device" in the devs: directory.))
9. Less problems from some programs using higher unit numbers,
and others using name mapping (Bryce agrees a name-mapper
should exist, but is trying to persuade people to use higher unit
numbers, and has posted no real design for a name-mapper.)
10. Relatively "clean" design, oriented towards the same ideas
that the expansion standards are: drop it in, no careful setting
of switchs, no hacker needed to configure it.
Disadvantages:
1. Requires the user run a program so the file can get in
devs:. (This applies to all schemes that put drivers there,
however, so it's no real loss. Plus something needs to make
sure for all schemes that some new software is installed,
so it's even less of a loss.)
2. Requires a prefs-type program to change names for units,
instead of editing a file with a text editor. Can also
be seen as a plus, as most novices don't know how to get to
a text editor, let alone how to use one (requires CLI unless
you have PD/whatever stuff - Notepad doesn't count here.)
3. Requires a small amount of ram for the fake library and
the nodes for each device/unit. This is pretty minimal
compared with forcing a driver (even one) to be resident.
4. Requires serial device users to add 5 or so lines to their
OpenDevice calls, which can be standardized. Not a big
overhead, less than the code required to let the user change
the unit number, probably.
5. ??? (I'm obviously biased, add you own here.)
Appendix: Structures and code fragments related to above
struct IOExtMap {
struct IORequest ior;
struct IOExtSer *Serial;
ULONG Flags;
ULONG Error;
UBYTE *Name;
/* I think that's all we need */
};
Code for user program instead of OpenDevice("serial.device",0,...)
<set up IOExtSer as always>
myIOExtMap.Serial = &myIOExtSer;
myIOExtMap.Flags = MAPFLAGS;
myIOExtMap.Name = "Modem";
myIOExtMap.Error = 0; /* probably redundant */
if (OpenDevice("mapper.device",0,&myIOExtMap,0))
if (myIOExtMap.Error != 0)
/* mapper exists but can't open desired device */
report some error
else if (OpenDevice("serial.device,0,&myIOExtSer,0))
report error
/* the else clause is if the user doesn't have */
/* the serial expansion software. */
/* If we get here without error, we can use IOExtSer */
This is being cross-posted to Bix and Usenet.
Randell Jesup
// Randell Jesup Lunge Software Development
// Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180
\\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942
\/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesuppeter@nuchat.UUCP (Peter da Silva) (01/22/88)
In article <217@imagine.PAWL.RPI.EDU>, jesup@pawl23.pawl.rpi.edu (Randell E. Jesup) writes: > In article <530@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >Also... even if the existing handler isn't guaranteed to work for ALL > >devices, is there some way of making it work for the serial.device and > >to get people writing new devices to work in concert. > What existing handler are you taking about????? The one returned by DeviceProc("SER:");. > Acutally, my latest proposals for serial port expansion include a new handler, > XSER:. This would tend to unify the device-level name-mapping for serial > ports and the dos-level file-naming. You would open XSER:modem, for example, > and the XSER: device would have the name-mapper get it a free serial port > with a modem attached. This would even allow things like list to tell > you which names exist, and allow assign to work. I don't see the advantage of XSER:modem over Modem:. With Modem: you can assign stuff, and even get a list of devices using assign with no args. It's a bit of a pain to get the devices from a program, but you can do it... my programs all look through the device list. To make it totally clean, you need a generic device-name device like my old suggestion of "dev:". But that's totally optional. 1> dir DEV: Workbench1.2 Auxilary VDISK RAM Disk AUX PIPE VD0 DF1 DF0 PRT PAR SER RAW CON RAM 1> cd DEV:VDISK 1> cd dev:prt Can't find dev:prt 1> cd DEV:VDISK -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
papa@pollux.usc.edu (Marco Papa) (12/16/88)
In article <3102@sugar.uu.net| peter@sugar.uu.net (Peter da Silva) writes: |In article <14049@oberon.USC.EDU|, papa@pollux.usc.edu (Marco Papa) writes: |about a terminal program that lets you specify the unit number for the |serial device, but not the driver. | || So harware guys, when are we going to get multiple serial devices? || The software is ready. | |No it's NOT. "serial.device" doesn't support more than one UNIT. Another ^^^^^^^^^^^^^ |manufacturer will have to call their driver "rs232.device" or "myserial.device" |or something like that. | |Anything they do to make "serial.device" accept multiple unit numbers (map |their memory in to some magic place, for example, or patch serial.device |to their code) is going to be (as I mentioned) a horrible kludge. Sorry, but I know for a fact that we will very likely see "somebody's" serial.device with multiple unit numbers. That one will work with A-Talk III. Serial drivers that have different names will also work with A-Talk III. One will be able to select them with: DEVICE=name such as: DEVICE=modem.device also on the ToolTypes Info. I was planning to post the code to do this, but unfortunately this is modified from a MANX library source file, wbparse.c, which is copyrighted and not redistributable. Sorry. It shouldn't be that difficult to figure it out, even if one doesn't have the sources. The whole thing is less than 20 lines of code. So, to repeat again, are any harware guys ready to deliver a multiserial.device? ASDG? CMI? -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
peter@sugar.uu.net (Peter da Silva) (12/17/88)
In article <14097@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > In article <3102@sugar.uu.net| peter@sugar.uu.net (Peter da Silva) writes: > |No it's NOT. "serial.device" doesn't support more than one UNIT... > ^^^^^^^^^^^^^ > |Anything they do to make "serial.device" accept multiple unit numbers (map > |their memory in to some magic place, for example, or patch serial.device > |to their code) is going to be (as I mentioned) a horrible kludge. > Sorry, but I know for a fact that we will very likely see "somebody's" > serial.device with multiple unit numbers. Well, calling it "serial.device" is a horrible kludge. They should give it their own name. I'd rather binary patch every one of my modem programs to the new name than rely on a driver that expects to be able to diddle with the device list, doesn't let me access my own port. > III. Serial drivers that have different names will also work with A-Talk III. Well, why didn't you *say* so. Yes, folks, this man is doing the right thing. Thank you. Still and all, giving a new device the same name as an old one is really uncool. Don't encourage it. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn busines#!rne
acs@pccuts.pcc.amdahl.com (Tony Sumrall) (12/22/88)
(This apparently didn't make it out the first time. Note that the promised change is now in 2.9.) Both 2.8 and 2.9 initialization scripts allow the user to specify unit = <unit-number> but not device = <device-name> I'll put support for the device command into 2.9. -- Tony Sumrall acs@pccuts.pcc.amdahl.com <=> amdahl!pccuts!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
ewhac@well.UUCP (Leo L. Schwab) (12/23/88)
[ 3M TA3 ]
Well, I just got through catching up with a 350-message backlog in
this group. Try not to talk so much when I leave on a weekend vacation. :-)
There has been discussion about how termulators should access the
exec-level device drivers. ATalk's solution is to put a DEVICE ToolType in
ATalk's icon.
If I remember correctly from the 1988 DevCon notes, the correct way
to go about supporting multiple serial ports is to go through DOS. (Wait!
It's not what you think!) By walking down arcane lists in the DOS, you can
discover the name of the exec device that is associated with a DOS handler.
It is in this manner that you're supposed to get the device name and unit
number for passing to OpenDevice().
Checking the notes, I find this doesn't work for SER:, PAR:, or
PRT:. Oh well. It's worth reading up on, anyway.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
\_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The DoctorHurn@cup.portal.com (Edward Hurn Braswell) (12/30/88)
Hmm.. I see some talk about implementing multiple serial ports (a multiple serial port DRIVER, by any other name, hopefully gets the job done But.. WILL such a hard-ware Creature appear on the market? (Accompanied by maybe a nice device.driver, and suitable patches for Comm terms (or a comm ter that will work with it?) Now.. that's the question!
papa@pollux.usc.edu (Marco Papa) (12/31/88)
In article <13054@cup.portal.com> Hurn@cup.portal.com (Edward Hurn Braswell) writes: >Hmm.. I see some talk about implementing multiple serial ports >(a multiple serial port DRIVER, by any other name, hopefully gets the job done > >But.. WILL such a hard-ware Creature appear on the market? (Accompanied by >maybe a nice device.driver, and suitable patches for Comm terms (or a comm ter >that will work with it?) We are aware of at least 5 different manufacturers of A2000 cards that will provide multiple serials ports (1, 2, 7, or 8 ports). We have furnished all of them with beta versions of our software that supports such cards. I would assume that more than one of those cards will be released 1Q89. All of the cards will come with their own serial device driver. As far as Comm programs working with such cards are concerned, I can only speak for myself. A-Talk III does already support multiple serial UNITs in the current version (but you can't really use it until such cards are out :-) A-Talk III 1.1 (due out end of January) also supports "alternate" device names, BOTH from CLI and Workbench. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
boom@concour.CS.Concordia.CA (Hendrik J. Boom) (01/07/89)
What we really need is not multiple serial ports for the Amiga, but an X25 packet-mode port and affordable X.25 service from the carriers. X.25 calls are packetized and error-checked, follow international standards, and multiple calls can go over a single physical connexion simultaneously.
karl@sugar.uu.net (Karl Lehenbauer) (01/08/89)
To anyone who might be developing a multiport serial board, two things: 1) Consider using the NEC 16550A's rather than 8250's or whatever, because the 16550's have a 16-byte typeahead buffer. At high speeds, it is very difficult to get out and get all the data on the Amiga. For example, at MIDI speeds, bytes come in every 333 microseconds. It's hard to catch them all, indeed impossible, as the exec seems to sometimes leave interrupts off for longer than that. With 16550's, the minimum time the system has available between the UART receiving a data byte and the system reading it before getting an overrun is widened by a beefy 16X, for MIDI to about 5 ms. 2) Please support MIDI as well as RS-232. Supporting MIDI requires only a couple of things: One is that you need to be able to produce data at 31250 kilobits (1 megahertz / 16) per second. The other is that you produce 0 and 5 volts for logic 0 and 1 rather than the -12 and +12 for RS-232 and that you use an opto-isolator capable of a few microseconds switching times on the input data wire. -- -- uunet!sugar!karl | "We've been following your progress with considerable -- karl@sugar.uu.net | interest, not to say contempt." -- Zaphod Beeblebrox IV -- Usenet BBS (713) 438-5018
pnelson@antares.UUCP (Phil Nelson) (01/08/89)
In article <554@sunkisd.CS.Concordia.CA> boom@concour.CS.Concordia.CA (Hendrik J. Boom) writes: >What we really need is not multiple serial ports for the Amiga, but an >X25 packet-mode port and affordable X.25 service from the carriers. >X.25 calls are packetized and error-checked, follow international >standards, and multiple calls can go over a single physical connexion >simultaneously. 1st, PLEASE EVERYONE REMEMBER THAT I AM NOT SPEAKING FOR TYMNET!!! Whew, now that I have that out of the way, I want another serial port! (sorry, I'm shouting again, but that's how I feel about it). I have several reasons, some of them have already been discussed here, I hope no-one minds if I list them again... 1. I want to talk to other RS-232 devices in my house. I have a Co-Co running a BSR home controller, it has a serial port, someday (after I learn 6809 assembly) I want my Amiga to talk to it. Or, if that's too tough, I will buy a BSR controller that talks ASCII and program direct. Either way, I need another serial port on the Amiga if I want to be able to modem at the same time. 2. I want my Amiga to dial the (Voice) phone for me. I know I could probably do this just using the sound chip and holding the phone up to the speaker, but maybe I don't want to do it that way. Maybe I want to use my outdated autodial modem, which otherwise will be gathering dust after I buy the new extra-high-speed whatever. Note that to do the latter, all I have to do is plug it in and write a SIMPLE (even I can do it) BASIC program to send the ASCII commands to the port. Or, I don't even have to write a program, the Gizmoz Rollodex (for one) is already set up for this, but I don't use it, since I have separate phone lines for voice and data. 3. I don't want to pay for what I can get for free. Don't get me wrong, the dial-up multiple circuit idea is a good one, obviously well suited to the Amiga, and thanks for reminding me, I really should be trying to talk someone into writing an X.PC (Tymnet's multiple-circuit ASYNC packet protocol) driver for the Amiga, but, even after I have all this hypothetical multi-channel capability, I don't want to be hooked into using (and paying for) outdial to play FirePower with my neighbor while my data is downloading from somewhere. I probably couldn't use FirePower on a multi-port anyway, but you get the idea, I hope. A n y w a y , (that was long, wasn't it?) you need more than an 8520 chip to do the HDLC, plus you're going to need a sync modem. If you have all that, and someone writes the X.25 driver (much too tough for me, I can't even do the X.PC driver) you can call up Tymnet X.25 (I'm not making any promises about affordable, though). By the way, the X.PC protocol is public domain, anyone can write a driver. I don't know why no-one has done one for the Amiga, maybe it's my fault, I should have promoted it, or learned more about low-level stuff and done it myself, or something... Of course, there is a catch to Tymnet X.PC; Someone would have to pay net charges for all those multiple circuits. And about prices going down, well, I don't know (it's not my department). I wouldn't hold my breath, especially if the FCC decides to have another go at us. So don't say I didn't warn you, if you do X.PC, it will cost you money to use it, OK? extra disclaimer: I really don't know anything special about Tymnet prices, I'm just a virtual fireman (A.K.A. Network Technical Support). -- Phil Nelson at (but not speaking for) OnTyme:NSC.P/Nelson Tymnet, McDonnell Douglas Network Systems Company Voice:408-922-7508 UUCP:{pyramid|uunet}oliveb!tymix!pnelson LRV:Component Station
aaron@madnix.UUCP (Aaron Avery) (01/08/89)
In article <554@sunkisd.CS.Concordia.CA> boom@concour.CS.Concordia.CA (Hendrik J. Boom) writes: >What we really need is not multiple serial ports for the Amiga, but an >X25 packet-mode port and affordable X.25 service from the carriers. >X.25 calls are packetized and error-checked, follow international >standards, and multiple calls can go over a single physical connexion >simultaneously. I agree with this to a certain extent. We do, however, need multiple serial ports for the Amiga. Hopefully, that need will soon be taken care of by us (ASDG) and others. As for cheap networking, X.25 would be one way to go. I seem to recall that X.25 is a bit-synchronous hardware interface. The amiga already has one of these built in (two, counting the keyboard). This would eliminate the need for additional hardware (unless you want to use your parallel port), but the software requirements would be great. Another cheap standard to think about is AppleTalk, which will probably be possible using some of the serial ports coming out soon. Aaron -- UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron {decvax|att}! ! {uunet|ncoast}!marque!
scotty@ziggy.UUCP (Scott Drysdale) (01/09/89)
In article <3241@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >To anyone who might be developing a multiport serial board, two things: > >1) Consider using the NEC 16550A's rather than 8250's or whatever, because >the 16550's have a 16-byte typeahead buffer. At high speeds, it is very >difficult to get out and get all the data on the Amiga. For example, at >MIDI speeds, bytes come in every 333 microseconds. It's hard to catch >them all, indeed impossible, as the exec seems to sometimes leave interrupts >off for longer than that. With 16550's, the minimum time the system has >available between the UART receiving a data byte and the system reading >it before getting an overrun is widened by a beefy 16X, for MIDI to about >5 ms. > >2) Please support MIDI as well as RS-232. Supporting MIDI requires only >a couple of things: One is that you need to be able to produce data at >31250 kilobits (1 megahertz / 16) per second. The other is that you produce >0 and 5 volts for logic 0 and 1 rather than the -12 and +12 for RS-232 and >that you use an opto-isolator capable of a few microseconds switching times >on the input data wire. >-- >-- uunet!sugar!karl | "We've been following your progress with considerable >-- karl@sugar.uu.net | interest, not to say contempt." -- Zaphod Beeblebrox IV >-- Usenet BBS (713) 438-5018 first of all, anyone who develops a multiport serial board that doesn't have it's own CPU on board is absolutely nuts. using interrupts from the UARTs is also grounds for the electric chair. i've done this before - the board was an intel SBC547, which is a multibus I card with and 80186, 4 zilog SCCs, and some rom and ram. the firmware that came with the board really sucked, so we rewrote it and made it compatible with the device drivers that normally worked with the 547 (running intel's firmware). the final solution was basically as follows: - all operations are polled. - communication requests from the host (multibus) generate an interrupt - the host manages it's transmit queue in our memory (32K of dual port RAM) - we manage the receive queue. - a 1 millisecond timer interrupt causes the 8 uarts to be polled for receive and transmit until they're empty or full. - minimal other work is done in the 1ms interrupt (xon/xoff checking for instance). - the 1ms interrupt fills and empties a set of secondary circular queues. - the main (idle loop, non interrupt) portion of the software merely - keeps an eye on requests from the multibus and the states of the uart transmit/receive queues and shuffles stuff back and forth between the dual port ram and the secondary queues. we also decided to put polling for hardware handshakes here (CD, RTS, etc). we measured the performance of the interrupt handler and when it had a full pile of work to do (3 bytes in each uart for receive, 2 bytes to transmit to each uart, xon/xoff checking) it took around 600 microseconds. that's 60% usage, allowing the host interface idle task to have 40% time even when the machine is doing 19.2K TX/RX at full blast on all 8 ports. because the host interface is sort of a background task, interesting things happen as far as loading of the host. the busier the board gets, the more efficient host transactions become. fewer interrupts (cuz the main loop goes through fewer cycles) with more data available per interrupt (since it's piling up due to the slow loop). as to midi, i suppose it would work as it stands for light traffic (assuming that no more than 3 bytes arrive on a given port per millisecond). to make it really handle midi, the simplest way would be to cut the number of ports in half and cut the 1ms interrupt down to a 500 microsecond interrupt. alot of the stuff the interrupt handler normally performs could also be removed, so maybe making the interrupt handler around 750 microseconds and cleaning up the handler could do it for 8 ports, but again it's not really full speed yet. yeah yeah, a faster 186! that's the ticket! i would just *LOVE* to whip up a similar board for the amiga (even if only for releasing the schematics and software to PD), if only i had the following: 1) useful description of how serial.device is supposed to behave (sorry, the RKM just doesn't cut it) 2) useful description of a device driver in general (again, the RKM is sort of wrong in several places - most notably the example device). the only device i have gotten to work is the scottdisk.device, but it bears very little resemblance to the RKM example, but they seem to do the same things. one works, one doesn't. anyone have any comments? --Scotty
pnelson@antares.UUCP (Phil Nelson) (01/09/89)
When I wrote "outdial" late last night, I meant to write: "Outdial (R)", I
think. No, I'm not sure, I'm not in the legal department either. Anyway, if
you can believe the Tymnet Information, "Outdial" is a registered trademark
of Tymnet, McDonnell Douglas Network Systems Company (that is what that (R)
means, isn't it?).
--
Phil Nelson at (but not speaking for) OnTyme:NSC.P/Nelson
Tymnet, McDonnell Douglas Network Systems Company Voice:408-922-7508
UUCP:{pyramid|uunet}oliveb!tymix!pnelson LRV:Component Stationkarl@sugar.uu.net (Karl Lehenbauer) (01/10/89)
In article <147@ziggy.UUCP>, scotty@ziggy.UUCP (Scott Drysdale) writes: > first of all, anyone who develops a multiport serial board that doesn't have > it's own CPU on board is absolutely nuts. using interrupts from the UARTs > is also grounds for the electric chair. It's not as necessary as it used to be. With the chip I mentioned, the NEC 16550A, it can buffer up to sixteen bytes of input data. That means you can have as many as 16 times fewer interrupts...only 60 a second for one port at 9600 baud. You can set a lowater mark, too, to where the chip won't generate an interrupt until that number of chars (or a timeout?) has been received. You also reduce costs a lot and obviate the need for a superhacked custom driver -- they're tricky. I think a 4-port board based on 16550s for, say $300 retail, would be desirable to most people over a 4 or 8 port smart board for $600-1000, and I'm cutting some slack there because PC/AT smart boards all seem to be over $1000. Plus, I still need MIDI and my stuff is already ready for it from a dumb port -- the default in the machine is one, after all, and the smart board will probably need a precision clock and internal specific intelligence for MIDI -- sort of like a multiport version of the Roland MPU-401. The trouble is, too, it's more expensive plus the programming model is totally different. i've done this before - the board was > an intel SBC547, which is a multibus I card with and 80186, 4 zilog SCCs, and > some rom and ram. ...remains of serial I/O performance story deleted. I too worked on a system that didn't have enough serial I/O throughput, an 8 MHz 8086 Multibus system (this was a few years ago) running the JMI C Exec couldn't receive 9600 baud data on even one port using 8251s. We switched to Zilog Z8530s, which have a 3 byte typeahead buffer, and it could receive all the data it needed to and not lose bits, a line in at 9600, in at 2400 and out at 9600. I never tested to see how far it could go. I guess the point is that I had a really favorable experience with adding typeahead buffer in the UART, and it's less expensive and easier -- the 16550As are 8250 pin-compatible, by the way. -- -- uunet!sugar!karl | "We've been following your progress with considerable -- karl@sugar.uu.net | interest, not to say contempt." -- Zaphod Beeblebrox IV -- Usenet BBS (713) 438-5018
aaron@madnix.UUCP (Aaron Avery) (01/10/89)
In article <3241@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >To anyone who might be developing a multiport serial board, two things: > >1) Consider using the NEC 16550A's rather than 8250's or whatever, because >the 16550's have a 16-byte typeahead buffer. At high speeds, it is very Thank you for the suggestion, but all of the multiport serial boards that I'm aware of are well past the hardware design phase (I guess all but ours would almost have to be, for me to know about them!). The chip we use is the Zilog 8530 SCC. This is probably the chip most people are planning to use. The 8530 can receive 3 full bytes before an overrun will occur. Granted, 16 would be better, but it's not quite as bad as you perhaps thought it was. Is the 16550A a superset of the 8530? The 8530 has some very nice built-in features that a designer wouldn't want to give up. If it's pin and software compatible with the 8530, maybe I'd like to look into it further. Is it? >2) Please support MIDI as well as RS-232. Supporting MIDI requires only Our device driver supports any baud rate from 110 through 38,400. So we fully support MIDI in the software. In fact, our driver handles it better than the serial.device does. As for the hardware end, you'd have to adapt the port to MIDI just like you would any other RS-232 port. Our little modules may be a little more hackable than the Amiga motherboard, if you wanted to save a little money, but, of course, that would void your warantee. -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." {decvax|att}! -- Robin Williams UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron {uunet|ncoast}!marque!
aaron@madnix.UUCP (Aaron Avery) (01/10/89)
In article <147@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes: >first of all, anyone who develops a multiport serial board that doesn't have >it's own CPU on board is absolutely nuts. using interrupts from the UARTs >is also grounds for the electric chair. i've done this before - the board was We've done this before, too. And I guess we're absolutely nuts and should be put to death, too. The real toss-up here is that if you want to design a high-end (pricey) multiport serial board, you must choose between an on-board processor, and DMA support. With DMA, the main CPU doesn't have to move any data anywhere, thus data- transfers are easier on it. Also, the main CPU gets about as many interrupts either way - there's a bit more overhead for checking the ports to see who's really done, and vectored interrupts would take care of that. The main reason for putting a processor on-board is to add intelligence to it, such as command parsing, built-in error correction protocols, etc. >an intel SBC547, which is a multibus I card with and 80186, 4 zilog SCCs, and Oh, and since I'm nuts, I guess I get to call anyone who programs an 80186 in assembly nuts. >anyone have any comments? Yes. I like the idea of a timer interrupt for handling this if you don't have DMA. The real problem with that is when you only have one CPU to handle the interrupts, the timer is more overhead than needed when the ports _aren't_ very active. -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." {decvax|att}! -- Robin Williams UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron {uunet|ncoast}!marque!
scotty@ziggy.UUCP (Scott Drysdale) (01/11/89)
In article <3256@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >In article <147@ziggy.UUCP>, scotty@ziggy.UUCP (Scott Drysdale) writes: >> first of all, anyone who develops a multiport serial board that doesn't have >> it's own CPU on board is absolutely nuts. using interrupts from the UARTs >> is also grounds for the electric chair. > >It's not as necessary as it used to be. With the chip I mentioned, the NEC >16550A, it can buffer up to sixteen bytes of input data. That means you >can have as many as 16 times fewer interrupts...only 60 a second for one port ... >Plus, I still need MIDI and my stuff is already ready for it from a dumb >port -- the default in the machine is one, after all, and the smart board >will probably need a precision clock and internal specific intelligence >for MIDI -- sort of like a multiport version of the Roland MPU-401. The >trouble is, too, it's more expensive plus the programming model is totally >different. that's a good point about midi timing. it would be relatively easy to add a mode to the board which caused it to recognize blobs of midi stuff and append a timestamp to them. my current idea for the board is having 64K of dual port RAM which looks from the amiga as one 64K block (amazing - the minimum autoconfig size!) and looks to the 80186 as 32K of data space at location 0 and 32K of code space at F8000. the amiga will upload the 186 code to the board, which should help as far as getting customized drivers into the board. as to the timing stuff, there are at least 2 (maybe 3) timers built into the 186, and i'll be using only one of 'em for the poll interrupt. that's enough left for timestamp counters. ... >I guess the point is that I had a really favorable experience with adding >typeahead buffer in the UART, and it's less expensive and easier -- the >16550As are 8250 pin-compatible, by the way. that's nice - but consider that you'll need 8 8250's to take the place of 4 SCC's - or is there a dual version of the 15660A in a 40 pin package? also, does it have it's own baud rate generator inside? >-- >-- uunet!sugar!karl | "We've been following your progress with considerable >-- karl@sugar.uu.net | interest, not to say contempt." -- Zaphod Beeblebrox IV >-- Usenet BBS (713) 438-5018 --Scotty
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (01/11/89)
In article <149@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes: >In article <3256@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: [...] >>Plus, I still need MIDI and my stuff is already ready for it from a dumb >>port -- the default in the machine is one, after all, and the smart board >>will probably need a precision clock and internal specific intelligence >>for MIDI -- sort of like a multiport version of the Roland MPU-401. The >>trouble is, too, it's more expensive plus the programming model is totally >>different. >that's a good point about midi timing. it would be relatively easy to add >a mode to the board which caused it to recognize blobs of midi stuff and >append a timestamp to them. That still leaves the problem that the programming model is different. More serial ports for MIDI won't do much good if no programs support them. And no programs will support them if every serial port behaves differently. I would really like to see some of this hidden by the device driver. If we had a serial.device with a MIDI mode, which would timestamp incoming events (and possibly send out events on a schedule), then manufacturers of add-on serial ports could reproduce this functionality in their device drivers using whatever hardware capabilities their board has. And MIDI software writers would have a standard device that did all the things they need. -Dan Riley (dsr@lns61.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
scotty@ziggy.UUCP (Scott Drysdale) (01/12/89)
In article <373@madnix.UUCP> aaron@madnix.UUCP (Aaron Avery) writes: >In article <147@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes: >>first of all, anyone who develops a multiport serial board that doesn't have >>it's own CPU on board is absolutely nuts. using interrupts from the UARTs >>is also grounds for the electric chair. i've done this before - the board was > >We've done this before, too. And I guess we're absolutely nuts and should be >put to death, too. > >The real toss-up here is that if you want to design a high-end (pricey) >multiport serial board, you must choose between an on-board processor, and >DMA support. so the parts cost is around $30 more than a non CPU design - but you end up with much greater throughput. i prefer performance over inexpensiveness. how well would the interrupt or polling scheme using only the 68000 work when you add several of these boards to the machine with 8 ports on each board? >With DMA, the main CPU doesn't have to move any data anywhere, thus data- >transfers are easier on it. Also, the main CPU gets about as many interrupts >either way - there's a bit more overhead for checking the ports to see who's >really done, and vectored interrupts would take care of that. yeah, DMA is cool - but DMA on the amiga has it's little problems. i think a DMA design without it's own CPU would be as costly as the CPU on board approach and would require more overhead from the host CPU than the CPU on board method. >The main reason for putting a processor on-board is to add intelligence to it, >such as command parsing, built-in error correction protocols, etc. that's one of the good things about a CPU design. you *CAN* do those things "offline" and get better performance. there is no penalty (except cost) for having the CPU and not really needing it for offline processing. >>an intel SBC547, which is a multibus I card with and 80186, 4 zilog SCCs, and > >Oh, and since I'm nuts, I guess I get to call anyone who programs an 80186 in >assembly nuts. assembly is the only way to program an '86 family CPU correctly - the compilers i've met up with get too bogged down with bookkeeping to do a decent job. the '547 board was mostly PL/M (which has the best code generator i've seen other than microsoft C) and only the 1ms UART poll interrupt handler was done in assembler. i think this one should be assembler all the way. >>anyone have any comments? > >Yes. I like the idea of a timer interrupt for handling this if you don't have >DMA. The real problem with that is when you only have one CPU to handle the >interrupts, the timer is more overhead than needed when the ports _aren't_ >very active. yes - that's true (more overhead when there's nothing to do). but that's no problem, since the board's purpose in life is to handle serial ports, and nothing else. as i said before, it's a GOOD thing to have the board busier polling ports since it'll naturally tend to send things to the host in bigger bunches. >Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." > {decvax|att}! -- Robin Williams >UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron > {uunet|ncoast}!marque! --Scotty
scotty@ziggy.UUCP (Scott Drysdale) (01/12/89)
In article <7161@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: >In article <149@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes: >>In article <3256@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >[...] >>>will probably need a precision clock and internal specific intelligence >>>for MIDI -- sort of like a multiport version of the Roland MPU-401. The >>>trouble is, too, it's more expensive plus the programming model is totally >>>different. > >>that's a good point about midi timing. it would be relatively easy to add >>a mode to the board which caused it to recognize blobs of midi stuff and >>append a timestamp to them. > >That still leaves the problem that the programming model is different. >More serial ports for MIDI won't do much good if no programs support >them. And no programs will support them if every serial port behaves >differently. yes - programming models can be a pain. i just HATE it when applications writers try to use systems code :)... you mention the MPU401 - perhaps a version of the RAMware (uploaded to the serial board from the host) could be done which would emulate a gaggle of MPU401's and look to the application like a serial.device with an mpu401 hanging off the end on each unit. i'm not familiar with the mpu401 details, but i'm aware that it's a popular unit for ibm pc's and stuff. >I would really like to see some of this hidden by the device driver. If perhaps a midi.device driver and a serial.device driver could be written, which upload different versions of the RAMware to the board and behave differently in the amiga. of course, this means creating a new "standard" programming interface (ie, it's not quite the same as looking like a serial.device+MPU401 as above). it'd have to be damn good before anyone considered supporting it in a commercial product, and i don't have enough midi experience to competently generate a spec for it. the MPU401 emulation technique would probably be more universally accepted. >-Dan Riley (dsr@lns61.tn.cornell.edu, cornell!batcomputer!riley) >-Wilson Lab, Cornell U. --Scotty
aaron@madnix.UUCP (Aaron Avery) (01/13/89)
In article <150@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes: >with much greater throughput. i prefer performance over inexpensiveness. >how well would the interrupt or polling scheme using only the 68000 work when >you add several of these boards to the machine with 8 ports on each board? I agree wholeheartedly with you on the performance over inexpensiveness issue, but you and I are not the entire Amiga community. We also had the price vs. versatility issue to contend with. Since we were designing the Twin-X multi-purpose I/O board, we decided to implement our serial hardware as iSBX modules, which leads to great versatility. You can have 2, 4, 6, or 8 serial ports on one board, with varying costs to match. You could also have 4 serial ports in one module position, and IEEE-488 (or any of hundreds of I/O functions, for that matter) in the other. When you start to add more and more active serial ports, of course system performance will be degraded. With no processor or DMA support on the serial board, the main CPU will probably spend most of its serial-support time handling the interrupts. The next step up is an on-board processor. With this configuration, the host CPU spends most of its serial-support time copying the data from dual-ported RAM into its main memory. This operation is quite efficient compared to interrupt handling. What I feel is the highest throughput configuration, barring protocol-specific support on a processor-equipped board, is DMA support. With this configuration, the host CPU only has to handle the interrupts, which only happen after complete block requests are completed. These take up just as much host CPU overhead as those required for the on-board CPU method. However, the RAM- copying step is eliminated from the host's responsibility, and occurs much faster than the host could do it anyway. >yeah, DMA is cool - but DMA on the amiga has it's little problems. i think >a DMA design without it's own CPU would be as costly as the CPU on board >approach and would require more overhead from the host CPU than the CPU on >board method. Yes, DMA on the amiga has its little problems, and our board doesn't use DMA. But there would definitely NOT be more overhead from the host CPU. The difference there is that the DMA method places the data in its final destination with no code execution on the host CPU. With the dual-ported RAM method, the host CPU must move the data to its destination itself, which is far less efficient than the DMA would be. >that's one of the good things about a CPU design. you *CAN* do those things >"offline" and get better performance. there is no penalty (except cost) for >having the CPU and not really needing it for offline processing. True. And there's that cost thing again! >>Oh, and since I'm nuts, I guess I get to call anyone who programs an 80186 in >>assembly nuts. >assembly is the only way to program an '86 family CPU correctly - the compilers I was not knocking anyone for programming the '86 family in assembly vs. doing so in another language. I was bashing people for programming the '86 family in assembly vs. programming other CPU families in assembly! It's a joke, son!-) -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." -- Robin Williams UUCP: {harvard|rutgers|ucbvax}!uwvax!nicmad!madnix!aaron ARPA: madnix!aaron@cs.wisc.edu
scotty@ziggy.UUCP (Scott Drysdale) (01/14/89)
In article <385@madnix.UUCP> aaron@madnix.UUCP (Aaron Avery) writes: >In article <150@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes: [...cost/performance mutterings deleted...] >support on a processor-equipped board, is DMA support. With this configuration, >the host CPU only has to handle the interrupts, which only happen after >complete block requests are completed. These take up just as much host CPU >overhead as those required for the on-board CPU method. However, the RAM- >copying step is eliminated from the host's responsibility, and occurs much >faster than the host could do it anyway. > >>yeah, DMA is cool - but DMA on the amiga has it's little problems. i think >>a DMA design without it's own CPU would be as costly as the CPU on board >>approach and would require more overhead from the host CPU than the CPU on >>board method. i still think you're getting into more overhead with DMA vs. onboard CPU. obviously, doing a write from DMA to serial port would be deliciously efficient - but input's another story. how are you going to have the DMA controller stop waiting for bytes from the UART and inform the host that the transfer is complete without periodically polling the DMA to see if anything came in, or adding timers on the serial board to generate interrupts if no bytes have arrived after a certain (programmable) delay? applications for serial ports vary widely in their input rates, such as a user sitting at a keyboard (one byte bursts), a mouse or other low volume instrument (small bursts, say less than 50 bytes) and big bursts (like downloading data from another computer or packet network). though i suppose you could have the host software dynamically adjust delays depending on how busy things get. i guess it'd work out ok, but... a system i'm doing at work uses DMA to/from a UART (it's a communications tester) and must poll the receive and transmit DMA quite frequently to make sure no overflow occurs. the maximum rate we've been able to transmit/receive at using this technique (with the other tasks in the system disabled) is around 70Kbytes/second, using an 8Mhz 80186 (see, that's where the 186 part of my design comes from - THAR'S EMULATORS IN THEM THAR HILLS!), whereas the 8Mhz 186 in the intel 547 running my polling software can do an aggregate of 153.6Kbytes/second (8 ports at 19.2K baud, all transmitting/receiving simultaneously. >>>Oh, and since I'm nuts, I guess I get to call anyone who programs an 80186 in >>>assembly nuts. >>assembly is the only way to program an '86 family CPU correctly - the compilers > >I was not knocking anyone for programming the '86 family in assembly vs. doing >so in another language. I was bashing people for programming the '86 family >in assembly vs. programming other CPU families in assembly! >It's a joke, son!-) the whole '86 family is a joke - but it can be fun to program the silly things. > >-- >Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." > -- Robin Williams >UUCP: {harvard|rutgers|ucbvax}!uwvax!nicmad!madnix!aaron >ARPA: madnix!aaron@cs.wisc.edu --Scotty
scotty@ziggy.UUCP (Scott Drysdale) (01/14/89)
oh, one more little thing about using DMA on serial ports - it gets tough to track errors, since they're not part of the data stream. the other problem with DMA is doing handshaking (either the hardware kind or XON/XOFF). if your UART does the proper hardware handshaking on it's own (the SCC has a mode to allow this) then that's not too bad, but you end up with a non-configurable hardware handshake. if you don't let the UART do the hardware handshake, you have to poll the silly UART for state changes, or add more interrupts to handle it. now that i think about it, XON/XOFF shouldn't be too awful in terms of the latency of receiving the XON/XOFF and reacting to it by pausing DMA, if the host gets the bytes relatively quickly (say, allow for 8 bytes of slop once a XOFF has arrived at the UART). --Scotty
aaron@madnix.UUCP (Aaron Avery) (01/15/89)
In article <154@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes: >controller stop waiting for bytes from the UART and inform the host that >the transfer is complete without periodically polling the DMA to see if >anything came in, or adding timers on the serial board to generate interrupts >if no bytes have arrived after a certain (programmable) delay? applications The Z8530 has DMA block transfer support built in. For single byte reads (perhaps the norm), you set the block length to 1, and the byte will be stuffed into main memory and you will get an interrupt from the SCC. When you set the block size to something greater than 1, you don't get an interrupt until the block transfer is completed. Why would you want to have the serial board ever generate interrupts if no bytes have arrived (except TBE)? You handle timeouts on the Amiga, as usual. Aaron -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." -- Robin Williams UUCP: {harvard|rutgers|ucbvax}!uwvax!nicmad!madnix!aaron ARPA: madnix!aaron@cs.wisc.edu
aaron@madnix.UUCP (Aaron Avery) (01/15/89)
In article <393@madnix.UUCP> aaron@madnix.UUCP (Aaron Avery) writes: >The Z8530 has DMA block transfer support built in. For single byte reads >(perhaps the norm), you set the block length to 1, and the byte will be >stuffed into main memory and you will get an interrupt from the SCC. When I wanted to add a bit to that last message -- sorry. This implementation will have terrific throughput for protocol-based transfers, but will have more host CPU overhead than an on-board processor approach for normal, single byte per request, communications. This can be overcome quite easily by adding FIFO buffers to the board, and a bit more DMA control logic. This brings the cost up closer to the on-board processor design, but should be both easier on the main processor (now that reads are buffered on-board), and have greater throughput. -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." -- Robin Williams UUCP: {harvard|rutgers|ucbvax}!uwvax!nicmad!madnix!aaron ARPA: madnix!aaron@cs.wisc.edu
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (01/16/89)
In article <399@madnix.UUCP> aaron@madnix.UUCP (Aaron Avery) writes: >.... This can be overcome quite >easily by adding FIFO buffers to the board, and a bit more DMA control logic. >This brings the cost up closer to the on-board processor design, but should >be both easier on the main processor ..., and have greater throughput. It's interesting that this discussion is recreating the design of the DH-11, an I/O controller used on the PDP-11 (and later on the VAX series). It was moderately tricky to program, but could easily sustain a data rate that the "replacement" DZ-11 could only dream about. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
Doug_B_Erdely@cup.portal.com (01/17/89)
Now the *REAL* question needs to be asked. Will a multi-serial board be out
from *ANY* of these developers?? Or will us A1000 owners be left behind?
- Doug -
Doug_B_Erdely@Portal.Cup.Comscotty@ziggy.UUCP (Scott Drysdale) (01/17/89)
In article <393@madnix.UUCP> aaron@madnix.UUCP (Aaron Avery) writes: >The Z8530 has DMA block transfer support built in. For single byte reads >(perhaps the norm), you set the block length to 1, and the byte will be >stuffed into main memory and you will get an interrupt from the SCC. When the 8530 does NOT support block DMA - it makes requests one byte at a time, just like it would when interrupting. any block length for DMA must be handled by the DMA controller or otherwise detected. it would seem that getting an interrupt in addition to having the byte arrive via DMA isn't any better than the interrupt driven method, anyways, except for transmitting if the DMA controller knows about block lengths. interrupts may be fine for a few ports (such as your twin-x thing) but for high speed (19.2K or higher) operation without glitches, running multiple ports, i think the board needs some brains of it's own. consider that many people have difficulty with the standard serial port at 9600 baud, which is interrupt driven. (yeah, i know, the internal serial port has zero recieve buffering - so maybe 9600 is safe). > >-- >Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." > -- Robin Williams >UUCP: {harvard|rutgers|ucbvax}!uwvax!nicmad!madnix!aaron >ARPA: madnix!aaron@cs.wisc.edu --Scotty
jms@antares.UUCP (Joe Smith) (01/17/89)
[I've changed the title and sent followups to comp.sys.amiga.tech] In article <154@ziggy.UUCP> scotty@ziggy.UUCP (Scott Drysdale) writes: > ... doing a write from DMA to serial port would be deliciously >efficient - but input's another story. how are you going to have the DMA >controller stop waiting for bytes from the UART and inform the host that >the transfer is complete without periodically polling the DMA to see if >anything came in, or adding timers on the serial board to generate interrupts >if no bytes have arrived after a certain (programmable) delay? > --Scotty One killer problem that I have come across is when the terminal at the other end demands immediate response to XON/XOFF. For instance: Lets say you have smooth-scrolling VT100 terminal running at 9600 baud. As the host tries to send a bunch of consecutive linefeeds, the VT100 will send a Control-S to the host, indicating that the host should stop sending. Some older terminals will lose data if the host sends more than 3 characters after the terminal sends XOFF. Here is where having a FIFO on the input side of the UART can work against you. And it's even worse if the DMA on the output side of the UART cannot be quickly disabled. Very nasty to have 16 characters sent to the terminal after it says to stop. I don't know if they make any UARTs that can be programmed to recognize Control-S (with and/or without parity) and have the hardware disable the transmit flag automatically when the XOFF is detected. If hardware won't do it, then there is an argument for using multiple dedicated microprocessors for multiple serial ports. -- +----------------------------------------------------------------------------+ | TYMNET:JMS@F29 CA:"POPJ P," UUCP:{ames|pyramid}oliveb!tymix!antares!jms | | INTERNET:(Real Soon Now) Amiga Hacker PHONE:Joe Smith @ (408)922-6220 | +----------------------------------------------------------------------------+