Atari Jaguar II

Atari Jaguar II
Manufacturer Atari Corporation
Type Video game console
Generation Sixth generation
Retail availability Cancelled in 1995
Backward
compatibility		 Atari Jaguar, Jaguar CD
Predecessor Atari Jaguar

The Atari Jaguar II was to be the successor to the Atari Jaguar. The console reached the lab prototype stage with partial working silicon. The project was cancelled in the summer of 1995 before a final design could be completed, and before Atari merged with hard drive manufacturer JTS Corporation. The Jaguar 2 was intended to be backward-compatible with Atari Jaguar cartridge and Jaguar CD.

History

Jaguar II was an evolutionary upgrade to Jaguar, developed in Atari's labs in Sunnyvale, California by a team led by John Mathieson, one of the designers of the original Atari Jaguar. It was intended to be software compatible with Jaguar, and was a superset of it. It used newer technology to speed up the Jaguar system, address short-comings in its architecture, and to make major improvements to the specification.

The project code name was "Midsummer", an arbitrary reference to A Midsummer Night's Dream; and the two main chips were named Oberon and Puck, references to characters in that play.

Development of the project started in January 1994, and working prototypes were running demos by March 1995. The Oberon graphics chip, which replaced Tom from Jaguar, was finished and was running in this prototype. Its companion chip, Puck, had not completed design by the time the project was cancelled in the summer of 1995 (the prototypes used Jerry chips).

The goals of the project were to substantially improve performance in the following areas:

Technical specs

Size: 10.5" × 12" × 3.5"
Controls: Power on/off
Ports:
  • Cartridge slot/expansion port (64 bits)
  • RF video output
  • Video edge connector (video/audio output) (supports NTSC and PAL; provides S-Video, Composite, RGB outputs, accessible by optional add-on connector)
  • Four controller ports
  • Digital Signal Processor port (includes high-speed synchronous serial input/output)
Controllers:
  • Eight-directional joypad
  • Size 5" × 4.5" × 1.5", cord 7 feet (2.1 m)
  • Six fire buttons (A, B, C, D, E, F)
  • Pause and Option buttons
  • 12-key keypad (accepts game-specific overlays)

Internal Blocks

CPU

GPU

The GPU and Blitter were the rendering engine for 3D graphics. The GPU was very similar to the RCPU, and was coupled on a fast local 32-bit bus to the blitter. The GPU was intended to calculate blitter polygon parameters while the blitter is drawing them.

Blitter

The Blitter was a 64-bit triangle rendering engine. It rendered triangles as a single operation, and these triangles could be any combination of Gouraud or Phong shaded, texture mapped and Z-buffered.

Object Processor

The Object Processor was a very flexible 64-bit list processor to generate the display. The display was built in a local line buffer from multiple bit-maps, which could be at different color resolutions. It performed scaling, shading and fog effects on bit-map data. It could behave like a traditional sprite engine, but was far more flexible and programmable.

The CRY color scheme used 8-bits for intensity and 8-bits for chroma, allowing smooth Gouraud shading from 16-bit pixels.

DSP

The DSP was a 32-bit RISC processor, based on the same RISC core as the GPU and RCPU. It contained a local PCM sample generator coupled to private sample memory which generated 24 voices at 44 kHz in parallel with the flexibility and power of the DSP.

System Performance

The Midsummer system was intended to be run from a 33 MHz clock. At 33 MHz the main system bus had a sustained burst rate of 133 MB/s. Assuming 16-bit pixels, which may be RGB or CRY, the blitter and object processor could both write and read pixels at 66 megapixels per second.

This gave the blitter a shaded, texture-mapped polygon rate of 750K polygons/second. This assumes a 10x10 triangle containing 50-pixels. Of course, realistic system performance would be lower as this assumes no overhead for computation or for display generation time.

The Jaguar RISC processors execute one instruction per clock cycle. They therefore have a peak instruction through-put of 33 MIPs, and a realistic performance level of 25-30 MIPs. This gave a combined system performance approaching 100 MIPs, as all three processors run in parallel from local memory. They can also execute code from main DRAM, although only the RCPU is well suited to this as it has an instruction cache.

Details relative to Jaguar

This lists full details of the improvements, relative to the original Jaguar:

In addition, some bugs that created problems for Jaguar One programmers have been fixed:

External links

This article is issued from Wikipedia - version of the Monday, March 07, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.