After a few days, the carrier return is much more reliable now as the oil has worked out of the mechanism. I still get rare situations where the carrier jumps past the left margin (probably a slow unlock of the CR mechanism but could be other issues). Indexing is also rarely failing to fully step one line, but I can see a sticky lever where residual stale lubricant is causing a problem.
Oddly, when I press the button that should space one position, the 1053 will perform a tab instead. Some maladjustment to track down. Also have to keep exercising this, as it gets better with further use (but slow rate of improvement).
LIVING COMPUTER MUSEUM ACQUIRES LARGE 1130 SYSTEM
I have just heard that the LCM in Seattle has acquired an 1130 system with plenty of peripherals. Important to me is that this system has an 1133 multiplexer box and 2310 disk drives. There are no online ALDs for the 1133 but I can hope the books at LCM can be scanned and shared.
I assume they will restore this system as well and I may very well help out a bit if asked. Exciting to see yet another 1130 that will breathe again.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
The validation error I experienced might be a race hazard or flaw in fetching words from core, even though I believe I found and fixed the flaw that was causing the problem - in the python code. However, it will be important to prove out the fetch reliability since this will be key to writing to virtual disk, printers or card punches.
Further testing shows that my fetch is not reliable, while store is rock solid. The fetch function involves latching up and storing words coming from cycle steal core fetches, but is spread across several FSMs and timing is very important in order for this to work reliably. Digging into the FPGA logic for this function.
I rewrote how the data words are latched during a set of 1 to 11 reads for a fetch transaction, as well as the logic that populates the outbound packet to return the data values to the Python program. Testing begins this afternoon.
My verification of memory still fails, but the write is perfect. Further, I did some disk writes and reads to the virtual 2310 cartridge and those results are perfect as well. I initialized a fresh virtual cartridge using the DCIP utility on the real 1130, then dumped its first sector to the console printer.
I took the virtual cartridge file I had initialized and attached it to the 1130 simulator, running the same DCIP utility there and it compared word for word identically to a virtual cartidge initialized by the utility on the simulator. Very happy with the accuracy.
More importantly - the speed of the virtual drive is immensely improved now. I initialized the virtual disk cartridge in just over six minutes. My estimate for the performance of a physical 2310 drive on my real 1130 was five minutes. The performance penalty will be barely noticeable as it is. I do have two further ways to improve performance:
I will make both changes since they are relatively simple. Meanwhile, I have to figure out why I am running into trouble with my core load verification function somewhere in the Python code. I keep looking at the Python code and can't find a problem. It leads me to suspect that my SAR auto-increment might be throwing in an extra increment on reads. This will take some instrumentation to check things out.
The python program opens with five reads of 11 words, pausing between each to display the SAR on the LEDs. The addresses and content were always correct. I went back to exhaustively reading the code when I FINALLY spotted the cause. My logic for extracting the words that were read is to step an index up from 0 to 10, extracting words in their low to high address sequential order, while decrementing the remaining count from 11 down to 0.
In my loop to check that zeroed locations are indeed 0x0000, I had written pcnt + 1 rather than pcnt = pcnt + 1 thus my increment was tossed away silently after executing, leaving the index unchanged.
Changed it and verified that all was well now.
When I ran the utility to initialize the virtual disk cartridge again, it ran along up to cylinder 97, almost the halfway point, and then the cylinder never advanced and the code looped. I tried to restart but the device was virtually busy, which implies that my seek logic in the fpga somehow got wedged,leaving the drive perpetually busy and in 'motion'.
I tried again and was successful on both fronts. The core load function successfully verifies now and the disk initialization proceeded through to completion. It ran in five minutes 30 seconds, a bit faster than last time due to the two minor improvements I added. I am satisfied with disk performance and with the functionality of the virtual disk drive.
I will turn my attention to debugging the virtual 2501 next, as it is substantially complete. The virtual 1403 and 1442 devices require some FPGA logic development and restructuring, which is why they will wait a bit.
My verification of memory still fails, but the write is perfect. Further, I did some disk writes and reads to the virtual 2310 cartridge and those results are perfect as well. I initialized a fresh virtual cartridge using the DCIP utility on the real 1130, then dumped its first sector to the console printer.
I took the virtual cartridge file I had initialized and attached it to the 1130 simulator, running the same DCIP utility there and it compared word for word identically to a virtual cartidge initialized by the utility on the simulator. Very happy with the accuracy.
More importantly - the speed of the virtual drive is immensely improved now. I initialized the virtual disk cartridge in just over six minutes. My estimate for the performance of a physical 2310 drive on my real 1130 was five minutes. The performance penalty will be barely noticeable as it is. I do have two further ways to improve performance:
- Further decrease the short packet timeout of the USB driver, which is currently a bit longer than 5 microseconds but could safely go down to about 660 nanoseconds and still work with my packets since I write these as a sequence of 12 words in about 250 nanoseconds.
- Each disk read or write is doing a transaction to fetch the current cylinder for the virtual arm, but this information can be piggybacked on the transaction which returns the XIO function, modifier, reset bits, WCA and DSW. I have five spare words in the packet.
I will make both changes since they are relatively simple. Meanwhile, I have to figure out why I am running into trouble with my core load verification function somewhere in the Python code. I keep looking at the Python code and can't find a problem. It leads me to suspect that my SAR auto-increment might be throwing in an extra increment on reads. This will take some instrumentation to check things out.
The python program opens with five reads of 11 words, pausing between each to display the SAR on the LEDs. The addresses and content were always correct. I went back to exhaustively reading the code when I FINALLY spotted the cause. My logic for extracting the words that were read is to step an index up from 0 to 10, extracting words in their low to high address sequential order, while decrementing the remaining count from 11 down to 0.
In my loop to check that zeroed locations are indeed 0x0000, I had written pcnt + 1 rather than pcnt = pcnt + 1 thus my increment was tossed away silently after executing, leaving the index unchanged.
Changed it and verified that all was well now.
When I ran the utility to initialize the virtual disk cartridge again, it ran along up to cylinder 97, almost the halfway point, and then the cylinder never advanced and the code looped. I tried to restart but the device was virtually busy, which implies that my seek logic in the fpga somehow got wedged,leaving the drive perpetually busy and in 'motion'.
I tried again and was successful on both fronts. The core load function successfully verifies now and the disk initialization proceeded through to completion. It ran in five minutes 30 seconds, a bit faster than last time due to the two minor improvements I added. I am satisfied with disk performance and with the functionality of the virtual disk drive.
I will turn my attention to debugging the virtual 2501 next, as it is substantially complete. The virtual 1403 and 1442 devices require some FPGA logic development and restructuring, which is why they will wait a bit.
No comments:
Post a Comment