ULTRIX-32M V1.0 and microVAX II

jmdhuse · Sep 4, 2024

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.

Code:

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

Well, I've tried everything I can think of and I just can't get the uVAX to believe the two GOTELs are 2 actual RX50 drives. I'm not experienced with simh,,, If I configure the simulation to have the same hardware as my real system, can I install ultrix, then somehow get the disk image from the simulator on to my RD53?

jmdhuse · Sep 11, 2024

Latest update - I used the simh-microvax2 simulator and went through the entire installation process with the 38 floppies. Then I copied the resulting "root.dsk" file onto the ZULUSCSI microSD card, and swapped the UC07/ZULUSCSI for the RQDX3/RD53 in my microVAX II. What do you know, I now have ULTRIX32M V1.2 running on my actual system.

Now, the next question: Is there a way to get the "root.dsk" image copied appropriately onto the actual RD53 hard drive and make it bootable?

At least this confirms that the floppies are not flawed - still would like to figure out why my two GOTEKs don't work together like an RX50 drive system.

Bitly · Sep 11, 2024

In theory you should be able to install the RQDX3 as a second controller and copy the files from the Zulu to the RD53. That said, I'm not sure the exact steps to make the filesystem(s), and if labeling is required. A copy of the 4.2BSD system manager's manual would probably help.

If memory serves, the full installation won't fit on a single RD53, but you should be able to get a minimal system running.

CW

jmdhuse · Sep 11, 2024

Bitly said:
In theory you should be able to install the RQDX3 as a second controller and copy the files from the Zulu to the RD53. That said, I'm not sure the exact steps to make the filesystem(s), and if labeling is required. A copy of the 4.2BSD system manager's manual would probably help.

If memory serves, the full installation won't fit on a single RD53, but you should be able to get a minimal system running.

CW

df reports 2970 kbytes free on / and 29043 kbytes free on /usr, so that is about half of the 71MB available on the drive.

I will try what you suggest about installing the RQDX3 as a second controller at 17760334 and first LUN assigned to 4.

czunit · Sep 12, 2024

What I usually do is format the RD53/54 drive, make an image file of it using Dave's MFM device, then install whatever OS on that image using SIMH, then copying back the resulting image.

Gets all the bad blocks, and everything proper.

jmdhuse · Sep 13, 2024

I now have reconfigured the hardware:
KA630 CPU and 2 x MS630-BB 4MB memory modules
VCB01 monochrome graphics adapter (behaves as console)
DZQ11 4-line serial multiplexer
UC07 SCSI controller with ZULUSCSI (this holds the boot image from simh)
RQDX3 controller with RD50 and 2 x GOTEK (imaging them to be an RX50)

When I boot this system I see:

So the system seems to see all the hardware.

However, the RD53 and GOTEKs aren't mounted and accessible, so I'm wondering if I have to configure my simh system with all the same hardware to that the installation program knows about it. Any help on how to configure the microvax2.ini so that it represents both of the disk controllers would be welcome.

Or, is there some way of reconfiguring the kernel running on the actual system so that the additional disk controller and drives are accessible. My attempts to use the "mount" command have not gotten me anywhere.

The journey continues - thanks!

Bitly · Sep 14, 2024

You probably don't have /dev/ra4*, /dev/ra5* or /dev/ra6*, so create them firstly.

Code:

# cd /dev
# ./MAKEDEV ra4 ra5 ra6

Then try the mount command again.

Code:

# mkdir /mnt
# newfs /dev/rra4a rd53
# mount /dev/ra4a /mnt

You can also try reading/writing from the drive in raw mode.

Code:

# dd if=/dev/zero of=/dev/rra4c
# od -x /dev/rra4c

For reference: SMM
CW

Note: This is all from memory, YYMV

jmdhuse · Sep 14, 2024

Bitly said:
You probably don't have /dev/ra4*, /dev/ra5* or /dev/ra6*, so create them firstly.

Code:

# cd /dev # ./MAKEDEV ra4 ra5 ra6

Then try the mount command again.

Code:

# mkdir /mnt # newfs /dev/rra4a rd53 # mount /dev/ra4a /mnt

You can also try reading/writing from the drive in raw mode.

Code:

# dd if=/dev/zero of=/dev/rra4c # od -x /dev/rra4c

For reference: SMM
CW

Note: This is all from memory, YYMV

That seemed to do the trick... thanks!

jmdhuse · Tuesday at 1:24 AM

I'm beginning to suspect that those of us who pursue this hobby might be a little unhinged... I had my microvax2 running ultrix from a ZULU SCSI emulator with an image I built on simh, but, oh no, that wasn't good enough for me. I wanted the full experience of installing ultrix-32m v1.2 on my RD53 from a set of floppies, the way *real* nerds do it.

First step, get my hands on a working RX50 drive and attach it to the RQDX3. Next, built a pc/at from scraps and cheap ebay parts, then install DOS 6.22. Next, learn how to use ImageDisk 1.2 and PUTR, and find a bunch of DD floppies that work with the RX50 drive. Format them with ImageDisk and copy the install images, all 35 of them, to floppies using PUTR. Then spend an afternoon shuffling floppies in and out of the RX50 until, amazingly, I have ultrix installed and running. Somewhere along the line I missed loading the Fortran floppy, so I will need to figure out how to install it after the fact, but, on the whole, I feel pretty satisfied.

Thanks to everyone who has provided help along the way...

Cheers, Jon.

leegleason · Tuesday at 2:11 AM

jmdhuse said:
I'm beginning to suspect that those of us who pursue this hobby might be a little unhinged... I had my microvax2 running ultrix from a ZULU SCSI emulator with an image I built on simh, but, oh no, that wasn't good enough for me. I wanted the full experience of installing ultrix-32m v1.2 on my RD53 from a set of floppies, the way *real* nerds do it.

First step, get my hands on a working RX50 drive and attach it to the RQDX3. Next, built a pc/at from scraps and cheap ebay parts, then install DOS 6.22. Next, learn how to use ImageDisk 1.2 and PUTR, and find a bunch of DD floppies that work with the RX50 drive. Format them with ImageDisk and copy the install images, all 35 of them, to floppies using PUTR. Then spend an afternoon shuffling floppies in and out of the RX50 until, amazingly, I have ultrix installed and running. Somewhere along the line I missed loading the Fortran floppy, so I will need to figure out how to install it after the fact, but, on the whole, I feel pretty satisfied.

Thanks to everyone who has provided help along the way...

Cheers, Jon.

"those of us who pursue this hobby might be a little unhinged... " Amen, Brother.

Bitly · Tuesday at 3:37 AM

jmdhuse said:
Somewhere along the line I missed loading the Fortran floppy, so I will need to figure out how to install it after the fact

I think the product floppies are tar images, so you should be able to just untar it in the appropriate directory (probably root). There is also a manifest file somewhere to verify all the files got installed correctly, but I forget if it's part of the initial image or the product floppy.

CW

AndrewZ · Tuesday at 12:36 PM

Just to clarify, the layout issue is that the physical floppies were interleaved, not logically sequential. It's a relatively simple thing to re-arrange, if you know what your system expects.

jmdhuse · Tuesday at 6:05 PM

AndrewZ said:
Just to clarify, the layout issue is that the physical floppies were interleaved, not logically sequential. It's a relatively simple thing to re-arrange, if you know what your system expects.

I have all the floppy images in physical format, so it was straightforward to copy them to the disks... I got them from:

Index of /bits/DEC/vax/ultrix/1.2

jmdhuse · Wednesday at 4:39 AM

I have concluded the the reason I could not install from a pair of GOTEKs was because the system saw the second drive as an RX33, rather than an RX50, and it did not know how to mount and read an RX33. I don't know how the GOTEK demonstrates which drive it is emulating.

shirsch · Wednesday at 2:20 PM

jmdhuse said:
I have concluded the the reason I could not install from a pair of GOTEKs was because the system saw the second drive as an RX33, rather than an RX50, and it did not know how to mount and read an RX33. I don't know how the GOTEK demonstrates which drive it is emulating.

If you have mounted an image with metadata (HxC format) it uses that information to setup virtual geometry. If you mount a raw sector image (dsk, img) it either uses a baked-in geometry keyed on image size or whatever you have defined in the IMG.CFG file. In neither case does it "tell" the host machine anything. It's up to the host software to infer the disk type from sector layout and geometry.

jmdhuse · Wednesday at 6:00 PM

shirsch said:
If you have mounted an image with metadata (HxC format) it uses that information to setup virtual geometry. If you mount a raw sector image (dsk, img) it either uses a baked-in geometry keyed on image size or whatever you have defined in the IMG.CFG file. In neither case does it "tell" the host machine anything. It's up to the host software to infer the disk type from sector layout and geometry.

I am starting with raw disk images that are organized as physical format, so no HxC format metadata is present. Here is how I came to my conclusion:

Before I committed to making and loading all 30-odd floppies, I tried a shortcut. I created the first 3 boot floppies and loaded those. They create what they refer to as a "minisystem" on the hard drive, then request that you reboot from DUA0. Once the minisystem starts, it begins to request the series of floppies be loaded into the RX50. What I did was replace the RX50 with a GOTEK (running FlashFloppy) holding all the floppy physical images, and tried to proceed with the loading. Upon trying to load the first floppy (base1_10), the system threw a panic and declared that it did not have partition information for an RX33, and so could not proceed. From that message I concluded that somehow the system does not see the GOTEK as an RX50, even though the images are exactly 400k.

Your comment makes me think that if I put the right information into IMG.CFG, this problem might go away... currently, the IMG.CFG is null...

czunit · Wednesday at 6:37 PM

Definitely define things in img.cfg. I have no issue running two GOTEKs on my Professional 350/380.

shirsch · Wednesday at 7:28 PM

czunit said:
Definitely define things in img.cfg. I have no issue running two GOTEKs on my Professional 350/380.

So, I'm curious. Does your DEC Pro 350 fail the floppy subsystem during POST when booted with both Gotek's empty (no image mounted)? I spent a long time trying to figure this out here, to no avail. I usually work around by having a valid RX50 image with no boot track in the first drive. If it sees that it's happy.

shirsch · Wednesday at 7:41 PM

jmdhuse said:
I am starting with raw disk images that are organized as physical format, so no HxC format metadata is present. Here is how I came to my conclusion:

Before I committed to making and loading all 30-odd floppies, I tried a shortcut. I created the first 3 boot floppies and loaded those. They create what they refer to as a "minisystem" on the hard drive, then request that you reboot from DUA0. Once the minisystem starts, it begins to request the series of floppies be loaded into the RX50. What I did was replace the RX50 with a GOTEK (running FlashFloppy) holding all the floppy physical images, and tried to proceed with the loading. Upon trying to load the first floppy (base1_10), the system threw a panic and declared that it did not have partition information for an RX33, and so could not proceed. From that message I concluded that somehow the system does not see the GOTEK as an RX50, even though the images are exactly 400k.

Your comment makes me think that if I put the right information into IMG.CFG, this problem might go away... currently, the IMG.CFG is null...

Try this in IMG.CFG:

Code:

# DEC RX50
[rx50::409600]
cyls = 80
heads = 1
secs = 10
interleave = 2
bps = 512
id = 1
rpm = 300
rate = 250
mode = mfm

Since there are other popular formats with the same size, the 'rx50' prefix requires that you name images in the form "<filename>.rx50.dsk" to avoid confusion. At least one of the conflicting formats is a built-in, which is likely to cause problems unless the tag name is used.

So, if you have an image file called "system_disk.dsk", rename it to "system_disk.rx50.dsk" when running on the Gotek. Then you'll be sure it's the definition above that gets used.

czunit · Wednesday at 7:55 PM

shirsch said:
So, I'm curious. Does your DEC Pro 350 fail the floppy subsystem during POST when booted with both Gotek's empty (no image mounted)? I spent a long time trying to figure this out here, to no avail. I usually work around by having a valid RX50 image with no boot track in the first drive. If it sees that it's happy.

I believe it works happily, the trick is that with no image and the proper CFG settings it sees the drive "door" as "open".

ULTRIX-32M V1.0 and microVAX II

Experienced Member

Experienced Member

Experienced Member

Experienced Member

Veteran Member

Experienced Member

Experienced Member

Experienced Member

Experienced Member

Experienced Member

Experienced Member

Experienced Member

Experienced Member

Experienced Member

Veteran Member

Experienced Member

Veteran Member

Veteran Member

Veteran Member

Veteran Member