Delivery-Date: Thu May  3 09:59:39 2012

OK, more topics of interest:

FDFORMAT formatting tool for RX50 enhanced performance diskettes.

RX50 Label files now enumerated and minimally documented.


First a correction to the #0001 mailing:

In the previous edition, I mentioned a machine I have the FD505 combo drive
in.  The exact CPU type was misidentified.  The proper designation is AMD K6-
II-550acz which is a 550 MHz CPU with a 100 MHz buss with a 5.5 multiplier for
this CPU chip.  It is the second fastest CPU in that class. [There is an
obscure "hot rod" version that can run off a 95 MHz buss with a 6.0 multiplier
that achieves 570 MHz performance if you can slow down the buss to 95 MHz. 
However, this is actually a nod to hot-rod modders who overclock their
machines; they have no intention whatsoever to slow the clock down and just
wanted to brag about 600 MHz which might be true for a few minutes before the
machine burned up.  [Unless they use water-cooling.].  I prefer a machine
that actually lasts years instead of minutes!


FDFORMAT formatting tool for RX50 enhanced performance diskettes.

Last time we dealt with the issue of creating STANDARD RX50 diskettes of
correct format with contents determined by the Teledisk process in creating an
image of any specific diskettes.  FDFORMAT affords an opportunity to do better
than that for certain applications.  Optimization techniques apply to
diskettes for use on the DECmates II, III, and III+ depending on the specific
purpose of the diskettes.

1)  All bootable RX50 DECmate diskettes must load in the "slushware" stored in
tracks 78, 79, and 0 [in that order].  [Note:  Hard-disk-based DECmate II and
III+ have a dedicated volume on the hard disk named FIRMWARE that is an exact
copy.  The standard DECmate System Test Diskette has utilities to transfer the
slushware from the diskette to another diskette or the hard disk.]

As some of you may know, I disassembled the contents of the DECmate II ROMs
[Here is a currently working link:

    http://anachronda.homeunix.com:8000/~rivie/decmate/358360.pal

.] [Note:  I give myself a B+ or at most A- on the job, but
remember I didn't have access to any DEC "secret" DECmate II documents that
explained how it worked, just some manuals from the vendor of the chips in the
machine that help to create the terminal emulator.  Much of the machine is NOT
made by DEC which should be no surprise in a world where everything is
outsourced.  From what I gather, many of these same chips are in a real VT-
220.]

The relevance I discovered is that the sectors are read in sequentially which
is doomed to failure to be efficient.  As is the case in all DEC RX products,
it is mandatory to perform a 2:1 interleave.  That sort of design is inherent
in all successful software throughout DEC RX applications.  Yet, this code
[clearly written by a newbie to lots of things, such as 12-bit machines.  See
some of my rant/comments in the source code of how foolish yet functional code
is in there as proof of "bad habits" achieved by prior experience with the
limitations of certain 8-bit micros with feeble addressing modes.  In comments
I have the proper code that should have been used to be PDP-8-specific [and
appropriate considering this is a 12-bit program only for use on the 6120 PDP-
8 on a chip.] does some dreadful things.  The ghastliest is as follows:

The code is generic to reading in the slushware from tracks 78, 79, 0 in that
order [or from the equivalent sequential sectors on the hard disk which is
acceptable] in perfect sector order, literally no [1:1] interleave whatsoever.

However, this leads to the embarrassment of each sector takes an entire
revolution to get to the next one as it is always perfectly wrong.  The full
rotational latency is always guaranteed.  what should be done in two
revolutions takes ten revolutions, and this is for all 30 sectors.  6
revolutions [not counting the unavoidable seek times] has become 30 revolutions
at least.

This excess creating poor throughput might be excusable on a reasonably speed
hard disk, but not on a very slow diskette.

However, this problem can be fixed by using a special variant format that can
be achieved with the FDFORMAT program.  FDFORMAT allows you to specify the
number of tracks, sides and sectors a disk is, the interleave [2:1 would be
appropriate] and the stagger factor [see below]

Thus, the way to fix this is as follows:

a)  FDFORMAT a single-sided 80-track diskette with 10 sectors/track and 2:
1 interleave.

b) FDFORMAT a 78 track diskette at 1:1 interleave.  This leaves tracks 78 and
79 at 2:1 interleave.

c) FDFORMAT a 1 track diskette at 2:1 interleave.  this leaves tracks 1-77 at
1:1 interleave and 78, 79 at 2:1 interleave.

This would be an optimzed diskette for use on any bootable RX50 diskette but
for one thing:  The resultant diskette cannot be read on a DECmate at all!

However, making a Teledisk image of such a diskette creates a file that
Teledisk will write out with the special check for RX50-type format.  The
resulting diskette is perfectly compatible with all DEC RX50 applications and
sector layout optimized for the slushware load.  [This form of optimization
should not be used for non-bootable diskettes where the prevailing software
conventions handle the disks based on standard format; to change that would
only make the diskette access slower.]

Thus, any RX50 diskette known to be bootable on DECmate should be copied to a
diskette created as described above as an alternative to the official [Blank
Diskette] format.  The resultant diskette will behave identically to the
original except that the bootup process will be materially faster.

This form of optimization solves about 90% of the problem.  The additional
nuance is to set the stagger factor.  Staggering refers to pre-biasing the
order sectors on a track are accessed by a predictable factor to account for
where predictably the first reliable sector number that can be read when
seeking to the next track.  On the RX01/02/03 this is known to be exactly 2. 
Thus, on systems [such as RT-11] where the software staggers the sector order,
the diskette can be read/written noticeably faster.

In the case of slushware loading, there is only a single case of stagger
potential improvement:  When done reading track 78 sector 10, the next sector
to be read will be track 79 sector 1.  However, predictably the seek has
occurred causing the next sector to be readable to be something further down
the disk.  Presumably sector 3 or thereabouts.  Thus, this sector will be
delayed by nearly an additional revolution until sectors 3,4,5,6,7,8 and 9 are
traversed before sector 1 is then finally available.  Since the software is
blindly doing straight sequential logical access, it is necessary to stagger
the format to compensate for this additional factor.

I have never checked the best value to use; I would start with a stagger factor
of 2 in FDFORMAT.  Perhaps someone knows if the -11/Professional programmers
documented what stagger factor was used on RX50 to best handle this.  [Note:
RX01 staggering two 128 byte sectors may translate into a stagger factor of 1
on the 512 byte RX50 sectors, but someone should time it if we cannot determine
what was used by these programmers who presumably got some hardware types to
answer their questions.  Back in the day, virtually no software engineer knew
anything about the hardware.  Of course, I never worked for DEC!]  Regardless
of the final value, I doubt if it would be significantly more, thus I assume we
need not test the values of 4 through 9 stagger settings.]

All OS/8-family RX software uses a 2:1 software interleave without
staggering.  Thus, whatever the proper value might be, they never use it.  As
such, there is an opportunity to stagger tracks 1 through 77 to correct for
this.  It is not clear if the optimal value for the the stagger at track 79 to
be identical to the stagger that best serves tracks 1-77 because the slushware
is loaded in 8-bit mode while OS/278 loads in 12-bit mode.  Clearly there is
an optimum number beyond a stagger of 0 that occurs with standard diskettes.

This can more easily be calibrated.  An OS/278 non-system RX51: diskette can
be used to read/write a full-disk's worth of files trying different stagger
factors for tracks 1-77.  [Note:  Non-system diskettes do not use tracks 0,
78, 79.]

Thus, clearly for OS/278-family usage, the final stagger factor should be
applied to tracks 1-77 independently of whether tracks 0, 78 and 79 are dealt
with otherwise.  [And for only OS/278-class applications; this includes
various games disks, source file disks, and COS-310 disks, and eventually
bootable P?S/8 RX50 diskettes.]  All other systems presumably handle the
sectors on tracks 1 through 77 reasonably well; in those cases changing the
stagger is not welcome or advised.

I maintain an archive on sunsite/ibiblio of .TD0 files for about 40-odd DECmate
disks [complete with text labels that are faithful to the DEC original.  These
are just the text and not graphics labels. [ No scanning equipment available
back in the early '80's].  Other than an OS/278 working copy [which has
stagger and interleave somewhat unknown] all of the disks are standard RX50.

A useful project for someone who can support these disks would be to a)
determine the optimizations for first all bootable disks and then all OS/278-
format-type disks regardless of bootability and develop the appropriate blank
diskette templates [also in Teledisk format] and then apply the optimization by
copying the appropriate diskettes to the appropriate optimized diskettes and
then post replacing the archive files with optimized descendents.  [There is
no purpose served archiving "pure" originals because if anyone wants to return
the relevant disks to their pessimized forms for some misguided purpose, they
are welcome to do so by copying the optimized diskettes' contents over a
standard RX50 based on the official blank diskette [which is part of the
collection.  Other than wanting to reinvent wheels to see how the optimization
works, I see no other purpose served.]  [That said, these images are so small
by today's standards, we could afford to support both variants.]

I believe FDFORMAT is available in many Internet places.  I certainly have my
own copy, including the WIMAGE program which is useful for creating diskette
images of PC-standard diskettes.  WIMAGE is a small DOS utility that can run
under just about any DOS or Windows system.  It can be used to transmit such
as bootable MS-DOS diskettes to allow all of these programs to run on otherwise
appropriate hardware.  Get back to me if you cannot readily find it.  The
original German author seems to have disappeared, but the package is provided
in source and executable form all in one .zip file.


RX50 Label files now enumerated and minimally documented.

Attached to this mailing is a UTF-8 .txt file that lists and documents all of
the label files in the RX50 archive.  This is in part a stop-gap because the
documentation from some others is not quite correct and apparently has lead to
some minor but needless problems.

Of particular note is that some of these disks require hardware past the basic
machines:

1) Hard disks - Some of these are hard-disk specific such as Master Menu or
hard disk volumes in MM format meant to be restored by MM onto the hard disk. 
OS/278 as a series of MM restore disks certainly is not readable by OS/278,
since MM backup/restore format is totally proprietary to MM.

2)  Some diskettes only work in CP/M-80, thus an APU or DECmate II XPU option
board is a hardware prerequisite.  Some of the diskettes are CP/M-80
applications.  Some are CP/M-80 install diskettes.  Some are the same sort of
thing, except for DECmate XPU MS-DOS.

3) A small few require the optional graphics board associated with the machine
series.

[In fact, for the APU and graphics boards, DM II is totally different from but
parallel to the DM III series.]

However, no additional hardware is required to read/write or copy any of these
disks.

Some of the diskettes are installation diskettes, perhaps to generate
additional diskettes.  If any of them are meant to be bootable, optimized
blank diskettes should be used, at least on the final working copy.

[A notable anomaly:  The CP/M-80 installation diskette can create a bootable
diskette with a standard complement of files; it is itself a bootable diskette
with many additional files that have no purpose being on a working copy
bootable diskette.  Due to some unknown quirk, any CP/M-80 bootable [even a
hard disk volume] created on a machine with an APU disk won't work on an XPU
machine and vice-versa.  Yet, the installation diskette can boot to either. 
Since generally this diskette is not expected to be booted up very often
[unlike the descendent working copies] it is arguable that it doesn't need to
be copied to an optimized format as much as the descendent disk or any other
diskette expected to be booted much more often.]

In any case, any commentary on the .txt file is welcome.  The remarks are
terse as most diskettes should be self-evident as to their intended purpose.

[Note: The attached file requires UTF-8 support beyond merely being a .txt
file.  It should make sense in most Windows-based editors such as NotePad.

cjl [no index files yet; too few editions at this time]

--
"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992