The interface on my drive is defined by the model number as "special", which means it doesn't match the schematics in any Pertec document and more importantly, it doesn't make use of the terminator power pin on the main connector to the interface board.
The drive produces 3.3V as pullup power for the terminator resistors, but this interface board ignores that. Instead, it feeds terminator power to the interface on pins 1 and 2 of one of the two 50 conductor cables. I shall have to do the same, feeding from my fpga board.
It was time to bring up the fpga board and check out the voltage levels on the incoming signals, in addition to powering up the drive itself. I proceeded to fire up the drive and then use the fpga board to command a spin-up. The voltage checks without power produced confusing results and I had to do some troubleshooting., Turns out that the ground of the interface is also not connected to the drive ground so I had to include that wiring.
Once the terminator was pulling voltages up and I was receiving reasonable status, I began to test out the functionality. The results were good but not perfect for this first run. Successes:
- A button push would command spin up or shut down of the drive
- When I set up a nonzero cylinder address and hit the seek putton, it moved the arm
- When I pushed the restore button, it brought the arm back to cylinder zero position
- The Unit Ready signal came out as the drive came ready
- Write Protect lights and extinguishes as I change the drive write protect switches
Failures to fix up include:
- Write protect status appears on the wrong led compared to what I expected
- I don't see the sector and index pulses on the LED, which makes sense given their short duration and high frequency
- I could see that one pair of the switches for entering a cylinder address are swapped positionally
- Emergency Unload does not happen at my button push even when held low for a long period
- my logic to display the sector count register appears defective
- sometimes the seek or restore buttons didn't work, other times they did
I can get erratic status led illumination if I wiggle the connectors onto the fpga board, so these are not of sufficient quality. I have female connectors on my cable and the fpga board is female connectors, so I was relying on some male-male adapters but they fit loosely in the connectors. This may work for initial checkout but I need a more reliable cabling scheme for when I begin to use the drive in earnest.
Looking at the signals I use, versus irrelevant ones (like double density, double or quad platter because I know what I want), plus dropping the busy and select lines for drives 2 3 and 4 that I won't have connected, leaves me with exactly 39 interface signals to receive or drive.
That is a fortuitous number, because it matches the 40 I/Os of FX2 extension board I have on the fpga board. This extension board will allow me to solder all the wiring onto the board, rather than relay on flaky connectors and adapter pins.
I will begin rewiring the interface all to the extension board, dropping signals I will ignore, and documenting the changes so I can update the fpga logic appropriately. This is a must-do for today before I try to accomplish more testing. I also had a wire snap off one of the connectors, which is inevitable with a rickety ad hoc cabling.
Investigating my problem areas from the first test, I found and corrected a few of the issues. Others will take more testing, particularly the state machines for my command buttons and the sector count display logic.
I put a voltmeter on the signal for Emergency Unload, which should be pulled up to +3 but then will be yanked down to ground when I drive the fpga output pin to logic level 0. It instead only drops to a bit under 2V when my signal is asserted. This means something else is holding this line up, which I have to diagnose within the disk drive. The wiring from the schematics shows this signal hooked directly to the input of an inverter, a section of U50 on the logic board, so that is where I need to look.
By dinner time, I had soldered in 22 of the 39 signals, those from one of the two 50 conductor cables, and went back to the workshop afterwards to finish the last 17. I will then have to update my documentation and the vhdl code to pick up the signals on these new pins. The power on test showed it was correctly set up.
The sector number display is whizzing through the numbers 00 to 23 that occur on each rotation. This validates the logic to see the index and sector pulses, plus the counter that tracks which sector is under the heads at any moment.
It appears that a Restore Initial Cylinder wouldn't work if I had a non-zero address in the cylinder address switches. On investigation, the reason is that I am violating setup times for that signal. A seek strobe is issued essentially simultaneously with setting that restore line, whereas it needs to be settled before the seek strobe occurs. I made changes to my state machines to correct this.
The problem that is still open involves the emergency unload signal, as I mentioned above. I set up the voltmeter to monitor what happens to that line when I try to drag the output pin of the fpga down to zero. I may have a bad chip or two in that path. What I see is the input to the first inverter stays at full high (3.29V) regardless of my attempts to pull it down.
It behaves as if something is doing a hard pullup of the pin on the logic board, so that my attempt to drop it simply divides the voltage across the resistors in the circuit from the fpga to the logic board inverter. This could be a failed inverter that is outputting on the input pin, but I suspect this is in my special interface board somewhere.
I exercised the positioner quit a bit tonight, moving it small and large amounts in both directions. My corrected logic for the Restore Initial Cylinder function now works - it moves the arm slowly back instead of the jump that occurs if it were a seek to cylinder zero.
Tonight and tomorrow I will change the controller to execute some programmed sequences of seeks, plus I will set up to switch between the four surfaces (two platters, two heads for each). That will be the last of the commands I can try that don't involve reading or writing on the disk.
It will also have a switch to turn on the read enable line, to see if it attempts to read data. I can set up a scope to watch what streams in from the heads. The fpga board has plenty of onboard memory capacity, so that I could read in the bitstream and begin analyzing it.
Not germane to this post, but to your efforts generally: do you know about micropython? It is a very small controller board with lots of inputs (but probably not the 50 or so you need) which runs Python 3.4 on the bare silicon. Watch the intro video at https://micropython.org and I think you will be extremely impressed with the ease of programming, as compared to an fpga.
ReplyDeleteI pick the component to use based on the requirements. In addition to the fpga boards, I have various mbed, arduino, raspberry pi, edison and other small devices I would use for controllers.
ReplyDeleteIt comes down to how parallel and fast I need the logic to be. The controller for an HP line printer to make it appear to be an IBM 1403 was done on an Arduino because it was pretty easy to handle this sequentially. Same with the controller for the keypunches and paper tape devices. However, with some peripherals it is easier to set up hardware to directly manage each bit of the peripheral independently, and to directly control it in granularity of 20ns or less.
Parallelism, speed/responsiveness, input-outputs, functionality,, programmability . . . all factors that go into the mix for which device I pick for the job.
I am using fpga as fan-out devices where they may control several different peripherals simultaneously. As long as all the logic fits on the fpga chip, there is no impact at all from adding on additional devices, whereas with a processor of some type the code gets more and more challenging to integrate.