bryce@cbmvax.UUCP (Bryce Nesbitt) (02/03/89)
--------------------------------------------
-- Amiga Multiple Serial Ports: User View --
--------------------------------------------
Software
--------
The current version of the Amiga has only one serial port. Since many
devices can interface with a serial port, having more serial ports is an
obvious improvement.
New system software has been developed for the Amiga which will allow
plug in cards with extra serial ports to be used. A typical setup on a
four port machine might be:
Port 1 - Connected to a MIDI keyboard
Port 2 - connected to a modem
Port 3 - connected to a printer
Port 4 - connected to a home-control device
Extra serial ports will also allow applications such as a multiple line
bulletin board system (BBS) with several modems connected to a single
computer. Such a BBS could support simultaneous users.
Multiple serial ports are implemented in a way which is compatible with
existing software.
o Old applications that ask for the serial port will be given
the "default" port. Using the Preferences tool, the user will
be able to set the default to any valid port.
o New programs will provide a way for the user to select the serial
port to use. If the user selects the number "0" or the word
"default", the program will connect to the default port which is set
in Preferences. The built-in port is unit 1. Extra serial ports
are numbered from two upward.
o From BASIC and the CLI, ports may be directly accessed in the
same manner as works today:
SER: = the default port
SER1: = the built-in port
SER2: = the second port
SER3: = the third port
SER4: = the fifth port
Hardware
---------
In addition to the new software support, Commodore is developing a plug in
card with multiple serial ports. All Commodore multiple serial port cards
will have a simple installation procedure:
o Insert the serial card into a slot.
o Boot up with the normal Workbench disk or hard drive.
o Insert the disk that comes with each serial card.
o Double click on the "Install Drivers" icon.
o To remove a driver, double click on the "Remove Drivers" icon.
Any number of cards may be installed. Advanced users may install the
driver software manually instead of using the installation icon.
Commodore's design for matching ports on cards with unit numbers is simple.
Port number 1 is the serial port built into each Amiga. Higher port numbers
indicate extra serial ports the user has added with a plug in card.
The bottom plug on a card is given the lowest unit number.
---------------------------------------------------
--- Amiga Multiple Serial Ports: Device Driver ---
---------------------------------------------------
A Commodre support document will be available for people who wish to write
multiple serial port device drivers. The document is available by request
only. We may send updates to the document, and require the name and
address of a contact person.
To request the support document, send your name, address, telephone number
and a short description of your hardware to:
CATS
Commodore Business Machines
1200 West Wilson Drive
West Chester, PA 19380-4231
USA
------------------------------------------------------
--- Amiga Multiple Serial Ports: Programmer's View ---
------------------------------------------------------
If you are writing serial port applications for the Amiga, you can now
add support for multiple serial port cards. This is easy to do and
will give your program extra power.
On an Amiga with one serial port the code needed to open the serial port
looks like this:
error = OpenDevice("serial.device", 0, myIORequest, 0);
/*
* BYTE=OpenDevice(char *,ULONG,struct IORequest *,ULONG);
*
* "serial.device" = name of the device
* 0 = unit number (unused)
* myIORequest = a blank extended trackdisk IORequest
* 0 = flags (unused)
*/
To work with multiple serial ports, just one very simple addition is
required:
error = OpenDevice("serial.device", myUnit, myIORequest, 0);
/*
* BYTE=OpenDevice(char *,ULONG,struct IORequest *,ULONG);
*
* "serial.device" = name of the device
* myUnit = which unit to try and open
* myIORequest = a blank extended trackdisk IORequest
* 0 = flags (unused)
*/
Notice that the second parameter has changed. Under the old system, unit
number was always set to 0. Now the unit number is used to identify
which of the serial ports should be used. The unit assignments are:
Unit 0 = default port, settable from Preferences
Unit 1 = the built-in serial port
Unit 2 = the first extended unit
Unit n = last extended unit
System support for a multiple port serial card requires changes to some of
the system files on disk. These files have been changed:
devs:serial.device ;exec support
l:port-handler ;AmigaDOS support
Preferences ;default port selector buttons
User Interface
--------------
Your application must allow the user to set the unit number. There are
several ways to do this.
o Use the TOOLTYPES field of the icon. Each icon has a
TOOLTYPES field which you can fill in with UNIT=0.
The user can modify the number later if needed. You
could also go one more step, and add DEVICE=serial.device
to this field.
o Have an option that brings up a box with a "default" gadget
and a string gadget for typing in a number.
o Add a menu or submenu like this:
---------------
| |
| unit number |
| -----------
----------| default |
| 1 |
| 2 |
| 3 |
| 4 |
|* 5 |
| 6 |
| 7 |
| 8 |
-----------
There are two disadvantages to this method. First, you
cannot find out how many units are connected with the
current serial.device. Second, the number of ports
available could exceed the vertical size of a menu.
Future Design Issues
--------------------
Plans for the V1.4 serial.device include several sensible extensions to the
current command set. For example, the best way to read under the current
serial.device is:
o Send a CMD_QUERY to see how many bytes are in the buffer.
o If there are any bytes, get them ALL with a CMD_READ.
o Else post a CMD_READ for exactly one byte. When it returns,
loop back to step #1.
With the old serial.device, this was the only way to get acceptable
performance at high baud rates. With the new serial.device, one will be
able to set a bit to request all available bytes from the serial port
(up to the size of the user buffer). The request will be held by the
device until at least one byte is ready.
The OpenDevice() call does not support a version number check at present.
In most cases there is no need to check the version number since the new
serial device is backward compatible. However, if you do need to find the
version number of the serial device, you should first open the device and
then look at the LIB_VERSION word in the device base. Versions 36 and higher
support multiple ports. Versions 35 and lower ignore the unit number field.
The Amiga's built-in serial port can generate any baud rate in the range
108 to 1,000,000 baud. However, off-the-shelf serial chips usually only
support the standard rates such as:
110 600 9600
150 1200 19200
300 2400 38400
Also, standard serial chips usually do not support the MIDI baud rate (31250).
Since most multiple serial port cards will be using standard serial chips,
the extra ports will not support all the different baud rates that the
built-in serial port does. There is no way for a serial.device client to
find out the capabilities of a specific serial unit at present.
|\_/| . ACK!, NAK!, EOT!, SOH!
{o O} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
--
|\_/| . ACK!, NAK!, EOT!, SOH!
{O o} . Bryce Nesbitt
(") BIX: bnesbitt
U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce
Disclaimer: I'm not an official, and this is not an official opinion.papa@pollux.usc.edu (Marco Papa) (02/03/89)
I'm happy to report that A-Talk III Release 1.1 is fully compliant with the EuroDevCon "Multiple Serial Spec". New UNITs and DEVICES can be accessed from icons (TOOL and PROJECT, by setting DEVICE=<name> and UNIT=<nn> in the ToolType), and from the CLI with the following syntax: ATalk3 [FROM <name>] [DEVICE <name>] [UNIT <nn>] Until a "reliable" method to figure out how many ports are available is devised, we won't support "dynamic" selection of UNITs through menus. -- 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) (02/03/89)
Flame on... AAAAARGH! Don't do it! Don't do it! Please please please don't implement this system. It provides no extra capabilities and adds YET ANOTHER LEVEL OF NAMING. There's too much name/level confusion as it is... just make new programs specify a device name and number... Flame off... -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
hbo@nobbs.ucsb.edu (02/04/89)
In article <5877@cbmvax.UUCP>, bryce@cbmvax.UUCP (Bryce Nesbitt) writes... > >-------------------------------------------- >-- Amiga Multiple Serial Ports: User View -- >-------------------------------------------- > This was an interesting discussion of Commodore's plans to standardize access to extra serial ports on the Amiga. However, it leaves prospective purchasers of such hardware in something of a quandry. Should we wait for CBM's hardware to appear, and thus assure ourselves of compatibility with the standard, or should we go with a third party vendor like ASDG, whose ports are available now, but whose serial driver does not conform to the standard? Given that Commodore's customary lead times between "technology previews" and product deliveries are horrendously long, the question takes on extra poignancy. If CBM wants to impose a standard on the serial port add-on marketplace, then I think that's great. If they fail to get the word out to vendors like ASDG however, then they have an obligation to GET THEIR PRODUCT TO MARKET QUICKLY! I for one think that it would be preferable to allow the third party vendors to define the standard, as messy as that could turn out to be, than to have CBM attempt to do so long after others have delivered non-compliant products. -- Howard Owen, Computer Systems Manager internet: hbo@nobbs.ucsb.edu Physics Computer Services BITNET: HBO@SBITP.BITNET University of California, Santa Barbara HEPNET/SPAN: SBPHY::HBO "I am not a pay TV service!" 805-961-8366 (work)
papa@pollux.usc.edu (Marco Papa) (02/04/89)
In article <3382@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >Flame on... > >AAAAARGH! Don't do it! Don't do it! Please please please don't implement >this system. It provides no extra capabilities and adds YET ANOTHER LEVEL >OF NAMING. There's too much name/level confusion as it is... just make >new programs specify a device name and number... > >Flame off... I don't see what is the big deal. It looks just fine to me. If you don't want to use the name "serial.device" for your board you don't have to. Use the DEVICE keyword to define your own. That's how it is done with the ASDG card. If CBM wants to continue to use "serial.device" in their serial devices, I also don't have any problem with that. I like the idea of a "default" serial device, selectable from Preferences. And the use of SER:, SER1:, SER2:, etc... (and SIOSBX: or whatever ASDG will call their DOS device) seems perfectly reasonable to me. So my vote is a total YES on the new Multiple Serial Spec. I still wish that a standard way to write the serial port bits (in my proposed way, Perry's or any equivalnet one) be approved as soon as possible. -- 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) (02/05/89)
> In article <3382@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >Flame on... [ This new serial-device stuff is a kludge ] > >Flame off... In article <15154@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) doesn't see the problem with it... They want everyone's serial devices to become part of an all-singing all-dancing serial device, as far as programs are concerned. That is, Perry's siosbx.device (I think that's the name) would show up as ports 1-4 of serial.device. Unless they also have FooCom's 2-port board and it happens to autoconfigure first, in which case they become ports 3-7... -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
limonce@pilot.njin.net (Tom Limoncelli) (02/06/89)
In article <3382@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: [ this new serial-device stuff is a kludge ] In article <15154@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) doesn't see the problem with it... In article <3385@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > They want everyone's serial devices to become part of an all-singing > all-dancing serial device, as far as programs are concerned. That is, > Perry's siosbx.device (I think that's the name) would show up as ports > 1-4 of serial.device. Unless they also have FooCom's 2-port board and it > happens to autoconfigure first, in which case they become ports 3-7... > -- > Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. > ...texbell!sugar!peter, or peter@sugar.uu.net 'U` From my reading of the spec, it seems more like venders have two options, first of all, they can supply their own serial.device (with a different name of course) and have software get configured to look for that device and a particular device number. Fine. If you don't like the standard you can do it the "old" way and be perfectly conforming. The second method is to, yes, become part of the all-singing, all-dancing serial.device. You WOULD know which ports are going to be which software devices because it seems that Preferences will get expanded to allow you to map numbers to devices. That means that I can set up: 0 -- built-in serial port (to assure compatability) 1 -- built-in serial port (unused but remapped) 2 -- JoeBlow serial device 3 3 -- ASDG serial device 1 4 -- JoeBlow serial device 1 5 -- ASDG serial device 2 This would be really nice as far as I can tell. In fact, it would permit me to set up my software and then have the OS do the mapping to the proper board/port depending on what *I* want, rather than the way that they autoconfig. If I pull out a board and replace it, my software is all configured to serial.device port 0 thru N and I just have to change preferences. In fact, I'd like device mapping to be done for almost every physical device. :-) Wow. I just realized how nice this will be. I can take a program that I'm using and move it to a different machine and not need to reconfigure it because I can do all that through preferences. In fact, I can reduce the mapping if I convince all my friends to put their modems on device 10-19, all their plotters on 20-29, all their serial printers on 30-39, etc. Hmmmmm...... -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Madison, NJ -- 201-408-5389 Standard ACM Regional Contest winner! See you at Disclaim the nationals in Louisville, KY on Feb 21-23! er.
perry@madnix.UUCP (Perry Kivolowitz) (02/06/89)
I have responded to this message in the comp.sys.amiga group. I feel
there is no reason to cross post here - I wish you wouldn't either.
--
Perry Kivolowitz, ASDG Inc.
ARPA: madnix!perry@cs.wisc.edu {uunet|ncoast}!marque!
UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry
CIS: 76004,1765 (what was that about ``giggling teenagers''?) papa@pollux.usc.edu (Marco Papa) (02/06/89)
||||ITn article <Feb.5.15.11.16.1989.14122@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >In ar.[^"-)U5{{ |[ this new serial-device stuff is a kludge ] | |In article <15154@oberon.USC.EDU|, papa@pollux.usc.edu (Marco Papa) doesn't |see the problem with it... |From my reading of the spec, it seems more like venders have two |options, first of all, they can supply their own serial.device (with a |different name of course) and have software get configured to look for |that device and a particular device number. Fine. If you don't like |the standard you can do it the "old" way and be perfectly conforming. Yep, if the "application" software is written in such a way as to allow USER selection of both DEVICE and UNIT, than one can have an application program work with BOTH a "conformant" serial.device or a "proprietary" whatever.device. -- 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] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
rsb@dukeac.UUCP (R. Scott Bartlett) (02/07/89)
In article <3382@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >Flame on... >AAAAARGH! Don't do it! Don't do it! Please please please don't implement >this system. It provides no extra capabilities and adds YET ANOTHER LEVEL >OF NAMING. There's too much name/level confusion as it is... just make >new programs specify a device name and number... >Flame off... >-- >Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. How does this new standard deal with multiple multi-ser cards? For instance: User has a multi-ser card that has all of its ports used: Builtin Port -> terminal w/ AUX: Multi Port 1 -> modem Multi Port 2 -> printer Multi Port 3 -> Midi Multi Port 4 -> You think of something Anyway, this user decides that he/she wants to start a multiport bbs while keeping the original modem port reserved for his own use. The user decides that adding another Multi Port card would be a great idea. Major questions pop up in my mind: 1) How do the two Multi-port cards deal with each other? (does autoconfig deal w/ non-memory cards?) 2) How does the serial.device deal with the two cards? 3) How are port numbers assigned between the two boards? (does it depend on which is closer to the CPU? ala autoconfig) 4) What happens when you use cards from different manufacturers? After reading the EuroDevCon paper on multi-ser ports, I am just left with too many questions. The proposed standard (or is it too late?) is good as a quick fix, but i think that it is just a bandaid fix that is bound to wear out sooner or later. (see above) The default ser-port is a good idea, but i think the rest should be left up to the individual board. ie, have individual devices for each card. This is going to complicate the installation process for the user, but lets face it, computers are complicated, and if users are going to want to do complicated things, they are going to have to do a little reading and learn a little about what is going on. The problem for C= and 3rd pary developers is making this literature available and readable. I know this is getting off the subject, but it is sort of related. Many Mac enthusiests (sp?) tout that their machine is easier to use than the Amiga. This is true to some extent. Macs come with a great piece of software called (if i remember correctly) "Introduction to the Macintosh." The Amiga however lacks a comparable piece of software. When you buy an Amiga, you are on your own. C/A needs to write a "Intro to the Amiga: A friend you can trust" program, and include it with ALL new machines and software upgrades. The manual can help the user with the hardware setup, and then direct the user to insert the Into disk and power up the machine. From then on, the user is introduced to the Amiga, starting with the mouse. Oh well, this has gotten entirely too long, and it has gotten off the subject. rsb -- All of the abuv speling mistakes are entintional!! ;-) -- rsb@dukeac.ac.duke.edu /// "Amigas do it with hardware."-- Me rutgers!mcnc!ecsvax!dukeac!rsb /// "Sycamore is open."-- Negativ Land I'm a HORSE, of course. \\\/// "I luv S&M!!!" "No geeks here!!" Disclaimer NOT included! \XX/ "This space for rent"