Tags: tap

piggu

Converting Audio to TAP files.

Well I did some work yesterday on the preliminaries of converting audio back into TAP files, using a process of quantization and sample counts, which gives back the original pulse lengths from the audio data.

So far, so good, with an emulator able to reload a reference audio file that I converted back to TAP. I use VICE for Mac OS X, for testing, as it is a good all-round emulator. It also allows me to save programs to TAP files, which I can then convert through tapdancer and load into the real machine for testing.

The converter code is in its infancy, but seems to be usable.

April.
piggu

(no subject)

I started writing a more generic representation of a Tape file. It is needed for when I start the mamoth task of supporting the Spectrum TZX format. It is a great deal more complicated than the Commodore TAP format. But, by basing them off a common route class it will allow a more standardized interface for manipulating the files.
Each basically consists of a Header (of variable size and content), and a Data Block which contains the actual digital representation of tape signals.
TGenTapeFile is the top level container class.
piggu

Impossible Mission


Remember last post I was curious about how the encoding would handle finicky loaders that use a very short pulse width?

These files, typically games with "US Gold" block loaders (or NovaLoad) when encoded by another program (I won't name names), hadn't had much success loading, as at some arbitrary point, the computer finds a glitch on the tape, or misses a pulse, and then resets. Anyone who has ever had one on these tapes on a less-than-perfect datasette will know exactly what I am talking about.

I encoded "Impossible Mission" last night in a batch of test games (by accident funnily enough), and it loaded. As the block counter crept towards zero, I kept wondering if it was going to glitch somehow, and yet it didn't. The game loaded perfectly first time. Bearing in mind that this same game seems impossible to load on the same equipment encoded with another program, I am pretty happy with the results so far.

Probably next weekend I will think about starting to write the decoder which will actually convert the analog audio back into TAP files, as the conversion only works one way so far...

April.
piggu

It works...

I produced AU Files from TAPs that actually read properly into the real computer. There were some accuracy issues with the calculations that converted from TAP bytes to machine cycles to durations (in uS) and then finally to the number of samples needed per square wave. We converted about 20 TAP files and produced an audio CD, which we then loaded into the real machine by way of a CD cassette adaptor.

The interesting thing will be to see how it behaves when it comes to things like US Gold loaders, which use very compressed pulse widths in order to fast load off tape.

The next step will involve setting up DEV tools on our mac, installing freepascal there and then compiling a Mac PPC version.
piggu

About the commodore TAP format...

The TAP format was created for the Commodore 64 Emulator CCS64 (link) by Per Hakan Sundell, as a means of representing the audio pulses on a commodore tape. These pulses represent square waves, with a one to one mark spacing, which essentially means, that the pulse spends as much time "up", as it does "down".

A TAP file contains a simple header, followed by a series of bytes representing these pulse widths. These values represent the pulse widths in microseconds (millionths of a second), and are calculated by the following formula: -

TAP data byte = P(uS) * (1/1000000) * (F(Hz)/8)

Where P = length of pulse in microseconds, and F = PAL Frequency of the C64 (985248Hz).

Sometimes the measured pulses are longer than 255*8 machine cycles, and in that case, we instead encode a zero byte, followed by another byte (which represents the overflow). In the most recent version of the TAP format, we still use zero to flag overflow, by follow it with a 24 bit number (3 bytes) which gives the actual length of the long pulse in machine cycles.

The beauty of this format is that it preserves everything within it. Load a TAP file into an emulator, and you will see the original loading screens, music, and yes, if you run your emulator at 100% speed, it will take 5-6 minutes to load!

I guess just to finish here, I should document the actual TAP header format, as there are scarce few places where it is documented online: -

Offset        Size         Description
0             12 bytes     File ID. 'C64-TAPE-RAW'
12            1 byte       Version (0 or 1 so far)
13            3 bytes      Reserved for future use (usually zeros)
16            4 bytes      Data length (Longword - Intel endianess)