SebRmv

[deleted because of double post]

There be here! You did you know that the CF is limited to friends only, that is what I was told! Just at look at you are you a pirate too? RRRR! You are just ridiculous. One of my drawback is that I am a collector and especially a Jaguar one. So don't expect me to games.

I think it would be nice if an admin could stop this flame war. I voted JagVR. But actually, I want a JagCF asap!

Yes, I know that. May I ask you your tables so that I can have a quick look at them? (otherwise, I'll code that myself when I'll have some time...) I dont have any tables so to speak. I wrote a small GPU app that did a bunch of combinations of divides with different inputs. The code I use needs the entire suite of test tools for you to be able to use them and they are not ready for release yet. Ok. I just wanted to help But I am very surprised if the divide unit does not behave as I said above.

Yes, I know that. May I ask you your tables so that I can have a quick look at them? (otherwise, I'll code that myself when I'll have some time...)

Actually no....I tried the same thing and the results were not exact. I never really did try to dig down in it. really? do you still have tables of experimental values? because on paper, the "non restoring division" algorithm behaves like that

Hi, during the night, I had a revelation. The sign of the remainder depends on the parity of the quotient (and conversely)!! (this result is trivial when looking at the algorithm) Indeed, we have that "r < 0" if and only if "q is even". So, a simple way to emulate the division algorithm of the GPU/DSP is: q = a/b; r = a%b; if(q & 1 == 0) { r -= b; } Simple, isn't it ?

Well, apparently, about the 16.16 mode, you just have to do the normal division but with (a << 16) and b (my code needs to be hacked a bit)

Yes, but it may not give you the results the Jaguar gives. You could give it a try... I might but Jaguar right now is not HIGH on my priorities list. Other work needs to be finish first to make some customers happy, and me a living. Of course. Here is a C version of this algorithm I have quickly coded: #include <stdio.h> #include <stdlib.h> int divide(int a, int b, int *q, int *r) { int i; *r = 0; *q = a; for(i = 0; i < 32; i++) { if(*r < 0) { *r <<= 1; if(*q & 0x80000000) { *r |= 1; } *q <<= 1; *r += b; } else { *r <<= 1; if(*q & 0x80000000) { *r |= 1; } *q <<= 1; *r -= b; } if(*r >= 0) { *q |= 1; } } } int main(int argc, char *argv[]) { int a, b, q, r; if(argc == 3) { a = atoi(argv[1]); b = atoi(argv[2]); } divide(a,b,&q,&r); fprintf(stdout,"%d / %d = (%d, %d)\n",a,b,q,r); if(r < 0) { r += b; } fprintf(stdout,"%d = %d * %d + %d\n",a,b,q,r); } Hope this helps. One can notice that, for instance, 12 / 3 gives back 4 and -3

Yes, but it may not give you the results the Jaguar gives. You could give it a try...

A quick word to say that I made a bugfix today. The new version is available for download now.

well, Google is your friend "non restoring division algorithm" gives lots of results...

Read: "gpu debugger" , not "Jaguar 'simu/emu/debug'-er" my plan for the moment is to use it for my next project, why do you think I released the source *edit* and I really don't see the point between cry and the gpu O_o by the way, If I had ripped the mame code I should not have any bug in the instruction emulated, and it's not the case, I just found a bug in my sharq instruction... Oh and i looked at the mame source code, i really don't see where you see similarities, they use one function per instruction, instead of case/switch for me, if you see that the structure for instructions is the same, then try to code a gpu instruction emulator and you will surely choose the same structure has you don't have any other way to do it ... Except for two or three instructions, mine uses a simple switch() to handle all intructions. I also ran at least a couple dozen tests on each GPU instruction of a real jag and compared the results with my code. Onle the remainder divide is not right yet...and I cant understand why. About the division, why don't you take the NET files of the Jaguar and adapt the division algorithm in your simulator? Its a hardware issue with the Jaguar. The PC is probably giving accurate(TRUE) results. Im not sure the .NET's would do me much good even if I did want to use those, which I dont. I'll eventually figure out what is wrong or different I always do. It was just to say that you cannot simply write in your simulator code: q = a / b r = a % b you have to emulate the algorithm used in the Jaguar since the value G_REMAIN is not exactly the remainder but a value that permits to compute the remainder...

Read: "gpu debugger" , not "Jaguar 'simu/emu/debug'-er" my plan for the moment is to use it for my next project, why do you think I released the source *edit* and I really don't see the point between cry and the gpu O_o by the way, If I had ripped the mame code I should not have any bug in the instruction emulated, and it's not the case, I just found a bug in my sharq instruction... Oh and i looked at the mame source code, i really don't see where you see similarities, they use one function per instruction, instead of case/switch for me, if you see that the structure for instructions is the same, then try to code a gpu instruction emulator and you will surely choose the same structure has you don't have any other way to do it ... Except for two or three instructions, mine uses a simple switch() to handle all intructions. I also ran at least a couple dozen tests on each GPU instruction of a real jag and compared the results with my code. Onle the remainder divide is not right yet...and I cant understand why. About the division, why don't you take the NET files of the Jaguar and adapt the division algorithm in your simulator?

Impressive again I imagine the nightmare it can be to handle this correctly. I imagine it was transparent at usage, isn't it? DId you split also scaled sprites (the word "nightmare" should be a bit weak then )? I am not anymore so impressed because I just finished to write a sprite manager that works the same way Scaled sprites were a bit tricky to handle anyway. Check it out with the Removers library 1.1.4 at http://removers.atari.org/softs/download.php

jagopedia.atari.org unfortunately, not much has been contributed so far feel free to ask for a login anyway

Thanks Matthias

Great! I have to give it a try when I find my BJL cable

Interesting! Thanks for this. Actually, I cannot make these work on my Alpine. I tried the command in rdb.rc but this does not seem to make anything apart from loading the indicated files (the green screen of the stubulator stays) Is there anything special to do? edit: sorry, apparently, I hadn't read carefully before posting this. So the game is now to recompile this for the actual Jaguar, right?

I think Oliver just made the point for me that the 68k should not be running if you want real performance from the Jaguar. I think ultimately everybody agrees on that subject, no?

Hey! I thought exactly at this kind of optimisation during the night ! Concerning my MOD player, I adopted a lazy approach: I have just coded a Paula emulator and then adapted an Amiga routine.So this is the interrupt routine that makes all the resampling also. (10 instructions is thus very short for doing this ) Was it the case for your routine or did you do resampling by blocks (a bit like on STF thus)? Anyway, I'll try this LOAD vs LOADB trick then.

Impressive again I imagine the nightmare it can be to handle this correctly. I imagine it was transparent at usage, isn't it? DId you split also scaled sprites (the word "nightmare" should be a bit weak then )?

sh*t ! I missed that ! I hope someone made a video

Interesting. Thank you so much for these gems This makes me think I have still some work to do on my mod player because I am far from such performance. I am really impressed by 16 voices at 50 kHz! I would love to know the tricks you used

It is an early beta but the only thing aquired for sure is that it will be exclusively compatible with the JagCF