I have an old XT clone which is fitted with a Seagate ST-238R RLL hard disk and an ST11R hard disk controller card.

I have recently revived this old machine and it all appears to be working still.

I'm looking for software to allow the contents of the drive to be archived before anything happens. The machine now has a XT_IDE v4 card.

On a newer machine I'd consider using Norton Ghost or Linux to create a sector-by-sector image of the disk.

It currently has MS-DOS 5.0 and I'm able to xcopy the files off.

  • Do you want the files only or really an image (that reflects the entire hard disk including all special file system sectors)? Are you looking for an off-the-shelf tool or do you also consider writing a program yourself or even soldering something? Jan 25, 2019 at 14:43
  • I've made a conventional file backup. What I was after was a full sector by sector image in case there are magic bits that a DOS 5.0 XCOPY isn't going to pick up. It doesn't look like there is a simple tool known to work on an old machine like and XT. I'm considering writing my own using INT13h BIOS calls. Shouldn't be reasonably simple to do. Back in 1989 20MB was a decent sized HDD but it's obviously nothing now with CF adapters.
    – davefiddes
    Jan 27, 2019 at 23:12

3 Answers 3


If you can’t image the disk using another system (and you probably can’t), I would take a two-pronged approach:

  • copy the files to a partition on a disk on your XT-IDE card; first the system files, using SYS, then everything else using XCOPY;
  • image the disk to a file in another partition on a disk on your XT-IDE card, using a disk imaging or editing tool.

I can’t remember off-hand an actual partition imaging tool which will work on an XT, but there is at least one disk editor which can copy tracks or sectors to files, Gregg Jennings’ DISKED. You can find a copy of that here. I recommend experimenting with it in a DOS virtual machine before using it on your XT; take particular care with the various character interpretation modes, you really want a raw copy here.

You might find other useful tools here, but many of them require a 386 or later CPU.


I'm considering writing my own using INT13h BIOS calls. Shouldn't be reasonably simple to do.

I was writing the comment because I had already the same idea.

This is how my code looks like:

# .COM file loaded into address CS:0x100, assuming DS=ES=CS
.intel_syntax noprefix

# Create and open the output file
    mov   ah, 0x3C
    xor   cx, cx
    mov   dx, offset (filename - start + 0x100)
    int   0x21
    jc    error

# The "loop":
# bx = File handle
# ax = cylinder number
# dh = head number
# dl = bios drive
    mov   bx, ax
    mov   ax, [firstcylinder - start + 0x100]
    xor   dh, dh
    mov   dl, [driveno - start + 0x100]

# Read one track
    push  ax
    push  bx
    push  dx
    mov   ch, al
    mov   cl, ah
    ror   cl, 1
    ror   cl, 1
    inc   cl
    mov   bx, 0x400
    mov   ah, 2
    mov   al, [numsectors - start + 0x100]
    int   0x13
    pop   dx
    pop   bx
    pop   ax
    jc    error

# Write the data to the file
    push  ax
    push  bx
    push  dx
    mov   ah, 0x40
    mov   ch, [numsectors - start + 0x100]
    xor   cl, cl
    add   cx, cx
    mov   dx, 0x400
    int   0x21
    pop   dx
    pop   bx
    pop   ax

# Loop: Go to the next head
    inc   dh
    cmp   dh, [numheads - start + 0x100]
    jb    nextLoop

# Loop: Go into the next cylinder
# (And continue at head 0)
    xor   dh, dh
    inc   ax
    cmp   ax, [lastcylinder - start + 0x100]
    jbe   nextLoop

# Close the file and finish
    mov   ah, 0x3E
    int   0x21
    int   0x20

# Error "handling"
    mov   ah, 9
    mov   dx, offset (errorMessage - start + 0x100)
    int   0x21
    int   0x20

    .ascii "An error occurred.$"

# -------- Configuration area ----------

# Replace this by the BIOS drive number
    .byte 0x80

# Replace these two bytes by the first
# cylinder to be copied
    .word 308

# Replace these two bytes by the last
# cylinder to be copied
    .word 614

# Replace this byte by the number of heads
    .byte 4

# Replace this byte by the number of
# sectors per track
    .byte 26

# Replace this by the file name
    .asciz "d:\\hdfile0.bin"

# .org 0x400
# dataBuffer:

The code supports disks with 512 bytes per sector.

I did a quick test in a virtual machine using DOS 5.0. Unfortunately I'm not sure if it works on a real XT; the virtual machine supports new BIOS features and 80486 instructions.

I also did not check if the disk was really copied correctly!!

Because the file size is limited in old DOS versions (I think the drive size is limited to 33 MB!), you can specify a "start cylinder" and an "end cylinder" in the "configuration area". So you can make a copy of the first half and the second half of the hard disk.

The machine now has a XT_IDE v4 card.

Maybe someone not having such a card but having the same problem is reading this:

The code above can be modified to write to a serial cable instead of a file. However using a serial cable is rather slow: At 9600 bauds (XTs don't support "high" baud rates) it would take about 10 hours to transfer the data.

I was also thinking about a solution that works similar to the "X*1541" type cables:

Such cables are used to connect an old Commodore disk drive to the parallel port of a modern computer; however, the same idea can be used to connect some memory with a similar interface (such as an SD card!) to the parallel port of an old computer.

I think this would allow a much higher speed than a serial cable, but require really much programming effort - even when writing to "raw sectors" of the SD card instead of a (FAT) file system.

  • 1
    A LapLink cable might also be worth looking at: the software of the same name used a two-way printer cable to exchange data over a parallel port.
    – TripeHound
    Jan 28, 2019 at 8:34
  • You might want to use the GNU linker's -Ttext=0x100 option so you don't have to adjust offsets manually: stackoverflow.com/questions/31479054/…
    – user722
    Jan 29, 2019 at 23:27
  • @RossRidge Using some versions of the GNU tool chain linking does not work (or it does not work correctly) with 16-bit code. Therefore I normally adjust the offsets manually, check that there are no relocations in the object file and take the .COM file from the object file directly (instead of a linker output). Jan 30, 2019 at 6:36

I'm just wondering aloud because I have never tried it, nor do I know if it even supports it, but assuming that the drive controller card is ISA, what about putting that card and the hard drive into a more modern system, like say a 386 or 486 - new enough that it would support Linux but old enough that you probably would not run into compatibility issues with the controller card. Then, you could use something like ddrescue or clonezilla to image the drive.

That said, with the disk itself being good, and with it appearing that you have an IDE controller in the same system, I would just xcopy the existing disk over to an IDE disk, and then put the IDE drive in a modern system and use a tool like Clonezilla to image it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.