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

[Brian Knittel]

> I am running this on a recently purchased quad-core system that is rather
> fast. I have simh set up on a system that is much slower, so I will give
> that a try to see if there is a difference.

Hi Peter,

The speed of the *host* (Intel) processor should not be a factor. The 
timing in question is within the simulated machine -- the "virtual"
time between when a hardware device is given a command and when
the corresponding data is transferred or when the device interrupt
occurs. In SIMH the delay is typically specified as a number of 
simulated instructions. That is, a delay of 10 means an interrupt will 
occur after the simulated VAX CPU has executed 10 instructions. The 
default delay settings for each device are determined on an ad-hoc 
basis, and as I found while writing the IBM 1130 simulator, this can be 
a dicey thing.

Here's a hypothetical explanation of the problem: The VMS 4 driver 
initiates an operation, does a little housekeeping, then enters an idle 
loop waiting for the corresponding operation-complete interrupt. On 
real hardware, there was always enough time for the housekeeping work. 
But, in SIMH the interrupt occurs before the VMS driver enters the wait 
loop, and so the wait never ends because no further interrupts occur.

This is the "too fast" issue they're talking about. If this is the 
problem, then increasing the disk device's delay settings may well 
solve it. It looks like the RP device read and write delay is:

    RTIME + STIME * (# of cylinders being stepped)

where RTIME and STIME are both 10 by default. If the read head is 
already on the desired cylinder, a read operation completes when just 
10 VAX instructions have elapsed since it was initiated.

On real hardware, a read took, at the very least, enough time for the 
desired number of words to rotate past the read head. 10 instructions 
isn't very much time at all. I'd suggest setting RTIME to 1000 just to 
see if the boot succeeds:

   deposit RP RTIME 1000

then boot. If it works, try repeatedly halving it. Find the minimum 
value needed for a successful boot.

But the problem could be also due to a subtle difference in the way 
that interrupts are generated on the real hardware vs. the simulated 
hardware (for example, an interrupt that should be occurring isn't or 
vice versa), or in the way that the control registers work (as a 
hypothetical example, after a seek the driver examines the current-
cylinder register and expects to see it changing over time, whereas in 
SIMH the register changes instantly). The VMS 4 driver might be 
dependent on the exact behavior, while the other versions' drivers 
aren't. 

If this is the problem, it may require a change in the source code for 
the simulated device. Far trickier to do. The change would have to make 
VMS 4 work but not break the other VMS versions or the PDP-11 operating 
systems, which share the same RP device simulator code.

Brian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_| _| _|  Brian Knittel
_| _| _|  Quarterbyte Systems, Inc.
_| _| _|  Tel: 1-510-559-7930
_| _| _|  http://www.quarterbyte.com