PC-Test Pro

home *** CD-ROM | disk | FTP | other *** search

/ PC-Test Pro / PCTESTPRO.iso / commtls / spm / org / spm220e.exe / STARGUID.DOC < prev next >

Wrap

Text File | 1995-10-20 | 63.9 KB | 1,220 lines

S E R I A L P O R T S M A N A G E R v 2.20 ------------------------------------------------------ S.T.A.R.COMM Serial Turbo Async. Resident COMMs ------------------------------------------------------ 10/20/95 ══════════════(C)opyRight HETRU 1991-1995═════════════ 13, chemin de la croix St Vincent 94430 CHENNEVIERES SUR MARNE FRANCE tel: (16-1) 45-93-27-38 CompuServe address: 100414,1524 Internet: 100414.1524@Compuserve.com U S E R G U I D E REMARK: In all this document, STARCOMM.EXE could be replaced by STARCOM8.EXE. STARCOMM.EXE is interfacing no more than 4 ports, whereas STARCOM8.EXE could support up to 8 ports ! (All the values limits specified in the following text are for STARCOM8: we refer to "COM8:" or to "8" ports or buffers. Just change these values to "COM4": or "4" if you consider STARCOMM !) TABLE OF CONTENTS Introduction........................................................ 1 I- Functional features of STARCOMM.................................. 2 II- Respective advantages between "BIOS" and "DEVICE DRIVER" installations 1- Used in the BIOS (T.S.R.) mode............................... 4 2- Used in the DEVICE DRIVER mode............................... 4 3- When using the library (SCLIB.OBJ)........................... 4 III- STARCOMM.EXE COMMAND SYNTAX 1- To load the driver in its T.S.R. BIOS mode................... 5 2- To load the driver in its DOS DEVICE DRIVER mode............. 5 3- Commands and options known by STARCOMM.EXE................... 6 IV- USING SPECIFIC(S) DEVICE(S) ON SERIAL PORT(S) 1- Using a mouse in 'competition' with STARCOMM................. 13 2- Accessing to an internal or external modem................... 13 3- All type of devices knowing a protocol....................... 13 V- SETPORT.COM UTILITY 1- Syntax of SETPORT.COM........................................ 14 2- Command options of SETPORT.COM............................... 14 ANNEX A: Principle of the null-modem cable......................... 17 ANNEX B: Types of UART chips on PC and compatibles................. 19 ANNEX C: Why a "BIOS emulation" ?.................................. 20 ANNEX D: Files making SERIAL PORTS MANAGER v2.20................... 21 1 INTRODUCTION This document exposes the main features of the serial driver, and the different ways STARCOMM.EXE can be used. This driver was developed in 8086 assembler language on IBM-PC and works under MS-PC/DOS and all compatibles operating systems (DR-DOS, DOS "task- windows" under WINDOWS and OS/2, etc.). The SETPORT.COM utility allows to modify the mode of working and the initialization of STARCOMM by nominative port, as well as visualizing the states of all the serial ports recognized by this driver (when found resident in memory...). It also presents the advantage, over the command-line interfacing offered by STARCOMM.EXE, that it doesn't reactivate the default values of the different driver parameters. The TESTSTAR.EXE demonstration (source *.PAS) permits to visualize the efficient working of STARCOMM, and permits to test locals serial links (TESTSTAR is a multi-ports processus). The TERMINAL.COM program (developed in C) demonstrates the utilization of STARCOMM when loaded in its DEVICE DRIVER mode. It creates a communica- -tion active on one channel at a time (it is a simple TTY emulator...). The REMOTE.EXE utility allows you to exploit a second IBM computer from a computer called "local". The "local" IBM then acts like the normal console of the distant IBM (called the "REMOTE" !). It is a small application gracefully offered with SERIAL PORTS MANAGER in order to give an example of what this package can do for you. The "EXISTENCE" of a port answers to the double following condition: the address that it wants to use correspond to a physically present UART, AND the IRQ it is assigned to could be installed (ATTENTION: if an other program comes to reroute this IRQ after the installation of STARCOMM, the port will be un-usefull to establish any serial link to the means of STARCOMM whereas the port will always remain "EXISTING", and this until restitution of our vector by this other application...). A port is said "OPENED" when the electric logical signals of the PC are set in order to activate the interrupts that are physically going to allow a completely functional link. Otherwise, this port will be said "CLOSED" ! 2 I - Functional features of STARCOMM: ═════════════════════════════════════ ■ STARCOMM.EXE could be loaded from the DOS prompt (like any standard program) or from the CONFIG.SYS (DEVICE=STARCOMM.EXE...). ■ In order to get an information page and a brief help, use the "?" character (the "/" character is not compulsory): x> STARCOMM /? ■ ErrorLevel codes returned by the installation module in BIOS mode: 0 --> No error: requested action correctly done, 1 --> End of program on impossibility to un-install. ■ This driver manages, under hardware interrupt(s), the serial ports COM1: to COM8: of compatible PC/AT in using buffers in RAM memory. There are 1 receipt buffer AND 1 transmit buffer for each port recognized at the installation time (except orders making a more explicit limitation in the command-line). The receipt buffer is 1 kilo-byte in size, whereas the transmit buffer is reduced to 1/2 kilo-byte by default. It is possible to fix each buffer size between ½ and 55 kilo-bytes. It is also possible, for each application, to define its own buffers of any sizes in the limit of ONE segment (of the CONVENTIONAL MEMORY) for each serial port used: every acknowledged port can thus dispose of up to 64 Kilo-byte of I/O buffers if needed ! ■ STARCOMM manages asynchronous communication ports in exploiting the availables UART on the IBM. These UART could be a 8250, 16450 or 16550 type. If an 16550 UART is available on a given serial port, its FIFO mode is automatically exploited (excepted if forbidden from the command-line !). ■ The Request_To_Send(RTS)/Clear_To_Send(CTS) and Data_Terminal_Ready (DTR)/Data_Set_Ready(DSR) signals can be managed by the STARCOMM communi- cation processes, as well as RI, DCD and OUT1 ! The software hand-shaking Xon/Xoff is also acknowledged, and can be activated and dis activated, as can be RTS/CTS and DTR/DSR. This can be ordered from the DOS prompt, or using the software interrupt giving access to the serial driver functions (Int 14h). The hexa. codes to use for Xon and Xoff can be define as needed. ■ All group of 10 consecutives received errors provokes a complete initialization of the controller associated to the serial port used, this to avoid any possible interference with any other programs reaching the port in the local machine. To this effect also, the BIOS software interrupt 14h is filtered by STARCOMM (case of the programs using the serial ports via the BIOS: in this case,they provoke a communication format resetting to the level of our driver). As a consequence, for example, this implies that any initialization made using the DOS "MODE" utility will be acknowledged by the STARCOMM driver... Remarks: 1- Any initialization request on an inhibited port (Cf. III-3) will be rejected by our filtering of the BIOS interrupt 14h. 2- The BIOS variables addressing the UART chips are up-dated by the driver. They are reseted in their initial state at the time of the STARCOMM uninstallation. 3- The time-out BIOS variables are not, in any case, altered by STARCOMM. 3 ■ STARCOMM filters the basics interrupt 14H BIOS functions: it redirects to the driver any commands sent to an open serial port. From then on, it is the addresses and all the technical features of STARCOMM that are stakes to disposition of ALL the DOS comm. applications based on the BIOS level. These applications will therefore have their performances distinctly improved, and they will be able to gain the mapping benefit offered by STARCOMM.EXE (see "/A..." and "/I..." options...). Example: suppose D_COMM.EXE only uses the COM1 (via the BIOS), and your modem is installed as a COM3:, using the IRQ 7. execute: x> STARCOMM /A1=03E8 /I1=7 x> SETPORT COM1: /O /Inform ...and then: x> D_COMM And that's all !... REM: Thanks to the "/EB" option that activate the STARCOMM BIOS emulator, it could be avoided having to open the port to use (Cf. ANNEX C) ! However, no buffer will be used by the driver in this last case. ■ ATTENTION: After the installation and/or after any parameter(s) modification from the driver command-line, the ports are reseted in their UNACTIVE state (except using option "/O..."). Any application wanting to use port(s) in order to communicate will therefore have to initially take carefulness of reopening the appropriate(s) port(s)... ■ STARCOMM can generate 2 kinds of transmitting: a slow transmission (18 bytes by seconds), and a fast transmission (continuous flow only limited by the capacity of the UART to transcode the bytes). On 8 simultaneous opened ports, each one could dispose of its own transmitting mode. The choice of the mode to activate only depends on the device with which it is necessary to converse. For example, to make a direct local link with a Minitel, it IS necessary to activate the slow transmission because this terminal doesn't presumably work in an interrupt way: if too much bytes arrives between 2 Minitel scans, there is overrun, and therefore loss of information to the Minitel level. In general, for all device working in a scanning mode, it is necessary to activate the slow transmission of STARCOMM (thus creating an everage transmission of 18 bytes a second...). ■ IMPORTANT REMARK ON HARDWARE INTERRUPTS SHARING: Only the specials multi-serial ports boards and the IBM-PS/2 computers permits several serial ports to share a same IRQ. If you joined several ports on a same IRQ with any other material (PC, XT or AT), know that you must NOT open at the same time all these ports. It will then be necessary to always open only ONE of these ports at a time for it to be fully working ! (! THIS IS A HARDWARE LIMITATION NOT SURPASSABLE BY ANY SOFTWARE !) 4 II- Respective advantages BETWEEN "BIOS" and "DEVICE DRIVER" installations ══════════════════════════════════════════════════════════════════════════ 1- Used in the BIOS (T.S.R.) mode: ────────────────────────────────── ■ Uses less RAM memory (the DOS normalized interface doesn't remain in RAM memory after the driver installation !). ■ Ability to un-install the driver when becoming useless in RAM, without having to fully reset the computer; ■ Complete relative independence to the operating system, so that: . considerable increase on execution speed of the services offered by the driver: indeed, the DOS layer being absent in the case of an Int 14h, every logical access to the driver corresponds to an unique physical call to this driver (where a DOS interface function could easily achieve it by at least 4 DOS internals calls !), . and absence of any trouble on EOF code (^Z) management that is merely unknown to the interrupt 14h. 2- Used in the DEVICE DRIVER mode: ────────────────────────────────── The driver is here-by known by the DOS. It opens the access to a new logical device (referred as "COMM:" by default) to which it is possible to access with no more programming using the DOS shell (COPY CON: COMM:) OR, with programming, using any computer language (use the DOS standard files access functions integrated to all programming languages !). 3- When using the library (SCLIB.OBJ): ────────────────────────────────────── This serial port driver format is not usable from the DOS prompt. It is only usable by the programers in order to integrate the kernel of SERIAL PORTS MANAGER directly to their creations,this to avoid any de- -pendence between their programs and any external driver if he wants to ! The application thus developed will only benefit the BIOS mode, with the advantages associated (report to part 1-...) PLUS the advantage to be able to call the driver services without transitting through the interrupt 14h (Cf. STAR-REF.DOC on this...). The ability, for each application, to define its own external buffers for each serial port negates the fact that the library only integrates 2 very small buffers for each port by default (1/2 kilo-byte each...). 5 III- STARCOMM.EXE COMMAND SYNTAX ════════════════════════════════ STARCOMM.EXE can be loaded as an external driver to the DOS (in its "BIOS" mode) OR as a DEVICE DRIVER (thus creating a "character" type file named "COMM:" by default). The SETPILOT.EXE utility can help you to get in touch with the numerous options that STARCOMM.EXE knows ! 1- To load the driver in its T.S.R. BIOS mode: ────────────────────────────────────────────── From the DOS command line (the "prompt"...), just order: d>[<drive>:][<\path\>]STARCOMM [COM:][speed][,parity][,bits][/<options>] The only software interrupt to access the STARCOMM services will then be the interruption number 14h. 2- To load the driver in its DOS DEVICE DRIVER mode: ──────────────────────────────────────────────────── Integrate the following order in your CONFIG.SYS: DEVICE=[<drive>:][<\path\>] STARCOMM [COMi:][speed][,parity][,bits][/<options>] In addition to the interrupt 14h, STARCOMM will thus be also accessible by using the DOS interrupt 21h FILES functions; and you will even have access to the "COMM:" file at any moment from the DOS prompt. 6 3- Commands and options known by STARCOMM.EXE: ────────────────────────────────────────────── The initialization format explained below takes effect for the whole acknowledged serial ports of the driver. [COM:] = Announces the definition of the format initializations. When STARCOMM has been (or is) loaded as a DEVICE DRIVER, specifying COM1: (or COM2:, etc...) allow to orientate the logical file ("COMM:" by default) on the serial port thus specified. [speed] = {110,150,300,600,1200,2400,4800,9600,19200,28800,38400, 57600, or 115200} bits a second (9600 by default). [,parity] = {N, P, I, T, or R} for 'N' no, 'P' even, 'I' odd, 'T' work, or 'R' rest (N by default). [,bits] = {5,6,7 or 8} for a coding on 5,6,7 or 8 bits (8 default). [,stop] = {1 or 2} for 1 or 2 stop-bit(s) (1 by default). The working-control options recognized by STARCOMM are: [/A<N>=<address>[,<N>=<address>[,...]] = Use <address> (in hexa.) for the port <N>, then... For each specification, give the address of the first associate UART register for the indicated port number. At this address, if no UART is detected, the associate port will not be functional and treated as INEXISTANT by the driver. Every specified address must be made of 4 numbers: write /A3=0370 and not /A3=370 !... Note that in permuting some addresses between different existing ports, you could redirect the standard DOS ports (attention to the IRQ linkage !...). ATTENTION: This option is unknown for the ports of which the IRQ seems to be rerouted by a program loaded after STARCOMM.EXE (in order to respect the consistency of the IRQ chain in the computer !). [/I<N>=<num>[,...]] = Use the RQ number <num> for COM<N>:. Only the IRQ 2, 3, 4, 5, 7, 10, 11, 12 and 15 are admitted. Any indicating sequence can be used with no importance. The erroneous or forbidden indications will be unknown. If a program installed after STARCOMM.EXE has rerouted some interrupts used by STARCOMM, it won't be possible to modify these IRQ for the associated port(s), and this until un-installation of that post-loaded program. The Order is then unknown (no apparition of new IRQ number in the driver message !). In case of repetitions for a same port, only the last specification will be considered as consistant. REM: Don't use IRQ2 on AT and PS/2, this IRQ being reserved to a second 8259 (interrupt controller) installed in cascade on these machines ! Don't use IRQ5 on the XT machines (providing hard disks). At the time of the installation (as well as at the time of any parameters modifications), a demand for IRQ2 on an AT or a PS/2 or a demand for IRQ5 on an XT will be rejected. The IRQ10 and above could not be accepted on AT or PS/2 equivalents ! 7 [/G<num>[,<num>...]] = I<G>nore the serial ports <num>. Permit the cohabitation of STARCOMM with other drivers working on serial port(s) too (we can explicitly dedicate them one or several ports: report to the paragraph IV about this topic...). This option also permits to manage the conflictual problem of sharing hardware interrupts on the materials that don't support these sharings (ex: if you have a COM2: and a COM4: both linked to the IRQ3 on an AT, forbid either before executing TESTSTAR.EXE; because this program opens all the marked present ports, it would result of it, in the contrary case, a conflict that would block either port COM2: or COM4:, in truth the two !...). Forbidding the access to all the ports won't forbid to load STARCOMM.EXE; but there won't be any possible communication in this case (except utilization of the function 0Ah of the services interrupt 14h...) ! ATTENTION: This option is never USEFUL when used to modify an already RAM-installed STARCOMM setup whereas it tries to act on a port of which the interrupt seems to be redirected by an other application than STARCOMM ! Allowing such a maneuver would set the logical existance statutes of the serial ports unconsistant with the real state of the machine's vectors diverted by the asynchronous ports driver; and then, some declared "EXISTING" ports could not be functional. Besides, it would become impossible to uninstall STARCOMM.EXE, even after all competitor applications (to the level of the used interrupts...) have been themselves uninstalled ! [/V<n°>[,<n°>,...]] = Locks the speed for the specified comm ports. Any new speed would be substituted by the locked one ! [/F<n°>[,<n°>,...]] = Locks the comm <F>ormat. Same as "/S"... [/EL<num>[,<num>...]] = s<E>nd s<L>ow on the port <num>. Permit to activate the transmission in its reduced flow for the specified ports. It will be the clock interrupt (and not the UART one) that will order them to send out some bytes contained in the transmit buffers of the specified ports. It will therefore be 18 bytes a second (maximum...) that will be transmitted toward the outside. [/O<num>[,<num>...]] = <O>pen the serial ports <num> as soon as the installation is finished. Using the device attached to "COM<num>:" is then possible as soon as the driver is installed. [/EB] <E>mulator IOS permit not to redirect the calls of the interrupt functions 1 to 5 toward the original BIOS int. 14h. A BIOS emulation code is then activated. It presents the advantage of using the addresses, the time-out values, and the respect of the hardware hand-shaking signals that are all imposed to the STARCOMM driver. This code executes its inputs/outputs directly on the physical specified port (buffers are not used...). 8 Each of the following options take value for all the ports known as existant by the installed driver. In order to act only on one port, it is necessary to act in using the software interrupt of the driver interface (this results of the will to preserve the driver installation process from being too complex; use SETPORT.COM in order to control the ports separately from one another...). [/PC] = Knows the used machine as a <PC>. The IRQ2, 3, 4, 5 and 7 will be all authorized for utilization. This command is to reserve for the old computers (BIOS of 1985 and before generally) or for those that declares of erroneous way (compatible PC to the BIOS little compatible (!), or advanced machine "under-configured": ex. an XT without hard disk --> its IRQ5 is therefore free !...). [/XT] = Knows the used machine as an <XT>. The IRQ2, 3, 4 and 7 will be the only IRQ authorized. [/AT] = Knows the used machine as an <AT>. The IRQ3, 4, 5, 7, 10, 11, 12 and 15 will be the only authorized. [/PF] = Leave orts <F>IFOs un-activated on the found 16550. This option surpasses the following one. [/F=<Nb. of bytes>] = Number of bytes of the 16550 UART buffers to use at the transmit process level. "<Nb. of bytes>" must be included between 2 and 15, otherwise the option is merely unknown, and the default value of 14 is then used. REMARKS: Indeed,16 bytes do constitute this physical buffer of the 16550 UART. STARCOMM only allows a maximum of 15 because it seems that some kinds of these UART loses some informations if the software tries to benefit from the transmit buffer in its entirety ! In receipt, the FIFO is always exploited on 14 bytes (the "trigger level" is frozen to 14 by STARCOMM). It is the maximal value authorized by the hardware ! [/AI] = <A>utoscan RQ... The driver automatically research on which IRQ lines are installed the serial ports found at the specified addresses. The "/I=..." option has priority on this "/AI" option that can reveal itself not reliable on some hardware (particular modems OR very fast computers...) NEVER USE OPTION "/AI" UNDER WINDOWS OR THE OPERATING SYSTEM WILL CRASH ! ! ! . [/S[=<hexa_code>]] = Activate the <S>ubstitution process of the bytes specified as deficient upon receipt by the specified code. This code could be specified in the room of term <hexa_code>. The default value used is 0FEh. /S=NULL (or "/S=N" because only the first letter of "Null" is really necessary !) permit to order the voluntary loss of any erroneous byte received. [/K[=<code_hexa>]] = Activate the function of representing, in the receive buffers, the received BREAKs. <code_hexa> is the code that will represents the BREAKs. /K without any more specification will force the use of 03h to represent a BREAK in the buffer. /K=Null stops this function. 9 [/<nb>] = Permits to limit the number of buffers pairs (transmit/ receive) that the driver could open in RAM. By default, STARCOMM reserves 1 pair of buffers by port physically acknowledged during the installation process. Attention: limiting the number of buffers pairs also limits the number of serial ports that it will be possible to open at the same time ! <nb> is limited between 1 (at least 1 buffer to create !) and 8 (i.e. the biggest possible number of usable ports). This option could only be acknowledged by the installation process of STARCOMM. Otherwise, it is ignored, and the correspondent message displayed will only be a recall of the number of buffers the driver knows it can create in RAM. REMARK: In order to save room in memory, it is better to load "STARCOMM/1" when it is going to be used with mono-link applications (some emulators generally...), whereas several serial ports exists on the used machine. [/BR=<size>] = Specification of the memory size to allocate to the <R>eceipt uffer(s). <size> must be included between ½ and 55 Ko., and won't be acknowledged but at the time of the first installation of driver in memory. Thereafter, the driver will satisfy of recalling the buffers used due to the initial installation. In order to modify the size of the receive buffers, uninstall then install again the driver with a new <size> value ! [/BE=<size>] = Specification of the memory size to allocate to the s<E>nd uffer(s). The notes on the reach of this option are identicals to those of the option above. NOTE that if the added sizes of all the buffers to create passes the re- maining free room in the driver segment, the sizes of these buffers will be automatically reduced in order to contain the buffers in the limit of this segment ! The sizes finally restrained will always be a multiple of 1024 bytes. [/R=<tps>] = Definition of the time limit to the tip of which the impossibility of <R>eceiving must abort on a time-out error... The <tps> parameter, that must be included between 1 and 255, explicit the maximum number of half a second to wait before generation of a receiving time-out. [/E=<tps>] = Definition of the time limit to the tip of which the impossibility of s<E>nding must abort on a time-out error... The <tps> parameter, that must be included between 1 and 255, explicit the maximum number of half a second to wait before generation of a transmitting time-out. [/LC] = "<L>ocal <C>lear_to_send": The local site must recognize the RTS/CTS hand-shaking: it checks CTS=TRUE before any send, but it sets RTS in order to control the distant site that is supposed deaf to this signal. [/EC] = "r<E>mote <C>lear_to_send": The distant site is supposed to check its CTS signal before its TRANSMITTING, this to control the speed of its transmit flow upon the order of the local site; however, the local site must not interpret the local CTS before its own TRANSMITTING. The local site sets RTS in order to up-date the CTS signal of the distant site. 10 [/BC] = Use the RTS/CTS hardware hand-shaking in bilateral. (i.e. "ilateral <C>lear_to_send") [/LD] = "<L>ocal <D>ata_terminal_ready": The local site must recognize the DTR/DSR hand-shaking: it checks DSR=TRUE before any send, but it sets DTR in order to control the distant site that is supposed deaf to this signal. [/ED] = "r<E>mote <D>ata_terminal_ready": The distant site is supposed to check its DSR signal before TRANSMITTING, this to control the speed of its transmit flow upon the order of local site; however, the local site must not interpret the local DSR before its own TRANSMITTING. The local site sets DTR in order to up-date the DSR signal of the distant site. [/BD] = Use the DTR/DSR hardware hand-shaking in bilateral. (i.e. "ilateral <D>ata_set_ready"). [/RI] = The local site must check that RI=TRUE before TRANSMITTING. REMARK: Check the remark below ! [/CD] = The local site must check that DCD=TRUE before TRANSMITTING. REMARK: In fact, it goes of it precisely in the same way for the options [/LC] (with the CTS signal) and [/LD] (with DSR) that are explained,higher, in the context of the normalized protocols RTS/CTS and DTR/DSR. (There is no obligation in the act that local CTS is hardback to remote RTS; or that local DSR has connected to distant DTR !...). [/OT] = The local site set OUT1=FALSE as soon as it is not able to receive anymore data. Otherwise, it sets this signal to TRUE. Analogous REMARK to the previous for [/EC] (RTS signal) and [/ED] (DTR signal). [/LX] = "<L>ocal <X>on/Xoff": The local site knows the Xon/Xoff hand-shaking. But no Xon or Xoff code will be transmitted toward the distant site, supposed deaf to this protocol. [/EX] = "r<E>mote <X>on/Xoff": The distant site is supposed to recognize Xon/Xoff to manage its transmissions on order of the local site; however, the local site doesn't interpret the Xon and Xoff codes that it receives, but must manage them like any other data. [/BX] = Use the software Xon/Xoff hand-shaking in bilateral. (i.e. "ilateral <X>on/Xoff"). [/X=[<Xon>][,< Xoff>]] = Use the hexa. values specified for the Xon codes (before the comma) and Xoff (after the comma). The values kept by default are 11h (for Xon) and 13h (for Xoff). Every hexa. value specified must be made of 2 numbers included between the values 0 and F ! The following option doesn't have any sense except when STARCOMM is used as a DEVICE DRIVER: [/ND=xxxxxxxx] = Logical <N>ame of the <D>evice. Permits to assign a different name than "COMM:" to the unit created by STARCOMM when it is loaded from the CONFIG.SYS. It is possible to define this name with this option at any moment using STARCOMM.EXE from the DOS prompt, under the simple condition that STARCOMM resides in RAM as a DOS DEVICE DRIVER. Only the characters 'A'..'Z' and '0.'..'9' are admitted in order to constitute the logical name of STARCOMM used as a DEVICE DRIVER ! This name could be constituted of a number of any active characters included between 2 and 8. 11 The following option is special to a specific type of multi-comm boards: [/AP<adress>=<val>] = The <val> byte (hexa.) is sent to the <adress> adresse (hexa.). This permit to activate more than 2 serial ports on specifics multi-ports asynchronous I/O boards. <adress> must be 4 bytes length, whereas <val> must be 2... For example: /AP03FF=80 is OK, /AP3FF,80 is NOT ! This option may be used more than once (always with the same adress or with differents adresses each time...). ATTENTION: There is no check on the neutral and not dange- -rous type of accessing the specified I/O adress... Only use this option IF YOU KNOW WHAT YOU ARE DOING ! ... The 2 following options surpass and nullify all the others options; on the other hand, they are not executable by STARCOMM when it is used as a DEVICE DRIVER: [/D] = <D>esactivate AND UNINSTALL the driver from the RAM memory. If a program executed after STARCOMM rerouted at least one of the STARCOMM used interrupts (anyone, hard OR soft...) this option won't be treated. A message of impossibility will appear, and it will reacts the same if STARCOMM is used as a DEVICE DRIVER, or if one (or several) program(s) forbade STARCOMM to leave the memory. [/?] = Demand a display of the helping and informations page. This page will be displayed only if STARCOMM is executed from the DOS prompt. Finally, the [/PM] (No <M>essage) option permits to forbid the writing of the initializations control messages that finally took place. This option is especially usefull when we want to avoid the proliferation of the messages at the boot time (loading of STARCOMM from the CONFIG.SYS or the AUTOEXEC.BAT) ! Only the essential messages of success to install or of impossibility to install (or to uninstall) could appear despite this "/PM" option. To the contrary, the [/PA[=<length>]] option permits to force a <PA>use in order to allow the reading of the driver installation report. (<length> admitted from 0 to 60 seconds, 0 for an infinite expectation of hitting a key. 0 is the default used value...). NOTE that, even though STARCOMM is loaded as a DEVICE DRIVER, it remains possible to execute STARCOMM.EXE at any time from the DOS prompt in order to command somme new initializations or new working modes to the driver installed in memory. All the options, "/D" excluded, are perfectly usable in this case. All these options could be enumerated in an any order. It is possible to modify the status of the driver thanks to these commands even though it is already installed in RAM memory. The spaces introduced in a command-line don't have any particular meaning to the "eyes" of the commands sensor inserted in the serial driver. They will always be unknown: you can therefore use spaces at your own discretion in order to give your line a more explicit meaning to YOUR eyes. A request for an helping page provokes the interruption of the program immediately after the information is displayed: it will be necessary to execute again the driver with the needed options (and, this time, without the "/?" option) in order to get the appropriate requested installation. 12 If some contradictory requests are enumerated,only the last valid request of the concerned option will be restraint. Besides, it is always the last valid declared option (in a given type) that will be served and not its previous apparitions in the command-line. For example, "/I1=5,2=3 /I2=7" will provoke the utilization of IRQ5 for the COM1: AND of IRQ7 for the COM2: !... Exception: the command options of the hand-shaking controls activity are cumulatives. For example, "/LX/EX" does have the same effect than "/BX". The values kept by default are, for each option: Addresses--> COM1: 03F8 COM2: 02F8 COM3: 03E8 COM4: 02E8 COM5: 01A8 COM6: 01E8 COM7: 01F8 COM8: 02A8 on PC, XT, AT--> COM1: 03F8 COM2: 02F8 COM3: 3220 COM4: 3228 COM5: 4220 COM6: 4228 COM7: 5220 COM8: 5228 on PS/ 2 IRQ--> COM1: 4 COM2: 3 COM3: 4 COM4: 3 COM5: 3 COM6: 3 COM7: 3 COM8: 3 on PC, XT, AT except COM3: 3 (instead of 4) on a PS/ 2 Speed/Format --> 9600 bds, N81, fully UN-locked... Ports to be unaware of --> Not any one. BIOS Emulator --> Inactive. Utilization of the FIFO --> YES with 14 bytes. Substitution process --> Inactive (working in Smode0). Receipt buffer --> 1 kilo-byte. Transmit buffer --> 1/2 kilo-byte. Time-out in receipt --> 10 seconds. Time-out in transmit --> 10 seconds. Activity of the hand-shaking --> All inactive (hard and software). Codes Xon and Xoff --> Xon=11h and Xoff=13h. Name of DEVICE --> COMM: Physical serial port accessed by COMM: --> COM1: When an option provided to STARCOMM.EXE is not correct, it uses the default value of the parameter associated to the deficient control, but it doesn't write any message of specific mistake. Just by checking all the inits messages (except utilization of "/PM" !) you can assure yourself of your command(s) success... STARCOMM.EXE systematically disactivates the "user interrupt" functions on all the serial ports, as well as the "error management function" of the interrupt 14h when it is executed. The BIOS emulator is always DISACTIVATED too by default. 13 IV- USING SPECIFIC(S) DEVICE(S) ON SERIAL PORT(S) ═════════════════════════════════════════════════ 1- Using a mouse in 'competition' with STARCOMM: ──────────────────────────────────────────────── ■ Install the serial driver with the parameters you really need, enumerated in addition to the option "/G" (where 'i' gives the number of the port to reserve for the mouse). ■ Install MOUSE.COM on the serial port your mouse is attached to. ■ In case of requiring, you could use STARCOMM.EXE all over again in order to modify the installation parameters of this driver, but ALWAYS INCLUDING the "/G" option in your command-line ! Indications: This is due to the dynamic management of the environment practiced by the driver. In the present case of modifications of the inits, whereas an other driver set intervenes (the one of the mouse), it makes necessary to protect the inits associated to this other driver. This is made by forbidding to our driver the access to the port(s) dedicated to the other(s) driver(s). In order to interrupt the utilization of the mouse and recover its port to the level of our driver, it is sufficient to execute STARCOMM.EXE all over again, SUPPRESSING the "/G" option. ATTENTION: The most recents mouse drivers MUST be uninstalled because they are able to recover their IRQ and inits. dynamically !... 2- Accessing to an internal or external modem: ────────────────────────────────────────────── The STARCOMM driver of SERIAL PORTS MANAGER permits to reach any modem plugged in any of the serial ports numbered from COM1: to COM8:. It is sufficient, for that, to normally install the driver in memory. REM: In order to send some specific commands to the modem connected on the serial port of your choice, uses the function 1Ah of STARCOMM. (i.e., in Pascal and in C, the 'WriteCmde' procedure). ATTENTION: When this function 1Ah uses the DTR signal in order to indicate the modem that it is going to receive a control, and not a sequence of bytes to send on the line, it is necessary that the modem receives (before BEING connected) an order indicating not to interpret the DTR change to 0 as a connect aborting request ! (For the Compatible Hayes modem, the command is AT&D1...). The alternative consists in using the function 1Ah with BH=0 (=> DTR no used), and in including the prefix of associated command to the modem ("+" by default for the Compatible Hayes modems). Report to MODEM.DOC and its examples (in PASCAL and C) to this topic. 3- All type of devices knowing a protocol: ────────────────────────────────────────── It goes of it precisely like for the modems. Question: Particular case as examples ? Answer: The MINITEL with its TeleTex commands, the serial printers, ... and a lot of other materials (...from laboratories generally !) 14 V- SETPORT.COM UTILITY ═══════════════════════ The STARCOMM installation module doesn't permit a selective initialization between the various serial ports acknowledged by the driver. The reach is global to all the ports supported by the driver... SETPORT gives this selective interfacing. Further more, the only functional parameters of STARCOMM that SETPORT modifies are those explicitly (and correctly) specified in the command-line ! There is not any systematic ini- -tialization of all the working variables to their default values like the STARCOMM installation/modification module does. Finally, in case of contradictory options, it is always the last stated option that carries it away, except for the hand-shaking command options that are cumulatives (/LX/EX will have the same effect than /BX for example...). SETPORT.COM uses the interfacing functions of the driver (interrupt 14h) in order to communicate with it and thus to modify its working modes and status. This permits, therefore, to demonstrate the good working of these service functions of the STARCOMM.EXE serial port driver. 1- Syntax of SETPORT.COM: ───────────────────────── A NOT EMPTY command-line is COMPULSORY. The "/?" command option recalls an helping message on the available options, and interrupts the utility (all other controls associated to "/?" are ignored): d>[<drive>:][<\path\>]SETPORT [<parameter(COM1)>][<parameter(COMi)>...][/I] where [COMi:][,<speed>][,<parity>][,<bits>][,<stop>] [/<options>] constitutes every group [<parameter(COMi)>] (any space forbidden !). If STARCOMM is NOT found available in memory, SETPORT.COM protests by an error message and immediately stops. If STARCOMM is available and that SETPORT received no command to execute, it presents some lines explaining the utility of this program. IF all the commands given to SETPORT are unvalid, there will be a specific error message; but if at least one command is correct, the erroneous command(s) will be merely unknown(s) while the correct(s) command(s) will be served... 2- Command options of SETPORT.COM: ────────────────────────────────── The 8 following options have a global reach because they don't concern a port in particular: [/Inform] (or [/I]) = display an array on the status of the serial ports acknowledged as "existing" (Cf. the introduction of this document). Only the first letter of word "Inform" is sufficient for that option to be acknowledged (ex: "/Infos" will be also admitted !). The written array allows you to check the good acceptance of your commands. [/8] = Display the infos. on the 8 ports. [/PC| XT| AT] = Force the recognition of the material architecture. (Cf. same options made more explicit for STARCOMM.EXE). [/EB] = Activate the <E>mulator of the original comm. ios. (report to the explanation of the option "/EB" in page 7 of present document...). 15 [/PEB] = lease, set <E>mulation of original Comm. ios OFF... (that is: desactivation of the BIOS emulator !) [/COMM=x]= Makes to point the logical port created by STARCOMM (when it is loaded as a DEVICE DRIVER) on the specified serial port (/COMM=2 will make to use the COM2: by the DEVICE...). The following options don't make any sense but when they constitute a group clearly identified (a group concerns 1 port identified by "COMi":, and it doesn't contain ANY space !): [COMi:] = Announces the definition of the format initializations for the serial port number i (i from 1 to 8 in order to designate from COM1: to COM8:). [speed] = {110,150,300,600,1200,2400,4800,9600,19200,28800,38400,57600, or 115200} bits by second (9600 by default). [,parity]= {N, P, I, T, or R} for 'N' no, 'P' even, 'I' odd, 'T' work, or 'R' rest (N by default). [,bits] = {5,6,7 or 8} for a coding on 5, 6, 7 or 8 bits (8 by default). [,stop] = {1 or 2} for 1 or 2 stop-bit(s) (1 by default). [/L-] = Where "-" worth from 0 to 3: L0 makes a complet unlocking, L1 sets the speed locking, L2 the format locking, and L3 locks the speed AND the format for the specified port... Notice that SETPORT.COM (like STARCOMM.EXE) doesn't take care of these locking: it may change any speed and format for any port at any time ! [/A=xxxx]= Definite a new address (HEXA) to associate to the port. [/I=x] = Definite a new IRQ to use (2 to 5, 7, 10 to 12, or 15). [/AI] = <A>utomatic RQ research of IRQ associated to the ports. [/G] = Forbade the access to the port: it then becomes INEXISTANT. This option could not be executed if the IRQ associated to the concerned port was captured by a program executed after STARCOMM. [/PG] = Permits (if possible) the access to the port that becomes existing again (same remark than for "/G" on the IRQ). [/PF] = ort <F>IFO: if the port's UART is a 16550, it will be used in its 8250 emulation mode. Useful for some (old) PS/2 that uses some buggies 16550-A ! [/F=xx] = Size of FIFO: 0, or 2 to 15 bytes. "/F=0" is equivalent to "/PF" (see previous...). ATTENTION: The options /A /L /AL /PF and /F closes the port by authority ! [/EL] = Activate the s<L>ow transmits. [/ER] = Activate the <R>apid (fast) s<E>nds (transmits). [/PS] = No <S>ubstitutions of the bytes received with an error signalled on their transmission. [/S] = Activate the <S>ubstitution of the bytes received with an error by the code 0FEh (the '■' character...). [/S=Null]= <S>ubstitutions by the empties: all erroneous byte in receipt is not placed in the receipt buffer. [/S=xx] = <S>ubstitutions by the HEXA code xx. [/K=xx] = For each Brea<K> received, make the xx HEXA code appearing in the receipt buffer. /K=Null stops this function. /K (alone) will activate it with the standard value of 03h... [/R=xxx] = Time-out <R>ecept after xxx half a second. [/E=xxx] = Time-out s<E>nd after xxx half a second. [/NC] = Stop the RTS/<C>TS protocol. [/LC] = Activate the <L>ocal hand-shaking by RTS/<C>TS. [/EC] = Activate the r<E>mote hand-shaking by RTS/<C>TS. [/BC] = Activate RTS/<C>TS in ilateral working. [/ND] = Stop the DTR/<D>SR protocol. [/LD] = Activate the <L>ocal hand-shaking by DTR/<D>SR. [/ED] = Activate the r<E>mote hand-shaking by DTR/<D>SR. [/BD] = Activate DTR/<D>SR in ilateral working. 16 [/NRI] [/RI] = Stop/activation of hand-shaking based on RI. [/NCD] [/CD] = Stop/activation of hand-shaking based on DCD. [/NOT] [/OT] = Stop/activation of hand-shaking based on OUT1. [/NX] = Stop <X>on/Xoff protocol. [/LX] = Activate the <L>ocal hand-shaking by <X>on/Xoff. [/EX] = Activate the r<E>mote hand-shaking by <X>one/Xoff. [/BC] = Activate <X>on/Xoff in ilatéral working. [/X=[xx],[yy]]= Definite the HEXA codes to use for Xon ([xx]) and Xoff ([yy]). [/O] = <O>pen the port. [/F] = Close the port. EXAMPLE: C:> SETPORT COM1:110,p,7,2/s=Null/El/o COM3:/BX/R=2/AI /Info 17 ANNEX A: Principle of the null-modem cable The null-modem cable to use in order to exploit the SERIAL PORTS MANAGER driver as well as the associates demos., must be made following the minimum installation below: (3) Rx (receipt)────────««────────(transmit) Tx (2) (2) Tx (transmit)─────────»»───────(receipt) Rx (3) (7) Gnd (ground)───────────────────(ground) Gnd (7) The following installation allows to neutralize the RTS/CTS and DTR/DSR signals (allows to verify the neutrality of the hard hand-shaking protocols implemented in STARCOMM.EXE): (3) Rx (receipt)────────««────────(transmit) Tx (2) (2) Tx (transmit)─────────»»───────(receipt) Rx (3) (7) Gnd (ground)───────────────────(ground) Gnd (7) (4) RTS»─┐ ┌─«RTS (4) (5) CTS«─┘ └─»CTS (5) (20) DTR»─┐ ┌─«DTR (20) (6) DSR«─┘ └─»DSR (6) In all rigor, the complete scheme for the null-modem cable is: (1) Chassis ─────────────────────────── Chassis (1) (3) Rx (receipt)─────────««───────(transmit) Tx (2) (2) Tx (transmit)────────»»────────(receipt) Rx (3) (7) Gnd (ground)───────────────────(ground) Gnd (7) (4) RTS ─────────────────»»──────────────── CTS (5) (5) CTS ─────────────────««──────────────── RTS (4) (20) DTR ──────»»─────────┐ ┌──────««────── DTR (20) (6) DSR ─«─┐ └─────────────┬─»─ DSR (6) (8) DCD ─«─┴────────────────┘ └─»─ DCD (8) (22) RI ───────────────────────────────────── RI (22) 18 There is, between the number of the DB25 binds (concerned by the above diagrams) and the number of the DB9 bind, the following corresponding: Taken DB9 Taken DB25 Signal 3----------------------------2 <--> Tx 2----------------------------3 <--> Rx 5----------------------------7 <--> Gnd 7----------------------------4 <--> RTS 8----------------------------5 <--> CTS 6----------------------------6 <--> DSR 4----------------------------20 <--> DTR 1----------------------------8 <--> DCD 9----------------------------22 <--> RI !!!!!!!!!!!!!!!!!! T A K E C A R E ---> Users... !!!!!!!!!!!!!!!!! !!! All other type of NULL MODEM CABLE is susceptible of !!! !!! provoking some stops of communication between the programs !!! !!! using the serial driver STARCOMM.EXE v2.0 and above. The risk !!! !!! entirely rest on the nature of the used links (by the cable) !!! !!! between the communication control signals... !!! !!! If your cable is not suitable, do not use the options to activate!!! !!! any of the hand-shaking protocols RTS/CTS, DTR/DSR, RI, etc... !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Developers... !!!!!!!!!!!!!!!!!!!!!!!!!! !!! You could define some particular hard hand-shaking !!! !!! (following the developed instructions in STAR_REF.DOC ANNEX...). !!! !!! Using its personalized management of modem signals, your program !!! !!! won't be able to work without its cable to the particular !!! !!! pattern: you will have earned a good hardware KEY protection for !!! !!! your program... !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 19 ANNEX B: Types of UART chips on PC and compatibles This appendix present a fast summary on the types of UART, products by INTEL C° (tm) and compatible with the 8250, that was successively implemented on the range of IBM computers and compatibles. 8250 ......... First UART used on the first IBM PC. It is a slow controller: the accesses to the registers are faster than the treatments done by the 8250 ! It disposes of 7 registers and is "sold" in order to accept bauds until 56 Kilo-bauds. The receipt and transmit buffer are both made of only one byte. 8250A ........ It is a correction of 8250, with 1 register in addition: the scratchPad, that allows to mark the presence of the UART controller. 16450 ........ It is an improved version of 8250A: its internal treatments are fast enough in order to avoid some losses of time at the time of software accesses to the controller regiters. It doesn't permit however, in theory, to support more than a 56 kilo-bauds speed of transmission. 16C451 ....... It is the CMOS version of 16450 (i.e. 16450 with low electric energy needs). 16550 ........ First version of a new improved 16450: it should permit the activation of an internal buffer of 16 bytes, and the support of 256 kilo-bauds. A mistake in realization made it inoperative. Only some first PS/2 received this controller (quickly retired from INTEL C° !). It must NOT be used as a 16450 (i.e. forbid the activation of its FIFO mode using the /PF option of STARCOMM.EXE !). 16550A/AF/AFN. It is the first functional version of 16550 ! Its 16 bytes buffers do works and it support up to 256 Kilo-Bds. 16C551 ....... CMOS version of 16550AF. 16C552 ....... Implement 2 16C551 in the same electronic box. 82510 ........ It is a 16450 supplied with buffers of 4 bytes. It is used in some notepad. Then.......... It decorated how certain(s) competitor(s) of the INTEL business is attacking the production of 16550AFN type controllers, based on the utilization of 32 bytes in its internals buffers (this since mis-1990...). To follow !... To summarize, retain 3 generations in the evolution of this UART controller essentially (Universal Asynchronous Receiver & Transmiter) 8250A ........ Simple but slow UART, 16450 ........ Simple and fast UART, 16550AF ...... Fast UART, with 16 bytes buffers and reliable ! 20 ANNEX C: Why a "BIOS emulation" ? Why offering an option to emulate the BIOS interrupt 14h whereas STARCOMM.EXE seem already be (by nature) such an emulator ? Because the functions 1 (send) and 2 (receive) of the INT 14h filtered by STARCOMM could benefit from contributions of this driver (16550 UART FIFO buffers excepted) only with the OPENED ports of the driver. Indeed, STARCOMM redirects the calls to these functions for the closed serial ports on the original BIOS interrupt (it was a logical choice at the time of the initial program development !...). In order to benefit from the possible redistribution of some serial ports addresses, from the access to the ports 1 up to 8, from the time-out definitions, and from hardware (input/output) hand-shakings, even on STARCOMM CLOSED ports, it is therefore necessary to activate a special part of the driver code: its BIOS emulator of the original BIOS communication functions. Of course, the I/O serial ports buffers won't be used when accessing a closed port THROUGH the BIOS emulator (it is necessary and sufficient to OPEN the ports in order to fully benefit from STARCOMM contributions !) But this emulation permits to dispose of an improved BIOS (from the today available UART point of view) as soon as STARCOMM.EXE is installed on your machine with its BIOS emulator activated... This improved BIOS also guaranties a security on the used addresses in order to reach to the UART (it is not anymore the BIOS addresses specified by [40:00] to [40:06] that is used, but the driver addresses, well "hidden" in RAM !). It finally permits to enhance all PC compatible BIOS with the function 05h that doesn't normally exist, except on the PS/2... 21 ANNEX D: Files making SERIAL PORTS MANAGER v2.20 INFORME DOC...General informations on the product origin. SPECIFS DOC...General technical facts on the pack. REGISTER DOC...To register SERIAL PORTS MANAGER, send me your appreciations, or report some noted bugs. UPDATES DOC...What's new in this last release of S.P.M. ?... STARGUID DOC...The user guide for SERIAL PORTS MANAGER v2.20 STAR_REF DOC...The reference manual for programming by using STARCOM8.EXE, STARCOMM.EXE or SCLIB.OBJ. SETPILOT EXE..Small utility to install and setup STARCOMM.EXE STARCOMM EXE...Serial driver:it is the kernel of SERIAL PORTS MANAGER ! STARCOM8 EXE...Kernel of SERIAL PORTS MANAGER adapted to the management of 8 serial ports (STARCOMM can only drive up to 4 serial ports...). SETPORT COM...An utility developed (using C) in order to offer you a way to have a 'port by port' control on the installed driver in memory (whereas it works in its BIOS or DEVICE DRIVER mode). STARINTF PAS...Interface in order to use the driver services from the (C)Turbo Pascal. STARINTF C.....Interface in order to use the driver services from the (C)Turbo C. SCLIB OBJ..."Library" release of STARCOM8.EXE (8 ports). DEMO_LIB ASM...A simple demo. of how to use SCLIB.OBJ. TESTSTAR PAS...A demo. DEVELOPED in Turbo PASCAL to use STARCOMM in a multi-communication process. Require the procedures of STARINTF.PAS TESTSTAR EXE...Executable file of this demonstration ! TERMINAL C.....A simple TTY terminal based on the use of STARCOMM loaded as a DEVICE DRIVER: we reache the port by the means of the logical file (called "COMM:"). Require the procedures of STARINTF.C TERMINAL COM...Executable file of this demonstration ! REMOTE EXE...A small application allowing you to exploit a remote IBM PC/AT from the local computer. We could name it a "DOS terminal emulator"... MODEM DOC...Document containing informations on the procedures made to access modems, procedures contained in MODEM.PAS and MODEM.C. MODEM PAS...PASCAL procedures to access HAYES modems. MODEM C.....C procedures to access HAYES modems. TESTMODP PAS...Source of the demo. to use MODEM.PAS. TESTMODC C.....Source of the demo. to use MODEM.C. CONVERT DOC...Document for the procedures made to convert data. CONVERTA ASM...Simple procedures to make ASCII-transcoding: they CONVERTP PAS...permit to transfer any binary file even when using CONVERTC C.....the Xon/Xoff software hand-shaking...