Table of Contents
Advertisement
22 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Operator Manual for the RCA CDS II CDP18S005
Programming Interface
to CSDP
Machine language coding,
even of a trivial
program, should convince the novice programmer
that to do any serious programming, one should take
advam.
a ge of the set of software support aids
available. Veterans in the programming community
are
already aware of the fundamental necessity for
assembly and simulation facilities. Support services
~re"
available either by timesharing, i.e., using a
system
of
RCA-developed
programs
hereafter
ief~rred
to as CSDP, or by this Development System
itself. The user manual for the former set of programs
is the Timesharing Manual for the CDP1802
COSMAC Microprocessor, MPM-202. For the
latter
set
of programs it is this manual. To do any
non-trivial programming, it is
essential
that the
reader be familiar with the facilities provided by these
software
support systems. If the reader is not using
CSDP, he should skip this
section.
As discussed in the Timesharing Manual for the
RCA CDP1802 COSMAC Microprocessor, MPM-
202, much of program developmenl by CSDP is
accomplished
without direct CDS involvement.
Typically, a source file is constructed, assembled,
edited
(if the assembler objects to the source code),
reassembled,oo.,etc. The
simulator
is used to run the
program, during
which
time program bugs are
isolated and removed by
further
editing and
reassembly of the source file. Eventually, the object
code
is ready for loading and running in the real
hardware (the COSMAC Development System) for
further testing. It is this part
of
the process that is of
concern
here.
Already discussed has been the use of the '! M'
utility program to load the CDS RAM from the
keyboard or from tape. One ultimate purpose of the
CSDP
system
is to
generate
an object code file,
compatible
with the required ! M format, and (on
command)
to transmit this file
over
the telephone link
to the CDS system. Clearly, it is possible for the user
to write this file onto a tape and subsequently load the
CDS using this medium. Of
concern
here, however, is
the
automatic
mechanism by which the
!M-
compatible
object file
coming
over the telephone line
is loaded into the CDS RAM directly.
There are three different data communication
paths. First is the I/O teletypewriter-CDS path,
already
discussed. Second is the I/O teletypewriter-
Timesharing System link, via an appropriate modem,
which is implied in the use
of
CSDP for assembly and
simulation. And third is the Timesharing System-
CDS link (again via a modem) which is essential to
the automatic, direct-load process.
Some switching mechanism is implied by which the
Development System
serial
"Terminal" input signal
can
come either from the keyboard/tape reader or
from the modem carrying data generated by CSDP.
A teletypewriter unit,
for
instance, requires an
external
modem (e.g.,
an
acoustic
coupler or
a'
data
set),
and
an
added
external
"switchbox"
to
mechanize the
various TTY-CDS.
TTY-modem,
and
modem-CDS paths. It
should
be an appropriately
wired three-position
switch.
In the "TTY CDS"
position
the terminal
acts as
the I/O device for the
CDS.
In the "TTY-TIMESHARING" position. it
acts
as
normal
timesharing terminal.
In
the
"TIMESHARING-LOAD"
position, the link is
established
to allow data from the timesharing
system
to be automatically loaded into the CDS memory.
If it is asslUned that the user has been using the
CSDP control
program
and
that an object
code
file,
previously
assembled by
CSDP,
is ready for tran-
smission,
the steps required to
effect
an automatic
load
of
the CDS RAM follow.
Because
CSDP will transmit an ! M-compatible
object
file on command from the terminal, it is
necessary to properly initialize the utility program
so
that it is ready for this input.
This
initialization is
done by temporarily
switching
the terminal to
ac-
tivate the TTY -CDS
path only,
and pressing
RESET, followed by RUNU, followed by the
keyboard
echo-timing
control
character
LF.
Initialization will be followed by a return of the
prompt
character indicating that UT20 is ready. It
will then ignore all subsequent inputs until a ! or
' !
or
$ is detected. It is essential that this local initialization
be done at a time before the final carriage
RETURN, which terminates
the
"transmit"
com-
mand to CSDP, yet after the occurrence of any
characters
in this
command string
recognizable by
UT20. Thus, the final "transmit
object
file"
com-
mand
to
CSDP
is
begun
in
the
TTY-
TIMESHARING
mode.
At the proper point, UT20
initialization occurs,
as discussed
above. Then, the
terminal is switched back to TIMESHARING
LOAD and the
command
is
completed.
All
sub-
sequent
characters are ignored by UT20 until it
receives
the loading ! M indicating the beginning
of
object
file transmission;
CSDP indicates that it is ready for a user command
when
it
outputs
to the terminal the prompt
characters
DBG. Assuming that the
assembled
file is ready for
transmission, the following two alternative CSDP
commands
will effect the transmission:
1.
$X
6.
FiLe Name
6.
Start
RAM Location
6.
End RAM Location where FiLe Name is the
name of the file
or
the device which will
Advertisement
Table of Contents
