Brian your post reminded me of an issue that arose when I first started playing with shadow sets on my emaulated VAX.<br><br>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...<br><br>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......<br><br>Villy<br><br><br><br>----- Original Message -----<br>From: Brian Knittel <brian@quarterbyte.com><br>Date: Wednesday, January 26, 2011 14:49<br>Subject: Re: [Simh] VMS 4.6 won't boot from a Massbus disk<br>To: simh@trailing-edge.com<br><br>> > I am running this on a recently purchased quad-core system <br>> that is rather<br>> > fast. I have simh set up on a system that is much slower, so I <br>> will give<br>> > that a try to see if there is a difference.<br>> <br>> Hi Peter,<br>> <br>> The speed of the *host* (Intel) processor should not be a <br>> 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 <br>> interrupt will <br>> occur after the simulated VAX CPU has executed 10 instructions. <br>> The <br>> default delay settings for each device are determined on an ad-<br>> hoc <br>> basis, and as I found while writing the IBM 1130 simulator, this <br>> can be <br>> a dicey thing.<br>> <br>> Here's a hypothetical explanation of the problem: The VMS 4 <br>> driver <br>> initiates an operation, does a little housekeeping, then enters <br>> an idle <br>> loop waiting for the corresponding operation-complete interrupt. <br>> On <br>> real hardware, there was always enough time for the housekeeping <br>> work. <br>> But, in SIMH the interrupt occurs before the VMS driver enters <br>> 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 <br>> the <br>> problem, then increasing the disk device's delay settings may <br>> 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 <br>> is <br>> already on the desired cylinder, a read operation completes when <br>> 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 <br>> for the <br>> desired number of words to rotate past the read head. 10 <br>> instructions <br>> isn't very much time at all. I'd suggest setting RTIME to 1000 <br>> 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 <br>> minimum <br>> value needed for a successful boot.<br>> <br>> But the problem could be also due to a subtle difference in the <br>> way <br>> that interrupts are generated on the real hardware vs. the <br>> simulated <br>> hardware (for example, an interrupt that should be occurring <br>> 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 <br>> current-<br>> cylinder register and expects to see it changing over time, <br>> whereas in <br>> SIMH the register changes instantly). The VMS 4 driver might be <br>> dependent on the exact behavior, while the other versions' <br>> drivers <br>> aren't. <br>> <br>> If this is the problem, it may require a change in the source <br>> code for <br>> the simulated device. Far trickier to do. The change would have <br>> to make <br>> VMS 4 work but not break the other VMS versions or the PDP-11 <br>> operating <br>> systems, which share the same RP device simulator code.<br>> <br>> Brian<br>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<br>> _| _| _|  Brian Knittel<br>> _| _| _|  Quarterbyte Systems, Inc.<br>> _| _| _|  Tel: 1-510-559-7930<br>> _| _| _|  http://www.quarterbyte.com<br>> <br>> _______________________________________________<br>> Simh mailing list<br>> Simh@trailing-edge.com<br>> http://mailman.trailing-edge.com/mailman/listinfo/simh<br>>