Up until mid morning of Saturday, I was completely engaged in building up fpga logic to support PC emulated peripherals, and making corresponding changes to the Python program that runs on the PC side. This extended beyond the simple functions I needed just to finish the cycle steal fetch and store operations when requested from the PC side.
These extensions will be needed to move to the next level where I appear to be a card reader, printer, punch, plotter or other peripheral so that I can do useful things bypassing physical punched cards and paper.
My first tests on the machine were to determine what was failing with the two channel address in lines. The gates were not functioning on the two chips involved, but I had a few spare gates in another location on the board. After I relocated the wires to the replacement gates and tested, I was able to set up correct addresses for cycle steal fetch and store. I still need to do a more exhaustive walk of the address range to be sure everything is good, but it is promising.
I did a few tests storing at different fixed locations and am not satisfied - so more Channel Address In testing. The data side works perfectly, giving me the right pattern each time, but addressing still needs work.
I began testing the new two-way link functionality between PC and fpga - rather than continually sending the status information as I had before, the protocol has the PC requesting a transaction with two words sent out over USB. For most transactions, the fpga will echo back the two words, which allows the PC side program to check for transmission issues.
The original status messages are now sent in response to a particular transaction, eleven words of status data followed by the two words sent to start this transaction. Some transaction types are asking for data to be returned - for example the two words asking for a cycle steal fetch will come back as the original first word (the command) but with the retrieved data as the second word.
This will take some time to wrestle with the code until it is sending and processing the transactions as I designed them.
I did a few tests storing at different fixed locations and am not satisfied - so more Channel Address In testing. The data side works perfectly, giving me the right pattern each time, but addressing still needs work.
I began testing the new two-way link functionality between PC and fpga - rather than continually sending the status information as I had before, the protocol has the PC requesting a transaction with two words sent out over USB. For most transactions, the fpga will echo back the two words, which allows the PC side program to check for transmission issues.
The original status messages are now sent in response to a particular transaction, eleven words of status data followed by the two words sent to start this transaction. Some transaction types are asking for data to be returned - for example the two words asking for a cycle steal fetch will come back as the original first word (the command) but with the retrieved data as the second word.
This will take some time to wrestle with the code until it is sending and processing the transactions as I designed them.
No comments:
Post a Comment