| |
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: Quote:Speed related parameters could probably be measured by just inserting a tape with a 1 kHz test tone and crafting a program to extract that information.
original Input64 had such thing on them, and a small type-in program in the Booklet that could be used with it to align the azimuth.
yes.. but that will assert if the speed is the philips standard.
we don't really know what commodore chose for tape speed.
since it was only for data we don't know for certain.
it could have been higher or lower. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Update:
also 9152 bit/sec worked!
also 10293.12 bit/sec worked!
his datassette is not bad at all even if it's a clone..
as usual is the software that makes the difference.
now he is going for the record :D
which will probably fail, because speed "9" is meant only for masters.
and here is his record!
https://twitter.com/zibri/status/1457334641896132610 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:For a fair comparison you should really post a benchmark that uses already compressed data too.
indeed, numbers derived from testdata with low entropy is a bit meaningless |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: For a fair comparison you should really post a benchmark that uses already compressed data too. The loader soci just uploaded loads the demo "SIDrip relive" at an average of 5400 bits/s at what looks like rather conservative settings.
It's also funny to observe that also this loader uses the scheme you claim was your idea, and that noone else had done before you ;)
Until now the funniest thing was to hear you speak and FAIL on his deck.
While with my turbo he beat even the record of my own testers.
Speed "9" is not even meant to work on a datassette.. yet it did.
And yes, you can believe it or not, I don't really care, everything I did was my own idea and from scratch.
If anyone else in 40 years thought of it or used it is not my concern.
My concern was to make the best program I could do.. and as of now it's the only one that worked on the australian (Neo-Rio) guy's hardware :P
Bite me. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:For a fair comparison you should really post a benchmark that uses already compressed data too.
indeed, numbers derived from testdata with low entropy is a bit meaningless
And I repeat: you will be welcome to make all tests you want after the release.
A commodore game was always a full (or partial) memory image (not considering multiload games which were the same but more than one... like different games... every stage was a completely new game or the same with different data).
All I care is to make the fastest and more reliable turbo. From scratch (that was my purpose and fun).
And I did. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
So, the confirmed table is:
============================================
S | C | B | PAL Bitrate NTSC | Reliability
--------------------------------------------
0 24 24 5154.12 5350.19 Best / Old D
1 23 22 5497.19 5706.31 High / Old D
2 22 20 5889.19 6113.22 High / Any D
3 21 18 6341.39 6582.61 Best / Any D
4 20 16 6868.8 7130.09 Good / Any D
--------------------------------------------
5 19 14 7491.9 7776.9 Best / Same D
6 18 12 8239.33 8552.76 Good / Same D
7 17 10 9152.42 9500.58 Avg / Same D
8 16 8 10293.12 10684.67 Low / Same D
--------------------------------------------
9 15 6 11758.64 12205.94 Low / Master (record by Neo-Rio)
-------------------------------------------
PAL C Center Freq: 123156 hz / C
NTSC C Center Freq: 127840.875 hz / C
PAL B Badwidth: 123156 hz / B
NTSC B Badwidth: 127840.875 hz / B
-------------------------------------------
File lenght: 47103 bytes.
------------------------------------------- |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Yeah I thought it was strange that the Giana sisters TAP reliably failed in the same way - but yeah, it was just software after all.
It's funny because that clone datasette used was relatively new old stock I got off ebay when somebody had a pile of them to offload a few years back. Have been using it to dump TAPs for Gamebase 64 for quite a while. It was given an amateur headclean and alignment with Azimuth 3000. The motor is a bit sketchy on that unit. The tape was a brand new (oldstock probably) Maxell Type I C90. C64 was completely stock C64C longboard.
By the way, the video posted completed this load in 20 counts on that particular datasette (I forgot to show it). Will aim for some higher speed settings tomorrow, but so far this looks really good. Each speed setting faster saves a counter revolution on this equipment by the looks of it. The question is: can it go higher? :D |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting ZibriMy concern was to make the best program I could do.. and as of now it's the only one that worked on the australian (Neo-Rio) guy's hardware :P
In the first post you did state claims about error resilience compared to other loaders so that was obviously a goal too, no?
I still think the error resilience/reliability part is the most interesting of your goals because turbos didn't use to very reliable. Improving the speed and the reliability at the same time would be a great achievment. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quoting ZibriMy concern was to make the best program I could do.. and as of now it's the only one that worked on the australian (Neo-Rio) guy's hardware :P
In the first post you did state claims about error resilience compared to other loaders so that was obviously a goal too, no?
I still think the error resilience/reliability part is the most interesting of your goals because turbos didn't use to very reliable. Improving the speed and the reliability at the same time would be a great achievment.
exactly.
I believe it can be even further improved.
After analyzing NEO-RIO results I found ONE byte error in the "speed 8" setting.
I expect to find more on the speed "9".
But the table is solid.
At lower speeds errors are zero even on bad devices.
At the lowest speeds the saved data is not only readable by the same deck, but also by other "out os speed" ones.
I am pretty satisfied with these results as of now.
As I said the work is not complete.
But for now the results are encouraging. |
| |
SLC
Registered: Jan 2002
Posts: 52 |
Glad that I can be of amusement. I do know why it failed on his deck, though, and I have rectified it on my end. One of the fails he mentions isn't really a loading fail even, it's caused by two lines of code I forgot to remove as I was originally intending a return to basic on load. He described a load that exited to a blue screen and wouldn't have happened without an active cartridge installed. Had it actually failed the load it would have ended with a red striped screen.
Any other issues lies in either how the .tap-file is prepared in advance and/or the solution being used to transfer it and I'm refining that process a bit now. Loader itself does exactly what it was designed to do.
I guess your constant need for bragging, trying to convince the world everyone steals your ideas, etc. is the signs of you not caring? :D |
| Previous - 1 | ... | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | ... | 34 - Next |
