bryce@cbmvax.UUCP (Bryce Nesbitt) (06/01/88)
>I'm using the serial.device, and I need to know if transmission is stopped >due to having received XOFF. > > So I did the obvious: > > if( IOSTF_XOFFREAD & InSer->io_Status) { The problem is that those bit definitions refer to the HIGH ORDER BYTE of the io_Status WORD. This is a bug, and will be fixed. >#define IOSTB_XOFFREAD 4L >#define IOSTF_XOFFREAD (1L<<4) /* change to */ #define IOSTB_XOFFREAD (4+8)L #define IOSTF_XOFFREAD (1L << IOSTB_XOFFREAD) That will work. > So I started using: > > if( IOSTB_XOFFREAD==InSer->io_Status) NO!!!!!!!!!!!!!!! NO!!!!!!!!!!!!!!!! NO!!!!!!!!!!!!!!! NO!!!!!!!!!!!!!!!! NO!!!!!!!!!!!!!!! NO!!!!!!!!!!!!!!!! >If you reply my e-mail, Frank's address is ...uunet!mcvax!inria!geocub!anthes >rouaix@inria.inria.fr
papa@pollux.usc.edu (Marco Papa) (06/01/88)
In article <3898@cbmvax.UUCP> bryce@cbmvax.UUCP (Bryce Nesbitt) writes: ||I'm using the serial.device, and I need to know if transmission is stopped ||due to having received XOFF. || So I did the obvious: if( IOSTF_XOFFREAD & InSer-|io_Status) { | |The problem is that those bit definitions refer to the HIGH ORDER BYTE |of the io_Status WORD. This is a bug, and will be fixed. ^^^^^^^^ ||#define IOSTB_XOFFREAD 4L ||#define IOSTF_XOFFREAD (1L<<4) | |/* change to */ |#define IOSTB_XOFFREAD (4+8)L |#define IOSTF_XOFFREAD (1L << IOSTB_XOFFREAD) | |That will work. ^^^^^^^^^ Bryce, What do you mean? Can we assume that the above fix will always work, even in 1.4 and above? That is, is the fix just properly documenting the current situation? -- 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] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jason@ziebmef.uucp (Jason Gould) (06/11/88)
Hello. I am writing a program which opens the serial device while another
task has it open, and the task does not know about my intentions of using the
device while it also has the device. When I tried a test program out on a few
term programs, I found that the original task that had the device open can't
communicate with it unless it changes its COM parameters.
My question is this: Is there any way to make the serial device work with
the original task without changing the COM parameters, after my program closes
the device?
Any help would be greatly appreciated.
--
Jason Gould
jason@ziebmef.UUCP {uunet!mnetor!lsuc,utgpu}!ncrcan!ziebmef!jasonrjhlric@neabbs.UUCP (RICHARD SCHIFFELERS) (04/03/89)
I've got a question concerning the serial device.
1. Can anyone tell me if it's possible to set a baudrate outside
the normal range (110,300 etc.) and so yes, how.
2. What is the lowest possible baudrate of the serial device.
( I would like to use the Amiga for RTTY decoding, and
for this i need 50 and 75 baud ).
Richard.
// Date : Sunday 2-Apr-89
\\ // Richard Schiffelers
\X/ UUCP: ...!mcvax!telmail!neabbs!rjhlricbryce@cbmvax.UUCP (Bryce Nesbitt) (04/05/89)
In article <125574@neabbs.UUCP> rjhlric@neabbs.UUCP (RICHARD SCHIFFELERS) writes: |1. Can anyone tell me if it's possible to set a baudrate outside | the normal range (110,300 etc.) and so yes, how. Yes. Set a different number in your SETPARAMS Iorequest. You cannot make the selection from the preferences program. |2. What is the lowest possible baudrate of the serial device. | ( I would like to use the Amiga for RTTY decoding, and | for this i need 50 and 75 baud ). The hardware low-end is about 108 baud -- |\_/| . ACK!, NAK!, EOT!, SOH! {O o} . Bryce Nesbitt, Commodore-Amiga, Inc. (") BIX: bnesbitt U USENET: cbmvax!bryce@uunet.uu.NET -or- rutgers!cbmvax!bryce Lawyers: America's untapped export market.
ugkamins@sunybcs.uucp (John Kaminski) (04/09/89)
In article <125574@neabbs.UUCP> rjhlric@neabbs.UUCP (RICHARD SCHIFFELERS) writes: > >I've got a question concerning the serial device. > >1. Can anyone tell me if it's possible to set a baudrate outside > the normal range (110,300 etc.) and so yes, how. Use OpenDevice() (instead of Open("SER:",...) and Preferences if that indeed is what you are doing) and DoIO() with the command SDCMD_SETPARAMS and io_Baud set to any rate needed. Maximum is an incredible 292000 according to the dox. Of course, don't expect the Amiga to handle a continuous stream of characters at this rate, but the capability of "character at a time" is there. (reference: Amiga ROM Kernel Reference Manual: Libraries and Devices ~ p 390) > >2. What is the lowest possible baudrate of the serial device. I think you wanted "?" and not "." > ( I would like to use the Amiga for RTTY decoding, and > for this i need 50 and 75 baud ). > > Richard. > > > // Date : Sunday 2-Apr-89 > \\ // Richard Schiffelers > \X/ UUCP: ...!mcvax!telmail!neabbs!rjhlric Unfortunately, forget it. Minimum the hardware can handle is 112. The device will accept down to 110, but will be bumped up to 112.
cmcmanis%pepper@Sun.COM (Chuck McManis) (06/14/89)
Serial devices are one of those things that everyone and their avocado plant
seems to have an opinion on. My plant is no exception.
The sort of general question I raised to Commodore a year and a half ago when
various folks were looking intensely at this problem, was why do people care
what "device" the serial interface is using? The reason is and continues to
be, because SER: is broken and doesn't provide the needed capabilities of
a "proper" serial device. AUX: was supposed to fix that sort of.
Generally, there are two ways in which one might use a serial device. The
first way is as a server driven port. Meaning that the host computer controls
what goes out, and usually expects nothing, or very small things to come back
into it. This is the SER: model, and it works well for plotters and printers
and other serial devices. The second way in which these ports are used is as
interactive data streams. Either externally driven such as in a BBS application,
or internally driven in the case of a terminal emulator program. In both cases
there are two "peers" on either end of the connection, each generating
information and data in an unpredictable manner. This is what AUX: is supposed
to handle.
So the question arises, as it inevitably does, what about name spaces?
My idea was that with some minor modifications you could make a name
space "under" AUX: that looked just like a disk name space. Specifically,
you allow the handler to deal with locks and in those locks it stores
useful information about the device.
So how would that look to the user? Well maybe you could type
1> dir AUX:
asdg (dir)
amiga (dir)
foobar (dir)
And then
1> dir AUX:amiga
110 (dir)
300 (dir)
600 (dir)
...
19200 (dir)
And then
1> dir AUX:amiga/1200
7E1 7E2 7O1 7O2
7M1 7M2 7S1 7S2
8N1 8N2
And for connections to tymenet you might want to say
1> Assign MODEM: AUX:amiga/1200/8N1
Then tell your terminal emulator to open MODEM: and it would
do the right thing. Want to switch to 2400 baud? Call Examine()
on the Modem lock and find the baudrate number (mfgr/<baud>/options)
Try for a Lock on AUX:mfgr/2400/options and if it works then great.
Same goes for setting the option bits.
Now of course the directories here would be completely fabricated
by the name space agent for AUX: which is similar to the file system
handler for disks. If you could get an established a set of packets/device
commands for setting these parameters, and get manufacturer buy in. Then
it would be a fairly simple matter to "install" new serial ports, simply
drag the device into a special drawer (maybe Expansion/serial) Doing
assigns are still problematic at the workbench level. Read() and Write()
would work as expected, and the world would continue to be orthogonal.
Comments ?
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"mcr@julie.UUCP (Michael Richardson) (06/14/89)
In some article Chuck McManis writes: >what "device" the serial interface is using? The reason is and continues to I don't. >interactive data streams. Either externally driven such as in a BBS application, >or internally driven in the case of a terminal emulator program. In both cases >there are two "peers" on either end of the connection, each generating And generally VERY interested in whether there is a Carrier, (write and reads fail in a particular way if there isn't) --- AND also very interested in some sort of out of band transmission to the modem (which is really what you are talking about) i.e. with DTR low. [I've tried hitting the hardware directly to drop DTR in Welmat to hangup --- not all modems work well with "+++" and a bbs that needs the modem to recognise "+++" is doomed when a message like this appear "+++ATH0DT<some number in Australia>" -- sending to the modem after setting the bit (while Disabled()) is a guaranteed guru. I can't OpenDevice()/CloseDevice() --- I already open the serial.device twice --- once for read and once for write (the write packet already duped for doing other things) and I fully expect to be able to run under vt100 (or the other way around!) or launch dnet as a Fidonet WaZoo protocol --- SERF_SHARED is too usefull to give it up like that. I'm still hoping that ASDG will provide for DTR control --- otherwise- I'm trying to track down a source of prototyping boards...] >1> dir AUX: > asdg (dir) > amiga (dir) > foobar (dir) I'm game. >1> dir AUX:amiga/1200 > 7E1 7E2 7O1 7O2 > 7M1 7M2 7S1 7S2 > 8N1 8N2 And of course "dir AUX:amiga/1200/8n1/2317144" --- at this point it doesn't make sense not to provide complete, intelligent modem support. >And for connections to tymenet you might want to say >1> Assign MODEM: AUX:amiga/1200/8N1 Assign TYMENET: MODEM:5551212 >Then tell your terminal emulator to open MODEM: and it would open TYMENET: >commands for setting these parameters, and get manufacturer buy in. Then >it would be a fairly simple matter to "install" new serial ports, simply >drag the device into a special drawer (maybe Expansion/serial) Doing >assigns are still problematic at the workbench level. Read() and Write() >would work as expected, and the world would continue to be orthogonal. And you'd want to install your modem too. >Comments ? I like it, and I'd gladly do it, but I'd rather see more a more intelligent, less buggy serial device first. >--Chuck McManis -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10
peter@sugar.hackercorp.com (Peter da Silva) (06/20/89)
In article <0048.AA0048@julie>, mcr@julie.UUCP (Michael Richardson) writes: > And of course "dir AUX:amiga/1200/8n1/2317144" --- at this point > it doesn't make sense not to provide complete, intelligent modem > support. AAAAAAAAARRGH!!!!!! No. Please. No. Please. No. Please. Please. I'll be good. I'll tell you what. *you* design the interface, then I'll find a modem it won't work with. THIS IS THE WRONG PLACE TO PUT ASSUMPTIONS ABOUT WHAT THE SERIAL PORT IS CONNECTED TO. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
doug@xdos.UUCP (Doug Merritt) (06/21/89)
In article <3937@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <0048.AA0048@julie>, mcr@julie.UUCP (Michael Richardson) writes: >> And of course "dir AUX:amiga/1200/8n1/2317144" --- at this point > >AAAAAAAAARRGH!!!!!! > >I'll tell you what. *you* design the interface, then I'll find a modem it >won't work with. THIS IS THE WRONG PLACE TO PUT ASSUMPTIONS ABOUT WHAT THE >SERIAL PORT IS CONNECTED TO. Well, Michael's example does look a bit extreme. It's a different way of looking at things. I thought that "con:400/600/200/100/Title" was pretty bizarre, too. But it's not necessarily bad. The way to make Michael's example work is to have some kind of modem server task that the AUX device handler calls upon in order to get parameters like phone numbers to work right. In other words, it's really just a question of syntax. And although I'm still unsure whether I like it, I think we could make it work. I do agree with Peter that the AUX device handler itself should *NOT* make assumptions about the kind of modem it's talking to. Nor even whether or not it *is* talking to a modem (until someone tells it so). Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
aaron@madnix.UUCP (Aaron Avery) (06/21/89)
In article <0048.AA0048@julie> mcr@julie.UUCP (Michael Richardson) writes: > And generally VERY interested in whether there is a Carrier, (write and >reads fail in a particular way if there isn't) --- AND also very Actually, the serial.device fails dependent on DSR, and pretty much ignores CD. You can always find out CDs status via the QUERY command. >that. I'm still hoping that ASDG will provide for DTR control --- >otherwise- I'm trying to track down a source of prototyping boards...] Yes, ASDG provided an additional command which gives you control over the status of the output pins DTR and RTS. > And of course "dir AUX:amiga/1200/8n1/2317144" --- at this point >it doesn't make sense not to provide complete, intelligent modem >support. ASDG's SER: and AUX: type handlers provide this type of command-line parameter setting. Plus, there are defaults for each Mountlist entry above the preferences settings. They do not support some of the packets associated with 'dir', as it makes no sense under the current Commodore specification. -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." -- Robin Williams ARPA: madnix!aaron@cs.wisc.edu {uunet|ncoast}!marque! UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron
mcr@julie.UUCP (Michael Richardson) (06/24/89)
Aaron Avery said: >Actually, the serial.device fails dependent on DSR, and pretty much ignores >CD. You can always find out CDs status via the QUERY command. I knew about Query. I query every time I get a packet back. DSR interests me. I checked my modem manual, and yes, I can make "DSR is ON only when a carrier is detected from the remote modem." How do I send _commands_ to the modem. (It is easy, until I turn DSR control on.. I could do that when I dial, but then when I lose the carrier I'd have to reset the modem with DTR before I could send to the modem...) >Yes, ASDG provided an additional command which gives you control over the >status of the output pins DTR and RTS. Beautiful. Now where was that paycheck.. Hmm, next week I guess. >ASDG's SER: and AUX: type handlers provide this type of command-line >parameter setting. Plus, there are defaults for each Mountlist entry above Details? >the preferences settings. They do not support some of the packets associated >with 'dir', as it makes no sense under the current Commodore specification. I didn't expect that yet. :-) >Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." > -- Robin Williams -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10
aleks@well.UUCP (Brian J. Witt) (06/25/89)
In article <3937@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <0048.AA0048@julie>, mcr@julie.UUCP (Michael Richardson) writes: >> And of course "dir AUX:amiga/1200/8n1/2317144" --- at this point >> it doesn't make sense not to provide complete, intelligent modem >> support. > >AAAAAAAAARRGH!!!!!! > >I'll tell you what. *you* design the interface, then I'll find a modem it >won't work with. THIS IS THE WRONG PLACE TO PUT ASSUMPTIONS ABOUT WHAT THE >SERIAL PORT IS CONNECTED TO. >Peter "Have you hugged your wolf today" da Silva A clear and guiding light to solve the continuing modem worries might be.... MODEM.DEVICE !!!!!! (in lower case, of course) This way, you can talk to any modem (or networked modem server) you have somehow attached to your amiga. This new device would be a value-added server to (most likely) the serial.device. No, I haven't seen the 1.4 specs :-) The modem.device would provide "typical" modem services to its clients. Upon opening the modem.device, you inform it of a "physical layer" device to use for communications. If you're networked, this could actually be a socket driver (ie, DNET or sockets) that would move your data over to a modem server computer. If you have a modem on the ?parallel? port, just tell the modem device so. Another desired feature the modem.device would provide is: DROP DTR (or CMD_HANG_UP). Ohhh.... I feeel a light headedness coming on. For those who are truely amibition, see RS-366A spec. Here, EIA went and speced out a modem interface. Wasn't that sweet of them :-) Can you say ""Circuit CRQ - Call Request", "Circuit DLO - Data Line Occupied",? :-) :-) :-) :-) Why, this document even specs pins for sending dialcodes to the DCE (ie modem) unit. Lay your head back And let your hair fall all around Open [ "layers.library" ] This is the end of the innocence... --- Don Henley, mostly --- brian witt --- USENET: well!aleks@ucbvax.berkeley.EDU
jonathan.forbes@canremote.uucp (JONATHAN FORBES) (12/21/89)
Is there any way I can get a program to send to the serial device and the console device at the same speed? The console is obviously much faster, and finishes displaying its text long before the serial device does. I tried making them print only 10 characters at a time, but for some reason, this makes no difference. It probably has something to do with the serial device's buffer. At any rate, I'd like to be able to send text like programs like BBS-PC! do (but *without* accessing the hardware directly.) Help would greatly be appreciated. --- * Via ProDoor 3.1R
valentin@cbmvax.commodore.com (Valentin Pepelea) (01/04/90)
In article <89122504041593@masnet.uucp> jonathan.forbes@canremote.uucp (JONATHAN FORBES) writes: >Is there any way I can get a program to send to the serial device and >the console device at the same speed? The console is obviously much >faster, and finishes displaying its text long before the serial device >does. > >I tried making them print only 10 characters at a time, but for some >reason, this makes no difference. It probably has something to do with The sequence of calls to the I/O routines should look something like this: BeginIO(foo) /* 10 chars to serial.sevice */ BeginIO(bar) /* 10 chars to console.device */ WaitIO(foo) /* wait for the serial.device to finish */ WaitIO(bar) /* wait for the console.device to finish */ This way, the 10 characters are still spit out to the concole much faster than to the serial port, but a certain synchronisation is maintained. Perhaps the fault in your code was that you were using SendIO() without waiting for the completion of the IO request before issuing the next SendIO(). DoIO() automatically Wait()'s for the request to finish, but obviously the sequence DoIO(foo) DoIO(bar) is not as good as the one listed above. BeginIO() is in amiga.lib. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
Jim.Locker@afitamy.fidonet.org (Jim Locker) (03/03/90)
Here's a problem some of you might recognize and hopefully tell me what is
happening.
Back in the distant past I started writing a package. This package, fully
asynchronous and multitasking, eventually was to be used as a process control
package. To do this, I needed to write a serial port handler that talked to
serial.device. I did this. To test it, I connected two Amigas via a null
modem, and shipped messages back and forth, thus verifying that my
communications worked and my protocol was correct.
Time passed, and we got to now. My code was sufficiently mature, so I hooke
up to a piece of hardware that I really intend to control in the real world.
This box communicates over a serial port using 7-O-1. Welllll..... I did my
original testing at 8-N-1. No problem, just change the flags and come up as
7-O-1. Easy as pie.
Except... at 7-O-1, instead of every byte of my message being sent out the
serial port, every other byte is being sent out. Here is the relevant code:
char Dataout[100]
main()
(a bunch of setup code)
Write_Req->IOSer.io_Data = (APTR)Dataout;
Write_Req->io_SerFlags = SERF_XDISABLED|SERF_EOFMODE|SERF_PARTY_ODD|
SERF_PARTY_ON;
At the present, I am working around this problem by pushing my outgoing
message into every other byte of Dataout, and that seems to work reliably.
BUT...clearly something is wrong.
My question is this: What set of conditions would cause serial.device to send
every byte at 8-N-1, but every other byte at 7-O-1?
Jim Locker <puzzled but pushing on>
--
------------------------------------------------------------------------
AFIT Amiga Users BBS/UFGateway |Jim Locker - via FidoNet node 1:110/300
1:110/300 Dayton, Ohio |UUCP: uunet!dayvb!afitamy!Jim.Locker
(513)-252-7681 |ARPA: Jim.Locker@afitamy.fidonet.org
------------------------------------------------------------------------Jim.Locker@afitamy.fidonet.org (Jim Locker) (03/07/90)
About 4 days ago I posted a message about the serial.device, asking if anyone
knew under what conditions it would ship every character when using 8-N-1, but
only ship every other character at 7-O-1.
Well, I found the answer. It helps if you have a bad Paula chip in your
machine. Then you can get this flaky effect. Last night, while puzzling over
this problem, a tiny gleam of light filtered into my brain. I quickly
scrolled my package off onto a floppy and booted my other Amiga, loaded the
package, and watched it run. It ran correctly, shipping every character out
the serial port.
My thanks to those who responded to my query...I am happy to report that my
software problem was really a hardware problem. (Happy? It's gonna cost me
money! So why am I happy? At least I know what the problem is!!)
Jim Locker
--
----------------------------------------------------------------------------
AFIT Amiga Users BBS/UFGateway |Jim Locker - via FidoNet node 1:110/300
1:110/300 Dayton, Ohio |UUCP: afitamy!Jim.Locker
(513)-252-7681 |ARPA: Jim.Locker@afitamy.fidonet.org
----------------------------------------------------------------------------