| |
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....
|
| |
Krill
Registered: Apr 2002
Posts: 2942 |
Quoting ZibriBefore someone asks: why TWO bits at a time and not 3 or 4 or even 8?
Because the speed won't improve by much.
With only 2 bits I can ssigne the more common ones (00 and 11) to the highest frequencies and so to a higher speed.
It the data is not compressed, that achieves a great compression on a frequency level. More than 4 pulse widths still look quite promising, imho: Tape loaders using more than two pulse widths for data shows 7 pulse widths to be pretty close to optimal - this could squeeze out some more density using information theory, on top of the more or less maxed-out physical optimisations.
The data should be compressed, though, as hard as possible. The more entropy, the better overall results can be expected. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11295 |
Quote:"tap files are quantized by 8 cycles" - I was very annoyed when I found that. Almost annoyed enough to create a more accurate format and add it to an emulator. :)
.tap format supports cycle exact pulse timing just fine
In TAP version $01 files, the data value of $00 has been re-coded to represent values greater than 255 * 8. When a $00 is encountered, three bytes will follow which are the actual time (in cycles) of a pulse
https://vice-emu.sourceforge.io/vice_17.html#SEC330 |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11295 |
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: 1762 |
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: 11295 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 34 - Next |
