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 of 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 synchronization 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. help 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 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