[ih] Intel 4004 vs the IMP

Noel Chiappa jnc at mercury.lcs.mit.edu
Tue Nov 16 09:16:57 PST 2021


    > From: Jack Haverty

    > in particular a "watchdog timer"

The TIU (BTW, I have an announcement about the recovery of its source and
documentation, which I'll get to after the list quiets down) also had a
watchdog timer board. (We used those boards on the MIT routers, with different
code; I'm not sure if anyone else did, e.g. BBN QBUS routers. The idea was
carried over to the Proteon p4200, and probably still exists in other routers
today.)

The TIU one had a less restricted operating environment, since the PDP-11
reserved a small block of address space for bootstrap ROM, and the machine
could be set to jump to that on reset. (For larger bootstrap codes, PDP-11's
often hid the larger code in ROM behind a 'window', and the initial code
copies it out to main memory to run it. I can't remember if the TIU one did
that.)

Which shows again the need to carefully examine all areas of a target machine's
functionality to assess its suitability.

 
    > So at some point, the instruction that the IMP was executing would be
    > overwritten by whatever instruction lived at that memory address in the
    > IMP code release coming from the neighbor. It seems that this was
    > handled by programmer discipline

The IMP custom hardware documentation:

  https://walden-family.com/impcode/imp-hardware.pdf

indicates (page 4-6) that it had the ability to write-protect protect the
watchdog interrupt vector, and also 'sector 1' of main memory (which
presumably, said vector could be set to point to). I'm not sure if this
capability was also utilized to make reload more robust (i.e. to protect the
'JMP .')

Certainly the IMPs were enormously robust against 'brain freeze'; in several
years as the liaison for the MIT IMPs, I don't recall ever having to manually
restart one.


    > Could the 4004 do it

I think I've already answered this: 'probably not'. (And as an
implementer of early routers, I think I have the detailed knowledge to make
this assessment.) To re-state my reasoning, which apparently got missed, the
maximum amount of RAM it could address was about 650 bytes - enough for only
a single packet buffer. I don't think one could build a viable router with
only a single packet buffer: e.g. if a packet started arriving on one
interface, all the others would have to be shut off.

Although one could probably have bodged up some sort of bank switching
hardware arrangement which allowed the CPU to only 'see' a single packet
buffer at a time, to partially get around that. (The PDP-11/23 variant of the
CGW did exactly that, so that approach worked - including as the main Stanford
ARPANET gateway for some years - although it kind of depended on having DMA
network interfaces which could 'see' all the packet buffers all the time;
supporting a DMA interface which could only 'see' the bottom 64KB of memory
took some contortions in the code.) Non-DMA interfaces, where the CPU had to
get invlved in moving data, would similarly have been an issue - lots of bank
swithing going on; but such interfaces would have been throughput bottlenecks
_anyway_.

It would have depended on what the performance goals were, what kind of
monetary budget one had for add-on work-around hardware ('an engineer is
someone who can do for $.5 what any fool can do for $2'), etc.

Also, it's not worth looking too hard at the 4004, when the 8008 (available
_very_ shortly after the 4004) was considerably more capable. (I never worked
with 8008's BITD, but the programmer's front panel for the PDP-11/04&34 used
them, and in debugging some panels recently I read a lot of the code, so I now
know a tiny bit about them.) Their address space was still pretty small (16KB,
but I'm not sure if that was ROM and RAM, or just ROM, like the 4004), but it
was probably enough for a rudimentary router. Especially if one could spend on
bank-switching, which was used very sucessfully in a number of early DEC
machines, including the very successful PDP-8 (from the original 'straight 8',
all the way on).

	Noel



More information about the Internet-history mailing list