| |
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 enthusiOh, missed all that.
The aforementioned loader by Thomas Jentzsch as well as the loader from C't magazine that was ported to multiple systems.
The latter reaches ~3600 Baud with option for 7200 with the warning that it will fail with many datassettes.
Mine reaches 4100 kilobit at the same reliability of commodore own loader.
Quoting enthusi
This is the point. Speeding up encoding and in particular decoding has its limits. I mastered several real world tapes. IRQ-loader and TurboTape-likes (and even heavy error correction ones - see 'neoload') and tested loaders on at least 20 different c2ns*. And even had to tune a loader to work at a party with people switching their big CRTs on/off :)
*(that part is crucial, there is no handshaking. Different c2ns will read things differently - even when both are 'aligned' to their best.)
If it was coded like the other I saw around, probably.
Quoting enthusi
Some loaders also auto-tune themselves to the registered pilot tone. To some extent even the ROM loader does that.
While technically quite possible, I personally consider everything considerably tighter than TurboTape to be unreliable.
They are but not just because of the pulse length, but because of the inaccuracies in the loader code.
My code (that was my main goal) is 100% accurate, with 0 jittering and a 2 cycle accuracy.
It has parameterts that make it possible to select ranges and bandwidths in 2 cycle steps.
And at the same pulse length of any other loader, has better results both in speed both in error reliability.
As an example, if I use my "speed 0" it still gets 4kilobit/sec on a compressed file but with a HIGHER error resilence than the own commodore slow loader.
Quoting enthusi
The meaning of azimuth is quite understood.
The headalign tools aim for minimal scatter (not zero scatter which is as you noticed not achievable in those codes).
And there IS a high res tape data format because TAP is very crude: https://www.luigidifraia.com/technical-info/
My results are checked by and engineer that worked 10 years on the cute32 and other devices. And cute32 can use a format called HTAP which not only is more granular than tap (to the cycle) but also defines both raising both falling edges,
"describing" all the signal.
Quoting enthusi
Loaders that prefer certain bits are not going to be faster than loading properly compressed data to begin with.
My loader just optimizes the representation of the bits. It still has 4kilobit speed on an exomized file or a random one.
The optimization kicks in only in uncompressed files.
Quoting enthusi
What is more tricky: decompress WHILE loading :)
What you observe (some bit pairs being faster and hence preferred etc) can also be seen in these simple tests as well :)
http://enthusi.de/oldhp/c64/tape/
With all that said: nice work, have fun!
I will discuss my code and make comparisons when I will release it, but the tests are all positive.
If the commodore loader work then also my 4-5 kilobit parameters will work. It's that simple.
I could even (untested yet) use a wider "bandwidth" as commodore. So even if commodore save/load will fail (on a defective tape or hardware) my loader will succeeed and still keep 3-4 kilobit/s speed. But to load the loader you'll then need a cartridge or floppy, since the commodore load would fail. :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
quick and dirty test program:
random data from $0801 to $FFF0
checked with 16 bit xor checksums
result is fail or success.
https://github.com/Zibri/C64/raw/master/chkram.prg
To test it:
load with
enter monitor in VICE:
issue:
bank ram
l"chkram.prg" 0 in VICE
exit and type RUN
Loader must:
load the program and run it (entry point is $80d)
P.S.
I know I could have made a nicer one, but I am lazy and this does the check I needed.
And I know colors are ugly :D
If anyone wants to provide a nicer one you are welcome to do so, but the checkd range must be no less than 0800-FF00
32 or 64 bit checkers are welcome too. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
if you want other ranges (including $0000-$ffff), there is a test file generator (cgen) in cbmtools 0.8.
Note that it currently generates random RLE compressible data which may or may not be what you want. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlrif you want other ranges (including $0000-$ffff), there is a test file generator (cgen) in cbmtools 0.8.
Note that it currently generates random RLE compressible data which may or may not be what you want.
No. I meant my chkram is ugly. That's all. But it works as a test file and almost no other loaders (very few) support a so big file which loads data in all ram (below SID, CIAs and VIC too) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting ZibriQuoting tlrif you want other ranges (including $0000-$ffff), there is a test file generator (cgen) in cbmtools 0.8.
Note that it currently generates random RLE compressible data which may or may not be what you want.
No. I meant my chkram is ugly. That's all. But it works as a test file and almost no other loaders (very few) support a so big file which loads data in all ram (below SID, CIAs and VIC too)
I guess my comment was aimed at all thread readers rather than your specific case. Haven't tried your chkram.
I don't think it was very uncommon that a tape loader loaded under I/O, maybe the oldest turbo tape variants didn't but Turbo 250 is a good example and a lot of (most?) commercial loaders loaded under I/O. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quoting ZibriQuoting tlrif you want other ranges (including $0000-$ffff), there is a test file generator (cgen) in cbmtools 0.8.
Note that it currently generates random RLE compressible data which may or may not be what you want.
No. I meant my chkram is ugly. That's all. But it works as a test file and almost no other loaders (very few) support a so big file which loads data in all ram (below SID, CIAs and VIC too)
I guess my comment was aimed at all thread readers rather than your specific case. Haven't tried your chkram.
I don't think it was very uncommon that a tape loader loaded under I/O, maybe the oldest turbo tape variants didn't but Turbo 250 is a good example and a lot of (most?) commercial loaders loaded under I/O.
Yep. That's right. Giana Sister's loader loads under IO and CHIPS too.
But I haven't seen it in many others... Usually the files are split in smaller ones and one ends up under the roms sometimes. Under the chips is more rare though.
UPDATE:
new "checkram.prg" (now with a clean exit to basic and blue background)
https://github.com/Zibri/C64/raw/master/chkram.prg
This is from now on my test program.
Made of all random data saved under chips and between $801 and $FFF0.
Range checked is: $0800-$FF00.
Can someone tell me how many loaders support this?
I am very curious. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Just update $01 as needed during the store or when reading timer CIA timers and acking IRQs. It's not hard at all. |
| |
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: 677 |
This should support it.
https://csdb.dk/release/?id=95190&show=notes#notes |
| |
Fungus
Registered: Sep 2002
Posts: 686 |
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? :) |
| Previous - 1 | ... | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | ... | 34 - Next |
