Right in the middle of my testing with the DCIP diagnostic, the damnable typewriter popped its carrier string off its pulleys, thus leaving the carriage jammed in the middle of the line. Until I fiddle with this and refit the string, no more typed output. That forces me back to hand coded instructions, or single stepping through the appropriate parts of the DCIP program.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I found a very subtle error in my 2310 logic. When the machine triggers an interrupt on level 2, the handler will fetch the ILSW to determine which device is causing the interrupt. I was looking at the wrong bits, causing the ILSW data to be presented at the wrong time and to set the wrong bit.
I located some key areas in the standalone DCIP program that I could watch for - where the XIO instructions are issued - in order to spot what is coming back to the utility program. I got out to the workshop and fired up the system to test out these changes and collect more information.
Neither defect was corrected - I continue to get the last XIO function repeatedly even though I should have reset it with the transaction so that it won't recur until the next XIO. I also retrieve null characters (typewriter produces the period for this). Something is happening in my fpga that I am just not seeing, but it is producing the erroneous behavior. It is time to instrument some special signals to see what is happening.
I hand coded a single XIO Sense Device command, issued it in single instruction mode, and watched the PC side loop receiving the same function code forever. My diagnostics showed that the field was indeed still 111 - the code for XIO Sense Device. This confirms that my code will NOT reset this as it should, although why this fails to work remains a mystery. More study and new diagnostic traces were needed.
Finally, the mistake in my logic leaped out of the page at me. The device number as issued from the PC to the transactions is actually the UCW number. The area code used in an XIO to select the specific device is a different number. I had coded my routine with the area code of the disk drive - 0b10101 (20) not the UCW number which implements this device adapter (0b01000 = 8). Doh. Days wasted because I kept seeing the area code and confirming in my head that it matched the virtual disk drive.
I repaired my grevious error and went back to testing. Once it worked, I went through the fpga VHDL code and changed all instances of devno (device number) to ucwno (UCW no) so that I won't slip into the same mistake any other times.
The next issue I found was that the adapter did one XIO Init Read with check, the PC side set operation complete but it didn't seem to proceed ahead from that point. This may be caused by the ratshit 1053 which is now spinning its golfball in place and randomly hanging up until I trigger a manual carrier return. Still, I will change my instrumentation to trace what is happening with my mirror 1053 driver, so that I can get both of these functions moving forward.
I cleaned up the 2310 adapter, so that it is triggering the interrupt at operation complete and then providing the DSW for the sense. I saw a way to change where I trigger the interrupt and reset it, to tighten up the timing. I am not sure what is wrong with the 1053 mirror function - I am arming and disarming the mirror, stuffing words in the buffer but the request to pop and return words from the buffer is no longer working.
The interrupt and reset logic is changed for the 2310 and I spotted and corrected a flaw that was blocking the 1053 logic from retrieving the buffered words. I ran out of time for testing tonight but I feel good with the progress I made and look forward to tomorrow's test time.
Neither defect was corrected - I continue to get the last XIO function repeatedly even though I should have reset it with the transaction so that it won't recur until the next XIO. I also retrieve null characters (typewriter produces the period for this). Something is happening in my fpga that I am just not seeing, but it is producing the erroneous behavior. It is time to instrument some special signals to see what is happening.
I hand coded a single XIO Sense Device command, issued it in single instruction mode, and watched the PC side loop receiving the same function code forever. My diagnostics showed that the field was indeed still 111 - the code for XIO Sense Device. This confirms that my code will NOT reset this as it should, although why this fails to work remains a mystery. More study and new diagnostic traces were needed.
Finally, the mistake in my logic leaped out of the page at me. The device number as issued from the PC to the transactions is actually the UCW number. The area code used in an XIO to select the specific device is a different number. I had coded my routine with the area code of the disk drive - 0b10101 (20) not the UCW number which implements this device adapter (0b01000 = 8). Doh. Days wasted because I kept seeing the area code and confirming in my head that it matched the virtual disk drive.
I repaired my grevious error and went back to testing. Once it worked, I went through the fpga VHDL code and changed all instances of devno (device number) to ucwno (UCW no) so that I won't slip into the same mistake any other times.
The next issue I found was that the adapter did one XIO Init Read with check, the PC side set operation complete but it didn't seem to proceed ahead from that point. This may be caused by the ratshit 1053 which is now spinning its golfball in place and randomly hanging up until I trigger a manual carrier return. Still, I will change my instrumentation to trace what is happening with my mirror 1053 driver, so that I can get both of these functions moving forward.
I cleaned up the 2310 adapter, so that it is triggering the interrupt at operation complete and then providing the DSW for the sense. I saw a way to change where I trigger the interrupt and reset it, to tighten up the timing. I am not sure what is wrong with the 1053 mirror function - I am arming and disarming the mirror, stuffing words in the buffer but the request to pop and return words from the buffer is no longer working.
The interrupt and reset logic is changed for the 2310 and I spotted and corrected a flaw that was blocking the 1053 logic from retrieving the buffered words. I ran out of time for testing tonight but I feel good with the progress I made and look forward to tomorrow's test time.
No comments:
Post a Comment