Write Bits Directly Onto a Hard Drive Platter?

kidcharles writes "I'm working on a project that requires writing bits to a magnetic hard drive platter in a completely controlled fashion. I need to be able to control exactly where 1s and 0s will appear physically on the platter. Normally when data is written to a drive the actual bits that get written are determined by the file system being used, as modified by whatever kind of error handling the drive itself is using (e.g. Reed-Solomon). All of the modern innovations in file systems and error handling are great for reliable and efficient data storage, but they are making my particular task quite daunting. My question for Slashdot: is there a way to get down to the 'bare metal' and write these bits? Any good utilities out there to do this? Obviously a free and open source solution would be preferable, but I'm open to anything at this point."

Comments

Sure

[Jurily]

Just make your own controller chip for the drive.

Re:Sure

[amn108]

Modern drives come with their own on-drive controllers, as far as I know. Chaining another controller on top will not give you any power to override the on-drive controller behavior. If the on-drive controller makes its own decisions on where and how to write data, your custom controller will not be able to override these decisions, I am afraid.

Re:Sure

[TheLink]

But you couldn't control exactly what was written with the Apple II drives.

IIRC the spec was you could not expect to _reliably_ write a bit stream that has more than two zeroes in a row. In practice you could usually get away with three zeroes in a row. You had to do stuff like write sync streams e.g. 11111111001111111100111111110011111111001111111100. Which are basically 5 x 10 bits of 1111111100.

You could control the drive head too. You could even move the head in sub-track increments - e.g. half track. However, tracks have to be at least a full track apart to be reliably read/written.

All these is why I find the submitter's request rather strange. When you get down to the low level details, there is no such thing as exact.

Even if you are writing one bit on the entire platter with a huge magnet :).

So I'm curious on what he's really trying to achieve.

Re:How about

[PaulIsTheName]

They (the bits you write to your typical /dev/sd* device) would still be wrapped up in sectors, the sectors be enhanced with error correction, then encoded (NRZ, Manchester or whatever is appropriate to the magnetic storage) and then written out. What OP wanted is to manipulate the bit that comes out of encoding. Given the usual stack of SCSI-like commands (and not direct access to the write head signal as early HDD controllers had) this does not seem feasible.

Re:You Da Man!!!

[maxwell demon]

Besides the fact that Flash doesn't have a hard disk platter (his problem obviously isn't just to save data), Flash chips also contain internal logic to map out defective blocks, and in addition they remap in order to avoid writing single blocks too often in order to prevent them from failing early. So even if the HDD platter isn't really needed, he won't get exact control on Flash either.

If you had at least suggested a floppy. There you can indeed control exactly where your bits go, and it's even a magnetic medium.

Solution:

[VulpesFoxnik]

Old MFM hard drive should do the work. The entire device was controlled via software in dos. I have one lying around. A whopping 5 MB!

http://en.wikipedia.org/wiki/Modified_Frequency_Modulation

Now all you need is a 8 bit ISA slot and you are set.

You can't do it.

[PhunkySchtuff]

It can not be done with off-the shelf equipment and software for many reasons, some of which are:
Line Codes
Error Correcting Codes
PRML
SMART
LBA
etc.

Re:Talk to Steve Gibson author of Spinrite

[Joce640k]

No it doesn't.

If I read it correctly (it was a couple of years ago) all Spinrite does is move the head to different tracks before trying to read the data. The theory is that a seek from different distances might align the drive head slightly differently to the data.

As far as I know there's no way to position drive heads directly via IDE/SATA, much less write individual bits. IDE/SATA are high level protocols, all the low-level logic is inside the drive controller.

8-bit ST412/506 MFM + Linux circa 1994-5

[aussersterne]

Get yourself an old, totally unintelligent S412/506 MFM controller from out of an IBM PC or PC/XT. These were fairly dumb devices (g=c800:5 in debug, anyone?) for which you were meant to enter a "bad sectors list" printed on the front of the drive after performing the low-level format yourself. The earlier the drive, the closer to bare metal, so you might want to look for any of the 2, 5, or 10MB (yes, MB) full-height (2 x 5.25" drive bays stacked on top of one another) drives that were floating around then. You'll also want to get yourself a set of ribbon cables.

You should be able to use a drive/controller combination like this with any machine with ISA bus slots up through about the 386/486 era, and that would let you also go back and grab an early Linux distro (say, kernel 1.2.13 days, like Slackware 3 or so) that included drivers for such a controller that were actually in use and known to work at the time, giving you a base on which to build more code.

If 10MB is too small, you might just have luck going up to the largest of the MFM (80MB) or even RLL drives (160-200MB, just get an RLL controller instead) drives. I don't remember whether there were any ESDI drives back in the day that didn't remap their own sectors, but if there were, these controllers were 16-bit ISA and somewhat smarter (also with Linux drivers from the period available) and went up to 680MB or so.

But if you're looking for the best chance of success for your purposes and don't need tons of storage, my educated guess would be that the MFM controller out of an IBM 5150 PC plugged into a 5MB ST506 hard drive and connected to a SIMM-based 80386DX mainboard with 8 SIMM slots (for 8MB ram) might be the easiest combo to find and get working in practical terms that has a chance of doing what you want.

Re:Your own Disk controller chipset?

[Anonymous Coward]

I think anything > 120MB may be unsuitable for this purpose, as they are likely to use ZBR, i.e. different sector densities depending on the circumference of the track. I'd also recommend a really old MFM or RLL disk, where the head movement is controlled with one set of wires and the analog signals from the read/write heads use another set of wires. MFM and RLL drives use the ST506 interface, which should be "easy" to control with microcontroller and a little bit of glue logic.

A real (but expensive) solution:

[Hurricane78]

You know how data restoration companies do it?
They take out the spindle with the platters, and put it in their own reading device with its own controller. And with that you can read and write the exact bits (as long as quantum physics allow it). But the head has to be compatible (e.g. perpendicular recording needs entirely different heads).

I bet those devices can be bought, and I bet their controller is actually just software on the computer (for flexibility). I also bet they come with different head configurations.
But they are definitely not going to be cheap.

Hey, at least it is a real solution. :)

Really? Do NONE of us read?

[True Vox]

No less then *7* posts to the SAME XKCD COMIC?!? Christ, bad enough people don't RTFA, at LEAST read the fine comments!

Re:Slashdot trolled

[dotgain]

You have got a lot of catching up to do. Drives just don't work like that any more.

Re:Slashdot trolled

[ElizabethGreene]

Spinrite may "write" 00000000 to a specific location on the disk, but that 00000000 is actually encoded as something else when it is written to the disk to maintain a minimum number of bit transitions. In the Telecom world, B8ZS is commonly used for encoding. AFAIK, the HDD manufacturer's algorithms are proprietary.

It is also worth mentioning that a hard drive head does not read a binary signal from the platter. It reads an analog waveform and converts it to digital via the encoding and ECC algorithms the OP is trying to bypass.

-ellie

Scott Moulton of http://myharddrivedied.com/ is the smartest HDD guy I know. If you absolutely have to have a solution, talk to him.

Re:Slashdot trolled

[plover]

The difference between the way you learned hard disks worked long ago and the way we use them now is due to IDE technology. Internally, the drive is still commanding cylinder, head and sector. Externally (to the PC), the interface is very different.

Way back when we used to have the computer telling the drive controller board to operate the physical drive mechanisms, with the controller telling the drive which cylinder, head and sector to retrieve. This was called Cylinder-Head-Sector (CHS) addressing. If you ever worked on an original IBM PC-AT, you might remember having to set the "heads and cylinders" in the BIOS settings. You, the human, had to select from a list in the BIOS how many heads and cylinders the disk drive had. (And the older the PC, the fewer the choices. That meant every drive you could buy already had to be supported in the BIOS, but since there were so few originally, it didn't matter too much. As I recall, the max size drive supported by the original AT BIOS was 33MB, even though the largest drive IBM offered at the time was something like 20MB, if you had all the money.) The protocol was called ST-506, named after the first commercially available 5-1/4" hard drive.

Integrated Drive Electronics (IDE) changed that. The controller board was moved from the PC to the drive itself. So now the controller board was set up by the drive manufacturer to know exactly how many heads and cylinders the drive had. To talk to an IDE drive, ATA was developed as a protocol. The computer would no longer send commands for a specific physical drive geometry, but would instead ask for a "logical block number", and the IDE would do a translation (looking it up in a map) to command the hardware to move to the correct physical cylinder, head and sector to retrieve the data. This is called Logical Block Addressing (LBA).

So unless the original story author knows exactly what drive he's dealing with, and can download the lookup table from the drive, what he's asking for is no longer realistic. Each individual drive has its own unique mapping from LBA to CHS, because each drive maintains its own map of bad sectors. A computer asking for logical block #52 might physically get it from head#0, cylinder#3, sector#21 on one drive, but due to bad block mapping on a different drive it might get it from head#0, cylinder#4, sector#35.

SCSI works on a similar principle, and Serial ATA has made further improvements on the scheme for performance and size changes. But all modern drive interfaces use some form of logical block addressing to access the data, and none use direct cylinder-head-sector addressing.