> 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@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh