AP 130_Using_Operating_System_Firmware_Components_to_Simplify_Hardware_and_Software_Design_Mar82 130 Using Operating System Firmware Components To Simplify Hardware And Software Design Mar82
User Manual: AP-130_Using_Operating_System_Firmware_Components_to_Simplify_Hardware_and_Software_Design_Mar82
Open the PDF directly: View PDF 
.
Page Count: 56
| Download | |
| Open PDF In Browser | View PDF |
intel~
APPLICATION
NOTE
AP-130
March 1982
© INTEL CORPO RATION,1982
ORDER NUMB
MARCH 1982
ER: 210295-001
John Wharton is currently the Technical Director of Applications Research, Sunnyvale, California. Please direct any
questions or comments to your local FAE (field applications engineer).
CP/M and CP/M-B6 are trademarks of Digital Research Incorporated.
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.
The following are trademarks of Intel Corporation and may only be used to identify Intel Products:
BXP, CREDIT. i. ICE. iCS. im , iMMX. Insite, Intel, intel, Intelevision,
Intellec, iOSp, iRMX, iSBC, iSBX, Library Manager, MCS,
Megachassis, Micromainframe, Micromap, Multimodule,
Plug-A-Bubble, PROMPT. RMX/80, System 2000 and UPI.
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 .
• MUL TIBUS is a patented Intel bus.
Additional copies of this manual or other Intel literature may be obtained from:
Intel Corporati on
Literature Department SV3-3
3065 BowersAvenue
Santa Clara, CA 95051
c INTEL CORPORATION, 1982
ii
Using Operating System
Firmware Components
To Simplify Hardware
and Software Design
Contents
INTRODUCTION
EVOLUTION OF PROCESSOR EXTENSIONS ............
2
Real-Time Operating Systems ........................
2
SYSTEM HARDWARE DESIGN .........................
5
Basic Functional Blocks ............................. 5
80130 Pin Functions. .. ... . . .... .... ... . ... . ... ...... 6
Additional System Requirements ..................... 9
Timing Considerations ............................... 10
Example System Design ............................. 12
APPLICATION SOFTWARE DEVELOPMENT . ............ 12
Hardware Initialization ...............................
Simple Time Delays ..................................
Stepper Motor Control ...............................
Real-Time Interrupt Processing .......................
Mutual Exclusion ....................................
Intertask Communication ............................
Segments, Messages, and Mailboxes. . . . . . . . . . . . . . . . ..
Console Command Interpreter ........................
Initialization Task ...................................
Code Translation ....................................
13
15
15
15
17
18
19
20
21
22
SOFTWARE CONFIGURATION AND INTEGRATION . ..... 22
Configuring OSP Support Code ......................
Linking and Locating Application Jobs ................
Creating the Root Job ...............................
Programming EPROMS ..............................
23
24
25
26
SUMMARy ........................................... 27
APPENDIX A. EXAMPLE SYSTEM SCHEMATICS . ....... A-1
APPENDIX B. SOURCE CODE LISTINGS . .............. B-1
APPENDIXC. SYSTEM MEMORY MAP
................ C-1
APPENDIX D. SUPPORT CODE LOCATE MAP .......... D-1
APPENDIX E. APPLICATION JOB LOCATE MAP ........ E-1
APPENDIX F. ROOT JOB LOCATE MAP ................ F-1
iii
AFN-02058A
design system hardware and software to take advantage
of such features.
INTRODUCTION
Intel recently introduced a new set of extensions to its
microprocessor product line. The iAPX 86/30 and
iAPX88/30 Operating System Processors (OSPs) augment the general-purpose instruction set of the wellknown 8086/8088 architecture to include common,
real-time, operating system capabilities. A single
device, the 80130 Operating System Firmware component (OSF), now provides hardware support for functions previously relegated to software.
The 80130 introduces new concepts in the areas of both
hardware and software. At first glance, traditional
component-level hardware designers could feel somewhat intimidated by the esoteric concepts and unfamiliar buzzwords encountered in the software world.
Even the experts in conventional operating system
(OS) design may initially find it strange that what used
to be "soft" software routines are now cast in silicon.
This application note is intended for readers at both
levels. The first section reviews the development of
processor extensions in general and operating system
firmware in particular. Later sections should help you
understand what a real-time operating system can do,
how the 80130 provides these capabilities, and how to
The note also documents a complete (albeit simple)
system, including schematics and listings. The reader
may wish to reconstruct this system to get started with
OSPs. Finally, a step-by-step description of the socalled "configuration" process shows how physical
system parameters are incorporated into the software
as the software is "installed" in memory. Throughout the note are a number of "exercises"-questions
relating to concepts just presented. Please take a
few moments to think about these questions before
reading on.
The reader need not have worked with operating systems previously, though such background would be
helpful. The reader should also know something about
microprocessor hardware-at a minimum, how the
8086 or 8088 devices operate. For simplicity, most of the
software examples are written in PLlM-86, so the
reader should be familiar with PLlM-80 or some other
block-structured language. Finally, be forewarned that
the configuration steps make use of several ISIS utility
programs, including EDIT, SUBMIT, ASM86,
LINK86, and LOC86. Readers who wish to brush up on
any of the above should consult the appropriate Intel
reference manuals.
MAX
MODE
8086
Vss
AD14
AD15
AD14
A015
BHE
A013
A16/S3
AD12
IR7
AD12
AD17/S4
AD11
IR6
AD11
AlB/55
AD10
IRS
AD10
A191S6
AD.
IR4
AD.
ADe
IR3
ADe
MN/Mx
AD7
IR2
AD7
AD
AD6
IR1
AD6
RQ/GfQ
ADS
IRO
ADS
RO/GT1
AD4
INT
AD4
LOCK
AD3
52
AD3
S2
AD2
51
AD2
51
AD1
SO
AD1
SO
ADO
ACK
ADO
050
LlR
NMI
IOCS
SYSTICK
MAX
MODE
8088
Vee
Vee
AD13
MEMeS
I I
INTR
BHE/57 (HIGH)
051
TEST
ClK
DELAY
CLK
READY
Vss
BAUD
Vss
RESET
Figure 1. 8086 and 80130 Pinout Diagrams
AFN-0205eA
AP-130
EVOLUTION OF PROCESSOR
EXTENSIONS
3. Specialized hardware is developed to support the
established functions more simply and effectively
than software alone.
In the early days of micro computing (circa 1974), things
were simple. The first microprocessors comprised just
the central processing unit of a simple computer. Systems built up from these processors were generally
small, dedicated-purpose device controllers-often
replacing the random logic of an earlier design. The
system designer had responsibility for the development
of the hardware and all application software.
In time, everything ends up in silicon.
The second theme is this: different functions should be
implemented in different ways to fit the customer's
needs. "Universal" requirements-like 16-bit
multiplication-are best incorporated into the CPU.
Functions needed only by certain applications-like
high-speed, extended-precision square roots-should
be provided as optional Processor Extensions so that
their expense is incurred only by those who need them.
In keeping with this philosophy, Intel currently offers
several processor extension products (see "What's in a
Name?").
Semiconductor technology has progressed rapidly
since then. Devices have become more sophisticated,
as have the applications in which they are used. System
functions today are more complex than they used to be,
and are demanding more in the way of both system
hardware and software.
What's in a Name?
To help designers cope with this complexity, semiconductor vendors are building increasingly more
"functionality" into their standard product lines.
Whereas the general arithmetic functions of the 8080
and 8085 were limited to addition and subtraction of
eight-bit unsigned (ordinal) values, for example, the
Intel® 8088 and 8086 now add, subtract, multiply, or
divide eight- or 16-bit, signed or unsigned variables
-an obvious improvement.
The 80130 Operating System Firmware (OSF) device is
only the latest member of an extremely flexible family
of Intel microprocessors. Its siblings include the 8086
and 8088 Central Processing Units (CPUs), the 8089110
Processor (lOP), and a floating-point math coprocessor, the 8087 Numeric Processor Extension (NPX).
These individual standard components may be mixed
and matched in numerous ways to create combinations
optimized for widely varying applications.
The evolution of floating-point arithmetic provides another example of technology growth. Initially, designers of numeric and process-control systems each
developed the floating-point arithmetic routines they
needed. Intel eased this task considerably in 1977 when
it introduced a standard floating-point format and a
floating-point arithmetic software library, FPAL-80. In
1978, the iSBC 310 High-Speed Mathematics Unit implemented these same functions with dedicated hardware and executed them an order-of-magnitude faster.
To make it easier to discuss the most common configurations, Intel has defined an "Advanced Processor
Series" (iAPX) numbering scheme, something akin to
those used in the minicomputer and mainframe worlds.
The 8086 CPU by itself, for instance, is called the iAPX
86110. The 8086/8087 combination is dubbed the iAPX
86/20. An 8086/80130 pair has the name iAPX 86/30. The
8086, 8087, and 80130 together would form an iAPX
The 8231A Arithmetic Processor Unit (introduced in
1979) provided similar functionality in one chip at much
lower cost. To accommodate the needs of today's
world, the Intel RealMath™ software standard and the
8087 numeric coprocessor perform 80-bit floating-point
arithmetic for high-performance 8088 and 8086
systems.
When each of these combinations uses an 8088 in lieu
of the 8086, each of the numbers above substitutes
"88" for the "86". An 8088 teamed with an 80130 is
therefore called the iAPX 88/30. Finally, adding an 8089
to any system changes the final zero to a one. So, an
iAPX 88/41 system would be one using the 8088/80871
8089/80130 chip set.
This evolution of floating-point hardware illustrates two
recurring themes in the microcomputer industry. First,
there is a natural trend toward componentization:
Real-Time Operating Systems
86/40.
Let's turn our attention now to the subject of microcomputer operating system software-an area steadily
growing in importance. The trends toward standardized
functions with specialized implementations will become evident.
I. New applications reveal a need for new types of
functionality (in this case, floating-point arithmetic).
2. As common requirements become evident, vendors
develop software to serve these needs.
2
AFN-02058A
AP-130
neously. Unlike the sequential time-sharing of
mainframe OSs, though, the tasks are prioritized. Lowpriority tasks are preempted if any of higher priority
have work to do. The higher-priority task then runs
until it must wait for some external event to occur or no
longer needs the CPU for some other reason. Thus, the
CPU services tasks in their order of importance.
But first, what is an operating system? The phrase
means different things to different people. In 20 words
or less: An OS is a tool, a set of programs or routines
which reduce and simplify the problem of managing
system resources. (Well, 21, actually ... )
Most microcomputer programmers have encountered
single-user diskette operating systems, Intel's ISIS-II®,
and CP/M® and CP/M-86® from Digital Research Incorporated among them. In essence, an OS of this sort is a
collection of run-time subroutines which perform
device 110 operations and give application programs
access to a disk-based file system. Along with these are
routines to supervise the loading and execution of application programs. Historically, this type of OS is
oriented toward user-interactive applications: software
development, business computing, and the like.
A computer controlling factory machinery, for in-.
stance, might perform five separate tasks:
1. Monitor input switches to detect emergency conditions, determine intended operating mode, or update
indicator lights showing machine status;
2. Drive a stepper motor to position a tool;
3. Keep track of the time of day;
4. Send output to the console (e.g., CRT), either in
response to explicit commands or as part of some
other task;
5. Read and process characters entered from a console
keyboard.
In the mainframe world, the goal of an operating system
is to use expensive equipment as efficiently as possible.
Batch processing systems ensure that programs waste
as little CPU time as possible, though each monopolizes
the CPU until it has completed. A time-sharing OS
allots short periodic "slices" of time to each of several
independent users, during which each has access to the
CPU, memory, and other system resources.
These tasks seem largely unrelated, though the first few
may be more important to system operation
than the others. Let's consider some alternate
ways to accomplish these functions with today's
microcomputers.
A step above the traditional time-sliced OS are "realtime, multitasking operating systems." But what is a
"real-time" application? ("Don't all programs execute
in real time?")
Conceptually, the most straightforward approach might
be to dedicate a separate computer to each. The program for each would then be quite simple: an initialization phase followed by an endless loop performing the
dedicated function. Algorithms for the first four tasks
are flowcharted in Figure 2.
A real-time system is one in which the CPU must do
many different things (tasks), all more-or-less simulta-
Figure 2. Flowcharts for Concurrent Machine-Tool Tasks
3
AFN-02058A
AP-130
chips, how would the number of peripheral
devices compare with the number of CPUs?
What's wrong with this approach? Ignoring cost, the
need for multiple CPUs becomes physically unrealistic
for more than a few tasks-60, say, or 600, And tasks
are rarely fully independent; note that the switches
monitored by task 1 could affect task 2, and that tasks 4
and 5 interact with the rest of the system in as yet
undefined ways, So, some sort of communications
would have to be set up between the micros,
In each task, the CPU spends most of its time waiting
for time to pass or for something to happen. One CPU
would be able to implement all five tasks if its time were
properly divided among them. An alternate approach,
then, might be for a single processor to attend to each
task in turn, performing the actions called for by each.
Figure 3 shows a flowchart for this scheme. Only one
CPU is required and the tasks can communicate between themselves and share physical resources like the
console.
Exercise 1. Suppose five tasks are all interrelated.
How many communications channels would have
to be set up between different processors? If each
channel requires two dedicated communication
READ STATE OF
INPUT SIGNALS
WRITE MACHINE STATUS
TO INDICATOR LIGHTS
STep IN APPRO·
PRIATE DIRECTION
INCREMENT TIME-
OF-DAY COUNTERS
OUTPUT MESSAGE
TO CONSOLE
Figure 3. Machine-Tool Tasks Implemented Via Polling Scheme
4
AFN-02058A
A"'-l~U
The problem here is the heavy interaction between
tasks. Before it can be serviced, an important task may
have to wait for many other less critical tasks to complete. This imposes a constraint that each task release
the CPU as quickly as possible. Also, lumping tasks
together obscures the boundaries between them. Initialization sequences must be grouped with each other,
rather than with the sections of code affected. Adding to
or deleting any task may affect the others. It's not clear
how to structure the program such that programmers
could cooperate on such a program.
Until now, that is. The current trend is to integrate as
software and hardware functions into silicon. Intel's
iAPX 432 32-bit MicroMainframe™ system does this
within the CPU. For the 16-bit world, however, Intel
provides a separate chip, the 80130, which contains
operating system firmware as well as timer and interrupt control functions.
What is the 80130 OSF? It is an extremely sophisticated
integrated circuit, fabricated using Intel's highperformance HMOS technology, which contains over
160,000 devices. In one 40-pin package (Figure 4), the
80130 combines several timers, multiple-mode interrupt control logic, and a large control store memory
-plus buffers, decoders and the like-to form the integrated heart of a multitasking operating system.
Compared with the iRMX 86 Nucleus, for example, the
80130 replaces an 8259A PIC, an 8253 PIT, a special
oscillator, 16K bytes' worth of memory, and associated
control logic.
Moreover, the various tasks can interfere with each
other. Suppose on a given pass through the processor
loop, three tasks each send one new character of a
message to the console display screen. The resulting
output would be most interesting.
The third, and optimal approach, would be one which
combined the advantages of the first two approaches,
while avoiding the pitfalls. Each function ofthe overall
system could be designed, written, and tested separately, as in the first approach, yet all the software
would run on a single computer system as in the
second. Tasks could therefore communicate with each
other easily, and share peripherals such as CRTs. This
multitask control and communication function could be
performed largely through software.
The 80130 operates in conjunction with the 8086 CPU.
Together, the two chips are called the iAPX 86/30 aSP.
The same device may be paired just as easily with an
8088 forming the iAPX 88/30. From here on, though,
references to the 8086 or "host processor" apply to
both CPUs. Due to the high speed of HMOS , the 80130
currently runs at system clock rates up to 8 MHz without inserting any wait states. Firmware in the 80130
supports the 35 primitive functions listed in Table 1.
Many of these are discussed in Chapter IV.
The key is finding a way to properly budget CPU time
between the various tasks. Early pioneers of complex,
real-time, control system design found that they needed
special routines, apart from the application tasks themselves, to supervise the execution of application tasks.
It was (at best) an inconvenience for so many engineers
to independently define, design, document, test and
debug software with the same general purpose. At
worst, schedules slipped or projects were cancelled for
the lack of reliable executive software.
SYSTEM HARDWARE DESIGN
The 80130 supports a wide range of system architectures, from compact to quite complex. Most, however,
have in common the functional blocks represented in
Figure 5. After a brief review of iAPX 86/30 systems in
general, we'll examine 80130 requirements in greater
detail.
To help avoid these hazards and free up the designers to
concentrate on more immediate goals, Intel developed
iRMX 80, the first real-time, multitasking, executive
operating system for microprocessors. iRMX 86 was
introduced to the l6-bit world two years later in 1980.
Basic Functional Blocks
In addition to the 80130, the central processing "core"
of a typical asp system would include an 8088 or 8086
operating in maximum mode, an 82843A clock
generator, and an 8288 system controller, all connected
according to the standard rules. More on the 80130specific interconnects later.
Because of the critical real-time nature of such operating systems, they require certain hardware capabilities
in the host system, such as special timer logic clocked at
certain frequencies to measure the passing of time, and
interrupt controllers to monitor assorted asynchronous
events. Combine all this with a handful of memory
chips to house just the as software, and the address
decode and control logic needed by all of the above, and
you'll find you need the equivalent of a single-board
computer system just to support a multitasking
environment.
Address latches (e.g., 8282s or 8283s) are generally
needed to demultiplex the processor address bus for
standard memory devices and for memory and 110
device-select logic. The number (from zero to three
octal latches) depends on the host processor,
memories, and the addressing scheme employed. Data
5
AFN-02058A
AP-130
Table 1. Operating System Primitives Supported by 80130
Task Management
Suspend Task
Resume Task
Sleep
Create Task
Delete Task
Set Priority
Get Task Tokens
Interrupt Management
Set Interrupt
Signal Interrupt
Reset Interrupt
Enter Interrupt
Wait Interrupt
Exit Interrupt
Enable
Disable
Get Level
Intertask Communications and Synchronization
Send Message
Receive Message
Create Mailbox
Delete Mailbox
Free Memory Management/System Partitioning
Create Segment
Delete Segment
Create Job
Misc. Support
Signal Exception
Get Type
Disable Deletion
Enable Deletion
Set O. S. Extension
Get Exception Handler
Set Exception Handler
Mutual Exclusion Control
Receive Control
Accept Control
Send Control
Create Region
Delete Region
transceivers (8286s or 8287s) may also be needed for
increased bus buffering.
80130 Pin Functions
Back to the 80130. Certain pins on the 80130 (inparticular, AD15-ADO) attach directly to the CPU. The AD
pins are bidirectional, accepting addresses from the
host and returning instructions or data. By monitoring
the system clock and status signals, S2-S0, the 80130
can decode the processor status internally and respond
automatically to the appropriate bus cycles. The BHE
input lets the 80130 determine the width of data transfers and distinguishes an 8088 host from an 8086. If you
refer back to Figure 1, you'll notice that these 80130 pin
assignments were selected to simplify P. C. board
layout.
Any complete microprocessor system must also have
some combination ofI/O peripherals and memory, collectively indicated by the box labeled "Local Resources." As we shall see, some of the system RAM
and ROM (or EPROM) must be reserved for OSP itself.
Additional logic decodes the latched address lines to
generate chip-select signals for the memory and I/O
devices.
This note only discusses simple, single-processor systems. More sophisticated architectures may incorporate a multimaster system bus, in addition to a local
processor bus. This would require additional system
controllers, address latches, and bus transceivers for
bus isolation, and address mapping logic (not shown) to
select between the various busses, enable the respective transceivers, generate a System Ready signal, and
so forth. For design information on such techniques,
refer to application note AP-67 in theiAPX 86,88 User's
Manual.
Because of the 80 130's location on the CPU side of any
latches or data transceivers (on what is sometimes
called the "pin bus"), the transceivers (if used) must be
disabled when the 80130 is driving the processor bus.
Whenever the 80130 is responding to any type of bus
cycle, it generates anACK signal. As Figure 4 suggests,
one way to avoid contention is to simply disable the
transceivers whenACK is active. ACK can also be used
to prevent the insertion of wait states.
6
AFN'02058A
AP-130
r----------------------------------~
I
I
I
I
OPERATING SYSTEM UNIT
I
I
I
00-7
I
I
I
[
I
I
I
I
PROGRAMMABLE
INTERRUPT
LOGIC
I
I
.~
08-15
I
C-
I
I
I
I
ADDRESSI
DATA BUS
I
I
I
I
I
I
I
I
SYSTEM
TIMER
~
SYSTEM
I
I
I
I
DELAY
TIMER
BAUD RATE
GENERATC':lA
:f-------------- - - - - - - -
,
INTERRUPT OUT
I
r-
DELAY
I
I
I
I
:
16
urs
I
2
:
:
:
<
INTERRUPT INP
I
KERNEL
CONTROL
STORE
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
7
I
/1
TE
BAUDRA
I
-- --------------j
I
r
<-DATA
BUFFER
&
BUS
INTERFACE
AND
CONTROL
ADDRESS
LATCH
~
L __________________________________
STATUS
~6USCO NTROL
~
CONTROL UNIT
CLOCK
!
LOCAL
INTERAU PT
I
(CTA}
~
Figure 4. 80130 Internal Block Diagram
Additional pins on the 80130 include eight interruptrequest inputs. Internal interrupt control logic provides
many of the functions of the 8259A. During system
configuration (Chapter V), each of the eight may be
individually defined as a direct level-sensitive or edgetriggered interrupt request, or each may be cascaded
with a standard 8259A in slave mode.
driven by SYSTICK, so this connection must be made
externally. Routines within the 80130 initialize and perform all bit-level control of the interrupt and timer
logic, according to options and parameters specified
during the configuration process. Freeing the programmers from this tedium allows them to devote lIjore
thought to solving their own unique problems.
The INT output must be connected to the host CPU to
inform it of an enabled interrupt request. In very large
systems with multiple, cascaded interrupt controllers,
Local Interrupt Request (UR) indicates to the bus
contention logic whether a requesting slave is local, or
must be accessed via a multimaster bus.
An additional, independent timer generates a userprogrammable, square-wave output signal called
BAUD to clock an off-chip USART.
Since the 80130 displays some of the characteristics of
both memory and 110, it requires chip-select signals for
both the memory (MEMCS) and I/O (IOCS) address
spaces. These are discussed at length below. Finally,
Intel has reserved one output pin (called "DELAY")
for use in future designs. Leave it unconnected in iAPX
86/30 systems.
The 80130 also contains dedicated timer logic to provide
the OS time base, which is output on SYSTICK.
Software operating in conjunction with the 81030 assumes one of the interrupt inputs (INT2 in this case) is
7
AFN-G205M
+5
r
I
8284A
::
f--
(Al)ClK
READY
5 - ROY1 RESeT
f~
Vee
RESET
AI.
I
AI.
8086
(A')
AD15
OSl
OSO
LOCK
N.C.
RQJGn
N.C
RQ/GTO
f
co
liD
N.C,
N.C.
I
I
ADO
tI
V
(Aa)
P
rY
l-
...
~
lACK
~
(AO)
V
- 'Srii"""
~~
t..
'\
n!~
I--
~:'6)
I-I--
1
I--
"'" 7-
N.C.-
-+--
r-
- I-
- ~
-
PERIPHERALS
- f- f-
iOCS
.4
DECODe
LOGIC
:~AS
• Al
~
MfilCS
A7
:rA7-A4
Ii.
"'l
INT7
INT6
INT4
ADI15
INT3
ADO
INT2
INTl
1NTOVSS
y
0-
f\r
A"
A'
SYSTEM
CONTROL
BUS
"
V
I-
PROCESSOR DATA BUS
~
~
SYSTEM
ADDRESS
BUS
A7- A O LOCAL (+5Y5)
015-00
READY
-<"'>-
I
Dl/R
:=r--,
r--'-
t---
SVSTlCK
IHTS
(PROM, PERIPHERALS, RAM
ACCORDING TO APPLICATION)
-;:---DIS
ADDRESS
BAUD
N . C . - DELAY
RESOURCES
I-~OE
~
.. lttSilr'r-
DR
(ON·BOARD)
LOCAL
~
A1B-A16
BHE
BHE
A"
A\6
V
I---
-f~
80130
(A1)
"
8...
~~
MDI
INTGND MAX
StiNT
BHE
8.82
TEST
L.... ~rii
TO SERIAL INT.
}
SIGNALS
8288
I
NMI
I
CONTROL
(CONTROL BUS)
lID
~q......rSTB
AEN1 RDY2
N.C.
Il'
READY
liHi!
N.C.
" 52-
SOl--,--
AEA2
-=-
t..
ClK
ClK
' \ 8...
(AS)
~~
!Y
~-r--
F~
OE
c;~:--w--"
FOR MULTI-MASTER SYSTE
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 and interrupt control logic occupy
a 16-byte block of addresses in the 110 space; at least
some of the bits A15-~ 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 150Oto 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 110 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
I-'-'-.J...W-'-'-'-I }
P~~"I }
1.5K CODE BYTES SYSTEM INITIALIZATION (ROM/EPROM)
1.5K RAM BYTES FOR IAPX 86/30 STACK AND DATA (RAM)
400H
=}
1K BYTES
RESERVED FOR
INTERRUPTS (RAM)
Figure 6. Operating System Processor System Memory Requirements
9
AFN-Q2058A
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 relatively 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, TCLA V is the delay from the start of
Tl until address information is valid on the CPU pins;
Trvov is the propagation delay through an 8282 latch;
and TCSCL is the 80130 chip-select 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 OSP systems, both of which relate to
the user-generated chip-select signals. Figure 7 illustrates the relevant timing signals of a standard 8086
four-state Read cycle (memory or 110), along with the
timing responses of the 80130. 110 Write cycle timing is
the same. (Full timing diagrams are part of the respective data sheets.)
T CLAV
+
T1VOV
Tovcs ,,; T CLCL
,,; 125
,,; 140
The first concern is that MEMCS and IOCS must be
active early in a memory or 110 cycle if the 80130 is to
n
T4
I
-
.. TCHCL
--'
elK
TelCH
,TeHSV_
/
52,51. $0
\
TW
I
I~AseH·1
RX-----
I
,
F
TClS'::1
TCLCL
-----I
nsee.
T3
/
TSVCH
1
I
T2
I
+ Tovcs + TCSCL ,,; T CLCL + T CLCL
+ T CLCL - T CLAV - T 1VOV - TCSCL
+ 125
- 60
- 30
- 20 (nsee.)
/
/
T4
I
BHE, A15-AO VALID
BHE, AD 15- AD o
TCSCL
4/
-
MEMes ,toes
I
-
ADDRESS VALID
XJIJJIX
-j
AeK
~
TSACK
FLOAT
ADDRESS VALID
I
TSACK
I.--TCSAK
J
I
1--1
-X
-
I I
1-1
WRITE DATA VALID
rTCSAK
REA o CYCLE
Ae K
'II
1
-
AD, s-ADo
AD,
TCHDH
TDSCL
I
WRIT E CYCLE
TeLDV
~
READ DATA VALID
~
FLOAT
TCLVE
~
\
Figure 7. Operating System Processor Timing Diagrams
10
AFN-02058A
AP-130
In a "normally not ready" design, acknowledge 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 of the system.) Based on
these assumptions, 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 address decode logic must produce
stable CS 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 I/O cycle to allow activation of ACK early
enough to prevent wait states. There are two 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
+
:5
~
~
Tovcs + TCSAK + RR1VCL ~TCLCL + TCLCL
2 TCLCL - TCLAV - TCSAK - TR1VCL
250
60
45 nsec.
110
35
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
80 G SQ
Gl
A18
70
70
G2B
A17
60
60
G2A
A16
50
50
C
AD15
40
40
AD14
30
30
}.DECODE
A
748373
MEMCS
74$138
ACK
READY
74S
00
Vee
READY
SYSTEM
ACKNOWLEDGE
-
Figure 8. High-Speed Address Decoding Circuit
11
AFN-02058A
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 USARToperating 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
AD15-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) ADI5 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 I/O 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 I/O cycle, the overall
effect on system performance would be insignificant.
APPLICATION SOFTWARE
DEVELOPMENT
A few words of caution, though. Ifthe 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 86/30 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 particular 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 of the 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 bus
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 86/30 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.
12
AFN-02058A
AI""-I",U
RESISTORS
RESET
8288
B086
D
B1
BYTE 1
~ -~~DDDDD
DD~
M1
'LS
73A
8284A
D
80130
B'
0
D'DDD
~ DOG"DDDD --
SWITCHES
LEOs
8255A
~ .~ ~
1489
DB~[]DDD D
[J
~D·
2732/
2764
[J
[J
1488
2732/
2764
\
I
l6X 2114
Figure 9. Example System Prototype Layout
ent motor, and a different console might make up a
second job.)
This makes it easy to divide a very large programming
job among a team 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.
All asp 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 aSp.) 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 oftasks cooperate to accomplish some
common goal, the collection of tasks is referred to as an
application "job." The asp 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-
'This life cycle is suggested by Example I, a segment of
code called HARDWARE$INIT$TASK. This task first
13
AFN-02Q58A
AP·130
the procedure RQ$DELETE$TASK, suicidally
specifying itself as the task to be deleted.
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 825lA 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$OUT) are reproduced
in Example 2.
Exercise 5. Beginners may make two common
programming errors when developing OSP 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 ofthe task did not originate with a call
from the OS.) 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.)
HARDWAREsINITsTASK: PROCEDURE;
DECLARE HARD$INIT.EXCEPTtCODE WORD;
DECLARE PARAMS~l <*) BYTE DATA (40H, SOH. OOH, 40H, 4EH, 27H);
DECLARE PARAM':5aINDEX BYTE;
DECLARE SIQNSON.MESSAGE <*l BYTE DATA
(CR. LF, 'iAPX B"/30 HARDWARE INITIALIZED', CR, LFli
DECLARE SIGN$ONSINDEX BYTE;
You may have noticed three things from this short example and Table 1. First, every OSP call begins with
the letters RQ. (PLIM compilers totally ignore dollar
signs within symbols; they serve only to split long symbol names to make them easierfor 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 OSP provides useful services at the bidding
of application code.
OUTPUT( pp I.eHO) III~OHl
OUTPUT (TIMER.eHO) "'OB6H;
aUTPUTCBAUO$T1MER)-33i
I*GENERATES 9600 BAUD FROM 5 MHZ*!
OUTPUT (BAUD$T IMER) =0;
DO PARAMSSUINDEX""O TO (SI ZE(PARAM$51 )-1);
OUTPUT(CHD.51 )""'PARAMS51 = 60
THEN 00;
AC$CYCLE$COUNT=Qj
CALL RG$SIGNAL$INTERRUPT (AC$INTERRUPT$LEVEL,
(!ACSEXCEPT$CODE) ;
END;
ELSE CALL RG$EX I T$INTERRUPT (AC .. INTERRUPT$LEVEL,
IlACSEXCEPn;CODE) ,
END
"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 aSp. 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 reduc.es the worst-case interrupt processing
time.
AC SHANDLER i
Example 5. 6o-Hz A.C. Interrupt Handler
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 asp 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
asp 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 as
routines. An interrupt task, on the other hand, is initiated and suspended by the asp itself, with no such
restrictions.
DECLARE SECOND$COUNT BYTe,
MINUTE$COUNT BYTE,
HOUR$COUNT BYTE;
TIME$TASK
PROCEDURE,
DECLARE TIME$EXCEPT$CODE WORD;
AC$CYCLE$COUNT=O;
CALL RG$SEHINTERRUPT(AC$INTERRUPT$LEVEL,OlH,
I NTERRUPT$PTR (AC$HANDLER), DATA$SEG$ADDR _ BASE,
@TIME$EXCEPT$CODE);
CALL RG$RESUME$TASK( INIT$TASK$TOKEN, (HIME$EXCEPT$CODE);
00 HDUR$COUNT=O TO 23;
DO MINUTEtCOUNT=O TO 59;
DO SECOND$CQUNT=O TO 59;
CALL RG$WAIT$INTERRUPT (AC$INTERRUPl$LEVEL,
@TIME$EXCEPT$CODE);
IF SECOND$COUNT MOD 5 '" 0
THEN CALL PROTECTED$CRT$QUT (BEL) i
END;
1* SECOND LOOP
'~I
ENDi
1* MINUTE L,QOP *1
END;
1* HOUR LOOP
*1
CALL RQ$RESET$INTERRUPT (AC$INTERRUPT$LEVEL,
@TIME$EXCEPT$CODE);
CALL RG$DELETE$TASK (0, @TIME$EXCEPT$CODE)i
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 byTIME$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
PRaTECTED$OUTPUT. This lead-in gives us a
chance to discuss asp provisions for task synchronization and mutual exclusion.
16
AFN-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 with 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 to TIME$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 USART 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! TaskAjust woke up and starts running. Task
A wants to transmit its own character. It calls its own
output routine, checks the USART, finds 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 OSP 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
17
AFN-02058A
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
queue of all tasks waiting for the busy region. When the
region later becomes available (i.e., when the task controlling the region calls RQ$SEND$CONTROL), one
of the 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, and 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
reentrant which means (by definition) the routine may
be interrupted and restarted safely. A reentrant routine
may be shared by a number of tasks, instead of replicating the same code throughout the application.
PROTECTEOSCRT$OUT
PROCEDURE (CHAR)
DECLARE CHAR BYTE;
DECLARE CRT$EXCEPTSCODE WORD;
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 the
application warrants.
REENTRANT;
CALL RQ$RECE I VE$CONTROL (CRT$REGION$TOK.EN, @CRT$EXCEPTSCODE);
DO WHILE (INPUT(STAT$51) AND 01Hl=O;
1*
NOTHING
'It/
ENOl
OUTPUT (CHAR$51 ) =CHARi
CALL RQ'SEND$CONTROL (@CRT$EXCEPTSCODE);
END
PROTECTEO$CRT$QUT i
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
18
AFN.()2058A
AP-130
PRINT$STATUS:
PROCEDURE,
DECLARE STATUS$MESSAGESTOKEN WORD.
DECL.ARE STATUS.EXCEP,TSCODE WORD;
DECL.ARE STATUS$SEGMENnOFFSET WORD,
STATUS$SEGMENT$BASE WORD;
DECL.ARE STATUS$SEGMENT$PNTR POINTER
AT (@STATUS$SEGMENTSOFFSET) J
DECLARE STATUSHEMPLATE (40) BYTE DATA
(39, 'THE SWITCHES ARE NOW SET TO
.B',CR,LF),
DECL.ARE STATUS$STRING BASED STATUS$SEGMENT$PNTR (40) BYTE,
DECLARE STATUS$STRING$INDEX BYTE,
DECLARE BIT$PATTERN BYTE;
length, followed by that number of ASCII characters.
Figure 10 shows this format.
PR I NT$TOD
PROCEDURE;
DECLARE TOO$MESSAGE$TOKEN WORD;
DECLARE TOO$EXCEPT$CODE WORD)
DECLARE TOD$SEGMENT$OFFSET WORD,
TDO!flSEGMENT$BASE WORD;
DECLARE TOD$SEGMENT$PNTR POINTER AT (@TOD$SEGMENT$QFFSE[,i
DECLARE TOO$TEMPLATE (28) BYTE
DATA (27, 'THE TIME IS NOW I'll'!: mm. 55. ',CR, LFl;
DECLARE TDO$STRING BASED TOO$SEGMENT$PNTR (28) BYTE,
DECLARE TOO$STRING$lNDEX BYTE;
ST ATUS$MESSAGESTOKEN=RGSCREATESSEGMENT ( 40,
@:STATUSSEXCEPT$CODE),
STATUS$SEGMENTSI3ASE=STATUSSMESSAGE$TOKEN,
STATUSSSEGMENT$OFFSET=Oi
DO STATUS$STRING$INDEX=O TO 39,
STATUS$STR ING (STATUSSSTR ING$INDEX)=
ST ATUS$TEMPLATE (ST ATUS$STR ING$ INDEX l i
END.
B I HiPATTERN=1 NPUT (PP I$A l )
DO STATUS$STRING$lNDEX=29 TO 36;
ST ATUS$STR I NG (ST ATUS.STR ING$I NDE Xl'"
ASCII$CODE(J3IT$PATTERN AND 01Hli
BITSPATTERN=ROR (BIT$PATTERN, 1 l,
END,
CALL RG$SEND$MESSAGE (CRTSMAILJ30X$TOKEN,
STATUS$MESSAGE$TOKEN, 0, @STATUS$EXCEPT$CQDE);
END
PRINT$STATUS;
TOD$MESSAGE$TOKEN==RG$CREATE$SEGMENT (28, @TDO$EXCEpnCOOE);
TOD$SEGMENT$BASE=TOD$MESSAGE$TOKEN;
TOO$SEGMENT$DFF'SET=Oi
DO rOO'$STRING$lNDEX=O TO 27;
TOO.STR I NG (TOD$STR I NG. I NDE X ) =
TOD$ TEMPLATE (TOD$STR I NG' INDEX) ;
END;
TOO$STRING( 17)=ASCI ]$CODE(HDUR$COUNT /10);
TOD.STRING( 18)=>ASCI I$CODE( HOUR$COUNT MOD 10);
TOD$STRING(20)=ASC I I$CODE (MINUTE$COUNf 110),
TOD$STRING(21 )=ASC I I$CODE( MINUTE$COUNT MOD 10) i
TOD$STR ING (23) ""ASC I I$CODE (SECOND.COUNT 110) ;
TOD$STR ING(24) =ASC I I.CODE (SECOND.COUNT MOD 10);
CALL RG$SEND$MESSAGE (CRT.MAILBOX$TOKEN,
TOD.MESSAGE$TOKEN, 0, (HOD$EXCEPT$CODE),
RETURN,
END
PR INT$TOD,
Example 9. Subroutine to Send Status Report
Message to Output Task
Example 8. Subroutine to Send Time-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),
while TIME$TASK is fresh in our minds. It will actually
be called by (and is therefore considered a part of)
KEYBOARD$TASK. Note that while tasks 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
read/modify/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 receiver calls RQ$
To repeat, these examples are intended to illustrate use
of the OSP routines assuming minimum familiarity with
PL/M. Better programming practices might take advantage of PUM literals, structures and the array
LENGTH function to build the message, rather than
the inflexible constants shown here. Some of these
techniques are suggested by PRINT$STATUS
(Example 9), which indicates the binary status of the
input switches.
10
OFFSET=
127 1T 1'H·
11
12
13
14
1S
16
17
18
19
20
21
22
23
24
25
26
27
I I I I .,' I·M·I I I·'· I's·1 I I,0·1 I I·'· 1.2.1 ',. 1. I'4·1 I I,.·1 I I I
'E·
sp
'1"
'E'
sp
sp
'N'
'W
sp
3'
'5'
CR
LF
LSEGMENT STARTING ADDRESS = TOD$MESSAGE$TOKEN:OOOOH
Figure 10. Message Formats Expected by Output Task
19
AFN·0205BA
AP-130
RECEIVE$MESSAGE later, the OSP will give it the
tokens one at a time.
CRT$DUT$TASiot,
PROCEDURE,
DECLARE MESSAGE$LENGTH BYTE;
DECLARE MESSAGE$TOKEN WORD;
DECLARE RESPONSE$TOKEN WORD;
DECLARE MESSAGE$EXCEPT$CODE WORDi
DECLARE MES5AGE$SEQMENT$OFFSET WORD,
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?
MES5AGE$SEGMENT$BASE WORD;
DECLARE MESSAGE$SEQMENT$PNTR POINTER AT
(@ME55AGE$SEGMENT$OFFSET) i
DECLARE MESSAGESSTRING$CHAR BASED MESSAGE$SEGMENT$PNTR BYTE,
CALL RG$RESUME,:$TASK (INIT$TASK$TOKEN, @ME55AGE$EXCEPT$CODEJ,
DO FOREVER;
MESSAGE$ TQKEN=R Q$RECE I VE$ME55AGE (C RT$MA I LBOX $ TO~EN, OFFFFH,
@RESPONSESTOKEN, = '0') AND (CONSOLE.CHAR
THEN DDi
CALL PROTECTED$CRTsOUT (eR) i
Initialization Task
<:=
'9')
CALL PROTECTED'CRT$OUT(LF);
DO CASE (CONSOLE.CHAR-/Q')i
CALL PRINT.TODi
CALL PRINT.STATUS.
Now that the application tasks have been written, we
can write the initialization task.
CALL RG.SUSPEND.TASK (CRT.QUT$TASK.TOKEN,
C!CQMMANDSEXCEPT.CODE) J
CALL RO.RESUME.TASK(CRTsOUT$TASK$TOKEN.
@COMMANO$EXCEPT$COOE);
CALL RO$DISABLE (AC$INTERRUPT$LEVEL.
@COMMAND$EXCEpnCODE);
CALL ROSENAI3LE(AC$INTERRUPT$LEVEL,
I!COMMANO.EXCEPT$CODE) ;
CALL RO$SUSPENDSTASK (MOTOR$TASKSTOKEN,
(tCOMMANOsEXCEPT$CODE) ;
CALL RO.RESUME.TASK (MOTOR.TASKHDKEN,
@COMMANOSEXCEPT.CODE);
CALL RG$SUSPEND$TASK (STATUSSTASKSTOKEN,
I!COMMANPsEXCEP1$CODE) ;
CALL RG.RESUME.TASK (STATUSSTASK.TOKEN,
(!CQMMANDSEXCEPT$CODE) ;
1* OF CASE-LIST '*1
END;
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
ENDl
END;
COMMAND.TASK;
Example 11. Task to Accept and Process Keyboard
Commands
INIT.TASK: PROCEDURE PUBLICi
DECLARE INIT'EXCEPT$CODE WORDi
DATASSEGSPTR=\UNIT.TASK.TOKENi
I*LOAD DATA SEGMENT BASE*I
CRTSMAILBOXHOKEN=RO$CREATE$MAILBOX (O •. @INIT$EXCEPTSCQOE)i
CRT$REGIONsTOKEN=ROSCREATESREGION (0. (!INITSEXCEPT$CODE) j
IN r 1$T ASK" TOKEN""RG$GET$ TASKnOKENS (0. \! I N I UEXCEPT$CODE) j
HARDWARESINITSTASKsTOKEN"'RG$CREATE$TASK
(110.
NAMEODEVCF
$INCLUDE{
Fl
NDEVCF. MAC)
%MASTEr~_PIC(80130,
2000H, 0, 0)
%TIMER (80130, 2008H, 28H, 12500)
; NDP _SUPPORT ( ENCODED_LEVEL
)
END
Figure 12. 80130 Device Configuration Table
23
AFN-02058A
AP·130
FO:ASMB6 :Fl:SUP130.A86 PRINT( Fl:SUP130,LST) ERRORPRINT '?(
MACRO
r.osx
(OFBOOOH, N)
Y.SYSTEM(FBOQ, 0, 4, N, N, 1)
END
Figure 15. Root Job Configuration File
25
AFN-02058A
AP-130
(After completing this phase, examine RJB130.MP2 to
confirm that 140H is the correct number.) The second
%SAB invocation excludes addresses 02000H through
OFFFFFH, all of which is non-RAM, either EPROM,
80130 firmware, or non-existent. The %SYSTEM
macro defines system-wide software parameters.
UPM memory buffer. The three commands in Figure 18
perform this function.
When the final system is reset, execution must branch
into the root job initialization sequence. When the absolute code modules have finished loading, manually
patch a jump instruction into the buffer area corresponding to the CPU reset vector. The opcode for the
8086 or 8088 intersegmentjump is OEAH; the instruction's address field must contain the address assigned to
label RQ$START$ADDRESS (read from the root job
locate map), the 16-bit segment offset (low byte first)
followed by the segment base address (ditto). The UPM
CHANGE command should be used to make this
patch, as illustrated in Figure 19.
Figure 16 is a command file to translate, link, and locate
the root job. Once again, the LOC86 parameters come
from Figure 11. The listings produced during this phase
are reproduced in Appendix F. The final memory map
appears in Appendix C.
EPROM Programming
We are now ready to program EPROMs with the program modules linked and located above. Intel's Universal PROM Programmer (UPP) and a control program
called the Universal Prom Mapper (UPM) will be used
in this step. Particular commands to the UPM will vary
with program size, memory location, and EPROM type,
but the general sequence should resemble that shown
here.
The UPM memory buffer now contains a complete
image of the code needed for the system EPROMs. Up
until now, all software-related steps-source code
preparation, translation, linking and locating-have
been the same for 8086- or 8088-based systems. At this
point, however, the software installation procedures
diverge slightly.
The first step is to invoke UPM and initialize the programming system, following a command sequence
similar to that in Figure 17. The example system incorporates two 2764 devices, so 16K bytes of memory
buffer are cleared.
Recall that the 8086 fetches instructions 16 bits at a
time, from coordinated pairs ofEPROMs. One contains
only even-numbered program bytes, the other, odd. To
separate the linear UPM buffer into high- and low-order
bytes for iAPX 86/30 designs, use the UPM STRIP
command as shown in Figure 20.
Next, all the final code modules produced above (e.g.,
SUP130, AP130, and RJB130) must be loaded into the
Now "burn" the EPROMs with the PROGRAM command in Figure 21.
LINK AND LOCATE THE iRMX 86 ROOT JOB
t10DIFIED FOR TWO-DRIVE OPERATION
REVISED 10/25 - JHW
ASM86
fI: RJB130. A86 MACRO(75)
LINK86
. fl: CT'oot. lib (root),
f1 RJD130.obJ'
fl: croot. lib
TO
'fl:RJD130.1nk
MAP PRINT( f!1:RJB130.mpl)
LOC86 : H: RJB130. Ink
TO
Fl RJB1::JO
MAP PRINT(:fl:RJB13Q.mp2)
i!<
OC(noli, nopl. noem, nosb) &
PC(noli. pI, noem, nosb)
&
SEGSI ZE (stac k (0) )
ORDER (c lasses (data, stac k I memory»
ADDRESSES( classes (c ode (OFDIBOH),
data(QOADOH» )
OH86
Fl:RJB130 TO
COPY
Fl RJB 130. LST TO . L.P·
Fl:RJB130. H86
C()PY :Fl:RJB130.MPl TO :LP:
COpy
Fl RJB130. MP2 TO : Lp·
Figure 16. Root Job Configuration Commands
26
AFN-02058A
AP-130
flUlrom 0 to 3fffh with Oflh
Figure 17. UPM Initialization Sequence
...ad 86hex flle : ": 8up130. h86lrom 0 to 3fffh start OIcOOOh
read 86hex fila: ": ap130. h86 lrom 0 to 3fffh start OIcOOOh
...ad 86h•• flle : 11 : ~b130. h86lrom 0 to 3fffh s\art OIcOOOh
Figure 18. UPM Commands to Load Hex Flies
change 3ffOh=Oeah, 11h, OOh, 18h, Oldh
Figure 19. UPM Command to Patch Restart Vector
strip low lrom 0 to 3Hlh into 4000h
strip hllrom 0 to 3fffh Into 6000h
Figure 20. UPM Commands to Strip High and Low Bytes
program from 4000h to Sfffh start 0
program from BOOOh to 71Hh start 0
exit
Figure 21, UPM Commands to Program EPROMs
To save some trouble, the UPM invocation and all commands except the manual patch can be combined into a
SUBMIT command file. Replace the CHANGE command with a control-E character so the operator can
adjust the starting address for the iteration. Also place
control-Es before each PROGRAM step to give the
operator time to socket the next memory device.
before. It is now possible for concurrent tasks to be
dispatched, memory segments <;illocated, and messages
relayed through mailboxes nearly as easily as subroutines, dynamic variables, and I/O ports were used in
the past. In effect, Jobs, Tasks, Segments, Mailboxes,
and Regions become new OSP data types, manipulated
entirely by firmware in the 80130.
SUMMARY
Yet despite standardizing these functions, the OSP does
not restrict the user's flexibility. The device can accommodate a variety of hardware environments, and both
the hardware and software capabilities are desired.
The development of the 80130 marks a major milestone
in the evolution of microcomputer systems. For the
first time, a single VLSI device integrates the hardware
facilities and operating system firmware needed by
real-time multitasking applications. The 80130 offers
the system hardware designer the advantages of higher
integration-reduced device count, smaller boards,
greater reliability-along with faster design cycles and
optimal system performance.
ACKNOWLEDGEMENTS
The author would like to thank Peter Pederson for
designing and implementing the demonstration system
breadboard discussed in this note, Pam Johnson for her
assistance in typing the manuscript, and Hal Kop,
Lionel Smith, George Alexy, Chuck McMinn, and
Sandy Wharton for their help in reviewing the drafts
and providing many thoughtful comments and
criticisms.
The 80130 gives the software engineer built-in support
for 35 standard operating system primitives. Application problems may now be solved at a higher level than
27
AFN-D2058A
AP-130
APPENDIX A
EXAMPLE SYSTEM SCHEMATICS
A-1
AFN·O~058A
r--------------------------------------1------------------r===~===o----------_t------_r--~rR..EiSE£Tr-~AA;~;7~~ I
Yce
,---------t-----------+-------,
100kU
1,---t-----H-lI~RES
~
RESET~
~
.L
11,;~'MF
RDY1
510n
2 PCO-7 -N.C.
......
-'"
DO.7-..!o~1V
L..._ _ _-..I ~
~
-
I)
OR4CSi----------..,
OR3CSi-----..,
:rERoCSr--
frr ~~~ ~ 7>c:~
II .1.-
ADDRESS-BUS
'"
_
PB~7 ==>
guSAPPIIC~).PCCcsSSIt---------J
I""
»
'U
;'--'-'-L..J.....J...----'-'-'--<-f=r:=--------j'
I
!:
!:
!:
L-------------~~+_I--t-H!:..'L----~~Lf_f_~__t~~
Y
BAUD
1,1.
-
8l
I
~-
...
H
I(!
RD
WR
L ~ c~
r
BHE
~ I--
r--+-I-~"CS
r+ A1
~
"
AM=~ -'"-_-+-+__-J>o-f'N.C.~
:~:~~ A16-A191-..,A;-!,!:;-6-';A~,9;------""""
-
I- N.C.
CLR f-Yee
)10
IORC
AIOWC
MRDC
!
...
....!ee+
=~'~OW~C~--~======~~======~;;~;;~=======t=f~~1F~~~~~Aiio
CEN
GND.- AEN
so
___C_SY_~_I~ S.. r::!
II~ ~LK;E ~
K
Vec'-
AEN2~GND
--It~_!
r---""',f-f-off-_t-j-
~_
L
I
RDY2 r>Vee
AEN1r>GND
RESET :
CLK
PCLK
READY
o-----
r -u
510n
~
I
IN PORT
...
r
_r
-
,--
>~
I
~;; __
L--
,--
'---
OATA-BUS
Figure A-1. Example System Schematics
'--
r----,
I
I--
!:
~
;;
.
.....
w
o
AP-130
G1
I
1
EN1G
2 S1A
A11
A12
~+s
3 S1B
15
ERleS
4 IYO
S2B 13
2YO 12
ER3CS
5 IVl
6 IY2
2V1 11
CRleS
OR2es
7 IV3
2Y2 10
DR3eS
2V3 9
OR4CS
=
=
11
Vee
EN2G
S2A 14
G N r GNO
3
03
03
AO
1
13
12
2
•
03
12
13
D4
11
10
9
F1
1
EN1G
Vee ~+5
2
15
S1A
EN2G
3
S1B
S2A ~A14?
IVO ;;i S2B ~A15
12
IV1
2VO
A15
A13
A14
(80130)=
USARTCS
r---1
§
6 IY2
III
7 Iva
PIOPCS
2Y1 11
2Y2 10
2Y3 9
LEPCS (2764)
MEMCS (80130)
MEPCS (2764)
GNO
r
Figure A·1. Example System Schematics (continued)
A-3
AFN-02058A
AP-130
APPENDIX B
SOURCE CODE LISTINGS
6-1
AFN-02058A
AP-130
ISIS-Il Pl..Il'I-86 V2.0 COl1PILATION OF MODULE DEM0130
OBJECT MOrnJLE PLACED IN :Fl:API30. OBJ
PLM86 :Fl:API30.PLM DATE(12/21l
COMPILER INVOKED BY'
$DEBUG COMPACT ROM TITL.E( 'AP-130 APPENDIX B
DEI'IO$130:
1*
12/21/81' )
DO;
SYSTEM-WIDE LITERAL DECLARATIONS:
*1
DE:CL.ARE FOREVER LITERAL.LY 'WHILE 01H';
1*
lIO PORT DEFINITIONS:
*1
DECLARE CHAR$51 LITERALLY '4000H',
CMD$51 LITERALLY '4002H',
STAT$51 L.ITERAL.LY '4002H';
4
DECLARE PPI$A L.ITERALLY '6001H',
PPI$B L.ITERALLY '6003H',
PPI$C LITERALLY '6005H',
PPI$CMD LITERALLY '6007H',
PPI$STAT LITERALLY '6007H';
5
DECL.ARE T II'1ER$CMD LI TERALL Y '200EH',
BAUD$TIMER LITERALLY '200CH';
6
DECLARE AC$INTERRUPT$LEVEL LITERALLY '00111000B';
7
DECLARE CR LITERALLY 'ODH',
LF LITERALLY 'OAH',
BEL LITERALLY '07H';
8
DECLARE ASCII$CODE (16) BYTE DATA ('0123456789ABCDEF');
$EJECT
$INCLUDE (:Fl:NUCLUS. EXT)
$SAVE NOLIST
$INCLUDE (:Fl:NEXCEPLITI
$save nolist
1*
GLOBAL VARIABLE DECLARATIONS:
*1
DECLARE DATA$SEG$PTR POINTER,
DATA$SEG$ADDR STRUCTURE (OFFSET WORD, BASE WORD)
AT (@DATA$SEG$PTR);
]00
DECl_ARE HARDWARE$INIT$TASK$TOKEN WORD,
STATUS$TASK$TOKEN WORD,
MOTOR$TASK$TOKEN WORD,
TIME$TASK$TOKEN WORD,
AC$HANDLER$TOKEN WORD,
CRT$OUT$TASK$TOKEN WORD,
COMMAND$TASK$TOKEN WORD,
INIT$TASK$TOKEN WORD;
]01
DECLARE CRT$MAILBOX$TOKEN WORD,
CRT$REGION$TOKEN WORD;
8-2
AFN-02058A
AP-130
$EJECT
1*
']02
3C<3
2
30·Q
2
30;"
306
30 7
:3
2
2
3m;
3()9
;~
31 (\
::3
!
31:'2
~2
]1
,.,
CODE EXAMPLE 2.
SIMPLE CRT INPUT AND OUTPUT ROUTINES.
*1
CS(JUT:
PROCEDURE CCHAR I ,
DECLARE CHAR BYTE,
DO WHILE CINPUTCSTAT$51) AND 0IH)=O,
1*
NOTHING *1
END,
OUTPUTCCHARS51)=CHAR,
END CS(JUT,
CSIN:
PROCEDURE BYTE,
DO WHILE CINPUTCSTATS51) AND 02H)=O,
i* NOTHING *1
END,
RETURN INPUTCCHARS51),
END CSIN,
$~:JECT
1*
3
3
3
3
3
1 :3
1 ·1
1 ""
16
17
:3 1 EI
3 1 '.,/
'::;;;:0
1
'''J~')
-,
,.,
-,
~2
-,
:,;,:':4
.", .? :7
~·2b
2.7
.::;.?~3
:-:;;~Cf
J:.lO
3:3 1
HARDWARE INITIALIZATION TASK.
*1
HARDWARESINIT$TASK: PROCEDURE,
DECL.ARE HARDSINIT$EXCEPTSCODE WORD,
DECL.ARE PARAMS51 e*1 BYTE DATA C40H.8DH.00H.40H.4EH.27HI,
DECLP,RE PARAMS51SINDEX BYTE,
DECL.ARE SIGNSONSMESSAGE C*I BYTE DATA
eCHo L.P". 'iAPX 86/30 HARDWARE INITIAL.IZED'. CR. LFI,
DECL.ARE SIGNSONSINDEX BYTE,
-,
.,
OUTPUTCPPISCMD)=90H,
OUTPUTCTIMERSCMD)=OB6H,
OUTPUTCBAUD$TIMER)=33,
;.z
~322
:]';.1::3
CODE EXAMPLE I.
I*GENERATES 9600 BAUD FROM 5 MHZ*I
OUTP~rCBAUD$TIMER)=O,
DO PARAM$51$INDEX-0 TO CSIZECPARAMS511-1I,
OUTPUT (CMDS51 I =PARAMS51 (PARAMS51 $INDEX),
END,
I*OF USART INITIALIZATION DO-LOOP*I
DO SIGNSONSINDEX=O TO (SIZECSIGN$ONSMESSAGEI-1I,
CI\L.L. C$OUT CSIGNSONSMESSAGE CSIGNSON$INDEX I I,
END,
I*OF SIGN-ON DO-LOOP*I
CAL.L. RQ$RESUMESTASKCINITSTASK$TOKEN.@HARD$INITSEXCEPTSCODEI'
CALL RGSDEL.ETE$TASKCO.@HARDSINITSEXCEPTSCODEI,
END HARm.JARE$INITSTASK,
,.:~
J
,3
-,
-,
:3
-,
~.
"'j
;..~
~iEJECl
i*
332
STATUS POLLING AND REPORTING TASK.
*1
PROCEDURE,
DECLARE STATUS$COUNTER BYTE,
DECL.ARE STATUSSEXCEPTSCODE WORD,
STATUS$TASI~
33:)
3::'14
;.2
33 ~)
3:36
2
~3:::~ '7
~:
:33f3
J:.lS'
:1
340
34 1
3'1·:.:'-
CODE EXAMPL.E 3.
c.:'
-,
:J
-,
...
)
-,
''')
STATUS$COUNTER-O,
CAL.L. RG$RESUMESTASKeINITSTASKSTOKEN.@STATUSSEXCEPT$CODEI,
DO FOREVER,
OUTPUTeppI$B)=INPUTepPISA) XOR STATUS$COUNTER,
5TATUS$COUNTER-STATUS$COUNTER+l,
CAL.L. RGSSL.EEPC100.@STATUSSEXCEPTSCODEI,
END;
END STATUS$TA5K,
B-3
AFN-02058A
AP·130
$EJECT
1*
344
345
346
2
347
;;~
348
349
350
2
2
"
*1
MOTOR$TASK:
PROCEDURE;
DECLARE MOTOR$EXCEPT$CODE WORD;
DECLARE MOTOR$POSITION BYTE,
MOTOR$PHASE BYTE;
DECLARE PHASE$CODE (4) OYTE
DATA (00000101B,000001100, 000010100,000010010);
I*INITIAL STEP DELAYS = 114 SECOND~'I
CW$STEP$DELAY=50;
CCW$STEP$DELAY=50;
CW$PAUSE$DELAY=200;
I*PAUSES AFTER ROTATION = 1 SECOND*I
CCW$PAUSE$DEI_AY=200 ;
CALL RQ$RESUME$TASK(INIT$TASK$TOKEN,@MOTOR$EXCEPT$CODE);
DO FOREVER;
DO MOTOR$POSITION=O TO 100;
MOTOR$PHASE=MOTOR$POSI nON AND 0003H;
OUTPUT(PPI$C)=PHASE$CODE(MOTOR$PHASE);
CALL RQ$SLEEP(CW$STEP$DELAY,@MOTOR$EXCEPT$CODE);
END;
CALL RQ$SLEEP(CW$PAUSE$DEL.AY,@MOTOR$EXCEPT$CODE);
DO MOTOR$POSITION=O TO 100;
MOTOR$PHASE=(100-MOTOR$POSITION) AND 0003H;
OUTPUT(PPI$C)=PHASE$CODE(MOTOR$PHASE);
CALL RQ$SLEEP(CCW$STEP$DELAY,@MOTOR$EXCEPT$CODE);
EI\ID;
CALL RQ$SLEEP(CCW$PAUSE$DELAY,@MOTOR$EXCEPT$CODE);
EI\ID;
END MOTOR$TASK;
"
3::">1.
:;~
352
353
354
355
356
357
2
2
3
359
:360
361
362
363
364
365
366
367
STEPPER MOTOR CONTROL TASK.
DECLARE CW$STEP$DELAY BYTE,
CCW$STEP$DELAY BYTE,
CW$PAUSE$DELAY BYTE,
CCW$PAUSE$DELAYBYTE;
343
:358
CODE EXAMPLE 4.
4-
4
44-
3
3
4
4
4
4
3
3
2
$E,')ECT
i*
CODE EXAMPLE 5.
INTERRUPT HANDLER TO TRACK 60 HZ INPUT.
368
DECLARE AC$CYCLE$COUNT OYTE;
:369
AC$HANDL.ER:
PROCEDURE INTERRUPT 59;
DECLARE AC$EXCEPT$CODE WORD;
370
,?
37]
J72
2
2
37:3
~~
375
]
376
3
377
,.,3
378
379
~2
*1
I*VECTOR FOR 80:t30 INT3*1
CALL. RQ$ENTER$INTERRUPT(AC$INTERRUPT$L.EVEL,@AC$EXCEPT$CODE);
AC$CYCLE$COUNT=AC$CYCLE$COUI\IT+l;
IF AC$CYCLE$COUI\IT >= 60
THEI\I DO;
AC$CYCLE$COUNT=O;
CALL. RQ$SIGNAL$II\ITERRUPT(AC$INTERRUPT$LEVEL,
@AC$EXCEPT$CODE);
END;
ELSE CAL.L RQ$EX IT$INTERRUPT (AC$INTERRUPT$LEVEL,
@.AC$EXCEPT$CODE);
END AC$HANDLER;
8-4
AFN-02058A
AP·130
$EJECT
1*
-,
3(~3
2
384
~~
38S
38o!>
387
'388
CODE
EXAMP~E
7,
PROTECTED CRT OUTPUT SUBROUTXNE,
*1
PROTECT~D$CRT$OUT:
380
381
382
PROCEDURE (CHAR) REENTRANT,
DEC~ARE CHAR BYTE,
DEC~ARE CRT$EXCEPT$CODE WORD,
CAL~ RG$RECEXVE$CONTROL(CRTSREGION$'TOKEN,@CRT$EXCEPT$CODE),
DO WHI~E (INPUT(STAT$lIl) AND 01H)"'O,
1* NOTHING *1
E::NDJ
OUlPUT(CHAR$51 )=CHARJ
CAL.L RG$SE::ND$CONTROL (
397
398
2
3
4
399
5
401
402
4
@TIME$EXCEPT$COPE>I
RGSRESUME$TASK
:2
2
@TIME.EXCEPT$CbDE) ,
SECOND$COUNT MOP 5 .. 0
THEN CALL PROTECTEP$CRT$QUT(BEL.) ,
END,
1* SECOND ~OOP */
END,
1* MINUT~ LOOP *1
END,
1* HOUR ~OOP *1
CALL RGSRESET$lNTERRUPT(ACsINTERRUPT$LEVEL,
@11ME$EXCEP1$COOE),
I~
CAL~ RG$DE~ETE$TASK(O,@TIME$EXCEPT$CODE)J
END
rtMEsrASK,
8·5
Ap·130
$EJECT
1*
407
408
409
410
2
2
"'
~
411.
;:~
41 ;;;
2
41 :.~
'"
,>14
~?
415
~~
416
2
~·17
418
2
2
41"
'3
420
.
4·21
4''")'")
~~
2
424
425
2
~l26
2
2
427
4~;B
4:;:~9
2
2
2
1*
430
4:ll.
432
433
•c
434
-,
iJ.::35
"c.
t:..~
2
436
,..".
4J7
2
43(~
"'c-.
439
/:'
44·0
..
-,
441
~
442
;;?
44:]
3
444
44:;
:3
--,<.
44t.~
2
447
3
44B
449
4fiO
3
4:51
2
:3
2
*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/IO);
TOD$STRING(18)=ASCII$CODE(HOUR$COUNT MOD 10);
TOD$STRING(20)=ASCII$CODE(MINUTE$COUNT/I0);
TOD$STRING(21)=ASCII$CODE(MINUTE$COUNT MOD 10);
TOD$STRING(23)=ASCII$CODE(SECOND$COUNT/I0);
TOD$STRING (24) =ASC I I$CODE (SECOND$COUNT MOD 10);
CALL RQ$SEND$MESSAGE(CRT$MAILBOX$TOKEN.
TOD$MESSAGE$TOKEN.O.@TOD$EXCEPT$CODE);
RETURN;
END PR I NT$TOD;
'"
;!
SUBROUTINE TO CREATE TIME-OF-DAY MESSAGE.
PRINT$TOD:
PROCEDURE;
DECLARE TOD$MESSAGE$TOKEN WORD;
DECLARE TOD$EXCEPT$CODE WORD;
DECLARE TOD$SEGMENT$OFFSET WORD.
TOD$SEGMENT$BASE WORD;
DECL.ARE TOD$SEGMENT$PNTR POI NTER AT «HOD$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;
3
423
CODE EXAt1PLE 8.
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 NOW SET TO ........ B'.CR.L..F);
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.
G!STATUS$EXCEPT$CODE) ;
STATUS$SEGMENT$BASE=STATUS$MESSAGE$TOKEN;
STATUS$SEGMENT$OFFSET=O;
DO STATUS$STRING$INDEX=O TO 39;
STATUS$STRING(STATUS$STRINGUNDEX)=
STATUS$TEMPLATE(STATUS$STRING$INDEX);
END;
BIT$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,l);
END;
CALL RQ$SEND$MESSAGE(CRT$MAILBOX$TOKEN.
STATUS$MESSAGE$TOKEN,O,@STATUS$EXCEPT$CODE);
END PRINT$STATUS;
8-6
AFN-02058A
Ap·130
I·'
45;2
45:3
454
4 ~5 ~j
4~?:~',
~"' ?
2
;.~
c.
,.,'"
""'fl
~2
,1,'.09
.<:;,
460
~2
"-16~;!
3
46:3
46,t
-,
46~j
"'
:J
4
4
/.l·t,;'?
:~l
·170
]
ij"'r
~2
1
*1
CAL.L RG$RESUME$TASK ( INIT$TASK$TOKEN, @MESSAGE$EXCEPT$CODE);
DO FOREVER;
MESSAGE$TOKEN=RG$RECEIVE$MESSAGE(CRT$MAILBOX$TOKEN,OFFFFH,
@RESPONSE$TOKEN,@MESSAGE$EXCEPT$CODE);
MESSAGE$SEGMENT$OFFSET=O;
MESSAGE$SEGMENT$BASE=MESSAGE$TOKEN;
11ESSAGE$LENGTH=MESSAGE$STR I NG$CHAR;
DO 11ESSAGE$SEGMENT$OFFSET=1 TO MESSAGE$LENGTH;
CAL.L PROTECTED$CRT$OUT(MESSAGE$STRING$CHAR);
END;
CALL RQ$DELETE$SEGMENT(MESSAGE$TOKEN,@MESSAGE$EXCEPT$CODE);
END;
1* OF FOREVER-LOOP *1
END CRT.OUT.TASK;
'".,
466
467
168
TASK TO RECEIVE MESSAGES AND TRANSMIT THEM TO CRT.
CRT$OUT$TASK
PROCEDURE;
DECLARE MESSAGE$LENGTH BYTE;
DECLARE MESSAGE$TOKEN WORD;
DECLARE RESPONSE$TOKEN WORD;
DECLARE MESSAGE$EXCEPT$CODE WORD;
DECl.ARE MESSAGE$SEGMENT$OFFSET WORD,
MESSAGE$SEGMENT$BASE WORD;
DECL.ARE MESSAGE$SEGMENT$PNTR POINTER AT (@MESSAGE$SEGMENT$OFFSET);
DECL.ARE MESSAGE$STR ING$CHAR BASED MESSAGE$SEGMENT$PNTR BYTE;
,.,
,+c, 1
CODE EXAI'IPLE 10.
$EJECT
1*
472
47:3
-,
474
r.::
4'/.:>
476
i>79
d.
2
:::1
3
::3
4.')1
3
48]
4El4
4
'+
4"17
478
<:,'..,
4f)~';
'1
41016
487
:>
48B
~j
·189
5
490
c;;,
491
5
49~2
5
49:1
5
494
5
495
5
496
497
498
499
0,
5
4
3
2
CODE EXAMPLE 11.
TASK TO POLL KEYBOARD AND PROCESS COMMANDS.
*1
COMMAND.TASK:
PROCEDURE;
DECLARE CONSOLE$CHAR BYTE;
DECLARE COMMAND$EXCEPT$CODE WORD;
CALL RQ$RESUME$TASK(INIT$TASK$TOKEN,@COMMAND$EXCEPT$CODE);
DO FOREVER;
CONSOLE$CHAR=C$IN AND 7FH;
CAL.L. PROTECTED$CRT$OUT(CONSOLE$CHAR);
IF CONSOLE.CHAR=CR
THEN CALL PROTECTED$CRT$OUT(LF);
IF (CONSOLE$CHAR )= '0') AND (CONSOLE.CHAR (= '9')
THEN DO;
CAL.L PROTECTED$CRT$OUT(CR);
CALL PROTECTED$CRT$OUT(LF);
DO CASE (CONSOLE$CHAR-'O');
CALL PR INT$TOD;
CALL PRINT$STATUS;
CALL RQ$SUSPEND$TASK(CRT$OUT$TASK.TOKEN,
@COMMAND$EXCEPT$CODE);
CALL RQ$RESUME$TASK(CRT$OUT$TASK$TOKEN,
@COMMAND$EXCEPT$CODE);
CALL RG$DISABLE(AC$INTERRUPT$LEVEL,
@COMMAND$EXCEPT$CODE);
CAL.L RG$ENABLE(AC$INTERRUPT$LEVEL,
@COMMAND$EXCEPT$CODE);
CALL RG$SUSPEND$TASK(MOTOR.TASK$TOKEN,
@COMMAND$EXCEPT$CODE);
CALL RQ.RESUME$TASK(MOTOR$TASK$TOKEN,
@COMMAND$EXCEPT$CODE);
CALL RQ$SUSPEND$TASK(STATUS$TASK$TOKEN,
@COMMAND$EXCEPT$CODE);
CALL RQ$RESUME$TASK(STATUS$TASK$TOKEN,
@COMMAND$EXCEPT$CODE);
END;
1* OF CASE-LIST *1
END;
1* OF COMMAND PROCESSING *1
END;
END COMMAND$TASK;
6-7
AFN-02058A
AP-130
$EJECT
1*
500
501
1.
2
~,O;2
2
,;04
505
:;06
;2
~~
.,e.
5(}i3
2
5()\:y
~~
510
2
51 1
51 ~~
2
;;~
513
514
2
515
516
2
2
517
5113
2
2
519
;2
520
~~
2
END
521.
*1
DATA$SEG$PTR=@INIT$TASK$TOKENl
I*LOAD DATA SEGMENT BASE*I
CRT$MAILBOX$TOKEN=RG$CREATE$MAILBOX(O.@INIT$EXCEPT$CODEll
CRT$REGION$TOKEN=RG$CREATE$REGION (0, @INlT$EXCEPT$CODE) l
INIT$TASK$TOKEN=RG$GET$TASK$TOKENS(O.@INIT$EXCEPT$CODEII
HARDWARE$INIT$TASK$TOKEN=RG$CREATE$TASK
(110,@HARDWARE$INIT$TASK,DATA$SEG$ADDR.BASE,0,300,
O,@INIT$EXCEPT$CODE)l
CALL RG$SUSPEND$TASK(O,@INIT$EXCEPT$CODE)l
STATUS$TASK$TOKEN=RG$CREATE$TASK(110.@STATUS$TASK.
DATA$SEG$ADDR. BASE,0,300,O,@INIT$EXCEPT$CODE)l
CALL RG$SUSPEND$TASK(O,@INIT$EXCEPT$CODEIl
MOTOR$TASK$TOKEN=RG$CREATE$TASK(110,@MOTOR$TASK,
DATA$SEG$ADDR. BASE.0.300,0.@INIT$EXCEPT$CODEIl
CALL RG$SUSPEND$TASK(O.@INIT$EXCEPT$CODEll
TIME$TASK$TOKEN=RG$CREATE$TASK(120.@TIME$TASK.
DATA$SEG$ADDR. BASE.0.300.0,@INIT$EXCEPT$CODEll
CALL RG$SUSPEND$TASK(O.@INIT$EXCEPT$CODEll
CRl$OUT$lASK$lOKEN=RG$CREATE$TASK(120.@CRT$OUT$TASK.
DATA$SEG$ADDR. BASE,0,300,O,@INIT$EXCEPT$CODE)l
CAl_L RG$SUSPEND$TASK (0, @INIT$EXCEPT$CODEl l
COMMAND$TASK$TOKEN=RG$CREATE$TASK(130,@COMMAND$TASK.
DATA$SEG$ADDR.BASE,0.300,0,@INIT$EXCEPT$CODEll
CALL RG$SUSPEND$TASK(O,@INIT$EXCEPT$CODEll
CALL RG$END$INIT$TASKl
CALL RG$DELETE$TASK(O,@INIT$EXCEPT$CODE)l
END INlT$TASKl
2
50?
TASK TO INITIALIZE OSP SOFTWARE.
INIT$TASK: PROCEDURE PUBLICl
DECLARE INIT$EXCEPT$CODE WORDl
2
503
CODE EXAMPLE 12.
DEMO$130l
MODULE INFORMATION:
CODE AREA SIZE
'" 084CH
CONSTANT AREA SIZE
OOOOH
VARIABLE AREA SIZE = 0052H
0026H
MAXIMUM STACK SIZE
848 LINES READ
PROGRAM ERROR(S)
=
21240
OD
820
380
°
END OF PL/M-'86 COMPILATION
6-8
AFN-02056A
APPENDIXC
SYSTEM MEMORY MAP
C-1
AFN-02058A
Ap·130
EXAMPLE SYSTEM MEMORY MAP
STARTING
ADDRESS
OFFFF:O
OFD1S:0
ENDING
ADDRESS
OFFFF:F
OFD36:6
OFC62:0
OFD17:B
OSP SUPPORT CODE AREA
OFCoo:o
OFC61:F
S0130 MEMORY SPACE
OFSOO:O
OFBFF:F
(FREE SYSTEM RAM)
OOCO:O
01FF:F
ROOT JOB DATA AREA
OOAD:O
OOBF:F
APPLICATION JOB DATA AREA
00A7:0
OOAC:l
OSP SUPPORT DATA AREA
0040:0
00A6:F
SOS6 INTERRUPT VECTOR
0000:0
003F:F
MEMORY MODULE
8086 RESTART VECTOR
ROOT JOB CODE AREA
EPROM
(2x2764)
RAM
(
APPLICATION JOB CODE AREA
INITIALIZATION TASK STARTING ADDRESS:
FC62:06B5
ROOT JOB STARTING ADDRESS: _ _-,F,-,D,.,l",S:",OO,,-l,-,l_ __
C-2
AFN-0205BA
AP-130
APPENDIX D
SUPPORT CODE LOCATE MAP
0-1
AFN-02058A
ISIS"~II M(;S~'86 LOCAT'E'R,
VI.;{ fNVOKED )Jv
FO: LOC8Q
·Fl:SUP130.LNK TO
Fl:SUP130 MAP PRINT(:Fl:SUP130.MP2)
SEGSIZE(STACK(O) )
ADDRESSES( CLASSES (CODE (OF8000H), DATA (00400H) i )
ORDER (CLASSES( DATA, STACK) )
OBJECTCQNTROLS (NOLINES, NOCDr1MENTS, NOSYMQOLS)
WARNING 26:
DECREASING SIZE OF SEGMENT
STACK
SEGMENT
6C(3)
SYMBOL TABLE OF MOPULE MINIMAL 801JO
READ FROM FILE: Fl SUP 1:)0. LNK WRITTEN TO FILE
Fl:SUPI30
BASE
OFFSET TYPE SyMBOL
0040H
0040H
OOOOH
014BH
PUB
PUB
INTERRUPTTASKVEC
INTERRORENTRY
0040H
Ol52H
004o'H
0040H
OlSBH
015EH
Q040H
Ol64H
EXTENSIONLISTROO
-T
ROOT JOBTOKEN
NDP _INTERRUPT~_LE
-V!;L_VAR
PUB
TASK_WAITING_FLA
0040H
0178H
PUB
0040H
0040H
0040H
0040H
0040H
FeOOH
OlEAH
OlEPH
020BH
023EH
0249H
45CCH
PUB
PUB
PUB
PUB
PUB
PUB
F800H
FBOOH
FBOOH
F800H
FBOOH
4556H
4538H
4529H
45lAH
450BH
PUB
PUB
PUB
PUB
PUB
F800H
FSOOH
F800H
44FCH
44E"DH
4400H
PUB
PUB
PUB
F800H
435CH
FSQOH
BASE
OFFSET TYPE SYMBOL
BASE
OFFSET TYPE SYMBOL
0040H
0040H
Ol20H
014CH
0040H
0040H
0144H
OlSOH
PUB
PUB
PUB
0040H
0154H
PUB
PUB
PUB
0040H
0040H
Ol5AH
Ol60H
PUB
PUB
0040H
Ol66H
PUB
0040H
01,EBH
PUB
FILLCHAR
INTMASK
IMR_PORT
PIC_INFO
CLOCK_OFF
NDP _INTERRUPT _LE
-VEL
G£TDESCRPOINTER
OVERFLOW
KINITIALIZE
KCREATERIS:GIONNS
INITNDP
0040H
0040H
0040H
0040H
0040H
F800H
01EBH
OlF6H
02lA"H
0247H
024AH
45C2H
PUB
PUB
PUB
PUB
PUB
PUB
F800H
PBOOH
FBOOH
F800H
F8QOH
4567H
4533H
4524H
45l5H
4506H
F800H
peOOH
F80QH
4336H
EOI_ROUTINE
COMMON_ERROR
SYSTEMEXCEPTIQNH
-ANDLER
PUB
INIT _INTERNAL_RE
-GIONS
PUB
NENTRY
FSOOH
40BlH
PUB
FBOOH
40A2H
FaOOH
40BAH
FBOOH
40~CH
RGS I GNAL I NTERR UP
-T BODY
PUB
RGENTER INTERRUPT
- BODY
PUB
RGSIGNALINTERRUP
-T
PUB
RGEX ITINTERRUPT
FBOOH
4058H
PUB
FBOOH
4049H
F800H
4Q3AH
F800H
FBOOH
FSOOH
4000H
PUB
FC5CH
FC5CH
FC61H
FC61H
FeOOH
OEP AUL T _HANDLER
SYSTEt1EXCEPTIONH
-ANDLERPTR
DELETION_OBJECT _
-BASE
MINTRANSSIZE
PARAM_VALIDATIoN
-_VECTOR
REG I ON_TOKEN_TAB
-LE
KERNEL_FLAG
PUB
PUB
READYLISTROQT
DELET I ONT ASK TOKE
•.. N
0040H
0156H
PUB
SYSTEMPDOL TOKEN
Q040H
0040H
OlSCH
Ol62H
PUB
PUB
LAST _NDP _TASK
REGIONyLAGS
0040H
Ol76H
PUB
SIGNAL_O_INDEX
0040H
OlE9H
PUB
0040H
0040H
0040H
0040H
0040H
FSOOH
OlECH
OlFFH
022CH
024BH
05DOH
4542H
PUB
PUB
PUB
PUB
PUB
PUB
PUB
PUB
PUB
PUB
PUB
NUM_SLAVES
D I SABLEMA5K
EDI_PORT
CLOCK_SP£;:C_EOI
CLOCK_LEVEL
VALIDATE_PARAMS_
-BODY _DUMMY
GETPOINTER
NENTRY _BODY
KENABLELEVELNS
KCREATEOBJECTNS
INITIALIZE
F800H
F800H
F800H
F800H
F800H
453DH
452EH
45lFH
4510H
450lH
PUB
PUB
PUB
PUB
PUB
44F7H
44EBH
4472H
PUB
PUB
PUB
DIVIDEBYZERQ
CLOCKENTRY _BODY
INITIALIZE_TIMER
F800H
FBOOH
F800H
44F2H
44E3H
43AEH
SCANI'1EMORY
KSUSPEND
KENABLELEVEL
KCREATEOBJECT
FINISHINITIALIZA
-TION
DECODE_LEVEL
PUB
ARRAYBOUNDS
PUB
PUB
INITIALI ZE_P ICS
P800H
434EH
PUB
433FH
PUB
40FEH
PUB
NOP _INTERRUPT _HA
-NDLER
INITIALI ZENUCLEU
FBOQH
FBOOH
F800H
40B6H
PUB
FeOOH
40ACH
PUB
RGGETLEVEL_BOOY
F800H
40A7H
P800H
409DH
PUB
RGOISABLE_BODY
FBOOH
4094H
RGWAITINTERRUPT _
-BODY
ROEXITINTERRUPT _
PUB
-BODY
RGWAITINTERRUPT
PUB
F800H
40eOH
PUB
RGQETLEVEL
FBOOH
4076H
PUB
RGENTER INTERRUPT
FeOOH
4062H
PUB
R(lOISABLE
FBOOH
405DH
PUB
NUNLOCKNS
peOOH
4053H
PUB
NUNLOCK
F800H
404EH
PUB
PUB
NOPENNS
F800H
4044H
PUB
NOPEN
FBOOH
403FH
PUB
PUB
NLOCKNS
peOOH
4035H
PUB
NLOCK
FBOOH
4030H
PUB
402BH
PUB
NCLOSENS
FBOOH
4026H
PUB
NCLOSE
F800H
4021H
PUB
401CH
PUB
DELETEOB~JECT
F800H
400AH
COPYRIGHT
FeOOH
4000H
PUB
NUNLOCK_DELET I ON
-_OBJECT
NDPEN_DELETION_O
-BJECT
NLOCK DELETION
-BJECT NCLOSE_DELETION_
·'·OBJECT
DELETERUNN I NGTAS
-K
NBEGIN
FC50H
0004H
PUB
IMR_START
FC5CH
OOOEH
PUB
OOOFH
0012H
INIT _NUCLEUS_JUM
-P
PUB
INIT _CMDl
PUB
INIT _CMD4_MASTER
FC5CH
FC61H
OOlOH
OOOEH
pua
PUB
INIT _CM05_MASTER
SLAVE_TABLE
FC5CH
FC61H
00llH
OOQ3H
rUB
PUB
0005H
OOOBH
4576H
PUB
PUB
PUB
FC61H
FC61H
F800H
0007H
OOOCH
4574H
PUB
Pt,lB
PUB
CLOCK COUNT
C_CLOCK_ON
FARAM_VALIDATION
-_PATH
PC61H
PC61H
OOOAH
0009H
PUB
PUB
-OS
SIQNAL_G
-8
CLOCK_O_PORT
C.,...CLOCK_SPEC_EOI
LEVEL7 _HANDLER
ACTIVATE_SIGNAL_
-G
OLD_SLAVE_NUM
LEVEL_SET _TABLE
ISR_PORT
CLOCK_ON
END_OF _DATA
GETDESCRTOKEN
CLOCKENTRY
a
l'1EMORY MAP OF MODULE MINIMAL 80130
READ FROM FILE :Fl:SUPl30.LNK
WRITTEN TO FILE :Fl;SUPl30
SEGMENT MAP
START
OOOOOH
00400H
009FOH
OOAOOH
OQAlQH
OOA20H
OOA30H
OOA40H
OOA50H
STOP
003FFH
009EFH
009FFH
OOAOFH
OOAIFH
OOA2FH
OOA3PH
OOA4FH
OOA5FH
LENGTH AL I GN NAME
0400H
05FOH
OOlOH
OOlOH
QDlOH
DOlOH
OOIOH
OOlOH
OOIOH
A
W
G
G
G
G
G
G
G
(ABSOLUTE)
DATA
INTVEC_REG_SEG
EXT REG SEG
JOB:REG:SEG
SEM_REG_SEG
MAIL._REG_SEG
oD_REG_SEG
POOL._REG_SEG
CLASS
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
0-2
AFN-02058A
AP·130
OOA60H
OOA6FH
D010H
DE;:LET ION_REG_.S
DATA
LAST RAM !lYlE USeD
-EG
OOA70H
OOA70H
F8000H
F(;SCEH
FC5D4H
FC5E6H
FC5FSH
F'C60AH
f:'C~13H
F'C61 EH
iFC61EH
FC620H
f.)OA'lOH
OOA7QH
FC5CDftoI
FC~D2H
FC5E5H
FCBP7H
FC609H
FC612H
FC61CH
FC61EH
I-C61FH
FC62QH
ooaOH
w
OOOOH
G
W
W
W
W
W
B
B
W
45CEH
0OO5H
OD1;;;!H
OO12H
0012H
QOQ9H
OOOAH
OOOOH
STACK
CODE
PIC ~_CNF ~SEG
CODE
CODE
IMR FlORT
::::EOr:::~PORT
W
CODE
TIMER_CNF _.SEG
CODE
CODE
CODE
CODE
CSEG
CODE:;:
_ISR~~Re;AD_PORT
_PIC~ INFO
SLAVE __ SEG
OQ02H
OOOOH
STACK
??SEG
MEMORV
CODEl--
LAST EPROM BYlIl USED
MEr10RV
GROVP MAP
AODR ~ss
004QOH
GROUP OR SEGMENT NAME
DGRO\JP
OATA
INTVEC_REG_SEG
EXT,_REG ......SEG
JO~ .....REG_6EG
SEM_REG_SEG
MAJL_REG._8~G
OD_REG_SEG
POOL_REG_SEG
DELETlON~REG_9EG
F8000H
CGROUP
CODE
PIC _CNF _SEG
IMR PORT
=::EO I ')1 ORT
_ISR_REAP_PClRT
PIC lNFO
~~~~"_CNF _.~Q
0-3
AFf'I·0205BA
AP-130
APPENDIX E
APPLICATION JOB LOCATE MAP
E-1
AFN-02058A
AP-130
rSIS-II MC5-86
LOC8~
LOG~ TER,
VI. 2 INVOKED BY;
: P1: AP130. LNK TO : Fl: AP130
ORDER (CLASSES(DATA, STACK, MEMORY»
SEGSIZE (STACK CO) )
ADDRESSES (CLASSES (DATA (OQA70H),
CODE (OFC620H» )
MAP PRINT (:Fl:AP13Q.MP2)
OBJECTCONTROLS ~ NOLINES, NQCOMMENTS. NOFUBLICS, NOSYMBOLS)
WARNING 26:
DECREASING SIZE OF SEGMENT
SEGMENT:
STACK
SYMBOL TASLE OF MODULE OEM0130
READ FROM FILE : P1: AP130. LNK
WRITTEN TO FILE ; Fl: AP130
EASE
OFFSET TYPE SYMBOL
BASE
OFFSET TYPE. SYM60L
FC62H
FC62H
FC62H
FC62H
FC62H
FC62H
OB3AH
OBOOH
OACBH
OA90H
QA:;)8H
OA28H
PUB
PUB
PUB
PUB
PVB
PUB
cB1CH
OAE4H
RG_N_C_RETURN_12
RG_N_C_RETURN_B
RG~~N_C_.RETURN~4
RGGETLEVEL
FC62H
FC61'ORS
F·2
AFN-02058A
INTEL CORPORATION, 3065 Bowers Avenue, Santa Clara, CA 95051
Printed in U.S.A./T-520/20K/0282/CP JL
(408) 987-8080
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.6 Linearized : No Create Date : 2016:12:04 11:43:59-08:00 Modify Date : 2016:12:04 11:47:40-08:00 XMP Toolkit : Adobe XMP Core 4.2.1-c041 52.342996, 2008/05/07-21:37:19 Metadata Date : 2016:12:04 11:47:40-08:00 Producer : Adobe Acrobat 9.0 Paper Capture Plug-in Format : application/pdf Document ID : uuid:20deec2b-3452-9a4a-a747-7bb39234bfde Instance ID : uuid:792c15c7-7c95-c045-8c43-c33925e11128 Page Layout : SinglePage Page Mode : UseNone Page Count : 56EXIF Metadata provided by EXIF.tools