| |
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 |
Not Commodore - but the vendors of the tape mechanics surely did this. Commodores implementation surely is based on the specs of the tape mechanics used in the 2001 PET, and then was just reused again and again. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Update: turns out that because of a previous version comment in the code, my program was OFF by a lot of cycles (and still performed).
After the correction of the typo, the program gave STELLAR RESULTS.... showing all his accuracy...
The program was working also before... but the results I was given didn't "add up" to what they whould have been.
I worked on it a night and the files were perfect.
The loader wasn't :D
It's parametric, and I was calculating wrongly it's parameters :D
Now I can finally say that unless another loader will use my same method, I will always be able to match it and surpass it.
P.S.
I created a program that checks 62K of memory and loads at $801 to FFF0.
Then it checks all memory with a simple 16 bit XOR on all bytes BELOW the ROMS and BELOW SID, VIC and CIAs chips.
The resulting prg works if loaded from ultimate or vice monitor or from some custom loader (like giana sisters).
If you want the file, it's here:
https://github.com/Zibri/C64/raw/master/chkram.prg
To load it in VICE just go to the monitor and write
l"chkram.prg" 0
x
then from c64 you can just do RUN
the file contains just "urandom" data and the data is checked in the range 0800-FF00
I can do a version that checks from 0500 to FF00 if that's not enough... my loader will load that too.. |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
I continue to play with these loaders and I think the difference between them is something akin to arguing over VHS and betamax.
My current reliability test has me using a TDK D90 to master a TAP in my newish aligned clone deck (which is capable of running Zibri's at it's master 15-6 setting - which even then isn't as accurate as professional hi-fi equipment or a CUTE32), and then trying to get that master to load in my CBM deck - which has never been serviced EVER - and work three times in a row without a single failure.
With the latest RC of slushload:
0x0c - had a single failure, so it's probably not as reliable as I first thought
0x0d - passed all three loads, and on the fourth load I shook the datasette around and only then did it fail
0x0e - passed and resisted abuse
Which makes 0x0e probably the best setting for general DIY mastering on decent tapes for distribution.
With Zibri's loader:
I've been trying his 21-14 setting and it failed the test, but his 24-24 setting worked fine. Note that there are two settings on Zibri's so more possible combinations of loads that are going to be reliable and those that aren't. The settings probably need more tuning for my crap deck, and it's not as fast obviously. Zibri is adamant that his loader be used on well maintained equipment and his code is more tunable than is Slushloads. Also this means that he can probably master a tape so well that it will be incredibly hard to copy with the old dual decks trick. If it was 1984 he might be showered in cash from EA or some other publisher.
So while it seems that Zibri's is the fastest, hands down - it's reliability is fairly limited to well maintained equipment - like betamax.
Slushload is not as fast, but comes across to me as fast enough with less reliable equipment - like VHS.
And really - speeds between the two? there's not much between them. A counter turn or so. Slushload however needs to stop cheating with the shorter tape lead in, as it's causing my old CBM deck lots of problems picking up FOUND and even loading in the first place.
Now I have absolutely no technical understanding of what I am currently seeing. I'm not digging into anyone's code. I've just been sitting around making masters and seeing the results for the past couple of days.
Well, that's the state of play so far - and I'm just one person's opinion and review. Everything is subject to change as both codebases aren't even finished yet.
What is for certain is that Gyrospeed has been surpassed. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Still some proper metrics needed for useful comparison, especially regarding reliability :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting GroepazStill some proper metrics needed for useful comparison, especially regarding reliability :) Lacking proper specs, i guess we're left with whatever we have.
So, i wonder if one could make a tape wobble measurement program.
I'd expect the wobble to be rather slow, with speed differences covering many pulses. And if that is so, perhaps, one could dynamically adjust pulse width detection thresholds, for greater reliability and perhaps even overall shorter pulses and faster loading? =) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting KrillSo, i wonder if one could make a tape wobble measurement program.
I'd expect the wobble to be rather slow, with speed differences covering many pulses. And if that is so, perhaps, one could dynamically adjust pulse width detection thresholds, for greater reliability and perhaps even overall shorter pulses and faster loading? =)
There's some info here: https://en.wikipedia.org/wiki/Wow_and_flutter_measurement
Not sure if a standard-ish measurement can be made with a tape deck containing a pulse detector like the datasette, but probably it could.
Quoting KrillI'd expect the wobble to be rather slow, with speed differences covering many pulses. And if that is so, perhaps, one could dynamically adjust pulse width detection thresholds, for greater reliability and perhaps even overall shorter pulses and faster loading? =)
For the slow changing part it is possible. I do that to some extent in the Trance Sector loader. I think the ROM tape loader does that too, or is it only regulating on the pilot? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Measuring should be rather easy... IF you have a pretty decent hifi deck, just record a reference signal, and then use something like recorder justage that plots the measured pulselengths. could be interesting to collect some data this way :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting GroepazMeasuring should be rather easy... IF you have a pretty decent hifi deck, just record a reference signal, and then use something like recorder justage that plots the measured pulselengths. could be interesting to collect some data this way :)
yes, IF. I have at least two, but they've been completely unused since perhaps 20 years. Chances they are worse than the datasette now. :) |
| |
enthusi
Registered: May 2004
Posts: 677 |
Oh, missed all that.
There used to be a few loaders with multiple bits encoded in several bit lenghts.
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.
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.)
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.
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/
sampling at 2 Mhz. And in Fact dumps are being made at this rate. Or higher even to investigate asymmetric signals which are a nice way to throw off some attempts to copy those tapes.
You can btw also inverse the data direction and use the data line as antenna on tape and use that as sampler AND loader. Tested. works. World first. But totally unreliable.
Not all that works can/should be used.
Loaders that prefer certain bits are not going to be faster than loading properly compressed data to begin with.
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! |
| |
Neo-Rio
Account closed
Registered: Jan 2004
Posts: 63 |
Decompression while loading would be something else.
Essentially I imagine that the decompression would also act as a checksum for the incoming data as well - meaning that you don't have to do it separately.
Or more simply, you could just write a tapeloader with no reliability checks and let the fully compressed file's decompress routine sort it out. If the tape loader is fast enough, a load error will come relatively quickly and shouldn't be too much of an inconvenience as the computer will crash anyway at the end.
Of course, in the latter case, some corruption may slip past the decompress routine and then you end up with a glitching piece of software :) |
| Previous - 1 | ... | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | ... | 34 - Next |
