Atari ST ASIC designs and GAME SHIFTER

[kool kitty89]

https://www.chzsoft.de/asic-web/

 

 

There's a lot of neat leaked documentation, schematics, and some commentary on Atari ASIC designs there, some prototypes and some that ended up in the STe, TT, Falcon, and Jaguar. Also interesting to note the dates on various documents and technical drawings. (among other things, some of them go along with other info I've seen in old interviews or magazine articles pointing to the STe chipset being designed over a year earlier than it was and was delayed for some reason: existing ST sales/demand being high enough is one cited reason; the TT chips also seem to be significantly older than most of the system, but that's also obvious from the 1988 copyright date printed on several chips actually used in production TTs)

 

I'm not sure if this fits best in the ST/Falcon section or Prototypes, but it seems mostly to be Atari 68k based computer stuff, so seemed relevant here.

 

 

 

 

The most intriguing thing in there for me is the GAME SHIFTER, which seems like it might be the PANTHER object processor ASIC or at least the video generator portion of it. It's numered ST-4118 and that's also printed on the socketed 84-pin LLC seen on the Panther development system. (and that chip has lines connecting to a resistor array containing 3x 12 resistor banks, almost certainly R2R networks for 18-bit RGB output, which the Panther used)

 

The fact that it has an ST related part number could be related to the Styra Semiconductor Corporation as noted on that page, but many of the ST-related ASICs also share that designation, so it's not really clear. (and also not clear if Styra was even making those custom chips for Atari)

 

It makes me wonder if the Panther graphics chip(s) were intended for an upgraded Atari ST as well. (if it was intended for the computer market, it would've been kind of weird, but neat in some ways: the line buffers could be exploited to line-double 15 kHz lowres framebuffer modes to VGA synch rates and use the same memory bandwidth, the object list processing could be used for GUI window acceleration, obviously TOS-support-dependent, and a few other non-game related things; and the Panther definitely used packed/chunky pixels and not bitplanes, so all the advantages of that as well, though the disadvantage of using 8bpp for just 32 colors due to the 5-bit line RAM and 32x18-bit CLUT, but 4/2/1-bit bitmap objects could use any consecutive set of those 32 colors via an 8-bit offset, like the Jaguar and also like the Lynx's 4-bit palette offset)

 

**note one of the laziest uses for the multiple-framebuffer window and 32 color palette set-up would be an AGA Amiga style 2 playfield mode with dedicated 15 colors + transparent + BG color, or an even lazier OCS/ECS Amiga simulation of a single 16 color playfield and 15 color sprites. (far poorer utilization than optimizing graphics around the 8-bit offset feature of the palette, which itself is obviously far more work than if a full 256 entry CLUT and 8-bit line RAM was present, but still a lot better than the STe's color limitations and arguably better than the Mega Drive's 4x15 +1 color 9-bit RGB CRAM)

 

If the Panther object processor actually used its line RAM more like the 7800's MARIA does, then 320x5-bits could be expanded to 800x2-bits or 1600x1-bit, which would be of little use to games but very useful for highres computer graphics. (more situations where lines could be double-buffered for efficiency/flexibility and potential line doubling, plus even more necessary if the Panther lacked the ability to chain line buffer reads, limiting screen width to a single line buffer's length)

Using the ST Blitter would also be fastest on 1-bit bitmaps, so a highres framebuffer mode or drawing to multiple 1-bit object windows. (even more useful assuming the Panther can do opaque 2-color 1-bit bitmaps like the 7800 Kangaroo mode: rectangles without sprite transparency)
 

Also worth noting: the Panther development board also uses the same 32.2159 MHz oscillator frequency as the NTSC STe uses. (good for monitor compatibility and system clock compatibility, not so good if games actually used the same 8.05 MHz dot clock due to the large border and NTSC color artifact issues, though 32.2/5 = 6.44 MHz would be much better and also have nearly square pixels)

 

Presumably, in the ST, the Panther would be using the same 32kB of fast 32-bit SRAM (35 ns chips used on the dev boards, but being used at 31 ns) and could exploit ST RAM like 500 ns 16-bit ROM using the existing SHIFTER DMA cycles, except able to use an entire H-time worth of bandwidth (or multiple H periods) aside from the DMA sound access slots. (disabling interleaved DMA for 250 ns saturated/cycle stealing access would allow higher bandwidth at the expense of CPU performance, unless you also used a 12 or 16 MHz 68000 and give the CPU access to all bus cycles as well for serial use of the full bus bandwidth; better still if the Blitter and DMA chip could use both even and odd bus cycles as well)

 

Though aside from that, some 16-bit wide 120 ns SRAM used as dedicated object data/framebuffer memory could allow neat high bandwidth modes (and potentially CPU interleaved 250 ns modes too) and 256 kB of SRAM on an upper-scale model would allow single-buffered 1600x1200x1bpp 60 Hz or double-buffered 800x600x2bpp 60 Hz (and potentially 50/50 bus interleaved with the CPU/DMA chips). Which would be nice monochrome/grayscale workstation class resolutions in 1989/1990, sort of like a low-cost competitor to NeXT, especially if they included a 56k DSP option. (which has implications for both audio work and 3D graphics)

Edited November 11, 2019 by kool kitty89

[kool kitty89]

Looking over the schematics more myself, it looks like the Game SHIFTER chip (4118 ASIC) might not be the entire PANTHER video ASIC, but just the video shifter portion with pixel data registers and palette registers (32 18-bit CRAM entries) but not the object processor or line buffers. 

 

The Panther dev systems have an additional Toshiba Gate array chip onboard, which may be the actual object processor chip with line buffers with a data port for the SHIFTER to access the line ram from and DMA data.

 

It looks like there's multiple sets of 5 registers with 16-bit inputs accumulating to 5-bit outputs, which seems like it'd be used for bitplane data on 16-bit word chunks like the ST SHIFTER uses, just with 5 rather than 4 bitplanes max, which seems kind of inefficient for a system using chunky pixel data natively (no need for that much chip space used when you could just read and latch an entire chunky pixel at once, or 2 pixels packed into a 10-bit word; logically treated as 8-bit packed pixels in a 16-bit word, but could be done on 10 data lines and 10 and 5-bit data words internally).

 

So it seems like Atari may have been planning to use a version of the SHIFTER with support for 5 bitplane modes at one point and recycled it as the video generator portion of the Panther, which would also mean they went through the trouble to have the object processor ASIC translate packed pixel data to bitplane words internally. (or assuming the CPU-addressible and object processing back buffer end does all work on 8-bit chunky pixel data, the translation would be through memory mapping on the output data port the SHIFTER reads from, assuming my inference is at all accurate) 

 

That in turn implies they could have been intending the 4118 ASIC itself as a standalone video chip in a computer, like a further upgrade to the STe's SHIFTER or a competing design that ended up scrapped. (like maybe lacking scroll registers or DMA sound support)

Or is the scrolling and fine address control handled on the MMU/MCU end in the STe?

Though the schematic drawings are dated well after the STe hardware was designed (or even introduced) and the 4118 chip uses an 84 LLC package like the GST SHIFTER so may have been intended as a plug-in, pin-compatible upgrade to the STe. (or factory assembly line replacement, since Atari wasn't particularly keen on actually shipping upgrade parts, but then the STe did have its SHIFTER socketed, so it'd be an easy dealer-level chip upgrade or an end-user one)

 

5-bitplane modes with an 18-bit RGB colorspace would've been interesting though, and assuming they were targeting the same 8 MHz dot clock and bus timing arrangements, that would imply a 10 MHz CPU clock and 20 MHz MMU clock. (though they could've just used 32/5 MHz for the dot clock, so 6.4 MHz, or 6.44 MHz for the STe's NTSC 32.2159 MHz clock)

The latter might actually make more sense given Atari seemed to be resistant to messing with the MMU timing at all, plus 6.44 MHz gives much closer to square pixels for NTSC (and should have less severe composite video artifacts) and would also fill out the screen to the borders, but conversely would tend to overflow 320 pixels off screen on TVs (or monitors without generous border adjustment) for around 307 pixels visible. 

 

That's also assuming a 320x200 resolution was intended and addressing matched that, but if they stuck with a 32kB screen space, 256x200 would use the exact same 32000 bytes as all the existing ST screen modes and also use the exact same screen and border space size. (albeit if that's the case, it would've been handy if they also let it switch to 5.37 MHz for a nice full width TV display and nice 1.5x colorburst in NTSC for good TV game purposes)

Given Atari's track record with the ST by 1989, yet another 32000 byte screen mode with identical hblank/vblank timing to the existing STe seems pretty likely, and not particularly amazing but at the same time still better than what they actually put out there in the STe range. (and would've been particularly nice in the MEGA STe ... or a cheaper, cacheless 16 MHz STfm cases STe+ sort of deal)

 

 

 

That might also explain why the Panther's development got strung along through 1990: the 1989 system needing 2-chips for video and not being cost-effective enough, and they just stuck with the 5-bit wide line RAM throughout. (granted, upgrading to 8-bits and 256 colors would've made going to a single chip even harder, but then doing away with bitplane translation and doing all the video generation stuff internally with an 8-bit digital video bus output would mate well to a VGA style 256x18-bit RAMDAC for a more economical 2-chip solution for an 8-bit chunky pixel system, and would've made the Panther far more relevant in 1991) Gate array logic is also relatively easy to modify and usually fast to have new masks made for testing, so that should've worked out well too. (and the object processor architecture itself already treated line RAM as 8-bits wide logically, so programming wouldn't be any different, palete select was via an 8-bit linear offset for lower color depths, and the RLE pixel mode used an 8-bit color select with 3 bits totally wasted)

 

I also assume a RAMDAC would be cheaper than repurposing the TT SHIFTER for a 2-chip solution using 256x12-bit color. (plus 18-bit color is nicer)

 

 

Though come to think of it, the TT SHIFTER works similarly at least: it's got the 64-bit wide bus buffering data and spitting out out faster through a 16-bit port to the SHIFTER, right? ... sort of like it could've been used on a cheaper 32-bit wide set-up at half the resolution. (like 640x240x4bpp and 320x240x8bpp plus 512x200x6 or 400x256x6 on TVs/mid-res monitors and 320x480x4bpp at VGA res or 640x480x2bpp or 768x400x2bpp given 32 MHz dot clock on normal VGA monitor calibration would allow more like 819 pixels in the space 640 usually goes; also potentially 512x400x3bpp and 256x400x6bpp)

I wonder if something like that was originally planned with the earlier 68020 machine developments and so-called SHIFTER II. (except it still would've been a fine fit for a 16 MHz 68020 or EC020 machine as a lower/mid-range mainstream market complement to the TT in 1990, or a cheaper version with 16 MHz 68000 with or without MEGA STe style cache, especially with a 32-bit latch connected to 32-bit RAM)

 

Actually a 12 MHz 68020 on a 32-bit bus with the same old 500 ns ST MMU bus slots would work out with 3 wait states and 6 CPU clocks per access slot. Plus 12.5 MHz was the bottom-end 68020 offering, but I think that was only true somewhat early on and the 16 MHz grade replaced it. (and seems to only exist in the PGA version, not the PLLC or CLLC surface mount versions) 16 MHz with 8 cycle slots would be OKish (still faster than the Amiga 1200), but much better with optional local fastRAM. (though a 16 MHz 68000 or 68010 using 8-cycle slots on a 32-bit bus latch could avoid wait states when doing 32-bit alligned operations and while filling prefetch without needing additional cache; also assuming data gets latched within 125 ns, which might mean changing MMU parameters for faster DRAM access timing even if cycle times stayed at 250 ns, which would be right for 120 ns DRAM since 187.5 ns cycles would probably be stressing that too far out of spec and need 100 ns chips: the ST's 248~250 ns cycles pushed 260~270 ns rated parts much more within other tolerances and operating temperature/other conditions)

With normal ST MMU timing, you'd be stuck with wait states on a 16 MHz 68000, and mis-alligned 32-bit accesses (9 or 10 cycles rather than aligning with 8), but that'd still help for slower instructions doing 32-bit read/write operations at least. (especially stuff like 32-bit arithmetic, and really slow things like multiplication and division would get a big boost even if you had just the 16-bit bus latch to work with, for things like 3D calculations, 2D scaling, sound sample scaling or interpolation, DSP type stuff)

 

 

 

 

For that matter, a stripped-down STe with that 16 MHz CPU and 32-color Game SHIFTER might have been OK as a game console in 1989. (or going really cheap and feeding the SHIFTER with a 26.85/26.6 MHz clock, so the MMU gets a 13.4/13.3 MHz signal, you end up with slower 298 ns DRAM cycles and can use cheap, old 200 ns DRAM like left over XE/XEGS DRAMs and 596 ns 68k access slots and a 6.7 MHz CPU speed or better: tap the 1/4 clock output from the MMU for 3.355/3.325 MHz and use a PLL for a 3x multiplier to 10.07/9.98 MHz and 6-cycle 2-wait-state bus slots, or just run straight off the 13.3 MHz clock with 8-cycle bus slots, though you could potentially add a little 16kB of 200 or 150 ns SRAM/PSRAM to work in without wait states)

And even 128 kB of slow 16-bit DRAM would be a lot more flexible than the 32kB the Panther was planned to have. (64 kB double buffered framebuffer, 64 kB to work in, plus ROM could be on the local CPU bus and have fewer wait states and/or letting the blitter interleave ROM access with the CPU, or both: with 300 and 200 ns ROM cycle options interleaving in 600 or 400 ns slots and the blitter having 6.7 and 10 MHz clock settings while the CPU has 2-wait and no-wait state settings)

 

There's also going the other direction and using a faster MMU with slower SHIFTER DMA and more CPU+blitter access slots. (using a simple 3-way split with 200 ns bus cycles using 120 ns DRAM and 20 MHz MMU, and/or a smarter MMU on top of that that gives access to vblank and maybe hblank SHIFTER bus cycles to the blitter and maybe CPU)

 

Messing around with timing and bus sharing is also a lot easier on a platform that doesn't have to be backwards compatible. (plus they could've dropped the LMC1992 and used a more barebones sound amp circuit, but a nice hack would've been a 16-bit mono mode that connected to the 8-bit channels, or the same thing but also dropped the discrete 8-bit DACs for barebones R2R networks that could be chained to 16-bit mono)

[Lynxpro]

On 11/10/2019 at 9:16 PM, kool kitty89 said:

https://www.chzsoft.de/asic-web/

 

 

There's a lot of neat leaked documentation, schematics, and some commentary on Atari ASIC designs there, some prototypes and some that ended up in the STe, TT, Falcon, and Jaguar. Also interesting to note the dates on various documents and technical drawings. (among other things, some of them go along with other info I've seen in old interviews or magazine articles pointing to the STe chipset being designed over a year earlier than it was and was delayed for some reason: existing ST sales/demand being high enough is one cited reason; the TT chips also seem to be significantly older than most of the system, but that's also obvious from the 1988 copyright date printed on several chips actually used in production TTs)

 

I'm not sure if this fits best in the ST/Falcon section or Prototypes, but it seems mostly to be Atari 68k based computer stuff, so seemed relevant here.

 

 

 

 

The most intriguing thing in there for me is the GAME SHIFTER, which seems like it might be the PANTHER object processor ASIC or at least the video generator portion of it. It's numered ST-4118 and that's also printed on the socketed 84-pin LLC seen on the Panther development system. (and that chip has lines connecting to a resistor array containing 3x 12 resistor banks, almost certainly R2R networks for 18-bit RGB output, which the Panther used)

 

The fact that it has an ST related part number could be related to the Styra Semiconductor Corporation as noted on that page, but many of the ST-related ASICs also share that designation, so it's not really clear. (and also not clear if Styra was even making those custom chips for Atari)

 

It makes me wonder if the Panther graphics chip(s) were intended for an upgraded Atari ST as well. (if it was intended for the computer market, it would've been kind of weird, but neat in some ways: the line buffers could be exploited to line-double 15 kHz lowres framebuffer modes to VGA synch rates and use the same memory bandwidth, the object list processing could be used for GUI window acceleration, obviously TOS-support-dependent, and a few other non-game related things; and the Panther definitely used packed/chunky pixels and not bitplanes, so all the advantages of that as well, though the disadvantage of using 8bpp for just 32 colors due to the 5-bit line RAM and 32x18-bit CLUT, but 4/2/1-bit bitmap objects could use any consecutive set of those 32 colors via an 8-bit offset, like the Jaguar and also like the Lynx's 4-bit palette offset)

 

**note one of the laziest uses for the multiple-framebuffer window and 32 color palette set-up would be an AGA Amiga style 2 playfield mode with dedicated 15 colors + transparent + BG color, or an even lazier OCS/ECS Amiga simulation of a single 16 color playfield and 15 color sprites. (far poorer utilization than optimizing graphics around the 8-bit offset feature of the palette, which itself is obviously far more work than if a full 256 entry CLUT and 8-bit line RAM was present, but still a lot better than the STe's color limitations and arguably better than the Mega Drive's 4x15 +1 color 9-bit RGB CRAM)

 

If the Panther object processor actually used its line RAM more like the 7800's MARIA does, then 320x5-bits could be expanded to 800x2-bits or 1600x1-bit, which would be of little use to games but very useful for highres computer graphics. (more situations where lines could be double-buffered for efficiency/flexibility and potential line doubling, plus even more necessary if the Panther lacked the ability to chain line buffer reads, limiting screen width to a single line buffer's length)

Using the ST Blitter would also be fastest on 1-bit bitmaps, so a highres framebuffer mode or drawing to multiple 1-bit object windows. (even more useful assuming the Panther can do opaque 2-color 1-bit bitmaps like the 7800 Kangaroo mode: rectangles without sprite transparency)
 

Also worth noting: the Panther development board also uses the same 32.2159 MHz oscillator frequency as the NTSC STe uses. (good for monitor compatibility and system clock compatibility, not so good if games actually used the same 8.05 MHz dot clock due to the large border and NTSC color artifact issues, though 32.2/5 = 6.44 MHz would be much better and also have nearly square pixels)

 

Presumably, in the ST, the Panther would be using the same 32kB of fast 32-bit SRAM (35 ns chips used on the dev boards, but being used at 31 ns) and could exploit ST RAM like 500 ns 16-bit ROM using the existing SHIFTER DMA cycles, except able to use an entire H-time worth of bandwidth (or multiple H periods) aside from the DMA sound access slots. (disabling interleaved DMA for 250 ns saturated/cycle stealing access would allow higher bandwidth at the expense of CPU performance, unless you also used a 12 or 16 MHz 68000 and give the CPU access to all bus cycles as well for serial use of the full bus bandwidth; better still if the Blitter and DMA chip could use both even and odd bus cycles as well)

 

Though aside from that, some 16-bit wide 120 ns SRAM used as dedicated object data/framebuffer memory could allow neat high bandwidth modes (and potentially CPU interleaved 250 ns modes too) and 256 kB of SRAM on an upper-scale model would allow single-buffered 1600x1200x1bpp 60 Hz or double-buffered 800x600x2bpp 60 Hz (and potentially 50/50 bus interleaved with the CPU/DMA chips). Which would be nice monochrome/grayscale workstation class resolutions in 1989/1990, sort of like a low-cost competitor to NeXT, especially if they included a 56k DSP option. (which has implications for both audio work and 3D graphics)

 

I don't have time right now to go through all of this but Atari Corp bought Styra Semiconductor. If I recall, they renamed it "Atari Dallas" or something to that effect...