B1 Diskette Information Last edit: 28-Jan-2015 cjl Type: OS/8 Format MDC8 Diskette Purpose: Source Files for P?S/8 as of 25-Feb-1988 Note: Some of the date information below has been modified to correct for factual errors or design limitations of OS/8. Authoritative date information has been obtained from reliable sources where applicable. As required, discrepancies regarding specific files and additional information about certain files will be provided. Directory Listing: ____________________________________________________________________________________ 25-FEB-88 RXBOOT.PA 0007 8 08-SEP-77 RXBUT0.PA 0017 3 08-SEP-77 RXBUT1.PA 0022 3 08-SEP-77 RXINIT.PA 0025 13 08-SEP-77 IPBOOT.PA 0042 4 24-NOV-76 XEQUA .TE 0046 2 09-AUG-79 DTAGEN.PA 0050 8 05-APR-86 IPBGEN.PA 0060 4 06-JUL-80 COMGEN.DU 0064 15 16-FEB-88 DTAGEN.DU 0103 4 06-OCT-87 DSUGEN.DU 0107 4 23-FEB-88 RKAGEN.DU 0113 5 06-OCT-87 RXAGEN.DU 0120 4 06-OCT-87 SUP4K .PA 0124 19 15-SEP-80 SUP8K .PA 0147 28 15-SEP-80 Z4K .PA 0203 1 08-APR-87 Z8K .PA 0204 2 08-APR-87 Z12K .PA 0206 2 08-APR-87 BLK400.PA 0210 1 21-APR-86 SYSHND.PA 0211 8 21-APR-86 DTAHND.PA 0221 17 12-MAR-86 LTAHND.PA 0242 19 17-APR-86 LINHND.PA 0265 19 17-APR-86 L8MHND.PA 0310 14 12-NOV-83 DL8HND.PA 0326 35 12-NOV-83 DOL8 .PA 0371 89 23-JUN-86 DSUHND.PA 0522 17 22-APR-86 RKAHND.PA 0543 35 01-APR-86 RXAHND.PA 0606 48 17-DEC-86 FLPHND.PA 0666 14 23-FEB-88 FIXUP .PA 0704 26 04-SEP-75 BSAVE .PA 0736 53 05-JAN-86 SET .PA 1023 138 05-JAN-86 CORE .PA 1235 34 25-SEP-85 DATE .PA 1277 57 08-APR-87 CONSOL.PA 1370 193 17-DEC-86 KL8 .PA 1671 132 08-APR-87 KL8PCH.PA 2075 44 08-APR-87 VT8E .PA 2151 150 17-DEC-86 ALLCAT.PA 2377 24 07-OCT-85 PRINT .PA 2427 118 03-JUL-87 FILMAN.PA 2615 289 06-OCT-87 ODT .PA 3256 139 05-JAN-86 DUMP .PA 3471 72 12-JAN-87 3601 159 159 FREE BLOCKS ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ File Information RXBOOT.PA Source file for RX8B/DSD-210 bootstrap program capable of a safer alternative bootstrap as well as DEC compatibility by changing one word. Due to poor design of both the bootstrap method and OS/8 in general, OS/8 will always write out memory during a bootup which is inherently risky. Since the DSD-210 supports write-protect, the initial phase of the bootup can be protected; however, OS/8 will halt the machine because of the write-protect which will confuse most users [pressing continue should work correctly if there were no unexpected errors]. To avoid this situation, an alternate bootstrap method can be used that assumes a safe operating system loader has been installed on track 0 of the bootable diskette. DEC never uses track 0 for a variety of reasons that are of no concern to the average user. The safe loader is not the subject of this program; it merely assumes such a program exists; once in control, the safer program can perform a reliable bootup that could start OS/8 without a write attempt or at least a graceful startup without a system halt. P?S/8 would have to be compatible with this scheme as well, which is easily achieved; however, P?S/8 doesn't attempt to write during the bootup operation; the standard DEC RX8E bootstrap is sufficient to start P?S/8 with write-protect set when used on the DSD-210. [Note: Modifying the DEC RX01 drive to support write-protect still requires the use of foil tabs on the diskette media; this is inconvenient as controlled writing from user commands would require the mechanical opposite tab presence. The DSD-210 drive supports front-panel protect switches for all media allowing safer bootup; flipping the protect switch restores normal operation.] [Note: Track 0 can always be restored to any properly formatted diskette to satisfy perceived need for standard contents. The DSD-210 drive supports diskette formatting without concern for prior contents; certain IBM 3740 equipment requires validation of track 0 to allow reformatting without additional procedures; this was taken too literally by DEC and became moot when they instead merely advised all users to purchase pre-formatted media.] Note: File date corrected. Full file name: RXBOOT.PAL. RXBUT0.PA Source file for the shortest program capable of supporting the safer bootstrap on track 0 of drive 0. By abandoning DEC compatibility altogether, this is another advantage. Note: File date corrected. Full file name: RXBUT0.PAL. RXBUT1.PA Source file for the shortest program capable of booting the DEC-compatible scheme [using track 1 of drive 0]. By eliminating support for retrying drive 1, the program is far more suitable for manual entry when performing a cold bootstrap. [Note: May require minor changes to boot the more recent P?S/8 and OS/8 system device handlers; this program was designed during the era when it was assumed a viable handler could be implemented without the need for extended memory; since that time, both OS/8 and P?S/8 have abandoned a minimal system. In the case of P?S/8 superior performance and error recovery while OS/8 merely gains functionality due to its inherently weak design. [Note: The 8K OS/8 handler has the dubious distinction of being the only handler first officially released then officially withdrawn due to inherent unreliability and tendancy to corrupt data during write operations.] Note: File date corrected. Full file name: RXBUT1.PAL. RXINIT.PA Source file for the track 0 code that implements the safer bootstrap mechanism. Also includes the program to write this code out and a full-length more conventional bootstrap to support it in a manner analgous to DEC's over methodology. [See the RXBUT0 program as an example of a much shorter bootstrap.] Note: File date corrected. Full file name: RXINIT.PAL. IPBOOT.PA Source file for InterProcessor Buffer [IPB] bootstrap program. Note: File date corrected. Full name: IPBOOT.PAL. XEQUA .TE Source file for a custom TECO macro used to maintain integrity of external symbols in various P?S/8 components. Many P?S/8 source files execute in specific memory space to reference components of the P?S/8 keyboard monitor and imbedded editor or other structures. It is necessary that specific equated symbols match the definitions obtainable from the main monitor source file, etc. A specific symbol table file is created as a derivative of the assembly of the main source file; this is then used for syncing up all dependent programs. The section of the source file that requires reconciliation with the main assembly is delineated by special comments that start with "//". As such, all prior commentary in the file must avoid this. All equate statements within the section must be simple octal constant values; all symbols must be defined in the designated symbol table file derived from the assembly of PQSMON.PAL. Error messages will be issued if attempts are made to define symbols not found in the designated symbol table file. The macro definitions within this file are likely highly dependent on specific implementations of TECO. Future versions should be written in a more generic implementation such as TECOC. [Note: TECO for the P?S/8 SHELL environment will likely conform to TECOC; many older TECO implementations such as various versions for OS/8 are known to be incompatible for various quirky reasons. Since the P?S/8 SHELL is oriented around larger memory configurations for increased performance, TECO for this system will strive for maximum compatibility as opposed to the expediency associated with older implementations. Any development work on this macro should increase the level of messages issued during its operation. It is recommended that there be some minimal output after each symbol is located; otherwise, long periods of time pass without any apparent progress, etc. The current design uses a hard-wired name for the symbol table file. This allows future implementations to create alternate sources for the definitions; SHELL-conforming programs will tend to require new global definitions not currently defined; the main keyboard monitor file may be inappropriate to source these values. Alternately, a different macro can be created to handle that analogous situation at a future time. Note: File date corrected. Full name: XEQUA.TEC. DTAGEN.PA Source file for the TC01/TC08 system device handler loader to be used when generating so-called "alien" P?S/8 systems. P?S/8 is generally created on a system that includes the intended target hardware for the system device; however, in some circumstances this is not feasible. There are several steps used to create a functioning system: 1) The binary files for the initial P?S/8 starter system intended for the target system are loaded under an existent P?S/8 system which then makes the current system device handler available to create an image of the target system on media compatible with the present P?S/8 system. This is generally convenient when the TC01/TC08 DECtape system is used as the host system device. The system generation routines use a special setting of the front panel switches to indicate the use of the resident P?S/8 system device handler to write out the image of the entire new system instead of attempting to use the intended target system device handler [which is not available]. 2) Subsequently, external means is eventually used to transfer the image created on the TC01/TC08 DECtape to the intended target hardware. For example, if creating a TC12 LINCtape system for the PDP-12, the DECtape image can be brought to the target system where the TC12F utility is available to convert the DECtape to LINCtape. The particulars vary according to the specific circumstances; the main issue is to run under an existing P?S/8 system that can write on media for the current system to create the image of the system intended for the "alien" system device. In some circumstances, the binary for system generation is not loaded into memory by an appropriate operating system, yet the TC01/TC08 hardware is available. By using this short additional program, the system device handler of the TC01/TC08 system can be loaded into 07600-07777 before starting the system generation [with the special switch register setting used to prevent attempting to use the target system device handler]. This program requires a 16K machine instead of the normal 12K used to create a starter system when the target hardware is available. Future development of the system generation routines should include the ability to load in a designated P?S/8 non-system handler to write out the image of the target system on a different device if this situation applies, in which case this program will be obsolete. Full file name: DTAGEN.PAL. IPBGEN.PA Source file for the InterProcessor Buffer [IPB] system device handler loader to be used when generating so-called "alien" P?S/8 systems. P?S/8 is generally created on a system that includes the intended target hardware for the system device; however, in some circumstances this is not feasible. There are several steps used to create a functioning system: 1) The binary files for the initial P?S/8 starter system intended for the target system are loaded under an existent P?S/8 system which then makes the current system device handler available to create an image of the target system on media compatible with the present P?S/8 system. This is generally convenient when the IPB system is used as the host system device. The system generation routines use a special setting of the front panel switches to indicate the use of the resident P?S/8 system device handler to write out the image of the entire new system instead of attempting to use the intended target system device handler [which is not available]. 2) Subsequently, external means is eventually used to transfer the image created on the IPB system to the intended target hardware. For example, if creating a TC12 LINCtape system for the PDP-12 and the IPB system is running on LINC-8 LINCtapes on the server side, the TC12 LINCtape can be created directly to be brought to the target PDP-12 system. The particulars vary according to the specific circumstances; the main issue is to run under an existing P?S/8 system that can write on media for the current system to create the image of the system intended for the "alien" system device. In some circumstances, the binary for system generation is not loaded into memory by an appropriate operating system, yet the IPB system hardware is available. By using this short additional program, the system device handler of the IPB system can be loaded into 07600-07777 before starting the system generation [with the special switch register setting used to prevent attempting to use the target system device handler]. This program requires a 16K machine instead of the normal 12K used to create a starter system when the target hardware is available. Future development of the system generation routines should include the ability to load in a designated P?S/8 non-system handler to write out the image of the target system on a different device if this situation applies, in which case this program will be obsolete. Note: File date corrected. Full name: IPBGEN.PAL. COMGEN.DU Command file for use with the P?S/8 system program DUMP. It is used to update the P?S/8 starter system after creation from the initial memory load which is written out creating a bootable system. Only the fundamental system programs are available at that point including DUMP. DUMP allows command input files such as COMGEN [generally in the form of TFS files named CMGEN1 and CMGEN2] to transfer groups of contiguous blocks from a designated OS/8 non-system device compatible with the P?S/8 system device handler and defined as unit 1 in P?S/8 terms such as DECtape unit 1 relative to a P?S/8 system created for the TC01/TC08 DECtape controller. The P?S/8 system is booted as drive 0 and the OS/8 non-system device [which contains saved images of additional P?S/8 binary programs in designated records] is accessed as drive unit 1. [The contents of the non-system device was created in OS/8 using OS/8 BATCH control files to enforce specific binary image placement; DUMP usage depends on the accuracy of the file placement on the device. The particulars of the COMGEN file are determined for each P?S/8 release in a generic manner for any variant system device associated with any particular release. Pragmatic DUMP commands transfer the images section by section and P?S/8 blocks are updated with the intended contents. Additionally, various structures are updated by ZApping the P?S?8 system directory to reflect the addition of the entries for the added programs. The non-system handler table is also updated to reflect images of non-system handlers also transferred from the OS/8 unit 1 device and saved in designated records. Once the DUMP operation has finished, the P?S/8 system is complete to the extent of all common system programs; additional system programs considered relevant to the particular system device must be updated by additional DUMP command files or other means. Once all system programs are present, the TFS and user directory structures will be updated. Additional files associated with a complete release can then be added to the completed system [which can be deleted by the user if desired]. Full file name: COMGEN.DUMP. DTAGEN.DU Command file for use with the P?S/8 system program DUMP. It is used to update the P?S/8 starter system after all common system programs have already been added. System programs are added deemed useful for P?S/8 systems based on the TC01/TC08 DECtape controller and TU55/TU56 drives. Once the DUMP operation has finished, the P?S/8 system is complete and ready for release. The TFS directory has been updated to reflect available user file space consistent with available storage on the system device. Additional TFS files associated with a complete release should be added [which the user can delete if desired]. Full file name: DTAGEN.DUMP. DSUGEN.DU Command file for use with the P?S/8 system program DUMP. It is used to update the P?S/8 starter system after all common system programs have already been added. System programs are added deemed useful for P?S/8 systems based on the DSD-240/Western Dynex disk system with removable cartridge [DS Upper] or fixed disk [DS Lower] or the MDC8 HD diskette system [FLP]. Once the DUMP operation has finished, the P?S/8 system is complete and ready for release. The TFS directory has been updated to reflect available user file space consistent with available storage on the system device. Additional TFS files associated with a complete release should be added [which the user can delete if desired]. Full file name: DSUGEN.DUMP. RKAGEN.DU Command file for use with the P?S/8 system program DUMP. It is used to update the P?S/8 starter system after all common system programs have already been added. System programs are added deemed useful for P?S/8 systems based on the RK8E/RK05 disk system or the PDP-12 TC12 LINCtape controller with TU55/TU56 drives. Once the DUMP operation has finished, the P?S/8 system is complete and ready for release. The TFS directory has been updated to reflect available user file space consistent with available storage on the system device. Additional TFS files associated with a complete release should be added [which the user can delete if desired]. Full file name: RKAGEN.DUMP. RXAGEN.DU Command file for use with the P?S/8 system program DUMP. It is used to update the P?S/8 starter system after all common system programs have already been added. System programs are added deemed useful for P?S/8 systems based on the RX01/RX02/RX03/DSD-210/DSD-440 in single density mode. Once the DUMP operation has finished, the P?S/8 system is complete and ready for release. The TFS directory has been updated to reflect available user file space consistent with available storage on the system device. Additional TFS files associated with a complete release should be added [which the user can delete if desired]. Full file name: RXAGEN.DUMP. SUP4K .PA Source file for the InterProcessor Buffer [IPB] Server program for use on 4K systems. The program runs under P?S/8 as implemented on the local system; the system device handler is called to read or write blocks as required to honor the request from the other side of the IPB. [Note: Device handlers have been written to support P?S/8 and OS/8 running on the client side of the IPB; the server cannot distinguish what software is requesting the service as it is carried out at the lowest level of transfer protocol.] Before operating the IPB from the client side, the appropriate storage media must be mounted on the server side; in general, this will be images of data unrelated to the local system written to compatible media; most importantly, the local system bootstrap device must be replaced by the appropriate media as required by the handler on the client side of the IPB. The program was designed to run on a 4K LINC-8 system running P?S/8 configured for the modified LINC-8 on 128 12-bit words/block LINCtapes mounted on LINCtape drive units 0 and 1; the system LINCtape is replaced by a LINCtape containing an image of the device as required on the client side of the IPB. Due to the minimal nature of the support system configuration, the program does not issue messages of any kind; a bare-bones approach is taken to maximize the number of blocks that can be read or written at any time to increase overall throughput. [Note: On a more capable configuration, an interrupt-driven version of the support program could be written; data blocks could be read in anticipation of need or other forms of caching can be performed. However, due to the minimal nature of LINCtape hardware as implemented on the LINC-8, this is not recommended.] No specific dependency on LINC-8 hardware exists except for a custom frill feature that includes a LINC-8-oriented light chaser null job executed while waiting for transfer requests from the client program on the other side of the IPB. [Note: Certain instructions will have to be removed/modified if execution of these instructions on systems other than the LINC-8 has unexpected effect. The only actual requirement is certain IOT instructions not change the AC.] The program supports all eight logical units as defined by the current P?S/8 system device handler; however, on the LINC-8, this generally means that all odd logical units are handled as unit 1 and all even logical units are handled as 0. This is a known restriction of the implementation of the P?S/8 system device handler for the modified LINC-8. Due to lack of testing facility, no attempt was ever made to confirm if there is any reasonable way around this problem; the few software systems ever written for an extended configuration always accessed extended LINCtape drives known to exist; there is apparently a hardware deficiency when accessing non-existent additional drives. It is also known that an apparent implementation quirk causes extended LINCtape drives to be added out of order. [While the first two drives are 0 and 1, the second dual transport selects as drives 4 and 5. Since so few systems were ever implemented with more than the first two drives, this was never corrected; the few software systems that ever supported these drives acknowledged them as units 4 and 5; no attempt was ever made to access the other four drives as it would cause the LINCtape controller to hang. It is conceivable that more sophisticated software might have detected this problem; however, the only known software was written in 100% LINC coding. As such, the software depended on the standard LINC-8 trap emulator used with such systems [PROGOFOP] which was never fully tested on configurations with more than the first dual LINCtape transport. Since all IPB and P?S/8 software is written completely in PDP-8 code [the LINCtape controller is actually a PDP-8 peripheral; tape operations of the LINC processor are trapped and emulated], any attempt at supporting additional logical units must be researched as to how to solve this problem; due to the constraints of tight coding, the P?S/8 system device handler for the modified LINC-8 is incapable of solving this problem [assuming it is solvable at all]. A future version of this program could be made to work with a P?S/8 non-system handler perhaps better able to deal with this consideration. This would allow the IPB protocol to be made more robust in terms of asking for data requests outside of the current configuration. The present version of all IBP-related software, as used in this specific configuration, assumes limiting the configuration to logical units 0 and 1 only. When operating the IPB server program on more capable systems such as TC01/TC08 DECtape, it is possible to support all logical units completely. [Note: When the server program is run on the other side of the IPB using some other device available on that system, the LINC-8 can run P?S/8 for the IBP; in this configuration, the LINC-8 supports all eight logical units; the LINCtape drives are available for other functions such as non-system LINCtape or DECtape handlers as used in utility programs; the P?S/8 non-system LINCtape handler does not require the hardware modifications; the DECtape handler requires a special handler [or utility program] to read or write DECtapes on the modified LINC-8. These programs can be run without the nuisance of having to be run from P?S/8 LINCtapes on the LINC-8; this makes the process of tape conversion on the LINC-8 easier from an operational standpoint; both drives are freely available to the program.] [Note: An unmodifed LINC-8 with IPB can run P?S/8 for the IPB as long as the support program is run on the server end. Non-system handlers can be used to read or write LINCtapes. However, the hardware modifications are far easier to accomplish than constructing the IPB, which also makes the machine dependent on the system on the other side of the IPB for all system-related functions. A more modern approach to such a system would be to implement a local storage device connected to the LINC-8 negative buss. The IPB approach is the only one available to the LINC-8 due to the inability to support DMA devices coupled with the small memory size. The largest practical LINC-8 is 8K; this allows few PDP-8 software options to the LINC-8; OS/8 cannot be run on an 8K LINC-8 unless the machine is either modified or a peripheral such as the IPB is available. P?S/8 can run on an 8K unmodified LINC-8 using an alternate system device handler designed to require an extended memory system device extension.] For systems with additional devices, the logical units can be mapped to other hardware devices such as logical partitions of a larger hard disk, etc. The program is easily modified as necessary to take advantage of available hardware. For systems with 8K or more, the 8K version of this program [SUP8K] is capable of slightly better throughput on calls for a larger number of blocks. Note: File date corrected. Full file name: SUP4K.PAL. SUP8K .PA Source file for the InterProcessor Buffer [IPB] Server program for use on systems with at least 8K. All matters unrelated to memory size are handled in the same manner as the 4K version. This verion of the program includes an internal copy of the then-current P?S/8 non-system DECtape handler for the TC01/TC08 DECtape. As such, it supports all 8 logical device units on the client side of the IPB. The program is easily modified to support alternative storage devices; a more elaborate version of the server can be created to take advantage of a real-time environment such as disk caching, etc. Note: File date corrected. Full file name: SUP8K.PAL. Z4K .PA Source file used to clear all user memory in field 0 [00000-07577]. This file is used when creating all P?S/8 core images from OS/8 to cause all unused memory locations to be 0000 which can aid in the debugging of P?S/8 components. Additionally, this helps standardize core images as used to make the OS/8 non-system device that holds all program images as used by P?S/8 DUMP to update the P?S/8 starter system to contain additional system programs. Note: This file is needed because OS/8 ABSLDR.SV has no memory clear options; P?S/8 BIN can set all of user memory to either 0000 or 7402 with a single command-line option. Full file name: Z4K.PAL. Z8K .PA Source file used to clear all user memory in field 0 [00000-07577] and 1 [10000-17577]. [Note: OS/8 limits loading into x7600-x7777 for any field x; generation of P?S/8 must honor the loading restrictions of any possible loading environment despite the more flexible loading rules of P?S/8 itself which is similar to the paper-tape binary loading restrictions.] Certain P?S/8 programs require 8K to create the image of the program and various overlays [which are loaded into field 0 as required during program execution]. All other considerations of the Z4K program apply. Full file name: Z8K.PAL. Z12K .PA Source file used to clear all user memory in field 0 [00000-07577], field 1 [10000-17577] and field 2 [20000-27577]. [Note: OS/8 limits loading into x7600-x7777 for any field x; generation of P?S/8 must honor the loading restrictions of any possible loading environment despite the more flexible loading rules of P?S/8 itself which is similar to the paper-tape binary loading restrictions.] Certain P?S/8 programs require 12K to create the image of the program and various overlays [which are loaded into field 0 as required during program execution]. All other considerations of the Z4K program apply. Full file name: Z12K.PAL. BLK400.PA Source file used to customize assembly of various LINCtape-oriented utilities that must be used to access standard LINCtapes [256 12-bit words/block] instead of PDP-8-oriented LINCtapes [128 12-bit words/block]. All of the various utilities default to 128 word support using conditional assembly. The BLK400 file allows the variant assembly without modifying the source files. Full file name: BLK400.PAL. SYSHND.PA Source file for the SYSx: [where x is the logical unit] non-system handler to allow programs [such as P?S/8 BLKCPY] access to the system device. In essence, the SYS handler acts as an intermediary between the system device handler of the P?S?8 system and the non-system handler environment to allow a program designed to load non-system handlers to access the system device handler logical units without any special-case handling. [Note: The calling sequence for the system device handler is incompatible with that of the non-system handlers as a fundamental design concept.] Since the system device handler can only return to the caller on successful completion of the call, it is not possible for a call to the SYS handler to ever fail as presently designed. Note: This is a stop-gap measure that will radically modified as part of a major redesign of P?S/8 non-system handlers for various design issues that were not under consideration at the time of the original implementation. [The P?S/8 SHELL overlay is currently being designed on various levels. Interaction between the area of a device that is both accessible from the basic P?S/8 system and the SHELL overlay will change the notion of a SYS handler; as such, it is possible it could cease to exist in the present form. Many issues exist such as exactly how much of the area potentially accessible by the SYS handler needs to have access limited for a variety of reasons, etc.] The file also contains the NULx: [where x is the logical unit] non-system handler. The NUL handler is essentially a read-only handler; any attempt to use it returns with the user buffer completely filled with 0000 words. Of special note is this is also true of write calls; the user buffer is not merely ignored, it is filled with 0000 words. This is done to allow programs such as BLKCPY, which may have complete data verification enabled, to be able to complete the device check without any false comparison errors. [Note: The NUL handler behavior is incompatible with any theoretical caching schemes as the write function destroys the data. Any program depending on the write buffer to be available again for reading will not work with the NUL handler as defined.] As with the SYS handler, the NUL handler is also subject to radical change once further work on the P?S/8 SHELL is accomplished. Note: All P?S/8 non-system handlers are being upgraded to a new calling convention involving double-precision block numbers and special handler-dependent features. Full file name: SYSHND.PAL. DTAHND.PA Source file for the non-system device handler for the TC01/TC08 DECtape controller and TU55/TU56 DECtape drives. This handler conforms with the description of P?S/8 non-system device handlers as defined for P?S/8 Version 8Z. Certain issues have come up since the writing of this program that will be important to future releases. [Some of the issues raised here apply to most if not all non-system handlers.] 1) The block argument to non-system handlers was defined as a single-precision value; thus, valid arguments were limited to the range of 0000-7777 only. While this is more than adequate for devices such as DECtapes, LINCtapes and RX-series diskettes, larger devices cannot be accommodated such as RK8E/RK05 dismountable disk cartridges, the DSD-240/Western Dynex fixed/removable cartridge disk system, the MDC8 SCSI host adapter, controller and hard disks, etc. As such, the next release of P?S/8 will change the block argument to a double-precision value in the form of a two word sequence passed low-order first; this will have the least impact on existing code where the 12-bit block argument is passed as the last parameter. 2) Certain "impossible" block number arguments will be created for special functions to be defined later. They will all be in the form of 7777 [low-order], xxxx [high-order] where certain xxxx values will be defined; all other values will be considered illegal. [Note: The largest allowed value of a logical block will be limited to 77777700 or so. This will limit the size of the largest allowed single logical unit accessible with any handler to over 16 million blocks of 128 words/block; by comparison, the largest storage allowed in OS/8 for any one device is 2048 times as small. The entire range of a complete non-system device handler is eight times this or approximately 32 GB [where one byte is six bits]. For example, a DECtape handler can be queried as to the size of the current DECtape mounted [if available]. Values are determined by the expected error return on calls for normally impossible block arguments that are used for this purpose. The value returned in the AC on the error return [the successful return is impossible] will be the size of the currently mounted DECtape. Rational values include: a) 2702 [standard DECtape], b) 3300 [extended length DECtape, c) 0000 [drive not ready]. This can be useful to a P?S/8 SHELL program to be able to adjust the number of empty blocks in the directory on the current DECtape. Not every device will support every special call; a standard value of 7777 will be used to return a value for any special call not supported within this handler. Handler particulars such as current status, loading information, version and revision can be defined in future releases to allow particular programs to more properly communicate with handlers as necessary. Handlers capable of certain protected operations may require special calls to enable certain features ordinarily inhibited [such as calls to write on block 0 without data validation]. 3) The search algorithm used in this handler is limited to locating blocks less than block 4000; while this is adequate for any physical DECtape media, the SIMH simulator has been modified to accommodate "phantom" DECtapes up to as many as 4096 blocks. Alternate algorithms can handle blocks up to at least block 7775. [Note: The modified SIMH simulator allows up to block 7777; however, limitations of the search algorithm may make it impossible to access blocks 7776-7777 due to the need to support the two-block undershoot factor associated with all DECtapes searching in reverse.] As such, the alternate algorithm will likely be used on future releases to support the complete simulation. [Note: The slurp loader for TC01/TC08 DECtape also uses the same search algorithm. As such, the virtual loader should be used if attempting to load a file located above block 3776. The P?S/8 system device handler for TC01/TC08 uses the extended algorithm capable of accessing block 7775.] 4) The handler needs to check initial drive status to avoid hanging in an infinite loop. Additionally, no check is made for impossible block numbers; the tape will loop endlessly searching one end of the tape to the other then reversing direction, etc. By adding in an initial status check, an error return can be made if the drive is off-line; by including a call to enable simulated larger block numbers, the full capability of the SIMH simulator can be implemented while otherwise protecting against applications attempting to ask for blocks slightly too high compared to the physical end of the tape. Full file name: DTAHND.PAL. LTAHND.PA Source file for the non-system device handler for the TC12 LINCtape controller and TU55/TU56 LINCtape drives. This handler conforms with the description of P?S/8 non-system device handlers as defined for P?S/8 Version 8Z. Certain issues have come up since the writing of this program that will be important to future releases; this is discussed in some detail in the description of the non-system handler for the TC01/TC08 DECtape controller and TU55/TU56 DECtape drives. Note: This handler cannot overcome the automatic reverse direction initial search of the TC12 controller; as such, no record-keeping is performed with respect to the last transferred block. Future releases of this handler may be able to overcome this limitation. Full file name: LTAHND.PAL. LINHND.PA Source file for the non-system device handler for the [unmodified] LINC-8 LINCtape controller and LINCtape drives. This handler conforms with the description of P?S/8 non-system device handlers as defined for P?S/8 Version 8Z. Certain issues have come up since the writing of this program that will be important to future releases; this is discussed in some detail in the description of the non-system handler for the TC01/TC08 DECtape controller and TU55/TU56 DECtape drives. Note: This handler was written to fit into a single page; as such, certain compromises were made that will be overcome in a future release as additional features are added: 1) Lack of proper retries. [A two-page handler need not be compromised as this will be required to implement the additional features required in future releases. On balance, a two-page handler that is more robust is a better compromise.] 2) Latest searched block is ignorant of drive unit change. This can easily be corrected using the method found in other handlers with similar requirements. Note: LINC-8 LINCtape handlers cannot accommodate LINCtapes of differing lengths. The tape controller cannot inform the handler the final data word has been detected. The tape blocksize must be consistent; as such, the handler only reads or writes the standard length tape. [Note: PDP-12 handlers can support an optional extra word per block because the transfer is performed via automatic DMA; the endangered word is saved before the transfer and restored afterwards.] Full file name: LINHND.PAL. L8MHND.PA Source file for the non-system device handler for the modified LINC-8 LINCtape controller and LINCtape drives. This handler conforms with the description of P?S/8 non-system device handlers as defined for P?S/8 Version 8Z. Certain issues have come up since the writing of this program that will be important to future releases; this is discussed in some detail in the description of the non-system handler for the TC01/TC08 DECtape controller and TU55/TU56 DECtape drives. This handler currently fits in a single page. Future releases may require an additional page to implement new features. Note: LINC-8 LINCtape handlers cannot accommodate LINCtapes of differing lengths. The tape controller cannot inform the handler the final data word has been detected. The tape blocksize must be consistent; as such, the handler only reads or writes the standard length tape. [Note: PDP-12 handlers can support an optional extra word per block because the transfer is performed via automatic DMA; the endangered word is saved before the transfer and restored afterwards.] Full file name: L8MHND.PAL. DL8HND.PA Source file for the non-system device handler for DECtape on the modified LINC-8 LINCtape controller and LINCtape drives. This handler conforms with the description of P?S/8 non-system device handlers as defined for P?S/8 Version 8Z. Certain issues have come up since the writing of this program that will be important to future releases; this is discussed in some detail in the description of the non-system handler for the TC01/TC08 DECtape controller and TU55/TU56 DECtape drives. This handler currently fits in three pages. Future releases may require an additional page to implement new features. Full file name: DL8HND.PAL. DOL8 .PA Source file for an early utility used to transfer files between DECtapes and LINCtapes on the modified LINC-8. The program is compatible with P?S/8 and uses P?S/8 command-line option switches to modify the configuration to take advantage of available memory. The additional memory allows larger read/write buffers to increase throughput on more capable configurations. An earlier utility called SYSCPY was used as the basis for the user interface to specify copying parameters; SYSCPY used the P?S/8 system device handler for all data transfers. SYSCPY was replaced by BLKCPY which is a more comprehensive program that uses P?S/8 non-system device handlers and supports additional features. The DECtape on Linc-8 [DOL8] utility represents a transitional phase during progression of the SYSCPY program into BLKCPY; internal device-handling subroutines are used for both LINCtape and DECtape functions with no reliance on the P?S/8 system device handler. This allowed the program to run from a modified LINC-8 running P?S/8 on a different device such as the IPB system freeing both tape drives for use with the utility program instead of directly supporting P?S/8. [Note: At the time of writing DOL8, P?S/8 had not been developed to the point of supporting fully relocatable [both page and field] non-system device handlers; the only level of compatibility with future P?S/8 releases was the notion of the indirect argument list passed via an inline pointer to the list. As of this writing, this specification is changing to support double-precision block numbers allowing much larger devices and device-specific special functions as appropriate.] The internal handlers are the basis for the later P?S/8 non-system device handlers for LINCtape on the modifed LINC-8 and DECtape on the modified LINC-8; some of the command syntax is uses as a precursor to BLKCPY. Arguably, much of the program is obsolete given the availability of the BLKCPY program and the L8MHND and DL8HND non-system device handlers; however, the DECtape routines support features incompatible with the P?S/8 non-system device handler: a) the block size can be adjusted to support 384 12-bit words/block DECtapes such as are used in the TOPS10 [and other DEC systems] DECtape format, b) the transfers can be accomplished in either the forwards or reverse [as defined for DECtapes] direction which is also required for compatibility with certain other programs or operating systems. [Note: these additional features can be useful for some future utility such as PIP10 for the modified LINC-8.] Future releases of the DL8HND device handler could incorporate these addtional features based on the new specifications for non-system device handlers for P?S/8 releases beyond Version 8Z. This would involve special calls to non-existent logical blocks as defined in the context of 24-bit block arguments; at such a time, the DOL8 program can be completely retired. For the present, DOL8 is being retained until a more comprehensive DL8HND is supported. Note: File date corrected. Full name: DOL8.PAL. DSUHND.PA Source file for the non-system device handler for the DSD-240-8 disk controller with the Western Dynex fixed/removable cartridge disk drive. This handler conforms with the description of P?S/8 non-system device handlers as defined for P?S/8 Version 8Z. Certain issues have come up since the writing of this program that will be important to future releases; this is discussed in some detail in the description of the non-system handler for the TC01/TC08 DECtape controller and TU55/TU56 DECtape drives. This handler currently fits in a single page. Future releases may require an additional page to implement new features. Full file name: DSUHND.PAL. RKAHND.PA Source file for the non-system device handler for the RK8E disk controller with RK05 disk cartridges. This handler conforms with the description of P?S/8 non-system device handlers as defined for P?S/8 Version 8Z. Certain issues have come up since the writing of this program that will be important to future releases; this is discussed in some detail in the description of the non-system handler for the TC01/TC08 DECtape controller and TU55/TU56 DECtape drives. The internal organization of disk storage will be changed in future releases to better take advantage of larger logical disks as used within the P?S/8 SHELL environment. Full file name: RKAHND.PAL. RXAHND.PA Source file for the non-system device handler for the RX8E controller and RX01 or compatible 8" diskette drives. This handler conforms with the description of P?S/8 non-system device handlers as defined for P?S/8 Version 8Z. Certain issues have come up since the writing of this program that will be important to future releases; this is discussed in some detail in the description of the non-system handler for the TC01/TC08 DECtape controller and TU55/TU56 DECtape drives. Future releases of this handler will address RX02 double-density media and other issues. Full file name: RXAHND.PAL. FLPHND.PA Source file for the non-system device handler for the MDC8 HD diskette system [FLP]. This handler conforms with the description of P?S/8 non-system device handlers as defined for P?S/8 Version 8Z. Certain issues have come up since the writing of this program that will be important to future releases; this is discussed in some detail in the description of the non-system handler for the TC01/TC08 DECtape controller and TU55/TU56 DECtape drives. Note: This handler contains vestigial logical units to address a small storage area at the largest diskette address. A future release of this program will eliminate the need for this minor nuisance. Full file name: FLPHND.PAL. FIXUP .PA Source file for the destructive one-way text file conversion program for R-L Monitor System DECtapes. [Note: This program runs under any P?S/8 system based on DECtape storage media; if the R-L Monitor System DECtape is imaged to another device such as LINCtape, the program will run under any P?S/8 system based on LINCtape, etc.] The purpose of this program is to convert R-L Monitor text files to the format used in the basic P?S/8 system; converted text files are then compatible with P?S/8 text files. The user must embellish the files to take advantage of the character set of the P?S/8 editor which supports the horizontal tab character which is unavailable in the R-L Monitor System. Once converted in place, the resulting DECtape is not quite directly useful for all purposes P?S/8 files are generally used for. The files must be copied to a P?S/8 system device unit to allow the files to be passed to P?S/8 system programs. This can be accomplished using the keyboard monitor's ability to load and save individual files or by using the P?S/8 File Manager [FILMAN] program for a more automated approach. [Note: If only a single DECtape drive is available, the keyboard monitor approach must be used including manual changing of the DECtapes; this was the only approach available under the R-L Monitor System due to being designed for a single DECtape drive only. Under P?S/8, up to eight logical drive units may be accessed at a time. [Note: The All Catalogs [ALLCAT] program may be used to speed up the manual operations; the program requires 8K memory and caches the entirety of all directories on all possible drives at once.] R-L Monitor System binary files are compatible with P?S/8 as a subset [no extended memory support within the files] and can be used once copied to a P?S/8 system logical drive unit. For all other files, the user must have an understanding of the exact file format as P?S/8 does not support undocumented file formats from the R-L Monitor System [such as might be devised by users]. Note: Programs written expressly to work with R-L Monitor-specific DECtape subroutines are recommended to be rewritten to P?S/8 specifications to take advantage of the resident nature of the P?S/8 system device handler. [Note: Binary programs written for the R-L Monitor System must include their own read/write subroutines for TC01/TC08 only; P?S/8 eliminates this overhead entirely; however, the user program must conform to P?S/8 standards regarding reserved system areas which are quite different from the original R-L equivalents. As such, it is recommended that only source files be given any serious consideration.] Note: File date corrected. Full name: FIXUP.PAL BSAVE .PA Source file for the P?S/8 BSAVE utility. Areas of contiguous memory or individual memory locations can be saved into binary output files which can be loaded later with any of the BIN utility loader options [or punched to paper-tape binary in either BIN or RIM format]. The BSAVE command line conforms to both the left-to-right and the right-to-left conventions of later P?S/8 command formation. Output files must be present and cannot be either the "%" or "$" file due to the nature of P?S/8 memory image saving conventions. The program will give a summary of how many binary output files were actually used; an error message will be given if insufficient output files were passed to accomplish the command. As a rule of thumb, each binary output file contains about 3/7 of a memory field of binary content. Up to 17 binary files can be specified which allows up to 28K of memory to be saved with a single BSAVE command. Since P?S/8 does not modify the contents of user memory [unless certain known programs are run, such as P?S/8 PAL which always attempts to allocate as much memory as is available], multiple commands can be issued to handle even the most extreme case possible. [Note: P?S/8 BIN can load as many as 17 binary files on a single command line; thus, binary loading limitations are consistent with the BSAVE command constraints. Few PDP-8 programming projects are as long as this one command line limitation, etc.] Full file name: BSAVE.PAL. SET .PA Source file for the P?S/8 SET utility. Many options of the keyboard monitor and integrated editor can be customized in various ways as necessary. Full file name: SET.PAL. CORE .PA Source file for the P?S/8 CORE utility. All aspects of the logical and reported physical memory size are managed by this program. Full file name: CORE.PAL. DATE .PA Source file for the P?S/8 DATE utility. The current date can be printed out along with an optional message of the day. The date can be set to any valid day in the supported time continuum. [Note: The internal date format is being modified; as such, certain changes will be required within this program.] Full file name: DATE.PAL. CONSOL.PA Source file for the Logical Console Overlay utility. The Overlay can be maintained using various command-line option switches in conjunction with special-format binary files used to modify the specific hardware configuration. Full file name: CONSOL.PAL. KL8 .PA Source file for the KL8-type serial interfaces and related devices for the Logical Console Overlay. Various parameters are available to allow quickly changing the configuration that will be applied. As with all Overlay updates, a custom binary file must be created which is then applied as an update by running the CONSOL utility. Full file name: KL8E.PAL. KL8PCH.PA Source file for customizing the KL8 file to likely standard types. Minor customization is possible; the main purpose is to minimize the errort to customize the KL8-oriented Logical Console OVerlay binary update file to be applied to the Overlay for a specific hardware configuration. [Note: The configuration can be set for the normal hardware configuration of device 03/04 console and device 66 lineprinter; since updates to the Overlay are permanent, this configuration will return to overlay to its original release state.] Full file name: KL8PCH.PAL. VT8E .PA Source file for the VT8E interface variant of the Logical Console Overlay. As with all Overlay updates, a custom binary file must be created which is then applied as an update for running the CONSOL utility. Full file name: VT8E.PAL. ALLCAT.PA Source file for the ALL CATalogs in memory overlay to the P?S/8 keyboard monitor. The contents of the TFS directory [CATalog] of all available logical units is cached in memory. This allows numerous operations on TFS files carried out manually to be accomplished rapidly; no actual writing of the modified catalogs occurs. Commands that might disturb the keyboard monitor are temporarily inhibited. Exiting the keyboard monitor will write out all updated TFS directories to their respective logical units. This utility is especially useful on slow system devices such as DECtapes and LINCtapes. [Note: Requires 8K memory.] Full file name: ALLCAT.PAL. PRINT .PA Source file for the P?S/8 PRINT utility. Text files can be printed on the system printer or the console with various formatting options to accommodate a variety of devices. Full file name: PRINT.PAL. FILMAN.PA Source file for the P?S/8 FILe MANager utility. TFS files can be copied or deleted; the directory can be emptied of all files on any logical device unit. Various command options are provided to perform common functions easily. [Note: Wild-card options are available as well as a myriad of command-line options in various forms beyond the basic P?S/8 command-line option switches.] Full file name: FILMAN.PAL. ODT .PA Source file for the P?S/8 ODT debugging utility. ODT is a superset of all known ODT implementations and includes the ability to manage multiple breakpoints. Various means of dumping out memory are available including representation in various formats as found in text packing schemes for a variety of file and memory formats. Full file name: ODT.PAL. DUMP .PA Source file for the P?S/8 DUMP utility. DUMP can be used to dump out the contents of blocks on the system device, make patches to any block or transfer a limited number of blocks at a time between logical units. All DUMP operations can be controlled by the contents of control files passed to DUMP to create an automated sequence of events if desired. Part of the present method of creating P?S/8 systems requires the use of P?S/8 DUMP driven by certain command files to enhance the starter system into a more fully implemented release. [Note: P?S/8 DUMP is created during the initial system generation process; this is required to allow the enhancement process later.] Full file name: DUMP.PAL. [End-of-file]