Monday, November 30, 2015
In London on business and pleasure
I am in London working through Wednesday then visiting TNMOC in Bletchley before I fly home at the end of week. Not much time (or opportunity) to work on 1130 related things.
Friday, November 27, 2015
Scanning DMS V11 load decks
Still trying to recover from my cold before I fly off to London tomorrow, but I did spend a few minutes on the 1130.
SYSTEM LOAD DECK RECREATION
I brought the rest of my DMS R2 V11 deck out to the card reader to try to read them all in. Some of the sections of the deck are in rough condition, thus causing problem during the reading. I completed the deck up through the FORTRAN compiler phases, then read about half of the COBOL compiler phases before I packed it in.
The COBOL phases do not have header cards and do not appear to participate in the Reload Table scheme at all. The only phases for which I am still missing a header card are 74 and the RPG compiler set I don't yet know if the RPG compiler uses header cards or omits them as COBOL did.
I am building up virtual card drawers for both V2 M11 and V2 M12 with all the phases and other decks needed for system load operations.
SYSTEM LOAD DECK RECREATION
I brought the rest of my DMS R2 V11 deck out to the card reader to try to read them all in. Some of the sections of the deck are in rough condition, thus causing problem during the reading. I completed the deck up through the FORTRAN compiler phases, then read about half of the COBOL compiler phases before I packed it in.
The COBOL phases do not have header cards and do not appear to participate in the Reload Table scheme at all. The only phases for which I am still missing a header card are 74 and the RPG compiler set I don't yet know if the RPG compiler uses header cards or omits them as COBOL did.
I am building up virtual card drawers for both V2 M11 and V2 M12 with all the phases and other decks needed for system load operations.
Thursday, November 26, 2015
Finding and reading in real decks to complete system load files
SYSTEM LOAD DECK AND CART RECREATION
I ran a reload of the phases I had in a card tray that came with my 1130 system, which are the DMS R2 V12 reload that runs against a full V11 system to create a V12 disk. These phases, real card decks from my system, were reloaded atop the virtual disk cartridge that comes with the IBM 1130 simulator.
Brian Knittel had painstakingly recreated the virtual decks by assembling the decks from a source tape and listings, but this test would let me know if there were any discrepancies on disk from my phases. I did a reload of my decks and then a sector by sector compare with DCIP. I found that one of my decks, phase08, was not a complete set of cards. It was missing some cards and therefore was shorter in my deck than in a real system. That threw off the rest of the system.
I retrieved the phase 08 deck and reread it, ensuring I had a complete deck, then redid the reload of my phases. I will iteratively do this until I ensure the correctness of both my real deck files and the simulator virtual cartridge Deck 08 was repaired but the work continues.
In a related project, I began reading in my DMS R2 V11 card files, where I should find all the phases that were not included in the V12 reload decks. There are 31 phases that were not changed in V12, thus not included in the reload. I obtained them all and completed a full set of load decks.These also contain the header card text I was looking to capture for my utility program, thus allowing me to produce accurate header cards.
Now I have several 'editions' of disk cartridges I can cross check to validate everything. I have the virtual cartridge from the 1130 simulator, the recreated phases I produce from a live disk cartridge with my utility programs turned into a virtual cartridge, and the real decks from my 1130 system turned into a virtual cartridge. To the extent that everything compares exactly, I can be confident we all have a true and faithful version of DMS2 V12 everywhere.
I grabbed the DUP portion of the R2 V11 deck in my trays and found that it had all the phases, so that it appears to be a complete initial load version, including RPG, FORTRAN, COBOL and the rest of the system.. All phases that aren't updated in V12 will come from here.
Turns out I have access to all the official header cards and all the official object decks. My utility program wasn't actually needed, although it will be a good cross check against any real cartridges I have and against the virtual cartridges from the IBM1130.org site. The process of building and testing the utility reminded me (or taught me) a lot about the 1130 software stack.
I ran a reload of the phases I had in a card tray that came with my 1130 system, which are the DMS R2 V12 reload that runs against a full V11 system to create a V12 disk. These phases, real card decks from my system, were reloaded atop the virtual disk cartridge that comes with the IBM 1130 simulator.
Brian Knittel had painstakingly recreated the virtual decks by assembling the decks from a source tape and listings, but this test would let me know if there were any discrepancies on disk from my phases. I did a reload of my decks and then a sector by sector compare with DCIP. I found that one of my decks, phase08, was not a complete set of cards. It was missing some cards and therefore was shorter in my deck than in a real system. That threw off the rest of the system.
I retrieved the phase 08 deck and reread it, ensuring I had a complete deck, then redid the reload of my phases. I will iteratively do this until I ensure the correctness of both my real deck files and the simulator virtual cartridge Deck 08 was repaired but the work continues.
In a related project, I began reading in my DMS R2 V11 card files, where I should find all the phases that were not included in the V12 reload decks. There are 31 phases that were not changed in V12, thus not included in the reload. I obtained them all and completed a full set of load decks.These also contain the header card text I was looking to capture for my utility program, thus allowing me to produce accurate header cards.
Now I have several 'editions' of disk cartridges I can cross check to validate everything. I have the virtual cartridge from the 1130 simulator, the recreated phases I produce from a live disk cartridge with my utility programs turned into a virtual cartridge, and the real decks from my 1130 system turned into a virtual cartridge. To the extent that everything compares exactly, I can be confident we all have a true and faithful version of DMS2 V12 everywhere.
I grabbed the DUP portion of the R2 V11 deck in my trays and found that it had all the phases, so that it appears to be a complete initial load version, including RPG, FORTRAN, COBOL and the rest of the system.. All phases that aren't updated in V12 will come from here.
Turns out I have access to all the official header cards and all the official object decks. My utility program wasn't actually needed, although it will be a good cross check against any real cartridges I have and against the virtual cartridges from the IBM1130.org site. The process of building and testing the utility reminded me (or taught me) a lot about the 1130 software stack.
Tuesday, November 24, 2015
System Load Deck utility working perfectly now
RESTORING SYSTEM LOAD DECK AND CARTRIDGE
I have fixed the issue with formatting for the phases that have reload table entries and get apparently good results doing a reload of a couple of phases. However, comparing the disk sectors still shows that the contents of the sector don't match after the first 45 word card is punched.
It looks like I am picking up random data rather than the remaining content of the sector. The cause was the CARD0 library routine, which corrupted index register 1 during its execution. I saved the register around the library call and got an almost perfect match of the disk sectors between the original source version and the version reloaded by my program.
The problem is in the last word of the sector - I see an extraneous word on the new version. This is another of those nuance issues - where the way the last card of a system load deck should be produced. It has to do with how the SLET entries interpret the starting core address and number of words. I studied examples of decks for a while in order to lock in my spec for the utility program.
I ran a large batch of phases, about 90, through the reload process which finished normally. However, since the last word or so of each phase is not correct, the disk did not boot up and work properly. This is understandable. I am still working on getting what seems to be the last issue for my utility corrected
Once I had resolved those problems, I did a partial reload and had the system boot up fine. I am going to set up an initial load of a 'fresh' cartridge and then do a sector by sector comparison of the disk, checking for any discrepancies. That will be the acid test for the correctness of the decks built by my utility program.
I ran the large reload again and did a DCIP utility disk compare, which found zero discrepancies on the system phase sectors 8 to F5 where my reloaded modules sat. I had to make a quick fix to the utility to spit out the phases without the 9s separator cards, so I can use the large file to do a full initial load of the system.
That fix done, I created my all phases deck and did a reload to validate it all before moving to the new cartridge. Then I used the DCIP utility to initialize a fresh cartridge and ran an initial system load using my generated phases. It worked perfectly! DCIP did a disk compare and the sectors holding the system phases (0008 to 0139) are a perfect match - SLET, Reload Table and all the phases themselves.
I am very pleased and can now use this tool for a number of interesting things.
I also discovered the documentation that came with the DMS2 V12 decks - which shows that the phases which are missing in my collection were never shipped. They are phases that didn't change in V12, so they may be sitting in the DMS2 V11 decks. The distribution cartridge would not have been a V12 version, thus the decks I have are applied as a reload atop a V11 system.
My card trays have an R2 V11 deck, which on a quick investigation appears to have the first DUP phase (01) which was missing from my V12 deck. The documentation for V12 shows that DUP phase 01 did not change for the new version. Its header card has an earlier assembly date, while V12 is 11/06/73 for all the V12 phases.
I have fixed the issue with formatting for the phases that have reload table entries and get apparently good results doing a reload of a couple of phases. However, comparing the disk sectors still shows that the contents of the sector don't match after the first 45 word card is punched.
It looks like I am picking up random data rather than the remaining content of the sector. The cause was the CARD0 library routine, which corrupted index register 1 during its execution. I saved the register around the library call and got an almost perfect match of the disk sectors between the original source version and the version reloaded by my program.
The problem is in the last word of the sector - I see an extraneous word on the new version. This is another of those nuance issues - where the way the last card of a system load deck should be produced. It has to do with how the SLET entries interpret the starting core address and number of words. I studied examples of decks for a while in order to lock in my spec for the utility program.
I ran a large batch of phases, about 90, through the reload process which finished normally. However, since the last word or so of each phase is not correct, the disk did not boot up and work properly. This is understandable. I am still working on getting what seems to be the last issue for my utility corrected
Once I had resolved those problems, I did a partial reload and had the system boot up fine. I am going to set up an initial load of a 'fresh' cartridge and then do a sector by sector comparison of the disk, checking for any discrepancies. That will be the acid test for the correctness of the decks built by my utility program.
I ran the large reload again and did a DCIP utility disk compare, which found zero discrepancies on the system phase sectors 8 to F5 where my reloaded modules sat. I had to make a quick fix to the utility to spit out the phases without the 9s separator cards, so I can use the large file to do a full initial load of the system.
That fix done, I created my all phases deck and did a reload to validate it all before moving to the new cartridge. Then I used the DCIP utility to initialize a fresh cartridge and ran an initial system load using my generated phases. It worked perfectly! DCIP did a disk compare and the sectors holding the system phases (0008 to 0139) are a perfect match - SLET, Reload Table and all the phases themselves.
I am very pleased and can now use this tool for a number of interesting things.
- Reload the simulator disk cartridge with the phase decks I read from my own card decks that came with the 1130 system. That might uncover discrepancies which would warrant investigation.
- Create the decks as input to the UCART utility which will build a distribution cartridge that will mirror the way an 1130 owner would receive the DMS2 system from IBM.
- Recreate phase decks from the cartidges I received with my 1130, since they have all the compilers (RPG, COBOL and FORTRAN)
I also discovered the documentation that came with the DMS2 V12 decks - which shows that the phases which are missing in my collection were never shipped. They are phases that didn't change in V12, so they may be sitting in the DMS2 V11 decks. The distribution cartridge would not have been a V12 version, thus the decks I have are applied as a reload atop a V11 system.
Monday, November 23, 2015
Moving forward with system load deck and cartridge recreation
As I remain in the throes of a nasty cold, I don't have much energy to expend and mostly spend it in front of a PC instead of out with the 1130 system. I am trying to get better before my two weeks of travel beginning on Saturday, where I will be forcefully separated from the 1130 and related gear.
SYSTEM DISTRIBUTION DECK AND CARTRIDGE RECREATION
I continued with testing, working to get the object decks I punched from the utility program work properly with a system load initialization or reload for DMS2. From time to time I discover some nuance of how the decks are configured for system load, but mostly I am cleaning up subtle defects in my code.
As an example of nuances, I first determined that the output of a deck should start at its beginning address, with a specific pattern identifying where in the module the loader should update the code with the SLET entries which this module will call. However, some decks have these entries and thus are covered by the Reload Table. The module helps build the reload table entry with these beginning words. Other modules don't refer to any entries so I have two styles of beginning card to produce, either two or four words long.
At this point, phases that don't have a reload table entry are loading without error, but I have a minor flaw in the logic for the other module type. Also, when I do a word by word comparison of the original sector and my reloaded version, I see that something is awry in my 'stepping' logic for advancing through the words of the sector and produce load cards.
SYSTEM DISTRIBUTION DECK AND CARTRIDGE RECREATION
I continued with testing, working to get the object decks I punched from the utility program work properly with a system load initialization or reload for DMS2. From time to time I discover some nuance of how the decks are configured for system load, but mostly I am cleaning up subtle defects in my code.
As an example of nuances, I first determined that the output of a deck should start at its beginning address, with a specific pattern identifying where in the module the loader should update the code with the SLET entries which this module will call. However, some decks have these entries and thus are covered by the Reload Table. The module helps build the reload table entry with these beginning words. Other modules don't refer to any entries so I have two styles of beginning card to produce, either two or four words long.
At this point, phases that don't have a reload table entry are loading without error, but I have a minor flaw in the logic for the other module type. Also, when I do a word by word comparison of the original sector and my reloaded version, I see that something is awry in my 'stepping' logic for advancing through the words of the sector and produce load cards.
Read in 1130 application deck, continued work on system load process
SYSTEM INIT DECK AND CARTRIDGE RECREATION
I worked on my utility program, painstakingly comparing the cards produced by my program to the cards from the assembly that created the original source disk cartridge. Still not going all the way through the system load process.
I worked on my utility program, painstakingly comparing the cards produced by my program to the cards from the assembly that created the original source disk cartridge. Still not going all the way through the system load process.
READING AND SAVING APP PROGRAM DECK FOR SOMEONE
A person donating an application program to the Computer History Museum wanted it read and an electronic copy sent to him, so I volunteered. It was exactly 1,866 cards which I fed through the Documation reader and converted to IBM 1130 simulator format, verifying each section after reading to eliminate any misread cards.
I have two Documation readers, model 600 and model 1000, but I have only made my hardware modification to the first one. This mod allows cards with the triangular 'cuts' on either the right or left sides to be read correctly. As built by Documation, the reader will get read checks on many cards with a triangle cut on the right side.
It seems that either my reader or my interface to the PC is balky, so that after running through 500 or so cards, it starts getting into wedged states that require me to reset. If I give the gear about 30 minutes to cool down, I can get it back to reading solidly for the next 500 or 600 cards. It wasn't too long until I had them all read in and was ready to do some deck processing.
The decks are split into separate decks, each one job - 21 subroutines, one list of error messages and two mainlines with sample data. Next up was to test these on the 1130 simulator to verify they all compile clean and perform reasonable things when run, after which I can send them to the donor.
A person donating an application program to the Computer History Museum wanted it read and an electronic copy sent to him, so I volunteered. It was exactly 1,866 cards which I fed through the Documation reader and converted to IBM 1130 simulator format, verifying each section after reading to eliminate any misread cards.
I have two Documation readers, model 600 and model 1000, but I have only made my hardware modification to the first one. This mod allows cards with the triangular 'cuts' on either the right or left sides to be read correctly. As built by Documation, the reader will get read checks on many cards with a triangle cut on the right side.
It seems that either my reader or my interface to the PC is balky, so that after running through 500 or so cards, it starts getting into wedged states that require me to reset. If I give the gear about 30 minutes to cool down, I can get it back to reading solidly for the next 500 or 600 cards. It wasn't too long until I had them all read in and was ready to do some deck processing.
The decks are split into separate decks, each one job - 21 subroutines, one list of error messages and two mainlines with sample data. Next up was to test these on the 1130 simulator to verify they all compile clean and perform reasonable things when run, after which I can send them to the donor.
All the decks compiled fine, but the two main programs made use of some subroutines that were not on the 1130 simulator system and not included in his deck. AMAX1, AMIN1, MOD, IDIF, RFRMT and the like. The first three should have come with a cartridge intended for a FORTRAN system,
Sunday, November 22, 2015
Debugging decks from my utility with the System Load process for DMS2
As I landed on Friday, I began sneezing and by the afternoon I was hammered by a strong cold. I only have this week before I head off to London and other places for a couple of weeks, but it is hard to do much work when I am so under the weather.
UTILITY TO BUILD SYSTEM LOAD DECKS AND CART
I discovered that the checksum logic includes a card sequence number in the calculation, something I hadn't included. That caused my decks to be rejected with checksum errors. I modified my code and ran again, until my decks passed muster for checksums.
The next problem I faced was some error that the system loader found in my cards, yielding the highly informative error E02 INVALID RECORD OR BLANK. Since I had no blanks in the deck, it was one of the 39 card images for the phase I was trying to reload. I successfully passed the checksums but now had something awry in my formatting,
As I corrected each issue, I found myself in more subtle difficulties, meaning I was getting very close to passing all the tests in the loader program. The larger question is whether an error free run would generate the exact clone of the data I used as the pattern. I kept at it. The last problem was an incorrect end card minus one, which appears to need to be one word long. There was a simple fix to my program to handle this.
Something is still not right with the last data card, which I will look into further tomorrow.
UTILITY TO BUILD SYSTEM LOAD DECKS AND CART
I discovered that the checksum logic includes a card sequence number in the calculation, something I hadn't included. That caused my decks to be rejected with checksum errors. I modified my code and ran again, until my decks passed muster for checksums.
The next problem I faced was some error that the system loader found in my cards, yielding the highly informative error E02 INVALID RECORD OR BLANK. Since I had no blanks in the deck, it was one of the 39 card images for the phase I was trying to reload. I successfully passed the checksums but now had something awry in my formatting,
As I corrected each issue, I found myself in more subtle difficulties, meaning I was getting very close to passing all the tests in the loader program. The larger question is whether an error free run would generate the exact clone of the data I used as the pattern. I kept at it. The last problem was an incorrect end card minus one, which appears to need to be one word long. There was a simple fix to my program to handle this.
Something is still not right with the last data card, which I will look into further tomorrow.
Saturday, November 21, 2015
Utility to recreate phase decks from system cartridge working properly
UTILITY TO PRODUCE SYSTEM INIT DECK AND DISTRIBUTION CARTRIDGE
I continued testing the code as I flew home, getting it nearly ready to use. By the early afternoon I had a clean run through the first sector of the SLET - phases 01 to 98 - but found a bug in my code to skip the five device entries from 99 to 9D. Once fixed, the utility appeared to punch out all the decks properly, with their header cards and all separated by the 9s cards the way that UCART punches the decks.
I am still missing the text for 31 of the header cards, since I didn't have those phases in my card trays. I will check a few other sources to see if I can capture the missing header cards. Since they are in straight hollerith code, it should be easy to snap a picture of a card to extract the text.
I need a quick small utility to split out the decks into separate files, so that they can be manipulated and used in an initial system load. My first major proof point of this will be to build a scratch disk cartridge on the 1130 simulator and use my deck of cards from the utility to load the disk. Then, I can compare them sector for sector with the cartridge I used as the input to my utility. They should match exactly.
If they do match, then I can run this on the real 1130 with my disk cartridges to capture the accurate object code shipped from IBM, The disk images we have online were recreated from source tapes and listings in a herculean effort by Brian Knittel but may have undiscovered differences due to typos or other transcription errors. This process will validate the total correctness of the simulator disk images.
The major purpose is to build the full system initialization object decks from my systems, including compilers like RPG, Fortran and Cobol, so that I can walk through the steps of system building and maintenance exactly as would have occurred decades ago with real machines and distribution cartridges.
I continued testing the code as I flew home, getting it nearly ready to use. By the early afternoon I had a clean run through the first sector of the SLET - phases 01 to 98 - but found a bug in my code to skip the five device entries from 99 to 9D. Once fixed, the utility appeared to punch out all the decks properly, with their header cards and all separated by the 9s cards the way that UCART punches the decks.
I am still missing the text for 31 of the header cards, since I didn't have those phases in my card trays. I will check a few other sources to see if I can capture the missing header cards. Since they are in straight hollerith code, it should be easy to snap a picture of a card to extract the text.
I need a quick small utility to split out the decks into separate files, so that they can be manipulated and used in an initial system load. My first major proof point of this will be to build a scratch disk cartridge on the 1130 simulator and use my deck of cards from the utility to load the disk. Then, I can compare them sector for sector with the cartridge I used as the input to my utility. They should match exactly.
If they do match, then I can run this on the real 1130 with my disk cartridges to capture the accurate object code shipped from IBM, The disk images we have online were recreated from source tapes and listings in a herculean effort by Brian Knittel but may have undiscovered differences due to typos or other transcription errors. This process will validate the total correctness of the simulator disk images.
The major purpose is to build the full system initialization object decks from my systems, including compilers like RPG, Fortran and Cobol, so that I can walk through the steps of system building and maintenance exactly as would have occurred decades ago with real machines and distribution cartridges.
READING APPLICATION PROGRAM FROM CARDS
The Computer History Museum is receiving a donation of an application program that handles garment designs and plots output on the 1627, but the donor would like a machine readable copy. The deck of cards was shipped to me so that I could read them with my documation card reader and convert them to the IBM 1130 simulator format. The deck is roughly one box of cards, about 2000 punched cards.
Since columns 73 to 80 are sequencing and identification, there are a maximum of 72 characters per card. This deck has just over 140KB of characters, but realistically probably closer to 60K since many cards are much shorter than 72 columns, with spaces taking up all the remaining columns.
The Computer History Museum is receiving a donation of an application program that handles garment designs and plots output on the 1627, but the donor would like a machine readable copy. The deck of cards was shipped to me so that I could read them with my documation card reader and convert them to the IBM 1130 simulator format. The deck is roughly one box of cards, about 2000 punched cards.
Since columns 73 to 80 are sequencing and identification, there are a maximum of 72 characters per card. This deck has just over 140KB of characters, but realistically probably closer to 60K since many cards are much shorter than 72 columns, with spaces taking up all the remaining columns.
Thursday, November 19, 2015
Debugging my utility to produce a distribution cartridge and card decks
DMS2 SYSTEM LOADER AND DISTRIBUTION RECREATION
Although I am away in Austin all this week at a conference, I have used my spare time to walk carefully through the programs I wrote that will build a set of cards decks that are as close to identical as possible to the decks punched out from the IBM Distribution Cartridge. I am fighting flaky punch behavior in the IBM 1130 simulator, but can get the remainder of the logic tested fully even with this problem.
Although I am away in Austin all this week at a conference, I have used my spare time to walk carefully through the programs I wrote that will build a set of cards decks that are as close to identical as possible to the decks punched out from the IBM Distribution Cartridge. I am fighting flaky punch behavior in the IBM 1130 simulator, but can get the remainder of the logic tested fully even with this problem.
Sunday, November 15, 2015
Code development for system distribution utility
I am on a trip in Austin, Texas at the Supercomputing 2015 conference all this week, but will have plenty of open time to code, test and do other 1130 design work. More, in fact, than I have been able to do lately due to demands from my employer.
RECREATING SYSTEM LOAD DECK AND DISTRIBUTION CARTRIDGE
I have asked members of the IBM1130 google group whether they have a schema to recreate more of the header cards, or even a source for the 100+ sets of text that came with a system distribution. A reader of this blog had suggested that avenue.
Another complication I discovered is the Reload Table, kept in sector 6. The way this is built during the load depends on a feature of the assembled object deck which is lost in the contents on disk. The first four words of each phase are special to the loader. The second words is the 2s complement of the phase number, the third is the displacement into the file where the SLET entries sit, and the fourth is the number of SLET entries that must be processed.
If the phase is going to be placed in memory at location /1100 then the object deck emits four words starting at /10FE, which are the special entries described above, then the second card of the object deck has data starting at /1100. This means that the data in /1100 and /1101, used to point to the SLET entries inside the phase, are overwritten by the first instructions. What I will see on disk is the data from that second card, not the four words from the first card.
Fortunately, I can recreate the first card for those phases that contain SLET entries. The Reload Table, contained in sector 6 of the disk, consists of three word entries for any of the phases that contain SLET entries - not all do. The first word is the phase ID of the phase containing the SLET entries, the second word is the relative address of the SLET entries inside this phase and the third word is the count of SLET entries to be processed.
For any phase that I find in the Reload Table, I will create the first card in the desired format, otherwise I will make a first card with /0000 and 0 for the SLET location/count. That way, my decks will build the Reload Table exactly as it exists. I will also double check all the phases for which IBM1130.org has source, to see which have non-zero counts of SLET entries.
RECREATING SYSTEM LOAD DECK AND DISTRIBUTION CARTRIDGE
I have asked members of the IBM1130 google group whether they have a schema to recreate more of the header cards, or even a source for the 100+ sets of text that came with a system distribution. A reader of this blog had suggested that avenue.
Another complication I discovered is the Reload Table, kept in sector 6. The way this is built during the load depends on a feature of the assembled object deck which is lost in the contents on disk. The first four words of each phase are special to the loader. The second words is the 2s complement of the phase number, the third is the displacement into the file where the SLET entries sit, and the fourth is the number of SLET entries that must be processed.
If the phase is going to be placed in memory at location /1100 then the object deck emits four words starting at /10FE, which are the special entries described above, then the second card of the object deck has data starting at /1100. This means that the data in /1100 and /1101, used to point to the SLET entries inside the phase, are overwritten by the first instructions. What I will see on disk is the data from that second card, not the four words from the first card.
Fortunately, I can recreate the first card for those phases that contain SLET entries. The Reload Table, contained in sector 6 of the disk, consists of three word entries for any of the phases that contain SLET entries - not all do. The first word is the phase ID of the phase containing the SLET entries, the second word is the relative address of the SLET entries inside this phase and the third word is the count of SLET entries to be processed.
For any phase that I find in the Reload Table, I will create the first card in the desired format, otherwise I will make a first card with /0000 and 0 for the SLET location/count. That way, my decks will build the Reload Table exactly as it exists. I will also double check all the phases for which IBM1130.org has source, to see which have non-zero counts of SLET entries.
I am pleased to see that my method should work, having tested it against a few different disks, as it was able to recover the Reload Table information for RPG whose source is not available online. While I think my decks of RPG and COBOL are complete, it is good to know I will be able to handle any system distribution.
I continued to code up the utility programs to recreate the distribution media while in Austin. Test, code more, test more - what a way to while away the idle time between sessions and meetings.
I continued to code up the utility programs to recreate the distribution media while in Austin. Test, code more, test more - what a way to while away the idle time between sessions and meetings.
Friday, November 13, 2015
Building utility to recreate the system load deck and build a distribution cartridge image
RECREATING DISTRIBUTION DECKS
I continued coding the routines that will run through a system cartridge, using the SLET table to find and punch every system file as a card deck - very much like was produced by booting the distribution cartridge from IBM. That cartridge had a program, UCART, to punch all the card images, each phase or file separated by a card with all 9 characters.
My program will read in the phases from the system area and produce a card deck that is equivalent to the official DMS V2 R12 version. It is not identical for a couple of reasons. First, the header card in the IBM decks, which come out from UCART, contains text information about the module which is thrown away as the phase is loaded to a disk cartridge. Second, the object decks are output from the assembly, skipping areas that were coded as BSS (block of reserved locations) and starting a new card when an ORG card was present, while I will produce a tightly packed object module with every card but the last full.
Since the header text is gone, I can try to copy the headers of as many decks as I can find, either those phases for which I have a deck, or decks at other 1130 installations. These are human readable and not directly related to either the phase name or even the heading on the assembly, for those where I have source code. For example, phase 002 which is Job Control 2, with a sequence code starting J0212001 in columns 73-80, has a header card that reads:
" 1 SJB 02 11/06/73 DUP-CTRL RECORD PROCESSOR V2M12 J0212001"
One can guess that it contains the data of last modification, the initials of the programmer changing it, but also has a code '02' whose purpose is unknown. The heading entries in the source deck are of the form "DCTL -DUP CONTROL - COMMA " with various names after the second hyphen. Nothing in the source indicates the date of last assembly, nor could you create "DUP-CTRL RECORD PROCESSOR" from "DCTL -DUP CONTROL".
What I am confident about is that the results on a disk cartridge, in the system area, will be identical word for word between the cartridge I use as the reference source and any cartridge built using my decks. In that way, they will produce identical results on disk even though a card by card comparison of the IBM version and my output will differ.
The SLET table takes a couple of thousand words in core, the largest phase takes almost 5000 words when read in, and a table with the header text I want punched will take over 7000 words. The total, 14K, will fit on a 32K word machine but my physical 1130 where I will run the programs is only a 16K configuration. That means I have to get smart and optimize the program to conserve core - but I will do that in a second pass after I get the basic 'in memory' version functioning properly.
So far, I have testing and verified functions to read in the SLET table and to read each phase from the system area based on the SLET entry. While I am on my trip to Austin for the next six days, I will finish coding and testing the rest, then cutting it down to fit in a 16K machine. It is possible to skinny it all the way down so that it could fit in a 4K machine, but at the present time I don't see the need for that.
I continued coding the routines that will run through a system cartridge, using the SLET table to find and punch every system file as a card deck - very much like was produced by booting the distribution cartridge from IBM. That cartridge had a program, UCART, to punch all the card images, each phase or file separated by a card with all 9 characters.
My program will read in the phases from the system area and produce a card deck that is equivalent to the official DMS V2 R12 version. It is not identical for a couple of reasons. First, the header card in the IBM decks, which come out from UCART, contains text information about the module which is thrown away as the phase is loaded to a disk cartridge. Second, the object decks are output from the assembly, skipping areas that were coded as BSS (block of reserved locations) and starting a new card when an ORG card was present, while I will produce a tightly packed object module with every card but the last full.
Since the header text is gone, I can try to copy the headers of as many decks as I can find, either those phases for which I have a deck, or decks at other 1130 installations. These are human readable and not directly related to either the phase name or even the heading on the assembly, for those where I have source code. For example, phase 002 which is Job Control 2, with a sequence code starting J0212001 in columns 73-80, has a header card that reads:
" 1 SJB 02 11/06/73 DUP-CTRL RECORD PROCESSOR V2M12 J0212001"
One can guess that it contains the data of last modification, the initials of the programmer changing it, but also has a code '02' whose purpose is unknown. The heading entries in the source deck are of the form "DCTL -DUP CONTROL - COMMA " with various names after the second hyphen. Nothing in the source indicates the date of last assembly, nor could you create "DUP-CTRL RECORD PROCESSOR" from "DCTL -DUP CONTROL".
What I am confident about is that the results on a disk cartridge, in the system area, will be identical word for word between the cartridge I use as the reference source and any cartridge built using my decks. In that way, they will produce identical results on disk even though a card by card comparison of the IBM version and my output will differ.
The SLET table takes a couple of thousand words in core, the largest phase takes almost 5000 words when read in, and a table with the header text I want punched will take over 7000 words. The total, 14K, will fit on a 32K word machine but my physical 1130 where I will run the programs is only a 16K configuration. That means I have to get smart and optimize the program to conserve core - but I will do that in a second pass after I get the basic 'in memory' version functioning properly.
So far, I have testing and verified functions to read in the SLET table and to read each phase from the system area based on the SLET entry. While I am on my trip to Austin for the next six days, I will finish coding and testing the rest, then cutting it down to fit in a 16K machine. It is possible to skinny it all the way down so that it could fit in a 4K machine, but at the present time I don't see the need for that.
1053 carrier return cord attached; working on DMS2 distribution deck recreation
1053 CONSOLE PRINTER RESTORATION
Refastening the carrier return cord - the cord that pulls the carrier to the right during space and tab under pressure from the mainspring and which in turn winds the mainspring during carrier return operation - is a huge pain. There are two counter-winding pulleys on a common shaft, one taking up string during rightward movement and the other taking up string during return, with that shaft connected to the mainspring. The cord has to fit over five small pulleys in its run.
To be precise, there are two separate cords. one winds up on the pulley during rightward carrier movement, goes around two smaller pulleys and hooks to the carrier on its right side. The other cord is attached to the pulley that winds up during carrier return operations, goes over three intermediate pulleys and then hooks to the left side of the carrier. One of the small pulleys for the first cord is also spring loaded, in order to establish the right tension but buffer the cord from minor stresses during operation.
The return side cord is wound on its pulley, routed over three pulleys and the carrier pulled rightward to keep it taut. Then, the forward side cord is wound on its pulley, routed over two pulleys including the one with spring pressure, then hooked to the carrier. To get the right tension involves a gross adjustment and a fine adjustment.
The gross adjustment comes from loosening two hard to get to screws in the rear return side pulley where the return cord winds, rotating that pulley on its common axis relative to the rightward cords winding pulley. This is quite hard to do, as the two cords have to be on all their pulleys and in the right grooves of the two winding pulleys, while I hold one and try to rotate the other relative to it.
When the gross adjustment gets the cord to be free of slack when the small spring loaded pulley is partway depressed, then the fine adjustment is done on that spring loaded pulley to set it in the middle of its travel range.
I spent 30 minutes fighting everything and have the gross adjustment almost were it needs to be, but get frustrated by all the spots where cords can pop off pulleys or jump over grooves as I manipulate things.
When I took a rest break and returned, I was finally able to get it back together. The gross adjustment is decent, but I don't have quite enough tension on the spring loaded pulley. For now, it will be good enough.
The next area I need to look at carefully is the interaction between the carrier and the margin mechanisms. I have had the carrier 'jump' over the left margin during some return operations, which is definitely not acceptable, which implies either a bent part or some alignment that needs changing.
CREATING DMS2 DISTRIBUTION DECKS
I now suspect that the file format of the tray images I found on the internet are big-endian rather than little-endian, which foils the display utilities from the IBM1130.org simulator. Meanwhile, I continued testing and developing more of the code that will create the object decks for a System Load of DMS2.
The code that reads a system file into a buffer, given the SLET entry for the file, is working properly. The next bit of code is the subroutine which will punch that buffer as card images in the proper format for use during the system loader process, putting out the right header and trailer cards as well. When debugged, it can be combined in a mainline routine that reads in the SLET and walks through the entries to punch out the decks for them.
Refastening the carrier return cord - the cord that pulls the carrier to the right during space and tab under pressure from the mainspring and which in turn winds the mainspring during carrier return operation - is a huge pain. There are two counter-winding pulleys on a common shaft, one taking up string during rightward movement and the other taking up string during return, with that shaft connected to the mainspring. The cord has to fit over five small pulleys in its run.
To be precise, there are two separate cords. one winds up on the pulley during rightward carrier movement, goes around two smaller pulleys and hooks to the carrier on its right side. The other cord is attached to the pulley that winds up during carrier return operations, goes over three intermediate pulleys and then hooks to the left side of the carrier. One of the small pulleys for the first cord is also spring loaded, in order to establish the right tension but buffer the cord from minor stresses during operation.
The return side cord is wound on its pulley, routed over three pulleys and the carrier pulled rightward to keep it taut. Then, the forward side cord is wound on its pulley, routed over two pulleys including the one with spring pressure, then hooked to the carrier. To get the right tension involves a gross adjustment and a fine adjustment.
The gross adjustment comes from loosening two hard to get to screws in the rear return side pulley where the return cord winds, rotating that pulley on its common axis relative to the rightward cords winding pulley. This is quite hard to do, as the two cords have to be on all their pulleys and in the right grooves of the two winding pulleys, while I hold one and try to rotate the other relative to it.
When the gross adjustment gets the cord to be free of slack when the small spring loaded pulley is partway depressed, then the fine adjustment is done on that spring loaded pulley to set it in the middle of its travel range.
I spent 30 minutes fighting everything and have the gross adjustment almost were it needs to be, but get frustrated by all the spots where cords can pop off pulleys or jump over grooves as I manipulate things.
When I took a rest break and returned, I was finally able to get it back together. The gross adjustment is decent, but I don't have quite enough tension on the spring loaded pulley. For now, it will be good enough.
The next area I need to look at carefully is the interaction between the carrier and the margin mechanisms. I have had the carrier 'jump' over the left margin during some return operations, which is definitely not acceptable, which implies either a bent part or some alignment that needs changing.
CREATING DMS2 DISTRIBUTION DECKS
I now suspect that the file format of the tray images I found on the internet are big-endian rather than little-endian, which foils the display utilities from the IBM1130.org simulator. Meanwhile, I continued testing and developing more of the code that will create the object decks for a System Load of DMS2.
The code that reads a system file into a buffer, given the SLET entry for the file, is working properly. The next bit of code is the subroutine which will punch that buffer as card images in the proper format for use during the system loader process, putting out the right header and trailer cards as well. When debugged, it can be combined in a mainline routine that reads in the SLET and walks through the entries to punch out the decks for them.
Wednesday, November 11, 2015
Work on DMS distribution project and mag tape interface
MAG TAPE INTERFACE TO 1130
I decided to pick up an NCR5380 chip and interface it to an fpga, allowing me to drive the 9 track tape drives I own. This will be part of the SAC Interface Box, implementing the tape drives as IBM 2415 drives attached through an IBM 1133 multiplexer box with the Selector Channel RPQ, the multiplexer box hooked to the 1130.
I have to create a PCB for the NCR chip and other circuitry to connect it to a Spartan 3E fpga. The fpga I am considered is connected by my fast link to the central ztex fpga board in my interface box.
I decided to pick up an NCR5380 chip and interface it to an fpga, allowing me to drive the 9 track tape drives I own. This will be part of the SAC Interface Box, implementing the tape drives as IBM 2415 drives attached through an IBM 1133 multiplexer box with the Selector Channel RPQ, the multiplexer box hooked to the 1130.
I have to create a PCB for the NCR chip and other circuitry to connect it to a Spartan 3E fpga. The fpga I am considered is connected by my fast link to the central ztex fpga board in my interface box.
CREATION OF DISTRIBUTION VERSION OF DMS2 V12
I researched the checksum process used by the loader and DUP and created a subroutine to allow me to calculate a checksum to punch in the card decks I will create from the SLET phases on my disk cartridge. Having ensured the checksum is working properly, I went on to write the larger routine to take a SLET entry and read the phase it points to into a buffer.
Those subroutines in turn are called by code that reads the SLET, phase by phase and for each calls my reading routine. The final bit of code will be the subroutine to convert a buffer read from disk to card images appropriate for use n the System Initialization/Reload process.
I found some files online that are described as DMS V2 R11 card trays - but the format of the files aren't known. There is a decent chance this may be the full card decks I am recreating - a third view of them to help me triangulate on the canonical version,. At the least, I may be able to recreate the sector break card text that is missing from the IBM1130.org recreated files - and missing for the decks that I don't have in my trays.
Some sections appear to encode the card columns with rows 12 down to 9 left justified in a word, which would leave the low nibble of each word as 0x00, but there are other sections where it is 1130 object code pure and simple, with nonzero values in all nibbles of each word.
I researched the checksum process used by the loader and DUP and created a subroutine to allow me to calculate a checksum to punch in the card decks I will create from the SLET phases on my disk cartridge. Having ensured the checksum is working properly, I went on to write the larger routine to take a SLET entry and read the phase it points to into a buffer.
Those subroutines in turn are called by code that reads the SLET, phase by phase and for each calls my reading routine. The final bit of code will be the subroutine to convert a buffer read from disk to card images appropriate for use n the System Initialization/Reload process.
I found some files online that are described as DMS V2 R11 card trays - but the format of the files aren't known. There is a decent chance this may be the full card decks I am recreating - a third view of them to help me triangulate on the canonical version,. At the least, I may be able to recreate the sector break card text that is missing from the IBM1130.org recreated files - and missing for the decks that I don't have in my trays.
Some sections appear to encode the card columns with rows 12 down to 9 left justified in a word, which would leave the low nibble of each word as 0x00, but there are other sections where it is 1130 object code pure and simple, with nonzero values in all nibbles of each word.
Monday, November 9, 2015
Work on 1053, DMS2 system files and the mag tape support for 1130
1053 CONSOLE PRINTER RESTORATION
I removed the mainspring and began the task of rewinding the string to pull the carrier left and right, either under spring tension for spacing or under power to do a carrier return that winds the spring back up.
The ribbon color tape, a nylon tape that is hooked to the carrier and passes around fixed and levered pulleys on the frame, is used to either shift the ribbon to the black ink section or the red ink section of the ribbon. One end of the ribbon color tape tore off its hook, which I need to repair to restore bicolor operation.
I found a glue, Bondic, that is UV cured, based on the glues that are used by dentists on teeth. This promises to allow me to form a new loop at the end of the tape to attach the hook end. I did a test with a tape of the same type, but one that is too short to work on my machine. I found it does hold onto the tape end when the surface is roughed up and the glue is bonded as a clamp totally around the tape.
I tested the loop and did cause it to fail, but on the section that was not fully surrounded by glue. This looks promising, however, once I try a few times on the short tape and perfect my technique.
MAG TAPE SUPPORT FOR 1130
I am still researching means of driving my 9 track tape drives, the simplest being a card that plugs into a PC but that adds more complexity to the interfacing. I am hoping for something I can readily hook to the fpga inside the SAC Interface box.
I have to lock down the location of the tape connection before I make design decisions about how the adapter logic will work. I can't go too far on this, but I did stick in vestigial logic to respond to the tape area code and to provide ILSW and sense information back.
RECREATING SYSTEM DISTRIBUTION CARTRIDGE
IBM distributes DMS2 on a disk cartridge set up so you boot the disk to have it punch the 5000+ cards that will form the system initial load deck needed to put DMS2 on your own cart. The card decks I brought back from Kansas are system reload decks, containing only some of the 'phases' not everything. For example, about half of the Disk Utility Program phases are missing.
I have been doing some design work to reverse engineer the card decks by reading all those phases from my active cartridge using the SLET on sectors 3, 4 and 5. It points me to the core image of each phase on the disk and gives me the remaining information I need to recreate the card decks. What I can't completely recreate are the comments on the type 1 card that is first in each phase. These don't appear in the source code I see on the IBM1130.org web site nor are they stored on disk.
I worked through documentation and dumped some disk sectors to check out my hypotheses. I should be able to build equivalent card decks which will produce the same system disk cartridge when loaded as are currently on my disks. I can cross check against the many decks I do have - more than half but not all the phases - to ensure I am doing this right.
Once I have virtual card decks for all the phases, I can build a complete system initial load on the IBM 1130 simulator to prove out the process. If that works well, the last step is to pass these through the UCART utility which will turn a blank disk cartridge into a distribution cart that can be booted to punch out all the decks. Having a distribution cartridge means I can take it to any restored 1130 with a card punch and help them create their own system load decks.
I found that the format of the phases on disk is not any of the usual disk formats used by DMS2 - such as DSF or DCI or DDF - instead being just the core contents written on disk in the system area, with the SLET indicating the sector, word count and the execution address for the phase when fetched into core. The card images are a variant of the card formats - a type 1 card is the header, then card data format records, ending with a program end record. These look a lot like the output of the assembler or compilers.
Thus, after the header card, I have to read the disk image and convert each group of 45 words into a card image, with its own pseudo load address word, checksum and identifier at the front, the data words starting in col 10, and a module identifer plus sequencing in 73-80. I can fit seven full cards plus a residual card of five words into each disk sector.
I could continue this way until I have converted the total number of words from the system area on disk into punched cards. However, knowing that the loader will deal with spanning sectors, I will just punch the data I find on disk with 45 words per card until done. I then punch the end program card using the execution address from the SLET entry, to wrap up the card version of the phase.
Again, this won't exactly match the deck that would be produced by the assembly. The assembler pays no attention to sector breaks. Further, if it ends a card with some BSS or an area skipped by an ORG, it doesn't load those words. Instead, the next card begins with the first defined content address and continues. One oddity is that the first data card will begin with two words, zero and the phase number, in the two addresses preceding the initial core location but these are not stored on the disk. That adds two words to the card file compared to the disk file length.
Thus, the actual deck for DUP phase 02 is 35 data cards plus the type 1 header and end program cards. My method would punch 33 data cards (32 full plus two words on the last card). Mine is slightly more efficient because I am not hopping around with each ORG and attempting to skip over BSS blocks.
An alternate method is to assemble the program, save the punched deck and see how I might convert it to the system load format. My test worked out beautifully - if I assemble and then do a *DUMP from WS to cards, I get almost exactly the same deck. The first two cards punched by the *DUMP are tossed and my type 1 header is stuck in its place, but the remainder of the cards are exactly correct.
However, this is only as good as the source code I have purporting to be DMS V2. It is very close but I can't guarantee it exactly matches the version I have on my system. Therefore, I still need to produce my decks based on reading the system areas of my disk cartridge.
I removed the mainspring and began the task of rewinding the string to pull the carrier left and right, either under spring tension for spacing or under power to do a carrier return that winds the spring back up.
The ribbon color tape, a nylon tape that is hooked to the carrier and passes around fixed and levered pulleys on the frame, is used to either shift the ribbon to the black ink section or the red ink section of the ribbon. One end of the ribbon color tape tore off its hook, which I need to repair to restore bicolor operation.
I found a glue, Bondic, that is UV cured, based on the glues that are used by dentists on teeth. This promises to allow me to form a new loop at the end of the tape to attach the hook end. I did a test with a tape of the same type, but one that is too short to work on my machine. I found it does hold onto the tape end when the surface is roughed up and the glue is bonded as a clamp totally around the tape.
I tested the loop and did cause it to fail, but on the section that was not fully surrounded by glue. This looks promising, however, once I try a few times on the short tape and perfect my technique.
MAG TAPE SUPPORT FOR 1130
I am still researching means of driving my 9 track tape drives, the simplest being a card that plugs into a PC but that adds more complexity to the interfacing. I am hoping for something I can readily hook to the fpga inside the SAC Interface box.
I have to lock down the location of the tape connection before I make design decisions about how the adapter logic will work. I can't go too far on this, but I did stick in vestigial logic to respond to the tape area code and to provide ILSW and sense information back.
RECREATING SYSTEM DISTRIBUTION CARTRIDGE
IBM distributes DMS2 on a disk cartridge set up so you boot the disk to have it punch the 5000+ cards that will form the system initial load deck needed to put DMS2 on your own cart. The card decks I brought back from Kansas are system reload decks, containing only some of the 'phases' not everything. For example, about half of the Disk Utility Program phases are missing.
I have been doing some design work to reverse engineer the card decks by reading all those phases from my active cartridge using the SLET on sectors 3, 4 and 5. It points me to the core image of each phase on the disk and gives me the remaining information I need to recreate the card decks. What I can't completely recreate are the comments on the type 1 card that is first in each phase. These don't appear in the source code I see on the IBM1130.org web site nor are they stored on disk.
I worked through documentation and dumped some disk sectors to check out my hypotheses. I should be able to build equivalent card decks which will produce the same system disk cartridge when loaded as are currently on my disks. I can cross check against the many decks I do have - more than half but not all the phases - to ensure I am doing this right.
Once I have virtual card decks for all the phases, I can build a complete system initial load on the IBM 1130 simulator to prove out the process. If that works well, the last step is to pass these through the UCART utility which will turn a blank disk cartridge into a distribution cart that can be booted to punch out all the decks. Having a distribution cartridge means I can take it to any restored 1130 with a card punch and help them create their own system load decks.
I found that the format of the phases on disk is not any of the usual disk formats used by DMS2 - such as DSF or DCI or DDF - instead being just the core contents written on disk in the system area, with the SLET indicating the sector, word count and the execution address for the phase when fetched into core. The card images are a variant of the card formats - a type 1 card is the header, then card data format records, ending with a program end record. These look a lot like the output of the assembler or compilers.
Thus, after the header card, I have to read the disk image and convert each group of 45 words into a card image, with its own pseudo load address word, checksum and identifier at the front, the data words starting in col 10, and a module identifer plus sequencing in 73-80. I can fit seven full cards plus a residual card of five words into each disk sector.
I could continue this way until I have converted the total number of words from the system area on disk into punched cards. However, knowing that the loader will deal with spanning sectors, I will just punch the data I find on disk with 45 words per card until done. I then punch the end program card using the execution address from the SLET entry, to wrap up the card version of the phase.
Again, this won't exactly match the deck that would be produced by the assembly. The assembler pays no attention to sector breaks. Further, if it ends a card with some BSS or an area skipped by an ORG, it doesn't load those words. Instead, the next card begins with the first defined content address and continues. One oddity is that the first data card will begin with two words, zero and the phase number, in the two addresses preceding the initial core location but these are not stored on the disk. That adds two words to the card file compared to the disk file length.
Thus, the actual deck for DUP phase 02 is 35 data cards plus the type 1 header and end program cards. My method would punch 33 data cards (32 full plus two words on the last card). Mine is slightly more efficient because I am not hopping around with each ORG and attempting to skip over BSS blocks.
An alternate method is to assemble the program, save the punched deck and see how I might convert it to the system load format. My test worked out beautifully - if I assemble and then do a *DUMP from WS to cards, I get almost exactly the same deck. The first two cards punched by the *DUMP are tossed and my type 1 header is stuck in its place, but the remainder of the cards are exactly correct.
However, this is only as good as the source code I have purporting to be DMS V2. It is very close but I can't guarantee it exactly matches the version I have on my system. Therefore, I still need to produce my decks based on reading the system areas of my disk cartridge.
Sunday, November 8, 2015
Mag Tape routines and interface planning for SAC Interface Box
So little free time this weekend I could only do some quick reading and thinking in short breaks.
TAPE DRIVE SUPPORT FOR 1130
I have successfully assembled the mag tape subroutine and interrupt handler code necessary to use tape drives attached to the 1130 system, resolving any open questions about implementation specs for the SAC Interface Box. I now can implement the support, which is a subset of the Selector Channel RPQ plus adapter logic to make my 9 track drives behave as if they were 2400 series units.
Quite a few functions of a selector channel are not used by the subroutine - thus won't need to be implemented. Command Chaining, Transfer in Channel, Test IO, Halt IO, Data Chaining and Program Controlled Interrupts won't be supported, therefore. The only CCW flag that is used is Suppress Length Indication.
The subroutines I am using, an FDP distributed as program 0.03.003 for the 1130, were written for use with DMS Version 1, not V2. As such I have to make modifications for their use on V2. The original code made use of ISS number 5, which was not used in DMS V1 but is in conflict with the interrupt service subroutine for disk in V2. I modified it to use ISS 15 for mag tape. I also had to rebuild the ILS04 they provided, since it did not include support for devices such as 2501 which were not supported in DMS V1.
The subroutine MAGTZ intended to allow use in FORTRAN requires a change to at least one run-time routine, SIOF, but also modifications to the Fortran compiler itself to recognize the IOCS device MAGNETIC TAPE and to support that on logical unit 11 in the program. The modifications to the compiler are not shown in the documentation I have and in any case would be unusable as they refer to the very old version of the compiler found in DMS V1.
I can support the new device type on the IOCS card by a source modification to kforph01 but I would either need to reload the system or turn it into a patch that can be applied to the existing load module on disk. I have not yet figured out the place to update where it will allow 11 as a logical unit number when tape was specified.
The fortran support via MAGTZ (using READ/WRITE commands) is not a priority and involves the work I described above. Fortunately, a slightly more cumbersome means is available for FORTRAN programs to use tape, via the subroutine MAGTA., Instead of READ/WRITE, the user issues CALL MAGTA statements and must do all data formatting operations that are otherwise performed by Fortran IO and FORMAT statements.
TAPE DRIVE SUPPORT FOR 1130
I have successfully assembled the mag tape subroutine and interrupt handler code necessary to use tape drives attached to the 1130 system, resolving any open questions about implementation specs for the SAC Interface Box. I now can implement the support, which is a subset of the Selector Channel RPQ plus adapter logic to make my 9 track drives behave as if they were 2400 series units.
Quite a few functions of a selector channel are not used by the subroutine - thus won't need to be implemented. Command Chaining, Transfer in Channel, Test IO, Halt IO, Data Chaining and Program Controlled Interrupts won't be supported, therefore. The only CCW flag that is used is Suppress Length Indication.
The subroutines I am using, an FDP distributed as program 0.03.003 for the 1130, were written for use with DMS Version 1, not V2. As such I have to make modifications for their use on V2. The original code made use of ISS number 5, which was not used in DMS V1 but is in conflict with the interrupt service subroutine for disk in V2. I modified it to use ISS 15 for mag tape. I also had to rebuild the ILS04 they provided, since it did not include support for devices such as 2501 which were not supported in DMS V1.
The subroutine MAGTZ intended to allow use in FORTRAN requires a change to at least one run-time routine, SIOF, but also modifications to the Fortran compiler itself to recognize the IOCS device MAGNETIC TAPE and to support that on logical unit 11 in the program. The modifications to the compiler are not shown in the documentation I have and in any case would be unusable as they refer to the very old version of the compiler found in DMS V1.
I can support the new device type on the IOCS card by a source modification to kforph01 but I would either need to reload the system or turn it into a patch that can be applied to the existing load module on disk. I have not yet figured out the place to update where it will allow 11 as a logical unit number when tape was specified.
The fortran support via MAGTZ (using READ/WRITE commands) is not a priority and involves the work I described above. Fortunately, a slightly more cumbersome means is available for FORTRAN programs to use tape, via the subroutine MAGTA., Instead of READ/WRITE, the user issues CALL MAGTA statements and must do all data formatting operations that are otherwise performed by Fortran IO and FORMAT statements.
Friday, November 6, 2015
Not much work time, but some research leading to potential to hook tape drives to 1130
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Driver chip 3 seemed a likely suspect as it controls the six bits that are hot when I am loading a PC file in the 1130 core memory. However, I powered up the SAC Interface box and the 1130, where I didn't see any problem. I will have to keep watching this, because of the perfect alignment to the driver chip.
It is definitely not the SLT card in the 1131, since bits 6 and 7 are on one card and the remaining bits are on another, plus other bits on those cards work fine. No common point in the 1131 that would produce the symptoms seen.
Driver chip 3 seemed a likely suspect as it controls the six bits that are hot when I am loading a PC file in the 1130 core memory. However, I powered up the SAC Interface box and the 1130, where I didn't see any problem. I will have to keep watching this, because of the perfect alignment to the driver chip.
It is definitely not the SLT card in the 1131, since bits 6 and 7 are on one card and the remaining bits are on another, plus other bits on those cards work fine. No common point in the 1131 that would produce the symptoms seen.
I continued my careful study of the VHDL and all Xilinx warnings, tightening up code where it makes sense. Nothing stood out as a problem. Until I can get time to go into the workshop and test with more diagnostic information, I won't lick this issue.
2400 TAPE DRIVE ATTACHMENT TO 1130
I resumed my investigation into interfacing tape drives to the 1130, through my SAC box, as I now have enough to meet my two requirements - software which uses the tape drives and an adequately detailed description of the programming interface (XIO commands, interrupts, status words and so forth).
Peter Vaughan of the National Museum of Computing in the UK gave me the successful lead - a document on Bitsavers of a field developed program for accessing the mag tape drives from both assembler and Fortran - 00.3.003 - which includes listings of the programs including the interrupt handler.
It is clear that the attachment of the 2400 tape drives (usually 2415 models which had an integrated control unit that attach to a S/360 selector channel) was through the Selector Channel RPQ that put such a channel inside the 1133 Multiplexor box. This is adequately described in the Attachment Channel RPQ document on Bitsavers and matches what I see in the software.
The Selector Channel is accessed as area code 27 and interrupts on level 4 with ILSW bit position 12 indicating it is the source of the interrupt. This however adds a bit of convolution to the interface since the XIO Write function in the 1130 are used to pass a string of Channel Command Words to the selector channel, each three words long. Further, the XIO Sense Device uses its modifier bits to select which of four Channel Status Words rather than returning a single word of status.
The tape drives are programmed by CCWs just as they are on a S/360 system, which does allow me to reference the 360 library manuals for the 2400 drives to properly model the drive's behavior. The software supports a string of up to eight tape drives on a control unit.
Implementing a full selector channel involves a lot of capabilities - Transfer in Channel which is a branch to a new CCW location in core memory, Data chaining and command chaining, program controlled interrupts and other nuances. I am tempted to dig through the software and implement only those parts of the selector channel function that are used by the code.
I will set up the code from the manual as machine readable card images and test with the 1130 simulator to be sure I have a clean assembly and the code looks good. That can occur as I work out the Selector Channel RPQ function in the SAC Interface Box.
I will still have to figure out how I attach the actual tape drives - I have two that are SCSI based which would either require me building SCSI hardware into my SAC box or they could be attached to a PC with a SCSI card and have the data pass over the USB link. My current PC for the USB link and the Python program is a laptop running Linux so even the PC attachment alternative would be a bit more disruptive than it seems.
2400 TAPE DRIVE ATTACHMENT TO 1130
I resumed my investigation into interfacing tape drives to the 1130, through my SAC box, as I now have enough to meet my two requirements - software which uses the tape drives and an adequately detailed description of the programming interface (XIO commands, interrupts, status words and so forth).
Peter Vaughan of the National Museum of Computing in the UK gave me the successful lead - a document on Bitsavers of a field developed program for accessing the mag tape drives from both assembler and Fortran - 00.3.003 - which includes listings of the programs including the interrupt handler.
It is clear that the attachment of the 2400 tape drives (usually 2415 models which had an integrated control unit that attach to a S/360 selector channel) was through the Selector Channel RPQ that put such a channel inside the 1133 Multiplexor box. This is adequately described in the Attachment Channel RPQ document on Bitsavers and matches what I see in the software.
The Selector Channel is accessed as area code 27 and interrupts on level 4 with ILSW bit position 12 indicating it is the source of the interrupt. This however adds a bit of convolution to the interface since the XIO Write function in the 1130 are used to pass a string of Channel Command Words to the selector channel, each three words long. Further, the XIO Sense Device uses its modifier bits to select which of four Channel Status Words rather than returning a single word of status.
The tape drives are programmed by CCWs just as they are on a S/360 system, which does allow me to reference the 360 library manuals for the 2400 drives to properly model the drive's behavior. The software supports a string of up to eight tape drives on a control unit.
Implementing a full selector channel involves a lot of capabilities - Transfer in Channel which is a branch to a new CCW location in core memory, Data chaining and command chaining, program controlled interrupts and other nuances. I am tempted to dig through the software and implement only those parts of the selector channel function that are used by the code.
I will set up the code from the manual as machine readable card images and test with the 1130 simulator to be sure I have a clean assembly and the code looks good. That can occur as I work out the Selector Channel RPQ function in the SAC Interface Box.
I will still have to figure out how I attach the actual tape drives - I have two that are SCSI based which would either require me building SCSI hardware into my SAC box or they could be attached to a PC with a SCSI card and have the data pass over the USB link. My current PC for the USB link and the Python program is a laptop running Linux so even the PC attachment alternative would be a bit more disruptive than it seems.
Wednesday, November 4, 2015
Looking for cause of hot bits on inbound data from SAC interface box
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Still hunting down the phantom source of the 0x03F0 injected into the inbound data register. It is possible that this could be a hardware issue, since we are talking about six contiguous bits that are hot, but I can test that by using a voltmeter on my driver boards.
Still hunting down the phantom source of the 0x03F0 injected into the inbound data register. It is possible that this could be a hardware issue, since we are talking about six contiguous bits that are hot, but I can test that by using a voltmeter on my driver boards.
I did take the time to walk through the thousands of lines of output from the synthesis report, looking for warnings that I could clean up - not only for the phantom hot bits but just to cut down on errors to make any actual issues easier to spot in the future.
So little time until I get through the crunch time at work.
So little time until I get through the crunch time at work.
Tuesday, November 3, 2015
Debugging activity on the SAC box and a bit of remote aid
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Making good progress on the debugging of the 1053 mirror device, now that I included plenty of diagnostic information that I could watch on the PC as the fpga box did its thing. I started the ZDCIP standalone disk utility, which first types some instructions and choices on the 1053 console printer.
I could see that I was correctly setting up data characters, pushing them into the FIFO and popping them back out, because the values were visible while the activity was underway. What seemed to go awry was in the delivery of that retrieved word back to the PC.
Next, the PC was receiving empty buffer status but not handling it correctly. I need to tweak the Python program on the PC side to deal with this.
I then experienced the same problem again, with something locking up and forcing 0x03F0 on the inbound B bus, which is read anytime an XIO instruction or cycle steal looks to that shared bus. I think I triggered this by shutting off the 1130 before I had stopped the mirror 1053 adapter function.
However, even when I power cycled the SAC adapter, started up the Python program again and cycled the USB interface cord, the system still had the erroneous status on the bus. I am not sure how this could persist over the cold restart that I did. It might be a flaw in the USB driver in Linux on the PC or it might be something in the 1130 itself - this is puzzling.
I need to figure out ways this might happen, instrument some checks and figure out what happens, since when it reaches this wedged state with 0x03F0 forced on, I can't do any other testing. It is a priority problem.
HELP TO FELLOW RESTORERS
Today I was able to offer advice and suggestions to one friend, who is assisting a US based museum in restoring some 4381 and 360 systems, and to check out the 'normal' behavior of a part on a keypunch for another friend working on a keypunch at a UK based institution.
The 4381 startup is terminated when the -1.5V power supply detects over-current as it ramps up, protectively dropping all power to the system. It seems to be reaching a bit over 80 amperes when this happens. They were pondering ways of measuring the actual current draw to sections of the machine, but didn't have a good tool. We are looking at something under 18 thousandths of an ohm resistance. It takes a very accurate and precise ohmmeter to sort out the real resistance of the load.
Since the power is delivered over a laminated sandwich of power bars, one of which carries the -1.5V current, those bus bars having very low resistance but not zero, once can treat them as a resistor in series between the power supply and the load. Stick a sensitive voltmeter across the two 'ends' of the bus bar, nearest the supply and nearest the load, and you can determine the current. This is because the resistance of the bar can be measured, out of circuit, and once known the voltage drop measured is simply IxR. Thus, the current carried on the bus bar will be calculated as V/R.
The keypunch is not feeding well. It has a pair of'knives' that select just the front card and pull it down into the rollers, but one of the knives pivots left and right while the other is fixed in position. I verified from my 029 keypunch that both knives should pivot. If the knife is frozen and its front is not exactly parallel with the cards in the hopper, the 'high' end will push the cards backwards, such that they won't slide down the 'throat' that is carefully adjusted to be a bit over one card thick.
I then experienced the same problem again, with something locking up and forcing 0x03F0 on the inbound B bus, which is read anytime an XIO instruction or cycle steal looks to that shared bus. I think I triggered this by shutting off the 1130 before I had stopped the mirror 1053 adapter function.
However, even when I power cycled the SAC adapter, started up the Python program again and cycled the USB interface cord, the system still had the erroneous status on the bus. I am not sure how this could persist over the cold restart that I did. It might be a flaw in the USB driver in Linux on the PC or it might be something in the 1130 itself - this is puzzling.
I need to figure out ways this might happen, instrument some checks and figure out what happens, since when it reaches this wedged state with 0x03F0 forced on, I can't do any other testing. It is a priority problem.
HELP TO FELLOW RESTORERS
Today I was able to offer advice and suggestions to one friend, who is assisting a US based museum in restoring some 4381 and 360 systems, and to check out the 'normal' behavior of a part on a keypunch for another friend working on a keypunch at a UK based institution.
The 4381 startup is terminated when the -1.5V power supply detects over-current as it ramps up, protectively dropping all power to the system. It seems to be reaching a bit over 80 amperes when this happens. They were pondering ways of measuring the actual current draw to sections of the machine, but didn't have a good tool. We are looking at something under 18 thousandths of an ohm resistance. It takes a very accurate and precise ohmmeter to sort out the real resistance of the load.
Since the power is delivered over a laminated sandwich of power bars, one of which carries the -1.5V current, those bus bars having very low resistance but not zero, once can treat them as a resistor in series between the power supply and the load. Stick a sensitive voltmeter across the two 'ends' of the bus bar, nearest the supply and nearest the load, and you can determine the current. This is because the resistance of the bar can be measured, out of circuit, and once known the voltage drop measured is simply IxR. Thus, the current carried on the bus bar will be calculated as V/R.
The keypunch is not feeding well. It has a pair of'knives' that select just the front card and pull it down into the rollers, but one of the knives pivots left and right while the other is fixed in position. I verified from my 029 keypunch that both knives should pivot. If the knife is frozen and its front is not exactly parallel with the cards in the hopper, the 'high' end will push the cards backwards, such that they won't slide down the 'throat' that is carefully adjusted to be a bit over one card thick.
Sunday, November 1, 2015
Starting in on string retrheading in 1053 and further debugging of the SAC Interface Box
Work reaching a peak level lately, which starves me of time to spend on the systems.
1053 CONSOLE PRINTER RESTORATION
The string is fouled up that winds the mainspring when a carrier return is done and releases that energy powering space, tab and similar forward operations. It has wound around the hub of the mainspring takeup pulley, which I have to clear up before I can put the string back on its small pulleys and tensioner. I may need to rewind the spring as well to get it back to the right initial tension.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I found an interrupt status word feed that wasn't sourced, cleaned it up and had a successful load and verification of core memory. I could then get back to testing.
I did get the 2310 diagnostic to get through reading the first sectors of the virtual disk drive I had mounted on the PC. I made a few changes in the code but also saw the transactional engine hang up, which meant that a 'done' signal was not sensed leaving one or more FSMs stranded in the wrong state.
NIXIE TUBE CLOCK WITH DEKATRON TUBE PENDULUM
I assembled a clock with six Nixie tubes displaying the hour, minute and second digits, and a Dekatron tube spinning back and forth as an electronic pendulum. Nixie tube clock working I wanted the retro feel of the orange glow of these cold cathode gas discharge tubes. The Nixies have ten cathodes, shaped like the ten digits, while the Dekatron has ten positions around the circular face of the tube.
Dekatron's were built to display decimal data, often counters of some kind, with the discharge moving around the clock face each time a pulse arrives to make the glow jump to the successor position.
This was a quick little project to leverage the tubes which I have had in my collection of retro esoterica for quite a while. The final project will be a melange of different eras and looks - it will be housed in a cathedral radio cabinet, very 20s-30s, has digital display not analog so modern, but uses tube technology so kind of 1950s feel. I guess the pendulum is quasi-analog, with the moving dot reflecting the virtual pendulum swing.
1053 CONSOLE PRINTER RESTORATION
The string is fouled up that winds the mainspring when a carrier return is done and releases that energy powering space, tab and similar forward operations. It has wound around the hub of the mainspring takeup pulley, which I have to clear up before I can put the string back on its small pulleys and tensioner. I may need to rewind the spring as well to get it back to the right initial tension.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I found an interrupt status word feed that wasn't sourced, cleaned it up and had a successful load and verification of core memory. I could then get back to testing.
I did get the 2310 diagnostic to get through reading the first sectors of the virtual disk drive I had mounted on the PC. I made a few changes in the code but also saw the transactional engine hang up, which meant that a 'done' signal was not sensed leaving one or more FSMs stranded in the wrong state.
NIXIE TUBE CLOCK WITH DEKATRON TUBE PENDULUM
I assembled a clock with six Nixie tubes displaying the hour, minute and second digits, and a Dekatron tube spinning back and forth as an electronic pendulum. Nixie tube clock working I wanted the retro feel of the orange glow of these cold cathode gas discharge tubes. The Nixies have ten cathodes, shaped like the ten digits, while the Dekatron has ten positions around the circular face of the tube.
Dekatron's were built to display decimal data, often counters of some kind, with the discharge moving around the clock face each time a pulse arrives to make the glow jump to the successor position.
This was a quick little project to leverage the tubes which I have had in my collection of retro esoterica for quite a while. The final project will be a melange of different eras and looks - it will be housed in a cathedral radio cabinet, very 20s-30s, has digital display not analog so modern, but uses tube technology so kind of 1950s feel. I guess the pendulum is quasi-analog, with the moving dot reflecting the virtual pendulum swing.