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

[Villy Madsen]

Brian your post reminded me of an issue that arose when I first started playing with shadow sets on my emaulated VAX.

During the building of (or rebuilding of later) the shadow sets, the CPU (VAX) would be just about pegged - very very slow to respond to anything until the shadow sets were rebuilt.  I put it down to the fact that the modern drives were just too darn fast to complete their IO...

I was temped to make changes in the disk drivers just to see what would happen, but decided that it wasn't worth the effort......

Villy



----- Original Message -----
From: Brian Knittel <brian at quarterbyte.com>
Date: Wednesday, January 26, 2011 14:49
Subject: Re: [Simh] VMS 4.6 won't boot from a Massbus disk
To: simh at trailing-edge.com

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