(including headalign which mainly shows on screen it's own jitter and not the truth).

...
You can try, but not only you have to use my "irq method" but also be sure the code does not jitter and has even cycles.
...

Quoting Zibri

...
You can try, but not only you have to use my "irq method" but also be sure the code does not jitter and has even cycles.
...

While I do appreciate your effort you have put in to bring the tape topic to new glory I think it's just fair to be careful when it comes to credits. Afaiu your approach is like "Ninja-method goes Tape jitter measuring", so the irq method is definately not yours. This doesn't mean that you copied it from there, I believe you had the idea on you own, but it's just not new.

However, applying this ninja-method to tape measuring hasn't been done before, that I'm pretty sure of.

Have to admit that I still have to sort all the information you give here; currently, the core benefits of this approach are not completely clear to me. Maybe I need more time to find the right path through this;)

What I think to have grasped is the potential to increase tape loading speed. Kudos for the effort, the numbers you tell here are really impressing!

Quote:

(including headalign which mainly shows on screen it's own jitter and not the truth).

Does this mean that a new headalign program would be a meaningful task for someone to take on, or are there already alternatives that work as they "should" in this regard?

I don't know if anyone ever used this method.. In some demos I saw them using an LDA or $04 in dc0c and an RTI in DC0E.
But the jump I came up with is way better.

what do you mean by "seven pulse length loader" ?

hmm 167 + 50*n means a frequency separation of 50 cycles (strange).

That can work but it will be very prone to errors.

Sorry but that's just wrong.
First (and again): this is NOT the ninja method.
...

for the tape (or timers) you only neeed DC0D.

a JMP instruction in DC0C will unlatch the IRQ (4 cycles saved) and then jmp immediately to DIFFERENT locations depending on the IRQ received.

Example:
lda #$4c
sta $dc0c
lda #$0a
sta $dc0e

Now.. a BRK will cause a jump to $A00
a pulse from tape will cause a jump to $A90
and with timers irq on there will be jumps to:
A01
A02
A03
A04
A05... etc etc

so it makes possible with the right code at $A00
to jump to different locations in your code without even having to check which irq happened.

That I call a HUGE advantage and I never saw that used anywhere in this way.

The JMP saves a few cycles on IRQ dispatch, minimising overall execution time per pulse.

But most of the measurement error would come from unstable ISR latency, i.e. whatever opcode was executing when the interrupt triggered would delay handling it by a variable amount of cycles.

Do you correct for that somehow?

No need to correct it.
In my code the amount of cycles is not variable because all "interruptable" code is made of 2 cycle instructions only :D

so whenever the IRQ happens, I get control at the 12 cycle mark.

Before someone asks: why TWO bits at a time and not 3 or 4 or even 8?
Because the speed won't improve by much.
With only 2 bits I can ssigne the more common ones (00 and 11) to the highest frequencies and so to a higher speed.
It the data is not compressed, that achieves a great compression on a frequency level.

"tap files are quantized by 8 cycles" - I was very annoyed when I found that. Almost annoyed enough to create a more accurate format and add it to an emulator. :)

I know, but there is a bug in the Ultimate2+.
Writing V1 taps makes a mistake on the 00 XX XX XX code.

Quote:

I know, but there is a bug in the Ultimate2+.
Writing V1 taps makes a mistake on the 00 XX XX XX code.

it uses the exact cycle timings from the tap - the mistake may be to expect to read back those exact timings too.

Nope.. I tested it.. there is something wrong in the files written with the ultimate if the timings are expressed in 00 XX YY ZZ.. vice is fine.
Infact in vice it works.

Can you really do something more constructive than giving air to your teeth?

Quote:

Nope.. I tested it.. there is something wrong in the files written with the ultimate if the timings are expressed in 00 XX YY ZZ.. vice is fine.
Infact in vice it works.

That doesnt make any sense. what are you even comparing there? It still sounds like you are expecting to read back the exact timing written to a real tape, like you can do in VICE (which doesnt emulate the properties of the tape that would prevent doing it). Ie if you write a tap in vice and then write this to a real tape with 1541U, the timing will not match what you get when writing directly to the real tape from a c64. That is expected. And that is also why socis RLL demo does not work in VICE, unless you create a .tap from a previously written real tape.
Quote:

Can you really do something more constructive than giving air to your teeth?

just post the damn thing so we can have a look. the entire thread is basically hot air until now.

But what keeps you from releasing a preliminary version along with the announcement in this thread's original post, which everybody can test for themselves and report problems, so you can put out a patch release some time later? :)

Here's my more or less working attempt just because I was bored.

Quoting SLC

Here's my more or less working attempt just because I was bored.

Would you be so kind to open your own thread for your own stuff, please?

semi-related:
did anyone yet write a tool that digitizes audio from datasette? (like a datasette-based sampler, any links greatly appreciated)

I know I could use: sysXXXX"filename",speed, start,end,jump
but using the kernel to get the parameters uses memory so, as of now I get the parameters manually.
Sure I can do it anyways but it will make the program way bigger.

I strongly advice not to use crunchers for the game, because the loader already takes care of that in it's own way. And the less compressed the data is the faster it will load.

Quoting Zibri

I strongly advice not to use crunchers for the game, because the loader already takes care of that in it's own way. And the less compressed the data is the faster it will load.

This is unexpected. Can you expand on that?

Usually you'd expect a tape encoding to assume a uniform distribution of 0 and 1 bits, i.e., high entropy, packed data.
It can then assume a fixed relation of symbol size and frequency, and optimise encoded symbols for that generic case.
The job of the encoding is to provide the shortest possible representation for that "noise", while a good cruncher is expected to provide the high entropy.
Crunching would make the payload data as small as possible, and the encoding would have less data to encode to start with.

Do you mix both somehow, or pick encoded symbols based on the statistics of that one file (not a generic encoding with one loader for multiple files) and does that give higher loading speeds?

Without this "trick" the loader will be anyhow faster than any other but with this it gains 30% of speed on average.
With a crunched file, the speed will be slower but if you consider the uncrunched size then it will be comparable.

Quoting Zibri

Without this "trick" the loader will be anyhow faster than any other but with this it gains 30% of speed on average.
With a crunched file, the speed will be slower but if you consider the uncrunched size then it will be comparable.

How does overall loading + decrunch time (= all that matters) compare, with both the uncompressed file and the compressed file being turbo-loaded?

Surely the compressed file will load + decrunch in less time than the uncompressed file will load? =)

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.

Note:
Speeds 0 to 2 are highly reliable.
Speeds 3 and 4 are more reliable than any other turbo
Speeds 5 to 8 are less reliable and dependent
on a good alignment and fitness of the datassette.

speed 9 worked on a particularly good datassette but it is meant for masters only.

Quoting Zibri

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.

Quoting Zibri

Note:
Speeds 0 to 2 are highly reliable.
Speeds 3 and 4 are more reliable than any other turbo
Speeds 5 to 8 are less reliable and dependent
on a good alignment and fitness of the datassette.

speed 9 worked on a particularly good datassette but it is meant for masters only.

I find these comparisons the most interesting, how are you measuring error resilience/reliablility?

It would be very interesting to see a plot of the results on different turbos against each other, both on speed and error resilience.

Quoting tlr

Quoting Zibri

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.

Quoting Zibri

Note:
Speeds 0 to 2 are highly reliable.
Speeds 3 and 4 are more reliable than any other turbo
Speeds 5 to 8 are less reliable and dependent
on a good alignment and fitness of the datassette.

speed 9 worked on a particularly good datassette but it is meant for masters only.

I find these comparisons the most interesting, how are you measuring error resilience/reliablility?

It would be very interesting to see a plot of the results on different turbos against each other, both on speed and error resilience.

To be unpolluted by bad hardware or any other variable, tests are conducted on more fronts:
1) accuracy of the signal generation taken directly from the source with an oscilloscope or using dedicated hardware (cute32 and htap format are more than redundant for this)
2) modification of the signal by a standard datassette and a test datassette at "worse" settings but stil able to read a "commodore standard save".
3) a very good aligned and serviced datassette able to read even the fastest turbo (Evil Dead master).

PAL Turbo Data length in seconds: 67.55324953717236
NTSC Turbo Data length in seconds: 65.07768348738226

Yes, but how do you quantify it to compare turbos against each other?

Are you messing with signal levels or speed to see when loading fails, or something else?

Quoting Zibri

PAL Turbo Data length in seconds: 67.55324953717236
NTSC Turbo Data length in seconds: 65.07768348738226

That's an awful lot of precision. Where does it come from? :)

the frequency separation is "strange" and the equivalent separation in my code is SPEED "3".
I can so say that my speed "3" is as error resilent as commodore's but since is higher in frequency will be more dependent on a good AZIMUTH setting.
But you can always use a lower speed and get even better error resilence.

Quoting Zibri

the frequency separation is "strange" and the equivalent separation in my code is SPEED "3".
I can so say that my speed "3" is as error resilent as commodore's but since is higher in frequency will be more dependent on a good AZIMUTH setting.
But you can always use a lower speed and get even better error resilence.

I'd consider the azimuth setting in the resilience. In my view it cannot be assumed that every tape unit is perfectly adjusted.

But, from what I hear the resilience of any of the turbos is yet to be measured, no?
Currently it's just an assumption based on pulse lengths.

Well that's my point. Your turbo at that speed loads twice as many bytes as gyrospeed does - on average.
Not sure how much the crunching of the Remember crack would affect your turbo - since you said that crunching isn't needed - but with a smaller number of bytes to load would we get even faster times?

Either way, well done :)

Probably some very efficient cruncher will gain in loading times but probably will lose everything in the decrunching.
Not sure though.

I just tried out the Slushload v2 implentation of Zibri's loader ideas

Quoting Neo-Rio

I just tried out the Slushload v2 implentation of Zibri's loader ideas

Er, please elaborate on that.

Quoting Neo-Rio

I just tried out the Slushload v2 implentation of Zibri's loader ideas

Er, please elaborate on that.

I was aware of that. My point was what makes it an implementation of Zibri's ideas? That it uses 4 pulse widths for 2-bit symbols and optimises symbol choice based on the payload file's stats? Pretty low bar for (TM)(C). :)

Quoting Krill

I was aware of that. My point was what makes it an implementation of Zibri's ideas? That it uses 4 pulse widths for 2-bit symbols and optimises symbol choice based on the payload file's stats? Pretty low bar for (TM)(C). :)

Low bar? Was never done before I did. Period.

1) tape encoding is based on pulse lenghts so there is an imbalance and the lenght of a 0 or a 1 is different in ANY tape encoding on the c64.

1) tape encoding is based on pulse lenghts so there is an imbalance and the lenght of a 0 or a 1 is different in ANY tape encoding on the c64.

1) tape encoding is based on pulse lenghts so there is an imbalance and the lenght of a 0 or a 1 is different in ANY tape encoding on the c64.

2) I didn't check any other code. I like to study and implement things myself and I came up with the "non original" idea of 2 bits encoding by myself.

3) since 2 bits have 4 possible combinations I just privileged the more common in an uncompressed file. In a compressed one every couple of bits should have the same statistical probability.

I remember many bad cracks having a decompression program which sometimes took 10-20 or even 30 seconds.

also very few programs were able to load more than 202 blocks.

And also, NONE of them had zero jitter because everyone thought that the tape "imperfection" was way more than any jitter. That's a wrong concept and I proved it even on the 1541 with my non-jittering speed test which as usual was first accused, then insulted and then copied (badly) by groepaz, but that's how things go here evidently.

Yes, decompression programs are a lot faster than they used to be. 20 seconds is considered unacceptably slow these days, with the bar being well under 10 seconds for decompressing to all of memory.

Halving the size of a file that would otherwise take over a minute to load even with a super fast tape turbo will save at least 30 seconds of loading time, so as long as the decrunch takes under 30 seconds you end up ahead. Even compression by a mere 30% would still be a drastic improvemnt.


Jitterless I can certainly see a point to, if you're pushing your throughput so close to bandwidth limitations.

About the jitter, think of it this way: if you have a jitter of 3 cycles is like having a third of the accuracy.

Even if there were some figures, on the 1541 there is a tachimetric disc for accurate setting. Because speed is very important

By philips specification, a tape should go at 4.75 cm/sec.

We determined that my deck is probably recording and loading from tape at completely different speeds.

In an emulator and on the ultimate ii, the pilot signal bars DID NOT MOVE, which shows that everything is in alignment.
With my clone deck after mastering and loading from the same deck those bars had significant jitter... either moving down screen or upscreen, even not that fast but there was distinct movement which highlights the problem I was having.

If the read pilot signal frequency is off the "perfect" (written) frequency by a fixed ratio, does the same ratio apply to all used pulse widths?
And how do preceding pulse widths influence the current one?
Surely the band-pass filter would mess a bit with the signal.

I wonder whether a pilot "training sequence" should use different combinations of all used pulse widths to determine feasible thresholds.

Speed related parameters could probably be measured by just inserting a tape with a 1 kHz test tone and crafting a program to extract that information.

For a fair comparison you should really post a benchmark that uses already compressed data too.

My concern was to make the best program I could do.. and as of now it's the only one that worked on the australian (Neo-Rio) guy's hardware :P

I still think the error resilience/reliability part is the most interesting

I hadn't even paid enough attention to see what scheme you were going for.

I am happy to KNOW that every single line (good or bad) of my code was done by me and not a single line was seen or "Inspired" by anything else.
Otherwise, where is the fun in creating?

Question:can some of you provide me a crunched version of giana sisters disk file "1" (entry point $84F) done with a GOOD cruncher? I don't want to try one then hear there was a better one.. and I never played with crunchers (yet).

Anecdotal evidence is a factual claim relying only on personal observation, collected in a casual or non-systematic manner.

Neo-Rio was pushing similar speeds with mine, and even managed to step it up one more notch, all though not with reliable results..

With the exomized giana sisters file (assuming ALL bytes from 0801 to FFF0 were crunched, which I doubt it and I would prefer some of you could "exomize" the file "1" of the disk version of giana sisters which is my reference file)

Hmm..
Interesting result.
With the exomized giana sisters file (assuming ALL bytes from 0801 to FFF0 were crunched, which I doubt it and I would prefer some of you could "exomize" the file "1" of the disk version of giana sisters which is my reference file)

It took 25(!) seconds less to load. and 7 seconds to decrunch before running.

That makes it 18 seconds faster than the demo you just watched.
(At the same turbo speed)

Oh.. nothing I didn't think you did it now.. I thought you just got it from somewhere.

Oh.. then it's ok...
Perfect.

1) I don't need to release any code.

2) my results are proved by engineers and as you can see random people (NeoRio, Flavioweb are normal users).

Oh and by the way, my turbo has done 34 kilobit on an emulated device (cute32, ultimate2 and vice) can any other (slc?) do the same? (this is off-topic since we are talking about the datassette... just wondering)

Scientific knowledge is best established by evidence and experiment rather than argued through authority as authority has no place in science. Carl Sagan wrote of arguments from authority:

One of the great commandments of science is, "Mistrust arguments from authority." ... Too many such arguments have proved too painfully wrong. Authorities must prove their contentions like everybody else.

1) I don't need to release any code.

"code or not true" is a bulls*t. I don't do fake videos (I am not even able to)

I don't even argue on what you wrote: you're just a nobody only able to steal code, mock people.

I have at least 10 witness (who also saw the code) and I have to prove nothing to you nor anyone else.

I thought I would share my findings but clearly excvept for a few exception this was the wrong place.

But I somehow enjoy to see you all getting heated and WANTING to see a code you clearly don't imagine or can't imagine if not by using the elements I already posted.

Bite me, or enjoy with me. Your choice.

post code or gtfo.

Quoting Adam

post code or gtfo.

GNE GNE GNE (sound of a baby crying and whining) :P

... personally, I don't find x64sc so much more accurate.
cpu speed still wobbles and is never a "still" 100% even in the sc version. ...

Quote:

... personally, I don't find x64sc so much more accurate.
cpu speed still wobbles and is never a "still" 100% even in the sc version. ...

performance of CPU eating emulators, for sure, depends on your (nowadays!) hardware, OS & whatnot...

But higher accuracy of X64sc vs X64 is NOT a matter of opinion.

If you're lucky, it doesn't matter (would mean whatever ancient X64 emu you use is accurate enough). But as your project is dealing with real hardware (if I got "datassette unit" from the thread title right), it rather makes me frown to read your (as of yet still unreleased) progress made so far is based on X64... Wouldn't it make sense to use the most accurate emulator you can get - or better: real hw?

... personally, I don't find x64sc so much more accurate.
cpu speed still wobbles and is never a "still" 100% even in the sc version. ...

I tested out Zibri's loader a bit more and we came to a bit of a sweet spot. Pity if he is not planning to release anything.

preferably no bigger than 60 minutes

I have a TDK D90, and a Maxell UE 90, and the TDK one allows for high speed mastering. I did all Zibri's testing with the TDK tape.

No I never did any of your tests on the bad tapes. I don't think there'd be much point.

One of the decks had occasional trouble getting to FOUND without distortion creeping in one in every five or so attempts - and that's before it even reached the tape turbo!

A random girl at Twitter just started a thread about "worst place you've travelled to", and her own suggestion was precisely Sharm El Sheikh, which she found really awful. Now of course I realise that people have different tastes, and personally I know nothing at all about Sharm El Sheikh — maybe it is totally great — but it was still kind of funny in relation to this thread. Hehhe..

Aaaanyway... back to topic and keep up the good work on those loaders! I'm eager to see what comes out of it. Maybe I should get myself a datasette again after all, just to be able to load real quick. :D

Still some proper metrics needed for useful comparison, especially regarding reliability :)

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? =)

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? =)

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 :)