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

[Jason Stevens]

I recall this being a big deal for OpenBSD as well.....

And of course they just said, that it works on real hardware, it's not their
problem to fix, etc etc.....

On Wed, Jan 26, 2011 at 4:49 PM, Brian Knittel <brian at quarterbyte.com>wrote:

> > 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
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20110126/837df559/attachment-0002.html>