Using the PX-8 with Asynchronous Communication Packages by Christopher Rhodes The PX-8 has built-in BIOS support for the RS-232-C port which is controlled by the 8251. These BIOS routines control all aspects of operation from setting the communication protocol to setting the address and size of the interrupt serviced input buffer. An alternative to BIOS calls is direct communication with the 8251. The article "Direct Communication with the 8251 Chip on the PX-8 Computer" (printed in the July 20 Mailbag) describes that procedure. This paper covers the use of the built-in BIOS calls for RS-232-C support and discusses the advantages and disadvantages of both methods. It includes recommendations for patching programs using either procedure. Using BIOS Calls The following BIOS calls are provided by the operating system: RSOPEN RSCLOSE RSIN RSINST RSOUT RSOUTST RSIOX These BIOS calls are used instead of the direct communication with the system UART normally performed by most machines. RSOPEN and RSCLOSE are responsible for the hardware and software initialization required before and after use of the RS-232-C port. Remember power must be supplied to the 8251 before it is used. The initialization is performed after the parameters chosen in CONFIG or those chosen by the general RS-232-C routine, RSIOX. RSIN and RSINST cover character input and input status, RSOUT and RSOUTST cover character output and output status. RSIOX can be used to accomplish any of the above individual calls and also can be used to determine the remaining chip status states such as parity, overrun, and framing errors. RSIOX is also used to configure the size and location of the buffers used by the 8251. Please refer to the PX-8 User's Manual for details. There is a one to one correspondence between the BIOS calls and calls you would normally do with direct I/O to the UART. BIOS Call Assembly Routine RSOPEN - General routine to initialize etc. RSCLOSE - Any clean up. Not normally required RSIN - IN A,(DATAPORT) RSINST - IN A,(STATPORT) AND RECRDYBIT RSOUT - OUT (DATAPORT),A RSOUTST - IN A,(STATPORT) AND TXRDYBIT RSIOX - Not normally supported except for other status information Program Patching RS-232-C support using the BIOS calls is no more difficult than direct I/O routines. In many ways your task is easier. Whenever you would do direct I/O to a UART, simply replace the code with a BIOS call. For example, to patch a modem program you would need routines to send and receive characters and to test the status of the chip prior to performing these operations. The following code would be used: PUSH BC PUSH DE PUSH HL CALL RSIN ; or RSOUT or RSINST or RSOUTST POP HL POP DE POP BC RET Remember that the BIOS uses many of the registers, so if your program assumes a register will be unaffected by a simple IN or OUT to a port, it may not work properly unless you preserve the environment across the BIOS call. The BIOS call is also slower than DIRECT I/O to a port. Any programs basing timing loops on the port access time may need to be modified to account for the time difference. Which to Use There are advantages to both DIRECT I/O and BIOS calls. At the outset, realize that the Geneva cannot be used if the only things a program allows you to specify are the data and status ports and which bits to check. As discussed in "Direct Communication with the 8251," there are many other concerns; such as memory locations affected by interrupt routines, power to the 8251, etc.; which must also be performed before simple IN and OUT routines to the 8251 will work. Such limitations determine your ability to modify the source code directly or to write your own drivers and overlay or include them in the program. The system BIOS calls are recommended for several reasons. They have already been written and debugged, and are available for your use. They allow all the necessary control without any additional coding. Since the input is being handled by interrupt, you can eliminate many data loss problems. You may specify your own buffer length and location. The BIOS calls support several types of handshaking such as XON/XOFF. One disadvantage of the BIOS calls is the rather excessive overhead incurred, especially if your only need is to get data to and from the port. However, in many applications this will not be a concern, and in fact, there will be times when your application will run more quickly with the system calls. The direct I/O offers the advantage of laying the code and operation of the chip before you. It leaves no question of what the BIOS may be doing. However, this simplicity is offset by the tricks you must perform to fool the BIOS into letting you take command of the chip. The pitfalls are numerous. An example using the MODEM program may prove useful. I patched one version of MODEM724 to use BIOS calls and patched one to perform direct I/O to the 8251. I had initially expected the direct I/O version to produce the better results. The outcome was quite surprising. The direct I/O version could not be made to run much faster than about 2400 baud for file transfer. The overhead of the program and the limited speed of the Z80 led to dropped characters and numerous retry conditions at speeds above 2400 baud. The BIOS version operated reliably at speeds up to and including 19.2K baud. I did not clock the overall transfer time, but doubt that it was significantly different. The BIOS version seemed faster and the ability to run at all the supported baud rates is desirable. I think the interrupt buffered input is the reason the BIOS version ran at the higher speeds. ------------------------------------------------------------ I recommend you use the BIOS calls whenever possible and use the DIRECT I/O only as a last resort. There is no coding advantage to using DIRECT I/O because all the special Geneva support will have to be included in special drivers that will have to be written and added to source code or overlayed on executable code. * * * * *