Discovering the mysteries of the datasette

[eslapion]

As I indicated in another thread, I am developing solutions to dump the content of the original cassette from Gortek and the Microchips but I don't have a standard audio tape deck.

This forces me to develop a device that allows the connection of a datasette to the line in connector of a PC soundcard.
During the process of understanding the inner workings of a datasette, I discovered a couple of very interesting things.

For one thing, I discovered the recording level cannot be adjusted but the bandwidth for recording is very high - beyond human hearing ranges. Also, the datasette does not use biasing techniques such as those used to record sound.

However, on playback, the datasette uses a series of low pass filtered op-amps BEFORE passing this to a 7414 Schmitt trigger. The schmitt trigger ensures square TTL level signals are sent back to the VIC/64/128 but the op-amp filtering on top of removing noise also severely limits the bandwidth on playback.

Since the mid 80s, I had the idea of modding a datasette to use the tape at a faster rate. This would ensure greater reliability with tape accelerators such as the Rabbit or Compute's Turbotape but it might also allow a new and considerably faster mode of storage. This filtering on playback seems to be the bottleneck.

The other obstacle to the initial idea of speeding up the tape is I absolutely cannot find a place in my C2N-b to adjust the speed of the motor. Usually these motors have an adjuster on the opposite side of the driving shaft but I fail to find one in this specific model.

[groepaz]

C64S came with an interface and software to dump over the LPT port, use that perhaps? the soundcard probably isnt the best interface for that, since the datasette delivers a digital signal anyway.
Another way would be using one of the various dumping methods involving a C64 ... 1541U, or REU needed, i think.

[eslapion]

... the soundcard probably isnt the best interface for that, since the datasette delivers a digital signal anyway.

The ONLY thing that's digital in a datasette is the 7414 schmitt trigger which turns the analog signal coming out of the op-amps into a square wave.

On another note....

Looking at the schematics of the datasette, there is a test point which allows to tap into the analog signal before the schmitt trigger. Extremely useful to align the R/W head with a good scope, which I did.

However, I found another very interesting use for that test point. I stored a 2.5 kHz square wave signal onto a tape using a datasette that is in extremely good shape. This little guy was able to read a few tapes from the Commodore Educator system which other datasettes couldn't read properly.

With the best aligment, the analog signal had an amplitude of 1.2v pk-pk.

Then I recorded a 5 kHz square wave, something close to the frequency used with TurboTape. On read back, altough I got a good clean 5 kHz square wave on the datasette normal port, the amplitude on the analog test point fell to 400mV pk-pk. This means the filtering built into the datasette makes these tape accelerator very "borderline" for reading back.

The way the datasette works "hides" from the user that the signal acquired prior to turning into a square wave might be very weak. This can be caused by head misalignment, degrading tape signal or too high a frequency.

[groepaz]

The ONLY thing that's digital in a datasette is the 7414 schmitt trigger which turns the analog signal coming out of the op-amp into a square wave.

i was referring to what's available at the tape connector, of course. there is little reason to record the analog signal either, as the only thing that matters when dumping is the time between zero transitions (and sampling with just 44khz wont help a lot with the process either, even if its okish in many cases)

The way the datasette works "hides" from the user that the signal acquired prior to turning into a square wave might be very weak. This can be caused by head misalignment, degrading tape signal or too high a frequency.

its very easy to align with a program like recorder justage or minimal head align however (should be relativly easy to port the second one to vic20 too)

[eslapion]

@groepaz
How exactly does these information help me create a more reliable datasette?

I don't need to use these software to realign a datasette, I get better results using a scope hooked to the test point. The C64s is not something I find anywhere when looking on google.

What I want is to have a deep and thorough understanding of the datasette and its limitations and your posts achieve the exact opposite.

[eslapion]

Can anybody tell me if the people who created TurboTape and Rabbit considered these characteristics of the datasette when creating these software?

[groepaz]

How exactly does these information help me create a more reliable datasette?

your original post said that you want to dump some original tapes - and a well aligned head is all you need for that.

What I want is to have a deep and thorough understanding of the datasette and its limitations

but you are bypassing the schmidt trigger and then sample with 44khz? does not compute.

perhaps you should tell what exactly you are trying to achieve, before blindly dismissing advice. dumping original tapes _is_ a solved problem afterall.

[eslapion]

The original thread that BECAUSE I originally PLANNED to dump tapes I started some works related to the datasette and discovered a few of its hidden limitations.

I also said that when I was younger, I thought making a more reliable datasette simply involved making the tape run faster and now discovered there's much more to it than that.

Now what I would've liked is for other knowledgeable people to indicate if they know more than I do about the peculiarities of this device and perhaps how we could better exploit these properties. Perhaps develop a few small alterations which could considerably improve the performances of the device.

Thanks to you, I learned absolutely nothing that I don't already know and the more knowledgeable people all have refrained from posting in this thread. In other words, as usual, you were quite good at turning my efforts to learn more into a waste of time.

That's what you do here and that's also what you did on lemon64 in the Behr-Bonz thread.

'-)

ADDED EDIT:
Perhaps reading the title of the thread would help... its not about dumping tapes... Its about... Discovering the mysteries of the datasette.

[eslapion]

@Groepaz
You're a great programmer so perhaps, I could study the exact properties of the filtering in the datasette and you could then create a new version of Turbotape that uses a smarter form of error checking and runs at a lower frequency so as to improve readability.

The standard CBM datasette protocol simple stores then reads back the information twice then compares them which is highly inefficient. You could make a version of turbotape which includes CRC, perhaps ECC that would both serve as error detection and possible correction. It could also warn the user upon loading back that the quality of the signal is degrading when error corrections begin to occur.

How about that?

[groepaz]

click

edit: again, this is a solved problem... loader worth mentioning are "super tape" (heise verlag) and "beta skip" (used for eg the pp hammer tape). the former is very fast (considered working at the practical limit) and the later has neat features like being able able to detect errors and let the users rewind and reload a block in that case. yes this is all c64 stuff, but it shouldnt be terribly hard to port if you really wanted (and no, i sure dont, i have dumped my c2n 15 years ago and never looked back). i *think* there was a super tape equivalent loader for vic20 even, perhaps also from heise, dont recall.

you might want to talk to either enthusi or martin pieper, who are the only ppl i recall writing tape loaders in the last decade (or two even =))

[eslapion]

click

Neoload. Not bad at all.

The tape format used is rather advanced, with an interleaved (29,24) Hamming code for error correction, a 32-bit checksum for block error detection and a 40-bit preamble with optimally low self-correlation for block synchronization. Turbo Tape timing is used, but due to the overhead of all these bells and whistles the actual payload data loading speed is more like 1/3 kB/s. In theory it is able to resist at least 10 bit errors during the 40-bit synchronization, or up to 45 bit errors in a row during a 1305-bit raw data block. As for reality, it was tested successfully with a recorder known to introduce errors.

Can you adapt it to the VIC-20? Specifically to load and save program files from a VIC, not just save from a PC then load back on a GeoRAM? We could call this the GPTT (Groepaz Turbo Tape).

It seems to be limited to transfering information from a PC to a GeoRAM. I suppose its a nice tool if you don't have a 1581 or hardware cable to transfer data back to a 64.

Does it take into account the built-in filtering of the datasette? I suppose not since the text says it uses Turbo Tape timing.

The overhead may be heavy but it is still considerably better than saving the same data twice. More reliable too. At 1/3rd of a kB per second, it remains considerably faster than standard Commodore protocol.

[groepaz]

It seems to be limited to transfering information from a PC to a GeoRAM.

as it is, perhaps - it should'nt be hard to modify it so it stores the data into regular memory though

Does it take into account the built-in filtering of the datasette? I suppose not since the text says it uses Turbo Tape timing.

it doesnt really have to - the filtering happens at a frequency that is way beyond what matters for a tape loader (its not practical to make the pulses a lot shorter than turbo tape does). super tape uses a different encoding that is based on 3 pulse lengths rather than just two, i think beta skip did something similar.

however, it's still unclear to me what you are trying to achieve... there IS turbo tape for the vic20, no? (which _IS_ quite reliable afterall, _IF_ you align the head properly).

[eslapion]

Yes this is all c64 stuff, but it shouldnt be terribly hard to port if you really wanted (and no, i sure dont, i have dumped my c2n 15 years ago and never looked back).

I don't even have the ability to program the ML menu for the Behr-Bonz so you can imagine making a tape saving/loading protocol...

For the moment, I will make a complete analysis of the transfer function of the datasette playback amplification system, very likely try to mod my datasette to improve turbotape reliability and performance and then see what could be next.

[pixel]

For the moment, I will make a complete analysis of the transfer function of the datasette playback amplification system, …

Awesome! Exactly what I hoped to find to push the audio/video tape player to the limits.

[groepaz]

I don't even have the ability to program the ML menu for the Behr-Bonz so you can imagine making a tape saving/loading protocol...

it's never too late to learn assembly