[Simh] VMS 4.6 won't boot from a Massbus disk

Bob Supnik bsupnik at comcast.net
Wed Jan 26 07:44:37 EST 2011


I agree with Dave Hittner: the hang in booting VMS 4.6 from Massbus is either a timing problem, or a bug in replicating some small detail of the Massbus controller.

Because booting from an RA81 waits in the same place (but eventually succeeds), the "branch to self" loop where the simulator is waiting appears to be an idle loop, where VMS is waiting for some sort of event, like a disk interrupt. The disk interrupt may have occurred too soon and been lost (a problem which occurred in DEC PDP-11 operating systems and in BSD Unix as well). Or some detail that was unimportant in VMS 7.x mattered in VMS 4.x, such as the handling of attention interrupts versus data transfer interrupts.  For an example of the kinds of details that could go wrong, see http://simh.trailing-edge.com/docs/massbusmystery.pdf, which documents an error in the 7.X driver sources for these disks.

What would be most useful would be a VMS 4.X source set, but up until now, no one in the community has found one.  So here are some questions and ideas for debugging this problem.

1. Are you using the VMB (primary boot) image that comes with the 4.X series, or the default VMB image that comes with the simulator, which is from 7.2? While I don't know of any version skew issues, they could certainly exist. Does the same problem occur when booting with a 4.X VMB?

2. Does the hang occur in SYSBOOT (secondary boot), or in VMS proper? VMS runs at high virtual memory (8XXXXXXX), yet the branch to self is in low memory. If the hang is in SYSBOOT, the problem is likely to be easier to solve, as the environment is simpler. One thing to check: is memory management enabled?

3. Other users have reported success in getting early versions of VMS to run. I seem to recall that versions as far back as 1.5 have run successfully. Can we get a census of which versions have been successfully tested on the 780 booting from Massbus, and what version of VMB they use?

4. Both the Massbus controller (RH) and the device (RP) have debugging capabilities. You can log every register read and write to see how far the the controller gets.

5. As a last resort, zip up your RP disk image and post it to an uploading site, like Megaupload, so that others in the community can try their hand at the problem. You'll need to include not just the disk image, but configuration data, as well as any auxiliary files (such as an earlier VMB, if you use one).

/Bob Supnik





More information about the Simh mailing list