blubaugh@ucqais.uc.edu (Dr. Blubaugh) (10/17/90)
How are multiple serial boards supposed to work?? I've got an
A3000 and the developer notes,AmigaMail,2.0 autodocs and all and I've
even built a multi-serial board with autoconfig and have a preliminary
device to handle the ports. I understand how the DOS level stuff is
going to work with additional ports but I just don't grasp how the
hardware board makes its extra units known to the system. I know from
the AmigaMail article that the port.handler,serial.device (why not
parallel.device too?) and preferences were rewritten to accomodate
multiple ports but what is supposed to happen when serial.device unit 4
is opened? Could someone explain how exec decides what code, if any,
is really going to get control. This surely has been worked out since
C= has an 8 port card ready to sell.
Is the board supposed to add its own serial.device to the exec list
of devices and hope that the first (C=) device looks for it to pass
control when it isn't their unit, or is there a special call
Hi_I_am_adding_units_to_this_exec_device that isn't documented yet. DXB132@psuvm.psu.edu (10/18/90)
It's much simpler than that. To use your extra ports, programs call OpenDevice with the name of YOUR driver (different from serial.device). The meaning of the unit number is defined by your driver. Most programs these days let the user specify the driver name and unit number to play with. If not, it's fairly easy to write a program to patch OpenDevice and pop up a window. -- Dan Babcock
blubaugh@ucqais.uc.edu (pri=2 Dwight Blubaugh) (10/18/90)
I recently posted a query regarding multiple serial ports and .. In <90290.160433DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >It's much simpler than that. To use your extra ports, programs call OpenDevice >with the name of YOUR driver (different from serial.device). The meaning of the >unit number is defined by your driver. Most programs these days let the user >specify the driver name and unit number to play with. If not, it's fairly easy >to write a program to patch OpenDevice and pop up a window. But Everything that Commodore has said is that 2.0 will solve the multiple-port problem. Every reply so far leads me to believe that we are no better off than the solution for 1.3 (which is what you just restated.) Besides, I can't see why Bryce would be so emphatic in the AmigaMail article and then C= just lets it drop. As I understood it the following mechanism was to be in effect. DOS serial.device Hardware port ser: Unit # ser1: 0 Default port, redirectable to any other real port. ser2: 1 Builtin serial port on Amiga ser3: 2 First port on first AutoConfig'd serial card ser4: 3 Second port " " " ... ... ..... serx: n First port on next AutoConfig'd serial card serx+1: n+1 Second port " " " What wasn't stated was how the actual code to handle the various ports got control from the new serial.device or how DOS was to get at anything that didn't belong to serial.device. There is a new serial.device under 2.0 but maybe that was nothing more than a maintainence release. Other E-mail replies has stated that C= has a complete replacement serial.device with their 8 port card :-( Could someone from Commodore enlighten me? >-- Dan Babcock Dwight Blubaugh Ph.D. UUCP: {decuac,mit-eddie,phri,pyramid}!uccba!ucqais!blubaugh.UUCP INTERNET: blubaugh@ucqais.uc.edu Anybody want to hire a Ph.D. chemist with a computer background????? -- Dwight Blubaugh Ph.D. UUCP: {decuac,mit-eddie,phri,pyramid}!uccba!ucqais!blubaugh.UUCP INTERNET: blubaugh@ucqais.uc.edu Anybody want to hire a Ph.D. chemist with a computer background?????
rwm@atronx.UUCP (Russell McOrmond) (10/19/90)
In a message posted on 18 Oct 90 15:17:54 GMT,
blubaugh@ucqais.uc.edu (pri=2 Dwight Blubaugh) wrote:
pDB> But Everything that Commodore has said is that 2.0 will solve the
pDB>multiple-port problem. Every reply so far leads me to believe that we
In order for it to solve it, it would have to have a device that called
another device, or would need to understand the hardware involved with each
serial device - There is no 'best' way to implement a serial device in hardware
- It really depends on what you want/need.
pDB>maintainence release. Other E-mail replies has stated that C= has a
pDB>complete replacement serial.device with their 8 port card :-(
I don't know if I'd WANT to have to rely on the Commodore Serial software -
There are a few functions missing that are required (IE: DTR control under
a shared Serial port situation (VERY common)).
So far I've found the ASDG serial device to be the best implementation,
which is why I bought their Duel-Serial board (IE: I don't use the internal
serial port).
I still, for the life of me, can't undestand any reason for Commodore,
Supra, and so many other companies to not support a simple thing like DTR
control. They end up forcing us to always go to the hardware directly which
is always a Bad idea - The FACT is that 'closing and re-opening' DOES NOT WORK!
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@atronx.UUCP {fts1,alzabo}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109blubaugh@ucqais.uc.edu (Dr. Blubaugh) (10/23/90)
In <52508.656318355@atronx.UUCP> rwm@atronx.UUCP (Russell McOrmond) writes: >In a message posted on 18 Oct 90 15:17:54 GMT, >blubaugh@ucqais.uc.edu (pri=2 Dwight Blubaugh) wrote: >pDB> But Everything that Commodore has said is that 2.0 will solve the >pDB>multiple-port problem. Every reply so far leads me to believe that we Russel responds with... >In order for it to solve it, it would have to have a device that called >another device, or would need to understand the hardware involved with each >serial device - There is no 'best' way to implement a serial device in hardware >- It really depends on what you want/need. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ since you asked.... I'd like the ability to drop in a serial card and have the system automagically know what it is and how to talk to it. This means that the card should really have all of its own code on board or sufficiently identify itself to the system that binddrivers can finish getting the resident portion of the code going. I then want DOS to know that additional serial/parallel devices are out there and have a sensible naming sequence imposed. I'd rather not have to build a mountlist or worry about the slot that a card exists in. When I access the serial.device asking for a particular unit, I want EXEC or a serial.device shell to figure out and direct all subsequent device/unit IO to the relevent resident code. We will always have the direct hardware people ( i.e. populous ) and that is their and our loss. I just think its ridiculous that IBM people can add multi-port cards and most all of their software can find the ports. With AutoConfig(TM), Amiga solved a major IO address problem and put us onto the road to easy to add hardware. I just wish I had more serial and parallel ports that are software accessable thru similar mechanisms that exist now ( e.g. SER2: , serial.device unit 2 ) >I don't know if I'd WANT to have to rely on the Commodore Serial software - >There are a few functions missing that are required (IE: DTR control under >a shared Serial port situation (VERY common)). I've heard about that one. > So far I've found the ASDG serial device to be the best implementation, >which is why I bought their Duel-Serial board (IE: I don't use the internal ^^^^ dual, although dueling ports might be funny. > I still, for the life of me, can't undestand any reason for Commodore, >Supra, and so many other companies to not support a simple thing like DTR >control. They end up forcing us to always go to the hardware directly which >is always a Bad idea - The FACT is that 'closing and re-opening' DOES NOT WORK! Is this something that is bigger than Commodore? Should the Amiga Software Developers be addressing this instead?? If third parties could agree upon a mechanism can we be sure that Commodore won't take a NIH (not invented here) approach much as they did with ARP?? > Russell McOrmond rwm@atronx.UUCP {fts1,alzabo}!atronx!rwm > FidoNet 1:163/109 Net Support: (613) 230-2282 > Amiga-Fidonet Support 1:1/109 -- Dwight Blubaugh Ph.D. UUCP: {decuac,mit-eddie,phri,pyramid}!uccba!ucqais!blubaugh.UUCP INTERNET: blubaugh@ucqais.uc.edu Anybody want to hire a Ph.D. chemist with a computer background?????
peter@sugar.hackercorp.com (Peter da Silva) (10/23/90)
In article <2521@ucqais.uc.edu> blubaugh@ucqais.uc.edu (Dr. Blubaugh) writes: > mountlist or worry about the slot that a card exists in. When I access > the serial.device asking for a particular unit, I want EXEC or a > serial.device shell to figure out and direct all subsequent device/unit > IO to the relevent resident code. No you don't. You want to specify a device name and port number, just like you do for the regular serial.device. This is NOT a commodore problem... it's the fault of the folks writing programs that talk to the serial port. > I just wish I had more serial > and parallel ports that are software accessable thru similar mechanisms > that exist now ( e.g. SER2: , serial.device unit 2 ) Aren't they? If any manufacturer's product isn't available as xxxx.device unit <N> then they should be shot. > Software Developers be addressing this instead?? If third parties could > agree upon a mechanism can we be sure that Commodore won't take a NIH > (not invented here) approach much as they did with ARP?? I don't know about Commodore, but I refuse to use ARP because it violates all sorts of interface standards Commodore had set out (mainly, wildcards... but I installed it and then had to keep backing out because the ARP versions of commands broke scripts). If ARP took an NIH approach to Commodore, is it any wonder Commodore reciprocated? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
LDSHANER@MTUS5.BITNET (Leon D. Shaner) (10/24/90)
>I don't know about Commodore, but I refuse to use ARP because it violates >all sorts of interface standards Commodore had set out (mainly, wildcards... >but I installed it and then had to keep backing out because the ARP versions >of commands broke scripts). If ARP took an NIH approach to Commodore, is it >any wonder Commodore reciprocated? AMEN!.... I wish more people thought like you, Peter... I walk into a friends room and try to use his machine and so many things do not work as specified by CBM, I just hate ARP commands... If they had just re-written the commands to be more efficient, but still support the exact command syntax that CBM uses on the standard commands, it would have been a more useful replacement project... I can live with the wildcard changes because they are somewhat consistent, even though I prefer the CBM version... I don't mind having programs that use the arp.libarary for things like file requestors and such, but I hope these go away with the advent of 2.0's req.library... +--------------------------------+-----------------------------------+ | LEON D. SHANER <LDSHANER@MTUS5> :BBS: AMIGA BITSWAP CENTRAL DISPATCH: | EE UNDER GRAD. : (906)482-8248 DIALOG PRO! BETA : | MICHIGAN TECHNOLOGICAL UNIVERSITY : FREE! -24 HOURS -80 MB -2 LINES!: +------------------------------------+-----------------------------------+
rwm@atronx.UUCP (Russell McOrmond) (10/24/90)
In a message posted on 22 Oct 90 18:24:49 GMT,
blubaugh@ucqais.uc.edu (Dr. Blubaugh) wrote:
DB> I'd like the ability to drop in a serial card and have the system
DB>automagically know what it is and how to talk to it. This means that
ASDG tried with their ReDirector - If you opened 'Serial.Device', it
would actually pop up a requestor when you did the Open (IE:Only when
you FIRST run whatever program) and it would then use whatever device the
user had selected after that point. Those authors that allowed for Any
device to be used (IE: About everything that I use ;-) would just use
CBMSER.device or SIOSBX.device (units 0 and 1).
Now, what would have been interesting for them to have done is have:
Unit 0: Eithor ask the question, or get the answer from some preferences
manager.
Unit 1: 'internal' serial (cbmser.device, unit 0)
Unit 2: siosbx.device Unit 0
Unit 3: siosbx.device Unit 1
So, someone COULD write a shell that would allow you to set up a Preferences
to map Serial.device 'units' to device/unit combinations for the specific
software.
For this list to come up on AutoConfig, Commodore Themselves would obviously
have to set this up. The hardware Locations are already part of AutoConfig,
the Software for the specific Card need only have Softeware on it as well.
Since these are Devices, it's easier to have the user do a '1-time install' of
the specific software into the devs:, and then just have the user use
preferences to deal with the rest.
DB>getting the resident portion of the code going. I then want DOS to
DB>know that additional serial/parallel devices are out there and have a
Here's the problem, though. It's not DOS that needs to know about these
things, but the application. Right now a lot of software just has
'serial.device', unit 0 hardwired into the Binary. IF it allows you to change
units (Which is what you need to do in the BEST case), the program usually also
allowes you to change the device. So, no matter what the specific authors do,
this has to be standardized.
DB>mountlist or worry about the slot that a card exists in. When I access
??? Mountlists are only used for Handlers (IE: ser:) - Writing a SERx: that
would go through this preferences (x is the UNIT) would be trivial. This is
not where the software issues are.
DB>that is their and our loss. I just think its ridiculous that IBM people
DB>can add multi-port cards and most all of their software can find the
This is because they have a hardware standard, not a software one - They are
in a much worse position than we are at this point. They also STILL have to
have software SPECIFICALLY WRITTEN to allow multiple serial boards to work with
it - You can't just 'NewZap' the binary like a lot of us do now with Amiga
software (IE: NewZap references to 'serial.device' to 'supra.device' to use
the Supra CardModem)
DB> Is this something that is bigger than Commodore? Should the Amiga
DB>Software Developers be addressing this instead?? If third parties could
We're talking about 10 lines of code Total, something that I myself have done
many times. Commodore seems to refuse to do it on Religious grounds.
(IE: UNIX has this *BUG*, so AmigaDos needs it too ;-)
DB>agree upon a mechanism can we be sure that Commodore won't take a NIH
DB>(not invented here) approach much as they did with ARP??
Ahh, but we know what happened to ARP - I have a 3000 running 2.0 - I don't
miss arp - Once I get a replacement to RENAME, 2.0 will have EVERYTHING that
ARP did (And more...)
DB>Dwight Blubaugh Ph.D.
DB>UUCP: {decuac,mit-eddie,phri,pyramid}!uccba!ucqais!blubaugh.UUCP
DB>INTERNET: blubaugh@ucqais.uc.edu
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@atronx.UUCP {fts1,alzabo}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109blubaugh@ucqais.uc.edu (Dr. Blubaugh) (10/24/90)
In <52902.656747372@atronx.UUCP> rwm@atronx.UUCP (Russell McOrmond) writes: >In a message posted on 22 Oct 90 18:24:49 GMT, >blubaugh@ucqais.uc.edu (Dr. Blubaugh) wrote: >DB> I'd like the ability to drop in a serial card and have the system >DB>automagically know what it is and how to talk to it. This means that > ASDG tried with their ReDirector - If you opened 'Serial.Device', it This is a third party solution to the problem but it is not the Commodore approved solution. For obvious reasons I'm sure ASDG's ReDirector doesn't work with Checkpoint Technologies' multiserial card. We need a solution from Commodore that is available to all hardware developers. >So, someone COULD write a shell that would allow you to set up a Preferences >to map Serial.device 'units' to device/unit combinations for the specific >software. But this can't be done with any combination of serial cards available. > For this list to come up on AutoConfig, Commodore Themselves would obviously >have to set this up. The hardware Locations are already part of AutoConfig, My point exactly. Commodore needs to develop a method for third party vendors to make their hardware become part of the system. Adding extra serial ports means more units appear in the serial.device. Adding more parallel ports means more units appear in the parallel.device. Also some of these ports might have printers attached so C= might as well expand the printer.device to allow someone to have a laserprinter on par1: (as prt1:) and a Paintjet on ser4: (as prt2:) >Here's the problem, though. It's not DOS that needs to know about these >things, but the application. Right now a lot of software just has But DOS does need to know. I want to redirect output from a CLI to the third serial port. You can't directly send IO to a device/unit from the CLI. >DB> I just think its ridiculous that IBM people >DB>can add multi-port cards and most all of their software can find the >This is because they have a hardware standard, not a software one - They are >in a much worse position than we are at this point. They also STILL have to >have software SPECIFICALLY WRITTEN to allow multiple serial boards to work with >it - You can't just 'NewZap' the binary like a lot of us do now with Amiga >software (IE: NewZap references to 'serial.device' to 'supra.device' to use >the Supra CardModem) I know that the IBM had specific addresses for extra ports, but my point is that MS-DOS does understand about LPT2: and COM3: when these multiport cards are added. I don't agree that we are in any better shape. You mention the problem yourself. We have to NEWZAP programs to use devices other than serial.device and other programs have added the ability to talk out through any device when actually it would make more sense to use other units of the serial.device. I had assumed that the AmigaMail article by Bryce Nesbit (published over a year ago) was telling us about a method that Commodore was currently developing for 2.0. Alas, it seems that this was preliminary design specs that didn't make it into 2.0. I take it that NEWZAPing binaries and writing code to handle user settable device name and unit is the APPROVED method until further notice. -- Dwight Blubaugh Ph.D. UUCP: {decuac,mit-eddie,phri,pyramid}!uccba!ucqais!blubaugh.UUCP INTERNET: blubaugh@ucqais.uc.edu Anybody want to hire a Ph.D. chemist with a computer background?????
papa@pollux.usc.edu (Marco Papa) (10/25/90)
In article <52902.656747372@atronx.UUCP> rwm@atronx.UUCP (Russell McOrmond) writes: >In a message posted on 22 Oct 90 18:24:49 GMT, >blubaugh@ucqais.uc.edu (Dr. Blubaugh) wrote: >DB> I'd like the ability to drop in a serial card and have the system ... >DB>automagically know what it is and how to talk to it. This means that >DB>getting the resident portion of the code going. I then want DOS to >DB>know that additional serial/parallel devices are out there and have a >Here's the problem, though. It's not DOS that needs to know about these >things, but the application. Right now a lot of software just has >'serial.device', unit 0 hardwired into the Binary. IF it allows you to change >units (Which is what you need to do in the BEST case), the program usually also >allowes you to change the device. So, no matter what the specific authors do, >this has to be standardized. This HAS been standardized. Commodore recommended application writers one of three methods (which are not mutually exclusive): 1. give a switch from the CLI, as in: run atalk3 SERIAL siosbx.device UNIT 1 2. select the device from the ToolType, as in: SERIAL=siosbx.device UNIT=1 3. Allow "dynamic" selection from a menu item A-Talk III implemented 1. and 2. since Jan. 1989. Even pd programs now support at least one of the above. It's been almost two years simce the recommendations were published, so if a comm program, commercial or not, doesn't support them, claiming it's Commodore fault, he's telling you a lie. -- Marco -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (10/25/90)
In article <90296.130035LDSHANER@MTUS5.BITNET> LDSHANER@MTUS5.BITNET (Leon D. Shaner) writes:
AMEN!.... I wish more people thought like you, Peter... I walk into a
friends room and try to use his machine and so many things do not work as
specified by CBM, I just hate ARP commands... If they had just re-written
the commands to be more efficient, but still support the exact command
syntax that CBM uses on the standard commands, it would have been a more
useful replacement project...
Yeah, I had that problem. It is possible to add to an interface and
not break things; ARP sure didn't do that, though. I've got enough
room to install them should someone/something show up who wants to use
them, but I'm not in that set.
In fact, I leave the standard CBM environment in place, and put all my
private stuff elsewhere. This means that 1) I can get back to standard
CBM easily, and 2) there's very little that breaks if I re-install the
CBM stuff from scratch. If I could convince links to work, I'd even
stop that, so all that has to happen is to recreate those few links
after a new install.
<mike
--smp@myamiga.UUCP (Steve Palm) (10/26/90)
In reference to <52902.656747372@atronx.UUCP>, written by Russel McOrmond.
RM> We're talking about 10 lines of code Total, something that I myself have
RM> done many times. Commodore seems to refuse to do it on Religious grounds.
I assume you were referring to the dropping of DTR signal?
What would the odds be of getting ahold of the sources for the serial.device
and actually writing this in? I agree with you that it NEEDS to be in there,
because the open-close gig does NOTHING if someone else had the serial port
opened.
Suppose you had a few tasks up and running. One that was watching for dialins
on the serial port, and one that was calling out. The one calling out
wouldn't adversely affect the one waiting for calls by messing around with the
DTR, but the one waiting for calls would stop the dialout program from
dropping the DTR using open-close techniques.
RM> (IE: UNIX has this *BUG*, so AmigaDos needs it too ;-)
It's not a bug, it's a feature! =^)
--
/// AMIGA: | Steve Palm, Sysop of FidoNet node 1:11/16
/// FOR THE | UUCP: {gatech,ames,rutgers}!ncar!asuvax!stjhmc!myamiga!smp
\\\/// CREATIVE | INTERNET: [not yet available]
\XX/ MIND |_________________________________________________________ peter@sugar.hackercorp.com (Peter da Silva) (10/27/90)
In article <77.2727B691@myamiga.UUCP> smp@myamiga.UUCP (Steve Palm) writes: >Suppose you had a few tasks up and running. One that was watching for dialins >on the serial port, and one that was calling out. The one calling out >wouldn't adversely affect the one waiting for calls by messing around with the >DTR, but the one waiting for calls would stop the dialout program from >dropping the DTR using open-close techniques. Would Matt Dillon please speak up and explain just how he solves this problem in his getty program? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dbk@phx.mcd.mot.com (Dave Kinzer) (10/30/90)
>In article <77.2727B691@myamiga.UUCP> smp@myamiga.UUCP (Steve Palm) writes: >>Suppose you had a few tasks up and running. One that was watching for dialins >>on the serial port, and one that was calling out. The one calling out >>wouldn't adversely affect the one waiting for calls by messing around with the >>DTR, but the one waiting for calls would stop the dialout program from >>dropping the DTR using open-close techniques. > In article <6910@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Would Matt Dillon please speak up and explain just how he solves this problem >in his getty program? I'm not Matt, nor play on on TV, but... The proper way: The dialin (monitor) program periodically wakes up, allocates the serial device for exclusive use (if refused, port is busy with dialout program), and asks the state of the DTR line. If busy or DTR inactive, go back to sleep otherwise proceed with the dialin program. The less proper but more CPU efficient method: The dialin program periodically wakes up and looks at the serial port hardware directly. If the DTR line has gone from inactive to active since the last time it woke up, try to allocate the serial device for exclusive use. If no change in DTR state or refused the serial device, go back to sleep, otherwise proceed with the dialin program. Example source code for this method was written by myself and available on a Fish disk somewhere around disk 250. * * * Imminent use of deathnet predicted. * * * // Dave Kinzer (602)897-3085 asuvax!mcdphx!teroach!dbk Opinions are mine. \X/
smp@myamiga.UUCP (Steve Palm) (11/01/90)
In article <13918@mcdphx.phx.mcd.mot.com>, teroach writes:
DK> The proper way:
DK>
DK> The dialin (monitor) program periodically wakes up, allocates the
DK> serial device for exclusive use (if refused, port is busy with dialout
DK> program), and asks the state of the DTR line. If busy or DTR inactive,
DK> go back to sleep otherwise proceed with the dialin program.
In my opinion, that is not proper. First of all, the program waiting for the
incoming calls should ALWAYS be running. The dialout program would only come
up as needed, if ever. Secondly, these two programs are not related, so they
should not be thought of as being able to pass information to each other.
The dialout program should have a flag asking whether or not you wish to muck
around with the DTR. If you say YES and have other programs running that
would be adversely affected by this, you are responsible. I don't feel that
you should have to have exclusive access to the serial port to toggle DTR.
Nor do I think you should have to do a open/close on the device to achieve
this. It is utter nonsense to have to go to the hardware for this function.
These are my opinions, so you may very well (and probably will) disagree
with me.
--
/// AMIGA: | Steve Palm, Sysop of FidoNet node 1:11/16
/// FOR THE | UUCP: {gatech,ames,rutgers}!ncar!asuvax!stjhmc!myamiga!smp
\\\/// CREATIVE | INTERNET: [not yet available]
\XX/ MIND |_________________________________________________________