1

Le sujet BJL help est fermé, alors j'ouvre ce nouveau sujet. Chez moi le chargement BJL c'est dur dur, et je suis toujours surpris en lisant vos posts : on dirait que vous n'avez jamais aucun souci ! eek Pourtant ma hotline privée (merciiii Seb!!wink) m'a souffé que pour vous aussi la vie n'est pas simple avec le BJL.

D'où mes deux questions :
- quelqu'un a-t-il déjà fait un bilan des difficultés possibles (checksum, interférences, loader foireux, pb sur certaines plateformes, etc) pluie ?
- quelqu'un a-t-il déjà fait une compilation des solutions possibles sun ?

Si jamais rien de tout ça n'a été fait, j'aimerais bien que chacun expose son installation (selon les thèmes: type de fabrication du câble, longueur du cordon, puissance machine hôte, OS hôte, version du progamme d'upload) et nous explique comment ça se passe chez lui (quelles limites de taille pour l'upload, quelles restrictions sur l'usage de la machine, quelles astuces pour améliorer le chargement). D'ailleurs je commence de ce pas. smile

Mon installation :
- fabrication du câble: freddifreddo, montage très pro, très propre
- longueur du cordon: 1m ou un peu plus (freddifreddo tu confirmes?)
- puissance machine hôte: Athlon 1GHz FSB 100MHz
- OS hôte: win2k ou linux sous vmware
- version du progamme d'upload: lo d'origine sous linux, lo.exe d'origine, lo.exe modifié par ZeroSquare

Comment ça se passe :
- limites de taille: 50ko ça peut aller, 100-150ko il faut essayer 10-15 fois, 500ko impossible après 30 essais
- restrictions côté hôte: le code de ZeroSquare marche bien mieux que les autres, il vaut mieux lui donner 100% du processeur (et il les prend!!)
- astuces pour améliorer le chargement: oublier les version du lo d'origine, donner tout le temps processeur, stopper net tout téléchargement qui ne fait pas immédiatement "bouger" les couleurs sur l'écran de la jag

Avez-vous connu d'autres situations? Avez-vous trouvé d'autres astuces?


Autre interrogation: je n'ai pas regardé le code d'upload du BJL, mais je me demande pourquoi il y a tant de problèmes de qualité de transfert. triso Pourquoi n'y a-t-il pas des checksums sur des petits paquets (et pas sur l'ensemble!), avec réexpédition des paquets erronnés?
Stabylo/The Removers
http://removers.atari.org/

2

mes câbles font 1m75 environ
limites de taille: 50ko ça peut aller, 100-150ko il faut essayer 10-15 fois, 500ko impossible après 30 essais


Problème connu smile ! c'est que ton port // n'est pas bien configuré là tu dois être en mode EPP/ECP
On peut en effet chargé des mini fichiers et dès qu'on dépasse environ 128 ko ça ne marche jamais !

Atari Jaguar :
http://perso.orange.fr/jaguar-64bit/

! Jagware !

3

-

4

-

5

Fredifredo :
Problème connu smile ! c'est que ton port // n'est pas bien configuré là tu dois être en mode EPP/ECP
On peut en effet chargé des mini fichiers et dès qu'on dépasse environ 128 ko ça ne marche jamais !

Ah, il faut passer en EPP/ECP... C'est bien dans le BIOS que ça se règle ou c'est ailleurs ?
Et après ça marche vraiment pour n'importe quelle taille d'upload ?
Stabylo/The Removers
http://removers.atari.org/

6

non justement il ne faut pas être en EPP / ECP !!!!! non
Atari Jaguar :
http://perso.orange.fr/jaguar-64bit/

! Jagware !

7

Moi c'est soit mon MegaSTe soit mon PC portable en utilisant le prog de Zerosquare.

Il y a toutes les explications sur JagWare. (faut retrouver où, mais je pense que Zero nous le retrouvera facilement tongue)
avatar

8

stabylo :
C'est bien dans le BIOS que ça se règle ou c'est ailleurs ?
Oui c'est bien là.

Orion_ :
ensuite il vaux mieux que je coupe msn ou autre parceque sinon mes transfers ne passe pas :/
Effectivement, il vaut mieux dégager le maximum de programmes tournant en arrière-plan. Je pense que c'est dû aux timeouts intégrés (voir plus bas), si l'OS passe la main à un autre programme à un mauvais moment, et que ça dure trop longtemps. J'avais commencé à coder une solution (en faisant un driver, parce que je pense que c'est le seul moyen d'avoir un contrôle suffisamment précis du hardware et des timings), mais je n'ai pas continué suite au lancement du projet Catnip (oui oui, il arrive, mais il y a plein de détails d'organisation casse-pieds à régler avant tongue )

stabylo :
Autre interrogation: je n'ai pas regardé le code d'upload du BJL, mais je me demande pourquoi il y a tant de problèmes de qualité de transfert.
Si tu regardes le code d'upload, tu ne verras rien de très spécial, il devrait théoriquement fonctionner sans problèmes (il y a même du contrôle de flux de prévu pour que la vitesse s'adapte automatiquement à la machine la moins rapide).

J'ai déjà tenté des transferts BJL entre 2 PCs (avec un soft fait maison pour imiter le comportement de la Jag en réception), et ça marche beaucoup mieux. De même il me semble que FalcXfer d'Orion_ utilise un protocole similaire au BJL, et il n'a pas de problèmes non plus.

Je crois par conséquent que le problème vient de l'implémentation côté Jag. D'après les tests que j'ai fait, ça ne marche pas si on envoie les données trop rapidement (même en respectant le contrôle de flux), ou trop lentement (le protocole fonctionne par "blocs" de 32 bits, et il semble y avoir un timeout sur la durée de l'émission d'un bloc ; par contre, apparemment il n'y en a pas pour l'attente entre deux blocs).

Je ne sais pas exactement pourquoi ça ne fonctionne pas quand on envoie trop vite, mais je pense que ça tient au moins en partie au fait que le BJL utilise des entrées prévues pour des pads, qui doivent donc contenir des anti-rebonds en logique interne (vu qu'il n'y en a ni dans les manettes, ni dans le hardware de la Jag, ni dans les softs, à ma connaissance). Peut-être aussi qu'il y a des bugs dans la ROM BJL ?

stabylo :
Pourquoi n'y a-t-il pas des checksums sur des petits paquets (et pas sur l'ensemble!), avec réexpédition des paquets erronnés?
Pour ça, faut demander à Bastian Schick et ses copains...

Je crois surtout que Bastian a essentiellement développé sur Atari, où il est beaucoup plus facile d'obtenir des timings reproductibles, que sur PC avec un OS multitâches non temps-réel. Il n'a donc peut-être jamais constaté de problèmes.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

9

SCPCD :
Il y a toutes les explications sur JagWare. (faut retrouver où, mais je pense que Zero nous le retrouvera facilement tongue.gif )
Je pense que tu parles de ce topic ?

avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

10

voila c'est celui là smile
avatar

11

Fredifredo :
non justement il ne faut pas être en EPP / ECP !!!!! non

Argh! j'étais justement en mode normal! confus je viens d'essayer en mode ECC/EPP et effectivement c'est binaire : <128k ça passe, et >128k ça passe pas.

J'ai aussi la possibilité d'être ECC tout seul ou EPP tout seul, mais vu les résultats de tes tests retranscrits sur JagWare, je vais pas essayer mourn Bon, je vais lire un peu le thread sur JagWare... Mais on dirait que le seul salut, c'est soit coder avec ProjectTempest, soit uploader depuis un atari tongue

Edit: en vérifiant dans le gestionnaire de périphs, mon port parallèle n'utilise ni interruption, ni le plug n play...
Stabylo/The Removers
http://removers.atari.org/

12

stabylo :
soit uploader depuis un atari tongue



SCPCD et moi meme te dirons pas le contraire wink



GT Sur Atari top
avatar
Accrochez vous ca va être Cerebral !!

13

moi, je suis en mode bidirectionnel et ça marche à peu près