RX50_FAQ

Frequently Asked Questions File for RX50 Users regarding PC's, etc.

Everything you ever wanted to know about RX50 and PC's, etc.  Aren't you
glad you asked? 

Currently maintained by Charles Lasner: lasner@sunsite.unc.edu.

     The latest version of this file is always available in the
PDP-8/DECmate archive on sunsite.unc.edu as the file rx50faq.doc in the
directory pdp-8/docs.  As of this writing, pdp-8 is a symbolic link to the
directory /pub/academic/computer-science/history/pdp-8.  Anonymous ftp
users may have to type the whole path in the hard way. 

Version 1.1.2  21-APR-1994

     RX50 diskette format is used on a variety of DEC systems and can be
used to interchange files with other machines, especially PC's. This
document will attempt to relate all relevant topics including formatting
problems/solutions and file conversions using programs that run on
suitably configured PC's. 

I.   RX50 applications.

     There are several classes of RX50 usage:

     1) PDP-11 type usage which includes one of Files-11 or RMS-11,
        RT-11 etc., directory structure applied over the low-level RX50
        format.  This applies to the various Micro-11 and PRO models, and
        to any Q-bus -11 with the appropriate add-on RX50 and controller. 
        Certain VAX systems also belong to this category.

        All of these are noted by the fact that they utilize the standard
        format RX50 with no hardware stagger and 1:1 interleave in a very
        efficient manner because the prevailing software implements the
        appropriate mapping.  Any attempt to change the low-level format
        will de-optimize the disk performance.

     2) MS-DOS type usage which includes DECmate II with the XPU option
        board and Rainbow.

     3) CP/M type usage which includes DECmate II with the APU or XPU
        option boards, Rainbow, and PRO with the APU option board.

     4) WPS and other application-specific formats used on DECmates. 

     5) OS/278 and other specific O/S usage on DECmates (such as COS-310
        and P?S/8).  Most notably, seemingly stand-alone utility disks such
        as the DECmate System Test Diskette, or Master Menu Install "A", or
        WPS Install etc., are actually OS/278 format bootable diskettes!
        Some of these formats have differing requirements and shouldn't be
        lumped together.  In some instances, the requirements change within
        an operating system such as P?S/8-OS/278 byte-oriented disks and
        the corresponding 12-bit-oriented disks, etc. 

     6) Other formats such as DECmate Master Menu backup format.  Some of
        these formats have differing requirements and really shouldn't be
        lumped together, but they are relatively obscure and known only to
        certain DECmate users.

II.  Low-level format considerations.

     Certain of the prevailing formats of RX50 have been used in an
optimal way when the diskettes are formatted in the default manner of no
stagger factor and 1:1 interleave.  However, certain specific applications
have been compromised for various reasons and in these cases specific
format variations can drastically change disk performance.  (Note:
hopefully these variations cause performance *improvement*.  One of the
tradeoffs of this form of "fine tuning" is that using an incorrect
variation is likely to *lower* performance!)

     The consideration of stagger factor is that invariably it is either 0
or 2.  Stagger factor refers to the notion of deliberately "sliding" back
the sequence of sector numbers on a track without changing their order. 
Relative to the index hole, an RX50 with 1:1 interleave and no stagger
would have each track's sectors in the order (from index): 
1,2,3,4,5,6,7,8,9,10. 

     There is a problem when transferring sector 10 on a track and then
seeking to the next track for sector 1, because the next physically
available sector is not sector 1, but rather sector 2 occasionally, or
more likely sector 3.  This is because the disk is spinning as the head
arm seeks to the next track.  The next reliable sector to seek to and
avoid a "penalty" of nearly an entire revolution without useful transfer
would be sector 3 on most systems. (Note: This implies that totally
different starting sectors are the first referenced on specific tracks
since the mapping is cumulative!) Some software includes such a stagger in
the software map so that indeed sector 3 would next be transferred in such
a situation, such as sequentially transferring track 1 then track 2 in a
situation as described in the example. 

     An alternate approach is to actually low-level format the diskette
with the stagger built into the format.  Thus a diskette with a stagger
factor of 2 would lay out the sectors as: 

Track 1: 1,2,3,4,5,6,7,8,9,10
Track 2: 9,10,1,2,3,4,5,6,7,8

In this case, sector 1 actually is the next reliably available sector when
seeking to track 2 after transferring sector 10 on track 1. 

     All PDP-11 software should never use any stagger options because of
the software mapping already in place, but other systems may benefit. 

     MS-DOS, COS-310 and all 12-bit P?S/8 and OS/278 disks can have
improved transfer by including a stagger of 2. (Note: Most OS/278
diskettes are 12-bit-mode while most P?S/8 disks are byte-mode. However,
variations of both exist.) CP/M diskettes may already have the stagger
factor accomodated in software.  If in doubt, tests should be run to
determine if a stagger of 2 helps or hurts.  If there is no change, the
test is likely defective as stagger usually noticeably helps software that
can use it and also noticeably degrades software that is better off
without it. 

     (The test chosen may be dominated by overhead unrelated to the
format's stagger factor etc., which could "swamp" the effect being sought. 
In addition, it is conceivable that there is partial device mapping such
as having the tracks for the directory structure be mapped differently
from the data tracks.  It has been determined that this is indeed the case
for Rainbow MS-DOS with regard to interleave. Thus, it may be necessary to
use a suite of tests designed to independently test out format variations
by disk region, etc.)

     All DECmate bootable RX50 diskettes require that tracks 78 and 79 be
treated specially, as these two tracks are where the binary data for the
so-called "slushware" is located.  For at least these two tracks, it is
useful to stagger (and interleave) the format on these diskettes. 
Additionally, portions of track 00 of DECmate bootable diskettes can
benefit from a 2:1 interleave as well.  (Stagger isn't an issue on track 0
of any diskette!)

     The consideration of interleave factor is a separate issue from the
stagger factor, although the two combine when determining the order of the
sectors on the diskette. 

     Most applications of RX50 work best with a 1:1 interleave because the
prevailing hardware and software work well at 1:1 or the prevailing
software maps the sectors to a 2:1 interleave for improved performance. 
In such a case, changing the hardware interleave would degrade
performance. 

     A notable exception is any diskette meant to be booted on a DECmate
II, III, or III+.  The DECmate ROM inefficiently reads in the sectors of
tracks 78 and 79 (and some sectors on track 00) in linear order without
benefit of stagger or interleave.  Thus applying the stagger and
interleave techniques to the low-level format will drastically improve
bootstrap performance on these systems. 

III. Formatting programs.

     The only DEC methods for formatting diskettes are to either attempt
to format them on a Rainbow CP/M system or to buy preformatted media.  The
Rainbow method may not be desirable because of potential alignment
problems of RX50, especially early revisions of the drive.  Disk
formatting should be accomplished on a more accurately aligned drive to
achieve maximum reliability as well as interchangeability.  (Note: it is
possible to upgrade a Rainbow system to use a drive such as a TEAC FD-55
series.  In that case the Rainbow's ability to format is just as good as a
PC!)

     Most PC's today are IBM-compatible, and have high-density disk
drives.  There are also a few DEC workstations that optionally support
SCSI adaptors that may support high-density drives and RX50 format
specifically.  Some may support low-level formatting in RX50's 80 track 10
sector format. 

     Most of the relevant PC applications/utilities discussed here are
geared for some specific purpose, such as supporting a single file
structure for interchange purposes, etc.  As a side issue, they generally
include the ability to low-level format RX50 diskettes, usually only in
stock format of no stagger and 1:1 interleave.

     Once formatted by any of these programs, the resultant diskette can
be used for any RX50 application, as virtually all of the RX50 support on
the DEC systems (and some of the PC-based packages) include directory
initialize or other high-level structure support while maintaining
existent low-level format.  (All DEC-only systems other than the Rainbow
can't change the low-level format at all!)

     However, note that some of the utilities should be used to fine-tune
the diskette format for specific applications where warranted.  Applying a
variant-formatted diskette will be functional, but will likely perform
worse when used in the wrong application than would a standard diskette! 

     Wherever applicable, distribution of these programs may include
user-written documentation to augment any supplied with the program itself
by the author.  In general, the user-written documentation will supersede
the original documentation, because it relates actual experience with the
program! 

IV.  Utilities and their strong and weak points.

1)   22DISK

     22DISK is a shareware package from Sydex that is oriented towards
interchanging CP/M diskettes with MS-DOS.  It has been tested with MS-DOS
3.30 and newer versions, and also DR-DOS 6.0, without problems.  Literally
hundreds of different CP/M disk types are supported.

     The two of interest here are Rainbow CP/M-86/80 and DECmate CP/M-80. 
These two formats are similar but differ in ways that are handled by CP/M
on an individual diskette basis.  Thus, DECmate and Rainbow CP/M systems
can freely interchange each other's disks, although throughput on each
other's systems will be somewhat degraded compared to that on the disk's
intended home system.  There is an obscure option for the PRO series to
also support CP/M-80; presumably it is compatible with either the DECmate
or Rainbow CP/M. From the 22DISK vantage point, selection of either
DECmate or Rainbow CP/M format achieves the same results, etc. 

     22DISK can format RX50 diskettes and reports errors as they occur. 
This may be useful when using marginal diskettes with some applications
that have difficulty determining flaws in their own environment, etc.  In
particular, it is likely that a diskette that formats without errors under
22DISK can be used with another system's data structure without checking
for errors.  (For example, RX50INIT, a portion of the RX50DRVR package, is
only able to write an error-free initialized MS-DOS directory to an
already (low-level) formatted RX50.  It is incapable of checking for
errors, so if the disk passes muster with 22DISK, this is acceptable,
etc.)

     22DISK can create directory listings of CP/M diskettes and transfer
files in both directions between CP/M and MS-DOS. 

     Note: While not specifically RX50 related, there is also another
Sydex package called 22NICE that can emulate the Z80 to allow execution of
CP/M-80 programs on the PC.  It also supports the hardware modes of the
CPU should it be a V20 or V30.  All files are actually MS-DOS files, but
the CP/M environement is what's emulated.  This allows programs taken from
Rainbow or DECmate CP/M-80 to be run on the PC, etc. 

2)   RX50DRVR, RX50INIT, MULTIDRV

     RX50DRVR is a freeware program that acts as an MS-DOS driver.  It
creates a logical drive that is physically the A: drive which must be
5.25" high-density.  The logical drive is the next available in sequence
at the point of driver installation in CONFIG.SYS and is indicated in
console messages as the system is configured. 

     RX50DRVR is also available in a variant version for use on 8088/8086
machines that have the 3-speed floppy hardware and ROM that allows typical
AT-type support of high-density floppies on an XT-class machine.  The
standard version requires a '286 processor or better.  The XT variant is
the only version that should be used on XT-class machines.  It is possible
that the XT variant should *not* be used on '286 or better systems; it
certainly runs slower on such systems, but probably not in a way
significantly affected by these variations, etc. 

     RX50DRVR does not support certain more recent DOS extensions beyond
DOS 3.30 and thus will not work with FORMAT or CHKDSK and a few other
programs in newer DOS versions.  It also doesn't work with FORMAT at all
because it lacks support for the format-track function call.  When used
with MS/PC-DOS 4-6, certain CONFIG.SYS parameters (BUFFERS=xx,1) must be
set to allow file reads and writes to work at all.  (Certain specific
cases of file size and grouping may aggravate this problem.  Sometimes
users report problems with either the COPY or XCOPY commands, etc.) There
are no problems in this portion of the program when used with DR-DOS 6.0,
which can also accomplish the CHKDSK function, because DR-DOS functions
without the extensions first required in MS-DOS 4 that RX50DRVR doesn't
support. 

     There is a companion program in the package called RX50INIT which
requires that RX50DRVR (or RAINDOS; see below) be present.  For purely
cosmetic reasons, RX50INIT also requires ANSI.SYS. 

     RX50INIT will initialize the directory of an already low-level
formatted RX50 diskette.  The only problem is that there is no provision
to account for bad sectors that may be on the diskette; the directory
structure is written assuming an error-free diskette.  Thus it is
important to note whether 22DISK (or other formatting program) reported
any errors while formatting. 

     RX50INIT will not run at all from DOS 4-6.  It works fine on DOS 3.30
and DR-DOS 6.0. 

     There is a variant to RX50DRVR called MULTIDRV.  It is based on
RX50DRVR, but it eliminates the need for a separate logical drive letter. 
Instead, references to drive A: are "smarter" and will still support the
1.2 MB and 360K floppies normally used, as well as RX50. In all other
ways, it has the same advantages (and disadvantages!) of RX50DRVR. 

     A common problem when using RX50DRVR, MULTIDRV or RAINDOS is various
forms of drive confusion when circumstances require a normal PC A: boot
floppy to be loaded into the A: drive.  This class of circumstances only
occurs when the boot device is the A: floppy, thus the user is advised to
avoid this circumstance where possible. (Note: This isn't always the case;
due to certain interactive problems, boot floppies are used to run under
alternate operating systems where required!). 

3)   FORMAT.COM (from MS-DOS 2.11 for the XPU/DECmate II release 1.01)

     FORMAT.COM from the DECmate II MS-DOS 2.11 release 1.01 can be run on
a PC (as well as on a DECmate!) with limitations.  If used with the /C
option, it becomes functionally equivalent to RX50INIT and used this way
can be run from DOS 4-6.  If the option is not invoked, then existent
errors will be discovered.  If run from a DOS system newer than 2.xx,
discovering errors will cause FORMAT.COM to crash!  If there are no
errors, then the program will exit normally.  Thus, FORMAT.COM is useful
where RX50INIT won't work, or to at least confirm that a disk is actually
error-free, etc. 

     To use FORMAT.COM, it is required that the logical drive that covers
the RX50 in the A: drive be drive D: or less.  This may require a floppy
bootable system, especially if the floppy is a PC-DOS 2.10 system, which
is essentially a requirement if the bad cluster feature is to work at all. 
DOS 2.xx systems will generally fail to notice the hard disk structures of
most newer versions, so the driver will generally install as C: on such a
system, thus fulfilling the requirement of being in the range A:-D: for
the target logical drive.  MULTIDRV usage should obviate this problem
entirely since RX50 references also use drive A:. 

4)   Norton Utilities DT

     The Norton Utilities Version 4.50 (and previous) support a utility
called DT which is a Disk Test utility.  It attempts to read every disk
sector and can optionally mark bad clusters it finds.  It works well with
RX50DRVR on any version of DOS or DR-DOS as long as the CONFIG.SYS
parameters are adjusted correctly.  (When running from DOS 4-6, the
CONFIG.SYS parameter should be given as BUFFERS=15,1 for best overall
performance.  The ,1 is required for most usage to work at all.  Note:
Earlier DOS systems and DR-DOS 6.0 don't support this switch option, but
may allow it to be present while ignoring it.)

5)   CHKDSK with /M set (from DR-DOS 5.0)

     DR-DOS 5.0 supports an option to CHKDSK called /M.  This is
functionally equivalent to the workings of Norton DT.  Note: CHKDSK of
DR-DOS 6.0 does not support this option!  The CHKDSK from 5.0 can be run
from other systems to use the feature, most likely MS-DOS 3.30 or any
newer system, including DR-DOS 6.0.  Moreover, unlike DT, certain errors
do not cause it to abort due to misinterpreting returned status as "drive
not ready" during the testing process. 

6)   RAINDOS

     RAINDOS.SYS is a shareware program from Sydex that is mostly a
replacement for RX50DRVR.  It fully supports CHKDSK and FORMAT, etc. The
only known problems with it are: 

     a) It is sometimes confusingly slow.  When used with Norton DT, there
        are unexpectedly many disk recalibrate operations that cause it to
        run quite slow compared to the same operation with RX50DRVR.

     b) When the low-level format operation is attempted using FORMAT under
        DR-DOS 6.0, there is an error message "drive already locked by
        another program" and an immediate abort.  Note that when there is a
        "quick" format operation there is no actual low-level formatting
        performed, so the command functions normally.

     c) If loaded from a floppy-booted system, the shared use of drive A:
        with the system device confuses the O/S. (Although somewhat
        differently from the confusion associated with RX50DRVR and
        MULTIDRV in similar circumstances.)  After the first usage of the
        logical drive for RX50, all further attempts to access drive A: 
        will only work with low-density 360K-type floppies.  High-density
        diskettes will get a general failure message that will not be
        correctable without changing to a low-density diskette.

     d) When RAINDOS is loaded, attempts to format standard 1.2 MB and 360K
        diskettes will function, but sometimes quite slowly, often
        accompanied by a recalibrate on every track, but only above some
        particular track.  (Best guess is about track 20 is where this
        starts to happen.)  The diskette will be properly formatted, but
        total format time is greatly increased.  Only the DOS FORMAT
        command is affected and the overall problem is noticeably worse on
        DR-DOS 6.0.

In all other ways, RAINDOS does everything that RX50DRVR ought to do.  It
neither helps nor hurts other programs such as RX50INIT, etc.  However,
when RAINDOS can be used, RX50INIT is often unnecessary, since attempts to
use the FORMAT command on MS-DOS 5.0 or newer, or DR-DOS 6.0 will support
a "quick" format (and can be forced by use of the /Q switch).  Moreover,
when the FORMAT command is used, detected flaws will cause marking of bad
clusters.  The quick format will preserve the existing bad cluster
marking, etc. 

7)   DR-DOS 6.0 DISKCOPY and DISKCOMP (with RAINDOS)

     An additional utility of RAINDOS under DR-DOS 6.0 is the ability to
use DISKCOPY and DISKCOMP on MS-DOS RX50 diskettes.  DISKCOPY and DISKCOMP
can access entire diskette images stored as MS-DOS files. RX50 diskettes
can be accessed using RAINDOS (but not RX50DRVR).  It is important to note
that only valid MS-DOS diskettes can be used with these utilities, whether
RX50 or otherwise.  Once the diskette images are stored as MS-DOS files,
they can be processed with other utilities for a variety of purposes such
as compression, archive, e-mail, etc. 

     An interesting quirk of using DISKCOPY to write an RX50 diskette is
that while target diskettes must already be low-level formatted to RX50
format, the high-level format data pre-existing on the diskette about to
be written on is ignored, i.e., it need not be valid MS-DOS data.  Thus,
it is possible to initialize an MS-DOS diskette by first using a program
such as 22DISK (which imparts a high-level CP/M-80 structure, not
MS-DOS!), then using DISKCOPY to write over the diskette with an image of
a previously initialized MS-DOS RX50 diskette. 

     While this may seem to be "the long way around" for MS-DOS, it's
actually the easiest way from DR-DOS 6.0 where RAINDOS cannot format! Once
a diskette is formatted and copied, you have some confidence in the
media's reliability.  If RX50INIT is used, the diskette is not tested, but
merely presumed to be error-free. (This is hopefully coupled with perhaps
your prior observance of 22DISK not issuing error messages during the
low-level format!)

     Additionally, the image file of the initialized diskette can be
compressed down to only a few percent of the normal image size of an
entire RX50 using the normal compression utilites such as PKZIP, etc.; the
uncompressed image file can be deleted after a session of formatting
media, etc. (Note: An alternative to using 22DISK to format followed by
DISKCOPY to write on the media is to use TELEDISK (see below) with an
image file of a formatted empty MS-DOS RX50 diskette, and this will also
work on DR-DOS 6.0.)

8)   DOS FORMAT command (with RAINDOS)

     When RAINDOS is used with the DOS FORMAT command, the correct usage
is: 

FORMAT {drive}: /T:80 /N:10 /1

On some systems it may not be possible to use the /1 because FORMAT
sometimes restricts /1 to be an option of low-density formatting only, and
is intended to make 160K or 180K diskettes only.  In this case, /1 will
have to be left out of the command, and a two-sided disk will result. 
Such a diskette is not high-level compatible with DEC MS-DOS usage.  In
which case RX50INIT or the DECmate FORMAT.COM program or DISKCOPY of an
initialized diskette image (DR-DOS only) will have to be used to create a
correct MS-DOS directory if desired. 

     Generally, DOS FORMAT programs indicate errors on the disk, although
not necessarily which specific areas are affected.  If the /1 can be
included and there are errors, the affected disk clusters will be
correctly marked as bad. 

9)   800K and 800 (aka 800 II)

     There are shareware or freeware programs such as 800K.COM and 800 II
that either directly format diskettes to double-sided equivalents of RX50
or allow a similar augmentation of the DOS FORMAT command as does RAINDOS. 
The limitations of the lack of /1 switch option will still likely apply as
well, so the same actions must be taken with disks created using these
utilities.  800 II is a TSR that allows FORMAT to use more flexible
options and can also be useful for creating larger diskettes, or
special-purpose diskettes such as 5.25" diskettes that are seemingly
identical to 3.5" 720K diskettes.  They are sufficiently close that
DR-DOS's DISKCOPY program will succeed in copying betwen the 3.5" and
5.25" versions.  Alternatively, a 3.5" diskette can be formatted to the
standard 360K or 1.2 Meg sizes. 

10)  FDFORMAT (and FDREAD, FDR88, WIMAGE)

     FDFORMAT (latest version 1.8) is a PD program that comes from
Germany.  (Make sure your proper choice of german or english language
messages is what you are running!  FDFORMAT.EXE is the name of either
language version.) It can be used for many different format improvements
on PC's, and can be instrumental in the cause of RX50 formatting. 

     FDFORMAT can manipulate the number of tracks, sectors, interleave,
and stagger (aka "slide") to produce customized formats.  Some format
commands can create diskettes that are faster to access from MS-DOS, while
other formats can give greater capacity, often coupled with a tradeoff of
performance.  Most of these features only apply to PC-based MS-DOS and
DR-DOS, and are of no consequence to RX50 diskettes. 

     Specifically for RX50, FDFORMAT offers the ability to create
diskettes with custom interleave and stagger factors, especially for
problematic cases such as where the format ought to change in the middle
of the disk, etc.  For example, a DECmate-bootable CP/M-80 diskette would
best have tracks 78 and 79 formatted with 2:1 interleave and a stagger
factor of 2, yet have the rest of the disk be formatted with 1:1
interleave, because the access to the rest of the disk is mapped with a
2:1 interleave.  (Insufficient testing has been performed on this format
to determine if a stagger factor of 2 within the first 78 tracks would
help or harm CP/M-80 format!) To accomplish this layout, first format the
entire diskette to produce a proper track 78 and 79: 

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

The T:80 means 80 tracks; N:10 means 10 sectors; H:1 means one head or
side; Y:2 means a stagger (slide) factor of 2; I:2 means 2:1 interleave. 

     After the first format is accomplished, then invoke the command:

FDFORMAT A: /T:78 /N:10 /H:1

This makes the first 78 tracks (00-77) be reformatted in 1:1 interleave
without stagger, but preserves the stagger and interleave on tracks 78,
79.  The resultant disk is optimal for a bootable CP/M-80 DECmate APU
system, etc. 

     Each system (other than -11, VAX, PRO, etc.) needs a variant amount
of "help" in this manner, so it will become necessary to test out various
formats for each specific application.  A rule of thumb should be that
when a format variant is used for the wrong purpose, it should "hurt" that
wrong use more than it "helps" the intended purpose as compared to
standard format.  The following notions should be useful as a starting
point: 

     a) All DECmate II, III, III+ diskettes that are to become bootable
        need to have tracks 78, 79 set to 2:1 interleave, and preferably a
        stagger factor of 2 as well.  If possible, track 0 should also have
        a 2:1 interleave.  (Note: the current version of FDFORMAT cannot
        fully accomplish this as track 0 is not formattable separately.)

     b) OS/278 12-bit diskettes must *not* have a 2:1 interleave in tracks
        01-77 since the system's handlers map the sectors in 2:1 order
        assuming the diskette is formatted 1:1.  However, a stagger of 2 is
        needed because there is no stagger adjustment as found in some
        other systems.  All OS/278 12-bit diskettes are potentially system
        diskettes; non-system diskettes do not use the slushware reserved
        tracks.  For purposes of these considerations, note that COS-310
        diskettes are identical to OS/278 12-bit diskettes.

        Byte-mode OS/278 diskettes are always non-system diskettes.  All such
        diskettes should always be formatted to the normal standards since the
        software handlers for these diskettes use efficient mapping analogous
        to the PDP-11 type handlers, etc.

     c) CP/M-80 diskettes may use internal mapping of standard format, thus
        the use of stagger and interleave could de-optimize the disk format.
        However, the format was created for the benefit of the Rainbow, and
        on the DECmate, certain operations take longer to carry out.  Thus,
        use of the diskette on the DECmate will likely be better served
        setting 2:1 interleave, a stagger of 2, or possibly both.  In any
        case, DECmate CP/M-80 diskettes *not* used for boot purposes reclaim
        the usage of tracks 78, 79, so whatever best serves the overall
        diskette should be applied to these tracks as well. (While bootable
        diskettes need to conform as stated in a) above.)

     d) MS-DOS diskettes for DECmate XPU usage are clearly different from
        their Rainbow counterparts in terms of performance.  This is because 
        the format is identical to the Rainbow MS-DOS diskette, but the
        floppy hardware is much faster on the Rainbow (where a dedicated
        Z80 does the floppy I/O).  Thus, portions of the disk currently
        allocated mapped 1:1 for best Rainbow usage should be formatted
        with 2:1 interleave for the benefit of the DECmate. 
        
        NOTE: *ALL* MS-DOS systems everywhere need to have the data areas
        of the diskettes formatted to a stagger factor of 2 because
        Microsoft's system has no reckoning of this problem!  Indeed, one of
        the primary reasons for the original creation of FDFORMAT was to
        add stagger support for otherwise standard PC diskette formatting,
        since just changing that factor improves diskette access 50-100%!

        In the case of the Rainbow-oriented MS-DOS diskette, the FAT and
        directory area (about the first 4 tracks) are already mapped with a
        2:1 interleave logically, so these tracks should be formatted with
        1:1 interleave; a stagger factor of 2 is likely innocuous here. 
        However, the rest of the diskette needs to be formatted with 2:1
        interleave for DECmate usage, and with a stagger factor of 2 for
        DECmate or Rainbow usage alike.  As with CP/M-80, non-bootable
        diskettes use tracks 78 and 79 for data storage, so boot diskettes
        have to be treated differently from data-only diskettes.

     e) WPS diskettes likely map as well as -11 diskettes, and shouldn't
        require any special considerations.  However, bootable WPS
        diskettes will require the same considerations as any other DECmate
        bootable diskettes regarding tracks 00, 78, 79.  It is believed
        that WPS will use tracks 78, 79 for data on non-boot diskettes.

     f) P?S/8 diskettes always reserve the ability to be bootable, much the
        same as OS/278 12-bit diskettes.  12-bit P?S/8 diskettes have the
        same tradeoffs as 12-bit OS/278 diskettes.

        Byte-oriented P?S/8 diskettes will perform best in standard format
        since PDP-11-style mapping is used.  (However the need to format
        tracks 00, 78, 79 as in 1) above applies!)

     g) There are sundry other formats used on the DECmates such as Master
        Menu backup diskettes.  More research is needed to determine what's
        best for these diskette applications.  In general, since the usage
        is uniform throughout, and the diskette is never bootable, the
        factors will distill down to whether to apply a 2:1 interleave
        and/or a stagger/slide factor of 2 to the entire diskette.  Note:
        Various utility diskettes such as WPS install, Master Menu install
        "A", System Test Diskette, etc. are actually 12-bit OS/278
        diskettes!  (Master Menu "B" is actually a Master Menu backup
        diskette!  Installing Master Menu is actually equivalent to
        restoring (from a pre-existing Master Menu utility that would
        be executing!) the copy of the volume named MENU (the one Master
        Menu is itself loaded in from).)

All of the above FDFORMAT considerations are partially moot! Diskettes
created by FDFORMAT for optimized usage on a particular system are
optimized for layout only!  The actual ability for FDFORMAT to format even
a single standard diskette is only marginally true! 

     There appears to be a bug in FDFORMAT pertaining to the creation of
10-sector diskettes.  Some people have postulated that the "gap" settings
of FDFORMAT are incorrect for the RX50 format, which admittedly pushes to
the edge the ability for a 250 KHz media to contain sectors.  (Note: IBM
first used 8 sectors, then 9 sectors in their DD formats, never 10
sectors!) FDFORMAT does support a /G:g switch for a gap parameter, but no
value setting seems to produce a reliable diskette read/writable on every
system.
 
     Certain DECmate systems are especially prone to failure to accept
diskettes created by FDFORMAT directly (see below for a workaround).  In
fact, many diskettes will have the bizarre behavior of being able to
apparently write data on the diskette, then immediately not be able to
read the data back!  Using these diskettes on the PC where they were
formatted presents no problems.  Apparently, the author didn't test the
viability of formatting diskettes on RX50 systems.  When the same media is
formatted by 22DISK etc., the diskettes are perfectly readable on DEC
systems as well as PC's. 

     Moreover, FDFORMAT is known to misinterpret certain errors during the
formatting process.  Diskettes can be created in error, yet FDFORMAT can't
detect the flaws.  Certain tests have been performed with physically
damaged floppies.  While 22DISK and RAINDOS correctly report errors,
FDFORMAT reports no problems.  Attempts to access the flawed tracks with
other utilities will always yield errors. 

     (Note: When FDFORMAT creates a 10-sector MS-DOS oriented diskette,
the MS-DOS structure imparted is not compatible with the Rainbow and
XPU-DECmate MS-DOS structure.  Thus, utilities have to be run on the
diskette following FDFORMAT to achieve whatever data structure is desired. 
Generally speaking, the PC can read/write the diskettes created by
FDFORMAT in RX50 10-sector low-level format without problem; problems only
arise when the media are moved to the actual DEC systems.)

     Thus, the only useful function FDFORMAT accomplishs to RX50 advantage
is to create "template" disks for subsequent usage with TELEDISK (see
below).  The sector ordering is very important, but diskettes have to be
created and tested for defects after the formatting to determine if the
diskettes truly are error-free! 

     When using FDFORMAT, it may be necessary to run the companion FDREAD
program.  (Note: On XT-class systems, the alternate file FDR88 must be
used!) This is a TSR program that allows FDFORMAT to set non-standard
formatting parameters.  It is possible that the 800 program can be used
instead of FDREAD for the same purpose. 

     On certain configuration of DR-DOS, it may be necessary to invoke the
command MEMMAX -l before attempting to load FDREAD to avoid an indicated
error regarding "too much memory." Following the FDFORMAT documentation
will likely fail.  (It indicates to attempt to load FDREAD several times
to clear the problem, but this often doesn't work.) (MEMMAX +L restores
memory allocation to the normal state afterwards.)

     A companion program to FDFORMAT is WIMAGE.  This program can transfer
entire diskette images from/to MS-DOS files similar to the DR-DOS DISKCOPY
program.  (Note: The files created by DR-DOS 6.0 DISKCOPY and WIMAGE are
not compatible!) WIMAGE provides a means of storing a diskette image as an
MS-DOS file, which in turn could be compressed and archived, etc. 
However, it is restricted to MS-DOS formats only, including any and all
variants created by FDFORMAT such as the 10-sector MS-DOS format that is
not compatible with Rainbow MS-DOS.  WIMAGE will not copy diskettes that
aren't high-level formatted for MS-DOS by either standard formatting
programs or FDFORMAT.  WIMAGE can run from any DOS system, thus has the
advantage of not requiring DR-DOS.  

     WIMAGE does not format the diskette.  Thus, the image data is merely
copied to the diskette, not the low-level format parameters of stagger and
interleave, etc.  Thus, while of much utility for standard PC diskettes,
it offers little functionality for RX50 diskettes.  (Note: RAINDOS
installed on DR-DOS allows DISKCOPY to correctly handle Rainbow and
XPU-DECmate II RX50 MS-DOS diskettes. Neither DR-DOS DISKCOPY nor WIMAGE
allow non-MS-DOS diskettes.)

     Someone is working on a variation of WIMAGE that will allow
non-MS-DOS diskettes.  More information should be available soon.

11)  TELEDISK

     TELEDISK is a shareware (and commercial! see below) program that can
copy virtually any diskette format to/from an MS-DOS file, including RX50
format diskettes.  Since there is no requirement that the data be
reckonable from an MS-DOS system, this allows any RX50 diskette to be
converted to an MS-DOS file, to be further processed for compression,
archiving, encoding, e-mailing, etc.

     When TELEDISK reads an existant TELEDISK file, the output diskette is
formatted and copied all at once.  As the format on the diskette is read,
status messages are written to the screen to inform the user of changes in
the format such as interleave or sector counts, etc.  Thus, the progress
of a disk's copying can be monitored looking for unexpected changes, etc. 

     Most notably, diskettes formatted with FDFORMAT can be successfully
read by TELEDISK.  However, when TELEDISK writes a diskette copy from the
file, the output diskette is reliable for all purposes including use on
DEC RX50 hardware.  Thus, all of the considerations of using FDFORMAT to
create special-purpose diskettes can be achieved by using TELEDISK to
create the actual diskettes! (Thus, TELEDISK becomes a "formatting"
program and FDFORMAT is used as a "format design tool"!) As TELEDISK
processes the RX50 diskette created by FDFORMAT, you can observe where the
interleave changes, etc.  There are several problems/considerations
associated with TELEDISK: 

     a) TELEDISK sometimes gets fooled into believing that I/O errors
        represent a variant of formatting.  It will erroneously reproduce
        its misreckoning of the format on the target diskette.  To ensure
        proper operation, it is recommended that diskettes are first
        formatted on the actual PC that will be used to operate TELEDISK,
        then brought to an appropriate DEC system to copy the intended
        contents onto the freshly formatted diskette, then the media should
        be brought back to the PC to be processed with TELEDISK.  Use of the
        original RX50 diskettes will often encur this problem, but whenever
        the media is formatted on the PC used with TELEDISK, the problem
        will generally disappear.

        Note: If using a variant disk format, the process is to first use
        FDFORMAT to define the disk sector layout, then read that diskette
        into TELEDISK to define an MS-DOS file that preserves the sector
        order (contents unimportant!), then use TELEDISK to output a
        corrected version of the custom-ordered diskette, then bring that
        diskette to the DEC system for data copy, then bring that diskette
        back to the PC for processing with TELEDISK.  The resultant MS-DOS
        file can then be used later with TELEDISK to produce diskettes
        which are both low-level formatted as desired, and also contain the
        desired contents.

        This method can be used to create standard "master" diskette
        formatting files that create system-specific RX50 diskettes that
        are correctly low-level structured for the intended usage, and also
        have empty directories and/or pre-configured system information on
        them, etc.  For example, an MS-DOS TELEDISK file could contain the
        image of a 12-bit OS/278-oriented RX50 diskette, where tracks 00
        and 78 and 79 are formatted to 2:1 interleave while tracks 01-77
        are formatted with 1:1 interleave, and a stagger factor of 2 is
        applied throughout.  The slushware could be applied to tracks 00,
        78, 79, and a valid zeroed-out OS/278 directory structure applied
        to the data area.  At any time TELEDISK could process this file to
        produce these ready-to-go OS/278 diskettes from formerly
        unformatted media.

     b) TELEDISK purports to have the ability to copy diskettes without
        creating an MS-DOS file that in turn can be processed into an
        output diskette.  It has been observed that this feature doesn't
        work.  Always create the MS-DOS file and delete it afterwards if
        desired.  Most users of TELEDISK will either desire to create
        files, or will use files provided by others; the lack of a one-step
        copy facility is a minimal problem (since it works fine as a
        two-step facility!).

     c) TELEDISK doesn't have a way to create non-compressed MS-DOS files. 
        Instead, two alternatives are provided: simple zero-data-only
        repeat compression, and LHARC-style compression.  The first is
        minimally unfortunate because it thwarts the best efforts of some
        other compression techniques.  (Most will still process the
        zeroes-compressed files further to produce better results, etc.)

        The second produces a fairly-well compressed file, but impacts
        negatively on the performance of TELEDISK since data compression and
        decompression is done during the disk operations. Often it is
        better to use the first method, and then use PKZIP or some other
        file compression technique on the data file.  TELEDISK will then
        work faster since it using the zero-compression only format. 

        Additionally, programs such as PKZIP are known to compress data
        better than LHARC (besides generally being much faster); clearly
        it's better to separate compression from the overall operation of
        disk writing so that the latest compression technology can be used,
        etc.

     d) While not directly observed on RX50 diskette images, TELEDISK has
        been reported to fail to produce correct TELEDISK files. (It has
        been reported to occasionally produce corrupted files of 1.44 MB
        3.5" floppies in standard MS-DOS format for PC's.) Using some of
        the FDFORMAT-specific MS-DOS variants, TELEDISK has been observed
        to create diskettes with proper low-level format, but incorrect
        data (specifically: 3.5" 1.72 MB diskettes of 82 tracks, 21 sectors,
        2:1 interleave).

        The only true way to ensure that TELEDISK is working correctly is to
        reproduce an RX50 diskette copy of the original, then compare the
        diskettes on a DEC system to ensure format and data integrity, etc.
        If available, the TDCHECK program (see below) can be used to
        quickly reject files that are corrupted.

     e) TELEDISK also has a "political" problem: Version 2.12 of TELEDISK
        is widely available as a shareware version.  As of Version 2.13,
        the author/seller of the program (Sydex) has decided that the
        program should now be considered a commercial product, i.e., it is
        not distributed as shareware, but must be paid for, and is not
        available for any "test drive" purposes, etc.  Moreover, the fee
        schedule is way out of line for a shareware product of this size,
        although possibly consistent with commercial guidelines, etc.

        The author claims that he came to this unfortunate decision
        because of the greedy actions of a few specific individuals, most
        of whom operate commercial BBS systems for profit, etc.
        Additionally, the author has indicated that he violated his own
        policy; he allowed himself to be cajoled into assisting
        individuals who called up his place of business asking for
        technical support without being registered users.  That they
        promised to register and never did is to be expected, since they
        had the nerve to call up while unregistered; to expect otherwise is
        simply bad business practice.

        It would seem that Sydex is "punishing the innocent along with the
        guilty" in this matter, since it means (for most of us) Version
        2.12 is the last version available.  This is unfortunate as newer
        versions partially correct some of these known bugs. It seems
        unreasonable to charge someone a fee when they are part of the
        marketing segment that enhanced your product by reporting the
        problem in the first place! Had there not been a shareware version,
        the bugs wouldn't get reported, except possibly by angry commercial
        customers who expect a higher level of (bug-free) support. 

        (Note: it has been reported that the author is even supporting
        several commercial versions simultaneously.  This likely indicates
        that his commercial customers do not want to monolithically upgrade
        to the latest version due to the fee schedule.  Additionally, it is
        indicated that each release only partially fixes known bugs, i.e.,
        commercial users are working with releases with known problems not
        shared by other commercial users, etc.  This only adds to the
        "overhead" of supporting the program on this basis, etc.)

        It is possible that the author has partially relented on one
        specific issue:  Newer versions include a program called TDCHECK
        which can validate a TELEDISK file without having to write out the
        diskette image to a physical diskette.  It can also display the
        file's built-in comments and format information, etc., and provides
        a nice companion utility to TELEDISK.  Also, it would appear that
        any file that was corrupted will be detected this way, which is
        faster than actually creating a diskette, etc.

        Note: Users troubled by the creation of corrupt 1.44 MB diskette
        images can detect this more readily using TDCHECK, and then make an
        alternate copy without the LHARC-type compression, etc.  (It
        appears that the corrupted file bug only happens when the
        LHARC-type compression is used, so using the zeroes-only
        compression produces a valid diskette image file, etc.)

        Recently copies of TDCHECK have appeared on some typical shareware
        sites.  The version released is known to be different from the one
        shipped with TELEDISK 2.13 (the first commercial version) in spite
        of claims of being the same revision, etc.  Functionality seems the
        same, but the programs cannot pass a binary compare, etc.  In any
        case, it is recommended that creators of RX50 TELEDISK image files
        use TDCHECK and also produce descendent disks which are fully
        compared against the originals on a DEC system that does a complete
        block-for-block compare, etc.

12)  RT11.EXE (et al)

     RT11 is the name of a PD utility that handles RT-11 format RX50
diskettes on MS-DOS.  Diskettes can be formatted and files can be
maintained as either RT-11 diskette files or MS-DOS files.  A nifty
feature is to access an image of the entire diskette which is actually an
MS-DOS file!  The utility is designed to resemble a subset of actually
running RT-11, etc. 

     A similar utility exists for ODS-1 FILES-11 RX50 diskettes, but it is
an obscure shareware program, presumably still under development by its
(ex)soviet authors.  It requires the use of the 800 II program, which is a
shareware TSR program that comes from Italy.  800 is used to allow MS-DOS
the ability to be passed non-standard formatting parameters.  A similar
facility exists in FDFORMAT called FDREAD (or FDR88 for XT-class machines
with only 8086/8088 processors). 

13)  User-written utilities

     There are various user-written utilities expressly for RX50 purposes
in various stages of development.  One such utility is being written for
the express purpose of avoiding dependence on TELEDISK for manipulating
MS-DOS image files of RX50 diskettes.  When completed, it should be able
to support formatting of RX50 with user-selectable stagger and interleave
considerations, as well as the ability to work with uncompressed diskette
image MS-DOS files, etc. (Note: The file format is not compatible with
TELEDISK and will only work with RX50.) Directory considerations will
include the ability to support 12-bit OS/278 diskettes, etc. 

     The modifications to WIMAGE to support non-DOS diskettes will also
provide a similar facility, although not limited to RX50 usage.  However,
this utility will not store layout-specific information.  The user must
still provide the low-level format as intended for best usage.  (WIMAGE
requires pre-formatted disks.)

cjl

[end-of-file]