Intellivision Game sizes

[CatPix]

But the PlayCable downloaded game from TV cable service, and the average user wouldn't know how to tap into the feed and save it.

It didn't took long, apparently, for people to find that dumping Atari 2600 cart games and converting them to data to be loaded on the Starpath Supercharger was possible - as long as the game didn't exceded 6 Ko and didn't contain special chips.

So in that regard it make sense that you can't load an Intellivision game from the tape port, it would make pirating much easier.

Edited March 18, 2019 by CatPix

[mr_me]

That make sense.

So, the ECS is kind of it's own computer that just hog on the Intelli for display and some input? Well, thinking about it, I suppose it make sense, else, people could have used the ECS like the 2600's Supercharger and load any Intellivision standard or ECS game on tape rather than buying the carts.

Like Carlsson said the ecs has no cpu so it's a peripheral to the intellivision cp1610 computer. Basic is built inside the ecs computer adaptor. The keyboard component does add a second cpu but all the KC application software, other than the basic programs, were intellivision cp1610 programs. Edited March 18, 2019 by mr_me

[+Lathe26]

As far as I understand, the ECS is an expansion containing 2K 8-bit RAM for storage, an extra AY sound chip and the I/O port. You can connect a keyboard to it, and by using a special BASIC cartridge, enter small programs that are executed by the interpreter (dog slow, even compared to the lowest end computers of its day).

 

The KCS however has its own 6502 CPU and rather was its own computer using the console for display.

 

Regarding loading games on tape, don't forget the PlayCable which was a dial-up service offering that, downloading games into RAM I presume and executing those.

 

As mr_me said above, the ECS has BASIC built in. The KC required an add-on cartridge into the back of it to add BASIC.

[Walter Ives]

On 3/15/2019 at 2:12 AM, DZ-Jay said:

Were they really using 10-bit ROM by then? My understanding is that they only did that in the earlier games, burning through GI's stock of 10-bit ROMs chips.

Nope. GI didn't keep a stock of half-processed 10 bit ROMs, they fabricated ROMs to order on their ever-rotating stock of virgin industry-standard silicon wafers whenever they received a tape of a program and a purchase order.

The Intellivision used 10-bit ROMs instead of 16-bit ROMs because that was the most economical thing to do. The bigger the die, the lower the yield—yield varies inversely as the square of the die size. In 1978 the yield curve was such that GI could economically build ROMs with 20,000 bits (2K x 10) but not with 32,000 bits (2K x 16). They could easily have built 16-bit wide parts, but they would have been 1K x 16.

 

On 3/15/2019 at 5:04 AM, DZ-Jay said:

Yes, they had alternative sources of ROMs, but my understanding was that GI was pushing their 10-bit ROMs in a time when the industry was transitioning to 8-bit and 16-bit words.

Nope. GI loved making 8-bit wide ROMs and made gazillions." It was indifferent about ROM width—it practically owned the market for 5x7 character generator ROMs with its 512 word x 5 bit RO-3-2513. "We had a ROM printing press," it was fond of saying. The 10-bit wide ROM it was making for Mattel was a bit of an odd duck, even for GI.

 

On 3/15/2019 at 2:46 AM, carlsson said:

If someone dumped a 16-bit ROM containing 10-bit code/data, would the top 6 bits typically be random or zero?

They had to be zero, otherwise immediate and direct instructions wouldn't work. For example, MOV #$17,R0 and MOV R0,.OBJX wouldn't yield the desired results if the high bits were messed up.

 

On 3/15/2019 at 5:24 AM, DZ-Jay said:

We pack GRAM graphics in 16-bit words now, which not only improves performance, but also conserves space. Plus all pointers and 16-bit data (of which a game is chuck-full) had to be encoded as double-byte data in two Decles. 16-bit ROMs would have cut the data storage requirements of a game considerably.

Ah, but would they have cut the number of words needed for a typical 4K x 10 program in half, to 2K x 16? Because that's what the choice was, either two 1K x 16 parts or two 2K x 10 parts. In deciding, remember that the EXEC allowed many of the 48 GRAM characters used by the background to be algorithmically encoded into one or two decles and that BACKTAB entries for many games could be efficiently compressed to five bits per card—that is apparent if you look carefully at games like Armor Battle, Sea Battle and Golf. And tables of pointers could be efficiently stored as 10-bit offsets.

The considerations you mention did not escape the designers. They regularly revisited their original decision as program sizes increased. APh lobbied heavily to increase the Keyboard Component's DRAM width to 16-bits for the very reasons you cite. That being said, Keyboard Component text was stored very efficiently as radix-100. The Intellivoice, which required a huge amount of data, was fed through a 10-bit wide FIFO. The development breadboards of the Intellivision III ECS used 16-bit wide DRAM, but that required 6 more devices and the suits hadn't yet signed off on the cost of including them in the production version. 4Kx16 bit ROMs were deemed feasible for late 1984 code releases on a case-by-case basis. Neither GI nor Prodromou had a problems with the concept of having both 10 and 16 bit ROMs available or of mixing the two types in a given cartridge.

 

On 3/15/2019 at 6:04 AM, mr_me said:

If anything, at first, GI might have charged a premium for roms knowing they were the only supplier.

Nope. In order to convince Mattel to use the CP1600/STIC chipset, GI had to agree to supply the ROMs at a competitive price. It was a package deal. Furthermore, Solomon was quite aware of the economics of the consumer electronics business and was motivated to price his components so that his customers could compete.

 

On 3/15/2019 at 5:49 AM, DZ-Jay said:

I don't know about the late '80s, though, during INTV Corp's reign. Perhaps it was still cheaper to use 10-bit ROM as 10-bit chips became increasingly obsolete...

Whatever their width, cartridge ROMs had to accommodate the CP1600's multiplexed bus. Valeski was a master penny pincher who hated putting money upfront. He was never sufficiently convinced he could sell enough product at a high enough price to invest substantial amounts of his own money in new technologies.

 

 

[+DZ-Jay]

On 12/3/2022 at 8:13 AM, Walter Ives said:

Nope. GI didn't keep a stock of half-processed 10 bit ROMs, they fabricated ROMs to order on their ever-rotating stock of virgin industry-standard silicon wafers whenever they received a tape of a program and a purchase order.

 

The Intellivision used 10-bit ROMs instead of 16-bit ROMs because that was the most economical thing to do. The bigger the die, the lower the yield—yield varies inversely as the square of the die size. In 1978 the yield curve was such that GI could economically build ROMs with 20,000 bits (2K x 10) but not with 32,000 bits (2K x 16). They could easily have built 16-bit wide parts, but they would have been 1K x 16.

 

Nope. GI loved making 8-bit wide ROMs and made gazillions." It was indifferent about ROM width—it practically owned the market for 5x7 character generator ROMs with its 512 word x 5 bit RO-3-2513. "We had a ROM printing press," it was fond of saying. The 10-bit wide ROM it was making for Mattel was a bit of an odd duck, even for GI.

 

They had to be zero, otherwise immediate and direct instructions wouldn't work. For example, MOV #$17,R0 and MOV R0,.OBJX wouldn't yield the desired results if the high bits were messed up.

 

Ah, but would they have cut the number of words needed for a typical 4K x 10 program in half, to 2K x 16? Because that's what the choice was, either two 1K x 16 parts or two 2K x 10 parts. In deciding, remember that the EXEC allowed many of the 48 GRAM characters used by the background to be algorithmically encoded into one or two decles and that BACKTAB entries for many games could be efficiently compressed to five bits per card—that is apparent if you look carefully at games like Armor Battle, Sea Battle and Golf. And tables of pointers could be efficiently stored as 10-bit offsets.

 

The considerations you mention did not escape the designers. They regularly revisited their original decision as program sizes increased. APh lobbied heavily to increase the Keyboard Component's DRAM width to 16-bits for the very reasons you cite. That being said, Keyboard Component text was stored very efficiently as radix-100. The Intellivoice, which required a huge amount of data, was fed through a 10-bit wide FIFO. The development breadboards of the Intellivision III ECS used 16-bit wide DRAM, but that required 6 more devices and the suits hadn't yet signed off on the cost of including them in the production version. 4Kx16 bit ROMs were deemed feasible for late 1984 code releases on a case-by-case basis. Neither GI nor Prodromou had a problems with the concept of having both 10 and 16 bit ROMs available or of mixing the two types in a given cartridge.

 

Nope. In order to convince Mattel to use the CP1600/STIC chipset, GI had to agree to supply the ROMs at a competitive price. It was a package deal. Furthermore, Solomon was quite aware of the economics of the consumer electronics business and was motivated to price his components so that his customers could compete.

 

Whatever their width, cartridge ROMs had to accommodate the CP1600's multiplexed bus. Valeski was a master penny pincher who hated putting money upfront. He was never sufficiently convinced he could sell enough product at a high enough price to invest substantial amounts of his own money in new technologies.

 

 

 

Wow!  I am so glad for this post.  Even as it contradicts many of my own speculative posts, it is phenomenally satisfying to have the record corrected with such breadth of historical context.

 

I know I’ve said this repeatedly in many of your posts, but I must repeat yet again:  Thank you very much, Mr. Ives!

 

     dZ.