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
Hi,
I need some information about the Commodore cassette storage format.
I want to salvage something from a damaged cassette, and I have a (rather
crummy) audio digitizer. I've spent a couple of hours staring at the signals
>from stored programs but I just don't 'get it'.
In the data portions, it appears as if every 20th wave is special, with
maximum amplitude and a smaller frequency. If these are synchronization
points, why does it appear to be at every 20th wave? Why not every 9th? Does
the format not care about bytes? Or is there some kind of error detection or
correction scheme taking up more bits?
There are about 200 of these 'synchronization waves' just in the header. The
machine-readable file I was looking at only has a three-character filename.
What data is normally stored in the header? Filename, load address, checksum
or CRC, etc?
It sounds like there are two identical copies of the header information. I
know that there are two copies of the actual file data.
How is the data actually stored? I expected to see square waves with
frequency modulation. IIRC, that's what the Apple does. The PET appears to
use sine waves (non-flattened) and I can't visually discern any frequency
differences in the data (at a sample rate of approx. 25,500 per second). A
lot of the data portion of the file I'm looking at looks like it is stored
with amplitude modulation, but I don't think that would make sense with such a
flaky thing as cassette tape. There are large amplitude "gulleys" here and
there in the file, yet the file I'm looking at loads properly.
(Of course, it sure SOUNDS like it's using frequency modulation. Perhaps I
should sample at a higher rate, and get out a ruler to measure the width of
the waves...)
Those 20 waves don't represent a single bit, do they? (Lessee... approx. 60
waves per 600 samples, 25,500 samples per second... that's 2,550 Hz, and 20
waves/bit = 127.5 bps, which isn't enough but is getting somewhat closer to
the numbers I'd expect. Maybe I'll answer some of my own questions with
another look at the samples.)
The damaged file that I want to salvage has had its header wiped out (someone
momentarily hit "RECORD"), but the data appears to be untouched. Is there a
way of getting the PET (or any other machine) to read the data without the
file header?
--
Doug Spence
ds_spenc(a)alcor.concordia.ca
http://alcor.concordia.ca/~ds_spenc/
Guys:
If you had a pile of impossibly dirty DEC Q-Bus boards,
what would you do? (This includes the usual disk controller card,
CPU/IO/Memory extender, a couple of corestacks, the backplane,
and the regulator card).
Jeff
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
Another item seeking a home... Replies to original poster please...
-jim
-----------
>Date: Sun, 09 May 1999 09:36:04 -0500
>From: FRedFritz <frederick.fritz(a)mankato.msus.edu>
>Reply-To: ffritz(a)mail.mankato.msus.edu
>X-Sender: "FRedFritz" <ffritz(a)mail.mankato.msus.edu> (Unverified)
>X-Mailer: Mozilla 4.06 [en]C-gatewaynet (Win98; I)
>To: jimw(a)agora.rdrop.com
>Subject: Kapro 2x available
>
>Dear Jim,
>
>I have a working Kapro 2x which I have just retired. I purchased it new
>in 1985. It is in mint condition and I have all the software and
>manuals that came with it. I would be delighted to find a "good home"
>for it with someone who would appreciate it. Fred Fritz
>
>ffritz(a)mail.mankato.msus.edu
---
jimw(a)computergarage.org
The Computer Garage - http://www.computergarage.org
Computer Garage Fax - (503) 646-0174
I have a Future Systems Inc. Model GTS-100 floppy drive for the
Atari ST series computers but I don't have the manuals, cables or
power supply. Does any one know specs on the power supply for
this drive so I can locate a replacement. I think I once heard that it
could use the same power supply as the Atari 5200 game system
but don't know for sure. Also, if anyone has a source for cables or
the strange 14 pin ST connector so I could make some cables,
please let me know.
Thanks.
-----
David Williams - Computer Packrat
dlw(a)trailingedge.com
http://www.trailingedge.com
Other than the core stack the first thing I do is the 120 lb air hose. It
cleans a lot of sins. At least lets you see what kind of mess you have.
(what was used for glue) Then Isopropyl, methanol, or some window cleaner
and a paint brush or soft well worn tooth brush and blasting it frequently
with air. Use an old towel to wipe the paint brush on to clean it between
strokes.
Be sure to wear safety glasses. Alcohol in the eyes is no fun.
Dan
-----Original Message-----
From: jeff.kaneko(a)juno.com <jeff.kaneko(a)juno.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, May 10, 1999 10:30 PM
Subject: Board Cleaning Opinions Wanted
>Guys:
>
>If you had a pile of impossibly dirty DEC Q-Bus boards,
>what would you do? (This includes the usual disk controller card,
>CPU/IO/Memory extender, a couple of corestacks, the backplane,
>and the regulator card).
>
>Jeff
>
>___________________________________________________________________
>You don't need to buy Internet access to use free Internet e-mail.
>Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
>or call Juno at (800) 654-JUNO [654-5866]
>
>If you had a pile of impossibly dirty DEC Q-Bus boards,
>what would you do? (This includes the usual disk controller card,
>CPU/IO/Memory extender, a couple of corestacks, the backplane,
>and the regulator card).
For everything except the core stack, I wouldn't hesitate to run them
through the dishwasher and gently dry. The core stack should be treated
substantially more delicately.
If you want to see "impossibly dirty", you ought to see some 11/23's that
I was maintaining at a solar cell plant. Absolutely incredibly quantities
of incredibly fine aluminum dust over everything - in some cases built up
over a quarter inch thick - yet they kept on (for the most part) working.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
1) Can a TK70 drive read/write TK50 tapes? I'm looking for media for the
TK70 to test it and all I've found so far are TK50 tapes (or are they the
same tape?)
2) What termination requirements are there on DSSI disks? I powered up the
two RF71's and the KQSFA DSSI controller in the BA213, they spun up and the
ready lights were on but when UNIX probed the controller it saw only one
drive and when I tried to read that drive its FAULT light started flashing.
The cabinet is set up to connect the card to a ribbon cable that connects
both drives and then ends at a funky high density connector (looks a lot
like SCSI-2).
Thanks,
--Chuck McManis
That's right. In fact, I have the '81 data book on the floor right here.
The ICM7228 is apparently an 8-digit LED display multiplexer which was not
available in '81. I was hoping it was a different part, more like the CMOS
4534, which is a counter-display-driver. In any case, the information I got
>from the Harris site and the Maxim site, per a referral from someone in this
group, seems to correlate with my recollection, such as it is, of what these
devices are.
The 7226 is a 10 MHz frequency counter circuit with LED drivers built in. I
once hooked up the part in a 9-digit application using a fast CMOS BCD
counter as a prescaler rather than the ECL jewel they designed in their
app-note. That makes it almost useful, as it then counts up to 100 MHz in
several modes. Of course, you have to prescale both the inputs in order to
make it work right, but it's a handy little tool if you package it right.
That outrageously large board of Intersil's was pretty impractical except
for the purpose for which it was intended, which was to demostrate how their
porduct works. They didn't make it easy to up the count rate by a decade,
nor did they make signal routing in and out very handy. The switches they
used forced one to mount the board in a large box even though only a small
area was needed for the display and switches. Their eval kit for the 7106
DPM was about as impractical. It got us to buy them, though, didn't it?
Dick
-----Original Message-----
From: Joe <rigdonj(a)intellistar.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, May 10, 1999 3:02 PM
Subject: Re: manuals available
>Richard,
>
> I have a couple of old Intersil Evaluation kits and the manuals list all
>of the devices available in 1981 but don't list a 7228. Are you sure it's
>not a 7226? or else it's newer than 1981.
>
> Joe
>
>At 03:46 PM 5/8/99 -0600, you wrote:
>>I've run into Intersil's ICM7228 once again and find my data book doesn't
>>cover that number. It's date coded '87, so It's probably in the last book
I
>>got from Intersil before they were acquired by GE.
>>
>>Has anyone got a complete sheet on this part? I believe it is a
>>multi-decade counter/display driver, or maybe just a display driver.
>>
>>thanx
>>
>>Dick
>>
>>
>
