[ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ]

[Bernie Cosell]

Let me add a little bit to Jack's explorations.  There are two things of interest we 
put in the IMP code that relates to this.  The first was the DDT/TTY machinery 
and other was the "reload from your neighbor" machinery.

I remember that first quite well, since I mostly designed it [we did 
EVERYTHING as a team so we coöperated and sorted stuff out together] and I 
implemented it [so I was really responsible for the complicated machinery that 
made this aspect of the IMP work]:

Early on as we were coding the IMP stuff the question arose as to what to do 
about the TTY [and how the hell were we to debug the damn thing].  We did 
several things in this regard.  First I wrote a simple DDT [about as powerful as 
the test-word switches on our PDP-1 :o)] but it allowed us to poke around in the 
dead hulk of the code of a stopped system to see what went wrong and also put 
patches in.  I believe it was originally a stand alone - the imp would crash or hit a 
diagnostic trap and they we could run the DDT and look at buffers and counters 
and pointers and such and generally try to figure out what happened.  When the 
IMP was running solidly enough [which actually happened pretty early on in its 
development],   I can't remember the genesis of the underlying idea, but  we 
thought we could route the DDT *over* the net to other IMPs and poke at *then*.
I came up with a scheme that Will [I think] thought was way too complicated: 

   1) connect the DDT to the IMP as a "fake host",
&2) connect the TTY to the IMP as another "fake host"

With those now residing *in* the IMP, instead of apart from it we got a bunch of 
benefits:
    1) we could run the DDT *while* the IMP was up doing its thing, and
   2) we could interrogate a *different* IMPs DDT [simply by pointing the TTY to 
the appropriate fake host on the other IMP.
   3) We could "IM" between machines [simply by pointing the TTY to the *TTY* 
on the other machine.

[on (3) that ability was very handy as Ben and Marty were bringing up IMPs 1&2.  
They knew, for example, long before any of the host interface and machinery was 
working, that the IMP was doing just fine, since they could exchange messages 
and *knew* it used the same code that the hosts would be using.  It also replaced 
lots of long-distance calls to coördinate what was happening at SRI and UCLA]

WE also had the IMPs send "health reports" [via a background process] and they 
were hard wired to send to the IMP 5 TTY and so virtually from the outset we 
could monitor [and with the DDT tweak] the whole network.   Until the PDP-1 
was online it chewed up a fair bit of paper :o)

It was all using the basic IMP packet-handling machinery, so that two IMPs 
could be poking the DDT on a particular IMP and not interfere with one another.    
When the PDP-1 came online as the first proto-NCC, the DDT was as happy to 
talk to a real host as one of its fake brethrens and ditto for the "health reports" 
that just changed which host they were going to and it all worked.  So everything 
was fitting together very nicely and very usefully [despite the complicated code]

A conceptually neat part about all this is that the *internals* of the IMP were 
host-agnostic.   They didn't care if they were fake or real, they just sent the 
packets where there were supposed to go.   and so we could implement "satellite"
activities that used the underlying IMP code to do other useful things  beyond 
just host-to-host.

Expanding this principle a few years later, we had a H316 that had *two* 16k 
banks.  [and I think I've mentioned this before on this list].  We decided to 
implement the TIP as, what else?? :o), a host.  But in this case it was a 
pseudo-real-host [as I've mentioned before]  this was done so that the TIP code 
could live in the upper memory bank and its "host interface" transferred data and 
control across the boundary.  The IMP didn't need to know or care that the TIP
was there.

Phew.   now to the second mechanism: reloading from a neighbor.   Maybe dave 
remembers this better than I do but I think that one of the things we did as the 
IMP got more solid was removed its "loader" [which could boot the machine 
from paper tape] and replaced with with something that could live in 20 words 
[which was where the paper tape loader lived: in shadow memory behind the 
registers]   I think that that code was *just* enough of a bootstrap to send 
message to a neighboring IMP and the first thing that IMP sent over a smarter 
loader that than received a whole memory-full of IMP code from the neighbor 
and then started the neighbor up.   I believe we could trigger this remotely via 
DDT and so if the IMP was up but just in need of an updated version it could 
suck it in from its neighbor.

My opinion is that hacking in this kind of stuff [and piggybacking "services" on 
top of the IMP's 'day job' of handing real host data] helped a lot in the ARPAnet 
being virtually "operational" [and manageable] from the start.

  /Bernie\
            Bernie Cosell
       bernie at fantasyfarm.com
-- Too many people; too few sheep --