General Category > Lisa Troubleshooting and Repair

BLU LLF Failing

<< < (3/4) > >>

mikerofone:

--- Quote from: patrick on January 04, 2025, 02:09:26 am ---Your photos show return code 00 00 00 xx, so the INIT SPARE TABLE command passed. The last digit indicates the number of spares used. In your case it is between 03 and 04. The number may increase after a couple of surface scans.

--- End quote ---
Ohhh, thanks for the explanation! I didn't know how to interpret the full error code, glad to hear I was wrong.


--- Quote from: patrick on January 04, 2025, 02:09:26 am ---The diagnotic firmware always reports 0 spares used. To see the correct number you have to use the RW firmware.

--- End quote ---
That would have been nice to know beforehand, maybe something to add to the BLU manual? As far as I can tell, this expectation isn't documented anywhere. I assumed that the BLU would only work with the debug ROM since I didn't get any responses with the stock FW. I guess my original z8 CPU or its ROM was really busted!
I was considering burning a stock ROM and testing it, but discounted the idea since I had no idea how to verify that it'd be working correctly. Should have just done it anyways since...


--- Quote from: patrick on January 04, 2025, 02:09:26 am ---qTry a different Z8 chip (e.g. your piggyback with a RW ROM) and check the ripple on the power supply voltages.

--- End quote ---
That did it! All the flaky and erratic power-up behavior is gone plugging in the 341-0080-B ROM! \o/ :D :D
While the power up self-test still doesn't do the back-and-forth seeks it's been doing before, I was now able to install and boot LOS without issue afterwards. I assume that running for extended periods of time with a bad PSU (only emitting 4.4V and who knows what ripple before recapping, as mentioned above) might have killed the chip.

THANK YOU SO MUCH! You saved my ProFile, and with a lightning-fast response time here too! :)

Cheers
mikerofone

stepleton:

--- Quote ---I also tried NeoWidEx, but any command talking to the ProFile just hangs immediately. I think my machine is a Lisa 2/10, with the ProFile connected to its internal parallel port via a bracket connecting to the internal 26 pin ribbon connector, and with ROM H/88. So I think it should work? However, it seemed that all the Widget-specific items in the menu were enabled, so maybe it misdetects my ProFile as a widget. Such confuse, very mystery!
--- End quote ---

Strange to see this, since NeoWidEx should be working a little harder to guess whether the drive is a Widget --- it's not based on the port in use. Did you ever see a line on the screen saying "SEEMS WIDGETY"?

mikerofone:
Thanks stepleton, I don't remember it saying "seems Widgety" but I did notice that the BLU reports a type of "????????" in the IDENTIFY screen, and vaguely remember seeing similar garbage in NeoWidEx. I assume that should have a more meaningful value? I tried both the 341-0080 and 341-0080-B ROM and it didn't make a difference.

Not sure if it's related, but even though I formatted the disk during LOS3.1 installation in "shared" mode for MacWorksXL, the HD installer fails to initialize the drive in either shared ("no space for MacWorks files on HDD") or full MacWorks mode (errors out immediately after a seek to track 0 with code -189 or -198, don't remember).
I had a MacWorks dual-boot before, so the HW is capable of it. The disk performs some seeks when MacWorks initializes and then gives a crossed out ProFile icon after a brief Happy Mac display, and it also seeks when inserting a floppy disk or clicking buttons in the "Install to disk" software. But it doesn't show up on the Macintosh desktop and I'm also never prompted whether I'd like to initialize an unformatted disk.
In the end, I don't really care about MacWorks on my Lisa, so I am perfectly fine with only installing LOS, which is working a treat again! Thought I'd mention it here just in case it's useful information for improving NeoWidEx. :)

Cheers
mikerofone

stepleton:
Thanks for this information: it's possible that the ProFile with the formatting ROM reports a different drive type to an ordinary ProFile; I'm sure this is documented somewhere if so. This could be confusing my Widget-detecting code.

The formatting mode is not relevant to drive type detection: instead, the controller on Apple parallel port hard drives return a data block when you read from block $FFFFFF. This data block is synthesised by the controller and isn't read from the disk. The contents of the data block can depend on disk contents (for example, the data block will say which spare blocks are used and what they are used for), but the identification of the disk type itself should not change.

patrick:

--- Quote from: mikerofone on January 04, 2025, 05:04:53 am ---While the power up self-test still doesn't do the back-and-forth seeks it's been doing before, (...)

--- End quote ---

It should not do so. When you start the drive with the cover removed, you can watch the stepper motor moving. It should go to track zero (with the interruptor into the sensor) and then step by step over each track. Only when a bad block is encountered, it will move to the spares track in the center and then continue. With a perfect drive you will see one smooth movement before the Ready light stays on.



--- Quote from: stepleton on January 04, 2025, 06:37:17 am ---Strange to see this, since NeoWidEx should be working a little harder to guess whether the drive is a Widget --- it's not based on the port in use. Did you ever see a line on the screen saying "SEEMS WIDGETY"?

--- End quote ---

With a broken ROM chip it is unlikely that any tool would recognise this drive properly. This will require at least one good handshake to read block $FFFFFF.

Navigation

[0] Message Index

[#] Next page

[*] Previous page