Matching timing to needs of the Pertec drive and cleaning up my controller logic

PERTEC D3422 DRIVE RESTORATION

This morning I sorted out the problem with the Activate Emergency Unload signal, which now immediately retracts the heads and spins down the disk, as it should. I will move on and update the controller logic to accomplish several pattern of seeks to exercise the drive, plus begin watching to see if the drive will attempt to read data from the drive.

At lunchtime, I whipped up the new controller logic and began testing. The two looping patterns keep the drive busy in seek lamp partly illuminated so I know that the commands are issued rapidly. What I don't see is the motion, so I have a flaw in my state machine or setup of the address lines.

After a short look at the Pertec documents I realized I am not meeting all the setup and stability requirements, which are a minimum of .5 us and sometimes 1 us. With an fpga that ticks along at
.02 us clock rate, I need to wait 35 to 50 cycles whenever I change lines. Another issue is the lagginess of status signals. Specifically, when you command a seek or restore, the drive may take up to 1 us before the busy signal goes on, thus my state machine thought that the drive had already finished. In fact, the shortest time even with zero movement or an addressing error is 2 us, 100 cycles.

I modified my state machines to stick in those wait durations before lunch was over and went out to test some more. First shot, didn't work. This evening I stuck in some diagnostic indications and retest (as well as looked over my logic for flaws). Even with greatly extended times, the FSM wasn't working. More seriously, once I had every valid state of the FSM lighting an indicator, I saw that it would often get lost in some invalid state - not covered by 'others' or any valid state.

I have to figure out why I have this flaky FSM behavior as that seems to be the likely source of the problem, not my drive nor the intent of my logic. This will take some study, I guess I can work out the logic to read in and decode the header section of the first sector, while I mull on the main problem.