Super interressant!!! J' avais pas vu ce post!
Allez je mets le contenu ici , faut garder ca!
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.
Auteur