Print

[stepleton]

A forum member who may choose to make themselves known has given me two sick Widgets. I'll try to see what I can do with them; I'll post about them here for the sake of sharing experience and attracting advice.

Both appear in reasonable physical shape; the two-layer controllers have the -D ROM revision and the Lizzy chip with the mask ROM (i.e. not the piggyback variety).

Widget #1 spins up readily, releases the brake, and attempts to move the heads. These attempts fail: the heads move, but I don't think they get to where the servo wants them to go. Here's what this sounds like: https://photos.app.goo.gl/pH4CwwTTKpvY7z1N8
Using the UsbWidEx servo debugger, you can put the servo into 57k6 bps mode, but it's never fully happy: you seldom see ServoRdy=1 and ServoErr=0. I'll have to do the work later to understand the servo status codes.

Widget 2 has stiff bearings and sounds awful, but it turns. No apparent attempts to move the heads after the brake releases. In the servo debugger, you can put the servo into 57k6 mode as usual, but now even the status command times out.

More updates as they come!

[patrick]

Look at test points TP9 (POS_B) and TP8 (POS_A) on the servo board while moving the heads manually. You should see two sine waves with 90° phase shift. If your oscilloscope has an X-Y mode, use it and you will get a circle. It should have a more or less circular shape and a radius of about 5V. If it is not, the optical system needs to be aligned. http://john.ccac.rwth-aachen.de:8000/patrick/UsbWidExamples.htm#session4

Never move the heads if the spindle motor is not spinning! Without rotation, the airflow is missing and the heads will scratch on the magnetic surface.

A servo reset signal will release the HDA brake. This is the loud "clonk" after startup.

[stepleton]

Thanks Patrick! I had a look at the servo for Widget 2, and I think it's fine now. Many of the chips were socketed, so I pulled each, burnished the legs, applied contact cleaner, and reseated them all. The servo now passes all of the oscilloscope tests on your website, more or less (there's room for some adjustment, but things seem more or less OK). Now Widget 2's problem is that it can only read from Head 0; diagnostic reads from Head 1 yield something like the following:

Code: [Select]

> k101,101
 160401010101E1 --> 00080000
> x
 1209E4 --> 05090000
> s0,1
 130100EB --> 00: 05090000
 Standard Status:
  No matching header found
  Operation failed
  Controller self test failed
  Controller aborted last operation
 130101EA --> 01: 05000000
 Last logical block: 000000
 130102E9 --> 02: 01010101
 Last seek to cylinder 0101, head 01, sector 01
 130103E8 --> 03: 01F90101
 Current cylinder: 01F9
 130104E7 --> 04: 81430102
 Internal Status:
  Auto recovery on
  Controller LED on
  Read a header after recal
  Seek complete
  Servo Auto-Offset is on
  For the last system command,
  * the current block is a Spare
 130105E6 --> 05: 0001DBE0
 Controller selftest failed:
  * No spare table found
 Z8 port 2:
  * Disk R/W direction set to Read
  * SIOrdy = 1
  * MSel1  = 0
  * MSel0  = 1
  * /PBusy = 1
  * /PCmd  = 0
  * ECC ok
  * State machine is stopped
 I/O control port 0x1F00:
  * CRC ok
  * Write valid
  * ServoRdy = 1
  * ServoErr = 0
  State machine state 0
 130106E5 --> 06: 88C09020
 Last Read operation:
  Read error occurred
  CRC or ECC error occurred
  ECC error detected
  CRC error detected
 Last Write operation:
  Write error occurred
  No matching header found
  32 bad retries
 130107E4 --> 07: 01010101
  Last seek came from cylinder 0101, head 01, sector 01

I'll set Widget 2 aside now and return to Widget 1 for the time being...

[rayarachelian]

Tom, can you say a bit more about this:

Using the UsbWidEx servo debugger, you can put the servo into 57k6 bps mode, but it's never fully happy: you seldom see ServoRdy=1 and ServoErr=0. I'll have to do the work later to understand the servo status codes.

Does this work through UsbWidEx, or do you need to attach a terminal to the widget, etc?

[stepleton]

In the Widget, the controller and the servo communicate with each other through a serial link. When the Widget powers on, the data rate is 19200 bps, but part of the normal Widget startup procedure is to switch this link to 57600 bps. When you're talking directly to the servo with a UsbWidEx device, you have to tell the servo to switch to 57600 bps mode yourself (via the UsbWidEx servo debugger 'n' command), since the controller isn't there to do it for you.

At all times, it's the UsbWidEx that's talking to the servo, and it switches the data rate it's using automatically if you execute the 'n' command. There wouldn't be much use to attaching a terminal to any part of a Widget, so far as I know: the servo serial protocol in particular is just bytes and nothing ASCII.

[stepleton]

Widget 1 continues to behave as it has last time. Following the instructions linked above, I found that the LED current was low and replaced the coarse adjustment resistor with a lower value, then adjusted as directed, but this then increased the amplitude of the POS_A and POS_B signals considerably. Even before the adjustment (and still afterwards), in the X/Y plot, these signals appeared to have a 1V offset from being centred around 0V,0V. I made adjustments, and this was about the best I could get:

https://photos.app.goo.gl/aJCD7Uu7Nwi7bK8j7

(The video shows repeated attempts at a data recal as commanded by a UsbWidEx in the servo debugger mode.)

The encoder gain adjustment was quite sensitive and nonlinear, and I probably ought to have exercised some contact cleaner into the pots ahead of time.

I noticed that one of the two L165 amplifiers on Widget 1's servo board seems to get pretty warm, warmer than I remember these parts getting for Widget 2. I put heat sinks on the amplifiers temporarily while I was adjusting the encoder gains. The attached thermal image shows that the one furthest from the card-edge connector gets up to about 60 degrees C this way after a few minutes. I'm not sure if this indicates a fault or if the arm is just stiff.

To finish on a happier note, here's a video of what I think is a healthier servo on Widget 2:

https://photos.app.goo.gl/mVcNxuQQjZ55d5hWA

I could adjust the tach gain pot so that the action goes to 35ms as recommended (instead of around 30ms as shown), but given that the problem now seems to be related to Head 1's ability to read, I think I'll focus my attention there instead. My next strategy will probably be to swap parts around between the boards of these Widgets (and perhaps some working Widgets as well) to try and isolate a fault.

[rayarachelian]

Good to know (about 56K, etc.) thanks.

[compu_85]

The head voice coil can not make much torque. Unplug the head wires, and voice coil wires, and with the drive spinning try to move the heads by hand. (As Patrick noted - the platters must be spinning - don't drag the heads across the stationary disk!)

It should feel completely smooth with little resistance, and no bumps / detends. If you feel any, you can try moving the heads back and forth a whole bunch by hand to "work out" the sticky spot.

[cheesestraws]

Hello!  I am belatedly making myself known as per the first post :-).  I didn't realise there was a thread here about these, so I will watch with interest.  These are the Widgets that came with my Lisa: the person who sold it to me said they hadn't been working when he got them, either, so they have been dead for a while, and have pretty much just sat in a box since I got them.  I'm really glad SCIENCE (or at least ENGINEERING) is now happening to them :-)

[patrick]

If you are interested in some internals of these drives, you can read this article: http://john.ccac.rwth-aachen.de:8000/patrick/UsbWidLA.htm
Many technical documents originating from the Apple Drive Division can be found at bitsavers: http://bitsavers.org/pdf/apple/disk/widget/
There you will also find the widget firmware, in a form that can be modified and reassembled (e.g. with the "as" assembler). This could be used to bypass faulty areas on the hard disk surface or to implement further debugging functions.

Here are some examples of working with UsbWidEx http://john.ccac.rwth-aachen.de:8000/patrick/UsbWidExamples.htm. This is the tool that Tom currently uses with your drives.

NeoWidEx https://github.com/stepleton/NeoWidEx you can use yourself by simply running it on your Lisa.

[stepleton]

I only ran across that "Deep Dive into Widget" article a few weeks ago! I still have it open in a browser tab. Among other things, the article provides clear information about the SysRead and SysWrite commands that tempts me to finally add them to NeoWidEx. Right now these are marked as "not implemented yet" as I hadn't taken the time to try and understand the protocol in detail. The lack of these commands is one of the things blocking NeoWidEx from a 1.0 release

Thanks for taking the time to write the article!

[stepleton]

No real progress to report from simple interventions with the two sick Widgets, but at least we might be able to eliminate certain possibilities.

I first tried @compu_85's head-turning advice on Widget 1, but regrettably (for hopes of having a quick answer) it seems to move freely: it is easy to rotate by the axle and moves cleanly from stop to stop.

I then tried swapping the servo, read-write, and controller boards between both Widgets, but there is little to no change. Widget 1 still attempts to move Head 1 on startup but doesn't ever sound like it successfully completes a recal. Widget 2 can still only read from Head 0 --- diagnostic reads from Head 1 produce random data that changes between reads.

I tried doing some probing on the Widget 2 motherboard with an oscilloscope, but didn't get very far. I think I need to take time to understand it better; also, signals from the arm are very slight. There is also the idea of interchanging the motherboard between both drives, but this will probably require an optics recalibration each time.

In any case, given that board swapping doesn't change behaviour very much, it seems like the problems with both Widgets are now narrowed down to the mechanism itself or to the motherboard. (I assume that the motor board is fine for both.) I'm not 100% certain of this, though.

[compu_85]

I've read the calibration procedure for the motherboard's pots a few times.... and still don't understand it :/

I've gotten 1 or 2 dead Widgets going again just twiddling those adjustments and listening to the sound of the stepper 

I have one drive with a very low SN mechanism which works OK, but just can't "fast seek" as well as the drive in my 2/10. The startup scan takes a bit longer, with more time between steps.  I suspect a proper tuneup would make this better.

-J