• Please review our updated Terms and Rules here

Why did the 5150 come with a tape connector?

voidstar78

Veteran Member
Joined
May 25, 2021
Messages
684
Location
Texas
I know the general answer to the question: IBM wasn't sure how quickly disk drives would become affordable, or if consumers would even adopt them at all (as standards and capability were evolving quickly - even the initial 160KB disk format was a little rough around the edges, though was quickly eclipsed by the 360KB standard). If production of floppy drives and or floppy disk media was somehow disrupted (and made too expensive too home/office users), then there would be a Plan B to load/store stuff from tape.


My question is more this: why couldn't tape support have been provided through the serial port? Isn't a tape storage basically equivalent to about 300 to 2400 baud, which by 1981 could be matched by a serial port? Or maybe it could be done, but the R&D time to have Cassette BASIC support such a thing would have taken too long? (in terms of getting the 5150 on the market) Or maybe it was since cassette to 9-pin cables already existed in plenty, nobody wanted to try making new cassette to serial cables?

Can the 9-pin cassette connector be thought of as a specialized serial connection? In that perspective, maybe it is cheaper/easier to have onboard support for the 9-pin connector, rather than trying to add a 2nd serial port.
 
Lots of reasons! The serial standards at the time generally used +/-12V signalling, so wouldn't have been electrically compatible with cassette ear/mic sockets - a powered adapter would be needed, not just a passive cable. Also the serial hardware was much more sophisticated than cassette hardware. Serial ports have hardware to convert a byte to a series of bits and back. With the cassette interface, this is done in software and the hardware is much simpler (especially given that almost all of it is shared with the speaker). So there was room to include the cassette interface on the motherboard, whereas a serial port was an additional (optional) add-in card. Putting the cassette interface on an add-in card as well as the disk interface would mean that the base configuration wouldn't have any storage I/O at all.
 
Ah, I didn't realize the serial port was an optional add-in.

But instead of the keyboard + cassette 9-pin DIN, the onboard cassette port could have been a serial port instead (right on the mainboard). Just I'm not sure how doing so would impact the size (of the mainboard), cost (more lines to trace/run), and schedule (getting released within '81 - BASIC ROM code would have to be adapted to interact with a serial port, maybe no existing code for that).

Some '79-'80 PETs/TRS-80s didn't come with any storage - just turn on, type some BASIC, turn off. But yeah, having to coordinate some "tape interface adapter" (sold separately) might not be practical, not as clean of an integrated solution.

Still curious that no independent "serial port based storage device" was ever developed third-party. It'd be slow, but couldn't you run it like 100feet? (well I forget the line length limit on serial cables)
 
What would you store the serial port data on? It would require a smart device at the other end to take the serial data and save it. The cassette port BIOS code sends sound (at 1000 Hz and 2000 Hz) which the standard audio cassette deck can handle.

There were a lot of serial based storage devices available in 1980. Have you considered paper tape? Or Punch cards? Or the Exetron Stringy Floppy? There were others. A whole banquet of relatively high speed serial port storage devices were marketed for the Tandy Model 100.

IBM didn't know how the PC would be used so included most of the features that the competition had. The cassette port was necessary for the initial prototypes of the 5150 since it took 6 months to get the disk controller and DOS working. BASIC, video card, and keyboard would have been thoroughly tested thanks to code saved on cassette. Anyone who worked on a microcomputer trainer would have had to develop a cassette interface and adapting the design to the 8088 isn't hard.

IBM did figure out that the cassette port would be little used. IBM didn't order cables or cassette decks before release. Radio Shack could have met the needs for a few PCs but I doubt they had the 50,000 cables in stock to handle the planned first year of 5150 production. The big change was the drop in prices on floppy disks. When the cassette was less than $1 and the floppy disk was $5 each, there were software to back up to cassette and software that was shipped on cassette to be installed to the disk drive. But by 1982, the floppy disk was cheaper than the cassette.

The 5150 was price competitive with the Apple II and TSR-80 in a loaded configuration with disk drives and lots of memory. The stripped down cassette only 5150 was a poor value since so much was charged for empty slots and drive bays.
 
Oh, gosh, serializing to an old paper tape reel would be wild just to watch - like creating an old player piano roll. But you're right, any (storage) device constructed would be like at least a shoebox size and expensive (and need its own power, as mentioned - yet another cable to run). [ but to me, it'd be fun to watch - a tiny parallel set of 8 hole punchers crunching away ]

I don't think EEPROMs were quite ready in early 80s (at least not in any affordable/sizeable fashion) - I suppose I was thinking of whatever Nintendo used to saved games on their cartridges. Yes, that's later 80s, and would be moot anyway due to the drop in disk drive and floppy costs. (and again to your point, you'd need darn near a whole NES to operate the cartridge, not cheap/practical).


I guess maybe it's unfortunate that it took until DOS 6.22 to realize an interlink cable, where you basically use an entire other IBM PC as the "serial based storage device". Was trying to think of ways someone could get new content onto disks if they had a model A 5150 -- but suppose they didn't want to even open the case (i.e. not install a NIC or XT-IDE), but suppose that they did have early DOS system disks available. They could use the serial port, but they'd need to somehow get access to running the interlnk.exe stuff (i.e. nothing on the old PC-DOS 1.X/2.X disks would help, and Cassette BASIC can't {easily} talk to disk drives). I guess maybe DEBUG.COM on those old DOS disks could construct a suitable program, but you'd have to hand type quite a few (thousands?) of instructions.


And you made another good point about the need on the prototype 5150 since none of the disk hardware was yet available. (so instead of thinking of it as a cassette data port, think of it as like a diagnostic port)
 
If you haven't already, check out these very early design documents of what would become the IBM PC, from circa August 1980:

https://www.os2museum.com/files/docs/IBM_PC_Design_Drawings.pdf

At this point the plan for the "personal configuration" was to have NO RAM on the planar and use the 16KB on the CGA card as combined video and system RAM! So the cassette port was intended as an ultra-cheap storage medium to use with this configuration.

Because the design already included an 8255 PPI (for the keyboard) and an 8253 timer (for the DMA refresh and system timekeeping) the speaker and cassette ports didn't really add any extra cost -- they just used some spare I/O pins from the PPI and a spare channel in the timer. The only parts on the 5150 planar that are dedicated to the cassette interface are an op-amp/comparator, a relay, and a handful of passives. So it was essentially "free" to add it.
 
Wow thanks, wonder what the lines were drawn with - they had Sharpie's then? That's no sissy pencil (thick lines). [edit: Sharpie 1964, i never knew that ]

And on the last page it mentions thinking of having the keyboard use the serial port (would doing that have the same problem of needing an extra power cable to your keyboard?).


Wonder why they felt the 8087 support was so important. My impression is the 5100 was catered more for engineers, scientific computing (at least on intent, it may turned out to be more used for accountants or business?). That intent maybe carried over to the 5150 perhaps - but ended up being little utilized (or maybe more 8087s ended up being installed in the 5150s than I realize).
 
Last edited:
The IBM PC shipped with a serial keyboard that went to a dedicated port which I think is what was described. It should have been cheaper than the parallel port cable that the System/23 used with the floor model.

IBM released APL in 1983 which required the 8087. I think it even shipped with the 8087 and a replacement 8088 since very early 8088 chips didn't work alongside with the 8087. Fitting that you mention the 5100. The 5100, 5110, and 5120 had the option of APL in ROM in addition to BASIC in ROM.
 
At this point the plan for the "personal configuration" was to have NO RAM on the planar and use the 16KB on the CGA card as combined video and system RAM! So the cassette port was intended as an ultra-cheap storage medium to use with this configuration.

I rather badly would like to know if any examples the 40x16 alphanumeric / 280x192 graphics TV adapter card envisioned in this doc existed or if it just evolved straight into the CGA card as we know it. It reads like a bizarre combination of TRS-80 and Apple II video capabilities, which is of course awesome.
 
I rather badly would like to know if any examples the 40x16 alphanumeric / 280x192 graphics TV adapter card envisioned in this doc existed or if it just evolved straight into the CGA card as we know it. It reads like a bizarre combination of TRS-80 and Apple II video capabilities, which is of course awesome.

Fascinating document! I'd be very surprised if the 280-pixel card was ever built. It would have added significant extra complexity to have the character clock switchable between 7 pixels (for text modes) and 4 pixels (for graphics). It's clearly inspired by the capabilities of the Apple II but character clock considerations caused that machine to have a much more complicated graphics memory layout, with 8 bits per 7 pixels (the last bit being the half-pixel phase offset bit which switched between orange/blue and magenta/green pixels on the composite output).
 
Fascinating document! I'd be very surprised if the 280-pixel card was ever built. It would have added significant extra complexity to have the character clock switchable between 7 pixels (for text modes) and 4 pixels (for graphics).

On a toy video card project I was banging on a few months ago (haven't touched it in too long, unfortunately work got... exciting) I was able to implement a state machine switchable between 6 and 8 pixels per character/graphics cell in a single GAL so I don't imagine that would be a huge problem. A system like this would impose some kind of interesting mismatches in screen format between graphics and text mode; it would be a huge PITA to draw 7 bit wide characters for a 40 column display in the high-res mode so you'd probably want to treat it as a "35 column" machine when splatting bitmaps. Although I guess that wouldn't be that weird; didn't the TMS9918A display generator have a 40 column text mode that used 6 bit wide characters in a 240x192 grid while its normal "tile" graphics/semigraphics modes were 32 8-bit cells wide for 256x192?

I also think it's interesting that they specify that strange 40x16 display grid with 12 scanlines to allow room for descenders in text mode. Lots of early video cards used 32x16 or 64x16 because it was convenient "electrically" but 40x24 was conquering the world by the late 70's so, yeah, 40x16 is a weird neither-fish-nor-foul thing.

That idea of running the whole system off the video card memory did make me snicker imagining the amount of screen snow you'd get if you tried running code from an original CGA card's RAM in 80 column text mode. ;)
 
There is also some thought that IBM included the cassette port so they could officially sell a "base" unit with no floppy drives as a complete "functional" computer.
 
The PCJr managed to use video card RAM for the CPU without having snow. Had IBM tried to run the 5150 off the CGA card RAM and had there been snow in the lower resolutions the card would use, I am sure IBM would have resolved the snow issue. I think the 80 column mode on CGA was a late change and there just wasn't time left to deal with the snow.
 
The PCJr managed to use video card RAM for the CPU without having snow. Had IBM tried to run the 5150 off the CGA card RAM and had there been snow in the lower resolutions the card would use, I am sure IBM would have resolved the snow issue. I think the 80 column mode on CGA was a late change and there just wasn't time left to deal with the snow.

Of course the PCjr takes a pretty massive performance hit from sharing the video RAM. CGA manages to mostly avoid contention (on writes at least?) because it has LS374 buffer/latches for incoming data and CPU addresses that I *think*, if I'm understanding this correctly, allow it to defer memory writes to sync up with the card's refresh timings? (The manual claims it implements "dual ported" memory in everything but high-res text mode, and staring at the schematic that's my best theory as to how they make that claim.) My guess is when it's running at the 80 column text pixel memory drain rate (which is twice as high as high-res graphics) there's no more bandwidth left over to let it "slip" the incoming writes. What's interesting, however, is the card does tie to the IOREADY signal to generate wait states, and... it must use that for CPU reads in all modes, because while those buffers could effectively make it dual-ported for writes there's no mechanism for doing the same for read?. Has anyone ever benchmarked a CGA card to see if it's slower to read from it than to write to it in graphics mode? Or maybe that wait state circuitry is used to "fix" synchronization issues so the CPU and video refresh end up in lockstep? If so that's really cool

(It does suggest you're correct that not preventing snow was a late oversight because they *do* have the wait state generator circuitry on the card already, they could have triggered it for 80 column writes. Maybe they didn't think it'd be acceptable performance-wise to hold the CPU until the next horizontal porch, assuming it's true that in 80 column mode the memory bandwidth on the original CGA is literally saturated?)

Of course the TV-centric video card described in this PDF would need significantly less RAM bandwidth than CGA in every mode it documents, with the exception of 280x192x4 colors, so any contention/wait states wouldn't matter. It says the text attribute selection would be limited to the 8th bit of the normal ASCII cell (ala Commodore PET's reverse video bit) so the text mode bandwidth is half of CGA's. The only mode that would come close to a CGA mode in bandwidth needs is the 280x192x4 color graphics mode. (Which would need twice the bandwidth of the text mode.)
 
The wait states on a CGA card are the same for reading as for writing. Indeed the CPU and CRTC VRAM accesses are put into lockstep by the wait states (the raster beam is aligned to a boundary of 16 hdots after an access). The wait states are active in all modes including 80-column text mode (which is why snow only appears on every other column). The memory bandwidth is saturated in 80-column text mode. Video writes using the BIOS routines are held until the horizontal overscan/retrace period, but software that accesses the CGA hardware directly can bypass this for speed.

The PCjr got around snow by having twice as much video memory bandwidth, which was achieved by having twice as much VRAM. If the CGA had been designed to have 32kB, it would have been able to do 80-column text mode without snow.
 
The Jr. does still take a pretty big performance hit from having to share. It's not impossible to do better, the Tandy 1000 is broadly similar yet manages to be quite a lot faster according to benchmarks running from VRAM (for reasons that pretty much boil down to "better hardware algorithm, no doubt due in part to not being designed to support a hobbled 64k version too"), but the Tandy method still relies on having two banks of memory. I guess that's still neither here nor there for this "TV Card" given its pretty low bandwidth requirements, if it used the CGA card's method of syncing up access it should be fine with a single bank.
 
I guess the idea with the 280x192 graphics mode is that it would take up 13K of the 16K shared video/main RAM on the barebones model, leaving around 3K free, or about the same as a VIC-20?
 
There is also some thought that IBM included the cassette port so they could officially sell a "base" unit with no floppy drives as a complete "functional" computer.
That's what I always assumed; it was there to create legitimacy to a diskless system which didn't practically exist. By providing a cassette interface and 16KB RAM as a base then it meant they could advertise the 5150 at a tasty-sounding starting price point which would get people drawn in and then quickly upsold to a more usable specification once it was clear the computer was actually very good but not in base configuration. If you were in the market for a budget computer with cassette and 16KB RAM you would already not be contemplating the price that an IBM PC was selling for so this option was clearly not really aimed at you; the 5150 was clearly designed with users who were going to have disk drives and hundreds of KB of RAM in mind - almost immediately this became the only practical configuration to consider.

I doubt the cost of including cassette was that great - development time on Cassette BASIC would have been minimal since it was just a ROM-based version of disk BASIC with a different storage device, the cassette interface itself was off-the-shelf, and given the margin on an IBM product there was almost certainly enough there to equip every system with an extra 5 pin DIN connector for the cassette (which they would already have ordered in bulk for the keyboard connector anyway) without hurting the bottom line on the product too much.

IBM never released an official cassette deck, nor even (AFAIK) an official cable to connect to the cassette interface. They never did anything to try and promote cassette-based software on the PC, and there was no (official) way to access the cassette interface from DOS. Then the first update to the PC dropped it. Seems to me like it was a solution to a problem marketing had rather than something that was ever intended to be used.
 
IBM didn't supply much support for anything. I think someone could have requested an explanatory white paper to make a cassette loader like the Diagnostics program. Note: there are a few mentions of cassette within the internal IBM PC newsletters. IBM was ready had the cassette only system taken off.

The cassette offered a few minor marketing benefits. I think some school districts included a requirement for the system to be able to use standard connection audio cassette decks in order to steer contracts away from S100, Commodore, or Atari. There was a surprisingly common educational concept of a proto-network with shared disk drives but all the student work would be stored on a local cassette. IBM wasn't going to lose that market over a one dollar set of parts.

The big advantage of Cassette Basic was the 32K reduction in memory needs. Any clone trying to load Extended Disk BASIC would have no free memory on a 64K system. The clone would need to upgrade thereby spending an extra $200 just to match IBM's capability. Well, up to the point where 64kbit RAM chips meant the most common system had 256K.
 
Back
Top