MSX Village forum

Reprise du message précédent

Je post pas ma nouvelle version car ça change rien visuellement, mais j'ai réussi à compresser mes données (voiture & pilote) et à gagner 2 Ko sur ma cartouche ! Ça va me permettre de rajouter quelques tiles et surtout, de finir le code (qui, mine de rien, prend pas mal de place !).

Petite question : Le DIX et DIY du registre R45 peuvent t'il servir pour faire de la symétrie horizontale/verticale ? En gros, est-ce que ça change juste la position d'affichage, ou bien le sens dans lequel l'image est copié ?

La question était de savoir si on pouvait utiliser cette fonctionnalité pour créer des images miroirs. Dommage qu'on ne puisse pas.

Du coup, je trouve pas de solution pour accélérer l'affichage de mes tiles...

(Je vais p'être juste préparer les tiles les plus courants en VRAM)

Si tu copies tes tiles à partir de la RAM (ou de la ROM), il y a une solution.

Il suffit de traiter les données avant de les envoyer vers la VRAM.



En supposant que tout est initialisé correctement, lorsque tu envoies tes données sur le port d'écriture du VDP :



- OTIR va envoyer les données dans l'ordre

- OTDR va les envoyer en sens inverse, générant l'effet miroir que tu recherches



Cependant, il faut alors gérer la copie des tiles ligne à ligne, puisque chaque ligne nécessitera une réinitialisation de l'adresse de la source en mémoire, et de l'adresse de la destination en VRAM.







Pas forcément ... Les éléments de décor symétriques sont une manière facile de gagner du temps dans le design graphique des jeux, mais cela ne veut pas dire pour autant qu'il y a une gestion hardware/software spécifique pour les gérer. Il peut simplement y avoir 2 tiles dans la bibliothèque graphique du jeu, une pour l'originale et une pour l'inverse.

Il n'y a pas de solution hardware.
Il y a des solutions software (notamment celle que j'explique plus haut), mais c'est alors un compromis entre gain de place et gain de temps.

Avec les événements au Japon, ou j'ai ma belle famille et beaucoup d'amis, j'avais plus trop le cœur à programmer, mais la, ça commence à revenir.

Une question pour les pros du hardware MSX : comment fait t'on pour exécuter du code à intervalle régulier ? Pour faire un chronomètre et pour la musique.

Ah ! ... Sujet très intéressant.



L'éxécution d'un code à intervalle régulier est possible à travers la gestion des interruptions. Le Z80 a la faculté, comme beaucoup d'autres microprocesseurs 8 bits de son époque, d'interrompre l'éxécution de son code lorsqu'il reçoit un signal extérieur en provenance d'un périphérique. Il y a plusieurs cas de figure, mais ce qui nous intéresse, c'est que le VDP envoie une requête d'interruption à chaque VBLANK (fin d'affichage de l'écran, juste après le dernier pixel). En pratique, cette interruption est donc générée 50 fois par seconde (dans le cas des MSX en PAL) ou 60 fois par seconde (dans le cas des MSX en NTSC).



Lorsque la requête d'interruption arrive sur le bus du Z80, le Z80 suspend l'éxécution du code en cours et effectue un saut à l'adresse $0038. Lorsque la ROM est présente, cette adresse pointe vers une routine qui gère toute une série de tâches nécessaires au BASIC. Mais avant de faire toute ces tâches, la toute première chose que cette routine fait, après avoir empilé tous les registres, c'est d'appeler par un CALL le hook en $FD9F.



Ce hook, en temps normal, ne contient qu'un 'RET', ce qui renvoie la routine à son point de départ.



Pour profiter de cet appel à intervalle fixe, il suffit donc de positionner en $FD9F une instruction JP $xxxx pour que la routine (terminée par un 'RET') en $xxxx soit exécutée tous les 50e de seconde (ou tous les 60e de seconde). Ou, si la ROM n'est pas présente, d'écrire la routine nécessaire en $0038, sans oublier d'empiler et de dépiler tous les registres.

Non, pas en assembleur.

Du moins, pas directement.



Parce que, ceci dit, il est possible de faire ce que tu décris en assembleur, mais indirectement. Il suffit d'initialiser autant de compteurs que de timers que l'on veut suivre, puis de les incrémenter à chaque interruption (donc tous les 50e ou 60e de seconde), et de tester leurs valeurs pour déclencher les actions prévues.