Logicielsmoto.com

Nous sommes le 18 Juil 2019, 00:06

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 52 messages ]  Aller à la page Précédente  1, 2, 3, 4  Suivante
Auteur Message
 Sujet du message:
MessagePosté: 11 Juil 2012, 21:43 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Prehisto a écrit:
Tu m'étoooooooooooonnes !!!! Je viens de retrouver Linux comme je l'aime ! Les vidéos sont bien plus fluides sans PulseAudio. Bon ben voilà un problème résolu, je pense.

Est-ce que ca règle le pb pour TEO aussi?


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 11 Juil 2012, 22:26 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Pas encore essayé. Je fais autre chose pour le moment. Mais je pense que le problème sera calmé, car PulseAudio prenait pas mal de temps CPU, si mes souvenirs sont bons.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Juil 2012, 08:30 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Ca n'a pas résolu grand chose, en fin de compte : si je vire l'appel à la routine son, XOrg et Teo tombent très bas en usage CPU. Si je rétablis l'appel à la routine son, XOrg (principalement) et Teo occupent les 100% d'usage CPU.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Juil 2012, 09:09 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Ca y est, tout est rentré dans l'ordre :D

XOrg ne fait plus des siennes, et Teo s'est calmé.

C'était, je pense, le programme de xrun-recovery qui causait problème, dans lequel j'utilisais des fonctions du style snd_pcm_recover() ou snd_pcm_state(), du temps où j'avais des problèmes avec le son. Après les avoir enlevé, ça va beaucoup mieux, même avec le son en continu.

Cette fois-ci, oui, le problème est résolu :)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 12 Juil 2012, 20:14 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Prehisto a écrit:
Cette fois-ci, oui, le problème est résolu :)
Cool :cool:, content pour toi.

Le problème était donc hyper particulier et pas du tout dans Teo qui n'y était pour rien. Je suis rassuré :) mais on voit que la base des testeurs est un peu trop réduite.

A ton avis il y aurait un truc à faire pour que google sorte la page avec la version 1.8.1 au lieu de l'anté-diluvienne 1.7.6? Une page sur la 1.8.1 n'arrive qu'en 7eme position avec la recherche google: teo to8 emulator (ou la version française "teo emulateur to8"). D'ailleurs c'est curieux que ce sujet ici même sur le forum ne semble pas du tout indexé par google même quand on cherche le simple "Teo to8" :cry:

[edit]Apparemment il y aurait une procédure pour faire indexer un site dans les outils google pour webmaster, mais il faut justement être le webmaster et déposer un fichier spécifique de "validation" fourni par google à la racine du site (il y a d'autres moyens, mais ils reviennent aussi à prouver à google que l'on est le webmaster du site).


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 15 Juil 2012, 17:33 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Prehisto a écrit:
J'ai eu à pas mal travailler sur le son, j'avais trouvé quelque chose qui évitait, justement, une légère friture qui n'existe pas sur un vrai Thomson dans certaines situations, mais ça a l'air de ne pas encore être au point.


A propos de la friture.. je crois que je suis en train de l'observer en ce moment même.

En je bricole un truc audio à base d'interruption timer dans l'esprit de ce que fait Android (chut c'est secret pour le moment).. Ca marche pas mal du tout, sauf qu'il y a de temps en temps un petit parasite qui apparait. Quand je regarde les courbes, je m’aperçois que c'est un décrochage de buzzer qui au lieu de faire 1 0 1 0 1 0 fait 1 0 1 1 0 1 0 1 (il fait 2 fois 1 au lieu d'alterner).

Le code en lui même est très simple: il lit $E7C1, fait un xor avec 8 et réécrit tout ca en E7C1. Je ne pense pas qu'il soit possible que le prog loupe une alternance, ca doit venir "d'ailleurs".

Pour en avoir le coeur net j'ai mis dans mon prog un test sur la valeur attendue du bit 3 de $E7C1. Et je tombe parfois dans un cas ou après avoir écrit 1 (ou 0), la lecture suivante lit une valeur opposée. Il y a quelque chose dans l'emul qui change de temps en temps le bit du buzzer!

Qu'est-ce qui peut provoquer ce phénomène? Ce qui est étrange c'est que ca le fait aussi sur DC-MOTO qui contient les mêmes artéfacts (aux même moments dans les chansons).
Image

Si je ne lis plus $E7C1 pour changer l'état du bit 3 mais que j'utilise la valeur attendue du code de test, le crépitement apparait nettement moins audible (voir inexistant, bien qu'il reste un truc de période 2secs +/-200ms). Il y a donc un truc "externe" qui change la valeur du bit 3 de $E7C1 dans l'emul.

Je ne sais pas si c'est pareil sur un vrai Thomson. Il faudrait que je ponde un prog tout petit qui met en exemple le soucis, mais le test immédiat de lire en permanence $E7C1 le montre bien sage. Il doit s'agir d'une interaction avec les interruptions timer je suppose.


Dernière édition par Samuel Devulder le 16 Juil 2012, 21:34, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 16 Juil 2012, 21:31 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Samuel Devulder a écrit:
Il y a donc un truc "externe" qui change la valeur du bit 3 de $E7C1 dans l'emul.
Avec un méga coup de chance (et un autre émul, hum...désolé ;-) ) J'ai peut-être trouvé le coupable. C'est la gestion des touches clavier en rom:
Code:
// Gestion du clavier
FACF A6    LDA  a,S
FAD1 84    ANDA #F8
FAD3 81    CMPA #E0
FAD5 27    BEQ  FAEC
FAD7 7A    DEC  60DC
FADA 26    BNE  FAE4
FADC B6    LDA  E7C1
FADF 84    ANDA #F7    <=== Nettoie le bit 3
FAE1 B7    STA  E7C1
FAE4 B6    LDA  60D4
FAE7 8A    ORA  #80
FAE9 B7    STA  60D4
FAEC B6    LDA  6019
FAEF 85    BITA #20
FAF1 27    BEQ  FAF7
FAF3 6E    JMP  [6027]

L'instruction en $FADF nettoie le bit 3 quand $60DC passe à 0! Le hic c'est que le manuel technique to8 n'indique pas ce que contient $60DC. C'est quand même curieux que le moniteur modifie un bit dont la doc indique (p133): "Le bit P3 n'est pas utilisé (ancienne commande LED clavier TO7, TO7/70)".

Quoi qu'il en soit, il semble que $60DC n'est touché qu'en $FADC. C'est donc un compteur cyclique de période 256 interruptions qui force à 0 le bit B3 de E7C1. Comme dans mon cas les interruptions ne sont pas espacées régulièrement, ce forcage à 0 introduit un parasite dans la routine de son.

La routine suivante
Code:
     21  5     A000 B6   E7C3     XXXXX  lda    $E7C3
     22  2     A003 8A   01              ora    #1
     23  5     A005 B7   E7C3            sta    $E7C3
     24  5     A008 B6   E7C1            lda    $E7C1
     25  2     A00B 8A   08              ora    #8
     26  5     A00D B7   E7C1            sta    $E7C1
     27  5     A010 B6   E7C1     LOOP   lda    $E7C1
     28  2     A013 85   08              bita   #8
     29  3     A015 26   F9              bne    LOOP
     30  7     A017 73   4000            com    $4000
     31  2     A01A 8A   08              ora    #8
     32  5     A01C B7   E7C1            sta    $E7C1
     33  3     A01F 20   EF              bra    LOOP
montre cet artefact. Elle écrit 1 dans le bit 3 de $E7C1 et regarde s'il passe à 0 "tout seul". Dans ce cas elle complémente le 1er octet écran et reforce le bit à 1. Avec ce code on entends un petit bruit accompagné de l'inversion de $4000 environ toutes les 25secs. C'est logique, la période par défaut de l'interruption timer est celle du clignotement du curseur soit 100ms. Or 100ms * 256 = 25secs. Ca colle impec!

Dans mon cas, je génère des signaux autour de 100hz, et donc le forcage à zero a lieu tous les 2.5secs... ca correspond avec ce que j'avais trouvé par l'analyse en fréquence (c'est cool les FFT!).

Du coup préhisto, pour en revenir à l'émulation, je me demande si la "friture" dont tu parles ne serait pas causée par le forcage à 0 du bit b3 par ce bout de code du moniteur appelé à chaque interruption IRQ alors qu'on fait tourner le timer à une fréquence élevée. Par exemple si on place 10 en $E7C6, le forcage à 0 a lieu toutes les 2 560µs = 400Hz environ.. un truc parfaitement audible!


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 22 Oct 2012, 20:48 
Hors ligne

Inscription: 21 Avr 2010, 10:59
Messages: 230
concernant le référencement du site, l'utilisation de tags google analytics devrait également améliorer le référencement.
Sinon tu as aussi un débugger sur la version linux de teo mais il reste encore à améliorer, pour le moment on a le minimum vital.
Il me semble que TEO bidouille encore la rom clavier mais je ne sais pas si le patch a une influence sur cette partie du code.

_________________
http://www.alternative-system.com


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Fév 2013, 14:35 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Pour info, sur un portable "moderne" (64bits AMD, windows 8) avec un écran 16/9 (1366x768) les modes pleins écran échouent avec un "Mode vidéo non supporté". Seul l'affichage en mode fenêtré peut s'ouvrir.

Par ailleurs, si on active l'entrelacement vidéo, l'affichage est super lent, et l'usage CPU coté "système" occupe un cœur complet.

On dirait que TEO et Windows8 ne s'aiment pas bien (sur mon XP 32bits ca marchait bien). D'autres ont t'il testé TEO sur les machines modernes?


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Fév 2013, 17:41 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Samuel Devulder a écrit:
Pour info, sur un portable "moderne" (64bits AMD, windows 8) avec un écran 16/9 (1366x768) les modes pleins écran échouent avec un "Mode vidéo non supporté". Seul l'affichage en mode fenêtré peut s'ouvrir.

Ça me paraît censé. Ce matériel n'a plus rien à voir avec les vieux 486.

Samuel Devulder a écrit:
Par ailleurs, si on active l'entrelacement vidéo, l'affichage est super lent, et l'usage CPU coté "système" occupe un cœur complet.

Ha ben oui, le mode vidéo entrelacé, ça pompe. Essaie-le en vitesse rapide, tu vas halluciner ;)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Fév 2013, 19:45 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Prehisto a écrit:
Ça me paraît censé. Ce matériel n'a plus rien à voir avec les vieux 486.

Yep. Pour info si j'utilise une version que j'avais compilée pour allegro 4.2, en mode plein écran, on voit une fenêtre plein-écran s'ouvrir. Mais ca se termine avec la même sanction. Je pense que c'est allégro qui estime que la réso native de 16/9 (1366x768) ne peut ouvrir l'écran 16/10 (320x200) demandé. Pourtant si on met des petites marges noires autour, ca tient.

Citation:
Ha ben oui, le mode vidéo entrelacé, ça pompe. Essaie-le en vitesse rapide, tu vas halluciner ;)

Oui. M'enfin ca ne devrait pas pomper autant de temps dans l'OS. Typiquement d'après process explorer le temps passé dans l'OS dépasse les 90%, alors que sous XP sur une machine beaucoup plus vielle, c'est beaucoup moindre. Je pense que c'est allegro40 qui ne sait pas bien faire les blits efficacement sur les carte graphiques modernes, ou qu'un truc est oublié qui était inutile avec les vieilles cartes mais qui s'avère indispensable avec les nouvelles. C'est peut-être simplement un problème d'alignement (https://www.allegro.cc/manual/4/api/bli ... rites/blit) des blocs à blitter. Les infos de la variable gfx_capabilities peuvent donner des stratégies sur la façon la plus efficace de faire le blit().


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Fév 2013, 20:57 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Samuel Devulder a écrit:
Je pense que c'est allegro40 qui ne sait pas bien faire les blits efficacement sur les carte graphiques modernes, ou qu'un truc est oublié qui était inutile avec les vieilles cartes mais qui s'avère indispensable avec les nouvelles.

Tu as dû effectivement mettre le doigt dessus. Mais certains demandent encore à ce que Teo tourne sur Windows 98. Alors que faire ?


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Fév 2013, 21:17 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Prehisto a écrit:
Tu as dû effectivement mettre le doigt dessus. Mais certains demandent encore à ce que Teo tourne sur Windows 98. Alors que faire ?

Pour l'instant rien. Je vais regarder plus en détail ce qui cloche avec allegro40 et voir si je peux me faire une version avec allegro40 qui marche pour ma nouvelle machine. C'est peut-être 3 fois rien, typiquement inspecter gfx_capabilities et peut-être utiliser masked_blit() au lieu de blit() si GFX_HW_VRAM_BLIT_MASKED est positionné.

Edit: Ah ca c'est dingue:
Code:
blit(screen_buffer, screen, 0, j, 0, j, tcol->screen_w, 1);
rame à mort (100%cpu 2 coeurs), alors que
Code:
blit(screen_buffer, screen, 0, j, 0, j, tcol->screen_w, 2);
ne mange rien. C'est la hauteur de 1 pixel qui fait tout ralentir. Un blit sur plusieurs lignes est instantané, sur une seule ca mange toutes les resources. C'est à n'y rien comprendre.

Edit2: ah la vache blit envoie sur linear32_bit qui est un code ASM 32bits:
Code:
/* void _linear_blit32(BITMAP *source, BITMAP *dest, int source_x, source_y,
 *                                     int dest_x, dest_y, int width, height);
 *  Normal forwards blitting routine for linear bitmaps.
 */
FUNC(_linear_blit32)
   pushl %ebp
   movl %esp, %ebp
   pushl %edi
   pushl %esi
   pushl %ebx
   pushw %es

   movl B_DEST, %edx
   movw BMP_SEG(%edx), %es       /* load destination segment */
   movw %ds, %bx                 /* save data segment selector */
   cld                           /* for forward copy */

   _align_
   BLIT_LOOP(blitter, 4,         /* copy the data */
      rep ; movsl
   )

   popw %es

   movl B_SOURCE, %edx
   UNREAD_BANK()

   movl B_DEST, %edx
   UNWRITE_BANK()

   popl %ebx
   popl %esi
   popl %edi
   movl %ebp, %esp
   popl %ebp
   ret                           /* end of _linear_blit32() */

#define BLIT_LOOP(name, bpp, code...)                                        \
blit_loop_##name:                                                          ; \
   movl B_DEST, %edx             /* destination bitmap */                  ; \
   movl B_DEST_Y, %eax           /* line number */                         ; \
   WRITE_BANK()                  /* select bank */                         ; \
   movl B_DEST_X, %edi           /* x offset */                            ; \
   leal (%eax, %edi, bpp), %edi                                            ; \
                                                                           ; \
   movl B_SOURCE, %edx           /* source bitmap */                       ; \
   movl B_SOURCE_Y, %eax         /* line number */                         ; \
   READ_BANK()                   /* select bank */                         ; \
   movl B_SOURCE_X, %esi         /* x offset */                            ; \
   leal (%eax, %esi, bpp), %esi                                            ; \
                                                                           ; \
   movl B_WIDTH, %ecx            /* x loop counter */                      ; \
   movw BMP_SEG(%edx), %ds       /* load data segment */                   ; \
   code                          /* do the transfer */                     ; \
                                                                           ; \
   movw %bx, %ds                 /* restore data segment */                ; \
   incl B_SOURCE_Y                                                         ; \
   incl B_DEST_Y                                                           ; \
   decl B_HEIGHT                                                           ; \
   jg blit_loop_##name           /* and loop */
Ca ne devrait pas ramer plus avec height=2 que height=1. Pourtant c'est bien le cas :( Ce qui rassure c'est qu'on est au moins^wexactement 2 à râler sur la planete à propos de linear_blit32. Pas sur que ca change de si tôt...

Edit3: j'ai posté une question sur le forum Allegro. On va voir les suites. J'espère que je ne vais pas avoir de réponses à l'emporte pièce: "utiliser allegro 5" alors que j'aimerais vraiment comprendre pourquoi le blit sur une seule ligne est plus lent que sur 2 avec ma machine.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Fév 2013, 15:08 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1054
Localisation: France (24)
Samuel Devulder a écrit:
Edit: Ah ca c'est dingue:
Code:
blit(screen_buffer, screen, 0, j, 0, j, tcol->screen_w, 1);
rame à mort (100%cpu 2 coeurs), alors que
Code:
blit(screen_buffer, screen, 0, j, 0, j, tcol->screen_w, 2);
ne mange rien. C'est la hauteur de 1 pixel qui fait tout ralentir. Un blit sur plusieurs lignes est instantané, sur une seule ca mange toutes les resources. C'est à n'y rien comprendre.

Si ça n'est que ça, il y a toujours la possibilité de tracer les lignes avec 2 points de haut en écrasant juste la ligne précédente à chaque fois. Pas génial, c'est sûr, mais si ça fait gagner du temps malgré tout ...


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Fév 2013, 16:09 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1110
Localisation: Brest
Prehisto a écrit:
Si ça n'est que ça, il y a toujours la possibilité de tracer les lignes avec 2 points de haut en écrasant juste la ligne précédente à chaque fois. Pas génial, c'est sûr, mais si ça fait gagner du temps malgré tout ...

J'ai expérimenté. On perds l’émulation de l'entrelacement. Autant basculer sur l'affichage normal.
Il serait sympa de trouver la bonne technique (rapide et jolie) pour emuler un CRT en jouant sur l'alpha blending (on affiche les pixels en gardant une fraction des pixels de la frame précédente). J'avais un jeu flash dans mes bookmarks qui faisait ca, mais je ne le retrouve plus :(


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 52 messages ]  Aller à la page Précédente  1, 2, 3, 4  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité


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 à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com