Talk:IBM cassette tape

Proposed merge

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

• Oppose merging this article to the IBM Basic, Cassette basic (article section). IBM basic is a programming language, whereas IBM Cassette tape is a cassette tape interface that was also used on some clone computers. They're quite different topics, conceptually. Northamerica1000^(talk) 13:14, 10 January 2012 (UTC)

Was there even one clone that had a cassette port? Aside from the PCJr. I would be very surprised to find a third-party motherboard that had a cassette port on it. It was a very minor temporary feature of the IBM PC product line that disappeared early on, and really had no practical use aside from that tiny handful of people who bought diskless 5150's to play on BASIC. This quirk should be combined with the IBM BASIC article because it had no uses outside of BASIC (and precious little within BASIC). --Wtshymanski (talk) 14:20, 10 January 2012 (UTC)

I cannot recall the name of these "no-name" clones after all these years, but I have seen several of the more straight-forward clone mainboards which featured a cassette port, presumably identical to the original IBM solution since they used the same 5-pin DIN plug. I have also seen clone mainboards, where the plug was not assembled, but apparently could be retrofitted.

How do we know that it had no use outside IBM BASIC? The ROM BIOS had INT 15h service functions so it was quite easy to use the cassette port from inside one's own DOS or CP/M programs. I haven't used the cassette port myself beyond curiosity, but I'm certainly not up to say, nobody else did. Whatever, there's more that could be written about the cassette port (modulation, data headers, etc.), which would be totally off-topic in the IBM BASIC article. Actually, I started to add some info (which you partially removed), as I happen to own the technical reference documents for the original IBM PC including full schematics and BIOS source code (probably quite rare these days) and little reliable information can be found about the port on the net. Since WP aims to be a reliable reference, I put it in although this article is otherwise not in my focus right now.

When discussing the future of an article we should not only look at what is written right now (not much), but envision would could be written about a topic to make it a comprehensive article over the next decades (assuming that knowledgeable people come around and dedicate their time). If we merge the stuff right now, we ultimately reduce chances that someone else will be motivated to add the missing info and split the articles again in the future. Adding snippets of information until there's enough for someone to pretty-type it are ideal tasks for IP "drive-by" edits, but they cannot create/split articles and therefore they might never add their info into a mostly unrelated IBM BASIC article (or their edits would be removed there since they would be mostly off-topic in there). So, if they are distinguished enough by their topics, give those little articles a chance to grow over the years. --Matthiaspaul (talk) 17:33, 10 January 2012 (UTC)

Small follow-up regarding the recent edit: I located the machine I thought would be equipped with a cassette port in the attic, but this computer turned out to be newer, an XT clone -- without cassette port. This was clearly not the mainboard I remembered also for other reasons; the board with the cassette port had all ICs (not only the RAM) socketed, and it had various hand-soldered wire patches - so it seems to have been an early revision. Chances are that the machine I thought I would still have in storage is long gone, but I will dig deeper in summer, since there are still some parts boxes with "spare" mainboards. --Matthiaspaul (talk) 20:32, 23 January 2012 (UTC)

I look forward to the result of your searches. It's hard to credit now (30 years on) but at the time there was intense interest in IBM PC clones; we had massive magazines like "Computer Shopper" and "PC Week" which for a while were coming out biweekly or weekly. I was rather intensely interested at the time, and yet I don't recall any reviews that state a product was such a faithful duplicate of the 5150 that it even included the useless cassette port. I think even in 1981, the writing was on the wall for cassettes as a data storage medium and if you could come up with the $3000 for a PC clone, you weren't going to balk at extra $750 or so to get a real "professional" diskette drive instead of the cassette.Even IBM dropped the cassette hardware rapidly, though their interest in backwards compatibility was so high that even PS/2 machines had cassette BASIC in ROM. --Wtshymanski (talk) 22:14, 23 January 2012 (UTC)

• Oppose to the merge as well, for the same reason as given by "Northamerica1000". See also the discussion here: Talk:IBM BASIC#Proposal to merge "IBM cassette tape" and "IBM BASIC". --Matthiaspaul (talk) 16:48, 10 January 2012 (UTC)

It just seems weird to have a whole article about a cassette port that was only theoretically useful. You'd as well have an article on the cassette port on a Sinclair ZX 81! There was never any commerically-distributed software fot the IBM PC on cassette (unlike the Sinclair, many Commodore products, etc.), and if the cassette port was so important, why did IBM drop it on the XT? If the IBM cassette port is [WP:N|notable]], we need some sources to say so, otherwise its a candidate for AfD instead of just merging it as a funny little section to the IBM BASIC article. There is zero potential to grow this article beyond a stub. --Wtshymanski (talk) 19:06, 10 January 2012 (UTC)

• Important note – There is also discussion occurring on the talk page for the IBM Basic article that has occurred here. As of the time of this post, there is one "oppose" comment on that page. Northamerica1000^(talk) 09:10, 15 January 2012 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Dubious

There's a one-line comment in Info World that some users reported catastrophic results when mixing the cassette and keyboard plugs. I don't know of any references other than that one line in a photo caption - it couldn't have been a widespread problem. If you plug the keyboard into the cassette plug of the PC, there's no significant voltage on any of the pins. I suppose if you were to plug your cassette recorder into the keyboard socket, that you'd put +5 volts onto the cassette output...but since the +5 volts returns on the "data in" pin, there would be a reasonably high resistance. I'm sure if it had been a common problemthere would be more references available. I think it's misleading to emphasize this in this article. --Wtshymanski (talk) 19:48, 23 January 2012 (UTC)

Pin	Keyboard socket	Cassette socket	Effect if cassette plugged into keyboard socket	Effect if keyboard plugged into cassette socket
1	clock	motor relay common	Grounds "clock" output line of motherboard	No effect
2	Data into PC	ground	No effect	Grounds keyboard data output but no supply voltage to keyboard
3	No connnect	Motor relay	No connection on motherboard	No connection in keyboard
4	Ground	Data in	Cassette sees ground on data in	Keyboard has no ground connection
5	+5 V	Data Out	Cassette sees +5 on data out (speaker) line	Keyboard has no supply voltage

Relative speeds are exaggerated

I know tape is slower than disc, but I think the comparison here is laying it on a bit thick. The raw ~1500 bit/s, or approx 187 bytes/sec achieved by the tape deck would be fairly close to the actual data rate, minus 1/128th for the CRC, and the small gaps between blocks (with each block being between 1 and 2 seconds in length); if we're pessimistic and say 1024 bit/s average thruput, that's 1kb in 8 seconds, or a base-model-memory-filling 16kb in about two minutes.

The 250kbit/s of the original IBM floppy disc controller (which could also be used for high speed tape drives etc) is more accurately the speed of MFM encoded signals being recorded to the actual media, and there's quite a lot of overhead, and not a particularly high duty percentage. It would be more accurate to figure the realworld data rate, as 250kbit is about 31kb/sec, and you're not going to find any 180kb disc drives that can read or write an entire disc in a mere six seconds... or a 360 that does it in twelve... or a 1.4mb that does it in 46... (in fact the 3.5" HD format which crams in twice as much data per track and has a much higher speed controller typically takes 90 seconds to fill or empty a disc).

The disc media spins at 300rpm, or 5 times per second, and has 9 sectors per track (and 40 or 80 tracks, and 1 or 2 sides - however, as it's a serial interface, and only one head is active at a time using a binary select line, double sided drives are no faster than singles, and the number of tracks doesn't make much difference). Each sector transfers 512 bytes of useful information plus a certain amount of overhead (CRC, sector # and sync, etc) - to keep it equal to the tape, however, let's assume that comes to 4 bytes per sector. Also, because of the speed of processing by both the drive controller and the OS, it's not usually possible to read or write an entire track at a time with anything other than specialist high speed disc-at-once imaging software (which isn't much use for everyday file access), and there has to be a certain amount of lag between successive sector reads which exceeds the amount of physical space (and thus time taken to spin from the end of one to the start of the next) given over to the actual gap.

(If each track was filled continuously at 250kbit/s, then each one would contain 50,000 bits of information, or 6250 bytes, equal to 12.2 sectors; maximum data load per sector with a disc formatted to a dangerously dense 12 sectors/track (and thus 240k on an otherwise 180k disc) would be only 520 bytes plus a sub-byte gap, which might not actually be enough. (Highest I've seen on double-density discs is 11 sectors, and those tended to be unreliable... however, Apple appeared to manage varying between 8 and 12 sectors in their own drives... whether this involved a slightly faster controller (ie 256k) or a slightly slower drive mechanism (even just 295 rpm...), who knows ;) )

A very simplistic, primitive format has all the sectors in strict numerical order, and therefore, thanks to this quirk, can only read one sector per revolution, and has to waste a whole revolution in order to resync after stepping the head by one track (even though the slowest typical step takes only 12ms of a 200ms rotation, or a little over half a sector). A higher speed format which arranges the sectors out-of-order (and skews each successive track by a certain amount) can accelerate this quite significantly, but is beholden to the physical layout itself and still has to allow a reasonable gap; thus with 9-sector discs, about 3 sectors per rotation (and 3 rotations per track, plus approximately a third of a rotation lost to stepping). Double sided discs get a very small speed bonus as they can switch seamlessly from reading from head 0 to head 1 without having to step to the next track, but not really enough to be worth calculating.

Thus, our net transfer speed for 16kb (16512 bytes including the CRCs) coming off that disc (or just over 3.5 tracks) is a minimum of:

Raw reading times of 32 sectors x 1/5th of a second (for a full revolution) = 6.4 seconds Track skip times of 3 x 1/5th of a second (ditto) = 0.6 seconds Or 7 seconds all up. IE about 2359 bytes/sec or 18871 bits/sec. Still the better part of 18.5x faster than tape, but not 125-250x faster.

Maximum speed is, well, about 3x quicker still, as each of the component parts is made 3x faster. So, a pretty impressive 2.3 seconds (instead of 120+), and ~56612 bits/sec.

Ergo it's upto about the same pace as a maxed out phone modem, but if you're using less intelligently formatted discs it's more like an older 19.2k one.

Plus for each format there's some setup time and so-on. In other words effective bitrates are about 1.0kbit/s for tape, and about 18 to 56kbit/s for disc. Still a stark difference to be sure, and even more critical once we go beyond 16k (where tape loading times are equivalent to what HD floppies eventually started to demand) and onwards to 64k or more, so the difference becomes one of 8+ minutes vs less than 30 seconds (or even, less than 10 seconds)... 193.63.174.115 (talk) 15:57, 23 August 2016 (UTC)