TeleDisk File ArchivesThe 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 FormatI'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.
Late Breaking NewsThis is the format description from the Version 1.03 Teledisk Manual Sergey emailed me in 2002. STRUCTURE OF THE TELEDISK v 1.03. TDn FILES
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
on.
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
byte.
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"
media.
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
bytes.
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
track.
2 - A data CRC error occurred when this sector was
read.
4 - A deleted data control mark was present for this
sector.
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.
|
File Format >