Some work on the Channel Address In flakiness

I have a trip this week to Washington DC which will take me away from the restoration for three full days. Today I could squeeze in some work, while getting ready for the trip, but most work will have to wait until I am back at the end of the week.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I changed the fpga logic to support a bidirectional flow between the PC program and the SAC Interface box. In addition, rather than sending a stream of status, which was the initial behavior, I now have a transactional engine which waits for requests from the PC program and executes. The first transaction types are Send Status, Write Word in Core and Read Core Location.

With these, I can load software, e.g. diagnostics, into the 1131 memory and execute without needing to read it from cards or disk. Later, of course, I can create various emulated devices to respond to XIO instructions.

I went through enough variations on data bits being fetched to be assured that my Channel Data In lines are correct. I then worked on the XIO Sense Device for area code 21 which I had set up to return 0x1130 (the most appropriate first value to store in this system). It worked when single stepped but when run at full speed I only got some of the bits.

I am not sure what is occurring and need to use the scope to watch a full speed operation.

The other problem, of the erratic channel address in values, seems to be more than just the two stuck on bits. When I probe the driver card, I can see that the fpga outputs a 1 which should drive the chip output to a low voltage, but the out line remains up at 2.9V. I may have bad chip circuits, as I did in another chip.

An additional puzzling problem was when I changed the address for a store to 0x3FFF which should have been high memory, but although i was writing and reading a value I set up, I couldn't find where in memory that took place. The cycle stealing operation does not display the memory address being used, all we see is the M register which is bypassed in order to gate in the Channel Address In values we emit. More investigation is necessary here. Perhaps I have too much latency after the operation of the FSM, so that the Channel Address In value is not fully set up when it is used to issue a memory read. I will emit it earlier in my FSM just to be more confident that I am driving the proper address.