• Please review our updated Terms and Rules here

Raw HDD cloning tool for DOS?

V

Vin Digit

Member
Joined
Jan 12, 2024
Messages
20
I've seen WinImage for DOS posted below but it appears that's more centered around floppies and I don't want to hijack that thread :)

I'm looking to be able to copy byte-for-byte a raw physical MFM disk (I'm using its paired controller) and output the image into a file containing the exact same bytes. I have it set up currently in a Socket 7 machine. I've been testing software in VMs and PCem prior to deployment on the physical system.

I've tried:
  • Norton Ghost
    • It doesn't access the raw drive (see appendix 1)
  • Quarterdeck DiskClone 1
    • It saves it in some silly proprietory format
  • Multiple old versions of GParted Live for i486 systems
    • Stuck at "booting kernel" on the physical system
  • PAUD 2.0.3 with `dd`
    • Drive not recognised
  • "The 'dd' from disc2/gnu/gnuish/gnufut21.zip" in PCem as mentioned by doshea in the WinImage for DOS thread, but indeed it doesn't appear to support HDDs.
  • MHDD
    • Crashes

I'm still looking around for tools but I seem to be coming up short. Does anyone know any particular software that can do what I'm looking to do? I'm not restricted to floppies as my DVD RW (yes DVD lol) is recognised and usable by the system, but not bootable.

Thanks in advance


Appendix 1:
Using a VM I went into Linux and ran `dd if=/dev/urandom of=/dev/sdc` in order to erase the drive. Norton Ghost then unfortunately had the drive greyed out so I'm assuming it isn't actually raw disk access. In PCem with two raw drives it says that there's no drives available to copy.
 
Last edited:
If you have access to a network card and give me the disk geometry, I'll give you code that will image the drive over the network.

You will boot from a floppy, load a packet driver, and then run the program. On the receiving system you'll end up with a raw sector-by-sector image of the BIOS hard disk. And for bonus points, with a little manual work you'll be able to mount the newly created image on the same machine and then do file compares to ensure everything went well.

MFM drives are tricky because you have to use the controller that formatted it, and often newer systems are not happy with old 8 bit MFM controllers. I like my network idea because except for adding a network card, it is mostly non-intrusive. And with a Xircom PE3 adapter really is non-intrusive.

(I've not released the code yet because it's basically equivalent to handing somebody a sharp knife - some training/guidance is required.)
 
That certainly sounds like a possibility! Is there a config file that can be modified to allow the program to work with user-defined disk parameters? I have added a PCI NIC which the BIOS does recognise so that's a start :) I presume I'd have to set up a listener on another machine to receive the data? I've got 256MB SDRAM in the system so could instead store it in a RAM disk and then copy over the network after the image has been made?

Turns out the CPU I'm using is i586 (I'm getting mixed messages from different sources) so I've found an Alpine version (3.19.9) which runs in PCem at least. Ordinarily I'd boot to the DVD drive, but I can't on the physical system and Smart Boot Manager (can boot to CDs from a floppy) gives gibberish and crashes when I select to boot from the CD. I used Plop 5.0.15 instead and it boots to the Alpine CD but the physical system appears to just hang after "boot:".
 
Last edited:
I know you asked for DOS, but you did try some Linux options, so I assume you're not completely opposed to it and will offer another one here:

https://www.seasip.info/VintagePC/xda.html explains how someone did it with Linux and hints about issues with the driver:
On a typical Linux 2.x kernel (prior to 2.6.33), attempting to use the xd driver, either compiled into the kernel or as a loadable module, will fail with the error xd: Out of memory. This is a bug in the xd initialisation code: it tries to allocate memory for a transfer buffer before having worked out how big the buffer should be.


The proper fix was committed in Linux 2.6.33. [...]
Click to expand...
A simple option than what they did (rebuilding the kernel) might be to go with an older distribution that hopefully doesn't have the bug. For example Slackware 2.3.0 which is at least partly on https://archive.org/details/LDR08951 (probably the other CDs in that InfoMagic set are elsewhere on archive.org, but I think you'd only need the floppy images which are on that CD #1) has kernel 1.2.8 which is hopefully not affected. It apparently has that necessary xd driver on this kernel floppy:
xt.gz. This is a boot floppy with IDE and XT hard drive support.
Click to expand...
slakinst/BOOTING says:
Parameter for XT hard disk controller (DTC 5150X):
==================================================

xd=type,irq,iobase,dma
----------------------

related files: drivers/block/xd.c
config: CONFIG_BLK_DEV_XD
Click to expand...
Maybe you need to use that parameter?

I must admit I don't know if all XT hard disk controllers are compatible with DTC 5150X or what, I've never had a pre-IDE HDD myself.

After booting QEMU from the slakinst/boot144/xt floppy image and then swapping to the slakinst/root144/color144 floppy image, I was able to log in and got a shell which had fdisk and dd. I didn't try with any kind of emulated MFM drive though.
 
Oh interesting thanks I wasn't aware of the `xd` kernel module, I'll look for a Linux system with that available.

I've investigated a bit further the crashes I've been having with MHDD and booting Linux, and I think it's due to the Cyrix 6x86L CPU I'm using. I switched the CPU on PCem to an Intel and tried booting MHDD and it booted so I tried booting to both Alpine 3.19.9 and MHDD on a physical Pentium-S system and it worked. The next step is finding a linux system with the `xd` module and finding out whether MHDD supports MFM controllers.
 
Booted into Linux with the Gparted Live (before kernel 3.9 when the `xd` module was removed), however it appears my WDXT-GEN ISA MFM controller is not picked up (`dmesg | grep isa` shows `isapnp` but no sign of the controller). I presume this is the reason for the error "no such device" with `modprobe xd`.

I tried booting to MHDD but it doesn't pick-up the MFM drive, despite the DOS environment from which it's executed being able to access C:\. I think this is because it only supports PCI devices.

This has led me to look further into the DOS route.


SUCCESS: I have successfully imaged the drive and copied the image onto my main computer!

My workflow:
  1. Boot to DOS and set up a 64MB RAM drive in which to store the image (memtest recommended prior to this)
  2. I found a program called DOLLY which uses the 13h interrupt to access drives through the BIOS. This imaged the drive raw format.
  3. I served the RAM drive through the mTCP HTTP server to my main computer
  4. I have the image file on my main PC and am now working on getting the system to boot in emulation

Answer:
DOLLY
 
I've recently had cause to image an IDE disc on a telecoms tester running Windows 95- no USB ports, only boots from A or C. Nowhere to connect a CD-ROM. No onboard LAN (never mind the ability to boot from LAN). Did have a 3.5" 1.44Mb floppy and two PCMCIA slots though.

Got the thing imaged by using a 3C589 PCMCIA card, booting into Slackware 4.0 (using the bare.i and pcmcia.gz boot and root disks).
Configured the network interface, mounted an NFS share on the server, then used dd to dump the partition, as well as the first 20 sectors of the drive to capture the MBR/partition table.
To image the whole disk, just use /dev/hda instead of /dev/hda1
This technique would work with any "legacy" laptop with PCMCIA and a bootable floppy drive.
The "bare.i" disc just does IDE (remember that IDE was just shifting electronics off a 16 bit MFM card onto the hard drive).

The boot and root disk images can be found at https://www.mirrorservice.org/sites/ftp.slackware.com/pub/slackware/slackware-4.0/

The Slackware 3.6 boot.i+pcmcia.gz cards are missing the files needed to mount a NFS share, so Slackware 4.0 appears to be the sweet spot - has the NFS support with standard images, only needs two floppy discs to do the job.

The xt.i boot disc should be capable of handling an 8bit MFM/RLL card.
 
Given the problems with bad sectors on DOS, I would have thought that cloning went against the technology of the era, outside of forensic purposes.

Mostly I just copy onto a ZIP, but I can understand the appeal of creating a logical disk image that an emulator can read.

It would have been far less practical in the DOS era to do such a thing though.

I see Dolly only works on modern DOS machines, ie, 286. 4Mb. Probably twice as large as my biggest DOS system. It would be nice to turn that into something that could be loaded from a floppy and pushed over a serial port or parallel port similar to suck information from really old DOS systems.

But it's nice to know it's there. :) thanks for sharing.
 
No problemo

Yeah I'm not sure how someone would have imaged an IBM 5160 HDD in 1983 for example, outside of removing it and copying it over to another drive with identical or no bad sectors (or indeed sending it over a PC to PC communication channel). At some point nowadays it's easier to just pull the drive and image it in a newer system. Had I more drives I would probably look into a USB MFM controller for use on a modern PC; for everything else post ISA I use a modern PC (e.g. IDE drives, 5.25" floppies).
 
You must log in or register to reply here.
Back
Top