TAP format
Fraser Ross
it. Is there a V3 format now?
Fraser.
Somebody
> Are the V2 TAP format specifications anywhere? I can't find anything on
> it.
The only one I could find is the source code of MTAP.
if (machine == C16)
fprintf(fpout,"C16-TAPE-RAW");
else
fprintf(fpout,"C64-TAPE-RAW");
fprintf(fpout,"%c%c%c%c",tapvers,machine,video_standard,0);
fprintf(fpout,"%c%c%c%c",0,0,0,0); /* filelength */
> Is there a V3 format now?
No
Joe Forster/STA
> > it.
>
> The only one I could find is the source code of MTAP.
And there are some other instances of "tapvers" in the source. The
changelog says experimental halfwave support has been introduced in
mtap 0.31. As Per Håkan Sundell's original specification at
http://www.computerbrains.com/tapformat.html contains no version 2, I
conclude that Markus Brenner added it.
VICE supports it, search for "tap->version" in "vice-2.3/src/tape/
tap.c" of the source package. For someone already familiar with the
TAP file format (e.g. unlike me <:-) ), these source fragments should
be enough to find out what this exactly means. If you've succeeded,
please, send the description to Peter Schepers to be added to his
Commodore-related file format compendium, available online at
http://ist.uwaterloo.ca/~schepers/formats.html.
Somebody
Version 2 is version 1, only each pulse represents a semiwave rather
than a full wave.
Markus Brenner extended the format further, to introduce machine (C64,
C16, VIC20) and video standard (PAL, NTSC). But those are not specific
to version 2.
Fraser Ross
Thanks for the help. I can see now I must have looked at some source
code before. It looks like the format was extended to hold longer waves
as 2 pulses. Vice simply joins them when they are read.
Fraser.
Fraser Ross
>
> Thanks for the help. I can see now I must have looked at some source
> code before. It looks like the format was extended to hold longer
> waves as 2 pulses. Vice simply joins them when they are read.
Its actually the shorter waves that are now effectively pulses with V2
files.
Fraser.
Linards Ticmanis
And do I get this right, the point of V2 is the following? While the VIC
and the 64 can only detect the falling edge of the tape read signal (so
it doesn't matter where the rising edge is located between two falling
edges), the C16 and Plus/4 can also detect the rising edge (so it does
matter where it is).
Or is there some other motivation?
--
Linards Ticmanis
Fraser Ross
> And do I get this right, the point of V2 is the following? While the
> VIC
> and the 64 can only detect the falling edge of the tape read signal
> (so
> it doesn't matter where the rising edge is located between two falling
> edges), the C16 and Plus/4 can also detect the rising edge (so it does
> matter where it is).
>
> Or is there some other motivation?
I'd like to know about that as well. In general pulse lengths are not
reliable for representing data or synchronisation signals. I've not
seen any format that uses them much.
Fraser.
A Grosz
> > it doesn't matter where the rising edge is located between two falling
> > edges), the C16 and Plus/4 can also detect the rising edge (so it does
> > matter where it is).
>
> > Or is there some other motivation?
>
> I'd like to know about that as well. In general pulse lengths are not
> reliable for representing data or synchronisation signals. I've not
> seen any format that uses them much.
The C16/+4 line can basically only detect an "edge change" and
can not distinguish them either. For most tape loaders (most notably
the KERNAL and
NOVALOAD) this is not an issue, however there were a couple
turboloaders
that (accidentally?) write only a half wave at one point, basically
inverting the signal.
Here's some more info:
http://c64tapes.org/forum/viewtopic.php?t=156
May I enquire why you need this info?
best,
Attila
Fraser Ross
TAP files. It can be found at World of Spectrum. I'd be interested in
seeing any TAP files where the waves become inverted like you were
saying. Do you have any links to any of them files?
Fraser.
A Grosz
Here's the most prominent one:
http://plus4world.powweb.com/software/Her_Turbo
This is the TAP of the actual turbo saved with itself, so one can just
go ahead and
investigate directly.
cheers,
Attila
Joe Forster/STA
I played around with this one... :-) The actual program code is at
offsets $16083-$22072. Bytes are stored MSB first, LSB last, bits are
stored as pulse pairs: $21 $21 is a 1 bit, $0E $0E is a 0 bit. The
extra byte at offset $22073 is probably a checksum, the extra 4 bytes
at offsets $16043-$16082 are definitely the start and end addresses
($0400-$0FFF).
Fraser Ross
to view negative code numbers as 0. I can't remember where I found the
information about the machine type and video standard extentions. There
are several reasons for getting the complete format written somewhere.
I think this file has a machine type of +4/C16 a video standard of PAL
and the sampling rate is 886724.
Fraser.
Joe Forster/STA
As I wrote in an earlier post of mine, Peter Schepers' compendium at
http://ist.uwaterloo.ca/~schepers/formats.html is the one to be
updated about _any_ Commodore-related file formats so, please, forward
any findings to him.
A Grosz
Yes that's correct. Basically for the C16/+4 you can consider anything
that has not not got a video
standard of 1 (NTSC) as PAL (0)... there were a few crappy TAPs made
in the past that
are not quite following the "standard" (in many cases tapes were first
sampled
as WAV and converted to TAP with "homebrew" utilities that often
disrespected
a few rarely used parameters.
BTW, it really does not make much sense to differentiate video
standard
AND machine type AND sampling frequency versions all at once. Storing
the sampling
frequency alone (i.e. the length of a TAP unit) would have been
perfectly sufficient.
But I guess it's too late now :) Or we could draft a version 3 MTAP
format that
would do just that...
Attila
Somebody
> BTW, it really does not make much sense to differentiate video
> standard
> AND machine type AND sampling frequency versions all at once. Storing
> the sampling
> frequency alone (i.e. the length of a TAP unit) would have been
> perfectly sufficient.
But it has an advantage: that way, you are guaranteed 1 time unit in a
TAP file is equal to 1 clock cycle of some C= machine.
BTW, the DMP format stores frequency
Somebody
> The file has a video standard byte of 0xC0.
Which sounds plain wrong. Only 0 and 1 are valid.
> I can't remember where I found the
> information about the machine type and video standard extentions. There
> are several reasons for getting the complete format written somewhere.
At
http://groups.google.com/group/comp.emulators.cbm/browse_thread/thread/f04cf362ab652a5e/1e8284ff8d07302f
, Markus Brenner explains his extension to the TAP format.