TAP format documentation?

[srowe]

I've started dabbling with TAP files and writing a decoder in Python. Is there a more recent document that describes the format than http://unusedino.de/ec64/technical/formats/tap.html? Some files seem to have non-zero values for the reserved fields in the header and I can find a mention of a version 2 format on news groups (and in the VICE code).

[groepaz]

Just asked SLC (ony of THE tape nerds =P) after i noticed the VICE docs are also missing this info.... according to him there is an unofficial v2 format which was used for C16 tapes only. He recommends looking at the tapclean source for details.

If you find out more, please post - i'd like to update the VICE docs accordingly.

[srowe]

Some discussions on this thread

http://compgroups.net/comp.sys.cbm/tap-format/559115

Unfortunately http://c64tapes.org seems down.

[tlr]

This is what I've used as reference when doing C16 tape masters:

Code: Select all

comp.emulators.cbm: How did the Cbm64/vic20 tapes work technically
------------------------------------------------------------------
From: Markus Brenner 2001-01-23

arcade...@hotmail.com wrote:
>I want to write a utility that takes the sound from a vic-20 tape into
>the soundcard of a PC and then produce a .TAP file of it for use in
>emulators, and for better preservation of the data.
>
>There are a number of good such utilities, none of them could read my
>old vic20 tapes that are (appatently) in a pretty bad shape.

Tape recording on the VIC-20 works pretty much the same as on the C64.
The only difference is the clock frequency:

C64_PAL: 985248 MHz (Cycles per second)
C64_NTSC: 1022727 MHz
VIC20PAL: 1108405 MHz
VIC20NTSC: 1022727 MHz

As the TAP format is always defined relative to the clock frequency (one TAP
unit is the time of 8 clock cycles on the machine), most of the TAP tools
around can't handle VIC20 PAL tapes as the VIC's clock frequency is somewhat
higher than C64's.

If you check out my own mtap, you will notice I actually implemented a command
line option for VIC-20 tapes:

http://arnold.c64.org/~minstrel/


So, actually you tapes are not that bad, but it's rather a fundamental issue
when transfering VIC-20 tapes with C64 TAP utilities that the resulting TAP
files won't work on VICE :)

>I want to start this utility from scratch and dont use any assumtions
>made in the available utilities, which dont do the job for me.

But the available utilities would use the same assumptions than you will, as
the principle isn't that complicated :)

>NOW. Can someone link me to information on how the information was
>saved on Vic-20 (C64) tapes, preferably also how the hardware in vic-20
>decoded it.

Well, I have written a document about this some time ago to help the YAPE
author implement TAP support in his Plus/4 emulator. I believe the information
is fairly correct, however there might be some flaws in there (I just wrote it
up and never proofread it). So read at your own risk :)

Proposal: Implementing TAP format on C16, C116, Plus/4 emulators.
========

(Markus Brenner, <mar...@brenner.de>)


BACKGROUND: Back in the 80s, software usually came on one of three data
storage mediums: Cartridges, 5.25" Floppy Discs and Cassette tapes. The
TAP format deals with archiving Cassette tapes in a digital, effective way,
maintaining 100% of the information stored on the original tape.
Per Håkan Sundell originally introduced the TAP format for his CCS64
emulator of the Commodore 64. The format has since been successfully
used for PET and VIC20 emulators, and can easily been adapted to
the TED/264 series of computers.


TECHNICAL INFO: A cassette recorder ("Datasette") uses normal magnetic
audio tape to store digital data. To be able to do this, the Datasette
uses some electronics hardware that 'translates' binary digits to
analogue sinus waves. '0' and '1' bits usually are discriminated by
the frequency of the sinus wave, or rather by the length of one complete
period of sinus wave: A '0' usually uses a shorter wave than a '1' bit.
On the tape, this looks something like this:

      _____                         ___
 __---     ---__                 _--   --_           _--
-               -__           __-         -_       _-
                   ---_____---              --___--

|-------- long '1' wave ---------|--- short '0' pulse --|

The exact lengths of pulses varies with different loader (KERNAL ROM loader,
Turbo Tape, NOVALOAD). The TAP format deals with this by storing the actual
_length_ of a pulse: Each byte in a TAP file gives the length (in units
of processor cycles) of a pulse stored on tape.

The computer communicates with the datasette basically by two lines:
CST_READ and CST_WRITE. Both lines are directly wired to the 8501 CPU
processor port. If the computer writes a bit to tape, it actually writes
two half-waves:

1) toggle Write Line:
   LDA  $01
   EOR  #$02 ; (toggles write line)
   STA  $01

2) use the TED timer to wait one halfwave

3) toggle Write Line
   LDA  $01
   EOR  #$02
   STA  $01

3) use the TED timer to wait the second halwave (both halfwaves
   have the same length)


Reading the cassette works similar:

1) wait for Read Line = 0
wait:
   LDA  $01
   AND  #$10
   BNE  wait:
   
2) start timer

3) wait for Read Line 0->1->0 transition

4) read out timer, and determine if it was a short or a long pulse.

FORMAT DESCRIPTION: (adapted from
http://www.computerbrains.com/tapformat.html)

0000 'C16-TAPE-RAW' ; Changed from 'C64-TAPE-RAW'
000C UBYTE Version
000D UBYTE Computer Platform (0 = C64, 1 = VIC-20, 2 = C16, Plus/4 etc)
000E UBYTE Video Standard (0 = PAL, 1 = NTSC1, 2=NTSC2)
000F UBYTE For future use...
0010 ULONG data length (Intel format LSB,MSB)
0014 UBYTE[] data
..

Version=0:
Each data byte represent the length of a pulse (the time until the c64's
hardware triggers again).  The length is (8*data) cycles (PAL C64), i.e. the
data byte of 2F represent (47*8/985248) seconds.  The data byte value of 00
represents overflow, any pulselength of more than 255*8 cycles.

Version=1:
As above but data value of 00 is now followed by three bytes, representing a
24 bit value of C64
cyles (NOT times 8). The order is as follow: 00 <bit0-7> <bit8-15> <bit16-24>.

Version=2:
As version 1, but each value represents a halfwave, starting with a
'0'->'1' transition. The time encoding doesn't change.


PLUS/4 IMPLEMENTATION HINTS: The TED timers always run with the slower
clock rate (886724 Hz for PAL machines (??)), so the length of one
TAP pulse should be relative to this frequency. A data byte of 2F represents
(47 * 8/886724) seconds for the TED machines.When playing back a TAP
on the Plus/4 emulator, you should write a routine that sets the CAS_READ
line to '0' for half of the time and '1' for the other half. This should be
easy to implement, as your emulator probably counts in units of clock
cycles anyway :) As for writing to a TAP file, you need to watch the CAS_WRITE
register (processor port, bit 0x02) and start counting whenever a 0->1
transition happens (I could be wrong with the polarity here, you need
to check this until you get reasonable TAP files).


References
----------

CCS64 Home Page:
    http://www.computerbrains.com/ccs64/         (CCS64 home page)

Original TAP format specs:
    http://www.computerbrains.com/tapformat.html (original TAP format specs)

Information on TED and timers:
    http://www.geocities.com/SiliconValley/Screen/3676/Hardware/p4gfx.htm

System information by Marko Mäkelä
    http://www.hut.fi/Misc/cbm/cbm-msmakela.html#C16

[Noizer]

Perhaps a sign of more understanding: http://wav-prg.sourceforge.net/faq.html

[groepaz]

what tlr posted is probably all you can find on the "v2" format. i have updated the VICE docs accordingly cheers