Slashdot Mirror
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."
It works for me. http://www.staples.com/Staples-Dry-Erase-Markers-Chisel-Tip-Black-4-Pack/product_607101?cmArea=FEATURED:SC1:CG11:DP1101 Now that someone has said it no one else can be a smart ass and they have to be informative.
Just make your own controller chip for the drive.
You would need to replace the firmware inside the drive or use an undocumented manufacturer mode. Whatever they use to write the servo tracks would be interesting to you. You will be in the situation of the firmware writer: There will be problems all the way. Be prepared to find a way to position the heads (ever tried to find a servo track?). Most likely you also need to at least parametrize the amplifiers in the DSP part of the firmware that does the analog-to-something-to-digital so you can have direct influence on the "bits". Good luck
The submitter appears to know enough about what he's asking to know that it's also impossible / completely impractical. Recording ones and zeros directly isn't done for a reason, submitter appears to understand this.
Your requirements are wrong, sorry.
Yes, I don't what they are. Still wrong.
I can't help directly, but can give one important advice - careful how you distribute the bits! If too many ones get on the same side of the platter this will destabilize it, causing it to wobble due to the weight difference ( a one weighs quite a bit more than a zero, you know!) and potentially tearing the platter in two!
This kind of copy protection has been outdated for quite some while and should have died with floppy disks ...
These kinds of questions are stupid: "I need to do XYZ for a project, how do I do XYZ?", where XYZ is one or more of complicated, ridiculous, vague, nonsensical, etc. Try telling us what your project is, and then we might be able to suggest a useful solution, possibly not involving XYZ at all, or involving a very particular/practical version of XYZ.
I'm actually more interested in why the fuck he wants to do this, much less how it would be achieved.
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.
RES PUBLICA NON DOMINETUR
The cynic in me wonders if he is working for some hack start-up company trying to develop a DRM scheme for a hard drive, similar to the crap the studios do to DVD's to make them difficult to rip. Typically this involves creating some sort of currupt/invalid area on the disk that your particular device will know to ignore, but will lock up anyone else trying to read the data off the drive.
The optimist in me wonders if he is trying to defeat such a scheme.
We don't need to work like that any more.
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.
STOP . AMERICA . NOW
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.
And if he's trying to see if he can read data patterns off platters by hand from a dismantled drive, and needs a known test pattern to calibrate his equipment with?
I'm working on a project that requires writing protons to an atom nucleus in a completely controlled fashion. I need to be able to control exactly where protons will appear physically on the nucleus. Normally when atoms are created during fusion the actual atoms that get created are determined by the energy input of the fusion reaction as modified by whatever kind of atoms are being fused (e.g. hydrogen into helium). All of the modern innovations in nucleosynthesis and alchemy are great for particle colliders and crackpots from the Middle Ages, 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 transmute lead into gold in a cost-effective manner? 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.
Finally had enough. Come see us over at https://soylentnews.org/
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. :)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
"I'm working on a project that requires writing bits to a magnetic hard drive platter in a completely controlled fashion."
Are you sure?
The reason I ask is I'm working on a project that requires me to move data faster than light. At least that's what I spent last Monday working up the math to prove that data replication between our different data centers has an upper bound enforced by the fabric of the universe and that it was impossible for me to achieve the project's stated goals without essentially inventing warp drive. As it turns out after a meeting it was determined that the goal was just a stated guideline. It also turns out the price of faster data transfer rates is prohibitive and after a further meeting the stated project goal was total baloney. Yes. Baloney. We had sandwiches. It was a nice meeting.
[signature]
Don't you hate it when people refuse to accept the premise of a technical question and write long monologues why the submitter is working with false assumptions even though they don't know what exactly they are dealing with? Yeah, me too. Makes them look arrogant, ignorant and smug. I'm going to go ahead though and reject the submitter's premise: there is no chance in hell that you're on the right track with whatever project you're attempting to do. But instead of merely dissing you for incompetence, I'll lay out a few scenarios (might as well, since you didn't supply any of your own).
If the actual physical bits matter to you...
you're either a hard drive manufacturer or a clueless person who should read up on how drives actually work. And we both know you're not working for a manufacturer. What you need to know is that there are several layers of indirection between the write call from within an OS down to the actual magnetic platter. These layers are there for a reason. At the very least, the onboard controller of the drive abstracts away the physical block allocation, and the drive won't work without the controller at all. Since the intricacies of the drive's physical address space are not accessible from the outside, there will never never never be a reason to try and fiddle with it directly. Because you can't.
If you are looking for disk I/O without a filesystem...
we're finally in saner territory. There are valid reasons to do this, e.g. speed and overhead considerations. Some database vendors actually have features like these. In this scenario, you're using the entire drive as one big addressable blob. A good starting point would be to have a look at the source code of a simple filesystem, such as ext2. Strip away all the actual file handling stuff and learn what you can from the disk I/O routines. On the other hand, if you didn't arrive at this conclusion yourself, that's not a very encouraging sign.
If you simply want a drive without error correction...
you're not developing software that will run on any modern system. If you accept this caveat, you can buy an ancient drive off ebay and use that. However, keep the first scenario firmly in mind: there is simply no reason to control the exact placement of every single byte if you don't plan on literally putting the drive under a microscope afterwards. Otherwise, this has no practical implications and, again, you are on the wrong track.
If you're a DRM/malware/virus developer...
I will sleep very comfortably tonight, because you had to ask about this on Slashdot, signaling once more that you're doing it wrong.