| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
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. |
| |
Frantic
Registered: Mar 2003
Posts: 1628 |
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. |
| |
enthusi
Registered: May 2004
Posts: 675 |
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) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
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). |
| |
Hoogo
Registered: Jun 2002
Posts: 102 |
...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... |
| |
enthusi
Registered: May 2004
Posts: 675 |
Yes, at least the backside had music on it ;-)
But two other things to note. If you press stop/play the starting motor will also produce all sorts of pulse-lengths (at least when read back via c2n) and of course these graphs show TAP bytes, not mere data bytes, so encoded pauses are also shown as pulses. That is the reason for those seemingly spurios pixels at the same horizontal position. Those others I'd bet as well are music.
50 cycles is _WAY_ too short unless you record/play on the very same device without touching anything (and no bad lines, sprites etc obviously). |
| |
thrust64
Registered: Jun 2006
Posts: 8 |
That loader is mine. :)
And of course it was only meant for personal use on the same hardware. And hey, it worked for me! :D
I don't remember exactly how I came to 7 pulse lengths. But I did some statistics about bit combinations from some files I had and then some math based on the minimum pulse length differences which seemed feasible. And that resulted into the 7 lengths for optimal performance. |
| |
thrust64
Registered: Jun 2006
Posts: 8 |
My target speed was 10k. That also played a role, IIRC. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1380 |
I'm impressed :) |
| |
enthusi
Registered: May 2004
Posts: 675 |
Ah good to see you here :)
I, too, was/am impressed, hehe. |
| Previous - 1 | 2 | 3 | 4 - Next |
