| |
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 Martin PiperA perfectly (very) reliable C2N that's been very well serviced or calibrated really isn't a good test however. It would be much better to use a standardised test that alters the TAP file bytes to introduce controlled errors and then check, under emulation, that the TAP with errors still loads.
That's what I did while developing the first version of my turbo.
I added in my encoder the option to randomly cause errors (pulse lenght changes) and that's how I tested the loader.
Then after it was stable and perfect I started the real world tests. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Neo-RioOh yeah, I forgot about audiotap.
I think somebody used to sell those cassette adapters with headphone jacks - like what came with the rainbow arts CD - but I don't think we can get them anymore. Shouldn't be too hard to handcraft one if you have the designs though.
I have one of those inside one of my datassette.
They are for sale on any chinese website for very little. I found them for sale even here in Egypt.
With those, if well aligned to the datassette head, the limit is "the sky". I think more that 20 kilobit.. haven't tested it yet... Even if it's perfect I didn't finish even the main loader code. I am adding a few options right now :D
But the new world records Flavioweb just did are a very good motivation to go on. |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Quote: Quoting Neo-RioOh yeah, I forgot about audiotap.
I think somebody used to sell those cassette adapters with headphone jacks - like what came with the rainbow arts CD - but I don't think we can get them anymore. Shouldn't be too hard to handcraft one if you have the designs though.
I have one of those inside one of my datassette.
They are for sale on any chinese website for very little. I found them for sale even here in Egypt.
With those, if well aligned to the datassette head, the limit is "the sky". I think more that 20 kilobit.. haven't tested it yet... Even if it's perfect I didn't finish even the main loader code. I am adding a few options right now :D
But the new world records Flavioweb just did are a very good motivation to go on.
The Rainbow arts CD had an actual circuitboard with headphone jack that plugged onto the cassette port edge-connector on the 64.
You're thinking about those car stereo plastic tape adapters with the headphone jack coming out of them so you can plug them into something else, like a CD player or an iphone, to play music in your car.
I suppose it would work just as well, only that you'd probably have to hack a hole for the cable (or lead it out through the datasette hole - only then the tape would be stuck in there. |
| |
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? |
| Previous - 1 | ... | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | ... | 34 - Next |
