Friday, July 31, 2015

Still battling sector read logic in my controller for the Pertec D3422 disk drive

PERTEC D3422 DRIVE RESTORATION

I implemented the merged single FSM this morning and did the test of it at lunchtime. I found some errors with signals starting out at the wrong level - fixed with appropriate startup logic - and can see that my synchronizer is not working properly. I went in to ponder, research and set up diagnostic instrumentation.

Later I ran some tests and it appears my problem may be while resynchronizing for the data field, after I have successfully read the five bytes of the header field. Time to rexamine my assumptions and do some digging.

Looking at the documentation, you would believe that the preamble and the zero bits between header and data fields are both greater than 200 bits long, but when I look at the assembler listing for the controller, I see that the gap between header and data is only a fourth the size of the preamble.

This causes the problem, since I insist on 80 bits of zeros before I will check for an xFF (sync byte). There aren't enough bits of zero to satisfy that first step in the synchronizer. I will fix this with an additional input parameter, InGap, that will shorten the target count when resynching between fields.

The logic that finds the desired sector is working perfectly and I was successfully reading the five bytes of the header, but then the machine is stalling. After quite a few changes trying to find the issue and fix it, my logic no longer reads the first five bytes. Time to look over the sync and assembly functionality for possible redesign.




No comments:

Post a Comment