PlayCable research and development

[+DZ-Jay]

According to this, dave1dmarx has an audio recording of buzz bombers loading through playcable. If that is correct than it's evidence of playcable having 8K games in 1983. I should have known since I asked the question.

http://atariage.com/forums/topic/263689-playcable-menu-music/?p=3727197

 

That would mean that the only cartridges not compatible with playcable at that time were vectron, chess, bumpnjump, pinball, motu, three of the voice and all but one of the ecs cartridges.

 

Yes. I think the whole "the games were limited" issue is a red herring. It appears that people were not subscribing as fast to the service as Mattel had hoped. Certainly the numbers didn't match the expectations (I believe I read that only about 3% of potential households had subscribed within a year or two of release). Plus the CableTV carriers were balking at the expense of setting up and maintaining the service, which hurts even more in light of the lackluster demand.

 

Therefore, I think the memory limitation was just the very least of its problems, and perhaps only mentioned as a added insult to the injury (e.g., "it cost too much, people didn't want it, it wasn't doing too well -- oh, and to top it all off, it wouldn't have worked with later titles anyway"), but not really as an actual root cause.

 

I'm sure that had it taken up like gangbusters, Mattel would have started figuring out how to bank-switch games or perhaps even upgrade the machine to support newer titles.

 

All that said, this entire thread is very cool and provides some very interesting insight into what was once a promising technology that to me always felt like "The Future."

 

-dZ.

Edited October 28, 2018 by DZ-Jay

[mr_me]

I still need hear the audio recording of playcable loading buzz bombers to debunk the myth.

 

The 3% is actually not low. It's from the pool of cable subscribers not just intellivision owners. The 3% number is actually slightly higher than the general household intellivision adoption rate. So that means a high percentage of intellivision owners that had access to playcable subscribed to the service.

[+DZ-Jay]

I still need hear the audio recording of playcable loading buzz bombers to debunk the myth.

 

The 3% is actually not low. It's from the pool of cable subscribers not just intellivision owners. The 3% number is actually slightly higher than the general household intellivision adoption rate. So that means a high percentage of intellivision owners that had access to playcable subscribed to the service.

 

What I read was that the expectation was that the pool of CableTV subscribers adopting the PlayCable would actually increase the rate of Intellivision adoption. That was the problem: it did not.

 

Like Apple today, Mattel was making money from hardware sales. The PlayCable was a service intended to increase those hardware sales, which was not happening.

 

That's why I think that, although it would be interesting to find out for sure, this "myth" that you are trying to debunk is mostly inconsequential. To me it always sounded, as I said above, like some throwaway comment someone would say to add insult to injury, perhaps to further rationalize the loss: "it wasn't working, people didn't care for it -- oh, and it didn't work with newer titles."

 

The truth appears to be that PlayCable adoption was failing even before the game-list limitation could became an actual concern. Nobody refused to get the PlayCable because it couldn't play, say, B-17 Bomber -- they just didn't know/care/wish/desire/afford the peripheral. Even the Intellivoice was failing in the market with lackluster adoption -- as befitted Mattel's expectations at least.

 

Still, that's not to say that it wouldn't be interesting to find out which specific games were and were not available at the time to use in the PlayCable; just that the focus on it seems misplaced to me. *shrug*

 

-dZ.

Edited October 28, 2018 by DZ-Jay

[mr_me]

Playcable did help sell intellivisions. In areas where playcable was available more people bought intellivisions than areas where playcable was not available, albeit slightly. In the early 1980s, there were 16M households in America on cable, yet only 650k had a cable provider with playcable. Had 50% of cable operators invested in playcable, subscriptions and revenues would have increased 12x. The problem clearly was not user adoption but adoption by the cable operators. It was popular with users. It was expensive for the cable operator not the end user.

 

Even if program size was limited to 6K, it clearly was not the problem because by the end of 1982 (two years into playcable) only vectron and the voice cartridges would have been incompatible, if vectron was released by then. In 1983 and going forward the 8k limit was most definitely an issue. But Mattel, by then, had bigger problems to worry about.

 

There have been more tham a few articles written about playcable that say the memory limitation is 6k or 4k. It's clear that once you open a unit up it's 8k but the more evidence you have the better.

 

And the intellivoice cartrides sold about as well as the tron cartridges. I wouldn't describe them as a failure. They weren't on the market long before the entire industry started failing. Still, add-on peripherals are generally not a good idea.

Edited October 28, 2018 by mr_me

[+DZ-Jay]

The Intellivoice was a failure if it did not meet Mattel's sales projections and expectations -- notwithstanding how large the number of units sold may seem. At some point, I believe, they almost gave it away with new Master Component units.

 

http://www.intellivisiongames.com/bluesky/hardware/voice_tech.html

Despite these space-saving efforts, the number of words that could be fit into a voice game was extremely limited, which probably contributed to the Intellivoice's failure. While orders for the initial voice game releases were around 300,000 each, orders for the fourth game, TRON Solar Sailer, released later, hit only 90,000. A completed children's game, Magic Carousel, was shelved.

 

(Emphasis mine, in red.)

 

 

Moreover, the following statement suggests that the capital investment was not recuperated:

An attempt to recoup the Intellivoice investment was made by deciding to include the Orator chip and RESROM in the Intellivision III master component;

 

Other statements made in various articles and interviews point to a device which did not meet its goals, and was therefore scrapped.

 

It may have been popular, sold many units, and indeed it was a very cool peripheral, but Mattel had specific goals and expectations which it did not meet. Therefore, as a business venture, it failed.

 

-dZ.

[intvnut]

• PDP-11 head end - possible, but doubtful. A library of 20, 8K decle games would occupy 320KB, less than half the 1MB available on the floppy disk quoted in the Dages' document

 

Dages' document mentions a capacity of 21 games. I personally wondered how much of the 1MB was split between system software (kernel and user-space) and game software (possibly pre-encoded to simplify the broadcast hardware). Dages' document shows multiple parallel broadcast encoding devices, so that may have been a limiting factor as well. I don't know how performant a PDP11/03 is, but feeding 21 parallel transmitters might be tricky, unless they could buffer the transmission and only needed to be loaded at "start of time."

 

 

 

I moved the ASIC onto the breadboard from its original red socket to make probing it easier. The microcontroller is taking the place of the cable TV tuner in the PlayCable and feeds a digital TTL level data signal into the ASIC. All the connections to the ASIC other than the one, digital data stream input are just patched through from the red chip socket. The microcontroller is programmed to feed a fake PlayCable channel into the ASIC and from there, if you get the incoming data correct, the ASIC just does its thing.

 

I wonder how hard it would be to actually modulate the necessary FM signal to make the receiver work. It looks like they parked the signal at the high end of the FM radio band (at least for US FM radio broadcasts), and used a channel spacing compatible with terrestrial FM radio broadcast. The bandwidth of a data channel is a bit higher than a typical audio FM broadcast, but still well within its channel.

 

Would it be feasible to build an actual PlayCable broadcasting circuit based around consumer-grade FM transmitter chipsets? You don't need to throw the signal very far... just a couple centimeters into a 75Ω cable.

 

Now another detail I saw in the Intellivision FAQ was that some PlayCable operators loaded a new set of titles on the first of the month. Whenever they did, the menu list would empty out, and then new titles would appear incrementally, 2 at a time. That suggests that the PlayCable menu software was actually scanning the active channels, looking for whatever titles were on offer at that exact moment, as opposed to having the title-vs.-channel association baked into the ROM.

[decle]

Dages' document mentions a capacity of 21 games. I personally wondered how much of the 1MB was split between system software (kernel and user-space) and game software (possibly pre-encoded to simplify the broadcast hardware). Dages' document shows multiple parallel broadcast encoding devices, so that may have been a limiting factor as well. I don't know how performant a PDP11/03 is, but feeding 21 parallel transmitters might be tricky, unless they could buffer the transmission and only needed to be loaded at "start of time."

The PDP-11/03 was a the baby of the PDP-11 family. According to this site its LSI-11 processor ran at 0.05 VUP (VAX Unit of Performance - nominally 1MIP). This suggests the 11/03 ran at 50KIPS, and therefore, may have been even slower than the Intellivision! It also seems it could only address 64KB (32K 16bit words) of RAM.

 

I believe that the broadcast cards were autonomous and independent, continually streaming data from their own onboard RAM. The Dages document says the head end architecture...

 

"utilizes the advanced concept of distributed processing for high reliability" and "these data channel cards contain memory for program storage and a microprocessor which formats the data into serial data streams".

 

Although, obviously any RAM buffer on the transmission hardware used to hold the game code for transmission could be another source of the game size limit. The PDP-11 would then just be used for initialisation and monitoring. The IEEE doc says...

 

"the computer's function is to read the data received via floppy diskettes, format it for compatible transimssion over the CATV system... and to monitor its own functionality... The computer system is designed to be completely self-operating. During power outages or the introduction of new program material, the computer automatically "boot straps" itself into operation. If an error is detected in the transmission from any data channel card, the floppy disc is reread and the data is loaded into the data channel card. If an error still persists, the channel assinments for various programs are reallocated and the operator is notified of the failure..."

 

I wonder how hard it would be to actually modulate the necessary FM signal to make the receiver work. It looks like they parked the signal at the high end of the FM radio band (at least for US FM radio broadcasts), and used a channel spacing compatible with terrestrial FM radio broadcast. The bandwidth of a data channel is a bit higher than a typical audio FM broadcast, but still well within its channel.

 

Would it be feasible to build an actual PlayCable broadcasting circuit based around consumer-grade FM transmitter chipsets? You don't need to throw the signal very far... just a couple centimeters into a 75Ω cable.

 

Hey, hey, stop giving RonTheCat more ideas, he has more than enough on his own!

 

Now another detail I saw in the Intellivision FAQ was that some PlayCable operators loaded a new set of titles on the first of the month. Whenever they did, the menu list would empty out, and then new titles would appear incrementally, 2 at a time. That suggests that the PlayCable menu software was actually scanning the active channels, looking for whatever titles were on offer at that exact moment, as opposed to having the title-vs.-channel association baked into the ROM.

Given the game seek time (average 3 seconds for a 4K game) and the transient nature of the PlayCable RAM (although it might have been possible to retain scan results across Intellivision resets - at the cost of some PlayCable RAM and therefore game size - I think the scan would have to be repeated at each Intellivision power on), I'm not sure I see how the PlayCable adapter menu program could have scanned for the games without crippling its performance on the first run from power on. Could you explain your thinking more please?

 

I had assumed that this incremental process, which also appears in the dave1dmarx's recollections, was a manifestation of the head end initialisation process. Starting with a clear down and reset of the menu being streamed on the catalog channel to an empty state. Then, as each channel card is loaded and initialised with a game, the relevant names are added to the menu program on the server and streamed. Repeat until done. I notice that Dages says "Each channel card is capable of providing two serial data streams to the RF data modulator", perhaps this is the source of the games appearing in pairs? I guess this information and the fact that the menu items also seem to have appeared in pairs is more circumstantial evidence that only one game was sent on a channel.

 

What do you think?

 

Edit: Going back to the menu recreation, dave1dmarx has highlighted that the pitch of the audio in the video I posted earlier is a semi-tone too high and that once this is corrected there are still some small discrepancies in the harmony voices, as can be heard in this comparison (the recreation is on the left track / the recorded original on the right):

 

sideBySide.mp3

 

Whilst I have traced the semi-tone problem to an off by one error in my code, the other differences are beyond my puny musical abilities to correct (there is a good reason I wrote MusoCheat!). If any of the Musos out there fancy taking a crack at it (or indeed transcribing the other two PlayCable tracks), please let me know. Obviously I can provide the current tune we're using as a start point and full credit will be given

 

 

Cheers

 

decle

Edited October 29, 2018 by decle

[intvnut]

Now another detail I saw in the Intellivision FAQ was that some PlayCable operators loaded a new set of titles on the first of the month. Whenever they did, the menu list would empty out, and then new titles would appear incrementally, 2 at a time. That suggests that the PlayCable menu software was actually scanning the active channels, looking for whatever titles were on offer at that exact moment, as opposed to having the title-vs.-channel association baked into the ROM.

 

 

Given the game seek time (average 3 seconds for a 4K game) and the transient nature of the PlayCable RAM (although it might have been possible to retain scan results across Intellivision resets - at the cost of some PlayCable RAM and therefore game size - I think the scan would have to be repeated at each Intellivision power on), I'm not sure I see how the PlayCable adapter menu program could have scanned for the games without crippling its performance on the first run from power on. Could you explain your thinking more?

I had assumed that this incremental process, which also appears in the dave1dmarx's recollections, was a manifestation of the head end initialisation process. Starting with a clear down and reset of the menu being streamed on the catalog channel to an empty state. Then, as each channel card is loaded and initialised with a game, the relevant names are added to the menu program on the server and streamed. Repeat until done. I notice that Dages says "Each channel card is capable of providing two serial data streams to the RF data modulator", perhaps this is the source of the games appearing in pairs? I guess this information and the fact that the menu items also seem to have appeared in pairs is more circumstantial evidence that only one game was sent on a channel.

 

What do you think?

 

 

I'm not suggesting anything particularly complicated, honestly.

 

Imagine two scenarios:

1. A fixed set of games that all become available at once. It might make sense to generate a menu program with all of the game names baked in, along with their channel assignments. The ROM image for this menu is static. It has compiled into it a game-to-channel mapping, and "knows" a very specific menu. If the actual menu changes, it won't resync. You have to reset the unit and download a new menu.
2. A flexible menu that adapts to whatever games are currently being cycled. It might be seeded with whatever's current when it's loaded to give it a head start. But, it watches all of the available channels, and updates its menu based on what it sees go by, or maybe it monitors a special catalog track that tells it what's on the other channels.

The fact that games "appeared in pairs" suggests that the menu program image was monitoring the cable line for what was actually available, and wasn't precompiled to know about a certain set of games on a certain set of channels. Or maybe whomever it was kept resetting the unit to force it to reload the menu. I don't know which one it is.

 

I'm not talking about retaining info across Intellivision resets. I'm more talking about the ability of the menu software, when it's loading and running, to determine which games are actively being streamed at that exact moment, vs. baking menu information into the menu software when it's initially downloaded.

[+intvsteve]

OK, I'm ready to get slapped down for this insane notion, but... Terrestrial FM band, you say?

 

Mobile Intellivision games. In 1981. Why not?

 

I ​swear​ at some point I saw a car dealer catalog from the early 1980's in which a luxury car had a small built-in TV with an Intellivision as well. Imagine a limo service in those days (gotta think big here!) someplace like NYC / Chicago / LA where an FM station would "broadcast" games to your car! You'd have to have it be in a big ol' luxury car. Otherwise you'd need a wagon (Radio Flyer, not station) to haul your batteries, TV, and Master Component, with a sidecar to sit in to play.

 

[intvnut]

OK, I'm ready to get slapped down for this insane notion, but... Terrestrial FM band, you say?

 

Mobile Intellivision games. In 1981. Why not?

 

I ​swear​ at some point I saw a car dealer catalog from the early 1980's in which a luxury car had a small built-in TV with an Intellivision as well. Imagine a limo service in those days (gotta think big here!) someplace like NYC / Chicago / LA where an FM station would "broadcast" games to your car! You'd have to have it be in a big ol' luxury car. Otherwise you'd need a wagon (Radio Flyer, not station) to haul your batteries, TV, and Master Component, with a sidecar to sit in to play.

 

 

LOL, that would have been hilarious! Of course, if you had fewer than 1000 such cars in your fleet—or perhaps 10,000 or more—you'd be better off with something like a VideoPlexer in the trunk, given the costs of operating a tower and licensing all that bandwidth.

 

Judging by the specs and by the width of the bars in the diagram, I suspect the bandwidth of the games channels was quite a bit wider than a typical audio channel. They mention an FSK deviation of ±75kHz, and a bit rate of 13.982kHz. That fills quite a bit of spectrum—about 178kHz out of the 200kHz notch, if I'm not mistaken. That seems awful wide, which makes me think I am mistaken.

 

You could get away with that over coax. I'm not sure how well it'd hold up in a terrestrial FM broadcast in an urban environment, especially with 1980s tech. Obviously, cell phones make it work, but they have heckloads of forward error correction, multipath compensation, beamforming at the towers to focus signals more directly on individual subscribers, and other techniques to make it work.

 

Remember, this was an era when "cell phones" looked like this:

Edited October 29, 2018 by intvnut

[carlsson]

Maybe I've been a sloppy reader, but computer program broadcasts over FM radio was not entirely unheard of in the first half of the 80's. At least here in Europe, there were several more or less long lasting experiments, perhaps the Dutch Basicode was the best known one. I don't know how much transmitting those audio signals would differ over transmitting the PlayCable signals - of course you'd want several parallel channels here instead of one game each week - but such things did exist to some degree.

[intvnut]

Maybe I've been a sloppy reader, but computer program broadcasts over FM radio was not entirely unheard of in the first half of the 80's. At least here in Europe, there were several more or less long lasting experiments, perhaps the Dutch Basicode was the best known one. I don't know how much transmitting those audio signals would differ over transmitting the PlayCable signals - of course you'd want several parallel channels here instead of one game each week - but such things did exist to some degree.

 

 

I looked up BASICODE just now, and it appears to be 1200 baud, and essentially a voice-band modem over the air. It was likely FM modulated in the same manner as an FM radio station playing music, so it could be received with a standard radio receiver.

 

PlayCable was about 11x the speed of that. It sounds like it wasn't FM modulated at all, but rather was direct FSK on the wire with two carrier tones 150kHz apart. The frequency spacing was compatible with terrestrial FM, so you could slot PlayCable channels in between broadcast channels and not interfere. (Much the same reason for the Ch3/4 switch on the RF modulator.) Each PlayCable data channel was much wider than a typical FM audio broadcast, though. (Looking at Wikipedia, a full-blown FM broadcast w/ stereo and mono and extra services looks to be around 100kHz wide.)

[carlsson]

Ok, I see. So a 8 kilodecle program would take what, 10 seconds to load over FM compared to almost two minutes if it had been FM modulated audio signals at 1200 baud?

Edited October 29, 2018 by carlsson

[intvnut]

Ok, I see. So a 8 kilodecle program would take what, 10 seconds to load over FM compared to almost two minutes if it had been FM modulated audio signals at 1200 baud?

 

If you assume the 8Kx10 program was packed efficiently as 10K bytes of data, and sent 8-N-1, at 1200 baud (120cps), it'd take 85 seconds by my calculations.

 

At 13.982kHz, and a coding efficiency of 5 bits per every 10 bit times (framing overhead), I actually get about 11.7 seconds. So, it's actually about 7.25x as fast in practice, once you account for the framing inefficiencies in the PlayCable format.

[+x=usr(1536)]

Little bit late to the party on this, but this is one hell of an accomplishment - and I say that as someone who has never owned an Intellivision, but finds devices like the PlayCable utterly fascinating.

There are a couple of comments I'd like to add in relation to things that were said previously; this may already be known info, but as I didn't see it elsewhere in the thread thought it may be worth mentioning.

Can it actually tune different channel frequencies or would the different games be all coming down one stream on one channel.

I'm going out on a limb on this one, but I'd imagine that it tuned a specific cable channel which was then divided up into what could be considered subchannels. The subchannels are where the game data would have been transmitted down to the PlayCable. More:

And yes, it really is changing channels. There are 30 channels, 200kHz apart.

This is why I think that the system tuned a single TV channel but logically divided it into subchannels. A standard NTSC TV channel required 6MHz of bandwidth to transmit. 200kHz * 30 = 6MHz, which fits neatly inside of a single standard NTSC channel. Mathematically (and practically), it wouldn't make sense to spread the 200kHz data streams across multiple NTSC channels.

• Non-functional requirements - For example, as has been highlighted, GI made a big thing about the 10 second average download time. In the IEEE paper on the PlayCable they compare the data rate with that of Teletext, which GI seems to have seen as the technology's primary market. If you compute the time to transfer 4K decles (8K bytes) at the 13.98KHz bit rate (this is correct by the way - the reason this unusual baud rate was chosen was probably because it is the Inty master clock and Colorburst frequency of 3.58MHz divided by 256) you get approximately 6 seconds. So adding on an average "seek" time of half the program length, the average time from selection to play would be 9 seconds. This and dave1dmarx's recollections suggest that while multiple games can be interleaved on a channel (each program on the stream has a header that identifies it), this was not done in practice. As download time is proportional to game length it is possible that either Mattel or GI/Jerrold might have placed an artificial cap on the game size to keep download times low.

(Emphasis in quote above mine)

It makes a lot of sense that this approach may have been considered, even if it didn't see implementation - it's pretty much exactly how Teletext worked. Have to give them a lot of credit for at least seeing the possibility; it would have been a great way to expand the number of games available for download, though admittedly at the expense of download times.

I wonder how hard it would be to actually modulate the necessary FM signal to make the receiver work. It looks like they parked the signal at the high end of the FM radio band (at least for US FM radio broadcasts), and used a channel spacing compatible with terrestrial FM radio broadcast. The bandwidth of a data channel is a bit higher than a typical audio FM broadcast, but still well within its channel.

 

As regards the similarity to FM radio broadcasts: it's likely just coincidence. FM stations (in the US) are allocated specific channels on set frequencies of 200kHz bandwidth. However, only about 150kHz of that 200kHz is available to broadcasters, with around 100kHz being the amount typically used. A certain amount of unused space between channels (typically 25kHz at the top and bottom of the 200kHz allocation) is mandated, which helps to reduce the possibility of, say, 101.1FM's broadcasts bleeding over onto broadcasts from 99.9FM and 101.3FM. This unused space is what's typically referred to as the 'guard band', and it would make sense for the PlayCable's engineers to have built in something similar.

 

One other thing to bear in mind: some cable TV channels were carried on frequencies used by the FM broadcast band, as well as above and below it. Since the cable channels weren't being broadcast over the air this generally didn't cause interference issues with FM radio - but it does mean that the spacing of the cable channels in relation to FM broadcast is more coincidence than anything else. There's a decent PDF guide to the cable TV channel allocations here that illustrates this more clearly than I probably am.

Would it be feasible to build an actual PlayCable broadcasting circuit based around consumer-grade FM transmitter chipsets? You don't need to throw the signal very far... just a couple centimeters into a 75Ω cable.

 

Definitely feasible. First thought: build the 30 data streams into a valid NTSC picture, send that picture out to your transmitter (which could potentially be something as simple as a videosender unit), and let the transmitter squirt it down to the PlayCable as RF. Provided that everything was formatted and modulated correctly prior to transmission, and as long as signal levels into the PlayCable are within the specs it expects and on the channel it intends to receive on... It should work.

Now another detail I saw in the Intellivision FAQ was that some PlayCable operators loaded a new set of titles on the first of the month. Whenever they did, the menu list would empty out, and then new titles would appear incrementally, 2 at a time. That suggests that the PlayCable menu software was actually scanning the active channels, looking for whatever titles were on offer at that exact moment, as opposed to having the title-vs.-channel association baked into the ROM.

 

Again, taking a shot in the dark at it: one of the subchannels could have been dedicated to providing the menu data as opposed to games. It would probably be checked at powerup / reset, and do one of two things: by some mechanism that let it know that the menu had changed, tune the menu subchannel and receive data; not actually check for an update to the menu subchannel and just grab whatever came down from it.

 

Judging by the specs and by the width of the bars in the diagram, I suspect the bandwidth of the games channels was quite a bit wider than a typical audio channel. They mention an FSK deviation of ±75kHz, and a bit rate of 13.982kHz. That fills quite a bit of spectrum—about 178kHz out of the 200kHz notch, if I'm not mistaken. That seems awful wide, which makes me think I am mistaken.

 

You may not be terribly far off from the truth, or even right on top of it. If the modulation scheme for the data streams was based around the broadcast FM model (which, remember, had 25kHz of guard band at the top and bottom of the 200kHz frequency allocation), the PlayCable model would leave 11kHz guard band at each end on a 200kHz allocation.

 

Now, I'll admit: that's a pretty tight margin of safety. But it does give a total guard band of 22kHz, which (as you pointed out) is likely safe in a cable TV environment that isn't going to be as susceptible to outside influences on the signal compared to FM broadcast.

 

Maybe I've been a sloppy reader, but computer program broadcasts over FM radio was not entirely unheard of in the first half of the 80's. At least here in Europe, there were several more or less long lasting experiments, perhaps the Dutch Basicode was the best known one. I don't know how much transmitting those audio signals would differ over transmitting the PlayCable signals - of course you'd want several parallel channels here instead of one game each week - but such things did exist to some degree.

 

I remember when the same thing was tried over Teletext. It worked, but depending on the reception conditions where you were trying to download, it could make a 300-baud modem connected to the world's dirtiest phone line seem like a paragon of reliability and efficiency by comparison

 

In any event, this is a really nifty project, and I'm looking forward to seeing how it progresses. Seeing the potential for the resurrection of a 1970s-era publically-accessible data network (which it really was, even if receive-only) is just too awesome to me.

[intvnut]

I'm going out on a limb on this one, but I'd imagine that it tuned a specific cable channel which was then divided up into what could be considered subchannels. The subchannels are where the game data would have been transmitted down to the PlayCable. More:

 

This is why I think that the system tuned a single TV channel but logically divided it into subchannels. A standard NTSC TV channel required 6MHz of bandwidth to transmit. 200kHz * 30 = 6MHz, which fits neatly inside of a single standard NTSC channel. Mathematically (and practically), it wouldn't make sense to spread the 200kHz data streams across multiple NTSC channels.

 

The graph in the PDF I posted earlier shows the frequencies overlapping terrestrial FM radio broadcast, which is in a gap between terrestrial TV channels 6 and 7. It also shows interleaving with other audio FM broadcasts.

 

 

At that time, I dont think there would have been be any video broadcast on those channels on cable. In fact, there was often stereo simulcast for cable channels in that space in the 80s. I see in the PDF you linked that cable channels 95 through 97 overlap the FM space. I don't think those were really "a thing" in 1981 - 1983. I remember in the early-to-mid 1980s having a splitter that allowed connecting your FM stereo receiver and cable box to the cable feed, so you could get the stereo simulcast and certain other stations on your stereo from the cable feed. The drive to 100 channels (or more) didn't start happening until the mid-to-late 1980s.

 

 

It's conceivable that they could offer units tuned to a video-channel frequency band, but then the cable tuner box would need to skip those channels somehow, or you'd need an inline filter so you only got static, rather than some bizarro signal that'd confuse the TV (far more than scrambled channels would) and blast noise at the subscriber. Given that this was the era of cable boxes with a physical knob you turned, I don't know how likely that was. Maybe the tuner boxes also had built-in filters?

 

I don't remember if CATV tuners were already starting to show up in high end TVs and VCRs yet.

 

Keep in mind when I say "channels" in my own description, I'm referring to the 200kHz-spaced data channels, not TV channel numbers. As you point out, the total bandwidth occupied is equivalent to a single video channel allocation. Channel / sub-channel is just a naming difference. I never meant to imply PlayCable tuned to frequencies 6MHz apart, especially when the docs make it explicit they're 200kHz apart.

 

 

Definitely feasible. First thought: build the 30 data streams into a valid NTSC picture, send that picture out to your transmitter (which could potentially be something as simple as a videosender unit), and let the transmitter squirt it down to the PlayCable as RF. Provided that everything was formatted and modulated correctly prior to transmission, and as long as signal levels into the PlayCable are within the specs it expects and on the channel it intends to receive on... It should work.

 

Uh... I doubt you could construct a syntactically valid NTSC picture that does the job. The 15.7kHz horiz retrace will kill you, along with front/back porch, burst, etc. But, if your video modulator takes any 1v p-p signal and modulates it up into the video carrier space without any care about RS-170A syntactic correctness, you could get 20 to 25 of the 30 possible channels, given a 4.5MHz video bandwidth.

 

 

Again, taking a shot in the dark at it: one of the subchannels could have been dedicated to providing the menu data as opposed to games. It would probably be checked at powerup / reset, and do one of two things: by some mechanism that let it know that the menu had changed, tune the menu subchannel and receive data; not actually check for an update to the menu subchannel and just grab whatever came down from it.

 

Maybe I didn't call it out explicitly, but it appears the PlayCable software tunes to data channel 30 ($1E) for reading the catalog program. Each of the channels seems to cycle its program in an infinite loop. Since we don't have the actual menu program itself, I don't know if that program subsequently scooped program information off the wire after loading, or if the data was baked in. It seems likely it pulled it off the wire.

 

Since the monitor ROM looks for a specific header, "DIR1 CATALOG", it also seems likely the additional catalog information was time-multiplexed on the same 200kHz channel, even if none of the other subchannels made use of the functionality. That makes it easier to deliver a canned fixed binary image for the menu front end, and for the back-end software to inject packets of data based on what's currently live.

 

BTW, parking the directory on the top channel is also corroborated by that frequency spectrum graph I inlined above that shows "DIRECTORY" at the far right.

Edited November 12, 2018 by intvnut

[intvnut]

 

Judging by the specs and by the width of the bars in the diagram, I suspect the bandwidth of the games channels was quite a bit wider than a typical audio channel. They mention an FSK deviation of ±75kHz, and a bit rate of 13.982kHz. That fills quite a bit of spectrum—about 178kHz out of the 200kHz notch, if I'm not mistaken. That seems awful wide, which makes me think I am mistaken.

 

 

You may not be terribly far off from the truth, or even right on top of it. If the modulation scheme for the data streams was based around the broadcast FM model (which, remember, had 25kHz of guard band at the top and bottom of the 200kHz frequency allocation), the PlayCable model would leave 11kHz guard band at each end on a 200kHz allocation.

 

Now, I'll admit: that's a pretty tight margin of safety. But it does give a total guard band of 22kHz, which (as you pointed out) is likely safe in a cable TV environment that isn't going to be as susceptible to outside influences on the signal compared to FM broadcast.

 

Well another thing to keep in mind is that FM transmission has its own issues, as it has a rather wider bandwidth than you'd expect. It's not as tightly controlled as AM transmissions. Carson's Bandwidth Rule suggests a normal FM audio transmission actually occupies more than 200kHz of spectrum, at least according to the analysis in this Wikipedia article.

 

The PlayCable modulation isn't FM, though. It's direct FSK, if I understood correctly. FSK has less spectral spreading than FM encoding.

[Ron The Cat]

Found this article (page 2) which stated playcable subscribers did not lose a channel to playcable as it can override portions of other channels to deliver the service ....

 

 

https://scholarworks.bgsu.edu/cgi/viewcontent.cgi?article=4957&context=bg-news

[+DZ-Jay]

Found this article (page 2) which stated playcable subscribers did not lose a channel to playcable as it can override portions of other channels to deliver the service ....

 

 

https://scholarworks.bgsu.edu/cgi/viewcontent.cgi?article=4957&context=bg-news

 

Neat! That's an interesting article. I particularly liked the optimism in the following passage:

 

The target goal in 1985 is for PlayCable programming to be installed in one million homes. Eight percent of homes in the United States own some type of programmable video game with an estimated rise to 50 percent in 1985. This projection makes the goal attainable, Hilt said.

 

Doh! It's too bad how it actually turned out.

 

-dZ.

[mr_me]

Thanks for finding that article. It's got some good information there.

 

The idea that playcable can be mixed between TV channels without costing the operator a TV channel kind of contradicts what intellivisionlives.com is saying about cable operators losing a channel to playcable being a factor. The article does give the example of a cable operator not expecting to go for playcable but is holding off until expanding from 12 to 20 TV channels is approved. So the issue might have been cable operators at that time were busy expanding their television service which itself was introducing set top boxes for the first time. (Where I was, the cable company put radio stations in that mid-band FM radio range well into the 2000s. Not a big deal in the big city where you can get dozens of radio stations off air but it was helpfull in rural areas.)

 

The cost of the server and boxes is also noted as a factor by intellivisionlives.com but I don't think it was all that expensive. A $57 playcable box would be paid for in less than five months of subscriptions. A cable operator would need 138 playcable subscribers to pay for the $12k server in the remaining seven months of that first year. That's more than reasonable given that about 20% of households subscribe to cable and close to 3% of households have an intellivision. That translates to a community of only about 25k households and 5000 cable subscribers. So the equipment should be paid for from subscriptions in much less than one year.

 

The article says in 1982, 8% of households had a video game system. With 80M households in the US that's 6.4M systems and well over 1M intellivisions. They are projecting 50% by 1985! 40M game systems! If Mattel maintained 20% market share that would have been 8M intellivisions by 1985. With 20% on cable they would need just over 60% of cable operators to adopt playcable to hit 1M playcable subscribers. With more cable operators, it could work with video games in households closer to 33% rather than 50%. So you can see where the 1M playcable subscriber projection came from. Of course, the 50% households with video games by 1985 went out the window. Well it happened eventually.

 

-------------

One of the things about how playcable works is that whenever you pressed reset on intellivision, playcable would re-download the catalog, everytime. Since pressing reset was the only way to restart a lot of intellivision games that would have been a bit of a pita.

Edited November 20, 2018 by mr_me

[carlsson]

Would PlayCable have to be exclusive to the Intellivision though? For that matter if Mattel were working on new systems including the 68K based IV, likely that should've been introduced in 1985 and it would be expected to support downloadable software too, though obviously larger programs than 8 kilodecles or whichever the current implementation was limited to in the user end.

[+DZ-Jay]

Thanks for finding that article. It's got some good information there.

 

The idea that playcable can be mixed between TV channels without costing the operator a TV channel kind of contradicts what intellivisionlives.com is saying about cable operators losing a channel to playcable being a factor. The article does give the example of a cable operator not expecting to go for playcable but is holding off until expanding from 12 to 20 TV channels is approved. So the issue might have been cable operators at that time were busy expanding their television service which itself was introducing set top boxes for the first time. (Where I was, the cable company put radio stations in that mid-band FM radio range well into the 2000s. Not a big deal in the big city where you can get dozens of radio stations off air but it was helpfull in rural areas.)

 

The cost of the server and boxes is also noted as a factor by intellivisionlives.com but I don't think it was all that expensive. A $57 playcable box would be paid for in less than five months of subscriptions. A cable operator would need 138 playcable subscribers to pay for the $12k server in the remaining seven months of that first year. That's more than reasonable given that about 20% of households subscribe to cable and close to 3% of households have an intellivision. That translates to a community of only about 25k households and 5000 cable subscribers. So the equipment should be paid for from subscriptions in much less than one year.

 

The article says in 1982, 8% of households had a video game system. With 80M households in the US that's 6.4M systems and well over 1M intellivisions. They are projecting 50% by 1985! 40M game systems! If Mattel maintained 20% market share that would have been 8M intellivisions by 1985. With 20% on cable they would need just over 60% of cable operators to adopt playcable to hit 1M playcable subscribers. With more cable operators, it could work with video games in households closer to 33% rather than 50%. So you can see where the 1M playcable subscriber projection came from. Of course, the 50% households with video games by 1985 went out the window. Well it happened eventually.

 

-------------

One of the things about how playcable works is that whenever you pressed reset on intellivision, playcable would re-download the catalog, everytime. Since pressing reset was the only way to restart a lot of intellivision games that would have been a bit of a pita.

 

Interesting. I think it was not so much fear that the PlayCable hardware investment would not pay for itself within a year (obviously it could as you point out). I think it's more that the investment was not seen as necessary when not incurring the cost lead to immediate profits from the growing number of regular CableTV subscribers, which was exploding at the time -- especially for smaller operations like the one in the article which only offered 12 channels at the time.

 

As I suggested before, when looked at individually, each factor does not seem too daunting -- but all of them at once may not have been too attractive at a time when many were still suggesting that video games were a fad (in spite of growing evidence to the contrary). Keep in mind that when the video game market crashed initially, many articles and books were written describing how it was a fad all along and everybody sane knew it was bound to happen.

 

I bet you that all those cable operators who decline the investment thought smugly of themselves as great prescient visionaries for going with MTV and other CableTV properties rather than investing in that "fad" of video games.

 

-dZ.

[Ron The Cat]

Some playable ads I came across which I have not seen before .....

[mr_me]

Would PlayCable have to be exclusive to the Intellivision though? For that matter if Mattel were working on new systems including the 68K based IV, likely that should've been introduced in 1985 and it would be expected to support downloadable software too, though obviously larger programs than 8 kilodecles or whichever the current implementation was limited to in the user end.

The playcable rom runs on the Intellivision cpu so it would have probably worked with the intellivision iii but not the intellivision iv. There's no reason they couldn't make playcable boxes for different game systems all working with the same server. How much ram would you put in a playcable box in 1985? Was the cost of 128kB ram reasonable in 1985. They could have transitioned this technology to NES; but there was a bit of a gap between 1983 and 1986. They might have gotten their 1 million homes by 1988. Theoretically the system could support a couple hundred games while only occupying one cable tv channel.

[carlsson]

I believe also home computer users might've been interested in this form of software distribution. Compare to e.g. various Videotex initiatives around the world including the USA, where everyone projected for large amounts of customers but after a couple of years had to admit they had missed their targets by far. Actually instead of multiple competing technologies and offerings, why not offer cable operators and others early online services that would combine e.g. Videotex (if that was a preferred technology) with the software distribution in the PlayCable.

 

Sure, a 128K computer wasn't particularly cheap even in 1985 but as noted, perhaps recouping hardware costs were among the least worries about getting the service running in big scale.