Logicielsmoto.com

Nous sommes le 28 Mar 2024, 18:07

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1 ... 16, 17, 18, 19, 20, 21, 22 ... 40  Suivante
Auteur Message
MessagePosté: 31 Oct 2021, 16:20 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Je suis curieux de voir ce que ca donne sur émulateur ou en vrai :)

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 31 Oct 2021, 17:46 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
Citation:
on est obligé de faire du pooling avant chaque envoi d'un octet sur l'interface, ou on peut se baser sur un nb de cycles a attendre ?

Le 6850 de l'interface midi reçoit E/2 soit une horloge de 500 KHz et la transmission MIDI se fait à 31.25 Kbits/s en 10 bits (8 bits de data + 1 bit start et 1 bit stop). Un calcul simple nous permet d'affirmer que la transmission d'un octet prend donc 320 cycles et on peut tout à fait partir sur cette base, puisqu'il n'y a pas d'acquit du récepteur à récupérer ou à valider.

Notons aussi qu'il y a un tampon de un octet dans le 6850 et que l'interface MIDI peut aussi utiliser l'IRQ pour signaler au processeur d'envoyer la suite.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 31 Oct 2021, 19:03 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Je n'avais pas réalisé que c'était aussi lent, du coup il va falloir réfléchir à cette contrainte ...
Car on ne peut pas attendre à ne rien faire pendant ce laps de temps (dans le cadre d'un moteur de jeu)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 31 Oct 2021, 19:43 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
Ben 31.25 kbits/s, hein ...

Mais de toute manière avec une interruption à 50 Hz, j'ai du mal à comprendre comment tu arrives à séquencer ? Sur un tempo très standard de 120, une quadruple croche c'est déjà du 32 Hz, c'est impossible à correctement cadencer avec du 50 Hz, non ?


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 31 Oct 2021, 19:55 
Hors ligne

Inscription: 24 Juil 2010, 16:08
Messages: 454
Localisation: France
Euh, personne ne peut jouer/chanter des notes à 32Hz de toutes façons, et c'est pour ça qu'il n'y a jamais de quadruple croches dans un morceau à 120bpm?

Le maximum doit être vers peut-être 10 notes par seconde dans les cas les plus extrêmes (percussionniste très rapide), et encore. Au delà, on aurait plus le temps d'entendre une note avant le début de la suivante.

Probablement le seul endroit ou on trouve plus rapide, c'est dans les musique chiptunes qui utilisent des arpèges à un rythme très élevé pour compenser le fait de ne pouvoir jouer que 3 ou 4 notes en même temps. Et même là on sera rarement à plus de 25Hz parce que au-delà on n'entend plus vraiment les notes.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 31 Oct 2021, 21:14 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Les drivers pour les cartes fm et psg tournent avec une irq a 50hz et c’est suffisant. Ça donne 6,25 frames entre chaque double croche a 120bpm.
(50fps x 60s) / 120 bpm = 25 frames entre chaque noire.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 31 Oct 2021, 22:50 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
Citation:
personne ne peut jouer/chanter des notes à 32Hz de toutes façons, et c'est pour ça qu'il n'y a jamais de quadruple croches dans un morceau à 120bpm?

Euh, le midi n'a pas été développé pour ça, mais pour piloter des synthétiseurs ... Quand tu développes un effet genre pitch bend ou que tu modifies un filtre, c'est utile les quadruples croches à 120 bpm. Les delta time midi permettent de descendre encore plus fin dans la résolution.

Pour jouer Lettre à Elise, ca va. Mais pour le morceau qui est sur la disquette que je t'ai envoyée, ça va être un peu juste. :D


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 06:51 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Je comprend tout à fait ton point de vue fool :
Les fichiers midi permettent de définir des delta à la microseconde, du coup ça parait un peu fou de vouloir arrondir ça à la frame (50hz) la plus proche soit dans le pire des cas + ou - 10 000 microsecondes.

Maintenant ce genre de décalage on le retrouve déjà naturellement en midi :
Si on prend un fichier midi standard et on déclenche une lecture de note (ou un pitch bend) sur les 16 canaux en même temps (donc 16 commandes de 3 octets avec un delta time de 0 entre chaque) : Il faudra bien attente 15*3*320 = 14400 microsecondes avant que le dernier message commence à être envoyé.

Bon je dirai peu importe, on verra bien lors des tests ce que ça donne.
L'idée de cette routine est de permettre une lecture midi la plus rapide possible en laissant un maximum de ressource au jeu, donc on voit bien que ça ne va pas tel quel.
Si je devais imaginer une autre méthode pour éviter les temps d'attente entre l'envoi de chaque octet à l'interface, je pense à la chose suivante :

On conserve une IRQ à 50hz (ou 100hz si ce n'est pas suffisant) pour la lecture des données midi, mais on copie ces données dans un buffer situé dans la page résidente ($6100-$9FFF) au lieu de les envoyer à l'interface midi.
Ensuite on reconfigure une autre IRQ pour qu'elle se lance tous les 640 cycles pour lire les octets du buffer et les envoyer à l'interface, on enverra 2 octets à la fois (utilisation de l'octet buffer de l'interface si ça fonctionne).
Quand l'IRQ a terminée la lecture du buffer elle repasse en mode 50hz.
On utilise ainsi le temps normalement dédié au pooling pour avancer la suite du programme.

On aura donc deux routines différentes pour l'IRQ :
- Une "lente" qui va lire les données midi dans différentes pages de RAM/ROM, gère le séquencement des messages, prépare le buffer ...
- Une la plus rapide possible qui va juste lire le buffer et envoyer deux octets à l'interface sans aucun temps d'attente (on part déjà avec un handicap de 65 cycles rien que pour l'aller/retour de l'IRQ).

Le tout ne sera pas extraordinairement rapide, mais on met à profit les temps d'attente.
On devrait rester dans une zone acceptable pour faire tourner un jeu en //.

Qu'en pensez vous ? une autre idée ?


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 08:57 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Ca marchera pas sur MO5 car l'IRQ-timer est fixe à 50hz. En outre 640 cycles entre les interruptions c'est vraiment pas beaucoup car rien que le traitement en ROM coute plusieurs centaines de cycles avant d'arriver dans la routine utilisateur. Mais cela ne se fera que tous les 20ms. A voir ce que donnerait le changement de fréquence timer dans une interrupt (car quand tu dis "autre irq", tu veux dire même irq physique, mais routine utilisateur et fréquence du timer différente.)

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 09:32 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
C'est une des raisons pour lesquelles je suis impressionné par tout le travail que tu as déjà abattu, Bentoc. J'ai toujours considéré qu'utiliser les interruptions, tout particulièrement sur TO8/8D/9+, était un bouffe-cycle intolérable.

Il est évident qu'il y a des contraintes avec lesquelles on est obligé de composer pour le midi. Si tu obtiens un résultat correct dans le cadre de ton moteur de jeu, ce sera déjà super.

Moi je raisonne toujours plutôt autour d'un vrai séquenceur (je rêvais d'avoir Cubase sur mon Thomson :lol: ) pour lequel on peut consacrer un bon 90% du CPU à la gestion du midi. Evidemment, la proposition n'est pas la même. D'où ma fameuse IRQ à période adaptée au morceau sur TO. Et sur MO, ce serait un casse-tête sans nom. TSG anyone :-) ?


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 10:00 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Exact sam ce que je propose c'est deux routines différentes qu'on "alterne" pour l'IRQ en fonction de la phase qu'on réalise.

Pour le MO5, tout n'est peut être pas perdu :
Si j'ai bien suivi le 6850 (le chip de l'interface) est capable de déclencher une IRQ quand il est prêt à transmettre de nouvelles données.
En théorie on pourrait donc appliquer cette méthode aussi sur MO5.
On aurait deux sources déclenchant l'IRQ : la source interne à 50hz et la source externe (interface midi)
Il faut juste déclarer au bon moment les changements de routine IRQ ...

Oui je crois que fool avait calculé (dans un autre fil et pour le MO5) un "cout" total de 65 cycles dépensé par le code de la ROM pour une IRQ.
Donc c'est toujours mieux de perdre 65 cycles que 320 (ou 640 si on peut vraiment envoyer 2 octets d'affilé au chip)

Alors là je pose ma question a deux balles, est il possible de modifier la référence à la routine appelée lors d'un FIRQ (par défaut sur nos Thomson : la routine du crayon optique) ?
Si c'est la cas (l'espoir fait vivre) : le signal FIRQ est dispo sur le port extension, on pourrait y brancher le déclenchement IRQ du 6850 ?


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 10:10 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
Citation:
le 6850 (le chip de l'interface) est capable de déclencher une IRQ quand il est prêt à transmettre de nouvelles données.

En effet.
Citation:
est il possible de modifier la routine appelée lors d'un FIRQ (la routine du crayon optique) ?

Bien entendu.
Citation:
Car le signal FIRQ est dispo sur le port extension, on pourrait y brancher le déclenchement IRQ du 6850 ?

Oui, moyennant une modification du circuit, car l'interface MIDI de Logimus ne câble pas la FIRQ.

La FIRQ est très intéressante dans le sens ou elle n'exécute pas tout le bataclan de l'IRQ et en plus elle ne sauve pas les registres sur la pile, hormis CC et PC. D'ou son nom : Fast IRQ.

Sur Thomson, elle a toujours été restreinte à l'usage exclusif du crayon optique et câblée directement ou indirectement en interne [edit] sur le phototransistor du crayon optique [merci sam]. Sur TO8, on a la chance que le signal est retransmis par le PIA 6821 système et donc on peut inhiber cette impulsion et réutiliser la FIRQ pour autre chose.

C'est un point qui mérite attention, surtout dans le cadre d'une nouvelle carte son pour Thomson, je pense : on pourrait envisager un timer externe programmable sur la carte son pour cadencer les envois au chip ou a l'interface midi.


Dernière édition par Fool-DupleX le 01 Nov 2021, 12:05, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 10:51 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Citation:
Bien entendu.

Super nouvelle :sol:

Bentoc a écrit:
Oui, moyennant une modification du circuit, car l'interface MIDI de Logimus ne câble pas la FIRQ.


Bon je sais que tu voulais faire une repro à l'identique de l'extension, mais ça nous aiderait bien d'avoir cette FIRQ câblée sur l'interface !
Le fait de faire ce câblage ça implique de rompre une compatibilité avec les softs qui utilisent l'IRQ normale avec cette carte j'imagine ?
Bon d'un autre coté il n'y a pas bcp de logiciels disponibles non plus.

Citation:
Sur Thomson, elle a toujours été restreinte à l'usage exclusif du crayon optique et câblée directement ou indirectement en interne sur le compteur du gate-array. Sur TO8, on a la chance que le signal du compteur est retransmis par le PIA 6821 système et donc on peut inhiber cette impulsion et réutiliser la FIRQ pour autre chose.


Donc si je comprend bien sur TO8 ça fonctionnerait car on pourrait activer le FIRQ mais inhiber le déclenchement par timer prévu pour la lecture du crayon optique (et donc on aurait le déclenchement par le port extension) ?
Donc ça ne fonctionne pas pour le MO5 ? (A moins que la FIRQ du crayon optique se déclenche toutes les 0,32ms :D , je ne sais pas quelle est la fréquence utilisée pour le crayon optique)

Citation:
C'est un point qui mérite attention, surtout dans le cadre d'une nouvelle carte son pour Thomson, je pense : on pourrait envisager un timer externe programmable sur la carte son pour cadencer les envois au chip ou a l'interface midi.

Bien vu, et même une simple extension avec un timer qui déclenche une FIRQ permettrait de faire de la lecture de samples sur le DAC interne sans consommer trop de ressources.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 10:58 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Non le timer ne marche pas à fréquence fixe. C'est le passage du spot lumineux de l'écran dans la photo-diode qui déclenche le FIRQ sur le CPU qui a alors quelques µs pour lire les compteurs écrans et les sauver dans un buffer qui sera décodé plus tard dans la routine GETLP du moniteur. En effet la ligne écran ne fait que 64µs. C'est pour cela qu'il faut aller vite dans le "latch" des compteurs et ainsi atteindre la précision du pixel (<1µs, soit plus rapide qu'un cycle cpu.. il y a une vache d'algorithme pour atteindre cette précision).

http://dcmoto.free.fr/documentation/mon ... ht_src.txt

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 11:31 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Merci sam

oh punaise, je ne savais pas qu'il y avait un livre avec le code source commenté de la ROM du MO5 sur le site dcmoto.
Dommage qu'il n'existe pas pour le TO8, bon il doit y avoir quand même de grands passages identiques j'imagine.


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1 ... 16, 17, 18, 19, 20, 21, 22 ... 40  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 37 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com