17
4. Running the MCDS COSMAC
Resident Editor (CRE)
The text Editor supplied with the CDPl8S694 and
available as an option for use with the CDPl8S693
allows the user to create ASCII files on cassette tape.
These files can be Level I CDPl802 language, BASIC3
instructions with line numbers, or simply text. The
Editor, in ROM, is evoked while UT62 is running by
the user typing E. Upon this command, the Editor
searches memory starting at 7FFFH for the top of free
RAM. After finding the top, the Editor types its title
and a prompt (^ ) thereby indicating its readiness to
accept commands.
Introduction
After the user has written his COSMAC assembly
language program and wants to assemble and run it, he
immediately faces the problem of convertingthe hand
written source file into a machine-readable form. This
conversion involves a keyboard-to-tape operation in
which lines on the coding sheet are transcribed to
become lines on a source tape. The Editor provides
assurance that the created files are in proper format for
later reading by the Assem bler and for later
modification, if necessary, by the Editor. Details on
formats are given later in this Chapter.
Once a source file has been created and a first
Assembly run made, it is very likely that error
diagnostics will be returned by the MCDS COSMAC
Resident Assembler (CRA) asking for corrections to
the source file to conform to CRA’s rules. Typically,
the changes required at this point are “trivial” but
necessary. For example, spaces may have to be
removed in one or more expressions. The same symbol
may have been erroneously used for two purposes. An
operation mnemonic may have been misspelled or a
punctuation character such as a comma, colon, or
single quote omitted. The number of possible trivial
errors is clearly large.
To correct the errors and to alter the source file to
conform the program to the CRA rules, the Editor is
used. Typically, modifications at this point merely
involve insertion and deletion of single characters or
replacement of a small string of characters by a
substitute string. The erroneous source file is used as
an input to the Editor and the user generates a
corrected source file as an output. The new file is then
re-assembled. At this point other trivial errors may
appear which were not apparent to CRA on the first
run. For example, an erroneous instruction operand
may not have been flagged on the first assembly
because its associated statement label or operation
mnemonic may have also been in error. Thus, a new
Edit-Reassemble pass may be necessary. Finally, a
program is developed to which CRA does not object.
At this point, a first run can take place.
The probability of a logical error in the program
depends on its length and the previous experience of
the programmer. Assuming one or more logical errors
are found (via some “debugging” procedure), the
source file must again be modified. Often such
modifications are no longer trivial. For example, it
may be necessary to find all instructions which branch
to a given location and precede some of them with one
or more instructions currently not in the program.
Often, it may be necessary to delete some code or insert
some code or move some code to a different point in
the program. Several duplicated sets of in-line
instructions may have to be removed and replaced with
calls to one common subroutine which is to be added.
The user may decide to “clean up” the program
logically, in any one of several ways, or to improve its
“readability” by modifying its comments or statements
form ats (by inserting TA B ’s or SPA CET, for
example).
Such modifications to the source file also involve use
of the Editor. After they are completed, a reassembly
may again turn up new errors of the “trivial” variety.
And so on. Thus the generation of a bug-free program
typically involves the chart shown in Fig. 4. It is quite
likely that the amount of time spent “conversing” with
the Editor will be much larger than that spent with the
Assembler.
