Denial

Have been experimenting with turbo loading a little bit more over the weekend and ended up with 4kbit/s. You can find a TAP and WAV file systems here: http://hugbox.org/pixel/external/denial/c2nwarp001.zip (+16K required).

New about this loader is that it uses four pulse lengths to encode 2 bits instead of 1 at a time. Also, it measures what's coming from tape in the trailer to build a 1K translation map from VIA timer values to bit pairs – the loader doesn't really need to now about the overall recording speed in advance. Part of the translation map is displayed together with where the pulses hit when loading. (Should run on both PAL and NTSC).

The loader itself is about 660 bytes, so it takes longer than the main file to get in. 10.9K compressed Super Starship Space Attack makes it in 20s.

My datassette is too wobbly to do more than 4kbit/s.

What exactly is this?

It is a machine code program to alter the normal loading speed from tape to be turbo load.

It makes larger programs load faster than normal but at the expense of loading the turbo loader first.

There were 1 or 2 turbo loaders back in the day for the Vic 20 (as programs were relatively small they loaded reasonably quickly already) but lots of variations on the C64 which had much bigger programs and load times.

Novaload, InvadeALoad are proprietary examples.

The C64 used to flash stripes on the screen when doing some turbo loading.

Some loaders like US Gold used to play music while loading.

InvadeALoad had a playable game while loading the main game purchased.

Asked my PR consultant to rephrase but he didn't get the question exactly. Got 4kbit/s in a reliable fashion, me hoping.

Hmm.. time to go digging in the basement to find that old datasette.

In a thread I posted about 2 years ago, I indicated what I found about the analog filter/integrator of the datasette and discovered some turbo loaders have an incredibly slim "safety margin" because of that filter.

IOW: If you don't use a data rate for which the datasette was designed then it is incredibly easy for your turbo saved stuf to become completely unreadable.

What can you say about the safety margin of your new protocol ?

See:
http://sleepingelephant.com/ipw-web/bul ... =11&t=7451

eslapion wrote:What can you say about the safety margin of your new protocol ?

Looks pretty tight. But there wasn't a single read error yet on my drive.

I've put the code online: https://github.com/SvenMichaelKlose/c2nwarp

pixel wrote:

eslapion wrote:What can you say about the safety margin of your new protocol ?

Looks pretty tight. But there wasn't a single read error yet on my drive.

That doesn't say much at all.

The "good" way to check it is to use an oscilloscope and note the amplitude of the analog signal at the input of the 7414 Schmitt trigger when reading signals from a normal Commodore tape protocol save.

Then compare this "reference" with the amplitude obtained when reading data saved with your protocol.

The Commodore protocol has an excellent safety margin which means the signal can degrade considerably before becoming unreadable.

i somehow doubt *any* tape turbo was checked this way, ever. and yet most of them are pretty reliable anyway

groepaz wrote:i somehow doubt *any* tape turbo was checked this way, ever. and yet most of them are pretty reliable anyway

That's probably why just about all my "turbotaped" cassettes became unreadable less than a year after being saved yet every single tapes from my CES collection are still readable more than 35 years after having been saved...

No, just in case you come up with this one, it's not because of the quality of the tapes.

IMHO, your post simply means "I don't know that so nobody needs to know that..."

no my post means "there are countless people who have transferred their turbo-tape recorded tapes many many MANY years after they have been saved to". and "the most popular turbo tape things were coded by sceners who most likely didnt have access to a scope nor would even knew what/how to check it". and millions of people used it to copy their games no problem :=)

i have a couple myself that were written ~1986 and they still work fine. even the original "supertape" ones (which is even much more tight than regular turbo tape was). badly aligned c2ns are much more of a problem than signal degrading over time.

groepaz wrote:... badly aligned c2ns are much more of a problem than signal degrading over time.

The nice thing with a datasette protocol which takes into account the effect of the playback filter of the datasette is that even with a poorly aligned R/W head, it will load just fine.

That's because the amplitude of the signal at the input of the Schmitt trigger remains strong.

I hope I know, I tried a bunch of different frequencies in order to get a good idea of the transfer function of that filter.

The sad thing about not taking this filter into account is if you play back a tape with an accelerated protocol that won't load anymore on a standard audio tape deck, everything looks fine on a scope. That's because a standard tape deck doesn't have that filter...

You know what I do when people start arguing with me about this sort of stuff that's so basic ? I bring out the scope and I prove my point...

The truth is you have strictly no idea if a specific tape carrying data saved with a specific protocol results in the Schmitt trigger getting a strong signal that can take a lot of punishment or a near limit signal that's about to become unreadable during loading. You even dismiss that as completely pointless.

Once more you seem to be willing to argue about it with tooth and nails.

lol, what are you argueing over? with a properly aligned c2n its no problem. end of story. making a fuzz about it not working with badly aligned c2n is like complaining about not being able to drive straight with a flat tire.

What's the effect of the filter anyway? To me on the software side it makes no difference.

I'll go with this loader at 3.6kbit/s for the syncing part alone.

What's the effect of the filter anyway? To me on the software side it makes no difference.

the analog signal that will go into the schmidt trigger (which makes a digital signal out of it so to say) will have lower amplitude ("volume"). as long as the amplitude doesnt become so low that the schmidt trigger cant do its job anymore, it makes no difference indeed.