Re: 10x CLOAD (fwd)

From: Marko Mäkelä (
Date: 1999-10-07 09:23:58

On Wed, 6 Oct 1999 wrote:

> I know there are going bits out and there are comming bits in at the
> tape-connector for the simple fact that this connector is directly
> connected to the I/O-port of the 6510 (or equivalent).

Only some pins (I think SENSE (whether one of the tape keys is pressed)
and WRITE) are connected to the 6510.  READ only goes to -FLAG on one of
the CIAs (or CA1 on the VIC-20).

> Could anybody explain me shortly two things:
> 1) Is the data send to the recorder the same as the real data to be saved?

In principle yes, I think.  I haven't played much with the tape, but I
think that -FLAG is an edge-sensitive input, while the processor line you
use to control WRITE is level-sensitive.

> 2) How is the data translated to "music"?

The data is stored as a square wave (okay, it is more sinusoidal, but an
op-amp and a cutter in the read circuitry of the datassette make it look
like a square wave again).

> Then some comment on the (2*) 149 files (of 64K)/CD. Using the CD as data-CD 
> means 650M / 64K = +10.000 files. That is quite a difference, isn't it? 

Yes, but since CD-R disks are cheap nowadays, that'd still be less than
one US cent per file.

> Although I like the technical aspect of the idea, I'm afraid that
> there is no much practical use for it. Sorry.

I would have use for it on my PET, since I still haven't built the
IEEE-488 interface for one of my 1541 drives.

BTW, I counted the cycles yesterday night, and I noticed that the
byte-read routine must be unrolled.  Using 8:9 GCR instead of 4:5 GCR
would save the transmission time of one bit per byte, but then there would
not be any error detection (at least not in my routine), and the tables
would take 512 bytes instead of 64.  Storing the decoded byte in memory
and incrementing and comparing the pointer takes well over 25 cycles.  I
could make the whole byte-read loop in 245 cycles, which is 11 samples on
a PAL C64, but without any synchronization code, the loop would come out
of sync after some hundreds of bytes.  Wasting 2 samples per byte (using
12 samples per byte) should allow for synchronization.  And it'd still be
3675 bytes per second, or less than 18 seconds for 64 kilobytes.


This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail

Archive generated by hypermail 2.1.1.