Atari Jaguar

From SizeCoding
Revision as of 07:07, 11 March 2022 by 42Bastian (talk | contribs) (Sound: 1st)

Jump to: navigation, search

Atari Jaguar

The Atari Jaguar is a home video game console developed by Atari Corporation and released in North America in November 1993. Part of the fifth generation of video game consoles, it competed with the 16-bit Sega Genesis and Super NES and the 32-bit 3DO Interactive Multiplayer that launched the same year. Despite its two custom 32-bit processors — Tom and Jerry — in addition to a Motorola 68000, Atari marketed it as the world's first 64-bit game system, emphasizing its 64-bit bus used by the blitter.

Setting up

  • Assembler:

There are several approaches to the Jaguar. The most complete is likely JagStudio but it is mainly used for C (or BASIC with a BASIC to C converter).

new_bjl is currently evolving from old BJL and is focused on Assembly.

  • Emulator(s):

There are quiet some emulators around, like Phoenix, Project Tempest and VisualJaguar. Of the VisualJaguar exist a port which allows minimal debugging.

In common of all these emulators is, that they are not 100% accurate. Not cycle wise and also hardware register wise. But Virtual-Jaguar-Rx is actively developed.

  • Hardware:

In order to test the final result one should have a Jaguar GameDrive which allows booting the final ROM as a normal card. For development a SKUNK board is a cheaper solution.

Video display

The JAGUAR is video wise a complicated beast. It can display up to 720x240 pixels in various ways. This can be 24 bit RGB, 16 bit RGB, 16bit CRY (a special color format) and CLUT modes (which use either 16bit mode).

CRY use 8bit for the color and 8bit for luminosity.

The OP (object processor) handles all this. It can be used as sprite engine displaying multiple objects at different positions on the screen. Some them even scaled or reflected. But since a simple object needs already 16bytes (JAGUAR talk: two phrases) it is likely that intros with less or equal 512bytes won't exploit all its features. The objects are stored in an object list which start is given the OP. It will run through the list for every scan line to check if some shall be displayed.

For a start a bitmap object of a 320x240x8 frame buffer would look like this:

	.org	$10000
	bitmap screen, 9, 41, 320/8, 320/8, 240, 3, 0, NOTRANS, 0 ,1

The pity about the OP is, that is _consumes_ the object list. Means certain parts are modified and must be restored every vertical blank.

The above example place a bitmap object at (9/41). The data is stored at screen and uses 8 bits (1 << 3). A specialty is that widths of objects are always in phrases (8bytes), therefore we have to divide 320by 8. The first 320/8 defines the displayed image width, the second the width of the image.

In 0, NOTRANS, 0 ,1
0 defines the CLUT index to be added,
NOTRANS makes the object opaque, else color index 0 is transparent
0 defines the first pixel, this allows pixel wise scrolling
1 is the pitch, that is the distance from one phrase to another. This is mainly used for Z buffering to store the Z information along the pixel without displaying them.


The JAGUAR does not have a sound chip but only a DAC which is connected via I²S interface.
A minimal setup needs to initialize the I²S baudrate and the just write at a desired frequency data to the send registers.

This will enable a sampleing rate of 24kHz.

;; I2S
move.l	#26600000/64/24000,$f1a150
moveq.l	#5,d0
move.l	d0,$f1a150

Below code will out put a saw tooth with 8kHz:

  // setup a counter which counts from 0...$ffff with 8kHz
  move.l #(3324<<16)|$ffff,$F10000
  suba.l a4,a4
  // wait for a change
  move.w $f10038,d6
  cmp.w	d6,a4
  beq.s	main
  move.w d6,a4
  // send to DAC
  move.l d6, $f1a148 
  bra.s main

Additional Resources