Atari's plans to use CV hardware back in 1983

[Dutchman2000]

Here is a memo I found which outlines Atari's proposals of possible products based on the ColecoVision hardware. It has been OCR scanned for easier reading.

 

12-17-83

 

Our current base unit situation reduces down to a clear leadership in the low end game machine market with the 2600 which is unlikely to be displaced by

Mattel's Intellivision II as long as we continue the current course of cost reduction and enhancement.

 

The mid-range market is currently in the hands of Coleco due to greater production capacity, true sprite management, and better sound generators when

compared with the 5200. We are already addressing the first issue and should outdistance them in sheer numbers this year.

 

We have been asked for a new game machine to be shipped by March 1984 which will place us back into the lead. This time frame absolutely dictates a machine with

no new custom chips.

 

There is a significant danger as well that a new game machine introduced so early in the life cycle of the 5200 would disenfranchise our customers and

potential customers by signaling a lack of commitment to recent products.

 

There are a couple of solutions, however; one of which is simple, inexpensive, and straightforward.

 

Both solutions build upon the 5200 to provide performance beyond that of either the ColecoVision or the 5200. One is to wrap a 5200 and a ColecoVision in the

same package and share power supply, modulator, and some dual-ported RAM. The other solution is to provide an external or internal enhancement to the 5200 in

the form of another 6502, additional RAM, and a small ROM.

 

COLECOVISION + 5200:

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

Since all of the components in a ColecoVision are off-the-shelf (except for the Operating System ROM) there is nothing to prevent us from marketing a

ColecoVision adapter for the 5200. A slight rev. to the O.S. would get around the potential copyright problem. This would provide our customers with the most

versatile machine on the market ... able to play 2600, 5200, and ColecoVision carts.

 

Better yet, we can produce a base unit which contains both a 5200 and a ColecoVision. Since the T.I. 9918A graphics chip in the ColecoVision is capable

of syncing to an external signal and of using an external video signal as a background image plane, the two graphics systems could conceivably be run

simultaneously. This would allow all of the graphics objects (4, monochromatic sprites + a multi-color character stamp playfield) of the 9918A to be used as

foreground objects and simultaneous use of the ANTIC/GTIA graphics objects (4, monochromatic players, 4 monochrome missiles, and a multicolored bit map or

character stamp playfield) as a background. In essence, there would be three main operating modes: 5200 only, ColecoVision only, and a simultaneous mode.

 

The simplest way of implementing this is to turn off the ColecoVision's Z80 microprocessor in the simultaneous mode and use the SALLY chip in the 5200 half

of this machine to run both graphics and sound systems. This would be accomplished through a dual-ported RAM in the ColecoVision half which would be

accessed by the SALLY chip only during VBLANK. This would provide a programmer-manageable, one CPU system but it is unlikely that the SALLY would

have enough time to accomplish everything it needs to during VBLANK. This is because the SALLY is already hampered in its performance by the DMA activity of

the ANTIC, because collision detection and management between the two graphics systems would have to be entirely in software, and because the two graphic

systems have different numbers of pixels per line plus different aspect ratio pixels. In other words, this would probably not work due to real time limits.

 

A more complex implementation of the 5200 + ColecoVision idea would allow both microprocessors (the SALLY and the Z80) to run in the "simultaneous" mode of

this machine. This would entail the same dual-ported RAM concept as the above proposal with communication through that memory space only during VBLANK. This

would be a real bear to design and program, in that one would have 2 CPUs with different characteristics and instruction sets, running a two different clock

rates, driving very different graphic and sound systems in a tight, real time environment. The advantage of this proposal is that it would be capable of

working, would allow one to combine the graphic and sound strengths of both machines, and would require no custom VLSI development. Even with this feasible

solution, the limited VBLANK time used for intra-machine coordination would lead to programs of rather limited graphic complexity; and the cost of this base unit

would be rather high for the performance gained:

 

--> cost of PAM Taiwan (with a larger power supply) $110.

+ cost of the ColecoVision + 93.

+ cost of the dual-ported RAM and other control circuitry + 10.

- cost of the ColecoVision modulator and power supply - 10.

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

total estimated bill-of-materials = $203.

 

In summary, it could be done; Atari needs to at least consider it for a near-term machine; but we don't recommend it.

 

 

 

ENHANCED 5200

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

A much cleaner solution to the near-term requirement for a better base unit is to build upon PAM itself .... change it from a system with rather dumb player,

sound, and I/O management to one with rather sophisticated, animated sprites, complex sound generation (including speech during non-static screens without

the GI speech synthesis chip), and more sophisticated joystick/keypad controller routines.

 

As we are revving the 5200 anyway to bring out the rest of the address lines, HALT, and READY, we should also take the opportunity to fully tri-state the

SALLY and ANTIC/GTIA chips (externally for now). This would allow us to place another 6502 on the main bus, running chase with the SALLY. It would need a

small ROM for its normal program and data, and some address decoding to ensure that its zero page and stack utilization (pages 0 and 1) do not conflict with

those of the SALLY. While we are at it we could add some additional RAM which could be addressed by either processor (i.e.. be in the main address space).

 

The primary job of the added 6502 would be to feed the ANTIC/GTIA player/missile RAM space with a succession of graphics data and to store appropriate data to

the horizontal position registers of ANTIC. This would allow the combination of the extra 6502 and the ANTIC/GTIA to look like an automatic, animated sprite

manager to the SALLY. In other words, the resulting graphic system would automatically step through animation sequences for motion objects with defined

width, height, and X,Y position on the screen. This would allow for the maximum use of the capabilities of the players/missiles in creating complex, reused,

animated, motion objects with far simpler programming on the part of the game programmers. In the process, this would free-up the SALLY to perform other

tasks such as the generation of more complex and more frequently updated bit mapped and character stamped playfields. The combination of both the enhanced

motion objects and the enhanced playfield will produce a very noticeable increase in the speed and complexity of the 5200 games.

 

Alternatively, at times, the extra 6502 can be used to generate simulated vector displays on the bit mapped playfield of the 5200. This can be done now for

wire-frame/perspective games such as Tempest, Battle Zone, or Gravitar. The problem is that generating vector information on a raster scan system requires a

lot of steps and is relatively slow on the 5200. With the extra 6502 to take some of the processing load off of the SALLY chip, faster and more complex

vector displays could be generated more easily.

 

Also, the extra 6502 can be used to feed the POKEY chip with a stream of sound data many times during each frame. This would allow us to utilize the POKEY's

sound generation capabilities to their fullest extent in every game. It could be used as a real sound generator chip with pseudo-registers for control of the

amplitude envelope (separate attack, sustain and decay curves), AM effects, FM effects, etc. This would give us a sound generator which is better than that in

the ColecoVision in its versatility and ease of use. When needed, it could also be used as a waveform synthesizer for generating waveforms other than the square

waves and pulse trains which are POKEY's normal output. When driven as a D/A device the POKEY is capable of producing tones with a wide variety of harmonic

contents .... including speech. Normally, however, the only way to have the time to drive the POKEY in that manner is to stop changing the graphic information

(i.e.. temporarily have a static screen). With the extra 6502 as the digital source for POKEY in the D/A mode, the SALLY would still be free to run the rest

of the game including a changing screen.

 

Since ROM would be added to the system anyway to run the extra 6502 under most circumstances, and since that ROM would be addressable by both CPUs, it could

contain some standard I/O management routines for interpreting the joystick or keypad which could be run by either microprocessor.

In addition, one would want to maximize the speed and memory efficiency of these graphic and sound hardware register stuffing activities of the extra 6502 by

mapping the address space of the hardware registers of the 5200 into the bottom of zero page of the extra 6502 (much as has been done on the TIA registers in

the 2600). With this feature, the enhanced 5200 would be able to run a kernal on the ANTIC/GTIA requiring the stuffing of all of the horizontal position

registers and color/lum registers for the motion objects during a single horizontal retrace period. This would mean players/missiles could be reused

vertically without any "dead" scan lines separating incarnations.

 

One of the really cute aspects of this enhancement to the 5200 is that, except for pages zero and one, all of memory would be accessible to both

microprocessors. This means that, most of the time, our games programmers would be able to make use of the above mentioned capabilities of the extra 6502 by

making use of the routines that come with it in its associated ROM. At other times, more sophisticated programmers would be able to make use of the extra

6502 in unique ways by providing routines for it in their game cartridge ROM. This is especially nice in that one can "mix and match" the canned routines and

special routines for the extra 6502 in the same game.

 

A side benefit of this wart on the side of PAM is that the added RAM could be used as added variable storage space for either processor. This would allow

double buffering (page flipping) of the full, high resolution, bit mapped playfield without running out of variable storage RAM .... something we cannot

do now with only 16K of RAM in the base unit. The page flipping technique is one in which the ANTIC/GTIA is programmed to display one chunk of graphic memory

while the microprocessor (SALLY or extra 6502) readies another chunk of memory for display. The graphics chips then work with the second piece of RAM and the

microprocessor then readies the alternative block of RAM. This allows the entire field display period to be used for modification of the display instead of only

the vertical blank interval. Since the entire field time is almost 17 times longer than the vertical blank period, much more time is available for modifying

the bit mapped playfield from frame to frame without loss of synchronization of the video image. In a game like Defender, where extensive use is made of the bit

map for the generation of a large number of graphic objects in the game, this has been a significant programming problem.

 

PROBLEMS AND DISADVANTAGES:

 

1. In order to run cophase 6502s in an enhanced PAM, one requires faster RAM and ROM (including game cart ROM) than that currently specified for the 5200. We

would also need to clean-up the manner in which we generate RAS and CAS signals to run that RAM. More seriously, the game cart ROM which we buy is

too slow for this cophase application. Our ROM cart costs would be noticeably higher for the new games which would make use of the enhanced features. (Since

the cophase 6502 could be turned off automatically if an "old" 5200 cart were inserted, our existing, slower ROM carts would run without any problem in the

new unit.)

 

2. We have again missed the time window. LITTLE PAM is going to production without the extra lines being brought out to the expansion port and without full

tri-stating of SALLY and ANTIC. Several million PAMs and LITTLE PAMs will be out there which will be incapable of using a plug-in enhancer as described above.

The most straightforward solution would be to forget about doing a plug-in enhancer at all and head only toward a higher end PAM with these enhancements

built into the base unit. This, of course, is a marketing management issue, not a technical one.

 

3. The memory map of the 5200 has been squandered. The locations for all of the hardware registers (internal and on the speech module) have been scattered

through the remaining areas of the memory map, instead of concentrating them all in one contiguous address space. Any additional ROM or RAM for this cophase

application would need to be interdigitated in the remaining address areas. This is both a cumbersome hardware addressing issue with added cost implications ...

and a limiting factor in the usefulness of that added memory from a software perspective. Nothing can be done on PAM itself to correct this problem of memory

map mismanagement; it is too late. Let us try and learn from this, however, and not make the same mistake on our future game machines.

[+Allan]

Did this come from an internal email or a printed memo?

 

Allan

[+DamonicFury]

Thank you so much for this glimpse into Atari's thought process at this point in its history!

 

Kind of surprising that they don't mention the problematic 5200 joysticks. It seems like releasing better controllers would have been a cheaper and easier solution to the 5200's woes than the solutions suggested by the memo.

 

Also interesting that they thought "true sprite management, and better sound generators " were the reasons the 5200 was losing out to the Colecovision. No mention (again) of the problematic 5200 controllers, or the initially far stronger launch library of the Colecovision. Instead they blame hardware problems that I've never seen mentioned as to why the 5200 wasn't a market success.

 

No wonder Atari was in such a problematic state back then... they really didn't seem to have any grasp of why they were having problems, and their best suggested solutions were to toss more hardware at an already over-saturated market.

[+darryl1970]

It is a shame that Maria wasn't developed on top of the A8 hardware. Supporting the 2600 at that point would have been pointless.

The 7800 should have been more powerful than the 5200, instead of a trade off of gaining flicker-free, multi-color sprites,

but losing versatility for particle effects (such as Defender and Robotron) and smoothness of gameplay (scrolling and complex calculations).

 

These are very interesting concepts. They were definitely scrambling to catch up, even though I have heard many times that the 5200 was overtaking the ColecoVision at this point.

 

Wouldn't this timeline be a little out of place, since the 7800 was getting ready to be announced?

Wouldn't Atari have already been in talks about releasing the NES in the states?

 

I have heard that some Atari employees wanted to scrap the 7800 for a dual A8 solution. Would this be that proposal?

If so, they may have know about the 7800 (or Maria).

Edited September 5, 2017 by darryl1970

[+darryl1970]

Thank you so much for this glimpse into Atari's though process at this point in its history!

 

Kind of surprising that they don't mention the problematic 5200 joysticks. It seems like releasing better controllers would have been a cheaper and easier solution to the 5200's woes than the solutions suggested by the memo.

 

Also interesting that they thought "true sprite management, and better sound generators " were the reasons the 5200 was losing out to the Colecovision. No mention (again) of the problematic 5200 controllers, or the initially far stronger launch library of the Colecovision. Instead they blame hardware problems that I've never seen mentioned as to why the 5200 wasn't a market success.

 

No wonder Atari was in such a problematic state back then... they really didn't seem to have any grasp of why they were having problems, and their best suggested solutions were to toss more hardware at an already over-saturated market.

Very good points.

[Dutchman2000]

Did this come from an internal email or a printed memo?

 

Allan

 

This was from a printed memo, I found it in a lot of paperwork I purchased some time ago.

[+Allan]

 

This was from a printed memo, I found it in a lot of paperwork I purchased some time ago.

Any way you could post the scans of the memos?

 

Allan

[Dutchman2000]

Any way you could post the scans of the memos?

 

Allan

 

No, as the author of the memo does not want them posted that way.

[+Allan]

 

No, as the author of the memo does not want them posted that way.

Understood.

 

Allan

[+remowilliams]

A Colecovision adapter for the 5200... Then I could play 2600/5200/7800/CV games all on the same unit today

 

 

No, as the author of the memo does not want them posted that way.

 

That's kind of unfortunate as (and nothing negative directed at you) - otherwise its kind of just something that was typed in somewhere by someone without reference.

[zzip]

Thank you so much for this glimpse into Atari's thought process at this point in its history!

 

Kind of surprising that they don't mention the problematic 5200 joysticks. It seems like releasing better controllers would have been a cheaper and easier solution to the 5200's woes than the solutions suggested by the memo.

 

Also interesting that they thought "true sprite management, and better sound generators " were the reasons the 5200 was losing out to the Colecovision. No mention (again) of the problematic 5200 controllers, or the initially far stronger launch library of the Colecovision. Instead they blame hardware problems that I've never seen mentioned as to why the 5200 wasn't a market success.

 

No wonder Atari was in such a problematic state back then... they really didn't seem to have any grasp of why they were having problems, and their best suggested solutions were to toss more hardware at an already over-saturated market.

 

yeah, in retrospect, it does seems like none of those companies (not just Atari) had a clue about what consumers really wanted. They were making it up as they went. Clearly they thought specs mattered more than they do.

 

Another example was the peripheral war. One maker announces a trackball, "we all need trackballs. Keyboard "we all need keyboards", 2600 adaptors, voice modules, steering wheels, etc. It's like nobody checked with consumers if they wanted, REALLY wanted to spend money on all those peripherals. It turned out they didn't.

[Tempest]

I like that Colecovison/5200 hybrid idea. That sounds like it could have been really interesting.

[Goochman]

This shows even more how badly Atari butchered the 5200 release. All the specs were wrong out of the gate and they looked to play catchup with CV right after launch. What a complete joke.

[Swami]

Its also possible, blaming these issues instead of the real ones will get them in less trouble and they are just hoping to get the next Christmas bonus, not change the world of entertainment.

[+DamonicFury]

Its also possible, blaming these issues instead of the real ones will get them in less trouble and they are just hoping to get the next Christmas bonus, not change the world of entertainment.

 

It's certainly true enough that by December 1983, a full year after the launch of the 5200, there wasn't really much that could be done to salvage the system, especially with the Crash happening. It's just interesting that they somehow thought new hardware might be the answer to their problems at such a late date. Even as a "make the boss happy" kind of solution, it's a curious one.

[TemplarXB]

"The mid-range market is currently in the hands of Coleco due to greater production capacity, true sprite management, and better sound generators when

compared with the 5200. We are already addressing the first issue and should outdistance them in sheer numbers this year."

That is interesting. I think the Coleco and 5200 are extremely similar in graphics/sound capabilities - I wouldn't consider slight differences a reason one would pull ahead.

What I'm really interested in is if someone like Opcode could deliver a modern expansion to the 5200 to bring these long dreamt capabilities to light.

[MrMaddog]

Wow, considering that Atari had just sued Coleco for making a 2600 adaptor that's real ballsy of them to consider making their own CV clone!

 

And the combo 5200/CV is even more daring since they're talking about using the TI VDP to overlay higher rez sprites on top of the ANTIC produced backgrounds. But RAM sharing problems makes it unfeasable anyway.

 

In the end, they were better off just making CV games on the Atarisoft label...

[zzip]

That is interesting. I think the Coleco and 5200 are extremely similar in graphics/sound capabilities - I wouldn't consider slight differences a reason one would pull ahead.

 

Yeah, I recently compared a bunch of actual games on both systems, and there was no clear winner. Sometimes the CV had the better version, sometimes the 5200. Maybe on paper the CV had better specs, but in practice it often had choppier/blockier animation. So the specs weren't as important as what you did with them.

[Bill Loguidice]

Brilliant posting, Dutchman2000, thanks. Would you be opposed to me blogging about this on Armchair Arcade, quoting your post?

 

I too would argue that the Atari 5200 had enough horsepower to compete with the ColecoVision as-is, although as a ColecoVision owner back-in-the-day, I will say that Coleco's console easily had the more exciting software line-up, which was probably the 5200's biggest issue outside of the controllers. Anyway, the Atari XEGS kind of proved that, at least superficially, the Atari 5200 had the goods to compete into the 1980s. With that said, I really like the COLECOVISION + 5200 idea, particularly with having a frankenstein mode that could in theory run "Super Games," although I suspect the programming challenges to harness that mode would have been a bit more involved than hinted at. I would have preferred to see that system come out (along with Atari 2600 compatibility) instead of the release of the 7800, although the former likely would have been overpriced for the market versus the latter. Of course, the Crash pretty much put a stop to any plans like that, but it's yet again another fascinating "what if?" to a growing collection of such things.

[Dutchman2000]

No problem Bill.

[Bill Loguidice]

No problem Bill.

 

Thank you! Here's the posting: http://armchairarcade.com/perspectives/2017/09/06/blockbuster-memo-uncovered-atari-planned-incorporate-colecovision-back-1983/

[Greg2600]

GREAT FIND! Wow, just wow, what a disaster their product development was back then! The decision to convert a low end A8 basis for a home console just killed them. CV came right out of the gate with far better hardware, and it showed in the games. Upgrading the PAM or selling a monstrosity 5200 CV would have been even worse.

 

How is it this company could roll out amazing, state of the art, arcade hardware, yet always sold half-assed, out of date, poorly designed home hardware?

Edited September 6, 2017 by Greg2600

[Goochman]

IMHO the 800 could've competed very well with the CV, except Atari crippled the 5200 from the start. The 5200 should've been a cost reduced '800' not '400'. A 48k 5200 with compatibility with the computer line and a new self centering multi fire button joystick. The cross pollination should've been obvious. The computer line moves up scale with 64k of RAM and additional expansion capabilities. Win win - except we got lose, lose lose..............

[+DamonicFury]

IMHO the 800 could've competed very well with the CV, except Atari crippled the 5200 from the start. The 5200 should've been a cost reduced '800' not '400'. A 48k 5200 with compatibility with the computer line and a new self centering multi fire button joystick. The cross pollination should've been obvious. The computer line moves up scale with 64k of RAM and additional expansion capabilities. Win win - except we got lose, lose lose..............

 

So true. A 5200 that was fully compatible with the 8-bit line would have been perfectly positioned to take advantage of consumers' rising interest in home computers. Start with a great game console, then simply add a keyboard later if you want the computer experience. Combine that with a stronger launch library of games, and they could have had a real winner.

[Bill Loguidice]

The issue with Atari making the 5200 an 800 clone is that that would have further increased the retail price. As it was, it already cost more than the ColecoVision. With the 400/800 being so advanced relative to their release in the late 70s, it was difficult for Atari to find much in the way of cost savings/reductions. They would have had to have waited until the latter part of 1983 most likely to come up with a more powerful version of the 5200 that didn't break the bank. That might have given the ColecoVision too much time as the sole console powerhouse, creating a gap that would have been difficult to overcome.