Skip to main content
Retrocomputing

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

25
  • 2
    @mnem: Compatibility with what? When the C64 was introduced, there were two computers that used that style of port (the C64 and the VIC-20), and there only existing drive that used that style of port (the 1540) wasn't compatible with the C64. The C1541 was a tragically-bad rush job; it kinda sorta worked, but should have been way better. Commented May 14, 2016 at 22:46
  • 1
    I recall having read an article which explains why the 1541 was so slow, and it seems like there was a mistake in the design of the CIA, and an operation that was meant to be handled by hardware had to be emulated by the CPU using bit banging, and hence, slower Commented May 15, 2016 at 0:06
  • 1
    @supercat It should be noted that cassettes were an inherently unreliable media (especially for digital/data) and most of that unreliability (in the short term) came from tape stretch. Engaging the read/write heads while it was in FF/REV speeds would naturally exacerbate that problem. The only obvious way to compensate for this problem would be to use shorter tapes (both because shorter means less stretch and because shorter tapes could have thicker mylar) which would mean less data storage. Then there's the long-term problem of dropouts from coating wear, made much worse by hi-speed R/W. Commented May 16, 2016 at 15:47
  • 1
    @RBarryYoung: Abuse of tapes could obviously cause trouble, but tapes were considered suitable media for music where a momentary 1% speed deviation would be quite noticeable. The only case I would think higher speed would make things worse would be when hitting the start/end of a tape, and if a tape had a suitable leader on the ends I wouldn't think the leader could take the brunt of that rather than the reset of the tape [indeed, I my understanding is that part of the purpose of the leader is to protect the rest of the tape]. Commented May 16, 2016 at 15:54
  • 2
    @mnem: Many encodings allow synchronization on each bit, which should allow them to tolerate 5% stretching without any problem whatsoever (RS-232 communication only synchronizes once every ten bits and can tolerate up to 5% speed mismatch between sender/receiver). For many encodings, even arbitrarily lengthening or shrinking individual bits by up to 25% would have no effect. Why should data be more readily corruptible than music, where a transient pitch change of even 1% would be noticeable and 5% would be obvious? Did some playback routines count pulses without synchronizing on them? Commented May 16, 2016 at 18:47