Atari Jaguar II

Infobox CVG system
title = Atari Jaguar II



manufacturer = Atari Corporation
type = Video game console
generation =
lifespan = prototype in 1995
CPU =
media =
onlineservice =
topgame =
compatibility = Atari Jaguar, Jaguar CD
predecessor = Atari Jaguar
successor = Atari Flashback

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:

* polygon rendering speed
* texture mapped polygons
* computational ability
* audio synthesis

Technical specs

Internal Blocks

RCPU

The RCPU was new for Midsummer, and was specifically tuned for running C code. It was intended to act as the CPU of the system, and as the geometry engine for 3D graphics.
* 32-bit RISC processor
* 4 kB of 2-way set-associative cache
* 1 kB fast local data RAM
* cache line fill operations at the full 64-bit bus rate (133 MB/s)
* extended precision (16 x 32) single cycle multiplier, and fast divider
* 64-bit DMA engine to and from system DRAM at full bus rate

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.
* 32-bit RISC processor
* 4 kB of fast local program/data RAM
* 8 kB of RAM either for texture buffers or for further program/data RAM
* single cycle multiplier, and fast divider
* DMA engine to and from system DRAM at full bus rate

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.
* 64-bit flexible rendering co-processor
* 8 kB of texture buffer RAM (can be shared with GPU)
* 8 kB of generic texture ROM
* texture mapping from local texture buffer or from main memory
* triangle draw as a single operation
* Z-buffering
* anti-aliased texture mapping (bi-linear interpolation)
* true-perspective texture mapping
* Gouraud or Phong shading, fog effects, colour blending and alpha-mixing all possible on texture data

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.
* 64-bit display generator
* up to 24-bits per pixel
* supports bit-maps at mixed color depths
* smooth image scaling (8.8 bit resolution)
* bit-map darkening, lightening and fog effects
* supports RGB or CRY color schemesThe 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.
* 32-bit RISC processor
* 8 kB of fast local program/data RAM
* single cycle multiply/accumulate, with 40-bit accumulator precision
* PCM sample generator from private memory, up to 1 MB DRAM or ROM
* PCM samples can be interpolated 8-bit, 16-bit and 8-bit -law compressed samples
* synchronous serial interface to CD quality DAC
* 64-bit DMA engine to and from system DRAM at full bus rate

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:

* There is an additional Jaguar RISC (J-RISC) processor, known as the RCPU, with a simple program cache. It is intended to perform the functionality of the CPU, acting as a geometry engine, and it is well suited to executing compiled code.
* The blitter can now draw polygons as a single operation. These may be just filled, or any combination of Gouraud shaded, Z-buffered, and texture mapped.
* The blitter can now draw texture maps at full bus speed  a maximum of one phrase per two clock cycles, from internal texture memory, and can also operate from external texture RAM more efficiently that before.
* The blitter can anti-alias textures as it renders them, using bi-linear filtering.
* The texture mapping and Gouraud shade modes can be combined to give shaded texture-mapped polygons, with Z-buffering as well if required. These can also be drawn at full bus speed. The shading is a multiplicative mix of the texture data and another colour, allowing lightening, darkening, distance-haze and other effects.
* The intensity calculations are now carried out with an extended range, using an eleven bit signed integer to represent intensity, this value being clipped (saturated) only when the pixels are drawn.
* A subset of the blitter registers are double-buffered, so that a polygon drawing engine can program the parameters for a polygon blit while the previous blit is still under way.
* There is no need to initialise all four I and Z values (or texture pointers) for a phrase mode blit, the blitter can automatically initialise them appropriately.
* The blitter address generators now both have clip window and mask functions. Formerly A1 had a clip window and A2 had a mask.
* The GPU has an overflow flag which reflects signed arithmetic overflow from add or subtract operations, and also gives the state of the bit modified by bit clear and set operations before the clear or set.
* The jump condition codes have been extended to cope with the new overflow flag, and now include all the conditions available on general purpose micro-processors, e.g. the 68000.
* The NOP instruction has been extended, so that if its operands are not zero then it becomes an unconditional jump relative with a ten bit signed jump offset, giving an increased range.
* Byte and word transfers to GPU RAM are now possible.
* The J-RISC processors all contain a simple DMA transfer engine, which allows full bus rate phrase mode transfers between internal and external memory. This speeds up program loads and data set transfers.
* The PACK and UNPACK instruction can now operate on RGB16 pixels as well as CRY.
* The object processor can now clip at a right hand side value of less than 720 by setting the limit register.
* The object processor can force the select bit for mixed CRY/RGB screens on a per-object basis.
* The object processor supports line-doubling so that a TV picture can be displayed on a progressive VGA monitor.
* The object processor can multiplicatively mix the pixel color with a “fade to” color according to a mix control value. A new object type defines the mixer control value and the mixed color.
* RMW objects can now have double the “strength”.
* Scaled objects may now be controlled to a higher precision, and the horizontal remainder may now be defined.
* Some additional extended jump condition codes allow debug functions, such as interrupt, stop and pause.

In addition, some bugs that created problems for Jaguar One programmers have been fixed:
* Score-board protection for writes is available, so that writes do not occur out of order. This is enabled by the GPU enhanced mode bit.
* GPU code can be executed out of external RAM.
* The blitter address flags for Y add control are now properly differentiated, there is an enable bit in the Collision control and Mode register that has to be set to fix this bug.
* The data register of an indexed store instruction now has full score-board protection.
* Problems related to MOVEI instructions at the beginning of a program, particularly when single stepping, have been resolved.
* Unscaled objects are now fetched at full bus speed.
* The pixel pre-scaler is now reset on the last line of the display, so the display need not be over-scanned to conceal it.
* Two divides may follow each other when one uses the quotient of another.
* The DSP external DMA interface has been completely overhauled, and will now support low and high priority transfers; as well as arbitrary load/store combinations and alignments.
* A variety of problems related to blitter window clipping have been resolved.

ee also

*Atari 2600
*Atari 5200
*Atari 7800
*Atari Lynx
*Atari Panther
*Atari Jaguar

External links

* [http://www.electric-escape.net/atari/Jaguar/FAQ Jaguar Frequently Asked Questions (FAQ), including information on the Jaguar II]
* [http://www.atarimuseum.com/videogames/consoles/jaguar/jag2.html Photos and infos on the Jaguar II]