I fired up the system for testing and found that my fpga and PC transactional links are no longer in synchronization. The Python program writes 12 words out and pulls 12 words back, but times out during this activity before the first monitoring transaction has completed.
The error is almost certainly in the fpga side - time to scrutinize the logic for the link and the transaction. I will also look at ways to use some LEDs as diagnostic signals from the fpga. I found some places that looked suspect in the basic FSMs for transactions and
My first tests show me that I wrote the 12 words out but when I tried to read back the 12 inbound words, I timed out trying to fetch the first pair. Definitely time to hook up the LEDs to the remaining few signals on the FPGA board and clue me in to where I am stalling.
Once the 12 word transactions are reliably swapping for the background status monitoring task on the PC, the one that displays the registers, clocks and so forth, I can debug the slightly more complicated code to load core with a PC file, stuffing up to 12 words per transaction. After those work, it should be straightforward to get the mirror 1053 and virtual 2310 functions working.
CHM CARD CAPTURE FOR MUSIC PROGRAMS
One of my teammates at the 1401 restoration group, Stan, found several music playing decks for the 1401 (picked up by an AM radio held near the system while the programs are running). He asked me to scan these in so that another member, Van, can examine the code and work out the best version for demonstrations at the museum.
I used my Documation card reader to read these as both ASCII and raw card files. The ASCII files use a translate table developed for most IBM 1130 Fortran and Assembler decks, selecting which hollerith patterns (holes on the card) become certain ASCII characters.
I had some read checks on one deck, because blank cards had been inserted to separate what is probably different songs within the deck. To make them visibly distinct, someone picked red card stock. Since they are totally blank, the orientation shouldn't matter except for one weakness that remains with the Documation readers.
They were notorious for throwing read checks if cards had the diagonal notch on the right upper corner of the card. I had developed and installed a hardware fix that eliminates this error, by ignoring the top row of the card when the machine is doing its error check at the column 81 time. In the blue music deck, one red card was placed with the diagonal notch at the lower right corner, where it tripped a read error. I could have added row 9 to the hardware modification, but this is a very unlikely situation which was easily rectified by flipping the blank red card around.
The ASCII mode is not a complete translation, both because some 029 keypunch characters don't exist in ASCII, and because the 1401 used 026 keypunches with different assignments of hollerith to BCD and therefore to ASCII. Finally, the mapping of card columns to text files is inexact.
This is why I included a raw card image file that ensures zero data loss from the cards - Van can use the combination of the two formats to be sure he has workable programs and data. The work was done quickly (after I found the errant position of the red card) and the filed emailed back to Van and Stan.
Once the 12 word transactions are reliably swapping for the background status monitoring task on the PC, the one that displays the registers, clocks and so forth, I can debug the slightly more complicated code to load core with a PC file, stuffing up to 12 words per transaction. After those work, it should be straightforward to get the mirror 1053 and virtual 2310 functions working.
CHM CARD CAPTURE FOR MUSIC PROGRAMS
One of my teammates at the 1401 restoration group, Stan, found several music playing decks for the 1401 (picked up by an AM radio held near the system while the programs are running). He asked me to scan these in so that another member, Van, can examine the code and work out the best version for demonstrations at the museum.
I used my Documation card reader to read these as both ASCII and raw card files. The ASCII files use a translate table developed for most IBM 1130 Fortran and Assembler decks, selecting which hollerith patterns (holes on the card) become certain ASCII characters.
I had some read checks on one deck, because blank cards had been inserted to separate what is probably different songs within the deck. To make them visibly distinct, someone picked red card stock. Since they are totally blank, the orientation shouldn't matter except for one weakness that remains with the Documation readers.
They were notorious for throwing read checks if cards had the diagonal notch on the right upper corner of the card. I had developed and installed a hardware fix that eliminates this error, by ignoring the top row of the card when the machine is doing its error check at the column 81 time. In the blue music deck, one red card was placed with the diagonal notch at the lower right corner, where it tripped a read error. I could have added row 9 to the hardware modification, but this is a very unlikely situation which was easily rectified by flipping the blank red card around.
The ASCII mode is not a complete translation, both because some 029 keypunch characters don't exist in ASCII, and because the 1401 used 026 keypunches with different assignments of hollerith to BCD and therefore to ASCII. Finally, the mapping of card columns to text files is inexact.
This is why I included a raw card image file that ensures zero data loss from the cards - Van can use the combination of the two formats to be sure he has workable programs and data. The work was done quickly (after I found the errant position of the red card) and the filed emailed back to Van and Stan.
No comments:
Post a Comment