QUICK CHECK OF POWER SUPPLY HEALTH AND VOLTAGES ON 1130
Once the L6-20 outlet for 240V was available, I ran a set of checks on the various power supplies in the 1130 to be sure that it was ready for powering on. This consists of unhooking the output of the supplies from the cables that carry those voltages to the logic gates, bringing up the supplies and testing voltages.
The 1130 does its own testing of power correctness as part of the power sequencing, done with relays and testing circuits. The machine was happy with the health of the +3, +6, -6 and other outputs, thus it brought them online serially until it was complete. I too found the outputs to be right on the money.
POWERING UP ALL APPEARS HEALTHY
After connecting all the cables back to the supplies, I plugged in the 1130 and flipped the Power On/Off switch on the console. The machine came up happy, at least to a stopped and reset state. Until I wire up the light panel I can't see the important status to be sure it is working well, but no red flags arose.
BOXED UP COMPLETE DMS V2 M12 LOAD/RELOAD CARD DECK FOR SALE
The complete set of cards to load a fresh disk cartridge with DMS V2 M12 including both Fortran compiler and Assembler takes approximately 3,000 cards. I put them in three mailing boxes, around 1,000 cards each, and got the vital statistics to calculate postage. Each box is 8 1/4" wide, 7 1/2" deep and 3 1/2" high. The weight for all three together is 15.4 pounds.
 |
| DMS V2 M12 Load Deck |
This deck consists of a sequence of card files:
- one card 1130 boot loader card that will read the next card into core and execute it
- one card 1800 loader card which is executed to read the binary format of the next file
- multi card loader deck that will begin reading in the actual system loader program
- first phase of the system loader program
- a load mode card that specifies whether this is Initial or Reload and the compilers to include
- the resident monitor that manages the hardware
- the second phase of the system loader
- configuration cards that specify I/O devices and core size
- phase ID cards that tell the range of phase numbers for each component
- phases for the Disk Utility Program (DUP)
- phases for the Fortran compiler
- phases for the supervisor
- phases for the core load builder
- phases for the I/O devices
- phases for the core image loader
- phases for part II of DUP
- phases for the macro assembler
- type 61 card to end system loading
- all the key system library routines set up as DUP commands to store from card to UA
A fresh cartridge is placed in some disk drive, the console switches are set to indicate which drive number contains the target cartridge, the card deck is placed in the reader hopper, the reader is readied and then the operator hits the Program Load button.
The deck is read and its contents are placed on the cartridge to prepare it as a DMS V2 M12 pack. When the type 61 card is reached, the system loader completes its work and it loads the resident monitor and invokes DUP. DUP then reads the remaining deck which is a series of *STORE commands and object deck pairs to build up the required system library routines in the new User Area of this system pack.
The process completes and you can then use this cartridge to operate an IBM 1130. The operator puts a one card Cold Start loader in the card reader, readies the card reader and the disk drive, then hits Program Load. The result is the booting of the monitor, an implicit JOB card is processed and some output appears on the line printer. The system waits for card decks to be placed in the reader and the Start button to be pushed to begin batch processing.
I tested this deck on the IBM 1130 simulator. I used the standalone Disk Configuration and Initialization Program (DCIP) to format a disk cartridge image as a fresh pack. I loaded the deck into the card reader, did a boot from the card reader and watched the process run to completion. On a PC this runs much much faster than it would with a real 1130 and its peripherals. I then booted the disk and ran some work.
NARROWING DOWN THE SEARCH FOR THE DEFECT IN IBM 1130 SIMULATOR
The IBM 1130 Simulator built by Brian Knittel in part upon the simh platform is a great tool to run 1130 workloads and try out software. However, it has two well known issues that impair its full usability. One is a loop when trying to store a core image file and the other is a loop punching blank cards.
If a job issues a DUP command to store a file as a core image format (*STORECI), the 1130 system goes into a perpetual loop, never completed nor storing the file. The FORMS CHECK light is illuminated, which is an error because that lamp means that the console typewriter has run out of paper. There is no reason that this should occur at this point.
Jobs that punch cards will punch some correctly and then settle into a loop punching completely blank cards until you reset the simulated 1130. This one is a bit more understandable because the simh handling of card reader and card punch as independent peripherals does not reflect the physical reality in most 1130 shops. Most use the 1442 card reader/punch, which has a single input hopper and single path that handles both reading and punching.
In the physical world, if you have a program that will punch some cards, you have to put the correct number of blank cards (or more) in the hopper at the appropriate point in the deck being read. Failure to get this right can result in lacing cards by punching new content atop existing holes for cards you intended to read. The 1442 simulation does not address this in accordance with the real machine, nor does it model the way the machine works even for pure reading.
When you put cards into an empty 1442, you push the start button and one feed cycle is taken to move the card into the machine at the station just before the read photocells. The next feed cycle, taken when the processor does a read, will move the card through the photocells and simultaneously feed the next card from the hopper to the preread station.
When the hopper is empty, the machine switches off ready state. The processor sees this as a not-ready reader. The final card that was in the hopper has NOT yet been read, it is simply sitting in the pre-read station. If there are more cards involved in this batch, you add them to the hopper and push Start on the reader. That makes it ready to the processor and reading continues.
If this is indeed the end of a deck and no additional cards will be added, then the operator pushes the Start button while the hopper remains empty. This allows the final card to be read but also provides a 'last card' or 'end of file' flag to the processor.
The 1130 simulator does not model this behavior. Instead, the final card is read without any action pushing a simulated Start button on the reader. That means that when a card file finished on the reader it always sends the last card flag. This makes it hard to add more cards without that status. There is a 'deck' construct in the simulator where it takes a file which in turn lists file names to put in the read, each of which is added without 'last card' flags until the final file of the deck is read.
If you couple this behavior with the reality that after the read station there is a pre-punch stop, then a feed is needed for the card to move to the final stacker, the mismatch with the physical world gets worse. After reading the final card of a deck, accepting the 'last card' state, the operator would have to push the NPRO (non-process runout) button to move the last card from pre-punch to the stacker.
For punching, after you read a final card such as // XEQ to run a program which is going to punch, something has to move that last card, the XEQ, past the pre-punch station before you begin writing (punching) card images. Then there must be sufficient blank cards following so that each write to the punch has a blank card in the pre-punch station ready for it. None of this is modelled by the simulator.
I needed to be sure that the errors, particularly the loop running the *STORECI, was not due to mangled contents of the DMS image that came with the simulator. Brian did a herculean job creating that by entering all the source cards for all of the monitor, assembling every module, then preparing them in the proper format to create the load deck described above. However, it is possible that some error crept in that is the root of this loop.
To test that, I took the load deck which I had read from my cards and used that to build DMS on a fresh cartridge. This disk was booted on the 1130 simulator but I still saw the two issues, *STORECI looping and a blank card punching loop. This tells me the issue is in the simulator itself and not the DMS.
I now have to figure out a means to debug this and fix it, in order to have a completely usable simulator. More in the future on this.
No comments:
Post a Comment