Show HN: I recovered one of my earliest ZX-Spectrum games from an audio cassette

It was a custom turbo loader for the CPC that had a co-operative multi-tasking thing going on, so it had a loader, music player, realtime data decompressor and some spare time left to do some other things.

I had plans to make the demo even better, but actually what got produced was quite pure because everything, literally EVERYTHING, is loaded directly into RAM and then decompressed in place (that's what the random white flashes are you might see at times - it's usually where a RLE marker was placed in RAM and shown by the display hardware before the background task to expand/copy the RLE section was executed).

As such, every step of the animations loaded could actually a full screen independent of the last, it's just most of the time it compresses super easily as the delta from what's already in the memory at that point is very small.

The live capture of the demo as it was presented live for the first time is here: https://www.youtube.com/watch?v=D62jpqZ6TG4 Someone else running it on real hardware (but sadly turned down the tape volume after a minute or so): https://www.youtube.com/watch?v=G7HEK1B2oIc

This is a very early prototype that actually shows the speed of loading completely unrelated images, just relying on compression - some of the screens load 16KB in around 10 seconds: https://www.youtube.com/watch?v=qfGcvWOaFFw (BUT BE WARNED IF YOU ARE SENSITIVE TO FLICKER)

Granted, it was quite a simple encoding, but it wasn't just "straight-up 1s and 0s straight into RAM".

The bits of data to be output are encoded into high/low symbols representing the voltage on the pin, a 0 bit is output as HL and a 1 bit is output as HHLL, recorded at a nominal symbol rate of 855 T-states or approx. 4092 symbols per second.

In other words, both 0 and 1 bits are output as a pair of pulses with the 1 bit being twice as long as the 0 bit. If you had a continuous stream of 0 bits, it'd be a steady 2046Hz square wave, with a steady stream of 1 bits, it'd be a steady 1024Hz square wave.

There are many reasons why this scheme is adopted rather than the much simpler "high voltage=1, low voltage=0" which would be your "straight-up 1s and 0s straight into RAM".

The first main reason is that while the signal ends up as a perfect square wave, recording this to tape and reading it back doesn't give a perfect square wave, but instead a noisy wave that's more like a sine wave but with flattened peaks and valleys. This is very much in the analog domain.

Firstly, there's the conversion of the 0V/5V to analogue wave form, where's actually zero-biased to produced a +ve / -ve waveform. Ignoring all the weirdness on the tape, this is read back as a +ve / -ve waveform, amplified and rebiased to a non-zero voltage (so e.g. now the signal might be 1V-4V or it might be -1V to 6V). So now, converting that back to digital is hard - you need to choose an arbitrary cut-off voltage where lower is 0 and higher is 1, but you then find that then the volume changes the relative size of 0 and 1 bits when read back from tape.

The next problem is called "head biasing", but essentially the magnetic head needs to keep changing polarity to record a useful signal, but if the polarity of the head stays +ve or -ve too long it becomes saturated and resists change in the opposite direction, and so takes longer to change state. So for instance if you recorded a pattern like LHHHHLLH it might read back as LHHHHHLH. A video of mine that shows this effect is: https://www.youtube.com/watch?v=-GdPSnFswgk

The next problem is that tape motor speeds, tape can stretch, even oscillators in different machines can vary slightly and it's very unlikely that the signal you read back will be exactly the speed it was recorded at. You can "re-clock" on edge transitions, but if you have long stretches without a transition, it's hard to be certain how many bits were there.

Replacing a bit with a pair of pulses solves all of the above problems. There are several competing tape formats that use pairs of pulses - using output symbols HL and LH, which gives a constant bit rate, and the one used in the Spectrum of HL or HHLL, which is effectively frequency modulation and gives an average bit rate of 1500 baud (it'd be 1000 baud for all 1 bits, 2000 baud for all 0 bits). The latter was adopted almost universally, as it's simpler to decode on read - it's just timing the period of a pair of pulses (i.e. an entire wave). The former one requires slightly slower baud rates, but a related encoding is the basis of most early floppy disk encodings which use MFM.

There are alternative encoding schemes possible, just very infrequently used. I made a demo for the Amstrad CPC back in 2014 that tries to implement a turbo loader by clever use of output symbols, and it actually translates an entire byte at a time into a sequence of "overall balanced" pulses over a roughly uniform time period, and achieves a baud rate of 2687-3072. I was attempting to implement something like MFM coding used on floppies, but it wasn't quite possible with tape. This demo also had realtime decompression of data. There's more information on that here: https://github.com/ralferoo/breaking-baud/blob/master/docs/t... and you can see an example of it in action here: https://www.youtube.com/watch?v=NxX4fu6dAzo - when watching this be mindful that each screen is 16KB and would take 52seconds with the standard loader (same speed as the Spectrum standard loader).