Difference between revisions of "Atari Jaguar"
(1st) |
(→Video display: 1st) |
||
| Line 18: | Line 18: | ||
=== Video display === | === 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: | ||
| + | <code><pre> | ||
| + | OBL0: | ||
| + | .objproc | ||
| + | .org $10000 | ||
| + | bitmap screen, 9, 41, 320/8, 320/8, 240, 3, 0, NOTRANS, 0 ,1 | ||
| + | stop | ||
| + | .68000 | ||
| + | OBL0_end: | ||
| + | </pre></code> | ||
| + | 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 <code>(9/41)</code>. The data is stored at <code>screen</code> and uses 8 bits (1 << <code>3</code>). A specialty is that widths of objects are always in phrases (8bytes), therefore we have to divide <code>320</code>by 8. The first <code>320/8</code> defines the displayed image width, the second the width of the image. | ||
| + | |||
| + | In <code>0, NOTRANS, 0 ,1</code><br> | ||
| + | <code>0</code> defines the CLUT index to be added,<br> | ||
| + | <code>NOTRANS</code> makes the object opaque, else color index 0 is transparent<br> | ||
| + | <code>0</code> defines the first pixel, this allows pixel wise scrolling<br> | ||
| + | <code>1</code> 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. | ||
=== Sound === | === Sound === | ||
Revision as of 05:56, 11 March 2022
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:
OBL0:
.objproc
.org $10000
bitmap screen, 9, 41, 320/8, 320/8, 240, 3, 0, NOTRANS, 0 ,1
stop
.68000
OBL0_end:
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.
Sound
No information yet
