This summer a group of us worked together to resurrect the original ARPAnet IMP software, and I’m now happy to say that the IMP lives again in simulation. It’s possible to run the original IMP software on a modified version of the H316 simh and to set up a virtual network of simulated IMPs talking to each other. IMP to IMP connections, which would have originally been carried over leased telephone lines, are tunneled over IP. As far as we can tell, everything works pretty much as it did in the early 1970s. IMPs are able to exchange routing information, console to console communications, network statistics, and they would carry host traffic if there were hosts on the network. The hooks are in there to allow simh to support the IMP side of the 1822 host interface, and the next step would be to recover the OS for an ARPAnet era host and then extend the corresponding simulator to talk to the IMP simulation.
Note that this is not the fully general Massbus implementation people were dreaming of. MB#1 is for RP/RM, MB#2 is for TU, and MB#3 is for RS.
I know that there were requests for four Massbus channels and multiple RP/RP subcontrollers, but if people want more disks, they can use the RQ.
- Added validation checks in auto_config to reject enabled devices which aren't Q22 capable on Q22 platforms.
- Changed pdp11_cr device to be default disabled in the PDP11 simulator
It also modifies the HP 2100 and PDP11 multiplexers to add serial support as demonstrations of the capability that, one day, might be extended to all simulators. I have tested the HP support, but I relied on Holger Veit to test the DEC stuff, so I can't guarantee that it works. I also relied on Holger to test under Linux, so the same caveat applies.
The changes needed in the device simulators are relatively small. For example, if you look at the patches for "hp2100_baci.c", you'll note that most of them are documentation changes. The only things of note are:
- an expansion of the TMXR initializer
- additional code in the "attach" routine to try attaching a serial port
if attaching a socket fails
- additional code in the "detach" routine for the same reasons
The HP MPX device (hp2100_mpx.c) needs a tiny bit of additional support from the ATTACH and DETACH commands. Specifically, SCP was modified to set a flag ("sim_unit_ref") to indicate whether ATTACH MPX or ATTACH MPX0 was done, i.e., to differentiate between a device and a unit attach (recall that SCP treats these as both referring to unit 0). This is needed because the socket attaches (logically) to the device, whereas a serial port attaches to a line. Without this flag, the attach routine cannot differentiate between ATTACH MPX and ATTACH MPX0, as the distinction is lost by the time the VM's attach routine is called. This support isn't needed for the HP MUX device because the socket attaches to a different device than the lines do.
MPX also requires a bit more work due to the capability to mix serial and Telnet lines on the same multiplexer (BACI is a single-line terminal device).
The attached PDF contains revisions to the "Writing a Simulator for the SIMH System" publication that documents the additions and changes to the multiplexer library for serial port support. User documentation for serial port support currently exists only in the initial comments in "sim_tmxr.c"; I will add the appropriate text to the "SIMH User's Guide" if we decide to add this to the release version.
- Removed flawed logic which assumed that sim_interval was meaningful when referenced by an asynchronous thread.
- Adjust the event_time of events removed from the asynch queue to account for the average time spent on the queue before the event was noticed by the instruction execution thread.
- Added a sim_activate_notbefore function which specifies an rtime which is the earliest time the event should fire.
- Changed the 'wakeup from idle' logic to force an immediate asynch queue check if the wakeup was not due to a timeout (i.e. it was due to an asynch queue insertion).
- Fixed the descrip.mms to build asynchronous support on AXP and IA64 VMS with kernel threads enabled
This allows a single simulator executable to be a completely useful component (for those simulators which dynamically load ROM or other boot code).
Meanwhile, we continues to allow the explicit use of a user's preferred ROM or other boot code as well.
A build option is provided in the makefile to not build with the included ROM functionality if desired.
