Working with RTE IV B
I downloaded the Algol compiler with the aim of adding it to my system. It would be great to have as many languages as I can find. I have assembler, Fortran and BASIC, with some chance that I also have Pascal. Adding Algol and any others that were available are just icing on the cake.
I do need to work out a transfer means between a PC file and the simulator. I think I should generate a paper tape reader into the system just to allow me to mount the file as a tape and transfer it in. Ah, yet another system generation, although I can dump the file to virtual tape on the special system and then pull it back into my good system image.
After bashing around for quite a while, I had a paper tape reader, with the relocatable code file attached, but was unable to figure out any way to transfer it into my system. I know how to boot absolute binary code from the device, but what I wanted was to read in the PTR file into a disk file.
Next I guess I will figure out how to convert the file into a simh mag tape format, mount it on the 7970 tape drive in the simulator and try to read it in that way. It will be a project for another day.
I received some help from Dave Bryan, who confirmed that the simulator will not work with two BACI boards configured. He does believe that I should be able to get the version with one BACI and one MPX board operational, although we are still exchanging emails about what incantations and sequences are required. Still, good to know my suspicion was correct and the simulator cannot host more than one instance of any device type.
I have a detailed cookbook to get the MPX virtual device working under the simulator - while it is more complicated and different from my real hardware installation, I can build a common system that will boot on either the HP 1000 or the simulator.
The MPX (12792C 8 channel multiplexer card) needs several drivers and additional equipment table and logical unit entries, before I can use the :CN and :CT configuration commands to get it active. I planned out my system generation for later execution.
Diagnosing bad 12966A BACI card
I need to set up a more useful testbench to work on this card. Right now I am using alligator clips, an extender board, and a few power supplies. What I will need to be doing to further test this is to inject various signal combinations on the inputs while watching the state of all the logic gates affected by them.
Fortunately, the -2V bias voltage for inputs makes all of them a valid 0 value when open, thus I only need to inject a logic 1 by applying a positive voltage level to a pin. I can use my micrograbbers hooked to scope probes for watching outputs of gates.
The failure mode is certain to be a case of an output being switched to 1 when it should not - the board is not selected. Where that occurs is the big question.
My first blush shows that the board is not selected when all the three selection inputs (SCL, SCM and IOG) are low. However, it may be that it will select when only some of those are high, whereas it should act like an AND function. That would be an easy problem to find and correct, with the improved testbench.
However, the testing proved that the selection logic is working properly, only activating if all three inputs are high. I therefore have to work back to check every gate for proper operation. This will be tedious but ultimately if I can push all gates through all their combinations I should be able to find the bad part(s).
The next test was to check that all the gates which should block incoming signals while the board is not selected are working properly. I had to use quite a few micrograbber clips and alligator clips to manage all the inputs, outputs and power to be covered plus I bought an 86 pin .156" connector to wire up power and key signals.
My test showed that all inputs which are gated by the selection logic (SCH⚫SCL⚫IOG) will be blocked unless the selection is active, at which point they work properly. The tested input signals:
- IOO
- IOI
- SFS
- SFC
- CLC
- STC
- STF
- CLF
There are a number of inputs which are not gated by selection logic:
- PRH
- IEN
- ENF
- SIR
- IAK
- T3
- POPIO
- CRS
- IOB15
Testing the above set of inputs is more complicated, constituting much of the interior logic of the board. The sequences that should trigger various latches to set or reset inside the machine are complex, thus I can't cover all of that until I have exhausted all the easier testing.
The next set of signals to test are easy - the three signals that individually can command a reset of the board. If POPIO, CRS or IOB15 are 1, the board will reset. POPIO is a power on or preset key rest, the high bit of the IO word is a software means to request a reset, and CRS is driven by a CLC instruction requesting a reset.
There are four chips involved in generating the reset signals, which I will test out in this round of checks. Once I know the reset is properly generated, I will trace it to the various flipflops that are controlled by the reset signals and verify as much as possible that they reset. It may be complicated to first force the FF to switch on, but I will work through that after proving that reset itself is generated.
Stage one was good - when either POPIO or CRS is activated, the reset timer generates a 5 microsecond pulse. I couldn't test IOB bit 15 because it is gated by some status of a flip flop, probably one that means IO is in process. Since I was not using the card when it jammed up IO activity for other cards, we are not dependent on that function and can neglect it for now.
Stage two will be to look at where the reset signal is sent and evaluate the health of each gate it controls. At a minimum those gates should sit in the right state after power-on of the testbench and following a reset signal. Any that are in the wrong state after reset are a problem, but that doesn't fully test out this functionality. Unless I can set each FF to its opposite state before issuing the reset, I can't confirm that reset functions as it should.
The FFs I checked and their state after reset are:
- Lockout - switched on
- SRQ - off
- IRQ - off
- Flag buffer - off
- Control - off
I then looked at the Flag FF, driven by the one I checked, and it is correct. I checked the priority encoding logic (if PRH from a higher priority card is active (0 logic level) or the BACI card wants to interrupt, then the output PRL is active (logic 0) otherwise it is high. That is properly logic 1 when PRH is 1 and drops to 0 when PRH is down at 0.
As I expected, this is tedious and there is still a lot unchecked on the board. I might have to jump to plan B - logic analyzer covering key FFs and internal states to see if the card, while plugged into the system, ever activates any signal that could affect other I/O in progress. That will take quite a bit of setup. This task is set aside for now.
Downloading software for use with the system
I mined the archives at Bitsavers and downloaded the paper tape master files plus a few key other files, which will give me access to pretty much any software I want that ran on the HP 1000 system. First priority is to figure out how to get Algol onto the system.
I did a byte swap (between the little-endian format used by Windows and the big-endian format for RTE) mounted the file as to the PTR and successfully transferred it into the system, I think. I have a binary file I named %ALGOL but the challenge is to further transform it into a command I can run.
I attempted to use the LOADR and asked for the %ALGOL as a REL file, but the program aborted with an illegal record error. The file is not formatted as a relocatable image. If it is a binary file, I must have read it in with the wrong parameters.
Dave Bryan straightened me out about the problem I had with Algol. The file I had was an absolute binary, the wrong kind to use with RTE. Bryan pointed me to the correct files and the sequence of steps I will need to install the compiler. With it installed, my test programs are not compiling - receiving error right at invocation of the compiler as it reads the first line.
No comments:
Post a Comment