Re: [Simh] VMS 4.6 won't boot from a Massbus disk
On 29 January 2011 14:33, Wilm Boerhout wrote: > Peter Allan mentioned on 29-1-2011 15:01: > > 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 >> > > I do not have a V4.6 system at hand, but consider this general principle: > if you boot VMS from a cloned or freshly installed system disk, it is > beneficial to run AUTOGEN, after checking MODPARAMS.DAT for anomalies. Could > it be that when booting from a MASSBUS device, the MSCP driver is not > automatically loaded? Not sure if V4.6 supports this, but try setting > MSCP_LOAD=1 in MODPARAMS.DAT, and AUTOGEN the system. Later versions of VMS > have the SYSGEN command SHOW MSCP_LOAD, SHOW MSCP_SERVE_ALL, not sure if > V4.6 has this. > > It may also take some time for the CONFIGURE process to enumerate all > disks. Is the configure process started at all when booting from MASSBUS? > Otherwise, @SYS$SYSTEM:STARTUP CONFIGURE will do so. > > /Wilm Thanks Wilm, The @SYS$SYSTEM:STARTUP CONFIGURE command does indeed configure the DUA0 and DUA1 disks. My system is definitely inconsistent in bringing them up without this. It seems to recognise them about 1 time in 3 or 4 boots, but more often than not it does not do so. I have not been able to detect any consistency in what causes the system to work when it does, so I will use the command above when I need to. Cheers Peter > > ___ > 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
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
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 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 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 d
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
Peter Allan mentioned on 29-1-2011 15:01: 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 I do not have a V4.6 system at hand, but consider this general principle: if you boot VMS from a cloned or freshly installed system disk, it is beneficial to run AUTOGEN, after checking MODPARAMS.DAT for anomalies. Could it be that when booting from a MASSBUS device, the MSCP driver is not automatically loaded? Not sure if V4.6 supports this, but try setting MSCP_LOAD=1 in MODPARAMS.DAT, and AUTOGEN the system. Later versions of VMS have the SYSGEN command SHOW MSCP_LOAD, SHOW MSCP_SERVE_ALL, not sure if V4.6 has this. It may also take some time for the CONFIGURE process to enumerate all disks. Is the configure process started at all when booting from MASSBUS? Otherwise, @SYS$SYSTEM:STARTUP CONFIGURE will do so. /Wilm ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
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 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 > _
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
On 1/26/11 5:38 PM, Bob Supnik wrote: I'd dearly like to see SYSBOOT and the RH/RP driver for V4... I'll see if I can find them. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
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 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
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
Thanks, Mark. How did you happen to have a 4.6 image? Not sure I want to slow down the RP everywhere else for this one case, but an STIME of 30 probably won't make a visible difference to anyone. /Bob On 1/27/2011 5:21 PM, Mark Pizzolato - Info Comm wrote: Setting rp STIME to 26 is sufficient to allow VMS V4.6 to complete its boot. The standard VMS driver is running when the issue is observed (i.e. when the boot doesn't complete with rp STIME< 26). The executing PC is at 80008B1F is: $ anal/sys VAX/VMS System analyzer SDA> e/ins 80008b1f EXE$NULLPROC: BRB EXE$NULLPROC SDA> Clearly the OS Idle loop in that version. - Mark On Wednesday, January 26, 2011 at 5:39 PM, Bob Supnik wrote: The performance of your host processor is irrelevant. The simulator times everything in instructions. Interrupts occur the same number of instructions after IO is initiated or completed, regardless of host processor speed. Are you using a "stock" version of SimH binaries on Windows, or are you running on Linux from binaries that you compiled yourself? If Linux, then which distribution and version, and which C compiler, was used? As was suggested by another writer, try increasing RP STIME and RTIME from 10 to 1000, and see if that makes a difference. Finally, you could still be in SYSBOOT. After you type CONTINUE, SYSBOOT does its real work, which is loading VMS itself, setting up the memory environment and tables, and starting the operating system. When the hang occurs, please type ^E and dump the state of the processor: ^E sim> EX CPU STATE [long printout] and mail that information to me. I find it interesting that the RP has successfully booted everything from V1 to V7 EXCEPT for V4. I'd dearly like to see SYSBOOT and the RH/RP driver for V4... /Bob - Original Message - From: "Peter Allan" To: "Bob Supnik", simh@trailing-edge.com Sent: Wednesday, January 26, 2011 3:07:43 PM Subject: Re: [Simh] VMS 4.6 won't boot from a Massbus disk Thanks to everyone for their suggestions. To answer Bob's questions: 1) I am using the vmb.exe image that comes with simh 2) The hang does not occur in SYSBOOT. I can get into SYSBOOT, look at the parameter values, change them and type CONTINUE. That is when the system hangs. Yesterday I tried a minimal boot by going into SYSBOOT and typing SET/STARTUP OPA0:, but that did not help. 4) I will try using the Massbus and RP debugging capability and see what it tells me. 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. Cheers Peter Allan On 26 January 2011 12:44, Bob Supnik< bsup...@comcast.net> wrote: I agree with Dave Hittner: the hang in booting VMS 4.6 from Massbus is either a timing problem, or a bug in replicating some small detail of the Massbus controller. Because booting from an RA81 waits in the same place (but eventually succeeds), the "branch to self" loop where the simulator is waiting appears to be an idle loop, where VMS is waiting for some sort of event, like a disk interrupt. The disk interrupt may have occurred too soon and been lost (a problem which occurred in DEC PDP-11 operating systems and in BSD Unix as well). Or some detail that was unimportant in VMS 7.x mattered in VMS 4.x, such as the handling of attention interrupts versus data transfer interrupts. For an example of the kinds of details that could go wrong, see http://simh.trailing-edge.com/docs/massbusmystery.pdf , which documents an error in the 7.X driver sources for these disks. What would be most useful would be a VMS 4.X source set, but up until now, no one in the community has found one. So here are some questions and ideas for debugging this problem. 1. Are you using the VMB (primary boot) image that comes with the 4.X series, or the default VMB image that comes with the simulator, which is from 7.2? While I don't know of any version skew issues, they could certainly exist. Does the same problem occur when booting with a 4.X VMB? 2. Does the hang occur in SYSBOOT (secondary boot), or in VMS proper? VMS runs at high virtual memory (8XXX), yet the branch to self is in low memory. If the hang is in SYSBOOT, the problem is likely to be easier to solve, as the environment is simpler. One thing to check: is memory management enabled? 3. Other users have reported success in getting early versions of VMS to run. I seem to recall that versions as far back as 1.5 have run successfully. Can we get a census of which versions have been successfully tested on the 780 booting from Massbus, and what version of VMB they use? 4. Both the Massbus controller (RH) and the device (RP) have debugging capabilities. You can log every register read
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
The performance of your host processor is irrelevant. The simulator times everything in instructions. Interrupts occur the same number of instructions after IO is initiated or completed, regardless of host processor speed. Are you using a "stock" version of SimH binaries on Windows, or are you running on Linux from binaries that you compiled yourself? If Linux, then which distribution and version, and which C compiler, was used? As was suggested by another writer, try increasing RP STIME and RTIME from 10 to 1000, and see if that makes a difference. Finally, you could still be in SYSBOOT. After you type CONTINUE, SYSBOOT does its real work, which is loading VMS itself, setting up the memory environment and tables, and starting the operating system. When the hang occurs, please type ^E and dump the state of the processor: ^E sim> EX CPU STATE [long printout] and mail that information to me. I find it interesting that the RP has successfully booted everything from V1 to V7 EXCEPT for V4. I'd dearly like to see SYSBOOT and the RH/RP driver for V4... /Bob - Original Message - From: "Peter Allan" To: "Bob Supnik" , simh@trailing-edge.com Sent: Wednesday, January 26, 2011 3:07:43 PM Subject: Re: [Simh] VMS 4.6 won't boot from a Massbus disk Thanks to everyone for their suggestions. To answer Bob's questions: 1) I am using the vmb.exe image that comes with simh 2) The hang does not occur in SYSBOOT. I can get into SYSBOOT, look at the parameter values, change them and type CONTINUE. That is when the system hangs. Yesterday I tried a minimal boot by going into SYSBOOT and typing SET/STARTUP OPA0:, but that did not help. 4) I will try using the Massbus and RP debugging capability and see what it tells me. 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. Cheers Peter Allan On 26 January 2011 12:44, Bob Supnik < bsup...@comcast.net > wrote: I agree with Dave Hittner: the hang in booting VMS 4.6 from Massbus is either a timing problem, or a bug in replicating some small detail of the Massbus controller. Because booting from an RA81 waits in the same place (but eventually succeeds), the "branch to self" loop where the simulator is waiting appears to be an idle loop, where VMS is waiting for some sort of event, like a disk interrupt. The disk interrupt may have occurred too soon and been lost (a problem which occurred in DEC PDP-11 operating systems and in BSD Unix as well). Or some detail that was unimportant in VMS 7.x mattered in VMS 4.x, such as the handling of attention interrupts versus data transfer interrupts. For an example of the kinds of details that could go wrong, see http://simh.trailing-edge.com/docs/massbusmystery.pdf , which documents an error in the 7.X driver sources for these disks. What would be most useful would be a VMS 4.X source set, but up until now, no one in the community has found one. So here are some questions and ideas for debugging this problem. 1. Are you using the VMB (primary boot) image that comes with the 4.X series, or the default VMB image that comes with the simulator, which is from 7.2? While I don't know of any version skew issues, they could certainly exist. Does the same problem occur when booting with a 4.X VMB? 2. Does the hang occur in SYSBOOT (secondary boot), or in VMS proper? VMS runs at high virtual memory (8XXX), yet the branch to self is in low memory. If the hang is in SYSBOOT, the problem is likely to be easier to solve, as the environment is simpler. One thing to check: is memory management enabled? 3. Other users have reported success in getting early versions of VMS to run. I seem to recall that versions as far back as 1.5 have run successfully. Can we get a census of which versions have been successfully tested on the 780 booting from Massbus, and what version of VMB they use? 4. Both the Massbus controller (RH) and the device (RP) have debugging capabilities. You can log every register read and write to see how far the the controller gets. 5. As a last resort, zip up your RP disk image and post it to an uploading site, like Megaupload, so that others in the community can try their hand at the problem. You'll need to include not just the disk image, but configuration data, as well as any auxiliary files (such as an earlier VMB, if you use one). /Bob Supnik ___ 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
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
I recall this being a big deal for OpenBSD as well. And of course they just said, that it works on real hardware, it's not their problem to fix, etc etc. On Wed, Jan 26, 2011 at 4:49 PM, Brian Knittel 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
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
Brian your post reminded me of an issue that arose when I first started playing with shadow sets on my emaulated VAX. 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... 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.. Villy - Original Message - From: Brian Knittel Date: Wednesday, January 26, 2011 14:49 Subject: Re: [Simh] VMS 4.6 won't boot from a Massbus disk To: simh@trailing-edge.com > > 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
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
> 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
Re: [Simh] VMS 4.6 won't boot from a Massbus disk / VMS 4.X source set
On Wed, 2011-01-26 07:03:13 -0800, Al Kossow wrote: > On 1/26/11 5:14 AM, Hölscher wrote: > > I can supply a VMS 4.X source set, but it is on microfiche. > > I have the fiche source sets for at least 1.x -> 5.x and a scanner > If there are specific files needed, I scan scan those. Aren't there any source listings digitally available? Didn't anybody scan then and run them through OCR? Sure, that wouldn't result in compileable code, but at least, it would be somewhat searchable. With only little luck, I'd probably get access to digital microfiche readers/scanners at the university where my girlfriend teaches, but I haven't got any source sets. But really, it would be great to have them available in a somewhat searchable format... OTOH, I'd even think of placing a project on kickstarter.com to bring up the money for a scanner and offer to scan a card per day afterwards. Al, would you borrow your fiches? MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: 23:53 <@jbglaw> So, ich kletter' jetzt mal ins Bett. the second : 23:57 <@jever2> .oO( kletter ..., hat er noch Gitter vorm Bett, wie früher meine Kinder?) 00:00 <@jbglaw> jever2: *patsch* 00:01 <@jever2> *aua*, wofür, Gedanken sind frei! 00:02 <@jbglaw> Nee, freie Gedanken, die sind seit 1984 doch aus! 00:03 <@jever2> 1984? ich bin erst seit 1985 verheiratet! signature.asc Description: Digital signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
Thanks to everyone for their suggestions. To answer Bob's questions: 1) I am using the vmb.exe image that comes with simh 2) The hang does not occur in SYSBOOT. I can get into SYSBOOT, look at the parameter values, change them and type CONTINUE. That is when the system hangs. Yesterday I tried a minimal boot by going into SYSBOOT and typing SET/STARTUP OPA0:, but that did not help. 4) I will try using the Massbus and RP debugging capability and see what it tells me. 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. Cheers Peter Allan On 26 January 2011 12:44, Bob Supnik wrote: > I agree with Dave Hittner: the hang in booting VMS 4.6 from Massbus is > either a timing problem, or a bug in replicating some small detail of the > Massbus controller. > > Because booting from an RA81 waits in the same place (but eventually > succeeds), the "branch to self" loop where the simulator is waiting appears > to be an idle loop, where VMS is waiting for some sort of event, like a disk > interrupt. The disk interrupt may have occurred too soon and been lost (a > problem which occurred in DEC PDP-11 operating systems and in BSD Unix as > well). Or some detail that was unimportant in VMS 7.x mattered in VMS 4.x, > such as the handling of attention interrupts versus data transfer > interrupts. For an example of the kinds of details that could go wrong, see > http://simh.trailing-edge.com/docs/massbusmystery.pdf, which documents an > error in the 7.X driver sources for these disks. > > What would be most useful would be a VMS 4.X source set, but up until now, > no one in the community has found one. So here are some questions and ideas > for debugging this problem. > > 1. Are you using the VMB (primary boot) image that comes with the 4.X > series, or the default VMB image that comes with the simulator, which is > from 7.2? While I don't know of any version skew issues, they could > certainly exist. Does the same problem occur when booting with a 4.X VMB? > > 2. Does the hang occur in SYSBOOT (secondary boot), or in VMS proper? VMS > runs at high virtual memory (8XXX), yet the branch to self is in low > memory. If the hang is in SYSBOOT, the problem is likely to be easier to > solve, as the environment is simpler. One thing to check: is memory > management enabled? > > 3. Other users have reported success in getting early versions of VMS to > run. I seem to recall that versions as far back as 1.5 have run > successfully. Can we get a census of which versions have been successfully > tested on the 780 booting from Massbus, and what version of VMB they use? > > 4. Both the Massbus controller (RH) and the device (RP) have debugging > capabilities. You can log every register read and write to see how far the > the controller gets. > > 5. As a last resort, zip up your RP disk image and post it to an uploading > site, like Megaupload, so that others in the community can try their hand at > the problem. You'll need to include not just the disk image, but > configuration data, as well as any auxiliary files (such as an earlier VMB, > if you use one). > > /Bob Supnik > > > ___ > 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
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
On 1/26/11 11:05 AM, Alan Frisbie wrote: None of these tapes have been on a drive in 20 years, so I don't know if they are still readable. I do have a 9-track drive (TSZ07) on my Alpha, so I can at least give it a try. please consider sending them to John Bordyuik for recovery http://www.johnbordynuik.com/ there is a very high probability they will be sticky and at least will require baking. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
> What would be most useful would be a VMS 4.X source set, but up > until now, no one in the community has found one. So here are some > questions and ideas for debugging this problem. I have a VMS v4.0 source kit (9-track, 1600 bpi), but tape #3 (of 4) was damaged years ago. It stuck to the head or capstan and stretched a foot or so of tape. I have heard good things about Backup's error recovery, so perhaps if it were spliced, Backup could recover the remainder. What do you think? I also have a copy (tape made from a disk) of a VMS v4.4 source kit. None of these tapes have been on a drive in 20 years, so I don't know if they are still readable. I do have a 9-track drive (TSZ07) on my Alpha, so I can at least give it a try. >From what I have heard about tapes from that era, the binder is a problem and tapes should be "baked" before attempting to read them. I've never done this, so I would appreciate expert advice before proceeding. Alan "Packrat" Frisbie ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
Bob wrote Date: Wed, 26 Jan 2011 12:44:37 + (UTC) From: Bob Supnik To: simh@trailing-edge.com Subject: Re: [Simh] VMS 4.6 won't boot from a Massbus disk Message-ID: <1403607596.1941754.1296045877844.javamail.r...@sz0174a.westchester.pa.mail.comcast.net > What would be most useful would be a VMS 4.X source set, but up until now, no one in the community has found one. So here are some questions and ideas for debugging this problem. I have a VAX/VMS V4.4 source fiche set that I have been hanging on to for years (DEC P/N AH-HP48A-SE). Is this useful? If so, please call me or reply with instructions. I am very close to the Computer History Museum, if that is a good way point. We also have about a dozen paper tapes of what look to be RM02/RM03 diagnostics. I assume these came with our PDP-11/70 in 1978, which had an RM03 system disk. I don't know if they can be read these days. If they are useful, someone should let me know as well. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk / VMS 4.X source set
On 1/26/11 5:14 AM, Hölscher wrote: I can supply a VMS 4.X source set, but it is on microfiche. I have the fiche source sets for at least 1.x -> 5.x and a scanner If there are specific files needed, I scan scan those. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk / VMS 4.X source set
Ulli, Yes, I am interested in that but you have someone to scan that for us. Thanks, Tim -Original Message- From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On Behalf Of Hölscher Sent: Wednesday, January 26, 2011 8:14 AM To: simh@trailing-edge.com Subject: Re: [Simh] VMS 4.6 won't boot from a Massbus disk / VMS 4.X source set > What would be most useful would be a VMS 4.X source set, but up until > now, no one in the community has found one. > So here are some questions and ideas for debugging this problem. I can supply a VMS 4.X source set, but it is on microfiche. If there's someone out there willing to scan it, I'll be glad to lend it out. The result shall be publicly accessible for anyone interested. Regards, Ulli P.S.: I'm still urgently looking for the DECnet/VAX V1 & V2 kits. I know they were rare and are even rarer nowadays, but I don't want to abandon all hope yet! ___ 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
Re: [Simh] VMS 4.6 won't boot from a Massbus disk / Massbus boot census
> 3. Other users have reported success in getting early versions of VMS to > run. > I seem to recall that versions as far back as 1.5 have run successfully. > Can we get a census of which versions have been successfully tested > on the 780 booting from Massbus, and what version of VMB they use? I use the simh RP06 device successfully with: - VMS V1.0 (yes, the very first one) - VMS V2.0 - all VMS V3 versions (V3.0 - V3.7) I always use the default VMB image that comes with the simulator. sim> sh rp0 RP0, 87MW, attached to VMS010.RP6, write enabled, RP06 sim> b rp0 Loading boot code from vmb.exe VAX/VMS Version 1.00 21-AUG-1978 15:54 PLEASE ENTER DATE AND TIME (DD-MMM- HH:MM) 26-JAN-2011 14:06 OPCOM, 26-JAN-2011 14:06:08.51, LOGFILE INITIALIZED, OPERATOR=_OPA0: $ ! $ ! VAX/VMS system startup - Release 1 $ ! $ SHOW TIME 26-JAN-2011 14:06:08 $ SET NOVERIFY %MOUNT-I-MOUNTED, CONSOLE mounted on _DXA1: Login quotas - Interactive limit=64, Current interactive value=0 SYSTEM job terminated at 26-JAN-2011 14:06:08.64 Accounting information: Buffered I/O count: 142 Peak working set size:98 Direct I/O count: 37 Peak virtual size: 111 Page faults: 298 Mounted volumes: 1 Elapsed CPU time: 0 00:00:00.04 Elapsed time: 0 00:00:00.12 Username: SYSTEM Password: Welcome to VAX/VMS Version 1.00 $ $ sh sys VAX/VMS Processes on 26-JAN-2011 14:06:21.09 PidProcess Name UIC State Pri Dir. I/OCPU Page flts Ph.Mem 0001 NULL 000,000 COM00 00:00:29.420 0 00010001 SWAPPER000,000 HIB 160 00:00:00.000 0 0001003B ERRFMT 001,006 LEF91 00:00:00.00 17 17 0001003C OPCOM 001,004 LEF 112 00:00:00.00 29 34 0001003D JOB_CONTROL001,004 HIB 126 00:00:00.00 31 62 0001003E DBA0ACP001,003 HIB 11 63 00:00:00.04 31 79 0002003F SYSTEM 001,004 CUR53 00:00:00.00 58 93 $ sh dev List of Devices on 26-JAN-2011 14:06:24.71 Device Device Device Err.Volume Free Trans Mount Name Status Characteristics Count LabelBlocks Count Count DBA0:on line MNT 0 VAXVMSRL1 31662419 1 OPA0:on line 0 DXA1:on line MNT FOR 0 CONSOLE 0 1 1 LPA0:on line 0 TTA0:on line 0 TTA1:on line 0 TTA2:on line 0 TTA3:on line 0 TTA4:on line 0 TTA5:on line 0 TTA6:on line 0 TTA7:on line 0 TTB0:on line 0 TTB1:on line 0 TTB2:on line 0 TTB3:on line 0 TTB4:on line 0 TTB5:on line 0 TTB6:on line 0 TTB7:on line 0 MTA0:on line 0 $ Regards, Ulli ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk / VMS 4.X source set
> What would be most useful would be a VMS 4.X source set, but up until now, > no one in the community has found one. > So here are some questions and ideas for debugging this problem. I can supply a VMS 4.X source set, but it is on microfiche. If there's someone out there willing to scan it, I'll be glad to lend it out. The result shall be publicly accessible for anyone interested. Regards, Ulli P.S.: I'm still urgently looking for the DECnet/VAX V1 & V2 kits. I know they were rare and are even rarer nowadays, but I don't want to abandon all hope yet! ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VMS 4.6 won't boot from a Massbus disk
I agree with Dave Hittner: the hang in booting VMS 4.6 from Massbus is either a timing problem, or a bug in replicating some small detail of the Massbus controller. Because booting from an RA81 waits in the same place (but eventually succeeds), the "branch to self" loop where the simulator is waiting appears to be an idle loop, where VMS is waiting for some sort of event, like a disk interrupt. The disk interrupt may have occurred too soon and been lost (a problem which occurred in DEC PDP-11 operating systems and in BSD Unix as well). Or some detail that was unimportant in VMS 7.x mattered in VMS 4.x, such as the handling of attention interrupts versus data transfer interrupts. For an example of the kinds of details that could go wrong, see http://simh.trailing-edge.com/docs/massbusmystery.pdf, which documents an error in the 7.X driver sources for these disks. What would be most useful would be a VMS 4.X source set, but up until now, no one in the community has found one. So here are some questions and ideas for debugging this problem. 1. Are you using the VMB (primary boot) image that comes with the 4.X series, or the default VMB image that comes with the simulator, which is from 7.2? While I don't know of any version skew issues, they could certainly exist. Does the same problem occur when booting with a 4.X VMB? 2. Does the hang occur in SYSBOOT (secondary boot), or in VMS proper? VMS runs at high virtual memory (8XXX), yet the branch to self is in low memory. If the hang is in SYSBOOT, the problem is likely to be easier to solve, as the environment is simpler. One thing to check: is memory management enabled? 3. Other users have reported success in getting early versions of VMS to run. I seem to recall that versions as far back as 1.5 have run successfully. Can we get a census of which versions have been successfully tested on the 780 booting from Massbus, and what version of VMB they use? 4. Both the Massbus controller (RH) and the device (RP) have debugging capabilities. You can log every register read and write to see how far the the controller gets. 5. As a last resort, zip up your RP disk image and post it to an uploading site, like Megaupload, so that others in the community can try their hand at the problem. You'll need to include not just the disk image, but configuration data, as well as any auxiliary files (such as an earlier VMB, if you use one). /Bob Supnik ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
