30

mais le 6502 et les tables c'est pas jouasse jouasse :/
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

31

Même pour une table de 256 octets ?
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

32

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
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

33

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.
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

34

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
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

35

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
avatar
De nouveaux jeux pour vos vieilles consoles ? En 2024 ?
https://yastuna-games.com

36

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.

37

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.
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

38

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...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

39

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 smile