Diagnostic JVS : RS-485, SENSE, erreurs de trames et reprise (JVS-004)

D'abord localiser la panne, pas remplacer le PCB

Un échec JVS peut venir du bus électrique, de SENSE et des adresses, de la structure des paquets, des commandes ou de l'intégration du jeu. Une carte E/S qui répond à la commande 10 n'est pas automatiquement compatible avec les commandes de la borne.

Relever la dernière transition vérifiée : l'hôte a-t-il envoyé F0 ? SENSE annonçait-il un nœud sans adresse ? F1 a-t-il reçu un accusé valide ? Les commandes 11 à 14 ont-elles réussi ? Les interrogations régulières des commandes physiques fonctionnent-elles ?

Sauf attribution explicite à un tiers, toutes les trames d'exemple sont synthétiques; ce ne sont pas des captures effectuées à l'oscilloscope par Atelier Rocky.

Préparer une capture sans danger électrique

Identifier le système, la borne, la révision exacte du PCB E/S et ses domaines d'alimentation. Couper l'alimentation avant de modifier les câbles. Les prises JVS peuvent ressembler à l'USB sans être de l'USB. Employer des sondes compatibles avec les tensions et la masse du matériel; ne jamais raccorder au hasard la pince de masse d'un oscilloscope à un conducteur alimenté.

Observer de préférence le signal différentiel A−B, UART RX/TX côté logique avec référence correcte, DE, /RE si accessible et SENSE en analogique. Les désignations A/B varient selon les fabricants de transcepteurs : contrôler leur fiche technique.

Contrôler la terminaison hors tension en comprenant l'ensemble du bus. Mettre une résistance fixe sur tous les nœuds n'est pas une réparation universelle. Garder le point de mesure, les réglages et la fréquence d'échantillonnage dans le dossier.

Journaliser une transaction complète

Une trace exploitable indique l'hôte et le jeu, la référence de la carte, l'alimentation, les signaux de direction synchronisés, SENSE, les trames physiques encodées et les trames logiques vérifiées. Une simple capture du nom de la carte ne révèle pas l'origine d'une panne de découverte.

À 115200 bauds en 8N1, un caractère UART occupe environ 86,8 microsecondes (dix bits), avant les éventuels octets d'échappement. Cette durée de transmission ne représente pas le délai maximal accepté par tous les hôtes.

Étiqueter chaque trace : mesure de notre atelier, capture d'un tiers, résultat calculé à partir du firmware ou exemple synthétique. Les horodatages logiciels seuls ne démontrent pas la libération physique du bus.

HÔTE / JEU :   <nom et révision>
CARTE E/S :     <numéro PCB, firmware, ordre dans la chaîne>
MATÉRIEL :      <sondes, fréquence, polarité A/B, tension>
TEMPS :         <dernier bit hôte> <DE nœud actif> <première réponse>
SENSE :         <avant F0> <sans adresse> <après F1>
TX HÔTE :       <octets physiques bruts>
RX/TX NŒUD :    <octets physiques bruts>
DE / /RE :      <instants d'activation et de libération>
LOGIQUE :       <E0, adresse, LEN, données, SUM décodés>
VALIDATION :    <somme, longueur, destination, rapports>
RÉSULTAT :      <défaut reproductible et reprise observée>
PREUVE :        MESURE / TIERS / SOURCE / SYNTHÈSE

Référence saine : reset, adresse, puis interrogation

Sur un bus courant à un seul nœud, l'hôte diffuse F0 D9 sans attendre de réponse, puis F1 avec l'adresse 01; le nœud admissible doit normalement envoyer son accusé. Les identifications, versions et capacités viennent ensuite.

La séquence calculée ci-dessous suppose un nœud fictif annonçant la version 1.1 des commandes. Elle sert à comparer les champs de paquets, non à représenter la temporisation réelle d'une carte Sega, Taito ou Namco.

HÔTE -> TOUS    E0 FF 03 F0 D9 CB       reset F0 D9; pas de réponse
HÔTE -> NŒUD    E0 FF 03 F1 01 F4       F1 attribue 01
NŒUD -> HÔTE    E0 00 03 01 01 05       état 01, rapport 01
HÔTE -> NŒUD    E0 01 02 11 14          demander la révision
NŒUD -> HÔTE    E0 00 04 01 01 11 17    état 01, rapport 01, BCD 11

Trames calculées pour l'enseignement, pas des captures réelles.

Décoder LEN et échappements avant de condamner la trame

Chaque trame commence par SYNC E0. LEN compte les octets logiques après LEN, y compris la somme finale SUM. SUM est l'addition modulo 256 de l'adresse, LEN et des données décodées, sans le SYNC initial.

Après SYNC, E0 logique devient D0 DF et D0 logique devient D0 CF. Dans un corps contenant D0 E0, deux octets physiques supplémentaires apparaissent; la longueur logique ne change pas. Un D0 final sans octet suivant est un échappement incomplet, pas la preuve d'une commande inconnue.

L'exemple suivant est artificiel pour tester le décodeur, et ne représente pas une commande JVS valide à envoyer au matériel réel.

LOGIQUE : E0 01 03 D0 E0 B4
             |  |  |-----|  +-- SUM B4
             |  |  +-- octets artificiels D0, E0
             |  +----- LEN 03 : deux données + SUM
             +-------- destination 01

PHYSIQUE : E0 01 03 D0 CF D0 DF B4
                   D0 -> D0 CF
                   E0 -> D0 DF

01 + 03 + D0 + E0 = 01B4 hex => SUM B4
LEN logique reste 03.

Silence après F0 ou silence après F1 : deux diagnostics

Une remise à zéro F0 valide ne reçoit normalement pas d'accusé. Déclarer une panne pour ce seul silence est une erreur. En revanche, F1 provoque habituellement une réponse du nœud non adressé admissible.

Si F1 n'obtient pas de réponse complète, vérifier la commande, la condition SENSE, la prise de direction RS-485 et l'adresse interne avant de compter un nouveau nœud. Le firmware Sega SP5001-B exige que FF5A vaille FF avant d'accepter F1; la correspondance physique de deux autres bits de P7 reste partiellement inconnue.

Une carte déjà adressée ne doit pas s'attribuer l'adresse de la suivante. Un problème multicarte exige donc d'examiner SENSE dans la chaîne, et pas seulement les bonnes réponses de la première carte.

Une mauvaise somme n'indique pas une carte absente

Une réponse peut arriver au complet avec une somme de contrôle incorrecte. La réponse de version se terminant par 17 est valide; modifier uniquement ce dernier octet en 18 la rend incorrecte sans changer les autres champs. Le diagnostic doit distinguer BAD_CHECKSUM de NO_RESPONSE.

Avant d'accuser le câblage, vérifier le décodage des échappements et les limites du paquet. Si les erreurs se concentrent sur le premier octet de réponse, comparer les transitions DE de l'hôte et du nœud. Une mauvaise somme ne prouve pas à elle seule une collision électrique.

Ne jamais accepter une réponse partielle comme preuve de découverte réussie. Conserver les octets bruts et le résultat du calcul séparément.

VALIDE : E0 00 04 01 01 11 17
SUM = (00+04+01+01+11) & FF = 17

INVALIDE : E0 00 04 01 01 11 18
                                ^^ somme reçue 18
             somme calculée = 17

Classement : BAD_CHECKSUM, pas NO_RESPONSE.
Cette réponse corrompue n'a pas été envoyée à une vraie carte.

Différencier erreur de trame, état général et rapport

Une somme valide ne garantit pas qu'une réponse vise la bonne destination. Un paquet de réponse normal est destiné à l'hôte 00; un paquet adressé à 02 peut être arithmétiquement correct et néanmoins inacceptable. LEN égal à zéro ou des données tronquées indiquent aussi un problème de structure.

Le premier octet de données de réponse est l'état du paquet : habituellement 01 normal, 02 commande inconnue, 03 erreur de somme et 04 dépassement. Même avec l'état 01, chaque commande possède son rapport : 01 réussite, 02 paramètre incorrect, 03 erreur de paramètre de données ou 04 occupé.

Notre étude de Namco WAJVIO Ver2.04 établit différentes valeurs d'erreur internes pour ces cas. Les réduire toutes à « carte JVS débranchée » empêcherait un diagnostic utile.

SENSE exige une observation analogique

SENSE est un signal auxiliaire, distinct des données RS-485. Dans les réalisations courantes, on distingue une tension haute sans nœud admissible, une tension intermédiaire avant l'attribution et une tension basse après F1 réussi. Ces zones ne sont pas des seuils universels.

Sur notre Sega 838-13683-93 Rév.B étudiée, une branche passive à diodes et une branche active commandée par P7.2 produisent ces comportements. Le conducteur SENSE ne rejoint pas directement une broche logique du MCU. Une résistance qui produit la bonne tension sur un hôte peut ne pas convenir à un autre.

Pour plusieurs cartes en chaîne, mesurer SENSE avant et après chaque attribution. Une tension basse sur la première ne prouve pas que la carte suivante peut recevoir son adresse; les tensions doivent être mesurées par un instrument analogique approprié.

Changement de direction RS-485 : collisions au premier octet

Une transaction JVS classique est semi-duplex. L'hôte transmet la requête puis libère son émetteur; le nœud adressé active ensuite le sien. Si le nœud moderne répond avant que l'hôte ait libéré la paire, la contention peut abîmer le premier caractère ou faire disparaître la réponse.

Sur la Sega SP5001-B Rév.B, le signal P3.6 commande DE et /RE du SP485 : bas pour recevoir, haut pour transmettre. Le firmware attend la fin physique de la transmission UART avant de retourner en réception. Libérer DE dès que la FIFO est vide peut tronquer le dernier bit d'arrêt.

Notre calcul statique pour la requête combinée 20 02 02 + 21 02 donne 0,378147 à 0,384386 ms depuis la disponibilité du dernier octet reçu jusqu'à l'écriture du premier octet de réponse dans SCBUF. Cela n'inclut ni la transmission UART, ni la propagation physique. La garde de 200 µs retenue par un prototype moderne n'est pas une exigence générale JVS.

UART HÔTE :  [ requête ][ STOP final ].......................
DE HÔTE :    =====================0...........................
BUS JVS :    [ signaux de l'hôte ]...repos...[ signaux du nœud ]
DE NŒUD :    ............................1=============0......
UART NŒUD :  .............................[ réponse + STOP ]....
                           ^         ^                 ^
                           |         |                 |
                      libération  activation      libération
                       par hôte   par nœud        par nœud

Comparer : dernier STOP hôte, DE hôte inactif, DE nœud actif,
dernier STOP nœud et DE nœud inactif. Aucune durée n'est dessinée.

Les délais dépendent de l'hôte et du type de temporisation

Un hôte peut surveiller le délai avant le premier octet, l'intervalle de silence entre deux octets, la durée totale de réponse ou le budget d'une image vidéo. Ces limites ne sont pas interchangeables. Le temps de traitement calculé pour une carte originale n'est pas la tolérance d'un autre système.

Nos dossiers décrivent une fenêtre d'inactivité du système Chihiro d'environ 2,432 à 2,560 ms et, séparément, un temps CPU d'environ 0,236816 à 0,243056 ms pour une requête isolée de boutons sur Sega SP5001-B. Il s'agit d'observations et déductions portant sur des fonctions différentes.

Une version expérimentale peut injecter séparément un délai initial et un silence entre octets, mais ces essais restent proposés pour USB2JVS et ne constituent pas des résultats mesurés sur tous les hôtes. Ne pas activer ces retards dans le micrologiciel commercial.

Une anomalie Sega : délai prévu contre fonctionnement réel du parseur

Le micrologiciel SP5001-A/B initialise un compteur de deux intervalles, soit environ 20 ms prévus pour recevoir le paquet. Ce compteur devrait être diminué par Timer1. Pourtant, notre analyse des instructions et du fonctionnement du processeur montre que le parseur reste dans l'interruption de réception sans permettre d'autre interruption masquable : Timer1 ne peut donc pas faire avancer le compteur au moment voulu.

Le SP5001 sans suffixe utilise une architecture d'interruption longue et Timer3 avec le même problème conceptuel. Le SP5002-A emploie plutôt une interruption courte par octet et une machine d'états; Timer3 peut alors imposer le délai nominal d'environ 10 ms. La famille plus ancienne 315-6215 Type-1 avait déjà une approche par octet : il ne s'agit pas d'une simple évolution chronologique.

C'est une conclusion statique solide à partir du firmware et des règles du CPU, mais nous n'affirmons pas avoir reproduit physiquement un blocage permanent sur une carte commerciale. Une simple panne intermittente ne permet pas d'attribuer ce mécanisme sans vérification.

Erreurs Namco et procédure de reprise reproductible

Notre reconstruction Namco WAJVIO Ver2.04 distingue un compteur public de redémarrage du bus, un compteur de réponses manquées par nœud et un compteur d'occupation du moteur. Cette DLL considère un nœud défaillant après 64 échecs de réception consécutifs; un seul paquet perdu n'est pas nécessairement une erreur fatale. Ses codes internes -22, -23, -24 et -25 séparent délai expiré, mauvaise adresse, longueur nulle et somme invalide.

La reprise doit préserver l'étape précise qui a échoué. Après restauration des paramètres sûrs de liaison, laisser l'hôte suivre sa procédure normale de reset et de redécouverte, puis contrôler à nouveau les identités et capacités. Ne pas réutiliser d'anciens états de boutons comme s'ils étaient toujours actuels.

Ce guide n'affirme pas que les prototypes USB2JVS sont électriquement qualifiés, ni que ces comportements ont été mesurés sur tous les systèmes Sega, Namco ou Taito.

• Archiver hôte, version logicielle, PCB, firmware et configuration.
• Conserver destination, trames complètes, sommes calculées et rapports.
• Mesurer SENSE et la direction RS-485 si le premier octet manque.
• Séparer la mesure du délai initial et du silence entre octets.
• Commencer par un système à un nœud connu avant de tester les chaînes.
• Ne jamais annoncer une compatibilité réelle sur la seule base de tests synthétiques.

DÉBUT : hôte et carte identifiés, aucune intervention sous tension
   |
   +-- L'hôte transmet-il un signal RS-485 valide ?
   |       NON -> étudier alimentation, connecteur et émission hôte
   |       OUI
   v
   F0 visible ? -> observer SENSE; silence après F0 est normal
   |
   +-- F1 obtient-il un accusé valide ?
   |       NON -> SENSE, admissibilité, RX, temporisation DE
   |       OUI
   v
   ID / versions / capacités : LEN, SUM, état et rapports valides ?
   |       NON -> classer TRAME / ÉTAT / COMMANDE / ADRESSE
   |       OUI
   v
   Boutons/pièces : lectures conformes aux fonctions annoncées ?
   |       NON -> paramètres, câblage et exigences du jeu
   |       OUI -> référence saine; éprouver la reprise prudemment

Conserver séparément OCTETS PHYSIQUES et PAQUETS LOGIQUES.