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

[Crazyace]

Rubbish... You've got no proof for that.

 

No rubbish is you forgetting me showing you the price of a 2x CD rom back then was at best

a $99 dollar cost to Atari (and that is being very consevative) since they went for $199.

 

The Mega CD was $300 a year earlier - and in some ways that had more components than the Jaguar

 

And single speed and garbage to boot. I dont care how many more components it had it would

not come close to performing as well as the Cd add-on did.

 

I'd expect Atari to reach $299 for launch - helped mainly by the removal of the pack in game cart and 68000 offsetting the cost of the CD mechanism. ( Also I'd expect there to be no 'butch' chip as the CD control would be part of Jerry )

Improved profits from game sales ( more of the royalty would be profit rather than the cost of manufacturing cartridges ) would also help Atari keep the initial cost down.

 

Yes making the DSP cost that much more to produce so either was you still are looking at $400.

 

 

I'd only expect a single speed CD ( as I said before ) in 1993, and I dont think it would add much to the DSP cost ( They could dump the waveform ram to make room if they had too )

I'm happy to disagree with you though, as something different was needed ... How would a 68020 make Trevor McFur any better, or Rayman, or even Doom?

[Crazyace]

Would that also include code running from main memory?

 

No because eiher way you are dealing with DRAM. So one way would not be any much beter than the other

way running from main.

 

- My point ( before Gorf became totally emotional about it ) was more that the GPU/DSP running general purpose code from main memory in a fixed system ( rather than the bugged one we have ) would be better than a 68020 ( at 13MHz - I don't think a 26MHz 68020 would have been practical for the jaguar price - even the falcon and Amiga1200 only had slower speed cpu's )

 

And like I said a 13 mhz EC020 woudl still be better than a GPU doing both rendering

and game logic and AI. At least with the 020 you will be off the bus most of the time

and would have no need for a seperate bus on the 020 thanks to the 020's cache which

for some strange reason you think is useless.

 

Three processors running in parallel OFF THE BUS is always better than two trying to

handle everything...even in paralelle off the bus.

 

( Losing the CPU gives the 32 bit path to Jerry for free as well )incorrectly I might add.

 

And puts the burden on two risc's where an 020 with two risc's all capable of staying off the bus

most of the time would be far better. Three heads are better than two.

 

 

Again...it's not that the 68k is a bad prcessor but because it MUST take over the bus when

operating, it completely chokes the system. A 68k with a 64k private RAM would have been

a great idea since the blitter would only need to pump in data to it rarely, keeping it off

the bus. It's not about which processor so much but which processor has the ability to stay

off the bus...the 68k dont, and 020 would and a dual risc only system would not be nearly as

efficient as three processors that could stay off the bus while running in parallel most of

the time...not matter how you slice it the 020 would have been the cheapest and best alternative

allowing a large jump in performance in both dev time and poly counts and no need to waste the

two RISC for AI and game logic. At best you could use the DSP for nice fast floats and still

maintain a rockin sound system, allowing the 020 to simply use the DSP here and ther for some

floating point results.

 

We're not really arguing the same point. You want a more powerful CPU to replace the 68k - because you think the 68k is the bottleneck, and the GPU/DSP aren't used enough. I agree with you , but I think that fixing the main memory bugs with GPU/DSP would allow them to run game code from main memory as well ( much better than a 68k ) without an external processor. ( I'd prefer that to having a 68020 and still not fixing the Tom/Jerry bugs )

I'm more concerned with CD vs cartridges, and the fact that there weren't enough games out, and then when the CD came out Atari tried to move titles from cart to CD to save costs. So for me a CD unit at launch is important, and dumping the 68k ( and the bundled Cybermorph game ) is just a move to help save money to offset the cost of the CD mechanism.

[Gorf]

What are you talking about? The blitter would still be there - it would just run 32 bits instead of 64 bits.

A fast page access is 2 cycles - a page break is 5 cycles - so blitting from memory to memory is 2 page breaks ( one read / one write ) - 10 cycles for 64 bits in phrase mode. With 2 pages it would be 2+2 read for 32 bits - 8 cycles per phrase.

For pixel writes ( texture mapping ) it would be better - 4 cycles compared to 10.

 

The OP would be way less efficient with a 32 bit bus though.

 

Yeah it would run half the bit rate per read/write...that's brilliant. Lets waste 32 bits just to

save two cycles every page brake. OY!

[Gorf]

I'd only expect a single speed CD ( as I said before ) in 1993, and I dont think it would add much to the DSP cost ( They could dump the waveform ram to make room if they had too )

I'm happy to disagree with you though, as something different was needed ... How would a 68020 make Trevor McFur any better, or Rayman, or even Doom?

 

How about porting the AI to game to the 020 being a lot faster and then you'd have much better games

at lauch because you did not have to write everything in assembler? My appologies. I forget you keep

missing the obvious.

[Gorf]

We're not really arguing the same point. You want a more powerful CPU to replace the 68k - because you think the 68k is the bottleneck, and the GPU/DSP aren't used enough. I agree with you , but I think that fixing the main memory bugs with GPU/DSP would allow them to run game code from main memory as well ( much better than a 68k ) without an external processor. ( I'd prefer that to having a 68020 and still not fixing the Tom/Jerry bugs )

I'm more concerned with CD vs cartridges, and the fact that there weren't enough games out, and then when the CD came out Atari tried to move titles from cart to CD to save costs. So for me a CD unit at launch is important, and dumping the 68k ( and the bundled Cybermorph game ) is just a move to help save money to offset the cost of the CD mechanism.

 

Ok so we now have CD sized shit for games...that's just great. The 020 would GREATLY...I repeat...GREATLY

improve not only the performance of the system but also the ability to create games A LOT faster. I think

Im getting the point just fine...it is you who seems to have trouble getting your head around the obvious

advantages of an 020 over a CD ROM. I'll try one more time....The GPU /DSP and 020 running in PARALLEL OFF

THE BUS, while the blitter and OPL have the bus most of the time would do MUCH more for a game than a CD

ever could. The add on was fine...it was the sytem that was the problem. N64 did quite well with a cart

based system long after the Jag came along.

[Crazyace]

N64 was a massive flop compared to the SNES though - only the fact that Nintendo have the best games saved them... That didn't apply to Atari though.

You really are pretty deluded if you think that a 68020 would have made a huge visible difference to some of the launch titles though. Trevor would still have been the same - Raiden as well. Only Cybermorph may have had a slight improvement in frame rate , and that was already better than anything on SNES/Megadrive, so it wouldn't have affected sales.

[Crazyace]

What are you talking about? The blitter would still be there - it would just run 32 bits instead of 64 bits.

A fast page access is 2 cycles - a page break is 5 cycles - so blitting from memory to memory is 2 page breaks ( one read / one write ) - 10 cycles for 64 bits in phrase mode. With 2 pages it would be 2+2 read for 32 bits - 8 cycles per phrase.

For pixel writes ( texture mapping ) it would be better - 4 cycles compared to 10.

 

The OP would be way less efficient with a 32 bit bus though.

 

Yeah it would run half the bit rate per read/write...that's brilliant. Lets waste 32 bits just to

save two cycles every page brake. OY!

 

or save 6 cycles per pixel - thats over 2x faster for general texture mapping.

It was only an observation though - I just found it funny that reducing the bus width might actually make some things go faster...

[kool kitty89]

Again...it's not that the 68k is a bad prcessor but because it MUST take over the bus when

operating, it completely chokes the system. A 68k with a 64k private RAM would have been

a great idea since the blitter would only need to pump in data to it rarely, keeping it off

the bus. It's not about which processor so much but which processor has the ability to stay

off the bus...the 68k dont, and 020 would and a dual risc only system would not be nearly as

efficient as three processors that could stay off the bus while running in parallel most of

the time...not matter how you slice it the 020 would have been the cheapest and best alternative

allowing a large jump in performance in both dev time and poly counts and no need to waste the

two RISC for AI and game logic. At best you could use the DSP for nice fast floats and still

maintain a rockin sound system, allowing the 020 to simply use the DSP here and ther for some

floating point results.

 

I think 128 kB might be a better idea as you could then use a single chip rather than 2x 32kB and 32kB chips were almost 2x as expensive in the mid 90s. (so hardly any cheaper for 2x 32 kB 8-bit DRAMs than 1x 128 kB 16-bit DRAM, and the smaller amout of board space used would be a major advantage, not to mention the added memory)

The question is, would adding DRAM onto the board (plus refresh circuitry) for the 68k to work in (possibly allow jerry to use it as well with it stuck at 16-bits) be any more cost effective than a 16.7 MHz rated 68EC020 with no added RAM? (I'd think the 020 would be cheaper, take up practically no additional board space compared to the 68k -rather than an added 128 kB DRAM chip -plus refresh circuitry unless you added that to Jerry or something)

 

The advantages would be RAM for the 68k and DSP to utilize without disrupting the main bus, the disadvantages compared to a EC020 would then be the 68k still less powerful than a similarly clocked 020, DSP still stuck at 16-bits, and additional board space taken up by the DRAM (plus refresh circuitry or invest in adding that to Jerry). Cost wise I'm not sure, a 1 Mb DRAM chip should cost between ~$3-4 at the time ( http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm ) but then there's the added board space and refresh curcuitry to considder.

 

 

Other than that, using the 68EC020 alone is great, but in addition to addressing other bugs and problems, even better. (crazyace seems to have gotten the impression of one or the other)

Anyway, I think you summarized the MMU bugs as one of th ebiggest problems, then other issues like problems with the blitter (with double buffering added being one), then Jerry's memory controller as well. (but even if that wasn't fixed, you'd probably be OK with the 020 and other improvements especially; if you mainly relagated Jerry to sound and I/O and minimuzed bus usage, used the 020 for AI/game logic, and did all 3D math and rendering with TOM -with the GPU not having the bandwidth problems of the DSP, you'd probably be good)

 

Ok so we now have CD sized shit for games...that's just great. The 020 would GREATLY...I repeat...GREATLY

improve not only the performance of the system but also the ability to create games A LOT faster. I think

Im getting the point just fine...it is you who seems to have trouble getting your head around the obvious

advantages of an 020 over a CD ROM. I'll try one more time....The GPU /DSP and 020 running in PARALLEL OFF

THE BUS, while the blitter and OPL have the bus most of the time would do MUCH more for a game than a CD

ever could. The add on was fine...it was the sytem that was the problem. N64 did quite well with a cart

based system long after the Jag came along.

 

The N64's use of cartridges is often considdered a huge fault, even among Nintendo fans. Sure there were advantages of a cheaper base unit and load times, but it meant more limits on music and cutscenes and MUCH more expensive games, along with detracting developer support -tued to the much cheaper an higher capacity of CD-ROMs. (esacerbated by Nintendo's policies and Sony's excellent dev kits) The N64 also had a pretty big issue with software tricling out very slowly, annoying to many early adopters. (the advantages being excellent 1st party software support, many 4-player party games, Nintendo's kid/family-freindly apeal, and a few other things like load times for impatient kids and more durrable cartridges -all less signficant in the Japanese market) What mattered was software, which the N64 had, but not nearly as broadly or frequently as Sony did, the cheaper, more versitle mediaum, combined with excellent tools and earlier release pushed toward this though.

 

OTOH, the N64 came out in mid 1996, for 1993 (or even early/mid '94) carts were still the norm and data compression was still a feasible option as well with the Jag's decent chunk of RAM to hold data (which would also be required for a CD system, if not moreso). Atari had until 1996 before Sony would really take off, prior to which CD ROM was expanding as a media (PCs in particular), but not key to success, particularly if the base unit was too expensive. (and Atari couldn't dump prices liek Sony, or even the likes of Nintendo -Sega was getting pretty screwed up by '95/96 though)

As came up before, the Jag CD could be handeled carefully, with developers encoraged to include provisions for CD ecpansions in the cart based games (even if just music, but added levels and bonus features would be great).

 

The add-on route could work if they were really serious, and even if it wasn't out until '95, there was still a little time to build up before Sony got huge. (and Atari could have been in a much better opsition by then) I mentioned before the opening in Europe, with the Atari name already well established by Atari Corp computers (especially in countries like the UK). With Sega screwing themselves at the time, causing them to basicly loose their longest established successful market (Europe), Atari had a major oppertunity there. (Sega would still be prominent up to 1995, about the time of the saturn's release, but by late '95 there were severe problems and eventually Sony took over and expanded Sega's previous customer base -with some even switchig to Nintendo as well) Atari could still have a price advantage over Sony as well by the time the PSX was released, well maybe not if you include the cost of the CD add-on. (though for Jag owners looking for an upgrade, the CD drive would be much more attractive than a new system alltogether, plus the Jag+CD could at least be somewhat competitive with Sony's prices, the Duo moreso)

 

And Atari could go ahead with the Jag Duo sooner, maybe even in parallel with the CD, then follow with the fully compatible Jaguar II possibly soem time in 1997, maybe '98. (with either 4x or 8x CD-ROM drive)

[Gorf]

N64 was a massive flop compared to the SNES though - only the fact that Nintendo have the best

games saved them... That didn't apply to Atari though.

 

Im willing to bet Atari would have loved N64's massive flop compared to theirs.

 

You really are pretty deluded

 

Read your above statement and then tell me who the deluded one is again?

 

if you think that a 68020 would have made a huge visible difference to some of the launch titles though.

Trevor would still have been the same - Raiden as well. Only Cybermorph may have had a slight improvement in frame rate , and that was already better than anything on SNES/Megadrive, so it wouldn't have affected sales.

 

 

No you are right, I dont think, I know it would have. It would have at very least allowed

even more games out the door MUCH closer to the release date of the Jag.

And I repeat, you are constantly missing the obvious and are rather weak on the

understanding of hardware if you can't get it through your thick skull that 3

processors running IN PARALLEL OFF THE BUSallowing the

OPL and the Blitter at least 85 percent face time on the bus instead of less

than half the time using a 68k in the loop.

 

You keep repeating weak games that would not have even been the release titles had an

020 been the main processor. I've stated perfectly logical and sensible reason as to

why all too many times.

 

You are just wrong and are diverting the subject in a desperate move to sound like you

have even the smallest beginings of a clue. The title games are not even remotely the

issue here. The ability to write better games in much shorter time would have averted

the sad first four releases. Cybermorph would have greatly benefitted from

an 020 in frame rate alone, never mind better shaper AI.

 

As far as release games being better, a Cd would have offered nothing other than a few

more levels at best. It would do NOTHING for the machines performance and the constant

need to read the CD would only further slow things down.

Edited December 21, 2009 by Gorf

[Gorf]

I think 128 kB might be a better idea as you could then use a single chip rather than 2x 32kB and

 

whatever...you get the point and there were 64k single chips, then and static ones that would have been even faster.

64k would have been plenty as the blitter would have been able to pop more code in and out of that private area faster

than you can say 020. The static 64k chips were not at all expensive either.

 

The advantages would be RAM for the 68k and DSP to utilize without disrupting the main bus, the disadvantages compared to a EC020 would then be the 68k still less powerful than a similarly clocked 020, DSP still stuck at 16-bits, and additional board space taken up by the DRAM (plus refresh circuitry or invest in adding that to Jerry). Cost wise I'm not sure, a 1 Mb DRAM chip should cost between ~$3-4 at the time ( http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm ) but then there's the added board space and refresh curcuitry to considder.

 

The disruption would have been very minimal and unnoticable.

 

Anyway, I think you summarized the MMU bugs as one of thebiggest problems, then other issues like problems with the blitter (with double buffering added being one), then Jerry's memory controller as well. (but even if that wasn't fixed, you'd probably be OK with the 020 and other improvements especially; if you mainly relagated Jerry to sound and I/O and minimuzed bus usage, used the 020 for AI/game logic, and did all 3D math and rendering with TOM -with the GPU not having the bandwidth problems of the DSP, you'd probably be good)

 

With the hardware as is, the private ram at even 2k would have shown a grave improvement in bus performance.

 

The N64's use of cartridges is often considdered a huge fault, even among Nintendo fans. Sure there were advantages of a cheaper

And Atari could go ahead with the Jag Duo sooner, maybe even in parallel with the CD, then follow with the fully compatible Jaguar II possibly soem time in 1997, maybe '98. (with either 4x or 8x CD-ROM drive)

 

The N64 was fine with a cart...it was the lame hardware with it's tiny texture cache that was even more of a major

offense.

 

The Jag Dou would not have had to come out faster with an 020 and an add on CD and the games would have been fine on cart.

The system would have been much more efficient regardless of the title games released which is as far from the point that

Crazy Ace can't seem to get.

Edited December 21, 2009 by Gorf

[Gorf]

What are you talking about? The blitter would still be there - it would just run 32 bits instead of 64 bits.

A fast page access is 2 cycles - a page break is 5 cycles - so blitting from memory to memory is 2 page breaks ( one read / one write ) - 10 cycles for 64 bits in phrase mode. With 2 pages it would be 2+2 read for 32 bits - 8 cycles per phrase.

For pixel writes ( texture mapping ) it would be better - 4 cycles compared to 10.

 

The OP would be way less efficient with a 32 bit bus though.

 

Yeah it would run half the bit rate per read/write...that's brilliant. Lets waste 32 bits just to

save two cycles every page brake. OY!

 

or save 6 cycles per pixel - thats over 2x faster for general texture mapping.

It was only an observation though - I just found it funny that reducing the bus width might actually make some things go faster...

 

 

No because the page breaks do not happen every read but every page boundary. The only thing that slows down

the DRAM is the refresh on pages and they do not occur every read and write. Grabing 64 bits a a time with

a few cycles lost for page beaks every so often is still much more efficient than a 32 bit wide bus.

[kool kitty89]

whatever...you get the point and there were 64k single chips, then and static ones that would have been even faster.

64k would have been plenty as the blitter would have been able to pop more code in and out of that private area faster

than you can say 020. The static 64k chips were not at all expensive either.

THe question is: would it have been cheaper than switching to an 020 -after you include added costs due to the increased board realestate? (say, the cheapest -16.7 MHz EC020) There's the refresh circuitry to considder as well, but then again that should be relatively trivial, and possible to add to Jerry. (to save on board space)

 

The advantages would be RAM for the 68k and DSP to utilize without disrupting the main bus, the disadvantages compared to a EC020 would then be the 68k still less powerful than a similarly clocked 020, DSP still stuck at 16-bits, and additional board space taken up by the DRAM (plus refresh circuitry or invest in adding that to Jerry). Cost wise I'm not sure, a 1 Mb DRAM chip should cost between ~$3-4 at the time ( http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm ) but then there's the added board space and refresh curcuitry to considder.

The disruption would have been very minimal and unnoticable.

You mean in terms of Jerry hitting main?

I seem to recall kskunk mentioning that it would take a lot outof the main bus to have Jerry handel all the geometry calculations for a polygon heavy game; then again, you should have that on the GPU instead (with its far more efficient accessing) and dedicate Jerry to audio (and I/O).

Howver, using that added block of RAM for sample data might be useful.

 

The N64 was fine with a cart...it was the lame hardware with it's tiny texture cache that was even more of a major

offense.

 

The Jag Dou would not have had to come out faster with an 020 and an add on CD and the games would have been fine on cart.

The system would have been much more efficient regardless of the title games released which is as far from the point that

Crazy Ace can't seem to get.

It made the games cost a lot more expensive (like 50% more compared to contemporary PSX games -or Dreamcast games as well) and that combined with the data storage limitations did deture developers who wanted to add multimedia features (streaming video and CD audio). Most significantly (for japan at least) was losing Square to Sony, losing the Final Fantacy series was a major hindrince to Nintendo and a major boon to Sony, noit only in Japan, but in the west, with FFVII being the first game to really popularize the JRPG genre, especially in Europe, where RPGs of any kind tended to be shunned if released at all. (in the US, not as major, but it was still a significant move of the genre into mainstream) In that case, it had less to do with hardware limitations (hell PS1's texture cache is 1/2 the size of the N62's and less RAM, etc) Square mainly switched because of the multimedia experience they wanted for the game: CD audio tracks, high quality streaming video cutscenes to advance the plot, etc. (I personally think the game is highly overrated, but that has nothing to do with its importance in the market)

 

And yes, Nintendo's decisions to limit the hardware in other ways sucked as well, plus the lack of support provided for the RSP's programmable microcode. (which should have been a key feature -providing developers with different optimized microcode to use with different game types -one requiring more filtering and more accurate textures and AA vs more polygons/s, not to mention more 2D oriented, and on top of that supplying good tools to allow developers to write their own microcode) With the limited support Nintendo did supply, some companies like Lucas Arts (with Factor 5) basicly had to reverse engineer a lot for the hardware to actually write custom microcode for the RSP. (and took several games to really get it optimized -compare the draw distance in Rogue Squadron to Battle for Naboo)

[Crazyace]

N64 was a massive flop compared to the SNES though - only the fact that Nintendo have the best

games saved them... That didn't apply to Atari though.

 

Im willing to bet Atari would have loved N64's massive flop compared to theirs.

 

 

Now that is definitely something I'd agree with.

 

 

You really are pretty deluded

 

Read your above statement and then tell me who the deluded one is again?

 

I think your fanatical arguement about a 68020 magically saving the Jaguar is deluded. Atari needed great software to sell the machine, and they didn't have the money to buy enough, and they didn't sell enough units for publishers to consider it a viable platform.

 

if you think that a 68020 would have made a huge visible difference to some of the launch titles though.

Trevor would still have been the same - Raiden as well. Only Cybermorph may have had a slight improvement in frame rate , and that was already better than anything on SNES/Megadrive, so it wouldn't have affected sales.

No you are right, I dont think, I know it would have. It would have at very least allowed

even more games out the door MUCH closer to the release date of the Jag.

And I disagree with you, I dont think it would have made any real difference, The only thing that may have changed is the framerate slightly on some of the slower games - not the time it took to complete them.

 

And I repeat, you are constantly missing the obvious and are rather weak on the

understanding of hardware if you can't get it through your thick skull that 3

processors running IN PARALLEL OFF THE BUSallowing the

OPL and the Blitter at least 85 percent face time on the bus instead of less

than half the time using a 68k in the loop.

 

You keep repeating weak games that would not have even been the release titles had an

020 been the main processor. I've stated perfectly logical and sensible reason as to

why all too many times.

 

You are just wrong and are diverting the subject in a desperate move to sound like you

have even the smallest beginings of a clue. The title games are not even remotely the

issue here. The ability to write better games in much shorter time would have averted

the sad first four releases. Cybermorph would have greatly benefitted from

an 020 in frame rate alone, never mind better shaper AI.

 

As far as release games being better, a Cd would have offered nothing other than a few

more levels at best. It would do NOTHING for the machines performance and the constant

need to read the CD would only further slow things down.

 

You haven't stated any logical reasons, just gone on about the 3 processors working together. And also you fail to see why I don't care about a 68020 .. It's just money , for me a fixed Tom/Jerry would allow the GPU or DSP to be used as a main processor more efficiently than a 68k, without costing Atari money.

My argument is all about costs - for the whole software platform, not just the initial console. CD's were the future - they were much cheaper and more practical than cartridges. It was all about risk for the licensees - If I had 100k cartridges from Nintendo or Sega it was probably around a million dollars in inventory, and if they didn't sell that was a huge loss. 100k CD's would only have a physical cost of around $100k, so the risk was far less.

The other argument for having a CD in the first place is that with the Add on the CD market was miniscule. Atari couldn't have made much profit on the tiny amount they sold.

 

So have a 68020 if you want - it just would have been a more expensive console with the same games that would fail to sell 100k the first christmas..

[Crazyace]

What are you talking about? The blitter would still be there - it would just run 32 bits instead of 64 bits.

A fast page access is 2 cycles - a page break is 5 cycles - so blitting from memory to memory is 2 page breaks ( one read / one write ) - 10 cycles for 64 bits in phrase mode. With 2 pages it would be 2+2 read for 32 bits - 8 cycles per phrase.

For pixel writes ( texture mapping ) it would be better - 4 cycles compared to 10.

 

The OP would be way less efficient with a 32 bit bus though.

 

Yeah it would run half the bit rate per read/write...that's brilliant. Lets waste 32 bits just to

save two cycles every page brake. OY!

 

or save 6 cycles per pixel - thats over 2x faster for general texture mapping.

It was only an observation though - I just found it funny that reducing the bus width might actually make some things go faster...

 

 

No because the page breaks do not happen every read but every page boundary. The only thing that slows down

the DRAM is the refresh on pages and they do not occur every read and write. Grabing 64 bits a a time with

a few cycles lost for page beaks every so often is still much more efficient than a 32 bit wide bus.

 

I see you fail to understand even a simple technical point. If I'm blitting from A->B ( copying a sprite, or drawing a line ) then the source and destination are very unlikely to be in the same page. So in that ( very common ) situation the blitter will incur a page miss with every access. If you look at any fast render code on the jaguar it's often split into 2 passes ( DRAM->GPU mem, then GPU mem->DRAM ) to avoid this.

The OP is the only component that would lose out, as it can saturate the bus completely when fetching 16 bit pixels.

 

In a perfect would Atari would put 4M of ram in, and then there would be 2 banks of 64 bit memory - a win for everyone

[Gorf]

You mean in terms of Jerry hitting main?

 

I seem to recall kskunk mentioning that it would take a lot outof the main bus to have Jerry handel all the geometry calculations for a polygon heavy game; then again, you should have that on the GPU instead (with its far more efficient accessing) and dedicate Jerry to audio (and I/O).

Howver, using that added block of RAM for sample data might be useful.

 

First of all Jerry would be able to grab twice the bits at once. The GPU would handle all the geometry and rendering

since it would not need to be tied down to AI and game logic.

 

It made the games cost a lot more expensive (like 50% more compared to contemporary PSX games -or Dreamcast games as well) and that combined with the data storage limitations did deture developers who wanted to add multimedia features (streaming video and CD audio). Most significantly (for japan at least) was losing Square to Sony, losing the Final Fantacy series was a major hindrince to Nintendo and a major boon to Sony, noit only in Japan, but in the west, with FFVII being the first game to really popularize the JRPG genre, especially in Europe, where RPGs of any kind tended to be shunned if released at all. (in the US, not as major, but it was still a significant move of the genre into mainstream) In that case, it had less to do with hardware limitations (hell PS1's texture cache is 1/2 the size of the N62's and less RAM, etc) Square mainly switched because of the multimedia experience they wanted for the game: CD audio tracks, high quality streaming video cutscenes to advance the plot, etc. (I personally think the game is highly overrated, but that has nothing to do with its importance in the market)

 

In the Day of Jag, the multimedia features meant little to consumers. When working part time at radio shack I learned

that most people were not interested in that for a gaming console. Most people were interested in the game play and content.

Quantity does not necessarily = quality. Though some people liked multimedia, they wer happy with that on their computers

but the true gamer was fine with the gameplay and good titles. The PS1 was able to grab textures from its main ram well

enough where the texture cache did not really matter so much. This was not the case with the N64.

 

And yes, Nintendo's decisions to limit the hardware in other ways sucked as well, plus the lack of support provided for the RSP's programmable microcode. (which should have been a key feature -providing developers with different optimized microcode to use with different game types -one requiring more filtering and more accurate textures and AA vs more polygons/s, not to mention more 2D oriented, and on top of that supplying good tools to allow developers to write their own microcode) With the limited support Nintendo did supply, some companies like Lucas Arts (with Factor 5) basicly had to reverse engineer a lot for the hardware to actually write custom microcode for the RSP. (and took several games to really get it optimized -compare the draw distance in Rogue Squadron to Battle for Naboo)

 

The draw distances in RS still sucked in comparison and though RS was a much better game than most, most developers

did not have the re-written micro code and Nintendo did not allow for it either.

[Gorf]

I think your fanatical arguement about a 68020 magically saving the Jaguar is deluded. Atari needed great software to sell the machine, and they didn't have the money to buy enough, and they didn't sell enough units for publishers to consider it a viable platform.

 

And your idea that a CD ROM included making the Jaguar cost $400 at launch would have? What you are saying is selling

the same exact system with a larger medium at a higher price would make the developers do any better? Come now.

 

And I disagree with you, I dont think it would have made any real difference, The only thing that may have changed is the framerate slightly on some of the slower games - not the time it took to complete them.

 

Because you don't know what you are talking about. That is why you dont agree. If you

actually knew the first thing about what I said over and over, it should make perfect

sense. Have 3 processors doing the work off the bus most of thetime in parallel is

definitely going to be better than a 68k choking the bus most of the time while the

real workhorses in the system have to beg for bus time. The dev time is reduced greatly

since most of the game(logic and AI) can now be written in C for the 020 and not in hard

work and time consuming assembler.

 

You haven't stated any logical reasons, just gone on about the 3 processors working together.

 

No you have ignored them time and time again. I would not have to go on and on about

3 processors if you had even the simplest clue of what you are talking about. You fail

to see the logic, not that the logic is not sound. a CD would only add larger games that

ran at horible frame rates. Look at all the CD game that were relased even with a 2x

drive....none of these did anything to blow away anyone. History says you are wrong as

well as your lack of hardware performance on the CD games that did get released with the

add-on.

 

And also you fail to see why I don't care about a 68020 .. It's just money , for me a fixed Tom/Jerry would allow the GPU or DSP to be used as a main processor more efficiently than a 68k, without costing Atari money.

 

I dont fail to see your point at all, I'm simply stating you are wrong. For the billionth

time, no host would add a larger burden on the two RISC's as compared to an 020 running off

the bus doing all the game logic and AI while theOPL/Blitter, GPU/DSP(now running at twice

the bits to the bus and less half the cycles) could have the bus to itself MOST OF THE TIME

as opposed to less than half the time beggin the 68k for bus face time. A completely logic

understanding that you can't get your head around.

 

 

My argument is all about costs - for the whole software platform, not just the initial console.

CD's were the future - they were much cheaper and more practical than cartridges.

 

And the games would not have been one bit more spectacular as the games would have

suffered from dev time, frame rate and an absolutely horrible tool kit on a console

that now cost $50-100 dollars more, so you fail in cost and in performance improvement.

 

Your wrong. An 020 automatically corrects the speed issue, which in turn corrects the

dev time issue as the C compiler for the 020 would be able to handle the game logic

and AI and take the burden of writing all this on two risc's with only an assembler

to work with. How this is not logical to you is beyond me.

 

It was all about risk for the licensees - If I had 100k cartridges from Nintendo or

Sega it was probably around a million dollars in inventory, and if they didn't sell

that was a huge loss. 100k CD's would only have a physical cost of around $100k, so

the risk was far less. The other argument for having a CD in the first place is that

with the Add on the CD market was miniscule. Atari couldn't have made much profit on

the tiny amount they sold.

 

Because it did nothing to enhance the system outside of larger data content. If you had an 020

even without the CD it would have done much more for the system...read on and I will once again

try to hammer home very logical reasons as to why you are wrong. Larger game s that suck dont

sell systems either.

 

 

So have a 68020 if you want - it just would have been a more expensive console with the same

games that would fail to sell 100k the first christmas..

 

Your cluless...mine would have been $300 tops and $50-$100 less than yours and once again...

 

Mine would be....

 

TWICE the clock TWICE the bit width able to run OFF THE BUS IN PARALLEL MOST OF THE TIME.

(CD cant help here)

 

A DSP that now take half the access cycles to the main bus and at TWICE THE BIT WIDTH

(Cd cant help this either)

 

An OPL and Blitter that had MOST OF THE FACE TIME to the main bus.

(Cd can't help here either.)

 

No need to try to flip modules in and out of the RISC locals doing AI and rendering on two riscs.

(CD cant help this either)

 

And MUCH LESS DEV TIME because all the game logic and AI can now be reasonably done on

the much more bus efficient, bit efficient 020. also allowing the OPL and the Blitter

MOST of the bus time.

(CD cant help here either)

 

The best argument you have is more room for data....this at best offers content and

you are still plagued with everything else the Jaguar was initially as even the CD

add-on did not help one bit. Name one CD game that showed the advantages of a CD by

adding more power and faster dev time to the system...it does not exsist. HoverStrike

CD and BattleMorph took forever to be released because the Cd rom did NOTHING to speed

up development time. Why? Because to get that small amount of extra performance, they

had to move some of the code over to the GPU in assembly, where as with and 020 that

could have all been done much more efficiently in C with much less time and much less

cost choking the system with local ram loads. They still needed to rely heavily on a

bus choking 68k to get the games out the door.

 

Your CD at launch would have done NOTHING to help anything other than extra content.

In other words more content that sucked.

 

It adds $50-100 dollars to the cost of the system and does not help any of the other

areas an 020 CLEARY would at $50-100 dollars less.

 

Sorry...you lose.

Edited December 21, 2009 by Gorf

[Gorf]

I see you fail to understand even a simple technical point.

 

You seem to fail to understand a whole lot more than one simple point.

 

If I'm blitting from A->B ( copying a sprite, or drawing a line ) then the source and destination are very unlikely

to be in the same page. So in that ( very common ) situation the blitter will incur a page miss with every access.

If you look at any fast render code on the jaguar it's often split into 2 passes ( DRAM->GPU mem, then GPU mem->DRAM )

to avoid this.

 

And we have found out that it does not help and in fact via our tests you are wasting tons of time moving data

to and from the locals...wasting cycles to save them. The overall performance of grabbing 64 bits at a time

is still going to be better...this based on the tests we've actually run.

 

The OP is the only component that would lose out, as it can saturate the bus completely when fetching 16 bit pixels.

In a perfect would Atari would put 4M of ram in, and then there would be 2 banks of 64 bit memory - a win for everyone

 

They could have done this with 2 megs of ram just as easily. I'll stick with the 64 bit width as you are still grabbing

8 bytes at a time even with a cycle hits as opposed to 32 bit's just to save two cycles...think about it.

Edited December 21, 2009 by Gorf

[Crazyace]

I think that you are obviously not reading anything I'm actually saying, just getting upset and resorting to insults.

 

My argument is that with cost cutting ( including dumping the 68k ) a Jaguar with single speed CD could launch at $299 , and Atari could recover money via the reduced production costs of CD's over cartridges.

For ease of use, having only the GPU/DSP riscs running C code, ( and optimised assembly where it's needed ) will make it easier for devs to develop.

CD storage will allow a lot of eye candy, and help make the jaguar appear different to the SNES for most titles, not just the 3D ones.

Also ( hopefully ) the 32 bit path to Jerry, and lack of bugs will make the system more powerful than the current jaguar - and this will help the 3D titles.

 

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.

[Crazyace]

The OP is the only component that would lose out, as it can saturate the bus completely when fetching 16 bit pixels.

In a perfect would Atari would put 4M of ram in, and then there would be 2 banks of 64 bit memory - a win for everyone

 

They could have done this with 2 megs of ram just as easily. I'll stick with the 64 bit width as you are still grabbing

8 bytes at a time even with a cycle hits as opposed to 32 bit's just to save two cycles...think about it.

 

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 )

[JagChris]

CrazyAce, you can prove all your theories by writing a nice community renderer for the Jag.

[marvio]

I guess that is what I was reffering to, to squeeze down the 64 bit data through the 68k was essentially to have a 16 bit machine, sure the chips could process at 64, but to send it down the datapath to the 68k so much stuff has to be truncated that it's almost a waste...

 

The machine would only be choked by using the 68k in a game's loop. The entire bus structure is 64 bits

wide. The 68k did not squeeze the bus down, it choked it.

 

At any rate, still think some true 3D hardware accel would've been the tipping edge there, didn't have to be the the voodoo chipset, which was the more expensive one, by 93 PowerVR had a one chip solution so did Rendition, which both were finished in 91 actually, even with those "subpar" 3D hardware, combined with the existing JAG hardware, it would've trully been revolutionary and would set the bar so high that Sony would have to play catch up!!

 

An 020 instead of a 68k would have given Sony problems. sure the Sony would still be a bit

more robust in terms of poly count but the game logic and AI as well as many other features

on the Jag would be superior. REAL 3D hardware back then would make the Jaguar cost $500 or

more dollars. Still better than the 3DO but hardly a power without the price offering.

 

Of course, all the other issues already discussed would have had to be dealt with as well

 

Someone other than the Tramiels at the helm might have seen the REAL beauty of the T&J chipset

and designed a much more efficient system around them....even with a 68k...one with a seperate

bus with it's own 64k of RAM to keep it off the main bus most of the time while the REAL work

horses(J-RISCS, BLitter and OPL) could have the bus most of the time.)

 

Shit...Let the 68k stay with a seprate bus where only the blitter need to write to it and the

Jag would have been a much better system. The 68k then could run in parallel doing AI and game

logic, writing to a specific area that the blitter could grab for the J-RISC to operate off of.

 

As it stands, everything comes to a screaching halt while that blasted host CPU is running.

Sorry indeed.

I'll defer to you sir!!

 

Like I said, I'm pretty new to the Jag, so I guess I was taking the "brute force" approach to the problem

 

If that's true tough, you shoud be able to get a lot nicer graphics than pretty much anytihng I've seen "out there", I thought the problem was the truncation that happened between the GPU and the main bus...

[kool kitty89]

I think your fanatical arguement about a 68020 magically saving the Jaguar is deluded. Atari needed great software to sell the machine, and they didn't have the money to buy enough, and they didn't sell enough units for publishers to consider it a viable platform.

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)

 

I see you fail to understand even a simple technical point. If I'm blitting from A->B ( copying a sprite, or drawing a line ) then the source and destination are very unlikely to be in the same page. So in that ( very common ) situation the blitter will incur a page miss with every access. If you look at any fast render code on the jaguar it's often split into 2 passes ( DRAM->GPU mem, then GPU mem->DRAM ) to avoid this.

The OP is the only component that would lose out, as it can saturate the bus completely when fetching 16 bit pixels.

 

In a perfect would Atari would put 4M of ram in, and then there would be 2 banks of 64 bit memory - a win for everyone

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

 

It made the games cost a lot more expensive (like 50% more compared to contemporary PSX games -or Dreamcast games as well) and that combined with the data storage limitations did deture developers who wanted to add multimedia features (streaming video and CD audio). Most significantly (for japan at least) was losing Square to Sony, losing the Final Fantacy series was a major hindrince to Nintendo and a major boon to Sony, noit only in Japan, but in the west, with FFVII being the first game to really popularize the JRPG genre, especially in Europe, where RPGs of any kind tended to be shunned if released at all. (in the US, not as major, but it was still a significant move of the genre into mainstream) In that case, it had less to do with hardware limitations (hell PS1's texture cache is 1/2 the size of the N62's and less RAM, etc) Square mainly switched because of the multimedia experience they wanted for the game: CD audio tracks, high quality streaming video cutscenes to advance the plot, etc. (I personally think the game is highly overrated, but that has nothing to do with its importance in the market)

 

In the Day of Jag, the multimedia features meant little to consumers. When working part time at radio shack I learned

that most people were not interested in that for a gaming console. Most people were interested in the game play and content.

Quantity does not necessarily = quality. Though some people liked multimedia, they wer happy with that on their computers

but the true gamer was fine with the gameplay and good titles. The PS1 was able to grab textures from its main ram well

enough where the texture cache did not really matter so much. This was not the case with the N64.

Yeah, FMV was the bigges multimedia aspect, though significant at the time even in high profile (non-interactive movie type games) like Wing Commander III/IV and Myst. (I'm partial to Return to Zork more than myst though, and there's always the Jag CD/Duo later on -of which Myst was a prominent feature)

 

My other point was though, that CDs are far less risky for developers than cartridges (being much cheaper and much easier to scale manufacturing), and thus much more attractive. The downside is the cost of the base unit, even with 1x CD, custom integrated CDROM controller (which would be an investment), it's probably going to be closer to $350 as Atari couldn't afford to dump the price. (look at the CD32, it's 2x speed, but with a custom controller so only buying the CD mechanism, 2 MB of ram and cost $400 -then again it had a much less consolidated board than the Jag)

 

I think the add-on could work out well though, particularly with an emphesis on foreward compatibility of cartridges (CD expansions for cart games) and timely release of the integrated DUO console. (preferably have the Jag CD out by late 1994 and hte Jag Duo out by mid 1995, in time to meet and preferably beat the PSX release date with a competitive price)

 

And yes, Nintendo's decisions to limit the hardware in other ways sucked as well, plus the lack of support provided for the RSP's programmable microcode. (which should have been a key feature -providing developers with different optimized microcode to use with different game types -one requiring more filtering and more accurate textures and AA vs more polygons/s, not to mention more 2D oriented, and on top of that supplying good tools to allow developers to write their own microcode) With the limited support Nintendo did supply, some companies like Lucas Arts (with Factor 5) basicly had to reverse engineer a lot for the hardware to actually write custom microcode for the RSP. (and took several games to really get it optimized -compare the draw distance in Rogue Squadron to Battle for Naboo)

 

The draw distances in RS still sucked in comparison and though RS was a much better game than most, most developers

did not have the re-written micro code and Nintendo did not allow for it either.

 

Yeah, and for some reason the PC didn't much improve it (resolution supported was far higher even compared to the 640x480i with the 4 MB "expansion pak" and that meant a drop in framerate as well a trade off in certain cases). However, that was an early example, Battle for Naboo sported a significantly longer draw distance. (and better performance in high res mode) Indiana Jones and the Infernal Machine is supposedly the most advanced example of Factor 5+LA's work and manages the high res mode w/out RAM expansion, and put an emphesis on improvements over the PC version, pulling tricks liek streaming textures on the fly from ROM to get around limitations.

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.

[Gorf]

I think that you are obviously not reading anything I'm actually saying, just getting upset and resorting to insults.

 

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.

 

My argument is that with cost cutting ( including dumping the 68k ) a Jaguar with single speed CD could launch at $299 , and Atari could recover money via the reduced production costs of CD's over cartridges.

For ease of use, having only the GPU/DSP riscs running C code, ( and optimised assembly where it's needed ) will make it easier for devs to develop.

CD storage will allow a lot of eye candy, and help make the jaguar appear different to the SNES for most titles, not just the 3D ones.

Also ( hopefully ) the 32 bit path to Jerry, and lack of bugs will make the system more powerful than the current jaguar - and this will help the 3D titles.

 

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.

 

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.

[Gorf]

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.

[Gorf]

If that's true tough, you shoud be able to get a lot nicer graphics than pretty much anytihng I've seen "out there", I thought the problem was the truncation that happened between the GPU and the main bus...

 

Nope, there is no such truncation....the truncation happens when the 68k is running. However its

not truncation at all. More like one of the Wonder Twins trying to boss around Superman, Wonder

Women, Batman and Green Lantern.