World Library  
Flag as Inappropriate
Email this Article

Atari Jaguar II

Atari Jaguar II
Manufacturer Atari Corporation
Type Video game console
Generation Sixth generation
Retail availability Cancelled in 1995
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 1
  • Technical specs 2
  • Internal Blocks 3
    • CPU 3.1
    • GPU 3.2
    • Blitter 3.3
    • Object Processor 3.4
    • DSP 3.5
    • System Performance 3.6
    • Details relative to Jaguar 3.7
  • See also 4
  • External links 5


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

Size: 10.5" × 12" × 3.5"
Controls: Power on/off
  • 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)
  • 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


  • 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


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


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 schemes

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


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.

See also

External links

  • Jaguar Frequently Asked Questions (FAQ), including information on the Jaguar II
  • Photos and infos on the Jaguar II
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.