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

[the keyboard of geoff goodfellow]

Bernie, one thing yours truly has always been curious of is when the
ARPANET was initially being rolled out, viz.:
http://som.csudh.edu/fac/lpress/history/arpamaps/press.jpg :

How were the first four IMPs (UCLA, SRI, UCSB & UTAH) managed/controlled
until the cross country link to IMP #5 to y'all at BBN was installed?
and
What was the length of time the initial 4 ARPANET IMPs "ran" without the
cross country link to IMP #5 in Boston?

geoff

On Sun, Sep 6, 2020 at 1:30 PM Bernie Cosell via Internet-history <
internet-history at elists.isoc.org> wrote:

> 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 --
>
>
>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True