Lisa Widget Drive Repair -- Errors 81, 82, 85 and one successful boot

[grbrady220]

I've been working through my first Lisa 2/10 and have the machine working well enough to want to try using the Widget drive.

I've gotten through many of the common issues. It initially was reticent about spinning up and was noisy, but after considerable cleaning and prodding it now spins up, needing a gentle push about 50% of the time to get started. The bearing is not what I'd call whisper quiet, but it's definitely quieter than I feared and seems to get quieter with use.

The brake on the head actuator was releasing on spin up quite reliably, but this has stopped happening. The head actuator moves freely and at various times has seeked successfully and read data. Currently the head does not release, but I'm somewhat confident the servo loop on the spindle motor has closed, as the index pulse period on the scope is very steady (is there a way to confirm that the loop is closed?)

Currently I am getting error 81 when starting up after a significant wait and some very brief, small movements of the head actuator. Before that I was getting error 82 nearly immediately after a bit more head activity. I also get error 85 spuriously. NeoWidEx currently reports that no drive is connected.

Prior to this, I had a period where the drive was successfully recognized. Watching the head, it would do a slow scan across the drive surface and the happily seek back and forth under control. It would usually get into the MacWorks "loading" screen, but the most common outcome was a hang there. On one or two occasions it successfully booted into MacOS System 6. I was able to open files and run programs from the Widget without trouble. I was thrilled, but sadly it was short-lived.

I started probing the BUSY and CMD lines and can confirm that currently BUSY is asserted while the drive is spinning up and remains asserted except perhaps for a few pulses. Consequently CMD is only asserted in a few quick pulses and then has no further activity. This seems to jive with the behavior on the Lisa end.

So I was wondering if anyone there can help me try to diagnose the drive? I have a two-channel sampling scope and logic analyzer and intermediate level expertise on how to use them. I'm just not well versed on how to narrow down the problem with a Widget. It occurs to me that these symptoms are plausibly consistent with a problem with the encoder grating, but I am reluctant to open the drive if it's not needed.

I'm also struggling with having, perhaps, not quite the correct schematics. For example, my controller board is P/N 667-0110-C (two layer controller), and I can't seem to find schematics for that anywhere. Using the schematic for 050-5023-B, most things seem similar but I can't always be sure that discrepancies are due to the schematic or a fault.

Thanks for any help and I will also post this on LisaList2.

 

[stepleton]

Hi grbrady220,

Widgets are fairly rare, so many repairs often encounter unique problems. I haven't heard of a syndrome quite like yours, but that in itself is not unusual.

The numeric errors you see can be interpreted in a few ways, but I always like to reach for the Lisa Boot ROM source code. The constant definitions at the top show that

...that I accidentally posted this too soon by accident! I will continue this post in a second reply

 

[stepleton]

Anyway, they show these definitions:

0000| 0000 0050 NODSK .EQU 80 ;DISK NOT ATTACHED
0000| 0000 0051 DSKBSY .EQU 81 ;DISK NOT READY
0000| 0000 0052 BADRSP .EQU 82 ;UNEXPECTED RESPONSE
0000| 0000 0053 STATNZ .EQU 83 ;NONZERO STATUS BYTE
0000| 0000 0054 BADHDR .EQU 84 ;INCORRECT HEADER
0000| 0000 0055 TMOUT .EQU 85 ;TIMEOUT ERROR

You can get some insight into where in the handshake your Widget is failing by seeing where in the source code the symbols are used.

NeoWidEx will only report natively that a Widget is present if that Widget completes virtually all of its power-on process successfully: that is, spinning up, releasing the brake, performing a "recal" (swinging the heads and making a "squeaky squeaky" sound), and then doing a track-by-track surface scan of the disk. As your disk is failing somewhere along the way, it isn't getting to the point where it will respond to normal ProFile-style commands.

In this situation, it's appropriate to force NeoWidEx to pretend a Widget is present. It's been a long time since I've tried to deal with a Widget in this state, but if you do, do you find that some of the status recovery commands (e.g. FULL STATUS, SERVO STATUS, or ABORT STATUS) recover sensible data? These commands do not require the heads to move. I am not sure that the Widget will respond to these commands if it never gets as far as releasing the brake, however --- the controller may just be waiting on the servo indefinitely.

If you are up for it, you may find the Widget controller and servo source code on Bitsavers to be useful for your debugging needs, but that is getting deep into the weeds! Still, if I were in your shoes, and I didn't have a UsbWidEx (which can talk directly to the servo), I'd try to reverse-engineer a reason why the servo isn't releasing the brake.

I would be surprised to find that a damaged coarse sensor optical graticule prevented this. I think it is wise to avoid opening the Widget for now; I'm not sure, but I doubt your answer lies in there.

I'm not sure which Widget schematics you are using --- I am guessing you're using the ones from here. There are some more in this document, but they seem compromised by lots of xeroxing. There are some reverse-engineered schematics here that you might compare against.

I think it's wise to ask on LisaList2 as you are doing --- you will hopefully find answers backed with more experience than mine!

Good luck!

 

[grbrady220]

Thanks for the response!

I skimmed the boot ROM assembly code and it looks like the logic for generating these is quite simple. Error 81 is generated when a wait loop expires after ~100 seconds without BUSY going low. If BUSY does go low, we proceed to the check for error 82. It asserts the CMD line and looks for a 0x01 response from the controller. If it doesn't get it then the error results. I think this is consistent with what I was seeing on the BUSY and CMD lines with the scope. So the question now becomes "what is happening on the control board that is preventing the Z8 from twiddling these lines correctly?" I'm thinking the answer lies somewhere on the Servo board, but I guess I should dig into the source for the controller Z8 to confirm.

I spent last night trying to understand what conditions need to exist for the brake to release. I was thinking that the spindle motor speed control circuit drove this, since the brake connects to this circuit. I came to the conclusion that, while there may be some connection relating to how the COP421 adjusts the amount of current going through the motor windings, the brake release signal ultimately comes the controller board Z8 with feedback from the servo board. This was probably already well-known.

To get to this conclusion, I went through the COP421 disassembly that I had, which was uncommented and was a real bear to even partially understand. I commented it as best as I could. Wow, the COP421 instruction set is strange! The code is pretty obscure and seems redundant in places, but the conclusion I came to was there is no explicit control of the brake solenoid. I might post the commented code (after cleaning up some stuff I know to be wrong now) if there is interest and if no one is aware of a better version.

So, this is now making me think the servo board and NeoWidEx is probably the next thing I need to work with. Unfortunately this will require a 100% working keyboard, which is pending for me. My keyboard apparently reports that every key in 3 columns of the matrix is pressed. On probing around, I found that the three lines of the XR22-908-03B capactive sensing IC corresponding to these columns are shorted to ground. I even clipped one of the pins to isolate it from the PCB and the short remains, so I assume that's a bad chip. I found replacements on eBay (for a premium) and am awaiting their delivery. I couldn't find any replacements for the other capacitive sensing chip, so I hope it's good and remains that way.

In the interim I guess I should also start looking at the code for the Z8 on the servo board. Let's hope it's less obscure and better commented than the COP421 code. I will also think about building a UsbWidEx, but maybe delay this until I get more indication that the servo calibration needs to be looked at more closely.

Of course, my ultimate fear here is that I've had a head crash or something and either the heads or or the platters are trashed so that the servo is unable to determine that the spindle motor speed is stable enough to release the brake. I'm guessing it might be difficult to discriminate between this and poor calibration, at least without a UsbWidEx. It would be really nice if the Lisa itself (running NeoWidEx or similar) could generate the signals needed to exercise the heads for calibrating he servo, but I assume there's a good reason why this is isn't possible.

Thanks again and I hope I'm working in the right direction.

 

[stepleton]

Good luck --- it sounds like you are as much a scholar of Widget as the rest of us, perhaps even moreso.

At this point you are forging ahead into terrain that virtually nobody has visited for 40 years. The commented COP code will be useful to share if you are inclined. There is much more commentary on the Z8 code out there courtesy Dr. Patrick Schäfer, whom you've already contacted, so that will be easier going for you. I am a little surprised that Dr. Schäfer hasn't commented the COP code, but I may have misremembered that he did that. If not him, I can't think of anyone else who would.

Per a previous discussion here on 68kmla, the only reason NeoWidEx can't swing the servo in a way that would be helpful for calibration is because I didn't have the wits to program it in.

Is there a chance you are anywhere near London, UK? If you're near me or near someone else with a UsbWidEx, then we can try talking to your servo directly.

 

[grbrady220]

I started trying to work with NeoWidEx, but the system freezes when I try to do almost anything. I am now fairly consistently getting error 85 and the BUSY line is always asserted and never goes low. Looking at the Z8 firmware this is all consistent with something failing a test very early on. It looks like that could be the RAM, ROM, or the motor speed failing. Or the Z8 itself. Amy thoughts as to how to narrow it down more? I’ll dump the EPROM but what about the ROM in the Z8 itself?

 

[grbrady220]

There was a single bit difference between my ROM dump and the image I found on Bitsavers. So, I burned a new one which of course didn’t substantially change the behavior. I “ll see if I can source some 6116 SRAMs but I don”t see anything compelling probing around it.

I also measured my motor speed as 3089 rpm, or a 19.4 ms period. This is a little fast and the code comments states the 19,5 ms is the shortest period that’s ok. So maybe I need to adjust the motor speed somehow?

I’m not in the UK, but thanks for the kind offer.

 

[stepleton]

what about the ROM in the Z8 itself?

Some Widgets have the Z8 with the "piggyback" ROM --- a ROM IC that rests atop the microcontroller. You can see a picture of it here. It sounds like you have the other kind of Z8, the one with the mask ROM.

There is a chance that the mask ROM on your Widget is corrupted, but I suspect this is unlikely. I also would not leap to replace the RAM at this early stage.

More than anything, the tool I'd like to have in your situation is a logic analyser. Being able to snoop on the various address and data lines to find out where the Widget is getting hung up would be very helpful. I assume that you would have mentioned it if you had a logic analyser, but just in case: have you got one? If so, how many channels? If not, could you lay hands on one somehow?

I also measured my motor speed as 3089 rpm, or a 19.4 ms period. This is a little fast and the code comments states the 19,5 ms is the shortest period that’s ok. So maybe I need to adjust the motor speed somehow?

It would be handy if we had a convenient way to browse this code and link to specific parts of it. I've never heard of a Widget that runs too fast, but, as mentioned, at this point most Widget syndromes are unique.

 

[cheesestraws]

I might post the commented code (after cleaning up some stuff I know to be wrong now) if there is interest and if no one is aware of a better version.

I have nothing much to add to this thread except a seconding that it would be really neat if you feel like you can upload this code with your comments!

 

[grbrady220]

Some Widgets have the Z8 with the "piggyback" ROM --- a ROM IC that rests atop the microcontroller. You can see a picture of it here. It sounds like you have the other kind of Z8, the one with the mask ROM.

I have the Z8 with only the internal mask ROM ("Lizzy"). Having a piggyback one would be nice, but the only seller I can find them at is Vintage Micros and they want more than would like to spend. I started thinking about how to make a board with a ROMless Z8, a regular EPROM and a multiplexer/latch for handling the shared address/data bus. It shouldn't be too hard, but not just a matter of wiring some pins together. If I need to low level format drive I'll definitely have to act on this.

More than anything, the tool I'd like to have in your situation is a logic analyser.

I do have a logic analyzer (mentioned it in passing in my first post). It's an inexpensive 16 channel Saleae clone but can be pretty useful (except for the clips for grabbing on to pins. Those are terrible and fall off constantly. I need a better solution there.) I'm thinking it would be good to hook up to the shared bus lines and the higher address bits as well as R/W_, DS_, and AS_, triggering off AS_ or DS_ depending on if I want to look at address or data activity? I wasn't able to glean (or don't recall) whether there's any external indication from the Z8 as to where it is in the self test code, but that would also be an interesting pattern to look for.

It would be handy if we had a convenient way to browse this code and link to specific parts of it. I've never heard of a Widget that runs too fast, but, as mentioned, at this point most Widget syndromes are unique.

The code I was referring to here is the in the controller Z8 Self Test where it times the index pulse to figure out the drive speed. This is all commented and reasonably straightforward to understand (at least at a high level) in the code that's already posted online.

I have nothing much to add to this thread except a seconding that it would be really neat if you feel like you can upload this code with your comments!

I will consider doing so. However, I now realize that I misunderstood a bunch of stuff that I understand a bit better now and I should go through the code again and revise my comments. The gist of how it works, I think, is that it is cycles through bit patterns energizing the coils in the brushless DC motor in specific ways based on feedback from a pair of Hall sensors that tell it the rotor position. It's slightly odd in that it doesn't use a lookup table or the like to change these patterns but rather a series of hard-coded branch instructions for different Hall sensor configurations and stored information about recent states of the system. In any case, it seems to me that in a scheme like this the only way the steady state motor speed could be wrong is if the clock driving the microcontroller was wrong or the control code was wrong.

I believe the COP421 is also able to vary the current flowing through the coils when they're on (and hence motor torque) using a PWM-like scheme. To do this it uses the tied together serial I/O pins and the serial shift register to form a ring oscillator that just keeps cycling the same bit pattern through repeatedly without any intervention from the time-critical code controlling the motor speed, except when it wants to change this pattern (which changes the duty cycle of the PWM output.) This drives a transistor network that allows more or less current through the coils when they're energized.

Note that the motor control circuit is entirely independent from the rest of the Widget drive, it doesn't feed any signals at all back to the control or servo boards, nor does it receive anything. The COP421 just sits there all by itself trying to keep the motor spinning at a constant speed, never knowing if it's doing a good enough job. The signal for releasing the brake isn't even generated by it, but rather the Z8 on the control board using signals from the Servo board. It seems like the Widget drive design could have been considerably simplified, but I guess Apple made some mistakes on their first attempt at a hard drive.

 

[stepleton]

I started thinking about how to make a board with a ROMless Z8, a regular EPROM and a multiplexer/latch for handling the shared address/data bus. It shouldn't be too hard, but not just a matter of wiring some pins together. If I need to low level format drive I'll definitely have to act on this.

This doesn't help the project of trying to make arbitrary code for debugging, but is there anyone around you with a Widget that you could approach for a temporary Lizzy swap? At a minimum, it can eliminate the IC as a potential problem point, though I believe it's probably a long shot.

With your willingness to "get into the weeds" of Widget, I wonder if it might make sense to approach Dr. Schäfer for parts for your own UsbWidEx. It may be a bit of an extravagance for a one-time repair, but never fear. Your Widget will break again

I do have a logic analyzer (mentioned it in passing in my first post). It's an inexpensive 16 channel Saleae clone

Apologies for missing this.

Unfortunately I haven't had the chance to double-check your measurement ideas, but it seems like it can't hurt.

One other idea would be to snoop on the serial connection between the controller and the servo board. (BTW: In my earlier messages, I'd mistakenly been thinking of the "motor control board" as the "servo board" --- further apologies for my rusty memories. This board (the C-shaped board with the COP) is not the same thing as the servo board, which has its own Z8 and can swing the arm and release the brake. In this image, the servo board is second from left, while the motor control board is at lower right.)

Anyway, the controller/servo link is a serial connection with TTL logic levels, and somewhat annoyingly the controller changes the baud rate shortly after start-up from 19200 BPS to 57600 BPS if memory serves. Based on this schematic, you can find the two serial directions on pins 4 and 5 of the controller Z8. A Saleae might be able to decode serial traffic, or perhaps you might have a scope that can do it --- in any case, the benefit here is that you have only a few pins to worry about rather than a lot of them. Even without decoding, if you spot serial traffic at all, you know that the controller Z8 code is reaching a particular location, and if you can identify the speed of the traffic, you can know more precisely still.

Other signals that look like they might be of interest are SERVORDY and SERVOERR, found on pins 51 and 49 respectively of U3. It may be pretty hard to get a probe into that PLCC, so pins 9 and 4 of RP3 might be an alternative.

If I need to low level format drive I'll definitely have to act on this.

You likely already know, but for folks stumbling on this thread later at least: this is only necessary for ProFile, not Widget. The regular ROMs support low-level formatting and a variety of other commands.

The code I was referring to here is the in the controller Z8 Self Test where it times the index pulse to figure out the drive speed. This is all commented and reasonably straightforward to understand (at least at a high level) in the code that's already posted online.

Indeed. This is more of a general wish --- I wish we had something like GitHub where we could link to specific lines of the source and easily browse it, not sitting in a ZIP archive or spread across a bunch of dot-matrix printout PDFS.

I will consider doing so.

Let us know if there's a good way to twist your arm

 

[grbrady220]

I received a second (obviously nonworking) Widget drive today. As a quick check I swapped controller boards and the macroscopic behavior was indistinguishable, so I suspect my Lizzy is probably fine. This new-to-me drive does not even spin up, though, and I believe I hear a rattle inside when it is moved, which is worrisome. The spindle bearing is of course very crunchy feeling, but I think no worse than my other one was (and that is feeling very smooth now). I suspect that the Darlington transistor array on the motor board is bad, since it gets burning hot, but whether that is a root cause or a symptom/effect I don't know.

I will set up the logic analyzer this evening or over the weekend and see what I can find. At least I now have a source for parts when I do find something rather than waiting for an order to arrive.

 

[stepleton]

IIRC I've observed a hot Darlington array on a drive that wouldn't start turning on its own. After an attempt or two at "push-starting" the spindle (like the "prodding" you were doing, it sounds like), it would spin, but it seems like a stuck spindle just means a lot of current through the array and a lot of heat. Naturally I wouldn't want to leave it in that condition for very long!

 

[grbrady220]

I grabbed a few traces on the logic analyzer, focusing on several pins on the controller Z8, Lizzy. If I understand what I'm seeing, it looks like it falls over almost immediately after coming out of reset, and never really gets the serial comms to the servo board up and running. Both Lizzys I have behave the same way.

One other thing I tried was replacing the PLCC socket for the gate array U3. The pins on the chip itself were badly oxidized (nicely cleaned up now) and the socket itself had seen better days, with some pins not looking like they could make good contact. I just replaced it since I have a bunch of 68 pin PLCCs on hand. However, this made no notable change in behavior.

 

[stepleton]

That's interesting ... what are you triggering on here? It looks like there's some serial line traffic and some attempt to decode it; does the bytestream have any resemblance to what ROM source code says? The traffic does look somewhat dubious to me.

Would love to delve deeper but the workday awaits...

 

[grbrady220]

I believe I was triggering on /START, but I now am of the opinion that that wouldn't tell me much useful, triggering on /RESET would be better.

I also believe the "activity" we're seeing around the rising edges is just spurious glitches from slow rise times on the signals. To try to combat this I've cleaned the pins on my Lizzy and Gate Array chips more carefully and replaced the Lizzy socket, as when I was looking with the scope probe the rise time improved if I pushed harder on the chip. So I'm assuming that makes better contact at either the probe-chip leg interface or at the chip leg-socket interface. I also noticed that the rise time is particularly slow on the open collector lines with external pullups. If I replace the pull-up resistors with a smaller value the rise time is shortened, i.e. 3.3k changed to 1k. I don't know if this is a good idea to do or not with all the open collector lines. I'm reverting back to the nominal for now and will take some more traces. Note that there is lots of activity on the shared data/address between the Z8 and the gate array and between the gate array and RAM and ROM.

I am starting to source components for a USBWidex and reached out to Dr. Schäfer at the email address on his web site. However, if there is a problem with the controller (in that it's not talking over its connector going to the Lisa) would the USBWidEx be especially helpful for debugging it? If it won't talk to the Lisa (running the BootROM or NeoWidex) why would it talk to the USBWidex. I get how it might be useful to connect to the servo board and Z8 over the serial line, etc., but if that's ultimately not where the fault lies then what more would we learn? I guess more information is always better, though, and a tool to low level format and exercise the actuator would definitely be nice to have.

Related to low level formatting, is it necessary to completely degauss the disk or will the tracks laid down previously not effect the servo or data reads?

 

[stepleton]

I also believe the "activity" we're seeing around the rising edges is just spurious glitches from slow rise times on the signals. To try to combat this I've cleaned the pins on my Lizzy and Gate Array chips more carefully and replaced the Lizzy socket, as when I was looking with the scope probe the rise time improved if I pushed harder on the chip. So I'm assuming that makes better contact at either the probe-chip leg interface or at the chip leg-socket interface.

It sounds to me like improving the probe-to-pin connectivity may be the main factor here. Since your controller swap yielded the same behaviour you saw earlier, I'm inclined to suspect that the controller is OK overall and that the problem lies elsewhere.

I am starting to source components for a USBWidex and reached out to Dr. Schäfer at the email address on his web site. However, if there is a problem with the controller (in that it's not talking over its connector going to the Lisa) would the USBWidEx be especially helpful for debugging it? If it won't talk to the Lisa (running the BootROM or NeoWidex) why would it talk to the USBWidex. I get how it might be useful to connect to the servo board and Z8 over the serial line, etc., but if that's ultimately not where the fault lies then what more would we learn?

To my mind, really conclusively isolating the fault to the servo board is pretty handy. If your UsbWidEx can't swing the servo, we'll know that it's necessary to concentrate troubleshooting there. Once your servo is shipshape, then there's a chance that your Widget would just work; if not, the controller may be the next place to look.

Related to low level formatting, is it necessary to completely degauss the disk or will the tracks laid down previously not effect the servo or data reads?

I've never known old tracks to affect a proper format. There was a problem with versions of BLU not actually formatting each track and so old data would have an effect that way, but NeoWidex or UsbWidEx ought to both be capable.