| |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I know, but there is a bug in the Ultimate2+.
Writing V1 taps makes a mistake on the 00 XX XX XX code.
it uses the exact cycle timings from the tap - the mistake may be to expect to read back those exact timings too. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazQuote:I know, but there is a bug in the Ultimate2+.
Writing V1 taps makes a mistake on the 00 XX XX XX code.
it uses the exact cycle timings from the tap - the mistake may be to expect to read back those exact timings too.
Nope.. I tested it.. there is something wrong in the files written with the ultimate if the timings are expressed in 00 XX YY ZZ.. vice is fine.
Infact in vice it works.
How can you make such assumptions when you don't even know my code?
Can you really do something more constructive than giving air to your teeth? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: I know, but there is a bug in the Ultimate2+.
Writing V1 taps makes a mistake on the 00 XX XX XX code.
Anyway,
This is the latest version:
Now the loader is ON TAPE and it is recorded only ONCE and not twice as commodore usually does but it is indeed in commodore standard.
By the way this is a different tester, with a different (and slightly out of speed datassette) and a c64c (I removed the "digi boost" from the loader because it was too loud on a breadbin, but on a c64c you can barely hear the sounds)
Enjoy!
https://twitter.com/zibri/status/1451954596251832327
As of now, the "fast" "non master" version takes 50 seconds to fully load from when you press play on tape to when the game actually starts :D
The "relaxed timings" version (which works also on datassettes in "bad" shape) takes a total of 59 seconds from LOAD to GAME.
I just made also an EMU-ONLY (means it works only on emulated datassette but on real hardware) version which loads at 30.5 kilobit per second :D
It works in VICE and probably on the Ultimate2 emulated tape (being tested right now).
Not so useful and I can go way faster than that on an emulated datassette. On a previous test I hit 34 kilobit/s.
As of now anyway both the slow and fast version work pretty well on a normal datassette.
The reason of some glitches we had was due to my testers skipping part of the pilot tone.
The pilot tone is pretty useless but it gives time to the datassette to gain a uniform speed.
That needs a minimum of 5-6 seconds.
On emulated tapes is not even needed but on the real thing it is very important to hit play at least 8 seconds before the real data begins (the commodore standard loader I mean). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
If some of you wants to test an early beta (tap and wav provided), let me know.
No need to test on emulators or FPGAs...
Only on real DATASSETTE (C2N) or compatible units. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
If anybody tries this on hw, it would be interesting to see how it compares to Datassette RLL Mastering Demo. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Nope.. I tested it.. there is something wrong in the files written with the ultimate if the timings are expressed in 00 XX YY ZZ.. vice is fine.
Infact in vice it works.
That doesnt make any sense. what are you even comparing there? It still sounds like you are expecting to read back the exact timing written to a real tape, like you can do in VICE (which doesnt emulate the properties of the tape that would prevent doing it). Ie if you write a tap in vice and then write this to a real tape with 1541U, the timing will not match what you get when writing directly to the real tape from a c64. That is expected. And that is also why socis RLL demo does not work in VICE, unless you create a .tap from a previously written real tape.
Quote:Can you really do something more constructive than giving air to your teeth?
just post the damn thing so we can have a look. the entire thread is basically hot air until now. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazQuote:Nope.. I tested it.. there is something wrong in the files written with the ultimate if the timings are expressed in 00 XX YY ZZ.. vice is fine.
Infact in vice it works.
That doesnt make any sense. what are you even comparing there? It still sounds like you are expecting to read back the exact timing written to a real tape, like you can do in VICE (which doesnt emulate the properties of the tape that would prevent doing it). Ie if you write a tap in vice and then write this to a real tape with 1541U, the timing will not match what you get when writing directly to the real tape from a c64. That is expected. And that is also why socis RLL demo does not work in VICE, unless you create a .tap from a previously written real tape.
Quote:Can you really do something more constructive than giving air to your teeth?
just post the damn thing so we can have a look. the entire thread is basically hot air until now.
The only one who is hot air in this scene is you.
I even posted the videos shot on real hardware showing two different parameters working.
I'm still testing anyway and I WILL TAKE MY TIME, so STFU.
And again. On commodore standard slow save, the frequency gap is of 96 cycles. I can use 80 with more accuracy and obtain 8 kilobit/s with the same error resilence.
Obviously I can shorten the gap up until 40-32 cycles and save a master tape recording it with a professinal tape deck and it still works when read on datassette.
But when you write and then read you induce a double error.
Safe settings are around 48-56 (11/10 kilobit/s) cycles of frequency separation, if you want to write and then read with any other datassette and even in bad shape, then you have to increase the gap to at least 80-96 cycles (which still beats turbo250 by TWO TIMES) and then you'll have no problems in any situation. In any other , even the normal commodore save would fail.
Sorry for the rant to the usual moron, guys. He is just not able to shut up. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I like how you ignore what was written and then repeat some unrelated babble combined with carefully crafted ad hominem. Good work! |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
But what keeps you from releasing a preliminary version along with the announcement in this thread's original post, which everybody can test for themselves and report problems, so you can put out a patch release some time later? :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillBut what keeps you from releasing a preliminary version along with the announcement in this thread's original post, which everybody can test for themselves and report problems, so you can put out a patch release some time later? :)
That is exactly my intention.. but for now is all very manual.. I have to automate things a little... to encode loader+game i have to do everything mostly manually as of now.
Perhaps I was wrong in posting the videos so early but you know... I was amazed that it worked so well on real hardware.
Imagine that the guys who make "CORE32" are updating their device because the fastest version of my program exposed a small timing bug :D
P.S.
As of now this has been tested mostly on PAL C64.
ON NTSC c64 the frequencies will be higher on tape and perhaps can give some problems. That's why I need some time to add some parameters.
If you want a sneak peek I can manually prepare a version for you if you are willing to test.
Drop me a message if you are. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 34 - Next |
