CP/M

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

/ CP/M / CPM_CDROM.iso / simtel / sigm / vols000 / vol068 / unspool.doc < prev next >

Wrap

Text File | 1984-04-29 | 12.9 KB | 392 lines

Documentation for UNSPOOL Version 3.1 for CP/M 2.0 and up. AUTHOR: Gary P. Novosielski Rutherford, NJ (201) 935-4087 Evenings and weekends. INTRODUCTION: UNSPOOL (Ver 3.0) is a program to send a standard CP/M file such as a .PRN or .ASM file to the system's list or punch device, while still allowing almost all other system operations to take place. The file is transferred during periods when console is waiting for input. SYNTAX: UNSPOOL [d:]filename.ext [dev] or UNSPOOL dummy OFF [square brackets denote optional parameters] Where d: is an optional drive spec such as A: or B:. If not entered, the current default drive is assumed. filename.ext is the name of the CP.M file to be printed/punched. dev is the symbolic name of the output device to be used. Valid devices are LST and PUN. Note that the colon (:) usually present in these names is NOT entered. If not specified, the LST: device is assumed. OFF If OFF is specified instead of a device name, the operator will be offered the option of cancelling UNSPOOL if it is already running. dummy Because the word OFF is the second parameter, a filespec is still needed. A dummy name of "." will suffice as a place holder. Examples: UNSPOOL TEST.PRN will send the file TEST.PRN from the Revised 81-12-06 Page 1 of 6 _______________________________________________________________ Documentation for UNSPOOL Version 3.1 current default drive to the current LST: device. UNSPOOL A:TEST.PRN LST is exactly equivalent to the above, assuming drive A is the default drive. Note that the device name has no trailing colon. UNSPOOL B:ZINGER.HEX PUN will send the file ZINGER.HEX from the B drive to the current PUN: device regardless of which drive is currently the default. Note that the device is "PUN" not "PUN:". UNSPOOL . OFF UNSPOOL *.* OFF UNSPOOL OFF OFF all cause an operator prompt: "Do you want to cancel UNSPOOL?" A single "Y" or "N" (Yes or No) is accepted from the console as a response. Any other character is assumed to mean "No". UNSPOOL OFF causes the file "OFF. " to be sent to the list device. OPERATION: Upon loading, the program checks to see that the the BIOS vector table pointed to by the word at location 0001H is valid, i.e. is a table of JMP instructions containing at least 16 entries. If an error is detected, the program will display an error message on the console and attempt to warm-boot CP/M. If found, the BIOS vector table is copied into the program segment which will remain active during unspooling so that subsequent application programs running concurrently with UNSPOOL will still have access to the BIOS. This table is modified to trap attempts to warm boot the system, perform direct console input, or perform direct disk sector writes. Direct sector writes are not permitted (see notes) under UNSPOOL. Warmboot requests and direct console input are handled as described below. The address of the old BIOS vector table, the BDOS entry address, and the CCP return address (from the top of the stack on entry) are saved in memory. The "dev" parameter from the command line is checked. If not valid, an error message is typed and control returns to the CCP. If the "dev" parameter is the literal OFF, the program executes a BDOS funcion 0 (System Reset) and terminates. Revised 81-12-06 Page 2 of 6 _______________________________________________________________ Documentation for UNSPOOL Version 3.1 The file named in the command line is opened for input. If not present, the command is echoed to the console followed by a "?" and control returns to CCP. If the drive is not explicit, the current default drive number is recorded internally in case the default drive is changed while UNSPOOL is active. The current user number and IOBYTE values are checked and stored internally so that if the user number is changed, UNSPOOL will still be able to read the input file. If the device is changed (using STAT LST:=TTY: for example) unspool will continue to use the physical device in effect at the time the program was initiated. Any application programs will, however, use the new values of the user number and the new physical device assignments. If no errors were detected, the active program segment which monitors all calls to BDOS is relocated into high memory just below the CCP. This reduces the available user program area by 3 K: 4 pages for the UNSPOOL supervisor segment, and 8 pages for the CCP which is commonly overwritten by user program buffers. The BOOT and BDOS jumps in low memory are modified to protect the CCP and UNSPOOL supervisor segment. Control is then returned to the console. Normal CP/M operation will then be possible. Characters will be sent from the input file to the output device whenever the console is idle. Whenever an application program or the CCP requests console input using BDOS functions 1 or 10, or a direct call into the jump table at A(BOOT + 1) + 6, the supervisor segment intercepts these requests and checks to see if the console is idle. If it is, characters are transferred from the input file to the output device until the console becomes ready, i.e. a key is actually pressed. At that time the BDOS function or BIOS call is executed normally, and control returns to the application program. If a jump to BOOT is attempted, this is also intercepted by the UNSPOOL supervisor segment. The message "Unspooling in progress" is displayed on the console, and no actual boot takes place. Control is returned to the protected copy of the CCP instead. Before returning, a disk reset is performed and the default DMA address is reset to 0080H to simulate a true warm-boot as closely as possible. If warmboot is attempted using BDOS function 0, the program will prompt the operator with the option to cancel. If the response is "Y", warmboot is performed using BDOS function 0 as requested. Otherwise the request is handled as with normal warmboot, above. Revised 81-12-06 Page 3 of 6 _______________________________________________________________ Documentation for UNSPOOL Version 3.1 If a direct BIOS call to write a sector to disk is attempted, UNSPOOL will display the message "Invalid operation attempted under UNSPOOL. Program aborted." The application program will be terminated, but UNSPOOL will continue to run. (See Notes.) This restriction applies only to direct BIOS writes. All normal file-oriented (BDOS) reads and writes are fully supported under UNSPOOL. When the input file is completely transferred, or a 1AH end-of-file character is detected, the supervisor becomes inactive, and passes on previously intercepted requests immediately, without checking console status. The sole exception to this is that direct BIOS writes are still not permitted until the next warmboot. When the next warm-boot request is detected, the supervisor removes itself from memory by executing a true warm-boot, and informs the operator with the message "UNSPOOL completed.". NOTES: While UNSPOOL makes every effort to restore the values of the DMA address, USER number, IOBYTE, and default disk drive before returning control to the program, a hardware reset may leave these values in an undetermined state if unspooling was actually taking place at the time. When function 10, Read Console Buffer is used, UNSPOOL will transfer characters only until the first key is pressed. At that time, no characters will be transferred until the input line is completed by pressing a carriage return. UNSPOOL requires that the List Status function in the BIOS was properly implemented at system installation time. UNSPOOL will not send characters to the LST: device unless it recieves a ready condition from the List Status routine. If the PUN: device is used, no status check is provided for by CP/M, so a not-ready condition on the punch may cause the system to hang up if PUN was specified on the command line. See the CP/M Alteration Guide for a discussion of the BIOS List Status routine. Although the console is polled frequently during the unspooling of the file, some of the diskette operations may take a second or two to complete, for example when a new extent is opened. Since the console is not polled during this period, high speed typing may cause one or more characters to be lost. This effect will vary depending upon the program being run, the types of input reqests (character or line) it uses, and the relative locations on disk of the spool file and any files in use by the program. As a result, heads-down typing is not reccommended while UNSPOOL is running. Some experience with UNSPOOL will teach the user when caution is required. Revised 81-12-06 Page 4 of 6 _______________________________________________________________ Documentation for UNSPOOL Version 3.1 Although it would be possible to perform direct BIOS writes while unspool is active, (indeed this was permitted in earlier versions) this action is now trapped and prohibited. The reason this was deemed necessary is that some existing software, for example DU.COM, uses direct BIOS writes in a manner which could cause a major system crash if allowed under UNSPOOL. The problem arises when a program calls the BIOS directly (it is actually calling UNSPOOL's copy of the BIOS table) to select the drive, set the track and sector, and perform direct disk I/O without going through the normal CP/M file handling system. This causes no problem if the selecting, addressing, and I/O are all done together, but if a console input is done between the time the disk address is set and the call to read or write a sector, the disk address may no longer be valid. This could cause the sector to be written to the wrong disk address, or even over the directory. This is true because a request for console input is taken by UNSPOOL as an opportunity perform its own functions, which themselves include disk I/O. Although this problem could be eliminated by insuring that console input is not allowed to intervene between disk addressing and disk I/O, it is not in the author's power to rewrite all existing applications software. This better-safe-than-sorry trap was therefore included. Note that direct reads are NOT trapped, since they do not have the same potential for disaster, but still may be unreliable for the same reasons. It is therefore recommended that software using direct disk I/O not be run under UNSPOOL. Normal CP/M file-oriented (BDOS) reads and writes always re-select and re-address the disk before reading or writing a sector, so no similar problem exists in the vast majority of software which uses the normal CP/M file handling system. INSTALLATION: The source file is written for assembly with the MAC assembler. The .HEX file produced is LOADed to a .COM file and executed just as any normal program. Relocation is done at execution time as described above. If the assembly option EXPAND is set to TRUE, tab characters in the input file will be expanded to spaces with assumed tab stops at every eighth print position. This option should be set to FALSE if the printer driver or the printer itself can properly handle the tab character. If the option PHYSBS is set to TRUE, a backspace character will cause the tab expansion algorithm to recognize backspace characters and decrement the column count when a backspace is encountered in the input file. This option should be set to FALSE if backspace characters are ignored by the printer. Revised 81-12-06 Page 5 of 6 _______________________________________________________________ Documentation for UNSPOOL Version 3.1 All other control codes except carriage return are assumed to be non- printing, and are ignored by the algorithm. If tab expansion is included, the version number in the signon message will be followed by "/T". Gary Novosielski Revised 81-12-06 Page 6 of 6 _______________________________________________________________