tape64 V1.20
============
by Andreas Matthies, 07/09/99
Please send feedback and bug-reports to This email address is being protected from spambots. You need JavaScript enabled to view it.
0. For Updaters
---------------
See the history.txt for a list of changes.
1. Overview
-----------
This small tool belongs to the group of utilities supporting the emulation
of the good old C64. To be more precise, it helps you to reuse your old tapes
recorded with the C2N (Datasette) of Commodore and full of programs for the
C64. All you have to do is to record the C64-tape with your soundcard and your
favourite sampling-software (for example the sound-recorder of Windows 9x).
tape64 then uses the recorded file (usually a .wav-file, when you use a
Windows-OS) to
a.) create a .tap-file (C64-TAPE-RAW). If you use Hakan Sundell's popular
emulator CCS64 or my favourite emu VICE, this .tap-file behaves like a
real tape. You can load your programs directly with the LOAD-command (or
<-L if they were saved with Turbo-Tape) in the emulation.
b.) create p00-files (binary images) from the C64-programs. In current version
the following loaders are supported/emulated:
- ROM-loader (files saved with the SAVE-kernal-routine)
- Turbotape
- Input64 (tapes coming with german magazine; tested with tapes 11/85-6/86)
- Novaload (commercial loader; special Nova-blocks are not supported due to
limitations of the binary format)
Support for other loaders may follow in next versions.
The p00's can be loaded directly in the emulator (I tested it with CCS64
and VICE) or can be converted (using another tool like 64copy) to other
common C64-archive-formats like D64.
c.) create a t64-archive, which includes all detected C64-files, offers a
directory-structure and is supported by nearly every emulator.
tape64 even accepts a formerly created tap-file as input, if you want to build
a t64-archive and have deleted the sample-file or if you downloaded tap's from
internet.
tape64 is now completely compatible with ANSI-C, so there are binaries for
Windows 9x/Windows NT and LINUX and it should be possible to build executables
for other OS's.
Developing this software I was inspired by some two other tools I want to
mention here:
- 64Utilities by Tomaz Kac,
which include some very powerful tools to convert between voc-, tap- and tzx-
format (an archive format better known in ZX-Spectrum-emulation). It supports
many loaders but only voc's as sample-files, which is not supported by my
recording software. Great documentation of many common loaders. I'll use this
to improve tape64.
- TurboTapeLoader V1.2 by Sami Silaste,
which extracts binaries saved with TurboTape, but didn't work well with my
tape-recordings and takes much time (I think, Borland's I/O-Routines are very
slow). This tool gave me the idea for the extraction-functionallity of tape64.
(Thank you Sami for helping me with the Turbo-Tape specifications. The postcard
is on its way ;-)
There are some other tools like tapload or mtap which read the data directly
from the datasette and also produce taps.
2. Copyright
------------
tape64 is freeware. Everybody who likes and uses it may give me feedback by
email to This email address is being protected from spambots. You need JavaScript enabled to view it. or may send a postcard (also an idea of
Sami Silaste) to Andreas Matthies, Spitzenkamp 48, 24149 Kiel, Germany.
3. Instructions
---------------
tape64 is a commandline utility; syntax is the following
tape64 -i: [options]
is the name of
- a sample-file of a recorded C64-tape. It should be a wav-file in uncompressed
PCM-format with 1 or 2 channels (mono/stereo), 8 or 16 bit resolution and
a sample rate of at least 22050Hz, better 44100Hz or 48000Hz.
If the sample-file isn't a wav, it is assumed to be an 8-bit-mono-sample;
default sample rate is 44100Hz and can be changed with option -f (see there)
The recording level should be high enough to ensure a high sample amplitude,
but should be low enough to prevent clipping samples which are too high.
If samples vary between 50 to 200 in most parts of the file, tape64 probably
will make a good job. Although stereo-samples are supported I recommend to
record mono-samples by connecting only one channel from the tape-player to
the soundcard.
or
- a tap-file (created in a former run or downloaded from one of the C64-sites)
[options] can be one or more of the follwing:
-f:
is used to specify the sample-rate of the inputfile. Default is the
information in the wav-header, or 44100 if the inputfile is a non-wav-sample.
-t:
tape64 has to decide if a minimum/maximum in the samplefile is caused by a
trigger of the C2N to store an information or is only an unexact sample
caused by a low quality soundcard, an old tape or something like that. The
is the lower bound for the difference of a wave-minimum and
following maximum identified as a C2N-trigger.
Default is 10. Try to vary this parameter, if your prg's are not
recognized correctly. Some of my tapes even needed a of -t:2 to get
best results, others loaded best with -t:90, so you may have to experiment a
little.
-r
Some soundcards seem to reverse the incoming signal, which makes it difficult
to decode them. With this parameter the samplefile is (re-)reverted. Try it
if you get bad results without.
-v0:
You can use this parameter, when your is a tap in format-version 0
and you want to transform it into a tap of version 1 (see parameter -or). A
value 0 in your is seen as a delay of milliseconds, the
default is 100 ~ 0.1s. Use a high value, when your emulator has problems
with taps in version 0 (For example VICE1.0 delays for 20ms which is too short
for some taps)
-or[:]
creates a tap-file. The tap-format is now version 1 (see CCS64-docu for more
information), cause there were some problems with version 0 when the
emulation needs longer delays between the files.
If the is omitted, file is named as the inputfile.
".tap"-extension is appended automatically. If the inputfile is also a tap,
this option creates a copy of the inputfile, and "(copy)" is appended to
prevent equal names.
-ot[:]
creates a t64-file, which contains all successfully loaded C64-files. If
is omitted, the default name is like the inputfile.The ".t64"-
extension is appended automatically.
-op[:]
creates the binaries of the successfully loaded C64-files.The binaries are
named like the corresponding C64-files with extension ".p00". See option -n
for informations about numerating the extensions.
Use to specify the directory for the binaries. must exist
and end with a \ (or / in a UNIX envirenment). You can also specify a common
prefix for the binaries, for example -op:c:\mydir\tape1 will create all
binaries with the prefix "tape1" in the directory c:\mydir\
if : is omitted, the binaries are created in current directory.
-n
numerates the binaries like boulder dash.p00, donkey kong.p01, pitstop.p02 to
preserve the order of the C64-files on the tape. For sure this option only
makes sence with the -op.
-y
forces tape64 to overwrite files without question. Without -y you are asked
whether an already existing file can be overwritten.
-e
With this parameter even the "bad" files which caused a load-error will be
saved in the t64-archive/p00-directory. If the load-error was caused only by
a few bad triggers you may use the corrupted file.
-s:
Some inputfiles may have a kind of speed-problem caused by the tape, the
tape-player or the recording software, so that the resulting values of the
tap are too small or too big. To (de)accelerate the tape you may use this
parameter. A -value bigger than 1.0 makes the tape slower (the values
of the taps bigger), lower values make it faster (smaller tap-values).
Default is 1.0 of course.
Note: The option -v isn't supported since V1.10. tape64 is alway verbose now.
4. Example
----------
This is the screen-output of an example-run to illustrate how tape64 works.
A C64-tape is recorded and saved as a1.wav, then tape64 analyses it in verbose-
mode with triggeramplitude 30, creates a tap-file, at64-archive named
archive_a1 and binaries in subfolder \binaries_a1\ (which already exists).
[screenshot on]
D:\c64>tape64 -i:input8606.wav -t:30 -or -ot:i64_1 -op:\binaries\
searching... found(1) input 64 at 792- 2560 loading... successful
searching... found(2) ctexte at 12288-16538 loading... successful
searching... found(2) rahmen .com at 50240-53247 loading... successful
searching... found(2) titelbild at 2049- 6296 loading... successful
searching... found(2) I N P U T - A at 2049-13006 loading... successful
searching... found(2) S c h l a u m e at 2049-23816 loading... load error
[...some more prg's...]
searching... found(2) V o r s c h a u at 2049- 5827 loading... successful
searching... found(2) TTTTTTTTTTTTTTTT
reached end of tape.
Results of processing:
----------------------
Input: input8606.wav Type: Sample-File
Triggeramplitude : 30
Sample-Frequency : 48000
Sample-Range : 0 - 255
Channels : 1
Sample-direction : normal
Output:
TAP-File: input8606.tap
T64-File: i64_1.t64
P00's in: \binaries\
C2N-Triggers : 1173773
Programs loadable: 13
Programs with load error: 1
Last program didn't finish before end of input file
D:\c64>
[screenshot off]
One C64-file couldn't be loaded caused by a load error (bad checksum). In fact
all files are loaded correctly if I use the standard triggeramp of 10, here I
choose -t:30 for illustration.
The number following 'found' shows the loader-type, 0 is for Turbo-Tape, 1 is
original ROM-loader, 2 Supertape from input64.
The sequence of T's represents bad triggers which don't match the loader. You
also may get P's which represent parity-errors.
5. Speed
--------
Just a little word about speed. An example-run with a 30-minutes-tape recorded
in 8-bit-mono at 441000Hz took 131 seconds on my Pentium-100 with 48MB running
NT4. So recording the tape is the main thing you have to spend time for.
6. FAQ (not really F but AQ ;-)
-------------------------------
Q: I recorded an old tape with a microphone holding next to the speaker of my
hifi-equipment, but I don't get any results. What's wrong?
A: The quality of a micro-recording is too bad for decoding with tape64. You
must use a direct connection from line-out of your tape-deck to line-in of
the soundcard.
Q: I recorded a tape with 16-bit-stereo, but the decoding-results of tape64 are
very bad, nearly 70% load-errors or even files not found. What can I do to
improve the results?
A: It is highly recommended to use mono-recordings. Using a stereo-recording
tape64 mixes the two channels into one. This may cause bad results when the
channels vary in level and are shifted.
Q: I configured my software to record in mono, but results are still bad. Any
idea to get better results?
A: You should use a real mono connection. So if you have a stereo tape-deck,
you should connect only one channel of line-out to your soundcard. Otherwise
this channel-mixing is still done by the soundcard or software.
Q: Can I use tape64 with a datasette directly connected to the parallel-port?
A: Not now. In fact I don't like hardware-connections since I crashed my C64
with a connection to the PC. Okay the datasette may be a little more robust,
maybe I'll try this in the future. I think there are some other tools that
support this kind of connection.
Q: tape64 loaded every file of my sample successfully but the tap-output doesn't
run well in my emulator. Is tape64 better than the original loading-routine?
A: No, probably not. It may be a problem with the unexact representation of
longer delays in taps of format 0. Since release 1.12 tape64 always uses
format-version 1 in output-taps to prevent these problems.
7. What comes next
------------------
I hope you keep on giving me some feedback to improve tape64. Next thing is to
implement more loaders, I think that the infomations and tools of Tomaz Kac will
help me a lot to do this.
Next thing may be a kind of debug mode to analyse problems with the tape.
Another plan is online-decoding with reading input directly from the soundcard.
8. I'm still sorry for my bad english...
----------------------------------------
