^^ .NOFILL Copyright 1977, McGill University .SPACING 1 .RIGHT MARGIN 76 .FIGURE 20 .CENTER RT/RSX SIMULATOR .CENTER ================ .CENTER MISC NOTES .CENTER ========== .FIGURE 22 .TAB STOPS 47,60 NAME: RTRSNOTES.RNO DATE: 14-SEP-77 AUTHOR: G.Bernstein IDENT: UPXX. LOCATION: SY:[1,203] LAST UPDATE: .PAGE .TAB STOPS 8,16,24,32,40,48,56,64 .FILL HISTORY .skip 1 ------- .skip 2 A set of files supporting an RT11/RSX simulator was received from Tom Provost of MIT/BATES labs in 1976. The originally distributed software was prepared by a DEC system programmer (Bill Klogher) as a prototype system demonstrated to DEC management in the hope that it would evolve into a DEC supported S/W product. Thus, it was a fairly quick and dirty implementation with many operational as well as inherent design problems. The idea, however, was good enough to encourage several users of both RSX and RT-11 to polish up the product sufficiently so that it could be used in production. These notes describe some of findings that were made at the Biomedical Engineering Unit (BMEU), McGill University during the development work and should prove useful to others who are planning to run, enhance or modify the system. .skip 2 OBJECTIVES OF SIMULATOR .BREAK ------------------------- .paragraph The objective is to allow a user to run a pseudo RT-11 system under RSX-11M, and give the appearance that he is sitting at an RT-11 stand-alone terminal. It supports all the usual program development steps such as running the RT-11 editor, compiler, assembler, linker, BASIC etc and the running of user-developed programs which perform only disk and/or TTY I/O. It is useful in situations where the laboratory mini is busy doing data acquisition and a programmer could use a larger RSX-based machine for RT-11 program development. .SKIP 3 APPROACH .SKIP 1 -------- .SKIP 2 The general approach is to load a modified RT-11 executive into RSX memory using an RSX task which emulates the functions of the RT-11 bootstrap. The modifications to the executive consist of replacing direct references to I/O device registers with calls to RSX routines which accomplish equivalent actions using QIO directives. These routines are located in the boot task, thereby necesitating communications between the RSX boot task and the loaded executive. The other important modification to the RT-11 system is to replace all RT-11 device driver code with equivalent RSX QIO directive code. Thus, for example, the system device driver linked to the modified executive consists of QIO disk read/write directives using a DPB located in the boot task. .skip 2 The system can be run in one of two filing modes. In the virtual implementation an image of an RT-11 "system disk" is located within a file ([1,200]VIRK05.VIR) in which is located the modified RT-11 monitor, the modified device drivers and the unmodified system programs. All RT-11 filing then proceeds normally by referencing virtual blocks of the file instead of logical blocks of a physical device. For example, when RT-11 programs require directory information the USR receives a request to read block 6 of the device, which it passes along to the device driver. Under the virtual system, the modified handler will execute the read operation on virtual block 6 of the file. .skip 2 The second approach consists of locating the modified RT-11 monitor on a foreign mounted RT-11 disk which is then accessed by the RSX system using logical block I/O instead of the virtual I/O mentioned above. .skip 2 It is important to note that with these modified components of RT-11 all the other RT-11 system programs, executive requests, FORTRAN programs, etc will operate without modification since these all eventually filter down as executive requests. .skip 2 In the original distribution from Provost three boot tasks were provided. One was the virtual boot task, the other the logical system boot task and a third (FUDG) was more or less a utility task used to boot to the logical monitor with another disk handler which would then allow writing to a virtual file. This task was used to load the virtual file with the components required for operation with the virtual bootstrap. The third task has been eliminated in the BMEU implementaion by distributing a workable copy of the virtual file. It should be noted at this point that an earlier version of this document went to great lengths describing the originally distributed system. Most of the information in that document (particularly file names) is now obsoleted by this one. .skip 3 IMPROVEMENTS .skip 1 ------------ .skip 1 Some of the operational problems fixed were: .skip 2 .nofill -Terminal stutter no longer a problem -Hogging CPU time. The original would not allow tasks of lower priority to execute (e.g. AT.). This was fixed, but the emulator is still CPU bound at times, particularly during device I/O (RT-11 enters a tight loop waiting for completion sometimes). However, the problem is not troublesome enough to prevent use. - Device drivers for DX and TT added. The DX driver accesses a foreign-mounted RT-11 floppy plugged into drive 0. It is required for file communication back and forth between the RSX system and the target RT-11 system. -Bug fixes. There was a serious bug in the original system device driver code which would cause intermittent "HDWR ERR" messages and essentially precluded using the editor on large files. This and other minor bugs were fixed. -A 24K virtual system was built. This was essential so that development work on the emulator could could be performed using the emulator itself under RSX, rather than having to go back and forth between RT and RSX machines. (The 16K version is not big enough to assemble the RT-11 executive.) -The size of the virtual file was extended to simulate a real RK05 disk (4K blocks). -Clean exit back to RSX by typing . -Conditional assembly code stripped from the bootstrap sources to make them more readable. -Documentation prepared and distribution tape organised. .skip 3 .fill EXISTING PROBLEMS, RECOMMENDATIONS FOR FUTURE WORK .SKIP 1 -------------------------------------------------- .skip 2 A) Address Resolution Problems .skip 2 A serious error in the original design makes it very difficult to modify code in either the boot task or the executive which result in address changes. This is basically because these two pieces of code communicate using jumps to absolute addresses which are hardwired in with local equates. The conditional assembly files RSX.MAC and RSX24K.MAC serve only as a convenience for assembling different size systems; e.g. 16K or 24K. Any future work must first attack this problem. .skip 2 B) Checkpointability .skip 2 It is now impossible to build a checkpointable version of the system. This is because the modified executive makes use of core normally a part of the RSX task header. .skip 2 C) Size of System .skip 2 It would be desirable to be able to run one version of the emulator which could be extended at run time to be, for example, an RT-11 8K to 28K system. This could be easily tackled once problems (A) and (B) are solved. .skip 2 D) Creating Newer Versions .skip 2 The distributed system uses an RT-11 V02B executive. To update to V02C or V3 requires the executive sources and involves a good deal of drudgery. Some semi-automatic method should be possible if problem (A) is ever solved. .skip 3 .nofill REBUILDING RSX BOOT TASKS ------------------------- .fill The distribution tape contains command files for rebuilding the various versions of the bootstrap task with and without ODT. Changes to, for example, the location of the virtual file, the devices supported, etc are inevitable for different installations. When making changes it is important to note that the task header size must be kept constant at 204 (octal) bytes. This can be accomplished by adjusting the size of the task stack within the build command files. Detailed instructions for calculating the appropriate stack sizes can be found in the comments sections of the command files. .skip 3 .nofill ASSEMBLING RT-11 EXECUTIVE -------------------------- .FILL .skip 2 The modified RT-11 executive may be rebuilt using the 24K version of the emulator on the RSX system or may be done on an RT-11 system and later transported to the virtual file using RT/RSX PIP. The basic operations are as follows: .nofill .skip 2 1. Assemble the RT/RSX monitor (a) 16K Virtual system .R MACRO *RTRS16,RTRS16=RSX,KMON,USR,RMONSJ,KMOVLY *RKV,RKV=RKV (B) 24K Virtual system .R MACRO *RTRS24,RTRS24=RSX24K,KMON,USR,RMONSJ,KMOVLY *RKV,RKV=RKV (c) 16K Logical system .R MACRO *RTRS16,RTRS16=RSX,KMON,USR,RMONSJ,KMOVLY *RKL,RKL=RKL It should be noted that there may not be enough room on the system device to store the '.LST' file. Because this file is essential for debugging purposes, it is recommended that it it be produced somehow, e.g. by construct of the form ",RTRS16=RSX,KMON,...". Also note that the executive object files generated above are distributed with the system, so that unless executive modifications are planned there is no need for reassembly. Also note that 'RTRS16.OBJ' and 'RTRS24.OBJ' can subsequently be used to create either a virtual or logical system of 16K or 24K respectively. The only difference between the two is the type of system device driver which is linked into the executive (i.e. either RKV or RKL for virtual and logical respectively. .skip 3 LINKING THE EXECUTIVE AND DEVICE DRIVERS ---------------------------------------- .skip 2 (a) 16K Virtual executive .R LINK *RSXMON.SYS,RSXMON=BSTRAP,RTRS16,RKV (b) 24K Virtual executive .R LINK *RSX24K.SYS,RSX24K=BSTRAP,RTRS24,RKV (c) 16K Logical executive .R LINK *RSXLOG.SYS,RSXLOG=BSTRAP,RTRS16,RKL Note that it is important to use the file names shown above since each of the bootstrap tasks look specifically for the presence of one of these files on the RT-11 device upon boot. Note also that the 16K and 24K boot tasks look specifically for device drivers with the extra charcater 'X' or 'Y' appended to the driver filename respectively; e.g. the 16K floppy driver is called 'DXX.SYS' while the 24K floppy driver is 'DXY.SYS'. Drivers other than the system device driver are assembled and linked in a fairly standard RT-11 fashion. For example, to assemble and link a 24K TT driver, virtual OR logical system: .R MACRO *TT,TT=RSX24K,TT .R LINK *TTY.SYS,TTY=TT .skip 3 USING RSX ODT AND RT11 PATCH ---------------------------- .SKIP 2 RSX ODT can be used to advantage in debugging the system. Once debugged, if the change is slight, (e.g. change a BEQ to BGE) the change can be implemented by using RT-11 PATCH on the modified executive, rather than reassembling and relinking. Then, when enough changes are accumulated, the source code can be changed. .skip 2 When using ODT it is essential that assembler listings are available for both the boot task and the executive. The usual procedure is to run a version of the boot task which has been task-built with ODT. Upon entry to ODT, relocation register 0 should be set to the base of the RSX task; i.e. always 204 octal. ODT's SST vector must be disabled by setting $5V=0. A breakpoint is then placed at an area of boot code which is executed AFTER the RT-11 executive has been read into the partition and relocated therein. At this point, other breakpoints can be set in the executive. .skip 2 In order to get the proper executive addresses for setting breakpoints, examining registers, etc, the location of BASE must be found by examining location 54. To facilitate following the flow with the executive source listings it is advisable to define a second relocation register which represents the in-core offset to base. This can be calculated by subtracting 16000 (unrelocated address of $RMON) from the contents of 54. For example,in the 16K version, examination of 54 yields a value of 71526. This is the location of $RMON in core. $RMON on the listing is at 16000. Therefore, by defining 1R=53526 (71526-16000) one is able to reference locations on the listing relative to 1R. .skip 2 As an example, consider placing a breakpoint at 'QMANGR' within the RT-11 executive (listing location 23360). A typical session with ODT would be: .skip 2 >RUN RTVODT ODT TTXX __204;0R (SET RELOCATION REGISTER FOR BOOT TASK) __$5V/XXXXXX 0 (DISABLE ODT'S SST VECTOR) __0,101206;B (BREAK INSIDE BOOT TASK AT '.PRINT BSTRING') __G (START TASK) 0B;0,101206 (ODT BREAKS IN BOOT TASK) __53256;1R (SET RELOCATION INTO EXECUTIVE) __1,23360;B (SET BKPT AT QMANGR) __P (PROCEED WITH BOOT) RT/RSX V0XXX,etc (RT/RSX BOOT MESSAGE) R PIP (RUN PIP) 1B;1,23360 (BREAKPOINT AT QMANGR) .SKIP 3 Patching may be accomplished by setting relocation register 0 of PATCH to 21000 (octal). Thus to patch the contents of QMANGR; .skip 2 .R PATCH FILE NAME__ *RSXMON.SYS *21000;0R *0,23360/10446 XXXXXX *E .page REASSIGNING DEVICES ------------------- .SKIP 2 It is possible to try out various configurations without rebuilding the boot tasks by installing the distributed boot task and reassigning LUNs from a privileged terminal. For example, to use the distributed version of RTV with support for a foreign-mounted RT-11 RK05 instead of a foreign floppy: .skip 2 >INS RTV >REA 5 RTV DK1: The LUNs currently assigned in the build command files are: BOOT TASK DEVICE LUN ========= ====== === RTV RSX SY: 1 TI:(input) 2 TI:(output) 3 LP: 4 DX0: 5 ============================================= RTL DX1: 1 TI: 2 TI: 3 LP: 4 DX0: 5