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.

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.

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

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.