1132 power connector fixed, display panel fixed on replica, signage done for VCF West

JACKSCREW REPLACEMENT FOR 1132 POWER CONNECTOR INSIDE 1131

I have removed the mounting screws for the power connector and have pulled it out from the frame a bit, to allow me to rotate it a bit and gain a bit more access. I have been unable to get the mounting nut to fit inside the back of the connector and grab threads from the front inserted jackscrew.

I tried to glue a bit of plastic soda straw to a face of the nut, so that I could insert it into the rear of the connector and even turn it slightly. Assuming I can get the jackscrew and its nut tightened, the next problem will be putting the 1132 connector back into its position on the power panel.

Four guide pins are used to hold the connector onto the frame. Unfortunately, the lock washers and nuts have to be held in place from the side of the power panel, while the threaded rods of the pins are inserted from the front. This is quite challenging because of extremely limited access.

I took a bit of paper town, inserted it between a 1/4" socket and the nut on the end of those guide pins. Pushing down caused the nut to be wedged into the socket, the pin unthreaded, and the socket potentially used to hold the nut in place in back while I attempt to thread in the pins from the front.

It took two improvisations to even attempt this reassembly - the glued on straw segment and the paper wedged nuts in sockets. The first of these worked like a charm! I now have the jackscrew tightened into place on the connector.

Unfortunately, the socket is too wide to fit into the narrow notch in the back of the connector where the lockwasher and nut must go. I removed the air duct for the internal disk drive, which gave me more access to the top two areas. I should be able to get those top two guide pins properly connected and tight. The problem will be with the bottom two.

I can reach my hand in and touch the spot where the pin threaded rod comes through, but I can't put the hand in if it is closed even a bit to hold a nut and I certainly can't move the nut around to put it into position. Even with the relatively easier top two pins, I am manipulating the nut with a single fingertip, sliding it down, changing its orientation and getting the thread to catch.

The top two pins are installed as is the bottom left. I had to wedge the small nut between my fingertip and the vertical wall of the power frame, slide it deep inside and up to the point where the guide pin threaded rod emerged, then carefully move things until the threads caught. To do the fourth and final pin, I have to slide the nut even deeper and then move it up into a notch around behind the bottom of the connector body.

After wrestling with this last guide pin for another hour, then losing the nut somewhere, I came to a realization. Three guide pins are plenty to position and guide the male connector as the jackscrew draws it carefully into the female connector.

I turned to the 1132 male connector, which still had the jackscrew female attached to the jackscrew. I took it off, inserted the screw properly in the connector, and put things back together. With all my cables reconnected, except for the SAC power cable whose connector donated the female jackscrew for this repair, I jumpered the power pins on the SAC power cable and brought my system up.

As I had suspected, the problem with the printer spewing paper was just an effect of a partially disconnected power cable. The AC power pins were still providing power, but the logic card voltages of +3, -3 and +6V were not going to the printer. With no logic to set it up properly, the printer was going to do bad things.

PREPARATION FOR VCF WEST EXHIBITION

I sprayed the texture coat, sand colored stone finish, last night so that I could put on the first color coat of pebble gray early today. Later in the afternoon I added the final pebble gray color coat. Once these are dry enough, tomorrow, I will reattach them to the 1130 frame. That will leave only the section of the top that holds the display pedestal and is the nook into which the console typewriter sits.

I printed the final signage for the booth, laminated some of them while inserting others in acrylic stands. This includes three original IBM magazine full page ads that I laminated for display. I feel good enough about the signage that I can put all my attention on the remaining tasks:

1. Finish 1132 power connector repair
2. Test all demonstrations as they will be done
3. Repair 1130 replica display panel that was broken last week
4. Mount new-old rotary mode switch on pedestal
5. Replace top metal on replica
6. Build typewriter and pedestal base from MDF
7. Paint typewrite and pedestal base
8. Install typewriter and pedestal base
9. Install pedestal on base
10. Load fpga with replica logic
11. set up power system for replica
12. connect all controls to FPGA
13. test replica and repair any issues
14. fit IO selectric in place on replica
15. Temporarily affix the console bit switches in place
16. Secure internal disk drive heads for transport
17. Disconnect all cables and secure them
18. Swap power plug on 1130 for L6-30
19. Cut and install replica cover braces
20. mount replica covers
21. move replica to staging area near real 1130

I have retrieved all the connector boards, power supplies and other bits that were used to run the replica. Now I will have to carefully note where every connector and signal should go, validate the cabling and other parts, then hook it all up.

I completed tasks 3 and 4 - repairing the replica's display pedestal panel, where the plexiglas panel had broken off when the stand tipped over. This has been quite hard to get secure, the last time I had drilled holes, glued in 1/8" plastic rods and then hooked clamps over the back of the rod, inside the pedestal head. Those broke off.

This time, I used 3mm flathead black screws through those 1/8" holes in the plexiglas, secured to locknuts inside the pedestal head. Three of the four are properly secured, the fourth is a friction fit but should hold okay without the locknut. I also secured the rotary mode switch plate firmly onto the head.

With the 1132 power connector repaired (see section above), I had now completed 3 of the 21 tasks. Eighteen to go, Three relate to the real 1130, the remainder are for the replica, to complete the cosmetics and get it working.

Preparation for VCF, working to install missing jackscrew in 1132 power connector inside 1131

PREPARATION FOR VCF WEST EXHIBITION

I fired up the system to walk through the demonstrations - running decks exactly as I will on the showfloor. When I powered up and flipped on the motor for the 1132, it began spewing paper even though it was not yet ready and no XIOs had been issued! A power cycle of the system didn't help.

Perhaps this is an artifact of the loose power connector, which I really should take on next anyhow. I have decent access to the rear of the connector bay inside the 1131, to put in the jackscrew that is missing. I will still have a problem - the need for either an extremely thin wall socket or painfully slow tightening with screwdriver blades.

I had better get all the demonstrations set up to work with virtual 1403 printers, in case my 1132 is not going to be dependable. That means alternate decks, since Fortran programs must be written to the specific printer which will be used at execution time.

I have a 1403 only version of the DMS disk, which I will use for testing the alternate decks. This printer malfunction will make it impossible to do my demonstrations booting a real disk since my cartridge requires the real 1132 to print. I need to figure this out and fix it.

It did appear that the 1132 power connector was partially disconnected - if resets aren't properly done, and grounds aren't good the logic can malfunction thus I will fix the connector first and then revisit the printer to see if any problem in fact exists.

My portable air conditioner stopped cooling the garage effectively, which I think is because it has filled with water. I unhooked the air exhaust hose that runs through the wall to vent outside, rolled the unit out and tried to drain some water from it. I will see if it cools any better now. Otherwise, the garage will be too hot to run the computer for most of each day, limiting my testing.

While waiting to see if my AC will recover to cooler temps, I took the metal top parts from the 1130 replica, steel wool cleaned the surfaces of loose rust, then primed them with Rustoleum Rust Converting Primer, That should give me a paintable surface for my texture coat tomorrow and then for the color coats.

My three advertisements for the 1130 were laminated, as were some signs for the various boxes at the exhibit. The card decks that were being run for demonstrations were printed and put in plastic holders for ease of handling (and protection).

INSTALL REPLACEMENT JACKSCREW ON 1132 POWER CONNECTOR IN 1131

I opened the side door and began planning my approach to this repair. It became immediately obvious that the jackscrew for the power connectors is smaller in diameter than the ones used for signal cables. I can't use the one I harvested from the CHI disk controller box.

There is a power cable that runs to my SAC Interface cable although is has limited use with my design. The power cable carries low voltage AC power out from the 1131 and has a pair of wires that complete the power connectivity circuit.

The low voltage AC energizes relays in the peripheral devices to cause them to power up when the 1131 is turned on. I had the fpga inside my box powered through such a relay, but because of the long time it takes the fpga to load its bitstream from flash, the 1131 will have come out of power-on reset while the FPGA is still in an invalid state. Thus, I jumpered around the relay and manually turn on my box instead, waiting until it is up fully before I switch on the 1131.

The power connectivity circuit carries power from the 1131 power system out to the SAC box, back to the 1131 and to a relay that enables the power-on switch to bring up the system. Thus, pin 23 and pin 28 of the connector are shorted up in my box. Now that I am scavenging the small jackscrew from the SAC power cable,

I need to bridge those two pins without a connector installed. I had used a small wire jumper, which I will put back in place. The connector is reinstalled, sans jackscrew, but the cable itself is not hooked up. Instead, the jumper wire is secured in place.

Now that I have a jackscrew, I need to begin installing it into the power connector for the 1132 printer. I can push the front part of the jackscrew in, but I have to turn the 1/4" nut from the back with limited access room. In practice, the big problem was getting the nut into the back of the connector at all.

Perhaps I can make a tube barely bigger than 1/4", stick it to the nut at one end, and push that tube into the connector hole until I can catch the threads from the jackscrew entering from the front. This is challenging, perhaps why the original owner didn't replace the jackscrew when it fell out decades ago.

I finally decided to remove the connector itself, which will pull forward enough for me to install the jackscrew (laboriously). That means, however, that I need to hold onto and extract nuts and bolts without them falling irretrievably inside the wiring tangles back there. I will also need to be able to put the washer and then bolt over the thread when re-installing.

I am going to shop for a strong magnet on a rod that I can use to grab up nuts and washers as the threads come out. I will figure out how to get the parts back on later, but this way I can remove the connector to fix the jackscrew problem, at least.

Working on Xerox Alto restoration, preparing for VCF exhibition

XEROX ALTO RESTORATION

Today I meet with my fellow restorers who are working on bringing a Xerox Alto II back to life. That took most of the, leaving me limited time for the 1130. We put the scope on various lines to verify the health of the machine and see where we might have problems.

First we tested the health of the system clocks and reset circuits. They were solid, so we then looked at the current task index, four bits that indicate which of the 16 tasks are executing. On an Alto, many duties that are implemented in hardware on other computers were instead done by software running in these microcode tasks.

For example, the RAM memory uses dynamic memory chips, like most RAM, which require all locations be refreshed within milliseconds or the stored value will leak away. This refresh is done in hardware on most computers, sometimes even in the memory device itself, but the Alto has a microcode task to read each location in bursts.

Setting up the bits for a line of the display is handled by two of the tasks. Ethernet has its own display. The cursor for the screen is managed by its own task. When no higher priority task is trying to run, the lowest priority task 0 runs, which executes the user code and operating system.

Our scope showed the task index changing as the display, memory refresh and disk sector tasks were taking slices of time. This was a good sign of the basic health of the machine, fetching and executing microcode, running the tasks and giving up control to let lower priority tasks run.

We then put the scope on the disk interface card, looking to see if we were attempting to read the disk for the bootup of the system. We didn't see any command strobe or other requests going out to the disk - the disk was not even being selected by the interface. The disk status was correctly reported to the processor and it believed it was okay to do disk IO.  We saw the sector pulses arriving as expected.

Likely the problem is that the disk IO request is not being set up and given to the disk interface and its microcode tasks. Task 0, the user/OS task, starts the bootstrap and builds a disk read request in RAM for the disk tasks to kick off. The disk tasks should match the desired sector (in the case of boot, sector 0), trigger a read and manage the execution of that comment. If it wasn't sure where the disk arm sat, it would issue a seek command to cylinder 0 first.

Since we saw no seek and no read, no disk selection, something is going wrong in the software in either task 0 or the disk tasks. We will have to wire up the logic analyzer and begin capturing detailed information about microcode execution. This will happen on our next work day.

PREPARATION FOR VCF WEST EXHIBITION

I picked up a nice poster for my exhibition space, plus document protectors for all the normal letter sized documents I produced. The show will provide two eight foot long tables, which will mostly have display items like the ALDs or sample SLT cards.

I took off the upper parts of my 1130 - sheet metal I was fitting - since they were untreated a have a surface rust film. I intend to steel wool them, then spray a rust converting primer over them. After that, they will get the sand colored stone texture paint then will be finished off with pebble gray.

I disconnected my rotary mode switch plate from the cable and connected up the real switch that I received as a gift. I have to mount this real plate on the display pedestal and then figure out the tough problem, how to get the plexiglas panel back in place.

At this point, I am going to try to use some small, black, flat head screws through holes in the plexiglass and try to hold the nuts from the rear while I tighten the panel down. I will need to drill out the plexiglass a bit to fit the screws, which is quite dangerous with plastic since the heat of drilling often melts the plastic or causes other damage.

xxxxxxxxxxxx

Virtual 1403 printer working now, prepping for show, accidentally damaged replica display pedestal (!)

PREPARATION FOR VCF WEST

I began collecting and amassing in one area all the items I will be bringing to the event - ALDs, manuals, example SLT cards, books and so forth. I also began formalizing the demo decks I will use and printing out each for reference by visitors as they run.

My current list of demonstrations include:

• Fortran program to calculate and print square roots on the 1132 printer
• Fortran program to solve equations, using 1403 printer and disk
• Assembly of some code
• Boot of internal disk drive using 1132 and 1442 reader for boot card, then virt 1442
• Boot of virtual disk, virtual 1403 and virtual 1442 to run decks above
• Hand code to show the 1130 add instruction in action
• DCIP utility to dump disk sector to virtual 1403
• Load core with CPU diagnostics and run to completion

I got out my saws, clamps and wood glue to begin building the upper metal piece for the 1130 replica. I had an alternative in mind to the original plan, which was to build wood pieces that sat atop the existing metalwork under the display pedestal. The new idea is to remove that piece of metal entirely and build up the top entirely of painted MDF. I went out to measure for the alternative and see how reasonable it is.

While moving parts around, the display pedestal part tipped over and the front plexiglas panel broke off. Too, the rotary dial came loose. Disaster! I need to go back out later when I am not so emotional about it and look for a way to repair this. If not, I have to scratch the replica entirely from the exhibition.

The mounting of the plexiglas on the pedestal was always a weak point. However, if I can repair this somehow, I can swap in a real rotary mode switch plate from an 1130, given to me by Jeff Jonas, which will improve the fidelity of the replica, although its paint is yellowed (tanned?) and a bit chipped up.

I am still too heartbroken to attempt the pedestal repair, but I do have it all inside where I can work on it once I am ready. Meanwhile, I am focusing on non-replica tasks. It doesn't make too much sense to finish the top, attach covers and test out the electronics if it is too damaged to display.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

-- virtual 1403 line printer --

Carefully reviewing the log file from the GUI, it became clear that my FPGA logic for the skip is where the flaw lies. The stopping points after a skip were always correct, in the GUI, for the current line number sent up from the FPGA. The problem was the current line number being returned.

I will have to test using the LED lamps and some hand code, checking where the logic reaches compared to the known correct answer, then interpolating the flaw from it. I did look over the VHDL code for a bit

I discovered that it was a timing thing - depending on when I polled, I would get various line numbers that didn't reflect where the virtual carriage would stop. I stopped looking at the 'last line number' field sent up from the FPGA, instead keeping track purely in the GUI, and the results were perfect.

I then began testing with different channels in the skip list to see if the function worked properly. I tried skipping to channel 4, which had a punch at each line modulo 4, and to channel 7 which was punched modulo 7 - good results.

I then did a test with skip to channel 1, which gave me a reasonable printout but I could see that the FPGA carriage tape mechanism was running away, cycling continuously. I need to figure out and fix this problem.

It may be a timing issue, in that I reset the line number back to 1 and then do the checks of the ctape buffer output just a couple of cycles later, but my FSM for changing the address of the buffer needs a bit of time before it emits the new address and then the output is available one cycle after that. I added to dummy cycles to let the address change and the carriage control tape buffer output to become correct before I start testing the match of channel bits and the skip list.

As well, I want to reset the 1403 printer to line 1 whenever paper is loaded, thus it has to happen during the process that makes the printer ready. I actually implemented this as a reset of the line number to 1 when the print is made not-ready, so that it will work on any reload of virtual paper.

Back out to test with the new code and the skip to channel 1 program. It still loops perpetually, but all the other skip channels work great. I need to look carefully at my logic to see how I am messing this up, because when fixed, the entire virtual 1403 printer will be fully debugged.

I decided I should change the LEDs to show me the bit for channel 1 on the buffer output, just to verify it was correctly written into the carriage control tape buffer and present for use. I also began thinking about how to break the loop of the 1403 printer. I think it should look at Not Ready and reset immediately, at the same place where I reset the line number to 1.

I tested and confirmed that I am NOT loading the first word of the carriage control tape, or at least not the first bit which governs skip to channel 1.  I looked over the write special data transaction and compared it to the successful version for the 1442 card reader. I spotted a couple of differences, one of which might have caused a timing problem with buffer address changes.

I cleaned up the transaction and reran my testing to see if I now have channel 1 stored in the buffer for line 1. It is still not set. At least my logic to reset a runaway printer when it goes not-ready is working. While I don't understand what is going wrong, I can make a hardcoded decision that anytime we are at line 1, we will have a match on channel 1 during a skip. Lets see how this works out.

All seems good now - the channel 1 skips work properly, mixed skip commands stop on the first matching hole, as they should, and the XIO Sense DSW shows channel 9 or 12 when we are on the relevant line of the page.  I consider this tentatively ready for use.

-- test of three virtual devices working in tandem --

I set up a test where I mounted a version of my DMS2 pack that support 1403 printers on my virtual 2310 drive, mounted paper on the virtual 1403 printer, and booted up the machine. I then inserted a card deck in the virtual 1442 reader and watched it begin processing. I had some issue where it looped up in high storage during the Fortran compile stage.

When I looked at the virtual printout, I saw some random junk overlaying some print lines, which should not happen. Since it was also getting a bit hot in the workshop, I ceased work for the day and will retry this when everything is nice and cool tomorrow. I will also check high memory to be sure we don't have any memory issues recurring.  I did make a small change to the GUI where it fetches the print line, which should make it more reliable. 

Copied real disk cartridge to virtual drive, other preparations for VCF exhibition

1053 CONSOLE PRINTER RESTORATION

My strategy is to work the printer from time to time, in between other tests and work. To do that, I will run DCIP and dump a sector, or run the typewriter/keyboard diagnostic program. I did a run today. Each time I run the 1053 performs just a little bit better. Carrier returns are more reliable now, although they will still fail about every tenth or fifteenth time. The line spacing is the poorest performing function.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Virtual 1403 line printer

I ran a test and recorded the line number that both FPGA and GUI thought they ended on. It matched. However, the GUI is malfunctioning somehow and I need to work out what is going on. I need to correlate the log messages with the carriage tape image and mark down what I think should happen, contrast it to what is reported and then interpolate what wrong behavior is occurring.

PREPARATION FOR VCF WEST

I cleaned up the countertops of the 1130 system late last night. Then, I opened the garage door to pull out my Diablo drive enclosure to get at the jackscrew I need to put into the 1131. The nut that goes on the back of the jackscrew fits into a circular opening in the back of the connector but the hole is so narrow that none of my sockets will fit in there to tighten it up.

Jackscrew ready to install in 1132 power connector inside 1131

This means I will need to laboriously nudge the nut tighter on the screw, using a flat blade of a screwdriver then try to tighten it as much as I can. I don't know what kind of access I will have to get to the connector rear, which is the big unknown. Still, this is the last mechanical 'to do' in the 1131, and important to hold the 1132 power cable secure during operation.

I built a version of DMS with both 1132 and 1403 printers, which will allow me to exhibit with the physical printer but use the virtual 1403 for most work.

I fired up the DCIP utility this morning with a virtual blank disk cartridge mounted and my real internal disk drive readied. I did a disk to disk copy of the internal disk to the blank cartridge. Now, we have a disk image for the IBM 1130 Simulator that directly matches what came with my machine.

It is now shared with the IBM 1130 group on google groups, so that anyone can use it as another reference version of DMS2 with the IBM 1130 Simulator. I did a system reload to make up several configurations - 8K, 32K, different readers and printers - and shared those for the people who wanted them.

FINISHING REPLICA 1130 COSMETICS

Today I measured and marked up support locations on the back side of each faux cover, so that I can cut and glue up the wood pieces for those supports. I have a plan which I can begin implementing tomorrow. 

Running DMS2 from virtual disk, prepping for show, more testing

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Virtual 1403 testing

Both sides are configured with tools to track the line that the printer believes it has reached - using the LEDs to display the line number and writing out line numbers from the GUI.  The first test I ran was with skip to channel 4 requested. The results were erratic, but I spotted a couple of places that could have caused this and modified the GUI.

It will be a bit complicated, because I have two skip mechanisms, one in the FPGA that simulates timing and interrupts, the other in the GUI that adds appropriate blank lines to the PC based "paper" file. Both have to be correct and they need to agree.

Mirror 1053 testing

I cleaned up both sides of the mirror 1053 function. In the fpga, I had logic to save the function code for writes, reads and sense DSW, yet it turns out I won't poll for any of those. I dropped the sense code entirely and just use the write and read to pop in a typed character or grab a keyed character.

The GUI had some funky logic for when it got an 'empty buffer' code up from the fpga which is where I think it was losing characters. I restructured in a more natural way that simply pulls up the buffer contents repeatedly.

The fpga is busy grabbing keyboard characters but my GUI is not processing them at all. No impact on things and perhaps I will expand the mirror 1053 function to also mirror the keyboard, sometime in the future.

I ran another test using DCIP to drive the console printer and it was very solid. I may still be losing about 1% of the typed letters but it is acceptable now.

Mirror 1053 captured file from DCIP dump sector

Test run of DMS2 from virtual 2310 and virtual card reader

I hooked up the 1132 printer again, readied it with paper, brought up the 1130 and attached the virtual 2310 disk drive and virtual 1442 card readers. I booted DMS2 and then ran a job that did 2 Fortran compiles and several DUP actions, then started the game which typed on the console printer.

First page of output of the Lunar Lander deck on the 1130

See my Video of the 1130 running jobstream which is a 5+ minute quick and dirty video of the deck running.

-- Card deck utility program --

The IBM 1130 simulator defined the format for card decks that I also use with the SAC Interface and my devices. There are two general formats - ASCII text and 'binary' - where the latter is actually Hollerith code, the pattern of holes in each of the 80 card columns. My virtual 1442 deals exclusively in the Hollerith or card image format, which is misleadingly named binary format in the simulator.

People who wish to type up card decks for the simulator typically do it in ASCII mode, using a regular text editor such as Notepad on Windows. The choice of which ASCII character stands for each punched card character was set up when Brian Knittel wrote the 1130 simulator in what he called 029 mode. He picked the characters that are on the keyboard of an IBM 029 keypunch, which was the common way to produce cards during the 1130's era, and assigned an ASCII equivalent to each.

For most, ASCII has the same character as the 029, making the assignment obvious. Letters, numbers and many special characters like $ or # are in both ASCII and the 029 keyboard. However, there are some characters that exist only in one or the other. The 029 has a cent sign character but ASCII does not. There is a 'logical not' character which is also found on the 029 but not in ASCII. Plenty of ASCII characters don't have an 029 equivalent either.

Generally, since the overlap between 029 keypunch and ASCII is very high, one just types regular characters from the PC keyboard into a text file and submits it as an 029 format card deck to the IBM 1130 simulator. There is no tool for entering 'binary' or card image files, just a means to view decks and delete or move around entire card images within the deck (Deckview utility from the simulator).

I am designing a simple utility that will take a text file, assume it is in 029 format, and convert it to a card image ('binary') file for use with my system. This will allow visitors to the VCF West show to type up decks and run them on the system.

I had roofers here today to repair some rotted boards on corner of the house, which kept me out of the workshop. A good time to bang together the utility program for converting card decks. I did this as a command line - Python shell - utility rather than a full blown GUI because it doesn't need all that. I leveraged code I had used with my automated 029 keypunch and SAC Interface projects.

After a bit of testing and refinement, it is done. It will pop up a dialog box asking to select the input file, then automatically create an output file of the same name but extension of .bin instead of the .txt or .029 of the input file. It runs through the deck, converting and flags any conversion errors for correction. The output is:

select the 029 or text file to convert
converted 5 cards successfully

PREPARATION FOR VCF WEST EXHIBITION

I looked over the replica and determined that I need to cut out a MDF plate for the console printer opening on the top, also to act as a base for the the display pedestal downtubes. I also need to reduce the height of the existing memory typewriter mechanism or stick in one of my selectrics. I have an I/O Selectric from an old word processing system that is exactly the right size and height, so that goes in and my working mechanism that is too big will come out for the time being.

The front cover in classic blue needs an IBM logo plate - no time to make one out of metal but I have a similar sized plate from an IBM 3803 control unit. Wrong color scheme and of course the wrong box number, but it will look okay on the quick and dirty covers. I placed the faux covers around the replica in my data center shed and like the way it will look.

Replica ready to install faux covers, then work on top

Memory defect repaired, full 16K words working on the 1130 again

FIXING DEFECTIVE CORE MEMORY MODULE

I began by clipping onto the diode packs to test connectivity from the G3 card pins D06 and B13. All diodes are good, no open or short situations. I then clipped leads to the inputs of the diode packs - for the Read Driver (RD) and Write Gate (WG) signals - and tested continuity back to card slot G3 pins for those signals. The WG line had continuity but the RD line was open!

Diode board on core array, diode packs I tested circled

The signal runs from Slot G3 pin D06, over the backplane to slot D5 pin B03. In slot D5 is a jumper connector block that should connect pin B03 to pin B12. From there, the signal runs from pin B12 up through the core array to the diode pack. There are three 'runs' where the break may be occurring, which I will now trace to the failing component.

In any case, I can compensate for this by running a wire to jump over the bad run. This is good news, other than the question of whether this failure portends future failures in similar components that may be more serious to track down and repair.

Specifically, if it is the backplane, I have already had jumpers over failed traces in a couple of locations on each of the two memory backplanes, thus this will be another in a string. The earlier trace failures happened several decades ago.

The earlier failures could have been a manufacturing defect although if it had been under IBM service contract they would have replaced the backplane. That means it was more likely something that developed in later years, before the machine was decommissioned but after it went off maintenance contract.

After tracing, the defect was where I suspected - lack of continuity from pin D06 of socket G3 to pin B03 of socket D5, meaning a failed trace on the backplane. I tacked a jumper wire on the back of the connector block at D5, pin B03 and inserted the jumper onto pin D06 of socket G3.

Lack of continuity between these two pins on backplane

Jumper restoring continuity of signal

The 3467 cards were replaced in C3 through L3 positions, everything tidied up and closed, then I did a test. Using the storage load and storage display CE switch functions, I successfully wrote and read every address in the full 16K of memory. Problem fixed!

Debugging the defect in the core memory, progress on virtual 1403 and a bit of exhibition prep

REPAIR OF DEFECTIVE MEMORY CARD

Before I begin ripping into the card I suspect, it would be prudent to swap the card with an adjacent one, just to verify that the problem moves  When I did that, the problem did NOT change, still occurred at addresses with Y high bit pattern of 011. Thus, the problem is elsewhere. Time to dig into the manuals to see what might cause this specific failure, either another card or a backplane trace failure.

This failure occurs in both halves of the 8K memory block, which is a consequence of it relating to Y addresses which run vertically through the planes covering both 4K sections. The address bit inputs that feed into the G3 card are used to decode one other line each as well as the 011 combination, so they must be good. Thus, my problem is isolated to the output of the G3 card down to the connectors onto the core plane diode boards.

The signal runs from the G3 card, over the backplane, to a connector and then to a set of diodes. The wire runs through the core planes, out to another set of diodes, through a connector and back through the backplane to another card connector. It will be in the first half of that run, up through the diode board wiring.

If I have a problem with backplane traces cracking, this is a long term worry but I can jumper around it for this failure. If it is a connector issue, more difficult but potentially can be bypassed. I also have to check that the other connections to the card socket are good:

• +8.3V
• +6V
• Ground
• Read current
• Read sink
• Write gate current

First up was continuity checking of all those signal connections. If any of those failed to make it to the board socket, I can jumper or wire around the failure. All six showed good continuity, leaving me to check the two signal run from the card socket up to the diode board on the core planes.

The card has a read driver output and a write sink input. Each goes over the backplane to a jumper-connector that carries the signal up through the core plane stack to the diode board on top. Each of the two signals is connected through sixteen diodes to sixteen separate lines that snake through all the core plans.

The diodes from the read driver line are oriented in one polarity while the diodes from the write sink line are in the other polarity. The far end of each pair of diodes is hooked to one of the sixteen lines wound through the 18 core planes. Each of the sixteen lines is hooked to its pair of isolating diodes on our end, but the other end of the sixteen lines connect to read gate/write driver cards

That means that I can't have a broken wire in the core arrays as that would effect only one of the sixteen words driven by our card, but all sixteen words are dead. Thus, the possible problems are:

1. continuity break from G3 card to the connector-jumper
2. corrosion or failure in the connector-jumper
3. broken wire from connector jumper up through core plane to diode board
4. some problem like a short in a diode impacting the entire line

I am a bit nervous about removing the connector-jumper blocks to test because of the age and possible brittleness of the small pins involved. If I can get to a pin on the connector block without removing it, I can resolve possible cause 1 above. I need to work out where on the diode board my signal lines connect, so that I can test the continuity all the way back to the G3 socket.

Another test will be to check each of the diodes to see if they are shorted or open. I think I have to pull all the driver/sink boards first, but then I can do pure continuity testing so it is worthwhile. I spent the evening studying the documents and laying out all the information I need for the testing.

The Y high order address card that handles  011 in bits 9-11, the failing symptoms, sits in slot G3. The Read Driver line runs from pin D06 over the backplane to the connector block at slot D5, pin B03. The Write Gate line runs from pin B13 over the backplane to a connector block at slot K5, pin D04.

In the D5 connector, pin B03 is jumpered to pin B12 which runs up through the core array to the diode card. For the K5 connector, pin D04 is jumpered to pin D12 which also runs up to the diode card. On the diode card, two diode packs are connected to these two signals, bottom right of the pack is the Read Driver and top left is the Write Gate connection. Each pack has four pairs of diodes to drive half the lines that go through the core arrays.

I can reach the diode packs on the board since it is on top of the core module, thus I should be able to check out all the diodes. Also, the diode pack has a line I can check all the way back to slot G3 to test connectivity. This will be my first test - since if I have a break in continuity I can track down that fault otherwise my problem is likely in the diode packs.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- startup test for Xilinx toolchain USB link corruption --

I had built a quick check into the GUI which will allow me to verify the usability of a bit load before I attempt to power on the 1130. Unfortunately, the test passed but it should not have. When I tried core loads and device operation, it failed.

I will need to wait until I have a known bad bitstream in the fpga and then tweak the transactions until I have a way to detect the problem reliably.

-- virtual 1403 --

I had rolled in the correction to the flaw I saw yesterday and reran the test that loops printing a line followed by a space. Bad bitstream but finally made enough trivial changes to get a workable load. In one of the runs, I received a Java array out of bounds exception from Vivado! What a dependable toolchain! Restarted it all and generated the bitstream. The write plus space a line program works great, at real 1403 model 7 speed.

With that working correctly, it is time to test out the skip function, which will advance the virtual page down to the point on the virtual carriage tape where a hole exists in the chosen channel. My default carriage tape has a hole in every channel with varying strides, so that I can validate the operation by counting blank links in my virtual paper file.

I tried with a skip to channel 3, but the output was still lines with one space between them. I need to enable some diagnostic output from the GUI, which luckily does not expose me to corrupted bitstreams. I put in a log to tell me each time we entered the skipping and the spacing logic.

I found a couple of minor flaws in my GUI side logic, one of which allows a subsequent write to arrive before the skip has occurred because of how I go back to polling transactions. Restructuring the flow a bit should fix this.

Upon testing, it got better - I never lost a skip nor a print line command - but I wasn't saving the skip pattern at the time I saved the existence of a carriage movement function. That is, I see a response to a poll that has a space or skip, save that code then process the outcome. It will be a print line if the XIO IW code was also returned from the poll, otherwise it goes to deal with the saved skip or space.

If it does have a print line to handle, the loop resumes and sees that we had a saved space or skip. Rather than poll again for a new print line and/or movement, we go ahead and handle the carriage movement. Once that is done, the loop now does the next poll for a new print line and/or movement.

With that rolled into the GUI code, I think I am ready to vary skip channels to ensure the behavior is correct. I had to rebuild a spreadsheet for the default tape image, where I had each channel spaced by its number, other than channels 1 and 12 which have special meanings of top and bottom of form, respectively. That is, channel 2 is in lines 2, 4, 6, 8 etc of the tape, while channel 3 is in 3, 6, 9 etc. This forms a pattern where a channel number gives you its value minus one of blank lines of skipping.

I set the next test up with channel 4 selected, which should give me the right pattern.
Unfortunately, I got into a loop in the GUI with bad values which I quickly traced to a wrong character in one line of code .

Once fixed, I ran various tests and the output is erratic compared to what I expected. I need to instrument both sides to see what line each side believes it has reached. I will work on this overnight and test tomorrow.

PREPARATION FOR VCF WEST EXHIBITION

I was reminded that the exhibition occurs two years to the day from when I got on an airplane to fly out to Beloit, Kansas to pick up and drive a truck bringing the 1130 system home for restoration. Thanks for the alert, Jack! I will have to commemorate this somehow.

I gave the five covers for the 1130 replica another color coat, as the surface was not even enough in color for my tastes, even for a quick and dirty substitute for the eventual metal doors with powdercoated paint. 

Painting covers for replica 1130, working on virtual 1403, other devices and defective memory card

CORE MEMORY FAILURE IN 1131

The consistent failures with addresses of the form B'xxxxxxxxx011xxxx' in the high 8K compartment points at addressing card type 3467 in location G3 of the compartment. This is called a high Y address read driver/write gate card, each card implements four circuits thus the suspect card covers 000, 001, 010 and 011 drivers.

I had diagnosed and repaired a very similar card back in 2014 - http://rescue1130.blogspot.com/2014/10/memory-addressing-card-repaired-all.html so this was not likely to be a major problem. The biggest complication is just making space to get to the compartment to remove and replace the card. I need to roll the entire 1130 unit to the side and then squeeze into limited space at the memory blister end.

My last act of the evening was to push the 1131 over so I could open the memory gate, access the high 8K compartment and pull out card G3 for diagnosis. I can look at the ALDs to decide which transistor(s) are involved in the 011 address block, so that I can test the involved components on the card.

There are two IBM 131 transistors (which can be replaced by 2n3906 types) hooked to B13 and D06 pins on the SLT card that provide the read drive and write gate for the address bits that are failing. Tomorrow morning I will check the transistors, diodes and other circuit elements, as far as possible while they are in-circuit.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- virtual 1403 line printer --

I made a few tweaks to the 1403 logic in the FPGA and put some diagnostic messages in the Python GUI code. My diagnostics showed the space command being executed correctly (XIO Control) but the print line did not appear, whereas it did yesterday. Most likely something I fouled up in my tweaking of the fpga.

My testing uncovered a design flaw in my approach. With the 1130 printer, printing a line and carriage movement are somewhat autonomous activities. In particular, one can issue a space request while the machine is still fetching and producing a print line. Thus, the hand loop I am using for testing issues two XIO instructions in a row - XIO Initiate Write to print and XIO Control to space, then waits for all the interrupts to take place.

My fpga will save the XIO IW function code so that the GUI can poll for it and begin the write. However, it doesn't do well with two back to back XIO such as are used with the printer. Thus, I need to record the write and the space or skip separately, so that one does not overwrite the other while my GUI is handling the operation. This will take some restructuring of both sides, once I figure out a bulletproof scheme.

The key is that one can start a print operation and then immediately issue either a space or a carriage skip, which will be held by the 1403 device adapter until the print is complete. Thus, I could poll and see just the IW, with the Control or Write in a subsequent poll, or the two could both be issued before the poll.

To deal with this, I needed to separate the 'last XIO issued' field into one that holds the XIO IW for a print line, and another that holds the space or skip command. Further, the WCA field of an XIO IW needs to be separate from the WCA from the XIO Write (skip to channel).

Then, the main loop logic has to deal with any combination so that it doesn't forget or lose the space/skip operation.  I changed the Python code to extract the carriage movement operation and make use of it on the next pass through the controller loop.

It was then time to rerun the CE hand loop which had uncovered the flaw in the prior design of the virtual device. Of course, bad bit 4 on the USB link once again, so I had to change and rerun the Xilinx Vivado toolchain to clear the bad behavior.

I was on the right track, but ended up with a spacing loop because my logic to rest the last XIO code wasn't flipping off the intended bits. When I changed it, the bad USB bit problem was back so my next test session was spoiled.

I decided I need a quick loopback or echo transaction in order to quickly spot the bad bit loads without having to turn on the 1131. I looked in the fpga to find such a function then stuck it into the GUI. Now, when the GUI "About" dialog is selected, it will first send a type 18 transaction with word 2 set to 0xFFFF, confirming that we receive that back.

It was time to work on the bad memory card, so I unplugged the system and ceased testing with the 1130 until I have corrected the memory card and its induced parity errors.

-- mirror 1053 console printer --

I had to think about how I might be losing a character from time to time. The fpga should be able to see every XIO Write and stuff its value into the FIFO, so the flaw must live somewhere in my fpga FIFO extract process and/or how I handle things in the GUI.

-- real 1627 plotter --

I checked the logic to arm and disarm the interrupts from the plotter device logic in the fpga. My first try didn't work - because I was issuing a write DSW instead of a write special data transaction from my GUI code. This now works perfectly.

-- real 1054 and 1055 paper tape reader/punch --

I checked the logic to arm and disarm the interrupts from the paper tape device logic in the fpga. My first try didn't work - because I was issuing a write DSW instead of a write special data transaction from my GUI code. The test worked, so that I know the devices must be armed before they will activate.

PREPARING FOR EXHIBITION AT VINTAGE COMPUTER FESTIVAL WEST

I began painting the wood panels I will attach around the frame of my 1130 replica to make it more realistic looking. It was only partially built when I got my real 1130 system and put the replica on hold.

The process is slow but the results are looking pretty good. I paint a first coat of a sand colored "stone" textured spray paint on the boards, which dry in about six hours. Next, I paint the color coat, which is a medium dary gray for most panels, a lighter pebble gray for the upper metalwork of the replica, and my choice of either "garnet rose" or "classic blue".

sample colors

I decided to apply the classic blue as it is the most common 360 era color, although closely followed by the red. My real 1130 system is painted in the relatively rare "sunrise yellow" color. Today I first painted the sand finish on the five panels and let them dry. Then, later today I put the color coat go on.

Faux covers with first color coat applied

The metal work at the top of the 1130 is roughly bent and not coated, so it acquired a light rust covering while in storage. I will spray a rust converting primer on the metal, then layer the stone texture and finally the pebble gray color coat. These will take a few days to complete, with the metal taken off the replica frame.

The remaining mechanical issue on the 1130 is the lack of a jackscrew for the power connector from the 1132 printer. The connector was missing that part, but I have a spare jackscrew I can salvage from the SAC Interface connector on the expansion unit that came with my 1130. That unit connected a dot matrix printer as if it were a 1403, and connected a Diablo 31 drive as if it were a 2310.

Jackscrew to move over to 1132 power connector in 1131 box

I need to create a utility to convert PC files in the IBM 1130 simulator "029" format - essentially ASCII plus unicode with a specific translation to hollerith - into the simulator's "binary" format which is pure hollerith. This will allow visitors to the exhibition (and me) to create jobs and programs using Notepad or similar programs, the convert them for loading into the virtual 1442 hopper. I can scrounge parts of my 1130 GUI to build this converter. 

Prep for VCF West, testing, boot up and running DMS2 from virtual 2310, virtual 1422 and real 1132 peripherals, bad memory card

DIGITAL GAME MUSEUM TIME

I am a board member of this museum and visited today to talk with another board member and restoration staff. Recently the interior was reorganized to make the collection more space efficient, using rolling shelving, and to establish a playable game space in the back. It looks great and should make for a more enjoyable time for visitors to the museum. I was back by mid-afternoon and working on my 1130 systems.

1053 CONSOLE PRINTER RESTORATION

I ran the keyboard/typewriter diagnostics a few times, which helps loosen up the machine and make it type more accurately. Already the carrier return is more dependable, although I still have erratic line advancement due to goopy adhesive in the mechanism. Typing itself looks pretty good now.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- mirror 1053 console printer and 1131 keyboard --

First up was the fpga engineered with appropriate diagnostic LEDs for the state of the mirror 1053 driver. It exhibited the special USB bit rot, dropping bit 6 this time, rather than bit 4. I made some other changes to set up arming and disarming of the 1627, 1134 and 1055 real devices from the GUI. Unarmed devices can't trigger interrupts.

The changed code went through - no spurious interrupts and no dropped USB bits. My test, however, uncovered a flaw in my GUI code in the sequence in which I look to see if I should arm or disarm the device. I moved the code up to the right place. Too, I found a few places where the state machines for the mirror driver would take action, yet they should be inert if the driver isn't armed. .

My next test resulted in a hung transaction engine, perhaps when I was firing off the arm and disarm codes. I needed to look over this part of the fpga carefully, then spotted that I wasn't ending the write special data transaction.

I fixed the problem and saw that the device armed properly. However, it didn't disarm when it should have. Further, when I tried to load core I had the bad bit problem over the USB so had to rebuild to clear up the spurious error. I did spot the problem with the disarming, which is only in the GUI so I have to make some change to the fpga just to force a good synthesis.

The mirror device worked pretty well. It missed about one character in 30 when the program was typing at full speed. I need to look for a flaw that will lose a character sporadically. Otherwise it looks good, except for an error check issue on the arm and disarm push transactions.

-- virtual 1403 printer --

The next device I debugged was the virtual line printer. It will be helpful if this is working for the exhibition, to give attendees a PC file with the printout of whatever they run on the real 1130. Also, it will free the 1130 from the heavy CPU load required to drive the 1132 printer.

I set up a print line and test program to print a line and space, over and over. It appears to be going to the next page, not skipping a single line. There is also a small flaw with the error check on DSW pushes. I will set up 1403 oriented diagnostics

PREPARING FOR VCF WEST EXHIBITION AUG 6-7

I had listed work to do on both the real and replica 1130 systems in yesterday's post. Today I worked on the cable holder for the memory ribbon cables and replacing the front plate in the kickspace below the keyboard. The cable holder had been glued to the underside of the typewriter pan, above the logic gates, but had come loose. The pan is a very glossy and slick enamel, not very suitable for adhesion.

Instead, I cleaned, roughed up and prepared the inside of the kickplate then epoxied the holder there. The memory cables will hook into the holder there and be out of the way. Once it was very solid, about an hour after gluing, it was ready for the kickplate to be reattached. This plate does in the footwell under the keyboard and typewriter, forming the visible cover when someone looks in from the front.

I couldn't find three of the four original bolts that held the kickplate on, so it was off to a hardware store to get what I needed. While I was there, I bought a 4 x 8 sheet and had it cut into the five covers that will go on my 1130 replica. These will be painted - four in medium-dark gray pebble finish and one in either garnet rose or classic blue, whichever of those colors looks more authentic.

The painting will take place tomorrow, first a sand texture coat and then the color coats. I will leave the backsides plain in order to glue mounting brackets onto them. I have a notion for how to mount the panels on my metal frame.

The kickplate is in place and the memory ribbon cables securely engaged in the holder that I epoxied to the plate. I used a couple of rubber bands to keep the cables from slipping out of the holder. The plate is solidly in place and cables routed properly.

The remaining two tasks on the cosmetics list are to secure the 1053 power connector to the SMS connection panel deep inside the 1130, and to repair the mounting screw for the power connector from the 1132 printer.  The SMS connector panel is now buttoned up nicely, so all that remains is to figure out what parts I need for the female power connection on the 1131, so that the male power connector from the 1132 will mate with it.

I powered up the 1132 in order to check out its operation, booting DMS2 from a virtual disk cartridge and running jobs from the virtual 1442. It booted fine, printed the welcome banner on the 1132 and I fed in a deck of cards with a job to compile some fortran code. The machine was in the midst of the fortran compilation when it stopped with a parity error. Up until that point, all was going well.

running a job from virtual 1442 on system booted from virtual 2310

This could be an issue I have to deal with concerning my virtual devices,although more likely this was residual junk in high storage and a flaw in some software since the address being referenced was up above the 8K line. The DMS2 disk pack for the 1130 simulator was built for a 16K machine which should mean no addresses beyond 0x3fff will be generated. I will clear memory so that it writes correct parity everywhere and try this again later.

To check out the memory, I made use of the CE Switches built into the 1131, specifically the Storage Load and the Storage Display switches. These will cycle continuously through all memory addresses, writing the console bit switch values into memory, or cycle continuously reading memory. Even when good data is supposedly written into memory, the Storage Display runs into a parity error when it reaches a memory address in the second 8K.

So this is good - I don't have a flaw in my SAC Interface or virtual devices that causes parity errors - but bad - because there is a hardware problem I need to fix. As a safety measure, I will generate a virtual DMS2 system with 8K of memory that can run at the show without touching the upper 8K. I will make sure that this 8K system boots up and runs several jobs to completion on my system.

The 8K system boots, confirms it is 8K, but something branches up to 0x3xxx and hits the parity error. At first I though it was a problem with the Fortran compiler, so I set up a deck to execute DUP but that had the same failure. This needs investigation.  See section of memory failure.

I have a few advertisements for the 1130 and some textbooks, which I will bring to add to the flavor of the exhibit. I need to figure out how to display them, secure and protect them, and keep track of them during the show.

1131 CORE MEMORY FAILURES

I walked through memory addresses and determined that the parity errors happen for specific ranges of addresses in the second memory compartment (addresses 0x2000 to 0x3fff). Any address in that compartment that has address bits 9 to 11 is 0b011 will fail. 203x or 20Bx, 283x, or 28Bx, 303x or 30Bx, and 383x or 38Bx. I have to find a card related to decoding 011 for drive lines and figure out what is wrong with it. 

Virtual 2310 disk drive working, plus preparation for VCF West exhibition of real and replica 1130 systems

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- virtual 2310 disk drive --

I had discovered a problem with the way I was modeling the busy bit for the DSW. It led to an error stop in the DMS Cold Start card program. I worked out a more faithful method and implemented it, ready for testing this morning. The virtual device will go busy as soon as it sees a seek, initiate read or initiate write command and will switch off when the operation complete status is triggered.

I had also switched around the diagnostic signals on the LED to the most useful ones related to the virtual 2310. My first attempt I found the sporadic bug where Vivado leaves me with bit 4 of the USB not working, but a new pass of the same logic through the toolchain should clear it up (wasting 15 minutes). Alas, same problem so trivial change and ran it again. Still bad. Made a more substantive change and tried that.

Finally I was free of the phantom missing bit 4 problem and could resume testing. I made it quite a bit further past the earlier point in the boot card sequence, with the system stopping at location 0x01FE which I think is somewhere in the boot sequence. As well as this problem, I noticed that if I attempt an XIO to the disk drive when it is not ready, it still kicks off the state machines or tries to perform the action. I need to make it obey the not ready condition more fully.

With those changes in place, I went out in the afternoon for more testing. First, I wanted to verify that it was inert as far as XIO when the device is not ready. Then, I wanted to investigate the behavior of the boot sequence more fully.

I had closed up the SAC Interface box, in order to have it ready for transport and exhibition. I don't know if I dislodged some wiring or whether this is a random Vivado corruption of the bitstream, but when I turn on the 1130 the SAC box is commanding interrupts on IL3 and IL4. I attempted a change to the logic and a new bitstream generation just to rule this out. If it is not the toolchain, then I have a hardware problem in my interface box.

Another idea came to mind. I had a highspeed link between an auxiliary fpga and the main one, in order to handle physical peripherals such as the 1627 plotter and 1134/1055 paper tape devices. I removed it, taped it over and put it inside the SAC unit.

However, if spurious signals on the line are interpreted as device signals, they could be generating interrupts. The devices just mention happen to interrupt on IL3 and IL4, which does match the symptoms. I blocked the interrupt requests for those devices and resynthesized.

I still have hot requests for interrupt levels 3 and 4. I decided to work on eliminating the devices in swathes until the IL level is gone, then reintroduce until I figure out what device is giving me the problem. At least the testing is quick - power up the fpga and the LED goes on right away if the problem persists.

With only eight of the 20 devices left, I still had a hot IL4 signal. I moved to the extreme, removing all of them so that the line is held low. Now I have seen everything. I have a signal, IntReqLvl4, which is set to '0' yet the diagnostic LED shows it '1'. This makes no sense. I am spreading the signals to other LEDs as well, for no better reason than to insist on corroboration.

With the signals spread over the LEDs, I could see that only the one I 'thought' was IL4 is still lit. I powered up the 1131 to verify and indeed there are no interrupt requests presented. I then went back and reset all the twenty devices back into the IL4 chain and resynthesized.

Every device back in, yet no interrupts being requested. It was one of two causes - either the high speed link issue for plotter and paper tape was bad but I fixed it earlier, or the toolchain is at it again. At this point, as long as it works properly I will get back to testing the disk after four hours of frittered time.

Something is not quite right, yet, although it may have worked. I saw the boot program read from disk into 0x00d0, the read the next sector into 0x0122, and finally read sector 2 into 0x0004. This is when the look sat at 0x01F4, possibly waiting to print to the 1132 line printer. I should do this test with the printer powered up and ready, just to see what happens.

I am not entirely sure if the disk image was set up for a 16K machine. If configured for a different memory size, it may not work properly even if my disk emulation is perfect.

I took the opportunity to load the keyboard/console diagnostic, which worked well. The 1053 types great, although its carrier return is still defective. It needs a helping hand to move it back to the left. The keyboard worked right, also.

I need to do some investigation of the boot sequence and of the disk image whose PC file I am using, to determine whether things are working okay or not. I may have some timing related problems in the virtual disk, particularly if it is too quick on the read.

The sectors being read are the correct ones for a boot. I need to do more testing of my disk device to ensure it is really working properly. After closely examining my GUI code, I think I see a flaw that might have caused some of the problems. It is changed and I am back out to test.

Success! DCIP began typing out the sector I chose on the console printer. It looked really nice, so time to bring up a test boot of the DMS disk once again. This time, it flew through quite a few fetches until the full DMS2 was up and waiting on device 6 - the 1132 printer - to become ready so that the DMS banner could be printed.

-- mirror 1053 console printer --

The next device to work on is the mirror 1053 function, which should capture a replica image of what is typing on the console, placing the contents in a PC file. This uses the FIFO, the remaining Xilinx IP unit that is giving me the obscure 'black box' error messages. I will begin debugging this tomorrow, while I work on the remaining cosmetic and testing items for the real 1130. When that is done, I will move on to the 1130 replica and its readying for the exhibition.

PREPARING FOR VCF WEST EXHIBITION

I have a few tasks to prepare the 1131 - the main unit of an 1130 system, consisting of the central processor, console printer, keyboard, internal disk drive, display pedestal and other controls:

• Attach cable holder and route the cables from the processor gates (A and B) to the 'blister', the expansion frame to the left of the keyboard where the memory sits in larger configuration machines. 
• Refasten the clamp holding the 1053 console printer power cable to the power connection point inside the 1131
• Replace the front facing machine cover that sits under the desk
• Work on replacement threaded screw for 1132 power cable where it attaches to the rear of the 1132

My replica 1130 needs several tasks to make it ready for exhibition:

• hardboard panels cut and painted to fit on frame in place of metal covers
• prime and paint metal top of replica to pebble gray IBM color and texture
• reload fpga and reconnect cabling to pedestal, keyboard, other controls
• shorten pedestal stand and anchor in place for show
• decide on appropriate printer mechanism for show

The replica consists of a life size welded frame shaped like a small memory 1131 (no blister), a display pedestal, the formica desk top, keyboard and other controls. I have a roughly bent sheet metal top that fits on the frame and under the formica white desk slab.

Link to video of 1130 replica running (viewing display pedestal)

Keyboard and control panel before mounting on frame

The pedestal with the blinking lights and rotary control is temporarily mounted on wooden stands which need changing to set the unit firmly at the right height and position. I have an IBM Memory typewriter sitting on the metal to serve as a 1053 console printer, but I don't have the cover manufactured for it yet. Similarly, I have the console bit switches on a mounting plate but not the final plate that sits in front of the 1053.

Today I tried to buy the hardboard panels and get them cut to serve as the 1131 covers. The first Home Depot had the hardboard sheet but their panel saw was out of service. The second Home Depot a few miles away also had the hardboard sheet and also had an out of service panel saw. The Lowes a few miles further had a working panel saw, but zero hardboard panels in stock. At that point, I gave up for the day and went back to testing on the 1130.

I closed up my SAC Interface box for transport and use over the next few weeks. I have the temporary diagnostic LED outputs emerging from the front of the case along with the USB cable although eventually I intend to install a more secure USB connector and the LEDs will be replaced with links to various FPGA boards such as disk drive controllers and I/O fanout units. 

virtual 1442 reader and punch working properly, moving on to other testing and work

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- virtual 1442 --

Eureka! I have the copyover (mostly) working now and the off-by-one problem is gone. Unfortunately, I have regressed to the problem where the first column of the pre-read buffer card is copied to every tenth position of the pre-punch buffer, replacing what belongs there. This was an error in my copyover logic that has returned now that I rewrote it completely.

I also have a minor error with the write special data transaction where I wasn't returning word 2 as it had been sent, but that was easily rectified by a snippet of code. Otherwise, this transaction has been working properly for some time.

Once I clean up the every-ten-overwrite problem, I can start debugging punching operations. I need to test with a blank deck of cards (input hopper file that is all blanks), punching a full card and then a short one. The 1442 will check each column being transferred for punching and when bit 12 is on, it ends the punch operation.

If blank cards work fine, the next test is loading a file with data already in the cards. The result of punching should be a merge or row-wise OR of both the original card and the new punched pattern. This will be checked for both full card and short card punching.

The tenth position error is the first word of each get special data transaction, which repeats the value in column 1 rather than starting over with the value in the column 10, 20, etc. It is caused by a lack of adequate time for the pre-punch buffer address to set up from the value delivered in the second word of the incoming transaction, so that it still uses the default value which is column 1.

I added another cycle between the startup and when I latch up values, which should give the buffer address time to settle on the actual start cycle. My next testing opportunity in the late morning showed that it was now working just as planned. Whether reading or feeding, the card images were faithfully copied over and then written to the stacker file on the PC. If reading, the columns were faithfully stored in memory.

Onward to the last items to test - punching cards and the stacker select function. My first try at punching cards did not produce any results. My guess is that the pemitter process didn't work properly, hanging up and keeping the main device process hung as well. I instrumented the LEDs to check various status signals and ran a test after lunch.

It confirmed what I suspected - the main device state machine got to the point where it triggered the punch emitter process, but that process hung. I did see that a punch operation was correctly recognized. Looking closely over the punch emitter process, I found two problems. Both were related to the timing that emulated the delay of a 1442 punch.

I had set up a counter to model the time of the card movement during a punch, but initially the times I used were the same as reading. The punch is considerably slower than reading, however, so that eventually I calculated the correct counts for the timers. I did not increase the size of the counter.

The counter would run from 0 to just over 1 million, which could model a 20+ millisecond delay. In fact, punching incurs an initial delay of 40ms, so I changed the test in the state machine to 2000000 yet the counter only went up to 1000000. It wrapped and cycled in an infinite loop.

The secondary bug was that I didn't reset the timer back to zero before modeling the 6.25ms per column delay, so it would have run from 2000000 upwards. I didn't reach this point because of the earlier bug and infinite loop.

I changed the timer to run up over 2 million, to cover the initial 40ms delay, and made sure to reset the timer before each column delay and before the final delay for card movement out of the punch station. With this changed, I went back to testing on the 1130.

I got punching over the blank card images. My only problem is that the results were off by one, which means I have to focus on my logic for the XIO Write and pre-punch buffer accessing. This is very encouraging, as I realize that I am pretty close to done.

I ran a quick test with bit 12 set on in the 10th column, just to verify that it will punch a short card.  It did, off by one of course but otherwise correctly stopping and leaving the remaining 69 card columns blank. All that is left to verify is:

• get it aligned to the right columns, 
• verify the punch merge function
• verify the stacker select function

Punch merge is a realism behavior I added which will combine the holes already existing in a card coming from the pre-read station with the rows that are punched during the punch operation. If a card deck were put in the hopper of a 1442 that had row 12 punched in all 80 columns, and the program were to punch row 3 in all columns, the resulting physical card would be a string of C characters (rows 12 and 3 punched in each column).

Stacker Select is a function that a program can issue (XIO Control with bit 8 set) that will arm the stacker mechanism so that the next card coming out will be ejected into the alternate stacker, rather than the primary stacker. I open twin output files, once for the primary stacker and another for the alternate, so that if the stacker select function was issued, I will write the card image to the alternate instead of the primary file.

Card movement in 1442

The Stacker Select is not completely accurately modeled. It should only take place during the time that a read, feed or punch is active and before the card would have reached the stacker pathway. It is reset by the completion of the feed, read or punch cycle. My implementation, however, will arm the code to put the next card ejected by punch, feed or read into the alternate stacker, no matter how long the time from select issuance until the actual card movement occurs.

The reason for my off by one problem is that I was triggering the write into the pre-punch buffer from within the print emitter loop, which only determines when we set off IL0. It is the subsequent issuance of an XIO Write instruction by the software in the 1130 that determines the column contents, so I will trigger the write of the buffer as soon as I grab the data value from the E3 cycle of the XIO Write instruction.

Problem solved. Punching reproduces the core contents exactly into the cards and short punching works correctly also. Time to check over the logic for punch merge and for stacker select, then do the final testing. Everything looks ready for punch merge, but it needs testing.

I discovered that my logic in the GUI that was checking which type of XIO Control was not working properly, apparently I am not sending the proper data up from the FPGA. Inspecting the code makes it appear that I should see the proper modifier from the XIO Control, but the results differ in real life.

My late afternoon testing was to test the punch merge operation, which would take a hopper deck with known contents and a prepared punch area to see if it merged properly. In addition, I tried out the stacker select operation.

Everything worked perfectly. When I open a file for the input hopper that already has holes punched in the cards, they are properly merged with the holes being punched by the program. Stacker selection causes the next card to be fed, read or punched to go into the alternate stacker file on the PC, rather than the primary 'stacker'.

This wraps up the virtual 1442 capability. Later, after I get my system back home, I will work on the mirror 1442 capability, which will capture cards as they are read and/or punched on a real 1442, storing them in a PC file. I don't need this, but it will be quite useful for other 1130 operators such as the National Museum of Computing in the UK.

-- virtual 2310 --

I attempted to test a boot of the virtual 2310 disk drive, using a cold start card booted from the virtual 1442. When the cold start code began, it stopped with the keyboard select lamp illuminated and an interrupt on IL4, which is definitely not what should be happening. I created a memory load of the boot card, just for convenience, as I chase down this flaw.

One possibility was that I have a defect in my mirror device logic causing it to interfere with the real device operation. The boot card reads from the console switches to decide which drive is being booted, so if this is inducing an error while the XIO to the console switches takes place, it might explain the symptoms.

I decided to hand step the boot card logic to see when the problem arose. The logic of the boot loader is to check that the busy bit went on for the drive, otherwise go to the invalid boot device wait at 001E. Single stepping will cause this to happen, even if the disk is valid, because the XIO Sense happens after the I/O is complete.

I have to verify that my logic is setting busy correctly and holding it long enough to be seen by the boot card program. Inspection of the program shows that it is not accurate as far as a disk read or write is concerned. I will display busy during a seek, but when the operation is a read or write, I shut off busy as soon as the XIO IR/IW completes, not when the disk is done. Will have to modify the design a bit. This is what I will be testing starting tomorrow.

CLEAN UP MACHINE COVERS IN PREPARATION FOR MOVE AND EXHIBITION

I replaced all the internal cosmetic covers in the 1442 - these are plastic plates that cover various parts of the machinery. I then replaced the front skin that had been removed while I worked on the machine. Still to do for the physical 1442 - fix up the status lamps and adjust the card feed into the stackers.

The lamps suffer from the same age degradation where the leads on the lamps snap off with the slightest movement, making it nearly impossible to get a full set of working lamps back behind the status panel. I left them loose for the show, since they are hidden inside, and will work on this when the equipment is back home.

The physical cards move from hopper to pre-read, through the read station to pre-punch, through the punch to the cornering station, then out into the stacker mechanism. The cards make a right angle turn in their motion at the cornering station. Cards are not reliably turning and moving through the stackers, which is a matter of adjustments of a few parts at the station and stacker. This is something I want to adjust before the show. 

Still fighting 1442 copyover plus replacement 1403 printer chain created

1401 RESTORATION TEAM WORK

Wednesdays are the day I visit the CHM to meet with the rest of the team and repair anything that is not working on the two 1401 systems. We had two problems related to one of the 1403 printers - a driver card had a blown fuse, and one of the print solenoid coils that fires a hammer partially shorted and burned.

I repaired the driver card, using new-old-stock fuses we have to solder it in place after removing the blown component. Other members cut off the burned coil, soldered in a new-old-stock replacement and put the printer back together.

In addition, we received a 1403 type chain, manufactured by one of the team at the museum in Binghamton, NY. We will install this in a train case and try it out on one of our printers, as a test of the process he used. If it works, it will allow us to make multiple print chains for use on our two 1403 printers and the 1403 printer at the Binghamton facility.

We have been worrying about the fragility of the chains given the complexity of making replacement parts, so this is an exciting potential source to allow us to keep these systems running indefinitely. Once the chain passes tests, we will send a couple of people from the CHM restoration team out to NY to learn how to make more.



SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- virtual 1442 card reader and punch --

I tested the feed operation - will advance a card without emitting IL0 interrupts or causing reads to take place. My logic worked properly for this as well, so that both card reading and card feeding are solid.

I still have a problem with the copyover. The data I see coming out of the pre-punch memory for card column 2 is the value that was in column 1 in the pre-read memory. They use the exact same address and I see the correct value on the input lines to the memory when it is written a cycle or two before I sample it. Inexplicable.

At times like this, when I can't find any logical reason for the flaw, I try rewriting the section of logic, often with a slightly different approach, hoping to eliminate whatever obscure cause was generating my problems. I decided to change way I locked in the buffer memory addresses, even though the exact same string is used for both memories.

I was setting up the address with a mux, selecting one leg when the copyover process has moved away from idle state. The leg has  std_logic_vector(to_unsigned((copyidx+1),7)) as the source of the address. This takes the integer counter copyidx, adds 1 to it, then converts it from an integer to a SLV with one signal per binary digit comprising the integer value. This was implemented at a time when I had a special use for buffer address 0, but it is no longer relevant.

It should take the value of copyidx, which is stable for several clocks around the time it matters, run it through an adder with a constant of one as the other operand, then route it as the memory address. I don't know how it could be getting this wrong, but I will change all my logic so that I use the index copyidx as it is, ranging from 0 to 79, eliminating the need for an adder in the address mux.

I also put in some diagnostic LEDs to compare the value in the data in lines and the data out lines for the pre-punch buffer, at the time we are looking at card column 2 in the copyover and have completed the write. I am finding that I am unable to update the pre-punch buffer memory even though I trigger the write and set the write enable flag.

I did see a type mismatch - the replacement VHDL I wrote to infer block ram used a simple signal as write enable, but the block box IP I had been using had a std_logic_vector of length 1 instead. I cleaned up all the code to be consistent and retested.

I still see a mismatch between the pre-punch memory input and output - indicating that it is not storing the right value. It agrees if the input is 0, but if the input is a 1 then we see a 0 on output. Oddly, some conditions give me a 1 on the output, but not the cases where I expect it to happen.

For the time being, I moved to the get special data routine which is failing to pick up the data from the pre-punch buffer (or that data is always blanks). I continue to hit a brick wall on this.

With some lingering suspicion that the block ram may not be working for some obscure reason, I set up the block memory module to force it to use distributed RAM rather that block RAM. This means the memory will be implemented using lookup tables throughout the FPGA rather than the dedicated block ram units on the chip.

Sadly, the results were exactly the same. I have cleared the reputation of the block RAM and toolchain, Back to allowing it to be implemented as block RAM and back again to the struggle to figure this out. I keep trying to change things in the hope that it resolves the problem but no luck so far.

1442 reading perfect, but still copyover problems

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- virtual 1442 --

Made a few tweaks to the copyover logic, particularly the way the buffer memory addresses are created. Now they are registered to avoid passing glitches as various selection signals transition, particularly state variables which might pass through unwanted states momentarily.

This made zero difference in the results - still blank cards coming out of the pre-punch buffer when I fetch them to the GUI. I validated once again that the card image in the pre-read buffer is properly read into core during a 1442 read operation. Still unclear whether this failure stems from the copyover process that moves a card from pre-read to pre-punch, or whether it is a defect in the get special data transaction fetching the pre-punch buffer.

I went back to the diagnostic traps, trying to catch column 2 during a copyover, setting one lamp if the high bit of that column is 1, a different lamp if the high bit was 0. At least one of the lamps will light if I catch column 2 during a copyover.  This tests that the pre-read buffer still has the proper card image at the time that the copyover is running. As you will see, this is a time consuming, exhaustive search for the place where the problem starts.

My first tests proved that the data was coming out of the pre-read buffer during the copyover process. The open questions are whether it makes it into the pre-punch, whether it is still there on get special data fetch, and whether something overwrites it before delivery.

Next, I moved the traps to see what the high bit of column 2 of the input to the pre-punch buffer is seeing at the time that the copyover is writing to that buffer. This will tell me whether the data is presented to the pre-punch buffer for writing.

This too worked properly. I have two decks to run into the 1442. One has the 12 row punched in column 2, while the other does not. The various lamps worked as expected, thus the data is set up as input to the pre-punch buffer during copyover.

Next, I set the traps to tell me what is coming out of the pre-punch buffer after it was written, for the high bit of column 2 during a copyover. This will confirm it was actually written into the buffer. The results highlighted where the problem lies. The value in column 2 of the pre-punch buffer output is the same as what was written in for column 1. Some interaction here is introducing the off by one problem. Clearly, that is separate from the other problem where only blanks are returned to the PC.

I changed quite a bit and still see the same outcome - no idea why this is not working, but it could be some flaw with how Vivado is implementing the three built in block ram instances. There is an obscure message about problems with black box instances, which I can't sort out even after reading all the documents and web pages related to the message.

I decided to infer the block ram with VHDL, coding up a module 'blockmem' based on the exact template from Xilinx documents. This way I will avoid the 'black box' confusion and should have discrete memories for all three buffers (two in the 1442 and one used for the carriage control tape of a virtual 1403).

My first try to test this resulting in the spurious lack of bit 4 on any USB transmissions, which I cure by making a trivial change and resynthesizing to replace the corrupted bitstream with a good one.
Bit 4 problem went away, but still not seeing the stored value from the pre-punch buffer that I see on its input. Time to look closely to make sure I am actually toggling the write enable - not sure what else could be the problem.

I did more tweaking and checking of the behavior when the hopper runs out, but with and without the last card box checked. Everything is working like a charm. At this point I have a good card reader, but it won't produce the stacker output file that will be essential for punching.

Time to rebuild the copy over process in its entirety. More tomorrow.