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


_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to