Comparison of 5th generation ("32/64-bit") game console hardware [Archive]

kool kitty89

06-09-2011, 05:46 PM

If you take the entire Jaguar's best case , and compare that against the Saturn VDP1 only then it appears comparable, but it's not quite as simple in practise and the hard limits on sprite overdraw are based on max pixels per hor. line , not total pixels per frame.
Once any backgrounds are involved there's no comparision at all.
Hmm, and any blitter rendered stuff would STILL add to that overdraw limitation as the framebuffer as scanned out as part of the object list, right? (which does allow neat things like fast full-screen scaling -and, of course, use of the OPL's line buffers for scanning the frame buffer at max bandwdith)

So the Jaguar is good for what it manages at low cost (and for being an older -though extremely cutting-edge- design), but not so much in raw performance. (then again, take almost the same hardware, but remove the super tight cost constraints -like being fixed to a unified bus, cheap CPU without cache, or -especially- relatively slow FPM DRAM, and things would change a lot -like with 35 ns EDO DRAM and something in line with an SH2 in place of the 68k, even without adding a 2nd bus -especially with the 2nd bank enabled for minimized page breaks . . . or no added CPU at all, but enough R&D time/resource to debug the GPU and DSP and add a cache in at least one of the 2 ;))

Flare did exceptionally well with low-cost limits on design and Atari's funding limits (and the very small R&D staff involved). Not to knock Sega's R&D though, they probably could have managed better (albeit spending a lot more on R&D to do so), but the Saturn seems to have gone in a rather odd direction as far as an efficient/unified design and one keeping costs to practical levels for the time. (not just the use of SDRAM, multiple buses for less-buffered graphics chips, or such, but things like the oddly overbuilt CD-ROM interface -SH1 with 512k of SDRAM dedicated to it where a cheap MCU and a small chunk of DRAM would probably be dine, hell, they could have built off of the MCD's 68000 based interface and chipset for that matter -tweaking things to support 2x speed mode and probably boosting the cache to at least 32k)

If the Saturn had been backwards compatible with the MD+MCD, it would have made a lot more sense to have some odd inefficiencies . . . except they probably could have had a comparably powerful (as far as consumers could see) and more cost effective machine and still made it backwards compatible.

Albeit there's also the rumor that went around the industry (and in the press) of the Saturn being significantly built-up late in design (usually claimed to be a result of the PSX threat, but it may have been more due to the 3DO/Jaguar and perhaps newer PC games -Sega of Japan was apparently taking the Jaguar's 1993 hype as a serious threat, partially spurring the 32x as well -and preceding "Super Megadrive" project; of course, they also had a good idea of what Nintendo was working with when the SGI partnership was announced -since Sega's own engineers had already scrutinized and critiqued that prototype chipset previously).
Though it they really DID do such a redesign, it was certainly rather sloppy, or at very least not carefully cost controlled. (the earlier design was supposedly primarily built around VDP2 with a single SH1 as the CPU -presumably dual-prupose as CD-ROM controller as in the MCD- with the same sound system, less main RAM, either software rendered "sprites" to VDP2 or -more likely- a primitive incarnation of VDP1 lacking the 3D drawing modes -which could also explain why the warped quad modes have broken "half transparency" effects)

The Saturn's VDP1 seems rather similar to the 3DO's Cel engine in a number of ways, though the Saturn obviously avoids the contention issue by adding a multi-bus video subsystem and uses RAM clocked as fast as the processor too. (but the 3DO has a 32-bit bus to work with, so potentially close to the same bandwidth -not sure how many operations actually supported 32-bit accesses though)
If the 3DO's Cell does actually allow most things in 32-bits (fill, gouraud shading, non-rotated 2D blits) that would get it a lot closer to VDP1 performance on its much slower RAM, especially if it had a 32-bit write buffer for texture mapping. (I doubt it has a 32-bit read buffer though)
If the Cel doesn't so much of anything at 32-bits, the only reason to even have 32-bit VRAM would be for famebuffer scanning bandwidth. (ie for the rather unnecessary/overkill high-res/high-depth modes) A 32-bit write buffer would also make it faster than the Jaguar's peak texture mapping rate even if using VRAM as source and destination.

Also when maxing out the Jaguar this way you end up starving the cpu of any bandwidth - so all processing end's up having to run in vertical blank. And with a complex sprite system the overhead of maintaining the object list can become excessive.
Isn't it preferable to use the GPU to build the object lists? (especially in such intensive cases . . . and where the GPU has no overhead for 3D or such)

Not really, even the Jaguar II still was a 'blitter' - the PSX GPU was a full geometric drawing engine for 2D triangles and lines , with all setup handled internally. ( Plus the name of the chip was GPU :) )
I thought the Jaguar II allowed triangle rasterization in a single blitter operation (not set up a line at a time like the Jaguar), with just the vertex information needed. (the Saturn's VDP1, 3DO's Cel, and PSX GPU both need separate processors to generate the vextex data too -the GTE is obviously not part of the GPU)

Couldn't the jaguar blitter also freely draw vector lines as well? (albeit not all that useful for full rasterized 3D . . . and something the old Flare 1 video controller also supported -actually, that had the neat "color hold" mode too, allowing filled polygons to be formed from plain outlines -though you'd still need to handle hidden line removal, and you could only render filled polygons in that mode, no textures/bitmaps/sprites and no dithering -it definitely saves a lot of blitter bandwidth for pure polygonal games -the 32x's RLE mode might have allowed that to some extent too, but probably with significantly more overhead for formatting things to RLE correctly -and the flexibility of using textures/bitmap stuff as well)

On another note, was I mistaken when I spoke of MARIA's line RAM being on-chip? (I'd gotten the impression that MARIA loads a scanline into on-chip RAM via DMA, and double buffers it to allow nearly free access of the main bus during active display to DMA the next line while the other line is being clocked out to the screen -of course, you'll end up with the CPU only working in vblank if you use all the bandwidth)
I'm not sure if GTIA/ANTIC has anything remotely close to that (if it is, it's certainly no double buffered -which would mean you could only fill it in hblank), but I'd definitely gotten the impression that MARIA did it that way.

The 7800 obviously isn't a 5th gen machine, but I was just using that as an analogy to the later line buffer systems used. (and how early such set-ups were being implemented in LSI) Albeit, applying that system to make efficient use of FPM accesses came much later.

The hit must be way higher... for example DRAM memory can to 16 reads OR writes in 1 time unit, but it can only 3...4 reads AND writes in that same time unit. That is a massive lost. Now if the reads and writes happen in same DRAM row then you get mo performance hit.
Yes, there's a good bit of contention in general, but as far as the framebuffer is concerned, it shouldn't be a major hit. (I'm not positive on the GPU's low-level functionality, but it should be stealing the bus for long segments to buffer a scanline at a time -or close to it- and staying off the bus the rest of the time)

Also massive caching will help, BUT you are forgetting the caches have to be written back to the memory at some point and while you write them you cannot do anything else, which is why I said it only softens the blow, and does not eliminate it.
Yes, always an issue with efficient bus sharing of DRAM based systems with page mode support (old, slow DRAM systems have similar trade-offs as SRAM since all accesses are slow anyway).
And again, it's not just caching, but additional buffering on top of that. (line buffers or "phrase buffers" especially important for un-cached operations -again, not sure on the specifics of the PSX GPU, but one direct comparison given to the jaguar was use of 64-bit source and 256-bit destination buffers to reach PSX level performance on the Jaguar's bus -working in cache would allow even higher bandwidth for cached textures, but there's the cache fill overhead to consider too)

PSX can have only 2x higher peak performance than Saturn, due to 32bit VRAM bus or 16+16, if there were 2x 34bit banks the bandwidth must be much higher than 133MB/sec so it is probably 16+16 setup, which makes more sense given what chips are used on the mobo and what do later models look like. Some early mobos use 4x 8bit 60ns DRAM chips. 60ns is access time within a row, and for 8bit memory it only gives 16.7MB/sec bandwidth per chip, you got 4 of them so its around 65MB/sec. Access that is done on different pages will result in much poorer performance, about 40% less, random access is 104ns.
60 ns seems way too slow, it should be 30 ns at least (for page mode accesses), it's too slow to allow 133 MB/s on a 32-bit bus. (then again, DRAM naming is a bit weird -wiki's example of "60 ns" referring to RAS low to valid data out, and that same RAM being capable of 25 ns FPM cycle times -so definitely compatible with the PSX . . . the Jaguar has 75 ns FPM accesses and 175 ns -actually longer due to 5 26.6 MHz cycles being the closest you can go- . . . so I guess that wouldn't actually be "75 ns DRAM" by convention -which would also imply that FPM cycle times of the MCD/SVP/32x's "80 ns" DRAM could be much faster than 80 ns)

The PSX's DRAM should be operating at 1 access per 33.8 MHz clock (when in page mode) and (given the ~104 ns figure) adding 3 wait states for full random read/writes. (so ~33 MB/s rather than 133 -and minimizing those page breaks is essential to good performance, which is a huge part of that caching/buffering, maintaining page mode accesses as much as possible -most efficient for moving large chunks of data around, worst for rendering a lot of small objects where you'd have nearly constant page breaks even for plain solid color fills or cached textures)

The PSX's DRAM is faster than the Saturn's RAM, at very least for page mode reads/writes. (~33 MHz vs 28.6/26.6 MHz) That's hardly surprising as EDO DRAM commonly went up to 33 MHz and the higher end stuff at least went to 40 MHz (most stuff from 50 MHz, and especially 66 MHz upward tends to be SDRAM). IIRC, common FPM DRAM rarely went beyond 22 MHz.

If the PSX was only using 60 ns FPM accesses, it would be using super cheap DRAM in-line with the jaguar (the jaguar 2 was actually planned to use RAM in that speed range, the Jag 1 was 75 ns in FPM), and they probably would have invested in a GPU with 64-bit DMA (though the CPU would still be stuck on a slower 32-bit bus -with more wait states for random accesses too). It would also mean they were using much, much cheaper RAM than the Saturn (or 3Do VRAM) and only slightly more than the Jaguar or 3DO (CPU work RAM), so I highly doubt that's the case given Sony's position. (not to mention the 133 MHz CPU and video bus speeds listed in various documents)

That 133MB/sec figure is only plausible when some really small chunk of memory is being manipulated with so it all fits into the internal caches. There is no way this is achieved in any other way.
It's plausible for framebuffer reads a block fills to "VRAM" where fast page mode is sustained for long periods. (fills of tiny polygons would have a lot more overhead on average per pixel)
Texture mapping would only reach close that speed for larger polygons using cached textures (small polygons end up with a lot more page breaks), and somewhat less for uncached textures. (though there's cache fill overhead to consider too -also more wasteful for small polygons that don't even use much of the texture)

I only read that there's 2KB of cache, and that isn't whole lot of memory
I'd gotten the impression there was an additional GPU data/command cache in addition to that, but I can't seem to find that reference again, so maybe I just remembered it wrong. (obviously it's got a lot of buffering for accelerating non-cached operations too)

I am designing a computer right now, and while its maximum bus bandwidth is 67MB/sec, you will only reach it in ideal condition when only one single device is on the bus and no other is. Now if I add CPU to the mix, some DMAs happening every once in a while I will end up with a figure nowhere near that 67MB/sec, I am not yet sure how big the hit is but its minimally 25%. I also use 60ns EDO DRAM in the system and within DRAM you will not achieve that 67MB/sec ever, there's refresh and other aspects that get in the way. Refresh messes up all your timings, nice chunk of performance goes lost into refreshes, though in video applications you can just interleave your data so that the chips never need refresh cycles, but that assumes VRAM access that is all over DRAMs so you can omit refresh circuitry from the DRAM controller and live with slight performance penalty if the accesses aren't properly thought out (random access is SLOW)
Yes, which is why any bus sharing MUST be heavily buffered and handled in long bursts as much as possible (better to end up with more wait states for bus masters than end up with tons of page breaks -of course, some things must have priority and can't wait, like when the framebuffer needs to be scanned -again, a good FPM based system would be buffering a long chunk of the framebuffer into a line buffer, possibly an entire scan line at a time)

Only old/slow systems (into the mid/late 80s) with no facilities for page mode wouldn't have to worry about that . . . they were just stuck with slow random accesses. ;) (like the 250 ns of the ST or 280 of the Amiga)

TmEE

06-10-2011, 02:42 AM

Framebuffer can have some caching done but you only get very few cycles between pixels so even if you cache you don't win much, since you can only cache few pixels before you run out of time... DRAMs suck :P

its most definitely 60ns, all photos of PSX mboos show 60ns DRAMs. 60ns figure is the fastest access you can do on the chip, which is access within a page. EDO is FPM, which slightly reduced access time and that's all.

sounds roughly correct - dont forget Saturn VDP1 also need bandwidth to read drawing commands as well as textures, and loses bandwidth when drawing commands are copied from the SH2 side. PSX drawing commands come from host memory, there's no VRAM side.
I wonder if there is any internal cache for the drawing commands.... ? I don't want to mess with Saturn just yet, I got way too many other things to finish first xD

Crazyace

06-10-2011, 05:51 PM

Albeit there's also the rumor that went around the industry (and in the press) of the Saturn being significantly built-up late in design (usually claimed to be a result of the PSX threat, but it may have been more due to the 3DO/Jaguar and perhaps newer PC games -Sega of Japan was apparently taking the Jaguar's 1993 hype as a serious threat, partially spurring the 32x as well -and preceding "Super Megadrive" project; of course, they also had a good idea of what Nintendo was working with when the SGI partnership was announced -since Sega's own engineers had already scrutinized and critiqued that prototype chipset previously).
Though it they really DID do such a redesign, it was certainly rather sloppy, or at very least not carefully cost controlled. (the earlier design was supposedly primarily built around VDP2 with a single SH1 as the CPU -presumably dual-prupose as CD-ROM controller as in the MCD- with the same sound system, less main RAM, either software rendered "sprites" to VDP2 or -more likely- a primitive incarnation of VDP1 lacking the 3D drawing modes -which could also explain why the warped quad modes have broken "half transparency" effects)

The only thing that seemed 'built up' to me in the Saturn is 1M of the 2M memory - it's a different slower type. VDP1 & VDP2 are totally designed to function together, so only an idiot would suggest that one of them was an 'add on'.

The Saturn's VDP1 seems rather similar to the 3DO's Cel engine in a number of ways, though the Saturn obviously avoids the contention issue by adding a multi-bus video subsystem and uses RAM clocked as fast as the processor too. (but the 3DO has a 32-bit bus to work with, so potentially close to the same bandwidth -not sure how many operations actually supported 32-bit accesses though)
If the 3DO's Cell does actually allow most things in 32-bits (fill, gouraud shading, non-rotated 2D blits) that would get it a lot closer to VDP1 performance on its much slower RAM, especially if it had a 32-bit write buffer for texture mapping. (I doubt it has a 32-bit read buffer though)
If the Cel doesn't so much of anything at 32-bits, the only reason to even have 32-bit VRAM would be for famebuffer scanning bandwidth. (ie for the rather unnecessary/overkill high-res/high-depth modes) A 32-bit write buffer would also make it faster than the Jaguar's peak texture mapping rate even if using VRAM as source and destination.

3DO's Cell draw's in a similar way to VDP1 - but has some nice image quality features ( counterweights to give 'super sampled' feel to some graphics )

Isn't it preferable to use the GPU to build the object lists? (especially in such intensive cases . . . and where the GPU has no overhead for 3D or such)

I thought the Jaguar II allowed triangle rasterization in a single blitter operation (not set up a line at a time like the Jaguar), with just the vertex information needed. (the Saturn's VDP1, 3DO's Cel, and PSX GPU both need separate processors to generate the vextex data too -the GTE is obviously not part of the GPU)

gpu/cpu - they still need b/w to fetch and write data.

Jag II had trapezoidal support - but not arbitary triangles.

kool kitty89

06-11-2011, 02:44 AM

Framebuffer can have some caching done but you only get very few cycles between pixels so even if you cache you don't win much, since you can only cache few pixels before you run out of time... DRAMs suck :P
Run out of time until the next read/write cycle after refresh. (and if you had double buffered scan-lines on-chip with one reading to the screen and the other being filled, there's a lot of flexibility -iirc, that's what the 7800's MARIA did back in 1983/84 with on-chip line RAM to build the scan line from the display list, albeit limited to pretty low resolutions/depths)

its most definitely 60ns, all photos of PSX mboos show 60ns DRAMs. 60ns figure is the fastest access you can do on the chip, which is access within a page. EDO is FPM, which slightly reduced access time and that's all.
OK, then the "60 ns" reference on wiki's DRAM discription is incorrect?
http://en.wikipedia.org/wiki/Dynamic_random-access_memory#Memory_timing

If that IS the case, that means the 133 MB/s figure for the CPU and GPU is false and the RAM used is only moderately faster than the 80 ns FPM RAM used in the 3DO. (or MCD/SVP/32x for that matter)
It also means the PSX was using pretty damn cheap RAM in it on top of the lesser number of buses and individual components and Sony's vertical integration on top of that. (making the cost/price gap a lot wider than I was thinking)

However, the numerous mentions of 133 MB/s DRAM bus connections (including from some PSX programmers) really doesn't mesh with 60 ns DRAM. (it definitely could be EDO DRAM at 33 MHz . . . some PC video cards were using faster EDO DRAM than that around the same time -the original Rage used 40 MHz EDO DRAM)

And I know FPM DRAM is almost the same as EDO (and both asynchronous), but it was my impression that mass market FPM DRAM available maxed out somewhat lower than EDO DRAM.

I wonder if there is any internal cache for the drawing commands.... ? I don't want to mess with Saturn just yet, I got way too many other things to finish first xD
If there is, that would improve flexibility a good bit . . . and also make software rasterization easier. (one of the suggestions of what the jaguar should have had is a blitter command cache to allow the GPU and blitter run in parallel for 3D drawing much more easily)

The only thing that seemed 'built up' to me in the Saturn is 1M of the 2M memory - it's a different slower type. VDP1 & VDP2 are totally designed to function together, so only an idiot would suggest that one of them was an 'add on'.
It really depends how much the system was modified (if at all), but we'll never know the real story unless someone like Sato takes interest in discussing the topic. (or if some of Sega of America's engineers have some information -if anyone, it would probably be Joe Miller)

As for VDP1+VDP2, yes they make sense together . . . but without VDP1 it wouldn't be much different than what NEC did with the PCFX (except the PCFX had the old SuperGrafx sprite+BG engine as well -albeit that would make as much sense as VDP1 being replaced by a modified/doubled MD VDP :p).
Engineering VDP1 at the last minute (ie within the final 10 months before release) is really far fetched, but one more realistic possibility might have been VDP1 being a more primitive incarnation of what is is now, perhaps lacking the 3D (warped) quad drawing modes and just having the 2D "sprite" engine with scaling and rotation support. (rather like an updated derivative of the graphics coprocessor in the MCD's gate array -and a VDP1 like that would assist in 3D rather like the Jaguar's blitter)
Possible evidence for that is the broken half-transparency effect in warped primitives. (total speculation though and very circumstantial)

As for the RAM, I've seen that as "evidence" before, but it doesn't seem like much of a smoking gun to me. (it seems more likely that it was just put in there as cheap auxiliary storage, though the fact that it's only 16-bits wide -in spite of using 2 256kx16-bit DRAMs- is a bit odd -and it would have been just as strange if coupled with the SH1 as the main CPU -though the SH1's SDRAM in the Saturn is also 16-bits wide like in the 32x, but that makes more sense since both cases use a single 16-bit wide SDRAM chip)

This was brought up before a few times, notably here:
http://www.sega-16.com/forum/showthread.php?12743-Did-you-fall-for-the-32X-hype&p=277055 (chilly willy's post about the rumor going around the industry back then)
then a lot more discussion on it here:
http://www.sega-16.com/forum/showthread.php?12743-Did-you-fall-for-the-32X-hype/page12 (mainly between Chilly Willy and me)
Also this rather vague, but interesting press release by EDGE in late 1993

Yes it was around November time, covered in Edge issue 4 1994 [typo, really 1993]. Long after the 1st Saturn tech spec's were leaking out . In Edge Issue 5 the Saturn spec's were as follows (being brief)

Hitachi: SH7032 CPU RISC CHIP Running at 27 Mhz
Memory: 3Mb Ram
Sound: 32 channels, support for PCM and FM
Relase: November 94

Again, if there is any truth to the Saturn redesign (especially if it's anything like the SH1CPU with no VDP1 -or more likely, a 2D only VDP1) probably was not a response to the PSX specifically and probably started earlier on as a response to the poor performance compared to the Jaguar and 3DO (and their related hype), perhaps PC games as well. (and/or the realization that upcoming arcade games would be virtually unworkable)

Such a major redesign should have started by mid 1993 at the very latest.

3DO's Cell draw's in a similar way to VDP1 - but has some nice image quality features ( counterweights to give 'super sampled' feel to some graphics )
The interpolation is nice, but overkill and a bit unnecessary for the time. (forcing things to 480i also limited framerate -not just in terms of peak framerate, but flexibility of a variable framerate -divisions of 30/25 rather than 60/50)
The N64 did that for a handful of games (320x240 interpolated to 640x480) and I honestly don't like it that much. (Episode 1 racer does it in low detail mode, not sure what others -oddly, the intro and title screen are in 240p)

Jag II had trapezoidal support - but not arbitary triangles.
It used warped quads like the 3DO and Saturn then? (which technically can be folded into triangles at the expense of heavily warping textures, screwing up gouraud shading, and cutting fillrate in half due to cosntant 50% overdraw -but sevral Saturn games did exactly that using pre-warped textures to get around one of the problems . . . but I can't help but think a software line by line triangle rastrizer -set up by one of the CPUs and filled by VDP1- wouldn't have been faster overall, definitely for any games where fillrate is the limit and not CPU resource)

Actually, doing a software rasterizer on the Saturn might get around the broken translucency effect since you're rendering in 2D scaled/rotated mode and nor warped mode.

That reminds me: I've seen some conflicting details on what the VDP1 alpha blending bugs cause in warped mode and when they are a problem.
From what I understand, plain 2D modes (1 or 2 point sprites) work fine for "half transparency" and VDP2 BG alpha blending effects work fine with everything (which makes sense since they're totally separate and treat everything on the VDP1 buffer as plain pixels with no added information other than priority -which might include alpha layer information in some modes, not sure), so that leaves problems with VDP1 objects and other VDP1 objects.
It's my impression that any 2D sprites over any other part of the framebuffer can use half transparency properly, but warped primitives (with or without texture) will not work for that effect. (either they show up as solid objects or show garbage when transparency is enabled, I'm not sure)

That reminds me:
I've read over a lot of the Jaguar manual, but I don't seem to remember mention of alpha blending/translucency/"transparency" effects for the blitter or object processor being mentioned.
Does the jaguar support any alpha blending effects in hardware? (be it in CRY or RGB modes )

Oh, and I made a stupid mistake with that comment on the Slipstream's "color hold" mode . . . you can still use normal bitmap graphics, you just need to cater to the specifics of that mode. (and not leave any framebuffer regions left as 0s that you don't what to get filled according to color hold -all it does is repeat the last color scanned in the line as long as 0s are encountered and changes to another color when a non-0 pixel is encountered -so if you wanted to genlock over another screen, you'd need to include "transparent" as one of the indexes above zero and limit total color count to 14 or 254 depending on the mode)
So it's just about as flexible as the 32x's RLE mode, but works a bit differently. (and probably requires less bandwidth and logic complexity in the video controller than RLE -which uses 16 bit values to set an 8-bit color and then an 8-bit count for pixel run-length)

TmEE

06-11-2011, 04:32 AM

The only thing that seemed 'built up' to me in the Saturn is 1M of the 2M memory - it's a different slower type. VDP1 & VDP2 are totally designed to function together, so only an idiot would suggest that one of them was an 'add on'.
Yes exactly, that slower type of RAM is really slapped on the design, when you look at Saturn schematics you see its hacked on there, like a tumor. Note says its only for holding data not running code.

I did take a look at DRAM specs and tried to find the type used in PSX and seems there's FPMs in use not EDO. I messed up in page cycles, and on EDO they can be quite fast, 25ns, but on FPM is 45ns, so it will raise the possible bandwidth to 22MB/sec per chip. Only overhead is initial and final parts of the access, so accesses need to be long for them to be minimal.

EDIT: I may have been looking at wrong kind of RAMs there... the 4 chips are 512KB and that is 2MB total which means they're main RAM not VRAM. VRAM is single 1MByte "synchronous GRAM" chip. Looking its properties up right now... definitely something expensive and exotic.
Seems to be 32bit SDRAM with 2 banks, and and that case, yes 133MB/sec figure is all good.
Looks like a quite fancy chip in the datasheet. PSX is saved by the 32bit bus of VRAM, that gives it double. The chip allows for much higher speeds than 133MB/sec though, I guess its not used to its fullest then. Its 12ns, with 2 or 3 cycle latency setting for up 55MHz or 83MHz operation, the 133MB/sec figure suggests the chip is ran at only 33.x MHz (probably the 33.8688MHz).

Crazyace

06-11-2011, 04:50 AM

KoolKitty,

JagII did not use warped quads - just trapezoids with flat top/bottoms ( so 2 would be needed for an arbitary triangle ) - it's just a slight modification to the blitter - the lynx also could draw trapezoids :)

TmEE,

The PSX supported 133MB/s bursts on both main and video memory, so you are probably just reading the chip specs wrongly. ( Every company always quotes peak figures though :) )

TmEE

06-11-2011, 05:08 AM

On main RAM I cannot really see 133MB/sec happening, that would assume single cycle access on the memory, but that is not possible on such DRAM. 133MB/sec inside a (CPU) cache is definitely plausible
on VRAM its definitely possible to get that 133MB/sec and beyond, and not even just burst accesses. I do see VRAM being clocked at 67MHz to minimize overhead on SDRAM commands etc., judging from the datasheet of the SGRAM chip there's quite a lot of empty wait cycles

Crazyace

06-11-2011, 05:41 AM

As I said - 133MB/s burst ( 1 transfer/cycle ) do happen during DMA -that is a fact.

TmEE

06-11-2011, 06:06 AM

Then the DRAM has to be EDO not FPM, (and DRAM controller has to run faster than CPU does)

Crazyace

06-11-2011, 09:25 AM

It was always described as SDRAM, so that's what I assumed it was.

TmEE

06-11-2011, 11:10 AM

I meant main RAM, that would have to be EDO if it was also supposed to peak at 133MB/sec. VRAM is SGRAM and that solves all the mystery on that side.

kool kitty89

06-11-2011, 11:31 PM

KoolKitty,

JagII did not use warped quads - just trapezoids with flat top/bottoms ( so 2 would be needed for an arbitary triangle ) - it's just a slight modification to the blitter - the lynx also could draw trapezoids :)
If you used 2 trapezoids for 1 tri, wouldn't that lead to a similar overdraw/bandwidth headache as folded quads in the Saturn? (compared to plain GPU assisted rasterization)

Did the Jaguar II add a blitter command cache as some (I think it was gorf) suggested the jag should have had? (which I interpreted as a buffer to hold commands independently from main RAM or the scratchpad)

The PSX supported 133MB/s bursts on both main and video memory, so you are probably just reading the chip specs wrongly. ( Every company always quotes peak figures though :) )
That would imply main memory was definitely EDO or SDRAM then. (for 29 ns operation)

I meant main RAM, that would have to be EDO if it was also supposed to peak at 133MB/sec. VRAM is SGRAM and that solves all the mystery on that side.
Ah, OK, so probably more expensive than the Saturn's video memory (at least for raw components -ie not PCB trace count/and logic costs of more buses/banks, but also narrower buses- and not considering Sony's vertical integration). That would also mean video wouldn't need special buffering (dual pages could be open and RAM could be clocked at 2x the bus speed with interleaving for framebuffer and GPU accesses, or it could have a bunch of buffering too and use the dual pages to generally reduce random accesses for GPU operations)
The jaguar supported such 2-page interleaving support via 2 banks of DRAM chips, but that was left unused due to cost reasons. (and RAM wouldn't have been 2x the GPU/blitter/OPL speed either, but 1/2 the speed, so such interleaving would only help for reducing page breaks and bandwidth for some less buffered operations and not increase peak bandwidth)

And, like the Saturn (and 32x) the chips are clocked way below their capable speeds. (unless the 2-page interleaving option was employed with SGRAM at 66 MHz -which would technically mean more than 133 MB/s if you included framebuffer bandwidth, just like the 3DO's VRAM would be more than 50 MB/s peak)

If main memory looks like FPM chips that definitely would be odd given the apparent speed.

Oh, and would the use of SGRAM make my impression of performance levels in the PSX GPU (relative to Saturn) realistic?

Crazyace

06-12-2011, 02:29 AM

If you used 2 trapezoids for 1 tri, wouldn't that lead to a similar overdraw/bandwidth headache as folded quads in the Saturn? (compared to plain GPU assisted rasterization)

Did the Jaguar II add a blitter command cache as some (I think it was gorf) suggested the jag should have had? (which I interpreted as a buffer to hold commands independently from main RAM or the scratchpad)

No overdraw - the trapezoids have horizontal top/bottom - so they go on different lines to make a triangle. The JagII did add double buffering to the blitter registers ( not a command cache, but it effectively allowed set up to be pipelined. ) - just have a look at the midsummer doc - it lists the differences between Jag II and I.

kool kitty89

06-15-2011, 02:36 AM

No overdraw - the trapezoids have horizontal top/bottom - so they go on different lines to make a triangle.
Hmm, so more flexible than the Saturn/3DO's quads (which would suffer roughly 50% overdraw for triangles and deal with excessive texture warping issues and ruined gouraud shading) while still cutting back overhead somewhat over plain line by line rasterization. (which the Saturn and 3DO could both do too, though the 3DO's CPU was probably too choked to ever make that more attractive than folded quads)

The JagII did add double buffering to the blitter registers ( not a command cache, but it effectively allowed set up to be pipelined. ) - just have a look at the midsummer doc - it lists the differences between Jag II and I.
OK, I'll take another look at that.

On a somewhat different note, there's another thing I asked about the Jaguar on AA a while back (I think over a year) and never got a response to.
That's this comment about a "double data rate" mechanism in the jaguar that wasn't used in the final system:

The original design for the Jaguar was that it was actually going to be a 128bit computer, it wasn't going to be 64bit. We felt we had the pins to do it. We were going to have 2 banks of memory at 64bits and do double data rate and achieve a 128 bit architecture on 64 pins. It was really pushing it - but in the end the economics said that 128 wasn't necessary and it would have been too expensive.

Is that just referring to the 2-bank interleave feature of the Jaguar, or something more than that?

I'd thought the interleave support was limited to holding 2 pages open (1 in each bank) and reducing page breaks by allowing different bus masters to work in different banks or for unbuffered operations where separate source and destination banks are helpful (like with the blitter).
However, maybe they did something even more useful (or planned to) that would actually allow 2x the bandwidth over 64-bit RAM at that speed by allowing consecutive pairs of 64-bit reads without wait states or with fewer wait states for random accesses.

Of course it would definitely add to cost by way of needing double the number of DRAM chips (or quadruple for 2 MB -since 32-bit wide DRAMs weren't available in 1993 and you'd need 16 256kx4-bit DRAMs instead of 4 256kx16-bit ones; 1 or 4 MB would have only needed 8 chips) and more traces on the board to connect those chips.

Crazyace

06-15-2011, 03:43 PM

Hmm, so more flexible than the Saturn/3DO's quads (which would suffer roughly 50% overdraw for triangles and deal with excessive texture warping issues and ruined gouraud shading) while still cutting back overhead somewhat over plain line by line rasterization. (which the Saturn and 3DO could both do too, though the 3DO's CPU was probably too choked to ever make that more attractive than folded quads)

Not really more flexible - it's just another step along the way to full triangle rasterisation. As it's scanning the source though it's not going to hit destination pixels more than once.
In some ways the quads are more flexible, as the distortion is less in some cases, and you can generate 'bow tie' poly shapes that give the impression of curves. ( With the jaguar blitter, or jag II blitter, you could render quads directly to avoid the middle triangle seam problem seen on PSX games )

Crazyace

06-15-2011, 03:48 PM

On a somewhat different note, there's another thing I asked about the Jaguar on AA a while back (I think over a year) and never got a response to.
That's this comment about a "double data rate" mechanism in the jaguar that wasn't used in the final system:

Is that just referring to the 2-bank interleave feature of the Jaguar, or something more than that?

I'd thought the interleave support was limited to holding 2 pages open (1 in each bank) and reducing page breaks by allowing different bus masters to work in different banks or for unbuffered operations where separate source and destination banks are helpful (like with the blitter).
However, maybe they did something even more useful (or planned to) that would actually allow 2x the bandwidth over 64-bit RAM at that speed by allowing consecutive pairs of 64-bit reads without wait states or with fewer wait states for random accesses.

Of course it would definitely add to cost by way of needing double the number of DRAM chips (or quadruple for 2 MB -since 32-bit wide DRAMs weren't available in 1993 and you'd need 16 256kx4-bit DRAMs instead of 4 256kx16-bit ones; 1 or 4 MB would have only needed 8 chips) and more traces on the board to connect those chips.

Not sure if that made it into the hardware at all - it sounds like the Flare guys wanted a 128 bit internal bus ( so the blitter / OP / and gpu would run at twice the bandwidth ) I guess that they would have connected dram's in parr. and enabled one 64bit set on a even cycle, and another on an odd cycle.

Pras

06-15-2011, 04:17 PM

This is very good Thread.

Can anyone make some matrix-list for the above discussion so that people can get the summary, and easily to comprehend the issues.

I just know recently that Genesis is only capable to play a cartridge with maximum 40 Mbits or equivalent with 5 Mega bytes (Super Street Fighter CE).
And Neo Geo can play up to 330 Mbits or around 40 Mega bytes.

kool kitty89

06-15-2011, 04:50 PM

Not sure if that made it into the hardware at all - it sounds like the Flare guys wanted a 128 bit internal bus ( so the blitter / OP / and gpu would run at twice the bandwidth ) I guess that they would have connected dram's in parr. and enabled one 64bit set on a even cycle, and another on an odd cycle.
OK, so it probably got cut back early on (otherwise there would have been a fair amount of wasteful vestigial logic left in it). That would have been interesting to implement for the Jaguar II. (though they also seem to have been considering the opposite direction with the mention of 16-bit SDRAM clocked at 2x the custom chips speed -except that would also have a much bigger page change penalty than slower RAM on a 64-bit bus, one of the major bottlenecks of the N64 and PS2 . . . and SDRAM would have still been quite expensive at that time, though EDO DRAM would have become much more affordable)

Anyway, given what Kskunk mentioned, the 2 bank interleave feature wast at least retained in the final chipset (but not implemented), but it seems unlikely that 128-bit logic was implemented.
However, depending on the complexity of that interleaving mechanism, it could have still been useful for boosting more than just page break reduction, but perhaps allowing Amiga/ST style interleaving but in fast page mode. (which could have allowed the 68k to run full bore and still leave 50% of bandwidth for page mode read/writes, though realistically less than that due to page breaks and not even being able to cram a single random access within the "free" portion of a 68k bus cycle -and in that sense, it might be most efficient to assert wait states on the 68k to keep average bandwidth as high as possible)

Albeit, that's still a ton of bandwidth (or bus time rather) eaten up, and if they'd really wanted the 68k to be a useful full-time processor in the system, a separate slow bus for the 68k (and probably DSP) would have made a lot more sense. (especially since super cheap, bottom bin DRAM could have been used . . . and had they planned that, JERRY could have sported its own DRAM/memory controller, and might have actually avoided some of the bottlenecks it suffers now) Though if that sort of change was made last-minute, the only options would have been SRAM/PSRAM for such a dedicated bus. (so not especially cheap, but maybe realistic for something like 64-128k of local memory . . . still slow RAM, so the lower end of PSRAM/SRAM on the market -an added external local scratchpad also could have accelerated texture mapping substantially for the blitter, though that would really need faster RAM and not the totally bottom-end stuff, though even common 100 ns SRAM would have helped significantly)

Putting the cartridge on that same slow bus (or a bank select mechanism to toggle the cart bus) might have made more sense too. (more attractive to work in ROM without hefty bus time penalties and relatively limited wait states for the 68k -and JERRY if its memory interface was still bugged and stuck at 6 cycle reads)
For that matter, mapping ROM to the interleaved 2nd memory bank would help somewhat. (unless ROM is already treated as a separate bank with such interleaving support -or at least not inducing page breaks in DRAM, but better would be actual interleaved RAM accesses crammed within a ROM access cycle time, which might allow 1 random access or several page mode accesses without delaying the ROM access)

That reminds me: Kskunk also mentioned that Jaguar cards specifically use 375 ns ROM (which was cheap, bottom-bin ROM around the time of its release), but is that a fixed figure, or was it programmable (or at least hackable)?
Making it fixed to that seems rather bad foresight given faster ROM would be getting cheap all the time, and certain developers might want to use faster/expensive ROM for certain games too (or a mix of fast and slow ROMs -like a small fast ROM for code and a slow one for bulk data).

NEC had been using 140 ns ROMs from day 1 in 1987 with the PC Engine, granted they had vertical integration facilitating that to a huge degree, and Nintendo started off with 375 ns ROMs in 1990 and later introduced 280 ns (which is as fast as the SNES supports) while the Genesis seems to also have gotten faster over the years. (to the point of allowing interleaved Z80+68k access without wait states in later games)

The same would be true for the lynx, at very least for allowing faster DMA updates to RAM. (though facility for the CPU or blitter to directly work in ROM would have been very useful, reducing RAM used, enhancing use of fast page mode for textures pulled from ROM and written to RAM -more so when 250 ns ROM became affordable/practical as there would be no wait states at all, or more still if ROM had actually been configured as a separate bus from RAM and thus allowed fully parallel operation when CPU was in ROM and blitter in RAM -with contention when either needed to access the other bus/bank, of course)
IIRC, the lynx was originally designed around the idea of using tapes (or similar media) to load games from, so such provisions wouldn't have made sense from that perspective.

Crazyace

06-16-2011, 02:26 AM

Rom is a seperate bank on the jaguar, and having slow rom isn't as important as most titles would decompress from rom to ram.

kool kitty89

06-17-2011, 05:41 AM

Rom is a seperate bank on the jaguar, and having slow rom isn't as important as most titles would decompress from rom to ram.
Yes, but making faster ROM optional (let alone possibly on-cart RAM) could allow much higher bandwidth for on the fly updates (including decompression) to RAM in addition to cases where it would be attractive to read directly from RAM. (code can't usually be compressed, so reading non-modifiable code from ROM would make sense in some cases)

In the case of the 68k and DSP, the bus width of the cart would be an issue (all are at least 16-bits) and only a moderate speed boost would be needed for full bandwidth (300 ns for the 68k, 225 for the DSP). So both could be running code and pulling read-only data from ROM and reducing page breaks at that (or potentially even allowing some interleaved page mode accesses within 68k or DSP read cycles).

That would be great for compressed sound data (various flavors of ADPCM, CVSD, etc) too, something that could easily be done on the fly and also not even need to occupy RAM (as it is, you WOULD want to leave it compressed when loaded to RAM just to save space).
Simple RLE compressed graphics would also apply, and perhaps some other lossless schemes.

And then there's the extreme cases where you'd sacrifice cost to boost performance with added RAM on cart and/or use of uncompressed (or very basic compression like RLE) graphics in fast ROM to boost blitting (especially texture mapping) speed with separate source and destination. (Chilly Willy's current Yeti 3D demo on the 32x does just that with uncompressed 256 color textures in ROM . . . and I think it's assumed to be ROM as fast as 32x SDRAM too -43 ns, not sure -and I'm not sure if the SRAM/PSRAM current flash carts actually runs that fast either, and I'm not sure how emulators treat ROM either)
Doom may have used a similar mechanism to get things working with the 32x's limited RAM, though it also may have uncompressed a fair amount into SDRAM (and maybe some into spare framebuffer space).
The GBA version of Doom almost certainly did that. (8 MB of ROM, fast ROM too)

Hmm, though in the case of practicality in the time of the Jaguar, a chunk of fast SRAM on cart (perhaps 75 or 37 ns with 32 or 64k at 8 or 16-bits) with normal cheap ROM used would have been more realistic. (still adding a bit to cost, but hey, probably proportionally a hell of a lot less than the 32 kB of SRAM used in Summer and Winter games back in 1987/88 on the 7800 ;)) That's in the context of using as a fast texture buffer of course . . . except it would have made a lot more sense just to tack on a bit of SRAM internally (preferably mapped as external local RAM for TOM, but at least into the 2nd main RAM bank) if they'd recognized the increased importance of texture mapping by 1993. (even a single 32kx8-bit SRAM would be very useful for speeding up texture mapping, though 16-bit would be more flexible . . . and even bottom-end 100 ns SRAM would have helped a lot over just DRAM+GPU local, though 75 or -especially- 37 ns would be much better)

Hell, if it was mapped to the 2nd main RAM bank, it could also be employed as DSP/68k work RAM, with some fairly flexible interleaving thanks to it being SRAM too. (and given it's simple to interface SRAM, it might have been feasible to allow that to be configured as an independent local bus for the DSP/68k that could be toggled back to main as needed . . . or have both a DSP/68k local and extended external local RAM, but that's more cost still)

There's PSRAM too, which would definitely be cheaper (though harder to find a source for), but also not potentially as fast as SRAM. (a non-issue for 68k/JERRY local though) Albeit, a much more cost effective long-term option (at least for JERRY/68k hogging main) aside from a different CPU (or additional caching -which may not have even been possible in the time/funding/technology constraints -including die space) probably would have been a local bus for JERRY+68k using DRAM (had that actually been planned, probably with the DRAM controller/interface embedded in JERRY), but that wouldn't have been practical as a "last minute" hack. (aside from using off the shelf logic for the DRAM interface and more board space an traces . . . though that could be consolidated in later revisions)

Crazyace

06-17-2011, 04:02 PM

Yes, but making faster ROM optional (let alone possibly on-cart RAM) could allow much higher bandwidth for on the fly updates (including decompression) to RAM in addition to cases where it would be attractive to read directly from RAM. (code can't usually be compressed, so reading non-modifiable code from ROM would make sense in some cases)

In the case of the 68k and DSP, the bus width of the cart would be an issue (all are at least 16-bits) and only a moderate speed boost would be needed for full bandwidth (300 ns for the 68k, 225 for the DSP). So both could be running code and pulling read-only data from ROM and reducing page breaks at that (or potentially even allowing some interleaved page mode accesses within 68k or DSP read cycles).

That would be great for compressed sound data (various flavors of ADPCM, CVSD, etc) too, something that could easily be done on the fly and also not even need to occupy RAM (as it is, you WOULD want to leave it compressed when loaded to RAM just to save space).
Simple RLE compressed graphics would also apply, and perhaps some other lossless schemes.

I dont think fast rom would be needed for compressed data - after all it's compressed, so reading it would need less b/w than writing the compressed data to ram

And then there's the extreme cases where you'd sacrifice cost to boost performance with added RAM on cart and/or use of uncompressed (or very basic compression like RLE) graphics in fast ROM to boost blitting (especially texture mapping) speed with separate source and destination. (Chilly Willy's current Yeti 3D demo on the 32x does just that with uncompressed 256 color textures in ROM . . . and I think it's assumed to be ROM as fast as 32x SDRAM too -43 ns, not sure -and I'm not sure if the SRAM/PSRAM current flash carts actually runs that fast either, and I'm not sure how emulators treat ROM either)
Doom may have used a similar mechanism to get things working with the 32x's limited RAM, though it also may have uncompressed a fair amount into SDRAM (and maybe some into spare framebuffer space).
The GBA version of Doom almost certainly did that. (8 MB of ROM, fast ROM too)

Hmm, though in the case of practicality in the time of the Jaguar, a chunk of fast SRAM on cart (perhaps 75 or 37 ns with 32 or 64k at 8 or 16-bits) with normal cheap ROM used would have been more realistic. (still adding a bit to cost, but hey, probably proportionally a hell of a lot less than the 32 kB of SRAM used in Summer and Winter games back in 1987/88 on the 7800 ;)) That's in the context of using as a fast texture buffer of course . . . except it would have made a lot more sense just to tack on a bit of SRAM internally (preferably mapped as external local RAM for TOM, but at least into the 2nd main RAM bank) if they'd recognized the increased importance of texture mapping by 1993. (even a single 32kx8-bit SRAM would be very useful for speeding up texture mapping, though 16-bit would be more flexible . . . and even bottom-end 100 ns SRAM would have helped a lot over just DRAM+GPU local, though 75 or -especially- 37 ns would be much better)

The fastest bus access is 2 cycles ( for the test rom mode ) , which isn't as fast as accessing the internal memory - most of the fast graphics routines on Jaguar rely on drawing to internal ram in pixel mode ( a 32x32 16bit pixel texture in main ram would fit into a page , so no read page breaks ), then writing the line back to screen ram in phrase mode. And for normal sprite use the Object processor already fetches data in phrases - so any fast rom wont be as fast due to only being 32bit wide at max.

Fast rom memory won't help the 68k and Jerry though - both of them have poor access times regardless , which is unfortunate.

Bastardcat

06-17-2011, 10:00 PM

Technical jargon aside, I always thought that PS1 games had a cleaner look than N64 games. That "texture filtering" almost always led to very muddy, blurred textures, that on the PS1 looked crisp, albeit pixelated. In that regard, the more powerful graphics hardware of the N64, isn't that superior. I mean look at Doom-64. Very pretty shiny game, but everything has that ugly blurred look. The game would have seriously benefited from them turning that blasted filter off.

kool kitty89

06-18-2011, 03:00 AM

I dont think fast rom would be needed for compressed data - after all it's compressed, so reading it would need less b/w than writing the compressed data to ram
Yes, but the faster ROM would mean less time contending for the bus (had ROM been on a separate bus entirely and not a separate bank, that would be a different issue -the 32x does that, toggles ROM between the Genesis and 32x buses, among other separate buses).
Of course, if we're talking JERRY accesses, any faster than 225 ns would be unnecessary.

Though I suppose the wait states inserted for ROM accesses could be used for added DRAM accesses by other bus masters too, if the memory interface was set-up to facilitate that. (and ROM, like SRAM -but unlike DRAM- could have the data held open as long as necessary -without having to wait for another ROM access cycle to complete, so additional waits could be inserted if a DRAM access has priority)
Still, with such waits would tend to mean more wasted cycles for the processor accessing ROM than it would for ROM that could respond as fast as said processor.

Hmm, though even with slow ROM, the fact that ROM can be held for an access indefinitely (unlike DRAM) would make for rather flexible bus sharing. (say for an example where the 68k works mainly in ROM, with interleaved fast and random accesses employed as possible -with additional waits forced on the 68k when added bus time is needed, just like normal DRAM sharing, except perhaps even fewer waits for the 68k to deal with since it could have the ROM held ready rather than waiting for a DRAM access)
Hell, for ROM (or SRAM) you also wouldn't need to leave as much time for the 68k's actual access on the bus as the memory would be able to respond immediately after the wait states ended (rather than DRAM being rather screwy), so nearly the entire first 3 cycles (plus wait states) for a given 68k access could be usable while it's working in ROM. (or SRAM, hypothetically)

The fastest bus access is 2 cycles ( for the test rom mode ) , which isn't as fast as accessing the internal memory - most of the fast graphics routines on Jaguar rely on drawing to internal ram in pixel mode ( a 32x32 16bit pixel texture in main ram would fit into a page , so no read page breaks ), then writing the line back to screen ram in phrase mode. And for normal sprite use the Object processor already fetches data in phrases - so any fast rom wont be as fast due to only being 32bit wide at max.
Hmm, so you mean buffering the destination block (32x32x16 would "only" use 1/2 the scratchpad) and then quickly copying that out to the framebuffer as 64-bit phrases? (or obviously smaller than 32x32 depending on the area being drawn)

Still, having a 75 ns SRAM buffer to work from would mean a 75 ns read and a 75 ns write (to DRAM in FPM) for each pixel rather than a similar number of 75 ns reads and 37 ns writes to the scratchpad followed by 4 pixel phrase reads ad 37 ns and 75 ns writes (ignoring the initial page break and possible contention)
So significantly more useful for some things . . .
Edit: nevermind, it looks like the local RAM buffer method is faster than a 75 ns external local could facilitate. (at least if my rough calculations are accurate . . . and they don't take buffer clearing time into account -which would probably still favor the on-chip local option even more- though using an external local buffer AND the on-chip local would reduce contention for main)

Though you could certainly argue that any added SRAM (or PSRAM) hacked in would have had much better value as 68k and/or JERRY local memory . . . or maybe DRAM as a 68k and/or Jerry local would be doable as a late development hack, perhaps just tacked on discrete logic (for early revisions) for a local bus that only the 68k and/or Jerry could access and requiring one of those 2 to access main to get added code/data -it would have only needed to be a slow bus too no FPM support even. (obviously that could be less attractive if it was more costly than using a 68EC020 . . . or perhaps a Cyrix 486SLC -or IBM SLC if it complied with the Intel contract- or DLC but those would obviously be more costly -the EC020 should be cheaper on a technical level, but there's a lot more than technical issues involved with pricing -especially directly compatible competition, of which Motorola had none for post 68k chips due to their monopolistic practices)
Or then there's things like possibly overclocking a 16 or 20 MHz 68k to 26.6 MHz if that proved stable with a large enough volume of 68ks they were getting. (or select a master clock -or second oscillator- that could allow close to 20 MHz for nominally available 68ks of the time, or even 16.7 MHz would have been a moderate boost -which would also have been notable if they'd used a 16.7 MHz EC020)

Fast rom memory won't help the 68k and Jerry though - both of them have poor access times regardless , which is unfortunate.
VERY fast ROM won't help, but 300 ns would mean no wait states for 68k ROM accesses and 225 ns would mean none for JERRY. (aside from wait states induced by bus sharing with other masters)

Technical jargon aside, I always thought that PS1 games had a cleaner look than N64 games. That "texture filtering" almost always led to very muddy, blurred textures, that on the PS1 looked crisp, albeit pixelated. In that regard, the more powerful graphics hardware of the N64, isn't that superior. I mean look at Doom-64. Very pretty shiny game, but everything has that ugly blurred look. The game would have seriously benefited from them turning that blasted filter off.
Some games aren't stylized well for filtered textures, others are (and some are stylized for limited use of textures in general), but there's also the huge issue of limited ROM space contributing to very low res textures.

The Dreamcast and all later consoles used similar filtering, as did many PC games in the mid late 90s, but all of those had better than PSX quality textures (or some closer to par with PSX), unlike the N64.

I'm not sure if Project 64 supports disabling filtering, but that would give some insight into what games might have looked like. ;)

Mega Man legends is a good direct comparison. Looking side-by-side, it's not just the blur (and perspective correction) that is noticeable on the N64, but also a rather substantial loss in resolution and texture detail compared to the PSX. (almost like comparing 32x Doom's textures to the PC version -except those didn't have the res cut back so much as sheer detail an texture count)

Crazyace

06-18-2011, 05:57 AM

kool kitty89

06-18-2011, 11:29 PM

I think that the problem's you are trying to solve seem to involve massive changes of the jaguar architecture - it doesn't have a seperate bus after all. If this is a comparision of 5th gen machines they have to be 'real' 5th gen machines, not imaginary 'perfect' redesigns...
What I'm commenting on are more hack-ish options . . . a "perfect" example would be far, far better and more in line with the jaguar 2's design philosophy. (but within practical 1993/1994 limitations . . . well Atari's funding/resources limited that a lot more anyway)
Perfect (within realistic limits of the jaguar's cost) for 1993/94 would have been knowing texture mapping was extremely important and dropping Z-buffering in favor of much more heavily buffered blitter support (Kskunk explicitly mentioned that the Z-buffer logic took up more than would be needed for a 64-bit source and 256-bit destination buffer), invest enough in trouble shooting to kill all the major bugs, plan to use the J-RISCs as the main CPUs (with tools to match -recognizing the importance of C support on top of low-level documentation -don't push libraries too hard like 3DO though ;)) and able to boot the system, have JERRY's memory interface like TOMs with 64-bit DMA and no added waits, and try to have a dynamic cache on at least one of the RISCs (like making JERRY more like the RCPU in the Jag II). Probably include a basic DMA sound mechanism for JERRY as well (rather than bare DACs) and get the internal DACs functioning properly. (in hindsight, intensive DSP-type sound was rather unnecessary in general and JERRY was rather wasted in the actual Jaguar, but using it in an RCPU type role would have changed that dramatically . . . and if they couldn't get the added funding/time/resources to pull off an RCPU type chip, dumping JERRY altogether would have been more cost effective -use a much smaller/simpler ASIC with DMA sound+UART and a much more powerful/flexible CPU -an ARM3, ARM610 or Hitachi SH RISC probably would have been among the most cost effective of the time from Atari's perspective . . . R3000 probably would have cost more and 68020/030 or x86 chips were generally lower cost/performance -well definitely lower in terms of manufacturing cost, but actual market price for bulk orders isn't always directly expressed in manufacturing cost, iirc Cyrix and AMD chips were generally at much lower margins than later gen motorola or most intel chips though ARM or Hitachi parts might have been more attractive still for parts aiming explicitly at embedded applications)

What I was suggesting was a more last minute hack to add a local bus for the 68k (or maybe shared with JERRY) that was outside of the main bus and not accessible (or visible) to TOM at all, but only to the 68k and maybe JERRY. (though probably most feasible to do it only for the 68k -especially due to therather tight-knit nature of the Jaguar in General) If not a full local bus, perhaps an external cache/buffer set-up like the MSTE and various 68k accelerators used on the ST.
Now, if such a local bus or external cache/buffer ended up costing more than a 68EC020 (or maybe SLC x86 chip, let alone better value/embedded market RISC options), that obviously wouldn't be an attractive option.
Or even a faster CPU without a cache or local bus, but fast enough to be much more useful than the 68k. (like the ARM60 of the 3DO -the SH1 also lacked a cache but had versions with up to 8k scratchpad at launch . . . and an embedded DRAM interface among other things)

In the existing Jaguar, the CPU was the only really flexible option without modifying the custom chips internally (I think Kskunk referred to the tightly meshing design as fitting in as pieces of a puzzle, with the exception of the CPU), well that and having lots of provisions for more RAM and the dual banks.

However, hardware alone (or tools to match) only goes so far . . . it could be the saving grace for a company in deep trouble (and in some respects, the Jaguar was exactly that for Atari -a very tight, efficient, cost effective design that almost game them a fighting chance on the mass market) or the icing on the cake for one on top, but other factors are usually far more important (funding, management, marketing, price point -though that could be part of marketing, brand recognition and market confidence -consumer, developer, and retailers committing with good faith that the product will do well- etc, etc -in the end, market share and software support are key, but how you get those 2 things is the real issue)

In the PSX's case, hardware and tools were really icing on the cake, as was the relatively low cost (compared to Saturn at least) and extensive vertical integration on top of all that.
In very few cases is hardware the deciding factor . . . though the PC-FX might be among those. (and the mangement decisions leading to its release) NEC is the perfect counter example to Sony: with the PCE/TG-16 they had tons of money and considerable vertical integration (like Sony in 1995), but bad management (and perhaps an unwillingness to exploit that money) killed their US market and led to Europe not getting any release at all. (the 3DO is pure market model mismatch, if it had been marketed like normal consoles -let alone the PSX- it might have been a very powerful 5th gen competitor)

In hindsight, Atari was lucky to get as far as they did in the US . . . investing private funds and/or borrowing a lot more from creditors/investors might have gotten them further but also probably would have ended up digging them (or Atari Corp, at least) deep into debt only to have Sony steal the mass-market position before Atari could recoup their investments. (sort of like Sega with the Dreamcast . . . though that's a more complex issue with other factors)

By 1993, not onyl was Atari in deep monetary trouble, they had a rather weak brand name in North America (7800 had done OK -better than the Master System, but was rather low-key and also basically dead by 1991 -close to it in 1990, and they had no 4th gen console but they did have the Lynx which went -more or less- nowhere fast in the US where the handheld market was also lower key and lower profit than home consoles -Atari obviously couldn't break into Japan/Asia unless maybe licensing to a recognized regional distributor, and the ST was niche in the US at best and almost dead by 1991 as well, but Europe was another story for them ;))

Their European market probably also suffered from lack of a 4th gen Atari console, and the ST was declining in the early 90s, but Atari definitely had a MUCH better image in Europe than the US with much more recent PR to build onto. The ST had dominated the 16-bit market up until almost the end of the 80s and still was notable into the early 90s. The Lynx had done quite well in Europe and outsold the Game Gear by a wide margin. (it was the definitive "deluxe" handheld console in the region)
On top of that, Europe also was far more competitive through viral marketing (denser population, more popular magazine publications for games/computers, etc), so even with Atari's problems by 1993, they could have had a fighting chance in establishing the Jaguar in Europe. (actually, if you look purely from the EU perspective -which was almost Atari's only market by 1992, they probably should have dropped the ST/Falcon and definitely not tapered off on Lynx support like they did -pulling back in North America definitely made sense, but Europe had far more continued sales potential and was far less costly to operate in)

However, Atari did discontinue the ST line, did start weakening Lynx support, and stupidly ignored Europe with the Jaguar until it was too late to matter. (the US-specific test market in 1993 might have been more sensible due to the greater potential for investment in the US -though one could argue some European manufacturers/suppliers/investors might have worked well enough, but in any case they should have pushed European distribution heavily in 1994 and definitely had a steady, shortage-free supply line to major regions in Europe before the end of summer)

It's rather ironic that Jack Tramiel was willing to divert ST supply to Europe in times of shortages (with US distribution suffering) in order to maintain their more prominent market, but Sam did the exact opposite with the Jaguar.
Hell, several UK/EU gaming/computer mags were hyping the Jaguar quite positively early-on (and it got some rather notable spots on Bad Influence), but the shortages and general lack of support (through most if not all of 1994 iirc) basically killed their chances in the market.

Hell, they also had the budget attraction to the system, though such pricing wasn't nearly as important in Europe as it had been in the late 80s, it was still notable and with the Jaguar's low-cost design, it could have filled the budget niche quite nicely in the long run. (even with Sony's price war deflating the prices of the Saturn and N64, it would have beensignificant)
And not to mention the large portion of good software houses in Europe, especially if Japanese support wasn't attainable.

It's like the hindsight discussions about what was wrong with the Saturn - nothing was wrong, it was designed to be state of the art for the kind of games popular in arcades, and it also handled 3D pretty well.
Yeah, except Sega also knew where the market was going (a good deal of foresight at least -including review of the SGI chipset in its early form), more so than Flare by a good margin (the jaguar was started a lot earlier), Sega had a lot more resource to work with too.
They also dropped the backwards compatibility trend, but that was less of an issue in the long-run.

However, beyond the actual feature set of the hardware (which really WAS quite reasonable for the time), there's the real issue of odd design, the manufacturing cost.
The way the Saturn is designed wasn't just cost-ineffective in some areas (ie same performance could have been done at much less cost with more intensive engineering), but its actual manufacturing cost was unrealistically high. (a design that had some significant inefficiency, but was still realistically cheap would have been much better)

Sega obviously knew the home market, they must have known the price sensitivity there, yet they (or SoJ management, rather) opted for a very expensive design that was a total mismatch for the mass market of the time.
The Saturn was worse than the 3DO in that respect . . . well not so much in price (3DO was heavily inflated by the business model . . . though was never more expensive than the Saturn's market price at any given time ;)), but the design itself (wile far more conservative and less cost effective than the likes of the Jaguar) was still far simpler and cheaper than the Saturn. (the Saturn, aside from VDP2 at least, was actually much like the 3DO if it had totally thrown practical cost to the wind and used very fast RAM with multiple video buses/banks and much more powerful CPU(s) -though if the Saturn was sold like the 3DO, licensed and for a large profit margin, it probably would have been over $900 in 1994)

It put Sega in a position where the price would either be uncompetitively high, or losing massive amounts on each console sold and thus detracting from potential funding in other areas. In the end, they obviously opted to play Sony's game of chicken and matched the prices continually (to $300 in fall of 1995, $200 in spring of 1996, $150 in '97, $100 in '98), the cost of the Saturn put them in a lose-lose situation.

Now, had Sony's little price war NOT happened, and Sega sold the Saturn only at cost, it would have meant a much higher price point for much longer in general.
In that respect, Sega may have been better off with the Jaguar chipset than the Saturn. ;) (not necessarily in the CPU+RAM configuration Atari used it, but the same based chipset with extreme cost effectiveness -the Cojag's configuration probably cost a hell of a lot less than the PSX -aside from Sony's vertical integration deflation of cost)

However, the hardware alone hardly killed the Saturn, it didn't help things, but obviously was only 1 facet of their management problems. (the issues surrounding the 32x and Saturn's launch would be major parts of that)
That's something that's already being discussed in the Mega Thread though, among other places (and rehashed many times) . . . and I went rather far off the pure tech side of the discussion with the Jaguar marketing issue above.

On that note, the only other tech-issue the Saturn really had was lack of development tools. Not only did Sega lag far too long in getting any decent library support out there, but they didn't have ANY development tools or detailed documentation at all for 3rd parties until mid 1995. (aside from Sega of Japan's in-house teams working from their own code)

The PSX was only designed to handle 3D, and had it's own design shortcomings ( the lack of perspective correct interpolation ) and that showed up when you compare the best 2D fighters on both platforms ( where the extra 2D memory and graphics capabilities of VDP2 shone out )
Yes, I understand that, and that's also why the jaguar's feature set makes a lot of sense . . . a lot of flexibility for a time when 3D/pseudo 3D was far from cut and dry. For all they knew, height maps could have become very dominant by the mid 90s (and on PCs they were for a time) or 2D could have held up longer too, but the Jaguar was still extremely cost effective for what it offered (and it's surprising it had as few bugs/problems as it did given Atari's position).

The 32x's design is also a bit more forgivable as it went from concept to production within 6 months. (it was cheap at least, but not great cost/performance ratio -the all CPU design also made it flexible like PCs but more of a jack of all trades master of none at the same time -unlike the jaguar)

However, the PSX did have quite good support for 2D via the rectangle drawing modes derived from the triangle rasterizer, definitely competitive for 2D in that generation while using the same logic as the 3D engine as well, so they were pretty well set even if 2D ended up more popular, though less so for height maps. (though using the GPU to draw individual columns of doom type games as lines and then do a 2nd pass to rotate them could work, same for doing basic line fills for a voxel type game and rotating 90 degrees, but both would need some CPU assistance and the GTE's coprocessing wouldn't be very useful -had Sony thought flexibility was much more necessary, the GTE probably would have been replaced with a much more flexible/programmable DSP-like chip that sacrificed peak vertex crunching performance in favor of said flexibility)
Perspective correct rendering wasn't practical for the time either, though perhaps quake-like segmented affine mapping would have been a good option. (or making it programmable for plain or segmented mapping) As it is, you can use more polygons to segment things, but going that within each triangle would have cut back on overhead a good deal more.

The N64 was perhaps the king of flexibility for that generation, and while a very efficient and heavily integrated design from an engineering standpoint, the execution, tool support, and actual market needs (and resulting software support) meant that all that flexible programmable silicon was used in a rather fixed-function manner that could have been far cheaper with fully dedicated fixed-function hardware. (albeit, if Nintendo/SGI had invested in really comprehensive RSP microcoding tools as well as a broad array of default microcode implementations to use, that flexibility probably would have been used quite well)
Given all of SGI's demos and such, they didn't seem to even be pushing that flexibility either, but treating it more like the high-end workstations. (ie a lot of non-dedicated hardware doing tasks that fixed-function hardware could do at much lower cost)
Well, it did have SOME fixed function hardware too, including the RDP rather prominently . . . so RSP+RDP is sort of like the GPU+blitter in the Jaguar in that respect, but more like if the GPU was far far more powerful and used a lot more transistors. (albeit in 350 micron rather than 500)

There's also the cartridge issue with the N64, very bad idea and rather arrogant on Nintendo's part (to think they couldn't lose their key 3rd party devs or to think they didn't need to compete with flexible low cost mass storage), and developing the DD was the icing on the cake. (more expensive drive and media, too late to really matter, and lower capacity/slower than CDs as well -or proprietary optical based on CD like GC did with DVD or Sega's custom GD-ROM format -which still used standard CD-ROM drives)
And with such media, Nintendo probably would have continued their reign in Japan and got much better support for the hardware even without better tools. (as it was, Rare and Factor 5 killed themselves pushing custom microcode somewhat like better PS2 developers did for custom tools/libraries along with low-level optimization . . . and the likes of Capcom and Konami may have pushed optimized 2D oriented microcode implementations -or maybe just used the PSX-like 3D oriented "Turbo 3D" microcode instead -not ideal for 2D, but much more efficient than the normal slow "Fast 3D" code))

Crazyace

06-19-2011, 04:44 AM

What I'm commenting on are more hack-ish options . . . a "perfect" example would be far, far better and more in line with the jaguar 2's design philosophy. (but within practical 1993/1994 limitations . . . well Atari's funding/resources limited that a lot more anyway)

I think that adding a seperate bus on to the Jaguar was way more than a hack. Just fixing the known h/w bugs would have improved things ( like the gpu/dsp running code out of main memory, and the dsp running slow bus cycles ) - and I still think that the only thing that really stopped the jaguar being more succesfull was not having a CD at the start.
Cartridges were way more expensive, and a CD at the start would allow publishers to support Atari with less risk.

In the JagII manual they have a intersting timing breakdown for texturing 4 pixels on the original Jaguar.

4 x ( rowchange + read + r/wbuschange + rowchange + write )

4 x ( 3 + 2 + 1 + 3 + 2 )

This gives 44 cycles for 4 pixels ( 11 cycles per pixel )

Using a 2 pass renderer the bus activity per 4 pixels would be 3 + ( 4 x 2) + 3 + (1 x 2) ignoring the blitter setup , so 16 cycles ( 4 per pixel ). If texturing a 16 pixel span the bus cost would be less than 3 cycles per pixel - which is a lot faster than 11, without any hardware changes.

saturndual32

06-19-2011, 11:10 AM

So, Crazyace, there was quiet a bit more untapped potential on the Jag for texture mapping, without any hardware revisions. Having stuff like Skyhammer at say... 4 extra frames per second would make quiet a diference to me.

Crazyace

06-19-2011, 02:20 PM

I dont know - I think that the later games were using faster texture mapping routines already. Nothing really would make the Jaguar match the Saturn for texture mapping, let alone the PSX or N64.

kool kitty89

06-20-2011, 02:20 AM

I think that adding a seperate bus on to the Jaguar was way more than a hack.
How about an external cache a la MSTE? (at least if that was cheaper than using a 68EC020 or 486SLC . . . well, actually a 26.6 MHz 386SX probably would have been a lot better than the 68k -and facilitate PC ports to some degree as well, though limit Amiga/MD ports)

But how hard would it have been to configure a local bus for the 68k? (not a 2nd system bus, but memory only mapped/interfaced to the 68k itself, outside the address range of the main system . . . though since the 68k is limited to 24-bits of space, so you'd probably end up using a bank switching mechanism to page between the Jaguar and local bus/map)
I think flare's notes in the Slipstream documentation also mentioned plans to include a local bus for the 8086 and avoid contention (when not accessing Slipstream memory).

And technically the CoJag DID add a separate bus to the Jag via the 2nd port of the VRAM bank (unless both ports were mapped to the main bus, which sort of defeats the purpose of VRAM).

But again, a local 68k bus (or external cache) might have ended up more expensive than better CPU options on the main bus alone. (especially if RAM1 was implemented to reduce contention overhead -namely for page breaks)

Just fixing the known h/w bugs would have improved things ( like the gpu/dsp running code out of main memory, and the dsp running slow bus cycles )
Obviously that would have been best for cost/performance, so would have been making the system self-booting (and with bug-free J-RISCs, even with no cache, the assembler would be fine and good compilers would be much more forthcoming).
However, that's a lot of wishful thinking that they could have addressed all those bugs, even if they'd kept the hardware design going into 1993 (rather than freezing it in mid/late 1992) and pushed the release back to fall of 1994. (and that definitely would have required more risk of private funds or loans at unfavorable rates -the 1993 jag text market hype drummed up investor interest and boosted PR/stock value, so they'd have to compensate for that in other ways to hold out for a single launch in mid/late '94 . . . well, since that hype generation focus was part of dropping the ST/Falcon and reducing Lynx emphasis, they might have gotten by by continuing ST/Falcon support and marketing -at low budget/low key levels- in Europe and pushed the Lynx more, at least in Europe -1993 might have been time for a 3rd major revision of the Lynx . . . reflective color LCDs might have been reasonably acceptable at that point too -making for a huge possibility for a "Lynx Jr" with unlit screen, lower price, smaller form factor, and much better battery life)

The only totally open options without any hacks at all as the design was in 1993 would have been a different CPU (given the flexible nature of the host processor interface) and varying RAM configurations within the 2x 4MB RAM1/0 banks. (well, that and more potential for PCB design, like adding a general purpose expansion port including addressing for RAM1/0 and direct full-speed 75 ns system RAM expansion or extend the cart slot's addressing/signals to facilitate expansion there . . . though you'd be limited to 32-bits without a major increase in pin count)

and I still think that the only thing that really stopped the jaguar being more succesfull was not having a CD at the start.

Cartridges were way more expensive, and a CD at the start would allow publishers to support Atari with less risk.
Yes, that is definitely true, though the RAM made for compressed carts too. ;)
And such lower risk would mainly have garnered more support with low quality ports/multiplatform games, or stronger support from small/budget developers on the better side of things.

Though the multimedia support is undeniable . . . Atari REALLY should have had an analog audio mixing line of the cart slot though, having to stream CD-DA as PCM to the DSP was unnecessary (though rather modest) hit to the main bus. (Sega CD did CD-DA totally analog -CD chipset did the decoding to internal DAC then mixed it with MD analog audio . . . as did pretty much every other system supporting CD-DA -any other streaming audio couldn't be decoded by the CD chipset though, so lower quality PCM, ADPCM, etc would need to be decoded and played by other hardware in the system, though in the MCD and PCE CD's cases, that hardware sound output is also mixed on the analog end with the PCE/MD sound ;))

For sheer low-cost, 1.44 MB floppies might be a decent option (technically more expensive than CD-ROM, but much cheaper due to volumes and competition -CD-ROM would take a bit longer to get really competitive with aggressive pricing and low margins), but then there'd be the piracy threat too. (they could have offered a cart slot too, for developers wanting to avoid such threat and who could afford the risk of ROM -better still if the cart slot was made flexible for RAM expansion)
OTOH, the computer game market was booming in spite of Piracy, and 1993 just started to see major CD-ROM releases on PC. (with floppy versions of most games for a while longer, not to mention Europe's computer market)

The lack of CD was a pure cost issue, though that itself was a conflict (low cost media vs low cost base unit), but floppy drives were much more affordable at the time and definitely would have been a smart move for catering to a low-cost oriented console. (and would have made many computer game ports a lot more realistic without heavy cuts or very large ROM sizes -RAM limits would still force trade-offs though)
One problem with that is that a floppy drive would be needed for backwards compatibility when CD became supported, though that might also make for a great low-cost memory card option at much higher capacities than anything pre-PS2.

Konix was going the floppy disk route (880k Amiga format was planned) in 1989, it would have been interesting to see how that played out. (or if Atari had licensed the Slipstream and scrapped the Panther in 1989 ;) -it would be interesting to know if Brennan ever tried to pitch that to Atari, the Slipstream was a non-exclusive license to Konix after all)

However, I disagree that it could have saved them if management/marketing wasn't any better (let alone existing PR) . . . those factors are far more important than hardware in most cases, and in 1993 the cost of CD was still a huge issue (Nintendo's decision with the N64 with planned 1995/96 release was just stupid though), but 1993 (especially with Atari's limits) would be a major trade-off.

And on the marketing/management end, Atari's options were limited. Well, for management, it just seemed to be poor in some areas in general (exacerbated by limited funds too), and the options on the funding end would have been risking large amounts of private funds and/or heavily deficit spending with investors/creditors (Sega did both the Dreamcast, and it DID pay off in the US market as far as good PR, good support -hardware/tools helped there a lot too, very good sales -especially considering the bad PR from Sega's mid 90s mess, but also a lot of short-term dept that would only have been recouped with long-term success of the DC -and it went nowhere fast in Japan and got botched in Europe, so a primarily US market crippled that further -one could argue it might have worked in the long run, but Sega obviously chose to cut their losses rather than taking that risk -of course, that decision alone also meant a massive hit to PR and stock prices, so there were risks either way)

Atari's lack of PR (or notice in general) in the US market would have meant Dreamcast (or Genesis) level spending/marketing to get a realistic position in the US. (and poor management of that marketing budget would ruin them . . . Sega had a massive budget with the SMS, initially ahead of Nintendo and always far head of Atari -by more than an order of magnitude at times iirc- but they failed to manage that marketing effectively in the US and lagged well behind Atari in US market share up to late 1989 . . . which also shows a major potential loss in a potential 4th gen console release around 1989/1990)

EDIT:
. . . It was stuff that happened before the Jaguar (declining computer market and lack of a 4th gen game console were both massive issues -the latter probably the most important factor in the US). They really needed a decent (if not great) 4th gen console offering, even the Panther (as it was) would probably have been a lot better than nothing (an ST derived console might have been more developer/port friendly, though probably with less raw 2D power than the Panther), the Slipstream would have been an interesting option (decent and flexible 2D and very interesting 3D potential), or pushing for a late 4th gen console prior to the jaguar. (like pushing Flare to design a more conservative, short term design in line with some of the jaguar concept -and intended to be forwards compatible- but feasibly ready for market by late 1991 . . . be it just a simpler all-new design with similar Slipstream+Panther conceptual basis, or heavier bias of the older design(s) depending on what was faster/cleaner -or using part of the older design(s) more directly along with new hardware, like a slower clocked jaguar aiming at .8 micron tech without the GPU or DSP but perhaps with a tweaked and up-clocked derivative of the Flare DSP for 3D/coprocessing support)
And then there's the offer in 1988 to distribute the MegaDrive in North America that Tramiel couldn't agree on (with some understandable reasons -the main one being that they'd have no direct input on the European market . . . and given the huge ST market in Europe in '88, that's quite a conflict of interests, plus Atari's in-house console projects -of course, none of which amounted to a 4th gen entrance in the end), and the mounting management problems under Sam Tramiel. (Katz leaving in early 1989 compounded that issue)

However, even if Atari didn't risk any more funds, but did manage some smarter management, they might have had a chance as a niche market in the US, but far more possibility for a real mass market position in Europe due to much better PR and brand recognition, much lower cost of marketing for that region (and effective viral marketing), great EU software support, etc.
They'd have no chance in hell for Japan unless they licensed it to a label who could sell it in Japan. (it was a hell of a lot better than the PC-FX too, but licensing it to NEC would have been iffy, but cool to think about ;) -maybe they could have gotten a good deal on the V810 CPU and NEC CD drives as well ;))

In the JagII manual they have a intersting timing breakdown for texturing 4 pixels on the original Jaguar.

4 x ( rowchange + read + r/wbuschange + rowchange + write )

4 x ( 3 + 2 + 1 + 3 + 2 )

This gives 44 cycles for 4 pixels ( 11 cycles per pixel )

Using a 2 pass renderer the bus activity per 4 pixels would be 3 + ( 4 x 2) + 3 + (1 x 2) ignoring the blitter setup , so 16 cycles ( 4 per pixel ). If texturing a 16 pixel span the bus cost would be less than 3 cycles per pixel - which is a lot faster than 11, without any hardware changes.
Neat, that sounds like it would be approaching the Saturn's peak VDP1 bandwidth too. (especially for 26.6 MHz VDP mode)
I'm not sure on the exact timing, but it shouldn't be faster than 2 clocks per pixel (and only when you avoid page penalties).

Of course, for actual 3D stuff the jag has to deal with GPU+blitter cooperation vs hardware quads on the Saturn (and more resource for vertex plotting -DSP and both CPUs). And even if you did do apples to apples with a CPU assisted line by line triangle rasterizer on the Saturn, you'd be able to do much easier multitasking due to the ability to buffer lists of drawing commands into VDP1 RAM. (if you got the GPU working in main, you could buffer blitter lists in local and have more parllel work too)

There was also an interesting possibility for a triangle (or warped quad) rasterizer other than line by line rendering via scaling/rotation based 2D blitter hardware mentioned here:

If you're using the ASIC you may as well just try textured polygons =P

Go and try the 3D globe widget for Opera (http://widgets.opera.com/widget/7337/). Technically it's just a ZIP with HTML and javascript code inside, so it should run on any browser if you unpack it (EDIT: well, any browser that supports 2D canvas). Look at the way it stores textures and you'll see how it'd be possible to do textured triangles with the ASIC.
and more:
http://www.sega-16.com/forum/showthread.php?17301-How-capable-would-the-Neo-Geo-MVS-AES-be-in-3D-polygon-graphics&p=367072

I dont know - I think that the later games were using faster texture mapping routines already. Nothing really would make the Jaguar match the Saturn for texture mapping, let alone the PSX or N64.
The more untapped potential is for flexible rendering of 3D/pseudo 3D, including voxel engines (and height maps in general). Sparing use of polygons with even more sparing use of textures (optimization for gouraud shading and CRY in general), heavy use of scaled sprites, and mixed use of Doom/duke 3D style textured height maps and voxel stuff.
Amok would have been interesting to see done on the jag.
It's a bit of a shame that there was no Commanche port or emphasis on height map engines in general. (Cybermorph using Commanche style voxels -let alone Phaze Zero type interpolated stuff- would have looked pretty awesome and probably run faster too -that game really needed nice 2D backgrounds though)

I wonder if doom type column rendering would be faster via GPU+blitter using software assisted texture mapping, or using the blitter's scaling/rotation feature and rendering columns as lines (probably as chunks into a buffer in local RAM) and then rotating 90 degrees and plotting to the framebuffer (and doing the floor/ceiling as a fine pass). I was talking about doing this on the Sega CD with Chilly Willy.
Or maybe you could even do walls with each column being a separate scaled OPL object.

I wonder how Carmak did it.

Another possibility is doing what Chilly Willy has with the 32x Yetti 3D demo (large screen size, but low resolution and blocky pixels), except better on the jag since it can do true low-res frame buffers (and flexible res in general) due to the object processor, while 32x is fixed at 6.7 MHz dot clock and 320 pixels. (the line table allows variable vertical resolution, but not horizontal . . . and a 1/2 res mode would have been great for some things, especially use of the 16bpp mode -which is what Yetti uses, though you could do pseudo 1/2 res 16bpp with dithered pairs of paletted 8bpp stuff)

Actually, given the number of rather choppy Jag games, dropping resolution probably should have been pushed much more often. Doom definitely made the sacrifice, and AvP definitely should have (not only easing fillrate, but halving the rays to cast), or variable detail options could be used. (which could include variable screen size as well as resolution)
Lower res would obviously also take less framebuffer space. ;)

3DO Doom had variable screen size, but oddly forced high detail mode . . . given that low detail should have roughly doubled the framerate at a given screen size, that would have been a huge boost to performance. (probably bringing it close to 32x levels)

kool kitty89

06-20-2011, 02:56 AM

Not sure if you saw my last edit (crazyace, I saw you tagged as viewing the thread), so I added "EDIT" in bold to mark the added paragraph. ;)

Crazyace

06-20-2011, 05:14 AM

I think that fixing bugs is way more believable than adding extra buses, or caches, or different processors, and in 1993 I also think that a single speed CD ( like those found on the Sega CD and PC engine CD ) would be cheaper than a 1.44MB floppy - especially as Atari didn't use a CD-rom controller, just an audio CD -controller.

Regarding the speed comparision with Saturn for the 'best case' texture mapping - don't forget that the object processor would steal cycles from the blitting, and there would be gpu overhead for both the blitter setup, and also the 3D transforms.

TVC 15

06-20-2011, 06:54 PM

Sorry if I'm derailing a Jag centric discussion, just have a quick question about the Saturn (another one, sorry!).

Whats the most limiting factor in the Saturn overall 3d performance. Is it using a general use processor in the case of SH-2's for 3D math, lacking a dedicated 3D transform engine that limits its overall performance. Though arguably some very tight coding could use both cpus for geometry transforms, the Shenmue tech demo probably uses both for its cutscene engine when game logic and A.I are not needed.

Or is it the VDP1. It has been mentioned (not sure if it was Chilly or Kool Kitty) that overall the PSX GPU (NOT GTE) has a much higher overall bandwidth and pixel throughput, regarding overall best case scenarios of MegaPixels per second.

And, what overall would have been the best way to solve some of these problems and limitations depending on the Saturns biggest fault. This is also not from a theoretical perspective, i.e altering the Saturns chipset, but through actual real coding practice, i.e with culling methods for example. Or is their only so much that could be done, if the Saturn really was lacking.

kool kitty89

06-21-2011, 12:13 AM

I think that fixing bugs is way more believable than adding extra buses, or caches, or different processors
External cache (and added bus moreso), perhaps, but changing the CPU used should have been very straightforward on the engineering end since the design was inherently meant to be flexible for different CPUs (intended to accept any x86 or 68k arch chip given Kskunk's comments . . . and by extension, also had little problems adapting to most other processors on the market sine most used x86 or 68k-like bus interfaces or a combination of the 2).

The issues with changing the CPU would be component cost (for a more expensive CPU), associated negotiation for a good high-volume price, possible added cost to the motherboard (namely if a 32-bit CPU bas was used, meaning at least 16 more traces for the CPU and 16 more for JERRY -and obvious performance improvements), and deviation from the set-up established for the early dev tools and documentation going out in early 1992. (though a 68k architecture chip would be less problematic on that end) The BIOS would need to be modified too. (and of their options, the cheapest next step up would probably be a 386 SX, 68EC020 -preferable, maybe x86 SLC chip, or maybe an ARM60 or ARM2/ARM3 if embedded versions of the ARM2/3 were available similar to the cacheless ARM60 -AM386DX, let alone DLC was probably still to competitive in the mid range to consider for a low-cost embedded option, though maybe they could get a good deal, as would probably any RISC with a cache or 68EC030 -maybe the SH-1 would be cheap enough; a lot is up to marketing and margins rather than actual manufacturing costs, especially for chips being used in midrange desktop computers)

Changing things after the mass production tooling was set-up would obviously be extremely wasteful and force a lot of unnecessary overhead. (but that's beyond "last minute" in the way I meant it)

Changing the RAM configuration would have similar trade-offs. The chips already supported up to 8 MB of 64-bit FPM DRAM in 2 banks, so anything within that should have been an option. (cost being the main factor to consider) Switching to 8 128kx8-bit DRAMs for a 1M 64-bit bank and a 2nd 16 or 32-bit bank (whatever the CPU bus width was) with 2 256kx16-bit chips or 2 512kx8-bit chips. (unless they dropped below 2 MB)

Neither of those things would require bug fixes, and (assuming the change in plans was done before any mass production board design or tooling was set down), shouldn't have significantly delayed things either. (just added to component and possibly manufacturing costs)
I believe the CoJag made its changes without modifications to the custom chips either.

OTOH, bug fixes wouldn't have added to component costs, but would have necessitated extended development time. (and Atari would have had to find another way to hang on in the short run -obviously, if they COULD address all the major bugs on top of a strong launch lineup for fall 1994, they'd have been a lot better off, but they'd need to do things differently to hold on that long -again, probably some degree of private investment, and probably pushing the ST/Falcon longer in Europe as well as maintaining/expanding the Lynx)
That, or changing decisions/management much earlier on than mid 1992. (things that would have avoided the steep decline of their European computer market and near absence in the game console market from 1990 onward) But that's another topic and one I already started drifting off to earlier. ;)

and in 1993 I also think that a single speed CD ( like those found on the Sega CD and PC engine CD ) would be cheaper than a 1.44MB floppy - especially as Atari didn't use a CD-rom controller, just an audio CD -controller.[quote]
CD-ROM drives were obviously fundamentally cheaper to manufacture than floppy drives (as kskunk mentioned -with the exception being basic low density floppy drives), but the question is whether the actual pricing was lower due to high margins on a premium product, heavy licensing/royalty overhead, and limited competition.

In the long run, CD would obviously be a winner, but, as it was, Atari couldn't afford to overlook the short run . . . at least not without risking a ton more than they did. (private funding and/or much heavier investment spending)
Well, if the margins were kept the same and just the price went up, then they wouldn't risk that either. (just risk going further and further out from the $150 price point goal . . . though the attractive CD media -from content and cost/price perspective of users and developers would be huge)

But yeah, if they could get basic, cheap 1x CD drives for as little (or less) than DS 3.5" floppy drives an HD controllers (like in the STe/TT/MSTe/Falcon), even in 1993, then that would definitely be preferable by far. (unless an existing stock from the ST would have offset that initially)
They definitely shouldn't have bothered with the expense of licensing a CD-ROM chipset, at least not until later on (once sales had proved strong and they had the revenue and favorable investor interest to better afford such investments), just buy off the shelf audio CD drives and chips for early models. (not sure if Sega licnesed theirs or not)

Another thing would be the need for interface logic to communicate with the super low-level CD controller (the Jag CD used an in-house ASIC for that, so more R&D unless off the shelf logic was used for early models). Sega used super low level CD-ROM interfaces too (on the Sega CD and Saturn) with the Sub CPU and SH1 handling CD-ROM data transfers and managing the cache/buffer. (slaving the jag's 68k for that purpose might have been sensible . . . even without a separate bus like the Saturn/MCD -though the CD-ROM cache/buffer would be off the main bus in any case-, offloading to the 68k might be quite useful since it's a CPU time/resource intensive issue and not really a bus intensive one -or not so much intensive either, but difficult to multitask with)

The Sega CD used an off the shelf Sanyo LC89515K CD-ROM/CDi error correction and host interface LSI, so Atari could have opted for something like that rather than going custom. (custom is cheaper in the long run, but less foolproof and can be costly in the short run -I wonder if the use of dense .5 micron ASICs really paid off for the volumes Atari was working with, and obviously didn't pay off nearly as much as it could have with million sales volumes -ie at least in the rage of the 7800 in the US or ST/Lynx in Europe)

Of course, there's still all the funding/management/software R&D/licensing/marketing issues aside from the tech stuff. (and more tech+management issues too, like investing more in good development tools -in hindsight, commissioning id probably would have been one of the best options given Carmak was one of the few if not only jag developers toput together a real tool set with reasonable compiler support for the RISCs -not sure if he implemented a main code workaround or not)

[quote]Regarding the speed comparision with Saturn for the 'best case' texture mapping - don't forget that the object processor would steal cycles from the blitting, and there would be gpu overhead for both the blitter setup, and also the 3D transforms.
If you wanted to do a true triangle rasterizer on the Saturn, you'd also have that set-up overhead . . . but have the VDP on a separate bus you could buffer drawing command lists into and keep a lot more parallel work than the jag. (for Quad engines the Saturn is obviously much better . . . though the DSP would be easier to use with triangles -or SH2s for that matter, though the software floating point support was pretty decent and the option taken by some developers to ease the use of quads)

But yes, having the separate frambuffer scanning bus (a la VDP2) frees things up more too, on top of other advantages. (totally different design cost though, and arguing cost to performance ratio is another thing entirely)

Crazyace

06-21-2011, 02:15 AM

Crazyace

06-21-2011, 02:30 AM

Whats the most limiting factor in the Saturn overall 3d performance. Is it using a general use processor in the case of SH-2's for 3D math, lacking a dedicated 3D transform engine that limits its overall performance. Though arguably some very tight coding could use both cpus for geometry transforms, the Shenmue tech demo probably uses both for its cutscene engine when game logic and A.I are not needed.

Or is it the VDP1. It has been mentioned (not sure if it was Chilly or Kool Kitty) that overall the PSX GPU (NOT GTE) has a much higher overall bandwidth and pixel throughput, regarding overall best case scenarios of MegaPixels per second.

And, what overall would have been the best way to solve some of these problems and limitations depending on the Saturns biggest fault. This is also not from a theoretical perspective, i.e altering the Saturns chipset, but through actual real coding practice, i.e with culling methods for example. Or is their only so much that could be done, if the Saturn really was lacking.

I think the biggest limitations for the saturn were the transparencies and dithering for 3D. Everything else was just performance , and even the quad rendering was a mixed blessing as a lot of subdivision methods worked on quads anyway, and heightfields would decompose to quads as well. Only having 8bits in high res for VDP1 was also an issue ( although it didn't affect VF2 )

kool kitty89

06-21-2011, 05:34 AM

In some ways I was thinking not of 'bug fixes' - which would involve more time , but instead 'not having those bugs' :) ie having the chipset work.
If the gpu/dsp could run code from main memory as designed, then having a better processor than the 68k wouldn't be necessary ( and even having a 68k at all would be questionable ) - devs could run game code on the dsp ( freeing up the gpu for blitter control and 3D work from local ) in main memory, with audio running as interupt driven from the dsp local memory.
Yes, but best laid plans and all that. :P

Though better R&D funding might have made for faster/smoother development in general . . . and may have given Flare the confidence to fundamentally design the system around their custom RISC architecture as the only general purpose (CPU, etc) processors used at all. (aiming at a cache would be nice too, but obviously more work and more possible bugs . . . though with just TOM and JERRY, they might have pushed a bit more into JERRY and enlarged the scratchpad a bit with a total die size closer to TOM's -I was of the impression that JERRY is about 20% smaller than Tom)

Even then, you couldn't totally be foolproof against bugs and delays. Maybe if just 1 J-RISC was used you might manage a bug-free set-up, maybe even with a cache. (actually, if you did that and put the RISC on its own ASIC and graphics stuff on another, you could have the RISC working without contention for the scratchpad and potentially more space to cram other things in either ASIC -given the general size of the RISC, moving the UART and other I/O stuff to the video ASIC would make more sense, probably with a significantly larger local for video too, and maybe a moderately larger one than JERRY had for the RISC if not a cache -having the on-chip DACs working properly and adding DMA PCM support, or at least FIFO buffers -especially with interrupt for full/empty rather than just flags like the 32x- would have been a lot more useful than the bare DACs JERRY got)

For true triangle rasterising on the saturn it just involves setting 2 coords to the same point, so it's not really a massive overhead in setup ( performance and texture prewarping are other issues )
If you wanted to avoid overdraw and texture prewarping (let alone make use of gouraud shading), line by line rasterization could make more sense, but require more CPU overhead, obviously.

On another note, rasterizing Jaguar style should also work around the transparency bug (as it only occurs for warped drawing modes and you'd be drawing in the scaled/rotated 2D mode, like the jaguar or Sega CD).

I think the biggest limitations for the saturn were the transparencies and dithering for 3D. Everything else was just performance , and even the quad rendering was a mixed blessing as a lot of subdivision methods worked on quads anyway, and heightfields would decompose to quads as well. Only having 8bits in high res for VDP1 was also an issue ( although it didn't affect VF2 )
Yes, the actual difficulties, but the performance differences would be significant to compare as well.
The drawing bandwidth of VDP1 vs the PSX GPU seems to have been a major bottleneck for 3D games, with CPU resource being less of an issue. (even with 1 CPU was near maxed with 3D math -if the DSP wasn't used for that, you wouldn't be too far from the PSX in CPU grunt, but actual graphics bandwidth is a separate issue . . . and you also get less texture RAM for average games compared to the PSX . . . though you could shuffle around things in other memory for added textures, maybe even un-used framebuffer space)

The Saturn was OK in pure performance nevertheless, certainly adequate for the generation, but Sega's management issues (including shaky development tool support), and the cost effectiveness of the hardware were another story. (made worse still by Sony's shockingly low pricing of the PSX on top of their somewhat cheaper hardware and vertical integration on top of that)

And with the 8-bit comment, do you mean that VDP1 could only do 8-bit reads/writes in 256 color mode? (so no improvement in pixel rate over 16-bit mode -not even plain 16-bit block copy/fill support, let alone read/write buffers for scaling/rotation/warped stuff)

Does the 3DO have any buffering to make use of the 32-bit bus while texture mapping? (or for plain 2D blits for that matter)

Crazyace

06-21-2011, 10:58 AM

Yes, but best laid plans and all that. :P

Though better R&D funding might have made for faster/smoother development in general . . . and may have given Flare the confidence to fundamentally design the system around their custom RISC architecture as the only general purpose (CPU, etc) processors used at all. (aiming at a cache would be nice too, but obviously more work and more possible bugs . . . though with just TOM and JERRY, they might have pushed a bit more into JERRY and enlarged the scratchpad a bit with a total die size closer to TOM's -I was of the impression that JERRY is about 20% smaller than Tom)

Even then, you couldn't totally be foolproof against bugs and delays. Maybe if just 1 J-RISC was used you might manage a bug-free set-up, maybe even with a cache. (actually, if you did that and put the RISC on its own ASIC and graphics stuff on another, you could have the RISC working without contention for the scratchpad and potentially more space to cram other things in either ASIC -given the general size of the RISC, moving the UART and other I/O stuff to the video ASIC would make more sense, probably with a significantly larger local for video too, and maybe a moderately larger one than JERRY had for the RISC if not a cache -having the on-chip DACs working properly and adding DMA PCM support, or at least FIFO buffers -especially with interrupt for full/empty rather than just flags like the 32x- would have been a lot more useful than the bare DACs JERRY got)

I think having the 68k was important at the time for getting ports done - fixing the onboard DAC would have saved money as well, but I'm not as bothered as you are about the need for DMA PCM. After all a lot of the reasoning behind the DSP was to synth sounds rather than just playback PCM.

If you wanted to avoid overdraw and texture prewarping (let alone make use of gouraud shading), line by line rasterization could make more sense, but require more CPU overhead, obviously.

On another note, rasterizing Jaguar style should also work around the transparency bug (as it only occurs for warped drawing modes and you'd be drawing in the scaled/rotated 2D mode, like the jaguar or Sega CD).

True - but the VDP1 drawing control blocks take a lot of memory, and line by line might hit limits there.

Yes, the actual difficulties, but the performance differences would be significant to compare as well.
The drawing bandwidth of VDP1 vs the PSX GPU seems to have been a major bottleneck for 3D games, with CPU resource being less of an issue. (even with 1 CPU was near maxed with 3D math -if the DSP wasn't used for that, you wouldn't be too far from the PSX in CPU grunt, but actual graphics bandwidth is a separate issue . . . and you also get less texture RAM for average games compared to the PSX . . . though you could shuffle around things in other memory for added textures, maybe even un-used framebuffer space)

The Saturn was OK in pure performance nevertheless, certainly adequate for the generation, but Sega's management issues (including shaky development tool support), and the cost effectiveness of the hardware were another story. (made worse still by Sony's shockingly low pricing of the PSX on top of their somewhat cheaper hardware and vertical integration on top of that)

I assume that, as the saturn forward textures it breaks a page with every pixel write ( although a Morten ordering on the write addresses might have helped ) - which is comparable to the Jaguar reads breaking pages. ( The PSX would be worse if every read was a texture cache miss ) and that is the limit for texturing

And with the 8-bit comment, do you mean that VDP1 could only do 8-bit reads/writes in 256 color mode? (so no improvement in pixel rate over 16-bit mode -not even plain 16-bit block copy/fill support, let alone read/write buffers for scaling/rotation/warped stuff)

Does the 3DO have any buffering to make use of the 32-bit bus while texture mapping? (or for plain 2D blits for that matter)
[/QUOTE]
I was just commenting on the fact that in highres (640etc) modes VDP1 doesn't support 16 bit pixels, only 8 bit - so no gourard shading or lighting on highres without a lot of hacks.
Not sure about the 3D0 , although there was a sport library to allow fast copies/clears using the vram line buffer.

kool kitty89

06-21-2011, 05:19 PM

I think having the 68k was important at the time for getting ports done - fixing the onboard DAC would have saved money as well, but I'm not as bothered as you are about the need for DMA PCM. After all a lot of the reasoning behind the DSP was to synth sounds rather than just playback PCM.
They should have realized by the early 90s how dominant sample synth was becoming . . . but DSP-like capabilities were still important there too for fast decompression (and doing that in software meant using any format you wanted from CVDS to 2-bit ADPCM to 4-bit to mulaw, etc), mixing, interpolation, etc. As well as potential for wavetable synth type stuff, or FM, or various other synths or combinations thereof. (FM would be much cheaper to accomplish on a Yamaha synth chip though, and much better supported on the developer end for standard functionality)

And DMA (or FIFO) support would be important in general for FM stuff as well, since you could synth and mix the channels (and possibly PCM along with it) into a buffer that's DMA'd independently and in parallel with the DSP rather than resorting to carefully timed loops (frustrating efficient multitasking and hardly foolproof as the Genesis saw -or maybe just an issue with developers not caring to put resources into decent Z80 coders) or using interrupts for a lot more overhead and performance loss. (something that wasn't an option on the MD due to the odd decision to not connect the YM interrupt signal to the Z80, though obviously inefficient compared to good cycle timed code, it would have been far better than many of the crappy playback schemes being used, especially at common sample rates)
And I mean DMA from the scratchpad, not main (to keep overhead down and put emphasis on the DSP scratchpad for the mixing buffer -even more important due to the very slow DSP writes to main), or FIFO for the same purpose. (and a FIFO cue should be pretty low overhead too, and with interrupts driving that, you'd need a much lower frequency interrupt scheme and thus far, far less overhead for the DSP)

In hindsight, not only was the synth support of the DSP rarely used (and rather poorly used when it was suppored), but the majority of sound/music was done with basic MOD formatted stuff, often basic 4 channel fixed stereo amiga type stuff at that (not even 8 channel with dynamic stereo), not sure if compression was used at least, but not even trying to emulate SNES level stuff. (which it would have been much more flexible for too due to DMA to main RAM/ROM and lack of forced filtering and interpolation -and higly variable compression possibilities)

Flare did the same thing for the Flare 1 (though I think the PWM DACs were working), and even in 1989, developers them were pushing PCM to a huge extent already, though there was a fair amount of use for the FM synth driver as well. (especially important due to the very memory available in the Multisystem -and no ROM to boost that)
Albeit the emphasis on synth made a lot more sense back then with the heavier memory limits. (though with the contention for DSP use in 3D games, it might have made sense to add a cheap discrete sound chip as well -the super cut down YM2413 was the super chip option in Yamaha's lineup and one of only 2 that integrated the DAC -the YM2612 was the only other, albeit the external DACs were pretty small/cheap anyway)

Though this comment is rather odd:
Brian Pollock of software publisher Logotron highlighted the limitations caused by the shortage of RAM (kept low to keep prices down), “My only concern is memory, or lack of it. For instance, in the game that I'm writing I am using six-channel FM synthesized sound. Now that takes up a hell of a lot of memory. I couldn't usefully fit any more samples, and that's sad.”[4]

FM shouldn't take up a lot of memory . . . unless his "FM" driver is actually a sample based engine using sampled FM.

True - but the VDP1 drawing control blocks take a lot of memory, and line by line might hit limits there.
OK, though there's still that interesting alternative method I liked to above:

If you're using the ASIC you may as well just try textured polygons =P

Go and try the 3D globe widget for Opera (http://widgets.opera.com/widget/7337/). Technically it's just a ZIP with HTML and javascript code inside, so it should run on any browser if you unpack it (EDIT: well, any browser that supports 2D canvas). Look at the way it stores textures and you'll see how it'd be possible to do textured triangles with the ASIC.
and more:
http://www.sega-16.com/forum/showthread.php?17301-How-capable-would-the-Neo-Geo-MVS-AES-be-in-3D-polygon-graphics&p=367072

I assume that, as the saturn forward textures it breaks a page with every pixel write ( although a Morten ordering on the write addresses might have helped ) - which is comparable to the Jaguar reads breaking pages. ( The PSX would be worse if every read was a texture cache miss ) and that is the limit for texturing
Given the speed of the Saturn's RAM, a break would probably force 3 wait states (4 cycles per write), so a pretty big hit.

Does the PSX have any added buffering for working out of cache (namely phrase buffers for source or, more importantly, destination), or does it rely solely on the cache for that functionality as well? (though even for cache operations, it really would at least need 32-bit source and destination buffers for efficient bandwidth use)

IIRC, the "sprite mode" also generally draws at close to the max texture fillrate (much closer than most 3D polygon stuff), so something must be going on there. (efficient pipelining for 2D drawing operations both inside and outside of caching, or very heavy optimized use of cache)

I was just commenting on the fact that in highres (640etc) modes VDP1 doesn't support 16 bit pixels, only 8 bit - so no gourard shading or lighting on highres without a lot of hacks.
16bpp is supported up to 512x256, correct? And 8bpp up to 512x512?

Actually, this is something I've been a bit confused about before, since several games indeed appear to be using 640x480 or 714x480 in 256 colors with polygons exceeding the 512 wide boundary (ie not just VDP2 stuff in that added space), but that should be impossible for the framebuffer to fit. (and even if you could fit it into the framebuffer -or do things like use each framebuffer for a separate interlaced field at the expense of single buffering- that would necessitate VDP1 being able to exceed 512 wide pixel addressing in general)

It's also a bit ironic that the Saturn got that 8bpp support when, if the PSX GPU had gotten it, there could have been far greater advantage (and flexibility) to using it due to the direct contention for framebuffer/VRAM space (while saturn framebuffer space is of limited use for anything but the framebuffer), and the support for hardware dithered interpolation making potential for dithered shading and transparencies in 8bpp, especially for high res stuff where dithering works better. (granted, you'd need some sort of programmable look up table for such a mode since the color palette would be variable . . . or only allow support for those features if a special fixed 256 color palette was used -with programmable palettes disabling dithering and hardware shading, requiring software look-up instead)

Had the Saturn at least supported a hardware shading LUT in VDP1, you could have had PC VGA style shading/lighting effects rather than just flat shading. (granted, it would be worse looking than the few PC games that supported dithered shading -like Tie Fighter- unless hardware dithering was added to VDP1, but most PC games just used simple look-up based shading gradients -sometimes used for limited, posterized, translucency as well- Like Doom, Quake, and Tomb Raider) It's smooth shading, but with a lot more limited color (so posterized/banded like highcolor stuff, but worse -more or less depending on how optimized the palette is and how diverse the texture colors are -ie if you had all textures limited to a single 16 color palette, shading could actually be smoother than most highcolor stuff ;)). It definitely looks better than just flat shading stuff, especially with higher contrast light sourcing. (giving flat shaded stuff an extremely faceted look, one of the shortcomings of Sega's model 2 board vs contemporaries like the System 22 -it oddly had spectral reclection, but not gouraud shading; albeit with light sourcing disabled, the faceting is far less visble and textures can be set at optimal shades for the smoothest look)

Crazyace

06-22-2011, 04:24 AM

They should have realized by the early 90s how dominant sample synth was becoming . . . but DSP-like capabilities were still important there too for fast decompression (and doing that in software meant using any format you wanted from CVDS to 2-bit ADPCM to 4-bit to mulaw, etc), mixing, interpolation, etc. As well as potential for wavetable synth type stuff, or FM, or various other synths or combinations thereof. (FM would be much cheaper to accomplish on a Yamaha synth chip though, and much better supported on the developer end for standard functionality)
The DSP was cheaper ( no royalties ) - and supported all of that plus reverb/effects as it was completely programmable.

And DMA (or FIFO) support would be important in general for FM stuff as well, since you could synth and mix the channels (and possibly PCM along with it) into a buffer that's DMA'd independently and in parallel with the DSP rather than resorting to carefully timed loops (frustrating efficient multitasking and hardly foolproof as the Genesis saw -or maybe just an issue with developers not caring to put resources into decent Z80 coders) or using interrupts for a lot more overhead and performance loss. (something that wasn't an option on the MD due to the odd decision to not connect the YM interrupt signal to the Z80, though obviously inefficient compared to good cycle timed code, it would have been far better than many of the crappy playback schemes being used, especially at common sample rates)
And I mean DMA from the scratchpad, not main (to keep overhead down and put emphasis on the DSP scratchpad for the mixing buffer -even more important due to the very slow DSP writes to main), or FIFO for the same purpose. (and a FIFO cue should be pretty low overhead too, and with interrupts driving that, you'd need a much lower frequency interrupt scheme and thus far, far less overhead for the DSP)

I disagree - the interupt overhead was pretty low, and keeping everything in software made things more flexible. - The slow DSP read/writes were another bug that shouldn't have been there :)
Dont compare with the MD/Z80 - this was a system designed around feeding a DAC in real time.

In hindsight, not only was the synth support of the DSP rarely used (and rather poorly used when it was suppored), but the majority of sound/music was done with basic MOD formatted stuff, often basic 4 channel fixed stereo amiga type stuff at that (not even 8 channel with dynamic stereo), not sure if compression was used at least, but not even trying to emulate SNES level stuff. (which it would have been much more flexible for too due to DMA to main RAM/ROM and lack of forced filtering and interpolation -and higly variable compression possibilities)

Part of that maybe the software libs, or the fact that the system never sold that many units :(

Flare did the same thing for the Flare 1 (though I think the PWM DACs were working), and even in 1989, developers them were pushing PCM to a huge extent already, though there was a fair amount of use for the FM synth driver as well. (especially important due to the very memory available in the Multisystem -and no ROM to boost that)
Albeit the emphasis on synth made a lot more sense back then with the heavier memory limits. (though with the contention for DSP use in 3D games, it might have made sense to add a cheap discrete sound chip as well -the super cut down YM2413 was the super chip option in Yamaha's lineup and one of only 2 that integrated the DAC -the YM2612 was the only other, albeit the external DACs were pretty small/cheap anyway)

Though this comment is rather odd:
Brian Pollock of software publisher Logotron highlighted the limitations caused by the shortage of RAM (kept low to keep prices down), “My only concern is memory, or lack of it. For instance, in the game that I'm writing I am using six-channel FM synthesized sound. Now that takes up a hell of a lot of memory. I couldn't usefully fit any more samples, and that's sad.”[4]

FM shouldn't take up a lot of memory . . . unless his "FM" driver is actually a sample based engine using sampled FM.

I guess 6 channels with 4 ops would need memory for all of the phase accum. and the other channel info - and maybe he had small waveform tables rather than just generating sinewaves. ( and there's the program code as well )

OK, though there's still that interesting alternative method I liked to above:

and more:
http://www.sega-16.com/forum/showthread.php?17301-How-capable-would-the-Neo-Geo-MVS-AES-be-in-3D-polygon-graphics&p=367072

Have you looked at the setup code - acos calls? It seems a little heavy in terms of calculation? I think I'd stick with stiching planar triangles into quads with saturn.

Given the speed of the Saturn's RAM, a break would probably force 3 wait states (4 cycles per write), so a pretty big hit.

Does the PSX have any added buffering for working out of cache (namely phrase buffers for source or, more importantly, destination), or does it rely solely on the cache for that functionality as well? (though even for cache operations, it really would at least need 32-bit source and destination buffers for efficient bandwidth use)

IIRC, the "sprite mode" also generally draws at close to the max texture fillrate (much closer than most 3D polygon stuff), so something must be going on there. (efficient pipelining for 2D drawing operations both inside and outside of caching, or very heavy optimized use of cache)

I guess the cache - and the wider ram

Crazyace

06-22-2011, 08:54 AM

16bpp is supported up to 512x256, correct? And 8bpp up to 512x512?

Actually, this is something I've been a bit confused about before, since several games indeed appear to be using 640x480 or 714x480 in 256 colors with polygons exceeding the 512 wide boundary (ie not just VDP2 stuff in that added space), but that should be impossible for the framebuffer to fit. (and even if you could fit it into the framebuffer -or do things like use each framebuffer for a separate interlaced field at the expense of single buffering- that would necessitate VDP1 being able to exceed 512 wide pixel addressing in general)

Have to check the docs - not got anything here with me

It's also a bit ironic that the Saturn got that 8bpp support when, if the PSX GPU had gotten it, there could have been far greater advantage (and flexibility) to using it due to the direct contention for framebuffer/VRAM space (while saturn framebuffer space is of limited use for anything but the framebuffer), and the support for hardware dithered interpolation making potential for dithered shading and transparencies in 8bpp, especially for high res stuff where dithering works better. (granted, you'd need some sort of programmable look up table for such a mode since the color palette would be variable . . . or only allow support for those features if a special fixed 256 color palette was used -with programmable palettes disabling dithering and hardware shading, requiring software look-up instead)

8 bit support on PSX would have been a terrible idea - after all you have full ( even 24 bit support ) already up to 640x and there is no vdp2 equiv to perform pallette lookup on the 8 bit pixels.

Had the Saturn at least supported a hardware shading LUT in VDP1, you could have had PC VGA style shading/lighting effects rather than just flat shading. (granted, it would be worse looking than the few PC games that supported dithered shading -like Tie Fighter- unless hardware dithering was added to VDP1, but most PC games just used simple look-up based shading gradients -sometimes used for limited, posterized, translucency as well- Like Doom, Quake, and Tomb Raider) It's smooth shading, but with a lot more limited color (so posterized/banded like highcolor stuff, but worse -more or less depending on how optimized the palette is and how diverse the texture colors are -ie if you had all textures limited to a single 16 color palette, shading could actually be smoother than most highcolor stuff ;)). It definitely looks better than just flat shading stuff, especially with higher contrast light sourcing. (giving flat shaded stuff an extremely faceted look, one of the shortcomings of Sega's model 2 board vs contemporaries like the System 22 -it oddly had spectral reclection, but not gouraud shading; albeit with light sourcing disabled, the faceting is far less visble and textures can be set at optimal shades for the smoothest look)

It would be better to just support 16 bit in high res on the saturn ( maybe a mode where the memory was organised as 640x200 ). Though in the end most games ran at 320x on both Saturn and PSX - and the Saturn games that did run at high res didn't seeem to be penalised for not having lighting ( VF2 etc )

Crazyace

06-22-2011, 04:49 PM

kool kitty89

06-23-2011, 01:32 PM

The DSP was cheaper ( no royalties ) - and supported all of that plus reverb/effects as it was completely programmable.
Cheaper than some advanced sample synth hardware no doubt, and perhaps the ensoniq chips Atari had been considering for the Panther (DOCII and OTIS), but I'd have thought Yamaha synth chips would have been getting pretty cheap by that point. (at least things like the YM2612, YM3812, YMF262, and perhaps YM2151 -margins vary, of course, and the 2151 had been produced in huge volumes but still may have been sold at a premium over the others . . . the 2612 was specifically aimed at low cost the an integrated -albeit lower quality- DAC with multiplexed mixing rather than adding the channels)

However, by the time of the jaguar, things sample stuff was much more common anyway, and the DSP provided a nice set-up for that. (though, again, rather basic MOD seems to have been used very often)
I also recall mention of Atari providing a general midi compliant driver and sample set, and perhaps that's what Doom uses. (that might explain the excessive DSP bandwidth/overhead -mixing 16-24 channels- though you'd think Carmak would have opted to cut back to 8 or fewer channels if that were the case . . . or use the FM driver -though they'd need an appropriate composer with experience in FM . . . especially if Atari didn't have a ready-made tracker/MIDI driver for FM with a good set of default instruments)

I disagree - the interupt overhead was pretty low, and keeping everything in software made things more flexible. - The slow DSP read/writes were another bug that shouldn't have been there :)
So doing 48-50+ kHz interrupts for playback routines don't eat heavily into RISC time? (especially with a full 32 registers to save per interrupt . . . unless there's something special about J-RISC interrupts . . . hmm, there is the dual banks of registers, can that be employed for fast ints? -ie reserve 1 bank solely for use within interrupts and the other left for normal operation)
From past discussions on this issue, it always comes up that interrupts are horribly inefficient with few exceptions (like the 6502), that's definitely the case with the 68k (more so than Z80) and with the SH2s in the 32x. (which is why lacking DMA support is such a big issue there, the FIFO and -especially- interrupt based schemes
eat up a ton of CPU time, the difference between a 4-8 channel player run via interrupts an a 32-64 channel player via DMA)

And even without the slow DSP writes to main, you'd still reduce overhead by buffering solely into the scratchpad. (both reducing DSP time in main and reducing overall DSP time since you'd do single cycle writes to SRAM rather than dealing with DRAM)

Dont compare with the MD/Z80 - this was a system designed around feeding a DAC in real time.
How is the Z80+DAC different in that respect? (it also must feed the DAC a byte at a time, manually . . . just with a much less powerful processor)
Though, again, interrupts aren't even an option there, so programmers are forced to use the more efficient cycle timed code route . . . except many screwed that up with crappy timing.

Part of that maybe the software libs, or the fact that the system never sold that many units :(
And the general budget/software support . . . some poorly selling stuff still got good support due to the money being spent on it. (of course, that also ended up meaning a lot more money lost :p )

Still, you'd think developers would at least be pushing 8 channel MOD+added SFX channels given that several common trackers supported 8 channel stuff (and doing per-channel stereo panning was a bit obvious). Then again, PC games that started using MOD via the soundblaster also oddly limited things to just 4 channel setuff (with fixed stereo in the Pro/16) and no use of FM either. (odd that pretty much no PC game use FM+PCM in music, enough arcade and MD games certainly did ;))

I guess 6 channels with 4 ops would need memory for all of the phase accum. and the other channel info - and maybe he had small waveform tables rather than just generating sinewaves. ( and there's the program code as well )
But would all of that exceed more than a few kB? (he made it sound like it was taking a major chunk out of the available 128k -the framebuffer would obviously take a major chunk of that though)

Have you looked at the setup code - acos calls? It seems a little heavy in terms of calculation? I think I'd stick with stiching planar triangles into quads with saturn.
Heavy compared to line by line rasterization? (which was the context of it being an alternative for)

I guess the cache - and the wider ram
Wouldn't you need buffering beyond that cache to make use of the wider RAM? (ie source and destination buffers)

8 bit support on PSX would have been a terrible idea - after all you have full ( even 24 bit support ) already up to 640x and there is no vdp2 equiv to perform pallette lookup on the 8 bit pixels.
The GPU only supports 16bpp as it is, 24-bit mode doesn't allow hardware acceleration (probably mainly intended for high detail still images).

As for 8-bpp, it could have been useful if the GPU was designed to cater to it too with similar efficient use of bandwidth as in 16bpp mode. (buffering for phrases of 8-bit pixels, use of hardware dithered shading, etc)
Obviously you'd need CLUT support in a RAMDAC type set-up (like the 32x or VGA), and additional look-up support if hardware shading (especially with dithering) was to be supported.
It could have meant high resolution stuff without using as much framebuffer space or bandwidth as it does in 16bpp.

As it is, the best case for 640x480i stuff is to go single buffered and leave a decent amount for textures. (as long as you could sustain 30 FPS, you'd avoid tearing too -especially if each 640x240 field was organized and rendered separately) One of the later Tekken games does just that iirc. (single buffered 640x480)
Though, for composite video, 640x480 probably won't look a whole lot better than 320-384x480. (and 320x480 using single buffering wouldn't use any more framebuffer space than double buffered 320x240 -and for games that don't drop below 30 fps or do so rarely, tearing won't be an issue either)
Though perhaps 512 wide would have been more useful. (especially something close to a 12 MHz dot clock since that would be near square pixels in NTSC 480i)

It would be better to just support 16 bit in high res on the saturn ( maybe a mode where the memory was organised as 640x200 ). Though in the end most games ran at 320x on both Saturn and PSX - and the Saturn games that did run at high res didn't seeem to be penalised for not having lighting ( VF2 etc )
The Saturn games do seem to have lighting, but it was all heavily faceted/flat shaded. (which all model 2 stuff was anyway)

As it was, you could do 512x256 in 16bpp (512x512 interlaced?), granted that would leave a noticeable boarder in the VDP1 area (VDP2 could go beyond that). Too bad the Saturn doesn't have a dot resolution mode that fills 512 to the edge, or very close to the edge (like 10.74 MHz or a little higher). Then again, with the pixel resolution to VDP+CPU clock restriction, that might have slowed things down a lot. (ie 21.48 MHz CPU+VDPs . . . unless they'd changed the system to avoid that odd issue and at least allowed VDP2's clock speed to be isolated -and have the CPUs+VDP1 always at 28.6 MHz -or have VDP1 faster if possible)

Though for NTSC, within 256k, 640x200 wouldn't be as nice as 576x224 with a ~6 MHz dot clock (or slightly higher) since you'd get full-screen or very little boarder and near perfectly square pixels in interlaced mode.

Just checked - in 8 bit high res mode the VDP1 buffer is 1024x256, 512x512 is for low res VDP2 rotated VDP1 screen in 8 bits
Ah, OK, so games could be doing 714x512i (PAL) or 480i NTSC. (that assumes that it's using 1 field per framebuffer bank with VDP2 supporting interleaving fields for interlaced output . . . and if you can't maintain 30 Hz rendering, you'd either get torn/incomplete frames or repeated/line doubled frames if you let 1 buffer stay with VDP2 for both field periods -the latter would probably actually look better than the former, occassional drops to 240 line effective resolution rather than tearing)

Crazyace

06-23-2011, 04:23 PM

Cheaper than some advanced sample synth hardware no doubt, and perhaps the ensoniq chips Atari had been considering for the Panther (DOCII and OTIS), but I'd have thought Yamaha synth chips would have been getting pretty cheap by that point. (at least things like the YM2612, YM3812, YMF262, and perhaps YM2151 -margins vary, of course, and the 2151 had been produced in huge volumes but still may have been sold at a premium over the others . . . the 2612 was specifically aimed at low cost the an integrated -albeit lower quality- DAC with multiplexed mixing rather than adding the channels)

I think very cheap and general purpose ( In theory it's fast enough to decode mp3's ) - and integrated into Jerry. Also if you weren't using a heavy audio player it would be a 'general purpose' processor ( a situation hurt by the ram timing bugs )

However, by the time of the jaguar, things sample stuff was much more common anyway, and the DSP provided a nice set-up for that. (though, again, rather basic MOD seems to have been used very often)
I also recall mention of Atari providing a general midi compliant driver and sample set, and perhaps that's what Doom uses. (that might explain the excessive DSP bandwidth/overhead -mixing 16-24 channels- though you'd think Carmak would have opted to cut back to 8 or fewer channels if that were the case . . . or use the FM driver -though they'd need an appropriate composer with experience in FM . . . especially if Atari didn't have a ready-made tracker/MIDI driver for FM with a good set of default instruments)
Atari had a 8 channel music player ( + extra channels for sound fx ) that supported FM synth , Wavetable, and compressed samples - it was MIDI based. Other dev's rolled their own. ( Atari's source was in the SDK )

So doing 48-50+ kHz interrupts for playback routines don't eat heavily into RISC time? (especially with a full 32 registers to save per interrupt . . . unless there's something special about J-RISC interrupts . . . hmm, there is the dual banks of registers, can that be employed for fast ints? -ie reserve 1 bank solely for use within interrupts and the other left for normal operation)
From past discussions on this issue, it always comes up that interrupts are horribly inefficient with few exceptions (like the 6502), that's definitely the case with the 68k (more so than Z80) and with the SH2s in the 32x. (which is why lacking DMA support is such a big issue there, the FIFO and -especially- interrupt based schemes
eat up a ton of CPU time, the difference between a 4-8 channel player run via interrupts an a 32-64 channel player via DMA)
You answered your own question - ( you wouldn't need to reserve all of the registers ), interupt response is fast on the DSP.
Also with 44.1Khz you have nearly 600 cycles between interupts - so plenty of time to prepare the next output sample.

How is the Z80+DAC different in that respect? (it also must feed the DAC a byte at a time, manually . . . just with a much less powerful processor)
Though, again, interrupts aren't even an option there, so programmers are forced to use the more efficient cycle timed code route . . . except many screwed that up with crappy timing.
It wasn't a Z80+DAC , it was Z80 driving a Yamaha FM chip , with a single optional direct DAC mode on one channel.. so not the complete aim of the design.

And the general budget/software support . . . some poorly selling stuff still got good support due to the money being spent on it. (of course, that also ended up meaning a lot more money lost :p )
Still, you'd think developers would at least be pushing 8 channel MOD+added SFX channels given that several common trackers supported 8 channel stuff (and doing per-channel stereo panning was a bit obvious). Then again, PC games that started using MOD via the soundblaster also oddly limited things to just 4 channel setuff (with fixed stereo in the Pro/16) and no use of FM either. (odd that pretty much no PC game use FM+PCM in music, enough arcade and MD games certainly did ;))

I guess musicians authored on the Amiga :)

But would all of that exceed more than a few kB? (he made it sound like it was taking a major chunk out of the available 128k -the framebuffer would obviously take a major chunk of that though)
Double buffered 200x256x8bit is 100k :) - so not much left for samples... although I thought he might be talking about the dsp internal ram holding pointers etc to control playback.

Heavy compared to line by line rasterization? (which was the context of it being an alternative for)
In terms of setup on SH2 ( running the inverse trig lookups ) - Also, it would still generate 'double pixels' as it's a deformed quad, so I'm still not sure it's any better than the normal triangle drawing( textures still need to be preprocessed, you can't unwrap a texture applied to a whole mesh of triangles )
line by line would be really heavy in terms of setup though..

The GPU only supports 16bpp as it is, 24-bit mode doesn't allow hardware acceleration (probably mainly intended for high detail still images).

As for 8-bpp, it could have been useful if the GPU was designed to cater to it too with similar efficient use of bandwidth as in 16bpp mode. (buffering for phrases of 8-bit pixels, use of hardware dithered shading, etc)
Obviously you'd need CLUT support in a RAMDAC type set-up (like the 32x or VGA), and additional look-up support if hardware shading (especially with dithering) was to be supported.
It could have meant high resolution stuff without using as much framebuffer space or bandwidth as it does in 16bpp.

It would have been a lot of extra cost ( ramdac + logic to load pallette ) for little improvement. A 640x448 NTSC screen still left almost half the VRAM available for textures ( so more than would be available on Saturn/VDP1 )

As it is, the best case for 640x480i stuff is to go single buffered and leave a decent amount for textures. (as long as you could sustain 30 FPS, you'd avoid tearing too -especially if each 640x240 field was organized and rendered separately) One of the later Tekken games does just that iirc. (single buffered 640x480)
Though, for composite video, 640x480 probably won't look a whole lot better than 320-384x480. (and 320x480 using single buffering wouldn't use any more framebuffer space than double buffered 320x240 -and for games that don't drop below 30 fps or do so rarely, tearing won't be an issue either)
Though perhaps 512 wide would have been more useful. (especially something close to a 12 MHz dot clock since that would be near square pixels in NTSC 480i)

Turbo Prop racing also does this ( Rapid Racer in PAL ) - it gives you 640x448 @ 60Hz in the same way VF2 operates on Saturn.

http://www.youtube.com/watch?v=97cI5SwSLgY

kool kitty89

06-23-2011, 09:09 PM

I think very cheap and general purpose ( In theory it's fast enough to decode mp3's ) - and integrated into Jerry. Also if you weren't using a heavy audio player it would be a 'general purpose' processor ( a situation hurt by the ram timing bugs )
Manufacturing the ASIC itself wouldn't have been too cheap . . . cheap relative to off the shelf alternatives of similar power, but no cheap compared to simpler sound devices. (otherwise Atari's POKEY definitely would have been cheaper than the YM2149 which you argued the opposite of ;) -Atari owned the IP, so just paying for the manufacturing without royalties)

But yes, compared to a fast RISC CPU or even a more limited DSP (of similar raw power for some things, but without CPU-like task capabilities), it would almost definitely be much cheaper. (would have been nice to introduce on Atari's computers had they still been around ;) . . . and if they hadn't already introduced the 56k in the Falcon, leaving a precedent for compatibility -for that matter, it would have been interesting if they'd licensed the old Flare DSP for use in the ST line earlier on)

Atari had a 8 channel music player ( + extra channels for sound fx ) that supported FM synth , Wavetable, and compressed samples - it was MIDI based. Other dev's rolled their own. ( Atari's source was in the SDK )
It's a bit odd then that so many seem to use MOD formatted stuff, and it seems that some of the 8 channel drivers also used amiga (or STe) like fixed L/R stereo rather than per-channel panning.

You answered your own question - ( you wouldn't need to reserve all of the registers ), interupt response is fast on the DSP.
Also with 44.1Khz you have nearly 600 cycles between interupts - so plenty of time to prepare the next output sample.

Is that efficient interrupt functionality basically the same on the GPU? (that's a really nice feature of the RISC that I hadn't realized, though that use of the 2nd register bank is something I wonder about before, that would have been a really useful feature to have on general CPU designs)

It wasn't a Z80+DAC , it was Z80 driving a Yamaha FM chip , with a single optional direct DAC mode on one channel.. so not the complete aim of the design.
In many, many cases it was the 68k driving PSG+FM with the Z80 doing absolutely nothing but handling PCM playback. Some engines did both on the Z80, and several of those were crap (early pre-SMPS Z80 drivers had to halt FM/PSG to play samples and later ones tended to be among the more distorted sounding drivers) while 68k based drivers tended to be more foolproof (though Capcom took that route and still failed to manage even PCM). The best examples do all sound on the Z80 and manage even playback (if not on the fly decompression and/or mixing). EA had one of those drivers, though the actual arrangements/compositions used by EA were often below average (well, at least compared to Japanese and European stuff). Tiido's hombrew Z80 driver is among the most advanced doing all FM+PSG and 2 23 kHz 7-bit PCM channels. (it's padded to 8-bit PCM in ROM iirc, but formatted to 7-bit to avoid overflow when mixing -if not for the slow DAC register, it could be preferable to interleave to 44-46 kHz instead)

Of course, the Z80 in general only makes sense due to backwards compatibility, and even there it's configured rather inefficiently (the slow bank switching mechanism, lack of boosted clock speed, etc -lack of timer interrupts made it tougher to work with as well -be it for more foolproof PCM playback or for much slower timing for tempo or software PSG envelopes).
If it wasn't for embedded SMS compatibiltiy, it would have been far, far more efficient to scrap the Z80 entirely and add a basic DMA sound channel instead. (even a Mac style set-up -and using hblank DMA for sound like mac/amiga could also avoid contention issues with Vblank VDP transfer)

This is a totally off topic though, and something that's already been discussed in several other threads. (and covering several other shortcomings SMS compatibility forced . . . well, forced due to the way that compatibility was implemented -ie tacked on via reserved VDP die space or added board space+components . . . and not even directly cart compatible at that -so a fully active adapter could have been employed with little difference on the consumer end)

I guess musicians authored on the Amiga :)
Sort of, except you had a ton of pure FM synth stuff on PC (though few really decent drivers -let alone good or great ones), a lot of MT-32 support, and quite rapid General Midi, GUS, and waveblaster/AWE32 support. (I think Ensoniq cards got pretty decent support too, though it might mostly be re-arranged general midi stuff -most GUS and AWE32 also seems to take that route, well a lot of FM too with some better optimzied than others)
Though the lack of PCM samples to complement FM was quite odd. (there's a very small handful of games that did that, and usually only into the intro/demo screen . . . that opposed to a large portion of MD games doing so -albeit many with rather low quality samples- and even several notable Atari ST games doing that -like Wings of Death, Lethal Excess, and the Turrican games)

Double buffered 200x256x8bit is 100k :) - so not much left for samples... although I thought he might be talking about the dsp internal ram holding pointers etc to control playback.
Yes, that's assuming they were using that resolution, but from the look of many of the demos, they were probably using 256x200x4-bit more often, and single buffering may have been a realistic possibility too. (actually it seems flare was assumign single buffering would be standard as they later commented that many developers wanted more RAM to facilitate page flipping)

Of course, it's not limited to 256x200 either, it's totally programmable up to 256 lines and horizontal well into overscan. (which would be around 280 pixels on most TVs for that 5.97 MHz dot clock)

With 128k, double buffered 8bpp stuff would simply be unattractive, and given the amount of tearing seen in some of the 3D demos (2D stuff may have been mostly 50 Hz rendering, but I noticed a little tearing there too), they were indeed likely using single buffering, and probably for the 16 color stuff too. (line drawing is actually slower in 16 color mode -not sure on the details, but that seems to be a non-issue for normal 2D blitting and 16 color stuff should be faster to render as such -and steal less for the display)

I'll stop now though as I'm way off topic again. ;)

It would have been a lot of extra cost ( ramdac + logic to load pallette ) for little improvement. A 640x448 NTSC screen still left almost half the VRAM available for textures ( so more than would be available on Saturn/VDP1 )

It would be less than Saturn, wouldn't it? (512k for textures in the Saturn vs 464 kB -both supporting 4 and 8-bit textures with look-up support)
Granted, the PSX has all 2 MB of CPU work RAM at 33 MHz 32-bit vs only 1 MB at 28 MHz 32-bit on the Saturn. (so faster DMA updates for added texture data when needed)

Turbo Prop racing also does this ( Rapid Racer in PAL ) - it gives you 640x448 @ 60Hz in the same way VF2 operates on Saturn.
Hmm, what would happen if it dropped below 60 Hz rendering speed? (would it tear, or end up repeating the same field twice as I mused on earlier -or could you program it do do one or the other?)

Crazyace

06-24-2011, 10:01 AM

Manufacturing the ASIC itself wouldn't have been too cheap . . . cheap relative to off the shelf alternatives of similar power, but no cheap compared to simpler sound devices. (otherwise Atari's POKEY definitely would have been cheaper than the YM2149 which you argued the opposite of ;) -Atari owned the IP, so just paying for the manufacturing without royalties)

The sound system was meant to be advanced - so reverb/echo/effects were also supported, not just music playback.

It's a bit odd then that so many seem to use MOD formatted stuff, and it seems that some of the 8 channel drivers also used amiga (or STe) like fixed L/R stereo rather than per-channel panning.
I found that in the jaguar the object processor and blitter would effectively starve the DSP of memory cycles, and in some cases it was difficult to play more than 8 channels with sample playback.

Is that efficient interrupt functionality basically the same on the GPU? (that's a really nice feature of the RISC that I hadn't realized, though that use of the 2nd register bank is something I wonder about before, that would have been a really useful feature to have on general CPU designs)
Yes - You also have something similar (FASTIRQ) on ARM , and MIPS had very low latency IRQ's ( at the cost of always reserving 2 registers k0/k1 )

Yes, that's assuming they were using that resolution, but from the look of many of the demos, they were probably using 256x200x4-bit more often, and single buffering may have been a realistic possibility too. (actually it seems flare was assumign single buffering would be standard as they later commented that many developers wanted more RAM to facilitate page flipping)

Of course, it's not limited to 256x200 either, it's totally programmable up to 256 lines and horizontal well into overscan. (which would be around 280 pixels on most TVs for that 5.97 MHz dot clock)

256x200x4bit is barely equal to an ST - 256 colours would be the minimum for Flare. Plus I expect that double buffering would be the norm, ( as on ST and Amiga games - even Spectrum games ) 3D stuff in particular would need double buffering.

It would be less than Saturn, wouldn't it? (512k for textures in the Saturn vs 464 kB -both supporting 4 and 8-bit textures with look-up support)
Granted, the PSX has all 2 MB of CPU work RAM at 33 MHz 32-bit vs only 1 MB at 28 MHz 32-bit on the Saturn. (so faster DMA updates for added texture data when needed)

Maybe... for 448 ( NTSC ) you'd have 464K - 480(PAL) only leaving 434K - VDP1 has 512K shared with commands - assuming a worst case 2000 polys/frame double buffered you'd have 387K for textures, 2000 polys/frame single buffered ( or 1000 double ) would leave 450K

Hmm, what would happen if it dropped below 60 Hz rendering speed? (would it tear, or end up repeating the same field twice as I mused on earlier -or could you program it do do one or the other?)
Panic!

kool kitty89

06-27-2011, 04:43 AM

256x200x4bit is barely equal to an ST - 256 colours would be the minimum for Flare. Plus I expect that double buffering would be the norm, ( as on ST and Amiga games - even Spectrum games ) 3D stuff in particular would need double buffering.
You could always do single buffering at the expense of tearing (which is rather prevalent in some of the Multisystem tech demos).
For 3D stuff, you'd probably be using color hold mode too, so very low bandwidth for actually drawing the polygons. (just using the line draw function and the video controller does the rest ;) -of course, you'd need space to buffer the 3D coordinates, drawing commands, and many other things a game needs, obviously)

As for 16 colors being "barely ST" level . . . that's only true for static frames, and there's the 12-bit RGB to consider too (and compared to STe -which is obviously 12-bit, the blitter is substantially faster).
For 32 color Amiga stuff, you'd have to cut back on certain things (doing multi-plane BGs is difficult, especially without fastRAM -with FastRAM you, of course, get a lot more freedom to eat into what would normally be CPU bus time . . . at least if a game supports that), you could limit most of the graphics to fewer planes and do faster blits for that (and limit color heavily too), and dual playfield mode is worse than using a single 16 color plane by a good margin (worse in color, but better for rendering flexibility due to the discrete, independently scrolling framebuffers).

With tactful use of palette swaps (something that should have been quite flexible in the Slipstream compared to the limits of the MD or hassle of the SNES -MD artifacting heavily if you do more than 3 or 4 colors between lines, SNES having other issues) 16 color bitmap graphics could have been fine for many, many things in the early 90s period. (especially from the perspective of the European computer game market -which was what the Flare 1/Slipstream was most prominently aimed at in the first place, but still rather favorable compared to the likes of the Mega Drive and PC Engine -with various trade-offs, obviously)

And if you WERE doing 2D stuff in 256 colors, you'd probably use the palette index reginster to segment that into 4 16 color palettes to facilitate use of 4-bit indexed textures.

This is a separate topic though, so I'll stop there, again. ;)

Maybe... for 448 ( NTSC ) you'd have 464K - 480(PAL) only leaving 434K - VDP1 has 512K shared with commands - assuming a worst case 2000 polys/frame double buffered you'd have 387K for textures, 2000 polys/frame single buffered ( or 1000 double ) would leave 450K
Where does the PSX GPU have its drawing commands buffered?

Panic!
What, so the VDP will spaz out and go into a ridiculous sync rate that could risk killing a TV? :p . . . Or just have tearing? (like many PC gamers suffered with until SVGA -or, more generally, until VGA mode 13h fell out of common use)
OTOH, if it repeated the same field twice for an interlaced fame, that would result in a different (less noticeable) sort of change.

Crazyace

06-27-2011, 08:40 AM

Where does the PSX GPU have its drawing commands buffered?
Main memory - the commands are DMA's across by the gpu as needed.

What, so the VDP will spaz out and go into a ridiculous sync rate that could risk killing a TV? :p . . . Or just have tearing? (like many PC gamers suffered with until SVGA -or, more generally, until VGA mode 13h fell out of common use)
OTOH, if it repeated the same field twice for an interlaced fame, that would result in a different (less noticeable) sort of change.

Not quite that bad - but the interlaced mode on PSX was a bit wierd, not just 2x 224 line buffers :) -

Crazyace

06-27-2011, 09:46 AM

You could always do single buffering at the expense of tearing (which is rather prevalent in some of the Multisystem tech demos).
For 3D stuff, you'd probably be using color hold mode too, so very low bandwidth for actually drawing the polygons. (just using the line draw function and the video controller does the rest ;) -of course, you'd need space to buffer the 3D coordinates, drawing commands, and many other things a game needs, obviously)

Tearing is actualy not linked to single buffering, you get it when double buffering without Vsync.
Colour hold also isn't really as good as you think - you can't draw poly's on top - as you need to know the underlying colour to restore on the right side of the poly. You could line a per line linked list of poly edges , but it soon becomes more expensive than just blitting the lines.

As for 16 colors being "barely ST" level . . . that's only true for static frames, and there's the 12-bit RGB to consider too (and compared to STe -which is obviously 12-bit, the blitter is substantially faster).
Unless you go high res ( with the memory penalties ) it is barely ST level. 256 compared to 320 pixels. The flare blitter also operates in 4bit pixel chunks, and needs a read / modify, so it's actually slower than if it were in 256 colour mode.
That's why I think the target was the 256 colour mode

For 32 color Amiga stuff, you'd have to cut back on certain things (doing multi-plane BGs is difficult, especially without fastRAM -with FastRAM you, of course, get a lot more freedom to eat into what would normally be CPU bus time . . . at least if a game supports that), you could limit most of the graphics to fewer planes and do faster blits for that (and limit color heavily too), and dual playfield mode is worse than using a single 16 color plane by a good margin (worse in color, but better for rendering flexibility due to the discrete, independently scrolling framebuffers).
Is this in comparision to the Slipstream ASIC? or just talking about Amiga? - Again I think that 256 colour mode is the sweet spot , otherwise the Amiga is way more flexible. Even h/w scrolling is limited to 4 pixel steps in 4 bit mode ( 2 pixel in 256 colour mode )

With tactful use of palette swaps (something that should have been quite flexible in the Slipstream compared to the limits of the MD or hassle of the SNES -MD artifacting heavily if you do more than 3 or 4 colors between lines, SNES having other issues) 16 color bitmap graphics could have been fine for many, many things in the early 90s period. (especially from the perspective of the European computer game market -which was what the Flare 1/Slipstream was most prominently aimed at in the first place, but still rather favorable compared to the likes of the Mega Drive and PC Engine -with various trade-offs, obviously)

The are no hardware sprites though - so you would have to split the 16 physical colours into a group of global sprite colours, and then pallette swap the rest - ( just as you would on an ST ), even the Amiga can have 16 colours and a seperate 16 for hardware sprites.

And if you WERE doing 2D stuff in 256 colors, you'd probably use the palette index reginster to segment that into 4 16 color palettes to facilitate use of 4-bit indexed textures.

This is a separate topic though, so I'll stop there, again. ;)

You'd be more likely to just use 256 colours ( or 128 colours for mixed mode would be nice ).

kool kitty89

06-28-2011, 04:02 AM

Tearing is actualy not linked to single buffering, you get it when double buffering without Vsync.
Well, tearing is related to lack of v-sync in general . . . except you can't use v-sync with single buffering unless you can render as fast as the refresh rate. (there's also the separate issue of timing single-buffered rendering to stay consistently ahead of or behind the pixels actively being scanned to the screen -or you'd even get tearing or similar artifacts if you can render at 50/60 Hz -of course, that's limited to systems that allow video memory access in active display)

Tearing can also occur if you render too fast (part of that issue for staying in sync with the scan rate for single buffering), though that's something that many modern games have started sacrificing in favor of greater detail (especially for action-oriented games) where developers feel that tearing is worth the faster updates, not to mention facilitating double buffering without disadvantages to triple buffering. (PC games tend to make that optional, but console games unfortunately seem to force it -which some people complain about . . . of course frame limiting also gets complaints, but making it optional would solve that issue ;))

Unless you go high res ( with the memory penalties ) it is barely ST level. 256 compared to 320 pixels.
If you mean plain display (not actual rendering or games, but static screen capabilities), yes, the ST is fairly close (STe more so), though the actual screen resolution is not fixed at 256x200 pixels, it's totally programmable given what's mentioned in the Slipstream documentation. (it can go up to 256 lines, and I think up to at least 320 pixels -double that for high res- but I'm not positive on the horizontal limits)
Of course, on a normal TV (due to the ~6 MHz dot clock), you'd only be able to see about 280x224 pixels for NTSC (much like the Neo Geo), so between the 2 resolutions the MD supports (common 5.37 MHz 256 wide and the 320 wide 6.71 MHz), while the ST of course has a huge boarder at normal TV calibrations due to the 8 MHz dot clock and 200 line limit. (if not for the SHIFTER's addressing limits, the ST should display close to 382x224 pixels on an average TV -or closer to 409x240 on a TV with perfect calibration for the normal NTSC frame size -most TVs have considerable excess of overscan- and custom calibration could obviously show more or less overscan)

And actually, you really wouldn't want to limit it to 256 pixels as that would not only leave a boarder, but make scrolling sloppier. (there's an 8-pixel boarder alignment limit for the video controller iirc, so if you didn't have overscan to mask things, you could get rather jerky pop-in/out at the edges -though you could also address that with a bit of blitter clean-up work each frame)

Another nice thing about the Slipstream's resolution is near-square pixels in NTSC (closer than any other console or home computer at the time unless you count the Neo Geo), albeit that still means rather wide pixels for PAL vs the Amiga's near perfect square pixels at double the NTSC color clock. ;) (ST is a bit too tall in PAL, but much better than NTSC at least)
OTOH, the MD's 6.7 MHz mode is a very happy medium between NTSC and PAL square pixels. (so games with no TV-specific art design will be slightly off on both, but not terrible -unlike the common 5.37 MHz which looks slightly wide in NTSC and horribly wide in PAL or 7.16 MHz which is way too tall in NTSC and near perfectly square in PAL)

The flare blitter also operates in 4bit pixel chunks, and needs a read / modify, so it's actually slower than if it were in 256 colour mode.
That's why I think the target was the 256 colour mode
That's for masking (or single pixel manipulation in general), right? (for straight block copy, 4-bit should have a significantly faster than with 8-bit, so some things should balance out with the overhead for additional pixel manipulation)

Is this in comparision to the Slipstream ASIC? or just talking about Amiga? - Again I think that 256 colour mode is the sweet spot , otherwise the Amiga is way more flexible. Even h/w scrolling is limited to 4 pixel steps in 4 bit mode ( 2 pixel in 256 colour mode )
Hmm, hadn't realized the hardware scrolling was limited to word allignment, that's too bad. (though it would also mean fast block-move based blitter scrolling would have fewer trade-offs -also working on words)

Aren't there a lot more trade-offs between the flare chipset and Amiga? (blitter bandwidth being a major one -not to mention 3D)

The are no hardware sprites though - so you would have to split the 16 physical colours into a group of global sprite colours, and then pallette swap the rest - ( just as you would on an ST ), even the Amiga can have 16 colours and a seperate 16 for hardware sprites.
Yes, or you could swap the sprite colors as well (for shading effects -water line, lighting, etc) or use full palette swaps for areas of the screen where some (or all) sprites won't interact

You'd be more likely to just use 256 colours ( or 128 colours for mixed mode would be nice ).
But, again, wouldn't that simply use too much memory? (if you had more RAM to work with, that would certainly be simplest -even for a cart based system, you could compress/index textures and unpack them to RAM as plain 8bpp graphics- but with the limited RAM and use of disk -or cost if they had used ROM with a lot of uncompressed stuff- 4bpp stuff would be much more attractive for many things)

And why would you have to split 128 colors for a mixed mode? (why not use 16 banks of 16 colors and use all 16 banks for designated 8bpp textures -sort of like how the SNES's 256 color modes 3 and 4 use the entire set of sprite+BG palettes for the colors on 8bpp tiles)

Crazyace

06-28-2011, 06:33 AM

If you mean plain display (not actual rendering or games, but static screen capabilities), yes, the ST is fairly close (STe more so), though the actual screen resolution is not fixed at 256x200 pixels, it's totally programmable given what's mentioned in the Slipstream documentation. (it can go up to 256 lines, and I think up to at least 320 pixels -double that for high res- but I'm not positive on the horizontal limits)
Are you sure - the slipstream doc I'm looking at only talks about a fixed 256 or 512 pixel screen ( with 3 graphics modes )

That's for masking (or single pixel manipulation in general), right? (for straight block copy, 4-bit should have a significantly faster than with 8-bit, so some things should balance out with the overhead for additional pixel manipulation)
For any blitting with 4 bit pixels. ( because of alignment )

Hmm, hadn't realized the hardware scrolling was limited to word allignment, that's too bad. (though it would also mean fast block-move based blitter scrolling would have fewer trade-offs -also working on words)

To scroll 200x256 pixels using the blitter at 50fps is 51200x50x2(r/w) for 8 bit mode, or x3 for 4 bit mode ( r/r/w ) - so either 5 million or 7.6 million cycles. With no video at all there are only 6 million cycles/second - so using the blitter for full screen scrolling isn't possible at full frame rate even in PAL. This doesn't compare well with the Amiga or Ste.

But, again, wouldn't that simply use too much memory? (if you had more RAM to work with, that would certainly be simplest -even for a cart based system, you could compress/index textures and unpack them to RAM as plain 8bpp graphics- but with the limited RAM and use of disk -or cost if they had used ROM with a lot of uncompressed stuff- 4bpp stuff would be much more attractive for many things)
Yup - memory is a real limitation, 256K would be better.

And why would you have to split 128 colors for a mixed mode? (why not use 16 banks of 16 colors and use all 16 banks for designated 8bpp textures -sort of like how the SNES's 256 color modes 3 and 4 use the entire set of sprite+BG palettes for the colors on 8bpp tiles)
Priority - you can have foreground and background, and sprites go behind foreground pixels. The blitter doesn't expand 4bit to 8bit pixels, so it's not really practical to use 16 banks of 16 colour sprites.

Thenewguy

06-28-2011, 01:25 PM

There's also the cartridge issue with the N64, very bad idea and rather arrogant on Nintendo's part (to think they couldn't lose their key 3rd party devs or to think they didn't need to compete with flexible low cost mass storage)

And with such media, Nintendo probably would have continued their reign in Japan and got much better support for the hardware even without better tools.I'm, not too sure about this these days to be honest.

Cartridge use or not it seems strange to me that a company who had always historically had like >80% of the Japanese market, and who had a very successful start (N64 first few months in Japan had huge sales) still had next to zero support from the entire country's software industry.

The Japanese do not do business in the same way as the west, its all about company alliances, loyalty's, and honour on top of making profit, there should have been more support, its not as though there was no money to be made with the N64, there was still profit there.

I think that cartridges probably played the biggest part, but I think another important factor was simply that Nintendo had spent the last 10 years openly disrespecting these Japanese companies, treating them poorly, being very controlling, and these companies wanted a change, Sony gave them an opportunity.

Look at Namco as an example to this, in regards to Namco it didn't matter whether the N64 was cartridge or CD, because Namco simply refused to support Nintendo's console regardless, they'd been trying to escape from Nintendo since the late 80s when Yamauchi publically humilliated the Namco boss by making him apologise for criticising him (he effectively said "make a public apology, or Namco is not going to be allowed to make NES games anymore, and NES has 90% of the market so lets see how well you do without us), Namco never had the chance to completely leave Nintendo without risking their business until Sony came onto the scene, Namco threw themselves completely behind the PS1 and ended up being a big reason for it becoming popular during the early days in the west.

On top of that, when you look at the 3rd party support of the N64 by region, its not balanced at all, virtually all of the major western companies supported the N64 with some software (Electronic Arts, Acclaim, Activision, Midway from the US, Ubisoft, Ocean, Eurocom, DMA Design, Software Creations, Factor 5 from Europe). On the Japanese side the only big 3rd party company who supported the system was Konami, with pretty decent support coming from Treasure too, everything else was generally just small numbers of games from lessor known companies.

So we have a system with loads of Mortal Kombat games, but not even one Street Fighter game from Capcom (not even the 3D EX games)

Even when Japanese games became huge and did end up ported to N64 (such as Resident Evil 2, and Ridge Racer 64) the ports were handled by US companies, I'm pretty sure both of the deals for these games being ported to N64 were actually suggested by the US companies too.

On top of that, lets say N64 had been CD, it still would not have been in Squaresoft's interest to put Final Fantasy on N64. Sony pumped huge amounts of money into the western release of FF7, christ knows how much, or whether it was always part of the agreement between the two companies in the 1st place, but the fact of the matter is that Sony gave Final Fantasy 7 the kind of exposure and backing that would've never happened under Nintendo.

On top of that we have Sony buying up companies (such as Psygnosis) for exclusives, and we know that they actually paid Core a hefty amount of money to make Tomb Raider 2 console exclusive to PS1.

So, personally I think the lack of software was Cartridges + ill feeling towards Nintendo + Sony actively seeking out, funding, and buying up exclusives.

Even if the N64 was released with CDs, it may have still had some problems getting the best software, if Capcom and Namco actually had issues with Nintendo their support would've still been low, and Sony may have still grabbed Squaresoft and other companies through use of lucrative deals (and simple diplomacy) etc.

Obviously they would've still been in a much better position than they actually ended up though.

kool kitty89

06-29-2011, 04:55 AM

Are you sure - the slipstream doc I'm looking at only talks about a fixed 256 or 512 pixel screen ( with 3 graphics modes )
Looking again, I don't see a specific reference to higher widths, but also no mention of that being a fixed limit.
It definitely mentions the limits on the scanline end (programmable up to 256 lines -warning about NTSC overscan as well and suggesting a 200 line limit), but nothing on horizontal res limits.

Wait, there it is: "the screen may begin on any 256 byte boundary, or any 128 byte boundary in low-res" so not possible to go beyond that. (assuming there's no way to allow low-res to operate on a 256 byte boundary like high-res 16 colors and have 512xXXX with everything beyond ~280 pixels in overscan -or ~300 on tighter calibrated TVs or monitors)

Hmm, for that matter, it would have been rather useful if the ST had had a 4 MHz dot mode that extended into overscan (same pixel resolution as the C64 too, though potential to fill the entire ~190 pixels with no visible horizontal boarder), and into vertical overscan too if they modified the screen addressing further for that mode. (leaving it the same as 8 MHz 320x200 would obviously be simpler)
Even further off topic now. :p

For any blitting with 4 bit pixels. ( because of alignment )
The Blitter is byte-addressible, right, so couldn't you blit 4bpp objects moved at 2 pixel increments horizontally (single pixel vertically, as always) without the added overhead?

To scroll 200x256 pixels using the blitter at 50fps is 51200x50x2(r/w) for 8 bit mode, or x3 for 4 bit mode ( r/r/w ) - so either 5 million or 7.6 million cycles. With no video at all there are only 6 million cycles/second - so using the blitter for full screen scrolling isn't possible at full frame rate even in PAL. This doesn't compare well with the Amiga or Ste.
How about comparing cases of multi-layer scrolling, but not full screen for every layer. (in most practical cases of parallax, there's a lot of open space that would need to be blitted . . . and on the Amiga you do have dual playfields, but with worse color than the Slipstream -and you could also blit much of the BG as low color stuff for less bandwidth on the STe/Amiga but again drop color/detail substantially)
And on the Amiga, even with zero CPU/video contention, there's only 3.58M memory cycles per second (and much less than that available to the blitter, even if the CPU was in fastRAM) and 4M on the ST (but with much less available to the blitter due to contention for video and CPU).

Yup - memory is a real limitation, 256K would be better.
I wonder if they considered using DRAM in the "fast RAM" block, or a mix of DRAM and PSRAM/SRAM. They only mention "fast RAM" (~167 ns or 2 clock cycle accesses) being supported in the 256k video memory address range rather than "slow RAM" (namely DRAM with no FPM support) with ~250 ns/3 clock accesses supported in the expansion region. (albeit, that also would be a non-issue if the expansion bank for "slow RAM" supported 16-bit memory rather than 8-bit)

Then again, by the time of the Multisystem (nearing 1990), maybe DRAM could have been used directly with 167 ns cycle times. (it would have meant using faster DRAM -perhaps in the 65-70 ns range- and thus more cost, but still probably a fair bit cheaper than the SRAM or PSRAM originally planned -and using a mix of fast and slow RAM could still have been an option too -but having it all 16-bits wide would have made more sense)

Priority - you can have foreground and background, and sprites go behind foreground pixels. The blitter doesn't expand 4bit to 8bit pixels, so it's not really practical to use 16 banks of 16 colour sprites.
Hmm, and I suppose doing a software assisted indexing scheme would mean more overhead than it was worth. (so slow that plain 16 color rendering would probably make more sense)

As for priority . . . that would work to facilitate more than one BG layer too, right? (but with further divisions of colors -like using 2-bits for priority rather than 1 and limiting to 64 colors)
Hmm, couldn't that also facilitate effects somewhat like the Amiga's shadow (or MD shadow/HL) using banks of colors with different shades? (though not as straightforward as using planar graphics -on the ST you could obviously do a shadow-like effect by limiting to 3 bits for 8 colors and 1 bit toggling between 2 banks of different shades)

I'm, not too sure about this these days to be honest.

Cartridge use or not it seems strange to me that a company who had always historically had like >80% of the Japanese market, and who had a very successful start (N64 first few months in Japan had huge sales) still had next to zero support from the entire country's software industry.
No, Nintendo had dropped well below 80% in the early 90s, averaging about 60% for the SFC, and only if you include 1995 sales onward (if you compare for when the MD was more notable and PCE/CD was near its peak, the SFX should have been well below 50%), of course, FC sales added in would skew things considerably. ;)

The Japanese do not do business in the same way as the west, its all about company alliances, loyalty's, and honour on top of making profit, there should have been more support, its not as though there was no money to be made with the N64, there was still profit there.

I think that cartridges probably played the biggest part, but I think another important factor was simply that Nintendo had spent the last 10 years openly disrespecting these Japanese companies, treating them poorly, being very controlling, and these companies wanted a change, Sony gave them an opportunity.
That's hardly a Japanese specific problem. Nintendo's harsh strong-arm tactics totally pissed off western developers too (and increasingly fed up as time went on), and that's part of what enabled Sega to take hold in the early 90s (on top of good management). Nintendo eventually eased up on some of those issues, but stood firm on others. (they eliminated the licensing restrictions for publishing on competing platforms, but they retained most of the horribly limiting cart allocation/volume/manufacturing constraints -Sega OTOH had allowed 3rd party cart manufacturing from close to day 1 on the MD)

Nintendo's stubbornness and overbearing need for control was (and still is IMO) their biggest weakness.

If it hadn't been for Sony, Sega probably would have ended up taking the lead in the west and perhaps Japan in the 5th generation, in spite of their other problems. (granted, with no Sony, Sega would have screwed up a lot less too -given how many mistakes seem to be directly spurred by fears of Sony)

Look at Namco as an example to this, in regards to Namco it didn't matter whether the N64 was cartridge or CD, because Namco simply refused to support Nintendo's console regardless, they'd been trying to escape from Nintendo since the late 80s when Yamauchi publically humilliated the Namco boss by making him apologise for criticising him (he effectively said "make a public apology, or Namco is not going to be allowed to make NES games anymore, and NES has 90% of the market so lets see how well you do without us), Namco never had the chance to completely leave Nintendo without risking their business until Sony came onto the scene, Namco threw themselves completely behind the PS1 and ended up being a big reason for it becoming popular during the early days in the west.
There's still one major thing I don't understand:
Why didn't publishers just go unlicensed and manufacture their own carts?
The main thing stopping that in the west was lockout (which several got around anyway), but that was totally absent in Japan, leaving the FC as vulnerable to unlicensed publication as the VCS had been.

Was that simply up to culture too, or did Nintendo have some nastier ways of enforcing things. (they tried to get retailers to pull unlicensed games in the west in rather illegal ways -like refusing to distribute to said retailers- and I can only imagine that Japan would be far more open to such things given the looser business laws -in the US that would probably have gotten trumped in court rather quickly -if it evne made it to court, much more straightforward than the Nintendo contract controvercy)

On top of that, when you look at the 3rd party support of the N64 by region, its not balanced at all, virtually all of the major western companies supported the N64 with some software (Electronic Arts, Acclaim, Activision, Midway from the US, Ubisoft, Ocean, Eurocom, DMA Design, Software Creations, Factor 5 from Europe). On the Japanese side the only big 3rd party company who supported the system was Konami, with pretty decent support coming from Treasure too, everything else was generally just small numbers of games from lessor known companies.
Capcom did some stuff on the N64 too, but much less than the PSX or Saturn. (Mega Man 64 jumps to mind)

So we have a system with loads of Mortal Kombat games, but not even one Street Fighter game from Capcom (not even the 3D EX games)

Even when Japanese games became huge and did end up ported to N64 (such as Resident Evil 2, and Ridge Racer 64) the ports were handled by US companies, I'm pretty sure both of the deals for these games being ported to N64 were actually suggested by the US companies too.
And that really makes sense since the US was the only market the N64 sold really well in . . . not unlike the Dreamcast. (except Nintendo didn't pull the plug in early 1998 like Sega did in early 2001 . . . except the DC was generally much lower risk to develop for -clean tools for smooth ports from PC/etc, low cost media, etc -and a lot more potential for falling into the role of a lower-cost alternative console due to use of a cheap/common CD-ROM drive and generally low-cost hardware)

On top of that, lets say N64 had been CD, it still would not have been in Squaresoft's interest to put Final Fantasy on N64. Sony pumped huge amounts of money into the western release of FF7, christ knows how much, or whether it was always part of the agreement between the two companies in the 1st place, but the fact of the matter is that Sony gave Final Fantasy 7 the kind of exposure and backing that would've never happened under Nintendo.
Yes, and Nintendo had a lot of liquid assets to compete there too . . . of course, they'd need to get their heads out of their collective assets and fight fire with fire rather than doing their own thing regardless of 3rd party or mass market interests. ;)

OTOH, there IS the issue of providing enough contention to induce cross-platform publishing. (something that Sega might have been able to manage with FFVII . . . obviously they didn't have the clout to totally pull Square to their side, but they might have had a chance in splitting interest enough for a multiplatform release)

On top of that we have Sony buying up companies (such as Psygnosis) for exclusives, and we know that they actually paid Core a hefty amount of money to make Tomb Raider 2 console exclusive to PS1.
Yes, though Nintendo had the ability to do that as well (either via raw cash or investment spending . . . and Sega was probably still healthy enough in '94 early 1995 to swing some hefty investment spending -buying up CORE before US Gold got their mits on them would have been wise . . . even without hindsight there was a pretty obvious risk of losing a very strong almost 2nd party developer)

So, personally I think the lack of software was Cartridges + ill feeling towards Nintendo + Sony actively seeking out, funding, and buying up exclusives.
Yes, and Nintendo doing absolutely nothing to right wrongs . . . the very use of carts was a big part of perpetuating Nintendo's old ways.
Had they changed their BS and been open and competitive to 3rd party needs, CD-ROM (or similar optical format) would have been an obvious must-have. (catering to low-cost, low-risk, flexible manufacturing and publishing -not just compared to cards, but compared to Nintendo's horribly limiting centralized manufacturing/distribution -hell, in that respect, a Sega released cart based console would have been far more attractive to publish for than the N64 ;) . . . games probably would have been a bit cheaper too)

On that note: Was Tomb Raider II ever even planned for the N64? (the lack of the Saturn release is a bit moot as the Saturn was basically dead in the west by late 1997 anyway, but N64 would have been quite significant -obviously there was a PC release, which is the only way I remember it from back in the day, albeit only from the demo)

Even if the N64 was released with CDs, it may have still had some problems getting the best software, if Capcom and Namco actually had issues with Nintendo their support would've still been low, and Sony may have still grabbed Squaresoft and other companies through use of lucrative deals (and simple diplomacy) etc.

Obviously they would've still been in a much better position than they actually ended up though.
Yes, and had nintendo done CD (or similar) but retained all their bad policies, they might have boosted market share/interest enough early on in Japan to keep the momentum going strong enough to attract 3rd parties regardless.

Crazyace

06-29-2011, 06:50 AM

Looking again, I don't see a specific reference to higher widths, but also no mention of that being a fixed limit.
It definitely mentions the limits on the scanline end (programmable up to 256 lines -warning about NTSC overscan as well and suggesting a 200 line limit), but nothing on horizontal res limits.
There is a section that shows the screen modes as 256/512 pixels .. and if you look at the registers there is nothing 'width' related, and when the cycle timing for cpu is discussed it's a fixed period ( 40us from 64us ) where the 8088 is locked out of the bus. This implies extremely strongly that the width is not programmable.

Hmm, for that matter, it would have been rather useful if the ST had had a 4 MHz dot mode that extended into overscan (same pixel resolution as the C64 too, though potential to fill the entire ~190 pixels with no visible horizontal boarder), and into vertical overscan too if they modified the screen addressing further for that mode. (leaving it the same as 8 MHz 320x200 would obviously be simpler)
Even further off topic now. :p
Yes :)

The Blitter is byte-addressible, right, so couldn't you blit 4bpp objects moved at 2 pixel increments horizontally (single pixel vertically, as always) without the added overhead?
Yes , but now you cant mask on single pixels, and the stepping is poor ( You might as well go to 16bit mode for straight memory copying )

How about comparing cases of multi-layer scrolling, but not full screen for every layer. (in most practical cases of parallax, there's a lot of open space that would need to be blitted . . . and on the Amiga you do have dual playfields, but with worse color than the Slipstream -and you could also blit much of the BG as low color stuff for less bandwidth on the STe/Amiga but again drop color/detail substantially)
And on the Amiga, even with zero CPU/video contention, there's only 3.58M memory cycles per second (and much less than that available to the blitter, even if the CPU was in fastRAM) and 4M on the ST (but with much less available to the blitter due to contention for video and CPU).
As I said the Slipstream's advantage is it's 256 colour mode. The point about the blitter timing was that it wasn't fast enough to make up for the lack of pixel accurate h/w scrolling.

Hmm, and I suppose doing a software assisted indexing scheme would mean more overhead than it was worth. (so slow that plain 16 color rendering would probably make more sense)
Dont forget - the cpu was completely locked out during display..

As for priority . . . that would work to facilitate more than one BG layer too, right? (but with further divisions of colors -like using 2-bits for priority rather than 1 and limiting to 64 colors)
Hmm, couldn't that also facilitate effects somewhat like the Amiga's shadow (or MD shadow/HL) using banks of colors with different shades? (though not as straightforward as using planar graphics -on the ST you could obviously do a shadow-like effect by limiting to 3 bits for 8 colors and 1 bit toggling between 2 banks of different shades)
Maybe - the blitter was quite a bit limited though ( I dont think it was possible to blit 4 bit pixels with transparent colours based on the documentation - you would have to waste a 'plane' )

Thenewguy

06-29-2011, 03:37 PM

No, Nintendo had dropped well below 80% in the early 90s, averaging about 60% for the SFC, and only if you include 1995 sales onward (if you compare for when the MD was more notable and PCE/CD was near its peak, the SFX should have been well below 50%), of course, FC sales added in would skew things considerably. ;)This section is very misleading.

To get a proper picture you would have to at least think about Famicom sales, because the PC-Engine's total for Japan was made up of 3 years worth of PC-Engine Vs Famicom sales, before the SNES existed. In fact, from what I've heard the PC-Engine's heydey was actually over when the SNES arrived.

The total sales for the region probably do indicate ~60%, but if you're looking at marketshare then the Japan marketshare video on Youtube indicates that by the turn of the 5th generation the SNES had probably buried these consoles, and Nintendo was probably back up to its previous dominance.

That's hardly a Japanese specific problem. Nintendo's harsh strong-arm tactics totally pissed off western developers tooWestern developers don't tend to turn down easy money based on personal issues.

and that's part of what enabled Sega to take hold in the early 90s (on top of good management).I can't really think of any western companies with vendetta's towards Nintendo tbh

Even US companies such as Atari, who had reason to hold grudges seemed to carry on supporting Nintendo consoles

There's still one major thing I don't understand:

Why didn't publishers just go unlicensed and manufacture their own carts?I would guess that this would be dishonourable, but I don't know, maybe there was some more physical reason for it. It does seem to follow the trend over there though, there was never an early attempt to just put software on Famicom without permission from what I've seen (even though the 1st year was very low on games, whilst the system was huge).

In the early days Namco and Hudson apparently formally visited Nintendo and asked them for permission to make games for the machine, Nintendo turned them down but changed their mind a few months later.

Capcom did some stuff on the N64 too, but much less than the PSX or Saturn. (Mega Man 64 jumps to mind)I think they made two games, Mega Man 64 (end of 2000), which was two whole years later than the PS1 version (three years if going by the original Japanese releases), and a Tetris game with Mickey Mouse in it, the Resident Evil port was made by Angel Studios.

Not really much to write home about, and if anything i'd take their releases as being insulting to be honest.

And that really makes sense since the US was the only market the N64 sold really well inNot really, every console has to start somewhere, where were the early 3rd party releases? its not like the system started off decent and then had 3rd party support tail off.

The N64 had a huge Japanese launch, and sold a lot in its 1st few months and then nosedived in popularity in Japan simply because there was no software, and not much being previewed. Games which were to be released in 1996, should've been started on during a time when industry analysts were still predicting the N64's dominance.

In fact, if Mobygames is right then the only 3rd party company who actually supported N64 in 1996 was Midway, with Acclaim's Turok ready for early 1997.

Looking at the early releases, it seems to me that the only major 3rd party Japanese companies who even had N64 projects on the go at all during the lead up to the system's launch were Konami, Hudson (2 games by end of 1997), and Treasure ( 1 game by end of 1997).

. . . not unlike the Dreamcast.Dreamcast had early support, most of the major companies made at least one or two games for the system within the 1st year (Namco, Konami, Capcom, Hudson, Taito, Atlus).

With Dreamcast as soon as the PS2 was nearing many of the Japanese companies completely lost interest in support, with N64 the support was never really there to begin with.

Yes, and Nintendo had a lot of liquid assets to compete there too...I don't think Nintendo even liked sharing profits with 3rd parties much to be honest, they seem to have always acted like they were directly competing with them, Sony were in a different position as they needed the 3rd parties to make their system successful, and at that stage didn't have popular in-house studios of their own.

Sony needed to create an identity of their own at that stage, whilst Nintendo didn't, I would imagine that Sony would've always been more hospitable to 3rd parties than Nintendo, even now Nintendo rarely throw their money around, I wouldn't have seen them entering any kind of a bid war with Sony for Final Fantasy 7.

OTOH, there IS the issue of providing enough contention to induce cross-platform publishing. (something that Sega might have been able to manage with FFVII . . .I sincerely doubt it, I mean how much money must Sony has actually spent marketing Final Fantasy 7?! it must have been astronomical, no way in hell was Final Fantasy 7 going to be appearing on any other systems, Squaresoft would've had to have been fools to jeapardize that kind of deal, especially when you add the subsequent Final Fantasy's (and Sony even released the never before released older SNES titles in Europe on top of that).

Even as it was Squaresoft could've cleaned up in Japan even if they'd just released a low key RPG for N64, the Japanese were crying out for anything, why did they put so many on the PS1 and none on N64? some of their games, such as Brave Fencer Musashi didn't even include any FMV.

Was Tomb Raider II ever even planned for the N64? (the lack of the Saturn release is a bit moot as the Saturn was basically dead in the west by late 1997 anyway, but N64 would have been quite significant -obviously there was a PC release, which is the only way I remember it from back in the day, albeit only from the demo)It wasn't initially planned, and as I said Core signed a console exclusivity deal with Sony (this is corroborated in interviews in Retrogamer)

Yes, and had nintendo done CD (or similar) but retained all their bad policies, they might have boosted market share/interest enough early on in Japan to keep the momentum going strong enough to attract 3rd parties regardless.The N64 was late anyway, 3rd parties didn't want to support it at all, and using a CD drive would've added another $100 to the hardware cost, 3rd parties were searching for a way out from Nintendo for years, the only way Nintendo could've kept those Japanese 3rd parties was to release their hardware competitor mid 1995 at latest and completely kill the PS1 and Saturn markets before they could get started, thereby stopping them from being viable alternatives, and allowing Nintendo to continue forcing 3rd parties to support them under their unreasonable conditions, its quite possible that had NEC actually made a decent job of selling their system in the US the SNES may well have lost a ton of its Japanese support.

By 1996 those machines already had healthy userbase's, 3rd parties knew they could be profitable, and had no interest in being raped by Nintendo for another 10 years.

Another problem is, that generation's change to 3D shook up the Japanese software industry and ended up with certain companies gaining a lot of importance, whilst others struggled to learn 3D graphics, the changeover put Sega and Namco into a very good position because due to their arcade markets they had become experienced with the sorts of games which had become popular in Japan (Sega due to innovation, and creating the trends, and Namco with their constant copying and polishing of Sega titles)

Sega were exclusive to Saturn, and Namco hated Nintendo with a passion and totally supported PS1, so early on N64 was always going to have problems finding key racing games, and key fighting games (the two most important genre's at the beginning of that generation, remember that FPS was unpopular in Japan, and 3D platformers became more prominent in the 2nd half) for Japan, until the other companies caught up.

Generally I agree with you, CDs were the dumbest move by Nintendo, all I'm saying is I disagree that -

"Nintendo probably would have continued their reign in Japan and got much better support for the hardware even without better tools."

I think its feasible that Sony could've still won that generation, based on their earlier release, good development environment, Squaresoft's desertion of Nintendo possibly being money orientated, and some key companies (such as Namco) still refusing to support N64.

kool kitty89

06-30-2011, 05:10 AM

There is a section that shows the screen modes as 256/512 pixels .. and if you look at the registers there is nothing 'width' related, and when the cycle timing for cpu is discussed it's a fixed period ( 40us from 64us ) where the 8088 is locked out of the bus. This implies extremely strongly that the width is not programmable.
Hmm, I hadn't realized that (I'd thought you at least got interleaved CPU accesses like the blitter), then again they did mention plans for adding a separate CPU bus for the later version with 8086 and totally avoiding contention. (which would be much more significant still if the CPU was locked out in active display)

Yes :)
Hardware scrolling would have been a lot more useful . . . but low res probably would have been much simpler/cheaper than even just H/V scroll registers. (packed pixels would have taken more logic too -at least for variable color depths- though maybe 8 bitplanes for low-res 160x200 would be doable -maybe with direct RGB or intensity shifts for the added 4 bits rather than added CRAM -something you mentioned before)
WAY off topic again though. ;) (not that anyone minds)

Yes , but now you cant mask on single pixels, and the stepping is poor ( You might as well go to 16bit mode for straight memory copying )
Couldn't you optimize a renderer to do straight block copys for parts of objects and do finer blits for masking the edges? (granted, that would only be useful for rather large objects, or smaller objects that were positioned on word boundaries)

As I said the Slipstream's advantage is it's 256 colour mode. The point about the blitter timing was that it wasn't fast enough to make up for the lack of pixel accurate h/w scrolling.
Yes, and the 3D (and pseudo 3D) capabilities were a major advantage as well. ;)

Use of 256 colors definitely would have had fewer trade-offs with more RAM. (be it for the multisystem -using disks- or for a ROM based console -so you could have most/all graphics compressed/indexed in ROM and unpacked to plain 8bpp textures in RAM)

Hmm, actually, given the more 8bpp oriented blitter, it might have been more useful to have a low-res 256 color mode rather than the 256 width 4-bit mode (or in addition to that) . . . 3 MHz dots would be a bit too low res though (especially if limited to 128 pixels), though if they could use 3.58 or (probably easier -being a division of 12) 4 MHz, it would be useful for a number of things (some low-res 2D games and probably more so for some 3D/pseudo 3D games -especially ray-casting stuff where 1/2 horizontal res would basically double game speed). Albeit, making the actual pixel resolution something other than 128 or 256 bytes might have been problematic and 128 pixels would (again) be pretty low (albeit Doom on the 32x ran at that) . . . maybe they could use the 256 bytes addressing at the lower dot clock and simply not use all of the screen in overscan (use it for other data -which would display as garbage, but would be off-screen and unimportant).
Even a 3 MHz 128 pixel mode would have had some utility. (probably a nice option if a Doom port was forthcoming ;) -or Wolf 3D, more realistically . . . though Doom might have ended up better than on the SNES in any case)

Maybe - the blitter was quite a bit limited though ( I dont think it was possible to blit 4 bit pixels with transparent colours based on the documentation - you would have to waste a 'plane' )
I was talking about in 8bpp mode, and I meant using the palette index register to assist in shading for something less intensive than software look-up. (in either case such effects would involve multiple passes to some degree for shading/translucency effects -using simple dithering should be simpler and faster though, but obviously not look as nice for many things)

On another note: in your opinion, how does the Slipstream compare to the Panther? (both in terms of raw capabilities and for the market at the time)

And finally getting back to the 5th generation topic:
How much potential does the N64 have for pushing 2D compared to the PSX and Saturn (or 3DO or Jag for that matter).
From what I understand, it has a lot of raw potential (bandwidth and flexibility that could be made to cater to 2D -ie with 2D optimized RSP code) but simply was never really pushed for 2D in game development. (let alone getting a 2D customized microcode . . . though short of that, the "turbo 3D" code SGI offered would have probably been best -at least omitting many of the more intensive and unnecessary effects and dramatically increasing fillrate)

This section is very misleading.

To get a proper picture you would have to at least think about Famicom sales, because the PC-Engine's total for Japan was made up of 3 years worth of PC-Engine Vs Famicom sales, before the SNES existed. In fact, from what I've heard the PC-Engine's heydey was actually over when the SNES arrived.
Yes and no, it's generally difficult and misleading to compare open market share in general (cross-generational) . . . in that context, Sega never really overtook Nintendo in North America (NES market share would supplement SNES considerably -I think the closest to a lead was the low 40% range for Sega . . . of course, there's different ways of expressing market share that skews things more -hardware sales, software sales, revenue, etc).

As for the PCE's "heyday" in general. The hucard format was past its heyday by the time the SFC launched in 1990, but the PCE-CD was still super hot and rising from what I understand (it was THE format for the PCE with cards being minor/niche -with few exceptions -SFII being a big one), and of course the Super CD and Duos were a significant boost. (Arcade card got decent support but really came too late . . . probably should have done 768k or 1 MB a year or so earlier -perhaps something like 256k SRAM for full compatibility with the Super CD and an added 512k of cheap DRAM)

1994 seems to be when the PCE CD started notably declining, though was still quite notable for a few more years. (probably much more in software sales than hardware)
The complete lack of duo sales figures makes this harder to quantify, especially since that seems to have been an extremely popular form factor for the format in Japan.

The total sales for the region probably do indicate ~60%, but if you're looking at marketshare then the Japan marketshare video on Youtube indicates that by the turn of the 5th generation the SNES had probably buried these consoles, and Nintendo was probably back up to its previous dominance.
That video doesn't show 1995, so the picture is a bit vague (odd that the PCE doesn't even show up in '96 though)

Western developers don't tend to turn down easy money based on personal issues.
Yes, but it wasn't "easy" money due to Nintendo's policies, there were many things that were a huge pain in the ass for 3rd party publishers (not as bad as the NES days, but still bad).
Not quite the same as personal issues, but a similar route cause on Nintendo's part.

I can't really think of any western companies with vendetta's towards Nintendo tbh
Not vendettas, but reduced interest in publishing/developing due to headaches of Nintendo's policies. Luckily for Nintendo, they were at least smart enough to curtail the bullshit of the NES days and compete more evenly with the mass market (they fought against ratings too, but eventually got stuck with those and benefitted greatly from reduced censorship ;)), but the SNES and N64 were still pretty bad in that respect. (DS is too iirc)
And, of course, even aside from the restricting contracts (especially distribution and manufacturing) there was the inherent cost of using ROMs. (Nintendo inflated that cost further though -both monetarily and due to overhead from dealing with Nintendo's own distribution/manufacturing policies)

Even US companies such as Atari, who had reason to hold grudges seemed to carry on supporting Nintendo consoles
Atari Corp never published on a Nintendo console, though Atari games kept doing so . . . the fact that Nintendo cut out the worst parts of the NES contracts helped a lot. (they still seemed to favor the MD significantly though)
The main reason they went unlicensed on the NES was due to the horribly restricting licensing contracts . . . a shame they went to all that trouble with the Rabbit chip though, and the resulting litigation. (when the simple and cheap voltage spike mechanism -a la codemasters- was effective and legally foolproof)

I would guess that this would be dishonourable, but I don't know, maybe there was some more physical reason for it. It does seem to follow the trend over there though, there was never an early attempt to just put software on Famicom without permission from what I've seen (even though the 1st year was very low on games, whilst the system was huge).
Maybe Nintendo was involved with the Mafia behind the scenes. :p

OTOH, I think some western publishers actually DID go unlicensed in Japan. I recall Tengen staff mentioning that they started work on FC game development well before the release of the NES . . . though they were associated with Namco at that point too, so probably would have published through them anyway. (though after 1985 that wouldn't have been the case -Atari Games became a self-owned company in '86, unlike '84 with Warner and '85 with Namco)

Not really, every console has to start somewhere, where were the early 3rd party releases? its not like the system started off decent and then had 3rd party support tail off.
Exactly, the system started off strong, ended up with 1st/2nd party software that really matched the market demands, and marketed thing well.
3rd parties jumped in after that market share was established, obviously. ;)

The N64 didn't get that in Japan, so it's unclear whether strong market share would have been enough to keep strong 3rd party interest.

If it WAS just about personal issues, why didn't Namco, Capcom, etc jump ship back in the late 80s or early 90s with NEC and/or Sega?

The N64 had a huge Japanese launch, and sold a lot in its 1st few months and then nosedived in popularity in Japan simply because there was no software, and not much being previewed. Games which were to be released in 1996, should've been started on during a time when industry analysts were still predicting the N64's dominance.
New software was pretty sparse for the first year or so in the west too, but that didn't stop it from being huge. ;)

In fact, if Mobygames is right then the only 3rd party company who actually supported N64 in 1996 was Midway, with Acclaim's Turok ready for early 1997.
Shadows of the Empire was released in '96. (missed black Friday, but still well in time for Christmas -though not in Europe or Japan)
Hmm, though that was actually Nintendo published, definitely not 2nd party (let alone 1st party) developed, but obviously funded/collaborated/partnered. (so more like Sony with Tomb Raider II)
All those Lucas Arts games got PC version too at some point (a couple on PC first, most examples on PC months later -of course plenty of PC exclusives from LucasArts too)

Looking at the early releases, it seems to me that the only major 3rd party Japanese companies who even had N64 projects on the go at all during the lead up to the system's launch were Konami, Hudson (2 games by end of 1997), and Treasure ( 1 game by end of 1997).
I thought Square started working on FFVII for the N64 and didn't jump to the PSX until some time in 1996. (if not very late '96)

With Dreamcast as soon as the PS2 was nearing many of the Japanese companies completely lost interest in support, with N64 the support was never really there to begin with.
So the DC was better off in general. (ie more JP support, possibly more potential to get a resurgence in the long run -if the US market continued to do well- and much more potential to at least get N64-like support from Western developers)

I don't think Nintendo even liked sharing profits with 3rd parties much to be honest, they seem to have always acted like they were directly competing with them, Sony were in a different position as they needed the 3rd parties to make their system successful, and at that stage didn't have popular in-house studios of their own.
Nintendo needed 3rd parties too, as did Sega . . . without 3rd parties they wouldn't have been nearly as profitable as they were (Nintendo more so than Sega -since Sega had SO much more variety and volume in-house -and more outsourced development for that matter).
Nintendo was (and is) horribly arrogant for thinking otherwise.

Hell, even with the VCS, where there were no royalties for Atari, 3rd party developers probably helped Atari a great deal to become as big as it was (and they were still selling hardware for profit too, though software was the big chunk), though royalties would obviously have been nice too. (and had Atari management been smart, maybe they could have arranged a favorable licensing agreement before suing)
Of course, the bad 3rd party developers are often noted for contributing to the crash, though it was really Warner/Atari themselves that made the biggest mistake there. (the single biggest problem was the heavily flawed distribution network that led to hugely inflated sales/demand/growth projections and subsequent

Sony needed to create an identity of their own at that stage, whilst Nintendo didn't, I would imagine that Sony would've always been more hospitable to 3rd parties than Nintendo, even now Nintendo rarely throw their money around, I wouldn't have seen them entering any kind of a bid war with Sony for Final Fantasy 7.
Sony seems to have taken a page from Sega's book, at least in as far as using many of the same tactics as Sega had (especially SoA) in the 4th generation. (albeit with some additional moves, especially those facilitated by massive spending -though to some extent, Sega actually did that too, albeit mostly via investment/deficit spending and more practically limited than what Sony did -and Sony almost cloned Sega's marketing/advertising style/theme as well, at least by 1996/1997)

I sincerely doubt it, I mean how much money must Sony has actually spent marketing Final Fantasy 7?! it must have been astronomical, no way in hell was Final Fantasy 7 going to be appearing on any other systems, Squaresoft would've had to have been fools to jeapardize that kind of deal, especially when you add the subsequent Final Fantasy's (and Sony even released the never before released older SNES titles in Europe on top of that).

Hmm, I suppose so, and Sony did allow a PC release after all.
Maybe if NEC had been well managed and competitive, they could have actually contended directly with Sony. (but between the general management/marketing mistakes for their game market, the massive decline of their computer monopoly in Japan in the early 90s, and the inadequate PC-FX, there was no chance for that)

The N64 was late anyway, 3rd parties didn't want to support it at all, and using a CD drive would've added another $100 to the hardware cost, 3rd parties were searching for a way out from Nintendo for years, the only way Nintendo could've kept those Japanese 3rd parties was to release their hardware competitor mid 1995 at latest and completely kill the PS1 and Saturn markets before they could get started, thereby stopping them from being viable alternatives, and allowing Nintendo to continue forcing 3rd parties to support them under their unreasonable conditions, its quite possible that had NEC actually made a decent job of selling their system in the US the SNES may well have lost a ton of its Japanese support.
Late for Japan, but perfectly timely for the US (the N64 launched just as the 5th generation kicked off in earnest in the US, sort of like the SNES had in 1991 -except the PSX had a much bigger bias in sales than the Genesis) . . . and also not really late at all compared to the FC to SFC gap. ;)

As for the added price, it should have been more like $50 for a cheap/well negotiated basic 2x (or perhaps 4x) CD drive, even less for just the basic mechanism and a license for a CD-ROM chipset (which required more investment, but cheaper in the long run).
The extreme low cost of the media and flexibility would have been a much bigger advantage than a $250 price point. (of course, if Nintendo broke another area of stubbornness and sold at a loss like Sony -let alone Sega ;) - they should have managed $200 with CD-ROM on top of that)

By 1996 those machines already had healthy userbase's, 3rd parties knew they could be profitable, and had no interest in being raped by Nintendo for another 10 years.

The situation really wasn't much different than Sega in 1990/91, except Sony had more money to throw around. (and the SFC/SNES's lingering presence wasn't quite as strong as the NES/FC had been in 1990/91)

Another problem is, that generation's change to 3D shook up the Japanese software industry and ended up with certain companies gaining a lot of importance, whilst others struggled to learn 3D graphics, the changeover put Sega and Namco into a very good position because due to their arcade markets they had become experienced with the sorts of games which had become popular in Japan (Sega due to innovation, and creating the trends, and Namco with their constant copying and polishing of Sega titles)
Hmm, yes, it seems like western developers didn't have that problem to nearly as great an extent. (maybe in part due to computer games being more popular earlier on -in Japan, the biggest 3D houses prior to the Saturn/PSX would have been arcade developers, and mainly Sega and Namco)

Sega were exclusive to Saturn, and Namco hated Nintendo with a passion and totally supported PS1, so early on N64 was always going to have problems finding key racing games, and key fighting games (the two most important genre's at the beginning of that generation, remember that FPS was unpopular in Japan, and 3D platformers became more prominent in the 2nd half) for Japan, until the other companies caught up.
There were probably some western arcade/computer games that Nintendo could have attracted (or actively funded conversion of) to the N64, probably better than what they got early on too. (ie the likes of Crusin USA -though that actually sold fairly well in the US)

Generally I agree with you, CDs were the dumbest move by Nintendo, all I'm saying is I disagree that -

"Nintendo probably would have continued their reign in Japan and got much better support for the hardware even without better tools."
Yes, CD alone wouldn't have been enough . . . Nintendo would have needed a dramatic head-out-of-ass surgery to really remain competitive (at least changing policies to cater to 3rd parties, if not making actual apologies to certain individuals ;)).
And again, the very lack of CD alone was part of that persisting stubbornness.

Crazyace

06-30-2011, 09:17 AM

Hardware scrolling would have been a lot more useful . . . but low res probably would have been much simpler/cheaper than even just H/V scroll registers. (packed pixels would have taken more logic too -at least for variable color depths- though maybe 8 bitplanes for low-res 160x200 would be doable -maybe with direct RGB or intensity shifts for the added 4 bits rather than added CRAM -something you mentioned before)
WAY off topic again though. ;) (not that anyone minds)
Packed pixels shouldn't have taken much logic - but that's a different topic ( Atari ST ) and given hardware scrolling ( and a blitter ) it wouldn't have been an issue anyway :(

Couldn't you optimize a renderer to do straight block copys for parts of objects and do finer blits for masking the edges? (granted, that would only be useful for rather large objects, or smaller objects that were positioned on word boundaries)
Alignment is actually more of an issue - and then there's the problem that optimising a renderer will take both more cpu time and blitter setup time - just going to 8 bit is easier :)

Yes, and the 3D (and pseudo 3D) capabilities were a major advantage as well. ;)
Not really much evidence - Fred Gill mentions "Starfox at 5fps best" on the Multisystem website.

Hmm, actually, given the more 8bpp oriented blitter, it might have been more useful to have a low-res 256 color mode rather than the 256 width 4-bit mode (or in addition to that) . . . 3 MHz dots would be a bit too low res though (especially if limited to 128 pixels), though if they could use 3.58 or (probably easier -being a division of 12) 4 MHz, it would be useful for a number of things (some low-res 2D games and probably more so for some 3D/pseudo 3D games -especially ray-casting stuff where 1/2 horizontal res would basically double game speed). Albeit, making the actual pixel resolution something other than 128 or 256 bytes might have been problematic and 128 pixels would (again) be pretty low (albeit Doom on the 32x ran at that) . . . maybe they could use the 256 bytes addressing at the lower dot clock and simply not use all of the screen in overscan (use it for other data -which would display as garbage, but would be off-screen and unimportant).
Even a 3 MHz 128 pixel mode would have had some utility. (probably a nice option if a Doom port was forthcoming ;) -or Wolf 3D, more realistically . . . though Doom might have ended up better than on the SNES in any case)
Going low res would have been a terrible idea, given the competition all running at 320 pixels ( or higher in the case of the Amiga ) - I don't think that a Doom game would run that well on a 6MHz 8088 ( or 8086 ) anyway, so designing hardware around it is a little excessive.

I was talking about in 8bpp mode, and I meant using the palette index register to assist in shading for something less intensive than software look-up. (in either case such effects would involve multiple passes to some degree for shading/translucency effects -using simple dithering should be simpler and faster though, but obviously not look as nice for many things)
Yes you could implement a shadow effect by using the lfu to and source with destination, along with an ordered pallette ( you'd effectively reduce the number of colours due to duplication between 'lit' and 'shadowed' sections )

On another note: in your opinion, how does the Slipstream compare to the Panther? (both in terms of raw capabilities and for the market at the time)

I dont know , both are 'vapourware' products. The Panther seems way better for 2D scrolling 50/60Hz games - but the Konix has more colours per line, and can handle busier screens at the cost of framerate.

And finally getting back to the 5th generation topic:
How much potential does the N64 have for pushing 2D compared to the PSX and Saturn (or 3DO or Jag for that matter).
From what I understand, it has a lot of raw potential (bandwidth and flexibility that could be made to cater to 2D -ie with 2D optimized RSP code) but simply was never really pushed for 2D in game development. (let alone getting a 2D customized microcode . . . though short of that, the "turbo 3D" code SGI offered would have probably been best -at least omitting many of the more intensive and unnecessary effects and dramatically increasing fillrate)

N64 offered 500MB/s bandwidth , so on paper that's at least 4x PSX with nothing else on the bus. There are some nice 2D style games ( Yoshi's Story, Mischeif makers ) on the N64.

Thenewguy

06-30-2011, 01:36 PM

As for the PCE's "heyday" in general. The hucard format was past its heyday by the time the SFC launched in 1990, but the PCE-CD was still super hot and rising from what I understandI'm not sure, I would need more info on Turbo Duo sales (I would imagine it would've been the system of choice during the 90s)

The PC-Engine reportedly sold ~7 million in Japan (according to Famitsu it was actually closer to 6 million), I've heard that there were roughly 3 million white PC-Engine's, I think that they discontinued the white at the end of 1989 for the Core version, selling through white stock throughout 1990, comparing a couple of Famitsu sales figures indicates that the Core's were selling only ~150,000 odd a year in Japan by 1993 and 1994. So well over 1/3rd of the total PC-Engine sales, maybe even as much as half, happened prior to the release of the Super Famicom.

By 1994 there were ~4 million non-CD PC-Engine's in Japan, so if sales were petering out in 1994 I guess we've got the left over 2-3 million as DUO sales

it's generally difficult and misleading to compare open market share in general (cross-generational) . . . in that context, Sega never really overtook Nintendo in North AmericaThing is, if half the PC-Engine sales were prior to the SNES' release, then it may not have taken that much actual marketshare from SNES.

Its different with US Genesis sales, because the SNES actually caught up with the Genesis' lifetime sales in the US within months of its release, and the actual competition only started in earnest at that point, with them effectively on a level with each other, and the marketshare for each subsequent year being fairly equal

Exactly, the system started off strong, ended up with 1st/2nd party software that really matched the market demands, and marketed thing well.

3rd parties jumped in after that market share was established, obviously. ;)You've got a "chicken or the egg" thing going here, did the N64 get no software support in Japan because of low sales, or did the N64 not sell very well in Japan because it didn't get enough software support.

If 3rd parties always ignored systems with low marketshare from the outset then they wouldn't get any software, and would all fail before they can get the marketshare in the 1st place.

N64 was coming from a huge name, it had a lot of hype, and it had big prospects, there should've been decent 3rd party Japanese support from the outset.

Major 3rd parties from the US didn't wait for N64 to gain marketshare, as said before Acclaim, Midway, and Electronic Arts all had games out by early 1997, they must have all started projects before (or around) the time the N64 was released.

Another weird thing about the N64 lead up hype, was the whole "Dream Team" stuff, I don't think anyone was convinced by that, I mean why were Nintendo hyping up the inclusion of these generally unknown or at times even unliked companies? where were the actual big Japanese companies? the whole thing was just odd. The Dream Team actually make me wonder if Nintendo already knew they were going to have trouble getting software support sometime in 1995.

If it WAS just about personal issues, why didn't Namco, Capcom, etc jump ship back in the late 80s or early 90s with NEC and/or Sega?Like I already mentioned (I prob should've elaborated), Namco did jump ship in the late 80s, their boss criticised Yamauchi's for essentially monopolistic practices

"Nintendo is monopolising the market, which is not good for the future of the industry"

According to Game Over he also stated "companies kept silent because Nintendo was too strong; to question Hiroshi Yamauchi when their businesses depended on Nintendo was suicide"

In response Nintendo stated that Namco was greedy, and jealous, at which point Namco said that they would support Nintendo's competition, the Mega Drive.

Namco's profits nosedived and their business started running into serious trouble (NES games had previously made up 40% of their earnings) Nakamura had to go back to Nintendo and apologise and ask for their NES licence back.

In fact, its quite possible that the thing with Namco may well have helped Nintendo to tighten their grip of 3rd parties, because it essentially showed that even the biggest 3rd party companies of Japan (one which was actually huge there before Nintendo) couldn't go up against them.

New software was pretty sparse for the first year or so in the west too, but that didn't stop it from being huge. ;)To be fair though there were a few key early titles released in the west, such as Turok, US based sports games, Mortal Kombat/Killer Instinct, and Cruisin' which were not the sort of games which were ever going to be popular in Japan (in fact half those games aren't really even that popular in Europe).

Japan's N64 release was also a few months earlier, so I guess they had a few months longer to lose interest than the US did.

I thought Square started working on FFVII for the N64 and didn't jump to the PSX until some time in 1996. (if not very late '96)According to Wiki they announced the move on January of 1996, I'm not sure how far Square had gotten with FF7, someone has argued in the past in a conversation I was in that it never got past tech demo stage.

Nintendo needed 3rd parties too, as did Sega.But Nintendo didn't acknowledge this, and they didn't run after 3rd parties either, not until the Gamecube era when it became apparent that they could no longer compete in variety anymore.

As for the added price, it should have been more like $50 for a cheap/well negotiated basic 2x (or perhaps 4x) CD driveI'm not an expert on CD prices through the ages, but I did look around as well as ask some people, and generally $100 is around the ball park which most seemed to agree on.

Someone also mentioned to me in the past, that the only reason Nintendo managed to compete on hardware price with the PS1 and Saturn was the lack of a CD drive, because the hardware itself was much more expensive to manufacture.

The situation really wasn't much different than Sega in 1990/91, except Sony had more money to throw around.Sega never had the home market in Japan with Mega Drive, and I've heard they also had an image there of being a little unreliable (putting out a lot of machines in succession)

Certainly not the same as Sony in the mid 90s, who were clearly taking the videogame market very seriously right from the beginning, and were known to have the money to back it up.

There were probably some western arcade/computer games that Nintendo could have attracted (or actively funded conversion of) to the N64, probably better than what they got early on too. (ie the likes of Crusin USA -though that actually sold fairly well in the US)Apart from Need For Speed (a definite possibility which would admittedly have been a good help) I can't think of many 3rd party games which would've been directly competitive with Sega or Namco's offerings in the 1996-1997 era, there'd be stuff like Burning Road I guess, the Tokyo Highway games, Battle Arena Toshinden for the 3D fighting genre :)

The only strong possibility I can see for N64-CD fighting game wise is Dead or Alive for ~1997, but I'm not sure how connected Tecmo were to Sega with that series at that point.

I think its possible that some of the European racers may have turned up, V-Rally may have made an appearance much earlier had N64 been CD based, maybe Codemasters would've put their games on the system (albeit their games seemed to only be popular in Europe, and they didn't have the distribution network set up to sell overseas anyway, in fact, I wonder if they would've been open to a deal with Sega on Saturn to publish overseas, being that their PS1 market was limited to Europe)

kool kitty89

07-07-2011, 03:22 PM

Not really much evidence - Fred Gill mentions "Starfox at 5fps best" on the Multisystem website.
What was the context of that? Was that for the existing Multisystem dev usnits using 8088s on a shared bus (without even having a bus latch) or the planned 8086 with latch and possibly separate CPU bus (notes in the technical manual mention plans for a dedicated CPU bus)?
Unless that figure is also taking into account a lot of DSP resource reserved for audio.

The SNES had comparably poor CPU resource to back up star fox as well (2.68 MHz in RAM, possibly 3.58 MHz in ROM depending on the game -plus time spent halted for VRAM updates) and the SFX had to deal with major bottlenecks of planar graphics (also needing to be composite planar tilemap formatted, plus the hefty DMA bottlenecks). And from the information I've seen, the SFX actually is lacking in some areas compared to the Flare DSP (seems to have a slower 16-bit multiply function at least) . . . though it may also be more general purpose. (possibly enough to offload some of the CPU overhead)
I was actually thinking the Flare DSP and SFX may have been directly related (vaguely similar general functionality, both designed by Ben Cheese, etc), but I'm not sure if there's any substantial relation.

Going low res would have been a terrible idea, given the competition all running at 320 pixels ( or higher in the case of the Amiga ) - I don't think that a Doom game would run that well on a 6MHz 8088 ( or 8086 ) anyway, so designing hardware around it is a little excessive.
Obviously you wouldn't be LIMITED to low-res, but have it as an option.
You've got the DSP to consider for offloading some of the overhead as well as the blitter (compared to purely software rendered PC games).
And if not Doom, then Wolf 3D at least, perhaps wing commander . . . after all, Carmak managed that on a vanilla SNES's 65816 alone (which is stuck at 2.68 MHz when working in RAM) rendering to a 112x96 8-bit packed pixel mode 7 screen, albeit SNES wind commander seems to use normal tile/sprite animation with no software rendering. (actually rather odd that some of the SFX games didn't use mode 7 . . . there's the 16k pixel limitation, but SNES Doom effectively used less than that anyway)

I dont know , both are 'vapourware' products. The Panther seems way better for 2D scrolling 50/60Hz games - but the Konix has more colours per line, and can handle busier screens at the cost of framerate.
What about ease of programming, or especially easy of porting games? (I got the impression that the Panther's rather "different" rendering mechanism wouldn't favor cross ports very well -sort of like the 7800- on top of the limited onboard RAM)

kool kitty89

07-07-2011, 04:53 PM

I'm not sure, I would need more info on Turbo Duo sales (I would imagine it would've been the system of choice during the 90s)

The PC-Engine reportedly sold ~7 million in Japan (according to Famitsu it was actually closer to 6 million), I've heard that there were roughly 3 million white PC-Engine's, I think that they discontinued the white at the end of 1989 for the Core version, selling through white stock throughout 1990, comparing a couple of Famitsu sales figures indicates that the Core's were selling only ~150,000 odd a year in Japan by 1993 and 1994. So well over 1/3rd of the total PC-Engine sales, maybe even as much as half, happened prior to the release of the Super Famicom.

By 1994 there were ~4 million non-CD PC-Engine's in Japan, so if sales were petering out in 1994 I guess we've got the left over 2-3 million as DUO sales
That's assuming Duo sales are even included in that 7 million figure, and not missing entirely.

In any case, NES's management/marketing decisions in Japan would have hardly helped things either. (SGX not being an add-on and been poorly marketed/managed/supported -and obviously not rolled into the Super CD or Duo standard, Arcade card coming too late and being a bit expensive -a 512k-1M card a year or so earlier probably would have made a lot more sense, and then the mess of the PC-FX -that's greatly simplifying things of course, and NEC had other major troubles in the early 90s with their home computer monopoly in Japan falling apart . . . and not addressing the much bigger mistakes they made in western markets)

Its different with US Genesis sales, because the SNES actually caught up with the Genesis' lifetime sales in the US within months of its release, and the actual competition only started in earnest at that point, with them effectively on a level with each other, and the marketshare for each subsequent year being fairly equal
I hadn't gotten that impression at all . . . I'd gotten the impression that the Genesis held a considerable lead in install base until 1994, though a slim one at times. Now, the SNES certainly sold far, far better in its first few months than the Genesis had up through 1990, but the Genesis really got going around the time of the SNES's release and held ahead in market share (with moderate existing install base building on that further).

Of course, market share had multiple areas to compare in general. (hardware, software -1st and 3rd party, revenue, etc)

You've got a "chicken or the egg" thing going here, did the N64 get no software support in Japan because of low sales, or did the N64 not sell very well in Japan because it didn't get enough software support.
Exactly, that's always the case . . . no one factor determines that outcome. Prior to the N64, Nintendo had major mitigating factors to hold firm and maintain support regardless of relations (huge brand recognition, interest in 1st party franchises, defacto 2nd party exclusives -especially Square).
However, they also had competition that didn't push quite as hard into extremes as Sony had . . . so Nintendo had even stronger opposition/frustration of 3rd party publishers AND even bigger 3rd party console competition to deal with.

Sega probably couldn't have pulled it off with the MD, but NEC had many of the attributes that Sony did with the PSX . . . they never pushed those advantages with the right management though. (Nintendo got lucky in that sense, but then again, so did Sega in the US/Europe given NEC's potential to push like Sony later would)

If 3rd parties always ignored systems with low marketshare from the outset then they wouldn't get any software, and would all fail before they can get the marketshare in the 1st place.
Most such systems rely on 1st/2nd party software alone for quite a while, or for the entire generation if they never gain strong marketshare. Albeit, if a company A. has a very strong reputation with powerful marketing/hype backing up the new product (PS2 would obviously be an extreme example there) that alone will drive support. (of course, Sony still poured tons of money into 1st/2nd party releases too)

The master system didn't get any notable 3rd party support at all for most of its life, neither did the 7800 (almost all as Atari published and Atari funded/commissioned). The Famicom started off with almost no competition on the market and with 1st party games alone too. (much like the 2600, but with weaker in-house development and a critical shift to allowing 3rd party support . . . with licensing royalties)
Some other early US consoles got 3rd party support too, but all unlicensed and thus far lower risk than what Nintendo offered. ;) (plus the Intellivision was backed by a major brand with powerful marketing/hype and strong in-house support, same with Colecovision -except Coleco wasn't nearly as strong a brand, but with a killer pack-in and good 1st party support)

N64 was coming from a huge name, it had a lot of hype, and it had big prospects, there should've been decent 3rd party Japanese support from the outset.
So what would the differences from that and the SNES be?
Were Sony's management/force/tactics the only major difference that made them a really competitive/attractive alternative to defect to compared to Sega or NEC? (OK, CD-ROM was an even bigger deal in 1994 than 1990 -plus Nintendo had promised a CD-ROM addon for the SNES, 3rd party publishers possibly weren't quite as pissed off as they were in '96 -though in the US, they were probably NOT as pissed as they'd been in the days of Nintendo's super limiting NES contracts, plus the ratings systems had been established-)

Hmm, for that matter, if Nintendo hadn't decided that CDs were contrary to their business model, the SNES CD probably WOULD have been released (albeit pretty late -probably '93 or '94), and that would have had more major implications on the market in general. (even stronger and longer late gen SNES market in Japan)
Though, again, the very acceptance of CD-ROM (without super tight provisions for exclusivity) would imply Nintendo was starting to accept more favorable terms with 3rd parties.

Major 3rd parties from the US didn't wait for N64 to gain marketshare, as said before Acclaim, Midway, and Electronic Arts all had games out by early 1997, they must have all started projects before (or around) the time the N64 was released.
Do you have any details on how Nintendo delegated things in the US vs Japan? It seems like (on top of the significant culture differences) that Nintendo was considerably harder on Japanese devs than western ones . . . though they'd been forced to soften things up a bit in the US already due to considerable competition from Sega. (not to mention mounting litigation on the NES publishing contracts)

So, in that respect, the cart based media probably would have been the only major issue with 3rd parties in the west. (and related manufacturing/distribution restrictions on Nintendo's part . . . well, and the overpriced development systems -though low cost 3rd party alternatives like the Dr. 64 soon arrived)

Like I already mentioned (I prob should've elaborated), Namco did jump ship in the late 80s, their boss criticised Yamauchi's for essentially monopolistic practices

"Nintendo is monopolising the market, which is not good for the future of the industry"

According to Game Over he also stated "companies kept silent because Nintendo was too strong; to question Hiroshi Yamauchi when their businesses depended on Nintendo was suicide"

In response Nintendo stated that Namco was greedy, and jealous, at which point Namco said that they would support Nintendo's competition, the Mega Drive.
What about the PC Engine? That was a far more significant competitor well before the MD got big in the west.
Then again, it may have been a fault on NEC's part. (aside from not pushing like Sony had in some areas, perhaps their licensing contracts were less attractive as well, not sure -I haven't seen anything on NEC's licensing policies . . . but they definitely could have done more like Sony and pushed harder for commissioned/bought out exclusives among other things)

But really, it would have made the most sense to jump to NEC first with weaker support for the MD. (plus push for plenty of computer game releases -MSX, PC88, PC98, and the new X68000, though PC gaming was obviously niche it should still have helped boost things -let alone international support . . . the master system and various western computer platforms were obviously significant in Europe -and SMS was on the market in the US well before the Genesis obviously)

Namco's profits nosedived and their business started running into serious trouble (NES games had previously made up 40% of their earnings) Nakamura had to go back to Nintendo and apologise and ask for their NES licence back.
And yet again, I wonder about the state of unlicensed development. Was it really just culture or something else?

That, and back to NEC vs Sony . . . if Namco dropped that much and that quickly in the late 80s, things had changed substantially by the mid 90s.
Hell, Sony specifically backed and supported Namco as a 2nd party partner with the PSX. NEC should have had the funding/clout in 1987/88 to push that too, but obviously didn't. (I wonder if Namco ever attempted any such partnership)

To be fair though there were a few key early titles released in the west, such as Turok, US based sports games, Mortal Kombat/Killer Instinct, and Cruisin' which were not the sort of games which were ever going to be popular in Japan (in fact half those games aren't really even that popular in Europe).
Yes . . . it's almost the polar opposite of what the Saturn got in that respect. (very US favorable releases, but Japan poor and so-so for Europe)

Japan's N64 release was also a few months earlier, so I guess they had a few months longer to lose interest than the US did.
Is it just me, or does this sound a bit like the situation of the Saturn's early launch in the US?

I'm not an expert on CD prices through the ages, but I did look around as well as ask some people, and generally $100 is around the ball park which most seemed to agree on.
Remember, we're talking huge mass market bulk orders of bare bones CD mechanisms (with licensed chipset or with included off the shelf low level chipset -the former being cheaper in the long run), nothing close to consumer level pricing . . . especially if Nintendo had maintained their Phillips connection (at very least for a favorable license of a Phillips chipset -Atari actually opted to license a Phillips chipset for the jag CD, though obviously a raw deal for them in hindsight with the Jag CD selling so few units).

It came up in a discussion on the Jaguar on Atariage (actually one with Crazyace involved ;)) that cheap 1x speed chinese CD drives were available in bulk for $99 in 1993 . . . so by 1996 (even for a 4x drive, let alone a common 2x one) it should have been considerably cheaper. (and obviously a fraction of the price of a consumer PC CD-ROM drive or music player)

Someone also mentioned to me in the past, that the only reason Nintendo managed to compete on hardware price with the PS1 and Saturn was the lack of a CD drive, because the hardware itself was much more expensive to manufacture.
Team Andromeda claimed that, but I don't buy it. (he also claimed that Sega only dropped the Saturn's price due to cost reductions, not to match Sony -which I don't buy either) The N64 was an extremely tight design aiming at a high degree of consolidation and cost effectiveness . . . Nintnedo also claimed to be selling it at a profit at the $200 launch (opposed to Sony and -especially- Sega selling at considerable losses).
The use of RDRAM in the N64 would have been expensive as an off the shelf component, but their partnership and position with SGI would have changed that considerably. (SGI was also speculating heavily with that RDRAM, pushing it to be used broadly in PCs/etc -and pushing it into the N64 would help that agenda -though it did little in the end other than give Nintendo a good deal on it)
Had it not been for that, Nintendo almost definitely would have opted for SDRAM or EDO DRAM on a slower, wider external bus than the 9-bit RDRAM. (the narrow bus cut motherboard costs and RSP pin count, and with a cheap source of RDRAM, that was win-win -other than RDRAM offering some other performance trade-offs over using slower, wider RAM -especially greater latency and page change penalties, some things that proved to be major bottlenecks with the PS2's 16-bit RDRAM later on)

Now, had Nintendo used CD and still aimed at above cost pricing (ie much more favorable margins than Sony, let alone Sega), it obviously would be above the $200 price matched with Sony, though had they cut margins to Sega's levels they may have still price matched things. (still, $250 would have been a much better deal, even $300 would have been a much better value for most consumers -due to game prices alone, let alone content- and then the advantages with 3rd party interests -of course, if Nintendo managed to implement a CD-like format with similar cart exclusivity of distribution/manufacturing, that would still have major drawbacks to 3rd parties)

Sega never had the home market in Japan with Mega Drive, and I've heard they also had an image there of being a little unreliable (putting out a lot of machines in succession)
Sega did that in all markets though . . . granted, many claim that (pushing new hardware more frequently than anyone else) as one of their major weaknesses . . . then again (up to the release of the Saturn), Sega has also been much more prudent in supporting and carefully phasing out older systems while they seemed to drop them almost immediately in Japan. (though the much greater market share -even with the SMS in the US- was another factor that skews that comparison, and the MD obviously had a long life in Japan before it was dropped)

Certainly not the same as Sony in the mid 90s, who were clearly taking the videogame market very seriously right from the beginning, and were known to have the money to back it up.
So again, NEC had the potential and simply screwed it up? (obviously with the push into the western markets, but prior to that failing to pull 3rd parties from Nintendo -especially ones actively looking for an out-)

Apart from Need For Speed (a definite possibility which would admittedly have been a good help) I can't think of many 3rd party games which would've been directly competitive with Sega or Namco's offerings in the 1996-1997 era, there'd be stuff like Burning Road I guess, the Tokyo Highway games, Battle Arena Toshinden for the 3D fighting genre :)
Hmm, that's an interesting point on 3D fighters . . . Nintendo/Argonaut actually had one in the pipeline for the SFX2 on the SNES (FX Fighter), which was dropped by released independently of Nintendo on PC in 1995. I wonder why Nintendo didn't grab that one. (unless they had a falling out with Argonaut in 1995/96)

http://www.youtube.com/watch?v=mQFgjILp9cY
mQFgjILp9cY

I'm not sure of the quality of the game itself, but it looks competitive on the graphics end at least. (and if it was at least near-Toshinden level with gameplay, that should have been fine) That, and there's the 1 year gap from the release of the DOS game and a potential N64 release at/near launch. (so potential for tweaks/improvments/changes optimized for the N64)
The existing game doesn't seem like it would hold up very well against Toshinden in style of gameplay.

That shouldn't have been something prevented by CD though . . . limited perhaps, but unless Nintendo really screwed up their relationship with Argonaut in 1995/96, it should have been a real possibility.

Edit:
that's actually a rather poor depiction of the gameplay it seems, but there's not much else on youtube other than these soundtrack videos with gameplay in the BG:
http://www.youtube.com/watch?v=RfuWSZSlZoE

And a decent set of screenshots on mobygames http://www.mobygames.com/game/dos/fx-fighter/screenshots

There's also the 1996 FX Fighter Turbo, and perhaps an N64 version would have been close to that in some respects. (except that seems to be all software rendered 256 color stuff too, so a major mismatch with what N64 stuff would look like -cuts due to ROM space, but much better color, shading, filtered+perspective correct textures, etc)

I think its possible that some of the European racers may have turned up, V-Rally may have made an appearance much earlier had N64 been CD based, maybe Codemasters would've put their games on the system (albeit their games seemed to only be popular in Europe, and they didn't have the distribution network set up to sell overseas anyway, in fact, I wonder if they would've been open to a deal with Sega on Saturn to publish overseas, being that their PS1 market was limited to Europe)
Hmm, yes . . . Codemasters doesn't seem to have done that well in the US, though it may be more due to marketing/distribution than actual marketability. (the old Camerica label actually seems to have done surprisingly well for an unlicensed somewhat niche publisher)

Crazyace

07-08-2011, 03:56 PM

What was the context of that? Was that for the existing Multisystem dev usnits using 8088s on a shared bus (without even having a bus latch) or the planned 8086 with latch and possibly separate CPU bus (notes in the technical manual mention plans for a dedicated CPU bus)?
Unless that figure is also taking into account a lot of DSP resource reserved for audio.

No idea - but I'd think it's a guess based on a good understanding of the Slipstream chipset - and if Fred Gill didn't have a machine with 8086 there probably wasn't one :)

The SNES had comparably poor CPU resource to back up star fox as well (2.68 MHz in RAM, possibly 3.58 MHz in ROM depending on the game -plus time spent halted for VRAM updates) and the SFX had to deal with major bottlenecks of planar graphics (also needing to be composite planar tilemap formatted, plus the hefty DMA bottlenecks). And from the information I've seen, the SFX actually is lacking in some areas compared to the Flare DSP (seems to have a slower 16-bit multiply function at least) . . . though it may also be more general purpose. (possibly enough to offload some of the CPU overhead)
I was actually thinking the Flare DSP and SFX may have been directly related (vaguely similar general functionality, both designed by Ben Cheese, etc), but I'm not sure if there's any substantial relation.
The SNES CPU wasn't halted during the whole of active display, and the sound chip was independant , and I guess the 65816 also ran at the same time as the SuperFX ( I've never looked into it though ) - Also a 65816@3.58MHz might even give a 6MHZ 8086 a reasonable run for it's money.[/QUOTE]

Obviously you wouldn't be LIMITED to low-res, but have it as an option.
You've got the DSP to consider for offloading some of the overhead as well as the blitter (compared to purely software rendered PC games).
And if not Doom, then Wolf 3D at least, perhaps wing commander . . . after all, Carmak managed that on a vanilla SNES's 65816 alone (which is stuck at 2.68 MHz when working in RAM) rendering to a 112x96 8-bit packed pixel mode 7 screen, albeit SNES wind commander seems to use normal tile/sprite animation with no software rendering. (actually rather odd that some of the SFX games didn't use mode 7 . . . there's the 16k pixel limitation, but SNES Doom effectively used less than that anyway)
I think one problem was that the Konix might have trouble with a 2D scrolling game at 60Hz - especially if you had multiple BG layers.

What about ease of programming, or especially easy of porting games? (I got the impression that the Panther's rather "different" rendering mechanism wouldn't favor cross ports very well -sort of like the 7800- on top of the limited onboard RAM)
Porting games from Megadrive/SNES/NeoGeo wouldn't be too hard for Panther on paper.. in some ways it's quite similar to NeoGeo.

kool kitty89

07-10-2011, 01:44 PM

No idea - but I'd think it's a guess based on a good understanding of the Slipstream chipset - and if Fred Gill didn't have a machine with 8086 there probably wasn't one :)
I don't think the 8086 version (or updated system in general) was available to developers (in hardware) prior to Konix folding, but whether its was known/available on paper (ie documented) to developers or whether it had been prototyped (or actually geared up for mass production) is a separate matter. (and I've not seen much info on it)

I do know that the working dev units and all the surviving demo footage was from the 8088 derivative development boards. (which also lacked a bus latch for the CPU, let alone a dedicated CPU bus)

It's unclear whether the notes to an added CPU bus are referring to a totally dedicated bank of memory on a local CPU bus, or if it's just referring to the planned 16-bit latch (a la ST) that has been mentioned elsewhere.
Even if it was just the latch, that should at very least have greatly facilitated bus sharing and facilitated more complex wait state generation rather than just halting the CPU. (in addition to potentially allowing interleaved access to memory in active display -similar to the blitter and DSP, wait state generation could displace indiscriminate halts in general -though that is only partially related to the added latch and more to do with other logic managing wait state generation)

A wait state system could also facilitate use of faster clocked CPUs in general (be it a faster 8086, V30, 186, 286, etc), though a 186 alone would incorporate some very useful features. (including wait state management logic) However, that doesn't seem to have been something planned for Konix . . . though potential for other possible adopters of the chipset. (I'd gotten the impression that the later 1994 MSU Multisystem was actually a direct Slipstream based system with a 386 shoehorned into the design, but it seems that the "Slipstream" ASIC used in that machine was far and away built up over the late 80s design -if even directly compatible/related to it- with highcolor support, 4 hardware playfields, hardware gouraud shading, etc -though I can't seem to find any info online beyond direct comments from magazine articles brought up by Team Andromeda on a recent Sega-16 thread)

The SNES CPU wasn't halted during the whole of active display, and the sound chip was independant , and I guess the 65816 also ran at the same time as the SuperFX ( I've never looked into it though ) - Also a 65816@3.58MHz might even give a 6MHZ 8086 a reasonable run for it's money.
Yes . . . with the way the 8088 version of the Multisystem is set-up, that is a major problem, though do note that the SNES is not running at 3.58 MHz much of the time, but 2.68 MHz. (if Wolf3D is using fast ROM, it could be running at 3.58 MHz in ROM, but any rendering and variables in RAM would be at 2.68 MHz)

I think one problem was that the Konix might have trouble with a 2D scrolling game at 60Hz - especially if you had multiple BG layers.
Yes . . . but I fail to see how this comment addresses any of my points on the advantages of including a low res 8bpp mode. (either in place of or in addition to the 256 pixel 4bpp mode)

60 Hz isn't that imperative either . . . 25/30 Hz is still quite respectable and reasonable for the most part, even 20 Hz isn't too bad.
Though for slowly scrolling BGs (ie cases where you'd only want to move one pixel every couple of frames or so), the 2-pixel allignment issue would be a more noticeable problem regardless of overall framerate (for fast stuff it would be barely noticeable, hence why 8 pixel aligned scrolling doesn't look so bad in some fast paced CV/MSX/ST/Speccy examples). Granted, anything with multiple BG layers would be using the blitter to draw that . . . unfortunately, it's usually the far BG which scrolls the slowest, but also the far BG which may be most convenient to use hardware scrolling on. (a case with a large foreground and smaller far BG sections would make things a good bit easier -have much of the foreground hardware scrolled and repaired by the blitter as needed -from sprites, etc- with the far BG drawn by the blitter every frame)

Porting games from Megadrive/SNES/NeoGeo wouldn't be too hard for Panther on paper.. in some ways it's quite similar to NeoGeo.
Kskunk pointed out some major sticking points like lack of normal sprite manipulation features (no "normal" sprite tables manipulating X/Y position registers among other things) as well as lack of conventional framebuffer or tilemap (character mode) generated BGs.
It's similar to the Neo Geo in the sense of being all "sprite" based and with zooming for sprites (not sure if it's NG/ystem 16 style "zoom" which only supports downscaling, scaling beyond the full resolution of a bitmap, or full 2D scaling with independent X/Y stretching), but the Neo Geo still uses conventional sprite tables to actually manipulate objects rather than display lists.

Aside from that, there's the general issue of the shared 32k of SRAM with full contention, though with a 16 MHz 68000 to at least do some hefty work when it does have access to the bus. (so some of the same trade-offs of the 7800 again)
Either a separate CPU bus (namely with slow/cheap DRAM -still fast enough for the CPU to run without wait states) or a more buffered OPL using DRAM for everything (like the Jaguar) could have been much more realistic. (or even with a shared bus with contention, have an added shared DRAM bank to supplement the fast SRAM -especially since that would facilitate use of slow ROMs and compressed data -and preferably an interleaving mechanism a la ST/Amiga for the OPL to "steal" cycles in the "free" portion of the 68k's memory access cycle, especially while the OPL is accessing SRAM) Even using a bank of slow/low end SRAM to complement the fast/expensive bank would help (but obviously be more limited/less cost effective than using DRAM -still, they were using 32kx8 SRAMs on cart back in '88 -Summer and Winter games).

Hmm, did the Panther use 30 or 60 ns SRAM? (the OPL is listed at 32 MHz, but I don't remember seeing anything on the SRAM speed)

Crazyace

07-11-2011, 03:07 AM

I don't think the 8086 version (or updated system in general) was available to developers (in hardware) prior to Konix folding, but whether its was known/available on paper (ie documented) to developers or whether it had been prototyped (or actually geared up for mass production) is a separate matter. (and I've not seen much info on it)

I do know that the working dev units and all the surviving demo footage was from the 8088 derivative development boards. (which also lacked a bus latch for the CPU, let alone a dedicated CPU bus)

It's unclear whether the notes to an added CPU bus are referring to a totally dedicated bank of memory on a local CPU bus, or if it's just referring to the planned 16-bit latch (a la ST) that has been mentioned elsewhere.
Even if it was just the latch, that should at very least have greatly facilitated bus sharing and facilitated more complex wait state generation rather than just halting the CPU. (in addition to potentially allowing interleaved access to memory in active display -similar to the blitter and DSP, wait state generation could displace indiscriminate halts in general -though that is only partially related to the added latch and more to do with other logic managing wait state generation)

I found an interesting document on the Multistream site - the Konix business plan from 16th August 1989. In it they specify the version of the console that would be manufactured. It is specified with the 6MHz 8086 - but only has 64k of 16bit SRAM - there is another 64k by 8bit ram for the cpu. So the cpu latch seems to be implemented at the cost of VRAM. - there is now just enough to handle double bufferering in the lowres 16 colour mode.

A wait state system could also facilitate use of faster clocked CPUs in general (be it a faster 8086, V30, 186, 286, etc), though a 186 alone would incorporate some very useful features. (including wait state management logic) However, that doesn't seem to have been something planned for Konix . . . though potential for other possible adopters of the chipset. (I'd gotten the impression that the later 1994 MSU Multisystem was actually a direct Slipstream based system with a 386 shoehorned into the design, but it seems that the "Slipstream" ASIC used in that machine was far and away built up over the late 80s design -if even directly compatible/related to it- with highcolor support, 4 hardware playfields, hardware gouraud shading, etc -though I can't seem to find any info online beyond direct comments from magazine articles brought up by Team Andromeda on a recent Sega-16 thread)
It would be interesting seeing how that would compare with Jaguar :)

Yes . . . with the way the 8088 version of the Multisystem is set-up, that is a major problem, though do note that the SNES is not running at 3.58 MHz much of the time, but 2.68 MHz. (if Wolf3D is using fast ROM, it could be running at 3.58 MHz in ROM, but any rendering and variables in RAM would be at 2.68 MHz)
It's not quite that bad - ram accesses are 2.68MHz - but instruction fetches come from fast rom - so the number of slow cycles would depend on the bytes read from rom and the data mode (8/16 bit ) . I guess a lot of the hard work on StarFox is done on the SuperFX though.

Yes . . . but I fail to see how this comment addresses any of my points on the advantages of including a low res 8bpp mode. (either in place of or in addition to the 256 pixel 4bpp mode)
With perfect hindsight, and a complete focus on Wolfenstein style games a low res 128pixel by 256 colour mode would sound really good. However Wolfenstein came out a lot later, and the Konix seemed to be aimed at competing with the Amiga, PC Engine, and Megadrive. I think if they had considered it it wouldn't replace any other modes though.
Something that might have been interesting would be the 'mixed resolution' flag used with this lower res mode. This would give you a selection per pixel of 1 128x pixel or 2 256x pixels.

60 Hz isn't that imperative either . . . 25/30 Hz is still quite respectable and reasonable for the most part, even 20 Hz isn't too bad.
Though for slowly scrolling BGs (ie cases where you'd only want to move one pixel every couple of frames or so), the 2-pixel allignment issue would be a more noticeable problem regardless of overall framerate (for fast stuff it would be barely noticeable, hence why 8 pixel aligned scrolling doesn't look so bad in some fast paced CV/MSX/ST/Speccy examples). Granted, anything with multiple BG layers would be using the blitter to draw that . . . unfortunately, it's usually the far BG which scrolls the slowest, but also the far BG which may be most convenient to use hardware scrolling on. (a case with a large foreground and smaller far BG sections would make things a good bit easier -have much of the foreground hardware scrolled and repaired by the blitter as needed -from sprites, etc- with the far BG drawn by the blitter every frame)
Designing a games console that is unable to compete with a C64 in terms of scrolling is a bit insane though :) - especially if the competition is the Megadrive.
As the Konix is a simple bitmap the BG would have to be redrawn each frame anyway, with any faster foreground planes ( and sprites ) painted on afterwards. You could implement a complex scheme where you drew bg only where it might be visible ( and scrolled foreground at 2 pixels/cycle ) but not having a pixel perfect h/w scroll is a limit.
It would be interesting to see if the Konix could even replicate a good MasterSystem game ( 32 colours scrolling at 60Hz plus sprites ) , let alone a good Megadrive game.

Kskunk pointed out some major sticking points like lack of normal sprite manipulation features (no "normal" sprite tables manipulating X/Y position registers among other things) as well as lack of conventional framebuffer or tilemap (character mode) generated BGs.
It's similar to the Neo Geo in the sense of being all "sprite" based and with zooming for sprites (not sure if it's NG/ystem 16 style "zoom" which only supports downscaling, scaling beyond the full resolution of a bitmap, or full 2D scaling with independent X/Y stretching), but the Neo Geo still uses conventional sprite tables to actually manipulate objects rather than display lists.
Panther only support vertical scaling of sprites - not horizontal.

Aside from that, there's the general issue of the shared 32k of SRAM with full contention, though with a 16 MHz 68000 to at least do some hefty work when it does have access to the bus. (so some of the same trade-offs of the 7800 again)
Either a separate CPU bus (namely with slow/cheap DRAM -still fast enough for the CPU to run without wait states) or a more buffered OPL using DRAM for everything (like the Jaguar) could have been much more realistic. (or even with a shared bus with contention, have an added shared DRAM bank to supplement the fast SRAM -especially since that would facilitate use of slow ROMs and compressed data -and preferably an interleaving mechanism a la ST/Amiga for the OPL to "steal" cycles in the "free" portion of the 68k's memory access cycle, especially while the OPL is accessing SRAM) Even using a bank of slow/low end SRAM to complement the fast/expensive bank would help (but obviously be more limited/less cost effective than using DRAM -still, they were using 32kx8 SRAMs on cart back in '88 -Summer and Winter games).

Hmm, did the Panther use 30 or 60 ns SRAM? (the OPL is listed at 32 MHz, but I don't remember seeing anything on the SRAM speed)

Seems to be a 16MHz clock , with 32bit SRAM taking 2 cycles per access, and 16Bit ROM taking 4 cycles for the graphics - pixels are processed at 1 per clock which matches ROM timings for 16 colour data. A sprite is 4 longwords control( 8 cycles from SRAM ) + pixels , and given >1000 cycles per line you could have around 25 32 pixel wide 16 colour sprites per line - enough for 2 BG planes or a lot of big sprites.

Thenewguy

07-11-2011, 03:40 PM

That's assuming Duo sales are even included in that 7 million figure, and not missing entirely.I think when put together the scraps of info I've seen indicate that Duo sales are included in the total.

Famitsu states that there were 3.92 million non cd units in Japan in 1994, and the rest of the data from Famitsu indicates that the CoreGrafx was selling much less than 200,000 a year in Japan by that point (and dropping, with PC-Engine marketshare being non-existent by 1996 if the Youtube video is anything to go by).

If both of those are true then I don't see the non-CD PC-Engines being able to reach the total of 6-7 million Japan sales without the help of the Duo.

I hadn't gotten that impression at all . . . I'd gotten the impression that the Genesis held a considerable lead in install base until 1994, though a slim one at times.I just re-checked all the facts I have, and it seems that the conclusion for this is wholly based on who you believe.

Nintendo claim to have caught up with the Genesis' total sales sometime late in 1991, with Genesis coming back and selling more during the Christmas period

Both companies dispute each others sales figures though, and going by Sega's statements they were still way ahead.

Trying to find an average between the two has Nintendo maybe catching up a good amount of the pre-SNES sales but still being notably behind MD overall sales before Christmas (which they then lost).

What about the PC Engine? That was a far more significant competitor well before the MD got big in the west.Game Over doesn't mention PC-Engine in this particular section, but that is possibly because the book is written from a western perspective.

Looking at Namco's releases though, actually shows that during the period of the argument (I think this occured midway through 1989-1990), that they supported both Mega Drive and PC-Engine anyway, with NES not receiving any new games in Japan.

So it seems that Namco probably did hedge their bets a little bit.

Is it just me, or does this sound a bit like the situation of the Saturn's early launch in the US?Yeah, N64 was released in June in Japan, whilst it was released in September in the US, that could be another factor which held the US system in marginally better stead.

It came up in a discussion on the Jaguar on Atariage (actually one with Crazyace involved ;)) that cheap 1x speed chinese CD drives were available in bulk for $99 in 1993 . . . so by 1996 (even for a 4x drive, let alone a common 2x one) it should have been considerably cheaper. (and obviously a fraction of the price of a consumer PC CD-ROM drive or music player)Nintendo do try to aim for reliability though, and tend to do business with other Japanese companies, I don't think they would've been happy to use the cheapest CD-ROM drive on the market.

Hmm, that's an interesting point on 3D fighters . . . Nintendo/Argonaut actually had one in the pipeline for the SFX2 on the SNES (FX Fighter), which was dropped by released independently of Nintendo on PC in 1995.

I'm not sure of the quality of the game itself, but it looks competitive on the graphics end at least. (and if it was at least near-Toshinden level with gameplay, that should have been fine) That, and there's the 1 year gap from the release of the DOS game and a potential N64 release at/near launch. (so potential for tweaks/improvments/changes optimized for the N64)Maybe. I was inclined to write the game off but PC reviews seem to have been positive (albeit positive in 1995)

N64 needed a good 3D fighting game with long lasting gameplay. Games like Toshinden were alright in the beginning of that generation, but people soured on it fairly quickly (maybe even by mid 1996).

People say the N64 had no fighting games, but really it has quite a few, most of them just aren't very good. There were a number of 3D fighting games early in 1997 (War Gods, Dark Rift), but they were unpopular and universally panned. Mace: The Dark Age came out at the end of 1997, and that at least got decent/mixed reviews.

I wonder why Nintendo didn't grab that one. (unless they had a falling out with Argonaut in 1995/96)I think Nintendo did have an at least mild falling out with Argonaut (Jez San actually talks about Nintendo with some dislike in interviews these days, he's stated that he felt that Nintendo used them to teach their programmers 3D, and then poached his staff) but it couldn't have been too serious or long lasting as they made Buck Bumble.

kool kitty89

07-12-2011, 07:25 PM

I found an interesting document on the Multistream site - the Konix business plan from 16th August 1989. In it they specify the version of the console that would be manufactured. It is specified with the 6MHz 8086 - but only has 64k of 16bit SRAM - there is another 64k by 8bit ram for the cpu. So the cpu latch seems to be implemented at the cost of VRAM. - there is now just enough to handle double bufferering in the lowres 16 colour mode.
There's also several mentions of Konix being unsure of RAM capacity due to cost concerns (not to mention somewhat volatile RAM prices) and was leaving the decision for the last minute with 64, 128, and 256k all being possibilities with additional external expansion support. (however, notes on the design point to RAM expansion only being supported via the cart slot, which itself only maps the 2 8-bit 256k slow RAM and ROM banks)

The 16-bit bus latch was to be an embedded part of the updated 160 pin version of the slipstream (which also added support for a 16-bit host processor bus in general and added the floppy controller), though I don't think that new ASIC changed the memory map and I haven't seen any elaboration on the hinting of a true dedicated CPU bus. (support for 16-bit slow RAM/ROM would obviously have been a very useful addition -especially since all bus masters would be 16-bit by that point too, making the cart expansion banks 16-bit wide would have been nice -still slower than the 2 cycle fastRAM accesses, but 3 cycle/250 ns at 16-bits is pretty useful in any case and would facilitate use of cheap DRAM -albeit without provisions for any fast page mode utilization, so like the ST or amiga in that respect)

It would be interesting seeing how that would compare with Jaguar :)
From the dates I've seen, it actually came out well after the jaguar's test market too, though the actual tech info is a bit vague.
From the other thread, this is the only info I've seen on it. (not sure on how accurate it is either)

CPU 386 @ 25 Mhz

GPU Custom Slipstream RISC

And Wyn Holloway said the machine supported no hardware sprites but instead 4 hardware planes and support of blitting in front or behind each of those planes.

Two graphics modes - 65,536 colours 16 bits per pixel , Gouraud shading, , capable of 96 million pixels per sec , No hardware sprites 4 backround planes can blit in front or behind each of the 4 backround planes.

Oh btw here's a pic for you along with the gang

http://farm4.static.flickr.com/3212/5852440037_b9b72dcd54.jpg

It's not quite that bad - ram accesses are 2.68MHz - but instruction fetches come from fast rom - so the number of slow cycles would depend on the bytes read from rom and the data mode (8/16 bit ) . I guess a lot of the hard work on StarFox is done on the SuperFX though.
That's only for games using Fast ROM. Many games (and all early ones AFIK) used 2.68 MHz in ROM too.
The ability for fast ROM to improve performance is the polar opposite of the more sensible design philosophy of fast RAM and slow/cheap ROM (Lynx, Jaguar, N64, some home computers, etc) and it is quite odd that the SNES didnt' at least have DRAM capable of 3.58 MHz operation if not more than that -perhaps 4.3 or 5.37 MHz. (beyond faster slow/random DRAM accesses, implementing fast page mode support with wait states would have added to complexity a bit, but paid off big time in performance . . . and using nothing but bottom barrel cheap/slow ROMs would have saved far, far more cost and meant higher profits -hell, even the SNES's "slow" ROMs were quite a bit faster than those used in many MD games or Lynx games for that matter and about as fast as the bone standard Jaguar ones -fast ROM on the SNES was faster than normal Jag games)

OTOH you have NEC using 140 ns ROM from day 1 in 1987 (and 140 ns SRAM accesses -probably common 100 ns SRAM chips), though they had vertical integration as a massive advantage and using their own glob top ROMs in hucards probably cut costs too. (cheap small PCB with cheap surface mounted glob top construction)

With perfect hindsight, and a complete focus on Wolfenstein style games a low res 128pixel by 256 colour mode would sound really good. However Wolfenstein came out a lot later, and the Konix seemed to be aimed at competing with the Amiga, PC Engine, and Megadrive. I think if they had considered it it wouldn't replace any other modes though.
Something that might have been interesting would be the 'mixed resolution' flag used with this lower res mode. This would give you a selection per pixel of 1 128x pixel or 2 256x pixels.
As it is, you could just use dithered pairs of 16 color pixels (like several MD games so), though that obviously wouldn't look as nice as true 256 color stuff it could still probably look pretty decent for a number of things. (be it polygonal stuff or scaled/rotated/texture stuff or ray casting based examples)

3D/Psuedo 3D was obviously a consideration in the design and there were obviously notable examples even by 1987/88 using several techniques. (scaled 2D was obviously prevalent in the arcade, polygonal and wireframe 3D was notable on several computers, though ray cast/height map based stuff was very limited in quantity)
There's also the neat pseudo 3D fractal engines that had appeared much earlier, but seems to disappear by the end of the 80s.

Designing a games console that is unable to compete with a C64 in terms of scrolling is a bit insane though :) - especially if the competition is the Megadrive.
As the Konix is a simple bitmap the BG would have to be redrawn each frame anyway, with any faster foreground planes ( and sprites ) painted on afterwards. You could implement a complex scheme where you drew bg only where it might be visible ( and scrolled foreground at 2 pixels/cycle ) but not having a pixel perfect h/w scroll is a limit.
It would be interesting to see if the Konix could even replicate a good MasterSystem game ( 32 colours scrolling at 60Hz plus sprites ) , let alone a good Megadrive game.
Better ST games already look a lot better than most (if not all) Master System games, even in motion . . . scrolling may not be as smooth, but color tends to be a lot nicer (2 palettes of 15 colors from 6-bit RGB is still pretty limited -and only 1 for sprites at that- with 16 5-bit RGB colors looking much better in many cases even without palette swap tricks -better optimized ST games don't even look too bad compared to the color in MD games, though Game Gear games obviously have a 12-bit RGB advantage as well as dual palettes for BG and tend to show that at times over Lynx games -though palette swap effects balance that to some degree -and on actual hardware, the LCD screens don't show color that well in general due to the limited contrast)
And then there's the flicker issues in SMS games, often more notable than in NES games (though sprite limits are similar in both) probably due to SMS games trying to push more advanced games more often and making a sacrifice for rather hefty flicker to allow that. (there's also a few games that opt to use tile based software sprites/objects with very choppy movement and attribute clash issues -Space Harrier and Afterburner both do that iirc . . . Afterburner manages to wast a full 512k in that case, as much as the MD and PCE versions in spite of considerably lesser quality -it probably wasted a lot on uncompressed graphics since VRAM was so small and perhaps some pre-shifted objects to reduce choppy movement)

So any reasonably well designed (art/sound/level), decently smooth 256 color game on the Slipstream should have been well ahead of average SMS stuff, if not blown it out of the water.

Panther only support vertical scaling of sprites - not horizontal.
So you'd need to animate (via ROM/RAM or software scaled) horizontally for full X/Y zooming effects on the Panther? (so less useful than what the Lynx can do)

Seems to be a 16MHz clock , with 32bit SRAM taking 2 cycles per access, and 16Bit ROM taking 4 cycles for the graphics - pixels are processed at 1 per clock which matches ROM timings for 16 colour data. A sprite is 4 longwords control( 8 cycles from SRAM ) + pixels , and given >1000 cycles per line you could have around 25 32 pixel wide 16 colour sprites per line - enough for 2 BG planes or a lot of big sprites.
Hmm so they could have been using common 100 ns SRAM at that point (or 120 ns, but 100 ns seems to have been quite common given Sega was using it in all their late 80s/early 90s SMSs and as Z80 RAM in MDs). And ROM would have been significantly faster than what the Jag was using later on (250 ns vs 376 -or the lynx's ~420 ns for that matter), so a major cost compromise on that end.

In that case, it's rather odd that they limited it to 32k. Average speed SRAM shouldn't have been THAT expensive (hell, they'd already put 32k into a couple 1987/88 7800 games -and only used 16k of that -but used 32k to save PCB space/cost) . . . and limited RAM would also mean very limited ability to decompress into ROM (on top of using not super cheap ROM in general) so a rather flawed proposition to save on costs. (either promoting lower cost games to offset a higher than ideal console price or eating the cost and using average priced games would have made far, far more sense -especially since Atari was still in very decent shape in 1989/90, though they had passed their 1987/88 peak and neither sales nor management were improving from there, but that's another topic ;))
The PCE used 64 kB of SRAM years earlier and the SNES opted for 64k SRAM as well (MD used VRAM, of course). And the SNES als using 128k DRAM, 64k SRAM/PSRAM (for audio), and a rather high-end sound system inflating cost as well.
Edit:
Then there's the multisystem itself which was planned to use at least 64k SRAM (or PSRAM if it became available at the desired speed and volumes) and possibly additional DRAM -64k 8-bit DRAM in the configuration you quoted. (actually 64kSRAM+64kDRAM at 125/250 ns in the panther could have been pretty decent even on a totally shared bus with only a latch -and possibly efficiently managed wait states- to facilitate bus sharing with the 68k+Panther)

Plus, with 125 ns SRAM accesses, it should have been possible to allow the OPL to interleave 2 accesses within a 68000 access cycle, so support for modes allowing that could be quite useful. (in addition to modes where the object processor saturated the bus as needed, halting the 68k or -preferably- generating wait states until the bus was free again)

The panther also had provisions for a dedicated audio bus . . . but a slow DRAM bus for the CPU would have made a hell of a lot more sense (250 ns random accesses to DRAM -like in the ST- accesses should have allowed a 16 MHz 68k to work without wait states), especially since a full-bore 68k combined with simple DMA sound could have made for a pretty good sound set-up for the time. (use of the Ensoniq DOC II was rather ambitious too . . . a run of the mill yamaha FM chip -and/or DMA sound- would have made a hell of a lot more sense unless they had some special deal with Ensoniq)

OTOH, the motherboard space and complexity saved by a unified bus (including no audio bus) is certainly notable too, and perhaps enough to outstrip use of nothing but SRAM for main memory as well (albeit including a slow DRAM buffer on a shared bus could still come in handy to allow slow ROM and heavily compressed data in ROM).

kool kitty89

07-13-2011, 01:34 AM

I just re-checked all the facts I have, and it seems that the conclusion for this is wholly based on who you believe.

Nintendo claim to have caught up with the Genesis' total sales sometime late in 1991, with Genesis coming back and selling more during the Christmas period

Both companies dispute each others sales figures though, and going by Sega's statements they were still way ahead.
There's also the issue of how legitimate statistics can be twisted one way or another. It could be that both cases are accurate depending on exactly what's being claimed. "market share" can refer to a number of things for sure (hardware units sold, software units, revenue, etc), though if they explicitly mentioned install base of hardware units then that's certainly some conflict. (albeit, even there, there's the issue of units distributed to retail vs units sold to consumers -the former can obviously be significantly higher than the latter in the short run)

Then there's the issue of conflicting sources on one side alone . . . there's a rather detailed write-up on Sega's financial situation in the MD years that cites a peak in 1992 and significant decline in '93 (corresponding to the slump) while another notably shows a significant increase in revenue in 1993 and no decline until '94. (the latter is definitely citing calendar years and not fiscal years and the former wouldn't make sense to be fiscal years as that would push the date since that would place things even earlier than 1992, unless it was the Japanese fiscal year -and while both were in specific context to the US, they're also for Japanese based companies)

Trying to find an average between the two has Nintendo maybe catching up a good amount of the pre-SNES sales but still being notably behind MD overall sales before Christmas (which they then lost).
I have a very hard time believing that Nintendo sold over 1 million SNESs in less than 4 months after the US launch.

OTOH, I wouldn't be surprised if the NES outsold both consoles considerably that year . . . and I wouldn't be surprised if the NES sold more in 1991 than the Genesis had in cumulative sales from launch through the '91 holiday season (after all, 1990 was the NES's absolute peak and 1991 still had massive sales for the console).
I don't think it was until christmas of 1992 that the SNES or Genesis outstripped the NES in quarterly sales/market share. (and I don't think Sega ever beat Nintendo's composite market share in the US due to the NES+SNES combo -in Europe, certainly thanks to the SMS+MD but highly doubtful in the US . . . )

Looking at Namco's releases though, actually shows that during the period of the argument (I think this occured midway through 1989-1990), that they supported both Mega Drive and PC-Engine anyway, with NES not receiving any new games in Japan.

So it seems that Namco probably did hedge their bets a little bit.
The big difference with Sony was that they didn't just offer an alternative, but gave Namco a very nice partnership deal for exclusivity as a de-facto 2nd party. (there's no reason NEC couldn't have pulled that off in the late 80s -with their position and computer market still going strong- but, again, NEC didn't seem to have nearly as capable management as Sony demonstrated in the following generation -in any region)

Nintendo do try to aim for reliability though, and tend to do business with other Japanese companies, I don't think they would've been happy to use the cheapest CD-ROM drive on the market.
Not necessarily the cheapest, but a cheap, bulk quantity in any case, cheaper than bottom end audio CD players at the consumer level (let alone PC CD-ROM drives). And, again, the most cost effective option would have been negotiating a favorable licensing agreement for a CD-ROM chipset (especially if they maintained a good working relationship with Phillips) and only bought the drive mechanism off the shelf. (or bought the chipset off the shelf in bulk from Phillips if the price was right)
Doing a custom chipset would be a bit pointless as you'd still need to shell out for a license (due to heavy pattents on the technology) so licensing a complete chipset (at least a basic low-level audio CD chipset) or going fully off the shelf would make the most sense. (even off the shelf should be cheaper than buying PC CD-ROM drives in bulk due to the latter having significant additions to the hardware for full CD-ROM data transfer management and IDE interfacing rather than just audio CD control logic -the CD-ROM interface logic could be custom/semi-custom and rather bare bones to save on cost, like most/all early disc based consoles)

Maybe. I was inclined to write the game off but PC reviews seem to have been positive (albeit positive in 1995)

N64 needed a good 3D fighting game with long lasting gameplay. Games like Toshinden were alright in the beginning of that generation, but people soured on it fairly quickly (maybe even by mid 1996).
A game like Tekken, yes . . . not so much for Virtua Fighter unless you're talking japan specifically. (the VF series never seems to have generated massive interest in the US -not sure about Europe- and seems to have even been overshadowed by Toshinden to a fair degree -undoubtedly in part due to Sony's marketing/hype, at least that's the impression I've gotten -personally, I didn't even know about VF or Toshinden until the last couple years, after getting into retro gaming more, and only really knew about the likes of the SFII series, Mortal Kombat, Tekken, Soul Calibur, DoA, and such back in the 90s or today . . . as far as promotions or friends owning the games -for that matter, I don't remember anyone owning Killer Instinct back in the 90s or early 2000s)

People say the N64 had no fighting games, but really it has quite a few, most of them just aren't very good. There were a number of 3D fighting games early in 1997 (War Gods, Dark Rift), but they were unpopular and universally panned. Mace: The Dark Age came out at the end of 1997, and that at least got decent/mixed reviews.
Aren't the mortal kombat ports pretty decent on the N64?
But yes, lacking compared to the PSX and Saturn, especially for 3D fighters.

I think Nintendo did have an at least mild falling out with Argonaut (Jez San actually talks about Nintendo with some dislike in interviews these days, he's stated that he felt that Nintendo used them to teach their programmers 3D, and then poached his staff) but it couldn't have been too serious or long lasting as they made Buck Bumble.
Making a game published by a 3rd party later on doesn't really prove or disprove hoe big of an upset in relations it caused (or whether it ruined potential for a close nit 2nd/3rd party partnership).
Then again, Nintendo tends to be rather controlling with any collaborative work, and not very attractive for partnering with 3rd parties for long periods (and building good relationships -unlike Sega or Sony) and only seems to partner for the long term with genuine 2nd party (largely Nintendo controlled) developers. (like HAL and RARE)

That's just another facet of Nintendo's main weakness though (their stubbornness/inflexibility and related harshness towards 3rd parties) . . . Sega had their own problems, but that certainly was one of their strengths. (and one Sony copied to a fair extent -except with a lot more money to back it up . . . and used more tactfully than MS -in part making PR better in general with developers/publishers and consumers)

Crazyace

07-13-2011, 03:41 AM

There's also several mentions of Konix being unsure of RAM capacity due to cost concerns (not to mention somewhat volatile RAM prices) and was leaving the decision for the last minute with 64, 128, and 256k all being possibilities with additional external expansion support. (however, notes on the design point to RAM expansion only being supported via the cart slot, which itself only maps the 2 8-bit 256k slow RAM and ROM banks)

The 16-bit bus latch was to be an embedded part of the updated 160 pin version of the slipstream (which also added support for a 16-bit host processor bus in general and added the floppy controller), though I don't think that new ASIC changed the memory map and I haven't seen any elaboration on the hinting of a true dedicated CPU bus. (support for 16-bit slow RAM/ROM would obviously have been a very useful addition -especially since all bus masters would be 16-bit by that point too, making the cart expansion banks 16-bit wide would have been nice -still slower than the 2 cycle fastRAM accesses, but 3 cycle/250 ns at 16-bits is pretty useful in any case and would facilitate use of cheap DRAM -albeit without provisions for any fast page mode utilization, so like the ST or amiga in that respect)

I think the bus latch might have helped the cpu in general, but wouldn't really improve the overall performance - as the blitter/dsp would still be the 'heavy hitters' of the system. Even with the bus latch though there aren't any mentions of other speeds for memory accesses apart from 2cycle/4cycle.

From the dates I've seen, it actually came out well after the jaguar's test market too, though the actual tech info is a bit vague.
From the other thread, this is the only info I've seen on it. (not sure on how accurate it is either)

CPU 386 @ 25 Mhz

GPU Custom Slipstream RISC

And Wyn Holloway said the machine supported no hardware sprites but instead 4 hardware planes and support of blitting in front or behind each of those planes.

Two graphics modes - 65,536 colours 16 bits per pixel , Gouraud shading, , capable of 96 million pixels per sec , No hardware sprites 4 backround planes can blit in front or behind each of the 4 backround planes.

Sounds like a 'wide' slipstream - add a 65k colour mode to the display , then I'd guess a 12MHz memory clock with 32 bit memory ( With 4 bit pixels you get 12x8=96million pixels per sec )
The 4 hardware planes sound exactly like the 4 hardware planes in the slipstream - ( using the blitter comparator along with the 2 plane bits from the pixel )

That's only for games using Fast ROM. Many games (and all early ones AFIK) used 2.68 MHz in ROM too.
The ability for fast ROM to improve performance is the polar opposite of the more sensible design philosophy of fast RAM and slow/cheap ROM (Lynx, Jaguar, N64, some home computers, etc) and it is quite odd that the SNES didnt' at least have DRAM capable of 3.58 MHz operation if not more than that -perhaps 4.3 or 5.37 MHz. (beyond faster slow/random DRAM accesses, implementing fast page mode support with wait states would have added to complexity a bit, but paid off big time in performance . . . and using nothing but bottom barrel cheap/slow ROMs would have saved far, far more cost and meant higher profits -hell, even the SNES's "slow" ROMs were quite a bit faster than those used in many MD games or Lynx games for that matter and about as fast as the bone standard Jaguar ones -fast ROM on the SNES was faster than normal Jag games)
I assume it's the usual case of supply - If Nintendo had a supply of slower rom's available at a lower cost then it made sense to use them. The 3.58Mhz mode then became a futureproofing step. I guess the dram speed was the same.

As it is, you could just use dithered pairs of 16 color pixels (like several MD games so), though that obviously wouldn't look as nice as true 256 color stuff it could still probably look pretty decent for a number of things. (be it polygonal stuff or scaled/rotated/texture stuff or ray casting based examples)
Yes, there's nothing stopping you running the blitter in 8 bit mode with the display in 4 bit.

3D/Psuedo 3D was obviously a consideration in the design and there were obviously notable examples even by 1987/88 using several techniques. (scaled 2D was obviously prevalent in the arcade, polygonal and wireframe 3D was notable on several computers, though ray cast/height map based stuff was very limited in quantity)
There's also the neat pseudo 3D fractal engines that had appeared much earlier, but seems to disappear by the end of the 80s.
Line drawing and 3D calculation were supported, but not texture mapping in any way - the blitter only supported straight pixel copying

Better ST games already look a lot better than most (if not all) Master System games, even in motion . . . scrolling may not be as smooth, but color tends to be a lot nicer (2 palettes of 15 colors from 6-bit RGB is still pretty limited -and only 1 for sprites at that- with 16 5-bit RGB colors looking much better in many cases even without palette swap tricks -better optimized ST games don't even look too bad compared to the color in MD games, though Game Gear games obviously have a 12-bit RGB advantage as well as dual palettes for BG and tend to show that at times over Lynx games -though palette swap effects balance that to some degree -and on actual hardware, the LCD screens don't show color that well in general due to the limited contrast)
That's not the point I raised - ( I wasn't comparing ST with Master system for one thing ). I personally think scrolling is important, and not having it was a big problem, just as it was for the ST when compared to the amiga.

And then there's the flicker issues in SMS games, often more notable than in NES games (though sprite limits are similar in both) probably due to SMS games trying to push more advanced games more often and making a sacrifice for rather hefty flicker to allow that. (there's also a few games that opt to use tile based software sprites/objects with very choppy movement and attribute clash issues -Space Harrier and Afterburner both do that iirc . . . Afterburner manages to wast a full 512k in that case, as much as the MD and PCE versions in spite of considerably lesser quality -it probably wasted a lot on uncompressed graphics since VRAM was so small and perhaps some pre-shifted objects to reduce choppy movement)

So any reasonably well designed (art/sound/level), decently smooth 256 color game on the Slipstream should have been well ahead of average SMS stuff, if not blown it out of the water.

Unless it was trying to scroll at 60Hz :) - and beating the SMS wouldn't have helped the Slipstream. It had to match or beat the Megadrive.

So you'd need to animate (via ROM/RAM or software scaled) horizontally for full X/Y zooming effects on the Panther? (so less useful than what the Lynx can do)
Yes

Hmm so they could have been using common 100 ns SRAM at that point (or 120 ns, but 100 ns seems to have been quite common given Sega was using it in all their late 80s/early 90s SMSs and as Z80 RAM in MDs). And ROM would have been significantly faster than what the Jag was using later on (250 ns vs 376 -or the lynx's ~420 ns for that matter), so a major cost compromise on that end.

In that case, it's rather odd that they limited it to 32k. Average speed SRAM shouldn't have been THAT expensive (hell, they'd already put 32k into a couple 1987/88 7800 games -and only used 16k of that -but used 32k to save PCB space/cost) . . . and limited RAM would also mean very limited ability to decompress into ROM (on top of using not super cheap ROM in general) so a rather flawed proposition to save on costs. (either promoting lower cost games to offset a higher than ideal console price or eating the cost and using average priced games would have made far, far more sense -especially since Atari was still in very decent shape in 1989/90, though they had passed their 1987/88 peak and neither sales nor management were improving from there, but that's another topic ;))
It was 32bits wide - so likely 4 8kx8 chips, and I guess Atari were looking at the 7800 model where the console is a cheap as possible :)

Plus, with 125 ns SRAM accesses, it should have been possible to allow the OPL to interleave 2 accesses within a 68000 access cycle, so support for modes allowing that could be quite useful. (in addition to modes where the object processor saturated the bus as needed, halting the 68k or -preferably- generating wait states until the bus was free again)
From ram Panther would fetch 8 pixels in 2 cycles - so 6 cycles would be free anyway which would be enough for a 68k access

The panther also had provisions for a dedicated audio bus . . . but a slow DRAM bus for the CPU would have made a hell of a lot more sense (250 ns random accesses to DRAM -like in the ST- accesses should have allowed a 16 MHz 68k to work without wait states), especially since a full-bore 68k combined with simple DMA sound could have made for a pretty good sound set-up for the time. (use of the Ensoniq DOC II was rather ambitious too . . . a run of the mill yamaha FM chip -and/or DMA sound- would have made a hell of a lot more sense unless they had some special deal with Ensoniq)
No idea about the sound - I guess it's just a ram attached to the sound chip ( The Apple IIgs had 64k - I wonder if Atari would have only used 32k or even 8k to cut costs )

Thenewguy

07-13-2011, 08:36 AM

though if they explicitly mentioned install base of hardware units then that's certainly some conflict.They specifically mentioned "install base"

I have a very hard time believing that Nintendo sold over 1 million SNESs in less than 4 months after the US launch.Yeah, and, in fact their own figures don't even support this.

Effectively Nintendo seems to be arguing that Sega's figures were much lower up until 1991 than have been stated, and that Sega only sold no more than 1 million units during 1991, so they estimate Sega's total install base at the end of 1991 at ~2 million, they state that they have sold 2.1 million SNES' as of the end of 1991.

Sega state that Nintendo are exagerrating their figures and say that by their information SNES has sold 1.4 million in 1991, and that they themselves sold 1.6 million Genesis in 1991. This, on top of the claimed 1.2 million install base prior to 1991, leaves them with ~2.8 million US Genesis owners as of the end of 1991 against Nintendo's 1.4.

To be honest, its probably worth taking any information about sales figures coming from official statements with a grain of salt.

OTOH, I wouldn't be surprised if the NES outsold both consoles considerably that year . . .Yeah, I think we checked this once, and even with SNES + Genesis 1991 sales added together you still had slightly less unit sales than what the NES managed that year in the US.

A game like Tekken, yes . . . not so much for Virtua Fighter unless you're talking japan specifically.Virtua Fighter would've been perfectly fine, the system just needed to have something representing it for the fighting genre earlier, for people to rally behind, and lessen the supposed weakness.

the VF series never seems to have generated massive interest in the US -not sure about Europe- and seems to have even been overshadowed by Toshinden to a fair degreeIts hard to say with Europe, Tekken was more popular here (the later Tekken's at least), but that could simply be because the PS1 sold more, and the game gained more exposure.

Virtua Fighter 2 certainly had its fans in Britain during the early days, and there were definitely arguments about which was the best, Virtua Fighter or Tekken. I'd say it was certainly far more popular in Britain than any Battle Arena Toshinden.

Aren't the mortal kombat ports pretty decent on the N64?Mortal Kombat Trilogy was poor, generally its regarded as having inferior graphics, animation, and sound to the PS1 version.

Mortal Kombat Mythologies: Sub Zero is a hybrid platfoming style game, and is honestly one of the worst games on the entire system.

Mortal Kombat 4 on the other hand is a fantastic port of the game, very good graphics, very good sound, fluid gameplay, and is, in fact probably the best traditional style 3D fighter on N64 (Fighters Destiny is pretty cool, but uses a very different gameplay style), but MK4 didn't arrive until 2000.

At the time I was actually quite interested in fighting games, and there was definitely a problem in this area. Early on the best you could do was make do with mediocre to decent games like Mace, or Killer Instict Gold. A little later I personally picked up Fighters Destiny quite fast, and it was a good game, but it wasn't really what people wanted (its kind of like 3D fighting mixed with a karate style points system), in Europe we also got a Street Fighter-lite style 2D game called Rakuga kids, which I wanted, and looked for, but never actually saw being sold anywhere at the time. Then later on is when some of the good games started to appear, I bought both Smash Bros and MK4 pretty much as soon as they came out and I wasn't really ever disappointed in either (Smash Bros is actually one of my top 5 fighting games for the whole era)

There was also Bio Freaks, which also got very mixed reviews, but was fun for a while, the gameplay was kind of like Toshiden level lightweight though.

Really, I guess Nintendo should've put Rare onto making a 3D Killer Instinct game (or at the very least putting a proper port of Killer Instinct 2 on the system to make up for Gold), but either way where it comes to the Japanese they were never really that interested in the Midway style fighting games, which Killer Instinct was influenced by, so they would've probably required home grown 3D fighters for that region.

Thenewguy

08-15-2011, 07:46 PM

Black_Tiger

08-15-2011, 09:04 PM

That's assuming Duo sales are even included in that 7 million figure, and not missing entirely.

Who knows if systems like the Shuttle or LT were included either. Chances are that the GT wasn't, even though it's as legitimate a hardware sale as other HuCard playing consoles since it solely supported sales of the exact same type of games (not an offshoot like Game Gear).

Crackdown

08-16-2011, 03:35 PM

I can answer some of this for you;

1. Built into the hardware. IIRC it can do something like 4:1 compression
2. Pass
3. Very easy indeed, just one command puts it to sleep just as intended
4. It can do everything mode 7 can do and a hell of a lot more. Remember that the the 1989 Atari Lynx could do "Mode 7" style features

The Jaguar is a 2D powerhouse that even beats out the Saturn in this catagory, it can push more sprites and also display more colours on screen too. There isn't any commercial games that even get close to maximising the system. The most impressive ones by far for me are these:

Missile Command 3D - Cartridge

The only game released that can utilise the VR Helmet the 3D effect is incredible even without it. Loads of texture mapping and incredibly smooth too. Still my favourite Jag game to this day too.

GJmnmRzWipo

Hoverstrike: Unconquered Lands - CD

A considerable update from the cart version the frame rate is better, smoother gameplay, more textures and some of the best lighting effects I have seen in any game of this gen. Blows Krazy Ivan in the PS1 and Saturn out the water. Wish there was video of a night mission they look incredible.

CAPtzUnYVOM

However for me the most impressive game I have seen, and I am lucky enough to have played too, is a homebrew RPG being produced by a friend of mine that right now only has a working title of "The Atari Owl Project". It uses a voxel engine for the landscape and textured polygons for all the sprites and objects. Has some of the best draw distance I have seen in a game of this gen.

g4K7ABfzMeA

Thenewguy

08-16-2011, 04:29 PM

Crackdown

08-16-2011, 04:36 PM

I nearly posted the vids of Phase Zero and Native myself. Its a shame Native never got further than a very short demo but its great to see it resserected in the form of Sturmwind on the Dreamcast.

Bigger shame Dactyl Joust is still lost, although there is a strong rumour that somebody in fact has it.

kool kitty89

08-16-2011, 06:01 PM

Koolkitty (hopefully you're still around) I've been wondering about a lot of stuff in regards to the Atari Jaguar recently and am having trouble finding concrete infomation and was hoping you could enlighten me, I have very limited understanding of this stuff so I could be speaking a lot of nonsense LOL
Sure, and I will eventually get around to replying to the above posts when I have time. (went on vacation back on July 19, came back at the end of the month, and have been a bit more busy in RL since ;))

1. I've heard the Jaguar can do some kind of real time decompression? is this an actual feature built into the hardware or are the chips just well suited to be programmed this way? could all the other consoles from that gen have handled a similar sort of thing?
I don't believe there's any true fixed-function hardware support for data decompression (not like the PSX does for FMV, audio, and general data, or Lynx with basic RLE support), but has lots of software resource to handle decompression via "GPU" and "DSP" RISC chips in the TOM and JERRY ASICs respectively. (namely the GPU since it's got a much cleaner/faster/wider main bus connection while JERRY's buggy 16-bit wide bus -though the latter's is still adequate for audio processing or other relatively low bandwidth, computation heavy processing -and is potentially powerful enough to decode MP3 audio)
It's a bit like the 32x's SH2s, but more specialized and with some additional trade-offs. (more powerful and flexible for some things, but with no caches -just scratchpads- and additional bugs and limited tools available from Atari -vs the commercially produced SH2s with documentation and support from Hitachi)

I know there's a software JPEG secompression scheme (or rather a custom derivative called JAGPEG iirc using the custom CRY colorspace) with 14:1 effective compression, but I'm not sure about the decoding speed and JPEG compression isn't that useful for a lot of 2D sprite/BG graphics or textures used in 3D games. (more for large, detailed images for digitized BGs or splash screens)
It would be great for FMV (MJPEG) if the GPU could decode frames fast enough to be useful for streaming video. (all commercial FMV used cinepak derivatives iirc)

For normal game data (including most graphic textures), you'd want to use lossless compression schemes, and for that the GPU should also be quite useful for decompressing on the fly (at least for 2D games or perhaps some less intensive 3D/pseudo 3D games) and even more advanced/intensive compression should be possible for graphics loaded into RAM. (ie not streamed/decompressed on the fly) Actual compression ratios vary depending on the data to be compressed and the compression scheme.

Of course, there's also "compression" in the sense of indexed colors for textures (ie 4-bit 16 or 8-bit 256 color textures indexed from 16-bit RGB or CRY via CLUT) though the blitter doesn't support 4bpp textures unfortunately (unlike the 3DO, Saturn, N64, and PSX) but I believe the object processor does. (and I think it may even go below 4-bit)

2. Is the Jaguar background built with layers like the Mega Drive/SNES? if so, how many does it have?
Yes and no . . . the Jag's video doesn't work like the MD/SNES but has 2 different graphics processors managing things. The real heavy hitter for 2D stuff is the object processor (usu OPL for short) which generates scalable rectangular bitmaps of arbitrary sizes and varying color depths, effectively a very flexible sprite generator (you could think of it a bit like the Neo Geo being all sprites, but with much greater flexibility in number, size, and color depth of sprites -plus the ability to scale up or down; though the actual mechanism of generating graphics is very different from the Neo Geo and directly related to the canceled Panther design which also resembles the 7800's MARIA in a number of ways).
The main limiting factor for the OPL is main bus bandwidth, though it is capable of efficiently utilizing close to the theoretical maximum 106.4 MB/s bandwidth, that's still has its limits and also must be shared for audio/game logic/etc.

Additionally, there's the blitter capable of 2D bitmap drawing to framebuffers (which are output to one or more windows/planes/sprites generated by the OPL), though it's faster to use the OPL directly for most 2D sprite/object generation. (though building a BG plane with the blitter could be preferable to composited OPL objects for some things)

3. How easy is it to completely bypass the 68000?
Bypassing the 68k mainly involves using the GPU as the CPU. That would be fairly straightforward if not for some unfortunate bugs (the worst being an MMU bug preventing code from being run from main RAM -note this is only for code, not data) and the limited tools Atari made available.
The simplest workaround (and the one Atari suggested) was using the blitter to quickly copy chunks of code to local SRAM (where the GPU/MMU had no issues). A better workaround later discovered by hardcore programmers allowed code to be directly run from main RAM via careful by-hand assembly language coding. (not sure if Carmak implemented this or if he managed to implement it in the compiler he developed)

Beyond that there's the fact that Atari's GPU C compiler was basically crap so developers had to use assembly or develop their own compilers for reasonable performance.

There are cases where the 68000 could still be useful even with the rest of the system being pushed efficiently. (Battlesphere makes limited use of the 68000 for such a reason)
And even without the bugs or limited tools, the 68k would still be very useful for 3rd parties sourcing ports of of various console/arcade games (namely 68k based platforms) that had been originally written in assembly (anything in C could be pushed onto the RISCs), but without other changes (local RAM for the 68k to work in or a total replacement with a different CPU) the 68k would still be of very limited use for Jag-specific/optimized games. (unlike the 32x where the MD CPU has it's own 64k of work RAM, let alone the MCD's sub-CPU)

4. Does it have any "Mode 7" style features?
In addition to plain 2D-oriented drawing, the blitter also supports line drawing and filling (flat and gouraud shading) useful for solid/smooth shaded 3D (with assistance from the GPU for the 3D projection calculations), supports hardware z-buffer, and includes a texture mapping feature somewhat like the GBA or Sega CD that's useful for scaling and rotating 2D objects, mode-7 like warping planes, and texture mapped polygons. (however, the designers didn't put a big emphasis on that feature and it's relatively slow compared to other features of the blitter -like G-shading and z-buffering, the latter being a particularly significant portion of JERRY and ironically a feature totally missing from the 3DO, Saturn, and PSX -it's still a lot better than software texture mapping and better renderers make use of some tricks to maximize performance, like drawing to a small buffer in high speed GPU SRAM and quickly copying the result to the framebuffer in DRAM)

Generally I was just wondering how it stacked up in 2D in comparison to PS1/Saturn, what types of 6th generation genres it would've been able to handle (Resident Evil style pre-rendered background based games? 2D fighting games?) and whether games which came out at the time were even remotely maximising the system or not.
I think Crazyace addressed that a few pages back (granted there's a lot of text to wade though).

I'd been of the impression that the Jag's OPL actually gave it major advantages over the PSX or Saturn, but (practically speaking) it's a bit weaker than either with some trade-offs. (potentially significantly better at raw sprite pushing than the Saturn, but weaker once VDP2 comes into play -increasingly so with more and more detailed BGs- while the PSX is more directly comparable -since it renders everything with the GPU, sprite/BGs/etc are all drawn as GPU objects- but has a general advantage of higher bandwidth -133 vs 106 MB/s- as well as a dedicated video bus with no contention for bandwidth for audio/game logic/etc)
The Jag also has less RAM than either system, so less space to load/decompress graphics into.

Of course, comparing the bare Jaguar custom chips (and potential for other configurations thereof, etc) or comparing cost effectiveness are other issues. (and I mean apples to apples cost to performance ratio, not historical consumer prices or even manufacturing costs -since even Sega had a considerable advantage in volume production of the Saturn and connections with suppliers, let alone Sony's vertical integration and the heavy price cuts -vs Jag which was sold above cost for much of its life)

Edit, here's Crazyace's comments from the first page. (and he definitely knows this stuff better than me)

Hi Kitty, my reply here :)

If you take the entire Jaguar's best case , and compare that against the Saturn VDP1 only then it appears comparable, but it's not quite as simple in practise and the hard limits on sprite overdraw are based on max pixels per hor. line , not total pixels per frame.
Once any backgrounds are involved there's no comparision at all.

Also when maxing out the Jaguar this way you end up starving the cpu of any bandwidth - so all processing end's up having to run in vertical blank. And with a complex sprite system the overhead of maintaining the object list can become excessive.

I can answer some of this for you;
1. Built into the hardware. IIRC it can do something like 4:1 compression
Really, there's hardware decoding? I'd thought it was all done via software on one of the RISCs. What sort of compression is supported?

3. Very easy indeed, just one command puts it to sleep just as intended
Halting the 68k isn't the issue . . . programming the GPU as the CPU is. ;) (and even with the GPU handling things, the 68k can sometimes still be useful in some cases)

It can do everything mode 7 can do and a hell of a lot more. Remember that the the 1989 Atari Lynx could do "Mode 7" style features
Yes and no . . . it's a lot more flexible than Mode 7, but it can't do some things that mode 7 can. (like a full-screen 60 Hz scaled/rotated -possibly warped- 256 color tilemapped plane with additional sprites over/behind that) Sort of like how the Sega CD can't match mode 7 on its peak areas. (but can also do many things that mode 7 can't)

And the Lynx is a poor example . . . it has no hardware rotation/warping support at all, so any such demos are doing that in software (ie CPU with assistance from the math coprocessor and blitter) in a very limited manner (as is possible on a bone stock genesis).

Thenewguy

08-16-2011, 06:41 PM

1. Being that the Jaguar uses ROM cartridges instead of CDs, would it actually need as much RAM as the Saturn and PS1? in regards to animation for fighting games for instance, the Neo Geo didn't have much RAM, but the Neo Geo CD had to have tons of RAM to accomodate the change to CDs

2. If the Jaguar decompression is in software using one of the chips, couldn't the Saturn have done some kind of real time decompression for fighting games?

(Essentially with these questions, I'm wondering about the Jaguar's ability to do advanced 2D fighting games, usually I would think the system doesn't have the RAM, but someone has specifically told me that the Jaguar can stream the data from the cartridge, and decompress it 14/1 in real time, giving it access to lots of ROM, and I'm wondering if the Jaguar could do this, why not the Saturn?)

3. Why did they (apparently) halve the colour counts in the Saturn and PS1 ports of Rayman?

4. What would be the native (most useable) resolution you would've commonly seen with Jaguar games for 2D and 3D?

5. Is the way the screen is set up not very good for parallax? (I don't really entirely understand about the background to be honest, are you saying you make a rectangle the size of the screen and thats your background, you can then overlay other smaller rectagles in front of it for parallax?, and then the sprites go on top of both?)

6. Can the Mode 7 features be used for flooring like you see with Saturn's 3D fighting games?

Sorry, loads of questions :D

Chilly Willy

08-16-2011, 07:43 PM

1. Being that the Jaguar uses ROM cartridges instead of CDs, would it actually need as much RAM as the Saturn and PS1? in regards to animation for fighting games for instance, the Neo Geo didn't have much RAM, but the Neo Geo CD had to have tons of RAM to accomodate the change to CDs

Yes, it does. The ROM is limited and expensive - far more expensive than a CD, hence the need for compression. Since everything in rom is compressed, you need lots of ram to decompress to. 2MB is barely enough.

2. If the Jaguar decompression is in software using one of the chips, couldn't the Saturn have done some kind of real time decompression for fighting games?

(Essentially with these questions, I'm wondering about the Jaguar's ability to do advanced 2D fighting games, usually I would think the system doesn't have the RAM, but someone has specifically told me that the Jaguar can stream the data from the cartridge, and decompress it 14/1 in real time, giving it access to lots of ROM, and I'm wondering if the Jaguar could do this, why not the Saturn?)

The Jaguar ROM is FAST to access compared to a CD, so decompressing from the ROM is much faster than loading from the CD. You could store compressed data in ram on the Saturn and decompress into vram, but I'm not sure if anyone did that.

3. Why did they (apparently) halve the colour counts in the Saturn and PS1 ports of Rayman?

They didn't. 15 bit RGB is the standard while 16 bit RGB is a bizarre oddball not supported by everyone. The reason is 15 bit RGB is 5 bits per color, while 16 bit is 5 for red and blue, but 6 for green. That makes the hardware more complex due to the odd size of one of the colors. Even if a different version uses 16 bit mode, I'll bet you the source images are still 15 bit.

Crackdown

08-16-2011, 08:07 PM

@Kool Kitty

With regards to turning off the 68k and the bugs you listed the solution has been out there for many years now after the bug work around was discovered by both Steve Scavone (Gorf) and Atari Owl, its out there to use and even despite these bugs there are still older games that don't make massive use of the 68k like Missile Command 3D, Hoverstrike CD and Battlesphere. Its also been long rumoured that some commerical coders knew how to work around the bug too and Dactyl Joust for example used the same technique.

With regards to the Lynx, its not really a poor example as it can actually do things the SNES can't. I was more refering to what people think is mode 7, i.e. Scaling and rotation. Most people don't actually realise what mode 7 is, a very SNES specific graphics mode that was designed with one effect in mind and isn't very flexible at all.

With regards to Rayman I seem to remember the coders themselves stating that the Jag version used more colours on screen simply because it could. The Jag can pretty much display its whole pallette in 2D from what I understand.

I am not a coder as such or a real techie so my information is not always 100% but I am involved with a lot of people who are and can easily go verify any facts with these people if needed.

saturndual32

08-17-2011, 01:50 AM

Dammit, this thread is destroying so many myths, like the PS1 and N64 having weak sprite capabilities, the Jaguar and PCFX being about on par with Saturn at 2d. Whats next...dont tell me there is no such thing as blast processing or that the Megadrive never broke the 64 color limit!

When younger i used to believe that there was some special thing inside the Saturn and Jaguar that made them more powerful than the PS1 and that someday some super homebrewer would prove it, but with all this info about how each hardware works, now i understand that while there was more potential to those systems than what we saw, they just cant match the PS1, let alone the N64 at 3d.

Another thing, wasnt the 3DO pretty weak for it generation when it came to 2d?, i remember reading and interview back in the day on the Game Fan magazine, where the creator of the 3DO admited that it wasnt good at 2d as proven by the SSF2X port and its total lack or parallax, and i think also lower frame rate than the 16bit ports of SSF2.

About PCFX, i know that it uses the same 2 layers of sprites as the Super Graffx, there is a layer for videoclips i think, i guess it also has the 2 background layers from Supergraffx, thats 5 layers so far, but on the specs usully found online, 9 total layers are mentioned. Does anyone know what the other 4 are about? Should the PCFX, Marty and CD32 even be considered part of this generation with their total lack of hardware for 3d?

And damn those are some clean textures on Hoverstrike CD for the Jaguar.

kool kitty89

08-17-2011, 05:06 AM

These canceled games impressed me -

This game Phase Zero is made using voxels, which the Jaguar was apparently good with (this seems to be the same method used in the Saturn game Amok, which makes me wonder if Jaguar could've managed something similar), no other Jaguar games seemed to attempt to use Voxels.
Amok on the jaguar would have been interesting, but it is interesting to note that the 32x was going to get a version of Amok. (Lemo even had a clip of it in the Scavenger demo)

Height map based pseudo 3D engines (be it voxels or doom/wolf3D/duke3D style games) are favored by flexible systems that don't emphasize hardware rendered polygonal 3D (so PCs, the 32x, and Jaguar fit the bill) or for systems with flexible resource in general (Saturn has a lot of CPU resource to help there, N64's CPU and RSP could cater well to that too). In that latter case (where good "conventional" 3D performance is there), use of height maps could still be attractive for managing things polygons just can't match with the available resources. (especially smooth landscales of voxels -doom type height maps are less dramatic in that sense)

But back to the Jag, it really isn't a shame that non polygonal 3D/pseudo 3D wasn't pushed more and earlier. You wouldn't need a Phase Zero class interpolated landscape engine to be reasonably impressive for the time (a decent port of Comanche would have been nice, or Cybermorph with Commanche level terrain -which is, granted, a lot coarser than Phase Zero).

This seems to be the best 2D thing I've seen, it starts at ~7:00

http://www.youtube.com/watch?v=Yd07QHBtYJI
Yeah, though Ultra Vortek is probably the most impressive in that respect of the commercial releases.

4. What would be the native (most useable) resolution you would've commonly seen with Jaguar games for 2D and 3D?
I believe 320x240 was most common (not sure of the exact dot clock, may have been 7.16 MHz like the Amiga), but the resolution was highly flexible (in terms of both window size/resolution and actual dot clock and sync rates used).
I think Doom may be natively running in 160 pixels wide in the game window rather than using doubled pixels in the PC, 32x, SNES, etc. (so saving a bit on rendering bandwidth and more on framebuffer space)

5. Is the way the screen is set up not very good for parallax? (I don't really entirely understand about the background to be honest, are you saying you make a rectangle the size of the screen and thats your background, you can then overlay other smaller rectagles in front of it for parallax?, and then the sprites go on top of both?)
You can think of it as having a lot of variable size (very small to very large) sprites to build the entire BG and all objects with, the main limit being memory bandwidth. You could build the entire BG with one large "sprite" (which could potentially have the blitter additionally render to as a framebuffer) and/or you could build the BG with a composite of smaller sprites. (again, sort of like the Neo Geo but with much more flexibility with the sprites and with a blitter to use on top of that)

6. Can the Mode 7 features be used for flooring like you see with Saturn's 3D fighting games?
Think of it more like the Sega CD's scaling/rotation ability (or GBA's), or for that matter somewhat like the Saturn's VDP1, 3DO, or PSX GPU (except without independent support for 3D projection of primitives). It's not really like the SNES's mode 7 or the Saturn's VDP2, it's a blitter with affine texture mapping functionality rendering to a framebuffer.

So, yes it could do flat, warped, textured floors (as can the PSX, 3DO, Saturn VDP1, Sega CD, and GBA -or PC or 32x via software), but it can't do it on par with the Saturn's VDP2 in terms of framerate (at comparable resolutions) much like the Sega CD can't hope to match mode 7 under such circumstances. (the relatively weak texture mapping hardware would also tend to fall behind the Saturn and certainly PSX, possibly 3DO depending on the circumstances)

Yes, it does. The ROM is limited and expensive - far more expensive than a CD, hence the need for compression. Since everything in rom is compressed, you need lots of ram to decompress to. 2MB is barely enough.
Yes, though in a raw technical comparison you could potentially ignore that. (or int he modern homebrew sense with cheap flash ROMs -though you'd need a mapper to go beyond 6 MB and I'm not sure it's possible to enable faster cartridge bus speeds than 2.66 MHz)

The Jaguar ROM is FAST to access compared to a CD, so decompressing from the ROM is much faster than loading from the CD. You could store compressed data in ram on the Saturn and decompress into vram, but I'm not sure if anyone did that.
It would be more significant for the 32x, especially since RAM is so limited in that case.

The Jag RISCs may also be better suited to such computation than SH2s, but I'm not sure.

They didn't. 15 bit RGB is the standard while 16 bit RGB is a bizarre oddball not supported by everyone. The reason is 15 bit RGB is 5 bits per color, while 16 bit is 5 for red and blue, but 6 for green. That makes the hardware more complex due to the odd size of one of the colors. Even if a different version uses 16 bit mode, I'll bet you the source images are still 15 bit.
16-bit RGB could potentially be 6-5-5, 5-6-5, or 5-5-6 RGB (and any system using 18-bit or higher output could potentially cater to all 3 -though I don't think the Saturn or PSX supported that), but in any case I'm not sure Rayman even took advantage of that. (if it had, posterizing to 15-bit wouldn't be a big hit -let alone more optimized edits to the graphics)

However, another possibility would be use of 24-bpp graphics (unlikely due to framebuffer space) or the Jaguar's custom CRY colorpace (a chroma/luma based scheme with 256 colors at 256 luminance levels interpreted as 24-bit RGB) and that could lead to a much larger discrepancy. (most of the blitter and OPL shading and other effects are optimized for -or limited only to- CRY, so using that would be very attractive) I do wonder a bit why they didn't use a conventional Y/C based colorspace like YUV/YCbCr. (even the YKJ format Yamaha used for the V9958 was less obscure than what the Jag used . . . and CRY also makes the odd assumption that humans are most sensitive to the color red when the scientific consensus is that green is the most significant)

That reminds me of another thing, I'm not sure how the Jaguar handled alpha blending (translucency) effects, or if they were supported in hardware (blitter or OPL) at all. (I wouldn't be surprised if they only worked for CRY graphics)

With regards to turning off the 68k and the bugs you listed the solution has been out there for many years now after the bug work around was discovered by both Steve Scavone (Gorf) and Atari Owl, its out there to use and even despite these bugs there are still older games that don't make massive use of the 68k like Missile Command 3D, Hoverstrike CD and Battlesphere. Its also been long rumoured that some commerical coders knew how to work around the bug too and Dactyl Joust for example used the same technique.
I was talking more in the context of the Jaguar's active commercial lifespan (ie ~1993-1995). Obviously things are a bit different with the current homebrew scene.

With regards to the Lynx, its not really a poor example as it can actually do things the SNES can't. I was more refering to what people think is mode 7, i.e. Scaling and rotation. Most people don't actually realise what mode 7 is, a very SNES specific graphics mode that was designed with one effect in mind and isn't very flexible at all.
Yes, but you specifically mentioned mode7-like effects (which entailes 1 or 2 large, potentially highly detailed, 256/128 color planes that are scaled and rotated at high framerate and able to fill the screen -and 3D warped perspective with a little extra CPU grunt to set each line independently). If you mean plain zooming/scaling, the Lynx is notable good for that . . . if you mean more complex software-oriented scaling/rotation (or ray casting, etc) then you're again hitting trade-offs with the SNES. (even ignoring the SNES's added 2D capabilities)

Using mode 7 as a plain 8bpp packed framebuffer for software rendering is one of the very useful exploits of that mode that's used in oddly few games (like Toy Story and Wolf 3D). It's a bit odd that software rendered games using the planar graphics modes were used at all (aside from a few where high resolutions in 16 colors were preferable -like Star Fox, Vortex). The ability to zoom in low-res windows in mode 7 further facilitates this (Wolf 3D is 112x96 zoomed 2x to 224x192), though the Lynx has some assistance from the blitter while the SNES CPU has to software render manually (more important for solid/line filling like for polygons) and both have 16-bit math coprocessors. (not sure how Suzie compares to the 16-bit Mul/div processor embedded in the SNES's CPU ASIC -there's an additional coprocessor in one of the PPUs, but that's not available with mode 7 active)

With regards to Rayman I seem to remember the coders themselves stating that the Jag version used more colours on screen simply because it could. The Jag can pretty much display its whole pallette in 2D from what I understand.
It can in 3D as well, but it's impractical in both cases due to the large amount of framebuffer and/or texture space. (not sure if the OPL had CLUT support for textures indexed to 24-bit RGB -I know the blitter only supports 16-bit RGB/CRY indexing) The PSX can do 24-bit RGB, but the GPU can't render that (only software rendering -I think JPEG and H.261 may support output to 24-bit RGB too). The Saturn's VDP1 color is a bit limited (indexed from 15-bit RGB or using the VDP2 CLUT indexes, but VDP2 can do both of those as well as direct 24-bit RGB textures. (which take up a lot of space though)

But, as above, the Jag's CRY could be a major factor in this case.

Thenewguy

08-17-2011, 08:12 AM

Yes, it does. The ROM is limited and expensive - far more expensive than a CD, hence the need for compression.
But going the Neo Geo route (uber expensive cartridges) was still feasible? or would the bank switching be a problem there?

They didn't. 15 bit RGB is the standard while 16 bit RGB is a bizarre oddball not supported by everyone. The reason is 15 bit RGB is 5 bits per color, while 16 bit is 5 for red and blue, but 6 for green. That makes the hardware more complex due to the odd size of one of the colors. Even if a different version uses 16 bit mode, I'll bet you the source images are still 15 bit.
Ok, that basically went over my head, are you saying that Rayman Jaguar having 65,000 colours onscreen, and Rayman Saturn/PS1 having 32,000 is an urban myth?

Or are you saying that its something to do with the porting of the obscure Jaguar colour system to other machines resulting in them having fewer colours, not any actual limitations with the systems themselves.

Dammit, this thread is destroying so many myths, like the PS1 and N64 having weak sprite capabilities, the Jaguar and PCFX being about on par with Saturn at 2d.
At this stage I'm not really entirely sure what the believe, I (and everyone I've ever spoken to) always simply took it for granted that it was obvious the Jaguar was worse at 2D than the PS1/Saturn

But then I start getting Retrogamer magazine and there are loads of articles on the system, and quotes which essentially say that the Jaguar is, in fact the best machine of that generation for 2D, at least on par with the Saturn.

Now I'm here, and people are basically saying everything I guessed when I was a kid about the Jaguar, was essentially correct LOL.

But back to the Jag, it really isn't a shame that non polygonal 3D/pseudo 3D wasn't pushed more and earlier.
Is this a typo? it seems a little bit odd given the context

You can think of it as having a lot of variable size (very small to very large) sprites to build the entire BG and all objects with, the main limit being memory bandwidth. You could build the entire BG with one large "sprite" (which could potentially have the blitter additionally render to as a framebuffer) and/or you could build the BG with a composite of smaller sprites. (again, sort of like the Neo Geo but with much more flexibility with the sprites and with a blitter to use on top of that)
Ok, I think I get this now, are there any advantages to building the background like that?

Chilly Willy

08-17-2011, 07:17 PM

Yes, though in a raw technical comparison you could potentially ignore that. (or int he modern homebrew sense with cheap flash ROMs -though you'd need a mapper to go beyond 6 MB and I'm not sure it's possible to enable faster cartridge bus speeds than 2.66 MHz)

Yes, that comment was for at the time, not today. Today, you could just use a large (maybe bank selected) rom with uncompressed data.

It would be more significant for the 32x, especially since RAM is so limited in that case.

The Jag RISCs may also be better suited to such computation than SH2s, but I'm not sure.

The primary limit on the 32X beyond the ram is the bus - everything is on a 16 bit bus. The Jaguar does better mainly because they used really wide buses for the RISC processors. The 32X would have REALLY kicked some butt with wider buses. :D

16-bit RGB could potentially be 6-5-5, 5-6-5, or 5-5-6 RGB (and any system using 18-bit or higher output could potentially cater to all 3 -though I don't think the Saturn or PSX supported that), but in any case I'm not sure Rayman even took advantage of that. (if it had, posterizing to 15-bit wouldn't be a big hit -let alone more optimized edits to the graphics)

No one has ever made a 16 bit mode with blue or red using 6 bits instead of green for two reasons: green is easiest for the eye to perceive making green the best use of the extra bit, and while red is easier than blue for the eye, it is also the worst handled by most video/TV encoding formats. Look at the reds on NTSC... pretty nasty!

However, another possibility would be use of 24-bpp graphics (unlikely due to framebuffer space) or the Jaguar's custom CRY colorpace (a chroma/luma based scheme with 256 colors at 256 luminance levels interpreted as 24-bit RGB) and that could lead to a much larger discrepancy. (most of the blitter and OPL shading and other effects are optimized for -or limited only to- CRY, so using that would be very attractive) I do wonder a bit why they didn't use a conventional Y/C based colorspace like YUV/YCbCr. (even the YKJ format Yamaha used for the V9958 was less obscure than what the Jag used . . . and CRY also makes the odd assumption that humans are most sensitive to the color red when the scientific consensus is that green is the most significant)

I do believe CRY is what Rayman uses, which is why they say that version has 64K colors - it's a 16 bit pixel with (like you say) 8 bits of luminance info and 8 bits of chroma info. The main reason to use this mode as opposed to EITHER RGB 555 or 565 is that you get smoother gradiants. 555 or 565 RGB can do about 32 shades of a "pure" color, while cry does 256. That avoids banding issues that crop up in 15/16 bits modes which require dithering to reduce the appearance of banding. CRY didn't need dithering while still avoiding banding, so was a common format on the Jaguar.

But going the Neo Geo route (uber expensive cartridges) was still feasible? or would the bank switching be a problem there?

No, big roms would work. Bank switching is only an issue if you do it like SEGA did the Z80 bank in the Genesis - setting the bank one bit at a time serially. As long as you don't do something that stupid (dumbest thing on the Genesis, hands down), bank selecting is fine.

Ok, that basically went over my head, are you saying that Rayman Jaguar having 65,000 colours onscreen, and Rayman Saturn/PS1 having 32,000 is an urban myth?

Or are you saying that its something to do with the porting of the obscure Jaguar colour system to other machines resulting in them having fewer colours, not any actual limitations with the systems themselves.

The source art is almost certainly in 24 bit RGB, so it's more your latter statement. Conversion of the artwork to the format used by the machine results in 64K colors on the Jaguar, and 32K colors on the PC/PS1/Saturn. It's slightly more complicated due to the formats themselves... CRY on the Jaguar is NOT 64K "colors" so much as 64K "shades" - it really only has 256 colors at 256 different saturation levels. That makes for better shading with less banding on gradiants (as I mentioned earlier), but actually has less color variation. RGB allows the widest color variation, but at the expense of fewer shades of any one particular color.

So in the end, CRY will look smoother without dithering, but not quite as colorful. RGB with be more colorful, but with banding that might be partly mitigated with dithering (which many people think looks nasty on higher def TVs).

At this stage I'm not really entirely sure what the believe, I (and everyone I've ever spoken to) always simply took it for granted that it was obvious the Jaguar was worse at 2D than the PS1/Saturn

But then I start getting Retrogamer magazine and there are loads of articles on the system, and quotes which essentially say that the Jaguar is, in fact the best machine of that generation for 2D, at least on par with the Saturn.

Now I'm here, and people are basically saying everything I guessed when I was a kid about the Jaguar, was essentially correct LOL.

The Saturn wins hands down for 2D IF the game makes full use of the VDP2 in the Saturn. You have multiple tile-based scroll layers that can also be rotation layers, all handled in real-time by a dedicated VDP. Everyone else builds a 2D game using multiple calls to their VDP to blit elements into a frame buffer. For the Saturn, it would be like ignoring VDP2 and only using VDP1... which some game devs did because it was easier.

Thenewguy

08-17-2011, 08:30 PM

No, big roms would work.
Well, thats something I guess.

Taking into account that I don't really know what I'm talking about, would you be able to compress some elements of the game onto the cartridge (such as a fighting game background image, or the music) decompress that to the RAM, and then stream the uncompressed sprite animation in real time from ROM?

I'm just thinking that by the late 90s cartridge prices had dropped a lot, 16MB cartridges were very common on N64 by the end of the 90s, with 32MB fairly common, and 64MB rare, but available.

Nintendo probably had more clout with manufacturers than Atari, but had the Jaguar been successful, and lasted out the generation I'm sure at least 16MB cartridges could've been made, many of the big fighting games of that generation, which were on Neo Geo seem to hover around 20MB, maybe with a little bit of compression they could've fitted onto a 16MB Jaguar cartridge, at a reasonable price.

Crackdown

08-17-2011, 08:53 PM

The Saturn wins hands down for 2D IF the game makes full use of the VDP2 in the Saturn. You have multiple tile-based scroll layers that can also be rotation layers, all handled in real-time by a dedicated VDP. Everyone else builds a 2D game using multiple calls to their VDP to blit elements into a frame buffer. For the Saturn, it would be like ignoring VDP2 and only using VDP1... which some game devs did because it was easier.

You mean like in the Jaguar where most programmers ignored the custom chips completely and just used the 68K. Sorry but the Jaguar destroys the Saturn in 2D, on sprites and colours alone.

Chilly Willy

08-17-2011, 10:02 PM

You mean like in the Jaguar where most programmers ignored the custom chips completely and just used the 68K. Sorry but the Jaguar destroys the Saturn in 2D, on sprites and colours alone.

Uh... no. The Jaguar builds it's 2D games via a list of blits into a framebuffer much like the other consoles. It's very fast at doing that - faster than other consoles, with a few more options it can do while doing so, but it cannot compete with VDP2 on the Saturn. Sorry, but that's just the way it is. VDP2 layers can also use 24 bit graphics, so it doesn't win on colors, either.

If you compare the Jaguar to just VDP1, it's much closer - the object processor in the Jaguar has a better bus, more options, and can do 64K colors (in CRY mode), while VDP1 is limited to 32K colors, and has a worse bus, but even then, you cannot say the Jaguar "destroys" VDP1 - it's only SLIGHTLY better. Then add on two SH2 processors and a fast 68000 as opposed to just a fast 68000 in the Jaguar and you can see why GENERALLY speaking the Saturn has better games than the Jaguar.

saturndual32

08-17-2011, 10:19 PM

So taking into acount everything thats considered important to be the king of 2d of that generation the things would look kinda like this:

Sprites: The blitter in the Jag is a bit better that the VDP1 on Saturn at pushing sprites but due to the numerous problems with the Jag architecture (bugs, botlenecks), they end up mostly on the same level.

Backgrounds: The VDP2 on Saturn is a monster background procesor, it can do 5 diferent background layers and 2 of them can be rotated mode 7 style, while the Jag has to use/waste its sprites for building the background.

Special effects: Saturn can do sprite and background scaling and rotation, the Jag can do sprite scaling but rotation seems to be pretty slow, has to build the background with sprites so the same applies here.

Colors: They use diferent formats, the Saturn has more color variation, while the Jag has more shades of each color.

This is what i have understood so far from the comments posted, this thread rocks guys!. What i would like to know is how the PCFX ever got the reputation of Saturn quality 2d, if it only has the Supergraffxs sprites and background capabilities, i know it has a few other layers of video, but still...

kool kitty89

08-18-2011, 01:14 AM

Another thing, wasnt the 3DO pretty weak for it generation when it came to 2d?, i remember reading and interview back in the day on the Game Fan magazine, where the creator of the 3DO admited that it wasnt good at 2d as proven by the SSF2X port and its total lack or parallax, and i think also lower frame rate than the 16bit ports of SSF2.
The 3DO was OK at 2D, its graphics hardware is a bit like the Saturn's VDP1 (rendering quads that can be scaled/rotated/warped) though the bandwidth is a fair bit worse, but 3D transparency works and I think there may be support for 24-bit rendering in hardware. (or at least 24-bit output for interpolation/filtering for the full-screen antialiasing functionality)
It's enough to be impressive compared to 16-bit consoles (especially in color and scaling/rotation effects), but it's nothing special against the PSX or Saturn.

However, I'm not sure how well 3DO's programming libraries catered to 2D performance, so that could have compromised the raw potential in 2D. (since low-level coding to the hardware was basically banned/impossible on the 3DO -sort of the polar opposite of the Jaguar ;))

About PCFX, i know that it uses the same 2 layers of sprites as the Super Graffx, there is a layer for videoclips i think, i guess it also has the 2 background layers from Supergraffx, thats 5 layers so far, but on the specs usully found online, 9 total layers are mentioned. Does anyone know what the other 4 are about? Should the PCFX, Marty and CD32 even be considered part of this generation with their total lack of hardware for 3d?
PCFX has the SGX layers and sound hardware (but without the 65C02 CPU) with the added feature that sprite or BG layers can be paired to 256 colors and that all color palettes are indexed from 24-bit RGB (or YUV interpolated to RGB) rather than 9-bit (16.7 million vs 512 colors). On top of that, you've got the fairly powerful NEC V810 CPU and the new 2D BG generator with 4 additional layers (I forget the specifics, but I believe they're somewhat close to the Saturn's VDP2 layers sans the scaling/rotation support). On top of that, there's the 2 MB of RAM, ADPCM channels, and streaming video decoder.

All 3D would need to be handled in software on the system and would be better than the 32x in some areas but worse in others. (CPU is more powerful in some respects, but slower/weaker in others and there's only 1, the 2 MB of RAM is a major advantage to be sure)

The FM Towns (Marty or any of the 16 MHz 386SX models) is certainly weaker for 3D than the PCFX and probably weaker in 2D for some things (sprite heavy games could have an advantage though) and the sound is arguably better than the PCFX. (it's definitely worse for multimedia/FMV though -PCFX was about equal to the PSX in that respect, apparently better than the PSX's own MJPEG though the PSX also has H.261 support which would be superior for a lot of FMV)

The CD32 is really weak, modest CPU (for the time) without coprocessors to compensate, barely upgraded hardware acceleration over the 1985 Amiga, heavy RAM bottlenecks (especially due to no fastRAM), etc. It wasn't even better than the SNES or Genesis in some areas, let alone the FM Towns or PCFX (or jaguar). The one area it might be better than the FM Towns could be multimedia due to the 2x data rate, but that's assuming the CD32 could pull off 2x speed cinepak (and some audio format) decoding at full speed. (except the FM Towns, though 1x speed CD, has highcolor support for potential highcolor cinepak or Truemotion if the 386SX is fast enough to handle that)

Whether the CD32 or FMTowns qualify as 5th gen consoles is more up to semantics or how you define the generation. (tech specs, release date, etc -though the FM Towns computer was released in 1989 and the Marty is technically identical other than form factor)

And damn those are some clean textures on Hoverstrike CD for the Jaguar.
Phase Zero's interpolated voxel terrain is still a lot more impressive IMO. ;) (and the PSX, 3DO, and Saturn should all easily match those textures, though if it's using CRY, the shading/lighting can't be as smooth as the Jag -CRY allows 24-bit quality lighting/shading with some trade offs like limited color selection and difficulty with some specific lighting effects like lens flares and shading towards white rather than black)
The PSX optionally allows dithered interpolation for shading too (like many PC accelerators featured), and that allows smoother shading gradients at the expense of a grainy look. (the alternative is a poserized look)

saturndual32

08-18-2011, 04:30 PM

kool kitty89

08-18-2011, 06:03 PM

At this stage I'm not really entirely sure what the believe, I (and everyone I've ever spoken to) always simply took it for granted that it was obvious the Jaguar was worse at 2D than the PS1/Saturn

But then I start getting Retrogamer magazine and there are loads of articles on the system, and quotes which essentially say that the Jaguar is, in fact the best machine of that generation for 2D, at least on par with the Saturn.
It's not really the most powerful, but it is very capable in 2D (it's its strongest point against the competition for sure -with advantages and trade-offs). Some discussions on the topic from particularly passionate Jag programmers end up exaggerating the Jag's advantages (which led to some of my more extreme comments on the topic earlier), but Crazyace corrected me on that in the first page of this thread. (that's in respect to the commercial jaguar console specifically, not hypothetical comparisons of the custom chips used in a more powerful/expensive configuration -hell, even the Arcade Cojag implementation looks rather conservative next to the PSX and Saturn, especially the 68EC020 version)

Now I'm here, and people are basically saying everything I guessed when I was a kid about the Jaguar, was essentially correct LOL.

Is this a typo? it seems a little bit odd given the context
Yes, I messed up there. It should have read: "it really is a shame", not "isn't" :lol:

Ok, I think I get this now, are there any advantages to building the background like that?
Each sprite/object can be manipulated independently (rather than having 1 solid BG plane, you could have a bunch of smaller scenery layers that scroll independently). A fully blitter based rendering system has similar advantages though the rendering process works a bit differently. (ie the PSX, N64, PC, etc -3DO too, but it's weaker in general due to lower bandwidth, 32X too for that matter but also limited in bandwidth as would be slower PCs with no 2D accelerators)
For games that rely heavily on large, full-screen (or close to it) BG layers, the Saturn's VDP1, PCFX, or other conventional character/tilemap BG generators gain an advantage.

The other advantage (or technically part of the same advantage from a different PoV) is the powerful sprite generation capabilities for non BG elements. (ie actual player/enemy/projectile/etc objects)
It's basically all the advantages of the Neo Geo's VDP but with more on top of that (more flexibility with the sprite sizes and color depths, shading effects, scaling, bitmap+blitter functionalities etc). The FM Towns also shares some of these aspects too with a large number of hardware sprites as well as bitmap (framebuffer) graphics capabilities. (not sure about hardware blitting support or character modes though, and character modes would equate to conventional tilemap BGs -the X68000 definitely does that on top of bitmap/framebuffer and hardware sprite support)

One of the least efficient ways to use such an engine would be directly emulating conventional tiled BGs: ie a huge number of relatively small sprites/objects aligned to a grid of rows and columns that basically bypasses all the advantages in flexibility of the system. (in the Neo Geo's case, there actually aren't even enough sprites to simulate the PC Engine's, MD's, or even Master System's tiled BGs of 8x8 cells since just one layer in the lowest resolution -256x224 uses 896 character cells on-screen)

Yes, that comment was for at the time, not today. Today, you could just use a large (maybe bank selected) rom with uncompressed data.
ROM bandwidth is also an issue, though fast/expensive ROM (for the time) will bypass that (something NEC actually did with the PCE from day 1 -presumably facilitated by vertical integration) unless there's a hard limit on the Jaguar's ROM speed. (I know the default/standard was 1/10th the system clock speed at 2.66 MHz -the same speed as early SNES games- but I'm not sure how programmable the ROM bus is; the limit definitely couldn't be over 13.3 MHz as that's the max external bus speed supported -Crazyace mentioned earlier that was the speed used in testROM mode iirc)

The primary limit on the 32X beyond the ram is the bus - everything is on a 16 bit bus. The Jaguar does better mainly because they used really wide buses for the RISC processors. The 32X would have REALLY kicked some butt with wider buses. :D
Actually, it's only the GPU, OPL, and Blitter that can actually work on the 64-bit bus and only DRAM is 64-bits wide (ROM is up to 32-bits but some games used 16-bit to save cost, especially since little to no on the fly ROM access was needed). I'm not sure if there's additional DMA block transfer (independent from the blitter/GPU) like in the N64, but that could have been pretty useful in minimizing overhead for on the fly loading.
The on-chip scratchpad is 32-bits wide but operates at the full 26.6 MHz with no wait states. (DRAM takes 2 cycles minimum per read/write)

The DSP and 68000 are both stuck with 16-bit wide data buses, and the DSP has a buggy memory interface that delays 16-bit reads to 6 cycles and I believe writes to 12 cycles (actually slower than the 68000 in that case), but this is limited to external memory (the 32-bit scratchpad is as fast as in TOM, though you get 8 kB rather than 4 -so one particularly efficient arrangement might be to have a sound engine that only read from ROM/DRAM and wrote solely to a small buffer in SRAM and then reading that out to the DAC interface on-chip with JERRY, thus minimizing time on the main bus and avoiding the considerable overhead of additional reads and -especially- writes to DRAM -that might be attractive for the slave SH2 in the 32x too if the audio interface was on-chip ;) ).

With the 32x, you've at least got full speed access for both SH2s (and even the fairly slow framebuffers are faster than JERRY's RAM accesses) . . . and dynamic I/D caches, good C support, no bugs, etc, etc. ;)

No one has ever made a 16 bit mode with blue or red using 6 bits instead of green for two reasons: green is easiest for the eye to perceive making green the best use of the extra bit, and while red is easier than blue for the eye, it is also the worst handled by most video/TV encoding formats. Look at the reds on NTSC... pretty nasty!
That's another flaw with CRY, it puts heavy emphasis on red over green (the documentation even comments that red is the most easily perceived color by the human eye . . . ). Using a more normal Y/C based colorspace (like the common YUV/YCbCR) or even something rather obscure like YJK used in the V9958 of the MSX2+.

I do believe CRY is what Rayman uses, which is why they say that version has 64K colors - it's a 16 bit pixel with (like you say) 8 bits of luminance info and 8 bits of chroma info. The main reason to use this mode as opposed to EITHER RGB 555 or 565 is that you get smoother gradiants. 555 or 565 RGB can do about 32 shades of a "pure" color, while cry does 256. That avoids banding issues that crop up in 15/16 bits modes which require dithering to reduce the appearance of banding. CRY didn't need dithering while still avoiding banding, so was a common format on the Jaguar.

RGB is better for high chroma contrast stuff but is limited in shades relatively speaking (sort of like comparing the GTIA/MARIA palette to 3-3-2 RGB), albeit you COULD have a Y/C based format that is heavily color biased (like 4-bits for luma and 12 for chroma) or a more flexible compromise between RGB and Y/C like RGBI. (the case of a heavily color biased Y/C scheme would probably never be implemented though given how human perception of lumiance is so much stronger than for color -unless you subsample chroma to a lower spacial resolution with such a high range of colors, like 8-bits forlumance at full res and 4:2:0 Cb and Cr at 8-bits each as well)

CRY was mainly aimed at smooth shading for 3D, but it certainly has advantages for certain types of 2D art as well. (smooth shading also only works in CRY mode and 24-bit RGB -but the latter is almost never used)

It's also important to note that, while it's 65k colors in theory, the limits of 24-bit RGB output mean that there's actually fewer than that (and that many colors have slightly off shades/colors or missing shades entirely).

There's also a mode allowing both CRY and 5-5-5 RGB to be used concurrently on a per-pixel basis (1 bit per pixel toggling the colorspace used and 15 defining the color/shade) with the disadvantage of cutting CRY shades to 128. (which isn't that big of a deal, especially with the limits of

No, big roms would work. Bank switching is only an issue if you do it like SEGA did the Z80 bank in the Genesis - setting the bank one bit at a time serially. As long as you don't do something that stupid (dumbest thing on the Genesis, hands down), bank selecting is fine.

Leaving the YM interrupt lines disconnected would be up there too. (worse than the Z80 banks in the sense of not even being a minor cost saving issue)

So in the end, CRY will look smoother without dithering, but not quite as colorful. RGB with be more colorful, but with banding that might be partly mitigated with dithering (which many people think looks nasty on higher def TVs).
Well, at least at such low resolutions and especially when dithering exceeds pixel pairs/checkerboarding and results in very visible artifacts even in composite -much like more heavily dithered FMV on the MCD. (too bad there wasn't finer control on the shading threshold to allow more subtle compromises in posterization and dithering, and/or allowing dithered interpolation to be applied only in the horizontal direction since composite and s-video blend horizontally and even RGB on SDTVs tends to blur a bit horizontally -the same could/should have been done to MCD FMV to reduce visible dithering artifacts)
PC monitors were (and are) effectively HD displays and such dithering was quite common on PC games of the era (albeit the feature was almost always optional via detail settings), but 640x480 and higher res looks far better than the common 320x240 of the PSX.

One other possible option would be realtime chroma subsampling (for rendering and reading the framebuffer), thus allowing full luminance resolution and lower spacial chroma resolution (which is limited on composite/s-video anyway) while maintaining a very broad range of colors on-screen. (granted, dithering could potentially be used in such a manner as well, namely dithering pixels of varying colors but closely approximated luminance values to the correct figure -the simplest implementation would probably be using paired pixels for a pseudo 4:2:1 subsampling scheme)
4:2:1 YUV would allow an effective 16bpp with 24-bit quality color/shades (at the expensive of halving the horizontal chroma resolution), let alone heavier subsampling like 4:2:0 (effective 10-bpp) and not only help with framebuffer space but potentially texture compression/space as well. Such a scheme would obviously add some complexity to the system in logic and/or programming. (and may involve 2-pass rendering with separate chroma and luma planes or specially orgnaized packed Y+C organization)

Taking into account that I don't really know what I'm talking about, would you be able to compress some elements of the game onto the cartridge (such as a fighting game background image, or the music) decompress that to the RAM, and then stream the uncompressed sprite animation in real time from ROM?
That's exactly what most cart based systems (with any significant amount of RAM) tend to do. Decompress/load as much as possible in RAM and update with uncompressed (or moderately compressed) data streamed on the fly if needed. (many games on the Genesis do that, some early ones do no or almost no streaming at all -with everything loaded into RAM ahead of time, those sort of games would also cater well to the limited RAM of the PCDCD ;))
Many late gen SNES games had embedded decoding logic to cut costs on large games while effectively allowing heavily compressed data to be streamed as if uncompressed. (the MD, PCE, and SNES could all do that in software to varying limited degrees with less complex compression formats -like with simple RLE or the UTFC format Sik has a thread on)

I'm just thinking that by the late 90s cartridge prices had dropped a lot, 16MB cartridges were very common on N64 by the end of the 90s, with 32MB fairly common, and 64MB rare, but available.
Yes, but nearly all of those are still heavily compressed to make efficient use of the space (and thus cost/performance ratio). Those 32 and 64 MB games cram a LOT more data than that into the carts.
N64 cars also tended towards the slowest/cheapest ROMs on the market to save cost (something most cart based home consoles do in general -PCE being the biggest exception), but that obviously limited bandwidth from ROM loads in general.

Nintendo probably had more clout with manufacturers than Atari, but had the Jaguar been successful, and lasted out the generation I'm sure at least 16MB cartridges could've been made, many of the big fighting games of that generation, which were on Neo Geo seem to hover around 20MB, maybe with a little bit of compression they could've fitted onto a 16MB Jaguar cartridge, at a reasonable price.
Had it been successful, it probably would have quickly transitioned to CD-ROM via the add-on (and Duo) followed by the much more powerful Jaguar II. (which was technically still weaker in pure 3D than the PSX in some specific areas, but was much closer all around while maintaining and expanding on the flexibility of the original and also being much more high-level programmer friendly -among the added fleatures is hardware support for bilinear filtered textures, so PSX style games could potentially have looked a bit like PSX games on the PS2 with texture smoothing, smooth non-dithered shading, but possibly lower framerate -at least for games limited by graphics bandwidth and not CPU resource -though given the number of games on the PSX that were primarily CPU limited, that wouldn't necessarily be a big disadvantage either, just as how the Saturn's weaker 3D drawing bandwidth doesn't manifest as extremely as the specs imply -especially for more optmized games)

Chilly Willy

08-18-2011, 06:44 PM

Actually, it's only the GPU, OPL, and Blitter that can actually work on the 64-bit bus and only DRAM is 64-bits wide (ROM is up to 32-bits but some games used 16-bit to save cost, especially since little to no on the fly ROM access was needed). I'm not sure if there's additional DMA block transfer (independent from the blitter/GPU) like in the N64, but that could have been pretty useful in minimizing overhead for on the fly loading.
The on-chip scratchpad is 32-bits wide but operates at the full 26.6 MHz with no wait states. (DRAM takes 2 cycles minimum per read/write)

The DSP and 68000 are both stuck with 16-bit wide data buses, and the DSP has a buggy memory interface that delays 16-bit reads to 6 cycles and I believe writes to 12 cycles (actually slower than the 68000 in that case), but this is limited to external memory (the 32-bit scratchpad is as fast as in TOM, though you get 8 kB rather than 4 -so one particularly efficient arrangement might be to have a sound engine that only read from ROM/DRAM and wrote solely to a small buffer in SRAM and then reading that out to the DAC interface on-chip with JERRY, thus minimizing time on the main bus and avoiding the considerable overhead of additional reads and -especially- writes to DRAM -that might be attractive for the slave SH2 in the 32x too if the audio interface was on-chip ;) ).

With the 32x, you've at least got full speed access for both SH2s (and even the fairly slow framebuffers are faster than JERRY's RAM accesses) . . . and dynamic I/D caches, good C support, no bugs, etc, etc. ;)

The 32X uses different access rates for different things, but all buses are 16 bit. The only "full" width access on the SH2 is the internal cache. Accessing the rom is 8 cycles best case, or 17 worst (unless held off by DMA from the rom by the MD VDP). Writing the frame buffer is 3 cycles best case, or 5 worst; reading is slower - 7 cycles best case, or 14 worst. Accessing the 32X hardware registers vary from 2 cycles to 7 cycles. The SDRAM is an odd case because it's hardwired for burst reading; it can transfer 8 words in 12 cycles for a burst read to the SH2 cache - but by the same token, reading uncached STILL does a burst read, but throws out all but the one word desired, so it still takes 12 cycles. Writing the SDRAM is fixed at 2 cycles.

What all this means is you want to try to keep uncached ram accesses down when you can, and access by words, not longs. For example, let's say you have a variable you share between the two SH2's, so it has to be uncached. Making the variable a short int means it takes 12 cycles to read, and 2 to write. Making the variable a long int means it takes 24 cycles to read, and 4 to write. In cases where you need to share a structure, it's usually better to leave it cached and flush the cache lines for the structure before reading. That 12 cycles per word on uncached reads can be a killer if you aren't careful. The other killer is trying to run the 68000 from rom while the SH2s also try to run from the rom. The bus contention on the rom becomes pretty severe. I copy the 68000 main loop to work ram and run it from there so the 68000 stays off the rom bus as much as possible. This can easily triple the speed on the 32X side, depending on how much the SH2s try to access the rom.

But yes, the lack of bugs is really one of the nicer things about the 32X. I don't know how Jaguar devs put up with all the "quirks" they have to program around. In fact, most of the quirks mentioned in the 32X docs from SEGA are only for the developer units, not the production units. Since all my work is on the production unit with a flash card, I don't have to worry about things like using the free run timer to bump the interrupt system periodically.

Thenewguy

08-18-2011, 08:17 PM

Yes, but nearly all of those are still heavily compressed to make efficient use of the space (and thus cost/performance ratio). Those 32 and 64 MB games cram a LOT more data than that into the carts.
Does the Neo Geo use tons of compression? this would be the relevant question, being that we're talking about fighting games which we already know take up ~20MB on Neo Geo being fitted to 16MB (or lower) Jaguar cartridges.

Had it been successful, it probably would have quickly transitioned to CD-ROM via the add-on
Either release the system with CD in the 1st place or not at all. In my opinion the CD add-on would've failed regardless, and if the Jaguar had managed to create a healthy userbase by then a full on shift to the CD add-on could've jeapardised what they'd already built, add-ons may work in Japan, where everyone is more willing to pay more for hardware, but westerners don't like them unless they're cheap, people who don't have a problem with constant upgrading don't bother with consoles, they get PCs

Putting myself into the place of one of these Jaguar owners in the alternate reality, if I owned the system, and Atari said they were shifting focus to CD, I would most likely use the money required for the add-on + some extra, to simply buy a PS1, mainly because I would want a stable, reliable hardware platform which I knew wasn't going to keep requiring top-ups/replacements every few years

Releasing the Jaguar hardware with CD in the 1st place would've been a huge advantage to the system, releasing it later as an add-on would just make Atari look weak, fickle, and/or money grabbing.

On top of that, from what Chilly Willy was saying the CD add-on eliminates a lot of the hardware's 2D advantages anyway, it wouldn't have been able to host competitive fighting games anymore (no streaming and hardware RAM is too low), had fighting companies jumped on board, they may well have continued to make cartridge games.

followed by the much more powerful Jaguar II.
I don't see them being able to release this any earlier than ~1998 without alienating, and losing their userbase to be honest (for the same reasons as mentioned for the CD add-on), and they probably would've still had to have supported the Jaguar 1 simultaneously with the new system for at least another year, maybe discontinuing Jaguar 1 ~1999.

Chilly Willy

08-18-2011, 09:23 PM

Does the Neo Geo use tons of compression? this would be the relevant question, being that we're talking about fighting games which we already know take up ~20MB on Neo Geo being fitted to 16MB (or lower) Jaguar cartridges.

Not that I'm aware of - the bulk of the cart (the tile data) cannot be compressed. The rest of the cart (level data and such) could be compressed and decompressed into ram, but it would probably make little difference to the final size of the cart.

On top of that, from what Chilly Willy was saying the CD add-on eliminates a lot of the hardware's 2D advantages anyway, it wouldn't have been able to host competitive fighting games anymore (no streaming and hardware RAM is too low), had fighting companies jumped on board, they may well have continued to make cartridge games.

Depends on how much memory is in the system - the Jaguar, like the PS1 and Saturn, only had 2MB, so loading data from the CD into ram would restrict how many frames of sprite animation you could have, and the size of the sprites. That was the issue with the PS1 and Saturn on NeoGeo game conversions, and it would have been the same for the Jaguar CD.

saturndual32

08-18-2011, 10:36 PM

I might be about to make the most retarded coment ever, but here it goes:
I dont know where or when but i remember once reading that one of the PCFX video layers was for something called "xelophane" effect or something like that, i am pretty sure i might be mispelling the name, hell, there is a chance that its not even called that:daze:, haha.
Anyway another weak part i see with PCFX is that it only has 256KB of video RAM, compared with 1.50MB VRAM of Saturn, and 1MB of VRAM for PS1 and 3DO.

Another disadvantage that the CD32, Marty and PCFX have, is that none of them have in hardware suport fro sprite scaling, right?

Hey, no one has yet mentioned the Pippin, it came out in 95 so its part of this gen. Where would it rank, more or less? From the few games it has, it seems to be somewhere between the Sat/PS1 and the Jag/3DO in terms of capabilities.

Got off my ass and did some googling and it turns out its no "xelophane", but "cellophane", which is some sort of transparency effect it seems. I seem to recall in the PCFX shooter Zeroigar, on some levels there is a whole transparent layers used for clouds, smoke effects, etc. I guess thats the cellophane background layer, right?
Also i said that PFX didnt seem yo have scaling effects, but it seems it does since it is capable of the following effects: Rotation, magnification, reduction, cellophane, fade, priority. My question would be, can it use this effects on the Supergraffx sprites and background layers, or are they only applicable on the PCFX exclusive scrolls?

kool kitty89

08-19-2011, 05:04 AM

Uh... no. The Jaguar builds it's 2D games via a list of blits into a framebuffer much like the other consoles. It's very fast at doing that - faster than other consoles, with a few more options it can do while doing so, but it cannot compete with VDP2 on the Saturn. Sorry, but that's just the way it is. VDP2 layers can also use 24 bit graphics, so it doesn't win on colors, either.
Jag can do 24-bit rendering too, but all textures (and framebuffers) must be 32-bpp, so pretty inefficent. But that's for blitter based rendering (since the blitter can only use CLUTs for 16-bpp mode, which also only supports indexing for 8 to 16bit, no 4-bit textures -or maybe that's only for 3D/rotated/scaled textures, not positive on that), and I think the object processor is a fair bit more flexible for indexed 24-bit color objects. (not sure how big the CLUT can be or how many CLUTs can be used at once, so it may be worse than the 4096 bytes of dedicated CRAM in the Saturn) In any case, manipulating 24-bpp objects would take a lot more bandwidth than 16bpp.
There's certainly a lot more hardware rendering support for 24-bit RGB than the PSX or Saturn VDP1 have (which is zero in both cases), not sure about the 3DO. (I know the N64 can, albeit using 32-bit words -which is also a limit of the Jaguar's 24-bit mode)

If you compare the Jaguar to just VDP1, it's much closer - the object processor in the Jaguar has a better bus, more options, and can do 64K colors (in CRY mode), while VDP1 is limited to 32K colors, and has a worse bus, but even then, you cannot say the Jaguar "destroys" VDP1 - it's only SLIGHTLY better. Then add on two SH2 processors and a fast 68000 as opposed to just a fast 68000 in the Jaguar and you can see why GENERALLY speaking the Saturn has better games than the Jaguar.
Again, the Jag can do more than CRY as well. It can do 15-bit RGB (I think it supports 5-6-5 too), the very useful dual 15-bit CRY/RGB mode (16th bit defining the colorspace used), and full 24-bit rendering (with some limitations, especially for the blitter).

Hmm, on another note (for any platform with 18-bit RGB or better), 5-5-5-1 RGBI would probably be more worthwhile than 5-6-5 RGB. (though in the Jaguar's case, the blitter shading logic is limited to manipulating 4 and 8-bit boundaries, so if you were to do RGBI of any sort, 4-4-4-4 would make the most sense)

Not that I'm aware of - the bulk of the cart (the tile data) cannot be compressed. The rest of the cart (level data and such) could be compressed and decompressed into ram, but it would probably make little difference to the final size of the cart.
Yes, and I think it's pretty common for arcade systems to use large, uncompressed, relatively fast, and thus expensive ROMs (since it's premium hardware as such -with different goals than the home consumer market, especially for arcade machines intended to run 1 game only or with long periods between replacment).

Depends on how much memory is in the system - the Jaguar, like the PS1 and Saturn, only had 2MB, so loading data from the CD into ram would restrict how many frames of sprite animation you could have, and the size of the sprites. That was the issue with the PS1 and Saturn on NeoGeo game conversions, and it would have been the same for the Jaguar CD.
Loading compressed animation into RAM (in a format able to be decoded at full speed on the fly) would be one workaround for that possible on all of these systems. (you already mentioned this earlier though and implied that it probably was never used on the PSX or Saturn)

Sprites: The blitter in the Jag is a bit better that the VDP1 on Saturn at pushing sprites but due to the numerous problems with the Jag architecture (bugs, botlenecks), they end up mostly on the same level.
No, the bugs have relatively little impact on the quality of 2D games (using the 68k isn't a big issue there either given the relative simplicity of logic/AI involved). The main issue there (in quality) is simply up to popularity of the console, corresponding interest from big-name publishers, and a general lack of high budget games. (as it is, it's rather surprising that the Jaguar got as much support as it did given the market share among other things)

Certain bottlenecks are indeed limiting factors of the system, but that's the same for all machines. (and not things that prevent it from reaching full potential, but rather part of the definition of what that potential is)

Backgrounds: The VDP2 on Saturn is a monster background procesor, it can do 5 diferent background layers and 2 of them can be rotated mode 7 style, while the Jag has to use/waste its sprites for building the background.
Yes and no. You can only rotate (and scale too iirc) when you sacrifice another layer on VDP2 (so if you want 2 scaled/rotated/warped layers, you can only have up to 3 BGs total using VDP2).

Having large BGs generated independently from sprites can be a major advantage, but it can also be marginalized for games that really benefit from building the BGs from many independent objects of different sizes moving independently from one another. (for such games on the Saturn, 5 such objects could be done by the BGs with VDP1 taking up the rest of the slack)

Special effects: Saturn can do sprite and background scaling and rotation, the Jag can do sprite scaling but rotation seems to be pretty slow, has to build the background with sprites so the same applies here.
Rotation/warping effects can only be done by the blitter (rather than the object processor), but if used to a limited extent it can be very fast/smooth at doing that. (trying to render very large rotating objects will certainly starve bandwidth and drop the framerate though -the texture mapping feature really was one of the less emphasized features in the system, though given the designers had to make the decisions on such features back in 1989-1991 -along with other constraints, they did a pretty damn good job ;))

Colors: They use diferent formats, the Saturn has more color variation, while the Jag has more shades of each color.
Jaguar can do both RGB and CRY (and both at the same time), so that's not really a disadvantage. (aside from some effects only working in CRY, like shading/lighting effects on sprites or polygons)

This is what i have understood so far from the comments posted, this thread rocks guys!. What i would like to know is how the PCFX ever got the reputation of Saturn quality 2d, if it only has the Supergraffxs sprites and background capabilities, i know it has a few other layers of video, but still...
It's more than SGX to be sure (the 4 added BGs should be fairly close to Saturn VDP2 quality, but with no scaling/rotation -not sure about translucency), but the SGX sprites are a bit limited and can't be scaled/rotated either (compared to Saturn VDP1 or 3DO even). The CPU is fast enough to do a fair amount of software rendering though, so that would push things a bit closer at least.

I'm not positive on the PCFX's added BG hardware. (it might be closer to the Saturn's VDP2, or even better in some areas, I haven't looked into it in detail) I think Tomaitheous knows a good bit about the system though.

I might be about to make the most retarded coment ever, but here it goes:
I dont know where or when but i remember once reading that one of the PCFX video layers was for something called "xelophane" effect or something like that, i am pretty sure i might be mispelling the name, hell, there is a chance that its not even called that:daze:, haha.
Anyway another weak part i see with PCFX is that it only has 256KB of video RAM, compared with 1.50MB VRAM of Saturn, and 1MB of VRAM for PS1 and 3DO.
The 256k VRAM is ONLY for the old PCE/SGX VDPs (so double what the SGX has available with 128k to each VDP rather than 64k), the PCFX's added BGs get an additional 1 MB of shared RAM to use (shared with CD DMA buffer, ADPCM samples, and streaming video compression data), and that's on top of the 2 MB of main RAM available to the CPU and another 256kB for the CD-ROM cache/buffer (which is 8x the size of the PSX or 3DO's, but 1/2 that of the Saturn's SH1 work RAM).
That also puts the system at a total of 3.5 MB of RAM (not counting the 32k save SRAM).

Another disadvantage that the CD32, Marty and PCFX have, is that none of them have in hardware suport fro sprite scaling, right?
Right, but like the 32x and most PCs of the time, the CPU was fast enough to push a fair amount of that in software. (well behind what the Saturn, Jaguar, PSX, or N64 could manage though and probably behind the 3DO -definitely for rotating sprites- )

Hey, no one has yet mentioned the Pippin, it came out in 95 so its part of this gen. Where would it rank, more or less? From the few games it has, it seems to be somewhere between the Sat/PS1 and the Jag/3DO in terms of capabilities.
Pippin (like unaccelerated PCs and 32x -sans MD VDP) was all CPU grunt with minimal hardware acceleration (basically SVGA graphics with a powerful PPC 603 CPU). That would put it behind the PSX and Saturn for some things, but ahead in others. (going all CPU is the extreme inflexibility but also a total departure of optimization allowed by specialized hardware, and cost/performance disadvantages on top of that -ie it might match some hardware capabilities of the PSX or Saturn, but that custom hardware probably costs a lot less to make to manage that performance -that also depends on how competitive the pricing was on the CPU vs costs for a chip vendor producing the custom chips . . . with Sony's vertical integration being a major mitigating factor that shifts the context of the comparison -that arrangement would allow nominally more expensive hardware to still cost less at similar margins as the competition)

It would have a strongest advantage at things that the other systems don't support in hardware at all (or have limited support for), and it could also have an edge where CPU resource is the biggest bottleneck on the contemporaries. (at least when rendering overhead isn't so heavy as to mitigate any CPU speed advantage)
The CPU used is actually overkill for a console and the relatively similar, but much more cost effective PPC602 would have been much better option had they actually wanted to introduce a somewhat cost competitive system. (ie had the Pippin actually been intended to directly compete in the home console market rather than being aimed at a multimedia system and home computer with gaming capabilities -and such a dedicated game console probably wouldn't have gotten support from Apple in general, but had Bandi done something like that independently -ie a mostly of the shelf PPC+framebuffer+DMA audio based console- it might have had a chance for success -then again, the failed merger with Sega and Bandai is a bigger what-if there ;))

Got off my ass and did some googling and it turns out its no "xelophane", but "cellophane", which is some sort of transparency effect it seems. I seem to recall in the PCFX shooter Zeroigar, on some levels there is a whole transparent layers used for clouds, smoke effects, etc. I guess thats the cellophane background layer, right?
Also i said that PFX didnt seem yo have scaling effects, but it seems it does since it is capable of the following effects: Rotation, magnification, reduction, cellophane, fade, priority. My question would be, can it use this effects on the Supergraffx sprites and background layers, or are they only applicable on the PCFX exclusive scrolls?
Hmm, interesting, if that's accurate then the PCFX BGs are a bit closer to VDP2 than I'd thought. Again I don't know a lot about the added BG hardware, so I can't answer those questions now. (I do believe the added BG VDP also acts as the external RAMDAC and overlay/merging hardware for the PCE/SGX VDPs, so doing alpha blending effects might be possible too -unlike the 32x where that's out of the question for the Genesis layers since video is mixed on the analog end)

Crazyace

08-19-2011, 09:29 AM

Jag can do 24-bit rendering too, but all textures (and framebuffers) must be 32-bpp, so pretty inefficent. But that's for blitter based rendering (since the blitter can only use CLUTs for 16-bpp mode, which also only supports indexing for 8 to 16bit, no 4-bit textures -or maybe that's only for 3D/rotated/scaled textures, not positive on that), and I think the object processor is a fair bit more flexible for indexed 24-bit color objects. (not sure how big the CLUT can be or how many CLUTs can be used at once, so it may be worse than the 4096 bytes of dedicated CRAM in the Saturn) In any case, manipulating 24-bpp objects would take a lot more bandwidth than 16bpp.
The Jaguar only has a single 256 entry CLUT that is used by the Object processor only to expand to 16-bpp only. It's not used by the blitter at all.

kool kitty89

08-19-2011, 03:44 PM

The Jaguar only has a single 256 entry CLUT that is used by the Object processor only to expand to 16-bpp only. It's not used by the blitter at all.
Hmm, so no support for indexed blitter textures whatsoever (aside from drawing each texture to a separate object with the colors indexed on that basis) and no support for 4bpp textures? (is there anything that would even assist in software indexing of 4bpp textures?)

Lack of any 4bpp support would certainly be another disadvantage to contemporary consoles (and make RAM use even tighter, or dynamic decompression even more important).

For 8bpp stuff, other than the CLUT, could textures be formatted to directly use the 256 color CRY palette (with all colors at a common brightness)?

Either release the system with CD in the 1st place or not at all. In my opinion the CD add-on would've failed regardless, and if the Jaguar had managed to create a healthy userbase by then a full on shift to the CD add-on could've jeapardised what they'd already built, add-ons may work in Japan, where everyone is more willing to pay more for hardware, but westerners don't like them unless they're cheap, people who don't have a problem with constant upgrading don't bother with consoles, they get PCs

Putting myself into the place of one of these Jaguar owners in the alternate reality, if I owned the system, and Atari said they were shifting focus to CD, I would most likely use the money required for the add-on + some extra, to simply buy a PS1, mainly because I would want a stable, reliable hardware platform which I knew wasn't going to keep requiring top-ups/replacements every few years

Releasing the Jaguar hardware with CD in the 1st place would've been a huge advantage to the system, releasing it later as an add-on would just make Atari look weak, fickle, and/or money grabbing.
I disagree about the add-on market in general (but that's a separate topic -as is console vs PC markets, probably worthy of a dedicated thread), but I agree with the specific case of the Jaguar meriting CD-ROM from day 1.

It would have made it at least $100 more expensive at launch, and probably would have been a 1x speed drive (vs 2x in the Jag CD), but it would have made it far more attractive to developers and consumers in a number of ways (especially with decent marketing). Games would be far cheaper to manufacture and distribute, making lower budget games much more price competitive and practical for smaller publishers to release while being similar attractive to high profile publishers for much higher profit margins at moderately lower prices than cart versions. Then there's the raw storage capacity adding flexibility for multimedia and general content (some disadvantages to ROM, but overall far more flexible -especially with the decent amount of RAM the Jag has), it would also facilitate ports of larger floppy PC games and newer CD specific PC games (and obviously ports/remakes of various CD console games) and with enough RAM to allow most major PC games to be reasonably cut down to fit.

If they did go CD from day 1, RAM expansion support would have been significant (especially if made more flexible than the existing cart slot). Regardless of whether you think add-ons are a good idea at all (IMO it's all a matter of management and marketing -alone with design of the add-on to actually cater to the market demands), RAM expansion is one of the simplest, most universally useful, and most attractive enhancement to add to a system. (especially a simple, fairly low priced plug-in module, more so if late models had it built-in standard) Multiple RAM expansions could confuse things, so one definitive would have been best. (so like the N64, not the Saturn or PCECD)
RAM expansion is also the oldest add-on implemented on any console, albeit it was most common embedded in carts (ie passing the cost on with every game rather than the much more efficient upgrade route).

As a side note, if they did go CD-ROM, there's a few odd pitfalls of the Jag CD that should have been avoided: use analog mixing for CD-DA to totally avoid main bus/DSP overhead (as it is, all CD-DA is mixed digitally iirc), and the next would be to use an off the shelf CD-ROM chipset (at least initially) to avoid risking a massive licensing investment (which certainly never paid off for the Jag CD). Probably use a similar Phillips chipset (sans the license, just full off the shelf) and a low-cost bulk contract for some Chinese CD-ROM mechanisms. (preferably at least slightly more reliable than the ones used in the Jag CD though)

On top of that, from what Chilly Willy was saying the CD add-on eliminates a lot of the hardware's 2D advantages anyway, it wouldn't have been able to host competitive fighting games anymore (no streaming and hardware RAM is too low), had fighting companies jumped on board, they may well have continued to make cartridge games.
Yes and no.
Ignoring RAM expansion and ROM+CD based games, there's still the massive advantage cheap mass storage of CD and 2 MB in the Jag is still a pretty decent amount for the time (especially with storing some data compressed into RAM to be decoded on the fly).

We aren't talking arcade (or Neo Geo) context here, so ALL developers are going to be very cost-aware meaning that technical advantages of carts are rather worthless in a practical sense. By the time ROM actually got cheap enough to even consider using large sizes (that have a definitive advantage over optimal use of CD), the Jag would already be getting fairly old and a full successor would be likely (especially if you drop all add-ons), or RAM expansion would become extremely attractive.

But overall (especially in the main period of the system's life), CD would be more of a benefit than a detriment for fighting games as well. The real argument would be whether a $350-400 price point was practical for Atari; it would mean a major shift in market strategy if nothing else -they were aiming at a $150 price point, but the advantages are considerable. (and a $350-400 Jag is pretty damn attractive against a $700 3DO or $400 CD32 -though the 3DO was down to $500 by the end of 1994 iirc)

I don't see them being able to release this any earlier than ~1998 without alienating, and losing their userbase to be honest (for the same reasons as mentioned for the CD add-on), and they probably would've still had to have supported the Jaguar 1 simultaneously with the new system for at least another year, maybe discontinuing Jaguar 1 ~1999.
4-6 years is the normal interval between old and new console releases (though there can be considerable overlap of sales of the older console if it's popular), so 1998 would be about right (assuming 1994 was the full release of the Jaguar), or later if the Jag was really successful. (though given the Jag II was actually aimed at being ready in 1996, they probably could/should have evolved that design considerably in the added 1-2 years of development time) If the Jag really was successful (even on the level of the 7800's sales) it probably would have merited being supported into the early 2000s at the very least. (remember, late gen market is often the most profitable, the time when hardware can be sold for profit, re-releases reap dividends, and a trickle of new releases boosts that further)

Hell, if the Jag really got successful (even if only in Europe), pushing back to 1999 for a new console could have been better profit/stability wise. (another thought is licensing it in Japan, since they basically had nothing to lose there -no way in hell they could market in themselves in that region- and while NEC would probably have been much better off with the Jag hardware than the PCFX -let alone if the V810 replaced the 68000 in the Jag or NEC gave a particularly good deal on DRAM/LSI manufacturing, a partnership with NEC and Atari seems unlikely -maybe Bandai given their interest in entering the console market)

Atari was really in no position to push the Jag in any respect in 1993 though (they had a slim chance in Europe that they quickly lost), and the real problems stemmed from what happened from 1989-1993 with no successor to the 7800 and mistakes made in progression/evolution of the ST line (and marketing/management). Atari Corp from 1984-1988 wasn't perfect, but it certainly was doing well (went from steeped in Atari Inc debt and a rather nasty mess from the sloppy transitional management on Warner's part to a fortune 500 company by the time Jack Tramiel retired at the end of 1988 with the fairly decently selling 2600 Jr and 7800 in the US with a niche presence of the ST to massive success with the ST dominating the 16-bit computer market in Europe).

Losing the Jack and then Michael Katz in early 1989 coincided with the start of Atari Corp's decline. (especially ironic that Katz left just a few months before the Lynx was brought out -since he'd formerly been the head of Epyx and had helped foster the working relationship with Epyx on Atari's platforms in the mid/late 80s) 1988/89 marked a point when Atari was in a position (monetarily and reputation wise) to potentially push hard into the console and computer markets, but that didn't happen and it all ended up falling apart under Sam Tramiel's tenure. (how much better Jack or Katz could have managed things is up to speculation though -and with Atari's 1988/89 position, there was potential to allow Katz to push the sort of marketing that he ended up doing at Sega . . . well, in hindsight they probably should have taken up Sega's offer in 1988 to license the Megadrive to Atari in the US in spite of the disagreements -mainly on conflicts of interest in Europe with Sega only interested in licensing to Atari in the US -then again, at the time, the MD had yet to be released and Sega had been floundering in the US and Japan even against the 7800 in the US, so having Sega's exclusive software support was the main foreseeable advantage by far -maybe a compromise could have been met that favored Sega publishing on Atari's computers as well, to mitigate some of the concerns for Europe)

This is way off topic now though, and more of an Atariage subject. ;)

Chilly Willy

08-19-2011, 04:36 PM

Thenewguy

08-19-2011, 07:37 PM

I disagree about the add-on market in general

Well, I can remember back in the day when the Jag-CD was announced people basically reacted two ways, they either laughed it off, or shook their heads. The CD announcement was seen as an admission by Atari that when they'd originally designed Jaguar, they had little idea of what they were doing, or where the industry was heading, they'd made a mess of the design, and were trying to play catch up, and jump on the CD bandwagon that the "real" consoles were pioneering.

The few Jaguar owners I knew at the time were actually furious, they'd paid out for Jaguar's, and had so far got nothing back yet at all bar a good port of Doom, and here was Atari trying to bleed them for more money?!?!

I'd say the announcement of the Jag CD was honestly met with pretty much universal derision, it was directly compared with the Sega CD, and 32X, which were still fresh in the minds of most gamers (in fact 32X was discontinued around the time that Jag-CD was actually released), Sega had probably made add-ons an even less viable model than ever at that stage.

Looking towards the N64 expansion upgrade, even that was still a fairly hard sell, but I'd say that can be held up as a template of a realistic hardware add-on model (it also did limited damage to N64 owners who didn't want it, as few games completely required it to work), it managed to just about tread a very thin line.

It managed to be in a price/feature range where the top end hardcore N64 gamers would just about be tempted, I'd say most mainstreamers though waited for it to drop ~£15-£20 (I certainly had no intention of spending money on a graphical improvement which I could've used for another actual game instead).

On top of that the Jaguar was always going to be in a notably worse position with add-ons than the N64, think about it, had the machine succeeded it would've been as the cheapest console on the market (ie in the budget range) its userbase would be low income families, no way is that userbase going to be buying loads of extras (and you're even talking about RAM upgrades on top of the CD add-on!), who would want to buy the cheapest system on the market, then pay out on a CD add-on, then pay out on a RAM upgrade and still know that they have the weakest console on the market?

but I agree with the specific case of the Jaguar meriting CD-ROM from day 1.

It would have made it at least $100 more expensive at launch, and probably would have been a 1x speed drive (vs 2x in the Jag CD), but it would have made it far more attractive to developers and consumers in a number of ways
It would be the only realistic way in which the Jaguar could ever have succeeded IMO

If CD pushed the Jaguar price over $299 then keep the CD and start downgrading the hardware until you could sell it for $299

On the upside Jaguar was bundled with a cartridge game, which would've at least been one thing saved from the cost with the addition of a CD drive.

We aren't talking arcade (or Neo Geo) context here, so ALL developers are going to be very cost-aware meaning that technical advantages of carts are rather worthless in a practical sense.
But we're not talking Neo Geo prices, we're talking about smaller than Neo Geo sizes, at a later date, cartridge prices dropped tons after the Neo Geo's heyday, N64 was doing 12MB-16MB by 1997 at respectable prices.

It depends on the developer, how they want their product to turn out, and how well the Jaguar actually was at decompression. Capcom chose to release Street Fighter 2 on higher priced Hu-Card simply to get a good version of the game out there without requiring too much RAM expansion. Depending on prices and the size of the Jaguar userbase similar decisions may have happened on that system by 1997-1998.

The real argument would be whether a $350-400 price point was practical for Atari; it would mean a major shift in market strategy if nothing elseOver $300 is clearly not feasible in my opinion, launch for $299 make sure you've dropped it to at least $199 (preferably $150) by the time PS1 and Saturn arrive.

Atari was really in no position to push the Jag in any respect in 1993 though
If thats true then they should've aggressively pushed into Britain and France at the end of 1993, then launched in the US with Euro software, and Euro profits later on (launching in fall of 1994 in the US would've been extremely risky, but if they had no choice, they had no choice), the Japanese launch should've been delayed indefinitely in my opinion.

tomaitheous

08-19-2011, 08:40 PM

It's more than SGX to be sure (the 4 added BGs should be fairly close to Saturn VDP2 quality, but with no scaling/rotation -not sure about translucency), but the SGX sprites are a bit limited and can't be scaled/rotated either (compared to Saturn VDP1 or 3DO even). The CPU is fast enough to do a fair amount of software rendering though, so that would push things a bit closer at least.

I'm not positive on the PCFX's added BG hardware. (it might be closer to the Saturn's VDP2, or even better in some areas, I haven't looked into it in detail) I think Tomaitheous knows a good bit about the system though.

I don't know the system intimately, but I do know it from its reused pce chips and from chats with the mednafen emulator author about the system.

The PCFX has two VDCs. They have 128k vram each (so 256k total). They each generate a BG layer and a sprite layer. In normal mode, the sprites and BG tiles are 4bit pixels with CLUTs (32 entries). But the VCE (much upgraded from the PCE and SGX systems) has a mode that combines either sprite or BG layers from each VDC for 8pixels (two 8bit CLUTs since it would use all 512 entries that are VDC specific).

The PCFX has another chip called "King". King can be configured in a limited micro code sort of way. This allows you to build out different BG setups. And yes, it supports scaling and rotation for one of the layers. I don't remember all the configurations that you can do with it (built with micro code), but typical is the 4 BG tilemap layer mode. Of course, there's also the MPEG/JPEG layer and the cellophane layer. The system supports the 7.16mhz and the 5.37mhz pixel clock modes (not the PCE/SGX 10.75mhz mode), but cellophane layer is only 256 pixels wide. I think it wraps instead of clips, for the higher res mode. The VCE supports YUV, but I don't remember the details. ADPCM and King (which can write to the ADPCM regs too) share a 1megabyte ram space. This is separate from the 2megabyte ram for the cpu and the VDC 256k vram.

There is no sprite scaling or rotation. There is no blitter. It's an old fashion realtime raster based system. I mean, other than using the cpu to soft blits to a PC style bitmap of a King BG layer mode (yes, you can setup a layer to be a linear bitmap mode). There was supposed to be a blitter addon card that did 3D, but I don't know much details about it.

Crackdown

08-20-2011, 02:21 PM

Well, I can remember back in the day when the Jag-CD was announced people basically reacted two ways, they either laughed it off, or shook their heads. The CD announcement was seen as an admission by Atari that when they'd originally designed Jaguar, they had little idea of what they were doing, or where the industry was heading, they'd made a mess of the design, and were trying to play catch up, and jump on the CD bandwagon that the "real" consoles were pioneering.

The few Jaguar owners I knew at the time were actually furious, they'd paid out for Jaguar's, and had so far got nothing back yet at all bar a good port of Doom, and here was Atari trying to bleed them for more money?!?!

I'd say the announcement of the Jag CD was honestly met with pretty much universal derision, it was directly compared with the Sega CD, and 32X, which were still fresh in the minds of most gamers (in fact 32X was discontinued around the time that Jag-CD was actually released), Sega had probably made add-ons an even less viable model than ever at that stage.

Dunno who these people were or where they got their news but the Jaguar CD was announced before the Jaguar was even released. It was always planned, their are prototypes that prove it and appearances at shows early in the systems life too. I actually pre-ordered by Jag CD not long after the machine came out and the only problem was that it came out much later than originally intended because there was no software ready for it.

Black_Tiger

08-20-2011, 02:58 PM

Dunno who these people were or where they got their news but the Jaguar CD was announced before the Jaguar was even released. It was always planned, their are prototypes that prove it and appearances at shows early in the systems life too. I actually pre-ordered by Jag CD not long after the machine came out and the only problem was that it came out much later than originally intended because there was no software ready for it.

I remember the Jag CD being announced and prototype pics coming out very early on. But when it finally launched, it was disappointing, at least by what little coverage it received.

Thenewguy

08-20-2011, 04:54 PM

Dunno who these people were or where they got their news but the Jaguar CD was announced before the Jaguar was even released. It was always planned, their are prototypes that prove it and appearances at shows early in the systems life too. I actually pre-ordered by Jag CD not long after the machine came out and the only problem was that it came out much later than originally intended because there was no software ready for it.
Ok, thats fair enough, but I, and no one I knew had actually heard about it until it was about to come out, so I guess as opposed to it being the announcement of the add-on, it was simply coming soon news/release date anouncements that originally must have alerted most people to its presence.

What was Jag-CD coverage like in popular magazines like CVG, and Games Master?

Chilly Willy

08-20-2011, 07:48 PM

What was Jag-CD coverage like in popular magazines like CVG, and Games Master?

Those were POPULAR magazines? ;) :D

Thenewguy

08-20-2011, 09:25 PM

Those were POPULAR magazines? ;) :D
American magazines aren't widely sold in Britain (you run into the odd one here and there sometimes)

CVG was probably the #1 selling multi-format magazine in Britain right from inception (1981), until around the mid 90s, when Games Master may have overtaken it for a short period, I think CVG went back into the lead in the late 90s after their re-design though, after that magazines like EDGE (which had been around for ages but wasn't that well liked by mainstreamers at first due to its overly serious/pretentious tone), and Games TM grew in popularity during the 2000s.

There were others (The Games Machine, ACE), but I don't think they ever rivalled CVG in popularity, Mean Machines was another one which was very popular at one stage, but that was an offshoot of CVG anyway (started to be a dedicated console mag)

Chilly Willy

08-21-2011, 03:09 AM

Ah - Britain... that explains everything! :)

Crackdown

08-21-2011, 07:59 AM

Ok, thats fair enough, but I, and no one I knew had actually heard about it until it was about to come out, so I guess as opposed to it being the announcement of the add-on, it was simply coming soon news/release date anouncements that originally must have alerted most people to its presence.

What was Jag-CD coverage like in popular magazines like CVG, and Games Master?

The coverage of the Jag was actually very good indeed and I remember C&VG even being positive about titles like Checkered Flag and Club Drive!!!!

A big difference to the American magazines that seemed to set out to destroy the Jag, especially EGM whos Jag bashing reached quite rediculous levels.

The biggest problem in the UK was availability and it if wasn't for that the Jag could have been pretty successful here. Daryl Still who was head of Atari UK was once quoted as saying he had the demand to sell 20 times as many units as he had but just didn't have the stock to sell. I myself worked for Game back in Xmas 1994, I had already had a Jag for a while which I preordered from Telegames, and was keen to push the machine when we got it in however the supply problems were a absolute joke. I can clearly remember having to go in at 7am to recieve our BIG xmas delivery and from this massive load all we got was something like 7 Jaguars. It was unreal, we must have had a waiting list of over 50 people who wanted one. By the time xmas was gone and Atari finally got the supply problems sorted everyone had decieded to wait for the PS1 and Saturn. They really shot themselves in the foot.

The Jaguar should have launched in the UK and Europe first, where Atari was still popular thanks to the ST and Lynx and didn't have a tarnished name like it did in the US where many still associated them with the crash. Had Atari got success here and got British software companies on board (much like the Sega Master System) then they could have launched elsewhere with a much better line up of games and probably at a lower price point to capture the budget market.

Thenewguy

08-21-2011, 01:04 PM

The coverage of the Jag was actually very good indeed and I remember C&VG even being positive about titles like Checkered Flag and Club Drive!!!!

A big difference to the American magazines that seemed to set out to destroy the Jag, especially EGM whos Jag bashing reached quite rediculous levels.
Well, if we're talking about general coverage, then I would say GamesMaster would fall into the negative bracket, they reviewed a lot of games, but tended to criticise the machine at every opportunity.

Not that I'm sure they weren't within their rights to though to be honest, I mean Jaguar didn't really achieve much during its lifespan, and clearly wasn't getting 3rd party support at the time.

The biggest problem in the UK was availability and it if wasn't for that the Jag could have been pretty successful here. Daryl Still who was head of Atari UK was once quoted as saying he had the demand to sell 20 times as many units as he had but just didn't have the stock to sell. I myself worked for Game back in Xmas 1994, I had already had a Jag for a while which I preordered from Telegames, and was keen to push the machine when we got it in however the supply problems were a absolute joke. I can clearly remember having to go in at 7am to recieve our BIG xmas delivery and from this massive load all we got was something like 7 Jaguars. It was unreal, we must have had a waiting list of over 50 people who wanted one. By the time xmas was gone and Atari finally got the supply problems sorted everyone had decieded to wait for the PS1 and Saturn. They really shot themselves in the foot.

At first I thought you may have been overstating some of this, but yeah I just looked at the sales numbers and the system only sold like 100,000 - 250,000 worldwide O.O

I think even if the Jaguar hadn't taken off in Britain to any huge extent, it still realistically could've managed over 100,000 by 1995 in Britain alone had it been released at the end of 1993 and been fully stocked.

They really shouldn't have bothered releasing the system in Japan at all, better to relocate those units to Europe. I can see where they were coming from though, from the US perspective they probably thought they needed Japanese developers to jump on board and thought that releasing it there would help get local support, which was never going to happen.

They would've been better off settling for lower key Euro support instead (and in fact European games actually ended up really taking off that generation anyway).

Some of this makes you wonder if Atari even had the resources to release a console competitor in the US in the first place, they don't seem to have been able to manufacture anywhere near enough machines. Again they may have only realistically had the resources to launch and advertise in a smaller market like Europe, and then use the profit from there to build up for a US release.

The Jaguar should have launched in the UK and Europe first, where Atari was still popular thanks to the ST and Lynx and didn't have a tarnished name like it did in the US where many still associated them with the crash.
Just Britain and France would've been the main priority (apparently Atari ST was never very popular in Germany, I've seen some sales figures and it looks like Germany actually went straight for the Amiga even before the price drops!), concentrate the initial launch on those two countries if need be.

Another problem is that by 1993 Atari fans had most likely moved on to Sega, Commodore, and Nintendo, I think much of their popularity had dissipated by 1993.

Had Atari got success here and got British software companies on board (much like the Sega Master System) then they could have launched elsewhere with a much better line up of games and probably at a lower price point to capture the budget market.
The problem is, British companies during that time were just beginning to grow wise to the US market, so unlike previous machines I think that our companies were going to go where the money was regardless of local popularity, so they were always going to have problems getting support.

Not to mention the fact that whilst Atari may have had a decent name in Britain, and some good feeling here and there, by 1993 they were still certainly behind Sega, Commodore, and even Nintendo in popularity, upcoming machines from all three of those companies would still have been seen to have had better prospects by British companies.

Crackdown

08-21-2011, 01:15 PM

Thenewguy

08-21-2011, 01:34 PM

Not sure where you got that information about Germany as I was always led to believe that Germany was actually THE strongest market for the ST and it did incredibly well there. I certainly remember a lot of German developed software coming out for the ST.
Mainly from official figures written in magazines of the time, some of the German members around here have also backed this up, also I've seen far more German software written for Amiga than Atari ST, and multi-format games seem to have been written for Amiga, and downgarded to Atari ST, unlike the common occurence in Britain which was to do the opposite.

From what I've seen Atari ST was most popular in Britain and France during the late 80s, I'm not sure what happened later in France, but after the British ST price went up due to the worldwide increase in RAM prices, and the Amiga was price cut by £100, the Amiga 500s popularity in Britain skyrocketed and the STs basically nosedived, I would imagine that by the early 90s the Amiga 500 was dominating the ST models.

With regards to the part about British companies and software, I am not sure if you realise but Tomb Raider was originally a Jag exclusive but because the Jag didn't take off Core jumped ship to Sega and Sony and the Jag version was never even released. Had the Jag done better here I am sure Core design would have stuck with it.
Yeah, I've heard that before, could've been very interesting if Tomb Raider had appeared on Jaguar.

Never seen the pictures though, they're pretty awesome! :cool:

sheath

08-21-2011, 02:01 PM

There is no way those are Jaguar shots, nothing 3D on the Jaguar has that many textures.

Thenewguy

08-21-2011, 03:34 PM

There is no way those are Jaguar shots, nothing 3D on the Jaguar has that many textures.
Maybe it ran at 5fps :D

Seriously though, from what I've heard none of the commercial releases even remotely pushed the system, so its difficult to really judge what the Jaguar was capable of.

tomaitheous

08-21-2011, 03:57 PM

Chilly Willy

08-21-2011, 04:01 PM

Maybe it ran at 5fps :D

Seriously though, from what I've heard none of the commercial releases even remotely pushed the system, so its difficult to really judge what the Jaguar was capable of.

It's more a matter of storage than speed. You can use a different texture for every single polygon... if you have the space for it. Textures consume memory quickly - a "tiny" texture of 64x64 like in Wolf3D is 4KB. A 256x256 texture consumes 64KB, or 128KB if it's 5551 or 4444 format. That's ONE texture. Even compressing the textures doesn't help too much since textures (usually) don't compress well, and compression would slow things down. To get all the textures for an entire game to fit in a reasonably sized cart, Jaguar (and other cart consoles) usually limited the number of textures a level could use, and/or shared them as much as possible. There's a reason modern video cards often have as much or more ram than the system. ;) :D

Crackdown

08-21-2011, 04:12 PM

There is no way those are Jaguar shots, nothing 3D on the Jaguar has that many textures.

Dactyl Joust, Atari Owl Project, Hoverstrike CD and Robinson's Requiem do

Thenewguy

08-21-2011, 04:25 PM

a "tiny" texture of 64x64 like in Wolf3D is 4KB.
Isn't that the standard size for N64 games though?

Black_Tiger

08-21-2011, 05:52 PM

There is no way those are Jaguar shots, nothing 3D on the Jaguar has that many textures.

Look at the poorly photoshopped-in sharp Jaguar logo in the "System" box. ;)

It doesn't matter though, since the previews of the 32X version of Tomb Raider were already looking much better.

True story: Core actually finished Tomb Raider for it's target platform, the 32X. But because the 32X didn't take off Core jumped ship to Atari and the 32X version was never even released. The worst part of all is that the 32X version ran at 60fps and had sharper textures than the butchered Saturn and Playstation ports.

http://superpcenginegrafx.net/misc/tr32x.jpg

Crackdown

08-21-2011, 05:56 PM

I assume you are taking the piss in some sort of way. It has long be known Tomb Raider was originally a Jag CD game, it was previewed in Edge and Core programmers have talked about it.

Thenewguy

08-21-2011, 06:17 PM

LOL! so which is it? was the game announced for both? what magazine is that from?

The only places I've actually ever seen a Jaguar version of Tomb Raider mentioned were Atariage, and Retrogamer forums.

EDIT: and we have a winner, EGM #82 May 1996

Judging by the date its most likely an early version of the Saturn or PS1 game.

http://img52.imageshack.us/img52/5887/egmtomb.png (http://imageshack.us/photo/my-images/52/egmtomb.png/)

Black_Tiger

08-21-2011, 07:55 PM

I assume you are taking the piss in some sort of way. It has long be known Tomb Raider was originally a Jag CD game, it was previewed in Edge and Core programmers have talked about it.

The joke was that ridiculous preview that someone stamped with a Jaguar logo.

I don't know how "known" it is that Tomb Raider "was" a Jaguar game. At the most, Core might've been been a licensed Jaguar developer/publisher and one of their ideas was that an upcoming game could very well be possible on the system. So instead of filling their upcoming Jaguar projects list with "To be determined", they simply listed one or more game that they were working on. If there are photos, videos and/or roms of a real actual build of Tomb Raider for Jaguar, I'd love to see them. But companies just go ahead and say stuff all the time that doesn't have anything behind it other than they once thought, "wouldn't it be cool if we did this", and that's as far as a project actually goes.

Thenewguy

08-21-2011, 08:01 PM

I don't know how "known" it is that Tomb Raider "was" a Jaguar game. At the most, Core might've been been a licensed Jaguar developer/publisher and one of their ideas was that an upcoming game could very well be possible on the system. So instead of filling their upcoming Jaguar projects list with "To be determined", they simply listed one or more game that they were working on. If there are photos, videos and/or roms of a real actual build of Tomb Raider for Jaguar, I'd love to see them. But companies just go ahead and say stuff all the time that doesn't have anything behind it other than they once thought, "wouldn't it be cool if we did this", and that's as far as a project actually goes.

I've just been searching through magazines for the past hour and have found zero mention of a Jaguar version of Tomb Raider (even in Retrogamer articles), so I'd imagine its probably a myth, in fact I've found a mention in an interview that the game was designed as multi-platform PC/PS1/Saturn from the beginning, and initial work started on the PC version.

sheath

08-21-2011, 08:43 PM

Dactyl Joust, Atari Owl Project, Hoverstrike CD and Robinson's Requiem do

Believe me, I would like nothing else for the Jaguar or 32X to prove they could ace the Saturn or PS1 in a fully 3D Platformer. I also think that the Jaguar, or actually the 3DO, had the best chance of achieving this. But seriously, the available games just don't leave a lot of hope. I can see a stripped down game with height mapped levels and lightly textured objects, but not vanilla Tomb Raider running on the Jaguar.

XG904E964Ts

g4K7ABfzMeA

f7oXmZNCHQ4

Actual gameplay starting at 5:44
tSXnLDHWI7w

Sorry, but none of that touches this:
3ev6HmOvvVQ

Thenewguy

08-21-2011, 09:06 PM

But seriously, the available games just don't leave a lot of hope.
The problem is (like I said before), there are no examples out there which show the capabilities of the system.

Jaguar games were, for the most part, developed by the dregs of the industry, with only a handfull of experienced coders working on it (ID, maybe Rebellion), not only that but the tools were awful and the hardware difficult to program and buggy, John Carmack stated that programming Doom was a huge learning experience, and that if he'd started it again he would've done everything completely different.

Jaguar games were also programmed by ridiculously small teams (often only one or two people!)

I don't think any Jaguar games run GPU code from main RAM (Atari documents apparently told developers not to do this), from what I've heard doing this, and bypassing the 68000 (which apparently was causing a huge bottleneck) causes an extreme perfomance boost.

Not that I think the Jaguar could've done Tomb Raider the same as the PS1 version or anything, but who knows, maybe a playable, slightly downgraded version could've been possible.

sheath

08-21-2011, 09:33 PM

I would love to see anything like that realized from the homebrew scene. Like I said, I don't think Tomb Raider would be impossible for the Jaguar. I just think it would be a ground up rewrite which would only be justified by the Jaguar being a dominant platform.

Chilly Willy

08-21-2011, 11:47 PM

a "tiny" texture of 64x64 like in Wolf3D is 4KB.

Isn't that the standard size for N64 games though?

32x32 for 16 bit textures with a mipmap. Games eventually started splitting textures and polys into small enough sections to allow better looking textures - instead of one poly with a stretched and filtered 32x32 texture, use several polys with an unstretched 32x32 texture from a larger texture.

Crackdown

08-22-2011, 01:19 PM

The joke was that ridiculous preview that someone stamped with a Jaguar logo.

I don't know how "known" it is that Tomb Raider "was" a Jaguar game. At the most, Core might've been been a licensed Jaguar developer/publisher and one of their ideas was that an upcoming game could very well be possible on the system. So instead of filling their upcoming Jaguar projects list with "To be determined", they simply listed one or more game that they were working on. If there are photos, videos and/or roms of a real actual build of Tomb Raider for Jaguar, I'd love to see them. But companies just go ahead and say stuff all the time that doesn't have anything behind it other than they once thought, "wouldn't it be cool if we did this", and that's as far as a project actually goes.

Core were a licensed developer for the Jaguar, there is a Jaguar version of Soulstar and there were numerous other games announced for the system including Tomb Raider, Thunderhawk and Battlecorps. Early screenshots were shown of some of these games and many made it into prototype stage. There was somebody on AA & JS2 who spoke to Core with regards to their games and they confirmed that Tomb Raider was started and was in an early prototype stage when it was scrapped.

Black_Tiger

08-22-2011, 03:47 PM

Core were a licensed developer for the Jaguar, there is a Jaguar version of Soulstar and there were numerous other games announced for the system including Tomb Raider, Thunderhawk and Battlecorps. Early screenshots were shown of some of these games and many made it into prototype stage. There was somebody on AA & JS2 who spoke to Core with regards to their games and they confirmed that Tomb Raider was started and was in an early prototype stage when it was scrapped.

Early prototype could mean pretty much anything, including something with zero graphics. But I doubt that Tomb Raider was "originally" a Jag CD game. What did Edge show of it in their preview?

Thenewguy

08-22-2011, 04:01 PM

Early prototype could mean pretty much anything, including something with zero graphics. But I doubt that Tomb Raider was "originally" a Jag CD game. What did Edge show of it in their preview?
Or more to the point which issue of EDGE does this preview actually appear in, being that I checked through loads of EDGE magazines yesterday and found no signs of a Jaguar Tomb Raider preview at all (there were loads for PS1/Saturn though)

kool kitty89

08-22-2011, 06:56 PM

Funny coincidence that it's mentioned a few times, but my work on the CD32X has been towards loading compressed data into ram, then decompressing it on the fly. There's really not much choice as ram is so limited. Decompressed data would mean needing to chop the content and/or size of levels, or constant halts to load more data from CD.
In a few cases of very fast/simple to decode optimized compression, you might even get some boost to bandwidth as well (in as far as moving data from the MCD to the 32x) over uncompressed data.

As to platforms with 18 bit RGB, the only one I'm aware of is the N64. The N64 uses RamBus RAM; this was very fast (for the time), very expensive, and meant for high end workstations like the SGI systems. Because of that, it has 9 bits instead of the usual 8, with the extra bit being meant for parity/ecc data. The N64 uses two chips (early on - it switched to one 18 bit RDRAM chip later) for 18 bits per word. The CPU can only use 16 of the 18 bits, with the other two meant for ecc as mentioned; however, the N64 didn't bother as it was a cheap consumer device. Since the engineers knew the extra bits weren't being used for ecc, they designed the GPU to use the extra bits for an extended alpha field in the frame buffer for 15 bit RGB mode. So instead of 5-5-5-1, the frame buffer was 5-5-5-3. Textures were still 5-5-5-1 or 4-4-4-4. All calculations with the frame buffer were done as 3 bits on the alpha. The extra bits weren't used in 32 bit mode as you already had 8-8-8-8 for the pixels. So alpha affects in 15 bit mode on the N64 were a bit better than PCs and other consoles while still retaining the speed of 15 bit mode.
Nintendo undoubtedly got special deals for RDRAM due to their collaboration with SGI (otherwise it really wouldn't have made sense to use RDRAM over SDRAM on a wider bus and/or multiple buses, or even EDO DRAM)
This is really beside my point though and I think you mistook what I meant by 18-bit RGB.

When I said 18-bit, I was simply talking about systems using video DACs with at least 6-6-6 RGB depth (like was standard for VGA) not that a system used direct 18-bit RGB colorspace. (though on that note, I do believe some SVGA cards used a truecolor mode limited to 18-bits due to the RAMDACs used -though the actual framebuffers were still organized as 24 or 32 bpp iirc)
But my actual point was just that any system with 18-bit (or higher) RGB output could be made to support 5-5-5-1 RGBI (not RGBA) with the intensity bit stepping all 3 RGB bits up or down 1 level. (so better than 5-6-5 RGB as you get truly double the shades of 5-5-5 RGB rather than only additional green-biased colors/shades)
I also wasn't addressing RGBA when I mentioned 4-4-4-4 but (again) was referring to simpler RGBI. (ie 12-bit RGB with an additional 16 shades of each color -though in that case you'd need 24-bit RGB for full representation rather than just 18-bit)

I was addressing other possible 16bpp colorspaces that might have been better compromises than plain 15-bit rgb or the Jag's custom CRY, but at least the Jaguar also supports conventional RGB and even has a mode allowing 5-5-5 and 15-bit CRY to be selected on a pixel basis. (though, again, conventional 8-4-4 YUV/YCbCr could have made a lot of sense -especially with a similar RGB+YUV mode reducing luminance to 7 bits for the bit needed to select colorspace; the PCFX did actually go the YUV route)

It's more a matter of storage than speed. You can use a different texture for every single polygon... if you have the space for it. Textures consume memory quickly - a "tiny" texture of 64x64 like in Wolf3D is 4KB. A 256x256 texture consumes 64KB, or 128KB if it's 5551 or 4444 format. That's ONE texture. Even compressing the textures doesn't help too much since textures (usually) don't compress well, and compression would slow things down. To get all the textures for an entire game to fit in a reasonably sized cart, Jaguar (and other cart consoles) usually limited the number of textures a level could use, and/or shared them as much as possible. There's a reason modern video cards often have as much or more ram than the system. ;) :D
Core probably would have targeted the Jag CD for TR, so no cart limits, but also no potential for ROM updates of uncompressed/on the fly decompressed data. (though if it was a cart version, everything would probably be heavily compressed in ROM and decompressed into RAM . . . though that still might be faster than streaming from CD even with very intensive/optimized compression schemes)

32x32 for 16 bit textures with a mipmap. Games eventually started splitting textures and polys into small enough sections to allow better looking textures - instead of one poly with a stretched and filtered 32x32 texture, use several polys with an unstretched 32x32 texture from a larger texture.
The limited ROM space probably didn't make for much incentive to push for higher res, segmented textures either. (less programming work AND space savings on software with tight memory constraints in general ;))
The larger the ROMs got, the less excuse there was to take that route. (though the alternative for smaller game would still be fewer unique textures at higher resolutions, for more texture detail at the expense of "samey" looking environments and a bit more work to manage the tiled texture mapping)

There is no sprite scaling or rotation. There is no blitter. It's an old fashion realtime raster based system. I mean, other than using the cpu to soft blits to a PC style bitmap of a King BG layer mode (yes, you can setup a layer to be a linear bitmap mode). There was supposed to be a blitter addon card that did 3D, but I don't know much details about it.
On the graphics end, it's a bit like if Sega had made the Saturn with a MD VDP in place of VDP1 (except VDP2 is a bit more powerful- sans MJPEG support- and the MD VDP is weaker than dual PCE VDPs).

Given they dropped backwards compatibility, it didn't make much sense to retain all the PCE specific hardware rather than just including the 2D/3D blitter (especially if it was something like the Saturn VDP1 or 3DO Cel engine) unless it was just an issue of the blitter not being ready yet and NEC panicking and rushing the older hardware to market. (especially with Sony on the scene and the Saturn's unveiling in Japan)

Cool pic. Though, AVP fooled me for the longest time with just pics (didn't see it in action until over a decade later). That game is chug'n.
They really shouldn't have gone full-res with that . . . Doom didn't and it looks a lot better in motion than AvP (the more complex height-mapped environment also looks better than the Wolf3D-ish or Gloom-like AvP maps).

Skyhammer looks smoother than AvP, and that's full textured 3D polyons rather than ray casting. (though it too probably would have been better off low-res)

Well, I can remember back in the day when the Jag-CD was announced people basically reacted two ways, they either laughed it off, or shook their heads. The CD announcement was seen as an admission by Atari that when they'd originally designed Jaguar, they had little idea of what they were doing, or where the industry was heading, they'd made a mess of the design, and were trying to play catch up, and jump on the CD bandwagon that the "real" consoles were pioneering.
No (lrather like the PCE) they'd planned the CD before the test market (probably not back in 89-91 when the primary design work was done, but well before release). From all I've seen, the main reason to stay away from CDs was the cost of the drive/chipset/royalties (and/or licensing) for their $150 target price point. (as it was, they were still unable to meet the desired price until 1995 in spite of an extremely tight and cost effective design).
Had they been healthier with steady sales in computers and/or other consoles, they may have had the resources in 1993/94 to sell the console at a loss to keep prices down (as a major long-term investment), though with more money and sustained good management they could have done a lot of things. (far, far better marketing, major in-house software R&D build-up and/or heavy outsourcing to prominent 3rd parties, etc, etc)

The few Jaguar owners I knew at the time were actually furious, they'd paid out for Jaguar's, and had so far got nothing back yet at all bar a good port of Doom, and here was Atari trying to bleed them for more money?!?!
That's where marketing comes in . . . thoughts like that would obviously be fostered in a lack of proper marketing for the CD in general. (ie promoting the obvious advantages of cheaper software -allowing the system to quickly pay for itself, the multimedia capabilities, etc, etc) Of course, not widely promoting the Jag CD from day 1 is another issue (of course, Nitnendo did the opposite with their CD vaporware which infuriated many hardcore SFC/SNES users who'd been strung along for years -with the N64 being cart only another kick in the teeth).

Marketing was definitely one of the biggest problems with the Jaguar, period (especially in the US). Part of that was management, but a lot was simply funding. (albeit the lack of funding could be attributed to sustained bad management from 1989 up to that point)

I'd say the announcement of the Jag CD was honestly met with pretty much universal derision, it was directly compared with the Sega CD, and 32X, which were still fresh in the minds of most gamers (in fact 32X was discontinued around the time that Jag-CD was actually released), Sega had probably made add-ons an even less viable model than ever at that stage.
The Jag CD was released shortly after the whole Saturn launch fiasco, so yeah, that would make sense. (in 1994, being compared to the Sega CD shouldn't have been a bad thing ;))

Looking towards the N64 expansion upgrade, even that was still a fairly hard sell, but I'd say that can be held up as a template of a realistic hardware add-on model (it also did limited damage to N64 owners who didn't want it, as few games completely required it to work), it managed to just about tread a very thin line.
It did ZERO damage to users who didn't own it. Add-ons aren't supposed to detract from the base system at all, but allow things that it can't do at all. (ie the alternative to having add-on specific game would be not having those games on the system at all)

Again, it's all about marketing, management, and catering to the userbase at hand, though price point is a part of that. (but, again, this really deserves a separate topic)

It managed to be in a price/feature range where the top end hardcore N64 gamers would just about be tempted, I'd say most mainstreamers though waited for it to drop ~£15-£20 (I certainly had no intention of spending money on a graphical improvement which I could've used for another actual game instead).
Buying an add-on is a bit like buying a new system . . . and there's similar deliberation for that too. (ie buying more games for the old system vs investing in the new one, but more of a compromise between a full new system and supporting only the old system)
Likewise, many people refuse to buy any new system or games until the prices drop in general (or buy used), no different with an add-on or the associated software. (in the extreme, some people will only buy things when they drop to budget prices)

As with any new system there must be a transition time (and careful management for that), you can't expect most people to jump right away in any case, so the old platform would obviously get the brunt of the support for a fair amount of time. (or indefinitely if it proved to be continually popular alongside the new system)

On top of that the Jaguar was always going to be in a notably worse position with add-ons than the N64, think about it, had the machine succeeded it would've been as the cheapest console on the market (ie in the budget range) its userbase would be low income families, no way is that userbase going to be buying loads of extras (and you're even talking about RAM upgrades on top of the CD add-on!), who would want to buy the cheapest system on the market, then pay out on a CD add-on, then pay out on a RAM upgrade and still know that they have the weakest console on the market?
If it was really popular (with associated big budget marketing) it wouldn't have been relegated to the budget end at all, and it wouldn't have been perceived as weak either. (lots of high quality software from prominent developers would show that ;))

Atari was just in no position to push that . . . they wouldn't have done much (if any) better even if they had the PS1's hardware simply due to the cashflow and management problems.

If CD pushed the Jaguar price over $299 then keep the CD and start downgrading the hardware until you could sell it for $299
No way that could be done and still have a reasonable console for the 5th gen without needing significant add-ons down the line (or a short life in general) as any major cuts would necessarily have involved cutting back on RAM substantially, something that would largely compromise the system's ability to support multiplatform releases from anything but older computer/console games. (ie any newer PC games, or any 3DO/PSX/Saturn/etc stuff)

The only way they could have managed a sub $300 price point with CD in 1993 would have been selling at a loss (something they couldn't afford -and if that could, many other things would also show much improvement from the added funding). Perhaps they could have managed $299 by late 1994 depending on the deals they could get on CD-ROM hardware. (given that they dropped the Jag to $150 and then $100 in 1995 and the CD cost $150 at launch, that wouldn't be unrealistic)
For the 1993 test market, they probably would have been hard pressed to go below $400 given their desperate situation. (they were forced to do the test market to attempt to drum up investment funding -one big reason Europe was left out of the test market was the much greater potential for investors in the US and very limited funds to manage even a test market, though London and Paris had originally been announced as well)

Higher volume production would also be critical for lower prices, but that's one area Atari never managed with the Jaguar, let alone the CD.

But we're not talking Neo Geo prices, we're talking about smaller than Neo Geo sizes, at a later date, cartridge prices dropped tons after the Neo Geo's heyday, N64 was doing 12MB-16MB by 1997 at respectable prices.
Not Neo Geo, but we're still talking $70-100 per new game rather than $30-50 (or less for actual budget titles).
As it was, Jaguar games were relatively small aned priced well above similar sized MD/SNES releases (presumably due to less attractive ROM prices than Sega and Nintendo could manage with distributors as well as the small volumes and Atari's difficulties in general).
So if those didn't change, the Jag would have been even worse off than the N64's rather high game prices. (and that's with Nintendo's relatively high royalties as well)

If Atari had the position and funding to bargain for good ROM prices and a market to produce large volumes for, they probably could have undercut the N64's game prices by a fair amount for similarly sized games. (like Sega may have been able to had they released the Jupiter ;))

It depends on the developer, how they want their product to turn out, and how well the Jaguar actually was at decompression. Capcom chose to release Street Fighter 2 on higher priced Hu-Card simply to get a good version of the game out there without requiring too much RAM expansion. Depending on prices and the size of the Jaguar userbase similar decisions may have happened on that system by 1997-1998.
No they released it on hucard simply because it was the only option for a decent port. The arcade card didn't exist and the Super CD's 256k wasn't enough for a port without cutting a ton of animation. 512k should have been enough for a decent port (ie the MCD should have managed it at least as well as SCE on cart), but that wasn't an option. (not sure if capcom could have made their own RAM cart -ie if NEC had the necessary documentation available- but that would have been a costly undertaking in any case -albeit that did happen with the Saturn)
Combo ROM+CD games also should have been possible, but that may have been a documentation issue as well. (and any such hucards would displace the bios and any RAM expansion on top of that -so particularly unattractive once the Super CD was out . . . unless they'd used a different form factor -ie a new base tray with added RAM instead of a card)

If thats true then they should've aggressively pushed into Britain and France at the end of 1993, then launched in the US with Euro software, and Euro profits later on (launching in fall of 1994 in the US would've been extremely risky, but if they had no choice, they had no choice), the Japanese launch should've been delayed indefinitely in my opinion.
As it was, they probably shouldn't have launched until fall 1994 in any case, the software simply wasn't there yet (and launching ealier in '94 would have watered down hype that could be concentrated for the fall -though as it was, they ended up launching in the spring/summer of 1994). They only pushed the 1993 test release because they lacked the funding to hold off for a proper release and did the test market mainly as a PR stunt for investor interest (and it worked in a sense, they did get some major investor support -including the IBM production contract- thanks to the hype from that test market). Again, that's also the primary reason the European test was canceled (limited funds and US investment seen as bigger potential).

If Atari had reasonable cash flow (ie from Lynx of computer sales) in 1993, they could and should have held of the Jaguar in all markets until mid 1994 at the very least (perhaps a summer release in Europe and fall in the US -not sure if Europe is as extreme about seasonal shopping as the US, but if so it's probably better for fallin both regions).

But really, Atari was already on its last legs before they launched the Jaguar (financially, management wise, and in reputation) and they were lucky to do as well as they did with the Jaguar considering that. (though in hindsight, by 1993 the Lynx was probably the best bet for any sort of sustained profitability -the Jaguar didn't last long enough or sell enough to overcome the R&D costs, but it did at least help them stabilize enough to win the Sega lawsuit settling for roughly 70 million dollars -30 million cash and 40 million in Sega stock)
1989-1991was the really critical time for Atari . . . if they had managed to introduce a really popular successor to the ST and/or a successful 4th gen home console, then they might have had a chance with the Jaguar. (better management probably would have helped the Lynx a lot too, especially in the US where sensationalist mass media marketing is so critical)

Ok, thats fair enough, but I, and no one I knew had actually heard about it until it was about to come out, so I guess as opposed to it being the announcement of the add-on, it was simply coming soon news/release date anouncements that originally must have alerted most people to its presence.
You've just demonstrated one of Atari's lack of proper marketing. ;)

At first I thought you may have been overstating some of this, but yeah I just looked at the sales numbers and the system only sold like 100,000 - 250,000 worldwide O.O
Only 225,000 were manufactured, with 125k sold by December 31 1995 and 100k left in inventory (the remainder were sold just before the discontinuation in 1996 and in liquidation following that), so yes it sold in very low volumes. (which is why prices are so sensitive to demand today)

Those low volumes almost certainly limited price drops from economies of scale (or lack thereof).

I think even if the Jaguar hadn't taken off in Britain to any huge extent, it still realistically could've managed over 100,000 by 1995 in Britain alone had it been released at the end of 1993 and been fully stocked.
Probably more than that if it had actually been ready for launch in 1993 rather than sporting a few unfinished/unpolished games (or glorified demo in McFur's case) at launch with a couple 16-iit console/computer ports trickling out towards the end of the year.

They really shouldn't have bothered releasing the system in Japan at all, better to relocate those units to Europe. I can see where they were coming from though, from the US perspective they probably thought they needed Japanese developers to jump on board and thought that releasing it there would help get local support, which was never going to happen.
Which is why I said to license it in a basically hands-off approach. (let some Japanese company handle all manufacturing and distribution on very favorable terms -ie for free other than perhaps reservations to favor localizations of JP tiles to the west with royalties from the western publications)
It would be attractive for Atari even under such conditioned due to the fact that they had no chance of getting into Japan otherwise, and could greatly benefit from the added international marketshare and JP software support.

Some of this makes you wonder if Atari even had the resources to release a console competitor in the US in the first place, they don't seem to have been able to manufacture anywhere near enough machines. Again they may have only realistically had the resources to launch and advertise in a smaller market like Europe, and then use the profit from there to build up for a US release.
They didn't just have limited production, but even more limited sales. As above, there were only 225k produced by the end of 1995, but only 125k had actually been sold.
Distribution was almost certainly an even bigger problem than manufacturing. They probably had the capacity (though IBM) to produce millions if they had the demand and distribution to back that up (and the funds to invest in such large orders -or willingness to risk makin such a large investment on credit).

Another problem is that by 1993 Atari fans had most likely moved on to Sega, Commodore, and Nintendo, I think much of their popularity had dissipated by 1993.
The ST had declined by that point, but remember the Lynx was very significant in much of Europe (selling into the millions), though well behind the game boy in all regions.

But yes, in general. 1993 was well after Atari should have been pushing a new console . . . they really needed something by 1989 and absolutely no later than 1991, preferably in both the console and computer markets. (a really competitive successor to the ST in '89 and/or a successor to the 7800)

The problem is, British companies during that time were just beginning to grow wise to the US market, so unlike previous machines I think that our companies were going to go where the money was regardless of local popularity, so they were always going to have problems getting support.
Also remember that distribution in Europe is FAR less costly than in the US, so even with lower priority, European sales would be significant. (that's another reason Atari had their best chance in Europe in general, they may have still been underfunded but not nearly as much as trying to push into the massive and diffuse/diverse US market)

Maybe it ran at 5fps :D

Seriously though, from what I've heard none of the commercial releases even remotely pushed the system, so its difficult to really judge what the Jaguar was capable of.
To manage a playable version of TR on the Jaguar, they probably would have taken the route Chilly Willy has with Yeti 3D (ie halve the horizontal and vertical resolution), except the Jaguar gains even more from this route as the object processor natively supports a wide range of resolutions as well as the ability to composite frambuffers and objects of different resolutions. (like having a full-res status overlay on a low res game window -thought it would probably be more efficient bandiwidth wise to put status icons and text in a boarder region instead)
The 32x could use MD sprites/BG to have full-res overlays similarly, but the main problem is the fixed 320 wide 32x resolution (a 160 wide mode would have been very useful). As it is, you might get away with a pseudo 16bpp 160 pixel mode treating pairs of 256 color pixels as single 16-bit pixels of simple dithered pairs (which Doom may do given the apparent "strippy dithering" look in RGB/emulation), ideally you'd optimize the 256 color palette for pixel pairs that blend almost seamlessly in composite video. (and preferably still look decent in RGB)

Given the relative complaints about screen size and framerate over low spacial resolution, it probably wouldn't have been a bad idea for a lot of 3D Jag games to take that route. (doom did it horizontally and would have been about 1/2 the framerate had they not done that; AvP definitely should have at least taken Doom's route -ray casting games work on vertical columns. so cutting horizontal res also gains a lot more than vertical)

I would love to see anything like that realized from the homebrew scene. Like I said, I don't think Tomb Raider would be impossible for the Jaguar. I just think it would be a ground up rewrite which would only be justified by the Jaguar being a dominant platform.
A ground up rewrite probably wouldn't be necessary . . . the biggest thing that would force that is RAM (to cut the game engine down to comply with that) and the Jag has enough that most 5th gen game engines should have been able to be hacked down to fit in the Jaguar's RAM. (something far more limited on the 32x, or even 32xCD)

With that issue aside, theere's still the performance issue, but (as I addressed above with TheNewGuy), cutting resolution could have addressed that big-time (and probably should have been used for many of the existing games).
IIRC, DOS Tomb Raider is actually playable on a fast 386 class system when detail is at low and screen size is close to the smallest setting. (except the Jaguar would be able to display that small screen stretched to a reasonable size and render in CRY with smoother shading than the PSX, let alone VGA)
Albeit, that 386 system would still have more RAM than the Jaguar, so texture res and/or texture count would need to be sacrificed. (lower res textures should also speed up rendering to some extent)

The Jaguar should have launched in the UK and Europe first, where Atari was still popular thanks to the ST and Lynx and didn't have a tarnished name like it did in the US where many still associated them with the crash. Had Atari got success here and got British software companies on board (much like the Sega Master System) then they could have launched elsewhere with a much better line up of games and probably at a lower price point to capture the budget market.
I doubt the crash had much to do with anything (many people didn't -and don't- even know what it is/was and retailers had gotten over that in the 2600 Jr and 7800 days) , the main problem was that Atari basically had no real mass market presence in the US since the late 80s (and even then they'd only been lukewarm with the Jr, 7800, and ST -and A8 to a minor extent).
Lack of any 4th gen home console was almost certainly a big part of that. (along with general management problems -which also crippled the ST and Lynx)

Not sure where you got that information about Germany as I was always led to believe that Germany was actually THE strongest market for the ST and it did incredibly well there. I certainly remember a lot of German developed software coming out for the ST.
That was my impression too, though I've never seen actual sales figures backing it up (or comprehensive ST sales figures in general). I wonder how much info Curt and Marty have on that.

From the descriptions I've seen, it may have been that the ST was popular early on in Germany (especially in the professional/business market), but fell behind sooner than other regions.

With regards to the part about British companies and software, I am not sure if you realise but Tomb Raider was originally a Jag exclusive but because the Jag didn't take off Core jumped ship to Sega and Sony and the Jag version was never even released. Had the Jag done better here I am sure Core design would have stuck with it.
That seems a bit odd, especially since CORE had had such a close working relationship with Sega prior to that (boarderline 2nd party at times). It's plausible that Core was developing a Jaguar version of Tomb Raider (possibly even the first version to start development), but extremely unlikely that it would have been planned as an exclusive.

Thenewguy

08-22-2011, 08:03 PM

No (rather like the PCE) they'd planned the CD before the test market (probably not back in 89-91 when the primary design work was done, but well before release). From all I've seen, the main reason to stay away from CDs was the cost of the drive/chipset/royalties (and/or licensing) for their $150 target price point. (as it was, they were still unable to meet the desired price until 1995 in spite of an extremely tight and cost effective design).
So essentially they intended to sell it as half a system, then screw over their userbase by forcing them to buy the other half at a later date, that wouldn't have been seen in a very positive light around here.

That's where marketing comes in . . . thoughts like that would obviously be fostered in a lack of proper marketing for the CD in general.
Sega had tons of marketing, 3rd party support, a core system userbase over 40 times the size of the Jaguar and their CD add-on still fell on its ass, I don't see how this is even debatable to be honest.

It did ZERO damage to users who didn't own it.
Lots of people bought N64s anticipating Donkey Kong sequels, people who didn't want to shell out on expansion packs were subsequently blocked out from being able to play Donkey Kong 64, therefore it did minor damage to some owners by limiting which games they could play.

I didn't get Perfect Dark until a year late wholly due to the fact that the single player required the expansion pack, I had to search and wait around that long to find a cheap one.

ie the alternative to having add-on specific game would be not having those games on the system at allYou'd simply have something else instead, or a slightly graphically worse game, DK64 wasn't even as good as Banjo Kazooie in the end anyway, and Conker had better graphics to boot.

If it was really popular (with associated big budget marketing) it wouldn't have been relegated to the budget end at all, and it wouldn't have been perceived as weak either. (lots of high quality software from prominent developers would show that ;))That would depend on how big a gulf in quality there would've been between the Jaguar and the PS1, if PS1 games were always going to be notably better (and PS1s were hardly expensive themselves after a while) then Jaguar's userbase was going to be limited unless they could monopolise 3rd party support, which seems unlikely.

No way that could be done and still have a reasonable console for the 5th gen without needing significant add-ons down the line (or a short life in general) as any major cuts would necessarily have involved cutting back on RAM substantially, something that would largely compromise the system's ability to support multiplatform releases from anything but older computer/console games. (ie any newer PC games, or any 3DO/PSX/Saturn/etc stuff)Are you sure? The bundled cartridge must've cost a good bit as it was so there's saving there, and the system sold for $250 at launch so there's another $50 to spend from that, if the 1X CD drive really was ~$100 then surely they could've got it out for $330 at most? maybe settling for ~$350 was still worth a try I guess.

There would also be possible deals that could be made with companies such as Phillips?

Not Neo Geo, but we're still talking $70-100 per new game rather than $30-50 (or less for actual budget titles).N64 games cost $70-$100 in the US?! jeez.

No they released it on hucard simply because it was the only option for a decent port. The arcade card didn't exist
Ah, Ok, I didn't take into account the timing

As it was, they probably shouldn't have launched until fall 1994 in any case
Suicide, Atari had a grand total of one advantage against their competitors, the 1993 release date, that was the only thing the Jaguar ever realistically had going for it, release at the end of 1994 worldwide and they would've done even worse.

The ST had declined by that point, but remember the Lynx was very significant in much of Europe (selling into the millions).Really? where was it popular?

That was my impression too, though I've never seen actual sales figures backing it up (or comprehensive ST sales figures in general).Well judging by magazine figures, what people have told me, and the state of German Atari ST support I'd find it unlikely to be honest, I can't remember if there was much German info for Atari ST posted in the "European Market (with real pieces of History inside)" thread, I know I posted some Atari ST sales figures for Britain there, so it might be worth re-reading the thread.

saturndual32

08-22-2011, 11:03 PM

Suicide, Atari had a grand total of one advantage against their competitors, the 1993 release date, that was the only thing the Jaguar ever realistically had going for it, release at the end of 1994 worldwide and they would've done even worse.

I dont know, had they waited a year, they would still have a one year lead in the USA on the Satun and Playstation, they could have fixed the bugs and bottlenecks the system had, and improved the texture mapping capabilities (i think i read it wasnt that hard), replace carts with a cd drive, maybe a bit more ram, maybe a 32 bit cpu instead of the 16bit motorola...most games would recieve a performance boost just by elimintating the bugs and bottlenecks, and most importantly at the late 1994 launch they would have even better versions of Doom, Iron Soldier, Aliens VS Predator, Battlepmorph instead of Cybermorph, Wolfenstein 3d, Tempest 2000, a Crescent Galaxy that plays as good as Thunderforce 4 (yeah right, haha), a better Club Drive and Checkered Flag, so till crap in those cases, haha. It would be a nice launch lineup.
I dont know, i am just daydreaming, haha.

Thenewguy

08-23-2011, 12:25 PM

I dont know, had they waited a year, they would still have a one year lead in the USA on the Satun and Playstation, they could have fixed the bugs and bottlenecks the system had, and improved the texture mapping capabilities
But nobody would've supported them, Saturn and PS1 tech figures were already known by journalists and the public by mid 1994, and both Saturn and PS1 were released in Japan at the end of that year (about when we're talking about releasing Jag), software development was starting up for those machines, Sony was actively courting 3rd parties, sending out dev kits, going on about how much money they were going to spend, developers would've known how much easier it was to make PS1 games.

Seriously, none of the major 3rd parties could ever have been so incredibly stupid as to look at the three machines and decide to support the Jaguar instead of learning and gearing up for the western PS1 and Saturn releases, the magazines (who were actively playing import machines) would've given the Jaguar even less support and exposure than they did (at least as it was Jag got some positive coverage in 1993)

Sega had been strong in the previous generation, were known to have great marketing skills (at the time lol), and provided high quality 1st party exclusive titles some of which had previously been in high demand

Sony had a high reputation in consumer electronics, masses of money behind them for marketing, making deals, and hiring the best people, and on paper in 1994 their system seemed like the best for what was required

Nintendo had a long history of making the most popular game systems, had powerful brand name in the US, and had loads of their own powerful IPs etc

Atari on the other hand had clearly no money for marketing or investment, unless they'd made substantial changes to the design they had the technologically worst system on the market (except 3DO, which quite possible would've been worse had Atari ironed out Jaguer's bugs etc), their brand name was extremely weak, and they had next to no exclusive IPs that anyone in 1994 actually cared about anymore (maybe Gauntlet I guess).

in 1993 Atari had the advantage of being the only viable next gen system on the market (3DO was too expensive), 2D gaming was also still the most popular type of game in that period so they could've sold tons of 2D games during 1994 whilst building up funds and releasing gouraud shaded 3D games (which would've still been impressive until maybe around mid 1995), and they would've had nearly 2 years to entrench themselves and build up a healthy userbase before the releases of the "bookies choice" machines.

I think the only people who would be helped by Atari releasing at the end of 1994 would've been 3DO, as it would've been the only machine for impatient people wanting to upgrade for christmas 1993. By the end of 1994 when the 3DO started to have price drops (it was $399 at christmas 1994) it also had a decently built up game library starting to form, Need For Speed, Road Rash, Madden 93', Star Control II, and Alone in the Dark were out, Super Street Fighter 2 Turbo, and Samurai Shodown were there, Gex, Guardian War and The Horde were pretty respectable, and there were a bunch of still popular 16-bit ports to make up the numbers and show support (Theme Park, Out of this World, Flashback, Lemmings, Incredible Machine).

kool kitty89

08-23-2011, 08:15 PM

Sega had tons of marketing, 3rd party support, a core system userbase over 40 times the size of the Jaguar and their CD add-on still fell on its ass, I don't see how this is even debatable to be honest.
By marketing, I didn't just mean quantity advertising, but the right sort of advertising and promotions alongside the right management on the business and software ends as well. (and doing so in multiple regions)
The Sega CD has tons of flaws in all of those areas, especially in Japan and Europe, but the US only looks good by comparison of those poor examples.

This is a separate topic (and one I've already argued in detail -though a dedicated thread wouldn't be a bad idea), but in the Sega CD's case alone there were these problems:
-Lack of reasonable software support from Japan.
-Problematic marketing model in the US (pushing FMV to the extent of missing promotion and R&D investment in broader genres from 2D/arcade to 3D/pseudo 3D -as well as alternate uses of multimedia than pure FMV)
-Lack of a low cost optimized duo unit (NEC had the Turbo Duo at $300 when the CD launched in the US, Sega should have managed that by the time of the model 2 in -1993 at least -possibly down to $200 by late 1994)
-Lack of ports/compilations of all major 1st party MD games at significantly lower prices and/or with significant enhancement over the cart versions (to add incentive to all owners and potentially allow the system to pay for itself -with corresponding promotions)
-lack of combo cart+CD games (especially games that could work via cart alone, but get enhancements via CD)
-lack of Demo discs
-Poor choice of pack-in(s)

And that's not addressing alternate hardware design choices that may have been more marketable. (most significant would probably be a simpler/cheaper/earlier CD unit that would have a real chance of cutting in on NEC's market in Japan while being more viable in the west simply due to lower pricing and earlier release -large back library, though marketing and managing it correctly could still be major issues)

Lots of people bought N64s anticipating Donkey Kong sequels, people who didn't want to shell out on expansion packs were subsequently blocked out from being able to play Donkey Kong 64, therefore it did minor damage to some owners by limiting which games they could play.

I didn't get Perfect Dark until a year late wholly due to the fact that the single player required the expansion pack, I had to search and wait around that long to find a cheap one.

You'd simply have something else instead, or a slightly graphically worse game, DK64 wasn't even as good as Banjo Kazooie in the end anyway, and Conker had better graphics to boot.
If managed tactfully, you'd avoid such conflict . . . any games reasonably possible on the unexapanded system could be released as such with support for enhancement via the add-on (namely for higher screen and texture resolution -the latter could be facilitated by exploiting ROM streaming of uncompressed/moderately compressed data at the expensive of much greater ROM space and thus a more expensive game -a major point of using the add-on in general).

That would depend on how big a gulf in quality there would've been between the Jaguar and the PS1, if PS1 games were always going to be notably better (and PS1s were hardly expensive themselves after a while) then Jaguar's userbase was going to be limited unless they could monopolise 3rd party support, which seems unlikely.
Yes, Sony was a perfect storm that they definitely couldn't have gone against in the long run (at least in the state they were in 1993, maybe if they'd actually been well managed from 1989 onward and had successful products, a reputable name internationally, and brand loyalty). It's the same reason Nintendo and Sega's screw-ups came at the worst possible time. (albeit Sony's very presence induced some of those mistakes -for Sega, NEC, and 3DO at least, probably not Nintendo since that was mostly pure stubbornness)

Are you sure? The bundled cartridge must've cost a good bit as it was so there's saving there, and the system sold for $250 at launch so there's another $50 to spend from that, if the 1X CD drive really was ~$100 then surely they could've got it out for $330 at most? maybe settling for ~$350 was still worth a try I guess.
The manufacturing cost of a 1 or 2 MB cart alone in 1993/94 wouldn't have been very much at all (price at retail as a separate game is another matter), but it would have been something at least.
OTOH they could have opted for demo discs rather than any full pack-in game, making lower margins on hardware more realistic even under Atari's problems.

There would also be possible deals that could be made with companies such as Phillips?
I believe Phillips was still tied to Nintendo at that point (SNES CD not canceled until early 1994), so if not legally obligated, at least a conflict of interests. (if they HAD managed to partner with Phillips, they may have wanted Atari to make the Jaguar CD-i media compatible -which the SNES CD apparently was to support as well)

N64 games cost $70-$100 in the US?! jeez.
It would be nice to have a comprehensive list, but the higher profile games were mostly $70 and up at launch prices (not positive any reached $100, but given several Genesis and SNES games did that, it wouldn't be out of the question).
My family bought very few new N64 games back then (almost all used from FuncoLand), and almost none right after release (I think Pokemon Stadium may have been the only 1), but I don't remember what we paid for any of those then. (I remember more of the used prices, though that was all from the early 2000s, so also not representative for the late 90s)

Suicide, Atari had a grand total of one advantage against their competitors, the 1993 release date, that was the only thing the Jaguar ever realistically had going for it, release at the end of 1994 worldwide and they would've done even worse.
But they didn't launch in 1993, they had a very limited test market only in 2 US cities and sold very limited numbers (I highly doubt they even had the announced 50,000 units available for that test). The actual national US rollout wasn't until mid 1994 (I've never seen an exact date, but it seems to have been by late spring) and it really wasn't until fall of 1994 that it had a decent launch library.

As it was, Atari had very limited 3rd party support, almost every single game was Atari commissioned and published, and many of the games released in 1994 had already been in development more than a year earlier. (prototype dev units went out by early 1992 with the final dev units available late that year)
With the system's architecture and the tools available, there was generally a steep learning curve leading to protracted development times and less than polished games released well behind schedule.

If Atari had been smart (and had the necessary funding) they could have kept the hardware design fluid for another few months to address some of the biggest bugs while developers could already be working with the preproduction units. But with or without hardware fixes, they definitely should have invested in building better development tools and researching for good workarounds for any bugs (the steep learning curve came from the primitive documentation requiring developers to learn a lot by themselves -including a lot of trial and error).
In hindsight, id probably would have been ideal for contracting a better tool set. (since Carmak actually ended up building his own tools for the system, including an actually functional GPU compiler -vs the horrible one Atari had)
That's also something Atari could have fixed after the test market or release of the system, but they didn't.

Atari releasing the Jaguar in 1993 with the pittance of software and test-market nature of the release was an act of pure despiration that could have even turned off certain developers/investors that examined the situation carefully. (compared to a definitive, well funded, well advertised national launch with a decent software lineup)

Having the hardware and software ready in 1993 obviously would have been better, but an actual launch in 1994 with a decent software lineup would have made for a much better impression for the media, consumers, and 3rd parties. (Atari simply didn't have the resources to tide them over until then though)

Really? where was it popular?
The figures I've seen have it outselling the Game Gear by a substantial margin, but being well behind the GB. It seems to have been strongest in the UK. (possibly somewhat like how the 7800 did in the US, except with a lot more software support)

Atari on the other hand had clearly no money for marketing or investment, unless they'd made substantial changes to the design they had the technologically worst system on the market (except 3DO, which quite possible would've been worse had Atari ironed out Jaguer's bugs etc), their brand name was extremely weak, and they had next to no exclusive IPs that anyone in 1994 actually cared about anymore (maybe Gauntlet I guess).

in 1993 Atari had the advantage of being the only viable next gen system on the market (3DO was too expensive), 2D gaming was also still the most popular type of game in that period so they could've sold tons of 2D games during 1994 whilst building up funds and releasing gouraud shaded 3D games (which would've still been impressive until maybe around mid 1995), and they would've had nearly 2 years to entrench themselves and build up a healthy userbase before the releases of the "bookies choice" machines.
Exactly, Atari was basically screwed one way or another (aside form a possible niche market for olschool arcade style games and a few other aspects -retro arcade remakes was one of the promoted features of the system that Atari failed to deliver on any reasonable scale, let alone lack of newer arcade ports -from Atari Games even, who many didn't understand was a separate company, among other things).

They were all but past saving by the time the Jaguar was released, and during the Jaguar's life, performance reviews of the company suggested that Atari Corp would be best off dropping to 3rd party publisher status. (something Sam Tramiel was apparently unwilling to do) Albeit, in that respect, they probably could have managed to keep the Lynx going alongside shifting to publisher status on consoles/computers. (except the problem there was that Atari Corp had never been a major software developer and only a moderate publisher at best -as far as outsourcing and managing licenses and releases, they had been hardware first and foremost from day 1 in 1984 -Atari Games got a lot of the software talent with the rest leaving for greener pastures)

Their real chance on the market (games or computers) had passed back at the beginning of the 90s when the ST's market was falling apart (with lack of a competitive successor), with a lack of a 4th gen console at all, and a general decline in business/marketing management stemming from around the time Jack Tramiel retired. (which Mike Katz quickly followed in early 1989)

I dont know, had they waited a year, they would still have a one year lead in the USA on the Satun and Playstation, they could have fixed the bugs and bottlenecks the system had, and improved the texture mapping capabilities (i think i read it wasnt that hard), replace carts with a cd drive, maybe a bit more ram, maybe a 32 bit cpu instead of the 16bit motorola...most games would recieve a performance boost just by elimintating the bugs and bottlenecks
If they held off on solidifying the design for another few months (say freeze it in fall of 1993 rather than late 1992) they may have been able to solve the major GPU/MMU bug and maybe tweaked a few other things, but nothing massive. (probably not enough time to address JERRY's main bus access issues, maybe fix the UART, maybe address the blitter bugs, and maybe add a bit more for texture mapping but that would be a bigger change -best case for such a last minute change would probably be a 64-bit destination buffer; as it is, there are some nice texture mapping routines that buffer to GPU SRAM to speed things upconsiderably -getting close to Saturn speed under ideal conditions, though probably less than 1/2 that in real-world cases)

Added RAM would be a no-go since DRAM prices were nearly static from 1992-1996, so the system would be far too costly. However, if the system's clock speed could be tweaked a bit further in that added year before production, faster RAM could have been used at fairly reasonable cost. (given the Jaguar II was only targeting 33 MHz in 1995 for a 1996 release, a huge speed boost would be unlikely, but maybe something like 28 Mhz or so)
Another possibility would be adding only a small amount more RAM (like 128k or 512k atonly 16-bits wide) in the 2nd DRAM bank to allow interleaved accessing (speeding up some blitter operations and potentially reducing hits to bandwidth from 68k and DSP accesses in main).

A replacement for the 68k would be fairly simple due to the flexible aspect of the design in that area (almost any CPU could be used -they aimed at x86 and 68k, but most RISC chips will work too since they use interfacing similar to one or both of those). However, cost would again be a problem and pretty much any RISC CPU (even the low-cost ones) would likely be outside of Atari's target price range (except maybe an SH1 or one of the cheaper ARM variants), a 68EC020 would be a nice help but still a significant cost increase, 386SX wouldn't be much better than a 68k and would likely cost more (a 26 MHz SX would be a more significant boost though), a 386DX or low-end Cyrix SLC/DLC chips would be nicer but probably still too expensive. (going RISC would also compromise a major point of having the 68k: being easy to source ports to from games in 68k assembly, though a 386 derivative would facilitate PC ports written in assembly and PC games were becoming pretty significant by 1992/1993)

If Atari was better funded, they could have afforded to invest in more costly hardware (including CD drive) with prices kept down by reducing profit margins, but they simply couldn't do that. (technically the Tramiels could have invested from their private savings at a time when major 3rd party investors wouldn't touch Atari, but that was a huge risc -for the very reason other investors wouldn't go near them, and it was almost certainly a smart move in hindsight ;))

most importantly at the late 1994 launch they would have even better versions of Doom, Iron Soldier, Aliens VS Predator, Battlepmorph instead of Cybermorph, Wolfenstein 3d, Tempest 2000, a Crescent Galaxy that plays as good as Thunderforce 4 (yeah right, haha), a better Club Drive and Checkered Flag, so till crap in those cases, haha. It would be a nice launch lineup.
More likely better versions of the 1993 and early 1994 releases and moderately improved mid 1994 releases. (not much more development time, but possible benefits from bug fixes and better tools)

saturndual32

08-24-2011, 01:39 AM

Some Jaguar games use a ton of little pixels to create some prety cool special effects like Tempest 2000. I noticed that the Saturn port of T2000 has those effects downgraded and in the PS1 game Tempest X they are replaced by lightning and transparency effects which in my opinion are not as cool as said Jaguar effects. So is there anything that makes the Jaguar better at those type of pixel effects than the PS1 and Saturn?
Here is a good example of what i am talking about:
http://www.youtube.com/watch?v=_eayMWYO-7c
Is stuff like that impressive for this generation, or can the other systems easly do it just as well?

Thenewguy

08-24-2011, 09:33 AM

By marketing, I didn't just mean quantity advertising, but the right sort of advertising and promotions alongside the right management on the business and software ends as well. (and doing so in multiple regions)

The Sega CD has tons of flaws in all of those areas, especially in Japan and Europe, but the US only looks good by comparison of those poor examples.
No, I don't agree with that, the marketing for the Sega-CD was decent at the very worst, everybody knew what the Sega-CD was at the time, magazines gave positive coverage, letters written into magazines of the day by readers were also positive for the first year it was on the market, opinion of Sega-CD was something which started out high, but soured due to limited software releases that made it worth owning.

People liked the idea of the Sega CD during its first year, but most mainstreamers still had no intention of paying out the money for it so support was low.

but in the Sega CD's case alone there were these problems:

-Lack of reasonable software support from Japan.
Jaguar was always going to get even less Japanese support

-Problematic marketing model in the US (pushing FMV to the extent of missing promotion and R&D investment in broader genres from 2D/arcade to 3D/pseudo 3D -as well as alternate uses of multimedia than pure FMV)
Atari had nowhere near the money for marketing or investment that Sega did, Jag CD was never going to get a much exposure or coverage as Sega-CD did, Jag-CD was also coming in the wake of two major add-on failures

-Lack of ports/compilations of all major 1st party MD games at significantly lower prices and/or with significant enhancement over the cart versions (to add incentive to all owners and potentially allow the system to pay for itself -with corresponding promotions)
Atari couldn't have done this anyway as they had no recent back catalogue of hits, Atari's hits were crusty games by this stage, and retro gaming was in its infancy, re-releases of their early-mid 80s games would've been seen as nothing but shovelware.

It all areas the Jaguar CD was in a worse position than the Sega CD, they could've spent all the money they'd owned and they still would not have gotten as much early coverage and marketing as the Sega CD had, the Sega CD was an add-on for a system which had a worldwide userbase of like 5 million odd when it was released! Unlike Jaguar the Mega Drive had really high 3rd party support, but still hardly any of the 3rd parties swapped over to support the Sega CD, Sega CD timing was virtually perfect for the west as well, allowing it to ride a wave of "CD is the future" hype.

The two biggest things Sega CD needed was

1# Sega supporting it with must have software which used the system's capabilities, stuff that put it into more homes, and facilitated more 3rd party support.

this is not a factor with Atari, because Atari's in house game developers, quite frankly were not as talented as Sega's anyway, for the most part they were not up to the task to make must-have 1st party titles, they were reliant on 3rd parties making them for them.

2# The Mega-CD unit to be much cheaper, people don't like paying out huge hidden extra costs, so at the price the Sega-CD was being sold for it was going to have fairly low percentage uptake.

This was not feasible for either add-ons as CD units cost too much money to manufacture in the early to mid 90s, if anything Sega had volumes so they would've been better off than Atari in yet another area.

But they didn't launch in 1993, they had a very limited test market only in 2 US cities and sold very limited numbers (I highly doubt they even had the announced 50,000 units available for that test). The actual national US rollout wasn't until mid 1994 (I've never seen an exact date, but it seems to have been by late spring) and it really wasn't until fall of 1994 that it had a decent launch library.
That might be enough for Britain and France if they had prioritised those areas, the Master System launched with ~30,000 units in the UK, and (according to one source I've seen) sold ~34,000 in France in 1987.

Releasing later in the fall 1994 could've been do-able in the US if they'd had built up software support already in Europe.

As it was, Atari had very limited 3rd party support, almost every single game was Atari commissioned and published, and many of the games released in 1994 had already been in development more than a year earlier. (prototype dev units went out by early 1992 with the final dev units available late that year)

With the system's architecture and the tools available, there was generally a steep learning curve leading to protracted development times and less than polished games released well behind schedule.

Atari releasing the Jaguar in 1993 with the pittance of software and test-market nature of the release was an act of pure despiration that could have even turned off certain developers/investors that examined the situation carefully. (compared to a definitive, well funded, well advertised national launch with a decent software lineup)

But they had the 68,000, which would've played a crucial part early on. Personally I think its feasible that had Jaguar used a CD drive from the beginning, they could've gotten support from some of the big companies.

Think about it, prior to release they could've gone up to companies like Virgin Interactive and said

"look, we've got a 68,000 in the system so you can port your Mega Drive titles without too much effort, and we're on CD so there's also no risk, and on top of that there's the possibility for much higher profits"

That seems like a pretty sensible deal to me, companies could've dumped improved CD audio on their games, and hopefully some of them would've added some extra graphical improvements on top of the ports to make them the best versions, games like Aladdin with CD audio and slightly better graphics ready at release/just after release would've still been viable late 1993, to mid 1994 in my opinion.

If they'd got Acclaim on board with a similar proposition, and managed to get the best console version of MK1, and later 2 that would've been a huge help.

On top of those they would've had the games which had been released anyway, in 1994 that would be Wolfenstein, Doom, Iron Soldier, Alien Vs Predator, and the money from royaties of the improved 16-bit ports could've been invested into more impressive projects.

The important thing with Jaguar would simply be to create the illusion early on that it had support from the biggest companies, building up funds for investment into impressive games and proper tools for 3rd parties.

Having the hardware and software ready in 1993 obviously would have been better, but an actual launch in 1994 with a decent software lineup would have made for a much better impression for the media, consumers, and 3rd parties. (Atari simply didn't have the resources to tide them over until then though)
It wouldn't have been much of an impression on the media, being that they were already covering the Japanese releases of Virtua Fighter and Ridge Racer on PS1 and Saturn by the end of 1994, and many journalists even had their own import systems and had spent large amount of time playing the games.

The figures I've seen have it outselling the Game Gear by a substantial margin, but being well behind the GB. It seems to have been strongest in the UK.
Well, being that the Lynx is very rare in the UK that doesn't bode particularly well :D

kool kitty89

08-26-2011, 05:48 PM

No, I don't agree with that, the marketing for the Sega-CD was decent at the very worst, everybody knew what the Sega-CD was at the time, magazines gave positive coverage, letters written into magazines of the day by readers were also positive for the first year it was on the market, opinion of Sega-CD was something which started out high, but soured due to limited software releases that made it worth owning.

People liked the idea of the Sega CD during its first year, but most mainstreamers still had no intention of paying out the money for it so support was low.

Jaguar was always going to get even less Japanese support

Atari had nowhere near the money for marketing or investment that Sega did, Jag CD was never going to get a much exposure or coverage as Sega-CD did, Jag-CD was also coming in the wake of two major add-on failures

Atari couldn't have done this anyway as they had no recent back catalogue of hits, Atari's hits were crusty games by this stage, and retro gaming was in its infancy, re-releases of their early-mid 80s games would've been seen as nothing but shovelware.

It all areas the Jaguar CD was in a worse position than the Sega CD, they could've spent all the money they'd owned and they still would not have gotten as much early coverage and marketing as the Sega CD had, the Sega CD was an add-on for a system which had a worldwide userbase of like 5 million odd when it was released! Unlike Jaguar the Mega Drive had really high 3rd party support, but still hardly any of the 3rd parties swapped over to support the Sega CD, Sega CD timing was virtually perfect for the west as well, allowing it to ride a wave of "CD is the future" hype.

The two biggest things Sega CD needed was

1# Sega supporting it with must have software which used the system's capabilities, stuff that put it into more homes, and facilitated more 3rd party support.

this is not a factor with Atari, because Atari's in house game developers, quite frankly were not as talented as Sega's anyway, for the most part they were not up to the task to make must-have 1st party titles, they were reliant on 3rd parties making them for them.

2# The Mega-CD unit to be much cheaper, people don't like paying out huge hidden extra costs, so at the price the Sega-CD was being sold for it was going to have fairly low percentage uptake.

This was not feasible for either add-ons as CD units cost too much money to manufacture in the early to mid 90s, if anything Sega had volumes so they would've been better off than Atari in yet another area.
Again, the whole add-on (and Sega CD) topic really deserves a separate topic, but I also didn't intend to use my Sega CD arguments as evidence for the jag CD's potential success. (I was only addressing the Sega CD example)

But on the topic of add-ons in general (regardless of marketability), one important aspect that's often missed is releasing an efficently designed, competitively priced all-in-one system or even making that new system the defacto standard and discontinuing the older model (especially in the case of relatively cheap/simple add-ons -like RAM and/or embedded coprocessor). Had Nintendo released an udated 8 MB N64 (with expansion slot removed and 8 MB soldered to the board -especially a single 4Mx18-bit RDRAM chip), pricing it similarly to the original and phasing out the old models, it would have made for a much broader standard at the expense of some profit margins on late gen sales.
But this is, again, more of a topic to get back to in a separate add-on discussion thread.

I also didn't mean to imply that the Jag CD should have had a RAM expansion released along with it; if they were to add any RAM it should have been embedded in the CD add-on itself.

Back to the general topic of the Jaguar:
I do agree that the CD addon was not a realistic route for the Jaguar for various reasons and that (in general) the jaguar being CD based from the start would have given it a better chance at a long-term place on the mass market and a better chance to be monetarily profitable for Atari.

Use of CD-ROM was actually Crazyace's main argument in this Atariage thread http://www.atariage.com/forums/topic/119048-its-1993-youre-in-charge-of-the-jag-what-do-you-do/ opposed to Gorf's argument that bug fixes and a replacement for the 68000 were needed (namely a 68020 was suggested . . . or a less realistic suggestion for another GPU core). Gorf's argument mainly stemmed from the programming and raw performance standpoint, not overall marketing/management/developer/etc concerns, and those were all bigger issues than the programming end (especially since investment in better documentation and tools would have gone a long way with no hardware change).
Improving the hardware configuration AND using CD would be better all around, but have major trade-offs in production costs and/or release date.

There's also some considerations that I missed regarding the cost trade-offs of using cart vs CD:
While the pack-in game wouldn't have been enough to offset the costs significantly (especially for the short term when Atari was critically short of funding), there's ALL of the game production to consider. Even without taking the added profit margins for CDs into account, the sheer savings on production (and to lesser extent, distribution) of CDs over carts would have been substantial. (possibly enough to afford taking a significant loss on hardware sales)
Again, the most problematic time would be around the test market (before they got additional investor support -and even further before the Sega winnings), but even in 1993 they had 4 games on the market (all Atari published and mostly 2 MB/16Mbit), so perhaps enough to facilitate a $300 price point. (especially if demo discs were pack-in rather than full games -actually, use of Demo discs could facilitate unfinished games being pushed back further while still having demo versions out to promote the system's capabilities)

In terms of keeping manufacturing costs down for 1993, cutting back on RAM might have been a realistic option as well, but probably only if a later RAM expansion was marketable. (obviously much easier to market than a CD drive, and also practical to add as standard to later base units) One problem with that is that the Jaguar already has a quite convenient DRAM selection with 4 256kx16-bit (512kB density) DRAM chips forming the 2MB on the 64-bit main bus, and since DRAMs only went up to 16-bits wide, you'd need to use more chips of a lower density (ie 128kB) to allow 64-bit bus width. On top of that, 128kB chips cost about 30% more per byte than 512kB chips for much of the Jaguar's life. (though maybe if you used 4 128kB 16-bit wide chips as 512kB 64-bits and 1 512kB 16-bit wide chip accessible at 16-bits only, it would be a decent balance of cost and board space, especially if that 16-bit chip were mapped to the 2nd DRAM bank -which allows interleaved FPM access, improving efficiency of bus sharing for some things)
So overall, it would probably be best to retain the current 2MB if possible, but support for further RAM expansion could still be significant. (plus you could limit expansion to 16-bit wide RAM -save on connector pins, board space, and DRAM chips- mapped to the 2nd bank -with interleaving- and still have a full 2MB accessible at 64-bits -where the aformentioned 512k+512k 64/16-bit bank suggestion would either require cumbersome expansion for 64-bits width or limit the 64-bit bank to the internal 512k)

I also have to retract some of my arguments for a 1993 release being impractical software support wise as there should have been some ways around that. One major possibility would be giving special deals to 3rd party publishers who hard games ready for release by launch/test release (or slightly later, perhaps by early December). Offering developers royalty-free publishing for all games released in that period would give some major incentive. (and also incentive to at least manage decent quality as those titles could be royalty free for the entire life of the Jag, so prolonged sales would be extremely attractive)
Maybe even give long-term advantages to such early sign-ons (like reduced royalties on later releases).
They should have made such an offer when introducing the finalized development systems in late 1992. (they'd still have to charge for development tools, but those costs shouldn't have been unreasonable)

Albeit, as it was, they probably wouldn't have been worse off making the Jag an open platform with zero licensing royalties to any 3rd party publisher for the entire life of the system (given how limited 3rd party support was). The same could be said for the 7800. (but more so since it had even less 3rd party support, but substantially greater hardware sales)

That might be enough for Britain and France if they had prioritised those areas, the Master System launched with ~30,000 units in the UK, and (according to one source I've seen) sold ~34,000 in France in 1987.
Yes, but, again, I'd question whether they actually had 50k units available in 1993. (but that would only make a European release more favorable compared to the US test market)

Releasing later in the fall 1994 could've been do-able in the US if they'd had built up software support already in Europe.
The question would still be whether they'd be able to get the additional funding they desperately needed had they gone the Euope first route. In that respect, it is possible that favorable sales, reception, and software support (especially if they offered extremely attractive contracts for early 3rd party releases) would have made for better PR and investor interest than the US release had.
Furthermore, a European release would have been far less costly to advertise and support than a US one (probably even compared to the test market and -more so- related hype). Viral marketing in particular is far more effective in Europe.

But they had the 68,000, which would've played a crucial part early on. Personally I think its feasible that had Jaguar used a CD drive from the beginning, they could've gotten support from some of the big companies.

Think about it, prior to release they could've gone up to companies like Virgin Interactive and said

"look, we've got a 68,000 in the system so you can port your Mega Drive titles without too much effort, and we're on CD so there's also no risk, and on top of that there's the possibility for much higher profits"
More so if they gave such developers special deals for early software support. (as above)

Going x86 may have been significant too, but overall 68k was probably better. (lots of console games and Amiga games to work from, still reasonable to port many DOS games too, and PC games starting to shift towards high level languages as well -though a lot was still in assembly) The use of CD-ROM alone would make shareware-oriented PC publishers more likely to support the system. (though demos/shareware are just one among many advantages of using CDs)

That seems like a pretty sensible deal to me, companies could've dumped improved CD audio on their games, and hopefully some of them would've added some extra graphical improvements on top of the ports to make them the best versions, games like Aladdin with CD audio and slightly better graphics ready at release/just after release would've still been viable late 1993, to mid 1994 in my opinion.
On the note of CD-DA, Atari definitely should have avoided the digital mixing set-up used with the Jag CD and used simple analog mixing (or digital mixing external to the DSP) to merge CD-DA and onboard JERRY sound output. (the current jag CD set-up involves streaming red book audio data to the DSP via the cartridge bus and thus wasting a small -but notable- amount of bandwidth on the main bus)

If they'd got Acclaim on board with a similar proposition, and managed to get the best console version of MK1, and later 2 that would've been a huge help.
Or even just versions equal (or close to) Probe's CD-ROM based DOS ports of those games. (which were considered arcade perfect for the time) Though the Jag could obviously do better than VGA style 256 color graphics (and some powerful audio compression schemes) if they optimized a version for the Jag.
I believe Raiden was basically a port of the PC version -the Graphics look very similar, but different from other ports:
http://www.youtube.com/watch?v=A1YC0Bg6FVg
A1YC0Bg6FVg
(I much prefer the Remix done in the FM Towns version though, but the FM Towns version is also better than Arcade perfect -the Jag version at least improved the SFX over the PC port, unless the YT examples aren't configuring soundblaster properly)
Edit:
The jag and DOS versions were both developed by Imagitec Designs, so no wonder. ;)

And the FM Towns version isn't better than arcade perfect, there's some missing/changed SFX and possibly other minor changes. (PSX is more intact there, but the remixed soundtrack is also worse than the FM Towns version IMO)

On top of those they would've had the games which had been released anyway, in 1994 that would be Wolfenstein, Doom, Iron Soldier, Alien Vs Predator, and the money from royaties of the improved 16-bit ports could've been invested into more impressive projects.
Unless they went the route I suggested and bypassed royalties for some early releases to gain added developer support early-on. (though the point of that would be to boost early software support and consumer+developer+investor interest in general and reap profits from royalties of later 3rd party releases and 1st party software sales)

It wouldn't have been much of an impression on the media, being that they were already covering the Japanese releases of Virtua Fighter and Ridge Racer on PS1 and Saturn by the end of 1994, and many journalists even had their own import systems and had spent large amount of time playing the games.
They also should have taken advantage of the Sega license privileges they got from the settlement in 1994 (I forget if it included home console games, but it definitely included Sega Arcade games).

Well, being that the Lynx is very rare in the UK that doesn't bode particularly well :D
The Game Gear must be extremely rare then . . . unless it sold really well from 1994 onward.

Remember that the Lynx's market share would be in respect to 1990-1993 (when it was primarily active), after that most support was shifted to the jaguar.

Some Jaguar games use a ton of little pixels to create some prety cool special effects like Tempest 2000. I noticed that the Saturn port of T2000 has those effects downgraded and in the PS1 game Tempest X they are replaced by lightning and transparency effects which in my opinion are not as cool as said Jaguar effects. So is there anything that makes the Jaguar better at those type of pixel effects than the PS1 and Saturn?
Here is a good example of what i am talking about:
http://www.youtube.com/watch?v=_eayMWYO-7c
Is stuff like that impressive for this generation, or can the other systems easly do it just as well?
I've also seen claims about the superior pixel/particle effects possible on the jaguar, but I'm not sure how that aspect compares with the Saturn's VDP1, PSX GPU, or N64 RSP/RDP.

Thenewguy

08-27-2011, 05:15 PM

The Game Gear must be extremely rare then . . . unless it sold really well from 1994 onward.
I wouldn't say rare, more like fairly uncommon, I actually ran into some Game Gear games a couple of weeks ago in a local charity shop for an awesome price of £1 each :D

From what I've seen the height of Game Gear popularity was 1992, all three Sega machines had a very strong sales increase that year on the back of Sonic the Hedgehog hype.

kool kitty89

08-27-2011, 08:23 PM

I wouldn't say rare, more like fairly uncommon, I actually ran into some Game Gear games a couple of weeks ago in a local charity shop for an awesome price of £1 each :D

From what I've seen the height of Game Gear popularity was 1992, all three Sega machines had a very strong sales increase that year on the back of Sonic the Hedgehog hype.
Hmm, interesting, I'd gotten the impression that the Lynx significantly outsold the GG in the US (and a couple countries in mainland Europe too), at least during its active life. (and had significantly better PR)

Maybe it's a bit like the 7800 in the US, selling better than the SMS in quantity but seemingly being more scarce in the current market. (I've seen a good amount of SMS stuff "in the wild" but never any 7800 stuff) Except in that case, the SMS generally got better receptions from the media (largely due to the higher quality and quantity of games), which is apparently not the case with the Lynx vs GG in the UK.

In the US market at least (by revenue figures), the GG peaked in 1994 (steadily improving from 91-94) before steeply declining in 1995 while the Lynx peaked in 1991 and slipped slightly in 1993 before heavily declining in '94 (but it was only a small fraction of the GG for all of those years). On another note, the Sega CD (again in the US only) was almost evenly strong in sales in 1993 and 1994, with a modest dip in '94 (and given the pricing was lower in '94, overall sales may still have been up), but 1995 saw a massive plunge down to less than 1/7 of 1994 and less than 1/2 of even the 1992 sales. (though that's revenue, not sales, so sales could have been proportionally high at clearance prices)
Based on the figures here:
http://www.blackwellpublishing.com/grant/docs/11Videogames.pdf

I also got the impression (forget whether it was in a discussion on here or AtariAge) that UK/Euro gamers were somewhat put-off by the GG as it felt like Sega was being money grubbing, charging twice for the same games (SMS and GG) without direct forward/backwards compatibility. (that probably could have been avoided if the GG had been literally a handheld SMS hardware wise, either using card games, or new mini carts with a cheap adapter to play on a normal SMS or MD -the ability to easily play GG games on the MD with a passive adapter would perhaps have been even more significant, obviously more so for the US)

But this is another totally different topic. I think I actually started a handhelds thread a while back, or maybe that got lost when the forums were hacked.

Thenewguy

08-27-2011, 10:05 PM

kool kitty89

08-28-2011, 12:34 AM

Sorry, but I've been looking into Lynx UK sales, and honestly you're going to need to at least cite sources because not only have I not seen any supporting evidence for Lynx outselling Game Gear in the UK, and not only does this directly go against my own personal experiences, but I've actually run into multiple instances of evidence which contradicts the fact.

From what I've run into the end total was somewhere around

Game Gear - ~600,000
Lynx - 170,000-200,000

However, interestingly enough the lion's share of the Game Gear's sales seem to have happened from 1992 onwards, whilst most of the Lynx sales seem to have happened prior to 1992, the figures I've seen actually point to the Lynx outselling the Game Gear up until 92' (according to ACE magazine at the end of 1991 there were 150,000 Lynx owners in the UK, whilst according to Mega Magazine there were 130,000 Game Gear owners at that stage), during 1992 Game Gear sales take off and Lynx sales nosedive.

So, judging by what I've seen thus far in magazines the Lynx was more popular than the Game Gear, but only for the early part of the competition after which the Game Gear overtook it in popularity, I will, however continue to look.
That would make sense. Atari apparently pulled back on support (or outright canceled) all other products and projects in 1993 in attempt to move forward with the Jaguar.

As for sources, I'll have to look more since I can only seem to find comments/statements without specific figures listed (especially in various Atariage discussions). The best case would obviously be internal Atari records (a la 7800 -albeit that lacked European figures), but I don't know what Curt or Marty have on the Lynx.

Also, the claim of the Lynx doing better in Europe than the US could be a relative thing (market share or sales per capita, not raw sales numbers); in fact, that almost certainly is the case given the Lynx did modestly well in the US and the consumer base is so much larger than in Europe. (so not a case like the Master System)

hacksquad

09-09-2011, 02:56 PM

How about Atari jaguar II? hehe, not sure whether it is fake or something :P

http://www.atarimuseum.com/videogames/consoles/jaguar/jag2.html

kool kitty89

09-09-2011, 04:25 PM

How about Atari jaguar II? hehe, not sure whether it is fake or something :P

http://www.atarimuseum.com/videogames/consoles/jaguar/jag2.html
No, it's real and they were planning on having it completed in time for a late 1996 release iirc. (the existing prototypes are from 1995 and only have the "TOM II" or Oberon chip with the old JERRY -no JERRY-II/Puck- and 26.6 MHz clock speed rather than the planned 33 MHz -though it may have pushed beyond 33 MHz)

The prototype board on Curt Vendel's Atarimuseum page is real, but the specs linked to on that same page are highly inaccurate (one of the things needing a re-write on his website).
However, the full developers' manual of the Midsummer (Jag-II) chipset has been leaked, so there is a lot of information on what the real Jag II would have been like.

Crazyace and I were discussing the Jag II earlier in this thread.

Over the Jag I, it offers a higher clock speed, separate (slow) data bus for audio, many bug fixes to the existing architecture and a 3rd RISC core added to be used as the CPU (more or less) which featured a dynamic cache to greatly facilitate efficient bus sharing. The main feature was the TOM-II (Oberon) chip which added substantial enhancements over TOM in the Jaguar:
aside from bug fixes, it added high-speed texture mapping (quoted as being able to texture as fast as the Jag can gouraud shade), bilinear filtered texture mapping (not perspective correct, so more like what you see with PSX games on PS2 with "texture smoothing" enabled), a dedicated 8 kB texture cache (in addition to the 4k GPU scratchpad), hardware warped trapezoid rasterization (not a full triangle rasterizer, but a big help over manual line-by-line drawing), and double buffered blitter registers to facilitate pipelining of rendering.

It was still optimized as a low-cost design and continued to use a unified bus with the exception of the audio bus (I'm rather surprised that added that even), so bus contention would still be a problem (but shared far more efficiently). That shared bus (at 33 MHz) would have a peak bandwidth of 133 MB/s, that's the same as the PSX has for the CPU and video on separate buses, and even if they pushed it to 40 MHz it would only be 160 MB/s peak. Then again, many PSX games had plenty of GPU bandwidth to spare and got killed on CPU resource instead, so the difference could favor the jaguar more in some cases. (either close to even or even ahead of the PSX in specific cases -though that would also depend on efficient programming and/or the quality of development tools used)

The amount of RAM planned was also up in the air. The manual implied 2 MB of main and 1 MB for the slow bus, but it could have been a number of other things. (especially since RAM prices started dropping significantly in 1996) The memory map alone supports 8 MB of RAM (in 2 4MB banks) for main memory on the Jaguar, so having provisions for higher RAM capacity definitely wasn't an issue.

Though, in the end, good technical performance, ease of development, and even good cost effectiveness wouldn't really have mattered with the state Atari was already in in 1995, and (more so) with the sort of competition Sony was pushing. (and Sony's price cuts largely compromised the cost-effectiveness aspect too -and exacerbated other competition with more costly hardware, ie Sega)

Edit:
Curt's page does show a chip labeled "JERRY II" is actually on the prototype board. I'm not sure if that's really the planned "PUCK" chip, or just a revision of the old JERRY. (from what kskunk mentioned on Atariage, it would probably be a revision of the old JERRY since PUCK was supposed to have not made it to the prototype boards before the project was halted)

sheath

09-19-2011, 08:42 PM

Alright, I just landed Ultra Vortek new in box. So far the biggest things I can notice are that the scroll rate is below 20FPS for the backgrounds and the combos are limited in a Street Smart or Slaughter Sport kind of way. I would not be able to use this as a comparison between the Genesis, SNES or 32X versions of MKII simply because the scroll rate and jumping animation is so, well, jumpy. Ultra Vortek does seem to be a competent game in the sense that the games I mentioned above are, or Black Hole Assault for that matter, but I am not seeing anything that would make me use this as exemplary of what the Jaguar can do.

I am searching gamefaqs for more info and intend to keep the game if I can figure out why it has such a good reputation.

gamevet

09-20-2011, 12:37 AM

I've never heard of Ultra Vortek getting a good rep.

kool kitty89

09-20-2011, 02:03 AM

sheath

09-20-2011, 09:01 AM

kool kitty89

09-21-2011, 03:29 AM

It looks very high color and the animation isn't quite as smooth as MKII and MKIII but it is still pretty high, but the scrolling and jumping sprite movement is 20fps or lower. I thought I could maybe compare this to Cosmic Carnage and MKII 32X, and I may still, but Ultra Vortek's choppiness is going to really stand out in comparison.
If it looks jumpy, it's probably not running at a constant framerate . . . a moderate (or even low) framerate will tend to look smoother than one jumping from low to high rates inconsistently.

To be clear, you're talking about the speed of sprite positioning on-screen and BG scrolling, not animation, right? (and for the BGs, you mean jumping several pixels at once, not just scrolling very slowly -which will be inherently choppy if lower resolutions are used, that's noticeable in some SNES games; Earthworm Jim 2's far BGs come to mind)

kool kitty89

09-23-2011, 06:32 PM

Crazyace, if you're still watching this thread, I finally got around to looking back to the discussion that got left off here:

I think the bus latch might have helped the cpu in general, but wouldn't really improve the overall performance - as the blitter/dsp would still be the 'heavy hitters' of the system. Even with the bus latch though there aren't any mentions of other speeds for memory accesses apart from 2cycle/4cycle.
My comments on the CPU resource issue were mainly towards you mentioning "Star Fox at 6 FPS" and musing whether that was mainly due to CPU resource limitations or not. (otherwise it would be DSP+blitter limiations over the Super FX . . . or that performance quote was for a real-world case with audio running and such -contending for DSP resource, unlike Star Fox)

I still wonder how similar the SFX is to the Flare DSP, but I haven't found much info on that so far. (I haven't seen much documentation on the Super FX -and my understanding is a bit limited anyway, so it'd be tough to compare the 2 by myself . . . Sik mentioned knowing a bit about the SFX's architecture, but he hasn't looked much at the Slipstream's DSP iirc)

Sounds like a 'wide' slipstream - add a 65k colour mode to the display , then I'd guess a 12MHz memory clock with 32 bit memory ( With 4 bit pixels you get 12x8=96million pixels per sec )
The 4 hardware planes sound exactly like the 4 hardware planes in the slipstream - ( using the blitter comparator along with the 2 plane bits from the pixel )
I wonder when that design was completed/developed relative to the Jaguar . . . it seems simpler but the actual MSU unit wasn't produced until 1994 (after the Jag's test market), but maybe it was just a lower priority project on Flare's part. (compared to the Jaguar)

And what's that about multiple hardware planes supported on the Slipstream? I didn't notice that in the manual. (that wouldn't allow multi-plane scrolling independent of the blitter, right, still only the full-screen/line scroll on that end?)

Edit:
Ah, I see the section on the comparator now, that makes sense. (2-bit priority for blitter rendering -also explaining the main use for the palette segment registers, able to assign a different 64 colors to each plane -or 128 if 2 planes are used, 256 with 1)

Another disadvantage of not having pixel-accurate scrolling (aside from smoothness) is the inability to do some "tricks" that require single pixel offset scrolling, like motion blurred dithering. (use cherckerboard dithering -or column dithering- and offset every other scanline by 1 pixel each frame to blend the dithering more evenly -at the expensive of horizontal and temporal resolution, ie effective 1/2 res and 25/30 Hz framerate, but useful for certain games and also going beyond the limits of 12-bit RGB -and working in RGB, unlike composite artifact blending)
Hmm, actually, maybe you could use the plane bits to do a similar effect without scrolling. (flickering between 2 different planes, changing the priority at 50/60 Hz for 36 pseudo colors in 4bpp or 8256 pseudo colors in 8bpp -using 2 8 or 128 color planes . . . or you could use that same effect at full res -not trying to blend dithering- for just getting 16 or 256 pseudo colors outside of the 12-bit RGB range)

I assume it's the usual case of supply - If Nintendo had a supply of slower rom's available at a lower cost then it made sense to use them. The 3.58Mhz mode then became a futureproofing step. I guess the dram speed was the same.
I understand the use of slow ROMs, but slow RAM made less sense. (especially if that was the real limiting factor on the CPU clock rate -I rather doubt Ricoh had trouble managing 7 or even 10 MHz for the 65816 in '89/90) If they couldn't get a good FPM DRAM interface set-up to allow something in the 7-10 MHz range (probably 7.16 MHz given the 21.48 MHz master clock and common 120 ns DRAM), they could have switched to SRAM or used a mix of SRAM and a slower DRAM buffer. (the main reason to have slow DRAM at all would be for decompressing data into, something many SNES games ironically avoided in general due to CPU speed issues -and not wanting long load times- so from that respect it probably would still have been win-win even if only 32k of fast SRAM had been used in place of the 128k DRAM, let alone 64k SRAM or 32k SRAM plus 64k DRAM)

Line drawing and 3D calculation were supported, but not texture mapping in any way - the blitter only supported straight pixel copying
Yes, but wouldn't the DSP be useful in accelerating software scaling/rotation/texture mapping?

That's not the point I raised - ( I wasn't comparing ST with Master system for one thing ). I personally think scrolling is important, and not having it was a big problem, just as it was for the ST when compared to the amiga.

That becomes somewhat moot when you get into multi-layer scrolling though. Hardware scrolling ofthe bitmap plane (or lines therein) is rather limited for any games that don't just use one large BG and moderate sprite objects. (albeit that would be the case for most ST games obviously, but by the early 90s, that wasn't so much the case -even the TG16 had heavy use of large/numerous sprites that go well beyond that -ie you'd only get modest assistance from a single scroll plane, and spend a lot of time repairing where sprite objects "damaged" the BG famerbuffer)

Unless it was trying to scroll at 60Hz :) - and beating the SMS wouldn't have helped the Slipstream. It had to match or beat the Megadrive.
SMS had trouble scrolling at 60 Hz at times too (especially for diagonal stuff), though most of that was probably slowdown from CPU timeouts. (not sure about the diagonal issue)

As for needing to beat the MD hardware in raw performance, that's arguable. They'd need some sort of attraction/advantage for the system to be sure, but inherent technical superiority is rarely the definitive advantage needed to be successful on the market. You do need at least adequate hardware for the time that's reasonable for developers to work with, perhaps with some special features the competition doesn't have (especially if it's weaker in other areas), then you need good marketing and management relative to the regions the product is released in, brand recognition, 3rd party software interest, some degree of 1st party/licensed software, attractive price point, etc, etc. (having a bunch of money to throw at software licenses and advertising always helps, but for Atari or -especially- Konix, that wasn't going to happen on a large scale -at least not on the level of outstripping Sega or Nintendo -nevermind Sony, or without some nice 3rd party investors providing considerable capital-)

Albeit, you could argue whether the Slipstream even met the minimum for a reasonable 5th gen system on the hardware end, especially in the state it was in at the time. (with some tweaks to the architecture, it probably could have been OK, or just a more expensive configuration like a full 256k of PSRAM -but then you threaten the price point, better would probably have been support for 16-bit wide DRAM and ROM rather than only P/SRAM and 8-bit DRAM/ROM and use a mix of P/SRAM and DRAM, probably use a faster x86 chip -like a 12 MHz V30, 186, maybe even V33 or 286, maybe even a dedicated CPU bus as well -allow the CPU to access the main system bus with contention but also allow local CPU work RAM like Amiga fastRAM or such, but then there's added cost for that too)

It was 32bits wide - so likely 4 8kx8 chips, and I guess Atari were looking at the 7800 model where the console is a cheap as possible :)
The problem with that is compromising cost effectiveness of software. The lynx and jaguar both took a better philosophy there: use ROM mainly as mass storage with as much data compressed as practical (so slow cheap RAM, and efficient use of limited memory capacity) with enough RAM to facilitate decompressing/loading data+code into.

The contemporary consoles also allowed that to a fair extent: PCE mainly for VRAM (work RAM was too limited -and ROM was very fast, so all read-only code was there anyway), MD for work RAM and VRAM, SNES for work RAM and VRAM as well. (though, in spite of the SNES having the most potential for buffering data with its 128k DRAM, many games avoided compression due to concerns of CPU performance leading to unseemly load times -Sik brought this up in one of his compression threads).

On top of that, there's the inherently limitations of having such little RAM. The 7800 already had programmers resorting to adding 32kx8-bit SRAMs on the carts in '87/88 (Epyx, and only 16k RAM expansion, 32k chips were used to save cost/board space over 8k chips), and planning on on-cart RAM expansion for the panther wasn't a good plan at all.

Sacrificing some low-cost on the hardware end to make for much more efficient software is a much better plan. More RAM means more flexible games, but also more cost effective games due to compression and use of slow/cheap ROMs.

Aside from just adding more SRAM, they could have added DRAM to buffer data into (leaving ROM largely compressed), good for decompression and 68k work RAM. (plus carts could be both slow and 16-bits wide to save on cost)

If they did want to allow RAM expansion later on, but wanted to maintain the cost-effective market advantage, add-ons would be the only option. (and as long as there were only few -or perhaps just 1- module(s) released, and they were small, easy to install, and inexpensive, it probably would have been quite marketable to do, especially if it was added as standard to later model revisions -128k SRAM in 1989 might have been iffy, but trivial as an upgrade ~1991) Still, 32k seems really skimpy even for 1989. (especially since a few 7800 games had been putting 32k SRAMs on-cart a couple years prior)
They also probably could have dumped the Ensoniq chip in favor of simple DMA audio using the 68k for added mixing when necessary -albeit more necessary for STe/Falcon style DMA sound than Amiga type sound with hardware channels with looping and high-res sample rate. (maybe a small audio RAM buffer independent of the main bus to avoid contention -or use a dedicated blank DMA period like the Amiga . . . or do the latter, but with a secondary bus using cheap DRAM for both audio and CPU to work in independent of fast SRAM for video)

From ram Panther would fetch 8 pixels in 2 cycles - so 6 cycles would be free anyway which would be enough for a 68k access
That's 1 68k access every 8 cycles (at 16 MHz)? So similar bandwidth as the 8 MHz 68k in the ST. (but 2x faster internal operations, and 2x the bandwidth in vblank with the Panther inactive)
Couldn't the Panther also saturate the bus for more bandwidth, making the 68k wait if necessary? (32 MB/s peak bandwidth for the Panther, 8 MB/s when interleaved with 68k accesses)

Crazyace

09-24-2011, 07:35 AM

Crazyace, if you're still watching this thread, I finally got around to looking back to the discussion that got left off here:

My comments on the CPU resource issue were mainly towards you mentioning "Star Fox at 6 FPS" and musing whether that was mainly due to CPU resource limitations or not. (otherwise it would be DSP+blitter limiations over the Super FX . . . or that performance quote was for a real-world case with audio running and such -contending for DSP resource, unlike Star Fox)

I think it was a whole system comparision - ie , not software rendering on an 8088/6 , but using the blitter / dsp

I still wonder how similar the SFX is to the Flare DSP, but I haven't found much info on that so far. (I haven't seen much documentation on the Super FX -and my understanding is a bit limited anyway, so it'd be tough to compare the 2 by myself . . . Sik mentioned knowing a bit about the SFX's architecture, but he hasn't looked much at the Slipstream's DSP iirc)

It's not that similar - look at the source code to bsnes , as that should clear up things for you regarding the SFX

Edit:
Ah, I see the section on the comparator now, that makes sense. (2-bit priority for blitter rendering -also explaining the main use for the palette segment registers, able to assign a different 64 colors to each plane -or 128 if 2 planes are used, 256 with 1)

Another disadvantage of not having pixel-accurate scrolling (aside from smoothness) is the inability to do some "tricks" that require single pixel offset scrolling, like motion blurred dithering. (use cherckerboard dithering -or column dithering- and offset every other scanline by 1 pixel each frame to blend the dithering more evenly -at the expensive of horizontal and temporal resolution, ie effective 1/2 res and 25/30 Hz framerate, but useful for certain games and also going beyond the limits of 12-bit RGB -and working in RGB, unlike composite artifact blending)
Hmm, actually, maybe you could use the plane bits to do a similar effect without scrolling. (flickering between 2 different planes, changing the priority at 50/60 Hz for 36 pseudo colors in 4bpp or 8256 pseudo colors in 8bpp -using 2 8 or 128 color planes . . . or you could use that same effect at full res -not trying to blend dithering- for just getting 16 or 256 pseudo colors outside of the 12-bit RGB range)

I dont think you understand the plane system - it's not really a seperate plane, more like a 2 bit Z buffer and 6 bit colour :) Also why would you need scrolling tricks to implement dithering - just draw the pixels!

I understand the use of slow ROMs, but slow RAM made less sense. (especially if that was the real limiting factor on the CPU clock rate -I rather doubt Ricoh had trouble managing 7 or even 10 MHz for the 65816 in '89/90) If they couldn't get a good FPM DRAM interface set-up to allow something in the 7-10 MHz range (probably 7.16 MHz given the 21.48 MHz master clock and common 120 ns DRAM), they could have switched to SRAM or used a mix of SRAM and a slower DRAM buffer. (the main reason to have slow DRAM at all would be for decompressing data into, something many SNES games ironically avoided in general due to CPU speed issues -and not wanting long load times- so from that respect it probably would still have been win-win even if only 32k of fast SRAM had been used in place of the 128k DRAM, let alone 64k SRAM or 32k SRAM plus 64k DRAM)

Again it's always cheaper to have slower components :) SRAM in particular is a lot more expensive than DRAM.

Yes, but wouldn't the DSP be useful in accelerating software scaling/rotation/texture mapping?

Maybe, but the DSP instruction set isn't really suitable for random memory accesses - it's still likely to be faster than a 8088 though :)

That becomes somewhat moot when you get into multi-layer scrolling though. Hardware scrolling ofthe bitmap plane (or lines therein) is rather limited for any games that don't just use one large BG and moderate sprite objects. (albeit that would be the case for most ST games obviously, but by the early 90s, that wasn't so much the case -even the TG16 had heavy use of large/numerous sprites that go well beyond that -ie you'd only get modest assistance from a single scroll plane, and spend a lot of time repairing where sprite objects "damaged" the BG famerbuffer)

Even with multilayer scrolling hardware assistance is helpful - you use it to handle the largest movement of pixels. ( dual plane scrolling is the best - and even the amiga had that )

SMS had trouble scrolling at 60 Hz at times too (especially for diagonal stuff), though most of that was probably slowdown from CPU timeouts. (not sure about the diagonal issue)

If SMS didn't have h/w scrolling it would have a lot more trouble :)

As for needing to beat the MD hardware in raw performance, that's arguable. They'd need some sort of attraction/advantage for the system to be sure, but inherent technical superiority is rarely the definitive advantage needed to be successful on the market. You do need at least adequate hardware for the time that's reasonable for developers to work with, perhaps with some special features the competition doesn't have (especially if it's weaker in other areas), then you need good marketing and management relative to the regions the product is released in, brand recognition, 3rd party software interest, some degree of 1st party/licensed software, attractive price point, etc, etc. (having a bunch of money to throw at software licenses and advertising always helps, but for Atari or -especially- Konix, that wasn't going to happen on a large scale -at least not on the level of outstripping Sega or Nintendo -nevermind Sony, or without some nice 3rd party investors providing considerable capital-)

Albeit, you could argue whether the Slipstream even met the minimum for a reasonable 5th gen system on the hardware end, especially in the state it was in at the time. (with some tweaks to the architecture, it probably could have been OK, or just a more expensive configuration like a full 256k of PSRAM -but then you threaten the price point, better would probably have been support for 16-bit wide DRAM and ROM rather than only P/SRAM and 8-bit DRAM/ROM and use a mix of P/SRAM and DRAM, probably use a faster x86 chip -like a 12 MHz V30, 186, maybe even V33 or 286, maybe even a dedicated CPU bus as well -allow the CPU to access the main system bus with contention but also allow local CPU work RAM like Amiga fastRAM or such, but then there's added cost for that too)

That's all vapourware - a bit like the multisystem itself in the end. As much fun as it is to hypothesis the version of the multisystem described in the business plan would have already been crippled compare to the original flare document :(

The problem with that is compromising cost effectiveness of software. The lynx and jaguar both took a better philosophy there: use ROM mainly as mass storage with as much data compressed as practical (so slow cheap RAM, and efficient use of limited memory capacity) with enough RAM to facilitate decompressing/loading data+code into.

It doesn't compromise all software , and the lynx only used ram as it was originally designed to load programs from cassette tape. The amount of ram on the jaguar was also pretty much the minimum amount needed for 64 bits :) - and it was cheap DRAM compared to PSRAM or VRAM on other consoles.

On top of that, there's the inherently limitations of having such little RAM. The 7800 already had programmers resorting to adding 32kx8-bit SRAMs on the carts in '87/88 (Epyx, and only 16k RAM expansion, 32k chips were used to save cost/board space over 8k chips), and planning on on-cart RAM expansion for the panther wasn't a good plan at all.

Sacrificing some low-cost on the hardware end to make for much more efficient software is a much better plan. More RAM means more flexible games, but also more cost effective games due to compression and use of slow/cheap ROMs.

I'll disagree with you here - minimising the cost of the hardware is important , Software developers will work around the limitations. In the panther case a smaller amount of fast SRAM would help maximise the performance of the device.

That's 1 68k access every 8 cycles (at 16 MHz)? So similar bandwidth as the 8 MHz 68k in the ST. (but 2x faster internal operations, and 2x the bandwidth in vblank with the Panther inactive)
Couldn't the Panther also saturate the bus for more bandwidth, making the 68k wait if necessary? (32 MB/s peak bandwidth for the Panther, 8 MB/s when interleaved with 68k accesses)
From the doc it sounds like the 68000 is halted for the entire object processor time - like the 7800, so no interleaving.

Actually I was incorrect when I said the panther wouldn't scale in X - it did have that feature

kool kitty89

09-27-2011, 03:32 PM

I think it was a whole system comparision - ie , not software rendering on an 8088/6 , but using the blitter / dsp
I wasn't saying it was in the context of software rendering (a 6 MHz 8088 obviously wouldn't be doing a 6 FPS star fox ;)), but that the 8088/86 might be the bottleneck in performance in that example. (unless they were talking about a tech demo with little/no game logic/AI and no sound -the latter issue could be a big compromise on DSP performance)

I dont think you understand the plane system - it's not really a seperate plane, more like a 2 bit Z buffer and 6 bit colour :)
Yes, that's what I meant by "priority" for blitter drawing. (no independent hardware planes as far as the video controller is concerned, but 2-bit priority "planes" for blitter rendering)

Also why would you need scrolling tricks to implement dithering - just draw the pixels!
Sorry, I didn't explain well enough. I was referring to a 60 Hz flicker based hblur technique that relied on single pixel H-scroll offets (or specifically, linescroll interleaved to even/odd frames and even/odd lines to mask the flicker/jiggling better than scrolling the whole screen one pixel every other frame). That technique can be used for solid blending of checkerboard (or column/strip) dithering to fake higher color depth at the expense of horizontal resolution.

You can't use hardware H-scroll to accomplish that on the Slipstream . . . . oh, but the blitter priority wouldn't help there either since it has nothing to do with how the video controller is outputting the graphics, nevermind. (the main advantage of using scroll based hblur/flicker/shimmering is to get more colors at a given/fixed color depth and resolution without needing a secondary framebuffer/tileset in memory to flicker/shimmer -like flicker color on the Atari 8-bit uses-)
You could use v-scroll on the slipstream, but that would halve vertical resolution and have the jiggling artifacting more. (since you can't do the interleaved lines to obscure that)

Again it's always cheaper to have slower components :) SRAM in particular is a lot more expensive than DRAM.

Yes, but in the SNES's case, there didn't seem to be much point to the added RAM if it was so slow.
It could be used for buffering compressed data, but most developers (including Nintendo) avoided that due to low CPU performance and concerns about load times. (which also compromised use of VRAM for buffering compressed data into -something common on the MD and even fairly common on the PCE)

Dropping to 32k SRAM would have reduced the potential for buffering decompressed data, but greatly improved performance (and eliminated the need for DRAM control/interface logic).
Alternatively, they could have implemented an FPM DRAM interface to allow the CPU to work at 7.16 MHz with wait states. (for refresh, page change, etc)

Even with multilayer scrolling hardware assistance is helpful - you use it to handle the largest movement of pixels. ( dual plane scrolling is the best - and even the amiga had that )
It's certainly even more useful if you can do row/line scroll too (for entire horizontal bands of the screen that only scroll as one layer).
But certain types of games will still have limited use for hardware scrolling. (albeit not so much the sort of games that were popular at the period in question . . . and many such games would have other problems on the slipstream anyway ;))

That's all vapourware - a bit like the multisystem itself in the end. As much fun as it is to hypothesis the version of the multisystem described in the business plan would have already been crippled compare to the original flare document :(
Yes, the way Konix was planning on producing the Multisystem would have left it rather crippled in general. (I keep thinking in the context of whether Atari Corp might have taken interest in the Slipstream over the Panther around the time they brought Brennan on board . . . albeit just building onto older designs generally isn't an efficient route to go -starting a new or partially new design in '89 using the best ideas of the panther/slipstream/lynx chipsets would have been nice . . . well the Jaguar pretty much did that too, except it was a much more ambitious/long-term project than a replacement/alternative to the Panther -that's partially just buisness model though, a much more conservative project targeting a much earlier release would have been a far more realistic plan)

It doesn't compromise all software , and the lynx only used ram as it was originally designed to load programs from cassette tape. The amount of ram on the jaguar was also pretty much the minimum amount needed for 64 bits :) - and it was cheap DRAM compared to PSRAM or VRAM on other consoles.
I'm not sure what you mean about the Jaguar . . . they could easily have gone with 4 64kx16-bit DRAMs for 512k main memory . . . and been a lot closer to what the 32x did. ;) (ie relatively limited space to decompress into leading to far, far less efficient use of cart space -and either much more costly games and/or greatly reduced content . . . not to mention lower performance for accessing lots of uncompressed data in ROM rather than having it loaded into RAM)

Limiting RAM obviously would have made porting games from PCs and doing multiplat 3DO/Jaguar/PSX/Saturn/etx games much harder. (obviously the Jaguar did already have significant programming difficulties, but at least it had a competent amount of RAM for the time -unlike the 32x ;))

I'll disagree with you here - minimising the cost of the hardware is important , Software developers will work around the limitations. In the panther case a smaller amount of fast SRAM would help maximise the performance of the device.
Yes, minimizing cost is important, but there's much more context than that. It's the same issue as the Jaguar going with carts rather than CD-ROM, just less extreme. (more RAM=more ability to compress data on carts and have lower cost games, much like adding CD-ROM does -and in the latter case you definitely need a competent amount of RAM since streaming on the fly is far more limited than carts)
Albeit one alternative to added RAM would be a coprocessor capable of quickly decompressing data on the fly.

But as to keeping costs down, that's also why I mentioned adding a DRAM bank in the Panther to allow for added buffering of decompressed data from ROM. (rather than just adding more SRAM) And there's also the limits of the Panther being planned to be ready for release in 1989. (even pushing that to late 1990 would have meant much lower RAM prices in general -potential for more SRAM and/or DRAM)

There's also the whole add-on module approach I mentioned. (far more efficient than tacking enhancements on carts, but also tricky to market -it doesn't help that nearly all historical examples are rather costly/bulky/substantial add-ons that were often mismarketed/mismanaged or only did well in Japan . . . but I am mainly talking RAM upgrades, and the few examples of pure plug-in RAM modules did generally avoid the pitfalls of other add-ons -Saturn RAM carts, N64 expansion pak, etc)

From the doc it sounds like the 68000 is halted for the entire object processor time - like the 7800, so no interleaving.

Actually I was incorrect when I said the panther wouldn't scale in X - it did have that feature
OK, that's what I'd originally thought (especially based on Kskunk's comments) . . . and like many 7800 programmers have suggested, a separate bus for video and CPU would have eliminated that problem. ;)

Obviously, multiple busses add to cost, though there were other possible trade-offs to help mitigate that. (like chucking the Ensoniq chip entirely and having the 68k handle mixing to simple DMA sound channels, plus any added RAM on the main bus could be cheap DRAM)

saturndual32

09-29-2011, 12:50 AM

kool kitty89

09-29-2011, 01:45 AM

I was reading an interview with Traveller Tales about their Sega Saturn game Sonic R. On it, it is mentioned by the team, that the Saturn is actually better at gouraud shading than the Playstation. Is this true?, judging by what was seen on both consoles libraries of games, one would think that its actually the PS thats better at g-shading, with games like Ridge Racer 4, Tobal 2, etc.
I think most here have already read said interview, but heres the link anyway:
http://info.sonicretro.org/Jon_Burton_interview_by_Sega_Saturn_Magazine_(Octo ber,_1997)
The PSX should be both faster and just as smooth as Saturn shading . . . and both should g-shade faster than they can texture map.

Both can only render in 15-bit RGB (32,768 colors), though the PSX allows 24-bit color to be displayed for other things (static images, streaming video, etc) but the GPU can't render 24-bit RGB. Likewise, the Saturn can display 24-bit color with VDP2 (and the BGs can use 24-bit RGB), but VDP1 can only render in 256 indexed colors or 15-bit RGB. (and can only g-shade in 15-bit mode)

The PSX has an added advantage of hardware dithering. You could choose to use plain 15-bit rendering with posterization (like the Saturn), but many developers chose to use the dithering feature to smooth out shading at the expense of looking grainy/blocky. (simple pattern block dithering is used, and apparently there's no control over the threshold -it's approximating 24-bit RGB iirc- and at the common 320x240 resolutions, the dithering is pretty coarse -PC games of thetime often supported dithering too, but usually ran at 640x480 or higher, and I think some PS3 games also used highcolor rendering with dithering -but at 640x480)

Crazyace

09-29-2011, 09:36 AM

I wasn't saying it was in the context of software rendering (a 6 MHz 8088 obviously wouldn't be doing a 6 FPS star fox ;)), but that the 8088/86 might be the bottleneck in performance in that example. (unless they were talking about a tech demo with little/no game logic/AI and no sound -the latter issue could be a big compromise on DSP performance)

In a game maybe - but running the game code in vblank, and the rasterisation during display would avoid any major slowdowns of 8088 code ( beyond the standard )
I guess it really needs to be tested - I wonder if there's any slipstream emulation in mame ( for the bell fruit machines maybe )

kool kitty89

09-29-2011, 04:04 PM

In a game maybe - but running the game code in vblank, and the rasterisation during display would avoid any major slowdowns of 8088 code ( beyond the standard )
I guess it really needs to be tested - I wonder if there's any slipstream emulation in mame ( for the bell fruit machines maybe )
I was really just making a possible inference on why it would be limited to "Star Fox at 6 FPS" in general. The context of that statement itself is generally vague, so it's hard to argue one way or the other.

It might not be about allowing the 8088/86 to run full bore either, but could be a general bottleneck of CPU resource regardless (ie you'd need better than a 6 MHz 808x to do better than that).
Plus, you've always got some contention for CPU/DSP/Blitter since having the CPU access interleaved will reduce blitter/DMA bandwidth for the other processors to some degree. (depending on how many accesses the 808x does -though you could dig into CPU bus time as needed like the Amiga)

If I didn't make it clear before, there's a number of different contexts I've been thinking of in regards to the Slipstream in general:
1. the configuration intended to be used by Konix themselves (apparently 64k 16-bit PSRAM+64k 8-bit DRAM, 6 MHz 8086 with a bus latch -existing development systems were only using 8088 and no bus latch iirc)
2. the general variety of configurations possible with the slipstream ASIC itself without specific context of the Multisystem (ie up to 256k fastRAM, possibly a better/faster x86 derivative, etc)
3. using the slipstream in conjunction with added external logic (extending the chipset) like a fully separate local CPU bus (in addition to the interface with the slipstream -with external bus logic allowing the CPU to switch between both -especially important with faster/more efficient x86 derivatives that would tend to be able to make use of the added bandwidth/bus time -and general lack of contention), and perhaps allowing the slipstream to use 16-bit DRAM rather than only 8-bit and SRAM/PSRAM. (better with FPM support+wait states, but plain 3 cycle ~250 ns DRAM accesses at 16-bits would still be double the bandwidth of using 8-bit DRAM)

Beyond that there's some areas I'd mused on but never brought up in this discussion, like the Slipstream's potential use as an accelerator in other systems. (for example, if Sega licensed it and used it in a configuration somewhat like the 32x on the MD; the Slipstream already has some provisions for genlock, but it would need to be able to use one of the MD's dot clocks to properly overlay video, either 6.7 MHz -which would mean overclocking the slipstream and having a larger horizontal boarder- or 5.37 MHz, which would mean dropping the internal clock speed to 10.74 MHz and having no horizontal boarder for 256 pixels, so probably the latter . . . of course, you'd also need added logic to interface with the 68k style bus rather than x86)

There's also the rather separate topic of actually using the Slipstream design/concept as the basis for a newer, more advanced system in general. (like if Atari had pushed for a much more conservative/short-cycle development for a system better than the Panther but still ready far sooner than the Panther . . . or a general earlier incarnation of the Jaguar of sorts that took some elements of the Slipstream and Panther design concepts -or perhaps some parts of those specific designs-)
But that's really a separate topic altogether . . . more of a general "what sort of console could/should Atari have had for the 16-bit console market" . . . or possibly uses of said console chipset in later gen ST family computers. (albeit they'd already kind of screwed that up with the STe in '89 . . . also a different topic ;))

Edit:
I forgot the bellfruit arcade machines . . . I wonder what memory configuration those used. (I'd imagine they used Z80s too given they predated the Konix efforts)

Crazyace

09-30-2011, 02:46 AM

kool kitty89

09-30-2011, 03:45 PM

I don't believe the 64k+64k configuration was actually practical at all - a single screen at 256x200 with 256 colours would eat 80% of that. ( It might explain why the Argonaut biker game used such a small window - 104x256x 256colours x 2 buffers + 96x256x16 colours would fit exactly into 64k. I guess a smaller window would actually be needed to leave some room for graphics sprites )
If Konix had released it as such, it certainly would have been crippled. Even if you dedicated the fastRAM to framebuffer space and pulled textures from DRAM, that would mean sacrificing a ton of blitter bandwidth due to the 8-bit wide 3 cycle (minimum) accesses.
With that little RAM, there would probably be many cases where going single buffered and accepting some tearing would be worth the added RAM space left. (or larger screen size -and, of course, making running in 8bpp mode more practical)

I wonder if that really was the planned final configuration for the Multisystem or whether they never finalized it at all. (the articles on the Slipstream Archive website point more towards never finalizing that configuration)

Crazyace

10-03-2011, 02:41 PM

kool kitty89

10-03-2011, 06:44 PM

I guess for most actual sprite drawing it wont be too bad - 5 cycles ( 3read/2write ) vs 4 cycles ( 2read/2write) per pixel for 8 bit - 7 cycles vs 6 cycles for 4 bit. Only 16 bit copies will suffer :(
I wonder why 16-bit DRAM (or ROM) wasn't supported . . . even with the 8088 or Z80 it would have made sense due to blitter (and possibly DSP DMA) access. And the more useful DRAM use becomes, the more practical it is to minimize SRAM/PSRAM. (they also gone the ST/Amiga route with a shared 16-bit DRAM bus design with CPU bus latch and wait states for added cycle stealing -the next step beyond that would obviously be FPM DRAM support with corresponding optimized features/system organization more like the Lynx, but that latter option wouldn't have made as much sense in the original 1986/87 Slipstream design timeframe with FMP DRAM being less common -except probably still much cheaper than SRAM or PSRAM)

In 256 color mode (or high res 16 color), you'd be using significantly more bandwidth than the ST though, and also at a dot clock that didn't fit very conveniently with simple interleaving via latch. (so, without added buffering, the video controller would saturate DRAM to scan the framebufer -so blitter/CPU would only have access in hblank/vblank)

Line buffers would get around that problem and allow reasonable bus sharing. You could have full 256 byte scanline buffers (or 512 bytes for double buffered lines -needed unless DRAM was fast enough to copy a whole line in hblank) and use serial bus sharing for VDC/CPU/blitter/DSP accessing (or add interleaved "cycle stealing" during CPU accesses -assuming such a slow accessing CPU was still used, obviously not a 650x ;) ), or you could also use a much smaller prefetch-like buffer that could much easily fit on-chip. (and thus avoid costly larger ASICs or need for external SRAM chips for such a video buffer)
With full line buffers and ~250 ns (3 cycle) DRAM accesses, you'd have just under 51% of bandwidth going to the VDC (outside of vblank), but you'd only need 6 bytes of prefetch (or 12 bytes since it would be double buffered) to effectively manage the same thing. (the VDC would use 9 of every 12 cycles to fill 6 bytes of the cue with 3 cycles -or one read- left for blitter/DSP use plus full bandwdith in hblank and vblank)

Obviously, such buffering would become even more useful if FPM DRAM were used. (and longer buffers would become more useful -long serial accesses to keep as close as possible to peak FPM speed, though small prefetch buffers would still allow major leaps in bandwidth in FPM DRAM over plain DRAM -especially at ~84 ns rather than ~168 ns, though only the latter would be practical for the late 80s . . . or ~120 ns if a different clock speed were used)
~168 ns FPM DRAM could have allowed close to the bandwidth offered by SRAM/PSRAM used in the historical Slipstream at far lower cost. (albeit in certain situations you'd have substantially less bandwidth compared to PSRAM/SRAM -especially slow CPU accesses, or generally changing bus masters too often, similar to the jag's bottlenecks . . . but that's still probably going to come out well ahead of the bottlenecks of slow 8-bit DRAM and ROM -or the separate bottlenecks of using too little RAM in general- )
An FPM DRAM interface would also be more difficult to implement, but that definitely seems like the best option overall.

For that matter, there's the same argument for the panther for DRAM. (ie 125 ns FPM DRAM rather than SRAM) And in that case, there's not even support for any interleaved bus sharing in active display (OPL saturates the bus as needed to build up the scanline -rather like MARIA), so it fits even better with FPM DRAM. (peak bandwidth would be identical to SRAM too, though real-world bandwidth would be somewhat less due to page changes)
Didn't the Panther already use on-chip line buffers to build the scanlines into, or is external SRAM also used for that? (I'd gotten the impression that MARIA also had line-RAM on-chip too -and double buffered, but maybe I'm mistaken)

Edit:
And on a more off-topic side note: FMP DRAM support should have been one of the first evolutionary additions to the ST and Amiga (both chipRAM and fastRAM), probably even before going to 32-bit buses. (not to mention support for higher peak CPU bandiwdth/access speed in ST-RAM or Amiga ChipRAM, so that faster CPUs weren't stuck on the 250/280 ns access speeds from 1985 -ie slower than 16-bit ISA :p )
Packed pixels would have added advantages over planar for FPM+buffering, though the ST SHIFTER's interleaved planar format also would have already been easier to make use of for buffering than a full planar bitmap. (4 linear 16-bit reads gets a complete line of 16 4-bit pixels similar to 4 16-bit reads for 4-bit packed pixels -so a 64-bit buffer/cue could be used to hold a complete 16 pixel line, though packed pixels are still far more flexible for providing added buffering)

Crazyace

10-04-2011, 02:10 AM

I guess either cost or added complexity in the dram controller.
Line buffers would also add to the complexity of the ASIC :) - and they wouldn't really add anything to the flare design - as video would scan out from memory in a linear fashion anyway. Regarding small buffers there's not much detail in the slipstream docs - so you don't know if they have internal buffers or not.
Buffering would also complicate the dsp access to memory, which was software controlled.

Regarding the ST comments I think some of those techniques made it into the TT blitter ( 64 bit memory, bursts ) - and the Archimedes graphics chip also used burst accesses ( needed as the ARM chip was a heavy bus user :) )

kool kitty89

10-04-2011, 05:54 PM

I guess either cost or added complexity in the dram controller.
For FPM support, perhaps, but lack 16-bit bus width (for ROM or DRAM) wouldn't make much sense in that regard. (reducing the number of traces on the board and pins on the expansion port would be a consideration though)

I'd imagine development time (and funding) would be a bigger factor for choosing (P)SRAM for fastRAM rather than DRAM/FPM DRAM. The latter has definitive cost advantages (and overall superior cost to performance ratio), but would definitely take more time/money to design -and more potential for bugs. (so more costly for R&D, but a major pay off for the final machine in terms of cost effectiveness and all around performance)

Line buffers would also add to the complexity of the ASIC :) - and they wouldn't really add anything to the flare design - as video would scan out from memory in a linear fashion anyway. Regarding small buffers there's not much detail in the slipstream docs - so you don't know if they have internal buffers or not.
With the way the current design is set-up (with framebuffer in fastRAM), it would make sense for the VDC to simply use a 16-bit latch for scanning the display (read 2 8-bit pixels or 4 4-bit pixels at a time into the latch and scan that out to the display). That works fine for SRAM/PSRAM while still allowing the blitter/DSP to soak up the remaining bandwidth in active display (for every 4 cycles in high res modes, the VDC uses 2 to read a word and leaves 2 open to the chipset -for low res, the VDC needs 2 of every 8 cycles), but that doesn't fit well with DRAM (either plain 3 cycle access DRAM, or FPM).

With 250 ns accesses (3 cycles) and no added buffering (than a 16-bit latch), the VDC would saturate the bus for high res modes even though it would only use 3/4 of the bandwidth. For every 4 cycles, you'd need 3 to read a word and the single cycle left over is wasted. (if you extended it to buffer 3 words worth of pixels at a time, you could have 3 cycles left for every 12 cycles, so you'd make use of that extra 25% bandwidth rather than wasting it) For low res mode, without added buffering, you'd need 3 cycles to read a word out of every 8 cycles, leaving 5 -but only enough for the chipset to make a single access in those 8 cycles. (with 3 words buffered by the VDC, you'd use 9 cycles of every 24 cycles and leave 15 for the chipset -enough for 3 reads and no wasted cycles)

With FPM used, there's more variable numbers of accesses depending whether page breaks occur between accesses from non-VDC bus masters. (though FPM for DSP DMA, blitter fill operations, and VCD reads would be useful at least)

Buffering would also complicate the dsp access to memory, which was software controlled.
The only buffering I was suggesting is for the VDC, to allow more efficient bus-sharing in active display if DRAM were used for the fastRAM bank.

Regarding the ST comments I think some of those techniques made it into the TT blitter ( 64 bit memory, bursts ) - and the Archimedes graphics chip also used burst accesses ( needed as the ARM chip was a heavy bus user :) )
You mean TT SHIFTER, right? (the TT has no blitter . . . )

I'm not sure if the TT SHIFTER used FPM accessing, but it obviously had buffering for 64-bit reads. It still only supported planar pixels though, especially bad since there was no blitter. (8-bit packed pixels would have been far better for the 68030 to manipulate . . . )

However, I was pointing out that it would have made more sense to implement FPM DRAM before even going beyond a 16-bit bus. (no added cost for more traces/pins, but double the peak bandwidth over what the ST used in 1985 -assuming 120 ns DRAM, or 125 ns accesses rather due to the 8 MHz system clock; a fastRAM-like CPU bus would also have been rather significant
. . . not to mention the addition of a general purpose expansion bus -which the MEGA ST did do, but didn't become standard on the console models)

Crazyace

10-05-2011, 01:53 AM

On the Konix highres is 4 cycles video read + 4 cycles free , and lores is 4 cycles video read + 8 cycles free - according to the documentation.

kool kitty89

10-05-2011, 03:08 PM

On the Konix highres is 4 cycles video read + 4 cycles free , and lores is 4 cycles video read + 8 cycles free - according to the documentation.
OK, so that implies buffering 2 words at a time rather than 1. That would mean lores might allow 16-bit DRAM (with 250 ns accesses) to have the VDC use 6 cycles and leave 6 free (2 more accesses), but highres would need 6 cycles and only leave 2. (not enough for even 1 access) Unless FPM DRAM were used, in which case (assuming 2 cycles for FPM), the VCD would take 5 cycles per video read with 3 left over in hires or 5 with 7 left in lores. (in the latter case, either 2 random accesses or 3 sequential accesses in the same page)

Hmm, wait a minute, why would it be 4+8 cycles for lores? That would mean the VDC was reading 32 bits once every 12 cycles, but at 4bpp and a ~6 MHz dot clock, it should only need a 32-bit read once every 16 cycles, not 12. (unless it's only reading 24 bits rather than 32 . . . and it must be 32 in the case of hires since you'd need a full 32 bits to be read within every 8 cycles due to 8bpp at 6 MHz or 4 bpp at 12 MHz)

Crazyace

10-05-2011, 03:56 PM

Dont worry - my mistake, it's 4 + 12 for lowres :) - You can check it yourself in the slipstream reference pdf.

kool kitty89

10-05-2011, 07:09 PM

Dont worry - my mistake, it's 4 + 12 for lowres :) - You can check it yourself in the slipstream reference pdf.
Yeah, I remembered reading that too, but I was taking your word for it. ;)

And in that case, for lowres, it would be 6 cycles for the VDC and 10 left over (so 3 accesses), or with FPM, 5+11 cycles. If they were going to optimize it for pure DRAM, the VCD should definitely have read/buffered 3 16-bit words at a time rather than 2 to cater to the 3 cycle long accesses.

Crazyace

10-06-2011, 02:25 AM

kool kitty89

10-06-2011, 05:46 AM

I suppose that as this would reduce performance though it's not really worth bringing up. - It's better I guess to talk about the Konix as it was designed :) - ( and maybe in the 4th generation topic as it's definitely not a 32/64 bit machine )
Yeah, though I think you've pretty much addressed it well enough in any case.

But actually on the topic of 5th gen stuff again:
I was thinking about the "fast" texture mapping schemes on the Jaguar you mentioned earlier. (fetching textels from main RAM, rendering to a buffer in GPU SRAM and then copying that to the framebuffer in 64-bit chunks)

Would it be possible to copy several textels at a time into GPU RAM (say a single 64-bit copy) and then use those 4 textels to render with in GPU RAM? (with 1 cycle per textel read rather than 5) That would only improve performance for cases where you'd often want to use several consecutive texels in a line from a texture (and be a detriment to cases where you only have 1 desired texel per 64-bit DRAM read), but wouldn't cases like that occur fairly often? (it would seem like most cases of texture mapping would cater to fetching a group/line of textels like that -like a very limited texture cache)

You could potentially cache/buffer larger chunks of textures into the scratchpad (ie well beyond the 64-bit line I suggested), but the larger that becomes, the more SRAM is consumed, obviously. (something already limited more than usual by the texture rendering buffer in SRAM)

Edit:

In the JagII manual they have a intersting timing breakdown for texturing 4 pixels on the original Jaguar.

4 x ( rowchange + read + r/wbuschange + rowchange + write )

4 x ( 3 + 2 + 1 + 3 + 2 )

This gives 44 cycles for 4 pixels ( 11 cycles per pixel )

Using a 2 pass renderer the bus activity per 4 pixels would be 3 + ( 4 x 2) + 3 + (1 x 2) ignoring the blitter setup , so 16 cycles ( 4 per pixel ). If texturing a 16 pixel span the bus cost would be less than 3 cycles per pixel - which is a lot faster than 11, without any hardware changes.

looking at this again, it seems like you already were comparing an example using cached textures AND a 2-pass renderer (texture cached in SRAM, then used to render to a buffer in SRAM, and then copied into DRAM).
Except even then I can't really see how you'd get it down to just 16 cycles for 4 pixels, let alone the mention of less than 3 cycles per pixel. (unless you were listing cycles spent on the main bus rather than GPU/blitter clock ticks needed to texture map -which would include cycles spent in main and SRAM)

Including overhead to cache a texture and copy the results to the framebuffer, the fastest case I could figure would be this:
2 cycles (64-bit FPM read) + 1 cycle (r/w buschange) + 2 cycles (2 32-bit writes to SRAM) + 4*(1+1+1) cycles (textel read, r/w change, write for 4 pixels/textels) + 2 (2 32-bit reads) + 1 (r/w) + 2 (64-bit FPM write)
Which gives 22 cycles (26.6 MHz) to render 4 pixels (ignoring overhead for set-up, and assuming peak FPM access times -in real world, you'd hit somewhat less than that at best), and spend 6 cycles of that in main. (and that's not 6 of every consecutive 22 cycles spent in main, but an average -since you'd spend many consecutive cycles paging/caching a texture into SRAM and again to copy the rendered stamp to the framebuffer -which also works out well for the serially-optimized bus sharing of the Jaguar, with a fairly long period with the blitter spent in SRAM leaving the main bus free for other masters to access)

Crazyace

10-06-2011, 06:42 AM

kool kitty89

10-06-2011, 09:08 PM

Those were pretty much scribble on piece of paper timings - I'll have to check the docs again ( and maybe even turn on the jaguar :) ) - so it's very likely that I haven't included the gpu memory cycles - which would change the timings to 3 + ( 16x2 + 16x1 ) + 3 + ( 4x2+ 4x2 ) for 16 pixels - 4.375 cycles per pixel rather than the optimistic 3.
( I need to check about whether the write to dram can overlap the next read from gpu internal ram )
Aren't you still leaving out some cycles spent accessing SRAM? After the 2 cyle DRAM readn, you'd need 1 cycle (R/W buschange) and 1 cycle (write) for each pixel, plus for reading the resulting texture buffer out to main: 2 cycles (read 64-bits), 1 cycle for R/W change, and then 2 cycles for a 64-bit DRAM write? (so for 16 pixels, that's another 20 cycles you didn't include -it looks like you included all the reads, writes, and rowchange cycles, but not R/Wbuschange)

For small repeated textures copying the whole thing into gpu ram should speed up the texture fetch as you said ( you could also use pallette ram as well if you needed to )
Palette RAM is 256x32-bits, right? (so another 1kB on top of the scratchpad)

Crazyace

10-07-2011, 02:44 AM

That's why I mentioned checking whether dram reads / gpu ram writes overlap :) - If the bus change is just for dram then that cycle is saved in the 2 pass method.
One thing to note is that this 2 pass style renderer seemed to be in Atari's later SDK - so newer titles would have been using it compared to the original atari code ( unless they had already rolled their own )

kool kitty89

10-07-2011, 04:17 AM

Crazyace

10-07-2011, 06:00 AM

blitter writes to gpu ram

kool kitty89

10-07-2011, 03:54 PM

blitter writes to gpu ram
Ok, by "GPU RAM writes" you meant writes to GPU RAM not GPU writes to RAM.

And on the note of using CRAM as an added scratchpad: it is usable as a full 1024 bytes (256 32-bit words), right? I remember Kskunk mentioning that CRAM was set up with full 32-bit words, but just couldn't be used for indexing 24-bit pixels for some reason. (something was wrong with color look-up in 24-bit mode)

Oh, and there's what you mentioned about only the object processor being able to use color look-up. Can the blitter really only use direct color (ie read 8/16/32-bit pixels and write to a framebuffer of the same depth), or is there some other support for color look-up with blitter textures? (only having unpacked textures could eat up RAM space really fast)

Da_Shocker

10-12-2011, 12:26 PM

kool kitty89

10-12-2011, 05:42 PM

Can anyone please explain this? In regards to D&D Collection on the Saturn

Due to the limitations of the Saturn there is a maximum of two players instead of the original four. As there are some doors and events which require the game to have more than two people playing the game (such as the special ability Final Strike), there may have been changes to the game rules to allow these events to happen with only 1 or 2 players.

What limitations are these? Does the CPS2 have more ram than a Saturn with the 4MB ram cart? I'm pretty sure all of the vs. games are more complex than D&D.
That seems rather odd . . . it would seem more likely that they didn't bother to support the multitap. (and if they had, they'd need to support different game modes for more or less players given parts of the arcade game require 4 players to work . . . or just allow 4 players along with the changes to work with 1-2 players in all modes)

The only other thing would be animation for the added players. (but as you say, that should be less intensive than the fighting games) Did D&D support the RAM cart?

Da_Shocker

10-12-2011, 07:25 PM

That seems rather odd . . . it would seem more likely that they didn't bother to support the multitap. (and if they had, they'd need to support different game modes for more or less players given parts of the arcade game require 4 players to work . . . or just allow 4 players along with the changes to work with 1-2 players in all modes)

The only other thing would be animation for the added players. (but as you say, that should be less intensive than the fighting games) Did D&D support the RAM cart?

I think it was laziness on there part idk though but I do remember this game being in development for the Saturn and PSx back in 96 but it took them forever to bring it out and the PSx version got canned. But the only Saturn beat em ups that support 3 or more players is Three Dirty Dwarves, Guardian Hero's and 6 Man scramble. But GH is a battle royal mode and 6 Man Scramble is a wrestling game. Hell Warriors of Fate was a 3 player game on the CPS1 system and Capcom simply omited it in that port. I could get why they didn't bother during the 16-Bit days but with the 32-Bit systems, it was sheer laziness.

edit
Tower of Doom supported the ram cart but Shadows of Mystaria didn't. Or maybe it is the other way around.

kool kitty89

10-25-2011, 06:30 PM

I suppose that as this would reduce performance though it's not really worth bringing up. - It's better I guess to talk about the Konix as it was designed :) - ( and maybe in the 4th generation topic as it's definitely not a 32/64 bit machine )
If you're still watching this thread, I'm taking this suggestion and moving the topic here:
http://www.sega-16.com/forum/showthread.php?18434&p=419048&posted=1#post419048

Edit:
Oh, and one area of the 32/64-bit era discussion that I never asked directly either:

Crazyace, from what you know, would you agree it would be accurate to say that the Sega Saturn was designed without realistic cost effectiveness (both in overall manufacturing costs and cost to performance ratio) for the market at the time? (especially with the perspective of Sega as a 3rd party technology company relying on outsourced manufacturing -with the associated overhead and limitations compared to vertical integration -a la Sony)

Compared to the PSX is seems to have some notable cost/performance disadvantages, and overall higher cost (far more with Sony's vertical integration taken into account) with the many buses and banks or RAM, larger amount of overall RAM, large motherboard, larger chip count (both custom and off the shelf -and much more silicon in general, not just more IC packages and traces), and several areas with overkill performance used where more limited hardware would have worked fine. (like the 512k SDRAM+SH1 dedicated to managing CD-ROM, among others -though that's probably the most glaring)
The 3DO seems far more conservative as well with its 2 bus design, cheap CPU, and use of cheap/slow 80 ns FPM DRAM and VRAM. (the latter not so cheap, but still cheaper than most of the PSX's and Saturn's RAM) Granted, the 3DO's market model and earlier release made it far more costly by comparison. (otherwise it probably could have undercut the PSX's price point in '95, in spite of Sony's advantages)

And then you have the Jaguar's extremely tight and cost-emphasized design with very high performance relative to manufacturing costs (albeit Atari's low volumes crippled that advantage -among other things) . . . the N64 is somewhat similar in that regard, though using some rather costly components that were only made cheap by collaboration with SGI. (albeit a fairly similar overall system that had to work without the partnered advantage should have been able to target EDO or SDRAM on a 64-bit wide bus -ie ~33 MHz EDO or ~66 MHz SDRAM)

Or, for that matter, compared to the Dreamcast's design. (a multi-bus design, but limited to 3 buses, all using commodity SDRAM for the time -PC-66 for audio and PC-100 for CPU/video- and a reasonable amount of RAM, very consolidated/embedded streamlined design, etc)

This is ignoring the context of 2D vs 3D performance (ie logic "wasted" on hardware that was mainly/only good for 2D -the Jaguar's object processor could be argued that too), and the SDK issues. (and to some extent, complex hardware that made good SDKs more difficult to produce -but it went beyond that, with poor translation/documentation of low level hardware . . . late release of SDKs to 3rd parties, and then the compiler/API level support issues on top of all that)

Crazyace

10-26-2011, 07:11 AM

It's not the amount of chips - but also the complexity and cost of the chips I guess.

kool kitty89

10-26-2011, 06:10 PM

It's not the amount of chips - but also the complexity and cost of the chips I guess.
Yes, the amount of silicon used and the speed of the logic, etc. (there's obviously some cost overhead for using a newer/smaller process -and more for the actual R&D involved, but fitting so much more on a small die space has huge benefits)

Using a larger number of chips does have issues too (even with overall silicon content, speed, bus width, etc the same) since you'll always end up with more board space and traces (and complexity of the motherboard) for using a larger number of individual chips. (far more redundant address/data/gnd/VCC/etc lines, plus added connectivity between any logic chips needing to communicate with eachother)
Granted, many cases of having more chips on the board also comes along with more overall silicon too . . . obviously in the extreme for cases with unconsolidated arcade boards with tons of discrete logic chips (often with a mix of custom LSI chips as well), same with a few unconsolidated computer chipsets. (like early Apple IIs and IBM PCs . . . and the TRS-Model II, among others)

But in the case of the Saturn specifically, there's 2 main problems for cost:
1. actual overall manufacturing cost of the system being relatively high for a game console at the time (regardless of performance or such)
2. the raw performance relative to that cost wasn't especially good either by contemporary standards of the time (even more so comparing nominal performance due to programming difficulties -hardware and tool related- and the separate issue of having a massive chunk of logic dedicated to 2D rendering -granted the OPL in the Jaguar was also a big chunk dedicated to 2D, but that was still proportionally small compared to the logic going to the GPU -plus the blitter and z-buffering- and the OPL's sprite scaling and efficient framebuffer scanning was arguably more useful for 3D support than what VDP2 offered)

Hell, even from the 2D perspective, the Jaguar was almost certainly more cost effective than the Saturn . . . the OPL+blitter didn't match the overall performance of VDP1+VDP2 obviously (especially for rotated/warped effects), but relative to the cost (highly consolidated .5 micron chstom chips using a shared bus with cheap DRAM) it would seem far, far more attractive . . . and obviously the OPL route works even better for games with an emphasis on heavy sprite use (large and many sprites) as well as sprite-heavy BG design (ie lots of independent BG objects vs fixed/solid scroll layers) . . . and with the same bandwidth/RAM the Saturn was using, the Jaguar chipset (or a very similar design built around such fast RAM) would have had even better performance and still been much cheaper than the Saturn. (or even more so if EDO DRAM were used rather than SDRAM . . . double the bandwidth with 26.6 MHz RAM -or more if it was boosted closer to 33 MHz . . . )

Not to mention potential use in the arcade (which was obviously a consideration for the Saturn too) . . . a Jaguar-like chipset could have been pretty awesome for 2D arcade games at the time (and very low cost as well -or very high profit ;)) especially with a faster/wider CPU like the Cojag had (especially the R3000 boards) . . . and the cojag also added the VRAM bank, so potentially better bus-sharing as well . . . and a considerable boost to blitter performance. (yet the Co-Jag's overall configuration was probably still substantially cheaper to produce than the Saturn's standard configuration)

It's just hard not to compare the Jaguar to the Saturn . . . especially the massive contrast in cost to performance ratio. (though there's also some parallels in 2D+3D emphasized hardware features, difficulties with architecture/bugs and tools/documentation in the SDKs, management problems with the parent companies, etc)

Crazyace

10-27-2011, 03:39 AM

But in the case of the Saturn specifically, there's 2 main problems for cost:
1. actual overall manufacturing cost of the system being relatively high for a game console at the time (regardless of performance or such)
2. the raw performance relative to that cost wasn't especially good either by contemporary standards of the time (even more so comparing nominal performance due to programming difficulties -hardware and tool related- and the separate issue of having a massive chunk of logic dedicated to 2D rendering -granted the OPL in the Jaguar was also a big chunk dedicated to 2D, but that was still proportionally small compared to the logic going to the GPU -plus the blitter and z-buffering- and the OPL's sprite scaling and efficient framebuffer scanning was arguably more useful for 3D support than what VDP2 offered)

Saturn had a very high quality ( you could say over engineered ) CD subsystem - that was a big expense that may have been a mistake ( although throughout the lifetime there were always more complaints about loading times on PSX titles ), and the audio block was also very high end - ( a much more complex system than the PSX or Jaguar )
The raw performance of the chipset was very good - better than the JagII would have been. It only suffered compared to the PSX - which was engineered for 3D performance, with no 'looking back' at 2D from consoles or arcade.

Hell, even from the 2D perspective, the Jaguar was almost certainly more cost effective than the Saturn . . . the OPL+blitter didn't match the overall performance of VDP1+VDP2 obviously (especially for rotated/warped effects), but relative to the cost (highly consolidated .5 micron chstom chips using a shared bus with cheap DRAM) it would seem far, far more attractive . . . and obviously the OPL route works even better for games with an emphasis on heavy sprite use (large and many sprites) as well as sprite-heavy BG design (ie lots of independent BG objects vs fixed/solid scroll layers) . . . and with the same bandwidth/RAM the Saturn was using, the Jaguar chipset (or a very similar design built around such fast RAM) would have had even better performance and still been much cheaper than the Saturn. (or even more so if EDO DRAM were used rather than SDRAM . . . double the bandwidth with 26.6 MHz RAM -or more if it was boosted closer to 33 MHz . . . )
OPL+Blitter wouldn't even match VDP1 on it's own - or even VDP2 on it's own for background generation :( - and the biggest problem with the jaguar would still be there - the fact that everything is contending for the same memory bandwidth.

It's just hard not to compare the Jaguar to the Saturn . . . especially the massive contrast in cost to performance ratio. (though there's also some parallels in 2D+3D emphasized hardware features, difficulties with architecture/bugs and tools/documentation in the SDKs, management problems with the parent companies, etc)

One was 250 at launch - the other 400 with a CD and way more performance, so is there really a huge cost to performance ratio?

kool kitty89

10-27-2011, 09:30 PM

Saturn had a very high quality ( you could say over engineered ) CD subsystem - that was a big expense that may have been a mistake ( although throughout the lifetime there were always more complaints about loading times on PSX titles ), and the audio block was also very high end - ( a much more complex system than the PSX or Jaguar )
The CD subsystem was definitely overkill though . . . they could have still had a substantially larger cache than the 32k of the PSX (or 3D), but without using a dedicated SH1 and 512k of SDRAM (a single 128kx16-bit FPM DRAM chip and an MCU overseeing transfers would make much more sense) . . . or for that matter, doing more like the MCD and using a general purpose sub-CPU to manage CD-ROM transfers, audio, etc. (while still being quite useful as a general purpose coprocessor)

As for the sound system, yes it was more advanced in some respects (more DMA channels, more DSP effects, flexible FM synth support -using the PCM oscillators as FM operators), but it ended up being nominally inferior to the PSX's sound system due to lack of any compression support (just 8/16-bit PCM and whatever software decoding the 68k could handle) and perhaps nominally inferior to the Jaguar's DSP as well (at least compared to the Jaguar's DSP on a dedicated bus -which, in addition to realtime synth or various sorts of sample synth+effects, could potentially decode MPEG-type audio in realtime).

In that respect, just having basic 16-bit DMA stereo and a fast embedded CPU/MCU handling audio mixing/decompression as well as overseeing CD-ROM transfers (and possibly used for general coprocessing) would have made far more sense. For example, omit the entire audio subsystem of the current Saturn (and SH1+work RAM), add 1 MB of of cheap 32-bit FPM DRAM shared for CD-ROM buffering/caching, sub-CPU work RAM, and sound samples, 16-bit DMA stereo PCM reading from a buffer in that DRAM, and a 28.6 MHz SH2 as the sub-CPU. (an even bigger cost savings would be to omit the 16-bit low-RAM in favor of using that general purpose FPM DRAM buffer for 2ndary storage -sort of like the Game Cube's 16 MB DRAM buffer, and SDRAM only used for the main CPUs and video subsystem . . . dropping the slave CPU on the main bus -in favor of just 1 main and 1 sub-CPU- but that would obviously reduce performance more and make more contention for audio and game/graphics performance . . . dropping the DSP from the SCU would certainly make sense though -since an SH2 is generally better at handling 32-bit fixed-point multiplication anyway)

Aside from games that stream data of CD during gameplay, you'd generally have 100% sub-CPU performance to use in-game. (and even when loading data, DMA channels should take up most of the overhead, at least for streaming long/linear chunks of data -so not seeking all over the place to grab small packets)
So you'd have a ton of resource for PCM mixing (and decompression) as well as potentially some left for general purpose coprocessing (depending how complex the sound system was). That could include MPEG audio decoding too (for general compressed speech/music or for FMV).

OPL+Blitter wouldn't even match VDP1 on it's own - or even VDP2 on it's own for background generation :( - and the biggest problem with the jaguar would still be there - the fact that everything is contending for the same memory bandwidth.
Yes, in the current system . . . but taking similar hardware with much faster memory (like EDO DRAM -so up to 1 access per OPL/blitter clock) would change that . . . and EDO DRAM would still have been a lot cheaper than the SDRAM used in the Saturn or SGRAM in the PSX. 33 MHz EDO DRAM on a 64-bit bus would allow 266 MB/s peak bandwidth . . . or 212.8 MB/s at the 26.6 MHz speed of the current Jaguar. For 2D games, there's far less CPU overhead to contend with anyway, but a fast CPU with a cache (like an SH2 or R3000 -or ARM 600) would have cut that even further. (assuming you're still sticking with the single-bus design)
If we're talking the Jaguar I hardware, the blitter would also get a substantial performance boost by filling the 2nd DRAM bank. (CPU overhead would be reduced even further if it worked primarily in that bank too -with OPL mainly/completely in the other bank)

And that's also ignoring Flare's early intention of a 128-bit OPL using 2 interleaved 64-bit banks to facilitate that while using only 64 pins on TOM. (which would have allowed 212.8 MB/s with the current FPM DRAM, or double that with EDO, or even more at 33 MHz)

One was 250 at launch - the other 400 with a CD and way more performance, so is there really a huge cost to performance ratio?
I'm talking manufacturing cost though, not market price . . . and even if you go by market price, the Jag was $150 against the $400 Saturn in '95. (though the Saturn was down to $300 that fall)

For pricing though, Sega and Atari were in totally different positions: Sega was a big-name company that could negotiate for much better deals on components (custom chips, SDRAM, CPUs, CD-ROM chipset, etc), could afford to invest in much higher volumes (economies of scale), and were willing to sell the hardware at a significant loss . . . especially after price-matching Sony late in '95. (Atari was selling the Jag at above-cost margins, at least at the $250 price point . . . and producing it only in the tens of thousands each year -maybe 100k a year at their peak, but only ~235k had been manufactured by the beginning of 1996 and only 135k sold)

The 3DO obviously had its price massively inflated by the business model used . . . it certainly wasn't as tight a design as the Jaguar (and had a CD drive), but it probably could have been sold for ~$400 (if not less) in 1994 had it been sold near cost (ie just above or just below manufacturing cost, like most consoles of the time), let alone significantly below cost as Sony started doing with the PSX.
After all, the Saturn was priced at ~$450 in Japan in '94, and that was obviously far more costly than the 3DO. (far more hardware in it, lots of SDRAM and more overall RAM with 3 MB SDRAM and 1.5 MB FPM DRAM vs 1 MB VRAM and 2 MB FPM DRAM -and 5 buses vs 2 on the 3DO)

The jaguar itself probably could have been well under $200 in 1994 if produced in volumes like the Sega and Nintendo's consoles (and sold at cost, etc).

Crazyace

10-28-2011, 05:21 AM

The CD subsystem was definitely overkill though . . . they could have still had a substantially larger cache than the 32k of the PSX (or 3D), but without using a dedicated SH1 and 512k of SDRAM (a single 128kx16-bit FPM DRAM chip and an MCU overseeing transfers would make much more sense) . . . or for that matter, doing more like the MCD and using a general purpose sub-CPU to manage CD-ROM transfers, audio, etc. (while still being quite useful as a general purpose coprocessor)

I think, given hitachi's background ( as well as the pricing sega would have got for multiple cpus ) that the SH1 wasn't really much more expensive than any other mcu - and given the worry about CD performance compared to cartridge Sega wanted the best CD system. Also, what would the cost difference have been between SDRAM and FPM ram for a console manufactuer ( like Atari or Sega ) - it wouldn't reflect the PC prices to end users. ( Was the CD buffer memory actually SDRAM )

As for the sound system, yes it was more advanced in some respects (more DMA channels, more DSP effects, flexible FM synth support -using the PCM oscillators as FM operators), but it ended up being nominally inferior to the PSX's sound system due to lack of any compression support (just 8/16-bit PCM and whatever software decoding the 68k could handle) and perhaps nominally inferior to the Jaguar's DSP as well (at least compared to the Jaguar's DSP on a dedicated bus -which, in addition to realtime synth or various sorts of sample synth+effects, could potentially decode MPEG-type audio in realtime).
No jaguar games managed 32 voice polyphony ( even without dsp effects ) so that's really completely untrue. An MPEG-type system might be a different case - but it's not a game console necessity. ( and you could make a good try on the saturn using the 68k for bitstream decompression and the 32 voices to crudely convert frequency bins to final waveform )

Yes, in the current system . . . but taking similar hardware with much faster memory (like EDO DRAM -so up to 1 access per OPL/blitter clock) would change that . . . and EDO DRAM would still have been a lot cheaper than the SDRAM used in the Saturn or SGRAM in the PSX. 33 MHz EDO DRAM on a 64-bit bus would allow 266 MB/s peak bandwidth . . . or 212.8 MB/s at the 26.6 MHz speed of the current Jaguar. For 2D games, there's far less CPU overhead to contend with anyway, but a fast CPU with a cache (like an SH2 or R3000 -or ARM 600) would have cut that even further. (assuming you're still sticking with the single-bus design)
If we're talking the Jaguar I hardware, the blitter would also get a substantial performance boost by filling the 2nd DRAM bank. (CPU overhead would be reduced even further if it worked primarily in that bank too -with OPL mainly/completely in the other bank)

And that's also ignoring Flare's early intention of a 128-bit OPL using 2 interleaved 64-bit banks to facilitate that while using only 64 pins on TOM. (which would have allowed 212.8 MB/s with the current FPM DRAM, or double that with EDO, or even more at 33 MHz)
Early intentions aren't products - and the JagII didn't show any mythical improvements to bandwidths :)

TmEE

10-28-2011, 05:41 AM

No jaguar games managed 32 voice polyphony ( even without dsp effects ) so that's really completely untrue. An MPEG-type system might be a different case - but it's not a game console necessity. ( and you could make a good try on the saturn using the 68k for bitstream decompression and the 32 voices to crudely convert frequency bins to final waveform )
On Saturn you would be using the DSP to do that stuff :P There is no fixed program with it, you put your own program on it, and you could make it do ADPCM that way :P

Crazyace

10-28-2011, 06:05 AM

On Saturn you would be using the DSP to do that stuff :P There is no fixed program with it, you put your own program on it, and you could make it do ADPCM that way :P

Is the saturn dsp run per voice? I thought it was after mixing, so not really any use for adpcm in the same way as SNES or playstation. ( And a single ADPCM channel shouldn't even stress the 68k )
Also for MPEG style audio is it fast enough to handle a DCT?

TmEE

10-28-2011, 06:44 AM

Chilly Willy

10-28-2011, 01:48 PM

I mixed up with AICA a bit... Saturn DSP is not so useful as it is indeed working on output only it seems, I did recall being able to deal with individual output ports but that is AICA stuff. But yes, the 68K alone can do a lot of things there already, only limited by the sample RAM.

A 68000 isn't going to uncompress more than a couple ADPCM channels in real-time. ADPCM on the Saturn is really only useful for sound effects, unless you are streaming ADPCM music off the CD.

kool kitty89

10-28-2011, 08:08 PM

I think, given hitachi's background ( as well as the pricing sega would have got for multiple cpus ) that the SH1 wasn't really much more expensive than any other mcu - and given the worry about CD performance compared to cartridge Sega wanted the best CD system. Also, what would the cost difference have been between SDRAM and FPM ram for a console manufactuer ( like Atari or Sega ) - it wouldn't reflect the PC prices to end users. ( Was the CD buffer memory actually SDRAM )
Yes, I believe it was Tiido (TmEE) who confirmed the Saturn uses a 256kx16-bit SDRAM for the SH1 (same chips as CPU high-RAM and texture RAM). Some have speculated that that was used due to the SH1 originally intended as the main CPU, and the final design being hacked around that. (and some leaked early specs do list an SH1 as the main CPU -or rather a specific hitachi CPU model number which was a type of SH1)

Bulk orders of RAM for game consoles obviously would be different from consumer RAM prices . . . but that wouldn't mean that common massm-market (ie highest volume by far) FPM DRAM wouldn't be substantially cheaper than SDRAM (and considerably cheaper than EDO DRAM for that matter -at east until EDO became the cheap/common low-end option in the late 90s).
Vertical integration and special interests with manufacturers would obviously have impacts as well, but that usually only goes so far. (aside from really extreme examples like NEC producing most of their own RAM and ICs . . . or Sony -though not so much for RAM- or Nintendo getting super good deals on RDRAM for the N64 -the PS2 likely as well . . . though even in the extreme cases, there's the fundamentally lower cost of manufacturing/procuring the common/high-volume off the shelf components)

On a related note, I'm generally basing my RAM prices on this:
http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm Which depicts the average prices of DRAM from the primary manufacturers/vendors (so not consumer level prices), and since it's the average of total DRAM sales, that's obviously going to best represent prices of the high-volume mass-market DRAM types being produced/sold at the time. (high-end/niche/new DRAM graded would inflate that somewhat, but relatively modestly -especially since super low-end/slow/obsolescent stock would also be deflating prices to some extent)

And I can't imagine an SH1 being anywhere near as cheap as a basic 16-bit MCU/CPU (like a 68k derivative) due to volumes, pin-count, die size, performance, etc. (the actual die size and transistor count of the SH1 wasn't much different than an SH2, but performance was obviously less -especially due to lack of caching- and pin count was a bit less too)

Obviously, doubling-up duties on coprocessors (a la MCD -if note more efficient than that configuration) would reduce cost while retaining flexibility of general purpose coprocessing.

No jaguar games managed 32 voice polyphony ( even without dsp effects ) so that's really completely untrue. An MPEG-type system might be a different case - but it's not a game console necessity. ( and you could make a good try on the saturn using the 68k for bitstream decompression and the 32 voices to crudely convert frequency bins to final waveform)
Most Jag games don't even use sampled sound aside from SFX (often using wavetable synth or other methods working totally from internal memory) . . . a sampled sound driver aimed at simulating something like the PSX's capabilities wouldobviously involve reading from ROM or DRAM and decompressing/scaling/interpolating to a buffer in JERRY's scratchpad. (and even with JERRY's slow 6-cycle 16-bit reads, a 24-channel 44.1 kHz 4-bit ADPCM driver should only take up 6% of the bus time in DRAM or 10% if reading from 375 ns ROM -though you'd avoid more page breaks and free-up DRAM space- . . . and obviously less at lower sample rates and/or lower bitrate samples like 2-bit ADPCM/CVSD or 1-bit CVSD . . . and then there's reading at lower sample rates but still scaling/inerpolating to a high rate for lesser artifacts -while still taking less bus bandwidth)

It should also be noted that Chilly Willy started working on a 32 channel 22 kHz 10-bit stereo sample driver for the 32x (using the slave SH2) almost as soon as he got the DMA sound working (without that, PCM playback took far too much CPU overhead . . . SH2s don't have the super fast interrupt modes of the J-RISC or some other RISC architectures), though he also mentioned that a 64 channel PCM driver would be practical using the slave SH2 alone. (and more recently he's made a 22 kHz mono 24-32 kbps OGG decoder that runs on the slave SH2 -though it does use up a good chunk of the limited 256k SDRAM)

Early intentions aren't products - and the JagII didn't show any mythical improvements to bandwidths :)
Again, I was talking in terms of general cost to performance examples . . . the jag and Jag 2 had far, far lower cost envelopes to cater to than the Saturn, so something as tight/efficient as those that cost as much to build as a Saturn would be another story. (again, also talking apples to apples in terms of component procurement -so disregarding in-house advantages with vertical integration, relationships with major vendors, volumes, etc)

Take the N64 as another example . . . though that's even more extreme and hard to compare due to the obvious in-house/partnership advantage with SGI (a 3rd party would have paid loads more to license the R4000 core to design something like the RSP, and even more for the RDRAM -so obviously, a similar design done independently would have relied on conventional EDO/SDRAM on a wider bus and a custom blitter and GPU/coprocessor designed independently -more like Flare's RISC GPU design, but obviously faster -so more like the Jaguar 2 at double the clock speed using PC-66 SDRAM with 533 MB/s peak bandwidth)

A 68000 isn't going to uncompress more than a couple ADPCM channels in real-time. ADPCM on the Saturn is really only useful for sound effects, unless you are streaming ADPCM music off the CD.
If you really wanted a multi-channel ADPCM (or other format) sample driver, you could always sacrifice CPU resource to do that . . . like in the 32x (but with faster CPUs on a full 32-bit bus, and with 32 hardware PCM channels to output to -so less overhead for scaling/mixing), though you'd need to periodically DMA the decompressed streams to sound RAM, store samples in main RAM, and obvious CPU/bandwidth overhead.

Hmm, would the SCU DSP be at all helpful for audio decompression? (albeit even if it technically is, lack of documentation might compromise utility for such tasks -and the existing example code is mainly oriented around 3D matrix calculations)

Chilly Willy

10-29-2011, 02:48 PM

It should also be noted that Chilly Willy started working on a 32 channel 22 kHz 10-bit stereo sample driver for the 32x (using the slave SH2) almost as soon as he got the DMA sound working (without that, PCM playback took far too much CPU overhead . . . SH2s don't have the super fast interrupt modes of the J-RISC or some other RISC architectures), though he also mentioned that a 64 channel PCM driver would be practical using the slave SH2 alone. (and more recently he's made a 22 kHz mono 24-32 kbps OGG decoder that runs on the slave SH2 -though it does use up a good chunk of the limited 256k SDRAM)

My last ogg example used the low memory branch of tremor, so it only uses 48KB of SDRAM instead of 128KB.

While 32 to 64 channels run by the Slave is possible, it would use a considerable amount of bus bandwidth if most of them were active. To avoid "excessive" bus usage by the Slave, you want to limit the channels (music + sfx) to around 16.

If you really wanted a multi-channel ADPCM (or other format) sample driver, you could always sacrifice CPU resource to do that . . . like in the 32x (but with faster CPUs on a full 32-bit bus, and with 32 hardware PCM channels to output to -so less overhead for scaling/mixing), though you'd need to periodically DMA the decompressed streams to sound RAM, store samples in main RAM, and obvious CPU/bandwidth overhead.

Yes, I was merely considering the 68000, not the SH2s. Like my 32X examples, you could use the Slave SH2 for mixing music/sfx, or decoding compressed streams like ogg-vorbis.

Hmm, would the SCU DSP be at all helpful for audio decompression? (albeit even if it technically is, lack of documentation might compromise utility for such tasks -and the existing example code is mainly oriented around 3D matrix calculations)

The SCU DSP actually ISN'T oriented around 3D calculations, it's just used for it sometimes. It's a regular integer DSP capable of the regular integer tasks such DSPs are used for. That said, it probably can be used to accelerate certain parts of audio decompression, like the iDCT. That would probably be a better use of the SCU DSP than 3D calculations.

kool kitty89

11-02-2011, 07:22 PM

My last ogg example used the low memory branch of tremor, so it only uses 48KB of SDRAM instead of 128KB.

While 32 to 64 channels run by the Slave is possible, it would use a considerable amount of bus bandwidth if most of them were active. To avoid "excessive" bus usage by the Slave, you want to limit the channels (music + sfx) to around 16.
Is part of that from wait states accessing ROM, or are you talking about SDRAM bandwidth alone?

Couldn't you also put a cap on the max bitrate channels were allotted, to moderate bandwidth more. (and for variable pitch stuff, that would be a limit on the peak sample rate being read at any time -which could be higher than the output sample rate if not specifically designed/limited to lower rates . . . OTOH you could intentionally limit max sample rate to be below the output rate, and interpolate up to the final rate)
Albeit there's the overhead not only from reading the samples, but also writing back to a buffer in SDRAM (especially since you'd probably end up with slow accesses to SDRAM . . . unless you wrote to a pre-buffer in SH2 scratchpad and copied that all out at once to SDRAM -to make use of the full-speed ~43 ns FPM accesses)

On the Jaguar, the "DSP" RISC MPU in JERRY has both a larger scratchpad (8k) and internal DACs (well, technically the internal PWM DACs aren't used, but the external DACs are still fied directly though JERRY's UART, independent of the main bus), so you only have the overhead of reading the raw/compressed samples from ROM (or DRAM) and then decoding/scaling/interpolating/mixing (and any additional effects) to a buffer in the scratchpad. (albeit there's the slow memory interface for JERRY, limiting it to 6 cycles for a 16-bit read at best -though it would be 10 cycles with the 375 ns ROMs used for many Jag games- . . . writes are really problematic to main RAM at 12 cycles -so using an external mixing buffer is even less attractive- . . . reads/writes to the scratchpad take 1 cycle, just like the "GPU" RISC in TOM)

The SCU DSP actually ISN'T oriented around 3D calculations, it's just used for it sometimes. It's a regular integer DSP capable of the regular integer tasks such DSPs are used for. That said, it probably can be used to accelerate certain parts of audio decompression, like the iDCT. That would probably be a better use of the SCU DSP than 3D calculations.
Yes, but isn't it explicitly presented as a 3D math coprocessor in the manual? (so what little support/documentation there was, was more oriented towards that than anything else)

Anyway, the SCU DSP can communicate through bus A and B on the Saturn, right?
So it could communicate with the sound subsystem directly (at least as far as the 68k), but could it actually access sound RAM? (if the SCU DSP could directly read/write to sound RAM, that could be extremely useful)

OPL+Blitter wouldn't even match VDP1 on it's own - or even VDP2 on it's own for background generation :( - and the biggest problem with the jaguar would still be there - the fact that everything is contending for the same memory bandwidth.
I was thinking about this comparison again . . .
Why wouldn't the Jaguar OPL be able to exceed VDP1 (aside from rotation), at least in the context of a CPU-light game (or demo) where graphics would have most bandwidth available?
The OPL has peak bandwidth of 106.4 MB/s in DRAM vs VDP1's 53.7 or 57.3 MB/s (depending on resolution/clock speed)for 16-bit SDRAM. (that's ignoring refresh overhead and such)
Then you have the inherent advantages of the object processor over a framebuffer/blitter system of generating sprites directly by reading pixels into an internal line buffer (vs copying textures to a feamrbuffer -requiring both reads and writes to external memory for each pixel drawn). Then there's potentially added overhead for color look-up (for indexed textures) or read/write buschange for blitter drawing. (albeit I'm not sure if VDP1 suffers from that as the Jaguar blitter does -if it does have that problem, that could limit it to 3 cycles per pixel peak rather than 2 -and obviously more for page breaks)
But even at best (2 cycles per pixel), that's a theoretical max performance of 13.3 or 14.3 Mpix/s with VDP1 vs 53.2 Mpix/s for the Jag. (and practically less due to page breaks and overhead for reading drawing commands; albeit the OPL in the Jag also has to deal with page breaks and reading the object list)

Hmm, and can't the Jaguar OPL render even faster at lower bit depths? (I assumed 16-bpp for the above context -but 8bpp should be roughly double, 4bpp 4x, etc) Vs the Saturn VDP1, which I don't believe gets a speed benefit when rendering in 8bpp mode, though I'm not positive on that (it might also vary depending on the operation being done, like flat shading or line filling vs gouruad shading or texture mapping); in any case, 8bpp mode limits the entire VDP1 screen to 256 colors vs the OPL being able to vary color depth (and colorspace for that matter) on a per-object basis.

Now, there is the other trade-off of any hardware sprite/blitter/scanline-display-list based system (including character modes) over a blitter+framebuffer of being limited to bandwidth on a per-line basis rather than a per-screen basis, plus a blitter doesn't have to re-draw regions of the frame that haven't changed -though there's overhead involved in sorting "damaged" and undamaged sections. (so games that have heavy bandwidth used only on a relatively small number of scanlines would reduce that advantage considerably, or for cases where large portions of the screen are unchanged from 1 frame to the next) And the issue of flicker/drop-out artifacts vs slowdown/timeouts. (or a blitter based system allowing a game to run at a generally lower framerate, but with more stuff on-screen)

But that doesn't change the fact that a list/object/etc based system will have roughly double the drawing bandwidth of a blitter based system using the same bus. (more so if you include overhead for framebuffer scanning on the blitter system) It's just that that raw power isn't useful in all cases the blitter could make use of its bandwidth. ;)

The Neo Geo had to deal with that trade-off . . . as did all sprite based systems -and tilemaps for that matter. (limited bandwidth per-line, though more like the Jaguar -or panther- for the Neo Geo since it's all sprites with no tile layers -albeit the Jag could use framebuffer/blitter rendered playfields as well, drawn as large/full-screen objects by the OPL)

And that's not getting into multiple blitter playfields. (which the Jaguar could also obviously do -since the BG layers were generated as OPL objects and there's enough RAM to allow several framebuffer planes, especially at lower color depths -albeit a direct trade-off with buffer space for graphics)

Crazyace

11-03-2011, 04:13 AM

I was thinking about this comparison again . . .
Why wouldn't the Jaguar OPL be able to exceed VDP1 (aside from rotation), at least in the context of a CPU-light game (or demo) where graphics would have most bandwidth available?
The OPL has peak bandwidth of 106.4 MB/s in DRAM vs VDP1's 53.7 or 57.3 MB/s (depending on resolution/clock speed)for 16-bit SDRAM. (that's ignoring refresh overhead and such)
Then you have the inherent advantages of the object processor over a framebuffer/blitter system of generating sprites directly by reading pixels into an internal line buffer (vs copying textures to a feamrbuffer -requiring both reads and writes to external memory for each pixel drawn). Then there's potentially added overhead for color look-up (for indexed textures) or read/write buschange for blitter drawing. (albeit I'm not sure if VDP1 suffers from that as the Jaguar blitter does -if it does have that problem, that could limit it to 3 cycles per pixel peak rather than 2 -and obviously more for page breaks)
But even at best (2 cycles per pixel), that's a theoretical max performance of 13.3 or 14.3 Mpix/s with VDP1 vs 53.2 Mpix/s for the Jag. (and practically less due to page breaks and overhead for reading drawing commands; albeit the OPL in the Jag also has to deal with page breaks and reading the object list)

Hmm, and can't the Jaguar OPL render even faster at lower bit depths? (I assumed 16-bpp for the above context -but 8bpp should be roughly double, 4bpp 4x, etc) Vs the Saturn VDP1, which I don't believe gets a speed benefit when rendering in 8bpp mode, though I'm not positive on that (it might also vary depending on the operation being done, like flat shading or line filling vs gouruad shading or texture mapping); in any case, 8bpp mode limits the entire VDP1 screen to 256 colors vs the OPL being able to vary color depth (and colorspace for that matter) on a per-object basis.

The Jaguar OPL max's out at 2 pixels/cycle for normal sprites or 1 pixel / cycle for scaled sprites - which matches the theoretical bandwidth at 16bpp, so no improvement for lower bit depths apart from allowing the possibility of other bus masters. ( Also - are your VDP1 figures correct? )

Now, there is the other trade-off of any hardware sprite/blitter/scanline-display-list based system (including character modes) over a blitter+framebuffer of being limited to bandwidth on a per-line basis rather than a per-screen basis, plus a blitter doesn't have to re-draw regions of the frame that haven't changed -though there's overhead involved in sorting "damaged" and undamaged sections. (so games that have heavy bandwidth used only on a relatively small number of scanlines would reduce that advantage considerably, or for cases where large portions of the screen are unchanged from 1 frame to the next) And the issue of flicker/drop-out artifacts vs slowdown/timeouts. (or a blitter based system allowing a game to run at a generally lower framerate, but with more stuff on-screen)
The OPL is active per line - so for a 192 line NTSC display you've reduced the available bandwidth by a quarter already. When you combine that with the normal 'uneven' pixel distribution in a game screen there is also bandwidth lost on lines where less pixels are drawn. Also, as your object list increases in complexity the line time is reduced ( as it is processed per line compared with per sprite on VDP1 )
You can still have 'drop-out' on VDP1 by killing drawing at 1 frame.

But that doesn't change the fact that a list/object/etc based system will have roughly double the drawing bandwidth of a blitter based system using the same bus. (more so if you include overhead for framebuffer scanning on the blitter system) It's just that that raw power isn't useful in all cases the blitter could make use of its bandwidth. ;)
My point was comparing VDP1 vs Jaguar - the split memory system for VDP1 means that it IS a list/object/etc based system - just one with a frame buffer rather than a line buffer.

The Neo Geo had to deal with that trade-off . . . as did all sprite based systems -and tilemaps for that matter. (limited bandwidth per-line, though more like the Jaguar -or panther- for the Neo Geo since it's all sprites with no tile layers -albeit the Jag could use framebuffer/blitter rendered playfields as well, drawn as large/full-screen objects by the OPL)
Not sure why you mention the Neo Geo ( apart from being a slower example of a line based system )
Once you start using the blitter on the Jaguar you also further reduce the available bandwidth again.

And that's not getting into multiple blitter playfields. (which the Jaguar could also obviously do -since the BG layers were generated as OPL objects and there's enough RAM to allow several framebuffer planes, especially at lower color depths -albeit a direct trade-off with buffer space for graphics)
Even in those cases VDP1 could match up until the point where you hit the 512k limit - and VDP2 would breeze past the capabilities available on the Jaguar ( more pallette entries at 24bit! )

TVC 15

11-03-2011, 08:19 AM

kool kitty89

11-04-2011, 05:18 AM

Actually I qouted a post I found on assembler a while back where a member did some basic dev work on the Saturn, in fact I think you replied to it, doing some basic polygon rendering and the throughput was roughly 22-24 mpixels. Of course the stuff he was doing was very basic and 'best case scenario' drawing some simple quads, I'm sure more advanced operations would bring that count down more, but surely would'nt sprite blitting hit that maximum more so than 3d rendering with the VDP1?
Yes, and that supports my generalized postulation on the VDP1 performance. That figure was for simple solid-shaded quads . . . so no textures, just simple line filling (ie writes to the framebuffer without needing to read/copy -as you would for textures), so the only thing the VDP would be doing is reading commands and writing to the framebuffer.

So that ~22 Mpix is a rather reasonable figure for the theoretical 26.6/28.6 Mpix/s fillrate. (which would only be achieved with zero overhead for command list reads and no wait stares from refresh or page changes)

Sprite/texture rendering requires at least 1 read and 1 write per 16-bit pixel . . . and it might be more if there's waits for read/write bus-change (definitely a factor for the Jaguar blitter) or if color look-up is used. So in a best case (not knowing if there's other added overhead for textures on VDP1), sprites/textures would be 1/2 the speed of solid filled quads. (also ignoring possible differences in drawing list overhead)

Doing translucent blended pixels would definitely take added overhead too. (since you'd need an additional read before each write -and possibly more cycles for the blending operation)

Likewise, the PSX's theoretical peak texture fillrate is 33 Mpix/s (though real-world overhead would make even an optimized demo average somewhat less than that -and a best-case demo would be tiling a 2k cached textured over the entire screen), but simple solid filling would be double that.

Or, for that matter, the Jaguar's blitter could flat shade at close to the same speed as that Saturn demo . . . or gouraud shade for that matter (given how fast the g-shading is on the Jaguar). The Jaguar blitter is rather slow for copying/blitting objects (ie tiles/textures for 2D or especially scaled/rotated textures) but it's very fast for solid filling, line filling, vector line drawing, and gouraud shading. (the slow copying is due to lack of buffering meaning every single read/write for a copy will suffer a page break in DRAM -ie no FPM accesses . . . so 5 cycles per read/write rather than 2 in FPM -and even slower for scaling/rotating/texture mapping since that can only work 1 pixel at a time rather than multiple pixels in a 64-bit read/write)

The Jaguar OPL max's out at 2 pixels/cycle for normal sprites or 1 pixel / cycle for scaled sprites - which matches the theoretical bandwidth at 16bpp, so no improvement for lower bit depths apart from allowing the possibility of other bus masters. ( Also - are your VDP1 figures correct? )
I'm not positive on the actual VDP1 performance figures, but given the 26.6/28.6 MHz VDP/memory clock rates and 16-bit bus, it should be impossible for it to copy textures any better than 13.3/14.3 Mpix/s. (and that performance would only be reached for reads/writes in page mode, ignoring any additional blitter overhead -including things like read/write bus-change)

The OPL is active per line - so for a 192 line NTSC display you've reduced the available bandwidth by a quarter already. When you combine that with the normal 'uneven' pixel distribution in a game screen there is also bandwidth lost on lines where less pixels are drawn. Also, as your object list increases in complexity the line time is reduced ( as it is processed per line compared with per sprite on VDP1 )
You can still have 'drop-out' on VDP1 by killing drawing at 1 frame.
Yes, as I said, bandwidth distributed on a scanline basis rather than a screen basis . . . plus the differences in interframe overhead (blitter has a big advantage if little changes between frames), etc.

It's the same sorts of trade-offs for all sprite vs blitter based systems. (and to some extent character mode vs blitter/framebuffer BG generation)

Hmm, though in that respect, you could make a general argument for a fully blitter-oriented design approach for the Jaguar's performance/concept goals. (ie focusing on designing a powerful and efficient 64-bit blitter with a far more basic VDC for scanning the framebuffer)
Obviously that would have been the way to go for better 3D performance (especially texture mapping -and thus also rotation effects), but with the general trade-offs for a blitter based system over a sprite/object based system in general, there's also a lot in favor of a blitter for pure 2D stuff as well. (I guess that would also apply to the discussion over the Panther -and Slipstream)

Hell, an all-blitter-graphics oriented system would be more of a direct evolution of Flare's slipstream design concept. (and the Lynx -albeit the Lynx/Amiga team did keep with the blitter-only route for the 3DO . . . and that route became dominant in the 3D era)

My point was comparing VDP1 vs Jaguar - the split memory system for VDP1 means that it IS a list/object/etc based system - just one with a frame buffer rather than a line buffer.
Huh? You mean the separate texture memory and frame buffer arrangement?
In that case, you could make a similar argument for any system that used separate framebuffer and graphics/texture/program memory buses/banks. (including the 32x and 3DO -the 32x especially since it uses hardware framebuffer banks that get flipped to the super VDP -vs a single VRAM bank being accessed by the VDC simultaneously)

For that matter, it would be similar to the Jaguar blitter if the 2nd DRAM bank was populated. ;) (and if you put the Jaguar blitter in a similar position as VDP1 -ie a 16-bit bus with single-cycle FPM reads/writes with separate source and destination banks with no contention for framebuffer scanning- . . . and for 2D stuff, the only major disadvantage of the Jag blitter would be lack of color look-up -for that matter, there's the context of the Jag blitter with 2 64-bit banks populated . . . something 100% supported on the existing hardware and probably a lot more cost effective than the Saturn's method, albeit only some things would benefit from being 64-bits wide -texture mapping would be just as much accelerated with a 16-bit bank, since that only works at 1 pixel at a time -and, obviously a blitter with buffering for efficient operation on a single bank would cut costs considerably more -ie no need for 2 populated banks of DRAM chips with double the traces and double the number chips or more depending on densities used)

Once you start using the blitter on the Jaguar you also further reduce the available bandwidth again.
Yes, but that's in the context of the Jaguar as an overall system, not just the performance of the OPL vs VDP1 for sprite generation.

As an overall system, the Saturn obviously has substantial advantages for raw performance in many areas . . . and it pays for that too with the many buses/subsystems, fast/expensive RAM, etc. (the PSX pays for it too, though not quite as extreme -fast/expensive RAM, but still more optimization for fewer buses -though more than the Jag or 3DO . . . and there's the separate issue of Sony's massive advantage of vertical integration)

OTOH, the 3DO didn't really "pay" for added performance like that though . . . it was just a more conservative/less cost effective/"safer" design compared to the Jaguar (larger, older process chips using more silicon to hold less/slower logic than the Jag ASICs, and using more and more expensive RAM -namely the VRAM- and the added CD drive obviously contributing to cost) . . . though that's a big apples and oranges comparison too given the market model used for the 3DO with huge margins compared to other consoles of 1993/94. (plus, that chipset could have been consolidated later on . . . still not as efficient as a heavily buffered unified bus architecture, but a 3DO marketed in a reazor-blader manner from the start and further cost reduced with consolidated board/chipset revisions later on should have allowed it to undercut Sony/Sega's pricing without taking major losses -after all, it was still using cheap/slow FPM DRAM for main memory, relatively slow VRAM, less overall RAM than the PSX -let alone Saturn, a small low-cost embedded CPU, and had been in production longer . . . though the Jaguar should have been cheaper still, even with a CD drive, at least if it had done well enough to manage efficient production volumes -ie in the millions per year)

and VDP2 would breeze past the capabilities available on the Jaguar ( more pallette entries at 24bit! )
Yes, VDP2 would be a different matter . . . for one thing it has more bandwidth than the OPL would if saturating the bus (114.4 MB/s . . . or the same peak bandwidth at 26.6 MHz), but then there's the inherent advantages for BG generation with VDP2 (and the indexed color advantages -and alpha blending, full-screen rotation/warping, etc).
Albeit that's if you're comparing BG generation capabilities alone . . . and for games that cater to VDP2's capabilities. Obviously you couldn't have much of a game with VDP2 doing the graphics alone (vs the OPL, where you could do that) . . . or for games where highly segmented BGs are used with little catering to full-screen layers. (which would obviously be the case for some Neo Geo ports . . . or similarly styled games of that nature -albeit a blitter would have an advantage for those types of games too . . . or the PSX vs Saturn for that matter -games where VDP1 might choke and VDP2 would be underutilized)

Crazyace

11-04-2011, 07:49 AM

Chilly Willy

11-04-2011, 01:44 PM

The 32X uses a FIFO for reading/writing the frame buffer. So you can read from the cache/SDRAM/cart at the same time a write to the frame buffer is pending in the FIFO. I would expect VDP1 was setup similarly, so it SHOULD be able to read from a texture/sprite while writes to the frame buffer are pending in a FIFO, meaning you SHOULD be able to get the same fill rate as a plain fill operation. SEGA was good about using FIFOs like that to get slightly better performance from hardware.

kool kitty89

11-05-2011, 04:42 AM

VDP1 has 3 seperate sets of address/data pins going to the 3 ram chips - so it's not a single bus, and should support simultaneous read/write operations. ( That's why I compare it to the OPL on Jaguar, rather than a blitter system which would be issueing read/writes sequentially )
Hmm, I knew framebuffer and texture RAM were on separate buses, but I didn't realize they could be simultaneously accessed by the VDP. (I assumed it switched between the 2 via a shared set of address/data lines -like the 32x CPUs do)

If VDP1 was pipelined to allow writes to the framebuffer while fetching the next textel, that would certainly boost texture fill rate to similar speed as plain line filling (and perhaps faster than gouraud shading -depending on what logic was dedicated to that).
So a lot faster than I was thinking. (and also a much better match for the PSX GPU, for that matter -and could probably have made for a quite nice 2D engine for the time even without VDP2 . . . and obviously similarly capable in 3D as it already is)

Hmm, I wonder if the 3DO supports that too . . . that would be a much better use of the separate source and destination buses (VRAM for the framebuffer and shared DRAM for textures), or for that matter if it has 32-bit source and destination buffers to take advantage of the full bus width (or at least a destination buffer). In the 3DO's case, the max fillrate (with FPM and 32-bit optimizations) would be 25 Mpix/s for 16-bit pixels. (not sure of the actual 3DO texture performance though)

It's also odd that VDP1 would have separate buses for both framebufer banks though, since it would only be accessing 1 per-frame (with VDP2 accessing the other) . . . unless VDP1 also contains the bus-steering logic to flip the banks between VDP1 and VDP2 (except that would require an additional set of address/data lines to connect to VDP2 . . . though since it should just be scanning a linear framebuffer, that could be limited to a serial pixel bus -somewhat like VRAM uses)

I found this quite interesting ( Saturn schematic )

http://www.geocities.jp/atx197/Ssmn052S1_10.pdf

along with a datasheet for the ram - which is SDRAM for VDP1 frame buffers.

http://www.datasheetarchive.com/HM5221605TT-17-datasheet.html

seems to show single cycle burst writes...
Hmm, interesting, especially the dual bank support (which would make that slightly closer to SGRAM in some respects -except the banks are fixed, so more like 2 separate 128k chips with interleaving . . . which would also explain the odd 2Mbit density). That should mean the 32x could get a significant performance boost from having the master and slave SH2s work mostly in separate 128k banks of SDRAM (reducing page breaks).

The speed ratings confirm my previous knowledge on the Saturn/32x SDRAM . . . much faster rated speed than the system was actually clocked at. (in that respect, a single bus using the same SDRAM chips clocked at double the VDP speed could have performed similarly to the separate buses -assuming source/destination were still interleaved as separate banks . . . or double the current bandwidth if used at full speed and with simultaneous accessed on separate buses)

The 32X uses a FIFO for reading/writing the frame buffer. So you can read from the cache/SDRAM/cart at the same time a write to the frame buffer is pending in the FIFO. I would expect VDP1 was setup similarly, so it SHOULD be able to read from a texture/sprite while writes to the frame buffer are pending in a FIFO, meaning you SHOULD be able to get the same fill rate as a plain fill operation. SEGA was good about using FIFOs like that to get slightly better performance from hardware.
In this case, it should be a good bit more than slightly more, but potentially double the performance.

The 32x example is limited since the framebuffers are quite slow in general, and the CPUs wouldn't be reading and writing pixels simultaneously even if the buffers were at SDRAM speed. (ie you wouldn't even be able to do block copy faster than 11.5 M words/s)

TmEE

11-05-2011, 06:12 AM

Crazyace

11-05-2011, 07:42 AM

Hmm, I knew framebuffer and texture RAM were on separate buses, but I didn't realize they could be simultaneously accessed by the VDP. (I assumed it switched between the 2 via a shared set of address/data lines -like the 32x CPUs do)

If VDP1 was pipelined to allow writes to the framebuffer while fetching the next textel, that would certainly boost texture fill rate to similar speed as plain line filling (and perhaps faster than gouraud shading -depending on what logic was dedicated to that).
So a lot faster than I was thinking. (and also a much better match for the PSX GPU, for that matter -and could probably have made for a quite nice 2D engine for the time even without VDP2 . . . and obviously similarly capable in 3D as it already is)
It makes sense if you think of VDP1 as a souped up arcade sprite board ( system X or Y ) with good performance for scaled sprites - general performance would depend on the page break penalty ( or half of it given that the SDRAM supports 2 open banks )

Hmm, I wonder if the 3DO supports that too . . . that would be a much better use of the separate source and destination buses (VRAM for the framebuffer and shared DRAM for textures), or for that matter if it has 32-bit source and destination buffers to take advantage of the full bus width (or at least a destination buffer). In the 3DO's case, the max fillrate (with FPM and 32-bit optimizations) would be 25 Mpix/s for 16-bit pixels. (not sure of the actual 3DO texture performance though)
Haven't looked into the 3DO for a long long time - what width was the VRAM? ( and how fast was it clocked ) - I remember some comments about 2 render engines to speed things up, but everything was high level.

It's also odd that VDP1 would have separate buses for both framebufer banks though, since it would only be accessing 1 per-frame (with VDP2 accessing the other) . . . unless VDP1 also contains the bus-steering logic to flip the banks between VDP1 and VDP2 (except that would require an additional set of address/data lines to connect to VDP2 . . . though since it should just be scanning a linear framebuffer, that could be limited to a serial pixel bus -somewhat like VRAM uses)
Again it makes sense if you think of VDP1 as a arcade sprite part - supporting rotated scan out of the frame buffer to display rather than rotating when drawing.

Hmm, interesting, especially the dual bank support (which would make that slightly closer to SGRAM in some respects -except the banks are fixed, so more like 2 separate 128k chips with interleaving . . . which would also explain the odd 2Mbit density). That should mean the 32x could get a significant performance boost from having the master and slave SH2s work mostly in separate 128k banks of SDRAM (reducing page breaks).
I read it as supporting two open banks at once which would be useful for speeding up copying memory in general. Obviously it's a ram feature, so dependant on the controller. ( Also why the reference to the 32X - this is the chip on VDP1 )

The speed ratings confirm my previous knowledge on the Saturn/32x SDRAM . . . much faster rated speed than the system was actually clocked at. (in that respect, a single bus using the same SDRAM chips clocked at double the VDP speed could have performed similarly to the separate buses -assuming source/destination were still interleaved as separate banks . . . or double the current bandwidth if used at full speed and with simultaneous accessed on separate buses)
Page breaks would still be the same if the clock was higher though I guess.

Chilly Willy

11-05-2011, 02:07 PM

The 32x example is limited since the framebuffers are quite slow in general, and the CPUs wouldn't be reading and writing pixels simultaneously even if the buffers were at SDRAM speed. (ie you wouldn't even be able to do block copy faster than 11.5 M words/s)

Which is why I said reading from cache/SDRAM/cart. :D Reading from the frame buffer is slower than writing it, but faster than reading uncached SDRAM or about the same speed as reading the cart. So it would be beneficial in some cases to use frame buffer memory for storing data. That would be more useful with 256 color displays than 16-bit color as the latter takes most of the frame buffer. As an example, cell data for a 2D game would not be a good thing to store as you would be constantly reading/writing the frame buffer at the same time, but name table data (to use the MD term) would be fine as you wouldn't be reading that data at the same time you are trying to write the frame buffer.

Da_Shocker

11-05-2011, 10:58 PM

So I know this system flopped bigger than the 32X and VB but has anyone played the Apple Bandai Pippin before?

Chilly Willy

11-05-2011, 11:24 PM

So I know this system flopped bigger than the 32X and VB but has anyone played the Apple Bandai Pippin before?

I've got the closest thing to it - a Performa 5200CD. :D

Da_Shocker

11-05-2011, 11:31 PM

I've got the closest thing to it - a Performa 5200CD. :D

LOL those were more advanced than the LC 2 and 3. I remember the ole IIe or whatever they're called we used them from 1st-6th grade. Then we the LC's in 7th grade and there were so advanced and shit.

Chilly Willy

11-06-2011, 01:47 AM

LOL those were more advanced than the LC 2 and 3. I remember the ole IIe or whatever they're called we used them from 1st-6th grade. Then we the LC's in 7th grade and there were so advanced and shit.

It was basically a Quadra 605 with the 68040 replaced by a PPC603 and some cache. It wasn't a BAD machine... for the time. The best thing about it was the video card - it had RF/svideo/composite inputs, a remote, and could capture video. It ran in YUYV mode for better quality than the previous Apple video cards. I used to digitize my video tapes using it. It wasn't very good for 3D - no hardware acceleration and the 603 wasn't any better than a Pentium for software 3D.

kool kitty89

11-07-2011, 03:36 AM

Multiple buses are done so there could be parallel accesses happen. VRAM is read and written to one of the framebuffers, while other framebuffer is read by the other VDP and shown along with BG stuff.
Yes, I already knew that . . . having hardware flipped framebuffer banks eliminates contention (like the 32x framebuffers or MCD word RAM in flip-flop 1M mode) and does so without needing dual-port memory (3DO does similarly using VRAM). Having separate buses for source and destination also allows use of fast page mode copying without extensive on-chip buffering (something the 3DO also takes advantage of), though having a single bus with bank interleaving (to allow 1 page to be held open in each bank) also allows that. (something the Jaguar supported -and used for the ROM/RAM banks, though also supported a 2nd DRAM bank which wasn't populated for cost reasons -the CoJag used VRAM in that bank)

However, what I had failed to consider was the possibility of reading and writing to both buses on the same VDP clock cycle. (and using buffering -ie FIFOs- to pipeline texture rendering would certainly facilitate that . . . and technically they could even have clocked the memory at 2x the VDP speed with 32-bit read/write buffers -even more so if those buffers could be configured as either 16 or 8-bit words to double the speed of 8-bit mode; that would have been much more efficient use of the already fast-rated SDRAM, and would have made VDP1 considerably faster than the PSX GPU . . . for that matter, they could have done the same for CPU memory on the 32x, with memory at 46 MHz and a 32-bit latch to allow 23 MHz 32-bit reads . . . or to reduce cost on the Saturn's main memory by using narrower SDRAM chips at 2x speed and a latch to make use of the bandwidth -Atari was actually considering doing that for the Jaguar II since SDRAM was becoming cheaper by that point and a 16-bit bus at 66.67 MHz would allow roughly the same bandwidth as 64-bit FPM DRAM at 16.67 MHz . . . or slightly more due to reduced wait states)

And, again, I wonder if the 3DO takes advantage of parallel reads/writes . . . actually, in that case the GPU (Cel Engine) is clocked at 2x the bus speed (80 ns FPM DRAM and VRAM), so it wouldn't even necessarily be using FIFOs, but rather doing reads (to DRAM) on 1 cycle and writes (to VRAM) on the next. (sort of like what the MD's VDP DMA does with ROM at 1/2 the speed of the VDP, except VRAM isn't at 1/2 speed too)
I'm not sure how much actual buffering the 3DO has (let alone for different drawing modes), but with the separate buses for textures and framebuffer (and dual-port VRAM cutting out any contention for framebuffer scanning), and with 32-bit wide 80 ns RAM, the 3DO's Cel Engine could potentially push 16bpp textures at 25 Mpix/s peak (which would be fairly close to the Saturn or PSX). Albeit there's the issue of CPU/GPU contention for main RAM (where textures are stored) and the lack of a CPU cache (and a relatively slow CPU in general) greatly exacerbating the issue. Plus that's just the potential that the RAM would allow . . . I'm not sure if the Cel can actually do that. (though having that sort of parallel rendering would make the separate bus for textures much more sensible -otherwise they could have had the Cel work on the video bus alone with 2 interleaved banks with a DRAM texture buffer and VRAM framebuffer -so no parallel reads/writes, but still using FPM bandwidth- . . . or dropped the VRAM entirely in favor of DRAM framebuffer banks more like the 32x -for that matter, having 1 MB of VRAM as a glorified framebuffer was rather excessive for the 3DO in general . . . 512k should have been fine for the time, or 256k at a consrvative minimum -though given the deluxe nature of the 3DO, 512k would make more sense . . . 256k would only allow 320x204 16bpp double buffered or 288x224, and you'd need 450k to double buffer 320x240x24-bpp -ie for VCD support, or potentially for Truecolor FMV . . . the only thing you'd need 1 MB for is 640x480 truecolor still images)

It makes sense if you think of VDP1 as a souped up arcade sprite board ( system X or Y ) with good performance for scaled sprites - general performance would depend on the page break penalty ( or half of it given that the SDRAM supports 2 open banks )
It seems more like an evolution of the MCD's ASIC/blitter . . . did the X/Y boards even use framebuffers? (they had no support for sprite rotation/warping -if they had had simple affine mapping like the MCD ASIC, that could have made for some interesting 3D/Pseudo 3D games beyond the scaled sprite stuff)

My problem was I just hadn't considered parallel reads/writes to both buses on the same VDP clock cycle, but again, that makes the use of independent buses for source and destination much more sensible. (otherwise you could just use 2 separate/interleaved banks on a shared bus for lower cost/complexity -like the Jaguar supported for ROM and the 2nd DRAM bank)

Haven't looked into the 3DO for a long long time - what width was the VRAM? ( and how fast was it clocked ) - I remember some comments about 2 render engines to speed things up, but everything was high level.
I'm not sure how much low-level documentation was ever available for the 3DO (after all, developers had to use 3DO's libraries alone . . . so any such documentation would have had to been leaked separate from official dev manuals).
However, from what I recall seeing (and some comments from Kskunk), the 3DO used 80 ns 32-bit FPM DRAM for main RAM and 80 ns 32-bit VRAM for the framebuffer (I believe 4 512kx8-bit chips for main and 2 256x16-bit dual port VRAMs)

Albeit, texture mapping rates in tech demos/benchmarks for the 3DO (or quoted textels/s figures) should shed some light on the 3DO's peak texture bandwidth.

If it didn't do parallel reads/writes, using separate buses for source/destination would have been rather wasteful (since 2 banks on the same bus would give the same bandwidth)

Again it makes sense if you think of VDP1 as a arcade sprite part - supporting rotated scan out of the frame buffer to display rather than rotating when drawing.
No, I mean it's odd that VDP1 has traces that connect separate address/data lines to each of the framebuffers rather than a single set of address/data lines that connects to a middle man (buss steering chip) that sits between VDP1 and VDP2. (unless VDP1 has that logic built into itself and has access ports connecting to VDP2)

I wasn't surprised that the 2 framebuffers were flipped between 2 buses . . . that's pretty obvious: 1 RAM bank is on VDP2's bus while the other is on VDP1's (just like the 32x framebuffers or MCD word RAM in flip-flop mode)

I read it as supporting two open banks at once which would be useful for speeding up copying memory in general. Obviously it's a ram feature, so dependant on the controller. ( Also why the reference to the 32X - this is the chip on VDP1 )
Yes, so similar to having 2 separate 64kx16-bit SDRAMs, but with 1/2 the board space/traces needed. (and not so much like SGRAM, since that allows 2 pages to be opened anywhere in the chip -not just 2 distinct banks)
So, again, rather like the Jaguar's bank interleaving.

And, again, since the 32x uses the same 128kx16-bit SDRAM, that could mean a performance boost if the master/slave SH2s kept mostly to separate 128k banks. (fewer page breaks)
Hmm, for that matter, it would mean less buffering was needed for the way SDRAM was used in the Genesis 3. (a single 128kx16-bit SDRAM chip was used in place of 68k work RAM -normally 32kx16-bit PSRAM- and VRAM -normally 64kx8-bitx2 port VRAM- . . . and while a single 16-bit SDRAM chip could potentially provide enough bandwidth to cover both of those buses seamlessly, it would require much less buffering if said chip had 2 banks allowing 1 page to be held open in each)

Page breaks would still be the same if the clock was higher though I guess.
I was thinking in terms of having 32-bit latches/buffers for reads/writes . . . so for page mode accesses, a 32-bit read/write (on a double speed 16-bit bus) would be just as fast as a 16-bit read/write on the normal speed equivalent (albeit only useful when reading/writing 32-bits -or 2 consecutive 16-bit words or 4 consecutive bytes).
Now, for cases of page breaks, you already have the separate buses (and 2 banks per SDRAM chip) to greatly reduce that overhead, but the 32-bit reads/writes themselves would still roughly double bandwidth even with page changes. (since the 2nd 16-bit word read will always been an FPM access and only 1/2 a VDP clock cycle, so rowchange+read+read -or write+write)

Actually, having double clocked RAM might even speed things up for plain 16-bit reads/writes due to faster RAM cycle times allowing fewer wait states for random (non page mode) accesses. Having DRAM clocked at 57.3/53.7 MHz vs 28.6/26.6 MHz might make the difference of 3 vs 4 cycles for random access memory cycle times . . . actually, it might get it down to 2 VDP cycles. (I'd have to see the actual SDRAM cycle times for those speeds) For that matter, it might even be able to squeeze 1 random access + 1 page mode access (ie for a 32-bit read/write) into 2 VDP clock cycles.

Hmm, and unless you optimized for 8-bpp rendering, you'd only ever need to deal with 2 pixels at a time (for 32-bit reads/writes), so you still would avoid needing to read the framebuffer before a write (if 1 of the 2 pixels being written is transparent, just do a single 16-bit write), though you'd need to read the framebuffer for translucent blending effects.

Which is why I said reading from cache/SDRAM/cart. :D Reading from the frame buffer is slower than writing it, but faster than reading uncached SDRAM or about the same speed as reading the cart. So it would be beneficial in some cases to use frame buffer memory for storing data. That would be more useful with 256 color displays than 16-bit color as the latter takes most of the frame buffer. As an example, cell data for a 2D game would not be a good thing to store as you would be constantly reading/writing the frame buffer at the same time, but name table data (to use the MD term) would be fine as you wouldn't be reading that data at the same time you are trying to write the frame buffer.
Reads from SDRAM are slower than the framebuffer?
By "uncached", I assume you mean non-sequential (ie non page mode) accesses to SDRAM . . . so comparing that to best case (page mode) accesses to framebuffer DRAM (which is at 7.67 MHz - so 3 SH2 clocks for a complete FPM read or write), that would mean SDRAM takes 4 cycles for a random access? (I can't imagine it being any slower than that, since that's already 173.8 ns . . .)

However, you didn't mention cached/sequential reads to the framebuffer . . . so are you implying page-mode DRAM reads, or not? (since random accesses of 7.67 MHz -130 ns- FPM DRAM should be somewhere around 230 ns . . . or 6 SH2 cycles -though I think Tiido mentioned that worst-case access time for the framebuffer was 7 cycles)

Chilly Willy

11-07-2011, 01:05 PM

Reads from SDRAM are slower than the framebuffer?
By "uncached", I assume you mean non-sequential (ie non page mode) accesses to SDRAM . . . so comparing that to best case (page mode) accesses to framebuffer DRAM (which is at 7.67 MHz - so 3 SH2 clocks for a complete FPM read or write), that would mean SDRAM takes 4 cycles for a random access? (I can't imagine it being any slower than that, since that's already 173.8 ns . . .)

However, you didn't mention cached/sequential reads to the framebuffer . . . so are you implying page-mode DRAM reads, or not? (since random accesses of 7.67 MHz -130 ns- FPM DRAM should be somewhere around 230 ns . . . or 6 SH2 cycles -though I think Tiido mentioned that worst-case access time for the framebuffer was 7 cycles)

The SDRAM is set to do burst reads, and non-burst writes. A burst read fetches 8 words in 12 cycles - REGARDLESS of cached or uncached. When doing a cached read, the eight words exactly fill one cache line. When doing an uncached read, the one word required is used and the other seven are discarded. So reading a word in uncached mode takes 12 cycles! Reading a long takes 24 cycles!! So when using uncached memory for cross SH2 communications, use WORDS whenever possible. In some cases, flushing the caches and then doing cached reads will be much faster than using uncached memory.

The non-burst write takes 2 cycles to write a word to SDRAM and is the same for cached or uncached.

The frame buffer uses non-burst reads and writes, but has to wait on the FIFO because the DRAM used for the frame buffer is slower than the SH2. If the FIFO is empty, it takes 3 cycles to write a word; if it's full, it takes 5 cycles. So when copying large blocks to the frame buffer, the average time to write a word is 5 cycles. So doing "stuff" between writes to the frame buffer makes better use of CPU time as you can do things while waiting for the FIFO to empty. Reading the frame buffer takes 6 cycles minimum, and 13 max. Writing being faster than reading is common where frame buffers are concerned. It gets ludicrously lopsided on many PC cards with writing being in the GBytes/sec while reading is in the low MBytes per second. 1000:1 seems absurd, but that's the way they are.

Non-burst cycles are the same regardless of cached or uncached - they use single random cycles with optional waits. It's only burst transfers that have such a lopsided difference between cached and uncached as explained above.

Crazyace

11-07-2011, 04:34 PM

It seems more like an evolution of the MCD's ASIC/blitter . . . did the X/Y boards even use framebuffers? (they had no support for sprite rotation/warping -if they had had simple affine mapping like the MCD ASIC, that could have made for some interesting 3D/Pseudo 3D games beyond the scaled sprite stuff)
The Arcade boards had scaled sprites - and then rotation of the sprite buffer on scanout ( for galaxy force ) - which is one of the VDP1 features. Look at the mame source ( video\segaic16.c ) it talks about frame buffer sprites starting with the Outrun boards.

I'm not sure how much low-level documentation was ever available for the 3DO (after all, developers had to use 3DO's libraries alone . . . so any such documentation would have had to been leaked separate from official dev manuals).
However, from what I recall seeing (and some comments from Kskunk), the 3DO used 80 ns 32-bit FPM DRAM for main RAM and 80 ns 32-bit VRAM for the framebuffer (I believe 4 512kx8-bit chips for main and 2 256x16-bit dual port VRAMs)

Albeit, texture mapping rates in tech demos/benchmarks for the 3DO (or quoted textels/s figures) should shed some light on the 3DO's peak texture bandwidth.

If it didn't do parallel reads/writes, using separate buses for source/destination would have been rather wasteful (since 2 banks on the same bus would give the same bandwidth)

It was specced at 50MBytes/second ( 12.5MHz@32bit ) with 9-16MPixels peak fillrate - Interesting limitation less than your 25MPixel cap. ( I wonder if the 2 renderers work on seperate lines and combine into 32bit writes as much as possible )

kool kitty89

11-07-2011, 10:12 PM

The Arcade boards had scaled sprites - and then rotation of the sprite buffer on scanout ( for galaxy force ) - which is one of the VDP1 features. Look at the mame source ( video\segaic16.c ) it talks about frame buffer sprites starting with the Outrun boards.
The only rotation I know of was full layer rotation (several Sega Arcade boards supported a sprite plane that could be rotated -but never on a per-sprite basis, and always with an additional non-rotated sprite plane . . . and usually additional text/character planes)

It was specced at 50MBytes/second ( 12.5MHz@32bit ) with 9-16MPixels peak fillrate - Interesting limitation less than your 25MPixel cap. ( I wonder if the 2 renderers work on seperate lines and combine into 32bit writes as much as possible )
The 25 Mpix comment was for theoretical peak throughput for block copy of 16-bit pixels. (with no added waits between reads and writes)
16 Mpix/s would correspond to 3 25 MHz cycles per 32-bit write . . . so there's an added cycle for something there. (possibly a read to the framebuffer prior to the write -though, again, since you'd only ever write a single pixel or a consecutive pair at any time -simply not writing transparent pixels, that step could be avoided anyway -aside from doing blending effects-)

I'd imagine simple block/line filling would be done at closer to 1 clock per 16-bit pixel.

In any case, that figure is close enough that it would have been reasonably competitive with the PSX/Saturn graphics bandwidth . . . if not for the CPU contention issue. (and overall CPU performance limiting things even further -and shared audio bandwidth having some impact too) And, of course, the limitation of programming only to 3DO's libraries also limited potential performance.

On another note, looking at the hitachi SDRAM datasheet, the double clocked SDRAM idea wouldn't have been possible at all it seem. It lists the max system clock cycle time as 30/34/40 ns (for the 3 grades listed -66 MHz, 58 MHz, and 50 MHz), so the RAM Sega was using was already being pushed to the rated speed. (the clock speeds are 2x the data/bus rates . . . which is how most/all DRAM -and DRAM controllers- are clocked . . . thus the RAM in question would be 30/34/40 ns DRAM -so similar in speed to commonly available EDO DRAM at the time, though with the other performance advantages of SDRAM -and easier interfacing, plus the dual bank for these specific chips)

Oh, and it seem that random accesses to SDRAM can already be done in 2 VDP/CPU cycles . . . especially given Chilly Willy's comment on 32x SDRAM timing.

The SDRAM is set to do burst reads, and non-burst writes. A burst read fetches 8 words in 12 cycles - REGARDLESS of cached or uncached. When doing a cached read, the eight words exactly fill one cache line. When doing an uncached read, the one word required is used and the other seven are discarded. So reading a word in uncached mode takes 12 cycles! Reading a long takes 24 cycles!! So when using uncached memory for cross SH2 communications, use WORDS whenever possible. In some cases, flushing the caches and then doing cached reads will be much faster than using uncached memory.
Hmm, and these are all SH2 clock cycles?

That would mean 1.5 SH2 (23.01 MHz) cycles per burst read to FPM DRAM . . . which would be 65.19 ns read cycle times, which would mean that RAM is definitely not clocked at 7.67 MHz as Tiido implied a while back, but almost certainly at 15.34 MHz (ie 2x the MD clock rate) . . . though that would technically be overclocking the 80 ns FPM DRAM they used. (though certainly well within the capabilities of FPM DRAM grades in common use at the time -which went up to 45 ns)
Err. . . technically the DRAM would be 2x all of those clock rates listed above (as would the DRAM controller), though the FPM/burst read/write cycle times (and effective bus speed) would be the rates I listed.

The non-burst write takes 2 cycles to write a word to SDRAM and is the same for cached or uncached.
That's quite good . . . only 87 ns for a random (non-page-mode) read/write.

Chilly Willy

11-08-2011, 01:28 AM

Hmm, and these are all SH2 clock cycles?

Yes.

That would mean 1.5 SH2 (23.01 MHz) cycles per burst read to FPM DRAM . . . which would be 65.19 ns read cycle times, which would mean that RAM is definitely not clocked at 7.67 MHz as Tiido implied a while back, but almost certainly at 15.34 MHz (ie 2x the MD clock rate) . . . though that would technically be overclocking the 80 ns FPM DRAM they used. (though certainly well within the capabilities of FPM DRAM grades in common use at the time -which went up to 45 ns)

Errr - the main memory is SDRAM, not FPM DRAM. It's connected directly to and controlled by the SH2(s). It's all handled by the SH2 bus controller. You might want to look at the SH2 hardware manual to see how burst and non-burst SDRAM bus cycles are handled exactly.

The frame buffer is DRAM. That could be clocked using some multiple of the MD clock since it's writable by both the SH2 (through the control chip through a FIFO), or by the 68000.

Crazyace

11-08-2011, 02:23 AM

The only rotation I know of was full layer rotation (several Sega Arcade boards supported a sprite plane that could be rotated -but never on a per-sprite basis, and always with an additional non-rotated sprite plane . . . and usually additional text/character planes)
Yes - that's the rotation I'm referring to. It's really superflous if you have full rotation in drawing, but is still present in VDP1/VDP2 - which is why I treat VDP1 as an extended version of the system Y sprite board with added gourard shading/general quad texturing.

The 25 Mpix comment was for theoretical peak throughput for block copy of 16-bit pixels. (with no added waits between reads and writes)
16 Mpix/s would correspond to 3 25 MHz cycles per 32-bit write . . . so there's an added cycle for something there. (possibly a read to the framebuffer prior to the write -though, again, since you'd only ever write a single pixel or a consecutive pair at any time -simply not writing transparent pixels, that step could be avoided anyway -aside from doing blending effects-)
Does the 3D0 have a 25MHz clock - it doesn't make sense - a 12.5MHz clock matches the cpu clock and memory bandwidth better.

In any case, that figure is close enough that it would have been reasonably competitive with the PSX/Saturn graphics bandwidth . . . if not for the CPU contention issue. (and overall CPU performance limiting things even further -and shared audio bandwidth having some impact too) And, of course, the limitation of programming only to 3DO's libraries also limited potential performance.
Not sure about that - it's better than the Jaguar though :)

kool kitty89

11-08-2011, 04:00 AM

Errr - the main memory is SDRAM, not FPM DRAM. It's connected directly to and controlled by the SH2(s). It's all handled by the SH2 bus controller. You might want to look at the SH2 hardware manual to see how burst and non-burst SDRAM bus cycles are handled exactly.
Oh, I misread part of your previous post as commenting on the framebuffer DRAM rather than SDRAM . . . (the 8 words in 12 cycles would make much more sense for a burst SDRAM access, though I'd have thought it would be a bit less than that -like 9 or 10 cycles for 8 words accessed in the same page . . . 9 cycles assuming the first read took 2 cycles and the other 7 took 1 cycle each)

The frame buffer is DRAM. That could be clocked using some multiple of the MD clock since it's writable by both the SH2 (through the control chip through a FIFO), or by the 68000.
OK, but you implied that reading from the framebuffer is sometimes faster than reading from SDRAM:

Reading from the frame buffer is slower than writing it, but faster than reading uncached SDRAM or about the same speed as reading the cart. So it would be beneficial in some cases to use frame buffer memory for storing data.

So how would read times compare in this case?

TmEE

11-08-2011, 04:18 AM

(You mention my name too much haha I definitely have not given any 32X clock cycles)

Chilly Willy

11-08-2011, 12:39 PM

OK, but you implied that reading from the framebuffer is sometimes faster than reading from SDRAM:

So how would read times compare in this case?

I mentioned that in the previous post: reading the frame buffer takes 6 to 13 cycles. So at best case it is twice as fast as uncached SDRAM reads, and at worst case it is virtually the same speed. So on average, reading the frame buffer will be faster than reading uncached SDRAM. When compared to reading the cart, assuming little bus contention, it will be roughly the same speed... probably just a little slower on average. Bus contention can really slow things down. The main source of bus contention is actually the 68000. If you try to run the 68000 on code in the cart, it can bring the 32X almost to a halt. My first working version of Wolf32X left the 68000 running in rom - it was slooooooooooooooooooooow! Moving the main 68000 loop to work ram made it at least 10 times as fast. If you are going to use the 68000 on rom code, you need the SH2's acting more like coprocessors - put their code into the cache and have them working on the SDRAM/frame buffer without accessing the rom.

So the speed all comes down to how you designed the game: If you use the SH2 to run the game, keep the 68000 out of the rom as much as possible; if you use the 68000 to run the game, keep the SH2s out of the rom as much as possible.

kool kitty89

11-08-2011, 08:19 PM

(You mention my name too much haha I definitely have not given any 32X clock cycles)
You never mentioned specifics on 32x cycle times, but you did point out the actual external clock rates being fed to various chips with a simplified schematic of the 32x. (apparently from the developer's manual)

Albeit, that technically only provides the external clock rates, so internal clock rates could vary more. (though re-reading what chilly willy wrote, 7.67 MHz for the framebuffer bus would make perfect sense, albeit the VDP would definitely need to scan it in page-mode to read the necessary bandwidth for 16bpp mode)

I mentioned that in the previous post: reading the frame buffer takes 6 to 13 cycles. So at best case it is twice as fast as uncached SDRAM reads, and at worst case it is virtually the same speed. So on average, reading the frame buffer will be faster than reading uncached SDRAM. When compared to reading the cart, assuming little bus contention, it will be roughly the same speed... probably just a little slower on average.
Ah, I missed that too . . . and with 6 cycles being the fastest (or 5 cycles for sustained writes through the FIFO), then 7.67 MHz would make sense.

The SDRAM is set to do burst reads, and non-burst writes. A burst read fetches 8 words in 12 cycles - REGARDLESS of cached or uncached. When doing a cached read, the eight words exactly fill one cache line. When doing an uncached read, the one word required is used and the other seven are discarded. So reading a word in uncached mode takes 12 cycles! Reading a long takes 24 cycles!! So when using uncached memory for cross SH2 communications, use WORDS whenever possible. In some cases, flushing the caches and then doing cached reads will be much faster than using uncached memory.

The non-burst write takes 2 cycles to write a word to SDRAM and is the same for cached or uncached.
Huh, so the SDRAM memory interface is only really set-up for burst reads . . . it has to fetch 8 words regardless of how many words you actually want to access?
That obviously heavily hurts single byte/word/long reads considerably, but also (more moderately) hurts longer sustained reads from within the same page. (since you have to break up burst into 8 word segments rather than there just being 1 read with rowchange overhead and the res being pure fast-page reads -ie single cycles in this case)

That defeats some of the advantages of using SDRAM . . . even cheap FPM DRAM at 1/2 the SH2 clock rate should manage 1 random read/write in 5 cycles with all consecutive (FPM) READs/writes being 2 cycles each with 1 additional cycle to change between reads and writes. (which is exactly what the Jaguar does, albeit at a higher clock speed than the 32x -I'd hope the Saturn did that for Low-RAM too . . . otherwise that would be even slower than I'd though)
Or, for a more direct comparison: 43 ns EDO DRAM should have managed 3 cycles per random access and 1 cycle for sustained page-mode accesses. (or in the case of reading 8 words, it should be 10 cycles . . . and more advantageous for longer sustained reads or writes -you'd obviously want to organize textures and other block data along page boundaries as much as possible)

The frame buffer uses non-burst reads and writes, but has to wait on the FIFO because the DRAM used for the frame buffer is slower than the SH2. If the FIFO is empty, it takes 3 cycles to write a word; if it's full, it takes 5 cycles. So when copying large blocks to the frame buffer, the average time to write a word is 5 cycles. So doing "stuff" between writes to the frame buffer makes better use of CPU time as you can do things while waiting for the FIFO to empty. Reading the frame buffer takes 6 cycles minimum, and 13 max. Writing being faster than reading is common where frame buffers are concerned. It gets ludicrously lopsided on many PC cards with writing being in the GBytes/sec while reading is in the low MBytes per second. 1000:1 seems absurd, but that's the way they are.
Slow accesses on any DRAM system would tend to be from lack of page-mode read/write support (which could be a limit of interfacing or from contention from other bus masters that must access the bus at regular intervals).

The discrepancy for modern DRAM types has become far more extreme since page-accesses are extremely fast while full random accesses (requiring row change) has barely changed since the 80s. (it's certainly faster too . . . at ~10x faster than DRAM of the early/mid 80s or ~3x faster than from the mid 90s, but nowhere near the gain in page-mode accesses)
And it's obviously even worse if the interface is configured for fixed burst transfer sizes. (like in the case of 32x SDRAM)

But for a specific example: a 64-bit wide 800 MT/s bus (6.4 GB/s peak bandwidth) would drop to roughly 160 MB/s for plain random 64-bit accesses. (ie bypassing all the caching/buffering/multi-bank interleaving/etc that's designed to sustain page accesses as much as possible)

Well . . . unless you had DRAM that had every single word in a separate page, but then you wouldn't have traditional DRAM at all anymore (removing the Row/Column multiplexing arrangement in favor of addressing the memory array directly, more like SRAM -and resulting increase in external pin count- but with the other differences of of DRAM and SRAM still retained -added overhead from refresh/specific access slots/etc and ~6x higher density vs SRAM), that's a totally different discussion though. (but I wonder why non-multiplexed DRAM wasn't implemented as such . . . it would seem like a major compromise between DRAM and SRAM -and different from what PSRAM does)

Yes - that's the rotation I'm referring to. It's really superflous if you have full rotation in drawing, but is still present in VDP1/VDP2 - which is why I treat VDP1 as an extended version of the system Y sprite board with added gourard shading/general quad texturing.
Again, the similarities to the MCD ASIC could be argued as more comparable to VDP1.

However, VDP2 certainly has more specific similarities with Sega's arcade boards (and some of the ways VDP2+VDP1 fit together -like rotation of the sprite plane), though perhaps closer to the System 32 than the superscaler boards.

Hmm, and with the added context of VDP1's real bandwidth/performance, that would indeed show the Saturn to be reasonably efficient as an outright design (even somewhat in the context of the sound/CD subsystems) . . . but just a very high-end design that wasn't tempered for practical consumer level costs. (ie it's overkill in way too many areas for what a home console should have . . . certainly more so than the PSX, 3DO, or especially Jag/N64 -let alone in the context of Sony's even greater cost-saving advantages- . . . arguably more so than what the PS3 did even -and 3DO was pricy, but much more due to market model than hardware design . . . that was actually simple enough that it should have been able to significantly undercut the PSX's price in 1995)

It's odd as Sega had been rather realistic on their previous designs (even the Sega CD was realistically cost-conservative -aside from the inherently costly CD-ROM drive), and the Dreamcast went back to that reasonable cost envelope too . . . and the 32x is the extreme in contrast to the Saturn being super low-end and bare bones by comparison (too much so to make it a realistic long-term competitor even under better circumstances -certainly less competitive than the Jaguar), albeit the 32x wasn't didn't have a particularly impressive cost/performance ratio with super tight engineering. (it was just a really simple design . . . sort of like the Atari ST or ZX Spectrum)

Then again, Sega had far bigger problems than the Saturn being costly to manufacture. (though having a significantly lower price point than Sony or Nintendo probably would have helped at least -and the MD being cheaper than the SNES had been a major advantage in the US/Europe with $150 vs $200 in '91/92, $130 vs $150 in '93 until late 1994 when both were $100 SRP)
For that matter, if the Saturn was significantly cheaper, much of the incentive for the 32x would have been gone anyway.

Does the 3D0 have a 25MHz clock - it doesn't make sense - a 12.5MHz clock matches the cpu clock and memory bandwidth better.
http://classicgaming.gamespy.com/View.php?view=ConsoleMuseum.Detail&id=39&game=12
The video processors and DSP are listed as 25 MHz.

That site also lists the 9-16 Mpix/s figure. (and 4x that for the "pixels" of the interpolated display)

Running processors faster than the bus makes plenty of sense though . . . and the Jaguar was doing exactly that (blitter/GPU/DSP/OPL all run at 2x the external bus rate). Among other things, it could have facilitated interleaving accesses to main/video for blitting (rather than pipelining to for reads/writes on the same clock cycle like the Saturn) and doing other internal operations faster than the bus. (including gouruad shading and the realtime bilinear screen interpolation/AA for 320x240/480 to 640x480 -something a handful of N64 games did too, like Episode 1 Racer in low detail mode)
For that matter, both the Slipstream and Lynx also ran at 2x the bus speed. (ie fastest possible read/write took 2 blitter/coprocessor cycles)

Not sure about that - it's better than the Jaguar though :)
The Jaguar's a lot faster at gouruad shading . . . compared to the PSX for that matter. (in terms of actual g-shaded filling . . . not for rasterizing g-shaded polygons, let alone managing a fairly complex 3D game in general, but the raw performance for G-shading was good . . . and there's hardware Z-buffering, not that those come close to overcoming the hardware rasterization, matrix math/projection, or CPU performance of the PSX for polygonal games ;))

In any case, the 3DO's CPU resource (and bus contention) bottlenecks were the biggest limiting factors for the 3DO (technically) competing with the PSX/Saturn . . . raw/peak graphics bandwidth was generally similar. (though there's the issue of using quads too, and the folded quad/triangle "cheat" basically halving bandwidth -and doubling the size of textures- compared to games optimized for quad based models . . . or true triangle renderers)

Hell, in that perspective (with the slow CPU and contention for main RAM), the 3DO probably would have been a lot better off using a single bus for video with interleaved DRAM/VRAM banks (so still separate source and destination banks, but on a single bus limited to roughly 1/2 the peak bandwidth for rendering over the 2-bus arrangement . . . while allowing the CPU to run full-bore in parallel with graphics). OTOH, it may have been more effects (for both cost and performance) to just use a faster CPU with a cache (like an ARM600 or 610) rather than making a multi-bank video bus. (and again, the 1MB framebuffer was really odd overkill . . . 512k would have been fine for everything up to double buffered 320x240x24bpp -ie for VCDs- or single buffered 640x408x16bpp, etc; albeit to get 512k at 32-bits wide you'd need 4 128k chips rather than 2 512k chips -since DRAMs/VRAMs only went up to 16-bits at the time- . . . or they could have used cheaper DRAM as 4 16-bit chips as in 2 128kx32-bit hardware framebuffer banks -sort of like the 32x/Saturn- . . . or reduced cost further with a single 512kx32-bit bank -using 4 8-bit wide DRAMs- with some contention for framebuffer scanning -though the latter would only be realistic if they could afford decent sized line buffers in the VDC to keep scanning near peak FPM bandwidth, which would take ~18% if framebuffer bandwidth for an average 320x224x16bpp/60 Hz display with normal page breaks/refresh -assuming you had fairly large line buffers like 128-256 bytes . . . 256 byte line buffers might allow less than 18% though 128 bytes would probably be slightly more than 18% at best)

Hmm, for that matter, the 32x could have configured the framebuffer DRAM as a single 256kB 32-bit bank with contention for framebuffer/CPU access, but double the overall bandwdith, and potentially only a modest percentage absorbed by the VDC. (if decent sized line buffers could be afforded -even ~64 bytes wouldn't be too bad, it should only have taken ~15% for an average 320x224x8bpp/60 Hz display or ~26% for 320x200x16bpp/60Hz) So you'd have double the bus width with double the peak bandwdith, and still considerably better average bandwidth after VDC scanning overhead. (while using fewer traces than the current Saturn since you wouldn't have 2 separate 16-bit buses to address, but a single 32-bit bus sharing the same address lines -though the SDRAM bus would be unchanged) Or they could have used a single 512k 32-bit wide SDRAM bus shared for CPU and video. (the dual banks of those SDRAM chips would help reduce page change overhead further too) . . . or they could have gone cheaper with EDO DRAM of the same speed. (though Sega probably had a really good deal on those Hitachi chips already)

You could argue the same for the Saturn's framebuffers, except for that to really be useful, VDP1 would need to work on 32-bit words rather than 16-bits. (if you just combined the 2 framebuffers to a single 32-bit bank/bus, that would nominally reduce VDP1 bandwidth since it wouldn't be able to make use of 32-bit accesses and the bitmap scanning overhead would cut some bandwidth)
And in all those cases, the buffers would obviously take more chip space.

kool kitty89

11-08-2011, 08:20 PM

Chilly Willy

11-08-2011, 11:37 PM

Huh, so the SDRAM memory interface is only really set-up for burst reads . . . it has to fetch 8 words regardless of how many words you actually want to access?

Yep. It's hardwired for burst.

That obviously heavily hurts single byte/word/long reads considerably, but also (more moderately) hurts longer sustained reads from within the same page. (since you have to break up burst into 8 word segments rather than there just being 1 read with rowchange overhead and the res being pure fast-page reads -ie single cycles in this case)

That defeats some of the advantages of using SDRAM . . . even cheap FPM DRAM at 1/2 the SH2 clock rate should manage 1 random read/write in 5 cycles with all consecutive (FPM) READs/writes being 2 cycles each with 1 additional cycle to change between reads and writes. (which is exactly what the Jaguar does, albeit at a higher clock speed than the 32x -I'd hope the Saturn did that for Low-RAM too . . . otherwise that would be even slower than I'd though)

Well, think about the intended use for the 32X a moment - burst reads means you fill the cache for instruction sequences very fast, and burst reads fetch cell rows for blits very fast. A well tuned assembly routine should do very fast 2D graphics. For other things, you just have to try things to see how it goes. Sometimes uncached is better, and sometimes it isn't... and sometimes it makes no difference.

For that matter, if the Saturn was significantly cheaper, much of the incentive for the 32x would have been gone anyway.

I'd have rather seen two versions of the Saturn - a cheap cart version, and the regular CD version.

Crazyace

11-09-2011, 04:28 AM

Well . . . unless you had DRAM that had every single word in a separate page, but then you wouldn't have traditional DRAM at all anymore (removing the Row/Column multiplexing arrangement in favor of addressing the memory array directly, more like SRAM -and resulting increase in external pin count- but with the other differences of of DRAM and SRAM still retained -added overhead from refresh/specific access slots/etc and ~6x higher density vs SRAM), that's a totally different discussion though. (but I wonder why non-multiplexed DRAM wasn't implemented as such . . . it would seem like a major compromise between DRAM and SRAM -and different from what PSRAM does)
I think DRAM relies on the row/column paradigm - every word in a seperate page would probably be more complex than SRAM ( You can look at the Mosys 1T memory to see a compromise between DRAM and SRAM )

Again, the similarities to the MCD ASIC could be argued as more comparable to VDP1.
I dont agree - the MCD ASIC is much more of a generalised mode 7 analogue, drawing textured lines from a tilemap+charset. VDP1 is a multi bus design that matches the frame buffer sprite systems of the high end arcade boards with the addition of generalised gourard/textures polygon drawing of quads.

However, VDP2 certainly has more specific similarities with Sega's arcade boards (and some of the ways VDP2+VDP1 fit together -like rotation of the sprite plane), though perhaps closer to the System 32 than the superscaler boards.
Or the system Y board , which showed the rotation of the sprite plane in PowerDrift in 1988.

Hmm, and with the added context of VDP1's real bandwidth/performance, that would indeed show the Saturn to be reasonably efficient as an outright design (even somewhat in the context of the sound/CD subsystems) . . . but just a very high-end design that wasn't tempered for practical consumer level costs. (ie it's overkill in way too many areas for what a home console should have . . . certainly more so than the PSX, 3DO, or especially Jag/N64 -let alone in the context of Sony's even greater cost-saving advantages- . . . arguably more so than what the PS3 did even -and 3DO was pricy, but much more due to market model than hardware design . . . that was actually simple enough that it should have been able to significantly undercut the PSX's price in 1995)
The Saturn was very powerfull - and a killer sprite/scroller machine. The PSX beat it with a feature set aimed more at 3D , although it's sprite handling was fast enough to replicate most of the 2D required in games at the time. ( and the dithering helped to smooth shading a lot )

It's odd as Sega had been rather realistic on their previous designs (even the Sega CD was realistically cost-conservative -aside from the inherently costly CD-ROM drive), and the Dreamcast went back to that reasonable cost envelope too . . . and the 32x is the extreme in contrast to the Saturn being super low-end and bare bones by comparison (too much so to make it a realistic long-term competitor even under better circumstances -certainly less competitive than the Jaguar), albeit the 32x wasn't didn't have a particularly impressive cost/performance ratio with super tight engineering. (it was just a really simple design . . . sort of like the Atari ST or ZX Spectrum)
Maybe VDP1+2 were cheap in terms of chip complexity compared to the gpu on the PSX ( and the N64 )

Crazyace

11-09-2011, 07:36 AM

The Jaguar's a lot faster at gouruad shading . . . compared to the PSX for that matter. (in terms of actual g-shaded filling . . . not for rasterizing g-shaded polygons, let alone managing a fairly complex 3D game in general, but the raw performance for G-shading was good . . . and there's hardware Z-buffering, not that those come close to overcoming the hardware rasterization, matrix math/projection, or CPU performance of the PSX for polygonal games ;))
Yes - in theory Jag gourard should shade 54Mpixels/s compared to 33Mpixels/s on PSX... In practise that doesn't seem to happen though :) , again it's the contention on the bus.

In any case, the 3DO's CPU resource (and bus contention) bottlenecks were the biggest limiting factors for the 3DO (technically) competing with the PSX/Saturn . . . raw/peak graphics bandwidth was generally similar. (though there's the issue of using quads too, and the folded quad/triangle "cheat" basically halving bandwidth -and doubling the size of textures- compared to games optimized for quad based models . . . or true triangle renderers)
3D performance was a lot lower as well - but one nice thing was as textures came from main memory there's actually more memory for textures. ( and backgrounds in vram could actually be copied really quickly using the vram page load/store mechanism in vblank )

Hell, in that perspective (with the slow CPU and contention for main RAM), the 3DO probably would have been a lot better off using a single bus for video with interleaved DRAM/VRAM banks (so still separate source and destination banks, but on a single bus limited to roughly 1/2 the peak bandwidth for rendering over the 2-bus arrangement . . . while allowing the CPU to run full-bore in parallel with graphics). OTOH, it may have been more effects (for both cost and performance) to just use a faster CPU with a cache (like an ARM600 or 610) rather than making a multi-bank video bus. (and again, the 1MB framebuffer was really odd overkill . . . 512k would have been fine for everything up to double buffered 320x240x24bpp -ie for VCDs- or single buffered 640x408x16bpp, etc; albeit to get 512k at 32-bits wide you'd need 4 128k chips rather than 2 512k chips -since DRAMs/VRAMs only went up to 16-bits at the time- . . . or they could have used cheaper DRAM as 4 16-bit chips as in 2 128kx32-bit hardware framebuffer banks -sort of like the 32x/Saturn- . . . or reduced cost further with a single 512kx32-bit bank -using 4 8-bit wide DRAMs- with some contention for framebuffer scanning -though the latter would only be realistic if they could afford decent sized line buffers in the VDC to keep scanning near peak FPM bandwidth, which would take ~18% if framebuffer bandwidth for an average 320x224x16bpp/60 Hz display with normal page breaks/refresh -assuming you had fairly large line buffers like 128-256 bytes . . . 256 byte line buffers might allow less than 18% though 128 bytes would probably be slightly more than 18% at best)
What was the contention for main ram? As source pixels are likely to be 4 bit textures you should see 20% read to 80% write bandwidth for sprites. Only in cases where you are shrinking.. would read be higher ( or if you are sourcing higher bitdepth texels )
Also you could place other data ( audio, or code ) in vram :)

You could argue the same for the Saturn's framebuffers, except for that to really be useful, VDP1 would need to work on 32-bit words rather than 16-bits. (if you just combined the 2 framebuffers to a single 32-bit bank/bus, that would nominally reduce VDP1 bandwidth since it wouldn't be able to make use of 32-bit accesses and the bitmap scanning overhead would cut some bandwidth)
And in all those cases, the buffers would obviously take more chip space.
VDP1 needs to read texels, write random pixels , and also read rotated pixels ( frame buffer rotated read by VDP2 ).

kool kitty89

11-09-2011, 07:35 PM

I dont agree - the MCD ASIC is much more of a generalised mode 7 analogue, drawing textured lines from a tilemap+charset. VDP1 is a multi bus design that matches the frame buffer sprite systems of the high end arcade boards with the addition of generalised gourard/textures polygon drawing of quads.
Except the MCD ASIC behaves more like a blitter drawing textured/stretched/rotated rectangles to various locations in a framebuffer . . . rather like the Jaguar blitter or GBA (except limited to 4bpp), though it has hardware support for outputting pixels directly in tilemap cell or sprite order (since it doesn't have its own framebuffer available -the same thing that massively limits framerate and color)

Or the system Y board , which showed the rotation of the sprite plane in PowerDrift in 1988.
Or Galaxy Force in 1988 ;)

But again, more like the System 32 in that there was far more substantial BG/tilemap support. (except the Saturn went beyond that with the rotation/warping effects -and added color depth options, etc)

The Saturn was very powerfull - and a killer sprite/scroller machine. The PSX beat it with a feature set aimed more at 3D , although it's sprite handling was fast enough to replicate most of the 2D required in games at the time. ( and the dithering helped to smooth shading a lot )
Here's a question though:
how would a higher-end system (similar to the Saturn's cost of VDP1+VDP2+RAM) with all graphics resources pushed into a single blitter instead . . . or looking at the existing VDP1 design specifically:
extending the framebuffer and texture RAM to 32-bits wide (with 32-bit source and destination buffers added to VDP1), so basically double the bandwidth without VDP2 at all.

Or, a more extreme shift with a single, higher bandwidth video bus with a processor (or processors) designed with enough buffering to take advantage of that. (like the same SDRAM configured on a single 64-bit bus for video . . . more like the Dreamcast -albeit much simpler- or Jaguar II in some respects . . . or some PC video cards -like ATi's RAGE) Such a design may indeed involve multiple chips in the early models (depending just how complex the system was and how aggressive the chip design was), but it would still have the cost advantage of a single bus, performance advantage of substantial bandwidth (228 MB/s peak), flexibility of a unified chunk of RAM to parse out as desired, and massive potential for cost reduction in later redesigns. (obviously an even more cost effective option would be a single bus for the entire system . . . but that would be limited by the CPU bus widths and speeds -though using 64-bit latches would be somewhat helpful . . . but the main option for reducing cost further would just be dropping the graphics bus back to 32-bits)

Hmm, or in that sense (with common/cheap CPUs being limited in speed and bus width), you could use a set-up more like the 3DO to save cost . . . except with much faster RAM than the 3DO used. (and with much faster CPUs with caching) So one large shared pool for textures/CPU/audio work RAM and a framebuffer bus with the GPU having similar texture drawing bandwidth as if it were using a single 64-bit bus, and you'd simplify the GPU design by using less buffering compared to a 64-bit bus -though shading/blending effects would potentially be less. (and using single port DRAM/SDRAM for the framebuffer would be much more cost effective too -and as long as the VDC used decent sized line buffer, there would be relatively little overhead for framebuffer scanning, especially at common resolutions)

There's other potential advantages to VRAM, but then again, for a similar number of pins (single address bus and 64 data lines) you could have 64-bit single-port DRAM/SDRAM instead, with much more potential performance than 32-bit VRAM. (but you'd need more logic/buffering to really take advantage of that -namely a 64-bit destination buffer for textures/shading/etc -in addition to line buffers for efficient scanning)

Maybe VDP1+2 were cheap in terms of chip complexity compared to the gpu on the PSX ( and the N64 )
There's a lot more to cost effectiveness than the chip complexity though . . . the pin count on the ASICs themselves is a major issue (and unlike transitors, that doesn't get cheaper as time goes on), or the even bigger issue of many external, independent buses. (so even if you do consolidate chips to fewer packages, you can only modestly decrease the overall pin/trace count since you're stuck with the external buses)

Those are all huge potential long-term advantages for unified bus systems (or systems with more modest numbers of subsystems), going well beyond initial advantages. (like if the Jaguar had been more successful, there was the potential of merging TOM+JERRY+68k into a single ASIC with many fewer overall pins -in extreme cases you can merge external buses if much faster memory and on-chip buffering is used, but that's not very common or practical in the main lifespans of systems -the MD had that happen with the 68k+VDP buses merged/buffered for a single external 16-bit SDRAM chip . . . in 1998 ;) . . . though there had still be substnatial consolidation prior to that -including merging of the Z80+SRAM+68k into the VDP/IO ASIC around 1995)

Actually Kskunk explicitly addressed this issue in the 1993 Jaguar discussion:
http://www.atariage.com/forums/topic/119048-its-1993-youre-in-charge-of-the-jag-what-do-you-do/page__st__675

The final problem is cost. You probably want a 32-bit bus (since this is the width of the scratchpads). 16-bits would halve performance again. A separate 32-bit bus is going to want around 60 pins. Chip packages with a lot of pins are expensive -- the number of pins is a major percentage of the cost in custom chips. Also, while transistors get cheaper every year (thanks to Moore's law), pins cost the same, so having a lot of extra pins for extra busses means you can't cost reduce very well in the future. And of course a 32-bit bus means you need at least 2 extra DRAM chips, which makes your PCB larger which trickles into other costs such as case size and packaging and so on...

Next thing you know you have a Saturn, which is NOT a cost effective console. (But man it has a cool looking motherboard. ;)

Huh, I'd forgotten he actually referenced the Saturn in that comment . . .

Yes - in theory Jag gourard should shade 54Mpixels/s compared to 33Mpixels/s on PSX... In practise that doesn't seem to happen though :) , again it's the contention on the bus.
It might actually approach that in some games . . . but there's many more bottlenecks that would push actual rendering well below that of contemporaries.
The only cases where you'd really see g-shading near peak speed would be 2D games using it (like T2K) . . . 3D stuff has so much more overhead that's bottlenecked in other areas that fast g-shading is only a modest saving grace. (OTOH, the smoothness of that shading -thanks to CRY- is more significant than the actual speed . . . and of course, CRY was chosen for more than just that quality -but also to greatly simplify blitter/OPL design since shading could be accomplished via a simple 8-bit addition per pixel rather than several multiplies -with multiplication being handled by the pixel output path with still much simpler logic than would be needed for similar speed shading on the blitter end -since it only needed to be done once per pixel scanned out vs for every textel/pixel drawn by the blitter -the same technique could have been used for 4-4-4-4 RGBY with much coarser shading or 8-8-8-8 RGBY -the latter would have been really nice to have in the Jaguar, especially since all 24-bit rendering already had to be done as 32bpp)

3D performance was a lot lower as well - but one nice thing was as textures came from main memory there's actually more memory for textures. ( and backgrounds in vram could actually be copied really quickly using the vram page load/store mechanism in vblank )
From what Kskunk mentioned, the matrix coprocessor in the 3DO was about as fast as an SH2 or J-RISC (though much slower than the GTE), though the actual drawing bandwidth would be more limited than the Saturn (or PSX) as already mentioned. (software z-sorting, scene management, etc would obviously be limited by CPU resource though)

What was the contention for main ram? As source pixels are likely to be 4 bit textures you should see 20% read to 80% write bandwidth for sprites. Only in cases where you are shrinking.. would read be higher ( or if you are sourcing higher bitdepth texels )
Hmm, to do that though, you'd need a 32-bit source buffer that could be configured at different word depths, but that would certainly greatly improve efficiency if supported.
A worst case would be no source buffer at all (and all textels being fetched 1 at a time), but that's obviously not the case given the 9-16 Mpix/s figure. (with no source buffer and only a 32-bit destination buffer, you'd get 12.5 Mpix/s as a theoretical peak)

However, even with such a source buffer, you'd have the issue of contention leading to page breaks . . . and that would mean 5 GPU cycles vs 2 in FPM (or 3 vs 1 for CPU cycles -another advantage of the higher GPU clock rate: finer precision wait states). So you'd spend 5 (25 MHz) cycles reading 8 4-bit textels and 8 cycles writing to the framebuffer (in parallel with texture fextches) leaving only 3 cycles (120 ns) in between, which isn't enough for the CPU to make even 1 random access. Or, if we assume more cycles in the graphics pipeline (given the 9-16 Mpix/s figure), that would be 5 cycles to read 8 textels and 12~22 cycles to write 8 pixels to the framebuffer, leaving 7-17 cycles (280 to 680 ns) for the CPU for every 480-880 ns of total bus time.
The CPU would take 240 ns for 1 random access and 80 ns for additional sequential accesses, so only 1 access every 480 ns (6 CPU cycles) up to 6 sequential or 2 random accesses every 880 ns (11 CPU cycles).
Though using 2 or 1-bit textures would give better results (for the few cases you'd use those) and 6/8/16-bit textures would be worse. (albeit for rotated/3D stuff, you'd end up with a lot more page breaks on the framebuffer end, so there'd be more room for CPU cycle stealing) -it's interesting to note that the 3DO seemed to support 6-bit textures. (at least the FAQ mentions 1/2/4/6/8/16-bit texture support . . . I'd guess that 6bpp textures would store 5 textels in 32 bits, though it's odd that they wouldn't support 3 or 5-bit textures -10 or 6 textels in 32-bits, but maybe it's a typo)

So, like the Jaguar, interleaved bus accessing isn't very attractive at all in many cases. (and without line buffers or caching for textures in the GPU, and/or CPU caching, you can't buffer longer chunks of FPM accesses either -or work off the bus with the CPU in cache . . . and not even a scratchpad for that matter -though the DSP had 32k)

Also you could place other data ( audio, or code ) in vram :)
Yes, somewhat like the 32x framebuffers. (except VRAM would more likely be saturated by the GPU than main)

VDP1 needs to read texels, write random pixels , and also read rotated pixels ( frame buffer rotated read by VDP2 ).
Which the 3DO and PSX (among others) also do . . . albeit without the VDP2 thing. Random pixel writes wouldn't be accelerated by a wider bus width (and destination buffer), but writing lines/rows of consecutive pixels would be accelerated.

I'd have rather seen two versions of the Saturn - a cheap cart version, and the regular CD version.
Yes, and I've argued that before too (sort of the idea behind the "jupiter" project), at least as far as making more sense than the 32x (ie complementing the "full" saturn much better -and allowing very straightforward ports with full forwards compatibility to the Saturn -including expansion of the "jupiter" to Saturn via an add-on).

However, it would have made even more sense to aim at a cheaper CD based system with expandability. (given the inherent advantages of using CD media)

That could have included releasing 2 models from the start (with a high-end model and a low end model with support for expansion to -or beyond- the high-end set-up) . . . the problem is that this latter option would have been much more difficult to do efficiently with the existing Saturn (vs a cart based system which would have been rather straightforward).
Albeit, in the context of Sega actually planning 2 parallel systems/models early on (and not a last minute change) and designing/configuring the hardware accordingly, that could have worked much better.

As it is, the only things that could be stripped out (while retaining forwards compatibility) would probably be RAM . . . or maybe some of the coprocessors (though some things would be more difficult to interface via add-on than others). Or, for a cart based system, you'd not only be able to cut out some RAM, but the entire (overbuilt) CD subsystem. (albeit they potentially could have used a cut-down CD subsystem for a low-end model and retained compatibility . . . though the SH1 would have had to be retained if they used the same security system, perhaps at least cutting the SH1 work RAM to 128k of cheap DRAM -which would still mean more buffer space than the 3DO or PSX)

But even bigger cuts could obviously be made if the Saturn were intended for a lower-end counter part from the start . . . like the possible merging of the CD-ROM and audio subsystems (more like the Sega CD in some respects), and if the SH1 were used in place of the 68k as sound manager, you'd also have a lot more potential resource for decompression and such (aside from cases where the SH1 was monopolized for CD-ROM management).
Then there's cutting down some of the RAM in general (like cutting out low RAM, and perhaps having 512k DRAM shared for SH1/audio/CD buffer -expanded to 1 MB for the "full" Saturn).
And the graphics subsystem . . . VDP1 alone was cable of very impressive 2D for the time (as well as the primary source for 3D, obviously), so cutting out VDP2 entirely on a lower-end model could have made a lot of sense. (albeit you'd need a simple VDC in its place -something even simpler than the Super VDP since you wouldn't really need the RLE or fill functions- . . . perhaps embedded in VDP1 -and you wouldn't need more external pins either, since VDP1 already handles separate interfacing for both framebuffers, so it would only be a matter of the added silicon needed for a VDC and CRAM -if you were to support the 256 color mode without an external RAMDAC)

And then, you'd just need a general purpose expansion port that allowed for RAM expansion (for audio/SH1 and main low-RAM) plus the VDP1 framebuffer port/bus to connect to VDP2 externally. (as well as analog RGB-in to allow VDP2's video to override the internal VDC output)

Granted, you could go even more extreme and cut CD-ROM on top of all that, but I think the value of CD-ROM was too great to leave out. (especially with the decreasing cost overhead of CD-ROM drives . . . and you've got the very low cost and low risk of CD media over ROM carts, potential for free demo discs as cheap promotional media, multimedia capabilities of the large data capacity -audio/FMV/etc, and the general capacity for game data/etc)
With those advantages, Sega could have eaten the added cost of CD to keep console prices down, and still benefited more from higher profits on software, demo discs pack-in (meaning more profits on games that would have been pack-in), demo disc promotionals saving money over other advertising, etc.

And even with VDP1 alone, there's significant cost overhead from all the separate external buses . . . though at least most of those are narrow (so relatively few traces), and that would be a much bigger problem in the long run than short run. (systems with fewer buses -even very wide buses- would gain much more from consoldation as you'd totally eliminate many pins when merging chips -since many processors share the same external bus . . . and you'd see even more dramatic differences if you had external buffering/latches to expand fast/narrow buses to wider ones -like if you merged the RSP with the R4300 and thus only had the 9-bit RDRAM bus externally vs 9-bits for the RSP and 32-bits for the R4300 -and related 32-bit buffer/latch internal as well)

Albeit Sega could have taken a different design route in general to save cost further while still pushing good overall performance. (ie done like the PSX with a single wider video bus and much more buffering to soak up the bandwidth . . . or a wider/faster bus for the whole system shared more like the Jaguar/JagII/N64/Xbox/360/etc . . . though since the CPU's were limited to 32-bits wide and ~28 MHz -wasting much bandwith on wider/faster buses- it might make the most sense to go the 3DO route with a shared 32-bit sound/texture/CPU bus and a framebuffer bus but much faster than the 3DO and with caching on the CPUs. (though they could also have used 32-bits for main/shared RAM and 64-bits for the framebuffer, for faster performance on that end -and still much lower pin/trace count to 2 16-bit video buses or a single 32-bit VRAM bus with 64 data lines plus the address lines)

Crazyace

11-10-2011, 03:34 AM

Except the MCD ASIC behaves more like a blitter drawing textured/stretched/rotated rectangles to various locations in a framebuffer . . . rather like the Jaguar blitter or GBA (except limited to 4bpp), though it has hardware support for outputting pixels directly in tilemap cell or sprite order (since it doesn't have its own framebuffer available -the same thing that massively limits framerate and color)

Doesn't the MCD ASIC only draw lines? and the charmap indirection on reads is completely unlike VDP1.

Or Galaxy Force in 1988 ;)

But again, more like the System 32 in that there was far more substantial BG/tilemap support. (except the Saturn went beyond that with the rotation/warping effects -and added color depth options, etc)

I liked PowerDrift much more than Galaxy Force :) , but they're both the Y board, that shows VDP1 style sprite drawing to a buffer thats read rotated :)
System 32 combines that style of sprite board with a vdp2 style tilemap - but none of the games on it seemed to show off the rotated sprites as much as PowerDrift ( and Galaxy Force )

Here's a question though:
how would a higher-end system (similar to the Saturn's cost of VDP1+VDP2+RAM) with all graphics resources pushed into a single blitter instead . . . or looking at the existing VDP1 design specifically:
extending the framebuffer and texture RAM to 32-bits wide (with 32-bit source and destination buffers added to VDP1), so basically double the bandwidth without VDP2 at all.
VDP1 writes single pixels to arbitary addresses - so having 32 bit ram would just waste writes in a lot of cases ( unless there was a major design change similar to the way the 3d0 worked )
reads are linear bursts - but as most cases 16bit pixels aren't read b/w isn't as high as write b/w.

Or, a more extreme shift with a single, higher bandwidth video bus with a processor (or processors) designed with enough buffering to take advantage of that. (like the same SDRAM configured on a single 64-bit bus for video . . . more like the Dreamcast -albeit much simpler- or Jaguar II in some respects . . . or some PC video cards -like ATi's RAGE) Such a design may indeed involve multiple chips in the early models (depending just how complex the system was and how aggressive the chip design was), but it would still have the cost advantage of a single bus, performance advantage of substantial bandwidth (228 MB/s peak), flexibility of a unified chunk of RAM to parse out as desired, and massive potential for cost reduction in later redesigns. (obviously an even more cost effective option would be a single bus for the entire system . . . but that would be limited by the CPU bus widths and speeds -though using 64-bit latches would be somewhat helpful . . . but the main option for reducing cost further would just be dropping the graphics bus back to 32-bits)
I think you've drifted off from comparisions of 5th gen systems here - what was the performance of the first Rage cards like?

There's a lot more to cost effectiveness than the chip complexity though . . . the pin count on the ASICs themselves is a major issue (and unlike transitors, that doesn't get cheaper as time goes on), or the even bigger issue of many external, independent buses. (so even if you do consolidate chips to fewer packages, you can only modestly decrease the overall pin/trace count since you're stuck with the external buses)
How does the pin count of VDP1 compare with the Jaguar Tom , or the playstation GPU? pin count is a major issue - but so is complexity and yield.

From what Kskunk mentioned, the matrix coprocessor in the 3DO was about as fast as an SH2 or J-RISC (though much slower than the GTE), though the actual drawing bandwidth would be more limited than the Saturn (or PSX) as already mentioned. (software z-sorting, scene management, etc would obviously be limited by CPU resource though)
Not looked into it - I assumed it was a fixed function coprocessor for the ARM ( like GTE was for MIPS on playstation ) rather than a seperate cpu like SH-2/J-RISC.

Hmm, to do that though, you'd need a 32-bit source buffer that could be configured at different word depths, but that would certainly greatly improve efficiency if supported.
A worst case would be no source buffer at all (and all textels being fetched 1 at a time), but that's obviously not the case given the 9-16 Mpix/s figure. (with no source buffer and only a 32-bit destination buffer, you'd get 12.5 Mpix/s as a theoretical peak)

Why do you think texels are fetched 1 at a time on 3DO? If you look here ( http://hackipedia.org/Platform/3D0/html,%203DO%20SDK%20Documentation/Type%20A/ppgfldr/ggsfldr/gpgfldr/3gpg.html#XREF38473 ) you can see that things are a lot more complex than read 1 texel, write 1 pixel.

Yes, somewhat like the 32x framebuffers. (except VRAM would more likely be saturated by the GPU than main)
This wouldn't matter if the CPU was halted anyway during graphics - but I haven't looked into things that much.

Which the 3DO and PSX (among others) also do . . . albeit without the VDP2 thing. Random pixel writes wouldn't be accelerated by a wider bus width (and destination buffer), but writing lines/rows of consecutive pixels would be accelerated.
The problem here is that it's not just doubling the bus - you have to add drawing ability to generate 2 pixels / cycle as well, and given that the Saturn texture mapping writes randomly it's more difficult to do that. ( On 3D0 it looks like a lot of the corner engines were there to help with that. On PSX the writing of pixels is linear, and reading comes via a texture cache )

Chilly Willy

11-10-2011, 02:54 PM

Doesn't the MCD ASIC only draw lines?

Actually, the SCD ASIC doesn't draw lines at all. It draws rectangular regions with arbitrary scaling and rotation. The only other thing the ASIC does is color expansion: write a foreground and background color index, then write a word to one register and it's expanded to 16 pixels with each bit in the written word representing the foreground (1) or the background (0); that function is meant for drawing text with the ASIC.

Crazyace

11-10-2011, 03:42 PM

You're right - I hadn't looked at the docs for so long :( - It's more like a series of horizontal lines, with the the source base and deltax/y set per line. As such it's completely different to the way VDP1 works. ( I knew I was right to describe it as a generalised Mode 7 :) )

kool kitty89

11-10-2011, 09:33 PM

Actually, the SCD ASIC doesn't draw lines at all. It draws rectangular regions with arbitrary scaling and rotation. The only other thing the ASIC does is color expansion: write a foreground and background color index, then write a word to one register and it's expanded to 16 pixels with each bit in the written word representing the foreground (1) or the background (0); that function is meant for drawing text with the ASIC.

You're right - I hadn't looked at the docs for so long :( - It's more like a series of horizontal lines, with the the source base and deltax/y set per line. As such it's completely different to the way VDP1 works. ( I knew I was right to describe it as a generalised Mode 7 :) )
It was actually Chilly Willy who specifically described/compared VDP1 as an extension of the MCD's ASIC drawing mechanism . . . (I'll have to dig up that specific discussion).

I liked PowerDrift much more than Galaxy Force :) , but they're both the Y board, that shows VDP1 style sprite drawing to a buffer thats read rotated :)
System 32 combines that style of sprite board with a vdp2 style tilemap - but none of the games on it seemed to show off the rotated sprites as much as PowerDrift ( and Galaxy Force )
There were some games that looked even closer to polygonal 3D than those (like Rad Mobile), but I'm not sure about examples showing off BG rotation verymuch.

VDP1 writes single pixels to arbitary addresses - so having 32 bit ram would just waste writes in a lot of cases ( unless there was a major design change similar to the way the 3d0 worked )
reads are linear bursts - but as most cases 16bit pixels aren't read b/w isn't as high as write b/w.
Yes, I was talking about a VDP1-like processor (or more like the 3DO Cel engine) that used separate source and destination buses, but had added logic/buffering that catered to 32-bit reads/writes. (or just 32-bit writes for that matter, as 8 or 4-bit 16-bit reads could potnetially buffer 2 or 4 pixels at a time -if the logic was there to support that)

You'd add complexity to the engineering end for much better performance with relatively little added cost. (or reducing overall cost for that matter -in the case of having a single framebuffer bus/bank with modest contention for scanning overhead . . . or obviously even more cost savings if VDP2 was replaced by a simplistic bitmap VDC and all graphics were handled by the blitter . . . or even more cost savings if main RAM was shared as the texture buffer -so, more like a 3DO, but with 2.23/2.29x faster RAM and CPU clock speeds -and 2 CPUs)

And that (32-bit source/destination buffers -or 16-bit source and 32-bit destination) would be much simpler logic-wise (and thus much more conservative) than what the PSX GPU does . . . or the Jaguar II. (or Kskunk's specific hypothetical example of a 64-bit source and 256-bit destination buffer for the Jaguar blitter -given as an example of what it would need to texture map efficiently on the 64-bit FPM bus . . . and also specifically noted that that would take less logic than was allotted for Z-buffering, and in the same conversation he mentioned the much simpler route of adding only a 64-bit destination buffer -not nearly as efficient for a shared 64-bit bus, but still much faster than the existing single pixel read/write function of the blitter)

How does the pin count of VDP1 compare with the Jaguar Tom , or the playstation GPU? pin count is a major issue - but so is complexity and yield.
Initial pin count isn't the only factor in any case . . . you could a multi-chip design with more traces using older process chips that would consoldiate/scale extremely well due to the use of few (or 1) buses.

Of course, that's thinking long-term, and the initial design practicality must be balanced with that . . . and your R&D resources. (except Atari obviously had much more limited resources, but skilled engineers pushing an extremely tight/aggressive design . . . and had the silicon been put to use in different areas, a chip the same size of TOM could have had much closer to PSX GPU performance -the Z buffer logic alone took up more space than fast texture mapping logic would have- let alone if they were afforded use of 35 ns EDO/SDRAM rather than limited to aiming at the lower-end mass-market options, and not to mention if they were afforded substantial resources for aggressive trouble shooting -for bug fixes- and extensive software tool development . . . or enough resources from the outset for the engineers to deem a dynamic cache viable on one -or both- of the RISC chips)

If the 3DO was a particularly conservative design in 1993 (in terms of cost/performance ratio), what would that make the Saturn in '94 by comparison?

Not looked into it - I assumed it was a fixed function coprocessor for the ARM ( like GTE was for MIPS on playstation ) rather than a seperate cpu like SH-2/J-RISC.
Yes, I believe it's fixed-function (or at least treated as fixed-function by the API), but Kskunk's comment as that it handled matrix calculations at similar speeds as the Jaguar GPU (or DSP) which would also be roughly comparable to an SH2 of a similar clock speed. (and thus a bit less than 1/2 the peak performance of the GTE)

Why do you think texels are fetched 1 at a time on 3DO? If you look here ( http://hackipedia.org/Platform/3D0/html,%203DO%20SDK%20Documentation/Type%20A/ppgfldr/ggsfldr/gpgfldr/3gpg.html#XREF38473 ) you can see that things are a lot more complex than read 1 texel, write 1 pixel.
I did say that it probably didn't fetch 1 at a time, and the rest of my supposition was based around doing 32-bit reads. (mainly in the context of reading 8 4-bit textels)

However, in the context of DRAM bus sharing on the 3DO, I failed to consider 1 significant possibility . . . interlaved banks.
I'd thought the 3DO used 4 512k8-bit FPM DRAMs for main RAM, but if it actually used 4 256kx16-bit chips, they potentially could have configured that as 2 32-bit banks with 1 page held open in each (similar to what the Jaguar supports). And in that case, you could get a fair bit more shared bandwidth for cases where the cel and CPU were working in separate banks and FPM accesses were used. (and you'd generally reduce page breaks from interleaved accesses)

The problem here is that it's not just doubling the bus - you have to add drawing ability to generate 2 pixels / cycle as well, and given that the Saturn texture mapping writes randomly it's more difficult to do that. ( On 3D0 it looks like a lot of the corner engines were there to help with that. On PSX the writing of pixels is linear, and reading comes via a texture cache )
Yes, I didn't mean to imply it would be a hack to the existing VDP1, but a generally different (and more efficient) alternate design of VDP1 . . . or a general 2D/3D sprite/blitter engine for the time.

Though again, making other trade-offs to drop to even fewer buses would make for even better cost effectiveness, though the more you do that, the tighter the design needs to be to soak up bandwidth efficiently.
And there's a variety of different levels of trade-offs for complexity of design vs manufacturing cost and future scalability/consolidation:
a system with a totally unified bus using a single bank (ie non-interleaved) of DRAM would be the most extreme for potential efficiency, then you add in multiple banks with interleaved page access support, then multiple buses, then more and more buses beyond that.

Granted, you could have a design that catered well to scaling/consolidation, but simply wasn't efficiently consolidated for other reasons: the company never bothered to invest the R&D resources for redesigns, the product didn't sell well enough to merit a long life to facilitate such redesigns, or the design was made from off the shelf/licensed components that had legal barriers for re-engineering. (like the Xbox: a totally unified dual-channel DDR bus for extenal memory meaning lots of potential consolidation -in the extreme, a potential single-chip implementation- but the off the shelf/limited licensed nature of the CPU and graphics chipsets made that impractical -unlike the PSX, where sony produced nearly all the chips and had a full license on the R3000 core . . . or the Jaguar with in-house designed ASICs and even the 68k would have been reasonable to license if the system had sold well enough to merit such consolidation)
For that matter, the Amiga could have been consolidated to a single ASIC for everything sharing the chipRAM bus . . . and the Atari ST potentially 1 ASIC for everything (or any single-bus system, obviously)

Systems that start off already highly integrated have less savings to make though . . . then you mainly just get economies of scale, falling component costs (moore's law), die-shrinks/core redesigns for smaller processes, etc.

And in the general context of practical design layouts/concepts for ~1994 . . . there's some specific options I didn't point out in my previous post:
like a single bus design with 64-bit bank for the framebuffer and interleaved 32 or 16-bit bank (or banks) for textures/audio/CPU with a 16/32-bit source and 64-bit destination buffer for a blitter/GPU (much simpler than the buffering/caching used in the PSX or Jaguar II, and not far off from what the 3DO already did) with a line buffer used for scanning out the framebuffer . . . or a full object processor for that matter. (like having a smaller 64-bit bank with the rest of the system 16 or 32-bits wide banks on the same bus -for a system like the Jag, using a 68k . . . or 386SX or 486SLC, the 16-bit case would make more sense, obviously)

In the case of a system using slow memory like the 3DO or Jaguar (say the Jag's clock speed for comparison), that would allow rendering at 26.6 Mpix/s theoretical peak (2 cycles to read 4 4-bit pixels and 2 cycles to write 4 16-bit pixels to the 64-bit bank) . . . or faster than that if you read more pixels at a time. (ie a 32-bit read fetching 8 pixels and 2 64-bit writes to plot 8 pixels would allow up to 8 pixels in 6 cycles or ~35.5 Mpix/s peak -though obviously such a single-bus system would have more bandwidth eaten up for other things)
Or, with RAM the speed of the PSX/Saturn (ie 35-30 ns), you'd have double those speeds . . . and thus much more competitive overall performance to the PSX (after bandwidth for other needs was accounted for) at potentially much lower cost than the PSX, let alone Saturn.

That layout would also cater better to soaking up bandwidth of CPUs/other off the shelf processors that couldn't make use of 64-bit buses (or 32-bit buses for that matter) while having a shared memory pool that could be used fairly modularly (ie any bank/bus could be accessed by any bus master), though with "normal" use treating the separate banks more as dedicated buses for different processors.

There's tons of other possible system layouts that could have been used at the time though . . . and obviously tons of other possible system hardware set-ups with different features, different levels of integration/aggressive design, etc, etc. (but the point would be that the Saturn took a very costly, less aggressive, and arguably rather "safe" design approach . . . though obviously not "safe" in terms of cost effectiveness, but in terms of likelihood of working without complications/bugs/poor yields/etc -rather like the 3DO, except the 3DO's approach still made for a much more easily consolidated/lower cost design than the Saturn, or PSX for that matter)

Hell, for that matter, the Sega CD is a bit of a mess too from that standpoint:
1 16-bit bus for the CPU/program RAM, an 8-bit local bus for the sound chip, a 16-bit bus for word RAM, and MD bus (with word RAM or program RAM able to be banked to the MD bus), but then there's also the MD VDP and Z80 buses. (so 6 buses -not including the CD-ROM buffer/interface) Then there's 2 more buses if you add in the 32x. ;) (albeit the Z80 bus was moved totally internal ~1995 when the Z80+RAM was merged with the VDP ASIC -so only 2 external buses were used)
-Compared to the Saturn with CPU, SH1/CD-ROM, Bus A, Bus B, audio, VDP1's 3 buses, and VDP2. (so 9 total, and no cases where integration of RAM+processor into a larger ASIC would remove that from play -like the Z80+SRAM was for the MD ... which was only some 4-5k transistors for the Z80 though some 393k for the SRAM)

Implying that the MCD itself would have been rather difficult to consolidate. (though all buses being 8 or 16-bits wide helps somewhat -and some having relatively limited address ranges . . . but merging chips wouldn't have nearly as much savings as systems with chips sharing fewer buses)

But all this tech stuff only goes so far, even if it's totally accurate . . . there's tons of other areas that contribute to a platform's success than technical capability or efficiency (or even how well the system's hardware fits the market in terms of features, performance, and cost).
Things like the PR/name of the parent company producing the product, management of said company, 1st party software/management/planning, relations with 3rd party publishers (and licensing terms, etc), marketing/advertising/hype, software development tools, etc, etc, etc. (and solid funding to back all that up)

Good/market-fitting hardware is a factor, and sometimes the thing that puts a system over the top, but also usually not enough to drive success without strength in many of the other areas. (especially in some markets -the US is obviously much more costly and saturation-advertising/hype driven than some other markets, especially in the past -some factors leading to the considerable success of the Spectrum, ST, and Amiga in Europe and relative weakness of IBM compatibles there prior to the mid 90s)

And weaknesses in some areas tend to exacerbate others (sometimes cyclically) . . . like what happened to Atari Corp (troubled management was exacerbated declining/stagnating revenue which further degraded management which fostered further degradation of the market situation), or what happened with Sega in the mid 90s. (mistakes/problems compounding others and making the overall problem into a bigger and bigger mess . . . unlike NEC or Nintendo who made rather few compounded mistakes, but fairly definitive -and consistent- ones . . . especially Nintendo's general arrogance, stubbornness, and lack of interest in supporting 3rd parties or establishing good relationships -in fact they more often did things to push 3rd parties away- . . . the software licensing and manufacturing terms showed exactly that from the NES through N64 -and lingering to this day, especially on the DS- the N64's use of cartridges obviously due mainly to Nintendo's self-interested obsession on exclusivity and complete control over software/publishing -ie not just preventing piracy/unlicensed games, but total control over manufacturing costs, delivery dates, production quantity, etc -since 3rd parties were barred from manufacturing their own games)

So, the argument for the Saturn's hardware design being its biggest problem is obviously wrong . . . though the expense and relative 2D vs 3D useful performance/features (especially relative to common 3D rendering/modeling techniques) certainly didn't help Sega. (and the poor documentation and tool support exacerbated the quality of 3rd party software even more . . . on top of all of Sega's non-technical problems)

kool kitty89

11-11-2011, 02:16 AM

Getting away from the issue of the Saturn . . . let alone the non-technical rant towards the end of my last post:

The Jaguar's blitter definitely has no color look-up support (it can only read pixels/textels of a given color/bit depth, and write/blit them to a framebuffer of the same depth, right)?
That's not counting software look-up/expansion done by the GPU, just the blitter by itself.

And on an even further separate issue:
Does the N64 render to an 18-bit framebuffer? I was thinking it used a plain 15-bit framebuffer normally, but then I remembered reading something about 18-bit color. (actually I think it may have been a comment Chilly Willy made when I was talking about how VGA used 18-bit RGB -I may have mentioned the Panther too, but I forget the details of that discussion)
Given the 9-bit memory used, that wouldn't be too surprising.

I remember reading that the RSP supported 5-5-5-1 and 4-4-4-4 RGBA formatted textures (and used the parity bit to define which format was used on a per-pixel/textel basis), but that doesn't really say anything about what the actual framebuffer/display used.

If it is actually 18-bits, that would explain when some shading/lighting/blending (including the bilinear filtered textures) looks smoother than similar examples done in 15/16-bit RGB.

Crazyace

11-11-2011, 03:54 AM

Yes, I was talking about a VDP1-like processor (or more like the 3DO Cel engine) that used separate source and destination buses, but had added logic/buffering that catered to 32-bit reads/writes. (or just 32-bit writes for that matter, as 8 or 4-bit 16-bit reads could potnetially buffer 2 or 4 pixels at a time -if the logic was there to support that)

You'd add complexity to the engineering end for much better performance with relatively little added cost. (or reducing overall cost for that matter -in the case of having a single framebuffer bus/bank with modest contention for scanning overhead . . . or obviously even more cost savings if VDP2 was replaced by a simplistic bitmap VDC and all graphics were handled by the blitter . . . or even more cost savings if main RAM was shared as the texture buffer -so, more like a 3DO, but with 2.23/2.29x faster RAM and CPU clock speeds -and 2 CPUs)

Something like that would be like the PSX gpu , but without the texture cache :)

And that (32-bit source/destination buffers -or 16-bit source and 32-bit destination) would be much simpler logic-wise (and thus much more conservative) than what the PSX GPU does . . . or the Jaguar II. (or Kskunk's specific hypothetical example of a 64-bit source and 256-bit destination buffer for the Jaguar blitter -given as an example of what it would need to texture map efficiently on the 64-bit FPM bus . . . and also specifically noted that that would take less logic than was allotted for Z-buffering, and in the same conversation he mentioned the much simpler route of adding only a 64-bit destination buffer -not nearly as efficient for a shared 64-bit bus, but still much faster than the existing single pixel read/write function of the blitter)
How much simpler would this be? Where is your evidence for this claim?

Crazyace

11-11-2011, 04:37 AM

Getting away from the issue of the Saturn . . . let alone the non-technical rant towards the end of my last post:

The Jaguar's blitter definitely has no color look-up support (it can only read pixels/textels of a given color/bit depth, and write/blit them to a framebuffer of the same depth, right)?
That's not counting software look-up/expansion done by the GPU, just the blitter by itself.

All the details are in the reference doc - there is the bit to pixel expansion logic as well, but it's not generalised.

And on an even further separate issue:
Does the N64 render to an 18-bit framebuffer? I was thinking it used a plain 15-bit framebuffer normally, but then I remembered reading something about 18-bit color. (actually I think it may have been a comment Chilly Willy made when I was talking about how VGA used 18-bit RGB -I may have mentioned the Panther too, but I forget the details of that discussion)
Given the 9-bit memory used, that wouldn't be too surprising.

I remember reading that the RSP supported 5-5-5-1 and 4-4-4-4 RGBA formatted textures (and used the parity bit to define which format was used on a per-pixel/textel basis), but that doesn't really say anything about what the actual framebuffer/display used.

If it is actually 18-bits, that would explain when some shading/lighting/blending (including the bilinear filtered textures) looks smoother than similar examples done in 15/16-bit RGB.

There seems to be a doc here: http://www.dragonminded.com/n64dev/Reality%20Coprocessor.pdf - shows frame buffer formats as 16 bit RGBA and 32 bit RGBA. The extra bits from the RDRAM are used for coverage.

Chilly Willy

11-11-2011, 04:10 PM

And on an even further separate issue:
Does the N64 render to an 18-bit framebuffer? I was thinking it used a plain 15-bit framebuffer normally, but then I remembered reading something about 18-bit color. (actually I think it may have been a comment Chilly Willy made when I was talking about how VGA used 18-bit RGB -I may have mentioned the Panther too, but I forget the details of that discussion)
Given the 9-bit memory used, that wouldn't be too surprising.

I remember reading that the RSP supported 5-5-5-1 and 4-4-4-4 RGBA formatted textures (and used the parity bit to define which format was used on a per-pixel/textel basis), but that doesn't really say anything about what the actual framebuffer/display used.

If it is actually 18-bits, that would explain when some shading/lighting/blending (including the bilinear filtered textures) looks smoother than similar examples done in 15/16-bit RGB.

There seems to be a doc here: http://www.dragonminded.com/n64dev/Reality%20Coprocessor.pdf - shows frame buffer formats as 16 bit RGBA and 32 bit RGBA. The extra bits from the RDRAM are used for coverage.

The "15-bit" mode in the N64 maintains 18 bits in RDRAM. The 2 extra bits RDRAM provides (RDRAM is 9-bit instead of 8-bit, so you have 18 bits instead of 16 when paired) are combined with one bit from the 16 "normal" bits to give 3 alpha bits for the frame buffer. The programmer cannot directly access those bits - you only have 5551 and 4444 textures; the RDP uses the bits itself as it renders to give better transparency effects for 15-bit mode.

That is not the same as the 18-bit palette in VGA cards - 18-bit VGA colors are 666; that is, six bits per color, and no alpha (VGA never had an alpha channel). The N64 15-bit mode is 555 for the RGB; that is, five bits per color. The extra bits are ONLY for computed alpha, not color.

TVC 15

11-15-2011, 12:33 PM

This piqued my interest a while back, an interview with Yu Suzuki where he briefly mentions his work with Lockheed Martin. Theres a few lines in the interview which stick out like a sorethumb, specifically he mentions trying to scale down some of Lockheed's technology for use in a console?! This may have been a massive translation error on the part of the interview where Suzuki-San may have meant scaling the tech for Arcade level, but could Suzuki-San have played some part in the initial development of the Saturn? Or perhaps a skunkwork project to see if an alternative design could be produced in the Saturns much vaunted though never confirmed 'redesign' period?

That all sounds a bit pie in the sky with some assumption on my part but the interview does highlight some interesting times at Sega. He chats about his work designing the Model 1/2 on page 3 here...

http://www.1up.com/features/disappearance-suzuki-part-1?pager.offset=2

kool kitty89

11-18-2011, 03:50 AM

How much simpler would this be? Where is your evidence for this claim?
Again, I meant simpler (in terms of chip design/transitor count) than the PSX GPU or Jag II blitter, but not simpler (logic wise) than what the Saturn does. (but more cost effective in terms of pin/trace count on the ASICs and RAM chips -and memory mappers and DRAM controllers- and lending better to further consolidation/cost reduction)

And, as far as being simpler (internally) than what the PSX GPU (or Jag II does) . . . there'd be much less buffering/caching involved at the very least. (small source and destination buffers vs caches and large source/destination buffers -I'm not sure what the Jag II's actual buffer sizes are, but given the texture mapping performance, it would have to have a 64-bit source and a destination buffer of several times that size -Kskunk mentioned a 256-bit destination buffer at one point, but I think that may have been a hypothetical comment)

In the PSX's case, it's using SGRAM, so it could potentially be reading from 1 page and writing to the 2nd active page (albeit with some contention for framebuffer scanning), so it may just be using 32-bit source/destination buffers (along with the 2k cache and associated logic) . . . so a bit like the 3DO but with interleaved page accesses on a single bus vs 2 separate buses.

The same could potentially have been applied to the Jaguar, taking advantage of the 2-bank DRAM support (plus ROM is in a 3rd separate bank), but flare chose not to populate that bank in the Jag I (and had the blitter relatively limited in any case), and also avoided on the Jag II for cost reasons. (especially with the added chip space possible in the timeframe of the Jag II's development . . . though had flare put much more emphasis on blitter rendering with the Jaguar, using modest source/destination buffers along with multiple DRAM banks may have been one of the more practical options -still a single-bus design, mind you)

All the details are in the reference doc - there is the bit to pixel expansion logic as well, but it's not generalised.
I don't see any reference to pixel/color depth expansion for the blitter in the manual . . . I see the notes on the bit to pixel expansion (via the bit comparator), but, unless I'm misunderstanding that feature, it doesn't sound like color/pixel expansion. (and certainly not look-up)

Without look-up support on the blitter (using CRAM -or tables in external memory or GPU SRAM), the best you could do for color/pixel expansion would be 1/2/4 bit to 8-bit expansion via an offset (expanding to paletted 8bpp objects), but I'm not sure there's even support for that. (maybe that's exactly what the bit comparator is used for and I'm just misunderstanding it)

Doing actual look-up would go a step further and use that offset to point to entries in CRAM and convert those 1/2/4/8-bit pixels to 16-bit RGB/CRY (albeit, if 8-bit, there's no need for an offset since CRAM has only 256 entries). Or, beyond just using an offset in CRAM, there could be support for other tables in GPU RAM or main for color expansion. (but that would be more complex and much slower in the case of main DRAM)

And, on another note:
I noticed some interesting comments on the Z-buffering system of the Jaguar . . . does it use 32-bits per pixel when Z-buffering is employed? (if a 16-bit Z value is attached to every pixel in the framebuffer with 16-bit CRY pixels, that would imply 32-bits per pixel . . . and while a z-buffer could technically take up separate memory from the framebuffer, it would seem to make more sense to interleave/pack the pixels with the corresponding Z values for faster rendering -fewer reads/writes to compare and modify Z values and pixels in the buffer, and fewer page breaks as well)

The "15-bit" mode in the N64 maintains 18 bits in RDRAM. The 2 extra bits RDRAM provides (RDRAM is 9-bit instead of 8-bit, so you have 18 bits instead of 16 when paired) are combined with one bit from the 16 "normal" bits to give 3 alpha bits for the frame buffer. The programmer cannot directly access those bits - you only have 5551 and 4444 textures; the RDP uses the bits itself as it renders to give better transparency effects for 15-bit mode.

That is not the same as the 18-bit palette in VGA cards - 18-bit VGA colors are 666; that is, six bits per color, and no alpha (VGA never had an alpha channel). The N64 15-bit mode is 555 for the RGB; that is, five bits per color. The extra bits are ONLY for computed alpha, not color.
Oh, OK . . . it just seems a bit odd that they'd use that on the framebuffer end rather than only on the texture/source end (and internally in the RSP), since pixels written/read from the framebuffer wouldn't have any use/need for an alpha channel. (unless multiple frambuffers were being composited -like the jaguar's object processor can do, but I don't think the N64 has any support for)
OTOH, 5-5-5-3 RGBI (or RGBY) on the framebuffer end would make more sense (and correspond well to 24-bit RGB output since 5-bit values multiplied by 3-bit values would conveniently fit within an 8-bit range), and that would also potentially allow 24-bit quality gouraud shading. (so more limited color than 6-6-6 RGB, but better intensity/shade resolution)

Crazyace

11-18-2011, 04:58 AM

I don't see any reference to pixel/color depth expansion for the blitter in the manual . . . I see the notes on the bit to pixel expansion (via the bit comparator), but, unless I'm misunderstanding that feature, it doesn't sound like color/pixel expansion. (and certainly not look-up)

Without look-up support on the blitter (using CRAM -or tables in external memory or GPU SRAM), the best you could do for color/pixel expansion would be 1/2/4 bit to 8-bit expansion via an offset (expanding to paletted 8bpp objects), but I'm not sure there's even support for that. (maybe that's exactly what the bit comparator is used for and I'm just misunderstanding it)

Doing actual look-up would go a step further and use that offset to point to entries in CRAM and convert those 1/2/4/8-bit pixels to 16-bit RGB/CRY (albeit, if 8-bit, there's no need for an offset since CRAM has only 256 entries). Or, beyond just using an offset in CRAM, there could be support for other tables in GPU RAM or main for color expansion. (but that would be more complex and much slower in the case of main DRAM)

As you found from the docs there is no colour lookup support in the blitter for the Jaguar - ( as I mentioned the bit to pixel expansion is much more restricted - and it's use is described as an example )

And, on another note:
I noticed some interesting comments on the Z-buffering system of the Jaguar . . . does it use 32-bits per pixel when Z-buffering is employed? (if a 16-bit Z value is attached to every pixel in the framebuffer with 16-bit CRY pixels, that would imply 32-bits per pixel . . . and while a z-buffer could technically take up separate memory from the framebuffer, it would seem to make more sense to interleave/pack the pixels with the corresponding Z values for faster rendering -fewer reads/writes to compare and modify Z values and pixels in the buffer, and fewer page breaks as well)
Dont you mean the phrase interleave? That's not 32 bit pixels - just 1 phrase of colour and 1 phrase of Z?

Chilly Willy

11-18-2011, 12:37 PM

Oh, OK . . . it just seems a bit odd that they'd use that on the framebuffer end rather than only on the texture/source end (and internally in the RSP), since pixels written/read from the framebuffer wouldn't have any use/need for an alpha channel. (unless multiple frambuffers were being composited -like the jaguar's object processor can do, but I don't think the N64 has any support for)
OTOH, 5-5-5-3 RGBI (or RGBY) on the framebuffer end would make more sense (and correspond well to 24-bit RGB output since 5-bit values multiplied by 3-bit values would conveniently fit within an 8-bit range), and that would also potentially allow 24-bit quality gouraud shading. (so more limited color than 6-6-6 RGB, but better intensity/shade resolution)

Think about it a moment - if you only have 1 bit for the alpha, your choices are pixel on, or pixel off. Period. If you wish for a translucent texture for water or glass or something, you need a LOT more than on/off, although dithering could help with that. So for things that ARE either on or off, like an opaque object, you use 5551 textures. For things that are translucent, you use the 4444 textures. However, suppose you have more than one translucent object? If your frame buffer only supported storing a 5551 pixel, you'd have a hard time applying more than one translucent texture to a scene. However, a 5553 frame buffer will allow for several translucent objects to keep the proper translucency. So you can look through the ghost through a window into the water and still see fish. :)

kool kitty89

11-18-2011, 08:38 PM

Think about it a moment - if you only have 1 bit for the alpha, your choices are pixel on, or pixel off. Period. If you wish for a translucent texture for water or glass or something, you need a LOT more than on/off, although dithering could help with that. So for things that ARE either on or off, like an opaque object, you use 5551 textures. For things that are translucent, you use the 4444 textures. However, suppose you have more than one translucent object? If your frame buffer only supported storing a 5551 pixel, you'd have a hard time applying more than one translucent texture to a scene. However, a 5553 frame buffer will allow for several translucent objects to keep the proper translucency. So you can look through the ghost through a window into the water and still see fish. :)
Why would the framebuffer impact that though? You overwrite each pixel drawn to the framebuffer, so independent objects no longer exist as far as that's concerned.

It's not like the alpha channel would be acting like a Z-buffer (defining depth of the current visible pixel) . . . oh, but if you were to use depth/Z sorting in addition to that alpha channel, it would matter, since some objects could be drawn "behind" the framebuffer if a lower depth priority. (but rather than not being drawn at all, they'd get blended with the translucent foreground)
For objects with higher priority than the framebuffer, that wouldn't matter though. (and a renderer specifically designed to render in Z sorted order with higher and higher priority objects rendered in successive passes, that wouldn't ever be necessary as the alpha channel of the textures would be all that matters -though that sort of renderer would suffer lots of overdraw without very efficient clipping/culling . . . and would also defeat the purpose of a Z buffer -though perhaps be desirable for a system relying on software z-sorting)
Plus, z-sorting on a per-object/per-polygon basis also avoids z-fighting. (or rather, you might get mis-sorted objects/polygons, but not patchy bleed-through/tearing within polygons -and indeed, the "z fighting" normally seen on software z-sorted renderers tends to be flickering polygons rather than tearing/bleeding on a pixel basis)

Also, a 1-bit alpha channel shouldn't necessarily just be on or off . . . it could be on (ie obscure all objects being drawn behind it) or 1/2 transparent (or made programmable for any other single fixed level of translucency), since being "off" (ie completely overwritten) would already be addressed by Z sorting.

As you found from the docs there is no colour lookup support in the blitter for the Jaguar - ( as I mentioned the bit to pixel expansion is much more restricted - and it's use is described as an example )
Hmm, so it just does 1/2/4 bit to 8-bit pixel expansion? I saw some descriptions and limited examples, but it wasn't really clear (unless I missed something).

It seems like expansion to 8bpp should be pretty straightforward . . . just a linear offset similar to 1/2/4-bit expansion in the OPL (or Panther), except a value of zero may define a fixed BG color rather than transparent. (that would have been a really useful, yet simple feature for the Slipstream blitter to have . . . just a simple linear offset to expand 1/2/4-bit to 8-bit pixels and look-up being done only by the VDC for 8=>12-bit ;) )

Dont you mean the phrase interleave? That's not 32 bit pixels - just 1 phrase of colour and 1 phrase of Z?
Yes . . . that makes more sense. :)

Can OPL sprites also be z-buffered? (that would be really useful for using scaled sprites in combination with a framebuffering -to define what parts of a sprite might be hidden by part of the 3D scene in the framebuffer . . . and that would also give more merit for a hardware z-buffer over software z-sorting -while you could often sort blitter objects/polygons to be drawn in software z-sorted order, that doesn't work for sprites/windows drawn to a line buffer -with the framebuffer being treated as 1 solid object)
For that matter, having a Z-buffer on the Saturn would have made using VDP a lot more useful. (or just 3-bit per-pixel priority -since there's only up to 5 BG planes compared to hundreds of objects on the Jaguar ;))

Crazyace

11-19-2011, 03:22 AM

On the N64 the extra bits are also for coverage, not simple alpha ( there are 4 bits in 32 bit mode, and 2 in 16 bit mode )

Hmm, so it just does 1/2/4 bit to 8-bit pixel expansion? I saw some descriptions and limited examples, but it wasn't really clear (unless I missed something).
Only 1 bit source.

Can OPL sprites also be z-buffered? (that would be really useful for using scaled sprites in combination with a framebuffering -to define what parts of a sprite might be hidden by part of the 3D scene in the framebuffer . . . and that would also give more merit for a hardware z-buffer over software z-sorting -while you could often sort blitter objects/polygons to be drawn in software z-sorted order, that doesn't work for sprites/windows drawn to a line buffer -with the framebuffer being treated as 1 solid object)
For that matter, having a Z-buffer on the Saturn would have made using VDP a lot more useful. (or just 3-bit per-pixel priority -since there's only up to 5 BG planes compared to hundreds of objects on the Jaguar ;))

OPL sprites aren't Z buffered - but you can blit Z-sprites ( read source and Z and test ) , even for general blits lying about Z would get you two reads then two writes to speed up copying slightly

Chilly Willy

11-19-2011, 07:01 PM

Why would the framebuffer impact that though? You overwrite each pixel drawn to the framebuffer, so independent objects no longer exist as far as that's concerned.

It's not like the alpha channel would be acting like a Z-buffer (defining depth of the current visible pixel) . . . oh, but if you were to use depth/Z sorting in addition to that alpha channel, it would matter, since some objects could be drawn "behind" the framebuffer if a lower depth priority. (but rather than not being drawn at all, they'd get blended with the translucent foreground)
For objects with higher priority than the framebuffer, that wouldn't matter though. (and a renderer specifically designed to render in Z sorted order with higher and higher priority objects rendered in successive passes, that wouldn't ever be necessary as the alpha channel of the textures would be all that matters -though that sort of renderer would suffer lots of overdraw without very efficient clipping/culling . . . and would also defeat the purpose of a Z buffer -though perhaps be desirable for a system relying on software z-sorting)
Plus, z-sorting on a per-object/per-polygon basis also avoids z-fighting. (or rather, you might get mis-sorted objects/polygons, but not patchy bleed-through/tearing within polygons -and indeed, the "z fighting" normally seen on software z-sorted renderers tends to be flickering polygons rather than tearing/bleeding on a pixel basis)

Also, a 1-bit alpha channel shouldn't necessarily just be on or off . . . it could be on (ie obscure all objects being drawn behind it) or 1/2 transparent (or made programmable for any other single fixed level of translucency), since being "off" (ie completely overwritten) would already be addressed by Z sorting.

Alpha doesn't work that way. 1-bit is on/off, not on/half-on. While you CAN do alpha affects without any alpha bits (Yeti3D does), you are stuck with however you hardcode the alpha (Yeti3D assumes 50% alpha for both the frame buffer and texture when doing alpha affects).

Say you want glass to be 25% alpha, but it's already been rendered to the frame buffer. How do you know what is glass and what is not in a frame buffer without alpha bits? And how do you know it's 25% if you only have one bit? Even hardcoding won't find already rendered polys with alpha, and if you have different levels of alpha (some 25%, some 30%, etc), then hardcoding won't handle that either.

kool kitty89

11-20-2011, 09:28 PM

Chilly Willy

11-21-2011, 12:15 AM

Oh, 1-bit alpha in the context of the texture end (not framebuffer end), defining a pixel as transparent or not . . . since you wouldn't want to have one of the 15-bit values reserved as transparent. (unlike indexed color textures, where a value is usually reserved as transparent -usually zero)

Yeah, sorry if that wasn't apparent. If you use 0x0000 as a 15-bit transparent instead of black, you would need to clear the frame buffer before drawing, but it would save that transparent/opaque bit. Some games do that, but that's usually for games without blending, just simple transparency.

kool kitty89

11-21-2011, 05:39 AM

Moved from:
http://www.sega-16.com/forum/showthread.php?11678-Polygon-rendering-Quads-vs-Triangles/page5

A.M.O.K. is a good mech shooter, and it looks great in its own way. I do think that Phase Zero looks like an early PS2 game though, it reminds me of Smuggler's Run in the way the ground looks, that is pretty impressive. The rest of the gameplay seems pretty run of the mill Battlezone fare.
Yes, and that's my point . . . it's not an amazing game on the gameplay/game design end, but it's an awesome showing of what a good voxel renderer could look like on the Jaguar.

When I said better than Amok, I was talking purely about the smoothness/quality of the voxel terrain, not any of the other aspects. (that's also what I meant when I said better than Rogue Squadron in some respects)
Though it would have been really interesting to see how Amok could have been done on the Jag. (obviously the polygon stuff would have been cut back to keep speed up, probably lower poly count and a lot of g-shaded-optimized models -like the original Mechwarrior II, but much smoother shading and probably better color- . . . and the framerate obviously would be nowhere close to Phase Zero -that game keeps things simple to push for speed . . . and doing so without dropping to a lower resolution -albeit low-res rendering probably would be the best option for reasonable speed on many types of 3D games on the Jag . . . and something more games probably should have done -like AvP; imagine if Doom hadn't made that sacrifice . . . exactly the problem 3DO Doom had -Yeti 3D on the 32x looks quite decent for being so low res, and small screen size seems to be a much bigger problem for people than low resolution -and the Jag has a really nice advantage for scaled-up low res windows since it has the object processor to do that -scale the framebuffer directly while scanning it rather than wasting drawing bandwdith -and the ability to overlay full-res sprites/windows too)

That's also not to say that other consoles couldn't have been pushing phase-zero quality voxels too . . . the Saturn and PSX might not have been able to do it (as well as the Jag, at least), but the N64 definitely should have (with proper RSP programming . . . and there's a lot of CPU resource too ;)), and obviously a fast PC. (Phase Zero's voxels aren't that far off from Outcast's for that matter . . . and that's saying something ;))

Part of that quality is dependent on CRY color too (those 256 shades lend exceptionally to interpolation/filtering), and you'd need 24-bit rendering to match that smoothness. (and obviously have better color effects in 24-bit than CRY can handle)
And the N64 could handle truecolor too, at the expense of more RAM for the framebuffer, of course.

Heh, that's another interesting note for the Jaguar: both the object processor and blitter can render in 24-bit RGB (unlike the 3DO Cel, PSX GPU, or Saturn VDP1), and the Jag blitter is actually just as fast at 24-bit texture mapping as 16-bit (or any depth -since it only reads/writes 1 pixel/textel at a time regardless -for affine rendering, mind you, not for simple 2D blits/fills -and certainly not for flat or gouraud shading, which it can do at 53.2 Mpix/s).
Also, since the GPU scratchpad is organized as 32-bit words, a cached 24-bit texture would take just as much space as one of another color depth. (since they'd need to be unpacked to 32-bit words)

Granted, the practical use of that is pretty limited: blitter based gouraud shading wouldn't work properly in 24-bit mode (since it relies on CRY's luminance channel -too bad 8-8-8-8 RGBY wasn't supported) though very nice additive color blending effects would still be possible. (and GPU effects as well -including software shading, but obviously at a fraction of the speed CRY does it -which is around 2x as fast as the PSX's gouraud shading) Then there's the issue that the blitter still doesn't do color look-up, so all textures would be 32bpp (or would need to be unpacked by the GPU), and (unlike CRY and 16-bit RGB modes) the OPL sprites also can't use color look-up (CRAM is 32-bits wide, but a bug prevents it from being used properly -a shame since they went to the trouble of making CRAM 32-bits wide as well as the line buffers -the latter being a much bigger sacrifice of chip space . . . though one that still meant direct 24-bit sprites could still be used)
Finally, there's the framebuffer size issue: 24-bit mode works on 32-bit pixels (even more of a shame there's no RGBY mode -or RGBA for that matter), so a 320x224 double buffered frame would take 460 kB.

Hmm, though, actually, if you DID do software look-up with the GPU (blitter texture expansion), you might as well go a step further and buffer several pixels at once in that operation (ie caching the texture -or a chunk of the texture- in SRAM) and significantly accelerating blitter texture mapping too. (at the expense of precious GPU time -needed for 3D transform, rasterization, lighting, and possibly game logic -since the 68k is such a poor alternative . . . as is the DSP for that matter -due to the crippled/buggy slow bus interface)
Of course, GPU resource is minimal for 2D (and some simple pseudo 3D) games that use affine texture mapping for scaled/rotated sprites alone (or mode 7 style warping effects), so there's far less trade-offs in those cases. (and using indexed textures saves precious RAM for more textures/animation/code/data/etc too)

And as I've already addressed a few times in recent posts . . . the Jaguar was certainly flawed and limited (albeit more by Atari's own position than anything else -including some of the technical problems undoubtedly), but the impressive aspects of the design aren't that it wipes the floor with the competition in raw performance, but that (in 1993) Flare managed to put together a quite powerful system with extremely tight engineering and extremely efficient cost to performance ratio that put hardware from contemporary (much better funded) companies to shame in those regards. (and in several respects, also DID wipe the floor with the competition -even some significantly later hardware, like the Saturn and PSX- in certain performance aspects . . . or many aspects for that matter, especially comparing the raw Jag chipset itself -ie Tom+JERRY, or mainly TOM- since the real-world performance is largely limited by the limited amount of RAM, single bus -and single bank at that- of said RAM, use of a slow/bus-hog of a CPU, etc -again, the CoJag is a prime example of re-configuring the chipset for higher perfomance, and in spite of being an arcade board, it was still quite conservative with RAM and CPU used -the use of dual-port VRAM in the 2nd bank probably being the biggest "splurge" in the system . . . such that it should still be lower cost than any of the 5th gen competition's hardware -of course, volume and vertical integration aside ;))

This also reminds me of some things I forgot to mention with the Jaguar II . . .
In spite of the total bus being 133 MB/s peak bandwidth, the peak texture mapping speed (for 16bpp) was actually as fast as solid/g-shaded filling (66 Mpix/s) for cached textures (an 8 kB texture cache was provided as well as 8k texture ROM with some generic/general-puspose patterns iirc), though much less for uncached textures (closer to 1/2 that) . . . and then there's the overhead for caching as well.
Of course, that's raw performance, and with the Jag II still being a low-cost optimized home console, it shared a single main bus like the Jag I, so that bandwidth had to be shared for game logic/3D math/etc too. (albeit with a lot more buffering/caching to allow more parallel operation -the added RCPU+cache being a big part of that, plus the beefed up blitter and 64-bit wide TOM+dedicated sound bus)
It was also still using slow FPM DRAM (60 ns, so 2 cycles per read/write minimum) . . . this may have been done to facilitate backwards compatibility, as otherwise it doesn't make that much sense. (30 ns EDO DRAM would have been pretty affordable by 1996 . . . and that would have meant 266 MB/s -and a system genuinely capable of outshining the PSX and Saturn on their terms -let alone with the added features specific to the Jag II, from the flexibility of the GPU and DSP to CRY shading to bilinear filtered textures, etc)

Hmm, what was the PSX's cached texture mapping performance? The GPU bus should support up to 66 million 16-bit pixels per second to be drawn . . . so if the GPU can keep up with that, it should be able to texture map from the cache at that speed. (of course, that would be theoretical peak bandwidth: framebuffer scanning and wait states would reduce that . . . not to mention updating the cache)

kool kitty89

12-01-2011, 02:05 AM

Continued from here:
http://www.sega-16.com/forum/showthread.php?11678-Polygon&p=428230&#post428230

The RDP has two methods of control: a command list ring buffer in memory that it DMAs from, and a FIFO from the RSP. The CPU can only use the command list - this is how libdragon works (libdragon is a homebrew SDK for the N64 - it currently doesn't use the RSP at all). The RSP can use both - for example, the RSP may turn a list of simple commands from the CPU into the proper RDP commands that go into the RDP command list, then supplement that with vertexes or other data on the FIFO.

The RDP handles all rasterizing, drawing, lighting, effects, etc. You can enable perspective correction, or disable it for affine mapping. The RDP handles textures, mipmaps, chroma keys, dithering (the N64 has three different RGB dither patterns and three different alpha dither patterns), scissors, zbuffering, etc. The RDP has so many things it does that SGI felt it too complex to control directly, hence the reason the program uses a simple command list which the RSP then turns into the RDP command list. If you know what you are doing, the program can control the RDP directly, as libdragon does.

The RSP is a "standard" 32 bit MIPS processor with no 64 bit commands, no multiply or divide, and no branch likely commands. What it does have is a vector unit as coprocessor 2. The vector coprocessor handles all matrix math and common SIMD operations. It only has 4KB of instruction ram for programs to run in, and 4KB of data ram for variables, but it has its own DMA channels it has full control over for fetching/saving data. So you have to be careful in the programs you give it, but otherwise it's very fast and powerful. Larger programs could be done by chaining overlays of code to DMA at the proper time into instruction memory. Most of the time, the N64 SDK simply has a 4KB binary "microcode" that is just the MIPS assembly program that interprets the N64 GBI (Graphics Binary Interface - the simple drawing commands the program uses for 2/3D) and the N64 ABI (Audio Binary Interface - various things like decompress ADPCM, mix channels, filter/echo/stereo-enhancement/QSound/etc).

So you could modify the RSP command translation program to allow interpretation of new/different simple commands from the CPU? (is that one of the issues with the standard APIs/RSP code offered in the SDKs -lack of flexibility for custom command decoding)
And is that what some "RSP microcode" references are actually alluding to (programming the RSP to decode simple commands to RDP commands), rather than referring to microcoding the vector unit? (since the "fast 3D" and "turbo 3D" microcodes seem to imply much more than varying VU usage, and more like differences in actual fillrate . . . so more like it's allowing a different set of RSP/RDP commands to be used -or, if it was only the VU, then there shouldn't be such impacts on fillrate, perspective correction, filtering/AA effects, etc -which the descriptions of Fast 3D and Turbo 3D imply as being different -as well as custom microcodes from a handful of developers)

Did Nintendo's standard tools/documentation limit the programmability of the RSP (the MIPS CPU core portion sounds like it should be quite straightforward to program), or is it really just the VU that was more problematic. (or was Nintendo extremely limiting of most aspects in general, and only allowed high-level access to most developers -more like the 3DO- . . . which would be a totally different case than the PS2 -which had very detailed low-level documentation, but limited API/library level support out of the box, at least early on -and especially in regards to the VUs from what I understand)

The N64's hardware actually seems a lot like the PS2 in many respects (the SGI/MIPS relation obviously, and the RDRAM, and the use of powerful vector coprocessors).

I wonder if 2D games would be among the types that would make more sense to have the CPU program the RDP directly rather than going through the RSP.

Crazyace

12-01-2011, 02:36 AM

Have a look for this game developer magazine article by Mark Deloura "Putting Curved Surfaces to Work on the Nintendo64" - ( I've got a print copy somewhere, but I've seen pdf's around ) - It shows how the RSP is used to implement bezier surface primitives

Chilly Willy

12-01-2011, 03:00 PM

So you could modify the RSP command translation program to allow interpretation of new/different simple commands from the CPU? (is that one of the issues with the standard APIs/RSP code offered in the SDKs -lack of flexibility for custom command decoding)

Yep! In fact, for LEGAL homebrew, you really need to make your own "microcode" from scratch as Nintendo's binaries are copyrighted. Most homebrew tends to use leaked SDKs from Nintendo and PsyQ. That's not legal in places like the US, but so far Nintendo hasn't made a fuss about it. They might if you tried to sell a game made with it - it's why the N64 Myth menu uses libdragon. Libdragon doesn't yet have a "microcode" binary - as I mentioned earlier, it builds the RDP command list directly from the cpu, not using the RSP at all. So far, it has RDP handled 2D, but not 3D.

And is that what some "RSP microcode" references are actually alluding to (programming the RSP to decode simple commands to RDP commands), rather than referring to microcoding the vector unit? (since the "fast 3D" and "turbo 3D" microcodes seem to imply much more than varying VU usage, and more like differences in actual fillrate . . . so more like it's allowing a different set of RSP/RDP commands to be used -or, if it was only the VU, then there shouldn't be such impacts on fillrate, perspective correction, filtering/AA effects, etc -which the descriptions of Fast 3D and Turbo 3D imply as being different -as well as custom microcodes from a handful of developers)

Correct. When they say they've "changed the microcode", they actually mean they modified the MIPS assembly program the RSP uses in some manner. Made it more efficient, faster, changed how it generates RDP commands, etc. You're not actually changing the hardware itself.

Did Nintendo's standard tools/documentation limit the programmability of the RSP (the MIPS CPU core portion sounds like it should be quite straightforward to program), or is it really just the VU that was more problematic. (or was Nintendo extremely limiting of most aspects in general, and only allowed high-level access to most developers -more like the 3DO- . . . which would be a totally different case than the PS2 -which had very detailed low-level documentation, but limited API/library level support out of the box, at least early on -and especially in regards to the VUs from what I understand)

Well, the SDK doesn't include much on the RSP itself beyond Nintendo's microcode interface they want you to use. It was probably too hard for the average dev. Now devs like Lucas Arts worked with SGI to make their own microcode that worked better than what Nintendo provided, but you expected that from folks like Lucas Arts.

The VU is rather "standard", having common vector math operations and common SIMD operations. It's the direct RDP that was the biggest pain... setting the OTHERMODE bits, setting the COMBINER, etc. SGI had a bunch of rather involved macros for generating the RDP command list entries. I can see where most folks would be intimidated by it. Not to mention Nintendo hinted at multiple versions of the hardware that would only be handled by sticking with their high level interface. It didn't work out that way (seems to be only two revisions of the hardware with only very minor changes), but I can see where Nintendo may have thought at one time that the next console after the N64 would use an update of the N64 hardware (very much like the Wii is an update of the GC hardware).

The N64's hardware actually seems a lot like the PS2 in many respects (the SGI/MIPS relation obviously, and the RDRAM, and the use of powerful vector coprocessors).

The vector units on the PS2 are actual processors that run instructions to process the data in a vector/SIMD fashion. Do not confuse that with "coprocessor" extensions to processors like on the MIPS. The vector coprocessor of the RSP is NOT a processor itself, merely a unit that performs set operations when told to by the processor; it is not programmable and doesn't run an instruction sequence. Think of it like the math coprocessor for old x86 CPUs or the 680x0 CPUs - the CPU fetches an instruction it knows is for the coprocessor, it decodes the instruction, fetches the operands (data), sends the data to the coprocessor along with what the coprocessor is to do with the data, waits for the result, then stores the results.

Actually, the N64 is much more like the PSP than the PS2. The PSP has two MIPS processors, but the main one has the vector unit and controls the video while the secondary one controls the media accelerator (FMV, compressed audio, etc). The N64 has two MIPS processors, but the secondary one has the vector unit and can control the video/sound.

I wonder if 2D games would be among the types that would make more sense to have the CPU program the RDP directly rather than going through the RSP.

Maybe, but I think it would be better to make a custom RSP program that acts like a 2D VDP, handling drawing cells with scrolling and rotation, and going through sprite lists. That would have helped 2D devs coming off systems like the Genesis, SNES, etc. The dev could have then pretended he was on a souped up 2D console.

kool kitty89

12-01-2011, 08:32 PM

Yep! In fact, for LEGAL homebrew, you really need to make your own "microcode" from scratch as Nintendo's binaries are copyrighted. Most homebrew tends to use leaked SDKs from Nintendo and PsyQ. That's not legal in places like the US, but so far Nintendo hasn't made a fuss about it. They might if you tried to sell a game made with it - it's why the N64 Myth menu uses libdragon. Libdragon doesn't yet have a "microcode" binary - as I mentioned earlier, it builds the RDP command list directly from the cpu, not using the RSP at all. So far, it has RDP handled 2D, but not 3D.

Correct. When they say they've "changed the microcode", they actually mean they modified the MIPS assembly program the RSP uses in some manner. Made it more efficient, faster, changed how it generates RDP commands, etc. You're not actually changing the hardware itself.
So the RSP is more of a customized MIPS based MCU, and with normal assembly language-level CPU tools (ie not limited to by-hand machine language coding), the RSP should be programmable with similar effort as other MCUs.

Actually, comparing it to the RISC GPU in the Jaguar, you've got 2x the scratchpad size (Jag only has 4k local RAM), and bugs with the GPU also prevent it from running code from main memory (without workarounds that Atari didn't provide) so perhaps even less limited in some respects. (albeit it can directly use data from main RAM, and can copy code/data to the scratchpad, though it sounds like the RSP can also page code/data to the scratchpads . . . the Jag GPU also uses 16-bit length instructions, so code density would be higher too -somewhat like SuperH) Plus Atari provided an assembler and other tools beyond what Nintendo seems to have offered to the RSP. (it actually had a complier too, but it was so broken and inefficient that virtually noone used it -John Carmak made his own compiler later on as part of Jaguar Quake development)

Hmm, actually, if Sega had designed a GPU along the lines of the RSP+RDP, it probably would have made a lot of sense to use an SH1/SH2 derivative as the graphics controller. (maybe with a beefed up fixed-point multiplier or removed entirely in favor of an integrated FPU -in the Jaguar/JagII's case, the RISCs used fast, fixed-point multiplication with software floating point support)

Well, the SDK doesn't include much on the RSP itself beyond Nintendo's microcode interface they want you to use. It was probably too hard for the average dev. Now devs like Lucas Arts worked with SGI to make their own microcode that worked better than what Nintendo provided, but you expected that from folks like Lucas Arts.
Basic assembler and debugging tools for the RSP probably would have done wonders for the programmability/flexibility of the system.

Not to mention Nintendo hinted at multiple versions of the hardware that would only be handled by sticking with their high level interface. It didn't work out that way (seems to be only two revisions of the hardware with only very minor changes), but I can see where Nintendo may have thought at one time that the next console after the N64 would use an update of the N64 hardware (very much like the Wii is an update of the GC hardware).
That sounds like what 3DO did, except not quite as extreme (3DO went well beyond cautioning/warning and didn't allow any options outside of their standard libraries -albeit even then there seems to have been some problems with compatibility on some hardware variations -one of the many pitfalls of the licensed architecture model . . . though the high margins/prices of the base units would be the bigger problem by far ;))

[QUOTE]The vector units on the PS2 are actual processors that run instructions to process the data in a vector/SIMD fashion. Do not confuse that with "coprocessor" extensions to processors like on the MIPS. The vector coprocessor of the RSP is NOT a processor itself, merely a unit that performs set operations when told to by the processor; it is not programmable and doesn't run an instruction sequence. Think of it like the math coprocessor for old x86 CPUs or the 680x0 CPUs - the CPU fetches an instruction it knows is for the coprocessor, it decodes the instruction, fetches the operands (data), sends the data to the coprocessor along with what the coprocessor is to do with the data, waits for the result, then stores the results.
OK, so it's more like a conventional FPU coprocessor (internal or external) for various architectures, or like the vector coprocessor extensions in the Dreamcast's CPU.

Would the SPEs of the Cell processor be more akin to the PS2's VUs?

Maybe, but I think it would be better to make a custom RSP program that acts like a 2D VDP, handling drawing cells with scrolling and rotation, and going through sprite lists. That would have helped 2D devs coming off systems like the Genesis, SNES, etc. The dev could have then pretended he was on a souped up 2D console.
Sort of like the PSX GPU's sprite mode? (at least from a high-level perspective)

Efficient use of the texture cache should really have catered well to cell/sprite style rendering. (since you're guaranteed to draw the entire cell/stamp, avoiding some of the trade-offs of 3D texture caching)

Chilly Willy

12-01-2011, 08:57 PM

So the RSP is more of a customized MIPS based MCU, and with normal assembly language-level CPU tools (ie not limited to by-hand machine language coding), the RSP should be programmable with similar effort as other MCUs.

You can use the same assembler for the RSP as the main CPU. The NeoN64 NES emulator (has no relationship to NeoFlash) uses the same assembler for all code, VR4300 or RSP. Just remember the restrictions (no mult or div or branch likely). If you wished to use the VU, you would need to make macros.

Actually, comparing it to the RISC GPU in the Jaguar, you've got 2x the scratchpad size (Jag only has 4k local RAM), and bugs with the GPU also prevent it from running code from main memory (without workarounds that Atari didn't provide) so perhaps even less limited in some respects. (albeit it can directly use data from main RAM, and can copy code/data to the scratchpad, though it sounds like the RSP can also page code/data to the scratchpads . . . the Jag GPU also uses 16-bit length instructions, so code density would be higher too -somewhat like SuperH) Plus Atari provided an assembler and other tools beyond what Nintendo seems to have offered to the RSP. (it actually had a complier too, but it was so broken and inefficient that virtually noone used it -John Carmak made his own compiler later on as part of Jaguar Quake development)

Like I said, you can use the regular assembler, but Nintendo didn't make any effort to document all that (at least none that have surfaced). The code density is something to be concerned with, so you would want to use hand-tuned assembly. At least they made the instruction memory separate from the data memory so that you don't "waste" data space on instructions. So as long as you ignored the extra VU instructions and handled the RDP with the main cpu, you could do whatever you want with the RSP. As mentioned, the NES emulator uses it for video and audio emulation.

Basic assembler and debugging tools for the RSP probably would have done wonders for the programmability/flexibility of the system.

The assembler was there, but they needed a macro include file for the extra VU instructions. And some docs. :)

OK, so it's more like a conventional FPU coprocessor (internal or external) for various architectures, or like the vector coprocessor extensions in the Dreamcast's CPU.

Yes. Precisely.

Would the SPEs of the Cell processor be more akin to the PS2's VUs?

Yes. The SPEs seem to just be an extension of the PS2 VUs. That was probably Sony's contribution to the Cell design, with IBM providing the PPE, and no idea what Toshiba brought to the group... I think they probably helped Sony on the PS2 EE, so they might have co-designed the SPEs.

Sort of like the PSX GPU's sprite mode? (at least from a high-level perspective)

Efficient use of the texture cache should really have catered well to cell/sprite style rendering. (since you're guaranteed to draw the entire cell/stamp, avoiding some of the trade-offs of 3D texture caching)

The texture cache is almost perfect for a cell. Think about it - 32x32 at 32 bits. Anywho, Nintendo included 2D drawing commands VERY similar to the 2D polygon commands of the PSX. So any of the 2D games on the PSX could have very simply been done with the existing libs on the N64. I think Nintendo was discouraging that kind of 2D by that point, trying to ride the 3D wave started by the PSX. It was a mistake to ignore 2D like that.

kool kitty89

12-02-2011, 03:08 PM

The texture cache is almost perfect for a cell. Think about it - 32x32 at 32 bits. Anywho, Nintendo included 2D drawing commands VERY similar to the 2D polygon commands of the PSX. So any of the 2D games on the PSX could have very simply been done with the existing libs on the N64. I think Nintendo was discouraging that kind of 2D by that point, trying to ride the 3D wave started by the PSX. It was a mistake to ignore 2D like that.
Some claim that Sony actively discouraged 2D too (though it seems more like they encouraged 3D rather than discouraging anything), but the PSX certainly got a good chunk of 2D games in any case.

I wonder if Nintendo was more limiting about that (especially since they had generally tighter/stricter control over software manufacturing -and licensing contracts in general).
Plus, it probably didn't help that many of the prominent 2D game publishers (at least the Japanese ones) had largely turned away from Nintendo by that point -mainly out of frustration with Nintendo's past and present treatment of them, and Sony (and Sega for that matter) giving a competitive and attractive alternate publishing platform. (and Nintendo wasn't doing any favors to those publishers either -the N64 itself epitomized many of the worst/unattractive aspects of Nintendo -at least from 3rd party publishers' perspectives- with the use of carts -and continued tight/limited Nintendo-only manufacturing- being a prime example)

Though there's a few US/EU developers that worked well on the N64, but still didn't push many/any of their 2D games on it. (like some Lucasarts developed -or at least published- games . . . though in the case of Herc's Adventures, that also wasn't published on PC -which is even stranger from a Lucas Arts title of the time)

saturndual32

12-02-2011, 03:25 PM

sheath

12-02-2011, 03:31 PM

In order for Radiant Silvergun to be perfectly ported to the Jag, the Jag would need to be able to handle all of the 2D background layers and 3D that game is pumping out, using the VDP 2 and VDP 1's hardware capabilities, in software. Since Radiant Silvergun was scrapped for the PS1 thanks to the lack of VRAM I sincerely doubt any developer would have wanted to make it work on the Jaguar.

Black_Tiger

12-02-2011, 06:01 PM

I hate how missinformed we, gamers, were back in the mid 90s. I remember magazines claiming that the Playstation was weak in 2d compared with Saturn, and that the N64 hardware wasnt very good at 2d. It turns out that the 3 systems were actally pretty comparable in that regard. Its also funny how in a matter of months, the Jag (in my view), was taken from being the biggest 2d monster from the era, to actually being weaker than the "no good at 2d" PS1 and N64, let alone the Saturn, which as a Jag fan, was quiet dissapointing. Hell, i remember reading comments from Gorf at AtariAge a long time at all, saying that he didnt see why Radiant Silvergun shouldnt be possible in the Jag:daze:.

Considering that the three consoles are also as comparable in 3D capability, you can see that some things never change. ;)

Radiant Silvergun would still look great and possibly better in full 2D and could play the same. Technically, none of the consoles could do an exactly-the-same port of a game from one if the other systems, just as 16-bit consoles had enough fundamental differences to keep ports at least slightly different.

Chilly Willy

12-02-2011, 07:05 PM

What I find odd is that even the "2D" games on the N64 are really 3D with a fixed camera. Does anyone know an N64 game that is REAL 2D? Even if the N64 wasn't designed for "standard" 2D, it had WAY more power than needed to fake it. Something like the original Rayman would have been child's play to do on the N64. Instead, they went for Rayman 2, the 3D version of the game. Granted, Rayman 2 was a great game as well, but not doing the first meant Nintendo had to go a couple years without a Rayman game on the N64. Maybe they thought the market for the first was dead by then, but it rather fit the market Nintendo was trying to hit, and Nintendo DID release it on the GBA.

kool kitty89

12-02-2011, 07:48 PM

Considering that the three consoles are also as comparable in 3D capability, you can see that some things never change. ;)

Radiant Silvergun would still look great and possibly better in full 2D and could play the same. Technically, none of the consoles could do an exactly-the-same port of a game from one if the other systems, just as 16-bit consoles had enough fundamental differences to keep ports at least slightly different.
Actually, the N64 could probably do a nearly perfect 1:1 port of Silvergun (or better if tweaks were made for specific features of the system).

It's more like comparing the Master System to the PC Engine in some respects than any 16 bit console with another of that generation. (or the Xbox with the Dreamcast perhaps -or maybe more like the GC and Xbox) With the exception that the N64 didn't have the same RAM capacity advantages (without expansion) . . . even if you take the wasted framebuffer and CD buffer space into account, the N64 only has moderately more useful work RAM than the Saturn. (albeit it's all in a shared pool, so you wouldn't need to move extra data around to different subsystems -ie if you wanted to store extra animation in main RAM rather than VDP1/VDP2 RAM, or especially if VDP2 RAM wasn't 100% utilized either, and the greater ability to use compressed sound samples -that flexibility is certainly a major advantage to unified bus systems, in addition to exceptional cost effectiveness -especially with greater optimization for bus sharing)

In order for Radiant Silvergun to be perfectly ported to the Jag, the Jag would need to be able to handle all of the 2D background layers and 3D that game is pumping out, using the VDP 2 and VDP 1's hardware capabilities, in software. Since Radiant Silvergun was scrapped for the PS1 thanks to the lack of VRAM I sincerely doubt any developer would have wanted to make it work on the Jaguar.
Anything with texture mapping (including 2D rotating sprite effects -let alone warping/rotating sprites/BGs) will have problems on the Jaguar for the same reason that texture mapped 3D will. (the blitter is slow at doing that)

Scaled sprites can be done very fast on the jaguar as those are handled by the blitter (that's also one of the most impressive features of the Panther -which the Jaguar's object processor is directly related to), but anything requiring rotation can't be done that way. (flat and gouraud shaded filling can also be done exceptionally fast, similar to unscaled sprites -and faster than scaled sprites . . . though that's just filling, not rasterization -which needs further GPU overhead to assist the blitter in drawing and then the overhead for 3D vertex math on top of that)
Blitter scaling is similarly slow due to that aspect of the hardware.

That's also why the texture mapping issue is one of the biggest oversights Flare made . . . it's NOT just a problem for 3D, but a liability for 2D as well. (and odd that they left that hole in the system -a feature very useful for both 2D and 3D/pseudo 3D effects- yet they put all that engineering effort -and chip space- into Z-buffer logic, and of course the custom J-RISC GPU/DSP core -the most substantial engineering achievement of the entire system, and the largest block of transistors present on the TOM ASIC)

There's also a good argument for going with an all-blitter based system in general over a sprite/object/list based system . . . slower in raw drawing speed for some things, but much more flexible and with that bandwidth spread out on a per-screen basis rather than per-line. (the very reason the Saturn's VDP1 isn't necessarily weaker than the Jaguar's Object processor in spite of technically having 1/2 the pixel bandwidth)
That design decision of the Jaguar is actually a bit ironic given Flare's previous design did take the all-blitter route (the Slipstream/Flare 1) as did the followup to that project (MSU's later system, sometimes called the Multisystem 2).

I hate how missinformed we, gamers, were back in the mid 90s. I remember magazines claiming that the Playstation was weak in 2d compared with Saturn, and that the N64 hardware wasnt very good at 2d. It turns out that the 3 systems were actally pretty comparable in that regard.
Its also funny how in a matter of months, the Jag (in my view), was taken from being the biggest 2d monster from the era, to actually being weaker than the "no good at 2d" PS1 and N64, let alone the Saturn, which as a Jag fan, was quiet dissapointing. Hell, i remember reading comments from Gorf at AtariAge a long time at all, saying that he didnt see why Radiant Silvergun shouldnt be possible in the Jag:daze:.
From a cost to performance standpoint, the Jag arguably has advantages, but in some areas it doesn't beat the PSX in 2D, let alone Saturn or N64. (it's down to bandwidth, and in that respect, the N64 wins by miles over all the others -5x the peak bandwidth of the Jaguar, more than double the combined bandwidth of all the PSX's subsystems, and still nearly double that of the Saturn -but perhaps better still due to the flexibility of all-framebuffer/blitter rendering rather than blitter/sprite+tilemap BG generation . . . and you'd need a very sprite-light BG-heavy biased game to really come close to giving the Saturn an advantage in bandwidth)

The N64 RDP also has more effects than the others, including better alpha blending capabilities. (and the same flexibility advantages of sprite+BG priority/effects as the PSX -or other blitter based systems- had over the Saturn's VDP1+VDP2 set-up -going VDP1 alone would have similar flexibility, but with much weaker overall performance than the N64, and significantly less than the PSX too)

The N64 should be totally superior for both 3D and 2D over all other consoles of that generation . . . similar to how the Dreamcast or late 90s gaming PCs were. (though not quite so extreme)

It's only the software that falls short on the N64. (more so in lack of quantity than quality even -since there's basically no high-budget 2D games on the N64)

The N64 was considerably more advanced hardware in general. It's not like the SNES where (in spite of significantly newer hardware) the technical advantages were hit and miss even under ideal circumstances (RAM capacity, memory speed/bandwidth, resolution, CPU resource, sound capabilities, etc were still going to have trade-offs with the MD and even PC Engine's capabilities taken to their best -with problems on the software end further exacerbating things- compared to the N64 where the hardware -aside from the storage media- was superior in performance across the board by a wide margin, and only the software end of things was the issue -partially the tools/documentation, but more so in terms of general support, especially for 2D games . . . and the use of carts put it at a major disadvantage too -and exacerbated lazy programming aspects too, like using low-res textures -since carts would mean less incentive to use high-res textures at all, and tend to induce creative programming/resources being pushed more towards making the most of limited ROM space -like specialized art design, compression algorithms -for mass storage and on-the-fly loading, etc)

I mean how many PSX/Saturn (or PC, or newer console) games bothered with optimizing compression to cram more data onto a single disc rather than just using more discs? (and having a hell of a lot of space in the first place -and relatively simple options for cutting back on streaming audio space used via lower bitrate PCM or ADPCM -or MP3 later on- or use of realtime sound engines where desirable -something forced on the N64 in most cases . . . and streaming audio being limited to fairly low bitrate mono tracks for the most part where there were used)

Imagine what PSX or Saturn games would look like if they were cart based.

Hell, the use of carts on the Jaguar had a big impact too, on top of the other technical (and more so) financial/marketing/etc problems. (especially with the super-low-cost emphasis meaning a huge number of games were only 1MB/8Mbit or 2MB/16MBit and a select handful of 4MB/32Mbit games -like Doom)
That was probably an even bigger limiting factor for texture mapped 3D than the blitter performance limitations.