Rescue 1130: 2014 Pickup of an IBM 1130 System and More: SAC Interface Box working correctly for all XIO types - ready to support devices

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I believe I found the flaw in the shadowing logic that would inform the XIO Read module when it was in the E3 phase - the point when it has to assert the data value on Channel Data In and raise the Channel Write Gate signal.

I could use some diagnostic outputs from the fpga so that I can tell what is occurring. Once the two way link is working I can send diagnostic info over that, but in the interim while I am working on the link itself . . .

There are several FPGA pins that are not currently used and accessible from the remainder of the AB and CD connectors. There are 24 potential signals to use, although four may be restricted from access mechanically due to the connector hooked to the driver/receiver boards.

While I could drive an LED on any single line to about 30ma safely, To be sure of protecting the FPGA chip, I used a high-ish limiting resistor giving me a faint illumination. I set up 16 lights initially, leaving four connector positions for future expansion of my diagnostic input/output.

I used it to check my state machine fix for determining when the 1131 is in XIO phases E2 and E3, as well as double checking the validity of the XIO type bits at the time I am sampling them. I spent a bit of time getting the lights working to my satisfaction which required smaller resistors, before moving on to the debugging of the XIO phase shadowing. One of the 16 is not working, probably due to a wire breaking off the fragile connectors, but if I disturb the wiring to fix this, I will likely break others.

Next, I discovered that none of my shadowing machines are advancing, but also I wasn't seeing DCReset or other signals I should. Something pretty basic is awry here. I am not sure what changed, but suddenly it was all working properly when I resumed testing. The great news is that an XIO Read is doing what it should - storing the data value from the peripheral device into the core location specified in the instruction's IO control word. I changed the data pattern and location just to double check, but it works nicely at both single step and full speed.

XIO Read (stores data into core storage)

I then moved on to some instrumentation using the lights to verify that XIO Write will lock in the data value from a core memory location specified in the IO control word, making it available to the peripheral device. Another test was that XIO Control picks up and saves information from the IO control word which will be used by the peripheral

As well, I checked that the XIO Initiate Write picks up and saves the memory location of the Word Count Area, a table with a word count as the first location and then data is stored or fetched from sequentially increasing addresses as the peripheral does its IO.

XIO Init Read and XIO Init Write

The test of XIO Write was successful - it picks up both the modifier bits from the second word of the IOCC and it latched the data fetched from the core location stored in the first word of the IOCC. Similarly, the XIO Control succeeded, locking in all the bits from the IOCC word 1 and modifier section of word 2.

IO control word and write count area

The test of XIO Initiate Write was unsuccessful, failing to latch the data (or resetting it at the end of the instruction execution, which is equally useless). Looking through the logic for the XIO Init Write, I found the problem was even simpler. Since XIO Initiate Read and XIO Initiate Write both fetch the WCA and modifier bits, leaving the IO device adapter to handle read or write, the two modules are essentially copies of each other. Too much so, because my XIO Init Write didn't look for the XIO type code "101", it was still looking for "110" which is what was in the XIO Init Read code.

Corrected logic was tested and now both XIO Init Read and XIO Init Write are working perfectly. All seven XIO function types are ready to use, as well as fetch and store using cycle stealing. The box can trigger interrupts on Interrupt Levels 2, 3, 4 and 5, as needed. This completes the 1131 side of every IO adapter - the other side is concerned with signals to and from the specific device being controlled.

Cycle Steal operation

If I can get my PC link working properly, I can put the device side of an IO adapter into the PC, creating various virtual peripherals. The bulk of the functionality needed to complete the support of virtual devices will be complete when the PC link is working properly.

The other purpose of this box is to support various physical peripherals, building their IO adapters fully in the fpga or in a hybrid of the peripheral and a microcontroller such as an Arduino. I have a backlog of physical devices to implement - additional disk drives (my CHI drive and several DEC Rk05s), a tape drive, paper tape reader and punch units, a plotter, and a 2741 typeball style APL terminal.