| |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
There were loaders that detect block errors and then tell you to rewind and reload (betaskip iirc?) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: There were loaders that detect block errors and then tell you to rewind and reload (betaskip iirc?)
Super Pavloda and/or Pavloda, IIRC. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Another interesting approach might be to put ECC data after the regular data, so incase errors are being detected, it will just take longer to load instead of giving load error. |
| |
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. |
| Previous - 1 | ... | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | ... | 34 - Next |
