|
DCMOTO - Emulateur universel Thomson 8 bits : Forum - Emulateurs et utilitaires - DCMOTO 9.0 beta2
|
|
|
Daniel
Visiteur
|
Date : 27/11/2004 à 18h16
Comme annoncé dans un autre fil de discussion, la version beta2 est disponible.
- Elle corrige un bug de formatage (quelle que soit l'unité sélectionnée le DSKINI formatait l'unité 0).
- Les messages d'erreurs de DirectX sont plus détaillés.
Daniel
|
| en haut - en bas |
|
|
|
Jérémie
Visiteur
|
Date : 03/01/2005 à 21h41
Salut Daniel et tout le monde, et bonne année à tous!!!
Daniel, je ne sais pas si tu tiens à faire fonctionner DCMOTO sur windows 95, enfin je t'informe quand meme: sur ma machine qui est justement en win95 eh bin voila, ca marche pas  
Un tout petit peu plus de détails:
- la version 8.4preview que tu m'avais envoyée je crois, fonctionne bien (il faut bien avoir configuré la carte son bien sûr).
- les previews "chinese stack", "sinux crawl", etc. fonctionnent aussi
- par contre les différentes versions de "dcmoto-test", ne fonctionnent pas
- .. et surtout, les dernières versions 9.0beta (beta1 et beta2) non plus
Les symptômes, communs à toutes les versions qui ne marchent pas, sont les suivants: je double-clique sur l'icone, le curseur se transforme en sablier une fraction de seconde (un dixième de seconde?), puis revient à l'état initial... et plus rien! Sans aucun message d'erreur ou autre
Voici ma config:
Win95B (OSR2)
DirectX 8.0a
et puis aussi, sans que je sache si ca t'est utile:
amd k6-2 350,
ATI rage2,
carte son Advanced Logic ALS4000
... voila, je n'en sais pas beaucoup plus, je ne suis pas un as du debug sous Windows... par contre je suis pret a faire tous les essais que tu voudrais eventuellement mener, si le coeur t'en dit!  (je peux par exemple essayer sur la meme machine mais avec un win98, si tu me laisses un peu de temps... etc.)
@+ Jeremie
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 03/01/2005 à 23h30
Pas évident, ton problème
Surtout qu'il n'y a pas de différences fondamentales entre les previews Chinese Stack et la version 9.0
Normalement DirectX 8.0 est suffisant. La carte son pourrait poser un problème, mais si elle marche avec Chinese Stack elle doit marcher avec la 9.0. Il doit y avoir un tout petit détail qui bloque. Je vais vérifier les options du compilateur, pour m'assurer de la compatibilité avec le K6-2
Ce qui m'embête le plus, c'est de réinstaller Windows 95 pour faire des tests. J'ai encore une machine en Windows 98 SE, mais aucune en 95. Si je trouve une piste pour expliquer le problème, je t'enverrai une nouvelle version de test. Mais je ne promets rien, car ça me semble très subtil. Et rien ne prouve que ce soit dû à Windows, c'est peut-être une incompatibilité matérielle. Si tu as la possibilité d'essayer sur la même machine avec une autre carte son, ça serait intéressant. Je vais aussi rechercher des versions intermédiaires entre la 8.4 et la 9.0, pour que tu puisses les tester. Ca permettra peut-être de trouver la petite différence qui provoque le problème. L'essai que tu proposes (windows 98 sur la même machine) peut apporter une information intéressante. Essaye aussi de lancer le programme après avoir supprimé le fichier dcmoto.ini (sa structure a changé entre la 8.4 et la 9.0).
Si dcmoto ne tourne pas sous Windows 95, ce n'est pas extrêment grave, mais c'est dommage. Je te remercie beaucoup de l'avoir signalé, et avec ton aide on devrait pouvoir trouver une solution. Je te fais signe dès qu'il y a du nouveau.
Daniel
|
| en haut - en bas |
|
|
|
Jérémie
Visiteur
|
Date : 04/01/2005 à 15h27
Bon, je vais donc attaquer bientot de multiples re-installs de Windows...
Plus précisément:
- je vais faire l'essai d'effacer le fichier .INI , bien que j'ai decompresse les differentes versions dans des repertoires separes, ca ne devrait donc pas etre ca.
- je fais aussi l'essai avec differentes cartes sons (j'en ai au moins 4 au total dont 3 de Creative, si avec ca il n'y en a pas une de bonne! Le seul truc peur-etre est que ce sont surtout des cartes assez anciennes, mais je pourrais aussi en emprunter a des amis... je te tiens au courant de tout ca!!!)
- et apres (quand j'aurai le temps,peut-etre pas ce soir) je m'installe un win98se, etc.
- enfin bien sur, je me tiens pret a tester les versions intermediaiares que tu m'enverras ;-)
a+
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 04/01/2005 à 15h41
OK ! De mon côté, je recherche les versions successives depuis la 8.4. Si on compare la dernière qui marche et la première qui plante, le diagnostic sera plus facile.
Daniel
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 04/01/2005 à 21h17
J'ai mis 3 versions successives ici
Le but est de savoir si elles marchent ou si elles plantent dans Windows 95. En dehors de ça elles n'ont aucun intérêt (buggées et incomplètes).
Daniel
|
| en haut - en bas |
|
|
|
|
|
|
Daniel
Visiteur
|
Date : 05/01/2005 à 12h08
| Jérémie a écrit : | | j'ai ete heureusement surpris d'ailleurs, puisque l'emulation ne "rame" plus comme c'etait le cas avec la 8.4preview |
Grâce à DirectX  l'affichage est environ 10 fois plus rapide, on peut redimensionner la fenêtre, et le son est meilleur. J'ai développé avec DirectX9.0 mais je n'utilise que des fonctions compatibles 8.0 (et même peut-être 7.0).
Ce que tu écris par ailleurs confirme que le pb vient de Windows 95. Je suis persuadé que c'est un tout petit détail, facile à corriger. Reste à trouver lequel...
Daniel
|
| en haut - en bas |
|
|
|
|
|
|
Daniel
Visiteur
|
Date : 06/01/2005 à 09h00
Grâce à ces tests je vais pouvoir comparer les versions du 06/11 et du 22/10, c'est un grand pas vers la résolution du problème.
Les autres résultats confirment ce que j'avais obtenu sur un Pentium II 330 MHz + Windows 98
Les previews de Chinese Stack n'utilisent pas la toute dernière version de dcmoto, ce qui explique leur performance moins bonne sur les machines moins rapides.
La solution adoptée dans la v9.0 beta2 est un buffer son de 512x8, ce qui donne la même qualité que 1024x4 mais diminue un peu le temps de latence (le décalage du son par rapport au programme). En théorie, il est de 512 * 7 / 22500 = 0,16 seconde. C'est un compromis, pour permettre de faire fonctionner l'émulateur sur des machines pas trop rapides avec un nombre de trames par seconde encore acceptable.
Avec les processeurs actuels, on pourrait facilement diviser par 4 ou même 8. Sur un pentium 4 à 3 GHz + une bonne carte graphique, avec un buffer audio de 512x2, on peut avoir un affichage de 1280x1024 à 50 trames/seconde sans perturber le son. Le temps de latence est alors 512 / 22500 = 0,02 seconde.
Daniel
|
| en haut - en bas |
|
|
|
Yoann
Visiteur
|
Date : 06/01/2005 à 10h10
Au passage Daniel ... je n'ai jamais ecrit d'emulo, donc je suis peut etre completement a cote de la plaque.
Mais pourquoi ne pas faire un emulo qui emule le hardware carement ... j'entend par la qui emule l'electronique (pas d'un niveau trop basique non plus ... sinon il va falloir changer les "resistances" et autres "alims" des emulateurs ... quoi que ce serait marrant  ).
Le microproc, on sait a peut pret l'emuler, le quartz aussi. Mais emule-t-on correctement les autres chips comme le son, la video ... etc ... ? Tu parles de decalage acceptable, mais pourquoi est-ce acceptable ? Je comprend l'emulation comme une facon de reproduire une machine, et non de reproduire ces logiciels. Un emulateur celon moi devrait fonctionner comme la becane. Je pense que de nos jours, les PC sont suffisament rapide pour faire ca.
Tu prend 1 cycle, et tu execute l'emulation de chacun des composants de la becanes (quand je dit "composant", je ne parle pas au niveau transistor ou resistance, hein ). Je pense qu'un cycle CPU est suffisament petit pour emuler toutes les parties de l'ordinateur (e.g. que rien ne se produit plus rapidement que la vitesse du processeur)
De cette facon, tu ne pourrais pas avoir de "decalage" entre quoi que ce soit.
Chose a emuler (en vraiment tres gros)
* Emuler un moniteur
* Emuler le chip video
* Emuler le CPU
* Emuler le chip son (ou le "truc" qui s'occuper de faire le "bruit")
* Emuler le bus d'extension ...
* Emuler le ...
Et bien sur, chaque extension a sa propre emulation par la meme occasion.
Et a chaque cycle CPU (1Mhz), tu les lances un par un.
Je ne sais pas si je m'exprime bien, mais je pense que tu sauras ou je veux en venir ;)
PS: Smague ... inutile de venir commenter la dessus, on s'en fout (Et inutile de citer les messages de ce forum sur logicielsmoto, ils seront effaces comme tous vos messages.)
|
| en haut - en bas |
|
|
|
Fool-DupleX
Visiteur
|
Date : 06/01/2005 à 12h19
| Citation : | | Je pense qu'un cycle CPU est suffisament petit pour emuler toutes les parties de l'ordinateur (e.g. que rien ne se produit plus rapidement que la vitesse du processeur) |
En l'occurrence, c'est inexact, car l'horloge d'un Thomson 8 bits est de ... 16 MHz. Le gate-array produit notamment a partir de cette frequence les 8 MHz necessaires pour transferer l'image video vers l'ecran. Le CPU est drive par deux horloges en quadrature de phase a 1 MHz et je m'etendrai pas sur le rafraichissement de la RAM dynamique.
Mais ca ne change pas grand chose a ta proposition  . qu'en dis-tu Daniel ?
Fool
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 06/01/2005 à 13h39
La description de Yoann est le rêve de tous les programmeurs d'émulateurs.
Il y a quelques années, c'était matériellement impossible, les performances des PC ne le permettaient pas. Aujourd'hui il serait possible, non pas de l'atteindre, mais de s'en approcher. Je dis ça parce qu'il faut bien modifier un peu le comportement de l'émulateur par rapport à la machine d'origine pour pouvoir utiliser le matériel du PC. Je n'ai pas du tout envie de connecter un lep au port parallèle pour charger Mandragore en 15 minutes, alors qu'une seconde suffit à partir d'un fichier .k7 sur le disque dur. Et je ne veux pas sortir la video sur un cable péritel, je préfère laisser le driver NVidia s'occuper de l'affichage.
Pour le reste, tous les choix se discutent. Personnellement je ne suis pas puriste, et peut-être aussi un peu paresseux. J'en fais le moins possible, et ne "colle" au matériel qu'en cas de nécessité. Ce fut le cas quand la démo Chinese Stack est sortie : avant j'affichais l'écran entier d'un seul coup (version 8.4), maintenant je l'affiche ligne par ligne (version 9.0).
L'autre approche serait de suivre l'idée de Yoann, et de s'en écarter qu'en cas d'impossibilité matérielle. Qui veut s'y lancer ? Ce serait excellent d'avoir une vraie concurrence entre émulateurs Thomson, tous en profiteraient et la motivation des programmeurs serait entretenue
Daniel
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 06/01/2005 à 15h55
Pour continuer sur ce sujet passionnant, il faut aussi savoir que le matériel d'un PC moderne n'est pas facilement accessible en direct par le programme, en particulier avec les systèmes Windows NT et successeurs.
Sur le MO5, le bit "haut-parleur" est directement connecté à l'entrée de la télé par un conducteur électrique. Sur PC ce n'est pas si simple d'accéder aux enceintes : le système est une première barrière. L'API Windows est un écran assez opaque : on envoie le son, Windows en fait ce qu'il veut quand il veut, et ce n'est pas toujours ce que souhaite le programmeur. Avec DirectX c'est un peu plus direct (comme son nom l'indique), mais toutes les cartes son ne supportent pas l'utilisation de leur buffer interne. Dans ce cas, DirectX créé un buffer logiciel intermédiaire en mémoire PC. Et quand on atteint le buffer physique de la carte son, ce n'est pas encore le haut-parleur : le processeur audio se charge du transfert, et personne ne peut le faire aller plus vite s'il n'a pas envie.
Tout ça pour dire qu'on ne peut pas éviter le temps de latence. Ou alors, il faut revenir en DOS et attaquer directement le haut-parleur interne du PC, accessible en direct.
Quant à l'idée d'exécuter un cycle du processeur à chaque microseconde, il ne faut pas y compter. Le système a des tâches prioritaires, qui interrompent le programme de temps en temps. Ces interruptions durent beaucoup plus qu'un cycle. La stratégie est donc d'exécuter les cycles en moins d'une microseconde pour prendre de l'avance, puis d'attendre un top de synchronisation. Ainsi, les interruptions de l'émulateur pendant les attentes passent inaperçues.
Tout ceci ne doit pas décourager les candidats à une émulation précise. Mais la programmation d'émulateurs n'est pas aussi simple qu'on pourrait le croire de prime abord. Cette difficulté en fait l'intérêt, et peut même transformer l'exercice en passion
Daniel
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 06/01/2005 à 20h02
Pour Jérémie : j'ai mis 4 autres versions de dcmoto ici
Si tu as le temps de les tester avec Windows 95, ça précisera encore mieux la cause de l'anomalie. Dans un premier temps, je suis passé à DirectDraw pour l'affichage, puis une semaine plus tard j'ai utilisé DirectSound pour le son. Je soupçonne que cette deuxième modif n'a pas été du goût de Windows 95, mais je voudrais en avoir confirmation avant de chercher davantage. Merci d'avance.
Daniel
|
| en haut - en bas |
|
|
|
Jérémie
Visiteur
|
Date : 07/01/2005 à 00h01
Voici les resultats; j'ai l'impression que ca se complique!
- version 2004-10-23 : le cadre de la fenetre s'affiche mais pas le contenu (il reste l'ancien contenu de l'ecran, papier peint ou autre...). Les menus sont fonctionnels, c'est apparemment seulement l'affichage qui n'est pas rafraichi
- version 2004-10-24 : un cas pas encore vu! la fenetre se remplit bien de la couleur de fond correspondant manifestement a la bordure de l'ecran Thomson (a l'aveugle sous le Basic, j'ai tape des SCREEN,,n qui modifiaient la couleur affichee en n )
- versions 2004-10-28 et 2004-11-05 : symptome habituel - sablier fugitif puis plus rien
Voila! En fait je finis par avoir un doute, les previews chinese stack etaient bien sous DirectX ... ?
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 07/01/2005 à 08h34
Comme ce sont des versions de travail intermédiaires, leur comportement plus ou moins bizarre n'a pas grande signification. L'information importante est le plantage dans Windows 95 à partir du 28/10. Pour trouver une piste, je vais recenser toutes les modifications faites ce jour-là.
Daniel
|
| en haut - en bas |
|
|
|
Jérémie
Visiteur
|
Date : 07/01/2005 à 10h40
ok Daniel,
Je suppose donc que tu vas refaire chacune des modifs du 28/10 ? Je me tiens pret a les essayer une par une!
Sur ce bonne journee!
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 07/01/2005 à 18h48
DirectSound est hors de cause : le 28/10 il n'était pas encore utilisé.
Pour continuer les tests, j'ai préparé une version spéciale de dcmoto qui affiche un message après chaque étape de l'initialisation. On pourra ainsi localiser la partie du programme en cause. Les messages affichés doivent être :
- "Register class OK"
- "Création fenêtre OK"
- "Création status bar OK"
- "Lecture fichier .ini OK"
- "Initialisation menu OK"
- "Initialisation joystick OK"
- "Thomson hard reset OK"
- "Initialisation DirectDraw OK"
- "Initialisation DirectSound OK"
De plus, le décompactage de l'exécutable est aussi une cause d'erreur possible, je n'ai donc pas compacté cette version. Elle est ici
Daniel
|
| en haut - en bas |
|
|
|
Jérémie
Visiteur
|
Date : 10/01/2005 à 23h13
Bonsoir Daniel, j'espère que tu as passé un bon week-end
J'ai testé la version que tu m'as soumise, le resultat est l'apparition de 2 fenetres d'erreur:
- une premiere, "Le fichier DCMOTO-CONTROLE.EXE est lie a une exportation manquante USER32.DLL:GetWindowInfo"
- une seconde "Un peripherique attache au systeme ne fonctionne pas correctement"
Bon, a vrai dire la seconde apparait sous la premiere fenetre, donc en fin de compte on a l'impression que la seconde est la premiere (elle est reconverte). Mais c'est bien elle qui apparait en premier
En tout cas, pas de trace de tes fenetres a toi....
J'ai verifie dans le panneau de config., tous les peripheriques sont indiques comme fonctionnant normalement!
(Au fait, si c'est l'affichage des messages de debug qui pose probleme, je ne vois pas d'inconvenient a ce qu'ils soient simplement ecrits dans un fichier plat dans le reperoire courant!)
|
| en haut - en bas |
|
|
|
)
sur ce bonne nuit ! 
et a bientot!