tape64 V1.20 ============ by Andreas Matthies, 07/09/99 Please send feedback and bug-reports to andreas.matthies@gmx.net 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 DOS, 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-function of tape64. ============ by Andreas Matthies, 07/09/99 Please send feedback and bug-reports to andreas.matthies@gmx.net 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 DOS, 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-functionality 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 andreas.matthies@arcormail.de 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... ----------------------------------------lity 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 andreas.matthies@arcormail.de 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... ----------------------------------------