Brian, Thanks for putting me right on the speed issue. I will have a go at it this weekend.
Peter On 26 January 2011 21:49, Brian Knittel <[email protected]> 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 > [email protected] > http://mailman.trailing-edge.com/mailman/listinfo/simh >
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
