5 ms·

Fun read! I'm having trouble understanding how a max byte read, a la ``dd`, would somehow be insufficient to yield a working digital master of an analog casset

Fun read! I'm having trouble understanding how a max byte read, a la ``dd`, would somehow be insufficient to yield a working digital master of an analog cassette tape.

deleted 4y ago
[deleted]
CamperBob2 4y ago
Same here. His explanation left me feeling like I'm missing something that's at once extremely simple and extremely clever. It seems to involve the observation that reading more data than the tape actually contains will return a trailing section of random noise that will fail a checksum, but that's as far as I got. (Edit: the author posted an answer to StackExchange here: https://retrocomputing.stackexchange.com/questions/143/what-format-is-used-for-apple-ii-cassette-tapes https://retrocomputing.stackexchange.com/questions/143/what-... . A single-byte checksum is appended to the tape image written by the firmware, and the software is presumably aware of what it should be. If you were to make a copy of the tape by writing too much data, the resulting checksum returned by the firmware would probably not match what the software expected. Maybe it's as simple as that?) Another point worth making when it comes to the cassette port, is that every Apple ][ essentially came with a free 1200-bps half-duplex modem. All you had to do was "just" connect the cassette in/out ports to the phone line with simple audio amps. (ISTR using the hybrid network from an old Western Electric rotary phone to do the actual interfacing.) I don't think I've ever run into anyone else who tried this, but it was an amusing thing to play with as a kid. I built two interfaces and gave one to a friend on the other side of town. It took less than a minute to send images of Suzy and Melissa from a warez copy of Artworx's Strip Poker, as I recall.
- dhosek 4y ago
  The other trick was to use the tape loading routines to read audio from a cassette tape and digitize it as 1-bit audio at some low bit-rate (1.2kHz?). It sounded pretty awful and you couldn't hold much audio in RAM, but it was possible. I had a floppy with an excerpt from Led Zeppelin’s Black Dog digitized with this technique.
  - CamperBob2 4y ago
    I remember being astonished at how realistic Vincent Price's laugh from the end of Thriller sounded when replayed using this hack. Either it didn't have enough high-frequency content to alias, or the aliases just added to the effect.
  - TedDoesntTalk 4y ago
    I have a program on disk called Apple Rock ‘83 that has 4 of those songs, including Black Dog. The author built a quiz around the songs. The others were, I think, Eruption by Can Halen and … now I forget then others.
    - pvg 4y ago
      Did you ever get around to posting it? https://news.ycombinator.com/item?id=28757274 https://news.ycombinator.com/item?id=28757274 I wonder how it will compare to other bits and pieces of Apple ][ sampled sound that are floating about.
      - TedDoesntTalk 4y ago
        I posted it after reading your comment. Thanks for the reminder: https://youtu.be/RKPaacw8UHk https://youtu.be/RKPaacw8UHk
  - Someone 4y ago
    I remember you could get a fairly high frequency (¿12kHz, maybe even 20kHz?) if you were willing to not sample uniformly. On a 6502, you would shift 8 1-bit samples into a single byte at high frequency, spend some time writing the byte, rapidly sampled 8 more bits, etc. The “write a byte” step also wasn’t constant time, as increasing the address to write to took longer when you crossed 256-byte boundaries. So, recording missed samples at predictable times. The trick was to make the playback code use the exact same timings. I think there was an article in Compute! for doing that on Commodore machines, but cannot find it.
duskwuff 4y ago
Or, even simpler -- surely you could use a pair of tape recorders to duplicate the tape, ignoring the digital aspects entirely?
- chillingeffect 4y ago
  the difference between 'dd' and analog tape copy is a regeneration of the write signal. In 'dd', the buffered data are written "freshly" from a GPIO into the cassette port. This results in a "stiff" or nearly perfect transition from '0' to '1' (and vice versa) because the output transistors in the chip are able to drive sufficient current into the high-impedance input of the cassette recorder's write circuitry mostly an amplifier (with a 20kHz oscillator mixed, but that's a long story) and the circuitry is able to generate rapid flux transitions and the tape can receive them. The resulting bandwidth of the signal into the write circuitry is roughly 20kHz and the resulting flux transitions in the ferrite are "sharp", "tall", brief, critically-damped, and quickly stablize on the microsecond scale. When performing an analog copy, those some excellent flux transitions are degraded at least 3 key distortions: First, there is limited bandwidth in the read circuitry. This is roughly equivalent to several low-pass or smoothing filters with various attenuations and cutoffs. They result from the original design intent of the recorder for audio, series inductance of the read head, and imperfect corrections for the frequency response of the media (think RIAA record curve). Additional distortions arise from noise, such as thermal, Schott, EMF, etc. There is also wow and flutter from the imperfections of the tape drive resulting in jitter. When the resulting imperfect signal is then sent to the write input of the cassette recorder, the flux transitions on the media are not as ideal and crisp as when a GPIO pin creates them. In general there are no regeneration stages, except for the "comparator" or differentiator in the input stage of the GPIO which reads the tape and determines at each time interval if the freshly-read bit is to be interpreted as a 0 or 1. The flux transitions may still be reliably read, but not after several generations of this process, and it will depend on the general quality of the tape recorder's electronic and mechanical components, tape quality, etc.
- VyseofArcadia 4y ago
  This was addressed in the article. You could for a few copies, but eventually the signal degraded to the point where a copy of a copy of a copy ... (n times) was unreadable. To combat this you would have to either dup from master, or read in (analog -> digital) followed by a read out (digital -> analog) to make a new pristine master.
NateLawson 4y ago
If you did a pure analog copy (dual tape deck), you had generation loss. Eventually copies of copies would have too much noise and thus persistent load errors. Additionally, in-band signals were included in the gaps between blocks that would mess with the auto gain control, causing an unreadable copy as the tape deck tried to compensate. The loader would skip over these sections during the regular load process. All copy protection relies on asymmetries between the production/mastering environment and the consumer equipment.

Fun read! I'm having trouble understanding how a max byte read, a la ``dd`, would somehow be insufficient to yield a working digital master of an analog cassette tape.

deleted 4y ago

[deleted]

CamperBob2 4y ago

Same here. His explanation left me feeling like I'm missing something that's at once extremely simple and extremely clever. It seems to involve the observation that reading more data than the tape actually contains will return a trailing section of random noise that will fail a checksum, but that's as far as I got. (Edit: the author posted an answer to StackExchange here: https://retrocomputing.stackexchange.com/questions/143/what-format-is-used-for-apple-ii-cassette-tapes https://retrocomputing.stackexchange.com/questions/143/what-... . A single-byte checksum is appended to the tape image written by the firmware, and the software is presumably aware of what it should be. If you were to make a copy of the tape by writing too much data, the resulting checksum returned by the firmware would probably not match what the software expected. Maybe it's as simple as that?) Another point worth making when it comes to the cassette port, is that every Apple ][ essentially came with a free 1200-bps half-duplex modem. All you had to do was "just" connect the cassette in/out ports to the phone line with simple audio amps. (ISTR using the hybrid network from an old Western Electric rotary phone to do the actual interfacing.) I don't think I've ever run into anyone else who tried this, but it was an amusing thing to play with as a kid. I built two interfaces and gave one to a friend on the other side of town. It took less than a minute to send images of Suzy and Melissa from a warez copy of Artworx's Strip Poker, as I recall.

dhosek 4y ago
The other trick was to use the tape loading routines to read audio from a cassette tape and digitize it as 1-bit audio at some low bit-rate (1.2kHz?). It sounded pretty awful and you couldn't hold much audio in RAM, but it was possible. I had a floppy with an excerpt from Led Zeppelin’s Black Dog digitized with this technique.
- CamperBob2 4y ago
  I remember being astonished at how realistic Vincent Price's laugh from the end of Thriller sounded when replayed using this hack. Either it didn't have enough high-frequency content to alias, or the aliases just added to the effect.
- TedDoesntTalk 4y ago
  I have a program on disk called Apple Rock ‘83 that has 4 of those songs, including Black Dog. The author built a quiz around the songs. The others were, I think, Eruption by Can Halen and … now I forget then others.
  - pvg 4y ago
    Did you ever get around to posting it? https://news.ycombinator.com/item?id=28757274 https://news.ycombinator.com/item?id=28757274 I wonder how it will compare to other bits and pieces of Apple ][ sampled sound that are floating about.
    - TedDoesntTalk 4y ago
      I posted it after reading your comment. Thanks for the reminder: https://youtu.be/RKPaacw8UHk https://youtu.be/RKPaacw8UHk
- Someone 4y ago
  I remember you could get a fairly high frequency (¿12kHz, maybe even 20kHz?) if you were willing to not sample uniformly. On a 6502, you would shift 8 1-bit samples into a single byte at high frequency, spend some time writing the byte, rapidly sampled 8 more bits, etc. The “write a byte” step also wasn’t constant time, as increasing the address to write to took longer when you crossed 256-byte boundaries. So, recording missed samples at predictable times. The trick was to make the playback code use the exact same timings. I think there was an article in Compute! for doing that on Commodore machines, but cannot find it.

duskwuff 4y ago

Or, even simpler -- surely you could use a pair of tape recorders to duplicate the tape, ignoring the digital aspects entirely?

chillingeffect 4y ago
the difference between 'dd' and analog tape copy is a regeneration of the write signal. In 'dd', the buffered data are written "freshly" from a GPIO into the cassette port. This results in a "stiff" or nearly perfect transition from '0' to '1' (and vice versa) because the output transistors in the chip are able to drive sufficient current into the high-impedance input of the cassette recorder's write circuitry mostly an amplifier (with a 20kHz oscillator mixed, but that's a long story) and the circuitry is able to generate rapid flux transitions and the tape can receive them. The resulting bandwidth of the signal into the write circuitry is roughly 20kHz and the resulting flux transitions in the ferrite are "sharp", "tall", brief, critically-damped, and quickly stablize on the microsecond scale. When performing an analog copy, those some excellent flux transitions are degraded at least 3 key distortions: First, there is limited bandwidth in the read circuitry. This is roughly equivalent to several low-pass or smoothing filters with various attenuations and cutoffs. They result from the original design intent of the recorder for audio, series inductance of the read head, and imperfect corrections for the frequency response of the media (think RIAA record curve). Additional distortions arise from noise, such as thermal, Schott, EMF, etc. There is also wow and flutter from the imperfections of the tape drive resulting in jitter. When the resulting imperfect signal is then sent to the write input of the cassette recorder, the flux transitions on the media are not as ideal and crisp as when a GPIO pin creates them. In general there are no regeneration stages, except for the "comparator" or differentiator in the input stage of the GPIO which reads the tape and determines at each time interval if the freshly-read bit is to be interpreted as a 0 or 1. The flux transitions may still be reliably read, but not after several generations of this process, and it will depend on the general quality of the tape recorder's electronic and mechanical components, tape quality, etc.
VyseofArcadia 4y ago
This was addressed in the article. You could for a few copies, but eventually the signal degraded to the point where a copy of a copy of a copy ... (n times) was unreadable. To combat this you would have to either dup from master, or read in (analog -> digital) followed by a read out (digital -> analog) to make a new pristine master.

NateLawson 4y ago

If you did a pure analog copy (dual tape deck), you had generation loss. Eventually copies of copies would have too much noise and thus persistent load errors. Additionally, in-band signals were included in the gaps between blocks that would mess with the auto gain control, causing an unreadable copy as the tape deck tried to compensate. The loader would skip over these sections during the regular load process. All copy protection relies on asymmetries between the production/mastering environment and the consumer equipment.