| |
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....
|
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Zibri: quit blabla and repeating yourself. "New life for your underloved datassette unit :D" is what you have chosen as topic - provide some binaries to the public in whatever format to fill that title with more life. Premastered crap at speeds up to blablup even!
Rest: quit getting triggered by blabla.
*looks at the CLOSE button* |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Well the videos are of my setup, I can vouch for that.
All the same, I'd like to do an apples-to-apples comparison between Zibri's and other turbos, but without his mastering tools (yet), I can't really do that.
Going for a speed world record is one thing, but trying to find that sweet spot of speed AND reliability is a bit harder to test, because we need to simulate "real world" use scenarios by non-engineers using standard hardware, and only allowing for manual azimuth alignment, head cleaning, and mastering with C2N decks ONLY without fancy equipment.
Here's what I'm thinking (so please chime in if you have better ideas!) :
I have two tape decks. The clone deck as seen in the video, and an official commodore C2N that has never had it's azimuth adjusted, so it is basically a factory setting.
Both decks have been run through the Interceptor "Azimuth 3000" tape and passed with a HEADS ALIGNED message. Azimuth 3000, however, plays a bit fast and loose with head alignment. It tolerates a bit of divergence with the azimuth screw position beyond the tightest allowable azimuth position, and yet the tightest possible azimuth position won't load the test game "Bandana City" on the back of the tape. It needs to be loosened just a bit further.
All the same, this should simulate some "mostly aligned" divergence between aligned tape decks.
I figure if I do the "mixtape test" and master an entire C90 tape side with a turbo loader of choice and particular speed setting, I *should* be able to get the entire side to load without error on the other deck, since they are both more or less "aligned". A C90 should be used because apart from it straining the tape motor it simulates a mixtape of yore :D The loader should be resilient to the motor pulling different sized spools of tape depending on where in the tape spool the head is reading.
I can get to work playing with Slushload (we estimate the sweet spot is somewhere between 0x0a and 0x10), but I'll have to wait until Zibri is ready to release his mastering tools before I (or anyone else for that matter) can test his head-to-head with the same file.
It may just turn out that both loaders come within half a counter revolution of each other anyway :D |
| |
TheRyk
Registered: Mar 2009
Posts: 2244 |
Quote:... personally, I don't find x64sc so much more accurate.
cpu speed still wobbles and is never a "still" 100% even in the sc version. ...
performance of CPU eating emulators, for sure, depends on your (nowadays!) hardware, OS & whatnot...
But higher accuracy of X64sc vs X64 is NOT a matter of opinion.
If you're lucky, it doesn't matter (would mean whatever ancient X64 emu you use is accurate enough). But as your project is dealing with real hardware (if I got "datassette unit" from the thread title right), it rather makes me frown to read your (as of yet still unreleased) progress made so far is based on X64... Wouldn't it make sense to use the most accurate emulator you can get - or better: real hw? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting TheRykQuote:... personally, I don't find x64sc so much more accurate.
cpu speed still wobbles and is never a "still" 100% even in the sc version. ...
performance of CPU eating emulators, for sure, depends on your (nowadays!) hardware, OS & whatnot...
But higher accuracy of X64sc vs X64 is NOT a matter of opinion.
If you're lucky, it doesn't matter (would mean whatever ancient X64 emu you use is accurate enough). But as your project is dealing with real hardware (if I got "datassette unit" from the thread title right), it rather makes me frown to read your (as of yet still unreleased) progress made so far is based on X64... Wouldn't it make sense to use the most accurate emulator you can get - or better: real hw?
I agree. I tend not to use real hardware myself. I am in a hot country and now it's not exactly the right season :D
Anyway I have a few testers more than happy to do that for me.
From my point of view it does not matter how accurate is the emulator since I use it mostly to check the main logic.
Also from my own tests I saw no difference between x64 and x64sc concerning the tape or my code. Aside from some nasty bugs in the machine monitor, I find it very handy for testing.
Al real tests are done on real hardware anyways. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Use x64 for development and quick debug turnaround cycles.
Once good, see if still good with x64sc. If not, continue with x64sc only.
Once good, see if still good on realthing. If not, send minimal test program to VICE team. :)
Quoting Zibri... personally, I don't find x64sc so much more accurate.
cpu speed still wobbles and is never a "still" 100% even in the sc version. ... The improved accuracy refers to emulation of realthing. Things that make a difference for cycle-exact (or even sub-cycle exact) interaction of the different components of the emulated system.
It has nothing to do with virtual CPU speed deviating from real time here and there. Having stable 100% emulated CPU speed would require a real-time OS, at least. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Actually the speed of the emulated cpu directly relates to the accuracy of the audio driver in your system, since that is what it syncs to :) |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
I tested out Zibri's loader a bit more and we came to a bit of a sweet spot. Pity if he is not planning to release anything.
So I did some more testing with Slushload.
So far I narrowed down Slushload's sweetspot to around 0x0c to 0x0e, with 0x0c being on the bleeding edge of fast/reliable.
Been having really good results swapping a 4 pulse 0x0c mastered TAP on my official Commodore C2N tape between it and my clone deck and experienced no load issues so far.
0x0a and 0x0b occasionally had load errors on the deck that mastered them, so those speeds are out of consideration for me.
Will try using older tapes to see how this speed holds up between decks, and how far I can shift the alignment of my clone deck before it can't read the master from the other deck reliably anymore.
Still investigating the SMB trainer menu issue. Seems like it is keyboard buffer related. Loading the created TAP with SHIFT+RUN/STOP seems to trigger the issues, but that's an easy fix if it is. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Neo-RioI tested out Zibri's loader a bit more and we came to a bit of a sweet spot. Pity if he is not planning to release anything.
I didn't say exactly that; it will be released, but at the time and form I will see fit. I won't release an incomplete and not yet fully tested program.
Also, while it will have a similar accuracy, the mastering program has yet to be completed and it may even cause changes the main loader. As I said these videos and tests are just an early preview I hoped you people would have simply enjoyed.
Lesson learnt. |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
One thing I have learned from these tape reliability tests was that having a good quality cassette can make a huge difference! It's fairly obvious that it would, but just *how much* of a difference it makes was news to me - especially at these turbo speeds.
I have a TDK D90, and a Maxell UE 90, and the TDK one allows for high speed mastering. I did all Zibri's testing with the TDK tape.
With slushload at 0x0c between both of my decks the TDK tape worked fine, but the Maxell tape just encounters way more errors at that speed and I had to drop the mastering speed right down to 0x10 in order to get the deck that wrote it to load it back. Even then - when transferred to my other deck it loaded up until the end and then failed.
Needless to say - when mastering tapes for general consumption, use good quality ones preferably no bigger than 60 minutes (as the tape thickness of a 90 minute tape and above is weaker)
And the keyboard buffer issue in the bleeding edge Slushload RC version I am testing got fixed and the issue is now resolved. |
| Previous - 1 | ... | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | ... | 34 - Next |
