Print

[blusnowkitty]

Any clues on why low-level formatting a 5MB Profile with BLU is failing during the Spare Sector format? I keep seeing Status 00000001 or 00000003 midway through the Spare Sector format.

[blusnowkitty]

So, found an old post on LisaList1 where Jason ran into the same problem. I'm seeing the same thing as well, ? as device name and completely nonsensical sizes in BLU. But the fun thing is... Office System can still format and install to the drive without issue regardless?

https://lisalist2.com/lisalist1/2682.html

[compu_85]

I was just going to reply that I ran into this same problem formatting ProFiles in BLU 

[AlexTheCat123]

I've had the same issue too.

[patrick]

Any clues on why low-level formatting a 5MB Profile with BLU is failing during the Spare Sector format? I keep seeing Status 00000001 or 00000003 midway through the Spare Sector format.

This is no fault. It just means that 1 resp. 3 spare blocks are in use. As long as this number is below 0x1F your drive will be useable.

[compu_85]

Ya, sounds like a bug in BLU then, because if it's not a 0, the process bombs out.

-J

[blusnowkitty]

And indeed, most of the time during the spare sector format when it errored out the stepper motor would be halfway or 3/4 across the surface of the disk.

[sigma7]

Thanks for the clarification, I'll add this to the bug list.

Any clues on why low-level formatting a 5MB Profile with BLU is failing during the Spare Sector format? I keep seeing Status 00000001 or 00000003 midway through the Spare Sector format.

This is no fault. It just means that 1 resp. 3 spare blocks are in use. As long as this number is below 0x1F your drive will be useable.

[mikerofone]

Hi,

I'm bumping this old thread since I also am trying to LLF a 5MB ProFile using BLU, and I'm getting an INIT SPARE TABLE FAILED error after the disk stepped through all sectors after doing the first pass of the LLF. Is it possible that this means that the spares table remains unpopulated?
Before the drive became unhappy, it would do a few seeks to the spare sectors during its self-test towards the end of the test, so I assume that these bad sectors were properly replaced by spares at some time. Now, after these incomplete LLFs, it spends 5-10 seconds on the bad tracks without doing any seeks, before stepping to the next track. It then continues the self-test to completion and the BUSY light becomes solid.

However, the the Lisa doesn't see the drive at all! It hangs for a long time while enumerating boot devices before (without showing any errors) requesting a boot from floppy, and the LOS installer reports not finding any disk after ~10-15sec.
Only if I turn on the Lisa right after turning on the ProFile will the drive respond to Lisa. About 15 seconds after turning on Lisa will the drive do its self-test, and the installer will see the drive. The first time I managed to format the disk and install up to disk 4 before the installer errored out with "cannot write to drive", but after trying the LLF again a couple times I never got that far again. The installer now errors out with the same error immediately when trying to format.

I cannot rule out that might be additional defects on my ProFile besides a loss of its formatting (after the drive turned bad I noticed that its PSU only gave 4.4V on the 5V rail, which I fixed without it making a difference). However, the fact that post-LLF the self-test now steps through the previously-good tracks exactly as before suggests to me that most of the drive is working correctly. The odd behaviour is the lack of seeks-to-spare-location on the bad tracks, and the fact that the drive goes silent after the self-test completes.

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!

What a looong preamble, sorry! I have a few questions:

• Other posters on this thread reported that even with the failure, their drives were working again. Did your drives actually have bad sectors, and did the power-on self-test behavior change in the same way?
• Is there a newer version of BLU than 0.90 which is able to handle bad sectors (if that's the actual problem here), and which can complete the INIT SPARE SECTOR TABLE process?
  I remember reading that BLU was created before the LLF source code was available by mimicing the commands sent from the Apple /// software, and I assume the disk used for that didn't have bad sectors, so that code path could be unimplemented.
  Edit: Maybe I should consider building an ArduinoFile instead, as it also has an LLF operation and seems to be (more?) aware of the possibility of bad sectors.
• Do you know whether an ArduinoFile would give me a better shot at doing a successful LLF on a disk with a few bad sectors?

Thanks a ton for reading all this! If you are still interested in more information, here's some pictures and additional information in a Google Photos album, including a video of the self-test when the disk was still OK: https://photos.app.goo.gl/q8qhYzUUmivfC35P7

Cheers
mikerofone

[patrick]

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.

The diagnotic firmware always reports 0 spares used. To see the correct number you have to use the RW firmware.


If your drive fails during power-up with the stock firmware, you'll have some hardware problem that is not related to the formatting. Try a different Z8 chip (e.g. your piggyback with a RW ROM) and check the ripple on the power supply voltages.

[mikerofone]

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.

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

The diagnotic firmware always reports 0 spares used. To see the correct number you have to use the RW firmware.

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...

qTry a different Z8 chip (e.g. your piggyback with a RW ROM) and check the ripple on the power supply voltages.

That did it! All the flaky and erratic power-up behavior is gone plugging in the 341-0080-B ROM! \o/
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]

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!

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]

While the power up self-test still doesn't do the back-and-forth seeks it's been doing before, (...)

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.

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"?

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.