LisaList2

Servo alignment procedure: https://lisalist2.com/index.php/topic,15.msg37.html#msg37 and last chapter of http://john.ccac.rwth-aachen.de:8000/patrick/UsbWidExamples.htm

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 have also posted this on 68kMLA.

Will the DS101 pass self-test if no drive is connected?

It appears that without a drive attached the controller will get through the Software Reset command successfully, then fail at Sequence Up...

Here are some results from various configurations with no drive connected:

Priam card in slot 3

• Nothing connected or With Cable connected at host end only
  Attempt Boot (Command 8) - 3 beeps, delay, Error 80
  BLU - Hd Identify : No device detected at that port
  
  
• With cable connected to DS101, but powered off
  Attempt Boot (Command 8) - 3 beeps, delay, Error 82
  BLU - Hd Identify :  Error Code 8000E5CB
  
  
• With cable connected to DS101 S#000298, powered on, no Hard Disk or tape interface connected
  Attempt Boot (Command 8) - 3 beeps, delay, Error 82
  BLU - Hd Identify :  Error Code A2FFE5CD
  -- Priam Docs say Error 22 is "Device Not Present"
  
  
• With cable connected to SMART S#008842, powered on, no Hard Disk or tape interface connected
  Attempt Boot (Command 8) - 3 beeps, delay, Error 82
  BLU - Hd Identify :  Error Code A200E5CD
  -- Priam Docs say Error 22 is "Device Not Present"
  (Don't know how to tell which type of board this is: SMART, SMART-E, etc.)
  
  
• With cable connected to DS101 S#0001312, powered on, no Hard Disk or tape interface connected
  Attempt Boot (Command 8) - 3 beeps, delay, Error 82
  BLU - Hd Identify :  Error Code 9D01E5CB
  -- Priam Docs say Error 1D is "PROM checksum error" - persists after reseating EPROMs
  -- this board has remnants of a toe-tag string tied to one of the corners.
  
  

From earlier BLU Priam Error list:
Priam Errors      $yyzzE5xx   ; xx are error code, yy is $80|transaction status (might be the same as the error code), zz is register 3 supplementary status

PriamErrSoftR   EQU   $E5CB      ; Priam error from software reset
PriamErrSeqUp   EQU   $E5CD      ; Priam error from sequence up

"I may be mistaken, but I have the impression you are using a prototype reproduction interface card that hasn't been tested before... any chance you could borrow one of the Priam cards from the museum's collection to see if it behaves differently?"

I guess that is the next logical step. I have an untested prototype and it is possible there was an error somewhere in the
reproduction. I don't have a Lisa with easy access to plug a logic analyzer onto the card

there is something wonky going on with the interface.

I may be mistaken, but I have the impression you are using a prototype reproduction interface card that hasn't been tested before... any chance you could borrow one of the Priam cards from the museum's collection to see if it behaves differently?

https://www.computerhistory.org/collections/catalog/102673923
https://www.computerhistory.org/collections/catalog/102673924

The RAM failure error is what I observed with the extended write signal that corrupted memory... although I can't imagine they were shipped that way. Perhaps there is some part that was marginal and performance decayed.

Similar to what I think you're reporting, I have a vague recollection that I found the RAM failure wasn't reported in response to the software reset command, but turned up later in response to trying to actually do something... I assumed I had somehow missed it as a response to the software reset, but maybe it does behave that way.

Regarding accessing registers twice/redundantly:

Before attempting to interact with the Priam controller, the host must check to see that the "register file" is not busy.

Then (BLU at least) calls a preliminary command setup routine that will write zeros into all the parameter registers, which will also (re)check that the register file is not busy before writing those null parameters.

After performing a command, BLU reads the interface status and transaction status registers to see if the command succeeded, and if not, jumps into the error reporting code which reads those registers again to ensure it has the latest values.

Those redundancies are not necessary but are there in BLU to minimize troubleshooting mysteries.

there is something wonky going on with the interface.
I put up some jpgs of traces in http://bitsavers.org/projects/datatower/traces
The boot is really strange I tried booting twice and there are two reads of the status register
a second before it does then it does a two byte write of 00 then 07
Looking at the smart-e schematic, it flags if there is a back to back command write

The BLU commands make a little more sense

the cmd 7 in ident is failing with a ram failure ?

wr 2 0
wr 4 0
wr 6 0  <--- this would make sense if the params are written to the word-write adr. I wonder if the byte/wrd adr is flipped on the interface just for writes?

wr 0 0
wr 0 7

rd adr 2 -- completion code 1a
rd adr 3 is 0
then it reads 2 and 3 again ??

Truly awesome. Did not see that coming 

Sweet!

-J

Do you have much experience debugging the DS101 board?

Not really. My only 'successful' efforts were the two boards that failed their self test that I've mentioned by email previously. The one with the invalid DRAM write timing (where the write signal was held after the address lines changed at the end of the cycle, causing erroneous writes to semi-random addresses -- "fixed" by adding some logic to terminate the write signal sooner), and the one isolated to a non-functional data bit in the DMA controller, which remains unrepaired in that state.

Since that effort some years ago, I have received a couple of more DS101s from eBay (Many thanks to James Denton), but when I've tried to test them, I find my Priam DataTower no longer works (drive spins up, seeks, and a data stream is present from the head amplifiers, but an ambiguous error occurs -- I presume the drive's digital section is the problem as the symptoms are the same with multiple controllers).

I am going to try poking at a SMART-E board

I suspect the DS101 variety of controller is only needed to access the QIC Tape.

Will the DS101 pass self-test if no drive is connected?

I think so... I'll see if I can try it.