A1 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 MOVEMA.BI 0007 2 23-FEB-88 MOVEMB.BI 0011 3 16-FEB-88 PQSASM.BI 0014 6 16-FEB-88 COMGEN.BI 0022 4 16-FEB-88 CMPARA.BI 0026 3 23-FEB-88 CMPARB.BI 0031 5 16-FEB-88 ASCODE.PA 0036 32 15-APR-86 DTCOPY.PA 0076 50 30-OCT-75 DTFRMT.PA 0160 111 30-OCT-75 RKLFMT.PA 0337 129 28-APR-77 MARK12.12 0540 81 08-APR-86 TC12F .12 0661 90 10-APR-86 FOCALZ.ZM 1013 120 08-APR-87 FLOATZ.ZM 1203 66 08-APR-87 PHOCAL.PA 1305 47 17-APR-77 ASMBLR.PA 1364 571 06-OCT-87 BIN .PA 2457 204 17-DEC-86 MAP .PA 2773 113 09-FEB-86 BLKODT.PA 3154 84 16-APR-86 LTBODT.PA 3300 123 17-APR-86 LTDUMP.PA 3473 111 12-JAN-87 3652 118 118 FREE BLOCKS ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ File Information MOVEMA.BI OS/8 BATCH input file to copy all P?S/8 "A" files from a logical source device [FROM:] to a logical destination device [TO:]. This allows the collection of "A" files on multiple media to be aggregated to another device for development. [Note: Historically, P?S/8 has been copied from removable media, such as multiple DECtapes, to a larger disk device such as RK8E/RK05.] MOVEMB.BI OS/8 BATCH input file to copy all P?S/8 "B" files from a logical source device [FROM:] to a logical destination device [TO:]. This allows the collection of "B" files on multiple media to be aggregated to another device for development. [Note: Historically, P?S/8 has been copied from removable media, such as multiple DECtapes, to a larger disk device such as RK8E/RK05.] PQSASM.BI OS/8 BATCH input file to assemble all of the sub-components of P?S/8. Logical devce TMP: is the target for all binary files. Logical devices A: and B: are derived from the "A" files directory and the "B" files directory [such as RKA1: and RKB1: respectively]. [Note: Several files require the user program PAL12.SV to assemble into suitable binary format for OS/8 loading. PAL12 is based on a very early version of PAL8 with many limitations, etc. The source code was converted from LAP6-DIAL files using P?S/8 L6DCON then converted to OS/8 using P?S/8 OS8CON. To distinguish these files from other PAL language files, the affected files use the .12 extension which is the default input type to the PAL12 program. In the P?S/8 environment, there is no requirement for special handling as P?S/8 PAL supports both PDP-8 and LINC assembly as a superset of both PAL8 and the LAP6-DIAL assembler [which does not support literals.] COMGEN.BI OS/8 BATCH input file to create a scratch directory [SCR:] containing specific P?S/8 binary core images in a pragmatic order needed by the P?S/8 starter system to update to additional system programs. The update is carried out by P?S/8 DUMP [which is available on the starter system] driven by various DUMP command files tailored to work with the scratch file collection. It is necessary to use appropriate logical units for this to work. [Note: Future P?S/8 system generation methods will use alternatives eliminating this tenuous step in the creation of a working P?S/8 release.] CMPARA.BI OS/8 BATCH input file to compare all P?S/8 "A" files from a logical source device [FROM:] to a logical destination device [TO:]. This allows the collection of "A" files on multiple media to be aggregated to another device for development. [Note: Historically, P?S/8 has been copied from removable media, such as multiple DECtapes, to a larger disk device such as RK8E/RK05.] CMPARB.BI OS/8 BATCH input file to compare all P?S/8 "B" files from a logical source device [FROM:] to a logical destination device [TO:]. This allows the collection of "B" files on multiple media to be aggregated to another device for development. [Note: Historically, P?S/8 has been copied from removable media, such as multiple DECtapes, to a larger disk device such as RK8E/RK05.] ASCODE.PA P?S/8, OS/8, DIAL-MS ASCII Code Chart. Assemblable source file. Full file name: ASCODE.PAL. DTCOPY.PA Source file for the stand-alone DECtape Copy Program [Version 10] from Digital Equipment Corporation. Note: File date corrected. Full file name: DTCOPY.PAL. DTFRMT.PA Source file for the stand-alone TC01/TC08 DECtape Formatter Program [Version 4] from Digital Equipment Corporation. [Note: This version is slightly defective as it needlessly includes non-standard exit that is not recommended and only passable from OS/8; in addition, the same section of code has bad programming technique that will hang if the CPU is the original PDP-8. These changes were apparently made by someone unfamiliar with the rules and conventions of proper support for programs designed to be as flexibly supported as possible.] Note: File date corrected. Full file name: DTFRMT.PAL. RKLFMT.PA Source file for the stand-alone RK8E RK05 Formatter program [apparently internal version 8] from Digital Equipment Corporation. [Note: This version is slightly defective as it incorporate instructions that can only be used on Omnibus processors. There are several sections of bad coding technique that will prevent the program from running properly on any machine prior to the PDP-8/E for a variety of reasons: 1) Lack of an MQ register. This applies to the PDP-8/L despite the existence of systems based on the RK8F [RK8E modified to work in the DW8E] and the original PDP-8 unless the optional EAE is implemented. It would appear an inexperienced programmer modifed the code without determining the inapplicability of the changes. [Note: The MQ register is not actually required for this program. Proper coding can determine if the MQ is available to be used as a status display and modify the program accordingly. If the hardware lacks the MQ register, the program can self-modify accordingly, etc.] 2) The use of PDP-8/E interrupt-oriented instructions instead of the fully compatible instructions. [Note: The newer instructions were added to speed the handling of interrupts; the basic design of this program doesn't require this.] It appears an inexperienced programmer was just confirming ignorance when these instructions were needlessly added to the program. 3) The use of CAF which will hang on the original PDP-8. The source code claims the program was modified for use with OS/8 Version 3D. In point of fact, no such modification need exist; the program already conforms to the general requirement of all properly written application programs, namely the avoidance of memory locations 07600-07777. Since the program does not load into extended memory, it is already compatible with all relevant PDP-8 operating systems. The only *constructive* change to the program appears to be activating an existent internal feature to allow the use of the program on systems lacking front panel switches; there are several such diagnostic programs with the same feature. This merely involves creating the equivalent of the proper switch register bits in the designated memory locations and enabling the feature already present in the program. The title of the program implies it is also for an RK8L which is apparently the name of an in-house prototype of an Omnibus-based redesign of the RK8E to occupy less slots in a hex-wide PDP-8/A box. While the RK8L was never marketed, the program is intended for use with the RKS8E which is a superset of the RK8E. As long as only the first four drives are addressed, the program will run on this device as well. Considering the tentative existence of the RK8L and the actual existence of the RK8E, RK8F and RKS8E, the program title seems to be somewhat misguided. Note: File date corrected. Full file name: RKLFMT.PAL. MARK12.12 Source file for the modified MARK12 program used to format LINCtapes on the PDP-12. Several changes have been made from the original MARK12 as implemented on LAP6-DIAL/DIAL-MS: 1) The source code has been overhauled sufficiently to be compatible with P?S/8 PAL and the user-written PAL12 assembly program for OS/8. [Note: PAL12 is derived from an early implementation of PAL8 which is known to be deficient in many ways. Several compromises were made in the source code to allow PAL12-compatibility; future releases of the source code may drop compatibility with PAL12 or include conditional assembly to allow compatibility in the binary sense only. By taking fuller advantage of P?S/8 PAL, the program source code will be more cohesive and readable.] The changes made are sufficiently incompatible with the DIAL assembler that backward compatibility is no longer possible. [Note: The DIAL assembler does not support literals.] 2) Program execution can be attempted on machines other than the PDP-12; appropriate error messages will be issued and the program will exit gracefully. 3) The program checks for the presence of the P?S/8 Logical Console Overlay as defined in 1986. Future releases may change this support slightly to conform with newer versions of the Overlay. 4) The program supports 3300 octal block LINCtapes of 128 words per block; this is more useful on tapes meant to be used with either P?S/8 or OS/8 on either the PDP-12 or the LINC-8 as required. [Note: Both P?S/8 and OS/8 support ignoring 129th data words on LINCtapes used on the PDP-12. On the LINC-8, only 128 word tapes can be supported; thus, the presence of the 129th word only complicates support issues. The 129th word adds no value by its presence; this only causes tape transfers to take longer and limits the maximum block count in a pointless attempt at pseudo-compatibility with DECtape that only applies to a theoretical application for unrelated operating systems such as the DECtape version of the Disk Monitor System. The DIAL standard of 1600 octal blocks of 256 words per block is also supported as in the original version. [Note: Future versions of P?S/8 MARK12 will optionally support longer [premium-length] LINCtapes as are used in the LINC-8; this would include 2000 octal block 256 words/block and 4000 octal block 128 words/block tapes. The release date of this file is correct within this directory; OS/8 releases of the file may have this wrong, which can be corrected. For use with OS/8 PAL12, the program was renamed to have a .12 extension which is the PAL12 default. [This is to be avoided when used with dual-mode assemblers such as P?S/8 PAL.] Note: The file date should be corrected as shown above; OS/8 copies of the file should use a date stamp consistent with this. Full file name: MARK12.PAL. TC12F.12 Source file for the modified TC12F program used to transfer DECtape contents to LINCtapes and vice-versa. Several changes have been made from the original TC12F as implemented on LAP6-DIAL/DIAL-MS: 1) The source code has been overhauled sufficiently to be compatible with P?S/8 PAL and the user-written PAL12 assembly program for OS/8. [Note: PAL12 is derived from an early implementation of PAL8 which is known to be deficient in many ways. Several compromises were made in the source code to allow PAL12-compatibility; future releases of the source code may drop compatibility with PAL12 or include conditional assembly to allow compatibility in the binary sense only. By taking fuller advantage of P?S/8 PAL, the program source code will be more cohesive and readable.] The changes made are sufficiently incompatible with the DIAL assembler that backward compatibility is no longer possible. [Note: The DIAL assembler does not support literals.] 2) The program can be attempted on machines other than the PDP-12. Appropriate error messages will be issued and the program will exit gracefully. 3) The program checks for the P?S/8 Logical Console Overlay presence as defined in 1986. Future releases may change this support slightly to conform with newer versions of the Overlay. 4) The program attempts to support Control-C abort as was practiced by P?S/8 in 1986; however, due to expedient design, attempts at program abort will likely fail. The program needs to be reorganized so as to not conflict with the P?S/8 resident kernel, which is destroyed as part of the program startup; DIAL system conventions are such that the normal PDP-8 resident kernel may not be preserved. DIAL is a very primitive system that can be restarted by LINC-mode LINCtape instructions in the tradition of the LINC. PDP-8 systems require a standardized system resident kernel; this allows flexible system configuration. The memory layout of the program requires major overhaul to properly reserve the resident area as defined in all relevant PDP-8 operating systems. For use with OS/8 PAL12, the program was renamed to have a .12 extension which is the PAL12 default. [This is to be avoided when used with dual-mode assemblers such as P?S/8 PAL.] Note: The TC12F program will be largely obsoleted by the next major release of the BLKCPY program. Full file name: TC12.PAL. FOCALZ.ZM Source file for FOCAL, 1969. Meant to be assembled with FLOATZ.ZM. [Note: Does not include the optional INIT section usually distributed as an independent binary section on the same physical BIN format paper-tape.] The creation of P?S/8 FOCAL starts with the binary output of the assembly of FOCALZ.ZM and FLOATZ.ZM. An additional binary file is then overlaid over this to create the P?S/8 system program image; this requires extended memory to load the entire image at one time. The creation process of P?S/8 FOCAL includes creating overlays from the additional code loaded in extended memory. Once this is completely installed as a P?S/8 system program, FOCAL executes in 4K; overlays are brought in as necessary, such as at the completion of reading the contents of all input files which can include FOCAL commands and data. Once this overlay is loaded, FOCAL then accepts input from the console as would the stand-alone version [subject to the presence of the P?S/8 Logical Console Overlay which may already be in effect before FOCAL is invoked.] Before FOCAL starts up, P?S/8-oriented additional once-only initialize code makes certain internal changes, some of which are dependent on passed option switches. Any initial P?S/8 SLURP format binary files are processed for the purpose of loading patches to FOCAL. This is accomplished by an imbedded SLURP loader that is device-independent but is non-virtualized; binary files must be created with intimate understanding of the internal workings of FOCAL as well as P?S/8 internal operations; extended memory can be loaded freely as required by the custom patch being loaded. By following the internal rules of FOCAL, multiple packages can be loaded by following the proper rules of relocation. Note: The original FOCAL INIT section is not used. In addition, it is flawed in several ways: 1) It does not properly detect the PDP-8/L. A defective method is used that cannot work on many actual PDP-8/I systems. As a result, it is often true that PDP-8/I systems are incorrectly identified as PDP-8/L due to improper technique. The reason for this is that an awful and undependable kludge is used to tell the PDP-8/I from the PDP-8/L: The two are assumed to be identical except for speed based on the presumption that a) the console speed can be assumed to be 110 baud, b) that it is always true that a PDP-8/I is faster than the timeout calculation used presumably to claim slower machines must be PDP-8/L. In point of fact, many PDP-8/I systems are slowed down from the nominal speed that would match the crystal-clock-controlled PDP-8. This is because the PDP-8/I memory often must be slowed down due to reliability issues; this is also why eventually the PDP-8/L and the PDP-12 were officially slowed down slightly; thus, the timeout is too critical to be reliably used. However, the method is totally worthless when any form of console change is made; there are perfectly legitimate alternatives on these machines that increase the baud rate such as using the LA-30P interface which is actually a parallel device with quite different [and faster] timing, or various terminals such as the VT05 and LA36 which are 100% compatible at the speed of at least up to 300 baud. [Note: The VT05 is not 100% compatible at speeds of 600 baud or faster; this is why the KL8-JA Omnibus interface was released several years later; it includes an option to correct the problem by brute-force hardware methods that function up to 1200 baud in countries that use 50 Hz power mains, and 2400 baud in countries that use 60 Hz power mains. However, this does not effect the reckoning of PDP-8/I versus PDP-8/L.] This problem can be corrected by executing the group III OPR instruction 7601. On all models from the PDP-8 up, this instruction clears the AC with the lone exception of the PDP-8/L because the design of the PDP-8/L is such that all group III OPR instructions are inhibited; on all other models, group III OPR instructions execute as harmless NOP instructions unless EAE is implemented. But the 7601 instruction always works on the rest of the product line [not including the PDP-5 and PDP-8/S which are already ruled out in the internal INIT code earlier than this decision point]. 2) INIT is ignorant of all computers newer than the PDP-12 [which is correctly identified by explicit CPU check]. As such, it just reports the CPU as PDP-8 which is confusing since that is also the correct notation for the original PDP-8, which has already been correctly identified by the fact that instructions that work on the PDP-8/I, PDP-8/L and PDP-12 do not function. As such, INIT will falsely identify any model of Omnibus CPU [KK8F as used in PDP-8/E, PDP-8/F, PDP-8/M, PDP-8/A 6xx or KK8A as used in one-slot CPU PDP-8/A models], the VT78 or any other machine based on the 6100 [Intercept I, PCM-12/12A], all DECmates or any other machines based on the 6120 [CPU-8 Omnibus CPU from CESI, SBC6120] or DCC models 112 and 112H which use a slightly different CPU design that can be detected by another OPR instruction. Note: FOCAL-8, a derivative of FOCAL, 1969 includes code to detect the DCC machines; however, if the CPU matches one of these models, FOCAL-8 cleverly self-destructs internally so as to suggest the hardware is flakey. [Note: Similar sabotege code was once added to a short-lived release of OS/8 and later removed; DEC management forgot that this had been added to FOCAL-8 which was never withdrawn.] If there is sufficient interest, a P?S/8-specific INIT can be created to roughly follow the program flow of the original INIT only with these problems corrected. However, one particular portion of such an INIT program patch cannot be implemented: 1) The original INIT asks the user certain questions regarding the possible retention of some of the trigonometric functions; however, only certain questions are asked creating the minor problem that not all cases are covered. 2) P?S/8 FOCAL corrects this situation by using passed option switches to allow all combinations of retention [which amounts to four possible combinations; the original INIT only allows three of the possibilities]. If required, P?S/8 FOCAL relocates one package over the address space of the other package, thus not only allowing this case, but recovering the storage space as intended. Thus, such an INIT package can only report which functions were/were not retained; this dynamic self-configuration has already been performed before any such a binary patch can be applied. Note: The extension used on FOCAL, 1969 apparently is derived from the author's personal preference to not embrace the .PAL extension and instead called the first implementation of FOCAL by the .ZZZ notation for both FOCAL and FLOAT. [Indeed, that there are actually two files is a personal preference. Nothing is gained by the separation; assembler features exist to force sectional titles within an assembly listing if this was the intended reason.] Apparently, with each major development effort, the extension was "decremented" thus, FOCAL, 1969 as released is known as FOCAL.ZZM. Full file name: FOCAL.ZZM. FLOATZ.ZM Source file for FOCAL, 1969 floating point arithmetic, etc. Meant to be assembled with FOCALZ.ZM. Full file name: FLOAT.ZZM. PHOCAL.PA A very early work-in-progress file that eventually lead to the P?S/8 version of FOCAL, 1969. It is used merely as an inspiration when performing additional development to FOCAL and includes a few inside jokes generally only known to a small group of people who have actually worked on FOCAL while studying the original source code. [Note: Much of the work of converting the earlier R-L Monitor FOCAL into P?S/8 FOCAL was obtained independent of this file; thus, the stated last edit date can be confusing.] Note: File date corrected. Full file name: PHOCAL.PAL. ASMBLR.PA Source file for the P?S/8 PAL assembler. Internal edit: 392. Full file name: ASMBLR.PAL. BIN.PA Source file for the P?S/8 BIN utility program. Internal version 8Z. Note: The SLURP loader and the /I system device handler reload routines are not contained in this file; system generation as currently defined resolves all loading considerations; the working image of the BIN system program requires the SLURP loader be placed into a designated area within BIN and certain entry points be resolved within the once-only initialization code, etc. As such, these components are generally combined with the corresponding system device handler source files for each supported device. [Note: Throughout P?S/8, the internal version number is handled in a way that is difficult to get beyond version 9Z in the usual numerical sense. A design goal for the future will be to create a unified method of determining program versions including the ability to detect non-conforming programs used as system programs such as the TC01/TC08 DECtape formatting program. The default contents of certain loaded words will be used by a method yet to be devised. Due to the large number of option switches supported by BIN with complex interactions, the creation of an internal option switch default modification method must be carefully chosen. Future versions of P?S/8 should manage these three-word areas carefully. [The corresponding bits for the passed option switches are modified by an .XOR. operation with these internal words; however, there are no standards for implementation of this feature in general; it is suggested this feature be resolved at the same time as proper version control; not all programs will bother to implement this, etc.] Future system generation methods may change the way the BIN system program is created for a more flexible method of system creation or update when combining system components, etc. Full file name: BIN.PAL. MAP.PA Source file for the P?S/8 MAP utility that creates bitmap output of the memory locations loaded by a passed set of binary input files. Various options exist to exclude specific fields if desired; the default is to account for all loading in all memory fields 0-7. MAP may be chained to by the P?S/8 PAL assembler as a post-processing output utility [the bitmap output is appended on the assembler output using the conventions of P?S/8 PAL as dynamically determined by the invocation of P?S/8 PAL using the "/M" option switch to chain to MAP]. MAP may also be used to optionally chain to the BIN utility to further process the passed binary files. Both chaining processes might apply allowing assembly, map, and go operations from a single command. Note: P?S/8 PAL attempts to support 256K of memory. [Note: The upper limit of the KT8A is 128K; CESI systems theoretically support up to 512K of memory. However, P?S/8 cannot run on machines with the CESI memory controller present unless set to compatible mode which limits memory to 32K. As such, this may be lowered to 128K depending on design considerations; only the KT8A is capable of extended loading while also maintaining full compatibility with the conventional 32K extended memory requirements. The use of CESI memory extensions beyond 32K is within the province of specially-designed application systems such as OMNI-8 which was designed expressly for this hardware. However, there is no need to directly support beyond 32K of loadable code; the rest of the memory is used for the application itself, not any loadable code that need be assembled for extended loading.] Once the conventions of memory loading beyond 32K are established, MAP can be extended to support the additional loading, etc. Full file name: MAP.PAL. BLKODT.PA Source file for the P?S/8 BLKODT program. BLKODT uses the general command syntax of P?S/8 ODT [other than execution and breakpoint commands] to examine a series of blocks on any logical unit of the system device. Note: BLKODT was formerly known as SYSODT to be more consistent with the way other operating systems approach this type of utility. Internally, the handler call is formed in the manner used by P?S/8 non-system device handlers of this release; however, the program was never developed to support non-system handlers. The exact nature of the calling conventions for non-system handlers is undergoing modification; certain additional features may be added useful to an enhanced BLKODT once the new calling sequence is finalized. [Note: In essence, the only change that would generally affect such a program is the need to support double-precision block numbers. However, certain "non-standard" devices may be available which do not translate into this convention readily, such as special-purpose devices LTDHND, a device that only supports 256 words/block standard LINCtapes. [And why there exists the program LTBODT to handle this specific case.] Future considerations of non-system handlers will dictate the direction of BLKODT; the present implementation may require supporting an option switch to run in "SYSODT" mode, which is the only operation currently supported. As a stopgap method, P?S/8 BLKCPY can be used to copy an image of a series of blocks on a non-system device to a corresponding area on any available logical unit of the system device handler; BLKODT can then be used on the transferred blocks, etc. Full file name: BLKODT.PAL. LTBODT.PA Source file for a special adaptation of P?S/8 BLKODT [SYSODT] for standard LINCtapes [256 12-bit word blocks only on certain operating systems for the LINC, LINC-8 and PDP-12; most PDP-8-oriented operating systems use 128 12-bit word blocks]. All features of BLKODT are retained or adapted to the 256 word format. The source code includes internal LINCtape routines that function on the LINC-8 and the PDP-12. The appropriate software is selected dynamically when the program determines what CPU type is present; attempts to run LTBODT on inappropriate hardware will result in an error message and automatic exit. Full file name: LTBODT.PAL. LTDUMP.PA Source file for a special adaptation of P?S/8 DUMP for standard LINCtapes [256 12-bit word blocks used only on certain operating systems for the LINC, LINC-8 and PDP-12; most PDP-8-oriented operating systems use 128 12-bit word blocks]. All features of DUMP are retained or adapted to the 256 word format. The source code includes internal LINCtape routines that function on the LINC-8 and the PDP-12. The appropriate software is selected dynamically when the program determines what CPU type is present; attempts to run LTDUMP on inappropriate hardware will result in an error message and automatic exit. Full file name: LTDUMP.PAL. [End-of-file]