Further experiments show that the detection of the MSCP disks is inconsistent. I have just built a VMS 4.6 system from scratch on an RP06 system disk with a configuration of 2 x RP06, 2 x RM05, RA81, RD53. After installing the mandatory update for VMS 4.6 I could see the MSCP disks. After a reboot I could not. After the next reboot I could!!!
Peter On 29 January 2011 14:01, Peter Allan <petermal...@googlemail.com> wrote: > Brian, thanks for your advise. Changing the value of RTIME has indeed got > VMS 4.6 to boot on my emulated VAX 780, which is terrific. > > I started by setting RTIME to 1000, as suggested and I decreased the value > until the system no longer booted. The smallest value I could use was 26. > > The system now boots very quickly and there is only about 1 second between > the message > > VAX/VMS Version V4.6 6-Jul-1987 17:00 > > appearing and the boot sequence finishing. In fact, I could detect no > difference between the speed of the emulated system whether I set RTIME to > 26 or to 1000, although all I am doing at present is booting the system and > typing a few simple commands like SHO DEV D. > > I realised this is a lot faster than booting from an RA81, which has always > worked, but takes about 10 seconds from the above message appearing to > completing the boot process. Both systems are clean installs with nothing in > the startup .COM files yet. > > My current configuration is: > One RP06 disk containing VMS 4.6 > One RA81 containing VMS 4.6 > One RD53 containing stand alone backup 4.6. > > I discovered that when I boot from the RP06 system disk, the MSCP disks are > not recognised and are not available after the system has booted. > > Right now, I am not to bothered about the MSCP disks not being recognised > if the system disk is a Massbus one, but I bet I will be at some time in the > future. I tried changing the RQ disk parameters ITIME, QTIME and XTIME, but > the little playing that I did did not result in the MSCP disks appearing > after the system booted. > > Anyone got any bright ideas about this problem? > > Peter Allan > > > > On 26 January 2011 21:49, Brian Knittel <br...@quarterbyte.com> 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 >> Simh@trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh >> > >
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh