| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
New life for your underloved datassette unit :D
The first phase of testing just ended.
(Still in the packaging and refining phase)
But I wish to share with you all my latest accomplishment.
You might want to check this out:
https://twitter.com/zibri/status/1450979434916417540
and this:
https://twitter.com/zibri/status/1450979005117644800
The fastest example (11 kilobit/sec) has the same (or better) error rlsilience as "turbo250" but it is 3 times faster.
The slowest one (8 kilobit/sec) has the same error resilience as the standard commodore slow "save", but it is 100 times faster and twice as fast as turbo250.
;)
Notes:
1) faster speeds are possible if the tape is written with a professional equipment or hi-fi with a stabilized speed and virtually no wobbling.
2) if the tape is emulated (tapuino or similar projects) the speed can go up to 34 kilobit/sec.
3) even with datassette, higher speeds are possible but the highly depend on the status of the tape, the datassette speed and azimuth. |
|
... 327 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Still some proper metrics needed for useful comparison, especially regarding reliability :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting GroepazStill some proper metrics needed for useful comparison, especially regarding reliability :) Lacking proper specs, i guess we're left with whatever we have.
So, i wonder if one could make a tape wobble measurement program.
I'd expect the wobble to be rather slow, with speed differences covering many pulses. And if that is so, perhaps, one could dynamically adjust pulse width detection thresholds, for greater reliability and perhaps even overall shorter pulses and faster loading? =) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting KrillSo, i wonder if one could make a tape wobble measurement program.
I'd expect the wobble to be rather slow, with speed differences covering many pulses. And if that is so, perhaps, one could dynamically adjust pulse width detection thresholds, for greater reliability and perhaps even overall shorter pulses and faster loading? =)
There's some info here: https://en.wikipedia.org/wiki/Wow_and_flutter_measurement
Not sure if a standard-ish measurement can be made with a tape deck containing a pulse detector like the datasette, but probably it could.
Quoting KrillI'd expect the wobble to be rather slow, with speed differences covering many pulses. And if that is so, perhaps, one could dynamically adjust pulse width detection thresholds, for greater reliability and perhaps even overall shorter pulses and faster loading? =)
For the slow changing part it is possible. I do that to some extent in the Trance Sector loader. I think the ROM tape loader does that too, or is it only regulating on the pilot? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Measuring should be rather easy... IF you have a pretty decent hifi deck, just record a reference signal, and then use something like recorder justage that plots the measured pulselengths. could be interesting to collect some data this way :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting GroepazMeasuring should be rather easy... IF you have a pretty decent hifi deck, just record a reference signal, and then use something like recorder justage that plots the measured pulselengths. could be interesting to collect some data this way :)
yes, IF. I have at least two, but they've been completely unused since perhaps 20 years. Chances they are worse than the datasette now. :) |
| |
enthusi
Registered: May 2004
Posts: 677 |
Oh, missed all that.
There used to be a few loaders with multiple bits encoded in several bit lenghts.
The aforementioned loader by Thomas Jentzsch as well as the loader from C't magazine that was ported to multiple systems.
The latter reaches ~3600 Baud with option for 7200 with the warning that it will fail with many datassettes.
This is the point. Speeding up encoding and in particular decoding has its limits. I mastered several real world tapes. IRQ-loader and TurboTape-likes (and even heavy error correction ones - see 'neoload') and tested loaders on at least 20 different c2ns*. And even had to tune a loader to work at a party with people switching their big CRTs on/off :)
*(that part is crucial, there is no handshaking. Different c2ns will read things differently - even when both are 'aligned' to their best.)
Some loaders also auto-tune themselves to the registered pilot tone. To some extent even the ROM loader does that.
While technically quite possible, I personally consider everything considerably tighter than TurboTape to be unreliable.
The meaning of azimuth is quite understood.
The headalign tools aim for minimal scatter (not zero scatter which is as you noticed not achievable in those codes).
And there IS a high res tape data format because TAP is very crude: https://www.luigidifraia.com/technical-info/
sampling at 2 Mhz. And in Fact dumps are being made at this rate. Or higher even to investigate asymmetric signals which are a nice way to throw off some attempts to copy those tapes.
You can btw also inverse the data direction and use the data line as antenna on tape and use that as sampler AND loader. Tested. works. World first. But totally unreliable.
Not all that works can/should be used.
Loaders that prefer certain bits are not going to be faster than loading properly compressed data to begin with.
What is more tricky: decompress WHILE loading :)
What you observe (some bit pairs being faster and hence preferred etc) can also be seen in these simple tests as well :)
http://enthusi.de/oldhp/c64/tape/
With all that said: nice work, have fun! |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Decompression while loading would be something else.
Essentially I imagine that the decompression would also act as a checksum for the incoming data as well - meaning that you don't have to do it separately.
Or more simply, you could just write a tapeloader with no reliability checks and let the fully compressed file's decompress routine sort it out. If the tape loader is fast enough, a load error will come relatively quickly and shouldn't be too much of an inconvenience as the computer will crash anyway at the end.
Of course, in the latter case, some corruption may slip past the decompress routine and then you end up with a glitching piece of software :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
There were loaders that detect block errors and then tell you to rewind and reload (betaskip iirc?) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: There were loaders that detect block errors and then tell you to rewind and reload (betaskip iirc?)
Super Pavloda and/or Pavloda, IIRC. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Another interesting approach might be to put ECC data after the regular data, so incase errors are being detected, it will just take longer to load instead of giving load error. |
| Previous - 1 | ... | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | ... | 34 - Next |
