Crazyace

16032 - I remember using one of those at uni. ( Whitechapel workstation ) This info is very cool ... looking forward to seeing everything

Actually that is an interesting read that I hadn't seen before.. Thanks.. I didn't realise that his split with Atari was quite like that, and so early either.. But true, he does seem to have had the blitter bug badly, and that's no bad thing, but I just never understood why the sprites made it through to the final design, especially 8 of them, in such an ineffectual form if they were convinced the blitter was the better solution.. Sure one or two for mouse pointer duties or something.. But to have 8 of them, how they were, kind of feels like they were maybe unsure of their importance and were hedging their bets a bit.. I found another quote to be really interesting - Jay says that the original design only had 320 pixel colour ( even in 640 mode ) - and the Commodore guys fixed that. So it sound's like the Video side was an evolution of the Atari 8 bit NTSC centric design - and HAM dropped out of the keep colour, change luminance stuff.

Actually I was thinking about this last night and if you think about it Miners weak point does indeed seem to have eternally been hardware moving objects.. Whilst the display hardware itself is pretty much always all well and good, the movable objects themselves, players, sprite, whatever have usually been the side that let the machine down.. Granted on the 2600 they were the absolute saviour for it, but they evolved very little from that point in, through to the 5200/A8 there's little in the way of 2 years of progress, and by the time the Amiga arrived, there's literally bugger all evolution in them from the A8, whilst the rest of the world had moved on to silly amounts of sprites, a theme that generally stayed for quite some time.. It's still odd that the Atari machines with the monster sprite-abilities (that Miner had nothing to do with) 7800/Lynx/Jaguar failed so catastrophically in their times.. Maybe there was something to that Miner magic after all.. I find that this interview is really interesting, http://www.amigahistory.co.uk/jayminerinterview.html He wanted to do a 68000 machine in 79 while still at Atari, and left when no bonuses were paid. He also seemed really into the blitter idea, and I guess that's why the sprites were given less of a boost. After all - the blitter gave the Amiga better 'sprite' capabilities ( in terms of size ) than most other machines.

This is what's really cool about the Atari Museum - all of the info that Curt's exposing. I notice a RF modulator - I remember an interview with Jay Minter where he said the commodore guys redid the video output, and HAM had been a happy accident - Maybe the Atari version was going to be NTSC colour generated directly on the chips, rather than RGB.

Now I'm going to have to dig out the Saturn again.. You're probally right, PDS was much more of an 'atmosphere' so I never worried too much about the frame rates - ( though I do remember some of the village bits on foot being pretty poor )

The reworking necesary to allow the system to boot without a host and to allow C coding. There was a lot of ncessary silicon needed for that such as a TRUE cache instead of a local. If the only thing they fixed was the simple power line to the MMU that would only be a very small cost and would have gone a long way in helping the systems performance. Then with the 020 staying off the bus and actually being able to perform work would have opened up that bus for much more amazing ability the 68k essentially destroyed. Even the inexperienced coder, then could have used 020 C compilers and had achived much better results much faster allowing much more time to fine tune a local renderer with much better performance. Ah - ok , you think a cache would be necessary to boot without a host. I disagree - only execution from main memory would be needed, which would be trivial. A cache would improve the performance a lot - speeding things up, but I wasn't planning on it. Just fix the powerline, or whatever the bug was , and have the GPU start running at 0 after reset. Nothing more complex than that

Go back and read the reviews of complaints of slow frame rate. Even with the same amount of polies the 020 would have been able to allow the system to run at 30-60 FPS no matter what game it was. You know, the never ending complaint of how it cant be 64 bits becasue everything ran choppy and slow? Those complaints? Oh go back and look at the two biggest mags at the time and how they blanket partied AvP for it's slowness. I dont remember the complaints being frame rate, more comments about the game being slow - and it still had very good reviews. But that was in the UK - I can't remember what the american magazines said - I used to read EGM and GamePro? but I never kept any ( even my Edge magazines went away when I ran low on room ) There weren't any complaints about the frame rate in Doom or Wolfenstein though, were there?

A CD was not necessary for a console of that time and only an idot would release a console costing $150 or more than the original Jaguar price, especially with all the bad stigma they had from previous products. The last clearly well supported product from Atari was sadly the 2600. How do you know a CD was not necessary? It seemed necessary to Sega with the Mega CD, 3D0 , even the CD32. Sony were designing the PSX with CD and Sega the Saturn with CD. Before you continue with your blah blah blah about an impractical Cd unit, that would have done nothing to reduce the cost as the machine would have costed at least $400. The typical price range for a Cd player was $199 or more and even at $99 dollars, Atari's cost, the machine with the necessary hardware needed to handle the CD would not have saved any money. Use the 020, fix the blitter and you could sell the machine at $299 with an Area 51 pack in. Retail price is not related to the cost Atari would pay for a bare mechanism. And why Pack Area51 in, it didn't come out till 1995?

Read my post and you will see the detriments. It does not help the system put up more polies per second. This would have been very important in porting games over like Quake. I dont think more polys per second would have had any impact on the jaguar sales - It had very good versions of both Doom and Wolfenstein, Quake came out in 1996, so it's not really relevant in 1993. I look at the best games on Jaguar and in my opinion they were incredibly impressive at the time. Alien Vs Predator stills compares pretty well with games on Saturn or PSX. Cybermorph was pretty cool for a launch title as well. Your hope is not based on reality. The Jaguar was by far the best bang for the buck....It did not sell because people remember who Atari was and how they blew their market place to bits previously with lack of support and software. Everyone took a wait and see and a Cd would have done nothing to change this. And how would a 68020 solve that? A Cd would help as it would cost publishers less to produce Jaguar games - Atari could go to someone like EA and say "Release Madden PC for Jaguar and we'll let it go royalty free this year" and it would be far less risk than carts. ( EA's probally a bad example given their connection with 3D0 ) What reworking? At the least, the DSP and GPU were always intended to run code from main memory - it's just a bug that stopped it. The minimal change to self boot would be to clear the PC to zero at reset and let the gpu run. The DSP could be left as is - it would be started from the GPU code. You obviously never looked at the horrendous bugs that compiler generates. In fact it was very optimal, even in local with the right flags but the generated code was absolute garbage. It could not even handle something simple like "for(k = 0;k < 10; k++)". You had to do "for(k = 0;k != 10; k++)" In my opinion no one fixed these bugs because no one used the C compiler for serious GPU work. C was for game work , and the gpu's main use was rendering. It was gcc, which even then was a pretty good compiler - and bugs like that seem to be simple back end mistakes. I disagree - if that were true then nothing would help them , 68020 or CD.

Hard to say. Some people get nostalgic about past projects they worked on, but personally I get allergic to them. After all the stress and burn-out and loss they suffered they might not revel in revisiting the past. However, John M of Flare did a pretty good Jaguar post-mortem interview many years ago, where he addressed all the usual talking points: 1) They wanted to a CD unit but it was simply too expensive. So instead they designed the console to support a cheap CD add-on and released it as quickly as they could. Remember that the Jaguar was supposed to be $199 -- the $249 price was a last minute change. Sure, the CD32 had a CD at $399 -- twice the target price! Atari did not think they could sell such an expensive console. 2) They didn't realize 3D texture mapping was going to be important. It was considered an occasional special effect and not a core feature -- they believed smooth shading would be the main effect for 3D graphics. Other consoles (such as the 3DO, and of course the Playstation) made texture mapping their primary emphasis. John said they could have shifted the resources of Tom around to support texture mapping but thought it was a waste of time for what they saw as a gimmick. 3) They didn't realize game programmers would want to use the 68K or the C programming language. They assumed game programs would be written primarily in assembly language (as they had been) and not in higher level languages. They didn't grasp the increasing complexity of game programs, and saw that contemporary (circa 1990) games were short and simple -- without realizing that by 1995 game programs would be far more complex. The 68K was only there to facilitate quick ports, and again John mentioned that he could have shifted resources in the JagRISC to support C if they had only realized it was a requirement. Hindsight is 20/20. I'm sure the Flare guys could do better than any of us if only they knew then what we do now. - KS I still think the CD was the key, even though it was more expensive, that's why I suggest a single speed dirt cheap drive rather than double speed. You're totally correct though, that the flare guys would do best with the benefit of 20/20 hindsight. Where was this post mortem? I remember reading some comment by Leonard Tramiel about cartridges being cheap as well, but they were definitely more expensive than CD's - Sony really had the better business solution in terms of inventory management there. If it's on the net anywhere is there a link?

Sorry , Cinepak - not Quicktime The Sh-2 comment was about the instruction set being new to programmers. My feeling is that it's not important if there's a working C compiler.

The 020 would also have the same advantage as it has a 256 byte TRUE cache unlike the GPU/DSP. A CD would not help this feature in any way shape or form and again would be yet another unit to contend for the bus...and make the unit cost $399. Adding the GPU/DSP enhancements to make this happen are no zero cost either. Pound for pound the 020 is the much more sensible choice, no matter how you slice it. Add a standard IDE interfacewhich cost nothing back then and let the user add his own CD. Solves the split market too. Oh...I just priced a Cd rom single speed from 1993...199 to 249. There goes your dream price of $299. Even if Atari could get these in bulk at $99 it's still $349 for the Jaguar with a single speed CD rom. I think you're really a bit hung up on the 020. Add an IDE interface? That's not a good console choice - the reason I want a CD in 93 is to unify the market. ( The CD32 launched in 93 with a double speed CD rom drive for $399 , and I'm expecting Atari to be more aggressive in pricing than that ) Only an idiot would launch a console with an 'add your own CD' - you'd have no idea how many people actually used CD's - so you'd have to keep the cartridge ports. I want CD and no cartridges - something simple for users and profitable for Atari. Before you start with any 'blah blah 68020 better' arguments again I'm not denying that a 68020 would speed up games written in 68000 code. I just dont think adding a 68020 would have changed the fate of the machine. The only reason I argue about removing the 68k completely is reduce costs so that the CD could be added.

I think a fixed GPU/DSP would help more than a 68020, and they would cost less in the long run. ( Maybe another respin of the chip to fix the bug , but that's a one off cost ) My reasons for adding a CD are not related to system power though, but why would it be a detriment - single speed is only 150k/second , that's not going to saturate the bus at all ( 3k per frame at 60Hz CD would add to the cost - but it would pay for itself by improving the profit on the games. I agree that FMV just for the sake of it is pretty sucky - but in 1993 people were lapping it up. Also if the GPU/DSP were running from main ( and both 32 bit ) wouldn't that be faster than games running on the 68000 - I know you say that even with your workarounds that GPU from main ram is better than 68000. Atari sold very poorly as it was - My hope would be that more people would pick up the unit because of the CD. Also Atari never made any profit from the pack in game - so it was basically an additional cost in the $250 , a demo CD would have cost almost nothing. I expect that eventually the Jaguar price would have had to drop, even with a CD - maybe most of the folks you know would have bought a Jag with CD for $199 Tell Sony that a CD unit for the playstation lessened it status as a true next gen machine. Nintendo were in a completely different situation from Atari. For me the CD unit is a business win in terms of profit, not really a technical win. With main memory working, coders would write C for the Jag. This is a completely different situation to the current jaguar, where the bug stopped nearly everyone except you and AtariOwl from using the GPU in main. Instead all of the 'poor/underfunded/timestrapped' teams would write C. ( And at least this C would be Risc C - allowing further optimisation, rather than just 68k ) It's no more silly than the SH-2's in the Saturn really. The C compiler was mainly garbage because you couldn't write main memory programs with it , and the overheads really added up in local memory. Lousy single speed is the same as all the previous consoles, and I dont think 150kB/s chokes the bus. Trevor may have been a poor example though , not much could have saved it A CD would have made more profits for Atari , and allowed more titles to be published at lower risk. It would be a higher component cost - but I think a single speed, not PC CD-ROM style drive would have cost Atari far less than you expect. Single speed drives seem ok for watching VideoCD at 30fps , I've not looked at what quicktime would look like though - but it's bound to be better than the Sega MegaCd. .. Separate to the CD issue - what do you think of the idea of GPU and DSP being able to run code from main memory perfectly at the start, and the C compiler not being constrained by the local memory size. Wouldn't that work as well as a 13MHz 68020?

As both GPU and DSP have 4 instruction deep queues they could take advantage of the 64 bit bus - ( ie IQ load from GPU acting almost like a loadp instruction , and the dsp load acting as a split 64 bit transfer ( 6 cycles read 64bit memory, bottom 32 to DSP , and 1 or 2 cycles write upper 32 bits to DSP ) without changing all of the other peripheral timings - After all some minimal changes to Tom/Jerry would be made if the decision to not have a host cpu were taken.

An 020 would run 32 bits, but I'm not convinced that it would really change things that much - it's still lowest priority, so it wouldn't affect the blitter/OPL that much. In a couple of years a 68020 jag would be as dead as the normal jag though... After all - the best games on the jaguar were pretty amazing anyway, and the titles that were criticised as being no better than SNES/Amiga were mainly limited graphically rather than by cpu. Fixing the gpu/dsp main code bugs would allow them to run C code - and they would be faster than a 13MHz 020 - ( unless you're suggesting a full speed 020 - which would be a lot more expensive, and even then the RISC's would be faster ) That's why I'd prefer no 68k chip at all - and fix the main code bug - in that situation the DSP would also run 32 bit. The CD unit would make it cheaper to publish games - increasing Atari's software profit. It would also ensure a single market, rather than the split market later. It would raise the profile of the machine - as being a true 'next gen' machine at that time. Also it would improve the audio side of games, as even for simple games the soundtrack could be CD audio. ( Allowing better music to be used whilst mixing SFX using the DSP ) FMV quality would be amazing compared to the crap shown by the Sega MegaCD - not really game related, but something that could boost sales. The CPU improvements would come from never having any 68k code - just GPU or DSP risc code running from C. Atari supplied a C compiler for GPU - with a HW fix it would be used by the developers. Even looking at something like Trevor McFur , the backgrounds could be streamed in as highres JPG images, ( as could the enemy animations ) - giving much more varied visuals, rather than everything coming from the single 2MB cartridge. It would slow the data access though compared to a cartridge - but many games used carts as file backing anyway and decompressed into ram. I disagree on the price - I think no 68k, and single speed CD could be achieved for $299. Packing a 'demo cd' rather than the full Cybermorph game would allow Atari to make profits on Cybermorph as well. I have to disagree there. After all there's no data cache on a 68020 - If you really wanted a 68k off the bus why not go for the 030.

Having Tom+Jerry with no additional host apparently had never been a serious consideration by Flare though. I'm not sure why they hard coded the DSP for the 6-cycle delay... At least the lack of cache on the RISCs makes sense given their constraints. (time and possibly funding) Having the 020 in place of th e68k would definitely be useful regardless, and definitely a good insurence policy in case of any snafus with getting good tools out. Ideally, youd have the RISCs working mosly in local (maybe some main with the GPU), the 020 working in cache, leaving as much bandwidth as possible for the OPL+Blitter. I think an 020 would be a pointless expense - especially as GPU/DSP not working from main is a bug. Atari already supplied a C compiler for gpu, and without a 68k in the system they could have concentrated on having gdb work with gpu/dsp. The DSP would run it's audio interupts ( and CD reads ) via interrupts in it's local memory - and it could handle game code running in main memory ( as it could be 32 bit instead of 16 at the moment ) leaving the gpu to be used pretty much as it was in most jaguar games , for 3D and blitter driving. ( This is all my view though - as I'd want to save money on other components to offset the cost of having the CD drive part of a $299 jaguar at launch )

Yes - the CD32 had a dual speed drive, but used the components from the a1200 ( which launched at $599 - though I guess that included a good profit margin ) The jaguar should have been cheaper eventually, with almost everything in Tom/Jerry , but I'd assume that it would launch with a single speed CD drive ( as the prices might be a lot cheaper ) I noticed that the TurboDuo also launched at $299 in 1992 as well - so that would have been a 'target' price for a CD console. As Gorf said - the GPU( and DSP I guess ) can run code from main memory now ( with the restrictions he has documented ), and it was always designed to run code anywhere - so I expect that the main memory bug could have been fixed if it were more of a priority for Atari at the time. ( ie- If they had decided to support C on DSP/GPU and lose the 68000 ) The key would be having the gpu C compiler, as the reliance on the familiar 68000 would be less important if you were writing C code from day one. Of course for real performance optimised loops would have to be hand tuned assembly , but that's always been the case - even for modern consoles.

I dont think it would have helped the games that much. Fixing the main memory execution and allowing GPU and DSP to both run 32 bit would have been better - as more people would have used C on GPU. ( At that point having a 68000 at all would be unnecessary, as C would be familiar for general game programmers ) ( I know I'd prefer GPU+DSP , rather than a 68020 ) The DSP is not designed that way. If Tom had been a full fledged CPU then you could use the DSP at 32 bits. As the design stands its does not work that way. The 020 would have added an extra processing unit that did not hit the bus and allowed the DSP a true 32 bit to that main bus. the 020 would have hit the bus every 256 bytes worth and that would have made a grave improvement. All three processors would have been able to run in parallel OFF THE BUS while the Blitter and OPL had the bus to themselves. There is no logical way to justify it otherwise. As far as the games: What you think does not align with the facts of the matter. If the 020 was there, the game logic as well as the AI would have been better served by it than trying to split those processes across the GPU and DSP that qould have better concertrated on GFX and SFX. Now if you want to argue folks just porting crap over than yes, but with a much better design you would have seen more folks taking advantage of the 020. A local TRUE cahce, a much better efficiency in external access as well as internally. Thereis just no way to argue that away. Fact is if you are going to remove the host, then you need the TOM at very least to be a true bootable processor and have both chips on sepreate buses. Otherwise is would have been no better in the way of bottlenecks, haveing those two fight over bus time with the OPL and the blitter. Yes - making Tom bootable wouldn't have been that difficult to do though. Jerry already has 32 data lines on the chip connecting it to Tom, so boosting the instruction fetch to get 32 bits at a time would be possible ( even if everything else was still 16 bit ) would also have been pretty simple. It is all conjecture anyway, so we can have different opinions. You want a more expensive processor and a complete redesign of the system to get separate buses. I'm thinking of fixing the bugs in the system, ( main code exec. ) and making the gpu boot at 0 so that more money can be saved by dropping the 68000 completely. Then adding a CD at launch - and having a GPU and DSP C compiler that works for all code. ( The DSP can run game code from main memory, and have sound running on interupt from local memory , and the GPU can handle the graphics as expected )

I dont think it would have helped the games that much. Fixing the main memory execution and allowing GPU and DSP to both run 32 bit would have been better - as more people would have used C on GPU. ( At that point having a 68000 at all would be unnecessary, as C would be familiar for general game programmers ) ( I know I'd prefer GPU+DSP , rather than a 68020 )

Do you really think it would have been $499 - I'm not so sure, after all the CD32 was $399 , and the Sega CD had launched at $299 ( as far as I can remember ). I'm sure that Atari would have priced cheaper than just the sum of the jag+jagCD if it had been a dedicated unit at launch. ( I'd have expected a single speed CD as well in 1993 - as that would be way cheaper than a 2x drive )

I disagree a bit - for a console expandability wasn't actually that important. Putting the CD into the jaguar at the start ( so that there would be no fragmentation of the market ) would have been the best thing in my opinion. ( Having a lot more software would have helped at launch as well ) Maybe later a 'jaguar computer' could have been launched , with a hard drive and floppy as well as the cdrom.

It was annoying seeing messes of pixels on titles like Drol , and missing out on the artifacting - especially as I could never understand why mode 15 was used with artifacting rather than mode 14 with a larger pallette.

Popmilo did a better job of looking at the picture than you did. I posted several similar pictures early in the thread-- they all get a bunch of shades added due to JPG not being able to deal with edges very well. But original BMP is 16 shades. No problem, I only posted as the pictures aren't realistic - you should try harder to post accurate images to support your point.

First he has yet to make up his mind why he's posting spatially dithered images and claiming they are blended into single colors on the real machine. Secondly, just having twice the horizontal resolution does not make images better without regard for color content. Take a look at this example (original 24-bit 320*480, 256-color at half resolution, and 16-color at same resolution and then GTIA picture in gray-scale w/8-pixel sprite overlay) and I have worked with thousands of such images and they all show up better in 256 colors at half resolution than 16-colors: That last picture shows 253 colours - and seems to have detail at 320 pixel resolution, That's pretty amazing for an A8 image? How do you do it?

I really liked Atari Tennis at the time - very simple graphics, but good fun to play