DEC Professional (computer)

This page has been nominated for cleanup for the following reason: Conversion to wiki markup is not yet complete. There may be formatting errors. Compare to the pre-formatted archived version if the information presented appears unclear.. Please edit this page to improve it. See this module's talk page for discussion.

DEC Professional Computer Frequently Asked Questions and Miscellaneous Trivia

The Digital Equipment Corporation (DEC) Professional 300 series are pdp-11 workstations that were introduced in 1982. A number of computer history enthusiasts have collected, restored, and continue to operate these obsolete computers as a hobby. This FAQ began in 1992 as a resource for restoration of these machines.

Whenever possible names of contributing individuals are placed after each answer. An effort has been made to retain attribution of early contributors, but email addresses have been expunged to protect the innocent from spam.

Please note that much of the information is long out of date and many of the links are broken. Also, some formatting may have been munged in the conversion from usenet format to wiki markup. See the archived version when in doubt. There is some reformatting that remains to be done.

This FAQ was originally compiled and edited by Chaim Dworkin in 1992. It was then maintained by Michael Umbricht starting in 2002. It was uploaded to this wiki on 19-JAN-2016 by Michael Umbricht (mikeu) and is now edited as a community effort. Additions, corrections, and constructive comments are welcomed. Please sign your contributions by placing --~~~~ at the end of your edit. If you have a question that you would like answered place it in the section near the bottom.

If you have any suggestions on how make this page more useful (such as splitting the questions into subpages, formatting, etc.) please leave a message on the Discuss page by clicking on the tab at the top.

See the view history tab for contributions after Jan. 19, 2016.

Revision history

Revision	Date	Editor
Vol. 4 No. 2	04-OCT-2002	mikeu
Vol. 4 No. 1	18-SEP-2002	mikeu
Vol. 3 No. 1	05-MAY-1994	Chaim Dworkin
Vol. 2 No. 2	03-SEP-1993	Chaim Dworkin
Vol. 2 No. 1	14-JAN-1993	Chaim Dworkin
Vol. 1 No. 2	05-AUG-1992	Chaim Dworkin
Vol. 1 No. 1	10-FEB-1992	Chaim Dworkin

I have just acquired a DEC Professional 350. I really don't know what it is. What operating system will it run? What sort of CPU does it have?

The Pro-300 was the engineering workstation of it's time. There were 3 models: the 325, 350, and 380. The 325 and 350 shared the LSI-11/23 cpu. The difference between them was that the 325 was floppy based, while the 350 had a hard disk and a bigger power supply. It can handle the RD51, RD52, and RD53 drives (10, 20, and 71MB, respectively). The 380 was based on the LSI-11/73 cpu. Available options include color monitors and ethernet. Runs 16 bits at 3 Mhz.

Basically, the PRO-300 is a personal PDP-11, with computer and terminal in a neat pc package. It has an expansion bus, the CT-bus. Unfortunately, it never really caught on, DEC marketing being what it is, despite being a contemporary of the IBM-PC and being priced about the same as the original IBM's. A friend of mine ran some benchmarks on his 350 , and determined it's about 1/3 to 1/2 as fast as a microVAX-II for non-virtual-memory numerical applications.

For a while after they stopped trying to sell the PRO's to the masses, DEC continued to use them as the central console system for the big VAX Clusters in the 8000 series. They also sold them to various OEM's as process controllers and graphical front-ends for large control systems. It was a cheap way to get an 11/23 or 11/73, if your expansion needs were limited and you only needed one (or perhaps two) terminals.

Operating systems: the worst thing DEC did to the PRO's was putting a brain-dead menu-driven version of RSX-11M+ called P/OS (Professional Operating System) on them. Now, RSX-11M+ is a nice operating system, as are the other PDP-11 operating systems. But who wants to be limited to a miserable, slow menu system on a nice little computer like the PRO-350? The only saving grace of P/OS is the PRO/Toolkit, a development environment which includes a partial DCL command shell. But you still boot up at the menu level, and it's only a limited shell. Fortunately, RT-11 quickly became available, as did a couple of versions of PDP-11 unix. The one I remember was VENIX, which was put out by VentureCom. It would be nice if someone at Berkeley put their unix on the PRO...

As for P/OS (and a version of RT-11 which actually runs _under_ P/OS), it's still available from DECUS, basically just for media charges. They also have printed documentation. Like DEC operating systems in general, P/OS has excellent and voluminous documentation. I have 8 3-inch 3-ring binders on my bookcase, plus various smaller documents. Everything you ever wanted to know about the Professional 300 series...

DECUS also has a C compiler that runs under the PRO/Toolkit, as well as a BASIC. They don't have the PRO Fortran, possibly because it's the same as the regular RSX Fortran (speculation).

Personal opinion of Steve Mitchell

«if DEC hadn't crippled the PRO with P/OS, but had sold them as software development workstations for the PDP-11, offering versions of all the PDP-11 operating systems (RSX-11M, RSX-11M+, Ultrix, RT-11, RSTS/E, IAS), they could have sold lots of them. It's a great way to move your system hackers off the main production machine without having to buy an expensive machine just for the developers. Unfortunately, Our Favorite Computer Company has always been stronger at engineering than marketing. sigh.»

Personal opinion of Glenn Everhart

«The pro is more akin to a mini, and will do some nifty multitasking if you choose to use it...with HARDWARE protection of each task against the others, hardware floating point, etc. etc. There's a trick to booting off a floppy to regain control. Also [zzsys]firstappl.ptr should probably be deleted, and the pro native toolkit is a MUST. Given the native toolkit, the Pro is a quite respectable computer. The major lossage of a pro is that I/D space separation is not supported by P/OS, which limits you to 8 page registers, making address space manipulation more of a chore.»

The PRO-380 is in fact a faster PRO-350 - about 5 times as fast I think. The 350 uses the PDP 11/23 chip (F11) and the 380 uses the PDP 11/73 chip (J11).

It also has extra memory bitmap pages, faster graphics and comes as standard with 512kb on the mother baord. The ram expansion cards can go in any slot. As I remember it, the 380 does not have a video card as all the video is on the mother board.

If you do MACRO-11 assembler coding you'll certainly discover that the F-11 doesn't really check for odd address errors, while the J-11 does (traps thru vector 4). Also, the J-11 includes the ability to separate Instruction and Data address spaces, and includes a third addressing mode (Supervisor). As I recall, P/OS takes advantage of some but not all of the additional features (not entirely sure exactly which ones appeared in which P/OS version). (Graeme Thomson)

Another 380 feature is that you can divide memory for applications into I-space and D-space (I = instructions, D = data), allowing your programs to use twice as much memory as in the 350 (as long as half is instruction and half is data, of course).

Other potential OS platforms (anything but POS!) were PRO-Venix (a UNIX of some ilk), RT-11 (and the non-DEC, RT-11-like TSX), and some flavor of MUMPS. Also it can be a decnet end node. (Dean File, Chapel Hill, NC)

DEC has various PDP11 languages that apply to the pro...stuff like BASIC (distinct from the DECUS Basic dialect), Fortran 77, Cobol, Datatrieve, and various others. DEC compilers are fairly cheap on the pro...probably even more so now that the pro is, er, "stabilized". The two DECUS pascal compilers, NBS and Swedish differ in that NBS generates faster, more compact code, while Swedish is more standard-conformant. (Turbo is not very standard conformant, BTW.) Two good Pascal compilers, a BASIC interpreter, a C compiler, FORTH, FOCAL, etc. are available. Also the DEC F77 compiler and mucho other stuff. (Glenn Everhart)

A couple of years ago, Digital donated all of the latest copies of their software for the PRO-350 to the DECUS library. This included P/OS 3.2, Synergy Windows for the PRO, DECNET, PRO/BASIC, the Tookit w/ DCL, PROSE Plus word processor, etc. This software is available on RX50 floppy media from the DECUS library. Copies of the complete documentation set are also available. (Kurt Wampler)

DECUS can be phoned at 508 480 3418. Join; it's free. It's the Digital Equipment Computer Users' Society. There are at least 95MB of diskettes of stuff packaged for pro between the library and the DECUS PC SIG. Much of it REQUIRES the native toolkit (which supplies little niceties like a decent command interpreter and a n assembler and linker...and the system symbol table file!). The DECUS library catalog, which you'll get free when you join, lists a bunch of pro offerings on rx50. I believe the 350 has a semi-weird disk interface though. My personal use for a 325 would be to run RT11 on it at most, since RT11 runs reasonably well off floppies. P/OS (which is to say, slightly modified RSX11M-PLUS) does not. There's lots of software for rt11 also.

The basic engine isn't really all that slow; there IS however a LOT of cruft in p/os. (Not for nothing did that OS get the nickname Piece Of S**t because of the menu orientation and misfeatures that distinguish it from RSX11M+.) With some of the free tools you can bypass much of that though. There's also a quite decent memory disk for p/os on the RSX SIG tapes. When you get your DECUS catalog, check out the pdp11 areas as well as the pro areas. Most of the stuff applies to pro. There's a working group in the RSX SIG whose mission is to make software from sig tapes available on floppies or other media (the "Other Media" working group...it actually DOES function). I'm continually surprised how many people with DEC processors don't know about DECUS. No wonder you use your pro as a terminal! sigh... (Glenn Everhart)

There is now an anonymous ftp site for PDP-11, PDP-8, Professional and Rainbow machines on <ftp://ftp.update.uu.se/pub/>

The site is located on a PDP-11/70 running BSD 2.11, but will perhaps later be moved to a VAX8650 with BSD 4.3. All software for the Professional, is from the DECUS library. (Tom Karlsson)

The amount of memory is really dependant upon where it is going to be installed: In the Mother Board /or/ in one of the Expansion Cages, that is, along with the disk controllers, Tms etc. locations. Expansion Cage: The memory board are configured for a :: maximum of 256K ::- you can install as many as you want this way (say to about 3 units of 256ks.

Mother Board: Here the modules vary; they are one the two module-sizes, that is, 128k boards or 512k boards. System normally comes with 2 of 128ks, thus, making a total of 256k in mother board and the other 256k board in the expansion cage: making a total of 512k - a basic PRO 350 system. You can replace one of 128ks with one 512k new board. This 512k is actually made for PRO380; but You can in Your 350, replace one 128k and substitute a 512k safely.

--tung

The DECNA card has 128Kbytes of RAM. This memory is not just used as buffer space for Ethernet packets; the memory is dual-ported and can be accessed by the CPU and other devices on the bus.

Maintenance Services does not appear to "count" this memory, but it is seen and used by P/OS.

For example: the PRO/Tool Kit command SHOW MEMORY reports 320k (words) yet the Maintenance Services Configuration Display reports 512 kilobytes of memory (system total)

--mikeu

Here is a how to guide for memory upgrade of the PRO 350 at home. At $2.00 per chip $64 will get you a 1 Megabyte of memory on your PRO and free up 1 expansion slot if you remove the memory board. Each board goes from 128K -> 512K and you could do 1 or both in the PRO.

Professional 350 Daughter Board Memory Upgrade

The Professional 350 (PRO 350) requires 512Kbytes of memory in order to start P/OS. In the least costly configuration this requirement is supplied by two 128Kbyte daughter boards located on the motherboard underneath the hard disks. These boards are elevated above the motherboard on spacers and are easily recognized. An expansion slot usually holds another memory Board with an additional 256Kbytes. Together these boards form the 512kbytes of memory needed in the minimal system configuration.

Because of advances in memory chips and DEC's useful fore-sight it is possible to install 1024Kbytes using only the two daughter boards. This may free up a slot or just give you additional memory. This file describes one method used to upgrade the memory boards.

The upgrade requires 32 256K X 1 dynamic refresh memory chips with at least 150ns access time. The original chips are not in sockets so they have to be desoldered. To make desoldering simple we used the following technique.

1. Remove the memory boards from the PRO.
2. Pre-heat a burner on an electric range to about medium heat.
3. Get your pliers or an IC extractor ready.
4. Each board has 2 rows of 8 chips each. The chips will be removed 1 column at a time (2 in each column). Hold the board so that a column of chips is over the hottest part of the burner. When the solder his hot enough simply pull the column of 2 chips out.
5. Remove the board from over the burner an allow it time to cool. If you try to do too many columns at one time you will scorch the board. Minor scorching may be expected depending on the amount of patience you have concerning getting the burner temperature correct and how many rows you attempt to do at one time. If you are careful enough you should be able to do it without scorching the board at all! Any time you touch the board to the burner you can expect scorch marks.
   
   Note: Sometimes the pins on the old memory chips are bent outwards on the bottom of the memory board. This makes them harder to remove. Straighten them if you can.
   
   Note: Don't worry about the capacitors, they may fall out when the solder is molten. The can be replaced when the new chips are inserted.
   
   
6. After you have done all columns and removed all the old memory chips you still have to remove old solder. Our homebrew method of doing this is to use a vacuum leaner as a solder sucker device. Turn the vacuum cleaner on and hold the nozzle between your knees. Using a soldering iron heat the solder on the pin hole a few inches away from the vacuum cleaner nozzle. When the solder is molten bring the board down on the nozzle so that the nozzle is centered under the hole. This sucks the solder out but it has a tendency to splatter it on the underside of the board too.
7. Use the soldering iron to collect the splattered solder into the pin holes on the other side of the board and then re-heat the pin hole and do step 6 again. After about three times the pin holes are clear from old solder. It could take longer for the first board until the technique is developed.
   
   Note: Solder will accumulate on the inside of the vacuum cleaner nozzle. I isn't very much solder but someone's wife could get mad about it. We don't know what will happen if the nozzle is made from plastic instead of metal as it was here. Perhaps some aluminum foil wrapped around the nozzle would solve both problems.
   
   
8. After steps 6 and 7 you should have a board with all the all the pin holes free of solder so that you can insert the new memory chips. Certain holes which are part of large traces are take more effort to unsolder because there is more solder in them. All holes need to be open in order to insert the new memory chips. Do the capacitor holes as well if necessary.
9. Place the new memory chips in the old holes and solder them in. Make sure they face the same way as the originals. You need only solder the chips from the bottom of the board, the plate-through holes will do the rest.
10. There are two jumpers that need to be soldered to enable the extra memory. They are labeled J1 and J2 on the board. Cut a piece of wire, strip the ends and solder the ends across the jumpers.
11. Reinstall the board into the PRO.
12. The P/OS toolkit "show memory" command should show 512K WORDS (1024K bytes) of memory with only the two mother boards installed.

We have upgraded four boards this way so far and not one has failed so far. All the memory chips we used were tested in another computer (one with sockets) before they were installed. You may want to solder sockets into your memory board instead of the chips themselves. If you have bad memory when you start up your PRO it would be much easier to replace a socketed memory chip than a soldered one. Although we have singe'd a few boards perfecting this method the damage was only cosmetic. Removing the memory chips over the burner is the most difficult part of the operation.

--Todd Miller

Along with the Pro-380 I received three RAM boards. I know that the slots in the Pro computers are dedicated, RAM goes in a specified slot, video in another, etc. Can all three RAM boards be put in and be recognized?

Actually, if I remember correctly some of the boards were slot dependent, others weren't. Additional memory is useful up to a point (J-11 max physical memory address is 22 bits) depending on what's already in the system. The base memory is daughter boards on the CPU motherboard, expansion memory can be added as modules in the CTI bus. The memory modules should self configure and play (if it all works :-).

--Bruce McCulley

Possibly. The standard method of conversion is to purchase the upgrade kit which consists of new motherboard, stronger power supply, and hard drive with hard drive controller card. It costs a lot of money. I tried to take a shortcut and simply put the hard drive controller card into the Pro 325. DEC glued plastic over the connector edges of the slot that the HD controller card fits into in order to discourage people from just inserting a drive. You have to spend some time carefully cleaning the connector edges of glue and plastic pieces (DEC used a strong glue). I called DEC and asked them if it was possible and the person who I spoke with said he has heard of only two people who succeeded. I did not, but my HD was bad to begin with.

--Chaim Dworkin

Answer: No. The F11 and J11 chips are wildly different. If you could scrounge a Pro380 system board, you could probably replace the 350 system board with that.

IMHO, having a 380 doesn't give much additional return. Oh sure, the chip is much more capable than the F11, but with super mode, I/D space, and cache permanently turned off, what real gain is there other than a little bit of CPU speed? I find the stupid disk controller in my 380 to be more of a problem in throttling the performance of the system.

BTW, DEC did once put up genuine RSX-11M-Plus on the 380. The conditionals are still there in the Exec source to make it work. Haven't got around to trying it yet, but one of these days ...

You can build a bootable PRO floppy on an 11/23+, assuming that you have all the pieces (like the distribution kit). The PROs floppies are called DZ and the winny is DW. You also need the PRO's screen driver (it's a bit-mapped screen) called PI. Finally, you have to have either RT11FB or RT11XM; SJ won't run on it :-(.

Basically, you should copy (SWAP,RT11XM,DZ,DW,PIX).SYS to the floppy and then COPY/BOOT:DZ to the floppy. You should then have a bootable RT-11 diskie for the thing. From there you can format the hard disk (if you copy FORMAT.SAV over) and install on the hard disk.

--Roger "I converted a Pro from P/OS to RT-11" Ivie

>> 2. How does a pro350/380 boot from a floppy? - where shoud
>> stuff be stashed? how does the pro know where to go??
>> thanks for your patience..
>
>       For both systems, the boot block is block 0. This is where
>       you'll find the first executable code for the system.

>From DEC literature on the Professional 300 series:

The boot block location for 5-1/4 inch diskettes

Track  1 (Track numbers start at 0.)
Sector 1 (Sector numbers start at 1.)

You also need the added magic header numbers at the start of the boot block to be recognised as a boot block.

--Ken Wellsch

In further discussion of the above message, Megan Gentry writes:

>Can you give specifics about the magic numbers required for bootability, 
>and/or a DEC spec for what it's called?

There are no real magic numbers. There are values which are required in certain words of the boot block (block 0), but they will be filled in by the operating system when you initialize the volume with the file structure the system plans on using.

The first word (offset 0) of the boot block should contain 240 (which is a no-op). The second word generally contains a BRanch instruction to a location elsewhere in the first block.

On entry to the boot code, the rom bootstrap generally sets R0 to contain the unit number of the unit being booted, and R1 contains the device base CSR.

--Megan Gentry

Charles Lasner replies to Gentry's message:

Apparently this isn't true. Certain bytes of the boot block on an RX50 have to conform to something. It was imposed on the DECmate as well, but I've not seen any "official" reference to it. The DM situation is quite troublesome to the prevailing software there and actually significantly hamstrings certain programs!

The ROM's of the DM clearly check for validity using a subset of these values, as if the full spec comes from elsewhere. The values aren't random, but rather are always present in a predictable manner. (PS: they aren't code or data to a boot program or anything like that. In fact, their mere presence hinders the boot process. Clearly someone insisted they be present for "compatibility" with something. It's that compatibility issue I seek here, etc.)

What you answered is unrelated to this question. Of course certain other bytes have to be what they have to be just so the device boots at all! But these values fall into the "magic numbers" category, etc.

--Charles Lasner

I just created a bootable RX50 for my PRO using RT-11 and the first few words contain the following:

        0/ 000240               nop
        2/ 000415               br 36
        4/ 000000
            .
            .
        32/042020
        34/115420
        36/000400               br 40
        40/000137               jmp @#
        42/000556                   556

I'll have to check the sources for why the branch to a branch, but that's basically the start of the RT bootstrap for a DZ volume (RX50 for the PRO) the next section of the boot starts at offset 556 (location 556 when loaded into memory).

Just wanted to point out that the supposedly *magic* numbers aren't so *magic* or required.

I guess the bottom line in all of this is - what are you trying to do?

If you have a booting system, then it *should* be able to produce more bootable volumes. If not, then its sort of a catch-22, you can't produce a bootable volume without the running system and you can't get a running system without a bootable volume.

--Megan Gentry

Okay, I'm in my office looking at the manual "CTI BUS: Technical Manual" EK-OOCTI-TM-002 in appendix B titled "Boot Block Standard for Professional 300 Series" and it has this (so people can translate):

B.3 Boot Block Contents

(All numbers are in octal unless otherwise noted.)

Byte 0          240             Type 1 boot block or
                0               Type 2 or 4 boot block or
                241-277         Type 3 boot block
Byte 1          0               Type 1, 2, or 3 boot block or
                20              Type 4 boot block
Byte 2          N               Offset from 0 to identification area,
                                in words
Byte 3          1               System volume or
                0               Data volume
Byte 4          4               Type 1 data volume only
Byte 5          1               Type 1 data volume only

unfortunately the Identification Area description goes on for two pages.

--Ken Wellsch

You don't. DEC, in it's wisdom, decided to take advantage of a captive audience and get rich off selling preformatted disks to Pro owners. They built a machine incapable of formatting disks. You'd think that would leave an opening for some enterprising hacker to write a formatter. However, I've been told the drive controller chips on earlier models of Pro are totally incapable of formatting. But there is an out.... You can format a generic disk on a Rainbow using the /I option to the FORMAT command. Some people, with lots of Pro's, bought a Rainbow JUST to make disks. Of course, nowadays, a copy of Media Master from Intersecting Concepts will do the job on any AT clone...

--Chaim Dworkin --David Lesher

But this may not even be the best way to go about it, and it costs money besides. The sections below address this issue!

There was a firmware update for the PRO's RX50 diskette controller that allowed it to format its own floppies, but it was never released to customers. The FORMAT command under P/OS 3.2 is all set up to format the floppies if it finds the right version of firmware in the controller card. I have tried since the Fall '91 DECUS Symposium to reach the old manager of the PRO development group in Digital to see if he would be willing to release that firmware through the DECUS Library, but he never responded to my e-mail and I haven't been able to obtain his telephone number; all I have is his name and e-mail address.

The PRO's floppy disk interface has a Western Digital chip on it which is fully capable of formatting, but a microprocessor (Intel 8041? if I remember right) sits between the WD chip and the bus, and only the repertoire of commands provided by this uP chip are passed through to the WD chip.

DEC's [unforgiveable] decision to not allow the PRO to format its own diskettes was based first on repeatability problems with the "A" version of the RX50 drive; but even after those problems were ironed out, the marketeers at DEC appear to have fixated on the meager $$$ they would make from selling RX50 media (HAH!).

So...PRO users of the world (if there are any of you left out there) UNITE! Let's see if we can brainstorm an effective way to coax Digital into releasing the new firmware for the RX50 controller. If I could just get my hands on one set of the ROM(s), I would arrange to have them duplicated and make them available at cost to anyone else in the world wanting the ability to format their own diskettes.

Note that this is likely a prototype, and is more likely an 8751 than an 8051. An 8751 can be read/blasted just like an EPROM, so if one copy can be procured, it most certainly can be duplicated!

--Kurt Wampler --Charles Lasner

There are some software packages available which proport to allow formatting of RX50s on MSDOS 5 1/4" high density drives. Here is a short review of three of those packages.

Please note that this review is meant for all DECmate/Rainbow/PRO users, so some of the info is not directly of use to PRO people, but in the interests of all RX50 users, it is provided with all of the relevant details, since we are talking about RX50 support of DEC machines using PC's, etc.

I have been playing with 22DSK138.ZIP and RAIND112.ZIP and FDFORM18.ZIP long enough to give some additional info regarding Rainbow/DECmate RX50 formatting and related issues.

FDFORMAT 1.8

There are some problems with the current release that have always been in at least the two previous versions when attempting to format RX50 diskettes. You use the command:

FDFORMAT A: /Y:2 /T:80 /N:10 /H:1

to format for RX50. The /Y:2 is to force a two-sector stagger per track to speed up transfer on all systems except -11/pro. /H:1 means a one-sided disk. /N:10 for 10 sectors and /T:80 for 80 tracks.

The resultant disks are marginal, especially to revision A and B RX50 drives. Symptoms include data CRC errors right out of the formatter when test reading the diskettes, and the inability to write data that won't read back with data CRC errors. The problems worsen with higher track numbers, but often start right at track 0 or 1. Using MD1DD media instead of MD2D makes a more reliable disk, so this was assumed to be the problem.

This has been confirmed as incorrect.

There are several bugs in FDFORMAT that directly affect RX50's:

If the floppy is already formatted without error for all 80 tracks, then FDFORMAT will merely verify readibility on every sector. Then the directory info is written by ordinary writing (not formatting) means as previously discussed. (Meaning suitable only as a strange variant of PC-DOS-specific MS-DOS, not DECmate/Rainbow MS-DOS. You then use RX50INIT or move to the DECmate or Rainbow and use the FORMAT command or whatever.) Thus, all that FDFORMAT has done at this point is to verify that a previously formatted disk is indeed readable.

What this means is that if a diskette is already low-level formatted, FDFORMAT will reliably determine that it can read the disk completely. Since the status line always shows a "V" for Verify in this case, you can be certain that the diskette is readable. However, no attempt is being made to confirm that the stagger/slide and interleave factors match the command line values! Thus, you still don't precisely know what the diskette looks like!

If FDFORMAT gets even a single error for any reason, it will change over to an actual low-level format mode. This is noticeable in that it runs much faster. And the status line will revert to the "F" for Formatting followed by "V" for Verifying, which actually goes faster than the reliable verify-reading, because it turns out that the verify read after the format is in fact flaky, and often misinterprets returned errors! In fact, FDFORMAT can be fooled into believing it correctly formatted *and verified* a damaged diskette readable nowhere! Smarter formatters will deal with the very real errors, but FDFORMAT gets fooled!

The resultant diskette is the unreliable type described above. Using the /U switch will force this to happen as well, but is a normal feature of this switch. Also using the /W switch to rewrite the prior contents of the sector also works, but since the sectors are reformatted, the same problem results. The /Q "quick" format works fine, since this isn't really a format, rather a directory initialization.

Thus, to determine if the diskette is usable, another program has to read the diskette after the fact. FDFORMAT itself can be used, since it will always attempt (unless /U is invoked) to do the "quick" format (which is actually slower!) and you can observe that only "V" for Verify appears throughout the verifying, etc. Alternatively, the diskette can be verified with the Norton DT program or the analogous CHKDSK /M feature that is unique to DR-DOS 5.0 (alas, dropped in 6.0 :-(, but can be lifted from there and run under 6.0 if desired :-).) to confirm that it's actually readable using either FDFORMAT's default MS-DOS layout which differs from DEC's RX50 MS-DOS allocation, or alternatively, use RX50INIT with RAINDOS, or use the DOS 5.0 or DR-DOS 6.0 FORMAT command through RAINDOS and specify the /Q for Quick option which will just init the directory for DEC MS-DOS purposes, thus allowing DT or DR-DOS 5.0's CHKDSK /M to check out the disk as an actual DEC MS-DOS RX50 diskette. Either way will ensure the disk is readable; the latter has the advantage that bad spots will be marked in the MS-DOS directory should this be the intended usage, and CHKDSK can confirm this was accomplished either way (indication of bad sectors, etc. of CHKDSK's report).

In any case, if the disks are being prepared on a PC for the purposes of being brought to a DEC system, it is desirable to check the reliability of the media and the PC's drive while still at the PC end where it can still be dealt with, as opposed to being at the DEC system end and being stuck with bad media, or worse, unreadable copies of programs!

One good thing FDFORMAT is good for is to weed out bad floppy drives for the RX50-oriented purposes:

A PC-specific usage of FDFORMAT is to create disks that actually achieve 1.48 MBytes on a HD 5.25" diskette normally formatted to 1.2 MBytes. This can be accomplished using the command:

FDFORMAT A: /Y:2 /T:82 /N:18 /U

A brief explanation of this command is that it achieves a 2:1 interleave diskette where the unreferenced sectors of the other half of the interleave are used to replace a portion of the gaps normally provided to allow 1:1 interleave usage to successfully find the next sector. In 2:1 this is obviated, so the space can be given back to allowing more sectors. If the drive is truly up to snuff, 18 sectors can fit instead of the normal 15. The /Y:2 parameter has the usual meaning. 82 tracks are usually available on such a disk as well, so that the 5.25" diskette now holds slightly more than the usual capacity of a 3.5" HD diskette! (However, the same technique ups the 3.5" diskette's capacity to 1.72 MBytes!)

If the drive can't handle this format, it likely can't properly format RX50 media either, since both formats depend on minimal drive speed jitter to work. (RX50 specs are actually tighter than IBM's original DD drives, since they only had originally 8, then 9 sectors, while DEC uses 10. However, most good drives are up to the task, so you can "weed out" the junky drives with FDFORMAT this way, etc.) Note that this usage requires HD diskettes, as opposed to the RX50's requirement of DD-type media!

An additional problem with the usage described above is that even though the /Y:2 option was given, it is ignored. The unreliable disk, when actually formatted, does apply the /Y:2 option to the new disk format, so the stagger is now present, but FDFORMAT attempts to merely verify the format in this usage to avoid formatting. The stagger/slide factor is not checked for, and can be any value. The disk will not be reformatted merely because it was a different stagger; of course if an error occurs it will be reformatted with the designated value.

Yes, to ensure a stagger/slide and/or interleave factor being as desired, the diskette must actually get formatted. /Q prevents this, and /U ensures it and leaving either out leaves it to chance, but since FDFORMAT can misinterpret certain I/O errors, it tends to err on the side of just reading the diskette, which means that it likely never verifies the stagger/slide or interleave, just the basic readability, etc.

So, FDFORMAT as currently released is of no useful value to any RX50 user, since the reliability suffers so terribly. However, if used intelligently as a prototype disk creator, and then passed through TELEDISK, the resultant disks are superior. Note that FDFORMAT can be used to make "pre-master" diskettes for TELEDISK's usage, and then TELEDISK makes all subsequent usable RX50 media, etc.

Additionally, some users report problems getting the FDREAD/FDR88 programs to load properly, preventing FDFORMAT's use entirely (except for "vanilla" PC formats).

This also affects the ability to create the extended-capacity HD diskettes which may be useful in and of themselves, but also allows some confidence checking on the drive's condition, so it is an important subject.

FDR88 for XT's, and FDREAD for all 286 and up machines can have problems getting loaded if these programs misinterpret the size of available memory, especially in the case of upper-memory and high-memory area systems. It does occasionally get it right, but in some cases, the galling message: "TOO MUCH MEMORY" appears, and cannot be cleared, even following the documentation to try loading the program multiple times. (Actually, the documentation merely says to try a second load attempt. In fact, in certain systems, it might work after as many as 20 attempts to load it, each one wasting a small amount of memory.)

The solution may well be to run a "bare-bones" system, such as a bootable floppy DOS system which lacks the memory juggling frills. This is still a viable environment for FDFORMAT, and all necessary files can easily fit on a bootable HD diskette. FDFORMAT allows a pause between execution invocation and formatting the diskette, so you can take out the system disk and replace with the disk to be formatted, etc.

The problems definitely come about when using MS-DOS or DR-DOS version 5 and up. Sometimes it is possible to shell out of another program and then run FDREAD in the now smaller memory space, etc. Experimentation is desirable here!

Hopefully, the author can be contacted for fixes to this otherwise useful program.

In spite of all of its problems, FDFORMAT still gets you viable master diskettes for variant formats that improve performance on many O/S's as found on RX50's on various machines. All MS-DOS formats can get a performance boost using some aspect of FDFORMAT, and if there is an MS-DOS board for the PRO, this issue certainly applies there. Also certain CP/M layouts can definitely benefit. Admittedly most mainstream PRO usage is for the standard layout where the drivers map the disk sectors instead of having a hardware sector reordering, thus any standard formatter is sufficient in those particular cases, but for all of the myriad variants out there, FDFORMAT (coupled with TELEDISK) is invaluable.

There is one additional use of FDFORMAT: If the O/S is MS-DOS V4.01 or older, there is no provision in the FORMAT command to override the current format on the diskette. Often you can get into a situation where FORMAT will not change the (incorrect and possibly only partial) format on the media which is in conflict with what you are attempting, etc. Since FDFORMAT always supports the /Q and /U switches in the same manner as the newer DOS versions, it can undo these problems should they occur, etc.

22DSK138

This is a useful package for converting many CP/M formats to/from MS-DOS. The DECmate and Rainbow are directly supported and can be set as the default CP/M types. The program can be configured for use with the TEAC FD-55F drives which are essentially two-sided RX50 types. (FD-55GFV and GFR can be configured as FD-55F equivalent.) The program can run on an XT configured with HD or FD-55F drives as well. Note that FD-55F doesn't require a 3-speed floppy controller, thus any XT can have an FD-55F added on if necessary.

22DISK also formats the CP/M disks it handles, so RX50's can be formatted directly. As a high-level consequence, a CP/M directory initialization is also performed. The resulting disk is usable anywhere an RX50 can go, and is quite reliable.

Note that there are no formatting options as in FDFORMAT, just a standard low-level-format RX50. But a reliable standard format is better than an unreliable "better" format. So, this is a recommended way to format RX50 on a PC.

Again, only if the application is for a standard format RX50, which isn't always the case. 22DISK will note errors while formatting though, and is an invaluable tool for weeding out flaky media, etc. even if ultimately non-standard sector layout is needed later, etc.

RAINDOS 1.12

For MS-DOS DECmate and Rainbow users, there is an alternate route: RAINDOS is a device driver from the same vendor as 22DISK, and apparently incorporates the same low-level disk support.

Unlike RX50DRVR, RAINDOS can work correctly with CHKDSK and most importantly DOS's FORMAT command. You still get a standard low-level RX50, but the resultant DOS structure is entirely compatible with DECmate and Rainbow MS-DOS, so programs like RX50INIT aren't required. Further, since DOS's FORMAT command was used, any actual errors will be incorporated into the FAT structure, so diskettes with bad spots can be used. (RX50INIT does a no-check perfect directory initialize. FDFORMAT does check for errors, but records them in the incompatible PC-like DOS structure that has to be replaced for DEC compatibility, so you have to observe that FDFORMAT found no errors, and must reject disks with errors.) The manual claims there is the same FD-55F support as in 22DISK.

RAINDOS has several problems:

It doesn't work under DR DOS. All but the FORMAT command actually does work there, but attempts to format a diskette terminate with the error message "Drive already locked to another program".

To clarify this issue:

If a FORMAT command actually causes a low-level format to be attempted, and the O/S is DR-DOS 6.0, the command will fail with the above noted error message. If the FORMAT command merely does a "quick" format, either due to FORMAT's guesswork or the /Q switch, then the disk is merely initialized and not formatted (a "high-level" format always occurs, but a "low-level" format will not under these circumstances.)

It doesn't work with DOS 4 and 5 booted to the A: floppy which is also the drive used by RAINDOS for its RX50 operations, unless DOS is used exclusively on 360K diskettes. As with other floppy-based systems, there are times when you get a message like "mount a diskette containing \COMMAND.COM in drive A: and press ENTER". This is perfectly normal for this limited environment. The problem is that if you have HD drives, (most machines have HD A: drives), then you would prefer to read HD diskettes on them. Once booted up and in the mentioned situation, all further attempts at using an HD floppy yield a GENERAL FAILURE error message that will not clear. You can mount a low-density floppy to get COMMAND.COM reloaded, but all further access to the A: drive disallows HD diskettes.

For hard-disk DOS 4 and 5 users, none of this is a problem in general, but since I use DR DOS 6, I had to boot a DOS 4 or 5 floppy :-(.

There additionally seems to be some speed/timing related problems with RAINDOS in that certain file transfers take inexplicably long times to read or write. The longer the file, the more likely the problem is. Also, when RAINDOS is loaded, the FORMAT command for normal DOS formatting may take inordinately long, often accompanied by extraneous seeks/recalibrates between track formats, although totally harmless otherwise; the resultant diskettes are formatted correctly.

Overall, if the goal is merely to format RX50 media, 22DISK is the best route since it runs under any PC-based DOS system. For many users, RAINDOS is even better, but clearly not for all users.

When/if FDFORMAT gets fixed, it will be a better way through that portion of the problem. BTW, RX50DRVR, while not able to format, does run under DR DOS 6, as does RX50INIT. RX50INIT cannot run under DOS 4 and DOS 5. RX50DRVR has some quirky problems partially avoidable there as well. There is also word that RX50DRVR is being upgraded to support formatting and DOS 4 and 5's CHKDSK. It currently can be used with DR DOS's CHKDSK as well as DOS 3.x.

Apparently, RX50 support is hardly a "static" issue :-).

Here's another possibility:

There is a shareware product from Italy called 800. I think the viable current version may be called 800II standing for 800 version 2 in Roman numeral notation.

This program essentially is an alternative to the FDREAD portion of FDFORMAT and allows the MS-DOS 5.0 and DR-DOS 6.0 FORMAT command to specify parameters that otherwise could not be performed. For example, it is possible after the 800 TSR is loaded, to invoke the DR-DOS 6.0 FORMAT command:

FORMAT A: /T:80 /N:10

This will create an RX50 format diskette with one difference: it is double- sided. Due to limitations of the FORMAT command itself, the /1 option is not allowed for any format other than the /4 format. (I.e., to make a single sided 160K or 180K diskette from what would otherwise be a 320K or 360K diskette.)

Such a diskette can then be used with any of the high-level formats to make it RX50 MS-DOS compatible, or merely tested for viability before being passed over to an RX50-based DEC system. The only interesting aspect is that it could report errors on the other side of the disk, i.e., the side ignored by the RX50!

Further testing is required to determine if 800 can interact favorably with FDFORMAT in lieu of FDREAD/FDR88. In any case, 800 has no problems getting loaded by MS-DOS 5 or DR-DOS 6, and reacts favorably to systems with high or upper memory enabled, etc.

Of course since it is primarily for use with the DOS FORMAT command, the non-standard parameters do not get passed through to 800, even though the ability to do so is present.

There exists a package available from the (ex-)Soviet Union as shareware, that can format and exchange files between MS-DOS and ODS-1 RSX PRO/-11 RX50 diskettes which is ideal for PRO's. This package runs under MS-DOS or DR-DOS, and requires 800, etc.

--Charles Lasner

I have down-loaded Sydex's teledisk, and have found it to exceed my expectations in some useful ways.

For starters, all of my attentions are based on the problems of distributing RX50 diskettes not necessarily in stock format, and not yet having any satisfactory way of creating the necessary disks.

Background:

There are several desirable variant formats for RX50 that have been discussed elsewhere. The only known program to create them is FDFORMAT for PC's. While this freeware program is generally quite good, it has a few crucial bugs that make it unsuitable for RX50 usage. It is conceivable that this will be solved by using some additional/non-standard parameters to FDFORMAT to create usable disks, but in any case, the use of all obvious parameters yields disks that are flakey on some RX50's, and downright unreadable on others. In addition, these disks are so messed up that a DECmate can't even WRITE on the disks and read back what it just wrote reliably! Yet, this isn't a media problem because it can be demonstrated that the problem disappears by low-level format of the same diskette with either Sydex's RAINDOS or 22DISK packages. (Note that *some* RX50 systems using some newer-designed controllers and/or higher revision drives and/or RX50-compatibility modes on different drives have little or no problems with these FDFORMATted diskettes; indeed the diskettes are fine on a PC; there's some low-level detail that's incorrect about FDFORMATted diskettes. Some parameter is being set to a PC-acceptable value that doesn't center on RX50's requirements. Perhaps this will be uncovered at a later time obviating this entire discussion. Until such a time, FDFORMAT cannot be used to create RX50 diskettes that are readable on *all* RX50 systems. FDFORMAT also has a few other operational bugs, such as incorrect recognition of certain I/O errors, etc., but these are exception cases, and for all other PC purposes, it serves quite admirably.)

The reason why FDFORMAT is desirable is that it is the only known program capable of creating the variant RX50 formats where the format must be done with interleave and stagger factors, especially if the disk must have "zones" where the format changes. For example, to create a disk best suited for DECmate OS/278 usage, the following *TWO* commands should be given:

FDFORMAT A: /T:80 /N:10 /1 /Y:2 /I:2
FDFORMAT A: /T:78 /N:10 /1 /Y:2

The first command creates a disk with an interleave of 2:1 and a stagger of 2 throughout. The second command changes tracks 0-77 to have 1:1 interleave and a stagger of 2 throughout.

When OS/278 is copied onto such a diskette, the "slushware" tracks are read in much faster than on standard RX50 diskettes, and all access to the rest of the diskette is speeded somewhat because of the stagger factor which overcomes the software's lack of stagger mapping. But since the software does map the sector order into a 2:1 interleave, the hardware order must stay in 1:1 interleave sequence.

This would be a nice disk to use for the intended purpose, but many DECmates will be unable to read this diskette. Literally, it will get a CRC error on *every* sector! Furthermore, if you attempt to write an image of the software onto this diskette, it will get a CRC error on *every* sector even though it just wrote the disk out!

Enter Teledisk to the rescue!

When I read Teledisk's documentation, I had doubts that it could solve this problem, because I noticed it could be quite "smart", perhaps *too* smart! It claims that it can get around certain copy-protection methods by virtue of how it operates, so I figured that it would likely copy the problems of FDFORMAT as well :-(. Or, alternatively, it might guess that the diskette was an RX50 and proceed to format it in a stock manner, thus destroying the optimization applied by using the two FDFORMAT commands instead of just using RAINDOS or 22DISK to create stock low-level RX50 diskettes.

Well, I was wrong on both counts!

Teledisk understands how to maintain sector order, and pointed out the change of interleave from 1:1 to 2:1 at track 78, so that problem is hurdled.

Teledisk understands that these sectors should be formatted with apparently the same parameters as the formatting routines in 22DISK and RAINDOS, so the resultant disk *is* readable on DECmates! Of course, this is *not* an "exact" copy, but rather it is a "better" copy. Apparently Teledisk only writes sectors in a "sane" format, and the copy-protection they refer to is the class of "funny" sector ordering, size, or count, not any lower-level details. Apparently the Sydex code at work in RAINDOS and 22DISK is also within Teledisk, thus since Teledisk recognizes the disk as a 10-sector/track 512 bytes/sector disk, it writes it as would RAINDOS, etc., except Teledisk is sensitive to sector ordering unlike the other Sydex programs, etc.

Thus, the descendent disk is actually *better* than the original. I can now therefore distribute diskettes in the intended format for working-copy usage of the best effort of each diskette :-).

Additionally, if I modify distribution diskettes to be in their intended format instead of their original stock format (virtually all diskettes that need to be distributed are in stock RX50 format, because the need to create optimal diskette layout is generally newer than the software; indeed, this entire effort is to distribute software that performs *better* than the original!), then the master disks should be copied with Teledisk to create perfect copies in one step.

There are additional advantages:

Teledisk can also create an MS-DOS file that is the image of the diskette in either a rudimentary-compressed or advanced-compressed form. These files can be transmitted down the net and then reconstructed on PC-AT's for use on RX50 targets. Since they are compressed, this minimizes the overhead as well, etc.

So, Teledisk has made my day :-).

However, all clouds have dark sides as well :-( :

Teledisk has some problems, some of which are "political" in nature. There is a known limitation of TELEDISK in that when you invoke the built-in compression feature, which is apparently "liberally borrowed" from the PD LHARC program, it runs quite slow, but admittedly creates smaller MS-DOS files for the effort. However, if the extra compression is disabled, the MS-DOS file is only subject to run-length compression of zero bytes, and the resultant file can then be compressed by better means, such as PKZIP which is often faster in the compression and decompression, which means that uncompressed files can be used to speed up TELEDISK's operations, and occasionally the PKZIP archive file is somewhat smaller (or somewhat larger, it varies!) than the LHARC-type file format used by TELEDISK when compression is enabled.

Although I would therefore recommend disabling the compression, the program tends to promote the use of the compression, etc.

There is a known bug in the compression routine that will occasionally show up as an incorrect file that is worthless! So far, only 1.44 MByte 3.5" HD diskette image files have been found to show this problem, and only occasionally. As distributed as shareware (last shareware version I believe is 2.12) the only way to confirm this is to attempt to make a descendent floppy, and notice that it craps out in the middle.

The author has acknowledged this weakness as of this 2.12 version, and apparently at least an additional newer version that he won't make available as shareware, even though this version, and perhaps some even newer versions only add on attempts at bug fixes. (Clearly there is at least one newer non-shareware version superseded by at least yet another non-shareware version, and the former's only purpose is to defectively attempt to overcome the problem in the shareware version, and the latter is a fix to that fix, etc. Relative to this problem, there are no other features to the newer versions, and perhaps there are no other features at all!)

Apparently the author is having some business problems with some unscrupulous commercial BBS operators who have apparently violated the shareware license by having a blatant amount of downloadable files in TELEDISK format, yet haven't paid for a shareware license, etc. The author contends that the only way these operators can have so many TELEDISK files is that they are violating the terms of the shareware, etc.

While all of this may even be true, Internet users who have no commercial interest in Teledisk are now being "punished" along with the "guilty" since the shareware author has decided to no longer support newer versions on Teledisk as shareware! Instead, all users are required to purchase a "site license" regardless of status, etc. Thus, it is necessary to pay a high (compared to shareware rates) price for the next version, even though it is of dubious worth over the last shareware version, at least in regard to RX50-related matters specifically. It is conceivable that someone able to justify the site license could report to us whether the problems we must concern ourselves with have been remedied in a newer version, etc.

Additionally, as of Version 2.13, an additional utility has appeared called TDCHECK. The TDCHECK program can check the viability of a Teledisk file to determine if the file isn't corrupted (whether caused by Teledisk itself or not!) and is faster than using Teledisk to create a target disk which then has to be verified as a copy of the original, etc. Of course, you need to purchase a site license to obtain this utility as it's a portion of the first "commercial" release, etc.

On the brighter side, the shareware author may have relented somewhat, because I have found a copy of the TDCHECK program on many of the common Internet resource sites (SIMTEL20, etc.) seemingly unbundled from any Teledisk release of Version 2.13 or higher, etc.

This TDCHECK program doesn't solve the problem of corrupted operation, it merely confirms that the problem has/has not occurred allowing you an easier work-around, i.e., definitely to not enable the compression.

Since the recommendation is to disable the compression and use an external utility for that purpose, this really shouldn't pose any actual problems, and I again want to emphasize that no RX50 images have ever been discovered to be self-corrupted by Teledisk V 2.12, just 3.5" HD diskettes.

However, there is yet another problem with Teledisk, at least as of V 2.12:

Teledisk attempts to read a diskette which might be highly non-standard, and it reports all points of change in the format of a disk as they occur, such as when the interleave changes, etc.

As a consequence of this, it "tolerates" a lot of format variations and will recreate them in the descendent disk (and in the case of FDFORMAT-created RX50 images, actually better than the original!)

However, if the disk is being read marginally, as RX50 diskettes sometimes do, it assumes that the variation is normal, i.e., there will be a report on the screen during the disk reading, copying to an MS-DOS file, of an unwarranted format change from the constant 10 sectors/track RX50 format with some stated interleave, etc. It appears that Teledisk inadequately retries reading a diskette to confirm the difference between a desirable format change or anomaly, and merely an I/O error that would clear up merely by re-reading the track a few times.

To get around this, the following recommendation is made:

First format a diskette on the PC using the desired interleave and stagger or slide parameters. Take this diskette to the DEC RX50 system and make an image copy of the desired diskette onto this diskette that was formatted on the PC just prior to being written on at the DEC system. Then take the copied diskette back to the PC where it was formatted, and read it into Teledisk. The resulting MS-DOS file will report no format changes during the diskette reading as would the original DEC diskette. This procedure can eliminate about 98% of the problem. If the format change is reported during the diskette read, the diskette is definitely useless, and there is no fix possible. If no format change is reported, the disk is likely trustworthy.

Of course the descendent disk can be brought back to the DEC system and compared to the DEC original, as a further "belts and suspenders" approach which should be done on important disks, etc.

An additional problem of Teledisk as of at least V 2.12 is that there is an option to make a direct copy from one drive to another without making the intermediate MS-DOS file. This option often doesn't work at all. Avoid the problem by creating the MS-DOS intermediate file, and using Teledisk a second time to create a descendent, etc. (You can always output to a RAM disk and/or delete the file afterwards if desired, etc.)

Not related to RX50 per se, but there is another notable Teledisk problem: When 1.72 Mbyte disks are created using FDFORMAT as described above, Teledisk cannot copy them at all! The symptom is that a descendent disk is created and is correctly formatted, but the contents of some portion of the disk (approximately 2/3 of the way into the disk) are a repeat of the contents of lower-numbered tracks. Often the file is self-corrupted as is occasionally the downfall of using Teledisk with 3.5" HD diskettes, but in this particular case, the file is not noted as corrupted with TDCHECK, but rather has plausible contents, just repeating some of the former track data instead of the desired data, but the Teledisk file is in the proper format per se, and the resultant disk's format is correct also. Note that it could be necessary to disable to compression to avoid self-corruption, but the data is still wrong even if the format is correct in that case.

In spite of all of these problems, Teledisk does generally work, and works rather well. Hopefully, the shareware author will change his policy regarding the usage by those more suited to being treated as shareware users, not commercial operators, and at that point, the shareware author can enjoy the benefits of having good feedback from his audience! This policy can give the greatest advantage to the author and users alike!

Besides Teledisk there is another option. You can retrieve rt11.zip by via anonymous ftp from newton.canterbury.ac.nz 132.181.40.1, in the pub/local directory.

It produces what appears to be a nice RT-11-like environment on a PC for file transfers, etc., but is inferior to Teledisk for the purpose of making a compacted image of an entire disk as a DOS file. Since this is a frill, it can be completely overlooked :-).

And yes, it does Format DD-type media to stock RX50 as advertised.

This program is written in Turbo Pascal. It would seem that someone who can understand enough TP and the quirky code to call BIOS routines should incorporate some of RT11.PAS into FDFORMAT (also a TP-based item) since the format routine works fine while FDFORMAT does not for RX50 as discussed elsewhere.

Overall a nice program.

--Charles Lasner

Just a word about using HD media:

You can't reliably use HD media on an actual RX50, because the coercivity is too far off in HD media. It was designed for the higher-frequency recording of the "real" 1.2 Meg format (500 KHz) and not the 250 KHz recording rate of the RX50, which is actually the same as good 'ol DS/DD media (360K kind of media). Some revisions of RX50 drives in combination with certain RX controllers in some DEC machines fare better than others, but it can be demonstrated that a lot of combinations don't particularly "like" HD media.

The designated media for RX50 is Maxell MD1DD-RX50 or equivalent, which is what used to be called "quad" media. This is well-honed low-density media, so it is rated for use on 96 TPI (80 track) drives, not just 48 TPI (40 track) drives as is usual. Note that MD2D is not MD2DD. (The 2 just means two-sided which for all intents and purposes today can be ignored; virtually *all* media is actually made double-sided :-).) The DD means 80-track support, but since most media are made well-honed, most cheap disks can support 80 tracks anyway. These disks will *not* cause I/O errors on any RX50! However, long-term usage requires the hub rings be removed completely (use alcohol to get the sticky stuff off, or ask your supplier for no-hub disks!). Failing to remove hub rings means eventually the disks will get unreliable sooner than they ought to due to registration problems. All 96 TPI disks have this problem. Note that MD2HD and MD1DD don't have hub rings! It is rumored that there is a "premium" line of diskettes from Fuji apart from their standard line of inexpensive diskettes that has a specially reinforced hub area, that isn't a hub ring per se. If the same mechanism is used in both HD and DD media, then the DD type would be the best thing today to use with impunity for RX50. Clearly the MD1DD or MD2DD or MD1DD or the 3M equivalents are too expensive, considering that what we want are the cheapest types of diskettes with the hub rings never added. (We don't want to pay more for less!)

An issue over hub rings:

While it is desirable to find media without hub rings, and yet be DD media, it is usually the case that DD and hub rings go together, i.e., if there are no hub rings, the media is likely to be HD. To confirm that the media is indeed DD, the following test will generally work:

Attempt to format a suspect disk as a normal 1.2 Meg HD diskette. If there are hundreds of kilobytes in bad sectors, then it's likely a DD-type diskette unsuitable for HD usage and therefore suitable for DD usage. If the diskette gets either no errors or few errors (under 200K in bad sectors) then it's some form of HD diskette and shouldn't be attempted for RX50 usage. It may appear OK on the PC, but it won't work reliably on (most) real RX50 systems!

--Charles Lasner

The PRO's hard disk controller supported only a few kinds of disks. Early versions of the controller supported only 5 or 10 MB drives. The last set of ROMs they issued for the hard disk controller supported a 67-MB RD53 disk. Without the more recent firmware, the controller doesn't recognize the higher-capacity disks.

 The official DEC drives supported were:
   RD50     5 MB
   RD51    10 MB
   RD52    33 MB
   RD53    67 MB
   RD31    20 MB
   RD32    40 MB

Various 3rd-party disks with similar operating specs to these drives would also work. The information I have on equivalent drives says the following drives would work as replacements for the official DEC hardware:

 RD52:  Quantum Q540

 RD53:  Micropolis Micro1325
        ATASI A3085
        Computer Memories CM7085
        Maxtor XT1085
        Miniscribe M6085
        Newbury Data NDR1085

 RD31:  Seagate ST225 or ST4026
        Computer Memories CM3426 or CM6426
        Lapine Titan20
        Miniscribe M3425 or M8425
        Syquest SQ325AF
        Tandon T262, T362, or T702AT

 RD32:  Seagate ST251-0, ST251-1 or ST277
        Miniscribe 3650J

...hope this helps...

--Kurt Wampler

The first difference is that the microPDP's use the Q-bus, which is well supported both by DEC and many 3rd parties, while the Pro3xx used the CT- bus, which was never used for anything else or supported by anybody. rather limits the expandability of the Pro3xx...

->My first guess would be that the microPDP-11 has none of the limitations
->of the Pro. But then I've heard that the limitations put into the pro
->were to prevent the Pro from taking away from the PDP-11 market. 

True to a degree. The Pro was intended as a personal engineering workstation, while the microPDP-11's were aimed largely at embedded, controller-like applications, and the 'real' PDP-11's for serious expansion and multi-user environments. Or so I understood it...;{) One irony of all this is that the only place I know of anybody using Pro380's in new installations is as graphics front-ends to microPDP-11's being used as controllers.

--Steve Mitchell

Needs ms-dos like a battleship needs a popgun! However, there are third party companies (or were) if memory serves who made 8088 boards for a Pro so you could run msdos on it as well as P/OS...concurrently, yet!

--Glenn Everhart

There was an add-on board that DEC sold which allowed you to format your hard drive CP/M. I actually had one for a while in the mid-1980s... never used it.

--Chaim Dworkin

The CP/M Option consists of hardware and software: a CTI card (000043) which contains a Z80-A microprocessor, 64Kbytes of RAM, 4Kbytes of ROM and CP/M-80 which runs on top of P/OS. P/OS can continue to multitask in the background while CP/M is running. CP/M-format diskettes (96 tpi) can be read or written in the RX50 drive, 48tpi diskette can be read only, and up to four virtual diskettes can be accessed on the hard disk. A CP/M application can also read P/OS sequential files allowing data exchange between the two. CP/M does not have access to the Pro's hardware registers, so applications (such as graphics) that have been written for specific I/O devices will not work. Applications that use CP/M services for I/O will run without modification. The DEC order code is PC3XS-AA

There are three diskettes:

BL-V447B-BH    Pro CP/M-80 APP DSKT V1.1 (1983)

BL-AH67A-BH    PRO-CP/M-80 APPLICATION (1983)
               DISKETTE SYSTEM V1.1

BL-V448B-BH    PRO-CP/M-80 APPLICATION (1983)
               DISKETTE HARD DISK SYSTEM V1.1

Teledisk images of these diskettes are available at:

http://starfish.rcsri.org/rcs/pdp-11/Professional/Pro-CPM/

--mikeu

We have two versions of UNIX running on PDP 11/73's in my lab.

The first is UNIX 2.10BSD, which is real BSD UNIX, basically the same as 4.3BSD. It is available from USENIX in Berkeley, (415) 528-8649. It only cost us $200 for the media, a TS-11 tape, but we had to prove that we already had a site license with ATT for UNIX. It only comes with installation instructions. You have to purchase the 4.3BSD documentation seperately if you want it. It seems to run fairly well except the network stuff seems a little slow. I don't really use the network stuff.

The second is VENIX (Release D I think), which is a clone. It is available from VenturCom in Cambridge, MA, (617) 661-1230. I am pretty sure they don't support it anymore but they still may sell it. We have been using it for quite a while (> 7 years) and it seems to work pretty well. It doesn't include any network stuff, but does support standard peripherals. We have done alot of patching to the kernal over the years, so if you get it and need some help drop me a note.

By the way, UNIX 2.10BSD comes with the complete source code for UNIX, which I have found great to have access to although it is 70 Mb worth of stuff.

--Mark S. Spector From: sms (Steven M. Schultz)

     Second Distribution of Berkeley PDP-11 Software for UNIX
                            Release 2.11
                      (Revised February 1992)

The USENIX Association is pleased to announce the distribution of a new release of the "Second Berkeley Software Distribution" (2.11BSD).

This release will be handled by USENIX, and is available to all V7, System III, System V, and 2.9BSD licensees. The Association will continue to maintain the non-profit price of $200. The release will consist of two 2400 ft. 1600 bpi tapes or one TK50 tape cartridge (approximately 80M) and approximately 100 pages of documentation.

If you have questions about the distribution of the release, or require 800 bpi tapes, please contact USENIX. At present a split I/D machine is required, thus 2.11BSD will not run on 23 or 23+ based systems. The USENIX address and phone number are as follows:

    2.11BSD
    USENIX Association
    2560 Ninth St. Suite 215
    Berkeley, CA  94710
    +1-510-528-8649

USENIX may also be contacted by electronic mail at:

    {ucbvax,decvax}!usenix!office
    officeusenix.org

If you have technical questions about the release, please contact Steven M. Schultz at:

    wlbr!wlv!sms
    sms
    (yes, a bit of a misnomer, will be changing it one of these days)

The root password is 'gnomes', and the games password is 'dale'. I think 'dale' is also the password to one other account. The password to the uucp account is probably 'uucp'. Anyway, you can change them once you get in as root.

To login via the COM port, edit /etc/ttys and change the 01com1 to 11com1 for 9600 baud null modem. (Other speeds require other codes in the second byte.) The first byte turns on the getty listener on that port. Then do: kill -2 1 to get the init to reread the /etc/ttys (or just reboot). You will then be able to login via the com port via a null modem at 9600 baud.

Venix does an fsck upon boot. This may be why your HD head is seeking?

Enjoy!

--Barry Kort

USERNAME: SYSTEM
PASSWORD: SYSTEM

--Tom Karlsson

I have a Pro running a form of unix and I no longer need or want it. I guess I'll just throw it out. I have an old copy of xxx unix for the Pro in a closet somewhere and I'm going to clean out the closet and discard all the old Pro stuff.

DON'T DISCARD A UNIX PACKAGE FOR THE PRO! Please post a note in comp.sys.dec.micro and offer it to someone. On the whole very few copies of unix were sold for the Pro computers making it a somewhat difficult OS to get a copy of. In the past 4 years or so whenever I've mentioned unix to anyone who owned a Pro they've always responded that they were "dying to get a copy".

P/OS says I have lots of space on my disk yet whenever I try to copy a file I get a message saying out of disk space, please delete some files and try again. Why?

Most OSs put pieces of a new file in chunks of empty disk space, P/OS and RSX-11M-PLUS can do this for data files but they require a single contiguous space for each task file or for other files which are designated "Contiguous". This means that if you delete many small files you create "holes" or empty spaces on your disk. When you copy new files that must be contiguous to your disk, P/OS will copy those files after the last file on your disk until your disk is full. Then if it cannot find a single contiguous space to fit the new file it will tell you your disk is full even though you may have previously deleted enough files to create space for the new file. I do not know if it is possible to "pack" a disk to make a single large contiguous space out of many small holes. Can someone answer this?

--Chaim Dworkin --Robert "Bob" Gezelter

Sometimes, as when you abort a compile or link, temporary files that were created will not be erased. These temporary files do not have a directory entry - and hence, they will not appear in a directory listing. The process that created this type of file did so by manipulating the master index file directly.

Ordinarily, you will not be able to tell that these invisible files exist. There is one Toolkit utility, however, that makes these files visible: VFY (file structure verification utility).

You may use the following VFY procedure on any PRO hard disk or diskette. VFY will search the volume and place any invisible file entries into the [1,3] directory. Hence, you should create a directory [1,3] first or VFY (while showing you what invisible files it found) will leave the files invisible.

Once the files are placed into [1,3], you may delete them to recover volume space. These files are typically scratch files and deleting them will cause no problems.

Enter the following to initiate the search for invisible ("lost") files:

            $ RUN $VFY
              VFY>/LO
         

VFY will then look for the lost files. If any are found, VFY will list them on the screen. When VFY is done, it will return the VFY> prompt. To quit from VFY, do a CTRL-Z:

              VFY>^Z
              $ +
         

The found files, as placed into [1,3], may have strange names and any block size (even zero).

--sjs

              $ SET TERM TT2: /SPEED:(nnnn,nnnn)

Where nnnn,nnnn represents transmit and receive baud rates.

To determine the current baud rate, do:

              $ SHOW SPEED/TT2:

--sjs

Use a hyphen (-) before the line's carriage return. In DCL, the command is not executed until a line ending in <CR> not preceeded by a hyphen is encountered. No DCL line can be more than 250 characters.

--sjs

              $ SET PROT <filespec> [/qualifier(s)] <code>
         
         /Qualifiers:
         
              /DATE=dd-mmm-yy
              /SINCE=dd-mmm-yy
              /THROUGH=dd-mmm-yy
              /TODAY
              /EXCLUDE=filespec  (don't forget a version specification)
         
         Code is in the following format:
         
              (SYSTEM:RWED,OWNER:RWED,GROUP:RWED,WORLD:RWED)
         
         where SYSTEM, OWNER, GROUP and WORLD are user types (since the
         PRO is  usually used  as a  single-user system  the GROUP  and
         WORLD types are seldom relevant) and RWED represent four kinds
         of access to files:
         
              R    file can be read/run, copied, printed
              W    file can be written to
              E    user can change amount of disk space alloted to file
              D    file can be deleted
         
         Example:
         
         $ SET PROT TEST.*;*/SINCE=01-JAN-88/EXCL=*.OBJ;* (S:RWE,O:WRE)

--sjs

              o    Install the task:   $ INSTALL <task>
         
              o    Assign the new LUN to the task:
                   $ ASSIGN/TASK=<install_name> <device:> LUN
         
              o    Run the task:  $ RUN <install_name>
         
         Example:   If  you  want  your  task  DATABASE  (install  name
         DATABA), which  currently uses  LUN 3  to write  to a file, to
         write the data to the printer, you would perform the following
         steps -
         
              $ INSTALL DATABASE
              $ ASSIGN/TASK=DATABA TT2: 3
              $ RUN DATABA
         
         TT2: is the device name for the printer.

--sjs

Note: This requires a BCC08 PR1/CONSOLE cable.

              $ INSTALL/NOREMOVE APPL$DIR:RMD.TSK/TASK=RMDT2
              $ ASSIGN/TASK=RMDT2 TT2: 1
              $ ASSIGN/TASK=RMDT2 TT2: 2
              $ SET TERMINAL:TT2:/VT125
              $ SPAWN RUN RMDT2
              $
         
         The above  reassigns RMD's  LUNs to  point to the TT2: device.
         RMD requires  a VT100-type  terminal setting  to run;  you may
         substitute the  /VT125 qualifier  with  one  that  more  aptly
         describes your terminal.
         
         Note:  You may still use SHOW MEMORY on the main terminal.

--sjs

You must apply a P/OS 2.0 Patch for 20 MEG HD

Perform the following ZAP to alter the POS.SYS file on the PROSYSTEMS2 volume diskette. This ZAP works for version 2.0 (not 2.0A) of P/OS. It causes the system to recognize a 20 meg hard disk (the Seagate ST225 is the one you want).

Remove any write-protect tab from the PROSYSTEMS2 diskette and place it in drive 1. You should copy the file named below to another diskette in case you make a mistake and want to try again. (A separate copy is suggested because ZAP alters the file directly - it does not create a new version).

Type the following in the Toolkit (user entries are in bold). The ^Z is a control-Z.

              $ SET DEF DZ1:[ZZSYS]
              $ RUN $ZAP
              ZAP> POS.SYS/AB
              _162:770/
              _000004
              _162:776/
              _001146
              _163:004/
              _114577
              _162:756/
              _000240
              _^Z
         
              $ +

The diskette is now ready to be used. Place the 20-meg disk into the PRO and format/load P/OS using the altered diskette.

Note: P/OS may give a complaint regarding the hard disk when you boot up to format the hard disk, but it should say it will try to rectify the problem and continue. After the system continues, you should not see any error messages again.

--sjs

I was given a Pro-350 by an office that was junking it and when I booted it up it asked for a password. I don't know any passwords. How can I break past that and delete the password file?

Well, I've never really dealt with P/OS, but a long, long time ago I was involved with a group that had a similar problem with a PDP-11/60 that we bought from another group at the site. It ran RSX-11M, but we didn't get any passwords from the group from which we bought the machine. After a lot of poking about in manuals, I found a way to get to the password file, which in that version of RSX-11M was not encrypted.

While the machine was booting, executing the startup command file, I pressed ^C. That gave me an MCR prompt at which I could type a command. Since the machine was executing the startup command file, the MCR prompt was attached to the system account. In an obscure manual that I no longer have and don't remember very well, I found the name of the password file. The MCR command that I issued, then, typed the password file on the console.

Since P/OS is related to RSX-11M, it might work. Wish I could remember the name of the account file, though...

--Roger Ivie

>From: kalisiak (christophe m kalisiak)
In article <1991Apr16.134937.47433 @ cc . usu . edu> slsw2 writes:
>While the machine was booting, executing the startup command file, I pressed
>^C. That gave me an MCR prompt at which I could type a command. Since the
>machine was executing the startup command file, the MCR prompt was attached 
>to the system account. In an obscure manual that I no longer have and don't
>remember very well, I found the name of the password file. The MCR command
>that I issued, then, typed the password file on the console.

What was the command? I would say that if one were to delete the password file, then you could probably start from scratch... Don't quote me on it.

>Since P/OS is related to RSX-11M, it might work. Wish I could remember the
>name of the account file, though...

[0,0]RSX11.SYS

--Chris Kalisiak

To break into P/OS, if you can get to a Pro (runnin g p/os 2.0 or later at least) that you can use, there is in the menu system a facility for writing a "password floppy". If you boot the Pro and have that floppy loaded, its' password will override the one on the hard disk. I used this technique once, but it's been long enough ago I don't recall more detail. I believe that some help exists on the system, though, as I had no manuals to infer this from at the time. (Someone had left the company and his pro was unusable till I freed it.) Doing this will also set a password on the pro you make the floppy on, but you can reset that after the floppy is safely written.

I don't particularly recommend passwords on personal Pros due to the extreme inconvenience they cause.

--Glenn Everhart

From "The Professional 300 Series Technical Manual", I have (p. 8-5):

J1 Pin-outs for the monochrome monitor:

1-3  not used
4    Ground ( video signal ground potential )
5,6  Ground ( operational voltage ground potential )
7,8  +12 Vdc ( operational voltage input )
9-11 not used
12   M Video ( composite video )
13   Ground ( tied to 5 and 6 )
14   Data Receive ( serial data line from the keyborad output to the system box, via J3 )
15   Data Send ( serial data line from the system box output to the keyboard, via J3 )

J3 pin-outs, for the keyboard:

1  Data Send ( via J1, pin 15 )  Serial line for output from the system box to the keyboard 
2  +12 Vdc ( output of operational voltage to the keyboard ( from J1, pins 7 and 8 ) 
3  Ground (from J1, pins 5,6,13)  Operational voltage ground.
4  Data Receive (via J1, pin 14)  Serial line for input from the system box.

I could not find equivalent information about a VR241 ( color ) monitor. However, there must be some relation, as the Extended Bitmap Option board can drive either, without hardware changes. You might be able to get more out of the manual if you can obtain one: The ordering or part number is: EK-PC350-TM-001

--John Erbland --Hubert Bartels

Professional 380 video-port pinout:

Pin:                            Description:
1,2,3,4,5,6                     Ground
7,8                             +12 Volts
9                               Blue
10                              Green
11                              Red
12                              Monochrome
13                              Monitor Present (don't know what it's for, or where it has to be connected to.)
14                              Keyboard transmit
15                              Keyboard receive

I got this info from our local DEC branch. I had to build my own cable and it works fine.

--Arno Griffioen

1,3,etc GND             Ground
 2      TG43            Track greater than 43
 4      N/U             Not used
 6      SEL3 L          Select for drive 3 (not used, near as I can tell)
 8      INDEX L         Index
10      SEL0 L          Select 0
12      SEL1 L          Select 1
14      SEL2 L          Select 2 (N/U)
16      MOTOR ON L      Motor on
18      DIR L           Direction
20      STEP L          Step
22      WRT DATA L      Write data
24      WG L            Write gate
26      TK00 L          Track 00
28      WRT PRT L       Write protect
30      RD DATA L       Read Data
32      SIDE 0 H        Side select     (Note: H vs L, so a transitor needed)
34      READY L         Drive Ready

--Warner Losh

New Pro 350 owners are so worried about the error codes I have reproduced the most common ones here. These are taken from the P/OS handbook. Note that unless you want to buy new components all you can do is reseat connections!

Code   Problem area             Corrective Action

000100  P/OS keyboard handler
      1: Check cables and connections
      2: Reseat option modules in card cage.
      3: Reset all IC's in sockets on system module.
      5: Replace system module
      6: Reload Operating system.

000200  Terminal driver         [deleted]

000300  Executive/general       If error occured on first access of RX or RD 
subsystem, check that subsystem is in order: 

     1: Check cables and reseat controller in card cage
     2: Replace Drive
     3: Replace RX or RD subsystem controller

If error not found on first access of mass storage, goto 000200 corrective action. 

000400 System startup processing

000500 Terminal driver
  (video and printer port)

Second line Error Codes

000000  IOT in system state
000001  Stack overflow or cannot install task CBOOT
000002  Trace Trap or breakpoint or cannot spawn task CBOOT
000003  Illegal instruction trap or cannot spawn task CBOOT
000004  Odd address or other trap to 4
000005  Segment fault
000006  A task on P/OS without a parent aborted
000007  EMT trap or required file not found
000010  TRAP trap

--Todd Miller

In a recent message someone reported getting the following error codes: >010013 >000401

The interpretation is:

  000401 = hard disk subsystem
  01     = card slot 1
  0013   = RD hard disk drive format failure

--Kurt Wampler

Billys Place (213)837-0892 Login ID is 1000 and password is 'moving target', from there youll recive a personal ID. Supports the RT-11 SIG, and has the RT-11 SIG library online for downloading (youll probably need the DECUS catalogue to help you). VTCOM/TRANSF, XMODEM, and Kermit seem to be supported, Ive successfully connected at 2400 (which is the highest-lowest, I dunno:-)

RSX BBS (612)777-7664 Supports RSX on the PDP-11 but since the Pro also runs RSX there is a Pro file area and discussion area. sysop is Bruce Mitchell.

Intellicon Data Systems (401) 884-9002 Contact sysadmin @ nospam.idsvax.ids.com or ...!uunet!rayssd!idsvax!sysadmin for information on their system.

--Chaim Dworkin --Michael P. Deignan --Billy D'Augustine

2.11BSD comes with SL/IP so a serial network connection is possible. Slow, but better than nothing.

--Steve Mitchell

DECnet for P/OS supports serial lines. These connections are quite usable, provided the parameters are set correctly on the VAX that you are connecting to.

--Robert "Bob" Gezelter

Pro KERMIT is actually RSX Kermit; there are conditionals in the code which make it recognize that it is running on a Professional rather than a PDP-11. The current version is T3.60 (with long packet support) which is available free from the RSX bulletin board system at (612) 777-7664. T3.60 works correctly on a Pro380 under P/OS 3.2 and under RSX-11M-Plus V4 and higher - I'm using it now in terminal emulation as a matter of fact. There are no problems with moving files from VMS to RSX using this version.

If you have T3.60, and still encounter problems, try SET ATTRIBUTE OFF before transferring. Many VMS Kermits do not recognize attribute packets.

--Steve Mitchell

You can also run Kermit-12 on the PRO. All Kermit-12 files are available at watsun.cc.columbia.edu in the /kermit/d/k12*.* area via anonymous FTP. PDP-8/DECmate assembler versions of the ENCODE and DECODE programs are there as k12enc.pal and k12dec.pal respectively.

--Charles Lasner (author of Kermit-12) watsun.cc.columbia.edu home of Kermit-12 and other fine Kermits.

The Pro-350 comes with one serial port standard. Does anyone know if it's possible to add a second serial port or additional ports?

Actually the Pro 350 and the Rainbow have two serial ports as the printer port is a serial port also. The hardware is bi-directional, the support may be lacking in the drivers. I don't believe the printer port had full modem control on it ( I think it had DSR/DTR ).

Near the end of the Pro 350's lifetime there was a 4 (?) port serial unit released for it. I doubt many would have been sold. Sorry, I don't recall the part number.

--Malcolm Dunnett

That 4 port unit was the Real Time Interface with 2 serial, 1 parallel, and an IEEE 488 bus (Pc3xx-aa). Dec was selling them through Dec Direct at fall special for $100 each last year.

Or it could be the PC3XC-BA Quad Serial Line unit described in the guide to writing P/OS device drivers. 4 ports to 38.4Kbaud, two with modem control attached to a flat ribbon cable that snaked out from inside the unit.

--Todd M. Miller --Paul S. Kleppner

Digital Data Communications Message Protocol(DDCMP) is the network protocol covering Rainbows, PRO's, Microvaxes, and VAXes that brings network access (and multiple sessions) over a cable or modem.

For those interested, I present here an abridged version of "Technical Aspects of Data Communication" chapter 18 "DDCMP" by John E. McNamara, 1977. Although I have not tried, it seems to be everything you need to program a DDCMP

DDCMP Message Queuing System:

"In the DDCMP protocol, any pair of stations that exchange messages with each other number those messages sequentially starting with message number 1. Each successive data message is numbered using the next number sequence, modulo 256. Thus a long sequence of messages would be numbered 1,2,3,... 254,255,0,1,... The numbering applies to each direction separately. For example, station A might be sending its messages 6,7,8 to station B while station B is sending its messages 5,6,7 to station A. Thus, in a multipoint configuration where a control station is engaged in two-way communication with 10 tributary stations, there are 20 different message number sequences involved - one for messages from each of the 10 tributaries to the control station and one for messages from the control station to each of the 10 tributaries.

Whenever a station transmits a message to another station, it assigns its next sequential message number to that message and places that number in the "Sequence" field of that message header. In addition to maintaining a counter for sequentially numbering the messages which it sends, the station also maintains a counter of the message numbers received from the other station. It updates that counter whenever a message is received with a message number exactly one higher than the previously received message number. The contents of the received message counter are inclueded in the "Response" field of the message being sent, to indicate to the other station the highest sequenced message that has been received.

When a station receives a message containing an error, that station sends a negative acknowledge (NAK) message back to the transmitting station. DDCMP does not require an acknowledgement for each message, as the number in the response field of a normal header, or in either the special NAK or positive acknowledgement (ACK) message, specifies the sequence number of the last good message received. For example, if messages 4,5, and 6 have been received since the last time an acknowledgement was sent, and message 6 is bad, the NAK message specifies the number 5 which says "messages 4 & 5 are good and 6 is bad." When DDCMP operates in full-duplex mode, the line does not have to be turned around; the NAK is simply added to the messages for the transmitter.

When a station receives a message that is out of sequence, it does not respond to that message. The transmitting station will detect this from the response field of the messages which it receives, and if the "reply wait" timer expires before the transmitting station receives an acknowledgement, the transmitting station will send a "REP" message. The REP message contains the sequence number of the most recent unacknowledged message sent to the distant station. If the receiving station has correctly received the message referred to in the REP message (as well as the messages proceding it), it replies to the REP by sending a positive acknowledgement (ACK). If it has not received the message referred to in sequence, it sends a NAK containing the number of the last message that it did receive correctly. The transmitting station will then retransmit all data messages after the message specified in the NAK.

The numbering system for DDCMP messages permits there to be up to 255 unacknowledged messages outstanding, a useful feature when working on high delay circuits such as those using satellites.

DDCMP Message Format:

 -  -  -  -----  ----  --------  --------  -------  -----  -----------  -----
|S||S||C||Count||Flag||Repsonse||Sequence||Address||CRC 1||Information||CRC 2|
|Y||Y||L|| 14  || 2  || 8 bits || 8 bits || 8 bits||  16 ||up to 16363|| 16  |
|N||N||A||bits ||bits| --------  --------  ------- | bits||  8-bit    || bits|
| || ||S| -----  ----                               ----- | characters| -----
| || ||S|                                                  -----------
 -  -  -
                                                  | Only Data & Maintenance
                                                    Message types have info &
                                                    CRC 2 fields |

SYN is a sync character. 
Classes:  10000001 = Data Messages (SOH)
          00000101 = Acknowledgement (ENQ)
          00000101 = Negative Acknowledgement (DLE)
Count: Used for Data and Maintenance messages to indicate the number of characters that will follow the header and form the information part of the message. In control messages, the first 8 bits designate the type of control message and the last 6 0's (except for NAK which uses
the low 6 bits for a reason:
        BCC Header Error    000001
        BCC Data Error      000010
        Rep. Response       000011
        Buffer Unavailable  000100
        Reciever Overrun    000101
        Message too Long    000110
        Header Format Error 000111

Flag:

Contains the quick sync and select flags, bits 0 and 1 respectively: Quick Sync is used to inform the receiving station that the message will be followed by sync characters; the receiver may wish to set its associated synchronous receiver hardware into "sync search" and syncs will be discarded until the first character of the next message arrives. The purpose of this is to permit the receiving station to engage any hardware sync-stripping logic it might have and prevent it from filling its buffers with sync characters.

It also warns the receiver that there may only be a few SYNs and no DEL` (377) Why the DEL`? Because it has only the 'stop' bit set. This helps force the UART to bitsync corectly with the incoming data.

The select flag is used to indicate that this is the last message which the transmitting station is going to transmit and that the addressed station is now permitted to begin transmitting. This flag is useful in half-duplex or multipoint configurations, where transmitters need to get turned on and off.

The Response field: The response field contains the number of the last message correctly received. This field is used in Data Message and in the positive and negative acknowledge types of Control Message. Its function should be evident from the preceding discussion of sequence control.

The Sequence field: The sequence field is used in Data Messages and in the REP type of Control Message. In a Data Message, it contains the sequence number of the message as assigned by the transmitting station. In a REP message, it is used as part of the question: "Have you received all messages up through message number (specify) correctly?".

The Address Field: The address field is used to identify the tributary station in multipoint systems and is used in message both to and from the tributary. In point to point operation, a station sends address "1" but ignores the address field on reception.

In addition to the positive and negative acknowledgement and REP types of Control Message, there are also start and start acknowledge Control Messages. These are used to place the station which receives them in a known state. In particular, they intialize the message counters, timers, and other counters. The start ackknowledge message indicates that this has been accomplished.

Maintenance Messages: These are typically bootstrap messages containing load programs in the information field.

Known Drawbacks: The header is short and higher level operating systems must have a buffer of the appropriate size ready on relatively short notice.

--Todd M. Miller --Paul zrepachol

RQDX1 supports RD51 , RD52 , RX50 .
RQDX2 supports RD51 , RD52 , RD53 , RX50.
RQDX3 supports RD51 , RD52 , RD53 , RD54, RX50, 
               RD31 , RD32 , RD33*,       RX33.

For reference:

RX33 - Teac FD-55GFR
RX50 - DEC built 800KB dual 5.25" floppy
RD31 - Seagate ST225
RD32 - Seagate ST251-1
RD51 - Seagate ST-412 / Tandon TM502
RD52 - Quantum Q540 / Atasi 3046 / [almost] Evotek ET-5540
RD53 - Micropolis 1325 with jumper R7 inserted (1335 also works)
RD54 - Maxtor XT-2190

The Seagate ST506 is an *RD50*, which was never supported on any of the RQDX controllers; its use was primarily on the Rainbow.

--Tim Thompson "Starkle, Starkle little twink" --Mark E. Levy --Bill Pechter

Take out the Mother Board and inspect the area near the Video Connector. Look for a meltdown on one of the leads and bridge it with a dollop of solder or a jumper wire.

To remove the Mother Board, pop the latch at the front of the HD and floppy drives and slide them forward. Uplug the ribbon cables to the card cage, and unscrew the 3 thumbscrews on the front of the card cage. Unplug the power cable and slide the Mother Board out.

The meltdown can occur if you try to connect the Video Connector with the power on. If you misalign the connector, you can short the power lead and meltdown the lead (I think it's Pin 1 or 2) to the keyboard.

--Barry Kort

You can only run v5.0 (or is that 5.1) and above on the Pro. V4.x wont work, due to the video device abortion.

--Billy D'Augustine

Switch settings for the DEC LA50 printer.

Factory settings (USA) 1=Closed and 0=Opened:

        8 7 6 5 4 3 2 1
       -----------------
  SW1  | | | | | | | | |
       |0|0|0|0|0|0|0|0|
       -----------------

        8 7 6 5 4 3 2 1
       -----------------
  SW2  | |1| | | | | | |
       |0| |0|0|0|0|0|0|
       -----------------

Country character set:

                         SW1
       country         4 3 2 1
       -----------------------
       USA             0 0 0 0 (factory)
       England         0 0 0 1
       Finland         0 0 1 0
       France          0 0 1 1
       French Canada   0 1 0 0
       Germany         0 1 0 1
       Italy           0 1 1 0
       Japan           0 1 1 1
       Norway/Denmark  1 0 0 0
       Spain           1 0 0 1 
       Sweden          1 0 1 0

Number of horizontal dots:

                              SW1
       relation b/h  dots/cm   5
       -------------------------
       2 to 1          57      0 (factory)
       2.5 to 1        71      1

Communication protocol:

                      SW1
       Protocol        6
       -----------------
       XON/XOFF        0 (factory)
       Ready/Busy      1

                      SW1
       Signal level    7
       -----------------
       Busy=high       0 (factory)
       Ready=low

       Busy=low        1
       Ready=high

Long rows printout:

                      SW1
       Work mode       8
       -----------------
       Truncate        0 (factory)
       cont.next row   1

Communication speed:

                        SW2
       speed           3 2 1
       ---------------------
       4800 Baud       0 0 0 (factory)
       2400 Baud       0 1 0
       1200 Baud       1 1 0
        600 Baud       0 0 1
        300 Baud       1 0 1
        200 Baud       0 1 1
        110 Baud       1 1 1

Data format:

                                SW2
       data format             6 5 4
       -----------------------------
       7 bit odd parity        1 1 0
       7 bit even parity       1 1 1
       7 bit mark (8=low)      1 0 0
       7 bit space (8=high)    1 0 1
       8 bit odd parity        0 1 0
       8 bit even parity       0 1 1
       8 bit no parity         0 0 0 (factory)

       SW2:  7 and 8 not used.

--Tom F Karlsson

Options inlcude the Telephone Management System, the Interactive Video Information System and the Realtime Interface. For more information, see:

http://starfish.rcsri.org/rcs/pdp-11/Professional/Handbook/

--mikeu

Each Pro has a 47-bit Identification number stored in ROM. This is not the same as the serial number printed on the case label. Some software (for instance VENIX) is keyed to this number. To view the ID use Maintenance Services and choose Configuration Display. The top line shows:

Identification number: ############

--mikeu

The Pro system bus is called the CTI, or Computing Terminals Interconnect bus. It has 22-bit addressing (4Mbytes) and multiplexes addresses and data, combining 16-bit data signals with the 22-bit address signals on 22 signal lines. In most cases, the bus will allow option modules to be placed in any available option slot. Each option module can generate two different hardware interrupt signals. The option modules feature zero-insertion force connectors. When an option is in place, an option-present signal is asserted. Each option contains onboard ROM with identification information.

--mikeu

The VAX Console is a standard Pro with the RTI option, which is used to communicate with a VAX. It runs VAX Console software on top of a modified version of P/OS.

--mikeu

The DEC Professional Series PC-38N was a PRO-380 with a real-time interface (RTI) that was used as the VAX Console for the VAX 8500 and 8550. The RTI has two serial line units: one connects to the VAX environmental monitoring module (EMM) and the other is a spare that could be used for data transfer. The RTI also has a programmable peripheral interface (PPI) consisting of three 8-bit ports for transferring data, address, and control signals between the console and the VAX console interface. It controls the power sequencing, loading of control stores, and general operation of the VAX system.^[1]

--mikeu ^talk 19:26, 21 January 2016 (UTC)

DECUS was originally formed in March 1961 as the Digital Equipment Computer Users Society. It was a non-profit users group supported by DEC (Digital Equipment Corporation.) DECUS maintained a library of user written programs that included software for the DEC Professional 300 series. Pro specific software from DEC, including the P/OS operating system, was donated to DECUS by DEC.

DEC was merged into Compaq in 1998. DECUS then changed name to Encompass. Compaq/DEC then merged with Hewlett Packard in 2002, so Encompass is now an HP user group. The web site is <http://www.encompassus.org/>

The Encompass Software Library at <ftp://ftp.encompassus.org> does not appear to contain any Pro related software.

However, some of the Pro DECUS software can be found at Update. Update is a computer club located at Uppsala University. They maintain a file archive of Pro software at <ftp://ftp.update.uu.se/pub/professional/>

From the README at Update: "This is the directory for DEC Professional 325/350/380 stuff. Most of it is for P/OS 2.0A - 3.2 from DECUS archives."

There is also some software at the Retro-Computing Society archive at: http://starfish.osfn.org/rcs/pdp-11/Professional/

--mikeu

PART NO.	OPTION	DESCRIPTION
DTC11-A		PC300 TELEPHONE MGT SYSTEM
KDJ11-CA		PC380 MOTHER BD,J11 CPU,512KB
KEF11-CA		FLOATING POINT ADAPTER-PC300
MSC11-B		PC300 512KB MEMORY MODULE
MSC11-CK		PC300 256KB MEMORY MODULE
PC325-D		PC325 SYSTEM UNIT
PC325-D2		PC325 SYSTEM UNIT
PC350-D		PC350 SYSTEM UNIT
PC350-D2		PC350 SYSTEM UNIT
PC35C-AA		PC350/5MB/RT-11 CTRYKT/US
PC380-AA		PC380 SYSTEM UNIT, 115V
PC380-AB		PC380 SYSTEM UNIT, 230V
PC38V-AI		IVIS SYS ITALY
PC38V-AE		IVIS SYS UK AND IRELAND
PC3VS-NB		IVIS VIDEO INTERFACE/BACKPACK
PC3XS-AA		CP/M+SOFTCARD FOR PC300
PC3XX-AA		REALTIME INTERFACE-PC300
PCXXF-AA		PC300 FLOOR STAND
RCD50-A		PC350 5MB DISK
RCD50-AA		PC350 5MB DISK+P/OS-USA ONLY
RCD51-A		PC350 10MB DISK USD
VC241-A		EXTEND BIT MAP OPT PC325/350
VC241-B		EXTENDED BIT MAP OPT. PC380
50-15057	002004	RX50 CONTROLLER
50-15100		CT100 SYSTEM MODULE
50-15137	001002	CT100 VIDEO GENERATOR
50-15145	001403	CT100 COLOR BIT MAP
50-15487	000034	PC350 MEMORY
50-15538	000046	(real-time interface)
50-15640	000043	CP/M OPTION
50-15986	000042	DECNA
50-16233		PC300 RAM
50-16236		PC380
50-16238		PC352 EBO
54-15084		(RAM card)
54-15134	000401	(hard disk controller)
54-15138		CT100 VIDEO GENERATOR
54-15146		CT100 COLOR BIT MAP
54-15488-KA		PC300 256KB MEMORY MODULE
54-15991-01		IVIS SYSTEM MODULE
54-15993-01		EXTERNAL IVIS ANALOG
54-15993-02		IVIS ANALOG
54-15995-01		EXTERNAL IVIS LOGIC
54-16006-01		IVIS EBO
54-16008-01		IVIS VIDEO GENERATOR
54-16681-01		IVIS BACKPACK CONNECTOR & MAS
B2-PC325-D2		REFURBISHED B2-PC325-D2
EK-PC300-V2		PROFESSIONAL 300 SERIES VOL 2
EK-PC380-PS		PRO 380 POCKET SERVICE GUIDE

The above table started as the Oct 4, 2002 version of the the file that was at http://starfish.osfn.org/rcs/pdp-11/Professional/part_no.txt --mikeu ^talk 17:59, 19 January 2016 (UTC)

Adapted from the Field Guide to Qbus and Unibus Modules maintained by Megan Gentry. For the full list see: http://world.std.com/~mbg/pdp11-field-guide.txt

MODULE      OPTION     BUS  DESCRIPTION
------      --------   ---  --------------------------------------------------
000034      MCS11-CK   CTI  Bus option RAM (256Kbytes)
000034          PN: 50-15487
000034          Refs: EK-PC100-V1

000041      DTC11-A    CTI  Telephone Management System (TMS)
000041          Refs: EK-PC100-V2, MP-01654, Intel (8031, 8051, 8251A)
000041          Refs: Intel (8255A)

000042      DECNA-K    CTI  Ethernet Controller
000042          PN: 50-15986
000042          Refs: EK-PC100-V2, MP-01895, Intel (82586)

000043      PC3XS-AA   CTI  Z80-A/CPM option
000043          PN: 50-15640
000043          Refs: EK-PC100-V2

000046      PC3XX-AA   CTI  Realtime Interface
000046          PN: 50-15538
000043          Refs: EB-25824-18

000051      DRC11-AA   CTI  Parallel Interface

000052      DLC11-AA   CTI  Serial Interface

000053      ARC11-AA   CTI  Analogue Interface

000064      PC3XC-BA   CTI  Quad serial line option

000401      --------   CTI  5.25" Winchester disk controller
000401          PN: 54-15134
000401          Refs: EK-PC100-V2

001002      --------   CTI  Professional 350 Bus video bit map controller
001002          PN: 50-15137
001002          Refs: EK-PC100-V1

001403      VC241-A    CTI  Professional 350 extended bitmap (color option)
001403          PN: 50-15145
001403          Refs: EK-PC100-V1

002004      --------   CTI  RX50 5.25" floppy diskette controller
002004          PN: 50-15057
002004          Refs: EK-PC100-V2

Refs: EB-25824-18 Professional Handbook, 1984

The info above is from the Mar. 4, 2002 version of http://starfish.osfn.org/rcs/pdp-11/Professional/cti_modules.txt --mikeu ^talk 19:43, 19 January 2016 (UTC)

The PDT11/150 was an earlier attempt from DEC to totally miss the boat on building a personal computer. It had a pdp11/03 CPU on a custom motherboard, typically 64k of memory, serial port, printer port, console port, and oddly enough could also be equipped with 3 more serial ports. There were also two RX01 type single density 8 inch floppy drives on it, and although it could read and write RX01 disks the driver for RT11 was very very odd. So you had to build RT11 and do a special copy/boot on it for that specific device (I forget which one it was, but not DX:). The device was PD.SYS, or PD:

Even more oddly, it could format RX01 floppies, I think it would re-write the format info on every sector write anyway. Really weird controller, very smart and odd.

It typically had the EIS/FIS option chip on it so you could run nice FORTRAN programs with limited floating point support.

Anyway in their usual way DEC sold the PDT11/150 as a terminal multiplexer so you could run 4 terminals down a serial line to a pdp11, and people loaded up RT11 and used it as a great offline computer. I have heard that VisiCalc was ported to it, but DEC didn't want to undercut their mainframe sales.

So same basic story as the Professional, just a few years earlier. I've got one somewhere, just powered up my 380 maybe I'll look around for it.

Chris Zach, 2017.

TMS was one heck of a card. I have one here, I should take a picture of it, it's an analog animal. Basically it was two cards: One went in the chassis, and the other went on the back of the unit. You could do amazing things with it, it could be a 300 or 1200 baud modem, it could also answer the phone as an IVR and take messages.

There was a nice little telephone keypad and headset that went with it as well, but I do not have those options. Need to find one.

Hope this helps! Chris

If you have a question that you would like to have answered, click edit to add it to the list.

IVIS was a system complete with DEC PC, video disk, and authoring language, created to develop qnd deliver courses for DEC's Education Services group. it was conceived and developed by Dr. Jesse Hines. —The preceding unsigned comment was added by 66.189.44.59 (talk • contribs) 15:36, 26 January 2016 (UTC)

• w:Digital Equipment Corporation
• w:DEC Professional (computer)
• w:DEC J-11
• w:PDP-11

• w:OpenVMS
• w:Digital Data Communications Message Protocol
• w:VAX 8000 series
• w:DECUS (users group)
• w:Encompass (users group)
• w:Connect (users group)

• The RX50 FAQ
• VR241 monitor and cable