| |
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: 2980 |
Quoting ZibriNo need to correct it.
In my code the amount of cycles is not variable because all "interruptable" code is made of 2 cycle instructions only :D
so whenever the IRQ happens, I get control at the 12 cycle mark. If the interruptible code is a bunch of NOPs, then you'd have a jitter of 1 cycle. This is quite small, of course, and may not be reducible further. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: @Copyfault: we are slightly off topic here.
but as I said to chain the JMP in dc0c to the timers all is needed is a code like this at XX00:
example:
.C:0a00 70 70 BVS $0A72
.C:0a02 0C 70 70 NOOP $7070
A00 >> A72 ; ON BRK
A01 >> A0F ; ON Timer A
A02 >> A05 ; ON Timer B
A03 >> A75 ; ON Timer A+B
A04 >> A12 ; ON TOD
putting for example (but there are more combinations)
70 70 0C 70 70
will cause a different jump for every situation :D
Novel approach! I'll probably use that someday! |
| |
ws
Registered: Apr 2012
Posts: 251 |
Is there any data on how the reliability of reading standard-recorded tapes is affected by this method?
Like does it introduce more noise/errors due to sampling more often, or is this just an overall better way to read from tape?
(If i read a value 3 times more often, it can be wrong 3 times more often, - do i deal with that yes/no&how?) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Is there any data on how the reliability of reading standard-recorded tapes is affected by this method?
Like does it introduce more noise/errors due to sampling more often, or is this just an overall better way to read from tape?
(If i read a value 3 times more often, it can be wrong 3 times more often, - do i deal with that yes/no&how?)
Hmm not exactly...
Imagine this situation: run headalign...
You will see 2 vertical lines on normal turbos (4 in mine).
As you will see they are "separated" by "a space".
Imagine to draw a THIN line bewteen them and assign 4 different values instead of the usual 2.
Now, the ability of my program is to draw those lines perfectly.
It's then up to the real datassette status and alignment and wobbling how variable will be the "data" lines.
Nonetheless every other program I saw add a huge jitter or imprecision in "discerning what is what". My program just does not have that problem and that allows smaller "gaps" between those "lines" without any loss.
Then again if I use the same GAPS (around 96 cycles) commodore uses, I still can achieve 100 times their speed (and 2 times turbo250) preserving the error resilience.
I tried to explain this as simple as I could.
There is no noise involved.
The datassette has a low pass filter in it's amplifier which cuts everything above 10khz (but not abruptly). Frequencies up to 11196 hz (perhaps even 12khz) are possible but a little less reliable and way more dependent on the azimuth.
About the azimuth, the tape head must be perfectly parallel to the magnetic tape.
If it's not, even slightly, higher frequencies will be affected first... then the more it is "slanted" the more frequencies will be "mixed up"...
Anyway, even at lower frequencies my turbo performs greatly.
And there will be parameters so everyone can set it up as they want and you will be very welcome to make tests, improvements , even challenges :D
Before 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.
I am studying some more improvements before starting to write all the "api", but as far as we tested, more complexity does not affect too much the performance. But I might be wrong on this. We will see.
This is still in the early stages of testing. I just wanted to share with you all what has been done so far. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quoting ZibriNo need to correct it.
In my code the amount of cycles is not variable because all "interruptable" code is made of 2 cycle instructions only :D
so whenever the IRQ happens, I get control at the 12 cycle mark. If the interruptible code is a bunch of NOPs, then you'd have a jitter of 1 cycle. This is quite small, of course, and may not be reducible further.
Yep.. on real hardware that could happen but I don't consider one cycle a "jitter".
I am developing mostly on an emulator and since tap files are quantized by 8 cycles I had to do most of the work on paper.
Anyway, a one cycle jitter won't affect the actual accuracy at all.
I went up to 8 cycle per symbol at 17.5 KHZ on an emulated tape with no problems. On a real tape if it's the datassette writing the file (consider that as a COPY of a master) the maximum speed we achieved was about 12 kilobit or little more than that.
If the master would be written by a professional device I am sure the speed could go way up and still be readable by a standard datassette. And you all will be very welcom to try that.
Also, about that, most programs I saw converting TAP to WAV seem to be wrong IMHO.
I created a tap 2 wav in python which generates a waveform that does not need to be inverted (it's simmatrical on the horizontal axis, and it works nicely with every device I threw it at. More on this later. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
"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. :) |
| |
morphfrog
Registered: Mar 2002
Posts: 33 |
Quote: 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.
Intresting and very impresssive!
How fast is this compared to the fastet tapeloader I know of Gyrospeed? ( GyroSpeedWin ) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
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: 11386 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 34 - Next |
