Working with RTE IV B
I finally got the ALGOL compiler working properly, again with aid from Dave Bryan. The compiler is an older product that worked with DOS and earlier RTE operating systems. In those days, compilers read and wrote directly to logical units, to peripheral devices, and not to files on disc.Apparently they way that compilers worked in the past versions required different commands which are not documented in the mainstream parts of any of my manuals. Dave pointed me at Appendix D of one book which is the only place these are mentioned.
The :LS command creates a temporary area on a disk cartridge (partition of a disk) for logical source files. The :MS command is one way to copy the contents of a file into this termporary area. The :LG command creates a temporary area for the binary output to reside. The :SA command is one way to copy the contents of the temporary binary area to a disk file.
With a modern compiler like Fortran, I can convert a source file &PROG to a relocatable binary file %PROG with this command: RU,FTN4,&PROG,1,%PROG where FTN4 is the compiler name, as a convention files starting with & are source and files starting with % are relocatable binary. The 1 is the logical unit number of the terminal where I was typing. The command specifies input file, listing device and output file.
With ALGOL, I had to start by moving my source code to the logical source temporary area on disk with :MS,&TEST,ALGOL and identify that the temp area is associated with the program ALGOL (the compiler). I also issue a :LG,5 to create a five track temporary binary area.
Then, the actual compile uses logical unit 2 to point to disk (that is the boot disk drive logical unit), LU 1 to deliver the listing to my terminal, and 99 to indicate the logical binary file on disk. The command is :RU,ALGOL,2,1,99 and after it runs, my relocatable program is in the LG area.
I then do a :SA,LG,%TEST to save the output binary as a file %TEST. Now I can deal with it the same as the output of any modern compiler. That is, I have to use the LOADR program to convert the relocatable into an absolute binary file that can be executed.
The output of the LOADR is a executable file, named TEST because my source program used that name, which is pointed to by a temporary ID in the OS. Confusingly, it doesn't show up as a file in any disk cartridge, but a :RU,TEST will execute it.
I could have used the :SP,TEST command to copy the temporary TEST file to a disk file of type 6 (abs binary) named TEST, which would allow it to show up in disk cartridge listings and persist across a boot of the OS. Alternately, one could give the LOADR and option PE to make a file permanent, although it still doesn't show up in any disk directory listing.
I have much to learn about RTE, clearly, but each adventure moves me a tad further along that journey. I do plan to look for other compilers and interpreters - activating the PASCAL and BASIC software I already have on the disk, as well as finding languages like C or SNOBOL.
I did find a tape that contains the C/1000 language. It is in a tape format that can only be read by utilities supported under RTE 6/VM, a newer version that the RTE IVB I am using currently. I have to conclude that I can't support C on the current OS.
My current system already has PASCAL/1000 and BASIC/1000. The search for SNOBOL failed - I thought I had come across that in some listing of software but it isn't in the bitsavers master file list. I spent the morning getting PASCAL working. It was quite a fight, as the LOADR kept running out of disk space and I wasn't quite sure how to control that.
I was attempting to build a version of RTE IVB that supported the multiplexer to use the simulator MPX device and have two terminals open, but it pushed some areas over the memory limit and produced almost a thousand errors during generation. I would have to look through it carefully and figure out how I can change the input file to resolve the issues.
However, the essential fact is that I only wanted to solve the dual terminal issue under the simulator for convenience, to see the same operation as with the real machine. The burden of doing so is too high for right now, thus I will simply generate my system with twin BACI cards and accept the limit under the simulator that only one can be active.
Diagnosing bad 12966A BACI card
It was time to bring out the big guns - the logic analyzer and scope - to figure out how this card is stepping on other I/O activities. I pulled up the schematics and identified 32 points I could monitor that are specific to this board. In many cases, if I could isolate the driving signal just before the line driver 8T13 chip, then I wouldn't be seeing the line pulled down by any other card since the bus is shared.
The 8T13 chip has each driver set up as a pair of dual input AND gates combined with an OR gate before the actual driver. Since these connections are all internal to the chip, the best one can do is watch the four input lines to see when A●B+C●D is true.
For the first pass, I hooked up the 12 most likely signals, using micrograbbers on the IC pins, to use with the first 16 signal probe set on my logic analyzer. I have ground and the signals wired, but need to fine another location where I can pull off the system clock of the HP 1000. The logic analyzer works best when clocked by the system, less so with what it thinks are async signals.
No comments:
Post a Comment