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: 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.
 
    Steve Mitchell  steve@cps.altadena.ca.us
----

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. 

    Glenn Everhart  Everhart%Arisia.decnet@crd.ge.com

 
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 seperate 
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      GRAEME@praxa.com.au


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       Everhart%Arisia.decnet@crd.ge.com                    

  
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          wampler@MicroUnity.com 

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      Everhart%Arisia.decnet@crd.ge.com

   
There is now an anonymous ftp site for PDP-11, PDP-8, Professional and
Rainbow machines on 'ftp.update.uu.se'. 

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        tomk@csd.uu.se

  
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   tung@eniac.seas.upenn.edu

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)

        - Michael Umbricht   mikeu@osfn.org

  
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 cleaner 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          tmiller@chaos.cs.brandeis.edu

  
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    chaim@linc.cis.upenn.edu

  
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       ivie@cc.usu.edu

                         **************************

>> 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   (kcwellsc@watdragon.uwaterloo.ca)

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  mbg@world.std.com

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  lasner@watsun.cc.columbia.edu 

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  mbg@world.std.com

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    kcwellsc@watdragon.uwaterloo.ca

 
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  chaim@linc.cis.upenn.edu
   David Lesher   wb8foz@ibiza.cs.miami.edu

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      wampler@MicroUnity.com
   Charles Lasner    lasner@watsun.cc.columbia.edu

 
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 V
4.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   lasner@watsun.cc.columbia.edu 

 
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  lasner@watsun.cc.columbia.edu 

 
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  lasner@watsun.cc.columbia.edu