File Format‎ > ‎


TeleDisk File Archives

The TeleDisk shareware program was initially developed by Sydex in the late 1980s. Sydex compared the compressed image files it created from a floppy disk to a electronic fax because they could be emailed across the country and floppy recreated at another location. It became a popular method of archiving and reproducing diskettes, especially those with unconventional geometries. I became interested in it because several of the Digital Equipment systems, the Decmate, Rainbow, and Pro PDP-11 machines could all use RX50 media which TeleDisk could accurately archive. There are still archives of these collections at a number of internet sites including Update and Metalab. All rights were sold to New Technologies, Inc in 2000 when it was removed from shareware distribution. There is some mention of Teledisk in the DEC rx50faq. It can still be downloaded from some software repositories but it is no longer a supported product line. I became interested in reverse engineering the file format in the early 1990s. It wasn't long until I discovered that Sergey Erokhin in the Ukraine and Dave Dunfield in the US were also working on this. We shared information at that time and all eventually released public domain programs that could read files written with the *.td0 Teledisk format.

Will's current wteledsk.tar.gz distribution and this summary page are available on these web pages. Wteledsk.exe will extract the compressed image data from a *.td0 file to an uncompressed binary sector by sector file suitable for use with John Wilson's PUTR program to write the data to DEC floppies or for direct use in an emulator package. Sergey Erokhin's distribution TDCVT is still available but the documentation appears to use the Cyrillic script (aka Russian language) and is not readable by someone with my limited language skills. I believe it reads and converts *.td0 images to ZX-Spectrum game disk emulator format. Sergey was fun to talk with via email and reported "He lives in Solar system, Earth, Europe, Ukraine, Kharkov ... and for more information on the Ukraine he recommended the CIA factbook". Dave Dunfield's pages on Teledisk and ImageDisk programs are located below the page above, but Dave wants you to start at the top level page so you read his comments on the intellectual property he presents. Personally I think Dave's pages contain most of the information one needs about this format and the tools to work with these images. Dave's ImageDisk utility can read and write *.IMD (Dave's documented image file format) from or back to floppy media. He also provides a utility to convert *.TD0 files or raw binary file images of a floppy to *.IMD format. I have seen some mention of PCE PC-Emulator which is a collection of PC emulators that contains support for the *.IMD and *.TD0 formats. I have not explored this and do not know how to extract the relevant code from the emulator package, but the post here by coolhaken recommends it.

The best, and actually the only original documentation I have seen about the TELEDISK format is contained in the TeleDisk manual for version 1.04 from August, 1988. My acquaintance Sergey emailed me the pertinent section from the version 1.03 TeleDisk manual and its included at the end of this file under "Late Breaking News". Dave Dunfields pages also include copies of several versions of the original TeleDisk distributions in *.zip files. His version 1.05 contains the manual for version 1.04 which also contains the documentation above. Of interest, the original programs could contain multiple images in a data set. The '0' in a *.td0 image is the disk number. I have never seen it done, but apparently the program could create *.td# images where # > 0 represents additional disks in a set.

TELEDISK File Format

I'm not going to try to cover all the aspects of the file format here, you can look at the various source code distributions if you are really interested. But I'll give enough of an overview that you can verify whether or not you actually have a Teledisk image file. There were two main varients. Both began with a 3 character signature. In the most common, know as 'normal compression', the first two bytes were the upper case characters "TD" followed by a digit representing the disk # in the set, typically '0'. In the less common advanced compression the first to characters were lower case "td". My wteledsk.c source code includes all the information I have on this file header. Of possible interest, the 4th byte of this header is a version number for the Teledisk program that created the file, its 0x15 in almost all the sample images I have seen which appear to be from Teledisk versions 2.11 to 2.16. The 8th byte of this header is a bit mapped flag byte, see below.

In a 'normal' compression file the file header is followed by a descriptive comment field if the high order bit in the flag byte is set. If this bit is set the structure below defines the next 10 bytes of the file:

struct com_head {
WORD crc, //  checksum of 8 bytes from &len to end of record
     len;     // length of string data region following date
BYTE yr,mon,day,
     hr,min,sec; // date and time info....

It in turn is followed by the variable length comment string.

The remainder of the file are repeats of the track and sector records and associated data for a given disk. The main file header includes the number of sides in use on the floppy, but depends on the track records to indicate the number of tracks. The format also allows different tracks to have different sector counts which a few copy protection systems apparently used. The file contains no direct information about the OS Struture or names of the files on the disk, it just stored the raw track and sector information. IE it worked for any floppy disks your drive could read. There were some minimal run length encoding options for the sector data but these were based on pattern repetition rather than more advanced data compression. However that can be very effective on a sparsely populated disk!

With advanced data compression the disk data was first encoded as described above. Then everything from the end of the 12 byte file header to the end of the file was compressed using LZHUF compression and written to the file starting immediately after the header. Sergey and I both handled this format with an additional program which decompressed the original file converting it back to 'normal' compressed format and then running the normal decompression program on the resulting file.

This is the system used in my initial release of wteledsk ver 1.00. I continued to work on this occasionally with people who had oddball files that my initial algorithm did not handle correctly. There are some Akai sampler disk and file formats and according to this document Akai distributed some of their sampler data in *.td0 format. I worked with some of these images provided by an internet acquaintance. They appeared to contain some duplicate sector data which I never fully understood although I added warning messages when I encountered them. When we got done my internet friend was able to use the data so I guess it worked when the duplicate regions were ignored. This code remains in the current wteledsk.c ver 1.03 included in the current distribution, but is ignored unless the keyword AKAI is defined in the build file.

In the process I also worked out a fairly painless method of handling the 'advanced data compression' issue in a single pass through the file. Enabling advanced compression and CRC checks is also handled at compile time with compiler defines rather than run time options. These additions are available in the current release wteledsk.tar.gz. The current source code release is now wteledsk.c ver 1.03. The current release has build files which allow creating executable files with the 'Open Watcom' compiler for Win32 in the console environment of a 'Command Prompt' box. Linux build files for gcc were also provided to run an equivalent program in console mode under Linux.
As a point of interest I find that there is a wteledsk ver 1.01 distribution available on I am credited for my original source code, but did not put it there nor write the linux makefile included. Its very similar to my current ver 1.03.

Late Breaking News

This is the format description from the Version 1.03 Teledisk Manual Sergey emailed me in 2002.

      The first file of a TELEDISK series has,  as its file name exten-
      sion, TD0.  A subsequent file will have the extension TD1, and so

      Every TELEDISK data file has a header of the following form:

           File Identification, 2 bytes, with a value of 'TD' if normal
           data  compression was used to write it,  or 'td' if advanced
           data compression was used.

           Volume Sequence, 1 byte, the first volume is volume 0.

           Check Signature, 1 byte.   This is a unique signature common
           to all files in a sequence.  That is, the headers for a TD0,
           TD1,  TD2  sequence would all have this same check signature

           Version number, 1 byte.   Version of TELEDISK used to create
           this file.  A decimal value of 10 would signify version 1.0,
           11 would signify version 1.1 and so on...

           Source Density,  1 byte.  Recording density of source drive;
           0 = 250K bps,  1 = 300K bps,  2 = 500K bps.   If this was  a
           single-density FM diskette, this number is biased by 128.

           Drive Type,  1 byte.   Type of source drive.   1 = 360K, 2 =
           1.2M, 3 = 720K, 4 = 1.44M.   Note that the actual media size
           is  not  recorded;  thus  type 3 may be either 5.25" or 3.5"

           Track Density,  1 byte.   Track density of source  drive  in
           relation to source media.   0 = source density matches media
           density.  1 = double density media in quad density drive.  2
           = quad density media in double density drive.

           DOS Mode,  1 byte.   Nonzero if source diskette was analyzed
           according to DOS allocation.

           Media  surfaces,  1  byte.    1  =  single-sided media,  2 =
           double-sided media.

           Header CRC, 2 bytes.  A 16 bit CRC for this header.

      After the header,  the diskette structure information and  sector
      data  follows.   If advanced data compression was used to produce
      this file, the information appears in 6,144 byte blocks of 12 bit
      Lempel-Zev code.   Each block is preceded by a 2 byte CRC and a 2
      byte code packet count (one packet = 12 bits).

      The  information  for  each  track  (or surface) is prefixed by a
      header of the following format:

           Sector count, 1 byte.  How many sectors are contained on the
           current track.   If this is the end of the data  file,  this
           field is set to 255.

           Physical  cylinder,  1  byte.   The physical position of the
           source drive head when this track was read.

           Physical side,  1 byte.   The actual surface (0 or 1) of the
           diskette on which this track occurred.

           CRC check byte,  1 byte.   A CRC checksum of the preceding 3

      After each track header,  there follows a list of sector headers.
      Each sector header is of the following format:

           Cylinder,  1 byte.  The cylinder number of this sector as it
           appeared in the ID address field.

           Side,  1 byte.   The side code of this sector as it appeared
           in the ID address field.

           Sector number,  1 byte.  The sector number of this sector as
           it appeared in the ID address field.

           Sector length code, 1 byte.  The length code (0 = 128 bytes,
           1 = 256 bytes, etc.) of this sector as it appeared in the ID
           address field.

           Syndrome flags, 1 byte.  Flags indicating various conditions
           of the sector data field, namely,

                1  - This sector number occurred more than once on this

                2  - A data CRC error occurred  when  this  sector  was

                4    - A deleted data control mark was present for this

                16 - A DOS sector copy was requested;  this sector  was
                not  allocated.   In this case,  no sector data follows
                this header.

                32 - This sector's data field  is  missing;  no  sector
                data follows this header.

                64  -  No ID address field was present for this sector,
                but there is a data field.   The sector information  in
                the header represents fabricated information.

           Sector  CRC,  2 bytes.   A CRC checksum of the sector header
           information as well as the sector data which follows.

      If present,  (see the syndrome flags above) the data for the cur-
      rent sector follows the header.   Note that this data is also in-
      cluded in the CRC checksum in the header.