I have recently fixed an old IBM Clone, which has an MFM hard drive. The PC booted up fine, but then I saw, that a few years back, I have deleted a few important files (probably by mistake). The computer runs DOS 3.2, so there is no 'UNDELETE' command. I think I should just image the drive, and then mount the image on my main computer, and recover the files this way. The only problem is, that I cannot write any files onto the drive of this machine, as it would likely damage the deleted files, so I need to be working off of a 360K floppy. I think I need to write a program that would just read the disk in segments and send them over to my new computer with RS-232. I have written multiple x86 ASM applications for DOS, but I cannot find an interrupt function that would allow me to read the drive, and not just the file. I know of the 13h interrupt, which would allow me to read raw data off of the drive, but I don't know how to get the parameters in order to call this function(sector, cylinder, head, drive).
-
2This is a "linux" for 8086 but I don't know if it's very simple to use. elks.sourceforge.net/introduction.html– Sir Jo BlackMar 15, 2020 at 10:52
-
2Int 25h (absolute disk read) may be easier to use.– ninjaljMar 15, 2020 at 10:57
-
1Thank you very much for your help, I'll search for additional documentation about INT 21H and INT 25H– XyzMar 15, 2020 at 11:52
-
3I feel like you might be going about this the "hard way". Why not use an appropriate DOS utility on a boot floppy to both recover your files and back them up on floppies?– Brian HMar 15, 2020 at 13:23
-
2@JohnEye As pointed out by SirJoBlack, there exists a linux version for such computers - ELKS, but even though I managed to compile it, it couldn't auto-detect the parameters of my HDD and the floppy drive, and it didn't allow me to enter them manually, so I gave PC Tools 1.0 a shot, and it worked like a charm!– XyzMar 16, 2020 at 14:18
4 Answers
You seem to be proposing a custom HDD "driver" that would image the HDD block-by-block by sending those blocks across a serial port to some sort of process running on your modern computer that assembles the blocks into an image file. This could be error prone and time consuming to implement.
An alternative suggestion is to use a legacy DOS Utility, such as PC Tools 1.x, that includes an Undelete utility. If you can just image a floppy with PC Tools, or similar utility, then you can boot from the floppy and try to recover your files in the same way you would have "back in the day".
You also state that you have 25MiB of potentially recoverable files. Once you have successfully restored them on your HDD, you then have lots of options to copy them, file-by-file, over the serial port to a modern computer. Again, legacy DOS utilities can do the trick, just as was done "back in the day" to move files between PCs with a null-modem cable.
-
Keep in mind that some Undelete software may undelete a file by copying it, which may cause other files to become unable to be undeleted. The first step absolutely should be to back up the drive, by getting an image, even if that doesn't involve using DOS. Use a Linux-based solution if needed (maybe Clonezilla). If the computer is using (E)IDE (I'm guessing not newer), you could move the drive to a newer computer, or use a USB-based-drive-reading-solution if needed to help get that "forensic"/bit-for-bit image so that undeleting can then be possible.– TOOGAMMar 16, 2020 at 14:50
-
@TOOGAM It's good advice, but as I understood the OP, they are dealing with an early ST-506 HDD and controller on an ISA bus. None of that is readily movable to a modern computer.– Brian HMar 16, 2020 at 15:45
-
@TOOGAM undelete programs for DOS work by restoring a byte in the directory entry, that’s all; they don’t copy the data. Mar 16, 2020 at 20:58
-
@StephenKitt I am absolutely positively confident that is not true of all Undelete/Unerase software. Perhaps it could be that easy. Perhaps it is done that easily with some software. Perhaps undeleting data that easy is the simple and logical and straightforward and sensible approach. But that is NOT how all the software does things, so one must be careful in order to not cause any further avoidable data loss.– TOOGAMMar 18, 2020 at 3:49
-
@TOOGAM DOS undelete software works by restoring the first character of the file’s name (which is replaced with 0xE5 on deletion). The allocated cluster chain doesn’t change; if the required clusters are free, the file can be restored, otherwise it can’t. On systems such as the OP’s, with no undelete helpers, there’s no copying involved, nor is there any point in copying. I agree it’s always better to image a drive before attempting to recover it, but in these circumstances, the issue just doesn’t come up. Mar 18, 2020 at 9:57
I'm actually attempting to do this right now, so I figured I'd add what I found so far.
Looks like one attempt to do this was https://github.com/tschak909/disk-xfer. It supports a Xmodem-style CRC16 on each sector, but it doesn't appear to support working around bad sectors like ddrescue does. It also doesn't have much of a user interface on the DOS side, and it uses INT 14H for serial I/O, which is probably not that fast (although a FOSSIL driver seems to fix this). Since I'm pretty sure my ancient hard drive has at least one bad sector, I won't be able to use this as-is.
Another person posted an account of using the XD driver (that was removed in Linux 3.9-rc1) to image the drive directly on a Linux machine that has an ISA slot. Doing some more digging, I found one more person working on some bug fixes for that driver right before it got purged, so these fixes might need to be applied. He was able to create an image that could boot off of floppies, but slightly more modern machines should be able to boot directly off a CD or DVD.
I'm going to attempt to do the serial port approach first (since I don't want to move that drive any more than I need to), then I might give the Linux approach a try.
I actually wrote a program a while back to image a hard drive in DOS and send the result over serial. However, It uses "new" extended BIOS methods based on LBA adresses rather than traditional C/H/S sectors, so I doubt it will work with an MFM-era machine.
https://github.com/trevorg16/serial-hd-img
The data is sent using run length encoding on 0s to speed up the process a bit, so you need to run the received data through the expand.c program.
-
Welcome on the RC SE! It looks to me as a unix source code, not as a DOS one, maybe I see it badly?– peterhMay 19, 2020 at 8:04
-
The dos program is in the .s assembly file, then you can run the companion program to receive and decompress the image on linux, connected with a null modem serial cable. May 20, 2020 at 4:00
I know of the 13h interrupt, which would allow me to read raw data off of the drive, but I don't know how to get the parameters in order to call this function(sector, cylinder, head, drive).
INT 13h is actually a set of routines; which one is called is determined by AH. (That list on Wikipedia covers various extensions as well, you won't have all of those on older machines. This list covers what's available from the ROM BIOS on early PCs.)
You can get the C/H/S parameters for the drive using AH=08h: Read Drive Parameters. (More details here.) That will give you the parameters you need to use [AH=02h: Read Sectors from Drive] to read what you need.
You can also determine the parameters by calling AH=02h with increasing sector, head and cylinder numbers until you get an error, and then checking error code (with AH=01h: Get Status of Last Drive Operation) to confirm it was something indicating a bad parameter for cylinder/track or sector. You may need to do this anyway if AH=08h returned the wrong parameters; IIRC the parameters were set "manually" and not read from the drive.
