[CSDb] - User Forums - Tape loaders using more than two pulse widths for data

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Tape loaders using more than two pulse widths for data

2018-12-08 20:16

ChristopherJam

Registered: Aug 2004
Posts: 1409

Tape loaders using more than two pulse widths for data

I’ve been thinking a bit about a novel tape encoding, but it would rely on (among other things) having more than two pulse widths. So far as I can see, none of the old turbo loaders used a long pulse for anything beyond end of byte/end of block - the bitstream itself was just a sequence of short and medium pulses (usually around 200 cycles for short, 300 to 450 for long).

Is there any particular reason none of the popular loaders used (eg) four pulse widths for each bitpair? Even using quite widely separated durations of 210/320/450/600 would then lead to an average time per bit of just 197 cycles, a massive improvement on the 265 cycles per bit you’d get for 210/320.

(The idea I’ve been working on is a bit more complex than that, but if a simple bitpair scheme wouldn’t work for some reason, then the idea I have would need to be scaled back somewhat. Promising that long pulses were used for framing, mind..)

... 23 posts hidden. Click here to view all posts....

2018-12-09 06:42

ChristopherJam

Registered: Aug 2004
Posts: 1409

tlr:

Yes, I was wondering about the transfer function. But on the other hand, the CBM standard loader uses long pulses of 688 cycles, and rainbow arts microload used short pulses of 200, so surely anything in that range should be pretty safe?

Thanks for the pointer to Blueload, I should investigate if I carry on any further.

2018-12-09 12:15

tlr

Registered: Sep 2003
Posts: 1790

Quote: tlr:

Yes, I was wondering about the transfer function. But on the other hand, the CBM standard loader uses long pulses of 688 cycles, and rainbow arts microload used short pulses of 200, so surely anything in that range should be pretty safe?

Thanks for the pointer to Blueload, I should investigate if I carry on any further.

I'm thinking there might be problems if you use both extremes in combination with some medium length pulses, but that needs to be measured.

With regards to multiple pulse lengths, Kabuto style encoding should be close to optimal for three different lengths. Think of those representing '1', '10' and '100' to get the idea. I use that representation for the standardish GCR in Blueload with timings being a multiple of the single '1'. An even more efficient way would be to "compress" the timing slightly, e.g use the original kernel timings.

2018-12-09 23:26

ChristopherJam

Registered: Aug 2004
Posts: 1409

Yes, a few days ago I was looking at assigning 'costs' of 1,2,3,4 (or 2,3,4,5) to four different pulse widths, then computing the tree of all possible codes of a given length. I suspect that's isomorphic to the Kabuto approach you've just mentioned.

I was just starting to think about how to store the tree, when I had a better idea.

The optimal usage of the codes happens when each code consumes an amount of time directly proportional to the number of bits of information it represents. Eg, for two pulses one of which is double the length of the other, the probability of the longer pulse appearing should be the square of the probability of the smaller.

Throw something like
solve 0.5^(210/r)+0.5^(320/r)+0.5^(450/r)+0.5^(600/r)=1 for r
at Wolfram Alpha or some such, and you get a theoretical efficiency of one bit per 178 cycles; 3% better than I could manage from the exhaustive tree approach.

( p per symbol = [0.442 0.288 0.174 0.097]
bits per symbol = [1.179 1.797 2.527 3.369])

The loader would extract the bitstream by arithmetically encoding the incoming pulse widths. This only requires low precision constant multiplies, so a few simple to build tables would make that quite fast. Easier for me to wrap my brain around than Kabuto's decoder, too.

Sadly, for the example set of pulses widths above it's only an 11% improvement on just using each pulse widths for a different output bitpair, so I really don't know how worthwhile any of this is. At this stage I'm just throwing the idea out there, because I'd prefer to be working on other things right now. I just don't want the idea to get lost :)

2018-12-10 10:08

enthusi

Registered: May 2004
Posts: 677

The most prominent multi-pulse-format would probably be Super Tape that utilized 3 different lengths.
It was first announced in german C't mag 04/1984 and ported to many systems of that time. It gained 3600 Bits/s and also had a 7200 Bit/s moe that however, was supposed to only work with suitable hardware.
The problem is less the min/max times but rather the proper thresholding. Some loaders self-adjust to the pilot tone which helps a great deal.
If you are interested in heavy error correction mechanisms for tape loading this would be suitable:
Neoload
Possibly the most overkill loader ever ;-)
I recently dumped a loader that used 6 (!) different pulselengths by Thomas Jentzsch. ;-)

We eventually got most of the data from the old 90'er tapes to load. The sources of the loader helped, though :)

2018-12-10 13:32

Frantic

Registered: Mar 2003
Posts: 1648

I know Deep Throat involved experimentation with three (or four?) different pulse lengths for data while it was created, but when I asked the authors just now none of them could remember if that made it into the final production. One of them said they probably settled for two different ones in the end after all, and the idea of using three different pulse lengths was abandoned for various reasons relating to limitations for what works well on the real hardware and things like code size and so forth.

(Is it true that the format used by the Kernal actually represents each bit of data four times on a cassette, or is that something I've dreamed in some dreadful nightmare at some point?)

2018-12-10 14:52

ChristopherJam

Registered: Aug 2004
Posts: 1409

Ooh, interesting about Super Tape. Haven't manage to find any documentation on that one, though I'll keep looking.

Neoload's error correction is seriously impressive; I guess that's a must for such a long file mind :)

What were the range of pulse lengths on the loader that used six of them? Interesting to see that they're evenly spaced in any case; I'd been pondering using larger gaps between the longer lengths so as to be more tolerant of speed variations (a 10% slower tape motor will affect the duration of long pulses more than the duration of short ones).

Frantic: yup, Kernal represents each bit as short+medium for zero, medium+short for one. Then the entire file is repeated. There's a nice writup at

http://c64tapes.org/dokuwiki/doku.php?id=loaders:rom_loader

But yes, looks like the final version of Deep Throat just used two pulse lengths for data. The tap file contains a long pulse every 20 pulses (framing bytes or words I assume), with the 19 between being a mix of short and medium pulses.

2018-12-10 15:24

Frantic

Registered: Mar 2003
Posts: 1648

I may be wrong, but I think think the long pulses in deep throat are used as "key frames", to allow the user to ffwd and rewind, and sync again, to watch the movie from that point on. At least I remember that this was a feature that was supported in this demo.

2018-12-11 10:00

enthusi

Registered: May 2004
Posts: 677

The 6-pulse loader is NOTHING you'd want for a release.
It was used privately to store own sources/code by Thomas 'back in the day'. Each pulse encoded 3 bits:
%101,%111,%110,%100,%001,%000
Ah, but it used 7 pulses in fact :)
One pulse length encodes 2 bits '01'
I just made a quick histogram (cycles):

While this looks nice and clean, this is how the actual data of basically the best dump looked like:

For a 'public use' loader I strongly suggest to use MUCH larger gaps. The loaders I wrote for the load of tap demo or Jars' Revenge etc are pretty stable. Stability over speed :)
(I just skipped the kernal load header for the histogram, it is based on that data)

2018-12-12 08:40

ChristopherJam

Registered: Aug 2004
Posts: 1409

Wow, so fitting a line to the approximate peaks, I'm getting pulse lengths of

 {167, 217, 268, 318, 369, 419, 470},

so increments of around 50 cycles. That's... brave.

Thanks for the encoding details, simulating how well it performs has revealed a flaw in my calculations. (I was only weighting the symbols by probability that they'd be next, instead of also including a factor for how much output they'd produce).

(also, everywhere I've said pulse width on this page, substitute pulse length; apologies for the ambiguity).

2018-12-12 09:53

Hoogo

Registered: Jun 2002
Posts: 105

...this is how the actual data of basically the best dump looked like...

Do you have any idea what caused these absolutely blurred signals mostly at the end of the blocks?

I guess these were multiple files, and those signals might be some of the original music...

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread: