Hacker News new | ask | show | jobs
by Waterluvian 777 days ago
What I'm most curious about is if this was always just a happy side-effect of cassette-based data storage, or if they put specific effort into making this work. Ie. by being resilient to noise before and after a broadcast, having error correction, etc.
2 comments

I'm curious how the timing worked - what happened if you were a few seconds early to record? Was the first part of the broadcast filled with noops?
ZX Spectrum tapes use a lead-in tone which the ROM code locks onto.

Random noise (and data! from a previous block) before that is ignored.

Zooming out, the format is:

  Lead-in (~4..5s usually), followed by a short header with program name & type of data that follows.
  A short pause.
  A shorter lead-in (~2s), followed by the data/program itself.
Most software uses several of such blocks. Eg. a short BASIC loader, followed by a loading screen, followed by a # of KB's machine code.

As far as audio tape storage goes, the ZX Spectrum system was fairly reliable & user-friendly.

That's ignoring headerless blocks, speedloaders, and the many copy-protection schemes...

There was no error correction on ZX Spectrum, the protocol was very simple. IIRC a square wave with next bit encoded as timing of next edge, the last byte was XOR of the whole stream serving as error detection.
Technical details: https://sinclair.wiki.zxnet.co.uk/wiki/Spectrum_tape_interfa...

Assembly: https://worldofspectrum.net/legacy-info/spectrum-rom-load-ro...

TL;DR:

> A '0' bit is encoded as 2 pulses of 855 T-states each.

> A '1' bit is encoded as 2 pulses of 1710 T-states each (ie. twice the length of a '0')

> A 'pulse' here is either a mark or a space, so 2 pulses makes a complete square wave cycle.