After my tests today it became obvious that my method of flagging the device as busy was not working to slow down the typing. I looked over my logic and see one thing I can do that might make a difference, otherwise I will need to go back to the idea of keeping a big buffer for the mirror device adapters.
I did verify that the logic is properly translating the typewriter character stream to the right ASCII characters or control codes such as carrier return. Once I solve the problem with the typewriter overrunning my Python codes ability to pick up the typewriter codes, the 1053 mirror driver will be finished.
I set up additional changes for the 1053 adapter and gave it one more try. When I was turning on not ready along with busy, the diagnostic dropped into the NR wait state - proving I am forcing inm the DSW bits for mirrored devices. However, it still issued bursts of characters without pausing for each one, which suggests that the diagnostic program doesn't check the DSW before each character is issued.
In order to debug this further, I will need to put in some hand-coded routines and step through the code on the 1130 to see if it is properly reporting status and picking up every character, if typed at a glacially slow rate. I can then try a rapid loop and see what is happening there.
I set up additional changes for the 1053 adapter and gave it one more try. When I was turning on not ready along with busy, the diagnostic dropped into the NR wait state - proving I am forcing inm the DSW bits for mirrored devices. However, it still issued bursts of characters without pausing for each one, which suggests that the diagnostic program doesn't check the DSW before each character is issued.
In order to debug this further, I will need to put in some hand-coded routines and step through the code on the 1130 to see if it is properly reporting status and picking up every character, if typed at a glacially slow rate. I can then try a rapid loop and see what is happening there.
No comments:
Post a Comment