University of Nigeria

Research Publications
Author

ONUCHUKWU Rose-Mary O.

PG/M.ENG./85/3300
Title

A versatile Microprocessor Development System

Using Apple II and Mat. 385
Faculty

Engineering
Department

Electronic Engineering
Date

September, 1987

Digitally signed by Fidelia Ngozi

Signature

Fidelia Ngozi Asiegbu

DN: CN = Fidelia Ngozi Asiegbu, C =
NG, O = University of Nigeria, OU =

Asiegbu University Library

Reason: I have reviewed this document
Date: 2008.10.06 15:51:17 +01'00'
 A VERSATILE MICROPROCESSOR
DEVELOPMENT SYSTEM

USING APPLE 11 AND MAT. 385

Onuchukwu Rose-Mary Obumnaeke

DEPARTMENT OF ELECTRONIC ENGINEERING

University of Nigeria, Nsukka

September, 1987.
 A VERSATILE MICROPROCESSOR DEVELOPMENT
SYSTEM USING APPLE I1 AND MAT 385

BY

ONUCHUKWU, ROSE-MARY OBUMNAEKE

REG. NO. PG/M.ENG/85/3300

BEING THE RESEARCH PROJECT SuJ3f"lITTED

THE DEPARTMENT OF ELECTRONIC ENGINEERING,
UNIVERSITY OF NIGERIA NSUKKA,
IN PARTIAL ElLFILMENT OF THE REQUIRFMENTS FOR THE AWARD OF
MASTER OF ENGINEERING DEGREE IN ELECTRONIC ENGINEERING

CERTIFIED BY:

ACCEPTED BY: /

HEAD OF DEPAFTMENT
 - ( i ) -

DEDICATION

his p r o j e c t is dedicated t o my mother, brothers, s i s t e r s and a l l my

well wishers.
 - (ii) -

ABSTRACT
The project is aimed at producing a versatile Microprocessor
Developnent Systan (MDS) £ran an existing MAT 385 Microcanputer trainer
kit and an Apple 11 Personal Ccmputer.

The MAT 385 is an 8085 microprocessor (UP) which a c w r t ~only machine

codes in hexadecimal (Hex) form. For prograns to be run on it, there is a
need for hand assenbly £ran source code to object code. This is tedious,
time consuning and for very long progran there is a tendency for many
mistakes. The MAT 385 does not have a facility for accepting assenbly
language thus a resident assanbler is not practicable. Hence a cross
assenbler is developed on Apple 11 PC.

The cross assenbler was designed using topdown design approach and
implenented on Apple I1 using the DOS facilities of Apple 11. The cross
assembler resides on the Apple 11 disk and is called into the systen
whenever it is required. Results £ran the cross assembler were also
printed and analysed.

The interface facilities available on the Apple I1 and MAT 385 were
studied and based on the available facilities interface design was made
for the interconnection of Apple I1 and MAT 385. The interface design
involved hardware interconnection of Apple I1 and MAT 385 and interface
software in both the Apple I1 and MAT 385. The interface design was
implenented, tested and satisfactory results were got.

The newly produced MDS is such that the assanbler is loaded into
Apple 11, £ran the disk, where the assably language are keyed in and
assenbled. On canpletion of the translation, the machine codes produced
are down loaded into MAT 385 where the program is debugged and tested.
..
./iii
 - ( iii ) -

DECLARATION

Unless otherwise stated, I claim credit for the work contained in

this thesis. The ~hesishas not been shitted to any other university.
However, ideas in it may be part of work suhitted to other universities
or technical journals.
 - ( i v ) -

I express my profound g r a t i t u d e t o my P r o j e c t Supervisor D r . M.A.

Nwachuku whose advice was very h e l p f u l and the c u r r e n t Head of Department

D r . Nzeako whose support led t o t h e successful canpletion of the work.

Also my thanks goes t o a l l m a n b e r s of s t a f f of Electronic ~ n g i n e e r i n g

Department e s p e c i a l l y D r . C.C. Osuagwu whose advice was very h e l p f u l both

acadanically and morally.
 TABLE OF CONTENT
-

PAGE
DEDICATION 0 .*. i
ABSTR?CT *.* .me ii
DECLARATION ... ... iii
ACKNCWLEDGm ... ... iv

CHAPTER ONE: REVIW OF MICROPROCESSOR DEVELOPMENT SYSTEM

CHAPTER TWO: DESIGN OF A VERSATILE M E ... ...

2.1 ~ n t r o d u cion
t . ... .
2.2 Apple I1 ... **. ...
2.2.1 Built-1n Input - Output F a c i l i t i e s
2.3 MAT 385 ... ... ...
2.3.1 8155, 8755 RST ...
& ... ...
2.4 MDS ~ e s i g n ... ... ...
CHAPTER THREE : OVERVIEX'J OF SOJ3WZUE DEVELOPMENT TECHNIQUES
3.1 Introduction ... ... ...
3.2 Flow Chart ... ... .
3.3 mp Down Design ... .. ...
3.3.1 Functional ~ e c a n p o s i t i o n ... ...
3.3.2 Data S t r u c t u r e Design ... ...
3.3.3 Data Flow Design ... ...
3.4 Software Design Method S e l e c t i o n ...
3.5 Data Flow Design ... ... ...
Design S t r a t e g y ... ... ...
Structured Chart ... .. ..
program Design Language ... ...
CHAPTER FOUR: C R O S S ASSE1YIBLER DESIGN ... ...
4.1 Introduction ... ... ...
4.2 Assenbler Survey ... .. ..
4.3 Assenbly Language Overview ... ...
.
4 4 Ekatures of An Assmbler Which Support
Gocd Program Design ... ...
Symbol Manipulation . ...
Data Constant Specification ... ...
Other Attributes ... ...
Assenbler Directives .. ...
Origin (ORG) ... ... ...
m a t e (mu) 0 . . .. ...
Def h e Byte (DB) ... ... ...
Define Word (DW) ... ... ...
T i t t l e . End. L i s t ... ...
Cross Assenbler Design ... ...
Introduction ... ... ...
Requ i renen t ... ... ...
Data Flow Diagram & Structure Chart ...
Cross Assenbler Program Design Language
Main Program ... ... ..
Input Source Code ... ...
validate Source Code ... ...
G e t Field ... .. .
v a l i d a t e Field ... ... ...
Assenble Source Code ... ...
G e t Label Table ... ... ...
Make ~ a b e lTable (Pass One) ... ...
Evaluate Machine Code ... ...
Store Objectcode ... ... . .
Produce Hard Copy ... ...
Cod ing ... .. ...
CHAFFER FIVE: CROSS ASSEMBLER IMPLEMENTATION
5.1 Overv i'ew ... ...
5.2 The Input Module ... ...
5.2.1 Basic ~ i l eSysten ...
5.3 The Source Code validation Module
5.3.1 Mode of Operation
5.3.1.1 MOV ... ...
5.3.1.2 MVI 0.. ...
5.3.1.3 ADI. ACI .....ICUT
5.3.1.4 LXI ... 0..

5.3.1.5 IDA. STAR ....IORG

5.3.1.6 RNZ. RZ. RC. ..I LIST
5.3.1.7 LDAX. STAX..... DAD
5.3e1.8 ADD. ADC. ..... DCR
5.3.1.9 RST ... 0 . .

5.3.1.10 DB ... e..

5.3.1.11 DW ... ...

5.3.1.12 Tttle ... ... ...
5.4 Subroutine Make Label Table ...
5.4.1 Non Executable Codes ...
.
55 Subroutine Generate Object W e
.
5 5.1 M W ... ... ...
5.5.2 MVI ... ... ...
5.5.3 ADI. ACI. ....I OUT ...
5.5.4 LXI ... ... ...
5.5.5 LDA. STA. ....a. OY1 ...
5.5.6 ORG ... ... ...
5.5.7 LDAX. STAX. .... RST ...
5.5.8 EXCHG. DAA. ...I SIM ..e

5.5.9 LIST ... ... ...

5.5.10 DB ... o.0 0 . 0

5.5.11 DW ... ... *.a

5.6 Conclusion ... ...

CHAPTER SIX: CROSS ASSEMBLER BASIC PROGRAM DESCRIPTION
6.1 ... ..
Cross Assembler Users ~ u i d e
6.1.1 Start Up ... ... ...
CHAPTER SEVEN : INTERFACING MAT 385 TO APPLE I1 ...
7.1 ~ntroduction ... ... ...
7.2 printer Interface Card ... ...
7.3 Design Specification ... ...
7.3.1 Interface ~outines ... ...
CHAPTER EIGHT: CONCLUSION ... ... ...
APPENDIX ... ... ... ...
.a.

REFERENCE ... ... ... ... ...

 LIST OF FIGURES

PAGE
A v e r s a t i l e Microprocessor Developent Systen Using
MAT 385 and Apple I1 ... ... ... 8
Typical Microcanputer ... ... ... 9

Configuration of A Typical Microcanputer Developnent

Systan 0.. 0.. ... .a.

Data Flow Graph ... ... ... ...

Structure Chart ... ... ... ...
Cross Assembler Data Flow Diagram ... ...
validate Source Code Data Flow Diagran ... ...
Make Label Table Data Flow Diagram ... ...
Evaluate Object Code Data Flow ~ i a g r a n... ...
Cross Assenbler Structure Chart ... ...
validate Source Code Structure Chart ... ...
Make Label Table Structure Chart ... ...
Evaluate Object Code Structure Chart ... ...
Interconnection of Apple I1 to MAT 385 using Parallel
printer Interface Card . ... ... ...
74/LS192 Hardware Data ... ... ...
 CHAPTER ONE

REVIEW OF MICROPROCESSOR DEVELOEMEHT SYSTEM

A canputer is a machine which can be made t o do anything by giving it
instructions called program. The only language that the canputer
u n d e r s t a n d s is t h e machine language o r low l e v e l language. Machine
language is a progran written i n ffts and 1's.

~ n i t i a l l ywhen canputers were introduced, the low level language was

the only language used t o c m u n i c a t e with the canputer.

with t i m e , the assembly language was introduced. Here, mnanonics a r e

used t o represent groups of zeroes and ones. This made programning a b i t
e a s i e r but not without problans. Since the clmputer does not understand
the assembly language, there was a need for a t r a n s l a t o r (assenbler) t o
t r a n s l a t e assenbly codes t o machine codes.

L a t e r , t h e high l e v e l language was introduced. This made l i f e easy

a s programs a r e w r i t t e n i n e n g l i s h - l i k e form. T r a n s l a t o r s a r e a l s o
required t o t r a n s l a t e the high level language t o assembly language and
then t o machine code.

In most cases, these t r a n s l a t o r s a r e software and resident in t h e

canpu ter manor y .
Keyboards, e d i t o r s and video display u n i t (VDU) were introduced t o
f a c i l i t a t e entering of the assenbly code and high l e v e l language i n t o the
canpu t e r .
 The keyboard is used to enter the instruction, editors prepares the
instructions in a form acceptable to the canputer while the VDU is used to
monitor what is going on in the computer. The keyboard and VDU are
hardware facilities interfaced to the canputer while the editor is a
software resident in the canputer which allows source code to be entered
into a canputer and puts it in a file. The editor also allows addition,
deletion or replacanent of portions of the source code.

As the computer was being put to bigger use, there was the need to
store programns outside the canputer main menory. Manory products like
disk and druns were introduced.

In most cases, when working on a ccmputer, only the twenty-two lines

on screen can be seen at a time, for larger portions of a program to be
seen, there is the need for hardcopy production. These problens were
tackled by the introduction of printers and teletypewriter ('MY).
1

The introduction of microprocessors brought a new dimension to the

canputer world. i
1

The microprocessor is a circuit caponent which can be assenbled in

conjunction with other supporting circuit blocks to build any desired
digital systen('). Like the canputer, the microprocessor needs to be
instructed for it to do a useful job. ~lthoughthe organisation of
cmercial microprocessors differ £ran each other, each has a central
process'ing unit (CPU) which makes then capable of interpreting instruction
codes £ran manory and data processing as specified by the program.

For a microprocessor to be widely accepted, its internal organisation

should be such that it responds to external control ccxrmands as well as
generate control signals for external modules to use.
 Microprocessors can be used to build canputer systan called
microcomputers. A typical microcomputer unit (fig. 1.2) has menory for
storage of data/information, input output port, data bus, address bus and
control bus for cannunication within the microprocessor and the external
world. Thus, for microprocessor to cannunicate or be used for any useful
work, there is need for it to be developed.

Considering that most microprocessor applications aim at producing

systen used for dedicated purpose, e.g. traffic light controller, washing
machine controller and process controller, it ! :Is to be as inexpensive
as possible.

To cut down on cost and make the target systen cheap, as to justify
its production, canpared to other methods of implanentation available, the
microprocessor cannot support developnent aids. Thus the target systan
.
cannot afford such costly junctions as systan so£tware (e.g translators
.
and editors) and peripherals (e.g VDU, TTY) that aid systen developnent.
Aids and facilities need to be providd to enable progran developnent,
testing and debugging of the target systen program. This developnent aid
is normally offered by the MDS.

In many cases, prticularly, when a systan design must be completed

quickly and sufficient money is available to purchase canputer time, the
best route to take is probably to design the systen with the aid of a
large powerful canputer. But for an engineer who looks for practical
hediate solution to systan implenentationvhile maintaining a low design
.
cost, he needs a self-contained developnent systan (3)

.../4
 Although it can be argued that it is possible to develop a
microprocessor application without an MDS, but in engineering, working
without appropriate and adequate tools is unacceptable since it leads to
waste of time and result may never be produced.

The early attmpts at providing these developnent tools under the

collective name of MDS were not £ran microprocessor manufacturers(4) .
Initially, the systems were very basic, a collection of circuit blocks
based around a microprocessor. ALthough these systems w r e crude, they
allowed entry of program and running of progran for test purposes.

The requirenent and denand for better and more powrful developnent
tools have led to the evolution of MDS in different forms, The new
generation of MDS are sophisticated and powerful (e.g. Intel, Tektronix,
Hewlett-Packard etc).
Like any other canputing facility, different makers offer MDS tools
to aid in the developnent of microprocessor application. Fig. 1.3 shows
.
what is generally accepted as MDS (4)

For the developnent of an application program in an MIS, the system

software is used to prepare the program in an executable form. The
program is then tested and debuggers facilitate the testing stage.

Facilities offered by debuggers are:

a). d isplay/mod ify memory and reg ister content
b) enable program execution to be started at a specific mmory
location.
C) allow for single stepand break pointsduring program execution.
 In s i n g l e s t e p debugging, cannand is given such t h a t one i n s t r u c t i o n
is executed a t a time while i n break p o i n t , the program runs and s t o p s f o r
s t a t u s of menory and r e g i s t e r s t o be checked a t s p e c i f i c desired points.

When t h e application has been f u l l y developed, t h e r e is a need f o r

the software t o be permanent i n t h e menory (ROM) of t h e microprocessor
hence t h e need f o r PROM programer. A t times, a f t e r a systan has been
developed, t h e microprocessor may not be r e a d i l y a v a i l a b l e f o r t h e systen
t e s t i n g hence t h e MlS needs t h e i n - c i r c u i t enulator t o allow for the
t e s t i n g of t h e software using a c t u a l t a r g e t hardware under developnent.
The i n - c i r c u i t enulator a l s o allows t h e hardware designer t o construct h i s
hardware while working with t h e a c t u a l design software, f a c i l i t a t i n g
debugging a s hardware developnent progresses (38)

For microprocessor, which is t h e b r a i n of t h e MDS, t o cannunicate

with t h e peripheral t o o l s , t h e r e is a need f o r then t o be linked f o r
information flow between then. ~ n f o r m a t i o nprocessing and access has been
made p o s s i b l e by t h e canputing and c m u n i c a t i o n i n d u s t r i e s .

In the canputer 1.. rld, interfacing denotes the facilities of

hardwired connections and canponents (halrdware) and information including
d a t a and i n s t r u c t i o n s (software) t o enable the canputer t o i n t e r a c t with
t h e world o u t s i d e it.

Interfacing facilities (hardware and software) provide for the

acceptance of raw information a t t h e input, and t h e d e l i v e r y of the output
processed d a t a . This is done using t h e input output devices which may be
on-line o r o f f - l i n e under t h e a c t i v e c o n t r o l of t h e c o n t r o l l e r u n i t of t h e
canputer .
 C o n s i d e r i n g t h a t many input-ou tput devices are i n t e r faced t o the
m i c r o p r o c e s s o r , t h e c o n t r o l l e r d e t e r m i n e s which one should be o n - l i n e a t a
time. This the c o n t r o l . l e r s p r o v i d e nc'lrlrcsr; rlr?c:or.lirrj Zoqic arul a c t as
s y n c h r o n i z e r s s i n c e t h e p r o c e s s o r ' s speed is much tri. . i ~ i y h e rtlian t h a t o f
t h e input-output f a c i l i t i e s .

F o r a m i c r o p r o c e s s o r t o be i n t e r f a c e d t o a p e r i p h e r a l . , t h e y have t o
be c a n p a t i b l e . C a n p a t i b i l i t y was one of t h e s e r i o u s problerns f a c i n g t h e
c a n p u t e r world because of few catununication s t a n d a r d s .

The u n d e s i r a b l e c o s t l y i n c a n p a t i b i l i t y problen h a s been p a r t i a l l y

solved by the introduction of standard interface by international
s t a n d a r d s f o r pa tchcord terminals. These interface standards i nclurl~
CAMAC f o r mainframes, its microco~nputer q u i . v a l e n t t h e I E E E - 488 and
RS232C (7, 37)

I n w e l l designed m i c r o p r o c e s s o r s y s t e n , t h e r e a r e always t r a d e o f f
c o n s i d e r a t i o n s where d e c i s i o n s a r e taken a s t o which p o r t i o n ~ l i ~h-e. ~ l ?
s o f tware and which hardware. In most a p p l i c a t i o n s , s o f t w a r e a c c o u n t s f o r
a b o u t 80% o f t o t a l c o s t s (10)

From t h e above d i s c u s s i o n , i t is T?, v y obvious t h a t t h e incl.usion of

d e v e l o p m e n t s y s t e m i n t h e t a r g e t s y s t e m w h i c h wou1.d r e s u l t i n t h e
p r o d u c t i o n of a v e r y e x p e n s i v e s y s t m is n o t j u s t i f j.abl.e, hence the need
f o r a n MDS. Considering a l s o £ r a n above, t h e f a c i l i t i e s o f f e r d by t h e
MDS, is v e r y e x p e n s i v e and c a n n o t he a f f o r d & i n e v e r y d e s i g n envirornnent.

I n s u c h c a s e s where t h e MDS is n o t r e a d i l y a v a i l a b l e , p r o t o t y p e k i t s
(e.g. I n t e l SKD-80, S i g n n e t i c s 2650, M A T 305 etc) a r c 11.7r-ul in j t.,; pl.ace.
These have the disadvantage that all the MDS aids cannot be provided for
by the latter. This is the case with our university electronic laboratory
where the prototype kit used for developnent does not have most of the
above mentioned developnent aids.

The available microcomputer MAT 385, used to develop 8085

microprocessor based systens, has facility for entering machine codes, in
hexadecimal form, into the menory through a key board. It also has the
four debugging facilities mentioned above. It does not have translator
nor can it be made to have one inside since only machine codes can be
entered through its keyboard. ~t does not display progran execution
status on VDU or print hard copy of object code after debugging, but it
can be made to do so by interfacing it to VDU and TTY. It also has
facility for its interface to a cassette tape for information storage.
Sane input-output subroutines are also available to ease the interfacing
.
of TlY to the microcanputer

his project is aimed at producing a versatile frcm Apple I1 and

MDS
MAT 385 which are available in the laboratory. Apple I1 is a micro-
canputer which has a keyboard, VDU, printer and disk drive peripheral
facilities. It can be programed in high level language (basic, pascal)
assenbly language (6502) and machine language (6502) .
Program developnent on MAT 385 requires a lot of strain since
assgnbly codes have to be hand coded and keyed into the system. Moreover,
after debugging, there is no hard copy nor storage facility provided. It
is hoped that when the MDS is fully implemented, by combining the
facilities on the two microcomputers, users of MAT 385 would not be
bothered with hand coding of the source code nor rewriting the code after
debugging. This gives room to concentration on the problem of the
envisaged system developnent. his means increased efficiency and
throughput which is the key to fast technological advancenent.
.../R
.
 ADORE88 BUS
-A

k
3 t >

Pt lNPUT /
0 MEMORY
0 WTQIlT

8 , no
o D A T A BUS

CONTROL BUS

FIO. 1.2 TYPICAL MICROCOMPUTER CONFIQURATION

 PRINTER
.
IN- CIRCUIT
*

EMULATOR

FLOPPY
01811s

I
I MD3 PROCESSOR
UNIT

CON3OLL
TERMINAL
( VDU 1
READER AND PUNCH

F18 1.3 CONFIOURATION OF TYPICAL MICROPROCESSOR DEVELOPMENT SYSTEM

 - 11 --

CHAPTER 'IWO

DESIGN OF A VERSATILE MDS

Since the facilities in Apple I1 and MAT 385 are to be used in the
production of a versatile MDS, there is a need to look at the
facilities available on both systms to make for the most efficient
use of then for the production of a cheap MDS,

2.2 APPLE 11:

his is a 6502 microprocessor based microcomputer which has a
keyboard, VDU, printer and disk drive peripheral facilities. It has
basic and pascal language cards and thus can be programed in those
two high level langugages. It can also be programmed, though
limited, in 6502 assenbly and machine languages.

For Apple I1 to talk and be talked to by other devices, it has sane

built-in-input output facilities and provision for interconnection of
other devices through the use of peripheral interface boards designed
especially for the Apple 11.

For ease of use, the Apple 11's circuitry has these input-output
locations menory mapped.

2.2.1 Built-In Input Output ~acilities:

a) The Speaker: To allow for various sounds to be made on the
Apple 11, an 8 o h speaker is connected to the internal
electronics of the Apple 11.
b) The c a s s e t t e Interface: A provision is made on the Apple
I 1 for connection of c a s s e t t e so t h a t infomation can be
recorded on c a s s e t t e tape and saved f o r l a t e r use.

c) The Gane Input-Ouput Connector: This allows tk connection

of special input-output devices t o heighten the e f f e c t of
prograns in general and especially, gane prograns.

d) Peripheral Board Input-Output: Seven peripheral connectors

a r e available a t t h e back of Apple 11, for use, t o plug any
of the Apple I1 canpatible peripheral interface board,
Each of the seven s l o t s is allocated a t o t a l of 280 byte
locations in the menory map and a 2k byte "camon areav
which a l l peripheral cards can share.

There is a l s o a special s l o t meant for menory or interface

expansion.

Since each peripheral card has 256 byte of manory, t h i s usually

c o n t a i n s the driving progran for the peripheral card. Thus
t h e s e cards a r e "inteligentt' such t h a t e x t r a program is not
required i n t h e use of these cards.

These peripheral connectors serve a s l i n k t o most systens t h a t

communicate with the Apple 11. ~t is through these s l o t s t h a t
the p r i n t e r is connected using p r i n t e r interface card, the disk
d r i v e using d i s k card. Other canputers can a l s o be linked
through it, using i n t e r f a c e adaptors which can be configured i n
simplex mode, half duplex and f u l l duplex.
Apart £ran these hardware facilities, the Apple I1 has software
faci 1ities which allow for information exchange between Apple
I1 and the peripherals.

These software facilities in the Apple I1 are collectively

called disk operating systen (DOS) . The softwares available
are editor, canpiler and debugging softwares.

Special DOS c m a n d s are used to activate these DOS softwares

as the need arises. The DOS c m a n d s can be put into five
categories.

House-keeping Cmands:
These allow for disk initialization, program entry into the
systm from disk, deletion or addition of program and
program running. It also ensures safety of disk stored
program and prevents unauthorised progran access,

Access CaTmand:
These allow program access to the various peripheral
devices.

Seauential Text File Cunnand:

This allows for information to be stored and retrieved
appropriately to and £ran the sequential file.

Randan Access File Cmand:

These, just as above, allow access to randan access file.

Machine Language File Cmand:

These allow for running of machine language (6502) program
in Apple 11.
.
./I4
2.3 MAT 385
This is a microcomputer which is used to develop 8085 based systems.
It canprises an Intel 8085 CPU an industry standard 8 bit
microprocessor, ROM, RAM and input-output ports. It has facility for
8085 based object codes to be entered into it in hexadecimal form
through a keyboard. It has all the debugging facilities discussed in
chapter one. It has hardware facilities and some useful software
routines, which can be called fran a program, for the interfacing of
VDU, 'MY and cassette.

The MAT 385 has some input-output facilities which allow it to

cannunicate with the outside world. The input-output lines are TTL
(transistor transistor logic) canpatible and allow for the use of the
microcanputer for control applications using software routines in the
microcanputer manory.
These input-output facilities are ports and serial lines which have
the disadvantage of not being directly canpatible with any standard
interface bus. Thus interfacing of MAT 385 to the outside world
using any of the available standard buses requires extra effort in
terms of design, data and control line matching to achieve a good
result.

The input-output facilities include 8155 ports, 8755 ports, RST 6.5,
. RST 7.5, serial interface provided specially for interfacing of
.
teletypewriter (TTY), cassette recorder and video display unit (VDU)
2.3.1 8155, 8755 And RST:
-
8155: This is an input-output manory card that is interfaced
to the 8085 microprocessor of the MAT 385 microcanputer. It
has 256 byte RAM memory available for storage of user's
progran , two input-output ports and an input-output
port/t her.
These facilities are available for use during the testing of
appl ication program, through socket J5. The port addresses
are 29 , 24 and 2B. Available also is a timer, VrX and W.

The ports can be programned to act as input or output ports

using the c m a n d register. It is also used to specify the
mode of operation of ports as well as timer specification and
programning.
8755: This is an ultra violet (UV) erasable and programnable
ROM (EPROM). It contains 2048 (2k), 8-bit words (byte), of
mmory and sixteen (16) input-output lines (2 ports).

Each of its ports can be programned to act as input or output

using their data direction register.

These ports are available to the user on the panel at 54 with

port addresses 00 and 01.

RST 6.Sf 7.5: These are vectored interrupts which allow the
programmer to interrupt the processor when it needs to
comnunicate with the microprocessor, using its control 'ITL
high input.
 Whenever any of the vector interrupt pins are high, the
microprocessor finishes the last instruction it is executing,
saves the content of program counter (PC) and branches to the
call address of the vectored interrupt. It executes the
subroutines stored in the address and returns to continue
whatsoever it was doing.

These interrupt pins need to be used for control of systens

that need imnediate attention of the processor. It also
eliminates wasting of the processor's time pol1,ing for an
interrupting systen using ordinary input-output lines.

These interrupt lines are available on 54 at pins 22 and 23.

2.4 MIX DESIGN

To achieve the aim of the project, writing application programs in
assanbly language, debugging and getting hardcopy of the object code,
.
the faci1ities available on Apple II and MAT 385 have to be used

since MAT 385 cannot house an assembler, the assembler program

written in high level language (basic) would be on disk for use in
Apple II. The assanbler would have a text editor to allow for entry
into Apple 11, 8085 assembly codes. Since Apple I1 is a 6502 based
microcomputer, the assembler is a cross assembler. The other
facilities to be offered by the cross assenbler for the translation
of source code (assembly code) into machine code are:

a) Syntax Analyser : ;1F

his is a subroutine which analyses each code keyed in, to make
sure it conforms to acceptable 8085 assanbly code.
b) The Label Table Routine:
his routine goes through the source code and collects all the
labels and puts than in a label table.

c) Cknerate Cbject Code:

This routine translates the corrected source code into machine
code and stores it in a file.

The assembler is also responsible for producing a hard copy

containing both the source code, object code and manory location.

On production of the object code on the Apple 11, it would be a

tedious task, especially if progran is large, to key it in on MAT
385. So, there is a need for a loader prograan to down load the
object code to MAT 385. his entails interfacing of Apple I1 to MAT
385.

From a review of interface facilities available on the Apple I1 and

MAT 385 a good interface mode can be selected to make the two
microcanputers talk and listen to each other.

Although, the MAT 385 does not have any standard input-output for
linking to the outside world, the input-output facilities it has can
be configured such that the Apple I1 does not realise this.

Ideally, Apple I1 peripheral interface adapter is the most suited for

this job since it is a standard adaptor for linking Apple to other
computers. In the absence of the adaptor, any of the input-output ,

facilities on the Apple I1 can be used for the interface.

For the communication between the Apple I1 and MAT 385 to be
possible, there is a need for handshake routines in both the Apple 11
and MAT 385. The transfer of data £ran Apple I1 to MAT 385 is to be
controlled by these subroutines.

After debugging of the application program using the debugging

facilities on MAT 385, the hard copy is to be produced. This is to
be done using the TTY to be interfaced to MAT 385 or in the
alternative the object code is sent back to the Apple I1 and printed
on the printer.

This also involves software routine on MAT 385. The MAT 385 has
subroutines on its monitor which can be called in a progran to do the
house keeping job for characters to be sent to WY. This progran in
MAT 385 would be used to call on the monitor subroutines to send the
application program to 'ITY for the production of hard copy.

Considering that the major part of the work would involve software
developnent chapter three is devoted to "Overview of Software
Developnent Techniques". In chapter four, the cross assanbler design
is discussed while the cross assanbler implenentation is treated in
chapter five. Chapter six is devoted to cross assembler basic
program description and users guide while chapter seven treats the
interface design and implenentation.

he write-up is concluded in chapter 8 where a detail of achieve-

ments, setbacks/handicaps and suggestion for further work are
analysed .
 - 19 -
CHAPTER THREE

3.0 OVERVIE37 OF SOFIWARE DEVELOPMENT TECHNIQUES

INTRODUCTION
A good software design methodology should aim at producing a
consistent program structure independent of whosoever is
applying it. The key to easily modifiable software are clarity
and simplicity in both design and implementation. Clarity and
simplicity are enhanced by modularity, module independence and
topdown design implementation.

The software developnent aids are flow chart and topdown design
.
(data flow design, data structure design and functional design)

FLClWcHART
The flow chart is one of the comnon methods of expressing the
logic and structure of a progran. ~t is a schematic visual
description of the logic of a program.

The fundanental function of a flow chart as of any other progran

design tool, is to show, in exact unambigous detail, the
sequence in which actions are to be carried out and the
conditions under which alternatives are to be taken.
 I t has the disadvantage that it has no s t a r t i n g point. The
whole progran flows in a monolithic manner with GOTO branches.
For a l a r g e progran, it can be d i f f i c u l t t o tackle the problm
s e c t i o n by section or i n a group, t o assign specific tasks t o
menbers of a group. For hunans, who, generally, think
sequentially, flow chart is normally canplex.

3.3 TOP-DOWN DESIGN

This is a design strategy that breaks large problens into l e s s
complex problems and then decomposes each of t h e s e smaller
problens into even smaller problens u n t i l t h e original problm
has been expressed a s sane canbination of many m a l l solvable
problens.

A t f i r s t , it is always best t o pretend that the program is being

done on a machine capable of solving t h e problem in only a
handful of carmands. A complex problen should not be regarded
immediately in terms of canputer instructions but rather in
terms of e n t i t i e s natural t o the problen i t s e l f abstracted in
.
some s u i t a b l e s e n s e (11) ~t is then subjected t o f u r t h e r
decanposition. This process of refinement continues u n t i l a
level is reached t h a t can be understood by a canputer.

In t h e f i r s t level of decomposition, a handful of comnands a r e

written for the canplete progran. Each level cannand yields the
subsystem in the systm.

.../21
In the second level, each of the first level instruction/cmand
is refined to get less powerful instructions. Thus each
sub-systen is broken down into program that canprise it.

The next functional decanposition should lead to modules

canprising each program.

Modular programs can be described as programs which implement a

single independent function, perform a single logical task, have
a single entry and exit point and are separately testable.

Following the above decanpositions, a set of nesting modules

result, that can be connected in a hierarchy to form large
prograns. ~ierarchicalmodularity enhance mpDown developnent.
Thus a major aspect of program design is the use of TopDown
functional decanposition of a problen, to achieve hierarchical
modularity.
Generally in so£tware design where topdown design approach is
assuned, all design work must be canpleted before coding begins,
functional decomposition is applied in a way that leads to
hierarchical and modular structure for the systan. his leads
to the modules being functionally cohesive.
3.3.1 Functional Decanposition
his is simply the divide and conquer technique applied t o
programing(1) . m a n p o s i t i o n can be with respect t o time
o r d e r , d a t a flow, l o g i c a l grouping, a c c e s s t o common
resource, control flow and sane other c r i t e r i a .
Functional decanposition can lead t o a good hierarchical
progran s t r u c t u r e i f c a r e f u l l y applied.

I t has t h e disadvantage that a given problm cannot be

d i v i d e d i n t o sections, which can be independently solved
by programers. More-over, i f it is not used carefully,
it can lead t o logical cohesion and occassionally towards
d e f i n i n g s n a l l e r and s n a l l e r modules that a r e not
independent but have strong coupling t o each other.

3.3.2 Data Structure Design

In data s t r u c t u r e design, the program structure is
designed fran the d a t a structure. Thus the relationship
between d i f f e r e n t l e v e l s of each resulting hierarchy tends
t o b e a I r i s composed o f r r r e l a t i o n s h i p . I t has the
advantage t h a t it is repeatable, teachable and r e l i a b l e .
I t usually r e s u l t s in a program s t r u c t u r e t h a t f a i t h f u l l y
models the problm. ~ h u si t s a t i s f i e s the principle of
consistency t o a large degree since it can be viewed a s
correct or incorrect.

I t h a s t h e d i s a d v a n t a g e t h a t t h e r e is s t i l l no c l e a r
methodology f o r l a r g e systen and deriving the c o r r e c t d a t a
s t r u c t u r e can be d i f f i c u l t .
.../23
 3.3.3 Data Flow Desisn
Data flow design is functional deccanposi t i o n with r e s p e c t
t o d a t a flow. Each b l o c k o f t h e s t r u c t u r e c h a r t is
obtained by successive a p p l i c a t i o n of the engineering
d e f i n i t i o n of a black box t h a t transforms an input d a t a
s t r e a n i n t o an o u t p u t d a t a stream.

I t has t h e advantages t h a t it produces a very good program

structure. I t c a n b e used t o p r o d u c e a h i e r a r c h i c a l
p r o g r m s t r u c t u r e with a l l of its i n t r i n s i c advantages.
The tendency is s t r o n g l y towards modules with s e q u e n t i a l
cohesion a t t h e s y s t m l e v e l , although anything can happen
w i t h i n t h e c e n t r a l transform.

3.4 SO- DESIGN METHOD SELECTION

The major motivation f o r looking a t progran design methodologies
is t h e d e s i r e t o reduce t h e c o s t of producing and maintaining
software. I

Compared t o t h e c o s t o f hardware, t h e c o s t o f s o f t w a r e is
c o n t i n u i n g t o e s c a l a t e (I2) .
The l a t t e s t s t a t e o f a r t i n
s o f t w a r e design is by t h e p r a c t i c a l a p p l i c a t i o n of s c i e n t i f i c
knowledge i n t h e d e s i g n and c o n s t r u c t i o n of canputer p r o g r m s 1
I

and t h e a s s o c i a t e d d o c m e n t a t i o n t o develop, o p e r a t e and

maintain then ( 12) .
 In software design, the choice of a particular design
methodology f o r design of a problan depends on application and
t h e method the p r o g r m e r is used to.

Based on the above, t h e data flow design approach was chosen and
it is used for a l l software design i n t h i s project.

3.5 DATA FLCkJ DESIGN

his is functional decmposition with respect t o data flow.

3.5.1 Design Strategy

The i n i t i a l s t e p i n using t h e data flow design method is
t o draw a data flow graph ( f i g . 3.1) .
This graph is a
model of the problan enviroment t h a t is transformed into
the progran s t r u c t u r e . The bubbles i n data flow graph is
l a b e l l e d "becanes". That is, data input X "becanes d a t a
output Y and data Y becanes a etc.

A look is then taken a t the flow graph t o identify t h e

most a b s t r a c t i n p u t and o u t p u t . T h i s is c a l l e d t h e
c e n t r a l transform (CT) . The inputs and outputs then "hang
down" from the CT. A t each level, a module in one of the
input or output data streams can be factored into a "get"
module, a "transformw module and a "put" module (Fig.
3.2) . The GET modules a r e called "afferent modules" and
t h e g l ~ ~ modules
~ t l a r e called "efferent modules". The
transform module is the "central transform".
3.5.2 Structured Chart
heir main departure £ran the abstraction stage is that
they analyse and present the action control and
sequencing. They do it in a topdown treed structure
manner. The key transformation is taken up f i r s t and
broken up into subtransformation which is broken up in a
t r e e manner. s his is achieved by replacing bubbles in
d a t a flow diagram by boxes anotated with m e of
transformat ion.

C a l l arrows go £ran these boxes t o lower levels ( t h i s

shows hierarchy) while bubble-end data directed arrows
show direction of particular data flow anotated with the
nane of the data.

The optimization of data flow diagran t o structured chart

is done by identifying the central transform, afferent and
efferent transforms, (see Fig. 3.1 and 3.2) .
3.5.3 Progran Design Language
After the structured chart then follows the description of
t h e coding program. This c o n s i s t s of f a i r l y n a t u r a l
language description of translation in each of the boxes.
Normally, t h e program d e s i g n language t o b e used is
defined. Program d e s i g n l a n g u a g e (PDL) which is a n
intennnediary between natural language and procedural
language a r e u s u a l l y used. Heavy r e l i a n c e on loop is
encouraged a t t h i s s t a g e with t h e use of " ~ reduced
" or
eliminated.

The progrinn design language coding should have maximun

cohesion between modules and minimal coupling so a s t o
a t t a i n s e l f containness.
 FIO. 3.1 DATA FLOW ORAPH

EXEC

J 1.
OET z Z-cL PUT L

FlO 3 . 2 STRUCTURE CHART

 - 28 -
CHAPTER FOUR

4.0 CRaSS ASSEMBLER DESIGN

4.1 INTRODUCTION
A t a t i m e , t h e canputer programner had a t h i s d i s p o s a l a b a s i c
machine t h a t i n t e r p r e t e d through hardware c e r t a i n fundamental
i n s t r u c t i o n s . H e programs t h e canputer by writing a series of
o n e s and zeroes (machine language), p l a c e them i n t o t h e menory
of t h e machine and p r e s s a buttan where upon t h e canputer would
s t a r t t o i n t e r p r e t e them a s i n s t r u c t i o n s . Programners found it
d i f f i c u l t t o w r i t e o r read these machine language program. In
t h e i r q u e s t f o r more convenient language, they began t o u s e
mnemonics (symbol) f o r each machine i n s t r u c t ion, which they
would subsequently t r a n s l a t e i n t o machine code. Such mnenonics
are c a l l e d assenbly language. r?rograms c a l l e d a s s e n b l e r s were
w r i t t e n t o a u t a n a t e t h e t r a n s l a t i o n of assenbly language i n t o
machine language.

4.2 ASSEMBLER SURVEY

Assenblers a r e programs used t o t r a n s l a t e t h e assenbly language
source code into object o r machine code executable by a
microprocessor. There a r e . t h r e e main types of assenblers.

Resident Assenbler :
This is an assenbler w r i t t e n t o run on t h e same machine t h a t
w i l l execute t h e source code. Example, an 8085 assenbler
t h a t is t o run i n a canputer whose microprocessor is an 8085
microprocessor chip, is a r e s i d e n t assenbler.
./29 ..
b) Meta Assenbler :
his is an assenbler which supports many d i f f e r e n t micro-
processors. The programer merely s p e c i f i e s a t the s t a r t of
t h e source which microprocessor assanbly language w i l l be
used and t h e meta-assenbler t r a n s l a t e s the source code t o
t h e c o r r e c t machine d e .

c) Cross Assenbler :
They a r e assgnblers which r e s i d e i n machine which can not
e x e c u t e the o b j e c t code generated by t h e assenbler. They
a r e normally w r i t t e n i n high l e v e l language e.g. f o r t r a n ,
b a s i c , pascal, which make then machine independent.

Assgnblers can be f u r t h e r c l a s s i f i e d based on t h e i r mode of

t r a n s l a t i o n of t h e source code.

d) me Pass Assenbler :
Here t h e source code is processed only once and during t h i s
p r o c e s s i n g , any l a b e l encountered is given an address and
stored i n a table. Therefore, when t h e l a b e l is encountered
a g a i n , t h e assanbler may look backward t o find t h e address
of t h e label. I f t h e l a b e l h a s n o t been d e f i n e d f o r
example, a junp i n s t r u c t i o n t h a t s k i p s forward, an e r r o r
message is generated.

I t has the disadvantage t h a t only backward reference may be

used. I t has t h e advantage of being f a s t s i n c e only one
pass is used f o r t r a n s l a t i o n .
.../30
 e) Two Pass Assgnbler:
Here, u n l i k e t h e o n e p a s s a s s e m b l e r , i n its f i r s t p a s s
through the source code, it assigns address t o a l l l a b e l s
and s t o r e s then i n a table. 'Ihen it makes a second pass t o
t r a n s l a t e t h e source code i n t o machine code. This is t h e
m o s t popular s i n c e l a b e l can be referenced before it is
used. But it has t h e disadvantage of being slower than a
one pass assenbler.

f) T h i s is a t y p e o f two p a s s assembler t h a t a l l o w s t h e
programer t o write the source code i n macro-sequence of
i n s t r u c t i o n s t h a t t h e programner g i v e s a name. Whenever the
progrmner wishes t o d u p l i c a t e t h e sequence of i n s t r u c t i o n s ,
t h e macro m e is inserted i n t o the source code.

The macro-technique is useful i n cases where subroutine a r e

.
not p r a c t i c a l

4.3 ASSEMBLY LANGUAGE OVERVIEM

I n a t y p i c a l microcanputer assgnbly language (source progran) ,
t h e r e a r e t h r e e (3) types of statenents:

a) Symbolic microcanputer i n s t r u c t ions which a r e t r a n s l a t e d

i n t o machine language i n s t r u c t i o n s (object code).

b) Directive s t a t e n e n t s t o t h e assenbler regarding the

t r a n s l a t i o n of t h e symbolic microcanputer instructions.
.../31
c) Comment statenents which a r e reproduced in program l i s t i n g
for docmentation purposes but have no e f f e c t on the
translation of the program.

Symbolic instruction statements and assembler d i r e c t i v e

statements typically have four f i e l d s , howver, one or more of
these f i e l d s may be blank in a particular statement.

The f i r s t f i e l d is called t h e label f i e l d . I t is used t o give

symbolic names t o data and program segments. The second f i e l d
is the operation or opcode f i e l d . I t specifies the operation or
function t o be performed by the instruction or .assembler
d i r e c t i v e . The third f i e l d is known a s the operand f i e l d and it
indicates the argunent t o the operation or function. The fourth
f i e l d is the carnent f i e l d which has no e f f e c t on the program
translation but is reproduced in the program l i s t i n g for
docmentation purpose.

A blank t y p i c a l l y separates one f i e l d £ran another. A label is

u s u a l l y optional on a l l instructions and sane assembler
d i r e c t i v e s , the operation must always be specified, sane
o p e r a t i o n s r e q u i r e no operands and some do ( f o r t h o s e t h a t
require operands, it must be specified) and caments a r e usually
optional on a l l instructions and assenbler directives.
4.4 FEATURES OF AN ASSEMBLER WHIm SUPPORT COOD PROGRAM DESIGN
Every assanbler has a specific assanbler directive to which it
responds and a group of symbolic canputer instructions that it
translates.

In most microcomputer assanbly language, each source program

line is one canplete statenent and c o l m dependence. Colunn
dependence can be renoved by terminating all labels with
limiters e.g. #,@. The field aligned assanbly source code makes
for easier reading of source code and even for easy translation
but then, does not offer the programmer flexibility. For
programer flexibility, a1igrment should not be canpulsory but
adviceable.

a he importance of colunn independent source input to an

assanbler is two fold:

The programer can format the source code based on his own
style and on the appropriate length of fields for particular
progran.

The assanbler will not reject a particular statenent just

because a particular field was inadvertently started in the
wrong column. Correcting errors of this type can be
I
expensive, time consuning and unnecessary.
4.4.1 Symbol Manipulation
The ability to define and manipulate meaningful symbols is
a very useful attribute of a cross assgnbler.

An assembly language program usually contains types of

symbols:

a) Those predefined symbols which are part of the

vocabulary of the language, such as canputer
instructions, opcodes, assanbler directives,
microprocessor register nanes etc.

b) Symbols which are assigned by the programer to data

value and program sqments.

The provision of meaningful predefined symbols and the

ability to define meaningful symbols are two features of
an assenbler which make good design possible.

Assemblers vary regarding the restriction placed on

programer defined symbols. Usually such symbols must
begin with a certain kind of character and they must be
less than a particular nunber of characters in length
(usually should have the same length as the label).

The first character of a symbol must be an alphabet or one

of the special characters @ (at sign), ? (question mark)
etc.
There a r e about four ways in which a symbol can be defined
i n assenbly language.

a) By placing a unique symbol i n t h e l a b e l f i e l d of an

assenbler directive statement which equates the
symbol with an absolute nunerical value. The value
may be a constant d a t a value o r an address of d a t a i n
memory o r a n a d d r e s s of a n i n s t r u c t i o n i n memory
(Exmple DELAY EQU 1255).

b) By placing a unique symbol i n the l a b e l f i e l d of an

i n s t r u c t i o n (Exanple START MOV A B) .
C) By placing a symbol in the label field of an
assenbler directive statement which assigns an
a b s o l u t e value t o be s t a r t e d i n one or more memory
l o c a t i o n which equates t h e symbol with t h e address of
t h e f i r s t of these locations. his is t h e method f o r
s e t t i n g up c o n s t a n t i n ROM. Data c o n s t a n t t h a t
r e q u i r e s more mmory t o be expressed than is
a l l o c a t e d i n an imnediate address i n s t r u c t i o n can be
l o c a t e d elsewhere i n ROM. These constants a r e then
a c c e s s e d by t h e program i n t h e same way a s a r e
v a r i a b l e s ; t h a t is, t h e i n s t r u c t i o n c o n t a i n s t h e
a d d r e s s of t h e d a t a r a t h e r t h a n t h e d a t a v a l u e s
(example DELAY DB 5 , 8 , 2 7 : DELAY DW 5 , 8 ) .
4.4.2 Data Constant S p e c i f i c a t i o n
The ability of the assembler to allow for data
s p e c i f i c a t i o n i n t h e progran i n t h e most meaningful manner
is of g r e a t importance.

Numbers which have t h e most meaning t o t h e p r o g r a m e r

should be used. Thus numbers can be s p e c i f i e d a s decimal
o r hexadecimal and it is assembler's job t o convert t h e s e
numbers i n t o a p p r o p r i a t e base, s i n c e it works f a s t e r than
hunan beings.

4.4.3 Other A t t r i b u t e s
The symbol table should have symbols i n t h e order i n which
they appear i n t h e progran and not i n a l p h a b e t i c a l order.

The assembler should have a good e r r o r d i a g n o s t i c s which

f l a g s any source progran s t a t e n e n t which v i o l a t e s assembly
l a n g u a g e syntax. The absence of "END1' d i r e c t i v e should
n o t c a u s e any alarm.

E r r o r messages should be c l e a r , e x p l i c i t s t a t a n e n t s which

i n d i c a t e t h e s p e c i f i c program and f i e l d s t a t a n e n t
c o n t a i n i n g t h e e r r o r . The p r o g r a m e r should be allowed t o
do c o r r e c t i o n and program start to re-assemble
imnediately. .
 The assenbler should also be able to produce object code
progran which can be loaded for execution into any
suitable area of manory. All of the addresses in the
program are assembled relative to sane base address. A
relocating loader program mod ifies the object program
address for it to run at the desired location.

4.5 ASSENBLER DIRECTIVES

Assembler directive or pseudoinstructions as they are sanetimes
called are instructions used in the source code which are not
translated into object code. hey are special instructions to
the assenbler to perform sane specific functions. These
instruction are placed in the opcode field.

4.5.1 Origin (ORG)

This is specified as ORG in an instruction statenent. It
is used by the source progran programner to direct the
assenbler on the menory address where to start putting the
object code. A starting address of one is assumed if no
ORG statenent is given in the source code (exanple ORG
$124 sets the counter at 124 hexadecimal number).

4.5.2 m a t e (EQU)
This is used to assign the data value or address in the
operand field to the label field. This instruction is
valuable because it allows the programer to write the
source code in symbolic form and not be concerned with the
nuneric value needed. (Example PORTA EQU @01).

The programner is required to assign a value to a label

before use.
..
./37
4.5.3 Define Byte (DB)
The DB instruction is used to set a menory location to a
specific data value. The DB instruction is usually used
to create data tables or to preset a flag value used in a
progran. As the name implies, the DB instruction is used
for creating an 8-bit value for example: ORG $50: set
table address. able DB $45, @34, $04; preset table
value. This means a table of three values, @34, $45 and
$04 had to be created starting £ran address $50.

4.5.4 Define Word (DW)

DW defines menory locations to specific values. As the
name implies, the menory alloted is in word length which
are usually 16-bits wide. When assigning a 16-bit value
to menory locations, two 8 bit menory locations must be
used. The Intel Style is normally used. The least
significant byte of the 16-bit value is stored in the
first memory location while the most significant byte of
the 16 bit value is stored in the next menory location.
Exmple :
ORG $200
DATA CW @255r $240, $ABC
This generates a machine code thus
200 00
201 FF
202 00
etc
 4.5.5 Title, Erd, List
~ittleallows the user to name the program example TITLE
ADDITION ROUTINE" .
The END instruction signals to the assembler that the
source code is cmplete. Any line after the end statanent
is ignored by the assembler.

The list instruction is a direct cannand to the assembler

and will cause the assembler to print the entire source
code program.

4.6 CROSS ASSEMBLER DESIGN

Introduction
The process of software developnent starts with the
difficult yet extrenely important task of capturing the
requirements. There is a need for a canplete, consistent,
validated, unambiguous machine independent specification
of software requirenents before design. The design must
then be expressed in an unambiquous an3 clear notation
£ran which programs can easily be constructed.

Requirement
The cross assembler under design is an assembler written
in high level language which is required to transform 8085
source code to object code for use in MAT 385
microcanputer.
 T h e MAT 385 microcanplter does n o t have f a c i l i t y t o accept
assenbly codes. Only o b j e c t code i n hexadecimal form can
b e keyed in. his creates problen t o t h e programer who
it t o a form
a f t e r w r i t i n g h i s source code, hand-codes
acceptable t o MAT 385 before keying it i n t o t h e MAT 385
manory .
The c r o s s assenbler is t o be designed such t h a t it runs i n
a microcanputer which has the facility to run the
assenbler as w e l l as allow the keying i n of t h e source
code by t h e programer. The p r o g r a m e r instead of
t r a n s l a t i n g source code, keys i n t h e source code and goes
t o d o another job while t h e assembler assembles t h e
program.

The c r o s s assenbler is t o have t h e assembler f e a t u r e s and

d i r e c t i v e s mentioned above. I t is t o be s t o r e d i n
d i s k e t t e and c a l l e d i n t o Apple I I whenever source code
t r a n s l a t i o n is required.

4.6.3 Data Flow Diagram and S t r u c t u r e Chart

These a r e a s shown i n f i g u r e s 4.1 t o 4.23.
4 . 6 . 4 C r o s s Assgnbler Program ~ e s i g nLanguage
4.641 MAIN PROGRAM
Do
INPUT SOURCE CODE
VALIDATE SOURCE CODE
ASSEMBLE SOURCE CODE
W T Ol3JEEI' CODE
OUTPUT

4.6411 INPUT SOURCE CODE

INPUT SOURCE CODE

END

VALIDATE SOURCE CODE

GET FIELD
VALIDATE FIELD
END

GEX' FIELD

GET SOURCE CODE

POINT TO FIELD
COLLECT FIELD
END
4 . 6 4 1 2 2 VALIDATE FIELD (LABEL, OPCODE, OPERAND AND
CWEEPT)
DO
If ";"then
DO
CASE 1
END
ELSE
If Label then
DO
CASE 2
ELSE
VALIDATE OPCODE
VALIDATE OPERAND
END
END

CASE 1: T h i s is a ccxrment
DO
RETURN
END

CASE 2:
DO
VALIDATE LABEL
END
 ASSEMBLE SOURCE CODE

GET VALID SOURCE CDDE

GET LABEL TABLE
EVALUATE MACHINE CODE
STORE O B J W CODE
PRODUCE HARD COPY
END

GET LABEL TABLE

GET LABEL
MAKE LABEL TABLE
END

MAKE LABEL TABLE (PASS 1)

INITIALISE COUNTER
I F LABEL THEN
DO
CASE 4
ELSE
POINT TO OPCODE TYPE
INCREMENT COUNTER APPROPRIATELY
END

END
CASE 4 LABEL TABLE
DO
STORE COUNTER VALUE, LABEL
POINT TO OPCODE TYPE
INCREMENT COUNTER APPROPRIATELY
END

EVALUATE MACHINE OODE

DO
INITIALISE COUNTER
GET OPCODE
EVALUATE MACHINE OODE
GET OPERAND
EVALUATE MACHINE OODE
END

STORE OBJECTCODE
DO
STORE COUNTER, MACHINE CODE
STORE COUNTER, MACHINE CODE, SOURCECODE
END

PRODUCE HARD COPY

DO
GET OBJECT O D E
PRINT
END
4.65 Coding
The coding is done i n basic using both Apple I1 and IBM PC
basic. Although t h e coding was done and debugged in these
PCs, the c r o s s assanbler can a l s o be run using any IBM
canpatible canputer (review of IBM canpat i b l e
canpu ters) (I4) . The Apple I I b a s i c coding is attached
(see appendix) .
Some p o r t i o n s of t h e b a s i c coding a s a t t a c h e d a t t h e
appendix may require extra e f f o r t i n reading, due t o t h e
printing format. These portions can be e a s i l y read on a
VDU screen d i r e c t £ran Apple I1 d i s k e t t e .
 'C
R
O
~(? M M b K R O B J E C T CODE

30URCE VALD CODE OBJECT

CODE *CODE

CODE CODE

FI@.4.1. C R 0 8 8 A 9 8 E M B L E R D A T A F L O W DIAORAM
 CODE \ CODE 1

- FLD

ERROR
ANALY 8 E R

I ERROR LINE

ERROR
CORRECT ION

F I Q . 4.11 VALIDATE 8OURCE CODE DATA FLOW OlAQRAY

VAt.0-
COD ADDMSS

F l 0 . 4. 12 M A K E L A B E L DATA F L O W DlAQRAM

INCREW-NT
ADDRESS

ADDRESS
I

FIQ. 4.13 EVALUATE OBJECT CODE DATA FLOW D I A B R A Y

 .
ASSEMBLER
EXECUllV E

OET LABEL EVALUATE

TABLE MACNINE
CODE
-
fly%%,*
i r

n
.%
OET VALID MAKE
SOURCE LABEL
WOE TABLE

VAL1DATE
FIELD FIELD

t
30URCE CODE

CROIS ASIEMBLER 8TRUCTURC CHART

 I VALIDATE SOURCE
CODE E X E C U T I V E I

PUT
VALIDATE
I SOURCE

I-- ERROR

t
SE PARAT t
SOURCE
FIELDS
CODE

Fie. 4 . P I V A L I D A T E BOURCE CODE STRUCTURE CHART

 LABEL 1
-
EXECUTIVE

1-1 LABEL EVALUATE

ADORES S
\
MAKE
LABEL
TABLE '

LABEL NUMBER
FIELD LABEL OF BYTES

I I V L - COD

OET VALID
SOURCEC00

F10. 4 . 2 2 MAKE LABEL TABLE STRUCTURE CHART

 EVALUAT E
MACHINE CODE
EXECUTIVE

OET CONVERT
FIELD F E U 10 FILE
T YPE OBJECT
&
\

gl
COD

VALD- COD
1-1 FIELD TYPE

EVALUATE OBJECT CODE STRUC11JRE CHART

 CHAPTER FIVE

5.0 CROSS ASSmLER IMPLEMENTATION

5.1 OVERVIEM
The c r o s s assgnbler program g e t s the source code £ran user,
s t o r e s it in a f i l e . I t then reads through the f i l e l i n e by
l i n e and validates each l i n e of code t o make sure i t is a valid
8085 code. On getting t o any invalid l i n e , it p r i n t s it on the
screen and pranpts user t o correct the l i n e by displaying the
possible source of e r r o r . After correction, the new 1ine input
b y u s e r is used t o r e p l a c e t h e old l i n e and t h e v a l i d a t i o n
routine continues. After validation, the label table is made.
This, the cross assenbler does by going through each l i n e of
s o u r c e code. On identifying a label in a l i n e , it s t o r e s the
l a b e l i n a label t a b l e with its matching address, t o serve a s
reference during decoding or object code generation.

A t the code generation stage, the a s s d l e r passes through the

i n p u t code f i l e , g e t s each l i n e of code c o n v e r t s i t t o its
equivalent machine code and p r i n t s out the l i n e nunber, the
a d d r e s s , the machine code and the source code . his is a l s o
stored i n a f i l e which can be recalled l a t e r .
 From t h e above, it can be seen t h a t t h e c r o s s assenbler is made
o f f i v e b a s i c modules which a r e a l l i n t e r f a c e d by t h e main
program. These modules include:
1. The input module
2. The val ida t ion module
3. The make l a b e l module
4. Object code generation module
5. The output module

5.2 THE INPUT MODULE

T h i s module accepts source code £ran t h e u s e r , s t o r e s it i n an
input f i l e . The f i r s t idea was f o r t h e progran t o accept source
c o d e , decode it, p r i n t r e s u l t and pranpt t h e user t o input t h e
next source code. But t h i s idea was dropped considering the
f a c t t h a t t h e c r o s s assenbler program takes sanetime t o assenble
t h e source code, it would lead t o waste of programer time.
More-over, it would not allow f o r forward l a b e l referencing t h u s
subjecting t h e programer t o only backward referencing.

The p r e s e n t idea is f o r t h e c r o s s assenbler t o pranpt user t o

k e y i n t h e source code which is stored i n a randan access f i l e .
The u s e r is pranpted again t o confirm t h e source code. I f t h e
u s e r is n o t s a t i s f i e d w i t h t h e keyed i n s o u r c e code, h e is
prompted t o key i n the modified source code. This process is
continued u n t i l t h e user has keyed i n a s a t i s f a c t o r y source
code.
The i n p u t module c o n t i n u e s t o a c c e p t i n s t r u c t i o n s f r ~ nu s e r
u n t i l an "ENDl1 s t a t a n e n t is encountered. s his module a p a r t £ran
a c c e p t i n g t h e s o u r c e c o d e a l s o t a k e s n o t e o f t h e number o f
i n s t r u c t i o n s keyed i n by user and r e t u r n s t o t h e main progran.

5.2.1 Basic F i l e Systan

T h e r e a r e two types of basic f i l e s , t h e s e q u e n t i a l and
randan a c c e s s f i l e .

I n s e q u e n t i a l f i l e , information can be s t o r e d o r accessed

s e q u e n t i a l l y . Thus, f o r a l a r g e f i l e , t o g e t information
towards t h e e x t r a n e , a l o t of time is wasted i n going
t h r o u g h unwanted d a t a b e f o r e t h e data l o o k e d f o r is
r e t r i e v e d o r w r i t t e n . I t is simple and e a s y t o use.

The randan a c c e s s f i l e is canplex b u t h a s t h e f l e x i b i l i t y

t h a t you can s t o r e o r r e t r i e v e information f r m any p a r t
o f t h e f i l e by indexing t o t h e d a t a d i r e c t l y .

I n t h i s a p p l i c a t i o n , t h e r e is need f o r t h i s f l e x i b i l i t y
and f a s t a c c e s s s i n c e t h e u s e r may feed i n an unacceptable
s o u r c e code which would need t o be changed. More-over ,
t h e r e may be need d u r i n g t h e program r u n t o c h a n g e
unacceptable code which was mistakenly keyed i n .
5.3 THE SOURCE CODE VALIDATION MOWLE
This module reads through t h e input f i l e , using t h e input source
code marker a s an indication of nunber of i n s t r u c t i o n s , takes
t h e source code l i n e by l i n e and checks i f each source code
conforms t o t h e 8085 standard assanbly code. On d e t e c t i o n of
a n y a b n o r m a l i t y , i t p r i n t s t h e code, a d v i s e s u s e r on t h e
possible cause of the error and pranpts him to make
modification.

A s it checks each l i n e of code, it p r i n t s it a s v a l i d on t h e

screen for t h e user t o see. The programner has t o wait for t h i s
module t o execute before leaving t h e progran t o run on its own,
s i n c e any source code l i n e which does not meet t h e required
syntax would cause t h e progran t o s t o p running while waiting f o r
t h e programner t o make t h e necessary changes.

The module has many subroutines which makes the validation of

t h e source code possible. The opcodes a r e grouped in such a way
t h a t a l l t h e opcodes t h a t have t h e m e s t r u c t u r e have t h e same
v a l i d a t i o n routines.

The convention here, unlike i n most assanblers, is t h a t space is

t h e o n l y f i e l d l i m i t e r . When you c o n s i d e r a t y p i c a l 8085
assenbly code which most assenblers use, it uses ":'I a s l a b e l
limiter, "," f o r opcode operand separator while ";ll is used
imnediately before a cannent.
The b a s i c f i l e managanent of Apple 11 regards " :"and " ," as the
end of an input t o f i l e and disregards everything beyond these
1i m i ters. Because of this constraint, all limiters in
conventional assanbler were disregarded and t h e systan d e s i g n d
t o a c c e p t a space a s a l i m i t e r . Apart f r a n space, a s l i m i t e r ,
a t t h e end of each l i n e of code, a space is a l s ~required. A
seni-colon before a cannent s t a t e n e n t is a l s o acceptable but it
is optional.

5.3.1 Mode of e r a t i o n
I t starts by c a l l i n g the subroutine which g e t s t h e
appropriate opcode. ~t g e t s -the f i r s t word of t h e source
c o d e , checks i n t h e opcode a r r a y t o see i f it is a v a l i d
opcode. I f it is not a va1i.J opcode, i t assumes it is a
label. I t then goes t o the ].ribel. v a l i d a t ion subroutine t o
v a l i d a t e the label. I f it is not a v a l i d l a b e l , i.e.
s t a r t s with a number o r has more than s i x c h a r a c t e r s , an
e r r o r message is generated, source code p r i n t d and user
prmpted t o make t h e necessary changes.

On t h e l a b e l being v a l i d , j k poes ahearl ko c o l l e c t t h e

opcode, canpare it with t h e q c d e arriiy t o check i f it is
a v a l i d opcode, i f it is an invalid opcode, e r r o r meqsage
is generated, source c d e printed atld user prcmptt.:d t o
make t h e necessary changes.
I f t h e opcode is v a l i d , t h e o p c d e nmber is used a s an
i n d e x t o g o t o t h e operand v a l i d a t i o n r o u t i n e . On
v a l i d a t i o n of operand, it p r i n t s t h e source code a s being
valid.

For t h e operand v a l i d a t i o n , t h e opcodes a r e subdivided

i n t o twelve d i f f e r e n t groups.

5.3.1.1 -
MOV
If t h e opcode is a "MW", t h e program is indexed
to the MOV subroutine. Here, the first
character h c d i a t e 1 . y a f t e r r.IW is c o l l e c t e d and
compared with t h e r e g i s t e r array. I f it is a
v a l i d register, i.t goes ahead to c o l l e c t t h e
second character which is a l s o a v a l i d r e g j .,p ter.

On any of these two c h a r a c t e r s being an invalid

r e g i s t e r , an e r r o r message (" inva 1 id r e g i s t e r " )
is generated and user pronrpted t o make necessary
changes.

5.3.1.2 MVI
---
Here, t h e next character is picked and validated
using t h e r e g i s t e r array. The data i t d i f ~ a t o ris
t h e n c o l l e c t e d , t h i s can be "@" o r "jP. When
t h e d a t a indicator is @ then i t m e m s the number
following imndiate1.y is a decimal. nmber while
"$" i n d i c a t e s a hexadecimal nmber .
 The nunber is collected, the indicator tested.
If the indicator is "$", the nmber is converted
t o decimal using t h e hexadecimal t o decimal
converter subroutine. Otherwise, the nunber is
checked t o ensure it is not greater than two
hundred and fifty-f ive (255) (lbyte) . If nunber
is g r e a t e r than 1 byte, an e r r o r message ("no.
g ' r e a t e r than 1 byte") is d i s p l a y e d and u s e r
pranpted t o make changes, otherwise, the l i n e is
printed a s an acceptable valid source code.

5.3.1.3 ADI, ACI, SUI, SBI, ANI, XRI, CPI, I N , OUT

Here, a f t e r val.idation of opcode, the data
i n d i c a t o r is collected and data validated a s
above (5.3.1.2).

The next character is collected, compared with

r e g i s t e r pair array t o check i f it is a valid
register pair, if not, an error message
( " ~ e g i s t e rpair Expected") is generated and user
pranpted t o make changes.

On g e t t i n g a v a l i d r e g i s t e r p a i r , t h e d a t a /
operand indicator is collected. In t h i s case,
t h e r e a r e three a l t e r n a t i v e indicators. Apart
from "@" and "S" discussed above, the indicator
can be "L", indicating a label. In the case of
a label, the label is validated.
 The nunber collected, if hexadecimal, is
converted t o decimal and t e s t e d t o make sure it
is not g r e a t e r than 65535 ( 2 b y t e s ) . I f ntpnber
is g r e a t e r than 65535, an e r r o r message
(Pddress > 2 bytes) is generated and user
prompted t o make changes. Otherwise, t h e code
is displayed a s being valid.

JPO, JPE, JP, --JM, CALL, CNZ, CZ, CNC. CC, CPO,

The address indicator is c o l l e c t e d , t h i s can be

ll@ll, 11$11 or l l ~ l l . he c o l l e c t e d a d d r e s s is
t r e a t e d a s 5.3.1.4 above.

5.3.1.6 R N Z , RZ, RC, RPO, RPE, RP, RM, XCHG, DAA, R E ,

RRC, RAL, RAR, CMA, OC, S K , PCHL, XTHL, SFHL,
E I , D I , HLT, NO;.----. i. .. I, SIM, END, LIS'l?.
They do not have operand and a s such a r e j u s t
displayed a s v a l i d source code.

LDAX, STAX, I N X , DCX, PUSH, POP, DAD

The next character is c o l l e c t e d and ccmpared
with t h e r e g i s t e r p a i r a r r a y t o confirm i f it is
a valid register pair. If the character is not
found i n t h e a r r a y , an e r r o r message ( " ~ e g i s t e r
P a i r Expected") is displayed and user pranpted
t o modify source code, otherwise t h e i n s t r u c t i o n
is displayed a s being valid.
5.3.1.8 ADD, A D C t SUB, SBB, ANAt XRAt O W t mt INRt DCR
The next character is collected and canpared
with the register array, if not found in the
array, an error message ("Invalid Register") is
d isplayed, instruction displayed and user
pranpted to make the necessary changes.

5.3.1.9 RST
-
The next character is collected and checked. If
it is a nunber between zero and seven (0 - 7),
the source code is displayed as being valid and
the validation continues. Otherwise, an error
message (%ST Nunber > 7") is displayed, source
code displayed and user pranpted to make the
necessary correction.

5.3.1.10 DB
-
Here, space separates the different bytes while
the last byte is immediately followed by a
mi-colon to show end of data.

The data indicator is picked for each and the

data validated as in 5.3.1.2. (X1 encountering

semi-colon (I1;") it knows it is the end of the

line, it validates the lasL data and the
validation routine continues.
 As in above, spaces act as limiters to the
different words while seni-colon indicates the
last word. The data indicator is picked for
each case and data validated as in 5.3.1.4. It
continues to collect and validate data until it
gets to the seni-colon limiter which indicates
end of line.

5.3.1.12 Title
The first character is collected and validated
to make sure it is not a nmber. ~f it is a
number, an error message (~nvalid~itle) is
displayed and user prompted to give a valid
title. On the first character being valid, the
title is collected and it's length validated.
IF, it is longer than twenty characters, an
error message is generated otherwise it is
displayed as being valid.

5.4 SUBROUTINE MAKE LABEL TABLE

Just like the above routine, it goes through the source progran
line by line. On getting each source code, it gets the first
word limited by space checks if it is an opcode, if it is not,
it assumes it is a label and stores it in a label table. it
also stores the appropriate menory location where the label was
picked. On being an opcode, the menory location is increnented
appropriately. The opcodes are subdivided into three groups:
 The One Byte Group:
When such opcodes are encountered the menory location
counter is incranented by one and the progran goes on to
collect the next source code.

The nJo Byte Group:

In this case, the memory location counter is increnented
by two.

The Three Byte Group:

This causes the location counter to incranent by three.

5.4.1 Non-Executable Codes

These are the codes which help programer in the
specification of a progran but are not part of the cdes
to be executed by the microprocessor (i.e. they do not
.
have object code equivalent)

ORG: When this is encountered, the manory location is

initiated with the number directly following it.

EQU: When this is encountered, the label before it is

stored in a label table while the number after it is
stored in the memory location table as its reference
nunber .
LIST, END, TITLE: The subroutine does not do anything on
encountering any of these but it goes to get the next
line.
.../63
5.5 SUBROUTINE GENERATE OBJECTCODE
This subroutine goes through the source code line by line and
determines their type and generates the appropriate machine
code.

An object code generation array is available. On picking any

opcode, depending on its group, the appropriate subroutine is
called which prepares it in a mode in which it is stored in the
objectcode generation array. ~t is then matched with the array
canponent to get its position index. This index is used to pick
the appropriate objectcode equivalent. The index nunber , the
menory location, the object code and the source code are then
stored in the object code file as well as displayed on the
Screen.

For two byte and three-byte instructions, the necessary

subroutines are then called to do the appropriate house keeping
to generate the second and third bytes.

The opcodes are grouped to facilitate this opcode generation.

5.5.1 -
MOV
On encountering this opcode, a subroutine is called which
collects the two registers hediately after it. These
two registers are concatenated with MOV example "MWABtt.
This new code is searched in the object code generation
array and its position is used to pick the appropriate
object code. The object code is stored in the appropriate
memory location. The menory location is then increnented
by one ready for another data.
5.5.2 -
MVI
This is a two-byte instruction. On the assenbler
detecting this opcode, it generates the appropriate object
code by using the WI subroutine. The subroutine picks
the character imediately after the opcode, which is a
register, concatenates it to MI1 and using the object code
generation array generates the appropriate object code,
stores it in the appropriate menory location and
increments menory location by one.

It then goes back to the source code and gets the data.
If the data information is a label, it goes to label table
to get the data equivalent. I£ it is in decimal (data),
it is converted to hexadecimal using decimal to
hexadecimal convertion subroutine. The data is then put
in the menory location and the manory location counter
increnented by one.

5.5.3 ADI, ACI, SUI, SBI, ANI, XRI, ORI, CPI, IN, OUT
These are two-byte instructions. Whenever any of these
opcodes are encountered, a subroutine call is made. his
subroutine uses these opcode to index into the objectcode
array thus picking the object code equivalent. The object
code is stored in the appropriate mmory location while
the menory location counter is increnented by one. The
second byte (data) is then collected and treated as in
5.5.2.
..
./65
5.5.4 -
MI
This is a three-byte instruction which has a register pair
before the address/data.

The recognition of this instruction leads to a call of

subroutine which collects the register pair and
concatenates it to LXI. The index number fran the object
code array is then used to collect the object code. The
object code is then stored in the appropriate menory and
the menory qounter increnented by one.

The address part is then collected. If it is a label, the

label table is used to collect the appropriate address.
If it is a decimal nmber, it is converted to hexadecimal.
The lower byte is collected and put in the menory location
as the second byte of the instruction. The menory counter
is increnented. The upper byte is then collected and put
in the menory location as the third byte and the menory
location increnented.
5.5.5 LDA, STA? LHLD, SHLD? JMP, JNZ, JZr JNC, JCI JPO, JPEl JP.?
JM, CALL, CNZl CZI CNCl CCr CPO, CPE, CPr CM
Once any of these opcodes are recognised, a subroutine
call is made which uses their position in the object code
array to collect the object code and put in appropriate
menory location and memory location increnented by one.

The address part is treated as for 5.5.4 above since they

are three-byte instructions.
.../66
5.5.6 -
ORG
On recognition of this instruction, a subroutine call is
made which uses the address part in decimal to initialise
the menory counter as the starting address for the opcode
storage.

5.507 LDAX, STAX, INX, DCX, PUSH, POP, DAD, ADD, ACC, SUE, SBB,
ANA, XRA, ORA, CMP, INR, DCR, RST:
These opcodes cause a call to subroutine which picks the
next character and concatenates to the opcode. This is
used to get the index nmber in the objectcode array.
This index nunber is then used to pick the object code
which is stored in the appropriate menory location and the
menory location counter increnented by one.

5.5.8 XCHG, DAA, RLC, RRC, RAL, RAR, CMA, CMC, SlC, PCHL, XTHL,
SPHL, EI, DI, HLT, NOP, RIM, SIM:
These opcodes are one byte instructions which cause a call
to subroutine which indexes into the object code array to
collect the object code, stores it in the appropriate
menory location and increnents the counter by one.

5.5.9 -
LIST
This causes a subroutine call that causes a hard copy of
the assenbled progran to be printed.
 5.5.10 -
DB
T h i s instruction causes a c a l l t o subroutine t h a t picks
o n e b y t e d a t a l i m i t e d by space and s t o r e s than s e r i a l l y
u n t i l it encounters a seni-colon. After 1-11 data
s t o r a g e , t h e memory l o c a t i o n is increnented by one.

5.5.11 -
DW
On encountering t h i s i n s t r u c t i o n , a subroutine c a l l is
made which p i c k s t h e two-byte d a t a limited by space and
s t o r e s them one-byte a t a time using t h e I n t e l s t y l e .
This data storage continues until a seni-colon is
encountered.

5.6 CONCLUSION
The c r o s s a s s e n b l e r h a s been f u l l y implanented and sane p r i n t e d
r e s u l t s £ran it a r e a t t a c h e d f o r reference.

Program test 1 shows a s i t u a t i o n i n which a l l source codes a r e

v a l i d and t h e a s s e n b l e r a s s a n b l e s source code without c a l l i n g
a t t e n t i o n of t h e p r o g r a m e r .

T e s t 2 shows a t y p i c a l c a s e where a programmer k e y s i n a n

u n a c c e p t a b l e opcode and was pranpted t o make c o r r e c t i o n b e f o r e
t h e s o u r c e code was assenbled.
In test 3, an undefined label was used. me assanbler had t o
prompt user t h a t the label does not point t o any address. The
program was then assenbled a f t e r correction.

I n t e s t c a s e 4 , MVI was used without d e f i n i n g a r e g i s t e r .

Programer was notified of t h i s e r r o r and a f t e r correction the
program was assanbled.

The l a s t attached results a r e typical examples of p r a c t i c a l

case, (pp 81 - 82). One is a loader progrm for down loading of
o b j e c t c o d e s from Apple 11 t o MAT 385. The o t h e r is a
programned input output routine written for an 8085 system ( i t
was g o t from r e f e r e n c e 26) . The p r i n t o u t f o r t h e s e two
p r o g r m e s a r e typical examples of the hard copy expected from
the cross assenbler.
RUN
1-DA @256 I S VALID
 LDR @256

RE'T
F'DF' I3
ADD P
21 21 C7 RST I(:
22 22 27 DAA
1)11 YOU WANT HARDCCIPY ?

'TYPE YDlJR PROGRAM T I TT'LE

-
?PllflG. 'TEST 1
F:. rz%~1 c-3 TEEST 1
INDEX MEM
NO. L-OC
1 (:,001
2 [I (11(32
-7
.._, o
(:I ( 1 : ~
4 (1)(1)(:I 4
e
J (:)(:I (:I 5 DH @34 8r88;
6 r:) ( j(1) 6 I)R (234 8638;
7 (1) (1) 7 MOV A D
l3 (11I:) (1)8 M V I D $478
9 O (:I i:, 7
1(:I (1) (:) (1)0
1. 1 c)(1) (:)H
12 (1)0 (1)c
1 :3 (:)(:I I:( 1)
14 0 0 0 E:
15 (3.1 c:)F I-DA 82%
I6 (:)o1(3
17 (:)r)1 1
18 0(): 13 RET
17 .i (:I 13
1 POP E
2 (1) w:] I 4 n m E(
a 1. (:)(:I 15 RST O
22 (:)(I1b 27 AA
I)
DQ YOU WANT TO TRRNSFER SOURCE CODE TO MAT 385 ?
KlJN
DE M E ; I S VALID
IL-LEGAL CIF'CODE
MCID A D
I N P U T SOURCECODE
?MOV A D

OKG trFF I S VALID

MOV A D I S VALID

RSD E Q U ?<HE3 I S VAL-ID

TEST CALL t477 IS VALID

I N LRSD I S VRLID

JMP L T E S T I S VALID

END I S VRLID
1 255 EE DB W E ;
,.'>o i 296 7A MOV A D
3 257 CD TEST C A L L fk77
4 23R 77
C
.J 299 r:) (1
6 2 (:) DP I N LASD
7 2h 1 88
£3 262 C3 JMP L T E S T
9 263 01
10 264 01
DO YOU WnNT HARDCOPY ?
?
TYPE YOUR PROGRAM T I T T L E
?PROG. T E S T 2
F'RCJC3- TEST ZZ
INDEX MEM OBJECT SOURCE
NO. LOC CODE CODE
1 OOFF EE DE bEE;
2 0 1 (30 70 MOV A D
.3 (3 10 1 IZD T E S T C A L L $47'7
4 0102 77
5 (1) 1. (:, (1)(11
6 0 104. RE I N LASD
7 0 1. 5 (38
 o o 1.3 0 r: J MF' L... 'rE::'IT
'3 I 1: '7 r:) 1
10 0108 01
Dn You WfiNT TO TRANSFER SOURCE CODE TO MRT 3 R 5 ?
?IV
?SYNTAX ERROR
IRUN
......................
***8085 CROSSASSENBLEFI,*.*.*.*
*,.* DEVEL..OPEI) EY*+f++-#+-#*+
***ONUCHUKWU R.M.D*****
.*+t.w I N PART I AL F U L L F ILMENT*+
+K.KOF M. ENG+*.**
.H * . * I N MAY 1'?87***
-w.* H*~*~**~********.**~*******
TO ANSWER ANY QUESTIDN PRESS
N FOR NO RND Y FOR YES
flND PRESS KETLJHN
S NF'LJT SOURCECODE
7LDA ZtEE
DO YOU WANT A CHANGE ?
3

S NF'LIT SCIURCECODE
'?RST h
DO YOU WANT A CHANGE ?
'7

S NF'LJT SOURCECODE
?MUV B fi
DO YOU WANT A CHANGE 7
?
S NPLlT SUUKCXXXJDE:
?CRL..L ASD
DO YULJ WANT A CHANEE ?
-?y
INPUT SCIURCECUDE
" X f i L I... L-ASD
DD YOU WRN'T A CHANGE 7
S NPUT SOURCECODE
7ENLl
Dl:] YOU WONT A CHANGE ?

RST 6 I S VALID

MOV B fi I S VALID
CAI... I.. I..I\TiD I S VISI..T I>

I--DA PcEE IS VALID

KST h I S VAL.. JD

MOV P A IS V A L I I )

LDA ttEE

'TYF'E YCIUt? F'flUGfWM TI'T'1'C.E

'7F:' R [);1. .r[;: r3.r 1;
F::. 1 7 f.;:") q-?S
II X
m
. '

ME:M
-',-__.
-rE-15's
CI E J E:1:: T
-7"

NC) . L.. (313 CUIIE

1. i:! (::! (11 :0
,, .
7 c~i:)r:)? F'F
.,. .

I::!!:)4::):x
,..*
._.. (1)
4 I ) F.' 7 Fi3 'I" 6,
C
rJ (:)0(:,5 47 MCIV B n
h f:.K)i-!b 131) CAI 1.. $ 4 '7 7
7 .7
0(::)(:.I 7 '7
RLJN
*.#.*.Ea;*..Ea..E+t.*..**s..n.n.*.r...n*
.n..*.N.f3 C:, 5 [I I:? 0 S !.j !3 :1, MB 1.. I..17 .*.% .M.
.%.it.#.I)EL'EL.(:JFy'E:I] EY.tc.++.tr..W-tc+!?1.,#.
~..K+(:]I\.II.JC:l..+I.Jt:::bJl.JR . M u0++%.*(.wK
*.E.U. I N PC.SRT'I: AL. F'I.JL.LF' I L-tIEN'T*.s.
*.WX-(:]F' H. EN(~.M..~.E+$
I N PlnY 19R7-W-W-R
.X..E.#.
n. n +w.,n.a .#. *.*.+.w.& #..)(.#..e.n,n.ws..#.a;.~
*.
"SC:) f7N!Wf:F? fWlY L!lJE:Sl'I ON PRESS
N FUFI 1\10 C\ND Y f'~IF'3 Y E S
flN1:) F::lRt"t';S F?E.'T'LJRpJ
II\IF'IJT SOU1:~'rC~ECClIIIif
71JRG & A
IIKI Y01.1 LrJRNT A CHnNGt= 7
3
I Nf"l.I'T SCII.IF7CECI~JI)E
';'I]W e477 c!23;
D13 YC:)CJ WANT A Ct-IRNGE ?

INFWT SO1JRI:E:COl:)E
'? I:! EI @ 3. 2 H(7' ;
%9

Dl::) YCI1.J IJRNl' A C H R N E E ?

''7

T NPLIT SO1JFICEC::OIIE~
'?MOV fl rl
DO Y1:)U WANT fl CF.IANGE 7
7
1IllFYI'T S 131JR S: E:C [.'I1.)F:
7P1VI (3254.
DKI YC:l(.J WONT A Ct-IC-INGE ?
'7
I N N J T SClI.JRCEZC:OI)EE
'?OD1 C5h
IIC:) YCllJ LrJANT A C::HRNGE '7
'7
I NPI.JT' SC:ILJF~C:~~.CC)I:)E:
'?RE')'
DC) YC)LJ WANT' A CFMNGE ?
'7
T NF'UT' SOLIRCECCJDE
' p[ IR
DU YClU WANT A C:tiANGE ?
'Y.)
I hIF::'I.JT' SOUFICEC:UI:)EZ
MOV A D I S VALID
M V I D (3254 I S V A L I D
AD1 (2% IS V A L - I D

FIE'T I S VALID

RS'T' 5 I S VAL... II1

nnn IS VALID
 ADI @5h

1Xl YOl.1 WANT' TW TRANSFER SOURCE CODE TCI MAT 985 ?

'7 N
 SOURCE
COLE
I N I T MV I A 8/.0(:)

OUT 8401 PREPARE COUNTER TO COIJNT UF'

WAIT I N $401

JZ L W A I T W A I T FOR STROBE

MOV M n s r n w ~ A T A
I N X H I N C R MEM
IJMF' I-.WFIIT

DO YOI..] WANT' T'CI TRANSFER SOLJRCE [:ODE TO MQT' 385 ?

MAT 385 INTERFACE SUBROUTINE

 ME11
I.. C3 C:
0 0 i:, 1
(3(:)02
:z
(1)(1)c,
.4.
i:)
(::) (1)(;:) 5

(1)ii)(1) 6)
ii)c)o '7
(1)(1)(1)E)
i:)(::I(1) c?
(1)(1)(1)A
(I i:)(::I R
0i:)0c:
(1)(::) (): D
(1)(1)(3E
0 ij 1::) F:'
0 (1) 1 (1)
i:)(:)I 1
(I(:) 12
(1) 1 73
(3(1)14
(:)O 15
0 ( :! 1. 6
(:)(::I 17

(1)0 1$3
(1) 0 19
(.)O 1A
00 1H
0(::' 1 c
(1) 1T.)
DCI Y(3U WANT T'CI
7N
 CHAPTER SIX

6.0 CROSS ASSEMBLER BASIC PROGRAM DESCRIPTION

,-
.-
The cross assembler program is mainly string manipulation. The
design is tailored to the string manipulation capability of the basic
program. The basic language, though not a structured language is
versatile for jobs requiring string manipulation. The scope of basic
application also varies £ran one microcomputer to another.

The progran was started by storing all the data required for the
program in different arrays as specified in the remark statements.
This array storage goes £ran line 10 - 350.

The main program is about twenty lines, 550 - 600. The main prclgram
involves mainly calls to major subroutines that do the actual job.
These subroutines are :
a1 Input source code
b) Validate source code
c1 Make label table
d1 Generate object code
e) Make hard copy

The input source code is a mall subroutine with very few lines (2500
- 2505) .
The validate source code is the core of the progran a d has many
subroutines which it calls to enable it to do its house keeping job.
It is this subroutine which detects any programmer error ard calls
for correction. Any error which goes undetected at this point,
propagates and later causes a break in progran.

The main program of this subroutine goes f r m 6000 - 6420 while the
subroutine it calls spans 1000 - 3940 and 6500 - 6540. What each
subroutine does has been discussed in the previous chapter.

The make label table routine, which occupies lines 7000 - 751.0, is
not a very big routine though it makes use of s m e of the validate
source code routines.

The subroutine prepares the label table ready for use by the object
code generation subroutine.

The generate object code routine translates the assanbly codes using
the valid source code produced by validate source code routine and
the label table produced by the make label table routine.

Its main program which spans f r m 8000 - 8270 though short, call on
many subroutines which aid it in performance of its task. These
subroutines span 8275 - 9920. It also shares sane subroutines with
the validates source code subroutine.
The make h a r d copy r o u t i n e which can o n l y b e a c t i v a t e d on u s e r
request occupies l i n e s 9930 - 9991. I t p r i n t s t h e output in standard
form having four colunns, index nmber, menory l o c a t i o n , o b j e c t code
and source code.

6.1. CROSS ASSEMBLER USERS- GUIDE

The c r o s s assenbler is used t o assemble 8085 assembly d e t h a t
is w r i t t e n i n its acceptable format. Due t o t h e b a s i c f i l e
c o n s t r a i n t , sane d i f f e r e n c e s e x i s t i n t h e i n s t r u c t i o n t h a t t h i s
assembler assembles canpared t o t h a t which looks like
conventional assenbly language syntax.

Assenbly languages used i n many t e x t s g e n e r a l l y use colon (" :")

t o show end of l a b e l , comma ( " , I 1 ) t o s e p a r a t e o p e r a n d s and
seni-colon (";") t o show end of an i n s t r u c t i o n .

~ n s t r u c t i o n saccepted by t h i s assenbler have t o conform t o t h e

c r o s s assenbler syntax, otherwise, e r r o r message would b e
g e n e r a t e d . The nunber of e r r o r s which can be corrected by t h e
programner a t a given assenbler run is limited by t h e menory
space a v a i l a b l e t o t h e program a t run time.

Making c o r r e c t i o n s l e a d s t o many subroutine c a l l s . Subroutine

c a l l s r e q u i r e a l o t of menory spaces t o s t o r e r e t u r n address s o
t h e more t h e c o r r e c t i o n s made t h e more t h e menory space being
t i e d down and when t h e r e a r e no memory spaces f o r s t o r a g e of
r e t u r n address, t h e r e is a systen e r r o r and t h e program s t o p s
running.
Unlike the well known assanbly syntax, the only limiter
recognised by t h i s assanbler is space except f o r DB and tW where
spaces a r e used between d a t a and sani-colon 1 9 - c d t o i n d i c a t e t h e
end of d a t a .his makes it easy f o r p r o g r a m e r s who d o n ' t need
t o think of limiters between f i e l d s b u t only press "space bar"
a f t e r keying i n every f i e l d .

Once an i n s t r u c t i o n is fetched, t h e executable p a r t is c o l l e c t e d

and processed while t h e rest of information on t h e l i n e a r e
regarded a s carment.

Data can e i t h e r be decimal o r hexadecimal. Decimal d a t a r e q u i r e

"@" before it while a hexadecimal d a t a need "$" before t h e d a t a .

For an address, it can be a nunber which can be specified a s

above o r a l a b e l which must have "L" before it. The program
below a c t s a s an example:

ORG $FF ~ n i t i a l i s ememory l o c a t i o n

DB @ l o $ED @11;Put d a t a i n approprriate manory locations.
DW SFF @65535; Put d a t a i n appropriate memory locations.
START MOV A B Put content B i n A
STAX D E s t o r e A i n address pointed t o by register pair DE
CPI @A Check i f d a t a i n A equals 10
JZ START I f r e s u l t of test is zero, go t o s t a r t .
CALL j@F I f r e s u l t not zero, c a l l subroutine $FF.
END End of progran.
6.1.1 S t a r t Up
The c a n p l t e r is s t a r t e d by switching on the systen. I t is
then booted f o r b a s i c mode of operation. To allow f o r
s o u r c e code c o r r e c t i o n , a s much a s p o s s i b l e menory space
need be f r e e .

The c r o s s assembler program is loaded i n t o t h e working

memory f r a n t h e d i s k . once t h e program is i n mallory, it
can be l i s t e d and run using the "RUN" carmand.

Once t h e program s t a r t s t o "RUN",

the user should wait f o r
t h e pranpt cannand "input source code" which would be
displayed on t h e screen. Another pranpt canes on a f t e r
t h e p r o g r a m e r has keyed i n a l i n e of source code. This
prompt is t o allow user t o repeat t h e l i n e i f he had any
mistake i n t h e o r i g i n a l l i n e . The p r m p t message is "Do
you w a n t a change?". I f t h e u s e r wants a change h e
presses t h e "Y" key and return/enter. I f only e n t e r o r
any o t h e r key is pressed the program goes on and is ready
t o accept the next l i n e of code.

This input d i s p l a y is a c t u a l l y very f a s t and t h e r a t e a t

which it p r m p t s for next input depends on t h e a b i l i t y of
t h e user t o key i n source code a t a f a s t r a t e . A user who
d o e s n o t need t o wait and have a look a t what is keyed i n
need p r e s s enter/return button two times a f t e r each l i n e
of source code input. In t h i s case, t h e program would run
s o f a s t t h a t user has t o work f a s t t o cope with its speed.
The program c o n t i n u e s t o p r a n p t u s e r t o input s o u r c e code
u n t i l t h e u s e r i n p u t s "END". The progran sees "ENDtt a s
t h e l a s t i n s t r u c t i o n t o be e n t e r e d by u s e r f o r any given
progran.

After accepting the source codes, the validation

s u b r o u t i n e starts. The u s e r h a s nothing t o do a t t h i s
s t a g e b u t w a i t s f o r h i s source codes t o be v a l i d a t e d .
Each l i n e of s o u r c e code is d i s p l a y e d as it is v a l i d a t e d .
For exanple, "MOV A B IS VALID1'. On g e t t i n g t o an i n v a l i d
s o u r c e code, t h e progran d i s p l a y s s o u r c e of e r r o r and
s o u r c e code and p r a n p t s user t o i n p u t c o r r e c t v e r s i o n o f
the line. Once t h i s is done, t h e progran s t a r t s a f r e s h t o
v a l i d a t e the s o u r c e code. I t c o n t i n u e s i n t h i s way u n t i l
a l l t h e s o u r c e codes a r e v a l i d a t e d .

A s n o t e d above, t h e r e is a limit t o t h e number of source

code l i n e s t h a t can be c o r r e c t e d i n a given progran. his
is why a u s e r is given a second chance t o look a t t h e
s o u r c e code h e h a s keyed i n .

A f t e r source code v a l i d a t i o n , t h e progran c o n t i n u e s t o run

and as it runs, it d i s p l a y s t h e assenbled code i n f o u r
c o l u n n s , index n m b e r , manory l o c a t i o n , o b j e c t code and
s o u r c e code.
When a l l t h e source code have been assmbled, then t h e
u s e r is prunpted t o indicate whether he needs t h e p r i n t
o u t o r n o t . I f a p r i n t out is required, the user keys i n
any key and return/enter o r only return, otherwise "N" is
keyed in t o indicate t h a t a p r i n t out is not necessary.

I f a p r i n t o u t is required, t h i s is done. T e s t cases

which were printed s t r a i g h t £ran screen (see chapter 5)
a r e attached t o f u r t h e r elaborate the above discussions.
 CHAPTER SEVEN

7.0 INTERFACING MAT 385 X

' U APPLE 11

7.1 INTRODUCTION
For the object code produced f r m the c r o s s assanbler t o be
loaded into the MAT 385, there is a need t o interface MAT 385 t o
Apple 11. A s i n d i c a t e d i n t h e d e s i g n i n c h a p t e r 2, this
i n v o l v e s the connection of MAT 385 and Apple 11 and control of
the data transfer by programns i n both Apple I1 and MAT 385.

Ideally, Apple peripheral interface adapter would have served

f o r t h i s purpose, since it is a standard adapter for linking
Apple I I t o other canputers. This would allow the Apple I1 t o
t a l k to, a s m l l a s l i s t e n t o MAT 385 and vice versa.

Due to the unavailability of this adaptor, the printer

p e r i p h e r a l card which can only serve a s an output £ran Apple I1
had t o be chosen a s a p a r a l l e l output card t o down load t h e
object code £ran Apple 11 t o MAT 385.

7.2 PRINTER INTERFACE CARD

The p r i n t e r interface card, a canpact board, for p a r a l l e l data
transmission provides a canplete e l e c t r o n i c link between the
p r i n t e r and Apple I1 mother board. The card can a l s o serve a s a
general purpose, 8-bit p a r a l l e l output p o r t , t o d r i v e other
peripheral devices (32) .
To use the printer interface card as output port, the handshake
signals strobe and acknowledge (ACK) need to be specified and
configured in the junper block. For this purpose, the
configuration used is the one already configured in the printer
in use.

For data transfer, the data to be transmitted is stored in

location K O 8 0 + $NO (N is slot nmnber). This appears on printer
.
board data lines (DPo - DP7) The data remains there until the
next "STORE" instruction to that location is executed.

his data transfer can also be done in basic using POKE (-16256
+ N16), DATA instruction. Where N is the slot nunber of the
printer card and DATA is the data to be transmitted.

Each time a byte is sent to the printer card, a strobe signal is

generated on the STR signal line. This signal takes the status
configured on the junper block.

From the hardware description, whenever data is stored in

location KO80 + NO or its basic equivalent, the strobe signal
line becanes active and renains in this state until the next
clock cycle. The acknowledge signal line when active is used to
select the printer PROM.
DESIGN SPECIFICATION
Since the strobe signal line indicates data ready, it is
monitored by a routine in MAT 385 to know when the data is
ready. Once this line becomes active, a subroutine which
collects the 8-bit data becanes active and collects the data.
This routine when it finishes its input activity is supposed to
make the ACK line active. This active FLlK line would then cause
selection of printer card PROM and printer software energised.

In this case, the interface software is quite distinct £ran the

printer software alld as such the AiCK signal is unnecessary as
there is no way it can be monitored by interface software.

Due to this inability to know when MAT 385 has finished its data
acquisition, data transfer can be time controlled, by
implementing a delay routine, in Apple I1 after each data
transfer.

7.3.1 Interface Routines

Apple I1
DO
DISPLAY START OF DATA TRANSFER
DO UNTIL END OF DATA
GET DATA
TRANSFER DATA
DELAY
DISPLAY END OF TRANSFER
END
END
MAT 385
DOFOREVER
WAIT FOR STROBE
RESET STROBE
GET DATA
STORE DATA
END

Since the interface software in Apple I 1 is in high level

langugage (basic), there would be no need of a delay
routine because, before it would finish getting data £ran
file and output, the interface routine, in MAT 385 which
is in machine language must have finished data collection
and storage.

Since the strobe signal lasts for only one clock cycle, it
is latched by a menory device with clear facility.

The interconnection is such that the strobe line is linked

to the data input and clock. Once Apple I 1 canputer is
ready with data by sending the strobe signal, it clocks
the memory device and a one is latched into the menory.
When this one is sensed by MAT 385, it sends a signal to
the menory clear to clear menory and be ready for next
data available signal. The MAT 385 interface software
then goes ahead to collect data, store in appropriate
memory location and continue monitoring the menory for
availability of data.
..
./94
Due t o unavailability of a latch with c l e a r f a c i l i t y , an
up-down decade counter which was available was then used
f o r the latching process.

The l o g i c symbol, connection diagram p i n o u t and mode

selection t a b l e is a s shown i n Fig. 7.2.

Using the mode selection table a s reference point, the

systen is i n i t i a l i s e d by MAT 385 sending a high signal t o
MR, counter pin 14. his r e s e t s t h e c o u n t e r . A low
s i g n a l is s e n t t o MR pin 1 4 and a high signal t o PL, pin
11 and CPO, pin 4 , t h i s makes the counter ready t o count
up when CPU, pin 5 is raised £ran low t o high. CPU, pin 5
is connected t o t h e strobe signal l i n e .

Thus when Apple 11 canputer sends data, t h i s strobe signal

goes £ran high t o low and high causing the counter t o
count one. The MAT 385 on sensing t h i s strobe signal, by
polling b i t 0 , Qo , pin 3, c l e a r s the counter, prepares it
for a count-up once there is another strobe, and goes
ahead t o collect data and s t o r e in t h e memory location.

MAT 385 points t o next menory location and goes ahead t o

wait for a strobe signal.
Before the data transfer, the user is required to
i n i t i a l i s e HL register t o point t o the s t a r t of menory
where object code is to be stored. The MAT 385 loader
subroutine should also be executing fran manory location
8000 Hex.

The canputer p r i n t out of loader routines i n the Apple 11

and MAT 385 a r e attached a t the end of the chapter.

The s u b r o u t i n e i n Apple I1 d i s k and MAT 385 had been

loaded and using the interface connection, the interface
s y s t m has been tested and it is working fine.

The interface was tested by putting source code into Apple

11, assenbling i t using the cross assanbler and energising
t h e loader progrm a f t e r i n i t i a l i z a t i o n of MAT 385 manory
and s t a r t i n g the execution of MAT 385 loader progrm.

After the object code transfer, then MAT 385 manory was
checked using the "display memory" facility . The
transferred data were seen t o be stored a t the appropriate
menory locations.
APPLE: I1 INTERFACE SUBROUTIME
 INDEX OBJECT SOURCE
NO. CODE CODE
1 3E I N I T M V I A &0Q
2 0Q
3 D3 OUT &U2 MAKE PORT 00 I N P U T
4 02
S 3E M V I A &OE
6 0E
7 D3 OUT &03
8 03
9 f E MU1 A $402
10 02
11 D3 OUT &O1 RESET COUNTER
12 01
13 3E M V I A &OC
14 0C
15 D3 OUT & 0 1 PREPARE COUNTER TO COUNT U P
16 (11
17 DR W A I T I N tcOl
1B 01
19 €6 A N 1 8401
20 01
21 CA J Z L W A I T W A I T FOR STROBE
22 11
cl-
L *> 00
24 gE M V I A &02
25 02
26 D3 OUT 8 4 0 1 RESET COUNTER
27 01
2R D3 OlJT fd31 RESET COUNTER
29 (:I1 ,

30 7
E
31 t:c
32 D.3
77
C' .-I
01
34 DR GDATA I N t&0 GET *DATA
35 (30
36 77 PlflV M A STORE DATA
57 23 I N X H I N C R MEM
38
99
c3 . JMP L W A I T
11
40 ):t ts
DO YOU WANT TO TRANSFER SOURCE CODE TO MAT 385 ?

\.

MAT 385 INTmFACE SUBROUTINE

P R I N T E R INTERFACE CABLE 7 4 /LS 192 MAT 3 8 5

BTROBE

DATA

DATA

DATA

DATA

DATA

DATA

DATA

DATA

10 ACK

II BUbY
It- I 8 N / A

19- 27 ON0

28-SU N/A

F le. 7. I INTERCONNECTION OF APPLE 11 TO MAT 385

USINO PARALLEL PRINTER INTERFACE CAR 0
 II 1 I
L

5 - r
CPu -12
4 - CP. -13 01

CONNEC T I 0 N D IAORAM PINOUT

MR i% CPu MODE

H X X -me 9( Assynchronous 1
L L X Preset

L H H No chonge

L H 1 Count up
L H H Count down

MODE SELECTION T ABLE

Fl0. * 7. 2 74 / LS 192 HARD WARE DAT A

 - 100 -
CHAPTER EIGHT

8.0 CONCLUSION

Although the widespread a v a i l a b i l i t y of computing f a c i l i t i e s is

r e l a t i v e l y r e c e n t , computers a r e now being used i n n e a r l y a l l
d i s c i p l i n e s a s tools for solving a wide variety of problens(18). The
range of p r o g r m i n g languages now available put the power of the
canputer within the grasp of nearly weryone. Despite t h i s ,
computers undoubtedly could be u t i l i z e d more e f f e c t i v e l y than they
a r e i f f u l l y developed.

The v e r s a t i l e @0S provided is t o enable for the ease of developnent

of 8085 microprocessor application programs. In t h i s systen, a cross
assembler resides in the Apple 11 d i s k e t t e .
When loaded on Apple 11,
it accepts source code, validates and converts the source code t o
machine code. The loader program handshake routines in Apple I1 and
MAT 385 down loads the object c,3e t o MAT 385 where t h e application
program is debugged. In the i n i t i a l design (Chapter 2) , a hard copy
of the progran is supposed t o be produced using TTY interfaced t o MAT
385 or using the Apple 11 p r i n t e r . But t h i s aspect of the project
was not implanented because the available 'ITY t o be interfaced t o MAT
385 is bad and the Apple I1 interface adapter which can be interfaced
t o MAT 385 t o allow the l a t t e r t a l k t o Apple I1 is not available.
The c r o s s assanbler has both the Apple I1 and IBM PC (IBM personal
computer) version. But, IBM PC is not interfaced t o MAT 385, so,
program assanbly on it implies keying in of machine codes i n t o MAT
385 a f t e r program assenbly. The cross assanbler has an IBM version
because, a t a stage t h e Apple I1 where t h i s work was being done, got
bad, s o work was continued on IBM PC and l a t e r converted t o Apple I1
basic.

Apart from the problan of having t o record the assanbler in IBM basic
and l a t e r Apple I1 basic, having the cross assanbler in B
IM basic
makes it more v e r s a t i l e a s the trend in microcomputer production,
t h i s day is the production IBM canpartibles. Recent report fran a
computer firm in ~ a i w a n (which represents U.S.A. computer i n t e r e s t
because of low c o s t of labour) , canputrex, shows t h a t a l l
microcanputer on display were IBM compatible and were being sold a t a
p r i c e very low when canpared t o IBM PC (23) .
Even the l a t e s t brand of
Apple I1 microcanputer i n the market (Markintosh) is IBM canpatible.
T h i s i s not surprising because IEM has done a l o t of work in the
production of very good systen softwares.

The c r o s s assanbler produced is easy t o use since it does not need

p r i o r knowledge of high level language. It is designed using top
down design method, the design and coding stages were w e l l docunented
and t h u s is e a s i l y maintained. I t can a l s o be e a s i l y modified. The
implenentation was done in basic which almost every microcanputer
has canpiler f o r , so it can be e a s i l y adapted t o another
microcanputer basic using, where available, basic converter progran.
Although the MAT 385 does not have standard interface facility, but
only input-output ports, the interface between it and Apple I1 was
designed using these ports and the printer interface card. The ports
were configured to act as both receivers and senders of control
signal as well as data receivers. This interface was successfully
done and it allows, with the aid of handshake routines, in both the
Apple I1 and MAT 385, for the object codes to be down loaded into MAT
385 fran Apple 11.

The most tasking, time consuming and frustrating aspect of the

project is the lack of facilities and information materials required
for the implenentation of the project design. This was overcane by
modification of existing facilities using available information to
meet the design specification.

The MAT 385 could not be interfaced to ASR 33 teletypewriter because

the latter was not in good condition. The TTY when put in use can be
interfaced to MAT 385 using interface outlet provided for it at the
back of MAT 385 (see reference 24).

The software for data transmission to and fran the microcanputer can
be implmented by using the subroutine already developed in MAT 385.
Before the subroutine call, data should be got fran the appropriate
menory locations and put in appropriate registers. These subroutines
are used to input or output data £ran or to the W .

For the work to be conclusively done, there is a need for the MAT 385
interface routines, both the down loader interface program and the
TTY program, to be on R(3M so that they can always be in canputer
menory. This calls for the ROM burning of the programs.
f-' -
- - ,->
.../lo3
 - 103 -
APPENDIX
I, IST

5 j, REM *.K-,.*.k.lt+**.******.k***~~**.It
'70 D I M H:S(lb)
'71 F::OR 1 :: (1) 1.0 15
' 7 2 HE:(?D Id$ ( I )
7X NEXT :[
, I),qTfi " O H , " I " , "2" , 1 1 "-.a " , " 4. "
,-,
11 c II , llbll, 1 1 7 0 ,I I H I I , U 9 M , II

A " , " B " , " L.' ", "1')" , "E:"

1
9 "F"
240 DRTA "DAR1' , "2711, "CMA" "2F ,
11
11 , , ,
S T C 11 11 37 II Il CMC 11 II SF fl II PCH
L", NE9", I ~ X T H L ~ ~ ,
, , ,
" S P H L " I'
,
1-9 11 1 11 E I 11 11 FB I 1 9 II D 1I 1 11 F:; 11 " t i L T
,
11, 11-7[,11, I l S I M I l " 3 0 " , I I R I M V , 1 1 2 i ) f l
, ,
"N(3Fl1, I1O(:)", " A D D E " M8r:,11, "AL)D
, , ,
C ll 11 8 1I 1 1 11 ADDD ll 11 R Z I 1 18 ADDE ll ll ,
l33"
250 O A T 0 llADI)H1', ,"84" "ADDL" ,
" 8 5 " , IIfiJ'JJ'JMl', "8&", ,
"AD])()" 11

87", " A D C B " , ,

"R8" "ADCB", I'

RW", RUCC:", "89", "ADCD", "(3

Pi'' , , ,
IIADCEI1 '18E(1' IIAl)CHtl , "8
C" , "RDCL.." , "8D" , "RDCM", "€3
E" , , ,
Ilwcnlt llnFll l l s t J e a l l 119 ,
O M , "SLJEC:", ? "'"I, "SUED", "9
2"
2 6 0 DFITA "SUE€" , ," 9.3" "SUBH",
"94" , "6LJRl ...", "95" , "SIJHM" ,
, ,
"Yh" I1SUHfl1' "Y'7" "SEIBE" , ,
"YR" , "SBI3C" , "c?Y1l, "SEtPD" ,
"9a1', " S R B E " , " Y B " , "SEEH" ,
"9C" , "SBBI-I' , "9D" , "SBBM" ,
"7E" , "SBBA" , "9F1'
270 D A T A "ANRF", ,"AO" ANRC ",
" f l l " , I*fiNfln)l, 'lfi211, I*nNflE'l,
,
~ f i : ~ " " G N A H " , " R 4 " , "RNRL.",
,
"a5" "ANAM", "A[," , 11 ANfiA"

"A'7", "XRAB", "AB1',XRAC", "R

Y " , "XRRD", "AA", "XRAE", "A
E", n ~ ~ ~ llncla, ~ l l ,llxrxnt-ll, I1n
D l ' , "XRAM", "AE","XRAB", "AF
... ..
..::,..:;#f.1 I:)X 3' ,,-. M I I.) B ( C: S' ,, C: 2 , 1. )
..., ..*
.::,..::J:):l. pi$- . " "
..* .,
1F' X :$ :.= " " 1 k.IE:
,

r ; :12
1(1
~ I F XLS: .- ;-??;& (1)
; 11 'l't.i~b1..3511.5
::;:? 1 4 LJ';?
.:;:y;?( ..
1;.)
.. :, .-,,.,.:-, . . : 1::
2
7: C:2 -1.. j

C Z .4.. 1,
, ,
PI I I>$ ( $:C ?: I[ 1)
-.
...,....,,, ,., :IF-' L.JI~ :-
.. .w~ .-: . , 1F I.J:f
..* ., .-,
P
.,
- 'rI..iE:rq 3:~.1.(::)
" ; I' 'Tt.IEN :iJI.c:)
.:, ,,:,,:,q. ~q:)' 7 : M:0: ,+ I1 .ir : (::;I: I 'r~3,:9:52r::)
3 ' 3 ) IF:' X $ r: " $ < I 1 Tt.IE::N 337c)
.. ..+
.,:,,,:. 1 2 1: I-' X :$: := " (ii." I'k.1E:N :3:38(:)
:,J::-qq, 1 y .? :!: 1 1 ,,,, 1 11 " l ' ~....- ~ ~ t,~
-:r"qC?[;)
.... ._.
,..r ...
\ - ' I

..:,.:,/I.$, f:.;[.)'y[:) :::=:>.ql= ,..I - ...I

, ; 1 <E"[I.jRN
.T r l'- .
: : REM *#..#.*.+**%.,W.R.#..#.*.E.tc..8..&.*.*
; :1 :3 (.) 2 :: r"; 2 .+. 1
'?..*
.-,.:. 6 2 13[J "I'[I 53 0 0
..*. "-..
: : 71) G CIS1.1E h 5 (30
:5:.5'72 TjC3"rn ;???;sc)
..., .
.rj.:.S!() 1) -: Vf.>I_. ( M B ) : GO'l-(l 333:)
,.* ..,.
,. ".I
a , .. [I: 2 :!. c 2 -- w 2
. C-7
;53C'7G(3SIJH ll:)i:l(.:):(3(31'(3 :33:-?1:)
I
. ..
, ,.rL. .. c:-
. J . . .
REPI ~ M ~ * ? ~ % ~ * ~ E . X ~ * ~ ~ ~ ~ * . * ~ ~ . . W ~ * . # . . F ~ *
f::'RXNT "C3I="EFZfll\lD EXI"EZI::l"l.:D1': GCI'Tl3
. h ? 1, F:'t ( T I?I'I" C:::$: : G!lS LJR 263 4 5): GfJ-I(3 570
I
5 7. i:)
., <..
(-*? C 2 -I.. 1,
7-

X B = M II.') $ ( (,:: :F t::.2 1 ) , ,

,[ F' X $: .- " " "I't.{ErNfi3 yB[L)
M$ ::: M$ + X $
7. S .t j,
I F S -= 1 'THEN H Z 8 0
I3C]S[.JE c?Oi;:)O
G [:I "r[:.I E!2: 4)I:?
"
['"?L :. C 2 -1- 1
X:t: MID$ (C:T,[::Z,I)
:-;L

I F XF 7: " " 'l'ffEI\I @:'52C)

M$ =- M:f -1- )($
GCJ!31.JB '?(::lr3(:1
GC)SI..IB 90bC!
U( I TCl €326 Cl
I:: :!' ::I? C 2 .+ 1
X:f - M:[r)$ (C::*,C:2,1.)

-.
I F X:$ :- " " "rHEN H>57[:)
M.$: 4- Y,:$
G[:')SLJB 90(::1(3
GC)!jLJKl YC')c?0
IXI'T'U 8260
f3t:)!!jl J Ef (9(:I i j (11
f3C)SI.JR 70'-?(): GC)TfJ 9 2 b 0
[iyyl ~.E***.E*.*.*,*,E,~~~*,*+
K'Ell SE:ARC:H C:)F':'f3C:)I:)E 'I'RBI.,..E
F:'UR I :- 1, 247 'r(:]
I F : M l : ::= f359:(T) THEW Yr:)1H
r ' I
t-I:$ e:: Ah$. ( I ) :F.:C
' :; -: PC: + 1 :% 1 2:::

1
1. NWACHUKU, M. A. Basic ~rinciples of Microprocessors fran the
Digital System Design viewpoint, May 1985.

2. MAN0 MORRIS, M. ~igitalmgic and Cmputer Design, Prentice

Hall, Inc, Englewood Cliffs, N.J., 1979.

3. FALK,H. Self - Contained Microcanputers Ease Systen

Implaentation, IEEE Spectrun Vol. 11, No.
12, Decenber, 1974, pp 53 - 55.

4. TSENG, V. Microprocessor Developnent and Developnent

Systens, Granada lmdon Toronto Sydney NY.

5. JACKSON, P. PC Cannunications, Britains Independent Guide

to IBM - Oanpatible Personal Canplting
October, 1986, Vol. 3 Issue 10 48 - 54.

6. JEAN, D. N. peripheral Interface Standard for

Microcanputers, proceedings of IEEE Vol . 64,
No. 6, June, 1976. pp 876 - 904.

7. CHIJIOKE, M. 0. Lecture Note, Cmputer Organisation, 1986.

8. DONALD E. TROXEL Serial Interface for Microcanputers, IEEE
Transactions on Canputers October, 1975.

A Guided Tour of Program Design

Methodologies, Canputers, 1975

10. WATSON, M. I. Canparison of Cannercially Available Software

Tools for Microprocessor progrming ,
proceedings of IEEE Vol. 64, June, 1976.

11. WIRTH, N. The Ccmposition of Well Structured Prograns,

ACM Canputing Surveys 6, 1974, TIC (3) .
Software Engineering , IEEE Transactions on
Canputers Dec., 1976.

13. HUSKY D. HARRY. The polish Assenbler, IEEE Transactions on

Canputers Nov., 1973

14. PETER, J. PC Cmunication, Britain's Independent aide

to IBM Canpartible Personal Canputing, Issue
10, Vol. 3, October, 1986. pp 48 -54.

15. BASIU, R. V. AND

BAKER TERRY Structured Programing Revised 1977
16. RAFIQUZZAMAN, M. Microprocessors and Microcanputer Developnent
Systens, Harper and row, Publishers, new
York, 1984.

Microprocessor Systgns Design, Prentice Hall,

Inc. Englewood Cliffs, ~ e wJersey

An Overview of Programming practices, ACM

Canputing Surveys 6, 1974 TIC (3).

19. TANENBAUM, S. A. Structured Oanputer Organisation renti ice

Hall ~nternationalEldition, 1976.

20. DONOVAN, J. J. Systens ~rogrming, MacGraw - ill

International Book Canpany, 1972.

~rogrminglanguages & Canputers: A unified

Metatheory, Advances in Computers Vol. 8 ,
1967.

Portable Micromputer Cross Assembler in

Basic, Canputer, Cztober, 1975. w 32 - 42.

23. RAIKE, W. M. ~aiwan Based PCs , Business Software ,

Decenber, 1986.
24. Microprocessor Applications Trainer, MAT 385, Vol. 1, 2 and 3,
Feedback Instrunents ~irnited,1982.

25. CARDENS, F. A. Interscience published by John Wiley and

PRESSER, L. & Sons, I~c.,NY, 1972.
MAVIA, A. M.

26. MALVINO, A. P. Digital Cunputer Electronics: An ~ntroduction

to Microcomputers, Second Edition, McGraw
Hill, Inc., 1983.

27. BASS, C. & B R m , D. A Perspective on Microcanputer Software,

Proceedings of IEEE Vol 64, No. 6, June, 1976
- pp 905 - 909.
28. YEH, R. T. & ZARE, P. Specifying Software Requirements, IEEE
Proceeding, vol. 68, No. 9, Septenber, 1980.

29. BROWN, J. C. ~nteractionof Operating Systens and Software

~ngineering,IEEE ~roceeding,Vol. 68, No. 9,
Septenber, 1980.

30. IBM Basic Reference Manual, Third mition, May, 1984.

31. .Intel MCS - 80/85* Family User's Manual, Intel Corporation,

October, 1979.
32. WIZARD IPI Intelligent printer Interface Card for Apple I1 and Apple
I1 Plus Canputer Owner's Reference Manual Copyright 1982 by Wesper
Microsystms, Inc., U.S.A.

33. he Apple soft ~utorial,1979 by Apple Canputer Inc., U.S.A.

34. The Apple I1 DOS Manual, 1981 by Apple Canputer INC., U.S.A.

35. Apple I1 Reference Manual, 1981 by Apple Canputer Inc., U.S.A.

36. Parallel Printer Interface Card, Installation and Operating Manual,

Apple ~ntelligentSubsystem, Apple Canpany Inc., U.S.A.

37. MOSDS, F. & An Introduction to Mini & Micro Canputers,

McLAUGHLIN , R. .
Published by Peter Peregrimus Ltd , London,
U.K., 1984.

38. KLINEI B. MAERZ, M & The In-Circuit Approach to the Developnent of

ROSENFELD, P. Microcanputer - Based Products, IEEE
proceedings Vol. 64, No. 6, June, 1976, pp
937 - 942.

A Cross-Assanbler for the Intel 8085

Microprocessor - A Project Subnitted to
U.N.N., June, 1983.