RTS8V2B.DOC DISCLAIMER This document file was created by scanning the original document and then editing the scanned text. As much as possible, the original text format was restored. Some format changes were made to insure this document would print on current laser printers using 60 lines per page. The original spelling and grammar has been preserved. 1-Jun-1996 RTS/8 User's Manual Order No. DEC-08-ORTMA-C-D Version 2B digital equipment corporation - maynard, massachusetts First Printing, June 1974 Revised: September 1975 February 1977 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license. Digital Equipment Corporation assumes no responsibility for the use or reliability of its software on equipment that is not supplied by DIGITAL. Copyright 1974, 1975, 1977 by Digital Equipment Corporation The postage prepaid READER'S COMMENTS form on the last page of this document requests the user's critical evaluation to assist us in pre- paring future documentation. The following are trademarks of Digital Equipment Corporation: DIGITAL DECsystem-10 MASSBUS DEC DECtape OMNIBUS PDP DIBOL OS/8 DECUS EDUSYSTEM PHA UNIBUS FLIP CHIP RSTS COMPUTER LABS FOCAL RSX COMTEX INDAC TYPESET-8 DDT LAB-8 TYPESET-10 DECCOMM DECsystem-20 TYPESET-11 RTS/8 CONTENTS Page PREFACE vii CHAPTER 1 INTRODUCTION 1-1 1.1 RTS/8 DESCRIPTION 1-1 1.2 REAL-TIME SYSTEM OPERATION 1-2 CHAPTER 2 USING TASKS UNDER RTS/8 2-1 2.1 THE STRUCTURE OF RTS/8 TASKS 2-1 2.2 CONCEPTS OF TASK COMMUNICATION 2-1 2.2.1 Task Synchronization Through the Use of Event Flags 2-2 2.2.2 Intertask Messages 2-3 2.3 EXECUTIVE INTERNAL TASK TABLES 2-5 CHAPTER 3 RTS/8 EXECUTIVE REQUESTS 3-1 3.1 COMMUNICATION WITH THE RTS/8 EXECUTIVE 3-1 3.2 ERs USED TO COMMUNICATE BETWEEN TASKS 3-1 3.2.1 SEND - Send Message 3-2 3.2.2 WAITE - Wait on Event Flag 3-3 3.2.3 SENDW - Send and Wait 3-3 3.2.4 RECEIVE - Receive Message 3-4 3.2.5 POST - Post Event Flag 3-5 3.2.6 Example of ERs for Message and Event Flags 3-5 3.3 ERs USED TO SET AND CLEAR TASK FLAGS 3-7 3.3.1 BLKARG - Block Task for Specified Reason 3-7 3.3.2 UNBARG - Unblock Task for Specified Reason 3-8 3.3.3 SUSPND - Suspend a Task's Execution 3-8 3.3.4 RUN - Run a Task 3-9 3.4 USING INTERRUPTS IN RTS/8 3-10 3.5 EXECUTIVE REQUEST WAIT STATES 3-13 CHAPTER 4 RTS/8 SYSTEM TASKS 4-1 4.1 CLOCK HANDLER 4-2 4.1.1 Examples of Clock Handler Calls 4-4 4.2 TERMINAL HANDLER 4-5 4.2.1 Additional Assembly Parameters Affecting Terminal Handler Properties 4-8 4.2.2 Useful Equates in the Parameter File 4-10 4.2.3 Examples of Terminal Handler Messages 4-11 4.3 LINE PRINTER HANDLER 4-11 4.4 MASS STORAGE HANDLERS 4-12 4.4.1 Floppy Disk Handler 4-14 4.4.2 LINCtape Handler 4-18 4.4.3 Example of Mass Storage Handler Call 4-20 4.5 POWER FAIL TASK 4-20 4.6 OS/8 SUPPORT TASK 4-21 4.6.1 Mapping of Fields with OS/8 Support Task 4-23 iii CONTENTS (Cont.) Page 4.7 OS/8 - RTS/8 COMMUNICATION (OS8COM) 4-23 4.7.1 Using the OS8COM Task 4-24 4.7.2 Other Techniques 4-25 4.8 OS/8 FILE SUPPORT TASK 4-25 4.9 UNIVERSAL DIGITAL CONTROLLER/INDUSTRIAL CONTROLLER SUBSYSTEM (UDC/ICS) HANDLER 4-27 4.9.1 AO Analog Output 4-29 4.9.2 AI Analog Input 4-29 4.9.3 DO Digital Output 4-30 4.9.4 DI Digital Input 4-31 4.9.5 GC Generic Code 4-31 4.9.6 EC Enable Counter 4-31 4.9.7 RC Read Counter 4-33 4.9.8 DC Disable Counter 4-33 4.9.9 ECT Enable Contacts 4-33 4.9.10 CS Change of State 4-34 4.9.11 DCT Disable Contacts 4-34 4.9.12 UDC/ICS Assembly Parameters 4-34 4.9.13 UDC/ICS Error Conditions 4-35 4.10 CASSETTE HANDLER 4-36 4.10.1 Handler Function 4-36 4.10.2 Utility Function 4-38 4.11 CASSETTE FILE SUPPORT HANDLER 4-39 4.12 PDP-8A NULL TASK 4-41 4.13 KL8-A SUPPORT 4-41 4.13.1 Executive KL8-A Support 4-42 4.13.2 TTY Task KL8-A Support 4-42 4.13.3 KL8-A Support for the OS/8 Support Task 4-43 4.13.4 KL8-A Support for a User Task 4-43 4.14 EXIT TASK 4-44 CHAPTER 5 MONITOR CONSOLE ROUTINE 5-1 5.1 MCR COMMAND ARGUMENTS 5-1 5.2 MCR COMMANDS 5-2 5.2.1 DAte [mm/dd/yyyy [,Time-of-day]] 5-2 5.2.2 TIme [Time-of-day] 5-2 5.2.3 NAme Task-ID,Newname 5-2 5.2.4 REquest Task-ID [,(@Time-of-day ! Interval) [,Interval]] 5-3 5.2.5 STop Task-ID 5-4 5.2.6 DIsable Task-ID 5-4 5.2.7 ENable Task-ID 5-4 5.2.8 CAncel Task-ID 5-4 5.2.9 SYstat [Task-ID] 5-5 5.2.10 OPen Address [,Count] 5-6 5.2.11 EXamine Address [,Count] 5-6 5.2.12 DEposit Address,Word [,Word] [,Word] 5-6 5.2.13 POst Address 5-6 5.2.14 EXIT 5-7 5.3 MCR ERRORS 5-7 5.4 NONRESIDENT MCR 5-7 iv CONTENTS (Cont.) Page CHAPTER 6 ASSEMBLING AND LOADING TASKS FOR RTS/8 6-1 6.1 PARAMETER FILE STRUCTURE 6-1 6.1.1 Executive Specifications 6-2 6.1.2 Task Definitions 6-2 6.1.3 System Task Specifications 6-3 6.1.4 System Wide Definitions 6-4 6.1.5 Task Setup 6-4 6.2 CREATING AN RTS/8 SYSTEM 6-5 6.3 USING THE OS/8 BITMAP PROGRAM 6-8 6.4 SAMPLE RTS/8 TASK PROGRAM 6-8 6.5 USE OF CONTROL FILES UNDER RTS/8 6-10 6.6 RTS/8 SYSTEM TASK PARAMETERS 6-11 6.6.1 Clock Handler Parameters 6-11 6.6.2 Swapper Parameters 6-12 6.6.3 Terminal Handler Parameters 6-12 6.6.4 Monitor Console Routine Parameters 6-14 6.6.5 OS/8 Support Task Parameters 6-14 6.6.6 KL8-A Support Parameters 6-15 6.6.7 Line Printer Handler Parameters 6-15 6.6.8 DECtape Handler Parameters 6-15 6.6.9 EXIT Task 6-16 CHAPTER 7 NONRESIDENT TASKS 7-1 7.1 OVERVIEW 7-1 7.1.1 Writeable Tasks 7-3 7.1.2 Checkpointable Tasks 7-3 7.1.3 Interaction Between Tasks 7-3 7.2 MEMORY PARTITIONS 7-3 7.2.1 FREE Command 7-4 7.3 NONRESIDENT TASK INITIALIZATION 7-5 7.3.1 Parameters for Nonresident Tasks 7-6 7.3.2 Assembling Nonresident Tasks 7-7 7.3.3 Creating the SAVE Image File 7-7 7.4 PARAMETER INITIALIZATION FOR PARTITIONS 7-8 7.4.1 General Information 7-8 7.5 NONRESIDENT TASK IMPLEMENTATION 7-8 CHAPTER 8 DEMONSTRATION PROGRAM 8-1 8.1 MODIFIED PARAMETER FILE (PARAM.PA) 8-1 8.2 NONRESIDENT TASK LISTINGS 8-12 8.2.1 Nonresident Task NR20 8-12 8.2.2 Nonresident Task NR22 8-13 8.3 ASSEMBLY AND LOAD PROCEDURE 8-14 8.4 NONRESIDENT TASK ASSIGNMENT AND EXECUTION 8-15 CHAPTER 9 ADVANCED RTS/8 PROGRAMMING TECHNIQUES 9-1 9.1 PERFORMING A RESCHEDULE 9-1 9.1.1 Writing Delicate Code 9-1 9.1.2 Inhibiting Task Switching 9-2 v CONTENTS (Cont.) Page 9.2 EXECUTIVE REQUESTS FOR ADVANCED APPLICATIONS 9-4 9.2.1 WAITM - Waiting for Multiple Event Flags 9-4 9.2.2 WAITX - Wait for Exactly This Event Flag 9-6 9.2.3 DERAIL - Derail a Task's Execution 9-6 9.2.3.1 Dangers of DERAIL 9-7 9.2.3.2 Restrictions Using DERAIL 9-7 9.3 STARTING PARTITIONS AT AN ARBITRARY BOUNDARY 9-8 9.4 DIRECT REFERENCES TO SYSTEM TABLES 9-9 APPENDIX A RTS/8 DISTRIBUTED SOURCE FILES A-1 APPENDIX B RTS/8 COMPONENT SIZES B-1 APPENDIX C RTS/8 FLOWCHARTS C-1 APPENDIX D RTS/8 ASSEMBLY ERROR MESSAGES D-1 APPENDIX E EXECUTIVE INTERNAL TASK TABLES E-1 GLOSSARY Glossary-1 INDEX Index-1 FIGURES FIGURE 2-1 Message Format and Linking of Messages 2-4 7-1 Nonresident Task Implementation 7-2 B-1 RTS/8 System Memory Map (Default Memory Allocation) B-4 E-1 Executive Internal Task Table Structure E-5 TABLES TABLE 1-1 RTS/8 System Tasks 1-2 2-1 Summary of Event Flag States 2-3 3-1 Summary of Executive Requests 3-2 3-2 Symbolic Names for Specifying WAITBITS 3-9 3-3 Summary of Wait States Incurred by Executive Requests 3-14 4-1 Summary of Terminal Handler Assembly Parameter Default Values 4-10 9-1 Summary of Task Switching Flag (TSWFLG) States 9-4 B-1 RTS/8 Component Sizes B-1 B-2 MCR Component Size B-6 vi PREFACE This manual describes the PDP-8 Real-Time Operating System (RTS/8). Knowledge of PDP-8 assembly language programming (PAL8) is essential for a complete understanding of this manual. In addition, the user should be familiar with real-time systems in general and with the operation and use of the development system for the PDP-8, OS/8. The information in Chapter 9, "Advanced RTS/8 Programming Techniques" is for the experienced RTS/8 user. It should be read after the user has gained familiarity with RTS/8. This version of the manual has been enlarged and expanded to incorporate several new RTS/8 features. The Major features include KL8-A Support, PDP-8/A Null Task, the EXIT Task, and two new Executive Requests. Other features are the nonresident implementation of the MCR, UDC/ICS support, an OS8COM facility that allows the OS/8 system to talk to an RTS/8 task, and control files that allow the user to efficiently make multiple task copies. RTS/8 flowcharts have been added to show system operation. The following PDP-8 handbooks will be helpful for review and reference: INTRODUCTION TO PROGRAMMING (DEC-08-XINPA-A-D) SMALL COMPUTER HANDBOOK (90P45) OS/8 HANDBOOK (DEC-S8-OSHBA-A-D) UDC8 UNIVERSAL DIGITAL CONTROL SUBSYSTEM MAINTENANCE MANUAL (46H745) PDP-8A MINICOMPUTER HANDBOOK (EB0621976) ICS8 INDUSTRIAL CONTROL SUBSYSTEM MAINTENANCE MANUAL (EKOICS8MM) vii CHAPTER 1 INTRODUCTION 1.1 RTS/8 DESCRIPTION RTS/8 is a compact real-time system designed for the PDP-8 family of processors (except the PDP-8/S). This system allows up to 63 tasks to run concurrently and compete for resources on a fixed priority basis. It can be used for a wide range of applications in which a number of processes must be monitored and controlled. As with other real-time systems, RTS/8 responds to physical or conceptual events to permit the timely execution and scheduling of tasks. The RTS/8 Executive controls execution and interaction among all tasks. The Executive decides which tasks should run (based on the priorities of the runnable tasks), and services the tasks by means of Executive Requests (ERs). A task is the basic program unit within RTS/8. RTS/8 system tasks (DEC-supplied) and their file names are listed in Table 1-1. The system supports both resident and nonresident tasks. A resident task resides permanently in memory; a nonresident task is one in which the major portion of the task resides on a mass storage device and is loaded into memory only when that task becomes executable. Using nonresident tasks permits portions of several tasks to share the same areas of memory, providing economical use of memory. RTS/8 includes system tasks that control most standard DIGITAL I/O devices. A full complement of peripherals is supported, including RK8 and RK8-E moving-head disks, DF32 and RF08 fixed-head disks, TC08 DECtape, RX8 floppy disk, LINCtape, DEC cassette, and LEO and LS8E line printers (RTS/8 does not support TD8E DECtape). The Monitor Console Routine (MCR) task provides an interface between the user at the console terminal and the system. The MCR provides the user with a series of commands to control, inspect, and, to some extent, debug the system. The MCR commands are straightforward and easy to use. They allow the user to schedule and execute tasks at specified intervals, suspend task execution, and print system status reports. A system task also is provided that allows a single copy of the OS/8 operating system to run in the background, creating a real-time foreground-OS/8 background system. With OS/8 in the background, the user has the facilities for program assembly, debugging, and editing. The minimum RTS/8 hardware configuration required for a foreground only system is a PDP-8 family processor, 4K words of memory, and a console terminal capable of papertape input. A system capable of running a real-time foreground and OS/8 in the background requires a PDP-8 family processor with KM8-A, KM8-E or TSS-8 Time Sharing options, a mass storage device (such as an RK8E cartridge disk or RX8 floppy disk), and two terminals (one must be dedicated to OS/8 system execution). 1-1 INTRODUCTION RTS/8 tasks are created by editing the RTS/8 master parameter file to produce a parameter file that describes the user's particular system. Task source files are then assembled with the edited parameter file using the PAL8 assembler. The assembler can run either under OS/8, or the OS/8 support system under RTS/8. Then using ABSLDR under OS/8, all task binaries are joined into a complete RTS/8 system. Table 1-1 RTS/8 System Tasks ---------------------------------------------------------------------- | Task Name | File Name | Task Function | ---------------------------------------------------------------------- | - | PARAM.PA | System parameter file with | | | | equates blank. Appropriate | | | | values should be inserted to | | | | create specific parameter files. | | | RTS8.PA | RTS/8 Executive | | MCR | MCR.PA | Monitor Console Routine | | null task | MCR.PA | Null task | | OS8 | OS8SUP.PA | OS/8 Support Task | | OS8F | OS8SUP.PA | OS/8 File Support Task | | PWRF | PWRF.PA | Power Fail Task | | CLOCK | CLOCK.PA | Clock Handler Task | | TTY | TTY.PA | Terminal Driver Task | | LPT | LPT.PA | Line Printer Driver Task | | DTA | DTA.PA | TC08 DECtape Driver Task | | RK8 | RK8.PA | RK8 Disk Driver Task | | RK8 | RK8E.PA | RK8E Disk Driver Task | | RF08/DF32 | RF08.PA | RF08/DF32 Fixed-Head Disk Driver Task | | CSA | CSA.PA | Cassette Driver Task | | CSAF | CSAF.PA | Cassette File Support Task | | UDC/ICS | UDCICS.PA |Universal Digital Controller/Industrial| | | | Controller Subsystem Handler Task | | RX8A | RX01RT.PA | Floppy Disk Handler (1st controller) | | RX8B | RX01RT.PA | Floppy Disk Handler (2nd controller) | | RX8C | RX01RT.PA | Floppy Disk Handler (3rd controller) | | RX8D | RX01RT.PA | Floppy Disk Handler (4th controller) | | LTA | LTA.PA | LINCtape Driver Task | | SWAPPER | SWAP.PA | Nonresident Task swapper | | NULL8A | NULL8A.PA | Null Task for PDP-8A | | EXIT | EXIT.PA | Exit Task | | | | | ---------------------------------------------------------------------- 1.2 REAL-TIME SYSTEM OPERATION A multiprogramming system is a software framework that allows available resources (such as memory, CPU time, and peripheral devices) to be shared by several tasks. Basically, a task is a portion of machine code that performs a specific function; a task is defined by convention since it overlaps with the definitions of "program" and "subroutine." 1-2 INTRODUCTION Multiprogramming allows many tasks to be in some state of execution simultaneously. If a task cannot use available central processor time because it is waiting for completion of an I/O operation (or is blocked by some other condition), the central processor can be switched to another task to use the available time, thus increasing system efficiency. Most real-time systems are required to serve a group of tasks that run at varying times or frequencies and alternate between being compute bound or I/O bound. If machine resources are to be efficiently used, these tasks cannot be run in series since the central processor will be poorly utilized during the periods the tasks are I/O bound. In addition, most real-time tasks are essentially time-critical and should not wait for a slow, less important I/O or compute bound task to finish before being executed. Thus, multiprogramming and a priority scheme for scheduling the central processor provide maximum resource utilization. Thus, a real-time system is a multiprogramming system that must, in addition to the multiprogramming features, respond quickly to critical internal or external events. The real-time system is required to suspend the operation of a less important task and start the task that deals with the critical event. A priority scheme establishes the relative importance of various tasks in the system. This allows a less important task to be interrupted to permit execution of a critical real-time task. For RTS/8, a fixed priority scheme was chosen because such a scheme is simple and reliable, and requires low scheduling overhead. 1-3 CHAPTER 2 USING TASKS UNDER RTS/8 2.1 THE STRUCTURE OF RTS/8 TASKS The RTS/8 Executive is the controlling program in an RTS/8 System. The Executive decides which task should run based on the priorities of the runnable tasks (those tasks not waiting for completion of any I/O or other events). It also provides services to the tasks by means of Executive Requests. Executive Requests are discussed in Chapter 3. The user assigns unique task numbers to each task in an RTS/8 System. He can assign up to 63 (77 octal) task numbers, and must account for system tasks within the total number of tasks. A task number, once assigned, cannot change during the execution of the program, since RTS/8 uses a fixed priority system. Task numbers serve the following purposes: 1. The task number is used by the RTS/8 Executive as an index to various system tables which contain information about each task. 2. The task number is used by other tasks in the system to reference a particular task when performing certain Executive Requests (such as sending a message). 3. The task number determines the task's priority - the lower the task number, the higher the priority of the task. The Executive uses five internal tables to maintain information about the tasks in the system. A brief description of these tables is given in Section 2.3. 2.2 CONCEPTS OF TASK COMMUNICATION RTS/8 is event driven, i.e., the highest priority runnable task executes continuously until it is completed or some event or condition in the system causes it to be suspended. Another change or condition can reactivate the task. Tasks can be self-starting if assembled to run at system startup, started by another task, or started by the user at the terminal console using the MCR task. RTS/8 performs two main types of task communication, as follows: 1. Task synchronization through the use of Event Flags 2. Intertask messages 2-1 USING TASKS UNDER RTS/8 2.2.1 Task Synchronization Through the Use of Event Flags Whenever two processes occur independently, one process may need to wait until the execution of the other is finished. This can be illustrated by using the PDP-8 terminal interface as an example. The PDP-8, when ready to generate the first character, alerts the terminal by issuing a Load Teleprinter Sequence (TLS) instruction. The PDP-8 must now wait in a TSF; JMP.-l loop if it wishes to do further I/O immediately. It cannot proceed with the next character until the terminal raises its ready flag to signal that it is finished printing the first character. When the flag is raised, the PDP-8 then exits from the wait loop and proceeds to load the next character. Similarly, RTS/8 provides Event Flags as a signalling mechanism to synchronize tasks with each other. An Event Flag is a user-chosen location that contains the status of an event. The events are either l) physical processes such as a clock ticking or a valve closing, or 2) conceptual occurrences such as a certain string of characters typed by the operator or scheduling a task for execution. Like device flags, an Event Flag can signify either a busy or a completed state, defined as PENDING (>0) and FINISHED (=0), respectively. Thus, a task can direct another task via a message to perform a specified action, at which time it sets a mutually-agreed upon Event Flag to the PENDING value. When the second task has completed the specified action it sets the Event Flag to the FINISHED value; this is known as Posting the Event Flag. As a simple example, if the first task has been waiting for the Event Flag with the instructions: TAD Event Flag /LOAD EVENT FLAG IN AC SZA CLA /IF EVENT FINISHED, SKIP JMP .-2 /KEEP TRYING then the Posting of the Event Flag will cause the first task to exit from its loop, continuing on with the knowledge that the second task has completed its processing. Since this loop ties up the PDP-8 processor, Event Flags under RTS/8 have an additional state, WAITING (<0). Using the example just cited, the addition of the WAITING state now allows the first task to tell the RTS/8 Executive that it wants to WAIT until the Event Flag signifying the status of the second task is FINISHED. The monitor saves the contents of the waiting task's PC and sets the Event Flag Wait bit in its Task Flags Table Word. The Event Flag is set to the WAITING state. The WAITING state for an Event Flag is octal 4000 plus the waiting task's Task Number. When the Event Flag is POSTed via an RTS/8 Executive Request call, the task WAITING for it is automatically taken out of Event Flag Wait by RTS/8. (If no other blocking bits are set, the waiting task is again runnable, and will resume execution when higher priority tasks are blocked.) WAITE is the mnemonic for the RTS/8 Executive Request that Waits for an Event Flag. This code would look as follows: CAL WAITE event flag 2-2 USING TASKS UNDER RTS/8 All Executive Requests are described fully in Chapter 3. A summary of Event Flag states is shown in Table 2-1. Table 2-1 Summary of Event Flag States ------------------------------------------------- | Event Flag State | Value | |-----------------------|-----------------------| | | | | FINISHED (posted) | 0 | | PENDING | >0 | | WAITING | <0 (4000 + Task No.) | | | | ------------------------------------------------- 2.2.2 Intertask Messages Just as Event Flags under RTS/8 are analogous to hardware device flags, messages are analogous to data-sending hardware I/O instructions (for example, TLS). That is, messages start a task, providing the task is WAITING for a message, and at the same time, they pass information to the task. Messages are transmitted by Executive Requests. An RTS/8 message consists of a three-word Message Header followed by any number of contiguous words of information to be exchanged between two tasks. The Message Header is used exclusively by RTS/8. The first word of the Message Header is the Event Flag for the message. When the message is sent, the RTS/8 Executive sets the Event Flag to the PENDING state. This signifies that the message has been sent but not yet completed. No action occurs to the Event Flag upon receipt of the message by the receiving task; however, RTS/8 requires that the receiver POSTs the Event Flag when it has performed the action specified (or implied) by the message. This posting serves two purposes: 1. It informs the task which sent the message (the "sender") that the requested action has been completed, and 2. It allows the message to be sent again (see Item 2 below). If multiple messages are waiting to be received by a task, RTS/8 uses the second and third words of the Message Header to link these messages together (see Figure 2-1). The second word is a CDF (Change Data Field) instruction to the field of the next message. The third word is the address of the next message. A second word of 0 signifies that this is the last message. If the receiving task is not actively waiting for a message, the message is placed on the receiving task's Input Message Queue. Messages are then queued in order of decreasing priority of the sender (increasing task number). Messages sent from the same task are queued in the order in which they were issued. 2-3 USING TASKS UNDER RTS/8 RTS/8 EXECUTIVE MSGTBL MESSAGE 1 MESSAGE 2 MESSAGE 3 --------- ------------ ------------ ------------ <---- | CDF | /->|Event Flag| /->|Event Flag| /->|Event Flag| | --------- | ------------ | ------------ | ------------ | | PTR |__| | CDF | | | CDF | | | 0 | Message --------- ------------ | ------------ | ------------ Header | PTR |__| | PTR |__| | | | ------------ ------------ |----------| <---- | | | | | | | | | | | | | | | | | | | | Message | | | | | | Content | | | | | | | ------------ | | | | | | | ------------ <---- | | | | ------------ Figure 2-1 Message Format and Linking of Messages The rest of the message can contain any desired information. Sending a message does not physically move the message information to the receiving task, but provides the receiver with the field and address of the first data word of the message. It should be noted that the information in a message is not copied into the receiver's area. This has the following implications: 1. Data in a message should not be modified by the sender while the Event Flag for the message is PENDING. 2. The same message cannot be sent a second time before its Event Flag is FINISHED the first time. RTS/8 enforces this by checking the message Event Flag on a SEND operation and putting the sender into Event Flag Wait if the message is still PENDING. 3. It is legal for the receiving task to store information in the body of the message. In this way, an "answer" to the message can be returned without the complications of sending a return message back to the sender. For example, when a task sends a message to the disk driver task requesting I/O, the driver places the error status of the completed operation in a specific word in the message to indicate whether an error occurred. 2-4 USING TASKS UNDER RTS/8 2.3 EXECUTIVE INTERNAL TASK TABLES The Executive uses five internal tables to maintain information about the tasks in the system. A brief description of these tables is as follows: Table Description Task State Table (TSTABL) Contains information such as the contents of the task's PC, Link and AC at the time the task stopped running. Task Flags Table (TFTABL) Contains information about why the task is not running, i.e., it indicates for what conditions (blocking or wait bits) the task is waiting. Task Input Message Queue Contains messages that have been sent Header Table (MSGTBL) to this task. This table is referred to simply as the Message Table. Residency Table (RESTBL) Used for nonresident tasks, this table specifies where the task is to reside in memory, and where it resides on the swap device. Partition Table (PARTBL) Used for nonresident tasks, this table contains information about each memory partition, such as length and location of the partition. Memory partitions are shared by nonresident tasks. The user does not need to know the format of these tables to use RTS/8. However, a detailed explanation of these tables is given in Appendix E. 2-5 CHAPTER 3 RTS/8 EXECUTIVE REQUESTS 3.1 COMMUNICATION WITH THE RTS/8 EXECUTIVE RTS/8 tasks communicate with the RTS/8 Executive via Executive Requests (ERs). RTS/8 uses locations 20-27 in every field as a communication region for ERs to facilitate Executive Requests across field boundaries. The Executive can be called in any field via a JMS 20 instruction (designated symbolically as CAL). The Data Field (DF) does not have to be any specific value when the CAL is given, since the code in location 20 sets the DF to the Instruction Field (IF), sets the IF to 0 and jumps to the RTS/8 Executive. A summary of Executive Requests is given in Table 3-1. Most of the Executive Requests are explained in detail in this chapter. The RESCHD, WAITX and DERAIL Executive Requests are described in Chapter 9. The RTS/8 Executive will not honor any request to switch tasks arising from an interrupt if the interrupted task's Program Counter (PC) was less than 100(octal). This protects the RTS/8 Executive's entry point (location 20 in each field) from being destroyed. User tasks must be written so that instructions are never executed below 100 in any field. All ER's except DERAIL and SKPINS can relinquish processor control to higher-priority tasks as a result of their action. 3.2 ERs USED TO COMMUNICATE BETWEEN TASKS The five ERs associated with the Intertask Messages and the Event Flags are SEND, WAITE, SENDW, RECEIVE and POST. An example of their use is shown in Section 3.2.6. In addition, a sixth ER called WAITX is described in Chapter 9, Advanced Programming Techniques (Section 9.2.2). 3-1 RTS/8 EXECUTIVE REQUESTS Table 3-1 Summary of Executive Requests ---------------------------------------------------------------------- |Code| Symbolic | Description |Section Reference| | | Name | | | |----|----------|----------------------------------|-----------------| | | | | | | 0 | SEND | Send a message to a task | 3.2.1 | | | | | | | 1 | RECEIVE | Look for and/or receive a | 3.2.4 | | | | message from a task | | | | | | | | 2 | WAITE | Wait for an Event Flag to be | 3.2.2 | | | | posted | | | | | | | | 3 | | RUN Run a task | 3.3.4 | | | | | | | 4 | SUSPND | Suspend execution of a task | 3.3.3 | | | | | | | 5 | POST | Post an Event Flag | 3.2.5 | | | | | | | 6 | SKPINS | Insert code into interrupt | 3.4 | | | | skip chain | | | | | | | | 7 | DERAIL | Derail or force a task's | 9.2.3 | | | | execution to a new address | | | | | | | | 10 | BLKARG | Block a task from running for | 3.3.1 | | | | a specific reason | | | | | | | | 11 | SENDW | Send a message and wait for | 3.2.3 | | | | it to be received | | | | | | | | 12 | UNBARG | Remove a reason that a task | 3.3.2 | | | | is blocked from running | | | 13 | RESCHD | Force the RTS/8 Scheduler to run | 9.1.2 | | | | | | | 14 | WAITX | Wait for a particular Event | 9.2.2 | | | | Flag to be posted | | ---------------------------------------------------------------------- 3.2.1 SEND - Send Message Format: CAL SEND TSKNUM MESSAG The SEND ER sends the message located at MESSAG in the field of the CAL instruction to the task whose number is TSKNUM. If the receiving task has a higher priority than the sender and is waiting for a message, the sender is temporarily suspended and the receiver runs. In this case, the sender is not put into any WAIT state once the 3-2 RTS/8 EXECUTIVE REQUESTS message is sent. However, if the Event Flag in location MESSAG is PENDING (nonzero), meaning the message is still busy from a previous SEND, the sender will be put into Event Flag Wait on location MESSAG, and only when the Event Flag becomes FINISHED (zero) will this SEND be performed. Care should be taken that a message is sent from only one task as only the last request to send a busy message is remembered; the first task can go to sleep in Event Wait permanently. 3.2.2 WAITE - Wait on Event Flag Format: CAL WAITE EFLG The WAITE ER checks the status of location EFLG and if it is FINISHED, returns control to the caller. If EFLG is PENDING, its state is changed to WAITING and the calling task is put into Event Flag Wait. When location EFLG is POSTed by another task or interrupt routine, the calling task becomes runnable again. The Event Flag must be initialized (set to 1) before use in most cases, particularly when a task is initiating an event to be completed by another task. The waiting task must reset the Event Flag before using it again in that the Event Flag does not reset itself. NOTE In advanced applications, the user may be waiting for multiple Event Flags (see Section 9.2.1 for description of WAITM). In this case the task will run whenever any one of the Event Flags is posted, and not necessarily the one specified in the WAITE. To insure that a particular Event Flag is posted, use the WAITX ER described in Section 9.2.2. 3.2.3 SENDW - Send and Wait Format: CAL SENDW TSKNUM MESSAG The SENDW ER is exactly equivalent to the sequence: CAL SEND /SEND THE MESSAGE TSKNUM MESSAG CAL WAITE /WAIT FOR RECEIVER TO ACKNOWLEDGE MESSAG 3-3 RTS/8 EXECUTIVE REQUESTS 3.2.4 RECEIVE - Receive Message Format: TAD TSKNUM /ONLY TO RESTRICT TO ONE CAL /SENDING TASK RECEIVE MADDR, 0 /MESSAGE ADDRESS STORED /HERE; CDF TO MESSAGE /FIELD IN AC ON RETURN If the AC is zero when the RECEIVE ER is issued, the calling task's Input Message Queue is examined. If there are messages in the calling task's Input Message Queue, the first (i.e., highest-priority) message is dequeued and the address of its first data word is placed in MADDR. A CDF to the field of the message is stored in the AC. If there are no messages, the task is placed in Message Wait until such time as a message is sent to this task. However, a task may first examine its Input Message Queue Header in field 0 to determine the state of the Input Message Queue. If the AC is nonzero when the RECEIVE ER is issued, the calling task's Input Message Queue is searched for a message whose sender's Task Number matches the contents of bits 1-11 of the AC. If such a message is found, it is removed from the queue as specified above; if a message is not found, the issuing task is placed in Message Wait. This allows a message from only one given task to be received. NOTE The following information is useful to the advanced user. When a task is in MSGWT, after just having done a RECEIVE, its PC as stored in the TSTABL points back to the location containing the CAL. Thus, when a message comes in, the task re-executes the RECEIVE ER and accepts the message. This mechanism is normally transparent to the user. One implication is that no harm is caused by taking a task out of MSGWT because once the task starts up again, it will re-execute the RECEIVE ER, and go back into MSGWT. Normally, if there are no messages in the Input Message Queue when a task performs a RECEIVE, the task is put into Message Wait. However, a 1 in bit 0 of the AC (i.e., the AC is negative) when the RECEIVE is issued indicates that the task is not willing to wait. Thus, with no messages in the Input Message Queue (or none sent by the task specified in bits 1-11 of the AC), the task will then continue to run (at CAL +3) with the AC equal to zero. The zero AC provides the means for the RTS/8 Executive to inform the task that there were no messages (of the desired type) pending. 3-4 RTS/8 EXECUTIVE REQUESTS 3.2.5 POST - Post Event Flag Format: TAD EFPTR /POINTER TO EVENT FLAG CAL POST CDF EFFLD /FIELD OF EVENT FLAG The Event Flag pointed to by the AC, in the field specified by the CDF, is set to the FINISHED (zero) state. If its previous state was WAITING, the task that was waiting for it is cleared of its Event Flag Wait. This ER never sets the calling task in a WAIT state. If the task waiting for the Event Flag is of a higher priority than the calling task, the calling task is temporarily suspended while the other is run. 3.2.6 Example of ERs for Message and Event Flags The following example illustrates the RTS/8 ERs dealing with Messages and Event Flags. Since I/O and interrupts under RTS/8 have not been discussed yet, this example is elementary. There is no advantage to keeping the functions of the two tasks separate, and the entire send/receive structure is being used here as an elaborate subroutine call. A description of the execution sequence follows the example. Task A A1 ALOOP, CAL SEND /SEND TASK B MESSAGE 1 B MES1 A2 CAL SEND /SEND TASK B MESSAGE 2 B MES2 A3 CAL WAITE /WAIT FOR MESSAGE 1 MES1 A4 JMP ALOOP /LOOP MES1, ZBLOCK 3 /MESSAGE 1 15 /RANDOM NUMBERS 37 23 MES2, ZBLOCK 3 /MESSAGE 2 -1 /RANDOM NUMBERS 4 3-5 RTS/8 EXECUTIVE REQUESTS Task B B1 BLOOP, CAL RECEIVE /GET A MESSAGE MADDR, 0 B2 DCA EFCDF /SAVE MESSAGE CDF FOR POST B3 TAD EFCDF B4 DCA .+1 /PUT CDF INLINE B5 HLT /CDF TO MESSAGE FIELD B6 TAD I MADDR /GET 1ST DATA WORD OF /MESSAGE (DO NOTHING WITH IT) B7 CLA B8 STA CLL RTL /-3 IN AC B9 TAD MADDR /AC POINTS TO MESSAGE /EVENT FLAG B10 CAL POST /DECLARE MESSAGE RECEIVED EFCDF, HLT /CDF TO MESSAGE FIELD HERE Bll JMP BLOOP /LOOP The flow of execution in this example depends on which of the two tasks has higher priority. Assuming that at some time both A and B become runnable and task A has higher priority, the sequence of execution is as follows: Sequence Reason For Execution A1 Task A has higher priority than task B. A2 Task A has higher priority than task B. A3 Task A has higher priority than task B. B1 Task A is now in Event Flag Wait since MES1 was PENDING; MES1 is now in WAITING state. Sequence Reason For Execution B2-B10 Task A is still waiting; the RECEIVE at B1 received MES1 A4 The POST at B10 posted MES1 and "woke up" A, which has higher priority than B. A1 A continues executing. A2 A tries to send MES2 again; B has not yet processed it; MES2 is PENDING. Bll Therefore, A is put into Event Flag Wait and B is resumed; MES2 is now WAITING. Bl-B10 B now RECEIVes and POSTs MES2. A2 This brings A out of Event Flag Wait; the RTS/8 Executive has modified task A's program counter so that it will re-execute the offending SEND. A3 A3 now waits for MES1 to be POSTed. If task B has higher priority, the sequence of execution is: 3-6 RTS/8 EXECUTIVE REQUESTS Sequence Reason For Execution B1 Task B has higher priority than task A. A1 Task B is placed in Message Wait since there are no messages in its input queue. Task A then sends MES1 to Task B. B2-B10 Task A's message brings task B out of Message Wait; since B has higher priority, A is stopped and B runs. Bll The POST at B10 sets MES1 to FINISHED but has no other effect. B1 Now task B tries to get another message. A2 There are no other messages, so task B is put in Message Wait and A is run. B2-Bll Task A sends MES2 which "wakes up" B; B processes MES2 and B1 returns for more, A3 and is put in Message Wait. Since MES1 is FINISHED A4 the WAITE at A3 has no effect and task A A1 loops back to A1 and sends MES1 again. 3.3 ERs USED TO SET AND CLEAR TASK FLAGS Several ERs allow a task to explicitly set and clear flags in the Task Flags Table entry of another task, and to set flags in its own table entry. These ERs are BLKARG, UNBARG, SUSPND and RUN. 3.3.1 BLKARG - Block Task for Specified Reason Format: TAD TASKNUM /OR 0 IF SELF CAL BLKARG WAITBITS TASKNUM contains the number of the task to be blocked (that is, not allowed to run). WAITBITS specifies one or more bits to be set in that task's Task Flags word. Assuming WAITBITS is nonzero, this will cause the specified task to become non-runnable. If TASKNUM contains zero, the issuing task will be blocked on the specified wait bits. The TASKNUM=0 form of this ER is the only legal way to specify the issuing task as the task to be blocked; if TASKNUM is equal to the issuing task number, the action of this ER is undefined. Example: 3-7 RTS/8 EXECUTIVE REQUESTS Task 14 is placed into User Wait by executing the following code. TAD (14 CAL BLKARG USERWT Symbolic names for specifying the condition for blocking or unblocking a task in the WAITBITS word is given in Table 3-2. 3.3.2 UNBARG - Unblock Task for Specified Reason Format: TAD TASKNUM CAL UNBARG WAITBITS TASKNUM contains the number of the task to unblock, and WAITBITS specifies one or more bits to be cleared in that task's Task Flags word. If the Task Flags word becomes zero as a result of this operation, the specified task becomes runnable; if the specified task has higher priority than the issuing task and becomes runnable, the issuing task is temporarily suspended while the higher-priority task runs. This ER is a no-op (no operation) if issued with TASKNUM equal to the issuing task's number. Example: Task 14 is taken out of User Wait by executing the following code. TAD (14 CAL UNBARG USERWT 3.3.3 SUSPND - Suspend a Task's Execution Format: TAD TASKNUM /0 IF SELF CAL SUSPND This SUSPND ER is identical in action to the following instructions: TAD TASKNUM CAL BLKARG RUNWT 3-8 RTS/8 EXECUTIVE REQUESTS Table 3-2 Symbolic Names for Specifying WAITBITS ----------------------------------------------------------------------- |Symbolic Name| Value | Meaning | |-------------|-------|-----------------------------------------------| | | | | | NONRWT | 4000 | Nonresident Wait - This task cannot run| | | | because it is not in memory. | | | | | | EFWT | 2000 | Event Flag Wait - This task is waiting for an| | | | Event Flag (which contains a WAITING value| | | | corresponding to this task) to be POSTed. | | | | | | RUNWT | 1000 | Run Wait - This task is waiting for a RUN ER| | | | to be executed with its number in the AC, or| | | | for the operator to type "REQUEST task" to| | | | the Monitor Console Routine (see Chapter 5). | | | | | | SWPWT | 0400 | Swap Wait - This task cannot run because it is| | | | in the process of being brought into memory. | | | | | | EORMWT | 0200 | Event or Message Wait - This task is waiting| | | | for an Event Flag to be posted or a message to| | | | arrive, whichever happens first. | | | | | | USERWT | 0100 | User Wait - This bit is reserved for use by| | | | user-written tasks. RTS/8 does not use this| | | | bit. | | | | | | ENABWT | 0040 | Enable Wait - This task is waiting to be| | | | Enabled. Use of this bit is restricted to the| | | | Monitor Console Routine for the "ENABLE task"| | | | and "DISABLE task" commands (see Chapter 5). | | | | | | MSGWT | 0020 | Message Wait - This task is waiting to be sent| | | | a message. | | | | | | DNEWT | 0001 | Task does not exist. This bit should never be| | | | set or cleared by a user task. | ----------------------------------------------------------------------- 3.3.4 RUN - Run a Task Format: TAD TASKNUM CAL RUN This RUN ER is identical in action to the following instructions: TAD TASKNUM CAL UNBARG RUNWT 3-9 RTS/8 EXECUTIVE REQUESTS The SUSPND and RUN ERs exist because their function is performed often enough to warrant a shorthand version. An example that shows how they can be used in a task follows. A data collection task is to print a report every 1000 data points without interrupting the data collection/reduction process. When executed, the Report Generation Task comes up running, so that the first report occurs on the first data. In this simplified example, the data operated on by the report program may have been already updated for the next cycle before being reported. A full example would require a scheme such as double buffering to protect the data. Data Control Task DLOOP, TAD (-1750 /1000 DECIMAL DCA COUNT DATALP, CAL WAITE DATAEF /WAIT FOR DATA READY . /CODE TO STORE DATA . /POINT IN BUFFER . . /GET A DATA POINT ISZ COUNT /AND PROCESS IT JMP DATALP /COUNT OFF 1000 POINTS TAD (REPORT CAL /RUN REPORT TASK RUN JMP DLOOP /KEEP COLLECTING COUNT, 0 Report Generation Task RLOOP, CAL /AC=0, SUSPEND SUSPND /UNTIL NEEDED JMS TITLE /HAS BEEN RUN . . /PRINT REPORT . /WITH TITLE . . JMP RLOOP /REPORT OVER-GO /BACK AND WAIT To eliminate interference with the data collection, REPORT should have a lower priority than DATA. 3.4 USING INTERRUPTS IN RTS/8 The RTS/8 Executive contains code to receive and dismiss hardware interrupts and to perform interrupt-initiated task switching, but it does not provide room for an interrupt skip chain. Instead, the skip chain is literally a chain and is built up dynamically at system 3-10 RTS/8 EXECUTIVE REQUESTS startup time via the SKPINS ER. A description of the SKPINS ER is as follows. Format: CAL SKPINS MODULE MODULE is the address (in the current field) of an interrupt processing module. An interrupt processing module has the following format: MODULE, 0 /THIS WORD GETS A POINTER /TO THE NEXT MODULE 0 /MODULE ENTERED HERE - CONTAINS /CDF CIF TO NEXT MODULE FIELD SKDR /SKIP ON DEVICE READY (SKP) /(ONLY IF SKDR REALLY MEANS SKIP /ON DEVICE NOT READY) JMP I MODULE /NOT READY - GO TO NEXT MODULE IN /CHAIN CDF CIF CUR /THIS ONE IS MINE - SET DF AND IF /CORRECTLY . /INTERRUPT PROCESSING . . CIF 0 /DISMISS THE INTERRUPT, MAYBE POST POSTDS /AN EVENT FLAG DEPENDING UPON /CONTENTS OF AC See item 7 below for the definition of the POSTDS instruction. Whenever a task executes a SKPINS ER, the interrupt chain is broken at the very end and the user's interrupt module is inserted. This is usually done by tasks at system start-up time only. The last interrupt module points to the interrupt dismiss routine as its "next module". In this way, RTS/8 tries to avoid superfluous interrupts. SKPINS always inserts at the end of the skip chain. This implies that the skips in the skip chain are ordered roughly by priority of the task which inserted them, since any SKPINS ERs in a task are usually executed as once-only code at system start-up time. Once an interrupt module receives control (i.e., its I/O skip succeeds), there are several restrictions on its execution: 1. The interrupt module must clear the interrupt request. 2. The Data Field and Instruction Field are those of the next interrupt module; the user must correct this as described above before any indirect addressing or jumps are performed. 3. An interrupt module may not issue any RTS/8 ERs. 4. An interrupt module should not compute excessively when interrupts are off. Typical execution time should be under 3-11 RTS/8 EXECUTIVE REQUESTS 75us. If considerably more computing than this is needed, a task should be scheduled to perform it by POSTing an Event Flaq. A POSTDS instruction is used to wake up the task from Event Wait. 5. Interrupt modules must not turn interrupts on because the state of the interrupted task will be destroyed by a second interrupt. 6. On entry to the interrupt module, the contents of the AC, Link, and Data Field have already been saved, but not the contents of the Multiplier Quotient (MQ). Therefore, interrupt modules requiring the use of the MQ should save it, and then restore it before dismissing the interrupt. 7. Interrupt modules must dismiss the interrupt by setting the Instruction Field to 0 and issuing a POSTDS instruction. POSTDS is defined as a JMP I 24 instruction. An Event Flag may be POSTed when the interrupt is dismissed by setting the Data Field to the field of the Event Flag and placing the location of the Event Flag in the AC prior to issuing the POSTDS. For example: CDF CUR /DF = THIS FIELD TAD (EVFLG /EVFLG MAY NOT BE AT LOCATION 0 CIF 0 POSTDS /DISMISS INTERRUPT AND POST EVFLG If an Event Flag is not going to be posted by the interrupt routine, the AC must be cleared prior to issuing the POSTDS instruction. For example, an RTS/8 Paper Tape Punch handler task might contain the following sections of code: In the initialization code (contained in a task that is runnable at system start-up time): START, CAL /LINK THE PUNCH SKIP SKPINS /INTO THE SKIP CHAIN PTPINT GETREQ, CAL RECEIVE /WAIT FOR MESSAGE . . . As a character punch subroutine used by the main body of the task: 3-12 RTS/8 EXECUTIVE REQUESTS PUNCH, 0 /ENTER WITH CHAR IN AC DCA TEMP /SAVE CHAR CAL /WAIT UNTIL PUNCH READY WAITE PTPEF /SET PUNCH EVENT FLAG ISZ PTPEF /TO THE PENDING STATE TAD TEMP PLS /PUNCH CHAR CLA JMP I PUNCH /RETURN . . . Interrupt skip chain code: PTPINT, ZBLOCK 2 /USED TO CHAIN SKIPS PSF /CHECK PUNCH FLAG JMP I PTPINT /NOT READY CDF CIF CUR /SET CORRECT DF, IF PCF /CLEAR PUNCH FLAG TAD (PTPEF POSTDS /DISMISS INTERRUPT, /POSTING PTPEF . . . PTPEF, 0 /PUNCH INITIALLY READY TEMP, 0 RTS/8 does not provide a mechanism for removal of entries from the interrupt skip chain. 3.5 EXECUTIVE REQUEST WAIT STATES A summary of wait states generated by Executive Requests is shown in Table 3-3. 3-13 RTS/8 EXECUTIVE REQUESTS Table 3-3 Summary of Wait States Incurred by Executive Requests ---------------------------------------------------------------------- | ER | Wait State | Condition | PC Suspended At | |---------- |----------------|---------------------|-----------------| | SEND | none | EFWT for SEND if | _ | | | | message busy at | | | | | 'CAL' | | | | | | | | RECEIVE | MSGWT | If no messages | 'CAL' | | (No wait | | in Input Queue | | |if AC=4000)| | and AC positive | | | | | | | | WAITE | EFWT | If Event Flag | 'CAL'+3 | |(No wait if| | not FINISHED | | | EF 'done')| | | | | | | | | | RUN | none | _ | _ | | | | | | | SUSPND | RUNWT | If task = self | 'CAL'+2 | | | | | | | POST | none | _ | _ | | | | | | | SKPINS | none | _ | _ | | | | | | | DERAIL | none | _ | _ | | | | | | | BLKARG | any (given by | If task = self | 'CAL'+3 | | | argument) | | | | | | | | | SENDW | EFWT | If message free | 'CAL'+3 | | | | but Event Flag | | | | | not FINISHED | | | | EFWT | If message busy | 'CAL' | | | | | | | UNBARG | none | _ | _ | | | | | | | RESCHD | none | _ | _ | | | | | | | WAITX | EORMWT | If specified Event | 'CAL' | | | | Flag not FINISHED | | | | | | | | WAITM | any (given by | _ | 'CAL'+3 | | | argument) | | | | | | | | |--------------------------------------------------------------------| | NOTE: (a) 'CAL' denotes the address of the CAL instruction in the| | Executive Request. | | (b) A message is said to be busy if its Event Flag has not | | yet been POSTED by its previous user. | ---------------------------------------------------------------------- 3-14 CHAPTER 4 RTS/8 SYSTEM TASKS The RTS/8 system includes system tasks that control most of the standard Digital PDP-8 I/O devices. Also included is one task that provides interactive system control from the console terminal and allows a single copy of the OS/8 monitor system to run in the background. Foreground tasks are protected from background tasks; however, the reverse is not true. The complete list of system tasks available in the RTS/8 system is as follows: o Clock Handler - accepts requests in the form of RTS/8 messages to perform actions after a specified time has elapsed. o Console and Non-console Terminal Handlers - handle a single terminal in either line or character mode. o Line Printer Handler - supports an LS8, LS8E, LP8 or LV8 line printer. o Mass Storage Handlers - Control the passing of information from these devices to and from memory for the RK08 and RK8-E moving-head disks, DF32 and RF08 fixed-head disks, and TC08 DECtape unit. Data is read and written in the standard RTS/8 block format (400 octal contiguous words). o Floppy Disk Handler - provides support for the use of the RX8 floppy disk. o LINCtape Handler - supports both OS/8 and DIAL-format LINCtapes. o OS/8 Files Support Task - allows the user to look up, create, and delete files in OS/8 directories from a foreground task. This task, when used with the mass storage handlers, provides the capability to read or write OS/8 files on mass storage devices. o OS/8 Support Task - supports the execution of an OS/8 operating system in the background. o UDC/ICS Handler - enables the user to control the various types of UDC/ICS modules. o Cassette Handler - allows the user to read or write data on a tape cassette. o Cassette File Support Handler - allows the user to look up, enter, and delete files from a DECcassette in CAPS-8 format. 4-1 RTS/8 SYSTEM TASKS o Power Fail Task - when used with power fail hardware, it provides for an orderly shutdown when AC power is lost. Also, it allows a programmed restart when power returns. o Exit Task - allows the user to perform special processing before making an exit from RTS/8. o PDP-8A Null Task - allows the user to count in decimal on the LED display of the PDP-8A. The sources of the system tasks are supplied with the RTS/8 system. The tasks referred to as "handlers" are completely message-driven, i.e., when idle they are in the Message Wait state. Other tasks send these handlers I/O request messages. When the handler completes the I/O operation, it POSTs the Event Flag associated with the request message and issues another RECEIVE ER. 4.1 CLOCK HANDLER The Clock Handler Task can be assembled to handle any one of four hardware clocks. The user selects the clocks by setting the symbol CLKTYP in the parameter file to 0 for KD8-EA/DK8-EC, to 1 for KW12, to 2 for PDP-8A, or to 3 for DK8-EP. The Clock Handler accepts RTS/8 messages and inserts the entries into an internal clock queue. As the entries become due, they are removed from the queue, and the request is decoded and executed. The user fixes the length of the queue at assembly time by defining the symbol CLKQLN in the parameter file to the minimum number of entry slots. The default value for CLKQLN is 20. The format of a clock message is: CLKMSG, ZBLOCK 3 /3 WORDS RESERVED FOR RTS/8 COMMAND+TASKNO /TASKNO=0 MEANS TASKNO=SENDING TASK TIMEHI TIMELO EXTRA1 EXTRA2 The words TIMEHI and TIMELO specify a time interval from the present time in terms of "system ticks". The user specifies the number of system ticks in a second in the RTS/8 parameter file by defining the parameter SHERTZ. The hardware tick rate (in ticks per second) is specified by the parameter HERTZ. CLKTYP and HERTZ are determined completely by the user's hardware configuration. SHERTZ equals the reciprocal of the software system clock resolution. HERTZ must be an exact multiple of SHERTZ. For example, the parameters for a line-frequency clock might be: DECIMAL HERTZ= 120 SHERTZ= 10 indicating that there will be 10 "system ticks" per second based on a 60-cycle clock. Such parameters might be used if only 1/10 second 4-2 RTS/8 SYSTEM TASKS resolution is necessary in the Clock Handler. Note that the maximum interval that can be expressed in TIMEHI and TIMELO is (2**24)/SHERTZ seconds. This is approximately three days if SHERTZ=60. Other RTS/8 system tasks use the symbol CLOCK when referring to the Clock Handler. The user should define this symbol in the RTS/8 parameter file to be equal to the Clock Handler's task number. It should be undefined if a Clock Handler is not to be included in the system. (See Chapter 6 for a description of the parameter file.) COMMAND is the type of request and has the following meanings: Octal Symbolic Description 0000 MARKTIME POST the event flag CLKMSG after the specified interval elapses. TASKNO, EXTRA1, and EXTRA2 are ignored. 1000 SCHEDULE POST CLKMSG immediately. Execute a RUN ER on the task specified by TASKNO after the specified interval elapses. EXTRA1 and EXTRA2 are ignored. 2000 TIMOUT POST CLKMSG immediately. DERAIL the task specified by TASKNO into a subroutine whose address is specified in EXTRA1 after the specified interval elapses. EXTRA2 is ignored. 3000 SCHEDULE PERIODICALLY POST CLKMSG immediately. Execute a RUN ER on the task specified by TASKNO after the specified interval elapses, and re-queue this command with the parameters EXTRA1 and EXTRA2 in place of TIMEHI and TIMELO. This has the effect of running the specified task periodically with a period specified by EXTRA1 and EXTRA2. 7000 CANCEL Cancel all the clock requests for the task specified by TASKNO. TIMEHI, TIMELO, EXTRA1, and EXTRA2 are ignored. POST CLKMSG immediately. Note that the requests are not actually deleted and that they still occupy space in the queue until they time out. 4-3 RTS/8 SYSTEM TASKS --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- \_________/ \_______________________/ | | Command: _____________| | Task number __| 0 MARKTIME 1 SCHEDULE 2 TIMOUT 3 SCHEDULE PERIODICALLY 7 CANCEL Command Word Format - Clock Handler The Clock Handler also maintains the current time-of-day (in system ticks until midnight), in symbolic locations TODH (high-order) and TODL (low-order) in Page 0 of Field 0. When this time-of-day reaches zero (i.e., at midnight), it is reset to the quantity -(SHERTZ*86400) (24 hours until midnight) and an OS/8-format date word in symbolic location DATE in Page 0 of Field 0 is incremented by one day. Note that in order for the quantity SHERTZ*86400 to be contained in 24 bits, SHERTZ must be less than 192. If SHERTZ is larger, an assembly error will result while assembling the Clock Handler. 4.1.1 Examples of Clock Handler Calls CAL /WITH A 60HZ SYSTEM TICK RATE, SENDW /THIS CAUSES THE CURRENT TASK CLOCK /TO "GO TO SLEEP" FOR 2 SECONDS. SLEEPM . . SLEEPM, ZBLOCK 3 /MESSAGE HEADER 0 /SET EVENT FLAG AFTER INTERVAL 0;170 /INTERVAL IS 120 (DECIMAL) SYSTEM /TICKS If the user changes the value 170 to the assembler expression 2^SHERTZ, the preceding sequence becomes configuration-independent. CAL /RUN THE TASK REPORT ONCE SEND /EVERY HOUR, INDEFINITELY, CLOCK /ASSUMING A 60HZ SYSTEM TICK RATE RUNMSG RUNMSG, ZBLOCK 3 /MESSAGE HEADER SCHEDULE REPORT PERIODICALLY /RUN REPORT AFTER SPECIFIED /INTERVAL AND PERIODICALLY /THEREAFTER, 4-4 RTS/8 SYSTEM TASKS 0;1 /FIRST RUN IS ALMOST IMMEDIATELY /(1/60 SECOND) 64;5654 /PERIOD BETWEEN RUNS IS 216000 /(DECIMAL) SYSTEM TICKS = 3600 /SECONDS = 1 HOUR. 4.2 TERMINAL HANDLER The RTS/8 Terminal Handler handles a single terminal in either line or character mode. Input in line mode is terminated by a carriage return or an ALTMODE character and may be edited using the RUBOUT and ^U characters. The RUBOUT character deletes the last valid character typed and prints a backslash; the ^U character deletes the entire line and returns the carriage. Character mode input is not echoed and is terminated by overflow of a specified character count. If multiple terminals are to be handled, multiple copies of this Terminal Handler must be assembled. Assembly parameters in the body of the handler specify which device codes the handler will use to access its terminal. These parameters also specify whether the handler is to be a "console" Terminal Handler, that is, the terminal on which the MCR program is going to be run. The console Terminal Handler invokes the MCR whenever a ^C is typed on the keyboard; nonconsole terminal handlers treat ^C as any other character. For the console handler, C wakes up MCR by POSTing an Event Flag. The parameters edited into the distributed version of the Terminal Handler assemble the handler to handle the PDP-8 console terminal as a "console" device. Thus, when the MCR function is required, both the MCR task and the Terminal Handler task must be assembled and included as part of the RTS/8 system. Modification of the Terminal Handler to support a VT50 terminal and other features are described in Section 4.2.1. The format of messages to the Terminal Handler can be either of the following: ZBLOCK 3 ZBLOCK 3 command+length ASSGN+tsknum INBUF OUTTXT Description: Description: Types text specified by ASSGN=200 OUTTXT and command, then Assigns Terminal Handler to task specified reads text into INBUF. Deassigns Terminal Handler if tsknum=0 Legal Commands, which can be combined, are as follows: 4-5 RTS/8 SYSTEM TASKS Octal Symbolic Action if specified Action if not specified 4000 NOPACK Output text is in Output text is in unpacked ASCII, one packed 6-bit, two character per word characters per word terminated by a 0000. terminated by a 00. 2000 NOCRLF Do not type a CR/LF Type a CR/LF after after the message. typing the message. 1000 IND OUTTXT points to the OUTTXT is the first first word of the word of the output text. output text. 0400 NOLINE Input is in character Input is in line mode; mode; terminated terminated by a CR after 'length' input or ALTMODE (ESC). The characters read. length is still tested. Length Is a seven-bit field which specifies the maximum size of the input buffer if input is in line mode, or the number of characters to input if input is in character mode. If input is in line mode and there are LENGTH-1 characters in the input buffer, characters other than carriage return, ALTMODE, RUBOUT and ^U will not be accepted or echoed the message Event Flag is Posted. INBUF Is a pointer to the input buffer; if it is zero, no input is taken. The input buffer is filled with input characters packed one per word with the parity bit (bit 4) forced on. If input is in line mode, the last character of the line is followed by a zero word (if a carriage return terminated the line) or a -1(7777) word (if an ALTMODE character terminated the line). OUTTXT Is either the first word of the output text string (if IND=0) or a pointer to the first word of the output string (if IND=1000) in the same field as the message. ASSGN =200 "Assigns" the Terminal Handler to the specified task. This will cause the terminal handler to only accept messages from the specified task. If another task tries to SEND a message to the Terminal Handler while it is assigned, the message will be placed in the Terminal Handler's Message Input Queue but will not be removed for processing by the Terminal Handler until the assignment is released. The task to which the Terminal Handler is assigned can release the 4-6 RTS/8 SYSTEM TASKS assignment by sending a message assigning the Terminal Handler to task number 0. No I/O operation is performed by an assignment message. tsknum Is a 6-bit field used with the ASSGN command to specify the task number of the task to which the terminal is to be assigned. If this field is zero, the terminal is deassigned allowing the terminal task to accept commands from any task. --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- ^ ^ ^ ^ ^ \___________________________/ Command (bits 0-4) | | | | |__ | | | | |____ | | 0: Packed ASCII \__| | |______ | | | 1: Unpacked ASCII / |________ | | | | | | | | | 0: CR/LF at end of message \__| | | | | 1: No CR/LF at end of message / | | | | | | | | 0: OUTTXT is the first word \___| | | | 1: OUTTXT points to first word / | | | | | | 0: Input in line mode \_________| | | 1: Input in character mode / | | | | Bit 4 must be a 0 _____________________| | | Length (bits 5-11) | | If bit 3=1, no. of characters to input \____________| If bit 3=0, maximum size of input buffer / Command and Length Word Format - Terminal Handler I/O Mode --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- \_____________/ ^ ^ \_______________________/ | | | | Unused _________________| | | | | | | Bit 4 must be a 1 ________________| | | | | Unused _______________________________| Task number __| Command Word Format - Terminal Handler ASSGN Mode 4-7 RTS/8 SYSTEM TASKS 4.2.1 Additional Assembly Parameters Affecting Terminal Handler Properties Several assembly parameters are available to the user as an aid in using the TTY task. This section describes these parameters. A summary of their default values is shown in Table 4-1. VT50 =0 Do not treat CTRL/S and CTRL/Q as special characters. =1 Support CTRL/S and CTRL/Q. If this feature is enabled, typing CTRL/S while data is being printed/displayed on the terminal will cause data to stop until the next CTRL/Q is typed. This can be used on fast CRT terminals to temporarily "freeze" the screen. This parameter must be set to 1 if the user's terminal is a model VT50 or VT52 since these terminals will occasionally send synchronization characters to the host computer of their own volition. WIDTH =n Where n is an octal number that sets the page width to n characters. TTY width is currently set to 120(octal) characters. For example, setting the parameter WIDTH = 60 changes the TTY page width to 80(decimal) characters. After n characters are printed on the terminal, the handler will automatically type out a carriage-return line-feed. Sometimes it is desirable to suppress this CR/LF (for example, when using direct cursor addressing). In this case, WIDTH should be set equal to 0. SCOPE This option is used to determine treatment of the RUBOUT key as follows: SCOPE=0 provides the normal mode of RUBOUT support (echo rubouts with a backslash). SCOPE=1 causes RUBOUT to move the cursor left one position, physically removing the character from the screen. If the cursor is in column 1, RUBOUT still works, but has no visible effect. TAB This option is used to simulate tabs by the proper number of spaces. This is accomplished via the assembly parameter TAB as follows: 4-8 RTS/8 SYSTEM TASKS TAB=0 specifies that the hardware does not support tabs. The software simulates tabs with spaces. TAB=1 specifies that the hardware does support tabs. FILL Fill characters are supported via the assembly parameter FILL as follows: FILL=0 provides no fill characters. FILL=n sends n fill characters (nulls) after a line feed. The number n must be in the range 1-5. FILL=4 is recommended for 2400 baud VT05s. CONSOL CONSOL = 1 means the handler is being assembled for the console terminal(default). CONSOL = 0 means that this handler will not wake up the MCR when a ^C is typed. OLDTTY OLDTTY = 1 specifies the use of the old two-page handler which was supplied with RTS/8 version 1. This handler has fewer features than the new handler but it is a page shorter. The parameters VT50, WIDTH, SCOPE, TAB and FILL described herein have no effect when using this handler. OLDTTY = 0 specifies the use of the new 3-page terminal handler. LSBOT LSBOT = 1 specifies the listing of both the old two-page and new three-page. LSBOT = 0(default) causes only the handler selected by the OLDTTY parameter to be listed. TTFLD Specifies the field of the TTY Handler task; for example, 20 designates field 2. TTLOC Specifies the starting location of the TTY Handler task; for example, 3000 designates the starting location at 3000. 4-9 RTS/8 SYSTEM TASKS Table 4-1 Summary of Terminal Handler Assembly Parameter Default Values ---------------------------------------------------------------------- | Parameter | Default Value | Meaning | |-----------|---------------|----------------------------------------| | VT50 | 1 | Support ^S, ^Q | | | | | | WIDTH | 120 | Page width of 80(decimal) characters | | | | | | SCOPE | 0 | Rubouts echo as \ | | | | | | TAB | 0 | Simulate tabs | | | | | | FILL | 0 | No fill characters | | | | | | CONSOL | 1 | ^C wakes up MCR | | | | | | OLDTTY | 0 | Use 3-page TTY task | | | | | | LSBOT | 0 | List only TTY task selected by OLDTTY | | | | | | TTFLD | 10 | Not a default value, but given as an | | | | example to show that the given number | | TTLOC | 5000 | assignments for TTFLD and TTLOC load | | | | the TTY Handler in field 1 starting at | | | | location 5000 | ---------------------------------------------------------------------- 4.2.2 Useful Equates in the Parameter File Several useful equates (described in Section 4.2) are available which can be used when sending messages to TTY or LPT tasks. They are as follows: NOPACK = 4000 Used if output message is not 6-bit ASCII format. NOCRLF = 2000 Used if output message should not be followed by carriage return/line feed. IND = 1000 Used if OUTTXT points to the first word of the output text. NOLINE = 400 Used if input is in character mode. ASSGN = 200 Used to assign the device handler for use only by this task. KL8ALINE = 100 Used with KL8-A support (see Section 4.13.2). 4-10 RTS/8 SYSTEM TASKS 4.2.3 Examples of Terminal Handler Messages HIYA, ZBLOCK 3 /MESSAGE HEADER 0 /PACKED TEXT, END WITH CR/LF, 0 /NO INPUT TEXT /HELLO/ /TEXT TO BE OUTPUT Sending the above message to the Terminal Handler prints HELLO on the terminal. QUEST, ZBLOCK 3 /MESSAGE HEADER NOCRLF+60 /PACKED TEXT, NO CR/LF, /48-CHARACTER INPUT LIMIT ANSWER /POINTER TO INPUT BUFFER TEXT /TYPE THE ANSWER:/ Sending the above message to the Terminal Handler prints TYPE THE ANSWER: on the terminal and inputs a reply without first returning the carriage. The answer obtained from the above message could be printed on the terminal by sending the following message: TYPANS, ZBLOCK 3 /MESSAGE HEADER NOPACK+IND /UNPACKED TEXT, INDIRECT, WITH CR/LF 0 /NO INPUT ANSWER /POINTER TO OUTPUT TEXT 4.3 LINE PRINTER HANDLER The RTS/8 Line Printer Handler outputs to an LEO, LS8E, LP8 or LV8 line printer. The format of messages to the Line Printer Handler is identical to the format of messages to the terminal handler, but the INBUF word and the LINE bit are ignored (the INBUF word must, however, be present in the message). 4-11 RTS/8 SYSTEM TASKS --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- ^ ^ ^ ^ ^ \___________________________/ Command (bits 0-4) | | | | |__ | | | | |____ | | 0: Packed ASCII \__| | |______ | | | 1: Unpacked ASCII / |________ | | | | | | | | | 0: CR/LF at end of message \__| | | | | 1: No CR/LF at end of message / | | | | | | | | 0: OUTTXT is the first word \___| | | | 1: OUTTXT points to first word / | | | | | | 0: Input in line mode \_________| | | 1: Input in character mode / | | | | Bit 4 must be a 0 _____________________| | | Length (bits 5-11) | | If bit 3=1, no. of characters to input \____________| If bit 3=0, maximum size of input buffer / Command and Length Word Format - Line Printer Handler I/O Mode --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- \_____________/ ^ ^ \_______________________/ | | | | Unused _________________| | | | | | | Bit 4 must be a 1 ________________| | | | | Unused _______________________________| Task number __| Command Word Format - Line Printer Handler ASSGN Mode 4.4 MASS STORAGE HANDLERS Handlers are available for TC08 DECtape, DF32 and RF08 fixed-head disks, RK8 and RK8E moving-head disks, RX01 floppy disks and LINCtape. All mass storage handlers accept the same message format to read or write blocks on various mass storage devices. However, the Floppy Disk Handler and the LINCtape Handler allow the use of additional parameters other than the ones described herein. These parameters are described in Sections 4.4.1 and 4.4.2. 4-12 RTS/8 SYSTEM TASKS The format of messages to mass storage handlers is: MSMESG, ZBLOCK 3 UNIT RW + PAGES + FIELD BUFADD BLOKNO STATUS where: UNIT Is the number of the logical unit on which the operation is to be performed. DF32 and RF08 disks consist of only one unit. TC08 DECtape has logical units 0-7 corresponding to its physical units 0-7. LINCtape has logical units 0-7 corresponding to its physical units 0-7. RK8 disk has logical units 0-3 corresponding to its physical units 0-3. RK8E disk has logical units 0-7. Units 0-3 correspond to the outer (lower track number) half of physical units 0-3, and units 4-7 correspond to the inner (higher track number) half of physical units 0-3, respectively. RX01 has units 0 or 1 which corresponds to the left and right drive, respectively. RW Is 0 for a read operation, 4000 for a write operation. PAGES Specifies the number of (128-word) pages to transfer (times 100 octal). For example, PAGES=2000 specifies the transfer of 20(octal) pages or 2048 words; if PAGES=0, 40(octal) pages or 4096 words are transferred. FIELD Is the PDP-8 field in which the transfer takes place (times 10 octal). For example, if FIELD=30, the transfer takes place in field 3. The RW+PAGES+FIELD word is sometimes called the function word of the message. --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- \_____________________________/ \_______________/ | | Reserved for task use ______| | | Unit ________________________________________________| Unit Word Format - Mass Storage Handlers 4-13 RTS/8 SYSTEM TASKS --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- ^ \_________________/ \_________/ \___________/ | | | | 0: Read operation \_| | | | 1: Write operation / | | | | | | No. of pages to transfer ________| | | | | 0-7 Field of transfer ___________________________| | | Reserved for task use ________________________________________| Function Word Format - Mass Storage Handlers BUFADD Is the starting address of the buffer to be transferred. BLOKNO Is the block number on the device from which the transfer will begin. All devices are assumed to have 256-word blocks. On DECtape, the first 128 words of each of an even/odd pair of 129-word DECtape records are considered to be a block. STATUS Is a word that the handler sets on completion of the operation. It contains a zero if the operation is successful, otherwise it will contain a nonzero quantity which is the contents of the device status register. Tasks which use the mass storage handlers should test this word after the I/O operation has been completed (that is, after the Event Flag has been POSTed) to determine if any errors occurred during the transfer. All RTS/8 mass storage handlers retry operations three times if errors are encountered before setting the STATUS word to a nonzero. Note that the middle three words of a message to the RTS/8 mass storage handlers are identical to the arguments to an OS/8 handler when the same operation is performed. 4.4.1 Floppy Disk Handler Each copy of the Floppy Handler can control one single or dual RX01 drive; for more than one RX01, multiple copies of the handler are required. The format of messages to the Floppy Disk Handler is: ZBLOCK 3 CODE+DEL+MODE+UNIT RW+PAGES+FIELD BUFADD BLOKNO STATUS 4-14 RTS/8 SYSTEM TASKS where: CODE = 0 Regular condition. BLOKNO is interpreted as an OS/8 logical record number. Also, PAGES is interpreted in the OS/8 sense to mean the number of pages of data to transfer. The DEL bit is ignored. = 4000 Special Physical Sector Condition. PAGES is ignored. One sector is transferred. It is specified by BLOKNO which is to be interpreted as TTTTTTTSSSSS. That is, the high order 7-bits of BLOKNO represent the physical track number. This number must be in the range 0-76 decimal (0-114 octal). The low order 5 bits of BLOKNO represent the sector number on that track. This number must be in the range 1-26 decimal (1-32 octal). DEL = 0 Deleted data marks should not be considered. = 2000 Handle deleted data marks (if CODE=4000) as follows: If writing a sector, write deleted data indication. Do not note this fact in STATUS word. If reading a sector, set bit 5 of STATUS word to a 1 if read deleted data indication. In such a case, the STATUS word may be nonzero even though no physical error has occurred. Other STATUS bits are relevant and STATUS negative means hard error. MODE = 0 Specifies transfer in 12-bit mode. = 100 Specifies transfer in 8-bit mode. OS/8 format uses 12-bit mode. In 12-bit mode, the 64 12-bit words that comprise an OS/8 floppy sector are packed into the first 96 bytes of the sector, while the last 32 bytes contain random bit patterns. In 8-bit mode, an 8-bit byte on the floppy disk corresponds to the low order 8-bits of a 12-bit word in memory. Data in the high order 4 bits of a word in memory is not transferred to the floppy disk. In 12-bit mode, a sector contains 64 (decimal) 12-bit words of data. In 8-bit mode, a sector contains 128 8-bit bytes of data. UNIT = Specifies the drive unit number. It may be 0 or 1. The number 0 refers to the unit on the left of a dual drive. RW = 0 Read data from floppy disk. = 4000 Write data to floppy disk. 4-15 RTS/8 SYSTEM TASKS PAGES = Specifies the number of pages to transfer (times 100 octal). Pages = 0 transfers 40 pages (a full field). This value takes the range 0-37 in bits 1-5 of this word. PAGES is ignored if CODE = 4000. In that case, either 100 (octal) 12-bit words or 200 8-bit bytes (from 200 words) are transferred depending on MODE. FIELD = Specifies the field of buffer (times 10 octal). Bits 6-8 of this word have the range 0-7. BUFADD = Specifies the address of the first word of the buffer containing data. Field of buffer is determined by FIELD. Length of buffer depends on PAGES if CODE = 0 or on MODE if CODE = 4000. BLOKNO = Represents first logical OS/8 block to transfer if CODE = 0. Each OS/8 block consists of 4 sectors. Track 0 is ignored and a 2-to-1 interleave scheme is employed. If CODE = 4000, this word contains physical track and sector numbers in the format TTTTTTTSSSSS. STATUS = Receives the status of the operation upon completion. If negative, a hard error has occurred. If 0, no error has occurred. This word may be positive nonzero only if DEL = 2000. The meaning of the STATUS bits is as follows: Bit Meaning if 1 0 Hard error 1-3 Not used by controller 4 Not used by RTS/8 5 Deleted data indication 6-7 Not used by controller 8 Reserved for future use by controller 9 INIT done (can occur after temporary power failure to controller) 10 Parity error 11 CRC error NOTE On power fail restart, the INIT error might occur. When this error occurs, the calling task should send the I/O message again. 4-16 RTS/8 SYSTEM TASKS --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- ^ ^ ^ ^ | | | | 0: Regular condition\| |_________ | | 1: Special physical / | | | sector condition/ | | | | | | 0: Do not handle deleted marks \__| | | 1: Handle deleted marks / | | | | 0: Transfer in 12-bit mode \_____________| | 1: Transfer- in 8-bit mode / | | 0: Left unit of dual drive \______________________________________| 1: Right unit of dual drive / CODE = 4000 (bit 0 set to 1) transfers one sector specified by BLOCKNO as follows: --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- \_________________________/ \___________________/ | | Physical track no. \__________| | (0-114 octal) / | | Sector no. on track \__________________________________| (1-32 octal) / Unit Word Format - Floppy Disk Handler --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- ^ ^ ^ ^ ^ | | | | | Hard error _______| | | | | | | | | Deleted data _________________________| | | | | | | INIT done ____________________________________________| | | | | Parity error ______________________________________________| | | CRC error ______________________________________________________| Status Word Format - Floppy Disk Handler 4-17 RTS/8 SYSTEM TASKS The largest legal OS/8 block number on a floppy disk is 755 octal. If block 756 is referenced, an error is generated. Use of larger block numbers may produce unpredictable results. Specifying an illegal track or sector may produce an error with STATUS = 4000. The standard OS/8 Interleave Scheme is as follows: OS/8 Logical Block (octal) Floppy Sectors (track/sector in decimal) 0 1/1, 1/3, 1/5, 1/7 1 1/9, 1/11, 1/13, 1/15 2 1/17, 1/19, 1/21, 1/23 3 1/25, 1/2, 1/4, 1/6 4 1/8, 1/10, 1/12, 1/14 5 1/16, 1/18, 1/20, 1/22 6 1/24, 1/26, 2/1, 2/3 7 2/5, 2/7, 2/9, 2/11 10 2/13, 2/15, 2/17, 2/19 11 2/21, 2/23, 2/25, 2/2 12 2/4, 2/6, 2/8, 2/10 13 2/12, 2/14, 2/16, 2/18 14 2/20, 2/22, 2/24, 2/26 15 3/1, 3/3, 3/5, 3/7 . . . Track 0 is not used by OS/8, and cannot be accessed in the 12-bit mode. 4.4.2 LINCtape Handler The LINCtape Handler supports both OS/8 and DIAL format LINCtapes. The format of messages to the LINCtape Handler is: ZBLOCK 3 MODE+UNIT RW+PAGES+FIELD BUFADD BLOKNO STATUS where: UNIT= Specifies the LINCtape unit number in range 0 to 7. MODE=0 Specifies OS/8 Mode. A LINCtape is presumed to contain 200 or 201 (octal) words per physical block. =4000 Specifies DIAL Mode. A LINCtape is presumed to contain 400 (octal) words per physical block. 4-18 RTS/8 SYSTEM TASKS Note: The LINCtape used is not checked to see if it is properly formatted for the specified mode. Use of a LINCtape with improper physical format will produce unpredictable results. RW =0 Read data from LINCtape =4000 Write data to LINCtape PAGES Specifies the number of 128-word pages to transfer (times 100 octal). For example, PAGES=2000 transfers 20 octal pages or 2048 words; if pages=0, 40 octal pages or 4096 words are transferred. FIELD Specifies the PDP-8 field in which the transfer takes place (times 10 octal). (For example, FIELD=30, the transfer takes place in field 3). BUFADD Is the starting address of the buffer to be transferred. BLOKNO Is the block number on the device from which the transfer will begin. All devices are assumed to have 256-word blocks. On OS/8 LINCtapes, two consecutive physical blocks comprise one OS/8 logical block. Only the first 128 words in each physical block contain meaningful data. When running in DIAL mode, BLOKNO represents a physical LINCtape block number. In this case, PAGES must be even because an even number of pages is transferred. If PAGES is (incorrectly) odd, the last page is not transferred, except if PAGES=1 which will result in one block (2 pages) being transferred. STATUS is the ones complement of tape check (checksum). The value 0 means no error. STATUS is always 0 on a Write operation. Three software retries are attempted on a checksum read error. Note that the hardware performs infinite retries on most errors (write-lock-out, tape not mounted, bad spot on tape) and does not return control to RTS/8 until successful. CAUTION In the OS/8 mode, the word following the end of the buffer is temporarily destroyed while a LINCtape operation is in progress. The location is then restored upon completion of the operation. However, since RTS/8 is a 4-19 RTS/8 SYSTEM TASKS real-time system, code may be executing while the tape operation is in progress. The user must make sure that this word is never referenced while the LINCtape is being used. Under no circumstances should the word following the end of the buffer belong to another task. --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- ^ \___________/ 0: OS/8 mode \___| | 1: DIAL model / | | Unit number _______________________________________________| Unit Word Format - LINCtape Handler 4.4.3 Example of Mass Storage Handler Call CAL SENDW DTA /SEND A MESSAGE TO THE DECTAPE /HANDLER DTAMSG /AND WAIT FOR COMPLETION TAD STATUS /CHECK THE STATUS OF THE OPERATION SZA CLA JMP ERR /BAD - GO TO ERROR ROUTINE /OK - CONTINUE PROCESSING . . . DTAMSG, ZBLOCK 3 /MESSAGE HEADER 4 /DECTAPE UNIT 4 4210 /WRITE 256 WORDS FROM FIELD 1 BUFFER /ADDRESS OF BUFFER 55 /INTO BLOCK 55 (RECORDS 132 & 133) STATUS, 0 /STATUS OF OPERATION STORED HERE 4.5 POWER FAIL TASK The Power Fail Task provides the mechanism by which the system recovers from power failure. If the power-fail/auto-restart hardware option is present and if the system parameter PWRFAL was equated to a nonzero value, the SPL (Skip on Power Low) instruction is included in the interrupt skip chain. If a power low condition occurs, the processor state is saved and the processor is halted. When power comes back, the processor state is restored and an Event Flag is POSTed which wakes up the Power Fail Task. The Power Fail Task restores the clock, console terminal, and OS/8 terminal if they are 4-20 RTS/8 SYSTEM TASKS present, and also performs an action for each task in the system based on the contents of an internal table. Each task has a one-word entry in this table, which contains: 0 If nothing should be done for this task (default value) -1 If the EFWT (Event Flag Wait) bit should be cleared in the Task Flags Table entry for this task (i.e., this task should be taken out of Event Flag Wait) ADDR If the task should be DERAILed to location ADDR in the field in which it is executing as well as having its EFWT bit cleared. Each task in the system may alter its entry in the Power Fail Task's table by sending a message to the Power Fail Task. The format of the message is: PWRMSG, ZBLOCK 3 WORD where: WORD is the new contents of the Power Fail Task's table entry for the sending task. 4.6 OS/8 SUPPORT TASK The OS/8 Support Task supports the execution of the OS/8 operating system as a task under RTS/8. OS/8 is run in the top two or more memory fields under control of the KM8-E memory extension and timeshare option (standard on PDP-8/E, 8/F, or 8/M with 8K or more of core memory) or TSS-8 time sharing hardware option. NOTE A jumper on the KM8-E module is used to select the timeshare function. The module is shipped with this jumper in place (timeshare function disabled). The PDP-8A utilizes the memory extension and timeshare option provided by the KM8-A extended option board. A switch on the KM8-A module is used to enable the timeshare function. The OS/8 Support Task is configured at system startup time to establish a correspondence between OS/8 devices and RTS/8 handler tasks. Terminal input and output from OS/8 are ring-buffered by several characters to minimize input loss due to the usurpation of the CPU by tasks of higher priority. Because of the large number of trapped CDF instructions in OS/8 and its Commonly Used System Programs 4-21 RTS/8 SYSTEM TASKS (CUSPs), response time is slower than a stand-alone OS/8 system but still quite reasonable. The background OS/8 task must have the same system device that was used by the OS/8 system to load RTS/8. The OS/8 Support Task cannot run on a stand-alone PDP-8 without OS/8. Several parameters in the system parameter file control the assembly of the OS/8 Support Task. The parameters and their meanings are as follows: OSFLDS Defined as the number of fields to be dedicated to OS/8. Example: OSFLDS=2 specifies two fields or 8K of memory for OS/8. OSKBDV Set equal to the keyboard IOT code of the OS/8 terminal. Example: OSKBDV=03 specifies the use of the console terminal keyboard of OS/8. Note: OS/8 requires its own dedicated terminal. OSTTDV Set equal to the teleprinter IOT code of the OS/8 terminal. Example: OSTTDV=04 specifies the use of the console teleprinter for OS/8. OSFILL Specifies how many null characters must follow a line-feed character on the OS/8 terminal. This allows high-speed VT05 terminals to be used as OS/8 terminals. For standard Teletypes and DECwriter terminals, this parameter should be set to zero. Example: OSFILL=4 allows the use of a 2400 baud VT05. OSSYSD Specifies the OS/8 system device driver task. Example: OSSYSD=DTA specifies DTA0 as the OS/8 system device. NOTE The user does not need to include a terminal driver for the OS/8 terminal device (it is built into OS8SUP). The OS/8 system that runs under the OS/8 Support Task runs all OS/8 CUSPs except BUILD, BOOT, PIP10, INDUSTRIAL BASIC, and BASIC and FORTRAN LAB runtime functions. All references to the keyboard and teleprinter are diverted to the specified OS/8 keyboard and teleprinter. References in OS/8 to the LEO, LS8E, LP8 or LV8 line printers are diverted to the RTS/8 line printer handler if the system parameter LPT is defined; otherwise they are executed directly by the Support Task. References to the following OS/8 device names will be diverted to the corresponding RTS/8 handler if one is defined: 4-22 RTS/8 SYSTEM TASKS DTA0-DTA7 LTA0-LTA7 RKA0-RKA3 RKB0-RKB3 RXA0-RXA7 If one is not defined, OS/8 will perform the I/O directly using the standard OS/8 handler. In addition, the OS/8 handlers SYS and DSK are diverted to the handler specified by the parameter OSSYSD. Other references to I/O under the supported OS/8 system may cause the OS/8 support task to hang in a loop. References to a handler called RTS8 are diverted to OS8COM (see Section 4.7). 4.6.1 Mapping of Fields with OS/8 Support Task The parameter HGHFLD in the parameter file must specify the highest field available to the entire RTS/8-OS/8 system. This is usually the highest field available in memory (e.g., 30 for a 16K machine). The OS8SUP task maps OS/8 fields into real fields as follows. The field which OS/8 uses as field 0 is actually HGHFLD. OS/8 fields 1, 2, 3, etc. are mapped into consecutive fields beginning with field HGHFLD-OSFLDS+1, proceeding upward. If an OS/8 program references a field greater than HGHFLD, unpredictable results will occur, as these fields are mapped over the lower OS/8 fields. The software core size is correctly set to OSFLDS and should be used by multi-field OS/8 programs. 4.7 OS/8 - RTS/8 COMMUNICATION (OS8COM) The OS/8 Support Task contains a mechanism by which OS/8 can talk to an RTS/8 task. To perform this communication, the OS/8 system must be configured with a handler called RTS8. This handler can be a dummy; it need not do anything. In fact, it can be some other handler to which the name RTS8 has been assigned. The OS/8 Support Task traps all calls to this handler. The arguments that are passed to the RTS8 handler by an OS/8 program will be passed to an RTS8 task called OS8COM. The user is responsible for writing this OS8COM task. The OS8COM task performs an RTS/8 RECEIVE ER. The task can then receive a message any time an OS/8 program reads or writes to the RTS8 handler. This message looks like any other message to a mass storage device. OS8SUP does make one change to the arguments. Bits 6 through 8 of the function word originally contain the field of the buffer. This is the field where OS/8 expects the buffer to be. When OS8COM gets control, these bits identify the actual field that contains the buffer. OS8COM can return information to OS/8 through these arguments. 4-23 RTS/8 SYSTEM TASKS 4.7.1 Using the OS8COM Task An OS/8 program that runs an RTS/8 task as specified by the OS/8 user is shown in the following example. Example: USR=7700 /LOCATION OF OS/8 USER SERVICE ROUTINE JMS PRINT /PRINT MESSAGE "WHAT TASK WOULD YOU /LIKE TO RUN?" ON THE OS/8 TERMINAL JMS READ /READS RESULT FROM OS/8 KEYBOARD /RETURNS TASK NUMBER IN RANGE 1-77 / IN AC DCA TASKNUM /STORE IT AWAY CIF 10 JMS I (USR /CALL USR 1 /TO DO A FETCH DEVICE RTS8 /OF DEVICE 'RTS8' ENTRY, ADDR /DUMMY ADDRESS (HANDLER WILL ALREADY /BE RESIDENT HLT /ERROR (HANDLER NOT FOUND) /NOTE THAT THIS CODE IS NOT REUSABLE AND THAT LOCATION /' ENTRY ' IS SET TO THE ENTRY POINT FOR THIS HANDLER CIF 0 JMS I ENTRY /CALL HANDLER 0 /DUMMY READ TASKNUM, 0 /TASK NUMBER ZBLOCK 2 /DUMMY JMP I (7605 /RETURN TO OS/8 It should be noted that TASKNUM is being passed as the second argument instead of the first because OS8SUP automatically modifies bits 6-8 of the first argument, presuming that a mapped field number is located there. OS8COM expects three arguments after the handler call plus an error return. These must be specified by the user. Where the OS/8 portion of the program has been written, the OS8COM task that handles the RTS/8 side of the communication must be written. OS8COM is written like any other RTS/8 user task, and an example of what it might look like is as follows: TASK=OS8COM /OS8COM IS ASSIGNED A PRIORITY IN THE /PARAMETER FILE INIWT=0 /COMES UP RUNNING CUR=40 /SPECIFY FIELD HERE FIELD CUR%10 *200 /STARTING ADDRESS START, CAL RECEIVE /IMMEDIATELY GO INTO RECEIVE WAIT MADDR, 0 /ADDRESS OF MESSAGE LEFT HERE DCA MSGFLD /CDF TO MESSAGE FIELD LEFT IN AC MSGFLD, HLT ISZ MADDR /POINT TO FUNCTION WORD ISZ MADDR /POINT TO BUFFER ADDRESS /(SECOND OS/8 ARGUMENT) 4-24 RTS/8 SYSTEM TASKS TAD I MADDR /GET TASK NUMBER CAL RUN /RUN THIS TASK /OS8COM WANTS TO BE HIGHER /PRIORITY THAN TASK IT IS RUNNING TAD MSGFLD DCA EFCDF TAD (-5 TAD MADDR /GET ADDRESS OF EVENT FLAG /FOR MESSAGE CAL POST /POST MESSAGE EFCDF, HLT JMP START /GET ANOTHER MESSAGE In this example, the task number was put in the second argument of the OS/8 call. However, it became the third word of the RTS/8 message because OS8SUP always adds a word to the mass storage call argument list, namely the unit number. For a description of the OS/8 standard handler call format, see Section 4.1 of the OS/8 Software Support Manual. For a description of the standard message format for mass storage devices, see Section 4.4 of this manual. 4.7.2 Other Techniques Other techniques which can be employed by the user are as follows: 1. If the RTS/8 handler STATUS word (word 5) of the message posted by OS8COM is nonzero, then return is taken to OS/8 at the error return of the handler call. 2. Arguments may be passed back to OS/8 through the argument list. 3. If more than three words of data need to be passed to OS8COM from OS/8, the user can pass a CDF and address of the area where the data resides. If the CDF occurs as the first argument to the handler call, it automatically will be relocated before being passed to OS8COM. 4.8 OS/8 FILE SUPPORT TASK The OS/8 File Support Task (OS8F) allows other tasks to look up, create, and delete files in OS/8 directories. This task is included in the same source file as the OS/8 Support Task, but the user can assemble it independently of that task (depending on which tasks are defined in the system parameter file). The format of messages to OS8F is: 4-25 RTS/8 SYSTEM TASKS OSFMSG, ZBLOCK 3 DEVHND^10+UNIT+FUNCT FILPTR STATUS BLOKNO LENGTH where: DEVHND Is the task number of the handler for the desired device. UNIT Is the unit number on which the operation is to be performed. FUNCT Represents the function to be performed. It can have the following values: 0 Looks up the specified filename and returns its starting block number in BLOKNO, and its length in LENGTH (as a two's complement number). 2000 Enters the specified filename into the first empty space (on the device) whose length is equal to or exceeds the value in LENGTH. Returns the starting block number of the new file in BLOKNO. If a file of the same name previously existed on the device it is deleted. The value of LENGTH is unchanged. 4000 Deletes the specified filename. FILPTR Is a pointer to a 4-word filename in the same field as the message. The PAL8 pseudo-op FILENAME can be used to generate these filenames. STATUS Describes the final status of the operation as follows: 0 Operation successful. 1 File not found on Lookup or Delete. 2 No room for file on Enter. >2 I/O error occurred. The value is the hardware error status of the device. -1 Invalid directory on device. 4-26 RTS/8 SYSTEM TASKS --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- \_____/ ^ \_____________________/ \___________/ | | | | Function: __________| | | | O Lookup | | | 1 Enter | | | 2 Delete | | | 3 Unused | | | | | | Unused ___________________| | | | | Task number ____________________________| | | Unit ______________________________________________________| OS8F Call Function Word If both OS8F and the OS/8 Support Task are present in a system, an interlock is set up to prevent simultaneous updating of directory blocks by both systems. Because OS/8 tends to leave directory blocks in memory for long periods of time, this interlock scheme causes lengthy delays for the OS8F task. Before a Delete or Enter operation is performed, OS8F waits until OS/8 is in a state in which: 1. There is no active temporary file on the OS/8 device corresponding to DEVHND and UNIT. 2. OS/8 has just loaded the Keyboard Monitor, Command Decoder, or USR into core. Look up operations are not interlocked since they do not modify the directory. 4.9 UNIVERSAL DIGITAL CONTROLLER/INDUSTRIAL CONTROLLER SUBSYSTEM (UDC/ICS) HANDLER The UDC/ICS handler gives the user the capability to control the various types of UDC/ICS functional devices. This handler performs two types of action: immediate and associated. Immediate actions include reading and sending analog and digital values to appropriate UDC/ICS functional devices. Associated actions can be linked to specified events within the UDC/ICS (counters overflowing, switches being thrown). The associated actions can do the following: 1. Run a specified task when the event occurs 2. Set the Event Flag when the event occurs 3. DERAIL a specified task when the event occurs The number of associated requests that can be pending simultaneously is determined by the size of the buffer, which is specified by the assembly parameter RINGBUF. 4-27 RTS/8 SYSTEM TASKS The UDC/ICS handler permits the following operations: 1. Analog Output - send a 10-bit value to an analog channel 2. Analog Input - accept input from analog subchannel 3. Digital Output - send a 12-bit value to a digital channel 4. Digital Input - read a digital channel 5. Get Generic Code - determine the generic code for a specified channel 6. Enable Counter - permit interrupts from a counter channel 7. Read Counter - read current value of the counter channel 8. Disable Counter - disable interrupts from a counter channel 9. Enable Contacts - permit interrupts from a contact channel 10. Change Of State - find the current COS value for a contact channel 11. Disable Contacts - ignore interrupts from a contact channel Each operation is discussed in detail below, including the format of the message for specifying the operation. The first three words are required for use by the Executive. Word 4 specifies one of the 11 UDC/ICS operations which are as follows: AO=0; DO=1; DI=2; GC=3; EC=4; RC=5; DC=6; ECT=7; CS=10; DCT=11; AI=12. Word 5 designates the channel being used for the indicated operation. Words 6 through 8 may be required to completely specify the operation, and the number used is dependent upon the operation. The word that follows the last word specifying the desired operation is used for the value read or the value returned. Word 10 of all UDC/ICS messages contains the error state. The general format for a UDC/ICS message is: ZBLOCK 3 OPERATION CHANNEL OPWORD1 OPWORD2 OPWORD3 VALUE STATUS 4-28 RTS/8 SYSTEM TASKS 4.9.1 AO Analog Output Format: AO channel number subchannel & value Channel number is the analog output channel. The subchannel and value word is formed by the subchannel (0-3) in bits 0 and 1 and the 10-bit value in bits 2-11. For example, a message for an analog output operation: AOEX, ZBLOCK 3 AO /ANALOG OUTPUT 23 /CHANNEL 23 4614 /SUBCHANNEL 2, VALUE 614 ZBLOCK 3 AOER, 0 /ERROR INDICATOR --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- \_____/ \_______________________________________/ ^ ^ Subchannel _________| | | Value ______________________________________| Subchannel and Value Word Format - UDC/ICS Handler 4.9.2 AI Analog Input Format: AI channel subchannel & gain answer where channel is the analog input channel. The subchannel and gain word need only specify the gain in bits 1-3 and the subchannel in bits 9-ll for UDC, and 5-11 for ICS. The handler automatically sets bit 0 (enable conversion) and read control register (UDC bit 8; ICS bit 4). The ICS analog converters must have addresses which are less than 20 (octal) since all converter modules must be located in the first 16 slots of the ICS unit. After conversion, the digitized value is placed in the answer word. 4-29 RTS/8 SYSTEM TASKS --------------------------------------------------- | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | --------------------------------------------------- ^ \_________/ ^ \___________________________/ | | | | Enable conversion _| | | | | | | Gain ______________________| | | | | ICS read control register; ________| | (for UDC, bit 8) | | ICS subchannel; ___________________________________| (for UDC, bits 9-11) Subchannel and Gain Word Format - UDC/ICS Handler An example of a message for an analog input operation is as follows: AIEX, ZBLOCK 3 AI /ANALOG INPUT 17 /CHANNEL 17 3 /SUBCHANNEL 3, GAIN 1 AIANS, 0 /RESULT HERE ZBLOCK 2 AIERR, 0 /ERROR INDICATOR The user should ensure that for each major channel there is sufficient time (approximately 250 microseconds for UDC; 5 milliseconds for ICS) for each subchannel conversion to be completed before another is indicated. In general, it may be helpful if all A/D conversions for a major channel are initiated from the same task. 4.9.3 DO Digital Output Format: DO channel value Channel is a legal digital output channel and value is the number to be output. For example: DOEX, ZBLOCK 3 DO /DIGITAL OUTPUT 20 /CHANNEL 20 7777 /VALUE = 7777 ZBLOCK 3 DOER, 0 /ERROR INDICATOR 4-30 RTS/8 SYSTEM TASKS 4.9.4 DI Digital Input Format: DI channel result Channel is the appropriate digital input channel and result will contain the value of the channel when read. For example: DIEX, ZBLOCK 3 DI /DIGITAL INPUT 27 /CHANNEL 27 DIANS, 0 /VALUE OF CHANNEL 27 WILL BE PUT /HERE ZBLOCK 3 DIER, 0 /ERROR INDICATOR 4.9.5 GC Generic Code Format: GC channel result The generic code of the specified channel is put in result. For example: GCEX, ZBLOCK 3 GC /DETERMINES GENERIC CODE 27 /CHANNEL 27 GCANS, 0 /GENERIC CODE PUT HERE ZBLOCK 3 GCER, 0 /ERROR INDICATOR Generic codes are as follows: 0 - No interrupt; 1 - Controller error; 2,3 - Contact Interrupt Modules; 4 - Counter Module; 7 - A/D converter. 4.9.6 EC Enable Counter Format: EC channel initial value reload value event action address Channel is the counter channel to be enabled, initial value is the first value to be loaded into that channel, and reload value is the value with which to reload the channel after every event. If the reload value is 0, the counter is not reloaded. The event action and address words specify what happens when the counter interrupts. There are three mutually exclusive possibilities, indicated by setting the appropriate bit in the event action word as follows: 4-31 RTS/8 SYSTEM TASKS Bit 0 = 1 - Set Event Wait Flag of this job; continue execution of this job when the event occurs. Address word not used. Bit 1 = 1 - Run a task that sent the message; run task specified by bits 4-11 of event action word. Address word not used. Bit 2 = 1 - DERAIL the task that sent the message; the address word is only used by the DERAIL operation and specifies the address of the DERAIL subroutine. The subroutine must be in the same field as the calling task. Bit 3 = 1 - Do action just once. If bit 3 = 0, specified action is performed after each interrupt. Bit 3 indicates whether action is to occur once or repeatedly. Several enable counter examples follow: ECEX1, ZBLOCK 3 EC /ENABLE COUNTER 4 /CHANNEL 4 7700 /INITIAL VALUE OF 7700 7710 /RESET TO 7710 AFTER EACH EVENT 4000 /POST EVENT FLAG ON EVENT EVERY TIME /IT OCCURS 0 /UNUSED ECER1, 0 /ERROR INDICATOR ECEX2, ZBLOCK 3 EC /ENABLE COUNTER 4 /CHANNEL 4 1205 /INITIAL VALUE OF 1205 0 /DON'T RESET 2016 /RUN TASK 16 ON EVENT EVERY TIME IT /OCCURS 0 /UNUSED ECER2, 0 /ERROR INDICATOR ECEX3, ZBLOCK 3 EC /ENABLE COUNTER 5 /CHANNEL 5 10 /INITIAL VALUE OF 10 7700 /RESET TO 7700 1015 /DERAIL TO TASK 15 EVERY TIME IT /OCCURS 5620 /AT LOCATION 5620 ECER3, 0 /ERROR INDICATOR 4-32 RTS/8 SYSTEM TASKS 4.9.7 RC Read Counter Format: RC channel result where channel is the counter channel whose current value is to be read. That value is placed in result. For example: RCEX, ZBLOCK 3 RC /READ COUNTER 6 /CHANNEL 6 RCANS, 0 /VALUE OF CHANNEL 6 PUT HERE ZBLOCK 3 RCER, 0 /ERROR INDICATOR 4.9.8 DC Disable Counter Format: DC channel where channel is the counter channel from which interrupts are to be ignored. For example: DCEX, ZBLOCK 3 DC /DISABLE COUNTER 6 /CHANNEL 6 DCER, ZBLOCK 4 0 /ERROR INDICATOR 4.9.9 ECT Enable Contacts Format: ECT bit & channel event action address where the bit & channel word specifies the bit on the contact channel from which to enable interrupts. Channel is specified in bits 4-11 and the contact bit is packed in bits 0-3 as a value from 0-13(octal). Event action and address are specified in the same manner as in the enable counter function. For example: ECTEX1, ZBLOCK 3 ECT /ENABLE CONTACTS 5401 /FROM BIT 13(OCTAL) OF CHANNEL 1 2013 /RUN TASK 13 AFTER AN EVENT OCCURS ZBLOCK 3 ECTElR, 0 /ERROR INDICATOR ECTEX2, ZBLOCK 3 4-33 RTS/8 SYSTEM TASKS ECT /ENABLE CONTACT 1001 /FROM BIT 2 OF CHANNEL 1 4000 /ON 1ST OCCURRENCE OF EVENT, POST /EVENT FLAG ZBLOCK 3 ECTE2R, 0 /ERROR INDICATOR Twelve messages are required to enable the entire channel. 4.9.10 CS Change of State Format: CS channel result where channel is the contact channel whose current change of state value is to be placed in result. For example: COSEX, ZBLOCK 3 CS /READ COS 1 /CHANNEL 1 COSANS, 0 /RESULT HERE ZBLOCK 3 COSER, 0 /ERROR INDICATOR 4.9.11 DCT Disable Contacts Format: DCT bit & channel where bit & channel is specified as in enable contact. That is, bits 0-3 specify the bit (0 - 13 octal) and bits 4-11 specify the channel to be disabled. For example: DCTEX, ZBLOCK 3 DCT /DISABLE CONTACTS 5401 /FROM CHANNEL 1, BIT /13(OCTAL) ZBLOCK 4 DCTANS, 0 /ERROR INDICATOR 4.9.12 UDC/ICS Assembly Parameters The UDC/ICS handler has several assembly parameters that the user must specify to indicate the UDC/ICS configuration. The number and address is required only for those modules that perform interrupts. They are as follows: RINGBF Number of interrupts that can be stored in the ring buffer. NCNTR Number of counter modules. 4-34 RTS/8 SYSTEM TASKS NCNTC Number of contact modules. NAD Number of analog input converter modules. FCTR