Debugging the virtual 1442 functionality
I have to find and fix the source of corruption of the buffer contents that occurs sometime in the feed cycle after the data is pushed from PC down to the pre-read buffer. Reading the card contents appears to get the correct data, but when it is fetched from the pre-punch buffer at the end things are wrong.
I need specialized diagnostics to figure out where things are wrong and then zero in on the source of the problem. I spent my free time at lunch devising these diagnostic signals. The other function that is not yet tested to completion is the program load (boot) process that takes the first card image, converts it to the special program load format and places the data in the first 80 words of core.
Back to basics in checking this out. First step was to read a card into core and exhaustively check all 80 columns against the card image. Do again for a second card. This combination will tell me for sure whether the data is loaded into the pre-read buffer and extracted into core properly.
As I had believed, the card image is loaded in core for all 80 columns in exact accordance with the holes in each virtual card. I then reran the test with the stacker output file open to see what is extracted into the output file. It will have read correctly, so that any changes occur during the copy-over from pre-read to pre-punch or in the extraction of the pre-punch buffer back to the PC to be saved in the output file.
This also confirmed the corrupted state of the output card images. The contents of column 1 are repeated in columns 11, 21, 31, 41, 51, 61 and 71, instead of the contents I should see in those columns, Since this occurs modulo 10, which matches the get special content transaction stride, the finger of suspicion points to the logic that does the fetching - either in the fpga where the transaction is implemented or in the Python code where it is issued and processed.
I have a test I can put into the fpga that will check the value of column 11 of the pre-punch buffer, showing me whether it contains bit 10 incorrectly copied from column 1 or if bit 10 is off as it should be. This will tell me if the pre-punch buffer is ever corrupted in the FPGA or if the issue is within the fetch operation itself.
I ran the test in the morning and found the bad data (column 1 data found in column 11) coming out of the pre-punch buffer.This problem is vexing. I included extra cycles to ensure long setup and hold around the write to the pre-punch buffer, but that seemed to make no sense.
The modulo ten behavior argues strongly for this to be related to the get special data or write special data transactions which handle ten columns each time they are called. I just can't see anything wrong yet.
I do have a plausible sequence of events to cause the problem. If the address for the pre-read or pre-punch buffer memory is seen as zero, that will cause it to output the contents of card column 1. Since these malfunctions happen in relationship to the fetch transaction, somewhere in the get special data transaction flow,
Somehow, I am letting the address of the pre-punch buffer go to zero and that is when I am latching up my outbound data word. My transaction process loads the address for memory as it starts up from incoming word 2 of the transaction, then increments it during the course of the transaction.
There are other ways for the address to get to zero, since I have a mux on the address lines which is switched by control signals when the get special, write special, copyover, XIO read and XIO write logic is active.
I tightened up what I could particularly concentrating on the address mux and the get special transaction and went back to testing. The results were even more mysterious. My first run was to read in several blank cards, copying them over to the output file and verifying that they were all blank there.
Next, I closed all the files, did an NPRO, opened a deck with card images and read several cards copying the image over to the output file. In all of these, the first column and every ten thereafter was blank!
Now I am really mystified. I might completely restructure all the logic around the buffers. I have to ponder this.
Implementing physical plotter (1627 equivalent)
I did strip out and change the logic for the 1627 (plotter) device to produce a simple transaction over to the slave FPGA. When an XIO Write occurs, one or more of the command bits is on in the word sent by the program. These are copied over the fast link to the slave, where anytime we have 1 or more bits on, it fires off the associated signal lines to the 1627 electrical adapter box - inverted logic so that any bit that is on becomes a 0 signal to the 1627 electrical adapter, the remainder stay at 1.
The slave FPGA holds these signals for a defined length of time then drops them. A response signal, D1627done, is normally 0 but is switched to 1 when the timed operation on the plotter is complete. When the slave board sees the command bits from the master reset to all zero, it drops the D1627done signal to complete the transaction. The master sees the D1627done signal turn on, triggers the response interrupt for the 1627 to the 1130 and then goes back to wait for the next XIO.
I need to add a Not Ready signal from slave to master, as well as a way of determining that the 1627 is ready or not, which will be a switch I hook up. The logic should ignore the XIO Write when the device is not ready.
Implementing physical paper tape reader/punch (1134 and 1055 equivalents)
I began the same process of moving the timing related and machinery control portions of the device adapter over to the slave FPGA, with the 1130 facing logic left in the ztex FPGA to handle XIOs, interrupts and so forth. The slave must provide the Not Ready signals from the two paper tape devices, as well as the same kind of transactional mechanism as I used for the 1627.
I will send a punch command signal and output bits to the 1055 and do an interlocked wait for a 1055 response. For the reader, there is only one command that is sent over, a request for movement command which sends back the 8 channels from the paper tape character as well as an interlocked response signal.
The movement control and timing is done in the slave, while the master will control the simple transactions and feed the buffered tape character to the XIO Read command. It also handles sense bits and interrupts. Both devices should ignore commands when not ready.
3D Printer Kit Assembled
I bought a low cost 3D printer kit (Hictop 3DP08) and assembled it in a few hours after it arrived. When I powered it up, the behavior was bizarre but that seemed to be flawed firmware (code in an Arduino that drives the unit). Although the tech support from the maker is quite limited, I found one post they put up in response to an Amazon feedback entry where they gave a link to a Dropbox with the firmware file.
With the new firmware file, the machine was much much better. I discovered a need to reroute some cables and to make tweaks to the alignment for the heated bed, but I expect with another hour or less of work it will be ready to pump out 3D parts in PLA and ABS plastic. By eight PM it was humming along on all axis smoothly. Tomorrow I will do a few prints - it does take a bit of setup time for any printing, getting the bed completely parallel and lining it with an adhering surface, then a few hours to print a reasonable complexity part - which is why I wont' start it tonight.
No comments:
Post a Comment