| |
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....
|
| |
SLC
Registered: Jan 2002
Posts: 52 |
Quote: Just update $01 as needed during the store or when reading timer CIA timers and acking IRQs. It's not hard at all.
Many loaders support it already, including the legendary Turbo 250 by Mr. Z. But as Martin Piper points out, this is nothing special. My loader does $0400-$fffa anyway, and did from the very start. The one I uploaded that I called "Pointless" does $0800-$fffa already, so.. again.. nothing special about it :)
Some commercial loaders have chosen to do it differently, though. They load the file somewhere else in RAM first, then copy it to $d000-$e000 (which is the only memory location you require a $01 change for during loading anyway). Freeload is one of the loaders that does this. I don't remember if this is also the approach for Novaload, but I think it might be.
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. |
| |
enthusi
Registered: May 2004
Posts: 675 |
This should support it.
https://csdb.dk/release/?id=95190&show=notes#notes |
| |
Fungus
Registered: Sep 2002
Posts: 631 |
Bleepload checks for bad blocks and even tells you how far to rewind.
Pretty much any commercial loader can load anywhere in ram after 1984, better question is which ones do not.
What's next, making IRQ or NMI loader which plays music as special feature? Maybe invade-a-load clone? :) |
| |
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: 647 |
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: 647 |
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: 647 |
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. |
| Previous - 1 | ... | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | ... | 34 - Next |
