Here's a transcript of a converstation I had with Jim Butterfield about the
Commodore cassette format:
====================
#: 42513 S2/Programming (CIS:CBMAPP)
31-Jul-97 17:49:07
Sb: CBM programming info
Fm: Jim Butterfield 73624,14
To: Richard Cini/WUGNET 70153,3367
Replies: 0 TID: 8132 Par: 42485 Chd: 0 Sib: 0
> I seem to be missing some info on the following: info on the structure
of
> the tape header, and the equates for the "I/O Error#" messages (i.e., the
> descriptions behind the error numbers). Can anyone point me in the right
> direction on this?
Hoo-eee! You picked a dilly of a complex format to look at (and some heavy
code to read .. I swear that I could rewrite it into about half the ROM!).
Probably the best place to start is on page 97 of the Inner Space Anthology.
where there's some basic data by some guy called Butterfield:
Leader = 50 cycles of Shorts
Short = 182 microseconds half cycle or 2.75 Khz
Long = 262 microseconds half cycle or 1.91 KHz
Mark = 342 microseconds half cycle or 1.48 KHz
BYTE MARKER = Mark Mark Long Long
(What goes mark mark? A dog with a harelip. Oops, sorry, continuing..)
1-bit: Long Long Short Short
0-bit: Short Short Long Long
Data Byte = Byte marker, 8 1/0 bits, 1 1/0 odd-parity bit' about 9.02
milliseconds total.
Leader detail (I'm faking this one from memory); after the leader, there's
a countdown byte series from about 0F hex to 00 hex; on the "second" block,
the countdown is repeated with the high bit set, thus, 8F down to 80 hex.
Tape File Format:
Leader - header block - data block - possible end block. (All blocks
written twice).
Hope this gets you started.
--Jim
==================
#: 42554 S2/Programming (CIS:CBMAPP)
01-Aug-97 14:41:14
Sb: CBM programming info
Fm: Jim Butterfield 73624,14
To: Richard Cini/WUGNET 70153,3367
Replies: 0 TID: 8132 Par: 42522 Chd: 0 Sib: 0
> I guess that the "countdown blocks" really are some sort of
synchronization
> before the header block?
Yes. As I recall the code (it's been a while!), the reading program looks
for this stream; when it finds an identifiable countdown byte, it just
counts off the remaining characters until it gets to the data. It always
seemed a bit like overkill to me.
And when you get into the code itself, you'll find some quite obscure
stuff in there trying to synchronize with the tape speed (a sort of
self-correcting timing). Tough reading.
> I'd like to get my hands on the "Inner Space Anthology" book. Can you
help
> there??
Karl Hildon, the compiler of the anthology, recently reprinted a quantity,
with some C128 data added (the original anthology was published before the
128 arrived). I see his email address has been posted.
Since Karl republished using a copying machine (including a colour copies
for the cover), I believe he's asking about $20 for a copy. But check it
out directly with him. If for any reason you can't find him, come back to
me.
--Jim
==================
#: 42698 S2/Programming (CIS:CBMAPP)
08-Aug-97 12:07:27
Sb: CBM programming info
Fm: Jim Butterfield 73624,14
To: Richard Cini/WUGNET 70153,3367
Replies: 0 TID: 8132 Par: 42665 Chd: 0 Sib: 0
> Am I doing the math wrong??
You have me at a couple of disadvantage. It's been something like 18 years
since I picked apart the tape code, os it's nor fresh in my mind. To add to
my difficulties, I have a vision problem at the moment which hopefully will
be corrected by surgery in the fall ... but it makes it hard for me to do
detailed picking through listings.
Before I start sounding like I'm copping out, I will have some comments for
you that may explain at least part of the discrepancy. But first, a couple
more vague excuses: darned if I can remember where those timing numbers
came from after all this time; seems likely that I filched them from a
Commdore design spec, or someone measured them with a time base calibrated
scope. I tend to doubt that I sweated through counting microseconds. And
in this response, I should mention that my original investigations were on
the PET 2001, my snoop today was on the C128 (built-in monitor makes
exploring easier). And a caution to anyone with a Plus-4 or C-16 .. the
code (and tape format) is not the same for those two machines.
Here's the deal, I think:
All this stuff is running off an IRQ. The "last" think the tape routine
does is to set the timer ("last" is in quotes because there may be other IRQ
jobs done after the tape work).
BUT: after the timer is set, and the interrupt finally hits to signal
that the time has elapsed, it will be quite a few microseconds before the
tape routines will get to the point where they will set the timer again.
First, the IRQ goes though the ROM routine which stashes the registers.
Then, it does an indirect jump to the tape-write code; but it has to do
quite a bit of investigation before it gets around to setting up the timer
again. Even the timer routines you quote are within a subroutine, and of
course it takes time to make the call, set up the numbers, etc.
I might guess that the overhead taken to get to the "bit write" timer set
could be in the region of 86 machine cycles. Thus, a timer value of $B0 or
decimal 176 would actually generate a time of 176+86 machine cycles, or 262
cycles; a value of $60 or decimal 96 would produce 96+86 or 182 cycles.
(Works out so exactly that, gosh, maybe long ago I did painstakingly count
all the machine cycles .. if so, I've blissfully forgotten doing so).
In looking at the code, you'll note that the byte marker is detected
earlier in the interrupt sequence; I'll guess a delay or 70 (rather than 86)
to get to that timer sequence. This would generate $110 or 272 o the timer
producing an overall time of 272+70 or 342 machine cycles.
Now, about the clock actually running at 1.1082 MHz. The original PET
didn't have an interface to NTSC video, and the clock ran at precisely 1
MHz. So the calculation were correct during the ancient PET/CBM days; but it
appears Commodore didn't see any need to trimthe figures by 10% when they
changed the clock to match video frequencies. Never thought of that; but I
expect that it's true that machines from the VIC-20 onward wrote tape about
9% faster than the earlier machines. I wonder if they made any adjustment
for European machines, which likely had another clock frequency so as to be
PAL compatible.
Does the above sound like a plausible theory?
--Jim
p.s. The tape WRITE part is easy ... when you get to that read stuff, with
multiple timers going, it's gonna be real fun.
=================
[ Rich Cini/WUGNET
[ ClubWin!/CW7
[ MCP Windows 95/Windows Networking
[ Collector of "classic" computers
[
http://highgate.comm.sfu.ca/~rcini/classiccmp/
[
http://highgate.comm.sfu.ca/~rcini/pdp11/
<---------------------------- reply separator
Received on Sat May 08 1999 - 07:14:06 BST