Timeline for How did Atari cassette "turbo without hardware mods" work?
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 15, 2018 at 10:42 | answer | added | Vinicius | timeline score: 4 | |
| May 16, 2016 at 1:11 | comment | added | supercat | @SF.: The Commodore tape system recorded everything twice, but in some cases a problem with the first recording would make a file unrecoverable via standard loader. ECC would allow comparable benefits, but with far less overhead. | |
| May 15, 2016 at 23:24 | comment | added | SF. | @supercat: eh. In case of Commodore, that wasn't needed. The recording was reliable enough without need for extra ecc. In case of Atari all it needed was Commodore's tape recorder system. I really, really wonder what went wrong - why a system that was created LATER, and by none else than lead designer of the prior system (Jack Tramiel) received so vastly inferior tape recorder. | |
| May 15, 2016 at 23:11 | comment | added | supercat | ...fixed with on playback by noting which block went missing, loading the correction block into that space, and then xoring everything else. | |
| May 15, 2016 at 23:10 | comment | added | supercat | @SF.: Also, I know that the Commodores at least reserved 192 bytes for a tape buffer, so if data were subdivided into 128-byte chunks it should be possible to handle the decoding of each chunk during a bit of "leader tone" for the next chunk; subdivision into chunks could then also allow for the possibility of error-correcting codes. Subdivide chunks into even and odd chunks, and after recording everything else normally, record the xor of all the even chunks and the xor of all the odd chunks. Complete loss of one even and one odd could be... | |
| May 15, 2016 at 23:06 | comment | added | supercat | @SF.: For pre-recorded games, encoding could be taken care of by a machine with extra RAM (offers benefits as a sort of copy-protection if most consumer devices don't have the RAM needed). Decoding can be taken care of by loading most of the game load in an encoded format, decoding it using some of the RAM that isn't yet loaded, and then using conventional means to load the rest. | |
| May 15, 2016 at 22:51 | comment | added | SF. | @supercat decoding after reading, from where to where? Some programs squeezed every free byte out of the available RAM. Never mind the decoding routine. | |
| May 15, 2016 at 19:44 | comment | added | supercat | ...or else have exactly two bits high and two low, then there will be five possible bit patterns that start with "1" and five the start with "0", so every four bit times will yield a one-of-five selection, while Manchester encoding would have yielded a one-of-four selection. Converting binary data to a bunch of one-of-five choices in real time would be hard, but encoding data before writing and then decoding after reading should be workable. | |
| May 15, 2016 at 19:39 | comment | added | supercat | @jdv: I wonder why I've not seen anyone try to use things like group cluster recording with tape storage, and I seldom see even anything as sophisticated as Manchester? Many drive data separators require a balance between 1s and 0s, and while that may be achieved by having every long 1 followed by a long 0, and vice versa, that's pretty wasteful of storage capacity. If one adapts rules that every group of four bit times must have its first bit be opposite the last bit of the preceding group, must not have two matching bits in a row, and must either have its first and last bits match... | |
| May 15, 2016 at 18:41 | vote | accept | SF. | ||
| May 15, 2016 at 18:37 | comment | added | SF. | @supercat: Don't put 'atari tape recorder' and 'efficient' in the same sentence. Despite baud rate (and data density, and decoding speed, and timing constraints...) roughly 10x lower than most competitors, Atari suffered worse error tolerance than others. So, no solution is too inefficient, too hare-brained, and too primitive to be used in Atari cassette recorder. The primary reason behind unpopularity of the modless turbo was even further drop of already abysmal reliability of the readouts. | |
| May 15, 2016 at 13:20 | comment | added | user12 | 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. | |
| May 15, 2016 at 8:19 | answer | added | SF. | timeline score: 5 | |
| May 14, 2016 at 21:56 | comment | added | supercat | @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. | |
| May 14, 2016 at 16:24 | answer | added | supercat | timeline score: 5 | |
| Apr 21, 2016 at 19:28 | comment | added | user12 | 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. | |
| Apr 21, 2016 at 19:19 | comment | added | SF. | @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. | |
| Apr 21, 2016 at 16:22 | comment | added | user12 | 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. | |
| S Apr 21, 2016 at 15:53 | history | suggested | fadden | CC BY-SA 3.0 |
Fix spelling in title; add tag
|
| Apr 21, 2016 at 15:52 | review | Suggested edits | |||
| S Apr 21, 2016 at 15:53 | |||||
| Apr 21, 2016 at 8:25 | history | asked | SF. | CC BY-SA 3.0 |