Leeroy ST Posted October 1, 2020 Author Share Posted October 1, 2020 1 minute ago, carlsson said: (Any reference to "Where did you learn to fly" is completely unintentional) I forgot that was a thing, that became popular in AVGN's Jaguar bashing videos which of course gave you zero information. 1 minute ago, carlsson said: you could do very cool demo effects, colour cycling etc that you could only dream about on the SNES but unless you're a die hard Jeff Minter fan (meant in a positive way, I like his games but not everyone do), this console might not be for you. This seems to be the case where a certain "type" or "style" of game seems to be the focus. Even the Jaguar with 2D games without any Amiga ports from or to, still have that Amiga "style" even some of the homebrews which I always wondered was due to the tools. Excluding Rayman of course. Panther in relation seems to also the more it's looked into, designed for specific types of games. Quote Link to comment Share on other sites More sharing options...
elmer Posted October 2, 2020 Share Posted October 2, 2020 23 hours ago, carlsson said: Did anyone link to this page before? https://valentinomiazzo.github.io/Atari-Panther-Part-2/ https://valentinomiazzo.github.io/Atari-Panther-Part-3/ Assuming the author knows what he writes about, that is interesting. The 2000 sprites quickly became 480 sprites. Well, for anyone that can actually read technical specifications and has done commercial game developement, that is the link that would have been nice to see posted 18 pages ago. IMHO the tech docs that Valentino links to (especially the TIMINGS doc) confirms his interpretation. So when drawing graphics from cartridge ROM, that's a 1.8x screen overdraw capability (i.e. effectively 1 tiled-bitmap backround layer and 0.8 screen's worth of sprites) vs a 3x screen overdraw on the Genesis and the SNES (2 tile layers plus enough sprites to cover a whole screen). If you use the whole bandwidth of the Panther chip to draw that much data, then the CPU will be stalled for most of the frame time, and unable to actually do any processing and updates of the objects list ... yuk! Things look a lot better if you can copy your graphics data from cartridge ROM to SRAM, where you could have 64 16x16 16-color Bitmap Objects per line, basically giving you the same 3x screen overdraw as the Genesis and SNES. Except that once-again, in order to get that level of overdraw, your CPU is totally stalled for the entire draw time of the frame ... and that still doesn't take the cycle time to traverse the BO list itself into account. It could have been an interesting, but difficult, machine to develop for (which mainstream developers wouldn't have done until it sold a million or more), and as others have said, basically a 2D-game-only 7800-on-steroids. IMHO it looks like it *BADLY* needed more 32-bit SRAM memory on the board in order to even be competitive against the Genesis and SNES in 1991/1992 ... say 64KB minimum, but 128KB would have allowed it to do a lot more. 1 Quote Link to comment Share on other sites More sharing options...
zzip Posted October 2, 2020 Share Posted October 2, 2020 11 minutes ago, elmer said: IMHO it looks like it *BADLY* needed more 32-bit SRAM memory on the board in order to even be competitive against the Genesis and SNES in 1991/1992 ... say 64KB minimum, but 128KB would have allowed it to do a lot more. Yeah, this was what 1991? I know it's the more expensive SRAM, but why so stingy with it? Quote Link to comment Share on other sites More sharing options...
carlsson Posted October 2, 2020 Share Posted October 2, 2020 (edited) How much conceptually does this design share with the Jaguar? I mean if the Panther was a 32-bit test bed for an architecture, not fully specified with the intent for commercial video games, and then redesigned with a bigger capacity for real life applications. On the other hand, if that was the intentions, Atari either were fooled or imagined magical things would be possible, just like people had crammed out far more of the 2600 (which was not under Tramiel's claim of fame, but they still sold it) than originally expected. Edited October 2, 2020 by carlsson Quote Link to comment Share on other sites More sharing options...
ColecoKing Posted October 2, 2020 Share Posted October 2, 2020 (edited) It has long been established but buried time and time again that Panther was a terrible system to make games for and developers didn't like it with some guys maybe deviating. The Jaguar was chosen because developers said it would be easier to bring games and Atari went with that feedback, and with nonsense bit wars going on fooling consumers they matter more than they did, it being 64-bit was a bonus. That is why Amiga port is all over the console including Zool 2 and cancelled Bubsy 3 garbagetales which was revived on the Jaguar, deal with Virigin make Bruce lee only on Jaguar and cancel 3DO version supposedly in development, Brutal Sports Football lazy Amiga port. Someone on Allgame sadly many links even on archive.org don't work, had claimed to have tired to make demo like robotron, detailed but not complicated 80 sprites shooting on screen, than wave two of 80 come on screen he say the game froze because Jaguar had to stop because too much was being loaded in at once which I suspect is the processor freeze mentioned above. Panther was a pain to port, too many custom problems to deal with, Jaguar was bare minimum that is why you have these games The Humans Zool2 Bubsy Fractured pain play another game Brutal sport football Cannon Fodder International Sensible Soccer Pinball Fantasies The Humans All Amiga ports!!!!!!! Power Drive Rally, a sequel to an Amiga released game that is very much the same outside a few changes. Dragon Bruce Lee lazy updated port of snes mega drive game. Double Dragon 5 lazy updated port of snes mega drive game. Head-on Soccer lazy updated port of snes mega drive game. Towers II, a port of a Falcon game that came out the year before. Look at these games and years they come out, why you think these games were all over Jaguar? Because Panther couldn't do bare minimum and Jaguar could that is why many games look close to 16-bit title, though bit is not important in this case all marketing. Enhancements to games made for or originated on other consoles were good part of Jaguar game list. Panther often mentioned to have had many games move to Jaguar for this reason. Jaguar also hard to develop but it easy to bring games to and it powerful enough to update gameplay, and that is what developers did, bare minimum. Not one independent 3rd party push system capabilities. just Atari and partnered studios. Maybe Doom I suppose. Panther likely trashed because it was itself trash. Towers II on Falcon look bad imo, Jaguar version was upgraded they say, still look crap runs at 12fps Panther can't do something like this? Game over. Could Panther even play Mega Drive Gunstar Heroes at half speed? All evidence from available information is solid NO! Edited October 2, 2020 by ColecoKing Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted October 3, 2020 Share Posted October 3, 2020 12 hours ago, carlsson said: How much conceptually does this design share with the Jaguar? I mean if the Panther was a 32-bit test bed for an architecture, not fully specified with the intent for commercial video games, and then redesigned with a bigger capacity for real life applications. On the other hand, if that was the intentions, Atari either were fooled or imagined magical things would be possible, just like people had crammed out far more of the 2600 (which was not under Tramiel's claim of fame, but they still sold it) than originally expected. The whole Panther ObjectProcessor with single scanline buffer (well 2) that goes thru a theoretically long list of Objects as long as it can traverse it in the time of a single scanline is identical to the Jag ObjectProcessor behavior but I believe that setup may not be original to Panther per se either. 2 Quote Link to comment Share on other sites More sharing options...
ColecoKing Posted October 4, 2020 Share Posted October 4, 2020 Some digging Panther had problems they couldn't get Road Riot 4wD to work moved it to the Falcon/ST. Look at video of that game tells you how much trouble Panther was. Even simple games had big problems that why so many Amiga ports on Jaguar because they had prepared games for Panther that would work at time, but became bare minimum for Jaguar. I see no future where Panther is released unless they want 3 games a year. Take too long to get anything working on Panther. There is no prediction here, those say maybe it can compete with other consoles is impossible. Nearly all compliments back then were of things developers saw with demos and almost every complaint was when actually making game for system PROPER. Maybe Panther can compete with an Amiga but that not flying in 1992 or even 1991. Quote Link to comment Share on other sites More sharing options...
Leeroy ST Posted October 11, 2020 Author Share Posted October 11, 2020 On 10/2/2020 at 12:59 PM, elmer said: It could have been an interesting, but difficult, machine to develop for (which mainstream developers wouldn't have done until it sold a million or more), and as others have said, basically a 2D-game-only 7800-on-steroids. IMHO it looks like it *BADLY* needed more 32-bit SRAM memory on the board in order to even be competitive against the Genesis and SNES in 1991/1992 ... say 64KB minimum, but 128KB would have allowed it to do a lot more. This is why I am wondering about the 2D capabilities of the Panther. From some quotes and what little info about it we have it's unclear whether it was actually competitive with the likes of say a Genesis or SNES. Quote Link to comment Share on other sites More sharing options...
elmer Posted October 11, 2020 Share Posted October 11, 2020 1 hour ago, Leeroy ST said: This is why I am wondering about the 2D capabilities of the Panther. From some quotes and what little info about it we have it's unclear whether it was actually competitive with the likes of say a Genesis or SNES. There are the official development documents, circuit schematics and pictures of the development board (to confirm all of the above) ... that is actually one heck of a *LOT* of information! All of that information also exists online for the Genesis and the SNES. It seems very, very clear that the Panther (in its 32KB SRAM configuration) would have been uncompetitive against the Genesis or the SNES ... especially since most publishers would not have had any reason fund the difficult development of games for its specific hardware (since it is so unlike any of the other competing products). Yes, the Panther could do a couple of really nice hardware tricks that the other two consoles couldn't ... but that shared memory bus, the lack of sufficient SRAM, and the 32-color-per-line limits are things that would have limited the quality of any games. 2 Quote Link to comment Share on other sites More sharing options...
carlsson Posted October 11, 2020 Share Posted October 11, 2020 Like I wrote earlier, the Panther probably would've been great for colour cycling things, scene demos and some of the Jeff Minter style of games. But even he encountered some problems according to previous quotes and if even he found shortcomings in a system almost tailored for his type of games, it really appears to have been a test bed for a type of architecture and programming that was improved and altered on with the Jaguar. Based on what I've read, a full release of the Panther could've sped up the demise of Atari as a company rather than improving its finances. Quote Link to comment Share on other sites More sharing options...
Leeroy ST Posted October 12, 2020 Author Share Posted October 12, 2020 18 hours ago, elmer said: It seems very, very clear that the Panther (in its 32KB SRAM configuration) would have been uncompetitive against the Genesis or the SNES ... especially since most publishers would not have had any reason fund the difficult development of games for its specific hardware (since it is so unlike any of the other competing products). Yes, the Panther could do a couple of really nice hardware tricks that the other two consoles couldn't ... but that shared memory bus, the lack of sufficient SRAM, and the 32-color-per-line limits are things that would have limited the quality of any games. Seems like it may have been looking at the Amiga as the standard to beat then instead of the SNES/GEN which I guess isn't surprising giving Atari corps history and people involved in many of their projects working on the former. 18 hours ago, carlsson said: Like I wrote earlier, the Panther probably would've been great for colour cycling things, scene demos and some of the Jeff Minter style of games. But even he encountered some problems according to previous quotes and if even he found shortcomings in a system almost tailored for his type of games, it really appears to have been a test bed for a type of architecture and programming that was improved and altered on with the Jaguar. Based on what I've read, a full release of the Panther could've sped up the demise of Atari as a company rather than improving its finances. It does make me wonder about the original plan to have the Panther release and the Jaguar release less than 2 years later (18 months I believe). Perhaps Atari formatted the Jaguar to have some similarities to the Panther and knowing the Panther had a few development problems it's earlier release could get the few devs who worked on it "practice" for the more powerful Jaguar, perhaps. It's not clear though why they abandoned that plan other than saying the Jaguar was further along but no real elaboration on what "further" ment since the Jaguar clearly wasn't ready for it's 1993 launch which turned into a test launch instead and only shipped 20,000 consoles. Quote Link to comment Share on other sites More sharing options...
kool kitty89 Posted June 12, 2023 Share Posted June 12, 2023 On 10/2/2020 at 10:12 AM, zzip said: Yeah, this was what 1991? I know it's the more expensive SRAM, but why so stingy with it? That was high speed cache grade SRAM they were using, 4 8kx8-bit 35 ns SRAMs used in the scans of one of the prototype consoles. Specifically LOGIC L7C185-35 chips (actually rated for 35 ns read, but 25 ns write times) per the datasheet. See datasheet:https://www.datasheetarchive.com/?q=L7C185PC35https://www.datasheetarchive.com/pdf/download.php?id=b4583c7bd0d14537f54b5b0476b6c047170786&type=M&term=L7C185PC35 On top of that, at 32.215905 MHz, the panther would be pushing those SRAMs beyond that spec at 31.04 ns read cycle times. (though you can get away with this sometimes, especially when you're well above the next speed grade down: 25 ns in this case, and contacting the manufacturer for such tolerances can further confirm reliability for such; that's what Atari did with the ST when working with 150 ns DRAMs and cycling them at ~249 ns when the spec across several manufacturers was 260 ns, not to get into specific timing parameters used by the ST's MMU) That's the sort of SRAM used for board-level L1 cache for 386s or L2 cache for 486s using a 25 MHz bus (or 32 or 33 MHz if pushing the spec a bit) ... excluding burst timing on clock-doubled 486s and such. Specifically, those small 8kB SRAMs would've been the sort used in 32kB caches for 386 motherboards with 25 or 33 MHz CPUs. When the Panther was canceled in 1991, AMD was just coming out with their 386, so intel's 386DX-33 was still the upper mid-range (ie quite expensive) market leader with the still new and expensive 486s covering the higher part of that range. (the AM386, especially the DX40) would quickly change that, plus further competition with their own 486 release (plus Intel and AMD 486SXs) and Cyrix's 486DLC and SLC chips in 1992. But we're talking 1989-1991 and very, very fast SRAM. 32kB was a reasonable amount as such and one could argue bumping the Panther clock speed back a bit to use less expensive SRAM would have been a consideration (let alone any issues with heat and chip yield). Clocking the Panther down to 25 MHz would've allowed 40 ns SRAM and for NTSC video timing a fairly convenient 3.579545 MHz x 7 = 25.056815 MHz, use a cheaper 12.5 MHz rated 68000 as well and still be way faster than any other console at the time. Plus if locking the pixel clock to 1/4 the system clock, you get 6.26 MHz instead of 8.05 MHz, nice square pixels that fill the screen rather than leaving a big border like the ST does at 8 MHz, though only ~298 of the 320 pixels would be visible, slightly more than the Neo Geo's at 6.0 MHz. Using a 53.69318 MHz system clock like the Master System and Mega Drive used /2 = ~26.8466 MHz /4 = ~6.71 MHz or pretty much exactly 320 pixels visible on screen and not square pixels, but closeish and a compromise for both NTSC and PAL screens: pixels are narrow in NTSC and wide in PAL, but not crazy wide like SMS/SNES 5.37 MHz pixels. (Note: the Panther's line buffer chip was also separate from the object processor itself so MIGHT have been clocked asynchronously ... the Jaguar's line buffers are, so pixel clock could still be tailored to the screen or tailored to the NTSC colorburst signal to reduce color artifacts: 7.15909 MHz, exactly 2x the colorburst clock should give better image quality and a smaller, but reasonable border; it shouldn't have been hard to make the pixel clock programmable, though, or even region specific so 6.26 MHz NTSC pixels ended up at ~6.65 or ~7.39 MHz for square-er PAL pixels) However, the Panther ONLY needed that fast SRAM for its object list and doesn't need such fast (or wide) memory for other things, though it CAN store graphics memory in SRAM, so slower cheaper memory types could have been considered for bulk graphics data storage and CPU code/data, but none of the Panther prototypes or dev systems or schematics had such RAM, aside from DRAM used for the Ensoniq DOCII chip before they switched to the OTIS. (note: the Jaguar got around this by using 64-bit wide DRAM and page-mode burst operation, so it could read a 64-bit object list word in 2 clock ticks when in page mode rather than 2 32-bit Panther list words in 2 ticks from SRAM) As implemented, the Panther dev systems and documentation only intended ROM as the other memory source for CPU code, data, and graphics data. This makes the Panther very much like a 16/32-bit successor to the 8-bit 7800 with its MARIA chip ... except that within its lifecycle 120~150 ns SRAM got cheap enough that some games put 8kB on cartridge, some (like Summer and Winter games) even 32kB, only using 16kB and using a larger chip because they couldn't fit 2 8kB chips on cart. But remember that was around 1988 when the 7800 hardware itself was 4+ years old (1983/1984 design, equivalent to 4+1989 = 1993 for the panther ... but by 1993, 35 ns SRAM was still quite expensive) As for ROM, the Panther was set up to do ROM reads in 8 clock cycles, or ~248 ns at 32.215905 MHz, this matches well with the common slower/bulk grade ROMs of the time at 250 ns. The cartridge slot was also 16-bits wide and the Panther was set up to do high speed 32-bit SRAM accesses and slow 16-bit ROM (or hypotehtically, other external memory) accesses. While intermediate speeds or width combinations would have been useful, it doesn't appear the Object Processor had any provision for doing so and I'm not sure if external wait states could be implemented to support that easily. (ie the chip internals may have needed to be revised to allow it) With 16-bit wide 250 ns ROM like that, and assuming SRAM list reads are "free" (overlapping with consecutive ROM cycles, which they should do), you'd max out panther speed using ROM data when doing scaling on 4bpp (4 bits per pixel, ie 15 color + transparent) objects since scaled objects take 2 clock cycles per pixel or 16.108 Mpixels/s max, and also max out ROM speed when drawing 2-bit (3 color) objects at the full 32Mpix/s rate. Unscaled 4-bit objects could be done faster, but you'd need (hypothetical) 32-bit wide ROM or 16-bit wide ROM (or RAM) with 124 ns cycle times, none of which was supported. Only the 31 and 248 ns (1 tick and 8 tick) SRAM and ROM times were offered as far as I've read in the documentation. 1, 2, 4, and 8 bit depths are supported, but the middle two would be the most useful while 8bpp is limited by the 5-bit wide line buffer so 3 bits go unused/reserved and you use a full 8 bit chunky pixel (and it is chunky/packed, not planar like the ST or Amiga) to get 32 colors ... plus transparent. So really inefficient to store in ROM that way, but useful to compress and then store in RAM ... you just don't have much RAM to store it in. (and 10-bit wide ROM chips were really a thing, and using multiple smaller ROMs to get 10 or 12 bits to save waste would drive up cost by sheer number of chips on cart and assembly cost to solder all those vs 1 or 2 16 or 8 bit chips) 32 color RLE (run length encoded) objects are also supported, which is a simple form of compression the Panther can decode in realtime (I forget if that's limited to 16 or 32 Mpix/s) OTOH a 16 MHz 68000 needs 125 ns access times to avoid wait states, so that ROM would be too slow and would need 2 wait states per access; the 68k uses a 4 clock-tick long bus cycle with data needing to be on the bus by the end of clock tick 2 and on the bus for ticks 3 and 4 (the ST, Amiga, and some others used a 16-bit latch to keep the data on the 68k end and nest a second access in for the chipset/video read, so you get 2 DRAM cycles in a 500 ns 4-tick 8 MHz 68k cycle without wait states so long as the instructions execute along 4-tick boundaries). So as implemented, the Panther SRAM is the only source of 0ws memory the 68k has, even though much cheaper 120 ns SRAM or even cheaper 120 ns PSRAM (Pseudostatic RAM, commonly used in embedded devices as an alternative to slower SRAM grades, the Mega Drive, SNES, and Mega CD used it) or 100 ns DRAM with a suitable DRAM controller. (needs to be 100 and not 120 ns as the rating is for RAS/RAC timing and you need some lead time for address request from the CPU, address set-up and DRAM commands to be sent ... and even then you need a 32 MHz DRAM controller or a 16 MHz one working on a 2-phase clock ... which is exactly what the old Atari ST MMU runs at: 16 MHz clock = 32 MHz internal clock rate with ~31 ns intervals) A 3D or software rendered game making heavy use of the 68k would need to make heavy use of SRAM to work in and a large, but low-res scaled object as the framebuffer. say 144x96 scaled to 288x192 if you wanted to use 32 colors (also faster to render to since 8-bit chunky pixels) or do 288x96 line doubled with 4-bit pixels used as dithered pairs to fake more colors (optionally using 50/60 Hz h-scroll to blur things). Both cases use 27 kB to double buffer in, which doesn't leave much for other things. 256x80x4bpp double buffered gets you down to 20 kB. Still really tight. On top of all that, and just like the 7800, there's only one shared system bus, no local CPU bus and no dedicated video bus, so the 68k gets halted while the Object Processor is reading lists and data, and a game that maxes out Object Processor time will only have CPU cycles available in vblank, or for 60 Hz NTSC with a 200 line display (ie 320x200), that leaves the 16.108 MHz 68k with only 62 of the 262 scanlines free to work, or 62/262= 3.805 MHz performance and it NEEDED to be 16.108 MHz just to do that well, but then any ROM accesses cuts performance again to 2/3 (memory cycles are 6 ticks long instead of 4). And while maxing it out might be an extreme case, consider this: cross-platform development was common at the time and the NES, SMS, PC Engine/TG-16, Mega Drive/Genesis, upcoming SNES, and many arcade systems used tilemap graphics using 8x8 pixel cells. The Panther can emulate this using 1 object for each cell, but a 320x200 screen is 40x25 cells which means 40x25 = 1000 objects on screen at once just for 1 background layer, and you'd need slightly more than that to get a scroll buffer going, say 42x27 = 1134, and that's just ONE scroll layer, double that for 2 scroll layers like the MD used and SNES normally used. That's also 9072 bytes of SRAM used for the lists for each plane or 18144 for both, leaving ~14.28 kB left for everything else. That's assuming the CPU can even process that much ... but given you're manipulating all of those objects in parallel (ie scroll just shifts the position setting of each object by an increment) it might not be too bad CPU wise and you don't worry about collission between objects on the same plane. AFIK there's no character mode setting for objects that simplify them, unlike the 7800 where there is a character type of MARIA object that's more restrictive than with sprite objects and more optimized for background graphics. (like using single 32-bit words for object lists that exclusively use 8x8 cells and fixed offsets in memory, so fewer address bits and other bits: like how the tilemap name tables work on the MD) On the Jaguar you can just draw a framebuffer background using the blitter to one large object (you can also use blitter objects on a framebuffer instead of OP objects, but that's another story). If the Panther had more RAM or slow RAM pretending to be ROM, the 68k could paint characters to a framebuffer which would be used as one big object by Panther. As it stands, you could ease things by using 16x16 cells rather than 8x8 ones, so you can now fill 320x224 pixels with an array of 20x224 objects. Going larger than 16x16 would probably be too inconvenient for ports, but 16x16 would probably work OK. Games OPTIMIZED for Panther would avoid solid tilemap or background layers and instead build up the background from objects (sprites) of various sizes, some as large solid bitmaps, other grouped together like tiles/characters but in clusters or small arrays rather than a full-screen tilemap. Another middleground option would be converting tilemap graphics to objects, then culling out all the empty space in the tilemap (ie all 8x8 cells in the map that are just empty/transparent don't get any object assigned to them) Optimized games would also make use of the 32 color palette with its linear offset, so for 15 color objects (common 4bpp stuff) you can select any consecutive 15 colors from the 32 colors in the palette RAM (which are 32 entries from 18-bit RGB), 3 color 2-bit objects can thus use any 3 consecutive colors, and 8bpp objects just use all 32. Non-optmized games might just use those as 2 16 color palettes or 2 15-color palettes plus 2 reserved background/border colors. Taking Mega Drive games (with their 4 15 color palettes) and re-optimizing them for the Panther would be somewhat difficult, but probably doable with some careful organization. You get nicer colors from 18-bit RGB, but games have to be really tailored to that to make the most of them, plus since there's only 32 palette entries, any color cycling/blinking effects will limit use of color even more as ANYTHING using that chunk of the palette will have those colors cycled. (I mean cases where palette entries are changed between frames to make flashing or shimmering effects or to simulate waves in water) Panther can update all 32 colors on a per-scanline basis and doesn't have artifacting issues like the MD does, so it can do gradient effects with reserved background colors like the ST/Amiga do (and Atari 8-bit, VCS, and 7800 games do) as well as full-palette swaps used for water line effects without having to hide the errors with sprites like on the MD, but you can't easily do a lot more than that without severely restricting the use of the 32 colors you have. The Object processor itself supports a full 256 color palette and outputs 8-bit data as such, but only 5 bits of that 8 are actually used by the line buffer+palette chip, and developers restricted themselves accordingly. Given that chip was external, it could've been replaced/upgraded during the development process, even late enough in the design so launch titles stuck with the 32 color limit (a 256 color line buffer wouldn't effect backwards compatibility). They also could've replaced the line buffer+palette chip with one that just acted as a line buffer and, instead of outputting 18 digital RGB signals (using a resistor ladder DAC to convert that to analog RGB), it could have output an 8-bit pixel bus feeding an off the shelf VGA-standard RAMDAC with palette-ram built-into that. (since you don't need VGA standard 25/28 MHz pixel clocks, Atari could've negotiated for down-binned sub-VGA spec RAMDACs as well) VGA uses an 18-bit palette just like the Panther already did, so the colorspace would be identical. (you'd just need the CRAM updates sent to the RAMDAC instead of the line buffer chip itself) Ditching the palette RAM alone would have saved space in the line buffer chip, but even so, if they couldn't manage full 8 bit line buffers within cost/time constraints, 7 bits for 128 colors would've been sufficient to unilaterally trump the Mega Drive and heavily challenge the SNES's 256 colors with more flexible use of 128 colors from 18-bit rather than 15-bit RGB. (note the PC Engine/TG-16 actually uses 32 separate 15 color palettes, 16 for sprites, 16 for background, in spite of using 512 colors from 9-bit RGB like the ST/MD, it has massive flexibility with that many palettes or 'sub palettes' to work from ... that said, on average, the SNES's use of 8sprite + 8BG palette arrangement from much larger colorspace is normally more useful) Also worth noting, the Mega Drive VDP uses an internal 320x7-bit line buffer for its rendering, sprites loaded in h-blank and tiles drawn (mostly) during active display in sync with the screen. The 7800, Panther, and Jaguar use double line buffers to give the processor an entire H-time to load the next scanline. (also why you can use an asynchronous pixel clock for the video output) To fix the Panther's RAM bottleneck, you need to add some slower, cheaper RAM to the system. The quickest fix would be slow SRAM, matched to the CPU's speed, in this case 120 ns, say at least 64kB, so a pair of 32kx8-bit SRAMs (literally identical chips to what some 7800 games used on cart) A 12.5 MHz 68k only needs 160 ns, so 150 ns SRAM would do fine. But with very little more work, PSRAM could be subsituted at dramatically lower cost (but not as cheap s DRAM; broadly speaking probably around 2x the cost of DRAM and half of SRAM within the same speed range) so the same 64kB could be used at lower cost or a quite reasonble 128kB could be used and even simplified by using a single 64kx16-bit PSRAM chip. Without any other changes, the Object Processor would see that PSRAM (or slow SRAM) as ROM and take 8 cycles to access, the 68k would still be halted during such access, but you'd have a much more flexible system. A bit more work would invove giving the 68k a dedicated block of local CPU work RAM off the Panther/cart bus so it can keep working until it tries to access panther RAM or ROM and waits for a free cycle. Better than either of those would be DRAM, but you need more hardware to control it ... unless they just re-used the old and proven Atari ST MMU (not the STe, the old vanilla ST) and doubled the clock rate, matching it with sufficiently fast 70 or 80 ns DRAM. (whether or not Atari had even bothered to try this back then, I don't know, but the MMU was found to be extremely overclockable, particularly by late 80s era revisions, and provided you used fast enough DRAM and the necessary tweaks to get other system clocks running properly, you could double the MMU speed, double the DRAM speed, and double the CPU speed) 80 ns FPM DRAM was common in fast 286 and 386SX systems at the time and is also what the Mega CD used, though not all 80 ns DRAM likes beign pushed to 32 MHz MMU timing (incidentally the TC511664BJ 128kB 64kx16-bit DRAMs used in the Mega CD do perfectly fit the spec for RAS and precharge timing a double speed MMU uses). And if not the full 32 MHz (mostly for RAM cost reasons), 25 or 26.8 MHz should have bveen doable with a mix of 80 ns and especially fast 100 ns FPM DRAMs. 128kB of DRAM minimum but they could've used a lot more or allowed external expansion. (a DRAM-only expansion slot would use few pins as the address lines are multiplexed, so 16 data + 10 address lines would get you up to 1MB easy, plus the control lines and Vcc and ground, easily fiting in a little 40 pin slot, like the ST cart slot used) Though for a 1991 launch date, I'd say 256 kB of DRAM, maybe 512kB and don't bother with expansion. (actulally some of the 80 and 100 ns DRAMs used in the Lynx should've been fast enough to match to a 25 MHz ST MMU) If delayed until a 1992 release for whatever reason, 512kB easy. (DRAM prices dropped dramatically in 1990 and continued to in '91, enough that Atari wouldn't have to hedge their bets with foresight ... something that bit them with the Jaguar's 2MB since they chose that in 1992/1993, expecting prices to drop, but instead they rose slightly and stagnated until 1996 ... between 1990 and 1995, bulk DRAM prices hit their low in 1992, and Atari had the very bad luck of missing the price drop trend from 90-92 and banking on another one in 1993-94; a similar problem plagued the ST in 1988 when its price went from around 300 pounds to 400 in the UK due to RAM shortage, at the same time the Amiga 500 dropped from 500 to 400, where as had the RAM price trends from 1986/1987 continued, Atari likely could've kept dropping the price of the 520 ST and had the 1040 dead even with the Amiga 500 ... though they really needed faster CPU options, too ... moreso than the STe's graphics/sound upgrade, but that's another story) See DRAM price trends:https://phe.rockefeller.edu/LogletLab/DRAM/dram.htm The ST MMU already has latches and dual bus connections to allow interleaved memory access, so while the 68k gets to see 2 tick access and 4 tick cycles, there's another port available (originally for the SHIFTER to use) with an extra access for every 4 68k cycles, or in this case, 8 Panther cycles, so it should be possible to make that DRAM look like 250 ns ROM (320 ns at 25 MHz, 300 ns at 26.8 MHz) to the Panther, no faster than using ROM, but now in full parallel with the CPU and more than enough to store a framebuffer and/or have the CPU decode packed/compressed graphics data into (including the wasted 8bpp 32 color object data ... if still restricted to 32 colors) and space for framebuffer backgrounds. You'd only need to access Panther SRAM to update the lists, Cost cuts could be made by dropping the Ensoniq sound chip entirely and going to simple 8 or 16-bit DMA sound, using the 68k to software mix samples (which there is now much more CPU timt to do) and possibly adding a bargain basement FM synch chip like the YM2413 OPLL, Yamaha's bottom end model FM chip, technically a cut-down version of the PC Adlib/Sound Blaster standard OPL2, but I suspect many games would sound better than PC counterparts ... even those developed in the US, given the hard-coded instrument patches actually appear to be better than the ones often used in PC games (if not at least similar), and actual chiptune composers in the UK/Europe (and potential Japanese developer potential, and a smaller number of US developers) could make much better use of the chip than typical PC midi drivers. Worst case, PC game devs would have something familiar to work with and you'd have sound in the class of "high end" PC games from 1990-1992. Software mixed MOD/tracker musing would be especially useful on the 68k if it had its own local RAM to work in. (let alone a big chunk of DRAM) Aside from any of that, Atari should've been looking at the 1989 vintage Slipstream hardware the Flare team designed (which Konnix had a non-exclusive license on) as a ready-made alternative or stop-gap. With multiple companies in the UK developing games for the Konix Multisystem (several of the same ones who worked on Panther games) with dev systems out back in 1988 and finalized/upgraded production-ready hardware arriving in 1989 (8088 replaced by 8086, bus latch implemented to allow parallel CPU+video DMA cycles) and Lucasfilm Games taking an interest in the project, briefly considering licensing it for the US, Atari should've been totally on top of that, and following Flare's follow-on deveoplements of that chipset which continued in parallel with the Jaguar. (along with some modifications that could've been made or added without a chipset redesign, like addition of an external sound chip to free up the DSP for 3D games, use of higher CPU speeds if working in local RAM or ROM off the slipstream bus, switching from an 8086 to a faster 186 with built-in I/O and DMA hardware or to a 286 or to a 68000 with the addition of some external logic to handle big/little endian translation: though for porting of 3D and pseudo 3D PC games, let alone PC games in general, x86 might have been an advantage over 68k ... and a 286 can do some things significantly faster than a 68k of the same clock speed, even if the programming model is ugly) The Slipstream of 1989 was already 256 color capable, using a 256x200 (or up to 256x256) 8bpp framebuffer and 256 color 12-bit RGB palette (so Amiga/STe quality, but 256 colors), though 16 color modes were also supported, 8bpp was faster for rendering sprites. (4bpp 16 color sprites could also be used in 8bpp mode, the blitter masking high/low nybbles when doing so) It wasn't a crazy fast system, and might have had a hard time keeping up with the Mega Drive for some things, and the SNES when CPU bottleneck wasn't killing that one, but being blitter+framebuffer based, it could handle a single scroll layer and arbitrary number of small or large sprites without any flicker or tearing, but with slowdown or globally reduced framerate when hitting blitter timeouts. it also needed PSRAM for its fast system RAM and framebuffer (up to 256 kB) with slower DRAM (3 tick cycles rather than 2) up to 512kB. It was also supposed to be floppy disk based, which would've dramatically reduced costs vs cartridges (and made potential for budget game bundles and free/shareware demos), but inflated the system cost with the floppy drive and added load times ... though cartridge based games could still be supported as well, or especially large/complex PC ports tha needed extra ROM and disk simultaneously. ROM address space is also limited to ~256kB within the 1MB system memory map, so bank-switching or mapping would be needed, or a CPU with larger address range (286 or 68000) to copy from ROM into system RAM. 68k would be easiest for the latter, since the 286 would either need to run in protected mode (which 16-bit DOS games didn't use) or use the Loadall instruction exploit to go outside the 20-bit realmode address limit. (the latter would be most likely and was well known by this time ... PC games didn't usually use that as they relied on EMS memory and fast hardware bank switching supported by EMS-compatible chipsets) Side-note, but the most-advanced fully-16-bit 286 (or 186) instruction compatible PC game I'm aware of is X-Wing by Lucas Arts, which will run on a 286, albeit slowly (somewhat playable on a 0ws 286-16 or a 20 with WS, but only some of the sparser levels) and runs with less than 640kB of RAM free (I think it needs slightly less than 576kB) but needs more to enable speech/sfx and the in-game IMUSE MIDI driver, though still under 1MB total. So a game like that COULD have been possible on Slipstream with some optimization and the 3D math and rendering offloaded from the CPU. (plus memory mapping changed a bit for all the EMS stuff, since it makes heavy use of EMS for most of the sound and music engine) Also the Slipstream chipset wasn't a work in progress, unlike the Panther that never made it to mass production (or beyond prototypes and pro-production units). The Multisystem never got released, but the same basic 1989 vintage chipset ended up used in quiz machines by Bellfruit in the UK, so it was a viable chip to manufacture. (and that aside from the further developments of the slipstream in several stages that aren't well documented until you get to the 1994 dated Slipstream 4 V 3.3 developers manual, which has a CD-ROM interface, does gouraud shaded line fills for polygon drawing, and has a similar scaling/rotation texture mapping feature as the Jaguar, though lacks much else in common with the Jaguar: no 32-bit RISC GPU, same old 16-bit DSP, no object processor, a much simpler and cheaper 16/32-bit system and nothing at all in common with the Panther)http://www.konixmultisystem.co.uk/index.php?id=downloads The 6 MHz 8086 would've been a bottleneck in the Slipstream as it was, but still a step above what the 1988 dev systems had to work with (8088 and no bus latch, so all CPU + system DMA ran serial, no parallelism) and should've been significantly more capable than (and less difficult to program for in some respects) than doing 3D on the Super FX chip of the SNES. (Note the DSP of the Slipstream was designed by Ben Cheese who also did the Super FX, but the two aren't closely related: the DSP is a fast, simple processor that can do 16x16-bit multiplies in 1 cycle, and would be useful for 3D marix math, the Super FX is a 16-bit RISC microprocessor with 16 general purpose registers and 16-bit, ie 64kB external address space, an 8-bit data bus, and is far more general purpose than that DSP, but also not as fast at raw computation and bottlenecked by an 8-bit external bus; the Super FX is more like a primitive and limited 16-bit counterpart to the 32-bit RISC chips in the Jaguar ... except I don't think Ben Cheese had a direct influence on anything in the Jag) Worse, the SNES uses bitplane pixel organization for its graphics on top of using a tilemap, so you need to render to bitplanes AND draw things in cell-order, terrible for 3D and even worse for scaling bitmaps or texture mapping, the Slipstream uses a linear 8-bit chunky pixel framebuffer when in 256 color mode and a blitter to use for filling poygons or drawing wireframe vector lines. (on the SNES, the exception is Mode 7, which uses 8-bit chunky pixels or can be zoomed out to give a 128x128x8bpp linear bitmap by making tilemap writes: SNES Wolfenstein 3D does this; no Super FX games use Mode 7 for that ... though Doom probalbly should have) There's also a multisystem Emulator out there now, and more complex 3D demos from homeberw might eventually show up. No such for the Panther thus far. On 10/2/2020 at 10:17 AM, carlsson said: How much conceptually does this design share with the Jaguar? I mean if the Panther was a 32-bit test bed for an architecture, not fully specified with the intent for commercial video games, and then redesigned with a bigger capacity for real life applications. On the other hand, if that was the intentions, Atari either were fooled or imagined magical things would be possible, just like people had crammed out far more of the 2600 (which was not under Tramiel's claim of fame, but they still sold it) than originally expected. The Jaguar's Object processor (bitmap/sprite engine) is a development of the Panther. That and the 68000 are the only things in common. The Jaguar's Object Processor went for 64-bit bus width and a DRAM interface with page-mode support so it could do (at least in page-mode bursts) a 64-bit read in 2 clock ticks where the Panther could do 2 32-bit SRAM reads in the same time. I believe the Jaguar can also use GPU SRAM (4kB of 32-bit wide SRAM inside TOM) to store object lists, but if you don't want to do that for anything actually using the GPU (the 32-bit RISC processor inside TOM). The Jag's object processor now has a massive pool of cheap, fast bulk storage to pull data from, 2MB of DRAM (though as it turned out, 2MB was a bit more espensive than hped for the 1994-95). Where the Panther used 32kB of SRAM for lists and (some) high-speed sprite fetches, it had to store most sprite data in ROM. (sprite, object, it's the same thing in this context) The panther was limited to 8bpp max where the Jaguar could do 16bpp using CRY colorspace and expand 1/2/4/8-bit palettized data to 16-bits in the line buffer in order to do shading and translucent blending effects. The Jaguar removed the RLE (Run Length Encoded) object mode where the Panther could read compressed data from ROM or SRAM in RLE format (basically a 16-bit word would use 8-bits to define the color and 8-bits to define the run-length, or how many pixels to draw in a horizontal line, so 1 to 256 pixels wide; except you use 8 bits for color when there's only 5 bits actually used ... and not enough RAM to pack/compress that data further on cart and then load it into RAM ... unless you're doing realtime compressed data streaming on every single frame ... which is sounds like at least one Panther Developer was working on: this goes in general, not just for RLE data, but it does apply still to RLE data as while it's already compressed, it can still be further packed/compressed into ROM). The Jaguar's use of DRAM made RLE compression less necessary, so compression could be done on cart and loaded into DRAM decompressed. As an all-sprite system, you could also compare it to the 7800, or draw parallels to the Neo Geo. Hell, give the Panther Neo Geo sized cartridges and a separate sound bus for sample ROM (for the OTIS) and you'd have something to rival the Neo Geo in all but per-line color ... give it a full 256 color palette with 8-bit wide line buffer, and you'd have a 2D monster of an arcade system for 1991. (Atari Games might have taken interest in licensing it at that point, and probably still would have even with the 32 color limited version; arguably more relevant in 1991 than the Co-Jag was in 1995) Unlike the Neo Geo, it does true sprite scaling/zooming, not just shrinking. Panther tops out at 16.108 Mpix/s when scaling (1 pixel per 2 clock ticks) where the Jaguar does 1 every clock tick or 26.6 Mpix/s. The Jaguar can achieve that in all color depths from DRAM ... using ROM would be much slower and it doesn't normally do that. Unscaled pixels max out at 32.215905 Mpix/s. However, with object data in ROM, With cartridges limited to 16-bit ROM at 250 ns, you can hit 16Mpix/s scaling 15 color objects (4bpp) or the full 32Mpix/s if using 2bpp 3 color objects. You can use any mix of color depths on-screen, but 4bpp 15 colors per sprite was the standard for the 16 bit era, but some optimizing for 3 color objects could go a long way towards expanding that and IMO could be fairly easily used for splatter or pixel blast effects (1bpp would suffice in some instances for particle effects) and for a mix of particle effects, explosions, and projectiles as with scrolling shooters (SHMUPs) or even speudo-3D rail shooters. You could also use fairly large 2bpp objects as "windows" to software render effects/animation to rather than storing them as such on cart. (a 128x128x2bpp object would take up 4kB of SRAM) OTOH with sprite data read straight from ROM, you can have very, very smooth animation with no bottleneck of needing to update VRAM. It's just like the 7800 and somewhat like the NeoGeo or NES in that respect (except those each have a second, dedicated bus for graphics ROM on cart), the graphics processor can see straight into cartridge ROM and grab data directly from there. Well animated fighting games with huge sprites should've been easy on the Jag, provided you had enough ROM (ie cost is the factor here). Cut back to realistic (or budget) home console prices and ... well, it'd be a lot like seeing what the Neo Geo could churn out with just 512kB to 1MB of ROM ... except it couldn't churn out ANYTHING with ROM on just one bus. (ie you couldn't make a Neo Geo game cheap without redesigning the hardware, but you could make cheap/small Panther games AND big expensive panther games in the realm of something like the Neo Geo ... just like you can on the Jaguar: the Jag is a 2D monster with pioneering next-gen 3D features and most of the silicon used up on the latter, but the 2D end of it is pretty well maxed out *except* for the scaling/rotation blitter function, that is limited and also is the bottleneck for texture mapped 3D) Adding a good chunk of slower RAM onboard could do nothing but complement the Panther's strengths and reduce or eliminate its weaknesses. The Panther would've been dramatically better off with some slow/cheap RAM to use rather than just ROM, and in terms of raw sprite scaling capability, should have been extremely impressive for a home console in 1991, but it is just scaling, no rotation, no mode 7 style texture mapped plane and no Jaguar blitter rendered rotated terrain, either, and no Mega CD style effects. You'd need to do software rendering with the CPU onto a framebuffer to do any rotating floor effects. (with 32kB of SRAM, that would limit you to doing a small, low-res buffer and scaling it up to screen width, say 160x50 pixels used to fill the lower half of the screen with 320x100 pixels; 16kB double-buffered using 32 color 8bpp pixels,, 8kB for 16 color 4bpp) We're talking scalar or superscalar arcade games and such like Space Harrier, After Burner, Thunder Blade, or Galaxy Force, but limited by how much ROM would be affordable and then limited by CPU time and panther bandwidth. The panther was weird and quirky to program for, but unlike the Jaguar, they were mostly in conventional ways from the standpoint of old timers in the Arcade industry or anyone who'd programmed for the 7800. It's an extension of display list generated graphics, modernized and made to work more like late 80s era sprite based arcade/console hardware. The Jaguar offered a lot more flexibility and more shortcuts for porting computer or console games using other architectures, like worst case scenario for a 2D game: just use the 68000 and blitter to render everything more like a typical computer game or use the blitter to build tiles onto a framebuffer and MAYBE just the object processor for sprites or just blit them, too. 3D and pseudo-3D games that were intensive enough to need to use the CPU (or well written 2D games that used the GPU to manage the object lists as well) were the matter of dedicated developers interested and motivated to work on the platform. The Jag just didn't get the support it needed from internal and external development for a ton of reasons unrelated to how hard the hardware was to program for and more related to delayed full release, further delayed international release (especially to the UK, which was Atari's only market left with strong brand recognition .. and they cancelled the UK test market in '93 of all thing), and overly restrictive licensing/development model. (they needed to be way more open to 3rd party publishing and way more open to getting dev tools out ... and negotiating licensing terms and fees; with their limited market share and presence, they couldn't afford to be as restrictive as they were with it) As a general note to this whole topic: Rememebr the people in charge who'd made the 7800 and Atari ST successes were no longer in Atari Corp in 1989. Mike Katz (President of Atari Corp's Games division 1985-1988) had left in 1988 and Jack Tramiel had stepped down as CEO in early 1989 (Sam took over, Jack stayed on as chairman of the board). Also Atari Corp was a publicly traded company, so perception of the shareholders also skewed things ... ie some of their flashy claims and announcements were likely made more for the investor side than for the consumer side, and it's often difficult to please both without compromising. (Sega of America suffered from this horribly in the mid 90s) Investors tend to want something new NOW and lots and lots of promises and spending ... whatever makes the stock prices go up, not what's actually profitable or good for the company long-term. Jack may have been capable enough to manage both profit and investor interests in his time there, but Sam did not, and as Atari shed more and more staff from 1989 onward, there were fewer and fewer people around to keep things running (ie the rare actually competent middle manager and/or engineer, marketing rep, etc, who could be delegated to and compensate for a lackluster CEO) Sam might have gotten better with time and experience, but he got in at pretty much the worst time and also had some bad luck (like the faulty testing equipment with the Falcon that delayed its release by a full year ... which in turn soured Atari on outsourcing to East Asia for manufacturing, which probably inflated the Jaguar's manufacturing costs as well, and led to them partnering with IBM on that project) Unfortunately, Curt and Marty's "Business is War" never got released, and with Curt gone, I'm not sure what will happen to it or all the work put into it. But from discussions I had with them years ago and tidbits of info I got from here and there between 2010 and 2018: Atari had been offered the Mega Drive for US (possibly all of North America, but not UK/Europe) in 1988, Mike Katz was in favor of it, but David Rosen and Jack Tramiel couldn't agree on terms. I believe the outcome of that (with Atari walking away from the Mega Drive) contributed to Katz leaving Atari for an extended vacation ... which was interrupted when he was recruited to Sega of America (literally approached on the beack, iirc) as President in 1989 and handled the launch of the Genesis and cretical in the marketing and celebrity endorsements Sega got in that period, plus critital in ironing out relations with 3rd parties, especially EA who'd worked around the lockout system and gone unlicensed (Japan wanted to sue them, but Katz ended up negotiating a mutually beneficial licensing deal instead). At some point in the midst of all that, Atari had also been considered for localizing the Neo Geo AES and that may have been the Mirai project. In contrast, I'm not aware of any attempt to use Atari to localize the PC Engine. Katz was also critical in getting the 7800 as much development support as it did have, especially from Epyx (which he'd previously managed) and that connection to Epyx also led to the Atari Lynx being developed. Ironic or just plain unfortuate that Katz left before that was even released. OTOH, also unfortuate Atari didn't court him back to his position after he left Sega in 1991. His management style seemed far more fitting of Atari anyway, or rather, the Tramiels. (by his own words, Sega wanted more 'warm fuzzies' and he didn't do that, and had been butting head with Japanese management being straight/honest about his perspective of things, probably brutally honest by some standards, which seems more like what worked at Atari Corp ... at least during their best days: ie hard-line no-nonsense business) See this interview:https://www.sega-16.com/2006/04/interview-michael-katz/ also timeline for Atari Corp:https://mcurrent.name/atarihistory/tramel_technology.html Quote Link to comment Share on other sites More sharing options...
Austin Posted June 13, 2023 Share Posted June 13, 2023 🤨 Quote Link to comment Share on other sites More sharing options...
kool kitty89 Posted June 15, 2023 Share Posted June 15, 2023 A few corrections on the Panther Hardware performance. I went and read through the 3 relevant/useful WP/doc text files from Atarimuseum's panther archives. They're from Atari England's development system dated Nov 1990, and a separate Flare II Panther Hardware file from May 17, 1991. They're from Panther.zip (in the "Dev System Atari England" folder) and PantherHW DocumentsFlare II.zip. I'll attach the files for reference. (they were also saved in the wayback machine archive of Atarimuseum's website) Relevant text files: PANHW.DOC PANTHER.WP PDS.WP Both the PANTHER and PANHW files list the Panther Object List Processor (OLP or just Panther) to be clocked at 16 MHz, not 32 MHz. More specifically and usefully, in PANHW.DOC we have this: " 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. " This would mean SRAM is cycled at 2 Panther clock ticks = 125 ns and ROM at 4 Panther clock ticks = 250 ns. Or more specifically: 124.16 ns and 248.32 ns running at 16.1079525 MHz. (with the 32.215905 MHz oscillator actually used in the systems, same speed as the NTSC STe clock, it's NTSC colorburst x9, or specifically a multiple of 3.579545 MHz, hence why it's not the more correct 32.215909 MHz which is more correct for the actual 315/88 MHz chroma clock) This is the same ROM speed I mentioned previously, but SRAM is 1/4 the speed I specified. The dev system definitely uses 35 ns rated SRAMs for the 32kB 32-bit RAM area, but I have no idea why they did that. It also uses 100 ns 128kx8-bit SRAMs (16 of them = 2MB) presumably to simulate cartridge ROM for software to be loaded into. They probably that speed grade as it was what was available, and dev units don't need to keep cost down the same way. But note: that bulk SRAM is 24% FASTER than the RAM the Object Processor actually needs per the documents. Maybe there was some bug/issue that was avoided using super fast SRAM chips to compensate, but there's no mention of such. The one big bug mentioned is with the LoadPalette object type, which is practically unuseable, so the object processor can't use those commands to update the palette on a line or mid-line basis. (you'd use interrupts instead and have the 68000 update palette RAM on a per line basis as needed, more like the ST, Amiga, PC Engine/TG16, Mega Drive/Genesis, SNES, the old Atari 8-bit computers, and many others could do; I THINK the 7800 allowed DLL interrupts to have MARIA DMA new palette entries, but it might have just needed the CPU to do that, too) Or even play around with experimental overclock settings up to 32 MHz for the Panther clock, which would thus need 124 ns ROM time (that 100 ns SRAM is plenty fast), but even at 32 MHz, with 2-clock tick 32-bit SRAM access times, that only needs ~62 ns and not 35 ns. (and could probably get away with many 70 ns SRAMs) 35 ns at 2 clock ticks would be 57.143 MHz or very close to 16xNTSC Chroma = 57.27272 MHz, which is way faster than any clock they'd likely have been using. Then again, I've seen pics of some MEGA STE motherboards with way faster than needed tag+cache ram, and others that were more tame and close to spec (though still a bit fast for what a 68000 needs, but it was 1991, and mass market cache RAM yields were probably well above that spec even at bottom bin). So MAYBE Atari was experimenting with a 32 MHz mode or even variable panther clock (16 MHz for slow ROM 32 MHz for fast 120 ns ROM, maybe even 21.477 MHz for ~186.2 ns ROM, close-ish for 200 ns rated ROM chips) I don't see any mention of such in the documents, though, so unless it's an undocumented feature of the dev systems and something Atari was working with internally, it wouldn't make sense to implement on those dev units and populate them with such RAM. In any case, this means the Panther tops out at ~16.108 Mpixels per second and I don't see any mention of scaled pixels being at 1/2 speed (though some implications that you can get certain delays for scaling pixels down too small). With the specified H and V sync timing used, it also gives exactly 1024 Panther clocks and 68000 clocks per scanline (NTSC and PAL), which also means identical timing to the STe (and all PAL ST models) with 512 8MHz 68k/GLUE clocks per line and 1024 midres (640x200) pixel clocks per line. Though the Panther's line buffer video output is clocked separately using NTSC and PAL specific colorburst multiples, unlike the ST/STe's mandatory synchronous video timing. Specifically, it's mentioned to use 32.215905/5 = 6.443 MHz NTSC and 26.6/4 = 6.65 MHz PAL. That gives about 307 visible pixels on a typical NTSC TV and 320 for PAL, and the higher PAL clock also makes for slightly closer pixel shape to NTSC. (though pixels will still be wide/horizontally stretched out looking in PAL, exactly like Mega Drive games running in 320 pixel AKA Mode H40, but much less distorted than the SMS/SNES/NES or MD at 256 pixels) But, with the 16 Mpix/s limitation, this also means that 4-bit objects will max out pixel rate when read from ROM (or hypothetical RAM read at ROM speed), so it's just the 8bpp (32 color, 5 bits unpacked into 8 bits) that need SRAM to hit max pixel rate. Albeit, there's more latency with ROM (for the first data word read) so while throughput hits a limit, there's some speed gains in RAM, especially for small objects where the extra 2 clock ticks to read the first word add up more quickly. However, it also takes 4 32-bit words for a typical Object list entry (scaled or unscaled doesn't matter) and not 2 as I suggested. Both Bitmaped Objects and Run Length objects take 4 32-bit words, or 128 bits total for their list entries. This perfectly explains the "2000 sprite" limit on the Panther spec as that's 16 bytes per object and 16x2000 = 32000 or all but 768 bytes of SRAM used. (actually 760 since the first 8 bytes of address space are for a tiny cartridge ROM window, I believe for the security signature) But the 2 (16 MHz) clock tick, 124 ns SRAM time is even worse than the actual 32kB SRAM limit here as far as trying to use objects as background tiles. It's just totally impractical to use a massive array of 8x8 objects as you'd spend too much time reading through the list. It would make most sense, and be easiest to work with the 32 color limit, to just use full 32 color Run Length objects and keep art from using dithering or too much inteicate detail as large solid color spans compress extremely well, so a background with large areas of flood-filled color would be ideal and very easy to just convert into large objects or slabs stored in Run Length format. (still, compressing/packing those further on-cart and loading into RAM would stretch ROM economy a good deal further) Using a global set of 32 colors means graphics are similar to the Amiga using 5 bitplane mode and ignoring hardware sprites and the second playfield, instead blitting everything at full 5 bit color, which very few games do due to limitations and blitter/CPU speed constraints, but it would much more easily allow conversion of Mega Drive games with their 4 15 color palettes due to inherent color redundancy and just a bit more opitmization to work with a single 32 color palette. (though using wider line RAM and 128 or 256 colors would be dramatically better; ie upgrading/replacing the line buffer "SHIFTER" chip) Leonard Tramiel mentioned at some point in recent past (possibly on Twitter) that he remembered the Panther object processor chips "not working" and that the chips they had at the Sunnyvale home office didn't work or that there was a bug they never managed to work around or fix. However, at very least devs in the UK had working (if sometimes unreliable) development systems with real Panther chips in them and the only major documented bug I see is with the loadpalette object, which could be lived with. (in fact, leaving that bug alone, leaving the Panther chip as-is, and just replacing the external line buffer to 6, 7, or 8-bit line buffers, to allow 64/128/256 colors would make the use of the loadpalette function less relevant, anyway ... though if they built enough Panthers, they'd probably integrate the line buffers on-chip with a new Panther revision, more like the Jaguar uses or even the old 7800 ... or other consoles, most of which had the palette and buffers all on-chip along with color DACs and only analog RGB or chroma/luma video outputs, except the PCE/TG16 which used a separate RAMDAC chip for all its massive array of 32x15 color palettes + 1 background/border color for 481x9-bit color RAM entries, plus integrated video DACs ... almost as much palette RAM as a standard VGA RAMDAC's 256x18-bit of CRAM) It's also possible the PAL development systems worked OK while the NTSC ones didn't for some reason. With SRAM reads done at ~124 ns, it's really baffling to limit the system to just 32kB, even back in 1989, let alone 1991. There's reserved space for another 32kB of 32-bit RAM, not installed (separate from the 16-bit cartridge SRAM area specified in the memory map), but even with all 64kB that's skimpy and inefficient as you have to use 8kB chips and not the much more affordable 32kB ones or potentially even 128kB ones (technically they also made 64kB SRAMs, but mostly for cache RAM speeds and 8/32/128kB was the standard progression, plus it's the 64kx16-bit 128kB 16-bit wide SRAMs that would be interesting: 2 chips = 256kB 32-bits wide). 32kB and smaller chips were generally only available up to 8 bits wide. They did make 64kB 32kx16-bit PSRAMs at leas, so MAYBE there were some slower SRAMs in that same class, but definitely the latter and definitely available in 70 and 80 ns grades with 115 and 130 ns cycle times; Sega used slower versions of those same chips in place od dual 32k8-bit PSRAMs in later MD models) But 128kB SRAMs and PSRAMs were available from more vendors. The Panther's memory map includes a total 4MB area for 32-bit RAM (including the 64kB SRAM actually mentioned) and another 1MB region 16 bits wide, or a total generic region of "potential external RAM" of 8MB less 64kB of base SRAM address range, but 3 MB of that 8 MB range are listed on another memory map to be 16-bit wide but lacking DTACK signaling while the other 4MB 32-bit and 1 MB 16-bit do have DTACK, so seems unuseable as configured. That gives a very wide range of possible alternate 32-bit RAM configuration and a pretty wide range of potential (up to 1MB) 16-bit slower RAM as well, plus forwards compatibility with the Jaguar (or a slightly different, panther-compatible Jaguar variant). Plus you're slow enough that the fastest PSRAM grades would come close or even meet that specification at the time. Either slightly stressing the 130 or 135 ns rated 80 and 85 ns PSRAMs around in the late 80s or using the ~115 ns rated 70 ns chips instead (and also using true SRAM when available cheap enough) would all have been viable. I'd have to dig into manufacturer databook catalogs to see what speeds became available when, but I think the 70 ns stuff was around by 1989/1990 and the 80/85 ns stuff was. Even so, 120 ns SRAM was the cheap bottom-end grade by 1989/1990 and the same speed that most 7800s used. Yields were such that you usually saw a lot of 100 ns SRAM mixed in with 120 ns stuff for applications needing it, or even for applications needing much slower stuff. (like the 8kB of SRAM for the Z80 in the Mega Drive at only 3.58 MHz, though very early models sometimes used NEC XRAM, a type of PSRAM, back in 1988, most used vanilla SRAM for the Z80 and PSRAM for the 68k ... also 8-bit wide dual-port VRAM for the VDP, true VRAM in the DRAM industry standard naming sense, though it supported 16-bit wide via expansion only used in arcade versions; so the MD video chip is actually 8-bits externally where the Panther is 32-bits externally, though sprite tables require 2 32-bit words for each entry, or 8 8-bit VRAM reads reads; the PC Engine uses SRAM for its video chip and SNES uses SRAM for its PPU as well, I believe, both 16-bits wide, and 128k 8-bit wide DRAM for main RAM cycled WAY slower than it should have been at only 2.685 MHz, but that's another story) And using the market averages for DRAM and SRAM in 1992: (all per 1MBit = 128kB) 128kB DRAMs = $3.2 128kB SRAMs = $8.58 32kB SRAMs = $14.31 8kB and smaller SRAMs = $27.18 no info on 64kB chips or on PSRAMs specifically (though the latter should be between SRAM and DRAM). So 32kB of SRAMs using 8kB chips = $6.795 64kB via 8kB chips = $13.59 128kB via 32kB chips = $14.31 256kB via 128kB chips = $17.16 And: 128kB SRAM (4x32kB) + 128kB DRAM (1x128kB) = $17.51 so 35 cents cheaper to just use 256 kB of SRAM via 2 128kB chips. For a 1991 launch (preferably with upgraded line buffer + palette depth), I'd say 256kB of SRAM is totally reasonable and you use less board space with just 2 SRAM chips. 70/80 ns PSRAMs of the same size and pinout could replace them as they became available and Atari could even replace those with 64kx16-bit DRAMs and a fast/efficient DRAM controller similar to the Atari ST's, but with a 32 bits wide data bus and giving full saturation of bus cycles to the Panther as needed (ie DRAM cycles at 124 ns, but rather than hard-coded split between SHIFTER RAM bus and 68k CPU bus you give 100% to Panther, except you COULD also add a bit more and allow 68k access while Panther reads ROM) For all those cases, you're making some kind of RAM behave like 120 ns SRAM, and for all those cases the Panther is set up to steal the bus for 100% time on each active scanline until the full object list is processed. So it would still benefit the 68k to have dedicated RAM to work in off the Panther bus (120 ns PSRAM would be sufficient or a slower DRAM controller using 100 ns DRAM). That slower CPU bus could double as the source fot a simple DMA sound engine reading samples from RAM. (the 68k now becoming the sound processor, software mixing to a simple 8 or 16-bit PCM buffer, better with a cheap little sound chip as well, like the YM2413 OPLL; or you do still use an ensoniq chip but use the 68k to stream ADPCM/DPCM compressed samples into DRAM ... and actually include DRAM for the chip, not just sample ROM and 8k of SRAM; the old ES5503 DOC or DOCII was plenty good enough even limited to 8-bit samples, and used cheap/slow DRAM on an 8-bit 6800/6502 compatible bus, and the 68k HAS a 6800 bus compatibility mode for 8-bit peripherals, so you're good; using the LMC1992 stereo mixer chip from the ST would greatly improve the flexibility of the 16-channel output of the DOC and allow much more flexible stereo panning effects on channels rather than locked left-right stereo channels ... unless you wired it up like the STe's DMA sound channels and didn't cross-connect to multiple L and R channels to allow a single channel to be panned sm0othly from left to center to right as desired ... or use offset volume with 2 channels set to center and pair 8-bit channels to 16-bit mono: which the STe also missed out on, without modding) But on top of that, the Panther's 32-bit RAM is left idle during ROM reads, especially long ROM reads for large objects. If you added a bus controller/arbitrator/bridge chip with address and data latches for the CPU, you could set things up so the 68k could use those idle RAM cycles for itself and not just be stuck there. The documents also mention 2 wait state operation for the 68k in ROM, and no mention of a provision for ROM faster than that 248 ns access time. With ROM speed locked at 4 panther clocks (248 ns at 16.108 MHz), the panther should be busy in ROM for the next 4 clock ticks, so there's 4 124 ns RAM cycles open and available to the 68k, of which it can make use of up to 2 with its 4-tick memory cycles (2-tick access, but 4 tick cycle time). You latch the data at access time, so the memory controller would only be touching RAM for 124 ns at a time and would have some room for mis-alligned 68k cycles all while making sure the RAM is freww for 0 wait state access to the Panther by the time its done with that ROM cycle. Of course, if the Panther starts another ROM cycle, it leaves another 248 ns period free for 68k use in RAM. Objects with their data stored in 32-bit RAM would not have such down time, and the 68k would be blocked from using it, and also couldn't easily access cartridge ROM since the Panther needs 0ws access to that as well. If you added dedicated bank of shared 16-bit RAM (not local CPU RAM) you could use that as a separate bank to interleave with as well, but Panther would still see it as slow 16-bit memory and use ROM cycles to read it, but the memory controller could see it as faster (ie more 124 ns RAM) and allow the 68k to access 16-bit RAM just like 32-bit RAM while the Panther is working in ROM, OR allow the 68k to access 32-bit RAM while the Panther is working in ROM or 16-bit RAM, or (since RAM is 2x as fast as Panther thinks) interleave 16-bit RAM accesses with Panther, though give the Panther priority, so any mis-allignment forced 68k waits (Panther can not be made to wait) rather like the ST's RAM or Amiga or Slipstream PSRAM. (but if not using DRAM to accomplish this you significantly simplify engineering, though a follow-on project to replace SRAM/PSRAM with DRAM and a fast DRAM controller could be planned for cost reduction provided sales go well enough to merit it) Adding such a chip late in development should've been done using gate array logic as it's simple to design for and fast to get prototypes made up. (plus Flare had implemented the Slipstream in gate array logic and included both a DRAM controller and bus latching PSRAM/SRAM bus controller unit in that back in '89) Though if you wanted to add 3D capabilities to the Panther, going a step further and re-using large chunks of the Slipstream ASIC for a Panther + 68k specific bus controller + I/O (it has 19 joystick input lines and 3 analog pot lines plus one light gun/pen line) + fast 16-bit DSP for sound or 3D math, plus a blitter for polygon filling or building up 2D framebuffers (could work in 16-bit panther RAM while the Panther works in ROM and/or in vblank, or when ever the panther is done reading lists; then you have the framebuffer there to read as panther objects from 16-bit RAM). Just remove the video controller and set things up for the 68k bus and you should be good. OR they could even integrate the new line buffers onto a gate array chip, but that's asking for trouble if bugs crop up where if they're separate chips the bugs can be worked out separately without messing with a good/working chip. (plus faster prototyping turn-around time and different speed ratings) You're also not making a whole new system, but a hybrid of 2 designs that several developers already had access (from 1988 in the case of the Slipstream, though 1989 for the proper 8086 model with bus latched interleaving). You even had several of the same developers working on the Panther who worked on the Konix Multisystem with its Flare Slipstream hardware. (Jeff Minter worked on all of the above) So, unlike the Jaguar, you aren't starting fresh with a new design, but re-using existing components with minimal redesign, so existing tools and documentation can be immediately applied and existing projects can be adapted to the new hybrid hardware. The Slipstream uses normal 4 and 8 bit chunky pixels, so it would easily render to panther bitmap data regions in RAM, plus even if you ended up stuck with just 32 colors, the blitter is set up to use 2 of the 3 "wasted" bits per pixel for priority. (it was designed to drop color count to 128 or 64 colors and allow 1 or 2 bits of priority to accelerate or at least simplify certain types of rendering, particularly reverse painters algorithms or anything that involves under-writing, especially when doing blitter rendering that repairs and modifies the previous frame and doesn't just redraw it like the Lynx, ST, and a lot of PC games did, but more like Amiga games or VGA games using 4-bit planar or 8-bit unchained modes with hardware scrolling, copy, and fill functions rather than the fixed 320x200 mode 13h MCGA compatible 'dumb' framebuffer mode) But, the Slipstream hardware was there in 1989, Atari even had the potential to negotiate with Konix OR to just go it alone (the hardware was open to license) with a working system in 1989 for a potential 1990 release as-is. By the time of the panther's cancellation in April of 1991, that's when you'd seriously consider upgrading the slipstream or hybridizing it with the Panther (the Jaguar did all of that, conceptually, but not literally as it was much more than that and used vastly more complex/larger/transistor dense chips and more RAM). It's also easier to migrate x86 code to 68k than the other way around, plus you get the necessary address space for cartridges + RAM, though a fast 286 would also be tempting to use, and would be faster/more powerful than a 68000 at the same clock speed, it's also a lot less elegant to use, so it's a toss up. (it's also more efficient with memory access, with 2 clock access and 2 clock cycle time, so no dead time unless you add wait states, so with 124 ns SRAM you can have a 0ws 286 running at 16.108 MHz and with 4 cycle ROM access rather than 6 ... there's also the oddball NEC V33, which is even faster than a 286 for some things, but is 80186/V30 instruction compatible instead and doesn't have the 286's MMU for protected mode, instead integrating LIM EMS memory mapping to 24-bit address space, useable in real-mode without hacky load-all exploits of the 286 and the standard memory mapping used for DOS games using more than 640kB prioer to 1993, and even after that for a number of cases: and some oddballs like Lucas Arts that required 386 instructions AND EMS memory working in real mode with hardware EMS or in virtual 8086 mode) The 68k would be better for developers using C rather than assembler, but even an 8086 is better for that than the SNES's 65816 (which did really poorly for devs trying to work with C), hell the Z80 is better for C as well due to its register set, 6800 and 650x are just ill suited to it. (unless you up-clock them and offer a cache or scratchpad at high speed to use RAM in place of registers, plus use a compiler that uses virtual registers like that ... like if the SNES had 32k of fast SRAM/PSRAM it could run at 2x speed in) Also the Slipstream handled floppy disk control via DSP programming, so custom disk formats could be used beyond the Amiga-like 880kB, and would allow encryption to prevent easy floppy copying/piracy but could also support shareware games using standard PC (or ST) disk formatting OR could use a custom format that just included a single PC formatted sector for game save data and the like. It also could have supported high density floppy drives (for 1.7 to perhaps just under 2MB for densely packed data) plus data compression could be used to store more, however, DD drives were significantly cheaper than HD ones and the demand for HD ones was driving the price of the lower density ones down to the point it would be more realistic to include them in a console or offer as a relatively low-cost upgrade for both cheaper games AND bigger/higher quality full price games. (potentially with ROM + disk combos for reduced load times and no or at least less disk swapping: to some extent, the ROM would act like part of a game installed on a PC hard drive, except much faster to access and likely not nearly as bug a chunk of memory) The same goes for an Atari or ANY CD based console with a conservative amount of RAM and a 1x speed drive, ROM + CD games would make porting large/complex PC games or arcade games (with lots of animation) to hardware that would otherwise need animation and content cuts on top of long load times. (hell, even in 1996 ... imagine if Nintendo did that as both a 'feature' to work around RAM limits + CD load times AND, more important to Nintendo: offer cartridge quality lock-out and licensing constraints so long as every single game needed a cartridge: they might not have lost Square that way, given it was more the CD multimedia feature set than Nintendo's politics or licensing agreements that bothered them) Also link to Christian Zietz's page on Atari ASICs which references the GAME SHIFTER (Atari Panther Line buffer chip, numbered 4118 and visible in pictures of the Dev system boards) Plus a PDF print of the panther schematics. (I believe the Production version, not the dev system, but I'm not sure: I haven't been able to open the old Atari CAD drawings myself)https://www.chzsoft.de/asic-web/https://www.chzsoft.de/asic-web/console.pdf (Atari Panther schematics) Panther.zip PantherHW DocumentsFlare II.zip Quote Link to comment Share on other sites More sharing options...
kool kitty89 Posted June 28, 2023 Share Posted June 28, 2023 Another correction on a couple detail: Jack Tramiel stepped down as CEO and Sam took over in May of 1988. https://www.atariarchives.org/atarileaks/timeline.html "May, 1988 Sam Tramiel took on the role of CEO of Atari (replacing his father, Jack Tramiel). Sam Tramiel would continue as president, and Jack Tramiel would continue as chairman. " Michael Katz didn't leave until some time in spring of 1989, he was replaced in April: https://mcurrent.name/atarihistory/tramel_technology.html "April: (early month) Ron Stringari, previously Atari Entertainment Electronics division vice president of sales and merchandising, would be promoted to president of the Atari Entertainment division, replacing Mike Katz who departed the company. (AdWeek 4/10; CornellAlumniNews 1989 p57) (Katz would join Sega of America as president/CEO in October 1989.) (Bob Harris remained marketing director/Atari entertainment electronics division.)" So the comments I remembered Curt and/or Marty making about Jack and David Rosen (of Sega) failing to come to agreeable terms on Atari distributing the Mega Drive would've been with Jack as Chairman, but not CEO. Katz didn't leave until after that. This also means he should've been aware of the Lynx and of early efforts related to what became the Panther. Also the Panther itself came out of an edict made by Jack Tramiel that any new video game console could not use any DRAM. Per Leonard Tramiel interview on youtube a few months ago here: https://youtu.be/QtHfH8O2xac?t=3235 This decision was likely made in 1988 or maybe '89 during the height of the DRAM shortage and inflation due both to poorer than expected yields of new 1mbit (128kB) chips and new restrictions/quotas on imports of Japanese DRAM following a federal ruling on previous price dumping or illegal anti-competitive tactics used by Japanese manufacturers. (atari largely avoided this with overseas manufacturing and it doesn't seem to have applied to importation of Japanese DRAM as part of finished goods or components, logic boards, etc: also likely why DIMMs and SIMMs became popular at the consumer level, as those could be imported and sold as-is without qualifying as bare DRAM chips). Additionally, this is the same time period when PSRAM (Pseudostatic RAM) became available, which also would've avoided such restrictions either because it's not DRAM in the strict sense (it's made to be in-compatible and interface compatible with SRAM chips and isn't a direct replacement for DRAM) or because it has DRAM inside of it, but along with additional control logic and buffers that come together to make a different final product. In either case, the Atari game console should've been free to use that interchangeably with SRAM when available and cheaper. VRAM (dual port DRAM specifically intended for video applications) might have still fallen into the DRAM category, I'm not sure. (noteworthy both for computer graphics at the time and for the Sega Mega Drive which used 64kB of VRAM as its video RAM, unlike "VRAM" in other consoles where it's just shorthand for Video RAM and was usually SRAM or PSRAM, or plain DRAM in the case of the Master System) With the XEGS and Lynx already using 64kB of DRAM each (and sharing similar 64kx4-bit DRAM chips, each using a pair of them), it made some sense to not introduce yet another DRAM based console during the shortage. That shortage itself may be one of the factors in the Lynx's initial production problems. Quote Link to comment Share on other sites More sharing options...
Lostdragon Posted December 29, 2023 Share Posted December 29, 2023 Thread bump but, saw this and it relates to the topic in hand.. In the 16-page ATARI feature in the new Retro Gamer Annual, Volume 10,there is a quote from D. Scott Williamson, regarding the Panther. "I worked on the Atari Panther and technically it was probably too much like the older Atari 8-bit computers to be competitive" Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.