This is a continuation of the development of the ftape driver, originally by Bas Laarhoven, later by Claus-Justus Heine et al., and now with some of my (Dmitry Brant) own tweaks and modernizations for getting it to compile and run on modern Linux kernels (version 6.1 and higher).

TLDR: It absolutely works! (tested on Xubuntu 24.04 and 26.04 (x86_64), and Debian 12.12 (i386))

However, there is still a lot of testing to be done, and therefore there may still be bugs related to the modernization effort. For my previous work getting the completely original (unmodified) driver to work with CentOS 3.5 (with kernel version 2.4.21), refer to the centos35 branch of this repo, and the README therein.

Ftape is a driver that allows Linux to read data from "floppy tape" drives, i.e. tape drives that connect to the floppy controller (FDC) directly on the motherboard, such as the Colorado Jumbo 250, the Ditto Max, etc. Formally speaking, the driver works with tape drives that support the QIC-117 specification. It also supports numerous external tape drives that connect to the parallel port of the PC, such as the Trakker, Iomega Ditto 2GB, etc.

The types of tapes supported by these drives are called QIC (quarter-inch cartridge), such as QIC-40, QIC-80, and their later cousins like QIC-3020, QIC-Wide, Travan, and Ditto.

The ftape driver used to be included in the Linux kernel, until it was removed in 2006, as of kernel version 2.6.20.

However, that's not the whole story:

• The last version of the driver that was included in the kernel, right up until it was removed, was version 3.04.
• BUT, the author continued to develop the driver independently of kernel releases. In fact, the last known version of the driver was 4.04a, in 2000.
• My goal is to continue maintaining this driver for modern kernel versions, 25 years after the last official release.

Even though QIC tapes have long been obsolete as a backup medium, there is still a nontrivial market for data recovery from such tapes that still exist in the wild, where the ftape driver can fill an important niche. There is also the retrocomputing community, which can benefit from such a driver bringing old hardware back to life.

• Since this driver is intended mostly for recovering data from old cartridges, more emphasis will be placed on maintaining reading functionality rather than writing, emphasizing compatibility with various tape drives. Bugs related to writing may be deprioritized, and indeed I might consider removing writing/formatting functionality entirely, and leave it in a separate unmaintained branch.
• In the interest of making this driver into a "forensic"-quality recovery tool, more emphasis will be placed on lower-level data extraction, e.g. raw mode, disregarding volume tables, disregarding ECC failures, etc.
• The intention is to compile this driver as an out-of-tree kernel module, without needing to copy it into the kernel source tree. That's why there's just a simple Makefile, and no other affordances for kernel inclusion. I can't really imagine any further need to build this driver into the kernel itself.

• Make sure your build tools are installed: sudo apt install build-essential
  • (You may also need to install Linux headers: sudo apt install linux-headers-`uname -r` )
• Clone this repo.
• Run make!

When (if) the build process finishes, it should make several kernel modules (.ko files) in the base folder of the repo. These are modules that are loadable using insmod or modprobe. There's actually no need to run make install (which copies the modules into your actual /lib/modules/... directory), I just prefer to load the modules directly from the repo directory on demand.

For convenience, there are scripts for loading the modules in the proper order, with the proper parameters for specific types of drives (look inside these scripts for examples and explanations of the parameters):

• insert_floppy.sh for when you have a drive connected to the floppy controller (FDC), such as Colorado 250, etc.
• insert_max.sh for when you have a Ditto Max drive, specifically, connected to the floppy controller.
• insert_parallel.sh for when you have a drive connected to the parallel port. This script might show warnings when loading, but ignore them and check dmesg for the true state of the driver. (And make sure your parallel port is configured for ECP in your BIOS.)

Once all of this is done, and the kernel modules are loaded without errors, you can interact with the tape device files, e.g. /dev/nqft0, /dev/rawqft0 and so on. You can proceed to dump the data from a tape using a command like: dd if=/dev/nrawqft0 of=out.bin bs=10240

Raw mode is the recommended way to dump the data from the cartridge for preservation.

When a raw device (/dev/rawqft0, /dev/nrawqft0) is opened read-only, the driver hands out an unabridged image of every segment: all 0x8000 bytes, i.e. the 29 data sectors followed by the 3 ECC sectors, exactly as they were read from the tape. This makes the dump a completely faithful representation of the cartridge. (Segments containing bad sectors, as listed in the bad sector map, are correspondingly shorter, since those sectors don't exist on tape.)

ECC checking and correction still happen as before, and a corrected segment is dumped in its corrected form. Use the ft_ignore_ecc_err module parameter if you want segments that fail ECC to be dumped anyway. (If a raw device is opened for writing, the ECC sectors are not part of the data stream (the driver generates them itself when writing), and the old behavior of 0x7400 bytes per segment applies. The same is true for the MTIOCRDFTSEG ioctl, whose user buffer is specified to be 29kb.)

In addition, raw mode also dumps the header segment(s) that appear at the very beginning of the tape (previous versions of ftape only dumped the data segments, starting with the volume table). A header segment contains the formatting details of the tape, as well as the bad-sector map, and other metadata. This means that any offsets encoded into the dump are relative to the first data segment (the VTBL segment) instead of the beginning of the dump.

All of this is for the purpose of having a 100% complete image of the tape, not just for proper archiving, but also for potential emulation in software, where an emulated DOS or Linux environment communicates with an emulated QIC drive, using a dumped tape image as the emulated cartridge. This also creates a couple of implications for dealing with raw tape images:

• When parsing a raw image, remember to take into account (or ignore) the ECC sectors at the end of each segment, and remember to take into account any header segments that come before the volume table.
• If you ever want to write a raw image back to a new physical tape, you'd need to strip away the header segments and ECC data, so that the driver can add those things on its own.

Make generous use of dmesg and look at the log messages therein. Use the ft_tracings module parameter to increase the verbosity of the messages to narrow down any issues.

In your BIOS, make sure the floppy controller is enabled. In certain BIOSes, this means enabling at least one floppy drive (the size/capacity doesn't matter).

Look at /proc/ioports and /proc/interrupts to see what IO ports and interrupts the system believes are assigned to the floppy controller, and use those assigments as parameters when loading ftape-internal (if they are different from the defaults). When the system boots up, it automatically loads the floppy module which claims those resources for itself. This is why the insert_floppy.sh script in this repo explicitly unloads the floppy module before loading the ftape modules, to ensure those resources are freed first.

In your BIOS, make sure your parallel port is configured for EPP or ECP mode.

Look at /proc/ioports and make sure that the IO ports are assigned to the parport module. You don't need to pass any custom parameters into ftape for using the parallel port, since ftape uses the parport API to get access to the parallel port, therefore it's only necessary to ensure that parport itself is working properly.

• This driver should work on either 32-bit or 64-bit x86 architecture, but obviously it still only works with the same limited set of FDC chipsets as before. If you want to use it with a real FDC tape drive, you must connect the drive to a motherboard with a supported FDC.
• The only thing that hasn't been modernized is Legacy Plug-and-Play support (Notice that internal/fdc-isapnp.c is left out of the makefile), simply because I don't have any PnP cards/devices to test with. If you have such a device, feel free to get in touch, or just take this driver and try to get it working, and submit a pull request.
• I have a rather limited collection of tape drives for testing and experimenting, so I make no guarantees about the driver working with your system. If you have a drive that doesn't seem to work with this driver, or if you simply need to recover data from QIC tapes, get in touch!