The distributor from whom I bought the console printer continuous feed paper is located fairly close to me, I discovered when they shipped the box yesterday. It will arrive Monday even though sent by ground transportation. With a name like Global Industrial and no obvious mention of location on the web site, I had no idea it was in Sacramento, a couple of hours drive from here. I wasn't anticipating the arrival anytime soon.
The DCIP program will print out the disk sector on the 1053, but it expects that tabs are set every six or so positions in order to fit all 16 words on a typewritten line. I tried to set the tabs by pushing my manual space button on the typewriter, but found it tabbing rather than spacing which is a definite defect in the spacing adjustment. Since spaces work properly when printing under program control, it is a maladjustment in the manual button setup.
The typewriter is getting better at unlatching at the end of a carrier return, and more of the returns are occurirng at reasonable speed, but I still have the other problems such as failure to latch the return reliably at the start of an operation.
xxxxxx
1442 CARD READER/PUNCH RESTORATION
On the other hand, my resupply of the Bondic material to repair the punch wheel is inexplicably delayed by Fedex. It was due yesterday and was in the hands of the nearby distribution center in Oakland, one hour away, but didn't arrive. The message from Fedex says "appears delayed should arrive no later than Jan 1". Huh? Then the doorbell rang in the morning and Fedex had come through.
xxxxxxxxxxxxxxxx
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I found my logic flaw that caused me to stuff memory incorrectly from a disk sector I read with my virtual 2310 adapter - I had been storing twice as many words as requested, with every other word consisting of incorrect values. It was indeed a defect in how I was handling indexing through a byte by byte array on one side and a 16 bit word array on the other.
The test on the 1130 worked much better, but there is still an issue. Although I step through the entire sector buffer and convert the values, I found that only the first half of the disk buffer was filled correctly - 160 words - while the second half bore no resemblance to the real disk contents.
The trace of the data I was processing showed that this defect was reflected in the data I converted from 1130 simulator file format to the array of words. That is, somehow the second half of the disk sector buffer is not valid. Problem again stemmed for two sizes (321 and 641) for operations. Fixed.
My next test showed that I was indeed reading the sector correctly in storage, then my python code pushed an operation complete to the FPGA. It does not appear that the FPGA requested the interrupt to handle the op complete, however, so my attention will turn to that logic for a while.
I also attempted to do the same test but entering a known sector that would require the diagnostic program to do a seek before attempting the read. It is likely that the same flaw in interrupts occurred here, because it never tried the read. I will put in suitable instrumentation to watch what is happening in the seek code.
Running with diagnostic messages on, I tried to do a dump of sector 0x0123 which should force a seek before it reads. What I saw was:
I should not be processing the XIO IR a second time. My logic that fetches the last XIO command should zero out that field such that I get back 000 and ignore anything until the next real XIO occurs. Instead my transaction is given a second XIO IR in a row without the system having reset the first op complete.
While it is dimly possible that the diagnostic is issuing XIO IR from within the interrupt handler and is aware it hasn't responded to the previous Op Complete, I don't understand how it would check for the second read to have completed in this situation. Therefore, I believe this is an artifact of my logic in the FPGA or in my Python code in the PC. The answer is more instrumentation.
The trace of the data I was processing showed that this defect was reflected in the data I converted from 1130 simulator file format to the array of words. That is, somehow the second half of the disk sector buffer is not valid. Problem again stemmed for two sizes (321 and 641) for operations. Fixed.
My next test showed that I was indeed reading the sector correctly in storage, then my python code pushed an operation complete to the FPGA. It does not appear that the FPGA requested the interrupt to handle the op complete, however, so my attention will turn to that logic for a while.
I also attempted to do the same test but entering a known sector that would require the diagnostic program to do a seek before attempting the read. It is likely that the same flaw in interrupts occurred here, because it never tried the read. I will put in suitable instrumentation to watch what is happening in the seek code.
Running with diagnostic messages on, I tried to do a dump of sector 0x0123 which should force a seek before it reads. What I saw was:
- XIO IR with check (meaning dont' transfer data issued
- Op complete sent for the IR Check
- DSW Reset issued indicating it saw the interrupt
- XIO IR issued (should have had seek here)
- Read of 321 words into memory
- Op complete sent
- XIO IR issued again (no DSW reset sent)
- read of 321 words again, not the correct data this time
- Op complete sent for this IR
- DSW reset issued.
I should not be processing the XIO IR a second time. My logic that fetches the last XIO command should zero out that field such that I get back 000 and ignore anything until the next real XIO occurs. Instead my transaction is given a second XIO IR in a row without the system having reset the first op complete.
While it is dimly possible that the diagnostic is issuing XIO IR from within the interrupt handler and is aware it hasn't responded to the previous Op Complete, I don't understand how it would check for the second read to have completed in this situation. Therefore, I believe this is an artifact of my logic in the FPGA or in my Python code in the PC. The answer is more instrumentation.
No comments:
Post a Comment