🚀 go-pugleaf

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

cjl