Restructuring the GUI
-- virtual 1442 --
I found code flaws that may have caused one of my outstanding errors, the duplication of card columns 71-80 across the entire card in the output stacker files. I proceeded to testing in the afternoon, having spent the morning as a volunteer examiner for an FCC amateur radio licensing test session at the Saratoga firehouse.
I also rethought the flow in the GUI to address the problem that the last card is not completing its read. As I did that, I realized that my code to model the hopper and pre-read buffer was not going to properly support the 1442 semantics so I made substantial changes.
In the real 1442, a deck of cards sits in the hopper initially. The operator pushes the Start button to cause one cycle when the first card of the deck is loaded into the pre-read station. The way that I synchronize between FPGA and the GUI, I don't move the card into the pre-read buffer until I see an XIO Control that starts a read, punch or feed.
This matters when the last card of the hopper goes into the machine. On a real 1442, that card moves into the pre-read station and the reader will go out of ready. The user may push the Start button again
-- virtual 1442 --
I found code flaws that may have caused one of my outstanding errors, the duplication of card columns 71-80 across the entire card in the output stacker files. I proceeded to testing in the afternoon, having spent the morning as a volunteer examiner for an FCC amateur radio licensing test session at the Saratoga firehouse.
I also rethought the flow in the GUI to address the problem that the last card is not completing its read. As I did that, I realized that my code to model the hopper and pre-read buffer was not going to properly support the 1442 semantics so I made substantial changes.
In the real 1442, a deck of cards sits in the hopper initially. The operator pushes the Start button to cause one cycle when the first card of the deck is loaded into the pre-read station. The way that I synchronize between FPGA and the GUI, I don't move the card into the pre-read buffer until I see an XIO Control that starts a read, punch or feed.
This matters when the last card of the hopper goes into the machine. On a real 1442, that card moves into the pre-read station and the reader will go out of ready. The user may push the Start button again
to set it into the special 'last card' mode and make it ready again.
This is a crossroads for the operator. If they select last card, the very next read will return a special bit in the DSW informing the software that the last card was read. If not, the operator must put additional cards into the hopper before the machine can be made ready and respond to a read.
This behavior allows the operator to feed vary large numbers of cards through the reader, more than can fit into the input hopper at one time. The hopper empties, the operator sticks on more cards, then the Start button resumes reading. When the entire deck is done, the operator hits Start with no new cards, telling the software that the entire deck of cards has been read.
On my virtual 1442, the operator selects the last card mode via a checkbox when the deck is loaded. If the last card mode is not chosen, then the virtual reader will become not ready when one card is left in the deck. The problem is that this last card is NOT down in the pre-read buffer, it is still in the PC file that was loaded in the hopper. In order to add more cards to the hopper, I must remember and deal wtih that final card image of the prior file.
My restructured logic will handle adding cards to the hopper when it runs out If the hopper already has one card in it, I read that last card from the current PC file, save it temporarily, then open the new file that will reload the hopper. I bump the count of cards from the new file by one if I did the save from the old file.
During the main card reading process in the GUI, if I have a saved card from the reload of the hopper, I pass that in rather than read one from the newly opened PC file. If there was no saved card, we just read normally from the hopper file.
For a last card sequence, when the card count reaches 0, the special status bit in the DSW signals last card, and we make the reader not-ready. When the user clicks on the hopper icon after this, the first click empties the hopper and closes the file. The next click loads a new file into the hopper and makes it ready.
This slightly cumbersome method will require a bit of testing, once I have the basic reading process working correctly. First up, some testing.
The issue with duplicating columns 71-80 is fixed. I have the off by one problem in both the data read into memory and in the file coming out of the stacker, which identifies the problem as sitting in my read buffer logic. I have some garbling where data in columns are misplaced - only happens every ninth column. These are primary issues, which I need to fix to get basic reading, feeding and punching working correctly.
The restructured code does read all cards completely when we get to an empty hopper with last card set. However, it does not stop at card 1 when last card is unset and I am getting undesired errors trying to read past the end of the hopper file. These can be deferred if the solution isn't obvious, until the core functions are correct.
I believe I found the issue with the garbling problem in the buffer and in memory after a read and prepared for a new test. Garbling is fixed. Unfortunately, it didn't correct the reading issue. After another shot, I am suspecting that I have a problem with sending out the IL0 interrupts too rapidly.
The particular code I am running, copied from the CE Handbook, has an interrupt handler for L0 that does an XIO Sense DSW to reset the trigger condition in the 1442, then an XIO Read to pick up the value for that column, and finally a BOSC instruction to reset the interrupt level and go back to wait.
To see if there is some issue related to timing, I slowed the emulated 1442 down 100 to 1000x, which spaces out the column interrupts by a few seconds each. No change at all in the behavior - the card columns 1 to 80 are stored in memory as 1, 1, . .. 79 and the pre-punch buffer fetch of the data that was copied over is blank 1 . . 79 instead of doubling column 1. I wish I could see what was causing the problem. I have rewritten many chunks of logic in the area, yet the flaw persists.
I restored the timing of the logic and went back to deep inspection. Until I have some clue about the failure mechanism at play, I can't even choose the signals to monitor.
-- test loop programs for debugging --
I set up memory files with the hand programs from the CE Handbook, so that I can quickly load them and test various peripherals without the time consuming toggling through the console.
MARCHANT FIGUREMATIC MECHANICAL CALCULATOR
I picked up a Marchant mechanical calculator at a very good price - free - and will need to do a bit of work to restore it to proper operation. This is a unit that can do add, subtract, multiply and divide rapidly on long numbers. This machine was the fastest way for computers to do calculations - computers being people who computed using machines or slide rules - until the WWII era when tools like Eniac were built to achieve higher speeds.
When I plug it in, the motor is grinding but nothing is moving. A couple of buttons are stuck down. I need to free up the mechanism, lubricate anything that might be jammed, and see if I can get it working again. I won't be working on this again for a few months, due to the VCF West exhibition and Xerox Alto restorations which are a priority.
This is a crossroads for the operator. If they select last card, the very next read will return a special bit in the DSW informing the software that the last card was read. If not, the operator must put additional cards into the hopper before the machine can be made ready and respond to a read.
This behavior allows the operator to feed vary large numbers of cards through the reader, more than can fit into the input hopper at one time. The hopper empties, the operator sticks on more cards, then the Start button resumes reading. When the entire deck is done, the operator hits Start with no new cards, telling the software that the entire deck of cards has been read.
On my virtual 1442, the operator selects the last card mode via a checkbox when the deck is loaded. If the last card mode is not chosen, then the virtual reader will become not ready when one card is left in the deck. The problem is that this last card is NOT down in the pre-read buffer, it is still in the PC file that was loaded in the hopper. In order to add more cards to the hopper, I must remember and deal wtih that final card image of the prior file.
My restructured logic will handle adding cards to the hopper when it runs out If the hopper already has one card in it, I read that last card from the current PC file, save it temporarily, then open the new file that will reload the hopper. I bump the count of cards from the new file by one if I did the save from the old file.
During the main card reading process in the GUI, if I have a saved card from the reload of the hopper, I pass that in rather than read one from the newly opened PC file. If there was no saved card, we just read normally from the hopper file.
For a last card sequence, when the card count reaches 0, the special status bit in the DSW signals last card, and we make the reader not-ready. When the user clicks on the hopper icon after this, the first click empties the hopper and closes the file. The next click loads a new file into the hopper and makes it ready.
This slightly cumbersome method will require a bit of testing, once I have the basic reading process working correctly. First up, some testing.
The issue with duplicating columns 71-80 is fixed. I have the off by one problem in both the data read into memory and in the file coming out of the stacker, which identifies the problem as sitting in my read buffer logic. I have some garbling where data in columns are misplaced - only happens every ninth column. These are primary issues, which I need to fix to get basic reading, feeding and punching working correctly.
The restructured code does read all cards completely when we get to an empty hopper with last card set. However, it does not stop at card 1 when last card is unset and I am getting undesired errors trying to read past the end of the hopper file. These can be deferred if the solution isn't obvious, until the core functions are correct.
I believe I found the issue with the garbling problem in the buffer and in memory after a read and prepared for a new test. Garbling is fixed. Unfortunately, it didn't correct the reading issue. After another shot, I am suspecting that I have a problem with sending out the IL0 interrupts too rapidly.
The particular code I am running, copied from the CE Handbook, has an interrupt handler for L0 that does an XIO Sense DSW to reset the trigger condition in the 1442, then an XIO Read to pick up the value for that column, and finally a BOSC instruction to reset the interrupt level and go back to wait.
To see if there is some issue related to timing, I slowed the emulated 1442 down 100 to 1000x, which spaces out the column interrupts by a few seconds each. No change at all in the behavior - the card columns 1 to 80 are stored in memory as 1, 1, . .. 79 and the pre-punch buffer fetch of the data that was copied over is blank 1 . . 79 instead of doubling column 1. I wish I could see what was causing the problem. I have rewritten many chunks of logic in the area, yet the flaw persists.
I restored the timing of the logic and went back to deep inspection. Until I have some clue about the failure mechanism at play, I can't even choose the signals to monitor.
-- test loop programs for debugging --
I set up memory files with the hand programs from the CE Handbook, so that I can quickly load them and test various peripherals without the time consuming toggling through the console.
MARCHANT FIGUREMATIC MECHANICAL CALCULATOR
I picked up a Marchant mechanical calculator at a very good price - free - and will need to do a bit of work to restore it to proper operation. This is a unit that can do add, subtract, multiply and divide rapidly on long numbers. This machine was the fastest way for computers to do calculations - computers being people who computed using machines or slide rules - until the WWII era when tools like Eniac were built to achieve higher speeds.
When I plug it in, the motor is grinding but nothing is moving. A couple of buttons are stuck down. I need to free up the mechanism, lubricate anything that might be jammed, and see if I can get it working again. I won't be working on this again for a few months, due to the VCF West exhibition and Xerox Alto restorations which are a priority.
No comments:
Post a Comment