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]