Certains l'ont ptet vu passer, je joue un peu avec le port ComLynx de la console du même nom : topics/153397-adaptateur-comlynx-rs232

Outre l'utilisation d'un câble PC<=>Lynx, le petit programme de test des IRQ fonctionne quand on met plusieurs cartouches en "écoute" : topics/153397-adaptateur-comlynx-rs232/4#post-98

Maintenant, pour l'exploiter dans un jeu j'ai besoin de définir un protocole réseau.

Dans mon idée, j'aimerai avoir un système "communiste" (pas de maitre) et je dois donc réfléchir à deux choses :
1) L'annonce (pendant l'écran titre, où chaque console connectée peut venir se connecter sur le réseau)
2) Les échanges (par un protocole réseau à définir)

Les contraintes :
- C'est du onewire donc 1 seule console peut parler à la fois et tout le monde (elle y compris) entend ce qu'elle dit il faut donc gérer les risques de conflit, les attentes, et les éventuelles collisions
- Le matériel ne propose qu'un octet de buffer réception/émission, pour gérer plus, il faut implémenter un tampon
- C'est à coder en C K&R 8/16 bits avec une taille "limitée" (64ram au total, incluant buffer graphique etc...)
- Il faut que ça soit "résistant" aux défauts (si une console s'éteint/se débranche, ça serait bien de pas planter tlm)
- L'attribution des "ids" doit se faire pendant l'annonce, on part du principe qu'il n'y a pas de peristance pour stocker les adresses (et qu'aucun élément matériel n'est unique)
- Si une console n'arrive pas à chopper toute une trame faut qu'elle puisse l'ignorer


Donc en gros, je m'étais dit que j'allais faire des trames de taille fixe avec ent^te, émetteur, destinataire, type, donnée, fin de trame (avec éventuel checksum).

Mais mes cours de réseau industriels sont loins et je me disai que certains d'entre vous auraient probablement de meilleurs conseils à donner autant pour l'algo que son implémentation...
avatarWebmaster 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
Zerosquare a été invité sur ce sujet.

Ça me rappelle un certain projet.... grin

(Je te donne mes idées des que je suis devant un PC et pas sur mon téléphone)
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Godzil: le probleme c'est que le protocole TI ne gère pas le broadcast, donc faut bitbanger un protocole a la main (ils l'ont fait sur cemetech)


fais un truc genre HDLC (half duplex chais plus quoi)

un octet sépare les trames (en général 0x7E)

et la présence de 0x7E dans un paquet est échappée par 0x7D 0x5E

la présence d'escape est elle même escapée par 0x7D 0x5D

ca peut être géré au moment de l'envoi/réception d'un caractère.

L'avantage c'est que c'est auto-sychronisant contrairement a header/len/payload

si tu tombes au milieu, tu jettes tous les octets jusqu'a recevoir 7E et paf t'as le début de la trame. La longueur devient également implicite.

Le dernier octet transmis peut être un checksum

en gros
enum {packet_pending, packet_done, protocol_error}
enum {waitsync,start,receiving,escape}
char state
char checksum
void receive(char input)
si state == waitsync:
  si input = 7E : start->state
  else: return

si state == start:
  si input != 7E : receiving->state, INIT_VALUE->checksum goto rx
  else: return packet_pending

rx:
si state == receiving:
  si input = 7D: escape ->state
  si input = 7E: if CHECKSUM_OK: return packet_done else: return protocol_error
  sinon: if len<maxlen: input->buf[len++], UPDATE_CHECKSUM, else: rx overflow

si state == escape:
  receiving->state
  if input == 5E or 5D: input == input xor 0x20, if len<maxlen: input->buf[len++], UPDATE_CHECKSUM, else: rx overflow
  else: waitsync->state, return protocol_error

Déja utilisé des tonnes de fois ici.

chaque station écoute tout, donc un seul peut effectivement parler a la fois.
la dedans tu peux définir que le premier octet est l'adresse de la machine (par ex 00h = broadcast) comme ca tu peux adresser un paquet a une seule machine.

l'émission est triviale, je te la laisse en exercice.

autre avantage, le buffer n'a besoin que de stocker la payload, mais les octets de départ/escape ne le sont jamais.

je te laissse digérer grin
Je n'ai jamais parle du protocol TI (ni meme pensé a ca) o_O
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
squalyl (./3) :
Godzil: le probleme c'est que le protocole TI ne gère pas le broadcast, donc faut bitbanger un protocole a la main (ils l'ont fait sur cemetech)


fais un truc genre HDLC (half duplex chais plus quoi)

un octet sépare les trames (en général 0x7E)

et la présence de 0x7E dans un paquet est échappée par 0x7D 0x5E

la présence d'escape est elle même escapée par 0x7D 0x5D

ca peut être géré au moment de l'envoi/réception d'un caractère.

L'avantage c'est que c'est auto-sychronisant contrairement a header/len/payload

si tu tombes au milieu, tu jettes tous les octets jusqu'a recevoir 7E et paf t'as le début de la trame. La longueur devient également implicite.

Le dernier octet transmis peut être un checksum

en gros
enum {packet_pending, packet_done, protocol_error}
enum {waitsync,start,receiving,escape}
char state
char checksum
void receive(char input)
si state == waitsync:
  si input = 7E : start->state
  else: return

si state == start:
  si input != 7E : receiving->state, INIT_VALUE->checksum goto rx
  else: return packet_pending

rx:
si state == receiving:
  si input = 7D: escape ->state
  si input = 7E: if CHECKSUM_OK: return packet_done else: return protocol_error
  sinon: if len<maxlen: input->buf[len++], UPDATE_CHECKSUM, else: rx overflow

si state == escape:
  receiving->state
  if input == 5E or 5D: input == input xor 0x20, if len<maxlen: input->buf[len++], UPDATE_CHECKSUM, else: rx overflow
  else: waitsync->state, return protocol_error

Déja utilisé des tonnes de fois ici.

chaque station écoute tout, donc un seul peut effectivement parler a la fois.
la dedans tu peux définir que le premier octet est l'adresse de la machine (par ex 00h = broadcast) comme ca tu peux adresser un paquet a une seule machine.

l'émission est triviale, je te la laisse en exercice.

autre avantage, le buffer n'a besoin que de stocker la payload, mais les octets de départ/escape ne le sont jamais.

je te laissse digérer grin
Merci, mais pour le coup, ton code est géré dans l'interruption directement ? T'as pas de buffer ? Pourquoi 7D ? pourquoi pas FF ?
avatarWebmaster 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
yep dans l'irq
ca a l'air touffu mais le code execute a chaque byte est tres court. qq conditions et un stockage éventuel.

faut un buffer ouais, mais juste pour recevoir la trame transmise.

7E/7D parce que RFC 1662 l'a inventé et que ca sert a rien de réinventer la roue et que ca peut aider a trouver des softs touts faits ou pour tester sur pc.
Ceci dit le probleme, si je ne m'abuse c'est que ta solution requière qu'on puisse parler et ecouter en meme temps, je ne suis pas sur que tu puisse sur la Lynx, ni meme faire du bitbang, elle parle le RS232 avec tout ce que ca incombe.. (bit de start, de stop, parité, etc..)

Il est probablement préférable d'avoir un systeme a la token ring, ou chaque appareil parle a tour de role.

Un moyen de donner un ID de maniere dynamique et d'ecouter la chaine de messages et de determiner le numero max, ajouter un temps aleatoire qui est compté en nombre de boucle, prevoir que le nombre soit assez grand pour eviter des collisions, et prevoir un leger delais a la fin de la chaine pour laisser un appareil qui veux s'ajouter avoir le temps de parler.

L'idee est:

On ecoute une boucle, et l'ID Max est X, on choisis donc X+1 comme ID, et on tire Y comme nombre de tour a attendre.
On ecoute pendant Y tours si l'ID Max ne change pas

Si il ne change pas au tour Y+1 quand on arrive a la fin on se presente (incluant un nombre aleatoire Z)
Si l'ID max change on fait X+1 et Y+1 et on continue jusqu'a ce qu'on atteinds la valeur de Y et que X n'a pas change.

Une fois qu'on a emis le prochain tour, les autres, au moins un, est sense repondre un message de bienvenue, incluant la valeur Z, si collision ou autre Z ne correspondra pas donc on repart pour au debut pour regenerer X, Y et Z.
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
la solution de qui? la mienne? celle de vince?

le token ring moais bof vaut mieux parler quand on a qc a dire, ca marche bien

le port de la lynx avec son rx et tx connectes ensemble ressemble beaucoup beaucoup a un canal radio partagé.

du coup checksum obligatoire en cas de collision

pour la rfc le broadcast est ff pas 0, mé souis planté
avatarWebmaster 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
L'avantage du TR c'est que c'est déterministe, et peu ou prou de risque de collision, la si tout le monde peu parler en même temps le risque de collision est énorme, et, a moins que je me trompe, Vince en parle dans le contexte d'un jeu, donc quelque chose de synchrone, donc chaque échange doit se faire dans un temps donné, donc il vaux mieux parler en n'ayant rien a dire que de parler que quand on a quelque chose a dire, de toute manière dans un jeu, on auras toujours quelque chose a dire.

Les collision sont un probleme recurent avec l'ethernet, et c'est un sujet sensible qu'il faut eviter au maximum, car ca fait fortement chutter le debit, car on est oblige d'attendre un temps (aleatoire) avant de pouvoir reparler, dans le cadre ou ta vitesse de transmission est celle qui determine le temps alloué par boucle dans ton moteur, c'est important que celui-ci soit maitrisé
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
alors qu'en token ring comment t'évites les collisions? chacun réémet la trame apres avoir recu si elle est pas pour lui?

mais dans ce cas, la même trame est réémise autant de fois qu'il y a de client? spas tres efficace a bas debit non? Puis ca risque de lagger un peu aussi non? chais pas, je connais pas ce protocole.
Le token ring n'est pas du tout adapté à une situation où tout le monde est connecté sur le même média... (pour se faire une idée c'est comme comparer une carte réseau avec un port BNC et une carte avec un DB15 IN et un DB15 out : physiquement c'est pas la même approche)
avatarWebmaster 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
J'ai dit token ring pour "chacun parle a son tour" en sequence, pas pour implementer un vrai reseau token ring smile

Le nom est peut etre mal choisis desole, l'idee est juste comme je dit que chaque "client" parle en sequence, ID1, puis ID2, puis ID3, puis ID4, ... IDX, puis ID1, ID2, ...
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Squalyl > non, Godzil parlait d'un autre vaporware non public tongue

Godzil > C'est du TDMA que tu décris smile

TDMA (comme les téléphones GSM)
Avantages : totalement déterministe (jamais de collisions, bande passante garantie).
Inconvénients : supporte mal les changements de topologie réseau (soit l'une des consoles est maître et c'est le bazar si elle se déconnecte, soit il faut un système auto-organisé et ça semble compliqué), gaspillage de bande passante

Autres possibilités que je vois :

- un système à collisions "synchronisées" avec priorités (comme le CAN)
Avantages : supporte bien les changements de topologie, déterminisme correct, utilisation raisonnable de la bande passante
Inconvénients : pas possible de faire de l'arbitrage au niveau du bit sur la Lynx (pas supporté par le hardware) -> à faire au niveau de l'octet, voir si la synchronisation est faisable (utilisation timer et CPU)

- un système à collisions "non synchronisées" (comme l'Ethernet sur un hub)
Avantages : le plus robuste face aux perturbations de tous types
Inconvénients : non déterministe, bande passante non garantie

Les ressources hardware dispo (CPU, timers) vont jouer, le type de jeu potentiellement également : s'il faut juste envoyer les appuis de touche d'un joueur, le système à collisions non synchronisées devrait faire l'affaire ; s'il y a beaucoup de données à transférer avec une latence à respecter, c'est différent.

Comme dit plus haut, il faudrait regarder ce qui existe déjà ; les cours de réseau sont loin pour moi aussi, mais le problème est classique, donc il doit déjà y avoir des solutions bien étudiées.
avatarZeroblog

« 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
En effet, ca pourrait etre comparable a du TDMA.

Tout depends du type de jeu, mais il n'y a pas forcement de gaspillage de bande passante, ni de difficulté pour l'auto organisation, certains type de jeu, on de toute maniere besoin d'un maitre, mais pour certains on peu s'en passer du moment que chaque consoles/ordi/autre utilise le meme algo de random avec le meme seed, sinon en effet, on risque d'avoir des mauvaises surprises (meme alogo == avec la meme graine on a la meme chaine)
Chaque objet a tour de role explique ce qu'il (a) fait pendant son tour, et les autres mettent a jour suivant ces infos.

Encore une fois tout dépend du type de jeu mais il est relativement courant pour des jeux en reseau de fonctionner dans un tel mode, sauf que pour l'ethernet/TCP/IP la on a vraiment du gaspillage de BP parcequ'il faut envoyer la meme information a tout le monde, soit en direct (chaque machine envois a tous les clients) soit au client maitre qui redistribue a tout le monde, la avec un tel bus, on a l'avantage que tout le monde ecoute en meme temps, donc les données ne sont a transmetre qu'une seule fois. (prévoir un codage type hamming pour eviter les erreur de synchro/lecture..)

Pour moi le point faible est la fiabilité des infos recus, il est un peu plus compliqué d'indiquer qu'un packet est foireux, enfin il y a bien certains moyens, mais ca complexifie la chose.

Honnêtement il y a peu de jeux qui ne doivent pas se synchroniser sur une base de temps précise, meme les FPS marchent comme ca.

Juste envoyer les appuis sur les touches, au bout d'un moment tu risque d'être complètement désynchronisé avec les autres joueurs, donc a pars un tetris, ou tu donne juste une idée de la table chez toi (ca peux juste être le niveau et et si une des machins méchants sont a envoyer a l'autre) mais meme la, quand je m'était amusé avec le Tetris Wonderswan, le jeu passe son temps a faire des ping/pong très régulièrement, il y a droit a une certaine latence, mais elle est courte avant que le jeu balance un "connection error" et les échanges on lieu meme si il n'y a rien a dire.

Il ya probablement plein de type de jeu auquel je ne pense pas et qui peuvent marcher en mode async, mais la je ne vois pas..
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Godzil (./16) :
pour l'ethernet/TCP/IP la on a vraiment du gaspillage de BP parcequ'il faut envoyer la meme information a tout le monde, soit en direct (chaque machine envois a tous les clients) soit au client maitre qui redistribue a tout le monde
Ethernet et TCP/IP supportent le multicast/broadcast, c'est sur Internet que ça pose problème (malheureusement).

Godzil (./16) :
Pour moi le point faible est la fiabilité des infos recus, il est un peu plus compliqué d'indiquer qu'un packet est foireux, enfin il y a bien certains moyens, mais ca complexifie la chose.
Comme tu dis, les codes correcteurs d'erreur sont faits pour ça, je pense pas que ça pose un vrai problème sur un lien local qui fait quelques mètres au total. La synchro et l'éventuelle gestion des collisions me semble plus complexes.

Godzil (./16) :
Il ya probablement plein de type de jeu auquel je ne pense pas et qui peuvent marcher en mode async, mais la je ne vois pas..
Tu as pourtant pas mal de jeux en ligne qui fonctionnent comme ça, vu que ça fait économiser beaucoup de bande passante et permet de tolérer la latence.
Mais c'est vrai qu'éviter les désynchros n'est pas simple. Sur PC par exemple c'est un vrai sujet, notamment parce qu'il y a plein de différences possibles entre les machines (un CPU Intel et un CPU AMD ne donnent pas exactement les mêmes résultats pour les calculs en virgule flottante, par exemple), et énormément de machins asynchrones qui tournent en parallèle. Sur la Lynx c'est beaucoup plus simple, mais il y a des choses qui restent asynchrones (par exemple, deux machines n'auront pas forcément le même nombre de VSYNC entre deux trames).

Pour ce qui est des méthodes d'accès, ce lien est pas inintéressant :
https://en.wikipedia.org/wiki/Channel_access_method
avatarZeroblog

« 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
Tu as des exemples de jeux marchant comme ca parce que la littérature que j'ai lu me semble indiquer l'inverse que c'est plutot au début qu'il n'envoyais que les échanges de movement fait par le joueur avant de se rendre compte que ca ne marche pas si bien que ca.

Je ne dit pas "c'est faux" c'est juste que ca contredit ce que j'ai lu ces dernières années, apres mes sources ne sont pas forcement les plus fiables non plus, je loin d'etre expert dans le domaine, mes propositions sont plutot un mix entre mon intuition et ce que j'ai lu plus qu'autre chose.
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Zerosquare (./15) :
TDMA (comme les téléphones GSM)
Avantages : totalement déterministe (jamais de collisions, bande passante garantie).
Inconvénients : supporte mal les changements de topologie réseau (soit l'une des consoles est maître et c'est le bazar si elle se déconnecte, soit il faut un système auto-organisé et ça semble compliqué), gaspillage de bande passante
Un système auto-organisé n'est pas si compliqué. Il existe le STDMA pour ça. Il n'y a que la base de temps qui pourrait poser problème, mais ça peut se régler en choisissant une base aléatoire pour le premier utilisateur et les autres s'alignent sur les intervalles des utilisateurs déjà présents.

Par contre, en effet, ce n'est pas forcément optimal du point de vue du partage du support. Il faudrait savoir si un débit fixe est nécessaire par utilisateur ou si les communications se font par paquets de données à un rythme non uniforme dans le temps.
avatar
Le niveau technique est un peu au dessus de mon domaine de confort mais à défaut d'une solution unique et idéale ne serait-il pas envisageable de proposer deux (ou plus) types de réseaux qui seraient adaptées en fonction du jeu?
- un type de réseau qui ne supporte pas le changement de topologie mais offre tous les autres avantages en terme de garantie de bande passante, latence & co > pourrait être adapté à des jeux longs par équipe où le nombre de joueur reste inchangé durant une partie
- un autre type qui sacrifierait certains critères comme la bande passante au profit d'une souplesse de topologie > idéal pour les mini jeux ou des jeux du type poker & co où les parties sont longues et peuvent se continuer même après changement du nombre de joueur (défaite d'un joueur ou arrivé d'un nouveau venu)

La lib réseau fournirait donc à un soft le choix dans le type de communication qu'il souhaite entreprendre.

#mytwocents
avatar"If you see strict DRM and copy protection that threatens the preservation of history, fight it: copy the work, keep it safe, and eventually share it so it never disappears. [...] no one living 500 years from now will judge your infringing deeds harshly when they can load up an ancient program and see it for themselves."

Benj Edwards - Why History Needs Software Piracy

- - -
Achat ou échange: topic de mes recherches
Godzil > j'ai peut-être pas été clair : je doute qu'il y ait des jeux modernes qui fonctionnent avec juste l'envoi des entrées utilisateur. Ce que je veux dire, c'est que beaucoup de jeux ne fonctionnent pas en synchronisation "dure", ils ne transmettent que des états partiels périodiquement, et garantissent la synchro à long terme par le déterminisme du moteur de jeu + des algos de resynchronisation.

Par exemple :
http://www.gamasutra.com/view/feature/3374/the_internet_sucks_or_what_i_.php
http://www.gamasutra.com/view/feature/131466/instant_replay_building_a_game_.php (ça parle des replays, mais la problématique est commune)
http://www.gamasutra.com/view/feature/173977/scaling_a_physics_engine_to_.php

RHJPP > oui y'a pas mal d'approches intéressantes, mais il ne faut pas perdre de vue que la Lynx n'a qu'une simple UART, quelques (ou un seul ? je sais plus) timers, et un CPU assez modeste qui doit s'occuper de plein d'autres choses. Du coup certains procédés qui nécessitent du matériel pensé pour ne seront peut-être pas faisables.

Jonas > c'est pas bête, mais avant de faire plusieurs protocoles, commençons déjà par en faire un seul hehe
avatarZeroblog

« 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
Zerosquare (./21) :
RHJPP > oui y'a pas mal d'approches intéressantes, mais il ne faut pas perdre de vue que la Lynx n'a qu'une simple UART, quelques (ou un seul ? je sais plus) timers, et un CPU assez modeste qui doit s'occuper de plein d'autres choses. Du coup certains procédés qui nécessitent du matériel pensé pour ne seront peut-être pas faisables.
Pour être précis, il y a 8 timers sur la lynx. Mais on ne peut en faire tout ce qu'on veut vu que par exemple le 4 est lié à la communication série, y'en a un qui est commun avec la lecture sur le port cartouche et deux autres qui sont chainés pour le rafraichissement de l'écran...
avatarWebmaster 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
(bon, c'est un "brouillon", j'ai pas de quoi tester sous la main donc c'est pour commencer à réfléchir au truc...)


const waitsync 1
const start 2
const receiving 3
const escape 4
const done 5
unsigned char state;
unsigned char buf[255];
unsigned char position;

void SER(){
  unsigned char input;

  DisableIRQ(4);
  POKE(0x10,0xFD80);
  input=serdat;
  EnableIRQ(4);
  if (state==waitsync){
    if(input==0x7e){
      state=start;
    }else{
      return();
    }
  }
  if (state==start){
    if(input!=0x7e){
      state=receiving;
    }else{
      return();
    }
  }
  if (state==receiving){
    if(input==0x7d) {
      state=escape;
    }
    if(input==0x7e) {
      state=done;
      return();
    }else{
      if(position<255){
        buf[position++]=input;
      }
    }
  }
  if (state==escape){
    state=receiving;
    if(input==0x5E || input==0x5D){
      input=input xor 0x20;
    }
    if(position<255){
      buf[position++]=input;
    }
  }
}

Derrière, je vois bien le tableau "buf" coupé en lignes, une par device

Ainsi, n'importe quel device peut "parler" pour dire le contenu de sa ligne par un envoi de 7E, ID, DATA, 7E (avec désactivation temporaire de l'IRQ réception)

Un "timer" dit à chaque console d'envoyer sa ligne toutes les X ms (si le canal est libre) ainsi tlm dispose du tableau à jour.

Avec le jeu de interruptions, la mise à jour du tableau tourne toute seule, le jeu peu donc taper dedans quand il veut, le même code fonctionne donc pour tout le monde.

Il reste le problème de l'annonce et l'attribution des numéros de device : je vois bien un envoi toutes les X ms d'un numéro. au début on écoute pendant X+1ms, si on entend rien, on prend le numéro 1, sinon on prend le numéro N+1 et on se met à donner son numéro en boucle toutes les X ms. Si une console envoie 0xFF alors c'est que la synchro est finie (qqn a appuyé sur start).
avatarWebmaster 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
Si j'ai bien compris, chaque console utilise son timer interne pour savoir quand émettre ? Si oui, comment tu gères les collisions ? (un timer périodique "brut" ne suffit pas : tu as toujours des petites différences de fréquence entre deux quartz, donc si tu ne fais rien, les décalages vont s'accumuler jusqu'à ce que les intervalles de deux consoles finissent par se chevaucher)
avatarZeroblog

« 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
Bon, c'est "crade" mais ça marche :

#define waitsync 1
#define start 2
#define receiving 3
#define escape 4
#define done 5
#define init_value 0
#define packet_pending 9
#define packet_done 10
unsigned char state;
unsigned char buf[255];
unsigned char position;
unsigned char checksum;


SER(){
  unsigned char input;

  DisableIRQ(4);
  POKE(0x10,0xFD80);
  input=serdat;


  if (state==waitsync){
    if(input==0x7e){
      state=start;
    }else{
      return 0;
    }
  }
  
  if (state==start){
    if(input!=0x7e){
      state=receiving;
      position=0;
      //checksum=init_value;
      //goto rx ?
    }else{
      //return 0;//packet waiting
    }
  }
  
  //rx: ?
  if (state==receiving){
    if(input==0x7d) {
      state=escape;
      return 0;
    }
    if(input==0x7e) {
    	/*if (checksum==0){
    		return();//packet done
    	}else{
    		return();//cheksum error
    	}*/
      //state=done;
      state=start;
      return 0;
    }else{
      if(position<255){
        buf[position++]=input;
        //update checksum
      }else{
      	return 0;//overflow
      }
    }
  }
  if (state==escape){
    state=receiving;
    if(input==0x5E || input==0x5D){
      input=input^0x20;
    }
    if(position<255){
      buf[position++]=input;
    }else{
    	return 0;//overflow
    }
  }

  EnableIRQ(4);

}

Conctrètement, j'ai fait un programme test :
un boucle while qui fait y++
on met buf[0] dans x
un carré est affiché à x, y
si on appuie une touche, on envoie 0x7e, y, 0x7e

quand les deux consoles démarrent, le carré reste collé à gauche, dès que l'une appuie sur une touche, le carré de la console réceptrice s'aligne en x avec la position y de la console émettrice

et pour tester les collisions : si on maintient appuyé les deux consoles, on a bien les deux carrés qui se déplacent en diagonale.

il n'y a pas de checksum pour le moment et je ne suis pas sûr que pour un truc à 2 consoles ça serve à qqch...

par contre j'ai trouvé un soucis : mes prises microjack ne font pas toujours contact avec la console :/
avatarWebmaster 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
vince (./25) :
et pour tester les collisions : si on maintient appuyé les deux consoles, on a bien les deux carrés qui se déplacent en diagonale.
Malheureusement ça ne prouve pas grand-chose : avec seulement deux consoles, des messages courts et une faible durée de test, tu peux ne pas avoir de collisions juste par coup de pot...

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 (de préférence avec un vrai port série intégré, parce qu'à travers l'USB ça rajoute une latence imprévisible, donc si ton protocole a des timings précis ça casse tout).
avatarZeroblog

« 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
je t'ai dit: le checksum sert a détecter les collisions.
squalyl (./27) :
je t'ai dit: le checksum sert a détecter les collisions.
donc c'est à l'émetteur de le fournir en plus des données ? quel est le plus "robuste", l'addition ou le xor (ou autre opération logique mais en restant dans des solutions qui bouffent pas trop de cycles) ?
avatarWebmaster 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
Ça c'est pas mal (la version à base de table, ça consomme 256 octets de ROM mais c'est rapide, et meilleur que l'addition ou le XOR) :
http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html

PS : avec la Lynx on reçoit chaque octet émis, s'il y a une différence (ou que l'octet n'a pas été reçu au bout d'un délai, mais c'est plus chiant à gérer) ça veut dire qu'une collision s'est produite.
avatarZeroblog

« 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
mais le 6502 et les tables c'est pas jouasse jouasse :/
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o