General Category > Demos

Breaking Baud on actual tape. Has anyone managed this?

<< < (9/11) > >>

Cracking open the CDT file it seems the frequency tops out a little over 11kHz!  :o

That's pretty high! I haven't seen a commercial fast loader go above about 8-9 kHz (on other platforms).


--- Quote from: pelrun on 09:07, 13 October 21 ---The CPC actually applies precompensation when recording to tape so it is close to the expected result when played back (See Soft968 section 8.3)
--- End quote ---

That's really interesting. I'll have a go at applying those shifts.

That document says:

--- Quote ---Precompensation is used  - which adds to the period of a one bit and subtracts from the
period of a zero bit to make the waveform closer to the ideal when it is read.
--- End quote ---

Do you know the amount that gets added and subtracted?

Hey, it's meeeee!  ;D

I've actually been thinking about precompensation again recently, and how maybe I could improve on this area.

The CDT as generated doesn't use precompensation, because I was actually overly concerned about overall tape bias that I didn't even think about it. Tape bias is the tendency for the magentism of the head to become densensitive the longer it stays in a +ve or -ve state (which correspond to 0 and 1 in the Amstrad firmware manual).

So, the encoding of breaking baud is much more like GCR encoding on disks (mostly only done on the Apple ][) rather than the normal encoding which has parallels to MFM encoding on disks (you could consider it a precursor to disk).

The standard tape encoding achieves overall zero bias by having high and low pulses of the same length (assuming no precompensation) and so this isn't an issue, but has IMHO the unfortunate side effect of variable length encoding - an encoded 1 bit is twice as long as an encoded 0 bit.

Breaking Baud does things totally differently (mostly because I'm an awkward sod). Instead, I consider a time intervals of 16 slots, each of which could be high or low, so we have 65536 possible combinations. But obviously, most of these will be totally unsuitable for tape encoding, so I only allow encodings where there are equal numbers of high and low states. There's a further complication for tape, because the tape speed isn't very reliable, so it becomes hard to tell longer periods apart. Initially, I tried a similar approach to tape loaders of doubling the time period, but whilst this is reliable for a normal loader which is doing nothing but loading, because I only sample the tape once every scan line, I'd occasionally misinterpret the length (which is almost certainly where it's falling down her). So, I settled on a long half-pulse being 3 times the length of a short half-pulse. In 16 scan-lines, this gives me 277 possible encodings that fit the scheme, which is what allows me to encode bytes at a constant rate and still have a few encodings to signal compressed data.

There's a more comprehensive write-up written when it was all still fresh in my mind:

I don't have any CPCs out on my desk at the moment, but I might have a play with improving the CDT generation around Christmas time. Actually, I could throw out some CDTs with the proviso that I can't test them on actual tape at the moment as my CPCs are all packed away.

But in answer to the original question, it was developed using actual tape on an actual CPC from the start... (very, very early, before music and palettes) (early drafts of images, proof of concept for audio playback)

And, and it's not obvious, but if you get any read errors from breaking baud, you can just rewind a few seconds and it'll pick up where it had the error. You can see the read error at 2:15 in the second video where I just rewind the tape to recover.

Shaun M. Neary:

--- Quote from: ralferoo on 12:37, 02 December 21 --- And, and it's not obvious, but if you get any read errors from breaking baud, you can just rewind a few seconds and it'll pick up where it had the error.
--- End quote ---

This in itself is pretty mind blowing to be honest. Too bad a lot of loaders in it's day didn't support this.

Quite a few of the turbo loaders that had a counter actually did support this. Each click was usually 256 bytes (as with breaking baud), although some loaders had counters every 64 bytes instead. Breaking baud was always supposed to have an on-screen counter (it maintains one internally), but despite working on it for about a year, as is usual there was a crazy rush in the last couple of weeks to finish everything in time for release at the demoparty, so that got cut!


[0] Message Index

[#] Next page

[*] Previous page

Go to full version
Powered by SMFPacks Reactions Mod
Powered by SMFPacks Alerts Pro Mod
Powered by SMFPacks Mentions Pro Mod