DEC Professional 350 Restoration
INTRODUCTION
DEC created the Professional Series of desktop computers for the corporate office environment, performing much the same functions that a desktop or laptop computer can do today. This was the professional series and there were three models; the PRO325, PRO350 and PRO380. The PRO325 was strictly a floppy based computer using DEC's RX50 floppies. The PRO350 and 380 both featured the RX50 floppy but also had hard disks in various sizes from 5MBytes to 30Mbytes. Whereas the 325 and 350 shared the same 40 pin F-11 single chip MOS processor as the LSI-11/23, the PRO380 used the bigger and faster J-11 processor as used on the PDP-11/73/83/93 series.
Although these were superbly engineered desktop computers, however, they were too expensive as compared to commodity PCs and never gained a major market foothold. Many corporate clients purchased these computers, especially if they were existing DEC clients, the support could be added to larger corporate support agreements. These were not meant for the average consumer, but as corporate desktops.
In late 1990 I acquired four PRO350s from a surplus dealer with the intent of networking them over DECNET. However, a move to a new city required me to reduce the collection to two systems. The remaining PROs were scavenged for their parts and the rest discarded. Regretfully, I didn't have the space to keep several power supplies, chassis or cases. I did keep the hard disks, floppies and other cards as spares. The lower capacity disks (5MB and 10MB) were scrapped due to their low storage capacity. On examination the disks, and subsequently, the computers originated from the Canadian Prime Minister's office. The disks had P/OS 2.0, were not password protected, but were void of any confidential content other than a few personal resumes and files. I understand DuPont Nemours Inc., in Delaware, was also a large client for these desktops.
Fast forward to 2022. These two computers, let's refer them to System A and B, have been largely unused since the 1990s. In 1992, one of the PROs, running P/OS 2.0, was used as a remote support terminal from my home to dial into Scotia McLeod's VAX production systems for after hours support, this was my job then. Scotia McLeod is a Canadian brokerage firm (Capital Markets) and in the 1990s was a large VAX shop with several production and development systems based on DEC VAX computer and network technologies. There was one PRO380 at Scotia; it was the console for the VAX8500 production computer. This computer was in turn connected to a couple of HSC50s over a CI interconnect. Production storage was based on several RA90s connected to the HSC50s and we had a total of 10GBytes of shadowed production disk storage; a generous amount of storage in the 1990s that held the historical Scotia McLeod "Bond Universe" database but minuscule by today's storage standards. Today you could fit three copies of the database on a MicroSD chip.
If I was paged during the evening for a support call, I would remotely turn on the PRO in the basement via an X10 appliance switch, so that by the time I awoke, dressed and arrived from the 2nd floor to the basement the computer was up and running and ready for remote login. This setup served me well for several years. One of the advantages was that I could log the entire terminal session to disk so that I could have a log of all work and steps performed in various support and application installations. Further, an LA75 printer attached to the computer provided a nice hard copy audit trail of the work performed.
At one time, an HP pen plotter was acquired from the Scotia equipment surplus room and connected via a serial cable to the PRO. A graphics package was installed and this provided the ability to draw computer floor and equipment locations for the computer room. A serial mouse was connected to the PRO and this provided a way to draw shapes on the computer. Quite remarkable that a PRO350 based on a PDP11 processor could be used to do graphics using a mouse and pen plotter. I recall one company using such a setup for a shipbuilding application. At work, people were surprised about the provenance of the diagrams.
As of this writing there are fewer occurrences of DEC equipment for sale on auction sites. VAX, PDP-11, Rainbow and PRO systems are becoming ever more rare. In future, there will be fewer occasions to purchase these original DEC vintage computers. They are obsolete by today's standards, some are still in use due to the applications running on them and other simply kept running by hobbyists.
SYSTEM A
This PRO350 featured a single ST225 20MByte hard disk, an RX50 hard disk, a couple of memory expansion cards and a Telephone Management System (TMS) option. On powering up this PRO, the self test for the disk controller failed. After swapping the disk controller with a spare the same failure persisted. The failure was instead with the disk drive, a victim of "stiction". Seems that MFM disks such as the ST225, Maxtor and other disks of that time, have a habit of the heads sticking and being unable to move. This results in a diagnostic test failure of the disk system. Replacing the ST225 with spares resulted in the same error. These disks have to be spun occasionally to prevent the heads from sticking shut. Since the disk have not been used in almost 30 years, this effectively made them useless due to "stiction". Several disks were scrapped but three disks spun up correctly and the heads moved.
System A Cards| Slot | Module ID | Function |
|---|---|---|
| 1 | 00041 | RDxx Disk Controller |
| 2 | 00204 | RX50 Disk Controller |
| 3 | 001002 | Video Controller |
| 4 | 000034 | 128KB Memory Module |
| 5 | 000034 | 128KB Memory Module |
| 6 | 000041 | Telephone Management Controller (TMS) |
With the ST255 disk replaced, P/OS 2.0 was installed. The versions I am aware of for P/OS are 1.0, 1.7, 2.0 and 3.2. The P/OS operating system is based on the RSX-11 PDP-11 operating system. I had installation disks for the latter three as well as RT-11 and Micro RSX disks, which I have never tried installing. I installed P/OS 2.0 as it is small and allows a full install in less time than the 3.5 version (21 disks). Once installed I was confident that P/OS 3.2 would also work. Subsequently installing P/OS 3.2 which went well.
P/OS 2.0 is a single user operating system. Applications can be installed directly from floppy. P/OS 3.2, I realized is an operating system that allows multiple people to use the computer, one at a time, not concurrently. At login you are prompted to enter a username and password. The first time you log into P/OS 3.2 the username and password are both System . You will be prompted to enter a new password the next time you log in. There is an account creation utility that allows additional users to be added to the computer. As well, my experience with 3.2 has been that programs are best installed to a central program library and then from the library installed as an application for the user. In this manner each user can have their own set of programs as not all users will require all programs in the library for their role. Most of the P/OS 3.2 programs were first installed to the library and subsequently then installed from the library into an application group.
SynergyDEC introduced a windowing environment on top of P/OS, named Synergy. Applications that were Synergy compliant could be installed within the Synergy application which provided several drop down menus. Examples were a Calculator, a Data Manager, PROSE text editing and even a Chess program. More programs were available but not listed here.
Hardware IssuesSeveral hardware glitches were found during the installation. The video card was replaced with a spare. Shortly thereafter the RX50 controller failed the startup diagnostic. The video card eventually failed at startup as well. These modules were replaced with spares salvaged from the two scrapped PRO350s. However, I am convinced that part of the issue may be related to card seating (although reliable and expensive ZIF connectors are used) or dirty contacts either on the card or motherboard. These cards have been in a box for over 30 years, so degradation of EPROMs, capacitors or corrosion are all possibilities. One issue that persisted and took many card swaps to identify was related to the two memory boards connected to the PRO350 motherboard. Over time, as a consequence of many physical moves of the computer, one card had come slightly loose from the main board connector, thereby causing the startup diagnostics to fail. The error pointed to a video problem which I thought was due to the video controller card, but somehow was a result of the loose memory card.
SYSTEM B
The second PRO350 has a unique configuration. It features the DEC unsupported ability to host two hard disk controllers internally driving two 20MByte disk drives. The DEC literature does not mention this capability but it obviously works well. The same approach as System A was taken when installing P/OS. First 2.1 was installed; initialized the system disk and then followed by the 3.2 installation which once again initializes the system disk. This computer also had a DECNET controller and thus the P/OS Decnet 2.1 software was also installed under P/OS 3.2. An early version of Kermit (1.0) file transfer software (over serial) was also installed from an RX50.
The most difficult part of restoring this system was the stiction experienced with the hard disks. This system has two disks, these are stacked one atop the other. The lower disk, an ST225, is a 20MB disk with P/OS 3.2. The upper disk is a MiniScribe 20MByte disk, equivalent to an RD31, and is for user files. The ST225 disk has the head stepping motor sealed into the disk case. If the heads are stuck then there is really no way to move them and the drive is of no use despite knocking it or spinning it in an attempt to loosen the heads. The smaller MiniScribe hard disk has the head stepping motor on the outside of the case. It is possible to physically move the stepping motor shaft to nudge the heads to move and avoid the stiction issue. Although several weeks after successfully having both disks on-line, the MiniScribe disk failed and moving the heads would not resolve the issue.
A posting on a PDP-11 bulletin board from back in the 1990s indicated that up to three disk controllers could be added to the PRO350 and it all would work. One user planned to do this with several RD53s and use the PRO as network disk server for other PROs in the office. The configuration used here with two disks confirms the approach would work.
System B Cards| Slot | Module ID | Function |
|---|---|---|
| 1 | 00041 | RDxx Disk Controller |
| 2 | 00041 | RDxx Disk Controller |
| 3 | 001002 | Video Controller |
| 4 | 00204 | RX50 Disk Controller |
| 5 | 000034 | 128KB Memory Module |
| 6 | 000042 | DECNET Controller |
Similar issues with hardware on System A were found here. Some card swapping took place and re-mediated the startup diagnostic errors. The only DECNET controller I had in my collection, fortunately passed the startup diagnostics. This controller, even today, is quite difficult to source and expensive to purchase when found.
Click on this link PRO350 Images for a view of the pictures taken during this upgrade.
MICROVAX FILE EXCHANGE
One of the goals of the restoration project was also to determine how to exchange files created on RX50 floppies from a MicroVAX to the PRO. Both systems feature the RX50 floppy drive but the file systems are not compatible. However, I was informed by a someone on one of the DEC FAcebook user groups this could be done.The following procedure is shown for formatting a floppy on the VAX, adding two files to the floppy, moving the floppy to the PRO and reading them on the PRO350. In this case DUA2: is the floppy disk on the VAX (BigRED).
BigRED> allocate dua2: %DCL-I-ALLOC, _$1$DUA2: allocated BigRED> initialize/structure=1 $1$dua2: TEST2 BigRED> mount $1$dua2: test2 %MOUNT-I-MOUNTED TEST2 mounted on _$1$DUA2: (RED) BigRED> create/dir dua2:[000000.test] BigRED> dir dua2:[test] %DIRECT-W-NOFILES, no files found BigRED> copy mom.log dua2:[test]mom.log BigRed> copy defrag.log dua2:[test]defrag.logEnd of article.