Cassette Routines
Kimm...@gmail.com
1) Who wrote the Cassette routines for the PETs (and C64)
2) Why did Jim Butterfield refer to the Read Tape Bits routines as
obscure
3) Why are the Cassette routines considered to be sloppily written or
could be written in half the space or is a mess of a routine to read
through?
Anyone with any information or a commented dissassembly of the Tape
Routines would be appreciated.
I am actually after 25 years going to delve into the Cassette routines.
Any advice or suggestions?
Fabrizio Gennari
> 3) Why are the Cassette routines considered to be sloppily written or
> could be written in half the space or is a mess of a routine to read
> through?
>
Also, they do something VERY stupid: they record a program twice (so it
takes double time to load), yet they give a load error if only one copy
is damaged. This means that the reliability is actually HALVED! Which is
the opposite of what redundancy is supposed to achieve.
The most famous turbo loading, Turbo Tape 64, achieves 10 times faster
loading by very simple tricks:
- no sync bit for every byte. Since tape loading is synchronous, there
is no point in having one. Having one reduces reliability (again)
- no double copy of a program
- 1 pulse=1 bit (in kernal routines, 2 pulses=1 bit)
- no parity bit at every byte, only final checksum can detect load errors
BlackJack
> Also, they do something VERY stupid: they record a program twice (so it
> takes double time to load), yet they give a load error if only one copy
> is damaged. This means that the reliability is actually HALVED! Which is
> the opposite of what redundancy is supposed to achieve.
Why is reliability halved? With that two copies you have at least the
chance to know there's something wrong. With one copy you read corrupted
information without knowing it.
> The most famous turbo loading, Turbo Tape 64, achieves 10 times faster
> loading by very simple tricks:
> - no sync bit for every byte. Since tape loading is synchronous, there
> is no point in having one.
But have to get in sync somehow and make sure you stay in sync. At every
byte might be overkill but it should be done from time to time.
> Having one reduces reliability (again)
How?
Ciao,
Marc 'BlackJack' Rintsch
Fabrizio Gennari
> On Sun, 05 Nov 2006 11:23:30 +0100, Fabrizio Gennari wrote:
>
Cyclic redundancy codes store information in more than one copy, so it
becomes more resistant to errors. Easiest example is (3,1) Hamming code:
you want to transmit one byte, you transmit it 3 times. When receiving,
you decide for the byte you receive at least 2 times. This means that,
if 1 bit out of 3 is received wrong, you can correct the error. This is
the "good" redundancy.
If you have a tape, and you damage it in one point, you damage only one
copy of the two stored, and the other is intact, yet any attempt of
loading it will cause load error. "Halved" means: you damage only one
copy, you make BOTH unusable.
If there was an easy method to recover a whole kernal-loader program
from a single copy, you would have been right. In fact, only a hacker
can do that. The normal user is screwed.
Nowadays you have the TAP format, which is relatively easy to
manipulate. In the C64 days, there was nothing.
> With that two copies you have at least the
> chance to know there's something wrong.
This could be a point. But the parity check at EVERY byte and the
checksum are more than enough to detect that there's something wrong.
And knowing that something is wrong is different than correcting it. The
method used by kernal loader doubles the chance to detect that there's
something wrong, and at the same time doubles the chances of having
something wrong in the first time. And, unlike error-correcting codes,
it does nothing to correct the errors.
> With one copy you read corrupted
> information without knowing it.
See above: checksum and parity bit at every byte make you know there's
something wrong anyway.
> But have to get in sync somehow and make sure you stay in sync. At every
> byte might be overkill but it should be done from time to time.
True in asynchronous transmission, where transmitter and receiver use
different clocks for detecting bit duration. False in C64 tapes, and in
general in synchronous communications: each byte sent by the datassette
causes an interrupt in the C64, and therefore re-synchronisation.
You could have a point: if the C64 misses an interrupt for some reason,
a sync pulse helps you detect the error immediately. If you only have
checksum, you first load everything then detect that the checksum is wrong.
>> Having one reduces reliability (again)
>
> How?
Again: you transmit more bits, there is more possibility you transmit
wrong bits.
Kimm...@gmail.com
Excellent posts guys, THANK YOU!
Keep them coming! Very delicious technical reads.
But could someone answer the first two questions?
And why did Commodore never improve on the cassette routines like they
did the DOS and other routines?
Also, has anyone actually gone through and commented the READ TAPE BITS
routine?
Even after almost 30 years, the official PET firmware site has almost
no comments and there are still '?' in some places..... can't SOMEONE
figure it out by now? WHO wrote the original damn thing and can't he
be contacted for all the details?
CHEERS!
Gil
Tom Lake
> did the DOS and other routines?
That one's simple. The price of disk drives plummeted so fast, that
cassette
storage was left behind by almost everyone. There was no incentive to
fix something that was so obviously destined to be extinct soon.
IBM included a cassette interface in their first PC but it was dropped
with the very next model, the XT, since very few people actually used it.
They brought it back temporarily in the PC Jr but no one used it with
that machine either.
Tom Lake
Kimm...@gmail.com
But Tom, Commodore went thru a zillion Firmware upgrades and
updates...1.0, 2.0, 4.0 etc....and this was around in the C64 as well
so we are talking easily 10-20 years, yet not an upgrade.
Fabrizio Gennari
>> Anyone with any information or a commented dissassembly of the Tape
>> Routines would be appreciated.
>>
A starting point is http://www.tkk.fi/Misc/cbm/docs/c64-diss.html
Start from F4A5, which is the entry point for the LOAD command, and get
to where data are loaded from tape (the LOAD routine is shared between
tape and disk)
Oenone
> That one's simple. The price of disk drives plummeted so fast, that
> cassette storage was left behind by almost everyone.
That may be true for the USA, but cassette storage stayed hugely popular in
the UK and presumably Europe too...
--
(O)enone
BlackJack
> BlackJack ha scritto:
>> On Sun, 05 Nov 2006 11:23:30 +0100, Fabrizio Gennari wrote:
>>
>> Why is reliability halved?
>
> Cyclic redundancy codes store information in more than one copy, so it
> becomes more resistant to errors. Easiest example is (3,1) Hamming code:
> you want to transmit one byte, you transmit it 3 times. When receiving,
> you decide for the byte you receive at least 2 times. This means that,
> if 1 bit out of 3 is received wrong, you can correct the error. This is
> the "good" redundancy.
But you tripled the chance something goes wrong.
> If you have a tape, and you damage it in one point, you damage only one
> copy of the two stored, and the other is intact, yet any attempt of
> loading it will cause load error. "Halved" means: you damage only one
> copy, you make BOTH unusable.
The routines are really a mess but I had the impression from the
commented ROM listing in “C64 Intern” published by Data Becker that up
to 31 corrupted bytes from copy #1 are replaced by bytes from copy #2
before the routine gives up.
>> With that two copies you have at least the chance to know there's
>> something wrong.
>
> This could be a point. But the parity check at EVERY byte and the
> checksum are more than enough to detect that there's something wrong.
> And knowing that something is wrong is different than correcting it. The
> method used by kernal loader doubles the chance to detect that there's
> something wrong, and at the same time doubles the chances of having
> something wrong in the first time. And, unlike error-correcting codes,
> it does nothing to correct the errors.
See above for the 31 possible corrections.
>> But have to get in sync somehow and make sure you stay in sync. At every
>> byte might be overkill but it should be done from time to time.
>
> True in asynchronous transmission, where transmitter and receiver use
> different clocks for detecting bit duration. False in C64 tapes, and in
> general in synchronous communications: each byte sent by the datassette
> causes an interrupt in the C64, and therefore re-synchronisation.
As I read the source every bit actually causes *two* interrupts, one for
each pulse.
> You could have a point: if the C64 misses an interrupt for some reason,
> a sync pulse helps you detect the error immediately. If you only have
> checksum, you first load everything then detect that the checksum is wrong.
With the byte sync you can identify every corrupt byte and replace it by a
good one from copy #2.
>>> Having one reduces reliability (again)
>>
>> How?
>
> Again: you transmit more bits, there is more possibility you transmit
> wrong bits.
Then we have different definitions of reliability. It's not only to get
the bits across but also to reliably tell when they are wrong. In my eyes
fewer bits with no chance to recognize an error is much more unreliable
than the little chance a parity bit gets corrupted.
Ciao,
Marc 'BlackJack' Rintsch
Kimm...@gmail.com
I know, I know, but there is no commenting.
I would have loved to see what the creator of the routine or SOMEONE
after all this time documenting the routine
Kimm...@gmail.com
Actually, I prefer
http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/d/petdis
$F976 Read Tape Bits
But still no documentation, lots of '?'
Who wrote this routine, Why no documentation, Why so much confusion
after all these years?
Groepaz
because the implementation is pretty braindead, and once you know the format
on tape you can easily implement it yourself (or another, better format) ?
--
http://www.hitmen-console.org
http://www.gc-linux.org/docs/yagcd.html
http://www.pokefinder.org
http://ftp.pokefinder.org
Es ist schon alles gesagt worden, nur noch nicht von jedem.
<Karl Valentin>
Kimm...@gmail.com
Why is the implementation braindead? Can you provide details?
Fabrizio Gennari
> On Sun, 05 Nov 2006 15:58:48 +0100, Fabrizio Gennari wrote:
>>
>> (3,1) Hamming code:
>> you want to transmit one byte, you transmit it 3 times. When receiving,
>> you decide for the byte you receive at least 2 times. This means that,
>> if 1 bit out of 3 is received wrong, you can correct the error. This is
>> the "good" redundancy.
>
> But you tripled the chance something goes wrong.
>
true: there is triple chance that at least one byte is wrong. But a
simple truth table will tell that the final result is right much more
often. If you transmit a bit, and the transmission goes wrong, the
result is wrong. If you transmit the bit 3 times:
- 1 bit transmission is wrong: you detect that there is an error, but
the error is corrected by the code
- 2 bit transmissions are wrong: you detect there is an error, and it is
not corrected
- 3 bit transmissions are wrong: you have an undetected error
If p is the probability of having a wrong bit, with plain communication
you have p probability to get an undetected error. With redundant
communication, you have p^3 probability to have an undetected error, and
3*p^2-3*p^3 probability to have an error detected but uncorrected. In
all other cases, you may have an error ("something goes wrong" according
to your definition) but you correct this (transmission is successful in
my definition). And p, being a probability, is between 0 and 1, so the
probability of successful transmission increases.
>
> The routines are really a mess but I had the impression from the
> commented ROM listing in “C64 Intern” published by Data Becker that up
> to 31 corrupted bytes from copy #1 are replaced by bytes from copy #2
> before the routine gives up.
>
If this is the case, you have a point. You detect a byte is wrong in
copy #1 (through parity check) and right in copy #2 (again through
parity check), so the byte in copy 2 can replace the one in copy #1.
This actually improves reliability
carlm...@hotmail.com
Hmm, I don't understood why people would write a disassembly that
doesn't assemble with a standard assembler, so you can verify that they
binary compare as equal (and tweak perhaps). Is there not an assembler
friendly (commented) version of the kernal and basic by now?
Groepaz
> Why is the implementation braindead? Can you provide details?
no. last time i looked at them was about 20 years ago, and i don't regret it
=)
--
http://www.hitmen-console.org
http://www.gc-linux.org/docs/yagcd.html
http://www.pokefinder.org
http://ftp.pokefinder.org
Physics is like sex: sure, it may give some practical results, but that's
not why we do it.
<Richard Feynman>
Kimm...@gmail.com
After almost 30 years, NOBODY has commented cassette routines?
And I am not talking about those garbage ones they have over at
http://www.zimmers.net/anonftp/pub/cbm/
There HAS to be someone who knows how the routines were put together
and how they work?
Gil
Fabrizio Gennari
> After almost 30 years, NOBODY has commented cassette routines? [...]
> There HAS to be someone who knows how the routines were put together
> and how they work?
>
Yes, the inventors.
The kernal routines are so complicated that nobody wants to have to do
with them.
There is some interest around tape loaders. Most people hang around the
forum at http://tapes.c64.no . Look especially for tce, a veritable
expert. Also check out http://coder.myby.co.uk : the maintainer has
analysed a lot of routines (don't know if the kernal routine is among
those, but many common turbo loaders have no secrets for him).
Kimm...@gmail.com
Thank you.
Why do you view the kernal routines as 'so complicated'?
What especially is the hard part for you?
Groepaz
> Why do you view the kernal routines as 'so complicated'?
> What especially is the hard part for you?
they suffer from the typical problem that many software has that "evolved"
rather than it was "designed" - in many parts its a giant hack. and like
said before, the tape format is simple enough (and well known) that
everyone with a bit of experience could reimplement it himself, so there
wasnt ever a good reason to dig through all the mess in the kernal.
--
http://www.hitmen-console.org
http://www.gc-linux.org/docs/yagcd.html
http://www.pokefinder.org
http://ftp.pokefinder.org
Man who stands on toilet is high on pot.
Anssi Saari
> There HAS to be someone who knows how the routines were put together
> and how they work?
Well, based on Brian Bagnall's book, it was Chuck Peddle who wrote the
original tape code for the PET and didn't comment it. Robert Russell
worked on that code with Peddle for the VIC-20.
So, ask them. Otherwise, why not figure this out for yourself? You
could become the only person alive to have thorough knowledge of the
cassette routines. Untold fame and glory is yours for the taking, so
go for it.
Fabrizio Gennari
> said before, the tape format is simple enough (and well known) that
> everyone with a bit of experience could reimplement it himself, so there
> wasnt ever a good reason to dig through all the mess in the kernal.
>
some results in
http://www.geocities.com/SiliconValley/Platform/8224/c64tape/). But with
the kernal one, I found the existing descriptions of the format complete
enough to understand the format itself, and decode TAP and WAV files, so
hacking the routine was not necessary. I did attempt, but it is really
horrendous compared to the relative simplicity of most other routines.