| |
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....
|
| |
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. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
@Groepaz
I messed up my calculation in my previous answer.
Speed 0 has a "bandwidth" of 24 TAP VALUES = 192 cpu cycles.
So the pulse can "randomly" "happen" 12 values (96 cpu cyles) before or after the "right" length.
For 48 cycles (6 tap values) that's speed "6" which goes double as fast as speed 0 and reaches about 8.5 kilobit/sec.
The number in column C and B are TAP values.
I organized them in speeds 0 to 9 but both values are arbitrary.
============================================
S | C | B | PAL Bitrate NTSC | Reliability
--------------------------------------------
0 24 24 5154.12 5350.19 Best / Old D
1 23 22 5497.19 5706.31 High / Old D
2 22 20 5889.19 6113.22 High / Any D
3 21 18 6341.39 6582.61 Best / Any D
4 20 16 6868.8 7130.09 Good / Any D
--------------------------------------------
5 19 14 7491.9 7776.9 Best / Same D
6 18 12 8239.33 8552.76 Good / Same D
7 17 10 9152.42 9500.58 Avg / Same D
8 16 8 10293.12 10684.67 Low / Same D
--------------------------------------------
9 15 6 11758.64 12205.94 Low / Master
-------------------------------------------
PAL C Start Freq: 123156 hz / C
NTSC C Start Freq: 127840.875 hz / C
PAL B Badwidth: 123156 hz / B
NTSC B Badwidth: 127840.875 hz / B
-------------------------------------------
File lenght: 47103 bytes.
-------------------------------------------
The actual record is "Speed 10" (which is C=13 B=5) with :D And he is attempting speed 11 (C=12 B=4) .. failing so far, quite obviously. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Small update:
I think there is no way to write and read back speed 11.
The measured error rate is about 30%.
So I think we hit the limit.
32 cycles of bandwidth *could* work only if written by a professional device and at the same exact speed of the datassette which will be reading it back.
It was a real miracle the record he did at only 40 cycles of bandwidth :D
And that's why my program starts at 48 cycles (speed 9) and still I consider that a "master only" speed. If written on a datassette the result is very unreliable even on the same datassette.
But.. still.. the record stands.
:D
P.S.
you might have noticed that my bandwidth settings go in multiples of 8. That's only to ease tests on the emulator.
The code allows also increments of 2 cpu cycles. I use 8 just because I am lazy :D |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
No shame in including a "you probably aren't using a cassette deck on the cassette bus" top speed for CDROMs, MP3 players, ultimate, or other devices.
Just because you can. |
| |
ws
Registered: Apr 2012
Posts: 251 |
A little bit off topicz, but:
if we applied a very simple hardware change that turns the datasette into variable speed by connecting something to the paddles pins... would that be cool?
Like take an old joystick cable, hook the wires up to a teensy and splice the teensy into the power supply of the datasette motor? VBR-Read with "spinup/spindown" to determine best error-free reading speed?
But maybe there was just something in my gung-pow tea just now.
(Just thinking Dongle here... a teensy costs around $16..) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I find it pretty non interesting myself if a mastered tape doesnt work on random, likely not optimal condition, c2n - afterall thats the usecase for 99% of all people that still use tapes these days :)
Quote:Error is not usually measured in bandwidth for instance.
Guess i need to make some calculations using supposed and guessed speed deviation/flutter/wow and see how these numbers go together :) |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Quote: I find it pretty non interesting myself if a mastered tape doesnt work on random, likely not optimal condition, c2n - afterall thats the usecase for 99% of all people that still use tapes these days :)
Quote:Error is not usually measured in bandwidth for instance.
Guess i need to make some calculations using supposed and guessed speed deviation/flutter/wow and see how these numbers go together :)
I agree.
It's nice in theory to have everyone service their datasettes, but we all know that that won't happen!
Unless there's some inexpensive way to realign and service them...
...and even then you need good tapes. You can still get tapes but the good ones are expensive. And if they're expensive, there are better solutions. The cheap "Type 0" knockoff tapes can't even hold a reliable kernel save let alone a turboloader.
It's fun, but tapes are totally not worth it these days, and the only reason to play with them is to push technical boundaries and ask "what if?" :)
Supporting them is still valid though - as you have to assume that a more accurate device may or may not end up using the cassette port. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Well, i guess we can expect shitty belts are being replaced and azimuth setting is somewhat okish - but anything besides that, not so much. It still boils down to the expected variations between individual c2n - which unfortunately we dont have datasheets of, but we can still do a couple calculations to atleast get an idea of what to expect. |
| Previous - 1 | ... | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 - Next |
