LisaList2
General Category => LisaList2 => Topic started by: AlexTheCat123 on July 25, 2021, 10:59:54 am
-
I was lucky enough to stumble upon a Widget drive at an e-waste recycler around a week ago (unfortunately, the rest of the Lisa was nowhere to be found) and I'm going to try to repair it in the coming weeks once my schedule gets a little less busy. Unfortunately, I only have a Lisa 2/5, so I'm unsure about whether the Widget would actually work with my Lisa. Since it uses the same interface as the ProFile, I would assume that I could just connect it to the external parallel port with the appropriate cable, right? Has anyone actually tried this before?
-
Congrats. Yes it will work with a Lisa 2/5, but you'll need to rig up external power and a DB25 to ribbon cable.
I'm not sure, but you might need +12V and -12V as well as +5V and GND. I think the drive cage uses a 24V fan, but not sure if the -12V is used by the drive or just the fan. Obviously you can use whatever fan you like in your own enclosure. I think the fan hooks up to the drive with a 2 (or maybe 3?) pin plug, but obviously not needed for your own enclosure + fans.
If you have an old full height SCSI drive enclosure it might work, but yeah, the power supply might be an issue.
-
Great! It should be really easy to make the appropriate DB25 to ribbon cable and I can use an ATX power supply for testing just like I did with my ProFile.
-
Sure, an ATX PC power supply should work, though you may need to force it to power on by shorting the right pins. see: https://www.smpspowersupply.com/connectors-pinouts.html
-
Yep, I've got an ATX power supply that has a wire permanently soldered between those pins that I use for testing stuff.
-
From the fiddling I've done with this, the Office System gets grumpy when there's a widget on the first parallel port of a 2/5.
Perhaps you'll have better luck! You can convert the pin header on the controller to a DB25 with the parallel port cable from an old PC.
-J
-
So I've fired up the Widget and it seems to mostly work (I can install and boot LOS on it just fine), but sometimes it just randomly stops booting and I have to go into NeoWidEx and reinitialize the spare table (and then reinstall the OS) to fix things. I want to give it a low-level format in the hopes that this will clear up some of this strange behavior, but the low-level format always fails. It seems to succeed with the trial format on cylinder 0, but then it tries to format cylinder 221 and gives the error "Failed to fine-tune head position at this location. The initial handshake with the drive failed." This seems really odd because I thought that the Widget only had 202 cylinders to begin with. What could be causing this problem?
-
Good question here --- I've had to try and rekindle some of my Widget memory, and I don't think I'm all the way there. If we're lucky, Dr. Schaefer will chime in with real knowledge.
So formatting from cylinder $221 is normal behaviour for NeoWidEx. I think the reason for this is because there are two ways of "recalibrating", or resetting the head servo and getting the Widget's heads close to a known location over the platter. There's an ordinary one called a "recal" or "data recal", which places the heads near the innermost data track, then there's the "format recal" which places the heads "about 36 tracks closer to the inside diameter of the disk", a place where "the disk surface in this area is not likely correctly [sic] store information written there". You can see this text on page 98 here:
http://bitsavers.trailing-edge.com/pdf/apple/disk/widget/Widget_ERS.pdf
When formatting, NeoWidEx follows a script that Dr. Schaefer observed whilst watching an Apple /// format a ProFile. You can skim the comments in the source code here:
https://github.com/stepleton/NeoWidEx/blob/main/NeoWidEx_UTIL_Format.X68#L128
where the comments at the top of each "block" of opcodes say what's going on. Anyway, the format starts formatting tracks from the position it reaches after a "format recal".
I'm not sure what the story is with the failure you're observing, and it may take some back-and-forth to sort it out. Perhaps a good turn-it-off-and-on-again first question to ask is: what ROM revision is your Widget? In other words, when you do DRIVE INFO, what's the number after "REV-"? The UsbWidEx documentation (http://john.ccac.rwth-aachen.de:8000/patrick/UsbWidEx.htm) recommends formatting with the latest firmware revision, 1A45. I'm not sure if that's relevant here, but it would be interesting if you were using a different version.
-
It looks like the ROM revision was indeed the problem. My Widget had 1A43 originally, but after installing 1A45 like you suggested it formatted perfectly and the format seems to have solved the reliability problems! I wonder what's different between the two revisions that keeps the LLF from working with the older one?
-
Ha, well, like they say, it's better to be lucky than good :)
Glad it's fixed, although I also wonder whether simply resocketing the 1A43 ROM would have had a similar effect.
It's possible that your older ROM might have been compatible with the READ_ABORT_STATUS command (https://github.com/stepleton/NeoWidEx/blob/main/MANUAL.md#abort-status) as implemented in NeoWidEx. I ought to have asked you to give the ABORT STATUS menu option a try after your format failure.
It might be nice to have a copy of 1A43 on some public archive. I can see that bitsavers (http://www.bitsavers.org/pdf/apple/disk/widget/firmware/) has archived some source code for 1A43, but I don't think we have the ROM data anywhere.
-
Glad it's fixed, although I also wonder whether simply resocketing the 1A43 ROM would have had a similar effect.
As a test, I tried putting the old firmware back in and it refused to format again, so I think the failure has to do with the ROM version itself instead of just being a connection problem.
It might be nice to have a copy of 1A43 on some public archive. I can see that bitsavers has archived some source code for 1A43, but I don't think we have the ROM data anywhere.
I just uploaded the contents of the EPROM to archive.org and it can be found at the following link: https://archive.org/details/1-a-43 (https://archive.org/details/1-a-43)
-
The Set_AutoOffset command fails with Firmware 341-0289-B (1A43) because it just wasn't there. It has been added with 341-0289-C (1A44).
-
That is an excellent reason for the command to fail!
Alex, thanks for trying a second time.
-
Alex, thanks for trying a second time.
No problem! I'm glad that we've figured out the reason that it failed and I hope that this information will be helpful to more people in the future!