Thanks for the info, I've never worked with physical VAX hardware this old. The kernel is definitely accessing the DEQNA, here's what the debug output shows during boot:
DBG(21694666)> XQ REG: xq_rd(PA=0x20001920 [MAC0], access=0) DBG(21694666)> XQ REG: data=0xFF08 DBG(21694681)> XQ REG: xq_wr(data=0x00000002, PA=0x2000192E[CSR], access=2) DBG(21694681)> XQ REG: xq_wr_csr(data=0x00000002) DBG(21694684)> XQ REG: xq_wr(data=0x000001F8, PA=0x2000192C[VAR], access=2) DBG(21694684)> XQ REG: xq_wr_var(data= 0x000001F8) DBG(21694766)> XQ REG: xq_rd(PA=0x20001920 [MAC0], access=0) DBG(21694766)> XQ REG: data=0xFF08 DBG(21694769)> XQ REG: xq_rd(PA=0x20001922 [MAC1], access=0) DBG(21694769)> XQ REG: data=0xFF00 DBG(21694772)> XQ REG: xq_rd(PA=0x20001924 [MAC2], access=0) DBG(21694772)> XQ REG: data=0xFF2B DBG(21694775)> XQ REG: xq_rd(PA=0x20001926 [MAC3], access=0) DBG(21694775)> XQ REG: data=0xFFAA DBG(21694778)> XQ REG: xq_rd(PA=0x20001928 [MAC4], access=0) DBG(21694778)> XQ REG: data=0xFFBB DBG(21694781)> XQ REG: xq_rd(PA=0x2000192A [MAC5], access=0) DBG(21694781)> XQ REG: data=0xFFCC DBG(21695029)> XQ REG: xq_wr(data=0x000080C0, PA=0x2000192E[CSR], access=2) DBG(21695029)> XQ REG: xq_wr_csr(data=0x000080C0) DBG(21695031)> XQ REG: xq_wr(data=0x00001E78, PA=0x20001924[RBDL-Lo], access=2) DBG(21695034)> XQ REG: xq_wr(data=0x00000004, PA=0x20001926[RBDL-Hi], access=2) DBG(21695037)> XQ REG: xq_wr(data=0x00002158, PA=0x20001928[XBDL-Lo], access=2) DBG(21695041)> XQ REG: xq_wr(data=0x00000004, PA=0x2000192A[XBDL-Hi], access=2) I uploaded the RD52 image and the output of "sh c" here, anyone is welcome to use it for whatever: http://cs.oberlin.edu/~hbent/vaxultrix/ultrix1.tar.bz2 -Henry On 26 June 2014 21:16, Mark Pizzolato - Info Comm <[email protected]> wrote: > Hi Henry, > > > > There are only two possible addresses for a DEQNA device, and I’m very > sure that the expected address is the primary address which should be the > default. > > > > You can verify that the kernel is attempting to touch the Qbus register > space for the DEQNA device with the following simh commands added to your > simh configuration: > > > > sim> set xq debug=REG > > sim> set debug stdout > > > > Boot the simulator and the debug output should show any register > references which may be occurring. > > > > If you truly believe that the DEQNA device isn’t working properly I can > dig into the details if you can provide an RD51 or RD52 disk image and the > configuration file you’re working with. > > > > Good Luck, > > > > - Mark > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Henry Bent > *Sent:* Thursday, June 26, 2014 6:09 PM > *To:* [email protected] > *Subject:* [Simh] Ultrix 1.0 > > > > I had success booting the Unix Archive's floppy distribution of Ultrix 1.0 > on the MicroVAX 1 simulator. It appears that the distribution there was > only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot > on any other machine. RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 > need to be RX50s. TTI and TTO need to be 7 bit. To boot the installer, > put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2. The install goes > cleanly, albeit with quite a bit of disk swapping - the installation disk > set is 13 floppies. > > The QVSS is supported and will display some output on boot. I haven't yet > looked into what is needed to use it as the console (if that's possible?). > > The kernel seems to support what I assume is the DEQNA - it has references > to a qe device - but I can't figure out how to get it recognized. > Unfortunately there are no kernel config files in the distribution, so I > have no idea if the stock kernel is expecting the controller at a > non-standard address. Any help with this would be greatly appreciated, > > -Henry >
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
