Protocole réseau Lynx de type onewire : idées de conception... - Page 2

Même pour une table de 256 octets ?

Ben tu ne peux que de toute maniere avec les instruction de base, X et Y servent a indexer des tables, mais la ou ca coince c'est qu'il est preferable que la table soit aligné sur une page et les modes indexé sont un peu spaces

Oui, mais il n'y a qu'un octet à lire dans la table par octet d'entrée. Même si le code généré par le compilateur est "moche", je ne pense pas que ça ralentisse suffisamment pour que ce soit gênant.

Le probleme c'est que le 6502 est un peu bizzare sur les modes indexé XD

enfin indexer un table via un pointeur est compliqué, un table a une addresse mémoire statique est un peu plus simple

Zerosquare (./26) :
D'ailleurs à part si tu as plein de Lynx et de flash carts chez toi, il va sûrement y avoir besoin d'un prog sur PC pour simuler plusieurs Lynx .

@Vince : à l'AC, j'aurais 3 flashcards avec les Lynx associées (et les cables BLL - pas testés depuis des années), donc si tu veux faire des tests/debugger, on peut organiser ça

calculer un simple checksum au fil de l'eau sur des paquets courts de ce genre est suffisant, la probabilité que deux collisions successives ramènent le checksum a une valeur correcte est infime.

vince: pas de différence entre add et xor dans cet usage. et oui c'est l'émetteur qui l'envoie. il envoie la valeur qui va bien pour obtenir zéro si tu fais la somme (ou le xor) de tous les octets y compris ledit checksum.

si tes données sont dans packet[] avec une longueur L

alors checksum_xor = packet[0] xor packet[1] .... xor packet[L-1]
alors checksum_add = -(packet[0] + packet[1] ... + packet[L-1]) [ou - est le complément a deux]

tu l'envoies juste après. la protection est la même, xor est plus simple peut être.

A la réception tu recalcules le xor/add sur tout Y COMPRIS le checksum et tu dois obtenir zéro, pratique a tester avec un jz, le code généré devrait être plus simple.

puis tu décrémentes la longueur recue vu que le dernier octet est le checksum, et pas le message.

Il ne faut pas perdre de vue que s'il y a collision, tu ne récupéreras pas forcément une trame complète. Si deux consoles (ou plus) émettent en même temps de façon synchronisée, les données reçues seront un AND de tous les octets émis en même temps (exemple : si une console envoie $83 et une autre $56, on récupère $02). Mais si elles ne sont pas synchronisées, ça peut faire n'importe quoi, y compris changer le nombre d'octets reçus.

Tester qu'on reçoit bien ce qu'on a émis (octet identique et aucun bit d'erreur activé) me semble une bonne solution pour détecter les collisions. Le checksum peut servir aussi, parce que si tu as un réseau avec des câbles longs, beaucoup de consoles et une vitesse élevée, il se peut qu'il y ait une erreur de transmission de temps en temps.

Vu que c'est le même registre qui sert à l'émission et à la réception d'une part et que d'autre part on s'assure que le canal est silencieux avant d'émettre (et j'ajouterai un test pour être sûr qu'on est en attente d'un start du protocole) je trouve que le risque de collision est extrêmement limité. Avec un XOR on peut s'assurer la garantie "suffisante" pour le jeu...

Zero: Ah oui j'avais zappé ca. c'est la méthode i2c. ca devrait le faire aussi, mais vince semble parti sur une technique, on va le laisser avancer je crois