| |
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 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 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I still think the error resilience/reliability part is the most interesting
Indeed. And it should be formally proved/calculated of course, a bunch of anecdotal evidence is useless for this - at best its a hint you are on the right track. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
If this was a healthy and not toxic environment I would have posted some preliminary code long ago. Unfortunately it isn't and what I see is people stealing each other code and ideas, adding a few tweaks and posting them as their own. Almost reminded me of the horrible italian bootlegged games with names and title changed and sold in newstands.
So I will post my final code when I think it will be ready.
I won't care about what "the usual guys" will think or say, because all my results are being professionally checked by engineers who are in this field from years (I am the newbie here).
About my results, they are "anectodal" only becayuse of a personal choice. When I post data is accurate data checked and rechecked by professionals and not "guys" like you or me.
I wonder why "the usual guys" are so harsh on a thing they didn't even see the code yet. And probably they won't see anything they haven't already seen in their career of sotware "inspired by others".
I am happy to KNOW that every single line (good or bad) of my code was done by me and not a single line was seen or "Inspired" by anything else.
Otherwise, where is the fun in creating? |
| |
SLC
Registered: Jan 2002
Posts: 52 |
If that was directed towards me, I can assure you that not a single idea was taken from you (you're not the only one that have been thinking of a 2 bit scheme as I said). I started from scratch on Wednesday, and I hadn't even paid enough attention to see what scheme you were going for.
Just like you, every single line of code is mine. I admit that I did initially ask for tips on a method to use for the timers, though I did not ask for code. Not have I seen any of your tap-files either, so there's no way I could have seen your code.
Also, why did I just release this now, you seem to have asked yourself. Part of the fun when doing something like this to me, is to let others experiment with along the way rather than just babbling on about it. Would I have written this now if it wasn't for you? No, not at this time. But this WAS on my todo-list, so I figured now was a good time as any. You haven't seen the last from me, as I know I screwed up a thing or two in the previous release and I am also trying out other ways. But again, your benchmarks would make much more sense with already packed data.. I hope that you'll add that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I hadn't even paid enough attention to see what scheme you were going for.
Not even looking at the thread - thats how toxic you are :( |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ZibriI am happy to KNOW that every single line (good or bad) of my code was done by me and not a single line was seen or "Inspired" by anything else.
Otherwise, where is the fun in creating? There's this quote, something with standing on the shoulders of giants. :)
I.e., looking at prior art and building on that to reach new heights, with some fresh ideas and creativity, can be pretty rewarding, too. =) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quote:I hadn't even paid enough attention to see what scheme you were going for.
Not even looking at the thread - thats how toxic you are :(
You're all awesome (Groepaz, Zibri, SLC etc) and gives the scene a lot. <3 Just try to appreciate your individual efforts and be proud of them. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Here is another "anecdote" for you all to enjoy:
https://www.facebook.com/Zibri/posts/10227091097965659
Giana sisters: 251 BLOCKS. Speed "6" : 8265.01 bit/sec
Note:
I made the pilot longer just to help testing.
As you can see the bars are "going" down.
That means that the writing is faster than the reading.
Why?
Because the tape was at more than half!
The same recording at the start of a tape causes bars to go up.. at about 25% of a tape they are steady. and after 50% they start to go up.
Just for information. |
| Previous - 1 | ... | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | ... | 34 - Next |
