The Atari Panther - Part 4 - Deep dive
Welcome back to this series of articles. In this 4th part we will go deeper on how the system works.
![]() |
| A 3D rendering of the Atari Panther. Author unknown. |
Articles:
- Part 1 - The history
- Part 2 - The hardware
- Part 3 - Declared features
- Part 4 - Deep dive
- Part 5 - Fun with object lists
Audio
The Panther prototype does not have a custom audio chip, however it uses a standard chip from Ensoniq. Ensoniq is the company created by the team that developed the historic Commodore 64 SID audio chip.
The Ensoniq ES5505 OTIS is not just sample player, it can be used as a powerful synthesizer complete of digital filters. Indeed this chip is inside the famous Ensoniq EPS 16 plus, many arcade machines of the time and PC sound cards.
| EPS 16+ demo |
As you can hear, the Panther could have been far beyond both the Megadrive and the SNES on the audio side.
CPU speed
In part 2 we saw that Panther’s CPU is a Motorola 68000 @ 16 Mhz with a maximum speed of 2.8 MIPS. We also saw that when working from ROM it has to slow down becoming 50% slower. So it is important to copy critical code in SRAM.
Anyway, there is another bottleneck. The Developer Manual states that the Panther Chip acquires the main bus at the beginning of every scanline and releases it only when it completes the processing of the Object List. When this happens the CPU gets the main bus. This is also confirmed by:
- the schematics clearly show that the 68000 is directly connected to the SRAM. There is not decoupling logic (74LS244, 74LS373 & similar) to detach it from the main bus so it can be shared.
- the Panther chip is connected to the BR, BG, BGACK pins of the 68000. This confirms that the Panther chip can steal the bus from the 68000.
The access pattern is therefore:
vblank scanlines: __cc__cc....__cc__cc....__cc
visible scanlines: PPPPPPPP....PPPP__cc....__cc
^--end of obj list processing
P = Panther chip memory access
c = CPU memory access
_ = Not used memory access
Note how memory cycles are wasted during vblank and how the CPU is paused while graphic is processed.
On scenes with a lot of sprites on screen the CPU can basically work only during the vblank. This means the CPU can work only:
- NTSC (262-200)/262 = 24% of time.
- PAL (312-256)/312 = 18% of time.
In systems like the Commodore Amiga or the Atari ST, the CPU idle cycles are used to interleave graphic memory accesses. So, the CPU can run at full speed (on the Amiga this is true only up to 16 colors low resolution, then the graphic chip starts to slow down the CPU).
In systems like the Sega Megadrive or the Nintendo SNES, the CPU run at full speed because it doesn’t share memory with the graphic chips.
When compared to Amiga, ST, SNES and Megadrive, the Panther has a CPU which is twice faster IF the CPU is not slowed down by the Panther Chip. This can be an advantage in 3D graphic.
Colors
The Panther has a Color Look Up Table of 32 entries of 18 bits each (262K shades).
18 bits color resolution is more than any console of the era, but on a TV screen, going above 12 bits starts to be pointless.
Instead, 32 CLUT entries are very few for a machine of that period. For example, the Commodore Amiga (designed 6 years before in 1983) has 32 entries. The Sega Megadrive has a CLUT with 64 entries of 9 bits each (512 shades), the Nintendo SNES has a CLUT of 256 entries of 15 bits each (32K shades).
An interesting feature of the Panther is that the Bitmap Object (sprites) descriptor contains a CLUT offset. This is added to the value encoded in the pixel data to define the value written in the line buffer. For example, if a pixel has a value of 3 and the CLUT offset is 7 then CLUT entry 10 is used.
For contrast, the Megadrive has a CLUT with 64 entries split in 4 banks of 16. Every sprite or tile has to select one of the 4 banks. This can be wasteful. For example, if two sprites has 8 common colors and 8 different colors they must use two different banks wasting 8 CLUT entries. Conversely, on the Panther the two colors set can overlap over the common colors.
Megadrive case:
bank 1: ABCD EFGH ilmn opqr ← Sprite 1
bank 2: STUV ZXYW ilmn opqr ← Sprite 2
bank 3: .... .... .... ....
bank 4: .... .... .... ....
ilmn opqr = common colors
Panther case:
┌─────────────────┐Sprite 1
clut: ABCD EFGH ilmn opqr STUV ZXYW .... ....
└──────────────────┘Sprite 2
As already explained in Part 3, both the CPU and the Panther Chip (via Palette Object) can manipulate the CLUT. Even better, the Panther Chip can change the CLUT automatically at a given scanline (see Palette Object).
We can imagine that Panther games would have used Palette objects quite extensively to appear as colorful as other game consoles. An useful setup could have been: reserving some of the CLUT entries to the playfield so they are not used by moving objects. Then change these entries frequently across the scanlines to introduce more colors in a controllable way.
How does it compares?
- Amiga: typically Amiga games use 16 entries plus a bit of dynamic CLUT. Panther games would have been more colorful.
- Megadrive: it has more CLUT entries but the Panther is somehow more flexible. Panther games would have been a bit less colorful.
- SNES: with 256 CLU entries, there is no game. Panther games would have been less colorful.
Resolution
The Panther has a fixed resolution of 320 * 200 pixels (NTSC).
The SNES has 256 * 224 or 512 * 224, very few games used the high resolution mode.
The Megadrive has 256 * 224 or 320 * 224 modes.
Arcade games of the era often had an horizontal resolution of 320 or 256 pixels. When a game is ported from an Arcade machine to a game console, it is necessary to convert the graphic. When the graphic resolution doesn’t match (for example the Arcade has 256 pixel and the console has 320 pixel) the graphic has to be resampled. This often requires lot of manual refinement. In these context, the Megadrive simplifies the process by supporting both 320 and 256 horizontal pixels.
The Panther has the ability to zoom sprites, this may have been helpful in this case to work around the absence of 256 * 224 resolution.
Games console typically use the whole TV screen. This is achieved by using a slower pixel clock compared to home computers. For example, the SNK Neo Geo, famous for its extreme overscan, used a 6 Mhz pixel clock.
The Panther seems to use a pixel clock of 8 Mhz. This means very large borders, even larger than those of the Commodore Amiga, which had 7.19 Mhz pixel clock.
This could have been fixed easily on the final machine by just creating a 6 Mhz pixel clock from the 8 Mhz system clock.
Closing
Thank you for reading up to this point ! The deep dive is not complete yet, so expect another article.

