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

[Peter Allan]

Further experiments show that the detection of the MSCP disks is
inconsistent. I have just built a VMS 4.6 system from scratch on an RP06
system disk with a configuration of 2 x RP06, 2 x RM05, RA81, RD53. After
installing the mandatory update for VMS 4.6 I could see the MSCP disks.
After a reboot I could not. After the next reboot I could!!!

Peter


On 29 January 2011 14:01, Peter Allan <petermallan at googlemail.com> wrote:

> 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/a5f1b882/attachment-0002.html>