Thanks for the walk down memory lane Stephen !
I remember loading up MicroVMS 4.5b onto a shiny new MicroVAX 2000 back in 1988. The total set of floppies came to about 80. I know this because I had to install it twice. What started out life as a standalone MicroVAX 2000 with 4Mb RAM, a single 31Mb RD52 disk, a TK50 and 4 terminals, eventually became a fully expanded system with 2 * 159Mb RD54s, 16 Mb of RAM (thanks Clearpoint !!!), a DHT-32 8-line asynchronous expander, DESVA Ethernet option and ran OpenVMS 6.2 as part of a mixed VAX and Alpha cluster. The MicroVAX 2000, despite its relative slowness compared to the later VAX 4000-300, MicroVAX 300 M76, AlphaServer 400 4/266 and AlphaServer 1000 5/300 nodes that we used, will always have certain soft spot in my heart. On the subject of loading VMS or MicroVMS into the emulated VAXstation 2000 in SIMH, can it be booted from across the Ethernet ? I honestly can’t remember if it was possible. We only ever booted it from floppies for the initial, RD disks for regular operations, or from the TK50 for standalone backup. Regards Jason From: [email protected] [mailto:[email protected]] On Behalf Of Stephen Hoffman Sent: Thursday, 26 May 2011 1:15 PM To: [email protected] Subject: Re: [Simh] VAXstation 2000 On Date: Wed, 25 May 2011 22:15:53 -0400, Michael Kerpan <[email protected]> posited: Given that IIRC, VMS does its hardware detection during install, how did you go about getting the system to see the hardware present in the VaxStation and forget about the stuff in the Vaxserver 3900? VMS implements the system and device configuration at bootstrap. The platform console finds and loads the primary bootstrap VMB, APB or IPB image into memory (from the system disk or from external console storage (and remember CONSCOPY.COM <http://CONSCOPY.COM/> or EXCHANGE to update the console media), depending on the VAX), and the primary bootstrap then uses the console and its own pieces including the primitive file system to find and to get SYSBOOT into memory, and SYSBOOT loads enough additional parts to kick off the rest of the bootstrap. The original MicroVMS stuff might have caused some confusion around the implementation details here, as that was a subset distribution specifically for storage-constrained MicroVAX processors. In various cases including the Local Area VAXcluster (LAVc) support, the system manager ended up loading full VMS onto the box. And the MicroVMS distribution was discontinued when the MicroVAX storage became sufficient for a (potentially tailored) VMS installation. This generic nature of the VMS bootstrap also plays into the DEFAULTS settings for the system parameters, too. The SYSBOOT (and SYSGEN) defaults are just good enough to get most any VAX box to boot far enough to run AUTOGEN and fix the parameters. (While there have been a few parameter "bugs" here over the years that could cause problems booting some boxes, these settings and this behavior holds for most VMS and OpenVMS releases.) The advent of CDs and TK50 as bootable VMS installation media was a substantial improvement over what was available prior to that, too; installing all of MicroVMS and ancillary pieces could involve thirty and often more floppies. The older VAX-11 processors differed substantially from one model to the next and which required some effort to implement the processor support, where the KA610 MicroVAX I series then kicked off the so-called subset VAX systems; those newer VAX systems that lacked various architectural mechanisms from the earlier VAX-11 series including the PDP-11 instruction set. I'd expect that the initial approach used for development here was to load a MicroVMS or VAX/VMS disk image into an emulation that presents itself as a VAXstation 2000, and booting it. The version would have to be new enough to support the VAXstation 2000 hardware.
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
