Atari Panther and the controversy of the bits of your processor

[Lostdragon]

23 hours ago, leech said:

Pretty sure you know more about video games and consoles, specifically of ones that were canceled, than anyone else on the planet.  We may need to figure out how to dump your brain for preservation.

Your far too kind, but thank you for the kind words. 

 

My knowledge is extremely limited when compared to the real heroes out there who've done so much to investigate lost games in a professional and credible fashion. 

 

The likes of Luca at Unseen64 and in particular Frank Gasking of GTW, have knowledge that dwarfs mine. 

 

I've always just felt extremely humbled to be able to assist their sites and books in some small fashion and Frank was the one who taught me how to research claims properly, something for which I am extremely grateful to him for. 

 

 

I just tried to tie up a few loose ends, help as and when i could. 

 

I just loathe people deliberately putting out false information, it helps nobody and just makes them look stupid, why do it?. 

 

I did, admittedlly, take a personal interest in the Panther.. 

 

😂 As for the matter concerning my brain, get in line, my beloved, Samantha, keeps telling me she would love to get inside my head. 

 

She both admires and loathes in equal measures, the geek that remains inside me. 

[leech]

1 hour ago, Lostdragon said:

😂 As for the matter concerning my brain, get in line, my beloved, Samantha, keeps telling me she would love to get inside my head. 

 

She both admires and loathes in equal measures, the geek that remains inside me. 

Hmmm... delicious brains....

[jhd]

On 6/20/2023 at 4:17 PM, leech said:

We may need to figure out how to dump your brain for preservation.

 

At least in the United States, there are companies that will, for an exorbitant fee, cryogenically preserve one's head until the technology develops sufficiently to manufacture a new body. 

 

This opportunity practically demands a Go Fund Me page! 

[leech]

2 hours ago, jhd said:

 

At least in the United States, there are companies that will, for an exorbitant fee, cryogenically preserve one's head until the technology develops sufficiently to manufacture a new body. 

 

This opportunity practically demands a Go Fund Me page! 

Ha, that was probably one of the most annoying Star Trek: The Next Generation episodes... Yet somehow, Space Seed with the same premise brought us Khan!
Though one was freeze them as we can't cure their stuff, and the other was freeze them because they're escaping into space.  Then you have Futurama...

[zzip]

We went from Atari Panther to talking about cutting off peoples heads?    one of the oddest derails 

[leech]

1 hour ago, zzip said:

We went from Atari Panther to talking about cutting off peoples heads?    one of the oddest derails 

Atari Hydra?  Cut off one head, another grows in it's place?

[Wayler]

1 hour ago, zzip said:

We went from Atari Panther to talking about cutting off peoples heads?    one of the oddest derails 

On the contrary, it's only natural to talk about bits and pieces. 

[fiddlepaddle]

Technically, he was talking about cutting off peoples bodies.

[+KaeruYojimbo]

11 hours ago, leech said:

Though one was freeze them as we can't cure their stuff, and the other was freeze them because they're escaping into space.  Then you have Futurama...

Don't forget Mr. Burns

 

 

[zzip]

21 hours ago, Wayler said:

On the contrary, it's only natural to talk about bits and pieces. 

Good point,  now I finally understand what a 'hacker' really does 😲

 

14 hours ago, fiddlepaddle said:

Technically, he was talking about cutting off peoples bodies.

Ah, I feel much better now 

[kool kitty89]

On 6/15/2023 at 1:35 PM, Ricardo Cividanes da Silva said:

Hi guys.

 

I am researching the story of the Atari Panther for the book I am writing and a question has intrigued me.
I found it a lot of material about this not released console and everyone says the Panther would be a 32 bits video game.
OK.
But, the problem is that the specification provided by Atari says that the Panther would use a Motorola 68000 processor, equal to the Mega Drive/Genesis, Neo Geo among others. And we know that, although internally the 68K has 32 bits registers it is, in essence, a 16 bits processor.
So is this one of those Atari tactics to use a processor and get as many as possible? Just as she did with the Jaguar when she added two 32 bits processors and said it was 64 bits?

 

Does anyone know something that really indicates that Atari Panther would be a 32 bits video game?

It was a 32-bit computer or system with a 16-bit CPU per Atari's own documents sent to developers.

This was due to the 32-bit wide bus and 32-bit instructions/commands/lists read by the Object Processor which performed operations at 32-bits ... or at least SOME operations at 32-bits. (it reads data 32 bits at a time from RAM or 16-bits at a time from ROM and writes 1 pixel at a time to a line buffer, logically 8-bits wide, but physically 5-bits wide: the line buffers are on an external chip but the Panther Object Processor itself has 8 data lines for pixel output, only 5 are used, presumably due to cost concerns)

Likewise, the Jaguar was a 64-bit system due to its graphics architecture. The blitter and object processor work on a 64-bit bus doing most operations 64-bits wide and the object reading lists of 64-bit wide words or "phrases" in Flare II terminology.

Sam Tramiel was out of touch and didn't understand the 64-bit aspect of the Jaguar. The fact that it has 2 32-bit RISC chips in it is irrelevant. It would be just as much a 64-bit system if it had just the 32-bit GPU (the RISC processor inside TOM is called the GPU, but it's not one of the 2 64-bit graphics processing chips in TOM, those are the blitter and object processor) or even if it had NO 32-bit processor in it at all. It's 64-bit in the same context that (relatively) high-end PC video processor chips were with 64-bit DRAM or VRAM busses and 64-bit wide GUI accelerators. (ones that used 64-bit busses but blitters that were limited to 32 or 16-bit operations wouldn't be "as 64-bit" as the jaguar)

The Jaguar was actually planned to use a 128-bit bus at one point using bank interleaving to have double the throughput of the existing system (Do 128 bits on 64-pins as I think Martin Brennan put it), but they cut it back to just 64-bits to save cost and time.

Interestingly, in this context, the PC Engine or TG-16 should be a 16-bit system (or at least I'm pretty sure it uses a 16-bit wide graphics bus, using a pair of 8-bit wide SRAM chips) and the SNES likewise, but the Mega Drive is actually 8-bits as far as its video bus goes. (it uses two 64kx4-bit VRAM chips, that's dual port DRAM, for its 64kx8-bit video connection, though technically it has 2 8-bit data ports it can use in parallel, one the fast serial port for clocking out pixel data, the other a general purpose port for reading/writing 8-bit data words)
However, the MD's VDP itself works on 16-bit words of data read through an 8-bit bus, so it's pretty well a 16 bit graphics processor, it also has provisions for an additional 64kx8-bit VRAM bank and actually doubles its bandwidth for some processes (especially DMA copy from external memory). This was only used in arcade versions of the VDP, normally along with an external palette DAC chip tuat used the full 4096 color 12-bit RGB format supported and 8 subpalettes rather than 4 (that's 8 sets of 15 colors + the background color vs the 4 sets of the Mega Drive using 9-bit RGB or 512 colors).

Likewise, the 3D0 chipset would still be 32-bit even if you used a 68000 or 8086 or something else as the host CPU. And oddly enough, the Sega Saturn would actually be 16-bit as far as the Polygon/sprite processor goes as it works on a 16-bit bus processing up to 16-bit pixel data (though supports 8 or 16-bit data in the framebuffer and 8, 16, or palettized 4-bit source data in texture RAM). VDP2 (the 2D background processor) works on a 32-bit bus, though. The N64 has an actual 64-bit CPU (albeit with its 64-bit addressing modes mostly useless) on an 8-bit wide (tehnically 9-bit with pairity) 500 MHz RDRAM bus, so at peak bandwidth it supplies 64-bits to the 62.5 MHz RSP graphics chip at 64 bits per 62.5 MHz clock cycle (ignoring latency issues and bus contention with the CPU ... not entirely unlike the Jaguar but with vastly more CPU grunt to power through the bottleneck ... a CPU with decent sized on-chip cache, too; the Playstation 2's architecture is somewhat similar to this as well)

 

Let me dig up the development documents that reference it being 32-bits.

It's from the PANHW.doc file written/maintained by Leonard Tramiel.

At the top of page 2 it reads:
"

  The Panther computer is a 32 bit system even though the CPU is a sixteen bit 68000. The computer owes its graphic performance to the bandwidth of the 32 bit static RAM which is cycled at 8MHz. ROM is 16 bits wide and is cycled at 4MHz. The computer is viable with as little as 32kbytes of RAM because it is not encumbered with a static frame store (it would need 64k to hold a 320 x 200 pixel image). The image data for most images will be held in cartridge ROM. The system can accommodate up to 6M bytes of cartridge ROM.

"

 

PANHW.DOC

[Ricardo Cividanes da Silva]

21 minutes ago, kool kitty89 said:

Era um computador ou sistema de 32 bits com uma CPU de 16 bits de acordo com os próprios documentos da Atari enviados aos desenvolvedores.

Isso ocorreu devido ao barramento de largura de 32 bits e às instruções/comandos/listas de 32 bits lidos pelo processador de objetos que executava operações em 32 bits... ou pelo menos ALGUMAS operações em 32 bits. (lê dados 32 bits por vez da RAM ou 16 bits por vez da ROM e grava 1 pixel por vez em um buffer de linha, logicamente com 8 bits de largura, mas fisicamente com 5 bits de largura: os buffers de linha estão ativados um chip externo, mas o próprio Panther Object Processor tem 8 linhas de dados para saída de pixel, apenas 5 são usadas, presumivelmente devido a questões de custo)

Da mesma forma, o Jaguar era um sistema de 64 bits devido à sua arquitetura gráfica. O blitter e o processador de objetos funcionam em um barramento de 64 bits, fazendo a maioria das operações com largura de 64 bits e o objeto lendo listas de palavras ou "frases" de 64 bits na terminologia Flare II.

Sam Tramiel estava fora de alcance e não entendia o aspecto de 64 bits do Jaguar. O fato de ter 2 chips RISC de 32 bits é irrelevante. Seria igualmente um sistema de 64 bits se tivesse apenas a GPU de 32 bits (o processador RISC dentro do TOM é chamado de GPU, mas não é um dos 2 chips de processamento gráfico de 64 bits do TOM, esses são os blitter e processador de objeto) ou mesmo se NÃO tivesse nenhum processador de 32 bits. É de 64 bits no mesmo contexto que os chips de processador de vídeo de PC (relativamente) de ponta estavam com barramentos DRAM ou VRAM de 64 bits e aceleradores GUI de largura de 64 bits. (aqueles que usavam barramentos de 64 bits, mas blitters limitados a operações de 32 ou 16 bits não seriam "tão 64 bits" quanto o jaguar)

O Jaguar foi realmente planejado para usar um barramento de 128 bits em um ponto usando intercalação de banco para ter o dobro da taxa de transferência do sistema existente (faça 128 bits em 64 pinos, como acho que Martin Brennan colocou), mas eles reduziram para apenas 64 bits para economizar custos e tempo.

Curiosamente, neste contexto, o PC Engine ou TG-16 deve ser um sistema de 16 bits (ou pelo menos tenho certeza de que usa um barramento gráfico de 16 bits, usando um par de chips SRAM de 8 bits) e o SNES da mesma forma, mas o Mega Drive é na verdade 8 bits no que diz respeito ao seu barramento de vídeo. (ele usa dois chips VRAM de 64kx4 bits, DRAM de porta dupla, para sua conexão de vídeo de 64kx8 bits, embora tecnicamente tenha 2 portas de dados de 8 bits que podem ser usadas em paralelo, uma porta serial rápida para registrar dados de pixel, a outra uma porta de uso geral para leitura/gravação de palavras de dados de 8 bits)
No entanto, o próprio VDP do MD funciona com palavras de dados de 16 bits lidas por meio de um barramento de 8 bits; alguns processos (especialmente cópia DMA da memória externa). Isso foi usado apenas em versões arcade do VDP, normalmente junto com uma paleta externa chip DAC tuat usado o formato RGB de 12 bits de 4096 cores suportado e 8 subpaletas em vez de 4 (são 8 conjuntos de 15 cores + a cor de fundo vs a 4 conjuntos do Mega Drive usando RGB de 9 bits ou 512 cores).

Da mesma forma, o chipset 3D0 ainda seria de 32 bits, mesmo se você usasse um 68000 ou 8086 ou qualquer outro como a CPU do host. E, curiosamente, o Sega Saturn seria na verdade 16 bits no que diz respeito ao processador Polygon/sprite, pois funciona em um barramento de 16 bits processando até dados de pixel de 16 bits (embora suporte dados de 8 ou 16 bits no framebuffer e dados de origem de 8, 16 ou paletizados de 4 bits na RAM de textura). No entanto, o VDP2 (o processador de segundo plano 2D) funciona em um barramento de 32 bits. O N64 tem uma CPU real de 64 bits (embora com seus modos de endereçamento de 64 bits praticamente inúteis) em um barramento RDRAM de 500 MHz de largura de 8 bits (tecnicamente 9 bits com paridade), portanto, no pico da largura de banda, ele fornece 64 bits para o chip gráfico RSP de 62,5 MHz a 64 bits por ciclo de clock de 62,5 MHz (ignorando problemas de latência e contenção de barramento com a CPU... cache on-chip dimensionado também; a arquitetura do Playstation 2 é um pouco semelhante a isso também)

 

Deixe-me desenterrar os documentos de desenvolvimento que fazem referência a 32 bits.

É do arquivo PANHW.doc escrito/mantido por Leonard Tramiel.

No topo da página 2 lê-se:
"

O computador Panther é um sistema de 32 bits, embora a CPU seja um 68000 de dezesseis bits. O computador deve seu desempenho gráfico à largura de banda da RAM estática de 32 bits, que é alternada a 8MHz. A ROM tem 16 bits de largura e é ciclada a 4MHz. O computador é viável com apenas 32 kbytes de RAM porque não está sobrecarregado com um armazenamento de quadro estático (seria necessário 64 k para armazenar uma imagem de 320 x 200 pixels). Os dados de imagem para a maioria das imagens serão mantidos no cartucho ROM. O sistema pode acomodar até 6M bytes de cartucho ROM.

"

 

PANHW.DOC 22,55 kB · 0 downloads

Brother, very grateful for your clarifications.
It helped me a lot!

[kool kitty89]

On 6/16/2023 at 12:30 PM, Lostdragon said:

The hardware seemed to divide opinion on those who worked on it.. 

 

 

Jeff Minter stating in a 2003 interview that the Panther hardware was superior to the Mega Drive and SNES..

 

But it's graphics implementation would later be described by Atari Corp. developer D. Scott Williamson as “lame” and a “big mistake” - particularly in comparison to the Lynx - due to it being a “display list platform with just a single scan line video buffer more like a 400/800/7800”

 

 

Jeff Minter has also said  on Twitter that while the chip had sprite scaling capabilities, it didn’t support hardware rotation, a feature which was found in the SNES.

 

He also mentioned running into issues with screen tearing when trying to display too many sprites on screen, a sentiment echoed asby  Rob Nicholson of Hand Made Software which he attributed to the same outdated “display list” design.

 

Joel Seider, senior programmer at Atari Corp at the time, told me the folliwing:

 

“I recall the hardware capability being average, but probably not anywhere near good enough to make a splash. The Super Famicom had already been released in Asia and my recollection was that the Panther hardware was really not that much better. At the time, there were also a lot of rumors of 3D hardware coming out in a few years from a number of different companies (including Atari).”

 

 

The Object list processor architecture of the panther was indeed inspired by the 7800 and allowed similar flexibility. It's a powerful "all sprite" sort of system and would be best compared to the Neo Geo with the exception that that used relatively conventional (by the late 80s) tiled graphics to build the sprites where the Panther (and Jaguar) used arbitrary bitmap sized "windows" for its objects.

All of these system suffer from screen tearing or "drop out" as all sprite based system do when you exceed the per-line bandwidth. That's the nature of the beast. Sega and the Ex-Atari/Ex-Amiga/Lynx developers and Sega both took this sort of sprite engine and replaced the line buffer with a frame buffer in the 3DO and Saturn (VDP1) which is also why you have the funky forward texture mapping quad rendering rather than typical rasterization.

 

Remember the Amiga is display list based, and like the Atari 8-bit computers, can display sprites AND framebuffer graphics. (the 8-bit can also display character map graphics) Where the Famicom/NES and pretty much all mid/late 80s and early 90s video game consoles other than the 7800 used character or "tile" based cell organized graphics exclusively, no framebuffer and not the flexibility of a display list. (arcade games largely used this as well, though some moved towards framebuffer graphics, namely 3D stuff, and I think some stuck with older style display list graphics ... Atari Games may have used this in their 68k based arcade machines, but I'm not sure).

 

The 7800, Panther, and Jaguar all had the POTENTIAL for using framebuffers as well as sprites. Ie a single large object could be used as a framebuffer or you could have multiple playfield framebuffers like the Amiga, up until you hit the bandwidth limit. (some 7800 games used extra RAM on cart to achieve this, most notably Summer and Winter games, and I think some homebrew projects work on it, too)

The fact they were only planning to use 32kB of SRAM would've limited this a great deal, and while reasonably conservative for 1988/89 early in the Panther's development, by 1991 that should've easily been expanded from the 4 8kx8-bit chips to 4 32kx8-bit chips for 128kB 32-bits wide at low cost using cheap 120 ns SRAMs.

That said, the bigger practical limitation would've been color count as it used only 5-bit wide line buffers hence 32 colors per scanline and why 8-bit per pixel objects map to 32 colors rather than 256. In all the prototypes (and the existing production panther schematics) the line buffers are on an external chip which also holds the palette data (32 entries 18-bits wide, using 6-6-6 RGB just like VGA). The panther Object Processor itself outputs 8-bit wide data, but programmers were directed to ignore the unused 3-bits since the line buffers are only 5-bits wide. This external implementation COULD have meant that Atari could've implemented a new fully 8-bit wide line buffer chip with 256 palette entries (or anything in between, 6 bits with 64 entries, 7 bits with 128 entries) while remaining backwards compatible with all existing 32 color game development. There's no indication they actually did that by 1991, but they easily could have. They also could've used an external RAMDAC/CLUT chip and offloaded the palette entries to that (a standard VGA RAMDAC would work, as would the


But according to Leonard Tramiel, they dropped the panther in 1991 because the chips came back non-functional. His memory may be sketchy here as they obviously had working (though buggy) development hardware during 1990 and the one big bug documented (the loadpalette object type doesn't work properly and generally has to be avoided) which implies real silicon and not just emulation software. So I'm not sure what's going on there or what he might be misremembering. It's possible they did a new revision of the chip for early 1991 to try to fix the bug(s) and it came back to them not working at all or so broken as to basically be nonfunctional. (though presumably they could still have just used the buggy but at least functional earlier revision, so I really don't know)
That or it only worked when in PAL mode as the developers who commented on having working dev systems were all in the UK. It would be worth getting info from Atari UK management or technical employees from this period to get their perspective.

Being broken in NTSC would obviously be a huge problem though, but could've meant doing a UK/PAL specific early launch or test market, something they failed to do for the Jaguar. (a shame given they had stronger brand recognition in the UK and more or even most of their viable developer talent would've been in the UK, especially given Atari's budget constraints for anything done in house, but also generally because you saw a much higher percentage of developers making the most of weird/quirky/limited hardware in the UK, that is relative to their population or the number of studios, plus they'd been less impacted by Nentendo's influence preventing 3rd party publishing on non-Nintendo platforms)

Leonard also said the Panther came out of the restriction of having a DRAM-less console, but again using SRAM (or PSRAM, or a mix of both) by 1991 shouldn't have limited them to 32kB as such even with 32-bit bus width requirement and even if trying to hit a price point close to $100. (not sure on the price point, but I assume they wanted something CHEAP like the 7800's $79.95 price tag in 1986) Plus the DRAM-less model was no longer critical in 1991 as DRAM prices had dropped through the floor, but the Panther would've needed some rework to use DRAM as such and not be ready as-is. OTOH they could've actually populated the OTIS sound chip with the DRAM chips it was designed for and had a very impressive sound system for 1991 or even 1994 depending how much DRAM they put in (say 128kB as a reasonable number and as the smallest 16-bit wide chips available in 1991). The Panther dev systems had OTIS on a board with just 8kB of RAM, so I'm not sure how they planned to make use of it, unless it was to also have onboard ROM to use as a sound font (in that case more like a high-end sample based MIDI system with a fixed sample set). Without sample ROM and just 8kB of SRAM you'd be limited to doing fancy wavetable synthesis and additive synthesis from tiny samples in RAM composited together using the many oscillators of the OTIS, or use sample based synthesis with very short waveform samples + envelopes and effects more like the PC Engine's sound chip or Konami SCC chip on the MSX except not quite that short and using 16-bit resolution rather than 5-bit. (the SCC and PC Engine use wave RAM entries of 32x5 bits; 8kB of SRAM could be used to hold 64 entries of each 64x16-bits long as one possible configuration) That would be OK if Atari had a really really good deal on the chips, such that they were cheaper than Yamaha's FM chips, plus you could play sampled sound effects by having the 68k copy into a small reserved sample buffer area of the SRAM.

And all that said, if they'd released the Panther as-is (assuming they had working chips of SOME kind) during mid 1991, it would've been a bit dated but at the same time still capable. The scaling effect would be its main obvious feature to use and it could be done very flexibly (where the SNES can only scale/rotate its mode 7 background, which also requires all other backgrounds to be disabled and uses up half of the video RAM leaving 32kB for sprites). It would be capable of good ports of Sega's scaling arcade games and some Neo Geo fighting games (think of 2D stuff on the Sega 32x, but 3-4 years earlier), but this would all require programming talent and 3rd party interest. Granted, this was after Nintendo America had gone to court over its anti-competitive practices so 3rd parties were a good deal more free to publish. (Apparently Atari won the anti-trust suit against Nintendo, but due to weird phrasing in the final jury forms, ended up not getting awarded compensation)

The panther was good enough to be SOMETHING in the 1991-1993 timeframe so long as it was cheap enough to remain in the same price range or just below the competition, i would've kept Atari in the game and given them cash flow and working relationships with dealers and developers alike. Plus they could get consumer and developer feedback on the Panther/Falcon gamepads and need for more face buttons for fighting games or such. (the keypad would've been good if they got ports of computer games using more functions like that)

If it didn't function at all, they should've just licensed Flare's Slipstream technology from the Konix Multisystem (which had a non-exclusive license and even then only for the UK). Also dated by 1991 but ready for mass production at the beginning of 1990 so Atari could've even chose to cancel the Panther sooner (or keep developing it as a more advanced future project) and released a cartridge based version of the Slipstream system in 1990 with the list of UK developers already making games for the Multisystem, the transition should've been fairly straightforward, though using ROM instead of just 128kB of PSRAM + floppy disk would've made things a bit more flexible. (they could've potentially offered a RAM+disk drive expansion module too, or moved on to CD-ROM like Sega did with its Mega Drive floppy plans)  The Slipstream chipset and its ready-to-license nature should've been a talking point with Martin Brennan to Atari as soon as he was brought onboard to work on the Panther in 1989. Hell, they could've started work on a quick and dirty conversion from the 8086 based version to a 68000 (and possibly 12 MHz rather than 6) though a 6 Mhz 8086 version would at least have been cheap to implement and arguably faster than the SNES's CPU, though you'd also need bank switching to access more than the 248 kB alloted ROM space where the 68000 would have full 24-bit address space and could use the existing 16-bit wide Panther cartridge design. (they could re-use the Panther case design and gamepads, too)



See recent Leonard Tramiel interview where he touches on the Panther:

 

[Lostdragon]

@kool kitty89

 

I did have a brief chat with Bob Katz from Atari UK at the time I was conducting research into the Panther, I haven't included him on my list of sources, as his memory was extremely sketchy regarding it. 

 

Bob Gleadow was a figure i always wanted to speak with, but couldn't find him, in fact i have never seen him interviewed anywhere since he left the industry. 

 

Jim Gregory has proven to be a rather unreliable source shall we  say, on various matters, so I am not sure how great his testimony regarding he Panther is. 

 

One individual attempted to claim the account Chuck Ernst gave Frank Gasking, when researching his GTW book, was incorrect, Chuck must of been talking about 7800 development kits, Frank had Chuck confirm it was indeed the Panther he was talking about. 

 

 

The dev kit he was given, was essentially a 7800 with a couple K more of  Ram and a slightly faster CPU. 

 

 

I would of liked to of had some insights from the folk who were converting Shadow Of The Beast to the Panther, but  i had to work with the resources available to me at the time. 

 

Hazy memories are also a factor to be taken into consideration when doing any interviews, would of been a long time since they worked on Panther Projects. 

[kool kitty89]

@Lostdragon

One other possibility that might fit in with multiple sketchy memories was that some Panther object processor chips worked, but yields were extremely poor to the extent only a few development boards ever worked. They could've sent out the few working ones while hoping yields would improve (or fixes could be made), but it never happened. If those sorts of problems were ongoing throughout 1990, I could understand the sketchy memories of the time. It could have been something like: a few development systems end up working OK, they send those out, then continue with chronic problems of most examples not working in any useful sort of way. This would contrast with the first run of Jaguar prototypes with Tom version 1 onboard (that "taped out" in late 1991 came back in silicon in early 1992). Those TOM chips were had significantly worse bugs than the second revision used for production in '93, but they at least appear to have worked without significant yield problems. The production units also used 26.6 MHz vs 32 MHz (probably 32.215905 MHz) heavily implied/planned in the documentations, but it's not clear this was a yield issue or related to keeping costs down elsewhere, like avoiding use of heat sinks or better case ventilation, or the DRAM speed chosen, or ROM speed for that matter, especially since JERRY has a fixed bus cycle time of 6 clock ticks. (albeit in that case 30 MHz would have made more sense to be used with 200 ns 16-bit ROMs, which would mean JERRY could load sound data from ROM at its full speed)

It seems like Atari was having problems with their oversees manufacturing/assembly plants as well (I know there was the big one in Taiwan, not sure about others or if the Taiwan plant was the problem one), but per 1992/93 era Atari magazine articles I've come across, faulty quality control testing equipment contributed heavily to delays in the Falcon's release. In that case it was failing to pass perfectly good hardware (assuming the magazine articles are accurate) that would've otherwise allowed the Falcon to be released months earlier. So if they had problems like that, it could have contributed to problems trouble shooting other things. The articles also mentioned Atari had been soured on their overseas production facilities to the extent of abandoning them (or considering abandoning them), but I'm not sure of the full extent of all that. If they did shut down their big Taiwan plant, that probably would've significantly increased their assembly costs for the Jaguar ... it may have also driven their decision to source a Phillips chipset for the Jaguar CD-ROM drive rather than one of the Japanese ones, though they also opted to license the chipset rather than buy it off the shelf, which wa slikely costly given the small numbers the Jag CD units were produced it, or even the Jaguar itself (around 235,000, with about 150,000 sold by 1996 iirc). I know the Sega Mega CD used a Sanyo chipset in it rated for both 1x and 2x CD-ROM speeds, though Sega used it with just a 1x speed drive mechanism.
I forget whether this was from ST Format or ST User magazine, but they're both archived pretty comprehensively online.

From the pictures of Panther dev hardware I've seen, the Panther ASIC itself was manufactured by Toshiba in Japan. As I recall, there were even some versions of the Jaguar chips that are Toshiba marked, though many are Motorola marked. I think IBM made the actual motherboards for the Jaguar.


In any case, it doesn't explain the lack of apparent consideration of Flare's Slipstream ASIC as an alternate option, especially as the Konix Multisystem had more developers already working on it in 1989 than the Panther had in 1990. The Konix deal was pretty clearly a non-exclusive license and I don't think even covered any distribution outside of the UK, so Atari should've been free to adopt it or even have it reworked/expanded, though some changes wouldn't have required modifying the existing production-ready ASIC at all, like switching from floppy disk to ROM cart (potentially with provisions for a floppy drive expansion) and bank switching to expand the limited address space. It was definitely less powerful for producing 50/60 FPS 2D games than the Panther (let alone 50/60 FPS scaled sprites/objects) but would've been a lot less exotic to work on for most home computer game developers, even if they'd stuck with the 8086, and the 256 color framebuffer would be much simpler to make good use of color in than the Panther's 32 colors. (albeit that was a limitation of the line buffer + palette RAM and not the object processor itself, which already supported a 256 color palette and 1, 3, 15, or 255 color objects at 1, 2, 4, or 8 bits per pixel)
It would've been miles better in 3D than the Panther, though adding a sound chip other than the DSP to the system would've made that a lot more flexible ... also a lot less bottlenecked with a faster CPU. (with the way wait states are set up for bus sharing, it seems like you could just drop in a faster CPU and synthesize the appropriate clock input from the Slipstream's source clock, so long as the CPU is still slow enough to work with 0 wait states in PSRAM, since it doesn't look like the Slipstream ASIC adds any wait states for that outside of video DMA time or PSRAM refresh time ... which would mean with the 100 ns PSRAM used, with 160 ns cycle times, you could use: up to a 20 MHz 68000, 25 MHz 8086/186/NEC V30, 12.5 MHz 286 or 386SX or NEC V33, or 18.75 MHz 68020)

The NEC V33 would've been an interesting option as it's faster than a 286 internally for a number of things, but lacks 286 protected mode and accesses its 24-bit (16 MB) address space via LIM EMS 4.0 compatible bank switching (ie the standard EMS system a number of early/mid 90s  DOS games used, though others went for actual 386 specific memory mapping modes). It was basically a really fast 186/V30/286 Real mode compatible processor, but one incapable of being used with any protected mode applications or OSs (like windows 3.x), and the pinout wasn't 286 compatible for some reason, but it should've been cheaper to compete in its market niche. It also completely avoided Intel microcode related legal issues by not using microcode (all instructions are implemented in wired logic), though I don't think that was ever a big problem for obtaining NEC's V20 or V30 chips, no import restrictions of cease an desist orders, rather they kept selling them but ended up having to pay Intel royalties. (unlike UMC, who was barred from selling their enhanced 486 class U5S Green CPU in the US)

On a side note, it SHOULD have even been possible to incorporate the Slipstream into the Atari STe or TT at the time, though the latter would make less sense as it wasn't capable of VGA display modes (it would have to run about 2.1x as fast to be useful for 640x480 60 Hz VGA and use 80 ns SRAM rather than PSRAM, if it could actually be clocked that high with any sort of useful yield).
The trick would be enabling its external sync inputs and using the STe's sync and display enable outputs to drive the display parameters for 320x200 in 16 or 256 colors or 640x200 in 16 colors. However, doing so would disable its hardware scrolling functions, as it's limited to using addresses along 256 byte boundaries like the original ST SHIFTER (though also supports 16-bit word wise horizontal scrolling), so its scroll features only work at 256 or 512 pixel width modes. Still, it uses chunky pixels rather than bitplanes, so software scrolling is a lot easier than on the ST, but for best performance, you'd want to use the native 11.93 MHz clock and 256/512 pixel resolution (up to 512x256 50 Hz) for dedicated games or graphics software. But the point being it COULD still be made to work at standard ST resolutions and was capable of bit to pixel expansion for character painting (so could have used the existing TOS character/graphics set using 1-bit bitmap data).
It could've even been made to genlock as an overlay for STe SHIFTER video, but that would've required external analog video mixing circuitry to achieve and wouldn't have been the cheapest/minimalist option. (granted it would easily allow a 16 color STe background with 256 color Slipstream sprites and/or polygons, very much like the Sega 32x does for the Mega Drive)
Mind you, to match STe pixel clock ouputs, the Slipstream would need to run at 16.108 MHz rather than 11.93, but that seems at least realistically possible compared to VGA clock rates. That or the STe SHIFTER compatible overlay mode would be limited to just 320x200 16 colors and the Slipstream would be clocked down to just 8.05 MHz instead, with 256 color mode limited to 160x200 as such. (but support the full 256x240/256x256x8bpp 256 color mode in native 11.93 MHz cock rate ... 11.823 MHz for PAL)
Without bothering with genlock support, the Sipstream DSP and blitter could still be available when  only using STe SHIFTER graphics (though for bitplane graphics the blitter would mostly just be useful for block fill and block copy operations) and the PSRAM could be available as local CPU bus fast RAM for software supporting it. (a 16 MHz 68000 would easily work in it, though unlike the cache of the MEGA STe, you wouldn't have immediate acceleration of all software ... TOS could be patched to support fast RAM though and allocate it as such)

I've never seen interviews with the Flare team members or Atari staff addressing whether the Slipstream hardware was ever considered.

[Lostdragon]

From my (limited) research.. 

 

Atari  put the contract to Assemble, Q.A test,package and ship the Jaguar, out for bids.

 

IBM apparently came in with the lowest bid and had a production facility with spare capacity. 

 

Toshiba and Motorola were reported as being the only 2 companies that could fabricate the custom Tom and Jerry chips, in large numbers at that time.

 

Initial chip yields were as low as something like 40% and without these chips in high numbers, IBM couldn't assemble enough Jaguar units to met launch demands. 

 

 

Today's YT historians always seem to place the blame on machine shortages on IBM, yet the issue was beyond their control. 

[Lostdragon]

Regarding Falcon manufacturing issues.. 

 

The excuses from Atari at the time ran thick and fsst:

 

 

 

BOB-BRODIE:I'm sure that

you are all very interested in the status of the delivery schedule
for the Atari Falcon030 here in the US. We have had a small
setback in the manufacturing of the unit. One of our suppliers is
running about 10 days behind in providing us with a couple of
components that we need for the US machines. This means that the
machines will probably arrive in late March to early April.

The reception that we've had for the machines has been nothing
short of sensational!! The phone has been ringing constantly,
with many people interested in signing up as Atari dealers. As
you might expect, the main interest is coming from the music
field, as few other computer systems can match the digital sound
capabilities of the Atari Falcon030 right out of the box!! We
have enough orders in hand that we expect to be sold out quickly.
This is the same type of reception that the Falcon030 has gotten
in the rest of the world, for instance in Germany, where it was
literally sold out in a matter of hours!!!

Much of our efforts here in Sunnyvale over the course of the last
month has revolved around finalizing plans for dealer agreements.
It is our hope that we'll be able to restore the value of an Atari
dealership, and help the dealers be able to be more profitable.
We will be soon going over the new arrangements with all of our
current dealers, as we release the pricing, and other sales
related information to our current dealers.

 

 

BILL REHBOCK:the first units are honestly (to the latest knowledge that I
got from manufacturing literally minutes ago) are supposed to be on
their way. We did make the mistake of jumping the gun on release dates
in the time-honored tradition of the computer industry and are suffering
because of it now. Right now, I can only hope that we'll see these units
within the next week or so."

 

 

Going back to people at Atari UK, who might have had insights into the Panther.. 

 

 

How about.. 

 

Gary Lawman Atari Corp. (U.K.) Limited technical manager..

 

 

I have never seen an interview with him, anywhere. 
 

 

 

Edited July 5, 2023 by Lostdragon

[Ricardo Cividanes da Silva]

2 hours ago, kool kitty89 said:

@Lostdragon

One other possibility that might fit in with multiple sketchy memories was that some Panther object processor chips worked, but yields were extremely poor to the extent only a few development boards ever worked. They could've sent out the few working ones while hoping yields would improve (or fixes could be made), but it never happened. If those sorts of problems were ongoing throughout 1990, I could understand the sketchy memories of the time. It could have been something like: a few development systems end up working OK, they send those out, then continue with chronic problems of most examples not working in any useful sort of way. This would contrast with the first run of Jaguar prototypes with Tom version 1 onboard (that "taped out" in late 1991 came back in silicon in early 1992). Those TOM chips were had significantly worse bugs than the second revision used for production in '93, but they at least appear to have worked without significant yield problems. The production units also used 26.6 MHz vs 32 MHz (probably 32.215905 MHz) heavily implied/planned in the documentations, but it's not clear this was a yield issue or related to keeping costs down elsewhere, like avoiding use of heat sinks or better case ventilation, or the DRAM speed chosen, or ROM speed for that matter, especially since JERRY has a fixed bus cycle time of 6 clock ticks. (albeit in that case 30 MHz would have made more sense to be used with 200 ns 16-bit ROMs, which would mean JERRY could load sound data from ROM at its full speed)

It seems like Atari was having problems with their oversees manufacturing/assembly plants as well (I know there was the big one in Taiwan, not sure about others or if the Taiwan plant was the problem one), but per 1992/93 era Atari magazine articles I've come across, faulty quality control testing equipment contributed heavily to delays in the Falcon's release. In that case it was failing to pass perfectly good hardware (assuming the magazine articles are accurate) that would've otherwise allowed the Falcon to be released months earlier. So if they had problems like that, it could have contributed to problems trouble shooting other things. The articles also mentioned Atari had been soured on their overseas production facilities to the extent of abandoning them (or considering abandoning them), but I'm not sure of the full extent of all that. If they did shut down their big Taiwan plant, that probably would've significantly increased their assembly costs for the Jaguar ... it may have also driven their decision to source a Phillips chipset for the Jaguar CD-ROM drive rather than one of the Japanese ones, though they also opted to license the chipset rather than buy it off the shelf, which wa slikely costly given the small numbers the Jag CD units were produced it, or even the Jaguar itself (around 235,000, with about 150,000 sold by 1996 iirc). I know the Sega Mega CD used a Sanyo chipset in it rated for both 1x and 2x CD-ROM speeds, though Sega used it with just a 1x speed drive mechanism.
I forget whether this was from ST Format or ST User magazine, but they're both archived pretty comprehensively online.

From the pictures of Panther dev hardware I've seen, the Panther ASIC itself was manufactured by Toshiba in Japan. As I recall, there were even some versions of the Jaguar chips that are Toshiba marked, though many are Motorola marked. I think IBM made the actual motherboards for the Jaguar.


In any case, it doesn't explain the lack of apparent consideration of Flare's Slipstream ASIC as an alternate option, especially as the Konix Multisystem had more developers already working on it in 1989 than the Panther had in 1990. The Konix deal was pretty clearly a non-exclusive license and I don't think even covered any distribution outside of the UK, so Atari should've been free to adopt it or even have it reworked/expanded, though some changes wouldn't have required modifying the existing production-ready ASIC at all, like switching from floppy disk to ROM cart (potentially with provisions for a floppy drive expansion) and bank switching to expand the limited address space. It was definitely less powerful for producing 50/60 FPS 2D games than the Panther (let alone 50/60 FPS scaled sprites/objects) but would've been a lot less exotic to work on for most home computer game developers, even if they'd stuck with the 8086, and the 256 color framebuffer would be much simpler to make good use of color in than the Panther's 32 colors. (albeit that was a limitation of the line buffer + palette RAM and not the object processor itself, which already supported a 256 color palette and 1, 3, 15, or 255 color objects at 1, 2, 4, or 8 bits per pixel)
It would've been miles better in 3D than the Panther, though adding a sound chip other than the DSP to the system would've made that a lot more flexible ... also a lot less bottlenecked with a faster CPU. (with the way wait states are set up for bus sharing, it seems like you could just drop in a faster CPU and synthesize the appropriate clock input from the Slipstream's source clock, so long as the CPU is still slow enough to work with 0 wait states in PSRAM, since it doesn't look like the Slipstream ASIC adds any wait states for that outside of video DMA time or PSRAM refresh time ... which would mean with the 100 ns PSRAM used, with 160 ns cycle times, you could use: up to a 20 MHz 68000, 25 MHz 8086/186/NEC V30, 12.5 MHz 286 or 386SX or NEC V33, or 18.75 MHz 68020)

The NEC V33 would've been an interesting option as it's faster than a 286 internally for a number of things, but lacks 286 protected mode and accesses its 24-bit (16 MB) address space via LIM EMS 4.0 compatible bank switching (ie the standard EMS system a number of early/mid 90s  DOS games used, though others went for actual 386 specific memory mapping modes). It was basically a really fast 186/V30/286 Real mode compatible processor, but one incapable of being used with any protected mode applications or OSs (like windows 3.x), and the pinout wasn't 286 compatible for some reason, but it should've been cheaper to compete in its market niche. It also completely avoided Intel microcode related legal issues by not using microcode (all instructions are implemented in wired logic), though I don't think that was ever a big problem for obtaining NEC's V20 or V30 chips, no import restrictions of cease an desist orders, rather they kept selling them but ended up having to pay Intel royalties. (unlike UMC, who was barred from selling their enhanced 486 class U5S Green CPU in the US)

On a side note, it SHOULD have even been possible to incorporate the Slipstream into the Atari STe or TT at the time, though the latter would make less sense as it wasn't capable of VGA display modes (it would have to run about 2.1x as fast to be useful for 640x480 60 Hz VGA and use 80 ns SRAM rather than PSRAM, if it could actually be clocked that high with any sort of useful yield).
The trick would be enabling its external sync inputs and using the STe's sync and display enable outputs to drive the display parameters for 320x200 in 16 or 256 colors or 640x200 in 16 colors. However, doing so would disable its hardware scrolling functions, as it's limited to using addresses along 256 byte boundaries like the original ST SHIFTER (though also supports 16-bit word wise horizontal scrolling), so its scroll features only work at 256 or 512 pixel width modes. Still, it uses chunky pixels rather than bitplanes, so software scrolling is a lot easier than on the ST, but for best performance, you'd want to use the native 11.93 MHz clock and 256/512 pixel resolution (up to 512x256 50 Hz) for dedicated games or graphics software. But the point being it COULD still be made to work at standard ST resolutions and was capable of bit to pixel expansion for character painting (so could have used the existing TOS character/graphics set using 1-bit bitmap data).
It could've even been made to genlock as an overlay for STe SHIFTER video, but that would've required external analog video mixing circuitry to achieve and wouldn't have been the cheapest/minimalist option. (granted it would easily allow a 16 color STe background with 256 color Slipstream sprites and/or polygons, very much like the Sega 32x does for the Mega Drive)
Mind you, to match STe pixel clock ouputs, the Slipstream would need to run at 16.108 MHz rather than 11.93, but that seems at least realistically possible compared to VGA clock rates. That or the STe SHIFTER compatible overlay mode would be limited to just 320x200 16 colors and the Slipstream would be clocked down to just 8.05 MHz instead, with 256 color mode limited to 160x200 as such. (but support the full 256x240/256x256x8bpp 256 color mode in native 11.93 MHz cock rate ... 11.823 MHz for PAL)
Without bothering with genlock support, the Sipstream DSP and blitter could still be available when  only using STe SHIFTER graphics (though for bitplane graphics the blitter would mostly just be useful for block fill and block copy operations) and the PSRAM could be available as local CPU bus fast RAM for software supporting it. (a 16 MHz 68000 would easily work in it, though unlike the cache of the MEGA STe, you wouldn't have immediate acceleration of all software ... TOS could be patched to support fast RAM though and allocate it as such)

I've never seen interviews with the Flare team members or Atari staff addressing whether the Slipstream hardware was ever considered.

I found Panther's development, very strange. Why create a new graphic chipset when they could have used existing PCs or even created by Flare?
As far as I understand in the research, Atari decides to create something new and, possibly cheaper and, as regards Flare, decided to send everything to the Jaguar project, leaving the Panther in the background.

[Crazyace]

Existing PC's would be too expensive - Panther was super cheap ( like the 7800 ) and on paper had the sprite scaling features that would rival the NeoGeo. ( It was also much more powerful than the konix , although only 32 colours was a big limit compared to SNES/Megadrive/PC Engine )

 

 

[Lostdragon]

@kool kitty89

 

Sticking with the delayed Falcon release just for a moment, having already presented some of the claims from various individuals within Atari at the time, earlier in this thread... 

 

 

Whilst I can't at this time find the quote, I do remember one of the Tramiel family blaming the Q. A testing at the Taiwanese plants, might have been explained as faulty calibration on the equipment 🤔

 

 

There were also rumours Atari had delayed the Falcon to upgrade the graphics hardware, having gotten wind of the Commodore A1200 hardware specs, but i assume that was just pure speculation at the time?. 

 

 

As for closure of manufacturing plants in Taiwan.. 

 

 

Came across claims that after they had closed the Taiwanese plant, the government of Israel was pissed that Atari had backed out on their plans to build a new  manufacturing facility there. 

 

 

Reuter business newswire claimed that  Atari Corp was negotiating with Israel to establish a $150 million computer factory, with Israel being asked to supply $100 million in loan guarantees for Israeli component plants.

 

 

The concept behind this idea was that  if Atari assembled machines in

Israel using a sufficient level of Israeli-made components, the machines
could be shipped duty-free to the European Community.

 

 

No idea how credible the claims were  though. 

 

I did find a 1991  Wall Street Journal report, stating that Atari Corp was  selling its assembly plant in Taiwan for $60 million and would shift the work to subcontractors in Taiwan and
Hong Kong.

 

The article quotesd an unnamed Atari spokesman as saying that
the company lost $2 million in the first quarter because of problems in
assembling ``a newer product line'' at the Taiwan facility.

 

 

[Lostdragon]

@kool kitty89

 

Regarding Atari considering using the Slipstream hardware.. 

 

From what I have read on it, it seemed to offer 'superior' performance to the existing ST and Amiga technology.. 

more colours on screen, more sprites on screen,was  more flexible and the  general blitter solution allowed the game coders  a lot of flexibility 

 

 

 Was said to be  capable of holding its own against the PC Engine, Sega Mega Drive and SNES... 

 

I an interview with Sam Tramiel in 1991,talking about why Panther had been cancelled, he said:

 

 

"We decided not to go into a fight with a 16-bit machine that is just comparable with it's rivals. 

 

It would of been an OK machine, but we want to make WOW machines." 

 

Maybe the Slipstream hardware was viewed as another OK machine? 

 

Not far enough ahead of the abilities of the SNES and MD? 

 

 

[Lostdragon]

@kool kitty89

 

What do you make of Fred Gill (ATD) saying about the Konix polygon 3D abilities.. 

 

"I reckon you'd have gotten about 5fps with Starwing / Fox" 

[kool kitty89]

On 7/8/2023 at 10:48 AM, Lostdragon said:

@kool kitty89

 

What do you make of Fred Gill (ATD) saying about the Konix polygon 3D abilities.. 

 

"I reckon you'd have gotten about 5fps with Starwing / Fox" 

Crazyace addressed this at one point, I think even pointed to further elaboration on Gill's part, but in any case, 5 FPS would be severely underselling the capabilities with some caveats. With the 8088 based development systems, performance was well below the production 8086 version, partially due to the CPU bus width, but mostly due to the lack of a bus latch, which meant the CPU could only access the bus outside of video DMA (during hblank and vblank) rather than interleaving with it like the ST or Amiga. (and even then, the CPU actually only used half the free PSRAM access slots at 6 MHz; a 12 MHz 8086/V30/80186 or 68000 could have worked just as well on 4 t-state boundaries like the ST does at 8 MHz) A 68000 probably would've been the cheapest option for a CPU that handles programs written in C reasonably well, I think even the 286 requires a fair bit more assembly optimization by comparison, at least compared to its performance on paper. (If you're doing mostly 16 bit operations or less and optimize reasonably well for x86 segmentation, a 286 should be significantly faster than a 68000 at the same clock speed with 0ws in both cases or even with 1 ws on the 286; both have 2 clock tick access time requirements, but the 68k cycles the bus ever 4 ticks where the 286 does it in 2 as well with 0ws, and most instructions execute in 3 ticks on the 286 vs 4 on the 68000, some are only 2 clock ticks on the 286 and prefetch is filled in 2 tick bus cycles at 0ws; but that doesn't say much about compiled code performance or how much compiler optimization is needed for comparable performance ... plus PC programmers working in x86 assembly language would still probably have an easier time porting things to 68000 than the reverse situation)

If the context was for doing Star Fox as close as 1:1 as possible to the SNES, with the full 2D background layer (with pseudo-rotation via character column scrolling) and having the DSP do comparable interpolated + reverb effects on sample based music, the 5 FPS argument might be valid as well, or perhaps even without the reverb but still doing interpolation on 8 channels with 32 kHz sample rate. (you could do something that sounds close-ish with much less overhead, or even better sounding if you use larger, higher quality uncompressed samples, but the latter runs into a RAM space issue more than anything else) That and, while the 6 MHz 8086 would've been a bottleneck for some things, that's also part of the chipset that should've been easiest to change, including switching to a 68000 as Atari may have wanted to do (and probably use an Atari TT based development system like they did with the Panther: 256 colors from 12-bit RGB would cover general graphics there and 68k compatible CPU ... otherwise just use VGA PC based development systems like the Multisystem was using)

Working within 256 kB of RAM and purely from floppy disk would also be a constraint where ROM cartridges would allow more flexibility there even with the same 512kB limit as Star Fox used.

At some point in the Multi System presentation videos during polygon rendering analysis, there's mention of Starglider II running at 50 FPS as well. (I think that may have been guys from Argonaut commenting there, even, as they were developing for the system and rather excited about the potential for 3D)
It should've easily handled very nice/impressive versions of the Hard Drivin' based aracade games of the period, too. (Atari Games was an entirely separate company from Atari Corp, but there was still a vested interest in cross-licensing or publishing for Atari systems, and there were Atari Lynx versions of several of those games)

Beyond that, there's the issue of maxing out the DSP vs using it for sound processing, and using it for FM synthesis would eat a lot of its processing power, as would doing something akin to the SNES's sound system with streamed ADPCM samples that also get interpolation and reverb buffer mixing. Adding another sound chip would offload a lot of that, but even aside from that, you could do something much less DSP intensive, like Amiga MOD (or similar sample based tracker music) that just does 4 channel sound, possibly with extra channels for sound effects. Doing a DMA sound routine that minimizes DSP RAM use as well as processing time shouldn't hurt 3D processing too much, but adding a separate dedicated sound chip would help a lot. (a cheap OPLL YM2413 + DSP just slaved for simple PCM playback would make something close to PC Sound Blaster capabilities and probably with better sounding music than many VGA games if you had the talented UK/European chip tune composers handling the music) Atari had a deal going with Ensoniq at the time, which might have conflicted with interests in using Yamaha chips, but without a decent chunk of DRAM onboard, those Ensoniq chips aren't all that impressive and even with the DRAM, if using cartridge ROM, you still have to store the samples in there first and atari probably would've skimped on ROM sizes due to costs. (floppy disk would've avoided that issue to some extent, but made use of RAM tighter) But having an FM synth chip onboard allows much lower RAM or disk/ROM storage space use with still having the potential to use sampled sound on the DSP when desired while also being very much industry standard for home computers and arcade games at the time, not to mention synthesizer keyboards (the OPLL itself was used in low-end keyboards, too).

OTOH, if they used floppies and filled up the 512kB DRAM block on the Slipstream, you could buffer snippets of streaming audio there and loop it, either using one long looping track or segments you play in different order somewhat like single channel MOD/tracker music, or 2-channel MOD/tracker music (separating melody from percussion, for example) using more RAM than you would for typical sample tracker music, but a lot less than one long stream (or at much better quality than one long stream). Granted, for 2D games, you'd have all that RAM to potentially use for tiled animation to do well animated and/or pre-rendered parallax (do blitter block copy to quickly build the background and do multi-layer scrolling as fast as a simple non-animated single layer scrolling background) This would also work even better in 16 color lowres mode since you can copy 2x as much graphics data per word and use less video DMA time and framebuffer space.

With just 256kB of PSRAM and floppy disk media, you could compare the Slipstream to the PC Engine Super CD (with 256kB system card) and the same sort of dynamic tiling tricks for parallax layers would be relevant, with the exception that the Slipstream uses the DSP to handle floppy disk transfers where the PC Engine could stream CD-ROM data while playing chip synth music to dynamically update a cache/buffer of tile data in main RAM. Again, a separate sound chip would avoid this issue, allowing more flexible use of DSP multi-tasking (or task switching) while relying mostly on chip synth music and sound effects. (I think you could do sampled sfx and/or percussion easily enough by embedding a PWM sample playback loop in with a floppy disk DMA routine, so you could still do some samples on the DSP without needing a separate PCM chip of any sort)

512kB of DRAM would've made ports of most pre-1994 VGA DOS games relatively easy as well and DSP+blitter assisted rendering wouldn't just be good for polygonal 3D but scaled sprite/bitmap stuff like Lucasfilm's Secret Weapons of the Luftwaffe series or Wing Commander 1 and 2, or Wolfenstein 3D. Even with just 256kB a number of games should've been able to be reworked to fit within the limits, though ST/Amiga ports would be easier than PC games requiring significant hard drive installation on 3 or 4 or more floppies. Expanded RAM + floppy media would've offered potential for a lower budget multimedia rich experience, allowing cutscenes and/or voice acting only really seen on CD-ROM based systems, PCs, or some disk-swapping heavy Amiga games. More RAM = fewer loading sequences, and either less disk swapping or less need for redundant data on disks (frequently or globally used code and data just gets loaded with the main boot disk and stays in RAM).


On the 2D end of things, something like Jazz Jackrabbit would be a good example of what the system should be capable of in 256 color mode with sample based sound on the DSP. That game doesn't really do any parallax at all, just focusing on smooth scrolling of colorful backgrounds and well animated sprites, so it pretty well fits the bill of the Slipstream's strengths without using tricks like pre-rendered parallax. (the 3D/pseudo-3D bonus stages also should've been doable on the system)
RAM requirements would've honestly been the biggest factor there compared to what Jazz requires on the PC. In that last respect it's more in the Jaguar's sort of system requirements as far as an actual port of Jazz would go (the 1994 release date fits with the Jaguar timeline as well ... even if they'd foregone the 1993 test market and refined the hardware and built up a larger library before the release). For that matter, it's very much in line with what the Falcon should've been capable of.
Jazz's tracker music really isn't that intensive either and not something you needed a GUS or the Falcon's DSP for. A 386SX-33 or 40 could handle it at max sound settings without noticeable performance loss, though running at max graphics settings does take more of a hit. (the main difference is more priority layers for foreground vs sprites vs backgrounds from what I remember)

Also, like the Panther, the Slipstream would be most impressive in 2D when working with relatively large sprites as maxing out closer to (or ahead of) what the SNES or Mega Drive could do. OTOH with a blitter you can also do a lot of line drawing or pixel particle effects that you'd only have with the Panther if more RAM was used (software rendering to a framebuffer). The Panther could do scaled sprites way faster than any of the others, but the Slipstream's DSP and blitter would accelerate software rendered scaling+rotation or texture mapping more like what the Mega CD does in hardware, but in 256 colors like the SNES's Mode 7, and possibly even similarly fast to the Mega CD games that used that feature. (the Mega Drive VRAM DMA bottlenecked framerate a lot, even if the Mega CD Gate Array can render relatively fast ... I think it actually does scaling/rotation faster than the Jaguar blitter, but limited to rendering 16 color tiles loaded into a "stamp" cache for 8x8 or 16x16 textures and rendering them in Mega Drive tile format)
 

[kool kitty89]

On 7/7/2023 at 12:45 AM, Lostdragon said:

@kool kitty89

 

Regarding Atari considering using the Slipstream hardware.. 

 

From what I have read on it, it seemed to offer 'superior' performance to the existing ST and Amiga technology.. 

more colours on screen, more sprites on screen,was  more flexible and the  general blitter solution allowed the game coders  a lot of flexibility 

 

 

 Was said to be  capable of holding its own against the PC Engine, Sega Mega Drive and SNES... 

 

I an interview with Sam Tramiel in 1991,talking about why Panther had been cancelled, he said:

 

 

"We decided not to go into a fight with a 16-bit machine that is just comparable with it's rivals. 

 

It would of been an OK machine, but we want to make WOW machines." 

 

Maybe the Slipstream hardware was viewed as another OK machine? 

 

Not far enough ahead of the abilities of the SNES and MD? 

 

 

I've seen that quote before, I think in one of your posts, actually. I'd chock up a good chunk of that to Sam Tramiel speaking in PR or marketing terms and not being straightforward, and that's even assuming he understood enough about the hardware to make judgments for himself and not just repeat what he'd been briefed on. If we go by what Leonard has been saying the last couple years in interviews, the Panther chips themselves just didn't work, or taking that with a grain of salt based on a 30+ year old memory, at very least there were production problems bad enough for him to form that memory. Sam Tramiel's cancellation memo on the Panther in 1991 also specifies it was due to technical problems, though that's also phrased as "If anyone asks we cancelled it due to technical difficulties." And that could either be truthful or just the official word on what to tell software developers and/or the media. (except Sam contradicted the latter in his own interview)

Besides that, based on everything I've gathered on the Panther, it wasn't supposed to be a WOW machine, it was supposed to be cheap like the 7800, cheap enough to undercut the competition and fit into the budget market niche while also being "good enough" to compete on a similar playing field while at least having some potential for wow factor (the sprite scaling was its main impressive feature there). Now, unlike the 7800 it shouldn't have been as bogged down by Nintendo's anti-competitive business practices and 3rd party support should've been easier to get while also riding on the relationships with developers they'd built up for the 7800 and Atari ST and without the roughly 3 year gap in market share they suffered between 1991 and 1994.

Even if the Panther had been no more successful than the 7800 in the US, that was still a quite solid 2nd place to Nintendo in 1986-89 and sales up through 1990 were close to 2500% of what the Jaguar sold prior to its liquidation, or total US sales of the 7800 was around 3.7 million vs about 150,000 Jaguar units sold prior to liquidation.

Now assuming they needed time to fix the Panther ASIC to actually bring it to market, it might not have entered production until late 1991, perhaps not even a full international launch until some time in 1992. However, I'd argue if they increased the RAM to 128kB and increased the line buffers and palette to 8-bits and 256 colors, and still kept costs low enough to undercut the competition, I think it would've been decent. (switching to a cheaper sound chip might have helped meet that) 32kx8-bit SRAMs (and PSRAMs) have a very similar pinout to 8kx8-bit ones and the same pin count, so even modifications to the motherboard layout would be minimal (just 2 more address lines to RAM)

Aside from that, if they were willing to really put more R&D effort into improving the panther in a meaningful, but time-constrained way, Atari could've had the flare team focus on an integrated single-chip Panther that put the line buffers inside the chip (could still use an external VGA RAMDAC to save on chip space) while also fixing the bugs with the existing panther chip and adding support for PSRAM rather than just SRAM with sufficient time in hblank for refresh (you'd need about 4 refresh cycles per scanline or 520 ns for 80 ns PSRAM). To strictly comply with 80 ns PSRAM's 130 ns cycle time rating, a 30.77 MHz oscillator and 15.385 MHz Object Processor clock rate would be needed in place of the 32.2/16.1 MHz speed, but that's also close enough that 80 ns PSRAM should've tolerated the stress, but worst case would've been 15 MHz. Going a bit further would be switching to actual DRAM instead could allow for 256 kB via 2 64kx16-bit chips and all the available chips of that density also feature unusually fast RC times (random read/write cycle times, ie what you'd need for SRAM-like behavior and nothing fancy like page-mode burst access). The 80 ns 64kx16-bit chips available from Hitachi and Toshiba at the time should have worked with the 32.215905 MHz clock rate using similar RAS/CAS/Precharge timing as the ST MMU (just at 32 MHz rather than 16 MHz) or slightly fast RAS and RC times but precharge time within spec at 77.6 ns RAS and 46.56 ns precharge with RC time of 124.16 ns (vs ratings of 80 ns RAS, 45 ns RP, 135 ns RC), 32.0 MHz would stress that a little less, and 30 MHz would be fully within spec, including the 3 ns rise/fall time for signal pulses, though actual RC time would be very slightly less than 135 ns at 133.33 ns. (given the line buffer clock rate is independent of the object processor and CPU clock, they could also change the choice of CPU/OP clock without changing the screen resolution or pixel shape and have developers target the minimum possible clock rate for launch titles, then potentially have more headroom after that if a higher clock rate was achieved)

Flare should've been able to basically copy much of the ST DRAM controller logic block of the MMU, but allow the Panther to saturate the bus rather than interleave (like the ST SHIFTER does), but doing hidden refresh cycles on every CPU bus cycle, so in vblank you're getting constant refresh while in active display you just need enough time after Panther DMA to ensure a minimum number of refresh cycles. (worst case, this could be done in software, cautioning programmers not to allow the Panther OP to use 100% of scanline period for DMA)
Alternatively, if they removed the external sound chip entirely and added simple DMA sound integrated into the Panther ASIC, the minimum refresh cycles could be nested into fixed sound DMA slots synchronized with the scanline/H-sync timing. (albeit something much cooler would've been integrating the Slipstream DSP onto the Panther ASIC, and also should've been cheap compared to external sound chips, but less foolproof in terms of getting the thing out the door with working chips ASAP)

After looking through datasheets from 1989-1993, I also couldn't find any vendors offering 64kx16-bit PSRAMs or SRAMs (that's 128 kB 16 bits wide) and the only 16-bit wide options were the 32kx16-bit (64kB) chips from Sanyo and I think Hitachi and Sharp that Sega used on the later versions of the MD/Genesis. And those would work fine for replacing 4 32kx8-bit chips. So the only obvious low-cost 256kB 32-bit wide option is with 64kx16-bit DRAM chips available in Toshiba and Hitachi catalogs by at least 1991.


Now, on the other hand, the Slipstream would be better as a budget oriented console with its floppy disk drive and marketing oriented at the range of budget software titles made possible by that medium compared to carts. (the KMS itself was targeting 15 pounds per game in 1990) But unlike the KMS, could also aim at expanding that to include higher profile games at higher prices as was likely necessary for higher profile US (and potentially Japanese) developers and ports of PC games that required multiple floppy disks. Plus they could include a cartridge slot for combo cart+disk games for reduced load times and fast access to bulk storage needed for lots of animation (like arcade fighting games). You'd gain the potential for more flexible game design and easier/better ports of some computer games (incoluding graphic adventures and flight/vehicle sims not common or not commonly done well on consoles) to offer something different from other consoles and expand on the 7800 and Lynx's business model of attracting computer game publishers. That and offering the Atari ST Mouse as a sandard peripheral (probably using the 15 pin enhanced joystick connector of the STe/Falcon/Jaguar) would make point and click adventure games and  Catacomb3D/Wolf3D a lot easier to play, while analog flight sticks or wheels would be good for many sims. (the latter would be a point where Konix would've been good to get in on before they sold off their joystick division and started offering peripherals for Atari's console instead, inclouding the KMS modular controller itself ... which IMO made much more sense as a versatile peripheral multi-purpose controller than built into the console itself)

Plus with disks you gain the potential for very cheap or free releases of demo disks and shareware (the latter could use normal PC/Atari ST style FAT disk formatting so as to be easy to copy where full games could use proprietary formatting and encryption, plus better than 720 kB or potentially better than the 880 kB if you're willing to use bulk storage formatting for much of the disk closer to the theoretical maximum 960 kB ... the 512kB expansion would facilitate this as you could more easily load large blocks of data at a time).

For the slipstream base unit, Atari would either have to choose to sell hardware at a loss (or at cost) to keep the price point down, or rely on marketing that promoted the inexpensive game options. The ability to use a demo disk compilation instead of full pack-in games could also balance this out somewhat, since you don't have the trade-off of losing profits for a killer app used as a pack-in game, but can still show off demos of the more impressive games available right out of the box. (like if the Jaguar had been CD-ROM based and come with a pack-in demo disk compilation of the best 1994 releases, including a Shareware/Demo version of Doom ... the low cost media would've made ports of some of the other Doom Engine games rather straightforward too, possibly with some further optimization, probably Doom II and Heretic but perhaps not Hexen given the added RAM required, then again Carmak was attempting Quake on the Jaguar, so who knows ... and hell, as silly as it might sound, if Atari really couldn't get CD-ROM at a sane price point by 1994, a High Density floppy drive with potential for bulk formatting at  >1.86 MB might have made sense if it actually meant the system got more software, both budget stuff and higher profile stuff, and especially shareware demo releases of PC games; plus you even have the potential for rushed, buggy early releases and cheap or free upgrades to patched versions with proof of purchase) Floppy disks also make for cheap/easy game save functionality.

If the floppy drive unit was sold separately, they could fall back on Jack Tramiel's old business model with the VIC-20 and C64 where the base unit was sold cheap and the peripherals were sold at a profit. (in this case, the floppy drive could probably come with the maximum 512kB already onboard)

At very least if Atari went with something weird/different like disk based software, they'd be filling a market niche that no one else attempted and with potential for success in that end of things.

Granted, Atari COULD have done multiple of the above, like improving the Panther a bit to be more competitive for 1992 while still cheap, but include provisions for expansion with plans to use a further development of the slipstream chipset as part of a Floppy Disk or CD-ROM expansion module and the Jaguar itself to be the bigger, more complex full next gen console. (granted, if they aimed at backwards compatibility the Jaguar would've likely been somewhat different, at very least with different RAM configuration and Object processor ... though for the latter, they could've just extended the Panther's modes to include the 16-bit CRY color mode and page-mode DRAM reads at a bare minimum, probably with 16-bit RGB mode as well, but wouldn't need the 24-bit color mode or 32-bit wide line buffers ... though I'd argue a 16-bit 4444 RGBY color mode would be quite useful for allowing 12-bit RGB color with 16 shades mapped into 24-bit colorspace, for easy use of the existing 8-bit and 4-bit functional blocks on the blitter and most of the existing CRY to RGB conversion logic, but allowing for blitter based colored lighting and blending in 12-bit RGB with 4 bits of brightness/black level Y intensity and 16 linear shades for 3D lighting effects without the dithering or posterization you'd get with 15 or 16-bit RGB, just not as good as CRY itself allows: ie for games that only need fade-to black and use black distance fogging like Doom, Quake, or Tomb Raider, CRY is best, but if you need colored lighting or want colored or white fogging effects, RGBY would be better)

Technically speaking, given the existing 12-bit RGB format of the Slipstream but use of full 16-bit wide CRAM entries, extending that to 16-bit RGBY, adding a direct 16-bit color mode and 4-bit logical shading on the blitter would probably be one of the simpler upgrades to more impressive 3D. Allowing it to also work at 8bpp for 256 colors, provided the palette was organized as 4+4 bits (with 16 colors x 16 shades) the same logic could be used to provide shading in 256 color modes, just with those constraints on the palette. Or save CRAM space (and give it to the DSP as extra RAM) with only 16 CRAM entries used for 16 colors and the 16 shades provided in hardware mapping into the 16-bit RGBY color space.
Adding translucent blending would probably be a little more expensive, but adding a dither option (just rendering every other pixel as transparent) would be a cheap workaround useful for scaled bitmaps and polygons and a lot better than nothing, or having to use slow CPU rendering to do dither effects. (you also can't just use dithring at the texture/texel level since you'd get ugly scaling artifacts and corase dither meshes ... this option only works well for rendering unscaled sprites/objects and could already be done on the Slipstream of 1989 in the sprite rendering mode since you have per-pixel transparency by using the blitter's mask register to reserve one color value as transparent)

[Lostdragon]

6 hours ago, kool kitty89 said:

I've seen that quote before, I think in one of your posts, actually. I'd chock up a good chunk of that to Sam Tramiel speaking in PR or marketing terms and not being straightforward, and that's even assuming he understood enough about the hardware to make judgments for himself and not just repeat what he'd been briefed on. If we go by what Leonard has been saying the last couple years in interviews, the Panther chips themselves just didn't work, or taking that with a grain of salt based on a 30+ year old memory, at very least there were production problems bad enough for him to form that memory. Sam Tramiel's cancellation memo on the Panther in 1991 also specifies it was due to technical problems, though that's also phrased as "If anyone asks we cancelled it due to technical difficulties." And that could either be truthful or just the official word on what to tell software developers and/or the media. (except Sam contradicted the latter in his own interview)

Besides that, based on everything I've gathered on the Panther, it wasn't supposed to be a WOW machine, it was supposed to be cheap like the 7800, cheap enough to undercut the competition and fit into the budget market niche while also being "good enough" to compete on a similar playing field while at least having some potential for wow factor (the sprite scaling was its main impressive feature there). Now, unlike the 7800 it shouldn't have been as bogged down by Nintendo's anti-competitive business practices and 3rd party support should've been easier to get while also riding on the relationships with developers they'd built up for the 7800 and Atari ST and without the roughly 3 year gap in market share they suffered between 1991 and 1994.

Even if the Panther had been no more successful than the 7800 in the US, that was still a quite solid 2nd place to Nintendo in 1986-89 and sales up through 1990 were close to 2500% of what the Jaguar sold prior to its liquidation, or total US sales of the 7800 was around 3.7 million vs about 150,000 Jaguar units sold prior to liquidation.

Now assuming they needed time to fix the Panther ASIC to actually bring it to market, it might not have entered production until late 1991, perhaps not even a full international launch until some time in 1992. However, I'd argue if they increased the RAM to 128kB and increased the line buffers and palette to 8-bits and 256 colors, and still kept costs low enough to undercut the competition, I think it would've been decent. (switching to a cheaper sound chip might have helped meet that) 32kx8-bit SRAMs (and PSRAMs) have a very similar pinout to 8kx8-bit ones and the same pin count, so even modifications to the motherboard layout would be minimal (just 2 more address lines to RAM)

Aside from that, if they were willing to really put more R&D effort into improving the panther in a meaningful, but time-constrained way, Atari could've had the flare team focus on an integrated single-chip Panther that put the line buffers inside the chip (could still use an external VGA RAMDAC to save on chip space) while also fixing the bugs with the existing panther chip and adding support for PSRAM rather than just SRAM with sufficient time in hblank for refresh (you'd need about 4 refresh cycles per scanline or 520 ns for 80 ns PSRAM). To strictly comply with 80 ns PSRAM's 130 ns cycle time rating, a 30.77 MHz oscillator and 15.385 MHz Object Processor clock rate would be needed in place of the 32.2/16.1 MHz speed, but that's also close enough that 80 ns PSRAM should've tolerated the stress, but worst case would've been 15 MHz. Going a bit further would be switching to actual DRAM instead could allow for 256 kB via 2 64kx16-bit chips and all the available chips of that density also feature unusually fast RC times (random read/write cycle times, ie what you'd need for SRAM-like behavior and nothing fancy like page-mode burst access). The 80 ns 64kx16-bit chips available from Hitachi and Toshiba at the time should have worked with the 32.215905 MHz clock rate using similar RAS/CAS/Precharge timing as the ST MMU (just at 32 MHz rather than 16 MHz) or slightly fast RAS and RC times but precharge time within spec at 77.6 ns RAS and 46.56 ns precharge with RC time of 124.16 ns (vs ratings of 80 ns RAS, 45 ns RP, 135 ns RC), 32.0 MHz would stress that a little less, and 30 MHz would be fully within spec, including the 3 ns rise/fall time for signal pulses, though actual RC time would be very slightly less than 135 ns at 133.33 ns. (given the line buffer clock rate is independent of the object processor and CPU clock, they could also change the choice of CPU/OP clock without changing the screen resolution or pixel shape and have developers target the minimum possible clock rate for launch titles, then potentially have more headroom after that if a higher clock rate was achieved)

Flare should've been able to basically copy much of the ST DRAM controller logic block of the MMU, but allow the Panther to saturate the bus rather than interleave (like the ST SHIFTER does), but doing hidden refresh cycles on every CPU bus cycle, so in vblank you're getting constant refresh while in active display you just need enough time after Panther DMA to ensure a minimum number of refresh cycles. (worst case, this could be done in software, cautioning programmers not to allow the Panther OP to use 100% of scanline period for DMA)
Alternatively, if they removed the external sound chip entirely and added simple DMA sound integrated into the Panther ASIC, the minimum refresh cycles could be nested into fixed sound DMA slots synchronized with the scanline/H-sync timing. (albeit something much cooler would've been integrating the Slipstream DSP onto the Panther ASIC, and also should've been cheap compared to external sound chips, but less foolproof in terms of getting the thing out the door with working chips ASAP)

After looking through datasheets from 1989-1993, I also couldn't find any vendors offering 64kx16-bit PSRAMs or SRAMs (that's 128 kB 16 bits wide) and the only 16-bit wide options were the 32kx16-bit (64kB) chips from Sanyo and I think Hitachi and Sharp that Sega used on the later versions of the MD/Genesis. And those would work fine for replacing 4 32kx8-bit chips. So the only obvious low-cost 256kB 32-bit wide option is with 64kx16-bit DRAM chips available in Toshiba and Hitachi catalogs by at least 1991.


Now, on the other hand, the Slipstream would be better as a budget oriented console with its floppy disk drive and marketing oriented at the range of budget software titles made possible by that medium compared to carts. (the KMS itself was targeting 15 pounds per game in 1990) But unlike the KMS, could also aim at expanding that to include higher profile games at higher prices as was likely necessary for higher profile US (and potentially Japanese) developers and ports of PC games that required multiple floppy disks. Plus they could include a cartridge slot for combo cart+disk games for reduced load times and fast access to bulk storage needed for lots of animation (like arcade fighting games). You'd gain the potential for more flexible game design and easier/better ports of some computer games (incoluding graphic adventures and flight/vehicle sims not common or not commonly done well on consoles) to offer something different from other consoles and expand on the 7800 and Lynx's business model of attracting computer game publishers. That and offering the Atari ST Mouse as a sandard peripheral (probably using the 15 pin enhanced joystick connector of the STe/Falcon/Jaguar) would make point and click adventure games and  Catacomb3D/Wolf3D a lot easier to play, while analog flight sticks or wheels would be good for many sims. (the latter would be a point where Konix would've been good to get in on before they sold off their joystick division and started offering peripherals for Atari's console instead, inclouding the KMS modular controller itself ... which IMO made much more sense as a versatile peripheral multi-purpose controller than built into the console itself)

Plus with disks you gain the potential for very cheap or free releases of demo disks and shareware (the latter could use normal PC/Atari ST style FAT disk formatting so as to be easy to copy where full games could use proprietary formatting and encryption, plus better than 720 kB or potentially better than the 880 kB if you're willing to use bulk storage formatting for much of the disk closer to the theoretical maximum 960 kB ... the 512kB expansion would facilitate this as you could more easily load large blocks of data at a time).

For the slipstream base unit, Atari would either have to choose to sell hardware at a loss (or at cost) to keep the price point down, or rely on marketing that promoted the inexpensive game options. The ability to use a demo disk compilation instead of full pack-in games could also balance this out somewhat, since you don't have the trade-off of losing profits for a killer app used as a pack-in game, but can still show off demos of the more impressive games available right out of the box. (like if the Jaguar had been CD-ROM based and come with a pack-in demo disk compilation of the best 1994 releases, including a Shareware/Demo version of Doom ... the low cost media would've made ports of some of the other Doom Engine games rather straightforward too, possibly with some further optimization, probably Doom II and Heretic but perhaps not Hexen given the added RAM required, then again Carmak was attempting Quake on the Jaguar, so who knows ... and hell, as silly as it might sound, if Atari really couldn't get CD-ROM at a sane price point by 1994, a High Density floppy drive with potential for bulk formatting at  >1.86 MB might have made sense if it actually meant the system got more software, both budget stuff and higher profile stuff, and especially shareware demo releases of PC games; plus you even have the potential for rushed, buggy early releases and cheap or free upgrades to patched versions with proof of purchase) Floppy disks also make for cheap/easy game save functionality.

If the floppy drive unit was sold separately, they could fall back on Jack Tramiel's old business model with the VIC-20 and C64 where the base unit was sold cheap and the peripherals were sold at a profit. (in this case, the floppy drive could probably come with the maximum 512kB already onboard)

At very least if Atari went with something weird/different like disk based software, they'd be filling a market niche that no one else attempted and with potential for success in that end of things.

Granted, Atari COULD have done multiple of the above, like improving the Panther a bit to be more competitive for 1992 while still cheap, but include provisions for expansion with plans to use a further development of the slipstream chipset as part of a Floppy Disk or CD-ROM expansion module and the Jaguar itself to be the bigger, more complex full next gen console. (granted, if they aimed at backwards compatibility the Jaguar would've likely been somewhat different, at very least with different RAM configuration and Object processor ... though for the latter, they could've just extended the Panther's modes to include the 16-bit CRY color mode and page-mode DRAM reads at a bare minimum, probably with 16-bit RGB mode as well, but wouldn't need the 24-bit color mode or 32-bit wide line buffers ... though I'd argue a 16-bit 4444 RGBY color mode would be quite useful for allowing 12-bit RGB color with 16 shades mapped into 24-bit colorspace, for easy use of the existing 8-bit and 4-bit functional blocks on the blitter and most of the existing CRY to RGB conversion logic, but allowing for blitter based colored lighting and blending in 12-bit RGB with 4 bits of brightness/black level Y intensity and 16 linear shades for 3D lighting effects without the dithering or posterization you'd get with 15 or 16-bit RGB, just not as good as CRY itself allows: ie for games that only need fade-to black and use black distance fogging like Doom, Quake, or Tomb Raider, CRY is best, but if you need colored lighting or want colored or white fogging effects, RGBY would be better)

Technically speaking, given the existing 12-bit RGB format of the Slipstream but use of full 16-bit wide CRAM entries, extending that to 16-bit RGBY, adding a direct 16-bit color mode and 4-bit logical shading on the blitter would probably be one of the simpler upgrades to more impressive 3D. Allowing it to also work at 8bpp for 256 colors, provided the palette was organized as 4+4 bits (with 16 colors x 16 shades) the same logic could be used to provide shading in 256 color modes, just with those constraints on the palette. Or save CRAM space (and give it to the DSP as extra RAM) with only 16 CRAM entries used for 16 colors and the 16 shades provided in hardware mapping into the 16-bit RGBY color space.
Adding translucent blending would probably be a little more expensive, but adding a dither option (just rendering every other pixel as transparent) would be a cheap workaround useful for scaled bitmaps and polygons and a lot better than nothing, or having to use slow CPU rendering to do dither effects. (you also can't just use dithring at the texture/texel level since you'd get ugly scaling artifacts and corase dither meshes ... this option only works well for rendering unscaled sprites/objects and could already be done on the Slipstream of 1989 in the sprite rendering mode since you have per-pixel transparency by using the blitter's mask register to reserve one color value as transparent)

Going off a very hazy memory, didn't in seperate interviews, Sam and Leonard offer up polar views on the launch of the ST. 

 

Sam portraying it as a massive success at the time, Leonard feeling it hadn't made any real impact next to the PC? 🤔

 

 

I know when I asked Darryl Still about some of his technical based statements, at the time of the Jaguar, claiming it was as powerful as the Sega Saturn, he replied with:

 

"Maybe it’s selective memory or maybe there is only so much tech data my brain can handle, but whilst I have a good recollection of my own products, I really have retained absolutely nothing about the technology that was inside the Saturn. Because I do not come from an engineering background, I tend to lean on others and soak up like a sponge regarding the key bullet points to focus on in this area, so if I was talking bollocks at the time (and it has been known) my only defence is that I was badly advised. 😎"

 

 

I've always viewed the Panther as Atari trying to re-enter tye console market, with a machine that technically could match or better what Sega were putting out with the MD and Mega CD, so more colours and Nintendo with the SNES, so better sprite handling abilities, which themselves have been mocked by the likes of Rob Nicholson and Jeff Minter, who actually worked on the development hardware, on projects Leonard Tramiel himself seemed unaware of.. 

 

Maybe because they were UK based projects?? 

 

Sam's memo saying, just say technical issues, is typical Tramiel playing the press, they loved to be in the spotlight, annoucing new hardware, that'd never arrive or arrive late and didn't deliver half of what was promised, they'd always have a throw away excuse ready to explain why it wasn't now appearing. 

 

 

With games known to be in development when Panther was canned or at the very least, approved for conversion, more colorful versions of Shadow Of The Beast, Tiertex Strider 2,an unknown RPG, Jeff Minter's take on Star Raiders.. 

 

That's not going to cut any mustard next to the libraries and more importantly, third party support, Sega and Nintendo could call apon for their platforms.