JagCF last news before the before the launch of final proto.

[Atari_Owl]

I pretty sure Scatologic would LOVE to re-release BattleSphere and I bet at

a reasonable price. But they too have the same concerns as we do and rightfully so.

 

They may want to release it on Compact Flash medium since there will be an anti-copy protection mechanism.

It will be cheaper to produce and cheaper for the Jag lovers.

 

 

Some of us do not buy the protection. We have no idea how it works or if it

is good enough. As long as the CF is flash upgradable, it can be altered to

counteract the original protections in it.

 

The flash upgradability is an important aspect of the JagCF

because it allows to fix potential bugs even after the release of

the hardware.

 

So, there is a part of trust here. Otherwise, it is a dead-end.

 

And here in a nutshell we have the crux of the problem as there is a crippling lack of trust in the jag 'communty' from all sides to all sides.

 

Is there a way out of that?

Not so far as i can see. Which is... to say the least... a rather sad state of affairs.

Edited October 2, 2007 by Atari_Owl

[Gorf]

I pretty sure Scatologic would LOVE to re-release BattleSphere and I bet at

a reasonable price. But they too have the same concerns as we do and rightfully so.

 

They may want to release it on Compact Flash medium since there will be an anti-copy protection mechanism.

It will be cheaper to produce and cheaper for the Jag lovers.

 

 

Some of us do not buy the protection. We have no idea how it works or if it

is good enough. As long as the CF is flash upgradable, it can be altered to

counteract the original protections in it.

 

The flash upgradability is an important aspect of the JagCF

because it allows to fix potential bugs even after the release of

the hardware.

 

So, there is a part of trust here. Otherwise, it is a dead-end.

 

And here in a nutshell we have the crux of the problem as there is a crippling lack of trust in the jag 'communty' from all sides to all sides.

 

Is there a way out of that?

Not so far as i can see. Which is... to say the least... a rather sad state of affairs.

 

This could have been done so much more intellegently and considerately and

things could have been better if not for that one issue. I've said all I can say.

I've done all I can do. My consience is clear.

[Gorf]

The flash upgradability is an important aspect of the JagCF

because it allows to fix potential bugs even after the release of

the hardware.

 

 

I understand this, but anyone with the same FPGA dev board can develop

a flash for it of there own. It would not be hard. The CF would need some

external, custom circuit to defend against this and that would further add

to the cost and still would not guarantee a crack free product.

 

My problem is, though you say there is protection, we dont know

how carefully that has been implemented. One layer is not enough.

 

 

So, there is a part of trust here. Otherwise, it is a dead-end.

 

 

Exactly and we are trying to help you out by telling you what would make

us trust this device. Unfortunately after some of the posts i've read here

that will not be much anymore.

[SebRmv]

The flash upgradability is an important aspect of the JagCF

because it allows to fix potential bugs even after the release of

the hardware.

 

 

I understand this, but anyone with the same FPGA dev board can develop

a flash for it of there own. It would not be hard. The CF would need some

external, custom circuit to defend against this and that would further add

to the cost and still would not guarantee a crack free product.

 

I don't think that "anybody" will be able to do that.

Moreover, as far as I know, SCPCD planned to protect the FPGA itself

from curious people... do not ask me details because I am not really an

expert at this.

[SebRmv]

So, there is a part of trust here. Otherwise, it is a dead-end.

 

 

Exactly and we are trying to help you out by telling you what would make

us trust this device. Unfortunately after some of the posts i've read here

that will not be much anymore.

 

I fear it is not the truth.

 

Your only solution is "remap the base address of the extra RAM" (I do not agree with this statement but well, this is not my point here).

But after that you say: "even if you do that, since it will be possible to flash upgrade the JagCF, we won't trust you".

Edited October 2, 2007 by SebRmv

[Gorf]

The flash upgradability is an important aspect of the JagCF

because it allows to fix potential bugs even after the release of

the hardware.

 

 

I understand this, but anyone with the same FPGA dev board can develop

a flash for it of there own. It would not be hard. The CF would need some

external, custom circuit to defend against this and that would further add

to the cost and still would not guarantee a crack free product.

 

I don't think that "anybody" will be able to do that.

Moreover, as far as I know, SCPCD planned to protect the FPGA itself

from curious people... do not ask me details because I am not really an

expert at this.

 

 

Why has not SCPCD approached Myself or T-Bird directly? I few

talks with him and what he plans to do to protect other developers

may sway us. It's not like he can't PM us or anything.

[SebRmv]

The flash upgradability is an important aspect of the JagCF

because it allows to fix potential bugs even after the release of

the hardware.

 

 

I understand this, but anyone with the same FPGA dev board can develop

a flash for it of there own. It would not be hard. The CF would need some

external, custom circuit to defend against this and that would further add

to the cost and still would not guarantee a crack free product.

 

I don't think that "anybody" will be able to do that.

Moreover, as far as I know, SCPCD planned to protect the FPGA itself

from curious people... do not ask me details because I am not really an

expert at this.

 

 

Why has not SCPCD approached Myself or T-Bird directly? I few

talks with him and what he plans to do to protect other developers

may sway us. It's not like he can't PM us or anything.

 

Every developer has been invited to subscribe on the Jagware forum to discuss about the JagCF.

You did not want to do it, that is your choice.

[GT Turbo]

Only someone inexperienced would say such a stupid, uninformed thing.

 

Yes i'm an inexperienced guy that's why i have asked SCPCD and Zerosquare about that, and trusting the two people who has done the JagCF and you, my choice was done. Because at this time you haven't give any proofs except you have managed to make the Gpu running slower than on a stock Jaguar and you talk about optimising.....

 

A gpu code can run very fast only in some case very hard to have, when no others acces to the ram (That means without OP processing (no picture on screen), that will be very hard to play without screen no ? With no digitized music, ...), i think a game without picture and sound isn't a game, perhaps you ?

 

Yes we know more than can you think, be sure that the logic analyzer is a great tool even if you think no.

 

GT

[Atari_Owl]

Only someone inexperienced would say such a stupid, uninformed thing.

 

Yes i'm an inexperienced guy that's why i have asked SCPCD and Zerosquare about that, and trusting the two people who has done the JagCF and you, my choice was done. Because at this time you haven't give any proofs except you have managed to make the Gpu running slower than on a stock Jaguar and you talk about optimising.....

 

A gpu code can run very fast only in some case very hard to have, when no others acces to the ram (That means without OP processing (no picture on screen), that will be very hard to play without screen no ? With no digitized music, ...), i think a game without picture and sound isn't a game, perhaps you ?

 

Yes we know more than can you think, be sure that the logic analyzer is a great tool even if you think no.

 

GT

 

I'm disappointed the thread is still following this line.

 

Gorf is not the only person who has claimed to be running RISC code from main. *I* am telling you too, and i've been running code in this manner for some time, though i admit previously i found it to be slower than i had hoped which made me less effusive about its merits.

 

Is it slower than from local ram?..... Yes for sure it is.

Is it 6 times slower?..... It can be up to 5x slower but not always and can often be much faster than that (though still slower than running locally).

Is it faster than doing the same with the 68k?..... Yes, by some considerable margin.

Is it faster than paging RISC code into local ram?..... Ummmmm, sometimes, it depends on how intensive the code is.

DO all the other processors (eg OP) need to be kept off the BUS?..... NO that would be silly and impractical

 

Remember that the OP is actually hitting the bus only a small proportion of the time. And is reading it very efficiently when it does.

Keeping the 68k off the bus is however a very good idea as it is extremely inefficient by comparison.

 

I don't know why i'm saying this... its been said many times before.

 

It IS a useful method... i'm saying this to you completely independently... both Gorf and I developed our techniques entirely separately and have both found them to be useful. Why would we both say this if it weren't true?

 

 

You may think you are responding only to Gorf on this... but this is also my work.

[SebRmv]

Just to clear things up:

 

I am in favor of the ability to play ROMs on the JagCF, but

 

1-it has been offered to developpers to discuss on a case by

case basis about mechanisms to prevent from playing their

(cartridge) games on the JagCF.

 

2-the JagCF will allow to play new games distributed on

Compact Flash; for those new CF games, an anticopy

protection mechanism is planned.

 

Hope I did not make a mistake.

In case I did, please could you correct me Zero^2?

 

Seb

 

 

edit: changed the presentation in order to make a

distinction between my own opinion and general

facts

Edited October 2, 2007 by SebRmv

[mariaud]

just one thing you 've forget :

 

0- the JagCF™ is a development tool

[Zerosquare]

Hope I did not make a mistake.

In case I did, please could you correct me Zero^2?

No mistake, this is correct.

[Gorf]

Only someone inexperienced would say such a stupid, uninformed thing.

 

Yes i'm an inexperienced guy that's why i have asked SCPCD and Zerosquare about that, and trusting the two people who has done the JagCF and you, my choice was done. Because at this time you haven't give any proofs except you have managed to make the Gpu running slower than on a stock Jaguar and you talk about optimising.....

 

A gpu code can run very fast only in some case very hard to have, when no others acces to the ram (That means without OP processing (no picture on screen), that will be very hard to play without screen no ? With no digitized music, ...), i think a game without picture and sound isn't a game, perhaps you ?

 

Yes we know more than can you think, be sure that the logic analyzer is a great tool even if you think no.

 

GT

 

 

Well just from the code Ive written, I can tell none of you know what you are talking about. If you can sit here

and try to convince me that some logica analyzer with some sample code that simply triggers the blitter

is a serious test of the GPU, I have to say, you really need to dig deeper into those Jaguar docs because you

dont know what you think you know. Logic anylizers are wonderful tools but they certainly cant tell you everything

nor can the DISPROVE that the GPU runs slower in main ram, especially with the sample used. I have no way of

knowing how you hooked this thing to the jaguar and what parameters you were using on the LA to determine

one way or another if you are correct or not. My code and experiences tell me you are completely incorrect.

 

But hey fine.

 

You go ahead and believe that the 68k is more efficient than the GPU in main. This will be only

your loss and not mine. I know what I've discovered is awsome. Im quite glad you dont even care

to see it for your selves. My GPU code may very well run slower in SOME instances but It will piss

on your most optimized 68k...ANYTIME.....ANYDAY.

 

You go ahead plug in another unecessary processor in an already cmplicated bus instead of

making good use of the extremely under-utilized DSP and GPU ALREADY in the Jaguar instead

of putting your energies toward gettting the most you can out of what is already there. I find this

rather ball-less to be quite honest. It seems to me you guys are afraid of these chips, the way you

all seem to avoid them.

 

You go ahead and think that the world will stop what it is doing to write from scratch a complete

development kit of a completely unknown processor such as your DSP. I hope your friends are

masters at machine descriptors and are VERY generous to do all that work for you for nothing.

 

You go ahead and think that you are going to port the entire world of titles to the CF

fast enough to satisfy everyone or even be able to cover everyones tastes in games,

especially when you dont even have any tools to code with.

 

You go ahead and hook up logic anylizers using meaningless code examples that do nothing

to show the REAL potential for running code in main. I gave you guys a GPU optimized version

of that same code and i still did not see you run THAT test. I heard excuses that he had no time

but has enough time to come here and argue this BS.

 

Be my guest dudes. It's your reputation not mine.

[Fadest]

Well, I never read that 68k entered in the comparison, it was just between GPU in its own RAM, and GPU in main, no ?

Reading all of you, I have the impression that everybody is saying nearly the same thing, but don't read each other.

In fact, the only point not cleared is "is running GPU from main is really slower that running from it main RAM ?"

Maybe this is not signifiant, or 6 times slower, this is probably depending of many things.

 

Hope I'm clear, but I'm not sure...

[Gorf]

Well, I never read that 68k entered in the comparison, it was just between GPU in its own RAM, and GPU in main, no ?

Reading all of you, I have the impression that everybody is saying nearly the same thing, but don't read each other.

In fact, the only point not cleared is "is running GPU from main is really slower that running from it main RAM ?"

Maybe this is not signifiant, or 6 times slower, this is probably depending of many things.

 

Hope I'm clear, but I'm not sure...

 

 

At times the GPU will run 5+ cycles on some instructions even from local. It is also based

on what else is going on out on the bus. The advantage of local is it is DEFINITELY faster

and uninterrupted. But it is also only 4k and it also needs to have the blitter flip in anything

bigger than 4k which wastes a lot more time than droping a cycle or two and maybe up to 6

or more running out in main.

 

There is a gain in performance over local the more local modules you need to flip in every

frame. A very BIG gain. Cycle for cyle? the GPU will ALWAYS be faster in local, but the long

haul main makes a huge difference in performance because the very FACT that the 68k is no

longer slowing down the system by 1/2 the clock and 1/4 the bus width. That is why the 68k is

quite relevant to this discussion. If you were to write a 4 k game that all fit in the GPU local, it

would be the fastest you could get, no doubt. The main code execution replaces the need for

the 68k and NOT the need for running the GPU in local, you still need to do this but if you can

fit the renderer in one 4k block as in Surrounded! and not have to flip anything else in , you will

have significantly increased your overall thoughput.

 

One or two modules flipped in and the performance suffers exponentially. if you can run

the non time critical stuff in main and essentially leave the rendering and fast stuff in local

you will absolutely gain more and moer performance the more modules you eliminate.

 

Surrounded! Is the best proof I can offer. I will keep looking for the old code to show you the

68k version and then the GPU code flip version which is definitely faster and then the main ram

code which is 60 FPS and twice as fast on average as the code flipped version. It really makes

a grave difference. If no one wants to believe me, fine but like I have said its your loss. The truth

be told is the trouble it takes to code in main due to a lack of tools that understand it, is quite a lot

to deal with but the increase in performance is absolutely beyond worth it.

[Fadest]

Let me try to summarize, from best to worse :

 

GPU in local

better than GPU in main

better than GPU in local with flipping (but sometimes, this can be the contrary, depending on code, or need to flip...)

far better than 68K

 

From what I have read from every poster, everybody agree on this, the main subject is which gain is obtained...

Well, nothing that should degenerate in flame war, right ?

 

 

 

Now, this have nothing to do with technic : concerning the gamer point of view.

A very good game in 68k

is better than a bad game in GPU local or even

 

but may be far worse than a very good game in GPU (local or main), depending on interest. The point is "very good game" here .

[walter_J64bit]

From what I've read, it sounds like Jagwares JagCF is their answer to a 32X add on.

[Gorf]

I pretty sure Scatologic would LOVE to re-release BattleSphere and I bet at

a reasonable price. But they too have the same concerns as we do and rightfully so.

There is a solution to that.

 

Preorders. Not only will you get a clear view of how many you need to make, you don't even have to fork out the money to make them, and in the end risk nothing.

 

Preorders are asking for trouble. I know we and Scatologic BOTH have a 'sell only in hand' policy.

The last thing we wan to do is take your money without a product. and preorders simply cover the first run.

then the copiers can run rampant. Not a good solution. We dont mind puting the money out. We just want to

be sure we get it back is all.

Edited October 3, 2007 by Gorf

[GT Turbo]

Well just from the code Ive written, I can tell none of you know what you are talking about. If you can sit here

and try to convince me that some logica analyzer with some sample code that simply triggers the blitter

is a serious test of the GPU, I have to say, you really need to dig deeper into those Jaguar docs because you

dont know what you think you know. Logic anylizers are wonderful tools but they certainly cant tell you everything

nor can the DISPROVE that the GPU runs slower in main ram, especially with the sample used. I have no way of

knowing how you hooked this thing to the jaguar and what parameters you were using on the LA to determine

one way or another if you are correct or not. My code and experiences tell me you are completely incorrect.

 

You do the same thing than me, working without tools !! I code without debugger and you work without logic analyzers.....

 

 

You go ahead and believe that the 68k is more efficient than the GPU in main. This will be only

your loss and not mine.

 

Where i have wrote that ? I'm curious !

 

I know what I've discovered is awsome.

 

Verry happy for you.

 

You go ahead plug in another unecessary processor in an already cmplicated bus instead of

making good use of the extremely under-utilized DSP and GPU ALREADY in the Jaguar instead

of putting your energies toward gettting the most you can out of what is already there. I find this

rather ball-less to be quite honest. It seems to me you guys are afraid of these chips, the way you

all seem to avoid them.

 

Who has told we want to avoid them ? Who ? I'm very curious, again you wrote things we have never told.

 

Have you tried to code on the DSP of the Falcon ? The DSP from the Jaguar is a little child versus the 56K in the Falcon. When i have started to code on the Gpu and the Dsp of the Jaguar, after two days i have tried to code anything i want on this chip, they are very easy to understand. Before writing we want to avoid it, try the 56K and after we can talk.

 

 

 

You go ahead and think that the world will stop what it is doing to write from scratch a complete

development kit of a completely unknown processor such as your DSP. I hope your friends are

masters at machine descriptors and are VERY generous to do all that work for you for nothing.

 

What have been the price of Atomic ? Or DiamJag ? Jagware has yet prouved that we can give things for nothing, never forget the JagCF has not been done for earning money.

 

 

You go ahead and think that you are going to port the entire world of titles to the CF

fast enough to satisfy everyone or even be able to cover everyones tastes in games,

especially when you dont even have any tools to code with.

 

We have a lof ot projects in progress, we will do games that we want to do, nothing else. Which tools ? You always told about tools that we don't have ? Who has wrote that ? Pocket has yet written that's not because YOU don't have it, anybody don't got it. Never forget WE are developers than means we can and we write missing tools.

 

But if we need some help, we can contact all our friends like Paradize, Sector One, Dune, Mjj Prod, ... i will stop here because the list will be very long, we came from the Atari world, not from the Jaguar world, we know a lot of great artists and coders.

 

 

You go ahead and hook up logic anylizers using meaningless code examples that do nothing

to show the REAL potential for running code in main. I gave you guys a GPU optimized version

of that same code and i still did not see you run THAT test. I heard excuses that he had no time

but has enough time to come here and argue this BS.

 

Be my guest dudes. It's your reputation not mine.

 

My reputation ? I have nothing to proove, if people trust in the Jagware community or in you, that's their choice.

You always talk about proofs, but can we get the chronogram from your code running in main ? For having a real proof ? I will trust you if you can give REAL PROOFS, and if think a lot of people here think the same thing but at this moment, i think SCPCD and Zerosquare are right.

 

GT Turbo

 

P.S. : Another pm for supporting the JagCF yesterday.

[JagMod]

P.S. : Another pm for NOT supporting piracy today.

 

Oops, did I forget to post something?

[Gorf]

You do the same thing than me, working without tools !! I code without debugger and you work without logic analyzers.....

 

 

I dont know of many programmers that have a LA next to them. Only those that are usually trying to crack some one elses

IP's. Oops!

 

Where i have wrote that ? I'm curious !

 

 

You imply it well enough without saying it.

 

Verry happy for you.

 

I doubt that quite honestly.

 

Who has told we want to avoid them ? Who ? I'm very curious, again you wrote things we have never told.

Have you tried to code on the DSP of the Falcon ? The DSP from the Jaguar is a little child versus the 56K in the Falcon. When i have started to code on the Gpu and the Dsp of the Jaguar, after two days i have tried to code anything i want on this chip, they are very easy to understand. Before writing we want to avoid it, try the 56K and after we can talk.

 

 

I never had a Falcon030, even though I did want one. But knowing one chip is not like knowing another

Regardless you are wasting a very valuable resource in the Jaguar by not working wround the main ram

issue. If you guys were so good at RISC and DSP code you would not need to add a new chip to a system

that has two very under-utilized processors at it is.

 

 

What have been the price of Atomic ? Or DiamJag ? Jagware has yet prouved that we can give things for nothing, never forget the JagCF has not been done for earning money.

 

What does this have to do with anything? Those games are cute little projects and I'd give them away too, but hardly on

the level of writing a tool kit for an unknown chip. Well unless that chip is really someone elses IP of VHDL code you took

and altered and renamed the mnenomics for, which would not suprise me, you are not just going to wake up one morning

and port GNU GCC, sorry. If this was that simple for you, you would have done it already for the DSP and the GPU. That

would have been more practical a help to the Jaguar community, instead of adding more unknowns with a whole new,

unecessary(IMHO) chip.

 

 

We have a lof ot projects in progress, we will do games that we want to do, nothing else. Which tools ? You always told about tools that we don't have ? Who has wrote that ? Pocket has yet written that's not because YOU don't have it, anybody don't got it. Never forget WE are developers than means we can and we write missing tools.

But if we need some help, we can contact all our friends like Paradize, Sector One, Dune, Mjj Prod, ... i will stop here because the list will be very long, we came from the Atari world, not from the Jaguar world, we know a lot of great artists and coders.

 

 

Hey I can write tools too and I know it's no walk in the park, Im writting them now for the GPU and the DSP to further

utilize the ORIGINAL Jaguar. I dont care how many guys you have, if they dont understand machine descriptors like

they know there own body, they wont be very optimal descriptors. Again, If you had such people willing and capable

you would have done it for the original processors.

 

My reputation ? I have nothing to proove, if people trust in the Jagware community or in you, that's their choice.

 

You suer acted like you did saying the CD is dead and you will save the Jaguar. Save the Jaguar using the Jaguar.

Then you 'll impress me. oh....and yes your reputation of looking foolish becasue you don't want to learn something

useful.

 

You always talk about proofs, but can we get the chronogram from your code running in main ? For having a real proof ?

 

Give me the full details of the CF protection scheme and then I'll believe you are not using the device for nor-do-well

reasons. I dont need to prove it to you ...you have heard it from Atari Owl and from T-bird and you still don't beielive it.

I fear me giving you the source is just supporting your laziness to not figure it out your self. Have you no sense

of challenge? Oh, and when I do release the information, remember what I said about your reputation. It will prove

you do not know what you think you know....like I have been saying.

 

I will trust you if you can give REAL PROOFS, and if think a lot of people here think the same thing but at this moment,

i think SCPCD and Zerosquare are right.

 

Surrounded! is real proof. Again, believe whom you will. It's your loss.

 

 

GT Turbo

P.S. : Another pm for supporting the JagCF yesterday.

 

I can get my friends to PM me too but my friends are time experienced on the Jaguar a lot longer than you ST guys.

If you think knowing the ST is a good way to approach the Jaguar, I have some land on the Mississippi to sell to you.

Edited October 3, 2007 by Gorf

[+remowilliams]

Why oh why couldn't Tototek have released a flash card for the Jag a long time ago. Then we wouldn't be having this stupid 'discussion'.

 

Oh wait, given the state of the Jag 'community' we probably would be anyway.

[mariaud]

Oops, did I forget to post something?

 

let me guess ... a constructive remark perhaps ?

[Gorf]

Why oh why couldn't Tototek have released a flash card for the Jag a long time ago. Then we wouldn't be having this stupid 'discussion'.

 

Oh wait, given the state of the Jag 'community' we probably would be anyway.

 

 

The state of the Jaguar community would be less developers with the Tototek

as if it were the same thing. I dont care who makes such a device. I dont plan

to allow my code to run on it. If I cant come up with a way then the code will

never be available in the first place, like most sane developers would do if the

CF or Tototek or whatever was available.

Edited October 3, 2007 by Gorf

[Orion_]

The state of the Jaguar community would be less developers with the Tototek

so why are there more developers (than on the jaguar) in the others homebrew communities that have flash card device for their system ?

simply because most of you developers here don't have the homebrew spirit and want money like if you were working for a game company