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.