Crazyace

Changing the subject ( or maybe dragging back to the subject ) - I thought I'd knock this up as the comparision of boulderdash was being made by Atariksi. If you run the boulder.prg on a ST it should scroll a character screen at 50/60Hz. The character paint routine for the whole screen takes around 100k cycles ( from 133k cycles 60Hz ) - leaving 33k cycles for game code , which compares well with 29k cycles total on A8 ( before any DMA ) It's just a brute force cpu algorithm, so no sync scrolling tricks, just something to show that the stock ST could easily match an A8 game in terms of scrolling boulder.zip

Atari had already used resources on a Risc compiler.

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 ) 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.

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.

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 )

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. 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.

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. 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.

As far as Atari Owl's renderer, I think he's worked too hard and too long for anyone to expect him to give it away. I especially find it rather tasteless for those of you offering it to the public. I'm not offering it to the public - so please don't imply that I am.

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 )

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.

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

Im willing to bet Atari would have loved N64's massive flop compared to theirs. Now that is definitely something I'd agree with. 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. 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. 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..

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...

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.

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. 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. 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.

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. 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. 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?

Then you obviously do not understand the blitter very well either. Even with a DRAM page breaks its a much more efficient means of moving data even externally. Hardly. The blitter's is a much more able chip than you obviously know. 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.

You can't compare it to GPRIOR=0 since that's perfectly safe and useable even in BASIC like the color clock shift in Gr.10. Frequency changing is known to destroy monitors as I know it did on CGA-based PCs. I don't agree making it 10Mhz is better than having a blitter. Amiga had all sorts of accelerators but the blitter still helped out as it's DMA-based... more in my next reply. The frequency changing syncscroll hacks on the ST dont actually change the frequency of hsync/vsync - they just trick the shifter into displaying more data in the borders, so it's not dangerous. 10MHz was just a comment - it would have increased the pixel rate allowing a 512x200 screen with 16 colours without slowing the cpu down at all. A blitter would have been preferrable , but it's more silicon to design - 10MHz 68000's were available in 84/85 and would have been just as easy to design for.

That was just a design consideration though - the ST was a much cheaper machine than the PC-AT, and offered much more 'out of the box'. I dont think there was anything that competed graphically on the PC at the time of launch though - eventually the PC would win over all, but the home market wasn't a given in 1985. ( I think the biggest problem with the ST was that it didn't compete well enough with the Amiga in terms of H/W at launch - it worked well enough with serious apps, but games were the mass market killer apps, and when the Amiga price dropped it took away the market from the ST )

I still think a great idea would be someone who has experience with making renderers(maybe someone like CrazyAce) and others willing to learn(perhaps SubQMod) putting their heads together and working on a renderer for the community where everyone willing could perhaps have some input in. I think only in cooperation can you achieve the best possible speeds, such as Gorfs and yours eventual cooperation towards refining the main ram techniques. Just a thought. Atari Owl has a really good renderer already ,his demo is excellent. At the moment I've got a wireframe geometry wars style game that needs my attention , which doesn't actually require anything in terms of texturing - and I've managed to completely ignore it over the last month or two due to work related programming.

I was just thinking that the only part of the system that really efficiently uses the 64 bit bus is the OP. Sure the blitter is ok for clears and copies to/from internal memories. But for general memory copies the page breaks end up limiting the process. It might have been quicker to actually only use 32 bit memory, but have 2 banks - so that blit's wouldn't page break all the time. That would also free up pins on tom to allow a seperate data bus for 68k/jerry and the dram. Interestingly OP heavy games could have the 68k( or GPU/DSP ) running on a seperate bank to the OP.

No, we needed those in 1992/1993

the carts yes...the system however would have cost you $400. Rubbish... You've got no proof for that. The Mega CD was $300 a year earlier - and in some ways that had more components than the Jaguar 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.

Wikipedia? I could just assuredly ignore the rest of this post based on that alone...not to mention everything else you have posted in the past....it's all making sense now. ...but seriously folks.... Well I could have quoted an architecture reference manual, or even some benchmark figures - but I thought I'd give you a reference you could read. ( Maybe I should have taken the PR numbers from motorola for the chips ) You extrapolated horribly wrong then and I can do much better than 0.7 MIPS/MHZ by hand. If you are using a ton of movei's you should probably stick to 68k. There are other ways to obtain immediate data with the GPU. Please read my post - movei wasn't mentioned, ( maybe you should also read up on 2 operand vs 3 operand architectures as well ) I'm glad you can do better that 0.7MIPS/MHZ by hand - it's not really relevant to the original point though. ( And would that be >0.7MIPS across your entire codebase, or just a small optimised loop ) This entire statement is ridiculous simply based on the fact that there is no C compiler for the GPU/DSP ( one that is worth bothering with that is) since assembly is the only route to go with the two RISC's. Hand tuned assembly should be the only way you bother coding the Jaguar RISC's until someone actually writes a real optimized compiler. There was a C compiler for the GPU's - and if the bug was fixed allowing main code execution then it would be a lot more practical. With C the entire codebase for a game would run on GPU/DSP ( I'd guess DSP - with sound running as an interrupt ) and development would be a lot quicker. Then the real bottleneck routines could be rewritten in ASM to get the final speed up. If the GPU ISA was the only target Atari could spend resources on improving the C compiler ( or if Jaguar were more successful then other tools companies could )

Would that also include code running from main memory? - 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 ) ( Losing the CPU gives the 32 bit path to Jerry for free as well )