Its 1993, you're in charge of the Jag, what do you do?

[Gorf]

Factor 5 was also involved in the Resident Evil 2 port to N64, all the content from the 2-dic game crammed ono a 64 MB cartridge, all the streaming video, all the prerendered backgrounds, all the levels and even with some improvements to the graphics.

 

I think Phaze Zero is much more impressive considering the Jag is a few years older tech.

[philipj]

I'm not saying that a 68020 will be worse than the 68k , I'm just not interested in it if the GPU/DSP can run C code directly from main memory. In my view it's a waste of money that would be better off spent on the CD.

 

I think a better C compiler would've made for a better tool set then what Atari originally provided and would've made deving for the Jag a lot more attractive considering that at the time it seemed like C was becoming more commonly used then Assembler. Certainly would've made homebrewing a lot easier then it was.

[Crazyace]

It would have facilitated developers in getting games out much more quickly and at higher quality. (instead of bypassing the 68k, minimizing it, ot throwing in the towel and using the 68k a lot, they could put all game logic and AI onto the 020 with little hit to the bus, all writen in C, then work with the GPU, blitter, and DSP for rendering and sound engine) Now, improvements on top of the 020 would have been awesome.

 

Also, it would have meant more developers staying on rather than dumping the Jag because of its shortcomings. (then again, a bug-free TOM+JERRY only jag could have been similar, albeit still weaker overall than even a buggy jag with 020 -where you could completely dedicate TOM to rendering and Jerry to sound+I/O)

If the GPU/DSP bugs had been fixed developer would have programmed the game code in C for them , with assembly for performance loops. Think of how Doom was written, but without the paging in/out of the local memory.

 

Wouldn't that be solved if the blitter was double buffered? (avoiding the necesity for GPU intervention)

Not on the registers, the breaks occur because the blitter is reading from one page to get the texels, and writing to another to draw the line. It even occurs on blits, but is worse for texturing as that has to be pixel rather than phrase mode.

I shouldn't really have bothered suggesting it - it was only a throwaway idea.

[JagChris]

It would have facilitated developers in getting games out much more quickly and at higher quality. (instead of bypassing the 68k, minimizing it, ot throwing in the towel and using the 68k a lot, they could put all game logic and AI onto the 020 with little hit to the bus, all writen in C, then work with the GPU, blitter, and DSP for rendering and sound engine) Now, improvements on top of the 020 would have been awesome.

 

Also, it would have meant more developers staying on rather than dumping the Jag because of its shortcomings. (then again, a bug-free TOM+JERRY only jag could have been similar, albeit still weaker overall than even a buggy jag with 020 -where you could completely dedicate TOM to rendering and Jerry to sound+I/O)

If the GPU/DSP bugs had been fixed developer would have programmed the game code in C for them , with assembly for performance loops. Think of how Doom was written, but without the paging in/out of the local memory.

 

Lets try this once more. Ideally yes the GPU bugs should of been fixed or the work arounds known, but they were not necessary to make an extremely effective C compiler for them as HVS proved.

[Crazyace]

Im not trying to insult anyone. Im pointing out that you keep diverting away from the original issue. What

I would do and why I think it would be necesary. I feel I've been more than logical and it's as if you did

not listen. I would say more fustrated than insulting.

 

You've presented your argument, but I disagree with it - not because of your arguments - the 68020 would be faster in a jaguar.

I just dont think that would save the console.

I guess the problem is that my disagreeing with you seems to be 'diverting' in your eyes. Why is that, the original topic is 'what would you do?'.

You would add a 68020 - I'd fix the gpu/dsp main memory bug, drop the 68k, add CD.

 

The trouble with this is even a single speed CD ROM woudl have it's obvious slowdowns to the system.

I think the 020 is a much more well rounded solution for the many reasons I stated and I also and quite

positive that it would have been much more welcome thatn a CD ROM that does little for anything but

fluff added to already piss poor games. The 020 would be a mutli faceted improvement in all the

important areas.

Yes, a single speed CD would have slowdowns. But it would also add CD quality background music, and video playback ( better than Sega CD or PC video at the time due to the better colour on the jaguar ), and lot's more storage.

('piss poor games' - is a different topic completely though)

Hoverstrike on CD seems no worse than Hoverstrike on cart - WorldTourRacing is fine on CD, so I expect that most games would have played pretty much the same as the cart versions.

 

A 68020 is an argument for programmers - if the topic was 'what would make the jaguar more powerful' , I'd agree with your arguments.

For me though, a CD would have been better for Atari's business and profitability.

[Crazyace]

Lets try this once more. Ideally yes the GPU bugs should of been fixed or the work arounds known, but they were not necessary to make an extremely effective C compiler for them as HVS proved.

 

Yes, a C compiler could generate good GPU/DSP code, but still paging in/out of local memory was needed. ( I think Doom's renderer was compiled as well )

Fixing the main memory bug would allow any C code to run on GPU/DSP - maybe it wouldn't be wonderful optimised assembly, but it would still be faster than 68k asm ( or even 68k C ) and Atari would have a single toolchain to optimise ( or 3rd parties could provide better compilers )

[kool kitty89]

X

Edited December 22, 2009 by kool kitty89

[kool kitty89]

If the GPU/DSP bugs had been fixed developer would have programmed the game code in C for them , with assembly for performance loops. Think of how Doom was written, but without the paging in/out of the local memory.

Yeah, but that assumes you've got the necessary time and funding to work out the additional bugs. (using a 68EC020 souldn't have added any development time)

Also, i though Doom on the Jaguar still used a good chunk of work on the 68k. (I've heard mixed info on these forums, but Chilly Willy -current 32x homebrewer over at sega-16 and on spritesmind- was commenting on the Jaguar Doom code and said it apeared to have a lot of C coding targeting the 68k, with mostly assembly used for anything RISC)

 

Not on the registers, the breaks occur because the blitter is reading from one page to get the texels, and writing to another to draw the line. It even occurs on blits, but is worse for texturing as that has to be pixel rather than phrase mode.

I shouldn't really have bothered suggesting it - it was only a throwaway idea.

OK, well maybe they could have done a split bus with 1 MB 32-bit bus (2x 512 kBx16-bit DRAMs) plus 512 kB 64-bit (4x 16-bit 128 kB DRAMs), but even then you'd add cost due to the greater amount of board space among other issues, pluis less flexibility of RAM useage, and less total memory available. (the single bus design was one of th ekey features of the Jaguar's design -and low cost emphesis) A cache for the RISCs (even just one) would have been a much more significant feature, but that would have required a lot more invested in development. (and somehting Flare/Atari weren't willing to risk)

 

 

Factor 5 was also involved in the Resident Evil 2 port to N64, all the content from the 2-dic game crammed ono a 64 MB cartridge, all the streaming video, all the prerendered backgrounds, all the levels and even with some improvements to the graphics.

 

I think Phaze Zero is much more impressive considering the Jag is a few years older tech.

 

Well, yeah, voxel engines are really cool, particularly if you think they're actually polygon environments at first. (then again, who knows what the N64's RSP might have been capable of with custom microcode tailored to such rendering)

 

Yup, keeping 64 bits would still be better for the OP and for phrase blits without pagemisses. ( You'd have to use different ram chips, as the jaguar used 4 16 bit wide drams )

 

Static RAMS are no wait state or cycle losses for the GPU or DSP and those would have been much nicer

but a lot more costly.

Wait, are you taliking about using SRAM for main? (which is completely unrealisic)

Edited December 22, 2009 by kool kitty89

[Gorf]

If the GPU/DSP bugs had been fixed developer would have programmed the game code in C for them , with assembly for performance loops. Think of how Doom was written, but without the paging in/out of the local memory.

Yeah, but that assumes you've got the necessary time and funding to work out the additional bugs. (using a 68EC020 souldn't have added any development time)

Also, i though Doom on the Jaguar still used a good chunk of work on the 68k. (I've heard mixed info on these forums, but Chilly Willy -current 32x homebrewer over at sega-16 and on spritesmind- was commenting on the Jaguar Doom code and said it apeared to have a lot of C coding targeting the 68k, with mostly assembly used for anything RISC)

 

Not on the registers, the breaks occur because the blitter is reading from one page to get the texels, and writing to another to draw the line. It even occurs on blits, but is worse for texturing as that has to be pixel rather than phrase mode.

I shouldn't really have bothered suggesting it - it was only a throwaway idea.

OK, well maybe they could have done a split bus with 1 MB 32-bit bus (2x 512 kBx16-bit DRAMs) plus 512 kB 64-bit (4x 16-bit 128 kB DRAMs), but even then you'd add cost due to the greater amount of board space among other issues, pluis less flexibility of RAM useage, and less total memory available. (the single bus design was one of th ekey features of the Jaguar's design -and low cost emphesis) A cache for the RISCs (even just one) would have been a much more significant feature, but that would have required a lot more invested in development. (and somehting Flare/Atari weren't willing to risk)

 

 

Factor 5 was also involved in the Resident Evil 2 port to N64, all the content from the 2-dic game crammed ono a 64 MB cartridge, all the streaming video, all the prerendered backgrounds, all the levels and even with some improvements to the graphics.

 

I think Phaze Zero is much more impressive considering the Jag is a few years older tech.

 

Well, yeah, voxel engines are really cool, particularly if you think they're actually polygon environments at first. (then again, who knows what the N64's RSP might have been capable of with custom microcode tailored to such rendering)

 

Yup, keeping 64 bits would still be better for the OP and for phrase blits without pagemisses. ( You'd have to use different ram chips, as the jaguar used 4 16 bit wide drams )

 

Static RAMS are no wait state or cycle losses for the GPU or DSP and those would have been much nicer

but a lot more costly.

Wait, are you taliking about using SRAM for main? (which is completely unrealisic)

 

 

It's not unrealistic at all...just expensive. The T&J using statics, even externally run as fast

as if they were in the local. I already stated it would have been costly.

[Crazyace]

If the GPU/DSP bugs had been fixed developer would have programmed the game code in C for them , with assembly for performance loops. Think of how Doom was written, but without the paging in/out of the local memory.

Yeah, but that assumes you've got the necessary time and funding to work out the additional bugs. (using a 68EC020 souldn't have added any development time)

Also, i though Doom on the Jaguar still used a good chunk of work on the 68k. (I've heard mixed info on these forums, but Chilly Willy -current 32x homebrewer over at sega-16 and on spritesmind- was commenting on the Jaguar Doom code and said it apeared to have a lot of C coding targeting the 68k, with mostly assembly used for anything RISC)

 

For me, the code execution bugs should have been high priority - especially as there would be no 68k at all. ( They would have been 'must fix' on the first spin of the h/w , rather than 'will not fix' on the 2nd and production chips )

( It's always better to fix bugs, rather than add extra h/w - Fixing the bugs is a fixed cost , whereas if you add $10 to the unit cost of every console it really hurts, especially when the cost reduction phase starts. On the 'real' Jaguar they weren't fixed because they weren't considered to be important bugs, and there was no extra cost involved )

 

 

Regarding Doom - there were discussions about the renderer coming from some custom compiler setup that ID had. I'm not that fussed - it was one of the better Jaguar games anyway, ( especially compared to the competition ) - my feeling is that it's sales wouldn't have been much more even if it had been slightly smoother.

[Gorf]

You've presented your argument, but I disagree with it - not because of your arguments - the 68020 would be faster in a jaguar.

 

It would also make game development faster as no more need to debug GPU assembly.

Quick, easy to debug C code could have been written swiftly for the 020, which

would run it off the bus 80-85% of the time, only hitting the bus occasionally

to grab more code. Then the time for assembly would be spent on the renderer

and the music system. All the real involved game mechanics would be a breeze

on the 020. Atari could have then spent some time getting the most efficient

renderer and sound system into developers hands instead of wasting tons of time

fixing RISC tool bugs.

 

Also the system would be at least 150% more efficient allowing quicker ports

of PC games.

 

You would add a 68020 - I'd fix the gpu/dsp main memory bug, drop the 68k, add CD.

 

No I would replace the 68k with an 020 as well as fix the bugs. Especially another 64

longs of 32 bit registers for the write backs to eliminate any stalls and a double

buffered Blitter reg file to eliminate any waiting on the GPU or GPU waiting on the

blitter. Oh the interrupt bugs of the OPL too.

 

Yes, a single speed CD would have slowdowns. But it would also add CD quality background

music, and video playback ( better than Sega CD or PC video at the time due to the better

colour on the jaguar ), and lot's more storage. ('piss poor games' - is a different topic

completely though) Hoverstrike on CD seems no worse than Hoverstrike on cart - WorldTourRacing

is fine on CD, so I expect that most games would have played pretty much the same as the cart versions.

 

A single speed would do nothing for more color in video as the slowness of a 1X would not

allow that kind of data to flow at any decnt frame rate. the 2x barely got away with it.

 

But adding music or video play back never sold a system. Most of the PS1 games at launch

like Krazy Ivan were rather bland in this respect but it was loaded with a few dozen

titles you could play. This would have been the case with an 020 Jaguar, even without

a CD. Good games do not need FMV or music play back.

 

A 68020 is an argument for programmers - if the topic was 'what would make the jaguar

more powerful' , I'd agree with your arguments. For me though, a CD would have been

better for Atari's business and profitability.

 

I dont see how. We'd have the same slow system with more data capability. You might sell a

few more units to the FMV/Music lovers but hardly enough to satisfy the hard core gaming

public. The Jag needed more games and the 020 instead of a 68k, even without bug fixes

would have cost little in the way of dev tools and programming effectiveness would

skyrocket. The Jag was popular at first not because of it's medium, but because of

it's promise of games that you could not do on other systems. Even cart based it would

have beaten the 3DO out much worse than it already did.

Edited December 22, 2009 by Gorf

[JagChris]

Lets try this once more. Ideally yes the GPU bugs should of been fixed or the work arounds known, but they were not necessary to make an extremely effective C compiler for them as HVS proved.

 

Yes, a C compiler could generate good GPU/DSP code, but still paging in/out of local memory was needed. ( I think Doom's renderer was compiled as well )

Fixing the main memory bug would allow any C code to run on GPU/DSP - maybe it wouldn't be wonderful optimised assembly, but it would still be faster than 68k asm ( or even 68k C ) and Atari would have a single toolchain to optimise ( or 3rd parties could provide better compilers )

 

The amazing thing is is Atari was so stupid it did not even occur to them to try to lease/buy the rights to use these tools tht HVS or ID developed. HVS had some crazy linker setup that paged in/out of local memory. HVS made some great games for the Jag and other devs would of at least had the benefit of using it to convert 2d games like Primal Rage more easily than what they had to work with and they would of used the big chips instead of the 68k.

[kool kitty89]

It's not unrealistic at all...just expensive. The T&J using statics, even externally run as fast

as if they were in the local. I already stated it would have been costly.

 

I mean impractical for a commercial product, not difficult to engineer. (that's the very reason the Panther only had 32 kB -that and they were going cheap, and it was fast SRAM, the SNES has 128 kB of SRAM -64 for video 64 for audio plus 128 kB of DRAM -genesis used dual-ported DRAM for video) hey, that reminds me, VRAM, that would have been faster too, a lot more expensive than the DRAM they used, but still a lot cheaper than SRAM. (and still more expensive than going for faster DRAM as well, probably even 50 ns EDO DRAM and clock the system at 40 MHz -let alone more moderately faster FPRAM of 70-60 ns)

 

Hey, why couldn't they have clocked TOM and JERRY at the full 40 MHz and had the main bus run at 1/3 speed rather than 1/2? (and then have faster scratchpads as well) Would that have required added heat sinks? (and cost)

 

Regarding Doom - there were discussions about the renderer coming from some custom compiler setup that ID had. I'm not that fussed - it was one of the better Jaguar games anyway, ( especially compared to the competition ) - my feeling is that it's sales wouldn't have been much more even if it had been slightly smoother.

But that's the renderer, what about the game logic/AI?

 

Would a (good) compiler working with the buggy chips still have to deal with paging code to scratchpads for everything, ot could one be made that takes advantage of a workaround for TOM accessing main?

[Crazyace]

A single speed would do nothing for more color in video as the slowness of a 1X would not

allow that kind of data to flow at any decnt frame rate. the 2x barely got away with it.

 

But adding music or video play back never sold a system. Most of the PS1 games at launch

like Krazy Ivan were rather bland in this respect but it was loaded with a few dozen

titles you could play. This would have been the case with an 020 Jaguar, even without

a CD. Good games do not need FMV or music play back.

 

It's all icing on the cake - but the real advantage of the CD is how cheap it is to make the games - even review copies can just be pressed and sent to games magazines without Atari having to recover expensive flash rom cartridges.

( and in my opinion adding better music and video playback never stopped a system from being sold )

 

A 68020 is an argument for programmers - if the topic was 'what would make the jaguar

more powerful' , I'd agree with your arguments. For me though, a CD would have been

better for Atari's business and profitability.

 

I dont see how. We'd have the same slow system with more data capability. You might sell a

few more units to the FMV/Music lovers but hardly enough to satisfy the hard core gaming

public. The Jag needed more games and the 020 instead of a 68k, even without bug fixes

would have cost little in the way of dev tools and programming effectiveness would

skyrocket. The Jag was popular at first not because of it's medium, but because of

it's promise of games that you could not do on other systems. Even cart based it would

have beaten the 3DO out much worse than it already did.

 

I can't see any difference in productivity between writing C code for GPU/DSP or writing C code for 68020 - It's still C, and at least I'd expect Atari to put more effort into a debugger for GPU/DSP if it was the only processor on the system.

 

I totally agree that the Jaguar needed more games. But I also think that it needed to make more money without inventory risk. Most SNES/Megadrive publishers were suffering from 'unsold' stock when they didn't have hits.. The Jaguar didn't sell enough units to make it a viable platform - so why would a publisher buy large numbers of carts from Atari that might not sell. With CD's they could reduce manufacturing costs and leadtimes, and also pay Atari on what they sold.

[Gorf]

It's all icing on the cake - but the real advantage of the CD is how cheap it is to make the games - even review copies can just be pressed and sent to games magazines without Atari having to recover expensive flash rom cartridges.

( and in my opinion adding better music and video playback never stopped a system from being sold )

 

It never sold systems either.

 

I can't see any difference in productivity between writing C code for GPU/DSP or writing C code for 68020 - It's still C, and at least I'd expect Atari to put more effort into a debugger for GPU/DSP if it was the only processor on the system.

 

I totally agree that the Jaguar needed more games. But I also think that it needed to make more money without inventory risk. Most SNES/Megadrive publishers were suffering from 'unsold' stock when they didn't have hits.. The Jaguar didn't sell enough units to make it a viable platform - so why would a publisher buy large numbers of carts from Atari that might not sell. With CD's they could reduce manufacturing costs and leadtimes, and also pay Atari on what they sold.

 

 

two fold:

1) Atari did not need to waste resources producing a RISC compiler...cost saved there.Time saved since the tool chains for

an 020 are already far more bug free and advanced.

 

2) You now have a 3rd processor that in parallel can run off the bus handling all AI and game logic

leaving the renderer and sound to the DSP and GPU, removing that burden from them. Win win win.

[Crazyace]

Atari had already used resources on a Risc compiler.

[Gorf]

Atari had already used resources on a Risc compiler.

 

And it was absolute garbage. Trust me. You would'nt be writting anything useful with that pile of crap.

It could not even handle simple loop algs.

[Crazyace]

I always considered it unusable because of the local memory limitation myself, but it was a compiler - and if it had been the only compiler for the machine then Atari could have had the bugs fixed.

( It was gcc - so the compiler is good, just the machine model is bugged )

[kool kitty89]

It's all icing on the cake - but the real advantage of the CD is how cheap it is to make the games - even review copies can just be pressed and sent to games magazines without Atari having to recover expensive flash rom cartridges.

( and in my opinion adding better music and video playback never stopped a system from being sold )

 

It never sold systems either.

Well, it did add some things (but as you said, some of the multimedia hype came later, other than FMV games -some of which still hold up- like Silpheed or Nova Storm, or graphic adventures like Myst or Retrun to Zork, and the huge budge WC III/IV of course in '94 and '95)

 

But Crazyace's main point is on the media cost, a huge advantage, except for the high cost of the base unit, Atari wanted an affordable system (and even at $250 or $300 it was well above what the SNES had launched at -even taking inflation into account), especially important in Europe where the prices inflate further. (possibly why the Mega CD saw relatively weak support there)

 

Cheaper meadia means less risk to developers and Atari (any game producers) and more reasonable prices at stores with higher profit margins.

 

However, none of that's any good if you can't establish a good sized userbase because your hardware is too expensive and Atari's marketing capabilities aren't enough to offset that by taking losses or spending lots on promotions.

 

So, if you could get all the major bugs fixed and allow TOM to be the host processor, all the better to omit the CD drive as well and have a system priced at under $250. (granted, the added power of the 68EC020 could still be useful, just not as necessary with a C freindly Tom -especially with a more efficient memory controller for Jerry) Plus you could chose between adding a 68020 or using faster FPM-DRAM (like 70, 65, or 60 ns, still FPRAM, of course, not EDO or SDRAM).

Having a cache for the system would have been a huge help, but I think we've established that that wasn't possible for the Jag-1 given the constraints. (particularly on top of all the other bug fixes -MMU, UART, blitter buffering, Jerry's memory controller, I think the OPL had some bugs too -I can't refer to the wiki article anymore though as it's missing from jagsectorII it seems)

All of this assums Flare could have had time to fine tune the chip-set, that, and taking a different approach from the outset (a J-RISC as a host, and possibly more emphesis on high-level freindly RISC architecture), regardless requireing more time and/or money: even if they opted for a later release, skipping the pre-release and going for the full early 1994 one -or even delaying that slightly, Atari needed funding, hence the test market to interest investors, the only other option by that point would be digging into the Tramiel's private assets for a few months. (with hindsight we can see the Sega windfall, but of course, they wouldn't have known that lawsuit was a sure thing)

 

Anyway, in that context, the 68EC020 is most foolproof. (again the 68EC020FG16 in particular being most feasible)

 

 

Also, there's Atarian's comment from a while back that in the early 90s, Atari should have spun off the Jaruar product to as a separate company, made it public, and relied on funding from stock investments. (with stock speculaition being big, especially if they hinted at plans for internet capabilities) With ample funding, lots of possibilities open up. (meyabe even cache for the RISCs, and have 3 J-RISCs with the 3rd as the host/logic/AI processor)

 

 

 

Oh, and any thoughts about running TOM and JERRY at 2x the bus speed (~40 MHz) rather than double the main bus/host speed? (again, heat dissapation would seem like a possible cost issue, that and I was assuming that the TOM and JERRY chips beng manufactured were indeed rated to 40 MHz as I recall being the design spec)

[Gorf]

I always considered it unusable because of the local memory limitation myself, but it was a compiler - and if it had been the only compiler for the machine then Atari could have had the bugs fixed.

( It was gcc - so the compiler is good, just the machine model is bugged )

 

 

It wopuld not have been needed at all with an 020 as you'd use the j_risc's in assembly from the locals anyway.

[Gorf]

Oh, and any thoughts about running TOM and JERRY at 2x the bus speed (~40 MHz) rather than double the main bus/host speed? (again, heat dissapation would seem like a possible cost issue, that and I was assuming that the TOM and JERRY chips beng manufactured were indeed rated to 40 MHz as I recall being the design spec)

 

Tom and Jerry on the bus all the time vs 020, TOm and JErry of the bus most of the time?

Sorry...in this case, 3 heads are definitely better than two. The Cd ROm offers little.

It would have been looked upon as a glorified over priced Genny CD at $400 dollars with

unimpressive software. The 020 senario is by far superior in every possible way.

[kool kitty89]

Oh, and any thoughts about running TOM and JERRY at 2x the bus speed (~40 MHz) rather than double the main bus/host speed? (again, heat dissapation would seem like a possible cost issue, that and I was assuming that the TOM and JERRY chips beng manufactured were indeed rated to 40 MHz as I recall being the design spec)

 

Tom and Jerry on the bus all the time vs 020, TOm and JErry of the bus most of the time?

Sorry...in this case, 3 heads are definitely better than two. The Cd ROm offers little.

It would have been looked upon as a glorified over priced Genny CD at $400 dollars with

unimpressive software. The 020 senario is by far superior in every possible way.

 

Well ... that response does address some of my other statements, but what does it have anything to do with the 40 MHz TOM+Jerry? I intended that as a separate general comment, regardless of any of the scenarios (68k/020/GPU host etc). Would ~40 MHz with a 1/3 speed external bus -ie using same DRAM chips (rather than 26.6 MHz with 1/2 speed bus) be a possibility. (again, heat might become an issue, and I'm assuming the TOM and Jerry were manufactured to a 40 MHz spec -again, I remember reading that earlier in the discussion)

 

Now, as to the 3 heads being better than 2, 3 J-RISCs could be better still. (though of limited utility without cache, with cache it would be awsome, and elliminat the nees for including a 68020 in the JagII) Without any cache the 020 would be more useful. (and in any case, the added JRISC only becomes feasible with a bug fixed architecture -all requiring more time+funding, plus means a design different from Flare's original concept -which had always included an added CPU -with x86, 68k, and MIPS architectures supported)

Edited December 24, 2009 by kool kitty89

[JagMod]

Yes, a C compiler could generate good GPU/DSP code, but still paging in/out of local memory was needed. ( I think Doom's renderer was compiled as well )

Fixing the main memory bug would allow any C code to run on GPU/DSP - maybe it wouldn't be wonderful optimised assembly, but it would still be faster than 68k asm ( or even 68k C ) and Atari would have a single toolchain to optimise ( or 3rd parties could provide better compilers )

The main memory bug and running C on the riscs has nothing to do with each other.

Running gpu out of main is not always faster than the 68k.

It would have to be "wonderfully optimized assembly" in order to be useful in main.

[kskunk]

Would ~40 MHz with a 1/3 speed external bus -ie using same DRAM chips (rather than 26.6 MHz with 1/2 speed bus) be a possibility. (again, heat might become an issue, and I'm assuming the TOM and Jerry were manufactured to a 40 MHz spec -again, I remember reading that earlier in the discussion)

 

I wonder where that 40MHz rumor came from. Tom CAN handle a 40MHz video clock -- allowing Super VGA style graphics. This was designed-in on purpose and mentioned throughout the manual. At one point they expected Tom to be useful for PC/Workstation apps, so that ability makes sense.

 

But I've read direct quotes from John Mathieson stating that the JagRISC exceeded all speed expectations by reaching 26.6MHz, and they were very pleased to achieve it. Given that high-budget RISCs were clocking at 33MHz in 0.5um process around that time, 40MHz seems completely nuts.

 

SCPCD has experimented with Jaguar overclocking and can only get it briefly stable (and only on certain games) at 37MHz, with active cooling! Active cooling and copper heatsinks in a 1993 console? Not likely. Not to mention what's stable for 10 minutes on one console is not a recipe for mass production and good yields.

 

So my guess is that the 40MHz rumor started from some 3rd party developer who misinterpreted the manual. Has anyone seen any authoritative quotes on the subject?

 

- KS

[Crazyace]

Yes, a C compiler could generate good GPU/DSP code, but still paging in/out of local memory was needed. ( I think Doom's renderer was compiled as well )

Fixing the main memory bug would allow any C code to run on GPU/DSP - maybe it wouldn't be wonderful optimised assembly, but it would still be faster than 68k asm ( or even 68k C ) and Atari would have a single toolchain to optimise ( or 3rd parties could provide better compilers )

The main memory bug and running C on the riscs has nothing to do with each other.

Running gpu out of main is not always faster than the 68k.

It would have to be "wonderfully optimized assembly" in order to be useful in main.

 

They are related if you intend to write an entire game in C - not just a group of small routines.

It's interesting that you find cases where the 68k is faster than the GPU running from main? What are they? Are they situations which would run faster if the memory bugs had been fixed?