I'm the one who raised this particular question. It came up due to Mattis Lind's recent comments/questions to me about why the VAX750 simulator didn't boot exactly like the real hardware did. Specifically, the initial implementation of the VAX750 simulator borrowed the paradigm used by the VAX780 simulator. That paradigm reflects what happened in the VAX 11/780 console subsystem to boot the system. Specifically, the simh boot mechanisms performed the same steps that the normal console XXXBOO.CMD file did on the console LSI11. Those steps initialized the CPU, copied VMB.EXE to RAM and loaded some registers with parameters useful for VMB and started execution of VMB.
This paradigm works fine on any VAX, but the real VAX 11/750 hardware was different. It had a 4 position boot device selector switch which was used to 'point' at a ROM routine which loaded sector 0 from the target disk (specified by the switch position) and started execution of the data that was loaded. This is called a boot block boot which is distinctly different from the VMB boot. The VMB boot has code which can parse ODS1 and ODS2 file structures so it locates the secondary boot files by walking the file system. If R5 bit 3 is set, VMB will do a boot block boot as well. When VMB was moved into ROM for the MicroVAX systems the boot behavior was changed to first try a file structure boot and if that failed fall back to a boot block boot. This allowed Ultrix and BSD systems (which didn't have OSD2 file systems) to boot without any special commands being entered. The current VMB.EXE provided with the simh simulators has been patched to also perform this file structure boot with a fallback to a boot block boot. In any case, inspired by Mattis Lind's question I've looked into providing the ROM based boot for the VAX750 simulator. Mattis has a working VAX 11/750 system and he was able to extract the console ROM contents (using >>> E ROMaddr commands). He happened to have more than one ROM set. An older one which could boot from TU58, RK06, DL and UDA devices and a newer one which could boot from TU58, RP/RM and UDA devices. The code which started this thread is the boot block boot of the RP/RM device. I'm working my way through each of these new pieces of boot code to make sure that they actually behave like the original hardware did. Apart from the interesting question about BBC for the RP/RM boot, booting the Unibus devices showed that UBA's initial power on/reset state clearly had the map registers initialized to 1) be valid and 2) map the first 256Kb of RAM directly. The minimal boot code in the ROM doesn't mess with the Unibus Map at all, so this initial state must have existed. I've been distracted by other real world problems for the past few days and I'll get back to finish this debugging soon. - Mark _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
