Hoping to finish the testing of the 1130 MRAM core memory replacement board

RETESTING STORAGE LOAD AND STORAGE DISPLAY WITH UPDATED FPGA LOGIC

After the changes I made to delay the write into the MRAM chip in order to allow the Storage Buffer Register (SBR) to complete its setting of the updated value, I loaded that into the FPGA board. I then worked through testing to see if the board is performing as intended. 

I used the Storage Load and the Storage Display switches on the machine which will loop repeatedly through memory storing the pattern set in the Console Entry Switches (CES) or displaying the contents of memory respectively. I checked to see if I could load memory with patterns including the value 0xFFFF which has the maximum of bits with a 1 value, then read them back properly. 

This worked perfectly for a variety of patterns including 0x0000 and 0xFFFF so I moved on to the type of test that filed before

RETESTING LOAD AND DISPLAY MODE USE OF MEMORY

The next set of tests made use of the rotary mode switch of the IBM 1130. Pushing the Prog Start button when in Load mode will store the value in the CES into the next storage location. Pushing the Load IAR button in Load mode will set the next storage location to the address set in the CES. Pushing the Prog Start button will display the contents of the next storage location in the SBR lights on the console. 

This too worked perfectly. I was able to load ranges of data into chosen memory locations, validate the address bits work properly, and do other tests. It appears that the new board is working properly now, so I chose to move on and run some IBM diagnostic programs. 

RUNNING 1130 MEMORY DIAGNOSTICS

IBM provides diagnostics to run that verify different aspects of the IBM 1130, including tests to confirm that core memory is working properly. I used the memory loader function I created and installed on this 1130 machine in order to load the memory diagnostic in core memory, then set the machine to the start address and pushed Prog Start while in the Run mode to let it execute. 

This consistently fails with a Parity Check error at one point in the routine. This could be a consequence of some device controller card jamming bits into the SBR when it should not, or it could be a failure in my board. The error means that the data stored into the SBR by my board does not agree with the parity bits generated by my board. This needs more investigation

Next I attempted to run the CPU Diagnostic which exercises every instruction in all their modes and variations. This consistently stopped with an error while testing the Shift Left Arithmetic (SLA) instruction. However, when I hand stepped through the routine I found that one of the instructions in the routine did not match the diagnostic program listing. I restored that to the correct value but when I reran the diagnostic from the start, it again had the wrong data in that address. This has to be caused by some other portion of the code storing in the wrong place. 

I displayed memory in many spots and found what had been loaded by my Console Loader matched exactly, but I didn't exhaustively check every location after loading. My console load triggers Cycle Steal operations in the 1130. These are typically used by faster peripheral devices to transfer in an entire record of data as it is ready without interrupting the program currently executing. The machine will pause the processor at the end of a memory cycle, holding at clock step T7. It then uses the X clock to take a memory cycle, with the peripheral controller (and my loader) providing both an address and a data word for the memory access. When the X clock gets to step X7 and there are no more cycle steal requests, the processor continues with the next memory cycle by advancing to clock step T0. 

There may be a timing issue with cycle steal and my memory board or an issue with my console loader use of cycle steal. This will take some investigation to get to the root cause so that I can finally get this memory board signed off and the project finished.