Low-level Floppy Wipe

[Jubbens]

Actually no it isn't.

"A 1.44 MB floppy disk takes its name from the fact that the disk has 2,880 sectors, and each sector is 0.5 KB; 0.5 times 2,880 is 1,440, so the 1.44 is a decimal measure. But, each sector is really 512 bytes, so the 0.5 KB is a binary measure. As a result the "1.44" is a mixed measurement; the true raw formatted capacity is either 1.41 MB (binary) or 1.47 MB (decimal), and not 1.44 MB at all!"

http://www.pcguide.com/ref/fdd/formatCapacity-c.html

[smiddy]

What you're talking about with 1.44MB isn't low level formating. Low Level Formating would ential writing information to every portion of the disk. With the format scheme you're suggesting here (1.44MB) the gaps between each sector would not get over written with anything other than sector information of the same vien. So, in order to really change the low level data on the disk you have to monkey around with the number of sectors per track, as I suggested above, make one sector per track, write all zeros, write all one, then reformat it back to the number of sectors per track that your OS requires, assume DOS FAT-12, 1.44MB disk. BTW, you can change the gap widths between sectors so that you can have more or less sectors per track(increase or decrease sector size), you can also interleave them differently so that you can speed up seeks, reads, and writes and increase the FAT 12 capacity beyond the standard format.

[Candy]

A 1 tesla magnet is quite powerful and should be enough to float a frog. The strongest one in the world a few years ago was 14 tesla or something like that.

You might try thermite for destruction of disks. Note that you need to make the fields on a disk change polarity to do anything effectively, plus you need a fairly strong (not big, strong) magnet.

Still, I think you just wanted a bunch of zeroes written. Just use winhex or dd or something similar.

[Brendan]

Hi,

In no way could "1.44 is a decimal measure" be considered correct, unless you're a salesperson.

A "1.44 MB" floppy disk is 1.44 * 1024 *1000 bytes, which is a combination of both common practice and SI units respectively. This results in 1440 KB or 1.40625 MB (common practice), or 1474.56 K bytes or 1.47456 M bytes (SI units). Because we're all programmers I favour common practice (1024 bytes per KB), which makes 1440 KB the tidiest way to express it accurately IMHO.

IIRC the original term for the disks themselves was something like "High Density Double Sided", as different systems could format them in different ways. For example, a Commodore 64's disk drive typically stored more data on the longer outer tracks than on the shorter inner tracks, and therefore it's disk format had no resemblance to the less efficient "constant number of sectors per track" formats we know today. IMHO this less efficient method is used as it doesn't require as much control over the frequency that data is read/written to to disk drive's heads (i.e it's used as it makes floppy drives cheaper to manufacture). The disk drives used by Commodore 64's were "intelligent", where the disk drive had it's own CPU and handled the file system and disk control by itself.

BTW, you can change the gap widths between sectors so that you can have more or less sectors per track(increase or decrease sector size), you can also interleave them differently so that you can speed up seeks, reads, and writes and increase the FAT 12 capacity beyond the standard format.

Indeed. The previous version of my OS worked well with 1680 KB floppies (with 512 byte sectors, reduced gap lengths and 21 sectors per track). I have a theory that by using 1024 byte sectors it may be possible to squeeze in 11 sectors per track (as the number of inter-sector gaps and sector address headers would be reduced). This would result in 1760 KB floppies, but I haven't attempted it yet.

I have tried 22 sectors (with 512 bytes per sector) and that doesn't work (the last sector overwrites the beginning of the first). Another idea I considered was to use the largest sector size possible for the first sector, and then squeeze in as many smaller sectors as possible after this. For example, an 8 Kb sector followed by a 4 KB sector and then a 512 byte sector *might* actually fit in a track, resulting in 2000 KB floppies. My previous floppy disk driver wasn't quite this flexible though...

BTW for complete data destruction, using a cheap cigarette lighter on the disk media is quite effective (and much easier to obtain than thermite ).


Cheers,

Brendan

[smiddy]

OK, since this thread has digressed into several different, but relavent directions; I have a question:

Has anyone used, seen, or tried working floppy disks to format them like a vinyl record? Is it possible? I suspect not since the heads move in a dithered fashion, stepping to each track.

Theories? New thread?

[Solar]

I have a theory that by using 1024 byte sectors it may be possible to squeeze in 11 sectors per track (as the number of inter-sector gaps and sector address headers would be reduced). This would result in 1760 KB floppies, but I haven't attempted it yet.

Which indeed is the capacity of a 3,5" HD floppy formatted on an Amiga computer. (The Amiga read / wrote complete tracks at a time.)

[Brendan]

Hi,

Has anyone used, seen, or tried working floppy disks to format them like a vinyl record? Is it possible? I suspect not since the heads move in a dithered fashion, stepping to each track.

It's totally impossible - there's no way to control the position of the head this accurately (there's only 80 positions it can be, corresponding to the 80 tracks). For vinyl (and CD-ROMs) the spiralling data also makes seeking to a specific position much more complex.

I have a theory that by using 1024 byte sectors it may be possible to squeeze in 11 sectors per track (as the number of inter-sector gaps and sector address headers would be reduced). This would result in 1760 KB floppies, but I haven't attempted it yet.

Which indeed is the capacity of a 3,5" HD floppy formatted on an Amiga computer. (The Amiga read / wrote complete tracks at a time.)

I'd assume this is just coincidence as I'd expect the Amiga would use a single sector per track (possibly with variable sized sectors transfered at varying frequencies).

I'd probably use something like a 16 KB sector at 560 Kb/s for the outer track and drop down to a 12 KB sector at 512 Kb/s for the inner track if I were a hardware manufacturer. But then I'd build a 2.5 MB cache into the floppy drive too so that the entire media can be read into the cache when it's inserted, and have 160 read/write heads instead of 2 moving back and forth (much faster and much less mechanical stuff that wears out).


Cheers,

Brendan

[smiddy]

It's totally impossible - there's no way to control the position of the head this accurately (there's only 80 positions it can be, corresponding to the 80 tracks). For vinyl (and CD-ROMs) the spiralling data also makes seeking to a specific position much more complex.

I figured as much, thanks for confirming.

But then I'd build a 2.5 MB cache into the floppy drive too so that the entire media can be read into the cache when it's inserted, and have 160 read/write heads instead of 2 moving back and forth (much faster and much less mechanical stuff that wears out).

Purhaps two heads running the length of the radius that reads 80 (or more) tracks simulataniously into a cache. The problem would be producing it at the same price point as a current 3.5 in. drive. Then again, secure cards are really tiny and could be used as the new-floppy...though I don't know their price point. Floppy drives are around $20.

[srg]

There is actually a program for Windows 9x that can format 1.7MB floppies, Alkonost MaxFormat. The disks only work on Win9x.

1.72M (Windows 95/98/Me)
--------------------------------------
Non-Standard; Type: 3.5 Inch.
82 Tracks; 21 Sectors/Track;
1 Sector/Cluster;
224 Root directory entries;
3,444 Total sectors on disk;
1,745,408 Bytes available for files.

BTW The Amiga's floppy drive is very versatile, probably because nearly everything is done in software, including MFM encoding/decoding.

srg