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.