Subject: Program to disassemble .RIM/.BIN files

From: [email-masked] (Megan)
Date: Sun, 2 Jan 1994 06:24:51 GMT

In case anyone is interested, I have written a first pass at
a pdp-8 RIM/BIN file disassembler.  It's pretty crude at the
moment, but if anyone is interested, I'll make it available.
It is written in C and has been tested on my Ultrix/VAX machine
and on a 386.

					Megan Gentry

p.s. I guess I'm looking for alpha-testers (no, not people with
     alphas... :-)

---

From: [email-masked] (Charles Lasner)
Date: 4 Jan 1994 12:01:47 GMT

>It is written in C and has been tested on my Ultrix/VAX machine

I'll assume for the moment that what you mean is the following:

Assuming an 8-bit-byte-oriented machine and file structure, a file is
present that consists of the 8-bit frames of a RIM or BIN paper-tape in a
data stream, etc.  Note that such a file can easily be created from an
OS/8 file that was an actual paper-tape or assembler output (.BN) file by
using the PDP-8 ENBOO utility and MSBPCT on the 8-bit end, etc. (I would
assume Kermit got the encoded file between systems, etc.)

Further, that the BIN or RIM file is then pseudo-loaded into a PDP-8
"core" buffer and the 12-bit values are themselves available in some more
symbolic form such as 4-digit octal addresses and data, and hopefully,
beyond that some actual symbolic disassembly where PDP-8 symbols are used,
together with some address symbols.  (Note, most disassemblers use some
form of auto-generated address which is a mechanical translation of the
octal address.  For example, the addresses 0000-0177 could be referred to
as Z000-Z177, and 0200-0377 could be A000-A177, 400-577 could be
B000-B177, etc.  Of course beyond that, it would be nice to define
user-defined symbols to override the auto-generated addresses!)

Please note that anyone who already has an -8 OS/8 system or an OS/278
DECmate system doesn't need this sort of "reinventing the wheel".  (Nor
does someone successfully running a "complete" emulator!)  We already have
the DCP16 and DCP24 programs.  (Note: the sources to these were lost years
ago; they apparently originate in Europe in a country where German is the
prevailing language; it would be greatly appreciated if the sources were
restored, since there are a few minor annoying bugs still to be fixed in
the disassembler itself!)

DCP16 can take either .BN or .SV files as input.  ABLSDR can load  any .BN
into a .SV anyway, and the program SV2BN can do the reverse if needed,
etc.  You can assign symbol names and values, and distinguish between
definitions and addresses.  (Thus, KSF doesn't ever mean a reference to
location 6031! NL0002 doesn't mean a reference to location 7326 (CLA CLL
CML RTL), etc.)  Disassembly of any field is allowed, but only one-at-a-time.
Binaries and a terse poor-english document are available.

I have used DCP16 to disassemble several sets of the DECmate 4K ROM's,
etc.  Of course, you have to decide when to abandon the disassembler and
go it alone on your "source", but you can get pretty far fairly quickly. 
Typically, a control file is created after a few hours work that contains
about 60% of the most important symbols you need to override automatic
disassembly, so you then quit with an ugly but manageable source.  Many,
many hours later, a fully adorned source file (may) emerge if you are
persistent (as I was).

DCP24 needs 24K to run in (thus the name; the other needs 16K).  You get
two features more:

1)	It attempts to follow mode A and mode B EAE changes and does
translate EAE symbols; you can help it into the correct mode if you know
it's backwards.  In any case, it uses mode change instructions SWAB and
SWBA to change the disassembly assuming sequential mode application, etc.

2)	This may be more trouble than it's worth, but it allows you to
assign comments to addresses!  This of course means that disassembled
output is strictly limited to only comments on words of code, thus no
"loose" comments anywhere else, and only one-liners at that.  Since
comments usually want to be a bit freer than that, you probably won't add
comments until you can call the source "your own" and no longer
disassemble, etc.  Moreover, due to other cosmetic problems with the
program, you'll want to perform some clean-up pass on the source, and
seeing comments before cleanup may be counter-productive, etc.  (Your
comments could interfere with TECO macros used to clean the source up!)

Like many other disassemblers, it does occasionally tend to create
"bunched-up" source lines, meaning OR'ed together symbols that do generate
the correct code, but make no sense.  By carefully creating control
statements that affect the particular locations, this can be curbed or
even eliminated.  (But likely isn't worth the effort of totally
eliminating it!  Better to just contain it and fixup later when you are
getting the source to make more sense, etc.)

In any case, I would rate the current DCP16 at about a B+ in terms of what
you would theoretically want it to do for you.  Those of you familiar with
ASMGEN will find ASMGEN to be a rip-off of this earlier work (or merely an
interesting coincidence!).

cjl