Restructuring the GUI
I started up virtual device drivers, in order to begin debugging the new version of the GUI. When I started the 1442 device, I came across a coding error and corrected it. It turned out to be a widespread flaw in how I converted my old GUI code to the controller modules for all the devices.
Where I had individual transaction request blocks created in each function previously, I set one one block owned by the controller module and established at initialization. Then, each function should refer to it. Instead the code still referred to the individual request blocks in each function as a global name, not to the owned block in the module.
I fixed this with straightforward but slightly tedious textual search and replace in all the controller modules. With the GUI now written in the Model-View-Controller (MVC) pattern, only the controller actually talks to the FPGA over the transactional USB link. Only the model holds the state of the peripheral device, and only the view module will update the GUI images.
This allowed me to focus solely on the ten controller modules. Even better, I only messed up two of the ten controller modules, so I was done faster than I thought and back to testing. First up, I will check that I can activate and deactivate the various peripherals without error messages, before I start debugging the functions one by one.
I then discovered one of the causes of random failures when restarting - failure to stop and destroy all the threads when I exited. I put in some code to handle this directly and my issues disappeared.
I have some funky code in the 1132, 1442 and 1053 controllers, while the others are ready to begin testing. I first desk checked the 2501 and 2310 controllers, since they seemed ready for testing. While sitting at the PC, I will work on the 1053 code next as it is closest to ready.
By mid afternoon I was deep in debugging of the 2501 functionality, knocking down problems rapidly. Many were Python issues having to do with accessing code that had been restructured or relocated. Each such problem was a defect in modularity; fixing them gave me a tighter and less error prone program.
By dinner time, I had verified that my code correctly read a deck of cards in '029' mode (modified ASCII format as defined in the IBM 1130 Simulator), including properly handling the last card condition. What I didn't like was seeing the low two bits of the DSW on, since they should reflect Busy and Not Ready/Busy respectively, but when the interrupt was taken for the end of the card read, those should be off unless we are at the last or last-1 card.
I also didn't see the Last Card indication on the DSW for the read of the last card. I need to do some diagnostic testing of the FPGA to see what state it believes the reader to be, as well as looking at my logic in the program to see that I am correctly communicating status changes to the FPGA from the Python code.
I tried a Program Load of a binary card, but encountered a Python code error that must be corrected before I can test the boot capability. I also did not yet validate that binary mode decks are correctly read into core.
I started up virtual device drivers, in order to begin debugging the new version of the GUI. When I started the 1442 device, I came across a coding error and corrected it. It turned out to be a widespread flaw in how I converted my old GUI code to the controller modules for all the devices.
Where I had individual transaction request blocks created in each function previously, I set one one block owned by the controller module and established at initialization. Then, each function should refer to it. Instead the code still referred to the individual request blocks in each function as a global name, not to the owned block in the module.
I fixed this with straightforward but slightly tedious textual search and replace in all the controller modules. With the GUI now written in the Model-View-Controller (MVC) pattern, only the controller actually talks to the FPGA over the transactional USB link. Only the model holds the state of the peripheral device, and only the view module will update the GUI images.
This allowed me to focus solely on the ten controller modules. Even better, I only messed up two of the ten controller modules, so I was done faster than I thought and back to testing. First up, I will check that I can activate and deactivate the various peripherals without error messages, before I start debugging the functions one by one.
I then discovered one of the causes of random failures when restarting - failure to stop and destroy all the threads when I exited. I put in some code to handle this directly and my issues disappeared.
I have some funky code in the 1132, 1442 and 1053 controllers, while the others are ready to begin testing. I first desk checked the 2501 and 2310 controllers, since they seemed ready for testing. While sitting at the PC, I will work on the 1053 code next as it is closest to ready.
By mid afternoon I was deep in debugging of the 2501 functionality, knocking down problems rapidly. Many were Python issues having to do with accessing code that had been restructured or relocated. Each such problem was a defect in modularity; fixing them gave me a tighter and less error prone program.
By dinner time, I had verified that my code correctly read a deck of cards in '029' mode (modified ASCII format as defined in the IBM 1130 Simulator), including properly handling the last card condition. What I didn't like was seeing the low two bits of the DSW on, since they should reflect Busy and Not Ready/Busy respectively, but when the interrupt was taken for the end of the card read, those should be off unless we are at the last or last-1 card.
I also didn't see the Last Card indication on the DSW for the read of the last card. I need to do some diagnostic testing of the FPGA to see what state it believes the reader to be, as well as looking at my logic in the program to see that I am correctly communicating status changes to the FPGA from the Python code.
I tried a Program Load of a binary card, but encountered a Python code error that must be corrected before I can test the boot capability. I also did not yet validate that binary mode decks are correctly read into core.
No comments:
Post a Comment