NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/alt/sys/pdp8/98

Text File | 1992-11-22 | 5.8 KB | 124 lines

Newsgroups: alt.sys.pdp8
Path: sparky!uunet!psinntp!news.columbia.edu!watsun.cc.columbia.edu!lasner
From: [e-mail] (Charles Lasner)
Subject: Re: What I've got and what I'd like to have
Message-ID: <[e-mail]>
Sender: [e-mail] (The Network News)
Nntp-Posting-Host: watsun.cc.columbia.edu
Reply-To: [e-mail] (Charles Lasner)
Organization: Columbia University
References: <[e-mail]> <[e-mail]>
Date: Sun, 22 Nov 1992 11:08:59 GMT
Lines: 110

In article <[e-mail]> asgard@sparky (J.R. Stoner) writes:
>
>Um, nope.  Mine was 33 words long and started: 7126, 1060, 6755...
>You must have been using a different RIM that I did.

Wrong.

RIM is a standard name for a paper-tape format and its loader: it stands for
Read-In Mode.  It proscribes a format that is a subset of the paper-tape
loading format known as BIN.  In Bin format, origins are optional, as the
next word is implicitly to be loaded at the next location, etc.  In RIM
format, each word must be preceded by an explicit origin, since the loader
has no ability to auto-increment the loading address.  Additionally, the
BIN format ends with a checksum not meant to be loaded, while RIM format
has no checksum.  It is possible to create a "universal" binary tape as
follows:

    *200        /ARBITRARY ORIGIN

FIRST,    CLA        /CLEAN UP

    *.        /FOR RIM'S BENEFIT

    TAD    300    /NEXT INSTRUCTION

    *.        /FOR RIM'S BENEFIT

    TAD    301    /NEXT INSTRUCTION

    *.        /FOR RIM'S BENEFIT

    HLT        /NEXT INSTRUCTION

    *.        /FOR RIM'S BENEFIT

Such a binary tape is essentially in RIM format because the programmer
inserted the required origins where needed.  Note the use of an extra origin
after the last instruction.  This is necessary because the checksum outputted
to the tape will become a junk value loaded there!  Without that "safety"
origin, the last instruction would get overlayed by the junk value.  Of course
this tape is acceptable to BIN format in the normal way.

Now back to the poster's reference:

You are indicating the RX01 bootstrap which is 30 words long.  This has zero
to do with RIM.  I believe that you are equating the fact that you toggle in
the RX boot, and the other poster toggles in a RIM loader.  They are for
quite different purposes.  His machine has only paper-tape as a peripheral,
while you have a floppy-disk-based machine, and you are toggling in the
code to bootstrap the O/S on floppy.  His machine must always have a paper-tape
loader available, since that's all he has available at that point.

BTW, the RIM loader is shorter than some of the boot sequences of certain
peripherals, so it's less hand work to toggle in the RIM loader, and boot
by reading in a short paper-tape of the longer boot.  The RIM loader is
in fact shorter than the RX01 or RX02 bootstraps (30 and 34 locations
respectively; I think your reference to 33 is to the octal value of where
to *start* the code, not the length, as both of these routines start at
0033.).  The RIM loader is 18 words long.

I know of one user who made a continuous loop of such a RIM program on a
model 33 Teletype.  The tape consisted of multiple copies of the RX boot
with the leader-trailer carefully glued together.  The machine was always
started with the RIM loader, and then the reader was manually enabled.  This
would read in one copy of the RX boot and start it up.  It was the standard
RX boot code augmented by a patch to the RIM loader itself to auto-start
the RX code.  (This machine actually had the MI8E Diode boot loader card,
but the contents was the RIM loader, not the RX01 bootstrap.)

BTW, there is a much shorter way to boot the RX01 than the DEC-supplied
bootstrap.  The reason is that the DEC bootstrap is longer than necessary
for two specific items:

1)    It attempts to boot on either drive 0 or drive 1.  Booting from
drive one may in fact be undesirable, but in any case, it is usually not
worth toggling in longer code just for this frill.

2)    Because of 1), the code doesn't take advantage of the self-test
that the drive performs every time power-clear occurs.  Since the boot
code starts with CLEAR, CONT (START on older machines), the self-test
always occurs, but is usable only on drive 0.  (Drive 1 is merely
recalibrated, but drive 0 is recalibrated and read as well.  The boot
code merely replicates what the self-test does, but supports doing so
on either drive.)

Thus, it is possible to toggle in a much shorter boot that expects the
power-clear-induced self-test to play an integral role in the boot process.

I can dig up this shorter boot, which I think was posted to pdp8-lovers
about a year ago.  I believe that version can be slightly trimmed as well,
but makes the code dependent on the CPU being an 8/e.  (Most are, but
the RX8E/RX01/02 or the DSD-210 equivalent can be placed in the DW8E, and
thus could be attached to a PDP-8 or LINC-8.  I believe the shortened version
depends on the proper execution of CLA CLL CML IAC RTL to load the AC with
0006, which can't work on those two machines; it would function on any
DW8E-P hooked to an 8/i, 8/l or -12 however.)

The DEC-standard RX01/02 boot code is 4 words longer than the RX01-only
version.  It not only boots either drive, it also attempts to load in
either density.  And it also functions on RX01.  However, because it is
longer than 32 words, it cannot be implemented on the MI8E Diode Loader
module, and thus is only an option of the 8/a boot card.  By paring the
code down, it is possible to write a version than *can* fit into 32 words
and thus could be implemented on the MI8E card.  This could be a version
that only supports drive 0, and possibly could require a front-panel
switches setting to select single versus double density.  Alternatively,
the front panel switches could select both the drive unit and the density
if there is enough room.

cjl