PDA

View Full Version : Low Level formatting an RLL Disk



NeXT
November 3rd, 2013, 08:32 PM
Normally when I Low-Level Format an MFM drive I hang it off one of my controllers that lets me invoke from the ROM using debug and I'm all set to go. I have a Miniscribe that has repeated issues reading back data I've written and I'm curious if a LLF will do it any good.
I've never done an RLL disk before so is there any additional steps I must take or are there any particular controllers I need to use? If it helps, its a Miniscribe 8438 and no, I don't have anything else to replace it with and I don't particularly want to use the drive at all.

http://i11.photobucket.com/albums/a166/ballsandy/Computer%20related/CGS_0408.jpg

Chuck(G)
November 3rd, 2013, 08:51 PM
Depends somewhat on your controller, but usually there's not a lot of difference when doing an LLF of an MFM or one of an RLL drive. Some controllers will let you format to, say, 25 sectors per track instead of 26, and give you a drive with 25 good sectors per track instead of one with 26 and flaws. Some controllers ask that you explicitly enter the drive geometry.

Stone
November 4th, 2013, 02:43 AM
SpinRite comes to mind and so does SpeedStor.

SomeGuy
November 4th, 2013, 06:08 AM
If the drive is already formatted and DOS partitioned, I would just throw Spinrite at it. On MFM and RLL controllers, Spinrite will automatically perform a low-level format while preserving any data. Also, the problems you describe sound like you may have some "weak" sectors (the kind that look fine and dandy until you actually NEED them :D ). If the low-level format doesn't fix those, SpinRite's extensive pattern testing will detect them and mark the sectors as bad for you. As a bonus it will check drives optimal sector interleave and correct it if needed.

NeXT
November 4th, 2013, 07:27 AM
SpinRite comes to mind and so does SpeedStor.

I don't have local copies of either. I can't ever seem to find the older versions.
At this point I don't care about the integrity of the drive for the format. I just want to get it formatted in the best possible conditions.

Stone
November 4th, 2013, 07:41 AM
If you want, I'll send you the location of SpinRite II v2.0.

fatwizard
November 4th, 2013, 10:52 AM
If you aren't interested in what is currently on the drive, then I recommend a low level format from the controller. Spinrite is a very useful tool, but it takes forever and you only need it if you want to preserve the drives contents. If you can access the controller's LLF routines (say though debug), format the drive with 615 Cyl. ,4 heads, and 26 sectors per track. Maybe do it a couple of times for good measure (I have found this to be useful).

Chuck(G)
November 4th, 2013, 11:22 AM
Some WD controllers place the drive geometry on a hidden (sector 0) short (256 bytes) sector on the first track, then read it up at boot and plug the values into the BIOS area. Spinrite isn't going to do this for you, I suspect.

Stone
November 4th, 2013, 11:36 AM
SpinRite doesn't alter () any data -- it just refreshes the format.

Chuck(G)
November 4th, 2013, 01:31 PM
If Spinrite doesn't know that the controller expects a short sector with an oddball number, it won't know to look for it.

In fact, it's quite possible to hide data from Spinrite on an MFM/RLL hard disk.

SomeGuy
November 4th, 2013, 03:42 PM
Ok then perhaps a BIOS LLF followed by spinrite to weed out any weak sectors. And yes it does take a while. I would expect to leave it running overnight.

Exactly what controller card do you have?

Stone
November 4th, 2013, 04:14 PM
In fact, it's quite possible to hide data from Spinrite on an MFM/RLL hard disk.Talking about SpinRite and data in the same context is apples and oranges. SpinRite is *not* about data -- it's about the LLF. By design SpinRite ignores all the data. Additionally, SpinRite formats the partitions one at a time and not the drive as a whole. It doesn't format the boot sector and requires that track zero and the boot sector not be corrupt. So it essentially doesn't interact with the first track any differently than any other program. If a partition is not properly defined and accessable SpinRite will not run. So, yes, it is unaware of anything 'oddball' on the first track as that is outside its sphere of operation and not relevant.

Chuck(G)
November 4th, 2013, 06:11 PM
If you're going to perform a low-level format without losing data, it works this way:

1. Read up what you can from the existing track; save the data somewhere safe.
2. Low-level format the track. This involves overwriting everything on the track and, in particular, presenting the controller with the track layout. The process writes all bytes from index to index--i.e., it overwrites everything.
3. Write the data obtained in (1) back to the newly formatted track.

My point is that if SR is unaware that any track contains oddball (i.e. geometry-containing special sectors) sectors, they and their accompanying format will be lost in the process.

Stone
November 4th, 2013, 06:25 PM
My point is that if SR is unaware that any track contains oddball (i.e. geometry-containing special sectors) sectors, they and their accompanying format will be lost in the process.Yes, but the track that contains this is not one that SpinRite has access to. It does not do track zero. It can only format a partition and the boot sector is not in a partition.

Chuck(G)
November 4th, 2013, 09:39 PM
If you're going to low-level format a disk, why skip track 0? That makes absolutely no sense at all.

Are you certain that the format is low-level? (You can't LLF almost all IDE drives, FWIW). i.e., does it really rewrite address and data headers and gaps?

Agent Orange
November 4th, 2013, 10:45 PM
FWIW some say that they have been able to recover track 0 with this: http://www.piotrkn22.republika.pl/drev/

P.S. Don't know what the heck I'm doing up at 2:40 AM EST even thinking about track 0. Could be that the Bears slapping the Packers around last night has me unable to sleep knowing that the Lions have the Bears on Sunday.

Chuck(G)
November 5th, 2013, 07:59 AM
I think the track 0 recovery utility (and the explanation) is mostly horse manure. There is a very little on a low-level control that one can squeeze through an ATA interface.

My point with Spinrite "low level" formatting a partition is that there's no good mechanism, AFAIK, to force many drives (including ATA) to perform a low-level format. Indeed, modern (since about 1990) drives also hide the true geometry of the drive from programs. You really don't think that every ATA drive has 63 sectors/track or even 255 heads, do you? In most cases, you don't even know if a "logical" partition begins on a real physical cylinder--and that's what's required for LLF--physical tracks are overwritten.

I do think the world of Steve Gibson, but if he's claiming LLF on ATA drives, he's got some 'splainin to do...

Trixter
November 5th, 2013, 08:09 AM
If you're going to low-level format a disk, why skip track 0? That makes absolutely no sense at all.

Are you certain that the format is low-level? (You can't LLF almost all IDE drives, FWIW). i.e., does it really rewrite address and data headers and gaps?

I do think the world of Steve Gibson, but if he's claiming LLF on ATA drives, he's got some 'splainin to do...


SpinRite is about 20% useful utility and 80% snake oil. On supported controllers (MFM, RLL, some SCSI) it does indeed issue a low-level format command to the controller; versions 5 and earlier will do this. Version 6 and later is IDE only and cannot perform a LLF.

Versions 5 and earlier require a proper partition table and one or more FAT filesystems because it tries to do intelligent things like find partially bad sectors and move files out of the way, and Stone is correct in that it doesn't touch track 0 if it finds a proper partition table. For version 6, if it doesn't find a proper partition table, it will go ahead and operate on the entire drive without any relocation features.

I stopped trusting SpinRite when I stopped trusting Gibson. I had an issue trying to get 5.0 running on an old system with any DOS version other than 6.22, where it would hang during the memory pattern testing on startup because it was trying to read/write segment F000:0000. I contacted support (I'm a paid customer) and Steve himself wrote me something along the lines of "I don't know what's happening, we just request memory segments from DOS". Sorry, wrong answer: DOS would never return F000 as a valid segment in request to a memory call, and furthermore you can see the program testing segments at 5000:0000, 6000:0000, and 6809:0000 every time it runs. So no, Steve, you're not asking DOS for memory, you're just grabbing whatever you want.

I still run SpinRite on vintage systems where I'd like to change the LLF interleave and I'm too lazy to back up and restore the data, but that's about it, and only on systems where the data is not unique or important.

fatwizard
November 5th, 2013, 03:30 PM
The info in this thread about Spinrite is very interesting. I have used the program quite a bit. I like many of the features and it has always done a good job at surface analysis for me.

I thought that all of the 8bit MFM/RLL hard drive controllers wrote drive info on track zero to be read back at boot since there is no CMOS memory to store this data in before the AT.

My experience with MFM drives is that a low level format from the controller is the most effective. I've had older ATA drives that I suspected a fresh low level format would do them good, but it just isn't possible for those drives outside of the factory.

modem7
November 5th, 2013, 10:05 PM
I thought that all of the 8bit MFM/RLL hard drive controllers wrote drive info on track zero to be read back at boot since there is no CMOS memory to store this data in before the AT.
No. The categories for XT-class controllers are:
* One fixed geometry only (e.g. the early (http://www.minuszerodegrees.net/ibm_xebec/ibm_xebec.htm#variation_1)versions of the controller supplied in the IBM XT)
* Multiple geometry - geometry selected by switches or jumpers (e.g. the later (http://www.minuszerodegrees.net/ibm_xebec/ibm_xebec.htm#variation_3)version of the controller supplied in the IBM XT)
* Multiple geometry - LLF code on controller asks for geometry to be entered - that geometry stored in non-volatile memory on the controller
* Multiple geometry - LLF code on controller asks for geometry to be entered - that geometry stored on a reserved track on the hard drive

fatwizard
November 5th, 2013, 11:43 PM
Oops. Actually I am aware of the hardwire/jumpered types, I was thinking about controllers the little Miniscribe in this thread would be paired with and went vague in my response. What I didn't know is that there were "ask for geometry" controllers that utilized non volatile memory.

NeXT
November 6th, 2013, 11:37 PM
After hassling with a bad keyboard I got the drive formatted and while I now know it has a healthy format, as predicted the Miniscribe is still a piece of junk and there's 7mb of space that's *gone*.