1985_Intel_Software_Handbook 1985 Intel Software Handbook

User Manual: 1985_Intel_Software_Handbook

Open the PDF directly: View PDF .
Page Count: 571

 Download Open PDF In Browser View PDF
LITERATURE
In addition to the product line handbooks listed below, the INTEL PRODUCT GUIDE (no charge,
Order No. 210846-(03) provides an overview of Intel's complete product lines and customer services.
Consult the INTEL LITERATURE GUIDE (Order No. 210620) for a listing of Intel literature. TO
ORDER literature in the U.S., write oreal! the INTEL LITERATURE DEPARTMENT, 3065 Bowers
Avenue, Santa Clara, CA 95051, (800) 538-1876, or (800) 672-1833 (California only). TO ORDER
literature from international locations, contact the nearest Intel sales office or distributor (see listings in
the back of most any Intel literature).
Use the order blank on the facing page or cal! our TOLL FREE number listed above to order literature.
Remember to add your local sales tax.

1985 HANDBOOKS
Product line handbooks contain data sheets, application notes, article reprints and other design
information.

*U.S. PRICE
QUALITY/RELIABILITY HANDBOOK (Order No. 210997-001)
Contains technical details of both quality and reliability programs and principles.

$15.00 CHMOS HANDBOOK (Order No. 290005-001) Contains data sheets only on all microprocessor, peripheral, microcontroller and memory CHMOS components.$12.00

MEMORY COMPONENTS HANDBOOK (Order No. 210830-004)

$18.00 TELECOMMUNICATION PRODUCTS HANDBOOK (Order No. 230730-003)$12.00

MICRO CONTROLLER HANDBOOK (Order No. 210918-003)

$18.00 MICROSYSTEM COMPONENTS HANDBOOK (Order No. 230843-002) Microprocessors and peripherals-2 Volume Set$25.00

DEVELOPMENT SYSTEMS HANDBOOK (Order No. 210940-003)

$15.00 OEM SYSTEMS HANDBOOK (Order No. 210941-003)$18.00

SOFTWARE HANDBOOK (Order No. 230786-002)

$12.00 MILITARY HANDBOOK (Order No. 210461-003) Not available until June.$15.00

COMPLETE SET OF HANDBOOKS (Order No. 231003-002)
Get a 25% discount off the retail price of $160. *u.s. Price Only$120.00

u.s. LITERATURE ORDER FORM
NAME: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ TITLE: _ _ _ _ _ __
COMPANY:
ADDRESS: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ___
CITY: _ _ _ _ _ _ _ _ _ _ _ _ __

STATE: _ _ _ _ ZIP: _ _ __

COUNTRY: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
PHONE NO.: (_ _.!....-..._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

ORDER NO.

=
=
=

TITLE

~::!=:*~~I-;:::::I
~~~~I-;:::::I
~::::::!:~~I-~I~
~::!=:*~~I-~I
~~~~I-~I~

TOTAL

x
x
x
x
x

'----J.--'--'--,J.......,L--JI-.I. . .

x

..&........&.--J

Subtotal _ _ _ __

POSTAGE AND HANDLING:
and handling to subtotal

PRICE

QTY.

Your Local Sales Tax _ _ _ __

10% U.S.
Total _ _ _ __

Allow 4-6 weeks for delivery

Pay by Visa, MasterCard, Check or Money Order, payable to I ntel Literature. Purchase Orders
have a $50.00 minimum. o o Visa Account No. _ _ _ _ _ _ _ _ _ _ _ __ MasterCard Expiration _ _ __ Date Signature: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ Mail To: Intel Literature Distribution Mail Stop SC6-714 3065 Bowers Avenue Santa Clara, CA 95051. Customers outside the U.S. and Canada should contact the local I ntel Sales Office or Distributor listed in the back of this book. For information on quantity discounts, call the 800 number below: TOLL-FREE NUMBER: (800) 548-4725 Prices good until 12/31/85. Source HB Mail To: Intel Literature Distribution Mail Stop SC6-714 3065 Bowers Avenue Santa Clara, CA 95051. SOFTWARE HANDBOOK 1985 About Our Cover: The design on our front cover is an abstract portrayal of the role Intel software plays in systems development. The heart of systems development is surrounded by a sphere of peripheral development through which Intel software can guide the designer to reaching development goals. Intel Corporation makes no warranty for the use of its products and assumes no responsibility for any errors which may appear in this document nor does it make a commitment to update the information contained herein. Intel software products are copyrighted by and shall remain the property of Intel Corporation. Use, duplication or disclosure is subject to restrictions stated in Intel's software license, or as defined in ASPR 7-104.9(a) (9). Intel Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in an Intel product. No other circuit patent.licenses are implied. No part of this document may be copied or reproduced in any form or by any means without the prior written consent of Intel Corporation. The following are trademarks of Intel Corporation and may only be used to identify' Intel products: BITBUS, COMMputer, CREDIT, Data Pipeline, GENIUS, i, i, ICE, iCS, iDBp, iDIS, 121CE, iLBX, i m, iMDDX, iMMX, In site, Intel, intel, inte'BOS, Intelevision, inteligent Identifier, inteligent Programming, Intellec, Intellink, iOSP, iPDS, iSBC, iSBX, iSDM, iSXM, KEPROM, Library Manager, MCS, Megachassis, MICRO-MAINFRAME, MULTI BUS, MULTICHANNEL, MULTI MODULE, OpeNet, Plug-A-Bubble, PROMPT, Promware, QUEST, QueX, Ripplemode, RMXl80, RUPI, Seamless, SLD, SYSTEM 2000, and UPI, and the combination of ICE, iCS, iRMX, iSBC, iSBX, MCS, or UPI and a numerical suffix. The following are trademarks of the companies indicated and may only be used to identify products of the owners. CP/M is a trademark of Digital Research, Inc. DEC, DEC-10, DEC-20, PDP-11, DECnet, DECwriter, RSTS, and VAX are trademarks of Digital Equipment Corporation. MDS is an ordering code only and is not used as a product name or trademark. MDS@ is a registered trademark of Mohawk Data Sciences Corporation. Microsoft is a trademark of Microsoft, Inc. @Intel Corporation, 1984 inter Table of Contents CHAPTER 1 OVERVIEW Introduction ....... , .................... '" ................. '" ........... " . .. . . . . . . 1-1 CHAPTER 2 OPERATING SYSTEMS Introduction ......•............................... , ............ , .. ,. . .. .. . . . . . . .. . . . . 8080/8085 Microprocessor Family DATA SHEET Digital Research Inc. CP/M 2.2 Operating System ................................ . . 8086/8088/80286 Microprocessor Family DATA SHEETS iRMX 86 Operating System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iOSP 86, iAPX 86/30, iAPX 88/30, iAPX 186/30 and iAPX 188/30 Support Package. . . .. iRMX 86 MULTIBUS II Support Package........................................... FACT SHEET iRMX Operating Systems ........................................................ XENIX 3.0 Operating Systems.................................................... APPLICATION NOTES AP-130 Using Operating Systems Processor's to Simplify Microcomputer Designs. . .. AP-174 Optimizing the iRMX 86 Operating System Performance on System 86/310 and System 86-330 ...................................... AP-184 Writing Device Drivers for XENIX 86 and 286 - Task or Trivia? ................ AP-221 An Introduction to Task Management in the iRMX 86 Operating System ....... ARTICLE REPRINTS AR-286 Software That Reside~ in Silicon .......................................... AR-287 Putting Real-Time Operating Systems to Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. AR-288 Intel's Matchmaking Strategy: Marry iRMX Operating System with Hardware ........................................... . . . . . . .. AR-337 Industrial PC Systems Demand Real Time Operating Systems ..........' ..... 2-1 2-2 2-5 2-24 2-28 2-31 2-37 2-44 2-95 2-123 2-193 2-234 2-240 2-252 2-255 CHAPTER 3 TRANSLATORS AND UTILITIES FOR PROGRAM DEVELOPMENT Introduction. • . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MCS-80/85 Mircroprocessor Family DATA SHEETS PL/M 80 High Level Programming Language ...................................... FORTRAN 80 8080/8085 ANS FORTRAN 77 Intellec Resident Compiler.. . . .. ... .. . .. Microsoft, Inc. BASIC-80 Interpreter Software Package.. . . ... .. . .. ... .. . . . . .. . . . . .. Microsoft, Inc. BASIC-80 Compiler Software Package ...................... " . . .. .. Microsoft Multiplan Spreadsheet ................................................. PASCAL-80 Software Package ................................................... WORDSTAR Word Processing Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IAPX 86/88/186/188/286 Microprocessor Family DATA SHEETS iAPX 86, 88 Software Development Packages for Series II/PDS . . . . . . . . . . . . . . . . . . . . .. 86/88/186/188 Software Packages ................................................. ' FORTRAN 86/88 Software Package. • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pascal 86/88 Software Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. PLIM 86/88/186/188 Software Package. . .. . . . . .. .. ... . .. ... ... . . .. . .... .. . .. .. . ... iC-86 C Compiler for the 8086 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8087 Support Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8087 Software Support Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8089 iOP Software Support Package #407200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. iAPX 286 Software Development Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PL/M 286 Software Package ..................................................... iSDM 286 iAPX 286 System Debug Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80287 Support Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pascal-286 Software Package ................................ . . . . . . . . . . . . . . . . . . . . VAXNMS Resident Software Development Packages for iAPX 286 . . . . . . . . . . . . . . . . . .. iii 3-1 3-3 3-6 3-10 3-13 3-15 3-23 3-28 3-35 3-45 3-46 3-50 3-53 3-57 3-61 3-65 3-68 3-71 3-76 3-80 3-84 3-87 3-90 VAXNMS Resident iAPX 86/88/186 Software Development Packages ..••............ iSDM 86 System Debug Monifor ................•.............•.......•...•...•... iVDI 720 Graphics Virtual Device Interpreter ......... " ...•........................ iPLP 720 NAPLPS Interpreter. .. . ... . . .. .. ..•. . . .. . . ... .. .. .. .... ....•... .. .. . ... FACT SHEETS iRMX Languages .....................•................................. ~.. .. .... XENIX Languages. . ... . . ....•. . .. . .. .. ..•• . ... . .. .. .. ... ... . .. . .. . .. ...•. .•.. ... Single Chip Microcontrolier Software DATA SHEETS 2920 Software Support Package .......................•.......................... MCS-48 Diskette-Based Software Support Package ................................ 8051 Software Package ........................•.................................. iRMX 51 Real-Time Multitasking Executive ....................................... MCS-96 Software Development Packages ........•............................... 3-96 3-103 3-108 3-112 3-116 3-121 3-125 3-136 3-138 3-147 3-153 CHAPTER 4 DEVELOPMENT PRODUCTIVITY TOOLS Introduction. ..•. .... .. . . . . .. . .•. .. . . . .. . .. . . .. ... . .. .. .. . .. .. .. .. . .. . . . ... .... .. . . .. Program Development and Management Tools DATA SHEETS PSCOPE High-Level Program Debugger. . . . . . . . . . . . . . . . . . . . . .. .................. Program Management Tools .........................•........................... ISIS-II Software Toolbox. . . .. .. . . . .. ... .•.. ... . .. .. .. ... . .. . . .. ... .. .. . .. . . .. . ... 8086 Software Toolbox .......................................................... AEDIT Text Editor ..................... ; .. .. . .. . . . . . . . . . . .. . . .. . ... ... ... . . . . . .. . 4-1 4-2 4-7 4-10 4-12 4-14 CHAPTER 5 COMMUNICATION SOFTWARE Introduction. .. .. .. .. .. . . .. ... . . . .. . . .. . .. .. .. .. ... . . . . . . .. .. .. . . ... ... ..•.. . . . . . . .. . DATA SHEETS . Mainframe Link for Distributed Development ........................... ;.......... Intel Asynchronous Communications Link ....................•................... iNA 960 Network Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NOS II Electronic Mail. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . iNA 955 iRMX NOS-II Link.. .. .. .. .............................................. iRMX 510 iDCM Support Package ..............•....................... , ........ , . 5-1 5-2 5-5 5-8 5-20 5-22 5-26 CHAPTER 6 SYSTEM AND APPLICATIONS SOFTWARE Introduction ...•............................................................ ;, .. . . .. . FACT SHEETS XENIX Productivity Software Tools............................................... Third Party Software for Intel Products. . . .. . ... . . . .. .. . . . . .. . .. ... . .. ... . . . . . . .. . Database Information System iDIS 715........................................... 6-1 6-2 6-10 6-13 CHAPTER 7 COMPONENT SOFTWARE DATA SHEETS 80130/80130-2 iAPX 86/30, 88/30, 186/30, 188/30 iRMX 86 Operating System Processors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . • 80150/80150-2 iAPX 86/50, iAPX 881"1), 186/50, 188/50 CP/M 86 Operating System Processors. . . . .. .. .. .. .. . . .. ... .. .. .. . ... .... ... ... . .. . ... iv 7-1 7-23 CHAPTER 8 USER LIBRARY Introduction ............................................................. , .. ... .. . . . . User Library Insite User's Program Library .................................................... Insite Submittal Requirements.. .. . . .. . . . . . . . . . .. . . . . . . . .. . .. .. . . . . . . .. . .... .. . . . . Insite Index of Program. .. .. . .. .. . . .. . . . . . . . . . .. . . . . . . . .. . .. .. . . . . . . . . . . ... . . . . . . 8-1 8-2 8-3 8-5 APPENDIX A Software Standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Support Services ....................... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iRUG................................................................................... v A-1 A-3 A-5 Overview 1 SOFTWARE HANDBOOK OVERVIEW Welcome to the Intel Software Handbook. This handbook is a complete guide to the software products and services offered by Intel. Intel's software products follow the open systems strategy that allows Intel products to be purchased at the customers' desired level of integration. Hence these products are available for component, board, or systems applications. This open systems philosophy is backed by software standards that insure that the software can operate at numerous levels of integration. These software standards are described in the appendix. Software for Intel's products is available both from Intel and from Independent Software Vendors (ISVs). For a complete listing of software available from ISVs, see the Int,,'i Yellow Pages which is published annually by Intel. This handbook describes software products that are avail.?,. J3through Intel, consisting of Intel-developed and ISV-developed products. Products that are offered by Intt::! f)ave all been evaluated and tested to meet Intel's quality standard. They are backed by an extensive support organization described in the appendix. Operating Systems 2 inter OPERATING SYSTEMS INTRODUCTION The ability to convert advanced microprocessor technology into solutions for modern day problems begins with effective and efficient designs for new hardware products and architecture. However, a most critical element In the success of any microcomputer solution is the availability of a high quality, reliable operating system. Without this software counterpart, the technological advances cannot be fully implemented, nor their benefits fully realized. The classic role of the microcomputer operating system can be outlined by viewing its major functions and purposes. The functions of the microcomputer operating system are threefold: 1) to manage system resources and the allocation of these resources to users; 2) to provide automatic functions such as initialization and start-up procedures; and 3) to provide an efficient, straightforward and consistent method for user programs to interface with the hardware subsystems, including a simple and friendly human interface. Typically, the operating systems have one of two main purposes. First, they can be used to develop a new software system that runs on another machine. These systems are usually large and fairly sophisticated. ISIS and 'XENIX are examples of such developmental operating systems. The second purpose for microcomputer operating systems is directed toward the execution of software programs fortargeted application. The largest number of operating systems are of this type, including the RMX systems. The most critical requirement is for these systems to be effective and efficient since they are usually small, fast systems dedicated to a specific real-time application. This rather neat and simple categorization of microcomputer operating systems, which has been useful in the past, is quickly becoming blurred. The rapid developments in microcomputer technology have increased the power and decreased the cost of microcomputers, allowing them to become applicable to the solution of a broader variety and more sophisticated set of problems. Microcomputer systems must increasingly provide such capabilities as multiprogramming, multitasking, multiprocessing, networking, as well as scheduling and priority determination. As systems become more complex, they must still remain responsive to real-time applications. Operating systems must be able to capitalize on the trends toward placing more and more software into silicon. This trend is blurring the distinction between the hardware and software subsystems. Microcomputer systems are also evolving to encompass both the developmental and target application purposes into one system. These dramatic changes in technology place additional demands on operating systems. We see operating systems undergoing changes to consider the need for: 1) modularity and ease of configurability; 2) evolutionary, not revolutionary, path of growth; and 3) standardization in languages, networks and the operating system itself. The first need is required to allow the system to be a powerful development tool yet configurable to more specialized applications. The last two items are needed to provide protection of a firm's software investment, including the option to move toward silicon software. The operating systems and executives in this section are state-of-the-art microcomputer systems that have taken to taslt the challenges posed by advanCing microprocessor technology. These operating systems offer the widest range of solutions with the highest quality and most future-oriented software available today. Consequently, our customers can select the appropriately optimized option to achieve their price/performance goals and give them time-to-market advantage over their competitors. 'XENIX is a trademark of Microsoft Corp. 2-1 DIGITAL RESEARCH INC. CP/M* 2.2 OPERATI'NG SYSTEM • High-performance, single-console operating system • More than 1,000 c;ommercially available compatible software products • Simple, reliable file system matched to microcomputer resources • General-purpose subroutines and table-driven data-access algorithms provide a truly universal data management system • Table-driven arc;hitecture allows field reconfiguration to match·a wide variety of disk capacities and needs • Upward compatibility from all previous versions • Extensive documentation covers all facts of CP/M applications CP/M 2,2 is a monitor control program for microcomputer system and application uses on Intel 8080/8085based microcomputer. CP/M provides a general environment for program execution, construction, storage, and editing, along with the program assembly and check-out facilities, The CP/M monitor provides rapid access to programs through a comprehensive me management package, The file subsystem supports a named file structure, allowing dynamic allocation of file space as well as sequential and rand'om file access, Using this system, a large number of distinct programs can be stored,in both sourceand machine-executable form. CP/M also supports a powerful context editor, Intel-compatible assembler, and debugger subsystems. Nearly all personal software programs can be bought configured to run under CP/M, several of which are available from Intel. ' FEATURES CP/M is logically divided into four distinct modules: -Uses less than 4K of. memory allOWing plenty of memory space for applications programs BIOS-Basic I/O System -Uses less than 4K of memory -Makes programs transportable from system to system -Provides primitive operations for access to disk drives and interface to standard peripherals (teletype, CRT, paper tape reader/punch, bubble memory, and user-defined peripherals) -Entry points include the following primitive operations which can be programmatically accessed: -Allows user modification for tailoring to a particular hardware environment SEARCH Look for a particular disk file by name OPEN Open a file for further operations CLOSE Close a file after processing -Provides disk management for one to sixteen disk drives containing independent file directones RENAME Change the name of a particular file READ Read a record from a particular file -Implements disk allocation strategies for fully dynamic file construction and minimization of head movement across the disk WRITE Write a record to a particular file SELECT Select a particular disk drive for further operations BOOS-Basic Disk Operating System f INTEL CORPORATION 1983 2-2 SEPTEMBER 1984 ORDER NUMBER:210268·004 DIGITAL RESEARCH, INC. CP/M 2.2 CCP-Console Command Processor ASM -Provides primary user interface by reading and interpreting commands entered through the console Fast 8080 Assembler-uses standard Intel mnemonics and pseudo operations with free-format input, and conditional assembly features DDT Dynamic Debugging Tool-contains an integral assembler/disassembler module that lets the user patch and display memory in either assembler mnemonic or hexadecimal form and trace program execution with full register and status display; instructions can be executed between breakpoints in real-time, or run fully monitored, one instruction at a time SUBMIT Allows a group of CP/M commands to be batched together and submitted to the operating system by a single command STAT -Programs created under CP/M can be checked out by loading and executing these programs in the TPA Lists the number of bytes of storage remaining on the currently logged disks, provides statistical information about particular files, and displays or alters device assignments LOAD -User programs, loaded into the TPA, may use the CCP area for the program's data area Converts Intel hex format to absolute binary, ready for direct load and execution in the CP/M environment SYSGEN Creates new CP/M system disks for back-up purposes -Loads and transfers control to transient programs, such as assemblers, editors, and debuggers -Processes built-in standard commands including: ERA Erase specified files DIR List file names in the directory REN Rename the specified file SAVE Save memory contents in a file TYPE Display the contents of a file on the console TPA-Transient Program Area -Holds programs which are loaded from the disk under command of the CCP -Transient commands are specified in the same manner as built-in commands MOVCPM Provides regeneratibn of CP/M systems for various memory configurations and works in conjunction with SYSGEN to provide additional copies of CP/M -Additional commands can be easily defined by the user -Defined transient commands include: PIP ED Peripheral Interchange Program -implements the basic media transfer operations necessary to load, print, punch, copy, and combine disk files, PIP also performs various reformatting and concatenation functions. Formatting options include parity-bit removal, case conversion, Intel hex file validation, subfile extraction, tab expansion, line number generation, and pagination BENEFITS -Easy implementation on any computer configuration which uses an Intel 8080/8085 Central Processing Unit (see the CP/M-86 data sheet for CP/M applications on the iAPX86 CPU) -iPDS version supports bubble memory option as an additional diskette drive. Also allows diskette duplication with a single drive Text Editor-allows creation and modification of ASCII files using extensive context editing commands: string substitution, string search, insert, delete and block move; ED allows text to be located by context, line number, or relative position with a macro command for making extensive text changes with a single command line -Extensive selection of CP/M-compatible programs allows production and support of a comprehensive software package at low cost -Field programmability for special-purpose operating system requirements -Upward compatibility from previous versions of CP/M release 1 2-3 AFN-02111C intel' DIGITAL RESEARCH, INC. CP/M 2.2 -Provides field specification of one to sixteen logical drives, each containing up to eight megabytes -Files may contain up to 65,536 records of 128 bytes each but may not exceed the size of any single disk -Each disk is designed for 64 distinct files-more directory entries may be allocated if necessary -Individual users are physically separated by user numbers, with facilities for file copy operations from one user area to another -Relative-record random-access functions provide direct access to any of the 65,536 records of an eight-megabyte file SPECIFICATIONS Hardware Required Shipping Media -Model 800 with 720 kit (Specify by Alpha Character when ordering.) -OS 235 kit or MDS 225 with 720 kit (integral drive supported except as system boot device) B-double density -iPDS Personal Development System Optional: RAM up to64K -Additional floppy disk drives A-single density (IBM 3740/1 compatible) F-double-sided, double density 5%" floppy (iPDS format) Order Code -Single density via 201 controller -Bubble memory and optional Shugart 460 5%" disk drive for iPDS Documentatiol'l Package Title CP/M 2.2 documentation consisting of 7 manuals: An Introduction to CP/M Features and Facilities CP/M 2.2 User's Guide CP/M Assembler (ASM) User's Guide CP/M Dynamic Debugging Tool (DDT) User's Guide ED: A Context Editor for the CP/M Disk System User's Manual CP/M 2 Interface Guide CP/M 2 Alteration Guide Product Description See Price List CP/M (Control Program for Microcomputers) is a disk-based operating system for the Intel 8080/80SS-based systems. CP/M provides a general environment for program development, test, execution and storage. CP/M storage is available via a comprehensive, named-file structure supporting both sequential and random access CP/M support tools include a Text Editor, a debugger, and an 8080/8085 assembler. SUPPORT: Intel offers several levels of support for this product, depending on the system configuration in which it is used. Please consult the price list for a detailed description of the support options available. An Intel Software License required. 'CP/M is a registered trademark of Digital Research, Inc: 'CP/M-86, MP/M, CP/NET and MP/NET are trademarks of Digital Research, Inc 2-4 AFN·02111C iRMXTM 86 OPERATING SYSTEM • Real-time processor management for time-critical iAPX 86, iAPX 88, iAPX 186, IAPX 188, and IAPX 286 (Real Address Mode) applications • Configured systems for the IAPX 86 and iAPX 286 processors in Intel integrated system products (ISYS 86/300 and ISYS 286/300) • On-target system development with Universal Development Interface (UDI) • Multi-terminal support with mUlti-user human interface • Configurable system size and function for diverse application requirements • Broad range of device drivers included for Industry standard MULTIBUS@ peripheral controllers • All iRMXTM 86 code can be (P)ROM'ed to support tC?tally solid state designs • Complete support of 8087 and 80287 processor extension • Compatible operating system services for IAPX 86/30, 88/30, 186/30 and 188/30 Operating System Processors (iOSPTM 86) • Powerful utilities for interactive configuration and real-time debugging The iRM)(TM 86 Operating System is an easy-to-use, real-time, multi-tasking and multi-programming software system designed to manage and extend the resources of iSB(;@ 86, iSBC 88, iSBC 186, iSBC 188, and iSBC 286 Single Board Computers, as well as other iAPX 86, iAPX 88, iAPX 186, iAPX 188, and iAPX 286 (Real Address Mode) based microcomputers. iRMX 86 functions are available in silicon with the iAPX 86/30, 88/30,186/30 and 188/30 Operating System Processors, in a user configurable software package. iRMX 86 functions are also fully integrated into the SYSTEM 86/300 and SYSTEM 286/300 Family of Microcomputer Systems. The Operating System provides a number of standard interfaces that allow iRMX 86 applications to take advantage of industry standard device controllers, hardware components, and a number of software packages developed by Independent Software Vendors (ISVs). Many high-performance features extend the utility of iRMX 86 Systems into applications such as data collection, transaction processing, and process control where immediate access to advances in VLSI technology is paramount. These systems may deliver real-time performance and explicit control over resources; yet also support applications with multiple users needing to simultaneously access terminals. The configurable layers of the System provide services ranging from interrupt management and standard device drivers for many sophisticated controllers, to data file maintenance commands provided by a comprehensive multi-user human interface. By providing access to the standard Universal Development Interface (UDI) for each user terminal, Original Equipment Manufacturers (OEMs) can pass program development and target application customization capabilities to their users. HUMAN INTERFACE USER APPLICATIONS iRMXTM VLSI Operating System The follow,ng are trademarks Intel Corporat,on and may be used only to deSCribe Intel products Intel. ICE, ,MMX, ,RMX, ,SBC, ,SBX, ,SXM, MULTIBUS, MULTICHANNEL of and MULTIMOOULE Intet Corporation assumes no responSIbility for the use of any CircUitry other than CirCUitry embodied In an Intel product No other CircUit patent licenses are Implied Information contained herein supercedes preVIOUsly published speCifications on these deVices from Intel © INTEL CORPORATION, 1984 2-5 Order Apnl,1984 Number: 210885.002 inter IRMXTM 86 OPERATING SYSTEM Process Management The iRMX 86 Operating System is a complete set of system software modules that provide the resource management func.tions n~ecj by computer ,systems. ThE!,se management functions allow Original Equipme!1t'Manufactur~rs (OEMs) to best use resOurces available in microcomputer systems while getting their products to market quickly, saving time and money. Engineers are relieved of writing complex system software and can concentrate instead On their application software. To implement multi-tasking application systems, programmer~ require Ii methoa of managing the differentprocesses of their application; and for allowing the processes to communicate with each other. The Nucleus layer of the iRMX 86 System provides a number of facilities to efficiently manage these processes, and to effectively communicate between them. These facilities are' provided by system calls that manipulate data structures called task~,,jobs, regions, semaphores and mailboxes. The iRMX 86 System refers to these structures "objects". This data st!e8t describes the major features of the iRMX 86 Operating System. The benefits provided to engineers who write application software and to users who want to take advantage of improving microcomputer price and performance are expl~ned. The first section ouUines the system resource management functions of the Operating System and describes several system calls. The second section gives a detailed overview of iRMX 86 features aimed at sen/lng both the iRMX 86 system designer and programmer, as well as the end users of the product into which the Operat, ing System is incorporated. as Tasks are the basic element of all applications built on the iRMX 86 Operating System. Each task is an entity capable of executing C,PU instructions and issuing system calls in order to Perform a function. Tasks are characterized by their register values (including those of an optional 8087 or 80287 Numeric Processor Extension), a priority between 0 and 255, and the resources associated with them. FUNCTIONAL DESCRIPTION To, take best ~dvantage of iAPX 86, 88, 186, 188, and 286 (Real Address Mode) microprocessors in applications where the computer is required to perform many functions simultaneously, the iRMX 86,Operating System provides a multiprogramming environment in which many independent, multi-tasking application programs may run. The flexibility of independent environments allows application programmers to separately manage ' each application's resources during both the development and test phases. The resource management functions of the iRMX 86 System are supported by a nUl)'lber of configurable software layers. While r:nanyof the functions supplied by the innermost layer, the Nucleus, are required by all systems, all other functions are optional. The I/O systems, for eXample, may be omitted in systems haVing no secondary storage requirement. Each layer provides functions that encourage application programmers to use modular design techniques for quick development of easily maintainable programs. Each iRMX 86 task in the system is scheduled for operation by the iRMX 86 Nucleus. Figure 1 shows the fIVe States in which each task may be placed, and some examples of how a task may move from one state to another. The iRMX 86 Nucleus ensures that each task is placed in the correct state, defined'by the events in its external environment and by'the task issuing system calls. Each'task has a priority to indicate its relative importance and 'need to respond to its environment. The Nucleus guarantees that the highest priority ready-to-run task is the task that runs. Jobs are used to define the operating environment of a group of tasks. Jobs effectively limit the sCQPe of an application by collecting all of its tasks and other objects into one group. Because the environment for execution of an application is defined by an iRMX 86 job, separate applications can be efficiently developed by separate development teams. The iRMX 86 Operating System provides two primary techniques for real-time event synchronization in multitask applications: regions and semaphores. Regions are used to restrict access to critical sections of code and data. Once the iRMX 86 Operating System gives a task access to resources guarded by a region, no other tasks may make use of the resources, and the task is given protection against deletion and suspension. Regions are typically used to protect data structures from being simultaneously updated by multiple tasks. The components of the iRMX 86 Operating System provide both implicit and explicit management of system resources. These resources include proc,essOr scheduling, up to one megabyte of system memory, up to, 57 independent interrupt sources, 'all input and output devices, as well as directory and data,files contained on mass storage devices and accessed by a number of independent users. Management of these system resources and methods for sharing resources between multiple processors and users is discussed in the following sections. ' Semaphores are used to provide mutual exclusion between tasks. Th~y contain abstract "units" that are serit between the tasks, and can be used to implement the cooperative sharing of resources. 2-6 Order Number: 210885-002 iRMXTM 86 OPERATING SYSTEM SYSTEM ROOT JOB JOB B e JOB A TASK 81 MAILBOX & TASK 82 SEMAPHORE 171 OBJECT DIRECTORY MAILBOX AM lSi 191 OBJECT DIRECTORY TASK 82 MAILBOX AN TASK A3 1 OBJECT DIRECTORY MAILBOX RM!Q!LA SEMAPHORE RS.LQ.Ll! TASK 82 (10) INON EXISTENTI NOTES: (1) Task . Figure 2. Multiple Jobs Example IS created known to the programmer at the time the tasks were developed. Both Job 'A' and Job 'B' exist within the environment of the 'Root Job' that forms the foundation of all iRMX 86 systems. Each job possesses a directory'in which tasks may catalog the name of an object. Semaphore 'RS', for example, is accessable by all tasks in the system, because its name is cataloged in the directory of the Root Job. Mailbox 'AN' can be used to transfer objects between Tasks 'A2' and 'A3' because its token is accessable in the object directory for Job 'A'. (2) Task becomes highest Priority ready task (3) Task gets pre-empted by one with higher Priority (4) Task calls SLEEP or task walts at an exchange (5) Task sleep period has ended. message was sent to walt Ing task or walt has ended (6) Task calls SUSPEND on self (7) Task suspended by other than self (8) Task suspended by other than self or a resume that did not bring suspension depth to zero (9) Task was resumed by other task (10) Task IS deleted Table 1 lists the major functions of the iRMX 86 Nucleus that manage system processes. Figure 1. Task State Diagram Memory Management Multi-tasking applications must communicate information and share system resources among cooperating tasks. The iRMX 86 Operating System assigns a unique 16-bit number, called a token, to each object created in the System. Any task in possession of this token is able to access the object. The iRMX 86 Nucleus allows tasks to gain access to objects, and hence system resources, at run-time with two additional mechanisms: mailboxes and object directories. Each job in an iRMX 86 System defines the amount of the one megabyte of addressable memory to be used by its tasks. The iRMX 86 Operating System manages system memory and allows jobs to share this critical resource by providing another object type: segments. Segments are contiguous pieces of memory between 16 Bytes and 64K Bytes in length, that exist within the environment of the job in which they were created. Segments form the fundamental piece of system memory used for task stacks, data storage, system buffers loading programs from secondary storage, passing in: formation between tasks, etc. Mailboxes are used by tasks wishing to share objects with other tasks. A task may share an object by sending the object token via a mailbox. The receiving task can check to see if a token is there, or can wait at the mailbox until a token is present. The example in Figure 2 also demonstrates when information is shared between Tasks 'A2' and 'A3'; 'A2' only needs to create a segment, put the information in the memory allocated, and send it via the Mailbox 'AM' using the RQ$SEND$MESSAGE system call (see Table 1). Task 'A3' would get the message by using the RQ$RECEIVE$MESSAGE system call. The Figure also shows how the receiving task could signal the sending task by sending an acknowledgement via the second Mailbox 'AN'. Object Directories are also used to make an object available to other tasks. An object is made public by cataloging its token and name in a directory. In this manner, any task can gain access to the object by knowing its name, and job environment that contains the directory. Two example jobs are shown in Figure 2 to demonstrate how two tasks can share an object that was not 2-7 Order Number: 210885·002 iRMXTM 86 OPERATING SYSTEM Table 1. Process Management System Calls System Call RQ$CREATE$JOB . RQ$DELETE$JOB Function Performed Creates an environment for a number of tasks and other objects, as well as creating an initial task and its stack . Deletes a job and all the objects currently defined within its bounds. All memer! used is returned to the job from which the deleted job was created. RQ$OFFSPRING

Provides a list of all the current jobs created by the specified job.

RQ$CATALOG$OBJECT

Enters a name and token for an object into the object directory of a job.

RQ$UNCATALOG$OBJECT

Removes an object's token and its name from a job's object directory

RQ$LOOKUP$OBJECT

Returns a token for the object with the specified name found in the object directory of
the specified job.

RO$GET$TYPE

Returns a code for the type of object referred to by the specified token.

RQ$CREATE$MAILBOX

Creates a mailbox with queues for waiting tasks and objects with FIFO or PRIORITY
discipline.

RQ$DELETE$MAILBOX

Deletes a mailbox.

RQ$SEND$MESSAGE

Sends an object to a specified mailbox. If a task is waiting, the object is passed to the
appropriate task according to the queuing disCipline. If no task is waiting, the object is
queued at the mailbox.

RQ$RECEIVE$MESSAGE

Attempts to receive an object token from a specified mailbox. The calling task may
choose to wait for a specified number of system time units if no token is available.

RO$DISABLE$DELETION

Prevents the deletion of a specified object by increasing its disable count by one.

RQ$ENABLE$DELETION

Reduces the disable count of an object by one, and if zero, enables deletion of that
object.

RO$FORCE$DELETE

Forces the deletion of a specified object if the disable count is either 0 or 1.

RQ$CREATE$TASK

Creates a task with the specified priority and stack area.

RQ$DELETE$TASK

Deletes a task fro.m the system, and removes it from any queues in which it may be
waiting.

RQ$SUSPEND$TASK

Suspends t~e operation of a task. If the task
depth is increased by one.

RO$RESUME$TASK

Resumes a task. If the task had been suspended multiple times, the suspension depth
is reduced by one, and it remains suspended.

IS

already suspended, its suspension

RQ$SLEEP Causes a task to enter the ASLEEP state for a specified number of system time Units. RQ$GET$TASK$TOKENS

Gets the token for the calling iask or associated objects within its environment.

RQ$SET$PRIORITY

Dynamically alters the priority of the specified task.

RQ$GET$PRIORITY

Obtains the current priority of a specified task.

RQ$CREATE$REGION

Creates a region, with an associated queue of FIFO or PRIORITY ordering discipline.

RQ$DELETE$REGION

Deletes the specified' region if it is not currently in use.

RQ$ACCEPT$CONTROL

Gains control of a region only if the region is immediately available.

RQ$RECEIVE$CONTROL

Gains control of a region. The calling task may specify the number of system time
units it wishes to wall if the region is not immediately available.

RQ$SEND$CONTROL
RQ$CREATE$SEMAPHORE

Relinquishes control of a region.
. Creates a semaphore.

RQ$DELETE$SEMAPHORE

Deletes a semaphore.

RQ$SEND$UNITS

Increases a semaphore counter by the specified number of units.

RQ$RECEIVE$UNITS

Attempts to gain a specified number of units from a semaphore If the units are not
immediately available, the calling task may choose to wait.

2-8

Order Number: 210885·002

iRMXTM 86 OPERATING SYSTEM

Each job is created with both maximum and minimum
limits set for its memory pool. Memory required by all
objects and resources created in the job is taken from
this pool. If more memory is required, a job may be allowed to borrow memory from the pool of its containing
job (the job from which it was created). In this manner,
initial jobs may efficiently allocate memory to jobs they
subsequently create, without knowing their exact requirements.

events always takes precedence over other system
activities.
The iRMX 86 Operating System gives applications the
flexibility to optimize either interrupt response time or
interrupt response capability by providing two tiers of
Interrupt Management. These two distinct tiers are
managed by Interrupt Handlers and Interrupt Tasks.
Interrupt Handlers are the first tier of interrupt
service. For small simple functions, interrupt handlers
are often the most efficient means of responding to an
event. They provide faster response than interrupt
tasks, but must be kept simple since interrupts (except
the iAPX 86, 88, 186, 188, and 286 non-maskable interrupt) are masked during their execution. When extended service is required, interrupt handlers "Signal"
a waiting interrupt task that, in turn, performs more
complicated functions.

The iRMX 86 Operating System supplies other memory
managrnent functions to search specific address ranges
for available memory. The System performs this search
at system initialization, and can be configured to ignore non-existent memory and addresses reserved for
1/0 devices and other application requirements.
Table 2 lists the major system calls used to manage
the system memory.

Interrupt Management

Interrupt Tasks are distinct tasks whose priority is associated with a hardware interrupt level. They are permitted to make any iRMX 86 system call. While an
interrupt task is servicing an interrupt, interrupts of
lower priority are not allowed to pre-empt the system.

Real-time systems, by their nature, must respond to
asynchronous and unpredict~ble events quickly. The
iRMX 86 Operating System uses interrupts and the
event-

10

0

8

g
~.

- _.

""

:>

Il.
l:

CI

:>
0

,

i

i

i-'-n'
i

Il.

:, .!, ~

6

a:

. . .:.-

rr-

l:

""

r
r

ro

..

!.

..

I
I

t

i
-

:.y-/l/.:~ ~I

86R
286W-:- ~_
86W;"-

I· J1
256

I

...

I,

.

1-' .

.

~

,A
j

lR

A~

!

:

~
..J
I
I

r

1fI"

~ r-"~

V

--

~

,

-

._--

-

-L
--_

..

-- _.

---- t--

I
-..•....

1K

i

I
I

I

\ 286R

-.-----.

...

--

..

..

-

i

...~.
I

.... -

-

!

I

r

--

4K

2K

\~1J

I

I

.

rr
II

!

i

--- - ..

'\

:

,

.j-. . +

:

~ --:::.-!~~
:

I

:
I

.. 1... ...1. ---.

!

.-1--

~

:/

~ ~-::

_
0

~

--t-

,~~
~

w

0
I
I

_ .. J ..
i

..

j
512

. - - . -.
..

w

"

_- .. -

-

I I
: I

: -r:-::....-.. . f-

2~6R

,

-+-- -_..

it

._.!._+.
I

,

-

_

..

i

0

w

i

I

I/)

I/)

... . -

!

14
0

-.-

w

8K

16K

Ii
32K

64K

TRANSFER SIZE

Figure 4. iRMXTM 86 Disk I/O Performance·
2-11

Order Number: 210885-002

intJ

iRMXTM 86 OPERATING SYSTEM

APPLICATION SOFTWARE

PHYSICAL
FILE
DRIVER

.sac·
215
DEVICE
DRIVER

,II

STREAM
FILE
DRIVER

NAMED
FILE
DRIVER

,
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I

.ssc·
254

DEVICE
DRIVER

,

,SBX'·
218
DEVICE
CONT
ROLLER

,sac'
215
DEVICE
CONT·
ROLLER

UN
CONN
DeVICE
UNIT

,
,

,sac'
254

FILE

1/4

CONN DEVICE UNITS

BUBBLE
MEMORY

MBYlE BUBBLE

CONNECTED DEVICE UNIT

CONDUITS REPRESENT DEVICE CONNECTIONS
WIRES IN CONDUITS REPRESENT FILE CONNECTIONS

Figure 5. Device Driver and Controller Relationships
By performing device buffering automatically, the
iRMX 86 EIOS optimizes accesses to disks and other
devices. Often, when an application task asks the System to READ a portion of a file, the System is able to
respond immediately with the data it has read in advance of the request. Similarly, the EIOS will not delay a task for writing ctata to a device unless it is
specifically told to, or if its output buffers are filled.
Logical file and device names are provided by the
EIOS to give applications complete file and device independence. Applications may send data to the 'line
printer' (:LP:) without needing to know which specific
device will be used as the printer. This logicill name
may, in fact, not be a printer at all, but it could be a disk
file that is later scheduled for printing.
The EIOS uses the functions provided by the BIOS to
synchronize indMduaillO requests with results returned
by device drivers. Most EIOS system calls are similar
to the BIOS calls, except that they appear to suspend
the operation of the calling task until the I/O requests
are completed.
.
Two new primitives have been added to the EIOS.
These are: RQ$HYBRID$DETACH$DEVICE and RQ$GET$LOGICAL$D~VICE$STATUS. RQ$HYBRID$DETACH$DEVICE allows a programmer
to temporarily detach a device physically so it can be
temporarily attached another way.

RQ$GET$LOGICAL$DEVICE$STATUS provides information about a logical device: the physical device name,
file driver, number of connections to the device, and
the owner of the device.

File Management
The iRMX 86 Operating System provides three distinct
types files to ensure efficient management of both
program and data files: Named Files, Physical Files,
and Stream Files. Each file type provides access to
I/O devices through the standard device drivers mentioned earlier. The same device driver is used to access physical and named files for a given device.

0'

NAMED FILES
Named files allow users to access information on secondary storage by referring to a file with its ASCII
name. The names of files stored on a device are stored
in special files called directories. As directories are
themselves named files, the iRMX 86 File System allows
directories to contain the names of other directories.
Figure 6 illustrates the resulting hierarchical file structure. This structure is useful for isolating file names
to particular user applications, and for tailoring system
data to the requirements of users and applications
sharing storage devices. Using different branches on
the directory tree, different users do not have to coordinate in naming their files to ensure unique names.

2-12

Order Number: 210885-002

inter

iRMXTM 86 OPERATING SYSTEM

SIM
SOURCE

SIM·
OBJECT

TEST OBJECT

I

= DIRECTORY

'-----'

/\

~

= NAMED
DATA FilE

BATCH-1 BATCH·2

Figure 6. Hierarchical Named File Structure
Whenever a request is made involving a file name, the
System will search the appropriate directory in order
to find the necessary information about the file's size,
access rights, and specific location on the storage
device.

granted to other users of the system. In general, users
of Named Files are classified into one of two categories:
User and World. Users are used when different programmers and programs need to share information
stored in a file. The World classification is used when
rights are to be granted to all who can use the system.

The iRMX 86 BIOS uses an efficient format for writing
the directory and data information into secondary storage. This standard iRMX 86 format is fully compatible
with the ISO Media standard, and other Intel systems
such as the iRMX 88 Operating System. This structure
enables the system to directly access any byte in a file,
often without having to do additional I/O to access
space allocation information. The maximum size of an
individual file is 4.3 billion bytes.

PHYSICAL FILES
Physical Files allow more direct device access than
Named Files. Each Physical File occupies an entire device, treated as a single stream of individually accessable bytes. No access control is provided for Physical
Files as they are typically used for such applications
as driving a printing device, translating from one device
format to another,. driving a paper tape device, realtime data acquisition, and controlling analog mechanisms.

EASE OF ACCESS
The hierarchical file structure is provided to isolate and
organize collections of named files. To give operators
fast and simple access to any level within the file tree,
an ATTACHFILE command is provided. This command
allows operators to create a logical name to a point in
the tree so that a long sequence of characters need
not be typed each time a file is referred to.

STREAM FILES
Stream Files provide applications with a method of using iRMX 86 file management methods for data that
does not need to go into secondary storage. Stream
Files act as direct channels, through system memory,
from one task to another. These channels are very useful to programs, for example, wishing to preserve file
and device independence allowing data sent to a printer
one time, to a disk file another time, and to another
program on a different occasion.

ACCESS PROTECTION
Access to each Named File is protected by the rights
assigned to each user by the owner of the file. Rights
to read, append, update, and delete may be selectively

2-13

Order Number: 210885-002

inter

iRMXTM 86 OPERATING SYSTEM

BOOTSTRAP AND APPLICATION LOADERS

Two utilities are supplied with the System to load programs and data into system memory from secondary ,
storage devices:
The iRMX 86 Bootstrap Loader can be configured to
a size of less than 1K Bytes of P(ROM), and is typically
used to load the initial system from the system disk
into memory, and begin its execution. Error reporting
and debug switch features have been added to the Boot~
strap Loader. When the Bootstrap Loader detects errors such as: file does not exist or device not ready,
an error message is reported back to the user, The debug switch will cause the Bootstrap Loader to load the
system but not begin its execution. Instead the Boots~rap Loader will pass control to the monitor at the first
instruction to be executed by the system.

face, or the standard iRMX 86 Command Line
Interpreter (CLI). For example, you may choose to use
the Microsoft Basic Interpreter as this initial program.
After system start-up, each terminal user would be able
to run the interpreter without asking for it to be loaded.
From the BASIC interpreter, an operator, for example,
could run a data collection program, written i,; BASIC,
that communicates with several laboratory instruments,
and prints charts and reports based on certain test results. When finished entering, changing, or running
a BASIC program, the terminal would remain in BASIC
for the next user.
Specifying an application program as a terminal's
initial program makes the interface between operators
and the computer system much simpler. Each operator
need only be aware of the function of a particular application; not needing to interact with any unfamiliar functions also available on the application system.

The Application Loader is typically used by application
programs already running in the system to load additional programs and data from any secondary storage
device. The Human Interface layer, for example, uses
the Application Loader to load the non-resident Human
Interface Commands. The Application Loader is capable
of loading both relocatable and absolute code as well
as program overlays.

Specifying the standard iRMX 86 Human Interface CLI
as the initial program enables users of the terminals
to access all iRMX 86 functions. This CLI makes it easy
to manage iRMX 86 files, load and execute Intel-supplied
and custom programs, and submit command files for
execution.

Human Interface

FEATURE OVERVIEW

The flexibility of the interface between computer controlled machines and their users often determines the
usability and ultimate success of the machines. Table
11 lists iRMX 86 Human Interface functions giving users
and applications simple access to the file and system
management capabilities described earlier. The process, interrupt, and memory managment functions described earlier, are performed automatically for Human
Interface users.

The iRMX 86 Operating System is well suited to serve
the demanding needs of real-time applications executing on complex microprocessor systems. The iRMX 86
System also provides many tools and features needed
by real-time system developers and programmers. The
following sections describe features useful in both the
development and execution environments. The description of each feature outlines the advantages given to
hardware and software engineers concerned with overall systemcost,expandability with custom and industry
standard options, and long-term maintenance of iRMX
86-based systems. The development environment features also describe the ease with which the iRMX 86
Operating System can be incorporated into overall
system designs.

MULTI-USER ACCESS

USing the multi-terminal support provided by the BIOS,
the iRMX 86 Human Interface can support several simultaneous users. The real-time nature of the system
is maintained by providing a priority for each user, and
using the event-driven iRMX 86 Nucleus to schedule
tasks. High-performance interrupt response is guaran~
teed even while users interact with various application
packages. For example, multi-terminal support allows
one person to be using the iRMX 86 Editor, while another compiles a FORTRAN 86 or PASCAL 86 program,
while several others load and access applications.

Execution Environment Features
REAL-TIME PERFORMANCE

The iRMX 86 Operating System is designed to offer
the high performance, multi-tasking functions required
by real-time systems. Designers can make use of the
latest VLSI devices such as the 8087 or 80287 Numeric
Processor Extension, and the 80130 Operating System
Firmware Component to improve their system cost/performance ratio or the iMM)(TM 800 MULTIBUS® Message
Exchange software package to divide and coordinate
various system activities among multiple processors.
Typical iRMX 86 system performance characteristics
are shown in Table 5.

Each terminal attached to the iRMX 86 multi-user Human Interface is automatically associated with a user,
a memory pool, and an initial program to run when the
terminal is connected. This association is made using
a file that may be changed at any time. Changes are
effective the next time the system is initialized.
The initial program specified for each terminal can be
a special application program, a custom Human Inter2-14

Order Number: 210885-002

iRMXTM 86 OPERATING SYSTEM

Many real-time systems require high performance operation. To meet this requirement, all of iRMX 86 can
be put into zero wait-state P(ROM). This approach eliminates the possibility of disk access times slowing down
performance, while allowing system designers to take
advantage of high performance memory devices.

SYSTEM BUFFERS

AND OATA
APPLICA nON CODE

r

CONFIGURABILITY

RAM

810S

0.83

Interrupt Latency
(to handler)

0.29
(Max)

0.20
(Max)

Interrupt Latency
(to handler)

0.02
(Typical)

0.03
(Typical)

Context Switch Caused
By Interrupt

0.84
(Max)

0.78
(Max)

Send Message
(no context switch)

0.32

0.25

Send Message
(with context switch)

0.58

0.49

Send Control
(no context switch)

0.21

0.16

Send Control
(with context switch)

0.64

0.54

(no waiting)

0.26

0.19

I

BACKGrOUND

APPliCATION

-1

I

WINCHESTER
DISK

DRIVER

I

FLOPPY
DISK

DRIVER

NUCLEUS
PROM

BUILDING SECURITY
SYSTEM

RAM

ISBC"'86/30 ISeC'" 28611 0
Execution
Execution
Time (msec) Time (msec)
1.02

COMMON
UTILITIES

EIOS

Table 5. iRMXTM Real-Time Performance
Using iSBC® 86/30 and iSBC® 286/10
Single Board Computers

1

HUMAN INTERFACE

The iRMX 86 Operating System is configurable by system layer, and by system call within each layer. In addition all the 110 port addresses used by the System are
configurable by the user. This flexibility gives designers
the freedom to choose configurations of hardware and
software that best suit their size and functional
requirements. Two example configurations are shown
in Figure 7.

Real-Time
Function

OPERATOR
CONSOLE
APPLICATIONS

f

SYSTEM
BUFFERS
DATA
16K BYTES

APPLICA liON CODe
PROM

SK BYTES NUCLEUS CODE

.asp 86 INTERFACE
801300SF
DATA COMMUNICATION
CONTROLLER

Figure 7. Typical iRMXTM 86

Configuratio~s

Most configuration options are selected during system
design stages. Others may be selected during system
operation. For example, the amount of memory devoted
to queues within a Mailbox can be specified at the time
the Mailbox is created. Devoting more memory to the
Mailbox allows more messages to be transmitted to
other tasks without having to degrade system performance to allocate additional memory dynamically.
The chart shown in Table 6 indicates the actual memory
size required to support these different configurations
of the iRMX 86 System. Systems requiring only Nucleus
level functions may require no more than 13K bytes
for the Operating System. (Use of the iAPX 86/30 requires only 4K bytes of RAM, 7K bytes of initialization
code in EPROM and the 16K bytes of code in the 80130.)
Other applications, needing 110 management functions,
may select portions of additional layers that fit their
needs and size constraints.

Context switch time is the time between executing in the
context of a task, and the first instruction to execute in the
context of another task.
The execution times shown in Column 2were measured using an 8MHz iSBC Single Board Computer, 256K on-board
RAM, and all program and data stored in on-board RAM.
The execution times shown in Column 3 were measured using a 5MHz iSBC 286/10 Single Board Computer, no onboard RAM, and all program and data stored in LBX RAM.

This configurability also applies to the Terminal HandIer, Dynamic Debugger, and System Debugger. The
Terminal Handler provides a serial terminal interface
in a system that otherwise doesn't need an 110 system.
Either one of the debuggers need to be included only
as debugging tools (usually only during system development).

2-15

Order Number: 210885-002

iRMXTM 86 OPERATING SYSTEM

Table 6. IRMXTM 86 Configuration Size· Chart
System Layer

Min. ROMabie
Size

Max.
Size

,Data
Size

1K

6K*

Nucleus

10.5K

1.5K
24K

BIOS
EIOS

26K
4K
10.5K

78K
10K
12.5K

Human Interface
UDI
Terminal Handler

22K
8K
3K

22K
8K
3K

2K
1K
15K
0
O.3K

20K
28.5K

20K

1K

28.5K

1K
116K
308K

System Debugger
Dynamic Debugger

2K
1K

Human Interface Commands
Interactive Configuration Utility
* Usable by System after bootloadln9

MULTI·PROCESSING
The resources provided by a single processor are often
not enough to perform certain functions. With the standard interfaces provided by the iMMX 800 MULTIBUS
, Message Exchange package, the iRMX 86 Operating
System supports a loosely-coupled multi-processing
environment. Task running on one processor may communicate with tasks running on other processors, even
if they operate under different operating systems. The
iMMX 800 software is capable of sending messages
over the MUL TlBUS to tasks operating under either
the iRMX 88 Executive, or the iRMX 86 Operating System. Using this message exchange mechanism, applications may increase their system performance quite
easily, improve overall interrupt response, gain access
to the iSBC® 550 Ethernet Controller, and leave room
for future product enhancements"

Q

0

6fEE.

-

TERM',NALS

.SBe 534 1 - 0

DATA
COLLECTION
TERMINALS

MULTI·USER ACCESS
Many real-time systems must provide a variety of users
access to system control functions and collected data.
The iRMX 86 System provides easy-ta-use support for
applications to access multiple terminals. II also enables multiple and different users to access different
applications concurrently.
FigLOre 8 illustrates a typical iRMX 86 application simultaneously supporting multi-terminal data collection
and real-time environments. Shown is a group of terminals used by machinists on a shop floor to communicate with a job management program, a building
security system that constantly monitors energy usage
requirements, a system operator console capable of
accessing all system functions, and a group of terminals in the Production Engineering department used
to monitor job costs while developing new device control specifications instructions. The iSBC,544 Intelligent
Terminal Interface supports multiple user terminals
without degrading system performance to handle character 110.

Figure 8. Multi·Terminal and Multi·User
Real-Time System
EXTENDABILITY
The iRMX 86 Operating System provides three means
of extensions. This extendability is essential for support
of OEM and volume end user value added features.
This ability is provided by: user-defined operating system calls, user-defined objects (similar to Jobs, Tasks,
etc.), and the ability to add functions later in the product life cycle. The modular, layered structure. of the
System easily facilitates later additions to iRMX 86 applications. User-defined objects are supported by the
functions listed in Table 7.
Using standard iRMX 86 system calls, users may define
custom objects, enabling applications to easily manipulate commonly used structures as if they were part
of the original operating system.

2-16

Order Number: 210885·002

iRMXTM 86 OPERATING SYSTEM

Table 7. User Extension System Calls
Function Performed

System Call
RQ$CREATE$COMPOSITE

Creates a custom object built of previously defined objects.

RQ$DELETE$COMPOSITE

Deletes the custom object, but not the vanous objects from which It was built

RQ$INSPECT$COMPOSITE

Returns a list of Token Identifiers for the component objects from which the 2jJeciiled
composite object is bUilt.
I

RQ$ALTER$COMPOSITE

Replaces a component object of a compOSIte object.

RQ$CREATE$EXTENSION

Creates a new type of object and assigns a mailbox used for collecting these objects
when they are deleted.

RQ$DELETE$EXTENSION

Deletes an extension definition.

as the iMMX 800 MULTIBUS Message Exchange, and
an Ethernet communication interface are supported
by optional software packages available to run on the
iRMX 86 System.

EXCEPTION HANDLING
The System includes predefined exception handlers
for typical 110 and parameter error conditions. The error
handling mechanism is both configurable and extendable.

SPECTRUM OF CPU PERFORMANCE

SUPPORT OF STANDARDS

The iRMX 86 Operating System supports a broad range
of Intel processors. In addition to support for iAPX 86
and 88 based systems, the iRMX 86 system has been
enhanced to support iAPX 186, 188, and 286 (Real Address Mode)-based Systems. This new support enables the user to take advantage of the faster speed
and higher performance of Intel's 286 based microprocessors such as the iSBC 286/10 single board
computer. By chOOSing the appropriate CPU, designers
can choose from a wide range of performance options,
without having to change application software.

The iRMX 86 Operating System supports the many
hardware and software standards needed by most application systems to ensure that commonly available
hardware and software packages may be interfaced
with a minimum of cost and effort. The iRMX 86 System
supports the iSBC family of products built on the Intel
MULTIBUS (IEEE Standard 796), and a number of
standard software interfaces such as the UDI and the
common device driver interface (See Figure 9). The
procedural interfaces of the UDI are listed in Table 9.
The Operating System includes support for the proposed IEEE 80-bit extended real-variable format of
the 8087 Numeric Data Processor, and the IEEE 796
(MULTIBUS) hardware interface. Other standards such

• ElHEANET IS a

,~ .. t.."d

COMPONENT LEVEL SUPPORT
The iRMX 86 System may be tailored to support specific
hardware configurations. In addition to system memory,

Itademark <>1 X"ro' Corp

Figure 9. iRMXTM 86 Standard Interfaces

2-17

Order Number: 210885·002

iRMXTM 86 OPERATING SYSTEM

only an iAPX 86, iAPX 88, iAPX 186, iAPX 188, or iAPX .
286 microprocessor, an 82591\ Programmable Interrupt
Controller (PIC), and either an 8253, 8274,.or 82530
Programmable Interval Timer (PIT) are required as
follows:
• iAPX 86 and iAPX 88 systems need either:
- 8253 PIT and 8259A PIC (master) or
- 80130 firmware (PIC is master)

boards each supporting up to four standard RS232
terminals.
The new RAM disk feature in iRMX 86 makes a portion of the memory address space look like a disk drive
to the 1/0 system.

Table 8. Supported Devices
ISBC@ Device
ContrOller

• iAPX 186 and iAPX 188 systems where 186 PIC is
slave, needs either:
- 8253 PIT and 8259A PIC (master) or
- 80130 firmware (PIC is master)
where 186 PIC is master:
- Uses 186 PIT for the system clock; no external
PIT is needed
- Can use either
186 PIC (master) only or
8259A180130 PIC (slave)

iSBC@ 86,88

Serial Port to CRT, Parallel Port to
Centronics-type Printer, Interval Timer
and Interrupt Controller.

iSBC''' 186/03

Small Computer System Interface
(SCSI) Supporting All Random
Access "Extended Standard"
SCSI/SASI hard disk controllers.

iSBC@ 204
iSBC@ 206

• iAPX 286 systems need
- 8253 PIT and 8259A PIC.
Alternatively, the iRMX 86 Operating System may be
used in conjunction with the 80130 Operating System
Firmware Component that not only provides these hardware functions, but eliminates the need for approximately 16K bytes of the i.RMX 86 Nucleus code (see
Figure 7). For systems requiring extended mathematics
capability, an 8087'or 80287 Numeric Data Processor
may be added to perform these functions up to 100 times
faster than equivalent software. For applications servicing more than 8 interrupt sources, additional 8259A's
may be configured as slave controliers.

Description

Single Density Diskette.
Cartridge-Type Hard Disk.

iSBC@ 208

Single & Double Density, Single &
Double Sided, 8" & 5.25" Diskettes.

iSBC@ 215(G)
iSBX@ 218

Standard Winchester Disks.
Single or Double denSity, Single or
double sided, 8-inch diskettes
(when used on an·iSBC 215(G)).

iSBX@ 218A

Single or Double Density, Single or
Double Sided, 8" & 5.25" Diskette
(when used on an iSBC 215G Win·
chester Controller).

iSBC@ 220
iSBX@ 251
iSBC@ 254(S)

Standard Storage Module Board.
Bubble ·Memory Multimodule Board.

iSBX@ 351

1-Channel Serial Port to CRTs,
Modems.

Bubble Memory Board.

iSBC@ 534,544 4-Channel Serial Ports to CRTs,
Modems.
ISBXTM 270
Black and White CRTs and full
ASCII keyboards.

BOARD LEVEL SUPPORT
The iRMX 86 Operating System includes device drivers
to support a broad range 01 MULTIBUS device controllers. The particular boards and types of devices
supported are listed in Table 8. The device controllers
all adhere to industry standard electrical and functional
interfaces.

NOTE: (G)

=

(S)

=

optional iSBC 215, iSBC 215B,
or iSBC 215G
optional iSBC 254 or iSBC 254S

Development Environment Features
The iRMX 86 Operating System supports the efficient
utilization of programming time by providing important
tools for program development. Some of the tools necessary to develop and debug real-time systems are included with the Operating System. Others, such as
language compilers, are available from Intel and from
leading Independent Software Vendors.

In addition to the on-CPU board terminal drivers, the
iRMX 86 BIOS includes two iSBC board-level device
drivers to support multiple terminal interfaces:
The iSBC 544 Intelligent Four-Channel Terminal Interlace Device Driver provides support for multiple
controllers each supporting up to four standard RS232
terminals. The iSBC 544 drivertakes advantage of an
on-board 8085 processor to greatly reduce the system
processor time required for terminal 1/0 by.locally
managing input and output bulfers. The iSBC 544
firmware provided with the operating system can offload the system CPU by as much as 75% when doing character outputting.

LANGUAGES
The iRMX 86 Operating System supports 31 standard
system calis known as the Universal Development Interface (UDI). Figure 9 shows the iRMX 86 standard
interfaces to many compilers and language translators,
including the iAPX 86 and 88 Macro Assembler; the
PASCAL 86/88, PUM 86/88, FORTRAN 86/88 and C86
compilers available from Intel. Also included are other

The iSBC 534 Four-Channel USART Controlier Device
Driver also provides support lor multiple controlier
2-18

Order Number: 210885·002

iRMXTM 86 OPERATING SYSTEM

Intel development tools, language translators and utilities available from other vendors. Any application that
ran on the iRMX 86 Release 5 Universal Runtime Interface (URI) will run on the iRMX 86 Release 6 UOI. The
full set of UOI calls (which includes the URI system
calls) is required to run a compiler.

These standard software interfaces (the UOI) ensure
that users of the iRMX 86 Operating System may transport their applications to future releases of the iRMX 86
Operating System and other Intel and independent
vendor software products. The calls available in the
UOI are shown in Table 9.

Table 9. UOI System Calls
Function Performed

System Call
Memory Management:
DQ$ALLOCATE Creates a Segment of a specified size DQ$FREE

Returns the specified segment to the System

DQ$GET$SIZE*

Returns the size of the specified Segment.

DQ$RESERVE$IO$MEMORY* Reserves memory to OPEN and ATTA'CH files - File Management: DQ$ATTACH
DQ$CHANGE$ACCESS*

Creates a Connection to a specified file.
Changes the user access rights associated With a file or directory.

DQ$CHANGE$EXTENSION

Changes the extension of a file nam,e

DQ$CLOSE Closes the specified file Connection. DQ$CREATE

Creates a Named File.

In

memory.

DQ$DELETE Deletes a Named File, DQ$DETACH

Closes a Named File and deletes ItS Connection

DQ$OPEN Opens a file for a particular type of access, DQ$GET$CONNECTION$STATUS*

Returns the curr!!nt status'of the specified file Connection

DQ$FILE$INFO *

Returns data about a file ConnecllOn.

DQ$READ Reads the next sequence of bytes from a file. DQ$RENAME*

Renames the specified Named File.

DQ$SEEK Moves the posillOn pOinter of a file, DQ$TRUNCATE

Truncates a file.

DQ$WRITE Writes a sequence of bytes to a file, Process Management: DQ$EXIT

EXits from the current application job,

DQ$OVERLAY* Causes the specIfied overlay to be loaded DQ$SPECIAL

Performs special 110 related functions on terminals With speCial control
f,eatures,

DQ$TRAP$CC

Captures control when CNTRUC is typed,

Exception Handling:
DQ$GET$EXCEPTION$HANDLER Returns a pointer to the program currently being used to process errors. DQ$DECODE$EXCEPTION Returns a short deSCription of the specified error code. DQ$TRAP$EXCEPTION Identifies a custom exception processing program for a particular type of error. Application Assistance: DQ$DECODE$TIME DQ$GET$ARGUMENT* Returns system lime and date In binary and ASCII character format. Returns the next argument from the character string used to invoke the applicallOn program, DQ$GET$SYSTEM$ID *

Returns the name of the underlying operating system supporting the UDL

bQ$GET$TIME*

Returns the current time of day as kept by the underlYing operallng system

DQ$SWITCH$BUFFER

Selects a new buffer from which to process commands,

• Calls available only through the UDI

2-19

Order Number: 210885-002

iRMXTM 86 OPERATING SYSTEM

The high performance of the iRMX 86 Operating System enhances the throughput of compilers and other
development utilities. Table 10 indicates the average
performance of typical development environment
functions operating in the same configuration
described in Figure 4.

Table 11. Major Human Interface Utilities.(Con.t.)
Command

Table 10. Development Environment Performance
Function

Average
Execution Time

Directory Command
(S Format with 25 files)

5.3 sec

Load the COPY Command

1.2 sec

Copy a 1K By1e File
(Winchester to Winchester)

1.0 sec

Copy a 16K By1e File

1.7 sec

Copy a 64K Byte File
Copy a 1K Byte File
(Winchester to Diskette)

3.9 sec

Compile PLiM 86

3931pm

Compile PASCAL 86
Program

4531pm

1.4 sec

Function

TIME

Set the system time·of-day clock.

VERIFY

Verify the structure of an IRMXTM 86
Named File volume. and ch'l~k for
possible disk data errors.

INTERACTIVE CONFIGURATION UTILITY
The iRMX 86 Operating System is designed to provide
OEMs the ability to configure for specific system hardware and software requirements. The Interactive Configuration Utility (ICU) builds iRMX 86 configurations
by asking appropriate questions and making reasonable
assumptions. It runs on either an Intellec® Series III
development system or iRMX 86 development system
that includes a hard disk and the UDI. Table 12 lists
the hardware and support software requirements of
different iRMX 86 development system environments.
Table 12. iRMXTM Development Environment
Intellecl!> Series III:
MDS 313 PUM 86/88 Compiler
One hard disk and one diskette drive

TOOLS

iRMXTM 86 Development System
iRMXTM 860 ASM 86 Assembler and
'Utilities
iRMXTM863 PUM 86/88 Compiler
iSDM 86 or 286 System Debug Monitor
512K By1es of flAM
5M By1e On-Line Storage and one
double-density diskette drive

Certain tools are necessary for the development of
microcomputer applications. The iRMX 86 Human Interface includes many of these tools as non-resident
commands. They can be included on the system disk
of a application system, and brought into memory when
needed to perform functions as listed in Table 11.
Table 11. Major Human Interface Utilities
Command

SYSTEM 86/300 or 286/300 Series
Microcomputer System Basic configuration

Function

BACKUP

Copy directones and files from one
device to another.

COpy

Copy one or more files to one or
more destination files.

CREATEDIR

Create a directory file to store the
names of other files

DIR

list the names, Sizes, owners, etc.
of the files contained in a directory.

ATTACHFILE

Give a logical name to a specified
location In a file directory tree.

PERMIT

Grant or rescind user access to a
file.

RENAME

Change the name of a file

SUBMIT

Start the processing qf a senes of
commands stored In a file.

SUPER

Change operator's 10 to that of the
System Manager with global access
rights and privileges.

Figure 10 shows one of the many screens displayed
during the process of defining a configuration. It
shows the abbreviations for each choice on the left,
a more complete description with the range of possible answers in the center, and the current (sometimes
default) choice on the right. The bottom of the screen
shows three changes made by the operator (lower
case lettering), and a request for help on the Exception Mode question. In response'to a request for help,
the ICU displays an additional screen outlining possible choices and some overall system effects.
The ICU requests only information required as a result
of previous choices. For example, if no Extended 110
System functions are required, the ICU will not ask
any further questions about the EIOS. Once a configuration session is complete, the operator may save all
the information in a file. Later when small changes are
necessary, this file can be modified. A completely new
session is not required.
2-20

Order Number: 210885-002

inter

iRMXTM 86 OPERATING SYSTEM

PARAMETER VALIDATION
Nucleus
(ASCI
lPV)
(RODI
(MTS)
{DEH}
(NEH)
(EM)
(NRI

All Sys Calls IYeslNol
Parameter ValidatIOn IVes/No]
Root Oblect D"ecto~ SlZeIO-OFFOhl
MInimum Transfer Size IG-OFFFFH]
Default ExceptIOn Handler !YeslNolOeblUsej
Name of Ex Handler Object Module [1- 32chs]
ExcepllOn Mode INeverlProgramfEnvtronlAIIJ
Nucleus In ROM IYeslNol

Some iRMX 86 System Calls require parameters that
may change during the course of developing iRMX 86
applications. The iRMX 86 Operating System includes
an optional set of routines to validate these parameters
to ensure that correct numeric values are used and that
correct object types are used where the Systf'm expects
to manipulate an object. For systems based only on the
iRMX 86 Nucleus, these routines may be removed to
improve the performance and code size of the System
once the development phase is completed.

Yes
Yes
OOt4H
0040H
Yes
Never
No

Enter Changes [Abbreviations '/ =new-value] ASC =N
pv=no
rod=48

em'

Figure 10. ICU Screen for iRMXTM 86 Nucleus

START·UP SYSTEMS
Two ready-to-run, mUlti-user start-up systems are included in the iRMX 86 Operating System package.
These iRMX 86 start-up systems are fully configured,
mUlti-user iRMX 86 Operating Systems ready to be
loaded into memory by the Bootstrap Loader. Both
start-up systems are configured to include all of the
system calls for each layer and most of the features
provided by iRMX 86. iRMX start-up systems include
UDI support so that users may run languages such as
PUM-86, Pascal, FORTRAN, and software packages
from independent vendors.
The start-up system for the iAPX 86 processor is configured for Intel SYSTEM 86/300 Series microcomputers with a minimum of 384K bytes of RAM. The
following devices are supported.

REAL·TIME DEBUGGING TOOLS
The iRMX 86 Operating System supports three distinct
debugging environments: Static, Dynamic, and PostMortem. While the iRMX 86 Operating System does
support a multi-user Human Interface, these real-time
debugging aids are usually most useful in a single-user
environment where modifications made to the system
cannot affect other users.
System. Debugger
The static debugging aid is the iRMX 86 System Debugger. This debugger is an extension of the iSDM 86
and the iSDM 286 System Debug Monitors. The System
Debugger provides static debugging facilities when
the system hangs or crashes, when the Nucleus is inadvertently overwritten or destroyed, or when synchronization requirements prevent the debugging of certain
tasks. The System Debugger stops the system and allow you to examine the state of the system at that instant, and allows you to:
- Identify and interpret iRMX 86 system calls.
- Display information about iRMX 86 objects.
- Examine a task's stack to determine system call
history.

• iSBC 215liSBX 218 or iSBC 215GliSBX 218A
•
•
•
•

iSBC 254(S)
Line Printer
8251A Terminal Driver
iSBC 544 Terminal Driver

The start-up system for the iAPX 286 processor is configured for Intel SYSTEM 286/300 Series microcomputers with a minimum of 512K bytes and a maximum
of 896K bytes of RAM. The following devices are supported.

iRMXTM 86 Dynamic Debugger

• iSBC 208
• iSBC 215/iSBX 218 or iSBC 215G/iSBX 218A

The iRMX 86 Dynamic Debugger runs as part of an
iRMX 86 application. It may be used at any time during
program development, or may be integrated into an
OEM system to aid in the discovery of latent errors.
The Dynamic Debugger can be used to search for errors
in any task, even while the other tasks in the system
are running. The iRMX 86 DynamiC Debugger communicates with the developer via a terminal handler
that supports full line editing.

• iSBC 254(S)
• Line Printer for iSBC 286/10
• 8274 Terminal Driver
• iSBC 544 Terminal Driver
Either system will run without hardware or software
configuration changes and can be reconfigured on a
standard system with at least 512K bytes of RAM. Definition files are also included for iSBC 186/03, 186/51
and 188/48 configurations.

System Crash/Dump Analyzer
The often difficult job of debugging real-time applications is made much simpler with the System
Crash/Dump Analyzer. The analyzer allows program
developers to record system memory for later analysis even if the system has halted. This analysis lists
such vital information as which jobs have active tasks,
which system queues contain which tasks, and what
segments contain which data.

This start-up system may be used to run the ICU (if a
Winchester disk is attached to the system) to develop
custom configurations such as those pictured in Figure
8. As shipped, the Human Interface supports a single
user terminal. However, the Start-up System terminal
configuration file may be altered easily to support from
two to five users.
2-21

Order Number: 210885-002

inter

iRMXTM 86 OPERATING SYSTEM.

SPECIFICATIONS

iSBC 215(G) Winchester Disk Controller

Supported Software Products

iSBX 218(A) Flexible Diskette Multi-Module
Controller

iRMX 860

iSBC 220 SMD Disk Hard Controller

iRMX 86 Development Utilities
Package, including the iAPX 86
and 88 Linker, Locater, Macro
Assembler, Librarian, and the
iRMX 86 Editor.

iSBC 254(S) Bubble Memory System
iSBC 534 4-Channel Terminal Interface
iSBC 544 Intelligent 4-Channel Terminal Interface
and Controller

iRMX 861

PASCAL 86/88 Compiler

iRMX 862

FORTRAN 86/88 Compiler

iRMX 863

PLIM 86/88 Compiler

iRMX 864

TX Screen-oriented Editor

iSBX 351 Serial Communications Port

iMMX 800

MULTIBUS Message Exchange
software package for iRMX 86,
and 88 application systems

iSBX 270 CRT Light Pen and Keyboard Interface

iOSP 86

iRMX PSCOPE 86

iSBX 251 Bubble Memory Multi-Module
iSBX 350 Parallel Port (Centronics-type Printer
Interface)
.

SYSTEM 86/300 Family
SYSTEM 286/300 Family

Support Package for iAPX 86130,
88/30,186/30, and 188130 Operating System Processors

AVAILABLE LITERATURE
The iRMX 86 Documentation Set is comprised of the
following four volumes of reference manuals. Order
numbers are associated with these four volumes only.

High Level Language Debugger

Supported Hardware Products

iRMX 86 INTRODUCTION AND OPERATOR'S REFERENCE MANUAL FOR RELEASE 6
Order Number: 146545-001 .

COMPONENTS
iAPX 86 and 88 Microprocessors
iAPX 186 and 188 Microprocessors

Introduction to the iRMX 86 Operating System

iAPX 286 Microprocessors (Real Address Mode only)

iRMX 86 Operator's Manual

8087 Numeric Data Processor Extension

iRMX 86 Disk Verification Utility Reference Manual

80287 Numeric Data Processor Extension

iRMX 86 PROGRAMMERS REFERENCE MANUAL
FOR RELEASE 6, PART I
Order Number: 146546-001

iAPX 86/30 (80130) Operating System Firmware Component
8253 and 8254 Programmable Interval Timers

iRMX 86 Nucleus Reference Manual

8259A Programmable Interrupt Controller

iRMX 86 Basic I/O System Reference Manual

8251A USART Terminal Controller

iRMX 86 Extended I/O System Reference Manual

8255 Programmable Parallel Interface

iRMX 86 PROGRAMMERS'S REFERENCE MANUAL
FOF! RELEASE 6, PART II
Order Number: 146547-001

8274 Terminal Controller
82530 Serial Communications Controller

iRMX 86 Application Loader Reference Manual

iSBC® MULTIBUS BOARD AND SYSTEM PRODUCTS

iRMX 86 Human Interface Reference Manual

iSBC 86/12A, 86/05, 86/14, 86/30, 86/35, 88/25, and
88/40 Single Board Computers

iRMX 86 Universal Development Interface Reference
Manual

iSBC 186/03 Single Board Computer
iSBC 186/51 Ethernet Controller

Guide to Writing Device Drivers for iRMX 86 and iRMX
88 1/0 Systems

iSBC 188/48 Communications Controller

iRMX 86 Programming Techniques

iSBC 286/10 Single Board Computer(Real Address
Mode only)

iRMX 86 Terminal Handler Reference Manual

iSBC 204 Diskette c:ontroller

iRMX 86 System Debugger Reference Manual

iSBC 206 Hard Disk Controller

iRMX 86 Crash Analyzer Reference Manual

iSBC 208 Diskette Controller

iRMX 86 Bootstrap Loader Reference Manual

iRMX 86 Debugger Reference Manual

2-22

Order Number: 210885-002

inter

IRMXTII 86 OPERATING SYSTEM

iRMX 86 INSTALLATION AND CONFIGURATION
GUIDE FOR RELEASE 6
Order Number: 146548-001

Ap Note 174 - Optimizing the iRMX 86 Operating
System Performance on System 86/310 and System
861330 (Order Number: 230990-001)

iRMX 86 Installation Guide
iRMX 86 Configuration Guide
Master Index for Release 6 of the iRMX 86 Operating
System

Training Courses
The iRMX 86 Operating System

Application Notes
Customer Seminars

Ap Note 130 - Using Operating System Processors
to Simplify Microcomputer Designs. (Order Number:
230786-001

Contact local Intel Sales Office for details on available
video·tape and slide presentations.

ORDERING INFORMATION

iRMX 86 KIT JRO:

The iRMX 86 Operating System is available under a
number of different licensing options as noted here.
Source listings are available on microfiche. Reconfigurable object libraries are provided on double density
ISIS-formatted diskettes or on either double density,
single sided iRMX 86-formatted 8" diskettes, or double
density, double sided, 5.25" diskettes. ISIS-format disk·
ettes may be used on Intellntellec Development Systems. The iRMX 86-format may be used on any iRMX
86-based system supporting the appropriate compilers
and development environment.

Double density, double sided
5.25" iRMX 86-Format OEM Ii·
cense for use on iRMX 86-based
environments.

Other licensing options include prepayment of all future
incorporation fees, single use rights for a single mach·
ine, use at a second development site, one year update
service extensions, the right to make copies for addi·
tional development systems, and source listing materials.

The OEM license options listed here allow users to
incorporate the iRMX 86 Operating System into their
applications. Each use requires payment of an Incor·
poration Fee.
ORDER CODE

DESCRIPTION

Each option includes 90 days of support service that
provides the quarterly iRMX 86 Technical Report, Soft·
ware Problem Report Service, anctcopies of System
Updates that occur during this period. Except for source
listings, all initial licenses include a complete set of
iRMX 86 Documentation.

iRMX 86 KIT BRO:

Double density, single-sided 8"
ISIS format OEM license
Double density, single sided 8"
iRMX 86-Format OEM license
for use on iRMX 86-baSed en·
vironments.

As with all Intel software, purchase of any of these options requires the execution of a standard Intel Master
Software License. The specific rights granted to users
depends on the specific option and the License signed.

iRMX 86 KIT ERO:

243

Order Number: 210885-002

'/

-n+ _I~

II I'ell

iOSpTM 86
iAPX 86/30, IAPX 88/30, iAPX 186/30 and
iAPX 188/30 SUPPORT PACKAGE
and run-time support for
with IntellP> PLIM 86, PAS• Development
• Compatible
IAPX 86/30, 88/30, 186/30, and 188/30
CAL 86, FORTRAN 86, and ASM86 MACOperating System Processors

RO ASSEMBLER

{P)ROM or
based system
•
• Supports
• Supports custom system Initialization
Extendable with iRMXTM 86 Operating
• System
calls
• Interactive Configuration Utility
Total iRMXTM 86 Operating System 'software compatibility

R~M

The Intel iOSpTM 86 SUppOI1 Package for the iAPX 86/30, 88/30, 186/30, and 188/30 Operating System
Processors contains a comprehensive set of easy-ta-use tools needed to develop (P)ROM or RAM-based applications that use the 80130 Operating System Firmware component. This Suppol1 Package is compatible
with all versions of the 80130 component. All of the system initialization and run-time facilities are provided
in libraries that may tie configured to specific requirements, and linked to application programs written in either
ASM86 MACRO ASSEMBLER or a high level programming language such as PASCAL 86, FORTRAN 86,
and PUM 86. The iOSP 86 Package provides users with the basic initialization ahd interface routines needed
to build application software based on the fundamental operating system functions of the iAPX 86/30, 88/30,
186/30, and 188130 Operating System Processors. The iOSP 86 Package also enables users to add higher
level I/O functions from the fully compatible iRMXTM 86 Operating System, or to form custom, real-time
systems.

.." ,

Intel Corporation Assumes No Responsibility for the Use of Any Circuitry Other Than Circuitry Embodied in an Intel Product. No other CircUit
Patent Licenses are implied,

2-24

JUNE,1984
ORDER NUMBER: 210236.()()2

inter

iOSpTM 86

FUNCTIONAL DESCRIPTION
The iAPX 86/30, 88/30,186/30, and 188/30 Operating System Processors (OSPs) provide an easy-touse foundation on which many real-time applications
may be built. They provide the functions and system
support needed to implement both simple and complex applications that require multiple tasks to run
concurremly (see Figure 1). These services are made
possible by the addition of the five new data types
integrated into the 80130 Operating System Firmware
(OSF) component. The 80130 OSF extends the basic data types of the CPU (integer, byte, character, etc.)
by adding new system data types (JOB, TASK, MAILBOX, SEGMENT, and REGION), and extensive timer,
interrupt, memory, and error management designed
to give real-time response to multitasking and multiprogramming applications. As shown in the second
half of the figure, other operating system functions
such as mass storage 1/0 services and an easy-touse Human Interface can be added easily, by using
modules from the iRMX 86 Operating System. The
iOSP 86 Support Package provides both an interface
between application software and the Operating System Processors, and development tools designed to
make the implementation and initialization of realtime, multitasking sYlltems much easier.
The iOSP 86 Support package provides system developers with the configuration options necessary to
tailor the iAPX86/30, 88/30,186/30, and 188/30 Operating System Processors to custom applications. Central to the entire configuration process is the
Interactive Configuration Utility (ICU86). This utility
is an easy-to-use tool which allows you to make configuration decisions by responding to screen-oriented
displays. Using' the ICU, users can build the necessary support code. The interface libraries form a sim-

pie interface between application software and the
operating system primitives of the 80130 OSF component.

Memory and 1/0 Addressing
The 80130 OSF requires that a 16K byte block of,
memory address space be reserved for accessing internal functions. The ICU is used to specify the base
address of the 80130,and the beginning of the initialization support code.
All Interrupt and Timer management of the OSF is
controlled via a reserved 16 byte 110 address block
that may be selected by the user. In addition, from'
1 to 7 slave 8259A interrupt controllers can be specified in order to provide the system with up to 57 priority interrupt sources. The 80130 baud rate generator
may also be configured to support an optional terminal interface.

Extending the 80130 OSF
The 80130 OSF allows users to add their own operating system extensions. These extensions may take
advantage of the detailed and efficient intertask communication and synchronization primitives already
provided by the 80130, andlor may utilize custom
functions tailored to specific applications. The Support Package also enables users to extend the OSF
with the extensive services of Intel's iRMX 86 Operating System, thereby allowing applications to. grow
without having to change or alter application software
already written, or having to write other operating system software.
Use of the 80130 OSF with the iRMX 86 Operating
System reduces the amount of memory needed for
the iRMX 86 Nucleus layer by 14K bytes, and enables applications to take advantage of the increased

COMPLEX
APPLICATION SOFTWARE
COMPILERS
HUMAN INTERFACE

APPLICATION SOFTWARE

EIOS
BASIC 1/0 SYSTEM
iRMX'· 86 NUCLEUS

iOSP'· 86 INTERFACE LIBRARIES

8087
(OPTIONAL)

8086
8088
80186
OR
80188

iOSP'· 86 INTERFACE LIBRARIES

8087
(OPTIONAL)

80130

8086
8088
80186
OR
80188

80130

Figure 1. Structure of Typical Systems
2-25

210236-002

inter

iOSpTM 86.

performance and reduced size requirements inherent in the iAPX 86/30, 88/30, 186/30, and 188/30
Operating System Processors. Since each of the services provided by the 80130 component is totally compatible with iRMX 86, applications have an automatic
upward path to support complete file systems and
multiple processor environments.

Parameter Validation
Parameter validlition is a configuration option of an
OSP-based system. The OSP can check the
parameters of the primitive that you invoke either on
a systemwide basis or on a per job basis.

Operating System Calls
Application Interfaces

The 80130 OSF performs a total of 38 operating system primitives all of which are completely compatible with the equivalent iRMX 86 Operating System
calls. The iOSP 86 Support Package provides userlevel, interfaces to these primitives to enable applications to create, delete, control, and exchange the
new data types provided by the 80130 OSF. In general, these interfaces allow application software to
manage all of the resources of an iAPX 86/30, 88/30,
186/30, or 188/30 OSP (and an optional 8087 Numeric
Processor Extension) system via any of the 38 system calls shown in Figure 2.

Two interface libraries are included in the iOSP 86
Support Package. The first allows programmers to
write application software modules in the Compact
Model of computation supported by Intel's compilers.
The second provides an .interiace to program segments written in either the Medium or Large Models.
The iOSP 86 Support Package does not support program segments written in the Small Model.
The interface libraries provide the means of accessing all of the primitives supported by the Operating
System Processors. With this interface, and all the
memory management primitives of the OSPs, applications have full access to 1M byte of memory, and
all of the addressing modes of the CPU.

Required Development Hardware

These libraries are fully compatible with object modules produced by the ASM86 MACRO ASSEMBLER,
and the PASCAL 86, FORTRAN 86, and PUM 86
Compilers.

a

Application Initialization
The iOSP 86 Support Package provides, via the ICU,
for the configuration of the system ROOT JOB, and
all user application JOBs that require initialization
when the system is started. The user also specifies
the configuration of the interrupt system (including
the optional iAPX 186/188 interrupt controller in either
master or slave modes and any slave 8259A interrupt controllers) and the clock rate used for system .
timing. These choices are automatically programmed
into the various devices when the system is initialized.
JOB GROUP
CREATE JOB

SEGMENT GROUP
CREATE SEGMENT
DELETE SEGMENT

SLEEP
SET PRIORITY

REGION GROUP
CREATE REGION
DELETE REGION
sEND CONTROL
ACCEPT CONTROL

MAILBOX GROUP
CREATE MAILBOX
DELETE MAILBOX
SEND MESSAGE

Use of the iOSP 86 Support Package requires a Series III Intellec Development System iNith double density flexible diskette drives or any iRMX 86 system
supporting standard 5.25 inch or 8 inch flexible diskette drive and the iRMX 860 Assembler and Utilities Package. Use of the 80130 requires only a
minimal system including either the iAPX 86/30,
88/30, 186/30 or 188/30 Operating System Processor, and enough system memory to contain the application programs and initialization and interface
software provided in the iOSP 86 Package.

Board Level Product Support
Intel microcomputer boards which use the 80130 OSF
include the iSBC 186/03 and the iSBC 186/51 Single Board Computers. An iOSP 86 application may
be written specifically to run on these boards.

OBJECT MANAGEMENT GROUP
CATALOG OBJECT
LOOKUP OBJECT
DISABLE DELETION
ENABLE DELETION
GET TYPE

INTERRUPT MANAGEMENT GROUP
SET OS EXTENSION
SETINTERl'lUPT
ENTER INTERRUPT
EXIT INTERRUPT
WAIT INTERRUPT
SIGNAL INTERRUPT
RESET INTERRUPT
ENABLE
DISABLE
GET LEVEL
ERROR CONTROL GROUP
SET EXCEPTION
SIGNAL EXCEPTION
GET EXCEPTION

Figure 2. Operating System Primitives
2-26

210236·002

iOSpTM 86

Part Number Description
OSP 86 B

iOSP 86 Support Package contained on an ISIS-II compatible,
single-sided, double density 8 inch
diskette.

ORDERING INFORMATION
Each of the ordering options listed below include all
the necessary initialization and interface procedures
needed to use the iAPX 86/30, 88/30, 186/30, and
188130 Operating System processors. Purchase of the
iOSP 86 Package requires verification of an Intel
Master Software License. Each package also includes
an iOSP 86 User's Manual (Document Number
146798-001), and a 90 day update service.

2-27

OSP 86 E

iOSP 86 Support Package contained on an iRMX 86 format,
single-sided, double density 8 inch
diskette.

OSP 86 J

iOSP 86 Support Package contained on an iRMX 86 format
double-sided double density, 5.25
inch, 48 tracks-per-inch diskette.

iRMXTM 86-MULTIBUS® II
SUPPORT PACKAGE
MULTIBUS® II support for iSBC® 286(100
Automatic software configuration of
• memory
• applications
boards
in Real Address Mode,
including support for the SCSI peripheral interface and up to 1 megabyte
Functions in conjunction with the
iRMXTM 86 Release 6 Operating System

•
• Interp,rocessor Signal Support

Support for battery backed-up, global
• time-of-day
clock
to allow addition of custom
• Extendable
device drivers

The iRM)(TM 86-MULTIBUS® II Support Package, functioning with the iRMX 86 Release 6 Operating System software, provides the ability to execute all configurable layers of the iRMX 86 software in the MULTIBUS II environment (iRMX 86-MULTIBUS II Operating System). Applications in Real Address Mode are supported for the iSBC®
286/100 board, including support for the SCSI peripheral interface and all iSBX™ boards supported by iRMX 86
Release 6, as well as support for iAPX 286 component applications.

HUMAN INTERFACE

USER APPLICATIONS

NEW IN iRMXTM 86
MULTIBUSII
OPERATING SYSTEM

0
iRMXTM VLSI Operating System

The followIng are trademarks of Intel CorporatIon and may be used only to describe Intel products· Intel. ICE. IMMX, IRMX, ISBC, iSBX, iSXM, MULTIBUS,
MULTICHANNEL and MULTIMODULE. Intel Corporation assumes no responsibility for the use of any CIrcuitry other than Clrcuttry embodied in an Intel
product. No other circurt patent lIcenses are imploed. Information contained hereon supercedes previously published speclficatons on these devices from Intel.

© INTEL CORPORATION, 1984

2-28

SEPTEMBER, 1984
ORDER NUMBER: 280057.001

inter

iRMXTM 86-MULTIBUS® II Support Package

FUNCTIONAL DESCRIPTION
Overview
The iRMX 86 MULTIBUS II package contains system
modules that replace portions of the iRMX 86 Release
6 Operating System, allowing the iRMX 86 Operating
System to execute in a MULTIBUS II environment. All
the functions available in the IRMX 86 Operating System are available in the iRMX 86-MULTIBUS II Operating System. For a complete description of these
functions, their value, and performance, please refer
to the Release 6 iRMX 86 Operating System Data Sheet
(order number 210885-0(2).
This functional description section describes the new
features provided by the iRMX 86 MULTIBUS II package. These new features add the new capabilities required for OEMs to execute the iRMX 86 Operating
System in a MULTIBUS II environment for iSBC 2861100
or iAPX 286 applications in Real Address Mode.

Interprocessor Signal Support

nal messages are not tied to hardware interrupt levels and priorities as external interrupts were in the
MULTIBUS I environment.

Automatic Software Configuration of
Memory Boards
The iRMX 86-MULTIBUS II Operating System has the
option of automatically configuring memory boards. The
addresses for each board are defined sequentially in
relation to the phYSical placement of each board in the
card cage. This feature allows for the swapping, adding, and deleting of memory boards in the system on
a dynamic basis.

Accurate Time-of-Day Clock Support
Resident in every MULTIBUS II system is a Central
Services Module (iSBC CSM/001 board). The CSM
board contains a battery backed-up, global time-of-

DECODE
LOGIC
2

SYSTlCK

A~1S

INT1

INTOySS

A7- A O LOCAL (+SYS)

Al~

~A8

~
"4 l\f
A7

PROCESSOR DATA BUS

015--00

V

<---;:,.

I

e-

»

l'
....

DT/A

=r--J

~

~

~

~I-

;L-

\r

.

~

So !\.j--

illi

N . C - DELAY

-

!J1..----

BAUD

r

BUS

;,.

A19-A16
BHE i+-

o SERIAL INT

r

-

INT
ACKU-

SYSTEM

Ai.

14='~

+51

NC-

ACCORDING TO APPUCATION)

A"

(AS)

~~6)

-

(ON-BOARD)

(PROM, PERIPHERALS, RAM

1\

8282

INTGND MAX

~

LOCAL
RESOURCES

~'STB
\

BHE

V A\6

jl~

8282

S>

SYSTEM
CONTROL
BUS

A19

(A4)

MOl

~~,(Ii

}

SIGNALS

8288
(A3)

"";'STB

NMI

TEST

1

CONTROL

(CONTROL BUS)

~

STB
~1-'-

p:

BHE

A1 9

~

"S2-

~I---

AEN1 RDY2

~

r-k-

S>-

ClK

,--'-

~

,.,,---

IIl\r

DE
015
8286

(A8)

~"~86lftry-(A9J
DO

\r-

1

~:"~--

FOR MULTI-MASTER SVST

vss

Figure 5. Basic iAPX 86/30 Microcomputer System Block Diagram

SYSTEM

DATA
BUS

AP·130

libraries being added to his application during the linking and system configuration steps. These memory requirements are shown in Figure 6. In practice, the
separate blocks in this figure would be grouped together
for more efficient use of RAM and EPROM chips.
The 80130 occupies a 16K-byte block of addresses in the
host-processor memory space, so external logic should
decode address bits A19 -A14 to generate MEMCS~
Similiarly, the timer arid interrupt control logic occupy
a 16-byte block of addresses in the I/O space; at least
some of the bits A15 -A. must be decoded to generate
IOCS. The 80130 decodes all the lower-order address
bits (14 for memory, four for I/O internally).

The OSP requires a certain amount of off-chip memory
for its own operation. The system must provide at least
lK bytes of RAM at address OOOOOH for the CPU
interrupt vectors, plus another 150(\0 bytes for OSP
system variables, data structures, stacks, and the like.
This RAM may reside anywhere in the 8086 megabyte
address space, although it is often contiguous with the
interrupt vector up front. Application tasks must each
have their own stack, so allow at least an additional 300
bytes of RAM for each.
Any iAPX 86 system must have ROM or EPROM at the
upper end of memory to hold the CPU restart vector.
About 3400 more bytes are consumed by code to initialize and access the OSP. This code is generated automatically from libraries on a diskette provided with a
product called the iAPX 86/30 and iAPX 88/30 Operating System Processor Support Package (iOSP 86).
Space left in the initialization EPROMs is available for

Firmware in the 80130 leaves a great deal of flexibility in
decoding the chip-select signals, to be compatible with
whatever decode logic is already present in the system.
The I/O starting address may be on any 16-byte boundary in the full CPU I/O space. The memory block has
only two restrictions: the off-chip initialization and interface code memory must be placed immediately
above the MEMCS block, so the 80130 may not occupy
the extreme top of memory, nor may the 80130 reside at
address OOOOOH since this area is reserved for interrupt
vectors.

As code is being written, the system designer should
count on another 1500 bytes of code from the support

iAPX 86/30 SYSTEM MEMORY REQUIREMENTS
OFFFFOH

POWER ON-LOCATION

80130 INITIALIZATION AND CONFIGURATION
CODE (ROM/EPROM)

MUST BE
CONTIGUOUS
16K FOR 80130 ON 16K BOUNDARY

x

1.5K CODE BYTES SYSTEM INITIALIZATION (ROM/EPROM)

1.SK RAM BYTES FOR IAPX 86/30 STACK AND DATA (RAM)

400H
1K BYTES
r////////////A }

RESERVED FOR
INTERRUPTS (RAM)

Figure 6. Operating System Processor System Memory Requirements

2-54
AFN-02058A

AP-130

respond during T3 . In each case, the chip-select signals
must be active TCSCL before the end of state T2 .
Assuming wait states aren't desired, addresses
generated by the CPU must propagate through the address latches and be decoded during Tl or T2 .
How much time does this leave the decode logic? As
we'll see, ample.

Timing Requirements
System timing analysis is often the most tedious part of
digital hardware design. This discussion can be rela-,
tively short, though, because the 80130 timing is quite
simple: by design, the part is compatible with the timing
of the host processor. Since it interfaces directly with
the CPU pins, traditional set-up, hold, and access times
no longer matter.

By convention, TCLAV is the delay from the start of
Tl until address information is valid on the CPU pins;
TIVOV is the propagation delay through an 8282 latch;
and TCSCL is the 80130 chip-~elect set-up time. The
mnemonic Tovcs represents the chip-select logic propagation delay, after the latch outputs are stable. The
sum of these four delays must be less than two system
clock cycles, reduced by the clock transition time.

There are really only two areas of concern in analyzing
the timing of most asp systems, both of which relate to
the user-generated chip-select signals. Figure 7 illustratesthe relevant timing signals of a standard 8086
four-state Read cycle (memory or 110), along with the
timing responses of the 80130. 1I0Write cycle timing is
the same. (Full timing diagrams are part of the respective data sheets.)

T1VOV

+

Tovcs

Tovcs :5 T CLCL

+

T CLCL - T CLAV - T1VOV - TCSCL

T CLAV

The first concern is that MEMCS and IOCS,must be
active early in a memory or 110 cycle if the 80130 is to

T'
I

• TCHCL

-'

ClK

.

n

1
52,51. SO

9

\

140

TW

J

+

TCSCL :5 T CLCL

- 60

I
,

I;SHC~

- 30

+

T CLCL

- 20 (osee.)

T'

j

J

/

~

BHE, Al"5-AO VALID

+ 125
osee.

T3

TClSH

I

I~ASCH·I
V

125

:5

/
relel

TSVCH

.:CHSV·

:5

I

T2

I

reLCH

+

X----reseL

H

S

/

,Ioes

-

CK
TSACK

'fJIJNX
-l r-TCSAK
Y

~

I
TSACK

I

H
~

FLOAT

I

WRITE DATA VALID

I

REA DCVCLE

ACK

~

I
I--

I

TDseL

I

WRIT E CYCLE

TClDV

~

j..-TCSAK

I

I

F9

FLOAT

TCLVE

~

\

Figure 7. Operating System Processor Timing Diagrams
2-55
AFN·02058A

AP·13.0

In a "normally not ready" design" acknowlejlge signals
are generated when each resource is accessed. The
individual acknowledgements are combined to form a
system-wide ready signal which is synchronized by the
8284A clock generator via 'the RDY and AEN inputs.
The 8284A can be strapped to accept asynchronous
ready signals (asynchronous operation) or to accept
synchronous ready signals (synchronous operation).
Synchronous 8284A operation provides more time for
address latch propagation and chip-select decoding. In
addition, inverting ACK off chip produces an activehigh ready signal compatible with the 8284A RDY inputs, which have 'shorter set-up requirements than
AEN inputs. (As a side benefit, a NAND gate used like
this can combine ACK with the active-low acknowledge signals from other parts ofthe system.) Based on
these assllplptions, the time available for address latch
propagation and chip-select decoding at 8 MHz is:

The propagation delay numbers plugged into the equation are worst-case values from the appropriate Intel
data sheets. The CPU is an 8086-2 operating at 8 MHz.
This means the Flddress decode logic must produce
stable C~ outputs within 140 nanoseconds.

Exercise 2. Using standard', low-power Schottky
TTL, does it make sense for a circuit to take
longer than 140 nsec. to decode 6 program or 12
110, address bits? Even if the rather liberal setup
specs are not met, the 80130 would still work fine.
Wait states would be needed until the ,chip-select
signal was active, however, so performance
'

The second point of concern relates to ready signal
timing. The 80130's acknowledge output signal, ACK,
can be used to control the CPU's ready signal. For this
case, the chip-select signal must be active early in a
memory or 110 cycle to allow activation of ACK early
enough to prevent wait states. There are tWQ schemes
for implementing ready signals; "normally ready" and
"normally not ready." (For more details, refer to AP67, "8086 System Design. ") Chip-select timing is more
critical in some "normally not ready" systems.

TCLAV ~Tovcs + TCSAK + BR;VCL sTCLCL + TCLCL
Tovcs s 2 TCLCL - TCLAV - TCSAK - TRIVCL
s
250
60
110
35
s
45 nsec.

The circuit in Figure 8 which uses Schottky TTL components leaves about 15 nsec. to produce MEMCS from

8288
80130

8086

OSF

ALE

CPU

A19

lOG 80

A18

70

70

G2B

A17

60

6Q

G2A

Gl

All

50

50

C

40

4Q

B

3D

30

A

748373

74S138

}DECODE

1mll:I'
lit:R

SYSTEM
ACKNOWLEDGE

Vee

-

Figure 11., Hlgh-!i)peed Address Decoding Circuit
2-56
AFN·02D5SA

AP-130

system has 4K bytes of 2114 RAM (with sockets for
another 4K), from 8K to 32K bytes of 2732A or 2764
EPROM, an 8251A USART operating at 9600 baud, and
an 8255A Programmable Peripheral Interface with 24
parallel 110 lines. Eight of the inputs read logic values
off DIP switches; eight outputs drive small LEDs. Four
more outputs connect to the coil drivers of a four-phase
stepper motor. A layout diagram of the prototype appears in Figure 9.

the high-order address bits-more than enough for the
74S138 one-of-eight decoder shown.
Granted, this does not leave much leeway to fully
decode the 110 address bits. A 12-input NAND gate on
ADI5-AD4 could be used, introducing only a single
propagation delay but forcing the 110 register block to
start at OFFFOH. Incomplete decoding is also legal:, it is
safe to drive IOCS with the (latched) AD15 signal directly, provided all other ports in the system are disabled when this bit is low. In this case, the effective
address of the 110 block (which must be specified during the system configuration step) could be OOOOH, or
any other multiple of 16 between OOOOH and 7FFOH.

The system is even simpler than the discussion of
"typical" requirements implied. The 8086 direct-bus
drive capability is adequate to make the data transceivers unnecessary. (To equalize the bus loading, the
8255A is connected to the upper half of the bus.) Address decoding logic was minimized by making the
high-order address bits "don't-cares." Moreover, the
part count could have been reduced to 16 using an 8088
and multiplexed-bus 8185 RAMs and 8755A EPROMs.
(The reader may be surprised to learn that, except for
wire-wrapping mistakes, the prototype system hardware worked when it was first powered up. The author
certainly was!)

Again, the OSP system will still operate even if the
memory or 110 decoding is slow. The acknowledge
signal returned to the host CPU would just be delayed
accordingly, 'so unnecessary wait states would be inserted in access cycles, but the 80130 would not malfunction. Only rarely does the OSP access resources in
its 110 space. Even if slow decode logic were to insert
several wait states into every 110 cycle, the overall
effect on system performance would be insignificant.

APPLICATION SOFTWARE
DEVELOPMENT

A few words of caution, though. If the 8284A is strapped for synchronous operation, external circuitry must
guarantee that ready-input transitions don't violate the
latch set-up requirements. Also, the chip-select signal
must not remain low so long after the address changes
that the 80130 could respond to a non-80130 access
cycle.

Like other well-structured programs, application
software to run on the iAPX 86130 is written as a number of separate procedures or subroutines. In conventional programs, though, execution begins with a
section of code (the program body) at the outermost
level. The program calls application procedures, which
may call other procedures, but which eventually run to
completion and return to the program body.

Exercise 3. Suppose the typical timing values for
a particuiar decoder would easily meet the readyinput set-up requirements presented above for
asynchronous 8284A operation, but pathological
worst-case figures were just a little slow. Could
that circuit still be used safely in most applications? What would happen if the worst-case combination of worst-case conditions ever actually
did occur? These occasional extra wait states
would probably not cause a hard system failure.

In an OSP application, though, there is no "outermost
level" in the traditional sense; rather, the procedures
are started, suspended, and resumed as situations warrant under the control of the OSP. The term "task"
refers to the execution of such a procedure in this way.
While an instruction stream is suspended, the OSP
keeps track ofthe task state (instruction counter, CPU
register contents, etc.) so that it may be resumed later.

Exercise 4. Earlier it was mentioned that the acknowledge signal could also be used to avoid ~us
contention. Prove that with any decode logic
which meets the above requirements,ACK would
disable the bus transceivers before the host CPU
samples the bus.

Each task is assigned a relative priority by the programmer, on a scale of 0 (high priority) to 255 (low). Tasks
with higher (numerically lower) priority are given preferential treatment by the OSP; the task actually controlling the CPU at any given instant will be the one with the
highest priority which is not waiting for some 'event to
occur. (If all this sounds confusing, examples coming
later may help.)

Example System Design
Appendix A includes full schematics for a complete
iAPX 86130 system providing considerable functionality with only 27 chips. In addition to the OSp, 'the

A task which operates independent of other tasks can
be written without knowing anything about the others.
2-57
AFN-02058A

AP·130

RESISTORS
8086

SWITCHES

D~Ll

B1

80130

B4

Figure 9. Example System Prototype Layout

This makes it easy to divide a very large programming
job among a ~eam of programmers, each writing the
code for some of the tasks. Moreover, a task need not
even know if other tasks exist. They may be tested and
debugged before others have even been written. As an
application evolves, new tasks may be added or unnecessary ones removed without affecting the rest.

ent motor, and a different console might make up a
second job.) .
All OSP application jobs must have one special initialization task (often called INIT$TASK) just to get . started; this 'One may, in turn, create other tasks as, it executes. The initialization task for this example is discussed at the end of this chapter. The number of tasks in an application may need to be qUite large. The number of tasks allowed in one application is essentially unlimited, as is the number of other objects-regions, mailboxes, segments, and the like. (The term "object" relates to different types of data structures maintained internally by the OSP.) Each object is internally identified by a unique 16-bit "token," which means the theoretical maximum total is over 65,000. The more pragmatic issue 'of physical memory consumption limits the number of simultaneous concurrent tasks to "only" several thousand. Hardware Initialization The life of any task can be broken into three phases: start-up, execution, and termination, The start-up phase initializes variables, data structures, and other objects needed by the task. During the execution phase the task performs its useful work. Depending on the application, this may be a single sequence of actions, or a loop executed repeatedly. When the task completes, it must terminate itself so as not to use any more CPU time. One or more phases may be omitted. For example, some tasks are intended to execute "forever," in which case the termination phase is not required. (When a number of tasks cooperate to accomplish some common goal, the collection of tasks is referred to as an application "job." The OSP also allows for an unlimited number of application jobs, though only one is illustrated in the example discussed here. A second similar machine, with different status switches, a differ- ThisJife cycle is suggested by Example 1, a segment of code called HARDWARE$INIT$TASK. This task first .2-58 AFN-02058A AP-130 programs the 80130 internal timer logic to generate a square-wave cycle on the BAUD pin every 52 system clock cycles, which corresponds to a system console data rate of 9600 baud. The task then sets the system's 8255A PPI and 8251A USART devices to operate in the desired modes, and outputs a short sign-on message to the CRT. For the sake of reader's unfamiliar with the protocol for interfacing with the 8251A, simple input and output routines (C$IN and C$aUT) are reproduced in Example 2: the procedure RQ$DELETE$TASK, suicidally sper;:ifying itself as the task to be deleted. Exercise 5. Beginners may make two common programming errors when developing asp tasks. The first is when a task deletes itself without ever resuming the suspended task that created it. The second is to not terminate a task properly, with the result that the processor executes a return instruction when the task's work is done. (However, execution of the task did not originate with a call from the as.) As with all computers, an asp will do exactly what it is told. How do you suppose the system would react in each case? (Hint: only one of the two failure modes is predictable.) HARDWARE$INITtTASK PROCEDURE,
DECLARE HARDtINITSEXCEPTtCODE WORD.
DECLARE PARAM'~l C*l BYTE DATA (40H. SOH. DOH. 40H. 4EH. 27H).
DECLARE PARAM.51$INDEX BVT£, DECLARE SIGN.ON.MESSAGE (*1 BYTe DATA (CR. LF. 'lAPX Sib/3D HARDWARE INITIALIZED', CR, LF). DECLARE SIGNtON.INDEX BYTE, You may have noticed three things from this short example and Table 1. First, every asp call begins with the letters RQ. (PL/M compilers totally iguore dollar signs within symbols; they serve only to split long symbol names to make them easier for humans to read.)The letters RQ don't mean anything in particular; their purpose is to make sure asp routine names don't conflict with any user symbols. These particular letters were chosen to be compatible with the historical naming convention used by iRMX 86. It may be useful, though, to think ofRQ as an abbreviation for REQUEST, implying that the asp provides useful services at the bidding of application code. QUTPUTCPP ISCMD)=9OH, OUTPUT CT I MER$CMD) =OB6H.

OVTPUT(BAUDSTIMERI-33.
I*GENERATES ~600 BAUD FROM :5 MHZ*I
OUTPUT CBAUD.TIMER )=0.
DO PARAMS51$INDEX-O TO (SIZECPARAM'tSl )-1) J CUTPUT- bO THEN DO. ACSCYCLE.COUNT=O, CALL RQtSlQNALtINTERRUPT(AC'INTERRUPTSLEVEL, ~AC'EXCEPTSCDDE) • END. ELSE CALL RG,EXITSINTERRUPTCACSINTERRUPTtLEVEL. @AC'EXCEPT'CaDE). END AetHANDLER. Example 5. 60-Hz A.C. Interrupt Handler "Interrupt Tasks," on the other hand, are higher-level tasks which sit idle until "released" by an interrupt handler. The task then executes along with other active tasks, under the control of the OSp. Such a task should be used to perform slower but less time-critical processing when occasions warrant, such as when the aforementioned buffer is full. Moving such additional processing outside the hardware-invoked interrupt handler reduces the worst-case interrupt processing time. In its initialization phase, TIME$TASK sets up the
interrupt handler by calling the RQ$SET$
INTERRUPT routine. The body ofTIME$TASK (the execution phase) is just a series of nested loops counting hours, minutes, and seconds. When TIME$TASK
calls RQ$WAIT$INTERRUPT inside its inner-most
loop, the OSP suspends execution of the task until
AC$HANDLER signals that another second's worth of A.C. cycles has elapsed. Thus, interrupt handlers can serve to "pace" interrupt tasks. After a day, TIME$TASK completes and deletes itself.

This hierarchy also decreases interrupt latency. Most
OSP primitives execute in their own, private
"environment" (e.g., with their own stack and data
segments) rather than that of the calling task. Interrupt
handlers, on the other hand, run in the same environment as the interrupted task. (In fact, the 80130
primitives may themselves be interrupted!) Leaving the
CPU segment registers unchanged minimizes software
overhead and interrupt response time, but also means
that interrupt handlers may not call certain OS,
routines. An interrupt task, on the other hand, is initiated and suspended by the OSP itself, with no such
restrictions.

DECLARE SECONDsCOUNT BYTE.
MINUTE'COUNT BVTE.
HOURtCOUNT BVTE.
TIHE$TASK PROCEDURE. DECL.ARE TIHESEXCEPTSCODE WORD. ACSCVCL.E'COUNT=O. CALL. RQSSETSINTERRUPTCACtINTERRUPTtliL.EVEL..OlH. INTERRUPTSPTR(ACtHANDL.ER), DATASSEQSADDR aASE. @TIHEtEXCEPTtCDDE). CALL. ROSRESUMESTASK( INIT$TASKSTOKEN.I:TIME.SEXCEPTSCODE).
DO HDURsCDUNT=O TO 23.
DO MINUTESCOUNT-O TO 59.
DO SECONOSCOUNT=O TO 59,
CALL ROsWAITSINTERRUPT CAC.INTERRUPT.LEVEL.
@TIMEsEXCEPTSCODEl.
IF SECONosCOUNT MOD 5 = 0
THEN CALL. PROTECTED.CRTtOUT (BEL.l.
END.
1* SECOND LOOP "'1
END.
1* MINUTE LOOP *1
END.
1* HOUR LOOP *1
CALL ROSRi!:SETSINTERRUPTCACSINTERRUPTSLEVEL.
ITIMESEXCEPTSCODE) •

Let's see how these capabilities would be used. The
time delays introduced by the RQ$SLEEP call are only as accurate as the crystal frequency from which they are ultimately derived: This may not be exact enough for critical time-keeping applications, since oscillators vary slightly with temperature and power fluctuation. Example 6. Interrupt Task to Maintain Time of Day To keep track of the time of day, the example system uses a 60-Hz A.C. signal as its time base. (Most power utility companies carefully regulate line frequency to exactly 60 Hz, averaged over time.) A signal from the power supply is made TTL-compatible to drive one of the 80130 interrupt request pins. An interrupt handler responds to the interrupts, keeping track of one second's worth ofA.C. cycles. An interrupt task counts the seconds by incrementing a series of variables. Exercise 7: The time maintained by TIME$TASK
is consistently wrong, unless the system resets at
midnight. Aside from that, how much error would
accumulate per month had TIME$TASK paced its inner loop by calling RQ$SLEEP if the system
oscillator was 00.01% off? How does this compare with a cheap digital watch? How much error
will accumulate from the 60-Hz time base
described?

Example 5 illustrates the former routine. AC$HANDLER simply increments a variable on each 60Hz interrupt. Upon reaching 60, it clears the counter and signals TIME$TASK (Example 6).

TIME$TASK incorporates another gimmick: every five seconds it sends an ASCII "BEL" character (07H) to the console to make it beep, by calling a routine called PROTECTED$OUTPUT. This lead-in gives us a
chance to discuss OSP provisions for task synchronization and mutual exclusion.
2-61
AFtI-02058A

AP-130

Exercise 8: In this example, would it be better if
Tasks, A and B shared a single output routine, so
that only' one section of code sent data to the
USART? Convince yourself that the same (or
worse!) problems could still arise.

Mutual Exclusion
Whenever system resources (e.g., the console) are
shared among mUltiple concurrent tasks, the software
designer must be aware of the potential for conflicts. In
the easiest way to transmit characters is by calling a
console output routine (written by the user or supplied
by the OS) which outputs the character code.
(Remember the examples following the hardware initialization routine?)

Sometimes critical sections can be protected by just
disabling interrupts at appropriate points in the application software. To maintain the integrity of an iAPX
86/30 system, application code must never execute the
STI, CLI, or HLT instructions (ENABLE, DISABLE,
or HALT statements in PUM), nor can it access the
interrupt control logic directly. Instead, the interrupt
status should be controlled w'ith the OSP
RQ$ENABLE and RQ$DISABLE procedures;
routines should be halted via RQ$SUSPEND or RQ$WAIT$INTERRUPT. This approach presents two problems in a multitasking system. One is efficiency: a high-priority task could 'hang up the whole system while it waits for a printer solenoid to energize, induce a magnetic field, accelerate the hammer, contact a daisy-wheel spoke, move it up to the ribbon, and press them both against the paper. This waste of time is termed "busy waiting," and should always be avoided. By OSP standards, even 1130 of a second can seem interminable; if the printer is otherwise occupied, the whole system could shut down indefinitely. Back toTIME$TASK: we want to transmit BELs to the
console every five seconds. The console output task
will be transmitting other 'characters. A "clever" programmer may recognize that this will lead to a critical
section and analyze the situation as follows:
1. A hazard would arise if TIME$TASK sends out a beep when CONSOLE$OUT$TASK is using the USART; , Aside from efficiency, though, there is a more serious synchronization problem here. Assume Task A has a higher priority than Task B. Task A is asleep. Task B calls a subroutine to poll the USART and transmit a character. The lJSART becomes ready. When this is detected, the subroutine prepares to output the character to the USART .... 2. TIME$TASK will only execute after being signaled
by A$C$HANDLER;
3. A$C$HANDLER only reponds to an external
interrupt.
"Therefore, all CONSOLE$OUT$TASK has to do to
be safe is disable the 60-Hz interrupt around its output
routine. "

Time out! Task A just woke up and starts running. Task
A wants to transmit its own character. It calls its own
output routine, checks the USART, fi~ds it available,
sends it a new character, and goes back to sleep
(or suspends itself, or awaits another interruptwhatever).

Not quite. There are still potential hazards. Suppose
CRT$OUT$TASK has the same priority as
TIME$TASK. TIME$TASK may already have been
signaled by A$C$HANDLER and be ready to run when
CRT$OUT$TASK completes. An otherwise unrelated
event-another interrupt, for instance-could momentarily suspend CRT$OUT$TASK during the critical region withA.C. interrupts disabled. When the OSP
returns to that level, it might resume with
TIME$TASK, not CRT$OUT$TASK. This could lead to the same malfunctions as before, so disabling 60-Hz interrupts didn't help. This series of worst-case assumptions is admittedly convoluted, but the resulting sporadic errors are among the hardest of all bugs to, squash. Now Task B continues. It "knows" the USART is available, having dutifully monitored it earlier. Task B's character goes out to the USART. The USART goes out to lunch. (In practice, the USART will probably just transmit corrupted data; still, its operating requirements have been violated.) In Task B's output routine, the sequence of statements from when the peripheral is found to be ready to when the next character is written constitutes a "critical region" (a.k.a. "critical section" or "non-interruptable sequence"). Recognizing such regions and handling them, correctly is an important concern in any multitasking system, so the asp provides several facilities ~interrupt control, regions and mailboxes-to help 'handle general synchronization and mutual exclusion problems. Which one to choose depends on the circumstance. The problem is that this attempted solution involves too much interaction between tasks, making it confusing and error-prone. Even if some scheme of priority-level 'assignments and task interactions could be made to work, later modifications or simple additions to the job 2-62 AFN'()2058A AP-130 could cause bugs to reappear. (The analogy of an unexploded time bomb comes to mind.) baud is only one millisecond, however, much shorter than a system tick. Besides, tasks performing character I/O will all have low priority levels, so the OSP would just delay them if anything more urgent comes up. A simpler solution would be one corresponding more closely with the problem. Accordingly, the OSP supports several primitives just to supervise and control access to critical regions. Exercise 9: Decide whether this explanation is a feeble attempt at rationalization, or a welljustified engineering trade-off. One of the OSP "data types" is a data structure called a "Region," which can be used by application code to control access to a shared port or some other resource. A task wishing access to the resource should call the OSP procedure RQ$RECEIVE$CONTROL before trying to access that resource; when done it must call RQ$SEND$CONTROL. Inter-Task Communication But what if a high priority task must output a string of characters, or the peripheral response time is too long? Busy-waiting may not be acceptable. Alternatively, the output routine could buffer the data and service the USART within an interrupt routine. Another would be to simply pass the data off to a special (low-priority) output task and continue. The OSP keeps track of which regions are in use. As long as a region is busy (i.e., has been entered but not yet exited), the OSP will prevent other tasks from entering the region by putting them to sleep. The OSP keeps a qu~ue of all tasks waiting for the busy region. When the regum later becomes-available (i.e., when the task controlling the region calls RQ$SEND$CONTROL), one ofthe sleeping tasks-either the highest priority or the most patient-will be awakened, granted control of the region, and sent on its way. (When a region is created the OSP is told whether to awaken tasks waiting for th~ region based on their priority or how long they have been waiting.) Effectively, a call to RQ$
RECEIVE$CONTROL will not return to the application task until the resource in question becomes available. Tasks pass information to each other via something called a "message." A message may be the token for any type of OSP object, but the most common and most flexible type is called a "memory segment." In our example, segments will be used to carry strings of ASCII characters between tasks, so we'll examine segments first. Message formats are defined by the individual application programmer-make sure the sending and receiving tasks assume the same format! A memory segment is just a section of contiguous-system RAM allocated (set aside) by the OSP at the request of an executing task. The OSP keeps track of a free memory "pool," which is initially all unused RAM in the system. When a task needs some RAM, it tells the RQ$CREATE$SEGMENT procedure how much it wants. The OSP finds a suitable memory block in the pool, a,nd returns a 16-bit token defining its location. (If not enough memory is available, the procedure returns an exception code.) The PROTECTED$CRT$OUTPUT (Example 7) demonstrates this protocol. The routine is declared ree~trant which means (by definition) the routine may be mterrupted and restarted safely. A reentrant routine may be shared by a number of tasks, instead of replicating the same code throughout the application. The token is the base portion of pointer to the first usable byte of the segment, with the offset portion assumed to be zero. (The token values for all other objects have no physical significance.) Knowing this it's possible to access elements of the segment as th~ application warrants. PROTECTED'CRr.OUT PROCEDURE (CHAR) REENTRANT, DECLARE CHAR BYTE, DECLARE CRT.EXCEPT$CODE WORD.
CALL Ra'RECEIVEtCONTROL (CRT'REGIQN$TO~ENI ~CRT$EXCEPT$CQDE), DO WHILE (INPUnSTAT.51) AND {)lH)"O, 1* NOTHING! *1 END. OUTPUT (CHAR.51 ) ""CHAR , CALL ROSSEND.CONTROL (&CRT$EXCEPT$CODE), END PROTECTED.CRT.OUT, Example 7. CRT Output Routine Protected by Region Protocol The subroutine in Example 8 shows how to request a segment and construct a message. PRINT$TIME sends
the ASCII values of the time-of-day counters
(maintained in TIME$TASK) to the CRT output task described later. The message format adopted for these examples will consist of a byte giving the message As a concession to simplicity, PROTECTED$
CRT$OUTPUT does use a form of the busy waiting method described earlier. The maximum delay at 9600 2-63 AFN·02058A Ap·130 i PRINT.STATUS, PROCEDUREI DECLARE STATUS.tESSAOE.TOKEN W~D. DECLARE STATUStEXCE'TKODE WORDi DECLARE BTATUS.SEQI'1ENT.DFFSET WORD, STATUS'SEQMENn8ASE WORD, DECLARE STATUS.HOMENT.PNTR POINTER AT (HTATUS.SEGI'ENT.OFFSET), DECL.ARE STATUS.TEMPL.ATE (40) BVTE DATA (39. 'THE SWITCHES ARE NOW SET TO B',CR.L,.F). DlfCLARE STATUhSTRINO BASED STATUS.SEOMENT"'NTR (40) BVTE. DECLARE STATUBtSTRINO.INDEX BVTE. ' DECL.ARE Bn.PATTERN BYTE, length, followed by that 'number of ASCII characters. Figure 10 shows this format. PRINn:TDD PROCEDURE. DECLARE TOD.MESSAOE.TOIODUTR INC;H 24) -Aac I1fCODE (SECONDtCOUNT MOD 10). CAL.L. R(ifBEND.MESSAGE (CRTtMAILBQX.TQKEN, TOD.MESSAQE.TDKEN. 0, .TOD.e:XCEPTfCDDE). RETURN. END PRINT.TODl Example 9. Subroutine to Send'Status Report Message to Output Task Example 8. Subroutine to Send Tlme-of-Day Message to Output Task Exercise 10: One input port is read by both STATUS$TASK and PRINT$STATUS. Does this constitute a shared resource? A critical region? We're coding PRINT$TIME here (see Example 8),
whileTIME$TASK is fresh in our minds. It will actually be called 'by (and is therefore considered a part of) KEYBOARD$TASK. Note that while task~ are written
as individual procedures, they need not be fully selfcontained: outside procedures should be used to help
organize and structure the code.

Exercise 11: PRINT$TIME reads the counts maintained by TIME$TASK, but doesn't alter
them. Forced mutual exclusion is generally
mandatory when multiple tasks perform
~eadlmodify/write sequences on a given variable.
Can PRINT$TIME make TIME$TASK malfunc~
tion? What about the opposite case? If this failure
mode was deemed unacceptable, how could it be
protected?

The first thing PRINT$TIME does' is have the OSP create a segment of suitable length, and copies a "message template" into the segment, byte by byte. Then it converts the TIME$TASK counter values to
ASCII, filling in blanks in the template. Finally, it sends
the token for the message to the CRT mailbox.

Mailboxes
The data in a message doesn:t actually move or get
copied from source to destination when the message is
sent; this would be too slow with long messages.
Rather, the OSP "carries" the message's token from
'task to task via a data structure cleverly termed a
mailbox. If one task must send messages to another, a
mailbox must be created to hold them. The' sender calls
the RQ$SEND$MESSAGE to put a message
token into the mailbox. If the receiver isn't ready for
the message yet, the OSP puts the message token
into an ordered queue. When the receive~ calis RQ$To repeat, these examples are intended to illustrate use of the OSP routines assuming minimum familiarity with PUM. Better programming practices might take advantage of PL/M literals, structures and' the array LENGTH function to build the message, rather than the inflexible constants shown here. Some of thj:se techniques are suggested by PRINT$STATUS
(Example 9), which indicates the binary status of the
input switches.

OFl'SET=

t! I·N. I'E'
4

I

T

lap IT

I .1·1 ,.·I·E' I I ·1' I~·I I'N·I ~'I·w·1 1. I·r I·:· 1. 1'4·1 .:' 1. '1 ~'I·'" I
ep

ep

ep

1•

3;

SEGMENT STARTING ADDRESS - TOO$MESSAGESTOKEN:OOOOH Figure 10. Message Formats Expected by Output Task 2-64 5 CR I LF, I AP-130 RECEIVE$MESSAGE later, the OSP will give it the
tokens one at a time.
What happens if a task tries to receive a message when
the mailbox is empty? (This is quite possible, since
tasks do run asynchronously.) What token would the
OSP return?

PROCEDURE,
DECLARE MESSAGE"LENQTH BYTE.
DECLARE MESSAGE. TOKEN WORD.
DECLARE RESPONSE.TOKEN WORD.
DECLARE MESSAQE'EXCEPUCODE WORD.
DECLARE MESSAQESSEQMENTSOFFSET WORD.
MESSAGE.SEGMENT.BASE WQRDJ
DECLARE MESSAQE'SEQMENTSPNTR POINTER AT
(@MESSAGE.SEGMENT.OFFSET) ,
DECLARE MESSAGE.STRINO.CHAP BASED MESSAGlE'SEGMENTSPNTR BYTE,

DO FOREVER I
,
MESSAGE,TOKEN-RO.RECE lVE.MESSAGE (CRTSMAILBoxsrOKEN. OFFFFH.
I:RESPONSE.TOM.EN. eI'1ESSAGE.EXCEPTtCODE) •
I'1ESSAOESSEOI'1ENTSOFFSET=OJ
I'1ESSf\OE.SEQI'1ENT.BASE-MESSAGESTOKEN,
MESSAOESLENGTH-MESSAGEtSTR ING.CHAR.
DO MESSAGEtSEQMENTSOFFSET-1 TO MESSAGESLENGTH.

In the simple case. . . it doesn't! Instead of returning
right away with no data, the OSP will wait until data is
available. In the meantime, the OSP puts the receiving
task to sleep, remembering that it is waiting for a
message at that mailbox. The next time a message is
sent to that mailbox, the OSP will awaken the receiving
task, give it the token, and-if its priority is high
enough-resume its execution. Alternatively, receiving
tasks may elect to not wait if the mailbox is empty, or to
wait only a specified time.

CALL PROTECTED.CRTSOUT (MESSAGE.STR I NO.CHAR ) I
ENOl
CALL ROtDELETESSEGMENT(MESSAQESTOKEN. (tMESSAQE'fEXCEPTSCODEl.
END.
1* OF FOREVER-LOOP *1
END

Example 10. Task to Transmit Messages
to the CRT

from the details, yet at times the two parts must be
manipulated separately (for instance, to access data in
an OSP segment knowing only the segment token/base
value).

Many tasks may actually send and receive messages
through a single mailbox, with messages being queued
in the order that the RQ$SEND$MESSAGE calls are
executed. The OSP also maintains a list of tasks waiting
to receive messages from an empty mailbox, analogous
to the queued tasks waiting for region control. As each
message is sent to themailbox.itis passed immediately
to a waiting task, either the one waiting the longest or
the one with the highest priority (likewise determined
by a parameter specified when the mailbox is created).

To get around this, these examples assign a pair of word
variables to the same address as a PLiM pointer variable. Each representation is then an alias for the other.
To determine the base or offset value of an item of data,
load the pointer variable with a pointer to the item and
then reference the appropriate field of the overlayed
pair of word variables. To "build" an arbitrary pointer,
assign computed values to the base and offset fields and
then access the data item via the composite pointer.

Exercise 12: Under what conditions could a mailbox's message queue contain messages waiting to
waiting for messages? Ignore the possibility that
this may happen momentarily during the implementation of either routine. If you think of any'

Exercise 13: PUM 86 does not have built-in functions to separate the high and low-order words of a
pointer variable. Does this seem to be a weakness
in the language? Bear in mind that the machine
representation for pointers varies depending on
which programming model is specified at compilation time. When the "small" model is selected, the
compilers take advantage of a 16-bit pointer
representation for faster and more compact code.

Example 10 shows a task which prints the messages
sent above. Upon receiving a message token,
CRT$OUT$TASK determines the message length from
the first two bytes, and sequentially prints each element
of the string through the PROTECTED$CRT$
OUTPUT routine explained earlier. When done, the
segment containing the message is deleted, returning its
RAM to the free-memory pool.

Console Command Interpreter
If a system has a console keyboard, it's probably used

to accept and interpret operator commands. For this
demonstration system, the lowest priority of all tasks is
a simple-minded routine which polls the USART until a
character has been received, and immediately echoes it
by calling-you guessed it !-PROTECTED
$CRT$OUTPUT. Thus, the keyboard is "alive"; jt
responds immediately to keystrokes, so the operator
can type whatever nonsense he desires while everything else is going on.

A few words are in order about the segment accessing
techniques demonstrated here. PUM-86 has a special
data type, called a "pointer," used to indirectly access
other PUM variables. OSP application programs must
be compiled with the "compact" or "large" model spe,cified. This tells the compiler to implement pointers as
32-bit double words corresponding to the two parts
(base:offset) of the 8086 machine-segmented addressing scheme. PUM-86 tries to shield the programmer

Ten of the keys (digits 0 through 9), invoke special
commands which illustrate interactions between the
2-65
AFN·02058A

AP-130

multiple tasks. Commands 0 and 1 print out the time
and status messages; the rest suspend and'resume
various tasks, as shown by Table 2. The code for
COMMAND$TASK appears in Example 11. COMMAND.TASK PROCEDURE, DECLARE CONSOLE.CHAR BYTE, DECLARE COMMANO.EXCEPT.CODE WORD. CALL RO$RESUMEHASK( INIT$TASKsTOKEN. @COMMAND$EXCEPT$CODE), DO FOREVER. CONSQLE$CHAR=CSIN AND 7FH,
CALL PRQTECTEDsCRTsOUT(CONSOLE$CHAR), IF CONSOLE$CHAR=CR
THEN CALL PROTECTEOsCRT$QUT(LFn -IF (CONSOLE$CHAR :>= 'O'l AND (CONSOLE$CHAR <.:= '9') THEN Do. Initialization Task CAll PROTECTED• .cRT$OUT (CR),
CALL PROTECTEOSCRT$OUT eLF), DO CASE (CONSOLE.CHAR-/O'), CALL PRINT$,TOD.

Now that the application tasks have been written, we
can write the initialization task.

CALL PRINT$StATUS. CALL RQSSUSPENO$TASK (CRTSQUT$TASKSTQKEN, @COMMANDsEXCEPTsCODE). CALL RQ$RESUME$TASK (CRnOUT$TASK*TOKEN,
@COMMAND$EXCEPT$CODE),
CALL RG$DISABLE (AC$INTERRUPT$LEVEL. @COMMAND$EXCEPUCODE),
CALL RG$ENABLE (AC$INTERRUPT$LEVEL, @COMMANO$EXCEPT$COOE), CALL RG$SUSPENO.TASK (MOTOR$TASK$TOKEN,
(iCOMMAND$EXCEPT$CODE) •
CALL RQ$RESUME$TASK (MOTOR$TASK.TOKEN, @COMMAND$E)(CEPT$CODE), CALL RQ$SUSPEND$TASK(STATUS4TASK$TDKEN,
@COMMAI'4D$E)(CEPT$CDDE),
CALL RG$RESUME$TASK (STATUS$TASK$TOKEN,
@COMMANO$E)(CEPT$CODE),
END,
1* OF CASE-LIST *1
1* OF COMMAND PROCESSING *1

All applications require a special type of task to initialize system variables and peripherals and create tasks
and other 'Objects used by the application. It, too, is
written as a PL/M procedure, and can thus be divided
conceptually into the same three phases.
Example 12 shows such a task for the demonstration
system. The first thing INIT$TASK does is determine the base address of the job data segment by assigning pointer DATA$SEG$PTR with its own address. Next it calls the RQ$GET$TASK$TOKENS routine, which
tells the task what token value the OSP assigned it at
run time. It then initializes the system peripherals by
creating the hardware initialization task discussed
above; this code could have been integrated into
INIT$TASK itself just as easily. During its own "execution" phase, INIT$TASK calls routines to
create the OSP data structures shared by the application tasks: the REGION controlling access to the
USART, and the MAILBOX repository for output messages. INIT$TASK creates the application tasks themselves by calling RQ$CREATE$TASK. END END, END, COMMAND$TASK,

Example 11. Task to Accept and Process Keyboard
Commands
INli$TASK PROCEDURE PUBLIC, DECLARE INITSEXC~PT$COOE WORD,
DATA$SEG$PTR=@INIT$TASKSTOKEN, I*LOAD DATA SEGMENT BASE*I CF!T$MAIL130X$TOKEN=RG$CREATE$MAtLBQX (0, @INlHiEXCEPT$COOE),
CRT$REGIDN$TOKEN=RG$CREATE$REGIONCO, @INIT$EXCEPT$CODE),
INIT$TASKHOKEN=RG$GET$TASK$TOKENS (0, @IN!T$EXCEPT$CODE),
HAROWARE$INIT$TASK$TOKEN=RG$CREATESTASK

~~ !~N~~:~~~~:~:~~~~~~ASK. DATf'~SEG$ADDR BASE, 0, 300, CALL RG$SUSPENO$TASK(Q,@INIT$EXCEPT$CODE), STATUS$TASKSTOKEN=RGSCREATE$TASKC 110, I!STATUSSTASK, DATA$9EGSADDR BASE, 0, 3QO, 0, @INIT$EXCEPT$COOE),
CALL RQ$9USPENO$TASK(0,@INITSEXCEPT$COOE), MOTOR$TASK$TOKEN=RGSCREATE$TASK( 110, @MQTOR$TAS~, DATA$SEG$ADDR BASE, 0, 300, O,@INITSEXCEPT$CODE),
CALL RG$SUSPEND*TASK(O,@INIT$EXCEPT$CDDE), T IME$TASK$TOKEN=RG$CREATE$TASK ( 120, @TIME$TASK,
OATA$SEG$ADDR BASE, 0, 300, 0, (!INIT$EXCEPT$COOE),
CALL RG$SUSPENDHASK(O. @:INIT$EXCEPT$CODE), CRT$OUT$TASY.$TOKEN=RG$CREATE$TASK ( 120, @CRTSDUT$TASK, DATA$SEG$ADOR BASE, 0, 300, O,@INIT$EXCEPT!IICODE),
CALL RG$SUSPEND$TASK(O,

$DEBUG COMPACT ROM TITLE( 'AP-130 APPENDIX B DEMO$l30.
1*

12/21/61' )

DO,

SYSTEM-WIDE LITERAL DECLARATIONS:

*1

DECLARE FOREVER LITERALLY 'WHILE 01H',
1*

1/0 PORT DEFINITIONS.

*1

:J

DECLARE CHAR$51 LITERALLY '4000H', CMD$51 LITERALLY '4002H',
STAT$51 LITERALLY '4002H'. 4 DECLARE PPI$A LI1ERA~LY '6001H'.
PPI$B LITERALLY '6003H'. PPI$C LITERALLY '6005H'.
PPI$CMD LITERALLY '6007H'. PPI$STAT LITERALLY '6007H'.

5

DeCLARE TIMER$CMD LITERALLY '200EH'. BAUD$TlMER LIl'ERALLY '200CH';

6

DECLARE AC$INTERRUPT$LEVEL LITERALLY '0011100013'.

7

DECLARE CR LITERALLY 'ODH'.
LF LITERALLY 'OAH',
BEL LITERALLY '07H'.

8

DECLARE ASCII$CODE (16) BYTE DATA ('0123456789ABCDEF');$I:JEC'!
$tNCLUDE (.Ft NUCLUS.EXT)$SAVE NOLI S T
$INCLUDE ( rl NEXCEP LIT)$o;dve nollst
1*
?,99

GLOBAL VARIABLE DECLARATIONS.

*1

DECLARE DATA$SEG$PTR POINTER.
DATA$SEG$ADDR STRUCTURE (OFFSET WORD. BASE WORD)
AT (@DATA$SEG$PTR).
DE.CLARE HARDWARE$INIT$TASK$TOKEN WORD. STATUS$TASK$TDKEN WORD. MOTOR$TASK$TOKEN WORD. TIME'$TASK$TOKEN WORD. AC$HANDLER$TOKEN WORD. CRT$OUT$TASK$TOKEN WORD.
COMMANDtTASK$TOKEN WORD. INIT$TASK$TLIKEN WORD. ]01 DECLARE CRT$MAILBOX$TOKEN WORD. CRT$REGION$TOKEN WORD; 2-77 • AFN·0205SA AP-130 SEJECT, 1* 'JO:"'2 '3(j':) 304 2 2 3()~' 3 306 2 2 3(Y' ~lO8 3(,1 1,.- .- 310 3 ~31 2 :2 ! -31. ;~ CODE EXAMPLE 2 SIMPLE CRT INPUT AND OUTPUT ROUTINES. *1 CSOUT: PROCEDURE (CHAR); DECLARE .CHAR BYTE; DO WHILE (INPUT(STATS51) AND 01H)=0; 1* NOTHING *1 END; OUTPUT(CHARS51)=CHAR; END CSOUT; C$IN:
PROCEDURE BYTE;
DO WH1LE (INPUT= 60
THEN DOl
AC$CYCLEsCOUNT=OI CALL RG$SIGNALsINTERRUPT(ACSINTERRUPT$LEVEL. @ACsEXCEPTsCODE)1 . END. ELSE CALL RGsEX ITsINTERRUPT (ACsINTERRUPT$LEVEL.
@ACSEXCEPTSCODE).
END AC$HANDLERI 2-79 AFN-02058A AP-130$EJECT
1*
380
381
38~

;;!
2

3[3:1
384

2

:385
J86

;:~

.~187

2

'388

;2

Z~

3

CODE EXAI1PLE 7.

PROTECTED CRT OUTPUT SUBROUTINE.

*1

PROTECTED$CRT$OUT.
PROCEDURE (CHAR) REENTRANT'.
DECLARE CHAR BYTE,
DECLARE CRT$EXCEPT$CODE WORD,
CALL RG$RECEIVE$CONTROL(CRT$REGION$TOKEN,@CRT$EXCEPT$CODE),
DO WHILE

489

.,,-

440
441

2

-,

~

~~

.,

442

c.

443

3

444

3

41.1 ~1

';:0]

44·S
447

2

3

448
449
450

3
3
2

431

2

SUBROUTINE TO CREATE TIME-OF-DAY MESSAGE.

*1

TOD$MESSAGE$TOKEN=RQ$CREATE$SEGMENT(28,@TOD$EXCEPT$CODE),
TOD$SEGMENT$BASE=TOD$MESSAGE$TOKEN,
TOD$SEGMENT$OFFSET=O,
DO TOD$STRING$INDEX=O TO 27,
TOD$STRING(TOD$STRING$INDEX)= TOD$TEMPLATE(TOD$STRING$INDEX),
END,
TOD$STRING(17)=ASCII$CODE(HOUR$COUNT/l0), TOD$STRING(18)=ASCII$CODE(HOUR$COUNT MOD 10),
TOD$STRING(20)=ASCII$CODE(MINUTE$COUNT/l0), TOD$STRING(21)=ASCII$CODE(MINUTE$COUNT MOD 10);
TOD$STRING(23)=ASCI I$CODE(SECOND$COUNT/l0) , TOD$STRING(24)=ASCII$CODE(SECOND$COUNT MOD 10),
CALL RQ$SEND$MESSAGE(CRT$MAILBOX$TOKEN,
TOD$MESSAGE$TOKEN,O,@TOD$EXCEPT$CODE),
RETURN,
END PRINT$TOD, 2 430 CODE EXAMPLE 8. PRINT$TOD.
PROCEDURE,
DECLARE TOD$MESSAGE$TOKEN WORD,
DECLARE TOD$EXCEPT$CODE WORD,.
DECLARE TOD$SEGMENT$OFFSET WORD,
TOD$SEGMENT$BASE WORD,
DECLARE TOD$SEGMENT$PNTR POINTER AT (eTOD$SEGMENT$OFFSET),
DECLARE TOD$TEMPLATE (28) BYTE DATA (27. 'THE TIME IS NOW hh: mm: 55. ',CR, LF), DECLARE TOD$STRING BASED TOD$SEGMENT$PNTR (28) BYTE,
DECLARE TOD$STRING$INDEX BYTE,

CODE EXAMPLE 9.

SUBROUTINE TO CREATE SWITCH STATUS MESSAGE.

*1

PRINT$STATUS: PROCEDURE, DECLARE STATUS$MESSAGE$TOKEN WORD, DECLARE STATUS$EXCEPT$CODE WORD, DECLARE STATUS$SEGMENT$OFFSET WORD, STATUS$SEGMENT$BASE WORD, DECLARE STATUS$SEGMENT$PNTR POINTER AT (@STATUS$SEGMENT$OFFSET), DECLARE STATUS$TEMPLATE (40) BYTE DATA
(39, 'THE SWITCHES ARE NdW SET TO
. . . . . B',CR,LF),
DECLARE STATUS$STRING BASED STATUS$SEGMENT$PNTR (40) BYTE, DECLARE STATUS$STRING$INDEX BYTE, DECLARE BIT$PATTERN BYTE,
STATUS$MESSAGE$TOKEN=RQ$CREATE$SEGMENT(40,
@STATUS$EXCEPT$CODE),
STATUS$SEGMENT$BASE=STATUS$MESSAGE$TOKEN,
STATUS$SEGMENT$OFFSET=O,
DO STATUS$STRING$INDEX=O TO 39,
STATUS$STRING(STATUS$STRING$INDEX)= STATUS$TEMPLATE(STATUS$STRING$INDEX)l
END,
Blf$PATTERN=INPUT(PPI$A),
DO STATUS$STRING$INDEX=29 TO 36,
STATUS$STRING(STATUS$STRING$INDEX)= ASCII$CODE(BIT$PATTERN AND 01H), BIT$PATTERN=ROR(BIT$PATTERN,1), END, CALL RQ$SEND$MESSAGE(CRT$MAILBOX$TOKEN, STATUS$MESSAGE$TOKEN,O,@STATUS$EXCEPT$CODE), END PRINT$STATUS,

2-81
AFN-02058A

AP·130

/·It
4~2

49:;
4 5l~

~

"-

'J

4~'\

~.~

4":>."

:;:

4

~j

7

4'>8

.1')9
~6(l

.,
<-

.'-'
;2

402

3

40,3
4c··:;,

j

46~J

3

466
467
'168
46'>'
470
47l

:1

El\A~IPLE-.

10.

TASK TO RECEIVE MESSAGES ANI? TRANSMIT THEM TO CRT.

*1

CRT$OUT$TASK. PROCEDURE,
DEC I_ARE' MESSAGE.LENGTH BYTE,
DECLARE MESSAGE$TOKEN· WORD, DECl.ARE RESPONSE$TOKEN WORD,'
DECLARE MESSAGE$EXCEPT$CODE WO~D;'
DECLARE MESSAGE$SEGMENT$OFFSET WORD,
MESSAGE$SEGMENT$BASE 'WORD;
.
DECLARE. MESSAGE$SEGMENT$PNTR POINTE'R AT ('DELETE$SEGMENT (MESSAGE$TOKEN, @MESSAGE$EXCEPT$CODE),
END,
(~OF FOREVER-LOOP
*1
END CRT$OUT!I>TASK, i~ 4 :3 ':1 ;1$EJI£CT
1*
472
473

2

47'l

~

41'0
470
471
478

.~

2
3
3

419

.l

4d1

3

48:1
484

4

4~3~1

4

48"
487

~

4

.,

4SH

:;

489

:;

490

"

491

:;

4qt.!

:;

493

5

494

:;

49~

:;

496
497
498

:;
4
3
2

499

CODE EXAMPLE 11.

TASK TO POLL KEYBOARD AND PROCESS COMMANDS.

*1

COMMAND$TASK. PROCEDURE, DECLARE CONSOLE$CHAR BYTE,
DECLARE COMMAND$EXCEPT$CODE WORD,
CALL RG$RESUME$'TASK ( INIT$TASK!I>TOKEN, @COMMAND$EXCEPTSCODE);
DO FOREVER,
CONSOLE!I>CHAR=C$IN AND 7FH, CAI_L PROTECTED$CRT$OUT (CONSOLE$CHAR),
IF CONSOLE$CHAR=CR THEN CALL PRO.TECTED$CRT$OUT(LF»)· IF (CONSOLE$CHAR:>= '0')· AND (CONSOLE$CI:IAR (= '9') THEN DO, CALL PROTECTED$CRT$OUT(CR), CALL .. PROTECTED$CRT$OUT(LF); DO CASE (CONSOLE$CHAR-' 0' ),.
CALL PR INT1IiTOD,
CALL PRINT$STATUS, CALL RG$SUSPEND$TASK(CRT$OUT$TASK$TOKEN,
@COMMAND$EXCEPT$CODE),
CALL RG$RESUME$TASK(CRT$OUT$TASK$TOKEN, @COMMAND$EXCEPT$CODE), CALL RG$DISABLE(AC$INTERRUPT$LEVEL,
@COMMAND$EXCEPT$CODE),
CALL RG$ENABLE(AC$INTERRVPT$LEVEL,. @COMMAND$EXCEPT$CODE), CALL RG$SUSPEND$TASK(MOTOR$TASK$TOKEN, @COMMAND$EXCEPT$CODE), CALL RG$RESVME$TASK(MOTOR$TASK$TOKEN, @COMMAND$EXCEPT$CODE); CALL RG$SUSPEND$TASK(STATUS$TASK$TOKEN, @COMMAND$EXCEPT$CODE); CALL RO$RESUME$TASK(STATUS$TASK$TOKEN, @COMMAND$EXCEPT$CODE), END, 1* OF CASE-LIST *1 END, 1* OF COMMAND PROCESSING *1 END, END COMMAND$TASK,

2-82

AFN.()2Q58A

AP·130

$EJECT 1* 500 501 50;2 503 504 ')05 506 srj / 5('<4 2 2 2 2 -, ~ 2 2 510 2 511 2 2 51 ~:> 513 :>14 51t:> 51t. 2 2 2 2 517 518 519 2 2 520 2 521 TASK TO INITIALIZE OSP SOFTWARE. *1 DATA$SEG$PTR=@INIT$TASK$TOKEN; I*LOAD DATA SEGMENT BASE*I CRT$MAILBOX$TOKEN=RG$CREATE$MAILBOX(O.@INIT$EXCEPT$CODE); CRT$REGION$TOKEN=RG$CREATE$REGION(O.@INIT$EXCEPT$CODE); INIT$TASK$TOKEN=RG$GET$TASK$TOKENS(O.@INIT$EXCEPT$CODE);
HARDWARE$INIT$TASK$TOKEN=RG$CREATE$TASK (110.@HARDWARE$INIT$TASK.DATA$SEGSADDR.BASE.0.300.
O.@INIT$EXCEPT$CODE);
CALL RG$SUSPEND$TASK(O.@INIT$EXCEPT$CODE);
STATUS$TASK$TOKEN=RG$CREATE$TASK(110.@STATUS$TASK. DATA$SEG$ADDR. BASE.0.300.0.@INITSEXCEPTSCODE); CALL RG$SUSPEND$TASK(O.@INIT$EXCEPT$CODE); MOTOR$TASK$TOKEN=RG$CREATESTASK(110.@MOTOR$TASK. DATA$SEG$ADDR. BASE.0.300.0.@INIT$EXCEPTSCODE);
CALL RG$SUSPEND$TASK(O.@INIT$EXCEPTSCODE); TIME$TASK$TPKEN=RG$CREATESTASK(120.@TIME$TASK. DATA$SEG$ADDR BASE.0.300.0.@INIT$EXCEPT$CODE); CALL RG$SUSPEND$TASK(O.@INIT$EXCEPT$CODE); CRT$OUT$TASK$TDKEN=RG$CREATE$TASK(120.@CRT$OUT$TASK.
DATA$SEG$ADDR. BASE.O.300.0.@INIT$EXCEPT$CODE);
CALL RG$SUSPEND$TASK(O.@INIT$EXCEPT$CODE);
COMMAND$TASK$TDKEN=RG$CREATE$TASK(130.@COMMAND$TASK. DATA$SEG$ADDR BASE.0.300.0.@INIT$EXCEPT$CODE); CALL RG$SUSPEND$TASK(O.@INIT$EXCEPT$CODE); CALL RG$END$INIT$TASK;
CALL RG$DELETE$TASK(O.@INIT$EXCEPT$CODE);
END INIT$TASK; 2 2 S09 CODE EXAMPLE 12. INIT$TASK: PROCEDURE PUBLIC;
DECLARE INIT$EXCEPT$CODE WORD;

">

END

DEMO$130, MODULE INFORMATION CODE AREA SIZE CONSTANT AREA SIZE VARIABLE AREA SIZE MAXIMUM STACK SIZE 848 LI NES READ o PROGRAM ERROR(S) 084CH OOOOH 0052H 0026H 2124D OD 82D 38D END OF PL/M-86 COMPILATION 2-83 AFN-02058A AP·130 APPENDIXC SYSTEM MEMORY MAP 2-84 AFN·02058A AP-130 EXAMPLE SYSTEM MEMORY MAP [--MEMORY MODULE ROOT JOB CODE AREA EPROM (2x2784) RAM APPUCATlDN JOB CDDE AREA STARTING ADDRESS OFFFF:O OFD18:O ENDING ADDRESS OFFFF:F OFD38:O OFC82:O OFD17:B OSP SUPPORT CODE AREA OFCOO:O OFC81:F 80130 MEMORY SPACE OF800:O OFaFF:F FREE SYSTEM RAM DOCO:D O1FF:F ROOT JOB DATA AREA DOAD:O DOBF:F APPUCATION JOB DATA AREA 0DA7:O DDAC:' OSP SUPPORT DATA AREA 0040:0 DOA8:F 11088 INTERRUPT VECTOR 0000:0 D03F:F INmAUZATlON TASK STARTING ADDRESS: FC82:G8B5 ROOT JOB STARTING ADDRESS: _ _..!.FD1=8"':001=''--_ _ 2-85 AFN-02058A , Ap·130 APPENDIX D SUPPORT ,CODE LOCATE MAP 2-86 AP-130 ISIS-[ I MLS-86 L.OCATER, VI 2 INVOKED OY FO LOCBb Fl SUP130 LNK TO Fl SUP130 MAP PRINTC FI SUP130 MP2) 9C(3) It SEGSIZECSTACKCO) ) & ADDRESSES (CLASSES (CODE (OF8000H) • OAT A (00400H) ) ) • ORDER (CLASSESC DATA. STACK» OB~ECTCONTROLS (NOL INES, NOCOHMENTS, NOSVHBOLS) WARNING 26 DECREASING SIZE OF SEGMENT SEGMENT STACK • . SYMBOL TABLE OF MODULE HtNIMAL_80130 READ FROM FILE . Fl SUP130 LNK WRITTEN TO FILE Fl SUP130 BASE OFFSET TYPE SYMBOL 0040H Q040H OOOOH Ol4BH BASE OFFSET TYPE SYMBOL BASE OFFSET TYPE SV"BOL PUB PUB INTERRUPTTASKVEC INTERRORENTRV 0040H 0040H 0120H 014CH PUB PUB OO4OH 0040H 0144H Ol5OH EXTENSIONLISTROO -T 0040H 01S4H PUB OO40H Ol51oH 0040H 0040H 015AH 0160H PUB PUB 0040H 0040H OISCH PUB OI62H ' PUB LAST...NDP _TASK REOIONjLAOS 0040H OIb6H PUB 0040H Ol71oH PUB SIONAL_O_INllEX 0040H OIEBH PUB 0040H OlE9H PUB 0040H 0040H 0040H 0040H OO4OH FBOOH OlEBH PUB PUB PUB PUB PUB PUB 0040H 0040H 0040H 0040H 0040H FBOOH OIECH OIFFH 022CH 024BH 05DOH 4542H PUB PUB PUB PUB PUB PUB FSOOH FBOOH FBOOH FBOOH FSOOH 453DH 452EH 451FH 4510H 4501H PUB PUB PUB PUB PUB FBOOH 44F2H 44E3H 43AEH BCAN'EIIDRV KSUSPEND KENABLELEVEL KCREATEDB.JECT FINIBHINITIALIZA -THIN PUB DECDDEJ.EVEL PUB ARRAVIDUNDII PUB INITIALIZE_PICS FBOOH 433FH PUB FBOOH 40BOH ~UB 40A1H 0040H 0152H PUB OO4OH 0040H Ol5BH 015EH PUB PUB 0040H 0164H PUB 0040H 017BH NOP _INTERRUPT J.E -VEL_VAR TAa..._WAITINQ_FLA -98 PUB SIQNAL_O OO4OH 0040H 0040H 0040H 0040H FBOOH OlEAH OIEDH 020BH 023EH 0249H 45CCH PUB PUB PUB PUB PUB PUB FSOOH FBOOH FBOOH FBOOH FBOOH 4556H 453BH 4529H 451AH 450BH PUB pUB PUB PUB PUB F800H FBOOH FBOOH 44FCH 44EDH 44DOH PUB PUB PUB FBOOH 435CH FBOOH ROOT.JOBTOKEN FtL.LCHAR INTt'lASK IHR_PORT PIC_INFO CLOCK_DFF NOP _INTERRUPT J.E OIFIoH 021AH 0247H 024AM 45C2H -VEL OETDESCRPOINTER OVERFLOW KINITIALIZE KCREATEftEQIONNS INITNDP ~:567H DEFAULTJiANDLER 8YSTEMEXCEPTIONH -ANDLERPTR DELETION-PB~ECT _ -BASE HINTRANSSUE PARAH_VALIDATION -_VECTOR REGION_TIlKEN_TAB -I.E KERNELJI.A9 NU',-SLAVES DISABLEHASK EOIJ'DRT CLOCK_SPEC...E0I CLOCK_LEVEL VAL I DATE_PARAttS_ -BODVJlUI1K'I' PUB OETPDINTER PUB NENTRY _BODY PUB KENABLELEVELNS PUB KCREATEOB~CTNS INITIALIZE _ PUB F800H F800H FBOOH FBOOH 4533H 4S24H FBOOH 45010H FBOOH FBOOH F8COH 44F7H 44EBH PUB PUB .UB DIVIDEBVZERO CLOCKENTRVJlODV 4472H NOP _INTERRUPT_HA -NDLER INITIALIZENUCLEU 451~ FBOOH 434EH PUB 4336H EDI_ROUTINE CDHHDN...ERROR SYBTEHEXCEPTIONH -ANDLER PUB INIT_INTERNAL._RE -OICINS PUB NENTRV FBOOH 40FEH PUB FBOOH 4OB1H PUB RGSI9NALtNTERRUP -TJlODV FBOOH 40ACH PUB RGQETLEVELJlODV FBOOH FBOOH 4OA2H PUB RGENTER INTERRUPT FBOOH 409DH PUB RClDISABLE_BODY FBOOH FaoOH 40BAH PUB FaOOH INITIALIZE_TIrER FBOOH FBOOH PUB PUB READVLISTROOT DELET IDNTASIITDKE -N PUB SVSTEHPDDLTOKEN' ACTIYATE_SID*L_ -G DLDJlL,AVE.-NUII LEYELJlET_T.....LE I8RJ'ORT CLOCKJlN END_DF-.DATA OETDESCRTDKEN CLQCKENTRV 4094H RGWAITINTERRUPT _ -BODV PUB R(I£XITINTERRUPT_ -BODV PUB RGWAITINTERRUPT FaOOH 4OBOH PUB RQQETt.EVEL FBOOH 40710H PUB 40bCH -_BODV RGSIGNALINTERRUP -T PUB RGEXITINTERRUPT F800H 40b2H PUB RGDISABLE FBOOH 405DH PUB FBOOH 4058H PUB FBOOH 40S3H PUB NUNLOCK FSOOH 404EH PUB -5 R(I£NTER INTERRUPT FBOOH 4049H PUB NOPENNS FBOOH 4044H PUB NOPEN FBOOH 403FH NUNLOCK_DELETION -_OBJECT NOPEN_DELETtDN_O -B.JECT PUB NLDCK_DELETION_O FBOOH 403AH PUB NLOCKNS FeOOH 4035H PUB NLOCK FBOOH 4030H PUB FBOOH 402BH PUB NCLOS£NS FeOOH 4026H PUB NCLOSE F800H 402lH NCLOSE_DELETtON_ -OBJECT PUB DELETERUNNINGlTAa FBOOH 401CH PUB DELETEOB.JEC T F800H 400AM PUB COPVRIGHT FBOt»< 4000H PUB FSOOH 4000H PUB FC5DH OQ04H PUB II"lR_START FC5CH eooEH pua FC5CH FC'5CH OOOFH 0Ol2H INIT_NUCLEUS_.JUM -P PUB INIT_CHDI PUB INIT _CMD4_MASTER FC5CH FC61H 0010H OOOEH PUB PUB INtT_CHD5_HASTER SLAVE_TABLE FC9CH FC61H 001lH 0OO3H PUB PUB FC61H FC61H FBOOH QOO5H OCOBH 4576H PUB PUB PUB FC61H FCblH FBOOH OQ07H OOOCH 4574H PUS PUB PUB CL.OCK_COUNT C_CLOCK_ON PARAM_VALIDATION -_PATH FC61H FC61H OOOAH 0009H PUB PUB NUNLOCKNS -B~ECT --I< CLOCK_O_PORT C_CLOCK_SPEC_EOI LEVEL7 _HANDLER MEMORY MAP OF MODULE MINIMAL_80130 READ FROM FILE FI- SUPI30 LNK WRITTEN TO FILE FI SUPl30 SEGMENT MAP START OOOOOH 00400H 009FOH OOAOOH OOAIOH OOA20H OOA30H OOA40H OOA50H STOP 003FFH 009EFH 009FFH OOAOFH OOAIFH OOA2FH OOA3FH OOA4FH OOA9FH LENQTH ALIQN NAME 0400H 05FOH OOlCH 00lOH OOlOH OOIOH OOIOH OOIOH OOIOH A W Q Q (ABSOLUTE) DATA INTVEC_REQ_SEQ EXT _REG_SEQ Q ~OB_REG_SEQ G Q G G SEM_REQ_SEQ HAIL.JIE"_SEQ OD_REQ_SEQ PDOL.JIE"_SEG CLASS DATA DATA DATA DATA DATA DATA DATA DATA 2-87 NBEQIN AP-130 OOA60H OOA7QH OOA70H FeOOOH FC'5CEH FC5D4H rC5E6H FC5F8H FC60AH FC613H FC61EH Ir-C61EH FC'620H OOA6FH COA70H QOA70H FC5CDH FC5D2H FC5E5H FC5F7H FC609H FC612H FC61CH FC61EH FC61FH FC620H DELETION...REQ_S -EG OOlOH COOOH W COOOH G 45CEH W W W W W 0OO5H 0012H OO12H 0012H 0OO9H OCOAH COOOH 0OO2H COOOH B B W W W DATA STACK "'?SEG STACK CODE CODE CODE P IC_CNF _SEQ _IMRJORT _EOI_PORT _ISR_READJORT JIC_INFO TIMER_CNF _SEG CSEG SLAVE_SEG MEMORY LAST RAM BYTE USED CODE CODE CODE CODE CODE CODE CODEt-- LAST EPROM BYTE USED MEMORY GROUP MAP ADDR ESS OQ400H GROUP OR SEGMENT NAME DGROUP DATA I NTVEC _REG _SEG EXT _REG_SEG .JOB_REO_SEG SEM...REO_SEQ ~~~;~~:E~EG, POOL_REO_SEQ DELE T ION_REG_SEQ FeOOOH CGROUP CODE PIC":'CNF _SEG _IMRJORT J;OIJORT _ISR...READJORT JIC_INF'O TIMER_CNF _SEG CSEG 2-88 AFN-02058A AP·130 APPENDIX E APPLICATION JOB LOCAtE MAP 2-89 AFtHl2058A AJ)-130 AP-130 OOA7H 002EH gYM OOA7H 002EH SYM STATUSSEGMENTOFF OOA7H OQ30H gYM FC62H 0059H SYM OOA7H 004EH gYM FC62H OOA7H OOA7H Q52FH 0032H 0036H gYM SYM gYM -SET OOA7H 002EH STATUSSEGMENTPNT -R BAS STATUSSTRING DOA7H OOA7H OOA7H D04FH 0050H 0034H SYM SYM SYM STATUSSEGMENTBAS -E STATUSTEMPLATE STATUSSTRINGINDE -x J'3ITPATTERN MESSAGELENGTH RESPONSETOKEN DDA 7H 0038H SYM 003AH 0038H SYM OOA7H 0038H FC62H 05AFH MESSAGESEGMENTOF -FSET MESSAGESEGMENTPN -TR SYM COMMANDTASK OOA7H OOA7H I CRTOUTTASK MESSAGETQKEN MESSAGEEXCEPTCQD -E SYM MESSAGESEGMENTBA -SE BAS MESSAGESTR INGCHA OOA7H 0051H SYM 00A7H 003CH SYM DOA 7H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FCb2H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H 003EH 0087H 0096H OOA1H OOBOH OOB9H OOOCH OOC8H OOD1H OOEFH 010CH 011FH 0139H 013EH OISOH 01SCH 016DH Ol72H 017AH 0184H 0196H 01A5H 01BDH 01D6H OlF5H 020FH 0228H 023BH 0259H 0270H 027DH 028DH 029CH 02ACH 02BBH 02CAH 02D2H 02F3H 030FH 032DH 034EH 035DH 036FH 0389H 038EH 03A7H 03BEH 03D9H 040EH 0440H 0472H 0489H 048CH 04A5H 04BCH 04D7H 04EEH 050FH 052DH 0532H 053FH 0560H 0573H 0592H OSAAH 05AFH OSBFH 05C9H 05DAH OSF4H ObOOH 0616H 062CH 064CH 066CH 06BCH 06EOH 06BSH SYM LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LI N LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LI N LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN t.:.IN COMMANDEXCEPTCOD -E INITEXCEPTCODE 304 306 308 310 312 319 321 323 325 327 329 331 335 337 339 341 344 349 351 353 355 357 359 361 363 365 367 371 373 376 378 380 384 386 388 392 394 396 398 400 402 404 406 415 417 419 421 423 425 427 429 439 441 443 445 447 449 451 460 462 464 466 468 470 472 476 478 480 483 485 487 489 491 493 495 498 1500 --R IFC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC-62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC6:2H F C62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H FC62H 06B5H \ SYM 0084H 0093H 009DH OOA4H OOB3H OOB9H OOC2H OOCEH OOE4H OOF8H 0116H 012CH Ol3BH 0143H OlSOH 0160H 0170H 0175H 017FH 0189H 0196H OlBOH OlCDH 01E6H 0202H 021FH 023BH 0256H 0266H 0278H 02BAH 029AH 02AOH 02BBH 02C2H 02CFH 02D7H 0300H 031EH 033AH 0354H 0366H 037CH 038BH 039FH 03ADH 03DOH 03FSH 0427H 0459H 0487H 0489H 049DH 04ABH 04CEH 04DFH 050BH 0518H 052FH OS3FH OSSAH 0568H 0588H 059DH 05ADH 05B2H 05BFH 05DOH 05EOH 05FAH 0610H 06lCH 063CH 065CH 067CH 069CH 06B3H 06aSH CONSOLECHAR INITTASK'~ INITIALIZATION TASK STARTING ADDRESS LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN UN LI N LIN LIN LIN LIN LIN LII>.I LIN LI N LW LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LI N LIN LIN LIN LIN LIN LI N LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN lIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN' LIN 302 305 307 309 311 31:) 320 322 324 326 328 330 332 336 338 340 342 348 350 352 354 356 358 ::160 362 364 366 369 372 375 377 379 383 385 387 ;]90 393 395 397 399 401 403 405 407 416 418 420 422 424 426 428 430 440 442 444 446 448 450 452 461 463 465 467 46'11 47\ 470 477 479 48\ 4B4 486 488 490 492 494 496 499 S02 2-91 AFN-02058A AP-130 FC6;H FC6;H FC6;H FC6;H FC6;H FC6;H FC6;H FCMZH FC62H FC6;H 06C4H 06E6H 071FH 075l1H O'78llH 07CIH 07F7H OBiWH OB3DH OOB4H LIN LIN LIN LIN LIN LIN LIN LIN LIN LIN FC6;H FC62H FC6;H FC62H FC62H FC6;H FC6;H FC6;H FC6l!H 503 505 507 509 511 513 515 517 51" 06DlIH 06F6H onCH 076;H 07ftH 07CEH 0II04H OB3AH 084AH LIN LIN LIN LIN LIN LIN LIN LIN LIN 504 506 'OB '10 511! ,514 5 ... 51411 520 !liI!1 'I'II!MORY MAP OF MODULE DEI't0130 READ "'ROM FILE Fl. API30. LNM WRITT~N TO FILE . F1. API30 S~Ql'tENt I1AP STOP START LENIITH ALIQN NAI'II! CLASS r..-_ __ ..;..._ _..;... _ _W_ _ _ _ _ _ _DA_TA....It..-- LA8l'DATA BYtE OFAPPLICATIONJ08 OOACIH 0052H DATA 100A70H ODAC2H ODADOH 00AC2H OOADOH OOOOH OOOOH W STAC~ Q ~?SEO stACM FD17BH Io.;..;;.;;.;;.;..;.......;.;;;.;;..;..;;.;.;.._-.;;.;..;......;........;.;.....;.;;.;;.;;;.... FCb20H oaSCH w CODE _ _ _ _C"'O;;;;OE.....\4--- LASl"CODE BYTE OFAPPUCATION JOB FD17CH FD17CH OOOOH W I1EI1ORY I'II!I1ORY OROUP MAP ADDRESS FC620H OOA7OH QROUP OR BE_NT HAl'll! CQROUP CODE OQROUP DATA 2-92 AP-130 APPENDIX F ROOT JOB LOCATE MAP 2-93 AFN·02058A AP-130 ISIS-II MCS-B6 LOCATER. VI. 2 INVOKED BY. It: TO : Fl RJB130 It L.OC86 .'1 R.JB130 Ink MAP PRINTt. fl. R.JB130 mp2) Bt OC(noli. nopl. noem. nasb) It PC (noli. pl. noem. noab) Bt SEQSIZE< stack (0» Bt ORDER(clils ••• (dat •• stack. m.moT'Y» AODRESSES(c las'us (cod~(OFDlBOH), data?SEG CODE SAB"pESCR IPTOR -S W _~_J_DESCRIPTOR W MEMORY CLASS DATA STACK I---- LAST DATA BYTE OF ROOT JOB STACK CODE CODE CODEr----LASTCODEBYTEOFROOToIOB MEMORY GROUP MAP ADDRESS OOADaH FD1SOH GROUP OR SEOMENT NAME DQROUP DATA COROUP CODE SAB "pESCR IPTORS U_,",_DESCRIPTORS 2-94 AFN-02058A inter APPLICATION NOTE Jan uary 1984 Optimizing the iRMXTM 86 Operating System Performance on System 86/31 0 and System 86/330 CATHERINE LUNDBERG ISO APPLICATIONS MARKETING , -INTEL CORPORATION, 1984 2-95 Order Number: 230990-001 Optimizing the iRMX™ 86 Operating System Performance on System 86/310 and System 86/330 CONTENTS INTRODUCTION .•••.•••.••••••.•• OVERVIEW OF THE iRMX™ 86 OPERATING SYSTEM .......... .. PERFORMANCE TUNING .•.•..•.•• The Size Of The Loader Buffers The Volume Granularity Of Devices The Number Of BIOS Buffers The Interleave Factor Of Devices PERFORMANCE TESTS .......•.•.. RSAT Maximum Transfer Rate iRMXTM 86 Operating System Generation iRMXTM 86 BIOS Generation COPY Test DIRTest Boot Disk Generation Boot Test BAcKU~ And RESTORE Test EVALUATION SEQUENCE .•.••.•.. SYSTEM 86/330A PERFORMANCE RESULTS .•..••.••••••••••.••... SYSTEM 86/310 PERFORMANCE RESULTS ••.••••••.••••..•.•..•. CONCLUSION ., ••.•••.•.•••..•.•.. APPENDIX A: 'SYSTEM CONFIGURATIONS .•••••.•.••••. APPENDIX B: DEFINITION FILE FOR AN OPTIMUM iRMXTM 86 OPERATING SySTEM .•... : ..••..•.•......... 2-96 230990.001 AP·174 INTRODUCTION . The Intel iRMXTM 86 Operating System is one of the most widely used real-time' operating systems. Because it is intended for real-time applications it must respond immediately to the event that has the highest priority. Most users of the iRMX 86 Operating System are application program oriented and their programs use the realtime capabilities fully. The Release 5 version of the iRMX 86 Operating System has the capability of supporting program development. This means that a system can be used for application code development, and later as the target system. Development costs can be decreased within a company, since there is no need to have separate systems for program development and for target systems. In addition, programs do not have to be downloaded from the development system to the target system. Since there are many possible software configurations for mixes of real time applications and program development work, the purpose of this application note is to identify system configuration options which will improve the overall performance of the iRMX 86 Operating.system from the Human Interface level, which is the level that the user sees while doing development work. The results of this application note could also be applicable to the user who is optimizing a target system configuration, since most of the parameters discussed in this study would affect the performance of the target system. Although the Release 5.0 operating system is faster and more optimized than previous versions of the iRMX 86 Operating System, further optimization has been found possible, especially when a specific hardware configuration is known. OVERVIEW OF THE iRMX™ 86 OPERATING SYSTEM The iRMX 86 Operating System is composed of layers. The layers in the iRMX 86 Release 5.0 Operating System are the Nucleus, the Basic 110 System, the Extended 110 System, the Application Loader, the Human Interface, and the Universal Development Interface (See Figure 1.) A layer provides a specific subset of operating system function. For instance, the Nucleus provides management of iRMX 86 objects such as tasks and jobs, the BIOS provides device independent 110 services, and the UDI provides the interface software to allow applications to be operating system independent. Different layers are added according to the requirements of the application. Lower layers may be used without upper layers, but upper layers must have the lower layers' as their groundwork. Using fewer layers of the operating system usually means that the application can execute faster. The UDI layer is required to run the utilities (such as PLiM 86, ASM86, and LINK86) since all the languages products are based on the UDI. The code produced by running these utilities may not need all the layers. Most layers of the iRMX 86 Operating System have user configurable parameters. The values given to these parameters can be changed to allow the operating system to perform efficiently. Some parameters should be left at their default values, or the operating system will not function properly. For other parameters, the optimum value depends on the application, and the hardware configuration being used. The System 86/310 and System 86/330A have different requirements because of their hardware implementations. The major difference is their Winchesters and flexible disks. Parameters that affect disk performance have the most effect on the systems. This application brief deals with those parameters which can be changed to provide optimal values for disk performance. PERFORMANCE TUNING A number of parameters can affect the system performance. The parameters which are configurable in the iRMX 86 Operating System don't change the actual speed at which the processor works. The variables that can improve performance' affect how fast information can be given to the processor, or how much time must be spent to maintain system integrity. There are two ways to change the values of these parameters. One way is to reconfigure the operating system using the ICU. The ICU is an interactive configuration utility which uses a screen oriented list of parameters to allow changes in an operating system. While using the ICU, different values are given to particular parameters to change the system performance. The ICU also allows the 230990-001 AP -174 Figure 1 Model of the iRMXTMS6 Operating System addition or deletion of individual layers of the operating system. The ICU creates a submit file from the information contafned in the definition file. When this file is submitted, it generates a new operating system which uses the new values that were given to the parameters. The second way parameters can be changed to affect system performance is to format the random access devices differently. Changing the interleave factor while using the FORMAT cusp makes a great difference in ' the disk I/O performance. The Size of the Loader Buffers The iRMX 86 Application Loader has two configurable buffer sizes. The Loader internal buffer is the Loader's working buffer for converting Object Module Formats (OMFs) to executable code. The default value for the Loader internal buffer is' 400H, or lK. Increasing this will not improve petformance, but is sometimes necessary. OMFs are usually smaller than lK, but the Fortran 86 compiler can sometimes generate records that are longer than lK. Trying to load these records will cause an "E$RECJ,ENGTH" error, which can be
eliminated by increasing the Loader internal buffer size. This parameter is found in the ICU screen titled
"Application Loader". The variable is called "Internal Buffer Size (IBS)".
The Loader read buffer is used as a caching buffer when reading data from secondary storage. The Loader read
buffer size influences the system performance. The Loader read buffer size is found in the ICU screen labeled
"Application Loader". The parameter is labeled "Read Buffer Size (RBS)". The default value of the Loader
read buffer size is 400H, or lK. IncreasiI\g the Loader read buffer size will improve system performance.
2-98

230990-001

AP-174

The Volume Granularity of Devices
File fragmentation happens when a file is written into a space that is not large enough to hold the whole file.
Portions of the file must then be stored somewhere else on the disk to finish writing the file. This means that
the disk controller must seek to several places on the disk to read the whole file, or to write the file, and the
speed of disk I/O will be decreased. There are three different characteristics the user can vary to control file
fragmentation on a device: device granularity, volume granularity, and file granularity. Device granularity is
both the minimum allocation size, the minimum transfer size and is usually the sector size of a device. Volume
granularity is the minimum file allocation size for all files on the device. The volume granularity is a multiple of
the device granularity. Finally, file granularity is the minimum allocation size for a particular file and is a multiple of the volume granularity. By increasing the volume granularity and file granularity the files on a device
should be forced to be contiguous. If the Winchester is fragmented, the smallest contiguous chunk of data for
anyone file will be the volume granularity.
Volume granularity on Winchester drives does not appear to affect system performance, so that parameter can
be left at its default value of 400H, or lK. This parameter is found in the screen titled "Intel iSBCI> 215/iSBX
218 Device-Unit Information". The field is labeled "Granularity".
The diskette media which is used most frequently on the System 86/330A is a double sided double density disk
with a device granularity of256 bytes (100H). The physical name of the first such device is "wfddO" in the standard defmition file. With a device granularity of 256 bytes, a volume granularity of 256 bytes is the most
effective. Using a device with a device granularity of 1024 bytes will improve the performance of the diskette.
The physical name ofthe first double sided double density diskette with 1 K byte device granularity is "wfdxO".
The device tested for this application note was "wfddO" the diskette with device granularity of 256 bytes. The
diskette device used in the System 86/310 has the physical name of "wmfdxO". It is a double sided, double
density diskette with a device granularity of 512 bytes.

The Number of BIOS Buffers
The BIOS buffers are internal caching buffers which are used to hold data which is written to or read from
secondary storage. The BIOS will only transfer the number of bytes that are a multiple of the device
granularity. The device granularity is 1024 for the Winchester, and it varies for flexible disks. The most commonly used values are 512 for the System 86/310's diskette, and 256 for the System 86/330A's standard
.
diskette.
Increasing the number of buffers for each device usually has a positive effect on disk performance, but only. up
to a certain point. Buffers'must be updated, or flushed to the device, after a certain amount of time to ensure a
reliable system. There are two parameters that control flushing buffers. They are called "Update Timeout:' and
"Fixed Update" or "Common Update Timeout". Update timeout is a variable for each device. A value of64H
(100) for update timeout means that when a device has not been accessed for 1 second, the buffers associated
with that device will be written to the device. If the device is in constant use, this timeout limit may never be
reached, especially if the value given to update timeout is large. For this reason, there is a second update
parameter which can also be used.
The second parameter is called "Common Update Timeout" in the BIOS screen, and "Fixed Update" in the individual device screens. Common update timeout has one value for all devices in the operating system, but it is
specified on an individual unit basis if it will be invoked. A value of 3E8H (1000) for common update timeout
means that buffers associated with devices where common update timeout was invoked will be flushed at the
end of 10 seconds. The buffers will be flushed if they have'been used since the last time the system wide
common update timeout happened. This ensures that even buffers for devices which have been continuously
in use will be written to their device.
Increasing the amount of time between updating system buffers would improve performance, but it degrades
reliability. If a system failure occurs, for instance, a' power failure, the disks would have incorrect data on them
. if the buffers hadn't been written to disk. Using update timeout and eommon update timeout values that are appropriate reduces the damage caused by a system failure.
Different values of update timeout and common update timeout were not tested for the systems. These
parameters were left at their default values for each device.
2-99

230990-001

AP-174

The time necessary to update the buffers causes a decrease in performance if there are,too many,buffers. Buffers also use memory when the device is connected. Careful usage of memory is necessary especially when the
amount of memory available is limited, as is frequently the case for the target system,
Since diskettes are usually used only to transfer files between systems or for backups, the performance of the
flexible disks is not as important as the performance of the Winchester device. Since increasing the number of
buffers for a device increases the amount of memory required to attach the device, adding buffers for diskettes
does not usually outweigh the need to conserve memory.
The BIOS number of buffers parameter is found in the ICU screen titled "Intel iSBC 215/iSBX 218 Device
Unit Information". Each device has its own Device Unit Infoqnation screen. The field is labeled "Number cif
Buffers". The default number of buffers for Winchester devices is 4. The default number of buffers for flexible
disk devices is usually 2.

The Interleave Factor of Devices
One of the parameters of the FORMAT command is "Interleave". If the consecutively-accessed sectors of a
disk are staggered (that is, if they are not consecutive physical sectors), disk access time can decrease
considerably. The reason for this decrease is that although a controller cannot read a sector and issue another
read command in the time it takes for the next sector to be positioned under the head, the controller can perform this operation in less time than it takes for the disk to revolve once. Therefore, if the consecutivelyaccessed sectors are staggered correctly, the next accessed sector will be positioned under the read head just as
the controller becomes ready to read it.
The amount of staggering is called the interleave factor. An interleave factor of two means that as the disk,
rotates, the controller consecutively accesses every second sector. Note that a prQperly set interleave factor also
implies the number of disk rotations necessary to access all the sectors on a given track. An interleave factor of
two implies that it takes two rotations of the disk to access all the sectors on a track.
The interleave factor is important when large transfers of consecutive data take place at speeds that approach
the maximum transfer rate of the disk. Most information put on a disk will be stored in sectors that are consecutively accessed, if that is possible. If a disk has been heavily used so that few logically adjoining blocks are
available, then the information will be stored in nonconsecutively accessed blocks, wherever there is space
available. Naturally, this will slow down data transfer speed, since seeks must be done frequently to find where,
the next block of data is located. System performance will be best if the most frequently used utilities, programs
and data are written onto the disk first, after formatting the disk with the optimum interleave factor.
There are three distinct cases where large amounts of data are transferred.
1)

When the operating system is bootstrap loaded from disk

2)

When the Application Loader is used to load an application program from disk

3)

When programs are invoked that perform large transfers of consecutive data, such as the Human Interface COpy command

Each of these operations does a different amount of processing to the data which is being transferred. This
means that the turnaround time between sector accesses is different.
The Bootstrap Loader instructs the disk controller to read one sector at a time. Thus, the turnaround time
depends on the execution overhead of the Bootstrap Loader and is comparatively long. A large interleave
factor is optimal for flexible disks that are used with the Bootstrap Loader. For hard disks however, the
Bootstrap Loader has no effect on the turnaround time because revolution speed is so great that more than one .
disk revolution occurs between sector reads.
The Application Loader reads several sectors at a time, into its internal read buffer. Then it takes a relatively
long time to process the object records in this buffer. The ideal interleave factor here is one that optimizes for
2-100

230990-001

AP-174

the object record processing time between disk accesses. For flexible diskettes, this interleave factor is somewhat smaller than that for the Bootstrap Loader. However, the Application Loader is not affected by the interleave factor on hard disks.
Applications which transfer large amounts of consecutive data (such as the COPY command) can'initiate data
transfers involving many sequential sectors. Thus, the controller accesses sectors on a given track as fast as
possible. Here, the ideal interleave factor is one that optimizes for the turnaround speed of the disk controller.
The ideal interleave factor depends heavily on the application. However, because the revolution speed of hard
disks is so high, they should be formatted with interleave facto,rs that are optimized for the turnaround speed
of the disk controller.
It is more important to match the interleave factor to the application with diskettes. They are usually smaller
devices and are usually used for one major type of access. Flexible disks are much more sensitive to varying interleave factors, since the controllers for flexible devices are not as fast as the Winchester controllers, Different
types of flexible disks will have different optimum values for the interleave factor. So optimum values for 8
inch diskettes will not be the same as optimum values for 51A inch diskettes.
The default value for the interleave factor in the FORMAT command is 5. The recommended Winchester interleave factor for the iRMX 86 Release 5.0 operating system was 4. This was evaluated to verify if this was the
best interleave factor for the Winchester. Then flexible disks were evaluated to find out which interleave factor
was best for each type of application.

PERFORMANCE TESTS
Since the goal of this application note was to determine optimum values of parameters when systems were
being used for development, benchmarks which measure CPU performance were not used, Instead, all the
tests used involved a lot of disk 110. Some of them also involved building tables in memory. These tables could
have been built on disk if there had been insufficient memory available for them, but that would have degraded
performance markedly.
The languages and system utilities were used extensively, as well as the DIR, COPY, BACKUP and RESTORE
cusps. These are the kinds of things that are done most frequently while using the system for development
purposes. Descriptions of each of the tests used follow,

A$AT Maximum Transfer Rate: The RSAT test ORMX 86 System Acceptance Test) measures the number of bytes transferred every 60 seconds from a secondary storage device: It also keeps track of the maximum number of bytes transferred in a 60 second time period. If RSAT is invoked with a large buffer size, a good approximation of the maximum transfer rate of a device is obtained. A larger buffer size will increase the transfer rate, The largest buffer size that RSAT allows is 63K. This is a multiple of both the Winchester device granularity and the diskette device granularity, so it allows the maximum transfer rate. The RSAT test is a composite of reads, writes, seeks, and truncates. The results are a good indication of overall performance during disk 110. The RSAT test was run for both the Winchester and the diskette evaluations. The RSA T performance data contributed heavily in the analysis of the performance datil. iRMXTM 86 Operating System Generation: The generation of an iRMX 86 Operating system from an Interactive Configuration Utility created submit file consists of a number of compilations and asSemblies, and extensive use of the utilities. The generation of an iRMX 86 Operating System gives a very good indication of the performance 'that can be expected when using these utilities. The time necessary to complete the iRMX 86 Operating System generation was weighted heavily in the analysis of the performance data. This test involved I/O only on the Winchester. 2-101 230990-001 AP·17~ IRMXTM 86 BIOS Generation Because the BIOS generation has fewer steps in it than a full iRMX 86 Operating System generation, it was used ,to zero in on the best configuration quickly. It assembles two modules, and then links two groups of Iibraties together. This test involved I/O only on the Winchester. ~YTest: The Human Interface COpy cusp was invoked to copy a large file (greater than 128K) from secondary storage. This test was used to see what the normal throughput of the system was. This was done for both Winchester and flexible disk devices. DIRTest: This test listed a directory with a large number of files in it to the terminal. The short file format was used to display the directory. This test was of some interest but was not weighted heavily in the analysis of the performance data. The time required to access a directory is extremely dependent on the location of the directory on the device'. This test was done for the Winc~ester and flexible disk devices. Boot Disk Generation: The boot disk generation test formatted a diskette and then copied the files need for a bootable system, onto the diskette. This test gave a good indication of the performance when writing to a diskette. This test was performed to c;leten:nine diskette performance with different interleave factors. Boot Test: The amount of time it took the iRMX 86 Operating System to boot from a diskette was recorded to determine the best interleave factor for booting. This test was performed only on diskettes to determine the optimum interleave factor. BACKUP And RESTORE Test: The time to BACKUP and RESTORE from the Winchester to one flexible disk wa'$,gathered to determine the
best interleave factor for the diskette when it is being used as a backup device. The'IRMX 86 Release 5 versions
of BACKUP and RESTORE were used in the evaluation. The volume granularity and BIOS buffer sizes were
not a factor, since the diskette is formatted physical. BACKUP and RESTORE perform lK reads and writes to
the diskette. BACKUP and RI;STORE use both Winchester I/O and diskette I/O, but the diskette was the only
device ~hich had the interleave factor changed as part of the evaluation with this test.

EVALUATION SEQUENCE
"
,
Since all possible permutations of variables could not be tested, the evaluation was performed by vlP'ying one
parameter at a time. The research started with the default configurations of the operating system. The first
parameter was varied to find the best value, and then its best value was used to determine the next parameter's
optimum value. This method continued until all optimum values had been found. The parameters were tested
in the following sequence.
. .

1)

The best Winchester interleave factor was found for the standard system. Values from 1 to 9 were tested
for the System 86/330A, and interleave factors from 1 to 8 were tested for the System 86/310.

2)

The best Application Loader read buffer size was determined. Buffer sizes from lK to 8K bytes were
tested for both systems in lK byte incremepts.

2-102

230990-001

AP-174

3)

The best number of Winchester BIOS buffers was determined. The systems were tested with 1 to 8 BIOS
buffers for the Winchester.

4)

The best Winchester volume granularity was found. Volume granularities of lK and 2K bytes were
tested for each system.
.

5)

The best Winchester interleave factor was determined. Again, Winchester interleaves from 1 to 9 were
tested for the System 86/330A, and Winchester interleaves from 1 to 8 were tested for the System
86/310.

6)

The best number of BIOS buffers was determined for the diskettes. The systems were tested with 1 to 6
BIOS buffers.

7)

The best diskette volume granularity was determined. Values of256, 512 and 1024 bytes were tested for
the System 86/330A diskette . Values of 512 and 1024 bytes were tested for the System 86/310 diske~te.

8)

The best flexible disk interleave factor was determined for each operation. Interleave factors from 1't~­
were tested for the System 86/330A diskette. Interleave factors from 1 to 7 were tested for the System
86/310 diskette.

SYSTEM 86/330A PERFORMANCE RESULTS
Performance data was collected on a production System 86/330A using the iRMX 86 Release 5.0 Operating
System in its standard configuration. Tests were run to determine the best configuration parameter values. Performance data was again collected with the best configuration of the iRMX 86 Operating System to determine
the improvement in performance. The results for both configurations of the operating system using the 8"
Priam Winchester using the iSBC 215 controller are shown in Tables 1 and 2 for the 5 MHz system and the 8
MHz system.
Table 1. System 86/330A Winchester Performance
(5 MHz ISBC· 86/30 Single Board Computer)

Test

iRMX 86 Generation
BIOS Generation
DIR of 171 files
COpy 128 K byte file

Execution Time
Standard
(min:sec)

Optimum
(min:sec)

Improvement
(percent)

17:22
4:20
0:25
0:10

16:08
4:05
0:25
0:10

7%
6%
0%
0%

Bytes per Second

RSAT max transfer rate

Standard

~ptiJIium

Improvement

80,640

90,316

12%

2-103

230990-001

Ap·174
Table 2. System Q6/330A Winchester Performance
(8 MHz ISBC@ 86/30 Single Board Computer) .

. Execution Time

Test

iRMX 86 Generation
BIOS Generation
DIR of171 files
COpy 128 K byte fil~

Standard
(min:sec)

Optimum
(min:sec)

Improvement
(percent)

13:26
3:21
0:22
0:10

12:29
3:09
0:19
0.08

7%
6%.
14%
20%

Bytes per Second

· RSAT max transfer rate

Standard

Optimum

Improvement

92,467

105,370

12%

Note that the granularity of the measurements was 1 second. In a test that takes 10 seconds to run, the real
amount of time necessary to run a test could be 10% off of the result shown. This can account for the differences shown between the 5 and 8 MHz systems, especially in the DIR and COPY command tests. The tests
which took greater quantities 'of time are a more accurate reflection of the actual system performance that can
be expected.
The optimum values of the parameters are listed below. These were the parameter values which ,were used in
the optimal iRMX 86 operating system configuration.
•
•
•
•
•
•

The Application Loader read buffer size was increased from lK to 7K.
The volume granularity of the Winchester was left at lK, which is the device granularity for the
Winchester.
The number of Winchester BIOS buffers was increased from 4 to 8.
A Winchester interleave factor of 3 instead of 4 was used.
The volume granularity of the diskette was left at 256 bytes. This was the 8" diskette's device
. .
.
granularity.
The numper of diskette BIOS buffers was increased from 2 to 4 ..

Performance data was collected on the 8" DS/DD diskette drive using the iSBX™ 218 controller after finding
the optimum values of the parameters for the rest of the System 86/330A. The best interleave factor for the dis"
kette was determined for each type of use. The results are shown in Table 3.
The fastest boot time was found when the diskette was formatted with an interleave factor 0(7. For transferring
files between systems by using the COPY cusp the interleave factor should be 3. This is shown in Table 4 by the
results of the Boot Disk Generation test, the DIR test; and the COPY test. When treating an 8" diskette as a
physical device, as in BACKUP and RESTORE, the interleave factor should be 2.

SYSTEM 86/310 PERFORMANCE RESULTS
Performance data was collected on a System 86/310 using the iRMX 86 Release 5.1 Operating System in its
standard configuration. Tests were run to determine the best configuration' parameter values. Performance
data was again collected with the best configuration of the iRMX 86 Operatin3 System to determine the improvement in performance. The result for both configurations of the operl!ting system at 5 MHz using the 51,4"
CMI Winchester with the iSBC 215 controller is shown in Table 5. The result for the optimum configuration of
the operating system at 8 MHz using the 51,4" CMI Winchester is shown in Table 6.

2>-104

230990-001

AP·174

Table 3. System 88/330A DS/DD Diskette Performance
Test

Execution Time
(min:sec)

Interleave Factor
Boot Time
Boot Disk Generation
DIR of14 Files
COPY 187,768 Byte File
BACKUP
RESTORE

7

3

2

1:02
6:34
0:22
1:01
4:15
4:40

2:42
6:18
0:21
0:45
2:43
2:43

2:36
6:43
0:22
1:03
2:25
2:25

Bytes per Second
RSAT Max Transfer Rate

5,376

9,677

12,902

Table 4. Optimum Interleave Factors for System 88/330A D'skettes

1YPe of Appllcatlon

Optimum Interleave Factor

Transferring Named files
BACKUP and RESTORE

7
3
2

I

Table 5. System 88/310 Winchester Performance
(5MHz ISBC· 88/30 Single Board Computer)
Test

iRMX 86 Generation
BIOS GenC}ration
DIR of171 Files
COPY 128 K Byte File

Execution Time
Standard
(min:sec)

Optimum
(min:sec)

Improvement

19:16
4:26
0:27
0:14

17:57
4:22
0:24
0:13

7%
1%
11%
7%

(pe~nt)

-

Bytes pe~ Second

RSAT Max Transfer Rate

Standard

,Optimum

Imp,rovement

72,038

69,888

-3%

2·105

AP-174

Table 6. System 86/310 Winchester Performance
(8 MHz iSBC@ 86/30 Single Board Computer)

Execution Time

Test

Optimum
(min:sec)
14:35
3:32
0:20
0:11

iRMX 86 Generation
BIOS Generation
DIR of171 Files
COpy 128 K Byte File

Bytes per Second
Optimum
78,490

RSAT Max Transfer Rate

The best performance of the System 86/310 was found with the following configuration of the parameters.
•
•
•
•
•
•

The Application Loader read buffer size was increased from lK to 7K bytes.
The volume granularity of the Winchester was left at lK bytes.
The number of Winchester BIOS buffers was increased from 4 to 8.
A Winchester interleave factor of 4 was used.
The volume granularity of the diskette was left at 256 bytes.
The number of diskette BIOS buffers was increased from 2 to 4.

After the optimum values were found for the variables affecting Winchester performance, performance data
was collected on the 5.25" DS/DD diskette drive using the iSBX 218A controller to determine the best interleave factor for the diskette. Again, different interleave factors were best for different uses of the flexible disk.
The results are shown in Table 7.
Table 7. System 86/310 DS/DD Diskette Performance

Test

Interleave Factor
Boot Time
Boot Disk Generation
DIR of14 Files
COPY 181,784 Byte File
BACKUP
RESTORE

Execution Time
(min:sed

5

2

1

1:20
12:50
0:24
1:17
2:02
2:04

1:55
10:59
0:27
1:01
1:20
1:11

1:55
11:20
0:24
1:16
1:10
1:00

Bytes per Second
RSAT Max Transfer Rate

3,226

6,451

9,677

"
.2-106

230990-001

AP-174

As the data shows, the best interleave factor for booting was 5. For ordinary use in transferring files between
systems with the COPY cusp the interleave factor should be 2. This was demonstrated by the Boot Disk Generation Test, the DIR test and the COpy test. For BACKUP and RESTORE from the Winchester to the flexible
disk the best interleave factor was l. These numbers are shown in Table 8 below.
Table 8. Optimum Interleave Factors for System 86/31 0 Diskettes

Type of Application

Optimum Interleave Factor

Transferring Named Files
BACKUP and RESTORE

5
2
1

CONCLUSION
The parameters changed generally affected 110 performance the most. The Application Loader read buffer size
was changed from lK to 7K bytes. The number of BIOS buffers was changed from 2 to 4 for flexible diskettes,
. and from 4 to 8 for Winchester devices. The interleave factor was set to 3 for the System 861330A Winchester,
and to 4 for the System 86/310 Winchester. The optimum interleave factor for each system's flexible diskette
varied according to how the diskette was to be used.
By reconfiguring the system with different values for the configuration parameters and no changes to the
hardware, a performance improvement of up to 20% may result. Performance may also be improved by changing the interleave factor when formatting random access disk devices. An application that used disk I/O would
benefit by using the optimum values found in this application note.

2-107

230990-001

AP-174

APP~NDIX A
SYSTEM CONFIGURATIONS

2-108

230990-001

Ap·174

APPENDIX A
SYSTEM CONFIGURATIONS
Both systems used in the performance testing were production model systems. The software used on them was
the iRMX 86 Release 5.0 Operating System for the System 86/330A, and the iRMX 86 Release 5.1 Operating
System for the System 86/310. Hardware and software configurations of each system are shown in Table A-I.
Table A·1. System Configurations

System 86/310

System 86/330A

iSBC 86/30 Single Board Computer
640 K Memory
iSBC 215/218 Disk Controller
iRMX 86 Release 5.1 Operating System

iSBC 86/30 Single Board Computer
384 K Memory
iSBC 215/218 Disk Controller
iRMX 86 Release 5.0 Operating System

Note: More memory was required to run the ICU than was available in the System 86/330A. The ICU requires
448K bytes of RAM to run.

2·109

230990-001

AP -174

APPENDIX B
DEFINITION FILE
OF AN OPTIMIZED iRMX™
86 OPERATING SYSTEM

230990-001

AP-174

APPENDIX B
Definition File of an Optimized iRMX™ 86 Operating System
Hardware
(OSP) 80130 Operating System Extension [Yes/No]
(OTU) 80130 Timer Used [YesINo] ,
(OPU) 80130 PIC used [YesINo]
(OCD) 80130Coypright = 1981 [YesINo]
(BL) 80130 Base Address Location [40h-OFFFFh]
(BP) 80130 Base Port Address [O-OFFFFH]
(MP) 8259A Master Port [O-OFFFFH]
(MPS) Master PIC Port Separation [O-OFFH]
(SIL) Slave Interrupt Levels [1-7 IN one]
(LSS) Level Sensitive Slaves [1-7INone]
(LSP) Local slave PICS [1-7 IN one]
(TP) 8253 Timer Port [O-OFFFFH]
(CIL) Clock Interrupt Level [0-7]
(CN) Timer Counter Number [0,1,2]
(CI) Clock Interval [O-OFFFFH msec]
(CF) Clock Frequency [O-OFFFFH khz]
(TPS) Timer Port Separation [O-OFFH]
(NPX) Numeric Processor Extension [YesINo]
(NIL) NPX Interrupt Level [Encoded]

No
No
No
Yes
OOOOH
OOOOH
OOCOH
0002H
None
None
None
OODOH
0002H
OOOOH
OOOAH
04CDH
0002H
Yes
0008H

Memory
Type: RAM
Type: ROM
Type: RAM
Type : RAM

= low, high
= low, high
= 0104H, 239FH
= 28CDH, F7FFH

Sub-systems
(UDI) Universal Development Interface [Yes/No]
(HI) Human Interface [YesINo]
(AL) Application Loader [YesINo]
(EIO) Extended YO System [YesINo]
(BIO) Basic YO System [YesINo]
(DB) Debugger [YesINo]
(TH) Terminal Handler [YesINo]
(CA) Crash Analyzer [YesINo]
(UIR) UDI in ROM [YesINo]
(CAR) Crash Analyzer in ROM [YesINo]
(RIR) Root Job in ROM [YesINo]

Yes
Req

Req
Req
Req
No
No
No
No
No
No

Human Interface
(ICL) Initial Command Line Size [O-OFFFFH]
(CNM) Command Name Length [0-255)
(SYS) System Directory [1-45 characters]
(DRP) Default Resident Initial Program fYesINo)
(RIP) Resident Initial Program [1-45 characters]
(CON) Conftguration Device Name [1-14 chars]
(PMI) Human Interface Pool Minimum [O-OFFFFH]
(PMA) Human Interface Pool Maximum [O-OFFFFH]
(HIR) Human Interface in ROM [YesINo]
2-111

0100H
0030H
:SD:SYSTEM
Yes
Default
:SD:
0100H
FFFFH
No
230990-001

AP-174

HI Jobs
(MIN) Jobs Minimum Memory [O-OFFFFH pages]
(MAX) Jobs Maximum Memory [O-OFFFFH pages]
(NPX) Numeric Processor Extension Used [Yes/No]

0100H
OOOOH
Yes

Resident User
(TDN) Terminal Device Name [1-12 characters]
(MTP) Maximum Task Priority [O-OFFH]
(UID) UserlD Number [O-OFFFFH]
(MIN) Minimum Memory Required [O-OFFFFH]
(MAX) Maximum Memory Required [O-OFFFFH]
(IpP) Initial-Program Pathname [RESIDENT/1-45 characters)
(DEF) Default Directory [1-45 characters)

TO
OOAOH
FFFFH'
0100H
FFFFH
RESIDENT
:sd:user/world

Prefixes
Prefix: 1-45 characters
Prefix: :$: Prefix: :PROG: Prefix: :UTILS: Prefix: :SYSTEM: Prefix: :LANG: Prefix: HI Logical Names Logical Name: logicaLname,patiLname " Logical Name: LANG, :SD:WORK Logical Name: WORK, :SD:WORK Logical Name: SYSTEM, :SD:SYSTEM Logical Name: UTILS, :SD:UTILS [I -12 Chars, 1-45 Chars) Application Loader (IBS) Internal Buffer Size [O-OFFFFh) (RBS) Read Buffer Size [O-OFFFFh) (LIT) Load Job Type [None/Async/Sync] (DMP) Default Memory Pool Size [O-OFFFFh] (CT) Code Type [Abs(Pic/LtI/Ovr] . (ALR) Application Loader in ROM [Yes/No] 0400H 1COOH Synchronous and Asynchronous OIOOH . Overlay, LTL, PIC and Abs No EIOS (ASC) All Sys Calls in EIOS (ABR) Automatic Boot Device Recognition [Yes/No] (DLN) Default System Device Logical Name [1-12 characters] (DPN) Default System Device Physical Name [1-12 charactersl (DFD) Default System Device File Driver [Phys/Str/Named] (DO) Default System Device Owners ID [O-OFFFFH] (EBS) Internal Buffer Size [O-OFFFFh] (DDS) Default 10 Job Directory Size [5-0FFOh] (ITP) Internal EIOS Task's Priorities [O-OFFH] (PM!) EIOS Pool Minimum [O-OFFFFH] (PMA) EIOS Pool Maximum [O-OFFFFH] (EIR) Extended 110 System in ROM [Yes/No] Req Yes sd wfO Named OOOOH 0400H 0020H' 0083H 0180H 0180H. 1"lo I/O Users User: user name,Owner-ID [,ID,ID;m,ID) 2-112 230990-001 AP -174 Logical Names Logical Name: logical name,device-Ilame,fiIe_driver,owners-id [1-12 Chars ,1-14 Chars. Physical/Stream/Named, O-OFFFFH) Logical Name: BB, BB, Physical, OOOOH Logical Name: STREAM,STREAM, Stream, OOOOH Logical Name: LP,LP, Physical, OOOOH BIOS (ASC) All Sys Calls in BIOS [Yes/No) (ADP) Attach Device Task Priority [1-0FFH) (TF) Timing Facilities Required [Yes/No) (TTP) Timer Task Priority [O-OFFH) (CON) Connection Job Delete Priority [O-OFFH) (ACE) Ability to Create Existing,Files [Yes/No) (SMI) System Manager ID [Yes/No) (CUT) Common Update Timeout [O-OFFFFH) (CST) Control-Sequence Translation [Yes/No) (PMI) BIOS Pool Minimum [O-OFFFFH) (PM A) BOIS Pool Maximum [O-OFFFFH) (BIR) Basic I/O System in ROM [Yes/No) Req 0081H Yes 0081H 0082H. Yes Yes 03E8H Req 0800H 0800H No Intel Terminal Driver (IlL) Input Interrupt Level [Encoded) (OIL) Output Interrupt Level (Enqoded) (UDP) USART Data Port (O-OFFFFH) (USP) USART Status Port (O-OFFFFH) ORP) 8253 Input Rate Port [O-OFFFFH) OCP) 8253 Input Control Port (O-OFFFFH) ORC) 8253 Input Counter Number [0-2) ORM) Input Rate Maximum (O-OFFFFFFFFH) (ORP) 8253 Output Rate Port [O-OFFFFH) (OCP)8253 Output Control Port [O-OFFFFH) (ORC) 8253 Output Counter Number [0-2) (ORM) Output Rate Maximum [O-OFFFFFFFFH) 0068H 0078H 00D8H OODAH 00D4H OOD6H 0002H 00012COOH OOOOH OOOOH OOOOH OOOOOOOOH Intel Terminal Driver Unit Information (NAM) Unit Info Name [1-17 Chars) (LEM) Line Edit Mode (Trans/Normal/Flush) (ECH) Echo Mode (Yes/No) OPC) Input Parity Control (Yes/No) (OPC) Output Parity Control (Yes/No) (OCP Output Control in Input (Yes/No) (OSC) OSC Controls (Both/In/Out/Neither) (DUP) Duplex Mode (Full/HaIf) (TRM) Terminal Type [CRT/Hard Copy) (MC) Modem Control [Yes/No) (RPC) Read Parity Checking [See Help/0-3] (WPC) Write Parity Checking [See Help/0-4) (BR) Baud Rate [O-OFFFFH) (SN) Scroll Number (O-OFFFFH) to-info Normal Yes Yes Yes Yes Both Full CRT No OOOOH OOOOH 2580H 0017H Intel Terminal Driver.Device-Unit Information (NAM) Device-Unit Name [1-13 Chars) (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name U-17 Chars) (MB) Max Buffers (O-OFFH) TO OOOOH to-info OOOOH 2-113 230990-001 AP,-17~ Intel iSBC~ 215/218 Driver (IL) Interrupt Level [Encoded LeveI] (ITP) Interrupt Task Priority [O-OFFH] (WIP) Wakeup Iio Port [O-OFFFFH] 0058H 00'82H 0100H Intel iSBC~ 215/218 Unit Information (NAM) Unit Info Name [1-17 Chars] (MR) Maximum Retries [O-OFFFFH) (CS) Cylinder Size [O-OFFFFH] (NC) Number of Cylinders [O-OFFFFH] (NFH) Number of Fixed Platters/Disk [Q-OFFH] (NRH) Number of Remove Platters/Disk [O-OFFH] (NS) Number of Sectors/Track [O-OFFFFH] (NAC) Number of Aux. Cylinders [O-OFFH) (SSN) Starting Sector Number [O-OFFFFFFFFH] (BTl) Bad Track Information [Yes/No] uinfo.215gen 0009H OOOOH OOOlH 0001H OOOOH OOOCH OOOlH OOOOOOOOH Yes Intel iSBC~ 215/218 Unit Information (NAM) Unit Info Name [1-17 Chars] (MR) Maximum Retries [O-OFFFFH) (CS) Cylinder Size [O-OFFFFH] (NS) Number of Cylinders [O-OFFFFH) (NFH) Numbers of Fixed Platters/Disk [O-OFFH] (NRH) Number of Remove Platters/Disk [O-OFFH] (NS) Number of Sectors/Track [O-OFFFFH) (NAC) Number of Aux. Cylinders [O-OFFH) (SSN) Starting Sector Number [O-OFFFFFFFFH] (BIT) Bad Track Information [Yes/No] uinfo.215w5 0009H OOOOH 0132H 0004H OOOOH 0009H OOOAH OOOOOOOOH Yes Intel iSBC~ 215/218 Unit Information (NAM) Unit Info Name [1-17 Chars] (MR) Maximum Retries [O-OFFFFH] (CS) Cylinder Size [O-OFFFFH) (NC) Number of Cylinders [O-OFFFFH] (NFH) Numbers of Fixed Platters/Disk [O-OFFH) (NRH) Nuniber of Remove Platters/Disk [O-OFFH] (NS) Number of Sectors/Track [O-OFFPFH) (NAC) Number of Aux. Cylinders [O-OFFH) (SSN) Starting Sector Number [O-OFFFFFFFFH] (BIT) Bad Track Information [Yes/No] uinfo.215w OQ09H OOOOH 020DH 0005H 000R' 'l OOOCH OOOAH OOOOOOOOH Yes Intel iSBC@ 215/218 Unit Information (NAM) Unit Info Name [1-17 Chars) (MR) Maximum Retries [O-OFFFFH) (CS) Cylinder Size [O-OFFFFH] (NC) Number of Cylinders [O-OFFFFFH] (NFH) Number of Fixed Platters/Disk fO~OFFH] (NRH) Number of Remove Platters/Disk' [O-OFFH) (NS) Number of Sectors/Track [O-OFFFFH] (NAC) Number,of Aux. Cylinders [O-OFFH] (SSN) Starting Sector Number [O-OFFFFFFFFH] (BTl) Bad Track Information [YeslNo] uinfo.215pt 0009H OOOOH '0102H 0003H OOOOH OOOCH 0006H OOOooOOOH Yes " Intel iSBC@ 215/218 Unit Information (NAM) Unit Info Name [1-17 Chars] (MR) Maximum Retries [O-OFFFFH] unifo.215f 0009H 230990-001 AP-174 (CS) Cylinder Size [O-OFFFFH) (NC) Number of Cylinders [O-OFFFFH) (NFH) Number of Fixed Platters/Disk [O-OFFH) (NRH) Number of Remove Platters/Disk [O-OFFH) (NS) Number of Sectors/Track [O-OFFFFFH) (NAC) Number of Aux. Cylinders [O-OFFH) (SSN) Starting Sector Number [O-OFFFFFFFFH) (BTI) Bad Track Information [Yes/No) OOOOH 004DH OOOOH OOOlH OOIAH OOOOH OOOOOOOOH Yes Intel iSBC@ 215/218 Unit Information (NAM) Unit Info Name [1-17 Chars) (MR) Maximum Retries [O-OFFFFH) (CS) Cylinder Size [O-OFFFFH) (NC) Number of Cylinders [O-OFFFFH) (NFH) Number of Fixed Platters/Disk [O-OFFH) (NRH) Number of Remove Platters/Disk [O-OFFH) (NS) Number of Sectors/Track [O-OFFFFH) (NAC) Number of Aux Cylinders [O-OFFH) (SSN) Starting Sector Number [O-OFFFFFFFFH) (BTl) Bad Track Information [Yes/No) , uinfo_21Sfd 0009H OOOOH 004DH OOOOH 0002H OOIAH OOOOH OOOOOOOOH Yes Intel iSBC@ 215/218 Unit Information (N AM) Unit Info Name 11-17 Chars) (MR) Maximum Retries [O-OFFFFH) (CS) Cylinder Size [O-OFFFFH) (NC) Number of Cylinders [O-OFFFFH) (NFH) Number of Fixed Platters/Disk [O-OFFH) (NRH) Number of Remove Platters/Disk [O-OFFH) (NS) Number of Sectors/Track [O-OFFFFH) (NAC) Number of Aux. Cylinders [O-OFFH] (SSN) Starting Sector Number [O-OFFFFFFFFH) (BTI) Bad Track Information [Yes/No) uinfo-shugart96 0009H OOOOH OOSOH OOOOH 0002H OOOSH OOOOH OOOOOOOOH No Intel iSBC@ 215/218 Unit Information (NAM) Unit Info Name 11-17 Chars) (MR) Maximum Retries [O-OFFFFH) (CS) Cylinder Size [O-OFFFFH) (NC) Number of Cylinders [O-OFFFFH) (NFH) Number of Fixed Platters/Disk [O-OFFH) (NRH) Number of Remove Platters/Disk [O-OFFH) (NS) Number of Sectors/Track [O-OFFFFH) (NAC) Number of Aux. Cylinders [O-OFFH) (SSN) Starting Sector Number [O-OFFFFFFFFH) (BTI) Bad Track Information [Yes/No) uinfo_shugart4S 0009H OOOOH 002SH OOOOH 0002H 0008H OOOOH OOOOOOOOH No Intel iSBC@ 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars) (PFD) Physical File Driver Required [Yes/No) (NFD) Named File Driver Required [Yes/No) (SDD) Single or Double Density Disks [Single/Double) (SDS) Single or Double Sided Disks [Single/Double) (EFI) S or S Inch Disks [8/S) (GRA) Granularity [O-OFFFFH) (DSZ) Device Size [O-OFFFFFFFFH) (UN) Unit Number on this Device [O-OFFH) (DIN) Unit Info name 11-17 Chars) (UDT) Update Timeout [O-OFFFFH) (NB) Number of Buffers [nonrandom = O/rand = I-OFFFFH) (FUP) Fixed Update [True/False) (MB) Max Buffers [O-OFFH) 2-115 cmO Yes Yes Single Single S 0400H OOA6S000H OOOOH uinfo_21SwS 0064H OOOSH True OOFFH 230990-001 AP-174 Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars) (PFD) Physical File Driver Required [Yes/No) (NFD) Named File Driver Required [YeslNo) (SDD) Single or Double Density Disks [Single/Double) (SDS) Single or Double Sided Disks [Single/Double) (EFI) 8 or 5 Inch Disks [8/5) (GRA) Granularity [O-OFFFFH) (DSZ) Device Size [O-OFFFFFFFFH) (UN) Unit Number on this Device [O-OFFH) (UIN) Unit Info name [1-17 Chars) (UDT) Update Timeout [O-OFFFFH) (NB) Number of Buffers [nonrandom = O/rand = 1-0FFFFH) (FUP) Fixed Update [True/False) (MB) Max Buffers [O-OFFH) iwO Yes Yes Single Single 8 0400H 0IE2DOOOH OOOOH uinfo-215w 0064H 0008H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars) (PFD) Physical File Driver Required [Yes/No) (NFD) Named File Driver Required [Yes/No) (SDD) Single or Double Density Disks [Single/Double) (SDS) Single-or Double Sided Disks [Single/Double] (EFI) 8 or 5 Inch Disks [8/5) (GRA) Granularity [O-OFFFFH) (DSZ) Device Size [O-OFFFFFFFFHJ (UN) Unit Number on this Device [O-OFFHJ (UIN) Unit Info Name [1-17 Chars) (UDT) Update Timeout [O-OFFFFH) (NB) Number of Buffers [nonrandom =,O/rand = 1-0FFFFHJ (FUP) Fixed Update [True/FalseJ (MB) Max Buffers [O-OFFH] wmfdxO Yes Yes Double Double 5 0200H 0004F800H 0008H uinfo_shugart48 0064H 0004H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 CharsJ (PFD) Physical File Driver Required [Yes/NoJ (NFD) Named File Driver Required [Yes/No) (SDD) Single or Double Density Disks [Single/Double) (SDS) Single or Double Sided Disks [Single/Double] (EFI) 8 or 5 Inch Disks [8/5J (GRA) Granularity [O-OFFFFH) (DSZ) Device Size [O-OFFFFFFFFH) (UN) Unit Number on this Device [O-OFFH) (DIN) Unit Info Name [1-17 Chars) (UDT) Update Timeout [O-OFFFFH) (NB) Number of Buffers [nonrandom = O/rand = 1-0FFFFH] (FUP) Fixed Update [True/False) (MB) Max Buffers [O-OFFH) wfddO Yes Yes Double Double 8 OIOOH OOOF9700H 0008H uinfo_215fd 0064H 0004H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars) (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No) (SDD) Single or Double Density Disks [Single/DoubleJ (SDS) Single or Double Sided Disks [Single/Double) (EFI) 8 or 5 Inch Disks [8/5) (GRA) Granularity [O-OFFFFH) (DSZ) Device Size [O-OFFFFFFFFH) 2-116 wfdO Yes Yes Double Single 8 0100H 0007C500H 230990-001 AP-174 (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name 11-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = 1-0FFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] Intel iSBC@ 21511SBX™ 218 Device-Unit Information (NAM) Device-Unit Name 11-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) 8 or 5 Inch Disks [S/5] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name [1-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = I-OFFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] OOOSH uinfo..215f 0064H 0004H True OOFFH wro Yes Yes Single Single S 0080H 0003E900H OOOSH uinfo..215f 0064H 0004H True OOFFH Intel iSBC@ 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) 8 or 5 Inch Disks [8/5] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name [1-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number'ofBuffers [nonrandom = O/rand = 1-0FFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] cm1 Yes Yes Single Single 5 0400H OOA6S000H OOOlH uinfo..215w5 0064H 0004H True OOFFH Intel iSBC@ 21511SBX™ 218 Device-Unit Information (NAM) Device-Unit Name 11-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) 8 or 5 Inch Disks [S/5] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name 11-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = I-OFFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] iw1 Yes Yes Single Single 8 0400H 01E2DOOOH 000lH uinfo..215w 0064H 0004H True OOFFH Intel iSBC@ 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name 11-13 Chars] wmfdx1 2-117 230990-001 AP-174 (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [YeslNo] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) S or S Inch Disks [S/S] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name [1-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = 1-0FFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] Yes Yes Double Double S 0200H 0004FSOOH 0009H uinfo..shugart4S 0064H 0004H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) S or S Inch Disks [S/S] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name [1-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = 1-0FFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] wfddl Yes Yes Double Double S 0100H OOOF9700H 0009H uinfo..21Sfd 0064H 0004H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [YeslNo] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) S or S Inch Disks [S/S] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name [1-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = 1-0FFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] wfdl Yes Yes Double Single S OlOOH 0007CSOOH 0009H uinfo..2lSf 0064H 0004H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) S or S Inch Disks [S/S] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name [1-17 Chars] 2-118 wfl Yes Yes Single Single S OOSOH 0003E900H 0009H uinfo..21Sf 230990-001 AP-174 (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand '(FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] = 1-0FFFFH] 0064H 0004H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name 11-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) 8 or 5 Inch Disks [8/5] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name 11-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = 1-0FFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] wmfdyO Yes Yes Double Double 5 0200H 0009F800H 0008H uinfo..shugart96 0064H 0004H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) 8 or 5 Inch Disks [8/5] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name [1-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = 1-0FFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] wmfdyl Yes Yes Double Double 5 0200H 0009F800H 0009H uinfo_shugart96 0064H 0004H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name [1-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No] (SDD) Single or Double Density Disks [Single/Double] (SDS) Single or Double Sided Disks [Single/Double] (EFI) 8 or 5 Inch Disks [8/5] (GRA) Granularity [O-OFFFFH] (DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name 11-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = 1-0FFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] pwO Yes Yes Single Single 8 0400H 0102COOOH OOOOH uinfo-215pt 0064H 0008H True OOFFH Intel iSBC® 2151iSBX™ 218 Device-Unit Information (NAM) Device-Unit Name 11-13 Chars] (PFD) Physical File Driver Required [Yes/No] (NFD) Named File Driver Required [Yes/No] (SDD) Single or Double Density Disks [Single/Double] 2-119 wO Yes Yes Single 230990-001 Ap .. 174 (SDS) Single or Double Sided Disks [Single/Double] (EFI) 8 or 5 Inch Disks [8/5] (GRA) Granularity [O-OFFFFH] .(DSZ) Device Size [O-OFFFFFFFFH] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name [I-17 Chars] (UDT) Update Timeout [O-OFFFFH] (NB) Number of Buffers [nonrandom = O/rand = I-OFFFFH] (FUP) Fixed Update [True/False] (MB) Max Buffers [O-OFFH] Single 8 0400H 00000400H OOOOH uinfo_215gen 0064H 0008H True OOFFH Intel Line Printer Driver (IL) Interrupt Level [Encoded LeveIl (ITP) Interrupt Task Priority [O-OFFH] (POA) 8255A Port A address [O-OFFFFH] (PO B) 8255A Port B Address [O-OFFFFH] (POC) 8255A Port C Address [O-OFFFFH] (CON) 8255A Control Port Address [O-OFFFFH] (TAB) Printer Expanded Tabs [Yes/No] 0048H 0082H OOC8H OOCAH OOCCH OOCEH Yes Intel Line Printer Driver Device-Unit Information (NAM) Device-Unit Name [1-13 Chars] (UN) Unit Number on this Device [O-OFFH] (UIN) Unit Info Name [1-17 Chars] (MB) Max Buffers [O-OFFH] Ip OOOOH NOT REQUIRED OOOOH Nucleus (ASC) All Sys Calls [Yes/No] (PV) Parameter Validation [Yes/No] (ROD) Root Object Directory Size [O-OFFOh] (MTS) Minimum Transfer Size [O-OFFFFH] (DEH) Default Exception Handler [Yes/No/Deb/Use] (NEH) Name of Ex Handler Object Module 11-32chsl (EM) Exception Mode [Never/Program/Environ! All] (NR) Nucleus in ROM [Yes/No] Req Yes 0020H 0040H Yes Never No User Jobs (ODS) Object Directory Size [O-OFFOH] (PM I) Pool Minimum [20H - OFFFFH] (PM A) Pool Maximum [20H - OFFFFH] (MOB) Maximum Objects [I-OFFFFH] (MTK) Maximum Tasks [I-OFFFFH] (MPR) Maximum Priority [O-OFFH] (AEH) Address of Exception Handler [CS:IP] (EM) Exception Mode [Never/Prog/Environ/ AlIJ (PV) Parameter Validation [Yes/No] (TP) Task Priority [O-OFFH] (TSA) Task Start Address [CS:IP] (DSB) Data Segment Base [O-OFFFFH] (SSA) Stack Segment Address [SS:SP] (SS) Stack Size [O-OFFFFH] (NP.X) Numeric Processor Extension Used [Yes/No] OOIOH OIOOH OlOOH OOIOH OOIOH OOOOH OOOOH:OOOOH Never Yes 0082H 23AOH:OOOOH OOOOH OOOOH:OOOOH OIOOH No 2-120 230990-001 Ap·174 Includes and Libraries Path Name [1-45 Characters] (VDF) VOl Includes and Libs Irmx86/udil (HIF) Human Interface Includes and Libs Irmx86/hil (ElF) Extended I/O system Includes and Libs Irmx86/eiosl (ALF) Application Loader Includes and Libs Irmx86/10ader I (BIF) Basic 1/0 System Includes and Libs Irmx86/iosl (THF) Terminal Handler and Debugger Includes and Libs Irmx86/thl (NVF) Nucleus and Root Job Includes and Libs Irmx86/nucleus/' (ILF) Interface Libraries Irmx86/libl (CAF) Crash Analyzer Includes and Libs Irmx86/crashl (DTF) Development Tools Path Names :Iang: Generate File Names File Name II-55 Characters] (ROF) ROM Code File Name rmx86.rom (RAF) RAM Code File Name rmx86 2-121 230990-001 AP-174 Intel Related Publications iRMX 86 Release 5 Operator's Manual (172764-001) iRMX 86 Configuration Guide (9803126-05) System 86/330A Overview Manual (144680-001) iRMX 86 Documentation Addendumjor Release 5 (146032-001) iRMX 86 Basic I/O System Rejerence Manual (9803123-05) iRMX 86 Loader Rejerence Manual (143318-002) 2-122 230990-001 inter APPLICATION NOTE AP-184 August 1984 Writing Device Drivers For XENIX* 86 and 286 Task or Trivia? MOHANDAS NAIR APPLICATIONS MARKETING INTEGRATED SYSTEMS OPERATION © Order Number 280041-001 INTEL CORPORATION, 1984 • XENIX is a trademark of MICROSOFT Corp: 2-123 AP-184 7.0 THE ANATOMY OFTHE 1/0 SYSTEM ........................ . 7.1 The block interface .......... . WRITING DEVICE DRIVERS FOR XENIX 86 AND 286 - TASK OR TRIVIA? 7.1.1 The system buffers ....... . 7.1.2 Driver support routines ... . 7.1.3 Block device driver routines ................. . 7.1.4 Review .................. . 7.1.5 Steps taken to satisfy requests ............. , .. . 7.1.6 iSBC@ 254 Bubble Memory board walkthrough ....... . 7.1.7 Final look at block drivers .................. . 7.1.8 The raw (character interface) to a block device ......... . CONTENTS 1.0 INTRODUCTION 2.0 DEFINITIONS ................... . 3.0 COMPONENTS OF THE XENIX· 1/0 7.2 The character interface ...... . .ENVIRONMENT ................. . 3.1 The process' view of the kernel ....................... . 3.2 The kernel's view of the process ..................... . 3.3 The kernel's view of the driver ........................ . 3.4 The drivers view of the kernel ....................... . 3.5 The driver's view of the device ..... ~ ................. . 3.6 Putting the components together ..................... . 7.2.1 Clists ................... . 7.2.2 Terminal I/O ............. . 7.2.3 Useful routines ........... . 7.2.4 tty.help - the line discipline routines ........ . 7.2.5 Terminal I/O device driver routines ................. . 7.2.6 Examples of character I/O (terminal) drivers ......... . 7.2.6.1 iSBXTM 270 Walkthrough .......... . 7.2.6.2 Low level routines ..... . 7.2.6.3Required routines ..... . 7.2.6.4 A final note ........... . 4.0 TYPES OF DEVICES ............ . 4.1 Block devices ............... . 4.2 Character devices ........... . 4.3 Combination devices ........ . CONCLUSIONS ..................... . APPEt-iDICES 5.0 DEVICES VIEWED FROM THE USER INTERFACE .............. . REFERENCES 6.0 THE ENVIRONMENT ............. ACKNOWLEDGEMENTS ............ . 6.1 The u-area .................. . 6.2 Task-time execution vs. interrupt-time execution ..... . 6.3 I/O path through the system .. • XENIX is a trademark of MICROSOFT Corp. 2-124 280041-001 AP-184 1.0 INTRODUCTION The world of device configuration and device drivers has since time been an area where only hacks could tread. Being the lowest-level of software interfacing to the device, drivers were always examined by selfmotivated experts. Also, drivers were hard to comeby and even harder to comprehend. 2) Understand how the XENIX Operating interfaces to the driver i.e what is covered in this application note. 3) Begin writing the routines needed for a driver i.e. mimic an existing driver. USER-TASK Intel Corporation's "open systems" concept, coupled with the XENIX' Operating System and our family of microprocessor systems, creates an attractive environment for building and adding new devices and drivers. However, the folklore involved with the XENIX Operating System and its internal functions are exemplified in the lack of device driver details. This paper clears the fog around device drivers and device driver writing. It is written for the general operating system user bringing him/her details of the anatomy of the I/O system, driver interfaces and driver support routines. The details that follow pertain to the Release 1 XENIX 286/86 Operating System which is a superset of the Unix' V7 operating system. This application note discusses writing device drivers for the XENIX Operating System as well as describes the operating environment around device drivers. Note that the reader may not need the discussion on the environment when writing device drivers. However, when the reader begins to debug them, he/she will find these discussions worthwhile. Most driver writers would agree that few start writing drivers from scratch. Many use existing driver code as templates. This paper includes actual coded and pseudo-coded examples coupled with descriptions which grant the reader(and soon to be writer) a bouncing-board introduction to writing device drivers. 2.0 DEFINITIONS A device driver is that body of software that allows an operating system to communicate with a device. This body of software is the lowest software level of abstraction in the I/O system. Figure la shows these levels identifying device drivers as a set of machineindependent routines(commands) of the operating system which talk to devices. In the XENIX Operating System, a device driver is a collection of procedures placed in a file that is configured into the system. No source code is needed for this configuration as the operating system, once configured, will talk with these routines in the driver. " Before attempting to write a XENIX device driver, one must: 1) Understand the device i.e. know how to talk to the device, initialize it etc, 'UNIX" a Trademark ofBelll.ab, 1- - - - - - - BYTE-STREAM I/O USER-INTERFACE (SHELL) FILE SYSTEM !-OPERATING SYSTEM DEVICE-DRIVERS t DEVICE 1977 Figure 1 a. Driver Model 3.0 COMPONENTS OF THE XENIX I/O ENVIRONMENT This application note breaks device drivers and the XENIX Operating system into the following components: 1) the process 2) the kernel 3) the I/O buffers 4) the driver(s) 5) the device (s) These components are shown in figure 1b. These components communicate with each other in unique ways. 3.1 The Process' View of the Kernel Processes communicate with the kernel through system calls i.e. open, close, read. These system calls can be found in the XENIX Operating System Documentation (I 73258001). 3.2 The Kernel's View of the Process Section 6.0 (THE ENVIRONMENT) defines a process, process synchronization, user-areas and introduces the kernel's view of the process. 2-125 280041-001 inter AP-184. an introduction to how the above-mentioned components interact. To understand this discussion, the following concepts must be covered: PROCESS 1) Types of Devices (Section 4.0) 2) How Devices are viewed from the user interface (Section 5.0) CLIST KERNEL 3) The kernel's view of the process (The Environment Section 6.0, 6.1 and 6.2) SYSTEM BUFFER 4.0 TYPES OF DEVICES The XENIX Operating System supports two kinds of devices - Block and Character. Input/Output to/from these devices are consequently known as block and character I/O. 4.1 Block Devices A block device is a sectored device that is accessed randomly. A file system resides on it as well. A good example of a block device is a winchester disk or a floppy disk. I/O with a block device is executed through a set of kernel I/O buffers(cache) which intervenes transfers of data (in fixed sized blocks) between user memory and the respective device. Block I/O involves a considerable amount of kernel activity due to these buffering characteristics. OEVICE 1978 Figure 1 b. Components of the I/O Environment 3.3 The Kernel's View of the Driver Section 4.0 (Types of Devices) serves as an introduction to how the kernel views the driver. Details of this view are found in Section 7.0 (The Anatomy of the I/O System) where the system I/O buffers are described as used by the kernel. Also: 1) The size of Block I/O transfer requests from kernel to device are a multiple of the system's block size (BSIZE). BSIZE is 1024 bytes in XENIX 286 Operating System. 2) Transfers are seldom done directly to the user task's memory. The transfers are staged through a buffer pool of BSIZE buffers. Also, the XENIX kernel manages these buffers to perform blocking/deblocking and cacheing. I/O transfers to/from the user task's memory are satisfied from the buffers. 3.4 The Drivers View of the Kernel Section 7.0 (The Anatomy of the I/O System) explains how the driver communicates with the kernel, by introducing the assist routines (Section 7.1.2, 7.2.3, 7.2.4) available to drivers. Furthermore, the driver must understand the buffer scheme when talking with the kernel. Sections 7.1.1 and 7.2.1 (The I/O buffers) detail what the driver manipulates. 4.2 Character Devices 3.5 The Driver's View of the Device The device driver is a collection of routines that act on the device and the device reponds to the driver through interrupts. The driver talks with the device when an action is requested or when the device interrupts the driver on completion of the action. The driver talks with the device through routines which are discussed in Sections 7.1.3 (Block device driver routines), 7.2.5 (Terminall/O device driver routines and Appendix D (Interrupt Mapping). 3.6 Putting the Components Together Section 6.3 (I/O Path through the system) will give A character device is unstructured. A file-system cannot reside on a character device. Examples are terminals and printers. In character I/O, data transfer requests occur in 'n' bytes between sections of memory and the device. Hence, "character" is synonymous to "byte." One must realize that there is minimal operating system involvement in data transfer as it is a private transaction between a user task and the device driver (see figure 2) . 4.3 Combination Devices Some devices can be accessed and treated as a block or character device. For example, the disk interface can be accessed either as a block or character I/O 2-126 280041-001 inter AP-184 USER PROGRAM USER SYSTEM KERNEL DEVICE 1975 Figure 2a. Block I/O Interface USER PROGRAM ~__K_E_R_N_E_L__~~------~~~~D_R_IV_E_R~~~---------'I~I_____D_E_V_IC_E__~ o 0 Figure 2b. Character 1/0 Interface 1976 Figure 2a and 2b. Block and Character Interfaces device. The character device permits direct i/o transfers between user memory and device. This mode of transfer is called RAW liD. Raw liD is very useful when direct disk-to-disk copy is necessary. The kernel buffers and file system are bypassed in this operation. Routines such as dump, dd, fsck are examples of such raw operations. 5.0 DEVICES VIEWED FROM THE USER INTERFACE How are drivers in the XENIX Operating System identified? In the XENIX user interface, a directory called /dev exists for the purpose of holding all relevant device driver interfaces. XENIX is a fileoriented operating system and treats all devices as files. As files are accessible by the file-system, so are devices. An Is -I (directory listing) of the /dev directory is shown in figure 3. Since devices are accessible as files, data can be sent to them with: echo "talk to me" > /dev/ttyaO Devices can be opened, updated and closed via the filesystem. /dev/ttyaO is some-user's terminal. Files that identify devices are called device special files as they provide the hook to the drivers from the filesystem. Enforcing device independence where all devices are files in XENIX permits tremendous flexibility and uniformity in the XENIX Operating System. Device special files are identified to the kernel as a 16-bit integer value. This 16-bit value is composed of two other values, which are the device's major and minor numbers. The high-order 8-bits form the major number and the low-order form the minor number. XENIX provides two macros - major(dev) /minor(dev) to decode these values from the device file. This < major,minor > number pair is used, whenever the device is referenced, to identify the relevant device driver. XENIX is internally very table(array) oriented. These numbers are indices to an array of possible drivers. Figure 3 shows the < major,minor> number-pair for each device. Also note that the leading "c" and "b" characters first on each line denote the character and block files respectively. To see the connection between major number/minor number and drivers, take a look at the c.c file (appendix A). C.c is created in the configuration process. The following datastructures in c.c are created to maintain the relationship between drivers and the major/minor numbers 2-127 280041-001 inter AP-184 4 illustrates the file and directory structure maintaing drivers and the configuration files/shell scripts. Basically, there are three interesting files: (identifying the device special file). The data structures are: 1) dinitsw[ ) is a vector of device-initialization procedures. The procedures mentioned in this vector are called during system initialization to initialize devices. 2) bdevsw[ I is the table of block-device interfaces. The index to a driver in this table is the major device number of the Block interface for the device. 3) cdevswl ) is the table of character-device interfaces. The index to the driver in this table is the major device number of the character interface to the device. Note that major numbers do not overlap for block/character devices unless the same device is represented as a block and a character device. 4) vecintswl ) is the table of interrupt procedures. This table contains one entry per supported interrupt level of the cascaded 8259A Programmable Interrupt Controller. The index represents the interrupt level. total 11 crw - - w - - w brw - - - - - - brw------brw - - - - - - crw------crw - - w - - w crw------crw-rw-rwcrw------crw------brw - - - - - - crw------crw------crw------crw------crw------crw------crw------crw-rw-rwcrw-w--wcrw--w--wcrw-rw-rwcrw - - w - - w crw -rw - rwbrw - - - - - - brw - - - - - - brw - - - - - - brw - - - - - - brw - - - - - - - 1 root 1 root 1 root 1 root lsysinfo 1 root 1 sysinfo 1 root 1 root 1 root 2 sysinfo 2 sysinfo 2 sysinfo 2 sysinfo 2 root 2 sysinfo 1 root 1 root 1 root 1 root 1 nair 1 root 1 root 1 root 2 sysinfo 2 sysinfo 2 sysinfo 2 sysinfo 1 root 4, 0, 0, 0, 2, 3, 2, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6, 3, 3, 3, 3, 4, 0, 0, 0, 0, 0, 1 Feb 1 13:13 console 9 Jan 2317:47 dfO 13 Jan 20 09:47 dxfO 8 Jan 20 09:46 fO 1 Jan 20 09:45 kmem 7 Feb 1 14:24Ip oJan 20 09:45 mem 2 Feb 119:30 null 9Feb 107:32 rdfO 13 Jan 2009:47 rdxfO 1 Jan 30 16:40 root 1 Jan 2009:45 rroot 3 Jan 30 16:42 rusr 1 Jan 20 09:45 rwOa 2 Jan 20 09:45 rwOb 3 Jan 3016:42 rwOc oJan 20 09:45 rwOtO 12 Jan 20 09:47 rxfO oJan 20 09:45 tty oFeb 1 17:35 ttyaO 1 Feb 1 19:36 ttyal 2Feb 1 08:26 ttya2 3 Feb 1 07:53 ttya3 oJan 2009:45 ttyfO 3 Jan 2416:51 usr 1 Jan 30 16:40 wOa 2 Jan 20 09:45 wOb 3 Jan 2416:51 wOc oJan 20 09:45 wOtO 1) xenixcanf: edit this file to describe the <;onfiguration to be built (see Appendix B) 2) master: contains a master copy of the configuration information (Appendix C) 3) c.c: generated from the above two using a program "config." config i.e master+xenixconf = = = = = = = = = = > c.c To configure: 1) edit master 2) edit xenixconf 3) in Isys/conf run MAKEXENIX The rest is automatic. Appendix Band C give examples of xenixconf and master. There will be no further discussion of the configuration details which do not contribute to learning how to write device drivers in XENIX. This overview was meant to describe how c.c is created. However, before attempting to write drivers, one must have a minimal understanding of the operating environment surrounding device drivers. This is the topic of discussion that follows. 6.0 THE ENVIRONMENT The environment of any driver is, of course, the operating system, the device and the userprograms(processes) that communicate with the driver. This section concentrates on the kernel's view of the process. A task or process to the operating system is defined as: Figure 3. Theis Listing Only an overview of configuration details will be covered in this write-up. Knowledge of the configuration process is not needed to write a device driver. Figure 1) the existence of an element/structure in the proc table. The proc table contains details of all processes in the system. 2) the existence of a per-process data area (u-area) representing it in the kernel. Any process image contains this special area that is copied into the kernel data space when it is active. This area identifies the process and hold parameters of the process. A proc table entry and its corresponding u_structure, defines the state of a process at any instance during its birth (fork), lifetime and death (exit). The proc table entry is that part of a process that must always remain in memory for process communication and restart capability. The u_structure is that part of the process which can be swapped out onto disk, along with the per-process data segment, at times when the process is not in a runnable state. 2-128 280041-001 inter AP-184 1987 Figure 4. The Configuration Files/Directories 6.1 The u-area 2) Asynchronous, as when an interrupt occurs and the interrupt service routine is called for the device. The XENIX operating system does not differentiate a kernel process from a user process. Processes can run in either kernel mode, using system services and privileges (access to ilo drivers, \Lllrea) or in user mode, where user-program code is executing. The operating system manages the relevant userprograms using a per-process data area, called the uarea. The u-area contains pertinent information such as system-stack information, preserved registers and I/O parameters used for data transfer. Throughout the discussion on device drivers, there will be mention of information in the u-area. To recap, the u-area is that space held in the kernel to maintain information about processes that run on the CPU. Every process has a u-area that is made up of a detailed structure, called the u-structure. This structure is multiplexed in the kernel i.e is swapped in and out with the process and contains considerable information about the process such as: Synchronous activities happen as the CPU permits users to run their code. When their code makes requests to the system resources, they are subject to be swapped out of memory. Once the device performs these requests, it interrupts the processor asynchronously. The Operating System then calls on certain routines, called interrupt service, routines, to perform actions that follow the device's completion of its requested job. The u_area, being part of the process, may have been swapped out after resource requests were made. Hence, the asynchronous portions of code called on an interrupt cannot access this area. The terms "task-time execution" and "interrupt-time execution" are used to differentiate times it can and cannot be accessed. Obviously, the device driver must contain routines that are called due to asynchronous and synchronous events. system call arguments process sizes registers saved error information I/O information 6.2 Task-time Execution vs. Interrupt-time Execution Input/output parameters held here are: u.u_error -error information, 0 means no error u.u_base - starting user transfer address u.u_count - bytes to transfer u.u..segflg - flag telling if transfer is to/from user data space (0) or system memory (1) u. u_offset - offset in file for 1/0 The driver will receive other information too, such as, the target device, the size of the job and the buffer address in the task's memory. For block devices, only u.u_error is updated. For character drivers, all other parameters are used. The u-area should not be accessed by the running driver at all times. This is because events occur in any operating system that are either: 1) Synchronous, as in normal code executing in user space As mentioned, the XENIX Operating System does not concern itself with whether tasks are running in user or kernel mode. Hence, there may be several tasks contending for system resources that are nonI/O related. At task-time, tasks are executing user or system code. Their u-area may be used whenever the process executes system code i.e. makes a system call and the kernel uses this area for stack and parameter storage. This u-area is resident when the process is running and ,therefore, can be addressed by the driver for data transfer. The user space is addressable at this time and information about the running process can be placed in this area by the driver. Contrary to this, during interrupt-time execution, the device has interrupted the CPU. At this time the running task may not be the task that requested 2-129 280041-001 inter AP-184 I/O to/from the device. Usually, the task-time portion of the driver has exited after the I/O request and that process may have been swapped out. Hence, the u-area and the user data space cannot safely be accessed or used at interrupt time by the interrupt service routine. However, the interrupt service routine gets relevant information(about what to do) from the task-time portion of the driver via static variables. Obviously, from the nature of taskmanagement, interrupt routines are limited in behavior and they cannot make assumptions about the state of the system or the presense of tasks/data in the system. Figure Sa illustrates the distinction between the task-time portion and the interrupt-time portion of any driver that has to evidently cater and respect the realities of task vs. interrupt -time execution. One such routine is called by bOth sides and manipulates common buffers used (will be discussed later). There is a mechanism used for mutually excluding an update attempt of one routine from another. This mutual exclusion technique is required as the asynchronous portion of the driver may be-removing an elem'ent from a list, for example, while the synchronous portion of the same driver may be placing an element onto the list. The technique basically deals with the interrupt structure and priorities of the system. For further details on the interrupt mapping, see Interrupt Mapping(Appendix D). The operating environment, and the' nature of tasks have been discussed only briefly as the device driver is the main focus of this application note. To bring together the basic components of the roadmap (Section 3.0) i.e. how the process, the kernel and the driver communicate, a brief description of the basic I/O path through the system follows. Task and interrupt-time routines are separate but they may call common data-manipulating routines. INTERRUPT TASK \ \ \ YES \ \ \ \ KERNEL TASK PORTION OF DRIVER \ \ \ \ \ 1983 Figure 5a. Task vs.lnterrupt Time Execution 2-130 280041-001 inter AP-184 6.3 1/0 Path Through the System Thus far, the driver interfaces have yet to be discussed. Knowing the environment a driver exists in is sufficient for understanding the 110 path through the kernel when liD system calls are made. This will explain how the components of the roadmap (Section 3.0) interact. To illustrate the way all these device tables and system calls relate, the following caIling sequences are presented. Details have been avoided to simplify the concepts described. 1* * user program makes system call */ fd = open ("/dev/ttyb1 ",1) 1* * the kernel reacts with */ 1) The kernel entry routine gets the system-call trap, determines it's an "open" call and calls "open" in the kernel. 2) Open calls a procedure to parse the path-name (nami) and turn it into an inode. An inode is the structure that represents a file in the file-system. 3) Open notices thai the inode represents a'character special-file and not a normal disk file. Thus, it accessed the cdevswll table using the major number in the inode, and calls the devicedrivers open procedure. 4) The driver's open procedure does whatever it needs to do i.e. opens the device. It sets u.u.-error if an error occurs and returns. 5) If the driver did not declare an error, open allocates a file-descriptor in the user-process, and returns it. 6) If the driver returned an error, open simply passes it back to the user program. 1* * user program does */ read(fd, buf, 128); 1* • kernel does 0/ 1) The kernel gets the system-call trap, determines it is a read call and calls read in the kernel. 2) Read uses the "fd" argument and determines which inode it represents. 3) The inode indicates it is a character special-file. Thus, read uses the major device number stored in the inode to access the cdevswll table and calls the drivers read routine. 4) The drivers read routine does whatever it needs to do transferring data to the user's buffer. If any errors occur, it sets u.u_error. In any case, the driver eventually returns after having transferred the data. 5) The read routine returns to the kernel, which returns to the user program. The liD path will be elaborated on with details on driver functions with respect to block lID. For the time being, the above sequence should be used as a template. 7.0 THE ANATOMY OF THE 1/0 SYSTEM This discussion covers how the kernel and the driver communicate (See Section 3.0 Roadmap) and can be best broken down into two stages. They are: 1) the block interface 2) the character interface The following discussions go into much detail on how the buffer schemes for block and character liD devices work. These details are not needed for device driver writing. However, knowledge of the kernel buffers for block I/O devices and the character lists for character I/O devices will be useful when debugging begins. This knowledge will help the device driver writer to understand the inner workings of the driver he/she is writing. 7.1 The Block Interface Much has been discussed about what block I/O is. Block I/O transfers require the kernel's intervention when they occur. All block transfers require the use ofI/O buffers. These buffers are used as a temporary storage area for caching and blocking/deblocking. Usually, data transfer occurs between user space and devices via these system buffers (see figure 5b). Each buffer is BSIZE bytes long and has a buffer header corresponding to it. BSIZE and other system level constants are defined in param.h (Appendix E) The header file buf.h defines this buffer header structure(Appendix F). Buf.h also describes how these kernel buffers are structured. Although it is not necessary to understand all fields in the buffer header, some fields must be noted: b_devdevice number b_blkno- block for the transfer b_bcount- bytes to transfer 2-131 280041-001 AP-184 b_cylinb-llddrbJiags- cylinder number address to be transferred from/to nature of transfer i.e. B-READ 7.1.1 THE SYSTEM BUFFERS Consider a list, called the freelist, that is initialized to be a circular doubly-linked list of buffer-headers. Each header in the list has a pointer to its own BSIZE buffer. Figure 6a shows this list with forward and backward pointers avJorw and av_back. Consider another list called the device list. This list hangs off each device driver. The buffers forming these device lists are device request that are waiting to be serviced. At start state these lists for each device are empty and their headers point to themselves with b_forw and b_back. (figure 6b). Each device has its own queue structure that exists to schedule I/O requests. This queue is structured exactly like the freelist, i.e. is doubly linked and circular. The head of this queue called the static buffer header, is a buffer-header just like all the others. However, some irrelevant fields that it holds (used by other headers in the queue) are redeclared (aliased). These redeclarations are found in buf.h. Here, av_forw, av_back, bJorw, b_back used on the same buffer headers but form two concurrent lists. Remember, the free list is the master list. b_f1ags determines, for the enquirer, if the buffer is BUSY, WAITING and the like. Details of these flags are found in buf.b also. (for further details about flags see ref 1). The configuration file c.c (appendix A) holds the data structure bdevsw[ I which is the table of device driver routines indexed by their major number. The last element in this structure for each device is ixxxtab (see naming convention - Appendix G) where i/ II II U If BLOCK DEVICE: 7 1986 Figure 5b. The System Buffers 2-132 280041-001 inter AP-184 DEVICE LIST FREE LIST ixxxTAB : \ 6J~ AV_BACK .s6)J "-'0'. CGJ) CGJ) ( AV_FORW ) (61 • • 1988 Figure 6a. Start State xxx is the device identification number e.g. 215, 544. xxxtab is the pointer to the system buffers for that device i.e xxxtab is the static buffer header address for the queue of device request. Remember that at start state, these queues are empty. When a user process requests a write (as a first request) a buffer header from the free list is removed and placed on the device list. The av-pointers of the freelist are unused and b_pointers are now used in the device list. The av _pointers are re-declared to be b..actf and b_actl respectively. These links ar.e used to form a new list using the same buffer headers that are in the device queue. Think of two lists i.e. the device list (with items plucked from the free list) using all four pointers ,thus being members of two lists superimposed (see figure 6b). But why two lists superimposed? Well, at first there were two lists the freelist and the device specific list (of course, each device has one device specific list but for this discussion let it suffice to have only one device). U pan a request, the kernel takes a buffer header from the freelist and places it on the device queue. The kernel also places details of the write request into the buffer header fields. As the kernel manages 2-133 these buffers, the address of this buffer header is given to the device driver. The driver calls a routine disksortO which takes the buffer header and orders it in the device specific queue using not the b_pointers but the unused av_pointers. Note that the buffer header is already in the device queue with the b_backlb_forw pointers active. DisksortO orders these requests into cylinder order on insert using the avJorw (b..actf) and aLback(b_actI) pointers forming a new list of optimally ordered requests (see figure 7a). There are tb,ree lists formed here: 1) the device specific list hanging off the device driver (cdevsw = = > xxtab) 2) the active list that uses the same elements in the device list but uses the av _pointers ordered by disksortO 3) the free list of buffer headers using the av_pointers before redeclaration. Thus, the write request is then ordered into the active list for the device. 280041-001 inter AP-184 FREE LIST DEVICE LIST 6) CGJ) (6)) (6)) • • • 6) 1989 Figure 6b. Buffer placed in device list by kernel The task-time portion of the driver has been running all this time and this task portion returns after it h~s made the request. The user process sleeps on the event that the device will complete the requested transaction. In other words, the task sleeps on the buffer-header address. The sleepO instruction permits a context switch within the operating system. The operating system can then schedule other tasks for CPU attention. The device, on completion of the requested write will interrupt the CPU. The interrupt, through the XENIX interrupt scheme, will invoke the respective interrupt service routine which is in the interrupttime portion of the driver. This is done asynchronously. This interrupt service routine will awaken all processes associated with the event using iodoneO (see section 7.1.2). Note that for write, the task-time portion was responsible for the transfer of data from the user space to the buffers while the interrupt service routine is invoked when the data in buffers are written to disk. Th'e relevant process, on awakening is rescheduled by the scheduler to run as soon as possible. The interrupt service routine then checks to see if there are other pending requests on the device specific queue. If not empty, it instigates the next transaction from the next buffer on the device queues (by following the av_pointers now declared b.-actflb_actJ) . When interrupt routines are alive and running, mutual exclusion(mutex) is ensured by raising the priority level of the running task in the CPU and on completion, lowering the priority level. Details of this technique is found in Interrupt Mapping ( Appendix D ). This technique locks out interrupts of an equal and higher level than itself for a short period when shared data structures are manipulated. The interrupt service routine may be looking for the next request on the device queue, when the task-portion 2-134 280041-001 inter AP-184 FREE LIST DEVICE LIST/ACTIVE LIST AV _FORW I AV _BACK USED HERE BUT ALIAS ED TO B..-ACTF/B_BACTL (DISKSORT PLACES IT IN THIS QUEUE> • • • AV _FORWI AV _BACK USED 1990 Figure 7a. Another Request Placed in Device List and also Placed in Active List by Driver of the driver may be calling disksortO that orders the device list or when the kernel is placing the buffer header with a request onto the same list. On completion, the buffer header is marked as IO complete and this header is released from the device specific queue and placed at the end of the free list using the av_pointers. Note that the link to the active list is broken ( reusing the av _pointers). Remember also, that b_forw/b_back pointers are still maintaining membership with the device specific list even when the buffer is now a member of the freelist pool. Here is where the buffer is placed in cache. the kernel will search the device queue (not the active list) from the beginning. As you can see in figure 7b, the list is diverted into another list of available but recently used buffers by following b_forw /b_back pointers. Here cacheing occurs as most recent transactions can be checked for repetition. Note that the X buffer will bubble up the free list until it will be re-used for other transactions. U ntiI then it is cached. ' As shown in figure 7b,the buffer request X is placed on the freelist using the av_pointers but is still a leading member of the device list. On the next request, 2-135 280041-001 AP-184 FREE LIST DEVICE LISTI ACTIVE LIST AV.FORW/AV.BACK USED HERE ~~ ~tf'+~~S CACHE LIST HANGING OFF THE DEVICE LIST 1991 Figure 7b. When Request Grantfd the Buffer is Returned to Free List but Is Still a Member of the Device List and is cached. No Longer in Active List. For a review of the block drivers duties, in an I/O request, consider a read request and the following point-by-point discussion: .fill out buffer header . with device # . block # · call task-time portion of device driver · on return , · sleep on buffer header waiting for wakeup · copy into user space user calls read READ { · maps file fd to inode · calls readi ' readi (read inode) · determines block to be read (bmapO called) · searches buffer list i.e follows av_pointers matching block # to last read/write · if cached, copy into user space and return · if not cached, flush first buffer from free list J The device driver does { issues or queues request to the device interrupt handler wakes processes when on I/O complete when awakened return to readi J 2-136 280041-001 AP-184 NOTE: the above is only a specific example and a brief one. For example, details of the support routines checking whether it is block/character read was not mentioned. disksort(&xxxtab, bp); So far, elements of the I/O system anatomy discussed are invisible to the device driver writer. He/She need not know all of the intricacies of buffer management but there is a need to fully comprehend the routines to be written, the system calls available and the operating environment of device drivers. In accordance with this methodology, block drivers have, in their grasp, many powerful and consistent system calls available from the kernel. They can be called "driver support routines" because some of them are available to character drivers also. disk sort 0 is the assist routine ingredient to the buffering/cacheing protocol as it manages the active request queue. It takes, as arguments, the address of the pointer to the static buffer header for the specific device. The active request queue holds all requests for the device. bp is the pointer to the new buffer header that holds another request on the device. disksort 0 inserts this request in the queue of requests in cylinder/block order to minimize disk accesses. 7.1.2 DRIVER SUPPORT ROUTINES iodone(bp) The following list is an informal collection of possible support routines used in block I/O drivers and by the kernel. The kernel deals with the declarations for the arguments and on many situations, places values into these arguments. This is because the kernel is allowed access to most of these arguments and knows their values. Some of these calls are also used in character I/O transfers and will be referenced in the character interface description: struct buff xxxtab 1* static buffer header */ struct buf *bp 1* new buff header to be inserted *1 struct buf *bp 1* header of completed request • / is a clean-up routine that informs the process that the request made is complete. iodoneO is called by an interrupt service routine and issues a wakeupO on the relevant event i.e. the buffer pointer bp. The routine pulls the request off the device specific queue and places it onto the free list. sleep(bp,prj), wakeup (bp) and iowait(bp) physio (strat,bp,dev ,rw) struct buf *bp where strat is the address of the strategy routine(a driver procedure) which is the routine that performs read, writes and starts up the device. This routine will be discussed in section 7.1.3. It takes, as an argument, a pointer to a buffer-header (bp) which holds detailed information about the transfer. where dey is the relevant device that character I/O is to occur to (the < major, minor > ) pair. where rw is a flag indicating the nature of the transfer(B~EAD, B_WRITE in param.h} Physio is used by block devices which can be treated as character devices. In this case, transfer between user space and device space is done directly(direct I/O} with no intervening buffers. Remember that for this to be successful, physical 1/0 must occur when the instigating user process is in memory and active (and not swapped out). physio is a routine called by a driver for physical I/O on a device. Among other functions, physio checks the validity of the transfer request. The buffer header pointer that is passed to physio does not hold a buffer address but the address of the physical location in memory or the device, depending on the direction of the transfer. Physical I/O is a contiguous transfer feature that is used in tar, fsck and dd, among other utilities. 2-137 Process/task synchronization is a required feature in the multi-user/multi-tasking XENIX Operating System. Processes have to be informed when to wait for the system's shared resources. The XENIX kernel provides two routines, sleepO/wakeupO, for this purpose. SleepO takes, as argument, a key or event that the calling process waits on. This key or event is nothing more that a bit-pattern. The key or event in this case is conveniently the bufferheader pointer that the task-time portion of a driver is using for the transfer request. To re-iterate, the task-time portion of the driver, when making an I/O request, may have to wait after the request is made until the actual I/O is completed. The waiting is begun by a system routine called iowaitO which is called by the kernel and physioO which is called by a driver in direct physical I/O (for magnetic tape drivers when driver calls stratO and waits for I/O t6 complete). PRI, the second argument, is the priority at which the process is to sleep. The sleep priority is higher than what a user process can acquire. When the wakeupO occurs, the process continues at the sleep priority thus giving it a higher probability of being scheduled earlier. 280041-001 inter AP-184 Priorities range from 0 to 127. Priorities are not bound by rules but the priority PZERO is used to differentiate two main situations that may occur. If a priority < PZEROis set for the sleep, no signal can wake up the process. Hence, the process will be awakened with an iodoneO in the future. With a priority > PZERO, signals will awaken the process even before iodoneO Also, smaller numerical priorities mean higher priority levels. The safer technique is therefore to place 'sleep' in a loop that tests if the buffer is available for continuation. Hence, if I/O is complete arid the buffer freed, the process is awakened legally. Otherwise, continue to sleep. Also, when the device returns an interrupt iodoneO is called which calls wakeupO that sets the event(buffer header) and induces life to all processes waiting on that event - not just the "first" one. Processes must therefore ensure that they are awake for the correct reason. One way to do this is for the tasktime portion to check a predetermined static memory location for instructions left by the interrupt-time portion of the driver on completion. openO is a routine that opens the device. Prepare it for activity and is called on every open of the device. Its parameters are dev_tdev; int flag; open (dev ,flag) is the calling sequence where dey is < major, minor > device number and flag is either B_READ or B_WRITE. The program validates the device number and sets-up initial parameters. Any errors detected is recorded in the u. u_error. The presence of the device is verified before the open occurs. close (dev) is called on the final close of the device. The close routine flushes pending transfers in device specific queue and sets flags that remember that the device is closed. strat(bp) struct buf *bp; 1* pointer to buffer header */ timeout(func,arg,time) int ('func) 0; int arg; int time; 1* function called as argument */ Arranges for func to be called with argument arg in time clock-ticks. timeoutO is a, facility that runs a procedure after n clockticks. The procedure is called at clock interrupt time and ,hence, conforms to the interrupt-time rules. Used for character I/O also. Called by the kernel.in response to the user program instigating a read/write request. strat is "strategy." Inserts a request on the queue of device requests. The kernel provides a buffer header to the routine and it validates the header to ensure that it has all the necessary information ( e.g B_READ ). The driver routine calls startO and disksortO intr(IeveJ) int level; iomove(addr, count, flag) Used for large data transfers. addr gives you information on where in kernel the transfer is to occur. count signifies the size of the transfer in bytes. Flag tells us if it is a B_READ/B_WRITE. The other transfer address is found in the processes' u_structure as u.u_base. 7.1.3 BLOCK DEVICE DRIVER ROUTINES Briefly, a block device driver is composed of one or more of the following routines: The interrupt routine is called by the kernel when the device interrupts. This routine is called when the device is moving from an active state to an idle state. If the device is active on entry to the interrupt service routine, the interrupt service routine was awakened by a spurious interrupt. ,If not, the device state is changed to idle. In this state, the previous request was satisfied and an iodone should be called. The momentun is continued to keep the device busy by calling the startO routine if other requests are pending on the request queue (device specific queHe). startO jnitO is a routine called very early during system initialization (at boot time) to initialize the device. It is called with no parameters and returns no values. Interrupts are disabled at this time and the existence of the device is verified. It prints appropriate messages stating that the device is/is not found and remembers if the device is alive (sets a flag). This routine is called once. This routine functions to move the device from an idle state to an active state i.e. it talks with device. It is called when the device is idle or a request is queued. It interprets the information on the buffer header at the beginning of the queue of device requests and sends commands to the controller. 2-138 280041-001 AP-184 These routines form a file called ixxx.c where xxx is the numerical representation of the device (see Naming Conventions - Appendix G). This file should reside in /sys/io directory. Conventionally, cxxx.c an adjoining file is also created to identify any data structure relevant for the main program. cxxx.c resides in the /sys/cfg directory. Finally, constants and #defines are found in a header file, generally "included" in cxxx.c, called ixxx.h. This file is created in /sys/h. Hence, a driver for the iSBC 254 Bubble Memory board should be composed of: i254.c main driver routines i254.h the header file c254.c the configuration data structures With this brief description of the driver routines, a casual discussion of how these routines interact with each other and the kernel is a natural follow-up. Some reiteration of previous details is necessary to give an overall consistent discussion. 7.1.4 REVIEW User requests to be performed on a device (usually on a file living on the device) are converted by the kernel to simple requests for I/O which are passed to the driver. The kernel does any blocking/deblocking and cacheing to minimize device accesses. Strate) and IntrO are the main routines required of a block device driver. The request which is passed to the strate) routine is passed in the form of a pointer to a buffer header. This header contains all the information necessary to perform the operation - B_READ, B_WRITE, device address to use e.g. which track and sector, and the address of the kernel buffer from which the data should be taken or into which the data should be placed. The buffer header points to BSIZE'd buffers and the request will always be for BSIZE operations. Be sure to keep in perspective the level of software being discussed - the driver itself sees only requests for transfers to or from a physical block of the device - entities like file-structure, disk space allocation, or blocking/deblocking of small or large requests are all performed by higher level kernel software. All the device driver needs to do is examine a request, determine whether it is a read or write and perform the operation between the indicated memory address and the indicated block device. 7.1.5 STEPS TAKEN TO SATISFY REQUESTS This discussion centers around the strate) and intrO routines. All requests are passed to the driver by the kernel by calling the stratO routine, with a single parameter - a pointer to a buffer header. As before, the header specifies the type of operation that is to be performed, the memory and device addresses to be used, and a field for recording the result of the operation after it has completed. The stratO routine places the incoming request on the linked list of active requests to be performed. If the device is currently busy performing a previously queued request, the stratO routine has finished its job and returns. If the device is idle (j.e. the request is the only one on the active list), the strate) routine must initialize the operation for the request. This typically involves loading parameters into a peripheral controller and initiating a command. At this point, the stratO routine has completed and returns. After a command is started, it is typically a long-time (by cpu standards) until the request is completed and an interrupt occurs. The interrupt routine must field this interrupt and determine the reason for it. If it is the expected "operation-complete" interrupt, the interrupt routine should perform any operation needed to complete the transfer, then call the iodoneO routine with a single parameter - the pointer to the buffer header of the request just completed. The iodoneO performs some clean-up, notably waking up the process which was waiting for the I/O to complete. At this point, the interrupt routine may determine if other requests are waiting in the active request queue for the device, and if so, initiate the next one by calling the startO routine. Once done, the interrupt routine returns with its jo b done. The interrupt routine is a trigger that keeps firing-up new requests as they are discovered on the queue. Once the list is exhausted, the intrO routine returns without starting another request (none there to start) and the seed is lost and the sequence stops. The strate) routine must start another request to "prime the pump" and start the momentum again. With this understanding of driver routines, a pseudocode example of the iSBC 254 Bubble Memory board driver will complete the discussion of block I/O device drivers. As mentioned, this section of block I/O is not the main thrust of the application note as emphasis has been placed on the character interface. This discussion will culminate in a pseudocode walkthrough. 2-139 280041-001 AP-184 7.1.6 iSBC@ 254 BUBBLE MEMORY BOARD WALKTHROUGH 1/" 2 • SBC 254 Bubble Memory board device driver. (Pseudo-code) 3' 4" - implements block and raw interfaces for an SBC 254 -1, -2, or -4. 5 • - always accesses all bubbles in parallel, meaning that there are 6 • always 2048 pages on the board, and the page size can be 64, 128, 7 " or 256 bytes (see c254.c) 8 • - will handle only one 254 9 * - uses DMA mode for bubble accesses 10' - I/O base address and number of bubbles configurable in c254.c 11' 12 * 13 "f 14 15 #include " .. fhfparam.h" 16 #include " .. fhfsystm.h" 17 #include "../hfbuf.h" 18 #include " ..lhfconf.h" 19 #include " ..Ihfdir.h" 20 #include " ..Ihfuser.h" 21 #include " .. /h/i254.h" 22 23 24 extern struct i254cfg i254cfg;1* see c254.c 25 • for values, i254.h for definition 26 "f 27 struct buf i254tab; f* static buffer header • f 28 struct buf i254rbuf; 1* static buffer header for 29 rawinterface *f 30 short i254alive, i254isopen; 1* device existence, open flags *f 31 321* 33 * i254init - called early in the system initialization - probes for 34 • 254 by resetting it and watching for appropriate reaction 35 *f 36 i254initO 37 ( 38 39 1* 40 • this is the first routine of the driver that will be called, 41 • it's a good time to clear the i254isopen flag 42 *f 43 44 i254isopen = 0; 1* 254 is closed *f 45 46 1* 47 * more stuff to init the board and check status 48 *f 49) 50 511* 52 • i2540pen - checks for correct minor number(O} ,and existence of the 53 * board, and either allows or disallows the open 54 *f 55 56 i254open(device, flag} 57 dev_t device; 1* device number *f 58 int flag; 1* what kind of open (for reading, writing, etc.) 2-140 280041-001 inter AP-184 we'll ignore this 59 60 { 0, if ((minor (dev) = = 0) && (i254alive» { 1* mark 254 as open i254isopen = 1; return; } else { u.u_error = ENXIO; return; 61 62 63 64 65 66 67 0, 68 69 } 70 711* 72 °i254strat - queues the flO request and starts it if the device is idle 73 0 , ' 74 i254strat(bp) 75 struct buf *bp; 76 77 { 78 int x, startpage, numpages, ppb; 79 80 1* o first thing to do is check device is open; otherwise, allow 81 o no I/O 82 0, 83 84 85 if ( - i254isopen) { bp->bJlagsl= B..ERROR; bp->b_error = ENXIO; iodone(bp); 1* mark it done return; 86 87 88 89 90 0, 91 921* 93 * convert the block number to a page number, and the number of 94 0 blocks to number of pages, and the starting block to the starting 95 • page - these could be sped up with some appropriate shifts instead 96 * and' 97 98 99 *'ot· *' 100 0, ppb = BSIZE' i254cfg.c_page..size; 1* pages per block numpages = bp- > b_bcount • ppb; * number of pages 0/ startpage = bp-> b_blkno * ppb; 1* 1st page of transfer 101 102 103 1* 104 • Now check the requested' operation for validity in terms of the 105 * the number of pages on the device. 106 • Here's the thinking: 107 • if request is READ on 1st block after the last block -> EOF 108 • " " " WRITE" " "" " " " . . > error 109 * " " " READ or WRITE 2 or more pages past the end - > error 110 o if request starts on valid page, but runs offend -> EOF III 112 113 114 115 116 117 118 *' 0, if (startpage > BUBPAGES) { 2 or more after last page, so error • / bp->bJlagsl= B..ERROR; bp->bJlags = ENXIO; iodone(bp); return; ,0 2-141 280041-001 AP·18'4 119 } '120 if (startpage = = BUBPAGES) ( 121 1* 1st ,block after last one 122 if(bp->bJlags&B-READ) 123 bp- > bJesid = bp- > b_bcount; read, so just EOF 124 else { 125 * write, so error 126 bp->bJlagsl= B..ERROR; 127 bp-> b..error = ENXIO; 128 } 129 iodone(bp); 130 return; 131 } 132 if «startpage + numpages) > (BUBPAGES -1)) ( 133 1* starting ok, but running off end 134 bp- > bJesid = bp- > b_bcount; 135 iodone(bp); 136 return; 137 138 139 1* if we're here, request looks OK, so queue it and 140 * (if necessary) start it 141 142 143 bp->b..cylin = startpage; 1* use page number as sort field 144 145 146 * Since we're about to play with the queue, and this can be 147 • accessed at any time via the interrupt handler, we need to 148 * shut down this interrupt level to provide mutex 149 150 151 x = SPLO; 152 disksort(&i254tab, bp); 153 if(i254tab.b...active = = IOJ:DLE) i254start(bp); 1* start if idle 154 splx(x); 1* reenable this interrupt level·' 155 } 156 i254start(bp) 157 struct buf·bp; 158 159 1* this routine is the most device specific of all others. 160 The routine is called by both stratO and intrO at task-time 161 and interrupt time. It starts up the device ifit is idle and 162 keeps the momentum going with other requests. 163 164 165 1* 166 *i254intr - interrupt handler-checks status of operation just completed 167 * and starts new operation if one is queued 168 ., 169 i254intr(!eveI) 170 intIevel; 171 { 172 short stat; *' *' '* *' *' *' *' '* *' *' *' 173 174 175 176 177 178 1* • point to first buffer header in the active queue, making sure * that it's actually pointing to a buffer header *' 2-142 280041-001 AP-184 179 if «bp = i254tab.b-- b_flags 1= B-ERROR; 208 bp- > b~error = EIO; 209 ) 210 else if (stat & BMCCORERR) 211 printf("Cor error, i254intr, status = %dO, stat); 212 213 1* 214 * At this point we have determined that a legitimate bubble interrupt 215 * has occurred, and if there has been an error, it's recorded. Now 216 * we need to mark the operation as complete and start the next request 217 * in the queue (if there's one there). 218 *j 219 220 i254tab.b_actf = bp->avJorw; 221 iodone(bp); 222 if «bp =i254tab. b-- terminals), a data buffering mechanism is employed. These Queues are character-based and, hence, are used only for small data transfers. 7.2.1 CLISTS Each driver that wishes to use these butTers declares a static butTer header. These butTers are called clists and are linked-lists of butTers. The ·butTer header is declared in tty.h (Appen\iix H). The struc.ture of the header is: r characters in the list *1 1* ptr to first char *1 /* ptr to last char "I 2-146 280041-001 AP-184 These dist-headers point to character-holding links that contain four-word blocks of characters( pointer and six characters ). Each driver program declares its own clists and this structure accumulates cliststructure-elements (as data transfer prevails) from a "freelist" of buffers. The buffer mechanism is simple compared to the block interface as only a few routines manipulate the dist structure. These marks are maintained for each dist by routines that manage them. When a process requests more than its high-water mark, it puts itself to sleep until there are more fre'e to use i.e. when the c1ist is flushed and it hits its low-water mark). This is an output feature (cannot suspend keyboard input!!). This will alleviate the problem of any process dominating the freelis!. Low speed character devices are assisted by the c1ist structure declared by the relevant driver. Each driver that deals with byte I/O must declare dist structures required for each operation i.e. an input dist and an output clis!. Two routines, geteO and puteO manipulate the dis!. 1) geteO removes a character from the list and moves e_cf forward if it not in a block boundary i.e. it is not in the end of a six character boundary. If it is, the pointer ccf is set to the beginning of the next block and the block that the last character was read from is placed in the freelist ( see figure 8a and b). 7.2.2 TERMINAL I/O Each terminal line is associated with line characteristics called the tty structure. Details of these are found in the manual section of tty (4) in the XENIX Operating System Documentation (I 73258-000. The file tty.h describes the tty structure for each line. 2) Consequently, puteO places a character in the list and obtains a new block when necessary (see Useful Routines). There exists a set of routines that manipulate this tty structure.These routines are found in tty.c (not attached) and are termed "line diSCIpline routines." In /sys/eonf/c.e (Appendix A) these routines are outlined under the data structure Iineswll. These If precautions are not taken, the freelist may be exhausted by one process. This is alleviated by defining two marks - a low and high -water mark in tty.h. FREE C_CF C_CL ~ - --1984 Figure 8a. clists - free list and clist for a device notice they pOint not to firstllast character. 2-147 280041-001 AP-.184 I FREE ~ 'I C_CF t-- C_CL r- .IE]- - ~ 1985 Figure ab. When getcO takes last char on first block, the clist structure is returned to FREE LIST. routines are preceded by "tty" or "tt" (Naming Conventions). A summary of these routines is found in tty. help (section 7.2.4). to further establish that XENIX is not lacking in humor! Two queues live to serve the goal of quick and consistent character treatment. Coming back to the tty structure(Appendix H), three queues are identified for use by each terminal interface. Thes~ structures are clists and are: The tty.c (line discipline) routines are invisible to the driver-writer. Once these routines are called, they do most of the work. The queue manipulation and I/O functions are purely interface functions that are not in the driver code . . the output queue . the input queues . the canonical queue (cooked) . the raw queue Three static buffer headers (dist headers) are established in the tty structure for each line. The output queue facilitates output to the terminal using the highllow-water marks as gauge. The raw queue is used as the first input vehicle where all characters input are placed. It is from here that the terminal echo occurs. Notice that echo response is generally quick and is irrespective of whether the requesting process is in or out of memory. The canonical queue is that queue maintained for each line that respects all characters especially those that are dependent on surrounding characters i.e. backspace, delete, character expansion etc. This queue is also called the cooked queue to symbolize a - raw (not raw) queue 2-148 As mentioned before (Section 6.2), the function of any driver can be partitioned into task vs. interrupttime execution. For character device drivers, the task-time portion deals with moving data to/from the user space and the dist queues. This movement (transfer) uses data derived from the users U.-!itructure e.g. u.u_count is decremented on data transfer (no device driver involvement) that is performed by the tty.c routines. The interrupt-time portion of the driver manages the transfer of data between the device and the dist queues (namely, the raw and output queues). 280041-001 AP-184 typed when in cooked mode whereas, in raw, it transfers data immediately. 7.2.3 USEFUL ROUTINES The following are useful kernel routines used by the line discipline routines. Further routines are found in Device Driver Support Routines (section 7.1.2). ttreadO also waits on ttyinputO to function in the interrupt time portion of the device driver. ttwrite (tp) int getc(queue) struct clist *queue; struct tty *tp Returns a character from the c1ist queue or -1 if the queue is empty. The queues are either the raw, canonical or output queues. int putc(c,queue) struct clist *queue; Puts a character "c" on the queue. Returns "0" if the character is placed and "-1" if unable to place in queue. The" -1" returns if gone beyond the highwater mark of the respective clist. 7.2.4 TTY.HELP - THE LINE DISCIPLINE ROUTINES XENIX currently supports one line discipline routines i.e. how to interpret characters on I/O on the line. This line discipline is made up of several routines. They are: ttyopen (dev, tp) Handles a write request. ttwriteO outputs u.u_count characters into the output queue (outq in tty.h) guarding the highllow-water marks. Calls ttyoutputO which places character in output queue adding delays, expanding tabs etc. Calls ttstartO to begin transmitting the character. ttyinput(c, tp) struct tty *tp; char c; Places a character on the raw queue and echoes it if required. This is how input characters are given to the read request. ttyinputO is run at interrupt-time to add "c" to the raw queue identified by "tp." The echo is done by a call to ttstartO to begin character transmittal and a call to ttyoutputO that basically transports characters from the raw queue to the output queue and prepares them for output. ttstart(tp) struct tty *tp; dev_tdev; struct tty *tp; This routine is called by the device driver's open routine: It is given an address of the line's device number and tty structure. Relevant fields in the tty structure are updated and the raw, canonical and output queues are initialized. is called to cause the next byte to be output if the device is idle. It is called by the task-time portion of the driver as well as the interrupt-time portion. ttstartO calls the "xxxstartO" routine in the driver. ttiocomm(cmd, tp, addr, dey) ttyclose(tp) struct tty *tp; All character queues with respect to the respective tty structure are flushed. Relevant fields in the structure are set to "closed." ttread(tp) struet tty *tp; Handles a read request i.e a system call. Details on the input target addresses are found in the u_structure i.e u.u_base, u.u_count etc. This routine obtains data from the. canonical queue and waits, if necessary, for more input. It also calls canon 0 , a routine that transfers characters from the raw input list to the canonical list after processing these lines. Canon 0 basically waits until a full line has been 2-149 intcmd; struct tty *tp; caddLt addr; dev_tdev; Handles common I/O control functions like lineediting, setting line characteristics except baud rates. Consider this call a transfer of input/output control and line characteristic functions to the relevant data structure that holds that information. This routine is called from the xxxioctlO routine of the driver. As mentioned in the discussion on driver interfaces, the file c.c holds all kernel interface data-structures to the main driver routines. The data structure cdevsw[J is the link to the character I/O drivers. This structure maps the main special devices like Idev IttyaO to the actual driver routines. 280041-001 AP-184 7.2.5 TERMINAL I/O DEVICE DRIVER ROUTINES ixxxwrite(dev) Like the read () . Calling sequence: The following routines are typical of a character device driver. The tty.c routines are used as most terminal liD device drivers rely on them. Other drivers for line printers (output only) do not use the tty.c routine as less processing of output is necessary and is simpler. The terminal liD driver-routines are: xenix = = = = > ixxxwriteO = = = = > ttwrite ixxxioctI(~ev, dev_t dev; intcmd; caddct addr; int flag; ixxxinitO This routine initializes the device. It checks to see if the device is alive and sets a flag to remember this. It then prints messages which tells the user interface that it is/is not alive. ixxxopen (dev, flag) Implements the ioctl system call for this line. liD control is used for special functions such as rewinding tapes and the like. In terminal drivers . -------- routine is used to get/set vario aracteristics of the line. A commjln---ffy.c routine used is ttioccomm O. Callingsequence: dev_tdev; int flag; dey is < maj,min > device number. Flag is B':'READ, B_WRITE. Flag may be ignored for tty drivers. Called every time the device is opened. Checks for validity of open, fills out tty structure for the device line. The fields it fills are: cmd, addr, flag) xenix = = = = > ixxxioctlO = = = > ttioccomm ixxxstart (tp) struct tty *tp; 1* ptr to the tty structure • / the startO routine is called by the common tty support routines to start output on the line. The address of this routine is set in the open 0 routine arid this address is kept in the line's tty-structure. This address is picked up by the tty.c routine to initiate action on the device. Typically,if the device is idle, a character is grabbed from the output queue and sent to the device. If the device is busy or no characters are available, the procedure is exited. Calling sequence: Laddr - set the device's I/O address Loproc - set to the address of the device's output start routine Liproc - set to address of start routine for output Lstate - device's state Calls ttyopen. Calling sequence: ixxxopen () = = = = = > ttyopen ixxxclose(dev, flag) at task time: dey and flag are described for ixxxopenO. The routine is called when the last file attached to the device is closed. Calls ttyclose and performs clean-up e.g. flushes pending clists. Calling sequence: xenix = = = = > ixxxcloseO = = = = = > ttyclose xenix = = = > ixxxwriteO = = = > ttwriteO = = = > ttstartO = = = > ixxxstartO at intr time: device = = = >ixxxintrO = = = >ttyinputO = = = >ttstartO = = = >ixxxstartO on input, ixxxread (dev) device = = = >ixxxintrO = = = >ttstartO = = = >ixxxstartO This routine implements the read system call for the line and calls ttread 0 passing it the tty structure for the line. Calling sequence: on output ixxxintrOeveO xenix ====> ixxxrea,dO ======> ttread int type; 2-150 280041-001 inter AP-184 This is the interrupt procedure. Level may be ignored. An input interrupt service routine will call ttinputO while an output interrupt will call ttstartO to begin output of the next character. The ttstartO routine will then call the driver's startO routine. As in block device, the interrupt service routine is called when the device is returning from the busy state to the idle state. ttstartO is called to bring the device back to the· busy state if further output is necessary. Calling sequence: HW!input intr = = = > xenix = = = > ttyinputO HW/output intr = = = = = > ttstartO = = = > ixxxintrO = > xenix = I READ ( ) CALL The following diagram (figure 9) illustrates how 110 occurs in terminal I/O. Before any further detail is tackled, a brief diagram of the calling sequences for the main driver routines is shown also. ixxxstartO (figure 10) is called from both the ixxxintrO /ixxxwriteO routines. 7.2.6 EXAMPLES OF CHARACTER 1/0 (TERMINAL) DRIVERS = = > ixxxintrO Note: These routines are simpler to write due to the tty.c routines. Terminal 110 is a special case of char- I KERNEL -----I acter 110. Other character 110 devices require the same routines i.e. ixxxopenO etc. but cannot rely on the functionality provided by the line discipline routines. I_ D.!!'V.!R-l.I ________ There is no real substitute for actual code. However, in XENIX drivers, code can be a challenge to read and understand. To alleviate long hours, a walkthrough of a roughlywritten driver follows. Another example is found in Appendix I. 2A!!< _ _ _ _ _ READ ( ) I (SYSTEM ~ALL) ~ _ I~T!!'~P~ J I I I I I I I I I I I I I I I I I I I I I TTINPUT () I RECEIVE INPUT I I 1 WRITE ( ) CALL I -~I' 1 I I I 1 1 I I WRITE ( ) I I I --+1--- TTWRITE ( ) - - - - - 1 I I I I I I 1 I TTSTARTt) TRANSMIT OUTPUT ---l.. I I I I I I I I I 1981 Figure 9. Architecture of Lists and Hold the Work. 280041-001 inter USER SYSTEM/DRIVER DEVICE 1982 Figure 10. TerminalI/O Driver Routines. 2-152 280041-001 - inter AP·184 7.2.6.1 iSBXTM 270 Walkthrough 1/" 2 " i270.c - iSBX270 device driver 3" 4 " - implements terminal device driver for the iSBX270 character 5" graphics video display controller 6" 7 • See also: c270.c - i270 configuration i270.h - i270 include files 8" 9" 10 " Notes on this driver: 11 " (1) The driver supports the keyboard interface and display 12" in scroll mode or page mode 13 * (2)AII manual references in the comments are to the iSBX270 14" Video Display Terminal Controller Board Hardware Reference 15 * Manual, order number 143444-001. 16 *f 17 18 #include " ..lhfparam.h" 19 #include " ..lhfuser.h" 20 #include " ..lhftty.h" 21 #include " ..lhIi270.h" 22 i270cfg i270cfg; 23 extern struct 1* configuration structure" f 24 25 short i270-alive; 1* board alive flag" f 26 struct tty i270tty; 1* tty structure *f 27 int c..state; f" state variable used for escape 28 sequences *f 291* 30" i270initO 31 *. - tests for presence of the iSBX270, and reports its presence 32 * or absence 33 * - initializes 270 for the configured modes of operation 34 * - this routine is called very early in the system initialization 35 *f 36 37 i270initO 38 ( 39 short mode; 40 int rststat; 41 421* 43 * The sequence below sends a reset command to the 270. The 44 * algorithm is based on the flowchart, page 3-8 of the manual. 45 * We perform the additional task of determining if the board is 46' present or not. 47 *f 48 c..state 0= 0; 49 rststat = rst270(); 1* reset 270 *f 50 if (rststat = = RSTERR) 51 52 f" 53 * Board not found. 54 "f 55 56 printf("iSBX 270 board port %x NOT found.O, i270cfg.c_data); 57 i270-alive = I270DEAD; return; 58 2-153 280041-001 AP-184 59 } 60 else ( 61 printf("iSBX 270 board port %x found.O, i270cfg.c_data); 62 i270_alive = I270LIVES; 63 } 64 651* 66 • Board lives, so set it up in the configuration specified. 67 • NIMASK is anded with everything to clear any bits which 68 • aren't implemented. 69 • Once we reach this point, we'll assume that the board is 70 • alive to some extent, so we'll just concern ourselves w.th 71 * getting through the initialization; but we can't afford to 72 • get hung up if the firmware is acting funny. Our approach 73 * will be to protect ourselves against infinite loops, but not 74 * check for error conditions or worry about reporting them. 75 *1 76 77 mode = (i270cfg.c_keybrd Ii270cfg.clpen Ii270cfg.cdma I 78 i270cfg.cmode IIBEINT I(i270cfg.c_cursor & CURMSK)) 79 &NIMASK; 80 mode270(mode); 81 } 82 831* 84 • rst2700 - resets the 270 board 85 *1 86 87 rst2700 88 ( 89 unsigned i; 90 91/* 92 * Clear out any garbage in input and output buffers. 93 * i is a safety valve in case the board is not here and 94 * we read a 1 in the IBF bit - we'll take care of the 95 • presence or absence of the board later - for now we just 96 * need to get out of this loop. 97 *1 98 99i = 0; 100 while «in-270(i270cfg.cstat) & I270IBF) && 0+ + < 30000)) ( 101 if (in_270(i270cfg.c_stat) & I2700BF) 102 in_270(i270cfg.cdata); 1* dummy data *1 103 } 104 ouL270(i270cfg.cstat, I270RST); 1* reset it *1 105 1061* 107 * We'll look for some sign oflife from the 270. If 108 • it's not there, we'll either blow right through the 109 • loop, or get stuck in it forever. We'll limit 110 * forever to 30000 iterations, and check for a count of 111 * 0 or > 30000 upon terminating the loop - either one is 112 • then interpreted as a sign that the board isn't here. 113 *1 114 115 i = O· 116 while' «in-270(i270cfg.c_stat) & 117 (I2700BF II270IBF II270BUS)) && (j + + < 30000)) ( 118 if (in_270(i270cfg.cstat) & 12700BF) 2-154 280041-001 AP-184 119 in-270(i270cfg.c--"ata); 1* dummy input */ 120 } 121 if((i = = 0) I (i > 30000» return RSTERR; 122 else return RSTOK; 123} 124 125/* 126 * mode270(mode) - sets VOTC mode for 270 board to specified mode 127 */ 128 129 mode270(mode) 130 short mode; 13l{ 132 unsigned i; 133 134/* 135 * First, go into null busy wait until we can stick another 136 • command into the input buffer - once again, i is used as 137 * an escape in case the firmware on the 270 is acting goofy. 138 *f 139 i = O' 140 while' ((in_270(i270cfg.c...stat) & I270IBF) && (i+ + < 30000»; 141 1421* 143 * Now we can issue a new command - we do a set VOTC mode. 144 *f 145 146 ouL270(i270cfg.c...stat, I270SM); 147 1481* 149 * Wait until the 270 can accept the parameter. 150 *f 151 152 i = O' 153 while' (((in-270(i270cfg.c_stat) & 154 (I2700BF II270IBF II270BUS» ! = I270BUS) && (i+ + < 30000» ( 155 if (in-270(i270cfg.c...stat) & I2700BF) 156 in-270(i270cfg.c_data); 1* dummy input ifOBF set *f 157} 158 ouL270(i270cfg.c_data, mode); 159} 160 1611* 162 * i270open(dev) - opens dev 163 *f 164 ' 165i270open(dev) 166 dev_t dey; 167 ( 168 int unit, i270startO; 169 struct tty *tp; 170 1711* 172 • First check to make sure that board is alive - if not, 173 * mark error and return. 174 *f 175 176 if (i270....alive == I270DEAO) { 177 u. u_error = ENXIO; 1* no such device or address *f 178 return; 2-155 280041-001 AP-184 179 } 180 1811* 182 ° tp will point to the tty structure 183 *f 184 185 tp = &i270tty; 186 1871* 188 ° Check for 270 already being exclusively opened 189 of 190 191 if «tp->Lstate & XCLUDE) && u.u_uid) { 192 u.u_error = EBUSY; 193 return; 194 } 195 1961* 197 ° Set up fields in tty structure. *' 198 199 200 tp->Laddr = (caddr_t)i270cfg.c_data; io base address 201 tp- > Loproc = i270start; 1* routine to start output 202 203 204 * If this is first open ... *' *' r ,* *' 205 206 207 if «tp- > Lstate & ISOPEN) = = 0) { 208, ttychars(tp); sets special characters 209 tp-> Lispeed = tp->Lospeed = 9600; 1* baud rate meaningless 210 tp- > Lflags = ODDP 1EVENP 1ECHO 1CRMOD; 1* should add no 211 tab expansion here 212 } 213 tp->Lstate 1= CARR_ON; 214 ttyopen(dev, tp); 215 } 216 r 0, *' 0, 2171* 218 * i270close(dev, flag) 219 220 221 i270close(dev) 222 dev_t dey; 223 ( 224 struct tty °tp; 225 226 tp = &i270tty; 227 ttyclose(tp); 228 tp- >Laddr = (caddr_t) 0; 1* forget base address *, 229 } 230 231i270read(dev) 232 dev_t dey; 233 ( 234 struct tty °tp; 235 236 tp = &i270tty; 237 ttread(tp); 238} 0, 2-156 280041-001 inter AP-184 239 240 i270write (dev) 241 dev_t dey; 242 ( 243 struct tty *tp; 244 245 tp = &i270tty; 246 ttwrite(tp); 247 ) 248 249 i270iintr(JeveI) 250 int level; 251 ( 252 struct tty *tp; 253 short status, chr; 254 255 tp = &i270tty; 256 status = inb(i270cfg.c-stat); 257 chr = inb(i270cfg.cdata); 258 if (status & I270KDR) 259 ttyinput(chr, tp); 1* only if a valid keyboard hit *f 260 ) 261 262 i270ointr(JeveI) 263 int level; 264 ( tty *tp; 265 struct 266 267 tp = &i270tty; 268 if (tp- > Lstate & BUSY) ( 269 tp- > Lstate & = - BUSY; ttstart(tp); 270 271 if «tp-> Lstate & ASLEEP) && 272 (tp-> Loutq.c_cc < = TTLOWAT» 273 wakeup«caddLt)&tp-> Loutq); 274 ) 275 } ttrstrtO; 276 int 277 extern char par tab []; 278 279 i270start(tp) 280 struc( tty *tp; 281 ( 282 int e,s; 283 short mode; 284 285 s = sp150; 286 if (tp-> Lstate & (TIMEOUT IBUSY» ( splx(s); 287 return; 288 289 } 290 if «c=getc(&tp->Loutq» >= 0) ( 291 tp->Lstatel= BUSY; 292 splx (s); 293 switch (c-state) ( 294 case 0: 295' if(c==Oxlb)( 296 #ifdefDEBUG printf("O %xO, c); 297 298 #endif 2-157 280041-001 inter AP-184 299 outb(i270cfg.c_data, c); 300 c-state = 1; 301 J 302 else if (c == Oxll) ( outb(i270cfg.c_data, c); 303 304 c-state = 8; 1* graphics leadin 305 I 306 else if «tp->Ulags & RAW) I (c < = Ox7f)} outb(i270cfg.c_data, c); 307 308 else ( 309 tp- > Lstate 1= TIMEOUT; 310 tp-> Lstate &= - BUSY; timeout(ttrstrt, (caddU}tp, (c & Ox7f»; 311 312 return; 313 J 314 break; 315 case 1: switch (c) 316 case '=': 317 318 1* cursor address sequence 319 #ifdefDEBUG printf("O %xO, c); 320 321 #endif outb(i270cfg.c_data, 0); 322 323 c-sta te = 2; break; 324 case 'G': 325 326 1* visual attribute sequence "' 327 #ifdefDEBUG printf("O 00000); 328 329 #endif 330 outb(i270cfg.c_data,0); 331 c_state = 3; 332 break; 333 case 'M': 334 1* change mode sequence 335 outb(i270cfg.c_data, 0); 336 c-state = 6; 337 break; 338 default: 339 1* regular escape sequence 340 #ifdefDEBUG printf("O %xO, c); 341 342 #endif outb(i270cfg.cdata, c); 343 c-state = 0; 344 345 break; 346 J 347 break; 348 case 2: 349 #ifdefDEBUG printf("O %xO, c); 350 351 #endif 352 outb(i270cfg.c-stat, I270SCP); 353 c_state = 4; 354 break; 355 case 3: 356 #ifdefDEBUG 357 printf("O %xO, cPx80); 358 #endif *' *' *' *' 280041-001 inter 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 AP-184 outb(i270cfg.c_data, «c & Ox30 IOx80»; c_state = 0; break; case 4: outb(i270cfg.c_data, (c - Ox30»; c-state = 5; break; case 5: outb(i270cfg.c_data, (c - Ox30»; c-state = 0; break; case 6: outb(i270cfg.c_stat, 1270SM); c-state = 7; break; case 7: mode = (i270cfg.ckeybrd Ii270cfg.c.Jpen I i270cfg,cdma Ii270cfgLmode I IBEINT I(i270cfg.c_cursor & CURMSK» &NIMASK; mode = (mode & Ox3f) I «c - Ox30) < < 6); outb(i270cfg.cdata, mode); c_state = 0; break; case 8: 3841* * just output character and go back to state 0 385 * nothing special, just didn't want to flip into a 386 * special mode as a result of this graphics character 387 *f 388 outb(i270cfg.cdata, c); 389 c_state = 0; 390 break; 391 392 393 I 394 else splx (s); '~§~ I 397 i270ioctl(dev, cmd, addr, flag) addr; 398 caddLt 399 ( *tp; 400 struct tty 401 tp = &i270tty; 402 if (ttioccomm (cmd, tp, addr, dev» ( 403 404 1* 405 * No ioctl functions supported 406 *f 407 408 409 else u.u_error = ENOTTY; 410 I 411 412in-270(port) 413 unsigned port; 414 ( 415 unsigned i; 416 417( for (i=0; i < DELAY270; i+ +); 418 return (short) inb(port); 2-159 280041-001 AP-184 419} 420 ouL270(pori, val) 421 unsigned port; 422 short val; 423 ( , 424 unsigned i; 425 426 for (i=0; i < DELAY270; i+ +); 427 outb(port, va!); 428 } 7.2.6.2 Low Level Routines The following routines are not required but were built for clarity and in accordance with structured methodology. The routines are: in_270-line 412 ouL270-line 420 rst270-line 87 mode270-line 129 Details of the calling sequences for these routines and others are found in figure 11. CO,nsider the procedures inJ70 (412) and ouL270 (420). These routines are just the in and out routines of the kernel with a constant delay in front, and are used only at boot time. This implies that DELAY270 times the execution time of a for loop is lost for every byte transfer (at boot time) to/from the 270 controller, and that the constant DELAY270 must be fixed every time the kernel is ported to a new cpu. These routines would make sense if the 270 required requests to be a certain time interval apart, and the author of the driver could not guarantee that the commands'to the 270 would be far enough apart any other way. It would also need to be checked that DELAY270 iterations took less than 100 microseconds, to insure interrupt latency was not adversely affected when these routines were called at a high cpu priority during interrupt service. rst270 (87) resets the 270 controller. It begins by reading the status register of the controller. If the input buffer is full (I270IBF), the 270 cannot accept another command (even the reset), so if the data buffer is full, a data byte is read to make room in the 270 hardware's buffer. Once the input buffer of the 270 is no longer full, it is sent a reset command. The variable 'i' is used to insure that if the 270 is not present, this loop will execute at most 30,000 times. Once the reset command is sent, it should be acted upon by the controller. We enter another loop, similar to the first, which is designed to' check the existence of the 270 controller. The controller exists if it is now unable to receive input (270IBF), ready to send to the cpu (I2700BF), or busy doing something (perhaps, but not necessarily, the reset). If it is none of the above, the loop will execute zero times. Note that it is possible that the 270 is not there and that garbage is being read from where the status register would have been. There is code here that assumes that if after 30,000 tries, the controller does not return to an idle state, garbage is being read. Note again that the use of a constant number of iterations to represent an interval of time is bad practice since it implies assumptions about the execution speed of the cpu, which will vary. Mode270 (129) is a routine similar to rst270, but designed to set the initial mode of the controller after the controller is reset. First the driver waits until the controller is ready to receive the command (or 30,000 tries). Note that this means the controller must become ready within 30,000 executions of an inJ70 to accept the mode change command. This is why there is a delay in inJ70, but this is still bad practice, since it is cpu dependent code. The 'set mode' command is sent, and a wait is done until the controller can accept the new mode, then the new mode byte is sent to the controller. The code to do this wait ensures that 'while the controller is busy and has input or output flush any input from it'. It shOuld be noted that this is acceptable because this routine is called only by i270init at boot time. If mode270 were called during normal system operation, this input would be meaningful and therefore would need to be processed. It is not clear that this loop will succeed in flushing all input generated' while the 270 was in the previous mode, raising the possibility that garbage typed before a reboot will remain in the 270's buffers. 7.2.6.3 Required Routines i270init (37) is called at boot time to be sure the 270 controller is ready to use, and is the only reference to the routines described above. First, rst270 is called to see if a 270 exists (49, 50). If not, a diagnostic is printed, and the fact there is no 270 controller is remembered (56, 57). If the 270 controller exists, it is set for a standard mode modulo NIMASK, which insures the controller is not placed in an unimplemented mode (77-80). This is also the place where interrupts from the 270 are enabled (78). i2700pen (165) is called for every open of the 270 device. In line 176 ensures that if the 270 controller was not found at boot time, all opens will fail with a 2-160 280041-001 inter AP-184 o KEY iIII111IIo. DRIVER WRITER ROUTINES 'fiII/IV (NOT REQUIRED) DRIVER ROUTINES 0> ~ PROTOCOL ROUTINES '--'" TTY.C KERNEL ROUTINES 1980 Figure 11. iSBXTM 270 Video Terminal Controller Board Driver Routine Dependancies Calling Sequences. 'nonexistent device' (ENXIO). Line 185 sets up a pointer to the status record for the device. If the device has an active exclusive open, line 191 arranges an open failure with a busy return. Line 201 sets a pointer for use by the protocol routines to start output. Line 207 arranges that the 270 looks to the kernel like a 9600 baud terminal with characteristics suited to the device. Line 213 sets a flag to note the device is open for later. Note that ISOPEN is set by ttyopen. 2-161 i270close (221) is called on the last close of the device. It just calls the protocol routine ttyclose, then removes the I/O address of the 270 from the tty structure. i270read (231) and i270write (240) respond. to reads and writes by simply calling the protocol routines 'ttread' and 'ttwrite', respectively. 280041-001 AP-184 i270iintr (249) responds to an input interrupt by simply getting the character, and calling the protocol routine 'ttyinput' with it if' it caqte from the keyboard. i2700intr (262) responds to an output interrupt by checking if there was output in progress. If so, line 269 c1earsthe BUSY flag (in case there are no more characters to output). The protocol routine 'ttstart' wilI send the next character and set BUSY if there is more output to do. If a process is sleeping because the output queue was at the high water mark, and the queue is now below the low water mark, all such processes are awakened(271-273). i270start (279) is called after output interrupts and by the protocol routines to initiate output to the 270. This routine sets a cpu priority high enough to prevent reentrancy problems caused by the fact it can be called by interrupts (285). The high cpu priority is used to insure the BUSY bit does not change, so that it may be used as a lock to prevent more than one flow of control from getting into the switch statement of line 293. Once this lock is obtained, the cpu priority is lowered. The interrupt priority should remain raised for no more than the 100 microsecond. If the driver is doing output, this routine will return(Iine 286). It is necessary that all paths out of this routine lower the cpu priority (note lines 287, 292, and 394) within the time constraint. Line 290 uses the 'getc' routine to get the next character from the output c1ist. The way interrupt driven output to tty devices is performed is by maintaining the output portion of the terminal in one of two states (idle or BUSY). In the idle state the device is ready to receive a character for output, and in the BUSY state a character has been sent to the device and the device has not yet signaled (via an output -interrupt) that it is finished initiating. the output. Output interrupts do not necessarily signal that the character has been output, only that the output has been started and the output device is ready to accept the next output character. A call to i270start, then should force the terminal into the BUSY state except in the case that the output c1ist is empty (lines 290 and 394). At the next output interrupt the terminal goes from BUSY to idle (line 269), and protocol routine ttstart calls the appropriate start routine (set by line 201 to be i270start) to attempt to put the device back into the BUSY state. A major reason for the bulk of this routine is that it maintains a finite state machine which controls the disposition of characters sent to the 270. This machine implements certain escape sequences which do device control operations. Some of these device control operations cannot be done by writing to the data port, and so require special code. There is also code implementing an escape for graphic attribute bytes which prevents them from being mistaken for device control escape sequence lead ins. A state transition diagram, shown in figure 12, details the control character sequences and other input sequences expected by the device. The code for the default treatment for most characters is in state 0 at lines 306 and 307. Characters with the high bit set (non-ASCII characters) are used to implement a timed delay at lines 308 through 313. If this state is not cleared, the driver will hang. The code at lines 295 through 301 implement a transition to state one in the event an escape character is written to the 270. The graphic attribute escape is in state 0 at lines 302 through 305 and in state 8 at lines 383 through 392. An escape is followed by a character which determines which escape sequence is involved. At state 1 lines 317 through 324 we see a transition to state 2 if a cursor motion sequence (<: ESC> =) is found, , after sending an ASCII NUL to the 270 controller to abort the escape sequence. State 2 sends a set cursor position (I270SCP) command to the status port and sends us to state 4 (Jines 352 and 353). State 4 then sends a data byte minus an ASCII '0' (the X axis position), and sends us to state 5 (lines 363 and 364). State 5 then sends another data byte minus an ASCII '0' (the Y axis position), and sends us back to state 0 (Jines 367 and 368). State 1 lines 325 through 332 abort the escape sequence and move to state 3 to implement a 'set attributes' «ESC> G) command. State 3 sends the character after masking it to insure a valid attribute byte (Jine 359), the returns to state O. State 1 lines 333 through 337 abort the escape sequence and move to state 6 to initiate a 'set mode' command. State 6 sends a 'set mode' to the controller's status port and moves to state 7 (Jines 371 and 372). State 7 shifts the output byte's low bit into the 'page mode' bit, sends the new mode to the data port and returns to state 0 (Jines 375 through 38J). Note that an M sequence followed by a character other than an ASCII '0' or '1' is not guaranteed to result in a valid mode. The remaining state 1 code (Jines 338 through 347) implement the default action, which is to send the escape sequence on to the device and return to state zero. Note that this works because no 270 hardware escape sequence is over two characters (the escape and the command). Longer escape sequences would probably need a protection similar the protection by state 8 of attribute bytes, to prevent them from being mistaken for lead-in characters. If all escape sequence support were implemented by the device via the data port, as is the case for terminals on a serial 'line, none of this state machine logic would be appropriate. 2-162 i270ioctl (379) is called to respond to every ioctl issued to the 270. It responds by using tlie protocol routine 'ttioccomm' to process al) terminal ioctls, and rejecting all others since the board does not sup. port baud rates. 280041-001 AP-184 ESCAPE SEQUENCE GRAPHIC CHARACTER 1979 Figure 12. State Transition Diagram for iSBXTM 270 Terminal Controller Board. Used by the Driver. 7.2.6.4 A Final Note This walkthrough has detailed the required routines, their subtleties as well as their interactions with the line discipline routines ( protocol routines). The iSBX 270 Video Terminal Controller Board driver is only in draft form ( it works!) and is not an example oflntel Corporation's coding methodology. CONCLUSIONS Now the clouds should have cleared around the XENIX Operating System and device driver writing. Insight is but one aspect of the challenge of writing device drivers. It is premature to call it a trivial task. The task of writing one is simple but the task of debugging, testing and completing one demands respect. Device driver writers have the pow~r to do almost anything with the operating system especially crash it! This power can be extremely difficult to adjust to at the tender age of a "XENIX user." However, this discussion has briefly covered 2-163 definitions, the 1/0 environment, the representative driver routines and code walkthroughs. In attacking the device-driver writing issue, there is difficulty in approaching the subject with any stepby-step logical flow with a top-down methodology. Hence, imagine the entire learning environment of device drivers to be a circle. This discussion joins the circle at anyone point, follows it and embraces the entire concept of device driver writing for the XENIX 286 and 86 Operating System. With this circle relatively filled, by this discussion, the task of writing device drivers may still be more a task than trivia but will be more a challenge than a chore! . 280041-001 AP-184 APPENDIX A: THE c.c FILE CREATED BY MASTER AND XENIXCONF ................................................ . APPI=NDIX B: XENIXCONF ................................... .. APPENDIX C: THE CONFIGURATION FILE MASTER ..................................................... . APPENDIX D: INTERRUPT MAPPING ...................... . APPENDIX E: param.h FILE THAT LISTS THE . SYSTEM CONSTANTS ........................ : ............... . APPENDIX F: THE buf.h FILE DESCRIBING THE BUFFER-HEADER STRUCTURE ........................... . APPENDIX G: NAMING CONVENTIONS .................. . APPENDIX H: THE tty.h FILE DESCRI~ING THE TTY STRUCTURE ................................................ . APPENDIX I: THE c254.c AND i254.h FILES ............ . APPENDIX J: THE iSBC® 534 ................................ .. 2-164 280041-001 AP-184 APPENDIX A: THE C.C FILE CREATED BY MASTER AND XENIXCONF /* * Conf1guration information */ #def1ne #define #def1ne #define #def1ne #deflne #def1ne #def1ne #def1ne #deflne #def1ne #def1ne #define #def1ne #define #def1ne #deflne NBUF 29 NINODE NFILE NMOUNT SMAPSIZ NCALL NPROC NTEXT NCLIST NFLOCKS MAXUPRC TIMEZONE NCOREL DSTFLAG GENBOOT CMASK MTOP 612 #1nclude #1nclude #include #lnclude #1nclude #1nclude #1nclude #1nclude #1nclude #1nclude #1nclude #1nclude #include #1nclude #lnclude #lnclude #lnclude #lnclude · ... /h/param h" " .. /h/buf .h" • .. ./h/tty. h" ". /h/conf.h" " .. /h/proc.h" · ... /h/text. h· " . ./h/dlr.h" .... /h/a out.h" • ... /h/user h" ./h/flle h" " . ./h/1node h" · ... /h/acct. h· /h/mmu.h" · ... /h/map. h' · .. ./h/ callo. h" " .. /h/mount h" .. /h/var h" " .. /h/clist.h" 120 120 8 (NPROC/2) 26 100 40 160 100 16 (8*60) 1 1 o o extern nodev(), nulldev(), novec(); int int int int int 1nt clockO; dbgintrO; 1544intr(); 12161ntr(); 174intrO; IplntrO; 1nt (*vecintsw[])() { clock, dbgintr, novec, 15441ntr, novec, 12161ntr, 1741ntr, 2-165 280041-001 i~ }; AP·184 novee, novee, novee, novee, novee, Dovee, Dovee, novee, novee, novee, novee, Dovee, Dovee, novee, novee, novee, novee, novee, Dovee, novee, novee, novee, novee, novee, novee, novee, Dovee, novee, novee, novee, Dovee, novee, novee, novee, novee, novee, novee, novee, novee, novee, novee, Dovee, novee, Dovee, novee, novee, novee, Dovee, Dovee, novee, novee, novee, novee, novee, novee, novee, novee, novee, novee, novee, novee, novee, novee, novee, Ip1nt.r, .,' / ext.ern 1216open(), 1215elose(), 12161nlt.(), 1216read(), 1215vr1t.e(), i2161oet.l(), 1215.st.rat.egyO, 1215t.ab; ext.ern 1644open(), 1644elose(), 16441n1t.(), 1644read(), 1644vr1t.e(), 15441oet.l(); ext.ern 1740pen(), 174elose(), 1741nlt.(), 174read(). 174vrlt.e(). 1741oet.l(); 2-166 280041-001 AP·184 extern Ipopen(), lpclose(), Iplnlt(), Ipwrlte(); extern mmread(), mmwrlte(); extern syopen(), syread(), sywrlte(), syloctl(); bdevsw bdevsw[]= struct { 1* 0*1 l2150pen, l215close, l215strategy, &1215tab, struct cdevsw cdevsw[] = }; { 1* 1* 1* 1* 1* 1* }; 0*1 1*1 2*1 3*1 4*1 5*1 int int 12150pen, syopen, nulldev, l544open, l74open, lpopen, nblkdev= nchrdev= l215Close, nulldev, nulldev, 1544close, l74close, Ipclose, l215read, syread, mmread, l544read, l74read, nodev, 1215wr1te, sywr1te, mmwrlte, 1544wr1te, 174wrlte. Ipwr1te, 12151octl, sy1octl, nodev, 164410ctl , 1741octl, nodev, nulldev, nulldev, nulldev, nulldev, nulldev, nulldev, 0, 0, 0, 0, 0, 0, 1; 6; rootdev= makedev(O,l); dey t dev-t pipedev= makedev(O,l); dev-t swapdev= makedev(O,2); dadQr t swplo= 1; 1nt nswap= 1180; (*d1nitsw []) 0 = lnt { 12151n1t, 16441n1t, 1741nit, Ipln1t, (int (*) 0)0 }; 1nt ttyopen(), ttyclose(), ttread(), ttylnput(), ttstart(); char *ttwrl te 0 ; struct 11nesw 11nesw[]= { 1*0*1 o ttyopen, ttyclose, ttread, ttwr1te, nodev, tty1nput, nulldev, nulldev, ttstart, nulldev, }; 1nt 1nt 1nt 1nt 1nt nld1sp::: 1; Tlmezone=TIMEZONE; Dstflag=DSTFLAG; Genboot=GENBOOT; Cmask=CMASK; struct but but[NBUF]; char buffers [NBUF] [BSIZE+BSLOP); Struct flle f11e[NFILE); struct lnode 1node[NINODE); struct lockl1st lockI1st(NFLOCKS); struct proc proc[NPROC); struct text text[NTEXT); struct map swapmap[SMAPSIZ) struct callo callout[NCALL) struct cblock cfree[NCLIST) struct mount mount[NMOUNT); struct var v= { NBUF, 2-167 280041-001 }; NCALL, NINODE, (char *)(11node[NINODE). NFILE. (char *)(lfile[NFILE]). NMOUNT. (char *)(lmount[NMOUNT]). NPROC. (char *)(lproc[NPROC). NTEXT. (char *)(ltext[NTEXT). NCLIST. MAXUPRC, NFLOCKS short mm free = 0; short mm-nfree = 0; short mem_top = MTOP; 2-168 280041-001 Ap·184 APPENDIX B: XENIXCONF The following file establishes the selected and conf1gured into the system. ** devices to be Dev1ces *i216 1 *1634 1644 174 *1270 lp *sm 1 debug *fd 1 1 1 1 1 1 1 1 *1287 root p1pe swap 1216 1 1216 1 1216 2 1 1180 ** Local parameters *t1mezone (8*60) daylight 1 0 cmask •* Tunable Parameters * Dont change * bufters 29 procs mounts 1nodes fUes c11sts locks maxproc mem_top them unless you're sure you know what you're do1ng! 100 8 120 120 160 100 16 612 2-169 280041-001 inter AP-184 APPENDIX C: The configuratlon !!~-Master ** The follo~ing devices are those that can be specified in the system * description file. The name specified must agree ~ith the name shown *name vsiz msk typ hndlr'na bmaj cmaj # na vecl vec2 vec3 vec4 * 1 2 3 4 5 6 7 8 9 10 11 12 13 14 i215 2 0137 014 1215 0 0 0 2 -1 0005 0 0 Oa fd 0 0137 014 fd 0 6 6 1 -1 0 0 0 Oa i534 2 0137 004 i534 0 0 1 1 -1 0002 0 0 Oa i544 2 0137 004 1544 0 0 3 1 -1 0003 0 0 Oa i74 2 0137 004 i74 0 0 4 1 -1 0006 0 0 Oa i270 2 0133 004 i270 0 0 7 1 -1 01060 ,0 0 Oa sm 0 036 010 sm 0 1 0 1 -1 0 0 0 Oa Ip 2 0132 004 Ip 0 0 5 1 -1 0107 0 0 Oa debug 2 0 0 dbg 0 0 0 1 -1 0001 0 0 Oa slave7 2 0 0 sl 0 0 0 1 -1 0007 0 o Oa i287 2 0 300 i287 0 0 0 -1 0008 0 o Oa ** The following devices must not be specified in the system description * file. They are here to supply information to the config program. * memory tty $$o o 06 0324 027 0324 mm sy o o -1 -1 o o 2 1 o o o o o o o o ** The following is the line discipline table *tty ttyopen ttyclose ttread ttwrite nodev ttyinput nulldev nulldev' ttstart nulldev$$$$** The following entries form the alias table. *i215 i534 sm disk serial sim$$$

**

The following entries form the tunable parameter table.
*
buffers NBUF
50
inodes NINODE 100
files
100
NFILE
mounts NMOUNT
8
swapmap SMAPSIZ (NPROC/2)
calls
NCALL 25
procs
NPROC 60
texts
NT EXT 40
clists NCLIST i50
NFLOCKS 200
locks
maxproc MAXUPRC 15
tlmezone TIMEZONE (8*60)
pages
NCOREL 1
dayllght DSIFLAG 1
genboot GENBOOT 0
mem_top
MIOP 512

2-170

280041-001

AP-184

APPENDIX D:
.!E.terrupt

~E..g

Interrupts are not vectored directly to the interrupt
routIne procedure of a drIver. Rather, the interrupt is vectored inot part of the Xenix kernel. The kernel code takes
care of playing with the 8259A PIC, setting up an appropriate interrupt mask, switching to the kernel map and stack
for the process, saving and restoring registers and handline
scheduling semantics The outcome to this in that the interrupt routine can be written in C. Xenix handles the other
details
The interrupt model is one of multiple levels of priorities. An interrupt is unique in priority and can be served
only if it higher(smaller in numerical form) than the
current interrupt level
The SPl~() command is used to lock out other interrupts
which are
ower in priority (i.e.  1
SIGINT 2
SIGQUIT 3
SIGINS 4
SIGTRC 5
SIGIOT 6
SIGEMT 7
SIGFPT 8
SIGKIL 9
SIGBUS 10
SIGSEG li
SIGSYS i2 •
SIGPIPE 13
SIGCLK 14
SIGTRM 16
SIGFN

because they are

llangup *1
interrupt (rubout) *1
quit (FS) *1
illegal instruction *1
trace or breakpoint *1
iot *1
emt *1
float~n~ exceDtlon *1
kill, uncatchable termination *1
bus error *1
segmentation violation *1
bad system call *1
end of pipe *1
alarm clock *1
Catchable termination *1
16
1* function key *1

1*
1*
1*
1*
1*
1*
1*
1*
1*
1*
1*
1*
1*
1*
1*

fundamental constants of the implementation-cannot be changed easily

2-172

280041-001

inter

AP·184

#define NBPW
sizeof(int)
1* number of bytes in an integer *1
#define BSIZE 1024
1* size of secondary block (bytes) *1
1* BSLOP can be 0 unless you have a TIU/Spider *1
#define BSLOP 4
1* In case some device needs bigger buffers *1
#define NINDIR (BSIZE/sizeof(daddr t»
1* BSIZE-l *1
#define BSHIFT 10
1* LOG2(BSIZE) *1
1* NINDIR-l *1
#define NSHIFT 8
1* LOG2(NINDIR) *1
#define
INOPB
(BSIZE/sizeof(struct dinode» 1* # inodes per block *1
#define
LINOPB
4
1* LOG2(INOPB) *1
#define NULL
0
1* default mask for file creation *1
#define NODEV (dev t)(-I)
#define ROOTINO «ino t)2)
1* i number of all roots *1
#define SUPERB «daddr t)l)
1* block number of the super block *1
#define DIRSIZ 14
- 1* max characters per directory *1
#deflne NICINOD 100
1* number of superblock lnodes *1
#define NICFREE 100
1* number of superblock free blocks *1
1* #define INFSIZE 138
1* size of per-proc info for users *1
#define CBSIZE 6
1* number of chars in a clist block *1
#define CROUND 07
1* clist rounding: sizeof(int *) + CBSIZE - 1*1

1*

* MMU parameters.

*1

#define
#define
#define
#define
#define

MMPGSZ 2048
LMMPGSZ 11
NPAGEPS 32
NSEG
0
MMFRAGMENTS

1*
1*
1*
1*

bytes/page 1n the MMU *1
log2(MMPGSZ) *1
There are 32 pages in a segment *1
max seg 1 user (see user.h) *1
256 1* mamlmum number of free segments *1

1*
* Some macros for units conversion
*1
1* pages to disk blocks */
#define ptod(x) «x) * (MMPGSZ/BSIZE»

1* bytes to diSk blocks */
#define btod(x)

«(x)+(BSIZE-l»»BSHIFT)

/* lnumber to disk address */
#define Itod(x) (daddr_t) «(unsigned) (x) + (INOPB+INOPB-l»»LINOPB)

/* inumber to disk offset */
#define itoo(x) (lnt)«(x)+(INOPB+INOPB-l»~(INOPB-l»

1* pages to bytes */
#define ptob (x) «x) «LMMPGSZ)
1* bytes to pages */
#deflne btop(x) «(unsigned) (x) + (MMPGSZ-l»»LMMPGSZ)
1* bytes to page number */
#deflne btopn (x) « (unsigned) (x» »LMMPGSZ)
1* page to address */
#deflne ptoa(x) «(long)(x)«

LMMPGSZ) )

1* address (long (32 bit» to page number (lnt)*1
#deflne atopn(x) «int) «(long) (x»»LMMPGSZ»
.1* address (long (32 bit»
#define atop(x)

to page count (1nt)*1
«int) «(long) (x)+(MMPGSZ-l»»LMMPGSZ»

1* address (long (32 bit» to offset (int) get bits LMMPGSZ-l - 0 *1
#define atoo(x) «int) «x)AI;(MMPGSZ-l))
1* long address to short address (get low 16 bits of long address */
#define atos(x) «int)( (x) AI; OxOOOOFFFF»
2-173

280041-001

AP-184

1* long address to short address (get low 16 bits of long address *1
#define atoh(x) «int)( (x) » 16»·
1* page number to long *1
#define ptol(x) «(long) «(tnt) (x» «LMMPGSZ)
1* major part of a device *1
#define maJor(x)
(int) «(unsigned) (x»>8»
1* minor part of a device *1
#define minor(x)

(int) «x)l0377)

1* make a device number *1
#define makedev(x.y)
(dev_t) «x)«8 I (y»
1* extract low word of long *1
#define

LOWORD (x)

.

«int) x)

1* extract high word of long *1
#define

HIGHWORD(x)

«int) «long)x »

16»

1* 8086 base from an absolute physical address *1

#define

base86 (x) «short)(x»4»

typedef struct { int r[1]; } *
typedef struct { unsigned short off;
unsigned short seg;} segadr;
typedef long
typedef char *
Ino t;
typedef unsigned short
time t; typedef long
label t[5];
1* return. sp. si. di. bp *1
typedef int
dev t;
typedef lnt
typeclef long
off=t;

1*

* Machine-dependent

bits and macros

*1

.4efine
.4efine
.4eflne

USERHODE(~s)

OxOO

CLKONLY(ps)

1* OxCO ==> SM on On-Board USART *1
«ps)l03 == 03)
«ps)lOX8000) 1* 1010 --- PLB *1

280041-001

AP-184

APPENDIX F:
The

~

•
•
•
•
•
•
•
•
•
•
•
•
•
•

•
•
•
•

file describing the buffer-header

buf.~

~~ructure

/

Each buffer in the pool is usually doubly linked into'.! lists:
the device with which it is currently associated (al~ays)
and also on a list of blocks available for allocation
for other use (usually).
The latter list is kept in last-used order. and the two
lists are doubly linked to make it easy to remove
a buffer from one list when it was found by
looking through the other.
A buffer is on the available list. and is liable
to be reassigned to another disk block. if and only
if it is not marked BUSY. When a buffer is busy. the
available-list pointers can be used for other purposes.
Kost drivers use the forward ptr as a link in their liD
active queue.
A buffer header contains all the information required
to perform liD.
Kost of the routines which manipulate these things
are in bio.c.

·1

struct but
{

};

int b flags;
1* see defines below *1
structbut *b forw;
1* headed by d tab of cont c *1
1* • *1
struct
buf *b-back;
struct
buf *av forw;
1* position on free list. *1
struct
buf *av-back;
1*
if not BUSY*I
dev t
b dev; 1* major+minor device name *1
unsIgned b_ocount;
1* transfer count *1
union {
1* always points to buffer area *1
1* as low order core address *1
1* as words for clearing *1
int *0 words;
struct-filsys *b filsys;
1* as superblocks *1
struct dinode *b-dino;
1* as iUst *1
1* as indirect block *1
} bun; dadar t
b blkno;
1* block # on device *1
char 0 xmem;
1* high order core address *1
char b-error;
1* returned after liD *1
unsignid int b_resld;
1* bytes not transferred after error *1
unsigned int b_cylin;
1* cylinder number for disk i/o queue *1

extern struct buf buff];
extern struct buf bfreelist;

,.
*

*1

1* The buffer pool itself *1
1* head of available list *1

These flags are kept, In.b_flags.

#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define

B WRITE
o
01
B-DONE
02
B-ERROR
04
B-BUSY
010
B-PHYS
020
B-MAP
040
B-WANTED 0100
B-AGE
0200
B-ASYNC
0400
B-DELWRI 01000

1*
1*
1*
1*
1*
1*
1*
1*
1*
1*
1*

read when liD occurs *1
transaction finished *1
transaction aborted *1
not on av forw/back list *1
Physical TO potentially using UNIBUS map *1
This block has the UNIBUS map allocated *1
issue wakeup when BUSY goes off *1
delayed write for correct aging *1
don't wait for liD completion *1
don't write till block leaves available list *1
2-175

280041-001

inter
#define
#define
#define
#define

/*

*
*
*

*/

AP-184

a-TAPE 02000
/* this is magtape (no bdwrite, raw i/o at any loc) *1
a-paUSY
04000
B-PACK
010000
a-PURGE
020000
/* bpurge() +n progress--invalidate buf when releas'

special redeclarations for
the head of the queue per
device driver.

#def1ne
#deUne
#define
#deflne

b actf
av forw
b-actl
av-back
b-actlve b bcount
b-errcnt b-resid

/*

* collect 10 statistics
*/
#deflne
DISKMON
"

#1fdef
DISKMON
struct {
lnt nbuf;
long ncache;
long nwrite;
long
bufcount[NIOSTAT];
long
nswapb;
} 10 info;
#endIf

2-176

280041-001

AP-184

APPENDIX G:
. Naming Conventions.
The convention followed is:
ixxxppp
where
xxx is the number of the device (i.e 634.624)
ppp is the procedure name i.e. lnit, open
Thus, the iSBX 270 Video Terminal Controller Board
driver has the interface procedures:
i270initO
i2700penO
i270sta.rtO etc.
This na.ming convention allows the kernel procedures to
understand unique driver interfaces. Usually, data structures also follow this convention to identify variable names
and symbols.

2-177

280041-001

AP-184

APPENDIX H:
The

1*

*
*
*
*
*
*

*1

~.~

file describing the

~

structure

A clist structure is the head
of a linked list queue of characters
The characters are stored in 4-word
blocks containing a link and several characters.
The routines getc and putc
manipulate these structures.

struct clist
{

};

1*

*
*
*
*

*
*
*
*

*1

1* character count *1
1* pOinter to first char *1
1* pOinter to last char *1

int c cc;
char *c cf;
char *c=cl;

tty structure is needed for
each UNIX character device that
is used for normal terminal 10.
The routines in tty.c handle the
common code associated with
these structures.
The definition and device dependent
code is in each driver. (kl.c dc.c dh.c)

A

struct tc
char
char
char
char
char
char

{

t intrc;
t-quitc;
t-startc;
t-stopc;
t-eofc;
t=brkc;

1*
1*
1*
1*

interrupt *1
qui t *1
start output *1
stop output *1
1* end-of-file *1
1* input delimiter (like nl) *1

};

struct tty
{

struct
clist t rawq; 1* input chars right off device *1
struct
clist t=canq; 1* input chars after erase and kill *1
struct
clist t outq; 1* output list to device *1
int (* t oproc)(Y; 1* routine to start output *1
int (* t=iproc)(); 1* routine to start input *1
struct chan *t chan;
1* destination channel *1
t linep; 1* aux line discipline pOinter *1
1* device address *1
dev tt-dev;
1* device number *1
short
t-flags; 1* mode, settable by ioctl call *1
short
t-state; 1* internal state not visible externallv */
short
t 2state; 1* continuation of state, driver specific *1
short
t-pgrp;
1* process group name *1
char t delct; 1* number of delimiters in raw q *1
char t-line;
1* line discipline *1
char t-col;
1* printing column of device *1
char t-erase; 1* erase character *1
char t-kill,
1* kill character *1
char t-char;
1* character temporary *1
char t-ispeed; 1* input speed *1
char t-ospeed; 1* output speed *1
union '{
struct tc t tc;
struct clist t ctlq;
} t_un;
};

2-178

280041-001

AP-184

#define

tun

tp->t un

1*
* structure of arg for ioctll
*1
*
ttiocb {
struct

};

char
char
char
char
int

#define
#define

ioc ispeed;
ioc-ospeed;
ioc-erase,
ioc-kill ;
ioc:::r lags;

e
f

a
u
I
t

TTIPRI
TTOPRI

#define

CERASE

#define
#define
#define
#define
#define
#define

CKILL
CQUlT
CINTR
CSTOP
CST ART
CBRK 0377

1* 11mt ts *1

#define
TTHIWAT
#define TTLOWAT 70
#define
TTYHOG

1* modes *1
#define
#dehne
#define
#define
#define
#define
#dehne
#define
#define
#define
#define
#define
#define

d

TANDEM
CBREAK
LCASE
ECHO 010
CRMOD
RAW 040
ODDP 0100
EVENP
NLDELAY
TBDELAY
XTABS
CRDELAY
VTDELAY

28
29

s
p

e
c#define

'@'

034
0177
023
021

1

a/*
1/*
1*
c/*

CEOT 004

FS, cntl shift L *1
DEL *1
Stop output: ctl-s *1
Start output: ctl-q *1

h

a

100
256
01
02
04
020

r
a
c
t

e
r
s

I*

020a
001400
006000
006000
030000
040000

1* Hardware bits *1
#define
#define

DONE 0200
I ENABLE
0100

1* Internal state bits *1
#define
TIMEOUT
01
1* Delay timeout 1n progress *1
#define
WOPEN
02
1* Waiting for open to complete *1
#define
ISOPEN
04
1* Device is open *1
#define
FLUSH
010
1* outq has been flushed during DMA *1
CARR ON
020
#define
1* Software copy of carrier-present *1
BUSY-040
#define
1* Output in progress *1
0100
#define
ASLEEP
1* Wakeup when output done *1
0200
#define
XCLUDE
1* exclusive-use flag against open *1
0400
#define
TTSTOP
1* Output stopped by ctl-s *1
01000
#define
HUPCLS
1* Hang up upon last close *1
#define
TBLOCK
02000
1* tandem queue blocked *1
#define
DKCMD
04000
1* datakit command channel *1
#define
DKMPX
010000
1* datakit user-multiplexed mode *1
#deftne
020000
DKCALL
1* datakit dial mode *1
040000
#define
DKLINGR
1* datakit lingering close mode *1
#define
CNTLQ
0100000
1* interpret t_un as clist *1
1* Driver specific state bits *1
#define INBUSY 01
1* Input in progress *1
#define INSTOP 02
1* Stop input interrupts *1
2-179

280041-001

AP-184

/*

* tty

ioctl commands

*/

.define
TIOCGETD
.define
TIOCSETD
.define
TIOCHPCL
.define
TIOCHODG
.define
TIOCHODS
.define
TIOCGETP
.define
TIOCSETP
.define
TIOCSETN
.define
TIOCEXCL
.define
TIOCNXCL
.define
TIOCFLUSH
.define
TIOCSETC
.define
TIOCGETC
.define
TIOCGETS
'define' DIOCLSTN
.define
DIOCNTRL
#define
DIOCMPX
#define
DIOCNMPX
.define
DIOCSCALL
#define
bIOCRCALL
'define
DIOCPGRP
#define
DIOC~ETP
.define
DIOCSETP
#define
DIOCLOSE
.define
DIOCTIME
#define
DIOCRESET
#define
FIOCLEX
.define
FIONCLEX
.define FIORDCHK
.define
MXLSTN
#define
MXNBLK

/*

*

*/

«('t'«8)IO)
({'t'«8)ll)
({'t'«8)12)
({'t'«8)13)
«'t'«8)14)
«'t'«8)18)
«'t'«8)19)
«'t'«8)II0)
«'t'«8)113)
«'t'«8)114)
«'t'«8) 116)
«'t'«S)117)
«'t'«8)118)
«'t'«8)119)
«'d'«S}fl)
«'d'«S)12)
«'d'«8)13)
«('d'«S)14)
(t'd'«S)15)
(C'd '«S) 16)
«'d'«8)17)
«'d'«S)IS)
«'d'«8)19)
«'d'«8)IIO)
«'d'«8)111)
«'d'«8)112)
«'f'«8)11)
«'f'«8)12)
«'f'«8)13)
«'x'«8)11)
«'x'«8)12)

tty ioctl commands (extension)

.define
#define
#define
.define

MLCRESET
MLCBOOT
MLCWRITE

«'m'«8)IO)
«'m'«S)ll)
«'m'«S) 12)
«'m'«S)13)

, 2-180

280041-001

inter

AP-184

APPENDIX I:
The c254.c and

*
**

~.~

files

include file for 254 driver ... this is i254 h
mask constants for BMC status:

*/
#define
#define

BMCBUSY
BMC

Ox80

/*

*

configuration structure for 254
*/
struct
i254cfg {unsigned c base port;
unsigned c page size; };
--

/* this is c264.c
*/
#include " .. /h/i254.h"
struct
1254cfg
1264cfg={Ox40. /* I/O base port address */
256} /* bubble page size
- 64 for 1 bubble,
128 for 2 bubbles,
266 for 4 bubbles */

2-181

280041-001

APPENDIX J:
The iSBC 634
-----

/*

* INTEL CORPORATION PROPRIETARY INFORMATION. THIS LISTING IS
* SUPPLIED UNDER THE TERMS OF A LICENSE AGREEMENT WITH INTEL
* CORPORATION AND MAY NOT BE COPIED NOR DISCLOSED EXCEPT IN

* ACCORDANCE

WITH THE TERMS OF THAT AGREEMENT.

*/

/*

* isbc634 device driver.
** This is the set of procedures that make up the isbc634 device driver.
* The procedures provided include i6340pen, i634close. i634intr. i634start.
*
*
*

i634ioctl which are the interfaces between xenix and the hardware.
The subroutines used are i634init. i634param which are used to program the
hardware. The isbc634 hardware conSists of 4 usarts. 2 pic's, 2 pit's and
a pp1.

*
** Multiple Isbc634 minor number structure:
* bits 0-4:
* Minor #:
Board:
* 0-3 usarts 1st Board lowest intr level
* 4-7 usarts 2nd Board intr level
*
** 20-23 usarts 6th Board last intr level(7)
* bits 6-6 reserved for future use.
** NOTES: The base address of the board MUST be non-zero!!!
*
The isbc86/12 board must have the fail safe timer installed. (default)
*
The isbc634 REQUIRES a HARDWARE MODIFICATION for MODEM SUPPORT
*
The isbc634 reqUires a default jumper removed from
*
pin 106-106
*
and add a jumper from
*
*

*
*
*
*
*
*
*
*
*
*
*

pin 106-104
This modification cascades timer bdg4 to bdg6 to allQw a
2 second timer used in detecting carrier from a modem.
The carrier loss signal is generated via a separate interrupt.
The above modification is ONLY NEEDED to FOR MODEM SUPPORT but should
be done for conSistency.
Debug switches are: DEBUG for isbc634 support.
i634debug: output control
o
no output except spurious intrs
1 -- special currently same as 0
2 -- little but useful output
3 -- all output

==

*
*
** Written
*
on
**
*
*
*
*
*
*
*
*
*
*
*

by Jim Chorn
12/29/81

History: modified 1/16/82 for multiple board support.
modified 1/29/82 for console support.
modified 3/29/82 for addition of modem support
mods affect i6340pen,i634close,i634intr.
modefled 4/22/82
moved console support out to support isbx361
modlfied 6/22/82 added OR tie'ng of 634's on the same interrupt
level.
Changed the modem support bit to OxCO meaning configure
the llne for detection of aquisition AND loss of carrier detect
Signal. Bit Ox40 means detection of aquisition and bit Ox80
means detection of loss of carrier detect signal.
The detection of aquisition of carrier without detection of
2-182

280041·001

int:er
*
*

AP-184

loss of carrier is meaningless and is not mentioned in the
manual entry.

*
*1
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

"
"
"
"
"
"
"
"
"
"

. . /h/i634.h"
.. /h/param.h"
. . /h/systm.h"
. . /h/conf.h"
.. /h/dir.h"
. . /h/a.out.h"
. . /h/user.h"
.. /h/tty.h"
.. /h/usart.h"
.. /h/intr.h"

#t!def DEBUG
tnt i634debug = 1;
.endt!
int
struct
struct
int
int

1* hardware structure and local commands *1
1*
1*
1*
1*

system *1
system configuration *1
system directory structures *1
1* needed for user.h *1
user structures (system)
*1
/* device structures (system) *1
/* baud rates *1
1* some pie commands from system */

1* debug output control *1

i634wakeup;
1* wakeup variable for modems *1
tty i534tty[N534*4];
/* 4 USARTs per 534 *1
i634cfg
i534cfg[N534];
1* board software addresses von conf*/
i634base[8];
1* board number -> board base addr *1
i634alive[N534];
1* does it live ?? *1

1*

* This procedure verifies that a isbc634 board is presently
* configured by putting the board into test mode and
* then checking if the board actually is in test mode.
* This test mode check is a one bit test. If the board configured is not
* present an array variable for each board called i634alive is set to false.
** TITLE: 1634probe

**

CALL:

**

INTERFACES: i6340pen. 1634tntr (thru the variable

**

CALLS: none

i634probe();
1634cf~[])

** History:

*
*1
i634probeO

{

register board;
register struct i634cfg *cf;
struct
db634
*DBbase;
int
alive;

1* set up the i/o boards base address. */

for (board=O; boardc base != 0) {
alive = 1;
1* assume it lives *1
DBbase =cf->c base;
outb(&DBbase->stestmd, 1);
1* select test mode *1
if«inb(&DBbase->stestmd) & 1) == 0)
1* is test mode selected?
alive = 0;
1* trash base addr for intr() *1
outb(&DBbase->stestmd, Oxff);
if«inb(&DBbase->stestmd) & 1)
0)
alive = 0;
outb(&DBbase->stestmd, 0);
1* deselect test mode */
printf("iSBC 634 Based Ix board Id Is.O,
cf->c base, board,
i534base[board] = cf->c base; 1* associate board & tty struc*1
i634alive[board] = alive;

=

*1

==

}

}
}

2-183

280041-001

1*
*
*
*
*
*
*
*
*
*

This procedure initializes the isbc534 when the call to dinit is
made. This procedure is done ONCE ONLY in the following sequence:
initlalize the lsbc534 structures to polnt at the board,
reset the board,
lnltlalize the usarts wlth a spec1al hardware sequence,
lnit1al1ze the pp1 port for 1nput,
ln1t1allze and mask the on-board p1c's.
After th1s has been accomplished there 1s no reason to reln1tla11ze the .
isbc534 except when hardware fallure occurs.
,
NOTE: The baud rate clocks are not programmed here; th~s
* is done on the f1rst device open in the call to l534param;see 15340pen.'

*

** TITLE: l6341nlt
** CALL:

1534init();

** INTERFACES: d1nlt
** CALLS: delay
** H1story: 1/11/82 Shortened the delay time from 100 to 10 to speed things
*
up a b1t.
,
*
1/16/82 Added probing for boards.

*
*1
15341n1tO

{

1* set up the

struct
db534
*DBbase;
struct
cb634
*CBbase;
reg1ster 1nt 1, board;

1/0 boards base address

*1

#1fdef DEBUG

1f(1634debug>=2)
pr1ntf("1634 1n1t, 0);

#end1f

1634probe 0 ;
for (board=O; boardreset, 0);
outb(lDBbase->seldata, 0);
for (1=0;1<4;i++){
1* lnlt each usart *1
l51u1n1t(lDBbase->USART[1] .cntrl);
}

outb(lDBbase->PIC[O] .csr, PICICW1)
outb (lDBbase-'>PIC[O] . msr, PICICW2)
outb(lDBbase->PIC[l] .csr, PICICW1)
outb(lDBbase->PIC[l] .msr, PICICW2)
outb(lCBbase->selcntr,l);
163tprog(lCBbase->PIT[l] ..tlmer[1],
lCBbase->PIT[l] .pcr,
(RATEKDOI Ox40),
U634SPEED);
1* 2'

,

}

163tprog(lCBbase->PIT[l] .tlmer[2] ,
lCBbase->PIT[l] .pcr,
..
(RATEKDOIOx80),
U534SPEED >;
1* 2
outb(lCBbase->seldata,l);

1* tlmer bdg4*1
1* pcr *f.
1* mode *1
sec *1

1* tlmer bdg6*1
1* pcr *1
1* mode *1
sec *1

}

1*
* Thls procedure sets up a usart tlmer for a load operatlon.
280041-001

inter
*
*
*

*
*
*
**
**

AP·184

The code depends on having the ttystructure filled out before a call is made
to i634param. This is the sequence of events;
check for valid speed
program timer
(using i63tprog)
This procedure will program bdgO to bdg4 as a baud rate generator.
TITLE: i634param
CALL:

**
**
**
*
*
*

i534param(dev);

INTERFACES: i534init,
CALLS: i63tprog
History:

1/20/82: removed bdg4, bdg6 programming options.
These timers aren't used.
1/29/82
4/7/82: added i63tprog to handle pit programming
4/22/82 : removed console programming

*

*
*/
#define MAXBAUDS 16 /* maximum indexes into i634baud[] */
int i634baud[] = {
US BO ,
US B50,
US B76, US B110, 0,
US-B1GO, US B200~ US B300~ US B600~ US B1200,
0,US=B2400,
- US_B480U,
US_B9600,
};

int

o

1634speed[N634*4];

0,

/* track record */

1634param(dev)
dev_t dev;
{

struct
cb534
*CBbase;
reglster struct tty *tp;
lnt unit, s, speed,mode,plt;

/* set up the i/o boards base address *,

unit = minor(dev) l MINORMSK;
tp = li634tty[unit] ,
CBbase = tp->t addr l OxfO;
s = (1nt)tp->t-ospeed;
1f(s==0) { /* hangup signal via stty */
return;
}

if(s == i534speed[unit])
return;
/* already that fast */
else
i534speed[un1t] = s;
un1t %= 4;
/* wh1ch usart? */
speed = 1634baud[s];
i f «s > MAXBAUDS) II «s != 0) u (speed == OJ)) {
u.u error = EINVAL; /* 1nvalid baud rate */
return;
}
if

(unit == 3){
pit = lCBbase->PIT[l] .timer[O];
mode = RATEMDO;
}else{
pit = lCBbase->PIT[O] .timer[unit];
mode = RATEMDO I (unit «6);
}

s = SPLO,
outb(lCBbase->selcntr,l);
163tprog(pit, (pltIOx03),mode,speed);
outb(lCBbase->seldata,l);
splx(s) ;
}

2-185

280041-001

AP~184

/*
*
*
*
*

This procedure opens one of the 4 lines on the isbc534 board for
exclusive use by a user. The file ~tructure is initialized
and control is passed to ttyread w~ich does the actual open.
Not supported is the fifth device which is the parallel port.

*

** TITLE: i5340pen
** CALL:
**
**
**
*

i5340pen(dev. flag);

INTERFACES: xenix
CALLS: i534init. ttyopen
History: 1/15/82:
Modifed code for multiple i534's to:index a
configuration table to get the board base address.

**/
int i634start();
i534open(dev)
dev_t
dey;
{

struct
db534
*DBbase; /* set up the i/o boards base address */
register struct tty *tp;
register int unit;
int modem;
/* modem bit in minor dey numb */
unit = minor(dev) a MINORMSK;
if (unit >= (N534*4» {
u.u_error = ENXIO;
return;

/* not enough tp's */

}

tp = ai534tty[unit];
if (i534alive[unit/4] -- 0) {
u.u error = ENXIO'
return;
.

/* Board not there! */.

}

DBbase = (struct db534 *)i534cfg[unlt/4] .c_base.
unit %= 4;
modem-= minor(dev) I MODEMMSK;
tp->t oproc = i534start;
if «tp->t state a ISOPEN)
0 ) {
ttychars(tp) ;
tp->t ispeed = tp->t ospeed = ISPEED. /* channel speed */
tp->t-flags = ODDP 1 EVENP 1 ECHO 1 CRMOD;
i534param(dev);
/* load baud clock */
/* turn usart (dtr) on */
if (modem) C
if(modem a MODEMWAIT)
/* mask detect leaving aqua */
while«inb«tp->t addr +1» a DTRON) == 0)
(-(Ox10« unit» aTIMERGO».

==

}

/* unmask txrdy. rxrdy */

~(-(3«

unit * 2»».

}

if (tp->t state a XCLUDE
}

u.u error = EBUSY;
return;

aa u.u uid != 0) {

tp->t state 1= CARR ON;
(*linesw[tp->t_lineT.l_open) (dev. tp).
}

2-186

280041-001

inter

AP-184

1*

* This procedure performs the close operation on one of the devices of the
* isbc534. A close masks the device on board; reinstalls the flags that
* state the device is closed; calls ttyclose the do the operation.
* Not implemented yet is device 4 which is the parallel port; it is
* unknown device at this minute.
** TITLE: i534close
** CALL: i534close(dev, flag);
** INTERFACES: xenix
** CALLS: ttyclose
** History:
*
*1

i534close (dev)
dev_t
dev;
{

struct
db534
*~Bbase;
register struct tf..y *tp;
reglster unit;
int s,

1* set up the

unit = minor(dev) l MINORMSK;
tp = li534tty[unit] ,
DBbase = (tp->t addr l OxfO);
if (unit < N534*~) {
if(tp->t state l HUPCLS) {
tp->t state l= -CARR ON;
}

}

1/0

boards base address *1

1* dtr off *1

(*linesw[tp->t line].l close) (tp);
ttyclose(tp); unit"=4;
s = SPLO;
mask = inb (lDBbase->PIC [0] .msr) I (3 « (unit * 2));
1* RxRDY, TxRDY off *1
splx(s);

}

1*
* This procedure interfaces the read ~equest with the system read operation
* to obtain a byte from the usart. The usart's character is read after an
* interrupt so this procedure calls the system to wait for the interrupt
* procedure to pass the character on to the input character queue.
** CALL:
**

INTERFACES: xenix

** CALLS:

** History:
*
*1

2-187

260041-001

AP-184

dev_t
dey;
{

register struct tty *tp;
register int unit;
,
unit=mlnor(dev) a MINORMSK;
tp = ai534tty[unit);
}

1*

* This procedure is the compliment of the i534read routine. A call is
* made to ttwrite which watches the output queue for characters and
* gets the characters in the queue out to the device
** TITLE: i534write
** CALL:

**

i534write(dev),

INTERFACES: xenlx

** CALLS: ttwrlte
** History:

*
*1
i534wri te (dev)
dey t
dey;
{

register struct tty *tp;
register int unlt;
unit=minor(dev) a MINORMSK;
tp = ai534tty[unit);
(*linesw[tp->t_line) . I_write) (tp);
}

1*

*
*
*
*
*
*
*
*
*
*

This procedure is called by xenix with interrupts off (sp15) when the
isbc534 interrupts. The interrupt process polles the 8259's on the isbc534
to find out whlch device; (if the device is a usart receiving it gets the
character) then sends the character to ttyinput or restarts output by
calling ttstart depending on which interrupt was set off. Ttystart calls
i534start to make sure that no more characters need to be transmitted and
to let every body know a character has been transmitted. The carrier detect,
ring indicator, present next digit and pit interrupt signals are not
implemented yet. The present next digit signal comes from the external
source on line 4.

** NOTE: all carrier detect signals both interrupt and latch on the 8255 ppi.
*
Refer to the H/W manual for possible uses of these signals
*
(ie ACU I printer applications) .
*
The rxrdy/txrdy lines from the older usarts (8251A/s2657 a older) cause
*
giltches on the piC interrupt lines. This is a problem with the USART.
*
If possible replace usart with a newer version.

*
**
**
**

TITLE: i534intr
CALL:

1534intr(level);

INTERFACES: xenix

** CALLS:

ttyinput, ttstart
2-188

280041-001

AP-184

** History:
*
*

Rxrdy/~xrdy intr switch to
run more efficiently using an if .. ; Added the
unset of busy flag which gets set in i634start.
1/16/82: changed variable type to level which was incorrect.
added multiple isbc634 support.

*

*

*
*1

tnt

1/13/82: Condensed the usart

wakeupO,

i634lntr(level)
lnt level;
{

struct
db634
*DBbase; 1* set up the 1/0 boards base address *1
reglster struct tty *tp;
reglster char c;
lnt
1* mask ~ status to/from PIC *1
lnt
gotone,board;
do {

gotone=O;
for(board=O;boardPIC[O] .csr, GETINT);
status = lnb(~DBbase->PIC[O] .csr);
if «status ~ GOODINT) == GOODINT) {
1* check b1t 8 for an int *1
gotone++;
outb(~DBbase->PIC[O] .csr, PIC EOI);
status ~= Ox07;
-1* mask off garbage blts *1
tp = ~1634tty[board*4] + (status » 1);
if «status ~ OxOl) == O){
1* Rxrdy intr *1
c = inb(tp->t addr);
(*linesw[tp->t line].l r1nt)(c, tp);
}else{
1*- Txrdy intr *1
tp->t_state ~= -BUSY;
1* the character is out *1
(*linesw[tp->t11ne].1 start) (tp); 1* do the next one *1
if«tp->t state ~ ASLEEp) ~~ (tp->t outq.c cc <= TTLOWAT» {
tp->t state ~= -ASLEEP;

}

}
}
outb(~DBbase->PIC(l] .csr, GETINT);
status = lnb(~DBbase->PIC[1] .csr);
if «status ~ GOODINT) == GOODINT)

{

1* check bit 8 for an int *1

gotone++;

.csr, PIC EOI);
status ~= Ox07;
-1* mask off garbage blts *1
i f (status >= 4)
tp = li634tty[board*4] + (status -4);
switch(status) {
case 0 :
1* pit 1 cntr 4 *1
break;
case 1 :
1* pit 1 cntr 6 *1
break;
case 2 :
1* ring ind all *1
break;
case 3 :
1* present next *1
break;
case 4 :
1* port 0 detect*1
case 6 :
1* port 1 detect*1
case 6 :
1* port 2 detect*1
case 7 :
1* port 3 detect*1
if«tp->t state l (CARR ONIISOPEN»
== (CARR ONIISOPEN» { slgnal(tp->t pgrp, SIGHUP);
tp->t state 1= -CARR ON;
1* flIck dtr off to cause

outb(~DBbase->PIC[l]

2-189

280041-001

AP-184'
* hardware hang up on
* modem

*1

lnb(tDBbase->PIC[l] .msr}
! (l«status);'
1* carrler detect off *1
}

break;
}
}

.ifdef DEBtiG
1* else
'endU

prlntf("1534: Spurlous Int level IdO, level); *1

1* no interrupt from thls device
*
*
*
*
*
*

*1

}

a call should be made to handle
some form of accountlng as this
interrupt ls probably caused by
an out of date usart 8261A/s2657
or older. (glItches occaslonal1y
the rxrdy/txrdy 11nes)

}

} whlle(gotone);
*
*
*
*

Thls procedure starts output on a usart if needed. 1534start gets a
character from the character queue, outputs the character to the usart,
and sets the BUSY flag. The busy flag gets unset when the character
has been transmitted 6y 15341ntrO.

** TITLE: 1634start

•* CALL: 1634start(tp)
** INTERFACES: ttystart
** CALLS: none
1/13/82:
** Hlstory:

Removed the hardware probing for txrdy and added
a set of the busy flag whlch gets unset on txrdy
lnterrupt.

*
*

*
*1

lnt ttrstrtO;
cbar partab [] ;
1634start(tp}
reg1ster struct tty *tp;
{

reglster c;
reg1st.er s;
'ifdef DEBUG
if (1534debug>=3)

pr1nt.f("1634~tart: called on unlt at IxO, tp->t_addr};
.endif
s = sp160;
1f (tp->t statea(TIMEOUT!BUSY» {
splX"{S};
return;

}

sp1X(s) ;
lf «c=getc(atp->t outq}) >= 0) {
if (tp->t flags a RAW) {'
hlse{
i f (c<=Ox7f) {
outb(tp->t addr, c ! (partab[c1a0200});
hlse{
2-190

AP-184

tp->t state 1= TIMEOUT;
timeout(ttrstrt, (caddr t)tp, (ctOx7f»;
return;
1* i'm tImed out t !BUSY *1
}
}

tp->t_state 1= BUSY;

}

,.

• This procedure handles the ioctl system calls for such things as baud rate,
• changes and various ~ardware control changes from the initial set up.
• Currently only baud rate changes are supported.

•• TITLE:

•• CALL:

163410ctl
1634ioctl(dev, cmd, addr, flag)

•• INTERFACES: loctl
•• CALLS: i634param,
*
•

•
*1

ttloccomm

History:

i634ioctl(dev, cmd, addr, flag)
{
register struct tty *tp;
register int unit;

-

}

unit = minor(dev) t MINORMSK;
tp = ti634tty[unit);
1f (ttioccomm(cmd, tp, addr, dev» {
if (cmd==TIOCSETP II cmd ==TIOCSETN)
1634param(dev);
}else
u.u error = ENOTTY;

2-191

I*if

baud change do it*1

280041-001

AP-184

REFERENCES

ACKNOWLEDGEMEfIITS

1) Ritchie, Dennis M., The Unix 110 System,

1) Jim Emmons, for hours of shared discussion on
device drivers and for his iSBC 254 Bubble
Memory Board Pseudo,-Code.

undated.
2) Scheulen, Bob, Microsoft Device Driller Guide, unpublished '82.
3) Letwin, Gordon, Interrupt Structure, unpublished
(MICROSOFT) '82.

2) Dilip Ratnam, Phil Barret, Jean McNamara
Rick Byrant and other members of the XENIX
team for sharing their ideas.

4) Short, Antony, The XENIX I/O System, unpublished (MICROSOFT) '82.

3) Vince Slyngstad, for his iSBX 270 Video Terminal Controller walkthrough.

5) Beck, Bob, The Anatomy of XENIX Device
Drillers, unpublished.
6) Byrant, McNamara, Vaish, Writing Device
Drillers, UNIFORUM '84.

2-192

inter

APPLICATION
NOTE

AP-221

October 1984

An Introduction to
Task Management in the
iRMX™ 86 Operating System

CATHERINE J. LUNDBERG
APPLICATIONS ENGINEERING

INTEL CORPORATION, 1984

Order Number 280047-001
2-193

AP-221

An Introduction to Task
Management in the
iRMX™ 86 Operating
System

Contents
Introduction .......................... .
iRMX™ 86 Operating System Nucleus
Architecture ........................ .
Memory Management ............... .
Task Scheduling .................... .
Single Task Application Example ..... .
Creating Tasks ...................... .
Mailboxes .......................... .
Using the System Debugger (SOB) "
Exception Handling ..... " ......... .
Multiple Task Application Example ... .
Main$task .......................... . Supervisor$task .................... .
Widget$task ......................... ' IO$task ............................. .
Mailboxes ......................... .
Deadlock .............. : ........... .
Initialization ........................ .
Debugging ......................... .
Configuration ........................ .
Configuring the iRMXTM 86
" Operating System ............... .
Linking and Locating the
Applipatio.n ..... I ....: .. .......... .

Co.nclusion ............................ .
Appendix A: Inittask Code ........... .
Appendix B: Onetask Code .......... .
Appendix C: Tasks Code ............ .
Appendix D: Submitfile .............. .
Appendix E: iRMX 86 Operating System
Definition File ..................... .
Appendix F: Related Publications ....

2-194

AP·221

INTRODUCTION
The purpose' of this application note is to help users
understand the nucleus of the iRMXTM 86
Operating System, and how to use the nucleus. The
other layers of the Operating System are not
discussed. It is assumed that the reader has a basic
understanding of the iRMX 86 Operating System,
which can be gained by reading the product
documentation. This application note does not
discuss all areas of the nucleus with equal depth, so
readers wishing to understand areaS other than task
scheduling should refer to the iRMX 86 Nucleus
areas are covered in enough detail to provide the
necessary background for understanding how to use
tasks in the iRMX 86 Operating System.
This application note focuses on the nucleus and its
task scheduling and resource management
functions. The nucleus of the iRMX 86 Operating
System must handle two major functions: task
scheduling, which also involves interrupt handling;
and resource management, in particular memory
management. The iRMX 86 Operating System has
other layers, which increase the functions provided
by the Operating System and which rely on the
nucleus as their base.
The iRMX 86 Operating System is a real time
operating system which can have multiple jobs and
tasks. It is a preemptive, priority based operating
system. Since only one task can be executing on the
central processor at any time, the task scheduler is
the heart of the operating system.
The application note has two examples. The first
example creates a single task to show what is
involved in creating a task. The second example
demonstrates how the relative priorities of the tasks
affect the way the application behaves, and is used as
the basis for discussing deadlock between tasks.

iRMX™ 86 OPERATING SYSTEM
NUCLEUS ARCHITECTURE
The nucleus of the iRMX 86 Operating System is
essentially a resource manager. There are many
resources which an operating system must handle.
These can be divided into three areas for the iRMX
86 Operating System: processor time, objects and
memory. The main concern in this application note
is control of processor time, but the reader should
remember that in controlling processor tif1le, the
nucleus also manages each of the other two areas.
Processor time is the key resource the iRMX 86
Operating System manages. The Operating System
should use the processor as efficiently as possible.
2-195

When a task requires the processor, that task is
placed in the ready state. The processor always
executes the highest priority ready task first. If more
than one task of that priority is ready, the processor
is allocated to the task that has been ready the
longest. Once a task gains control of the processor,
that task retains control until preempted by a higher
priority task or interrupt, or the task gives up controL
Objects are the building blocks of the iRMX 86
Operating System. There are several types of
objects: tasks, jobs, segments, mailboxes,
semaphores, regions, extension objects, and
composite objects. Tasks are the primary focus of
this application note. However, the use of segments
and mailboxes will also be discussed since they are
used to communicate between the tasks in the
example programs.
Memory usage is usually a critical factor in an
application. It is desirable to use as little memory as
possible, while still allowing the application to run
efficiently. Insufficient memory can slow down the
execution of a task or cause an error when executing
the application.
Some other functions of the iRMX 86 Operating
System that are implemented at the nucleus level
are exception handling, interrupt management, and
hardware manipulation of devices such as the
programmable interrupt controller, the system
clock, and the numeric data processor. These
functions are not specifically discussed in this
application note.

Memory Management
In the iRMX 86 Operating System, memory is
partitioned into pools. That portion of the nucleus
that allocates memory is called the free space
manager. The root job, which is the first job in the
Operating System and the ancestor of all other jobs,
has a memory pool consisting of all available
memory when the Operating System initializes. As
jobs are initialized, they are allocated memory from
the root job's pool for their own use.
Jobs which are created during system initialization,
such as those that make up the iRMX 86 Operating
System layers, are allocated memory based on
configuration parameters. There are two parameters
used in requesting memory. The first is the
minimum memory pool size. This parameter
specifies the minimum amount of memory that the
job requires in order to run. The second parameter is
maximum memory pool size. This parameter can
either have the same value as the minimum pool
size, or it can have some larger value. If it has a
larger value, the job will be allowed to borrow
memory dynamically from its parent or some more
280047-001

inter

AP·221

distant ancestor. If the maximum memory pO'ol is
set to a smaller value than the minimum memory
pool, an error will result. If the minimum and
maximum memory pool sizes are the same, the job
will be allocated that amo.unt of memory and will not
be allowed to borrow memory.
If there is sufficient memory to fulfill the request
when a job is created, it is given the minimum
amount of memory requested. If there is not enough
memory, the job is not created and an error
(E$MEM) will be returned to the creator. If the job is created and later needs more memory, the request will be honored up to the maximum memory pool size by borrowing. The memory is borrowed from the job's ancestors. A job with the same minimum and maximum memory pool size cannot borrow memory from its parent. Usually, only one job created by the root job should be allowed to borrow memory. This prevents more than one job borrowing memory from the same memory poo\. Multiple jobs borrowing from the same memory pool can cause deadlock between the jobs, so borrowing should be used with great caution. In an iRMX 86 Operating System with all the layers, the Human Interface is usually chosen to be the layer allowed to borrow memory. Memory is allocated by the free space manager on a first come, first served basis. The job that is created first will receive the memory it requested if there is sufficient memory available to satisfy the minimum memory pool request. Then the next job created wiII request the memory it needs. If a job is not able to get as much memory as it needs, the operating system will return an E$MEM error to the creating
task and the job will fail to be created. The free space
manager will continue to try to allocate memory to
the next job that is created.
The free space manager for Release 6 of the iRMX
86 Operating System keeps a sequential doubly
linked list of the available segments of memory
within each job pool. Each block of memory has a
header which contains two links: one forward, and
one backward. A pointer called the rover always
points to the next entry of the linked list's unallocated memory.
When a memory request is made, the next' memory
entry in the linked list is checked to see if it is large
enough. The first segment found which is large
enough is allocated and removed from the free space
manager's list. The rover points to the remainder of
the segment just allocated. Memory is always allocated in contiguous segments, including allocating minimum memory pools. The rover keeps the lower portionof memory from becoming more fragmented
than the upper portions. Using the rover and a first

fit algorithm means that the average number of segments that must be checked is also decreased. (See
Knuth: The Art of Computer Programming: Vol. I
pp 435-453. In particular, refer to exercise 6 on p.
452 and its answer on p. 597 J When memory is returned to a pool, it is merged with existing segments
when possible.
The Application Loader allocates memory to jobs at
run time under control of the iRMX 86 Operating
System. The OMF (Object Module Format) for ·the
iAPX 86 processor has two areas in which minimum
and maximum memory pools' are specified. First are
the program's. minimum and maximum static
memory requirements. These static memory
requirements correspond to the code and data size
of the job. The second area in which memory pools
are specified are a minimum and maximum dynamic
memory pool which are specified in the LINK86
process.
When the Application Loader allocates memory for
a program, the Application Loader calls the Nucleus
to create a memory pool as large as possible within
the specified bounds from the user's memory poo\.
In Releases 5 and 6 of the iRMX 86 Operating
System, with each failed attempt to allocate
memory, the application loader decrements the size
of the memory pool requested by 3% of the
difference between the current size attempted and
the minimum size. The Application Loader then
tries again to allocate the memory. This approach is
used so that the application is given the largest
amount of memory possible in as few tries as
possible, and so that the loading time is decreased.

Tasks are the active objects in an iRMX 86
Operating System, and they do all the work. They
run inside of jobs, which provide the environment
the tasks need, such as the memory pools. There are
five possible execution states for an iRMX 86 task.
These states are running, ready, asleep, suspended,
and asleep-suspended. Nucleus system calls can
change the state of a task. External events can also
affect the state of the task. Figure 1 shows the state
transition diagram for tasks.
Tasks can have different priorities. A numerically
lower priority is a logically higher priority task. A
task which has a logically higher priority wiII execute
first if it is in the ready state. Tasks will be put on the
ready list in priority order, and within a priority, the
task which has been ready the longest will execute
first.
Normal tasks are assigned priorities between 80H
and OFFH so that they can be serviced with
minimum delay. Interrupts are usually at a higher
priority than normal ta,sks, and will always irterrupt
2-196

280047-001

inter

AP-221

r------,

NON-EXISTANT-----..

RUNNING

,

ASLEEPSUSPENDED

2079

Figure 1. Task State Transition Diagram

the processor when they occur. The interrupt
handler may be able to handle the interrupt directly,
or it may invoke an interrupt task to handle the
interrupt. The interrupt handler will retain control of
the processor until the handler exits or a higher
priority event occurs.
When mailboxes are used, queues of either tasks
and objects can form at the mailbox. Task queues
can form at semaphores. Task queues can be priority
ordered or FIFO (First In First Out) ordered. This
order is specified when the mailbox is created. A
FIFO queue on a mailbox can cause a task with a
lower priority to execute before a task with higher
priority. If both tasks are waiting on the mailbox
before continuing execution and the lower priority
task is first on a FIFO queue, the lower priority task
will execute first. However, when the higher priority
task receives the object for which it was waiting, the
priority and can take control of the processor.

SINGLE TASK APPLICATION EXAMPLE

called Inittask (Appendix A), which is used to
provide a stable entry point for the application code.
The entry point of Inittask is the start address for the
task. In the User Job screen of the ICU, this value
must be supplied for the task start address
which does all the work of the application. The
submit file which links and locates the user job is
given in Appendix D.

The .initial module, shown in Appendix A, is very
simple. It illustrates how to set up a stable entry
point for a user job. There is no data in this module,
and there are only two calls. Inittask is never
changed, and it is linked first, so its entry point is
stable no matter what changes are made to the rest
of the application code. This approach allows the
user job's entry point to be set up only once in the
configuration of the operating system, and removes
the need to generate a new operating system
whenever the application code is changed.
The .MP2 file generated by the LOC86 utility shows
that the module has the entry point Inittask at
1500:0002H. This address is used as the task start
address in the definition file, in the User Job screen
of the ICU. Inittask calls RQ$END$INIT$TASK, which is a requirement for any job created by the root job in the iRMX 86 Operating System. Calling RQ$END$INIT$TASK allows the root task to
resume execution and create another first level job.
Once RQ$END$INIT$TASK has been called, This section explains how to create a task, how to use mailboxes, and how to use the System Debugger. It also covers exception handling, as well as how to configure the iRMX 86 Operating System, and how to link and locate the application job. The single task example shows how to create a single task that writes to the terminal. The structure of the operating system used for this application example is shown in Figure 2. The code has an initial module, 2-197 280047-001 inter AP-221 ROOT JOB (deletes itself after initialization) BIOS JOB SDBJOB APPLICATION JOB 2080 Figure 2. Single Task System Inittask calls an external procedure called Main$task, which is the actual code that creates the
example task. The same initial module is used with
both application examples.

In Appendix B, the code for Onetask is shown.
There are two parts to Onetask. First is the main
module, called Main$task. Second is the task which is created by Main$task, called First$task. Note that there are really two tasks, only one of which is created specifically in the example code. Main$task creates a mailbox and catalogs it in the
user job's directory under the name DONEMBX. It
uses this mailbox to synchronize Main$task and the task which is created. It creates First$task and then
waits at the mailbox to receive a message from
First$task to indicate that the task has finished. Main$task then deletes the task and deletes the
mailbox.
Main$task deletes segments received from the mailbox, and then deletes the mailbox. In the code shown in Appendix B. there is a loop around creating and deleting the task. with the PUM 86 call C AUSE$INTERRUPT (3) at each end of the loop. This code
as used in this example was for debugging purposes,
but could have also allowed stopwatch timing of the
routine. Note also that using CAUSE$INTERRUPT (3) calls in your code will result in all other tasks in the system halting. including those of other users. At the point where Main$task calls RQ$RECEIVE$MESSAGE to wait at the mailbox, First$task begins to run. Main$task has a higher priority than
First$task, so First$task cannot run until Main$task either suspends itself or goes to sleep. In this case, Main$task is waiting on the mailbox, which puts it in
the sleeping state, and Main$task cannot continue until an object is received from the mailbox. This situation gives First$task' a chance to run, since it is
First$task creates some mailboxes and segments, and does a lookup to find the mailbox DONEMBX which it must use to communicate with Main$task.
First$task then physically attaches the terminal, opens a file connection, and writes a buffer to the terminal. Then it closes the connection, deletes the file connection, and detaches the device. It cleans up by deleting the segments and mailboxes it created, and signals Main$task that it is done by sending a
message to the mailbox DONEMBX.
Main$task receives control of the processor after First$task sends a message to DONEMBX to indicate completion. Main$task then deletes the segments and mailboxes which are left, and then deletes the application job. All memory allocated to the application job will then be returned to the root job's memory pool. If there was an error while running this application, the task would end up looping in one of the 'error' routines. If the application completed successfully and exited, the nucleus idle task for Release 6 of the iRMX 86 Operating System would begin executing. 2-198 280047-001 AP-221 The Basic I/O System (BIOS) was used in this application to provide immediately visible results. The section which involves using the BIOS is the most complex part of the example code. Many applications will have no need of the BIOS. These applications were done in the LARGE model of compilation to provide simpler examples. The COMPACT model can be used if the application's code and data are less than 64K each. COMPACT code can usually execute faster because calls will be within the same segment, so won't require changing as many registers to execute the call. Creating Tasks To illustrate all the areas that are involved in creating a task, let's go through each of the parameters of the RQ$CREATE$TASK system call. The call looks like this. task$token = RQ$CREATE$TASK
(priority,
start$address$pointer,
data$segment, stack$pointer,
stack$size, task$flags,
exception$pointer ); models of PL/M 86, the user task must explicitly set up its own data segment or the value of the data segment must be obtained from the locate map and used in the call. Refer to the iRMX 86 Configuration Guide, which is part of the ,RMX 86 TH Installation alld Configuration Guide for Release 6 for more information on how to set up the data segment of a task. Stack$pointer: The stack pointer is also set to zero
to allow the iRMX 86 Operating System to
automatically allocate a stack of size stack$size. While the task is running, the SS register will show which stack segment is being used for the application task. Stack$size: The stack size will need to vary with
stack requirements of the task. If the task is
reentrant, or makes calls to subroutines with
many parameters, or if the task makes iRMX 86
Operating System calls, the amount of stack
must be larger than if the task only keeps local
variables on the stack.
There are two ways to determine the stack size
needed. The first method involves arithmetically
determining the stack size needed, based on
three things: the number of bytes required for
interrupts, the number of bytes required for
system calls, and the amount of stack required
by the task's code segment. This method is explained in iRMX 86 Programming Techniques,
which is part of the iRMXTM 86 Programmer's
Reference Manual for Release 6, Part 1/. The
other method involves choosing a relatively
large stack size and reducing it through empirical
methods. To use the empirical method, display
the stack with a debugger. If there are "C7"s on
the stack when the application has completed,
that part of the stack hasn't been used. You can
also watch the stack pointer, kept in the SP
register, to see how low it goes. It will grow
toward zero from the value given as the stack
pointer when the task is created.

The parameters in the RQ$CREATE$TASK call are
explained below.
Priority: Task scheduling involves setting relative
priorities of tasks. Unless a task is involved in
processing interrupts, its priority should be
between 129 and 255. When a task having a
priority in the range 0 to 128 is running, certain
external interrupt levels are disabled, depending
on the priority. The task for this application used
a priority of 202. The initial task itself was given
a priority of82H, or 130, at configuration time.
Start$address$pointer: The start address pointer is
used to point to the beginning of the task which
is being created. In the PUM 86 LARGE and
COMPACT models, the pointer points to the
label of the procedure containing the task. The
task was a procedure within the same main
module for these examples. If the task had been
compiled separately, it would have to be defined
as an external procedure within the main
module which created the task. The actual
locations are resolved when the application is
Data$segment: In the PUM 86 LARGE model, the data segment is set equal to zero when creating the task. Setting the data segment to zero allows the task to set up its own data segment. In other While testing the example application code, the stack size was set to 2000 (7DOH) which was much too large. A stack size of 300 was sufficient for this task. Task$flags: Task flags are used in the iRMX 86
Operating System Releases 5 and 6 to tell the nucleus whether the task contains floating point
instructions. This task did not, so task$flags was set to O. Setting bit 0 of task$flags to I to indicate
the use of floating point instructions will result
in memory being reserved for the NPX
registers. The other bits of task$flags are reserved. The iAPX 8087 or iAPX 80287 must 2-199 280047-001 inter AP·221 Using the System Debugger (SOB) be included in the system if floating point instructions are used. Exception$pointer: This pointer gives the location
of the word where the status of this call will be
returned. The result is checked after the call to
make sure that an E$OK was returned. For convenience while debugging, the condition code can also be found in the CX register. The nucleus manual (Chapter 7 for iRMX 86 Release 6) contains a table of exceptional conditions that can be returned and their numeric codes. Mailboxes There are two object queues associated with every mailbox. One is a fast queue, which has a fixed length determined when the mailbox is created. The other object queue is an overflow queue, and memory must be allocated for that queue each time it is used. This example used one mailbox to communicate between the original task and the task it created. The fast queue has a length of 4, which is the default value, indicated by the 0 as the first parameter of the create$mailbox call. If this mailbox
frequently had large numbers of objects on its
queue, it might have been useful to use a larger fast
queue. This approach, of course, means that more
memory would be allocated to the mailbox when it
is created. In this application, the minim.um fast
queue length was used.
The DONEMBX mailbox is being used as if it was a
semaphore. It is used only to tell the parent task that
the child task has completed. First$task also creates some mailboxes which are used to send information. For instance, when a physical connection is made to the terminal, the mailbox is used to receive a token for the physical connection. Similarly, when a file connection is made, the mailbox receives a file connection token. Different protocols can be set up to handle objects which are received at a mailbox. In this application, after an object is received from a mailbox, that object is deleted after it has been used in an appropriate manner (such as to extract the file connection token). A protocol can also be set up so that objects are reused. A response can be sent to the task that sent the object. Only Operating System created objects can be sent to a mailbox. Objects should be deleted when they are no longer needed, because they take up memory. Creating extra objects and neglecting to delete them can eventually cause a task to use up all its available memory. The objects which are sent to mailboxes in this example are segments. Examples of how to check for the presence of objects are shown in the following section on using the System Debugger. 2-200 The System Debugger is a job which is added to the iRMX 86 Operating System at configuration time. The only configurable parameter in the SDB is its interrupt level, which in this example should be the default value of 018H, master interrupt level one. The SDB knows most of the data structures of the iRMX 86 Operating System, and can be used to determine what is happening within the Operating System while an application job is running. The first thing that must be done when using the SDB is to activate it. If you are writing an application which can be run from the Human Interface, the DEBUG cusp can be used. The example application wasn't run from the Human Interface. Instead it is built in as a user job. The SDB can be invok~d by pres.sing the front panel interrupt button, or by insertmg a 'CAUSE$INTERRUPT (3)' call into the
source code. While bootloading an application, the
'CAUSE$INTERRUPT (3)' call is a more useful tool, since pressing the interrupt button cannot stop the application at a specific point. The monitor won't get control immediately as it would if the job were loaded from a development system. The 'CAUSE$INTERRUPT (3)' call can be taken outof
the application: when the code is debugged. Any use
of the SDB should be done only in a single-user
system, since the SDB will stop all jobs.
CAUSE$INTERRUPT (3) is used in three places in the single task application code. The first occurrence is as soon as the module Main$task is entered but
before any of its code has executed. The se~ond
place is before the loop to create and delete the task.
The third place is after the loop is completed. During
the debugging phase of developing the code, there
were also CAUSE$INTERRUPT (3) calls within the task, to help determine what was happening. Breakpoints can also be used once the code has been stopped so that the monitor has control. A breakpoint is set by the monitor command 'g, address'. The code will execute until it gets to that address ' and then it will break to the monitor. The job tree is found by using the SDB command 'vj' for view job. An example follows for the application task. .vj BFDD B68A BE9E BFDD is the token for the root job. By knowing the memory pools of each of the layers, and looking at the memory pools of each of the other job tokens, a user can determine that B68A is the user job, (the application code), and BE9E is the BIOS. The 'vI' command will show the current state of each token. 280047-001 inter AP-221 .vtBE9E Object type = 1 Job (NOTE: This token is for the BIOS.) Current tasks 0003 Current objects OOOA Directory size 0000 Except handler OEE4:01CO Pool min 0800 Pool size 0800 Max tasks Max objects Entries used Except mode Pool max Allocated .vt B68A Oject type = 1 (NOTE: This token is for the applicationjobJ Job Current tasks 0001 Current objects 0001 0010 Directory size Except handler OEE4:01CO Pool min 0500 Pool size 0500 FFFF FFFF 0000 00 0800 0077 Max tasks Max objects Entries used Except mode Pool max Allocated 0010 0020 0001 00 0500 01FD Notice from these tables that the application job may have been created with too much memory. It is only using 01FD of memory (Allocated), and has a minimum and a maximum pool size of0500H (Pool min, Pool max). A pool size of 0250H would probably have been sufficient. If this command was executed early in the application, all the objects might not be created yet. So the job might require more memory than is currently being used at some point in its existence. BE64 BE2E BE06 lCCF 00 BFB8 0001 BFDD 0500 0303 Exception Handling In this example, the default system exception handler is used, and the exception mode is set to 'never'. This setting means that the application code either wishes to handle exceptions in-line or through a call to an exception handler. The system exception handler will not be invoked for errors. If the handler were invoked, it would simply delete the task containing the call which caused the exception. This application handles exceptions in line. After each system call, the task checks the status word for E$OK. If an exception is detected, the task will jump
to ERROR and loop there forever. This technique is
to help identify where an error occurred, and is
useful for debugging the application. The CX register
contains the status returned from the call, so it is
possible to find out which error occurred by using
the monitor command 'x' to display the registers.
The problem them becomes the following: to find
out where the error occurred. This procedure usually
involves stepping through the code, or setting several breakpoints (using the monitor commands to
break at given points).

.vo B68A
Child Jobs:
B491
Mailboxes:
Semaphores:
Regions:
Segments:
Extensions:
Composites:

.vk

Max priority
Parameter obj
Job flags
Parent job
Initial size
Largest seg

00
BFB8
0000
BFDD
0800
0764

If the code hadn't completed executing, results like
this might indicate deadlock. The tasks would have
to be examined to see how long they were asleep. If
they are all asleep forever, nothing further will
happen without an external event.

The command 'vo job-token' shows all the objects
that have been created in a job. The token for each
object contained by that job will be shown, listed
after a designation for which type of object it is. You
can check for the presence of leftover segments at
the end of a task's execution with this command.
Before executing the application code, the following
list shows what the command and its results look
like.

By using the SDB command 'vk', the tasks that are
ready or sleeping can be seen. After running the
user job to completion, the result of the 'vk' command looks like this:

Max priority
Parameter obj
Job flags
Parent job
Initial size
Largest seg

It is useful to insert 'CAUSE$INTERRUPT (3)' calls at points when the task is likely to transfer control (such as after sending or receiving messages). When the application is running properly, remove the 'CAUSE$INTERRUPT (3)' calls to allow the
code to execute unattended. Breakpoints can also be
used to monitor the code.
2-201

260047-001

inter

AP-221

If you write your own exception handler, you have
to decide upon which conditions it will be invoked.
You must compile, link and locate the exception
handling code, and determine the starting address of
the exception handler, This value must be configured into the operating System as the User Job's exception handler address. Each task can also have its
own exception handler by using the call
RQ$SET$EXCEPTION$HANDLER. An exception handler is the preferred method of handling exceptions, but exception handlers are beyond the scope of this application note. An exception handler would eliminate the need for GOTOs in the code. GOTOs are considered bad programming practice in most structured' languages. MULTIPLE TASK APPLICATION EXAMPLE For the second example, the same initial code, Inittask, was used. The main module is called Main$task as it was for the single task example. The same
configuration of the iRMX 86 Operating System is
used, since the start address is the same for both
applications. The code for this example, 'called
Tasks, is shown in Appendix C, The main module
for this example creates three tasks, and lets them
do the work, A diagram of the system is shown in
Figure 3.

The three tasks are set up according to their
function. This very simple example of a machine
control system makes the classic product, widgets.
One task is the supervisor and controls the other two
tasks. It sends messages to the other tasks to tell
them what to wri~e or how many widgets to make.
The second task, called IO$task, outputs messages which it has received from Supervisor$task to the
terminal. The third task, called Widget$task, makes widgets. In this example, Widget$task is essentially a
no-op task, but it could easily be replaced with code
that implemented a real application.

MAIN$TASK The code in the second example has an initial module which creates three tasks, and then waits at a mailbox for them to complete execution. The initial module then deletes the three tasks and the mailboxes it has created. When everything is cleaned up, it deletes the application job. The initial task not only creates the mailbox it needs for signaling when the tasks are done, but it also creates the other four mailboxes that are used by the three tasks to communicate with each other. The mailboxes are cataloged in the user job's directory, and each task must look up the mailboxes it needs to use. ROOT JOB (deletes itself after initialization) BIOS JOB APPLICATION JOB SDBJOB 2081 Figure 3. Multiple Task System 2-202 280047-001 AP-221 Pseudocode for Main$task
create mailboxes
catalog mailboxes injob's directory
create Supervisor$task create Widget$task
create IO$task receive message from Supervisor$task (done)
delete mailboxes
delete myself

SUPERVISOR$TASK Supervisor$task is created with the highest priority
of the three tasks. It happens to be created first, but
because it has the highest priority it would execute
first regardless of when it was created. Supervisor$task controls the other two tasks. The other two tasks are created with priorities lower than both Supervisor$task and the creating task. If one of them
had been created with a priority higher than the
creating task and had been the first one created, it
would have begun executing as soon as it was
created, preventing the creator task from creating
Supervisor$task. Pseudocode for Supervisor$task
lookup mailboxes in job's directory
do 1 to 10
send message to Widget$task (make widget) send message to IO$task (making widget, message)
receive message from Widget$task (done) receive message from IO$task (done)
end
send message to Widget$task (cleanup) send message to IO$task (cleanup)
receive message from Widget$task (done) receive message from IO$task (done)
cleanup by deleting segments
send message to Main$task (done) The supervisor allows Widget$task and IO$task to work as independently as possible. It sends messages to both of them, and then waits for both to reply before it repeats the loop. This approach allows the tasks to execute when they can get the processor, completely independently of each other. We can also look at the ready list at various points in the code and see which task is executing. Tasks will not always execute in the same order with this method. Because each task is required to wait for a message indicating that it may run, IO$task cannot inform
the console that a widget is being made any sooner
than Widget$task begins to make the widget. If the sends and receives had instead been paired (sending then receiving from the same task) Supervisor$task
could have guaranteed which task would be executing at any given point in the code.
2-203

Supervisor$task is sending information in the mailboxes to each task. In the single task example, a simple segment with no information content was sent between the creating task and the created task to signal that the created task was done executing. A semaphore could have been used just as well in that example. In this multitasking example a semaphore would not work. Information is being passed to each of the tasks to tell them whether or not to continue executing, or that they should clean up their environments. In addition, Supervisor$task is
passing to IO$task a message that will be printed out. To pass the message, a structure is used. The structure contains values, rather than tokens for objects. The values are moved into the structure with the MOVB PUM call prior to sending the structure's token through the mailbox. Structures which contain tokens should be avoided, especially when using mailboxes which communicate between jobs. On more advanced processors than the iAPX 86, operating systems may be implemented in which jobs have disjoint address spaces. In that case, a token may have different values in different jobs. The iRMX 86 Operating System will expect this convention to be followed but will not enforce it. Future operating systems may enforce the convention. This example is completely contained within one job, so it isn't quite as restricted. WIDGET$TASK
Widget$task is extremely simple for this example. This portion in a real application would probably be the most complex, since it would involve the machine interfaces for a control process. It could also include any mathematical calculations which need to be done. Pseudocode for Widget$task
look up mailboxes
receive message from Supervisor$task (make widget) do while make widget is true send message to Supervisor$task (done)
receive message from Supervisor$task (make widget) end cleanup the environment send message to Supervisor$task (done)

IO$TASK This task is very similar to First$task in the first
example. The main difference between the two is
the way the information for the messages is given to
the tasks. In Onetask, the message was defined
within the task. In IO$task, the information for the message is passed to IO$task via a mailbox from
Supervisor$task. This task illustrates how to do simple l/O with just the BIOS. 280047-001 inter AP·221 not shown here keeps the three tasks all at the same priority, and uses mailboxes to allow the tasks to execute in a strictly defined order. The implementation shown in this example is quite general purpose, and doesn't use as many mailboxes as the alternative implementation would. This implementation also allows the tasks to have more freedom in when they can run, and uses the processor more efficiently if one of the tasks is blocked while doing I/O. Pseudocode for IO$task

,
look up mailboxes
receive message from supervisor (making
widget, message)
create user
physically attach terminal
get device connection
'
create file
get file connection
open file
receive message from Supervisor$task (making widget, message) do while making widget is true write message (Making widget) delete segments send message to Supervisor$task (done)
receive message from Supervisor$task (making widget, message) end close file delete file connection detach device delete user cleanup environment by deleting segments send message to Supervisor$task (done)

As more tasks are used, and as more mailboxes are
used to communicate between the tasks, the possibility of deadlock increases. Deadlock usually is
caused by faulty design, and may appear when
debugging of the code begins. Evidence of possible
deadlock occurs when all the tasks are sleeping, and
no tasks are ready when you use the SOB command
'vk' to check what's going on. This situation can be
caused by sending a message to the wrong mailbox,
or by not creating segments to send within a loop
that is sending messages. An example of deadlock
can be obtained by changing the code in Supervisor$task in some minor ways. Mailboxes Executes correctly: In this application, mailboxes are used for several purposes. Their most obvious purpose is to send information between tasks. Less obvious but more important is the role they play in allowing mutual exclusion and synchronization between tasks. Do i := 1 to 10 create segments send message to Widget$task (make widget)
seRd message to IO$task (making widget, message) receive message from Widget$task (done)
delete segment
receive message from IO$task (done) delete segment end The simplest messages in the application return an empty segment to the mailbox to indicate that the task has completed some portion of work, and the receiving task can continue. This empty segment is the kind of message that Widget$task and IO$task send to Supervisor$task, and the kind of message
that Supervisor$task sends to Main$task when it has
completed execution. This exchange could be accomplished just as well by using a semaphore rather
than a mailbox.
The more complex messages contain some
information. In this example, the message contains
information indicating that the task should continue
executing a loop, or that it is time to clean up the environment and exit. The message that was sent between Supervisor$task and IO$task also contained
the message that Supervisor$task wanted IO$task to
print out. This example illustrates the kind of informatiori that can be passed between tasks using
mailboxes.
Mailboxes are also used in this application to implement mutual exclusion and synchronization betweeri
the tasks. O,ne alternative implementation ~hich is
2-204

create segments
Do i := 1 to 10
send message to Widget$task (make widget) delete segment send message to IO$task (making widget, message)
delete segment
receive message from Widget$task (done) receive message from IO$task (done)
end
The second code example results in deadlock because the object which is sent. to the mailbox is created outside the loop. Once it is sent, there is no
longer an object to send, and the receiving task can't
continue unless it has a timeout specified because it
never receives another object. With a different synchronization scheme, 'if the receiving task hadn't
deleted the message, that object could have been
sent again.
280047-001

inter

AP-221

Key plac~s to watch for deadlock in the code are
where some communication occurs between the
tasks. Other situations that can cause deadlock are
tasks needing the same resources, such as a unit
from a semaphore, or a region. Insufficient memory
will cause an E$MEM error rather than deadlock. and locating the application code. The same definition file was used for both applications, and the same submit file was used to link and locate the applications. Configuration of the iRMX™ 86 Operating System Initialization Supervisor$task controls the other two tasks. This
control is necessary since the tasks cannot execute
more than a few lines of code without receiving a
message from the supervisor. The tasks execute a
few lines of code to lookup the mailbox which they
will use to communicate with the other tasks. Then
they can make the RQ$RECEIVE$MESSAGE call.
The task with the highest priority which was created
first, and as a result, has been ready the longest, will
execute first. Since Supervisor$task was created with a higher priority than the other two tasks, it will execute first. By the time it gives up control of the processor, it has already sent messages to both of the other tasks. The task that has been ready the longest at this point will execute first. In this example, the first executed task happens to be Widget$task,
since it was created before 10$task was. Debugging The same techniques are used to debug a multiple task application as were discussed in the single task example. Look at the .MP2 file before beginning debugging, and find the entry points to each task. The .MP2 file is produced as a result of the LOC86 step in building the application. Use 'CAUSE$INTERRUPT (3)' calls at the beginning of
each task, and keep track of which task is executing
at a given time. One technique that was used in this
application to make it easier to debug was to send all
errors to an error routine within each task. The error
routine was different in each task (outputting AIH
for the first task, A2H for the second task, etc.). It
was immediately obvious by looking at the disassembled code containing the call which task caused the
exception.
As a second debug alternative, the iRMX 86 Dynamic Debugger is also useful in a multiple task
application. Rather than halting the entire system
like the SDB does, the Dynamic Debugger allows
users to examine vital system objects while the
system is running. The Dynamic Debugger must be
configured into the Operating System with its own
terminal handler and its own terminal if the BIOS is
used.

For both examples in this application note, the same
operating system configuration was used. The layers
used are the Nucleus (for scheduling and intertask
communication) and the BIOS (so that I/O could be
done). The SDB, for debugging the code, was also
configured into the operating system as a user job.
The only device driver required is the terminal
driver. The listing of the operating system definition
file is shown in Appendix E.

User Jobs
This application code is configured into the operating
system as a user job. The Interactive Configuration
Utility (lCU) requires information to be given about
the user job, and sets up a %JOB macro for the job.
However, the ICU does not set aside memory for
the user job, and it does not link and locate the job
as it does for the layers of the operating system.
An application that uses only nucleus and BIOS calls
is a user job. If the application uses the EIOS or the
Human Interface, it is an I/O job and must be configured as a child job of the EIOS. Applications can
also be run from the Human Interface level, as jobs
under the Human Interface. In a real-time
application, treating the application as a user job or
user jobs is usually most appropriate. During
development, however, the application could be run
under the Human Interface. This technique would
eliminate rebooting after each code change or trial
run to test the application.
The following parameters appear in the User Jobs
screen in the ICU. Each parameter is defined and explained in the context of the example application.
JOB NAME (NAM)

The first question in the User Jobs screen for the
iRMX 86 Release 6 ICU is Job Name. This question
is optional, and is just used for the user to keep track
of which user job is being configured in the screen. It
is not used by the ICU.
OBJECT DIRECTORY SIZE (ODS)

CONFIGURATION
There are two steps involved in configuration: configuring the operating system; and compiling, linking
2-205

Object directory size refers to how many objects can
be cataloged in the job's directory. In the first
example, the only object that is being cataloged is
280047-001

AP-221

the mailbox DONEMBX which is used to let the
main task know that First$task has completed. In the second example, five mailboxes are cataloged, so the object directory size doesn't have to be very big for this application. The default value for this parameter is IOH, which is large enough for this application. If you have a large application and many objects are cataloged, this number would have to be increased. For small applications, a small value can be used to conserve memory. Memory is allocated for the object directory of a job when the operating system is initialized. OOOOH:OOOOH. If the user job had its own exception handler, the correct address of that exception handIer would have to be found by first linking and locating the application code and the exception handler, and then looking in the .MP2 file for the address of the exception handler. EXCEPTION MODE (EM) The exception mode is set to 'never' for this user job, indicating that the exception handler won't be invoked for any kind of error condition. Instead, exceptions will be handled in-line in the example code. POOL MINIMUM, POOL MAXIMUM (PMI, PMA) Pool minimum and pool maximum are closely related. They specify the amount of memory that the job requests from its parent. For this example, a pool minimum and pool maximum size of 500H was chosen. The minimum and maximum should be set to the same value in the user job to avoid memory fragmentation. The Human Interface is usually the only exception to this rule. MAXIMUM OBJECTS (MOB) This parameter defines how many objects can be created by the application. For this application, the maximum objects was set to 20H, but only 10 objects existed at any given time. In a larger application, of course, 20H could easily become insufficient. To determine how many objects are being used at a given point in time, use the SDB command 'vo userjob-token'. MAXIMUM TASKS (MTK) PARAMETER VALIDATION (PV) Parameter validation is used by the nucleus to determine if the parameters passed in system calls are valid. This question should be answered yes until the application code is debugged. If the BIOS or other upper layers are being used in the operating system, parameter validation should be enabled even when the application code is debugged, or the Operating System will not work. If parameter validation is turned off, the nucleus calls will execute faster, so setting parameter validation to 'no' can improve perform!1nce. TASK PRIORITY (TP) Task priority sets up the static priority of the initial task which is created for the user job. For this application, the priority of the task is set to 82H, or 130. TASK START ADDRESS (TSA) The next parameter specifies the maximum number of tasks whiCh can be created by tasks in this user job. This application used the default value of lOH, but could have used 4H, since only three tasks were created (one task was created by the root job to be the .user job task). The definition file was being used by both the single task example and the multiple task example, so the default value is appropriate. The Task Start Address is the start address of the job's initialization task. This address is determined from the .MP2 file after locating the application code. For both example applications this address was I500H:0002H. MAXIMUM PRIORITY (MPR) The maximum priority parameter refers to the maximum priority allowed of any task in this job which is created. This parameter was set to OH where OH indicates that the priority of the root job is the maximum allowable priority of the tasks. The root job's priority in this. operating system is OOH, which doesn't limit the maximum allowable priority. ADDRESS OF EXCEPTION HANDLER (AEH) This application is using the system exception handler. so the address of exception handler used is 2-206 DATA SEGMENT BASE (DSB) The data segment base is set to OOOOH, which allows the task to set up the data segment base for the initial task of the user job. Since the LARGE model of compilation was used, the parameter can be set to zero. STACK SEGMENT ADDRESS (SSA) The stack segment address is also set to OOOOH:OOOOH to allow the nucleus to allocate a stack segment to the task and take care of initializing the SS and SP registers. This setting permits dynamic stack allocation and deallocation. 280047-001 AP-221 STACK SIZE (SS) WARNING 12: UNRESOLVED SYMBOLS The stack size for the task is set to 300, which is the amount that is considered necessary to make any nucleus system calls. Since this application was very small, it didn't need a very large stack. If a job used a lot of subroutines and nested procedures with many parameters, or if the job was recursive, the amount of stack needed could increase. WARNING 26: DECREASING SIZE OF SEGMENT SEGMENT: STACK NUMERIC PROCESSOR EXTENSION USED (NPX) WARNING 66: START ADDRESS NOT SPECIFIED IN OUTPUT MODULE CONCLUSION The 8087 Numeric coprocessor was not used in this application task. If any floating point functionality is needed within a task, this parameter should be set to yes in the configuration process. Ram The last parameter which must be considered when creating the definition file for the application is the amount of RAM required and where it is located. This is a parameter in the memory screen of the ICU. Remember that the ICU does not locate the user job for you, so memory must be specifically set aside to be used by the user job. In this application, the RAM that was used was from 0104H to 1500H, and from 1800H to F7FFH. The user job was allowed to use RAM from 1500H to 1800H (these numbers are specified in paragraphs of 16 bytes each). The operating system itself was put into the memory from 104H to just under 1500H. This location can be determined by looking at the .MP2 files for each of the layers of the operating system after completing the configuration. Linking and Locating the Application The submit file that was used for this application is shown in Appendix D. Note first of all that instead of using the name of the application code program, a %0 was used. This convention allows you to invoke the submit file with a parameter which is the name of the application code program. The same submit file was used for both examples. Note that Inittask is linked with the INITCODE option. This is necessary with LINK86 v 2.0 and LOC86. The INITCODE option is not necessary with other versions of LINK86. While the submit file is running, some warnings will be generated. The following errors are normal and should be ignored. 2-207 This application note is an introduction to the basic functions of the iRMX 86 Operating System Nucleus. Task scheduling and memory management functions were covered in detail. Two applications were discussed, using some pieces of code in common. The functions involved in developing and testing real-time code were explained while using the application code for examples and reference. Configuration of the application operating system was also covered in detail. The examples shown in this application note illustrate how to develop a real-time application. The first example shows how to use the nucleus and BIOS to do simple I/O at the lowest, most optimizable level. The second example builds on the concepts developed in the first example, expanding the application to a more realistic process control situation. Both examples shown earlier are fairly simple. They illustrate what has to be done to create and use a task. They are good examples for a user who has written a limited amount of PUM 86 code using the nucleus system calls. The multiple task example would be a good foundation for a process control application. Each of the tasks in the second example shows a major function of real time code, demonstrating control, 110, and supervisory functions. The iRMX 86 Operating System is ideally suited to multi-tasking, real-time applications. The ability to use the same system for both development and as the target system is a great benefit to the development engineer and the company which is developing real-time applications. The modularity provided by the iRMX 86 Operating System and the PUM 86 language make it easier to develop code for one application, then modify it for another application. The ultimate benefits to users are reduced development time, added cost savings, and shorter timeto-market for new products. 280047-001 inter AP-221 APPENDIX A: APPENDIX B: APPENDIX C: APPENDIX D: APPENDIX E: APPENDIX F: 2-208 280047-001 inter AP-221 APPENDIX A PL/M-86 COMPILER single task creation; for ap note iRMX 86 PL/M-86 V2.1 COMPILATION OF MODULE INITTASK OBJECT MODULE PLACED IN INITTASK.OBJ COMPILER INVOKED BY: :LANG:plm86 INITTASK.P86$large rom debug
$title('single task creation; for ap note') 1 = 4 5 i 2 /********************************************************* * This is an example to be used for an ap note on task * * scheduling. * * Cathy Lundberg 03/22/84 * *********************************************************/ inittask: do;$INCLUDE (/RMX86/INC/NEINIT.EXT)
$SAVE NOLIST main$task: PROCEDURE EXTERNAL;
END main$task; /********************************************************* * This separate module is used to keep the user job's * * start address constant while changing the code. * * This module has no data or constants in it. all it * * does is call the main routine. main$task. after
*
* calling rq$end$init$task. * *********************************************************/ 6 1 begin: PROCEDURE PuBLIC; 7 8 2 2 9 2 CALL rq$end$init$task;
CALL main$task; END begin; 10 1 END inittask; MODULE INFORMATION: CODE AREA SIZE = 0018H CONSTANT AREA SIZE = OOOOH VARIABLE AREA SIZE = OOOOH MAXIMUM STACK SIZE = 0008H 36 LINES READ o PROGRAM WARNINGS o PROGRAM ERRORS 24D OD OD 8D 2-209 280047-001 AP-221 DICTIONARY SUMMARY: 112KB MEMORY AVAILABLE 3KB MEMORY USED (2%) OKB DISK SPACE USED END OF PL/M-86 COMPILATION 2-210 280047-001 AP-221 APPENDIX 8 PL/M-86 COMPILER single task creation; for ap note iRMX 86 PL/M-86 V2.1 COMPILATION OF MODUlE OMETASK OBJECT MODUlE PLACED IN ONETASK.08J COMPILER INVOKED BY: :LANG:PLM86 ONETASK.~86 Slarge rom debug Stitle('stngle task creation; for ap note') onetask: DO; 1 /********************************************************* * This is an example to bp. used for an ap note on task * * schedul ing. * * Cathy Lundberg 03/22/84 * ****************************************************~••**/ /* The include for LTKSEL.LIT must bp. done before any other 1ncludts, * because anything that uses TOKENS must have the data type defined * for a token. */ = = SINCLUDE (/RMX86/INC/LTKSEL.lIT) SSAVE NOLIST . SINCLUDE (/RMX86/INC/NEXCEP.LIT) Ssave nolist SINCLUDE (/RMX86/INC/NUC.EXT) SSAVE NOLIST SINCLUDE (/RMX86/INC/BIOS.EXT) SSAVE NOLIST /***************************************************.**.*********.******** * mainStask is the procedure that is called by inittisk to create the * * task 'firstStask'. It creates a mailbox, cre~tes the task, and then, * * waits at the mailbox, allqwing firstStask to execute. When ffrst$task*
* finishes and sends a message to the mailbox, control is returned to *
* mafn$task, and it deletes first$task and the mailbox.
*
**********************************.*.**************.*********************/
280

1

PROCEDURE REENTRANT PUBLICi

281

2

DECLARE job
data$seg userStoken taska done$writ fngSmbx
resp

TOI(EN,
TOKEN,
TOKEN.
TOKEN,
TOKEN.
TOKEN;

282

2

status

WORD.
WORD.
WORD;
2-211

inter

.AP·221

, POINTER,
DECLARE seg$pointer POINTER, startSaddress POINTER, taska$ptr.
stack$pointer POINTER; LITER ALL Y , 300 I ; DECLARE stack$s.ize$300 DECLARE priority$level$202 LITERALLY '202 1 ; DECLARE iors$token
SELECTOR;
. TOKEN
, DECLARE done$obj AT(@iors$token);
DECLARE iors
BASED
STRUCTURE
iors$token (status WORD, unitSstatus WORD, actual WORD) ; 283 2 284 285 286 287 288 2 2 2 2 2 289 290 291 292 2 2 2 2 293 2 294 295 297 2 2 2 298 300 301 2 2 2 302 3 303 3 305 0, 3 done$obj

306

3

@status);
IF status <> E$OK THEN GOlO error; 308 309 311 312 314 315 316 317 319 3 3 3 3 3 2 2 320 2 321 322 3 3 2 2 data$seg
= 0;
stack$pointer =0; task$flags
= 0;
job
= 0;

/*
/*
/*
/*

task sets up own data segment */
automatic .stack allocation */
no floating point */
catalog object in containing job */

CA4SE$INTERRUPT (3); /* create a mailbox to use for letting this task know * that the ~ask it created is done writing. */ done$writing$mbj( = rq$create$mailbox (0, @status); IF· status <> E$OK THEN GOTO error;
CALL rq$catalog$object (0, done$writing$mbx, @(7,IDONEMBX'),
@status);
.
IF status<> E$OK THEN GOTO error; CAUSE$INTERRUPT (3);
DO I = 1 TO 1000; .
/* Now create taska.*/
taska = rq$create$task( priority$l eve 1$202 ,@first$task, data$seg, stack$pointer, stack$size$300, task$flags, @status);
IF status <> E$OK THEN GOTO error; == rq$receiv"e$message (done$writing$mbx, Offffh, CALL rq$delete$segment (done$obj, @status);
IF status <> E$OK THEN GOTO error; CALL rq$delete$task (taska, @status); IF status <> E$OKTHEN ~TO error;
END; /* of DO WHILE loop */
CAUSE$INTERRUPT . (3); CALL rq$delete$mailbox (done$writing$mbx, @status); IF status <> E$OK THEN GOTO error;
GOTO ok;
error:
DO WHILE 1;
OUTPUT(9CH)
END;

~

/* output to usart to determine which */
/* task had the error. For debugging.*/
OAAH;

2-212

280047-001

AP-221

323

2

ok:

CALL rq$delete$job (0, @status); /* delete myself */
324

2

END main$task; /************************************************************************* * FIRST$TASK is the task which is created by main$task. It creates * * the necessary mailboxes and segments, and then attaches the terminal * * physically. It then creates a file so that it has a file connection.* * It opens the file connection, and writes the contents of a buffer to * * * the terminal. Then it closes the file connection, deletes the * device connection, and detaches the device. Last, it looks up the * * mailbox created in main$task and sends a message to the mailbox.
*
* This allows control to return to main$task. * *************************************************************************/ 325 1 first$task: PROCEDURE REENTRANT PUBLIC;

326

2

DECLARE

327
328
329
330

2
2
2
2

DECLARE
DECLARE
DECLARE
DECLARE

331

2

DECLARE

332

2

DECLARE

333

2

DECLARE

334

2

335
336
337

2
2
2

user$object.length user$object.count
user$object.id(O) 338 339 2 2 job = 0; hard = OffH; job mbx$token
seg$token user$token
fil e$connect ion device$connection
done$token done$writing$mbx status hard iors$token
dev$conn$object
file$conn$object
object
iors
BASED
( status
unit$status ac tua 1 buffer TOKEN, TOKEN, TOKEN, TOKEN, TOKEN, TOKEN, TOKEN, TOKEN; WORD; BYTE; TOKEN; TOKEN AT (@iors$token),
TOKEN AT (@iors$token), TOKEN AT (@iors$token);
iors$token STRUCTURE WORD, WORD, WORD) ; seg$token (1)
BASED

user$object (1 ength count id (1) DECLARE message(*) STRUCTURE WORD, WORD, WORD) ; DATA BYTE BYTE; ('SINGLE TASK TEST'); = 1; 1; OFFFFH; /* catalog object in containing job */ /* request a hard detach of the device */ 2-213 280047-001 AP-221 340 341 343 344 346 347 2 2 2 2 2 2 user$token = rq$create$user (@user$object, @status); IF status <> E$OK THEN GOTO error;
mbx$token = rq$create$mailbox (0, @status); IF status <> E$OK THEN GOTO error;
seg$token = rq$create$segment ( 48, @status); IF status <> E$OK THEN GOTO error;

349

2

CALL rq$a$physical$attach$device ( @(2,'TO'), I, mbx$token, 350 352 2 2 353 355 2 2 @status); IF status <> E$OK THEN GOTO error;
dev$conn$object.= rq$receive$message (mbx$token, OFFFFH, 0, @status); IF status <> E$OK THEN GOTO error;
d~vice$connection = dev$conn$object; 356 2 CALL rq$a$create$file (user$token, device$connection, '

357
359

2

360
362

2
2

363
364
366
367
369
370

2
2
2
2
2

IF status <> E$OK THEN GOTO error; object = rq$receive$message (mbx$token, OFFFFH, 0, @status);
IF status <>E$OI( THEN GOTO error; CALL rq$delete$segment (object, @status); IF status <> E$OK THEN GOTO error;

372
373

2
2

CALL movb( @message, @buffer, SIZE(message»);
CALL rq$a$write (file$connection, @buffer, size(message), 374 376 377 379 380 2 2 2 2 2 i 0, 0, 0, 0, 0, mbx$token, @status);
IF status <> E$OK THEN GOTO error; file$conn$object = rq$receive$message (mbx$token, OFFFFH, 0,
@status);
IF status <> E$OK THEN GOTO error; file$connection = file$conn$object;

CALL rq$a$open (file$connection, 2, 0, mbx$token, @status);

2
2

mbx$token, @status); IF status <> E$OK THEN GOTO error;
object =rq$receive$message (mbx$token, OFFFFH, 0, @status); IF status <> E$OK THEN GOTO error;
CALL rq$delete$segment (object, @status);
IF status <> E$OK THEN GOTO error; 2 CALL rq$a$close (file$connection, mbx$token, @status); 2 2. 2 2 2 IF status <> E$OK THEN GOTO error;
object = rq$receive$message (mbx$token, OFFFFH, 0, @status); IF status <> E$OK THEN GOTO error;
CALL rq$delete$segment (object, @status);
IF status <> E$OK THEN GOTO error; 3 E$OK THEN GOTO error;
object = rq$receive$message (mbx$token, OFFFFH, 0, @status); IF status <> E$OK THEN GOTO error;
CALL rq$rlelete$segment (object, @status);
IF status <> E$OK THEN GOTO error; 280047-001 inter AP-221 400 ? 401 403 404 406 407 2 2 2 2 2 CALL rq$a$physical$detach$device (device$connection, hard,
mbx$token, @status); IF status <> E$OK THEN GOTO error;
object = rq$receive$message (mbx$token, OFFFFH, 0, @status); IF status <> E$OK THEN GOTO error;
CALL rq$delete$segment (object, @status);
IF status <>E$OK THEN GOTO error; 409 410 2 2 CALL rq$delete$mailbox (mbx$token, @status);
IF status <> E$OK THEN GOTO error; 412 413 415 416 418 419 421 2 2 2 2 2 2 2 422 424 2 2 425 427 428 430 431 433 2 2 2 2 2 434 2 435 436 3 3 error: DO WHILE 1; OUTPUT(9CH) END; 437 2 ok: 438 439 440 441 3 2 3 2 1 CALL rq$delete$user (user$token, @status);
IF status <> E$OK THEN GOTO error; CALL rq$delete$segment (seg$token, @status);
IF status <> E$OK THEN GOTO error; , done$token = rq$create$segment ( 16, @status);
, IF status <> E$OK THEN GOTO error; done$writing$mbx = rq$lookup$object (0, @(7,'DONEMBX'), 500, @status); IF status <> E$OK THEN GOTO error;
CALL rq$send$message (done$writing$mbx, done$token, 0, @status); IF status <> E$OK THEN GOTO error;
CALL rq$delete$segment (done$token, @status); /* this code */ IF status <> E$OK THEN GOTO error;
/* shouldn't be*/
CALL rq$delete$mailbox (done$writing$mbx, @status);
IF status <> E$OK THEN GOTO error; /* executed */ GOTO ok; /* output to usart for debugging */ = OAAH; DO; CALL rq$suspent1$task (0, @status); END; END first$task;

/* slJspend myself */

MODULE INFORMATION:
CODE AREA SIZE
= 0554H
CONSTANT AREA SIZE = 0023H
VARIABLE AREA SIZE = OOOOH
MAXIMUM STACK SIZE = 0040H
o PROGRAM WARNINGS
o PROGRAM ERRORS

13640
350
00
640

2-215

)

280047-001

inter
DICTIONARY SUMMARY:
84KB MEMORY AVAILABLE
20KB MEMORY USED (23%)
OKB DISK SPACE USED
END OF PL/M-86 COMPILATION

2-216

280047-001

inter

AP-221

APPENDIX C
PL/M-86 COMPILER

three task creation; for ap note

iRMX 86 PL/M-86 V2.1 COMPILATION OF MODULE TASKS
OBJECT MODULE PLACED IN TASKS.OBJ
COMP1LER INVOKED BY: :LANG:PLM86 TASKS.P86

$large rom debug$title('three task creation; for ap note')

1

/*********************************************************
* This is an example to be used for an ap note on task *
* schedul ing.
*
* Cathy Lundberg 04/23/84
*

************************~********************************/

/* The include for LTKSEL.LIT must be done before any other

* includes, because anything that uses TOKENS must have the
* data type defined for a token. */

$INCLUDE (/RMX86/INC/LTKSEL.LIT)$SAVE NOLIST
$INCLUDE (/RMX86/INC/NEXCEP.LIT)$save nolist
$INCLUDE (/RMX86/INC/NUC.EXT)$SAVE NOLIST
$INCLUDE (/RMX86/INC/BIOS.EXT)$SAVE NOLIST

/*************************************************************************
* MAIN$TASK is the procedure that is called by inittask to create the * * three tasks. IO$task outputs to the screen. Widget$task makes * * widgets. Supervisor$task controls what IO$task and widget$task are *
* doing. When widget$task has made X widgets, supervisor$task sends *
* a message to IO$task saying that X widgets have been made, and the * * message is printed by IO$task. Then it sends a message to
*
* main$task to tell it that the tasks are done executing. Main$task *
* has been waiting at a mailbox for that welcome news, and when it
*
*
* receives the message, it deletes all three tasks.
*************************************************************************/

280

1

main$task: PROCEDURE REENTRANT PUBLIC; 281 2 DECLARE data$seg
IO$task$token
widget$task$token
supervisor$task$token
2-217

TOKEN,
TOKEN,
TOKEN,
TOKEN,
280047-001

AP·221

lila in$super$mbx
write$msg$mbx
start$write$mbx
done$write$mbx
start$widget$mbx
done$widget$mbx
DECLARE task$flags. status TOKEN. TOKEN. TOKEN. TOKEN. TOKEN. TOKEN; WORD. WORD. WORD; POINTER; LITERALLY '300' ; LITERALLY '202' ; LITERALLY '190'; SELECTOR; AT (@iors$token);
iors$token STRUCTURE WORD. _WORD. WORD); 282 2 283 284 285 286 287 288 289 2 2 2 2 2 2 2 290 291 292 2 2 2 data$seg
= 0;
stack$pointer = 0; task$flags
= 0;

293

2

294
,295
297
298
300
301
303
304
306
307
309

2
2
2
2
2
2
2
2
2
2.
2

310
312

2
2

313
315

2
2

316

2

CAUSE$INTERRUPT (3); /* create a mailbox to use for letting this j~b know * that the tasks are done executing. */ main$super$mbx = rq$create$mailbox (0. @status); IF status <> E$OK THEN GOTO error;
start$write$mbx = rq$create$mailbox (0. @status);
IF status <> E$OK THEN GOTO error; done$write$mbx = rq$create$mailbox (0. @status); IF status <> E$OK THEN GOTO error;
start$widget$mbx = rq$create$mailbox (0. @status);
IF status <> E$OK THEN GOTO error; done$widget$mbx = rq$create$mailbox (0. @status); IF status <> E$OK THEN GOlO e~ror;.
CALL rq$catalog$object (0. main$super$mbx. @(9.'"AINSUPER').
@status);
IF status <> E$OK THEN GOlO error; CALL rq$catalog$object (0. start$write$mbx. @(lO.'STARTWRITE'). @status); IF status <> E$OK THEN GOTO error;
CALL rq$catalog$object (0. done$write$mbx. @(9.'DONEWRITE').
.
@status);
IF status <> E$OK THEN GOTO error; 318 2 319 321 2 2 322 324 2 2 i DECLARE DECLARE DECLARE DECLARE DECLARE DECLARE DECLARE stack$pointer
stack$size$300

priority$lev~1$202

priority$level$190
iors$token done$obj
TOKEN
iors
BASED
(status
un it$status actual /* task sets up own data segment */ /* automatic stack allocation */ /* no floating point */ CALL rq$catalog$object (0. start$widget$mbx, @(ll.'STARTWIDGET'). @statlJs); . IF status <> E$OK THEN GOTO error;
CALL rq$catalog$object (0. done$widget$mbx.
,
@(10. 'DONEW-IDGET'). @status);
IF status <> E$OK THEN GOTO·error; CAUSE$INTERRUPT (3);
2-218

280047-001

inter

AP-221

/* Now create the tasks. */

325

2

326
328

2
2

329
331

2
2

332

2

supervisor$task$token = rq$create$task (priority$level$190,
@supervisor$task, data$seg, stack$pointer, stack$s1ze$300, task$flags, @status);
IF status <> E$OK THEN GOTO error; widget$task$token = rq$create$task (priority$level$202, @widget$task, data$seg, stack$pointer,
stack$size$300, task$flags, @status); IF status <> E$OK THEN GOTO error;
IO$task$token = rq$create$task (priority$level$202, @IO$task, data$seg, stack$pointer, stack$size$300, task$flags, @status);
IF status <> E$OK THEN GOTO error; 334 ? done$obj

335
337

2

@status);
IF status <> E$OK THEN GOTO error; CAUSE$INTERRUPT (3);

338
339
341
342
344
345
347
348
350
351
352
354
355
357
358
360
361
363
364
366
367

2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2

368
369

3
3

CAtl rq$delete$segment (done$obj, @status); IF status <> E$OK THEN GOTO error;
CAll rq$delete$task (IO$task$token, @status);
IF status <> E$OK THEN GOTO error; CAll rq$delete$task (widget$task$token, @status); If status <> E$OK.THEN GOTO error;
CAll rq$delete$task (supervisor$task$token, @status);
IF status <> E$OK THEN GOTO error; CAUSE$INTERRUPT (3);
CAll rq$de 1ete$ma 11 box (ma in$super$mbx, @status);
IF status <> E$OK THEN GOTO error; . CAll rq$delete$mailbox (start$write$mbx, @status); IF status <> E$OK THEN GOTO error;
CAll rq$delete$mailbox (done$write$mbx, @status);
IF status <> E$OK THEN GOTO error; CAll rq$delete$mailbox (start$widget$mbx, @status); IF status <> E$OK THEN GOTO error;
CAll rq$delete$mailbox (done$widget$mbx, @status);
IF status <> E$OK THEN GOTO error; GOTO ok; error: /* output to usart for debugging */ DO WHILE 1; OUTPUT(9CH) = OAAH; END; 370 2 ok: 2 = rq$receive$message (main$super$mbx, OFFFFH, 0, CAll rq$delete$job (0, @status); /* myself */ END main$task;
/***********************************************************************
* This is the task which is controlling the other two tasks. It has *
* higher priority than them now, but could have the same priority
*
* since it uses the mailboxes to synchronize the tasks.
*
***********************************************************************/

371

2

2-219

280047-001

AP.-221

372

1

supervisor$task: 373 2 374 2 DECLARE oone$token
main$super$mbx
s tart$wr ite$mbx
done$write$mbx
start$widget$mbx
done$widget$mbx
cleanup$token make$wldget$token DECLARE status 375 2 DECLARE 376 2 DECLARE 377 378 2 2 DECLARE DECLARE 379 380 2 2 381 383 2 384 2 386 2 387 389 2 2. 390 392 2 2 393 2 395 396 2 3 397 3 398 400 3 3 401 3 402 3 404 3 2 PROCEDURE REENTRANT PUBLIC; TOKEN, TOKEN, TOKEN, TOKEN, TOKEN, TOKEN, TOKEN, TOKEN; WORD, WORD; i BASED cleanup$token (1) BYTE,
cleanup$ptr make$widget$ptr BASED make$widget$token (1) BYTE; BYTE DATA(O), cleanup$d
BYTE
DATA(l),
make$widget$d
BYTE
DATA('Making widget'),
message$d(*) BYTE DATA(l); making$widget$d TOKEN; send$to$io$token
send$to$ io$token STRUCTURE ( send$to$io BASED making$widget (1) BYTE,
message
(13) BYTE);

CAUSE$INTERRUPT (3); main$super$mbx = rq$lookup$object (0, @(9,'MAINSUPER'), OFFFFH, @status); IF status <> E$OK THEN GOTO error;
start$write$mbx = rq$lookup$object (0, @(10,'STARTWRITE'),
OFFFFH, @status);
IF status <> E$OK THEN GOTO error; done$write$mbx ='rq$lookup$object (0, @(9,'DONEWRITE'), OFFFFH, @status); IF status <> E$OK THEN GaTO error;
start$widget$mbx = rq$lookup$object (0, @(11,'STARTWIDGET'),
OFFFFH, @status);
IF status <> E$OK THEN GOTO error; done$widget$mbx = rq$lookup$object (0, @(10,'DONEWIDGET'), OFFFFH, @status); IF status <> E$OK THEN GOTO error;
DO i = 1 TO 10;
CAUSE$INTERRUPT (3); /* Send message to widget task, mailbox STARTWIDGET */ make$widget$token = rq$~reate$segment (SIZE(make$widget$d), @status); IF status <> E$OK THEN GOTO error;
CALL MOVB (@make$widget$d, @make$widget$ptr,
SIZE(make$widget$d));
CALL rq$send$message (start$widget$mbx, make$widget$token,
0, @status);
IF status <> E$OK THEN GOTO error; CAUSE$INTERRUPT (3);

2-220

280047·001

inter
405
406
408

3
3
3

409

3

410

3

411
413

3
3

414

3

415
417
418
419

3
3
3
3

421

3

422
424
425
426

3
3
3
3

428

3

429
430
432
433

2
2
2
2

434
436

2
2

437
438
440
441

2
2
2
2

442

2

443

2

445

2

AP-221

/* Send message to 10 task. mailbox STARTWRITE */
send$to$io$token = rq$create$segment ( 32. @status); IF status <> E$OK THEN GOTO error;
CALL MOVB (@message$d, @send$to$io.message. SIZE(message$d));
CALL MOVS (@making$widget$d. @send$to$io.making$widget. SIZE(making$widget$d)); CALL rq$send$message (start$write$mbx. send$to$io$token, O.
@status);
IF status <> E$OK THEN GOTO error; CAUSE$INTERRUPT (3);
/* Receive message from widget task. mailbox DONEWIDGET */
done$token = rq$receive$message (done$widget$mbx. OFFFFH, O. @status); IF status <> E$OK THEN GOTO error;
CAUSE$INTERRUPT (3); CALL rq$delete$segment (done$token, @status);
IF status <> E$OK THEN GOTO error; Receive message from 10 task. mailbox DONEWRITE */ done$token = rq$receive$message (done$write$mbx. OFFFFH. O.
@status);
IF status <> E$OK THEN GOTO error; CAUSE$INTERRUPT (3);
CALL rq$delete$segment (done$token. @status); IF status <> E$OK THEN GOTO error;
/* receiving messages from the tasks. they are done and we *
* are ready to tell them to clean up.
*/
END;
/*

/* Send message to widget task. mailbox STARTWIDGET */
cleanup$token = rq$create$segment ( SIZE(cleanup$d), @status);
IF status <> E$OK THEN GOTO error; CALL MOVS (@cleanup$d. @cleanup$ptr, SIZE(cleanup$d));
CALL rq$send$message (start$widget$mbx, cleanup$token, O. @status); IF status <> E$OK THEN GOTO error;
CAlJSE$INTERRUPT (3); /* Send message to 10 task, mailbox STARTWRITE */ send$to$io$token = rq$create$segment ( 32, @status);
IF status <> E$OK THEN GOTO error; CALL MOVS (@message$d, @send$to$io.message, SIZE(message$d)); CALL MOVS (@cleanup$d, @send$to$io.making$widget, SIZE(cleanup$d));
CALL rq$send$message (start$write$mbx, send$to$io$token, 0, @status); IF status <> E$OK THEN GOTO error;
/* Receive message from widget task, mailbox DONEWIDGET */
done$token = rq$receive$message (done$widget$mbx, OFFFFH, O. @status); 2-221 280047-001 ,i~ AP-221 ~~U~af~~E~~U~~O~31~EN GOTO ,error; 446 448 449 450 2 2 2 2 452 2 453 456 457 2 2 2 2 /*' Receive message from 10 task, mailbox DONEWRITE */ done$token = rqSreceive$message (done$write$mbx, OFFFFH, 0, @status); , IF status ,<> E$OK THEN GOTO error;
CAUSE$INTERRUPT (3); CALL rq$delete$segment (done$token,' @status);
IF status <> E$OK,THEN GOTO error; 459 2 CAUSE$INTERRUPT (3);

460
461
463
464

2
2
2
2

/* Send message to main task, mailbox MAI~SUPER */
done$token = rq$create$segment ( 16, @status); IF status <> E$OK THEN GOTO error;
CALL rq$send$message (main$Super$mbx, done$token, 0, @statIJs); IF status <> E$OK THEN GOTO error;

466
467
469

2
2
2

CALL rq$suspend$task (0, @status);
IF status <> E$OK THEN GOTO error; GOTO ok; 470 2 471 472 3 3 473 2 4~5 CALL rq$del ete$segment (dQI1.e$token, @status);
IF status <> E$OK THEN GOTO error;, /* suspend ~self */ error: /* output to usart for debugging */ DO WHILE 1; OUTPUT(9CH) = OA3H; END; ok: ' CALL rq$suspend$task (0, @status) /* myself */ END supervisor$task;

/***************~*************~**************~***~*****~******************

*
*
*
*
*
*

IO$task is a, task which is created by main$t~sk. It creates
*
the necessary mailboxes and segments, and then attaches the terminal *
physically. It then creates a file so that it has a file connection.*
It opens the file connection, and writes the contents of a buffer to *
the terminal.' Then it closes the file conned:ion~ deletes the
*
*
device connection, and detaches the device.

**********~*****~********************************************************/

474

1

' IO$ta~sk: PROCEDURE REENTRANT,PUBLlC; 475 2 , DECLARE mbx$token
seg$token user$token,
fileSconnection
device$connection cleanup$token
done$token, make$widget$token cOAtinue$token
doneSwrite$mbx start$write$mbx ,TOKEN, TOKEN, TOKEN, TO~EN, TOKEN, TOKEN, TOKEN, TOKEN,' ' TOKEN, TOKEN, TOKEN; 280047-001 inter AP·221 WORD; status hard BYTE; iors$token
TOKEN;
cleanup$token (1) BYTE; cleanup$ptr
BASED
send$to$io$token TOKEN; send$to$io$token STRUCTLRE(
send$to$io
BASED
making$widget (1) BYTE. (13) BYTE); message dev$conn$object TOKEN AT (@iors$token).
file$conn$object TOKEN AT (@iors$token). msg$received$obj TOKEN AT (@iors$token).
object
TOKEN AT (@iors$token); iors$token
STRUCTURE
iors
BASED
WORD,
(status
unit$status WORD. WORD) ; actual seg$token (9) BYTE;
BASED
buffer
STRUCTURE
user$object (length WORD. WORD, . count id (1) WORD) ; 476 477 478 479 480 481 2 2 2 2 2 2 DECLARE DECLARE DECLARE DECLARE DECLARE DECLARE 482 2 DECLARE 483 2 DECLARE 484 485 2 2 DECLARE DECLARE 486 487 488 2 2 user$object.length = 1;
user$object.count = 1; user$object.id(O) = OFFFFH;

489

2

hard = OffH;

490

2

491

2

492
494

2
2

495

2

CAUSE$INTERRUPT (3); /* Set up the mailboxes for this task to use */ start$write$mbx = rq$lookup$object (0. @(10.'STARTWRITE'). OFFFFH. @status); IF status <> E$OK THEN GOTO error;
done$write$mbx = rq$lookup$object (0. @(9.'DONEWRITE').
OFFFFH. @status);
IF status <> E$OK THEN GOTO error; 2 /* request a hard detach of the device */ /* Receive message from supervisor task. mailbox STARTWRITE. */ 497 2 498 500 2 2 send$to$io$token = rq$receive$message (start$write$mbx.
OFFFFH. O. @status);
IF status <> E$OK THEN GOTO.error; CAUSE$INTERRUPT (3);

501
502
504
505
507
508

2
2
2
2
2
2

user$token = rq$create$user (@user$object. @status);
IF status <> E$OK THEN GOTO error; mbx$token = rq$create$mailbox (0. @status);
IF status <> ESOK THEN GOTO error;
seg$token = rq$create$segment ( 48. @status); IF status <> E$OK THEN GOTO ecror;

510

2

CALL rq$a$physical$attach$device ( @(2.'TO'). 1. mbx$token. @status); 2-223 280047-001 inter AP-221 , 511 513 2 2 514 516 2 2 517 2 518 520 2 2 521 523 .2 CALL rq$a$create$file (user$token, device$connection,
0, 0, 0, 0, 0, mbx$token, @status); IF status <> E$OK THEN GOTO error;
file$conn$object = rq$receive$message {mbx$token, OFFFFH, 0, @status); IF status <> E$OK THEN GOTO error;
file$connection = file$conn$object; 524 525 527 528 530 531 2 2 2 2 2 2 CALL rq$a$open (file$connection, 2. 0, mbx$token, @status); IF status <> E$OK THEN GOTO error;
object = rq$receive$message (mbx$token, OFFFFH, 0, @status); IF status <> E$O~ THEN GOTO error;
CALL rq$delete$segment (object, @status);
IF status <> E$OK THEN GOTO error; 2 IF status <> E$OK THEN GOTO error;
dev$conn$object = rq$receive$message (mbx$token, OFFFFH, 0, @status); IF status <> E$OK THEN GOTO error;
device$connection = d~v$conn$object; /*********************************************************************** * This is the part of the code that will be repeated. It receives * * the message from second task and writes it to the screen, then * * returns control to the second task. . */ 533 534 535 2 3 3 536 538 3 3 539 541 542 544 545 3 3 3 3 3 547 548 550 3 551 553 3 3 3 3 DO WHILE send$to$io.making$widget(O) = 1;
CAUSE$INTERRUPT (3); . CALL rq$a$write (file$connection, @send$to$io.message,
size(send$to$io.message),
mbx$token, @status); IF status <> E$OK THEN GOTO error;
object = rq$receiv~$message 1mbx$token, OFFFFH, 0, @status); IF status <> E$OK THEN GOTO error;
CALL rq$delete$segment (object, @status);
IF status <> E$OK THEN GOTO error; CALL rq$delete$segment (send$to$io$token, @status);
IF status <> E$OK THEN GOTO error; /* Send message to supervisor task, mailbox DONEWRITE done$token = rq$create$segment ( 16, @status);
IF status <> E$OK THEN GOTOerror; CALL rq$send$message (done$wtite$mbx, done$token, 0,
.
@status);
IF status <> E$OK THEN GOTO error; CAUSE$INTERRUPT(3) ;

*/

/* Receive message from rupervisor

554

3

555

3

*/
send$to$io$token = rq$receive$message (start$write$mbx, OFFFFH, 0, @status); IF status <> E$OK THEN GOTO error;

* STARTWRITE

2-224

280047-001

inter

AP .. 221

557
558

3
3

CAUSE$INTERRUPT (3); END; 559 560 562 563 565 566 568 569 571 2 2 2 2 2 2 2 2 2 572 574 575 577 578 2 2 2 2 2 CALL rq$delete$segment (send$to$io$token. @statlJs);
IF status <> E$OK THEN GOTO error; CALL rq$a$clos~ (file$connection. mbx$token. @status); IF status <> E$OK THEN GOTO error;
object = rq$receive$message (mbx$token. OFFFFH. O. @status); IF status <> E$OK THEN GOTO error;
CALL rq'$de 1ete$segment (object. @status);
IF status <> E$OK THEN GOTO error; CALL rq$a$delete$connection (file$connection. mbx$token.
,
, @status);
IF status <> E$OK THEN GOTO error; object = rq$receive$message (mbx$token. OFFFFH. 0, @status);
IF status <> E$OK THEN GOTO error; CALL rq$delete$segment (object. @status); IF status <> E$OK THEN GOTO error;

580

2

581
583
584
586
587

2
2
2
2
2

589
590

2
2

CALL rq$delete$mailbox (mbx$token, @status); IF status <> E$OK THEN GOTO error;

592
593
595
596

2
2
2
2

CALL rq$delete$us~r (user$token. @status); IF status <> E$OK THEN GOTO error;
CALL rq$delete$~egment (~eg$token. @status); IF status <> E$OK THEN GOTO error;

598
599
601
602
604
605

2
2
2
2
2
2

/* Send message to supervisor task, mailbox DONEWRITE */
done$token = rq$create$segment ( 16. @status); IF status <> E$OK.THEN GOTO error;
CALL rq$send$message (done$write$mbx. done$token. O. @status); IF status <> E$OK THEN GOTO error;
CAUSE$INTERRUPT (3);, OOTO ok; 606 2 607 608 3 3 error: DO WHILE 1; OUTPUT(9CH) = OAIH . , END; 609 2 ok: 610 2 END IO$tas'k;

611

1

w,idget$task: CALL rq$a$physical$detach$device (device$connection, hard,
mbx$token. @status); IF status <> E$OK THEN GOTO error;
object = rq$receive$message (mbx$token. OFFFFH. O. @status); , IF status <> E$OK THEN GOTO error;
CALL rq$del~te$segment (object, @status);
IF status <> E$OK THEN GOTO error; CALL rq$suspen~$task (0. @status); PROCEDuRE REENTRANT PUBLIC; 2-225 280047-001 AP-221 D£CLARE done$token
TOKE".
continue$token TOKEN, clelAupStoken TOKEN. start$widgetSmbx, TOKEN.
dQne$w1d,get$mbX
TOKEN.
MahSwic;tget$tOken' 'FOKEN; OECLAR£ statqs , WORD; DECLARE c1eanupSptr BASED cleanup$token (1) BYTE.
,
continueSptr
BASED
continue$token (1) BYTE. makeSwidget$ptr BASED
make$widget$token (11) BYTE;
CAUSESINTERRUPT (3);
"
"
'
~tatt$widget$mbx
rqSlookupSobject (0,- @(11.'STARTWIDGET').
OFFFFH. @status):
IF status' <> [SOK THEN GOTO error;
,
doneSwidge~$mbx rq$.lookl.lpSobject (0, tt(10,'DONEWIOGET'),
OFFFFH, @status):
If status <> E$OK THEM GOTO error; " a12 2 a13 614 2 615 616 2 611 619 ~ no 2 622 2 623 '. 2 625 2 626 627 628 3 3 1 630 3 631 a33 3 3 634 636 3 637 3 638 3 640 3 ENDi /* do making the widgets */ 641 2 642 2 (3). /* del.,up the environmenf now.*! CALL rq$delete$segment (mi~e$widget$token, @status); IF stltus <> E$OK lHE~ GOTO error;

645
646
648

2

2

2
2

3

10

10

/* Receive message from supervisor task, mailbox STARTWIDGET */
MakeSw1dtetStoken 10 rqSreceive$meuage (startSwidgetSmbx. , ,,' OFFFFH, 0, @status); status <> ESOk THEN GOlO error; I' 00 WHILE makeSwidgetSptr'(O) .. 1; /* Repeat endlessly. * Let superv~sor task take 'cafe of controlling. */ CAUSES'INTERRUPT (3); , , CALL rqSdeleteSsegment (make$widget$token, @status); IF stitu$ <> ESOK THEN 9OTO efror:
/* Send me$sage,to supervisQr task, mailbox DONEWIDGET */ .. rqScreate$segment ( l~', @status):
IF status <> ESOK THEN GOTO error;
CALL fqSsepdSmessage (done$widget$mbx. done$token. O. .status); IF status ~> ESOK THEN GOTQ error; CAUSES I NTtRR UPT(3 ); " ~one$token

/'* Receive message from supervisor task. mailbox STARTWIDGET */

643 , 2

,

t

2

'0

MakeSwidg'etStoken • rqSrecei'veSmessage (start$widgetSmbx. , . OFFFFH. 0, @status); . IF stltus <> E$OK THEN GOtO error;
CAUSE$IHTE~RUPT /* Send messlge'to supervisor task, mailbox 'DONEWIDGET */ don.Stoken rq$cre.teSsegment ( 16. @status);
IF status <> ~$.OK THEN GOTO error; , C~LL rq$s_nd$messlge, (done$widget$~bx, doneStoken. 0, .' '" '@sta,ttl!;);' ".' , 10 2-228 280047-0<11 . inter AP-221 649 651 652 2 2 2 IF status <> E$OK THEN GOTO error;
CAUSESINTERRUPT (3);
GOTO ok;

653

2

654
655

3
3

error:
/* output to usart for debugging */
DO WHILE 1;
OUTPUT(9CH) = OA2H;
END;

656

2

ok:

657

2

END widget$task; 658 1 END tasks; CALL rq$suspend$task (0. @status); MODULE INFORMATION: CODE AREA SIZE = OD1BH CONSTANT AREA SIZE = OOA9H VARIABLE AREA SIZE = OOOOH MAXIMUM STACK SIZE = 0044H 1796 LINES READ o PROGRAM WA~NINGS o PROGRAM ERRORS 33550 1690 00 680 DICTIONARY SUMMARY: 84KB MEMORY AVAILABLE 22KB MEMORY USED (26%) OKB DISK SPACE USED END OF PL/M-86 COMPILATION 2-227 280047-001 AP'·221 APPENDIX 0 PLMS6 %0.PS6 PLMS6 inittask.PSn LINKS6 inittask.OBJ to inittask.lnk initcode LINKS6 %O.OBJ to %O.lnkl initcode \inkS6 inittask.LNK, & %O.LNKl, & /lib/ndpS7/dconS7.1ib,·& /lib/ndp87/celS7.1ib, & /lib/ndpS7/ehS7.1ib, & /lib/ndpS7/S0S7.1ib, & /lib/rmxS6/epifl.lib, & /lib/rmxS6/ipifl.lib, & /LIB/RMXS6/RPIFL.LIB, & /LIB/PLMS6/PLMS6.LIB & TO %O.LNK LOCS6 %O.LNK TO %0 & SEGSIZE(STACK(O» ADDRESSES(CLASSES(CODE(015000H),DAT~(017000H») NOINITCODE 1 ibS6 ' delete /boot/%O(inittask) add %0 to /boot/%O e 2-228 280047-001 AP-221 APPENDIX E ICU86 V2.0 ONETASK.DEF OS/21/84 07:04:32 Hardware (CPU) Processor used in the system (OSP) 80130 Operating System Extension [Yes/No] (TP) 8253/8254 Timer Port [O-OFFFFH] (CIl) Clock Interrupt level [0-7] (CN) Timer Counter Number [0,1,2] (CI) Clock Interval [O-OFFFFH msec] (CF) Clock Frequency [O-OFFFFH khz] (TPS) Timer Port Separation [O-OFFH] (NPX) Numeric Processor Extension [Yes/No] (NIL) NPX Interrupt level [Encoded] 8086 No OODOH 0002H OOOOH OOOAH 04CDH 0002H No 0008H Interrupts (MP) 8259A Master Port [O-OFFFFH] (MPS) Master PIC Port Separation [O-OFFH] (SIl) Slave Interrupt levels [0-7/None] (lSS) level Sensitive Slaves [0-7/None] OOCOH 0002H None None Memory Type Type Type Type RAM ROM RAM RAM = low, high = low, high = 0104H, 1500H = 1800H, F7FFH Sub-systems (UDI) Universal Development Interface [Yes/No] (HI) Human Interface [Yes/No] (Al) Application loader [Yes/No] (EIO) Extended I/O System [Yes/No] (BIO) Basic I/O System [Yes/No] (SDB) System Debugger [Yes/No] (DDB) Dynamic Debugger [Yes/No] (TH) Terminal Handler [Yes/No] (CA) Crash Analyzer [Yes/No]' No No No No Yes Yes No No No BIOS (ASC) (ADP) (TF) (TTP) (CON) (ACE) (SM1) (CUT) Yes 0081H Yes 0081H . 0082H Yes Yes 03E8H All Sys Calls in BIOS [Yes/No] Attach Device Task Priority [1-0FFH] Timing Facilities Required [Yes/No] Timer Task Priority [O-OFFH] Connection Job Delete Priority [O-OFFH] Ability to Create Existing Files [Yes/No] System Manager 1D [Yes/No] Common Update Timeout [O-OFFFFH] 2-229 280047-001 illtJ . . Ap·221 Yes Yes No 0800H 0800H (CST) (OSC) (TS) (PMI) (PMA) Control-Sequence Translation [Yes/No]· Terminal OSC Controls [Yes/No] Tape Support for iSBC 215G [Yes/No] BIOS Pool Minimum [O-OFFFFH] BIOS Pool Maximum [O-OFFFFH] 8251A (Ill) (OIL) (UDP) (USP) (IRP) (ICP) (IRC) (IRF) (ORP) (OCP) (ORC) (ORF) Driver Input Interrupt level [Encoded] Output Interrupt level [Encoded] USART Data Port [O-OFFFFH] USART Status Port [O-OFFFFH] 8253 Inrate Port [O-OFFFFH] 8253 Input Control Port [O-OFFFFH] 8253 Input Counter Number [0-2] Inrate Frequency [O-OFFFFFFFFH] 8253 Outrate Port [O-OFFFFH] 8253 Output Control Port [O-OFFFFH] 8253 Output Counter Number [0-2] Outrate Frequency [O-OFFFFFFFFH] 0068H 0078H 00D8H· OODAH - 00D4H 00D6H 0002H 0012COOOH OOOOH OOOOH OOOOH OOOOOOOOH 8251A (NAM) (lEM) (ECH) (IPC) (OPC) (OCC) (OSC) (DUP) (TRM) Unit Information Unit Info Name [1-17 Chars] line Edit Mode [Trans/Normal/Flush] Echo Mode [Yes/No] Input Parity Control [Yes/No] Output Parity Control [Yes/No] . Output Control in Input [Yes/No] OSC Controls [Both/In/Out/Neither] Duplex Mode [Full/Half] Terminal Type [CRT/Hard Copy] Modem Control [Yes/No} Read Parity Checking [See Help/0-3] Write Parity Checking (See Help/0-4] Baud Rate [O-OFFFFH] Scroll Number [O-OFFFfH] tOinfo Normal Yes Yes Yes Yes Both Full CRT No OOOOH OOOOH 2580H 0017H (Me) (RPC) (WPC) (BR) (SN) 251A Device-Unit Information (NAM) Device-Unit Name [1-13 chars] (UN) Unit Number on thi~ Device [O-OFFH] (UIN) Unit Info Name [1·17 Chars] (MB) Max Buffers [O-OFFH] System Debugger (SlV) SDB Interrupt level [Encoded level/None] Nucleus (ASC) All Sys Calls [Yes/No] (PV) Parameter Validation [Yes/No] . (ROD) Root Object Directory Size. [0 - OFFOh] 2-230 TO OOOOH tOinfo OOOOH 0018H Yes Yes 0020H 280047-001 inter (MTS) (DEH) (NEH) (EM) (SRR) AP-221 Minimum Transfer Size [O-OFFFFH] Default Exc~ption Handler [Yes/No/Deb/Use] Name of Ex Handler Object Module [1-32chs] Exception Mode [Never/Program/Environ/All] Start Root job from Reset [Yes/No] User Jobs (NAM) Job Name [0-14 characters] (ODS) Object Directory Size [O-OFF.OH] (PMI) Pool Minimum [20H - OFFFFH] (PMA) Pool Maximum [20H - OFFFFH] (MOB) Maximum Objects [1 - OFFFFH] (MTK) Maximum Tasks [1 - OFFFFH] (MPR) Maximum Priority [0 - OFFH] (AEH) Address of Exception Handler [CS:IP] (EM) Exception Mode [Never/Prog/Environ/All] (PV) Parameter Validation [Yes/No] (TP) Task Priority [O-OFFH] (TSA) Task Start Address [CS:IP] (DSB) Data Segment Base [O-OFFFFH] (SSA) Stack Segment Address [SS:SP] (SS) Stack Size [O-OFFFFH] (NPX) Numeric Processor Extension Used [Yes/No] 0040H Yes Never No onetask 0010H 0500H 0500H 0020H 0010H OOOOH OOOOH:OOOOH Never Yes 0082H 1500H:0002H OOOOH OOOOH:OOOOH 1F40H No User Modul~s Module: 1-55 characters ROM code (BIR) Basic I/O System in ROM [Yes/No] (SIR) SOB in ROM [Yes/No] (NIR) Nucleus in ROM [Yes/No] (RIR) Root Job in ROM [Yes/No] No No No No Includes and Libraries Path Name [1-45 Characters] (UDF) UOI Includes and Libs /rmx86/udi/ (HIF) Human Interface Includes and Libs /rmx86/hi/ (ElF) Extended I/O System Includes and Libs /rmx86/eios/ (ALF) Application Loader Includes and Libs /rmx86/l oader/ (BIF) Basic I/O System Includes and Libs /rmx86/ios/ (SDF) System Debugger Includes and Libs /rmx86/sdb/ (THF) Terminal Handler and Dynamic Debugger Includes and Libs /rmx86/th/ (NUF) Nucleus and Root Job Includes and Libs /rmx86/nucleus/ 2-231 280047-001 AP-221 (ILF) Interface Libraries /rmx86/l ib/ (CAF) Crash Analyzer Includes and Libs /rmx86/crash/ (DTF) Development Tools Path Names :lang: Generate File Names File Namf! [1-55 Characters] (ROP) ROM Code Prefix (RAF) RAM Code File Name none /boot/onetask 2-232 280047-001 AP-221 Appendix F: Related publications Knuth, The Art of Computer Programming, Vol 1, pp 435-453, and exercise 6, p 452 with answer p 597. (c) 1973,1978, Addison-Wesley Publishing Co., Redding,MA iRMXTM 86 Introduction and Operator's Reference Manual For Release 6 (146194-001) iRMXTM 86 Programmer's Reference Manual, Part I, For Release 6 (I46195-001) iRMXTM 86 Programmer's Reference Manual, ,Part II, For Release 6 (146196-001) iRMXTM 86 Installation and Configuration Guide For Release 6 (146197-001) 2-233 280047-001 ARTICLE REPRINT AR-286 June 1983 " Reprinted with permission from VLSI Design magazme, March/Apnl1983 Copynght© 1983. 2-234 2'034.-GOS inter AR-286 Software That Resides In SUicon Ron Slamp and Jim Person. Intel Corporation S ilicon software sounds like a contradiction in terms. The casting of software in silicon implies that the software cannot be changed; yet software does and must change. For example. it must be possible to alter a microprocessor operating system so that the system will support different hardware and software designs, as well as accommodate new hardware components and applications. And if the software has been committed to silicon, then a way must exist to overcome any bugs that are discovered later. Design Considerations Silicon software consists of two kinds of code: on-chip code and off-chip code (see Figur~ I). In a typical case, some of the off-chip code works closely with the on-chip code, and is developed as part of the silicon software package. This special offchip (or "support") code might contain initialization, interface, system, and version update codes. For silicon software to tolerate change and be usable in more than one system, the on-chip code must have three qualities: position independence, configuration independence and stepping independence. On-Chip Code I SilICon Software ConfiguralionIndependence The second requirement for silicon-resident software is that the on-chip code must not depend on the underlying hardware and software configuration of the system. Instead, the on-chip code must have indirect access to other code or data, and must then check the run-time data to deduce the system configuration. VLSI DESIGN March/April 1983 I I I I ~~f:~r~ Other Code I I I I System Memory IL ___ JI nGURE I. Silicon soft1rare is dh1ded into on-chip code and 011chip code. The oil-chip code either directly supports the on-chip code or contains other applications code. Because of the read-only nature of silicon software, constants can cause problems when they are located within the on-chip code. Values representing a hardware device must not reside on-chip if that device can be located anywhere in the system, or when values support several devices having similar functions but different programming interfaces. Indirect access is necessary for all values that vary depending on the configuration of the system. Position Independence Because the most advanced microprocessors address at least I megabyte of memory, system software that resides in silicon must work right regardless of its location in memory. Absolute addresses in the read-only, on-chip code or data restricts the configuration of the system. Because the on-chip code recognizes only offsets, absolute addresses are unacceptable. Onchip code cannot presume to know the location of any code or data, it can only presume to know the structure of the data whicn it accesses. It cannot know, except relatively, where in memory it (or any other code) resides. If the on-chip code is to be position independent, then any absolute addresses needed by the on-chip code must be obtained via the processor's registers. Position independence i, not a new concept: in fact, it is rather an obvious requirement for sIlicon software. Compilers and relocatable assemblers allow linking and locating, thus making it easier to produce position-independent code~ But most of these tools can also produce code that is not position independent. Silicon software developers need to be aware of the position-independence requirement throughout the design, implementation and test phases for their products. Olf-Chlp Code r---, Stepping Independence Stepping independence is an expansion of configuration in: dependence, and is perhaps the most elusive of the requirements to be met by software intended for residence in silicon. A "step" is an updated version of the on-chip code. The on-chip code and the off-Chip code must remain compatible, regardless of changes in either of them. Stepping independence exists when all versions of the on-chip code work with all versions of the off-chip code. If stepping independence is taken into consideration when the ,ilicon software is developed, then provisions can be made for the subsequent additions of options without changing the on-chip code. Otherwise, the static nature of the on-chip code might make it impossible to add options. Although configuration independence can be designed into software from the start, stepping independence can be achieved only if a system's existi ng silicon software does not include features that prevent it. One type of data that is likely to change between steps is the value representing the size of a data area. !fthe software is to be stepping independent, it cannot know the sizes of the data areas accessed by on-chip code prior to run time. (No problems arise if on-chip and off-Chip code agree on the size of the data area.) But what happens if the on-chip code IS not from the same version of the product as the off-chip code, and if the size of the data area has changed between versions" If the size of the data area is defined by a constant in the on-chip code, then that area might be smaller than the off-chip code expects it to be. This misunderstanding can lead to disaster as the off-chip code reads and writes beyond the data area. 2-235 210341-005 AR-286 This problem is, solved when the on-chip code asceitains the size of the data area from off-chip data. Thus, the size of the data areas for the system becomes a configuration option. Getting the Bugs Out 01 SUicon Software Every large program contains bugs. I)esignets" us'ua)ly remove bugs'by modifying the program to correct the problem, and then discarding the old program. However, a program in silicon cannot be modified without stepping the component. And even so, it is undesirable to discard the outdated component. Software designed for silicon should include a facility for fixing bugs in on-chip code, One way to fix an on-chip bug is to prevent access to the routine containing the bug. A correct version ofthe routine is provided off-chip, and program execution is forced to branch to the off-chip version whenever the routine is invoked. Modular programming practices during development help reduce the cost of such off-chip duplication. This on-chip bug-fix works well over time. Each component step has an associated collection of bug-fix modules. The collection is updated for each new version of the product, as component steps fix known bugs. During system configuration, the user specifies which component step is being used ; the fixes for that step are included automatically in the off-chip code. Because of this facility, one step looks just like another to the user. nGtJRE 2, The OS, component works with systems that use the IAPX 86.88. 186. or 188 microprocessor. Close coupling 01 the CPU and the osr allows mazimum .ero-walt-state perloImqJ;l.ce 01 the osr soltware. r I 80130 Kernel Control Storti Intel's OSF: A S01tware Component _~ Sup;;-rt-'" Software I 1 User Execution + ~e<:qu,es.tlor I ~ .. _ I ~~I~~~ment ! ~SerYIce -r--.,' I ' L-----..J The Operating System Firmware (OSF) component consists of several hardware modules (see Figure 2). These modules provide two functions that are essential to operating systems: interrupts and timers, The OSF modules include a Control Store (l6K.bytes of fast ROM) to contain the silicon software, three programmable interval timers, an eight-input programmable interrupt controller, a bus interface, control logic, a data buffer, and address latch logic. _K.,," , ~ L_~ '. nGtJRE 3. Th;, position-Independent Interlace supplies data location and run-time yalue•• and starts on-chip execution 01 the soltware. The 80130: The lRMX™ 86 Kernel in Silicon Intel's first software-on-silicon product is the 80130. It provides a functional subset of the iRMXTM 86 Nucleus, which is the heart of the iRMX 86 operating system (OS), The iRMX 86 OS is a real-time, multi-tasking, multiprogramming operating system intended for 16-bit microprocessor designs. The iRMX 86 family of standard software modules includes a nuCleus, a stand-along terminal handler, a stand-alone debugger, an asynchronous 1/0 system, a synchronous I/O system, a: loader, a human interface, and options required for real-time applications. The nucleus manages the creation and dynamic deletion of all system architectural features (tasks, program environments, memory segments, data-communicaiion managers, etc.), It also schedules tasks, based on priority, interrupt management, memory management, validation of parameters, management of exceptional conditions, and co-process?r support. How the 80130 Satisfies the Silicon Sollware Criteria . The iRMX 86 Nucleus provides both the on-chip and off-chip codes needed to implement the operating system. The on-chip code resides in the 16K-byte ROM space of the 80130. It is the main portion of the Nucleus code, and includes the kernel ofthe VLSI DESIGN MarchiAprill983 Oll-Ch!p COde On Chip Code operating system and the primitives, which are present in the basic 80130 configuration. The off-chip code is stored in external RAM or ROM: It consists of initialization code, and code that either cannot be position in.dependent or cannot be known before a given system is configured. , Position independence is guaranteed If entry to the on-chip code is possible only through an interface in .the off-chip code that sets up the necessary registers. The off-chip positionindependence interface (see Figure 3) provides an absolute data location and begins on-chip e~ecution by the siliconresident code. All run-time values can be determined, based on the data location. O~-chip execution gives the processor a location in the on-chip code from which other on-chip locations can be calculated. It was relatively easy to make the80130 configuration independent, because (like most operating-system kernels) it contains oQly general-purpose' functions. The off-chip code contains all the drivers for particular peripheral chips. The Interactive Configuration ,Utility integrates the drivers with the 80130. The interface between the off-chip and on-chip codes remains stable across component steps. The steppingindependence interface (see Figure 4) resideson the chip, and is a mal' of the on-chip code. This interface gives the qff-chip code indirect access to all on-chIp "publics" (e.g" externally accessible routines, modules, and labels). It is also a chart that routes execution to the proper on-chip location. The off-chip code uses an index of this chart to specify which public should 2-236 210341.005 inter AR·286 • • CCP Code CCP Code CCP Data .000 BOOS Code nGUIIE ts and preserves all registers, while Exitmon reverses these actions. Wait and Signal, on the other hand, work in tandem to control access to a critical resource. Wait queues up tasks needing an unavailable resource. Signal releases them from the queue when the resource becomes available. Wait and Signal are examples of an intertask communication mechanism, called semaphores, found in most real-time operating systems. As noted, these commands Simply queue up and release tasks needing a critical resOurce. Such a resource may be an 1/0 device, a memory location, or simply a go-ahead' signal that synchronizes a pair of tasks. For example, task A may execute only after task B has completed. In this case, task A would begin with a Wait (flag) command, where the flag IS used as an associated variable. Task B, on the other hand, would end with a Signal (flag) command. In this way, task A would be blocked until task B had exeCuted its Signal command at the end of its processing. But exchanging simple go-no-go Signals is not sufficient for many l\1ultitasking environments. For longer messages, real-time operating systems offer extensive intertask commumcatlOn facilities called mailboxes. Mailboxes are essentially semaphores with storage. As such, 'tasks needing data from another task will wait until the other has loaded the mailbox with the information. Intel's object-oriented RMX-S6 transfers any of the defined objects in the system through mailboxes. Hemenway's MSP, on the other hand, provides a buffer of fixed size that may be used without restriction on its contents; as long as the 256-byte buffer is not 'exceeded. With its Multibus message exchange (iMMX) extension to RMX for a S; ~ Electronics/March 24, 1983 Handling hardware interrupts Underlying the special software of a real-tlma syStem is the assumption that the hardware itself can respond in a coordInated fashion to external events, or Interrupts. In ,_ct, microprocessors contain subsystems whose sole functiOn . Is to deal with interrupts in a way that eases integration of the interrupt-handling software. All modem computers integrate interrupt-handling hardware and software at a very low level of design. When a user accesses a microprocessor through a terminal, the same hardware interrupt facilities coma into play as when, for example, lin anaJog.to-digital converter sends data to the same type of microprocessor. The software response, on the other hand, depends on the type of operating system, but both real-tlma and genaral-pwpose operating systems must take some action, like read in the data value or the character. Examining the details of a simple keyboard task illustrates the complex nature of real·time processing. It also serves as a vehicle for Introducing soma of the basic vocabulery in this field. A standard software subsystem in a microcomputer system, called the keyboard monitor, is respOnsible for working With the hardware interrupt system to detact a charactar, collect it, and effect some action bssed on the input character. When a key is struck on a terminal, the corresponding byte is converted into a serial stream of bits that are passed from the terminal to a universal asynchronous receiver·transmitter. Onoe it receives the full character, the ~ART generates a hardware signal, or Interrupt, that noti· fies the processor. Since interrupt management is a common activity, processors contain special hsrdware to respond to this signal. Although the details may vary from one particular microprooessor to the naxt, the result is the same for all. When its interrupt-request line is asserted, the processor ceases its current processing and places values from its Internal registers into system mamory. Typtcally, the processor status I!IId instruction-address ragistars are saved In the system stack, a last-in, first-out buffer located In soma portion of system mamory. As the figure shows, the pr0cessor responds to the original Interrupt-request signal by issuing a signal of its own, called an interrupt acknowledge. The peripheral hardware that originated the interrupt detects the interrupt-acknowledge signal on the system bus and responds by returning the mamory addraases of both the interrupt-handllng subroutine and the new processor status. Typically, the n_ processor status Will provide for disabling any further interrupts. This latter action is a simple precaution, preventing a single external stimulus from causing a continuous series of interrupts that Will eventually result in an overflow of the system stack. Such an interrupt machanism, called a vectored interrupt, allows the speediest identification and reaction to an interrupt. (An alternative interrupt mechanism used by earlier processors, called a device-poiling interrupt, simply forced the processor to sWitch to a defined address in mamory containing softwara that polled each penpheraJ device until the devioe that generated the interrupt was discovlrred.) At 2--244 21_1_ intel· AR-287 this point in the interrupt-handling task, all the activity was exclusively in hardware, but nevertheless resulted in extensive processor activity and bus traffic due to multiple accesses of system memory and the involved peripheraldevice controller. Consequently, it is not surprising that the time for hardware to set the processor to handle the interrupt-the hardware;intflrrupt latancy-should be several processor cycle times in length. In general, hardware-interrupt lateney is not a fixed number, but will lie within some range, since the processor will need a varisble length of time to complete Its current instruction and to initiata the intarrupt-acknowledge signal. For example, if a processor is involved in a lengthy floating-point operation, several microseconds could elapse before the interrupt is acknowledged. Once the processor has reached the interrupt-handling subroutine, the contents of only a minimal set of Its internel registers have been preserved. However, before the resl work of the subroutine may commence, the contants of other registers and variables shared by independent sactions of the operating system must be preserved. The time needed to perform this action is called the contaxt-switching time. Only altar the software context is switched is the system ready to begin handUng the special requirements of the device that Originated the interrupt. The period of time betwaan the occurrence of the eldamal event and this stata is the total intarrupt-response latency. In real-time operating systems, intarrupt-response latency is ususlly a specified value-sround 100 microsaconds in vary, high-performance systal'l1$ based on 16-bit microprocessors. Designers oltan bypass the constraints imposed by response lataney by including speciaI-purpose
hardware to boost system response to external events.
Throughout all this time, system intarTUpts are still dlsabled. However, now thet the context switch has taken
place, the keyboard hendler is fres to transfer the charactar
from the lJART. DecIding wIlere to put the character is
iItlportant in terms of system throughput and overall effi..
ciency. When it is put in some specified location in system
memory, system interrupts must remain disalJled; otherwise, if the handler attempted to service a subsequent
intarrupt, the new charactar would overwrita the cheractar
aIresdy in the location. but not yet fuDy processed.
In general. there are two methods for hendHng this
problem. In the first method, the charactar is simply placed
on th!I system stack and referenced through the relevantpointer. In an alternative
method, the charectar is
placed In a block of

memory thet has bsen
reserved just for the hendler and is called a contaxt block: In this case,
the charactar is 'referred
to by using a specified
offset from the bese of
the contaxt bloCk. Each
time the keyboard handier is called in response
to an interrupt, one of

Electronics'March 24, 1983

1
EXT ERNAL
EVE

.~

PERIPHERAL
CONTROLLER

these context blocks is reserved from available system
memory. Setting up a context block and switching the
proceseor to it in a context switch acoounts for a significant
fraction of the time that is needed to respond to an interrupt.
Software code. such as the UART hencllar in this example, that does not contain any memory lOcations for variables is called reentrant because the proceseor l'l1$y asynchronouely enter it, be called away by an interrupt dS~lg!l Intf'rrupt RO$GETSLEVEl

return number of highest priority

Entry Description

system beginning dddress

sys RAM Sile

system memory size

sys stack SllP

system stack size

stdftlng address for avalldble memory In
initial partition

hdndler

Interrupt level currently being

user RAM size

$IZ8 of Initial partition user block size size of memory block for dynamiC allocation user stack size size of stdck for user tasks user task dddr dddress of first user task user task count mdXlmum number of tasks lJroct'sspd RO$SIGNAL$INTE A RUPT 5191101 from Interrupt hdndler that {'vent has occurred RO$WAITSINTERRUPT

Wdrt for occurrence of event

RQ$EXIT$I NTERRUPT

reitnqulsh control of the system

AQ$ENABlE enable hardware to deeept Interrupts ROSDISABLE dlSdble hardwdre from accepting sys Inlt dddr dddress of user supplied initialization routme sys tcreate addr address of user supplied routine accessed sys tdelete addr address of user supplted routme accessed when a tdsk IS deleted sys tswap addr address of user supplied (outlne accessed whf'n d context SWitch occurs [RESERVEDI dddress of Hunter & Ready future extenSions to VRTX when a task IS created mterrupt~ embedded system, thiS new routine could be placed In ROM along with applicatIOn software, Now that programs In ROM have matured into slhcon systems, the development of software for embedded systems may now follow a more hospitable development cycle. The particular method used to create embedded systems will, In general, fall Into one of two paths represented by the two major camps. On one hand, kernels In slhcon from systems such as RMX-86 or the MSP from Hemenway Corp., Boston, Mass., for the 68000 or Z8000 are self-contained subsets of the full operating system. Consequently, software programmers may use the full development version of the same operating system as that in the eventual target to create the application package. On the other hand, development of apphcatlOn programs around the ZRTS system from Zilog Corp., Cupertino, Calif., or Hunter & Ready's VRTX for the Z8002, IAPX-86 family, or 68000 relies on the use of a separate development system to create software for the target microprocessor, since this software does not have development versions. Two approaches The significance of these two approaches as usual depends on the Intended application. Hunter & Ready views VRTX as a set of processor-independent building blocks that programmers use to construct application packages for embedded systems. As such, the programmers employ the same development systems that they might use to build apphcation code, but now with the benefit of a sophisticated set of ready-made system-software components. In plaYing Its part in Intel's systematic dnve toward Electronics/ March 24, 1983 providing an Integrated environment around the iAPX86 family, the 80130 holds the anchor pOSitIOn in an Interlocked set of components. Able to function independently of the upper layers of the operating system, it provides a hardware base for the rest of RMX-86. Serving as a. viewport into thiS system-software base for the central processing Unit, Intel's universal run-time and development interfaces offer the mechanism for software portability needed for the next stage In the company's plan to grow Into higher-performance microprocessors, such as the 186, 286, and 386. While interlocking With the software in thiS way, the 80130 also must play its role in the complementary relationships being established at the hardware level. As such, it Includes on-chip hardware support for systemlevel functions, including timers, interrupt controller, bus control, and bus interface. Meanwhile, Intel's plan for software-in-silicon becomes evident as it gathers the other pieces of the puzzle, such as the 82730 text-coprocessor chip, the 82586 local-network coprocessor, and the 82720 graphics processor chip. Similar to the 80130 software connection, the 82720 graphics part interlocks with the rest of the system at the software level through its support of another well-defined software Interface-the virtual device interface. Yet to come are pieces for voice I/O support, as well as some 0 level of hardware support for data-base access.' 2-251 210341-005 ARTICLE REPRINT AR-288 June 1983 Copynght© 1983 CMP PubhcatlOns, tnc, 111 E Shore, Rd, Manhasset, N Y 11030 Reprinted with permission trom Electr5Jnlc Engmeermg Times 210341-005 2-252 inter AR-288 Intel's Matchmaking Strategy: Marry iRMXTM Operating System With Hardware Intel's major software product, the iRM)(TM-86 16-bit operating system, which is now in its fifth release, represented a three-year development investment which most independent software vendors would have found a daunting prospect in 1978 when the project was conceived. The investment was essential. By the mid-1970s, feedback from OEMs working with Intel's hardware revealed problems with system integration-the marriage of software with hardware. It consequently slowed sales, with the prospect of even greater problems at higher levels of circuit integration. Intel management, looking for ways of coping with the ballooning software requirements of the rapidly accelerating hardware program, began stepping up software development programs in the mid-1970s. Object-oriented programming is a method which has worked best in creating a software program blending with the component approach. By hiding data representation within an object with its own object manager, changes in the hardware environment that affect the data ean be accommodated without having to change the rest of the software. "The RMX program illustrates a number of things one needs to keep in mind with developing a real-time operating system;' explained Bill Lattin, Intel's OEM microcomputer systems manager. "Foundations must be well laid so the system can grow and evolve over time. And there is a need for the system to be open to modification by typical OEM-specific applications. "Although the RMX program has been around since 1978, it has only recently hit its stride, as processor technology has advanced to use the full range of its features;' Lattin said. The fast-paced microcomputer market had created a new situation: for systems designers in terms of a radical shift in the hardware/software cost ratio. Earlier hardware generations involved various expensive centralized facilities. Not only was software cheap in comparison, but the hardware environment changed slowly, so that it was also feasible to rewrite systems as needed. But when the price of a computer drops to as low as$5,
the hardware environment becomes volatile and software
turns into a major investment. Intel was finding that
customers might invest as much as two-thirds of their
development costs in software, only to see it eclipsed by
evolving VLSI technology.
It became evident that merely supplying components
would become increasingly counterproductive. Thus, the
Intel "total solution" emerged-a consistent systems approach to hardware sales, which naturally depends heavily
on a viable software program.

A price is paid in terms of program size with this approach, however. And it was difficult at the ti}lle to justify
this kind of liability with the existing onboard memories
of the 8-bit generation.
Bill Stevens, iRMX-86 program manager for release five,
explained the difficult decisions that had to be made at the
outset of the program. "Every engineering decision
involves a trade-off. We wanted to optimize program productivity and we had to have modularity. The consequence of this was large size. It turned out that a minimum
configuration was 12 kbytes wide and the full configuration was 128 kbytes. At the time we did not have 64k
dynamic RAMs and 64k EPROMs, so we didn't have the
technology to realize the systems of initial specifications
times. Bruce Schafer has to take credit for making that
decision to go ahead anyway, early on ... it was a gutsy
decision, and it turned out to be absolutely right:'
2-253

210341.(105

AR-288
Had Intel known of ,the difficulty it was about to encounter in producing its 64-kbyte RAM, Schafer may have

processing aspects of real-time applications required a
special test apparatus to simulate a real-world
environment.

Schafer joined Intel in 1976 and began working on
iRMX-80. "It was a nice little system;' Schafer said. "A
miniat)Jre dispatcher had evolved to handle multiple asynchronous events and became a primitive OEM operating
system. It was tempting to do an enlarged version of it,
mainly because I was already working on it for the 16-bit
generation:'

What they came up with is a nuCleus executing directly on
the 8086 and 8088 processors as the basic building block
of the system. Together with the next layer-a basic I/O
system-a minimal operating system can be configured,
which has been found useful in many applications.

Schafer soon found himself centrally involved in the task
of heading off the 16-bit software crunch, laying groundwork for a system that could cover a wide range of applications, many of them unknown at the time, and a
system which could also evolve with hardware advances.
"When you set out to design a system of that scope, you
don't just sit down and start writing code. It's definitely
a top-down process;' explained Schafer. He discovered
early in the project that the purely technical hurdles in
writing software were minor compared to orchestrating a
team of engineers on such a comprehensive project.
The iRMX-86 system is multi-layered, 'and the project had
to be coordinated across these layers along with the sequence of planning, design and implementation. On top
of that, a thorough testing program had to be coordinated
with all phases.
"I had a difficult time convincing engineers on the project that documentation of their work was as important
as the work itself. Specificatiens were absolutely crucial
to the development phase:' said Schafer.
Schafer began with a customer survey to discover the kind
of problems OEMs were experiencing with system design.
He wrote a production implementation plan, which was
critiqued by marketing and engineering personnel. This
was approved in June 1978 and formed the basis for
engineering specifications. A critiquing process evolved as
the organizing principle behind initial product design;
engineers on the project would exchange documentation
and then meet to evaluate the progress of the system.
The sessions were lively and the problems of coordinating
implementation, testing and design along with the pressure
of deadlines for the whole program generated quite a bit
of excitement.
Development testing turned out to be a particularly thorny problem-the asynchronous interrupts and multiple-

However, it was necessary to develop an application on
the Series-III development system even though the target
was going to be RMX. "We quickly realized that users
want to be able to do development work on the machine
they target on;' said Schafer. "This is particularly important for field maintenance ... you can't drag a Series-III
out to an oil derrick:' To realize this goal, Intel built higher
layers around iRMX so that program development could
be done without a Series-III. Higher layers involve extended I/O and human interface facilities. After this,
customer-written software can be added in high-level
languages.
A major objective has been to provide a stable base for
independent software vendors; with its latest release,
Intel also announced an ISV program initially involving
three major vendors; Microsoft, Digital Research and
Mark Williams Inc.
The first release of iRMX-86 came out in April 1980. Since
then, the system has bee~ refined and released four more
times, with release five appearing last December. An Interactive Configuration Utility appeared for the first time
with release five, a further attempt to aid OEMs in putting their systems together. The system designer runs the
ICU program on a terminal and is quizzed on his requirements, after which tM program generates the unique
iRMX software for his application.
"It has been a successful product in its own right, apart
from its role in the hardware program, but I doubt that
anyone would have wanted to invest in a three-year
development process before there was a chance at some
return;' observed Stevens, who has been most excited by
the diverse applications he has seen. "I've really enjoyed
the iRMX symposiums. There is always some new system
demonstrated. In Tokyo, I just saw an 8086-based scientific system with really first-class graphics put together by
Seiko. Another time I saw a blood analyzer based on the
system. There are even RMX-based personal computers:'

2-254

210341.005

ARTICLE
REPRINT

AR-337

APRIL,1984

Reprinted with pennlaolon from April, 1984 _ e of Sys1ems & Software, Heyden PubflShing, 1984.

2-255

21_,-005

AR·337

must be able
to coordinate
with one another."

PC • INTEGRATION SERIES

,

Industrial PC systems demands
real-time op'erating system
Personal computers find a wide range of applications
in an industrial process control environment. For
, example, the computers can be used for temperature
monitoring and control, production line testing,
wear analysis, frequency signature monitoring,
analysis in noisy or hostile environments, and
vibration analysis.
All of these jobs for the computer have certain
characteristics in common. All require that the
computer process asynchronously occurring events
that are happening in real time. Moreover, handling
multiple asynchronously occurring events, some of
which can happen concurrently, demands that the
computer process more than one operation or task
at a time.
For example, in monitoring and controlling the
temperature of a burn-in oven used to stress printed
circuit boards, the computer must have a task that
keeps track of time so that the temperature is read at
prescribed intervals. It requires a second task to read
the temperature sensor, and a third to control the
application or remQval of heat:
Furthermore, 'certain tasks ate more time critiCal
than others. For example, an error 'routine' that
detects a critical overtemperature condition in the
burn-in oven must be given the highest priority and
executed before any other routine vying for
computer time.
Finally, the tasks must be able to coordinate with
one another. They must be able to communicate so
that the results of one needed by a second can be
passed between the two. Tasks must also be able to
exclude one another so that, for example, olie can
have use of commonly' aqcessed data without"
interference from a second. Finally, tasks must be,'
able to synchronize with one another to ensure, for
example, control of a chemical reaction that
requires an ordered sequence of elements be added
to produce the desired result.
Kathryn S. Norrll, Software Products Marketing Manager
Intel Corp
5200 N.E. Elam Young Pkwy
Hillsboro. Ore 97123
APRIL 1984 SYSTIMS

a SOFTWARI'

To meet the requirements of an industrial control
environment, a personal computer must have an
operating system like the iRMX-86 from Intel Corp.
(Hillsboro. Ore.), which can meet the requirements
just described. One recently announced industrial
personal computer which offers iRMX-86 is the
MSC 8807 Industrial PC from Monolithic Systems
Corp. (Englewood, Colo.), see ("Industrial PC goes
to work;.
The' o'perating system contains a nucleus which
gives an applications program or task the means to
monitor and control external events. Tasks running
concurrently are called into execution by interrupts
generated by the real-world process being controlled.
A scheduler inside the operating system decides
whether an executing task should be interrupted to
process data from a device generating an interrupt.
In addition, three facilities inside the operating
system provide for tasks to interact with one
another. Each of the three is optimized for data
transfer, synchronization or mutual exclusion.
Handling multiple tasks. The essence of real-time
application systems is the ability to process
numerous events occurring at randoll) times. Any
single program that attempts to process multiple,
concurrent, asynchronous events is bound to be
complex. It must process each event and remember
which have already occurred and the order in which
th~yhappened. The complexity obviously grows
greater as the system monitors more events.
Multitasking capability in an operating system
unwinds this confusion. Rather than writing a single
monolithic program to process N events, N
progfams are written, each of which processes a '
single event. Each of..these N programs forms an
iRMX 86'task. Multitasking eliminates the need to
monitor the order in which events occur.
The operating system is an interrupt processor.
When an interrupt occurs, it schedules a task to
proce~s the interrupt. This method of event
detection improves the performance of an application system.
There are two ways that computer systems can
schedule processing associated with detecting and

2-256

210341-G115

AR·337

"iRMX 86 uses
preemptive, prioritybased scheduling to
runs at any instance."

PC • INTEGRATION SERIES
controlling events in the real world: polling and
interrupt processing. Polling has the major
shortcoming of requiring a significant amount of the
processor's time to test to see if events have
occurred.
The second method of controlling processing is
the interrupt. An event occurring generates an
interrupt to the computer. Rather than executing
the next sequential instruction, the processor begins
to execute a task associated specifically with the
detected event.
Interrupt processing allows a system to spend all
of its time running the tasks that processes events,
rather than executing a polling loop to see if events
have occurred. Since there is a direct correlation
between interrupts and tasks, a system can easily be
modified to process different events. All that is
needed is to write the tasks to process the new
interrupts.
Because interrupt processing allows a system to
respond to events by means of modularly coded
tasks, system programs are more structured and
easier to understand. Modular programs are less
costly to develop and maintain, and modules can be
developed more quickly than a monolithic program
containing the equivalent of several independent
modules.
Scheduling with priority. The iRMX 86 operating
system uses preemptive, priority-based scheduling
to decide which task runs at any instant. This
technique ensures that if a more important task
becomes ready while a less important task is
running, the more important task begins execution
immediately.
,
In multitasking systems, there are two common
techniques for deciding which task is to be run at any
given moment. One called time slicing, better known
as the familiar round-robin approach, involves tasks
running in rotation. Each task is allotted a fixed
quantity of computer time in whic~ to execute. If it
does not complete in that time, it must relinquish the
CPU and wait-until its turn with the CPU comes up
again. The technique is commonly employed in
time-sharing systems.
The second technique, priority-based scheduling,
uses assigned priorities to decide which task is to be
run next. Within priority-based scheduling, there
are two approaches. N?n-preemptive scheduling
SYSTEMS

a SOFTWARE APRIL 1984

allows a task to run until it relinquishes the
processor. Even if while running it causes a higher
priority task to become ready for execution, the
original task continues to run until it explicitly
surrenders the processor.
The second approach to priority-based scheduling
is preemptive. Using preemptive scheduling, the
system always executes the highest priority task that
is ready to run. In other words, if the executing task
or an interrupt causes a higher priority task to
become ready, the operating system switches the
processor to the higher priority task.
Preemptive, ptiority-based scheduling goes handin-hand with interrupt processing. The priorities of
tasks can be tied to the relative importance of the
events that they process. Thus, the processing of
more-important events preempts the processing of
less-important ones.
Allowing tasks to Interact. The iRMX 86
operating system provides simple techniques for
tasks to coordinate with one another. These
techniques allow programs in a multitasking system
to mutually exclude, synchronize, and communicate
with each other. The processing of several events
may be related. For instance, the task processing
event A may need to know how many times event B
has occurred since event A last occurred. This
processing requires coordination between programs.
Tasks exchange information for two purposes.
One is to pass data from one program to another.
Suppose that one task accumulates keystrokes from
a terminal until a carriage return is encountered. The
keyboard program then passes the entire line of text
to another task, which is responsible for decoding
commands.
The second reason for passing data is, to draw
attention to a specific object, a mailbox for example,
in the application system. In effect, one task says to
another, "I am talking about that object."
The iRMX 86 system facilitates intertask
communications by supplying objects called
mailboxes along with system calls to manipulate
them. The system calls associated with mailboxes
are CREATE ~AILBOX, DELETE MAILBOX,
SEND MESSAGE, and RECEIVE MESSAGE.
Tasks use the first two commands to build and
eradicate a particJ,llar mailbox. They use the
remainder to communicate with each other.

2-257

210341_

AR..337

"The priorities of tasks
can be tied to the
relative importance of
the events that they
process."

PC • INTEGRATION SERIES

If Task A wants task B to become aware of a
This problem can be avoided by mutual
particular object, it uses the SEND MESSAGE exclusion. If task A can prevent task B from
system call to send the object to the mailbox. Task B modifying the table until after A has finished using
uses the RECEIVE MESSAGE system call to it, A can be assured of valid information. Somehow,
retrieve the object from the mailbox. Why don't task A must obtain exclusive use of the table. The
tasks just send messages directly between each other iRMX 86 operating system provides a type of object
rather than through mailboxes? Tasks are asynchro- that can be used to provide mutual exclusion in the
nous; they execute in unpredictable order. form of the semaphore.
A semaphore is an integer counter ,that tasks can
Mailboxes allow tasks to communicate with each
manipulate using four system calls: CREATE
other even though tasks are asynchronous.
If the receiver uses the RECEIVE MESSAGE SEMAPHORE, DELETE SEMAPHORE, SEND
system call before the message has been sent, the UNITS and RECEIVE UNITS. The creation and
receiver waits at the mailbox until a message arrives. deletion system calls are used to build and eradicate
Similarly, if the sender uses the SEND MESSAGE semaphores. The send and receive system calls can
system call before the receiver is ready to receive, the be used to achieve mutual exclusion.
Semaphones can only take on non-negative
message is held at the mailbox until a task requests a
integer values. Tasks can modify a semaphore's
message from the mailbox.
Providing tasks exclusivity. Occasionally, when value by using the SEND UNITS or RECEIVE
tasks are running concurrently, the following kind UNITS system calls. When a task sends N units to a
of situation arises. Task A is in the process of semaphore, the value of the counter is increased by
reading information from a memory segment. An N. When a task uses the RECEIVE UNITS system
interrupt occurs and task B, which has a higher call to request M units from a semaphore, one of two
priority preempts task A. Task B modifies the things happens: If the semaphore's counter is greater
contents of the segment that task A was in the midst than or equal to M, the operating system reduces the
counter by ~ and continues to execute the task.
Task B finishes processing its event and Otherwise, the operating system begins running the
surrenders the processor and task A resumes reading task having the next highest priority, and the
the'segment. However, task A might have requesting task waits at the semaphore until the
information that is completely invalid. For ins'tance, counter reaches M or greater.
To use a semaphore to achieve mutual exclusion,
suppose the application is air traffic control. Task A
is responsible for detecting potential collisions and the task wanting exclusivity creates a semaphore
task B is responsible for updating the plane location with an initial value of one. Before any task uses the
table with the new X- and Y-coordinates of each shared resource, it must receive one unit from the
aircraft's location. U-nless task A can obtain semaphore. Also, as soon as a task finishes using the
exclusive use of the plane location table, task Bean resource, it must send one unit to the semaphore.
make task A faU to spot a collision.
This technique ensures that at any given moment, no
Here's how it could happen. Task A reads the X- more than one task can use the resource, and any
coordinate of the plane's location and is preempted 'other tasks that want to use it must await their turn
by task B. Task B updates the entry that task A was at the semaphore.
reading, changing both the X~ and Y-coordinates of
Semaphores allow mutual exclusion; they don't
the plane's location. Task B finishes its function and enforce it. All tasks (there can be more than two)
surrenders the processor. Task A resumes execution sharing the resource must receive one unit from the
and reads the new X- and Y-coordinate of the semaphore before using the resource. If one task
aircraft's location. As' a direct result of task B fails to do this, mutual exclusion is not achieved.
changing the plane location table while task A was Also, each task must send a unit to the semaphore
reading it, task A thinks the plane is at old X and when the resource is no longer used. Failure to do
new Y coordinates. This misinformation could this can permanently lock all tasks out of the
easily lead to disaster.
resource.
SYSTEMS. SOFTWARE APRIL 1984

2-258

210341·005

intJ

AR-337

must know that a
certain event has
occurred before it
starts running."

PC • INTEGRATION SERIES
Nonetheless, occasionally a task must know that a
certain event has occurred before it starts running.
For instance, suppose that a particular application
system requires that task A cannot run until after
task B( has been completed.
An application system can achieve synchroniza-

tion also by using semaphores. Before executing
either task A or task B, a semaphore is created with
an initial value of zero. Task A issues RECEIVE
UNITS requesting one unit from the semaphore.
Task A is forced to wait at the semaphore until task
B sends a unit. This achieves the desired synchronization.

I ndustrial PC goes to work
One portable computer designed exclusively for the
multitasking industrial and scientific environment IS the
MSC Model 8807 Industrial PC from Monolithic Systems
Corp. (Englewood. Colo ). the first of a planned family of
system and support products that emphasizes software
flexibility by offering two operating systems. four major
languages and a variety of utility programs
Based on the Intel Multibus architecture. the industrial
PC Integrates a 16-bit 80186 CPU. up to 512 kby1es of
parity RAM. 9-in. CRT screen. dual 3Y,-in. floppy disk
drives, parallel and serial I/O ports, and ACSllnterface
The total weighs approximately 35 Ib and Includes a
100-W power supply, cooling fan and built-In carrying
handle. One of two operating systems available for the
PC is Intel's iRMX-86 operating system.
RMX-86 is a multi-user, multitasking, real-time
operating system, which provides such advanced
features as hierarchical file structure with variable file
granularity. It schedules tasks with true real-time
preemptive priorities. It enables dynamic memory
allocation among concurrent applications, device
. independent I/O and intertask communication via
mailboxes and semaphores.
The PC is built around the company's MSC 8186
single-board computer, which, in turn, is based on the
Intel 80186 microprocessor. The processor board
contains 128 kby1es of dual-port, dynamic parity RAM, a
dynamic flAM controller, up to 64 kby1es of EPROM, and
programmable parallel and senall/O ports. Twenty-bit

SVSTEMS .. SOFTWARE APRIL 1984

addreSSing, plus four bits for bank select, enables
addreSSing up to 16 Mbytes of system memory. The
senal I/O port is controlled by a programmable
communications Interface for operatIOn In most
synchronous or asynchronous data transmiSSion .
formats Parallel I/O is Implemented with a baSIC 24
lines controlled by a programmable peripheral interface
An on-board programmable Interrupt controller allows
the system to handle up to eight levels of interrupt
Priority under software control The CPU operates at 8
MHz and has the enhanced 80186 instruction set. The
processor board contains two iSBX bus connectors for
piggyback expansion modules
Product packaging also reflects the targeted
industrial market. The enclosure is metal, rather than
plastiC, and the top of the unit is hinged for easy access
to all internal parts. This permits a user to run an
interface directly off the processor board in addition to
external port connectors.
The chassis is designed with six board slots, of which
three are intended for customer-specified modules. This
is a tool for system integrators who specialize in factory
automation, test systems, process control, R&D
laboratories, and a muHitude of other on-line applications
where system portability is important.
The product can monitor units under test concurrent
with statistical analysis or data processing applications.
As a software development tool, the system can do large
compiling jobs concurrent with code writing or editing.

2-259

21_1-G05

1ranslators and Utilities
for Program Development

3

.'>., '

TRANSLATORS AND UTILITIES
FOR PROGRAM DEVELOPMENT
Intel offers an extensive selection of program development tools for its microprocessor (8080, 8086, 8088,
80186, 80286) and microcontroller (8048, 8051, 8096 etc.) families. These tools include translators and
programming utilities such as linkers, relocators, and library managers. These program development tools are
high quality, time tested tools for the professional. Based on a set of well-defined standards, they provide an
integrated development environment. The result isan extremely flexible and productive program development
environment.
'

A LANGUAGE FOR EVERY NEED
The iAPX-86 family has the most comprehensive set of translators available for a microprocessor. These
include a macro assembler and compilers for PUM, Pascal, FORTRAN, and C (see Table 1). The macro
assembler produces the most optimum code. PUM is the most popular 8086 language for systems
programming and provides the best of both optimal code and high level language capabilities.
The main advantage of 'C' is portability across different target machines. Pascal and FORTRAN are used
extensively for applications programming. To allow applications to be portable, Pascal and FORTRAN conform
to ISO and ANSI77 standards respectively, with many useful extensions for microprocessor applications.
Intel's microcontrollerfamily (8048, 8051, 8096 etc.) is similarly the best supported in the industry. PUM-51 was
the first high level language ever to be introduced for a microcontroller. The 8096 is similarly supported with
PUM-96. Every microcontroller in the family is supported with an assembler and linkage utilities.

USE A MIXTURE OF LANGUAGES FOR MAXIMUM FLEXIBILITY
Programs are typically decomposed into modules to exploit the many benefits of modular programming. Intel's
integrated programming technology allows different modules of the same program to be programmed in a
variety of languages. For instance, the most performance-sensitive system modules may be coded in assembler
or in PUM. The application modules, on the other hand, can be written in Pascal to speed up programming. The
system and application modules can then be linked into one program using the linker. Hence, the various
modules of a program can each be coded in the most suitable programming language.

UTILITIES ENHANCE PROGRAMMING PRODUCTIVITY
A set of utilities is provided to support modular and position independent programming. The linkers combine
the constituent modules of a program into one system. A locator is provided to position the code in memory.
This allows code to be placed in appropriate ROM and RAM locations. Also, coding can be done in a
position-independent way, The librarian provides a structured way of organizing frequently used routines. The
routines needed by a particular program can be linked in by the linker. The linker automatically selects only
those modules from the libaray that are needed by the program. For the protected, virtual-memory, and
multi-tasking processor iAPX 286, a sophisticated operating system configuration utility BUILD-286, is
provided.

FULL RANGE OF DEBUG SUPPORT
The programming tools are integrated with the debugging tools via the well-defined Intel object module format
standard. iAPX-86 family programs may be debugged using any of the Intel 8086 debug tools. This includes
PSCOPE which provides source level software debug, and the ICE products which provide in-target real-time
debug. Microcontroller software is similarly supported by the various emulators and ICE units.

CHOOSE FROM A VARIETY OF HOST CONFIGURATIONS
The programming tools are provided on a variety of development host environments to meet the needs of
different project sizes and development budgets (see Table 1). The environments span personal development
systems (iPDS), stand alone development systems, network development systems (NDS-II) and even the
'VAXNMS microcomputer. The programming tools work identically, no matter which of the available host
configurations is chosen. This allows the user to grow his development environment, as his needs grow,
without impacting previous investment in software.
• VAXNMS is a trademark of Digital Equipment Corporation.

3-1

inter
Table 1. Intelll'anslator/Host Summary

I

Language

Component Family

Macro Assembler + Utilities

2920
MCS-85 Family
MCS-48 Family
MCS-51 Family
iACX-96 Family
iAPX-86 Family
iAPX-286 (Protected Mode)

1,2
1
1
1
2
1,2,3
2,3

PUM

MCS-85 Family
MCS-51 Family
iACX-96 Family
iAPX-86 Family
iAPX-286 (Protected Mode)

1
1
2
1,2,3
2,3

PASCAL

MCS-8S Family
iAPX-86 Family
iAPX-286 (Protected Mode)

1
2,3
2

FORTRAN

MCS-85 Family
iAPX-86 Family
iAPX-286 (Protected Mode)

2
2'

"C"

iAPX-86 Family
iAPX-286 (Protected Mode)

2,3'
2',3'

iAPX-86 Family
iAPX-286 (Protected Mode)

3'
3'

NOTE: '= Planned
HOST CODES
1 = 8085 Based Development System
2 = iAPX-86 family Based Development System
3 =VAX/VMS Minicomputer

3-2

Host Code

1

PL/M 80
HIGH LEVEL PROGRAMMING LANGUAGE
• Speeds Project Completion with
Increased Programmer Productivity

• Provides Resident Operation on
Intellec® Microcomputer Development
System and Intellec® Series II
Microcomputer Development Systems

• Cuts Software Development and
Maintenance Costs

• Produces Relocatable and Linkable
Object Code

• Improves Product Reliability with
Simplified Language and Consequent
Error Reduction

• Sophisticated Code Optimization
Reduces Application Memory
Requirements

• Eases Enhancement as System
Capabilities Expand

The PLiM 80 High Level Programming Language Intellec Resident Compiler is an advanced, high level programming language for Intel 8080 and 8085 microprocessors, iSBC-80 OEM computer systems, and Intellec
microcomputer development systems. PLiM has been substantially enhanced since its introduction in 1973
and has become one of the most effective and powerful microprocessor systems implementation tools available. It is easy to learn, facilitates rapid program development and debugging, and significantly reduces maintenance costs. PLiM is an algorithmic language in which program statements naturally express the algorithm
to be programmed, thus freeing programmers to concentrate on system development rather than assembly
language details (such as register allocation, meanings of assembler mnemonics, etc.). The PL/M compilerefficiently converts free-form PLiM programs into equivalent 8080/8085 instructions. Substantially fewer PLiM
statements are necessary for a given application than would be using assembly language or machine code.
Since PLiM programs are problem oriented and thus more compact, programming in PLiM results in a high
degree of productivity during development efforts, resulting in significant cost reduction in software development and maintenance for the user.

MAY 1983

© INTEL CORPORATION, 1983

ORDER NUMBER:210327-002

3-3

PUM 80
FUNCTIONAL DESCRIPTION

Block Structure - aids In utilization of structured pro·
grammlng techniques.

The PUM compiler Is an efficient multlphase complier
that accepts source programs, translates th.em Into
object code, and produces requested listings. After
compilation, the object program may be first linked to
other modules, then located to a specific area of memo
ory, and finally executed. The diagram shown In Figure 1
Illustrates a program development cycle where the pro·
gram consists of three modules: PUM, FORTRAN, and
assembly language. A typical PUM compiler procedure
Is shown In Table 1.

Acc••• - provided by high level PUM statements to
hardware resources (Interrupt syetem., absolute
addresses, CPU Input/output ports).
Data Dlflnltlon - enabln complex data structures to
be defined at a high level.
A.,.ntr.nt
option.

P~c.dure.

-

may be specified as a user

B.n.fltl
PUM I. designed to be an efficient, co.t,.ff.ctlv••olu·
tlon to the .peclal requlrem.nts of mlcrocomput.r soft,
ware dev.lopm.nt .s IlIu.trat.d by the following b.n.,
fits of PUM use:

F.ltur..
Major features of the Intel PUM ao complier and pro·
grammlng language Include:

Low Learning Effort - .v.n for the novice progr.mm.r,
bec.use PUM I•••• y to I••rn.

Allld.nt Op.ratlon - on Intellec microcomputer devel·
opment systems eliminates the need for a large In·
house computer or costly timesharing system.

Earlier Project Compl.tlon - on critical proj.ct.,
b.caus. PUM substantl.lly Incr..... progr.mmmer
productivity whll. reducing program dev.lopment tim •.

ObJ.ct Cod. O.nlratlon - of relocatable and linkable
object codes permits PUM program development and
debugging In small modules, which may be easily linked
with other modules and/or library routines to form a
complete application.

Low.r D.velopmlnt Co.t - b.cause Incr•••• d pro·
gFammer productivity requiring Ie.. programming
rnource. for a given function tran.late. Into lower .oft·
ware development co.ts.

Extln.lvl Codl Optimization - Including compile time
arithmetic, constant subscript resolution, and common
subEixpresslon elimination, results In generation of
short, efficient CPU Instruction sequences.

Increa.ld Aellablllty - because of PUM's use of simple
statement. In the program algorithm, which are easier
to comlct and thus substantially reduce the- risk of
costly errors In systems that have already reached full
production status.

SymbOlic Dabugglng - fully supported In the PUM
complier and ICE·a5 In·clrcuit emulators.

Easler Enh.ncem.nt and Maintenance - because pro·
grams written In PUM are easier to read and easier to
understand than assembly language, and thus are eas·
ier to enhance and maintain as system capabilities
expand and future products are developed.

Compile Time Options - includes general listing for·
mat commands, symbol table listing, cross reference
listing, and "innerlist" of generated assembly language
instructions.

Figure 1. Program Development Cycle Block Diagram

3-4

AFN·OO818B

PUM 80
ging software for 8080 and 8085 microcomputers, and
the use of expensive (and remote) timesharing or large
computers is consequently not required.

Simpler Project Development - because the Intellec
microcomputer development system with resident
PUM 80 is all that is needed for developing and debug-

Table 1. PL/M-80 Compiler Sample Factorial Generator Procedure
$OBJECT(:F1 :FACT.OB2)$DEBUG
$XREF$TITLE('FACTORIAL GENERATOR $PAGEWIDTH(80) PROCEDURE') FACT: DO; DECLARE NUMCH BYTE PUBLIC; 2 3 4 5 6 2 2 2 FACTORIAl. PROCEDURE (NUM,PTR) PUBLIC; DECLARE NUM BYTE, PTR ADDRESS; DECLARE DIGITS BASED PTR (161) BYTE; DECLARE (I,C,M) BYTE; 10 11 12 13 14 15 2 2 3 3 4 4 4 4 NUMCH=l; DIGITS(l)=l; DO M = 1 TO NUM; C=O; DO 1=1 TO NUMCH; DIGITS(I)= DIGITS(I)*M + C; C= DIGITS(I)/10; DIGITS(I)= DIGITS(I) - 10'C; END, 16 17 18 20 21 22 3 3 4 4 4 4 IF C<>O THEN DO; NUMCH = NUMCH + 1; DIGITS(NUMCH) = C; C = DIGITS(NUMCH)/10, DIGITS(NUMCH)= DIGITS(NUMCH) - 10*C; END END; 24 2 7 9 END FACTORIAL; 25 END; SPECIFICATIONS OPERATING ENVIRONMENT DOCUMENTATION Intel Microcomputer Development Systems (Series II, Series III, Series IV) Intel Personal Development System PliM 80 Programming Manual ISIS-II PliM 80 Compiler Operator's Manual ORDERING INFORMATION SUPPORT: Product Code MDS PLM 'MDS IS Hotline Telephone Support, Software Performance Report (SPR), Software Updates, Technical Reports, and Monthly Technical Newsletters are available Description PliM 80 High Level Language Compiler. Needs Software License an ordering code only and IS not used as a product or trademark MOS' 's a registered trademark of Mohawk Data SCiences Corporation 3-5 AFN-0081B8 FORTRAN 80 8080/8085 ANS FORTRAN 77 INTELLEC® RESIDENT COMPILER • Meets ANS FORTRAN 77 Subset Language Specification plus adds Intel·· microprocessor extensions • Supports full symbolic debugging with ICE·80™ and ICE·85™ • Produces relocatable and linkable object code compatible with resident PL/M 80 and 8080/8085 Macro Assembler • Supports Intel Floating Point Standard with the FORTRAN 80 soft· ware routines, the iSBC·310™ High Speed Mathematics Board, or the ISBC·332 IM math multi module • Provides optional run·time library to execute in RMX·80™ environment • Executes on Intellec Microcomputer Development System, Intellec Series II Microcomputer Development System, and Personal Development System • Has well defined I/O interface for configuration with user·supplied drivers FORTRAN SO is a computer industry-standard, high-level programming language and compiler that translates FORTRAN statements into relocatable object modules. When the object modules are linked together and located into absolute program modules, they are suitable for execution on Intel SOSO/SOS5 Microprocessors, iSBC-SO OEM Computer Systems, Intellec Microcomputer Development Systems and Personal Development Systems. FORTRAN SO meets the ANS FORTRAN 77 Language Subset Specification1 . In addition, extensions designed specifically for microprocessor applications are included. The compiler operates on the Intellec Microcomputer Development System and Personal Development System under the ISIS-II Disk Operating Systems and produces efficient relocatable object modules that are compatible for linkage with PLiM SO and SOSO/SOS5 Macro Assembler modules. The ANS FORTRAN 77 language speCification offers many powerful extensions to the FORTRAN language that are especially well suited to Intel 8080/8085 Microprocessor software development. Because FORTRAN 80 conforms to the ANS FORTRAN 77 standard, the user is assured of compatibility with existing FORTRAN software that meets the standard as well as a guarantee of upward compatibility to other computer systems supporting an ANS FORTRAN 77 Compiler. 1 ANSI X3J3/90 MAY 1983 <£,)INTEL CORPORATION, 1983 ORDER NUMBER:400610-001 3-6 FORTRAN 80 FORTRAN 80 LANGUAGE FEATURES Major ANS FORTRAN 77 features supported by the Intel FORTRAN 80 Programming Language include: o Structured Programming is supported with the IF ... THEN ... ELSE IF ... ELSE ... END IF constructs. • CHARACTER data type permits alphanumeric data to be handled as strings rather than characters stored in array elements. o Full 1/0 capabilities include: Sequential and Direct Access files Error handling facilities Formatted, Free·formatted, and Unformatted data representation Internal (in·memory) file units provide capa· bility to format and reformat data in internal memory buffers List Directed Formatting o Supports arrays of up to seven dimensions. • Supports logical operators .EQV. - Logical equivalence .NEQV. - Logical nonequivalence Major extensions to FORTRAN 77 in Intel FORTRAN·80 include: o Direct 8080/8085 port 1/0 supported by intrinsic subroutines. o o The INCLUDE control permits specified source files to be combined into a compilation unit at com· pile time. Transparent interface for software and hardware floating pOint support, allowing either to be chosen at time of linking. FORTRAN 80 BENEFITS FORTRAN 80 provides a means of developing applica· tion software for Intel MCS·80/85 products in a familiar. widely accepted, and computer industry· standardized programming language. FORTRAN 80 will greatly enhance the user's ability to provide cost· effective solutions to software development for Intel micropro.cessors as illustrated by the following: o Completely Complementary to Existing Intel Soft· ware Design Tools - Object modules are linkable with new or existing Assembly Language and PUM Modules. • Runtime overhead is limited only to facilities required by the program. o Low Learning Effort - FORTRAN 80, like PUM, is easy to learn and use. Existing FORTRAN software can be ported to FORTRAN 80, and programs developed in FORTRAN 80 can be run on any other computer with ANS FORTRAN 77. o Earlier Project Completion - Critical projects are completed earlier than otherwise possible because FORTRAN 80 will substantially increase program· mer productivity, and is complementary to PUM Modules by providing comprehensive arithmetic, 1/0 formatting, and data management support In the language. • Lower Development Cost - Increases In program· mer productivity translates Into lower software development costs because less programming resources are required lor a given function. o Increased Reliability - The nature of hlgh:level languages, Including FORTAN 80, Is that they lend themselves to simple statements of the program algorithm. This substantially reduces the risk of cosily errors In systems that have already reached production status. • Incremental Runtime Library Support - • Binary and Hexadecimal integer constants. o Well defined interface to FORTRAN·80 I/O state· ments (READ, OPEN, etc.), allowing easy use of user·supplied I/O drivers. o User·defined INTEGER storage lengths of 1,2 or 4 bytes. o User·defined LOGICAL storage lengths of 1, 2 or 4 bytes. o REAL STORAGE lengths of 4 bytes. o Bitwise Boolean operations using logical operators on integer values. o Hollerith data constants. • Implicit extension of the length of an integer or logical expression to the length of the left·hand side In an assignment statement. o A format descriptor to suppress carriage return on a terminal output device at the end of the record. Like PUM, program modules written In FORTRAN 80 are easier to read and understand than assembly language. This means It Is easier to enhance and maintain FORTRAN 80 programs as system capabilities expand and future products are developed. • Easler Enhancements and Maintenance - FORTRAN 80 COMPILER FEATURES • Supports multiple compllatfon units In single source file. o Opllonal Assembly Language code listing. o Comprehensive cross·reference, symbol attribute and error listing. • Complier controls and directives are compatible with other Intel language translators. o Optional Reentrancy. • User·deflned default storage leng·the. • Opllonal FORTRAN 66 Do Loop semantics. o Source files may be prepared In free format. • Comprehensive. Yet t;lmp/e Project Development - The Intellec Microcomputer Developmef!t System and Personal Development System, with the 8080/8085 Macro A.8Imbler, PL/M 80 and FORTRAN 80 are the most comprehensive software design facilities available for the Intel MCS-S0/85 Microprocessor family. This reduces development time and cost because expensive (and remote) timesharing or large computers are not required. 3-7 AFN·00241C FORTRAN 80 SAMPLE FORTRAN·80 SOURCE PROGRAM LISTING - • • " " ThIS PROGRAM IS AN EXAMPLE OF ISIS-II FORTRAN-BO THAT CONVERTS TEMPERATURE BETWEEN CELSIUS AND FARENHEIT PROGRAM CONVRT ChARACTER'l CHOICE, SCALE PRINT 100 "ENTER CONVERSION SCALE (C OR F) PRINT 200 READ (5,300) SCALE , 10 IF (SCALE ,EQ. 'C') THEN PRINT 400 " ENTER THE NUMBER OF DEGREES FARENHEIT READ (5,') DEGF DEGC = 5,/9,'(DEGF-32) " PRINT THE ANSWER WRITE (6,500) DEGF,DEGC ,. RUN AGAIN? PRINT 600 READ (5,300) CHOICE IF (CHOICE ,EQ. 'Y') + THEN GO TO 10 ELSE IF (ChOICE .EQ. 'N') + THEN CALL EXIT ELSE GOTO 20 END IF ELSE IF (SCALE .EQ, 'F') + ThEN ** CONVEHT FROM FARENHEIT TO CELSIUS PRINT 700 READ (5,*) DEGC DEGF = 9./5.*DEGC+32. ** PRINT THE ANSWER WRITE (6,800) DEGC,DEGF GOTO 20 ELSE ** NOT A VALID ENTRY FOR THE SCALE WRITE (6,900) SCALE GO TO 10 END IF FORMAT(' TEMPERATURE CONVERSION PROGRAM',II, +' TYPE C FOR FARENHEIT TO CELSIUS OR',I, +' TYPE F FOR CELSIUS TO FARENHEIT' ,II) FORMAT(/,' CONVERSION? ',$)
FORMAT(Al)
FORMATU, 'ENTER DEGREES FARENHE1T: ',$) FORMATU ,F7 .2,' DEGREES FARENHEIT = ',F7 .2,' DEGREES' CELSIUS') FORMAT(/,' AGAIN (Y OR N)? ',$)
FORMAT(/,' ENTER DEGREES CELSIUS: ',$) FORMAT(/,F7.2,' DEGREES CELSIUS = ',F7.2,· DEGREES FARENHEIT',/) FORMAT(/,lH-,Al,' NOT A VALID CHOICE - TRY AGAIN I ',I) END + , , , 20 * * * 100 200 300 400 500 600 700 ~OO 900 3-8 AFN-00241C inter FORTRAN 80 The FORTRAN 80 Compiler is an efficient, multiphase compiler that accepts source programs, translates them Into relocatable object code, and produces requested listings. After compilation, the object program may be linked to other modules, located to a specific area of memory, then executed. The diagram shown below illustrates a program devel· opment cycle where tne program consists of modules created by FORTRAN 80, PUM 80 and the 8080/8085 Macro Assembler. 1111-11 TEXT IDITOII 1"1-11 LOAOEII ;0- DIIUG VIA MONITOR ~ OPTIONAL ICE-IO'" ICE..." IN·CIRCUIT EMULATOR '--- PROM PROGRAMMER 'OIlTIIANIO SOURCE IIII-II TEXT EDITOR ISIS·II TEXT EDITOR ;0- PUMIO SOU liCE ASSEMBLY LANGUAGE SOUIICE RELOCATABLE OBJECT MODULE SPECIFICATIONS DOCUMENTATION PACKAGE OPERATING ENVIRONMENT FORTRAN-80 Programming Manual Required Hardware: ISIS-II FORTRAN-80 Compiler Operator's Manual IMel Microcomputer Development Systems -MDS-800 and Sertes II or FORTRAN-80 Programming Reference Card 2. Personal Development System ORDERING INFORMATION SUPPORT PART NO. DESCRIPTION Model MDS·301 FORTRAN 80 Compiler for Intellec Microcomputer Development Systems Intel offers several levels of support for this product which are explained in detail in the price list. Please consult the price list for a description of the support options available. Requires Software License. *MDS is an ordering code only and is not used as a product name or trademark. MDS is a registered trademark of Mohawk Data Sciences Corporation. 3-9 AFN-00241C MICROSOFT*, INC. BASIC-SO INTERPRETER SOFTWARE PACKAGE • Compatible with other Microsoft BASIC compilers and interpreters • Meets the requirements for the ANSI subset standard for BASIC, and supports many enhancements • Sophisticated string handling and structured programming features for applications development • Extensive text editing features built-in • Automatic line number generation and renumbering • Direct transfer of BASIC programs to the 8085, 8086 and 8088 • Supports assembly language subroutine calls • Random and sequential file manipulation where random file record length is user-definable • Trace facilities for easier debuggi"g • Read or write memory location capabilities BASIC Release 5.0 from Microsoft is an extensive implementation of BASIC. Microsoft BASIC gives users what they want from a BASIC-ease of use· plus the features that are comparable to a minicomputer or large mainframe. BASIC-80 meets the requirements for the ANSI subset standard for BASIC, as set forth in document BSRX3.601978. It supports many unique features rarely found in other BASICs. FEATURES -Four variable types: Integer (-32768, +32767), String (up to 255 characters), Single-Precision Floating Point (7 digits), Double-Precision Floating Point (16 digits). -Formatted output using the PRINT USING facility, including asterisk fill, floating dollar sign, scientific notation, trailing sign, and comma insertion. -Trace facilities (TRON/TROFF) for easier debugging. -Direct access to I/O ports with the INP and OUT functions. -Error trapping using the ON ERROR GOTO statement. -Extensive program editing facilities via EDiT command and EDIT mode subcommands. -PEEK and POKE statements to read or write any memory location. -Assembly language subroutine calls (up to 10 per program) are supported. -Automatic line number generation and renumbering, including reference line numbers. -IF/THEN/ELSE and nested IF/THEN/ELSE constructs. ·--Matrices with up to 255 dimensions. -Supports variable-length random and sequential disk files with a complete·set of file manipulation statements: OPEN, CLOSE, GET, PUT, KILL, NAME, MERGE. -Boolean operators OR, AND, NOT, XOR, EQV, IMP. ©INTEL. CORPORATION. 1983 3-10 MAY 1983 AFN·02086C inter MICROSOFT, INC. BASIC-80 INTERPRETER BASIC-80 Commands, Statements, Functions AUTO LIST NULL TROFF CLEAR LOAD RENUM WIDTH CONT MERGE RUN DELETE NAME SAVE EDIT NEW TRON RANDOMIZE COMMON DEF FN ERROR POKE RESUME SWAP DEFDBL DEFSTR DEFSNG DEFINT ABS INT SGN ATN EXP SIN CDBL CSNG CINT SOR LOG FIX COS RND TAN String Functions Program Statements CALL GOSUB END GOTO STOP WHILE/ WEND CHAIN DEF USR LET REM Arithmetic Functions RETURN WAIT ON GOSUB DIM FOR/NEXT/ STEP IF/THEN/ ELSE ON ERROR GOTO OPTION BASE INSTR RIGHT$
MID$SPACES STR$
HEX$OCT$
VAL

ASC
LEN
STRING$CHR$
LEFT$Operators II <= < > <> XOR NOT EOV MOD IMP OR AND + \ >= Input/Output Statements and Functions CLOSE KILL OUT RESTORE READ TAB DATA LINE INPUT PRINT WRITE LPRINT GET POS FIELD LSET/RSET PRINT USING LOC MKI$
MKS$MKD$
LUST
LPOS

NAME
PUT
EOF
SPC
INKEY$INPUT OPEN CVD CVI CVS Special Functions ERL USR VARPTR PEEK ERR FRE SPECIFICATIONS Operating Environment Required Software The standard disk version of Microsoft BASIC-80 occupies 24K bytes of memory. Microsoft BASIC·eO Interpreter Is compatible with Intel's ISIS operating system or CP/M' operating system. ISIS Operating System or CP/M Operating System. Documentation Package Required Hardware Intellec Microcomputer Development System One C()py of each manual Is supplied with the software package. -IPDS (Personal Development System) -minimum of 1 diskette drive DIlCrlptlon BASIC·eo Aeference Manual BASIC Aeference Book 3-11 AFN·02088C MIC.ROSOF1; INC. BASlc·eo INTERPRETER ORDERING INFORMATION Order Cod. SD102CPMaOF SD1021ssaOF De.crlptlon Microsoft BASIC-aO Interpreter Software Package, CP/M version (Double-Sided, Double Density 5W Floppy) IPDS format Microsoft BASIC-aO Interpreter Software Package, ISIS version (Double-Sided, Double Density 5W Floppy) iPOS format . SUPPORT Intel offers several levels of support for this product, depending on the system configuration in which it is used. Please consult the price list for a detailed description of the support options available. An Intel Software license reqUIred. 'Microsoft IS a trademark of Microsoft. Inc. 'CP/M IS a registered trademark of Digital Research. Inc. 'MP/M-II IS a trademark of Digital Research. In.c. 3-12 AFN-02086C intJ MICROSOFT*, INC. BASIC-80 COMPILER SOFTWARE PACKAGE • Produces highly optimized, true machine code • Compiled programs are fast and compact because of extensive optimizations performed during compilation • Machine code for application program' may be placed on diskette, ROM, or other Media • Provides source program security because only complied code need be distributed to end-users • Supports all the commercial language features of the Microsoft BASIC interpreter (except direct mode commands) • Supports double-precision transcendental functions • Loader format identical to Microsoft's MACRO-80 assembler, COBOL-80 compiler, and FORTRAN-80 complier: Compiled BASIC programs can be loaded and linked with any of these languages Microsoft's BASIC-BO compiler is a powerful tool for programming BASIC applications or microprocessor system software. The single-pass compiler produces extremely efficient, optimized 8080 machine code that is in Microsoft-standard, relocatable binary format. Execution speed is typically 3"-10 times faster than Microsoft's BASIC-80 interpreter. FEATURES Optimized, Compatible Object Code The BASIC compiler produces object code that is highly optimized for speed and space, relocatable, and compatible with other Microsoft software products. The loader format is identical to that of the MACRO-80 assembler, COBOL-80 compiler and FORTRAN-80 compiler, so programs written in any one of these four languages can be loaded and linked together, The compiler can also provide a formatted listing of the machine code that is generated, -The code generator is template-driven, allowing optimal sequences to be generated for the most commonly used operations, -String operations and garbage collection are extremely fast. Cqmpiled programs are fast and compact due to extensive optimizations performed during compilation: Compiled BASIC-80 programs are the Ideal end product for BASIC applications' programmers, The machine code for any application program may be placed on a diskette, ROM, or othllr media. The prcgram not only runs faster than witH the Interpreter, but the BASIC source program n'ed not be distributed. Thus the original application program Is protected from unauthorized alteration. -Expressions are reordered to minimize temporary storage and (wherever possible) to transform floating point division into multiplication, Language Feature. -Constant multiplications are distributed to allow more complete constant folding, The Microsoft BASIC-SO Complier supports all the commercial langua~e features of Microsoft BASIC80, except thOH commands that ars not usable In the compiler environment (I.e., direct mode commands such as LOAD, AUTO, SAVE, EDIT, etc.). That mean. you get the BASIC language compatible with other Microsoft BASIC packages. -Constants are folded wherever possible. The expression reordering finds "hidden" constant operations. -Peephole optimizations are performed, including strength reduction. MII/II13 , INTEL CORPORATION 1983 3-13 ORDIR NUMlllh1l101l470001I intel' MICROSOFT, INC. BASIC-SO COMPILER In addition, the compiler sJpports double-precision transcendental functions (SIN, COS, TAN, ATN, LOG, EXP, SOR), %INCLUDE, CHAIN and COMMON. The %INCLUDE compiler directive brings another source file into the compilation without retyping the main source file. . larger programs because the runtime routine library does not reside in memory during linking. The executable files saved on disk are also much smaller since the BRUN module exists separately. BRUN Runtime Module The BRUN runtime module contains the most common runtime rOlltines needed for most programs .. Using the BRUN module provides faster' link loading of program modules and allows the user to link much The BASIC-80 package includ~s the Microsoft Utility Software Package. The Utility Software Package includes the MACRO-80 macro assembler, the lINK-80 linking loader and the CREF-80 Cross-Reference Facility. Refer to the description of the Microsoft Utility Software Package for full details. SPECIFICATIONS Operating Environme.,t Required Software Utility Software Package CP/M" Operating System The BASIC Compiler requires a minimum of 34K bytes of memory (exclusive of the operating syste,m). Microsoft recommends that 48K bytes .be available for compiling medium to large programs. The compiler itself .occupies about 28K bytes: At runtime, the BRUN module occupies approximately 15.5K bytes. If, as an option, the BRUN module is not used, the runtime library occupies 8K-18K bytes. Documentation Package One copy of each manual is supplied with the software package. Description BASIC Compiler User's Manual BASIC-80 Reference Manual BASIC Reference Book Microsoft Utility Software Manual Required Hardware Intellec Microcomputer Development System -iPDS (Personal Development System) -minimum of 1 diskette driv~ (Specify by Alpha Character when ordering.) ORDERING INFORMATION Description Order Code SD124CPM80F Microsoft BASIC-80 Compiler Software Package, CP/M version (iPDS Format) SUPPORT: Intel offers several levels of support for this product, depending on the system configuration in which it is used. Please c6nsult the price list for a detailed description of the support options available. An' Intel Software ,License required 'Microsoft IS a trademark of Microsoft. Inc 'CP/M IS a registered trademark of Digital Research. Inc 'MP/M-II IS a trademark of Digital ResearCh, Inc 3-14 MICROSOFT* MULTIPLAN* SPREADSHEET the design and use of very • Simplifies large spreadsheets, and multiple inter· related spreadsheets Automatically updates subtotals, • totals, percentages, growth curves, etc Can perform multiple iterations to • solve closed· loop problems Formulas automatically revised when • reordering rows and columns in displays Can be used in time, monetary, and in• ventory budgeting array of sophisticated functions • toWide simplify formulas Cells and areas can be named for • clarity • Can reference and update several in· terrelated spreadsheets at once to use, intuitive commands. • Simple Single keystroke command entry allow several portions of • "Windows" large sheets to be viewed at once Contains the features of the most • popular spreadsheet programs, as well as its contribution of new features Multiplan is a productivity tool designed to help the user to a:nalyze data in spreadsheet format. As an aid to both business and personal needs, Multiplan is an extremely powerful modeling and planning tool. Multiplan is easy to learn and use, yet its versatility is enhanced by the skill of the user. Multiplan allows the user to operate in as intuitive a way as possible, and its widespread capabilities allow accomplishment of a variety of tasks. Advanced users are unencumbered by simplifying features, and have enough power to satisfy their needs. ACTIVE BORDERED WINDOW.2 01 COLUMNS (1-63) ROWS (1·255) MENU SELECTION 1 2$20000.00
3 Sales
4
5 Cost
Material $4000.00 6 7 Labor$7000.00
8
Overhead $4000.00 9 10 Total Costs$15000.00
11

2
3
4
5
6
7
8
9
10
11

$5000.00 12 13 14 15 16 17 18$20000.00
'$4000.00$7000.00
$4000.00 IiiIi$5000.00

STORAGE REMAINING

COMMAND LINE

95% Free

MESSAGE
lC.' . ATION AND CONTENTS
OF ACTIVE CELL

DOLLAR FORMAT

---,f-SHEET NAME

ABSOLUTE REFERENCE

Typical Multiplan Screen Display
The following are trademarks of Intel Corporation and Its affiliates and may be used only to Identlf> Intel products· BXP, CREDIT, I, .CE, leS, 1m, Inslte, Intel, INTEL,
InteleVISlon, Intellmk, Intellec, ,MMX, .OSP, IPDS, IRMX, ISSC, rsax, library Manager, MeS, MULTIMODULE, Megachassis Micromainframe, MULTI BUS, Multichannel, Plug-ABubble, PROMPT, Promware, AU?I, RMXfBO, System 2000, UPI, and the combmatlon of ICS, lRMX, Isec ISBX, ICE, 121CE, MCS, or UPI and numencal suffiX Intel CorporatIon
AS5um6s No Respon51blhty for the use of Any CirCUitry Other Than CircUitry Embodied 10 an Intel product No Other Patent Licenses are Implied. "/ INTEL CORPORATION,
MAY 1983
·Mlcrosoft & Multiplan are trademarks of Microsoft Corp
ORDER NUMBER:210767-002

3-15

FEATURES

-'~oltiplan
~

,

- Names can be used to'" express 'I'cells"
(worksheet elements), or groups of cells. These
names, in: turn, can be ,used 'as parts of formulas and commands. ,Named areas can be
comp,ined in various ways for ease of use.
-A wide range of functions unique to Multiplan
is availal:1le in, additjon to the functiQns typical
to the mqst popular spreadsheet, programs.
These functions allow the user to select' windows, sort data, draw from other worksheets,
and a numbeJ of other impo~tant Je, Insert, or delete entire rows or columns
of data. The remaining rows, columns, or free
space will expand or contr~ct automatically as
necessary, thereby eliminating the costly and
tiresome work of typing or' hanO-prlntlng the
worksheet over and over.

-All commands can be invoked by"a s'ingle
keystroke and selections are menu driven.
Multiplan ev~n offers proposed responses to
commands, to encourage' Its use by even the
most unskilled user. Multiplan's commands,
prompts, and messages, as well as the screen'
and keybo,ard, communicatE! with each other
and the user directly and naturally to allow the
untrained user to accomplish objectives easily.
- A special edit area helps the user to make addi·
tions and deletions quickly and easily.
- Up to eight windows are available to allow
users to view different parts of a very large
worksheet simultaneously. The, windows can
be aligned, scrolled together, opened, or closed
at will.
- An iteration option allows the simulation of
closed-loop problems involving mutually In·
terdependant formulas. The number of Iterations can be chosen" or Iterations can continue
until a given constraint is met.
- Formulas can be moved from one worksheet
locati9n to another without having to be rewrlt·
ten by the user.
- Reference to a particular cell need not be In
absolute terms, but can be expressed as a loca·
tlon relative to other cells. A formula containing
this sort' of relative reference may be copied
Into other cells and will be automatically
changed'to reflect Its new position.
- The sheet display may be redesigned or format·
ted In various ways without affecting the data
sto.red In ~ultl,plan. Thus, the same data can be
presented In different order In different reports
with a minimum of effort.

3-16

placed on the command line for modification. The
edit cursor Is placed at the end of the current
contents rather than highlighting the whole
command, as Is done for other defaults. If the cell
contains a string, It Is presented In double quotes.
After having edited the cell's contents, press
RETURN to put the changed contents back In the
cell (or press ABORT to cancel any changes).

Commands
The following Is a brief list of commands available
under Multiplan. All of these commands are Invoked by the single keystroke of their first letter
(I.e. "C" for Copy or "F" for Format) with the exception of eXternal, which Is Invoked by typing an

"x.

II

Several of the commands offer a number of selections of operational modes, which are displayed
when the command Is Invoked. In order to choose
a mode, either press the TAB key until the cursor
rests over the selected mode, then hit RETURN, or
type the first letter of the selected mode, then hit
RETURN.

FORMAT
Presents a choice of three kinds of format adjustment. To set a specific format for a cell or group of
uells, choose Cells. To set the width of a column
or columns, choose Width. To set the default
format-the format that applies wherever a
specific format hasn't been set-choose Default.

For more detailed descriptions of the commands,
please see the Multiplan User's Manual.

GOTO
Presents a choice of ways to move the cell pOinter
over the sheet. To display a specific row and column, choose Row-col. To display a named area,
choose Name.

ALPHA
Replaces the contents of the active cell with a
character string. If the active cell already contains
a string, that string is the proposed response of
the command, so that it can be edited.

HELP
When help is requested, the spreadsheet is
replaced by text from the HELP file and the HELP
command menu appears on the screen. Help is
available in the areas of Applications, Commands, Editing, Formulas, and the Keyboard. The
spreadsheet display is reinstated when the
RESUME subcommand is entered.

BLANK
Deletes contents of all specified cells. Names are
not affected; if a cell was referred to by a name
before use of this command, that name will still
apply.
COpy
Presents a choice of three ways of copying the
contents of some cells into other cells. To
duplicate one cell across several to its right,
choose Right. To duplicate one cell across several
below it, choose Down. To copy any cell or cells to
any others, choose From.

INSERT
Presents a choice of ways to insert new cells into
the sheet. To insert new rows choose Row. To
insert new columns choose Column.

DELETE
Presents a two-way choice to delete cells. To
delete a row or rows, choose R. To delete a column or columns, choose C. To blank out the cells,
use the Blank command.

LOCK
Provides two ways to lock cells in protection
against accidental change. Either individual cells
or all cells containing formulas can be moved,
deleted, formatted or sorted after having been
locked, but their contents cannot be changed.

EDIT
Makes contents of the active cell available for
editing. Place the cell pointer on the cell to be
edited and press E. The cell's contents are then

MOVE
Presents a choice of ways to move cells around
the sheet. To move whole rows, choose Row. To
move whole columns, choose Column.

3-17

AFN-006498

Table 1. Multiplan Commands
ALPHA
BLANK
COPY DOWN
COPY FROM
DELETE COLUM N
DELETE ROW
EDIT
FORMAT CELLS
FORMAT WIDTH
FORMAT DEFAULT
CELLS
FORMAT DEFAULT
WIDTH
FORMAT OPTIONS
COMMAS
FORMAT OPTIONS
FORMULAS
GOTO ROW·COL
GOTONAME
GOTOWINDOW
HELP APPLICATIONS
HELP COM MAN OS
HELP EDITING
HELP FORMULAS
HELP KEYBOARD
HELP NEXT
HELP PREVIOUS
HELP RESUME
HELP START
INSERT COLUMN
INSERT ROW
LOCK CELLS
LOCK FORMULAS
MOVE COLUMN
MOVE ROW
NAME
OPTIONS
PRINT FILE
PRINT MARGINS
PRINT OPTIONS
PRINT PRINTER
QUIT
SORT
TRANSFER CLEAR
TRANSFER DELETE
TRANSFER OPTIONS
TRANSFER RENAME
TRANSFER SAVE
VALUE
WINDOW BORDER
WINDOW CLOSE
WINDOW SPLIT
HORIZONTAL
WINDOW SPLIT
VERTICAL
WINDOW SPLIT
TITLES
XTERNAL COPY
XTERNAL LIST
XTERNALUSE

Replaces cell contents with a character string.
Clears cell c,ontents.
Used to fill a column with identical values.
Duplicates one or a, number of cells to another location.
Used to make a row of identical values.
Removes columns from the spreadsheet.
Removes'rows from the spreadsheet.
Allows editing of the contents of a single cell.
Used to help align cells in a column.
Limits the width of all cells in a given column.
Sets formats for all previously unformatted cells.
Sets formats for all previously unformatted columns.
Displays numbers with commas separating every third

dig~t.

Displays formulas instead of their values.
Moves the cell pOinter to the specified row and column.
Moves the cell pOinter to the named area.
Places the specified cell within the given window.
Illustrates solutions to a number of common problems.
Lists and describes all commands.
Describes Editing functions.
Gives Formula construction rul':ls.
Explains'l3pecial functions of the keyboard.
Gives the next screenful of HELP text.
Gives the previous sc'reenful from HELP cail.
Returns to the spreadsheet from HELP call.
Begins the HELP tutorial.
Used to add a column to an existing spreadsheet.
Used to add a row to an existing spreadsheet
Protects the indicated cell from alteration.
Locks out alteration of all cells containing formulas or text.
Changes the order of the columns on the sheet.
Changes the order of the rows on the ~heet. '
Assigns a name to a cell or number of cells.
Allows the user to disallow recalculation upon every change of a cell
value, to mute the audible alarm, or to enable the Iteration option.
Outputs the spreadsheet to a diskette file.
Sets up the margins on the printed output.
Allows optional printing modes to be used.
Prints the spreadsheet on the system's printer.
Ends the Multiplan session without saving the active sheet.
Sorts a range of rows to put values In a specified column Into ascending
or descending numerical order.
Clears the active sheet.
Deletes the specified file.
Loads a sheet from the disk file.
Modifies the context of the following transfer operation.
Renames the active sheet.
Saves the active sheet on diskette.
Enters a value or formula Into the active cell.
Changes the border 01 the specified window.
Removes a window from the screen.
Sets orbreaks link for synchronized scrolling between windows.
Horizontally divides a window Inlo two

wlr,~low~.

Vertically divides one window Into two windows.
Divides one window Into two or four which scroll together.
Copies data from an Inactlve'sheet to the active sheet.
Displays the relationships between the active sheet and the other sheets.
Sets a substitute name for a supporting sheet.

3-18

AFN·00849B

Commands (Contln,ued)
NAME
Assigns a name to a cell or area of cells. The
name defined may then be used wherever a
reference to that cell or area Is needed In a com·
mand or formula.
OPTIONS
The Options command can be used to set 'and
reset various options provided with Multiplan.
The Recalc option controls 'how often Multiplan
performs formula calculations. If the option Is on,
Multiplan recalculates all formulas whenever a
cell Is changed. If the option is off, recalculation
Is done only when the Recalc control key Is
pressed or during Transfer Save.
The Recalc option has an effect on how quickly
Multiplan finishes entering a new value in a cell.
The length of time Multiplan takes to recalculate
the sheet depends on how many cells are in use,
and on the complexity of the formulas in them.
When you want to make a number of entries on a
busy sheet, turn the Recalc option off to get the
quickest response. Turn it on again when you are
interested in seeing the effect of each change.
The Mute option silences Multiplan's audible
alarm.
The iterate option gives the user a means of solv-.
ing problems which involve circular or "closed
loop" references. Whereas formulas which count
on each other's results (Le., A = B + C, B = A + C)
are disallowed in other sp.readsheet programs,
Multiplan allows spreadsheets with such
references to be reiterated upon in an orderly
manner either until a maximum number of iterations has been reached, or until a cell has reached
a predetermined value.
PRINT
Presents a choice of four actions related to printing the active sheet. To begin printing, choose Go.
To put printable output In a disk file, choose File.
To set the margins that will be used on the printed
output, choose M~rglns. To fix the part of the
worksheet to be printed, or to insert a control line
at the top of the output, choose Options.
QUIT
Ends the Multiplan session without saving the ac-

tlve sheet. Multiplan requests conflrmatlonj If It Is
given, Multiplan terminates, returning control to
the computer operating system. The active sheet
Is lost unless It has previously been saved.
SORT
Reorders the rows on the spreadsheet so that the
data In a specified column appears In ascending
or descending numerical order. The column to be
sorted may contain numbers, text, or other values,
and If such values are mixed, they are presented
In ascending order numerically, alphabetically
and by error value, after which any bla"k cells
follow.
TRANSFER
Offers a choice of five commands, which affect an
entire sheet.
To load a saved sheet, replacing the active sheet,
To save the active sheet in a disk file, choose
Save.
To give the active sheet a new name, choose
Rename.
To clear the active sheet, deleting all its contents,
and restoring all its default settings, choose
Clear.
To delete the disk copy of the active sheet,
choose Delete.
VALUE
This command' is used to enter a formula or
number into the active cell. VALUE may either be
selected from the command menu or by typing a
numerical value, a mathematical symbol, or a left
parentheses ..
WINDOW
Presents a choice of four things that can be done
with windows.
To open a new window by splitting the active window horizontally or vertically, or to open a window
used strictly for titles, choose Split.
To close a winnow by' removing it from the screen,
choose Close.
To synchronize scrolling of windows, choose Link.

3-19

AFN·00649B

To move a window to a particular part of the sheet,
choose Home.

To copy data, or blocks of data from an inactive
spreadsheet to the active sheet, choose Copy.

To add or remove a decorative border around a
window, choose Border.

To display the relationships between the active
sheet alid other sheets, showing which sheets
support (provide values for) the active one and
which sheets depend on (use values from) the
active sheet, choo!?e List.

XTERNAL
Presents a choice of actions relating.to the use of
data from other sheets in the formulas of the
active sheet.

To assign a substitute name for an inactive sheet,
specify Use.

Table 2. Multiplan Functions

ASS
AND
ATAN
AVERAGE
COLUMN
COS
COUNT
DOLLAR
EXP
FALSE
FIXED
IF
INDEX
INT
ISERROR
ISNA
LEN
LN
LOG10
LOOKUP
MAX'
MID
MIN
MOD
NA
NOT
NPV
OR
PI
REPT
ROUND
ROW
SIGN
SIN
SORT
STDEV
SUM
TAN
TRUE
VALUE

Calculates the absolute value of an argument.
True if, and only if, all values are true; otherwise returns false.
Gives the arctangent of an argument.
Returns the average of all cells referenced by up to 5 arguments.
Gives the current column number.
Calculates an argument's cosine.
Finds the number of cells fitting the referenced criteria.
Formats numbers as dollar amounts.
This is the inverse natural logarithm of the argument.
Returns the logical false value.
Rounds the first argument to the precision specified by the second.
Returns value specified after "THEN" if argument is true, or the "ELSE" specified
value if false.
Returns the value of the cell in a named area offset by an Index value.
Truncates the argument's fractional part.
Returns true If, and only if, the argument Is an error value.
Returns true If, and only if, the argument Is an #N/A value.
Gives the number of characters In the argument's string.
Calculates the natural logarithm Of Its argument.
Returns the common logarithm of Its argument.
Used to search for dependent variables In a lookup table.
Finds the largest numeric value1n an area of cells.
Produces the middle characters of a string.
Finds the smallest numeric value In an area of cells.
Gives the remaInder of the Integer division of the two arguments.
Returns the #N/A value.
Gives the logical Inverse of the argument.
Calculates the net present value of a constant annuity.
True If, and only If, any of the arguments are true; otherwise returns a false.
Returns PI (3.14159 ... ).
Forms a string consisting of a repeated substring.
Rounds the first argument to the precision specified by the second,
GIVes the current row number.
Performs the Signum function on the argument.
Returns the sine of the argument.
Calculates the square root of the argument.
Calculates the standard deviation of the arguments.
Adds the sum of all cells In a specified area.
Calculates the tangent of the argument.
Returns the logical true value.
Used to extract numbers from strings.

3-20

name can then be used In functions, or even as a
response In a command. NAME also allows the
user to review all cell names In their proper position on the screen In order to reduce confusion.

BENEFITS
Unlike other spreadsheet programs, Multiplan
allows the user to create and view as many as
eight different windows within the screen display
area. Complete control Is allowed over each window, allowing windows without borders and the
freezing and scrolling of title columns a~d rows.

Multiplan commands can be entered by single
letters on the command lines, after which the program will fill In the rest of the command. This
speeds the user through complex operations
without leaving any doubt about their functions.
Versatile commands handle not only single data
cells, rows, or columns as do other spreadsheet
programs, but these commands allow Multiplan
to move multiple rows or columns, or Insert,
delete, or handle any rectangular area. All relative
references are automatically adjusted to account
for these changes.

Multiplan allows formulas to describe the contents of any cell. Formulas are written In a method
similar to standard programming languages, and
are evaluated according to priority of functions a
unique feature among spreadsheet progra~s.
Parentheses are allowed to clarify the order of
calculation. Formulas can use a string of
characters as a variable name, and variables may
be either numerical data, or strings of characters
which may be manipulated to concatenate words
and phrases. These are all unusually powerful and
intuitively easy-to-learn features many of which
are unique to Multiplan.

Multiplan automatically updates all entries
affected by a change in a single cell, without requiring the user to command it to do so. This
feature allows the user to fiddle with numbers and
test for sensitivities and trouble spots.

Multiplan gives the user an unusual amount of
flexibility in rearranging the format or layout of a
spreadsheet with its three forms of addressing:
absolute, relative, or symbolic (by name). Any of
the three can be combined in any order to produce
the exact results needed in any case.

Another unique benefit of Multiplan is its ability
to employ values from one sheet in the formulas
of another. This "sheet linkage" can be used to
construct a hierarchy of worksheets, with detailed
worksheets feeding their totals to a summary
worksheet. When a detail sheet is updated and
saved on diskette, the dependent summary sheet
will be automatically updated the next time it is

One of the features that sets Multiplan apart from
other spreadsheet programs is the ability to name
all cells. The NAME command allows the naming
of single cells, an area of ce!ls of any shape, or
even a list of unconnected areas of cells. That

SPECIFICATIONS
Operating Environment

Documentation Package
Multiplan users manual

REQUIRED HARDWARE:
Multiplan requires a minimum system which contains at least:
- 64K bytes of RAM
- 80S0/S0S5 CPU
- Console with absolute cursor positioning
- One Diskette drive
.

Shipping Media
(SpeCify by Alphabetical Character when order.
ing)
A - Single density IBM 3740/1 compatible S"
diskette
B - Double density IBM 3740/1 compatible S"
diskette
F - IPDS1M compatible 5-1/4" diskette

OPTIONAL HARDWARE:
- Li ne pri nter
REQUIRED SOFTWARE:
CP/M' Operating System

·CFJIM JI I reglatared trademark of Digital AII•• ren, Inc.

3-21

AFN-0084tB

ORDERING INFORMATION
Order Code
. SD1 09CPM80A
SD109CPM80B
SD109CPM80F

Shipping Media

Product Description

A-Single-density 8" diskette
B-Double-density 8" diskette
F-iPDS Format 5'/1' diskette

for use under CP/M' on 8080/8085
based small computers.

SUPPORT
Intel offers several levels of support for this product, depending on the system configuration in
which it is used. Please consult the price list for a
detailed description of the support options
available.

3-22

AFN-00649B

inter
PASCAL 80
SOFTWARE PACKAGE
• Offers a Superset of Standard Pascal

• Can Call Routines Written in PL/M 80,
FORTRAN 80, or 8080/8085 Macro
Assembler

• Provides Highly Structured Language
with Powerful Data Type Definitions to
Suit Applications

• Allows Modular Breakdown of Large
Programs and Separate Compilation of
Individual Modules

• Compiles Pascal Source Code into
Intermediate Code to Optimize
Execution Speed and Storage

• Gives Application Control Over
Run-Time Errors by Providing
User-Declared Error Procedures

• Executes Compiler and Interprets the
In~ermediate Code on Intellec®
Microcomputer Development Systems
• Provides a Utility to Produce
Relocatable Object Modules
Compatible with Other Intel®
Languages

PASCAL 80 Software Package consists of a compiler and an interactive Run-Time System designed to provide
the Pascal programming language as a software development tool for Intellec Development System Users.
Pascal is a highly-structured, block-oriented programming language that is now gaining wide acceptance as a
powerful software development tool. Its rigid structure encourages and enforces good programming techniques, which, combined with a high level of readability, helps produce more reliable software.
Standard Intel development tools, such as CREDIT editor car) be used to create and modify Pascal source
programs. The compiler compiles this source and creates a P-Code file. The Run-Time System executes this
P-Code in an interpretive manner undec ISIS-II.
• Pascal language as defined in PASCAL User Manual and Report, Second Edition. Kathleen Jenson and NiklalJs Wirth.

3-23

inter

PASCAL 80

LANGUAGE FEATURES
Data Structures
Pascal allows the user to define labels, constants,
data types, variables, procedures, and functions.

Variable Types
Variables can be defined according to the following
system-defined data types: boolean, integer, real,
character, array, record, string, set, file, and pointer.

PROGRAM TRACING FACILITY
The PASCAL 80 System incorporates a program
tracing facility which allows for selectively monitoring the execution of a Pascal program. When the
TRACE flag is set, the line number of each program
statement being executed is output to the console.
The TRACE flag may be manipulated in two ways:
-The TRACEON command (of the Run-Time System) will set the flag, and the TRACE OFF command will reset the flag.

User-Defined Types

-Pressing the Interrupt 4 switch on the Intellec System front panel will toggle the TRACE flag; I.e., the
flag will be set if it
reset, and vice-versa.

New types can be defined by the user for added
flexibility.

COMPILER DIRECTIVES (PARTIAL LIST)

File Handling Procedures

Compiler Command LIne Directives

Pascal provides procedures to allow a user's program to interface with the ISIS-II file manager.
Routines provided are: RESET, REWRITE, CLOSE,
PUT, GET, SEEK, and PAGE.

NOLIST
No list file is produced; used for fast compilation of
"clean" programs.
-

Was

NOCODE
No code file is produced; used for syntax error
checking.

Input/Output Procedures
Routines are provided to interact with the console or
an ISIS file. These procedures are: READ, WRITE,
READLN, WRITELN, plus BUFFER and BLOCK Read
and Write.

ERRLlST

List file is limited to only those Pascal lines that
contain errors, along with the error messages
produced.

Dynamic Memory Allocation

LIST (file-name)
Specifies the name of the list file.

The procedures NEW, MARK, and RELEASE allow
the user to obtain and release memory space at runtime for dynamically allocating variable storage.

CODE (file-name)
Specifies the name of the code file.

String Handling

NO ECHO
Error lines are echoed on the console unless this directive is specified.

Pascal provides powerful tools for defining and
manipulating strings and. character arrays. These
facilities enable concatenation of strings, character
and pattern scans, insertion, deletion, and pOinter
manipulation.

Embedded Compiler Directives
$C text Causes text to appear in code file (allows for comments, copyrights, etc.). Recursion$1+
Causes checking for I/O completion after each I/O
transfer. Failure results in a run-time error. ($1causes no checking, and no errors on I/O failure.) Pascal allows a PROCEDURE definition to include a call to itself, a powerful construct in many mathematical algorithms. 3-24 AFN-OI2338 inter PASCAL 80$R+

-Pascal is being acclaimed as the programming
language of the future; it is being taught in many
colleges and universities around the country.

Causes Range Checking to occur, so that an out-ofrange value causes a Run-Time error. ($R- suppresses generation of code for Range Checking.) -PASCAL 80 Run-Time System provides great ease in programming formatted I/O operations.$0+
Causes the compiler to operate in overlay mode.
Overlays allow less source code to reside in memory. ($0- causes no overlays, which decreases compile time, since there are fewer disk accesses.) PASCAL 80 provides a portable language for application programs running under ISIS-II. PASCAL 80 can be used to evaluate complicated algorithms using a natural language.$T+

PASCAL 80 compiler generates intermediate
Pseudo-code.

Causes the compiler to generate tracing instructions to be used by the TRACE facility. ($Tsuppresses tracing instructions.) -P-code is optimized for speed and storage space. -P-code is approximately 50% to 70% smaller than corresponding machine code. BENEFITS -P-code is machine independent, providing code portability to any CPU. Brings Pascal to Intellec Microcomputer Development Systems: Makes the Intellec Development System a more valuable tool. Extension of software support to include Pascal makes software development and resource management more flexible. -Pascal is a block-structured, highly-readable programming language, suitable for a wide-range of applications. The source program is created on diskette with the ISIS·II te)tt editor -PASCAL .. loads the Run~Time System which executes compiled PASCAL programs. COMPPROG ... ... Loads the compiler to convert the source program into an interpreted object form known as intermediate code, or P-code. 'PROG ... •.•Loads the Run-nme S,ltem which execute. compiled Peacal programs. Figure 1. Program Development Cycle 3-25 AFN.()l233B ,P~SCAL80 Table 1. Sample Program Ustlng Showing Nesting Levels BUFFER.PAS Program UsUng , Line Seg Proc Lev Disp program example; 3 3 4 3 3 5 ,6 7 44 64 8 65 9 67 108 10 11 o 12 13 14 0 o 27 68 15 87 16 109 109 116 132 179 197 17 18 19 20 2 2 21 208 208 22 23 24 25 26 27 28 29 30 4 226 4 4 262 292 331 4 3 1 o 378 378 388 { 'Example USing bufferread and bufferwrite with break characters I var buffer: stnng, disk storage: hie; break char; new len,len: integer, buff array: packed arraylO. 80101 char; begin rewrite (disk storage, 'data'); wnteln(,lnput a line 01 text: '); readln (buffer), len .= bufferwnte(diSk storage, bufferl1!. length(buffer)), repeat reset(disk storage); writeln, wnteln; wnte('lnput break char Icntrl Z to stopl:, '), readln(break); II not eol(lnput) then begin new len = bufferread(disk storage, buff array, len, ord(break)), wnteln('The buller read. '), wnteln(copy(buffer, 1, abs(new len))); wnteln('Length. ',abs(new len):O); If new len < 0 then wnteln('(Break char not lound)'); end. until eof(lnput), end OPTIONAL SOFTWARE SPECIFICATIONS ISIS-II CREDIT™ (CRT-Based Text Editor) Operating Environment Documentatiol'J Package REQUIRED HARDWARE Intellec$ Microcomputer Development System
-Model BOO
-Series II·Model 220, Model 230, Model 240
64KB of Memory
Dual-Diskette Drives
-Single- or Double-Density·
System Console
-Intel@ CRT or non-IntelCRT PASCAL 80 User's Guide (9B01015-01) PASCAL User Manual and Report, Second Edition, Kathleen Jensen and Niklaus Wirth Shipping Media Flexible Diskettes -Single- and Double-Density "Recommended. REQUIRED SOFTWARE ISIS-II Diskette Operating System -Single- or Double-Density 3-26 intel PASCAL 80 ORDERING INFORMATION Part Number Description MDS-381* PASCAL 80 Software Package Requires Software License ·MDS is an ordering code only and is not used as a product name or trademark. MDS" is a registered trademark of Mohawk Data Sciences Corporation. SUPPORT CATEGORY: Level 0 3-27 AFN-Ol233B inter WordStar~ WORD PROCESSING SOF·TWARE • Streamlines text entry • Horizontal scrolling for wide pages • Wordwrap removes need to worry about right margin • On-screen formatting displays text exactly as It will be printed • All functions easily controlled despite differences in printers and ,consoles • Powerful, reliable, and use,...frlendly word processing software package • Six oo-screen menus and ten Help menus provide quick command reference • Printout enhancements provide numerous combinttd print functions • Simple formatting commands including Hyphe,,-Help WordStar, a popular word processing program written for use under the CP/Mt operating system, gives screen editing oapabilities in an easy to learn and use format. The program is in 'use by programmers, and engineers for documentation and program entry, as well as managers and secretaries. With WordStar. the user can easily make insertions and deletions, move or copy blocks of text, and search for and replace a string of text. WordStar will automatically reformat text upon command as these editing functions are p~rformed. Documents produced by WordStar can include any combination desired of pagination (page numbers), right and left justification, subscripts, superscripts, underlining, boldface type, overstrikes, crossouts, and even accents for use in foreign languages. Commands for all of these are entered with simple control-character keystrokes which are well documented in the program's six help menus. All WordStar commands are easily executed using the CTRL key and the standard typewriter keys. Using the CTRL key, the function of standard keys can be changed to perform useful editing commands. The cursormovement diamond (a group of standard keys on the keyboard) allows fast access to any area of text. Q QUICK MENU r-- W LINE - + Z X SCROLL LINE. Lr - DELm G WORO C4 SCROLL SCREEN DELm LINE WORD F 0 ~J'Ii" .~:R Y T SCNIlL SCIIEtN + S A WORt) R+ E· LINE SCAOI.L V J H HELP MENU SPACE B RI'OIIM I TAB Il1IPA BACK OELm CHAR INSERT ON/OFF co __ U N INSERT RETURN 0 tBIIII MENU K REkAT MENU 11M( BLOCK r--- P PRINT MENU FINOI M RETURN Flgur.1. WordStar Keyboard Functions The follawlng Ire'rldlmarks of Intel Corporation and Itl affillat•• and may be uHd only to identify Irtel pfoducts: B)(P' CREDit I, ICE, ICS. i m, Inslte. Intel, INTEL, InteleVlllon, Int.II"nt IdentH''''· ,'ln~1I8.nt ProgrlmlT!lnglll ,lntelllnk,lnteUlc, IMMX, 10SP. ,POS. ,RMX, ,SBC, ,sex, Library Manager, MCS. MULTIMODULE. Megachass,s, Micromainframe. MUl.TIIUI. Muntc:hlhnel. Pluo-A--Iubbll, PROMPT, Promwarl. RUPI, AMX/80. System 2000, UPI. and tne combination of rCS. IAMX. Isec. ,sex. Ice. 12 ICE, MCS. or UPI and I nur'ftfrIClllUnlx. Intel COrporation AuUITtlI No Alaponalbility for the UN Of Any Circuitry Other Than Circuitry Embodied In an Intel Product. No Other Patent Licenses are IIIIplllCI. {ClINTIL COfIIPOIIATION. ' ..3 _81., MIIIM.". Irld SpeI1811'.ro 1,Id.ml,kl 01 MIc,OP,o Inlllnillonil. 'CP/M II I roglll.rod I,_.,k 01 Dlgllll A_I,ch Inc. , 3-28 MAY'883 ORDER NUMBER:210782-002 intel· WordStar* WORD PROCESSING SOFTWARE FEATURES user each time, searching backward, or to compensate for differences in upper and lower case letters (i.e., at the beginning of a sentence). WordStar is designed to be simple for the novice to use, while remaining sophisticated enough to be appealing to even the most advanced user. Entire blocks of text can be marked at their beginning and ending, then moved to a new area as easily as moving the cursor. Different block control commands allow the duplication and deletion of blocks as well. Standard typewriter keys are combined with the "Control" key to provide a wide variety of editing functions (Fig. 1). All cursor control is localized to the ten keys in the "Cursor-Movement Diamond" (Fig. 2), and the on-screen menu details the functions of the other keys, so the user can quickly find functions without memorizing them. Column Move assists in the creation and editing of tables of data. With Column Move, a column can be taken from one table and moved to another table or to another place in the same table. Columns can also be easily duplicated or deleted. Wordwrap is a feature of WordStar that allows the typist to entirely disregard margins. When typed characters go beyond the right margin, WordStar brings the last full word down to the next line automatically. The only time the Return key needs to be used IS between paragraphs Margins can be automatically right and left justified both during and after entry. Over 20 Page Formatting commands enable a range of functions from producing automatic page headings to overriding built-in parameters for line height and character width. Margins can be set and number of lines typed per page can be dictated via these very simple commands. These page commands are especially useful in long documents. Horizontal Scrolling give the flexibility in creating documents too wide to fit on the video screen. When Wordwrap is disabled and a line is being typed beyond normal screen width, the displayed lines are automatically scrolled offscreen to the left. A single keystroke can be used to move the lines back to their normal position. Editing functions can also use HOrizontal Scrolling to examine and modify any part of a wide document. Decimal Tab is a feature that assists in aligning figures into columns. When a number is entered into a decimal tab position, it will be automatically aligned so that its decimal point is directly below thadecimal pOint of the number on the line above. Files can be combined with each other to form derivative documents. One file can be inserted at any point of another, beginning middle or end, with equal simplicity. The On-Screen Formatting feature displays the text on the screen as it will appear when it is printed. This allows the changing of margins, spacing, and other format variables without requiring the use of a number of intermediate printouts. Print controls, single letters entered while editing to enhance the printout, permit the user of underscore, boldface, underlining, double-strike, superscript, subscript, overprint, and nearly any combination of the above. This facilitates the generation of mathematical formulas with subscripts and superscripts, and allows the text to include foreign words and phrases with accents above and below certain letters. Alternate character pitch, for italics, and even ribbon color selection can be controlled by WordStar if these options are available on the printer in use. Hyphen-Help aids in reformatting by positioning the cursor over a word requiring hyphenation at the end of a line, and allowing the user to select a hyphenation point or decide not to hyphenate. Hyphens entered this way are "soft", and will not be printed if the document is reformatted and the hyphen is no longer required. Permanent or "hard" hyphens are inserted while typing and will always be printed. Can be used with MailMerge· to generate chained printing combining form letters with mailing lists. Mail Merge allows names to be drawn from the address and insertod i .... to the text of the form letter. WordStar's Find and Replace command allows the text to be scanned for a specified character string. Once the string is found it will be replaced quickly with the updated information. Options with this command allow the user to perform functions like finding the "nth" occurrence, performing the operation "n" times, replacing the string without verification by the SpellStar· may also he used with WordStar to check the spelling in a document against both a 20,000word standard dictionary and a user-generated supplemental dictionary which can be used to store names, buzz words, or abbreviations. 3-29 AFN-01315B WordStar* WORD PROCESSING SOFTWARE WordStar is easily adapted to nearly any video terminal and document printer, despite the wide variation of options and communication standards used by these devices. At installation time the user is prompted through a sllries of questions which configure that WordStar installation to fit the hardware at hand. On-Screen Menus are displayed at the top of the screen along with the text being edited. Should the user desire to filt the entire screen with text, the menu displays can be turned on and off as desired. The ten Help Menus guide the user through the use of alt editing functions from Moving Text to Paragraph Reform. When an existing file is edited and saved, any previous version of the file is saved under the original filename as a .BAK extension (Le., after updating a file entitled "LETTER" there would be two files, LETTER and LETTER.BAK on the diskette). When a document is to be updated, its latest extension is automatically used as input. Whenever a new .BAK extension is created, the older .BAK version is destroyed. WordStar allows documents of almost any size to be entered and edited. A Memory Management feature automatically transfers text to and from mass storage if the document is too farge to be held in main memory at one time. There are six Main Menus (Fig. 3A-3F) and ten Help Menus to guide even the most inexperienced user through a WordStar editing session. The Main or A:TFSl' .r:cx: Figure 2. The Cursor Movement Diamond CDL 1 INSERl' ON MAIN MENO »> * * CUrsor Movenent * * '* Delete *' * Miscellaneous * , * Other Menus * "s char left "'D char right '''G char '''I Tab "'B Refollll , (fran Main only) "A word left "p word right IOEL chr 1£' "V Insert On or Off I"J Help "R Block "E line up P1GE 1 LINE 1 «< "'X line down '''T word rt' "'L PindiReplce again '''0 Quick "p print line IRE'l.'IJRN End paragraph 1"0 Onscreen , "N Insert a Rm'tlRN , , "0 Stop a CCIIIIIIU'ld 1 * * SCrolling * * I "y "z line up "'W line down 1 "c screen up '"R screen down' L-l-l-l-l-l-I-I-I-I-I-I R • Figure 3A. Main Menu: guide to the most frequently used commands. This menu -and all other menus-can be called up at any time, or dropped to allow full·screen viewing of the text. A:TEST.OOC PAGE 1 LINE 1 CX>L 1 <<< HEL P INSERT ON MEN U H Display and set the help level , B Paragraph reform (CTRL B command) F Flags in rightmost column of screen o Dot commands, print ctrl(P command) , >>> S Status line R Ruler line M Margins and tabs P Place markets V Moving text. 1 * Other Menus * 1 (from Main only) '''J Help' "K Block '''0 Quick "p Print 1"0 Onscreen . 'Spacebar returns 'you' to Main Menu. L---l-l--I-I--~l--I---l---I---I----I---I ..----R • Figure 3B. Help Menu: a directory of commands that control help levels and show reference Information. 3-30 WordStar* WORD PROCESSING SOFTWARE AQ A:TEST.DOC PAGE 1 LINE 1 COL 1 INSERT ON <<< QUI C K MEN U >>> * * Cursor Movement * *1* Delete *1 * Miscellaneous * I * Other Menus * S left side D right side IY line rtlF Find text in file I (from Main only) E top of scrn X bottom scrnlDEL lin IflA Find .and Replace IAJ Help AK Block R top of file C end of filel* * * *IL Find misspelling IAQ Quick Ap Print B top of block K end of block IQ Repeat conmand or I AO Onscreen 0-9 marker Z up Wdown I key until space ISpace bar returns V last Find or block I bar or other key Iyou to Main Menu. L----!----!----I---l---l--l--!--I--I--I--I-----R • Figure 3C. Quick Menu: expanded cursor movement, deletion, find/replace commands, and place marker commands. AK A:TEST.DOC PAGE 1 LINE 1 COL 1 INSERT ON «< BLOCK MENU »> * Saving Files * 1* Block Operations *1 * File Operations *1 * Other Menus * S Save and resumelB Begin K End IR Read P Print I (from Main only) D Save--done IH Hide / Display 10 Copy E Rename IAJ Help AK Block X Save and exit IC Copy Y DeletelJ Delete IAQ Quick Ap Print Q Abandon file IV Move W Write 1* Disk Operations *IAO Onscreen * Place Markers *IN Column off (ON) IL Change logged disk ISpace bar returns 0-9 Set/hide # 0-91 IF Directory on (OFF) Iyou to Main Menu. L---!--I---!--I--!--I---I---I--I--I--l R • Figure 3D: Block Menu: Instructions for using block and place markers, saving and printing a file, and inserting other files. AO A:~EST.DOC PAGE 1 LINE 1 COL 1 INSERT ON < < < 0 N S C R E E N MEN U > > > * Margins & Tabs * 1* Line Functions *1 * More Toggles * I * Other Menus * L Set left margin IC Center text IJ Justify off (ON) I (from Main only) R Set right margin IS Set line spacing IV vari-tabs off (ON) IAJ Help AK Block X Release margins I IH Hyph-help off (ON) IAQ Quick Ap Print I Set N Clear tab I * Toggles * IE Soft hyph on (OFF) lAO Onscreen G Set paragraph tablW Wrd wrap off (ON) ID Prnt disp off (ON) ISpace bar returns F Ruler from line IT Rlr line off (ON)IP Pge break off (ON) Iyou to Main Menu. L---! ----I---I---I--I--I--! --I --1--1--1- ------R • Figure 3E. Onscreen Menu: functions that perform onscreen documel'lt formatting (such as line spacing, tabs, margins, justification, and wordWrap). 3-31 AFN·01315B WotdStar""WORD PROCESSING SOFTWARE p A:TFST.DOC Pi\GE 1 LINE 1 COL 1 INSERT ON « < P R ' I N T MENU ,»> , *Special Effects*1 * Special EffeCts * 1* Printing Changes *1 * Other Menus * Jbe9in and end) I (one'time each) IA Alternate pitch I (fran Main only) B Bold D QoublelH OVerprint characterlN Standard pitch IAJ Help ~K Block S Underscore IONon-br~k space Ie Printing pause I~Q Quick ~P Print X StrikeQut IF Phantan'space . IY Other ribbon color I ~O Onscreen V Subscript IG Phantan rubout I * User Patches *ISpace bar returns T Superscript IRETURN OVerprint linelQCl) W(2) E(3) R(4) Iyou to Main Menu. L----I----I----I----I----I----I----I----I----I----I----I--------R A • Figure 3F. Print Menu: special print control characters Including llIubscrlpts, superscripts, boldface, double strike, and strikeout. BENEFITS WordStar is an advanced word-processing program that can turn any CP/M based personal computer into a sophisticated yet easy to learn and use text processor. It takes very little time for even the leasttrained user to learn to productively generate documentation with WordStsr. The simplifying features of WordStar do not detract from its acceptance by advanced users. Menu.s and other features are designed to be unobtrusive when they are not needed. WordStar's sophistication means that it will not run out of horsepower as the user progresses, but will always be an appealing and highly productive tool. With WordStar there is no question about the appearance of the printed output, since the text can be displayed on the screen exactly as it is to be printed. Time savings when using WordStar will be considerable. Generation of new text is easier than by handwritten/typed means. When WordStar is used for program editing it supplies powerful features unavailable in other editors. With WordStar, both code and documentation can be generated at the same time within the same environment. 3-32 WordStar* WORD PROCESSING SOFTWARE Table 1. EDITING COMMAND INDEX " hold CTRl key, type letter "A cursor left word "B reform paragraph "c scroll up screenful "0 cursor right character " E. cursor up line " F cursor right word "G delete character right H cu rsor left character " I tab " J help PREFIX " K editing PREFIX " l findlreplace again " M (Same as RETURN) " N insert hard carriage return 0 formatting PREFIX " P print control PREFIX " 0 editing PREFIX " R scroll down screentul " S cursor left character " T delete word right " U interrupt " V insert onloff " W scroll down line " X cursor down line " Y delete line " Z scroll up line ·· JB · JD · JFJH · JI · JM · JP ·, JR JS , JV explain reform summarize print directives explain Flags set Help level command il"ldex explain tabs and Margins explain Place markers explain Ruler line explain Status line explain moVing text 'KO-'K9 • KB , KC , KD , KE , KF , KH , KJ ' KK KL • KN • KO , KP set/hide marker 0-9 mark/hide Block beginning Copy block Done edit (save) rEname file File directory on/off Hide/display marked block delete additional file mark blocK end change Logged disk column mode onloff cOpy file Print "KO " KR " KS " KV "KW " KX " KY abandon edit Read additional file Save and reedit moVe block Write block to additional file save and eXit delete block " OC " 00 Center cursor line print control display onloff soft hyphen Entry onloff margins & tabs from line paraGraph tab Hyphen-Help onloff set tab stop Justification onloff set left margin clear tab stop P'!lge break display onloff set Right margin set line Spacing ruler display onloff Wordwrap " OE OF OG OH " " " " 01 " OJ OL ON OP OR OS OT OW - · PA-" PZ PM PO " 00- " 09 · · ·· , , , ·, , , ·, , , OA OB OC QD QE QF QK QL QP QQ QR QS QV QW QX QY QZ Qde' , DEL ' ESCAPE : LINE FEED RETURN ' TAB 3-33 enter" A-"Z make next line overprint enter non-break space cursor to marker·0-9 find and replace cursor Block beginning cu rsor end file cursor right end line cursor top screen Find cursor blocK end find misspelling cursor Previous position repeat next command cursor beginning of file cursor left Side screen cursor source continuous downward scroll cursor bottom of screen delete to end line continuous upward scroll delete ~o beginning line clllete character left error release (samE! as J) hard carriage return tab AFN·OI315B WordStar*WORD PROCESSING SOFTWARE Table 1. (Continued) NO:"FILE COMMANDS D E F H L M N open a Document file rEname file File directory on/off set Help level change Logged disk run MailMerge (optional) open a Non-document file 0 P R S X V cOpy file Print Run program run SpeliStar (optional) eXit to operating system delete file ~ SPECIFICATIONS DOCUMENTATION PACKAGE OPERATING ENVIRONMENT Wordstar Training Guide Wordstar Operator's Guide Wordstar General Information Manual Wordstar Reference Manual Wordstar Installation Manual Hardware Required 8080 or 8085 CPU 5V4" or 8" Diskette drive Printer 64K Bytes of memory . Console with absolute cursor addressing Note Intellee Series II and III reqUIre IMDX-Sll Optional hardware SUPPORT Intel offers several levels of support for this product, depending on the system configuration in which it is used. Please consult the price list for a detailed description of the support options available. Intel software license is required. Additional mass storage Software Required CP/M 2.2 operating system ORDERING INFORMATION Description WordStar word processing software package for use under the CP/M operating system Order Code Shipping Media SD111 CPM80ASU A-Single-density 8" 'diskette SD111 CPM80BSU B-Double-density 8" diskette SD111 CPM80FSU F...... iPDS Format 5V4" diskette AFN·01315B inter iAPX 86,88 SOFTWARE DEVELOPMENT PACKAGES FOR SERIES II/PDS • PUM 86/88 High Level Programming Language • ASM 86/88 Macro Assembler for iAPX 86,88 Assembly Language Programming • LINK 86/88 and LOC 86/88 Linkage and Relocation Utilities • CONY 86/88 Converter for Conversion of 8080/8085 Assembly Langaage Source Code to iAPX 86, 88 Assembly Language Source Code • OH 86/88 Object-to-Hexadecimal Converter • LIB 86/88 Library Manager The IAPX 86,88 Software Development Packages for Series II provide a set of software development toois for the iAPX 86/88 CPUs and the ISSC 86/12A single board computer The packages operate under the ISIS-II operating system on Intel Microcomputer Development Systems-Model 800, Series II or the Personal Devel~ opment System (PDS)-thus minimiZing requirements for additional hardware or training for Intel Microcom, puter Development System users. These packages permit 8080/8085 users to efficiently upgrade existing programs into iAPX 86/88 code from either 8080/8085 assembly language source code or PLiM 80 source code. For the new Intel Microcomputer Development System user. the packages operating on a PDS or an Intellec Series II, such as a Model 235, provide total iAPX 86,88 software development capability. 'C INTEl COPPORATION 1983 MAY 1983 3-35 AFN-01239E inter iAPX 86,88 SOFTWARE DEVELOPMENT PACKAGES FOR SERIES II/PDS . PUM 86/88 COMPILER FOR SERIES II/PDS • Language is Upward Compatible from PL/M 80, Assuring MCS-80/85™ Design Portability • Produces Relocatable Object Code Which is Linkable to All Other 8086 Object Modules • Supports 16-bit Signed Integer and 32-bit Floating Point Arithmetic in Accordance with IEEE Proposed Standard • Supports Full Extended Addressing Features of the iAPX 86/10 and 88/10 Microprocessors (Up to 1 Mbyte) • Easy-to-Learn, Block-Structured' Language Encourages Program Modularity • Code Optimization Assures Efficient Code Generation and Minimum Application Memory Utilization Like its counterpart for MCS-80/85 program development, PUM 86/88 IS an advanced, structured high-level programming language. The PUM 86/88 compiler was created specifically for performing software development for the Intel iAPX 86,88 Microprocessors. PUM 86/88 has significant new capabilities over PUM 80 that take advantage of the new facilities provided by the iAPX 86,88 microsystem, yet the PUM 86/88 language remains compatible with PUM 80. With the exception of. hardware-dependent modules, such as Interrupt handlers, PUM 80 applications may be recompiled with PUM 86/88 with little need for modification. PUM 86/88, like PUM 80, is easy to learn, facilitates rapid program development, and reduces program maintenance costs. PUM IS a powerful, structured, high-level system implementation language in which program statements can naturally express the program algorithm. This frees the programmer to concentrate on the logic of the program without concern for burdensome details of machine or assembly language programming (such as register allocation, meanings of assembler mnemonics, etc.). The PUM 86/88 compiler efficiently converts free-form PUM language statements into equivalent 86/88 machine instructions. Substantially fewer PUM statements are necessary for a given application than if it were programmed at the assembly language or machine code level. The use of PUM high-level language for system programming, instead of assembly language.. results in a high degree of engineering productivity during project development. This translates into significant reductions in initial software development and follow-on maintenance costs for the user. FEATURES structure allows the use of REENTRANT which is especially useful in system design. Major features of the Intel PUM 86/88 compiler and programming language include: Language Compatibility Block Structure PL/M 86/88 object modules are compatible with object modules generated by all other 86/88 translators. This means that PUM programs may be linked to programs written in any other 86/88 language. PL!M source code is developed in a series of modules, procedures, and blocks. Encouraging program modularity in this manner makes programs more readable, and easier to maintain and debug. The language becomes more flexible by clearly defining the scope of user variables (local to a private procedur global to a public module, for example). Object modules are compatible with ICE-88 and ICE-86 units; DEBUG compiler control provides the In-CirCUit Emulators with symbolic debugging capabilities. PUM 86/88 Language is upward-compatible with PL/M 80, so that application programs may be easily ported to run on the iAPX 86 or 88. The use of procedures to break down a large problem is paramount to productive software development. The PUM 86/88 implementation of a block 3-36 AFN-01239E intel' iAPX 86,88 SOFTWARE DEVELOPMENT PACKAGES FOR SERIES II/PDS Supports Five Data Types Interrupt Handling PUM makes use of five data types for various applications. These data types range from one to four bytes, and facilitate various arithmetic, logic, and addreSSing functions' PLIM has the facility for generating interrupts to the iAPX 86 or 88 via software. A procedure may be defined with the INTERRUPT at~ribute, and the compiler will automatically initialize an interrupt vector at the appropriate memory location. The compiler will also generate code to same and restore the processor status, for execution of the user-defined interrupt handler routine. The procedure SETINTERRUPT, the function retuning
an INTERRUPT$PTR, and the PLIM statement CAUSE$INTERRUPT all add flexibility to user programs involving interrupt handling.

-Byte:
-Word:
-Integer:
-Real:
-Pointer:

8-bit unsigned number
16-bit unsigned number
16-blt Signed number
32-bit floating POint number
16-bit or 32-bit memory address
indicator

Another powerful facility allows the use of BASED
variables that map more than one variable to the
same memory location. This IS especially useful for
passing parameters, relative and absolute addressIng, and memory allocation

Two Data Structuring Facilities
In addition to the five data types and based variables,
PLIM supports two data structuring facilities. These
add fleXibility to the referencing of data stored in
large groups.
-Array:
-Structure:

Indexed list of same type data
elements
Named collection of same or different type data elements

-Combinations
Arrays of structures
of Each:
structures of arrays

or

8087 Numerics Support
PLIM programs that use 32-bit REAL data may be
executed using the Numeric Data Processor for improved performance. All floating-point operations
supported by PUM may be executed on the8087
NDP, or the 8087 Emulator (a software module)
provided with the package. Determination of use of
the chip or emulator takes place at link-time, allowIng compilations to be run-time independent.

Segmentation Control
The PLIM 86/88 compiler takes full advantage of
program addressing with the SMALL, COMPACT,
MEDIUM, and LARGE segmentation controls. Programs with less than 64KB total code space can
exploit the most efficient memory addressing
schemes, whi.ch lowers total memory requirements.
Larger programs can exploit the flexibility of extended one-megabyte addreSSing.

Code Optimization
The PLIM 86/88 compiler offers four levels of optimization for significantly reducing overall program
size.
-Combination or "folding" of constant expressions; and short-circuit evaluation of Boolean expressions.
-"Strength reductions" (such as a shift left rather
than multiply by 2); and elimination of common
sub-expressions within the same block.
-Machine code optimizations; elimination of
superfluous branches; re-use of duplicate code;
removal of unreadable code.
-Byte comparisons (rather than 20-bit address calculations) for pointer variables; optimization of
based-variable operations.

Compiler Controls

Built-In String Handling Facilities

The PLIM 86/88 compiler offers more than 25 controls that facilitate such features as:

The PUM 86/88 language contains built-In functions
for string manipulalton. These byte and word functions perform the following operations on character
strings: MOVE, COMPARE, TRANSLATE, SEARCH,
SKIP, and SET.

-Conditional compilation
-Intra- and Inter-module cross reference
-Corresponding assembly language code in the
listing file
-Setting overflow conditions for run-time handling

3-37

AFN-01239E

inl:el'iAPX 86,88 SOFTWARE DEVELOPMENT PACKAGES FOR SERIES II/PDS

BENEFITS
PL/M 86/88 is designed to. be an efficient, costeffective solution to the special requirements of
iAPX 86 or 88 Microsystem Software Development,
as illustrated by the following benefits of PLIM use:

because less programming resources are required
for a given programmed function.

Increased Reliability
PLIM 86/88 is designed to aid in the development of
reliable software (PLIM 86/88 programs are simple
statements of the program algorithm). This substantially reduces the risk of costly correction of errors in
systems that have already reached full production
status, as the more simply stated the program is, the
more likely it is to perform its intended function.

Low Learning Effort
PLIM 86/88 is easy to learn and to use, even for the
novice programmer.

Earlier Project Completion
Critical projects are completed much earlier than
otherWise possible because PLIM 86/88, a
structured high-level language, increases programmer productivity.

Easier Enhancements and Maintenance
Prog rams written in PL/M tend to be selfdocumenting, thus easier to read and understand.
This means it is easier to enhance and maintain
PL/M programs as the system capabilities expand
and future products are developed.

Lower Development Cost
Increases in programmer productivity translate immediately into lower software development costs

iAPX 86,88 MACRO ASSEMBLER
FOR SERIES II/PDS
• Powerful and Flexible Text Macro
Facility with Three Macro Listing
Options to Aid Debugging

• High-Level Data Structuring Facilities
Such as "STRUCTUREs" and
"RECORDs"

• Highly Mnemonic and Compact
Language, Most Mnemonics Represent
Several Distinct Machine Instructions

• Over 120 Detailed and Fully Documented Error Messages

• "Strongly Typed" Assembler Helps
Detect Errors at Assembly Time

• Produces Relocatable and Linkable
Object Code

ASM 86/88 is the "high-level" macro assembler for the iAPX 86,88 assembly language. ASM 86/88 translate~
symbolic 86/10,88/10 assembly language mnemonics into 86/10, 88/10 relocatable object code.
ASM 86/88 should be used where maximum code efficiency and hardware control is needed. The iAPX 86,88
assembly language includes approximately 100 instruction mnemonics. From these few mnemonics the
assembler can generate over 3,800 distinct machine instructions. Therefore, the software development task is
simplified, as the programmer need know only 100 mnemonics to generate all possible 86/10, 88/10 machine
instructions. ASM 86/88 will generate the shortest machine instruction possible given no forward referencing
or given explicit information as to the characteristics of forward referenced symbols.
ASM 86/88 offers many features normally found only in high-level languages. The iAPX 86,88 assembly
language is strongly typed. The assembler performs extensive checks on the usage of variables and labels.
The assembler uses the attributes which are derived explicitly when a variable or label is first defined, then
makes sure that each use of the symbol in later instructions conforms to the usage defined for that symbol.
This means that many programming errors will be detected when the program is assembled, long before it is
being debugged on hardware.

3-38

AF~-01239E

inter IAPX 86,88 SOFTWARE DEVELOPMENT PACKAGES FOR SERIES II/PDS
FEATURES

Over 120 Detailed Error Messages

Major features of the Intel iAPX 86,88 assembler and
assembly language include:

-

Powerful and Flexible Text Macro Facility
-

-

Macro calls may appear anywhere
Allows user to define the syntax of each macro
Built-in functions
conditional assembly (IF-THEN-ELSE, WHILE)
repetition (REPEAT)
string processing functions (MATCH)
support of assembly time 1/0 to console (IN, OUT)
Th'ree Macro Listing Options include a GEN
mode which provides a complete trace of all
macro calls and expansions

Support for ICE·86™ Emulation and
Symbolic Debugging
-

-

Debug options for inclusion of symbol table in
object modules for In-Circuit Emulation with
symbolic debugging.

Generates Relocatable and Linkable
Object Code-Fully Compatible with
LINK 86/88, LOC 86/88 and LIB 86/88

High·Level Data Structuring Capability
-

Appear both in regular listfile and error printfile.
User documentation fully explains the occurrenCe of each error and suggests a method to
correct it.

STRUCTURES: Defined to be a template and
then used to allocate storage. The familiar dot
notation may be used to form instruction
addresses with structure fields.
ARRAYS: Indexed list of same type data elements.
RECORDS: Allows bit-templates to be defined
and used as instruction operands andlor to allocate storage.

Permits ASM 86/88 programs to be developed
and debugged in small modules. These modules
can be easily linked with other ASM 86/88 or
PL/M 86/88 object modules and/or library
routines to form a complete application system.

Fully Supports IAPX 86,88

-

BENEFITS

Provides for complex address expressions involving base and indexing registers and
(structure) field offsets.
Powerful EaU facility allows complicated expressions to be named and the name can be used
as a synonym for the expression throughout the
module.

The iAPX 86,88 macro assembler allows the extensive capabilities 'of the 86/88 CPU's to be fully exploited. In any application, time and space critical
routines can be effectively written in ASM 86/88. The
86,88 assembler outputs relocatable and linkable object modules. These object modules may be easily
combined with object modules written in PL/M
86/88-lntel's structured, high-level programming
language. ASM 86/88 compliments PL/M 86/88 as the
programmer may choose to write each module in the
language most appropriate to the task and then combine the modules into the complete applications program using the iAPX 86,88 relocation and linkage
utilities.

Powerful STRING MANIPULATION
INSTRUCTIONS
-

Permit direct transfers to or from memory or the
accumulator.
Can be prefixed with a repeat operator for repetitive execution with a count-down and a condition test.

3-39

AFN-01239E

inter

.

iAPX 88,88 SOFTWARE DEVELOPMENT PACKAGES FOR SERIES II/PDS

. CONV 86/88
MCS@·80/85 to iAPX 86,88 ASSEMBLY LANGUAGE
CONVERTER UTILITY PROGRAM·

• Translates 8080/808.5 Assembly
Language Source Code to iAPX 86,88
Assembly Language Source Code
• Provides a Fast and Accurate Means to
Convert 8080/8085 Programs to the
iAPX 86/88 Facilitating Program
PortabUity

• Automatically Generates Proper ASM
86/88 Directives to Set Up a "Virtual
8080" Environment that Is Compatible
with PL/M 86/88

In support of Intel's commitment to software portability, CONY 86/88 is offered as a tool to move 8080/8085
programs to the iAPX 86/88. A comprehensive manual, "MCS-86 Ass'embly Language Converter Operating
Instructions for ISIS-II Users," covers the entire conversion process. Detailed methodology of the conversion
process is fully described therein.

-

CONY 86/88 will accept as input an error-free
8080/8085 assembly-language source file and
optional controls, and produce as output, optional PRINT and OUTPUT files.

-

The PRINT file is a formatted copy of the
8080/8085 source and the 86/88 source file with
embedded caution messages.

Because CONY 86/88 is a transliteration process,
there is the possibility of as much as a 15%-20%
code expansion over the 8080/8085 code. For compactness and efficiency it is recommended that critical portions of programs be re-coded in iAPX 86,88
assembly language.

-

The OUTPUT file is an 86/88 source file.

Also, as a consequence of the transliteration, some
manual editing may be required for converting instruction sequences dependent on:

-

CONY 86/88 issues a caution message when it
detects a potential problem in the converted
86/88 code.

-instruction length, timing, or encoding
-interrupt processing"
-PWM parameter passing conventions"

....:... A transliteration of the 8080/8085 programs occurs, with each 8080/8085 construct mapped to its
exact 86/88 counterpart:

"Mechanical editing procedures for these are suggested in the converter manual.

Registers
Condition flags
Instruction
Operands
Assembler directives
Assembler control lines
Macros

The accompanying figure illustrates the flow of the
conversion process. Initially, the abstract program
may be represented in 8080/8085 or iAPX 86,88 assembly language to execute on that respective target
machine. The conversion process Is porting a source
destined for the 6080/8065 to the 86/88 via CONY
66/88.
3-40

AFN·01239E

intel'

iAPX 86,88 SOFTWARE DEVELOPMENT PACKAGES FOR SERIES II/PDS

ABSTRACT PROGRAM

SOURCE CODE
IN 8080/8085
ASSEMBLY LANG

~"

. ~..

"

FOR
8080lB085

SOURCE CODE
IN 86110, 88110
ASSEMBl V LANG

ALGORITHM

~

CONY 86188

r•

~SSEM9LE
-------ioiL._ 86/10,
_
FO,...R_--I
88110

!

1
EXECUTe
ON
80808085

EQUIVALENT
FUNCTION

EXECUTE
ON
86110, 88/10

Figure 1. Porting 8080/8085 Source Code to the iAPX 86/10 and 88/10

• Automatic Combination of Separately
Compiled or Assembled iAPX 86, 88
Programs Into a Relocatable Module

• Automatic Generation of a Summary
Map Giving Results of the LINK 86/88
Process

• Automatic Selection of Required
Modules from Specified Libraries to
Satisfy Symbolic .References

• Abbreviated Control Syntax
• Relocatable Modules may be Merged
into a Single Module Suitable for
Inclusion in a Library

• Extensive Debug Symbol
Manipulation, Allowing Line Numbers,
Local Symbols, and Public Symbols to
be Purged and Listed Selectively

• Supports "Incremental" Linking
• Supports Type Checking of Public and
External Symbols

LINK 86/88 combines object modules specified in the LINK 86/88 input list into a single output module. LINK
86/88 combines segments from the input modules according to the order in which the modules are listed.
LINK 86/88 will accept libraries and object modules built from PLIM 86/88, ASM 86/88, or any other translator
generating Intel's iAPX 86/88 Relocatable Object Modules.
Support for incremental linking is provided since an output module produced by LINK 86/88 can be an input to
another link. At each stage in the incremental linking process, unneeded public symbols may be purged.
LINK 86/88 supports type checking of PUBLIC and EXTERNAL symbols reporting an error if their types are not
consistent.
LINK 86/88 will link any valid set of input modules without any controls. However, controls are available to control the output of diagnostic information in the LINK 86/88 process and to control the content of the output
module.
LINK 86/88 allows the user to create a large program as the combination of several smaller, separately compiled modules. After development and debugging of these component modules the user can link them
together, locate them using LOC 86/88 and enter final testing with much of the work accomplished.

3-41

AFN·01239E

intel'

iAPX 86,88 SOFTWARl: DEVELOPMENT PACKAGES FOR SERIES II/PDS

LIB 86/88
• LIB 86/88 is a Library Manager
PrograR:! which Allows You to:
Create Specially Formatted Files to
Contain Libraries of Object Modules
Maintain These Libraries by Adding or
Deleting Modules
Print a Listing of the Modules and
Public Symbols in a Library File

• Libraries Can be Used as Input to
LINK 86/88 Which Will Automatically
I,.ink Modules from the Library that
Satisfy External References in the

• Abbreviated Control Syntax

Libraries aid in the job of building programs. The library manager program LIB 86/88 creates and maintains
files containing object modules. The operation of LIB 86/88 is controlled by commands to indicate which operation LIB 86/88 IS to perform. The commands are:
CREATE:
DELETE:
LIST:
EXIT.

creates an empty library file
adds object modules to a library file
deletes modules from a library file
lists the module directory of library files
terminates the LIB 86 program and returns control to ISIS-II

When using object libraries, the linker will call only those object modules that are required to satisfy external
references, thus saving memory space.

LOC 86/88
• Automatic Generation of a Summary
Map Giving Starting Address, .Segment
Addresses and Lengths, and Debug
Symbols and their Addresses

• Automatic and Independent
Relocation of Segments. Segments
May Be Relocated to Best Match
Users Memory Configuration

• Extensive Capability to Manipulate the
Order and Placement of Segments in
iAPX 86/88 Memory

• Extensive Debug Symbol
Manipulation, Allowing Line Numbers,
Local Sy.mbols, and Public Symbols to
be Purged and Listed Selectively

• Abbreviated Control Syntax

Relocatabllity allows the programmer to code programs or sections of programs without having to know the
final arrangement of the· object code in memory.
LOC 86/88 converts relative addresses in an input module to absolute addresses. LOC 86/88 orders the segments in the input module and assigns absolute addresses to the segments. The sequence in which the segments in the input module are assigned absolute addresses is determined by their order in the input module
and the controls supplied with the command.
LOC 86/88 will relocate any valid input module without any controls. However, controls are available to control
the output of diagnostic info.rmation in the LOe 86/88 process, to control the content of the output module, or
both.
The program you are developing will almost certainly use some mix of random access memory (RAM), readonly memory (ROM), and/or programmable read-only memory (PROM). Therefore, ttie location of your program affects both cost and performance in your application. The relocation feature allows you to develop your
program on the Intellec development system and then simply relocate the object code to suit your application ..
3-42

AFN-01239E

inter iAPX 86,88 SOFTWARE DEVELOPMENT PACKAGES FOR SERIES II/PDS
OH 86/88
• Converts an iAPX 86/88 Absolute
Object Module to Symbolic

• Converts an Absolute Module to a
More Readable Format that can be
Displayed on a CRT or Printed for
Debugging

• Facilitates Preparing a File for Later
Loader, such as the iSBC™ Monitor
SDK-86 Loader, or Universal PROM
Mapper

The OH 86/88 utility converts an 86/88 absolute object module to the hexadecimal format This conversion may
be necessary to format a module for later loading by a hexadecimal loader such as the iSBC 86/12 monitor or
Universal PROM Mapper The conversion may also be made to put the module in a more readable format than
can be displayed or printed
The module to be converted must be

In

absolute format; the output from LaC 86/88 is in absolute format.

Figure 2. iAPX 86,88 Software Development Cycle

3-43

AFN·01239E

inl:el"

iAPX 86,88 SOFTWARE DEVELOPMENT PACKAGi:S FOR SERIES II/PDS

SPECIFICATIONS

ORDERING INFORMATION

Operating Environment

iAPX 86,88 Software Development
Packages for Series II:

Intel Microcomputer Development Systems
Intel Personal Development System

Documentation

Part No.

Description

PL/M-86 Programming Manual
MDS-308*

Assembler and Utilities
Package

MDS-309*

PUM compiler and Utilities
Package

MCS-86 Assembly Language Converter Operating
Instructions for ISIS-1/ Users

MDS-311 *

PUM compiler, Assembler,
and Utilities Package

Universal PROM Programmer User's Manual

All Packages ReqUire Software Licenses

ISIS-1/ PL/M-86 Compiler Operator's Manual
. MCS-86 User's Manual
MCS-86 Software Development Utilities Operating
Instructions for ISIS-1/ Users
MCS-86 Macro Assembly Language Reference
Manual
MCS-86 Macro Assembler Operating Instructions
for ISIS-1/ Users

SUPPORT:
Hotline Telephone Support, Software Performance Reports (SPR), Software Updates, Technical Reports,
Monthly Newsletters are available

*MDS is an ordering code only and IS not used as a product name or trademark. MDS® is a registered trademark of Mohawk Data Sciences Corporation.

3-44

AFN-01239E

86/88/186/188 SOFTWARE PACKAGES
FORTRAN 86/88 Software Package

PUM 86/88/186/188 Software Package

•

•

Advanced Structured System Implementation Language for Algorithm
Development

•

Supports 16-bit Signed Integer and
32-bit Floating Point Arithmetic in
Accordance with IEEE Proposed
Standard

•

Easy-to-Learn Block-Structured
Language Encourages Program
Modularity

Features High-Level Language
Support for Floating-Point
Calculation, Transcendentals,
Interrupt Procedures, and run-time
exception handling

•

Meets ANS FORTRAN 77 Subset
Language Specifications

•

Supports Complex Data Types

PASCAL 86/88 Software Package
•

Resident on iAPX 86 Based Intel
Microcomputer Development Systems

•

Object Compatible and Linkable with
PUM 86/88, ASM 86/88 and FORTRAN
86/88

•
•

Implements Full C Language
Produces High Density Code
Rivaling Assembler

•

Supports Large Array Operation

•

Supports Intel Object Module
Format (OMF)

iC-86 C Compiler for the 8086

ASM PROGRAMS

PL/M PROGRAMS

TARGET
SYSTEM

:il
;::
:::;

;::

:::!
W

CPROGRAMS

C!l

~

Z

:::;
CD

""

X

FORTRAN
PROGRAMS

Il.

COMPATIBLE
DEBUGGERS
e.g. PSCOPE,
ICETM DEBUGGER

:'!

PASCAL PROGRAMS

Figure 1. Program modules compiled with any of the iAPX 86 languages may be linked together.
Each language is compatible with Intel's debug tools.
Intel Corporation Assumes No Responsibility for the Use of Any Circuitry Other Than CircUitry Embodied In an Intel Product No Other CirCUit
Patent LIcenses are Implied Information Contained Herem Supercedes Previously Published SpecIfications On These DeVices From Intel
INTEL CORPORATION. 1983

3-45

SEPTEMBER 1984
ORDER NUMBER: 210689·003

FORTRAN 86/88
SOFTWARE PACKAGE
• Features high-level language support
for floating-point calculations,
transcendentals, interrupt procedures,
and run-time exception handling
• Meets ANS FORTRAN 77 Subset
Language Specifications
• Supports iAPX 86/20, 88/20 Numeric
Data Processor for fast and efficient
execution of numeric instructions
• Uses REALMATH Floating-Point
Standard for consistent and reliable
results
• Supports Arrays Larger Than 64K
• Unlimited User Program Symbols

• Offers powerful extensions tailored to
microprocessor applications
• Offers upward compatibility with
FORTRAN 80
• Provides FORTRAN run-time support
for iAPX 86,88,186,188-based design
• Provides users ability to do formatted
and unformatted I/O with sequential or
direct access methods
• ICE™ SymboliC Debugging Fully
Supported
• PSCOPE Source Level Debugging Fully
Supported
• Supports complex data types

FORTRAN 86/88 meets the ANS FORTRAN 77 Language Subset Specification and includes many features of
the full standard. Therefore, the user is assurep of portability of most existing ANS FORTRAN programs and of
full portability from other computer systems with an ANS FORTRAN 77 Compiler.
FORTRAN 86/88 programs developed and debugged on the Intel Microcomputer Development Systems may be
tested with the prototype using ICE symbolic debugging, and executed on an RMX-86 operating system, or on a
user's iAPX 86,88,186,188-based operating system.
FORTRAN 86/88 is one of a complete family of compatible programming languages for iAPX 86,88,186,188
development: PUM, Pascal, FORTRAN, and Assembler. Therefore, users may choose the language best suited
for a specific problem solution.

1983

MAY 1983

3-46

intel'

FORTRAN 86/88 SOFTWARE PACKAGE

FEATURES

Intel® Microprocessor Support

Extensive High-Level Language
Numeric Processing Support

FORTRAN 86/88 language features support of iAPX
86/20, 88/20 Numeric Data Processor

Single (32-bit), double (64-bit), and double extended
precision (80-bit) floating-pOint data types

Compiler generates in-line iAPX 86/20, 88/20 Numeric Data Processor object code for floating-point
arithmetic (See Figure 1)

REALMATH Proposed IEEE Floating-Point Standard) for consistent and reliable results

Intrinsics allow user to control iAPX 86/20, 88/20
Numeric Data Processor

Full support for all other data types: integer, logical,
character

iAPX 86,88,186,188 architectural advantages used
for indexing and character-string handling

Ability to use hardware (iAPX 86/20, 88/20 Numeric
Data Processor) or software (simulator) floatingpoint support chosen at link time

Symbolic debugging of application uSing ICE
emulators

ANS FORTRAN 77 Standard

Source level debugging using PSCOPE.

[FLOATING.POINT.STATMENT ]

TEMPER = (PRESS - VOlUM I JUEK) - 3.45 I (PRESS - VOlUM I QUEK)
- (PRESS - VOlUM I QUEK) * (PRESS - VOlUM I QUEK)

&

OBJECT CODE GENERATED

I

Intel FORTRAN-86 Compl.ler
iAPX 86/20, 88/20
MACHINE CODE

0013
0018
0010
0022
0025
0026
002E
0031
0034
0037
0034
0030
0040
0045

9309060COO
9608360000
9B082E0800
960001
9B2E083EOOOO
9609C9
960002
9BOEE9
9609C1
9B08C8
9BOOC2
9BOEE1
9B091E0400
9B

[iSSEMBLER

-

FlJ
F DIV
FSU5~

FST
FOIV~

FXCrlG
FST
FSU6RP
FLO
FMUl
FFREE
FSUSP
F5TP
wAIT

MNEMONI~ •

, STAT::MENT

#

2

VOlUM
:;)UEK
PRESS
T:JS+1H
CS:@CONST
TOS+1H
TOS+2H
T:J5+1H
T05
TOS+2f1
TEMPER

Figure 2. Object Code Generated by FORTRAN 86/88 for a Floating·Point Calculation Using iAPX 86/20,
88/20 Numeric Processor.

3-47

AFN-016538

intel·

FORTRAN 86/88 .SOFTWARE PACKAGE

Microprocessor Application Support

Early Project Completion

-Direct byte- or word-oriented port I/O

FORTRAN is an industry-standard, high-level
numerics processing language. FORTRAN programmers can use FORTRAN 86/88 on microprocessor projectswith Iittle.retraining. Existing FORTRAN software can be compiled. with FORTRAN
86/88 and programs developed in FORTRAN 86/88
can run on other computers with ANS FORTRAN 77
with little or no change. Libraries of mathematical
programs using ANS 77 standards may be compiled
with FORTRAN 86/88.

-Reentrant procedures
-Interrupt procedures

Flexible Run-Time Support
Application object code may be executed in iAPX 86,
88,186,188-based environment of user's choice:
-a Series III or Series IV Intellec Development System
-an iAPX 86,88,186,188-based system with iRMX-86
Operating System

Application Objec~ Code
Portability for a Processor Family.

-an iAPX 86,88,186,188-based system with userdesigned Operating System

FORTRAN 86/88 modules "talk" to the resident Intellec development operating system using Intel's standard interface for all development-system software.
This allows an application developed under the ISISII operating system to execute on iRMX/86, or a usersupplied operating system by linking in the iRMX/86
or other appropriate interface library. A standard
logical-record interface enables communication
with non-standard I/O devices.

Run-time exception handling for fixed-point numerics, floating-point numerics, and I/O errors
Relocatable object libraries for complete run-time
support of I/O and arithmetic functions. In-line code
execution is generated for iAPX 86/20, 88/20 Numeric Data Processor
.

BENEFITS
FORTRAN 86/88 provides a means of developing application software for the Intel iAPX 86,88,186,188
products lines in a familiar, widely accepted, and
industry-standard programming language. FORTRAN 86,88 will greatly enhance the user's ability to
provide cost-effective software development for
Intel microprocessors as illustrated by the foliowing:

Comprehensive, Reliable
and Efficient Numeric Processing
. The unique combination of FORTRAN 86/88, iAPX
86/20, 88/20 Numeric Data Processor, and
REALMATH (Proposed IEEE Floating-Point Standard) provide univel'6al consistency in results of
numeric computations and efficient object code
generation.

SPECIFICATIONS

Documentation Package

Operating Environment

FORTRAN 86/88 User's Guide

Intel Microcomputer Development Systems (Series
III/Series IV)

3-48

AFN-016538

FORTRAN 86/88 SOFTWARE PACKAGE

ORDERING INFORMATION
Part Number Description
MDS*-315

FORTRAN 86/88 Software Package

SUPPORT
Intel offers several levels of support for this product
which are explained in detail in the price list. Please
consult the price list for a deSCription of the support
options available.
*MDS is an ordering code only and is not used as a product name or trademark. MDS is a registered trademark of
Mohawk Data Sciences Corporation.

3-49

AFN·O,653B

intJ
PASCAL 86/88
. SOFTWARE PACKAGE
on IAPX 86 Based Intel
• Resident
Microcomputer Development Systems
Compatible and Linkable with
• Object
PUM 86/88, ASM 86/88 and FORTRAN

•

86/88
ICE™ Symbolic Debugging Fully
Supported

• PSCOPE Source Level Debugging Fully
Supported
REALMATH for Consistent
• Implements
and Reliable Results
• Supports large array operation

• Unlimited User Program Symbols
IAPX86/20, 88/20 Numeric
• Supports
Data Processors
Implementation of ISO Standard
• Strict
Pascal
Extensions Essential for
• Useful
Microcomputer Ai)pllcatlons
Compilation with Type• Separate
Checking Enforced Between Pascal
Modules

•

Complier Option to Support Full RunTime Range-Checking

PASCAL 86/88 conforms to and implements the ISO Draft Proposed Pascal standard. The language is
enhanced to support microcomputer applications with special features, such as separate compilation, interrupt handling and direct port I/O. To assist the development of portable software, the compiler can be directed
to flag all non-standard features.
The PASCAL 86/88 compiler runs on Series III and Series IV Microcomputer Development Systems. A well-defined I/O interface is
provided for run-time support. This allows a user-written operating system to support application programs as an alternate to the
development system environment. Program modules compiled under'PASCAL 86/88 are compatible and linkable With modules
written in PLIM 86/88, ASM 86/88 or FORTRAN 86/88. With a complete family of compatible programming languages for the iAPX
86,88, 186, 188 one can implement each module in the language most appropriate to the task at hand.

PASCAL 86/88 object modules contain symbol and type information for program debugging using ICE™
emulators and PSCOPE source language debugger. For final production version, the compiler can remove this
extra information and code.

Intel--Corporatlon Assumes No Responsibility for the Use of Any Circuitry Other Than Circuitry Embodied In an Intel Product. No Other
Circuit Patent Licenses are Implied. Information Contained Herein Supercedes Previously Published Specifications of These Devices
JUNE 1984
from Intel.
© INTEL CORPORATION, 1983

3-50

PASCAL 86/88

FEATURES

Supports numerous compiler options to control the
compilation process, to INCLUDE files, flag nonstandard Pascal statements and others to control
program listings and object modules.

Includes all the language features of Jensen & Wirth
Pascal as defined in the ISO Draft Proposed Pascal
Standard.

Utilizes the IEEE standard for Floating-Point Arithmetic (the Intel REALMATH standard) for arithmetic
operations.

Supports required extensions for microcomputer
applications.

Well-defined and documented run-time operating
system interfaces allow the user to execute the applications under user-designed (',perating systems.

-Interrupt handling
-Direct port 110
Separate compilation extensions allow:

Predefined type extensions allow:

-Modular decomposition of large programs

-Create precision in read, integer, and unsigned
calculations.

-Linkage with other Pascal modules as well as PUM
86/88/186/188, ASM 86/88/186/188 and FORTRAN
86/88.

-Means to check 8087 erl"Ors
-Circumvention of rigid type checking on calls to
non-Pascal routines

-Enforcement of type-checking at LINK-time

BENEFITS

Provides run-time support for co-processors. All
real-type arithmetic is performed on the 86/20 numeric data processor unit or software emulator.
"Run-time library routines, common between Pascal
and other Intel languages (such as FORTRAN), permit efficient and consistently accurate results.

Provides a standard Pascal for iAPX 86,88,186,188
based applications.
-Pascal has gained wide acceptance as the portable application language for microcomputer
applications

Extended relocation and IInkaye support allows the user to
link Pascal program modules With routines wntten In other
languages for certain parts of the program. For example, realtime or hardware dependent routmes wntten In ASM
86/88/186/188 or PUM 86/88/186/188 can be linked to Pascal
routines. further extending the user's ability to wnte structured
and modular programs.

-It IS being taught in many colleges and universities
around the world
-It is easy to learn, originally Intended as a vehicle
for teaching computer programming
-Improves maintainability: Type mechanism is
both strictly enforced and user extendable
-Few machine specific language constructs

PASCAL 86/88 programs "talk" to the resident
operating system using Intel's standard interface for
translated programs. This allows users to replace
the development operating system by their own
operating systems in the final application.

Strict Implementation of the proposed ISO standard
for Pascal aids portability of application programs. A
compile time option checks conformance to the
standard making it easy to write conforming
programs.

PASCAL 86/88 takes full advantage of IAPX 86, 88, 186, 188
high level language architecture to generate effiCient machine
code

PASCAL 86/88 extensions via predefined procedures for interrupt handling and direct port 110 make
It possible to code an entire application in Pascal
without compromising portability.

Compiler options can be used to control the program
listings and object modules. While debugging, the
user may generate additional information such as the
symbol record information required and useful for
debugging using PSCOPE or ICE emulation. After
debugging, the production version may be streamlined by removing this additional information.

Standard Intel REALMATH is easy to use and provides reliable results, consistent with other Intel
languages and other implementations of the IEEE
proposed Floating-Point standard.

3-51

AFN-01652B

PASCAL '86/88

SPECIFICATIONS
Operating Environment

Documentation PacJ(age

REQUIRED HARDWARE
Intel Microcomputer Deve!opment Sys,tems (Series III. Series

PASCAL 86 User's Guide

IV)

ORD,ERING INFORMATION
Part Number

Descr:iption

MDS*-314

PASCAL 86/88 Software Package

• MDS is an ordering code only and IS not used as a product name or trademark, MDS" is a registered trademark of Mohawk Data Science,

SUPPORT:
Hotline Telephone Support. Software Performance Report (SPR). Software Updates. Technical Reports. and
Monthly Technical Newsletters are available.

3-52

AFN-01652B

PL/M 86/88/186/188 Software Package
Systems Programming Language for
• the
iAPX 86/88/186/188 Processors
Language Is Upward Compatible from
• PUM
80, Assuring MCS®-80/85 Design

Improved Compiler Performance Now
• Supports
More User Symbols and
Faster Compilation Speeds

•

Portability
Structured System Imple• Advanced
mentation Language for Algorithm

Produces Relocatable Object Code
Which Is Linkable to All Other 8086
Object Modules

Code Optimization Assures Efficient
• Code
Generation and Minimum

Development

Application Memory Utilization

Supports 16-Bit Signed Integer and
• 32-Bit
Floating Point Arithmetic in

Built-In Syntax Checker Doubles Per• formance
for Compiling Programs

Accordance with IEEE Proposed
Standard

Containing Errors

Block-Structured
• Easy-to-Learn
Language Encourages Program

Resident on iAPX 86 Intel Micro• computer
Development Systems

Modularity
PUM 86 is an advanced, structured, high-level systems programming language. The PUM 86 compiler was
created specifically for performing software development for the Intel 8086, 8088, 80186 and 80188 Microprocessors. PUM was designed so that program statements naturally express the program algorithm. This frees the
programmer to concentrate on the logic of the program without concern for burdensome details of machine or
assembly language program~ing (such as regist~r allocation, meanings of assembler mnemonics, etc.).
The PUM 86 compiler efficiently converts free-form PUM language statements into machine instructions. Substantially fewer PUM statements are necessary for a given application than if it were programmed at the assembly
language or machine code level.
The use of PUM high-level language for system programming, instead of assembly language, results in a
high degree of engineering productivity during project development. This translates into significant reductions in initial software development and follow-up maintenance costs for the user.

NOTE The Intellec@ Development System pictured here IS not Included With the PLfM 86/88 Software package but merely depicts a language In Its operating environment
The follOWing are trademarks of Intel Corporation and Its affiliates and may be used only to identIfy Intel products 8XP, CREDIT, I, ICE, leS, 1m, In site, Intel, INTEL, IntaleVISlon,
Intellnk, Intellee, IMMX, IOSP, lPDS, IRMX, ,sac, .SBX, library Manager, MeS, MULTIMODULE, Megachassls Micromainframe, MULTI BUS, Multichannel, Plug-A·Bubble,
PROMPT, Promware, RUPI, RMX/80, System 2000, UPI, and the combination ICS, IRMX, ISBC, IS ex, ICE, 121CE, MCS, or UPI and numerical suffiX Intel Corporation Assumes No
Responsibility for the use of Any Circuitry Other Than Circuitry Embo~led In an Intel product No Other Patent Licenses are Implied ©INTEL CORPORATION, 1983
MAY 1983

3-53

inter

PL/M 86/88/186 SOFTWARE PACKAGE

Another powerful facility allows the use of BASED
variables that map more than one variable to the
same memory location. This is especially useful
for passing parameters, relative and absolute addressing, and memory allocation.

FEATURES
Major features of the Intel PLiM 86 compiler and
programming language include:

Block Structure
Two Data Structuring Facilities

PLiM source code is developed in a series of
modules, procedures, and blocks. Encouraging
program modularity in this manner makes programs more readable, and easier to maintain and
debug. The language becomes more flexible, by
clearly defining the scope of user variables (local
to a private procedure).
The use of procedures to break down a .Iarge
problem is paramount to productive software
development. The PLiM 86 implementation of a
block structure allows the use of REENTRANT
(recursive) procedures, which are especiaily useful in system design.

In addition to the five data types and based
variables, PLiM supports two data structuring
facilities. These help the user to organize data into logical groups.
- Array: Indexed list of same type data elements
- Structure: Named collection of same or different type data elements
- Combinations of Each: Arrays of strl!ctures or
structures of arrays

8087 Numerics Support
PLiM programs that use 32-bit REAL data may be
executed using the Numeric Data Processor for
improved performance. All floating-point operations siJpported by PLiM may be executed on the
iAPX 86/20 or 88/20 NDP, or the 8087 Emulator (a
software module) provided with the package.
Determination of use of the chip or Emulator
takes place at linktime, allowing compilations to
be run-time independent.

Language Compatibility
PLiM 86 object modules are compatible with object modules generated by all other iAPX 86
translators. This means that PLiM programs may
be linked to programs written in any other iAPX 86
language.
Object modules are compatible with In-Circuit
Emulators; DEBUG compiler control provides the
In-Circuit Emulators with symbolic debugging
capabilities.
PLiM 86 Language is upward compatible with
PLiM 80, so that application programs maybe
easily ported to run on the iAPX8\5.

Supports Seven Data Types

Built·ln String Handling Facilities
The PLiM 86 language contains built-in functions
for string manipulation. These byte and word
functions perform the following operations on
character strings: MOVE, COMPARE,
TRANSLATE, SEARCH, SKIP, and SET.

. Interrupt Handling

PLiM makes use of seven data types for various
applications. These data types range from one to
four bytes, and facilitate various arithmetiC, logiC,

PLiM has the facility for handling interrupts. A
procedure may be defined with the INTERRUPT
attribute, and the compiler will automatically initialize an interrupt vector at the appropriate
memory location. The compiler will also generate
code to save and restore the processor status, for
execution of the user-defined interrupt handler
routine. The procedure SET$INTERRUPT, the function retuning an INTERRUPT$PTR, and the
PLiM statement CAUSE$INTERRUPT all add flexibility to user programs involving interrupt and handling. -Byte: 8-bit unsigned number -Word: 16-bit unsigned number -DWORD: 32-bit unsigned number -Integer: 16-bit signed number -Read: 32-bit floating point number -Pointer: 16-bit or 32-bit memory address indicator -.,Selector: 16-bit base portion of a pointer 3-54 AFN-01661C intJ PL/M 86/88/186 SOFTWARE PACKAGE - Combination or "folding" of constant expressions; and short-circuit evaluation of Boolean expressions - "Strength reductions" (such as a shift left rather than multiply by 2); and elimination of common sub-expressions within the same block - Machine code optimizations; elimination of superfluous branches; re-use of duplicate code; removal of unreachable code - Byte comparisons (rather than 20-bit address calculations) for pointer variables; optimization of based-variable operations Compiler Controls . Including several that have been mentioned, the PLIM 86 compiler offers more than 25 controls that facilitate such features as: - Conditional compilation - Including additional PLIM source files from disk - Corresponding assembly language code in the listing file - Setting overflow conditions for run-time handling Segmentation Control Error Checking The PLIM 86 compiler takes full advantage of program addressing with the SMALL, COMPACT, MEDIUM, and LARGE segmentation controls. Programs with less than 64KB total code space can exploit the most efficient memory addressing schemes, which lowers total memory requirements. Larger programs can exploit the flexibility of extended one-megabyte addressing. The PLIM 86 compiler has a very powerful feature to speed up compilations. If a syntax or program error is detected, the compiler will skip the code generation and optimization passes. This usually yields a 2X performance increase for compilation of programs with errors. A fully detailed set of programming and compilation errors is provided by the compiler. Code Optimization The PLIM 86 compiler offers four levels of optimization for significantly reducing overall program size. MOO. ;. Beginning of module 0/ KEYINDEX)C£U~ISl:-~ SORTPROC PROCEDURE (PTA. COUNT. RECSIZE DECLARE PTR POINTER. (COUNT RECSIZE. KEYINDEX) INTEGER r Parameters PTA IS pOinter to first record COUNT IS number of records to be sorted RECSIZE IS number of bytes In each record-max IS 128 KEYINDEX 15 byte position within each record of a BYTE scalar to be used as sort key ~----_~ __ DECLARE CBECOfiD BASED PT~(11 BYTE CURRENT (1281 BYTE (I J) INTEGER. SORT FIND DO J Based Variables allow manipulation of external data by passing the base of the data structure (a pOinter) ThiS minimizes the STACK space used for parameter paSSing and the execution time to perform many STACK operations 1 TO COUNT·1 CALL MOVB(@RECORD(J'RECSIZEI (@CURREN"C( RECSIZEI I J ' DO WHILE I 0 AND RECORD((I 1)"RECSIZE KEYINDEXI CURRENT(KEYINDEXI CALL MOVB(@RECORD((I 11'RECSIZEI @RECORD(I'RECSIZEI RECSIZEI I I i The AT operator returns the address of a vanable. Instead of Its contents ThiS IS very useful III passing pOinters for based variables 1 END FIND CALL~(@CURRENT @RECORD(I'RECSIZEI RECSIZEI END SORT . ____ "_____ .___ . ____ __ _ _ END SORTPROC END M One of several PL M bUilt-In procedures for SIring manipulation 'End of module' Figure 3_ Sample PUM 86 Program_ 3-55 AFN-01661C inter PL/M 86/88/186 'SOFTWARE PACKAGE BENEFITS Lower Development Cost PLiM 86 is designed to be an efficient, cost-effective solution to th~ special requirements of iAPX 86 Mlcrosystem Software Development, as illustrated by the following benefits Of PLiM use: Increases In progrtlmmer. productivity translate immediately into lower software development costs because fewer programming resources are required for a given prog,rammed func~ion. Increased Reliability Cost· Effective Alternative to Assembly Language PLiM 86 Is designed to aid In the development of reliable software (PL/M 86 programs are simple statements of the program algorithm). This substantially reduces the risk of costly correction of errors in systems that have already reached full production status, as the more simply state~ the program is, the more likely it is to perform its intended function. PLiM 86 programs are code efficient. PL/M 86 combines all of the benefits of a high-level language (ease of use, high productivity) with the ability to access the 'IAPX 86 architecture. Conse· quently, for the development of systems software, PLiM 86 is the cost· effective alternative to assembly language programming. Easler Enhancements and Maintenance , Low Learning Effort PL/M is easy to learn and to use, even for the novice programmer. Programs written in PLiM tend to be selfdocumenting, thus easier to read and understand. This means it is easier to enhance and maintain PLiM programs as the system capabilities expand and future products are developed. Earlier Project Completion Critical projects are completed much earlier than otherwise possible because PLiM 86, a structured high-level language, increases programmer productivity. SPECIFICATIONS Documentation Package Operating Environment PLlM·B6 User's -Guide for B086-based Development Systems (121636) REQUIRED HARDWARE: Intel Microcomputer Development Systems (Series , III/Series IV) SUPPORT: Hotline Telephone Support, Software Performance Reporting (SPR), Software Updates, Technical Reports, Monthly Newsletter available. ORDERING INFORMATION Requires Software License Part Number MDS-313* ·MOS IS an ordering code only and is not used as a product name or trademark MOS' is a registered trademark of Mohawk Data Sciences Corporation Description PL/M 86 Software Package 3-56 AFN-Ol661C iC-86 C COMPILER FOR THE 8086 • Implements full C Language • Produces high density code rivaling assembler • Supports Intel Object Module Format (OMF) • Supports both small and large models of computation • Supports PSCOPE-86 and 121CETM • Supports IEEE Floating Point Math with 8087 coprocessor • Supports Bit Fields • Supports full standard I/O Library (STDIO) • Written in C • Runs under the Intel UDI on Intel Development Systems and iRMXTM 86 • Available for the VAX/VMS· Operating System The C Programming Language was originally designed in 1972 and has become increasingly popular as a systems development language. C is not a "very high level" language and is not tied to any specific application area. Although it is used for writing operating systems, it has been used equally well to write numerical, textprocessing and data base programs. C combines the flexibility and programming speed of a higher level language with the efficiency and control of assembly language. Intel iC-86 brings the full power of the C programming language to 8086 and 8088 based microprocessor systems. Intel iC-a6 supports the full C language as described in the Kernighan and Ritchie book, "The C Programming Lanugage," (Prentice-Hall, 1978). Also included are the latest enhancements to the C language: structure assignments, functions taking structure arguments and returning structures, and the "void" and "enum" data types. C is rapidly becoming the standard microprocessor system implementation language because it provides: 1. the ability to manipulate the fundamental objects of the machine (including machine addresses) as easily as assembly language. 2. the power and speed of a structured language supporting a large number of data types, storage classes, expressions and statements, 3. processor independence (most programs developed for other processors can be easily transported to the 8086), and 4. code that rivals assembly language in efficiency INTEL iC-86 COMPILER DESCRIPTION The iC-86 compiler operates in four phases: preprocessor, parser, code generator, and optimizer. The preprocessor phase interprets directives in C source code, including conditional compilations (# define). The parser phase converts the C program into an intermediate free form and does all syntaC1ic and semantic error checking. The code generator phase converts the parser's output into an efficient intermediate binary code, performs constant folding, and features an extremely efficient register allocator, ensuring high quality code. The optimizer phase converts the output of the code generator into Intel Corporation Assumes No Responsibility for the Use of Any CirCUitry Other Than Circuitry Embodied in an Intel Product No Other CirCUit Patent licenses are Implied Information Contained Herein Supercedes Previously Published SpeCifications of These Devices from Intel ·VAX IS a trademark of Digital EqUipment Corporation JUNE 1984 ©INTEL CORPORATION, 1983 3-57 intel' iC·86 C COMPILER FOR THE 8086 relocatable Intel Object Module Format (OMF) code, without creating an intermediate assembly file. Optionally, the iC-86 compiler can produce a symbolic assembly like file. The iC-86 optimizer eliminates common code, eliminates redundant loads and stores, and resolves span dependencies (shortens branches) within a program. The iC-86 runtime library consists of a number of functions which the C programmer can call. The runtime system includes the standard I/O libr.ary (STDIO), conversion routines, routines for manipulating strings, special routines to perform functions not available on the 8086 (32-bit arithmetic and emulated floating point), and (where appropriate) routines for interfacing with the operating system. iC-86 uses Intel's linker and locator and generates debug records for symbols and lines on request, permitting access to Intel's PSCOPE AND 12 1CETM to aid in program testing. FEATURES Support for Small and Large Models Intel iC-86 supports both the SMALL and LARGE modes of segmentation. A SMALL model program can have up to 64K bytes of code and 64K bytes of data, with all pOinters occupying two bytes. Because two byte pointers permit the generation of highly compact and efficient code., this model is. recommended for programs that can meet the size restrictions. The LARGE segmentation model is used by programs that require access to the full addressing space of the 8086/8088 processors. In this model, each source file generates a distinct pair of code and data segments of up to 64K bytes in length. All pointers are four bytes long. ments from arrays, and extract fields from structures or unions Arithmetic operators: add, subtract, multiply, divide, modulus Relational operators: greater than, greater than or equal, less than, less than or equal, not equal Unary operators: indirect through a pOinter, compute' an address, logical negation, ones complement, provide the size in bytes of an operand. Logical operators: AND, OR Bitwise operators: AND, exclusive OR, inclusive OR, bitwise complement Preprocessor Directives Data Types and Storage Classes #define-defines a macro Data in C is described by its type and storage class. The type determines its representation and use, and the storage class determines its lifetime, scope, and storage allocation. The following data types are fully supported by iC-86. #include- includes code outside of the program source file #if-conditionally includes or excludes code Other preprocessor directives include #undef, #ifdef, #ifndef, #else, #endif, and #Iine. char an 8 bit signed integer Statements int a 16 bit signed integer The C language supports a variety of statements: short same as int (on the 8086) Conditionals: IF, IF-ELSE Loops. WHILE, DO-WHILE, FOR long a 32 bit signed integer Selection of cases: SWITCH, CASE, DEFAULT unsigned a modifier for integer data types (char, int, short, . and long) which doubles the positive . range of vail,Jes Exit from a function: RETURN Loop control: CONTINUE, BREAK Branching: GOTO float a 32.blt f,ioating point number which utilizes the 8087 or a software floating pOint library Expressions and Operators The C language includes a rich set of expressions and operators. double a 64 bit floating point nur:nber Primary expression: invoke functions, select ele· 3-58 AFN-00144C inter IC-86 C COMPILER FOR THE 8086 void a special type that cannot be used as an operand in expressions; normally used for functions called only for effect (to prevent their use in contexts where a value is required). extern a variable defined outside of the function where it is declared; retaining its value throughout the entire program and accessible to other modules enum an enumerated data type auto a local variable, created when a block of code is entered and discarded when the block is existed These fundamental data types may be used to create other data types including: arrays, functions, structures, pOinters, and unions. static a local variable that retains its value until the termination of the entire program The storage classes availabe in iC-86 include: register suggests that a variable be kept in a machine register, often enhancing code density and speed typedef defines a new data type name from existing data types BENEFITS Faster Compilation Rapid Program Development Intel iC-86 compiles C programs substantially faster than standard C compilers because it produces Intel OMF code directly, eliminating the traditional intermediate process of generating an assembly file. Intel iC-86 provides the programmer with detailed error messages and access to PSCOPE-86 and 12 1CETM to speed program development. Portability of Code Full Manipulation of the 8086 Because Intel iC-86 supports the STDIO and produces Intel OMF code, programs developed on a variety of machines can easily be transported to the 8086. Intel iC-86 enables the programmer to utilize features of the C language to control bit fields, pointers, addresses and register allocation, taking full advantage of the fundamental concepts of the 8086. SPECIFICATIONS Operating Environment The iC-86 compiler runs host resident on both the Intel Series III Microcomputer Developrnent System under ISIS-II and on the System 86/330 under the iRMXTM 86 operating system. iC-86 can also run as a cross compliler on a VAX 11/780 computer under the VMS operating system 128 KBytes of User Memory is required on all versions. Specify desired version when ordering. -Dual Diskette Drives, Single or Double Density -System Console; CRT or Hardcopy Interactive Device iRMX 86 version: -Any iAPX 86/88, iSBC® 86/88, iTPS 86/XXX, or SYS 86/3XX based system capable of running the iRMX 86 Operating System Required Hardware Development System Version VAX version: -Intellec® Microcomputer Development System; Series III or Series IV -Digital Equipment Corporation VAX 11/780 or compatible computer 3-59 AFN·OO144C " .,"' :', ic-86 C COMPILER FOR THE. 8086 Optional Hardware iRMX 86 version: ISIS· II version: -ICE-86, 121CE-86 -None iRMX 86 version: -MOS··384 Kit-Mainframe Link for distributed development, or iMOX-394 Asynchronous Communications Link. VAX version: - Numeric Data Processors for support of the REALMATH standard -VAX iAPX 86/88/186 MACRO utilities package (iMDX-341VX) Assembler and VAX version: -None Documentation Package Required Software The C Programming Language by Kernighan and Ritchie (1978 Prentice-Hall) iC-86 User Manual ISIS· II version: -ISIS·II Diskette Operating System -Series III or Series IV Operating System Shipping Media iRMX 86 version: Development System Version: -iRMX 86 Realtime Multiprogramming Operating System -Two single and one double density ISIS-II format , 8" diskettes, one 5 1/4" Series IV Format -iRMX 860 Utilities Package iRMX 86 version: VAX version: - Double Density iRMX 86 format 8" diskette -VMS Operating System -Double Density iRMX 86 format 5%" diskette VAX version: Optional Software -1600 bpi, 9 track Magnetic tape Development System Version: -None ORDERING INFORMATION Order Code iMbx-317 iRMX-866 IMDX-347 SUPPORT Intel offers several levels of support for this proCluct which are explained in detail in the price list. Please consult the price list for a description of the support options available. Description iC-86 Compiler for ISIS-II iC-86 Compiler for iRMX 86 iC-86 Cross Compiler for VAX/VMS Intel Software license required *MDS is an ordering code only and is not used as a product name or trademark. MDS is a registered trademark of Mohawk Data Sciences Corporation. 3-60 AFN'()()l44C 8087 SUPPORT LIBRARY • Full 8087 Software Emulator for soft· ware debugging without the 8087 component • Library to support floating point arithmetic in PUM·86 and ASM·86 • Common elementary function library provides trigonometric, logarithmic and other useful functions • Accurate, verified and efficient Imple· mentation of algorithms for functions • Decimal conversion module supports binary.decimal conversions • Supports proposed IEEE Floating Point Standard for high accuracy and software portability • Error·handler module simplifies· floating point error recovery The 8087 Support Library provides PLlM-86 and ASM-86 users with the equivalent numeric data proceSSing capability of Fortran-86. With the Library, it is easy for PLlM-86 and ASM-86 programs to do floating point arithmetic. Programs can link in modules to do trigonometric, logarithmic and other numeric functions, and the user is guaranteed accurate, reliable results for all appropriate inputs. The 8087 Support Library implements Intel's REALMATH standard and also supports the proposed IEEE Floating Point Standard. Consequently, by using this Library, the PUM-86 user not only saves software development time, but is guaranteed that the numeric software meets industry standards and is portable-his software investment is maintained. The 8087 Support Library consists of the common elementary function library, the decimal conversion module, the error handler module, the full 8087 Software emulator and interface libraries to the 8087 and to the 8087 emulator. B PLM APLM PROCEDUIIE rTHETA REAL EXHRNAI DECLARE THETA ilEAL ENDmqerTNN mq~,TNN OUTPUT VALUE mqerTNNf!NPUT Nuw w.lh ,h. 'e" Inp"' OUTPUT I----f PLM·86 "'---1 I----f AsM·86 I----t VALUE VALU,,, .h"", 0';5]12801 DAsM CAsM EXTRN m<,~,TNH I-------t FAR LlNK86 LINKED USER OBJECT MODULE "",,1'[1'1 ,IUN', HfAI 'All ",,",HIH t\TPf,IT11'11l VAI"t I MAY 1983 INTEL CORPORATION 1983 ORDER NUMBER :121653-001 3-61 8087 SUPPORT LIBRARY CEl87.LI·B· THE COMMON ELEMENTARY FUNCTION LIBRARY..... CElS7.lIB contains commonly used floating point functions. It is used along with the'SOS7 numeric ·copr.ocessor or the S087 emulator and it provides a complete package of elementary functions, giving valid results for all appropriate inputs. This library provides PUM-S6 and ASM-86 users all the math functions supported intrinsically by the Fortran-86. Following is a summary of CElS7 functions, grouped by functionality. Rounding and Truncation Functions: mqerlEX, mqerlE2, and mqerlE4 round a real number to the nearest integer; to the even integer if there Is a tie. The answer returned is real, a 16-bit integer or a 32-bit integer respectively. mqerlAX: mqerlA2, mqerlA4 round a real number to the nearest integer, to the integer away from zero if there is a tie; the answer returned is real, a 16-bit integer or a 32-bit integer, respectively. mqerlCX, mqerlC2, mqerlC4 truncate the fractional part of a real input; the answer is real, a 16·bit Integer or a 32-bit integer, respectively . .logarlthmlc and Exponential Functions: mqerlGD computes decimal (base 10) logarithms, mqerlGE computes natural (base e) logarithms. mqerEXP computes exponentials to the base e. mqerY2X computes exponentjals to any base. mqerYI2 raises an input real to a 16-bit integp.r power. mqerYI4 is as mqerYl2, except to a 32-bit integer power. mqerYIS is as mqerYI2, but it accommodates PUM·S6 users. Trigonometric and Hyperbolic Functions: mqerSIN, mqerCOS, mqerTAN compute sine, cosine, and tangent. mqerASN, mqerACS, mqerATN compute the .corresponding inverse functions. mqerSNH, mqerCSH, mqerTNH compute the corresponding hyperbolic functions. mqerAT2 IS a special version of the arc tangent function that accepts rectangular coordinate inputs. Other Functions: mqerDIM is FORTRAN's positive difference function. mqerMAX returns the maximum of two real inputs. mqerMIN returns the minimum of two real inputs. mqerSGH combines the· sign of one input with the magnitude of the other input. mqerMOD computes a modulus, retaining the sign of the dividend. mqerRMD computes a modulus, giving the value closest to zero. DCON87.LIB THE DECIMAL CONVERSION LIBRARY DCONS7.lIB is a library of procedures which convert binary representations of floating point numbers and ASCIIencoded string of digits. The binary-to-decimal procedure mqcBIN DEClOW accepts a binary number In any of the formats used for the representation of floating point numbers in the S087. Because there are so many output formats for floating point numbers, mqcBIN_DEClOW does not attempt to provide a finished, formatted text string. Instead, It provides the "building blocks" for you to use to construct the output string which meets your exact format speCification. 3.:a2 AFN-020638 8087 SUPPORT LIBRARY The decimal-to-binary procedure mqcDEC_BIN accepts a text string which consists of a decimal number with optional sign, decimal point, and/or power-of-ten exponent. It translates the string into the caller's choice of binary formats. Decimal-to-binary procedure.mqcDECLOW_BIN is provided for callers who have already broken the decimal number into its constituent parts. The procedures mqcLONG_ TEMP, mqcSHORT_TEMP, mqcTEMP_LONG, and mqcTEMP_SHORT convert floating point numbers between the longest binary format, TEMP_REAL, and the shorter formats. EH87.LlB THE ERROR HANDLER MODULE EH87.LlB is a library of five utility procedures which a user can utilize for writing trap hal1dlers. Trap handlers are called when an unmasked 8087 error occurs. The 8087 error reporting mechanism can be used not only to report error conditions, but also to let software implement IEEE standard options not directly supported by the Chip. The three such extensions to the 8087 are: normalizing mode, non-trapping not-a-number (NaN), and non-ordered comparison. The utility procedures support these extra features. DECODE is called near the beginning of the trap handler. It preserves the complete state of the 8087, and also identifies what function called the trap handler, and returns available arguments and/or results. DECODE eliminates much of the effort needed to determine what error caused the trap handler to be called. NORMAL provides the "normalizing mode" capability for handling the "0" exception. By calling NORMAL in your trap handler, you eliminate the need to write code in your application program which tests tor non-normal inputs. SIEVE provides two capabilities for handling the "I" exception. It implements non-trapping NaN's and non-ordered comparisons. These two IEEE standard features are· useful for diagnostic work. ENCODE is called near the end of the trap handler. II restores the state of the 8087 saved by DECODE, and performs a choice of concluding actions, by either retrying the offending function or returning a specified result. FILTER calls each of the above four procedures. If your error handler does nothing more than detect fatal errors and implement the features supported by SIEVE and NORMAL, then your interface to EH87.LlB can be accomplished with a single call to FILTEA. E8087 THE FULL 8087 EMULATOR E8087 is an object module that functionally emulates the 8087 coprocessor chip. It is ideal for use during prototyping and debugging floating point progranls. However, the target system should use the 8087 component because it exe· cutes 1000 times faster and uses significantly less memory. 3-63 AFN 020638 8087 SUPPORT LIBRARY E8087.LIB,8087.LlB,87NULL.LlB INTERFACE LIBRARIES E8087. LIB, 8087.LlB and 87NULL. LIB libraries configure a user's application program for his run-time environment: running with the emulator, with the 8087 component or without floating point arithmetic, respectively. SPECIFICATIONS TARGET ENVIRONMENT Required Software 8086/8088 Based Microcomputer System For Series II: 8086/8088 Software Development Package DEVELOPMENT ENVIRONMENT Required Hardware Documentation Package All Intel Microcomputer Development Systems (Series II, Senes III/Series IV) Numeric Support Library Manual • Recommended ORDERING INFORMATION Part Number Description MDS*-319 8087 Support Library Requires Software License SUPPORT Intel offers several levels of support for this product which are explained in detail in the price list. Please consult the price list for a description of the support options available. *MDS is an ordering code only and is not used as a product name or trademark. MDS is a registered trademark of Mohawk Data Sciences Corporation. 3-64 AFN-020638 8087 SOFTWARE SUPPORT PACKAGE • Program Generation for the 8087 Numeric Data Processor on 8080/8085 Based Intel Microcomputer Development Systems • 8087 Emulator Duplicates Each 8087 Floating-Point Instruction in Software, for Evaluation of Prototyping, or for Use in an End Product • Consists of: 8086/8087/8088 Macro Assembler, 8087 Software Emulator • Macro Assembler Generates Code for 8087 Processor or Emulator, While Also Supporting the 8086/8088 Instruction Set • Macro Assembler and 8087 Emulator are Fully Compatible with Other 8086/8088 Development Software • Implementation of the IEEE Proposed Floating-Point Standard (the Intel® Realmath Standard) The 8087 Software Support Package is an optional extention of Intel's 8086/8088 Software Development Package. The 8087 Software Support Package consists of the 808618087/8088 Macro Assembler, and the Full 8087 Emulator. The assembler is a functional superset of the 8086/8088 Macro Assembler, and includes instructions for over sixty new floating-point operations, plus new data types supported by the BOB7. The B087 Emulator is an 8OB6/80B8 object module that simulates the environment of the 80B7, and executes each floating-point operation using software algorithms. This emulator functionally duplicates the operation of the B087 Numeric Data Processor. Also included in this package are interface libraries tQ link with 80B6/8087/80B8 object modules, which are used for specifying whether the 8087 Processor or the 8087 Emulator is to be used. This enables the run-time environment to be invisible to the programmer at assembly time. The follOWing are trademarks of Intel CorporatIon and may be used only to IdentIfy Intel products expo CREDIT, Intellee, Multlbus, I, ,SSC, Multlmodule, ICE. ,sax, PROMPT, tRMX, leS, Library Manager. Promware, Inslte, t-1eS, RMX, Intel, Megachassls, UPI, InteleVISlon, Mlcromap, J,LScope and the combmatlon of ICE, leS, ISse, ,sex, MeS, or RMX and a numerical suffix ©INTEL CORPORATION, 1983 SEPTEMBER 1984 3-65 ORDER NUMBER:4042150·002 8087 SOFTWARE SUPPORT PACKAGE FUNCTIONAL DESC~IPTION floating-point instructions, the macro assembler also'introduces two new SOS7 data types: aWORD (S bytes) and TSYTE (ten bytes). These support the highest precision of data processed by the SOS7. " 8086/8087/8088 Macro Assembler The SOS6/S0S7/80SS Macro Assembler translates symbolic macro assembly langu,age instructio'ns into appropriate mach.ine instructions. It is an extended version of the SOS6/S0SS.Macro Assembler, and therefore supports all of the same features and functions, such as limited type checking, conditional assembly, data structures, macros, etc. The extensions are, the nevy instructions and data types to support floating-point operations. Realmath floating-point instructions (see Table 1) generate code capable of being converted to either SOS7 instructions or interrupts for the SOS7 Emulator. The Processor/Emulator selection is made via interface libraries at LINK-time. In addition to the new Full 8087 Emulator The Full SOS7 Emulator is a 16-kilobyte object module that is linked to the application program for floating-point operations. Its functionality is identical to the SOS7 chip, and is ideal for prototyping and debugging floating-point applications. The Emulator is an alternative to the use of the SOS7 chip, although the latter executes floating-point applications up to 100 times faster than an SOS6 with the SOS7 Emulator. Furthermore, since the SOS7 is a "co-processor," use of the chip will allow many operations to be performed in parallel with the SOS6. Table 1. 80S7 Instructions Arithmetic Instructions Processor Control Instructions 1 - - - - - - - - Addition FADD Add real FADDP Add real and pop FIADD integer add 1----------Subtraction FSUB FSUBP FISUB FSUBR FSUBRP FISUBR Subtract real Subtract real and pop Integer subtract Subtract real reversed Subtract real reversed and pop Integer subtract reversed Multiplication FMUL FMULP FIMUL Multiply real Multiply real and pop Integer multiply Division I----------r---------~~~I FDIV FDIVP FIDIV FDIVR FDIVRP FIDIVR Dlvlde.. real Divide real and pop Integer .dlvlde Divide real reversed DIvide real reversed and' pop Integer qlvlde .reversed FINIT/FNINIT Initialize processor FDISI/FNDISI Disable Interrupts FENI/FNENI Enable Interrupts FLDCW Load control word FSTCW/FNSTCW Store control word FSTSW/FNSTSW Store status word FCLEX!FNCLEX Clear exceptions FSTENV!FNSTENV Store environment FLDENV Load environment FSAVE!FNSAVE Save state FRSTOR Restore state FINCSTP Increment stack pOinter FDECSTP Decrement stack pOinter FFREE Free register FNOP No operation FWAIT CPU walt Comparison Instructions I FCOM Compare real f----:F::::S---:O:-:R:-:T=-----O-th-,er °sPerations quare root FSCALE Scale FPREM Partial remainder FRNDINT Round to Integer FXTRACT Extract exponent and slgnlflcand FCOMP Compare real and pop FCOMPP Compare real and pop tWice FICOM Integer compare 1_ ~~~~______ _~_~_~~_I~_!~_~g_a~_u_e _ _ _ __ 3-66 FICOMP Integer compare and pop FTST Test FXAM Examine _ AFN·01574C intel 8087 SOFTWARE SUPPORT PACKAGE Table 1. 8087 Instructions (cont'd) Data Transfer Instructions Transcendental Instructions FPTAN Partial tangent FPATAN Partial arctangent F2XM1 2'-1 FYL2X Y.log,X FYL2XP1 Y.log,(X+1) Real Transfers FLD FST FSTP FXCH Integer Transfers FILD FIST FISTP Constant Instructions FLDZ Load ~ 00 FLD1 Load ~ 10 FLDPI Load TT FLDL2T Load log,10 FLDL2E Load log,e FLDLG2 Load log ,,2 FLDLN2 Load 109,2 Load real Store real Store real and pop Exchange registers Integer load Integer store Integer store and pop Packed Decimal Transfers FBLD FBSTP . Packed decimal (BCD) load Packed decimal (BCD) store and pop SPECIFICATIONS Documentation Package Operating Environment 8086/8087/8088 Macro Assembly Language Reference Manual for 8080/8085-Based Development Systems REQUIRED HARDWARE Intel Microcomputer Development Systems -Series II -Personal Development System -Series IV 8086/8087/8088 Macro Assembler Operating Instructions for 8080/80B5-Based Development Systems The 8086 Family Users Manual Supplement for the 8087 Numeric Data Processor REQUIRED SOFTWARE 8086/8088 Software Development Package ORDERING INFORMATION Part Number Description MDS*-387 8087 Software Support Package Requires Software License SUPPORT Intel offers several levels of support for this product which are explained in detail in the price list. Please consult the price list for a description of the support options available. *MDS IS an ordering code only and is not used as a product name or trademark. MDS IS a registered trademark of Mohawk Data Sciences Corporation. 3-67 AFN·01574C inter 8089 lOP SOFTWARE SUPPORT PACKAGE #407200 Program Generation for the 8089 I/O • Processor on the Intellec® 8089-Based Addressing • Supports Modes with a Structure Facility that Enables Easy Access to Based Data Microcomputer Development System 8089 Macro Assembler, plus • Contains Relocation and Linkage Utilities Relocatable Object Module • Compatible with All iAPX 86 and iAPX 88 Object Modules Fully Supports Symbolic Debugging • with the RBF-89 Software Debugger • Powerful Macro Capabilities Provides Timing Information in • Assembly Listing • Fully Detailed Set of Error Messages The lOP Software Support Package extends Intellec Microcomputer Development System support to the 8089 I/O Processor. The macro assembler translates symbolic 8089 macro assembly language instructions into relocatable machine code. The relocation and linkage utilities provide compatibility with iAPX 86, iAPX 88, and 8089 modules, and make structured, modular programming easier. The macro assembler also provides symbolic debugging capability when used with the RBF-89 software debugger. 8089 program modularity is supported with inter-segment jumps and calls. The macro assembler also provides instruction cycle counts in the listing file, for giving the programmer execution timing information. The programs in the 8089 Software Support Package run on any Intellec Series 1\ or Model 800 with 64K bytes of memory. The following are trad~marks of Intel Corporatton and may'be used only to Identlfy'lntel products exp, CREDIT, InteUee, MUltlbus, t, ,sec. Multlmodule, ICE,.SeX, PROMPT, iC$.
,RMX, Library Manager, Promware.lnslte. MeS, RMX, Intel, Megachassls. UPI, Intelevlslon, Mlcromap, p.$cope and the combination of ICE, ,sse,.sex, MeS, orRMX and a numerical suffix MAY 1983 © INTE, CORPORATION 1983 ORDER NUMBER:210853-002 3-68 intJ 8089 lOP SOFTWARE SUPPORT PACKAGE Table 1. Sample Program Listing 1::l1S-11 oe 'ET ~i1i1j PlACRO ""'Ellill.[F' M~~E"8L~ KlS5 OF !lOClUl£ aSK 'tllDULE PLACE! PI t! TAH OBJ IHVOKE!.I 9'1': Ol, .. ~q tl:tQ!J~ 11.99 g.n 1I00Cl"'0 d.bug pog,",dlh(132) pl"',nt{:fl:toskll A::~E:'t8!.ER OBJECT CODE IH[ "HC llHE SOURCE !lGr'" 9 TIIS'- Baal TASK !"~qfl_ent In t ... ! ,rst po.rt or th,S SQllp\I 1'1'0.9".0" do.lo. " lIovtd rrOIl 8Bal:> s~n .... RAil to. .. ,,,,or-v 100co.I to. th. '189 lOP In th • • • cond purt, th. dolo. IS IIQvtd fro.I'I th. 100clll tU"o,.", to Q do.to "ort. II. Iso, nth. 8889 110 spoc • ..,"", ., ':8" 15 16 cOI'I"'''''Idtlport@8251 BclJet h 112 •• \;' 92118h CIII 1st) •• dQtQ~port'82S1 buf(t"~~8889 19 t"xtrf'l 28 extr" equ equ equ IIclll8h ; 8251 01' on 81.' 10co.l bu. i 82' 1 tP on 88.' loco. t bu. ,RAt! burt ... ,n .18a, 110 .po.c. .".t." bl,lt ferlHille, IRA" bu"." In .186 • "."or.., , 1 oco.t. on of the buff.,. count. ':I 2. 22 l.+def,". (IIo.cro_l) 23 ( gil, bl,lrf.,.UlI89 1 pd, gc, '" bc,[gc) "ovb " "", 27 I.• d.t',". 28 .... ........ IU8 '"' I"t 1111 lUI ' I I• .18Z ."2 ........ 1112 1.,1 •• CD 1116 IIlI 8118 2838 IIU 41le IIle 4'.' .'IF •• 23 1111 I.CI till I!CI lilt 1112 .127 1118 lUI 'III ........ 6182 lin Ill' ,"1 2138 41lC UlE 4848 F2 "1 1I4' " 7. , .. ...... " ." ." .85 ." '" 2. , .54 236 t?3 '" Ht. '" '" '" ,,, '88 '" ". , 227 '48 8Il~ !!II 77 38'· 8UC eBB " " I.IA FD lice ,. " "J5 "" ,."" "" """ " "" 38 ." F3 I 2'3 n. '" 377 3" .... ., .,..., .. ., . .. ..,, .f~i' 5" 562 ., ("o.c .. o_2{ po.,.o.II_I, ,o.ro.,,_2» 10c,,\ loop Inc,..".nt ,otnt.,. Into .0U,.C. ,"C %PI1"o." 1 d.c %po.,.0.,,:2 O.c,..".nt byte count Jnz %po.ro.,,_2,%100p Loop bo.ck ,f b\jt. count> • ONE: 1'1011, I pd, "o..,b lit' th go.,buffe,.~e88' Loo.d ".9; .t.,. GA 0' e18' buff.,. gb,bl,lff.,.i81., 9c,." bc, (;c 1 "0'01'. bl,l"." o.ddr ••• ,nto CI Loo.d po,nt.r to count ,nto Cit "ov. bvtt count • nto Ie 33 .dd,. ••• 38 Nove b..,tt f,.o" 81., to •••• buU'.,. loop": "ovil [;b],[90.) ,nc go. Inc,..".nt po Int.,. ,nto ••• , bu"." %ftllc,.0_2< gb, 9c) %PARA"_1 ) Inc,..".",t po,nt.,. ,nto .ourc. I:PARA"_2 , O.c,..".nt byte cou"t J 1'1% %PAPA"_2 gc,UDDP LOOPS! ; Loop bOock • f bvt. count> I ,b 5. 5. rwo "" ;'''(lcro I I pd, rlQvb 54 ...'" , , Ito..,. buff.,. .dd,. ••• ,nt.o CI Loo.d po,nt.,. to count Into Ct "0'01'. b..,t.. count , .. to Ie "" ","" , "" "" "" .. go., d~ t 0.9 po ,.t •• 251 go., co ''''11 nd'.,.o,.t .82 51 lood eA 1/, th Ooddr . . . of' 8251 OP 1000d ce v, th o.dd,. ••• of' 8251 ep 9 b ,bu(f.,.1lI888" 9c, y b<:, r {lC l "ov. buf'." add,. •••• nto 1:1 po.nt.r to count ,nto CiC "ov. bvt. count .nto Ie \o?p81 )nbt [gc]'B.loopBt "Qllb [gil J, (gb 1 ""lJcro_2( gb 9C 1 loop unt, I aO!:J1 t,._n.".t r.o.Clllv "."lIg. I "to buff.,. l,Pj:jRj:j" _I Incr""'ent po,nt.r .nto gb ',PHRi4f't 9<: ) nz 9c _~ (I!l'cre-",.nt byt. count ·.PARAtI_2 :~ LO J P LOOf.BI h. Loop bOock, f byt. count) I t 3-69 AFN-008408C 8089 lOP SOFTWARE SUPPORT PACKAGE FUNCTIONAL DESCRIPTION The lOP Software Support Package contains: ASM89 -The 8089 Macro Assembler. lINK86 - Resolves control transfer references between 8089 object modules, and data references In 8086, 8088, and 8089 modules. LOC86 -Assigns absolute memory addresses to 8089 object modules. OH86 -Converts absolute object modules to hexadecimal format. UPM - The Universal PROM Mapper, which supports PROM programming In all iAPX 86/11 and IAPX 88/11 applications. ASM89 translates symbolic 8089 macro assembly language instructions Into the appropriate machine codes. The ability to refer to both program and data addresses with symbolic names makes It easier to develop and modify programs, and avoids the errors of hand translation. so that arw changes to that sequence need to be made in only one place in the program. Common code sequences that differ only slightly can also be referred to with a macro call, and the differences can be substituted with macro parameters. ASM89 provides symbolic debugging information in. the object file. The RBF-89 debugger makes use of this information, so the programmer can symbolically debug 8089 programs. ASM89 also provides cycle counts for each instruction in the assembly listing file (see Table 1). These cycle counts help the programmer determine how long a particular routine or code sequence will take to execute on the 8089. ASM89 provides relocatable object module compatibility with the 8086 and 8088 microprocessors. This object module compatibility, along with the 8086/8088 relocation and linkage utilities, facilitates the designing of iAPX 86/11 and iAPX 88/11 systems. The powerful macro facility allows frequently used code sequences to be referred to by a single name, ASM89 fully supports the based addressing modes of the 8089. A structure facility allows the, user to define a template that enables accessing of based data symbolically. SPECIFICATIONS Shipping Media Operating Environment -Single and Double Density Diskettes Intel Microcomputer Development Systems (Model 800, Series II, Senes III, Senes IV) ORDERING INFORMATION Support Hotline Telephone Support, Software Performance Report (SPR), Software Updates, Technical Reports, and Monthly Technical Newsletters are available. Part Number Description MDS*-312 8089 lOP Software Support Package Requires Software License Documentation Package 8089 Macro Assembler User's Guide (9800938) 8089 Macro Assembler Pocket Reference (9800936) MCS-86 Software Development Utilities Operating Instructions for 15/5-1/ Users (9800639) 'MDS IS an ordering code only and IS not used as a product name or trademark MDS® IS a registered trademark of Mohawk Data SCiences Corporation Universal PROM Programmer User's Manual (9800819) 3-70 AFN·008408C iAPX 286 SOFTWARE DEVELOPMENT PACKAGE • Complete System Development Capability for High-Performance iAPX 286 Applications. • Software Simulator for Execution and Symbolic Debugging on Intel Development System. • Allows creation of Multi-User, Virtual Memory, and Memory-Protected Systems. • Package Supports Program Development with PLlM-286, Pascal-286, and FORTRAN 286. • Macro Assembler for Machine-Level Programming. • System Utilities for Program Linkage and System Building. • Extends Existing Intellec(R) Development Systems to Provide Broad Support for the iAPX 286 Microprocessor. The iAPX 286 is a 16-bit microprocessor system with 32-bit virtual addressing, integrated memory protection, and instruction pipelining for high performance. The iAPX 286 Software Development Package is a cohesive set of software design aids for programming the iAPX 286 microprocessor system. The package enables system programmers to design protected, multi-user and multi-tasking operating system software, and enables application programmers to develop tasks to run on a protected operating system. The iAPX 286 Software Development package contains a macro assembler, a program binder (for linking separately compiled modules together), a system builder (for configuring protected multiple-task systems), and a software simulator (for execution and symbolic debugging). The memory protection features of the lAP X 286 architecture are invisible to applicatIOn programmers, who use language translators and the program binder System programmers, may use special memory protection features In ASM-286 or PUM 286, and use the system bUilder for InitialiZing and managing protection features. The Simulator duplicates the operation of the 80286 CPU, as well as the floating pOint operations of the 80287. All the utilities In the Software Development Package run on the Intel Microcomputer Development Systems (Series III/Senes IV) DEBUGGER ICE. MONITOR, etc APPLICATION SOFTWARE The iAPX 286 Software Development Package keeps the protection mechanism invisible to the application programmer, yet easy to configure for the system programmer. Intel Corporal/on Assumes No Responsibility for the Use of Any Circuitry Other Than Circuitry Embodied In an Intel Product. No Other Circuit Patent Licenses are Implied. Information Contained Herein Supercedes Previously Published Specifications of Thes's Devices JUNE 1984 from Intel. ©INTEL CORPORATION, 1983 3-71 ORDER NUMBER: 210585-001 iAPX 286 SOFTWARE DEVELOPMENT PACKAGE • Instruction Set and Assembler Mnemonics Are Upward Compatible with ASM-86/88. • Powerful and Flexible Text Macro Facility. • Type-Checking at Assembly Time Helps Reduce Errors at Run-Time. • Structures and RECORDS Provide Powerful Data Representatio~. • "High-Level" Assembler Mnemonics Simplify the ~anguage~ • SlJpports Full Instruction Set of the iAPX 286/20, Including Memory Protection and Numerics: ASM-286 is the "high-level" macro' assembler for the iAPX 286 assembly language. ASM-286 translates symbolic assembly language mnemonics into relocatable object code. The assembler mnemonics are a superset of ASM-86/88 mnemonics; new ones have also been'lldded to support the new iAPX 286 instructions. The segmentation directives have been greatly simplified. The iAPX 286 assembly language includes approximately 150 instruction mnemonics. From these few mnemonics the assembler can generate over 4,000 distinct machine instructions. Therefore, the software development task is simplified, as the programmer need know only 150 mnemonics to generate all possible machine instructions. ASM-286 will generate the shortest machine instruction possible (given explicit information as to the characteristics of any forward referenced symbols). The powerful macro facility in ASM-286 saves development and maintenance time by coding common program sequences only once. A macro substitution is made each time the sequence is to be used. This facility also allows for conditional assembly of certain program sequences. ASM-286 offers many features normally found only in high-level languages. The assembly language is strongly typed, which means it performs extensive checks on the usage of variables and labels. This means that many programming errors will be detected when the program is assembled, long before it is being debugged. ASM-286 object modules conform to a thorough, well-defined format used by all 286 high-level languages and, utilities. ThiS makes it easy to call (and be called from) HLL object modules. Key Benefit: For programmers who wish to use assembly language, ASM-286 provides many powerful "high-Ie'vel" capabilities that simplify program development and maintenance. 3-72 AFN-00378B intel iAPX 286 SOFTWARE DEVELOPMENT PACKAGE iAPX 286 BINDER • Links Separately Compiled Program Modules Into an Executable Task. • Makes the iAPX 286 Protection Mechanism Invisible to Application Programmers. • Works with PL/M-286, Pascal-286, FORTRAN-286 and ASM-286 Object Modules. • Performs Incremental Linking with Output of Binder and Builder. • Resolves PUBLIC/EXTERNAL Code and Data References, and Performs Intermodule Type-Checking. • Provides Print File Showing Segment Map, Errors and Warnings. • Assigns Virtual Addresses to Tasks in the 232 Address Space. • Generates Linkable or Loadable Module for Debugging. BND-286 is a utility that combines iAPX 286 object modules into executable tasks. In creating a task, the Binder resolves Public and External symbol references, combines segments, and performs address fix-ups on symbolic code and data. The Binder takes object modules written in ASM-286, PLlM-286, Pascal-286 or FORTRAN-286, and generates a loadable module (for execution or debugging), or a linkable module (to be re-input tothe Binder later; this is called incremental binding). The binder accepts library modules as well, linking only those modules required to resolve external references. BND-286 generates a print file displaying a segment map, and error messages. The Binder will be used by system programmers and application programmers. Since application programmers need to develop software independent of any system architecture, the 286 memory protection mechanism is "hidden" from users of the Binder. This allows application tasks to be fully debugged before becoming part of a protected system. (A protected system may be debugged, as well.) System protection features are specified later in the development cycle, using the 286 System Builder. It is possible to link operating system services required by a task using either the Binder or the Builder. This flexibility adds to the ease of use of the 286 utilities. Key Benefit: The Binder is the only utility an application programmer needs to develop and debug an individual task. Users of the Binder need not be concerned with the architecture of the target machine, making application program development for the 286 very simple. iAPX 286 MAPPER • Mapper Allows Users to Display: • Flexible Utility to Display Object File Information. Protection Information: SEGMENT TABLES GATE TABLES PUBLIC ADDRESSES • MAP-286 Selectively Purges Symbols from a Load Module. • Provides Inter-Module Cross-Referencing for Modules Written in All Languages. Debug Information: MODULE NAMES PROGRAM SYMBOLS LINE NUMBERS Key Benefit: A cross-reference map showing references between modules simplifies debugging; the map also lists and controls all symbolic information in one easy-to-read place. 3-73 AFN-0037B8 intel' iAPX 286 SOFTWARE DEVELOPMENT PACKAGE iAPX 286 LIBRARIAN • Fast, Easy Management of iAPX 286 Object Module Libraries. • Librarian Allows Users to: Create Libraries Add Modules Replace Modules Delete Modules Copy Modules from Another Library Save Library Module to Object File Create Backup Display Module Information (creation date, publics, segments) • Only Required Modules Are Linked, When Using the Binder or Builder. Key Benefit: Program libraries improve management of program modules, and reduce software administrative overhead, iAPX 286 SYSTEM BUILDER • Supports Complete Creation of Protected, Multi-task Systems. • Creates a Memory Image of a 286 System for Cold-start Execution. ill Target System may be Boot-Ioadable, • Resolves PUBLIC/EXTERNAL Definitions (between protection levels). Programmed into ROM, or Loaded From Mass-store. • Supports Memory Protection by Building System Tables, Initializing Tasks, and Assigning Protection Rights to Segments. • Generates Print File with Command Listing and System Map. BLO-286 is the utility that ,lets system programmers configure multi-tasking, protected systems from an operating system and discrete tasks. The Builder generates a cold-start execution module, suitable for ROMbased or disk-based systems. The Builder accepts Input modules from IAPX 286 translators or the IAPX 286 Binder. It also accepts a "Build File" containing definitions and Initial values for the 286 protection mechanism-descriptor tables, gates, segments, and tasks. BLD-286 generates a Loadable or bootloadable output module, as well as a print file with a detailed map of the memory-protected system. Using the Builder command Language, system programmers may perform the following functions: - Assign physical addresses to segments; also set segment access rights and limits. Create Call, Trap, and Interrupt "Gates" (entry-points) for inter-level program transfers. Make gates available to tasks; this is an easier way to define program interfaces than using interface libraries. Create Global (GOT), Interrupt (lOT), and any Local (LOT) Descriptor Tables. Create Task State Segments and Task Gates for multi-task applications. Resolve inter-module and inter-level references, and perform type-checking. Automatically select required modules from libraries. Configure the memory image into partitions In the address space. Selectively generate an object file and various sections of the print file. Key Benefit: Allows a system programmer to define the configuration of a protected system in one place, with one easy-touse Utility. This specification may then be adopted by all project members, using either the Builder or just the Binder. The flexibility simplifies program developmentfor all users. 3-74 AFN-00378B IAPX 286 SOFTWARE DEVELOPMENT PACKAGE iAPX 286 SIMULATOR • Supports Symbolic Debugging of Complete, Protected 286 Systems. • Executes Full Instruction Set, Including 80287 Numerics. • Allows 286 Program Execution and Debugging in Absence of iAPX 286 Hardware Execution Vehicle. • Symbolic Access to Program Variables as well as Descriptor Tables. • Functionally Duplicates the Operation of the IAPX 286 Microprocessor, Including Memory Protection. • Two Execution Timers for Program Benchmarking and Interrupt Simulation. • UDI File System Support for User Program. - SIM-286 is an 8086-resident program designed to support development of iAPX 286 O.S. kernels, systems, and applications. All of these may be developed and debugged without the use of a 286 hardware execution vehicle. The Simulator consists of a human interface layer, and software executors for the 80286 CPU and 80287 Numeric Data Processor. The human interface receives commands with symbolic names, and passes control to the executor as though it were a 286-resident monitor. SIM-286 lets designers manipulate a 286 program using the symbolic names given for code and data. It also lets users symbolically examine and modify the protection features (such as system tables, access rights, etc.), if it is desired. SIM-286 contains two instruction timers. One may be set and incremented during execution; this allows program sequences to be bench marked in clock cycles and microseconds. The second, an interval timer, may be set to generate interrupts every 'f/ clock cycles, to simulate event-driven processing. These timers are extremely useful for developing system kernels. For programs that make operating system calls for file 1/0, SIM-286 provides access to these services through the Universal Development Interface. Key Benefit: Symbolic system debugging (for protected 286 software) may be performed in the absence of a 286-based target. iAP.X 286 System Builder User's Guide iAPX 286 Simulator User's Guide PockefReference for all the above: ·ASM 286 Utilities SIM286 SPECIFICATIONS OPERATING ENVIRONMENT Intel Microcomputer Development Systems (Series III1Serles IV) DOCUMENTATION SUPPORT: ASM 286 Language Reference Manual ASM 286 Macro Assembler Operating Instructions iAPX 286 Utilities User's Guide Hotline Telephone Support, Software Performance Report (SPR), Software Updates, Technical Reports, and Monthly Technical Newsletters are available. ORDERING INFORMATION Product Code iMDX-321 Description iAPX 286 Software Development Package 3-75 AFN-IlO37BB intJ PL/M 286 SOFTWARE PACKAGE • Systems programming language for the protected virtual address mode iAPX286 • Producesrelocatab'e object code which is linkable toobject'modules generated by all other iAPX286 . language translators • Upward compatible with PL/M 86.and PL/M 80 assuring softwar.e portability • Multiple levels of optimization • Enhanced to support design of protected, multi-user, multi-tasking, virtual memory operating system software • Resident on Intel microcomputer development systems (Series III, IV)· ., Advanced, structured system implementation language for algorithm development PL/M 286 is a powerful, structured, high-level system implementation language for the development of system software for the protected virtual address mode iAPX 286. PL/M 286 has been enhanced to utilize iAPX 286 features-memory management and protection-for the implementation of multi-user, multi-tasking virtual memory operating systems. PL/M 286 is upward compatible with PL/M 86 and PL/M 80. Existing systems software can be re-compiled with PL/M 286 to execute in protected virtual address mode on the iAPX 286. PL/M 286 is the high-level alternative to assembly language programming on the iAPX 286. For the majority of iAPX 286 system programs, PL/M 286 provides the features needed to access and to control efficiently the underlying iAPX 286 hardware and consequently it is the cost-effective approach to develop reliable, maintainable system software. The PL/M 286 compiler has been designed to efficiently support all phases of software development. Features such as a built-in syntax checker, multiple levels of optimization, virtual symbol table and four models of program size and memory usage for efficient code generation prpvide the total program development support n~ded. . MAY 1983 ORDER NUMBER:210536-002 3-76 infel' PL/M 286 SOFTWARE PACKAGE iables to memory locations. This is especially useful for passing parameters~ relative and absolute addressing, and dynamic memory allocation. FEATURES Major features of the Intel PL/M 286 compiler and programming language include: Two Data Structuring Facilities Structured Programming In addition to the seven data types and based variables, PL/M supports two powerful data structuring facilities. These help the user to organize data into logical groups. PL/M source code is developed in a series of modules, procedures, and blocks. Encouraging program modularity in this manner makes programs more readable, and easier to maintain and debug. The language becomes more flexible by clearly defining the scope of user variables (local to a private procedure, for example). -Array: Indexed list of same type data elements -Structure: Named collection of same or different type data elements -Combinations of both: Arrays of structures or structures of arrays. The use of modules and procedures to break down a large problem leads to productive software development. The PL/M 286 implementation of block structure allows the use of REENTRANT procedures, which are especially useful in system design. Numerics Support PL/M programs that use 32-bit REAL data are executed using the 80287 Numeric Data Processor for high performance. All floating-point operations supported by PL/M are executed on the 80287 according to the IEEE floating-point standard. PL/M 286 programs can use built-in functions and predefined p roced u res-I N IT$ R E AL$M ATH$U NIT,
SET$REAL$MODE, GET$REAL$ERROR,
SAVE$REAL$STATUS, RESTORE$REAL$STATUS
-to control the operation of the 80287 within the
scope of the language.

Language Compatibility
PL/M 286 object modules are compatible with object
modules generated by all other 286 translators. This
means that PL/M programs may be linked to programs written in any other 286 language.
Object modules are compatible with In-Circuit
Emulators; DEBUG compiler control provides the InCircuit Emulators with full sym~olic debugging
capabi lities.

Built-In String Handling Facilities

PL/M 286 language is upward compatible with PL/M
86 and PL/M 80 so that application programs may be
easily ported to run on the protected mode iAPX 286.

The PL/M 286 language contains built-in functions
for string manipulation. These byte and word functions perform the following operations on character
strings: MOVE, COMPARE, TRANSLATE, SEARCH,
SKIP, and SET.

Supports Seven Data Types
PL/M makes use of seven data types for various
applications. These data types range from one to
four bytes and facilitate various arithmetic, logic,

Built-In Port I/O
PL/M 286 directly supports input and output from the
iAPX 286 ports for single BYTE and WORD transfers.
For BLOCK transfers, PL/M 286 programs can make
calls to predefined procedures.

-Byte: 8-bit unsigned number
-Word: 16-bit unsigned number
-Dword: 32-bit unsigned number
-Integer: 16-bit s,igned number
-Real: 32-bit floating-point number
-Pointer: 16-bit or 32-bit memory address
indicator
-Selector: 16-bit pointer base.

Interrupt Handling
PL/M 286 has the facility for generating and handling
interrupts on the iAPX 286. A procedure may be
defined as an interrupt handler through use of
the INTERRUPT attribute. The compiler will
then generate code to save and restore the processor status on each execution of the user-defined

Another powerful facility allows the use of BASED
variables which permit run-time mapping of var-

3-77

infel

PL/M 286 SOFTWARE PACKAGE

-"Strength reductions": a shift left rather than
multiply by 2; and elimination of common subexpressions within the same block
-Machine code optimizations; elimination of
superfluous branches; reuse of duplicate code;
removal of unreachable code
-Optimization of based-variable operations and

interrupt handler routine. The PUM statement
CAUSE$INTERRUPTaliows the user to trigger a software Interrupt from within the program. Protection Model PUM 286 supports the Implementation of protected operating system software by providing built-in procedures and variables to access the protection mechanism of the !APX 286. Predefined variablesTASK$REGISTER, LOCAL$TABLE, MACHINE$
STATUS, etc.-aliow direct access and modification
of the protection system. Untyped procedures and
functions-SAVE$GLOBAL$TABLE, RESTORE$GLOBAL$TABLE, SAVE$INTERRUPT$TABLE,
RESTORE$INTERRUPT$TABLE, CLEAR$TASK$
SWITCHED$FLAG, GET$ACCESS$RIGHTS, GET$SEGMENT$LlMIT, SEGMENT$READABLE,
SEGMENT$WRITABLE, ADJUST$RPL-provide all
the facilities needed to Implement efficient operating
system software.

Error Checking
The PUM 286 cbmpiler has a very powerful feature
to speed up compilations. If a syntax or program
error is detected, the compiler will skip the code
generation and optimization passes. This usually
Yields a 2X performance increase for compilation of
programs with errors.
A fully aetailed and helpful set of programming and
compilation error messages is provided by the compiler and user's guide.

BENEFITS

Compiler Controls

PUM 286 is deSigned to be an efficient, costeffective solution to the special requirements of
protected mode iAPX 286 Microsystem Software Development, as Illustrated by the following benefits of
PUM use:

The PUM 286 compiler offers controls that facilitate
such featu res as'
-Optimization
-Conditional compilation
- The Inclusion of additional PUM source files
from disk
-Cross-reference of symbols
-Optional assembly language code In the
listing fl,le
- The setting of overflow conditions for run-time
handling.

Low Learning Effort
PUM 286 is easy to learn and use, even for the novice
programmer.

Earlier Project Completion

Critical projects are completed much earlier than
otherWise possible because PUM 286, a structured
high-level language, increases programmer
productivity.

The PUM 286 compiler uses the SMALL, COMPACT,
MEDIUM, and LARGE controls to generate optimum
addreSSing Instructions for programs. Programs
of any size can be easily modularized into
"subsystems" to exploit the most effiCient memory
addressing schemes. ThiS lowers total memory requirements and Improves run-time execution of
programs.

Lower Development Cost
Increases in programmer productivity translate immediately into lower software development costs because less programming resources are required for a
given programmed function

Code Optimization
Increased Reliability

The PUM 286 compiler offers four levels of optll'nizatlon for significantly redUCing overall program size.

PUM 286 is designed to aid in the development of
reliable software (PL/M 286 programs are simple
statements of the plOgram algorithm). This substantially reduces ,the risk of costly Gorrection of errors in

-Combination or "folding" of constant
expressions; and short-Circuit evaluation of
Boolean expressions

3-78

AFPIJ-006438

PL/M 286 SOFTWARE PACKAGE

systems that have already reached full production
status, as the more simply stated the program is, the
more likely it is to perform its intended function.

Cost-Effective Alternative to
Assembly Language

Programs written in PL/M tend to be selfdocumenting, thus easier to read and understand.
This means it is easier to enhance and maintain
PL/M programs as the system capabilities expand
and future products are developed.

PL/M 286 programs are code efficient. PL/M 286
combines all of the benefits of a high-level language
(ease of use, high productivity) with the ability to
access the iAPX 286 architecture. This includes language features for control of the iAPX 286 protection
mechanism. Consequently, for the development of
systems software, PL/M 286 is the cost-effective alternative to assembly language programming.

SPECIFICATIONS

Documentation Package

Operating Environment

PL/M 286 User's Guide

Easier Enhancements and Maintenance

Intel Microcomputer Development System (Series
III/Series IV)

ORDERING INFORMATION

SUPPORT:

Part Number

Description

iMDX 323

PL/M 286 Software Package

Hotline Telephone Support, Software Performance
Report (SPR), Software Updates, Technical Reports,
and Monthly Technical Newsletters are available.

3-79

AFN-006438

iSDMTM 286
iAPX 286 SYSTEM DEBUG MONitOR
Universal Development Interface (UDI)
Development support for iSBC® 286• support
• and
via development system
iAPX 286-based applications
connection
Address Mode (RAM) and Protect• edRealVirtual
Address Mode (PVAM) support
execution, including proof MULTIBUS® I and MULTIBUS®
• Support
• Command
gram load capability from Intellec® Series
II environments
III or Series IV Development Systems
Powerful debugging commands,
• including
single step CPU operation
Supports 80287 Numeric Processor
MULTIBUS® II, software configuration
• Extension
• ofForsystem
(NPX) for high-speed math
boards at start-up and autoapplications

matic configuration. of memory boards

The Intel iSDMTM 286 System Debug Monitor package contains the necessary software, cables, I;:PROMs, and
documentation required to interface an iSBC® 286 board or iAPX 286 application to an Intellec® Series III or Series
IV through a high-speed link. The System Debug Monitor supports an OEM's choice of MULTIBUS® lor MULTIBUS
II environments, and the iRMXTM 86 Real-Time Multitasking Operating System or a custom operating system.
The monitor contains debugging tools that examine CPU registers, memory content, CPU descriptor tables, and
other crucial environmental details. The Monitor also allows programs to access files on the development system via the internal UDI support 'and the serial communication link.

The following are trademarks of Intel CorporatIon and may be used only to describe Intel products: Intel, ICE, iMMX, iRMX, iSBC, iSBX, iSXM, MULTIBUS,
MULTICHANNEL and MULTI MODULE. Intel Corporation assumes no responsibility for the use of any circuitry other than CirCUItry embodied in an
Intel product. No other circuit patent licenses are implIed. Information contained herein supercedes previously published specificatons on these deVIces
from Intel.

© INTEL CORPORATION, 1984

3-80

SEPTEMBER, 1984
ORDER NUMBER: 230882'()()2

inter

iSDM™286 MONITOR

FUNCTIONAL DESCRIPTION

MULTIBUS® II Software
Configuration of System Boards

Overview
The iSDM 286 System Debug Monitor provides
programmers of iAPX 286-based applications with the
debugging tools needed to test new applications ranging from single-user systems to complex operating
systems executing in either a MULTIBUS I or MULTIBUS II environment. Programmers are given direct
access to both the Real Address (RAM) and Protected Virtual Address (PVAM) modes of the CPU via a
simple terminal interface or via an Intellec Series III
or Series IV Development System.

The MULTIBUS II Interconnect Space Registers allow the software to configure boards, eliminating
much of the need for jumpers and wire wraps. The
iSDM 286 Monitor can initialize these registers at configuration time using user-defined variables. The Monitor can also automatically configure memory boards,
defining the addresses for each board sequentially
in relation to the board's physical placement in the
card cage. This feature allows for the swapping, adding, and deleting of memory boards on a dynamic
basis.

Powerful Debugging Commands

Command Execution

The iSDM 286 Monitor contains a powerful set of user
functions, including commands to:

Commands to the iSDM 286 Monitor are entered
interactively via a standalone terminal, an Intellec~
Series III or a Series IV Development System. The
target application hardware is connected to the terminal
or development system via a serial link. Figure 1
shows a typical MULTIBUS I environment and Figure
2 shows a typical MULTIBUS II environment. All control operations and UDI file manipulations occur over
the serial link through the cables supplied. More than .
one channel can be configured for the communication since the Monitor scans all configured channels
to determine which channel is in use.

Examine and modify CPU registers
Examine, modify, and move memory locations
Symbolic reference to variable names
Find and compare memory contents
Set program breakpoints
Bootstrap load applicati9n software from iRMX 86
file compatible peripherals (requires the iRMX 86
Operating System for Bootstrap Loader)

Numeric Data Processor Support

Single-step CPU operation

In addition to executing 80287 Numeric Processor Extension (NPX) applications with full NPX performance,
programmers may examine and modify NPX registers
using decimal and real number format. Any location
in memory known to contain numeric values in standard real format (IEEE-P754) may be examined or
modified using normal decimal notation. In this manner, programmers may feel confident that correct and
meaningful numbers are available to applications
without having to encode and decode complex real,
integer, and BCD hexadecimal formats.

Switch from Real Address Mode to Protected Virtual Address Mode

Formatted Displays
The iSDM 286 Monitor formats all iAPX 286 predefined data structures into clearly understandable displays. This display gives programmers a formatted
view of such CPU structures as LOTs, GDTs, lOTs,
Segment Selectors, and Task State Segments-not
just a series of unconnected digits.

Universal Development Interface (UDI)
Via the Universal Development Interface (UDI), the
iSDM 286 Monitor can support the execution of iRMX
86, Series III, Series IV, or any other UDI-based applications. The Monitor emulates many of the UDI
calls (RAM or PVAM), and passes all requests for a
file system to the host development system. UDI applications, such as compilers and other programs
available from Independent Software Vendors, can,
be tested in the target iAPX 286 environment immediately.

3-81

230882'()()2

iSDMTM 286 MONITOR

,SDM'· 286
MONITOR PROMS

SERIAL 110
PORT

SERIAL PORT
,SBC 286/10

INTELLEC SERIES III
DEVELOPMENT STATION

Figure 1. Typical MUL TIBUS® I Environment

SERIAL 110
PORT

APPROPRIATE
,SBC' BOARD

INTELLEC" SERIES IV
DEVELOPMENT SYSTEM

RS232
CABLE

Figure 2. Typical MUL TIBUS® II Environment

3-82

230882·002

inter

iSDM™286 MONITOR

SPECIFICATIONS
Development System Environment
Intellec Series III or Series IV Development System
with 128K of memory and 1 disk drive.

Target System Environment

manual. The software is provided on a double-density,
single-sided ISIS-formatted 8" diskette for Series III
Development System use and on a double-density,
double-sided iRMX-formatted 5V4" diskette for Series IV Development System use.
The OEM license option listed here allows users to
incorporate iSDM 286 into their applications. Each
use requires payment of an Incorporation Fee.

Any iAPX 286 system with at least 4K of read-write
memory starting at location OH and 32K of read-only
memory starting at location OFF8000H.

ORDER CODE: iSDM 286 RO.

Serial communication with a stand-alone terminal or
development system requires either a 8274 USART
and 8253 or 8254 PIT, or an 82530 SCC.

The iSDM 286 RO product also includes 90 days of
support services that includes the Software Problem
Report service.

Monitor EPROMs are supplied for locations OFF8000H
through OFFFFFFH.,

ORDERING INFORMATION
The iSDM 286 System Debug Monitor package includes cables, EPROMs, software, and a reference

3-83

Another licensing option includes prepayment of all
future incorporation fees.
As with all Intel software, purchase of any of these
options requires the execution of a standard Intel
Master Software license. The specific rights granted
to users depends on the specific option and the

230BB2-OO~

80287 SUPPORT LIBRARY
• Library to support floating
pOint arithmetic in Pascal-286,
PL/M-286 and ASM-286

• Common elementary function library
provides trigonometric, logarithmic
and other useful functions

• Decimal conversion module
supports binary-decimal
conversions

• Error-handler module simplifies
floating pOint error recovery

• Supports proposed IEEE Floating
Point Standard for high accuracy
and software portability
The 80287 Support Library provides Pascal-286, PLlM-286 and ASM-286 users with numeric data processing
capability. With the Library, it is easy for programs to do floating point arithmetic. Programs can bind in library
modules to do trigonometric,. logarithmic and other numeric functions, and the user is guaranteed accurate,
reliable results for all appropriate inputs. Figure 1 below illustrates how thee 80287 Support Library can be
bound with PLlM-286 and ASM-286 user code to do this. The 80287 Support Library supports the proposed
IEEE Floating Point Standard. Consequently, by using this Library, the user not only saves software development time, but is guaranteed that the numeric software meets industry standards and is portable--the
software investment is maintained.
The 80287 Support Library consists of the common elementary function library (CEL287.LlB), the decimal
conversion library (DC287.LlB), the error handler module (EH287.LlB) and interface librarie!? (80287.LlB,
NUL287.LlB).

B.PLM
APLM

m~J~lH.J'l~~f~~U~HETA) REAL EXTERNAL
ENOm'lf!{TNH
DECLAFlE(INPUTVALUE OUTPUTVALUEJAEAL

I----t PLM·286 t--~

OUTPUT VALUE"mqe,TNH(INPUT VALUEI

~ ~~1~~~!~ 1&$Ilnpul OUTPUT VALUE 1$ a~out

COMPILED
SOURCE MODULES

DASM
CASM
T~:~, eXTRN must appea, oUls1de 01 all SEGMENT ENDS

J'XTANmqerTNH FAR
INPUT VALUE 001 OG2) V~I~,:alLzall""'$ale51 TI1eloilowlngcodeduplK:alestheabcvePLIM ~!~'~~I:nl st81ement e.c,pl w~h LONG REAL fLO INPUT VALUE ~~!hepaf.menle"nIQlhe802S1 CALLmqerTNH FSTPOUTPUTVALUE take the hyOft Corporation 'I////////////////""/""/"""'IIIIIIII~ 3-122 defined communications module provides the user with a standard mechanism for program-to-program message- passing in multi-user networks such as those found in an "office of the future .. settings. Forms-2™ Support for Screen-Painting program development of new applications in a microcomputer environment. These features include a facility for dynamically loading sub-programs from disk as required which effectively removes limits on the size of the application code that can be run. XENIX COBOL augments the functionality of the ANSI standard with additional compilerfeatures, such as interactive screen"handling, that further increase convenience and programmer productivity. XENIX COBOL supports FORMS-2, a powerful visual programming tool that. speeds the creation of programs involving interactive screen-handling. In an extremely user-ftiendly environment, the user "paints" a form on the screen, and FORMS-2 generates the COBOL source code to support it. FORMS-2 results in greatly improved programmer productivity in a microcomputer, screenbuilding environment. XENIX BASIC for Maximum Flexibility Intel's offering of Microsoft BASIC opens a whole window of applications to the XENIX user. Since their BASIC is the same as that used on MS-DOS· based machines, most programs written for MS-DOS can now run on XENIX un, changed. When developing your own Users can license a separate run-time support package. This enables OEMs to pass COBOL applications onto customers at a much lower cost than that involved in transferring full COBOL packages. XENIX COBOL is one of only eleven COBOL compilers in existence-and the only one for microcomputers - that has been GSA-certified programs, BASIC is simple and easy for quick prototyping, yet complete enough for total development. Conforming to the ANSI X3.60 1978 subset standard, BASIC also has powerful extensions, 16 significant digit Double Precision floating point arithmetic,80287 support, and assembly languages routine calling capabilities. From using applicatIOns to designing your own programs BASIC is easy, complete, and extremely flexible. Worldwide Service and Support All XENIX systems are fully supported by Intel's worldwide staff of trained hardware and software engineers. Complete documentation is provided for ail operating systems and application software languages, as well as for system hardware components. The XENIX and XENIX Languages warranty includes Hotline support, Software Updates, and Subscription Service. Total Solutions for Interactive, MultiUser Applications Intel's XENIX-based systems offer the most complete solutions for interactive, multi-user applications requiring fast, accurate throughput and a ftiendly programming environment. XENIX is complemented by industry-standard, high-level languages with which OEMs can create flexible and open end-user systems. XENIX languages are completely portable-from one level of integration to another (chip to board to system). Intel is paving the way into the future of VLSI and pioneering VLSI-based systerns. We are committed to providing customers with smooth, uninterrupted application development on the latest VLSI-based systems - today and tomorrow. 'IIIIIIIIIIIXENIX* LANGUAGES 3-123 inter Specifications Required Hardware: Required Software: • Any iAPX 286 based or iSBC® 286 based system including Intel's 286/300 family and iDlS systems • Intel's XENIX 286 Operating System • 196 KB memory • Purchase of any XENIX Language requires signing of Intel's OEM License Agreement (OLA) • Two floppy disks or one hard disk • One 8" double-density or 5.25" double-density floppy disk drive for distribution of media Ordering Information Language Order Code Product Contents COBOL XNX2867 One 8" diskette and one 5.25" diskette Level II COBOL Language Reference Manual-122158 Level II COBOL Operating Guide-122159 Forms II Utility Manual-122160 Level II COBOL Pocket Guide-12216l FORTRAN BASIC XNX2868 Incorporation Fee for passing through the COBOL Runtime System XNX2862 One 8" diskette and two 5.25" diskettes Fortran Reference Manual Fortran User's Guide XNX2865 One 8" diskette and one 5.25 diskette BASIC Reference Manual BASIC User's Guide FORMS·21S a trademark of Micro Focus 3-124 Warranty 90 days: Software Updates, Subscription Service 90 days: Software Updates, Subscription Service 90 days: Software Updates, Subscription Service 2920 SOFTWARE SUPPORT PACKAGE • Complete software design and development support for the 2920 • Extends Intellec@ Microcomputer Development System to support 2920 software development The 2920 Software Support Package furnishes a 2920 Signal Processing Applications Software/Compiler, 2920 Assembler, and 2920 Software Simulator. These three software design and development tools run on the Intellace Microcomputer Development System. The 2920 Signal Processing Application Software/Compiler is an interactive tool for designing software to be executed on the 2920 Signal Processor. The compiler accepts English·like statements from the user and generates 2920 assembly language code. The assembler tra.lslates symbolic 2920 assembly language programs into the machine operation code. The user can load the code into the simulator for 2920 simulation or to the Universal PROM Programmer for 2920 EPROM programming. The simulator, operating entirely in software, allows the user to test and symbolicaily debug 2920 programs. The user can specify input signals, Simulate program execution, set up breakpoints, display input and output, and display and alter the contents of the 2920 registers and memory locations. The simulator can also stop or trace the program and constructively give the user access to the key elements inside a 2920 for analyzing his program. The 'compiler, assembler, and simulator enable the designer to develop and test an entire program without a complete prototype design, The 2920 designer works on the Inteilec" Microcomputer Development System rather than on a breadboard, The development system can program, store and recall programs or routines and aid in 2920 program design. 2920 Software Support Package The fOllowing are trademarks of Intel Corproallon and may be used only to Identify Intel products BXP.lntellec, Muilibus. I, ,sac. MultlmOdule.ICE.IS8X, PROMPT, leS.lIbrary Manager, Promware. InSlte, MeS, RMX, Inlel, MegachaSSIS. UP!. InteleVISlon, Mlcroamp, .I'Scope and the combinatIon of ICE .• es. ,sac. ,sax, MeS. or AMX and a numerical suffiX Intel CorporatIon 1980 3-125 Sept 1980 1662208 2920 SOFTWARE SUPPORT PACKAGE 2920 SIGNAL PROCESSING APPLICATIONS SOFTWARE/COMPILER • Compiler generates 2920 A~sembly Language Code ' • Extensive command set for designing electrical filters • Graphics capability enhances analysis of filter response or piecewise linear function approximations • Powerful MACRO capability for executing frequently used routines • Interactive software support tool for 2920 Signal Processor • Extends IntelJec® Microcomputer Development System support of the 2920 • Contains MACRO library for several standard filters and signal processing functions The 2920 Signal Processing Applications Software/Compiler (SPAS20) is an interactive tool for designing software to execute on the 2920 Signal Processor. The SPAS20 package can be visualized as being comprised of four inter-related sections: A compiler section, a filter design section, a curve fitting section, and a MACRO section. Among the abilities of SPAS20 are: ability to generate 2920 assembly language code directly from specifications of signal processing building blocks such as filters and waveform generators; ability to generate 2920 assembly language code for several classes of algebraic equations such as Y C· X, Y C'Y, and Y =C· X + Y where X, Yare variables and C is a constant; ability to generate 2920 assembly language code for one variable function Y(X) = F(X); ability to examine time and frequency r~sponses of filter sections specified by continuous or sampled poles and zeroes; ability to examine piecewise linear approximation of specific function; ability for users to implement more complex commands by grouping sets of commonly used commands into a MACRO. = = The SPAS20 package runs under ISIS-II on any Intellec@ MicrocQmputer Development System with 64K RAM. The output of SPAS20 can be assembled with the 2920 assembler, tested with the 2920 Simulator, and programmed into the 2920 chip with the Universal PROM Programmer for prototyping. 3-126 AFN·01386A 2920 SOFTWARE SUPPORT PACKAGE FUNCTIONAL DESCRIPTION DATA The 2920 Signal Processing Applications Software! Compiler gives the analog designer a "high level language" for his 2920 applications-it decreases the need to code 2920 assembly language. Furthermore, the compiler is interactive. This feature enables the designer to define a filter, or transfer function, graph their response, and change their parameters many times, without having to program and test in an actual 2920 implementation. This command allows for specification of a set of vertices (i.e. X - Y coordinate pairs) which determine a piecewise linear approximation of some defined function, filter response characteristics, etc. HOLD Command to correct attenuation due to sample-and-hold distortion: if ON, it corrects absolute gain by sin(x}! x and phase by adding x, where x=TS'FREQ'lT. It corrects group delay by subtracting IT'TS. EVALUATE Gives the decimal nUf)1eric value of any expression. CODE Creates 2920 assembly language code for given poles, and zeros, equations, and user defined functions. Once a filter is realized by moving poles and zeros in the continuous and sampled planes, the filter may be coded and written onto an ISIS file. Similarly, after a function Y =F(X) has been defined, the code for a piecewise linear approximation can be stored onto an ISIS file. Several other file commands are available to store and retrieve command sequences for SPAS20 sessions. SPAS20 Command Language DEFINE This command defines a pole or zero by associating it with a number (i.e., POLE 3), and with real and imaginary coordinates in the continuous or sampled plane. This command also defines a symbol by associating a name with a numeric value, or a MACRO by providing a pOinter to a specified command sequence. GRAPH! OGRAPH MOVE This command graphically displays the values of object(s) specified. For example, GRAPH GAIN and GRAPH PHASE are used to display filter response. The OGRAPH command will "overgraph" the new response over the old response. after any changes have been made. (You may also graph Group Delay, Step, and Impulse.) Allows the definition of a pole or zero to be changed-its coordinates, its plane, or both. REMOVE Deletes the definition of a pole, zero, symbol, or macro. HELP Types an explanatory message on the console, pertaining to a command or its attributes. FIT This command performs curve fitting, i.e. it approximates an arbitrary user supplied function with a piecewise linear function. The SPAS20 compiler also recognizes the following commands for file handling: PUT! APPEND Writes out objects (commands) to a specified file, either creating a new one or appending an existing one. This enables the user to store all or part of a SPAS20 ses· sion on a diskette to be brought back later with the INCLUDE command. DISPLAY Copies the contents of a file to the console. INCLUDE Executes a sequence of instructions from a diskette file as if they were typed in from the console. LIST Creates a file containing console interactions. all In addition to naming macros for specific command seql,lences, compound and conditional commands may be formed using all of the above statements. These compound commands are: IF Establishes conditional flow of control within a block of commands. REPEAT Used for repetition of a block of commands; executes indefinitely or until a condition is met (using WHILE, UNTIL, and END statements). COUNT Establishes the number of times a command sequence is to be executed, in a looping fashion. 3-127 AFN-01386A 2920 SOFTWARE SUPPORT PACKAGE Intel also supplies several MACRO library files con· taining the following commonly needed MACROs: SPAS20 MACRO Facility A macro is a sequence of commands that is stored on a temporary diskette file. The command sequence is executed when the macro name is entered as a command. This saves repetitive entry of the sequence, and permits alogorithms to be saved on diskette for future use. This SPAS20 facility allows you to do the following: • Display the text of any macro. • Define a macro, specifying its name and any parameters that are to be used by the block. This definition is followed by the contents of the macro (commands) and the EM statement to end its definition. • Invoke a macro by entering its name and appropriate values for any parameters. • List the names of all defined macros. • Remove any or all macros. Filter design MACROS - Butterworth filter - Chebyshev filter - Bilinear transform - Evaluate gain or phase of digital filter in parallel form - Time response simulation Function design MACROs - Code and error optimization - Calculate instertitial error MACROs for generation of 2920 code - Code for all·POLE filter - Input and AID conversion - Multiplication - Division - Logarithm functions - Square·root functions - Sinewave oscillator SAMPLE SPAS20 FILTER DESIGN SESSION -: Fl : SPAS20 • SFT ·· ISIS-II 2920 SIGNAL PROCESSING APPLICATIONS COMPILER. V2.0 'OEFINE POLE 1 • -101.707 : CREATE A POLE IN CONTINUOUS S-PLANE .p: LIST ALL POLES ANt ZEROS PO"E I • -701 00000.701 OOOOO.CONTINUOUS •'FSCALE' •OVSC4LE • · 100.10000 : ESTABLISNES FREQUENt' RANGE OF INTEREST -45.1 ESTABLISHES MAGNITUDE RESPONSE RANGE OF INTEREST 'CP"PH CAIN PLOT MAGNITUOE RESPONSE OF POLE PAIR .., '. CAH4 .. . -" , ................ . • • ,_ ....................... 1.0 -! 2. 1 --tIL l". -; I) - 1 l. • -21). ~ -21. : -2~.' -1"'.':' -2f .... ... 3 1. ? -H.J ... 30).':: -1) ... -41). ,; .... 1. '? ':'415 .. t) DB I HZ ! ............................................ A . ..• 100 150 200 300 400 500 • • • •• " 700 1000 1400 2000 3000 5000 J \0000 •• THE UNITS USED IN CRAPHING GAIN ARE SHOWN IN THE LOVER LEFT CORNER •. CAIN IN DEelBELS IS GRAPHED VERSES FREQUENCV IN HERTZ .: PREPARE TO MOYE TO THE OIGITAL OOM"IN . • ; SAMPLE RATE MUST BE SPECIFIEO •.T& • 1/13020 RATE FOR 192 INSTRUCTION PROC'AM AND IOMH2 CLocr TS = 7 '805004/10 •• 5' 3-128 AFN.()l386A inter 2920 SOFTWARE SUPPORT PACKAGE SAMPLE SPAS20 FILTER DESIGN SESSION (Cont'd.) '"OVE POLE TO l I OOcES/lE'OES ftDYEO , CONYERT FilTER TO DIGITAL YIA ftATCNEO-l TRAMaFORftATION LIS T TRANSFORftEO POLE POLE 1 • 0 71092836,0 341183",Z .p ., COMPARE RESPONSES OF THE ANALOG AHO DIGITAL FILTERS BV CRAPHINC THE .' NEW RESPONSE OYER THE DLP 1"",'".'",,,'·,,',,.',,,,',,,, !.~ "" - - - - - - - - - - - - - - - - - - - - - - - - - - - ••. -1. '* -5.'; --. ~ + -. - I 'J .•J -11. I +' , +' . -!".3 .' -. +' - t 1:. - -ZO.-:- + -. • + • -- •• - 2 ~. ' -~;. ) ++ - r'. :. - 2~ ++ .... ++ - J. ., -::". ,:, - J,;. • .;. ++ -B. -I - .'L " - 41 . ~ -45' 'I ++ + :'8 I HZ ' 1 Ii o· i 50 .200 ... 300 .400' 500' . 70 0 . i 000 . i 400 . 2000' . iooo .... 5000 ..... i 0000 ....... ""... ,. ,. " A ... ... I C' ' . PLUS SICNS INDICATE OLD CURYE " NOTE THAT THE DIGITAL FilTER RESPOHSE BECINS TO INCREASE Ar,AIN ., ., HALF THE SAftPlE UTE ( "10HZ ) · .: THE PHASE CHARACTEJISTICS OF THIS FILTER CAM BE EKAftlNEO .YSC~LE • -PI.PI PH~SE , ESTABLISHES RAMGE OF INTEREST I ................... " ...................................................................... ! 3. : .. 2 ... 2. ~. 2.24 1." 1. '5 1,35 1. O~ 0,75 0.45 0.15 -0.15 -0.45 -O.~S - I ,05 -1.35 -1,65 -t.H -2.24 -2.54 -2.84 -3· 14 RAOIHZ P. • · OP~T i 00' iso' 200'" 300 '400 . 500" 700' ioao' i 400' 2000' "3000" .. 5000 .. , .. ioaoo I ... 'Fl 'POLE PZ H'JUt PuLE 1 B;'1 33'8'.'0 IN~Tul A ..."... ... A " ... ... ... I , 'AYE THE POLE LOCATION IN A DISK FILE BACKUP ; "~Hi.i<.i~ ,~lU A,H"tL, '.ODE FU~ THIS 'ILI~~ B2'-0 50541'14 3-129 AFN·01386A inter 2920 SOFTWARE SUPPORT PACKAGE SAMPLE SPAS20 FILTER DESIGN SESSION (Cont'd.) OPTI"IZEO 2'20 CODE IS NOW eEMERATEO TO ~AYE SPACE. SOME OF THE SCREE" OUTPUT HAS BEEN DELETED NORNALLY ALL ATTENPTS BY THE COM'ILER TO GE"ERATE CODE ARE ECHOED ON THE SCREEN IHiT=lO 'OLE I • 0 7108'458.0 34116779.2 8EIT: PER~OR - 3 3795874/10005.1 5884'567/10005 , HOTE: "AlE SURE SIGNAL IS <0 74'35571 ?UT2.PI.OUTI.PI.ROO : OUT2.PI-1 OOOOOOOOoOUII.'1 LD~ OUII.'I.OUIO.'I.ROO OUII.PI-I ooooOOOOoOUIO.PI sua QUTO.'I.OUTI.'I.R05 : OUTO.Plol oooOOOOOoOUTO.'I-O 03125000000UII_'1 ADO OUIO_'I.OUIO_'I.R03 OUTO.'lol IZ50000000UTO.'1·0 03'1'6Z'000UTI.PI ADD OUIO_'I.OUII.'I.R02 . OUTO_PI-I 12'0000000UIO.PI+0 2148437,00UII.PI SUB OUTO_'I, OUT2.'I.ROI ; OUTO.Plol 1250000000UIO_'1+0 2148437500U11.PI-O SUB OUTO_'I.OUI2.PI.ROB OUTO_Plo, 12'0000000UTO.'I+O 2148437500UTI_PI-0 ADD OUTO.'I.OUIZ.PI.RII OUIO.Plol 12'0000000UIO.PI+0 2148437,00UTI.PI·0 SUB OUTO_'I.OUT2_PI.R09 : OUTO_Plol '1250000000UIO.'1+0 2148437,00UTI.PI·0 ADD OUTO_Pl, INO.' I, too : OU'IO.PI-I l2'OOOOOOOUIO.'I+O 2148437,00UTI.P\·0 lD~ ,000000000UT2.PI 5039062500U12.PI 503417,,00UT2.PI '0'3710900UI2_'1 '0'3710900UT2.Pl+1 oOOOOOOOoINO.PI 0, THE CODE COUAND SPECIFIEO THAT THE POLE PAU BE CODED IN LESS THAN II 0, INSTRUCTIONS, SO 10 INSTRUCTIONS WERE GENERATED. WITH CO"",NlS 0, THE FIHAL ERROR 1M RADIUS AND ANGLE FOR THE POLE PAIR WAS OF THE OJ ORDER OF 1/10'" AS INDICATED ABOYE IN PHROR OJ THIS OPTI"IZED 2920 ASSE"BLY CODE CAH HOW BE APPENDED TO A FILE OJ WHICH NAY CONTAIN OTHER COOED FUNCTIONAL BLOCtS OF A 2920 PROGRA" SAMPLE SPAS20 CURVE FITTING SESSION nE'10NSTRATION OF THE ~PA~2n CURVE-FITTING PACKAGI. ISIS-II 2920 SIGNAL PROCESSING APPLICATIONS SOFTWARE/COMPILER, V2.0 *1.I<;T vfi!~Fn.R/q *; •. •. TIIF CIIRVF FTTTI~r: r;n''''AllD I INPUT CHANNEL 0 SIftUL TAHEOUSLV CALCULATE SAYT OOTH BY SUBTRACTIHG 3/1' fROH y ALSO CHECK SIGN .BIT Of Y IF Y HrGATIYE START NEXT TOOTH COHYERT SAMPLED I NPU T TO DIGITAL (S IGH 8 IT) SUPPRESS SAUTODTH IF IHPUT WAS < 0 PREPARE TO OUTPUT SAWTOOTH ANALOG LEYEL HUST SETTLE OUTPUT SAWTOOTH PROGRAM WILL EHO IH THREE HORE I HS TRUCT I OMS 24 ,5 EHO YAlUE: SYHBOL: AS~E"8LY ERROPS YARNINGS RAMS !ZE ROHSlZE COMPLETE • o o I 20 3-132 AFN·Ol386A 2920 SOFTWARE SUPPORT PACKAGE 2920 SIMULATOR Speeds test and debug of 2920 programs Output and internal data can be saved on disk for further analysis. Simulates 2920 internal operation Operates on Intellec@ Microcomputer Development Systems Provides ability to set breakpoints and to collect trace information Easy·to·learn commands Allows users to specify 2920 input signals, and display or alter ROM, RAM, and system variables The 2920 Simulator is a software facility that provides testing and symbolic debugging of 2920 programs in an Intellec Microcomputer Development Systems environment. The 2920 designers have the capability to specify the 2920 input signals, to set breakpoints, to collect and display 2920 input, output, system variables, and ROM and RAM data values during simulation The 2920 Simulator accepts the hex format oblect files produced by the 2920 assembler. Output values and internal trace data may be saved on ISIS·II disk files for further analysIs. Functional Description 2920 Input Signal Specification The four analog signal inputs to the 2920 processor can be specified as algebraic combinations of basic functions of time. The basic functions are SIN, COS, EXP, LOG, SaR, SAW, saw, ABS 2920 Simulation The simulation bf 2920 machine instructions is performed in software All 2920 internal registers, memory, input values, output values, and other sys:em variables can be examined and modified. The Internal processing of the 2920 is simulated. Time constants for the sample and hold capacitators are assumed to be zero Calculation of input signals is performed in single precision floating poinf. The speed of simulation varies with the complexity of the input signal, breakpoint setting, and trace condition. Exclusive of I/O time requirements, 2920 instructions will be simulated at a rate of approximately several hundred instructions per second. records are stored in Intellec resident memory and are optionally written to the console for display or to a disk file for record. Symbolic Debugging Capabilities The 2920 Simulator allows the user to refer to program addresses symbolically. The user can load or save the symbols generated from the hex format object files or created during the debugging session. 2920 program memory in ROM can be disassembled, or filled with assembled instructions. The 2920 Simulator is designed to provide users with . powerful, easy-to-use commands. The user interfaces to the Simulator by entering commands to the Intellec console. The commands consist of one command line, t!'lrminated by one of the two line terminators - carriage return or line feed. The 2920 Simulator offers two types of commands: Simulation and Control Commands Breakpoint Capabilities Command After each instruction is simulated, the breakpoint is evaluated to determine whether to stop or continue simulation. Conditional breakpOints are also provided for debugging purposes. Simulation can be manually stopped at any time by .pressing the ESC key on the Intellec console. Trace Capabilities Based on the qualifier's condition, trace data records can be collected during simulation. The trace data 3-133 Operation Simulate Starts slmulalton of the Input signals and the 2920 program in simulated ROM memory Imtlal setting IS "FOREVER" Trace Controls the trace selection. Initial setting IS "TIME." Qualifier Sets qualifter condition during trace. Imtlal setting IS "ALW.AYS." Breakpoint Sets breakpoint condition during simulation. Imtlal setting IS "NEVER." AFN·01386A inter 2920 SOFTWARE SUPPORT PACKAGE Interrogation and Utility Commands • Software Simulalor Keyword References Command Operation TIME Display DIsplays the values of symbols, RAM, ROM, Input, output, regIsters and system variables Elapsed simulated time in seconds (read only) TaUAL Time when the qualifier last matched in seconds' (read only) Change Alters the values of symbols, RAM, ROM, input, regIster and system variables. COUNT Base Establishes the mode of display for output data. Number of instructions simulated since last SIMULATE command (integer, read only) BUFFERSIZE SuffIX EstablIshes the mode of display for Input data. Number of trace data records (integer, read only) Fetches user symbol table and object code from input devIce. TlNST Load Time between successive instructions in seconds (read only) Save Sends user symbol table and object code to output devIce SIZE Number of instructions in program disregarding actual EOP placement Define Enters symbol name and value to user symbol table TPROG Time between successive passes in seconds Console Controls the console onloff dIsplay VREF Reference analog level voltage in volts list Defines lIst devIce program Exit Returns program control to 1515,11. Evaluate Converts expression to eqUIvalent values In binary, decImal, and hex Remove Deletes symbols from symbol table ISIS Compatibilities Help ProvIdes a brief summary of the syntax for the command languages. Graphics' OnlOff' Switches output mode between list and graphICS. The 2920 'software Simulator runs under the ISIS "submit" facility. The 2920 software simulator uses the ISIS-II line editing capabilities to correct errors 'in an input line on the Intellec console. X S,ze Enters horizontal dIsplay sIze. Keyword References The 2920 Simulator provides users with keyword references to gain access to all of the numeric valued system variables including simulated 2920's memory, register, status flags and input/output. These keyword references can function as the evaluation command, display command, and change command. • 2920 Processor Keyword References INO IN1 IN2 IN3 OUTO OUT1 OUT2 OUT3 QUT4 OUT5 OUT6 OUT7 IN DAR PC CY OVF OVE Analog input 0 in volts Analog input 1 in volts Analog input 2 in volts Analog input 3 in volts Analog output 0 in volts (read only) Analog output 1 in volts (read only) Analog output 2 in volts (read only) Analog output 3 in volts (read only) Analog output 4 in volts (read only) Analog output 5 in volts (read only) Analog output 6 in volts (read only) Analog output 7 in volts (read only) Sampled and held analog input sigpal in volts Digital to analog register (RAM location 40) Program counter (integer 1 to 192) Carry (integer 0 or 1) Overflow (integer 0 or 1,read only) Overflow enable (integer 0 or 1) The above keyword references are designed to aid 2920 program debugging. Sample 2920 Simulation Session ISIS-II 2920 SIMULATOR, Vl.l * *; THIS I~ THF. <;IMULATION OF THF. *L1<;T SRG.LOG J.ISTS *1.DAn SRG.HEX *RO\t 0 ROH RO~1 TO nao 001 S LOA ,. Ann ; LOAD THE OHJECT CODP TH~ ; DISPLAY .K.KP5,ROO,NOP 'SAWTOOTH GF.:~r:RAToR· <;HHlLATION <;F.S<;ION TO AN SRG I~Tn lSI<; .Y.,KPl,R05,NOP ROtt 002 ,. LOA .K,oK,R02 , NOP ROH n01 .. SUR .o<)c, .K,ROO,NOP ROM 004 ,. LOA DAR,oOSC.ROO,NOP ROM n05 • AOO .O<>C,KP4,LOl,CNDS *TPROG-I/IOOOO ; SET THE SAIIPLF. RATE ; SET THE ITEMS TO HE TRACED j DISPLAY THE RESULTS IN BINARY *SIHULATE PROM 0 TILL COUNT=3 ; <>IMI!LATF. THREE IN~TRUCTIONS TO VERIFY CONSTANT *TRA-~C,RAM .K *HASE-R RAlf n PC SIMULATION BEGUN 1.000000000000000000000000 2.0000000£+0 3.00(}OOOOf.+0 0_101000000000000000000000 0_101000010000000000000000 o. no 1 () 1 ooon 100000000000000 SHWLATION TF.RrlINATF.D *QIJALIFIER=PC=O ; TRACt, EVERY PROGR'AI1 PASS *TRACf.=T.OAR.RAH .00;(; ; <>F.T THf ITF.~t<> TO RF. TRACF.D *RAll .ose-ONt, ; INITIALIZE TI-lE RAil LOCATION *RRF.AY.:POINT-T).OOl12 ; <>IIIULATE FOR TWO CYCLECi *RASF.-D ; (jET THE RA<>F, TO nF.CI~AL *C;ItlULAT~ PRO.t 0 ; HEGIN Slf'l'LATION T DAR RA!l I 3-134 FlU' TlfE 7Q20'SI'!UALTOR PROCRAN AFN·01386A 2920 SOFTWARE SUPPORT PACKAGE <;I·llr1.ATln~J 1'1; F [,(1 tl n.nnfljflOOIl n.klfJR417 r l n.6R1S917,) n,'i271417') n.noo2onno o.nonlnnnn n.non4nnnn n.nnO,)fiOOn f). 1fo 7! R 7 ')() n. 2 11)t) n.A4777114 n,fJR'),)4hAl n. ')2R1202fl n.17J0917n 17 ')() n.nOllhnnno n.?J1Rh714 Il.O')4hR7';o n.n,)6h4o,)f, n.On07nnOO n.nnl"/)I)/)/) n.nOlloonn -0. I n I ,)(,2 SO n.71R2RI2'i n. ')820112') n.42'i7B12,) 0.269')11]') n.nOl2nnnn n.nnll!)OOc) 0.10917')00 -o.n46R75()O n.nnnRnnnn n. Ol)l)qnflnn <; HlULATl0N n.R9941196 (). 7421 R 14 ') n.SR4961lA9 0.'12771711) 0.270')0776 O.1112R119 0.95605459 TERMINATf.n ·CPAP!I ON ; <;WITrHF~ T'IE DI<;PLAY 'lODE TO *TRACf:-'T.O,DAR,RA'l.0'iC,-1.-l,i,1 *RA'1 ,ooe;r-oNF ·SI'HlLATF: FRO'l 0 ; INITIALIZE THE ; ,)ET'> ITF-Mot; DAR T TO CRAP!IIC~ BE TRACED RAil LOCATION RAH 1 -I -I <:;HlIll.ATION RF'r.UN - ). n • n • n • n • 1 • 1 • o • o • o • o • 2 1 3 • <:;lH!JLATION TF'lHIINATEO *EXIT SPECI FICATIONS Optional Software Operating Equipment FORTRAN·80 (Product Code MDS·301) Required Hardware Intellec' Microcomputer Development System RUNNING ISIS Documentation Package 2920 Assembly User's Guide (9800987) 2920 Simulator User's Guide (9800988) 2920 Signal Processing Application Compiler User's Guide (121529) Required Software ISIS·II Diskette Operating System Optional Hardware Shipping Media Line Printer Universal PROM Programmer Flexible Diskettes ORDERING INFORMATION Product Code Description MCI·20·SPS 2920 Software Support Package Includes 2920 Signal Processing Application Software/Compiler and 2920 AssemblerlSimilator Software 3-135 AFN-01386A intJ MCS e -48 DISKETTE-BASED SOFTWARE SUPPORT PACKAGE • Extendslntellec microcomputer development system to support Mcs-48 development • Takes advantage of powerfullSIS-1i file handling and storage capabilities • Provides assembler output in standard Intel hex format • MC5-48 ....mbler provides conditional assembly and macro capability The MCS-48 assembler translates symbolic 8048 assembly language instructions into the appropriate machine operation codes, and provides both conditional and macroassembler programming. Output may be loaded either to an ICE-49 module for debugging or into the iUP Universal PROM Programmer for 8748 PROM programming. The MCS-48 assembler operates under the ISI8-11 9perating system on Intel Development systems. @INTEL CORPORATION, 1983 MAY 1983 3-136 AFN·00619D inter MCS·48 Table 1. Sample MCS-48 Dlskett.Based FUNCTIONAL DESCRIPTION The MCS-48 assembler translates symbolic 8048 assembly language instructions into the appropriate machine operation codes. The ability to refer to program addresses with symbolic names eliminates the errors of hand translation and makes it easier to modify programs when adding or deleting instructions. Conditional assembly permits the programmer to specify which portions of the master source document shoul,d be Included or deleted in variations on a basic system design, such as the code required to handle optional external devices. Macro capability allows the programmer use of a single label to define a routine. The MCS-48 assembler will assemble the code required by the reserved routine whenever the macro label is inserted In the text. Output from the assembler is in standard Intel hex format. It may be either loaded directly to an in-circuit emulator (ICE-49) module for integrated hardware/software debugging, or loaded into the iUP Universal PROM Programmer for 8748 PROM programming. A sample assembly listing is shown in Table 1. ISIS 118048 MA,CROASSEM8LER VI 0 lOC OBJ ,DECIMAL AODITION ROUTINE ADO BCD NUMBER AT LOCATION 6ETA TO eCD NUMBER AT ALPHA WITH .RESULT IN ALPHA LENGTH OF NUMBER IS COUNT'DIGIT ,PAIRS 'ASSUME 80TH 8ETA AND ALPHA ARE SAME LENGTH AND HAVE EVEN NUMBER OF DIGITS OR MSO IS 0 IF 0001 INIT AUGNO.AOONO eNT FlO 'AUGNO Rl lAOONO , " 00'''' 00' " 0032 1. "" " BETA 15 COUNT 13 0100 0102 OHM 0106 88IE 6928 8A32 91 0101 0106 0109 FO TI 57 OIOA AI ALPHA 19+L1 22 010818 OIDe 19 0100 EA07 USER SYMBOLS ,au ,au ,au 0'0 "" ". ". " "" "" "'" R2,ICNT '00" ALPHA BETA COUNT "0' FlO IALPHA RltBET" 1'12 'COUNT C MO' MO' C," lP ,"'" INIT MO' ACor: " MO' ONC 'NC Dmz 'NO A @"" A @Rt A @"" "'" R~ LP ALPHA OOOte U 0102 ASSEM8l Y COMPLETE NO ERRORS ALPHA 1311 The MCS 48 assembler supports the 8048, 8049. 8050, 8020, 8021 , 8022, 8041 and 8042. The MCS 48 assembler can also support CMOS versions of the 8048 family. 17 8ETA 14' COU"1T 151 \1 11 17 Ll 1. '!WI' LP 2211 28 SPECIFICATIONS Operating Environment Documentation Package (All) Title.s of: Intel Microcomputer Development Systems (Series II, Series III/Series IV) Intel Personal Development System User Guides Operating Instructions Reference Manuals Ordering Information SUPPORT: Part Number Hotline Telephone Support, Software Performance Reports (SPR), Software Updates, Technical Reports, Monthly Newsletters are available. Description MCS-48 Disk Based Assembler MDS-D4S' Requires Software License *MDS is an ordering code only and is not used as a product name or trademark. MDS is a registered trademark of Mohawk Data Sciences Corporation. 3-137 AFN-00619D 8051 SOFTWARE PACKAGES PLlM51 Software Package Contains the following: • PL/M51 Complier which Is designed to support all phases of software Implementation .. RL51 Linker and Relocator which enables programmers to develop software In 'a modular fashion • LlB51 Librarian which lets programmers create and maintain libraries of software object modules 8051 Software Development Package Contains the following: • 8051 Macro Assembler which gives symbolic access to 8051 hardware features • RL51 Linker and Relocator program which links modules generated by the assembler • CONV51 which enables software written for the MCS@ ·48 family to be up graded to run on the 8051 • LlB51 Librarian which lets programmers create and maintain libraries of software object modules LEGEND D 101 O - ~J:~O:::~':=:OOLS Me...., SOFTWARE TOOLS USER-CODED .soFTWARE Figure 1. MCS®·51 Program Development Process Intel Corporation Assumes No Responsibility for the Use of Any CirCUitry Other Than Circuitry Embodied in an Intel Product. No Other Circuit Patent Licenses are Implied. Information Contained Herein. Supercedes Previously Published Specifications On These Devices From Intel. © INTEL CORPORATION, 1983 MARCH 1984 3-138 ORDER NUMBER: 162771.002 inter 8051 SOFTWARE PACKAGES PUM 51 SOFTWARE PACKAGE • High-level. programming language for the Intel MCS®-51 single-chip microcomputer family • Produces relocatable object code which is linkable to object modules generated by all other 8051 translators • Extends high-level language programming advantages to microcontroller software development • Improved reliability, lower maintenance costs, increased programmer productivity and software portability • Compatible with PL/M 80 assuring MCS®-80/85 design portability • Enhanced to support boolean processing • Tailored to provide an optimum balance among on-chip RAM usage, code size and code execution time • Includes th" linking and relocating utility and the library manager • Supports all members of the Intel MCS®-51 architecture • Allows programmer to have complete control of microcomputer resources PL/M 51 is a structured, high-level programming language for the Intel MCS-51 family of microcomputers. The PL/M 51 language and compiler have been designed to support the unique software development requirements of the single-chip microcomputer environment. The PL/M language has been enhanced to support Boolean processing and efficient access to the microcomputer functions. New.compiler controls allow the programmer complete control over what microcomputer resources are used by PL/M programs. PL/M 51 is largely compatible with PLIM 80 and PL/M 86. A significant proportion of existing PL/M software can be ported to the MCS-51 yvith modifications to support the MCS-51 architecture. Existing PL/M programmers can start programming for the MCS-51 with a small relearning effort. PL/M 51 is the high-level alternative to assembly language programming for the MCS-51. When code size and code execution speed are not critical factors, PL/M 51 is the cost-effective approach to developing reliable, maintainable software. The PL/M 51 compiler has been designed to support efficiently all phases of software implementation with features like a syntax checker, multiple levels of optimization, cross-reference generation and debug record generation. LEGEND D 101 O INTEL DEVELOPMENT TOOLS AND OTHER PRODUCTS MC$-51
SOFTWARE
TOOLS

USERoCODED
SOFTWARE

Figure 2.

PL/M51 Software Package

3-139

AFN-GOO47C

inter

8051 SOFTWARE PACKAGES

PU'-4 51 Compiler
FEATURES

Interrupt Handling

Major features of the Intel PL/M 51 compiler and
programming language include:

A procedure may be defined with the INTERRUPT
attribute. The' complier will generate code to save
and restore the processor status, for execution of the
user-defined int~rrupt handler routines.

Structured Programming
PL/M source code is developed in a series of modules, procedures, and blocks. Encouragingprogra'm
modularity in this manner makes programs more
readable, and easier to maintain and debug. The
language becomes more flexible, by clearly defining
the scope of user variables (local to a private procedure, for example).

Compiler Controls
The PL/M 51 compiler offers controls that facilitate
such features as:
-Including additional PLIM 51 source files from
disk
-Cross-reference
-Corresponding assembly language code in the
listing file

Language Compatiblity
PL/M 51 object modules are compatible with object
modules generated by all other MCS-51 translators.
This means that PL/M programs may be linked to
programs written in any other MCS-51 langlJage.
Object modules are compatible with In-Circuit
Emulators and Emulation Vehicles for MCS-51 processors; the DEBUG compiler control provides these
tools with symbolic debugging capabilities.

The PL/M 51 compiler-takes' full advantage of
program addressing with the ROM (SMALL/
MEDIUM/LARGE) control. Programs with less than 2
,KB co~e space can use the SMALL or MEDIUM option to generate optimum addressing instructions
Larger programs can address over the full 64 KB
range.

Supports Three Data Types .
PL/M makes use of three data types for various applications. These data types range from one to sixteen bits and facilitate various arithmetic, logic, and
-Bit: a binary digit
-Byte: S-bit unsigned number or,
-Word: 16-bit unsigned number.
Another powerful facility allows the use of BASED
variables that map more than one variable. to the
same memory location. This is especially useful for
passing parameters, relative and absolute addressing, and memory allocation.

Code Optimization
The PL/M 51 compiler offers four levels of optimization for significantly reducing overall program size.
-Combination or "folding" of constant expressions;
"Strength reductions" (a shift left rather than mUltiply by 2)
-Machine code optimizations; elimination of superfluous branches
-Automatic overlaying of on-chip RAM variables
-Register history: an off-Chip variable will not be
reloaded if its value is available in a register.

Error Checking
1\No Data Structuring Facilities
PL/M 51 supports two data structuring facilities.
These add flexibility to the referencing of data stored
in large groups.
,-Array: Indexed list of same type data elements
-Structure: Named collection of same or different
type data elements
-Combinations of Both: Arrays of structures or
structures of arrays.

3-140

The PL/M 51 compiler has a very powerful feature to
speed up compilations. If a syntax or program error'iS
detected, the compiler will skip the code generation
and optimization passes. This usually yields a 2X
performance increase for compilation of programs
with errors.
A fully detailed set of programming and compilation
error messages is provided by the compiler and
user's guide.

AFN-00047C

inter

8051 SOFTWARE PACKAGES

BENEFITS

Lower Development Cost

PUM 51 is designed to be an efficient, cost-effective
solution to the special requirements of MCS-51 Microsystem Software Development, as illustrated by
the following benefits of PL/M use:

Increases in programmer productivity translate immediately into lower software development costs because less programming resources are required for a
given programmed function.

Increased Rellabllty

Low Learning Effort
PL/M 51 is easy to learn and to use, even for the
novice programmer.

Earlier Project Completion
Critical projects are completed much earlier than
otherwise possible because PL/M 51, a structured
high-level language, increases programmer
productivity.

PL/M 51 is designed to aid in the development of
reliable software (PL/M programs are simple
statements of the program algorithm). This substantially reduces the risk of costly correction of errors in
systems that have already reached full production
status, as the more simply stated the program is, the
more likely it is to perform its intended function.

Easier Enhancements and Maintenance
Programs written in PL/M tend to be selfqocumenting, thus easier to read and understand.
This means it is easier to enhance and maintain
PL/M programs as the system capabilities expand
and future products are developed.

RL51 Unker and Relocator
• Links modules generated by the
assembler and the PL/M complier

• Enables modular programming of
software-efficient program
development

• Locates the linked object to absolute
memory locations

• Modular programs are easy to
understand, maintainable and reliable

The MCS-51 linker and relocator (RL51) is a utility which enables MCS-51 programmers to develop software in a
modular fashion. The utility resolves all references between modules and assigns absolute memory locations to
all the relocatable segments, combining relocatable partial segments with the same name.
With this utility, software can be developed more quickly because small functional modules are easier to
understand, design and test than large programs.
The total number of allowed symbols in user-developed software is very large because the assembler number of
symbols' limit applies only per module, not to the entire program. Therefore programs can be more readable
and better documented.
•
Modules can be saved and used on different programs. Therefore the software investment of the customer is
maintained.
RL51 produces two files. The absolute object module file can be directly executed by the MCS-51 family. The
listing file shows the results of the link/locate process. ,

3-141

AFN..ocJ047C

805.1 SOFTWARE PACKAGES

LlB51 Ubrarian
The LlB51 utility enables MCS-51 programmers to
create and maintain libraries of software object modules. With this utility, the customer can develop standard software modules and place them in libraries,
which programs can access through a standard interface. When using object libraries, the linker will

call only object modules·that are required to satisfy
external references.
Consequently, the librarian enables the customer
to port and reuse software on different projects
-thereby maintaining the customer's software
investment.

SPECIFICATIONS

Documentation Package

Operating Environment

PL/M 51 User's Guide
MCS-51 Utilities User's Guide

All Intel Microcomputer Development Systems or
Intel Personal Development Systems

OR.DERING INFORMATION

SUPPORT:

Part Number

Description

iMDX 352

PL/M 51 Software
Package

Hotline Telephone Support, Software Performance Report (SPR), Software Updates, Technical Reports, and
monthly Technical Newsletters are available.

3-142

AFN·OOO47C

8051 SOFTWARE PACKAGES

8051 SOFTWARE DEVELOPMENT PACKAGE
• Symbolic relocatable assembly
language programming for 8051
mlcrocontrollers

• Macro Assembler features conditional
assembly and macro capabilities

• Extends IntelleC® Microcomputer
Development System to support 8051
program development

• CONV51 Converter for translation of
8048 assembly language source code
to 8051 assembly language source
code

• Produces Relocatable Object Code
which is linkable to other 8051 Object
Modules

• Provides upward compatibility from
the MCS-48™ family of single-chip
microcontrollers

• Encourage modular program deSign
for maintainability and reliability

The 8051 software development package provides development system support for the powerful 8051 family of single
chip microcomputers. The package contains a symbolic macro assembler and MCS-48 source code converter.
The assembler produces relocatable object modules from 8051 macro assembly language instructions. The object
code modules can be linked and located to absolute memory locations. This absolute object code may be used to pro·
gram the 8751 EPROM version of the chip. The assembler output may also be debugged using the ICE-51TM in·circuit
emulator.
The converter translates 8048 assembly language instructions into 8051 source instructions to provide software compatibility between the two families of microcontrollers.

•

..:;s~,

A'\hUIB~

1«14",,, 11%1
Y tA...  Microcomputer

Provides software support for many
and data allocation

Development Systems
• 8051
hardware features

•

capabilities
Assembler supports symbol
• Symbolic
table, cross-reference, macro

Produces object file, listing file and
error diagnostics

capabilities, and conditional assembly

The 8051 Macro Assembler (ASM51) translates symbolic 8051 macro assembly language modules into linkable and
locatable object code modules. Assembly language mnemonics are easier to program and are more readable than
binary or hexadecimal machine Instructions. By allowing the programmer to give symbolic names to memory locations
rather than absolute addresses, software design and debug are performed more quickly and reliably. Furthermore,
since modules are linkable and relocatable, the programmer can do his software In modular fashion. This makes programs easy to understand, maintainable and reliable.
The assembler supports macro definitions and calls. This is a convenient way to program a frequently used code
sequence only once. The assembler also provides conditional assembly capabilities.
Cross referencing is provided In the symbol table listing, showing the user the lines in which each symbol was defined
and referenced.
'
ASM51 provides symbolic access to the many useful addressing features of the 8051 architecture. These features include
referencing for bit and byte locations, and for providing 4-bit operations for BCD arithmetic. The assembler also provides symbolic
access to hardware registers, 110 ports, control bits, and RAM addresses. ASM51 can support ail members of the 8051 family.
Math routines are enhanced by the MUltiply and DIVide instructions.
If an 8051 program contains errors, the assembler provides a comprehensive set of error diagnostics, which are included in the
assembly listing or on another file. Program testing may be performed by using the IUP Universal Programmer and iUP F87/51
personality module to program the 8751 EPROM version of the chip.
ICE51 and EMV51 are available for program debugging.

RL51 LINKER AND RELOCATOR PROGRAM
• Links modules generated by the
assembler

• Enables modular programming of .software for efficient program development

• Locates the linked object to absolute
memory locations

• Modular prOgrams are easy to
understand, maintainable and reliable

The 8051 linker and relocator (RL51) is a utility which enables 8051 programmers to develop software In a modular
fashion. The linker resolves all references between modules and the relocator ass,lgns absolute memory locations to
all the relocatable segments, combining relocatable partial segments with the same name.
With this utility, software can be developed more quickly because small functional modules are easler to understand,
design and test than large programs.
The number of symbols in the software is very large because the assembler symbol limit applies only per module not
the entire program. Therefore programs can be more readable and better documented.
Modules can be saved and used on different programs. Therefore the software Investment of the customer is maintained.
RL51 produces two files. The absolute object module file can be directly executed by the 8051 family. The listing file
shows the results of the IInkilocate process.

3-144

AFN.QOO47C

inter

8051 SOFTWARE PACKAGES

CONV51
8048 TO 8051 ASSEMBLY LANGUAGE
CONVERTER UTILITY PROGRAM
• Enables software written for the
MC\$-48TM family to be upgraded to run
on the 8051
• Maps each 8048 Instruction to a corre·
sponding 8051 Instruction

• Preserves comments; translates 8048
macro definitions and calls
• Provides diagnostic Information and
warning messages embedded In the
output listing

The 8048 to 8051 Assembly Language Converter is a utility to help users of the MCS-48 family of microcomputers
upgrade their deisgns with the high performance 8051 architecture. By converting 8048 source code to 8051 source
code, the software investm~nt developed for the 8048 is maintained when the system is upgraded.
The goal of the converter (CONV51) is to attain functional equivalence with the 8048 code by mapping each 8048
instruction to a corresponding 8051 instruction. In some cases a different instruction is produced because of the
enhanced instruction set (e.g., bit CLR instead of ANL).
Although CONV51 tries to attain functional equivalence with each instruction, certain 8048 code sequences cannot be
automatically converted. For example, a delay routine which depends on 8048 execution speed would require manual
adjustment. A few instructions, in fact, have no 8051 equivalent (such as those involving P4-P7). Finally, there are a
few areas of possible intervention such as PSW manipulation and interrupt processing, which at least require the user
to confirm proper translation. The converter always warns the user when it cannot guarantee complete conversion.
CONV51 produces two files. The output file contains the ASM51 source program produced from the 8048 instructions.
The listing file produces correlated listings of the input and output files, with warning messages in the output file to
point out areas that may require users' intervention in the conversion.

LlB51 LIBRARIAN
The LlB51 utility enables MCS-51 programmers to create and maintain libraries of software object modules. With
this utility, the customer can develop standard software modules and place them in libraries, which programs can
access through a standard interface. When using object libraries, the linker will call only object modules that are
required to satisfy external references.
Consequently, the librarian enables the customer to port and reuse software on different projects-thereby maintaining the customer's software investment.

-3-145

AFN-GOO47C

inter

8051 SOFTWARE PACKAGES

SPECIFICATIONS
OPERATING ENVIRONMENT

Docum~~tatlon

All Intel Microcomputer Development Systems or Intel
Personal Development System

Package:

MCS-51 Macro Assembler User's Guide
MCS-51 Utilities User's Guide for 8080/8085 Based Development System
MCS-51 8048-to-8051 Assembly Language Converter
Operating Instructions for ISIS-II Users

ORDERING INFORMATION

SUPPORT:

Part Number

Description

MCI-51-ASM

8051 Software Development
Package

Hotline Telephone Support, Software Performance
Reporting (SPR), Software Updates, Technical Reports,

3-146

AFN-G0047C

iRMXTM 51
• Software tool for family of 8051
microcontroller based applications

• Reliable
• Simple user interface

• Real-time, multitasking executive
• Supports remote task communication
• Small - 2.2K Bytes

• Compatible with BITBUSlMlDistributed
Control Modules (iDCM) product line:
iSB)(lM 344 & iRCB 44/10 boards

The iRM)(TM 51 Executive is a compact, easy to use, software tool for development and implementation
of applications built on the high performance 8-bit family of 8051 microcontrollers. A few members
of this expansive family are the 8051,8044, and 8052 microcontrollers. Like the 8051 family, the iRMX 51
Executive incorporates many features that make it exceptionally well suited for real-time control applications requiring manipulation and scheduling of more than one job, and fast response to external stimuli.
The 8051 microcontroller family is the family of choice for applications such as: data acquisition and
monitoring, process control, robotics, and machine control. Using the iRMX 51 Executive for a foundation can significantly reduce applications development time. Also, the iRMX 51 Executive fully supports
Intel's BITBUSTM microcontroller interconnect expressly designed for reliable high performange realtime control.

Figure 1. Structure Diagram

3-147

ORDER NUMBER 230972-001

iRMXTM 51

ARCHITECTURE

ling Heater 1: The iRMX 51 Executive recognizes
three different task states as one of the mechanisms to accomplish scheduling of up to eight
tasks. Figure 2 illustrates the different task states
and their relationship to one another.

Real-time control applications must be responsive
to the external environment and typically involve
the execution of more than one function (task or
set of tasks) in response to different external
stimu1i. Control of an industrial drying process is
an example. This process could require monitoring
of multiple temperatures and humidity; control of
fans, heaters, and motors that must respond accordingly to a variety of inputs. The iRMX 51
Executive fully supports applications requiring
response to stimuli as they occur ie. in real-time.
This real-time response is supported for multiple
tasks often needed to implement a control application.

The scheduling of tasks is priority based. The
user can prioritize tasks to reflect their relative
importance within the overall control scheme.
For instance, if Heater 1 must go off line prior to
Heater 2 then the task associated with Heater 1
shutdown could be assigned a higher priority ensuring the correct shutdown sequence. The RQ
WAIT system call is also a scheduling tool. In this
example the task implementing Heater 2 shutdown could include an instruction to wait for completion of the task that implements Heater 1
shutdown.

Some of the facilities precisely tailored for development and implementation of real-time control
application systems provided by the iRMX 51 Executive are: task management, interrupt handling,
message passing, and when intergrated with
communications support, message passing with
different microcontrollers. Also, the iRMX 51 Executive is driven by events: interrupts, timers,
and'messages ensuring the application system
always responds to the environment appropriately.

The iRMX 51 Executive allOWS for PREEMPTION
of a task that is currently being executed. This
means that if some external event occurs such
as a catastrophic failure of Heater 1, a higher
priority task associated with the interrupt, message, or timeout resulting from the failure will
preempt the running task. Preemption ensures
the emergency will be responded to immediately.
This is crucial for real-time control application
systems.

A task is a program defined by the user to execute a particular control function or functions.
Multiple programs or tasks may be required to
implement a particular function such as 'control-

I

Interrupt Handling
The iRMX 51 executive supports sixteen interrupt sources as shown in Table 1. Four of these
interrupt sources, excluding timer 0, can be as-

Running Task Executes ROWAIT or RODELETE

lk-----:::---:-=-----;:-~:_:7=:-;:::;:-_:::;_--__j1

RUNNING

1

Event Occurs Assoc. wlAsleep Task wi
Higher Priority Than Running Task.

Event Occurs Assoc.
wi Asleep Task wi
Lower Priority
Than Running

I

Event Occurs Assoc. wi Asleep Task wi
Higher Priority Than Running Task

ASLEEP

Ik-----=--:---=--:--=-~__:=:-:-:-:;----------"
Running Task Executes ROWAIT

Figure 2. Task State Transition Diagram

3-148

230972-001

iRMXTM 51

signed to a task. When one of the interrupts
occurs the task associated with it becomes a running task (if it were the highest priority task in a
ready state). In this way, the iRMX 51 Executive
responds to a number of internal and external
stimuli including time intervals designated by the
user.
Table 1. iRMXTM 51 Interrupt Sources
INTERRUPT SOURCE

INTERRUPT NUMBER

External Request 0

OOH

Timer 0

01H

External Request 1

02H

Timer 1

03H

Internal Serial Port 1

04H

Reserved

05H

Reserved

06H

Reserved

07H

Reserved

OSH

Reserved

09H

Reserved

OAH

Reserved

OBH

Reserved

OCH

Reserved

OOH

Reserved

OEH

Reserved

OFH

the next part of the analysis. The tasks could
continue to move between one another.

The iRMX 51 Executive system calls can support
communication to tasks on remote controllers.
This feature makes the iRMX 51 Executive ideal
for applications using distributed architectures.
Providing communication support saves significant application development time and allows for
more effective use of this time. Intel's iDCM product line combines hardware and software to
provide this function.
In an iDCM system, communication between
nodes occurs via the BITBUS microcontroller
interconnect. The BITBUS microcontroller interconnect is a high performance serial control bus
specifically intended for use in applications built
on distributed architectures. The iRMX 51 Executive provides BITBUS support.

BITBUSTM/iDCM COMPATIBLE

Message Passing
The iRMX 51 Executive allows tasks to interface
with one another via a simple message passing
facility. This message passing facility can be
extended to different processors when communications support is integrated within a BITBUS/
iDCM system, for example. This facility provides
the user with the ability to link different functions
or tasks. Linkage between tasks/functions is typically required to support development of complex
control applications with multiple sensors (inputs
variables) and drivers (output variables). For instance, the industrial drying process might require
a dozen temperature inputs, six moisture readings,
and control of: three fans, two conveyor motors,
a dryer motor, and a pneumatic conveyor. The
data gathered from both the temperature and
humidity sensors could be processed. Two tasks
might be required to gather the data and process
it. One task could perform a part of the analysis,
then include a pointer to the next task to complete

A pre-configured version of the