mirror of
https://github.com/aaru-dps/docs.git
synced 2025-12-16 11:14:37 +00:00
76 lines
3.6 KiB
Plaintext
76 lines
3.6 KiB
Plaintext
|
|
*** TAP (raw C64 cassette TAPE images)
|
|
*** Document revision: 1.1
|
|
*** Last updated: March 11, 2004
|
|
*** Compiler/Editor: Peter Schepers
|
|
*** Contributors/sources: Per Hakan Sundell,
|
|
Markus Brenner
|
|
|
|
Designed by Per Hakan Sundell (author of the CCS64 C64 emulator) in 1997,
|
|
this format attempts to duplicate the data stored on a C64 cassette tape,
|
|
bit for bit. Since it is simply a representation of the raw serial data
|
|
from a tape, it should handle *any* custom tape loaders that exist.
|
|
|
|
The TAP images are generally very large, being a minimum of eight times,
|
|
and up to sixteen times as large as what a raw PRG file would be. This is
|
|
due to the way the data is stored, with each bit of the original file now
|
|
being one byte large in the TAP file. The layout is fairly simple, with a
|
|
small 14-byte header followed by file data.
|
|
|
|
|
|
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
|
|
----------------------------------------------- ----------------
|
|
0000: 43 36 34 2D 54 41 50 45 2D 52 41 57 00 00 00 00 C64-TAPE-RAWúúúú
|
|
0010: 51 21 08 00 2F 0F 0D 31 64 1D 26 0D 07 21 0A 12 Q!úú/úú1dú&úú!úú
|
|
0020: 4A 2F 2C 34 07 18 0D 31 07 04 23 04 0D 42 0D 1E J/,4úúú1úú#úúBúú
|
|
0030: 34 04 42 0D 20 15 5E 04 0D 18 61 0D 26 29 34 0D 4úBúúú^úúúaú&)4ú
|
|
0040: 23 0D 07 0A 3F 55 04 0A 13 3F 07 0D 12 2B 18 0A #úúú?Uúúú?úúú+úú
|
|
|
|
Bytes: $0000-000B: File signature "C64-TAPE-RAW"
|
|
000C: TAP version (see below for description)
|
|
$00 - Original layout
|
|
01 - Updated
|
|
000D-000F: Future expansion
|
|
0010-0013: File data size (not including this header, in
|
|
LOW/HIGH format) i.e. This image is $00082151 bytes
|
|
long.
|
|
0014-xxxx: File data
|
|
|
|
In TAP version $00 files, each data byte in the file data area represents
|
|
the length of a pulse, when the C64's hardware will trigger again. This
|
|
pulse length is determined by the following formula:
|
|
|
|
pulse length (in seconds) = (8 * data byte) / (clock cycles)
|
|
|
|
Therefore, a data value of $2F (47 in decimal) would be:
|
|
|
|
(47 * 8) / 985248 = .00038975 seconds.
|
|
|
|
A data value of $00 represents an "overflow" condition, any pulse length
|
|
which is more that 255 * 8 in length.
|
|
|
|
The value of "clock cylces" from above (985248) is based on the PAL
|
|
value. Since this file format was developed in Europe, which is
|
|
predominantly PAL video, this is only logical. The NTSC value would be
|
|
1022730, which is very close to the PAL, and therefore won't cause a
|
|
compatability problem converting European and NTSC tapes. I would stick to
|
|
using the PAL value just in case.
|
|
|
|
|
|
In TAP version $01 files, the data value of $00 has been re-coded to
|
|
represent values greater than 255 * 8. When a $00 is encountered, three
|
|
bytes will follow which are the actual time (in cycles) of a pulse, and the
|
|
above formula does not apply. The three bytes are stored in LOW/HIGH
|
|
format.
|
|
|
|
|
|
The actual interpretation of the serial data takes a little more work to
|
|
explain. The typical ROM tape loader (and the turbo loaders) will
|
|
initialize a timer with a specified value and start it counting down. If
|
|
either the tape data changes or the timer runs out, an IRQ will occur. The
|
|
loader will determine which condition caused the IRQ. If the tape data
|
|
changed before the timer ran out, we have a short pulse, or a "0" bit. If
|
|
the timer ran out first, we have a long pulse, or a "1" bit. Doing this
|
|
continuously and we decode the entire file.
|
|
|