Emulator Universe CD/emulatoruniversecd1998.iso/CPC/Utils/PC2Tape/REFRNCE.TXT

Text File | 1996-11-26 | 7.4 KB | 169 lines

How the CPC stores data on its tapes:
------------------------------------

 1. Introduction
 2. Higher Level
 3. Lower  Level



1. Introduction

This document was written by Pierre Guerrier, [e-mail].

It is intended to show how data is actually stored on a tape. It deals
with the analog structure of the tape signal, and not with the way you
can use the firmware to store and retrieve data on tapes.

The information here has been gathered from the firmware manual, from
a disassembly of the 6128 ROM and from observations on sampled sounds.
It has been used successfully in my program AIFFdec to translate audio
recordings into binary data. The source code of this program is also
available.

You can use this information if you want to write another AIFFdec, or
for whatever you want to do. But cannot be held liable for any damage
to your hardware or data that could arise from the use or misuse of
this document.

Another interesting source of information is the SOFT968 firmware
manual from Amstrad plc. It has been converted to HTML by Kevin Thacker
and should be available some day on the CPC guide. Kev's paper filled
some gaps and corrected some "experimental" measurements error in mine.



2. Higher Level

When a file is stored on a CPC tape, it is segmented in 2k *blocks*.
The last of these blocks can be shorter than 2k.
Each block is preceded by a 64 bytes *header*, containing useful info
like the file name and the block ordering. See its structure in the
CPC guide for instance (http://andercheran.aiind.upv.es/~amstrad).
It is not very complicated to understand. Just note that the "block
size" indicates the actual size of the forthcoming data block (2048
bytes at most).

Before each stream of data (block or header), there is a *leader*.
The leader is a stream of about 256 bytes of value &FF. This leader
is used to guess the recording speed of the file, by measuring the
duration of all the "1"s in it (see next section for details).
After the data stream, whatever is kind, you find a *trailer*, which
is 4 bytes of &FF.

Between the leader and the data stream, there is a *synchronization*
pattern, used to distinguish block and header streams. The pattern
consists of a single "0" bit followed by a byte, that is either &2C
(header) or &16 (block). Note that &2C is &16 shifted by one bit.
So if you really want to make the difference, what you need to count
is the number of "0"s between the last "1" in the leader and the
first "1" in the pattern.

Now if we look inside the data streams, we don't find only the user
data. There is also a Cyclic Redundancy Check system. It works by
cutting the stream into 256 bytes chunks (the last chunk is padded
to 256 with &00 bytes). After each chunk is appended a 16 bits CRC.
So actually a full 2k data block has 2060 bytes, 16 of which are
CRCs, lying every 258 bytes in the stream.

Here is a synopsys of one data stream (whatever kind) of length L.
  C = L/256  number of full chunks
  R = L%256  remainder

 bits   bytes    value      notes
 ----------------------------------
 2048    256      &FF      Leader
  1     0.125      0       Pattern delimiter
  8       1    &2C or &16  Sync Pattern (header or block)

(repeated for C+1 chunks)
 2048    256    variable   Chunk of User data (R or 256 valid bytes)
  16      2     variable   CRC for this chunk (including padding)

  32      4       &FF      Trailer


Algorithm for the CRC: although the implementation in the ROM is
pretty messy and unrecognizable, the CRC is actually a very usual
method using "primitive polynomials over the integers modulo 2".
The base polynomial is X^16+X^12+X^5+1 (it is the one recommended
by the CCITT and used in Xmodem, Kermit, X25... ).
The CRC seed is &FFFF and it is stored negated on the tape. No
other protocol is exactly identical, but all these features can be
seen somewhere else. The only unusual thing (for the CPC) is that
it is stored big-end-first. (Informations provided by Kevin Thacker
from the CPC firmware manual)
The CRC code in AIFF decoder comes from an algorithmics book. Rest
assured, I don't understand it myself, but the book says its just
a long division on polynomials.



2. Lower Level

Here we talk about the way the CPC stores single bits, and how it
makes the difference between a "0" and a "1". For a better under-
standing of this section, you should see by yourself what the
waveform looks like. The best is to use a sound card with audio
input ability and sample the output of the tape plug of your CPC
(or a CPC tape of course). Then run a sound editor and zoom in down
to the samples.

The aspect of the bits in the sampled sound the depends on:
  - the SPEED WRITE of the CPC (roughly 1200 or 2400 bps),
  - the sampling frequency of the digitized sound,
  - the electrical characteristics of the wires and tapes that where
    used for the transfer.
In the following, we will assume that the speed is 2400 bps (who wants
to be slower ?) and that the sampling frequency is 11kHz (who wants
bigger files ?).

The principle of the encoding could be pedantically called "frequency
modulation" or "pulse width modulation". The idea is to send a strobe
(low-high-low) signal, with one of two possible durations: short for
"0" and long for "1".
The exact parameters of the strobes can be set by a firmware call,
but trying non-standard values often results in an unreadable file,
so you can forget it (unless you want to do that kind of thing, like
for a protection...)
The leader before a data stream, provides the read-back routines in
the CPC with many sample "1"s so that the routines know what
parameters where used for recording.

Typical durations in microseconds are summarized here:

   time   frequency     note
  ---------------------------
   363     2750 Hz      "0" in SW1
   730     1375 Hz      "1" in SW1, "0" in SW0
  1500     680  Hz      "1" in SW0

The exact baud rate depends on the average number of "1"s in the user
data. The frequency spectrum of the sound also depends on the user
data, but if you want to safely digitize a SW1 file, you must have at
least 5.5k samples/second (Nyquist frequency) and preferably 11kHz to
include the first harmonic of the shortest strobes.

Now what does it look like ? Roughly, a "0" is an arch with 4 samples
and a "1" is an arch with 8 samples. Forget about the blabla above,
this is the only key to the translation.
We decide of the limit between two bits by looking for samples where
the signal falls below 0V (in the CPCTERM recording). Of course, if
your wires have reversed polarities, this won't work: try changing
the sign of all your samples.
Then it goes Low, High, Low (and as it goes low again, it falls under
0V and this is another bit). This is the strobe created by switching
the PIO bit. Check its length, you get a bit. All done.

Well, not that easily... Actually, "0"s are in a [3..5] window, with
some occasionnal 2-samples dwarves. And "1" are in a [6..9] window.
Plus a number of weird glitches that happen some times. In AIFFdec,
you will find a "filter" function that processes all this mess. Don't
ask me how it works, I still wonder myself. And it's been pretty hard
to tune.

I believe that the Sinclair range of computers had a very similar way
of storing bits on their tapes. I also know of a Spectrum emulator for
PowerPC which has built in tape emulation, but I don't know its
internals.