I have a local buddy who has a dying 30M hard drive on some kind of Atari which he says is in a rather big box (for an Atari). It is MFM and he wants me to sell him one of my extra PC MFM drives if we can figure out how to make it work. Anybody know how to go about that? Also I have an Atari 540ST, and I suppose I might like to use a HD with that, if it's not too hard or expensive. Anybody know where I can get a controller for it cheap? Below is my email to the guy attempting to explain why it might need to be low-level formatted. I'd welcome any comments on any of that as well, or we could even get into a discussion about various FS architectures if there are any experts here on that.... As I understand it, low-level formatting means it writes the timing marks. MFM drives usually use one side of one platter just for these marks that tell the electronics where the heads are at, at any given point. So by rewriting these marks, you can change the "architecture" of the drive, specifically, how many sectors per track. I was told that each brand of hd controller does its own style of formatting, but I'm not really sure what the differences are, just that the chances are very good that when you move a drive from one machine to another, the hd controller won't be able to use the formatting on the drive as-is. By contrast, IDE (Integrated Drive Electronics) puts all the proprietary stuff on the drive itself, and the data going over the cable to the drive conforms to the standard. So you usually can't low-level format an IDE drive (and attempting to do so with one of those 286 BIOS's that can do that has been known to render IDE drives unusable), but some manufacturers will provide the software to do it. Usually it's done at the factory and never needs to be done again. On a PC, if you need to low-level format an MFM drive there are several options. Starting with the original XT controller, IBM set the standard that BIOS code for doing that formatting would always start at a particular address. So, you could use DOS's debug utility to simply execute the code starting at that ROM address, and it would prompt you for the parameters of the drive (number of tracks, number of heads, sectors per track, etc.) and then do the format. But AT clone BIOS's typically had a nice menu-driven program accessible from the "CMOS setup" routine to make this easier. So I can only assume that Atari's have a similar capability, either in the HD controller ROM, or the main BIOS, or some program that you have to run. You can check to see if your HDX makes that distinction; chances are if it doesn't, it's only doing the high-level formatting. (They would have no doubt preferred that you buy your HD pre-low-level-formatted from them, anyway.) Or, maybe the Atari uses a common PC-style controller chip, in which case if the drive was formatted on a PC with that same controller chip, I imagine it would work on the Atari as well. High-level formatting simply means constructing the filesystem. Given a reliable set of tracks with certain-sized sectors, how do we organize them into clusters, and then how do we put a file onto the disk, and keep track of where it is located. I believe on both DOS and Unix file systems, files are linked lists; the filesystem code can find out on what track and sector the file starts, and it can then read the first block, but the last few bytes of the first block are a "pointer" saying where to continue reading next. But with Unix filesystems, the information about where to start reading a file is distributed, whereas a FAT filesystem puts all the information about all the files on the first few tracks (the File Allocation Table). The FAT is a list of files, names, sizes, permissions, etc. along with where each file starts - sort of a flat database. The reason FAT formatting has limits as to how much data can be stored, is that you can run out of room to create more entries, so it won't matter whether or not you can write more data, because you can't index it, therefore can't find it later on. But I don't know as much about Unix filesystems, and nothing at all about Atari's. It's also optional, don't you think? -- _______ KB7PWD @ KC7Y.AZ.US.NOAM ecloud(a)goodnet.com (_ | |_) Shawn T. Rutledge on the web: http://www.goodnet.com/~ecloud __) | | \__________________________________________________________________ * Khoros * emusic * electronics * Gravis Ultrasound * X window * Java *