| |
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 |
Quote:I added in my encoder the option to randomly cause errors (pulse lenght changes) and that's how I tested the loader.
so what is the random amount of error it can deal with at what speeds? that'd be some kind of metric to work with at least. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazQuote:I added in my encoder the option to randomly cause errors (pulse lenght changes) and that's how I tested the loader.
so what is the random amount of error it can deal with at what speeds? that'd be some kind of metric to work with at least.
It can deal with any amount of error depending on the "bandwidth" of the "speed setting".
Since the code is 100% accurate, the "borders" of the ranges are also usable (not in jittering code).
So if I set a "bandwidth" of let's say 144 cpu cyles per symbol I have a better resilence than CBM with higher bandwidth.
If I use the same bandwidth of CBM (144-160 cpu cycles) then I have a better error resilence than CBM but I can still do 5 kilobit/sec.
In my turbo, as of now, the maximum bandwidth is 192 cycles, which is way more than CBM (and that's my speed 0 setting) at about 4.2 kilobit/sec
The highest speed achieved so far on a real tape is 12kilobit/sec. (Almost zero error resilence but within the parameters of a good datassette and a very good tape)
P.S.
it can also deal with an azimuth misalignment, just a tad more than cbm. But a wrong azimuth setting or a datassette in bad condition SHOULD NOT considered normal as musch as a misaligned 1541 does.
Like saying that a 1541 turbo "should work" on a 1541 with dirty heads, 40 years old elastic rubber band and bad media.
The datassette is not "as shit" as people may think. It was it's use that was wrong. Only because it was cheap.
Commodore on the other hand didn't spend time in telling how to make it perfectly aligned and fit or it would have impacted probably the sales of drives.
But everything I am doing could have been possible at the time.
Now I am focusing on the mastering program on the C64 itself.
The mastering program in python is very fine but the challenge for me is also to write a mastering program with zero jitter and same accuracy the loader has. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:It can deal with any amount of error depending on the "bandwidth" of the "speed setting".
no shit. that is pretty much an universal truth and couldn't be more generic. the interesting thing is the answer to "what is the random amount of error it can deal with at what speeds?" because "that'd be some kind of metric to work with at least." |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazQuote:It can deal with any amount of error depending on the "bandwidth" of the "speed setting".
no shit. that is pretty much an universal truth and couldn't be more generic. the interesting thing is the answer to "what is the random amount of error it can deal with at what speeds?" because "that'd be some kind of metric to work with at least."
I thought you were following the discussion.
The amount of error is exactly half the bandwidth of each signal. It is obvious, since the program has no jitter and it 2 cycle accurate if bandwidth is 96 cycle, the "wrong" signal can happen up until 48 cycle bofore or after if should have been.
"I can explain it for you, but I can't understand it for you." (anonymous) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ZibriQuoting GroepazQuote:It can deal with any amount of error depending on the "bandwidth" of the "speed setting".
no shit. that is pretty much an universal truth and couldn't be more generic. the interesting thing is the answer to "what is the random amount of error it can deal with at what speeds?" because "that'd be some kind of metric to work with at least."
I thought you were following the discussion.
The amount of error is exactly half the bandwidth of each signal. It is obvious, since the program has no jitter and it 2 cycle accurate if bandwidth is 96 cycle, the "wrong" signal can happen up until 48 cycle bofore or after if should have been.
And the bandwidth can go as high as 192 cycles for example at speed 0. More than CBM bandwidth.
"I can explain it for you, but I can't understand it for you." (anonymous) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting ZibriQuoting ZibriQuoting GroepazQuote:It can deal with any amount of error depending on the "bandwidth" of the "speed setting".
no shit. that is pretty much an universal truth and couldn't be more generic. the interesting thing is the answer to "what is the random amount of error it can deal with at what speeds?" because "that'd be some kind of metric to work with at least."
I thought you were following the discussion.
The amount of error is exactly half the bandwidth of each signal. It is obvious, since the program has no jitter and it 2 cycle accurate if bandwidth is 96 cycle, the "wrong" signal can happen up until 48 cycle bofore or after if should have been.
And the bandwidth can go as high as 192 cycles for example at speed 0. More than CBM bandwidth.
That's not very clear at all. Error is not usually measured in bandwidth for instance.
Also there are many factors that may affect the reliability, so measuring the limit of what each loader can take is the only real way to know anything.
One method could be this:
Take a tape image for each loader, introduce various amounts of jitter, measure for each loader at which amount it starts to fail and plot that.
Then, do the same for various amounts of high-frequency dampening, and so on... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:The amount of error is exactly half the bandwidth of each signal. It is obvious, since the program has no jitter and it 2 cycle accurate if bandwidth is 96 cycle, the "wrong" signal can happen up until 48 cycle bofore or after if should have been.
Are you saying it's tolerant to random +/- 48 cycles per pulse (that is 48 / 8 = 6 tap values)? At what speed is that? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazQuote:The amount of error is exactly half the bandwidth of each signal. It is obvious, since the program has no jitter and it 2 cycle accurate if bandwidth is 96 cycle, the "wrong" signal can happen up until 48 cycle bofore or after if should have been.
Are you saying it's tolerant to random +/- 48 cycles per pulse (that is 48 / 8 = 6 tap values)? At what speed is that?
precisely.
48? is SPEED 0 at about 4-5 kilobit/sec
I can even esceed that using +/- 7 tap values.. but speed zero until now worked wherever the cbm loader does.
No need to slow it down any further, but it's possible. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlrThat's not very clear at all. Error is not usually measured in bandwidth for instance.
I don't agree here.
I (or the tape) can induce as much random errors (deviations from the right value) as the range allows.
The range (or bandwidth) of each symbol can be set and determines the turbo speed/reliability.
After a certain deviation (not much) even the standard CBM loader stops working.
So exceeding or matching CBM own "tolerance" assures the same (or better in my case) tolerance to errors.
I say better, bceause CBM code is very imprecise and can't determine "accurately" when the pulse came. My loader can.
So it can take advanage of a slightly "wider" range that includes up until 2 cycles from the "border".
CBM (or any other) loader jittering does not allow that because they never know if the PULSE arrived AT TIME X or TIME X+/- it's jitter (which in many cases is more than 8 cycles!) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepaz
Are you saying it's tolerant to random +/- 48 cycles per pulse (that is 48 / 8 = 6 tap values)? At what speed is that?
My loader can be very tolerant, differently from his author, or can be very intolerant (thus enforcing even a copy protection).
One of my testers succeded even in writing and reading back at speed 9 (only 40 cycles bandwidth = +/- 20 cycle tolerance)
Which means that his perfectly service datassette has a combined writing + reading deviation of a maximum of 20 cpu cycles :D
that's an incredible 10 cycle deviation! (10 writing + 10 reading in the worst case scenario).
Speed 9 was meant only for masters... it surprised me.
Now he is attempting a new record, but I dount he will make it with a bandwidth of only 32 cycles.. we will see.
This is just for fun to test the limits of a PERFECT device on a perfect tape. |
| Previous - 1 | ... | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | ... | 34 - Next |
