Working with RTE IV B
I set up the BASIC interpreter on my system and configured it to be readied at startup. I feel that I have finally mastered the concepts behind programs and how they are stored and accessed in RTE, thanks in part to excellent explanations from Dave Bryan.
When the BASIC system is generated, the LOADR program links together the relocatable code and any routines from libraries, producing the programs BASIC, BASC1, BASC2, BASC3, BASC4, BASC5, BASC6, BASC7, and BASC8.
The numbered programs are overlays that are fetched as a means of dealing with a limited memory size. The program is segmented so that after one logical set of code is complete, the next segment is loaded and executed.
The LOADR has placed the code for those 9 programs in temporary space on a disk cartridge and built an ID segment in memory that defines the program and points to the disk based code. These ID segments are by default temporary, meaning they and the reserved disk space go away when the system is rebooted.
If a RUN command is issued for BASIC after loading, it finds the name BASIC in the temporary ID segments and executes it. Any call for an overlay will find that name in the temporary segments and cause it to be run. After a reboot, with no temporary ID segments, the attempt to run BASIC will result in a No File Found type of error.
A command :SP will store the code from a temporary ID segment into a permanent named disk file of type 6. If this is done for all nine program names, then BASIC and its segments are kept permanently over reboots.
However, a type 6 file is not kept in the ID segments, thus after a reboot the RUN command won't find the name BASIC. It has been written so that if it searches the ID segments and a name is not there, it then looks for a type 6 file of the same name. The type 6 file is read to create a temporary ID segment which does point at the code in the type 6 file.
Thus, RU,BASIC after a reboot will appear to run BASIC the same way it does after the initial generation with LOADR. However, it is only the name BASIC which is copied into a temporary ID segment. When the program tries to load and run one of its eight overlays, the name is NOT found in the temporary ID segments and a failure occurs. This in spite of the fact that the names are in type 6 files.
Thus, for programs with overlays, such as BASIC, FTN4 and ASMB, the type 6 files for their overlays are not enough and a temporary ID segment must be created. A command :RP will find a type 6 file and create a temporary ID segment, the perfect solution.
If you do an :RP for every overlay segment after a reboot, the temporary ID segments are set up. When the main program is executed with RU,BASIC, the main code is also put in the temporary ID table and every overlay is waiting in the table for when it is needed.
The convention for handling this is to make a file of the :RP commands, name it the same as the main program but with a forward slash (/) prefix. The /BASIC file is executed as part of the startup WELCOM file, recreates all the temporary entries for the BASIC system, and now it will run properly if called with RU,BASIC.
In addition to the temporary ID segments, during system generation of RTE IVB, the administrator can load programs into the ID segments as permanent files. Those use some space on the disk cartridge which is not associated with any file name, but is pointed to by the ID segment.
In addition to these disk based permanent programs, whose name is not visible in any directory list but which will execute with a RUN command, the administrator can load some programs permanently in memory. The code takes no space on disk at all (other than as part of the system to be loaded at bootup), does not show up in any directory listing, but will be executed by RUN
Just to round out the situation, I should mention that when creating a program with the LOADR, an option can be entered to make it permanent. This sticks the produced code in one or more tracks on the disk cartridge, without a name in the directory, then makes a permanent ID segment which persists across boots.
This was confusing at first, when I could issue RUN commands for program names which did not show up in any directory. Further, you can see some programs stored as type 6 files, but if the overlay segments were not set up by :RP then the program would fail to run properly.
Now, however I grasp how it works. I can look at the ID segments through a special LOADR option - thanks to Dave Bryan for the tip about this. Below is the output of that on my system;
NAME TY PRIOR LMAIN HMAIN LO BP HI BP SZ EMA MSEG PTN TM COM S-ID
PRMPT 1 1 26000 26532 4 11 NC
D.RTR 1 1 26532 46655 11 257 NC
R$PN$ 2 1 24000 24760 2 14 2 PE NC 0
LGTAT 2 10 24000 26272 2 55 3 PE NC 0
T5IDM 2 10 24000 35450 2 220 6 PE NC 0
WHZAT 2 2 24000 30605 2 150 4 PE NC 0
,,,,, 3 99 24000 30136 2 226 4 PE NC 0
FMGR 3 99 24000 32367 2 112 14 PE NC 0
HELP 3 99 24000 32576 2 103 5 PE NC 0
LUPRN 3 99 24000 51500 2 422 12 PE NC 0
LOADR 4 99 10000 41062 2 1274 28 PE NC 0
EDIT 4 51 10000 30722 2 604 28 PE NC 0
RT4GN 4 90 10000 32351 2 473 28 TE NC 0
FMG01 3 99 24000 32367 2 112 14 TE NC 0
ALGOL 3 99 24000 37530 2 466 15 PE NC 0
FMG10 3 99 24000 32367 2 112 14 TE NC 0
TG00S 5 24401 26543 265 335 TE
TG01S 5 24401 26201 265 333 TE
TG02S 5 24401 26124 265 322 TE
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
<LONG BLANK ID>
FMGR0 5 32367 44036 112 377 PE
FMGR1 5 32367 45035 112 513 PE
FMGR2 5 32367 45504 112 630 PE
FMGR3 5 32367 43553 112 322 PE
FMGR4 5 32367 42744 112 426 PE
FMGR5 5 32367 36217 112 255 PE
FMGR6 5 32367 44600 112 510 PE
FMGR7 5 32367 43611 112 277 PE
FMGR8 5 32367 43477 112 365 PE
FMGR9 5 32367 43477 112 274 PE
FMGRA 5 32367 44604 112 404 PE
FMGRB 5 32367 45046 112 424 PE
EDIT0 5 31324 52607 604 1234 PE
EDIT1 5 30722 50141 604 1115 PE
EDIT2 5 33111 44043 604 1046 PE
EDIT3 5 30722 36572 604 760 PE
EDIT4 5 30722 40617 604 1113 PE
ALGL1 5 37530 40174 466 471 PE
F4.0 5 27356 33326 574 754 TE
F4.1 5 27356 34150 574 755 TE
F4.2 5 27356 30355 574 632 TE
F4.3 5 27356 31645 574 715 TE
F4.4 5 27356 34270 574 766 TE
F4.5 5 27356 33254 574 734 TE
ASMB0 5 24425 32310 437 571 TE
ASMB1 5 24425 26663 437 571 TE
ASMB2 5 24425 26555 437 537 TE
ASMB3 5 24425 25352 437 454 TE
ASMB4 5 24425 25755 437 454 TE
RT4G1 5 33200 34547 473 570 TE
RT4G2 5 33200 36700 473 733 TE
RT4G3 5 33200 37143 473 1052 TE
RT4G4 5 33200 36301 473 751 TE
RT4G5 5 33200 36576 473 753 TE
RT4G6 5 33200 36326 473 734 TE
RT4G7 5 33200 36334 473 612 TE
RT4G8 5 33200 34045 473 541 TE
SWSG1 5 41542 42647 547 612 TE
SWSG2 5 41542 47313 547 675 TE
BASC1 5 15634 21524 211 462 TE
BASC2 5 15625 26003 211 433 TE
BASC3 5 15635 22215 211 503 TE
BASC4 5 15626 30427 211 1007 TE
BASC5 5 15644 26347 211 567 TE
BASC6 5 15644 23515 211 503 TE
BASC7 5 15646 23105 211 455 TE
BASC8 5 15625 21352 211 424 TE
17 FREE LONG IDS, 0 FREE SHORT IDS, 10 FREE ID EXTS
/LOADR:$END
The in memory entries are at the top, then the disk based ones are listed with either PE for permanent or TE for temporary. The TE entries were made by the /xxxxx files that issued :RP commands or by RUN,xxxx that copied from the type 6 files, while the PE entries were either loaded with the PE option or created during system generation.
The LGTAT utility program will identify disk space used both for permanent and temporary code that exists without a file name in the directory. Only the system (and optional auxiliary) cartridge can hold the system and the non-file disk based programs. Below is the output of that program on my system.
TRACK 0 1 2 3 4 5 6 7 8 9
0 SYSTEM SYSTEM SYSTEM SYSTEM SYSTEM SYSTEM R$PN$& WHZAT& FMGR & FMGR1&
10 FMGR2& FMGR3& FMGR4& FMGR5& FMGR7& FMGR8& FMGR9& FMGRB& HELP & LUPRN&
20 LUPRN& LOADR& LOADR& LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY
30 LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY
40 LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY
50 LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY LIBRY ENTS
60 ENTS D.RTR EDIT & EDIT & EDIT0& EDIT1& EDIT1& EDIT3& SYSTEM ALGOL&
70 ALGOL& -- -- -- -- -- -- -- -- --
80 -- -- -- -- -- -- -- -- -- --
90 -- -- -- -- -- -- -- -- -- T5IDM^
100 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
110 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
120 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
130 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
140 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
150 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
160 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
170 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
180 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
190 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
200 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
210 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
220 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
230 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
240 FMP FMP FMP FMP FMP FMP FMP FMP FMP FMP
250 FMP FMP FMP FMP D.RTR
We can see from the listing above that I have a few permanent programs on the disk:
- EDIT and its segments (different from EDITR which is a type 6 file)
- D.RTR
- ALGOL
- T5IDM
- FMGR and its segments
- WHZAT
- LOADR
- R$PN$
- HELP
- LUPRN
These persist from boot to boot. Some memory resident programs exist but won't be seen on the disk, for example PRMPT which issues the prompt to any online terminal and schedules the disk resident program R$PN$ to process the commands. There are no temporary programs on disk in this view,
but after I loaded the KEYS program with the LOADR, this is the relevant snippet of the LGTAT listing.
60 ENTS D.RTR EDIT & EDIT & EDIT0& EDIT1& EDIT1& EDIT3& SYSTEM ALGOL&
70 ALGOL& KEYS & KEYS & -- -- -- -- -- -- --
80 -- -- -- -- -- -- -- -- -- --
90 -- -- -- -- -- -- -- -- -- T5IDM^
We can see that KEYS is loaded here and also has a temporary ID segment allocated to it. If I were to issue a RUN,KEYS it would be executed, but a DL,KEYS won't show any file named KEYS in the directories of any online cartridge.
ENTER ONE OF THESE FUNCTIONS: [CREATE,MODIFY,OUTPUT,LIST]
OR PRESS [RETURN] TO TERMINATE THIS PROGRAM:
The command :OFF,KEYS releases the temporary ID segment and also freed up the disk tracks holding the program. Having previously issued a :SP,KEYS command, I first had copied the code to a type 6 file named KEYS. Now, issuing RU,KEYS will first check the ID segments, then find the type 6 file and create the ID segment before running the program again.
I then turned to installing the PASCAL compiler and runtime system. It would be the last of the languages and utilities I needed on my system. Unfortunately for me, I ran into a snag. One of the three parts of PASCAL to be generated (the PCLF loader file) takes up so many entries as it builds the temporary code that I run out of segment ID entries in the system.
I may have a temporary solution, however. I would need to blow away some of the temporary programs in the non directory area, then do the LOADR of PCLF, then get back those programs. I create many ID entries by running the /progname files from WELCOM, to convert type 6 files into temporary entries.
Since I only need to run the LOADR and FMGR to accomplish the generation of the PCLF program entries, I can strip out all the other temporary files manually. FTN4 or other programs that depend on this will no longer run until I reboot or rerun the :RP commands, but I won't need them until I reboot.
All that done, I reran the LOADR to generate from the PCLF file. Now, with enough ID segment space, I ran out of disk space. That is, the 28 tracks available on the system cartridge aren't large enough for all the code that will be stored temporarily during the LOADR session.
The solution is to blow away my system cartridge 002 and rebuild it with the directory located at a higher track number, leaving more temporary space. At first I thought I would have to recreate pretty much every program if I did that, a task not worth contemplating as it would be a many many hours of work.
Instead, I discovered that the :IN command could reinitialize the director in a new space, leaving all the contents below the directory untouched. What I did to accomplish this was:
- Copy all files on 00002 to the SC cartridge using :CO command
- Remove all the temporary ID entries pointing to the disk using :OFF commands
- Reinitialize with :IN,mpw,-2,00002,SYSTEM,150,2 where mpw was my master PW
- Copy all files from the SC cartridge to the new empty 00002 cart using :CO
I then reran the PASCAL step PCLF to generate the many segments of PASCAL, now that I had plenty of scratch space and lots of unused ID segments. Once it was complete, I converted all the entries it had created as temp ID segments into type 6 files, wrote a /PASCAL file to issue :RP for all overlays, and killed off the superfluous temp segments with :OFF commands.
I tested PASCAL, which worked fine, then modified my WELCOM file to run /PASCAL and rebooted as a final check. The compiler works fine. I entered a test program and ran it successfully as well. The last test was to update the WELCOM file and reboot.
ARRGH. So close. I forgot to save one of the 20 segments of PCL as a type 6 file, therefore after the reboot I no longer had a working PASCAL environment. I shall have to go through the entire regeneration of the PCLF portion again, save just that one file, and then I will be back in business.
Another thing I learned is that PASCAL can't be loaded (via a startup file with :RP statements) because the 20 segments on top of everything else in the system will exhaust the pool of ID segments. Instead, I have to run a file to unload BASIC segments and load PASCAL in order to use it, then reverse out the PASCAL after I am done.
The longer term solution would be to generate many more ID segments into the RTE system. I will put that on hold for a later system generation effort.
No comments:
Post a Comment