Rochester Institute of Technology

RIT Scholar Works

Theses

1988

A Simulator for the Intel 8086 microprocessor

William A. Chapman

Follow this and additional works at: https://scholarworks.rit.edu/theses

Recommended Citation
Chapman, William A., "A Simulator for the Intel 8086 microprocessor" (1988). Thesis. Rochester Institute
of Technology. Accessed from

This Thesis is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in
Theses by an authorized administrator of RIT Scholar Works. For more information, please contact
[email protected].
 A SIMULATOR FOR THE INTEL 8086 MICROPROCESSOR
by
William A. Chapman

A Thesis Submitted
in
Partial Fulfillment
of the
Requirements for the Degree of
Master of Science
in
Electrical Engineering

Approved by: Professor Ken Hsu

':"(':":T~h":"e~sJ.';":·S=--=-A-d'=""v-i:-s-o-r-)-------

Professor James R. Schueckler

Professor _~~ _
Professor _ _~_ _:--:~-=- _
(Department Head)

DEPARTMENT OF ELECTRICAL ENGINEERING

COLLEGE OF ENGINEERING
ROCHESTER INSTITUTE OF TECHNOLOGY
ROCHESTER, NEW YORK
MAY, 1988
 Abstract

This project was originally suggested by J. Schueckler as an aid

to teaching students the Intel 8086 Assembly Language. The need

for such a tool becomes apparent when one considers the expense

of providing students with dedicated hardware that rapidly

becomes obsolete, but a Simulator which could be easily updated

and runs on a general purpose or timesharing computer system

would be accessible to many students for a fraction of the cost.

The intended use of the Simulator therefore dictated that it

precisely model the hardware, be available on a multiuser system

and run as efficiently as possible. An additional design goal

was to develop the Simulator in a structured, high level

language so far as was practical, to make it easier for others

to understand, maintain and modify when necessary. It was

therefore in this framework that this Intel 8086 Simulator was

developed in Pascal to run on a Digital Equipment Corporation

VAXcluster .

The following are trademarks of Digital Equipment Corporation:

DEC DEC/MMS VAX VAXcluster VMS VAX/VMS VAX 8600

The following are trademarks of Intel Corporation:

DEBUG-88 iAPX86/88 Intel iSDM86 MCS-86

ii
 TABLE OF CONTENTS

Chapter 1 Introduction

1.1 Preface 1
1.2 Overview 1
1.3 Literature Review 5
1.4 Summary 8

Chapter 2 Simulator Architecture

2.1 Preface 9
2.2 Overview 9
2.3 Central Processing Unit Model 15
2.4 Memory Model 20
2.5 Instruction Formats 24
2.6 Summary 27

Chapter 3 Input/Output Architecture

3.1 Preface 28
3.2 Overview 29
3.3 Map Description 31
3.4 Map Generation And Viewing 36
3. Data Description 39
3, Data Generation And Review 40
3. User Communications 46
3. Summary 48

Chapter 4 Debugger Architecture

4.1 Preface 49
4.2 Overview 49
4.3 Command Types 53
4.3.1 Utility Commands 54
4.3.2 Execution Commands 55
4.3.3 Examine/Modify Commands 59
4.4 Limitations 64
4.5 Summary 67

Chapter 5 Maintenance and Support Features

5.1 Preface 68
5.2 Opcode Look Up Table Maintenance 69
5.3 Keyword Look Up Table Maintenance 70
5.4 Command Procedures 71
5.5 Expansion And Modification Capabilities .... 72
5.6 Language Extensions And Deviations 75
5.7 Summary 79

111
Chapter 6 Summary and Conclusions

6.1 Preface 81
6.2 Observations On The Simulator 82
6.3 Observations On The Debugger 85
6.4 Summary 86

Chapter 7 Enhancements

7. Preface 87
7. Simulator Enhancements 88
7. Debugger Enhancements 90
7. Support Program Enhancements 93
7. Library Routines And Operating Systems
Enhancements 95
7.6 Summary 96

Appendix A Sample Programs

8 1
. DAC Program Listing 97
8 2
. DAC Debug Session 100
8.3 DAC IOMap86 Session 104
8.4 DAC IOData86 Session 105
8.5 DAC I/O Map And Data 106
8.6 ADC Program Listing 107
8.7 ADC Debug Session 110
8.8 ADC IOMap86 Session 115
8.9 ADC IOData86 Session 116
8.10 ADC I/O Map And Data 118

Appendix B Ordered Opcodes for the Intel 8086

Processor 120

Appendix C Opcode Look Up Table 125

Appendix D Data Dictionary 131

Appendix E Keyword Look Up Table 155

IV
Appendix F User's Guide for the Intel 8086 Simulator

13.1 General 158

13.2 Input And Output 159
13.3 Debugger 159
13 4
. Attachment I
-

An Alphabetical Listing Of
Debugger Keywords 163
13.5 Attachment II -

Debugger Keywords Listed By

Class 165
13.6 Support Policy 167
13.7 Maintenance Capabilities 168
13.8 Release Notes For The Intel 8086 Simulator . . . 170

Appendix G Unsupported DEBUG-88 Commands 171

Bibliography 172
 Chapter 1

Introduction

1 . 1 Preface

This Simulator was designed primarily for the academic

environment as an aid to teaching students the Intel 8086

Assembly Language. It was therefore of primary concern that the

Simulator model the operation of the Intel 8086 microcomputer

hardware with as few compromises as possible. The Simulator's

host machine was chosen to be a Digital Equipment Corporation

VAXcluster which is a multinode system that can be made

available to many students simultaneously. Although the

architectures of the Intel 8086 and the Digital Equipment

Corporation VAX computers are different, it was possible to

create an operational model of the Intel 8086 processor through

the use of a variety of data structures and extensions to DEC

VAX Pascal.

1 . 2 Overview

Some compromises were necessary however, especially regarding

the instructions that dealt directly with the hardware (e.g.

input and output, interrupts, bus lock and escape) since this is

where the two architectures differ most significantly. Two

types of input and output operations were designed for the

Simulator. User communications for interacting with the program

1 -
are supported for such operations as displaying text or prompts

and entering values to be assigned to input variables, while

'
other hardware devices are simulated by mapping the I/O

operations to a data file. The multiuser environment of the

Simulator precluded the direct support of other hardware

operations such as interrupts and direct memory access (DMA)

operations. Other hardware related instructions which could not

be supported include those which manipulate the bus control

signals for a multiple processor configuration and those which

communicate with an attached coprocessor such as the Intel 8087

Numeric Processor Extension. These unsupported instructions

require actual hardware to be connected to the system which is

not practical for the target environment.

In an academic environment, students who are learning to use a

new computer frequently make a plethora of errors which is

characteristic of the learning process. The Simulator must

tolerate these mistakes or the learning process will be

inhibited. In order to be useful here, the user interface must

be friendly and forgiving of as many blunders as practical. The

Debugger, which is the user interface for the Simulator, was

therefore designed to be as tolerant as possible of incorrect

input and to provide as much recovery capability as practical.

2 -
The Debugger provides the user with a variety of ways to access

memory (i.e. using either numeric values or register contents

for segment and displacement parameters) and a variety of ways

to interpret the information found there (e.g. boolean, byte,

word, pointer etc.). The Debugger also provides an expanded

number of breakpoints (up to sixteen) for the user to

investigate the program's operation and a variety of methods to

control program execution (e.g. single step, resume, program

step over subroutines etc.). Also included is a method to

regain control (i.e. Control D) over a malfunctioning program

without aborting the Simulator. These features are intended to

assist users in debugging their programs and gain a good

understanding of how the Intel microcomputer functions.

The Debugger was also designed to encourage the user to become

familiar with what actually goes on in a microcomputer as a

program is executed. As a result of this assumption, the

Debugger provides a minimum set of commands for the user and

does not support symbolic debugging, or make any assumptions

about the initial register contents or flag states.

It was desirable to implement the Simulator on a computing

system which provided simultaneous access to a large number of

students. This implied that the Simulator, all of the support

programs and look up tables had to be sharable, but the programs

3 -
under test, the I/O maps and the I/O data files had to reside in

the
students'

accounts. This would then permit one copy of the

Simulator to reside on the system and be shared by many students

at the same time. The host machine chosen to support the

Simulator was the Digital Equipment Corporation VAXcluster since

this provided access by the largest audience of users at this

facility. Other support programs such as the cross assembler,

cross linker and cross locator were also available on the

system, as well as a variety of DEC supported utilities to

assist in the program development and debug process.

It was desirable to implement the Simulator in a modern high

level language so that good structured programming techniques

could be used in the development process. It was also necessary

to provide good documentation for the Simulator so that any

changes or enhancements could be readily incorporated by others

in the future. It was recognized that Pascal possessed the

necessary qualifications and so it was chosen as the

implementation language. However certain Digital Equipment

Corporation extensions to Pascal were expedient to model the

microprocessor's operation and these are discussed in Chapter 5,

MAINTENANCE AND SUPPORT FEATURES, Language Extensions and

Deviations. The interactive communications between the user and

the program under test also required further deviations from the

extensions of VAX Pascal and it was necessary to rely directly

upon the VMS I/O capabilities. The choice of Pascal as the

4 -
implementation language should minimize the future maintenance

efforts.

1 . 3 Literature Review

Many sources of information were reviewed to acquire the

necessary detailed knowledge to develop this Simulator. Several

user's guides, reference manuals and user's manuals published by

Intel provided insight into the architecture of the Intel 8086

Processor as did several texts from independent sources. In

addition, several references on Pascal also helped formulate the

the necessary data structures to support the Intel 8086

Architecture. No references were found however, on a

generalized approach for the development of software to simulate

the operation of non-native computer opcodes.

The examination of Intel documentation provided considerable

insight into the organization of the Intel 8086 processor and

its opcodes. This analysis initially focused on how to

interpret the MOD and R/M fields of the opcode, and influenced

the design of the Effective Address Type record, the RMDecoder

module and the ComputeEA (Compute Effective Address) software

modules. The organization of the opcodes affected the design of

the Opcode Look Up Table, the OpcodeLUTEntry record and the

Opcode Type Record. Intel, in their literature, had already

assigned opcodes to various classes and this provided a useful

5 -
way to segregate the execution of the instructions. It was not

sufficient however, to develop the look up table because the

opcodes were not all resolved in the first byte. This led to

the development and inclusion of an extended class to fully

resolve the opcodes.

The User's Manual Programmer's Reference proved to be the major

reference for the specific details of implementation for each

opcode. However, other sources were also used to clarify or

simplify the implementation of each opcode. The Motorola

Programmers Handbook for the Motorola 6800 processor provided a

more concise, easier to implement method for setting condition

codes as a result of performing arithmetic operations. The

Rochester Public Library, Rundel Branch, Science and Technology

Division also provided precise definitions of mathematical terms

which were used to properly identify the variables used in some

operations .

Several Intel manuals were consulted to determine the structure

and content of the object files created by the cross product

assembler and compiler. Since these files are the source of the

information on which the Simulator operates, a detailed review

of the file formats was essential. This review provided the

necessary algorithm for computing the file checksum which is

used to verify proper loading of the located object module.

6 -
This investigation also revealed the structure of the header

records, physically enumerated data records and physically

iterated data records which contain the necessary information to

load into memory for simulation.

The Intel manual for DEBUG-88 was reviewed and formed the basis

for the design of the Debugger. The various command format

notations were modeled and implemented as described in Chapter 4

Debugger Architecture. The utility commands, execution commands

and examine/modify commands are all patterned after their

DEBUG-88 counterparts.

The DEC literature on Pascal and the supported extensions was

referenced to select the appropriate data type for manipulating

data in the Simulator. The unsigned data type and the

associated operators UINT, INT, UAND, UNOT, UOR, UXOR and HEX

proved most useful when manipulating the internal bits of

information. The VAX/VMS literature was also perused for the

information necessary to support the queued I/O operations and

the asynchronous trap for the Control D function. Several

reference manuals, a course lecture guide and workbook were also

needed to successfully implement these features.

7 -
While an extensive literature search did not prove fruitful, a

thorough review of Intel and DEC documentation did provide the

detailed knowledge to develop an efficient simulator for the

Intel 8086 processor.

1 4
.
Summary

The Simulator and auxiliary programs provide a cost effective

method for users to test and debug Intel 8086 assembly language

programs. Most of the Intel instructions (including I/O

instructions) are supported. Bidirectional communications with

the user's terminal are provided and a simple, user friendly

Debugger controls the program's execution and provides

interaction with the program variables. The Simulator and

auxiliary programs have been developed in Pascal, a modern high

level language, to permit structured programming techniques,

self documenting code and ease of future modifications.

8 -
 Chapter 2

Simulator Architecture

2 . 1 Preface

This Simulator was designed to operate solely on the output of

the cross products assembler, linker and locator. After

creating and successfully assembling the source code, the user

must link the object modules together using the cross products

linker and then position the executable code within the memory

map of the Simulator using the cross products locator. The

Simulator currently has 8192 (8K) bytes of memory which start at

hexadecimal '0000'. A larger memory map can be provided using

the maintenance capabilities defined in Chapter 5, MAINTENANCE

AND SUPPORT FEATURES, Expansion and Modification Capabilities.

Programs that are intended to be executed by the Simulator must

have been successfully assembled, linked and located by the

appropriate cross products and confine their memory references

to the above locations defined in the Simulator's memory map.

2 . 2 Overview

After a program has been created, assembled and linked without

errors, the locate operation produces a file referred to as an

MCS-86 Absolute Object File. This file consists of Physically

Enumerated Data Records which contain the information to be

"loaded"
into memory for the Simulator. These records contain

9 -
the data and define the physical addresses where those data

blocks will reside in memory. A checksum is also included to

verify that the data are loaded correctly. The MCS-86 Absolute

Object File may also contain a Module End Record that defines

the starting address of the main module which is loaded into the

Code Segment Register and the Instruction Pointer. The Data

Segment, Extra Segment and Stack Segment registers and the Stack

Pointer are not initialized, nor are any of the general

registers or status flags.

If these steps have been properly executed, the located object

file will contain the exact bit patterns as they would appear

after being loaded into the memory of an Intel computer. This

file can also be read by the Simulator into an array in a Pascal

program which models the memory of an Intel machine. The

information in this array can then be interpreted as opcodes,

operands or data and manipulated by the Pascal program as needed

to simulate the operation of an Intel 8086 microprocessor. If

"load"
the user attempts to a file which has not been located,

the record types are incorrect, the information is not stored in

memory and an error message is returned to the user.

Intel provides a variety of system services to its users through

previously defined system utilities. These include such

operations as allocating and deallocating memory buffers,

10 -
communications with disk and tape drives, file management

services and a host of other functions normally expected in a

sophisticated user environment. Many of these operations vary

from system to system and all are dependent upon the actual

hardware characteristics and their addresses to execute

properly. The DEC VMS environment in which the Simulator

operates makes the support for these system services much more

complicated. It was determined that support for these system

services was not essential for an introductory teaching tool and

therefore it was considered outside the scope of this project to

provide support for these system calls.

In order for the Simulator to be an acceptable teaching tool, it

was necessary to provide some support for input and output

functions but the host computer and its environment placed

constraints on the extent to which hardware could be simulated.

The most practical compromise was to provide a fixed number of

simulated I/O ports where the supporting software would read

"generated"

previously defined data from an array or store data

the in an array. The array would be loaded from a

by program

disk file when the simulation session began and would be saved

in a disk file when the session ended. Ancillary programs were

also developed to create and maintain the input data files and

review the output data files. It was not practical to attempt

any support for interrupt driven I/O or direct memory access

(DMA) operations. These restrictions do not detract from the

11 -
usefulness of the Simulator as an introductory teaching tool

however, since interrupts and DMA operations are advanced topics

that are closely allied with hardware. Likewise, support for

the Intel 8089 I/O Coprocessor was not provided. The design of

the Simulator does not preclude support for advanced I/O

any

devices, but modeling asynchronous interrupts and their impact

on bus signals internal to the Intel 8086 CPU was considered

beyond the scope of this project. This may be an enhancement

that could be considered at some future time.

It was also necessary to provide support for the input and

'
output operations to the user s terminal and this is described

in Chapter 3, INPUT/OUTPUT ARCHITECTURE, User Communications.

There are three instructions in the Intel 8086 instruction set

that are tied very closely to the hardware and cannot be fully
simulated. These are the WAIT, LOCK and ESCAPE instructions.

The WAIT instruction causes the processor to do nothing until an

interrupt occurs. Since interrupts are not supported by the

Simulator, this instruction cannot be properly emulated. If

this opcode is encountered, a message is sent to the user's

terminal indicating that the "WAIT instruction (is) not

supported", and execution of the user's program will continue

with the next opcode as though an interrupt had been received

immediately. The second instruction which cannot be fully

12 -
supported is the LOCK opcode. The LOCK instruction is used to

assert the bus lock signal in the Intel 8088 maximum mode

configuration. Since the hardware signals are not directly

simulated, this instruction has no effect on the execution of

the Simulator. If this opcode is encountered, a message will be

sent to the user's terminal indicating that the "Bus lock

instruction (is) not supported", and the execution will continue

with the next opcode. The third instruction that is not fully
supported is the ESCAPE instruction. This opcode is used to

communicate with other coprocessors that may be associated with

the Intel 8086. This instruction will access the memory operand

as required but there is no bus on which to place that operand.

This instruction is therefore partially supported so no message

is issued to the user's terminal, and execution will continue

with the next opcode.

The other group of instructions whose implementation deviates

from a strict interpretation of the Intel 8086 processor are

those which cause software interrupts for system services.

These software interrupts include the breakpoint interrupt, the

divide by zero interrupt, the single step interrupt, and the

nonmaskable interrupt. The response to the breakpoint interrupt

is built into the Debugger and may not be modified by the user.

All of the other software interrupts will cause the appropriate

information to be placed on the stack and the interrupt to be

processed correctly if the user has defined a vector in the

13 -
interrupt pointer table. Since catastrophic things may happen

if the user has not defined the required interrupt vector, a

message is sent to the user's terminal indicating that

"Interrupt Type
xxx"

has occurred before resuming execution at

the location specified by the vector in the interrupt pointer

table. The user may then choose to ignore this additional piece

of information, or it could be an invaluable debugging message

if the interrupt was unexpected (i.e. a divide by zero

interrupt) and no vector had been defined. All of the other

instructions perform the appropriate operations as described by

the available Intel documentation.

Support for other Intel microcomputer components such as the

Intel 8089 Numeric Processor Extension and the Intel 80130

Operating System Firmware are not provided. They were likewise

considered beyond the scope of this project, but nothing in the

design of the Simulator precludes supporting them at some future

time.

The assumptions and restrictions indicated above are not

believed to be serious impediments to the intentions of this

Simulator. It is the conviction of the author that these

assumptions and restrictions will focus the student's attention

on the task of learning and understanding the operation of the

Intel 8086 Microcomputer.

14 -
2.3 Central Processing Unit Model

The Central Processing Unit (CPU) Model is composed of two

pieces, the Register Model and the Arithmetic Logic Unit Model.

Files"
The Register Model consists of three "Register and the

software modules needed to access and update the register files.

The register files include the General Register File, the

Segment Register File and the Control Register File which

contain the contents of the Intel 8086 working registers. The

Arithmetic Logic Unit Model consists of software developed by

the author to manipulate the contents of the register files,

memory array and I/O ports in a manner consistent with the

operation of the Intel 8086 microprocessor. This section will

discuss the implementation of the Register Model and the

Arithmetic Logic Unit Model.

The Intel 8086 CPU supports four general purpose registers, two

pointer registers and two index registers in the General

Register File. The registers are all sixteen bits wide, but the

upper and lower eight bits of each of the four general purpose

registers can also be accessed independently. The General

Register File is modeled by a collection of eight uniquely

identified variables where each variable is thirty two bits

wide, but only the lower sixteen bits of each are used. The

software modules which access the register files imitate the

operation of the Intel CPU so that the upper and lower eight

15 -
bits of the four general purpose registers can be accessed

independently. The method of accessing the General Register

File consists of forming a unique identifier from a width

qualifier and a three bit register, pointer or index designator.

The width qualifier specifies whether an eight or sixteen bit

register is to be accessed and the designator then uniquely

selects the appropriate register. This approach was chosen

because it permitted a direct implementation from the

information contained in the opcode format. The width and

designator parameters are used by the software modules

FETCHREGPTR and STOREREGPTR to access or update the contents of

the General Register File.

The Intel CPU supports four segment registers in the Segment

Register File, each of which is sixteen bits wide and are used

in calculating physical addresses. The Segment Register File is

modeled by a collection of four uniquely identified variables

where each variable is thirty two bits wide but only the lower

sixteen bits of each are used. The method of accessing the

Segment Register File consists of forming a unique identifier

from a fictitious width qualifier and a two bit register

designator. The Segment Registers are then accessed and updated

by using the General Register File routines but with the

fictitious width qualifier selecting only the segment registers

and the two bit designator mapped onto the three bit designator

for the FETCHREGPTR and STOREREGPTR modules. Thus all accesses

16 -
to the Segment Register File are made through the same software

modules that are used to access the General Register File.

The Intel 8086 CPU supports a Status Flags word and an

Instruction Pointer in the Control Register File. The Status

Flags word contains nine processor status flags which reflect

the results of various operations in the arithmetic logic unit.

The flags are all boolean storage devices, having a value of

either true or false, and can be tested or updated independently

or treated as a collection called the Flags Register. The model

of the Control Register Files organizes the status flags as nine

separate boolean variables which can each be accessed or updated

without effecting the others. For those operations where the

flags must be treated as a sixteen bit register, dedicated

software modules either assemble the nine boolean variables and

map them into a sixteen bit register or disassemble a sixteen

bit register and map them into the appropriate nine boolean

variables, permitting proper execution of those operations.

The Instruction Pointer is used by the CPU to determine the

address of the next memory resident datum needed by the

arithmetic logic unit, which may represent an opcode, an

address, an address offset, or datum for manipulation. Once the

information is retrieved, the Instruction Pointer is incremented

to point to the next datum. Some of the decisions made in the

17 -
course of executing an instruction however, may further change

the value of the Instruction Pointer. Since there are many

modules and procedures in the Simulator which can effect the

Instruction Pointer, it is implemented as a global variable

accessible by all of the software modules.

"brain"
The arithmetic logic unit is the of any computer system

and the Simulator models the arithmetic logic unit's

implementation of each Intel 8086 opcode with software on the

host computer. The opcodes are grouped into six classes: Data

Transfer, Arithmetic, Logic, String Manipulation, Control

Transfer and Processor Control and a software module has been

developed for each of the six classes. Each module contains

routines for the opcodes in the specified class and manipulates

the flags, registers, memory, I/O ports or Instruction Pointer

as needed to precisely reflect the operation of the Intel 8086

Central Processing Unit.

the logic
microprocessor"

In a "conventional arithmetic unit

alternates its operations between fetching information and

executing opcodes. The Intel 8086 however is an "advanced

up this by pipelining
microprocessor"

which speeds process or

queuing data from memory in parallel with the execution of the

current opcode. The primary purpose of pipelining is to speed

up the execution of opcodes by anticipating the next datum to be

18 -
used and having it waiting in the internal instruction queue

without causing the processor to wait for it to be fetched from

memory. The Simulator does not model the pipelining done in the

arithmetic logic unit for several reasons. First of all, as a

'
teaching tool , the Simulator s primary purpose is to have the

correct net effect on the register files, memory array and I/O

ports and pipelining is not necessary to achieve this goal.

Secondly, pipelining is done primarily to increase the speed of

execution in the target environment, but speed of execution is

not of primary concern for the Simulator. In fact since the

Simulator is executing on a different processor in a high level

language, each instruction could take several thousand times

longer to execute than it would on a native machine. Thirdly,

there is no difference in the results produced by the arithmetic

logic unit if it had to wait for the next datum to be fetched

from memory. For these reasons, pipelining has been omitted

from the model of the arithmetic logic unit.

In an actual Central Processing Unit, Control Circuitry is also

necessary to complete the processor system. Control Circuitry

provides the necessary clocking and sequencing operations to

insure that everything progresses smoothly within the Central

Processing Unit. However, none of control circuit functions are

visible to the end user unless they malfunction. The purpose of

the Simulator is to have the same net effect on the register

files, memory array, and I/O ports that would result from an

19 -
actual Intel 8086 processor executing the same program.

Therefore it was not deemed necessary to simulate the control

circuitry functions, and no attempt was intended or made to

model them.

The Simulator has modeled the internal Intel 8086 registers as

variables and has support routines which provide access to the

registers in a manner consistent with the operation of the

Central Processing Unit. The arithmetic logic unit has been

simulated by software modules to effect an accurate manipulation

of the flags, registers, memory, I/O ports and Instruction

Pointer which is consistent with the Intel 8086 specifications.

However, pipelining and control circuitry functions of the Intel

8086 processor have not been modeled since these hardware

operations are not immediately visible to the user.

2.4 Memory Model

The Intel 8086 CPU is capable of addressing 1,048,576 bytes (one

megabyte) of memory for programs and data. In order to address

this large of a memory space, a twenty bit address is required,

but each of the registers which point to memory is only sixteen

bits wide. The Intel 8086 CPU forms physical memory addresses

the contents of the desired segment register

by multiplying by
sixteen to form the segment address and then adding the offset

20 -
or logical address to form a twenty bit physical address, which

points to the desired memory location. The Simulator model has

been constructed to follow this process in creating addresses to

reference memory and no access can be made to memory without

going through a module which computes the appropriate physical

address .

The Intel 8086 CPU requires two memory references to access a

word which is not aligned on a word boundary. Since

instructions can vary in length from one to six bytes,

inefficiencies in fetching instructions from memory would occur

if this were done serially. The pipeline architecture

alleviates this situation by fetching data from memory as words

and placing them in the internal instruction queue. The

arithmetic logic unit then removes a datum from the queue a byte

or word at a time, as necessary, to complete the execution of

each instruction, thus reducing the amount of time the

arithmetic logic unit has to wait for the next datum and

improving the efficiency of the processor. The Simulator

however, does not support the internal instruction queue and has

therefore taken a different approach to the problem. The

Simulator accesses memory a single byte at a time and if a word

access is requested, a higher level software module makes two

sequential one byte requests, and assembles them into a word for

the calling module. In this manner, greater control is

exercised over memory reference operations with no loss of

21 -
generality. The only negative aspect of this process is that

"speed"
of execution is reduced but the execution speed is not a

design criteria to be modeled by the Simulator.

The Intel memory space is simulated by a one dimensional array

with four -

eight bit bytes of memory per address in the array,

thus providing the most efficient use of the thirty two bit word

size in the VAX host computer. Support routines were developed

to select the requested byte from the array and provide the

proper boundary alignments for the calling module. As indicated

previously, word accesses of sixteen bits are accomplished by

assembling two adjacent bytes in a higher level software module.

This approach of packing four bytes per array address provides

the most economical use of the VAX host memory and a minimum

image (page) size for execution.

The size of the memory array for the Simulator is defined by two

Limit"

parameters, "Low Memory and "High Memory Limit". The

Limit"
"Low Memory is defined as having a value of zero to

provide address space for interrupt vectors, so the size of

Limit"
memory is proportional to the value of the "High Memory

parameter. The number of bytes of memory in the Simulator model

Limit"
is therefore four times the "High Memory since there are

four bytes of memory per address in the array. All of the

memory addressed by a program must reside within this address

22 -
space,*
including code, data and stack requirements. Any

attempt to load a program which is not within these defined

boundaries of the Simulator's memory will result in an error

message and cause the loader to abort. Likewise any attempt to

access the stack or data outside these memory limits will result

in an error message during program execution.

A one dimensional array is used to model memory for the Intel

8086 Simulator, where each entry in the array contains four -

eight bit bytes. The physical address is assembled from a

segment address and an offset, and is used as the index into the

array to access the desired information. Two sequential eight

bit byte accesses are used to assemble sixteen bit words. The

size of memory is defined before the Simulator is compiled and

all programs, data and stack references must be confined to this

space. Attempts to access memory outside the bounds defined in

the Simulator will result in an error message for the user, but

the memory space can be expanded and the Simulator rebuilt if

more space is needed.

* Refer to Chapter 5, MAINTENANCE AND SUPPORT FEATURES,

Expansion and Modification Capabilities regarding instructions
and considerations for expanding memory space.

23 -
2.5 Instruction Formats

Each Intel 8086 instruction is from one to six bytes long, where

the first byte contains the opcode and subsequent bytes contain

additional information, data or addresses for the arithmetic

logic unit. Each opcode belongs to one of six classes: Data

Transfer, Arithmetic, Logic, String Manipulation, Control

Transfer and Processor Control. There are eight opcodes which

are not uniquely identified in the first byte and require a

byte, they fall into "extended for

class"
second so a special

this implementation of the Simulator. The class for each opcode

is determined by using the value of the opcode as an index into

an Opcode Look Up Table which has two hundred fifty six entries

(all possible permutations of eight bits or 2**8) of which two

hundred thirty four entries are presently used, leaving twenty

"spare"
two entries. The spare entries are filled with an

invalid opcode class to increase the robustness of the

Simulator.

The Extended class causes the eight non-unique opcodes to use

three bits from the second byte to resolve their class. The

resolution of the Extended class is not included in the Opcode

Look Up Table because it would consume extra table space for

only eight of the two hundred fifty six entries. A second (and

smaller) table could have been created to resolve the eight

non-unique opcodes into the necessary twenty two unique opcodes

24 -
but that would have required an additional maintenance program.

Instead, the resolution of these eight opcodes was built into

the Simulator for sake of compactness.

In addition to the opcode class, the look up table contains

"key"
three additional fields: a field, a "direction bit

field
present"

and a "width bit present"

field. The opcode

"key"
field has nine possible values (zero through eight) and it

provides the necessary information to interpret the opcode and

subsequent byte(s), to identify the registers, addressing modes,

displacements or immediate data necessary for the proper

instruction. "direction bit

present"

execution of this The

field indicates if bit one of the opcode should be interpreted

as a direction bit (i.e. to or from the arithmetic logic unit),

and the "width bit

present"

field indicates if bit zero should

be interpreted as a width bit for byte or word operations.

the "width bit present"

fields
present"

The "direction bit and

imply that a single instruction might have more than one entry

in the opcode table. For example, the ADD instruction supports

both a direction bit and a width bit, so the ADD instruction has

four different hexadecimal values (i.e. from 00 to 04)

depending upon whether it was to or from a register or memory

and if it was a byte or word operation. All four of these

entries (00, 01, 10, 11) must have identical characteristics in

25 -
the Opcode Look Up Table for the instruction to be executed

properly. Care must be taken when performing any modifications

to take this into consideration.

Once the extended opcode has been resolved, the appropriate

addressing mode selected, the effective address of the operand

computed, the register designators selected, and the proper

segment register selected, the Simulator invokes the appropriate

module for this instruction. The selected Simulator software

performs the appropriate manipulation of the status flags,

Instruction Pointer, register files or memory array as required

to complete the execution of this instruction.

A look up table is used to decompose each opcode into one of six

classes where software procedures perform the appropriate

manipulation of data. The look up table also provides

information on how to decode addressing modes, displacements,

registers, immediate data, the operand direction and the

instruction width. A support program is also provided to

perform any required maintenance on the look up table. (See

Chapter 5, MAINTENANCE AND SUPPORT FEATURES, Opcode Look Up

Table Maintenance. )

26 -
2 . 6 Summary

A Simulator has been developed to execute Intel 8086

instructions on a DEC VAX computer. The Simulator supports all

of the Intel 8086 instruction set except three instructions

which are dependent upon Intel hardware. A model for the

central processing unit has been created which is functionally

equivalent to the Intel 8086 hardware, but it does not support

pipelining or simulate the supporting control circuitry. A one

dimensional array is used to model Intel memory for storage of

user programs and data. A look up table is used to interpret

Intel 8086 opcodes and select the appropriate software

procedures for the simulation.

27 -
 Chapter 3

Input/Output Architecture

3 . 1 Preface

A computer is useful only if it can communicate with its

environment, so the Simulator must have some facility for

modeling input and output operations in order to assist the user

in understanding how his program will interact with the outside

world. The Intel 8086 CPU supports two methods for addressing

I/O ports, fixed port addressing which includes the port number

as the operand and variable port addressing which uses the

contents of the DX register as the port address. Fixed port

addressing is limited to eight bits of address information as

immediate data or 256 ports, but the DX register is a sixteen

bit register, so it is possible to have 65,536 unique port

addresses, each having some data associated with them. In

reality, an application would use only a few ports but port

addresses are rarely contiguous except over a very short range,

and they are usually not fully decoded. This suggests that if

all 65,536 port addresses were to be provided, the I/O space

would be sparsely populated. It was also not desirable to

restrict the user to a particular range of port addresses if

to accurately model their desired application.

they were

28 -
The Simulator must also provide a mechanism for the program

under test to communicate interactively with the user for a

variety of reasons. A program may need to issue a prompt to the

user, it may need data from the user or it may be necessary to

deliver a status message to the user. To support this, a

feature has been built in to the Simulator to allow the program

under test to communicate directly with the user's keyboard and

CRT even though they are being used to run the Simulator.

3 . 2 Overview

For these reasons, it was decided that the I/O model would allow

the user to describe the key characteristics of the I/O ports

needed to support their application and then the Simulator would

translate references to those ports into operations on the

simulated I/O ports. In this manner, the I/O model would

support a limited number of ports, having any address the user

desired within the following guidelines:

Eight ports in total are provided, each eight bits wide.

Sixteen bit wide ports must consist of two physically

adjacent eight bit wide ports (addresses of n and n + 1).

Any port can be either a read, write or bidirectional port.

Data that is input to the program will be retrieved from an

array associated with that port. The array is loaded from a

disk file when the Simulator is started.

29 -
 Data that is output from the program will be stored in an

array associated with that port. The array is saved in a

disk file when the Simulator ends in a normal fashion.

"FF"
The port address (hexadecimal) is reserved for

users'
communications with the terminal.

In order to support these features, an auxiliary program is used

to define an I/O Map which will contain the key characteristics

for each I/O port and store those characteristics on the host

'
computer s disk . Likewise a second auxiliary program must be

used to create and review the input data for the program and to

review the output data generated by the Simulator. This data

file is also stored on the host computer's disk.

When the Simulator is started, the user is asked for the names

of the I/O Map File and the I/O Data File if any I/O (other than

with the user's terminal) is to be performed by his program.

These files are then read from the host computer's disk into

working arrays in the Simulator and the necessary pointers

initialized. If the simulation session ends in a normal manner,

these two files are updated and can be reviewed with the

programs that created them. If the simulation session ends in

an abnormal manner, no updates are made to the disk files and

none of the intermediate I/O results are saved.

30 -
In order to perform input or output operations, the Simulator

searches the I/O Map for the port address and retrieves the key

characteristics. The Simulator then uses the Port Index and the

Data Index to access the I/O Data array for the appropriate read

or write operations. The Data Index is then incremented and

stored back into the map for the next operation. It is possible

however, to write to an input port or read from an output port,

but these operations do not advance the Data Indices.

Limited I/O support is provided by the Simulator for testing and

debugging programs. In order to provide a reasonably cost

effective model, the number of I/O ports is limited but to

'
preserve flexibility the user s addresses are mapped onto the

Simulator's working I/O Data array. This map and input data are

created by auxiliary programs which are also used to review the

output from running the Simulator. The map and input data are

loaded into working arrays in the Simulator when it is invoked,

and the disk files are updated upon normal termination of the

Simulator. The Simulator also supports I/O to the user's

terminal .

3.3 Description
Map

The I/O Map has seven fields which contain the necessary

information to access and review I/O ports. These fields are

described as follows:

31 -
Port Address: This is the address (in hexadecimal) of the

I/O port that is referenced in the user's program. Any

"0" "FFFF"
address can be used from to (hexadecimal) except

"FF"
for the address (hexadecimal) which is reserved for the

user's keyboard and CRT interface. However, the total

number of addresses specified (excluding the keyboard and

CRT ports) must be less than or equal to the "Maximum Number

Ports"
of I/O as defined at compile time of the Simulator

(presently eight) . All eight bit ports require the

allocation of one address and all sixteen bit ports require

the allocation of two adjacent addresses.

Port Width: This is the number of bits (either eight or

sixteen) in the I/O port. The lower eight bits of a sixteen

bit port are located at the designated address and the upper

eight bits are located at the address plus one.

Upper /Lower Flag: This flag is used in conjunction with the

port width to indicate if this is the lower or upper eight

bits of a sixteen bit port. (For an eight bit port the flag
"lower"
is set to the state. ) If the user accesses the

upper eight bits of a sixteen bit port with a sixteen bit

instruction, then the operation is adjusted to be aligned

with the port's correct address. If an eight bit

instruction is used to access the upper eight bits of a

32 -
sixteen bit port then the operation is executed only on the

requested eight bits. This field was included in the map

rather than force the user to adopt some other alignment

convention for sixteen bit ports.

Auxiliary Index: This is the corollary index (i.e. port

index) for the other eight bits of a sixteen bit port. This

field is included so that the actual entries in the map do

not have to be adjacent for sixteen bit ports. This field

contains an invalid entry for an eight bit port.

Data Index: This index indicates how many entries have been

read from the I/O Data array or written to the I/O Data

array by the user's program. Each time an input or output

operation is performed, this field is manipulated depending

upon the value of the I/O State flag. (Please refer to the

discussion in the I/O Data Description section for more

details .
) This field of the map is reset each time the

Simulator begins execution and the map is loaded.

Input Index: This index indicates how many entries the user

created in the data file for use by the program. It is

adjusted only when entries are Input, Appended, Inserted or

Removed from the data file by the support program.

33 -
 I/O State: This flag indicates whether the port is an

input, output or bidirectional port. Data can be input from

an input or bidirectional port and written to an output or

bidirectional port. Each of these operations has the

potential for modifying the Data Index per the discussion in

the I/O Data Description section.

The total number of I/O ports is specified by a constant "Max

Ports"
Number of 10 and the maximum number of data points for

each port is specified by the constant "Max Number of 10 Bytes".

The maximum number of data points is the same for all I/O ports

since the data are stored in the Simulator in a rectangular

array. The actual number of data points used can vary from port

to port, but if any attempt is made to exceed the maximum value,

Ports"
the Simulator will crash. The "Max Number of 10 and the

Bytes"
"Max Number of 10 determine the size of the map files and

data files on the host computer's disk and the size of the

arrays that need to be allocated in the Simulator when it is

compiled .

Each of these parameters can be modified, the modules recompiled

and relinked to change the number of I/O ports or the amount of

data for all ports as needed. It should be noted however, that

the sizes of these fields have a direct impact on the response

time to start and exit from the Simulator if I/O is being used.

34 -
Each time the Simulator starts and the user indicates that I/O

is to be performed, the specified I/O Map and Data files are

loaded into memory to support the simulation session. As a

Ports"
general rule of thumb, if the "Max Number of 10 is kept

the same, doubling the number of data points will cause the

Simulator to take twice as long to initialize the I/O block

before starting the Simulation session and twice as long to

write the files out to disk before exiting and returning control

to VMS. The same rule of thumb applies if the number of data

Ports"
points is kept the same and the "Max Number of 10 is

doubled .

It is for the benefit of the user community to keep these maps

as small as is practical, not only to optimize initialization

and exit times from the Simulator but also to optimize execution

speed and page swapping in the host computer. If the maps are

made excessively large then the program will take up more

resident memory space and perhaps exceed what has been allocated

to the user by the host computer. If this happens then the VMS

Operating System stores part of the simulation session on disk,

swapping pages in and out of memory as needed, further slowing

the response time of the Simulator to the end user.

35 -
It should also be noted that any map or data file generated for

use with a particular version of the Simulator will not be

compatible with a different version of the Simulator where the

Ports" Bytes"
"Max Number of 10 or the "Max Number of 10 have

been changed. The entire map and all data will have to be

re-entered into new files before they can be used.

An I/O Map permits the user to have the I/O port addresses at

the desired locations for this application without consuming

excessive amounts of I/O real estate which would then be

sparsely populated. Certain parameters have been built into the

Simulator and support programs to permit modifications of the

number of ports and amount of storage for data if necessary.

3 . 4 Map Generation And Viewing

Before running the Simulator to execute a program which reads an

input port or writes to an output port, the user must create a

map defining the necessary key characteristics of the I/O ports.

A support program (IOMAP86) has been developed to perform this

task as well as review an already existing map or to generate a

hard copy of any map created with this version of the program.

The IOMAP86 program supports eight commands as discussed below:

36 -
Create: Creates a new I/O Map with the file name supplied

by the user. All of the map data is input by the user for

the desired number of I/O ports. All unused ports are

initialized with invalid values for increased robustness.

Read: Reads into memory a previously created I/O Map with

the file name supplied by the user. This must be done

before the map can be displayed, printed or modified. An

invalid file name will cause the IOMAP86 program to display

an error message and request a new command.

Modify: Allows the user to change an existing I/O Map by

adding (A) a new port, deleting (D) an existing port,

resetting (R) a datum (D) index, resetting (R) an input (I)

index or resetting (R) both (B) data and input indices, or

any combination of these operations until the user is

finished (F) and wants to exit this function.

Display: Displays a port index plus the seven port

parameters on the user's terminal.

Print: Creates a formatted, printable disk file from the

current version of the I/O Map. This file contains

descriptive headers for each of the fields, the port indices

37 -
 and the seven parameters for each of the ports. After

exiting from the map utility, the user can print this file

at the desired printer.

Write: Saves the current version of the I/O Map in the disk

file designated by the Create or Read operation without

exiting the map generation and review program (IOMAP86).

Quit: Exit the map generation program without saving the

current state of the map. An auxiliary check is made to be

sure the user is intentionally leaving the program without

saving any changes.

Exit: This is the normal exit from the program which saves

the map in the disk file specified by the Create or Read

operation. This operation is equivalent to a Write

operation followed by a Quit operation.

These commands provide the user with adequate capabilities to

create an I/O Map or make any necessary changes. The Simulator

assumes that the necessary I/O Map and Data files have been

created prior to its invocation if the user program is to

perform any I/O other than to the user's terminal.

38 -
3.5 Data Description

The actual I/O data are stored in a rectangular array whose

dimensions are the "Max Number of 10

Ports"

by the "Max Number

Words"
of 10 as defined at compilation time of the Simulator.

Data are read from the array or stored in the array as eight bit

bytes based on the current parameters of the I/O Map.

The Port Address is located in the I/O Map and the necessary key
characteristics are used to access the stored data. The Port

Index identifies the appropriate linear array containing the

Index" Word"
data and the "Data modulo "Bytes Per is used to

select the current word within the linear array and the

Index" Word"
remainder of the "Data modulo "Bytes Per is then

used to select the correct byte of data. A word datum is

accessed as two eight bit bytes of data, stored independently in

two separate linear arrays as designated by the current

parameters of the I/O Map and using the Auxiliary Index for the

corollary Port Index.

Each datum is stored as an eight bit unsigned number in the same

manner as a datum is stored in the memory array. Interpretation

of the value of the datum (i.e. positive or negative integer,

character etc .
) is left to the user of the program being
simulated .

39 -
As each datum is accessed, the Data Index is adjusted based upon

the type of access and the port direction. Operations which

fetch a datum from an I/O port cause the Data Index to be

incremented if the port is designated as an input port. If the

port is designated as an output port or a bidirectional port,

the fetch operation proceeds to return the current value of the

port, but the Data Index is not incremented. Operations which

store a datum to an I/O port cause the Data Index to be

incremented if the port is designated as an output port or a

bidirectional port. If the port is designated as an input port

then the current value of the datum in the port is overwritten

by the store operation and the Data Index is not incremented.

If the next operation on that port is to fetch a datum, then the

value that was stored there will be the value that is retrieved.

Input and output data are stored in a rectangular array and

accessed by Port Number and Data Index for compact storage. The

Data Index is adjusted based on the type of access (i.e. input

or output) and the type of port.

3.6 Data Generation And Review

Prior to running the Simulator to execute a program which

requires or generates I/O data, the user must create a map

defining the necessary characteristics of the I/O ports.

Furthermore, if the program requires input data, the user must

40 -
also supply the data which will be read by the program during
the simulation session. An additional support program

(IODATA86) has been developed to create the input data set and

review the I/O data generated by the program. The IODATA86

program supports nine commands as discussed below:

Create: Creates a new I/O Data file with the file name

supplied by the user. Any valid file name supported by the

VMS environment (including subdirectory paths) is

acceptable. An invalid file name will cause VMS to

abnormally terminate the IODATA86 program. All data points

in the newly created file are presumed to be in an

indeterminate state, i.e. the values of the data points as

a result of the create operation are not specified.

Read: Reads into memory a previously created I/O Data array

from the file specified by the user. This must be done

before the data can be displayed, printed or modified. An

invalid file name will cause the IODATA86 program display an

error message and request a new command.

Modify: Allows the user to manipulate the existing data set

for the specified port, but only if the port is an input

port or a bidirectional port. Supported operations include

appending (A) data, inserting (I) data, removing data (R),

-

41 -
changing a datum (C), displaying (D) data with index or any

combination of these operations on the specified port until

the user is finished (F) and wants to exit this function.

Since free form editing of the data is not supported and

most of these operations require knowledge of the index

associated with each datum point, it is recommended that the

Index"
user issue the command "Display with to provide the

required information before performing other operations.

Append: Allows the user to add a specified number of

data points (up to the maximum number allocated) at the

end of the existing data set.

Insert: Allows the user to insert a specified number of

data points (up to the maximum number allocated) between

two specified data points. Existing data after the

specified point of insertion are shifted to make room

for the new data.

Remove: Allows the user to remove a specified number of

data points from the data set. If the points are

removed from the middle of the data set, the retained

values at the end of the data set are moved up to the

deletion starting point so that the new data set is

contiguous .

42 -
Change: Allows the user to provide a new eight or

sixteen bit value for an existing datum point. Freeform

editing of the data set such as changing a single

character or moving around within the data set (i.e.

such as with a screen editor) is not supported. Only

one datum point (eight or sixteen bit) can be modified

each time this command is executed.

Display With Index: Presents information to the user's

terminal about the I/O port under modification. The

information includes the port address, width and

direction, the number of data points entered by the

user, the number of data points accessed by the

'
Simulator during it s most recent execution and the data

for this port. Most of the other Modify operations

require the index for the datum point or points before

other the operations can be performed. The Display With

Index function provides this information for the user so

that other operations can be successfully completed.

Finished: Indicates that the user has completed the

desired Modify operations.

43 -
Input: Allows the user to input a specified number of data

points for an input or bidirectional port only. The stream

of data is stored in the I/O Data array based on the

specified port address.

Display: Displays the I/O port information and the data for

'
that port on the user s terminal . In addition to the port

address, width and direction, the Display function also

indicates the number of data points entered by the user and

the number of data points accessed by the Simulator during

'
it s most recent execution and the data for this port .

While the data are displayed in a sequential manner, no

index information is provided by this command.

Print: Creates a formatted, printable disk file of the

current version of the data for all ports. In addition to

the port address, width, direction and data, the Print

function also indicates the number of data points entered by

the user and the number of data points accessed by the

Simulator during it's most recent execution. After exiting

from IODATA86, the user can queue the file to be printed.

44 -
 Write: Saves the current version of the I/O Data array in

the disk file designated by the Create or Read operation

without exiting the IODATA86 program. The I/O Map file is

also updated if the user has Appended, Inserted or Removed

any data points causing the Index parameter to change.

Quit: Exit the data generation and reviewing program

without saving the current values in the I/O Data array. An

auxiliary check is made to be sure the user is intentionally

leaving the program without saving any of the modifications.

Exit: This is the normal exit from the program which saves

the data in the I/O Data array. Data are stored in the disk

file designated by the Create or Read operation. The I/O

Map file is also updated if the user has Appended, Inserted

or Removed any data points causing the Index parameter to

change. The Exit function is equivalent to the Write

operation followed by the Quit operation.

These commands provide the user with the ability to review both

the input and output data which has been directed to or received

from the I/O ports as well as to create input data for use by
the Simulator. The Simulator assumes that the necessary I/O Map

and Data files exist prior to its invocation.

45 -
3.7 User Communications

The Simulator must also support interactive communications

between the user and the program under test. This feature

required the use of QIO calls to communicate directly with the

VMS environment.

Any input or output operations to or from the port addresses

designated for the keyboard and CRT are treated differently from

the normal I/O operations. These port addresses are not built

into the I/O Map or Data files, so that communications can occur

interactively with the user without the overhead of having to

specify and load an I/O Map and a previously defined data set.

Communications with the user's keyboard and CRT also take

precedence over other I/O operations. This implies that if a

port is defined in the I/O Map with the same address as the

keyboard and CRT, that port in the I/O map is unreachable.

In order to support the interaction with the user while running

the Simulator, it was necessary to implement these

communications directly with the DEC VMS environment using QIO

calls. This approach was necessary in order for the Simulator

to process each input keystroke or character to be displayed as

a separate I/O step, which is the desired implementation at this

"primitive"
level of computing. This implementation is

compatible with the extended VAX Pascal provided by DEC.

-
46 -
The keyboard and CRT ports are eight bits wide but the CRT port

supports only seven bit wide data, ignoring the most significant

bit of the byte. This was done to insure that the messages sent

to the user would be composed of those characters which are in

the printable ASCII character set.

Addresses have been chosen for the user

'
s keyboard and CRT which

are fixed at compile time for the Simulator. The selected

"FF"
addresses are hexadecimal for both the keyboard port and

the CRT port, thus making this a bidirectional port. These

particular addresses were chosen so they can be accessed with

the simpler fixed port I/O instructions in the 8086 repertoire,

as well as located out of the most frequently or most likely to

be used part of the I/O address space. The port addresses can

be modified if necessary, and the Simulator recompiled if it

becomes essential that these addresses be used for another

purpose .

Communications are supported for the user to interact via the

user's keyboard and CRT with the program being simulated. The

keyboard and CRT addresses are predetermined as the result of

building in this feature, but they can be modified if needed and

the Simulator recompiled.

47 -
3 . 8 Summary

Two types of I/O are supported by the Simulator, mapped I/O and

terminal I/O. For mapped I/O, the user specifies the key I/O

port characteristics using the program IOMAP86 and the input

data using the program IODATA86 prior to the simulation session.

The user can then examine the output data as desired after the

simulation session, also using the program IODATA86. The

maximum number of ports and the number of data points per port

can be modified and the Simulator and support programs

recompiled if changes are necessary. Interactive communications

between the program under test and the user are possible using

his or her terminal. Likewise, the port address for the

keyboard and CRT can be changed and the Simulator and support

programs recompiled if necessary.

48 -
 Chapter 4

Debugger Architecture

4 . 1 Preface

A Simulator is a useful tool for verifying the proper operation

of a program under development, but other tools must also be

available in order to control the execution of that program and

to examine or modify the program or the parameters that are

being used by the program. These features have been included in

the Debugger in order to facilitate the use of the Simulator.

There are many features that could be included in the Debugger

to make life easier for the user, but they can also cause the

user to loose touch with the environment in which he or she is

working. Since this project was developed as a teaching tool, a

minimum number of features have been provided to encourage the

user to understand what the program is doing. This does not

mean that the Debugger has to be difficult to use. In fact,

user friendliness is enhanced by the simplicity of the tool set.

4 . 2 Overview

Consistency is a major feature to emphasize in order to make a

tool set easier to use. All of the commands that perform

similar operations should do them in a similar manner. For

example, all of the commands which access VMS files should have

the same format, all of the commands that display memory,

49 -
registers or the flags should have a common user interface and

all of the commands that modify memory, registers or flags

should be consistent both among themselves and with the display

commands. This makes it easier for the user to learn how to use

the features and easier to remember them later. Consistency

also makes the Debugger easier to develop and maintain since a

common routine would be called to implement similar functions.

The Debugger was designed to support as many of the Intel

DEBUG-88 features as was practical. There are many features

which are identical, including register and flag names, the

commands used to examine the registers, memory, flags and I/O

ports and some of the commands to control program execution.

However, there are also substantial departures from DEBUG-88.

It was decided that in order to keep the user closer to the

operation of the hardware, symbolic debugging would not be

supported. In the interest of simplifying the Debugger, the

on-line evaluation feature was not included, it is not possible

to change the radix used for the presentation of information and

compound commands are not available to the user.

Some of the available commands were also enhanced. It was felt

that two breakpoints were inadequate to control the program

execution, so the number was increased to sixteen. Each

breakpoint can be set, displayed or cleared individually, or all

50 -
sixteen breakpoints can be treated as a group to be displayed or

cleared. Additional commands were added to control program

execution such as START, CONTINUE and RESUME. As a result of

these changes the concepts of the "break

register"

and the "go

register"

are no longer supported.

In order to provide sufficient flexibility for implementing the

Debugger commands, they are contained in external disk file.

The commands are then read from the disk file and loaded into a

look up table each time the Debugger is invoked by the

Simulator. There are four active fields in the Debugger Keyword

Look Up Table. They include the keyword name, a class code, an

identifier and a width code. Each keyword name is limited to

eight characters, but only the first three characters are used

in identifying the keyword. When parsing the command line, a

keyword is isolated and compared against each keyword name entry

in the table until a match is found. The remaining

characteristics in the table tell the Debugger how to interpret

the command. The class code indicates in which of the thirteen

classes (i.e. Utility, Qualifier, Operand, I/O, blank, Logic,

Stack, Register, Flag, Memory, Breakpoint, Execute or unused)

the command belongs and is the major discriminator for all of

the Debugger commands.

51 -
Once the class for a given command has been determined, the

identifier indicates the how that specific command should be

interpreted. It is the identifier value for example that causes

the BYTe command to bits information in

display eight of

hexadecimal and the SINteger command to display the same eight

bits as a signed, decimal number. The fourth field in the

keyword look up table is the width field and it indicates the

width parameter which is used primarily for the register and I/O

port classes. The width field provides the necessary

information to distinguish the AX register from the AL register

in the subsequent Debugger manipulations since both have the

same register identifier.

As previously indicated, the keyword name is a maximum of eight

characters long, and must be unique within the first three

characters. However, there are some execution class commands

which are used much more frequently than others, so special one

letter commands are supported that duplicate the entries for the

corresponding full commands (e.g. R for RESume). There is an

additional constraint in selecting keyword names since none of

the command names can be composed entirely of hexadecimal (i.e.

letters A through F) and numeric characters. If this were done,

the Debugger would not be able to distinguish between a

hexadecimal number and a Debugger command. This implies for

"AB2" "C"
example that "ABE", and are not valid Debugger

commands .

52 -
Storing the Debugger commands in an external disk file required

the development of an additional support program ( KEYWORDLUTGEN )

to create and perform maintenance on the keyword table. See

Chapter 5, MAINTENANCE AND SUPPORT FEATURES, Keyword Look Up

Table Maintenance for more details.

A Debugger has been developed to provide the necessary commands

to control the execution of a program under simulation. The

commands have been developed to be easy to learn and use and

consistency among commands has been emphasized. Many of the

commands are identical to Intel's DEBUG-88, but some departures

were necessary and some enhancements were also implemented.

4 . 3 Command Types

There are three different types of commands in the Debugger.

The first type are utility commands and they allow the user to

communicate with the outside world, the second type are

execution commands and they allow the user to control the

execution of the program under test and the third type are

examine/modify commands and they allow the user to examine or

modify the memory, registers, flags etc. that are used by the

Simulator. All of these commands however, have a similar format

to provide consistency and ease of use. If a command is

intended to display or modify an object, then that command

followed by a carriage return will display the object and that

53 -
command followed by an equal sign, a value (even if it is the

null value) and a carriage return will the object,

modify

setting it to the new value. This is true if the object is a

memory location, a register, a flag, a breakpoint or a file

name. This similarity between commands makes the Debugger

easier to learn and use.

4.3.1 Utility Commands

There are three Utility commands available to the user:

* Load

+ LOAd <cr>: Displays on the user's terminal the name of

the file which has been loaded.

+ LOAd =
Filename <cr> : Loads the specified linked and

located Intel executable file into the Simulator's

memory for execution.

*
Log

+ LOG <cr>: Displays on the user's terminal the name of

the file which contains the commands the user has logged

for this simulation session.

"<cr>"
Note: is a carriage return and the colon is not part of
the command.

54 -
 + LOG =
<cr> : Disables logging of Debugger commands which

the user is entering.

+ LOG =
Filename <cr> Enables the Debugger
: logging of

commands which the user is entering. Commands are

written to the file specified.

* EXIt: Leave the Debugger and Simulator, write the I/O Map

and I/O Data files to disk if they were used, close the log
file if it is open and return to the VMS environment.

Where a file name is specified, a full path name

(node: : disk: [user] filename. extension) can be entered, but it

must be less than forty characters in length including all

punctuation. An invalid path or file name will cause the

Simulator to crash.

4.3.2 Execution Commands

Execution commands are provided to enable the user to start and

stop the Simulator in a controlled manner. There are six basic

commands which cause the Simulator to begin execution (i.e. GO,

STArt, CONtinue, RESume, STEp and PSTep) .

* GO or STArt will begin the execution of the program at the

address specified by the Code Segment Register and

Instruction Pointer values. If numeric values are used in

55 -
 the GO or STArt command, these values will replace the

contents of the Code Segment Register and/or the Instruction

Pointer before execution of the program begins.

*
RESume or CONtinue will cause the program to resume

execution at the address specified by the current values of

the Code Segment Register and Instruction Pointer. All of

the registers, stack, memory, flags etc. will be unchanged

from where the program was interrupted unless they were

modified by the user.

*
STEp will cause the Simulator to execute one instruction and

then return control to the Debugger.

*
PSTep will cause the Simulator to execute one instruction

and then return control to the Debugger unless that

instruction is a subroutine call. When a subroutine call is

encountered, the Simulator will execute the entire

subroutine before returning control to the Debugger at the

first instruction past the subroutine call unless a

breakpoint is encountered.

These commands can be abbreviated in the usual manner, but since

they are the most frequently used commands, special one letter

abbreviations (i.e. G for GO or STArt, R for RESume or

CONtinue, S for STEp and P for PSTep) have also been included

for the user.

56 -
It was generally perceived that the two breakpoints specified in

DEBUG-88 were not sufficient for debugging programs, so the

breakpoint structure was modified to accommodate sixteen

breakpoints. The command syntax for displaying the location of

a breakpoint is the breakpoint name followed by a carriage

return (e.g. BPO <cr>). If the breakpoint name is followed by

an equal sign and a carriage return (e.g. BPO =

<cr> ) , the

"null"
value is assigned to that breakpoint, or that breakpoint

is deactivated. If the breakpoint name is followed by an equal

sign, a value and a carriage return (e.g. BPO =

CS:A3 <cr>),

then that value is interpreted as the address at which the

breakpoint is to be set. All valid addressing modes that can be

used in the Debugger are acceptable for specifying the

breakpoint address. If a segment register is not specified,

then the Code Segment Register is used as a default.

Breakpoints are dynamically installed and removed from the

source code during simulation. This is done so that when a user

examines a memory location on which a breakpoint has been set,

the expected value of memory is found rather than the breakpoint

opcode. Just prior to starting or resuming execution, all

breakpoints are installed and the opcodes saved. When a

breakpoint is encountered, the breakpoint opcodes are removed,

the original opcode is restored and control is returned to the

Debugger. It is very important for the correct operation of the

program, the Simulator and the Debugger that the user place

57 -
breakpoints only on the first byte of an instruction but there

is nothing in the Simulator or Debugger which would guarantee

this. If a breakpoint is not placed on an instruction boundary,

this would most likely cause the incorrect operation of the

program rather than executing the breakpoint as expected.

All sixteen breakpoints can be treated collectively by using the

command ALLbp. This allows the user to see all of the addresses

on which breakpoints have been set. When the command is

followed by an equal sign and a carriage return all breakpoints

are removed from the program under test.

Any time a program is running and a breakpoint is encountered,

the user is notified and control is returned to the Debugger.

The user then has control of the debugging session and can use

any of the commands to examine or manipulate the registers,

flags, memory or stack as needed to modify the program's

operation .

In order to provide better control over a malfunctioning program

under test, it is possible to abort the Simulator and return

control to the Debugger at the next instruction by entering a

Control D. Thus if a user program is caught in an infinite

loop, or executing where no breakpoints were entered, control

can be returned to the Debugger in an orderly manner, the user

58 -
can set the appropriate breakpoints and then resume execution.

If the Debugger or Simulator become corrupted, a Control C or

Control Y will return the user to the VMS environment, but no

recovery of the simulation session is possible when this action

is taken.

4.3.3 Examine/Modify Commands

Examine commands are provided to enable the user to verify that

memory, registers, flags etc. contain the expected intermediate

values during program execution. The modify commands enable the

user to change the intermediate values if they are not correct

or to alter the program so that correct values are produced.

There are six commands which can be used to examine memory, and

they all require a full twenty bit physical address (i.e. a

segment register value and a displacement) in order to access

the desired memory location. However, these commands have been

simplified by assuming that the user desires to examine the

to by the values of the Code

memory location pointed current

Segment Register and Instruction Pointer. These assumptions are

modified by providing more information with the desired

easily

examine memory command. If no segment register information is

included, then the Code Segment Register value is used and the

desired memory address can then be entered directly in

hexadecimal or the contents of any register can be used as the

displacement. Alternatively, the Code Segment Register value

59 -
can be replaced by entering a hexadecimal value for the segment

or the value of any register can be used by specifying its name.

Some of these combinations may be meaningless in terms of the

utilized memory space, but the modes of addressing are

available.

There are also two qualifiers that can be used when displaying

memory, the LENgth and the TO parameters. The LENgth parameter

allows the user to specify how many times the command should be

applied, and it displays different amounts of memory for the

various commands. For example, the BYTe command displays one

byte of memory and the Pointer command displays four bytes of

2"
memory. The command sequence "BYTe LENgth will display two

2"
bytes of memory, but "Pointer LENgth will display two

pointers each of which is four bytes long, for a total of eight

bytes displayed. The TO qualifier specifies the address where

the display process will stop and therefore has a different

effect. To display three bytes of memory using the BYTe

"BYTe" "TO"
command, the user would enter nnnn nnnn + 3. Since

the WORd command displays two bytes of memory at once, the

number of bytes is increased to insure that the desired

"WORd"
information is displayed. Therefore the command sequence

nnnn
"TO"
nnnn + 3 will display four bytes or two words of

memory .

60 -
The available commands differ only in the way the contents of

memory are displayed to the user. The six commands are as

follows :

* Interprets the information

BOOlean: in memory eight bits at

a time and displays it as TRUe or FALse. If the eight bit

value in memory is an odd number, then it is interpreted as

TRUe.

* BYTe: Displays the information in memory eight bits at a

time, as a hexadecimal number.

* INTeger: Displays the information in memory sixteen bits at

a time as a signed, decimal number.

* Pointer: Displays the information in memory thirty two bits

at a time as a sixteen bit segment value followed by a

sixteen bit displacement value.

* SINteger: Displays the information in memory eight bits at

a time as a signed, decimal number.

* WORd: Displays the information in memory sixteen bits at a

time as a hexadecimal number.

All of these commands can be used to modify memory as well as

it. If the command is followed by just a carriage

display

return, then the information will be displayed but if the

61 -
command is followed by an equal sign and a value, then the

specified memory location is updated to the new value.

The STAck command is a special form of the memory display

command which simplifies the process of displaying the contents

of the stack. The STAck command uses the Stack Segment Register

and the Stack Pointer for the segment register value and

displacement respectively for accessing memory rather than the

Code Segment Register and Instruction Pointer assumed for other

memory accesses. This command can also have a LENgth qualifier

to indicate how many of the stack entries should be displayed.

No changes to the stack entries are possible using this command.

Registers are less complicated to address than memory, but the

same command syntax is used. To display a register's value, the

register name is followed by a carriage return (e.g. AX <cr> )

and to modify the contents of the register, the register name is

followed by an equal sign, the desired new value for the

register and a carriage return. Both the short and long forms

of the register names are supported (e.g. AL and RAL) . The

flags can also be assembled and displayed as a register using

the RF command. It is possible to display the contents of all

registers including the assembled Flags in the RF register by

using the REGister command.

62 -
In a similar manner, the flags can be examined and modified. To

display a flag's state, the flag name is followed by a carriage

return (e.g. ZF <cr>) and to modify the state of the flag, the

flag name is followed by an equal sign, the desired new state of

the flag and a carriage return. Although any hexadecimal value

can be entered for a new value, all bits off will be interpreted

"clear"
as or "false". This implies that any other value will

"true"
result in the flag being set or interpreted as . All nine

flags can be displayed at once using the FLAg command.

The Debugger also allows the user to examine the I/O ports

without altering the Data Index of that port. This means for

example that the user can look at an input port and examine the

next value the program will retrieve without causing the Data

Index to advance. There are two commands to examine or modify

the I/O ports, PORt and WPOrt. The PORt command operates on

eight bits of data in either an eight or a sixteen bit port, and

the port can be an input or an output port. Likewise the WPOrt

command operates on sixteen bits of data for an input or an

output port. However, the Debugger will correctly display or

modify sixteen bits of data if the upper address of a sixteen

bit port is specified for the WPOrt command. The commands also

allow the datum stored in the ports to be modified in the same

manner as the memory commands. Writing a datum to an output

port will overwrite the last value stored and writing a new

datum to an input port will modify the datum that is about to be

63 -
read from that port. It is not possible however, to move

"forward" "backward"
or in time for a given I/O port and examine

or modify other data values. The user only has access to the

data that currently resides in the ports. The LENgth and TO

qualifiers are also supported, and cause multiple ports to be

examined if they are present in the I/O Map.

Three types of commands are provided in the Debugger, utility

commands, execution commands and examine/modify commands. All

of the commands operate in a similar fashion, so that the

command followed by any operands or qualifiers and a carriage

return will display the requested information and the command

followed by an equal sign, a value and a carriage return will

modify the object and set it to the new value.

4 . 4 Limitations

As previously indicated, the Debugger was intentionally

developed as a primitive tool to encourage the user to remain

closer to the actual operation of the hardware. This means that

the essential commands for debugging were developed and

only

some features were intentionally not supported. These

unsupported features include symbolic debugging, evaluation of

expressions, manipulation of the display radix, disassembly of

instructions, support for displaying line numbers and module

64 -
names and support for compound commands. See Appendix G for a

complete list of DEBUG-88 commands that are not supported.

Since symbolic debugging is not supported, it was not necessary

to maintain a symbol table in the Debugger and therefore many of

the DEBUG-88 commands that reference or manipulate the symbol

table are not supported. Symbolic debugging is not supported

because it discourages the user from thinking about how the

processor is interpreting the segment register and displacement

values. The evaluate expression command also relies upon the

symbol table for the correct interpretation of expressions, and

since the symbol table is not maintained the evaluate expression

function is not supported.

The option to change the radix of the information displayed is

not supported. Although there is nothing precluding the support

of this feature, most of the literature on the Intel 8086

processor is in hexadecimal and support for binary, octal or

decimal display formats seemed counterproductive. When learning

"thinks"
a foreign language, it is easier if the user in the new

language rather than think in the old and translate into the new

language, so most of the information displayed by the Debugger

or entered for commands is in hexadecimal notation. The use of

decimal notation is generally confined to those instances where

integer counts are required by the VMS environment and where

65 -
errors would cause the Simulator or Debugger to malfunction.

Anywhere a decimal value is required, the communications with

the user clearly indicates this.

The disassembly of instructions is likewise not supported.

While it is a feature found in many of the more sophisticated

debuggers, it also takes the user a step further away from the

reality of the machine code world. The display of line numbers

and module names is not supported since this feature would add a

level of complexity to the Debugger which is not essential to

its proper operation. The use of compound commands is also not

supported since the typical user will be a first time student

and most user programs will not be complex enough to warrant the

inclusion of compound commands. Instead of supporting compound

commands, additional breakpoints were included to increase the

power of the Debugger.

These limitations were carefully evaluated to insure that the

essential commands were provided for the user to debug a

program, and the complexity of the Debugger was minimized.

66 -
4 . 5 Summary

A Debugger has been developed to provide the necessary commands

to control, monitor and modify a program under test.

Consistency and ease of use were major considerations in

developing these commands as well as providing a smooth

transition to the Intel program, DEBUG-88. Commands have been

provided to interface with the VMS environment, start and stop

the Simulator and examine and modify registers, flags, memory

etc. as required to debug a program.

67 -
 Chapter 5

Maintenance and Support Features

5 . 1 Preface

The Simulator uses an Opcode Look Table to obtain information

Up
on how the opcodes should be interpreted. In order to develop
the Opcode Look Up Table a program, OPCODELUTGEN , was developed

which can also be used for any necessary maintenance. Likewise,

the Debugger uses a Keyword Look Up Table to interpret commands,

and the maintenance program KEYWORDLUTGEN has been developed to

create the look up table and can be used to make any necessary

changes .

There are several command procedures and support programs which

were developed during the course of designing and building the

Simulator. These tools can also be useful in performing

maintenance such as expanding user memory, changing the number

of I/O ports or changing the amount of data allowed per port.

The Simulator response time must also be taken into

consideration when modifications are made so that it remains

acceptable to the user community. Some installations may not

support all of tools (such as the DEC/MMS build commands) but

other alternatives can be developed to provide the equivalent

functions. Some of the extensions to VAX Pascal were very

useful in the development of the Simulator. The global and

68 -
external attributes for variables and procedures, the unsigned

data type and associated operators and the include feature were

some of the fundamental building blocks for the Simulator. The

asynchronous trap also required a variety of extensions to

support the Control D function.

5 . 2 Opcode Look Up Table Maintenance

The Simulator uses an Opcode Look Up Table to obtain the

necessary information for the interpretation and execution of

each opcode. The look up table is stored as an external file so

that maintenance of the table can be done by a qualified

individual without recompiling the Simulator. A program was

developed (OPCODELUTGEN) to create the table and provide the

necessary support functions for maintaining and enhancing the

active opcode set. This program also provides a print function

to generate a hard copy of the table.

The OPCODELUTGEN program allows the user to modify the Class,

Key, Direction Bit Present and Width Bit Present fields of the

table. The Class field is limited to a one letter abbreviation

for each of the six valid classes plus the Extended and Invalid

classes. The Key field inputs are limited to values from zero

to eight, although all values might not be valid for all

classes. The Direction Bit Present and Width Bit Present fields

are filled with true/false responses depending upon whether the

69 -
opcode requires a direction bit and/or a width bit. The table

is accessed by using the hexadecimal value of the opcode as an

index for the information.

Although this program is provided to perform maintenance on the

Opcode Look Up Table, it requires a knowledgeable and extremely

careful maintenance programmer to make changes.

any

5.3 Keyword Look Up Table Maintenance

To simplify the operation and maintenance of the Debugger, its

commands are also stored in a separate file which is loaded into

a look up table at execution time. This makes the Debugger less

sensitive to maintenance changes of the keywords, but it also

requires an additional program (KEYWORDLUTGEN) to perform any

required maintenance on the keywords.

The KEYWORDLUTGEN program provides the maintenance programmer

with the ability to change the spelling of a keyword name or add

keyword entries as needed. There are one hundred one (101)

entries in the keyword table, including six spare or unused

entries for future commands or abbreviations as deemed

necessary. It is the responsibility of the individual making

any modifications to insure that the change or new entry in the

keyword table does not conflict with an existing entry and

cannot be interpreted as a hexadecimal number. The maintenance

70 -
program does not perform any checks for collisions or prevent

the entry of abbreviations which would render the Debugger

inoperative. The maintenance program is provided primarily for

the simple expansion of commands, changes in spelling (such as

"LOG"
renaming the command to "JOUrnal") and the addition of

other abbreviations as deemed expedient by the user community.

5.4 Command Procedures

One of the optional DEC utilities is the Module Management

System (DEC/MMS) which minimizes the amount of work to be done

to build a large, complex software system. DEC/MMS provides the

user with the capability to describe the relationships between

software modules and then when one of the modules has been

modified, these relationships are reviewed and a user defined

sequence of operations is invoked as appropriate. This provides

the ability to compile, update an object library and link only

those modules which must be processed to properly reflect the

recent change. Four such DEC/MMS command files have been

created to support the generation of the Simulator, the I/O Map

and Data generation and viewing programs, the Opcode Look Up

Table maintenance program and the Debugger's Keyword Look Up

Table maintenance program. If the user's installation does not

support DEC/MMS, command file (COM) procedures have been

developed to build the programs, but they do not have the level

of sophistication of DEC/MMS and cause all of the support

modules to be compiled and updated in the library, even for a

71 -
small change which might otherwise affect one module. If
only

these COM procedures are used, excess work may be performed, and

the user should consider issuing the necessary commands manually

for small changes.

5.5 Expansion And Modification Capabilities

Various expansion features were reviewed in the previous

sections. Those with a significant impact on system performance

or response time are summarized here.

It is possible to expand the memory space for the user program

beyond the present eight kilobytes in the Simulator. The file

"HighMemoryLimit"
CONST. DEFN must be edited, and the constant

given a new value. (It is recommended that no changes be made

"LowMemoryLimit"
to the value of the constant .
) Since this is

the number of VAX words that are reserved and each word contains

four bytes of Intel information, this value should be twenty

five percent of the total desired memory including interrupt

vectors, stack, data and code space. Once this modification is

made, the Simulator, IOMAP86, IODATA86, KEYWORDLUTGEN, and

OPCODELUTGEN must be recompiled and relinked. If DEC/MMS is

used, the minimum number of modules needed to support the change

will be recompiled and relinked. If DEC/MMS is not available,

all programs should be recompiled and relinked to ensure that

all references to the altered variables are correct. Since the

72 -
file CONST. DEFN is used in many modules, this modification is

not a candidate for performing the updates manually.

As the user memory space is increased, care must be taken to

monitor the Working Set Size allocated to the user by the VMS

Operating System. When the size of the Simulator image exceeds

the allocated Working Set Size, the VMS Operating System will

start page swapping to keep the active portion of the user

program in memory. This may appear as a severe degradation in

response time and new user parameters should be negotiated with

the computer center.

The maintenance person also has the ability to modify the number

of I/O ports available to the user community. It should be

noted that modifying the number of I/O ports or the number of

data points per I/O port will invalidate all existing maps and

data sets for all users, and all of that information will have

to be re-entered. No provision has been provided to translate

from one map size to another or from one data set size to

another. The users should also be made aware that increasing

the map size with the same number of data points or increasing
the number of data points with the same map size will make the

Simulator start up time longer, as additional data points must

now be loaded.

73 -
To modify the number of I/O ports or the number of data points

per I/O port, the file IOCONST.DEFN must be edited. The

Ports"
constant "Max Number Of 10 will modify the number of I/O

Words"
ports while "Max Number of 10 and "Max Number Of 10

Bytes"
must both be modified to increase the number of I/O data

Bytes"
points. The constant "Max Number Of 10 must always

Words"
remain four times the "Max Number Of 10 since there are

four bytes of 1/0 data per word reserved on the VAX. Once the

modifications are made, the Simulator, IOMAP86, IODATA86,

KEYWORDLUTGEN, and OPCODELUTGEN must be recompiled and relinked.

If DEC/MMS is used, the minimum number of modules needed to

support the change will be recompiled and relinked. If DEC/MMS

is not available, all programs should be recompiled and relinked

to ensure that all references to the altered variables are

correct. Since the file IOCONST.DEFN is used in many modules,

this modification is not a candidate for performing the updates

manually.

During the development of the Simulator, a maximum VMS path and

file name length was established at forty characters. This can

be changed by editing the file CONST. DEFN and selecting a new

"FilenameLength"
value for the constant . Once the modifications

have been completed, the necessary program modules must be

recompiled and relinked for the Simulator, IOMAP86, IODATA86,

KEYWORDLUTGEN, and OPCODELUTGEN.

74 -
Provisions are available for modifying the amount of memory, the

number of I/O ports, the number of data points per I/O port and

the length of the VMS path name and file name. Once these

modifications are complete, the Simulator and support programs

must be recompiled and relinked to incorporate the changes.

Some of the response time implications and precautions

surrounding these changes were also discussed.

5.6 Language Extensions And Deviations

One of the goals in the development of this Simulator was to use

a structured, high level language not only for ease of

development but also for ease of maintenance. The language

'
chosen was Digital Equipment Corporation s implementation of

Pascal and the choice was based in part on the availability of

the compiler on teaching systems and the supported extensions to

the language. There were only three Simulator features that

required the author to digress from Pascal. These were the need

to interrupt the Simulator at the next instruction (Control D),

the need to support interactive keyboard input and output and

the need to check for the existence of a file prior to opening

it to prevent the Simulator from crashing as the result of an

incorrect user input.

75 -
Many of the DEC extensions to Pascal were used in the

development of the Simulator. These included the following:

The ability to assign a procedure the global attribute and

reference it as an external procedure from another module

was essential in order to segment the development and

debugging of the Simulator.

"include"
-

The ability to another file at compile time was

essential to maintaining version control. This guaranteed

that constants, data types and variables were only defined

in one place for all modules and support programs.

The ability to define global variables in one procedure and

reference them as external variables from another procedure

simplified the module interfaces. For example, the Memory

space is declared as a global variable, and defined at the

highest level module even though it is only accessed by two

of the lowest level modules. Since the variable and its

"include"
associated type are defined in files, they are

available to procedures that explicitly require them.

only

However, if they were passed as part of the procedure call

from the highest to the lowest module, all modules would

have access to Memory in an uncontrolled fashion whether or

not they needed the access.

76 -
 The ability to define constants in binary and hexadecimal

formats increased the accuracy and readability of their

definitions .

The data type UNSIGNED and the unsigned operators UTRUNC,

UAND, UOR, UNOT, UXOR, UINT and INT allowed the Simulator to

operate in an easily understood manner on bit patterns.

The use of a VOLATILE variable and ASYNCHRONOUS and UNBOUND

procedure attributes were required to support the Control D

function .

The ability to write variables to an output device using the

HEX macro, including parameters to control the field widths,

was of great value in maintaining consistent entry and

display formats.

The ability to OPEN files as sharable made the use of look

up tables practical.

The reader is referred to the DEC documentation on these Pascal

extensions for further definition, but the Simulator would have

been more difficult if not impossible to develop without them.

77 -
As previously indicated, the development of the user I/O

interface and the support of the Control D operation required

the use of non-Pascal features. When a user is performing I/O

with a Pascal program, Pascal requires complete lines to be

entered before they are processed. The Simulator needed the

ability to accept and process a single character without a

carriage return in order to support I/O to the user terminal

with the IN and OUT instructions. This support was provided by

linking in the VMS Library routines and performing $QIOW calls

to the assigned terminal. This routine is essentially a

" I/O-wait"
queued-
call to the specified device and it was

established to accept one character at a time. Implicit in the

support of these procedures was the facility in Pascal that

allowed them to be included in the compilation. Without the

LIB$STOP, $CANCEL, $ASSIGN and $QIOW procedures, terminal I/O on

a per character basis would not have been possible.

The support for Control D required the ability to accept input

from an asynchronous trap, or an AST with the ASYNCHRONOUS and

UNBOUND attributes using the previously mentioned VOLATILE

"accept"
variable. This allowed the program to a Control D

whenever is was typed, record its receipt and continue with the

normal processing. The Simulator then looked at the variable

upon the completion of an instruction and return to the Debugger

if a Control D had been entered. This provided the user with

78 -
the ability interrupt the simulation session and return control

to the Debugger without

aborting the program.

A FORTRAN subroutine was also acquired to check for the

existence of a file prior to opening it. This provided the user

with a greater degree of fault tolerance to misspelled names,

invalid directories, subdirectories or path names and allowed

them to recover from these problems rather than the

causing

Simulator or Debugger to crash when they attempted to reference

"non-existent"
files. This is a blessing to those users who are

prone to typographical errors.

Pascal was chosen as the high level language in which to

implement this Simulator based in part on its availability and

its extensions which made this project practical. Input and

output to the user's terminal required "queued I/O wait"

calls

and support for Control D required additional features of VMS.

A FORTRAN subroutine was also included to improve the fault

tolerance for the user file names.

5 . 7 Summary

During the design of the Simulator and Debugger, maintenance

programs were also developed to support the external Opcode Look

Up Table (OPCODELUTGEN) and Keyword Look Up Table

(KEYWORDLUTGEN). Additional command procedures and support

79 -
programs were created to assist in the development process. The

Module Management System provided the capability to minimize the

amount of compilations required, while providing an up to date

version for debugging. This minimized confusion and provided a

certain amount of configuration control over the process.

Certain expansion capabilities were provided by changing any of

four key constants to add user memory space, I/O ports, I/O data

or longer path and file names for VMS. The Simulator was

implemented in Pascal for ease of development and maintenance

and the DEC VMS extensions proved essential in the

implementation process.

80 -
 Chapter 6

Summary and Conclusions

6 . 1 Preface

The primary reason for undertaking this to

project was develop a

Simulator for the Intel 8086 microprocessor which would permit

"hands-on"
students to have experience without the expense of

the processor hardware. In a teaching environment, it is

difficult to justify the cost of a set of dedicated hardware for

each student, so it was the goal of this project to provide a

Simulator on a multiuser minicomputer for students to debug

their programs to some level of proficiency prior to using the

hardware. As a result, students require less time with the

hardware and it does not become the limiting factor in the

learning process. It is the author's opinion that this goal has

been achieved.

A secondary goal was to demonstrate that a Simulator could be

developed in a modern, high level language which simplifies the

development process and aids in the maintenance of the Simulator

after the project is completed. Pascal was chosen as the high

level language and the minicomputer of choice for the

implementation was the VAXcluster from Digital Equipment

Corporation. DEC's version of Pascal provided several

extensions which proved to be essential to the development of

81 -
the Simulator, and it has been demonstrated that building a

Simulator with a modern, high level language is indeed

practical .

6.2 Observations On The Simulator

The following observations have been made regarding the

development of the Simulator and its subsequent performance:

time"
-

The Simulator has a "reasonable response in the

student environment. When the Simulator is executing on a

VAX 8600 with approximately 100 other student users, the

response time for communicating with the user is about the

same as the response time when using the editor.

The size of the complete Simulator and Debugger with all

look up tables loaded, eight kilobytes of Simulator memory

allocated and eight I/O ports each having 256 bytes of data

is less than two hundred blocks of DEC memory. This compact

size also contributes to the speed of execution.

-
Although minimal user feedback has been obtained, the

Simulator appears to satisfy the need for a learning tool.

82 -
Initial user feedback however, indicated that default values

were expected for the Stack Segment Register and the Stack

Pointer and that they should be consistent with the Intel

Debugger. This was despite the fact that the User's Guide

provided with the Simulator and Debugger clearly stated that

no initial values would be assumed for any registers except

the Code Segment Register and the Instruction Pointer when a

program start directive was included in the source code.

This reinforced the author's perception that users are

frequently unaware of the extent of the services provided to

them with more sophisticated debuggers and that first time

students need to understand that the user is responsible for

everything when they work with a standalone microcomputer.

The Simulator was not intended for a professional or

industrial environment and does not appear suited to these

applications. The simulation of input and output is too

limited for "real

world"

applications and the Simulator does

not support any calls to library utilities or interaction

with an operating system to take advantage of already

existing software. The cost of developing improvements to

make this system suitable for the professional or industrial

environment does not seem justifiable when applications for

these environments ultimately need the hardware anyway.

83 -
As a learning tool, the Simulator supports most of the

instruction set of the Intel 8086 processor, including the

input and output instructions. However, the use of external

programs to establish I/O Maps and to edit input data and

review output data makes it awkward to use I/O operations.

The user must construct an I/O Map, key in data, execute the

test program, and then review the output all of which

requires running four different programs before the user can

review any I/O results. A minor change in the input data

set then requires three of the programs to be run again and

this quickly becomes confusing and time consuming for the

user, but it was the most practical method to provide this

capability -

Conversely, interactive I/O with the user was implemented in

a more elegant fashion than expected. Using the $QI0W

operation directly from Pascal on a per character basis

provided the necessary support for the user program to

communicate directly with the terminal.

Likewise the use of the asynchronous trap or AST to

implement the Control D function was also a very elegant

solution for this feature. The ability to provide support

for the Control D function also increased the user

friendliness of the system.

84 -
6.3 Observations On The Debugger

The following observations have been made the

regarding

development of the Debugger and its subsequent performance:

The Debugger turned out to be much more complicated than

initially anticipated. The Debugger design went through

three major revisions before an acceptable set of commands

and implementation techniques were identified. In

retrospect, the Debugger took almost as much time to develop

and bring to an operational state as the Simulator itself.

The limited functionality of the Debugger is a result of the

author's personal experience in teaching others how to use

minicomputers and microcomputers. Many users are unaware of

the extent of the services provided by an operating system

or debugger during program development and they don't

realize that their program is responsible for the initial

values of various registers when their microcomputer and

program are buried inside a product. The nature of a

teaching tool is to encourage students to develop good

habits and this philosophy influenced the assumptions

implemented in the Debugger.

85 -
 the to support
-

Likewise, author chose not symbolic debugging

to encourage the user to develop a better understanding of

how the system operates. Symbolic debuggers are

productivity aids and are as essential in program

development as high level languages, but students need to

learn what the symbolic debugger is doing for them and to

them. If for example, the segment registers are not

established correctly by the program under test, addressing

problems can be difficult to isolate. If the user manually

traces through the address computation the problems are

usually more apparent than if a symbolic debugger is used.

This is especially true when segment registers are used,

since a single memory location can be accessed by any one of

several addressing schemes and a variety of addressing

modes .

6 . 4 Summary

The development of the Simulator and the Debugger represent a

significant tool set for enhancing the process of learning the

Intel 8086 instruction set.

86 -
 Chapter 7

Enhancements

7 . 1 Preface

During the development of the Simulator, a number of

enhancements were suggested to broaden the scope of the project.

Some of those enhancements have been implemented and many of

them improve the user friendliness of the Simulator, the

Debugger and the other support programs. As with any project

however, improvements can be made forever but there is a point

when the incremental cost of the improvement exceeds its

benefit. While there are still valuable enhancements that can

be made to this Simulator, the primary objective of developing a

usable Simulator for the Intel 8086 microprocessor written in a

modern high level language has been achieved.

There remains a list of improvements and enhancements which

could expand the usefulness of the Simulator. They can be

divided into four categories: enhancements for the Simulator,

the Debugger, the support programs and those which would expand

the scope of the Simulator to provide support for Intel library

routines and operating system functions.

87 -
7 . 2 Simulator Enhancements

+ The Simulator was designed to support the Intel 8086

microprocessor, but the architecture of the Simulator was

designed to permit limited expansion of the instruction set.

A minimal amount of effort would be required to support the

Intel 80186 processor with its expanded instruction set.

There are an additional seventeen instructions for which

code must be developed and some of them will require using a

"spare"
few of the slots in the Opcode Look Up Table, while

others will require further resolution in the extended

class. However, the architecture of the Intel 80286 and

Intel 80386 processors would require a major rewrite of the

Simulator and would best be developed separately, using this

Simulator as a model.

+ As an enhancement of the teaching tool, the Simulator could

be expanded to support the Intel 8087 math coprocessor.

Such an expansion could be most useful, both to add new

capability to the Simulator and as an exercise in developing

VAX applications which must be coordinated as true

coprocesses .

88 -
+ A better method could be developed to support input and

output operations. This could take several phases, one

being the integration of the creating, and viewing

editing

of maps and data as part of the Debugger.

A second phase could be to provide real hardware interfaces

for the user to manipulate. This would require extreme care

on a multiuser system and might not be cost effective. The

real benefit of this phase would be the experience of

encountering the unexpected when performing I/O. The

current configuration does not provide any real opportunity

to experience the impact of noise on a signal, or the

response of a system when a circuit design is incorrect or

improperly implemented.

+ It has also been suggested that the Simulator monitor,

record and provide to the user the number of clock cycles

that were required to execute the program. This was not

originally included because of the magnitude of the

Simulator project, but it could be a useful measure of

program efficiency. It -would however, require extensive

modifications to almost every module in the Simulator and

hence would be a project unto itself.

89 -
 + The Intel 8086 uses a bit in the Processor Status Word, the

Trap Flag, to permit single step execution of the program.

The Simulator does not support this flag, other than to

permit its state to be modified. The function of single

stepping through the program is provided by the Debugger and

hence support for the Trap Flag was not considered

necessary. To be an accurate representation of the

processor, support for the Trap Flag should be provided and

linked to the Debugger in a coherent fashion.

7.3 Debugger Enhancements

+ During the development of the Debugger, several problems

were encountered which are minor inconveniences but

represent flaws in the implementation of the Debugger. One

of these problems occurs when a breakpoint is set on an

instruction and the instruction is executed in single step

mode. The Debugger does not give any indication that a

breakpoint had been encountered. As a user, this

notification could have been a reminder that other

operations needed to be performed at this point in the

program.

90 -
+ The user friendliness of the Debugger improved if
might be

the Debugger could check for the possibility that the user

placed a breakpoint in the middle of a multi-byte

instruction. This could be accomplished by scanning the

addresses in the breakpoint table as each instruction is

being executed. If a breakpoint was encountered in the

middle of a multi-byte instruction, this could then cause an

unexpected breakpoint interrupt and notification to the user

of the abnormal situation. It would require a major

revision in the way breakpoint information is stored and in

the way memory is accessed to assemble all of the bytes

needed to complete an instruction.

+ Presently, there is nothing to prevent the user from

inadvertently placing two breakpoints at the same location

and causing the Simulator to be unable to execute the

original instruction on which the breakpoint had been set.

A simple check of the breakpoint table could be made prior

to adding the breakpoint to see if that address has already

had a breakpoint set on it.

+ Improvements could be made to the logging of user commands

in the Debugger. Presently, the user can create a file of

the commands which are entered during the debugging session,

but there is no process by which the user can automatically

91 -
 recover from the log file. This feature would be

particularly useful when accessing the host system remotely

and communications are lost or in resuming a particularly

long and complicated debugging session.

+ An additional feature that would benefit students and

instructor alike is to be able to log the results of the

Debugger commands .
Presently , the user can examine a

register or a memory location and the information is

displayed on the user's terminal. Unless that is a hard

copy terminal, or the terminal has a printer port and a

printer attached, it is not possible to obtain a hard copy

of the information for discussion. The log command of the

Debugger could be expanded to write anything displayed at

the terminal to a log file, or it could be implemented to

separate the commands to one file and the results to another

file so that the previous feature, recovery from a log file,

would still work.

+ Although symbolic debugging is not supported and the author

does not believe it should be, others may not be of the same

opinion. An addition to the Debugger which may be deemed

appropriate could be the addition of symbolic debugging.

92 -
 + The Debugger could also be expanded to include support for

compound commands. Commands which permit loops of

instructions to be executed or which support logical

operations would significantly increase the power of the

Debugger .

+ An additional feature that could be supported in the

Debugger is to allow the user to control the radix of the

information which is displayed. Presently, the radix

information is "hard coded"

into the Debugger and the base

used for displaying information is what the author felt was

most useful. Other users may have different needs and

desire to dynamically alter the radix of the displayed

information.

7 . 4 Support Program Enhancements

+ As previously indicated, improvements could be made to

permit easier use of the I/O operations. An additional

feature that should be considered is free form editing of

input data rather than forcing the user to specify which

byte is to be changed. The current approach is admittedly

primitive, but it was necessary to provide a capability for

93 -
 editing I/O Data, not in making everything elegant. There

is substantial room for improvement in this area.

+ The likelihood of future users the Debugger's

modifying

keyword table is very high. There are substantial risks in

making modifications to the keyword table and having a

resultant table which is flawed. It is possible to add more

robustness to the editing process and perform certain checks

to see if the desired change conflicts with an existing

entry or could be misinterpreted as a hexadecimal value

before accepting the input. Also the identifier value is

not specified in a very robust manner and unsupported values

can be created which would result in confusion.

+ Likewise the Opcode Look Up Table maintenance program could

be made more robust. The maintenance programmer modifying

this table must be excruciatingly careful when making

changes so that the Simulator works correctly. While

changes in this table are much less likely, the expansion of

the Simulator to support the Intel 80186 processor will

result in a need to modify the Opcode Look Up Table. Any

modifications to this table should be thoroughly understood

before attempted.
they are

94 -
7.5 Library Routines And Systems Enhancements
Operating

+ The power of the Simulator be

could greatly enhanced by

including support for existing Intel library routines. This

could be accomplished in two ways: the routines could be

interpreted, rewritten in Pascal and assembler calls

directed to the appropriate Pascal procedures, or the

necessary library routines could be physically linked,

located and then loaded with the program under test, thus

causing the Simulator to execute the library routine. The

first approach requires a complete and exact understanding

of each supported library routine as implemented by Intel

and some of these routines may be "trade secrets".

Implementation at this level would also have to replicate

any flaws in the original code. The second approach assumes

that the library routines are self-contained, or at least

that all of the pieces are included in the package that is

loaded with the program under test. This would also require

a much larger memory space and could significantly impact

the Simulator response time.

95 -
 + Likewise, support for any operating system functions could

be implemented in either of the two above mentioned

approaches. Support for an operating system would

facilitate the transition from a simulation environment to

operation on the target hardware.

+ As a these
subset of features, a selected peripheral or

class of peripherals could be supported. It might be useful

to support a time of day clock, a timer, disk I/O or a

printer. The effort expended to implement these features

needs to be evaluated carefully against the cost and

availability of hardware to perform these functions on the

target system.

7 . 6 Summary

There are a number of enhancements which would increase the

usefulness of the Simulator. A careful and thorough evaluation

of the impact of any change should be done before it is

implemented to minimize the undesirable side effects.

96 -
 Appendix A Sample Programs

8.1 DAC Program Listing

x
I x x x J x
N o a
0- "
10 w
10 u. uj rj
o
u
_ lij (J ID " -*

OD O
o O O O
CD
m i"

z x x x x
j-
u s a o -

CD m n to
_
j
o-
r cd
CD uj o
o c o o o o

8
"
z
j
* i
m
i i
o
i
a. _

0- * -I
CD UJ Q
o
,.

z
h*> i 5 S i 5
1"- Uj UJ K CD N
c S o n n
o
L. o o o o o
tl
*>
L z I I X X x
u o w in *
II a
> Q N n
0-
C
0 8 8 8 8 8
u
-_

CF
0
z
o IE I S
^H

ic
0-
""
q ui
s
a
y
-o
&
n
c O O O O w

u
E
0 cc JZ I I X X x
n ui in o uj
*> D 05 o
D 4
U. u. io - *
u ^
. a. cd
LOJ
Ul
11] U UJ U ?
5 *>o
It > o
Q *J
a
n 3
z x x x
CF CT
o J 4) <l O
<r '""' *"
5 TJ
D to 03 tO
CO ui y
O
*
UJ
r-
O
o
y
O
O
a. I-
0
u. 4J UJ z
o z Ul
Ul
o *< o o
a
Q
a
TJ o
Ul 3
in a i I S I 1
r
LU TJ
01 Q
Ul
Ul 0 cn
E + D
C il
Z ID CD
r-
4J
o
3 z
N -0 LU a 10 a.
> CD (J +* 10 1
CC 3 M c a
1-
cc in D O CD r-

u lu a o a a
a -I ID
c m u

UJ Oi Q
Ul D U
cn c
U 3 Ul . N Ki 10 -0 r. m
CC
uj a z
_i o o -a "

m cc u co -i

e u a E
ui mm
cn a
cn z

CD -

O - Q >
CC ^ UJ CD
(J CO U
Ot CO <I Q
>. _J LU
in a. *
,0 CD O
CD v Ul >
- 4JZ
v CD 3 -

So a
to o cc _

v z ui 2

i Chi m I N * * D
3
,S iSS u
K ! 9555S9
8888888
22ffi 18888888
gg S

97 -
 UJ
O
a z
a. Ul
o 41
CD o O U Z
CD
U.
z U U.
Z u.
in
a u.
u *t o
CM 0 *> c o
o C B V
* E a e
E P> 0
n Z z
o T
D I
in z
10 cm
CM D III
4)

z Z a
TJ *>
c
-0 Q
N c * ii
CO D 0 . 3
CM in
O
*> +> 0 ti
a. W ll
*> L. *
-f L.
C c ^ OU j M-
z z 44 4. u a 3 a
u 0 0 * a.*> J
Ul u. a 0. *> a c 3 U
as V 0 4J 0
0 0 4J 3
*> *i m w 3 a u
< 0.4J
z i: CD 0) 01
0- N C 3 u
u Q in <D>0 c
m c . IN CM
r-
a a a. a. in e
cn 3 3 c L
u .. u +* .. - Ql
- CO +* W <<auu 4J
z z _i CD _l u il C . (m II
CM CO a CO 01
-CD a. a. a. a. a
Ul 3 3
t'l a. 1- LL
a
o **. r-
a o
r-
Q K
CL I
Z X CM a. 3 CD i:
c in 3 a o D t-
a v cc 01
n 0- rv r
o LU
-.-. ..
a
-o *>
z z
a X a O UJ CJ
K u r-
a u 0-
Ii. O
z IZ 1-
c <-
r. o-
u. _l

UJ -1 u Ul a x r-
X: < * 0-
u. x u
in r Ul cn <l r a tn c 0 - a G
a cn m a D m UJ
3 3 3 3 3 3 3 3 Z UJ 3 a 3 z ui x cn X tO Q_ CL XX X X X
O Q a a a Q Q Q UJ ID O _i o ui co co a a to co co a q o a a u.

01 >>>>>>>> > > >

CO oooooooo o o -
a
q co a Ul
cc 1-
r-
Q
ui Ul lu co a; O -

u X K Z IO f- x U r-

cc (J o z cc a. la u iu ICC
3 O Ul 3 Ul O Z 1- c U <E
u O _JCC O 50UICr- a t-
a 01 u u. u Q J JQ01 CD CD CO o cn

Ul 0> CM Kl
cc O in-4ooct>o.'rMnrin'0Na}f>-.CMr')<rin
LU z - CM CM CM CM CM MNNNNKlMnKirinnCrlrl?****!!
_l

CD

Ul
10
01
<x

o
a
u
c

0
a o
o
O N
CD O CD
NNH------NNNnni'J*,HH)NOO r-
co c-
O -0
n o o o o oo o y O t-
o OOB
CO 4 O 0-
IM a CM D-
O -0 T 10 UlCO -i (J Q 10 O O 5 -> l> a
O fO CM Ul CD N CD Ul CMIO ff O N Ul N U. CD CM U <0 O O
-
= t- 8 BB

a
- n
u.
o 003<ZUUICM'-003aUUIrM<>'4iai<IUUIO(M i ? i SCO
SiniOinr5io<<i'a4'0<<i'<iNiSNNr-r<.rsiv(BCDoa - i
8 eOO000000000000
6
18 O O 1 o
CD j 5 o o o o o o o o o i O O 1 o o

98 -
Ul
o
a.

oo
CD

to
o
0-

in

B
3

f o
L a >
II ** B
v C n o >- L
X) C XI 0 >. c B
C 3 JJ *j * V
Il Of* C -M 4J k. B
JT U 0 *" 4. X * XI B XI 4

L O B xi r *> o>
B C I. T! a c f B B B
> -* II B X . N L.
O XI O o C 0 *i E*
*> e * *J +J Ul B B v. B
II -3 L L L
> C -w XI + +1 + 3 O 4. > 0
o nil c c b h-
c a *> B ** m +>

E N > .w - > * -p. +< > v. -. a

II N c BO so n r 0 3 CD B c B B
cc - m a a. o a. to to a. o Z CC CD a cc

Ul -I

Z CL
<-
I-

3 10
o <X to O CC
r- r-
CC z <I
Ul X z CC
z 1 q a. z > a LU
t-
cc to . i i c z
Ul I-
cc z <I i-i u. -I cc Ul
> 01 Ul Ul r-
-, u. Ul Ul D 3
o Ir-
-1 1 CD > JlLX a u I O
Ofl. z Q lj * u a Ul in CJ CO
.. O 3 V - _i
- - - - > cc a a
X x Cl O X 1 x-hmxuj-Ixxx x a o z z
CUIDUQUCDQ i- cc U 3 Ul
QJU u to Ul
o
a u
Q
<X LU
z -I CC Cl Z Z Z Cl u
co > > > > <r UUBIJ>J>r- > Ul a. B >-
a. m cn en > caiir-

3 3 " O 3 LU ZZ3<XOZQ3 a z O O _l D33D OOOOIll

01 E a _l x-HUIOZO iljii clclcle.. _io.o.a.cc

Z > Ul
Ul -j a
LU CD ..a o
U I > i u
cc Ul Ul Ul I
3 cc > -IE U
O o ui - a
Or-
CD 3 Q

cc Ul *MCI>ONMl0'0MllCO-iNKi*in'0MDfrO-NM*r'0MD-O-NMin
Ul z vvinnnioionionioin4i-o4i-(i-a4i-ii<04i-OisNNr<.iNNrviSrvNCDaDaiaicDco
_l

CO

Ul
CO
01
a
oc cc cc cc
o
cc
(J
a
E
*
CD o o o
o o o
CD O *
0
CD OD CD 8
Ul ?
t
c Q CM
CD
Ul
O -0 Ul -g
i n oo w Soul. Ul Ul
0-
co c n r> co CO-O-e-CO-r'i'IU. CM CO UO"l CM Cf-
CO Q ri
co
co
g
co OTvinuicoacoui n ui u. ui o-
in in co ui m in o- u ti :
CD o cm co u
v. E
e - I) B U U - . SM><BUILI04 MtCDBQUIlL O <T r -0 N CO 0- I III
CM CM CM CM CM CM M MHririrlrlrl* jTJ'f'SSS'ioioinriiDiom i CD
CD
8
,,...,

O 8
OO
v
000O
wwvVVwV j
CD _j o o o ooooooooo
ooooo O OOOOOOI
> o
o o o o I

99 -
8 . 2 DAC Debug Session

Mac > em86

Intel 8086 Simulator

Version 1.4

Will this program access an y 10 ports CY/N3 ? y

Enter name of -file containi ng 10 port map: wacdac.map
Enter name of -file containi ng 10 port data: wacdac.data
* loa =
wacdac.dat
*
reg
AX =
0000 BX =
0000 CX = 0000 DX =
0000
CS =
002B SS =
0000 DS =
0000 ES =
OOOO
IP =
0000 SP =
0000 SI =
OOOO DI =
OOOO
RF =
0000 BP =
0000
* byte cs :u len a

002 B : 0000 B8
002B:0001 20
002B : 0002 00
002B:0003 BE
002B : 0004 DB
002B:0005 B8
0026:0006 29
002B : 0007 00
002B:000B 8E
002B : 0009 DO
* wport fffe
Port address: FFFE / FFFF: OOOO
* bp0=17
*
g
Breakpoint BPO encountered at: 002B:0017
*
reg
AX = 9990 BX = OOOO CX =
OOOO DX =
FFFE
CS = 002B SS = 0029 DS = 0020 ES =
OOOO
IP = 0017 SP = 0014 SI =
OOOO DI =
OOOO
RF = 0000 BP =
OOOO
* wport f-f-fe
Port address: FFFE / FFFF: 9990
? bpl=2f
* all

Breakpoint 0 = 0026:0017
Breakpoint 1 = 002BI002F
* r

Breakpoint BP1 encountered at: 002B:002F

? reg
AX - 0B41 BX = OOOO CX OOOO DX OOOB
CS = 002B SS 0029 DS <=
0020 ES OOOO
IP = 002F SP - 0014 SI = OOOO DI ~
OOOO
RF = 0094 BP = OOOO

100 -
? s

This instruction at 002B:002F

* ex
CX -
0040
* s

This instruction at 002B:0033

* si

SI =
oooo
* ds
DS =
0020
* word dsisi
0020:0000 0800
* s

This instruction at 002B:0037

* a>:

AX =
0800
* s

This instruction at 002B:0039

? s

This instruction at 002B:003A

* si

SI =
0002
* s

This instruction at 002B:003B

* s

This instruction at 002B:003C

# stack 4
0029:0010 003F
0029:0012 0040
0029:0014 0000
0029:0016 0000
* c>:

CX = 0040
*
sp
SP = 0010
bp2=54
? all

Breakpoint 0 = 002B:0017
Breakpoint 1 = 002B:002F
Breakpoint 2 = 002B:0054
* r
Breakpoint BP2 encountered at: 0026:0054
*
sp
SP = OOOA

101
* stack 6
0029: OOOA 0040
0029:000C 0800
0029:000E OOOO
0029:0010 003F
0029:0012 0040
0029:0014 OOOO
* bp2=

* all

Breakpoint 0 =
002B:0017
Breakpoint 1 =
002B:002F
* r

Aborted by a CtrlD encountered at: 0026:0054

*
reg
AX =
0800 ex =
oooo CX =
0460 DX =
0006
CS =
0026 SS =
0029 DS =
0020 ES =
OOOO
IP =
0054 SP =
OOOA SI =
0002 DI =
oooo
RF =
OOOO BP =
OOOO
* stack 6
0029: OOOA 0040
0029: OOOC 0800
0029: OOOE OOOO
0029:0010 003F
0029:0012 0040
0029:0014 OOOO
* r

Aborted by a CtrlD encountered at: 002B:00!

reg
AX = 0B8F BX =
OOOO CX =
0730 DX =
FFFA
CS = 0026 SS =
0029 DS =
0020 ES =
OOOO
IP = 0054 SP =
OOOA SI =
OOOE DI =
OOOO
RF =
OOOO BP =
OOOO
* stack 6
0029: OOOA 003A
0029 : OOOC 068F
0029: OOOE OOOO
0029:0010 003F
0029:0012 003A
0029:0014 OOOO
* word B4
0026 : 0084 OOOO
* word ds:84

0020:0084 0641
* word ds:84 = 35
* r
Breakpoint 6P2 encoun tered at: 0026: 0050

102 -
Aborted by a CtrlD encountered at: 0026:0050
? all
Breakpoint 0 =
0026:0017
6reakpoint 1 0026:002F
Breakpoint 2 =
0026:0050
? bp2=

* all

6reakpoint 0 =
0026:0017
Breakpoint 1 =
0026: 002F
* CK

CX =
0038
* s

This instruction at 0026:0050

* c>:

CX =
0035
? r

Aborted by a CtrlD encountered at: 0026:0054

* c>:

CX =
0029
? stack 6
0029: OOOA OOOC
0029: OOOC 0226
0029: OOOE 0004
0029:0010 003F
0029:0012 OOOC
0029:0014 0000
* wport fffa
Port address: FFFA / FFF6: 1E00
* r

Halt encountered at: 0026: 004 A

? wport fffa
Port address: FFFA / FFF8: 7600
*
reg
AX = 7600 ex = oooo CX = OOOO DX =
FFFA
CS = 0026 SS =
0029 DS = 0020 ES -
OOOO
IP = 0046 SP = 0014 SI =
0080 DI =
OOOO
RF = 0014 BP = 0000
? e>:

wac > f

103
8.3 DAC IOMap86 Session

wac> mapS6

Intel B0B6 Simulator -

I/O Map Generation Utility
Version 1.2

Generate or Modify 10 Map

Enter desired operation:

Create (C) , Read (R> , Modify (M) , Display (D>

Print <P), Write <W) , Quit <Q) , Exit (E) : r

Enter name of file containing map: wacdac.map

Enter desired operation:

Create (C) , Read <R> , Modify <M> , Display <D>

Print <P), Write (W) . Quit (Q) , Exit <E) : d

Description of 10 Port Map

Port Port Port Upper Aux Data Input I / 0

Index Address Width Lower Inde> Index Index State
1 FFFE 16 L 2 2 Output
2 FFFF 16 U 1 2 Output
3 FFFA 16 L 4 65 Output
4 FFFB 16 U 3 65 Output
5 FFFF B L -1 1 Input
6 FFFF 8 L -1 1 Input
7 FFFF B L -1 1 Input
B FFFF B L -1 1 Input

Enter desired operation:

Create <C>, Read <R> , Modify (M) , Display <D>

Print <P), Write <W>, Quit <Q> , Exit (E) : ex

104 "
8.4 DAC IOData86 Session

wac> dataB6

Intel 8086 Simulator Review -

I/O Data Utility
Version 1.2

Enter name of file containing map: wacdac.map

Enter desired operation to perform on data file:

Create file <C>, Read file
<R>, Modify data <M> , Input data (I),
Display data <D) . Print data (P) , Write (W), Quit <Q) , Exit (E) : r

Enter name of file containing data: wacdac.data

Enter desired operation to perform on data file:

Create file (C), Read file <R> , Modify data (M), Input data (I),
Display data <D) , Print data <P) , Write (W) . Quit <Q) , Exit (E): d

Enter port address : fffe

Index: 1
Address: FFFE and FFFF, Width: 16 bits, Entries Accessed: 1,
Number of Entries: 0, Direction: Output
Data: 9990

Enter desired operation to perform on data file:

Create file <C> , Read file (R) , Modify data <M> , Input data (I),
Display data (D) , Print data <P> , Write <W> , Quit (Q), Exit (E) : d

Enter port address : fffa

Index: 3
Address: FFFA and FFFB, Width: 16 bits, Entries Accessed: 64,
Number of Entries: 0, Direction: Output
Data: 8000 8A00 9400 9DB0 A730 B040 BBF0 C150
C860 CF20 D5A0 DAC0 DEA0 E200
E470 E5E0 E860 E5E0 E470 E200 DEAO DACO
D5A0 CF20 CB60 C150 BBFO B040
A730 9DB0 9400 BAOO BOOO 7600 6C00 6250 5BD0 4FC0 4710 3EB0 37A0 30E0
2A50 2540 2260 1E00 1B90 1020 17A0 1020 1B90 1E00 2260 2540 2A50 30E0
37A0 3EB0 4710 4FC0 5BD0 6250 6COO 7600

Enter desired operation to perform on data file:

Create file <C> , Read file (R) Modify data
, <M) , Input data (I),
Display data <D> , Print data <P>, Write <W> , Quit (Q) , Exit (E) : ex

105 -
8.5 DAC I/O Map And Data

wac> list wacdacmap. list

Description of 10 Port Map

Port Port Port Upper Aux Data Input I/O

Index Address Width Lower Index Index Index State
1 FFFE 16 L 2 Output
2 FFFF 16 U 1 Output
3 FFFA 16 L 4 Output
4 FFFB 16 U 3 Output
5 FFFF 8 L -1 Input
6 FFFF 8 L -1 Input
7 FFFF B L -1 Input
8 FFFF B L -1 Input

wac> list wacdacdata.list

Index: 1
Address: FFFE and FFFF, Width: 16 bits. Entries Accessed: 1,
Number of Entries: 0, Direction: Output
Data: 9990

Index : 3
Address: FFFA and FFFB, Width: 16 bits, Entries Accessed: 64,
Number of Entries: 0, Direction:
Output
Data: 8000 8A00 9400 9DB0 A730 B040 BBFO C150 CB60 CF20 D5A0 DACO DEAO E200
E470 E5E0 EB60 E5E0 E470 E200 DEAO DACO D5A0 CF20 CB60 C150 BBFO B040
A730 9DB0 9400 8A00 8000 7600 6C00 6250 5BD0 4FC0 4710 3EB0 37A0 30E0
2A50 2540 2260 1E00 1B90 1020 17A0 1020 1B90 1E00 2260 2540 2A50 30E0
37 AO 3EB0 4710 4FC0 5BD0 6250 6C00 7600

106
-
-
 8.6 ADC Program Listing

Ul
CD
a
0.

IB
a

CM

Hi
*>

L.
11
D
E
3
C

U E
" 3
U -i 6
<I il -h
a x
u a. -
Q r
a
a
3
z z z d
3 u u z z CO
o Il II a 4 n 3
o oooo Cl

U U c
o a II
a a E ii n
u 3 3 3 3 3 D CP
a a a cr cr cr C il c
a I t t ii LU CO ti

Ui
cn Z
in LU
a ui
ID
C c o> C Ul
> Z il il c u in
E 01 E a
0> cr
_i o Ul
CM ui + a n *i *> a *>
u > CJ 3 C " CD CL a CO i Je J O u
a cc O "> - 6 e u u u u ii
o or co z> f- a o *> o o z **
u -.
u ui a o CC CO CC U 01 C L L. Ul 4J *l -U O II
a -i CD CL r-
-a . -Ul -

<z CO CJ
rt a
ui co a
to o u
in . a
cc a u 3 -NK>IHIMIIffONrlll4Mll'C'
^Niowiri'OrvCD 0"O CNfOwn-O
LU a NNNNnNriN n n n n b n
_l a <m
CO cc u co
CJ C
Ul a 3 in
cn a
tn z
<r * -

CO
o -
D >
cc V UJ CO O O CM
u CD U <NKM1
<x 03 c a o o cm in Ki
v. Ul
_l
N -O I- <l N
N CL X cm m in t ui
CD O t>- N 41 tv
MU> nantnL
0 _l Z 4 <0 -O <0
o- o-
CD D * a o
CD o a r -0 -0 CM .0
CD cd a cc ui co in -o t
Ul O
cn _i CO nuiu-.w<i
CD h co o u. u. o a V41441-0CMCNO
3-
U u u o Kl
-0 v Ul Ul o o -a
CD x r> m o o CN CM
co cn 8
> o c O

107 -
Ul
CD
a
CL

CD
CD
v
N L
w. L. 11
N. II *>

**
Z
m .
u
^ cr z u.
o u LL u
f'j a L Ll u.
CM L. U
.. * L. LL
|v ** C II O f-
CM C 1 +i
a
.. II E c D
E cr ^. Z to
N CT u 0 C I ui
a m a .
il in
a I-
X *J U -I

.x IL Ul 3 I- r-
u -<
3
u U u. 0. 3 3H- ii CL Cl
** u. CL CL 3
r-
r-
L m
*i *l u 321-1 CC * c Z w
"D i U CD cc CD ?
L U o
a a Q. f- m in a t g, CL c
3 3 3 <r c co in E *< 4J I 3 *>

<c c 0 U +> X CPU L. r-

3 CP
+* *> *> a d di 01 - to >. ll 3 O CP ti c
u ii II oc -. n rv CC L O C o.o *> a. _l 01
m CO m o a. cl i i u C 4J c t- I
>ou G in jj > 4J l X 3 3 X
CO UCJ z C UhJ c a O O o m
CM CM - - a oi c a- c u u -
Cl Cl ClO. O *> L * 3 + L 3 II X
T> C 4J +J Oi 3 oi u in
t- t-
r- r- r-
*> c - 4J o " > V Tl UJ > ui D -
Z o II Oi
0 II 3 3 * 01 Tl - Oi a Z
CL O Z Z ZZ Z Cl - cd in a. o in co a a u 01 " 01 LU Ul r-

0 u cn 01

cr
c
01 01
-I

01 *< *t +> -J _l co CO
01 01 Z X
J a a. a <x _i c ~ z
* u n uj E E u
4J < s* CD LL 0 0 D U O U u.
x 4J x * Ll L LI[flL4< ki cl co in _ico in z _i cc -m u. *> U X
a a in a o co u. Cl Cl U 3 _l 3 (0 3 II * a c ^ a co a U 3 _l 3 u. -. _l

O O uD 3 o o a
. . .(-
. |- - r-
II r- r-

x oi x oi cl x x xxjrr ji JUX j -Iuj -I-T-j -Jz _l CC cc

_l 3
c a oi oi a aucucu cum" u a u Cl

CL X CL
C0>>r-r-r-
>>>>>>> > > > I- r-
>r-UO co > co a cc
_i > > r-
> r-
> O
O O O o o o o Ul O O 3 O 3 CLO 3 Z O Z330Z3Q0 O O 3 O 3 300303 O O
_l O O f O - J iC0E-iCnx O O CLOZO _l

Ul M CL
CJ u r- 01 Ul
a cc CC 3 Ul 01
o 3 <I <E -^

u o f-
S =>
a 01 01 . - a.
c

cc Ul rvcoc^o
rvCOO-O CM Kl *
Nn*in<iNai^o-<rMrOwiO'<iivcoDoCMrOin<irvaio-o CMioeio-oivCDOk rNnvin-orvcocfo
r'lr

Ul z n kj *
-1
M

CO -1

Ul
01
01

0
oo
o 8
N. 1 u. -0 u.
03 1 CO u. w CM u.
0-
09 03 1 * Ul uiuiou.au. Ml tO MO CD U O 10 V a u. u. o - o in ui
v. r) Q 1 Q CO U. - o u. o u. u. u. nNQlLNUUJ 8ILCIL u. o a o u
N 00 1 1 Ul 03 Ul CJ CD a 6Q CO <0 <0 4 Kl N *U4>aUCMCM 5 o -o ><o m-am o-
n
o C I 00 CO CD 03 a 00 CO 00 CO Ul CO Ul 09 Ul * Ul UICMU.ODUICMr> oo ui m ui n co co ui u. uj co ui
03
v.
0 ooniooicoo n * oo u ui n CD 0-
-0 HDlLrHlMMI U. - 10 IO SNtDOSOUl
u OOO-" m ,. -c - - fM CM CM CM CM CM CM NNNMnWrlrl n * * * <-*ifi inniiT
00
o o 5 O O O O oocooo SO OO 8o o o o o o o oooo 6ooo oo
09 -J s<3 O O o oooo OOO o o o o oooo oo

108 -
Ul
CD

CL

CD
CD o
Ul (9
(-
z
(J
Ul
CO z
z 01
I-
o
cc u " CO cc o
o t o 01
CM Cl 01 . 3 f- CL
-* X Cl Z CD
D o z o z
r-
U i U r-

01 a u. CM ->
II
U Ll <X Cl a.
CM r-
C > > r-
l
Z u. I-
Qmzd
o a o z ID D 01
a
CO Or-U OrlDO c
cc V ii -* u. ui T)
Ul a co u a i- cn
> r-
01 Ul 01
z i- t- z I-
3 C Ul cc
o 3 Z CD CL 3 Ul U Ul
i-
u Cl a -< a. _i o u
z u in 3 Z CC
o -i cm a.
u i-
i-i 01 U Ul Ul cc
u uj z a OIUI O
* o z is C I- I r-
U. l
Ul o ~ r-
01
Q CO Ul I- Ul r-
LU -u

VI X X 01 Q UJ 3 cc
u Z I- > 0.
h r-
3 Ul -

Ul 1>(Ir-
UJ 01 Z CP
I-
X zoo O - 01 3 01
SCr-
u a o o LU CC
z
ii X
I-
u
3
O OJ
CC cc
r-

X X XX 01
a 1 X Z U CO
u u. Ix o u. U. UJ
U- LL U. O U U a >-
-I U. x _l z U. x u CD O U x
<i o a i- a o - o a Ul -< Ul cn
Z II cc o a
|x xZJlS XX xxxxxx I- T) X O z z
: a a a a a i i a i <z a a U Ul UJ
-I 01
-I UJ
c +> o
u O
CL a. o
oonesi- >- *J *- Or-
> 01 > CL O U
O 3 o z cc z OZ Z00Z03 C - O O -I O UJ Q
z o - O n " aiKlLO x a. _i z j cc a

LU 5-

u u
a cc
a 3 a
u o CD
a cn
<z
a

3
o
ic Ul MK>lf)41lsC0D-O-rMI0l/14!rvC0Cr>-"rMK;Vin4)rsCD0'-.
Ul Z MMht'K'OOeOOOOOC'0-----NN
_1
01
CO cc
o
Ul CC
01 IE
01 Ul
1
o
o Z
cc
u

E
Ul
-0 -I

00
I
o
00 u. tf
O u u
CD CX UL CD U CD
Q J-
N. Ll U. O U U. Ll 0-
So in in - m c u. CM -I
M-

00 CO Ul CM O Q CM CO LU nuu. CO H-

N. E
4} 4) CD 0-
U Q U. -. Ifl CD CO Q O Kl 10 N Ul A
09 u n in in in m in 414) 4) 41 43 43 r- r- r* r- f- 01 u
o o 000 o oooo OOO 01
09 J 00 000 00 oooo OOO a x

109 -
8.7 ADC Debug Session
Intel B0B6 Simulator
Version 1.4

Will this program access any 10 ports CY/ND ? y

Enter name o-f -file containing 10 port map: wacadcmap
Enter name of -file containing 10 port data: wacadc.data

* loa=wacadc dat
* bp0=lc
* bpl=47
*
Q
Breakpoint BPO encountered at: 0020:0010
+
reg
AX =
BASA BX =
0004 CX =
0024 DX =
FFFE
CS =
0020 SS =
0028 DS =
0029 ES =
0000
IP =
uolC SP =
0014 SI =
0000 DI -
0000
RF =
0000 BP =
oooo
* wport -f-ffe

Port address: FFFE / FFFF: BA8A

? word ds:b;: len 4
0029:0004 6E45
0029 : 0006 6574
0029:0008 2072
0029: OOOA 616D
* r

Enter max i mum number o-f iterations: 12

Breakpoint BP1 encountered at: 0020:0047
*
reg
AX = OOOA BX = OOOA CX OOOC DX =
FFFE
CS = 0020 SS = 0028 DS 0029 ES = 0000
IP = 0047 SP =
0014 SI oooo DI = 0000
RF = 0044 RP
BP = OOOO
* stack 2
0028:0014 6E45
0028:0016 6574
* s

This instruction at 0020:0047

* stack 3
0028:0012 OOOC
0028:0014 6E45
0028:0016 6574
* sp
SP = 0012
* all

Breakpoint 0 = 0020: 00 IC
Breakpoint 1 = 0020:0047
* bpl =

* s

This instruction at 0020:0048

110
-
-
* E

This instruction at 0020:0046

* s

This instruction at 0020: 004D

* al

AL =
01
* d>:
DX =
FFFC
* port fffc
Port address: FFFC: 01
* s

This instruction at 0020: 004E

? al

AL =
FE
* port -f-ffc

Port address: FFFC: 01

* s

This instruction at 0020:0050

* port fffc
Port address: FFFC: FE
* s

This instruction at 0020:0051

* c>:

CX =
0005

This instruction at 0020:0054

? =

This instruction at 0020:0054

* s

This instruction at 0020:0054

* s

This instruction at 0020:0054

* s

This instruction at 0020:0054

* s

This instruction at 0020:0056

* port -f-ffc

Port address: FFFC: FE

* s

This instruction at 0020:0058

* al

AL =
01
? port fffc
Port address: FFFC: 01
* bp2=5f
* r

Ill -
Breakpoint BP2 encountered at: 0020: 005F
* al

AL =
40
* sfl

SFL =
0
* port fffd
Port address: FFFD: 40
r

Breakpoint BP2 encountered at: 0020: 005F

* sfl

SFL =
0
* port fffd
Port address: FFFD: CO
* s

This instruction at 0020: 005F

* s

This instruction at 0020: 005C

* al

AL =
CO
* sfl

SFL =
0
* E

This instruction at 0020:0050

* al

AL =
CO
* sfl

SFL =
1
* =

This instruction at 0020: 005F

* s

This instruction at 0020:0061

. =

This instruction at 0020:0064

* s

This instruction at 0020:0065

* ax

AX = 0A54
* s

This instruction at 0020:0068

* a>:

AX - 1254
* s

This instruction at 0020: 006B

-
ax

AX = 092A
* wprot fffB
"N"
Bad keyword class:
"N"
Bad keyword class:

* wport fffB
Port address: FFFB / FFF9: 0000

112 -
 s

This instruction at 0020: 006D

* s
This instruction at 0020:0070
wport fff8
Port address: FFF8 / FFF9: 0000
* s

This instruction at 0020:0073

? wport fff8
Port address: FFF8 / FFF9: 092A
*
'VlEC/j
* s

This instruction at 0020:0074

* ex

CX =
OOOC

This instruction at 0020:0075

* s

This instruction at 0020:0047

* all

Breakpoint 0 =
0020: 001C
Breakpoint 2 =
0020: 005F
* all =

* bpf=75
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX =
00 OB
* wport fffB
Port address: FFFB / FFF9: 05B8
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX OOOA
*
wport fffB
Port address: FFFB / FFF9: 0A06
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX = 0009
? wport fffB
Port address: FFFB / FFF9: 0BA1
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX = 0008
* wport fffB
Port address: FFFB / FFF9: 0752
* r

113 -
Breakpoint BPF encountered at: 0020:0075
? ex

CX -
0007
* wport fff8
Port address: FFFB / FFF9: 0B54
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX =
0006
* wport fffB
Port address: FFF8 / FFF9: 05FE
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX =
0005
* wport fff8
Port address: FFF8 / FFF9: 0928
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX =
0004
* wport fff8
Port address: FFF8 / FFF9: 0A51
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX =
0003
* wport fffB
Port address: FFF8 / FFF9: 0412
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX =
0002
* wport fffB
Port address: FFFB / FFF9: 0BAB
* r

Breakpoint BPF encountered at: 0020:0075

* ex

CX = 0001
* wport fffB
Port address: FFFB / FFF9: 0962
* ex

CX = 0001
* s

This instruction at 0020:0075

* s

This instruction at 0020:0077

Halt encountered at: 0020:0077
* e
"N"
Bad keyword class:

* ex

114 -
8.8 ADC IOMap86 Session

wac> mapB6

Intel 80B6 Simulator I/O Map Generation Utility

-

Version 1.2

Generate or Modify 10 Map

Enter desired operation:

Create (C) , Read (R) , Modify <M) ,
Display (D)
Print (P), Write <W) , Quit <Q> , Exit <E) : r

Enter name of file containing map: wacadc.map

Enter desired operation:

Create (C) , Read <R> , Modify <M> , Display <D>
Print <P>, Write (W) , Quit (Q) . Exit (E) : d

Description of 10 Port Map

Port Port Port Upper Aux Data Input I/O

Index Address Width Lower Index Index Index State
1 FFFE 16 L 2 2 1 Output
2 FFFF 16 U 1 2 1 Output
3 FFFC B L -1 37 1 Output
4 FFFD 8 L -1 32 46 Input
5 FFFA 16 L 6 13 31 Input
6 FFFB 16 U 5 13 31 Input
7 FFFB 16 L B 13 1 Output
e FFF9 16 U 7 13 1 Output

Enter desired operation:

Create <C) , Read (R) , Modify <M> , Display (D)

Print (P), Write (W) , Quit <Q> , Exit (E) : e

115
-
-
8.9 ADC IOData86 Session

wac> data86

Intel B0B6 Simulator Review

-
I/O Data Utility
Version 1.2

Enter name of file containing map: wacadc.map

Enter desired operation to perform on data file:

Create file (C> , Read file <R> , Modify data (M) , Input data <I>,
Display data (D) . Print data <P) , Write <W) , Quit <Q) , Exit <E> : r

Enter name of file containing data: wacadc.data

tnter dE.:red operation t^. perform on data file:

Create file (C) , Read file <R> , Modify data (Ii) , Input data (I),
Display data (D) , Print data <P) , Write <W> , Quit <Q> , Exit (E) : d

Enter port address : fffe

Index: 1
Address: FFFE and FFFF. Width: 16 bits, Entries Accessed: 1,
Number of Entries: 0, Direction: Output
Data: SABA

Enter desired operation to perform on data file:

Create file <C> , Read file <R> , Modify data <M> , Input data (I),
Display data (D) , Print data <P) , Write <W) , Quit <Q) , Exit (E) : d

Enter port address : fffc

Index: 3
Address: FFFC, Width: 8 bits, Entries Accessed: 36,
Number of Entries: 0, Direction: Output
Data: 01 FE 01 01 FE 01 01 FE 01 01 FE 01 01 FE 01 01 FE 01 01 FE 01 01 FE 01
01 FE 01 01 FE 01 01 FE 01 01 FE 01

-
116 "
Enter port address : fffd
Index: 4
Address: FFFD, Width: 8 bits, Entries Accessed: 31,
Number of Entries: 45, Direction: Input
Data: 40 40 CO 40 40 CO CO CO 40 40 CO 40 40 CO 40 40 CO CO 40 40 CO 40 40 CO
40 40 40 CO 40 40 CO 40 CO CO CO 40 CO 40 CO 40 CO CO CO CO CO

Enter desired operation to perform on data file:

Create file <C) , Read file (R) , Modify data (M) , Input data (I),
Display data (D) , Print data <P) , Write <W) , Quit <Q> , Exit <E> : d

Enter port address : fffa

Index: 5
Adri-=;s: FFFA and FFFB. Wi.'Lh: 16 bits, Entries Accessed: 12,
Number of Entries:Direction: Input
30,
Data: OA54 A370 5C0D EF42 06A5 9EAB 03FC BA51 7CA3 5024 3957 0AC5 19AF 9D24
OACD EB3F 9AFC 03E7 9BA2 37AE F023 D5CA 9A38 C247 349A 1B3C 32A0 B62C
A034 2B46

Enter desired operation to perform on data file:

Create file (C) , Read file (R) , Modify data <M) , Input data (I),
Display data <D) , Print data <P) , Write <W) , Quit (Q) , Exit (E) : d

Enter port address : fffB

Index: 7
Address: FFFB and FFF9, Width: 16 bits, Entries Accessed: 12,
Number of Entries: 0, Direction: Output
Data: 092A 05BB 0A06 0BA1 0752 0B54 05FE 0928 0A51 0412 OBAB 0962

Enter desired operation to perform on data file:

Create file <C> , Read file (R) , Modify data (M) , Input data (I),
Display data (D) , Print data <P) ,
Write <W> , Quit (Q) , Exit <E> :

-
117 -
8.10 ADC I/O Map And Data

wac> list wacadcmapstart. list

Description of 10 Port Map

Port Port Port Upper Aux Data Input I/O

Index Address Width Lower Index Index Index State
1 FFFE 16 L 2 1 Output
2 FFFF 16 U 1 1 Output
3 FFFC B L -1 1 Output
4 FFFD e L -1 46 Input
5 FFFA 16 L 6 31 Input
6 FFFB 16 U 5 31 Input
7 FFFB 16 L 8 1 Output
B FFF9 16 U 7 1 Output

wac> list wacadcdatastart. 1 i st

Index: 1
Address: FFFE and FFFF, Width: 16 bits, Entries Accessed: 0,
Number of Entries: 0, Direction: Output

Index: 3
Address: FFFC, Width: B bits, Entries Accessed: 0,
Number of Entries: 0, Direction: Output

Index: 4
Address: FFFD, Width:
8 bits, Entries Accessed: 0,
Number of Entries: Direction: Input
45,
Data: 40 40 CO 40 40 CO CO CO 40 40 CO 40 40 CO 40 40 CO CO 40 40 CO 40 40 CO
40 40 40 CO 40 40 CO 40 CO CO CO 40 CO 40 CO 40 CO CO CO CO CO

Index: 5
Address: FFFA and FFFB, Width: 16 bits. Entries Accessed: 0,
Number of Entries: 30, Direction: Input
Data: 0A54 A370 5C0D EF42 06A5 9EAB 03FC BA51 7CA3 5024 3957 0AC5 19AF 9D24
OACD E83F 9AFC 03E7 9BA2 37AE F023 D5CA 9A3B C247 349A 1B3C 32A0 B62C
A034 2B46

Index: 7
Address: FFFB and FFF9, Width: 16 bits, Entries Accessed: 0,
Number of Entries: 0, Direction: Output

wac> ff

118 -
wac> list wacadcmapstop. 1 ist
Description of 10 Port Map

Port Port Port Upper Aux Data Input I/O

Index Address Width Lower Index Index Index State
1 FFFE 16 L 2 2 1 Output
2 FFFF 16 U 1 2 1 Output
3 FFFC 8 L -1 37 1 Output
4 FFFD B L -1 32 46 Input
5 FFFA 16 L 6 13 31 Input
6 FFFB 16 U 5 13 31 Input
7 FFFB 16 L B 13 1 Output
8 FFF9 16 U 7 13 1 Output

wac> list wacadcdatastop. 1 ist

Index: 1
Address: FFFE and FFFF. Width: 16 bits, Entries Accessed: 1.
Number of Entries: 0, Direction: Output
Data: 8A8A

Index: 3
Address: FFFC, Width: 8 bits, Entries Accessed: 36,
Number of Entries: 0, Direction: Output
Data: 01 FE 01 01 FE 01 01 FE 01 01 FE 01 01 FE 01 01 FE 01 01 FE 01 01 FE 01
01 FE 01 01 FE 01 01 FE 01 01 FE 01

Index: 4
Address: FFFD, Width: B bits, Entries Accessed: 31,
Number of Entries: 45, Direction: Input
Data: 40 40 CO 40 40 CO CO CO 40 40 CO 40 40 CO 40 40 CO CO 40 40 CO 40 40 CO
40 40 40 CO 40 40 CO 40 CO CO CO 40 CO 40 CO 40 CO CO Cu LO CO

Index: 5
Address: FFFA and FFFB, Width: 16 bits, Entries Accessed: 12,
Number of Entries: 30, Input Direction:
Data: 0A54 A370 5C0D EF42 06A5 9EA8 03FC BA51 7CA3 5024 3957 0AC5 19AF 9D24
OACD EB3F 9AFC 03E7 9BA2 37 AE F023 D5CA 9A3B C247 349A 1B3C 32A0 B62C
A034 2B46

Index: 7
Address: FFFB and FFF9, Width: 16 bits, Entries Accessed: 12,
Number of Entries: 0, Direction: Output
Data: 092A 05BB 0A06 0BA1 0752 0B54 05FE 0928 0A51 0412 OBAB 0962

wac> ff

119 -
 Appendix B
H I-I
41 0
X-P
P (0
HrH
14 4) 3
01 E
X 0 3
P M +J 0 u
h

4)
o o 8
4J h fl x In
(0 4) in +j o
0H4J E 4> M -H+J

+J3W0 X 0 4) (0 U
.
Eli.U JJ JJ rH O
U 3 CT4-I -H (8 O 3 4J
U 0) O 4) I-i 0)rHi3i=
41 O In 0) 4)
-M
33 rH
X lH 0) (0 4-1 X 0 E In O 3

0
P

-HX In
(H J)
Oi O C -H
-H TJ (0 4JIh +J3
o
So E
-HO -P -P a
0)4JjJO4l4J(BT3 4I4J hurj B O
CI0^H4JIm 4) (0 (I It ffi HO O JJ L, Lj

OOrH0)lOE| OrH ^ (h 0,iJ In O4>0)

H-P3H.e.p\E -P 3 01 E -P 0) 4I1O4J4J
Jr .
E 03 +J 10 (h -h E 'DHOJ3 M 4) -P j: U <n in
Q< H 3 -P E -H -H H lH3TJtJ>fcl3.p CO I) -H -H
H 9jt) 3 >BJ5 01 h 0)0 (0 4) MH 0) TJ (0 TJ Cn tn
-H -H .Q lH u
In -P O H O 4>
0 0 -P 4) 4-1 O I-i C-H TJ &>5 3 4) 4) 4) 4)
O 0110 4)0 EEMI-l 0) -p 0)10 14 Oll-l (CO (0 fl) m 2 2 P -D

5 t- 4J* \6i<ll Hll H 0E4J0 4) 01 10

<U 0
o> 0) l-l-HOO D>-H piO U QigLi EC (.
a) jJIjjJjJ H -H
Q S^
lH Tr,5
tT>-P
^.^Q-Cl

>i >i ? ST
lH 0) P
I-I
^
.
MH TJ
^
.
^C
M-H
0
lH
"S TJ O H H tntn
.p -P -H C-HIH.Q.Q 0) 4>
4) 0) MMXX U 0) 01 4) 0) h (CTJ u Lj
^t!
^ "i MM-P-P -P X-P 3EE3 h I-i 4J Ih 4).pvovo
JJ(0 C -P 4J (OnJ
t-i\ E ("">
4J(0 .h-h
00 0] 0) E E 01 H H 4-1 4J
U H-H'D(0OO3?4)C-H-H'aH-HT3 3 > \ E 3 -n-H
0 s-oc-h 6o jb (04)4) -i-i 0 ih^ht-i+jjj ja xi
01 0) (OTJ XX-P-P 4)
01
_ &>Ej
&>
-P-P >> 73 iDCC
EE 4) UU t) IJ CD EE rHOOrH H^H (C 4J 0)41(04)4) U3 10
4) \ E EE -H.H(0(0 0)0) \E (0(0(0(0 0101 c I-1I-1 EE <HW
O Ih-h \E SStit, 01 l-i-H EUlUE 33 W 0) (0(OIHO)4I
O I-I -H
4J+JX -H+J+J-HrHrHMEa Q.H U| Lj JS
h tj tj tj tj .q oi a,
.a tjtj o ja .q o oo cj o> eeuoo oi a,
a o tjtj hi-i tj TJ 3 3 30 cc 413341 x x co 4) 0 0 co e 4) 30
H (010 00 (OlOOlOl OiOi 10(0 TJ 0) 0) TJ 0)4) < 01 O O < H TJ ft, Q.
LO C
DO 0
o E X X
o 4) QQ cj 0 co cq to a qd < co cq to a: a: < a a, co cj rj wa
C QQ OS OS Q Q IB CO DO 22 <DD< OO <S S S < 2 H DO
rH

4)
S << OO <<loco aa << q co co q xx 3 uS<hq a a
+J >,
C 0) HO HO HOHO OO HO OtHOO HO O ^ HOOiniTl LOIO
H X.

0) 01 << JJ < < < < QQ J i-3 <C < < < J ij < a <<<<< QQ
X 0)
+J (0
rH
lH CJ
0

01
0)

-8
o
a
O

TJ
4)
In
4)
T3
lH
O
H^^^^^^ ^^ ^~i -h -h

X X X X XXX X
a a a a O. D. a. Q.
01 0) 0) 0) 01 01 01 CO

TJ

O.H D-H CL-H D.H Q.H Q.H Q.H a

01 01 01 01 01 01 01 0)
H II H II H || -H 11 -H II H II H II H
TJ TJ TJ TJ ^
10 ^
10 .. ^
TJ
-'S * :*~ s --* ^Z ~^? *-^

E (0 E (0 E (0 E (0 E (0 E (0 E E
S.4J \-M\4J \*J S.*) \
\-P
lH (0 lH 10 In (0 lH (0 Ih (0 M 10
>t!
lH (0 In
TJ TJ TJ TJ TJ TJ TJ
Cr>w OW t-j,wO! Qi~ tJi^ tJl^ Oi
0)
"O 0> 0> 0) 0) 0) 0) 0) 4)
0 >H 10 H (0 hiih lH 10 u ie lH (0 h (0
+) 4J +> jj +j 4J 4J
0 M

a TJ (0 TJ (0 TJ (0 TJ 10 TJ (0
o 15 ETJ ETJ ETJ ETJ ETJ It? It?
5 S 3 JJJJ O H f * ^Z *r* * * H O * Sh P>B> tjicn
TJ O TJ O TJ O TJ O H H TJ O H TJ O H TJ O H H TJ O H 0) 0) 0) 4)
O H O H O H O H H H OH H O H H O H H H O H H I-I lH I-i M
O O H H O O H H lH lH O O O H H H O O O 01 H H H O H O H
O O O O ri ri -! ri 0) 0) O o OOOO H H H o H H H O O H H
O O O O OOOO o o H H H H H H H H H H H H H O O O O
O O O O OOOO o o o o OOOO O O O o O O O H H H H
O O O O OOOO o o o o oooo O O O o O O O o o o o

-
120 -
 HH lH lH E
rHrH 4)0) (0104)4) \
(0(0 > > 3 3 4-> 4-> H
33 oo trcriflio
D-tT XIJ3 TJ0)0)4)4) E
4) 4) (0 (0 TJ h h 0 1-1
0 U U Di tn lH 0
In In 0 \-P C 00 MH 4-1
00 IhO 0)>i -P\ E (0
4)CrH >4JLjhO \4) H
0)4) N (fl 0)-H0)O)CH m 4-> e 3
>> \3 Ih-P-P (0 10 < E h E
oo 4) tr >,(c (0 (0\3 OH E U Ih\ 41 3 TJ
.O.Q OH 4) 4Ja t) IT PTJ \ E lH 0) lH 4-1 0 lH
c (0(0 CIO -H MIhHO) 4) U 0\ 0) -P 0) O 0
0 5e 0 3Ih
^ v
Ih\ tn tnio 4) E -P lH 4-> 0) 0 H 10 S 4-1
H 0-P\Ih\&0 (0 3 Ij P E E 01 H 4J U> c
P ho 4) 4) a>,4J \cr o ifl-H 0 0)X H&I 0) X 0) 0)
a C 3 NH 4JO 4) H 14 4-> 4-> 14 Cn 4) M <h 4-> H
H
M
5 "H
0 0)\H\30H
0
IB I-I 0 C \-H C 01
tn U
CO
01 V, 01
E ETJ * E MH (OH
\4) 0\ H S
0) 4) In 4) H TJ 43 !
D1
4-> lH 4J lH 4J 3 tl 3 4)
H !>
O 4) 4) H >, 10 \ 4) 0 4) H M |lH lH 4>TJ 01 E 0) 0) C 01
CO
4)
IHO JJ5.HJJSJ)
(hOMOChoio)
014JQ. H H 1 Ih
0 Oh 0 0 (0 E
4J 4) 4) H
Dl
X 0 H 4-> 4) lH 3 M
-P P In tnoi E 4> 0)
Q 0) -PH 4-> 34JH4J C314J H4J 014J 01+) P 4-> H E 10
.12 -P 4) -H MH 4> H tn -P 0 0 4J
>04)0O,04)0-H0i004)04)0 >l TJ H -H lH S In tn 4) 01 P-P c
ocjac4)cjaco)cacHciHc 0) 4) IhX 4) 4) TJ \ 4) 0) H H
4J4JI-l4-l4-IEt(4) TJ E (4
-P tn 0)TJ
cccccccccccccccc (0 10 10 h 10 E 0 E C \0 C 0 0) 4J 14 4J
0000000000000000 H H O 15 H H g (0 I-I 4-> 4) 0 4-1 M >iO O
TJ TJ TJ 4) -H -Q 3 4)
0.0.0.0.0.0,0.0.0.0.0.0.0.0.0.0. 0) 4>X -P 4) -P > E 0) E E
tn 0) lH
EEEEEEEEEEEEEEEE E E 4J 0 E O -H 4) \ tn\4) <\E tn +J 4-1 H
3333333333333333 E E H 10 E 10 0) Jh u C In 0] 63 ti \ C lH U TJ
4} 0)
4-> *)Hft 4J X 0) 4>TJ 4) X > > H 4J

TJ TJ .QTJ.Q O E 01 O > > (0 > a 0 c c H H

O TJ WV 3 C 3 X 0 41 XI 0 0 0 0 0 0 10 10
H 63 63 N<< O 63 H CJ U (0 0 (0 01 (0 0) 0) 0 4-1 0) E EH E a 4) 0 0 O s
c <C < 2 Z fo 63 a CJ CJ 2 l"3
0 ZJMrJrjS D.bZ'3fl\
E 4\)i\\BI b\b\\H Eh CJ CJ J E-i
0) 0\CD\6363CQ w \a \ J 63 J Q CJ CO Q CD OS a CO x > S> <> a =c SO J H
c O2C0263ZCDZC0ZaZJZJZ qosqcozdos 63 CJ O O 63 O O CJ CDS < <
* bbbbibfjbilbihbbi^bbb) <o<w<cwxu E-i XES JEQ.X u CJ CJ s

0000000000000000 r^rf-rr r~ r c h h n h ci <N m 0 0 O 0

4) H

0) CJCJCJUUUUCJCJUtJCJCJCJCJrj 6363636363636363 iJ QQQQQQQ << CJ a

01
^^ ^
(0 -^ .-,

00000

II H II II H II H II

* II * * II * II *

(0(0(0(0(0(0)0(0
4J4J4J4J4-I4J4J4J
(0(0(0(010(0(0(0
TJTJTJTJTJTJTJTJ

10(0(0(0(0(0(0(0
4J4-l4J4-)4->4-)4-l4->

(0(01010(010(0(0
TJTJTJTJTJTJTJTJ

^-1 ^4 -rt ** 'H t4 *-i ^-i

xxxxxxxx X XX X
p, fl, p, Q, p, P, P, p, CL Cl Cl Cl
(00.(0(00)01100. CO CO (0 CO
H -H -H H -H *H -H *H -H -rt t-t -rt

rDrOrDrDrO'OrOfD *0 'W 'U

0)
^^ -**- r^
O
00000000 0 0 0 0
r-tr^rHr^rHr-irHrH H H H H 0
aaaaaaaa a CuCu a. H
01010)0)0101010] 01 CO 01 01 1
H -H H HHHH -H H H H H 0)
TJTJTJTJTJTJTJTJ TJ TJ TJ TJ O
*^"
^r ^^ V^ ^^ -.^ ^^ ^^ *"*

"""e we H
E E E E E E E E E e E\E\E X
WIh\Ih\ 1
COCOCOCOCOCOCOCOGOGOCOCOCOCOCOCO IhIhShMIhShIhIh I-i Sh Ih U U a
I I I I I I I I I I I I I I I I U i-i T-f

OOOOOOOOOOOOOOOO OHOHOHOH tn tn tn 01 01 01 0
CCCCCCCCCCCCCCCC
C C C C OOHHOOHH 4) 0) 4) 0) 0 0
TJ
0 ^4^4^-i H OOOOHHHH ti (h u 0 tJ 0 0 H
|
o LLil
0,0.0.0.0.0.0.0.0.0.0.0.0.0.^0 TJ TJ TJ TJ TJ TJ a
a.
^1^11111 1 H

OHOHOHOHOHOHOHOH * S S O H O H tn O H O H
OOHHOOHHOOHHOOHH coococoocooco 0 H TJ O O H H 0) O O H H
OOOOHHHHOOOOHHHH 00000000 H O ri ri r^ ri lH
<-t O O O O
OOOOOOOOHHHHHHHH 00000000 O O -{ ri ri ,-i ri O H H H H
ririr^T-{riririr^rHrHrHr-irirHr-iT-l
00000000 O O O O O O O H H H H H
00000000 O OOOOOOO O O O O
00000000 O OOOOOOO O O O O
OOOOOOOOOOOOOOOO i-|rHHtHtHiHHiH H T-i -< <-t ri r-i r-l H H H H H

121 -
 a
CO
a
0 to
-p

o
4) P

10 4)
H 4J
TJ (fl
4) H P

E TJ MH
E 4) 4)
ti E
0 E
P tn
P O
10 c -PXH
H H H tn MH t7l-P
c 3 4) TJ C 4)H 4)
0 E 4-> TJ H
H TJ H u E P an
3 01 Ifl TJ 0) X
4-1
0
X H TJ
a TJ H >i>l4-> tn PH
3E o tn 4-> 4-) (0 "-1
H Ifl i? ti Ihh+Jh H >
4) c e
tl 0)
H 0 lH tl IhX lH 3H <
3 0 tl 41 4) O H ro (0 (c m
o tn 0) o 4J
-P -P
ETJ
TJ co co a c 0) MH
01
0)
IB
H 10
tn O C 0 >> 63Q 0) 4) 0 In
o o HO
\t<H ti U
0
4J
(fl
c
ifl In (0 4J 4) 0) E Em 0) 4)
Q MHH XX 4-> 0 0 tl
O 01 0) 0 0 tncn > cn tnH H 4) 0)
MH 4)
0 -P cn 4) 4-1 4-1 4) 4) 4) 0) 0 4-1 3 3 (0 IB E
o -p io c -P C C to to a a
P P

H
px o o o ox P 4-> >l X
-PX 10 tn H H lH H (fl u u >, >iC MH tn tl lH H H 4-1
C 0) 01 4)
4-> >,3 tnlH H e tn tn XX 0) 41 H 0) 4) 4J o 4) h
0)
p x; tn cn-H
,c
3 3
C 4J TJ h c c -P 4-1 4-> 4->TJ H tl 4J 4-1 0 0 tl 4)
cn to s 3
P -P -r-i-r-i o
ifl tnx
2
E O
0) lH H -H H -H C C 4) C C 4-1 P 4-> -P HH (fl TJ TJ 4-1 4-)
E -P lH lH H-H E -h h a a a a 41 41 01 0) 10 (0 (0
H (fl < X E 01 4J 4->
0 0 E 3 3 3 3 4-1 +J -P -P -P 4J -P H 0)
MH H < E 10 0) 0) c c a oh c c ti tl ti t) (fl (fl (0 (fl MH MH MH 0) a
MH 4) 4) H H tl lH tl tl lH tl 4-1 4-1 4-> 4-1 -H H H c (0
X In TJ 0) 0) -P IhTJ C 3 3 TJTJ 4) 3 3 4) 4) 0) 4)
oi a
0 0 0 oxxx O CJ Ifl o
o> > io 01 0 Ifl 10 4-1 4J (0 (B > 4-> 4-1 4J 4-> 4J 4-1
ti ti ti ti 0) 0) 0) CO CO
3 0 0 0 0 4)
tl 0)
-P
poo 0) 4) 0 0 4) 0) C c c c <<
0.0,0) H E E 4J 0) H 01 )H lH HH a tl Ih-h H
4)

6. <
CO
Xbbb CO CO Eh CO CO CO O OS Eh
co a x x >
> > a CO oo< S> Eh Eh CO to
> Eh Eh Eh Eh Eh Eh J OS 1-3 OS J OS OS Q < CJ
D O < < O O O S 63 Eh
Q CJ 6363 63Q O
a a w 3 s s SO EH CO 3 CO
Q o; a:
63 63 2 2 Z 2 OOUOIK < < J CO
KtEHHHH OS OS OS OS to CO to < < X 63

0) O O O O 00 00 o o in o o o o o o o o t*- p- r*- r*- r^ r- r-

US ID O CM
J<

01 Q QQQ Q Q CO CO Q O U CJ CJ CJ CJ cj u
0)
Q a
(0
H
CJ

(0
p

(fl
TJ

(0
P

Ifl
TJ
^^^^

^4 ^4 -H ^-i ^4 ^ -H ^ ^-i ^-t

XXX xxxxxxx X
a a a a a a a a a a a
0) 0) 0) 0) 01 0) 0) 0) 01 01 01
-r4 'H ^-\ -ri H H H
TJ TJ TJ TJ TJ TJ TJ TJ TJ TJ

0 0 0 0 0 0 0 0 0 0
H H H H H H H
a a a n.n.n.n,!"),!*!.!-), a
0) 01 01 01 0) 0) 0) 0) 0) 0) 01
X X ^4 -H *-i ^4 *4 ^4 'H
I I TJ TJ TJ TJ TJ TJ TJ
XX (fl (fl
tl ti p 4-1
TJTJ (fl (0 10 E E E (0 E EE EEE E
TJTJ p 4-> TJ TJ
(0 (0 (fl (fl 4> tl lH lH lH lH tl lH o o tl
TJ TJ a H H
0 0 cn tno >1 O H O H O H H o o X
H H I 41 4) O I 4J O O H H O O H H H X
"8o tl tl (0
4J
(0 Ifl tl MO 10
4-> 4J
I O O O O H H H O O X
TJTJ P P O O
a TJTJ (0 10 (0 TJ TJ TJ (0 c O O
o (0 (0 TJ TJ TJ SEE TJ E E o o g
H O H * * U * * * * tn O H OH* O H O H O H OH H X
OOHHOH OH O H O H 4) H H O O H H H O O H H O O H X
HHHHOO r-4 rH O O H H O O H H H O O H H H H OOOOOOO X
HHHHOO
HHHHOO
OO
OO
H
O
H H H
OOO
a O
O
O
O
OOO
OOO
H H H H H H
OOOOOO
OOOOOOO
H H H H H H H
O O
H H
O
H
OOOOHH HH H H H H O O OOO OOOOOO OOOOOOO O O O
OOOOOO OO O OOO H H H H H H

-
122 -
 3
o-

0)

0 -P

CH H
(0 0
\3 X
CT 0) 4J 4->
0 0) c c
4J 4J 4-1

c
IK
N
c c c
4) 4J
E C E C
4) 4->

4) 4) 4-1 4) tn o) cn o)
0 0 0) E 4) E
H P ti && 4) & E o) cn oi &>
p 0 0) oi 41 41 E 4) \ 4) 4)
a C N 4) O 0) 0) tn 0) 4->
lH c oi c to
H E 41 p tl H tl H tl
tl 4) 4) H X C C 0) c ti 0 TJ X 4) X 4)
o HH 4J o 4J H Htl H a C >, Jj 4-1 4-> 4->
01 H H 4-1 lH XX 0)X >i (0 H >, H C H C
0) * c H0 4J 4J 4J 4J 4) In an 4)
5-S 4J C & 'r4 $ *4
Q * O 0 Ra H H C H 4)H ti 4) H aTJ 0) a o
J>H} h jq (0 4-> 4-1 H H TJ 3 4-lH c E E 4J 4-> 4J -P
a a a a
888"
TJ ja io o (0 H -P > H in a-p o \ O O O O
E TJ CD 4-> 4J 4J 4-> (0 H H C 3 H H > >4 tl 3 OH tl ti 0) 4) 4) 4)
3 0) X OOOO H tl 4J TJ tn E 3 TJH ti 4) ti 4) -P In tl tl lH
H H H n X-H 0) 0) 0) 0) In (fl c 4) h E TJ lH >,4J tl lH 0 4-) 4-> H -H H -H
H MH ti In ti ti (fl > 0) 0) E 0) TJ TJ (fl ti C 4)H 4) C CTJTJTJTJ E
MH ^-i-rl -H H > 3 E E 0) lH 0) tl O tlH 4JT3 tl 4) 0) C C C C \
63 P TJ TJ TJ TJ 4-> XI p 4) H 4) C 4) C 4)
4-1 (fl C H E E H H tH H lH
2 P 3 P 3 (0 H ti tn tn tn cn tn tl 0 tlH tlTJ 0) 4)
a 63 3 a h a a a 3 a M 4) p a -p 4) C H 0) H 0) (fl (fl (fl lH in h h a ax
a-p H E E E a 4-) O a H E 0) > 10 0) 4-> 0) 4-1 4)4J 4) 4-) 0) 4J 0 OHH E E 0)
8 C 3 ifl 3 3 3 C 3 0 0) (0 0 0) CX C C C c H 0) H 0) H 4) c 0) (0 (0 3 3 3
o H 0 O -n-r--r- H O H ti X 0 PH 0 3H 3H O 0) O 0) 0 0) H TJ O O -rvo a
r-f

c
0 2 03
E a a a n i-5 Hi Eh J !> J J X
4) oo ox Eh t3n.an, Eh CJ a Eh CJ tO Eh CJ J D > H UOHHQQ cj cj tJ i-3 a a to
C CJ 2D < 2D 63 J 63 O 63 D h Q Eh J Eh Eh 2 63 < < D
sss i-o H O O H) H, H, HO s OS X u Eh Z Z H Q H
1-3
CJ to u to cj to
i-q
H q cj cj i-o h, a

0) OOOO O O OOOO o o o o o o i r- r- i~- r- r r

OOOOOO r r r- r t t~ r-

0) U CJ CJ CJ QQ CJ CJ CJ u QQ a CO a a 63 63 63 63 63 63 63 a a a a a a 63 63 63 63 63 63 63
0)
(C

10
p

(fl
TJ

(0
4J
(0
TJ

rt -H rt -rt -rt-rt-rt

xxxxxxx XXXXXXX
p. n, o, d. n, n. p.
Pi CL 0 1 0 1 ^ 0 1 Pi
CO to CO CO CO CO CO CO CO CO to CO 0) CO
H -H -H -H tH -H -H rt -H -rt -rt -rt -rt -rt

X "D 'U 'D 'D 'D 'D "D ^3 'U *0 'D *U 'D TJ
+-> **-
WW S-- %-* v^

H 0)
X H 0
1 X 0 0 0 0 0 0 0 0000000
C) 1 0 IrH
i-
1 1 IrH
i
1 i <

Q, Qj pjfLQ, QjQi Cl Cl Cl cl cl cl Cl
c OH
H c 1 10 CO CO (0 CO to CO co co co co co co co
1 H 01 *H H rt t-I -H -H -H

a i 0 'O "U 'U "U T3 "U 'U TJ TJ TJ TJ TJ TJ TJ

H a
H -H

X E E E E E EE
0 0 1
00 CO 00 00 H H a ti Ih ti Ih ti ti ti
I I I I 1 1 H CO
o o O O O H O H O H
0) oooo
C C C C c c 0 c O H H O O H H
TJ O O O H H H H
O HHH H 4J 4J H H H H
O I I I I tl tl
a aaaa o 0 a a a a TJ TJ TJ TJ TJ TJ TJ
O ^^-t^4^-l O. a HHHH EEEEEEE "BIB'S
OHOH *S OHOH * O J S S S S S 5 OHOHOH |* lit H H .
OOHH OH OOHH OH O H H H H H H H OOHHOO HHHH*
OOOO HH OOOO r4 rH O O H H H H H H H OOOOHH HHHHi
OOOO OO HHHH HH O O OOOOOOO
OOOO OO OOOO OO H H H H H H H H
H H H H H H H H H H H H H
H H H H H H H H H H H H H

-
123 -
 01
0)
0)
0)
(0
H
o

X
H c
01 4)
H 0) 4)
ti 0 ti 4-> Ih
0)
MH
Ih 4) 8 * X
Oh
Ih 0)
PX E Ih 4) -P
0) C -P H 01 Ih 0) 4J 0)
C O 0 Q cn H 4) 4-1 01 H TJ 0)
(0 CJ H C O 0 4-> CH cn 4) -P

tl 0) H Mh 4) CH Cn 4) EMH
Eh (hX tl 01 h o oi a. tlH
0 -P fl) 01 (0 (fl o a os OX
H 0) 01 P 0) 4J 4J a 4J Mh 01
0 cn to mh 01 01 tl 4J (0 (fl C 4-> C Ih
Ih c o) o 0) H TJ 4J C TJTJ C 0 C 0) 4) Ih
4JH o tl tnTJ c fl) C Oh 4) E ao
c tl 0 0) TJ 4) (0 0) E 0 fl)MHH 4J E cn TJ 4) Mh
O-P ti c TJ Ih E 41 tl H PO-Potna) cotj 0) TJ 4)
cj to a o < 0) 4) O fl) P (0 O 3 0) CO 0) 01 fl) TJ HXITJ
4)X O (fl -p o H 01 3 tl CO 0141TJ TJ tl 4)
n II II 0 4) X -P (OH c 4J 3 TJ-PlH-P 4)0)lHTJ (0 ti 0 oi
4J 0) > +) na H tl ti fl)H4J0)4)TJtlTJ(O 4)4)3
cj co a c PH oi aoi 0 P EXI01CTJ0TJTJ 0) >
H H 4J 0) 4) 01 H a a 01 I CH out) Ul) XI 04)
DXI O H C H TJ c HUH CJ (0 XI OX!
TJ a 0> H TJ e TJ H X 4) 4) C O 4J w

fl) CJ MH 0) g (fl 0 4) MHtnOJXOlXClOO -P C TJ

> ti H L IB
HMH H X EH OhX 4)X 4-> (B 4J 4) -PH

H .wCd OX 4) Mh 4J H tl 0) 4J 4J MH 01 EMH 3
0 H 4J 4J 4JMH 0 O MH 0 0) Mh Mh Mh O 01 -p &>H 0
CO C 4) 18
'
0) 0 3 a 4-> -PTJMhOMhOO 4-llHHtl 4>XX
0) 0)X O TJ 01 ti (fl 63 (fl IhhcO 0 C0H4JXI4) CO 01 01
Ih 0 fl) 01
-PH 01 4-> 4-) OS c OXlfl) CO 0) 01 .PXI -P 4J
4J TJ C -4J-H
-P 0) tl cn-P 4J014J014J4JH C4JC tl 0)
fl) 0) X 0) C 0 01 H XI 4-> C 0 tl H (fl C X4JH4JHHXI-PHJSH OHH
XI c t|H4JHHCXl fl)H MH 0 CO O 0)0)HXIHXIX1 X 0 tn 0 Mh cn^-
0) 0 0 0) 3 P 0 -P 01 (0MH 0) H o) XI XI 4J BIB.H a 0) c
0) 4J H a>H(0H 4JXMH CO 0) 4J TJ TJ C 4J -P4) X H 0) atj h 4J -P

Ih CO 4-1 ti E Ih tl 4JX tnMH.fi 0) CO (fl Ih c X 0>4JX 4JXX tnoi c c >i4) 01 C

"8 fl) 3 10 o 0 0 0 4) (0 cnn o
tin 4)
-P -P fl)TJ 0
Ih
(HH h -h x tnx tn cn-H
4-1 tl 4) to to cnn cnn hviihvh
0 t: 04) to 3
3 ifl 0
o Mh E H 0 E a H
fl) 0 4) fl) 0X1 TJ MH (0 fl) 4J c H41H4I0) 0)4JTJ4-l4J O
o 0) > -P

CO H c ^ 5 EO 0 E a IHH 4J TJ 0 O-P to 0 CC4)

(hTJOIhO ao) cn fl)
0) 4-) (fl TJ Ih 0 wjj ti 0 ti 0)XI = (fl H 01 -H H 4)0)
Ih Ih 4) Ih 3 0 3 3X1 C 4) Ih
10 fl) tl 4) XI ti Ih 0) 0)TJ TJ 0) C0TJ H cnoixxtiO)tifl)fl)TJOti ti ti H H
H E Eh TJ 3 Mh 4JTJ 0 4-> >,TJ H 4J fl) M4J 4J c cnfl) C4J4Jfl)TJ4>TJTJtl 4JX-P Ih O-P XI
CJ X O C (0 x o) 01 ti Ih OXTJ Ifl H H H 0) ti fl) TJtiTJtitiO?oitnio 4) 4J (fl (0
p (fl H 4) ^ tn 01
Ih h o 0 cnTJ OX! XI M PHHhOtlOO 0CHC4J OH
MH H 4J P>4-> Mh C-H 3 4! cnE XH 10 cn H XOHO O JZr4 MJZr-l C t|H t|
0 tl (0 O 0 4) P 4) 0) * cnfl) 4-> 4J 4J (fl 4) Ifl 0) X X J tn H OITJ 10
< Q i-3 63 H CO ti XXH c tl
Oh JS'
ll ll o) n oi .P C > * tn * cn 0 h n
c c 4J ^ H C tn o>mh 0) 4) c
hx II OH OHHX X X II 01H
0 HH E C tjv* SHXHX 0-PH4J H Ifl
0 II II II II 0 OXT3 tn Ih Ih
H H o) -p 5 0) O 0 II II co 0TJ 41 41 0 tn4) H HUH X cntn
4J < Q J 63 P tiTJ E MMHMH 1 P Ih 4) cn to to to II II II II 10 10 ifl)
Oh o 4J 0 4J >ltlH 0
18 tl 1
H H H H = OHO II II 0) to
C c TJ * II HX C n N n II OhOhhxC c P Mh
H H II aa-H 4-1 (0 II HXHXtllHH H 1 II
MH MH II II E 01 01 1 X (H-P II tn? 1 1 1 1 TJTJ 1 1 P II
0) 0) Cv h h a X O (0 tl oj aatooiTJTja a c CO
Q Q TJ 3 E ti TJTJH X OiTJ N CO Ih 01 HHOOICIOH H H o >
-
124 -
 Appendix C
Opcode Look Up Table

Index Hex Class Key Dir Width

0 00 A 1 P P
1 01 A 1 P P
2 02 A 1 P P
3 03 A 1 P P
4 04 A 0 N P
5 05 A 0 N P
6 06 D 4 N N
7 07 D 4 N N
8 08 L 1 P P
9 09 L 1 P P
10 0A L 1 P P
11 0B L 1 P P
12 OC L 0 N P
13 0D L 0 N P
14 0E D 4 N N
15 OF D 4 N N
16 10 A 1 P P
17 11 A 1 P P
18 12 A 1 P P
19 13 A 1 P P
20 14 A 0 N P
21 15 A 0 N P
22 16 D 4 N N
23 17 D 4 N N
24 18 A 1 P P
25 19 A 1 P P
26 1A A 1 P P
27 IB A 1 P P
28 1C A 0 N P
29 ID A 0 N P
30 IE D 4 N N
31 IF D 4 N N
32 20 L 1 P P
33 21 L 1 P P
34 22 L 1 P P
35 23 L 1 P P
36 24 L 0 N P
37 25 L 0 N P
38 26 P 4 N N

125 -
Index Hex Class Key Dir Width

39 27 A 0 N N
40 28 A 1 P P
41 29 A 1 P P
42 2A A 1 P P
43 2B A 1 P P
44 2C A 0 N P
45 2D A 0 N P
46 2E P 4 N N
47 2F A 0 N N
48 30 L 1 P P
49 31 L 1 P P
50 32 L 1 P P
51 33 L 1 P P
52 34 L 0 N P
53 35 L 0 N P
54 36 P 4 N N
55 37 A 0 N N
56 38 A 1 P P
57 39 A 1 P P
58 3A A 1 P P
59 3B A 1 P P
60 3C A 0 N P
61 3D A 0 N P
62 3E P 4 N N
63 3F A 0 N N
64 40 A 5 N N
65 41 A 5 N N
66 42 A 5 N N
67 43 A 5 N N
68 44 A 5 N N
69 45 A 5 N N
70 46 A 5 N N
71 47 A 5 N N
72 48 A 5 N N
73 49 A 5 N N
74 4A A 5 N N
75 4B A 5 N N
76 4C A 5 N N
77 4D A 5 N N
78 4E A 5 N N
79 4F A 5 N N

126 -
Index Hex Class Key Dir Width

80 50 D 5 N N
81 51 D 5 N N
82 52 D 5 N N
83 53 D 5 N N
84 54 D 5 N N
85 55 D 5 N N
86 56 D 5 N N
87 57 D 5 N N
88 58 D 5 N N
89 59 D 5 N N
90 5A D 5 N N
91 5B D 5 N N
92 5C D 5 N N
93 5D D 5 N N
94 5E D 5 N N
95 5F D 5 N N
96 60 Q -1 P P
97 61 Q -1 P P
98 62 Q -1 P P
99 63 Q -1 P P
100 64 Q -1 P P
101 65 Q -1 P P
102 66 Q -1 P P
103 67 Q -1 P P
104 68 Q -1 P P
105 69 Q -1 P P
106 6A Q -1 P P
107 6B Q -1 P P
108 6C Q -1 P P
109 6D Q -1 P P
110 6E Q -1 P P
111 6F Q -1 P P
112 70 C 0 N N
113 71 C 0 N N
114 72 C 0 N N
115 73 C 0 N N
116 74 C 0 N N
117 75 C 0 N N
118 76 C 0 N N
119 77 C 0 N N
120 78 C 0 N N

127 -
Index Hex Class Key Dir Width

121 79 C 0 N N
122 7A C 0 N N
123 7B C 0 N N
124 7C C 0 N N
125 7D C 0 N N
126 7E C 0 N N
127 7F C 0 N N
128 80 E 7 N P
129 81 E 7 N P
130 82 E 7 N P
131 83 E 7 N P
132 84 L 1 N P
133 85 L 1 N P
134 86 D 1 N P
135 87 D 1 N P
136 88 D 1 P P
137 89 D 1 P P
138 8A D 1 P P
139 8B D 1 P P
140 8C D 3 N N
141 8D D 1 N N
142 8E D 3 N N
143 8F D 2 N N
144 90 D 5 N N
145 91 D 5 N N
146 92 D 5 N N
147 93 D 5 N N
148 94 D 5 N N
149 95 D 5 N N
150 96 D 5 N N
151 97 D 5 N N
152 98 A 0 N N
153 99 A 0 N N
154 9A C 0 N N
155 9B P 0 N N
156 9C D 0 N N
157 9D D 0 N N
158 9E D 0 N N
159 9F D 0 N N
160 AO D 8 N P
161 Al D 8 N P
162 A2 D 8 N P
163 A3 D 8 N P

128 -
Index Hex Class Key Dir Width

164 A4 S 0 N P
165 A5 S 0 N P
166 A6 S 0 N P
167 A7 S 0 N P
168 A8 L 0 N P
169 A9 L 0 N P
170 AA S 0 N P
171 AB S 0 N P
172 AC s 0 N P
173 AD s 0 N P
174 AE s 0 N P
175 AF s 0 N P
176 BO D 5 N N
177 BI D 5 N N
178 B2 D 5 N N
179 B3 D 5 N N
180 B4 D 5 N N
181 B5 D 5 N N
182 B6 D 5 N N
183 B7 D 5 N N
184 B8 D 5 N N
185 B9 D 5 N N
186 BA D 5 N N
187 BB D 5 N N
188 BC D 5 N N
189 BD D 5 N N
190 BE D 5 N N
191 BF D 5 N N
192 CO Q -1 P P
193 Cl Q -1 P P
194 C2 C 0 N N
195 C3 C 0 N N
196 C4 D 1 N N
197 C5 D 1 N N
198 C6 D 2 N P
199 C7 D 2 N P
200 C8 Q -1 P P
201 C9 Q -1 P P
202 CA C 0 N N
203 CB C 0 N N
204 CC C 0 N N
205 CD C 0 N N
206 CE C 0 N N
207 CF C 0 N N

129 -
Index Hex Class Key Dir Width

208 DO L 7 N P
209 DI L 7 N P
210 D2 L 7 N P
211 D3 L 7 N P
212 D4 A 6 N N
213 D5 A 6 N N
214 D6 Q -1 P P
215 D7 D 0 N N
216 D8 P 2 N N
217 D9 P 2 N N
218 DA P 2 N N
219 DB P 2 N N
220 DC P 2 N N
221 DD P 2 N N
222 DE P 2 N N
223 DF P 2 N N
224 EO C 0 N N
225 El C 0 N N
226 E2 C 0 N N
227 E3 C 0 N N
228 E4 D 0 N P
229 E5 D 0 N P
230 E6 D 0 N P
231 E7 D 0 N P
232 E8 C 0 N N
233 E9 C 0 N N
234 EA C 0 N N
235 EB C 0 N N
236 EC D 0 N P
237 ED D 0 N P
238 EE D 0 N P
239 EF D 0 N P
240 FO P 0 N N
241 Fl Q -1 P P
242 F2 S 0 N N
243 F3 S 0 N N
244 F4 P 0 N N
245 F5 P 0 N N
246 F6 E 7 N P
247 F7 E 7 N P
248 F8 P 0 N N
249 F9 P 0 N N
250 FA P 0 N N
251 FB P 0 N N
252 FC P 0 N N
253 FD P 0 N N
254 FE E 7 N P
255 FF E 7 N P

130 -
 Appendix D
Data Dictionary
This is a Data Dictionary for the global/external constants,
data structures and variables used in the Simulator.

Activate: "true"
-

constant
-

defined as for use in the

Debugger to indicate whether or not a given breakpoint
should be used.

AddressState: defines the

-

finite
-

constant state (in a

state machine
sense) where the address is assembled for
entering data into memory using the Debugger assignment
function .

AHId: constant
-

identifies the AH register, defining it in

' '
binary as 100 .

AHWidth: constant
-

defines AH as an eight bit register.

ALId: constant
-

identifies the AL register, defining it in

' '
binary as 000 .

A1116Bits: constant
-

defines a mask for all 16 bits as a

' '
hexadecimal FFFF .

AllBPIDs: constant
-

defines the collection of all sixteen

breakpoints .

ALorAXId: identifies the AL or

constant AX register
-

or

accumulator (as eight or sixteen bits) where the width has

not yet been determined. The constant has a value in binary

of '000'.

ALWidth: constant
-

defines AL as an eight bit register.

ArithmeticClass: constant
-

identifies the entries in the

Opcode Look Up Table as belonging to the Arithmetic Class
and having the value 'A1.

131 -
 AssignmentID:
-

constant identifies
-

the operator
encountered whenparsing the line
Debug command as an
assignment operator, and assigning it a value of one.

AuxCarryFlag : constant defines the bit position of

-

the
Auxiliary Carry Flag in binary as '000000010000'. This
constant also serves as a mask to assemble or isolate the
flag.

AX: variable
-

a global, unsigned variable the

containing
value of the AX (and consequently the AL and AH) register.

AXId: identifies
-
-

constant the AX register or the

accumulator, defining it in binary as '000'.

AXWidth: constant
-

defines AX as a sixteen bit register.

BadCEAModeValue : indicates
-

that
-

error message an
Effective Address could not be computed successfully.

BadCheckSum: error message

-

indicates that a checksum

error was encountered attempting to load the executable
'
image into the Simulator s memory .

BadMemoryAddress : error indicates an attempt

message was
-

made to access an invalid memory location. This most likely

occurred as a result of an address outside of the supported

memory bounds.

-
BadMemoryWidth : error message
-

indicates the Simulator was

unable to interpret a width parameter.

BadOpcode: error message

-

indicates an invalid or
unsupported opcode was encountered.

BadOpcodeClass: error message

-

indicates an invalid opcode

class (in the Opcode Look Up Table) was encountered.

132 -
 BadOpcodeExtension : error message
-

indicates the opcode

extension could not be resolved.

BadOpcodeKey : error message -

indicates the opcode key

(from the Opcode Look Up Table) is not supported.

BadOperandType: error message -

indicates an invalid
operand type was encountered.

BadPortAddress : error message

-

indicates an invalid or
undefined I/O port access was attempted.

BadRegisterlD: error message

-

indicates an invalid
register identifier was used in the current operation.

BadRMDModeValue: error message

-

indicates an invalid
register /memory code was encountered.

BHId: constant
-

identifies the BH register, defining it in

' '
binary as 111 .

BHWidth: constant
-

defines BH as an eight bit register.

Bit 8Di visor:constant defines the bit eight divisor

-

in
hexadecimal as '100'. The constant is used to shift data
from the high eight bits to the low eight bits.

Bit8Multiplier : constant
-

defines the bit eight multiplier

' '
in hexadecimal as 100 . The constant is used to shift data
from the low eight bits to the high eight bits.

Blank: constant
-

defines a space or blank character.

BlankClass: Debugger This class is used

Command Class
in
-

the Debugger to eliminate extra spaces input by the user to

improve the clarity of their commands.

133 -
-

BLId: constant
-

identifies the BL register, defining it in

' Oil'
binary as .

BLWidth: constant
-

defines BL as an eight bit register.

BooleanID: constant
-

indicates that the contents of memory

being displayed by the Debugger should be displayed in the

boolean format.

BooleanState : defines the

constant
state (in a finite
-

state machinesense) where the boolean data are assembled

for entering data into memory using the Debugger assignment
function .

BP: variable
-

a global, unsigned variable containing the

value of the BP (Base Pointer) register.

BPId: identifies the BP register, defining it in

-

constant
'101'
binary as .

BPWidth: constant
-

defines BP as a sixteen bit register.

Breakpoint: constant
-

indicates that the simulation has

ceased because a breakpoint was encountered.

BreakpointClass: Debugger Command Class -

processes the
operator commands related to breakpoint operations.

BreakpointOpcode : constant
-

defines the opcode to be

substituted in memory to cause control to return to the
Debugger .

BreakPointTableType: array of records

-

provides the
storage locations for the information stored about each

breakpoint .

134
- -
 BreakRecord: record
-

defines the information stored for

each breakpoint as consisting of the following variables:

+ Encountered: boolean variable

-

indicates if the
breakpoint has been encountered.

+ Activated: boolean variable

-

indicates if the
breakpoint should be activated when execution resumes.

+ Segment: unsigned variable contains

-

the segment
register portion of the desired breakpoint location.

+ Address: unsigned variable

-

contains the address

portion of the desired breakpoint location.

+ PhysicalAddress: unsigned variable used to -

verify
that the proposed breakpoint location is within the
bounds of defined memory.

+ Code: unsigned variable

-

contains the opcode which was

removed to insert the breakpoint opcode.

BX: variable
-

a global, unsigned variable containing the

value of the BX (and consequently the BL and BH) register.

BXId: identifies the BX register, defining it in

-

constant
-

'Oil'
binary as .

BXWidth: constant
-

defines BX as a sixteen bit register.

ByteODivisor: constant defines the

-

divisor to separate

off the low eight bits in a thirty two bit VAX word. The
constant has a value in hexadecimal of '00000001'.

-
ByteOMask: constant
-
defines the mask to separate off the
low eight bits in a thirty two bit VAX word. The constant
has a value in hexadecimal of '000000FF'.

135 -
ByteOMultiplier: constant defines the multiplier to -

pack
data into the low eight bits in a
thirty two bit VAX word.
The constant has a value in hexadecimal of '00000001'.

BytelDivisor : constant defines the

-

divisor to separate
off the second eight bits in a thirty two bit VAX word. The
constant has a value in hexadecimal of '00000100'.

BytelMask: constant
-

defines the mask to separate off the

second eight bits in a thirty two bit VAX word. The
constant has a value in hexadecimal of ' 0000FF00 ' .

BytelMultiplier: constant
-

defines the multiplier to pack

data into the second eight bits in a thirty two bit VAX
word. The constant has a value in hexadecimal of
'00000100'
.

Byte2Divisor : constant defines the

-

divisor to separate
off the third eight bits in a thirty two bit VAX word. The
constant has a value in hexadecimal of ' 00010000 ' .

Byte2Mask: constant defines the mask to separate

-

off the
third eight bits in a thirty two bit VAX word. The constant
has a value in hexadecimal of '00FF0000'.

Byte2Multiplier-. constant defines the multiplier to

-

pack
data into the third eight bits in a thirty two bit VAX word.
The constant has a value in hexadecimal of '00010000'.

Byte3Divisor : constant defines the

-

divisor to separate
off the high eight bits in a thirty two bit VAX word. The
' '
constant has a value in hexadecimal of 01000000 .

Byte3Mask: constant defines the mask to separate

-

off the
high eight bits in a thirty two bit VAX word. The constant
has a value in hexadecimal of 'FF000000'.

Byte3Multiplier: constant
-

defines the multiplier to pack

data into the high eight bits in a thirty two bit VAX word.
' '
The constant has a value in hexadecimal of 01000000 .

136 -
 BytelD: constant
-

indicates that the contents of memory

being displayed by the Debugger should be displayed in the
byte format.

BytesPerWord : constant
-

defines the number of Intel bytes

of memory that fit in a DEC VAX word.

Call: constant
-

indicates that the Simulator has

encountered a subroutine call, and it may be appropriate to
"Return"
being uninterrupted simulation until a instruction
is encountered.

CarryFlag: constantdefines the bit position of the Carry

-

*
Flag in binary 000000000001 '
as This constant also serves .

as a mask to assemble or isolate the flag.

Characters: set
-

a grouping of all characters that the

user can enter at a keyboard.

CHId: constant
-

identifies the CH register, defining it in

' '
binary as 101 .

CHWidth: constant
-

defines CH as an eight bit register.

Clear: constant
-

defines the state of a boolean constant

or variable which is to have the value of false or no bits

set.

CLId: constant
-

identifies the CL register, defining it in

'001'
binary as .

CLWidth: constant
-

defines CL as an eight bit register.

-
ColonID: constant identifies
-

the operator encountered

when parsing the Debug command line as a colon operator, and

value of two.
assigning it a

-
ColonState: constant
-

defines the state (in a finite state

machine sense) where a colon has been encountered while
data into
assembling an address for entering memory using
the Debugger assignment function.

137 -
-

CommalD: constant
-

identifies the operator encountered

when parsing the Debug command line as a comma operator, and
assigning it a value of five.

ControlTransferClass:
-

constant
-

identifies the entries in

the Opcode Look Up Table as belonging to the Control
Transfer Class and having the value '
C
'
.

ControlD: constant
-

indicates that the simulation has

ceased because the user entered a Control D code.

CRTOutPortNumber : constant
-

defines the port address for

'
output to the user s terminal .

CS: variable
-

a global, unsigned variable containing the

value of the CS (Code Segment) register.

CSId: constant
-

identifies the CS register, defining it in

' '
binary as 01 .

CSWidth: constant
-

defines CS as a sixteen bit segment

register .

CX: variable
-

a global, unsigned variable containing the

value of the CX (and consequently the CL and CH) register.

CXId: constant
-

identifies the CX register, defining it in

'001'
binary as .

-
CXWidth: constant
-

defines CX as a sixteen bit register.

-
DataArraySize: constant
-

defines the maximum amount of

numeric data that a user can enter per Debugger command.

-
DataArrayType : type -
defines how numeric keyboard data are

stored until used by the Debugger.

temporarily

138 -
 DataTransferClass : constant identifies the entries in the -

Opcode Look Up Table as belonging to the Data Transfer Class

'D'
and having the value .

DeActivate: constant
-

defined as
"false"
for use in the
Debugger to indicate whether or not a given breakpoint
should be used.

DHId: identifies the DH register, defining it in

-
-

constant
' '
binary as 110 .

DHWidth: defines DH
-

bit
-

constant as an eight register.

DI: variable
-

a global, unsigned variable containing the

value of the DI (Destination Index) register.

Dlld: constant
-

identifies the DI register, defining it in

' '
binary as 111 .

DirectionFlag : constant defines the bit position

-

of the
Direction Flag in binary as '010000000000'. This constant
also serves as a mask to assemble or isolate the flag.

DlWidth: constant
-

defines DI as a sixteen bit register.

DLId: constant
-

identifies the DL register, defining it in

' '
binary as 010 .

-
DLWidth: constant
-

defines DL as an eight bit register.

DS: variable
-

a global, unsigned variable containing the

value of the DS (Data Segment) register.

DSId: constant
-

identifies the DS register,-

defining it in
' '
binary as 11 .

-
DSWidth: constant
-
defines DS as a sixteen bit segment

register.

139 -
 DX: variable
-

a global, unsigned variable containing the

value of the DX (and consequently the DL and DH) register.

DXId: constant
-

identifies the DX register, defining it in

' '
binary as 010 .

DXWidth: constant
-

defines DX as a sixteen bit register.

EffectiveAddressType: record
-

defines the information

stored for an effective address as consisting of the
following variables:

+ Mode: character variable

-

defines whether this address

should be considered as a register reference or a memory

reference.

+ Width: integer variable

-

defines the width (eight or

sixteen bits) of the variable to be accessed.

+ Address: unsigned variable

-

contains the register

designation or the memory address to be accessed.

+ Segment: integer variable

-

contains the segment

register to be used when accessing memory.

EightBits: constant
-

defines the variable or register as

value of zero.
eight bits wide, having a width

Elipse: constant
-

defines the period character.

EndofLine: constant
-

defines the end of line when parsing

user input to the Debugger.

-
ErrorClass: Debugger Command Class
-

processes the invalid

operator commands.

140
-
-
ErrorState: constant
-

defines the state (in a finite state

machine sense) that is entered when an error has been
encountered entering a datum for the Debugger.

ES: variable
-

a global, unsigned variable the

containing
value of the ES (Extra Segment) register.

ESId: constant
-

identifies the ES register, defining it in

'00'
binary as .

ESWidth: constant
-

defines ES as a sixteen bit segment

register.

ExecuteClass : Debugger Command Class processes

-

the
operator commands related to program execution.

ExtendedClass: constant
-

identifies the entries in the

Opcode Look Up Table as belonging to the Extended Class
(those opcodes whose class is not yet fully resolved) and
' '
having the value E .

FF: constant
-

defines a form feed character to be used in

formatting output for the user.

FileName: variable
-

contains the path and file name to

access VMS files.

FilenameLength: constant
-

defines the maximum permissible

length of file names.

FirstBreakpoint : constant
-

defines the starting entry in

the breakpoint table.

FirstlODataPoint: constant
-

defines the starting entry in

the I/O data table.

FirstlOPortlndex: constant
-

defines the starting entry in

the I/O port table.

141
- -
FirstOpcodeValue: constant
-

defines the starting entry in

the Opcode Look Up Table.

FirstKeywordEntry: constant defines the

-

starting entry
for the Debugger's Keyword Look Up Table.

FlagClass: Debugger Command Class -

processes the operator

commands related to flag (processor status word) operations.

Flags: variable
-

a global, record structured variable

containing the values for the flags or processor status

word.

FlagType: record
-

defines the structure used to store the

flags as consisting of the following variables:

+ Carry: boolean variable

-

contains the value of the

Carry flag.

+ Parity: boolean variable

-

contains the value of the

Parity flag.

+ AuxCarry: boolean variable -

contains the value of the

Auxiliary Carry flag.

+ Zero: boolean variable

-

contains the value of the Zero

flag.

+ Sign: boolean variable

-

contains the value of the Sign

flag.

+ Trap: boolean variable

-

contains the value of the Trap

flag.

+ Interrupt: boolean variable

-

contains the value of the

Interrupt flag.

142 -
 + Direction: boolean variable the the
-

contains value of
Direction flag.

+ Overflow: boolean variable the value of the

-

contains
Overflow flag.

Halt: constant
-

indicates that the simulation has ceased

because a halt instruction was encountered.

HexState: constant
-

defines the state (in a finite state

machine sense) where hexadecimal data are assembled before
being stored in memory using the Debugger assignment
function .

High8Bits: constant
-

defines a mask for the high eight

bits of a word and has a value in hexadecimal of ' FFOO '
.

HighMemoryLimit : constant
-

the upper limit of the memory

array, having a default value in decimal of 2048. This
provides eight kilobytes of user memory.

Inputlndicator : constant
-

defines the direction of a port

as being an input port.

InputLine: string variable

-

contains the current user

input to the Debugger.

InputLineLength : constant
-

defines the maximum length of

the user input for the Debugger as 120 decimal characters.

Debugger Command Class the

-

InputOutputClass: processes

operator commands related to input and output operations.

InputPointerRange: constant defines the -

limits of the
index to the user input for the Debugger.

Integer ID: constant

-

indicates that the contents of memory

being displayed by the Debugger should be displayed in the
decimal integer format.

143
-
-
IntegerState : defines the
constant
state (in
-

a finite
state machine
sense) where integer data are assembled for
entering into memory using the Debugger assignment function.

InterruptFlag : constant defines the bit position

-

of the
'
Interrupt Flag in binary as 001000000000
'
This constant .

also serves as a mask to assemble or isolate the flag.

InvalidAddress : constant
-

defines an invalid or unused

address in the I/O port map.

InvalidClass : constant
-

identifies the unused and

therefore invalid entries in the Opcode Look Up Table as
' '
belonging to the Invalid Class and having the value I .

This class was created to improve the robustness of decoding

opcodes .

Invalidlndex : constant
-

defines an invalid or unused index

in the I/O port map.

InvalidLocation : constant
-

defines an invalid or unused

location in the I/O port map.

IOData: variable
-

a global, two dimensional array of

unsigned variables containing the I/O data for all of the
I/O ports.

IOIndicator: constant
-

defines this I/O port as a

bidirectional port.

IOPortMap: array of records

-

provides the storage

locations for the information stored about each I/O port.

IP: variable
-

a global, unsigned variable containing the

value of the Instruction Pointer.

144 -
KeywordCharacteristics : record defines
-

the information
stored for each Debugger keyword as of the
consisting
following variables:

+ Name: variable
-

the name of the keyword.

+ Class: variable
-

the keyword class.

+ Width: variable
-

defines the operation as affecting

eight or sixteen bits.

+ ID: variable the identifying

-

value of the keyword

within the designated class.

+ Value: unsigned variable

-

used to get numeric values

from the command line into the Debugger.

KeyboardlnPortNumber: constant
-

defines the port address

'
for input from the user s terminal .

LastBreakpoint : constant
-

defines the end of the

breakpoint table.

LastKeywordEntry: constant
-

defines the end of the keyword

table .

LastOpcodeValue: constant
-

defines the last entry in the

Opcode Look Up Table.

LengthID: constant
-

indicates that the specified command

should be repeated by the Debugger the indicated number of

times .

' ' ' '

Letters : set
-

a grouping of all letters from A to Z ,

both upper and lower case.

145
-
-
LettersAndNumbers : set
-

a grouping of allletters from

'A'

' '
to Z both upper and lower case and all digits
'
0
'
to
'
9
'
.

LogicClass: constant identifies the entries in the Opcode

-

Look Up Table as belonging to the Logic Class and

'L'
having the
value .

Low8Bits: constant
-

defines a mask for the lower eight

bits of a word and has a value in hexadecimal of ' FF
'
.

LowerPortlndicator : constant indicates the associated

-

information describes an eight bit I/O port or the lower

eight bits of a sixteen bit port.

LowMemoryLimit : constant
-

defines the lower bound of the

memory array having a value in decimal of zero.

MaxID: constant
-

defines the maximum value of the

identifier allowed for a class of Debugger commands.

MaxNumberof IOBytes defines the

: maximumconstant
number
-

of data bytes that can be entered for each I/O port, having
a decimal default value of 256 or four times the "Max Number
Words"
Of 10 allocated.

MaxNumberof IOPorts : constant

-

defines the maximum number

of I/O for the Simulator

ports and support programs having a

decimal default value of eight.

MaxNumberof I OWords : constant

-

defines the maximum number

of data words that can be allocated for each I/O port,

decimal default value of 64.

having a

MaxWidth: constant
-

defines the maximum width used to

verify keyword names for the Debugger.

Memory: variable
-

a global array which contains the user

program and data.

146 -
MemoryArray: type -

defines the limits and data type for

the memory array.

MemoryClass: Debugger Command Class -

processes the
operator commands related to memory access operations.

MinID: constant
-

defines the minimum value of the

identifier for a class of Debugger commands.

MinusID: constant identifies

-

the operator encountered

when parsing the Debug command line as a minus operator, and

assigning it a value of four.

MinWidth: constant
-

defines the minimum width for names in

the Debugger keyword table.

NameString: string variable

-

defines a string to contain

the commands parsed off the user input line for the
Debugger .

NameType: type -

defines the characteristics of the name

string .

NegativeOper ator : constant

-

defines a unary operator for

negating values input by the user.

NoMemoryAccess : error message

-

indicates that memory was

not accessed during the loading of a program (i.e. the

Droaram
program was not loaded into memory) .

Normal: constant
-

indicates that the simulation of this

opcode was completed in a normal fashion.

NullAddressValue : constant
-

defines a null address value

for default operations in the Debugger.

NullEntries: constant
-

defines a null default value for

the number of entries in the Debugger.

147
-
-
NullSegmentValue: constant defines a -

null segment value

for default operations in the Debugger.

Numbers : set
-

a
grouping of all digits '
0
'
to
'
9
'
.

NumericClass : Debugger Command Class processes

-

the
operator commands related to entering numeric data.

OpcodeLUT: array of records provides the storage

-

locations for the information stored about each opcode entry

in the Opcode Look Up Table.

OpcodeLUTEntry : record defines the entries in the-

Opcode
Look Up Table as consisting of the following variables:

+ OpcodeClass: variable
-

contains the opcode class (i.e.

Data Transfer, Arithmetic etc.) for this entry.

+ OpcodeKey: variable
-

contains the opcode key for this

entry .

+ DirectionBitPresent: variable
-

indicates in a boolean
sense if a direction bit is present in this opcode.

+ WidthBitPresent : variable
-

indicates in a boolean
sense if a width bit is present in this opcode.

OpcodeType: record
-

defines the information stored for

each opcode as consisting of the following variables:

+ Direction: variable defines -

whether the information

mores to or from the CPU.

+ Full: variable
-

the value of the opcode.

+ Width: variable
-
defines this operation as an eight or

sixteen bit process.

148 -
OperatorClass: Debugger Command Class -

processes the
punctuation (i.e. equal sign, plus sign, minus sign, colon
and comma) encountered in operator commands.

Outputlndicator: constant
-

defines this I/O port as an

output port.

Overf lowFlag : constant defines the bit -

position of the
Overflow Flag in binary as '100000000000'. This constant

also serves as a mask to assemble or isolate the flag.

PageSize: constant
-

defines the number of lines to be

placed on the printed page output for the user.

ParityFlag: constant
-

defines the bit position of the

' '
Parity Flag in binary as 000000000100 . This constant also

serves as a mask to assemble or isolate the flag.

PlusID: constant identifies the

-

operator encountered when

parsing the Debug command line as a plus operator, and

assigning it a value of three.

Pointer ID: constant

-

indicates that the contents of memory

displayed by the Debugger should be displayed in the
being
pointer format.

PortEntry: record defines the information stored for

-
each

I/O port as consisting of the following variables:

+ Address: variable
-

contains the address of the I/O

port.

+ Auxlndex: variable
-

contains the index for the

eight bits of information if this is a sixteen
remaining
bit port.

+ Datalndex: variable
-

contains the user's program index

into the data array for this port.

-
149 -
 + Inputlndex: variable
-

contains the number of data

entries made by the user when creating input data.

+ PortWidth: variable
-

indicates if this is an eight or

sixteen bit wide port.

+ LowerUpper Indicator: variable indicates if this is -

the lower or upper eight bits of information for a

sixteen bit port.

+ InOutlndicator : variable
-

indicates if this is an
input port, an output port or a bidirectional port.

PortMap: array of records

-

defines the characteristics of

the I/O port map.

PositiveOperator: constant
-

defines a unary positive

operator .

ProcessorControlClass: constant
-

identifies the entries in

the Opcode Look Up Table as belonging to the Processor
Control Class and having the value 'P'.

Qualif ierClass : Debugger Command Class -

processes the
memory operation qualifiers (i.e. LENGTH and TO).

RegisterClass: Debugger Command Class -

processes the
operator commands related to register operations.

RegisterType : record
-

defines the information stored for

each register as consisting of the following variables:

+ Id: variable
-
contains the register identifier.

+ Width: variable
-
contains the width parameter for the
register (eight or sixteen bits).

150 -
Return: constant
-

indicates that the Simulator has

"Return"
encountered a instruction and the Debugger may need
to cease uninterrupted simulation and return control to the
user.

SegmentOffset: constant
-

defines the multiplier to be used

when computing a physical address.

SegmentOverRideCount : variable
-

contains the necessary

information to determine if a segment override should be
applied on the next operation.

SegmentOverRideValue: variable
-

contains the register

identifier that should be used in the segment override
operation .

SegmentState : constant
-

defines the state (in a finite

state machine sense) where the segment portion of the
address is assembled for entering data into memory using the
Debugger assignment function.

SeparatorState : constant (in a finite

-

defines the state

state machine
sense) datum separator
which is entered when a

(comma) is encountered while entering data into memory using

the Debugger assignment function.

SetHigh: constant
-

defines the state of a boolean constant

or variable which is to have the value of true or all bits

set.

ShortString: string variable

-

contains a short string for

manipulation by the Simulator.

Shorts tringLength: constant

-

defines the length of the

short string.

SI: variable
-

a global, unsigned variable containing the

value of the SI (Source Index) register.

151
-
-
-

SignFlag: constantdefines the bit position of

-

the Sign
'
Flag in binary 000010000000 '
as This constant also serves .

as a mask to assemble or isolate the flag.

Slid: constant
-

identifies the SI register, defining it in

'110'
binary as .

"mod"
-

SimpleMode: constant defines the bits for computing

-

the effective address of the direct memory to accumulator

and accumulator to memory data transfer operations, and has
the binary value of ' 0 ' .

"r/m"
-

SimpleRM: constant defines the

-

bits for computing

the effective address of the direct memory to accumulator
and accumulator to memory data transfer operations, and has
' '
the binary value of 110 .

SIntegerlD: constant indicates that the -

contents of

memory being displayed by the Debugger should be displayed

in the signed eight bit decimal integer format.

SlWidth: constant
-

defines SI as a sixteen bit register.

SixteenBits: constant
-

defines the variable or register as

sixteen bits wide, having a width value of one.

SP: variable
-

a global, unsigned variable containing the

value of the SP (Stack Pointer) register.

SPId: constant
-
identifies the SP register, defining it in
' '
binary as 100 .

SPWidth: constant
-

defines SP as a sixteen bit register.

SRWidth: constant
-

defines the segment register as sixteen

width value of two.
bits wide, having a

-
SS: variable
-

a global, unsigned variable containing the

value of the SS (Stack Segment) register.

152
-
-
SSId: constant
-

identifies the SS register, defining it in

' '
binary as 10 .

SSWidth: constant
-

defines SS as a sixteen bit segment

register .

StackClass: Debugger Command Class processes the

-

operator
commands related to the stack operations.

StartOfData: constant
-

defines the initial index into the

data entered by the user for the Debugger.

StartofLine: constant defines the initial index into -

the
InputLine for the Debugger.

StringClass: constant
-

identifies the entries in the

Opcode Look Up Table as belonging to the String Class and
' '
having the value S .

ToID: constant
-

indicates that the contents of memory

should be displayed by the Debugger from the specified

starting address to the subsequent terminating address.

TrapFlag: constantdefines the bit position of

-

the Trap
Flag in binary '000100000000'.
as This constant also serves
as a mask to assemble or isolate the flag.

TrueFalseClass: Debugger Class

Command processes
-

the
operator commands related to entering boolean data.

UnaryState: constant
-

defines the state (in a finite state

machine sense) which is entered when it is desired to store
the two's complement of the datum into memory using the
Debugger assignment function.

UndefinedClass: constant
-
defines an invalid class for the
Debugger keyword table to improve the Debugger's robustness.

153 -
UndefinedID: constant
-

defines an invalid identifier for

the Debugger keyword table to improve the Debugger's
robustness .

Undef inedName : constant

-

defines an invalid name for the

Debugger keyword table to improve the Debugger's robustness.

Undef inedWidth: constant

-

defines an invalid name width

for the Debugger keyword table to improve the Debugger's
robustness .

UpperPortlndicator : constant
-

defines this I/O port

information as belonging to the upper eight bits of a
sixteen bit I/O port.

UtilityClass : Debugger Command Class processes

-

the
operator commands related to utility operations (e.g. load
and log ) .

WordID: constant
-

indicates that the contents of memory

being displayed by the Debugger should be displayed in the
word format.

WordMultiplier : constant defines

-

a multiplier to isolate
an Intel word and has a hexadecimal value of '100'.

ZeroFlag: defines the bit position of

constant
-

the Zero
Flag in binary '000001000000'.
as This constant also serves
as a mask to assemble or isolate the flag.

ZeroOne: type -

defines a range of integers from minus one

to one, with an acceptable valid range of zero to one and

with an acceptable invalid state of minus one. This is used
to perform range checking on the width variable.

154 -
 Appendix E
Keyword Look Up Table

The following list contains the current

definitions of the keywords used in the
Debugger .

dex Keyword ID Class Width

0 EXIT 1 U 1
1 LOG 2 U 1
2 LOAD 3 U 1
3 LENGTH 3 Q 1
4 TO 5 Q 1
5 =
1 0 1
6 : 2 0 1
7 + 3 0 1
8 -

4 0 1
9 i 5 0 1
10 PORT 2 I 0
11 WPORT 6 I 1
12 (blank) 1 (blank) 1
13 FALSE 0 L 1
14 TRUE -1 L 1
15 STACK 1 S 1
16 REGISTER 8 R 2
17 AL 0 R 0
18 CL 1 R 0
19 DL 2 R 0
20 BL 3 R 0
21 AH 4 R 0
22 CH 5 R 0
23 DH 6 R 0
24 BH 7 R 0
25 AX 0 R 1
26 CX 1 R 1
27 DX 2 R 1
28 BX 3 R 1
29 SP 4 R 1
30 BP 5 R 1
31 SI 6 R 1
32 DI 7 R 1

155 -
Index Keyword ID Class Width

33 ES OR 2
34 CS 1 R 2
35 SS 2 R 2
36 DS 3 R 2
37 IP 4 R 2
38 RF 5 R 2
39 RAL OR 0
40 RCL 1 R 0
41 RDL 3 R 0
42 RBL 3 R 0
43 RAH 4 R 0
44 RCH 5 R 0
45 RDH 6 R 0
46 RBH 7 R 0
47 RAX OR 1
48 RCX 1 R 1
49 RDX 2 R 1
50 RBX 3 R 1
51 CFL OF 0
52 PFL IF 0
53 AFL 2 F 0
54 ZFL 3 F 0
55 SFL 4 F 0
56 TFL 5 F 0
57 IFL 6 F 0
58 DFL 7 F 0
59 OFL 8 F 0
60 FLAG 9 F 0
61 BOOLEAN 1 M 0
62 BYTE 2 M 0
63 INTEGER 3 M 0
64 POINTER 4 M 0
65 SINTEGER 5 M 0
66 WORD 6 M 0
67 Qqqqqqqq -2 z -1

68 Qqqqqqqq -2 z -1

69 Qqqqqqqq -2 z -1

156 -
Cndes: Keyword ID Class Width

70 BPO 0 B 1
71 BP1 1 B 1
72 BP2 2 B 1
73 BP3 3 B 1
74 BP4 4 B 1
75 BP5 5 B 1
76 BP6 6 B 1
77 BP7 7 B 1
78 BP8 8 B 1
79 BP9 9 B 1
80 BPA 10 B 1
81 BPB 11 B 1
82 BPC 12 B 1
83 BPD 13 B 1
84 BPE 14 B 1
85 BPF 15 B 1
86 ALLBP 16 B 1
87 GO 1 X 1
88 G 1 X 1
89 START 1 X 1
90 CONTINUE 2 X 1
91 RESUME 2 X 1
92 R 2 X 1
93 STEP 3 X 1
94 S 3 X 1
95 PSTEP 4 X 1
96 P 4 X 1
97 Qqqqqqqq -2 z -1

98 Qqqqqqqq -2 z -1

99 Qqqqqqqq -2 z -1

100 EX 1 U 1

157 -
 Appendix F User's Guide for the Intel*8086 Simulator

13.1 General

Three
-

main programs are available to the general user:

+ Simulator -

for executing programs (SIM86).

+ I/O Map Generation for creating reviewing the

-

and I/O
map (IOMAP86).

+ Review I/O Data -

for creating input data and reviewing

input and output data ( IODATA86 ) .

All numbers in the Simulator and support programs are in

hexadecimal unless otherwise specified.

Any place a file name is requested, a full VMS path name can
-

be used, but the total path name specified must be less than
40 characters.

An invalid file name anywhere a file name is requested will

crash the Simulator.

The Simulator should be insensitive to upper / lower case

for letters.

Programs must be assembled, linked and located by the cross

products tools.

Programs must reside between the addresses of 0 and 8192

(8K) (bytes) memory, including all stack and data
requirements. Attempts to access outside these boundaries
should produce soft errors.

Each program is responsible for setting up all Segment

Registers, Stack Pointer and Instruction Pointer prior to
use. (Default values are zero.)

158 -
 No Intel system services are provided.

All trap definitions are left to the user (except for

breakpoint, which cannot be redefined).

The Simulator will display the fact that a trap was

encountered .

Input and output port addresses and data are mapped to save
disk space and execution time.

13.2 Input And Output

Input / Output space is limited to 8 I/O ports. (A 16 bit

wide port counts as two ports ) .

I/O data is limited to 256 bytes

-

for an 8 bit port or 256

words for a 16 bit port.

I/O can be directed to the user's terminal by using the port

"FF"
address for both input and output.

13.3 Debugger

Anywhere a punctuation or terminator is used, a space can be

added for legibility (i.e. byte AX : BX <cr> is the same as
byte AX:BX<cr>, or BP0=<cr> is the same as BPO =
<cr>).

Logging of Debugger commands is available, but recovery from

or execution of commands from the log file is not supported.

All commands can be shortened to 3 letters if their original

form is longer. Spelling past 3 letters is not checked.

159 -
Available commands
-

(an alphabetical listing of all

commands can be found in Attachment I, and a listing of
commands by class can be found in Attachment II):

+ LOG turns on logging of commands.

+ EXIt exits from the Debugger and the Simulator.

+ LOAd loads a file.

+ All registers and flags are available their

using
standard naming conventions.

Examples :

* RAX <cr> will display the contents of the AX

register.

* AX <cr> will
=
FdCb set the contents of the AX
register to the hexadecimal value FDCB.

+ REGister will display the contents of all registers.

+ FLAg will display the contents of all flags.

+ Sixteen breakpoints are available: BPO through BPF.

BPO <cr> displays breakpoint 0.

BPO yyyy <cr> breakpoint 0 at memory location

=
sets
-

CS : yyyy.

BPO yyyy <cr> sets breakpoint 0 at

=
xxxx memory
-

location xxxx: yyyy where xxxx is the segment

register value and yyyy is the displacement.

BPO =
<cr> clears breakpoint 0.

+ ALLbp <cr> displays all breakpoints.

+ =
<cr> clears all breakpoints.
ALLbp

160 -
+
Starting program execution:

GO <cr>, G
-

<cr>, or STArt <cr> will start a program

at CS : IP.

GO
-
=
xxxx :
yyyy <cr> will load CS : IP with xxxx
and yyyy respectively and start the program.

GO =
CS : IP <cr> will start the program at CS : IP.

GO yyyy <cr> will assume the current value for CS,

=

load IP with yyyy and start the program at CS : IP.

GO =
IP <cr> will assume the current value for CS
and start the program at CS : IP.

+ RESume, R, CONtinue are used to resume execution.

+ S
STEp, will single step through the program.

+ PSTep, P will step over subroutines unless breakpoints

are encountered.

+ The following memory access commands are supported:

BOOlean the least significant bit of the

-

byte is
interpreted as FALSE if its value is 0 and TRUE if
its value is 1.

BYTe -

8 bits of data in hexadecimal.

WORd -

16 bits of data in hexadecimal.

INTeger
-

8 bits of data as a signed decimal number.

SINteger
-

16 bits of data as a signed decimal

number.

Pointer
-

32 bits of data interpreted as a segment

address pair (e.g. Segment : Address).

161 -
 + All memory segment and address values are specified in
hexadecimal .

+ All addresses for memory follows:

can be specified as

Registerl
-

Register2: where the -

contents of
Register 1 will be used as the segment value and the
contents of Register 2 will be used as the address
value .

xxxx : yyyy where xxxx will be used as the segment

-

value and yyyy will be used as the address value.

CS will be used
~ ~

yyyy where as the segment value

and yyyy will be used as the address value.

I/O ports can be accessed by port number or the contents of

the DX register.

If the low address of a 16 bit port is accessed with the

WPOrt command then all 16 bits are displayed or modified as
requested.

If the high address of a 16 bit port is accessed with the

WPOrt command then all 16 bits are displayed or modified as
requested.

If the low address of a 16 bit port is accessed with the

PORt command then only the specified 8 bits are displayed or
modified as requested.

If the high address of a 16 bit port is accessed with the

PORt command then only the specified 8 bits are displayed or
modified as requested.

Control D will abort a run away program at the next

instruction .

-
Control Y or Control C will abort a run away Simulator.

162
-
-
13.4 Attachment I -

An Alphabetical Listing Of Debugger

Keywords

(blank)
AFL
-

AH
-

AL
-

ALLBP, ALLB, ALL

AX
-

BH
-

BL
-

BOOLEAN, BOOLEA, BOOLE, BOOL, BOO

BP
-

BPO
BP1
-

BP2
-

BP3
BP4
-

BP5
-

BP6
BP7
-

BP8
-

BP9
BPA
-

BPB
BPC
-

BPD
-

BPE
-

BPF
-

BX
BYTE, BYT
-

CFL
-

CH
-

CL
CONTINUE, CONTINU, CONTIN, CONTI, CONT, CON
-

CS
-

CX
-

DFL
-

DH
-

DI
-

DL
-

DS
-

DX
-

ES
EXIT, EXI
-

FALSE, FALS, FAL

FLAG, FLA
-

G
GO, G
-

IFL
-

INTEGER, INTEGE, INTEG, INTE, INT

163 -
IP
LENGTH, LENGT, LENG, LEN
LOAD, LOA
LOG
OFL
PFL
P
POINTER, POINTE, POINT, POIN, POI
PORT, POR
PSTEP, PSTE, PST, P
R
RAH
RAL
RAX
RBH
RBL
RBX
RCH
RCL
RCX
RDH
RDL
RDX
REGISTER, REGISTE, REGIST, REGIS, REGI, REG
RESUME, RESUM, RESU, RES, R
RF
S
SFL
SI
SINTEGER, SINTEGE, SINTEG, SINTE, SINT, SIN
SP
SS
STACK, STAC, STA
STEP, STE, S
TFL
TO
TRUE, TRU
WORD, WOR
WPORT, WPOR, WPO
ZFL

+ (Unary operator)
(Unary
-

operator)

-
164 -
13.5 Attachment II -

Debugger Keywords Listed By Class

Blank
(blank)
-

Breakpoints
BPO
BP1
BP2
BP3
BP4
BP5
BP6
BP7
BP8
BP9
BPA
BPB
BPC
BPD
BPE
BPF
ALLbp

Execution
GO, G
CONtinue
RESume, R
STEp, S
PSTep, P

Flags
CFL
PFL
AFL
ZFL
SFL
TFL
IFL
DFL
OFL
FLAg

-
Input and Output
PORt
WPOrt

-
Logic Values
FALse
TRUe

165
-
-
Memory
BOOlean
BYTe
INTeger
Pointer
SINteger
WORd

Operands

+
(Unary operator)
-

(Unary operator)

Qualifiers
LENgth
TO

Register
REGister
AL, RAL
CL, RCL
DL, RDL
BL, RBL
AH, RAH
CH, RCH
DH, RDH
BH, RBH
AX, RAX
CX, RCX
DX, RDX
BX, RBX
SP
BP
SI
DI
ES
CS
SS
DS
IP
RF

Stack
STAck

Utility
EXIt
LOAd
LOG

166 -
13.6 Support Policy
I will investigate problems reported to me under the following
conditions :

Notification be
-

should made via the system mail utility to

user WAC1751 describing the problem.

Mail will be examined at least once per week for reports of

malfunctions.

The author the Simulator 8 6 program is not responsible for

of

any studentfailing to complete an assignment as a result of

a malfunction of the Simulator.

Include in the description.

-

all symptoms problem

A short test program which demonstrates the problem

(typically 5 to 10 lines of source code) is required for a

rigorous investigation. The test program should be mailed
to WAC1751 along with a log file of the Debugger commands

used to demonstrate the problem.

Resolution of bonafide problems is not guaranteed within a

specified time frame.

Comments regarding improvements to the user interface will

be taken under consideration.

167 -
13.7 Maintenance Capabilities

Memory space, number of I/O ports, amount of I/O data, file

name length and terminal designator can be varied by
port
editing the appropriate definition files, recompiling and
relinking the Simulator programs.
-

The Simulator executable image is about 160 blocks in size.

Three utilities
-

are available for maintenance:

A Command build file -

walks the maintenance person

through the building of the three main programs and two
support utilities.

Opcode Look Up Table Generator -

for Opcode Look Up

Table generation and maintenance.

Debugger Keyword Look Up Table Generator -

for Debugger
Keyword Look Up Table maintenance.

The Build Command procedures assumes all definition files in

the parent directory.

The maintenance person can modify the spelling of any

keyword, provided it doesn't conflict with other keywords or
a single, double or triple hexadecimal character number
(i.e. ACE is not a valid keyword). Note that it is the
responsibility of the maintenance person to insure that
conflicts do not exist. No checks are done by the program
to inhibit invalid or duplicate entries.

168 -
The Simulator is limited to VAX Pascal and it's extensions
except for:

Three features which use the VAX Utilities and $QIOW

functions .

Support
-

of Control D

Keyboard input
-

CRT output
-

Checking for the existence of a file. This feature uses

a FORTRAN Subroutine.

The Simulator assumes the Opcode Look Up Table File and the
Debugger Keyword Look Up Table File in the same directory as
the executable module.

169
13.8 Release Notes For The Intel 8086 Simulator

The following problems have been corrected:

The implementation of CBW has been corrected. The

investigation has surfaced other
"bugs"
associated with
storing 8 bit registers, which have also been corrected.

The following changes have been made:

The format of the LOG instruction has changed.

* <CR>
LOG displays the name of the log file

*
LOG =
<CR> turns off logging of commands

*
LOG =
filename <CR> writes Debugger commands to the
"filename"
file called

The format of the LOAd instruction has changed.

* LOAd <CR> displays the name of the file loaded

* filename <CR> loads the

LOAd =
specified file into
memory

An invalid file name or VMS pathlonger

name should no
crash the Simulator. Invalid file
instead names should
generate an error message and allow you to input a
correct file name or path name. Invalid file formats
(such as reading a data file instead of a map file) will
still crash the Simulator.

170 -
 Appendix G
Unsupported DEBUG-88 Commands

DEBUG-88
The following is an alphabetical list of the commands

which are not supported:

* ASM

* UNTIL
COUNT, WHILE,

* DEFINE

* DOMAIN

* EVALUATE

* EVALUATE LINE

* EVALUATE SYMBOL

*
IF, THEN, ORIF, ELSE

* LINE

* MODULE

* RADIX

* REMOVE

*
REPEAT, WHILE, UNTIL

* SYMBOL

171
-
-
 Bibliography

1. Intel iAPX86/88, 186/188 User's Manual -

Programmer's
Reference May, 1983 (Order Number
210911-0)

2. Microcomputer Systems: The 8086/8088 Architecture,

Family
Programming and Design by Yu-cheng Liu and Glenn A. Gibson

3. HP-16C Computer Scientist Owner's Handbook April 1984

VAX-
4. 11 PASCAL Language Summary (Order No. AV-L368A-TE)
October 1982

5. MCS-86 Assembly Language Reference Guide 9800749A October

1978

6 .
Programming in PASCAL , Revised Edition , by Peter Grogono

7 . Introduction to Switching Theory and Logical Design , by

Fredrick J. Hill, Gerald R. Peterson

8. VAX-11 Pascal Language Reference Manual (Order No.

AA-H484C-TE)

9. VAX-11 Pascal User's Guide (Order No. AA-H485C-TE)

10. Intel Debug-88 User's Manual (Order Number 121758-001)

11. Intel iAPX86,88 Family Utilities User's Guide (Order Number

121616-004)

12. Intel iSDM86 System Debug Monitor Reference Manual (Order

Number 146165-001)

13. Intel MCS-86 Absolute Object File Formats (Order Number

9800821A)

172
-
-
14. Intel 8086 Relocatable Object Module Formats (Order Number
121748-001)

15. Utilizing VMS Features from VAX Pascal, Lecture Guide

EY2321E-LG0001

16. Utilizing VMS Features from VAX Pascal, Language Specific

Workbook EY-2320E-WB-0001

17. Motorola M6800 Programming Reference Manual M68PRM(D)

18. VAX/VMS Internals and Data Structures by Lawrence J.

-

Kenah
& Simon F. Bate (Order No. EY-00014-DD)

19. VAX/VMS Run-Time Library Routines Reference Manual (Order

No. AA-Z502B-TE)

20. VAX/VMS System Services Reference Manual (Order No.

AA-Z501B-TE)

21. VAX/VMS I/O User's Reference Manual: Part 1 (Order No.

AA-Z600C-TE)

22. Rochester Public Library, Rundel Branch, Science &

Technology Division

173
-