| |
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 |
Quoting SLC
I think the main reason why turbo loaders such as Super Tape (not to be confused with Input64s Super Tape), GRL Turbo, etc. didn't load higher than $d000 is because regular kernal load doesn't allow it, so I simply think many considered it quite pointless to support it.
It's not in my opinion. The fact that commodore doesn't support it means nothing. Commodore didn't "support" 99.9% of the things that were done after the release of the C64 :D
And that's why my loader supports that too.
After a cleanup, my loader supports from a normal basic program to a full 64K image (excluding the locations where the small loader code is which are a bunch of bytes).
At the moment I rechecked all parameters, cleaned up also the mastering program (written in python and multi-platform).
And now I will proceed with the difficult task (for me at least) to make a mastering program FOR the C64.
That's not going to be easy without any jittering like my loader is but I have a few ideas. |
| |
SLC
Registered: Jan 2002
Posts: 52 |
Just pointing out that it wasn't "not done" because it was deemed an impossible task or anything. A lot of commercial loaders loads $d000-$e000.
But yeah, I agree.. in this context, a bare minimum should be loading $0400-$fffa... :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
As compression algorithms got better and file sizes got smaller, being able to load under the IO/VIC/CRAM probably got less important as well. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Just a note about error reliability, since I see some confusion on the matter.
Reliability is given by 3 factors:
1) frequency range (the higher the more the azimuth and tape media must be perfect ..e.g. TDK D60 or better)
2) frequency "separation" or bandwidth.
3) acuracy of code.
Commodre uses 3 "symbols" with a base pulse lenght of $30 (in tap values) separated by $12 ($42) or $14 ($56)
Both the save program AND the loader have a big jitter of even 8 cycles or more. Thus losing a lot of accuracy and needing bigger separation.
So, let's say I set my turbo to $30 with $12 separation and my error resilence, will be about 150% of the commodore one becase my code ha zero jitter.
Moreover: speed "0" of my loader is higher in frequency but has 1 time and a half the bandwith of the standard commodore loader. It has proven to work even on a very unstable and in need of service datassette owned by NEo Rio, a member of this forum.
Speed 0 has "$18" as separation. And it still keeps a more than respectable speed of 4.4 kilobit/sec.
On his "debatable" hardware it even worked speed 1 and 2 (as the table I posted shows they are the most reliable and forgiving speeds).
Using the same base frequencies and separation of other turbos, my turbo proved to be more stable and error free than the counterpart (depending on the settings obviously).
A jitter, even minimal in code is like saying that your "borders" are "about there". Meaning you must use wider ranges to be sure the signal was actually there.
With zero jitter you are sure the signal arrived at precisely THAT time.
Another important factor is the "readiness".
My code is ready before the 40th cycles after the pulse arrived. I have therefore some "wasting time" routines there at the moment which could be instead used to play a tune of do some raster effects or even nothing. At the moment it just does the usual INC $D020 (6 cycles) and and plays the tape audio on the sid, but it could be a tune instead of the screeching sound of the tape pulses).
Unless a loader will use my exact same method (I tried many other methods) there is no way it can be faster.
And whatever method it uses it can't be more accurate than mine (no jitter, 2 cycles accuracy).
Now, this is all anecdotial for people who never did something like this, but 4 testers plus an independent one can't be all posting photoshopped videos for a complicated hoax, don't you think? Think what you prefer. I am fine as I am.
I just need to code a good writer program for the c64 and that's another very complex task. Sure I could use a timer but it won't be as accurate as the loader is.
A last note: if the writer also has a jitter, that jitter sums and in some moments multiplies by th loader jitter, lowering the accuracy by another order of magnitude or two in the worst case. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
My standard tape loader, no real optimisation or speed tweaks, can load 33,096 bytes in 62 seconds (with the screen enabled, flashing sprite, music with music load, bitmap load, then data load) which I think works out to be 4270 bits/sec.
Plus overhead for block checksum and gaps between blocks and files.
TAP file bytes are $20 and $40. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
If I use tape file bytes $18 and $30 then it loads in 44 seconds, which is I think, 6017 bits/sec. |
| |
SLC
Registered: Jan 2002
Posts: 52 |
Quote: My standard tape loader, no real optimisation or speed tweaks, can load 33,096 bytes in 62 seconds (with the screen enabled, flashing sprite, music with music load, bitmap load, then data load) which I think works out to be 4270 bits/sec.
Plus overhead for block checksum and gaps between blocks and files.
TAP file bytes are $20 and $40.
What kind of data is relevant. If it's unpacked it will load somewhat faster than if it is packed if there's a majority of zero bits in the data. With a 50/50 separation which is roughly what you'd expect with a crunched file, you would have ended up with 105 seconds for that file size if you're using a standard 0/1 encoding scheme (if I didn't miscalculate).
33096 bytes * 8 bits = 271248 pulses needed
271248 / 2 = 135625
135625 * 256 = 34720000 total cycles of short pulses
135625 * 512 = 69440000 total cycles of long pulses
104160000 cycles / 985248.0Hz = 105,7 seconds ~ 2504 bit/s.
(Freeload from Paul Hughes uses the same pulse lengths)
If you are using a different encoding scheme or some realtime unpacking, these numbers of course do not apply. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Well that's the point about how and where to use symbols to encode data combined with their relative error rates given the mechanics of the tapes. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Well that's the point about how and where to use symbols to encode data combined with their relative error rates given the mechanics of the tapes.
To have the right calcluation of the "turbo" data, just do this:
SUM all values of the pulses leght from start to end of the turbo section.
Then divide that big number by 123156 and you will get the seconds. Then divide total number of bytes and divide by seconds and you will get BYTES/sec then multiply that by 8 and you will get BIT/sec
In other words. if your SUM of all pulses lenghts in the TAP file (turbo section) is "ttime", the formula is:
bit/s = len(data)*985248 / ttime (for PAL)
bit/s = len(data)*1022727 / ttime (for NTSC)
Let's put it this way:
in your case ($20/$40) it's like having a file made all of $30 on average.
you will have $30 * 8 symbols per BYTE in your TAP file.
in a 2 bit encoding instead, you will have half of them :D
let's say in your 2 bit encoding your 4 symbols will be:
$18 $28 $38 $48
that would be the same as having all $30 on average.
in my turbo that encoding is called "24 16"
it's one of the slowest and more error resilent (the best is 24 24)
On a test file (archon exomized) my 24 16 does:
File size: 22073 bytes
bit/s: 5322.25
Note:
even if you would use the same pulse lenghts and encoding, unless your code will have zero jitter, an error resilence as my turbo is NOT achievable.
To remove (conceal) the jitter you must then use a wider bandwidth and slow everying down a notch or two. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
On other news...
One of my testers just made the newest world record with my turbo:
https://twitter.com/zibri/status/1459938649873784833
That's a load at 11534.22 !!!
Written and loaded by the same datassette of course.
This is what a well serviced datassette can really do with the RIGHT software :D
Update!!!
New world record: 12338.79 bit/sec!!! https://twitter.com/zibri/status/1459981517925593097
As of today, my turbo is the fastest turbo ever made.
It succeeded writing and reading back from a normal commodore DATASSETTE, in perfect owrking order and on a good compact cassette.
Probably there is still a chance he will break to 12989.49.
We will see.
Note:
this is just "how fast can he go?" test.
But at lower speeds the reliability is total (more than commodore's own save method) |
| Previous - 1 | ... | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | ... | 34 - Next |
