As a collector of DEC hardware, I recently acquired a couple of Pro-350’s to add to my collection. Now anyone familiar with the Pro-350 probably recalls that the default shipping operating system was P/OS (Professional Operating System), or, as some have been known to call it, the Piece of Sh*t Operating System. P/OS was basically a stripped-down, menu driven version of RSX-11M. The Pro-350 may have shipped with P/OS, but other operating systems were known to run on it as well. Among them are RT-11, Venix, and 2.9BSD.
Assuming you still have access to a DOS machine with a 5.25″ floppy drive and a copy of Teledisk, installing P/OS and Venix on the Pro-350 is trivial. You can find RX50 images for P/OS and Venix here:
The latter includes the proacc.c source code needed to generate the access number needed during installation, as well as a pre-compiled 32-bit Linux binary.
Installing these images to 5.25″ floppies using Teledisk is easy, so I won’t document the process here. You can find Teledisk here:
The problems with P/OS may be many, but for me, lack of a command-line is the real problem. I’ve heard there is a PRO/Toolkit option that gives more functionality, but I’d prefer a more traditional UNIX Operating System. Venix fits the bill, but doesn’t have network support. So the best options for a UNIX Operating System with network support is 2.9 BSD or ProV7M, and the latter is hard to find. I opted to install BSD, as the images are readily available at the Unix Heritage Society site:
Browsing the archive, the first thing you will notice is the site hasn’t been updated for quite some time, and so documentation is lacking. The images themselves aren’t very organized either – you will find what appears to be duplicate copies of some images among the various sub-directories.
The information needed to install these images can be found in the documents sub-directory as a bunch of hand-written notes scanned into TIF images. Reading through the notes, the first thing to do is make/acquire a cable to use for terminal interaction with the Pro-350 from a PC. After that, you need to create a bootable floppy from the maintenance0.rx.50 image. As mentioned in the notes, due to an error in their creation, these images fall slightly short of the size they should be. Fortunately, an acquaintance of mine had corrected versions of these images and those are what I used as the basis for my work. I believe the default images will work, despite being shy a few bytes, but I didn’t try them out. You can find the fixed verisons here:
Now creating the boot disk turned out to be harder than I thought. There are a few places on the web that document how to create an RX50 floppy from linux. One such site is the Xhomer Project Pro-350 emulator site:
In the “Reading and Writing RX50 Floppies” section of the site, you will find directions on how to create an RX50 floppy from Linux using the setfdprm utility. Unfortunately, this did not work for me. Every RX50 floppy I created using setfdprm and dd on Linux failed to boot in my Pro-350. I know the procedure works for other folks, but it wasn’t working for me. I tried two machines, one a Pentium 4 class and the other a Pentium I, as well as two Linux distributions – Debian and Slackware. Both failed to create a bootable RX50 floppy.
After a week of messing with floppy creation under Linux, I began to suspect that Linux was the cause of my problems. I say this because I was able to create P/OS and Venix disks under DOS from Teledisk images with no problem, yet I wasn’t able to create a single working floppy under Linux. After some research, I learned about a DOS utility called ImageDisk (http://www.classiccmp.org/dunfield/img/index.htm) which was written as a replacement for Teledisk because Teledisk is no longer supported. Also, ImageDisk claimed to be more robust, with an open-source image format rather than the proprietary format used by Teledisk. So I downloaded ImageDisk and played around with it. Like Teledisk, it could read a floppy and create an image from it, or vice versa. When I learned that ImageDisk would also store the geometry of the floppy disk in the image, an idea occurred to me – why not let ImageDisk create an image file from my bootable Venix disk? That way, I could examine that image with ImageDisk and find out what geometry was used by Teledisk to create the Venix floppy. So I did just that. This is what I learned about the geometry of the Venix image:
300k DD 10 sectors, 512 bytes per sector, read gap = 7, format gap = 14
Now most of these parameters line up with what setfdprm in Linux was set for, except for the gap parameters. In Linux, those values were 20 and 24. Also, my research on RX50 floppies showed the frequency to be 250k, not 300k. So when I created my images with ImageDisk, I had to change those parameters accordingly.
So armed with this new knowledge, I took the BSD maintenance0.img raw image and ran it through the ImageDisk utility BIN2IMD to create an ImageDisk image from a raw binary image. The command to do that is:
BIN2IMD maintenance0.img maint0.imd /1 n=80 dm=4 ss=512 sm=1-10
Basically, /1 means single sided, n=80 means 80 cylinders, dm=4 means 300k, ss=512 means a sector size of 512 and sm=1-10 means create a disk with 10 sectors per track.
Once I had the maint0.imd image, I then used ImageDisk to create a floppy from that image. Before the creation process, I had to change the following settings in ImageDisk:
R/W gap: 7
I then selected write disk from image and the resulting floppy booted in my Pro-350, displaying the 40Boot prompt as documented in page02.tif.
With this knowledge, I think if I were to change the Linux setfdprm parameters to match those of ImageDisk, I could create working RX50 floppies under Linux. The problem is setfdprm is woefully undocumented. From Xhomer and related sites, I have learned that this is the recommended format of the setfdprm string to use for creating RX50 floppies:
|Sectors per track||10|
|R/W Gap (Gap 1)||0x14|
|Stepping Rate (Spec1)||0xdf|
|Format Gap (Gap 2)||0x18|
Clearly R/W Gap and Format Gap map to the same values in ImageDisk, but I’m not sure what the Stretch, Data Rate and Stepping Rate values map to, nor do I know how to specify the frequency. I’m sure with the right values, I could create a usable floppy under Linux. What’s strange is how these values must have worked for those who published the information, but not for me.
That’s it for this post – stay tuned for Part II, where I demystify the various images in the 2.9 BSD distribution.