| |
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.... |
| |
tlr
Registered: Sep 2003 Posts: 1790 |
Quoting ZibriQuoting tlrQuoting ZibriThe 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.
Quoting ZibriNote:
Speeds 0 to 2 are highly reliable.
Speeds 3 and 4 are more reliable than any other turbo
Speeds 5 to 8 are less reliable and dependent
on a good alignment and fitness of the datassette.
speed 9 worked on a particularly good datassette but it is meant for masters only.
I find these comparisons the most interesting, how are you measuring error resilience/reliablility?
It would be very interesting to see a plot of the results on different turbos against each other, both on speed and error resilience.
To be unpolluted by bad hardware or any other variable, tests are conducted on more fronts:
1) accuracy of the signal generation taken directly from the source with an oscilloscope or using dedicated hardware (cute32 and htap format are more than redundant for this)
2) modification of the signal by a standard datassette and a test datassette at "worse" settings but stil able to read a "commodore standard save".
3) a very good aligned and serviced datassette able to read even the fastest turbo (Evil Dead master).
Yes, but how do you quantify it to compare turbos against each other?
Are you messing with signal levels or speed to see when loading fails, or something else? |
| |
Krill
Registered: Apr 2002 Posts: 2980 |
Quoting ZibriPAL Turbo Data length in seconds: 67.55324953717236
NTSC Turbo Data length in seconds: 65.07768348738226 That's an awful lot of precision. Where does it come from? :) |
| |
Zibri Account closed
Registered: May 2020 Posts: 304 |
Quoting tlrYes, but how do you quantify it to compare turbos against each other?
Are you messing with signal levels or speed to see when loading fails, or something else?
You should ask Andrea Nalli, the electrical engineer behind the Cute32 device.
Anyway, as a rule of thumb, what counts are the frequencies (pulse lenghts to be exact) and the frequency separation used.
Commodore uses 3 pulses:
"SHORT" 384 cpu cycles + some jittering
"MEDIUM" 528 cycles + some jittering
"LONG" 688 cycles + some jittering
the frequency separation is "strange" and the equivalent separation in my code is SPEED "3".
I can so say that my speed "3" is as error resilent as commodore's but since is higher in frequency will be more dependent on a good AZIMUTH setting.
But you can always use a lower speed and get even better error resilence.
At speed "3" my turbo yields 6364.21 bit/sec in PAL and 6606.31 bit/sec on an NTSC machine. (calculated on giana sisters huge file)
Which is 50% more than the fastest released (Evild Dead master).
P.S.
Evil dead was not only an ugly game but gave a lot of problems to original tape owners.
It was even used often to calibrate datassette due to it's high sensitivity to errors. |
| |
Zibri Account closed
Registered: May 2020 Posts: 304 |
Quoting KrillQuoting ZibriPAL Turbo Data length in seconds: 67.55324953717236
NTSC Turbo Data length in seconds: 65.07768348738226 That's an awful lot of precision. Where does it come from? :)
LOL.. forgot to remove the digits..
It comes from the tap generator I coded in python :D |
| |
tlr
Registered: Sep 2003 Posts: 1790 |
Quoting Zibrithe frequency separation is "strange" and the equivalent separation in my code is SPEED "3".
I can so say that my speed "3" is as error resilent as commodore's but since is higher in frequency will be more dependent on a good AZIMUTH setting.
But you can always use a lower speed and get even better error resilence.
I'd consider the azimuth setting in the resilience. In my view it cannot be assumed that every tape unit is perfectly adjusted.
But, from what I hear the resilience of any of the turbos is yet to be measured, no?
Currently it's just an assumption based on pulse lengths. |
| |
Zibri Account closed
Registered: May 2020 Posts: 304 |
Quoting tlrQuoting Zibrithe frequency separation is "strange" and the equivalent separation in my code is SPEED "3".
I can so say that my speed "3" is as error resilent as commodore's but since is higher in frequency will be more dependent on a good AZIMUTH setting.
But you can always use a lower speed and get even better error resilence.
I'd consider the azimuth setting in the resilience. In my view it cannot be assumed that every tape unit is perfectly adjusted.
But, from what I hear the resilience of any of the turbos is yet to be measured, no?
Currently it's just an assumption based on pulse lengths.
I repeat:
my turbo is AS IS. It has parameters. In the end people will use what they want.
P.S.
a good tape alignment and maintenance is WHAT SHOULD BE DONE.
As it was for drives it is for tapes.
There were commercial loaders even for the 1541 that didn't work if the drive didn't have a good alignemnt and speed setting.
There's no difference with a datassette.
Alignment and steady speed have always to be good. Otherwise you stick with the commodore loaders which assume also the MISUSE of their products.
Anyway. We are off topic. Again. The program is still in the early stages of testing and development.
If you want to help in this project, just tell me what setup do you have and what kind of tests you want to do and I can provide the appropriate TAP files (for now) assuming you will write them correctly on a good tape and with a good device.
I would really apreciate some help in testing. |
| |
Zibri Account closed
Registered: May 2020 Posts: 304 |
And here is a very early preview of the new version of the loader in action: https://twitter.com/zibri/status/1456759971610337283 |
| |
Neo-Rio Account closed
Registered: Jan 2004 Posts: 63 |
I timed a gyrospeed load of the Remember crack of Giana sisters in an emulator alongside your twitter footage.
Speed seems comparable with gyrospeed just edging out Zibri's by a second although the Remember crack had a long depack once loaded.
And the Remember crack is 37,590 bytes - so actually smaller than Zibri's test file. |
| |
Zibri Account closed
Registered: May 2020 Posts: 304 |
Quote: I timed a gyrospeed load of the Remember crack of Giana sisters in an emulator alongside your twitter footage.
Speed seems comparable with gyrospeed just edging out Zibri's by a second although the Remember crack had a long depack once loaded.
And the Remember crack is 37,590 bytes - so actually smaller than Zibri's test file.
longer than what?
I don't depack anything.
Giana sisters is unpacked. is the file "1" on the disk version but a little longer (file 1 is from 0820 to FFF0, the loaded file is from 0801 to FFF0 without any depacking) |
| |
Neo-Rio Account closed
Registered: Jan 2004 Posts: 63 |
Well that's my point. Your turbo at that speed loads twice as many bytes as gyrospeed does - on average.
Not sure how much the crunching of the Remember crack would affect your turbo - since you said that crunching isn't needed - but with a smaller number of bytes to load would we get even faster times?
Either way, well done :) |
Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ... | 34 - Next |