[Exelvision] Nouvel émulateur EXL100

[gilles]

Après écoute, la méthode des buffers multiple sonne effectivement bien, et mieux que la version allégro... Donc on reste comme ça, la synchro sur le son sera pour plus tard...

[OlivierP]

wxWidget 2.8.8 livré avec Snow Leopard, SDL est une build perso. Je ne sais pas pourquoi il veut passer en x86_64 alors que ce n'est pas explicitement demandé.

Est-ce que peux lancer cette commande

Code : Tout sélectionner

file /usr/lib/libwx_macud-2.8.dylib 

cela donne chez moi:

Code : Tout sélectionner

/usr/lib/libwx_macud-2.8.dylib: Mach-O universal binary with 2 architectures
/usr/lib/libwx_macud-2.8.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
/usr/lib/libwx_macud-2.8.dylib (for architecture ppc7400):	Mach-O dynamically linked shared library ppc

[OlivierP]

Gilles, est-ce que tu as un sound.log semblable au mien ?
J'ai mis 10 buffers, mais c'est peut être un peu trop (mais bon, ce n'est que 200 octets par buffer).

[gilles]

Le log est assez similaire, les rattrapages ne se font pas exactement au même endroit mais c'est le même profil, par contre change la fréquence pour 8000 ca sonne plus réaliste... Je suis sûr d'avoir lu 10000 sur une doc mais elle devait être fausse...

[gilles]

Mise à jour CVS et sur le site.
Pour la version WX : intégration de la gestion multi buffer
Intégration de la gestion des K7 WAV
Correction des touches de direction non mappées.

[OlivierP]

Cool, tu as ajouté la gestion de K7 et mappé les chiffres hors pavé numérique.
Il ne manque plus que le memory debugger par rapport à la version allegro, non ?

[gilles]

Il manque encore qqs touches à mapper (je l'ai fait ce matin dans le train). Et aussi améliorer le debugger car il n'est pas totalement utilisable en l'état. Maintenant les 2 versions sont totalement de niveau et la version wx est plus avancée sur la gestion du son.

[jester]

ça avance bien, et comme humeur a diffusé la doc du 3556 tu as tous les éléments en mains... sauf bien sur les particularités non documentés d'Exelvision. Mais on en est tous réduit au même point.
Toutes les docs sont en ligne maintenant. S'il te manque un élément n'hésite pas, mais pour l'émulation Exl100 tu dois être Ok.

[gilles]

Une partie des spécificités est justement documentée dans le doc du TMS3556, dont l'explication de la double lecture pour le RDVDP, il est même écrit que cela doit (peut) être réalisé dans une instruction microcodée du TMS7xxx.
De mon côté j'ai encore un bug qui provoque quelques erreurs en basic (et qui plante VegaX4 à la ligne 520). J'ai un soupçon sur les opérateurs DCB du 7020 mais sans certitude absolue.
Ensuite j'ajouterai la gestion des exelmémoire.
Puis de l'exeldisc mais pas dans l'immédiat.
Ensuite je passe à autre chose... Un peu de code sur exl probablement... et un autre émulateur d'autre chose (j'hésite entre 2)

[jester]

Ahhh VegaX4... The programme qui fout la merde !
Le mec qui l'a programmé connaissait tous les secrets du VDP et des raccourcis possible via le TMS7020. Daniel avait ramé pour permettre l'exécution de ce programme. Le programme type qui montre que même la Doc du 3556 ne suffit pas...
Bon courage !

[Daniel]

Dans KungFu et Vegax4 il y a une lecture non standard de la VRAM. J'ai dû faire un cas particulier dans dcexel pour ces deux programmes. Ca marche bien, mais je ne comprends pas ce qui se passe exactement. La clé du mystère est peut-être dans l'interaction des registres périphériques P39 et P40 avec le VDP. Malheureusement la doc sur le sujet est très pauvre et notoirement insuffisante. Si vous avez des explications, n'hésitez pas à les donner.

[gilles]

mon plantage se fait assez rapidement, je pense qu'il n'interprète pas correctement une ligne du basic, peut être à cause d'un mauvais calcul, le code du 7xxx est maintenant fiable... mais pratiquement non testé pour le DCB et certainement faux sur les cas d'erreur ou aux limites.
La question du microcode et du comportement dynamique du TAL est un autre sujet... pour juste apres la correction de ce bug

[OlivierP]

Et aussi améliorer le debugger car il n'est pas totalement utilisable en l'état.

Oui, le placement des breakpoints ne doit pas être utilisable en l'état.
L'interface devrait être plus intuitive : utiliser une ListBox pour sélectionner une ligne, placer un breakpoint via menu contextuel par clic droit, ...

[gilles]

moi je voyais plutot une fenetre mère (désassemblage et commandes) et d'autres fenetres contextuelles et redimensionnables (dump mémoire, dump mémoire VDP, traces, registres, registres VDP). Que l'on puisse adapter le debugger à la tâche. Chose totalement irréalisable sous allegro avec sa frame unique.

[OlivierP]

C'est encore mieux en effet.