+ $BRX:brxDOC.TXT$ V01.30 29-OCT-98 Michael M. Iloff + e-mail 100021.2047@CompuServe.com Software Product Description -------------------------------------------------------------------- + PRODUCT NAME: EbrxDOSF, Version V15.26[A] MS-DOS <=> RT-11 File Converter 1. EDESCRIPTIONF As a replacement for cumbersome network or KERMIT installations, this utility - operating on a BAYDEL BRX50 floppy disk Q-bus controller - provides a comfortable offline link - between RT-11, TSX-Plus and SHAREplus on the one hand and the huge world of IBM PC, XT, AT, PS/2 and ATARI ST machines on the other hand - through the use of the appropriate floppy disk as a connecting media. ECONTENTSF 1. EDESCRIPTIONF 2. EFEATURESF 2.1 Eknown disksF 2.1.1 EMINI-disks F(5.25") 2.1.2 EMICRO-disks F(3.5") .1 EMS-DOS F .2 EATARI ST F 2.2 Efunction menuF 2.3 Eserviceable devices and filesF 2.3.1 ERT-11F .1 EfilesF .2 EdevicesF .2.1 Erandom access F(except magtape) .2.2 Esequential access F .2.2.1 EinputF .2.2.2 EoutputF 2.3.2 EMS-DOSF .1 EfilesF under functions .1.1 that Emodify the directory F .1.2 that Edo not modify the directory F .2 Edisks F 2.4 EwildcardF 2.4.1 EMS-DOSF .1 Efilenames F .1.1 Eoutput F .1.2 Einput F .1.2.1 Ejoker "?"F .1.2.2 Easterisk "*"F .2 Epathnames F 2.4.2 ERT-11 F .1 Eoutput filesF .2 Einput filesF .2.1 Ejoker "%"F .2.2 Easterisk "*"F 2.5 EMS-DOS directory operationsF 2.5.1 EentriesF 2.5.2 EspecificationsF .1 Evolume labelF .2 EfilenamesF .2.1 from EMS-DOS to RT-11 F .2.2 from ERT-11 to MS-DOS F .3 Ecreation date and timeF .3.1 EdisplayF .3.2 EtransferF .3.2.1 EMS-DOS to RT-11F .3.2.2 ERT-11 to MS-DOSF .4 EattributesF .4.1 EdisplayF .4.1.1 Eread onlyF .4.1.2 EhiddenF .4.1.3 EarchiveF .4.1.4 EsystemF .4.2 EusageF .4.2.1 Eread onlyF .4.2.2 EhiddenF .4.2.3 EarchiveF .4.2.4 EsystemF .4.3 EmodificationF .4.3.1 Esingle fileF .4.3.2 Emultiple filesF .1 E1st modificationF .2 Elater modificationsF .5 ElengthF .5.1 EFrom MS-DOS to RT-11F .5.2 EFrom RT-11 to MS-DOSF 3. EHARDWARE REQUIREDF 3.1 Efloppy controllerF 3.2 Efloppy drivesF 3.3 ECPUF 3.4 Econsole terminalF 4. ESOFTWARE REQUIREDF 4.1 Eoperating systemF 4.1.1 ERT-11F 4.1.2 ETSX-PlusF 4.1.3 ESHAREplusF 4.1.4 Emulti-user systems and RT-11 V5.2 through V5.3F 4.2 ERT-11 monitorsF 4.3 Edevice handlerF 4.3.1 Eunmapped systemsF 4.3.2 Emapped systemsF .1 ERT-11 XMF .2 ESHAREplusF .3 ETSX-PlusF 5. EINSTALLATIONF 6. EOPERATIONF 6.1 EList MS-DOS directoryF 6.2 EShow MS-DOS media typeF 6.3 ECopy MS-DOS to RT-11 fileF 6.4 EChange MS-DOS file attributesF 6.5 ERename MS-DOS fileF 6.6 EDelete MS-DOS fileF 6.7 ECopy MS-DOS from RT-11 fileF 6.8 EInitialize MS-DOS diskF 6.9 EFormat MS-DOS diskF 7. EHINTS AND KINKSF 8. EORDERING INFORMATIONF 9. ESOFTWARE WARRANTYF 2. EFEATURESF Written in MACRO-11 assembler code, this programm is fast and compact. The numerous data buffers required during operation are allocated and invalidated dynamically in accordance to the current demand, that depends on the specific type of disk currently under treatment. 2.1 Eknown disksF brxDOS determines the MS-DOS media type by means of reading the boot sector with the media descriptor byte in its BIOS parameter block (BPB) or - if not available - by the FAT ID byte inter- pretation. (Yet on ATARI ST disks neither the media descriptor nor the FAT ID byte is reliable, so brxDOS checks additional BPB parameters in order to determine the type of media.) Since the newer versions of MS-DOS insist on evaluating the boot sector for media description, brxDOS writes it during the format procedure onto disk as well. Hence brxDOS can read, write and format at least all MS-DOS, TSX-32, OS/2 or ATARI ST standard disk formats: 2.1.1 EMINI-disks F(5.25") single/double side, double/high density, 40/80 tracks/surface, 8/9/15 sectors/track 2.1.2 EMICRO-disks F(3.5") .1 EMS-DOS F single/double side, double/high~) density, 80 tracks/surface, 8/9/18~) sectors/track .2 EATARI ST F single/double side, double density, 80 tracks/surface, 9 sectors/track 2.2 Efunction menuF The following options are available: <0> Exit to operating system <1> List MS-DOS directory <2> Show MS-DOS media type <3> Copy MS-DOS to RT-11 file <4> Change MS-DOS file attributes <5> Rename MS-DOS file <6> Delete MS-DOS file <7> Copy MS-DOS from RT-11 file <8> Initialize MS-DOS disk <9> Format MS-DOS disk The free demo license brxDEM.SAV neither includes menu options <4>...<9> nor yields permanent RT-11 files through menu option <3>. 2.3 Eserviceable devices and filesF 2.3.1 ERT-11F no legal device or file specification is exempted (except options) .1 EfilesF for input and output .2 EdevicesF for input and output (must not be loaded for/owned by another job): .2.1 Erandom access F(except magtape) .2.2 Esequential access F .2.2.1 EinputF devices that can close a file (e. g. TT:) - at end of file the cluster (under RT-11) respectively the block (under TSX-Plus) remainder is padded with nulls rather than appending a ^Z character .2.2.2 EoutputF (e. g. CL: under TSX-Plus, TT:, LP:, NL: under all supporting systems, SP: under RT-11) 2.3.2 EMS-DOSF .1 EfilesF under functions .1.1 that Emodify the directory F files that are pointed to by a root directory .1.2 that Edo not modify the directory F files that are pointed to by any directory since brxDOS does not cause any subdirectory nesting restriction in excess of MS-DOS itself .2 Edisks F copy back and forth as an image as long as the according RT-11 file matches the size (2 RT-11 blocks for every Kb MS-DOS disk space) 2.4 EwildcardF 2.4.1 EMS-DOSF .1 Efilenames F .1.1 Eoutput F at least a standing alone asterisk "*" is required to avoid an attempt to copy from an RT-11 file to the MS-DOS disk image (explicit wildcard) - missing file name extensions are automatically taken from RT-11 (implicit wildcard) .1.2 Einput F .1.2.1 Ejoker "?"F applicable at any position in "filename.ext" .1.2.2 Easterisk "*"F + It is applicable as a t r a i l i n g character accomplishing + "filename" either/or/and "ext". As soon as an explicit character + appears as trailing to an asterisk in a name or extension field, + this specification will be rejected - unlike MS-DOS itself, which + merely ignores such characters and therefore may cause unexpected + trouble. + - .2 Epathnames F + do not accept wildcard characters nor implicit extension + - 2.4.2 ERT-11 F .1 Eoutput filesF Missing file name extensions are automatically taken from MS-DOS (implicit wildcard). brxDOS attempts to process a trailing asterisk "*" in either or both name or extension field (explicit wildcard) automatically so as to prevent a just closed file from being re-deleted during a bulk copy operation. Yet, in case of MS-DOS file names that are too long for RT-11, a special specs string mapping mechanism provides more security against re-deleting RT-11 output files: If the user terminates both the MS-DOS input file specs field (name or extension) and the appropriate RT-11 output file specs field - both of any legal but zero length - with an asterisk "*" each, brxDOS maps the MS-DOS specs field to the RT-11 specs field. In addition, this mechanism provides a convenient support for squeezing MS-DOS file names to RT-11 name length easily. .2 Einput filesF .2.1 Ejoker "%"F applicable at any position in "filnam.ext" .2.2 Easterisk "*"F applicable as a t r a i l i n g character accomplishing "filnam" either/or/and "ext" 2.5 EMS-DOS directory operationsF 2.5.1 EentriesF + During transfer from RT-11 to MS-DOS, old MS-DOS files with the same name as the RT-11 input file are not automatically pre-deleted from the MS-DOS directory as long as there is still room both in the MS-DOS directory and file allocation table for the new file with the old name. Since this feature preserves the MS-DOS disk structure from physical modification as long as possible, the user may abort his or her copy operation the later. + When deleting particular MS-DOS files either explicitly (through + DELETE) or implicitly (through COPY or RENAME), provision is made to + erase any existing long file name of the Windows95 VFAT file system + automatically too. + 2.5.2 EspecificationsF .1 Evolume labelF may be created or changed-only at any time be means of the "initialize MS-DOS disk" function; in the latter case, it is not + necessarily positioned in the very first directory entry; its + archive bit will be set always + - .2 EfilenamesF .2.1 when passed automatically from EMS-DOS to RT-11:F filenames longer than their RT-11 counterparts or those containing characters that are illegal to RT-11, are screened the most appropriate way under the specific circumstances and displaid in a warning log - entirely illegal strings are replaced by "X" .2.2 when passed automatically from ERT-11 to MS-DOS:F reserved MS-DOS file names or extensions cause a warning log - *.BAD files must be named explicitely .3 Ecreation date and timeF .3.1 EdisplayF + is fixed to the the ISO standard "yyyy-mm-dd-hh-mm" (seconds as an + option) + - .3.2 EtransferF + The creation date will be transferred back and forth. In both MS-DOS + and RT-11 directory entries, years up to 2099 are valid. To achieve + this under RT-11 too, in the RT-11 date entry, bit15,14 are used as + straight extension to the documented year representation in bit4..0. + Therefore, this enhanced data entry is fully backwards compatible to + the plain entries of classic RT-11 directories. + - .3.2.1 EMS-DOS to RT-11F literal transfer of date .3.2.2 ERT-11 to MS-DOSF time of day defaults to noon .4 EattributesF .4.1 EdisplayF .4.1.1 Eread onlyF a trailing "+" is appended to the length .4.1.2 EhiddenF a trailing "-" is appended to the extension .4.1.3 EarchiveF ignored always .4.1.4 EsystemF ignored always .4.2 EusageF .4.2.1 Eread onlyF transferred back and forth as the RT-11 "protected" bit .4.2.2 EhiddenF + the file is not counted as existent in the directory listing + - .4.2.3 EarchiveF automatically set after transfer from RT-11 to MS-DOS, never cleared automatically after transfer from MS-DOS to RT-11 .4.2.4 EsystemF + the file is not counted as existent in the directory listing + - .4.3 EmodificationF When to be changed at will, brxDOS suggests a default setting in angle brackets in the following manner, depending on the number of files on disk that match the user's file specification: .4.3.1 Esingle fileF the appropriate setting found on MS-DOS disk is default .4.3.2 Emultiple filesF .1 E1st modificationF archive bit set - others reset - is default .2 Elater modificationsF the setting denoted last - either done or aborted - is default .5 ElengthF .5.1 EFrom MS-DOS to RT-11F, every byte beyond the MS-DOS file length - declared in the MS-DOS directory entry - will be nulled in the RT-11 file. .5.2 EFrom RT-11 to MS-DOSF All - even trailing - nulls in an RT-11 file are treated as belonging to the file length that is then filled in into the directory entry (so an MS-DOS file may be "longer" after being copied from MS-DOS to RT-11 and back again). As an option, the brxDOS syntax allows a "/C" switch trailing the RT-11 file specification. This makes sense as soon as the user is sure that he/she is copying RT-11 ASCII file(s) to MS-DOS file(s) (not to MS-DOS disk image): Rather than nulling the remainder of the last MS-DOS cluster, brxDOS counts the trailing characters in the last MS-DOS cluster and writes the actual character count into the MS-DOS directory entry as the experienced MS-DOS user is used to. Since trailing nulls may belong to the intended contents of a binary file, considerable care should be taken through the usage of this + option. E. g., Microsoft Word does not open a *.DOC file with the + expected trailing 8 or 9 empty bytes stripped off through this + method. Generally, one or more clusters that precede a last cluster + full of nulls will be treated with their complete byte count. + + - 3. EHARDWARE REQUIREDF 3.1 Efloppy controllerF + brxDOS is developed for and tested on a BAYDEL BRX50 floppy disk controller in conjunction with at most two double sided drives of arbitrary origin, that comply with the requirements listed in the BRX50 manual. The controller's thoroughly tested and recommended firmware release is V12. 3.2 Efloppy drivesF Care should be taken while selecting an appropriate drive because of their different abilities to read/write 48 or 96 tracks/inch (tpi) wide tracks: here, the BRX50 controller dos not support half stepping and therefore writes narrow tracks in a drive that supports 96 tpi disks. Of course, it reads both widths anyway. IBM do not assert being able to write an XT disk on an AT drive so that the XT disk is readable then on another drive. In case of making use of a switched power supply, the magnetic radiation of it must be kept apart of the heads of a high density drive. This can be achieved by installation of a soft iron sheet metal around the power supply module. Otherwise, the drive operation in high density mode may be unreliable. The drives should be jumpered the way that their indicator lamps are only on as long as the appropriate head is physically loaded. As long as none of the connected drives is jumpered as unit #0, the controller will never go online. The microdisk drive must rotate with 300 rpm at both double and high density. Its pin 34 must carry the READY signal. Drives with only the DISK CHANGE signal on pin 34 potentially operated with a modified BRX50 controller hardware are not supported by brxDOS. 3.3 ECPUF The -11 CPU must contain the extended instruction set (EIS). 3.4 Econsole terminalF A VT100 is required. Advanced Video Option (AVO) is recommended. The TT: TAB setting is faster than the opposite. TT: must not be set to CRLF and WIDTH less than 140 (decimal) simultaneously. 4. ESOFTWARE REQUIREDF 4.1 Eoperating systemF 4.1.1 ERT-11F + brxDOS is developed and tested under V5.4D through V5.5. It is + proved to run under V5.1 through V5.3 as well. + - There are installations running under STAR-eleven too. 4.1.2 ETSX-PlusF ~~~) brxDOS requires V5.0 and later. MEMMAP and SPFUN privileges are required. In order to save CPU time, the execution is suspended while waiting for terminal input and resumed only every second for detection of disk change and the user's activation character stroke. TSX-Plus V6.0, V6.01 and V6.16 use the unmodified RT-11 V5.2 DUX handler. Because of a bug in the RT-11 V5.2 through V5.3 DU handler - if and only if TSX-Plus V6.0 through V6.16 has been started from neither RT-11 V5.2 nor V5.3 - the system hangs infinitely after having started brxDOS, so it must be stopped, rebooted and TSX-Plus re-launched from the appropriate RT-11 release (say V5.2). In rare cases besides that, a workaround described under 4.1.4 is appropriate. Operation under the later TSX-Plus releases V6.2 through V6.40 does not require such effort anymore. 4.1.3 ESHAREplusF ~~~) As tested so far, release V3.0 supports brxDOS. CMKRNL right is necessary. Because of an uncertain release recognition procedure inside SHAREplus, unpredictable trouble with the DU handler of RT-11 V5.2 through V5.3 may arise. Then, the user should either avoid the usage of those handler versions or apply the workaround described below. 4.1.4 Emulti-user systems and RT-11 V5.2 through V5.3F A derivative "Vn.nEAF" called "brxDOS.SAEAF" can be availed on request in addition to the original issue "brxDOS.SAEVF" that must be copied to the system instead and renamed to "brxDOS.SAEVF". Yet - as opposed to the original issue - this derivative will likely become incompatible to future releases of RT-11. Instead, a patch to the source file DU.MAC of RT-11 V5.2 through V5.3 provides more safety for more effort. Here, the distributed code 10$: CMPB R4,#SP.BYP BNE 20$ 15$: DO BYPASS,THEN,DUEXIT 20$: CMPB R4,#SP.MUC BEQ 15$ must read 10$: CMPB R4,#SP.BYP BNE 20$ 15$: movb #sp.byp,q$func(r5) ;13-jun-90 DO BYPASS,THEN,DUEXIT ;13-jun-90 20$: CMPB R4,#SP.MUC BEQ 15$ and the bug is fixed forever. 4.2 ERT-11 monitorsF The code is runnable under SJ, FB and XM without requiring any adaption to the specific monitor. It is overlaid, yet may under worst circumstances - claiming a total of 64~) (decimal) blocks of low memory space - require to remove a foreground or system job under FB or XM (e. g. PS/2 Microdisk~) treatment needs - at a time, for buffers and handlers - at most 40 (decimal) extra blocks of dynamic heap space in excess of the net code image). Since the USR (if SET SWAP) swaps over pure brxDOS code, its 8 (decimal) blocks space is available to brxDOS under SJ and FB. Under XM, VBGEXE avails sufficient space to start brxDOS within extended memory. If the XM monitor is the distributed version or sysgenned without .FETCH support, every device handler that will be needed during execution must be LOADed before starting brxDOS in order to circumvent the "Sorry, RT-11 .SERR unloaded XM handler" brxDOS error message. 4.3 Edevice handlerF A DU: type device handler is required. The user should follow the instructions in the BRX50 manual. This handler may be arbitrarily renamed under RT-11 or renamed and redefined into TSX-Plus or mounted under SHAREplus, yet must avoid any conflict with the distributed DU handler - even under extended-units support - or multiple MSCP class units installed. Therefore, the starting program asks the user for his or her individually installed device. For ease of operation, its name may even be passed through a command file (refer to the file BRXDOS.COM pre-edited for RT-11) or passed as a parameter with the CCL command "BRXDOS ddx:". It is absolutely mandatory to have selected the BRX50's starting logical unit number "SLUN" through its switch bank 2 switches 1 through 3 to the same RT-11's device unit number "x" that the user passes to brxDOS as "ddx" within the beforementioned command line. As a consequence, this BRX50's starting logical unit number "SLUN" versus RT-11's device unit number "x" always refers to MS-DOS drive number zero. Any violation of this rule leads to an unpredictable kind of drive confusion and "no drive" messages, since brxDOS has no runtime means to compare the specified device unit number with the BRX50's switch setting. 4.3.1 Eunmapped systemsF Under RT-11 SJ or FB, the distributed handlers work straightforward. 4.3.2 Emapped systemsF Of RT-11 release V5.4D and V5.4E (does not apply to TSX-Plus), a bug must be fixed in UM.MAC. Here, the following code ADD P1HIGH-UMBASE(R3),R2 MOV R2,@#SEKPAR should read nop ;for SIPP DUX.SYS only ;13-jun-90 ADD r1,R2 ;13-jun-90 MOV R2,@#SEKPAR and DU: will LOAD/.FETCH correctly even in extended memory. .1 ERT-11 XMF Although brxDOS is automatically loaded into low memory as a privileged background job, the handler will partly be installed in extended memory, so the beforementioned problem should be kept in mind. .2 ESHAREplusF The problem with the RT-11 V5.4D or V5.4E handler described above must be avoided. The user must have mounted both units explicitely and - through the /nocache option - avoid directory caching. A mapped handler (i. e. %%X.SYS) is a must, /22bit setting is recommended, /external is impossible. (Yet, brxDOS itself circumnavigates the internal handler's buffer.) .3 ETSX-PlusF Since it makes no use of the handler releases listed above, the operation is straightforward. 5. EINSTALLATIONF For best compatibility between operations under brxDOS and RT-11, the BRX50 controller switch bank 2 switches 4 through 7 must be in the following positions (the user may refer to the BRX50 Application notes configuration instructions too), depending on the actual correspondence of the physical drives to their logical unit numbers: E unit_1 unit_0 SW5 SW4 RT-11 FUNCTION F MINI_drive ON ON RX50/33 emulation MINI_drive (5.25" drives) - factory setting MICRO_drive ON OFF RX22/23 emulation~~) MICRO_drive (3.5" drives) MICRO_drive OFF OFF Mixed RX22/23 and MINI_drive RX33/50 emulation~~) - Combo Mode SW7 and SW6 must both remain in the ON position (factory setting). Important: In Combo Mode, the MINI (5.25") drive must be drive 0 and the MICRO (3.5") drive must be drive 1 - never vice versa. Before operating brxDOS the first time, the comfortable dialogue structure wants to know on which drive number it finds either a minidisk drive or a microdisk drive. A location to be patched at installation time is provided for this purpose. The beforementioned command file contains the necessary code for doing this automatically under RT-11. Under both TSX-Plus and SHAREplus, this command file is not supported. Then, the user must SIPP or PATCH in advance the image of brxDOS.SAV in accordance to the contents of the command file, if (s)he wants to divert from the Combo Mode installation option. Under SHAREplus, the shipped brxSHP.COM installs the brxDOS image with the default additional system rights in order to have read access to the unevitable physical addressing scheme even in protected systems. brxDOS must not be used on BRX50 controller release V10. Instead, the user should take care on having installed the V9 (or earlier) firmware that is still able to detect the disk absence condition distinctively. With V11, this problem has been fixed again. 6. EOPERATIONF brxDOS ist designed for self-explanatory operation. The user may just install the hardware, make sure DU[X].SYS (DU.TSX under TSX-Plus) is on the system device, copy BRXDOS.SAV to SY:, type "BRXDOS [dd[x]:]" and see what's going on. Doing so, the user must honour the BRX50's starting logical unit number (selected through switch bank 2 switch 1...3) with RT-11's device unit number 'x' typed in conjunction with 'dd' in the command line. First of all, brxDOS guesses a certain format of the disk residing in the slot, then - most likely - fails and retries with at most two further guesses. The running program prompts the user for input and reports everything that's bound him/her to make aware of. Initially, he/she will recognize the MS-DOS style display of the current directory. After having selected a function from the menu, he/she will most likely be prompted for a command line in a manner that - in accordance to the common syntax - a set of possible responses is displaid. Especially in the case of longer drive/path/file specifications, this display describes the command string in the completely composed form - although the user may suppose the pre-displaid MS-DOS prompt to be known to the system as a leading path specification that may be simply accomplished by means of appending additional trailing path/file specification in his/her response. Yet, every drive number response makes the current directory jump back to drive level and/or a leading backslash response returns to the root directory. The user will observe, that a lot of reasonable responses are predetermined as default. So the default RT-11 sequential device is TT:, the default RT-11 random device is DK: and the default MS-DOS file name is "disk image" (if copying at drive level, yet "all files" for copy at any directory level or listing the directory). brxDOS is designed with extreme care in order to circumvent any risk of physically corrupting data - so the user may logically abort any dialogue or any transfer at any time, yet most likely every data integrity will be preserved all the way, as long as the environment is operating properly and the involved MS-DOS disk complies with the rules of MS-DOS. Whenever the user physically changes the disk in the current drive within a dialogue stream, the program may abort the current function and prompt for a retry. Does the disk change occur outside the dialogue, brxDOS helps itself automatically. Unlike MS-DOS, brxDOS never deals with invalid directory and file allocation table copies in memory. As opposed to that, brxDOS recognizes every disk change, invalidates the according disk structure duplicate in memory and re-reads the tables in from the new disk. A first exception to this rule is an intentional disk change during terminal output page hold (when the user hit the "NO SCROLL" key on the VT100 a first time or sent te ^S "XOFF" control character to the monitor): As long as the monitor is waiting for the "XON" character to resume output to the terminal, brxDOS is blocked and does not check the drive for a possible disk change. The user must not exchange the current disk with another one of the same format in this situation, because the RT-11 monitor provides no economic compatible means for the detection of page hold mode. The same disadvantage turns up under SHAREplus during normal wait for user response as soon as the user has struck a first character on the keyboard. The SHAREplus SETting PROGRAM/LOOP should, yet unfortunately does not help either in this situation. Under RT-11 FB or XM, care should be taken with running foreground or system jobs the same time brxDOS is running as a background job: In this configuration, brxDOS carries the lowest priority and may be blocked because of pending i/o as long as not all higher-priority jobs are de-scheduled from execution. Then, brxDOS may be unable to check the disk for absence either. As soon as brxDOS writes a (modified) directory to the MS-DOS disk, the FAT ID byte will be patched to its correct value. For this reason, an ATARI ST disk with an initially wrong FAT ID will return consistently from this procedure. For additional redundancy, as soon as brxDOS detects a bad boot sector, it suggests to proceed with mere FAT ID evaluation as an MS-DOS disk as long as the disk is not created on an ATARI ST computer. A physically damaged 1st FAT leads to an automatic read retry from the 2nd FAT copy. A "Sorry, RT-11 .SERR unloaded XM handler" or "Sorry, RT-11 .SERR .FETCH error" brxDOS error message may be avoided the easiest way by having LOADed the handler that caused the message before running brxDOS. In this case, the XM monitor probably has no .FETCH support. Under both TSX-Plus and SHAREplus, because of the numerous time-consuming operations on the MS-DOS disk, the user is strongly encouraged to run brxDOS as a subprocess in parallel to other work to get rid of frustrating wait for completion of those operations, once initiated. Thus, brxDOS needs only be started once per session and may further be left running even with no intervention - a process window switch provides easy access at any time. The SHAREplus process size is sufficient if set default /working_set=128(decimal): "CREATE/PROCESS/SUBPROCESS/NOLOG/IMAGE=SY:BRXSHP.COM/HIBERNATE BRX50" is tested as a rather comfortable means of launching a subprocess off the system startup file. The shipped brxSHP.COM is pre-edited for this application. In addition to the obvious functionality, a couple of potentially useful hints and remarks are mentioned below. 6.1 EList MS-DOS directoryF The default RT-11 output file type is "DIR". + If the label and/or the file names of the MS-DOS directory - by + accident - contain non-printable binary garbage, the according + characters are displayed as question marks. + For a hardcopy of the MS-DOS directory (or even an MS-DOS file), the user should have his/her RT-11 LP: handler SET LP: ENDPAG=1 and respond "LP:" for the RT-11 output file. (Including V5.4G, when output is spooled to SP: and final page eject is enabled and desired, RT-11 wants the user to specify a - dummy - filename in addition to the output device specification.) + The first line commences with a dot, followed by a character in + order to assure a left-aligned printout even in cases when the print + head was not in the leftmost position: There are printers that do + not move at all without a printable character in front of the . + + Of the Windows95's long file names, the most significant 8 bits of + every character word are discarded. So, in the listing, the least + significant 8-bit bytes appear normally - as printable characters. + 6.2 EShow MS-DOS media typeF 6.3 ECopy MS-DOS to RT-11 fileF For MS-DOS disk image copies (device copy), the default RT-11 output file type is "DEV". R The user may immediately "type" an MS-DOS file on the console screen through the "copy from MS-DOS disk to RT-11" function by merely striking the return key as a response to the RT-11 output file query. Yet, a coming ^Z (that stands for the german uppercase "U" umlaut "]") will stop TT:. Abort occurs as usual through ^C^C. R Copied straight from the MS-DOS file to RT-11's LP:[file], the MS-DOS end-of-ASCII-file-character ^Z can make such printers hang that expect this character as a mode bracket. When the user is short on space for RT-11 output, he/she should be aware of that the RT-11 option "[-1]" allocates the largest available room for a file. This option is applicable even during bulk file copy using the explicit syntax "dd:[-1]" or "*[-1]" (or "*.*[-1]") for the output file specification. "[-1]" alone does not work. Unlike vice versa, brxDOS does not stop copying from MS-DOS as soon as it detects and reports bad data on the MS-DOS disk. This is to enable the user to analyse the duplicate of an MS-DOS disk under RT-11 even around MS-DOS data flaws. In order to enjoy a considerably automatic mapping of the long MS-DOS file names to the shorter RT-11 names, the user should refer to the description of the wildcard features described there for the RT-11 output files. 6.4 EChange MS-DOS file attributesF The user can inspect the attribute bits of an MS-DOS file the way that he/she inputs - to the "change attribute" function - a file specification that leads to a s i n g l e file lookup and displays the current bit settings of this single file in angle brackets. If he/she always responds with to the bit modification questions or aborts the dialogue with , a change is avoided. 6.5 ERename MS-DOS fileF During RENAME, brxDOS sets the (not used by MS-DOS) most significant bit of the last byte of the file extension of every renamed file for internal use and clears it upon completion. + In case of long file names of the Windows95's VFAT file system, the + RENAME function can only rename the (short) MS-DOS name, not the + long Windows95 name. The user must be aware of any consequences of + such an action. brxDOS can only fully erase both the short and long + name of a file, when a short name already exists, to which a file is + being renamed to. + brxDOS prior to V08.05 must not be used for automatic bulk renames through wildcard specification, if and only if an(y) old file(s) with the same name as an arising new name has/have to be deleted automatically. The reason is, that whereas the directory is updated, the file allocation table (FAT) - by mistake - is not. So, in this rare case, the MS-DOS disk integrity would be lost. 6.6 EDelete MS-DOS fileF 6.7 ECopy MS-DOS from RT-11 fileF Similar to the genuine MS-DOS environment, the user can create an MS-DOS file through an edit from the system console: A copy from TT: (This is the default RT-11 sequential access input file) to a new MS-DOS output file is sufficient. As known from RT-11, ^Z closes this file. File bulks, the RT-11 block sum of which seems to fit into an MS-DOS disk, in fact need not fit: When the MS-DOS disk partitions its space into 2 sectors per cluster, odd RT-11 block numbers for the file size expand to even MS-DOS sector numbers in order to comply with the next upper cluster boundary. This way, a sum space calculation dealing with odd RT-11 block counts may fail. Unlike vice versa, brxDOS stops copying to MS-DOS immediatly on detection of bad RT-11 source data. As opposed to vice versa, no sophisticated file name mapping mechanism through wild card usage is necessary here to extend short RT-11 file names to the longer MS-DOS names. This feature is perfectly carried out by usage of the rename function thereafter. 6.8 EInitialize MS-DOS diskF + The experienced MS-DOS user knows this operation as the so-called + "logical formatting". + The user may edit volume labels as he/she is used to entering file names with or without extension. Processing a label entry, brxDOS leaves embedded jokers behind, whereas trailing jokers/wildcards are subject to be flushed. The latter takes place separately for name + and extension. The archive bit will be set for the label entry. + - As long as the MS-DOS boot sector is not required on disk, DEC RX33 formatted disks need not be reformatted for use as IBM AT disks. Instead, they may be initialized under brxDOS right-away. The appropriate applies to the DEC RX22 disk used as a standard IBM PC microdisk under brxDOS or accordingly - the DEC RX23 disk used as an IBM PS/2 disk under brxDOS. 6.9 EFormat MS-DOS diskF On the other hand, IBM AT, PC microdisk and PS/2 disks may be formatted as such under brxDOS and then initialized for use as DEC RX33, RX22~~) and RX23~~) disks under RT-11. Doing this under an old RT-11 release, the user must not quit brxDOS through rather than menu option <0>. Because of an incomplete initialization functionality in DU: handlers older than RT-11 V5.5 (e. g. the one of RT-11 release V5.4C still being used under TSX-Plus V6.40), having formatted a fresh MS-DOS media under brxDOS and immediately initializing this to a DEC disk, the user may be surprised by an invalid DEC media image resulting this way. Whereas a plain abort cannot drop the current controller operating conditions, menu option <0> has the power to leave it behind clean regardless of whether - in turn - the DU: handler resets the controller to its idle state. Prior to BRX50 firmware release V11, an attempt to format a write protected disk caused the message "Sorry, MSCP media format error" - which in fact did not describe the situation accurately. This insufficiency of the controller firmware up to the V10 release has been fixed with V11. For overall compatibility, brxDOS format writes both the 32 bit MS-DOS 4.0 and the 24 bit ATARI ST serial number of an almost random selection into the MS-DOS disk boot sector. The user should never format a particular disk structure onto wrong media. Instead, he/she must write AT Mini disk format on High Density (HD) Mini disk only, PC, XT Mini disk format on Double Density (DD) Mini disk - never vice versa. Else, the AT formatted DD Mini disk will be unreliable and the PC, XT formatted HD Mini disk will not work at all. Micro disks require DD or HD~) media accordingly. + The experienced MS-DOS user knows this operation as the so-called + "physical formatting". + + 7. EHINTS AND KINKSF The user can - under brxDOS - copy conveniently between an MS-DOS drive and an RT-11 device "DUx:" back and forth, as far as the opposite unit contains any initialized DEC disk. The latter applies even for having booted RT-11 from DUx: too. The user may duplicate MS-DOS disks the way that he/she copies the MS-DOS disk image to an RT-11 file and the latter back to an appropriately formatted further MS-DOS disk. Bulk file transfers within MS-DOS between different disk types can be easily carried out through a wildcard copy from one MS-DOS disk to RT-11 and another wildcard copy from RT-11 to a different MS-DOS disk, as long as the file names are not too incompatible and the creation time of day may be discarded. The user should mind the attribute bits that are not all automatically transferred back and forth. In addition - since RT-11 measures the file size in blocks rather than in bytes - the resulting MS-DOS file length will be stretched to the sector boundary. 8. EORDERING INFORMATIONF Single-Use licensed software is furnished under the licensing provisions of PDV's Standard Terms and Conditions of Sale, which provide in part that the software may be used at only the single site at which the software is first installed, and may be copied (with the proper inclusion of the copyright notice and any proprietary notices on the software) for use at the same site. 9. ESOFTWARE WARRANTYF Warranty for this software product is provided by PDV with the purchase of a license for the product as defined in the Software Warranty Addendum. -------------------------------------------------------------------- ~) Release V9 or later of BRX50 firmware required in conjunction with a PS/2 drive that outputs READY rather than DISKCHANGE on pin 34. ~~) Release V12 and up of the BRX50 controller firmware is required. ~~~) Because of a bug detected lately in the BRX50 controller firmware through to the V10 release, servicing utilities must never be operated anyway else than in kernel mapping. Otherwise, unpredictable logical ricochets may shoot the adjacent software down. This problem applies to brxDOS mapped by VBGEXE under RT-11 XM and both TSX-Plus and SHAREplus as a rule. The bug has been fixed since BRX50 firmware release V11. ********************************************************** ** ** ** Most of the quoted items are protected ** ** trademarks of the appropriate corporate. ** ** ** ********************************************************** R -------------------------------------------------------------------- + August 1993 + pdv-systeme Ges. f. Systemtechnik mbH Bornhardtstr. 3 D-38644 Goslar - R