N'exagérons rienjester a écrit :Mais Fabrice nous fabrique une extension 4Go pour les infothicaires + un contrôleur SATA/USB.


Modérateur : Politburo
Sur l'EXL100 physique les deux programmes fonctionnent en utilisant ces adresses.jester a écrit : Il faudrait juste tester sur la vraie machine si un branchement à l'adresse présumée de début de programme fonctionne: Sous le BASIC tu peux faire un CALL EXEC(40844) pour tester CB5QUAD et CALL EXEC(32784) pour tester QUIZZY. ça marche très bien de cette manière... donc c'est peut être juste lié à un problème d'exécution via l'outil de mise au point de l'émulateur.
Pour Quizzy, pas vu de différence (identique à la ROM cartouche): il y a surement une page d'explication dans le langage EXLQUAD (mais pas dans le code du jeu).
Si tu as d'autres programme plus intéressant, il sera donc facile de les lancer sans EXELQUAD. Tu trouveras l'adresse de la première instruction en BFFD normalement (au moins pour les jeux, je rentrerais pas dans les détails): il faut ajouter +1 pour avoir l'adresse exacte.
J'ai également pensé à un conflit avec la ROM Exelbasic. Je vais tenter une autre approchejester a écrit :IMAGIX ça doit être un problème de pagination, comme tu lances une commande à partir de la ROM (BASIC) la RAM exeldisk est inaccessible, alors qu'ExelQuad doit fixer la pagination par défaut sur la RAM exeldisk => on pointe donc dans le décor (en ROM) lors d'appel aux instructions DOS pour la zone de travail. ça doit se résoudre facilement sans passer par le basic !
Aucun des jeux en .BKP stocké en CRAM ne fonctionne par cet appel alors qu'ils fonctionnent tous sans problème sur un EXL100 physique.jester a écrit :Je n'ai pas bien compris ce qui ne marche pas avec l'émulateur: la CALL (32768) ?
Je ne pense pas que ceci explique cela. Il est curieux de voir souvent pointées ces différences de versions pour expliquer des bugs de l'émulateur. En fait, je pense que ce sentiment vient du fait que des problèmes existaient (vraiment) avec les versions antérieures et sur l'EXL135. J'en ai fait la douloureuse expérience à l'époquejester a écrit : C'est intéressant car cela pourrait expliquer les corruptions entre exeldisk et exelmémoire. Si tu as un moment l'exeldos 1.5 serait vraiment vital pour circonscrire le bug.
Oui, cela doit être assez péniblejester a écrit :De toute manière j'ai rencontré de nombreux problèmes avec l'exelmémoire dans DCEXEL... la gestion de ce support semble très fragile. Il faut croiser les doigts à chaque écriture sur le support... et une copie de fichiers de l'exelmémoire sur l'exeldisk (ou le contraire) résulte automatiquement dans la corruption d'un des deux supports... sympa !
Le problème est réel c'est indéniable et je n'ai rien à prouver à Daniel, qui est libre d'ignorer mes retours d'information.jester a écrit : Daniel a beau dire que ça marche... en langage scientifique je dirais qu'il y a une couille. Daniel corrige très vite les bugs mais il faut lui prouver que le problème est réel et que ça vient de son émulateur...
C'est clair. Cela dit, le 7041 renferme bien des secrets dont l'importance n'est pas des moindre.jester a écrit : Ce bug dans la gestion mémoire est assez critique (plus que le VDP ou le 7041)...
Oui, sur EXL100, il y a une musique aussi bien pendant la page d'accueil que pendant le déroulement de l'épreuve. Le jeu est d'une rapidité normale et aucun crash constaté pendant et après l'épreuve. Je n'ai pas décortiqué le jeu, cela dit la musique pourrait bien venir du port K7 (en jouant avec le bit 3 du port et le Timer du CPU) plutôt que du TMS5220. Cela permettrait d'ailleurs de pouvoir voir cette fonction implémentée sur l'émulateur. D'après ce que j'ai pu lire, Daniel n'avait pas d'exemple de logiciel exploitant le port K7. Cela dit, j'avais proposé voila un bout de temps un programme développé par les créateur d'EXL100 qui montrait comment se servir du port K7 pour faire de la musique, mais apparemment cela ne l'avait pas intéressé...jester a écrit :Il y a du son ? sur l'émulateur il y a des parasites en fond (bloc bloc... blouc... bloc) sans interruption.
Le jeu est-il rapide ? c'est d'une lenteur atroce (moins rapide qu'un programme en BASIC) sur l'émulateur...
Et ça plante avant la fin (programme gelé !).
(j'ai lancé sur l'adresse >8000)
Il se peut que des avancées de l'émulateur m'échappent, il faut dire que je m'en sert très peu. Si cela fonctionne, c'est une bonne chose. Je viens en effet de le lire dans l'historique des mises à jour. Comme j'avais lu sur l'autre forum qu'il manquait matière à tester cette fonctionnalité, je me suis dit que la fonction n'était pas encore prête. Si elle fonctionne bien, le problème est ailleurs ouijester a écrit :La gestion du son sur port K7 est implanté depuis 2 versions sur l'émulateur... ça marche dans toutes les applications (BASIC et jeux assembleurs).
...Et pourtant, cela fonctionnejester a écrit :Par contre ce qui est incompréhensible c'est qu'un CALL(32768) fonctionne... si je regarde le contenu de la mémoire à cet endroit j'y vois des instructions incohérentes dont des trap 0... je ne comprends pas comment ça peut marcher sur une vraie machine ??????? Ou bien la présence de la cartouche exelQUAD/exelTEL (avec son électronique supplémentaire modifie le comportement de l'engin)... je ne sais pas si elle étais connecté lors de tes tests. Seul le jeu de ski possède une vraie instruction de branchement en 32768.
Oui effectivement...Fabrice Montupet a écrit :Pour faire les CALL EXEC, seule la cartouche Exelbasic est insérée... puisque c'est le but de l'opération.