ULTRIX-32M V1.0 and microVAX II

[Bitly]

I've installed Ultrix-32M v1.2 on the simh/microvax1 without issue. There are no prompts of any sort aside from changing floppies.

Spoiler: uVAX I simh install

%SIM-INFO: Loading boot code from internal ka610.bin
.2..1..0.
Boot
: ra(1,0)vmunix
211052+99036+52116 start 0x13d0
Ultrix V1.2 System #1: Wed Feb 19 22:16:59 EST 1986
real mem = 4190208
avail mem = 3168256
using 95 buffers containing 418816 bytes of memory
MicroVAX-I, Gfloat Microcode, level = 5
Q22 bus
rqd0 at csr 172150 vec 774, ipl 17
ra0 at rqd0 slave 0
ra1 at rqd0 slave 1
ra2 at rqd0 slave 2
tmscp0 at csr 174500 vec 770, ipl 17
tms0 at tmscp0 slave 0
NO LOOPBACK
WARNING: -- CHECK AND RESET THE DATE!




Starting installation of ULTRIX-32m


Whenever a default selection is given for a question
[shown in square brackets] you only need to press
the <RETURN> key to select the default choice.

Is the distribution medium <d> diskettes or tape <t> [t] ?

I've attempted to install on simh/microvax2, but it fails with the joyous message:

>>> b dua1

  2..1..0..

ra: I/O error
super block read error
Exit called
THE PROCESSOR CAN NOW BE HALTED

?06 HLT INST
    PC = 000B1830
>>>

After much single stepping, reversing, and back-annotating I've conclude there is a bug in the Q-Bus mapper in SimH that I don't know how to fix. The sectors are intended to be read into 0x000B1BC8, but it gets munged by the software into 0x010000C8 (the 1 is meaningless for uVAX II), but SimH doesn't think this should be mapped and fails since it is non-existent memory. Since everything from the QBus goes through the mapper, the check is wrong but I can't figure out why it was coded that way.

I need to make an issue, but haven't had time recently.

None of which helps you. What are you using for a hard drive? I think only up to RD53's are supported since the disk geometry was baked into the kernel.

An image that works in simh almost certainly will not be correct when mounted on a Gotek.

The raw image doesn't work in simh. Since jmdhuse got vmunix to at least start, the disk format is most likely okay.

CW

 

[jmdhuse]

An image that works in simh almost certainly will not be correct when mounted on a Gotek.

Here's a pair of Python scripts for converting between l

I've installed Ultrix-32M v1.2 on the simh/microvax1 without issue. There are no prompts of any sort aside from changing floppies.

Spoiler: uVAX I simh install

%SIM-INFO: Loading boot code from internal ka610.bin
.2..1..0.
Boot
: ra(1,0)vmunix
211052+99036+52116 start 0x13d0
Ultrix V1.2 System #1: Wed Feb 19 22:16:59 EST 1986
real mem = 4190208
avail mem = 3168256
using 95 buffers containing 418816 bytes of memory
MicroVAX-I, Gfloat Microcode, level = 5
Q22 bus
rqd0 at csr 172150 vec 774, ipl 17
ra0 at rqd0 slave 0
ra1 at rqd0 slave 1
ra2 at rqd0 slave 2
tmscp0 at csr 174500 vec 770, ipl 17
tms0 at tmscp0 slave 0
NO LOOPBACK
WARNING: -- CHECK AND RESET THE DATE!




Starting installation of ULTRIX-32m


Whenever a default selection is given for a question
[shown in square brackets] you only need to press
the <RETURN> key to select the default choice.

Is the distribution medium <d> diskettes or tape <t> [t] ?

I've attempted to install on simh/microvax2, but it fails with the joyous message:

>>> b dua1

  2..1..0..

ra: I/O error
super block read error
Exit called
THE PROCESSOR CAN NOW BE HALTED

?06 HLT INST
    PC = 000B1830
>>>

After much single stepping, reversing, and back-annotating I've conclude there is a bug in the Q-Bus mapper in SimH that I don't know how to fix. The sectors are intended to be read into 0x000B1BC8, but it gets munged by the software into 0x010000C8 (the 1 is meaningless for uVAX II), but SimH doesn't think this should be mapped and fails since it is non-existent memory. Since everything from the QBus goes through the mapper, the check is wrong but I can't figure out why it was coded that way.

I need to make an issue, but haven't had time recently.

None of which helps you. What are you using for a hard drive? I think only up to RD53's are supported since the disk geometry was baked into the kernel.


The raw image doesn't work in simh. Since jmdhuse got vmunix to at least start, the disk format is most likely okay.

CW

My hard disk is an RD53, which I formatted under XXDP using the RQDX3/ZRQC?? formatter. I presumed that this is a low-level format, and that the ultrix installer would do any higher-level formatting as part of its process.

 

[Bitly]

Browsing the 4.2BSD source code, I spy the following code:

fs = mountfs(rootdev, 0, (struct inode *)0);
    if (fs == 0)
        panic("iinit");
    bcopy("/", fs->fs_fsmnt, 2);

So, it's failing on mounting one or the other floppy. Since later instructions say to remove "Boot 1" and insert "Boot 3", my guess would be it is unhappy with "Boot 2". Do you have both of them set to R/W mode?

I'd suggest renaming all the files to useful names since you'll be prompted to insert them by name. I've attached my conversion/rename script that you can modify to just rename.

CW

 

[jmdhuse]

Browsing the 4.2BSD source code, I spy the following code:

fs = mountfs(rootdev, 0, (struct inode *)0);
    if (fs == 0)
        panic("iinit");
    bcopy("/", fs->fs_fsmnt, 2);

So, it's failing on mounting one or the other floppy. Since later instructions say to remove "Boot 1" and insert "Boot 3", my guess would be it is unhappy with "Boot 2". Do you have both of them set to R/W mode?

I'd suggest renaming all the files to useful names since you'll be prompted to insert them by name. I've attached my conversion/rename script that you can modify to just rename.

CW

The write-protect option in the GOTEK configuration file is set as "write-protect = no", so I think they are both writable. The opening text in the installation record indicates that it sees both floppy drives, but I wonder if there is some other configuration I need to do on the GOTEKs.

Is it possible that this message is because it is failing to mount the hard drive, which would be "rootdev" (I'm guessing). Is there some other formatting I should have used besides the RQDX3 formatter under XXDP?

 

[Bitly]

Is it possible that this message is because it is failing to mount the hard drive, which would be "rootdev" (I'm guessing). Is there some other formatting I should have used besides the RQDX3 formatter under XXDP?

No, the installer will mkfs the RD53 and copy the mini-root to it then reboot. Since your system hasn't created the root filesystem on the hard drive, it must be something to do with the floppies.

I can reproduce the symptoms you are seeing (panic: iinit, boot loop) by mounting "BOOT 1" and "BOOT 1 (DUPLICATE)" instead of "BOOT 1" and "BOOT 2".

I've attached a partial logfile from the uVAX I installation. Note, it panicked with an ialloc error then rebooted and continued just fine. Sometimes it panics and sometimes not, I think it's related to what was on the root disk before starting.

CW

 

[jmdhuse]

Got it... I will reformat both of the usb drives, re-copy the boot files to them, and see if that makes a difference... thanks for your help!

Update - nothing changed. Switched the two GOTEKs, and still the same problem.

 

[Bitly]

Got it... I will reformat both of the usb drives, re-copy the boot files to them, and see if that makes a difference... thanks for your help!

Update - nothing changed. Switched the two GOTEKs, and still the same problem.

Only remaining suggestion would be to try BOOT 2 (DUPLICATE) (aka 4.raw) and see if that makes a difference.

CW

 

[shirsch]

Got it... I will reformat both of the usb drives, re-copy the boot files to them, and see if that makes a difference... thanks for your help!

Update - nothing changed. Switched the two GOTEKs, and still the same problem.

You are starting with images that are compatible with simh, correct? If so, please run them through my 'simh2dsk.py' program (see posting above) before mounting the files on a Gotek. For whatever reason, the diskette image layout is an extremely confusing issue in the community. I wasted days on the problem before working out what was happening and coding the conversion programs.

 

[jmdhuse]

You are starting with images that are compatible with simh, correct? If so, please run them through my 'simh2dsk.py' program (see posting above) before mounting the files on a Gotek. For whatever reason, the diskette image layout is an extremely confusing issue in the community. I wasted days on the problem before working out what was happening and coding the conversion programs.

I am starting with images that are *not* compatible with simh... The .raw images in the archive appear to be in physical sector format as required by the GOTEK.

The first floppy image does boot and makes some progress, but fails when trying to mount the second floppy drive. I did try running the images through the conversion as an experiment, but that resulted in the "FILSTRUCT" error when trying to boot.

 

[shirsch]

For a controlled experiment, it might be interesting to convert them over to simh format using my utilities and trying an install on simh. Might help infer where the problem lies.

 

[jmdhuse]

For a controlled experiment, it might be interesting to convert them over to simh format using my utilities and trying an install on simh. Might help infer where the problem lies.

I think member Bitly did exactly that... his report is a little earlier in this thread. He was successful in getting the boot process running on the uVAX1 model, but had problems with the uVAX2 model. If I understood correctly, he thinks the problem is in the model, not an incompatibility between the OS and the processor.

 

[jmdhuse]

I have also tried the install on a uVAX III (KA650 CPU) and it stalled without starting. This makes sense because I think the KA650 requires version 2.2-1. I'm beginning to wonder if version 1.2 is just not compatible with uVAX II (KA630)...

 

[jmdhuse]

OK, so I tried something else - I removed the hard drive altogether, and booted from dua0, which is now the first floppy...

=======================================================
KA630-A.V1.3

Performing normal system tests.

7..6..5..4..3..

Tests completed.


>>> b du0

2..1..0..


Boot
: ra(0,0)vmunix
211052+99036+52116 start 0x13d0
Ultrix V1.2 System #1: Wed Feb 19 22:16:59 EST 1986
real mem = 9428992
avail mem = 7953408
using 95 buffers containing 778240 bytes of memory
MicroVAX-II with an FPU
Q22 bus
rqd0 at csr 172150 vec 774, ipl 17
ra0 at rqd0 slave 0
ra1 at rqd0 slave 1
NO LOOPBACK
Don't have a parition table for a DU RX 33
Don't have a parition table for a DU RX 33
Don't have a parition table for a DU RX 33
Don't have a parition table for a DU RX 33
panic: iinit
syncing disks... done

dumping to dev 901, offset 0
dump uddump: invalid partition table i/o error
=======================================================

So, it appears that the boot process does indeed check the hard drive, and perhaps this is the cause of the failure, not the inability to mount the second floppy drive.

I have read a lot of discussion about how to get a hard drive formatted for a uVAX system. The maintenance images I have (MDM 1.10) do not have the format utilities that are apparently quite rare. I'm going to head down that path for a while.

If anyone has any insight into how to appropriately format the RD53, I'd welcome any help.

 

[shirsch]

Do you have a real physical disk? Or, is this emulation?

 

[Bitly]

I have also tried the install on a uVAX III (KA650 CPU) and it stalled without starting. This makes sense because I think the KA650 requires version 2.2-1. I'm beginning to wonder if version 1.2 is just not compatible with uVAX II (KA630)...

There are definite checks for uVAX II and VAX 8200 in the code, so I'm confident it should work. This snippet is from vax/machdep.c:

12283325  000B0DB6 041F0000| MFPR 4(AP),R0
                               db ac 04 50
                               0000003E 000180D4 -> 08000000
  12283326  000B0DBA 041F0000| RET
                               04
  12283327  000B0DD8 041F0000| MOVL R0,-4(FP)                       cpuid = mfpr(0x3e)
                               d0 50 ad fc
                               08000000 000AFF30 -> 08000000
  12283328  000B0DDC 041F0000| MOVZBL -1(FP),-8(FP)                 cpu = cpuid >> 24
                               9a ad ff ad  f8
                               00000008 000AFF2C -> 00000008
  12283329  000B0DE1 041F0000| CMPL -8(FP),#7                       if (cpu == MVAX_I)
                               d1 ad f8 07
                               00000008 00000007                    no
  12283330  000B0DE5 041F0000| BEQL B0DED
                               13 06
  12283331  000B0DE7 041F0000| CMPL -8(FP),#8                       if (cpu == MVAX_II)
                               d1 ad f8 08
                               00000008 00000008
  12283332  000B0DEB 041F0004| BNEQ B0DFB                           yes
                               12 0e

CW

 

[jmdhuse]

Do you have a real physical disk? Or, is this emulation?

I am working with physical hardware: KA630 CPU with two 4MB memory boards, two GOTEK emulators trying to act like an RX50, RD53 hard drive, RQDX3 disk controller, BA23 chassis with the console bulkhead.

I'm wondering, if I stick the drive into my PDP-11/53, and format it under XXDP, will the result be a drive that can be partitioned, etc. on the uVAX? I think that will be my next step.

 

[jmdhuse]

There are definite checks for uVAX II and VAX 8200 in the code, so I'm confident it should work. This snippet is from vax/machdep.c:

12283325  000B0DB6 041F0000| MFPR 4(AP),R0
                               db ac 04 50
                               0000003E 000180D4 -> 08000000
  12283326  000B0DBA 041F0000| RET
                               04
  12283327  000B0DD8 041F0000| MOVL R0,-4(FP)                       cpuid = mfpr(0x3e)
                               d0 50 ad fc
                               08000000 000AFF30 -> 08000000
  12283328  000B0DDC 041F0000| MOVZBL -1(FP),-8(FP)                 cpu = cpuid >> 24
                               9a ad ff ad  f8
                               00000008 000AFF2C -> 00000008
  12283329  000B0DE1 041F0000| CMPL -8(FP),#7                       if (cpu == MVAX_I)
                               d1 ad f8 07
                               00000008 00000007                    no
  12283330  000B0DE5 041F0000| BEQL B0DED
                               13 06
  12283331  000B0DE7 041F0000| CMPL -8(FP),#8                       if (cpu == MVAX_II)
                               d1 ad f8 08
                               00000008 00000008
  12283332  000B0DEB 041F0004| BNEQ B0DFB                           yes
                               12 0e

CW

That's good to know.

I found RX50 images of the customer diagnostics from 1986, which should include the ability to format the drive. However, when I try to enter the utilities menu, I get a message about needing to have a license to run the tools. How am I supposed to purchase a maintenance kit license in 2024?

 

[Bitly]

I hacked simh to mask Q-Bus addresses to 22 bits (24 actually) and ran the installation up to the first reboot. Attached is the logfile.

diff --git a/VAX/vax630_io.c b/VAX/vax630_io.c
index c25dbbf9..a2ca24f1 100644
--- a/VAX/vax630_io.c
+++ b/VAX/vax630_io.c
@@ -714,7 +714,7 @@ int32 Map_WriteW (uint32 ba, int32 bc, const uint16 *buf)
 {
 int32 i;
 uint32 ma, dat;
-
+ba = ba & 0x00FFFFFF;                                   /* hackapotamus rex */
 ba = ba & ~01;
 bc = bc & ~01;
 if ((ba | bc) & 03) {                                   /* check alignment */

CW

 

[jmdhuse]

I hacked simh to mask Q-Bus addresses to 22 bits (24 actually) and ran the installation up to the first reboot. Attached is the logfile.

diff --git a/VAX/vax630_io.c b/VAX/vax630_io.c
index c25dbbf9..a2ca24f1 100644
--- a/VAX/vax630_io.c
+++ b/VAX/vax630_io.c
@@ -714,7 +714,7 @@ int32 Map_WriteW (uint32 ba, int32 bc, const uint16 *buf)
 {
 int32 i;
 uint32 ma, dat;
-
+ba = ba & 0x00FFFFFF;                                   /* hackapotamus rex */
 ba = ba & ~01;
 bc = bc & ~01;
 if ((ba | bc) & 03) {                                   /* check alignment */

CW

Super! That gives me confidence that if I figure out what is happening I will end up with success... thanks. I have the RD53 being formatted right now using the XXDP diag ZRQCH0 - we'll see if that makes any difference.

 

[jmdhuse]

Re-formatting the RD53 didn't make a difference... I'm thinking there is something with the GOTEKs, so I might need to break out a scope of logic analyzer and look at the drive select lines or something like that.