testing of rewritter 1442 buffer handling logic, 1800 and 1620 news, and work on high speed link resilience

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Debugging the virtual 1442 functionality

I finally had a chance to test my rewritten logic for handling buffers at lunchtime on Friday. I found that column 11 was correctly extracted from the pre-read buffer during the copyover process, validating that it was not corrupted in loading nor in the process of handling the XIO Read instructions.

What has failed is the logic to fetch the contents of the pre-punch buffer before doing the copy-over. I always get spaces regardless of what card was in the pre-read buffer. Since this is further down the chain, but my successful test above showed me that the data was still in the pre-read buffer while copy is underway, I will first chase through to see if there is any corruption before I work on the fetch transaction problem itself.

I altered the code to a couple of times and retested:

• 1- latch what is now in the pre-punch buffer after I have written the word in copyover
• 2 - latch in what is pulled from the pre-punch buffer when the data is fetched back to the PC
• 3 - latch what is pulled from the pre-punch buffer by the fetch transaction

These are intended to find the first point where data is corrupted, permitting me to isolate the problem and fix it. I will also see after the first one above whether the pre-read contents made it correctly to the pre-punch buffer. By methodically isolating where problems arise, I can zoom in on just the offending logic.

Test 1 showed that my copy-over didn't seem to be writing the output of the pre-read into the pre-punch. That would cause the downstream error of seeing only spaces from the fetch. I tweaked the copy-over logic, looked it over at the same time, and prepared for a late afternoon test.

Part of my test for the afternoon, as a latched in the contents of column 11 in the pre-punch buffer right after the copyover routine had written it to match the output of the pre-read buffer, was to see that the input and output of the pre-punch buffer was the same. If not, I had a functionality issue with the buffer component.

Somehow I am now getting nothing in the read buffer by the time I try to copy it over. I checked memory and I now have nothing in memory either. WTF. This all ought to be simple stuff, easily debugged and checked off, but it has burned a couple of weeks of admittedly restricted access to the machine.

I realized that previously today I was testing with XIO Control Start Feed, but changed to XIO Control Start Read which invokes the IL0 interrupts and handles XIO Read. I looked at my rewritten buffer control logic and found conditions where the buffer read and write machines would stall. I fixed the issue but will also revert to testing simple feed through until I get the card images moving all the way through the virtual 1442. Then I can debug the read and punch actions.

Early the next morning I went out to test the new logic. Interestngly, rather than having column 11, 21 etc overloaded with the content of col 1, but the remainder of the card image okay, I now have all blank cards except for column 12, 22, 32, etc which appears to match the input file. I did verify that the buffer control logic is not stalling.

Seems I need to interlock the fetch, copy, read/write and push transactions with the buffer control, since these take several fpga cycles to process each read or write but the transactional logic advances at full fpga speed. This turned out to be more convoluted than I first thought, with the need to maintain setup and hold times for addresses but still trying to cycle the buffer FSMs at the right time.

The key is to build solid interlocked buffer processes, then add the steps to the calling FSMs to be sure it stays in sync. I updated the buffer FSMs first, then rolled in the calling sequences to the five callers (push card image to pre-read, handle XIO read from pre-read, handle XIO write into pre-punch, fetch pre-punch buffer contents, and copy from pre-read to pre-punch.)

Debugging should be a matter of fnding stalls and verifying set of data at the proper moments. First test found a stall in the pre-punch buffer process during copyover. Once I had the two buffer processes free of stalls, I redesigned the copyover to separate reading of the pre-read from writing to the pre-punch, eliminating any timing trickiness. It takes more cycles this way, but compared to electromechanical reader/punch speeds, it is invisible.

Improving resilience of the high speed link between master and slave FPGA boards

My master drives a sequence of data bytes to the slave, with an idle pause between each round. Thus the idle is a restart point to force the machines to get back into sync if an error occurs. I will put a timer on the input process for both slave and fpga, reset at the idle point and counting down independently while the input process steps through bytes.

If enough time elapses and we have not returned to the idle point, it constitutes a fault that will drive every step in the input process back to the idle point. As well, a fault will drive the output processes back to idle, so that the link machine on each side is forced to idle waiting on input and the master is ready to initiate the next round.

IBM 1800 and 1620/1710 RESTORATIONS IN FINNLAND

1800

The 1800 system being restored by Johannes Thelan is properly executing all instructions entered in hand loops. He is still validating functionality but it looks quite solid. With the core of the system in good shape, he will turn his attention to peripherals and extentions modules, I guess.

1620/1710

Johannes will also be accepting this IBM 1710 (a 1620 with some process control additions), bringing it from its current home to his workshop to start the journey towards restoration. A similar but earlier restoration at the Computer History Museum found that something about the solder or rosin or other materials used in the construction of the 1620 core memory caused the connections of the fine sense and drive wires to corrode at their connection points. The memory was not salvageable at the time.

System to be restored in Finnland

What is unknown is whether this was a systemic flaw, so that all 1620 memories would similarly degrade over time due to an unfortunate choice of materials/process, or if this was due to local repairs to the one machine at CHM prior to their accessioning the system. When Johannes transports his machine, he can examine the condition of the core modules and answer this question. Cotemporaneous core memories built by IBM in systems like 1401 did not suffer this problem, so we can be hopeful that it was a one-off issue and not a plague upon all 1620 units.

3D PRINTER SETUP

The extruder was giving me problems, something I have to sort out in order to move on to good prints. I cleaned it out and assembled it, then dealt with several nuts and screws having loosened and failure of the connection to one of the microswitches for the Y axis far limit. I will resolder the limit switch wiring right away so I can make another test print.

What this really needs is loctite for the threads on some of the nuts and bolts that have loosened, particularly when they are holding compressible plastic parts yet have no lockwasher. The allen wrenches provided are cheap quality and have rounded off too much already. I need to get better tools and go over all the connections.

The fine-tuning, once all the parts are together and working, deals with getting the bed level and at the right height, the temperature of the nozzle correct and doing other tweaks to get the prints coming out with sufficient quality.