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

[Peter Allan]

Brian, thanks for your advise. Changing the value of RTIME has indeed got
VMS 4.6 to boot on my emulated VAX 780, which is terrific.

I started by setting RTIME to 1000, as suggested and I decreased the value
until the system no longer booted. The smallest value I could use was 26.

The system now boots very quickly and there is only about 1 second between
the message

   VAX/VMS Version V4.6  6-Jul-1987 17:00

appearing and the boot sequence finishing. In fact, I could detect no
difference between the speed of the emulated system whether I set RTIME to
26 or to 1000, although all I am doing at present is booting the system and
typing a few simple commands like SHO DEV D.

I realised this is a lot faster than booting from an RA81, which has always
worked, but takes about 10 seconds from the above message appearing to
completing the boot process. Both systems are clean installs with nothing in
the startup .COM files yet.

My current configuration is:
   One RP06 disk containing VMS 4.6
   One RA81 containing VMS 4.6
   One RD53 containing stand alone backup 4.6.

I discovered that when I boot from the RP06 system disk, the MSCP disks are
not recognised and are not available after the system has booted.

Right now, I am not to bothered about the MSCP disks not being recognised if
the system disk is a Massbus one, but I bet I will be at some time in the
future. I tried changing the RQ disk parameters ITIME, QTIME and XTIME, but
the little playing that I did did not result in the MSCP disks appearing
after the system booted.

Anyone got any bright ideas about this problem?

Peter Allan



On 26 January 2011 21:49, 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/20110129/1f99d25b/attachment-0002.html>