home *** CD-ROM | disk | FTP | other *** search
- DigiWARE DMODE for OS/2 (V1.3.1)
-
- Introduction
-
- DMODE is a 'work-alike' of the MODE command under OS/2 but with a
- number of added features and a few different rules of behavior.
- It came to the attention of the DigiBoard Technical Support Staff
- that the standard MODE command -- though useful for many things --
- was limited in the following ways:
-
- -- No communications device names besides COM1 - COM8 could be used.
- -- Baud rates above 9600 could not be assigned.
- -- Timeout, Handshake signals, etc. could not be set without having
- to re-specify the Baud rate, Parity and Data type parameters.
- -- If any of the set of Baud_rate:Parity:Databits:Stopbits was left
- off the command line, MODE would assign them to ITS defaults of
- 1200,e,7,1, instead of the defaults of whatever those values are
- CURRENTLY set to. Thus a user wanting only to change Baud rate
- would unknowingly also re-set the Data type and Parity of the
- device.
-
- DMODE addresses these issues while attempting to remain compliant
- with the familiar MODE command syntax.
-
- In general, DMODE attempts to forgive as much as possible in terms
- of both the order of the arguments and of each argument's
- requirements for other unrelated arguments. Given the limited range
- of values that most of the parameters can assume, DMODE will assign
- a parameter based on its value instead of its position in the command
- line. The syntax of the DMODE command is then
-
- DMODE device-name[:] [arguments]
-
- where the device name must be the name of a character-device that
- supports Generic IOCtl system calls. The Colon is optional and is
- there only to be backward compatible with MODE. The remainder of
- the arguments are parsed according the following rules. The
- arguments may appear in any order and must be separated from
- each other with a space and/or comma. Any parameters left unspecified
- on the command line will be left in their current settings. In any
- case, DMODE will report the current settings of all parameters AFTER
- such changes as requested on the command line have been assigned.
- Thus with no arguments (i.e. no changes to current settings), DMODE
- simply reports the current settings.
-
- Baud Rate Rules:
- Baud Rates parameters are recognized to be any 2 to 5 decimal
- digit argument to be mapped as follows.
- Accepted values.... Assigned Baud rate
- -----------------------------------------------------------
- 11 110 110
- 15 150 150
- 30 300 300
- 60 600 600
- 12 120 1200 1200
- 24 240 2400 2400
- 48 480 4800 4800
- 96 960 9600 9600
- 19 192 1920 19200 19200
- 38 384 3840 38400 38400
- 57 576 5760 57600 57600
- 07 75600
- 01 115200
- ***Baud rates above 9600 NOT recommended for COM/XI on many channels
- ***Baud rates above 38400 NOT recommended for any of the cards except on a few
- channels at a time.
-
- Data Bit Rules:
- Data Bit parameters are recognized to be any 1 digit
- consisting of 5,6,7, or 8.
-
- Stop Bit Rules:
- Stop Bit parameters are recognized to be any argument with
- the value of 1, 2, or 1.5.
-
- Parity Rules:
- The Parity parameter is recognized to be any single-letter
- argument with the value of E, O, N, M, S -- For (E)ven,
- (O)dd, (N)one, (M)ark, and (S)pace. Upper or lower case letters
- are acceptable.
-
-
- Handshake Signals and Timeout parameter Rules:
- These arguments follow the documentation for standard MODE command.
- The accepted signal names are listed below. In all cases the
- name and assignment may be in any mix of upper an lower
- case characters.
-
- Full name Argument State Assignments
- -----------------------------------------------------
- Read-timeout TO ON OFF
- Xon/Xoff handshake XON ON OFF
- Input DSR sensitivity IDSR ON OFF
- Output DSR sensitivity ODSR ON OFF
- Output handshake on CTS OCTS ON OFF
- DTR signal control DTR ON OFF HS
- RTS signal control RTS ON OFF HS TOG
-
- ALT_PIN processing:
- In some cases it is useful to have the driver report changes in
- DSR as if they were changes in CD (the modem Carrier Detect Signal).
- This is sometimes done to get around a limitation of the
- 8-wire RJ45 connector -- a connector which leaves pin1 and pin10
- of the standard 10-wire RJ45 unterminated. Since pin10 is defined to
- be Carrier Detect and so many communications programs depend on
- accurate reporting of the state of this CD signal use of 8-wire
- RJ45 connectors can prevent these programs from working. A work-around
- is to slightly change the wiring scheme of the 8-wire RJ45 so that
- the CD wire is brought into the middle 8 wires which DO make contact.
- Of course this means that the signal that USED to be defined for that
- location must be moved out to pin10, where CD used to be. In
- general the LEAST payed-attention-to signal is DSR (on Pin2) so if
- CD is wired to Pin2 and DSR is wired to Pin10 close to full modem
- control can be acheived on an 8-wire RJ45. The final step in this
- trick is then to instruct the Device driver that for THIS channel
- pin2 is to be interpretted as CD instead of DSR. DMODE permits
- this ALTERNATE PIN ASSIGNMENT PROCESSING mode to be established on
- channels by issueing the requisite custom command to the XALL driver.
-
- dmode {devname} ALT=ON ;; report PIN2 as CD
- or
- dmode {devname} ALT=OFF ;; report PIN2 as DSR (default)
-
- Those interested in implementing this custom call in software should
- look at the file XALL.DOC on the distribution diskette for information.
-
- QUICKWRITE processing:
- Normally, each time an application program WRITEs to a device
- (i.e. makes a request to transmit data), the application is
- suspended until all of the data in the request has actually been
- transmitted. With many small requests this can be wasteful. An
- alternate method is to transfer all the data to the shared memory
- buffers on the DigiCHANNEL card and leave it up to the intelligence
- on the card to transmit that data according to the relevant
- flowcontrol settings -- and permit the application program to
- proceed with execution. This greatly increases overall system
- performance but can possibly confuse an application that is attempting
- to very closely track the throughput (bytes/sec transmission rate)
- or doing timeout of fine granularity.
-
-
- dmode {devname} QW=ON ;; enable QUICKWRITE processing
- or
- dmode {devname} QW=OFF ;; disable QUICKWRITE (default)
-
- Those interested in implementing this custom call in software should
- look at the file XALL.DOC on the distribution diskette for information.
-
- Examples:
-
- dmode digi12 [ interrogative; no settings changed ]
-
- dmode com5 2 [ the '2' assumed to be stop bits.. ]
-
- dmode com5:38 rts=ON [ the '38' is parsed to the baud rate]
- [ of 38.4K baud, and RTS is turned ON]
-
- dmode com5 8 [ the '8' parsed as data bits ]
-
- dmode comdev83 IDSR=OFF,TO=off e 7 12
- [ IDSR is turned OFF, timeout on reads]
- [ is set to off, Even-parity is set, ]
- [ 7 data bits is set, 1200 baud is set]
-
- dmode com5 38 ALT=ON [ set 38.4Kbaud, report PIN2 as CD ]
-
- dmode com5 e alt=off QW=on
- [ set EVEN parity, report PIN2 as DSR , ]
- [ enable QUICKWRITE processing ]
-