Subject: What I've got and what I'd like to have

From: [email-masked] (gordon hlavenka)
Date: 14 Nov 92 06:10:03 GMT

I have a pdp8/e.  Not just _any_ pdp8/e, either.  This is the unit
that was used to teach computer science to the students of York High
School in Elmhurst, IL.  The unit that introduced me (and many others)
to computers.  (One of the others was Sam Dicker, co-developer of the
popular arcade game Defender.  You out there, Sam?)  In its prime,
this machine ran BASIC timeshared between 4 ASR-33s, in 12K of core.
I graduated from York in '76, and they retired my old friend pidipity
a few years later.

I was in the Navy by then, and while on leave at home I went back to
York and bought the computer, an ASR-33, and every scrap of paper tape
they had in the district warehouse.  (I've heard of stuff like tape
drives and even disk drives for the pdp family, but REAL MEN don't use
such things! :-)

I took the machine back to the ship, (this machine later saw duty in
the Persian Gulf and the USSR!) and ordered all the manuals from
DEC.  These cost me about $400 at the time, but I have volumes 1, 2,
and 3 of the e/f/m Maintenance manual, the 8/e Illustrated Parts
Breakdown, and the pdp8/e Engineering Drawings.  Also the 1979 edition
of the PDP-8 Product Summary Catalog.  All originals.

I have a third- or fourth-generation photocopy of most (I think) of
the ASR-33 Teletype schematics.  (Wanna hear something real scary?   I
actually understand at least half of what goes on inside an ASR-33.
I'd like to see some hotshot QA guy run his reliability prediction
formulae on one of these puppies...)  I have most of the MAINDEC pdp-8
processor tests on paper tape -- original DEC tapes.  (No, not
DECTAPES)

My machine has 3 fields of core installed.  Two of these are working;
the third has one failed inhibit driver.  Gotta fix that one of these
days...

I have three extra M8650 current loop interface boards.  They were
working in 1979 when I unplugged them.

Supplies?  I've got a _lot_ of blank 1" paper tape.  A couple of cases
of DEC prefolded gray PDP tape, a bunch of yellow oiled rolls, and a
little pink, green, and black.

I'd like to have:
A copy of BASIC that works.  I have my EDUSYSTEM-20 BASIC tape from
the goodle days, but it doesn't run.  I need several switch handles
for the front panel (doesn't everybody?)  I'd be interested in a
source for ASR-33 ribbons and paper.  And all of the plastic
associated with the air filters in the desktop case has deteriorated,
so if someone has a spare (!) case floating around...

-- 
----------------------------------------------------
Gordon S. Hlavenka           [email-masked]
Vote straight ticket Procrastination party Dec. 3rd!

---

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: Mon, 16 Nov 1992 02:26:26 GMT

>From article <[email-masked]>,
by [email-masked] (gordon hlavenka):
> I have a pdp8/e.
	Me too, but not with any emotional connections.
> the ASR-33 Teletype schematics.
	I have originals of the schematics and maintenance manual.
> I have three extra M8650 current loop interface boards.
	I have a pile of these too -- but note, the 8650 can do RS232
	as well as current loop!  You can hook modern terminals to
	them at up to 2400 baud, and even faster if you use jumpers
	to points not advertised in the manual.  Read the extended
	comments in the board schematics for the M8650 to find out
	how to make the RS232 cable and how to jumper for higher
	speeds.
> Supplies?  I've got a _lot_ of blank 1" paper tape.
	I got cases and cased of oiled fanfold and roll tape, mostly
	black, but also a case of dark grey.  No DEC original tape,
	though.
> the goodle days, but it doesn't run.
	I have the EDUSYSTEM-30 user's guide (mark-sense batch BASIC),
	The EDUSYSTEM-10 user's guide (basic, but minimal), the
	EDUSYSTEM Produce Catalog, including an undated letter
	offering price quotes, circa 1971, and a copy of the
	Educational Program Index from the same era.  All are DEC
	originals.  Sorry I don't have the software itself.
> I need several switch handles
> for the front panel (doesn't everybody?)
	I don't know about everybody, but one "goldenrod" handle
	would do me a world of good.  (Goldenrod is the official
	DEC name for the yellow color that goes opposite terra
	cotta on the PDP-8/E front panel).
> I'd be interested in a
> source for ASR-33 ribbons and paper.
	I think it's a standard kind of cloth ribbon.  If worse comes
	to worse, the width of the ribbon is exactly standard, so al
	you have to do is wind a ribbon from whatever kind of spool
	you get onto the ASR33 spool.
> And all of the plastic associated with the air filters in the
> desktop case has deteriorated,
	Strip out the bad filters.  If your air is dirty enough to
	need filtering, go to a furnace store and look at the filter
	media they have to offer.  I've seen some "plastic" furnace
	filter material that's not too different from the DEC stuff,
	but thicker.  I assume it'd work well enough if you can get
	it to fit in the path of the airflow.  I've got a rack-mount
	system with no air filters (at least, none remaning) inside
	the rack.  The top-of-rack fan still has a filter, though,
	but just about anything can be stuffed there.

				Doug Jones
				[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: Mon, 16 Nov 1992 07:59:42 GMT

>	how to make the RS232 cable and how to jumper for higher
The M8650 is current loop at 110 baud if the crystal is 14.418 Mhz.  To make
it do the other rates, you have to change the crystal or even the whole
oscillator circuit to 19.6608 MHz, which is a fairly standard rate.  Then
the lowest baud rate is 150, not 110 baud.  The schematics show that the 
original card was designated to go up to 1200 baud only using a set of
neatly arranged split-lug jumpers, where one side of all of them is in
common.  Basically, you are picking off the proper divide-down output intio
the next stage, etc.  Then there was an ECO to add 2400 baud using another
similar pair, but located some distance from the 150,300,600,1200 jumpers.
But, if yo look at the schematic, there is the common run near the chip in
the upper right hand corner of the card, and pins on that chip are for
even faster outputs such as 4800, 9600, 19,200, 38,400, etc. and they
only need a short jumper, although not "neat" or "official".

You can also use the current-loop output for speeds faster than 110 baud,
but only if you remove (at least one end of) an electrolytic capacitor
being uses as a filter for the "dirty" input data of the tty commutator.
When removed, the rate can easily go to 9600 baud current-loop if needed.
On the KL8-JA card, a routine jumper change implements the same mod, but
you have to unsolder it here.

Also, note that the KL8E can go faster than the KL8-JA!  
Whether it's current-loop or RS-232 depends on the cable plugged in.  There
is a short designated current-loop connector that ends with a flat Mate'N'Lok
connector to a DEC current-loop terminal, and it has a jumper to enable the
current loop input on the module.  If it's RS-232, then you have to use the
BC01V or BC05C cables which implement an alternate jumper for the RS-232
input convertor.  The outputs are both driven so there is no need for an
output control jumper.

>	you get onto the ASR33 spool.

It's a standard ribbon for a rather ancient standard typewriter.

>	but just about anything can be stuffed there.

That urethane foam can be deadly when it flakes apart; better to vacuum it
all away, and go bare, but air conditioner filter is essentially the same
stuff, with perhaps a different "weave" and effective density, etc.

cjl

---

From: [email-masked] (gordon hlavenka)
Date: Mon, 16 Nov 1992 17:57:52 GMT

[email-masked] (Douglas W. Jones) writes:
> ... (Some good thoughts and a little commiseration) ...

>	but just about anything can be stuffed there.

Unfortunately, my problem is that the whole filter assembly is shot.
I'm less concerned about filtering the air than restoring the case.
The sheet metal is showing some rust but can be repainted.  All those
snap-in plastic things are broken, and it looks pretty sad.  (Works
great, though -- just like you'd expect from an 8/e :-)

---

From: [email-masked] (Victor-charles Scafati 4-6784 MR Srv)
Date: Tue, 17 Nov 92 16:10:50 GMT

In article <[email-masked]>, [email-masked] (gordon hlavenka) writes:
|>(I've heard of stuff like tape
|> drives and even disk drives for the pdp family, but REAL MEN don't use
|> such things! :-)
|> 

"REAL MEN" (and real women) don't use paper tape.  They use front panels.

|> -- 
|> ----------------------------------------------------
|> Gordon S. Hlavenka           [email-masked]
|> Vote straight ticket Procrastination party Dec. 3rd!

-- 
________________________________________________________________________________
                        |     The views expressed herein do not     |    Fear
 Victor-charles Scafati |   necessarily represent the views of the  |     no 
 [email-masked]  |  author, let alone his employer or client |    Art!
________________________________________________________________________________

---

From: [email-masked] (gordon hlavenka)
Date: Wed, 18 Nov 1992 04:16:02 GMT

>"REAL MEN" (and real women) don't use paper tape.  They use front panels.

Ah, yes...  I remember the contests we used to have, seeing who could
toggle in the RIM loader the fastest.  (That's probably one of the
reasons I need new switch handles :-)  I don't remember the record
time, but I used to be about average -- I'll time myself and see what
it comes out to.

---

From: [email-masked] (Victor-charles Scafati 4-6784 MR Srv)
Date: Wed, 18 Nov 92 16:57:58 GMT

In article <[email-masked]>, [email-masked] (gordon hlavenka) writes:
|>  [email-masked] (Victor-charles Scafati 4-6784 MR Srv) writes:
|> >"REAL MEN" (and real women) don't use paper tape.  They use front panels.
|> 
|> Ah, yes...  I remember the contests we used to have, seeing who could
|> toggle in the RIM loader the fastest.  (That's probably one of the
|> reasons I need new switch handles :-)  I don't remember the record
|> time, but I used to be about average -- I'll time myself and see what
|> it comes out to.
|> 
|> -- 
|> ----------------------------------------------------
|> Gordon S. Hlavenka           [email-masked]
|> Vote straight ticket Procrastination party Dec. 3rd!

Ah yes, 6016, 6011, 5027, 6016....  We used to compete on a PDP8/I which
had the smooth rocker switches rather than the toggle type.  The rockers
were far superior-  you could kind of "flow" down the switches rather
than flick up or down.  I have a PDP8/L, but I'd really like an PDP8/I
someday

---

From: [email-masked] (Jonathan E. Quist)
Date: Wed, 18 Nov 1992 19:47:20 GMT

>|> time, but I used to be about average -- I'll time myself and see what

Yep - the 8/I was my favorite, even at the expense of a slightly slower
instruction time than the other machines in the lab.  (Someone had added
pots to the system clocks - a couple times a year during PM they'd
tune the clock speed up as fast as the processor could handle it, then back
off a few percent.)  Aside from the rocker switches, my favorite part
was the full register display - made debugging that much easier.

RIM loader?  We never had to do that...  Just toggle in the network
bootstrap, then 7600, Load Address, Go.

All the PDP-8's I worked with were on a star network, with a pair
("Network Central") at the hub running the disks.  Years before anyone
thought up the term "file server".

And, of course, the first thing that the OS did when it booted was to
load the bootstrap into all available extended memory - if you only had
a minor crash, you could just select an alternate segment and boot
from there.

Question:  Was the network part of a standard OS, or was it just
something developed at Northwestern?  (The hardware looked homemade.
As I recall, it was a 40kword/sec network - add to that CRT terminals,
instead of the usual ASR's - pretty nifty.  Not to mention the system
with extra hardware for doing 4-channel realtime music synthesis, or
the one with the vectorscope display that did "Asteroids" years before
the game hit the arcades...)

My nomination for PDP-8.godhood:  Mr. Rich Karhuse.  Formerly head of
the Northwestern CS Research Lab; last I heard, working for Bell Labs.
I heard stories from several reliable sources that, upon discovering
a bug in the network central systems, he would halt the machines from
the front panel, toggle in the changes in memory and AC/L, then continue.
(And then, of course, document the fix... :')  From talking with him
on numerous occaisions, I have no reason to doubt the stories.
Rich, if you're out there, many thanks.  The environment you provided
was one of the single greatest influences on my professional skills.

These kids today just don't know what they're missing.
-- 
Jonathan E. Quist                              INTERACTIVE Systems Corporation
[email-masked]  '71 CL450-K4 "Gleep", DoD #094        Naperville, IL
        There are many things a person should experience in a lifetime.
       Among them are an infant's first cry, and an infant's first laugh.

---

From: [email-masked] (Charles Lasner)
Date: Thu, 19 Nov 1992 06:51:28 GMT

In article <[email-masked]> [email-masked] (Jonathan E. Quist) writes:
>In article <[email-masked]> [email-masked] (
>

Richard Karhuse was well known years ago to the PDP-8 world.  In all fairness,
I don't think he would put himself in the category you do, but was well known
for some really good stuff on the -8 and related peripherals.  Rich took a
bunch of us for a "tour" during one of the Chicago DECUS Symposiums around 1980
so I know all about that configuration.  It's partially based on stuff done
by others (me too), the largest being done in Atlanta by the people responsible
for documenting the early changes to Focal, 1969 emanating from Georgia Tech.
DEC actually published some of their stuff, although nothing about the
Local Area Networks of the day.  (Let's just say that at least 4 or 5 of us
simultaneously reinvented this wheel :-).  Some of us even had enough access
to carry it out in various institutions.)

Rich is best known in the "greater" -8 world for two related items:

A viable RX01 system and non-system handler that uses a kludge so that a
system can be built using the standard RX01 bootstrap in spite of the
fact that the handler format (8-bit) is incompatible with the proscribed
boot, which eventually was put into hardware.  There were other 8-bit
handlers, some produced merely to be compatible with other systems (WPS,
COS, etc.), but only Rich's was bootable.  (Part of this problem is caused
by limitations in the OS/8 system build process; in P?S/8 I had to invent
a special-purpose routine concept for initializing a system at system
generation time to overcome a parallel situation in P?S/8.)

The other thing has to do with the crux of a problem with virtually all
RX01/02 code:

Rich forced DEC to document the existence of the write-protect hardware of
the RX01, and made DEC write up the instructions to implement it in the
drive.  The RX01/RX02 pocket Reference Card page two now clearly shows
that bit[8] of the Error and Status Register means Write-Protect Error.
On drives Rich modified, etc., if you place a diskette in with the notch
area uncovered (this is backwards to newer floppies, but the identical
concept), the disk can't be written on.  These modified DEC drives do
implement this form of protection; reading the status register on the RX01
confirms the diskette is protected.

The problem is that before Rich's efforts to get the bit documented occurred,
DEC published a work of misinformation: the RX02 programmer's manual.  This
defective book claims that bit[8] of the register means "drive is RX02 type"
and is a 1 on all RX02, as if this was supposed to mean something useful.

The problem is that when you program an RX01 in 8-bit mode, you don't do
anything "special" to deal with it, yet if you want to read/write the 
same single-density diskette on an RX02, you are obliged to slightly change
the interface protocol.  Instead of just sending the command with the 8-bit
mode bit set, you are obliged to wait for the transfer flag to raise, then
to send an additional byte via the XDR instruction (0000 value, but it must
be sent, and on the RX01 it must be *not* sent).  Note that in 12-bit mode,
none of this applies, so generally it only comes up in special handlers,
conversion programs such as RTFLOP and WPFLOP, etc., while most standard
DEC handlers are devoid of esoteric error handling, thus have no concern
over these matters; their code runs equally (poorly) on RX01 or RX02.

So, guided by the misinformation in the manual, virtually all programmers
who wanted to support the RX02 inserted a test for RX02, consisting of
checking for this bit[8] being a one.  But this is *not* useful information
because:

1)	An RX02 operating as an RX02 is not the only case where this bit
sets.  An RX02 emulating an RX01 still sets this bit!

2)	An RX01 with the write-protect feature implemented shows this bit
if either the drive is not ready and has no diskette mounted, or has a
ready diskette with the notch hold uncovered, and thus protected from
writing.

3)	The DSD-210 RX01 superset supports all of the above, and also has
individual drive write-protect switches that supersede the write protects
of the media on a temporary basis.

So, software intending to "trust" this bit, generally fails to function 
when the hardware turns out to be other than an RX02 in native mode.

There has been tremendous resistance to these simple facts over the years, 
because people keep pointing to the info in the RX02 reference manaul as
"sacred" rather than a naive mistake.  Rich Karhuse helped to dispell this
set of mistakes, and thus allowed fixes to take place in other software.

The current P?S/8 system and non-system handlers partially consist of code
defensive to this issue.  IF a drive is suspected of being a write-protect
problem, the handler tests if the drive is actually an RX02, rather than a
lessor model where the RX01-type code is possibly usual, albeit in a more
inefficient manner.

Rich's work in getting to the truth of the situation has contributed to
the overall "quality" of the RX line, including RX50's on DECmates, etc.

cjl

---

From: asgard@sparky (J.R. Stoner)
Date: Thu, 19 Nov 1992 18:29:24 GMT

Victor-charles Scafati 4-6784 MR Srv ([email-masked]) wrote:
: In article <[email-masked]>, [email-masked] (gordon hlavenka) writes:
: |>  [email-masked] (Victor-charles Scafati 4-6784 MR Srv) writes:
: |> >"REAL MEN" (and real women) don't use paper tape.  They use front panels.
: |> 
: |> Ah, yes...  I remember the contests we used to have, seeing who could
: |> toggle in the RIM loader the fastest.  (That's probably one of the
: |> reasons I need new switch handles :-)  I don't remember the record
: |> time, but I used to be about average -- I'll time myself and see what
: |> it comes out to.
: |> 
: |> -- 
: |> ----------------------------------------------------
: |> Gordon S. Hlavenka           [email-masked]
: |> Vote straight ticket Procrastination party Dec. 3rd!
: 
: Ah yes, 6016, 6011, 5027, 6016....  We used to compete on a PDP8/I which
: had the smooth rocker switches rather than the toggle type.  The rockers
: were far superior-  you could kind of "flow" down the switches rather
: than flick up or down.  I have a PDP8/L, but I'd really like an PDP8/I
: someday

Um, nope.  Mine was 33 words long and started: 7126, 1060, 6755...
You must have been using a different RIM that I did.
--
J.R. Stoner, DWMIT - [email-masked] - sun.com!plx!plxsun!asgard

---

From: [email-masked] (Charles Lasner)
Date: Sun, 22 Nov 1992 11:08:59 GMT

>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

---

From: [email-masked] (Bruce M. Walker)
Date: 23 Nov 92 01:19:11 GMT

In article <[email-masked]> asgard@sparky (J.R. Stoner) writes:
> : Ah yes, 6016, 6011, 5027, 6016....
> 

You must have been using a different Rim than *any* of us :-)

Not to put too fine a point on it; here are the two I remember(*) most:

             Rim Loader

     Low speed       High Speed
       (TTY)      (paper-tape reader)

7756/   6032            6014
        6031            6011
        5357            5357
        6036            6016
        7106            7106
        7006            7006
        7510            7510
        5357            5374
        7006            7006
        6031            6011
        5367            5367
        6034            6016
        7420            7420
        3776            3776
        3376            3376
7775/   5356            5357

---
*  Or, how I would have remembered, if I hadn't forgotten :-)  I cheated
   and copied them off the back of my "pdp8/e instruction list" [DEC
   started the lower-case revolution even before Ken Thompson].

--
"Eventually, I decided that thinking was not getting me very far and it
 was time to try building."           -- Rob Pike, The Text Editor sam
      [email-masked]   [ ...!uunet.ca!isgtec!bmw ]  Bruce Walker

---

From: [email-masked] (Victor-charles Scafati 4-6784 MR Srv)
Date: Tue, 24 Nov 92 14:21:07 GMT

In article <[email-masked]>, [email-masked] (Bruce M. Walker) writes:
|> In article <[email-masked]> asgard@sparky (J.R. Stoner) writes:
|> > Victor-charles Scafati 4-6784 MR Srv ([email-masked]) wrote:
|> > : Ah yes, 6016, 6011, 5027, 6016....
|> > 
|> > Um, nope.  Mine was 33 words long and started: 7126, 1060, 6755...
|> > You must have been using a different RIM that I did.
|> 
|> You must have been using a different Rim than *any* of us :-)
|> 
|> Not to put too fine a point on it; here are the two I remember(*) most:
|> 
|> 
|>              Rim Loader
|> 
|>      Low speed       High Speed
|>        (TTY)      (paper-tape reader)
|> 
|> 7756/   6032            6014
|>         6031            6011
|>         5357            5357
|>         6036            6016

In the interest of ending this thread, I have to admit, those sound pretty
familiar.  Ok, so it's been 15 year, my memory is fading- so sue me!

You have to admit, I was pretty close on the High Speed Reader...

I would have gotten it right if I'd had a PDP8/I front panel to diddle, 
yea, that's it...

---

From: [email-masked] (Charles Lasner)
Date: Tue, 24 Nov 1992 20:42:49 GMT

>You must have been using a different Rim than *any* of us :-)

As I pointed out, he doesn't understand the difference between *something*
being toggled in, and the RIM loader being toggled in.

In his case, it's the RX01 bootstrap that starts loading at 00024 and is 
started at 00033 after a power-clear.

>       (TTY)      (paper-tape reader)

Note that 7776 is the pointer for storing data through, thus isn't loaded
by the toggle-in code.

7777 is reserved also: it is the JMP to the actual start of the BIN loader
which loads into locations before 7756.  Since there are different versions
of the BIN loader, the convention is to start at 7777 and JMP to whatver
you have to, etc.

A comment on the standard code above:

Note that in 7765 there is a different instruction depending on which
loader is used.  (All other changes are merely to use the I/O instructions
for either the teletype or high-speed reader.)

In the TTY: version, it's a JMP back to the top of the routine.  The reason for
this is that the first loop uses 6036, which loads the AC, thus the old 
contents while waiting for the leader to finish get wiped out when the 6036
is executed for what follows the leader.

In the RDR: version, it's a JMP to the bottom of the routine.  Effectively,
it stores the shifted leader code into 7776, and then effectively goes
to the same loop at the top as in the TTY: version.

The point is that this JMP to 7774 can be the same in *both* versions.

In P?S/8, my proprietary system for the -8, there is an option for a BIN
and RIM loader to be put into the usual places.  I use the form stated, 
meaning with that one word always set to the value that works for either
reader.  If the command is:

.BIN /P/R

Then you get the TTY: version (with the one word changed)

.BIN /P/R/F

gets you the standard high-speed reader version.

BTW, I have managed to squeeze the BIN loader down to 7643-7755.  The P?S/8
command

.BIN /P

gives you a TTY: BIN and RIM loader and starts the BIN loader

.BIN /P/F

gives you a high-speed reader BIN and RIM loader and starts the BIN loader.
(The RIM loader start is signified by /R; actually both loaders are
put into memory together.  The /P indicates paper-tape loading; ordinarily
the BIN program is used to load system binary files.  If the /P switch
is given as well as files, then the binary is punched.  If /F is given then
it is punched on the high-speed punch.  If /R is also given, then the
output is punched in universal RIM format with the "sacrifical" origin
setting past the last loaded word to avoid corrupting the code with the
checksum generated for compatibility with the BIN loader.)

The JMP at 7777 is a valid JMP to the new start address.  This version of
BIN supports everything, including the rubout-character-bracketed error
messages of paper-tape assemblers that might get interspersed in the
binary output if the tape was prepared on the Teletype, and you still wanted
to load the binary in spite of the assembler errors.  This is a standard
feature, but not all of DEC's loaders support it (the self-starting binary
loader does not).

The only feature not supported is that, like the RIM loader, you must
choose in advance whether you want the low or high-speed version.  The
DEC version reads the console switches for a "dynamic" decision, yet I
doubt if anyone is complaining about the inability to switch reader devices
in the middle of a multi-tape load :-).

So, by eliminating the switch control (which is appropriate for a loader
which is optionally brought into memory from a disk-based O/S when you want
to kick the O/S out of memory for some stand-alone stuff, such as
diagnostics, etc.), and squeezing the hell out of the rest of the code,
the page is occupied from 7643-7777 only.  This allows 7600-7642 to be
available for a bootstrap back to the O/S by starting at 7600.  Admittedly
there are some programs that wipe out 07600 or so, since they "know" the
BIN loader isn't there, but for "well-behaved" programs, this means that
you can reload the O/S in most cases without having to toggle in a disk
reboot, etc.  (A known sort point: the RANISZ diagnostic loads a few words
in 07600-07604 or so.)

A word of warning!

The self-starting binary loader has a serious design problem:

When a field setting appears in the binary tape, it is erroneously acted
upon too soon, i.e., the last loaded location to be loaded in the
previous field is instead loaded into the new field!  There is no fix
for this.  (You need to "double-buffer" the frames, and all *working* BIN
loaders do that.  But the self-starter "forgot" about that!)  Some diagnostic
tapes are aware of the problem, and fix the problem by having an extraneous
origin setting before the field setting, just after any loaded data.  The
origin becomes to the correct location in the wrong field, but since no
data is associated with it, it's harmless.  After the field setting is
processed, the new data is correctly loaded into the new field, etc.

Aware of this problem, the programmers of several things such as 8K BASIC
chose instead to require a specific version of BIN to load the program.
The binary of 8K BASIC will attempt to patch over the loader!  It makes the
loader JMP into some just-read-in code (not yet checksummed!) where it then
patches the end-of-load routine to JMP to some other code, so that the
program itself can decide to start itself if the load went OK.  If the
load got a checksum failure, then the intercepting code restores the BIN
loader for a retry.

The obvious question: If there was a checksum failure, how do we know
that these intercepting kludges are themselves loaded correctly?

cjl

---

From: [email-masked] (Charles Lasner)
Date: Tue, 24 Nov 1992 20:46:25 GMT

>familiar.  Ok, so it's been 15 year, my memory is fading- so sue me!

No flames here; you are merely mixing up what you toggled.  It's perfectly
reasonable for someone to have at one point needed to toggle in a RIM loader
and at another time toggle in a disk boot.

>I would have gotten it right if I'd had a PDP8/I front panel to diddle, 

That's cheating, since the code is emprinted *on* the panel!

cjl