How did the Cbm64/vic20 tapes work technically
arcade...@hotmail.com
the soundcard of a PC and then produce a .TAP file of it for use in
emulators, and for better preservation of the data.
There are a number of good such utilities, none of them could read my
old vic20 tapes that are (appatently) in a pretty bad shape.
I want to start this utility from scratch and dont use any assumtions
made in the available utilities, which dont do the job for me.
NOW. Can someone link me to information on how the information was
saved on Vic-20 (C64) tapes, preferably also how the hardware in vic-20
decoded it.
WhatI already know is that the information was frequecy modulated
(which freqs ?), and that the information had one paritybit per byte
and that the information was stored twice. I would need to know more.
Please cc an reply to my email adress.
Sent via Deja.com
http://www.deja.com/
Thomas Bätzler
>I want to write a utility that takes the sound from a vic-20 tape into
>the soundcard of a PC and then produce a .TAP file of it for use in
>emulators, and for better preservation of the data.
>
>There are a number of good such utilities, none of them could read my
>old vic20 tapes that are (appatently) in a pretty bad shape.
Hm. Why invent the wheel again? If your tapes are really in such a bad
shape, why do you think that you can do better on the conversion?
Just curious,
--
Thomas Bätzler, tho...@baetzler.de (home), tbae...@harbinger.de (work)
Humor Archive: http://baetzler.de/humor/, C64: http://baetzler.de/c64/
arcade...@hotmail.com
information even if terrible disturbed. I just need to know what to
look for.
The tape converters I have looked at are very rudimentary, and there is
a lot of improvement that can be done.
It seams the information on how the information was stored on the
tapes, which modulation for instance is well hidden...
In article <61vq6t07e5pj6ig0m...@4ax.com>,
Andreas Matthies
<arcade...@hotmail.com> schrieb im Newsbeitrag
news:94k0qc$nak$1...@nnrp1.deja.com...
> Being a signal processing specialist I do believe I can find the
> information even if terrible disturbed. I just need to know what to
> look for.
>
In short words: Search where the signal goes from "up" to "down". This event
triggers an interrupt in the CIA(VIA).
- Andreas
Markus Brenner
>I want to write a utility that takes the sound from a vic-20 tape into
>the soundcard of a PC and then produce a .TAP file of it for use in
>emulators, and for better preservation of the data.
>
>There are a number of good such utilities, none of them could read my
>old vic20 tapes that are (appatently) in a pretty bad shape.
Tape recording on the VIC-20 works pretty much the same as on the C64.
The only difference is the clock frequency:
C64_PAL: 985248 MHz (Cycles per second)
C64_NTSC: 1022727 MHz
VIC20PAL: 1108405 MHz
VIC20NTSC: 1022727 MHz
As the TAP format is always defined relative to the clock frequency (one TAP
unit is the time of 8 clock cycles on the machine), most of the TAP tools
around can't handle VIC20 PAL tapes as the VIC's clock frequency is somewhat
higher than C64's.
If you check out my own mtap, you will notice I actually implemented a command
line option for VIC-20 tapes:
http://arnold.c64.org/~minstrel/
So, actually you tapes are not that bad, but it's rather a fundamental issue
when transfering VIC-20 tapes with C64 TAP utilities that the resulting TAP
files won't work on VICE :)
>I want to start this utility from scratch and dont use any assumtions
>made in the available utilities, which dont do the job for me.
But the available utilities would use the same assumptions than you will, as
the principle isn't that complicated :)
>NOW. Can someone link me to information on how the information was
>saved on Vic-20 (C64) tapes, preferably also how the hardware in vic-20
>decoded it.
Well, I have written a document about this some time ago to help the YAPE
author implement TAP support in his Plus/4 emulator. I believe the information
is fairly correct, however there might be some flaws in there (I just wrote it
up and never proofread it). So read at your own risk :)
Proposal: Implementing TAP format on C16, C116, Plus/4 emulators.
========
(Markus Brenner, <mar...@brenner.de>)
BACKGROUND: Back in the 80s, software usually came on one of three data
storage mediums: Cartridges, 5.25" Floppy Discs and Cassette tapes. The
TAP format deals with archiving Cassette tapes in a digital, effective way,
maintaining 100% of the information stored on the original tape.
Per H†kan Sundell originally introduced the TAP format for his CCS64
emulator of the Commodore 64. The format has since been successfully
used for PET and VIC20 emulators, and can easily been adapted to
the TED/264 series of computers.
TECHNICAL INFO: A cassette recorder ("Datasette") uses normal magnetic
audio tape to store digital data. To be able to do this, the Datasette
uses some electronics hardware that 'translates' binary digits to
analogue sinus waves. '0' and '1' bits usually are discriminated by
the frequency of the sinus wave, or rather by the length of one complete
period of sinus wave: A '0' usually uses a shorter wave than a '1' bit.
On the tape, this looks something like this:
_____ ___
__--- ---__ _-- --_ _--
- -__ __- -_ _-
---_____--- --___--
|-------- long '1' wave ---------|--- short '0' pulse --|
The exact lengths of pulses varies with different loader (KERNAL ROM loader,
Turbo Tape, NOVALOAD). The TAP format deals with this by storing the actual
_length_ of a pulse: Each byte in a TAP file gives the length (in units
of processor cycles) of a pulse stored on tape.
The computer communicates with the datasette basically by two lines:
CST_READ and CST_WRITE. Both lines are directly wired to the 8501 CPU
processor port. If the computer writes a bit to tape, it actually writes
two half-waves:
1) toggle Write Line:
LDA $01
EOR #$02 ; (toggles write line)
STA $01
2) use the TED timer to wait one halfwave
3) toggle Write Line
LDA $01
EOR #$02
STA $01
3) use the TED timer to wait the second halwave (both halfwaves
have the same length)
Reading the cassette works similar:
1) wait for Read Line = 0
wait:
LDA $01
AND #$10
BNE wait:
2) start timer
3) wait for Read Line 0->1->0 transition
4) read out timer, and determine if it was a short or a long pulse.
FORMAT DESCRIPTION: (adapted from
http://www.computerbrains.com/tapformat.html)
0000 'C16-TAPE-RAW' ; Changed from 'C64-TAPE-RAW'
000C UBYTE Version
000D UBYTE Computer Platform (0 = C64, 1 = VIC-20, 2 = C16, Plus/4 etc)
000E UBYTE Video Standard (0 = PAL, 1 = NTSC1, 2=NTSC2)
000F UBYTE For future use...
0010 ULONG data length (Intel format LSB,MSB)
0014 UBYTE[] data
..
Version=0:
Each data byte represent the length of a pulse (the time until the c64's
hardware triggers again). The length is (8*data) cycles (PAL C64), i.e. the
data byte of 2F represent (47*8/985248) seconds. The data byte value of 00
represents overflow, any pulselength of more than 255*8 cycles.
Version=1:
As above but data value of 00 is now followed by three bytes, representing a
24 bit value of C64
cyles (NOT times 8). The order is as follow: 00 <bit0-7> <bit8-15> <bit16-24>.
Version=2:
As version 1, but each value represents a halfwave, starting with a
'0'->'1' transition. The time encoding doesn't change.
PLUS/4 IMPLEMENTATION HINTS: The TED timers always run with the slower
clock rate (886724 Hz for PAL machines (??)), so the length of one
TAP pulse should be relative to this frequency. A data byte of 2F represents
(47 * 8/886724) seconds for the TED machines.When playing back a TAP
on the Plus/4 emulator, you should write a routine that sets the CAS_READ
line to '0' for half of the time and '1' for the other half. This should be
easy to implement, as your emulator probably counts in units of clock
cycles anyway :) As for writing to a TAP file, you need to watch the CAS_WRITE
register (processor port, bit 0x02) and start counting whenever a 0->1
transition happens (I could be wrong with the polarity here, you need
to check this until you get reasonable TAP files).
References
----------
CCS64 Home Page:
http://www.computerbrains.com/ccs64/ (CCS64 home page)
Original TAP format specs:
http://www.computerbrains.com/tapformat.html (original TAP format specs)
Information on TED and timers:
http://www.geocities.com/SiliconValley/Screen/3676/Hardware/p4gfx.htm
System information by Marko M„kel„
http://www.hut.fi/Misc/cbm/cbm-msmakela.html#C16
arcade...@hotmail.com
with your mtap is that you need a functional datasette to use it, which
I have none.
For the utilities that dont use a datasette, that takes care of the
conversion from sinus to 1's and 0's, I still think there is possibly
to do some improvements, I can share my ideas so far if someone is
interested.
Two questions:
Have you used the redundancy that are in vic20/cbm tapes, that the
information is stored twice ? This gives the possibility to fix a byte
with parity error with the byte from the "verify" version stored
directly after on the tape. This should greatly improve a succesful
transfer.
I your doc you wrote that the information was stored as sine waves,
should it not really be cosine wawes, i.e. waves that start from zero
and grow to a maximum at the half wave time, and then fall back to zero
in the latter half wave ?
.. ..
Like this:. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
|-------------Long 1--------|--------short 0 -|
In article <94kj61$e287r$1...@ID-56208.news.dfncis.de>,
Markus Brenner
>Thank you very much for the documentation you provided. One problem
>with your mtap is that you need a functional datasette to use it, which
>I have none.
They are quite cheap to get on ebay. Using the 'WAV'->'TAP' doesn't produce
quite as good quality as most soundcards are limited to about 44kHz of
sampling frequency which isn't as good as the TAP format's resolution. That's
why I chose to use the original datasette equipment for mtap.
>For the utilities that dont use a datasette, that takes care of the
>conversion from sinus to 1's and 0's, I still think there is possibly
>to do some improvements, I can share my ideas so far if someone is
>interested.
Share and Enjoy! (Douglas Adams, The Hitchhiker's Guide to the Galaxy)
>Two questions:
>
>Have you used the redundancy that are in vic20/cbm tapes, that the
>information is stored twice ? This gives the possibility to fix a byte
>with parity error with the byte from the "verify" version stored
>directly after on the tape. This should greatly improve a succesful
>transfer.
Parity errors in ROM type loaders are very rare: The ROM loader uses _very_
different values for the pulse lengths and they rarely get read wrong. Of
course you are right, you could use the extra information to fix the TAP, but
I'd rather preserve the original state of the original tape and fix it
afterwards (say, when you are converting TAP to a simple PRG file, you usually
get two times the same PRG file, if not, you can always have a look at the
parity to determine which of the files has the correct information). In this
case, you can always turn the thing around and create a TAP file from the
(good) extracted PRG file, and thus get a 'perfect' TAP file.
In ordinary life, most of the tape loaders you will encounter are turbo
loaders (like Novaload, Cyberload, Flashload etc.) which save the
information only once and some of these even don't come with a checksum at
all! So relying on the checksum isn't very safe.
>I your doc you wrote that the information was stored as sine waves,
>should it not really be cosine wawes, i.e. waves that start from zero
>and grow to a maximum at the half wave time, and then fall back to zero
>in the latter half wave ?
Sine, cosine, for a physicist it's all the same, just different phase :)
Besides, there are usually a couple of waves at the start of the tape (or
individual blocks) that are there exactly for the purpose of getting a clean
signal, as the first waves sometimes don't have the full amplitude anyway.
Besides, in my school maths I learned that sin(0) = 0 and cos(0) = 1 :)
Hm, but I believe I see your problem:
In a complete wave, I meant 0 > 1 > 0 > -1 etc., the '1' and '-1' representing
different orientations of the magnetic field stored on tape ('N' and 'S'
respectively). The change of magnetic flux is recorded by the read head and
transformed to '0' and '1' halfpulses by the datasette electronics.
(BTW, while the C16 can actually read 'halfwaves', the C64 and VIC20 can't.
If the signal changes from 0 to 1 the C64 can trigger an interrupt. That's the
reason the C64 stores information always in full waves and doesn't need a
halfwave format as the C16 does for some turbo loaders)
cheers,
-markus
Martijn van Buul
> Sine, cosine, for a physicist it's all the same, just different phase :)
Real engineers use the real part of the complex e^(j*[omega]+phi)...
Then again, a mathematician will never use an approximation of Pi,
a civil engineer considers '3.14' to be a pretty good idea, some
architects find '3' to be good enough, while the Real Engineer
(namely, the Electrotechnical Engineer) thinks that it is in the
order of 10^0.
Real Engineers *never* use i.
--
Martijn van Buul - Pi...@dohd.org - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
Kees J. Bot: The sum of CPU power and user brain power is a constant.
Carlsson, Anders
> Then again, a mathematician will never use an approximation of Pi,
Those who want an approximation that is a real number can use 355/113.
At least six decimals correct.
--
Anders Carlsson
arcade...@hotmail.com
> They are quite cheap to get on ebay. Using the 'WAV'->'TAP' doesn't
produce
> quite as good quality as most soundcards are limited to about 44kHz
of
> sampling frequency which isn't as good as the TAP format's
resolution. That's
> why I chose to use the original datasette equipment for mtap.
Is that really a fact ? The last time I looked for a classy HIFI tape
recorder its bandwith was limited to below 20000Hz, and the last time I
bought a tape is was band limited even more. Further I believe that the
high frequences are the first to disappear from magnetic tapes. BTW is
ebay safe ?
I still think using the parity to fix incorrect bytes are a good idea,
for the original C64/VIC20 storage method. Were'nt there a parity bit
for each byte ? If so the extra information can be used to fix a single
byte that has a parity error, perhaps not neccesary when reading from a
datasette, but I think it can help the wav->tape readers a lot.
> Sine, cosine, for a physicist it's all the same, just different
phase :)
really :), and sorry about my clumsiness saying that cos(0) !=1
What confused me in your diagram was that I wanted a 1 from the vic to
produce a rising slope, and a zero to produce a decreasing slope, btw
is it at all sinus(cosinus) is'nt it rather a "lowpass filtered" step
function ?
In your decription you say (for writing) toggle writeline, wait T,
toggle eriteline.
As I have understood it T is dependent on if it is a 0 or a 1 we are
writing, if 1 T is bigger, the datasette cant know how big T is, and
thus cant produce two different sine waves, so I assume that it is
actually just sloping up or down the signal to the read/write head.
This also gives that the amplitude for a 0 is lower than for a 1.
Can you help me to reason this out ?
> Hm, but I believe I see your problem:
>
> In a complete wave, I meant 0 > 1 > 0 > -1 etc., the '1' and '-1'
representing
> different orientations of the magnetic field stored on tape ('N'
and 'S'
> respectively). The change of magnetic flux is recorded by the read
head and
> transformed to '0' and '1' halfpulses by the datasette electronics.
Ok, so it is the change in flux that transforms from 0 to 1, not at all
the level of flux, makes sense.
Well, thanks for the info, I will try to create a WAV->[0,1] converter
that can read any tape with any tapeplayer.
David Kinder
> information even if terrible disturbed. I just need to know what to
> look for.
I appreciate that you've probably already thought of this, but are you
connecting a stereo source to the mono input of the soundcard? I had a lot
of problems with converting some tapes, even though I could hear the audio
signal quite clearly. I was stuck until I sampled the tape in stereo and
had a look at the signal, and found with quite a few tapes the signal is
almost entirely on one channel or the other. Saving that channel as a mono
sample and running through the converter has never yet failed for me, even
on some quite battered tapes, made circa 1983.
David
Thomas Bätzler
[Minstrel:]
>> In ordinary life, most of the tape loaders you will encounter are
>> turbo loaders (like Novaload, Cyberload, Flashload etc.) which
>> save the information only once and some of these even don't
>> come with a checksum at all!
>> So relying on the checksum isn't very safe.
>I still think using the parity to fix incorrect bytes are a good idea,
I don't think that many people (and especially not Markus) would
disagree with you. His point is that you can't rely on a checksum
being present in all tape formats.
>for the original C64/VIC20 storage method. Were'nt there a parity bit
>for each byte ? If so the extra information can be used to fix a single
>byte that has a parity error, perhaps not neccesary when reading from a
>datasette, but I think it can help the wav->tape readers a lot.
Huh? With 1 bit you can detect single bit errors, but you certainly
can't fix 'em.
Cheers,
arcade...@hotmail.com
> Huh? With 1 bit you can detect single bit errors, but you certainly
> can't fix 'em.
In general no, but in the case of vic/cbm64 original tapes, the data
information is stored twice, so you have two copies of the data to work
with. If byte X in dataset 1 has a parity error, but byte X in dataset
2 has not, well use byte X from dataset 2. Do this for every byte that
has a parity error, and you have "fixed" all bytes with error.
Can someone confirm that there is a parity bit for each byte stored on
the tape?
Martijn van Buul
> > Huh? With 1 bit you can detect single bit errors, but you certainly
> > can't fix 'em.
>
> In general no, but in the case of vic/cbm64 original tapes, the data
> information is stored twice, so you have two copies of the data to work
> with. If byte X in dataset 1 has a parity error, but byte X in dataset
> 2 has not, well use byte X from dataset 2. Do this for every byte that
> has a parity error, and you have "fixed" all bytes with error.
This sounds like a generally good idea, but it has one catch: How can
you be certain that the parity bit is correct? (if there is such a thing, I
don't recall it) (Then again, I never really delved into the technical details
of the tapedrive) The chance that a parity bit is faulty is just as big
as the chance that any other bit is at err. Granted, the chance that
there is _a wrong bit in the databyte_ is 8 times bigger than the chance
that the parity bit is wrong, but I don't think that it is a good idea to
rely on the parity.
Another issue is the observation that a wrong bit hardly ever comes alone.
You have a 50% chance that the wrong parity corrects itself in the next
bit..
If you really want to reconstruct your data, you *have* to use CRC checks
and all that.
ki...@my-deja.com
> This sounds like a generally good idea, but it has one catch: How can
> you be certain that the parity bit is correct? (if there is such a
thing, I
> don't recall it) (Then again, I never really delved into the
technical details
> of the tapedrive) The chance that a parity bit is faulty is just as
big
> as the chance that any other bit is at err. Granted, the chance that
> there is _a wrong bit in the databyte_ is 8 times bigger than the
chance
> that the parity bit is wrong, but I don't think that it is a good
idea to
> rely on the parity.
I am not sure there is a parity bit for each byte, can someone confirm
this ?
The byte parity will be wrong if any of the nine bits are wrong, 8 bits
+ parity. So when a parity error occurs the propability that the data
was correct and the parity bit was wrong is 1/9, but that is irrelevant.
IF there is a parity bit, and we got a parity error the converted .TAP
file would fail anyway.
> Another issue is the observation that a wrong bit hardly ever comes
alone.
> You have a 50% chance that the wrong parity corrects itself in the
next
> bit..
That is true, two errors in a byte would give correct parity, but I
dont think that is very likely, eighter way, the suggestion shall only
be used if a conversion fails, so nobody would loose anything, and it
might help in some cases. (It can be a switch in your favorite
conversion program).
Markus Brenner
>Can someone confirm that there is a parity bit for each byte stored on
>the tape?
Yes :)
The Byte parity counts the number of '0' bits in the byte and is initialized
to 1, so it's 1 for an even number of 0-Bits and 1 for an odd number of '1's.
There's also an EOR checksum (initialized to 0) over the whole data block.
(I'll answer the other post later, after having some more thought about the
bandwidth limitation you mentioned).
cheers,
-markus
ki...@my-deja.com
> There's also an EOR checksum (initialized to 0) over the whole data
block.
Ahh, even more redundancy...
I dont know how the EOR is calculated, but I once worked with a system
that hade a "block parity" as well as byte paritys, so it could do
error correcting like this:
00000000 0
00000100 1
00000011 1 <-parity error!
00000000 0
00000000 0
00000000 0
00000110 0 <-block parity, all columns shall have even parity.
So with this we know that the third line should be 00000010
Do you know how this checksum is calculated ? Perhaps it can be used
for correcting errors ?
Markus Brenner
>> There's also an EOR checksum (initialized to 0) over the whole data
>block.
>
>Ahh, even more redundancy...
>
>00000100 1
>00000011 1 <-parity error!
>00000000 0
>00000000 0
>00000000 0
>00000110 0 <-block parity, all columns shall have even parity.
>
>So with this we know that the third line should be 00000010
If there's only one bit of error, you're right.
>Do you know how this checksum is calculated ? Perhaps it can be used
>for correcting errors ?
Yes, like I wrote above, it's an EOR over all the bytes in the block. An
ordinary file usually has 4 blocks:
Header (Filename)
Header (Repeated)
Data (Program data)
Data (Repeated)
Each of these four blocks has an EOR checksum over all its data bytes
(resulting in an 8 bit checksum).
For further information please refer to '64loaders.txt', a document detailing
about a dozen of C64 loader types included with Tomaz Kac's 64tape utilities
(available from cia.c64.org under the tools section). As for the checksum, I
can send you the source code to 'Tapsplit', a little tool I wrote for
splitting apart multi-file TAP files. Tapsplit includes a ROM loader tracer
which analyzes the data and also checks for valid checksums.
cheers,
-markus
Fabrizio Gennari
> For further information please refer to '64loaders.txt', a document detailing
> about a dozen of C64 loader types included with Tomaz Kac's 64tape utilities
> (available from cia.c64.org under the tools section).
64loader.txt has not been updated for a long time. It would be nice to
open a new discussion about tape loaders. Therefore, I put some
documents about tape loaders (everything in 64loader.txt and some more)
and other tape-related info at
http://www.geocities.com/SiliconValley/Platform/8224/c64tape/ . If
anybody thinks (s)he can contribute to it, just write.
Bye
Fabrizio
Ben Castricum
"Fabrizio Gennari" <fabri...@tiscalinet.noitspam> wrote in message
news:3A72E5BC...@tiscalinet.noitspam...
>[...]
> Therefore, I put some
> documents about tape loaders (everything in 64loader.txt and some more)
> and other tape-related info at
> http://www.geocities.com/SiliconValley/Platform/8224/c64tape/ . If
> anybody thinks (s)he can contribute to it, just write.
Cool, but could you change my e-mail adres on that page to
hostm...@cia.c64.org ? I no longer work at Getronics ;)
Regards,
Ben
Markus Brenner
>64loader.txt has not been updated for a long time. It would be nice to
>open a new discussion about tape loaders. Therefore, I put some
>documents about tape loaders (everything in 64loader.txt and some more)
>and other tape-related info at
>http://www.geocities.com/SiliconValley/Platform/8224/c64tape/ . If
>anybody thinks (s)he can contribute to it, just write.
I'm a bit busy right now, but I'll check it out in the next weeks. I believe I
have some info for updates (like the byte-parity in the Kernal loader).
cheers,
-markus
ki...@my-deja.com
> I'm a bit busy right now, but I'll check it out in the next weeks. I
believe I
> have some info for updates (like the byte-parity in the Kernal
loader).
Very valuable information in compact form is found in this readme file,
I cant remember where I found it, but it was included in a utility
called C64save, and C64load
Written by Richard Storer < > 28-10-1999
Standard CBM encoding
----------------------
The Datassette stores data on tape as a series of square pulses of
varying
wavelength.
All CBM tape data used by different Commodore machines are 100%
compatible
with the exception of the C16/+4 which has its own slightly modified
version
of the original format not discussed in this documentation.
CBM encoding consists of three different pulses: Short, Medium and Long.
C64
S = 387.2æs or 2.583kHz
M = 536.4æs or 1.864kHz
L = 707.4æs or 1.414kHz
VIC 20
S = 313.4æs or 3.190kHz
M = 449.2æs or 2.226kHz
L = 593.4æs or 1.685kHz
PET
S = 358.7æs or 2.788kHz
M = 509.6æs or 1.962kHz
L = 677.2æs or 1.477kHz
C16/+4
S = 472.7æs or 2.116kHz
M = 955.4æs or 1.047kHz
L = 1852.2æs or 0.540kHz
(All timing data were collected from samples of different PAL tapes
and therefore maybe slightly inaccurate)
The three pulses when grouped together can be interpreted as,
L,M = new data
L,S = end of data
M,S = bit 1
S,M = bit 0
The tape encoding begins by a tape leader of several S pulses.
After the tape leader a new data marker L,M is written followed by the
byte,
the check bit, then another L,M.
The byte is written to tape as, bit0 .. bit7
The check bit is calculated by, 1 xor bit0 xor bit1 .... xor bit7
Example,
LM MS MS SM MS MS SM SM MS SM LM MS SM MS
1 1 0 1 1 0 0 1 0 . . .
10011011 = 155
Check bit = 0
When data has finished L,S + 77 S pulses are written followed by a
repeat
of the same data + L,S and 78 S pulses.
Data stored on tape is as follows,
10 second tape leader
ID + header block + check byte
ID + header block + check byte - repeated
Small gap
2 second tape leader
ID + program block + check byte
ID + program block + check byte - repeated
The ID consists of nine bytes and determines whether the tape data
contains the first block or repeated block.
First block ID = $89 $88 $87 $86 $86 $84 $83 $82 $81
Repeated block ID = $09 $08 $07 $06 $05 $04 $03 $02 $01
The check byte is calculated by, 0 xor all block data written to tape.
The header saved to tape consists of 192 bytes.
Header information:
offset|bytes used| information
-------+----------+---------------
0 | 1 | file type
1 | 2 | load address
3 | 2 | file size
5 | 16 | file name
21 | 171 | unused
File type:
1 - Basic file
2 - Data block (for a seq file)
3 - Fixed address file
4 - Seq file
5 - End of tape maker
Turbo Tape encoding
--------------------
Turbo Tape is a special type of signal encoding used by most commercial
games
to load and save data much faster than the standard method. To be able
to read
and write Turbo Tape data a custom written machine code program is
needed.
Turbo Tape encoding consists of two types of pulse data of varying
wavelength,
Hi pulse (H) and Low pulse (L). The actual wavelengths used for H and L
would
vary from Turbo Tape to Turbo Tape and the encoding method could vary
too.
The following Turbo Tape encoding described below is from a program
called
TURBOTAPE 64 which appeared in the COMPUTE! Gazette July 85.
Hi pulse (H) = 207.8æs or 4.811kHz
Low pulse (L) = 338.6æs or 2.953kHz
H pulses = bit 0
L pulses = bit 1
The bytes are written to tape as, bit0 .. bit7 and unlike CBM standard
encoding TURBOTAPE 64 doesn't include a check bit for each byte or does
it indicate a new byte.
Example,
HLLHLLLH -> 01110110 = 118
The tape encoding begins by a tape leader with the byte value $02
written 256
times (HHHHHHLH).
After the tape leader the following bytes are written,
$09, $08, $07, $06, $05, $04, $03, $02, $01,
Load address
End address
Program data
Check byte
HLLHHH pulses
The check byte is calculated by adding all bytes written for program
data.