Crazyace

No. That only added to its data mass ability. The blitter is what powers Area 51. Seen the sources BTW. The the 030 makes a huge leap in difference. ITs at the same clock at the other two processors instead of half and it sees the bus at a full 32 bits....then the same game was ported over to the MIPS and it ran even smoother. You can see the difference if you can see the two machine versions side by side. I think the extra ram and storage is way more important - even now memory is king on consoles.. The CPU boost is great - but it changes the ability to run AI.. For an arcade game throwing a faster cpu makes sense - for a console it was just too expensive. If they'd aligned gpu jumps properly in gcc and allowed the game to be written in C code maybe the 68k wouldn't have been as much of an issue - or we could have had Atari ST style games - with a panel at top or bottom where there was no OBJ activity to speak of and 68k running at high priority, and 68k idle during the rest of the display. As you said, you've seen an AVP demo running at 30-60fps already The hardware was hard to code for and why the games sucked. I still really disagree with this - the hardware was no more difficult than any previous consoles. Only the 3D0 offered a high level library at the time , if you coded for SNES or Megadrive or 32X or even SegaCD the jaguar was quite reasonable. .. As an aside: If Atari had delayed the jaguar a year it's quite likely that no one would have developed for it - Sony and Sega were already showing developers the PSX and Saturn ready for then, and more devs would have tried the 3d0 - ( with the C model and 3D texturing hardware ) which would move perfectly to the japanese platforms. 1993 was better, as the competition was the 32X and the 3d0 - ( and the comparisions between jaguar 3d and 3d0 3d could be explained away by the difference in price )

Area51 probally benefited more from the Hard Drive and extra memory than anything else. I think that everyone is focusing too much on the hardware bugs - The real problem was the games, and the release of add-ons that made the jag look silly.. Releasing at the same time - across the whole country, with the 1st years worth of games available on day 1. If any H/W change - just ship with CD instead of cartridge CD would make it easier for Atari to make product with less risk.. something that really worked well for PSX ( especially for publishers who didn't need to commit to buying large numbers of cartridges )

The other thread got locked that you asked about this in. Here's another youtube of surrounded. Not quite so dark as the other but still darker than on my tv. Maybe my tvs color setting is off or something. Or maybe its the size of the video window making it look dark to me. hmmm Thanks for the link

I guess I should have qualified the statement with 'at the time' - I assumed that the topic was about '1993' not 2007. I didn't think of the DC ( or even PSX ) in my original statement, as they didn't exist at that time Regarding the DC shareware - a lot of the emulators run on DC because DC is faster, so it's easier to take a PC emulator and recompile it. The jag isn't as fast so a lot of homebrew needs more work ( optimisation or complete rewrites ) I'm not disregarding what other people are saying just understanding what they are saying. What I've done before is immaterial really.. I personally enjoy low level programming ( I like 2600 programming ) and I understand pretty much all of the consoles at a very low level ( both from experience programming them, and general interest )

There are so many reasons Jag failed - the hardware was almost the least of the problems. What was needed was the 'best' of the Amiga/ST conversions - and also the new games , and the console conversions. I've got way better things to do with my time than anything to do with gcc - ( and if I have to touch gcc it's not going to be for the jaguar ) for hobby programming I'll use assembler

So if you can code an efficient bug free machine descriptor for the GPU utilizing main you'd be the first. Machine descriptors is a science in itself especially if you hope ro deal with all the Jaguar bugs too. I aggree thought that this needed to be completed but easier said than done. Strange thing to say - I think a working gcc would be enough, it doesn't have to be the most efficient version - and there's nothing really that special about machine descriptors.. There are/were lots of cpu's out there way more complex and buggy than the gpu I think the CD could have helped but the tools....the tools.... Tools 15 years ago were pretty crude for all systems - ( The 3d0 was an exception in some ways , and the PSX was praised for it's libraries ) Libraries and samples could have been a bit more prolific of course Well at very least we would have no stalls and we'd get closer to the 27 mips and not the 18 with careful interleaving. We would not have to re align addresses by hand in main for the GPU and we could write small C snippets efficiently because the entire two megs would be able to hold and allow the GPU to execute it. The uart would work right and the blitter would have a command buffer. dual port the registers at very least. The blitter and OPL should have had its own VRAM. Extra cost or not. Extra cost is everything for a console.. If you really want a better machine at cost Atari should have gone with the Jaguar 2 chipset One thing with the 68k that is easy to ignore now is just how much programmers were used to it at the time, and how it would help Megadrive/ST/Amiga ports

Thanks, I still have the original docs somewhere - but it's actually more convenient to hit the internet than search in the loft. DosBox works fine for me.. ( I'm using Steem to run my old ST/Amiga devpac environment.. )

Any other console at the time encompassed the SNES / Mega CD / 32X and PC software rasterisers.. and then Saturn of course DC was a lot later - and it was easier in some ways as the hardware was more capable Also there were a lot more DC's than Jaguar's sold.... Why are you comparing DC with Jaguar - it's a bit like complaining that there are no mp3 players for the Apple ][ For the DC I haven't seen a great deal of homebrew, just more people moving cross compiling linux apps

No they would not have...they Jag is hard to code. the tools offered as remo has pointed out, is a mean joke at best. They do not in anyway support this systems abilities where they should have. The GCC for the RISC should have been bug free. It should have been moer important thatn the GCC of the 68k and the 68k should haev been used for what it is .......a boot manager. Your strategy is not much at all different than Atari's which proved to fail. A few bug fixes in the hardware is the first place.....there were many other areas they blew it with the Jag. Actually the jaguar was no harder to program for than any other console really. gcc being bug free was a software problem and it should have been fixed. The biggest difference I suggest would be to make the jaguar a CD machine from day 1. That way discs could be mastered more cheaply than cartridges - Even with the HW in the same state a lot of good 2d games could have been produced ( rivalling NeoGeo CD at least ) Fixing the very few HW bugs would have opened up the GPU use ( and maybe saved money by not requiring external DACs for the audio )

Anyone get jag development running under cygwin or windows xp? I haven't got anything that runs win95 anymore - and I'm reluctant to run an AtariST simulator to host the jaguar development tools Was there source for the jaguar gcc? what about madmac?

Bit 2 of memcon2 selected BE/LE mode you're right about CPU prices though ( but I think the hitachi 68k was way less than $21 dollars in 93 ) - a SLC would be way better than a 68020 - it had FP and a cache ( only 1k though ) Maybe IBM would have done a deal on their cheap 486s I wouldn't want to delay the H/W launch at all... Get onto the market for the Xmas 93 with more games on CD-rom Then by Xmas 94 - drop the console price... Aim to hit $150 dollars by the time PSX and Saturn arrive - with games.. ( rather than just dumping the H/W ) ( At this point , with CD as standard EA may have moved titles from 3do to jaguar )

I think I'd be more realistic.. Keep all the hardware the same... 68k/2MB memory etc integrate CD instead of cartridge. Chase Capcom for StreetFighter, and Midway for Mortal Kombat Aim for $200 dollar price - no game packed in.. sell games for $30 each 3D0 was too expensive - so chasing 2D arcade companies would be good If possible - 4MB ram ( unlikely though ) Project manage games more... Going for gpu only would be difficult to source ports from NeoGeo and Megadrive/MegaCD as well as Amiga1200 games 68020 would be too expensive at time - but I'd be tempted to put a cheap intel style cpu in ( The Cyrix 486SLC was around about that time... ) Fixed HW bugs

One team did NBA, and then Porsche Challenge, another team started on RapidRacer.. Not a new studio - but definitely a new team / new engine.. ( Hey I was wow'ed by Toshinden and Ridge Racer at the launch of PSX - especially the transparent torus stage )

No developer ever 'maxes' out the system. There are always shortcuts taken, and things to balance.. If you claim Omega Boost was an experienced team compare it to this: http://www.youtube.com/watch?v=Ywwxp5-oJio This was a 'first time' game for a new team - and it ran at 60fps in hires/interlace mode ( I wont say anything about the quality of the game - but the engine was very good ) For me - I really like games like Super Burnout on the Jag - they seemed to play to the strengths.. I would have loved to have Outrun and PowerDrift converted

HoverStrike CD UL's texture quality is amazing. The trouble is all the game logic and AI is still being done on the 68k so it gets about 15 - 20FPS. There is light sourcing from weapons adn the head lamp on the craft as well as other very nice perspective correction and what even looks like mip mapping. This is using Atari's sample renderer...but no you wont get poly count like you will on PSX but it can texture. It would have been much better if the blitter could texture in phrase mode. So its four times slower than G shading. BattleSphere is not so much a graphical achievment(thought it really is) as much as it is a AI achievement. I doubt that PSX title it pulling off the same amount of thinking going on in the Jaguar. Scott Legrand said he could not pull such trickery off on a system like the Sony which graphically in 3D is superior but lacks in the computing power of a DSP and GPU core along with a cleverly interfaced 68k helping out. I say cleverly because they managed to get that performance with the 68k ON the bus. Again, to get the ultimate performance from the Jag is a tricky balancing act. But very significant performance increses can be a result. I think the TOM & Jerry in multi bus system like the PSX would be superior in many ways. It would need SRAM and get rid of that DRAM. That would eliminate waits, refresh and page issues right there. The blitter and OPL would love SRAM. At the time I would have rather seen... Tom with 2 Megs on one bus. Jerry with 1 meg on another bus. A small unified cache between them so they can exchange data. NO 68k! A nice GPU core at the same speed as as Tom and Jerry with a small 256k memory space for game logic and AI also hooked to the unified cache. Give us time...I think we can imperss... I dont know if Scot tried hard - The PSX was normally single threaded, although a few people implemented multi threading in game code. .... Sounds like jag2 - with the extra gpu, and the enhanced blitter, Norman came over and spoke about it -but things fell apart quite soon after that for Atari

A good comparision would be to compare Battlesphere with OmegaBoost on PSX ( ) Battlesphere is really nice, but a lot simpler

Again Gorf - I've never seen anything really to compete in terms of texture quality from the jaguar - For larger poly spans I could see someone using a quake like trick.. ( Although I'd be more tempted to texture out along a line of constant Z , and damm the pagebreaks ), but I can increase the quality of PSX texturing using subdivision, or even by reducing close polys to line spans. ( Vertical lines are a bit slow on PSX, due to the way the VRAM was setup, but the fast screen clears really helped ) At one point for the olympic demo I was tempted to render the mode 7 stadium floor directly into the line buffer, and render each runner into a seperate object, but the stadia were too big for that to be practical, so it went back to a straight double buffer display

I liked the jag at the time ( a long time ago ) - for gourard shading with Z it was pretty cool - but it sucked on texturing, and took so much more effort than any of the 3d0, Saturn , or PSX I'm quoting fill rate - not polygon set up, to show how drawing poly's doesnt take away system bandwidth. For transforming polys the 1/Z divide should be the limiting factor (18 cycles without bugs! ) which would limit you - ( especially as triangle setup isn't cheap ) I think for poly counts the PSX rarely hit 100k/second in real games not as much fun as the Atari8 bit, where turning off the display sped up the CPU

The GTE is the 3D transform - it's pretty cool ( from memory effectively 7 or 8 cycles for a 3D transform and perspective projection of a single point ) I think the strongest part of the jaguar is the Z compare on the blitter - there's no equiv. on the PSX GPU Anything else could be generated by textured line GPU commands If these people are surprised, then they probally haven't looked at the PSX much The biggest problem here is that I'm assuming that the 68k is turned off most of the time - and even then I dont think the jaguar will match the PSX. The PSX GPU can draw textures at 33MPixels/second - and polys at 66MPixels max - and this will only saturate the vram bandwidth. The main memory is completely free for the MIPS cpu. On the jaguar drawing can completely saturate both the memory bandwidth, and the gpu cycles. Even if you run a draw system completely on a gpu interupt, so other code can run asynchronously on GPU ( from main memory ) - you are probally going to lose a great deal of time as general gpu code will have to fight for memory bandwidth. That's true - 2D really is the jaguar's strength, although it can have trouble matching some of the SNES features ( ie: trying to emulate a hardware charmap using the object processor was a real pain - especially when the SNES has 4 planes for free effectively ) Thinking about it - for performance I'd probally organise something like: GPU: local memory interupt, triangle rasterise + coord fetch... main memory, run game logic / objects visibilty and other DSP - interupt copy stereo buffer + read 3d polylist and transform/light and copy to GPU local memory During vblank/end of drawing run both GPU and DSP in tight loop generating next frames audio buffer For speedup, dsp could generate transformed triangle list and sort, to avoid per pixel Z overhead ( I'm going to have to dig out my old jaguar stuff - it's been over 12 years! but the temptation to buy a jag and swap the rom is high )

I think that - although it was a very nice system, there really is no way that the jaguar would compete with the PSX.. As polygons get smaller, the overhead of blitter setup increases to the point where the gpu can be completely bogged down with drawing triangles - and although the DSP could handle transformations it would be way less powerfull than the GTE on the PSX.. and finally with the blitter running quite heavily, the main bus would end up pretty fully used, and the 68k would be starved .. I'm not completely convinced by the claims of better quality texturing either - what is this based on? Is it the versions of doom? ( This thread has made me quite keen to dig out my old gpu code - and get a jag to run stuff on again )

I think in some ways the 3d0 was better as well... If you stuck a HD on the PSX ( rather than the CD ) it would be quite easy to increase the quality of the fmv's

There are always HW bugs and features - where can I get your demo from? ( Feeling tempted to buy a jaguar - to join all of the other old systems that I never have time to program for anymore )

It's funny about the sound drivers on Jaguar - I wrote one for the jag that only accessed memory during vblank ( so it had up to 24 voices ) and I had to justify it to my boss at the time because Norman K. ( cant remember his name ) at atari told him that it was impossible. ( I think it was used on Val D'isere skiing because I remember how difficult it was to get snow samples.... also used on Brutal Sports football and probally F1 I guess - it was a long time ago )

This is a pretty awesome thread, but I dont think there's really anything that the Jaguar could do that couldn't be duplicated or exceeded on the PSX. The coolest things with the blitter often involved explosion effects ( writing out with gaps.. ) which would be most difficult to reproduce on the PSX - but they could be done Even getting a mode 7 effect running was a pain - I had an olympics demo where the stadium floor was a 512x256 CRY image - easy to spin around at 60Hz , but such a pain after the more memory efficient mechanism on the SNES! Given similar low level programming it's quite easy to generate 'more' perspective correct texturing on the PSX - but it was really not worth it in many cases, as the graphics were 'good enough' and the programming efforts had moved on towards the 3d geometry/world processing rather than the triangle drawing.