The Central Point Backup Floppy Format

A reader recently asked about the “native” format of Central Point Backup (CP Backup) floppies. Diskettes formatted in this manner are somewhat tricky to work with as they do not use a standard DOS format. A session with Sydex’s AnaDisk helped shed some light on this format. An old (1992) backup on 51⁄4” floppies was used for analysis.

When the DIR command is ran on a CP Backup floppy, a listing of largely zero-length files is shown. If the listing is not sorted (standard DOS behavior), a message spells out that the floppy does not use normal DOS format and needs to be reformatted for DOS use. If the directory listing is sorted (4DOS or similar), the message may prove difficult to decipher.

The above should imply that CP Backup formats floppies in a way that DOS can recognize, but not work with. AnaDisk immediately shows what the “problem” is: The 51⁄4” diskette is formatted with a standard BPB, FATs, and a root directory, but shows that all clusters are bad. What’s worse, the BPB indicates a standard 15 sectors per track (SPT) format, but in reality the diskette is formatted with 16 SPT. This will cause severe confusion to any tool (including DOS itself) which expects the BPB to reflect the true format.

AnaDisk is obviously not thrown off by this. It can dump CP Backup floppies and creates images of size 1,310,720 bytes. That is of course larger than a standard 1,228,800 byte image and explains how CP Backup stores more data per diskette in its native format.

Other tools, such as IBM’s XDFCOPY, fare rather worse than AnaDisk. A standard-size 1.2MB image is produced, which means one sector on each track was not imaged. Norton’s DiskEdit has the same problem and only accesses 15 sectors per track instead of 16. 51⁄4” diskettes are somewhat difficult to use with with recent Windows versions, but the assumption is that Windows would have trouble with this format as well. A quick check with Windows XP and rawwritewin produced an unexpected result—a 1.44MB size image, of unknown integrity.

It is worth noting that CP Backup is not nearly as extreme as XDF or 2M in providing DOS-compatible disk structures. It creates standard-size FATs and root directory, which wastes several sectors. On the other hand, unlike XDF or 2M, CP Backup uses a uniform geometry which has at least some chance of working on non-DOS systems, and can be reasonably represented by a raw image.

No interleaving or sector slipping appears to be used. CP Backup presumably gains its speed primarily from using optimized disk access which efficiently transfers data and does not waste time between disk revolutions.

It should be mentioned that CP Backup can utilize three different modes of floppy access: DOS compatible (slow), medium speed, and high speed. Backups created in high speed mode (which is the default mode of operation) cannot be restored using the ‘compatible’ mode.

To complicate matters, most if not all CP Backup versions (such as those delivered with PC DOS 6.3 or 7.0) have trouble running on fast CPUs in the “native” modes. Which means that users with disks created in high-speed CP Backup mode find themselves in an unpleasant situation—medium/high speed mode doesn’t work, and compatible mode won’t read the disks. More about this problem later.

This entry was posted in DOS, Floppies. Bookmark the permalink.

28 Responses to The Central Point Backup Floppy Format

  1. Darkstar says:

    Interesting article, thank you very much!

    I know that there are some unofficial patches for CPBackup which fixes the crashes on fast CPUs, but you probably know that already 🙂

    Didn’t think that the disk format was so close to the standard…

    -Darkstar

  2. Michal Necasek says:

    The funny thing is that the format could probably be a lot more standard if the BPB specified the actual number of sectors per track. I wonder if Central Point didn’t do that because it didn’t work for some reason, because they didn’t care, or because they didn’t want to.

    I’ve not found any functional patches for CP Backup so far, just numerous complaints that it crashes. It doesn’t look like it should be that hard to patch though. The hard part is finding the run-time error message when it flashes by so fast it’s invisible 🙂

  3. I recall the ‘special’ CP formatted disks would lose data easier than the ‘slow’ MS-DOS formatted version….

    then I switched to tape backups which was great until I did enough upgrades and the tape drive stopped working….

    But that was a long long time ago…!

  4. Michal Necasek says:

    I recently looked at an old backup that I have, eight 5.25″ disks created with the ‘fast’ CP Backup option a bit over 20 years ago. No bad sectors at all…

  5. Must have been bad media, drives, or who knows what… It was all my Pascal & Fortran stuff from college, along with OS/2 1.3 and Xwing…

    I don’t even know why I even remember that much.

  6. Dan S says:

    I just used ‘dd’ to rip 22 5 1/4 floppies i had done backups on with CP backup ages ago (circa 94).. I assume they’re all intact since dd just streams from the floppy device.. (I hope).. Unfortunately, CP backup won’t run under DOS for me, since it can’t ‘run as fast’.. (under Virtualbox) 🙁

  7. Michal Necasek says:

    Whether the images are usable or not depends on how the floppies were formatted... if they used the non-standard 16-sector format then I’d worry that ‘dd’ didn’t capture the 16th sector. Do you know what format was used? And how big are the images?

  8. Dan S says:

    360k floppies. I used the CPbackup disk format. Each file is 368640 bytes.

  9. Dan S says:

    @Michal Welp.. I was able to try using the backup disks (in a round about sort of way).. and cp backup v6 doesn’t fully recognize it as valid (a backup history shows it as a backup, but that doesn’t go as deep)… Ideas on ‘ripping’ the disks then?

  10. Michal Necasek says:

    I don’t have any experience with 360K disks and CP Backup... I do have a functioning 5.25″ drive and probably some DD media I could use, but I have a bad feeling the box is “too fast” for CP Backup. I’ll try to find out over the weekend.

    The only question is whether all the sectors are in the images... but I can’t say right now.

  11. Dan S says:

    @Michal well, the machine i’m using to run CP backup.. is definately not too fast. It’s running at 4.7mhz (I’m using http://jsmachines.net/disks/pc/dos/microsoft/4.0M/ (a machine in javascript… actually works really well)… my output from CPBACKUP’s directory utility shows the following: http://i39.tinypic.com/2m7g089.jpg

  12. Michal Necasek says:

    Ah, jsmachines is excellent 🙂 Anyway, there is a clue right there: 10 sectors per track. So your image should be 400K big (is it?) and jsmachines needs to support such non-standard images (I don’t know if it does).

  13. Dan S says:

    my images are: 368640 bytes…. so no… I’m gonna have fun ripping these disks again then (one i had to _clean_ the disk to get it to read the last track) … the slowest i can get in actual hardware is breaking out an old dual PPro box i have

  14. Dan S says:

    I’m going to do some digging.. i know for a fact, that i’ve done ‘oddball’ floppy sizes under linux.

  15. Dan S says:

    Addendum to the above. i was right, non existant ‘track 41’ shouldn’t matter ya think?
    5.25 inch double density device files:

    Name Capac. Cyl. Sect. Heads Base minor #
    ———————————————————-
    fdnd360 360K 40 9 2 4

    5.25 inch high density device files:

    Name Capac. Cyl. Sect. Heads Base minor #
    ———————————————————-
    fdnh360 360K 40 9 2 20
    fdnh410 410K 41 10 2 48

  16. Michal Necasek says:

    Right, the 41st track shouldn’t matter. You should be able to strip it from the images if necessary. Using an extra track or two was a common trick... but it didn’t work on all systems.

  17. Dan S says:

    welp.. linux won’t let me access the floppy with other than /dev/fd0. if i try and use the fd0h410, let’s just say it’s not happy… even on one of the cpbackup floppies. well hell.

  18. Dan S says:

    and if i poll information on one of the disks, it ‘claims’ 9 sectors per track..

  19. Dan S says:

    and.. after reading your article again.. I am going to run into this issue.. ” disks created in high-speed CP Backup mode find themselves in an unpleasant situation—medium/high speed mode doesn’t work, and compatible mode won’t read the disks. ”

    since mine were made with ‘high speed mode’… *sigh*.. what for a timemachine.

  20. Michal Necasek says:

    If it’s like the 5.25″ HD disks created by CP Backup, then the disk indeed pretends to be a standard DOS format, but isn’t. Great for confusing software 🙂

    I successfully (well, I think it was successful) dumped CPB floppies using Sydex’s AnaDisk (ancient DOS utility). I won’t pretend to know how to do it in Linux, but I’m almost certain it’s possible as well. The difficulty probably lies in convincing the OS that the disk format is what you say it is, not what the disk says it is.

  21. Dan S says:

    I’ll give that a shot (It’ll involve more trickery, but i tend to always have to do a lot of that anyways).. what about the bit with the ‘high speed vs low speed’?

  22. Dan S says:

    I managed (did a test one anyways) to rip one of the disks with anadisk under freedos booted from a usb stick. file size: 409600 bytes

    What’s funny is that a ‘scan’ with anadisk shows 9 sec/track, when obviously that’s not what it actually ‘ripped’… and it saw the ‘sectors marked bad’ as CPbackup does.

  23. Michal Necasek says:

    That’s certainly the right size. AnaDisk shows the information from the BPB, but analyzes each track separately.

    Now... can you use the image with some emulator?

  24. Dan S says:

    That’s going to be the fun part.. the machine i was on was defintely ‘too fast’ for CPbackup.. but then there’s going to be the low speed vs high speed backup issue.

  25. Dan S says:

    So I tried using CPBDIR against the ‘disk images’ (mounted as floppies in jsmachine) and it gives the same ‘Invalid Parity Record’ on them that it was giving on the previous images… Note: these were ‘ripped’ on a 1.2M Teach 5-1/4 drive…

  26. Michal Necasek says:

    The question is how jsmachines handles the non-standard floppy image. Does it use a 40/2/10 to work with the image, or something else? If it doesn’t use the right geometry then nothing will work properly.

    Any chance you could send me the image? I’d love to test it with other emulators/hypervisors.

  27. Herbert says:

    Thank you very much for the documentation of this bug and its obstacles. With SlowDown, I was able to find a middle type setting to get CPB for Windows run on a Pentium1/133 W98 again to restore some cp-formatted 1.44 backup discs with mid speed. 🙂

  28. DOS says:

    > The hard part is finding the run-time error message when it flashes by so fast it’s invisible

    I take it that’s why the interface seems to scroll 2 lines up the screen and then gets redrawn a second later without my history being retrieved?

    I tried running CP Backup 7.1 under Windows for Workgroups 3.11 and there you at least get to see the error message “System Error”, “Divide By Zero or Overflow Error”.

    Thanks @Herbert, I used “slowdown” from http://bretjohnson.us/ to slow my Pentium 166 down to 486/33 speed and it worked when running CP Backup 7.1 under DOS to restore a high-speed backup. It didn’t work for me under Windows, maybe a newer version of PC Tools would be better when using such a modern Windows 3.x variant.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.