================================ DEC Professional Computer Frequently Asked Questions and Miscellaneous Trivia ================================ Currently maintained by: Michael Umbricht mikeu@osfn.org Originally compiled and edited by: Chaim Dworkin chaim@linc.cis.upenn.edu ------------------------------------------------------------------------------ Vol. 4 No. 1 Part II Size:786 lines; 41006 bytes 18-SEP-2002 ------------------------------------------------------------------------------ This is Part 2 of a 4 part post. This "FAQ and other miscellaneous trivia" is compiled from discussions which took place on comp.sys.dec.micro over the past 7 years. Whenever possible names and addresses of contributing individuals are placed after each answer. Additions, corrections, and constructive comments are welcomed. Summary of questions in Part II: Q11. How do I format a generic floppy on a PRO? Q12. Can I format an RX50 on my MSDOS computer? Q13. Is there a way to copy RX50s on an MSDOS computer? Q14. Is an RX50 equivalent to a low density or high density generic floppy? ************************** Q11. How do I format a generic floppy on a PRO? You don't. DEC, in it's wisdom, decided to take advantage of a captive audience and get rich off selling preformatted disks to Pro owners. They built a machine incapable of formatting disks. You'd think that would leave an opening for some enterprising hacker to write a formatter. However, I've been told the drive controller chips on earlier models of Pro are totally incapable of formatting. But there is an out.... You can format a generic disk on a Rainbow using the /I option to the FORMAT command. Some people, with lots of Pro's, bought a Rainbow JUST to make disks. Of course, nowadays, a copy of Media Master from Intersecting Concepts will do the job on any AT clone... Chaim Dworkin chaim@linc.cis.upenn.edu David Lesher wb8foz@ibiza.cs.miami.edu But this may not even be the best way to go about it, and it costs money besides. The sections below address this issue! There was a firmware update for the PRO's RX50 diskette controller that allowed it to format its own floppies, but it was never released to customers. The FORMAT command under P/OS 3.2 is all set up to format the floppies if it finds the right version of firmware in the controller card. I have tried since the Fall '91 DECUS Symposium to reach the old manager of the PRO development group in Digital to see if he would be willing to release that firmware through the DECUS Library, but he never responded to my e-mail and I haven't been able to obtain his telephone number; all I have is his name and e-mail address. The PRO's floppy disk interface has a Western Digital chip on it which is fully capable of formatting, but a microprocessor (Intel 8041? if I remember right) sits between the WD chip and the bus, and only the repertoire of commands provided by this uP chip are passed through to the WD chip. DEC's [unforgiveable] decision to not allow the PRO to format its own diskettes was based first on repeatability problems with the "A" version of the RX50 drive; but even after those problems were ironed out, the marketeers at DEC appear to have fixated on the meager $$$ they would make from selling RX50 media (HAH!). So...PRO users of the world (if there are any of you left out there) UNITE! Let's see if we can brainstorm an effective way to coax Digital into releasing the new firmware for the RX50 controller. If I could just get my hands on one set of the ROM(s), I would arrange to have them duplicated and make them available at cost to anyone else in the world wanting the ability to format their own diskettes. Note that this is likely a prototype, and is more likely an 8751 than an 8051. An 8751 can be read/blasted just like an EPROM, so if one copy can be procured, it most certainly can be duplicated! Kurt Wampler wampler@MicroUnity.com Charles Lasner lasner@watsun.cc.columbia.edu ************************** Q12. Can I format an RX50 on my MSDOS computer? There are some software packages available which proport to allow formatting of RX50s on MSDOS 5 1/4" high density drives. Here is a short review of three of those packages. Please note that this review is meant for all DECmate/Rainbow/PRO users, so some of the info is not directly of use to PRO people, but in the interests of all RX50 users, it is provided with all of the relevant details, since we are talking about RX50 support of DEC machines using PC's, etc. I have been playing with 22DSK138.ZIP and RAIND112.ZIP and FDFORM18.ZIP long enough to give some additional info regarding Rainbow/DECmate RX50 formatting and related issues. FDFORMAT 1.8 There are some problems with the current release that have always been in at least the two previous versions when attempting to format RX50 diskettes. You use the command: FDFORMAT A: /Y:2 /T:80 /N:10 /H:1 to format for RX50. The /Y:2 is to force a two-sector stagger per track to speed up transfer on all systems except -11/pro. /H:1 means a one-sided disk. /N:10 for 10 sectors and /T:80 for 80 tracks. The resultant disks are marginal, especially to revision A and B RX50 drives. Symptoms include data CRC errors right out of the formatter when test reading the diskettes, and the inability to write data that won't read back with data CRC errors. The problems worsen with higher track numbers, but often start right at track 0 or 1. Using MD1DD media instead of MD2D makes a more reliable disk, so this was assumed to be the problem. This has been confirmed as incorrect. There are several bugs in FDFORMAT that directly affect RX50's: If the floppy is already formatted without error for all 80 tracks, then FDFORMAT will merely verify readibility on every sector. Then the directory info is written by ordinary writing (not formatting) means as previously discussed. (Meaning suitable only as a strange variant of PC-DOS-specific MS-DOS, not DECmate/Rainbow MS-DOS. You then use RX50INIT or move to the DECmate or Rainbow and use the FORMAT command or whatever.) Thus, all that FDFORMAT has done at this point is to verify that a previously formatted disk is indeed readable. What this means is that if a diskette is already low-level formatted, FDFORMAT will reliably determine that it can read the disk completely. Since the status line always shows a "V" for Verify in this case, you can be certain that the diskette is readable. However, no attempt is being made to confirm that the stagger/slide and interleave factors match the command line values! Thus, you still don't precisely know what the diskette looks like! If FDFORMAT gets even a single error for any reason, it will change over to an actual low-level format mode. This is noticeable in that it runs much faster. And the status line will revert to the "F" for Formatting followed by "V" for Verifying, which actually goes faster than the reliable verify-reading, because it turns out that the verify read after the format is in fact flaky, and often misinterprets returned errors! In fact, FDFORMAT can be fooled into believing it correctly formatted *and verified* a damaged diskette readable nowhere! Smarter formatters will deal with the very real errors, but FDFORMAT gets fooled! The resultant diskette is the unreliable type described above. Using the /U switch will force this to happen as well, but is a normal feature of this switch. Also using the /W switch to rewrite the prior contents of the sector also works, but since the sectors are reformatted, the same problem results. The /Q "quick" format works fine, since this isn't really a format, rather a directory initialization. Thus, to determine if the diskette is usable, another program has to read the diskette after the fact. FDFORMAT itself can be used, since it will always attempt (unless /U is invoked) to do the "quick" format (which is actually slower!) and you can observe that only "V" for Verify appears throughout the verifying, etc. Alternatively, the diskette can be verified with the Norton DT program or the analogous CHKDSK /M feature that is unique to DR-DOS 5.0 (alas, dropped in 6.0 :-(, but can be lifted from there and run under 6.0 if desired :-).) to confirm that it's actually readable using either FDFORMAT's default MS-DOS layout which differs from DEC's RX50 MS-DOS allocation, or alternatively, use RX50INIT with RAINDOS, or use the DOS 5.0 or DR-DOS 6.0 FORMAT command through RAINDOS and specify the /Q for Quick option which will just init the directory for DEC MS-DOS purposes, thus allowing DT or DR-DOS 5.0's CHKDSK /M to check out the disk as an actual DEC MS-DOS RX50 diskette. Either way will ensure the disk is readable; the latter has the advantage that bad spots will be marked in the MS-DOS directory should this be the intended usage, and CHKDSK can confirm this was accomplished either way (indication of bad sectors, etc. of CHKDSK's report). In any case, if the disks are being prepared on a PC for the purposes of being brought to a DEC system, it is desirable to check the reliability of the media and the PC's drive while still at the PC end where it can still be dealt with, as opposed to being at the DEC system end and being stuck with bad media, or worse, unreadable copies of programs! One good thing FDFORMAT is good for is to weed out bad floppy drives for the RX50-oriented purposes: A PC-specific usage of FDFORMAT is to create disks that actually achieve 1.48 MBytes on a HD 5.25" diskette normally formatted to 1.2 MBytes. This can be accomplished using the command: FDFORMAT A: /Y:2 /T:82 /N:18 /U A brief explanation of this command is that it achieves a 2:1 interleave diskette where the unreferenced sectors of the other half of the interleave are used to replace a portion of the gaps normally provided to allow 1:1 interleave usage to successfully find the next sector. In 2:1 this is obviated, so the space can be given back to allowing more sectors. If the drive is truly up to snuff, 18 sectors can fit instead of the normal 15. The /Y:2 parameter has the usual meaning. 82 tracks are usually available on such a disk as well, so that the 5.25" diskette now holds slightly more than the usual capacity of a 3.5" HD diskette! (However, the same technique ups the 3.5" diskette's capacity to 1.72 MBytes!) If the drive can't handle this format, it likely can't properly format RX50 media either, since both formats depend on minimal drive speed jitter to work. (RX50 specs are actually tighter than IBM's original DD drives, since they only had originally 8, then 9 sectors, while DEC uses 10. However, most good drives are up to the task, so you can "weed out" the junky drives with FDFORMAT this way, etc.) Note that this usage requires HD diskettes, as opposed to the RX50's requirement of DD-type media! An additional problem with the usage described above is that even though the /Y:2 option was given, it is ignored. The unreliable disk, when actually formatted, does apply the /Y:2 option to the new disk format, so the stagger is now present, but FDFORMAT attempts to merely verify the format in this usage to avoid formatting. The stagger/slide factor is not checked for, and can be any value. The disk will not be reformatted merely because it was a different stagger; of course if an error occurs it will be reformatted with the designated value. Yes, to ensure a stagger/slide and/or interleave factor being as desired, the diskette must actually get formatted. /Q prevents this, and /U ensures it and leaving either out leaves it to chance, but since FDFORMAT can misinterpret certain I/O errors, it tends to err on the side of just reading the diskette, which means that it likely never verifies the stagger/slide or interleave, just the basic readability, etc. So, FDFORMAT as currently released is of no useful value to any RX50 user, since the reliability suffers so terribly. However, if used intelligently as a prototype disk creator, and then passed through TELEDISK, the resultant disks are superior. Note that FDFORMAT can be used to make "pre-master" diskettes for TELEDISK's usage, and then TELEDISK makes all subsequent usable RX50 media, etc. Additionally, some users report problems getting the FDREAD/FDR88 programs to load properly, preventing FDFORMAT's use entirely (except for "vanilla" PC formats). This also affects the ability to create the extended-capacity HD diskettes which may be useful in and of themselves, but also allows some confidence checking on the drive's condition, so it is an important subject. FDR88 for XT's, and FDREAD for all 286 and up machines can have problems getting loaded if these programs misinterpret the size of available memory, especially in the case of upper-memory and high-memory area systems. It does occasionally get it right, but in some cases, the galling message: "TOO MUCH MEMORY" appears, and cannot be cleared, even following the documentation to try loading the program multiple times. (Actually, the documentation merely says to try a second load attempt. In fact, in certain systems, it might work after as many as 20 attempts to load it, each one wasting a small amount of memory.) The solution may well be to run a "bare-bones" system, such as a bootable floppy DOS system which lacks the memory juggling frills. This is still a viable environment for FDFORMAT, and all necessary files can easily fit on a bootable HD diskette. FDFORMAT allows a pause between execution invocation and formatting the diskette, so you can take out the system disk and replace with the disk to be formatted, etc. The problems definitely come about when using MS-DOS or DR-DOS version 5 and up. Sometimes it is possible to shell out of another program and then run FDREAD in the now smaller memory space, etc. Experimentation is desirable here! Hopefully, the author can be contacted for fixes to this otherwise useful program. In spite of all of its problems, FDFORMAT still gets you viable master diskettes for variant formats that improve performance on many O/S's as found on RX50's on various machines. All MS-DOS formats can get a performance boost using some aspect of FDFORMAT, and if there is an MS-DOS board for the PRO, this issue certainly applies there. Also certain CP/M layouts can definitely benefit. Admittedly most mainstream PRO usage is for the standard layout where the drivers map the disk sectors instead of having a hardware sector reordering, thus any standard formatter is sufficient in those particular cases, but for all of the myriad variants out there, FDFORMAT (coupled with TELEDISK) is invaluable. There is one additional use of FDFORMAT: If the O/S is MS-DOS V 4.01 or older, there is no provision in the FORMAT command to override the current format on the diskette. Often you can get into a situation where FORMAT will not change the (incorrect and possibly only partial) format on the media which is in conflict with what you are attempting, etc. Since FDFORMAT always supports the /Q and /U switches in the same manner as the newer DOS versions, it can undo these problems should they occur, etc. 22DSK138 This is a useful package for converting many CP/M formats to/from MS-DOS. The DECmate and Rainbow are directly supported and can be set as the default CP/M types. The program can be configured for use with the TEAC FD-55F drives which are essentially two-sided RX50 types. (FD-55GFV and GFR can be configured as FD-55F equivalent.) The program can run on an XT configured with HD or FD-55F drives as well. Note that FD-55F doesn't require a 3-speed floppy controller, thus any XT can have an FD-55F added on if necessary. 22DISK also formats the CP/M disks it handles, so RX50's can be formatted directly. As a high-level consequence, a CP/M directory initialization is also performed. The resulting disk is usable anywhere an RX50 can go, and is quite reliable. Note that there are no formatting options as in FDFORMAT, just a standard low-level-format RX50. But a reliable standard format is better than an unreliable "better" format. So, this is a recommended way to format RX50 on a PC. Again, only if the application is for a standard format RX50, which isn't always the case. 22DISK will note errors while formatting though, and is an invaluable tool for weeding out flaky media, etc. even if ultimately non-standard sector layout is needed later, etc. RAINDOS 1.12 For MS-DOS DECmate and Rainbow users, there is an alternate route: RAINDOS is a device driver from the same vendor as 22DISK, and apparently incorporates the same low-level disk support. Unlike RX50DRVR, RAINDOS can work correctly with CHKDSK and most importantly DOS's FORMAT command. You still get a standard low-level RX50, but the resultant DOS structure is entirely compatible with DECmate and Rainbow MS-DOS, so programs like RX50INIT aren't required. Further, since DOS's FORMAT command was used, any actual errors will be incorporated into the FAT structure, so diskettes with bad spots can be used. (RX50INIT does a no-check perfect directory initialize. FDFORMAT does check for errors, but records them in the incompatible PC-like DOS structure that has to be replaced for DEC compatibility, so you have to observe that FDFORMAT found no errors, and must reject disks with errors.) The manual claims there is the same FD-55F support as in 22DISK. RAINDOS has several problems: It doesn't work under DR DOS. All but the FORMAT command actually does work there, but attempts to format a diskette terminate with the error message "Drive already locked to another program". To clarify this issue: If a FORMAT command actually causes a low-level format to be attempted, and the O/S is DR-DOS 6.0, the command will fail with the above noted error message. If the FORMAT command merely does a "quick" format, either due to FORMAT's guesswork or the /Q switch, then the disk is merely initialized and not formatted (a "high-level" format always occurs, but a "low-level" format will not under these circumstances.) It doesn't work with DOS 4 and 5 booted to the A: floppy which is also the drive used by RAINDOS for its RX50 operations, unless DOS is used exclusively on 360K diskettes. As with other floppy-based systems, there are times when you get a message like "mount a diskette containing \COMMAND.COM in drive A: and press ENTER". This is perfectly normal for this limited environment. The problem is that if you have HD drives, (most machines have HD A: drives), then you would prefer to read HD diskettes on them. Once booted up and in the mentioned situation, all further attempts at using an HD floppy yield a GENERAL FAILURE error message that will not clear. You can mount a low-density floppy to get COMMAND.COM reloaded, but all further access to the A: drive disallows HD diskettes. For hard-disk DOS 4 and 5 users, none of this is a problem in general, but since I use DR DOS 6, I had to boot a DOS 4 or 5 floppy :-(. There additionally seems to be some speed/timing related problems with RAINDOS in that certain file transfers take inexplicably long times to read or write. The longer the file, the more likely the problem is. Also, when RAINDOS is loaded, the FORMAT command for normal DOS formatting may take inordinately long, often accompanied by extraneous seeks/recalibrates between track formats, although totally harmless otherwise; the resultant diskettes are formatted correctly. Overall, if the goal is merely to format RX50 media, 22DISK is the best route since it runs under any PC-based DOS system. For many users, RAINDOS is even better, but clearly not for all users. When/if FDFORMAT gets fixed, it will be a better way through that portion of the problem. BTW, RX50DRVR, while not able to format, does run under DR DOS 6, as does RX50INIT. RX50INIT cannot run under DOS 4 and DOS 5. RX50DRVR has some quirky problems partially avoidable there as well. There is also word that RX50DRVR is being upgraded to support formatting and DOS 4 and 5's CHKDSK. It currently can be used with DR DOS's CHKDSK as well as DOS 3.x. Apparently, RX50 support is hardly a "static" issue :-). Here's another possibility: There is a shareware product from Italy called 800. I think the viable current version may be called 800II standing for 800 version 2 in Roman numeral notation. This program essentially is an alternative to the FDREAD portion of FDFORMAT and allows the MS-DOS 5.0 and DR-DOS 6.0 FORMAT command to specify parameters that otherwise could not be performed. For example, it is possible after the 800 TSR is loaded, to invoke the DR-DOS 6.0 FORMAT command: FORMAT A: /T:80 /N:10 This will create an RX50 format diskette with one difference: it is double- sided. Due to limitations of the FORMAT command itself, the /1 option is not allowed for any format other than the /4 format. (I.e., to make a single sided 160K or 180K diskette from what would otherwise be a 320K or 360K diskette.) Such a diskette can then be used with any of the high-level formats to make it RX50 MS-DOS compatible, or merely tested for viability before being passed over to an RX50-based DEC system. The only interesting aspect is that it could report errors on the other side of the disk, i.e., the side ignored by the RX50! Further testing is required to determine if 800 can interact favorably with FDFORMAT in lieu of FDREAD/FDR88. In any case, 800 has no problems getting loaded by MS-DOS 5 or DR-DOS 6, and reacts favorably to systems with high or upper memory enabled, etc. Of course since it is primarily for use with the DOS FORMAT command, the non-standard parameters do not get passed through to 800, even though the ability to do so is present. There exists a package available from the (ex-)Soviet Union as shareware, that can format and exchange files between MS-DOS and ODS-1 RSX PRO/-11 RX50 diskettes which is ideal for PRO's. This package runs under MS-DOS or DR-DOS, and requires 800, etc. -- Charles Lasner lasner@watsun.cc.columbia.edu ************************** Q13. Is there a way to copy RX50s on an MSDOS computer? I have down-loaded Sydex's teledisk, and have found it to exceed my expectations in some useful ways. For starters, all of my attentions are based on the problems of distributing RX50 diskettes not necessarily in stock format, and not yet having any satisfactory way of creating the necessary disks. Background: There are several desirable variant formats for RX50 that have been discussed elsewhere. The only known program to create them is FDFORMAT for PC's. While this freeware program is generally quite good, it has a few crucial bugs that make it unsuitable for RX50 usage. It is conceivable that this will be solved by using some additional/non-standard parameters to FDFORMAT to create usable disks, but in any case, the use of all obvious parameters yields disks that are flakey on some RX50's, and downright unreadable on others. In addition, these disks are so messed up that a DECmate can't even WRITE on the disks and read back what it just wrote reliably! Yet, this isn't a media problem because it can be demonstrated that the problem disappears by low-level format of the same diskette with either Sydex's RAINDOS or 22DISK packages. (Note that *some* RX50 systems using some newer-designed controllers and/or higher revision drives and/or RX50-compatibility modes on different drives have little or no problems with these FDFORMATted diskettes; indeed the diskettes are fine on a PC; there's some low-level detail that's incorrect about FDFORMATted diskettes. Some parameter is being set to a PC-acceptable value that doesn't center on RX50's requirements. Perhaps this will be uncovered at a later time obviating this entire discussion. Until such a time, FDFORMAT cannot be used to create RX50 diskettes that are readable on *all* RX50 systems. FDFORMAT also has a few other operational bugs, such as incorrect recognition of certain I/O errors, etc., but these are exception cases, and for all other PC purposes, it serves quite admirably.) The reason why FDFORMAT is desirable is that it is the only known program capable of creating the variant RX50 formats where the format must be done with interleave and stagger factors, especially if the disk must have "zones" where the format changes. For example, to create a disk best suited for DECmate OS/278 usage, the following *TWO* commands should be given: FDFORMAT A: /T:80 /N:10 /1 /Y:2 /I:2 FDFORMAT A: /T:78 /N:10 /1 /Y:2 The first command creates a disk with an interleave of 2:1 and a stagger of 2 throughout. The second command changes tracks 0-77 to have 1:1 interleave and a stagger of 2 throughout. When OS/278 is copied onto such a diskette, the "slushware" tracks are read in much faster than on standard RX50 diskettes, and all access to the rest of the diskette is speeded somewhat because of the stagger factor which overcomes the software's lack of stagger mapping. But since the software does map the sector order into a 2:1 interleave, the hardware order must stay in 1:1 interleave sequence. This would be a nice disk to use for the intended purpose, but many DECmates will be unable to read this diskette. Literally, it will get a CRC error on *every* sector! Furthermore, if you attempt to write an image of the software onto this diskette, it will get a CRC error on *every* sector even though it just wrote the disk out! Enter Teledisk to the rescue! When I read Teledisk's documentation, I had doubts that it could solve this problem, because I noticed it could be quite "smart", perhaps *too* smart! It claims that it can get around certain copy-protection methods by virtue of how it operates, so I figured that it would likely copy the problems of FDFORMAT as well :-(. Or, alternatively, it might guess that the diskette was an RX50 and proceed to format it in a stock manner, thus destroying the optimization applied by using the two FDFORMAT commands instead of just using RAINDOS or 22DISK to create stock low-level RX50 diskettes. Well, I was wrong on both counts! Teledisk understands how to maintain sector order, and pointed out the change of interleave from 1:1 to 2:1 at track 78, so that problem is hurdled. Teledisk understands that these sectors should be formatted with apparently the same parameters as the formatting routines in 22DISK and RAINDOS, so the resultant disk *is* readable on DECmates! Of course, this is *not* an "exact" copy, but rather it is a "better" copy. Apparently Teledisk only writes sectors in a "sane" format, and the copy-protection they refer to is the class of "funny" sector ordering, size, or count, not any lower-level details. Apparently the Sydex code at work in RAINDOS and 22DISK is also within Teledisk, thus since Teledisk recognizes the disk as a 10-sector/track 512 bytes/sector disk, it writes it as would RAINDOS, etc., except Teledisk is sensitive to sector ordering unlike the other Sydex programs, etc. Thus, the descendent disk is actually *better* than the original. I can now therefore distribute diskettes in the intended format for working-copy usage of the best effort of each diskette :-). Additionally, if I modify distribution diskettes to be in their intended format instead of their original stock format (virtually all diskettes that need to be distributed are in stock RX50 format, because the need to create optimal diskette layout is generally newer than the software; indeed, this entire effort is to distribute software that performs *better* than the original!), then the master disks should be copied with Teledisk to create perfect copies in one step. There are additional advantages: Teledisk can also create an MS-DOS file that is the image of the diskette in either a rudimentary-compressed or advanced-compressed form. These files can be transmitted down the net and then reconstructed on PC-AT's for use on RX50 targets. Since they are compressed, this minimizes the overhead as well, etc. So, Teledisk has made my day :-). However, all clouds have dark sides as well :-( : Teledisk has some problems, some of which are "political" in nature. There is a known limitation of TELEDISK in that when you invoke the built-in compression feature, which is apparently "liberally borrowed" from the PD LHARC program, it runs quite slow, but admittedly creates smaller MS-DOS files for the effort. However, if the extra compression is disabled, the MS-DOS file is only subject to run-length compression of zero bytes, and the resultant file can then be compressed by better means, such as PKZIP which is often faster in the compression and decompression, which means that uncompressed files can be used to speed up TELEDISK's operations, and occasionally the PKZIP archive file is somewhat smaller (or somewhat larger, it varies!) than the LHARC-type file format used by TELEDISK when compression is enabled. Although I would therefore recommend disabling the compression, the program tends to promote the use of the compression, etc. There is a known bug in the compression routine that will occasionally show up as an incorrect file that is worthless! So far, only 1.44 MByte 3.5" HD diskette image files have been found to show this problem, and only occasionally. As distributed as shareware (last shareware version I believe is 2.12) the only way to confirm this is to attempt to make a descendent floppy, and notice that it craps out in the middle. The author has acknowledged this weakness as of this 2.12 version, and apparently at least an additional newer version that he won't make available as shareware, even though this version, and perhaps some even newer versions only add on attempts at bug fixes. (Clearly there is at least one newer non-shareware version superseded by at least yet another non-shareware version, and the former's only purpose is to defectively attempt to overcome the problem in the shareware version, and the latter is a fix to that fix, etc. Relative to this problem, there are no other features to the newer versions, and perhaps there are no other features at all!) Apparently the author is having some business problems with some unscrupulous commercial BBS operators who have apparently violated the shareware license by having a blatant amount of downloadable files in TELEDISK format, yet haven't paid for a shareware license, etc. The author contends that the only way these operators can have so many TELEDISK files is that they are violating the terms of the shareware, etc. While all of this may even be true, Internet users who have no commercial interest in Teledisk are now being "punished" along with the "guilty" since the shareware author has decided to no longer support newer versions on Teledisk as shareware! Instead, all users are required to purchase a "site license" regardless of status, etc. Thus, it is necessary to pay a high (compared to shareware rates) price for the next version, even though it is of dubious worth over the last shareware version, at least in regard to RX50-related matters specifically. It is conceivable that someone able to justify the site license could report to us whether the problems we must concern ourselves with have been remedied in a newer version, etc. Additionally, as of Version 2.13, an additional utility has appeared called TDCHECK. The TDCHECK program can check the viability of a Teledisk file to determine if the file isn't corrupted (whether caused by Teledisk itself or not!) and is faster than using Teledisk to create a target disk which then has to be verified as a copy of the original, etc. Of course, you need to purchase a site license to obtain this utility as it's a portion of the first "commercial" release, etc. On the brighter side, the shareware author may have relented somewhat, because I have found a copy of the TDCHECK program on many of the common Internet resource sites (SIMTEL20, etc.) seemingly unbundled from any Teledisk release of Version 2.13 or higher, etc. This TDCHECK program doesn't solve the problem of corrupted operation, it merely confirms that the problem has/has not occurred allowing you an easier work-around, i.e., definitely to not enable the compression. Since the recommendation is to disable the compression and use an external utility for that purpose, this really shouldn't pose any actual problems, and I again want to emphasize that no RX50 images have ever been discovered to be self-corrupted by Teledisk V 2.12, just 3.5" HD diskettes. However, there is yet another problem with Teledisk, at least as of V 2.12: Teledisk attempts to read a diskette which might be highly non-standard, and it reports all points of change in the format of a disk as they occur, such as when the interleave changes, etc. As a consequence of this, it "tolerates" a lot of format variations and will recreate them in the descendent disk (and in the case of FDFORMAT- created RX50 images, actually better than the original!) However, if the disk is being read marginally, as RX50 diskettes sometimes do, it assumes that the variation is normal, i.e., there will be a report on the screen during the disk reading, copying to an MS-DOS file, of an unwarranted format change from the constant 10 sectors/track RX50 format with some stated interleave, etc. It appears that Teledisk inadequately retries reading a diskette to confirm the difference between a desirable format change or anomaly, and merely an I/O error that would clear up merely by re-reading the track a few times. To get around this, the following recommendation is made: First format a diskette on the PC using the desired interleave and stagger or slide parameters. Take this diskette to the DEC RX50 system and make an image copy of the desired diskette onto this diskette that was formatted on the PC just prior to being written on at the DEC system. Then take the copied diskette back to the PC where it was formatted, and read it into Teledisk. The resulting MS-DOS file will report no format changes during the diskette reading as would the original DEC diskette. This procedure can eliminate about 98% of the problem. If the format change is reported during the diskette read, the diskette is definitely useless, and there is no fix possible. If no format change is reported, the disk is likely trustworthy. Of course the descendent disk can be brought back to the DEC system and compared to the DEC original, as a further "belts and suspenders" approach which should be done on important disks, etc. An additional problem of Teledisk as of at least V 2.12 is that there is an option to make a direct copy from one drive to another without making the intermediate MS-DOS file. This option often doesn't work at all. Avoid the problem by creating the MS-DOS intermediate file, and using Teledisk a second time to create a descendent, etc. (You can always output to a RAM disk and/or delete the file afterwards if desired, etc.) Not related to RX50 per se, but there is another notable Teledisk problem: When 1.72 Mbyte disks are created using FDFORMAT as described above, Teledisk cannot copy them at all! The symptom is that a descendent disk is created and is correctly formatted, but the contents of some portion of the disk (approximately 2/3 of the way into the disk) are a repeat of the contents of lower-numbered tracks. Often the file is self-corrupted as is occasionally the downfall of using Teledisk with 3.5" HD diskettes, but in this particular case, the file is not noted as corrupted with TDCHECK, but rather has plausible contents, just repeating some of the former track data instead of the desired data, but the Teledisk file is in the proper format per se, and the resultant disk's format is correct also. Note that it could be necessary to disable to compression to avoid self-corruption, but the data is still wrong even if the format is correct in that case. In spite of all of these problems, Teledisk does generally work, and works rather well. Hopefully, the shareware author will change his policy regarding the usage by those more suited to being treated as shareware users, not commercial operators, and at that point, the shareware author can enjoy the benefits of having good feedback from his audience! This policy can give the greatest advantage to the author and users alike! Besides Teledisk there is another option. You can retrieve rt11.zip by via anonymous ftp from newton.canterbury.ac.nz, 132.181.40.1, in the pub/local directory. It produces what appears to be a nice RT-11-like environment on a PC for file transfers, etc., but is inferior to Teledisk for the purpose of making a compacted image of an entire disk as a DOS file. Since this is a frill, it can be completely overlooked :-). And yes, it does Format DD-type media to stock RX50 as advertised. This program is written in Turbo Pascal. It would seem that someone who can understand enough TP and the quirky code to call BIOS routines should incorporate some of RT11.PAS into FDFORMAT (also a TP-based item) since the format routine works fine while FDFORMAT does not for RX50 as discussed elsewhere. Overall a nice program. -- Charles Lasner lasner@watsun.cc.columbia.edu ************************** Q14. Is an RX50 equivalent to a low density or high density generic floppy? Just a word about using HD media: You can't reliably use HD media on an actual RX50, because the coercivity is too far off in HD media. It was designed for the higher-frequency recording of the "real" 1.2 Meg format (500 KHz) and not the 250 KHz recording rate of the RX50, which is actually the same as good 'ol DS/DD media (360K kind of media). Some revisions of RX50 drives in combination with certain RX controllers in some DEC machines fare better than others, but it can be demonstrated that a lot of combinations don't particularly "like" HD media. The designated media for RX50 is Maxell MD1DD-RX50 or equivalent, which is what used to be called "quad" media. This is well-honed low-density media, so it is rated for use on 96 TPI (80 track) drives, not just 48 TPI (40 track) drives as is usual. Note that MD2D is not MD2DD. (The 2 just means two-sided which for all intents and purposes today can be ignored; virtually *all* media is actually made double-sided :-).) The DD means 80-track support, but since most media are made well-honed, most cheap disks can support 80 tracks anyway. These disks will *not* cause I/O errors on any RX50! However, long-term usage requires the hub rings be removed completely (use alcohol to get the sticky stuff off, or ask your supplier for no-hub disks!). Failing to remove hub rings means eventually the disks will get unreliable sooner than they ought to due to registration problems. All 96 TPI disks have this problem. Note that MD2HD and MD1DD don't have hub rings! It is rumored that there is a "premium" line of diskettes from Fuji apart from their standard line of inexpensive diskettes that has a specially reinforced hub area, that isn't a hub ring per se. If the same mechanism is used in both HD and DD media, then the DD type would be the best thing today to use with impunity for RX50. Clearly the MD1DD or MD2DD or MD1DD or the 3M equivalents are too expensive, considering that what we want are the cheapest types of diskettes with the hub rings never added. (We don't want to pay more for less!) An issue over hub rings: While it is desirable to find media without hub rings, and yet be DD media, it is usually the case that DD and hub rings go together, i.e., if there are no hub rings, the media is likely to be HD. To confirm that the media is indeed DD, the following test will generally work: Attempt to format a suspect disk as a normal 1.2 Meg HD diskette. If there are hundreds of kilobytes in bad sectors, then it's likely a DD-type diskette unsuitable for HD usage and therefore suitable for DD usage. If the diskette gets either no errors or few errors (under 200K in bad sectors) then it's some form of HD diskette and shouldn't be attempted for RX50 usage. It may appear OK on the PC, but it won't work reliably on (most) real RX50 systems! -- Charles Lasner lasner@watsun.cc.columbia.edu ************************** End of part II: DEC Professional Computer FAQ.