SCOPE MONITORING OF KEY SIGNALS IN THE CYCLE STEAL PROCESS
The shield that is fitted to the Arduino has a state machine to step through a cycle steal. Once the Arduino raises a signal to start a cycle, the shield must assert a request for a cycle steal on CS level 0. It waits until the processor grants the cycle steal, turning on the -CS Level 0 signal, at which time the shield must pass the storage address and data values through to the 1130.
Each cycle steal memory cycle takes eight clock steps, four for the read of the core location and another four for the write stage. While normal instruction execution uses the T clock for its eight steps, named T0 to T7, that clock is held while a separate X clock advances for the cycle steal. Those are X0 to X7.
When we reach X6, the data has already been transferred to the Storage Buffer Register and written to the memory location, thus we can drop our data and address signals. As the cycle steal ends, we will see -CS Level 0 drop. At that time the shield will notify the Arduino that the cycle is complete. When the Arduino drops its request signal, the state machine goes back to idle and waits for a next request.
I will monitor -CS Level 0, -X6, -CS Level 0 Req, and +Storage Write Cycle on the oscilloscope in order to judge whether the state machine is moving as I expected and if it seems properly synchronized with the 1130. That is a microscopic level of evidence I will look for.
TESTS USING THE LOADER
As a higher level verification, I will have first store a known pattern A5A5 into all of core so that I can immediately tell if any location is changed by the loader. I will then connect to the loader with a tablet over USB and try a few commands.
After enabling the loader with a line containing #, I will set a starting memory location into the Arduino with the @0100 command. This is saved in the Arduino and is where the next data word will be stored, autoincrementing after each store. I will then write three words in succession, each on its own line sent to the loader. First, 0000, then FFFF, then 5A5A.
I will observe the 1130 display panel as this happens to see if I spot the activity and if the registers are updated in any way. I expect no change to the Instruction Address Register (IAR), Accumulator (ACC), Arithmetic Factor Register (AFR) and Accumulator Extension (EXT). I may see the Storage Address Register changed to show the address where the loader placed the last word of data, but I don't believe this will happen. Finally, I will see the last data value in the Storage Buffer Register, which I do expect since the process of writing to core loads the SBR.
Using the Display mode, I will check the words at 0100, 0101 and 0102 for the patterns I intended to load. If these are correct, I will look at adjacent words (00FF and 1013) to be sure I am not touching locations that should not be changed.
CHECKING FOR STRAY DATA IN MEMORY
If all that looks good, I will restore 0100 to 0102 to the default pattern A5A5. A small hand loop is inserted in low core to read every word of memory and compare it to A5A5. It will stop at any location that differs. Except for my small hand loop, there should be no stops.
USE THE LOADER WITH A SIZEABLE PROGRAM
As a top level proof of concept, I will upload the CPU diagnostics into core and run them. This will execute every instruction and variation of instruction processing as a checkout of the soundness of the IBM 1130 and at the same time, of the soundness of the core loader.
No comments:
Post a Comment