First post, by mkarcher
I intended to deep dive into MCGA hardware level reverse engineering on a PS/2 model 30 - but as it turned out, not only the 10MB hard drive on the hard card is dead (it was already dead when the machine was put into storage), but also both floppy drives in that system failed to boot the IBM system disk (which is known good). I also have a second PS/2 model 30, but the floppy drive on that one died 23 years ago emitting some burnt smell. So two computers with no working storage, which is not good. The Novell Personal Netware infrastructure that I used to remote-boot the storageless PS/2 is long gone, so the only thing directly at hand is IBM ROM Basic.
The broken floppy drives from the computer I expected to have working drives seem to seek properly, but can't read any data. In contrast to many other vintage floppy drives, these drives also don't have a belt. Yet, I decided to program a RPM measurement tool using IBM ROM Basic. Please be aware that this BASIC program is specific to the (early?) PS/2 models of IBM, as it uses a diagnostic input port that is not available on standard PC floppy controllers, but only in the PS/2 I/O Gate Array. Let's go
10 DEF SEG=020 OUT &H3F2, &H1C30 PRINT "Wait for stabilization"40 FOR I = 1 TO 10 : GOSUB 1010 : NEXT I50 GOSUB 2010 : START=TMR60 PRINT "Measuring 100 revolutions"70 FOR I = 1 TO 100 : GOSUB 1010 : PRINT I; : NEXT I80 GOSUB 2010 : DURATION = TMR-START90 PRINT 60*18.2/DURATION*100; "RPM"100 END1000 'Wait for one index event1010 POKE &H440,&H801020 WAIT &H3F0,41030 WAIT &H3F0,4,41040 RETURN2000 'Read BIOS time tick counter2010 X=PEEK(&H46C)2020 Y=PEEK(&H46D)2030 TMR=X + 256*Y2040 RETURN
And, surprisingly, this program really indicated a problem:
OkRUNWait for stabilizationMeasuring 100 revolutions1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 2223 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 4243 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 6263 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 8283 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100616.9491 RPM
Huh, maybe I am just to stupid to get the formula to convert ticks per 100 revolutions into revolutions per minute wrong? Floppy drives are supposed to run at 300rpm, which is 5 revolutions per second. So 100 revolutions should take 20 seconds. I timed the 100 revolutions manually, and obtained 9.8 seconds, so the calculation that resulted in the drive being twice is fast as it should be is obviously not totally wrong, and the drive spins way too fast. Maybe the regulation is gone? I tried a different floppy disk, and indeed, this disk spun at 530 RPM. Now that's funny: Instead of a working floppy drive, I now have a friction measurement device. That's not helpful for data transfer, though... Obviously, the drive just seems to go as fast as possible, with no regulation kicking in.
It turns out you can disassemble the PS/2 floppy drives quite nicely without being afraid of loosing adjustment: You can unscrew the top cover, remove the top PCB and the shielding plate below. Try to not break the plastic clips that hold the shielding plate in place. You can also remove the mounting plate on the bottom, and unscrew 4 screws to take the machanism out. On the bottom side on the mechanism is a second PCB - this is the direct drive motor controller/motor PCB. Parts of the direct drive motor (like the coil for the index sensor magnet, the speed measuring "inductor", and most likely also the three drive coils) are directly mounted on this PCB. There are just 5 wires connecting the motor controller PCB to the main PCB, three of them are power, the last one "/MOTOR ON" and "IDX", so the fault must be located on the motor PCB. And it indeed is. I reverse engineered the complete motor PCB:
The KiCad source code for the schematic as well as a Gimp .xcf file containing the board photo and the component designators as individual text layers are available in the associated GitHub repository.
As you see, the schematic cleanly divides into two parts. The left part contains the motor controller (including speed control), using a dedicated floppy motor controller chip, whereas the right part contains the index pulse generator. This is the first very important thing to understand: The presence of index pulses (which I measured with that basic program) only means that the index sensing coil sees the magnet fly past it. The motor controller needs more precise speed feedback: It uses a signal that toggles 60 times per revolution, and is generated by a magent (perhaps the motor magnets?) flying over a zig-zag trace below the disc-shaped flywheel. This drive does not use the "FG out" signal from the motor controller to generate the index pulses (it could divide the FG out signal by 60 to obtain a single pulse per revolution, but it would not know the rotational position of the disk, so a different sensing scheme is needed).
The final outcome of the troubleshooting is: C1, the DC blocking cap in the frequency meter section, was gone. That's an electrolytic cap, and those are prone to fail when they age. This cap is 33 years old. I tried paralleling another 1µF capacitor, and the speed of the drive suddenly drops when you hold the cap so it touches the signals C1 is supposed to be connected to. I re-ran my basic program with the cap held agains the PCB - and the output was "300 RPM". When desoldering the broken capacitor, I shorted some pins on the motor controller with solder, and need some desoldering wick and flux to clean up the mess I made. This has to wait for some days until I got these supplies.
Some final random notes about the motor controller PCB: It regulates to 300 or 360 Hz on the frequency feedback if the reference crystal has the suggested frequency of 610.2kHz. That is not 300 or 360 pulses per minute, but pulses per second. So that's why I wrote that you need 60 pulses per revolution. You might install crystals of different frequency, so the controller regulates to another speed. In the case of the IBM drive, IBM installed a 508.5kHz crystal, and chose the mode intended for 360Hz operation (mainly for 5,25" HD drives), which also results in 300Hz target frequency. When I checked the main oscillator with the ancient 10MHz analog single channel scope at hand, my first idea was that the scope is completely out of adjustment, because the frequency was way off 610kHz. U2E/U2F seem to be used to reverse the polarity of the hall sensor supply to cut down the standby current. This assumes the hall sensors don't conduct current if supplied in reverse. This feature is disabled by having JP1 (some solder points) open.
