| |
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....
|
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Quote: Neo-Rio: My loader is *not* an implementation of Zibri's loader. Apart from checking out the claimed benchmarks, I have not paid much attention to technical details. But there's a big likelihood that it's based on the same principles. I have no idea about the actual implementation as I never saw the actual loader.
And Zibri, drop the attitude.
None of the ideas I used came from you. The method is not exactly new, and I'm not sure it's the first time it's implemented on tape loaders either. I'm not even sure I've still landed on the optimal solution and have a few more ideas to try out. You told me to take "my projects" elsewhere, so I did... wasn't so much talk about cooperation then.
The only thing here that somehow is right is the fact I was triggered by your attitude to give it a go :)
More than happy to be corrected here. I did not see any code and make comparisons. Only made an assumption from the chatter in this forum. So if I'm wrong - I own that mistake right there.
In any case I tried mastering both Slushload v2 and Zibri's test tap he sent me to try out.
I have a pretty woeful clone datasette. I tried aligning it and giving it a headclean, and with firmware 3.10 on an ultimate 1541-II and tape adpater - I could not get either tap generated to master properly. Slushload v2 failed take off (0x0a speed from a file I generated - which worked in VICE), and Zibri's loaded but the end result made some pretty cool glitch music along with corrupted graphics :D
Now granted that my tape deck was a pile of cack, and the ultimate 1541 is not the best mastering tool (it won't even let you lead in the motor before recording) -- and yet Gyrospeed mastered TAPs I created played back OK on it.
So while Gyrospeed is not the fastest tape turbo in existance, it is *mostly* reliable across really badly maintained datasettes IMHO.
And I suppose this was the problem with datasettes back in the day - just wide variance on equipment - and nobody really giving two flying firetrucks about it because they were cheap and nasty. While theoretically possible to get amazing speeds with it, the datasettes in question need to be properly maintained - which mine was certainly not. That's even though it was an oldstock clone datasette which I haven't had for very long, and also has a funky motor. Yet it still manages to load a lot of stuff normally.
The other thing is that emulators don't really "count" so to speak, as you should expect a perfect load every time. But this is obvious....
I am by far and away no subject matter expert on this. Only reporting so far what I'm seeing and trying to see if I can work to improve the situation. Fully expecting to be corrected on these assumptions. |
| |
SLC
Registered: Jan 2002
Posts: 52 |
I would like to know more about what you tried and that didn't work, so if you could send me a PM about it (keeping it outside of this thread etc.) I would really appreciate that.
The 1541U does btw delay a second before it starts outputting data after you start recording, which should be enough time for the signal to settle.
The challenge with writing these signals back to tape (and which is why Zibri's real C64-approach might yield a better result as he will have full control of this process), is that you need to be more careful on how you render the signal but nothing we can do with the .tap-files can affect how for example the 1541U handles it. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJam
Yes, decompression programs are a lot faster than they used to be. 20 seconds is considered unacceptably slow these days, with the bar being well under 10 seconds for decompressing to all of memory.
Halving the size of a file that would otherwise take over a minute to load even with a super fast tape turbo will save at least 30 seconds of loading time, so as long as the decrunch takes under 30 seconds you end up ahead. Even compression by a mere 30% would still be a drastic improvemnt.
Jitterless I can certainly see a point to, if you're pushing your throughput so close to bandwidth limitations.
Yep.. all that's right.
About the jitter, think of it this way: if you have a jitter of 3 cycles is like having a third of the accuracy.
HeadAlign for example has a total jitter of more than 20 cycles and "most" of the movement you see is it's own jitter and not the tape.
Just saying.. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: I would like to know more about what you tried and that didn't work, so if you could send me a PM about it (keeping it outside of this thread etc.) I would really appreciate that.
The 1541U does btw delay a second before it starts outputting data after you start recording, which should be enough time for the signal to settle.
The challenge with writing these signals back to tape (and which is why Zibri's real C64-approach might yield a better result as he will have full control of this process), is that you need to be more careful on how you render the signal but nothing we can do with the .tap-files can affect how for example the 1541U handles it.
The u2+ is accurate but it will never go even near the Cute32.
Cute32 has an accuracy that is way over the c64 cpu itself.
The last imperfection (a 0.5microsecond rounding) was corrected thanks to a special ultra-fast version of my turbo which unexpectedly failed on the cute32 while working on VICE.
Corrected the very small rounding error now Cute32 is the most accurate device for tape mastering (and dumping).
Anyway, the c64 mastering program is still under work... different duty cycles yeld different results on original datassette and clones. No difference on emulators or devices like u2/u64/cute32.
In the meanwhile I am thinking of a way to let people correctly set their datassette.
This of this:
a 1541 (which costed a lot and people cared about it) is most of the time very well aligned and expecially at a "perfect" speed, set by a tachimetric disc on the back of the motor.
On (the cheap) datassette, people didn't care and always blamed the software or the "friend's recording".
We analyzed a few datassette, few of which never even opened and in mint condition and we dind't find 2 at the same speed.
Moreover the azimuth was set almost randomly.
With the ultra-slow commodre save/load that didn't create a big problem but with anything that wants to use the full potential of the deck, there will be dragons.
I found a way to be sure that at least the speed is right.
About the azimuth, it does NOT depend on the "recording".
There is a right one and a wrong one.
Anything wrong will worsen the reading process.
The right azimuth is the one that makes the head perfectly parallel to the tape. That can depend on the tape media (the plastic cassette) itself and on the deck mechanics too.
But again, once the azimuth is correctly set and the speed is also correct, we successfully tested speeds up to 12 kilobit/sec on 2 different devices.
My turbo anyway can keep a very decent (commodore-like) error resilence at about 4-6 kilobit/sec and, as I said on a good deck/tape it performed at about 12 kilobit/sec.
Note, if you put a "line in fake tape" instead of a real tape, obviously wobbling and speed problems cease to exist. in that case the speed goes way up, demonstrating once and for all that the electronics of the datassette is not an issue. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ZibriAbout the jitter, think of it this way: if you have a jitter of 3 cycles is like having a third of the accuracy. Hmm... if, say, there is some noise on the pulse width coming in from tape, making it +/- 30 cycles compared to the saved intended width... and you add 3 cycles of measurement error due to jitter on top of that, are +/- 33 cycles a third of the accuracy of +/- 30 cycles? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Do we know how the c2n was specified to begin with? Whats the max speed deviation? For the floppy drive mechs we know this (and thus what a proper loader must be able to deal with). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Do we know how the c2n was specified to begin with? Whats the max speed deviation? For the floppy drive mechs we know this (and thus what a proper loader must be able to deal with).
Even if there were some figures, on the 1541 there is a tachimetric disc for accurate setting. Because speed is very important. About tapes even with audio hi-fis there were differences, for example TEAC hi-fi were known to be "faster".
By philips specification, a tape should go at 4.75 cm/sec.
With my program we found a perfect setting which then works with anything else too (obviously) but we don't know the exact figure.
A simple test could be this one (assuming the ribbons are new and good):
turn the motor on for exactly one minute from the start of a tape and check the counter. The problem is we don't know exactly what should be the right one. And nobody cared much at the time.
(I cared zero because I had the 1541 almost immediately). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Even if there were some figures, on the 1541 there is a tachimetric disc for accurate setting. Because speed is very important
for data its much less important than for audio tape - actually floppy drives are specd much "worse" than good audio decks regarding deviation in speed.
Quote:By philips specification, a tape should go at 4.75 cm/sec.
Thats the ideal figure - but the interesting number is the maximum deviation from that. Good HIFI decks manage ~0,1% for example - however the shitty straight from hell mechs used for C2N are surely specd much worse. This is the number we need to know to make a loader that can deal with all devices. |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
I tried loading Zibri's loader and Slushloadv2 in the ultimate-ii under TAP loading emulation. While Zibri's loader worked, slushload v2 crashed to BASIC right at the end.
Meanwhile both TAPs worked fine in VICE 3.1 (old, I know).
It gets interesting because Zibri gave me multiple TAPs at different speeds to try out mastering to tape, and all of them "loaded" from the same deck they were mastered from, but his Giana Sisters TAP dreliably glitched out with fast music every time when loaded!
(G0T080 would have loved it! :D )
We determined that my deck is probably recording and loading from tape at completely different speeds.
It makes me wonder if the ultimate-II is mastering TAPs to tape properly (probably not), and what sort of equipment and software is the average user going to need to fine-tune their C2Ns within an inch of their lives....
At best most users can only really do a headclean and adjust azimuth. Maybe a demagnetization too if they have a demag tape. |
| |
SLC
Registered: Jan 2002
Posts: 52 |
Neo-Rio: I can explain a few things for you if you send a message, I won't discuss slushload here. :) |
| Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | ... | 34 - Next |
