I recall this being a big deal for OpenBSD as well.....<div><br></div><div>And of course they just said, that it works on real hardware, it's not their problem to fix, etc etc.....<br><br><div class="gmail_quote">On Wed, Jan 26, 2011 at 4:49 PM, Brian Knittel <span dir="ltr"><<a href="mailto:brian@quarterbyte.com">brian@quarterbyte.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> I am running this on a recently purchased quad-core system that is rather<br>
> fast. I have simh set up on a system that is much slower, so I will give<br>
> that a try to see if there is a difference.<br>
<br>
</div>Hi Peter,<br>
<br>
The speed of the *host* (Intel) processor should not be a factor. The<br>
timing in question is within the simulated machine -- the "virtual"<br>
time between when a hardware device is given a command and when<br>
the corresponding data is transferred or when the device interrupt<br>
occurs. In SIMH the delay is typically specified as a number of<br>
simulated instructions. That is, a delay of 10 means an interrupt will<br>
occur after the simulated VAX CPU has executed 10 instructions. The<br>
default delay settings for each device are determined on an ad-hoc<br>
basis, and as I found while writing the IBM 1130 simulator, this can be<br>
a dicey thing.<br>
<br>
Here's a hypothetical explanation of the problem: The VMS 4 driver<br>
initiates an operation, does a little housekeeping, then enters an idle<br>
loop waiting for the corresponding operation-complete interrupt. On<br>
real hardware, there was always enough time for the housekeeping work.<br>
But, in SIMH the interrupt occurs before the VMS driver enters the wait<br>
loop, and so the wait never ends because no further interrupts occur.<br>
<br>
This is the "too fast" issue they're talking about. If this is the<br>
problem, then increasing the disk device's delay settings may well<br>
solve it. It looks like the RP device read and write delay is:<br>
<br>
    RTIME + STIME * (# of cylinders being stepped)<br>
<br>
where RTIME and STIME are both 10 by default. If the read head is<br>
already on the desired cylinder, a read operation completes when just<br>
10 VAX instructions have elapsed since it was initiated.<br>
<br>
On real hardware, a read took, at the very least, enough time for the<br>
desired number of words to rotate past the read head. 10 instructions<br>
isn't very much time at all. I'd suggest setting RTIME to 1000 just to<br>
see if the boot succeeds:<br>
<br>
   deposit RP RTIME 1000<br>
<br>
then boot. If it works, try repeatedly halving it. Find the minimum<br>
value needed for a successful boot.<br>
<br>
But the problem could be also due to a subtle difference in the way<br>
that interrupts are generated on the real hardware vs. the simulated<br>
hardware (for example, an interrupt that should be occurring isn't or<br>
vice versa), or in the way that the control registers work (as a<br>
hypothetical example, after a seek the driver examines the current-<br>
cylinder register and expects to see it changing over time, whereas in<br>
SIMH the register changes instantly). The VMS 4 driver might be<br>
dependent on the exact behavior, while the other versions' drivers<br>
aren't.<br>
<br>
If this is the problem, it may require a change in the source code for<br>
the simulated device. Far trickier to do. The change would have to make<br>
VMS 4 work but not break the other VMS versions or the PDP-11 operating<br>
systems, which share the same RP device simulator code.<br>
<br>
Brian<br>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<br>
<font color="#888888">_| _| _|  Brian Knittel<br>
_| _| _|  Quarterbyte Systems, Inc.<br>
_| _| _|  Tel: 1-510-559-7930<br>
_| _| _|  <a href="http://www.quarterbyte.com" target="_blank">http://www.quarterbyte.com</a><br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Simh mailing list<br>
<a href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a><br>
<a href="http://mailman.trailing-edge.com/mailman/listinfo/simh" target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a><br>
</div></div></blockquote></div><br></div>