| |
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....
|
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Is your speed table the bitrate when loading uncrunched/unpacked data?
My speed table is on unpacked/uncrunched data.
On giana sisters the bitrate is even higher (by almost 10%) because giana sisters file "1" is 250 blocks. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillQuoting ZibriI strongly advice not to use crunchers for the game, because the loader already takes care of that in it's own way. And the less compressed the data is the faster it will load. This is unexpected. Can you expand on that?
Usually you'd expect a tape encoding to assume a uniform distribution of 0 and 1 bits, i.e., high entropy, packed data.
It can then assume a fixed relation of symbol size and frequency, and optimise encoded symbols for that generic case.
The job of the encoding is to provide the shortest possible representation for that "noise", while a good cruncher is expected to provide the high entropy.
Crunching would make the payload data as small as possible, and the encoding would have less data to encode to start with.
Do you mix both somehow, or pick encoded symbols based on the statistics of that one file (not a generic encoding with one loader for multiple files) and does that give higher loading speeds?
I encode 2 bits at a time. in 4 "symbols". 4 different pulse "widths".
Statistically, in any uncrunched file representing a C64 game in memory (think of it as a memory freeze like giana sisters original game) there are more "00" and "11" than "01" or "10".
So, the first encoder I did, counted every pair of bits and assigned the shorter pulses to the more frequent ones.
In this way the file is "time compressed" automatically. (probably the wrong term)
Without this "trick" the loader will be anyhow faster than any other but with this it gains 30% of speed on average.
With a crunched file, the speed will be slower but if you consider the uncrunched size then it will be comparable.
Also, in the latest tests I am using a fixed frequency order:
00 11 10 01
assigning the short pulses to "00" and the longest to "01".
I found that statistically on real files that's the most common distribution, "10" and "01" have a 10% difference in the total amount while 00 and 11 are the most common.
As of now I already have the TAP files tested and working on real hardware and I could pre-release a few of them but it seems that the ultimate 2+/ultimate 64 have some jitter and problems in writing which affect my results.
If written with CUTE32, the results are perfect.
Now I am writing the code that creates the turbo data on tape from the c64. Unfortunately VICE is so full of bugs that I had a lot of false positives so I have to check everything on real hardware and that takes time.
I will need a few more days to perfect the writing routine and refactor the whole thing.
If any of you has a cute32 or is able to write a TAP file on a real tape with NO JITTER of sorts, contact me and it will sure speed up things. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ZibriWithout this "trick" the loader will be anyhow faster than any other but with this it gains 30% of speed on average.
With a crunched file, the speed will be slower but if you consider the uncrunched size then it will be comparable. How does overall loading + decrunch time (= all that matters) compare, with both the uncompressed file and the compressed file being turbo-loaded?
Surely the compressed file will load + decrunch in less time than the uncompressed file will load? =) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillQuoting ZibriWithout this "trick" the loader will be anyhow faster than any other but with this it gains 30% of speed on average.
With a crunched file, the speed will be slower but if you consider the uncrunched size then it will be comparable. How does overall loading + decrunch time (= all that matters) compare, with both the uncompressed file and the compressed file being turbo-loaded?
Surely the compressed file will load + decrunch in less time than the uncompressed file will load? =)
Sincerely I haven't done these tests yet, that will be everyone "game" after the release.
As of now my problem is to generate 50% duty cycle arbitrary signals which is not easy with high accuracy and I am thinking of using unrolled code.
we will see... generatig the turbo data in a TAP file is one thing, doing it from the C64 in an accurate way is another. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting 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. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting 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).
Obviously once released, people will probably have to argue but in most cases different results are mainly because datassette have a good alignment but the wrong speed. The speed setting is on the motor itself and almost nobody ever cared about it.
A standard tape (by philips specification) should run at 4.75 cm/sec by the way. I have no clue on what was the original commodore setting but after 50 years even the most pristine and in "mint condition" were found to have different speeds (and very bad rubber bands which needed to be changed).
We will see. I just want to do the best program possible, after that it will be a matter of good tapes and good settings I think. But my turbo has a speed setting and at the lowest speed (which is still very high) data are very reliable (little less than commodore own protocol).
The program just needs a datassette with a good azimuth setting. And on the same datassette, very high speeds are possible (up to speed 8 of my program)
At the moment I could release a demo tape in TAP format but the program to generate that on the C64 side is still far from being releasable. I just need a little more time. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
An example with Giana Sisters file "1" on the disk version:
Turbo speed "5" (range is 0-9)
File size: 63472 bytes
PAL Turbo Data length in seconds: 67.55324953717236
NTSC Turbo Data length in seconds: 65.07768348738226
PAL Turbo Bitrate in bit/s: 7516.68
NTSC Turbo Bitrate in bit/s: 7802.61
Load address: $0801
End address: $FFF0
Jump Address: $84F |
| |
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. |
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | 34 - Next |
