Jump to content
IGNORED

Atari Jaguar VS Sega Saturn


sd32

Recommended Posts

That 32X demo has to be a fake, I know there's no game play or music, but come one. The Saturn was barely able to do that.

But I don't know anything about programming...its just that from what I've seen...come on, that was probably a Saturn demo at best. :)

 

No its real and impressive for what the 32X is. Who ever did the demo has talent though that's for sure.

 

Also, Gorf, you complain about not having enough time on your hands to program the Jaguar...well quit writing these 10 page arguments on the forum and then you should have plenty of time to write more awesome games!!!

LOL, just kidding man! ;) :) Thought that would be a funny joke. :)

 

I'd laugh if I did not know the agony it is to code the Jaguar with the current tools.

 

Scatologic took eight years in there spare time. Gorf 3D and Plus would have been

done already if we did what most everyone else did however, which was just be satisfied

with what was available. We decided to eliminate the 68k altogether in our games where

more power is a must.

 

The 'Surrounded!' demo which is something i've written on other platforms took me a long

time on the jag in comparison.....When I coded 'Surrounded!' on the PC, It took me 3 or 4

hours roughly. There is really nothing heavy hitting going on there...its 6 sided (3D) simon. A proof

of concept more than anything. On the Jaguar I took me a week and a half just to get the demo

running in main. I FIRST ported it over to the 68k as the PC version was in C code but it ran like

a snail.

 

Im trying to find that code again so I can show everyone a 68k vs GPU local vs GPU main

comparison using 'Surrounded!'.

 

I can write a sites worth of post and have plenty of time to code....in fact...Im typing this

as I code the contract work I have.....I can walk and chew gum at the same time. :D

I dont have time for Jag right now because of the contract work. I do sneak a little in here

and there from time to time...very little but anything to keep sharp.

 

As much as I love the contract stuff Im doing....trust me....I have more fun coding my Jaguar

for nothing, getting a US RDA beatdown on the forums and all!!! I want to get back to the

sucker more than you want me to. However, I have to eat at least once a day... ;)

Link to comment
Share on other sites

Hehehe, I know man. Just thought I'd change the subject so we could have a laugh or two instead of everyone trying to pick a fight with you...it's amazing how many people would rather get on a message forum and argue about a 14-year old system!

 

Let's just enjoy the Jaguar and get on with it! :)

 

Good luck to you!

 

Thanks, as the MC says...."You'll need it!"

Link to comment
Share on other sites

Again...instead of shooting off your mouth, being clearly unknowledgable about the Jaguar, you should read.

The docs say CLEARLY that there are issues with the jump instructions in main ram that make running code

with jumps unreliable. they recommende against it and NO one bothered to try to find a work around, obviously.

That is why everyone either overused the 68k or inefficiently flipped code in and out of the local.

 

That sounds like a pretty serious design flaw.

 

It also says jumping between main and local is not reliable either. This is a completely incorrect statement. Go

and download Surrounded! Demo I posted for living proof that this is no longer true. I can not only run in main

but jump back and forth to and from local and main with NO assitance from any other processor.

 

Okay Gorf, once again I never said that this wasn't possible. Why do you keep arguing with me about things I'm not even saying?

 

This demo started out running on the 68k for game AI and got about 15- 20 fps. I moved that over to the GPU

using code flips to the local and got a significant increase in frame rate 20-30 FPS.

 

I then discovered the main ram jump workaround and moved the GPU code of the AI in main ram. It again

increase noticably in frame rate and allowed me to obtain 30-60 fps out of a demo that once ran only 15 at

best then 20- 30 with the code flips. The GPU will never run as fast in main but it will run fast enough. Alot faster

than the 68k and is pretty much my only claim on the subject.

 

The 68k is a very slow processor, that's all there really is to say about that (I wish people pushing Genesis over SNES would start realizing this).

 

When I say I want benchmarks what I'm actually interested is in how code (that does nothing external, no data memory accesses) that is purely in main RAM compares to code that is purely in the SRAM.

 

 

I guess i'm a little late to the discussion.

This is how i addressed the speed issue twice before.

 

Again to restat and confirm Gorf's position:. Atari did not tell people not to run RISC code out of main because it was slow.. as was implied in the thread.. but because they believed it was not possible to run RISC code from main due to the problems with JR and JUMP. They were wrong its perfectly possible to jump within Main and between Main & Local without intervention from any other processor. There can be a fairly large hit on speed though depending on the BUS load and the nature of the code executed.

 

 

 

This is what i said then:

Gorf is obviously and justifiably proud and pleased about the development, i tend to be more cautious and do not see it as quite the panacea he does.

In my own coding i've found the speed of GPU running from main to be highly dependent on load on the main BUS (eg. from the blitter) with speeds typically in the range of 20-90% of the speed of the same code running from GPU local ram. (By which i mean 5 times slower to almost the same speed).

It would therefore be foolish for example to put a tight, commonly called routine in main ram, its far better called in local.

 

 

Now lets take a look at the 20% speed. Thats a pretty large cut in speed.. faster than the 68k? For sure, but a lot slower than local.

Is it worth taking the 68k off the bus and running in GPU from main instead with the 68k STOPped? Without a doubt!

 

[lets look at it from a maths point of view.. i believe the speed of the ST 68k at 8MHz was reported as being very roughly about 1MIP... Therefore at 13.3MHz this should be about 1.65MIPS... in theory the GPU can reach 26.6MIPS, in practice this tends to be more like 17MIPS in other words 10x the speed of the 68k, even if we run at 20% its still twice as fast as the 68k and thats not even taking into account the effects on BUS]

 

Is it worth running from main instead of paging code to/from the GPU local? Ummmmmmm.... Sometimes yes, sometimes no. Its a hard question to answer and depends on a great many factors including the BUS load and the code in question.

Edited by Atari_Owl
Link to comment
Share on other sites

Again...instead of shooting off your mouth, being clearly unknowledgable about the Jaguar, you should read.

The docs say CLEARLY that there are issues with the jump instructions in main ram that make running code

with jumps unreliable. they recommende against it and NO one bothered to try to find a work around, obviously.

That is why everyone either overused the 68k or inefficiently flipped code in and out of the local.

 

That sounds like a pretty serious design flaw.

 

It also says jumping between main and local is not reliable either. This is a completely incorrect statement. Go

and download Surrounded! Demo I posted for living proof that this is no longer true. I can not only run in main

but jump back and forth to and from local and main with NO assitance from any other processor.

 

Okay Gorf, once again I never said that this wasn't possible. Why do you keep arguing with me about things I'm not even saying?

 

This demo started out running on the 68k for game AI and got about 15- 20 fps. I moved that over to the GPU

using code flips to the local and got a significant increase in frame rate 20-30 FPS.

 

I then discovered the main ram jump workaround and moved the GPU code of the AI in main ram. It again

increase noticably in frame rate and allowed me to obtain 30-60 fps out of a demo that once ran only 15 at

best then 20- 30 with the code flips. The GPU will never run as fast in main but it will run fast enough. Alot faster

than the 68k and is pretty much my only claim on the subject.

 

The 68k is a very slow processor, that's all there really is to say about that (I wish people pushing Genesis over SNES would start realizing this).

 

When I say I want benchmarks what I'm actually interested is in how code (that does nothing external, no data memory accesses) that is purely in main RAM compares to code that is purely in the SRAM.

 

 

I guess i'm a little late to the discussion.

This is how i addressed the speed issue twice before.

 

Again to restat and confirm Gorf's position:. Atari did not tell people not to run RISC code out of main because it was slow.. as was implied in the thread.. but because they believed it was not possible to run RISC code from main due to the problems with JR and JUMP. They were wrong its perfectly possible to jump within Main and between Main & Local without intervention from any other processor. There can be a fairly large hit on speed though depending on the BUS load and the nature of the code executed.

 

 

 

This is what i said then:

Gorf is obviously and justifiably proud and pleased about the development, i tend to be more cautious and do not see it as quite the panacea he does.

In my own coding i've found the speed of GPU running from main to be highly dependent on load on the main BUS (eg. from the blitter) with speeds typically in the range of 20-90% of the speed of the same code running from GPU local ram. (By which i mean 5 times slower to almost the same speed).

It would therefore be foolish for example to put a tight, commonly called routine in main ram, its far better called in local.

 

 

Now lets take a look at the 20% speed. Thats a pretty large cut in speed.. faster than the 68k? For sure, but a lot slower than local.

Is it worth taking the 68k off the bus and running in GPU from main instead with the 68k STOPped? Without a doubt!

 

[lets look at it from a maths point of view.. i believe the speed of the ST 68k at 8MHz was reported as being very roughly about 1MIP... Therefore at 13.3MHz this should be about 1.65MIPS... in theory the GPU can reach 26.6MIPS, in practice this tends to be more like 17MIPS in other words 10x the speed of the 68k, even if we run at 20% its still twice as fast as the 68k and thats not even taking into account the effects on BUS]

 

Is it worth running from main instead of paging code to/from the GPU local? Ummmmmmm.... Sometimes yes, sometimes no. Its a hard question to answer and depends on a great many factors including the BUS load and the code in question.

 

 

Good job bud! But Exophase realizes things about the Jaguar now that he admitted not knowing before hand.

Then again, beside you and I , who else knows....shoot me an email or get on the im when you have a chance

if you would...I need to chat with you...catch up on a few things...give you some hopeful news as well.

 

:)

Link to comment
Share on other sites

Good job bud! But Exophase realizes things about the Jaguar now that he admitted not knowing before hand.

Then again, beside you and I , who else knows....shoot me an email or get on the im when you have a chance

if you would...I need to chat with you...catch up on a few things...give you some hopeful news as well.

 

:)

 

Will do.. i've been a little out of the loop recently.

Looking forward to the news :)

 

CHeers :)

  • Like 1
Link to comment
Share on other sites

Good job bud! But Exophase realizes things about the Jaguar now that he admitted not knowing before hand.

Then again, beside you and I , who else knows....shoot me an email or get on the im when you have a chance

if you would...I need to chat with you...catch up on a few things...give you some hopeful news as well.

 

:)

 

Will do.. i've been a little out of the loop recently.

Looking forward to the news :)

 

CHeers :)

 

Cool. See you then. :)

  • Like 1
Link to comment
Share on other sites

  • 14 years later...
On 8/3/2007 at 12:12 AM, Gorf said:

 

Really? Ive seen plenty. Look past the bluriness a little more... :)

 

The N64 texture RAM is extrememly small...the same size as the Jag's locals....5 years later?

Come now Nin!

 

N64 would have killed if Nintendo allowed other micro codes to be used. They hurt themselves

with this idiotic decision. In it's current config it's hardly a leap over everything else if a leap at all.

I'd say in a lot of ways a step back when it could have been MANY steps foward. It would be able

to blow the Jag away in the crispness, and the other two in poly counts by large margins. If only

they allowed other microcode.

 

For those that do not know what microcode is.....

 

Microcode is the actual logic that makes up a processors instruction set and is usually hardwired.

 

Usully in RISC, the instructions ARE the micro code. The MIPS in the N64 had a super

cool feature of allowing you to redesign the instruction set(essentially) specifically to the

games needs. A simple change to the microprogram and you have a new processor.

Or you could improve or repair the bugs.

 

So if you would use a lot of trig functions you could actuall design super fast executing

one instruction versions. Customize the instruction set...just awsome...dont let anyone

else use the feature...ass-o-nine!

 

A total waste on Nin's part.

 

Why are games companies their own worst enemies?

The Jag has 4k for GPU code and Data. Texture access is crippled by a 16 bit gateway and was never planned. The N64 has those 4k for the GPU + 4k for texture + 4k for frame buffer cache (line buffer, but also useable to renders stuff and first swap it out to RDRAM). So it can run for extended times without hogging the bus. The specs say that the texture ram is fast enough to deliver all the data for trilinear texture mapping to the pixel shader so that the latter is still the bottleneck. They don't mention any alignment requirements, but I guess that they don't have only two dataSource registers on the blitter like the Jag, but more like 16 and that they do reuse them like the OP does it on the Jag. So the N64 is basically a debugged Jag.

Edited by ArneCRosenfeldt
more analogies
  • Confused 2
Link to comment
Share on other sites

Hyper-threading: The GPU/DSP already have bank0 for thread 0 .. the interrupt thread and bank1 for the usual program. They cannot be interrupted within an interrupt routine. You are supposed to keep it short. A lot of code is needed to switch from the usual program to the interrupt program. An GP register is reserved as a backup for programPointer. Similarly we could just have a second programm Pointer (internal SRAM only, 10bits) and a second set of flags. The only problem is, is that the code is optimized for a two-port register bank. You are supposed to hard bake two threads in one. So a second thread can only be used as a speed up at certain regions. Maybe there is a way to branch the instruction stream into two .. one runs on thread0 and interrupts are blocked. Both threads have different program flow. Thread0 STOPs fast to again allow interrupts. Thread1 waits for this stop. With a bugfree connection to the DSP .. with the 32 data pins on Jerry, there could almost be 4 thread symmetric multiprocessing.

 

On the blitter rectangle moves in phrase mode should allow (vertical) flip and (horizontal) mirror. In phrase mode for 2d operations the blitter already has tons of registers at its disposal to reduce the number of memory page flips. I guess they did not want to debug anything "internal". They should have integrated blitter functionallity as instructions in the GPU. Then you can write test code and test those instructions individually. There is already a single step function. One can interrupt the GPU and read out everything. With hyperthreading it does not hurt so much. We can debug SIMD instruction and hyperthreading separately. Then we would not even have rectangular moves and a missing flip, not on the blitter nor on the OP.

 

90° rotation + px move would even be possible with 4 phrase registers. The memory layout in the Jag is optimized for frambuffer layout. Thus one can only address every fourth pixel in horizontal direction. But with 90° rotation in between, vertical addressing in the source (pull) becomes horizontal addressing in the target ( push ). If we insist that the blitter has a register file, it would still need two read and two write ports. Then it can swap px between phrases. Flip is a two register swap. And mirror swaps with in the operand.

Edited by ArneCRosenfeldt
rotation
  • Confused 1
Link to comment
Share on other sites

6 hours ago, ArneCRosenfeldt said:

The Jag has 4k for GPU code and Data. Texture access is crippled by a 16 bit gateway and was never planned. The N64 has those 4k for the GPU + 4k for texture + 4k for frame buffer cache (line buffer, but also useable to renders stuff and first swap it out to RDRAM). So it can run for extended times without hogging the bus. The specs say that the texture ram is fast enough to deliver all the data for trilinear texture mapping to the pixel shader so that the latter is still the bottleneck. They don't mention any alignment requirements, but I guess that they don't have only two dataSource registers on the blitter like the Jag, but more like 16 and that they do reuse them like the OP does it on the Jag. So the N64 is basically a debugged Jag.

Also the N64 can do color look up in the blitter. You could store 16 color texture there. And Gouraud and texture mapping can be combined in the pixel shader. So on a high poly model you can store a low resolution of the skin color in the vertices and only do the high frequency correction in the texture. Thus the texture is often monochromatic or as said can be 4 bit.

  • Confused 2
Link to comment
Share on other sites

On 7/30/2007 at 12:20 PM, Gorf said:

When you compare the peak bus rate of all three systems, they are close.

PSX 132 megs a second

Jaguar 106 megs a second

And I cant find anything on the Saturn but Im sure its not very far from the other two.

 

They all have advantages and disadvantages. The right development team behind each system

will result comparble results with the Saturn and PSX getting the advantage in poly count and

the Jaguar getting the advantage in raw computing power.

 

any one who belives that the PSX is that much moer advanced power wise than the other two

are folling them selfs. The PSX wins because the tools to use the machine raw power were

in developers hands. Unlike Jag and Saturn.

LMAO. 
This thread needs to be preserved for posterity. 

  • Haha 1
Link to comment
Share on other sites

On 8/2/2007 at 6:12 PM, Gorf said:

N64 would have killed if Nintendo allowed other micro codes to be used. They hurt themselves

with this idiotic decision. In it's current config it's hardly a leap over everything else if a leap at all.

I'd say in a lot of ways a step back when it could have been MANY steps foward. It would be able

to blow the Jag away in the crispness, and the other two in poly counts by large margins. If only

they allowed other microcode.

 

For those that do not know what microcode is.....

 

Microcode is the actual logic that makes up a processors instruction set and is usually hardwired.

 

Usully in RISC, the instructions ARE the micro code. The MIPS in the N64 had a super

cool feature of allowing you to redesign the instruction set(essentially) specifically to the

games needs. A simple change to the microprogram and you have a new processor.

Or you could improve or repair the bugs.

 

So if you would use a lot of trig functions you could actuall design super fast executing

one instruction versions. Customize the instruction set...just awsome...dont let anyone

else use the feature...ass-o-nine!

 

A total waste on Nin's part.

 

It's amazing what a little time does to "common knowledge" about older consoles. Time has not been good to the N64 as described by Nintendo and SGI - most of everything they claimed was marketing nonsense to try to sell idiot bosses while keeping the engineers in the dark.

 

First, what SGI/Nintendo calls "microcode" is nothing of the sort. Gorf was right in saying that microcode inside a CPU controls the decoding and handling of the instructions themselves, but the chipset SGI designed did NOTHING OF THE SORT. The RCP was the combination of a bog-standard GPU (called the RDP) and a stripped down R4000 processor (called the RSP). The RDP was like virtually all GPUs: it had a standard set of drawing commands, and took those commands from a circular buffer in memory. On the RDP, a command byte would be followed by a number of data bytes, depending on the command itself. Certain ranges of the command byte were reserved... reserved for the RSP.

 

What SGI/Nintendo called "microcode" is actually an R4000 library (written in standard R4000 assembly) loaded into the local instruction ram in the RSP (it had two blocks of local ram - instruction ram, and data ram). The RSP was stripped of all 64 bit instructions, a number of other instructions deemed "not essential", and then had a few matrix instructions added. The main processor would send a stream of commands and data to the RCP, where the RSP library routines would go through the stream byte by byte looking at the commands. Regular RDP commands would be passed through, either unchanged, or with some minimal changes to things like the coordinates and lighting (you could apply matrix operations to the coords for rotating and whatnot). Some of those reserved commands were meant to tell the RSP to do things, like update local matrix values, use its built-in DMA to transfer data, and do most of the sound processing and mixing. Yes, the N64 actually had NO sound hardware beyond a DMA driven stereo DAC. The "microcode" told the RSP how to handle processing sound samples and to do mixing into buffers that would then be DMAed to the DAC.

 

At no point were ANY instructions in ANY processor in the N64 changed. You could change the "microcode" library to reinterpret the commands... maybe changing triangle rendering from perspective correct RDP commands to affine RDP commands for better speed (Turbo microcode). Maybe someone wrote a better method of handling poly clipping in software - that change could be worked into the library. Maybe someone introduced a new method of compressing textures, or sound samples. New library routines would allow the RSP to decompress the new data formats. Nintendo and SGI made it all sound like magic when it was actually all smoke and mirrors. They would have been far better off just documenting the hardware as it really existed and let the developers use it as they saw fit. Most devs would have stuck with the normal libraries regardless of what Nintendo called them or how they worked, and devs like Rare would have made their own that did just what they needed instead of what Nintendo felt everyone should use.

 

  • Like 4
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...