The typewriter remains inconsistent in many ways. More often than not, the carrier returns are very slow, but sometimes they are jet fast. CRs don't usually latch but sometimes they do, but that is unrelated to the hi versus lo speed behavior. Sometimes it jumps over the left margin and sticks there. Once in a great while, index sticks on. Time, patience and adjustments. That is my mantra to help me deal with the flakiness.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
After some careful testing I discovered a logic flaw - a timing error - where the Op Complete status bit was reset before the XIO Sense DSW had finished strobing the DSW into the 1130. Thus, the XIO Sense DSW with reset bit on would never see the condition because it had reset it too early.
The flaw was in the flipflop that holds Op Complete. It is turned off if we see an XIO Sense DSW executing and the modifier field of that instruction has bit 15 turned on. The way I coded this was to see if the XIO Sense Device was occuring (its busy bit was on), then immediately tested the modifier bit and reacted. What I needed to do was to add a stage to the FSM for this flip flop. When I see the XIO Sense go busy, step to the next state where we wait until it goes off (the Sense is done) before looking at the modifier bit and either turning the FF off or remaining on.
With my fpga logic recoded, I went back out to test and verified that I had a reliable DSW stored with the operation complete indicated. The next problem I had was some hangup in the disk routine inside the DCIP utility, where it should be issuing a seek based on the cylinder I requested via bit switches. My guess is that my XIO Control routine (how a seek is requested) is not working properly thus not setting the operation complete for the seek.
I looked over the seek logic in the fpga to figure out the problem. This is an issue that arises from handling XIO Seek and XIO Sense locally (in the fpga) but the Init Read and Init Write up in the PC. The PC pushes the op complete status down to the fpga for the IR and IW, but it is necessary that my fpga logic does this for a seek.
I discovered that I was directly turning off the Busy status but not setting the operation complete flip flop, thus not triggering the interrupt. I adjusted the logic such that I now set the flipflop, whose reset by a Sense DSW is indirectly how the busy is reset. I am still concerned that I didn't see the proper cylinder reflected in my GUI, but that will be the next item for testing.
Much better now, but even when I enter a sector address of 0x0003 which is on the same cylinder as my current position, the results don't match. I suspect this is a flaw in my logic to 'seek' through the PC file and return contents, as I see data in the buffer, just nothing matching what is on the virtual disk at that location.
By dinner time, I had corrected the problems with the virtual seek on the PC side and was able to read any of the eight sectors of a disk correctly. I still had the problem where my seek did not appear to be working, which left the cylinder at 0 even when I entered a sector number larger than 7 on the bit switches. Pouring over the logic for triggering on a seek, modeling the timing, capturing the seek amounts and updating the cylinder number.
I looked over the seek logic in the fpga to figure out the problem. This is an issue that arises from handling XIO Seek and XIO Sense locally (in the fpga) but the Init Read and Init Write up in the PC. The PC pushes the op complete status down to the fpga for the IR and IW, but it is necessary that my fpga logic does this for a seek.
I discovered that I was directly turning off the Busy status but not setting the operation complete flip flop, thus not triggering the interrupt. I adjusted the logic such that I now set the flipflop, whose reset by a Sense DSW is indirectly how the busy is reset. I am still concerned that I didn't see the proper cylinder reflected in my GUI, but that will be the next item for testing.
Much better now, but even when I enter a sector address of 0x0003 which is on the same cylinder as my current position, the results don't match. I suspect this is a flaw in my logic to 'seek' through the PC file and return contents, as I see data in the buffer, just nothing matching what is on the virtual disk at that location.
By dinner time, I had corrected the problems with the virtual seek on the PC side and was able to read any of the eight sectors of a disk correctly. I still had the problem where my seek did not appear to be working, which left the cylinder at 0 even when I entered a sector number larger than 7 on the bit switches. Pouring over the logic for triggering on a seek, modeling the timing, capturing the seek amounts and updating the cylinder number.
When I was handling the seek in the Python program, I never intercepted any of them. It makes me wonder if there is some subtle issue that is affecting my handling of XIO Control commands, either generally or for this specific virtual device. Part of my instrumentation will be a flag to tell me if XIO Control was ever detected, helping steer me towards the cause of the problem. Also plenty of eyeball time looking over all the logic to see what might possibly be going wrong.
No comments:
Post a Comment