Subject: PAL assembler in C?

From: [email-masked] (Douglas W. Jones)
Date: Wed, 9 Jun 1993 17:14:40 GMT

In order to simplify fooling with my -8, I cobbled together an approximation
of the PAL assembler, written in C.  My intended use for the thing is to use
it to assemble diagnostic code snippets and then download them from my laptop
to the -8, with the RIM loader on the receiving end of the download.

By default, the assembler outputs in BIN format (untested), but it has a
UNIX style -r command line switch to make it generate RIM format and a -d
switch to make it dump the symbol table.

If I can get source for the BIN loader over the net, of course, I'll download
BIN into my 8 using RIM, then make more use of BIN format.  If I can get
source for the RX01 diagnostic programs, I'll assemble them and use them
to test my RX01, then give up on using this toy assembler and use the real
thing.

My assembler provides at least partial support for the DECIMAL, OCTAL,
ZBLOCK, PAGE, TEXT, EJECT and FIELD pseudo ops (EJECT just puts out ----),
and it can handle [] and () notations for constants assembled onto page zero
or the current page -- it even puts them in the same place DEC's assembler
does for a few examples I tested.

It hasn't been very well tested, I don't guarantee much in the way of
compatability with DEC software, and in addition, I make all the other
usual disclaimers, but if anyone wants it, they're welcome to it.

					Doug Jones
					[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: Wed, 9 Jun 1993 23:58:54 GMT

>to the -8, with the RIM loader on the receiving end of the download.

For some people, it would be nice to have a truly compatible assembler.  I
can provide some of the compatibility points on the "sticky" issues.

Note that if a complete -8 emulator is used, then the *real* -8 assemblers
themselves can be used which avoids the problem.

Note that an MS-DOS file or any other byte-stream file can represent either 
BIN or RIM files currently.  Assuming a serial connection between the -8
(whether simulated or not) and a PC, you can send the contents down the
serial line at a RIM or BIN loader as required, etc.  This format file can
be derived from OS/8 binary format using the PDP-8 ENBOO/DEBOO programs I
wrote that are distributed with Kermit-12, etc.  On the PC side, run the
MSBPCT (MSBMKB to go the other way) utility to recover this format, which
is good for any of the 8-bit-representable OS/8 formats, including BIN and
ASCII including TECO macroes, etc.

PDP-8 assemblers do not output RIM format per se (except for P?S/8 which has
an explicit RIM format option switch).  However, it is possible to output a
file that can be loaded as both RIM *and* BIN.  This convention has been
used in some DEC programs such as the self-starting binary loader (a slightly
buggy program itself, but the format is what's interesting), etc.  Consider
a short program:

	*200

	CLA
	TAD	L3
	HLT

L3,	3

If changes are made to the file, it can be both RIM and BIN compatible:

	*200

	CLA

	*.

	TAD	L3

	*.

	HLT

	*.

L3,	3

	*.

This outputs the requisite origin settings for RIM's benefit, and also outputs
the checksum at the end for BIN's benefit.  The reason for the trailing "extra"
origin setting is to prevent the last program word from being destroyed.  Note
that this last origin must be to an innocuous memory location into which the
checksum data will be loaded when using RIM!  (Thus, the last origin shouldn't
be to something like 7756 assuming the program is loading just in front of the
RIM loader, etc.  Use some other origin such as 0010, etc.)

I will dig up the sources to the space-optimized P?S/8 BIN loader which is
totally DEC compatible save one unimportant feature:

The "real" BIN loader reads the console switch register[0] to dynamically
determine whether to use the low or high-speed reader.  In theory this means
that you could switch devices in the midst of a multi-tape read.  This is of
no importance to a loader that in turn is loaded from a disk/tape-based O/S!
Note also that the RIM loader already has this restriction, i.e., there are
actually two RIM loaders, one for low and one for high-speed.  So, the P?S/8
version must already be assembled for either reader, but not both.  In the
actual load by P?S/8, the user passes option switches to the overall utility
that are used to patch together the appropriate BIN and RIM device codes
since the instructions, while not identical, take up the same exact code
length and absolute addresses, etc.

[Note: I will have to provide enough equates to make this code assemble
without being imbedded within the larger space of the overall system program.
This is merely a code fragment that is assembled with relocation and is meant
to be "massaged" and patched and ultimately be placed into memory by the
utility itself, and not necessarily (at all times) at the intended addresses.
This is a common technique used in writing utilities of this type, especially
since the usage of BIN and RIM "displaces" the O/S itself.  Once BIN and/or
RIM are in control of the machine, P?S/8 is no longer in memory.  Restarting
the machine at 07600 executes a device-dependent warm boot routine that
reloads P?S/8 from the device the BIN and RIM loaders were residing on in the
first place, etc., but literally no other aspect of P?S/8 is left in memory
at the point that BIN and RIM are loaded.  During the time that BIN or RIM
is in control, all locations can be freely loaded except the locations where
BIN and RIM are, and also 07600-07642 if it is desired to have the ability
to reload P?S/8 merely by restarting at 07600.  BIN and RIM occupy 07643-07777
which is somewhat smaller than the original DEC BIN and RIM loaders.  (Actually
RIM for P?S/8 is 100% identical to DEC's BIN; the differences are purely in the
BIN code.  RIM occupies 07756-07776; 07777 is reserved as a JMP instruction to
where the normal restart address of BIN actually is, so that it's unnecessary
to know the starting address other than 07777, etc.  Also, the variable
locations within RIM are used by BIN, so while it is correct to say that
RIM occupies 07756-07776, it must be said that BIN occupies all of 07643-07777
which includes RIM.)  Certain DEC diagnostics are known to destroy locations
such as 07615-07617.  The P?S/8 version of BIN is more than compatible with
this convention, however the P?S/8 reload function will be destroyed by
loading such code; only complete manual restart can get P?S/8 back up.  
(Perhaps using a P?S/8 bootstrap in BIN or RIM format!)]

cjl