Thursday, October 15, 2015

Debugging away on the virtual 2310 and mirror 1053 device adapters, plus some disk and tape device activity

1053 CONSOLE PRINTER RESTORATION

Every test I run on the 1130 is further exercising the 1053 mechanism, which should work out any stiffness from old lubricants and get me closer to a properly operating, fully restored console printer. Of course, I am still missing the rearward pulling spring on the tab interposer although in operation I am seeing tab operations taking place so this might not be as much of an issue as I assumed.

P390 SYSTEM CHECKOUT

The tape drive is cabled up but until I find a Centronics SCSI terminator I won't be ready to power up and test this. I was sure I had a few but after a couple of hours searching, I decided to just order one and test when it arrives Saturday.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I fired up the system and began some debugging. First, I realized that my fpga code is not working properly, to save the character typed into the FIFO and deliver it on request, as I am instead fetching an all zero character from the buffer. I will look into the logic to correct this.

My 2310 disk drive emulation testing showed me that the DCIP standalone utility has issued the XIO Sense DSW to the drive but doesn't like what it is seeing, since it goes into a loop continually sensing. I will have to dig into the program code to see what the utility is expecting to see and therefore what I need to be presenting with my driver logic.

I found a flaw in how I track and update the DSW for the virtual 2310 drive. This is probably a flaw that exists in other virtual drivers as well. Once I am sure this problem is gone, I will wrap the fix to the other devices.

Even with the fix made, something is not working properly. When my Python program requests the last XIO function code from the fpga logic, that act should reset the saved code so that further requests from the software will get a code of 0 until a new XIO is issued by the program.

After thorough review of the fpga logic, that reset has to be occurring. I then looked over the Python code and found two anomalies in the Python code for handling XIO Sense which might be contributing to the problem, although I didn't see the direct mechanism that would induce the symptoms I experienced.  With a new fpga bitstream loaded and new diagnostic output on the PC side, I went back to test.

I had also spotted something wrong in my fpga logic for the console printer mirror adapter which would result in it failing to capture the character written by the XIO Write instruction. I made those changes along with the 2310 adapter fixes and did a combined test of both adapters.

The 2310 test stopped initially on a Not Ready state for the drive, which should not have happened, but once I pushed start the program began merrily issuing XIO Init Read commands to analyze the pack. I had an error message from my Python code to investigate, but this is definitely progress.

My change to the 1053 mirror adapter now gets me different symptoms - the fpga side returns 'buffer empty' continually and I didn't see any data characters. That implies that the function to write into the buffer is failing, but I do need to stare at everything to be sure it is all solid.

I am getting an XIO Init Read with a word count of 0 from the standalone DCIP utility - will have to research what the drive will do with this - probably accomplish ECC checking but transfer zero words - which kind of makes sense for a Analyze function of the utility. The reason I am getting all the XIO Sense DSW invocations is the utility watching the sector number, I think. Anyway, my error checking assumed a wordcount of zero is an error but I have to change that.

I had it looping continually on the XIO Init Read operation - this also appears like the prior error, where it acted as if the fpga logic is not zeroing out the prior XIO function code once it is polled by the PC. I need to look more deeply, because that is a pretty basic flaw that must be fixed first.

I also had an error where I had opened and run against the disk file, then closed the file and shut down the virtual disk. When I started the virtual device again and attempted to reopen the file, I took an error. I need to figure out what flaw allowed this and correct it. However, I am done for the night with testing.

ARRIVAL OF SECOND PERKIN-ELMER DISK DRIVE

The drive arrived safe and sound and will be stored while I work on the first of the two. My back is already hurting from wrestling my P390 and tape drives around when I installed the SCSI cable - I can't even move the wood board with the drive inside to a convenient location until I feel a bit better. 

No comments:

Post a Comment