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 <[email protected]> Date: Wednesday, January 26, 2011 14:49 Subject: Re: [Simh] VMS 4.6 won't boot from a Massbus disk To: [email protected] > > 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 > [email protected] > http://mailman.trailing-edge.com/mailman/listinfo/simh >
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
