Restructuring the GUI
-- virtual 1442 --
I need to send the changed status for the 1442 down to the FPGA prior to the end of the current read, punch or feed cycle, in order to have it post properly with the DSW when the operation complete interrupt on IL4 is emitted. This is a small change. The Python code that sends the NR or last card&NR DSW has to be moved before I fetch the pre-punch buffer. That will set the conditions for the device. No change is needed in the fpga.
My first priority is to find and fix the bug that causes cards in the stacker file to be offset by one column. I spent another half hour walking through the logic for both copy-over and fetch, hoping to notice the problem. I rewrote the logic and added a few LED outputs, then went to test again.
Once again the annoying problem with failure to get a valid poll response back. I rebooted the Windows laptop just in case this is a USB driver and windows issue. When I restarted, I had the same problem. Interestingly, it is related to the spurious problem yesterday when core load wouldn't work.
I sent 0x5d48 to the FPGA as the command word, which is a poll on UCW 11 (device number as implemented in my logic, not the 1130 area code used to address it). However, the reflection back had it as 0x5548. That is, bit 4 when numbering starting from the left, was 0 when it should be 1. My core failure yesterday was loading core but failed to verify because any word with bit 4 set was loaded as a 0, not a 1.
The only things in common are the USB path for transactions - the bit is dropped somewhere between where I load the words to send and when it arrives in the FPGA. That could be python failures, USB driver software, the USB module on the fpga board or the signal line from the USB to the fpga chip for that bit position. I think USB does some kind of checksumming of transactions, which points to a broken chip or trace on my $200 FPGA board.
The problem arose yesterday morning and went away spontaneously by the afternoon. Lets see if it does the same today. Alternatively, I will:
I went back to the saved bitstream to confirm that the problem recurred. This is an artifact of the toolchain. Nothing in my logic should be timing sensitive concerning the input bit 4 from the USB module. Now I have to consider any particular run of the toolchain potentially corrupt, which means that I have to do two runs with minor changes and produce dual bitstreams, in order to know immediately if the flaw is in my logic or spurious Xilinx effects.
My last test yielded a different problem with the copy over process - now I get column 1 repeated three times before the rest of the card is copied. What????? Will need to test for Xilinx disease before I try to troubleshoot this. Made a trivial change and reran the toolchain.
Repeated with two versions of bitstream, so the problem is real. I am going to rethink my method of loading up the response to the get special data transaction. I build up a temporary array of 10 words as the get special logic loop fetches from the punch buffer, then when the loop signals its end I copy from the temporary array to the output words to send back to the GUI.
With the new bitstream loaded, I fired up the system, ran through some cards. and found that I was fetching nothing but blank columns. Time to look closer at my logic to capture the value of the punch buffer during the fetch loop.
Couldn't see why this isn't working, but rewrote it anyway. Still fetching nothing but zeroes. Perhaps their is a problem over in the copy-over process? In case there are glitches in the buffer address lines I registered those. No change, however.
I did some testing of the last card processing logic. It worked exactly as desired when the last card box is checked - one the last card, the DSW has last card set, op complete and not ready. When I turned off the last card checkbox, it didn't stop on the next to last card, it emptied the hopper entirely but did at least show op complete and not ready in the last DSW issued.
I updated my GUI logic to recognize when the reader has one card left in the hopper, if last card is not selected, and turn the device not ready at that point. I ran out of test time today but will resume tomorrow.
PLANNING FOR VCF WEST EXHIBITION
It is less than three weeks until the event. I need to prioritize my work on the SAC Interface box, as I only need the devices which will be part of my exhibition. That will free up time for other work prepping the 1130 and preparing exhibit signage. My wish list is virtual 1442 reader/punch, virtual 2310 disk drive and mirror 1053 console printer devices.
A 12 foot van with lift gate is waiting in my name. Will get it Friday, load up and bring everything to CHM that evening. The show runs Saturday and Sunday, with move-out the final evening. Much easier than my prior plan to use a horse trailer, which would have involved two trips each way, winches, ramps and sweat. Plus, I don't have to disassemble the 1130 into two parts.
I need to script out a few demonstrations and walk through them, so that everything goes smoothly during the show. With that, I can figure out a schedule for performing them. I anticipate that I will also allow a few visitors to prepare card decks on the PC for execution on the 1130. To support this, I will have Brian Knittel's 1130 simulator available for them to test out everything in advance.
I hope to bring my 1130 replica as part of the exhibit, which will require some work to get it ready. I need to finish some cosmetics - painting the metal top cover for certain, but I hope to build quicky side panels and paint them, to improve the visual appearance. I will look for some kind of hardboard to use for those panels. Essential, before I bring it, is to hook up the FPGA, load its firmware and make sure all my wiring is in place.
My 1130 has some problems with the lamps in the display pedestal. At a minimum I have to carefully close up the compartment but if I see a very safe alternative I will replace the missing few. The lamps go into boards which are very finicky to handle and insert, while the lamps themselves have brittle leads that snap off with the slightest flexing. After some peering, I chose to close it up as-is.
I spent some time creating signage and printing it out. Some discuss the 1130 and the replica, others cover the demonstration times or label the physical boxes present. I then drew out the cutting diagram to turn a 4 x 8 foot hardboard panel into the missing covers on my 1130 replica. These will be sprayed with a sand texture paint as a first coat, to get the pebbling effect of IBM machines, then sprayed with as close a spray paint color as I can find to either IBM Classic Blue or IBM Garnet Rose. I also need some medium tone gray to match the top of the 1130.
-- virtual 1442 --
I need to send the changed status for the 1442 down to the FPGA prior to the end of the current read, punch or feed cycle, in order to have it post properly with the DSW when the operation complete interrupt on IL4 is emitted. This is a small change. The Python code that sends the NR or last card&NR DSW has to be moved before I fetch the pre-punch buffer. That will set the conditions for the device. No change is needed in the fpga.
My first priority is to find and fix the bug that causes cards in the stacker file to be offset by one column. I spent another half hour walking through the logic for both copy-over and fetch, hoping to notice the problem. I rewrote the logic and added a few LED outputs, then went to test again.
Once again the annoying problem with failure to get a valid poll response back. I rebooted the Windows laptop just in case this is a USB driver and windows issue. When I restarted, I had the same problem. Interestingly, it is related to the spurious problem yesterday when core load wouldn't work.
I sent 0x5d48 to the FPGA as the command word, which is a poll on UCW 11 (device number as implemented in my logic, not the 1130 area code used to address it). However, the reflection back had it as 0x5548. That is, bit 4 when numbering starting from the left, was 0 when it should be 1. My core failure yesterday was loading core but failed to verify because any word with bit 4 set was loaded as a 0, not a 1.
The only things in common are the USB path for transactions - the bit is dropped somewhere between where I load the words to send and when it arrives in the FPGA. That could be python failures, USB driver software, the USB module on the fpga board or the signal line from the USB to the fpga chip for that bit position. I think USB does some kind of checksumming of transactions, which points to a broken chip or trace on my $200 FPGA board.
The problem arose yesterday morning and went away spontaneously by the afternoon. Lets see if it does the same today. Alternatively, I will:
- reload the same bitstream just in case it is a failure in the flash load
- make a trivial change to the fpga logic, resynthesize and load
- build a transaction in the GUI to echo to the fpga, allowing me to validate the state of the link
I went back to the saved bitstream to confirm that the problem recurred. This is an artifact of the toolchain. Nothing in my logic should be timing sensitive concerning the input bit 4 from the USB module. Now I have to consider any particular run of the toolchain potentially corrupt, which means that I have to do two runs with minor changes and produce dual bitstreams, in order to know immediately if the flaw is in my logic or spurious Xilinx effects.
My last test yielded a different problem with the copy over process - now I get column 1 repeated three times before the rest of the card is copied. What????? Will need to test for Xilinx disease before I try to troubleshoot this. Made a trivial change and reran the toolchain.
Repeated with two versions of bitstream, so the problem is real. I am going to rethink my method of loading up the response to the get special data transaction. I build up a temporary array of 10 words as the get special logic loop fetches from the punch buffer, then when the loop signals its end I copy from the temporary array to the output words to send back to the GUI.
With the new bitstream loaded, I fired up the system, ran through some cards. and found that I was fetching nothing but blank columns. Time to look closer at my logic to capture the value of the punch buffer during the fetch loop.
Couldn't see why this isn't working, but rewrote it anyway. Still fetching nothing but zeroes. Perhaps their is a problem over in the copy-over process? In case there are glitches in the buffer address lines I registered those. No change, however.
I did some testing of the last card processing logic. It worked exactly as desired when the last card box is checked - one the last card, the DSW has last card set, op complete and not ready. When I turned off the last card checkbox, it didn't stop on the next to last card, it emptied the hopper entirely but did at least show op complete and not ready in the last DSW issued.
I updated my GUI logic to recognize when the reader has one card left in the hopper, if last card is not selected, and turn the device not ready at that point. I ran out of test time today but will resume tomorrow.
PLANNING FOR VCF WEST EXHIBITION
It is less than three weeks until the event. I need to prioritize my work on the SAC Interface box, as I only need the devices which will be part of my exhibition. That will free up time for other work prepping the 1130 and preparing exhibit signage. My wish list is virtual 1442 reader/punch, virtual 2310 disk drive and mirror 1053 console printer devices.
A 12 foot van with lift gate is waiting in my name. Will get it Friday, load up and bring everything to CHM that evening. The show runs Saturday and Sunday, with move-out the final evening. Much easier than my prior plan to use a horse trailer, which would have involved two trips each way, winches, ramps and sweat. Plus, I don't have to disassemble the 1130 into two parts.
I need to script out a few demonstrations and walk through them, so that everything goes smoothly during the show. With that, I can figure out a schedule for performing them. I anticipate that I will also allow a few visitors to prepare card decks on the PC for execution on the 1130. To support this, I will have Brian Knittel's 1130 simulator available for them to test out everything in advance.
I hope to bring my 1130 replica as part of the exhibit, which will require some work to get it ready. I need to finish some cosmetics - painting the metal top cover for certain, but I hope to build quicky side panels and paint them, to improve the visual appearance. I will look for some kind of hardboard to use for those panels. Essential, before I bring it, is to hook up the FPGA, load its firmware and make sure all my wiring is in place.
My 1130 has some problems with the lamps in the display pedestal. At a minimum I have to carefully close up the compartment but if I see a very safe alternative I will replace the missing few. The lamps go into boards which are very finicky to handle and insert, while the lamps themselves have brittle leads that snap off with the slightest flexing. After some peering, I chose to close it up as-is.
I spent some time creating signage and printing it out. Some discuss the 1130 and the replica, others cover the demonstration times or label the physical boxes present. I then drew out the cutting diagram to turn a 4 x 8 foot hardboard panel into the missing covers on my 1130 replica. These will be sprayed with a sand texture paint as a first coat, to get the pebbling effect of IBM machines, then sprayed with as close a spray paint color as I can find to either IBM Classic Blue or IBM Garnet Rose. I also need some medium tone gray to match the top of the 1130.
No comments:
Post a Comment