14

There were some cassette copying programs for 8-bit Atari, that boasted saving the games in a way that would load it at up to 1800baud - versus the standard 600baud, which was a significant improvement, and without requiring hardware modifications of the cassette recorder.

How did they work? And why wasn't that the standard used everywhere?

(IIRC, the program "Warp Copy" was an example of this.)

Improve this question
14
  • 1
    Many older computers did all the bit-banging for the cassette in software, with almost no hardware. This was done (at least for the TRS-80 Model I) as a cost-savings measure. Is the Atari we are talking about there similar in this regards? (I don't know, so I can't make a real answer.) If so, it is pretty much a matter of hooking into the routines to tweak raw I/O being fed to the cassette port.
    – user12
    Commented Apr 21, 2016 at 16:22
  • 1
    @jdv: Atari used the same interface for cassette recorders with turbo mods, and for disk drives, which both outpaced "Warp" by orders of magnitude, so the CPU speed definitely wasn't an issue. Also, older competitors (C64, ZX Spectrum) used vastly faster tape recording system, which was ported to Atari by independent firms, as the "Turbo" - and it was a mod to the cassette recorder only; the computer only needed a short bootloader to handle it, all in software.
    – SF.
    Commented Apr 21, 2016 at 19:19
  • I wouldn't expect the CPU speed to be a factor. It sounds like these utilities for your Atari just hooked into the I/O and tweaked the signalling rate (and whatever else needed to be adjusted for that.) All you need is a decent clock source. If Atari used the "Kansas City" protocol, or similar, then it would have been pretty robust in the face of noise and timing, too.
    – user12
    Commented Apr 21, 2016 at 19:28
  • @jdv: I've never heard the phrase "Kansas City protocol". It seems awful slow, though; I would think Manchester encoding would be much more efficient. Adding an ECC layer on top of Manchester coding would allow it to be robust against things that would kill KC protocol while still leaving it more efficient.
    – supercat
    Commented May 14, 2016 at 21:56
  • The encoding follows the hardware capabilities. And early micros use software only level encoding to keep the bill of materials shorter and cheaper. Kansas City was an accord to allow for certain levels of interoperability.
    – user12
    Commented May 15, 2016 at 13:20

3 Answers 3

Reset to default
5

If one doesn't need particularly high data rates, it's possible to implement data-to-audio and audio-to-data routines in a very small amount of code. To store a "1", generate 250us of high followed by 250us (e.g.) of low; to store a "0", store 500us of high followed by 500us of low. Note that some tape-drives' electronics, which are designed for analog signals, will try to adjust the signal try receive so that it's high about half the time and low about half the time, and the signal may get badly distorted (and thus become illegible) if the high and low times aren't close to being balanced, which is why tape formats seem to waste half the storage capacity writing each bit twice.

If one is willing to use more complicated code for recording and playback, it's possible to use a mixture of different pulse lengths, encoded in such a fashion that the high and low times remain balanced. Such approaches can allow more than twice as much information to be stored as the simple straightforward technique, but require more code to read or write data. For a computer to include built-in support would have required that manufacturers devote hundreds of bytes of ROM to that purpose that could otherwise be used for other things.

For programs shipped on pre-recorded tapes, however, the size of the record/playback routines is not an issue. The data can be written on the tape using specialized equipment, making the size of the record routines irrelevant [if the encoding is one that couldn't be written by a standard computer, that would actually be a bonus]. The size of playback code is also not much of an issue. Even if playback code would take 1024 bytes, it could be used to load all but 1024 bytes of RAM; if it would be necessary to load even more than that, the last little bit could be loaded using a slower but smaller routine (or perhaps the built-in one).

Improve this answer
2
  • 'Warp Copy' was not for pre-recorded tapes though. You'd load Warp Copy, then the program/game from a floppy, then it would save the 'turbo' bootloader followed by the game, no specialized equipment, no special computers. Completely independently from that some games were compressed - after loading you'd see colorful bars blinking on the screen for a while as the game decompressed (the decompression routine usually stored in memory that the game would overwrite and use to store volatile state once started); the recording on tape was the same as usual with these though.
    – SF.
    Commented Jan 23, 2019 at 12:33
  • @SF. My use of "prerecorded tapes" was to distinguish from "tapes written without any special utilities loaded into memory". I'm not sure what term would be best to make the distinction, or if I should just write out the whole phrase.
    – supercat
    Commented Jan 23, 2019 at 15:48
5

Actually, in that case, no fancy algorithm changes were used - the tape recorder was literally "overclocked" - frequency of interrupts handling communication with the tape recorder changed.

I found a program that allowed to override speed on the standard C: handler. It allows operation at up to 1400 baud, but as the author writes, the ability to use higher speed is "an individual property of each tape recorder and requires high-quality tapes."

Let me translate the segment of the article that addresses how the program actually works.

For the curious: After being loaded, "Selector" searches hatabs for the address of the C: handler, and basing on it, it creates its own, with modified "OPEN" and CLOSE" procedures. [note, read/write procedures are umodified! --SF.] New table address is attached to the standard handler, so it doesn't ocupy extra space. The speedup is based on modification of the serial bus interrupt vserini and corresponding setting of the POKEY work frequency registers for duration of the transmission. The interrupt change occurs only on opening the C: device and is restored after its closing in order to enable normal use of a disk drive. The control keys are passed from the keyboard interrupt. The program is immune to warm start of the computer. Good luck in turbo'ing!

Improve this answer
4

With Atari, some or combination of the following practices were used:

  • Increasing block size from default 128 bytes to more bytes. Fewer blocks resulted in fewer overhead bytes (calibration sequence, record header, checksum) and fewer IRGs (gaps between blocks)
  • Reducing duration of the IRGs (standard duration was 0,25 s)
  • Increased baud rate. The FSK demodulator in the data recorder was optimized for 600 bps, but it was possible to squeeze better baud rate from it (even 900). With that, the condition and build quality became essential. Typically the best performer was the Atari 1010.
  • Decoding data by directly polling the serial input pin bypassing POKEY's shift registers.

All these three practices reduced time available to process data (the IRG is present to allow CPU to process the data just read), so some loaders were forced to completely disable DMA (blank screen) or use a display list with minimum CPU overhead (one or two lines of GR.1 or GR.2 to display program name).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .