"extra" RAM

[LinkoVitch]

Do we really need those "what if..." topics in the Programming forum, too?

 

What if.. there were no pointless what if questions? Would that have saved Atari and killed off the PlayStation, causing Sony to reverse merger with Costa Coffee and produce budget coffee makers? hmmmmm ;)

[kool kitty89]

Would something like this not work for an SD cartridge? If it pulls the read data from one eeprom slot which loads the SD card could another slot not be dedicated to a custom RAM chip?

Why not just use an SD cart that uses SRAM as the simulated ROM, but allow for games to reserve part of that address space for variable use. (or rather than 'reserve' just require software to manage the memory in a responsible manner and avoid writing to address space that's supposed to be treated as ROM)

 

Some of the Mega Drive (and I imagine SNES, GB, etc) flash carts are actually SRAM carts, though I'm not aware of homebrew software exploiting that. (it's just a design choice and leads to faster loading and avoiding burn-out of flash memory)

 

 

 

 

Still be sharing the same physical data bus internally, so you are still going to have CPUs fighting for access to the memory, only one can control the bus at any one time.

 

If you were to add additional RAM 16bit wide for the purpose of CD enhancement, you would have a few extra things to do. Games now need to be more complicated, as they have to support with and without the extra RAM, or simply require anyone using them has the cart. Developing for those games requires you have some way of connecting the extra ram cart whilst you are developing, (BJL, or some form of riser/splitter card).

 

Plus, anything that wants to talk to the CD-Unit and the memory is going to need to keep toggling the cart bus configuration in the memcon registers to switch between 8bit and 16bit mode. That *might* get messy if you have multiple CPUs vying for bus access, need to be very careful one of them doesn't leave the configuration in an unexpected state for when the next one comes along (68K loses bus control as it is lowest priority whilst a blit happens).

 

It's extra complexity for no real benefit.

 

Firstly, it at very least greatly benefits texture mapping speed, especially for large textures where buffering them into GPU SRAM or line buffer SRAM would be impractical. (plus GPU SRAM chokes the GPU if used for textures, while at least line RAM exploits allow the GPU to continue working) So you can actually hit the peak 5.32 Mpixels/s fillrate of the blitter for texture mapping (or scaled/rotated objects ... or just scaled objects where you need per-pixel granularity with the framebuffer that OPL sprites wouldn't provide ... you can use the Z-buffer for OPL sprite priority overlapping a 3D scene, unfortunately)

 

I was also mistaken earlier, it's not 10, but 11 cycles to render a single pixel when texture mapping. 2 cycles for the read, 3 for rowchange, 1 for R/W change, 2 for write, another 3 for rowchange and repeat.

Using 2 separate banks of DRAM (or any memory with cycle times no more than 5 cycles) takes 5 cycles instead, I thought it could be faster but see below for Kskunk's quote: the blitter can't render textures faster than 5 cycles (26.6 MHz ticks) per pixel, thus the worst-case timing in DRAM (5-cycles for a read+rowchange) wouldn't slow down the blitter at all.

 

To put it another way, for a game that uses texture mapping in main memory, you'd spend 45.5% of the time you normally would on the bus, and that much more time for other things. (the more texture-heavy a game is, the more dramatic the advantage)

 

 

 

On the 'back then' hypothetical end, we could argue the Jag CD came bundled with the RAM cart at its release in 1995, if you want to fixate on the split development base issue. (and in the case of a 32kx16-bit PSRAM chip on-cart or a pair of 32kx8-bit SRAMs, it would've been both cheap and foolproof enough to pull off: with a DRAM cart, it might be cheap enough, but I could imagine delays in actually implementing a little DRAM controller/interface ASIC if they weren't planning ahead ... they obviously hadn't planned ahead for RAM expansion given the lack of external connectivity for the unpopulated main DRAM bank: that would've been cheaper and simpler to expand than any of the above, and taken fewer pins given the multiplexed nature of DRAM ... a little 40-pin edge connector would've been sufficient for a 16-bit DRAM interface, that or just put the DRAM control lines on the cart slot for intended expansion use)

 

Or if they were really planning ahead, perhaps even arrange the Jaguar's DRAM originally as 512kB 64-bit in one bank (4 64kx16-bit DRAMs) and 1MB 32-bit DRAM in the second (two 256kx16-bit DRAMs) while still using a 32-bit wide cartridge bus, but adding the necessary DRAM control signals and allowing that connector to serve both as the interface for the cart address space at 32-bits wide AND to allow expansion of the other 32-bits of the second DRAM bank. (ie the CD add-on could have another 1MB 32-bit wide chunk of DRAM, but mapped to the same 64-bit addresses as the existing 1MB bank, interleaving on a 32-bit word basis and now providing two complete 64-bit DRAM banks, 2MB + 512kB ... and now you could have a cart passthrough without touching any of the cart ROM address space ... plus it's cheaper, no DRAM controller, much more seamless, and much more generally useful for the fast, fully 64-bit portions of the system)

 

On top of all that, the Jag would've been moderately cheaper to manufacture at launch and still a good bit more flexible/powerful due to the reduced bus contention. (fewer page-breaks by doing more work in different DRAM banks as much as possible, plus faster texture mapping and faster 32/64-bit blits as well, as source could be in one bank with destination in the other, keeping nice 2-cycle page mode accesses going) And 1.5 MB was still plenty for the time, and much nicer than what Sega CD or 32x programmers had to work with. Now if they wanted to get fancier and make JERRY slightly less crippled, they'd have also added a 32-bit wide CPU in place of the 68k. (68EC020, 386DX, ARM60, maybe one of the lower-end embedded flavors of AM29000 series, etc ... the 020's I-cache would help a bit too, but whatever was cheapest would be best ... the Jag was already designed with big or little endian in mind, so reconfigurating that would've been less an issue ... a Cyrix 486DLC with the 1kB on-chip cache also was nice ... or IBM's similar chips, but those probably would've only been cheap from the desktop PC perspective, not from an embedded system/console standpoint: the AM29000's low end options also lacked cache, but you've got the massive array of 192 32-bit registers to consider ... a neat complement to the 64-register J-RISCs)

 

 

 

But more to the point at hand: Jerry is more of a bottleneck in the CD than with cart games as you can have it work largely in ROM to read samples or other data or copy code (or have the blitter copy chunks to JERRY's SRAM) while avoiding hitting main DRAM and thus avoiding performance-killing page-breaks caused by rowchange. (Jerry's accesses are so slow anyway that ROM isn't that big of a bottleneck, and games using it basically just for audio would be fine, even if doing sample based music+SFX, especially if streaming compressed sampled 2/4-bit ADPCM or even CVSD would be interesting, or 2-bit flavors of CVSD: 2, 3, and 4-bit ADPCM flavors had long been promoted by Covox as low-overhead compression formats for PCs, targeting the low-end systems using parallel port DACs, but applicable to pretty much anything else capable of PCM too: CVSD, especially 1-bit CVSD is obviously better suited to speech compression than musical instruments; plus the DSP can do filtering and interpolation of lower sample rate stuff and minimize both ROM space and bus time needed to stream the samples ... and still probably sound a lot nicer than the SNES, quality of compositions aside of course)

 

In any case, without ROM, the DSP now needs to read from main DRAM, which means page-breaks for TOM where there might otherwise just be some waits. Meanwhile, adding even a chunk of slow RAM (or even a small chunk of RAM) would offload that significantly

 

 

 

That aside, wouldn't handling RAM on cart be similar to using ROM of a similar width? (likewise you COULD directly texture map from ROM, but it would've been slow back then, usually 8 cycles, 10 for slow/cheap stuff iirc, plus it'd mean using uncompressed 16-bit textures rather than unpacking them into RAM)

 

Now you also could've had carts that had RAM right on them, like several 7800 games did and some SNES and even MD games (well ... just Virtua Racing with the DRAM for the SVP chip, I think, ignoring SRAM for battery saves) and a couple 7800 games had even used 32kx8-bit SRAM chips back around 1987 (both Summer and Winter Games did that iirc, only using 16kB as that's what they needed for the memory map they used and because 2 8kB chips took up too much space to fit, and the cost of 32kB was cheaper than a modified cart PCB/case at the time, apparently) so 64kB of 16-bit SRAM/PSRAM slapped on cart wouldn't seem too unusual for 1994-96 ... or later. (had the Jag done well with carts). But you needed at least enough confidence in the platform and investment funds handy to actually manufacture carts like that. (making masked ROMs at all was a big problem, and a big reason some folks suggested the Jag should've been a CD system from the start ... not for performance, but for sheer economy of development and attracting more devs and publishers who'd otherwise be unwilling to risk the overhead of a ROM based system: that and Atari could do things like ship out free demo discs both pack-in with consoles and at promotions, and even jump onboard the wave of Shareware distribution at the time ... plus still be vastly cheaper than the 3DO, but that's yet another topic)

 

 

But on the issue of bus sharing and interleaving, is there too much of a delay for granting the bus to TOM, the OPL, or Blitter to do any useful interleaving between slow, periodic accesses? Like the 8-cycle reads of the 68k (not that it even hits the bus for every memory cycle) or 6-cycles for DSP. I believe you only need a 73-ish ns (2-cycles at 26.6 MHz) period for the actual read/write strobe, and while you couldn't interleave accesses in a single bank of DRAM at that speed (as there's 3 cycles for rowchange and another to switch read/write if needed) having accesses in different DRAM banks with different rows being accesses and held open (for page mode) would allow overlap of everything but the actual read/write strobes.

 

Now, a higher priority processor on the bus couldn't take open cycles from a lower one as it already has priority, so you need situations where the slow processors have priority, but leave enough time to grant one or more accesses to lower-priority processors/DMA-channels/etc (any bus master). The 68k is normally bottom priority, so would be difficult to actually put in a situation where TOM, the Blitter, or OPL could waiting for holes in 68k accesses to work, but the DSP normally has fairly high priority and that could be exploited. Further, the 68k has higher priority when doing interrupts, so coding a game where the 68k is being used pretty much exclusively as an interrupt handler would make that arrangement viable. (as such you could potentially split up general processing duties between the DSP and 68k while not too horribly hogging the bus)

 

 

From the Jaguar Refrence Manual V8

 

 

The CPU normally has the lowest bus priority but under interrupt its priority is increased.

The following list gives the priorities of all bus masters.

Highest priority

1.

Higher priority daisy-chained bus master

2.

Refresh

3.

DSP at DMA priority

4.

GPU at DMA priority

5.

Blitter at high priority

6.

Object Processor

7.

DSP at normal priority

8.

CPU under interrupt

9.

GPU at normal priority

10.

Blitter at normal priority

11.

CPU

Lowest priority

 

 

 

 

 

 

 

 

 

 

Put a cache and a command queue into the blitter and you'll get much better performance.

 

The Jag II fixed that with double-buffered blitter registers instead. And I say fixed and not 'would have fixed' as I'm pretty sure that was functional on the preproduction Oberon (Tom II) chips used on the development systems in 1995. (Puck was not on those, just old Jerry, as crippled as ever, except 32-bits wide thanks to using the 68020 in place of the 68k ... something they might not have needed to retain for the production version if Puck's features worked correctly, allowing a cheap 68000 to be stuck on there for compatibility: indeed, better compatibility than an '020 would provide, plus a 68k would have been a reasonable fit on the slow 16-bit sample RAM bus Puck was to use, sort of like the 68EC000 in the Sega Saturn audio system)

 

 

 

 

 

 

 

Do we really need those "what if..." topics in the Programming forum, too?

Playing devil's advocate here, I'd point out that Kskunk's skunkboard (and any modern homebrew ROM cart based games that got enough traction to be manufactured in masked ROM) could be run fast enough to allow texture mapping from ROM without waits, but more than that it could allow GPU code/data/DMA fetches from ROM at full speed as well. (using the high speed ROM cycle mode that was originally intended for testing only) The blitter and OPL doing 64-bit bus operations would still be faster in DRAM though, in cases where serial access can exist.

 

But beyond that, you could build an SRAM cart that could either be simple SRAM (only useful for loading from CD), made into a passthrough cart and only using part of the address space (allowing ROM as well, possibly bank-switched), or just a full 6 MB 70 ns SRAM cart used for CD homebrew. Or add an SD card interface (or CF, XD, etc: the latter would probably be easier given it's parallel, but SD is obviously the most popular and what most 'flash' carts use, regardless of whether they load into flash memory or SRAM on-cart: the latter has the advantages of speed and not wearing out from successive writes)

 

And given the hardware hacking stuff folks do (overclocks included), I'd think wiring up the unused DRAM bank would also be an interesting possibility ... probably not as simple as the old piggyback RAM upgrade on the ST, but also not totally different. (and SOJ leads aren't too bad to work with ... touching the leads on TOM would be iffy OTOH)

 

Oh, and Kskunk's experimenting with texture mapping on internal SRAM showed that the logic for calculating scaling/rotation in the blitter limited pixels to 5 cycles at best, so even random read/write DRAM speed would be fast enough to do texture mapping at the peak rate. (that would include page-breaks in the second DRAM bank or a slower DRAM controller onboard a cartridge with no page-mode support and basically behaving like PSRAM at the 5-cycle cart I/O mode)

 

https://forum.beyond3d.com/posts/1936444/ (Nammo is Kskunk)

 

By snooping around the HDL, I figured out the speed limit of the blitter: 5 cycles/pixel. The constraints are annoying, but you canfree the RISC's on-die bus for pipelined rasterization, even at that speed. (Just don't touch external RAM.)

 

There's also stuff in that thread about rendering directly to the line buffers and potentially doing beam-racing style 3D at 50/60 Hz, but that's better for another thread.

 

 

 

 

What if.. there were no pointless what if questions? Would that have saved Atari and killed off the PlayStation, causing Sony to reverse merger with Costa Coffee and produce budget coffee makers? hmmmmm ;)

My current new favorite is actually: what if Atari spun off Flare II's Jaguar II project to Sega in 1996 during all the second-guessing with the Saturn. (plus the unfinished Puck chip with RCPU and DSP could be displaced by some neat Hitachi Super H RISC chip with built-in UART and such ... or an Power PC 602, convenient 64-bit bus there) But again not the topic here.

 

More on topic I'd say would be bundling a 512kB DRAM cart with the CD to boost performance/flexibility a bit might've made an impact, that and they just had bad luck of choosing to cut their losses early in 1996 before DRAM prices dropped like a rock. (they had the misfortune of test-marketing the Jaguar at about the same time of the big Formosa resin factory fire in Japan that cause RAM and other IC prices to jump up then stagnate, just like they did in 1988: the latter hurt the ST big time and crippled the 1040ST's potential of becoming the bottom-end standard, plus made the Amiga end up price matching the ST that year ... the 520STfm and A500 starting 1988 at $300 vs $500 and meeting at $400 mid-year)

 

Granted, the reason Atari desperately needed good luck to survive was mostly related to Sam Tramiel's abysmal management. (Atari Corp was best under Jack and Mike Katz ... 1985-88)

 

 

Oh but I doubt anyone would bother with a DRAM cart for modern homebrew. SRAM is much easier to do and cheap enough not to bother with anything else, plus 2-cycle read/write times offers more flexibility for the fast parts of the system. (the DSP and 68k would be fine with 186 ns cycles ... the DSP can only do reads at 6-cycle intervals anyway, and the 68k takes 4, but 8 system clock cycles as it runs at half the speed)

Edited March 1, 2018 by kool kitty89

[swapd0]

The Jag II fixed that with double-buffered blitter registers instead. And I say fixed and not 'would have fixed' as I'm pretty sure that was functional on the preproduction Oberon (Tom II) chips used on the development systems in 1995. (Puck was not on those, just old Jerry, as crippled as ever, except 32-bits wide thanks to using the 68020 in place of the 68k ... something they might not have needed to retain for the production version if Puck's features worked correctly, allowing a cheap 68000 to be stuck on there for compatibility: indeed, better compatibility than an '020 would provide, plus a 68k would have been a reasonable fit on the slow 16-bit sample RAM bus Puck was to use, sort of like the 68EC000 in the Sega Saturn audio system)

 

Cool, so if you draw two scan lines of a wide polygon you can't send the next one because the blitter is still drawing the first scan line ... bad solution.

 

IMHO the problem with the jaguar is that they build the first version and they released it to the market, they never asked to the developers for bottle necks, also I don't understand why no one in Atari complained about having 5 processors on a slow shared bus.

[Welshworrier]

That's numberwang!

[philipj]

 

Oh, and Doom might have still been easier to code on a 1 MB (.5 MB 64-bit .5 MB 16-bit) Jaguar in spite of the lower RAM quantity due to better use of 68k and DSP, as well as ability to keep textures in the 16-bit bank for faster access. (and given how much profanity Carmack left in his comments of Jag Doom's source code, you can bet the bugs /and/ broken DSP bus controller were high on his lists of complaints) That's also still way more RAM than the 32x port had to work with slightly later (adapted from Jag Doom's source code no less) and that port also had to make do with less ROM (3 vs 4 MB). Jag Doom probably would've had some nice music in such a situation as well. (though 32x Doom also has a 7.67 MHz 68000 with its own private bus and 64 kB of PSRAM to work in totally in parallel, though I think 32x Doom just slaves the 68k to I/O and sound and leaves the brunt of things to the 32x side)

Hi Kool Kitty... When I think about "Virtua Racer" for both the Geny and the 32X, I think it's clear to see that the Genesis version, with the extra processor on the chip uses full 16bit to crunch the 3D numbers in order to pull off those fast graphics thus the same principle can apply in practice for the Jaguar system. I believe they did it right when they made DOOM for the Jag by optimization of the GPU being a rasterizer while the other processors handle the pseudo 3D engine. I think the DSP having full access main ram without slowdown from the 68K can be very tempting reason to cut the 68K off, but over time my view has changed a little from that notion.

 

Still be sharing the same physical data bus internally, so you are still going to have CPUs fighting for access to the memory, only one can control the bus at any one time.

 

If you were to add additional RAM 16bit wide for the purpose of CD enhancement, you would have a few extra things to do. Games now need to be more complicated, as they have to support with and without the extra RAM, or simply require anyone using them has the cart. Developing for those games requires you have some way of connecting the extra ram cart whilst you are developing, (BJL, or some form of riser/splitter card).

 

Plus, anything that wants to talk to the CD-Unit and the memory is going to need to keep toggling the cart bus configuration in the memcon registers to switch between 8bit and 16bit mode. That *might* get messy if you have multiple CPUs vying for bus access, need to be very careful one of them doesn't leave the configuration in an unexpected state for when the next one comes along (68K loses bus control as it is lowest priority whilst a blit happens).

 

It's extra complexity for no real benefit.

Well it took a few years for the game "Battlesphere" to be created so you probably have a point there... It is possible, however, to individually time your processors in a way that's optimal for fast simple programs and even fast 3D programs in regards to main ram access. That gives me hope for the use of the 68000, which I've always felt would be a shame to not put to good use since it's already there. Another thing to consider is the fact that the DSP seems to handle math a whole lot faster than it can handle graphics; so that means it could be possible for graphics to be processed in the form of math instead of bitmaps, jpeg/JagPEG, whatever the format. But you're probably right; the Jag have so many bugs in it, I nearly turned my back on that d@m system, but I still would like to see some innovative stuff come from the Jaguar.

[philipj]

 

Cool, so if you draw two scan lines of a wide polygon you can't send the next one because the blitter is still drawing the first scan line ... bad solution.

 

IMHO the problem with the jaguar is that they build the first version and they released it to the market, they never asked to the developers for bottle necks, also I don't understand why no one in Atari complained about having 5 processors on a slow shared bus.

Dude you can't imagine how many times I've been down that quote "What If" road and you're absolutely right... Atari got greedy and released a lemon to the market. But at some point one has to except whatever flaws the Jaguar has and work with what's already there.

[JagChris]

I don't think those swear words were Carmacks. I think they were Dave Taylors.

[JagChris]

Dude you can't imagine how many times I've been down that quote "What If" road and you're absolutely right... Atari got greedy and released a lemon to the market. But at some point one has to except whatever flaws the Jaguar has and work with what's already there.

And so many of the Jags problems were solved by third-party developers trying to innovate. and Atari just didn't listen when developers tried to share these innovations.

[+CyranoJ]

And so many of the Jags problems were solved by third-party developers trying to innovate. and Atari just didn't listen when developers tried to share these innovations.

 

I agree. Rebellion were the best.

[philipj]

And so many of the Jags problems were solved by third-party developers trying to innovate. and Atari just didn't listen when developers tried to share these innovations.

Point made... Could've changed the game early on if they'd listen. These days I'd rather just focus on something new for the Jaguar. I just purchased my third Skunkboard so I'm a little pumped about doing some Jag stuff.

[justclaws]

Where do you get a Skunkboard these days? I'm hoping not via Ebay auctions, else I'm definitely out of the game.
Cheers, Richard.

[JagChris]

Whoops link gone

Edited March 30, 2018 by JagChris

[kool kitty89]

 

Cool, so if you draw two scan lines of a wide polygon you can't send the next one because the blitter is still drawing the first scan line ... bad solution.

 

IMHO the problem with the jaguar is that they build the first version and they released it to the market, they never asked to the developers for bottle necks, also I don't understand why no one in Atari complained about having 5 processors on a slow shared bus.

A command cache (or scratchpad ... or just prefetch queue) for the blitter probably would've been the more elegant and practical solution, yes, but I was mostly just summarizing a comment kskunk made on the issue years back.

 

That said, wouldn't the rasterization situation also be different on the Jaguar II given Oberon's blitter had a trapezoid drawing function, so you only need to build lists of trap-segments to build triangles (or quads) rather than line by line rasterization. (incidentally, I believe several of the early PC 3D acceelrators worked on trapezoids internally for doing polygon drawing, some documented such as well: it's in the S3 ViRGE manual, at least described in the section on 2D polygon rendering depicting the trapezoidal segments used for arbitrary polygon fill operations)

 

And on the texture mapping bottleneck, John Carmack's suggestion (in the context of something cheap and simple that they should have already included) was a 64-bit destination buffer in the texture mapping pipeline. (though given how slow the texture mapping unit is, given kskunk's 5-cycle peak test results, that wouldn't help all that much for raw speed, no more than populating the second DRAM bank the system already supported ... so it's somewhat moot there, though I'm also unsure Carmack was aware of the existing support in the DRAM controller or the 5-cycle bottleneck of the blitter)

 

kskunk and several others (Gorf, Crazyace, I think maybe Atari Owl) also went over the problems using GPU SRAM as a texture cache, particularly how it kills GPU performance if used heavily, however, kskunk's later tests seem to point to use of the line buffers as texture RAM to be a lot more useful, possibly also useful as a texture render buffer. (the latter wouldn't be faster per se, but rendering from line buffer RAM into line buffer RAM, then blitting to the framebuffer in 64-bit, phrase-alligned chunks, would greatly reduce time on the bus and that much less contention).

 

Honestly, for a game like Quake with the lighting model used, dropping textures entirely at a certain distance (Z-sorted as an extension of the existing ray-casting visibility system a la PC Quake) would've made a ton of sense to minimize texture mapping overhead. (PC quake also already was heavily optimized on minimizing actual rendering time, lots of computation or table based optimizations to spend as little bandwidth as possible drawing to the framebuffer, and an engine like that would adapt well to the Jaguar's bottlenecks, albeit trading more of the tables for raw realtime computation and trading the Pentium FPU pipeline-specific tricks for other things)

 

 

Hi Kool Kitty... When I think about "Virtua Racer" for both the Geny and the 32X, I think it's clear to see that the Genesis version, with the extra processor on the chip uses full 16bit to crunch the 3D numbers in order to pull off those fast graphics thus the same principle can apply in practice for the Jaguar system. I believe they did it right when they made DOOM for the Jag by optimization of the GPU being a rasterizer while the other processors handle the pseudo 3D engine. I think the DSP having full access main ram without slowdown from the 68K can be very tempting reason to cut the 68K off, but over time my view has changed a little from that notion.

The SVP-chip version of Virtua Racing used a 16-bit DSP to handle the 3D math, yes, though I think it also assisted with drawing the polygons using the 128kB of DRAM the cart included as a framebuffer as well as work RAM (or local memory for paging things in and out of local DSP memory). It's a DSP though, not a CPU or MCU (so unlike the 32x or even the primitive 16-bit RISC MPU in the Super FX chip) and not good for all that much else, not flexible general purpose processing like the Jaguar's GPU and DSP, but good for 3D and probably OK for simple pixel/line/block fill operations. (as a DSP it also should have done well as a sound processor, but Sega didn't use it as such ... no DACs or audio input lines connected on that cart)

 

Unlike the Jaguar, but like the 32x, you did have multiple buses to work with, and the local DRAM able to be flipped on and off the 68k bus for copying the render buffer into VRAM.

 

Now, the MD's 68k was still fast enough to do some software rendering on its own, and having a much simpler DSP co-processor that simply handled the vertex math and left all the rasterization to the 68k probably would've worked better than SuperFX driven 3D on the SNES (or been competitive, at least), but there's no other examples of co-pro or add-on chips used on the Mega Drive at all, unless you count the Mega CD. (and unfortunately, unlike Mode 7 in the SNES, the fast multiplier unit that must be embedded in the Sega CD Gate Array for the scaling/rotation function isn't directly accessible to either CPU, otherwise it'd be handy for polygonal 3D when the scaling/rotation function wasn't in use ... really handy if they still let the Gate-Array's blitter functionality work for simple copy/fill operations in proper nibble-precise tilemap pixel organization, but ... nope: honestly, with the amount of RAM it had along with that sort of hardware assist, I'd think it would've handled Virtua Racing well enough and probably a solid port of X-Wing, at least the more limited floppy disk version for PC, flat shading, 1MB RAM compliance and such)

 

The Jag was way more powerful than any of that, though ... but yes, being able to interleave 68k access to some extent would give the advantages of a separate/local bus as on the MD. I'm not sure how the timing of the bus latches in the Jaguar work or if interleaving was really a major consideration, but it certainly had been when Flare designed the Slipstream and included a 16-bit bus latch to minimize time the 8086 spent on the bus (in that case interleaving on PSRAM cycles with the CPU working in SRAM or DRAM on the same bus: the video processor would only work in PSRAM, so the bus cycle interleaving was based around the 12-ish MHz video DMA clock, fetching a 16-bit word once ever 4 12MHz clocks). The Slipstream 4 (1993 vintage hardware done in parallel with the Jaguar) switched to dual DRAM banks with page-mode support and up to 32-bit bus width, but the intended 12 MHz 386SX should still have interleaved with video DMA cycles for most video modes provided it worked in the separate DRAM bank. (the blitter and DSP DMA may have remained serial only with the CPU, though)

 

The 68k also doesn't need to hit the bus all that often to stay nearly at full speed, so having a feature to have consistent, periodic wait states for slow-ish interleaved bus access would've made it a far better investment in the system as a whole, albeit using a 20 MHz rated 68k and running it at 3/4 the system clock (19.95 MHz) would've probably been more useful as well. (you don't need the 68k bus cycles to allign with the system bus cycles anyway, not like ST/Amiga style 4-T-state interleaving, so the 1/2 system clock rate wasn't all that useful other than just being cheap/simple to divide) That and they probably spent way too much on Jerry given its limited use (it's a decent audio DSP, but too bottlenecked with its very slow bus cycle times and some other bugs, and need to page code to local RAM to work, thus nixing it as a stand-in as CPU: at least when coupled with the slow bus connection, opposed to paging code modules to the GPU; the DSP even made a poor geometry processor as writes to main RAM were twice as slow as reads, slower than 68k writes in fact: 12 cycles for a 16-bit word, while reads were less crippled at a hard-coded 6 cycles). The DSP's slow bus cycles would have made it reasonable for interleaved access on a separate memory bank (the second DRAM bank and ROM bank) but otherwise it's pretty crippled and a serious bus hog. (compared to just including a rudimentary DMA sound/UART ASIC ... or possibly including an embedded, easily licensed low-cost MPU like a 65C02 or 65816 a la Lynx ... as a sound processor or maybe in leu of the 68k, though it'd make coding in C a lot tougher ... for lazy C or 68k assembly source ports, for what that's worth)

 

Well, that, or the Flare II team could have ditched the 68k and JERRY some time early in 1992 in favor of a nice, flexible microcontroller. Hitachi's SH-1 had just been released, and would've been really appealing as a low-cost CPU+sound processor combo, but aside from happening to catch that brand new design being released, there was also AMD's embedded range of the 29000 series, particularly the bottom-end of its microcontrollers in the family, the AM29205. (both that and the SH-1 had onboard DRAM controllers, both also used 16-bit data buses for lower cost and pin count, so also would have been fairly simple to include a local, dedicated bus to work in rather than sharing the graphics bus ... Flare could've just dropped to a conventional main bus + GPU bus layout and also used a simpler, 16-bit cart slot and copy/DMA data to the Jaguar graphics bus through I/O ports rather than sharing everything ... plus, no fragile and more expensive 32-bit MCB/VESA/PCI-ish connector for the cart slot to deal with, just something close to SNES/Mega Drive, or ISA slot pins) Though, that said, it also shouldn't have been too tough for flare to include a (slow) 16-bit DRAM controller and basic sound hardware (possibly the 16-bit Flare DSP or just DMA sound) and UART on a 16-bit bus controller ASIC to complement a 13.3 or 19.95 MHz 68000. (a unified bus reduces cost, but swapping JERRY for a much smaller, simpler, and slower ASIC, possibly with a lower pin count also saves costs and would have just made more sense ... it also could have used gate array logic, slower, lower density, but for a much smaller and simpler custom chip it would have the advantages of being much easier to prototype, faster to bug-fix, and cheaper to start up production than the standard cell ASICs used for TOM and JERRY)

 

 

Oh also note, the 3DO was horribly bottlenecked when it came to anything short of solid-shaded polygons as heavy use of textures (3D or 2D) was mutually exclusive with CPU operation as main RAM was texture/sprite/etc RAM, plus it used forward texture mapping (like the Saturn, and Lynx for that matter, though just sprite-drawing) where textels are read out a line at a time and drawn over multiple times to the screen if down-scaled or folded, reducing fillrate further and also breaking translucent blending and gouraud shading. (or corrupting both due to drawing folded pixels multiple times and warping the shading gradient). Plus you had strict liberary-level coding on the 3DO without the ability to clean up bad compiler output with some hand-tuned ARM assembly.

 

If the Jaguar had a bit of smart bus interleaving on multiple memory banks, the 68k might not have fared that badly next to 3DO games. (albeit the CD-ROM mass storage issue was a factor for actual software development ... and PC games that the Jaguar really would've been well suited for: especially various flight/combat sims using shaded 3D or limited texture mapping ... and heavy keyboard commands that made the Jag-pad really appealing)

 

 

 

Dude you can't imagine how many times I've been down that quote "What If" road and you're absolutely right... Atari got greedy and released a lemon to the market. But at some point one has to except whatever flaws the Jaguar has and work with what's already there.

They weren't greedy, they were poorly managed (I blame Sam Tramiel mostly) and extremely desperate, plus it was also just poor timing as DRAM prices stagnated from 1993-1995 and finally dropped again just after the Jaguar was discontinued. (by fall of 1996, the Jaguar Duo could probably have been a genuine low-cost/budget range alternative to the PSX and Saturn ... and the idea of including a RAM expansion cart as standard and offering it at a very low price to existing users would all have been feasible)

 

But in 1993, Atari was desperate, they had a big lawsuit over old patents pending with Sega (which would create a windfall in 1994) but in the mean time they were struggling, downsized to a skeleton of a company, and made the decision to discontinue their computers, somewhat marginalize the Lynx, and put a ton of effort into a Jaguar propaganda campaign to drum up investor cashflow, and it worked: it scared the crap out of Sega (at least the Japanese executives) and got Motorola and IBM onboard for manufacturing along with sufficient investment backing to bring the thing to market. Still, it was wholely mismanaged and the UK/European market entrance was both late and particularly poorly supported ... all really bad decisions on top of cancelling the Falcon. (cancelling the Falcon in the US and continuing to market computers only to the smaller, easier to support/market to UK and European market, or at least the UK, France, and Germany, would've been more reasonable ... moreso if they'd worked the Jaguar chipset, or TOM specifically, into a second-gen Falcon project, like as part of the Falcon040 or a lower-cost '030 counterpart)

 

The further irony, of course, is that CBM fell out of the computer market, leaving a void for the Wintel invasion to finally take the UK/Europe at a time Atari might have continued to compete (especially with the shift towards open-source GNU OS extension development with MiNT/MultiTOS), plus Sega ended up dropping the Game Gear, leaving even less competition for the Lynx. (plus the Game Boy Color failed to even match the Lynx's hardware and continued cost/size/power reduction left tons of room for Lynx updates to compete)

 

Atari's lack of a significant mainstream game console from 1990-1993 (or given the Jaguar remained niche ... from 1990 onward) was a big gap on top of the ST and 7800 sales struggling somewhat in '89, and Sam Tramiel's management ... or perhaps more specifically: Jack's retirement as CEO and Mike Katz's leaving as president of the Games division seriously crippled the whole operation. Katz thought failing to agree on terms with Sega for Mega Drive distribution was a mistake, but even that aside, I can't imagine he couldn't have guided things better after that with the Panther development, Lynx release, Panther cancellation and possible short-term alternatives, etc. (they needed something reasonable to launch in 1990-91, maybe 92 ... and a 'fixed' Panther without so many shortcomings or a derivative of one of the many incremental developments of Flare's Slipstream ... or a much more conservative Jaguar, which would also fall into the 'fixed' Panther configuration: ie support for FPM DRAM operation, enough RAM for a decent-sized framebuffer, addition of a blitter, integrated sound hardware, and some intention for polygonal 3D, but without the custom RISC architecture being implemented: the Flare DSP was enough for geometry co-processing along with CPU-assisted triangle set-up and blitter line fills)

 

Anyway, I wouldn't blame greed as one of the Jaguar's main problems, or Atari's ... though lack of honesty might have been a major problem along with poor management and negotiation skills on Sam's part. (dishonesty with developers during the Jag's lifespand seemed to be one of the problems ... dishonesty with investors was too, which was forgivable to some extent in 1993 with Atari being on the verge of collapse, but much less so after they got market recognition and just seemed to go ... weird or incompetent with what added resources they were afforded) The late introduction of the CD add-on, DRAM prices keeping the base system price point high, and Sony's splash in the market all didn't help, of course.

 

Actually, with all that in mind, Atari probably made a bad bet dropping computers in favor of a new game console ... the Jag chipset (or just TOM) might have been more successful in the Falcon series than it ended up as a console. (as it was, I think the Jaguar's sluggish sales didn't compare too well to the Falcon's sales for the short time it was on the market) Plus the DRAM cost overhead was a lot more justified in a computer system, and floppy disk software was the norm, so no cart vs CD headache to decide over (or be the only console on the market using floppy disks ... especially in 1993/94), plus ... TOM would've been a lot more potent alongside a 68030 on a dedicated bus (even the 16 MHz 030 on the 16-bit bus of the Falcon 030), and that's not just hindsight ... though obviously pure spec-fic fantasy. (well ... I can't help but imagine Jack Tramiel would've put more interest in working a potent new graphics/multimedia processor into a low-cost, mass market home computer rather than 'just a games machine' ... but ... )

 

 

 

 

 

 

 

 

Oh, and, back on the topic or real-world relevant stuff:

I'd missed out on the new (or last couple years of) Jaguar Flash cart development project (and thread on that), so my comments on a RAM cart earlier in the thread are a bit moot there, as such a RAM cart is in the works, just not Jag-CD oriented. 16 MB of SDRAM acting as cart ROM or RAM is pretty neat, though I'm not sure the 16 or just 6 MB (no bank switching) is planned on being implemented, but the project looks super neat. (and totally relevant to some neat workarounds for homebrew programmers to exploit ... provided folks are interested in that, and interested in digital distribution of freeware or online store style software distribution ... or crowdfunded early access sponsored stuff with free distribution later on ... that and just freely distributed tech demos and hacks, as are common for homebrew on a bunch of old game systems and several computers, even 'obscure' or 'failed' ones like the 32x)

[doctorclu]

Where do you get a Skunkboard these days? I'm hoping not via Ebay auctions, else I'm definitely out of the game.

Cheers, Richard.

 

Holy crap, Justclaws posted!

[Welshworrier]

And it looked like Mexico was going to have to pay for the other post

[neo_rg]

If you can't get one I can lend you one if needed.

[Zerosquare]

Welcome back Justclaws

[LinkoVitch]

Where do you get a Skunkboard these days? I'm hoping not via Ebay auctions, else I'm definitely out of the game.

Cheers, Richard.

 

By jove it's that chap! Glad to see you are still about squire! Do you think you'll be making e-Jagfest this year?

[justclaws]

 

By jove it's that chap! Glad to see you are still about squire! Do you think you'll be making e-Jagfest this year?

 

I suppose it's months away, which is good, because right now, I know less than ever about what my future holds. I was made redundant. Looking for an employer who wants an extreme-IT-versatilist. :-)

[LinkoVitch]

 

I suppose it's months away, which is good, because right now, I know less than ever about what my future holds. I was made redundant. Looking for an employer who wants an extreme-IT-versatilist. :-)

 

That's crap! Hopefully it's the start of a new awesome adventure for you squire. I have ended up going the contracting route, maybe worth a consideration, had a few clients that like having someone who can turn their hand to most things computer shaped.

[Zerosquare]

Looking for an employer who wants an extreme-IT-versatilist.

Oh that's not hard to find, plenty of companies want to hire a single person to fix ALL of their IT problems.

The trouble begins when you start explaining to them that versatility has a price...