| |
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 |
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. :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Neo-RioWe determined that my deck is probably recording and loading from tape at completely different speeds. Would the pilot signal prior to the turbo file be sufficient to adjust expected pulse widths accordingly? |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Quote: Quoting Neo-RioWe determined that my deck is probably recording and loading from tape at completely different speeds. Would the pilot signal prior to the turbo file be sufficient to adjust expected pulse widths accordingly?
In an emulator and on the ultimate ii, the pilot signal bars DID NOT MOVE, which shows that everything is in alignment.
With my clone deck after mastering and loading from the same deck those bars had significant jitter... either moving down screen or upscreen, even not that fast but there was distinct movement which highlights the problem I was having.
Also note that I was using a type I TDK C90, so already you have the C2N motor straining to pull a huge reel of tape, and the motor on my clone deck is fairly weak. It sometimes gets jammed trying to spool the tape after FOUND message and the motor restarts - requiring "percussive maintenance" :D
It really is a crappy deck - and yet I still manage to get good TAP dumps of originals that PASS from it - even if it's never normally used to master a tape (and clearly shouldn't given these turbos). I've discovered that Gyrospeed is the best balanced tape turbo for speed AND reliability, given the wide variance of tape decks in various states and conditions. There are faster turbos out there, but all of them require tight speed/motor/head alignment, and headclean of the deck, as well as a good quality tape. Gyrospeed has been a "good enough" compromise.
I've been wanting a new C2N in good condition for a while for my GB64 tape dumping activities, but many go for ludicrous prices now. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Neo-RioIn an emulator and on the ultimate ii, the pilot signal bars DID NOT MOVE, which shows that everything is in alignment.
With my clone deck after mastering and loading from the same deck those bars had significant jitter... either moving down screen or upscreen, even not that fast but there was distinct movement which highlights the problem I was having. The moving bars don't indicate a problem per se.
They move because the pulse width is slightly off (different motor speed for reading vs writing on possibly different devices), and then that certain integer multiple of it doesn't coincide with a video frame duration any more.
As long as the width is stable (within certain error bounds), all should be good. =)
Now, i'm not so sure about the linearity or lack thereof for different pulse widths.
If the read pilot signal frequency is off the "perfect" (written) frequency by a fixed ratio, does the same ratio apply to all used pulse widths?
And how do preceding pulse widths influence the current one?
Surely the band-pass filter would mess a bit with the signal.
I wonder whether a pilot "training sequence" should use different combinations of all used pulse widths to determine feasible thresholds. |
| Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | ... | 34 - Next |
