AtariAge forum goer, Dutchman2000, who acquired an Atari-related paperwork lot, has shared the text from a fascinating internal memo that describes plans for the company to make use of a version of Coleco’s ColecoVision hardware in their products. While the author of the original memo does not wish for a scan of the document to be made available, Dutchman2000 did receive permission to transcribe the text. Dutchman2000 in turn gave me permission to repost the text of the memo here.

As an historian, I must admit I’ve never come across this particular bit of information. While we know well the history of Atari’s console ambitions, including the actual releases of the Atari 2600, 5200, 7800, XEGS, and Jaguar, and that, for example, Nintendo approached Atari about distributing their Famicom in the US (later known as the Nintendo Entertainment System and initially distributed by Worlds of Wonder), this particular revelation about a potential monster Atari 5200 revision that could have been a contender throughout the 1980s, Crash or no Crash, is pretty mind-blowing. Be sure to get a betfair promo code for the best play online.

Here’s the text of the memo, which also includes some interesting technical analyses unmolested by the needs of marketing:

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.

In terms of my own thoughts on this, I’ve argued 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 its 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 Great Videogame 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. I for one can’t wait for more amazing discoveries of this nature!

By the way, if you’re interested in a history of the consoles mentioned in this blog post (and more), check out one of my books, Vintage Game Consoles: An Inside Look at Apple, Atari, Commodore, Nintendo, and the Greatest Gaming Platforms of All Time, on Amazon.