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

1053 CONSOLE PRINTER RESTORATION

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

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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

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

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

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

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

Mirror adapter for 1053 produced proper output matching typewriter output

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

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

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

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

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

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

1053 CONSOLE PRINTER RESTORATION

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

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

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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

Other aspects are not yet satisfactory:

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

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

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

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

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

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

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

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

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

1442 CARD READER/PUNCH RESTORATION

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

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

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

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

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

Working on FIFO code in SAC Interface Box

1053 CONSOLE PRINTER RESTORATION

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

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

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

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

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

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

Repaired the color shift tape for the 1053 console printer

1053 CONSOLE PRINTER RESTORATION

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

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

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

Test loop to verify bond strength on wrong length tape

Repaired tape end ready to be reinstalled in 1053

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

SCANNED AND SHARED 1053 CONSOLE MANUAL

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

Done with System Load deck work

SYSTEM LOAD DECK WORK

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

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

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

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

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

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

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

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

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

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

WILLIAMS TUBE MEMORY PROJECT

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

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

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

Load deck cleanup and a bit of work on 1053 restoration

1053 CONSOLE PRINTER RESTORATION

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

SYSTEM LOAD DECK WORK

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

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

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