1053 mirror adapter working correctly, good progress debugging virtual 2310 disk drive adapter

1053 CONSOLE PRINTER RESTORATION

I finally hunted down suppliers of the continuous feed paper that is needed for the 1053 - it is wider than normal page printers but not as wide as the line printers. Easy to find 9.5" and 14 7/8" forms, but I needed 13 7/8" wide pages for the tractor feed of the 1053. A box is $72 with shipping, a bit expensive but the 2400 pages should suffice for quite a while.

All my testing of the virtual 2310 function makes use of the physical 1053 for the operator messages and data output. The continued use is making the behavior of the console printer better, just through exercising it so much. It will still require work and adjustments, but loosening the old lubricants is important too.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I traced down the cause of the problem with my 1053 printer mirror adapter, where it was failing to translate Selectric tilt/rotate codes to ASCII. The fix was made and I will retest soon. Still no clue as to why I am getting pairs of characters arriving in a single transaction from the FPGA. More research underway, because I don't see any way this could happen unless the diagnostic program issuing the XIO is packing two characters per XIO Write, which violates the Functional Characteristics declarations concerning the console printer.

I also prepared a virtual disk drive with known contents on various sectors so that I could test out the virtual 2310 disk adapter logic a bit more. This way, I can run the DCIP utility and dump various sectors to how what the first few words returned from the sector match the known contents. Finally, I have recorded the memory location of the disk sector buffer in core so that I can check an entire sector of content without needing to print it all on the 1053 typewriter.

My Python program GUI speaking to the SAC Interface Box and 1130

My test on the mirror adapter worked much better - getting good translations for some characters but still didn't match exactly what was being typed by the DCIP utility. The problem was once again in the same area I had to fix before - in converting the incoming word value into a bit string to look up the ASCII translation. I will change how I do this to a more reliable method.

With the change in place, I can report that the mirror 1053 adapter is working perfectly. It produced a file with exactly what was typed by the DCIP program, but in ASCII on the PC, without interfering at all with the operation of the real physical 1053 console printer.

Mirror adapter for 1053 produced proper output matching typewriter output

On to the testing of the virtual 2310 disk drive adapter next. Armed with the location of the disk buffer, I tried to dump sector 0 of the virtual disk in order to compare it to the known values. I saw two anomalies:

• the disk contents were correct, but alternated with words of a fixed value 0x5803. This means my loop to dump each word of the disk sector is not working properly. I read the sector from the PC file, place it into an array and then walk through the array to do the read or write. I may be setting up the array wrong or walking it wrong. 
• The PC side adapter logic pushed an operation complete status down to the FPGA box, but I didn't seem to react to it until I had reset the 1130 processor. Thus, one of my FSMs in the 2310 logic in the FPGA is not working properly. Once I triggered it via the reset, I saw my box write the data words down to the 1130 IO buffer using cycle steal, just as it should have. 

The first problem is almost certainly in the Python code, while the second is almost certainly in my VHDL for the FPGA. I will walk through the code and see what might be causing both problems - if not patently obvious, I will instrument some tests to help me figure out the flaw in either or both sides as needed.

I think I fixed the second problem and concentrated on debugging the first problem as the night fell. When I emitted diagnostic messages during the routine to read the sector from the PC disk file, I saw that the data was correct from the file but the flaw was in my logic for moving it into an array for pushing into core with the cycle steal mechanism.

The root of the defect is in the way I am handling the difference between the byte size of data from the PC file and the 16 bit words used in the 1130. I need to step by twos when fetching words from the PC file buffer but step by ones when bumping storage addresses for the cycle steal write.

Debugging work on 1053 and on SAC box mirror1053 and virtual 2310 functions

1053 CONSOLE PRINTER RESTORATION

I ran the typewriter diagnostic to test the console printer operation. I found it is still unacceptable:

• Sometimes a line feed sticks on, ejecting line after line
• Some carrier returns don't latch on, returning only partway
• it stalled on some CR operations with the carrier at the left
• sometimes CR movement is very slow (to the left)

One area for repair I spotted was the CR activation microswitch on the underside, which isn't set up properly. I will detach and reinstall it correctly. The line feed issue is still residual crud that stops the interposer from latching frontward on a restore. The CR failure to latch on is an adjustment issue. Not sure what causes the stall, but I will work on these first tasks and then test another time.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

My fixes to the FIFO usage seem to be working fairly well, as I am now seeing the proper typewriter codes returned to the Python program. My logic is also working properly in detecting empty conditions, when I have fetched all the characters that were in the FIFO. The character stream I see matches what was typed and what the diagnostic should have typed.

Other aspects are not yet satisfactory:

• Sometimes I get back one character at a time, which is what I expect, but in the middle of the test I began receiving pairs of characters. Good would be x9a00 x2100 x4100 x9200 but I might see x9a21 x4192. Since in almost every case the two sides are both valid character codes for the typewriter, I must have a flaw in my fpga logic although the PC side is possible.
• I am not translating the character I received back to ASCII, a flaw in the Python program

I will hunt through the PC and fpga side logic to investigate these odd results and fix the code. Meanwhile, I will switch testing to the disk emulation, loading the DCIP utility and attempting to dump a sector of a virtual disk drive hosted on the PC. This will help debug the virtual 2310 disk drive adapter logic.

My first run failed because I entered the wrong drive number for the utility. My virtual 2310 disk drive is drive D, which is entered as drive 4 to the utility, the internal disk being drive 0. I entered 1 instead, which my logic reported correctly as 'not ready'.

When I tried to run the program again, I found that my incoming data register was jammed with extra bits 0x01F0 so that I couldn't even load core properly from a file anymore. This happened in past days when I was testing as well. Not sure what is happening, but power cycling the fpga, my PC program and the 1130 didn't correct it. I will need to ponder what could possibly be causing this, although I suspect it is either the SAC box or one of the adapters inside the 1130.

The bits that are stuck on align too neatly with chip 3 of my output driver board in the SAC Interface Box. I powered up for another test, found the bits still stuck on, and brought out a VOM to check the voltage levels on chip 3. I touched the +5V feed for the chip and a few other leads on the chip, which looked okay. On a hunch, I tried the the memory load again and found it working fine. This tells me I have an intermittent power issue with the +5V feed on pin 14 to chip 3. I will reflow the solder and verify that the socket to pin mating isn't at fault.

Since I could test again, I loaded the standalone disk utility program DCIP once again and this time, used the correct drive number (4) for my test. I tried a dump of the first sector and was delighted to see that the code appeared to complete a read of the sector and the values began to be typed on the console. The typewriter isn't in good enough shape yet to print out a 320 word sector properly, but even with the first few words printed I could see that I had indeed fetched the beginning of sector 0 of the virtual pack. The status information from the Python program running in the PC looked good as well.

I will have to do some incremental testing before I am convinced that the emulation is all correct, but the fact that I seemingly got through a dump of one sector is very promising. I will take a known disk image from the simulator, with some printed sectors as reference, then do runs on the SAC Interface Box where I can check the in-core buffer to see if the contents are exactly right.

Going back to the 1053 mirror adapter issue, the biggest defect is the failure to translate to ASCII properly, which seems to be due to a subtle python issue since on first blush, the values I saw during operation should have fetched the right ASCII characters. I will need to do some testing with the code to see why it isn't succeeding.

Working on a repair to the cracked ceramic feed wheel on the 1442 card reader punch

1442 CARD READER/PUNCH RESTORATION

I decided to use my UV hardening material, Bondic, to build up the broken section of the wheel that moves cards through the punch station. Once I get the material up close to level, I will have to invent a method to establish an accurate radius for the new section. I intend to spinkle grit onto the top layer as a way of establishing a similar grip to the remaining section and other wheel.

It was a very slow and careful process to build up layers and harden them, approaching but not exceeding the height I need. If I overshoot I will need to find a way to file this surface down, something I don't relish. Still, it is likely I will need to do this and the maker of Bondic says that this is feasible with various standard methods.

I ran out of my first vial of the material, ordered more, but need to wait a few days for it to arrive.

BOUGHT KEY ON EBAY FOR THE ELAPSED TIME METERS ON THE 1130

Unfortunately, while it looked like it might be correct and was advertised as an IBM mainframe key, the key I received is probably for a cash register or other non-mainframe instead. I will continue to seek out the key which lets me switch the between CE mode and customer mode meters.

Working on FIFO code in SAC Interface Box

1053 CONSOLE PRINTER RESTORATION

I won't put my repaired ribbon color shift tape onto the 1053 until I am ready to put on the outer cover, as I broke the tape earlier while manipulating the console printer mechanism. I had to validate that the console printer was performing acceptably, using the IBM typewriter diagnostic program.
Running it will have to wait until my guests are all gone.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I began looking at parts of the fpga logic that use the FIFO to copy data words from mirrored devices. Mirror devices is an invention in the SAC Interface which shadows the operation of a physical IO device adapter inside the 1131 processor, capturing the data stream and control actions done to the device. Its purpose is to deliver a copy of the output of the console printer or 1132 printer in a PC file.

To accommodate timing constraints, I use a 1024 word deep FIFO in the fpga, stuffing in the output words from the mirrored device and popping them out at the request of the mirror driver code running on the PC. When I last tested, I wasn't getting valid data words out to the PC, which implied a failure on either the push or the pop side of the FIFO (or both theoretically).

I worked through my FSMs that drive the FIFO and are in turn driven by the mirror XIO logic and the incoming transactions from the PC. I was particularly focused on the setup, hold and duration of the control signals relative to the clock edges as this is the most likely source of malfunction. The FIFO will produce to status signals - VALID and WRITE-ACK - which I will include in the new FSMs I will write to control the FIFO.

The existing FSMs will now trigger the two FIFO-specific machines. I worked up the code and integration into the existing FPGA logic, but didn't get to any live testing because I still had family over for the holidays.

Repaired the color shift tape for the 1053 console printer

1053 CONSOLE PRINTER RESTORATION

I worked out the best process for repairing the ribbon color tape - a plastic tape that travels over rollers as the carrier moves, but with a shift in tension on the tape it can trigger the carrier to move the ribbon higher or lower, typing through the red or black half of the ribbon. On my tape, one end tore open where it was looped to hold a metal hook. The loop in the tape was originally heat-welded.

I am using Bondic, a ultraviolet light curing adhesive very similar to what dentists use to fill cavities in teeth. First, the surface of the tape was lightly roughed up to create a better bonding surface. Then, I folded the torn end of the tape and began building up the material on the outsides and edges. Once it formed a solid blob around the tape, it had secured the two ends inside firmly.

My test piece used a loop in the middle of my spare tape - after bonding I yanked as hard as I could but there was no slippage or detachment. With that success behind me, I slowly and carefully built up the end of the proper length tape that I needed to repair. This worked well and I now can install it to provide ribbon color shifting on my console.

Test loop to verify bond strength on wrong length tape

Repaired tape end ready to be reinstalled in 1053

I have to go back to the diagnostic program and work on the 1053 until its typing and other behaviors are working well enough - spacing, backspaces, tab movement, carrier returns, line feeds, and color shifts.

SCANNED AND SHARED 1053 CONSOLE MANUAL

I scanned the FE Theory of Operations manual for the 1053 console printer, placing the resulting PDF up on my dropbox and also sharing it with the Golfball typewriter group. I will also offer it to Al to put up on Bitsavers.org, although he is quite busy right now with an office move and doesn't have the spare cycles; he has a backlog of other manuals I have scanned for upload.

Done with System Load deck work

SYSTEM LOAD DECK WORK

I am still having problems with the phase 1 loader program (DSYSLDR1) reading in the phsae 2 loader (FSYSLDR2). The error I receive is E03 Seq Error or Missing Record which the code shows can come from three faults:

1. SCON card not read after the loading of the phase 2 loader is complete
2. the phase 2 loader did not have a type F card recognized (end of its deck)

I have already processed the MODE card and the code is reading the phase 2 loader when the error occurs. Something is wrong with the phase 2 loader deck or something is wrong with the phase 1 code that is reading it. It shouldn't be looking for the SCON card until it finished reading the phase 2 loader and in any case, there is a valid SCON card immediately after the end of phase 2.

I suspect the problem is with the check for the type F card. However, the phase 1 code that is throwing off the error is unique in that it is stored in the binary card loader format, not the usual card data CDD format of all the other phases. This is processed by a utility provided by Brian Knittel, Makeboot, which might be causing some problem with my DSYSLDR1 deck. I will need to carefully examine both programs and perhaps do some hand-debugging on the 1130 simulator.

I used the listing to figure out where to place a WAIT instruction and how to investigate which of the two causes has triggered the error message. When I ran it, the reason was that it hadn't recognized the type F record. I can see a type F at the end of the deck, so there must be something malformed about that card image.

The problem comes in how I split the deck assembled from the single source PMONITOR which yields decks used in two different places in the load process. The first portion is the resident monitor, EMN, which is loaded by DSYSLDR1 just prior to loading FSYSLDR2 and continuing. The second portion are the device driver phases 8C to 98 which come in sequence after the core image loader phases.

Brian split the source deck, assembled each separately, but I decided to assemble it as one and divide up the binary object deck. The type F card is produced by the assembler when it sees the END directive at the end of the source program. Thus, the type F card was misplaced at the end of the device phases rather than right after the resident monitor. I moved the card around to the proper location and the ERR 03 went away.

My next stop was when loading phase 7 of the DUP program, where I had ERR 04 ORG BACKWARD on program JGDELETE. It was simply because I had omitted the SBRK card at the front of the source code, easily fixed. I now was able to process the entire system reload deck. From the initial testing I have done, it is all working properly.

My next step was to package the update into the files in the same groupings as for the V12 update. Similarly, I am finalizing a grouping that would represent a full initial load cartridge as it might have existed if IBM had shipped a V13 of the monitor system.

This project is essentially complete now - I have canonical versions of V11 and V12 plus a correct update from V11 to V12. In addition, I have a presumptive full version of "V13" and an update from V12 to "V13". I can build cartridge images for any of these versions.

WILLIAMS TUBE MEMORY PROJECT

Bob Erickson began a project to produce a working Williams-Kilburn tube memory system. This was a technique used in a few of the earliest computers, such as Manchester Mark I, Von Neumann's IAS system and the IBM 701, using the surface of a CRT tube to store bits as a memory. Mercury delay lines were a contemporaneous alternative, as used in the Univac 1, but these all gave way to magnetic core memories once they were developed by Jay Forrestor.

Bob had serviced these systems while at IBM and had a memory tray in his possession which he intended to use, with driving circuitry he would design in line with the circuits he knew from the 701, to recreate a working memory for visitors. Bob and a few other volunteers worked on building this up, but Bob succumbed to cancer before the system could be completed.

The CHM doesn't want it taking up space in the workroom, so I have taken temporary custody of the unit. I would like to participate in completing this but have far too many other projects in line first to accomplish anything in the near term. Still, better to preserve this and hope to build a team later than to see it scrapped.

Load deck cleanup and a bit of work on 1053 restoration

1053 CONSOLE PRINTER RESTORATION

Took another test pass on the spare but wrong sized ribbon color tape perfecting the technique I will use to repair the correct sized broken tape. I want to take another pass at it tomorrow as I have just the one correct tape and can't afford to ruin it.

SYSTEM LOAD DECK WORK

I worked out a modification for the assem1130 program that Brian Knittel wrote as part of the IBM 1130 simulator. This adds a parameter (-k) that is used with system phases, allowing me to stick on a type 1 header via a SBRK card as the new front of the source deck. SBRK also will pick off the first five characters of the sequence field and use it for the output deck, resetting the three digit sequence numbers for each phase.

Then, the output decks look more like the real card decks that come from IBM. I could add further nuances if needed - for example if the increment per card for the sequence field is not always one but sometimes by tens.

I now have the phase decks for a V13 update and for a full initial load of V13. I finalized the decks and tested them on the simulator. There are some issues which I am chasing down.

Work on 1130 simulator tools for system load deck

SYSTEM LOAD DECK WORK

I noticed that the assembled output of a module has a garbage header card at the beginning of the output, whereas the SBRK commands produce the proper type 1 card for all the remaining phases in the assembled file. This tells me that something is missing in the process that Brian devised, which should have included a default header value for the first phase in each assembled module.

I will look over the source for the assem1130 program to see if I can figure out what has to happen to produce the right type 1 card at the start of the binary output deck. Right now, it assembles this as a relocatable or absolute object deck, with a type card that is inappropriate to system phases.

It appears that I should add an SBRK card to the source deck to inject the first type 1 card text. This produces the same invalid type 1 and then the SBRK version so I need to do tweaking to the program itself not just the source decks.

Initially I could just replace the mangled type 1 record with the proper header text to get usable files. I also note that the output of assembling the files sometimes produces different deck prefixes in columns 73 and onward compared to the card decks produced on a real 1130. This suggests that the assem1130 program should have some way to control the value in the sequencing field. More study needed for this.

Note that this is a problem with the source based recovery done by Brian Knittel and used with the 1130 simulator. Since I have IBM distributed decks for R2 V11 and R2 V12, I can ignore the problem for those releases, but when trying to assemble the "PTF" decks for the 'R2 V13" release, the header cards and sequencing is not faithful to the existing decks. I could create a utility to resequence decks if there is not a clean simple way to adapt the assem1130 program.

I made progress during my trip to Lima but didn't finish. I arrived back home Saturday and spent my barely conscious hours with family.

DMS R2 V12 DECK AND CARTRIDGE WORKING, BEGAN ON V13 VERSION FROM PTF DECKS

Lots of time in the airport and on the flights from San Francisco to Lima (via Dallas), which I took advantage of. When I tried to charge my laptop in Dallas, I discovered I had somehow left my PC charger at home. Yikes! If I had a day or so I could have one delivered from Amazon for $25, but instead I paid an airport kiosk $108 for a generic charger. Still, this lets me continue working, handle boarding passes and other trip details, and stay sane, so worth it compared to toting a dead laptop around until Saturday

SYSTEM LOAD DECK WORK

I built and tested the initial load deck for a DMS R2 V12 system (rather than loading V11 and then running an update. This involved substituting all the changed phases and modules from the V12 update into the decks I had previously prepared for the V11 initial load.

Next, I prepared the deck to load a fresh cartridge with all the decks for DMS R2 V12 to match what IBM would have shipped to a user who ordered V12. This loaded successfully. Just as with the cartridge I produced for V11, I booted the disk but it looped in the simulator rather than punching the 4380 cards it should have.

I suspect this is a simulator flaw with punching rather than an issue in my procedures, although it is also possible there is something wrong with the zucart.asm file that came with the 1130 simulator. Running ZDCIP and dumping sectors of the disk cartridge, I see the card images loaded properly on the cart and the programs properly placed on cylinder 0, so my initial assessment is that my distribution cartridges are good.

Next, I used the cross assembler that comes with the 1130 simulator to compile the object decks from the purported R2 V13 version of the monitor. These are source code of all the routines that were touched by PTFs which were shipped after V12 was out - using the fiction that the V13 which IBM never produced would have encompassed all these changes,

With all the decks produced, I built an update deck that will take a V12 cartridge and convert it to 'V13'. First, I had to update the phase header cards for each of the modified programs for V13, producing a file suitable for use with the system loader. I copied the cards from the V12 decks and modified them to use my initials, today's date and claim them as R2 V13.

Most were straightforward, but the PMONITOR deck includes both the resident monitor, numbered EMN and the device phases, so I had to separate it The DSYSLOADER deck didn't correspond directly to anything in my decks, so I had to do more research before I could merge this into the V12 decks. I found that it was the code that would be converted to 1800 core image loader format and become the DPI first phase of the loader. Brian Knittel had a utility program to accomplish this conversion.

I did all the others first, then began the work on the two problem modules. It was relatively easy to separate resident monitor from device phases and the utility program from Brian helped me get the cards converted from the normal object deck CDD format to the 1800 core image format. There are some peculiarities to work out before I test this updating a system to V13.

I plan to continue this a bit more tonight, before I get on the redeye down to Lima, but need to try to sleep for the relatively short 7 hour flight. 

Initial system load of DMS R2 V11 and update process to V12 working properly

I am off to Lima, Peru for a few days on my last trip on the horizon. Once I am back this weekend I can get fully back to the 1130 system.

SYSTEM LOAD DECK AND CARTRIDGE RECREATIONS

I made some improvements and retested my initial load deck for DMS R2 V11 - it now appeared to work perfectly. I ran the sample programs and got proper results from Assembler and Fortran, but RPG looped and COBOL apparently didn't load at all during my load procedure.

The reason for the problem with COBOL is that IBM inverted the logic for the MODE card for COBOL versus the other compilers. If you are loading RPG, Assembler or FORTRAN, you leave the assigned column of the MODE card blank. A letter A, R or F in the appropriate column means that the compiler will NOT be loaded. COBOL, on the other hand, uses a blank in its column to mean that the compiler is skipped. I had to add in an explicit C in column 15 of the MODE card to have the loader process the COBOL phases.

The COBOL compiler is now active and I ran the sample job, which compiled fine but looped after printing the first line of output. Interestingly, that was the same symptom for the RPG sample job. Another person who had donated an RPG formatted disk image to the IBM1130.org site for use with the simulator had some advice - that some simulator parameters had to be adjusted to reduce the CPU load of the card reader emulation in order to have the 1132 printer work properly.

The looping jobs had turned on the FORMS CHECK light, which claimed that the output file was not hooked to the printer, but I believe this was a symptom of the printer emulation failing. The changed parameters for the simulator allowed my RPG job to work properly, but the COBOL sample program still fails with those values.

Since the COBOL failure mode is the same as the RPG one, a spurious FORMS CHECK lamp on the simulator, with only the heading line having been printed, I will chalk this up to a simulator flaw. If I have time, I will try some other values for the simulator parameters to see if that allows the job to complete.

There are some limitations in the 1130 simulator, excellent as it is generally, such as this printer flaw and the modeling of the card reader/punches, which is not faithful to the real peripherals and thus lacks the ability to set the last card indicator reliably.

I found a site offering modified source code to match all the outstanding PTFs for DMS R2 V12 thus this would have been a V13 if IBM had released it that way. I am considering creating a V13 update deck so that users can apply those fixes and have a 'R2 V13' system. I downloaded all the source code which I can assemble and form up into a reload deck.

First, however, was the test for an update of a V11 cartridge to V12 using my decks. That ran well and produced a working cartridge with DMS R2 V12 on it. I also arranged the decks so that I could run UCART to build a distribution disk for the V12 update, as it was sent to the owner of my 1130 system.

DATACENTER SHED

I found a problem where my neutral line on the buildings plug was not properly torqued down, resulting in sporadic loss of that line. It affected the 120V loads in the shed. After redoing the plug my power is solid, so that I can plug the building into the outdoor outlet on the side of my house and run the systems in the shed. 

New System Load decks worked to build R2 V11 from scratch

SYSTEM LOAD DECK RECREATION

I made more progress on this front, finding the remaining decks that were punched from the distribution cartridge for a DMS R2 V11 system. The two major issues left were an exceedingly mangled loader part two (FP2) deck, a special version of the DISKN routine to handle 2311 disk drives, and a missing single card program to dump core to the console printer.

I found another set of cards that had a V11 front end, which was in pristine condition. I read that in and completed my set of load decks (except for the one card console core dump). I also located the single card program to dump to console printer.

My remaining challenge was locating the 2311 version of DISKN, something that wouldn't be needed on the 1130 systems I bought and therefore not retained by the owner. I went through the 75000 cards in my card cabinet, looking for the disk routine, and discovered it on the bottom level, sandwiched between some demo and games decks and unmarked. Fortunately, I knew the code in columns 73 to 80 for this deck. It is scanned and in place now.

I built a simulator file to load a fresh cartridge, numbered 0211, with the decks exactly as it would have been run by IBM. The result will be a bootable disk cartridge which simply punches all 25 decks, each section separated by a card with all 80 columns containing the 9 character.

My first run consisted of loading the standalone DCIP program, initializing the fresh disk on the first external drive 1, and labeling it 0211. I then mounted a good dms pack on drive 0 (internal disk), booted, and ran my deck to build the fresh cartridge. It appeared to load the cartridge properly with all the decks, but I got a loop when I booted that cartridge to attempt punching.

I did a quick single step and found a point where the code was doing a XIO Sense DSW for device 0, which is an error. I need to debug this further as it might be a flaw in the ZUCART program. Since it has never been tested with the simulator since the DMS system was recreated, there may be a typo or other issue.

I then set up a full system initial load of DMS R2 V11 from my decks, including RPG, FORTRAN, COBOL and Assembler. It went almost perfectly, except for some COBOL PTF (temporary fix) files mixed into the library routines, which also blocked installation of the RPG library routines. Still, the resulting system booted up and seems to work well.

Once I clean this up, I can redo the load and then test the four sample programs - assembler, FORTRAN, COBOL and RPG - to further shake out the performance of this cartridge. Once I am satisfied with its operation, I will apply my DMS R2 V12 system reload decks to convert this from V11 to V12, then test the operation of that version.

Read in lots of cards for system load decks, donated 1130 programs, as well as scanned several donated manuals

SYSTEM LOAD DECK WORK

I read all the library routines for the full load version of DMS R2 V11, including all the COBOL and RPG library routines. I took time to organize these into the groupings (decks) that are punched by the distribution cartridge in preparation to do a system load. Some of the front end deck, the system loader in particular, is really chewed up.

The decks in the card cabinet had swollen considerably making it nearly impossible to remove as they were under considerable pressure. The team helping me retrieve the 1130 from its prior home had to dig some cards out of each tray in order to release the clamp at the end. Unfortunately, this section of cards was where they had to dig.

I will be able to read these, but it may be one card at a time after smoothing the edges as much as possible. The cards condition is awful and would have instantly jammed in any IBM card reader. Fortunately, the Documation with its unique feeding mechanism is much more forgiving.

SCANNING NEW MANUALS GIVEN TO ME

Clare Owens sent me a number of manuals he had for years, including quite a few FE documents that will be helpful to me and other restorers of 360 era systems. I began scanning these and turning them into PDF files. The first two, covering SLT packaging, procedures and SLT circuits, are now complete.

SLT Packaging manual

SLT Circuits manual

I have a handbook for 1130 FEs with lots of conveniently concentrated information plus some I have not seen before. Because of its small size and many double folded pages, it will take a bit of work to scan in.

Other manuals include MST circuits, 360/50 maintenance manual, some 1401 reference cards, two SMS power supply instructional manuals, and more.

READING DECKS AND ORGANIZING CONTENTS

I had received a second box of cards from a donor intended them to eventually go to the Computer History Museum but wanting them read and made available in the mean time. I went out to the shed and ran them through the card reader to capture everything. This went smoothly.

One deck is a simulator for a very simple computer that was used for education on computer principles, based on a book and paper 'computer' called CARDIAC. This program, SIMCO, implements the same instruction set on the 1130. I have documentation on the simulated computer but not on the format for input cards or any other operating and administration instructions. When I run it, I get no output at all.

1800 in Finland now executing instructions, while my virtual card decks for system load are being completed

Friday - flying home from a trip to Las Vegas and finally able to work with the hardware for a few days until my midweek trip to Lima, Peru in a few days.

1800 SYSTEM RESTORATION IN FINLAND

The system is now advancing through the T-clock states, fetching data from core memory and looks like it is basically alive. The restorer discovered a signal that was blocking the clock advance and disabled it temporarily in order to get basic operation underway.

Johannes then discovered that an SLT card was plugged into the wrong socket, so that an input to a NOT gate was left floating, ultimately blocking the clock advance. When he moved the card to its proper place, the machine clocks now work correctly.

Another issue he found and corrected was spurious parity errors, which stemmed from a loose cable that he reattached. He is now able to test and confirm proper operation of the instructions and related hardware.

DMS DECK AND CARTRIDGE RECONSTRUCTION

The system update deck for taking a DMS R2 V11 system to V12 is now essentially complete - all phases and library routines are available. The larger initial load deck for V11 itself is coming along nicely. I am missing a few of the initial decks that fit in front of the system phases, and need to make sure I have all the library routines for a V11 install as well as the library routines for the RPG and COBOL compilers.

I found a few decks which are marked as COBOL PTFs (Program Temporary Fix) thus these would replace the original distribution version of certain system phases and library programs. I don't have any RPG library routines yet, but feel pretty confident that they are sitting in my card trays ready to be captured.

Working with DMS card decks and my utility program

I am in Las Vegas for the week, working heavily, but I did manage to do some work on the flight over and in spare time tonight.

PROCESSING DMS V11 CARD DECKS

I worked on the raw files read from all the decks, converting them to individual decks per phase so that they can be combined as needed in system loads. I also created a separate copy of the decks for the COBOL and RPG compilers.

I updated my program to punch out decks from any existing disk cartridge, merging in the phase header text for RPG and a few missing phases. Only COBOL lacks the header cards and all others are now going to match the versions shipped by IBM.

Another improvement I made was to punch the separator cards (a card with the character 9 punched across all the columns) only where they were punched from the IBM distribution cartridges. These occur after phases 12, 39, 74, 84, 98, A1, CE and F6 plus I added one after the COBOL and RPG compiler phases at 5C and CC respectively. These cards allow someone to find the breakpoint in decks which are punched, since they have no printing atop the card. The pattern of 9s is very distinctive and easy to spot.

I have to read in all the library modules, which are handled differently from the system phases. Library modules are saved in the regular file area and manipulated by the Disk Utility Program (DUP) just as with ordinary user programs. System phases, on the other hand, are only loaded by the System Load process and exist in a system area on the disk that is not intended to be visible to the user.

Each library program comes with a DUP control card (e.g. a *STORE     CD  UA    FILENAME) in front of the object deck. The system load process, after handling the system phases, sees an "81" card and starts up DUP. DUP will read all the subsequent cards, which are these combinations of a DUP command and the object decks. The user can always change one of these without having to do a system load of any type, just by running DUP.

I have a few small decks to scan as well - the front end program to start the system load, the cold start card, and the sample programs that are shipped on the IBM distribution cartridges. It is my intent to have all the cards to allow me to produce a complete distribution cartridge.

Read more of DMS R2 V11 decks, COBOL and RPG compilers, plus news of 1800 restoration in Finland

Back home for one day, before flying off to another conference in Las Vegas for most of the week.

READING DMS R2 V11 SYSTEM DECK AND RPG COMPILER

I got out to the datacenter shed and read in a tray of cards - the remainder of the COBOL compiler, the rest of the system phases for DMS, the assembler, and RPG. I can break these into separate phase decks at my leisure while traveling. Next, I have to read in all the system library modules although they don't need to be divided into individual decks. I won't get to it today since I have to pack again for my pickup at 4AM tomorrow to head off to my next trip.

When I finish up this set of V11 decks, I can go back and scan all the V12 changed system library routines. Too, I need to read in the COBOL and RPG library modules.

1800 SYSTEM RESTORATION IN FINLAND

Johannes Thelan has the 1800 powered up, having fixed and validated a few power issues, and is now chasing down minor issues before he can begin executing code. The pulse that advances the T-clock from T7 to start a memory cycle is not occuring. There are a number of conditions that will block the clock from advancing out of T7, among them ongoing arithmetic operations, shift operations, certain branch operations and if the X clock (cycle stealing is running).

Likely this is cycle stealing running amok due to a cabling issue or other problem with an IO adapter, but Johannes has to do some scoping to determine which condition is incorrect then resolve the root problem. I expect this to be a relatively easy thing to fix, so he should be executing instructions in a few days maximum. Another system returned to life!

Visited museum and returned home

VISIT TO NATIONAL MUSEUM OF COMPUTING IN UK

I was able to visit the museum in the United Kingdom during my trip and meet again with Peter Vaughan who restores and maintains historic systems including an IBM 1130. Their system is working fine, but they don't have a system disk cartridge to run DMS2. Since I have quite a few cartridges, I should be able to build it and send it to them, as soon as I have my virtual card reader functionality working fully.

The museum system is an 8K 1130 with a 1442 card reader/punch and an 1132 printer. I got a quick picture of Peter standing behind the system.

Peter Vaughan at the National Museum of Computing, UK, with their running 1130 system

Their newest prize is the first computer built by British Tabulating Machinery, the Hollerith Electronic Computer 1 (HEC-1). which was a prototype, never sold, but was the basis for subsequent HEC machines they sold. They are not sure if it can be restored to working order, given its construction quality was sufficient as an engineering testbed not continued production use. However, they are a clever bunch, so if it is at all possible, I would expect to see it running again.

HEC 1 computer front side

Back of HEC-1 computer, showing funky wiring

The other exciting project underway at TNMOC is the creation of a replica of the EDSAC computer. Quite a bit is complete already, but it will be some time until it is all complete and running. The original EDSAC used mercury vat delay lines for memory, but due to the hazardous nature of mercury plus the difficulty acheiving reliable operation of such memories, they are substituting delay lines using nickle wire. Otherwise, it is as exact as possible to the original machine.

EDSAC replica coming together

CLEANING UP SCANNED DOCUMENTS

I had scanned several manuals and ALDs but the results remained as many files each representing a block of 20 or 30 pages. Due to the use of autofeeder, one side of the document would be in reverse page number while the other side is in ascending sequence. I had to 'sort' the pages in Acrobat, which frankly is much more work than it sounds, then merge the files.

When merged, I had runs of perhaps 20 even page numbers followed by 20 odd page numbers, which I had to resequence so that the result is a linearly increasing document. The flight was a good opportunity to get that done.

The ALD had pages which were rotated 90 degrees while others were 'upright', but for ease of reading I changed all the pages to be readable 'upright'. It was much easier to combine the sections of the ALD, since I didn't have two-sided printing to deal with and thus no blocks of even and blocks of odd pages reversed.

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.

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.

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.

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.

1. 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. 
2. 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.
3. 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.

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.

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.

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.

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.

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, 

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 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.

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. 

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.

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.

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.

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.

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.

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.

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.

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. 

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.

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.

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. 

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.

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.

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. 

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.