Atari Jaguar VS Sega Saturn

[A Sprite]

PS1 doesn't have a "2D sprite engine", it does however have a sprite (textured 2D quad) primitive, and it's in no way limited to being 8x8.

 

I'll vouch for this. It's not a secret.

[kevincal]

Welcome to Atari Age. It looks like Gorf has some real competition now...

 

 

Please....in your dreams PS1 fan boy. See previous post wher FACTS are once again laid out.

 

 

Edit...

 

sorry KK.....forgot the ..... ...after the PS1 fan boy...you knowIm busting you short and curly's...

 

You had me worried there for a sec.

[spiffyone]

Exophase, I should point out that the technical specs on PSone provided on Wiki actually came from Sony's own site, which rather mysteriously doesn't have the PSone specs apparently.

 

But this is where, after years of throwing around "500,000 polys per second texture mapped and lit" Sony finally admitted it was less than half that in game. Far less. It was actually 180,000 per second texture mapped and lit or so to be exact.

 

So the "4000 8x8 sprites individually rotated and scaled" actually comes from Sony, as do the rest of the specs that appear on Wikipedia. Which, again, have mysteriously disappeared from Sony's own site (do a search on playstation.com for PSone or Playstation specs...trust me, Sony took them down). But I remember them, because when they were unveiled (the revised Sony specs, which only happened very recently), tons of classic game boards erupted into "Sony lies again" flame wars.

 

For some morbid reason I eagerly await their revised PS2 specs, which, if history is any indication, will be released in a year or two. Watch them hype building early tech spec numbers drop.

 

Any money down on how far they go?

[spiffyone]

I should add that they all pretty much lie, although Nintendo and Sega lied less that gen, what with their lowball estimates of in game power.

 

But MS really took the cake with the exaggerations on XBox. I fully expected Doc Brown to come out during Gates' revealing the console and start screaming "1.21 GIGAWATTS! My God!"

 

[spiffyone]

The only thing I've read about Jaguar is in actual technical docs written by people with a genuine interest in documenting the thing. I've ignored the BS gleaned from places like Wikipedia (like the RISC CPUs having 64 registers, that's a good one)

 

You mean tech docs by people with interest in documenting the thing like this:

 

Jaguar Underground Dox

 

Which go on to state:

 

Registers

=-=-=-=-=

 

64 registers, each 32 bits wide, stored in two banks of r0..r31

interrupts always execute out of bank 0 (i.e. your code should

always execute in bank 1..)

 

JUD on the registers of TOM

 

Don't know which of you is winning the pissing contest, but I'd thought I'd chime in with that.

 

Carry on.

[Gorf]

I dont have to wish .....I know.

 

read on the system sugests otherwise

Nice try, I searched this out beforehand just to see where the misinformation was coming from and the only thing that came up was the exact Wikipedia quote. There is no 8x8 limit on size on sprites for PS1, that's rubbish.

 

you should use another search engine...here is where I got mine from

 

http://www.vidgames.com/ps/hardware/techspec.html

 

Not Wiki...under the graphics sub title.....so much for that...

There are plenty of sites if you just use google.

 

 

The problem with everything you've said here is that I never even compared its 2D power to the Jaguar - what I did say is that you were wrong to claim that PS1 can only do 8x8 sprites. This suggests that you actually know next to nothing about PS1's graphical hardware.

 

I know what I've read that is actually available. Link please.....I'll conceed if you show me a credible link...that's all...

I have no problem learning but you 've posted nothing but words....I've at least posted links and available information

as well as my own experiences.

 

I never said it was the same, but let's see. A linked list of commands to draw graphics primitives that the

GPU processes. Maybe the reason no one has ever tried comparing the two is because very few people

care about the Jaguar?

 

Now that's a reasonable assement. Very few? Spoken like a true fanboy...oh I already admit to being one BTW

so save your breath. I see you know knothing about the Jaguar.. the GPU does not process the OPL commands.

The OPL is started by ANY processsor in the jaguar and thes traverces the list and fills the lines buffers ON ITS OWN.

How is that similar?

 

 

See, here's yet another problem - you clearly said a SINGLE Saturn SH2 can vastly outperform the PS1's R3000a (this is even considering that the R3000a is clocked higher), not that it can "keep up." Quite a different statement, do you want me to go dig out the original quote? It was probably in the vs. 3DO thread.

 

Different indeed....too bad you got it wrong again....

 

Here allow me to help you. Im not afraid to stand by my words. I base them on nformation availble to me.

 

http://www.atariage.com/forums/index.php?s...l=sh2&st=48

 

 

Clearly? VASTLY? 'More robust' and efficient is HARDLY clearly and vastly. Compare the cycle per cycle.

The sh2 can split cycles for executing instructions. Reading is fundemental. You should try it sometime.

OR actually do the homework before you look stupid....dont worry though I did your homewrok for you

like I usually do for those who THINK they know what they mean.

 

 

The smaller cache footprint is the only benefit that these instructions will give you (and of course something like Jaguar desperately needs it with its gimped cacheless architecture). If you can fit it in cache then the R3000a will have better code that will get things done, on average, faster.

 

Horse toot. In some cases not on average.That might be true in an ideal

situation which usually never exsist in a computer program.

 

If yu can fit it in the cache ...Im dying here... My point exactly.

The SH2's efficiency is incredible even with the 16 bit wide instructions.

It will hold its own even against a higher clocked r3000. BLow it away , no.

keep up and exceed in some situations.

 

How is the texture mapping having poor bandwidth not a problem of the bus when the blitter has to read off of

(guess what) the bus to actually blit anything? It doesn't have dedicated RAM, and it only reads one word at a

time. So unless your pixels are 64bit wide (and they aren't) you're wasting a lot of bandwidth. What he said

was perfectly valid, no matter how many other stabs you throw at him.

 

No they are not 64 bit widths becasue the BLITTER is the problem, and not the bus.

 

I threw no stabs at Carmack. I simply stated he does not know the JAguar as well as we now know the Jagaur,

unless he still plays around with his dev kit .However that is not possible as he has said he has nothing Jagaur

related anymore. The guy essentially ported whatever he could get away with to bring doom to the Jag and did

a frighteningly amazing job. But By his OWN ADMITANCE, said he could have done a lot better had he coded he

jag from scratch....read what I actually post and not what is convenient for your arguments please.

 

We know the blitter has full speed access to the ram in the GPU..yes, its way too little but its there.

The fact is the blitter not being able to read more than a pixel, not that the bus could not handle it.

This is no longer true anyway. Like every console new discoveries and workarounds come along

and prove otherwise. We have discoverd such workarounds. Docs from ten years ago are not

as true as they used to be.

 

G-shading on the Jaguar is a full 64 bit operation in PHRASE mode. The phrase mode in the jaguar

for texturing does not exsist...only the one blitter channel has a phrase source with fractional

increment and is the REAL reason why....not becasue the bus cant handle it. Carmack's complaint

about the bus was the overall system access...becasue he gave probably too much time was given

to the 68k. If Carmack knew what I know now Im sure he would have used it. He's a brilliant

developer.

 

 

Nice wording there, "as fast as it does in local, outside of the dram pitfalls." Why don't you come back with

some benchmarks and I'll listen to what you have to say about that. Or I suppose you think that Atari told

everyone to not run code RISC out of main RAM just for the hell of it?

 

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.

 

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.

 

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.

 

Again I can back up my claims with code and with documentation.

 

 

 

The MMU helps this to take place. It always sees the bus

as a physical 64 bit wide bus and internally redirects the smaller parts out to the smaller widths.

Yes, which without a buffer is completely wasteful. I think I already went over this?

 

Yeh we have but you still dont get it.

 

Completely wasteful? Inefficent compared to a cache yes but completely wasteful?

 

 

As far as I see it you're the ones being ridiculously stubborn about the issue, going so far as to put in your sig that it's "illogical" for anyone to suggest otherwise. So you start off this paragraph saying that it's impossible to actually make a claim as to what the bit rating is, then you go on to:

 

Ive seen nothing that I consider evidenvce otherwise.

 

My sig is also a comeback to someone elses sig... again do your homework or stop leaving out details to bolster

your blather. Oh and I still dont see any IEEE or other standard that agrees with your bitness definition.

 

And again. How are the Pentium 1 machines (which is contemporary to Jaguar) not 64bit? Because no one was calling them that. Obviously it's an accepted convention, not just what you're referring to.

Personally, I don't care at all. I just find it hilarious to watch people get in a huge fit over it, especially if you tell them their precious Dreamcast isn't 128bit. It's marketing. Get over it.

 

No, it is what actually takes place in the Jaguar when coded properly. YOU get over it.

I really dont care either other than to be factual. The Jaguar as a system manipulates data 64 bits at a time,

andI dont see why that cant not be classified as a 64 bit SYSTEM. Why do I need a 64 it ALU? Why?

 

Then don't even bother mentioning it. Lots of platforms have lots of ICs that process data. Does Jaguar really have to artificially have more to look better?

 

 

Artificially? The OPL runs on it own once started so does the blitter. Why are they any less a processor? The OPL

very much so has an instruction set. Read the docs. Ok so they dont look like conventional instructions but they still

fetch process and move on the the next like any other processor does. The blitter is different in that it needs to be

reloaded for every operation. Are they a CPU or a GPU? no but it is a bit block processor...PROCESSOR...and an

Object Processor...PROCESSOR..not like a sprite engine though it can 'emulate' one perfectly.

 

The vic-20 video chip does not read and write based on a list of todo;s given to it. It is a hardwired function

of the chip. This is not the case with either the blitter or the OPL...Read...read....read....

they just dont function after powerup.They can be programmed.

 

 

Wow, if you eat more cycles moving it back and forth then it's an even more gimped system than I thought. If only they did a cache controller we wouldn't be having this discussion in the first place, and a lot more people would have used the CPUs.

 

 

Yes 4k of code every fram for every 4k flip as opposed to a few cycles lost running in main.

You really dont know what you are saying do you?

 

I'll be waiting for those benchmarks, by the way.

 

You'll be waiting a long time too. Do your own homework....Ive done mine...I know Im right...I have actually done it.

I dont pop into conversations I dont know sqwat about , unlike yourself here.

 

What I HAVE noticed is that you always start talking about how many years you've done something to validate everything you've said (rather than things like, I don't know, sources).

 

Its no suprise experience means nothing to you. It fits you well actually. I guess you are right abotu wasting my

time mentioning it but I should have known when you joined just to battle with me, ineffectively so far, might I add.

 

Then here's a tip you might understand a little better - until you've

programmed on any of the consoles you constantly slag in comparison to the Jaguar why don't you shut up about what they can and can't do? Okay, enjoy!

 

here's a tip you might understand a little better -

Until you know the first thing about the Jaguar which you clearly do not, why dont you shut up yourself? You have

made it very clear to me you dont know a damn thing about the machine.

 

 

You're a real cocky individual who is full of a lot of crap (maybe on purpose because you know you can get away with it).

 

No I am individual that likes to post fact and stae things based on available information.

 

Let me tell you what cocky is...some jack ass signing up for the SOLE purpose of agruing( and quite poorly I might add)

with me, not knowign square one about the Jaguar....that is cocky and foolish to boot.

 

I may be cocky but Im at least as factual as I can possibly be.

 

Right now

I'm more interested in instilling a bit of doubt in the minds of your readers on this forum than actually getting you to admit you're wrong about anything.

 

Why? Becasue so far you have brought NOTHING to the table

other than your incorrect assumptions?

 

Yes clearly here to start a fight. Figured that out from the first post.

 

Good luck trying but so far you look like you dont have a clue compared to me when it comes to the Jaguar.

You could'nt saying the CRAP you are saying. Keep trying but you are wasting your time. I expect the likes of

you to come around and ...really...you are not the first and you wont be the last.

[JagChris]

The only thing I've read about Jaguar is in actual technical docs written by people with a genuine interest in documenting the thing. I've ignored the BS gleaned from places like Wikipedia (like the RISC CPUs having 64 registers, that's a good one)

 

You mean tech docs by people with interest in documenting the thing like this:

 

Jaguar Underground Dox

 

Which go on to state:

 

Registers

=-=-=-=-=

 

64 registers, each 32 bits wide, stored in two banks of r0..r31

interrupts always execute out of bank 0 (i.e. your code should

always execute in bank 1..)

 

JUD on the registers of TOM

 

Don't know which of you is winning the pissing contest, but I'd thought I'd chime in with that.

 

Carry on.

 

I don't know all this tech stuff yet, however, the guys at Eclipse who have worked on the PS1 say even it's 2D is done in 3d which I took to mean it's rather weak at doing straight 2D.

[Exophase]

The only thing I've read about Jaguar is in actual technical docs written by people with a genuine interest in documenting the thing. I've ignored the BS gleaned from places like Wikipedia (like the RISC CPUs having 64 registers, that's a good one)

 

You mean tech docs by people with interest in documenting the thing like this:

 

Jaguar Underground Dox

 

Which go on to state:

 

Registers

=-=-=-=-=

 

64 registers, each 32 bits wide, stored in two banks of r0..r31

interrupts always execute out of bank 0 (i.e. your code should

always execute in bank 1..)

 

JUD on the registers of TOM

 

Don't know which of you is winning the pissing contest, but I'd thought I'd chime in with that.

 

Carry on.

 

Okay, but referring to IRQ banked registers like that is extremely misleading. It's like saying that ARM has more than 15 general purpose registers (which some people do). You'd may as well call the program counter in machines that can't even visibly see it as an extra register too - afterall, isn't that what it's physically implemented as? Jaguar's RISC don't have any means of actually accessing the other bank of registers, so it's pretty pointless to refer to more than 32.

 

As far as the 4000 8x8 sprite thing is concerned, the main reason I brought it up is because Gorf has repeatedly used it to claim that PS1 can't draw sprites LARGER than 8x8. I don't know where the actual numbers come from (and I don't really trust what Sony says either way) but that kind of 2D fillrate isn't really an issue. In practice you don't actually have like 10 layers in 2D games, or tens of thousands of sprites zipping around the screen (if you can think of a good game that demonstrates this be my guest)

[A Sprite]

In practice you don't actually have like 10 layers in 2D games, or tens of thousands of sprites zipping around the screen (if you can think of a good game that demonstrates this be my guest)

 

Off the top of my head, Jurassic Park Arcade. (Sega)

 

Do continue.

[Gorf]

Okay, but referring to IRQ banked registers like that is extremely misleading. It's like saying that ARM has more than 15 general purpose registers (which some people do). You'd may as well call the program counter in machines that can't even visibly see it as an extra register too - afterall, isn't that what it's physically implemented as? Jaguar's RISC don't have any means of actually accessing the other bank of registers, so it's pretty pointless to refer to more than 32.

 

here...let me prove you wrong again....

 

movefa

moveta

 

Instructions allowing access tot he other bank via running from the opposite bank. No means of actually

accessing those? I chane ONE bit in a register and the Jaguar runs directly out of the alternate bank.

Really dude...do a little homework.

 

 

As far as the 4000 8x8 sprite thing is concerned, the main reason I brought it up is because Gorf has repeatedly used it to claim that PS1 can't draw sprites LARGER than 8x8. I don't know where the actual numbers come from (and I don't really trust what

 

 

I beleive I something more along the lines of it takes a bunch of 8x8's to make up a bigger sprite.

Stop with the convenient exagerations.

[spiffyone]

As far as the 4000 8x8 sprite thing is concerned, the main reason I brought it up is because Gorf has repeatedly used it to claim that PS1 can't draw sprites LARGER than 8x8. I don't know where the actual numbers come from (and I don't really trust what Sony says either way)

 

Well, we can agree on that last part, at least in principle.

 

It is very funny to read the numbers go down from 1.5 million flat shaded polys per second and 500,000 fully textured and lit polys per second to 360,000 flat shaded and 180,000 textured and lit.

 

Where'd all those extra polygons go?

 

My guess is, they either somehow made them part of physical reality ("PS3 will bring 4D gaming") and proceeded to snort them like coke (how else to explain the PS3 debacle?), or, they've made them physical and formed the sword that Kutaragi-san used to perform seppuku so as not to dishonor his ancestors.

 

 

Of course, Sony labeled it a "retirement"...but, c'mon...who has actually seen Krazy Ken since then?

[Exophase]

I'm pretty sure I said there were plenty of sites that had the exact same copied + pasted material as Wikipedia. Whoever came up with it (apparently Sony's site?) doesn't really matter. You got the wrong idea.

 

About PS1 sprites:

 

http://www.romhacking.net/docs/gpu.txt

 

Size can be up to 16x16.

 

Now that's a reasonable assement. Very few? Spoken like a true fanboy...oh I already admit to being one BTW

so save your breath. I see you know knothing about the Jaguar.. the GPU does not process the OPL commands.

The OPL is started by ANY processsor in the jaguar and thes traverces the list and fills the lines buffers ON ITS OWN.

How is that similar?

 

I never said the Jaguar GPU processes OPL commands, where are you getting this? I'm perfectly aware that the Object Processor does this. The GPU on the PS1 processes display lists and draws them to the screen "on its own" as you said, why does that sound so different?

 

 

Different indeed....too bad you got it wrong again....

 

Here allow me to help you. Im not afraid to stand by my words. I base them on nformation availble to me.

 

http://www.atariage.com/forums/index.php?s...l=sh2&st=48

 

Clearly? VASTLY? 'More robust' and efficient is HARDLY clearly and vastly. Compare the cycle per cycle.

The sh2 can split cycles for executing instructions. Reading is fundemental. You should try it sometime.

OR actually do the homework before you look stupid....dont worry though I did your homewrok for you

like I usually do for those who THINK they know what they mean.

 

What are you on about, "split cycles for executing instructions", you mean that it's pipelined, like every other RISC processor I'm aware of? Seriously, what are you even talking about? How is an instruction set that has half the registers, less orthogonality, and smaller immediates "more robust", why don't you explain that one...

 

"One SH2 alone is a much more robust and effecient a chip than the Playstation's

R3000. The SuperH series of instructions operate in half cycles in some cases.

Coded right it will do some damage to an r3000. SH has a more robust math set

too. "

 

Saying "much more robust and efficient" does seem to indicate it'd do better.

 

 

Horse toot. In some cases not on average.That might be true in an ideal

situation which usually never exsist in a computer program.

 

How are you going to back this up exactly...

 

If yu can fit it in the cache ...Im dying here... My point exactly.

The SH2's efficiency is incredible even with the 16 bit wide instructions.

It will hold its own even against a higher clocked r3000. BLow it away , no.

keep up and exceed in some situations.

 

Well you seemed to be giving quite a different impression in your comparison. I will grant it "keep up."

 

No they are not 64 bit widths becasue the BLITTER is the problem, and not the bus.

 

I threw no stabs at Carmack. I simply stated he does not know the JAguar as well as we now know the Jagaur,

unless he still plays around with his dev kit .However that is not possible as he has said he has nothing Jagaur

related anymore. The guy essentially ported whatever he could get away with to bring doom to the Jag and did

a frighteningly amazing job. But By his OWN ADMITANCE, said he could have done a lot better had he coded he

jag from scratch....read what I actually post and not what is convenient for your arguments please.

 

So you're saying that his comment on the texturing bandwidth is wrong, in all of that? Yes or no, and if so, explain how it was wrong.

 

We know the blitter has full speed access to the ram in the GPU..yes, its way too little but its there.

 

Yes, way too little for decent texture mapping, at any rate.

 

The fact is the blitter not being able to read more than a pixel, not that the bus could not handle it.

This is no longer true anyway. Like every console new discoveries and workarounds come along

and prove otherwise. We have discoverd such workarounds. Docs from ten years ago are not

as true as they used to be.

 

Okay, but if the bus was 32bit and clocked twice as fast then it'd have the same "theoretical" bandwidth but twice the pixel throughput. That's what I'm getting at. If it had a BUFFER of some size it'd have much better throughput too. No, the bus is not "responsible" for this per se, but the fact is that not all of the components can make full use of the wide bus in ways that are especially useful.

 

G-shading on the Jaguar is a full 64 bit operation in PHRASE mode. The phrase mode in the jaguar

for texturing does not exsist...only the one blitter channel has a phrase source with fractional

increment and is the REAL reason why....not becasue the bus cant handle it. Carmack's complaint

about the bus was the overall system access...becasue he gave probably too much time was given

to the 68k. If Carmack knew what I know now Im sure he would have used it. He's a brilliant

developer.

 

Is the texturing really relevant to which CPU was used? I'm sure either way Carmack didn't want to do a software renderer.

 

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.

 

Completely wasteful? Inefficent compared to a cache yes but completely wasteful?

 

When I say wasteful I mean wasteful. Not useless.

 

No, it is what actually takes place in the Jaguar when coded properly. YOU get over it.

I really dont care either other than to be factual. The Jaguar as a system manipulates data 64 bits at a time,

andI dont see why that cant not be classified as a 64 bit SYSTEM. Why do I need a 64 it ALU? Why?

 

You need a 64bit ALU to be considered 64bit because that's what everyone uses a metric for bit rating ;P (no, of course there won't be a standard for something like that...)

 

 

Artificially? The OPL runs on it own once started so does the blitter. Why are they any less a processor? The OPL

very much so has an instruction set. Read the docs. Ok so they dont look like conventional instructions but they still

fetch process and move on the the next like any other processor does. The blitter is different in that it needs to be

reloaded for every operation. Are they a CPU or a GPU? no but it is a bit block processor...PROCESSOR...and an

Object Processor...PROCESSOR..not like a sprite engine though it can 'emulate' one perfectly.

 

Again. All gaming consoles have parallel circuitry. Most people don't harp on this. PS1's GPU processes display lists in the same way, like I mentioned...

 

Naming really doesn't matter, on PS1 SPU is called "Sound Processing Unit", so what? All I'm saying is that Jaguar doesn't have some kind of massive parallelism unattained in any other platforms. It does have 3 CPUs, which does standout (no more than Saturn, of course), but the other components really don't set it apart in terms of parallelism.

 

The vic-20 video chip does not read and write based on a list of todo;s given to it. It is a hardwired function

of the chip. This is not the case with either the blitter or the OPL...Read...read....read....

they just dont function after powerup.They can be programmed.

 

I know how they work. And unless they're turing complete (have fun demonstrating that to me?) then what you're saying means very little to me.

 

Yes 4k of code every fram for every 4k flip as opposed to a few cycles lost running in main.

You really dont know what you are saying do you?

 

Can you describe what a "few lost cycles are"? Obviously whether to use overlaying or to take the hit of running it directly is going to depend on how it's coded and what the working data set is like. If you have a renderer that runs two very long passes per frame then of course you're going to benefit from swapping them into SRAM rather than running one of them in main RAM. You're just putting a particular spin on the wording...

 

You'll be waiting a long time too. Do your own homework....Ive done mine...I know Im right...I have actually done it.

I dont pop into conversations I dont know sqwat about , unlike yourself here.

 

That's funny, you even admitted you don't know anything about PS1 but still talk about it a lot.

 

Its no suprise experience means nothing to you. It fits you well actually. I guess you are right abotu wasting my

time mentioning it but I should have known when you joined just to battle with me, ineffectively so far, might I add.

 

here's a tip you might understand a little better -

Until you know the first thing about the Jaguar which you clearly do not, why dont you shut up yourself? You have

made it very clear to me you dont know a damn thing about the machine.

 

Fine, I'll shut up about the Jaguar when you shut up about everything else you don't know about.

 

 

No I am individual that likes to post fact and stae things based on available information.

 

Let me tell you what cocky is...some jack ass signing up for the SOLE purpose of agruing( and quite poorly I might add)

with me, not knowign square one about the Jaguar....that is cocky and foolish to boot.

 

I may be cocky but Im at least as factual as I can possibly be.

 

Why? Becasue so far you have brought NOTHING to the table

other than your incorrect assumptions?

 

Yes clearly here to start a fight. Figured that out from the first post.

 

Good luck trying but so far you look like you dont have a clue compared to me when it comes to the Jaguar.

You could'nt saying the CRAP you are saying. Keep trying but you are wasting your time. I expect the likes of

you to come around and ...really...you are not the first and you wont be the last.

 

Most of my criticism with your posts comes from what you say about OTHER platforms you know. Yeah, I'm sure you do know more about Jaguar than I do. And I really haven't argued much about Jaguar, only in ways relevant to OTHER platforms (calling things processors, bit ratings)..

[Gorf]

Of course, Sony labeled it a "retirement"...but, c'mon...who has actually seen Krazy Ken since then?

 

 

that is a scream of a pic...

[Exophase]

here...let me prove you wrong again....

 

movefa

moveta

 

Instructions allowing access tot he other bank via running from the opposite bank. No means of actually

accessing those? I chane ONE bit in a register and the Jaguar runs directly out of the alternate bank.

Really dude...do a little homework.

 

Alright, I was wrong. I admit missing those instructions entirely when I read through the docs.

 

I beleive I something more along the lines of it takes a bunch of 8x8's to make up a bigger sprite.

Stop with the convenient exagerations.

 

And that's where you're wrong, since you can use 16x16 sprites (of course you can use normal textured quads when you want bigger, but I digress)

[kevincal]

About the amount of polys per second the PS can move. It got me thinking...There's a 32X tech demo on youtube that is VERY impressive. No 32X game comes close. I believe in purely tech demos with no sound or AI programming, you can push a lot more poly's and effects per second. So maybe the original Sony claim of 500,000 a second was maybe what it was capable of under tech demo circumstances, where all of the system's power is devoted soley to graphics... The same wouldn't be possible in an actual game where sound and AI takes a big chunk of graphics processing power away. Is this feasable?

[Gorf]

Size can be up to 16x16.

 

Wow! You got me there...ok so its 16 x 16...still backs up what Im saying.

Big 2D graphics require either using two trips per sprite or building it up with

a bunch of 16 x 16 sprites. The bottom line is The Jagur got it beat in 2D ability.

 

I never said the Jaguar GPU processes OPL commands, where are you getting this? I'm perfectly aware that the Object Processor does this. The GPU on the PS1 processes display lists and draws them to the screen "on its own" as you said, why does that sound so different?

 

 

Many video processor use a list, like the 800 dli's. It does not necessarily mean its similar. The GPU in the PS1

uses a list for ALL its graphics, 2D or 3D...its different than how the OPL works.

 

Saying "much more robust and efficient" does seem to indicate it'd do better.

 

having coded both, I have to give the nod to the SuperH series. The instruction set is much nicer.

The R3000 is no slouch by any means, but I would use an SH due to some of the really nice

math they do...R3000 has a few less than the sh-2...that makwes it more robust..maybe not

generations apart, but I think it gives it the edge.

 

 

 

How are you going to back this up exactly...

 

Easy , just ask any one who has ever coded anything.

 

Well you seemed to be giving quite a different impression in your comparison. I will grant it "keep up."

 

I think you are just over interpreting the things I say, that is all. I dont do this to sound smart. I do it

to hopefully honestly answer questions. I think I have been reasonable in my assesment, givn the information

I have.

 

 

 

So you're saying that his comment on the texturing bandwidth is wrong, in all of that? Yes or no, and if so, explain how it was wrong.

 

Let's look at what he REALLY said.....

 

I actually dug up all my old jaguar development hardware to give to these guys a year or two ago.

 

Unfortunately, it turned out that I had lost the C compiler that I had retargeted to the jaguar RISC engines, so DOOM was no longer buildable.

 

There is something noble about developing on a dead platform -- it is so completely for the joy of the development, without any commercial motivation.

 

The quick recap on the jaguar:

 

The memory, bus, blitter and video processor were 64 bits wide, but the processors (68k and two custom risc processors) were 32 bit.

 

The blitter could do basic texture mapping of horizontal and vertical spans, but because there wasn't any caching involved, every pixel caused two ram page misses and only used 1/4 of the 64 bit bus. Two 64 bit buffers would have easily trippled texture mapping performance. Unfortunate.

 

It could make better use of the 64 bit bus with Z buffered, shaded triangles, but that didn't make for compelling games.

 

It offered a usefull color space option that allowed you to do lighting effects based on a single channel, isntead of RGB.

 

The video compositing engine was the most innovative part of the console. All of the characters in Wolf3D were done with just the back end scalar instead of blitting. Still, the experience with the limitations and hard failure cases of that gave me good amunition to rail against microsoft's (thankfully aborted) talisman project.

 

The little risc engined were decent processors. I was surprised that they didn't use off the shelf designs, but they basically worked ok. They had some design hazards (write after write) that didn't get fixed, but the only thing truly wrong with them was that they had scratchpad memory instead of caches, and couldn't execute code from main memory. I had to chunk the DOOM renderer into nine sequentially loaded overlays to get it working (with hindsight, I would have done it differently in about three...).

 

The 68k was slow. This was the primary problem of the system. You options were either taking it easy, running everything on the 68k, and going slow, or sweating over lots of overlayed parallel asm chunks to make something go fast on the risc processors.

 

That is why playstation kicked so much ass for development -- it was programmed like a single serial processor with a single fast accelerator.

 

If the jaguar had dumped the 68k and offered a dynamic cache on the risc processors and had a tiny bit of buffering on the blitter, it could have put up a reasonable fight against sony.

 

Now the LYNX, on the other hand, was very much The Right Thing from a programming standpoint. A fast little processor (for its niche), a good color bitmapped display, and a general purpose blitter.

 

Price and form factor weighed too heavily against it.

 

John Carmack

 

 

Is the texturing really relevant to which CPU was used? I'm sure either way Carmack didn't want to do a software renderer.

 

 

Well yes....ifyou use the 68k to control the blitter your killing yourself. I would ONLY use the GPU as it is internally

direct to the blitter and OPL. That is why they stuffed it all on one chip. The DSP is fine for reading samples and

playing them and for controller and io stuff...I would also ercommend doit poit traslations and some AI on the DSP

as even wtih all the sound, I/o and AI it has plenty of room for poit translations, further helping the GPU.

 

 

That sounds like a pretty serious design flaw.

 

It 's actually not a porpblem when you run code in main. I can fit an complete texturemapping

renderer in the 4k with no flips...see Surrounded!....and the rest I do out in main.

 

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?

 

 

Becasue it is a relevant part of this debate and why the Jaguar had so many issues with a decent frame rate.

 

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 am not sure how to even benchmark it..I could simply post the two older versions...Im trying to locate

those older sources to do just that. that is the BEST benchmark I can offer at this time but you will see

Im not bullshitting.

 

 

You need a 64bit ALU to be considered 64bit because that's what everyone uses a metric for bit rating ;P (no, of course there won't be a standard for something like that...)

 

 

I can live with the definition with single processor systems but I don't see how it fairly applies here.

 

The vic-20 video chip does not read and write based on a list of todo;s given to it. It is a hardwired function

of the chip. This is not the case with either the blitter or the OPL...Read...read....read....

they just dont function after powerup.They can be programmed.

 

I know how they work. And unless they're turing complete (have fun demonstrating that to me?) then what you're saying means very little to me.

 

Can you describe what a "few lost cycles are"? Obviously whether to use overlaying or to take the hit of running it directly is going to depend on how it's coded and what the working data set is like. If you have a renderer that runs two very long passes per frame then of course you're going to benefit from swapping them into SRAM rather than running one of them in main RAM. You're just putting a particular spin on the wording...

 

 

No you wont, not with the JAguar. you have to waste a few thousand cycles per flip.

You will not eat up that many in the same 4k patch of code running in main ram.

That is what I mean.

 

 

That's funny, you even admitted you don't know anything about PS1 but still talk about it a lot.

 

 

I know enough to make the points I've made but you are right, I am no PS1 expert.

Yet, I still have no one to prove me otherwise. If Im wrong, show me with some facts.

 

 

Fine, I'll shut up about the Jaguar when you shut up about everything else you don't know about.

 

 

I dont talk about things Im totally clueless on..that is not the case with the Sony. I dont know it

like I know the Jaguar but enough to know what I know. again.....show me some evidence to

prove otherwise and I'll concede. I do not need to be right if Im not.

 

Most of my criticism with your posts comes from what you say about OTHER platforms you know. Yeah, I'm sure you do know more about Jaguar than I do. And I really haven't argued much about Jaguar, only in ways relevant to OTHER platforms (calling things processors, bit ratings)..

 

It sure did not come across that way. The fact is I do not think I have been misleading or inaccurate..at least not

purpposefully.

[Gorf]

About the amount of polys per second the PS can move. It got me thinking...There's a 32X tech demo on youtube that is VERY impressive. No 32X game comes close. I believe in purely tech demos with no sound or AI programming, you can push a lot more poly's and effects per second. So maybe the original Sony claim of 500,000 a second was maybe what it was capable of under tech demo circumstances, where all of the system's power is devoted soley to graphics... The same wouldn't be possible in an actual game where sound and AI takes a big chunk of graphics processing power away. Is this feasable?

 

 

That is exactly why they came up with that number. All manu's do it. Stretch the specs to hell.

I admit it...I know this is a noramal practice. Oh and that 32X is not nearly as impressive as it

may look to you, but yes it does allow a better scene with no other code...rather useless though.

[Gorf]

Alright, I was wrong. I admit missing those instructions entirely when I read through the docs.

 

I appreciate the concession.

 

I beleive I something more along the lines of it takes a And that's where you're wrong, since you can use 16x16 sprites (of course you can use normal textured quads when you want bigger, but I digress)

 

 

Ok, ok..my point is the size limits exsist where they dont with the Jaguar's OPL.

 

Due to this constant bickering, I have made a proposal to a PS1 programmer, to sit with

me side by side and do ahonest to God assesment of the both of these systems. I v'e not yet

heard back from him but I hope he is willing...then I plan to do the same witha Saturn and a

32x coder.

[kevincal]

About the amount of polys per second the PS can move. It got me thinking...There's a 32X tech demo on youtube that is VERY impressive. No 32X game comes close. I believe in purely tech demos with no sound or AI programming, you can push a lot more poly's and effects per second. So maybe the original Sony claim of 500,000 a second was maybe what it was capable of under tech demo circumstances, where all of the system's power is devoted soley to graphics... The same wouldn't be possible in an actual game where sound and AI takes a big chunk of graphics processing power away. Is this feasable?

 

 

That is exactly why they came up with that number. All manu's do it. Stretch the specs to hell.

I admit it...I know this is a noramal practice. Oh and that 32X is not nearly as impressive as it

may look to you, but yes it does allow a better scene with no other code...rather useless though.

 

Here's a link to the 32X tech demo that I was referring to. I'd say it's pretty impressive.

 

[Gorf]

Yes...that's the one. Imperssive for the 32x but that's about it. Add a real game and watch the fame rate drop

and possibly the polycount anddraw distances which are minimal already.

[ManShowBoy]

Wasn't the Saturn the first dual-core console? Maybe it was hard to make games for it back in 95 but, today it would be considered easy since everything is multi-core these days.

Edited September 7, 2007 by ManShowBoy

[Gorf]

Wasn't the Saturn the first dual-core console? Maybe it was hard to make games for it back in 95 but, today it would be considered easy since everything is multi-core these days.

 

No, not dual core but two seperate processors...9 actually in the saturn, but only the two sh2's are useful for application

code.The rest are pretty much there to deal with I/O and the CD access and other system choers but the actual system

control is in the sh2's. It was not the first to have two general purpose processors...the Jaguar was before it and the 32x.

Genny has two general purpose processors but the z-80 is only there for sound...I do not think it controls the rest of the

system as the 68k does. Im not suer about this though and I am sure someone out ther in genny dev world may have

found a way, but it was not intended to operate that way as far as I can tell. The TG16 has two GFX processors but only

one main processor. There really is no such thing in the Jaguar. Any of the 3 processsors in the JAguar can fully control

the system.

[spiffyone]

About the amount of polys per second the PS can move. It got me thinking...There's a 32X tech demo on youtube that is VERY impressive. No 32X game comes close. I believe in purely tech demos with no sound or AI programming, you can push a lot more poly's and effects per second. So maybe the original Sony claim of 500,000 a second was maybe what it was capable of under tech demo circumstances, where all of the system's power is devoted soley to graphics... The same wouldn't be possible in an actual game where sound and AI takes a big chunk of graphics processing power away. Is this feasable?

 

 

Oh, it might be...except I don't actually remember any tech demos that showed PSone was capable of 1.5 million flat shaded and 500,000 textured and lit.

 

Regardless, most of the numbers they've given through the years (and MS is guilty of this as well...so too was Nintendo in some ways with N64) have just been "pie in the sky" imaginary numbers, even their "in game" numbers.

 

That's why I'd rather they lowball the figures like Nintendo did with GC and Sega did with DC.

 

And it's not like they (Sony) can't get an engine or demo game up and running fairly quickly to test those conditions.

[spiffyone]

Genesis could flip to Z80 mode when used with Master System games (backwards compatibility, as the Z80 was primary CPU in SMS). Otherwise, it was the 68k all the way, with Z80 as sound controller as you stated.

[Gorf]

Genesis could flip to Z80 mode when used with Master System games (backwards compatibility, as the Z80 was primary CPU in SMS). Otherwise, it was the 68k all the way, with Z80 as sound controller as you stated.

 

Ah so then there must be some sort of hack to allow it to run the rest of the system, I would imagine.