Rev-eng Décodeur Dolby SR-D - Page 1

En ce moment j'ai une nouvelle lubie, sans rapport avec les jeux vidéo pour changer !
Je veux mettre à poil le matos qui a permit pendant pratiquement 20 ans d'avoir plus de 2 canaux audio dans les cinémas.

Pour résumer le (vaste) sujet:

Vers 1994, Dolby ont eu l'idée d'encoder jusqu'à 6 canaux audio en AC-3 et d'intégrer le flux de données sous forme de petits codes optiques imprimés entre les perforations de la pellicule.
Une tête de lecture spéciale est installée sur le projo. L'arrière de la pellicule est éclairée par une LED bien puissante. Un capteur CCD linéaire transmet la vidéo des codes qui défilent au décodeur (Dolby DA-20).
Depuis les "pixels" des codes jusqu'à la sortie audio, ça se passe comme suit:
Lumière (ou pas) -> Capteur CCD -> ADC -> Détection des marqueurs, alignement, ré-échantillonnage de la vidéo -> séparation des données audio et de contrôle -> EDC Reed-Solomon pour l'audio -> décodage AC-3 -> DACs -> sorties audio.
Quelques images sur Wikipedia: https://en.wikipedia.org/wiki/Dolby_Digital#Cinema

J'ai pu chopper un DA-20 fonctionnel ainsi que quelques bandes annonces 35mm pour pas cher, cependant le prix des têtes de lecture sont un peu trop hauts pour le budget de ce projet-qui-rapporte-pas-de-sous.
Le capteur CCD est tout de même assez rapide malgré son âge: 30MHz sur deux canaux pour les pixels pairs et impairs. Malheureusement les capteurs de scanner qu'on trouve aujourd'hui favorisent la résolution plutôt que la vitesse, donc l'idée de faire fonctionner le décodeur "normalement" est mise de côté pour le moment.

La détection et correction d'erreur se fait par un chip spécialisé dont la documentation est dispo. L'algo et les paramètres sont connus donc pas d'inquiétude à ce niveau là.
Le décodage AC-3 se fait aussi par un chip spécialisé et documenté. Les specs du format AC-3 sont aussi publiques et des décodeurs open-source existent, toujours pas d'inquiétude.

Le vrai délire, c'est la conversion des codes 2D sur la pellicule en données.
Le brevet (https://patents.google.com/patent/US5710752A/en) donne quelques infos fort utiles, mais ne va pas en détail dans les champs de données, l'insertion des codes R-S, la méthode d'entrelacement, les métadonnées et données de contrôle...

Tout le traitement des codes optiques se fait avec 5 DSP. Oui, cinq. Des DSP56000 en plus ! J'ai hésité à poster dans le forum Falcon
Quatre DSP56000 identiques qui bossent en parallèle, et un DSP56002 chef d'orchestre.
Les quatre DSP56000 ont chacun une EPROM avec un petit programme qui sert de bootloader, afin que le DSP56002 puisse charger leur programme depuis une mémoire flash centrale.
La mémoire flash contient le programme de base du DSP56002, ainsi que le programme envoyé aux quatre DSP56000 qui font le gros du boulot.
Truc fun: la doc du DA-20 indique que des mises à jour sont parfois inclues dans les codes sur le film ! Pendant les "20 à 30 secondes" de mise à jour, la piste analogique du film est utilisée.

J'ai toutes les cartes, toutes les docs des composants et tous les dumps des mémoires en question, donc à priori j'aurais tout ce qu'il faut pour y arriver. SAUF QUE.
L'asm DSP56k m'explose le cerveau, et j'aurais besoin d'un peu d'aide pour commencer.

Le bootloader des DSP56000 est 100% compris, pas de souci vu que c'est du code style MCU.

Par contre au démarrage du DSP56002, je bloque déjà. Par exemple, il y a un bout de code qui fait s'afficher la sélection d'une roue codeuse 0~F sur un afficheur 7-segments.
J'ai pu repérer et comprendre la routine qui affiche le caractère (ShowSSegDigit, param: x0), par contre son appel ici me laisse perplexe:

ROM:0185 TestModeA:                                   ; Test mode: Boucle infinie, montre l'état roue codeuse sur afficheur (testé IRL)
ROM:0185                 bchg    #3,x:<<PBD           ; Toggle bit 3 port B: kick watchdog
ROM:0186                 movep   y:<<OUT_SSEG,x0      ; Lecture roue codeuse, exemple 9: $000009 -> x0
ROM:0187                 move    #$80,x1              ; $000080 -> x1
ROM:0189                 mpy     x1,x0,a     #$F0,x1  ; x1*x0 -> a, $000080 * $000009 * 2 = 000900 -> a1   $0000F0 -> x1
ROM:018A                 move    a0,a                 ; a0 -> a1 ?! Surement pas 
ROM:018B                 and     x1,a        #$800,x1
ROM:018D                 mpy     x1,x0,a     a1,y:YMEM_FFE1  ; IO externe inconnu
ROM:018F                 move    a1,x0
ROM:0190                 jsr     <ShowSSegDigit
ROM:0191                 jmp     <TestModeA

A ROM:018A, le move a0,a devrait mettre a0 (les 24 bits bas de a) dans a (sous entendu a1, les 24 bits du milieu de a).
Ce qui aurait pour effet d'effacer le résultat du mpy à ROM:0189...

Je suis un peu largué avec les différents bus et la taille des registres DSP56k, malgré avoir passé quelques heures sur le manuel de programmation
S'il y a des habitués qui peuvent me mettre sur le bon chemin, je leur serais fort reconnaissant !

Jamais utilisé ce DSP donc je peux pas t'aider malheureusement, mais ça a l'air sympa

Sinon c'est pas bête de penser au Falcon, il y a peut-être de la doc qui pourrait resservir :
https://mikro.naprvyraz.sk/docs/index.htm

Tu peux aussi de demander dans la section développement Atari ici, et sur Atari-Forum.

mpy   x1,x0, a     ; x1*x0 => a ; si tu as $900 du coup le résultat est dans a0 et non a1 vu qu'il est moins de 24bits
move a0, a          ; le résultat de la mul précédente et shifté dans a en fonction de ce qui est défini dans le register SR

Je le comprend comme ça.

Une petite piste éventuelle pour sourcer des capteurs CCD qui privilegient a priori la vitesse sur la résolution: les anciens lecteurs de codes barres 1D ou certains lecteurs de code barre 2D (datamatrix, aztech, qrcode...) de premières générations (les générations actuelles sont basées sur des caméras donc je ne sais pas dans quelle mesure ça pourrait t'aider).

Pour l'ASM DSP56K as-tu joué avec Ghidra qui dispose de pas mal donctionnalitées pour aider ton analyse ? Je ne sais pas ce que ça vaut mais je suis tombé là dessus :

EDIT: pour reconnaitre au premier coup d'oeil un lecteur code barre 1D CCD d'un lecteur 1D laser (nouvelle génération) il suffit de voir la gueule de la ligne rouge émise par le scanner : ultra fine et bien délimitée c'est du laser, large et floue sur les bords c'est du CCD

SCPCD: c'était ça !! J'étais confus avec le positionnement du résultat de certaines opérations. Je pensais que mpy faisait 24 * 24 -> 24, mais c'est 24 * 24 -> 56 donc le résultat tient dans a0 dans mon cas, comme tu as dit.
Ça m'a bien débloqué pour le reste

Zerosquare et Jonas: merci pour le lien de cette mine d'or ainsi que le tip pour trouver des capteurs 1D, je vais essayer de trouver des modules.
Sinon certains se sont intéressés au EPC901, un capteur 1D ultra rapide:
Pas très cher et facile à interfacer, c'est peut être une piste alternative.

Concernant le firmware, il semble qu'ils utilisent une sorte de FAT avec des secteurs de la même taille que ceux de la flash (128 octets).
Ils utilisent des valeurs 12 bits avec 000 pour marquer les fins de chaines, mais c'est pas du FAT12.
Il n'y a pas de noms de fichiers non plus, juste des drapeaux dans certains secteurs pour indiquer tel fichier doit être chargé à tel endroit.
Le premier secteur d'un fichier contient sa taille et un checksum en header également.
C'est certainement proprio mais des fois que ça vous parle...

Je viens de voir ton twwet sur l'injection directe de signaux sans passer par la capture optique, du génie de simplicité ça ! Tiens nous au jus que ça marche ou que ça foire