new@udel.edu (Darren New) (01/12/90)
I understand that there are multi-port serial boards out there.
I also understand that the device-level interfaces are essentially
the same as serial.device (mod Open parameters). My question is this:
Do the current boards support 'AUX:' style devices? That is,
can I Open("AUX:1", MODE_???) and Open("AUX:2", MODE_???) and
read/write these (in a blocking way, of course)? (Or whatever the
device names may be.)
On a related question: When a user types a control-C, control-D,
control-E or control-F on the AUX: connection, does the device-reader
get Signal bits set? If so, exactly how does the device driver
determine which task gets its bit(s) set? Also, how does
CON: determine which Task gets the bits set?
(This is for a BBS, in case you wonder)
Thanks in advance! -- Darrenlphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/13/90)
In <14137@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) writes: >In article <7970@nigel.udel.EDU> new@udel.edu (Darren New) writes: >>I understand that there are multi-port serial boards out there. >>I also understand that the device-level interfaces are essentially >>the same as serial.device (mod Open parameters). My question is this: >>Do the current boards support 'AUX:' style devices? That is, >>can I Open("AUX:1", MODE_???) and Open("AUX:2", MODE_???) and >>read/write these (in a blocking way, of course)? (Or whatever the >>device names may be.) >> > Due to it's limited usefulness, we (Checkpoint Technologies) >decided not to include an AUX:-style handler with the Serial Solution >board, but we do supply a utility which can make one. The ZapPort >utility on the driver disk automatically patches executable programs to >use our serial driver. This works just fine on aux-handler as well, so >you can make a duplcicate for the Serial Solution card. While I am glad to see that the aux-handler can be patched, I am a little shocked that you see AUX: as having limited usefulness. Indeed, for some folks, it is far more useful than SER:, allowing as it does, an easy way to use a shell or an application normally run using stdin/stdout over a serial port. Does your ZapPort utility patch executables in a generic manner? The reason I ask is that the aux-handler I use is not the one supplied by CBM, but has been improved significantly. -larry -- "Cavett Emptor - Let the talk show host beware!" - Evan Marcus +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
ckp@grebyn.com (Checkpoint Technologies) (01/14/90)
In article <7970@nigel.udel.EDU> new@udel.edu (Darren New) writes: >I understand that there are multi-port serial boards out there. >I also understand that the device-level interfaces are essentially >the same as serial.device (mod Open parameters). My question is this: >Do the current boards support 'AUX:' style devices? That is, >can I Open("AUX:1", MODE_???) and Open("AUX:2", MODE_???) and >read/write these (in a blocking way, of course)? (Or whatever the >device names may be.) > Due to it's limited usefulness, we (Checkpoint Technologies) decided not to include an AUX:-style handler with the Serial Solution board, but we do supply a utility which can make one. The ZapPort utility on the driver disk automatically patches executable programs to use our serial driver. This works just fine on aux-handler as well, so you can make a duplcicate for the Serial Solution card.
cmcmanis@stpeter.Sun.COM (Chuck McManis) (01/16/90)
In article <14137@grebyn.com> (Checkpoint Technologies) writes: > Due to it's limited usefulness, we (Checkpoint Technologies) >decided not to include an AUX:-style handler with the Serial Solution >board, but we do supply a utility which can make one. The ZapPort >utility on the driver disk automatically patches executable programs to >use our serial driver. This works just fine on aux-handler as well, so >you can make a duplcicate for the Serial Solution card. AAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHH! This reminds me of CP/M-80 where theoretically "professional" software came with instructions that said "Patch the executable in the usual way to customize it to your system." I'm not sure who I think deserves the blame for such a travesty, CheckPoint for making an executable zapper or Commodore for not following through on addressing this problem. (multiple serial ports) The port handler isn't even in ROM for heaven sake so something certainly could have been done. God what non-technoweenie in their right mind would buy a product that encouraged them to damage the software they already own! --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
perry@madnix.UUCP (Perry Kivolowitz) (01/16/90)
>In <14137@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) writes: >>In article <7970@nigel.udel.EDU> new@udel.edu (Darren New) writes: >>>the same as serial.device (mod Open parameters). My question is this: >>>Do the current boards support 'AUX:' style devices? That is, >>>can I Open("AUX:1", MODE_???) and Open("AUX:2", MODE_???) and >>>read/write these (in a blocking way, of course)? (Or whatever the >>> >> Due to it's limited usefulness, we (Checkpoint Technologies) >>decided not to include an AUX:-style handler with the Serial Solution Due to its enormous usefulness to those who need it, we (ASDG) provide both a ser: and aux: clone with the Dual Serial Board. These handlers both support complete command line serial parameter specification, like so (using Darren's example): Open("Joey:9600" , MODE_OLDFILE) or just as easily Open("Joey:19200/8N1/32000" , MODE_OLDFILE) etc. We also support two levels of defaults for filling in the serial parameters which were not specified on the command line. pk -- Perry Kivolowitz, ASDG Inc. ``We look for things. Things that make us go.'' UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 PLINK: pk-asdg
peter@sugar.hackercorp.com (Peter da Silva) (01/16/90)
> Commodore for not following through on addressing this > problem. (multiple serial ports) The port handler isn't even in ROM > for heaven sake so something certainly could have been done. What should they have done? The serial port is in a documented name space. It's up to applications developers to provide a way of specifying the port number and device name to their program. Hardcoding ("serial.device",0) is as bad as a UNIX program hardcoding ("/dev/acu") or ("UNIX:0"). I've seen people go around and around on this, and I'm still missing the point. Devices have names. Are the names aesthetically displeasing or something? Whatever *new* scheme Commodore came up with would have no better chance of being supported by developers than the *old* scheme. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
ckp@grebyn.com (Checkpoint Technologies) (01/16/90)
In article <130261@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <14137@grebyn.com> (Checkpoint Technologies) writes: >>board, but we do supply a utility which can make one. The ZapPort >>utility on the driver disk automatically patches executable programs to > >God what non-technoweenie in their right mind would buy a product that >encouraged them to damage the software they already own! In fact we don't encourage people to zap their executables; ZapPort was rather a last minute addition. Instead we reccommend that a user use the NewPort utility; this leaves the executable untouched but creates a separate loader program which will load in the application and alter it in RAM. (It has the interesting side-benefit that your pointer is available more quickly after double-clicking the app in Workbench, which only has to load a small file rather than the whole application.) However, this will only work with WorkBench- or CLI-launched applications, not with handlers or drivers.
new@udel.edu (Darren New) (01/17/90)
O.K., great! Next question:
Can anybody tell me an easy way to do an asynchronous, abortable read
of a device from AREXX? Basically, I want to read the serial port
with a timeout. I have one quite kludgy method: task one reads lines
and posts them to a port. Task two delays and sends "TICK" to the same
port every ten seconds. Task three reads the port and eventually times
out. It works, but is really ugly. Also, can anybody tell me how to
automatically change the serial-port speed depending on the connect-speed
without losing the carrier? I.e., my Hayes will send "connect 1200" at
300 baud and then switch. Can any AUX: driver be switched when I get this line
to 1200 baud without a close and reopen, which probably drops DTR?
Alternately, can anybody direct me to the recent "rexserdev" programs/libs/etc
mentioned recently here or in comp.lang.rexx? I would just as soon do
this whole mess in ARexx w/o resorting to C hosts, but a pre-written host
(freely distributable) would be acceptable, possibly better.
Again, thanks in advance for any info anyone supplies! -- Darrenpeter@sugar.hackercorp.com (Peter da Silva) (01/17/90)
> In fact we don't encourage people to zap their > executables; ZapPort was rather a last minute addition. Instead we > reccommend that a user use the NewPort utility; this leaves the > executable untouched but creates a separate loader program which will > load in the application and alter it in RAM. Since you're working on a copy anyway (I hope) zapping it on disk or in RAM isn't that different. Exactly what does ZapPort do? Change "serial.device" to "checkp.device"? Try to find the unit # and change it? -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
ckp@grebyn.com (Checkpoint Technologies) (01/17/90)
In article <8438@nigel.udel.EDU> new@udel.edu (Darren New) writes: >O.K., great! Next question: >Can anybody tell me an easy way to do an asynchronous, abortable read >of a device from AREXX? Basically, I want to read the serial port >with a timeout. >Also, can anybody tell me how to >automatically change the serial-port speed depending on the connect-speed >without losing the carrier? I.e., my Hayes will send "connect 1200" at >300 baud and then switch. The things you speak of are generally in the domain of serial.device, which is perfectly capable of doing what you want (with the help of timer.device). You can't change the baud rate of an AUX: port once it's opened, you can only close it and re-open it, but this will drop DTR on the modem and (probably) make it hang up. I've seen mention of rexxserdev, but I don't know what it includes. It may be your best bet.
cmcmanis@stpeter.Sun.COM (Chuck McManis) (01/18/90)
In article <4943@sugar.hackercorp.com> (Peter da Silva) writes: >What should they have done? The serial port is in a documented name space. >It's up to applications developers to provide a way of specifying the port >number and device name to their program. Hardcoding ("serial.device",0) is as >bad as a UNIX program hardcoding ("/dev/acu") or ("UNIX:0"). Why do people use the serial.device and not SER: ? The reason is fairly simple, because the handler doesn't do what most people want to do with a serial device, which is usually things like : set_baud_rate() set_frame_format() set_parity() query_baud_rate() query_frame_format() query_parity() check_for_character() wait_for_character() send_character() send_buffer() send_break() query_status() These are the kinds of operations that any application might want to do with the serial port, but the handler doesn't let them. Rather the handler will just let them read it and write it. (buffered no less) >I've seen people go around and around on this, and I'm still missing the >point. Devices have names. Are the names aesthetically displeasing or >something? Whatever *new* scheme Commodore came up with would have no better >chance of being supported by developers than the *old* scheme. You are absolutely correct, devices do have names but no one is arguing that file requesters should put up "trackdisk.device", "harddisk.device" as selections. But you may be overly cynical in believing that a new scheme would not have a better chance of being supported. I think this is only true if the new system didn't offer any benefits over and above old scheme. And yet the benefits are clearly sufficicent to merit the change. Consider what we are trying to accomplish, and the obstacles thereto. The handler for the serial device sucks, granted, so lets fix it so that people will use it instead. No more DoIO's to the serial device and training new kids on the block that the loop : for (;;) { Waitfor_1_char(); Display_1_char(); } which has the two disadvantages that these are custom routines built out of calls to DoIO/SendIO/etc, and that they will be slower than molasses in winter because the massive overhead of the various system calls for each character. Instead have the handler read and write characters efficiently to and from the device for you, which it can because it is a separate task. Then use a loop like : for (;;) { l = Read(ser, &buf, 256); /* Return all characters in buf */ Write(con, &buf, l); /* Write them to console */ } which will have acceptable performance and uses prebuilt routines. That will get people to use the _handler_ instead of the actual device (because anyone who has written massive serial code with DoIO's will welcome the change). Just that will have a *tremendous* benefit, now with people using SER: instead of serial.device,0 we can point the handler at anybodies serial device code just like we point the printer handler PRT: to different printer drivers. Now people like CheckPoint and ASDG can just deliver their drivers and tell users "To use our port, set your preferences selection for the serial device to WhizBang" And the application will automatically pick up the new serial device. Once you get people using the name of the handler, you can actually make it into a full fledged name space if you chose. We have pipe handlers that let you do a directory of named pipes, why not a serial handler that lets you do a directory of available serial devices. Type dir SER: and get things like "modem, asdg1, asdg2, amiga" and now not only do you get human readable names (rather than trying to remember that serial unit 6 is the third board from the right, or was it left, first port). You also get a system supported way for listing all of the serial ports attached to a system (which is currently impossible given the DeviceList structure definition). Application developers want some way of providing a selection of devices, well this is it and they can use the same code that is in their file requester. Another red herring pops up in this discussion all the time as well, what about backward compatibility with those programs that don't use SER: ? Nonproblem, they still work with the Amiga serial port just fine so what have you lost ? Nothing. The commercial applications will migrate or die. The PD ones would definitely migrate because it would be so much easier to write them using this scheme. So what is this proposal/suggestion ? It can be laid out as follows : o New Serial Handler SER: that uses a field in preferences to to determine which device it defaults to. Additionally, it supports packets that allow users to change/query baud rates etc etc as described above. And it supports "locks" on different devices so that the high level DOS commands such as DIR, COPY, etc would do what you expected them to. o New library, serial.library that does the actual grunge work of sending the packets to the handlers and actually implement the routines I've shown above. What do you end up with ? Well, you end up with a system that can now have an unlimited number of serial ports added to it that can be supported by all future applications because they have a well defined and useful interface by which to access them. And further they can be easily understood by experienced and novice users because all you have to do is look in the directory and see which devices are there. This is a Good Thing. It also gives us another leg up on the competition (PC, Mac, and ST) because none of them have an expandable serial port architecture. If you play your cards right you can do this with PAR: as well and then you are even better off. Of course it only works if Commodore decides to do it, if I write the handler and library and give them away for free it will be 'nonstandard' and no one will rely on them because you may not have them on your disk. So here I sit. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
ckp@grebyn.com (Checkpoint Technologies) (01/18/90)
In article <4949@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Since you're working on a copy anyway (I hope) zapping it on disk or in RAM >isn't that different. Exactly what does ZapPort do? Change "serial.device" >to "checkp.device"? Try to find the unit # and change it? The big advantage in using NewPort is that it only makes a 500-some odd byte long loader. This saves a lot in disk space, especially with 300K long executables. This is really important if the app is on a floppy, but still very nice when using a hard disk. What we do is find strings of "serial.device" and change them to "ckptss.device". Finding and changing the unit number is not something that can realistically be done, given the myriad numbers of ways programs might generate it. More and more programs are being released with support for multiple serial ports, especially communications programs. I figure many users won't need these zappers at all.
peter@sugar.hackercorp.com (Peter da Silva) (01/18/90)
In article <130368@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: > Why do people use the serial.device and not SER: ? The reason is fairly > simple, because the handler doesn't do what most people want to do with > a serial device, which is Which is not relevant. The default serial device is "serial.device",0. In fact, a well behaved terminal program should have requestors that allow you to change that. > You are absolutely correct, devices do have names but no one is arguing > that file requesters should put up "trackdisk.device", "harddisk.device" > as selections. If you have a generic format program, why not? [ Lots of stuff about improving the handler-level interface ] That's *also* a good idea, but in the existing world a modem program that doesn't allow you to specify things in the currently available name space is just plain broken. That's all. Oh yes, a modem program really shouldn't be busy-waiting on the serial port, as you describe. That's IBM-PC style stuff... busy-waiting is not acceptable on the Amiga. And there's no way to wait on two file handles at once (Hey, Commodore, how about making asynchronous I/O to handlers roek in 1.4?), so you have to go down to the DoIO level for an efficient terminal program anyway. > and ASDG can just deliver their drivers and tell users "To use our > port, set your preferences selection for the serial device to WhizBang" > And the application will automatically pick up the new serial device. Yeh? And what happens if I want to run two modem programs at once, on two lines? I've needed to do that badly enough that I wrote a dual-port split- screen modem program for the IBM-PC. > Once you get people using the name of the handler, you can actually make > it into a full fledged name space if you chose. We *have* a full-fledged name space. device name and unit number uniquely identifies a port. Now what you *really* need is a "ROOT:" device and a packet you can send to a handler to return the underlying device so you can DoIO to your heart's content. And there *are* existing modem programs that support underlying devices. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
d87-khd@sm.luth.se (Karl-Gunnar Hultland) (01/19/90)
In article <1053@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: > >Due to its enormous usefulness to those who need it, we (ASDG) >provide both a ser: and aux: clone with the Dual Serial Board. These >handlers both support complete command line serial parameter specification, >like so (using Darren's example): > > Open("Joey:9600" , MODE_OLDFILE) or just as easily > Open("Joey:19200/8N1/32000" , MODE_OLDFILE) etc. > >We also support two levels of defaults for filling in the serial parameters >which were not specified on the command line. That seems like the thing I'd need if I manage to port MUD to the Amy. What's the price of the board , with software? Karl +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Karl 'Dixie' Hultland | email: d87-khd@sm.luth.se | | University of Lulea | : {uunet,mcvax}!sunic.se!sm.luth.se!d87-khd| | Sweden | Snailmail: Mjolkuddsv. 63-5, S-95157 Lulea Sweden | |=======================| Voice nat: 0920-15479 | | Urbi et Orbi | Voice int: +46 920 15479 | |=============================================================================| | If two people agree on EVERYTHING , one of them is OBSOLETE!! | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
doug@xdos.UUCP (Doug Merritt) (01/20/90)
In article <1053@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: >>In <14137@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) writes: >>> Due to it's limited usefulness, we (Checkpoint Technologies) >>>decided not to include an AUX:-style handler with the Serial Solution > >Due to its enormous usefulness to those who need it, we (ASDG) >provide both a ser: and aux: clone with the Dual Serial Board. <Snicker.> Nice comeback. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary