Mixing
How did the C64 interface tape drives?
How did the C64 interface tape drives?
I'm aware that the external interface was basically a audio input - but how was this audio converted into digital data, and how was it loaded into RAM and executed?
Basically what I am asking is how the computer handled the audio, as it entered the machine. How was it digitized, and how was this transferred to RAM?
commodore-64 cassette-tape
asked Jan 19 at 19:17
vidarlovidarlo
1335
add a comment |
How did the C64 interface tape drives?
I'm aware that the external interface was basically a audio input - but how was this audio converted into digital data, and how was it loaded into RAM and executed?
Basically what I am asking is how the computer handled the audio, as it entered the machine. How was it digitized, and how was this transferred to RAM?
commodore-64 cassette-tape
asked Jan 19 at 19:17
vidarlovidarlo
1335
Hi vidarlo, and welcome to the site! This question is extremely broad, and so is gathering close votes. I'd encourage you to see if you can narrow the question down a bit. For example, are you asking about how the computer formatted the data on the tape, or are you asking about how to use the BASIC prompt?
– Wilson
Jan 19 at 20:57
Sorry! I believed the question to be fairly specific. I will edit it :)
– vidarlo
Jan 19 at 20:57
@vidarlo Yeah; it's clear and specific now. Thanks for the question! I'm interested to see what the answer is.
– wizzwizz4♦
Jan 19 at 22:05
Um, "poorly" and "slowly". Sigh.
– Ed Grimm
Jan 22 at 4:34
add a comment |
How did the C64 interface tape drives?
I'm aware that the external interface was basically a audio input - but how was this audio converted into digital data, and how was it loaded into RAM and executed?
Basically what I am asking is how the computer handled the audio, as it entered the machine. How was it digitized, and how was this transferred to RAM?
commodore-64 cassette-tape
asked Jan 19 at 19:17
vidarlovidarlo
1335
How did the C64 interface tape drives?
I'm aware that the external interface was basically a audio input - but how was this audio converted into digital data, and how was it loaded into RAM and executed?
Basically what I am asking is how the computer handled the audio, as it entered the machine. How was it digitized, and how was this transferred to RAM?
commodore-64 cassette-tape
commodore-64 cassette-tape
asked Jan 19 at 19:17
vidarlovidarlo
1335
asked Jan 19 at 19:17
vidarlovidarlo
1335
edited Jan 19 at 20:58
vidarlo
asked Jan 19 at 19:17
vidarlovidarlo
1335
asked Jan 19 at 19:17
vidarlovidarlo
1335
asked Jan 19 at 19:17
vidarlovidarlo
1335
1335
Hi vidarlo, and welcome to the site! This question is extremely broad, and so is gathering close votes. I'd encourage you to see if you can narrow the question down a bit. For example, are you asking about how the computer formatted the data on the tape, or are you asking about how to use the BASIC prompt?
– Wilson
Jan 19 at 20:57
Sorry! I believed the question to be fairly specific. I will edit it :)
– vidarlo
Jan 19 at 20:57
@vidarlo Yeah; it's clear and specific now. Thanks for the question! I'm interested to see what the answer is.
– wizzwizz4♦
Jan 19 at 22:05
Um, "poorly" and "slowly". Sigh.
– Ed Grimm
Jan 22 at 4:34
add a comment |
Hi vidarlo, and welcome to the site! This question is extremely broad, and so is gathering close votes. I'd encourage you to see if you can narrow the question down a bit. For example, are you asking about how the computer formatted the data on the tape, or are you asking about how to use the BASIC prompt?
– Wilson
Jan 19 at 20:57
Sorry! I believed the question to be fairly specific. I will edit it :)
– vidarlo
Jan 19 at 20:57
@vidarlo Yeah; it's clear and specific now. Thanks for the question! I'm interested to see what the answer is.
– wizzwizz4♦
Jan 19 at 22:05
Um, "poorly" and "slowly". Sigh.
– Ed Grimm
Jan 22 at 4:34
Hi vidarlo, and welcome to the site! This question is extremely broad, and so is gathering close votes. I'd encourage you to see if you can narrow the question down a bit. For example, are you asking about how the computer formatted the data on the tape, or are you asking about how to use the BASIC prompt?
– Wilson
Jan 19 at 20:57
Hi vidarlo, and welcome to the site! This question is extremely broad, and so is gathering close votes. I'd encourage you to see if you can narrow the question down a bit. For example, are you asking about how the computer formatted the data on the tape, or are you asking about how to use the BASIC prompt?
– Wilson
Jan 19 at 20:57
Sorry! I believed the question to be fairly specific. I will edit it :)
– vidarlo
Jan 19 at 20:57
Sorry! I believed the question to be fairly specific. I will edit it :)
– vidarlo
Jan 19 at 20:57
@vidarlo Yeah; it's clear and specific now. Thanks for the question! I'm interested to see what the answer is.
– wizzwizz4♦
Jan 19 at 22:05
@vidarlo Yeah; it's clear and specific now. Thanks for the question! I'm interested to see what the answer is.
– wizzwizz4♦
Jan 19 at 22:05
Um, "poorly" and "slowly". Sigh.
– Ed Grimm
Jan 22 at 4:34
Um, "poorly" and "slowly". Sigh.
– Ed Grimm
Jan 22 at 4:34
add a comment |
1 Answer
1
active
oldest
votes
The analogue audio is turned into a 1-bit signal — either high or low.
The machine then detects positive transitions, counting the amount of time between each. That allows them to be bucketed into one of three types:
- short, which are those closest to a 364 microseconds;
- long, which are those closest to 524 microseconds; and
- mark, which are 684 microseconds.
Each byte is preceded by a byte marker, which is a mark wave and a long wave.
From there onwards, 0s are stored as a short wave followed by a long wave, and 1s are stored as a long wave followed by a short wave, and each byte is completed by an odd parity bit.
So reading a byte is as simple as watching for a mark wave, then tracking the sequence of short and long waves, using the parity bit as confirmation.
All files are also preceded by periods of lead-in tone, which is just a prolonged period of short waves. The computer can use that section to calibrate itself to different tape speeds.
A complete program file then looks like:
- lead-in tone;
- 192 bytes of header;
- those bytes, repeated;
- the program data itself;
- the program data itself, repeated;
- 192 bytes of ending data; and
- those 192 bytes repeated.
Commodore used repeated data as a basic means of checking integrity; it's an outlier in this regard — other micros tend to do more intelligent things but the Commodore ROM just stores bytes directly to their intended destination on first run through, then checks them on the second.
answered Jan 19 at 22:07
TommyTommy
15k14174
With that close timing requirements, tape speeds appears like a crucial factor. Did different devices have close enough playback speed to read each others tapes successfully? Or did the calibration patterns take care of this?
– vidarlo
Jan 19 at 22:10
If the first copy of the data is bad, do they try to use the second copy?
– Tim Locke
Jan 20 at 0:00
1
@TimLocke, how do you tell that the first copy is bad? All you can tell is that the first and second copies don't match.
– Mark
Jan 20 at 1:21
@vidarlo: A casette player whose speed was off by enough to conflate those lengths would be completely unacceptable for playing back music. Making 524 μs into 684 μs or vice versa would shift the key of the music by almost a fourth and make the playing time noticeably longer or shorter.
– Henning Makholm
Jan 20 at 1:49
2
It is worth noting, though, that this encoding is fundamentally not "basically an audio input" since the binary level transitions need to be preserved. This could work because the C64 had a dedicated tape drive. If you instead had to depend on a random audio player procured by the user (which might introduce odd phase shifts of the signal components) this format wouldn't be reliable.
– Henning Makholm
Jan 20 at 2:16
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8826%2fhow-did-the-c64-interface-tape-drives%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The analogue audio is turned into a 1-bit signal — either high or low.
The machine then detects positive transitions, counting the amount of time between each. That allows them to be bucketed into one of three types:
- short, which are those closest to a 364 microseconds;
- long, which are those closest to 524 microseconds; and
- mark, which are 684 microseconds.
Each byte is preceded by a byte marker, which is a mark wave and a long wave.
From there onwards, 0s are stored as a short wave followed by a long wave, and 1s are stored as a long wave followed by a short wave, and each byte is completed by an odd parity bit.
So reading a byte is as simple as watching for a mark wave, then tracking the sequence of short and long waves, using the parity bit as confirmation.
All files are also preceded by periods of lead-in tone, which is just a prolonged period of short waves. The computer can use that section to calibrate itself to different tape speeds.
A complete program file then looks like:
- lead-in tone;
- 192 bytes of header;
- those bytes, repeated;
- the program data itself;
- the program data itself, repeated;
- 192 bytes of ending data; and
- those 192 bytes repeated.
Commodore used repeated data as a basic means of checking integrity; it's an outlier in this regard — other micros tend to do more intelligent things but the Commodore ROM just stores bytes directly to their intended destination on first run through, then checks them on the second.
answered Jan 19 at 22:07
TommyTommy
15k14174
With that close timing requirements, tape speeds appears like a crucial factor. Did different devices have close enough playback speed to read each others tapes successfully? Or did the calibration patterns take care of this?
– vidarlo
Jan 19 at 22:10
If the first copy of the data is bad, do they try to use the second copy?
– Tim Locke
Jan 20 at 0:00
1
@TimLocke, how do you tell that the first copy is bad? All you can tell is that the first and second copies don't match.
– Mark
Jan 20 at 1:21
@vidarlo: A casette player whose speed was off by enough to conflate those lengths would be completely unacceptable for playing back music. Making 524 μs into 684 μs or vice versa would shift the key of the music by almost a fourth and make the playing time noticeably longer or shorter.
– Henning Makholm
Jan 20 at 1:49
2
It is worth noting, though, that this encoding is fundamentally not "basically an audio input" since the binary level transitions need to be preserved. This could work because the C64 had a dedicated tape drive. If you instead had to depend on a random audio player procured by the user (which might introduce odd phase shifts of the signal components) this format wouldn't be reliable.
– Henning Makholm
Jan 20 at 2:16
|
show 1 more comment
The analogue audio is turned into a 1-bit signal — either high or low.
The machine then detects positive transitions, counting the amount of time between each. That allows them to be bucketed into one of three types:
- short, which are those closest to a 364 microseconds;
- long, which are those closest to 524 microseconds; and
- mark, which are 684 microseconds.
Each byte is preceded by a byte marker, which is a mark wave and a long wave.
From there onwards, 0s are stored as a short wave followed by a long wave, and 1s are stored as a long wave followed by a short wave, and each byte is completed by an odd parity bit.
So reading a byte is as simple as watching for a mark wave, then tracking the sequence of short and long waves, using the parity bit as confirmation.
All files are also preceded by periods of lead-in tone, which is just a prolonged period of short waves. The computer can use that section to calibrate itself to different tape speeds.
A complete program file then looks like:
- lead-in tone;
- 192 bytes of header;
- those bytes, repeated;
- the program data itself;
- the program data itself, repeated;
- 192 bytes of ending data; and
- those 192 bytes repeated.
Commodore used repeated data as a basic means of checking integrity; it's an outlier in this regard — other micros tend to do more intelligent things but the Commodore ROM just stores bytes directly to their intended destination on first run through, then checks them on the second.
answered Jan 19 at 22:07
TommyTommy
15k14174
With that close timing requirements, tape speeds appears like a crucial factor. Did different devices have close enough playback speed to read each others tapes successfully? Or did the calibration patterns take care of this?
– vidarlo
Jan 19 at 22:10
If the first copy of the data is bad, do they try to use the second copy?
– Tim Locke
Jan 20 at 0:00
1
@TimLocke, how do you tell that the first copy is bad? All you can tell is that the first and second copies don't match.
– Mark
Jan 20 at 1:21
@vidarlo: A casette player whose speed was off by enough to conflate those lengths would be completely unacceptable for playing back music. Making 524 μs into 684 μs or vice versa would shift the key of the music by almost a fourth and make the playing time noticeably longer or shorter.
– Henning Makholm
Jan 20 at 1:49
2
It is worth noting, though, that this encoding is fundamentally not "basically an audio input" since the binary level transitions need to be preserved. This could work because the C64 had a dedicated tape drive. If you instead had to depend on a random audio player procured by the user (which might introduce odd phase shifts of the signal components) this format wouldn't be reliable.
– Henning Makholm
Jan 20 at 2:16
|
show 1 more comment
The analogue audio is turned into a 1-bit signal — either high or low.
The machine then detects positive transitions, counting the amount of time between each. That allows them to be bucketed into one of three types:
- short, which are those closest to a 364 microseconds;
- long, which are those closest to 524 microseconds; and
- mark, which are 684 microseconds.
Each byte is preceded by a byte marker, which is a mark wave and a long wave.
From there onwards, 0s are stored as a short wave followed by a long wave, and 1s are stored as a long wave followed by a short wave, and each byte is completed by an odd parity bit.
So reading a byte is as simple as watching for a mark wave, then tracking the sequence of short and long waves, using the parity bit as confirmation.
All files are also preceded by periods of lead-in tone, which is just a prolonged period of short waves. The computer can use that section to calibrate itself to different tape speeds.
A complete program file then looks like:
- lead-in tone;
- 192 bytes of header;
- those bytes, repeated;
- the program data itself;
- the program data itself, repeated;
- 192 bytes of ending data; and
- those 192 bytes repeated.
Commodore used repeated data as a basic means of checking integrity; it's an outlier in this regard — other micros tend to do more intelligent things but the Commodore ROM just stores bytes directly to their intended destination on first run through, then checks them on the second.
answered Jan 19 at 22:07
TommyTommy
15k14174
The analogue audio is turned into a 1-bit signal — either high or low.
The machine then detects positive transitions, counting the amount of time between each. That allows them to be bucketed into one of three types:
- short, which are those closest to a 364 microseconds;
- long, which are those closest to 524 microseconds; and
- mark, which are 684 microseconds.
Each byte is preceded by a byte marker, which is a mark wave and a long wave.
From there onwards, 0s are stored as a short wave followed by a long wave, and 1s are stored as a long wave followed by a short wave, and each byte is completed by an odd parity bit.
So reading a byte is as simple as watching for a mark wave, then tracking the sequence of short and long waves, using the parity bit as confirmation.
All files are also preceded by periods of lead-in tone, which is just a prolonged period of short waves. The computer can use that section to calibrate itself to different tape speeds.
A complete program file then looks like:
- lead-in tone;
- 192 bytes of header;
- those bytes, repeated;
- the program data itself;
- the program data itself, repeated;
- 192 bytes of ending data; and
- those 192 bytes repeated.
Commodore used repeated data as a basic means of checking integrity; it's an outlier in this regard — other micros tend to do more intelligent things but the Commodore ROM just stores bytes directly to their intended destination on first run through, then checks them on the second.
answered Jan 19 at 22:07
TommyTommy
15k14174
answered Jan 19 at 22:07
TommyTommy
15k14174
answered Jan 19 at 22:07
TommyTommy
15k14174
answered Jan 19 at 22:07
TommyTommy
15k14174
15k14174
With that close timing requirements, tape speeds appears like a crucial factor. Did different devices have close enough playback speed to read each others tapes successfully? Or did the calibration patterns take care of this?
– vidarlo
Jan 19 at 22:10
If the first copy of the data is bad, do they try to use the second copy?
– Tim Locke
Jan 20 at 0:00
1
@TimLocke, how do you tell that the first copy is bad? All you can tell is that the first and second copies don't match.
– Mark
Jan 20 at 1:21
@vidarlo: A casette player whose speed was off by enough to conflate those lengths would be completely unacceptable for playing back music. Making 524 μs into 684 μs or vice versa would shift the key of the music by almost a fourth and make the playing time noticeably longer or shorter.
– Henning Makholm
Jan 20 at 1:49
2
It is worth noting, though, that this encoding is fundamentally not "basically an audio input" since the binary level transitions need to be preserved. This could work because the C64 had a dedicated tape drive. If you instead had to depend on a random audio player procured by the user (which might introduce odd phase shifts of the signal components) this format wouldn't be reliable.
– Henning Makholm
Jan 20 at 2:16
|
show 1 more comment
With that close timing requirements, tape speeds appears like a crucial factor. Did different devices have close enough playback speed to read each others tapes successfully? Or did the calibration patterns take care of this?
– vidarlo
Jan 19 at 22:10
If the first copy of the data is bad, do they try to use the second copy?
– Tim Locke
Jan 20 at 0:00
1
@TimLocke, how do you tell that the first copy is bad? All you can tell is that the first and second copies don't match.
– Mark
Jan 20 at 1:21
@vidarlo: A casette player whose speed was off by enough to conflate those lengths would be completely unacceptable for playing back music. Making 524 μs into 684 μs or vice versa would shift the key of the music by almost a fourth and make the playing time noticeably longer or shorter.
– Henning Makholm
Jan 20 at 1:49
2
It is worth noting, though, that this encoding is fundamentally not "basically an audio input" since the binary level transitions need to be preserved. This could work because the C64 had a dedicated tape drive. If you instead had to depend on a random audio player procured by the user (which might introduce odd phase shifts of the signal components) this format wouldn't be reliable.
– Henning Makholm
Jan 20 at 2:16
With that close timing requirements, tape speeds appears like a crucial factor. Did different devices have close enough playback speed to read each others tapes successfully? Or did the calibration patterns take care of this?
– vidarlo
Jan 19 at 22:10
With that close timing requirements, tape speeds appears like a crucial factor. Did different devices have close enough playback speed to read each others tapes successfully? Or did the calibration patterns take care of this?
– vidarlo
Jan 19 at 22:10
If the first copy of the data is bad, do they try to use the second copy?
– Tim Locke
Jan 20 at 0:00
If the first copy of the data is bad, do they try to use the second copy?
– Tim Locke
Jan 20 at 0:00
1
1
@TimLocke, how do you tell that the first copy is bad? All you can tell is that the first and second copies don't match.
– Mark
Jan 20 at 1:21
@TimLocke, how do you tell that the first copy is bad? All you can tell is that the first and second copies don't match.
– Mark
Jan 20 at 1:21
@vidarlo: A casette player whose speed was off by enough to conflate those lengths would be completely unacceptable for playing back music. Making 524 μs into 684 μs or vice versa would shift the key of the music by almost a fourth and make the playing time noticeably longer or shorter.
– Henning Makholm
Jan 20 at 1:49
@vidarlo: A casette player whose speed was off by enough to conflate those lengths would be completely unacceptable for playing back music. Making 524 μs into 684 μs or vice versa would shift the key of the music by almost a fourth and make the playing time noticeably longer or shorter.
– Henning Makholm
Jan 20 at 1:49
2
2
It is worth noting, though, that this encoding is fundamentally not "basically an audio input" since the binary level transitions need to be preserved. This could work because the C64 had a dedicated tape drive. If you instead had to depend on a random audio player procured by the user (which might introduce odd phase shifts of the signal components) this format wouldn't be reliable.
– Henning Makholm
Jan 20 at 2:16
It is worth noting, though, that this encoding is fundamentally not "basically an audio input" since the binary level transitions need to be preserved. This could work because the C64 had a dedicated tape drive. If you instead had to depend on a random audio player procured by the user (which might introduce odd phase shifts of the signal components) this format wouldn't be reliable.
– Henning Makholm
Jan 20 at 2:16
|
show 1 more comment
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8826%2fhow-did-the-c64-interface-tape-drives%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Hi vidarlo, and welcome to the site! This question is extremely broad, and so is gathering close votes. I'd encourage you to see if you can narrow the question down a bit. For example, are you asking about how the computer formatted the data on the tape, or are you asking about how to use the BASIC prompt?
– Wilson
Jan 19 at 20:57
Sorry! I believed the question to be fairly specific. I will edit it :)
– vidarlo
Jan 19 at 20:57
@vidarlo Yeah; it's clear and specific now. Thanks for the question! I'm interested to see what the answer is.
– wizzwizz4♦
Jan 19 at 22:05
Um, "poorly" and "slowly". Sigh.
– Ed Grimm
Jan 22 at 4:34