1985_Intel_Software_Handbook 1985 Intel Software Handbook

User Manual: 1985_Intel_Software_Handbook

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

Download1985_Intel_Software_Handbook 1985 Intel Software Handbook
Open PDF In BrowserView 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:
Add appropriate postage
and handling to subtotal

PRICE

QTY.

Your Local Sales Tax _ _ _ __

10% U.S.
20% Canada
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
TASK

TASK

TASK

PHYSICAL
FILE
DRIVER

.sac·
215
DEVICE
DRIVER

TASK

TASK TASK

,II

TASK

TASK

TASK TASK

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

TASK

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

Receive Control
(no waiting)

0.26

0.19

I

BACKGrOUND

APPliCATION

-1

I

WINCHESTER
DISK

DRIVER

I

FLOPPY
DISK

DRIVER

NUCLEUS
PROM

BOOTSTRAP LOADER

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

Suspend Task

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*

Bootstrap Loader
Nucleus

10.5K

1.5K
24K

BIOS
Application Loader
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,
©INTEL CORPORATION, 1984

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

MULTITASKING, REAL-TIME
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
END INIT TASK

SEGMENT GROUP
CREATE SEGMENT
DELETE SEGMENT

TASK GROUP
CREATE TASK
DELETE TASK
SUSPEND TASK
RESUME TASK
SLEEP
GET TASK TOKENS
SET PRIORITY

REGION GROUP
CREATE REGION
DELETE REGION
sEND CONTROL
RECEIVE CONTROL
ACCEPT CONTROL

MAILBOX GROUP
CREATE MAILBOX
DELETE MAILBOX
SEND MESSAGE
RECEIVE 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
addressability
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

ADO

INT1

INTOySS

A7- A O LOCAL (+SYS)

Al~

~A8

~
"4 l\f
A7

PROCESSOR DATA BUS

015--00

READY

V

<---;:,.

I

e-

»

l'
....

DT/A

=r--J

~

~

~

~I-

;L-

\r

.

~

ADDRESS

So !\.j--

illi

N . C - DELAY

-

!J1..----

BAUD

r

BUS

;,.

A19-A16
BHE i+-

o SERIAL INT

r

-

INT
ACKU-

SYSTEM
ADDRESS

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---

READY

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

Additional System Requirements

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
application tasks.

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

BHE.AD 1s- AD o.

+

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

-

ADDRESS VALID

CK
TSACK

'fJIJNX
-l r-TCSAK
Y

~

ADDRESS VALID

I
TSACK

I

H
~

FLOAT

I

WRITE DATA VALID

I

REA DCVCLE

ACK

~

I
I--

AD, s-ADo

ADo

I

TDseL

I

WRIT E CYCLE

TClDV

~
READ DATA VALID

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
would degrade some.
'

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

AD15

40

4Q

B

AD14

3D

30

A

748373

74S138

}DECODE

1mll:I'
lit:R

READY
SYSTEM
ACKNOWLEDGE

Vee

READY

-

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) •
CALL RGSDELETE.STASKCO.@TIMESEXCEPTSCODE).
END TIME.TASK.

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
single-threaded (as opposed to multitasking) programs,
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?

CRTSounTASK
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,

CALL ROSRESUME'TASK( INITSTASK,TOKEN, @MESSAQESEXCEPTSCODE),
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

CRT.OUT.TASK,

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
. be received, while the task queue contains tasks
waiting for messages? Ignore the possibility that
this may happen momentarily during the implementation of either routine. If you think of any'
such circumstances, please contact the author.

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

Using Bootstrap Loader
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

Using Bootstrap Loader
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
cmask
CMASK 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»
#define BMASK 01777
1* BSIZE-l *1
#define BSHIFT 10
1* LOG2(BSIZE) *1
#define NMASK 0377
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
#define DCMASK 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]; } *
physadr;
typedef struct { unsigned short off;
unsigned short seg;} segadr;
daddr t;
typedef long
typedef char *
caddr-t;
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

SPLOMASK

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
caddr t b addr;
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
daddr t *b daddr;
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
B-READ
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*

non-read pseudo-flag *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 nread;
long nreada;
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
caddr t
t linep; 1* aux line discipline pOinter *1
caddr-t
t-addr;
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
MLCREAD
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,
alive-? "found" : "NOT found" );
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(lDBbase->PIC[O] .msr, HASKINT)
outb(lDBbase->PIC[l] .msr, HASKINT)
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
added console programming
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 */
outb(tp->t addr+1,SHANGUP);
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;
tp->t addr = (caddr t)aDBbase->USART[unlt] .data;
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 */
outb«tp->t addr +1). SANSWER);
/* turn usart (dtr) on */
if (modem) C
if(modem a MODEMWAIT)
/* mask detect leaving aqua */
while«inb«tp->t addr +1» a DTRON) == 0)
sleep«caddr=t)ai534wakeup.TTIPRI),
outb(aDBbase->PIC[l] .msr . «inb(aDBbase->PIC[l] msr» a
(-(Ox10« unit» aTIMERGO».
/*unmask carrier/detect */

==

}

outb(aDBbase->PIC[O] .msr . «inb(aDBbase->PIC[O] .msr»
/* 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;
register mask;
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;
outb(tp->t_addr +l,SHANGUP);
}

}

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));
outb(lDBbase->PIC[O] msr, mask);
1* RxRDY, TxRDY off *1
splx(s);

tp->t_addr = (caddr_t) 0,

}

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.
** TITLE: i534read
** CALL:
**

i634read (dev)

INTERFACES: xenix

** CALLS:

ttread

** History:
*
*1

2-187

260041-001

AP-184

i534read (dev)
dev_t
dey;
{

register struct tty *tp;
register int unit;
,
unit=mlnor(dev) a MINORMSK;
tp = ai534tty[unit);
(*linesw[tp->t_line] I_read) (tp);
}

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
status,mask;
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;
wakeup«caddr_t)~tp->t_outq);

}

}
}
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
wakeup«caddr_t)li534wakeup);
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

mask =

lnb(tDBbase->PIC[l] .msr}
! (l«status);'
outb(tDBbase->PIC[11.msr, mask};
1* carrler detect off *1
outb«tp->t_addr +l},SHANGUP};
}

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) {'
outb"{tp->t addr, c};
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)
caddr t addr;
{
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 ..... .
Inittask ............................. .
Onetask ............................ .
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
Reference Manual for more information. Related
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
shows multitasking, creating three tasks. It
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.

Task Scheduling
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-----..

READY

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
task now becomes the ready task with the highest
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
parameter. Inittask calls Onetask (Appendix B)
which does all the work of the application. The
submit file which links and locates the user job is
given in Appendix D.

INITTASK
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.

ONETASK
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
now the highest priority ready task.
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
linked and located.
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:
Tasks:
B491
Mailboxes:
Semaphores:
Regions:
Segments:
Extensions:
Composites:

.vk
Ready Tasks:
Sleeping Tasks:

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 tasks
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)

Deadlock
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

Causes deadlock:
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

mainStask:

PROCEDURE REENTRANT PUBLICi

281

2

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

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

282

2

DECLARE taskSflags
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;
END onetask;

/* slJspend myself */

MODULE INFORMATION:
CODE AREA SIZE
= 0554H
CONSTANT AREA SIZE = 0023H
VARIABLE AREA SIZE = OOOOH
MAXIMUM STACK SIZE = 0040H
1520 LINES READ
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')
tasks: DO;

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

task~ mailbox
*/
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

sys RAM addr

system beginning dddress

sys RAM Sile

system memory size

sys stack SllP

system stack size

user RAM addr

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
had second thought!l.

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

"The tasks
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
decide which tasks
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.
of reading.
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

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

PC • INTEGRATION SERIES
Synchronizing tasks. Tasks are asynchronous.
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'

Ada

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,
©INTEL CORPORATION. 1983
MAY 1983
·Mlcrosoft & Multiplan are trademarks of Microsoft Corp
ORDER NUMBER:210767-002

3-15

MICROSOFT MULTIPLAN SPREADSHEET

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

MICROSOFT MULTIPLAN SPREADSHEET

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
Provides helpful information about Multiplan.
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

MICROSOFT MULTIPLAN SPREADSHEET

Table 1. Multiplan Commands
ALPHA
BLANK
COPY DOWN
COPY FROM
COPYRIGHT
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 LOAD
TRANSFER OPTIONS
TRANSFER RENAME
TRANSFER SAVE
VALUE
WINDOW BORDER
WINDOW CLOSE
WINDOW LINK
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

MICROSOFT MULTIPLAN SPREADSHEET

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,
\ choose Load.
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

MICROSOFT MULTIPLAN SPREADSHEET

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

MICROSOFT MULTIPLAN SPREADSHEET

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
loaded.

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

MICROSOFT MULTIPLAN S,PREADSHEET

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

Multiplan spreadsheet program
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-Intel$ CRT

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 SET$INTERRUPT, 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
Addressing Modes

-

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

LINK 86/88
• 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
Modules Being Linked

• 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:
ADD:
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
Hexadecimal Format

• 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
Loading by a Symbolic Hexadecimal
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.

© INTEL CORPORATION,

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

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-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

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 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,
and addressing functions:

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,
and addressing functions:

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
cross-statement load/store.

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

Addressing Control

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.

Requires Software License

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
license signed.

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.

Program Addressing Control
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
address functions:
-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
Requires Software License

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
• addressing
and data allocation

Development Systems
Gives symbolic access to powerful
• 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,
Monthly Newsletter available.

'Requires Software License

3-146

AFN-G0047C

iRMXTM 51
REAL-TIME MULTITASKING EXECUTIVE
• 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
Real-time and Multitasking

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.

Task Management
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

READY

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
Task

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.

REMOTE TASK COMMUNICATION
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