Tag Archives: ImageDisk

Now that I have a Pro-350 running BSD 2.9, but without an Ethernet card, a solution is needed for transferring files to and from it. The first thing that comes to mind, as mentioned in the notes, is to use the venerable cu command. Using cu to transfer files is as old as UNIX itself, and should work.

So I connected up a NULL modem cable from the serial port of the Pro-350 (a 25 pin D-SUB connector) to my Linux box. In BSD, the serial port equates to /etc/tty01 (the printer port is /etc/tty00). I made sure that I enabled /etc/tty01 for logins in BSD as mentioned at the end of part III, and then fired up cu on Linux:

cu -l /dev/ttyS1 -s 9600

Sure enough, it connected and I was presented with the login prompt. After logging in, I initiated the put command (~p or ~%put) and attempted to transfer a file. After a few seconds, the terminal started echoing back what appeared to be some characters from the original file, and then the connection dropped. Unfortunately, the file didn’t transfer. Looking through the cu manual page, I tried various options to try and fix the problem, but nothing seemed to work. Reading this in the BUGS section of the man page didn’t fill me with confidence:

This program does not work very well.

After seeing that, I decided to try using my Solaris box instead.

Unfortunately, Solaris turned out to have the same problem. However, the Solaris man page did offer this tidbit that was missing from the Linux man page:

The use of ~%put requires stty(1) and cat(1) on the remote side. It also requires that the current erase and kill characters on the remote system be identical to these current control characters on the local system. Backslashes are inserted at appropriate places.

The use of ~%take requires the existence of echo(1) and cat(1) on the remote system, and that the remote system must be using the Bourne shell, sh. Also, tabs mode (see stty(1)) should be set on the remote system if tabs are to be copied without expansion to spaces.

Aha! Is this what I was missing? After verifying that these conditions were indeed met, I decided to manually set the erase and kill characters. After doing that, the echos stopped and cu appeared to work (there were no errors). However, no file was transferred.

Long story short, I spent many hours trying cu from Linux to BSD and Solaris to BSD, trying both puts and takes unsuccessfully. I still do not know why it didn’t work, but assume it’s due to the fact that the cu on BSD 2.9 is over 30 years old, whereas the one on Linux or Solaris is probably 1/2 that. Perhaps there is some sort of incompatibility between the two. I wouldn’t think there would be, but I don’t know what else the problem could be.

With cu out of the equation, the next logical step was to try kermit. But how do I transfer the source files to the Pro-350? Or the binary if I could find one? There are too many files to type in manually, and cutting/pasting between terminal windows doesn’t work very well on the Pro-350 side.

As luck would have it, my friends Sidik and Tarik over at the Xhomer project (http://xhomer.isani.org/xhomer) had for some time an interest in getting BSD 2.9 running on their Pro-350 simulator. With the help of my instructions, they were able to get a BSD 2.9 image up and running on Xhomer! As a bonus, they created a utility, rx2f, that enables you to create a BSD RX50 image of a file on Linux (up to 400K in size) that can then be written to a 5.25″ floppy drive. That floppy can then be put into the Pro-350 running BSD 2.9 and extracted. Their work is still in progress, but you can find it here: http://xhomer.isani.org/xhomer/BSD/bsd.html.

Using rx2f, I was able to transfer files such as kermit to the Pro-350. For my first attempt, I tarred up the kermit sources on Linux, used split to make 400K chunks, wrote them to a 3.25″ floppy on Linux, and then copied those chunks to DOS (As explained in part I, I had no luck using Linux to create RX50 floppies). Once on DOS, I used BIN2IMD to create IMD files for use in ImageDisk, and then wrote the chunks to 5.25″ floppies (again, as explained in part I). Then once in BSD, I retrieved the files from the RX50 floppies, used cat to glue the chunks back together and then tried to use tar to extract them. Guess what? The stock BSD install doesn’t contain tar! As hard as it is to believe, it’s true. So I found the tar binary in the original sources:

And then used rx2f to transfer tar over to the Pro-350. After that, I was able to extract the kermit sources.

Armed with a mechanism to get files onto the Pro-350, I attempted to compile ckermit. Some minor edits were needed, but in the end, I got a successful build. However, running it resulted in the following error:

kermit:too big

Clearly the binary is too big to load into memory. Since I have 350K of memory, I found this strange.

To try and shrink the binary, I added -O and -V options to cc and recompiled. The binary was smaller, but still wouldn’t load. Other than adding more memory or trying to reduce the memory footprint of kermit by hacking the source code, I’m not sure what to do.

About this same time, my friends at Xhomer had gotten zmodem to compile and run on their BSD emulator. Figuring I could do the same, I transferred the zmodem sources via rx2f and compiled zmodem on the Pro-350. You can find the zmodem sources here:

The sources are for 2.11, but worked for Xhomer and so should work on the Pro-350 as well.

As expected, the source compiled without issue. However, running it proved to be problematic. Like cu, I couldn’t get transfers in any direction working. I tried both sz and rz, as well as both tty00 and tty01. The best I could get were timeout errors and ZNAKs. I tried invoking the utilities after logging in through the tty port, as well as stand-alone with commands similar to below:
rz /dev/tty01
sz file /dev/tty01

Nothing seemed to work. My best guess is that zmodem needs to be 8-bit, but BSD seems to be 7-bit. Why does it work on the simulator? I’m guessing it’s because they are using pseudo-ttys.

With kermit and zmodem not working, I tried gkermit. Unlike ckermit, gkermit to load and run, but like zmodem, it failed to transfer any files. The G-Kermit documentation did provide some potentially useful information:

G-Kermit is always on the “far end” of a connection, on a Unix system that you have made a connection to from a terminal emulator by dialup, network, or direct serial. If you have a direct or dialup serial connection into Unix, use the “stty -a” or “stty all” command to see if your Unix terminal driver is conditioned for the appropriate kind of flow control; if it isn’t, very few applications (including gkermit) will work well, or at all.

Interesting. As far as I can tell, there is no flow control available in BSD 2.9. Or at least it’s not documented in the stty man page. Perhaps this is the root of the problem.

So at this point, I am left using rx2f. I’m grateful that the folks at Xhomer provided me with this utility, else I couldn’t transfer any files at all.

OK, so with an understanding of how to create RX50 floppies from the images, as well as what images to use, we are now ready to begin the actual installation. I’d like to point out that these instructions are basically typed versions of the hand-written notes found here:

1) As discussed in Part I, first create the floppy distribution using ImageDisk. You will need nine 5.25″ floppy disks if you are using the 3 disk usr set, and twenty-five if using the 16 disk usr set. You will also need a DOS PC, a copy of ImageDisk and, of course, the images. Use ImageDisk to create the installation floppies from the *.IMD images, using these settings:

Note that during installation of BSD, the maintenance floppy must not be write-protected, else you get this error:

r50a: hard error on 10 cs0=370 csi=260

All other floppies can be write-protected.

2) In order to perform the installation, you must gain access to the Pro-350 via the printer port. When a cable with pins 8 and 9 shorted together is inserted into the printer port, it puts the Pro-350 into maintenance mode, which is necessary for installing BSD. Either construct a cable, or find an official DEC cable on ebay or someplace (DEC part BCC-08). To construct a cable, use the following pinout:

PC (DB9)

Pro-350 Printer Port (DB9)

1

1

2

2

3

3

5-6

7

7

8-9

Once you have a cable, connect it between the printer port of the Pro-350 and the serial port of the PC. Note that while connected via the cable, sending a break signal will put the Pro-350 into the ODT (Online Debugging Tool). If your prompt changes to an @, you are in the ODT. If this happens, hit p to resume.

3) The original notes mention that the Pro-350 expansion cards may need to be in a particular order for the installation to work. I have gotten BSD to install with a slightly different set of cards in a different order, but believe that the DECNA card MUST be in slot 4 (slots are numbered from 0 – 5, left to right) or not present in order for the installation to boot from the hard drive. I do not have a DECNA card to test this theory (I can’t seem to find one), but I originally had a 256KB RAM expansion card in slot 4 and this is the error I received when trying to boot from the hard drive:

In order to get by this error, I moved the 256KB RAM expansion card from slot 4 to slot 5. So the order of my cards became:

Slot

Card

0

RD51 Controller

1

RX50 Controller

2

Screen Bitmap

3

Extended Screen Bitmap

4

Empty

5

256K RAM Expansion

This worked, but I lost 256KB of memory, presumably because BSD wasn’t using the card in slot 5. So I removed the Extended Screen Bitmap card from slot 3, and put the 256KB RAM expansion in its place. This gave me the additional 256KB of memory that is needed to do anything useful with BSD once the system boots. So the short of all this is to follow the original notes and arrange your cards in the order specified, which is:

Slot

Card

0

RD51 Controller

1

RX50 Controller

2

Screen Bitmap

3

256K RAM Expansion

4

DECNA Ethernet Controller

5

Empty?

I’m sure the system can be reconfigured to use a different card order, but for installation, use the above order.

4) When restoring volumes, it is OK if you put the wrong disk in by accident as the system will inform you. If you put the wrong disk in for the first set of a volume, you will receive this error:

Tape is not volume1

If subsequent disks are inserted in the wrong order, you will receive this error:

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 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:

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:

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:

Sides: One
Double-step: Off
R/W gap: 7
Format gap:14

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:

Size

800

Sectors per track

10

Heads

1

Tracks

80

Stretch

0

R/W Gap (Gap 1)

0x14

Data Rate

0x01

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.