(Community info on how to preserve existing tape and disk software - conversion from native Dragon to PC formats - WAV, CAS, VDK, DMK, conversion between formats and restoration back to physical media)
Tape to CAS File
Current preferred method is a special version of XROAR that will output the byte stream its virtual ADC reads from a WAV file as the tape loads (CLOAD/CLOADM).
Previously DC.EXE (Dragon Convert) was used to create CAS files from WAV samples but this often resulted in CAS files with truncated sync bytes rather than an accurate dump of the original media. DC.EXE had two operating modes, the default mode assumed that the tape content followed the documented dragon tape format and the /R option simply created a CAS file that was a RAW stream of the input bytes.
WAV to CAS
CAS to WAV
DC.EXE will create a clean WAV sample from a CAS file. If the CAS file has all its SYNC bytes then the resultant WAV can be loaded by a real Dragon 32/64.
"Fixing old CAS files"
Some of the older CAS files with truncated SYNC bytes can be rescued using the FIXCAS.EXE tool that attempts to insert the appropriate number of missing SYNC bytes into the CAS file.
Disk to VDK
Using and old PC with a 5.25 inch drive and a DOS environment, the VCOPY.EXE tool can be used to copy some common Dragon disk formats to .VDK files.
Disk to JVC
Linux - dd
JVC to VDK
Perl Tool to add VDK header
VDK to JVC
Perl Tool to remove VDK header
VDK to Disk
Using and old PC with a 5.25 inch drive and a DOS environment, the VCOPY.EXE tool can be used to copy some common Dragon disk formats from .VDK files to disks. The disks must have been formatted in a real Dragon first....
JVC to Disk
Linux - dd
CSAVEM, start, end, exec Convert to CAS Use DC.EXE to extract from CAS to ROM format
.DGN format is a only an 8 byte header that can be removed or added to a raw rom dump.
CAS File Format
The CAS file format is one way of representing programs or data stored on Dragon cassette tapes. The CAS file format comes in two flavours, the most usual and default format is modelled after how the Dragon actually stores data on cassettes but with truncated leader and header bytes. The alternate format is simply the RAW byte stream and was only used for games that did not conform to the standard tape format (an early form of copy protection). The true tape format is documented in Inside the Dragon (Section 8.4.4).
The standard CAS file consists of a number of blocks. Each block contains:
- A leader, comprising of any number of bytes with value 0x55.
- A sync byte of value 0x3c.
- A block type byte. Valid types are 0 for namefile block, 1 for data block and 0xff for EOF block.
- A byte containing the data payload size (0-255).
- 0-255 bytes of payload data.
- A checksum byte. The checksum is the sum of the block type, the payload size and the data bytes.
For a namefile block, the payload data contains the following information:
- An 8-byte program name.
- A byte indicating the file type. Valid types are 0 for a BASIC program, 1 for a data file, and 2 for a machine code program.
- A byte indicating whether the file is encoded as ASCII or binary.
- A byte indicating whether the file is written with gaps between blocks. A value of 1 indicates that the file is written without gaps, and a value of 0xff indicates that it contains gaps between blocks.
- Two bytes indicating the start address of a machine code program.
- Two bytes indicating the load address of a machine code program.
The first block of a standard CAS file should be a namefile block, and the last block should normally be an EOF block. Some games used copy protection where the number of blocks to be loaded did not match the number specified in the file header and a fake EOF block was included so a simply copy of the file would result in a truncated file.
Note that standard format CAS files may omit leaders. Use the FIXCAS utility to add leaders to more closely resemble the true Dragon cassette tape format. Since the standard format CAS file is a fairly simple representation of the data stream read from a tape after demodulation and decoding of the audio signals, certain properties of cassette tapes cannot be reproduced, e.g. gaps of silence (at least one game loader uses this as a copy protection mechanism that needs the RAW format of CAS to work - although this doesn't store silence it does store noise in those gaps).
The above description makes it pretty easy to create CAS files. Reading CAS files can be a bit more difficult though. Data is actually represented as a stream of bits on cassette tapes, and the Dragon uses different audio signals to represent different bit values. When decoding such an audio signal into a bit stream and creating a CAS file, the structure described above might not align to byte boundaries in the CAS file. Especially the leader may not be decoded to an integral number of bytes. To make matters even worse, both leaders and sync bytes may contain noise and still be readable. A robust CAS file reader must take this into account.
For an example of a RAW format CAS file exhibiting both byte misalignment and leader noise, see Beyond Software's Kriegspiel (last modified 2009-01-04) in the download area.
JVC/DSK File Format
A disk format created by Jeff Vavasour for his Tandy emulator series, this is the simplest disk image format. It consists of an optional header followed by the DATA portion of each disk sector in order of track, then side, then sector number.
Taken from Tim Lindner's JVC format documentation, the header is as follows:
|0||Sectors per track||18|
|2||Sector size code||1|
|3||First sector ID||1|
|4||Sector attribute flag||0|
Sector size code indicates sector is (128 << n) bytes long. The default of 1 means a sector size of 256 bytes.
The sector attribute flag indicates that each sector is preceeded by an attribute byte. This contains which bits would be set in the WD279x status field after a read sector command, and can indicate record type, record not found and CRC error.
The presence of the sector attribute flag confuses things slightly, as if it is set, suddenly the header size is the file size modulo 257 instead of modulo 256.
VDK File Format
Similar to the JVC/DSK format, this contains a header followed by a raw dump of sector data. Data is in track, then side, then sector number order.
Complete header information from the source code:
|0, 1||'d', 'k'|
|2, 3||Header size (little-endian)|
|4||Version of VDK format|
|5||Backwards compatibility version|
|6||Identity of file source|
|7||Version of file source|
|8||Number of tracks|
|9||Number of sides|
|11||Compression flags and name length|
DMK File Format
A file format created by David Keil, carrying a lot more information about the underlying structure of the disk. Almost every piece of information that can be reported to the WD279x is recorded.