Vous n'êtes pas sans savoir que les jeux [multi-joueurs multi-consoles] sur jaguar ne sont pas légions pour la simple et terrible raison qu'un vilain bug empêche les transmissions de correctement se dérouler.

Une seule personne a réussi à le découvrir et l'a utilisé pour son jeu : Thunderbird avec Battlesphere



Voici le dernier sujet en date sur jaguar sector II :



vous remarquerez qu'on essaye d'avoir des réponses mais même avec les meilleures intentions du monde rien ne filtre !



http://jaysmith2000.ipbhost.com/index.php?...c=3075&st=0



Pour ceux qui auraient des problèmes d'ego, et vu que ce bug traine depuis longtemps , sachez que les meilleurs coders jaguars de ces 10 dernières années ( Mathias, Bastian, etc... ) ont déjà passé pas mal de temps dessus et n'ont rien trouvé !

Thunderbird doit être le meilleur ? ;)

Fredifredo malgré tout le respect que je te dois reposte pas ce genre de phrase ou je fais un demande a RaZ d'effacer ce sujet !!



Je viens aussi de le lire et je m'apercois que thunderbird est et restera un clown, ne pas partager ce genre d'info, pitoyable.



Je te prends le pari que nous sommes capables de trouver ce bug, si c'est hard nous avons de toute façon SCPCD qui a de toute façon un meilleur niveau que l'oiseau.



Dans la doc de la Jaguar, il est fait allusion a un problème de transfert d'octet qui peut se dérouler dans certain cas, il explique comment le résoudre, mais je penses pas que ce soit cela ca serait trop simple.



Je ferais des essais dès que je pourrais cabler la RaZ's Jag et la mienne. On laissera pas le jeu en réseau a 'l'élite'... Car je comptes bien profiter de cette possibilité qui n'a pas été très exploité !!



GT Pour partager mes infos !! :yes:

Si j'ai posté ce sujet c'est bien que j'espère que toi et SCPCD vous pourrez lui montrer qui sont vraiment les meilleurs ! :)



Jagware team Powa !

Jagware team Powa !



J'en fait une affaire personnel et je t'assures qu'il va se manger quelque chose !!



On va le trouver ce bug, et après on fait un article complet dessus avec tous les sources et on le dédicacera a.....





GT Une tourelle de DCA !! ;)



P.S. : Pour info l'UART désigne la puce de transfert utilisé pour le link de consoles

La vrai question est est ce qu'il y a deux bugs dans l'UART ?



Si la réponse est non, voila le bug et la technique pour le corriger :



There is a bug in the Jaguar UART.If a start bit is detected at a certain phase in the UART's divide by 16 timer, it will be shifted in twice, resulting in a left shift of the data byte.



The problem may be avoided by preceeding a data packet with a dummy byte where the MSB is set (E.G.$80). The receiver code should discard this dummy byte. Subsequent bytes should be exactly aligned (i.e. 2,3 or 4 stop bits exactly, before the next start bit). This will result in causing the falling edge of the next start bit to miss the phase of the UART counter which causes the problem.



If a gap is left after a byte which is more than 2 bit times long, or is not exactly aligned with the previous byte, then the dummy byte must be retransmitted (To align the UART counter again).







Voili, voila donc est ce que qu'il y a deux bugs dedans ? Pour info le texte d'avant provient de la doc Atari dans la page bug....



GT En train de lire ;)

Bah y en a 2 alors ! pasque sinon Thunderbird se farait pas chier à vouloir garder secret une info qu'il ne l'est pas !



cf : la suite du sujet sur JSII !

Ben si, ca s'appelle de la desinformation, pratique habituelle en temps de guerre pour tromper l'ennemi !

Deja, ce que l'on sait c qui est sur c'est que c'est la reception qui bug.

Car, il y a le programme de transfert de la clé de cryptage du CD qui est transmise par ce port.

Hors, je n'ai pas souvenir qu'ils ont parlé qu'ils avaient reussi a faire un code qui passe au dessus du bugg.

Tu veux dire que le code de la clef d'encryption contourne le bug mais avec des contraintes par exemple au niveau du timing ou de la redondance en renvoyant par exemple 2-3 fois les mêmes données pour être sûr du truc ?

non, je pense qu'il y a un bug que dans la partie reception de la Jag.

et pas dans la partie emmission (ce qui est logique en fait : c'est plus facile d'envoyer des données series asynchrone que de les recevoirs :wacko:)

Ok je n'y étais pas ! Pour l'encryption c'est la jaguar qui balance les données dans le PC via le port série/jaglink !



Donc le truc c'est qu'il faudrait balancer des données dans la jaguar via un Jaglink 2 par exemple ( j'en ai 2 sous la main dans un carton ... :mellow: ) mais à partir de quoi ? d'une autre jaguar ou bien d'un ordi ?

et pouvoir afficher le résultat sur la Tv reliée à cette jaguar pour savoir si c'est buggué ou pas ...



Un début de piste ici :



http://www.mulle-kybernetik.com/jagdox/jerry.html#NETWORK*



le site de Derek Else concepteur du Jaglink 2 :



http://home.comcast.net/~delse/

ben pour les tests, c'est vrai que en utilisant un PC ou un ATARI en faisant des progs d'envois de données serie, et d'afficher les resultats sur l'ecran de la Jag, ca permettrerais, je pense, de trouver un protocole qui marche.

Donc se reservir du même câble que pour l'encrytion des CD ?



C'est juste un cable DB9 avec 3 ou 4 fils et un prise RJ11 ( j'avais commencé à m'en faire à partir d'un RJ11 déjà connecté mais il est dans un carton ! )



C'est le genre de tache qui serait dans mes cordes quand tout mon matos sera en place d'effectué des tests de protocole ! :)



Si on se sert de 2 jaguars sinon, pourquoi ne pas utiliser un prog comme celui du joypad tester le code source est dispo ...

Je peux faire les essais, il va juste falloir qu'on regarde pour le cable de transfert.





GT ;)

Oui, il faut un cable comme celui pour l'encryption CD.

Quelqu'un a un schéma ? Que je puisse planter la console de mes reves :yes:



GT En train de bugger :wacko:

Tu peux trouver des infos sur le cablage ici :

http://www.domin-connect.de/Atari/Jaguar/j...ion20041018.zip

Schéma récupéré, maintenant pour la partie soft, je balances des séquences au hasard avec le micro, chiffre et intervalle variable.

Mais coté Jag, je fais une bete boucle au 68000 en attendant la réception d'un octet et j'en fais la lecture oue je fais une routine d'inter ?



Faut que je regardes dans le code de Doom, je sais que celui la plante par moment, mais je sais pas si les routines reception-emission sont dans les sources, cela permettrait de savoir quel type de lecture appliqué.



GT En train d'emettre ! ;)

un petit peu de C from Doom spécialement pour GT :D :

=====================

=

= I_NetSetup

=

======================

*/



void DrawSinglePlaque (jagobj_t *pl);



int listen1, listen2;



void I_NetSetup (void)

{

jagobj_t *pl;



DoubleBufferSetup ();

UpdateBuffer ();



pl = W_CacheLumpName ("connect", PU_STATIC);

DrawSinglePlaque (pl);



Z_Free (pl);



ASICLK = UCLK_115200;

ASICTRL = (1<<6);

ASICLK = UCLK_115200;

ASICTRL = (1<<6);



/* ASICLK = 0xffff; // very slow */



GetSerialChar ();

GetSerialChar ();

wait (1);

GetSerialChar ();

GetSerialChar ();



/* wait a bit */

wait (4);



/* if a character is allready waiting, we are player 1 */

listen1 = GetSerialChar ();

listen2 = GetSerialChar ();



if (listen1 == -1 && listen2 == -1)

Player0Setup ();

else

Player1Setup ();





/* wait a while and flush out the receive que */

wait (5);



GetSerialChar ();

GetSerialChar ();

GetSerialChar ();

DoubleBufferSetup ();

UpdateBuffer ();



}





/*

======================

=

= I_NetTransfer

=

======================

*/



void G_PlayerReborn (int player);



unsigned I_NetTransfer (unsigned buttons)

{

int val;

byte inbytes[6];

byte outbytes[6];

byte consistancy;

int i;



/* don't transmit during heavy blitter action */

#if 0

do

{

junk = phasetime[8];

} while (!junk);

#endif



outbytes[0] = buttons>>24;

outbytes[1] = buttons>>16;

outbytes[2] = buttons>>8;

outbytes[3] = buttons;



consistancy = players[0].mo->x ^ players[0].mo->y ^ players[1].mo->x ^ players[1].mo->y;

consistancy = (consistancy>>8) ^ consistancy ^ (consistancy>>16);



outbytes[4] = consistancy;

outbytes[5] = vblsinframe;



if (consoleplayer)

{

/* player 1 waits before sending */

for (i=0 ; i<=5 ; i++)

{

val = WaitGetSerialChar ();

if (val == -1)

goto reconnect;



inbytes[i] = val;

PutSerialChar (outbytes[i]);

}

vblsinframe = inbytes[5]; /* take gamevbls from other player */

}

else

{

/* player 0 sends first */

for (i=0 ; i<=5 ; i++)

{

PutSerialChar (outbytes[i]);

val = WaitGetSerialChar ();

if (val == -1)

goto reconnect;

inbytes[i] = val;

}

}



/* */

/* check for consistancy error */

/* */

if (inbytes[4] != outbytes[4])

{

jagobj_t *pl;



S_Clear ();

pl = W_CacheLumpName ("neterror", PU_STATIC);

DrawPlaque (pl);

Z_Free (pl);



wait (200);

goto reconnect;

}



val = (inbytes[0]<<24) + (inbytes[1]<<16) + (inbytes[2]<<8) + inbytes[3];



return val;



/* */

/* reconnect */

/* */

reconnect:

S_Clear ();



if (consoleplayer)

wait (15); /* let player 0 wait again */



I_NetSetup ();

if (starttype == gt_single)

Jag68k_main ();



G_PlayerReborn (0);

G_PlayerReborn (1);



gameaction = ga_warped;

ticbuttons[0] = ticbuttons[1] = oldticbuttons[0] = oldticbuttons[1] = 0;

return 0;

}

Trop fort ce Fredifredo !!



GT Epaté ! :wub:

J'ai chopé au détour d'une recherche sur mon DD le code source du Jaguar Modem et il y a 3 codes en assembleur 68k/GPU ? qui se nomment UARTrx , UARTtx et UART , peut-être pourraient-ils servir de départ à un prog de test ?

Pourquoi cherche un bug qui est connu par quelqu'un d'autre ?



En farfouillant ici :



http://www.mo5.com/obsolete/67-dossier-anecdotes-atari.html



et si on descend plus bas on trouve ceci :



Oui et le son était fait au DSP et le pauvre devait aussi gérer le fameux réseau qui d'ailleurs était buggué au niveau de la FIFO HARD de la puce obligeant à capturer chaque octet sous peine de le perdre !



Rodolphe Czuba et Thierry Schembri connaissaient déjà le bug !!!



GT Mort de rire !! ;)

Vraiment interressant ce dossier :)



Ils connaissaient le bug et apparement ils ont trouvé comment le contourner !!!!

Et j'ai compris comment ils ont fait ;)

UNE PUBLI !!! UNE PUBLI !!! UNE PUBLI !!! Vive SCPCD !!! SCPCD Président !!!:yes:

Bah, c'est le bug connu non ?



Et puis Fifo, faut le dire vite hein ! C'est juste un octet d'avance !



Donc, toujours l'histoire du $80 à tester pour voir si décalage en début de trame...

C'est une bonne question, j'ai un doute, enfin dans tous les cas de figure, j'ai juste posté cela car je trouvais cela interressant, après de toute façon SCPCD nous a règler le problème......Alors perdre du temps la dessus, moi ce que j'en dis....







GT ;)

C'est clair que de toute facon le probleme est resolu ;)

SCPCD and Jag CF Powa !!!! ;)





GT En réseau !! :p

Non c'est pas pareil !



Le problèmes est contourné ! et l'autre machin truc il aura toujours sa petite fierté en disant que lui seul a réussi et que pour faire un réseau non bugué la seule solution aura été de faire autrement !

Je suis d'accord en partie avec Fredifredo, le mieux eut été de corriger ce bug (facile à dire car c'est pas moi qui corrige cette partie). Je pense qu'il serait interressant quand GT aura ses deux jag qu'il fasse un petit essai de jag en réseau pour faire un code solide. Ok, ça ne servira pas dans notre cas, mais au moins être à l'origine d'un code propre peu d'une part être d'une utilité pour nos codes réseaux et d'autre part ce serait une p....n de fierté de le sortir !



PS : je sais pas si ce que j'ai écrit est compréhensible, j'ai trop peur de me relire.

C'est compréhensible pas de panique. Ensuite je comprends votre motivation, je suis prèt a faire les tests effectivement, mais je les ferais quand tous les autres projets en cours m'auront trop pris la tete, car se fixer que la dessus c'est une perte de temps a écrire un code qu'on aura très très peu de chance d'utiliser.



Entre nous sa fierté il peut la garder, cette fierté ne peut exister que grace aux autres, si personne ne lui accordait autant d'importance, il reviendrait pas avec son 'bug' !!, se reposer juste sur une chose on a vite fait de tomber.......



GT ;)

..could anyone give a short english recapitulation of what you people have come up with so far? ...Im just qurious... And preferable if anyone tested it in real life with code (and not just theory.... because in theory I have a good understanding of what causes the error.. but my experience shows that theory & practise dont realy mix).

Thanx!
/Sym

I haven't tested in real life even in theory, perhaps someone else like SCPCD or Zerosquare.



GT

Short about some uart related problems i know of:


Spock have been sitting quite some time with doom tryig to get the "$80 before packet" thing to work... but i think he gave up on that.. since something that simple did not work properly with the doom code... even though it should have worked! other parts of the doom code then became unstable and crashed.. ????!!!! (insert a steel bar into a card-house and expect it to be more robust?)..
So I think he agreed to start from scratch with the net code, not try to build it via doom.. (or that is what i would suggest to do..).

Personally i have 2 jaguars communicating via rs232 using the uart IRQ!!...
BUT!... as soon as there is an error in the transmission the uart IRQ hangs!... and it is impossible to recover it, except via a reset/poweroff...
If there are 1object on screen it works nice... 2 or 3 then the hang occures more often... totally unreliable...

I only use the 68K irq... perhapps i need to go into a gpu&dsp combination.. (my plan al long anyhow).


One thing i know though, is that the programmes that use the uart and get something out of it, use "manual polling" and not the irq. ....(cf Doom, aircars... ...not BS, they use either gpu or dsp... that im sure of).

Either there are some stupid problems in my IRQ handler (especially when an error occures) or the irq is unstable.... (or i would be able to clear error & reset it right?)...

Its tiresom to debug this sh-t since it takes two trail-n-error uploads each time...
And it was almost a year since I did any work on it... and it take allot of time, time i would rather "waste" on something else... (polygon).

Anyone else have any experience?

well, just a stupid question... some of us have an alpine... some have BS roms... or can make an image of them...
so, why not disassemble the receiving code, post it and see how it looks?
does anyone has started any work in that direction, or is it just a stupid idea?
do we lack disassembling tools?
does the cartidge encryption makes it a harder task?

(i'm sorry i can't access JS2 forums yet, so I didn't checked available information there, and well... this 10 posts barreer is somehow getting on my nerves... )

There is no stupid question here Stabylo I haven't BS Cartridges or rom, and you know what ? I haven't think to this idea before you give it


GT

Not a stupid idea, but certain people would get very angry with us, and it might even be illegal. Besides, I think we have the abilities to figure it out ourselves without having to copy someone else's code.

Reverse engineering is not illegal since you don't display it to the world. Giving the brute source-code is illegal, but you can give the principle of how to avoid the bug and produce the corresponding code.

Of course it is better to solve it by yourself

I'm not so sure about that with the side-effects and loopholes of the DMCA law in the United States. Several small companies got sued by their bigger competitors.

bon, avant de prouver que c'est du reverse-engineering ...
mais c'est peut être plus dur à faire que de réfléchir "from scratch"
et puis non, c'est pas dans l'esprit
en plus, on s'en fout, vu qu'on aura la JagCF avec un UART sans bug

Like AMD rev.engin. Intel.. and se what happened to AMD, they got sued & died did they not? .... =) *retorical question, dont answer *
There are legal ways to get around the law and avoid a lawsuit. (Haha... that sentence sums up the stupidity in legalsystems =) ..anyhow..

>but certain people would get very angry with us
That is true... since his "life work" would be public domain, every game from there on would have that feature, and that "unique" feature of their game would be lost...
I think this might be a major contributor as to why the "trick" of how to get it to work hasn't been revealed yet . That and the fact that there is no real UG-game out there that is "there yet"... meaning that perhapps he would help out with that part if we had a full flagged, good game out there, soon to be released...

BUT point beeing that There seem to be some horrible timing issues with it, and IF you ignore these from the beginning, and build your game dissregarding them, I would assume that if you later learned how to get the UART working (by some kind person) you would have to rebuild the hole code!...

So I mean if the will to help was there, atleast general hints on what Not to do, would be given to the public.. or atleast to the UG coders..
So I would assume theory1 holds untill prooven wrong (basic scientific prinsiple

>stabylo
No the cart encryption is not a problem as such.. (since the data on the cart is not encrypted).
But dissasembling any program is no easy task.. and we can be sertain that the data is packed to save space, which is a much bigger problem for a dissasembler. in worst case you need to run the dissassembler code of the orignal program to get it working properly.. which means hours of tracing through the code on the cart.. (avouding hangs)...

Added to the difficulty is the fact that the jaguar has 3 different processors... with atleast 2 different languages... (3 if you are harsh). making a dissass even more difficult.

Im not saying itis impossible Im just saying its not realy easy!... which means that we would better spend time on developing our own code... or atleast start with the higher protocalls.
Or instead of the obsession of hacking the code, spend time on writing an actuall game...

Though I know everyone loves a challange

cheers
/Sym

Well I just mentionned this possibility because I'm quite used to reverse engeneering (I did it for Indeo 3.2 video compression, which is more complicated than Cinepak). I now know that it's not illegal (at least here in France), because technology that relies on the secret of its internals can't be patented, as te process would be made public if it was patented (patent documents are always publicly available).

You're right, compression and multi language are factors that harden the task, but my experience in reverse engeneering is that it's quite usefull when you already has many hours of searching around your problem. Then it's not hard to look at the code for a specific sequence that identifies for sure any code related to your problem. I mean that's the second blade of the knife. Doesn't replace the real work

So, I'm not saying we have to start disassembling BS right now, just think about how this could help. Indeed if TB is ready to help a real project in need for his knowledge, then we shouldn't worry about it.

I just thought it would be bad that unsolved technical issues prevent some creative idea to be developed but sure we first need a game concept that would require networking, then think about how we can do it.

I didn't know that JagCF is to implement a new networking unit (shame on me!), that's good news to me! SPCD is a real master!

I confirm Stabylo is a real master at disassembling code and it is not a bad idea however to try to find the bug fix for the UART. I understood that lots of people would be more than happy if someone manages to recompile Doom with the UART bug fixed. But once again, maybe it is possible in this case to use the JagCF UART instead.

I would be interested in the source code from the UART that uses the IRQ are they somewhere?

serial port on jagcf.

This is something nice to have so we have a bug-free serial port, but I did buy all these jaglink, jaglink2 and catboxes and scatboxes and they will become useless I think the bug of the atari jaguar needs to be solved aswell...

Aircars has also a pretty good networking protocol, the best protocol has Battlesphere...

Let's continue the search for the jaguar uart fix...

If you guys, a whole community of programmers, cannot figure out what one man did on his own in a relatively short time and have to resort to downloading illegal ROMS, Disassembling and stealing his hard work because you guys aren't good enough to figure it out on your own then shame on all of you.

But we have people good enough to make a new hardware which will have no problem about it.

Hi !

Sorry about that, but I think that there is a misunderstanding.
All things said before was only a "and if we made this" and a global information about law of reverse engineering and not a real temptation to reverse engineering BS or AirCars for exemple to copy the serial protocol of these games.

We prefere all to find and create our own serial protocol to correct the Jaguar UART bug, but we haven't yet the time to search about that.
So that's why we said just crazy idea

Regards,
SCPCD.

You must know something, we will do that if we have enough time, now we can't loose time on working on a thing that nobody here will use, because the JagCF can do that without any errors.

Better writing games as loosing time for something old, see the future !!




GT Turbo

..desiding if I'm to be offended by that post or not... but... nahh... I dont take it personal since I dont have any reason to.

I just what to point out that there is NOTHING special about an old RS485 protical from early 80ies and i know of atleast a dusin people here that would be able to do that IF they had the chanse (equippment) and took the time to do it...
But instead Im playing New cd games for the jag.. released by coders here.... and that is actually better than having a protocall in my hand..


But I must agree that we should not abandon the idea of investigating the bug, nor the protocall solution just because there will be a new HW that has better UART.... we still need a good protocall even if the HW is "error free" to handel setup of multiplayers and sending the data around... (this is actually a verry simple problem if you start to think about it, and you dont need 10years to finish it!).

And also I would like people not owning a JagCF to be able to play future net games.. and hence it would have to work on a "standard jaguar UART device"...
thats my oppinion..

so keep investigating in any way you see fit! =)
cheers