The console printer is being very sluggish today, not sure why it is misbehaving. I have to help it along on a carrier return, although typing itself works fine. Line spacing is also erratic. I will minimize use of the console printer during the show.
PREPARATION FOR VCF WEST EXHIBITION
This morning, I ran through demonstrations using the virtual disk, printer and reader to stress test my changes to the USB link. I ran into cases where it found bit errors but recovery was bad. I put in diagnostics in the GUI side and improved the logic a bit.
I then ran through several demonstrations I plan to execute at the show, ensuring they worked properly. The slow speed of the USB link, now that it is festooned with the quick and dirty overhead I added to eliminate the unacceptable bit error rate, excludes a few of the demos I might have done.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
USB link robustness
My solution for the data link integrity is not good enough. Specifically, the action taken when a transmission error is detected is inadequate. The reason is that my transactions are not idempotent. That is a characteristic that says a transaction can be repeated without any consequence.
I have a transaction that polls for the last XIO issued. As part of the transaction, it resets the remembered values so that a subsequent poll receives null answers until the next XIO occurs. If a poll is returning data from an XIO, but has an integrity issue, when I reissue the poll automatically I will be getting nulls back, not the valid data that was sent in error.
Transactions that have corruption but are caught by the fpga side are safe. They did not occur, thus we only need a very reliable way to tell the Python program that the transaction was ignored, to cause it to resend. This works pretty well now, but could use some bolstering.
Transactions that are corrupted in the returned data words are caught by the checksum and parities, but the correct recovery would be to ask the FPGA to have saved the output and resend it This will avoid the problem of causing transactions to occur more than one time.
The challenge for both of these is to ensure that data corruption does not impact the recover mechanism itself. That is, if we had a checksum failure and sent some code pattern that requested retransmission of the already completed transaction output, that code pattern itself is vulnerable to corruption.
Similarly, if the pattern we send back that tells the Python code that the fpga has ignored a corrupted message, has itself suffered some degradation, we might either resend a transaction that didn't have an error or fail to resend one that did.
I was not going to do any further work on the detection and recovery logic this week, because I have to move everything to the show location on Friday and it is already Wednesday. My demonstrations need to be structured to handle possible one-time failures that will occur due to these low frequency errors in the channel.
Since I was touching this anyway, to deal with timeouts I discovered this morning I put in a 'resend last response' transaction type which just sends back the same 26 words as were last transmitted. The GUI asks for this with errors that represent garbling of the return data.
The GUI sends the same data twice - 12 words then the same 12 words. If the FPGA sees any corruption of the incoming packet, it will take the first 12 words and send back their complement in words 13-24, as a request to resend a command that was seen as malformed.
Tests for malformed incoming transactions are:
COMPLETING REPLICA COSMETICS
Today, I put the rotating plates on the gray cover that sits in the footwell, facing forward, then mounted the cover. That done, it was time to fit and glue braces on the remaining gray cover inside the footwell, which has no lower or upper frame members to control its vertical position. I hope to have enough friction from repeated braces on the two side frame members to ensure it stays in place.
Each cover took more than an hour, including time to glue up braces in two sittings with drying time in between, then fitting rotating plates and installing onto the frame.
The last gray cover mounts on the left side of the replica. I fit and glued braces, installed the rotating plates and secured that last cover onto the frame. Now the covers are all on the replica and it lacks only the display pedestal, typewriter and console entry switches for completion.
CONNECTING UP AND TESTING REPLICA
I pulled out my schematics of the boards and wiring of the keyboard and of the driver card that hangs on the side of the fpga. This gave me the final information for how to wire up the replica.
I found a broken lead on one of my connectors coming from the keyboard, which I have to repair before I hook up the replica electronics. At the same time, I must determine how I will mount the fpga board and other wiring, before I go too far forward. The keyboard has connectors on the bottom that must mate up with an extension board on the end of the Digilent FPGA board.
I decided that the fpga and its boards should sit under the black plate covering the keyboard or just to the side. At this point, I discovered that I am missing a major component for the system. It is my 'input board' which debounces and multiplexes many switches into a single I2C line. It handles the push buttons on the side of the keyboard, as well as the keyboard. While I have spare boards to solder up an input board, I don't have all the ICs and other components on hand.
It is possible that I repurposed the input board for use with the Documation card reader, which I was hooking up to the replica to serve as an emulated IBM 2501 card reader. If so, I will have to disentangle it from the PC frame that holds it, since that frame is hard wired to the Documation cables, or at least do medium scale surgery to get the board back into operation.
The board is not the one I expected - it could work out if needed, but the connectors are wrong too. I need to hunt around some more in the garage and sheds for the missing board with its wiring, as otherwise this is going to be painful and time consuming.
The input board takes 32 signals at TTL levels, debounces them as most are switches, shifts the voltage to 3.3V and them multiplexes them on an I2C link back to the FPGA. At a minimum, I need to support the switches on the black plate surrounding the keyboard - Prog Start, Prog Stop, Load IAR, Imm Stop, Reset and Prog Load.
The rotary mode switch is connected separately now, so I can skip those seven signals entirely. The board also supported the Keyboard/Console switch, the six CE switches that cycle through memory or disable interrupts, and a few other miscellaneous signals, none of which are critical to the exhibition.
The board I found inside the 2501-Documation frame is only half populated, which gives it 16 signals, more than enough for the six or seven I need. I will look it over and begin wiring the switches to it. The board does NOT have the debouncers, so I will have to do software debouncing when the signals arrive in the fpga, but it is otherwise very suitable.
I hard wired the input board to the six switches it will handle. This simplifies the code that watches the signals since it only has to read a single 8 bit register in the mux chip. I then connected the I2C link to the appropriate connector to put on the fpga extension board.
The fpga extension board is the central point with two connectors to the keyboard aux circuit board, a connector to the LEDs in the display pedestal and keyboard black plate, a link to the input board handling the pushbuttons, and a few other unused circuits such as the typewriter drive.
I untangled the main power and validated the existence of +5V, +3.3V and +12V power. The power brick gives me the +20V needed by the keyboard solenoid. I will install the power supply and brick behind the footwell cover, under the typewriter section and routed= the power lines up to where they are needed. Of course, it is needed now on the testbench until things are working properly.
The biggest challenge is where to support the fpga and fpga extension board assembly, near enough to all the cables from keyboards and other places, but out of sight and safe from knee intrusions.
I was just beginning to debug when I ran out of time tonight. I have all of tomorrow to get this working, then Friday is reserved for last second things, packing and eventually moving everything to CHM for the festival.
There is going to be a fair amount of debugging once I have everything put back together as closely as I can. I expect to do the debugging on my kitchen island until the replica is working, then move the parts over to their mounting spots on the frame. Time will be very tight!!
My solution for the data link integrity is not good enough. Specifically, the action taken when a transmission error is detected is inadequate. The reason is that my transactions are not idempotent. That is a characteristic that says a transaction can be repeated without any consequence.
I have a transaction that polls for the last XIO issued. As part of the transaction, it resets the remembered values so that a subsequent poll receives null answers until the next XIO occurs. If a poll is returning data from an XIO, but has an integrity issue, when I reissue the poll automatically I will be getting nulls back, not the valid data that was sent in error.
Transactions that have corruption but are caught by the fpga side are safe. They did not occur, thus we only need a very reliable way to tell the Python program that the transaction was ignored, to cause it to resend. This works pretty well now, but could use some bolstering.
Transactions that are corrupted in the returned data words are caught by the checksum and parities, but the correct recovery would be to ask the FPGA to have saved the output and resend it This will avoid the problem of causing transactions to occur more than one time.
The challenge for both of these is to ensure that data corruption does not impact the recover mechanism itself. That is, if we had a checksum failure and sent some code pattern that requested retransmission of the already completed transaction output, that code pattern itself is vulnerable to corruption.
Similarly, if the pattern we send back that tells the Python code that the fpga has ignored a corrupted message, has itself suffered some degradation, we might either resend a transaction that didn't have an error or fail to resend one that did.
I was not going to do any further work on the detection and recovery logic this week, because I have to move everything to the show location on Friday and it is already Wednesday. My demonstrations need to be structured to handle possible one-time failures that will occur due to these low frequency errors in the channel.
Since I was touching this anyway, to deal with timeouts I discovered this morning I put in a 'resend last response' transaction type which just sends back the same 26 words as were last transmitted. The GUI asks for this with errors that represent garbling of the return data.
The GUI sends the same data twice - 12 words then the same 12 words. If the FPGA sees any corruption of the incoming packet, it will take the first 12 words and send back their complement in words 13-24, as a request to resend a command that was seen as malformed.
Tests for malformed incoming transactions are:
- First word does not have special header value, e.g. "101010"
- First and second set of 12 do not match pairwise
The fgpa sends a good packet with incoming words 1-12 sent out as outbound words 13-24. If there was an error, outbound words 13-24 are the complement of incoming words 1-12. If the fpga saw a special code of 0xfabf in either word 1 or word 13, it is maximally different than a good header word and is very likely to be a request for retransmit. To retransmit, the fpga sends the same 26 words as it last sent.
The GUI checks to see that all 12 pairs (1 and 13, etc) match, else it has an indication the fpga rejected the transaction. It tests to see that all 12 pairs are complements of each other, then resends the same transaction another time. If the 12 pairs neither all match nor are all complements, we request retransmission.
If the checksum in word 25 doesn't match our checksum calculation of returned data words 2 through 12, we request retransmission with 0xfabf. If the parity of each of the returned data words 2 through 12 don't match the value we calculate, using odd parity, then we request retransmission with 0xfabf.
The changed logic and code work without any flagged errors, but on the other hand the performance has become abysmal. Where before the 12 word down and 12 word back transaction ran as fast as the real peripherals I am emulating, with 24 down and 26 back, plus checksums and parity calculations, the system is noticeably slower on virtual devices than real ones.
COMPLETING REPLICA COSMETICS
Today, I put the rotating plates on the gray cover that sits in the footwell, facing forward, then mounted the cover. That done, it was time to fit and glue braces on the remaining gray cover inside the footwell, which has no lower or upper frame members to control its vertical position. I hope to have enough friction from repeated braces on the two side frame members to ensure it stays in place.
Each cover took more than an hour, including time to glue up braces in two sittings with drying time in between, then fitting rotating plates and installing onto the frame.
The last gray cover mounts on the left side of the replica. I fit and glued braces, installed the rotating plates and secured that last cover onto the frame. Now the covers are all on the replica and it lacks only the display pedestal, typewriter and console entry switches for completion.
CONNECTING UP AND TESTING REPLICA
I pulled out my schematics of the boards and wiring of the keyboard and of the driver card that hangs on the side of the fpga. This gave me the final information for how to wire up the replica.
I found a broken lead on one of my connectors coming from the keyboard, which I have to repair before I hook up the replica electronics. At the same time, I must determine how I will mount the fpga board and other wiring, before I go too far forward. The keyboard has connectors on the bottom that must mate up with an extension board on the end of the Digilent FPGA board.
I decided that the fpga and its boards should sit under the black plate covering the keyboard or just to the side. At this point, I discovered that I am missing a major component for the system. It is my 'input board' which debounces and multiplexes many switches into a single I2C line. It handles the push buttons on the side of the keyboard, as well as the keyboard. While I have spare boards to solder up an input board, I don't have all the ICs and other components on hand.
It is possible that I repurposed the input board for use with the Documation card reader, which I was hooking up to the replica to serve as an emulated IBM 2501 card reader. If so, I will have to disentangle it from the PC frame that holds it, since that frame is hard wired to the Documation cables, or at least do medium scale surgery to get the board back into operation.
The board is not the one I expected - it could work out if needed, but the connectors are wrong too. I need to hunt around some more in the garage and sheds for the missing board with its wiring, as otherwise this is going to be painful and time consuming.
The input board takes 32 signals at TTL levels, debounces them as most are switches, shifts the voltage to 3.3V and them multiplexes them on an I2C link back to the FPGA. At a minimum, I need to support the switches on the black plate surrounding the keyboard - Prog Start, Prog Stop, Load IAR, Imm Stop, Reset and Prog Load.
The rotary mode switch is connected separately now, so I can skip those seven signals entirely. The board also supported the Keyboard/Console switch, the six CE switches that cycle through memory or disable interrupts, and a few other miscellaneous signals, none of which are critical to the exhibition.
The board I found inside the 2501-Documation frame is only half populated, which gives it 16 signals, more than enough for the six or seven I need. I will look it over and begin wiring the switches to it. The board does NOT have the debouncers, so I will have to do software debouncing when the signals arrive in the fpga, but it is otherwise very suitable.
I hard wired the input board to the six switches it will handle. This simplifies the code that watches the signals since it only has to read a single 8 bit register in the mux chip. I then connected the I2C link to the appropriate connector to put on the fpga extension board.
The fpga extension board is the central point with two connectors to the keyboard aux circuit board, a connector to the LEDs in the display pedestal and keyboard black plate, a link to the input board handling the pushbuttons, and a few other unused circuits such as the typewriter drive.
I untangled the main power and validated the existence of +5V, +3.3V and +12V power. The power brick gives me the +20V needed by the keyboard solenoid. I will install the power supply and brick behind the footwell cover, under the typewriter section and routed= the power lines up to where they are needed. Of course, it is needed now on the testbench until things are working properly.
The biggest challenge is where to support the fpga and fpga extension board assembly, near enough to all the cables from keyboards and other places, but out of sight and safe from knee intrusions.
I was just beginning to debug when I ran out of time tonight. I have all of tomorrow to get this working, then Friday is reserved for last second things, packing and eventually moving everything to CHM for the festival.
There is going to be a fair amount of debugging once I have everything put back together as closely as I can. I expect to do the debugging on my kitchen island until the replica is working, then move the parts over to their mounting spots on the frame. Time will be very tight!!
No comments:
Post a Comment