Obligement - L'Amiga au maximum

Jeudi 28 mars 2024 - 18:17  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z,
ALL


Trucs et astuces

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Glossaire

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Le courrier des lecteurs d'Amiga News Tech - octobre 1990
(Rubrique animée par Frédéric Mazué et extraite d'Amiga News Tech - octobre 1990)


Plus sur le Blitter

Fou de programmation en assembleur, j'ai beaucoup apprécié la série d'articles sur le Blitter. J'aimerais cependant en savoir plus sur les points suivants :
  • Programmation du Blitter dans une liste Copper.
  • Obtenir une animation de 50 images/seconde.
  • Animation de BOB, détection des collisions de BOB.
  • Défilement différentiel (!).
Cela peut paraître beaucoup, mais j'espère que vous publierez des programmes d'application sur le Blitter. Je fais confiance à l'ANT pour m'éclairer car c'est le seul moyen que j'ai pour apprendre à programmer sérieusement, la "doc" française étant franchement mauvaise sur ce sujet. Encore bravo et félicitations à l'ANT [Guilbert Cyrille].

Réponse

Programmer le Blitter dans une liste Copper ? Mais rien de plus simple si vous êtes déjà capable d'établir une liste Copper élémentaire du type de celle qui ferait un dégradé de la couleur de fond de l'écran. Si vous savez faire ça (si vous ne savez pas regarder donc mon petit programme du n°21), vous savez que le Copper peut écrire des valeurs dans les registres machine dont font partie les registres du Blitter. Il n'y a donc qu'à initialiser les registres dudit Blitter de cette manière au lieu de le faire par le microprocesseur. Il y a cependant une précaution à prendre : de même qu'il fallait s'assurer que le Blitter ait fini de travailler avant d'y accéder par le 68000, de même, il faut que le Copper s'assure que le Blitter soit effectivement disponible. Pour cela, il suffit de mettre le bit BFD de l'instruction Copper WAIT à zéro. Ainsi, le Copper ne touchera pas le Blitter si celui-ci est occupé. Pour plus de renseignements vous pouvez consulter la Bible de l'Amiga ou l'Amiga Hardware Reference Manual page 31.

Une animation de 50 images par seconde ? Encore plus simple. Il faut savoir que le faisceau d'électrons ("raster") qui crée l'image sur le moniteur "revient" tous les 50e de seconde donc 50 fois par seconde. Chaque fois que le raster est en haut de l'écran, le Copper commence l'exécution de sa liste Copper, on a donc déjà, comme Monsieur Jourdain qui faisait de la prose sans le savoir, une animation de 50 images par seconde !

Dans mon article "Défilement avec le Blitter", le programme lit dans un registre machine la position du raster et le défilement en question est donc lui aussi une animation (certes modeste) de 50 images par seconde. Notez également que l'image qui défile n'est ni plus ni moins qu'un BOB (rudimentaire car à un seul plan de bits) et que l'obstacle est un autre BOB tout simplement immobile. Ce qui a été dit à propos du test de collision est évidemment valable si le deuxième BOB eut été animé. Pour animer des BOB beaucoup plus colorés, il suffit de faire défiler chaque plan de bits avant le passage du raster. Pas de panique, même si le programme paraît très long, le Blitter travaille tellement vite que tout va très bien.

D'autres moyens d'animation ? Reportez-vous à l'article du n°25 "Animation de sprite sous IRQ" où la routine d'interruption IRQ3 est détournée. On peut encore installer un serveur d'interruption du niveau convenable avec exec.library ou faire une requête d'interruption dans le matériel comme expliqué page 61 de l'Amiga Hardware Reference Manual.

En ce qui concerne les défilements différentiels, j'ai donné dans mon article le moyen d'obtenir des vitesses de défilement variables. Il n'y a plus qu'à programmer deux défilements de vitesses différentes lors d'un même passage du raster (on a le temps, le Blitter travaille vite) pour obtenir l'effet recherché. A l'occasion, je vous ferai un petit article d'explication sur les interruptions mais patience, il y a tant à dire sur l'Amiga...

Bloc d'amorce

Cher Frédéric Mazué. Tout d'abord, félicitations pour l'ANT, c'est la partie de Commodore Revue que je préfère. Voici la question que je me pose (ainsi que tous ceux qui veulent écrire leurs propres blocs d'amorce) : quel est l'étrange petit programme qui se trouve sur un bloc d'amorce "normal". J'ai vu qu'il faisait un test, mais je ne sais pas lequel ! Pourquoi n'y a-t-il pas simplement un RTS (4E75) ? [Ewalenko Bernard].

Réponse

L'étrange petit programme en question cherche l'adresse de base de la dos.library ce qui est une manière de vérifier que la structure résidante correspondante est bien installée. Si ce n'est pas le cas, nous aurions une petite méditation du gourou de n°#30000001. Mais alors, me direz-vous, à quoi sert ceci, puisque la dos.library est en ROM et donc qu'elle a 100% de chance d'être convenablement installée ? (remarque ô combien pertinente, d'autant plus que finalement c'est moi qui l'ai faite !). Je pense que ceci est un reliquat de l'ancien temps des Amiga 1000 où le Kickstart était chargé à partir d'une disquette.

Il fallait alors bien vérifier que tout était correct. De cela on peut déduire que le programme d'amorce est un tantinet désuet, mais il ne faut cependant jamais l'omettre car chaque version du Kickstart continue de l'exiger. Chez Commodore, on aime bien tester plusieurs fois une même chose afin d'être bien sûr que tout va bien. Un peu comme ceux qui mettent une ceinture et des bretelles à leur pantalon... Mais j'y pense, dans le Commodore Revue n°20, il y a un excellent article sur les blocs d'amorce et un non moins excellent installateur de bloc d'amorce écrit par un certain EM. Courez l'acheter immédiatement (le Commodore Revue n°20 bien sûr, pas le EM).

Dynamic HAM

Frédéric Mazué, bonjour. Avant tout, mauvaise nouvelle. Bien que cette lettre te soit adressée personnellement, ce n'est pas pour te féliciter, ni pour te poser une question sur tes articles (désolé), mais pour discuter avec toi d'un article paru dans Commodore Revue n°23 pages 72-75, dans lequel l'un de tes confrères dit que le mode "Dynamic HAM" consiste à changer 16 couleurs de la palette tous les 16 points. Ayant moi-même essayé d'en faire autant, j'en suis arrivé à changer seulement une couleur tous les 16 points (haute résolution, deux plans de bits). Qu'en penses-tu ? Ne voulait-il pas plutôt dire 16 couleurs toutes les lignes ? Pourrais-tu envisager de disséquer un peu ce mode graphique, en particulier la structure de la liste Copper associée ?

Ce qui a motivé cette lettre, ce n'est pas le plaisir de mettre Commodore Revue en défaut, mais le désir d'acquérir des connaissances, que je compte mettre en application. Tu te demandes peut-être pourquoi je t'ai envoyé cette lettre à toi personnellement ? Eh bien, pensant (à tort ?) que Laurent Charbonnel était peut-être plus intéressé par l'utilisation des logiciels que par leur programmation, j'ai voulu m'adresser à quelqu'un qui serait sans doute intéressé lui aussi de connaître la réponse à ma question. Or, vu les astuces parfois employées dans tes articles... bref je t'ai choisi [Baudrin Gérald].

Réponse

Fichtre ! Que d'honneur. J'espère que le grand patron lira tout ça, et qu'il se rappellera que m'octroyer une petite augmentation serait vraiment du meilleur aloi car j'en aurais bien besoin pour soigner mon SIDDA (SIDDA = Salaire Inchangé Depuis Des Années). (note du directeur : "je signale à tous les pigistes que je ne suis pas un banquier, mais un homme libre"). Ainsi, il s'agit de discuter, voilà qui convient à merveille à un bavard comme moi, d'autant plus que Commodore Revue n'est pas mis en défaut.

Les 16 premiers registres couleurs sont bien changés tous les 16 points dans ce mode "Dynamic HAM". Comment est-ce possible ? Très simple. En mode haute résolution, l'instruction WAIT du Copper peut être programmée tous les 8 points. NewTek a choisi une bonne solution : utiliser WAIT tous les 16 points. Voilà qui est rusé car l'écran ouvert par DigiView 4.0 est à 4 plans de bits et peut donc théoriquement gérer 16 couleurs et ceci offre la possibilité suivante : le Copper attend que le raster soit en bonne position et lorsque que c'est le cas, il change (car ainsi le veut la liste Copper) les 16 premières valeurs de couleurs dans les registres machine puis il a juste le temps de tester la nouvelle position du raster et ainsi de suite.<

Le moins que l'on puisse dire est que le Copper et les canaux DMA sont accaparés par ce procédé et que la liste Copper est vraiment très longue, ce qui justifie la remarque de Laurent Charbonnel : l'Amiga ne peut plus faire autre chose que de nous afficher une très belle image ! Mais pour ce qui est du nombre de couleurs différentes possibles, il est tellement élevé que je n'ai même pas le courage de faire le calcul.

Votre routine ne marche pas ? Désolé mais c'est normal puisque vous utilisez seulement deux plans de bits donc seuls les quatre premiers registres couleurs seront utilisés, et il n'est plus possible de changer les couleurs que quatre par quatre. De plus, si vous arrivez à ne changer qu'une couleur c'est probablement parce que vous allumez les points dans un seul des deux plans de bits ou bien que vous ne modifiez pas les quatre premiers registres couleur. Par exemple, mettre une valeur dans le registre 31 est inutile car le nombre de plans de bits est insuffisant pour que ce registre ne soit jamais pointé. Voilà.

Amiga qui plante toutes les 5 minutes

Salut Maxou... Mon pote et moi sommes deux fans de l'Amiga. Nous avons quelques questions à te poser.

1. Toutes les 5 minutes environ, nos Amiga plantent : l'écran se vide en gardant la couleur du fond et il n'y a plus rien à faire. C'est comme lorsqu'on désactive les canaux DMA ; y aurait-il un problème de ce côté ?

2. Si tu n'as pas de solutions, la meilleure chose à faire est de sauvegarder nos listings à des intervalles réguliers. Mais encore faut-il y penser. Pourrais-tu nous dégoter une routine qui se chargerait de le faire toutes les 2 minutes par exemple ?

3. D'autre part, nous recherchons une routine permettant de sélectionner des bandes fixes sur l'écran à la manière des menus déroulant sauf qu'ici les menus seront déroulés.

4. N'as-tu jamais songé à l'indépendance de l'ANT ?

5. Nous souhaiterions également de plus amples informations au sujet d'AMOS : peut-on créer aussi rapidement qu'il est dit des jeux et/ou des démos ? Que penses-tu d'un article en détail sur ce langage ?

En espérant que tu répondras prochainement à notre lettre, nous te laissons méditer tel un Gourou en Chaleur [Scrap & Lolo].

Réponse

Je réponds à la place de Max qui, c'est bien connu, en fait toujours un minimum. Vos deux machines ont la même panne ? A mon avis pas de doute, il s'agit du virus Byte Bandit ou d'un de ses clones. Il faut utiliser un chasseur de virus pour nettoyer tout ça. Moi j'aime bien VirusX 4.0 mais il en existe plein d'autres dans le domaine public. Si c'est le Byte Bandit en personne (qui effectivement coupe le DMA après 5 minutes environ), il existe un truc : appuyer sur les cinq touches Alt-Commodore-Espace-Amiga-Alt simultanément ramène l'ordinateur à la vie.

Il n'est pas envisageable de faire la routine de sauvegarde demandée si l'éditeur employé ne possède pas un port ARexx ou n'utilise pas le clipboard.device. Effectivement, il faudrait modifier le programme de l'éditeur lui-même et ce n'est pas très légal sans la permission de l'auteur.

Pour la souris : soit Intuition est utilisé et les IntuiMessages fournissent les coordonnées de la souris si le drapeau REPORTMOUSE est activé, soit il faut aller lire le contenu des registres JOY0DAT ou JOY1DAT dans le matériel.

L'ANT indépendant nous y pensons depuis longtemps mais ce n'est pas encore pour tout de suite, patience...

Format IFF

Je vous remercie tout d'abord pour l'aide que vous m'avez apporté au sujet de mon problème avec le format IFF. Ainsi, j'ai pu commencer à développer une routine d'affichage d'une image IFF en 320x200 et en huit couleurs, mais je souhaiterai que vous me disiez pourquoi elle ne marche pas. De plus, je souhaiterais que vous me disiez comment est structurée la partie BODY du format IFF [Dumont Frédéric].

Réponse

Aaargh ! Ce sympathique lecteur m'envoie un listing de quatre pages ! Il fait beaucoup trop chaud pour que j'ai le courage de m'y plonger. Avis à la population : dans un cas comme ça, il faut envoyer un programme sur disquette.

La partie BODY maintenant. Voyons : huit couleurs impliquent trois plans de bits. Un plan de bits a une taille de (320x200)/8=8000 octets. Comme il y a trois plans de bits, le BODY doit contenir 8000x3=24 000 octets. Maintenant, il faut savoir que l'image est définie ligne par ligne. Ceci veut dire qu'il faut lire les 40 (pour une ligne) premiers octets et les placer dans le premier plan de bits, puis lire les 40 autres et les placer dans le deuxième plan de bits puis encore 40 octets dans le troisième plan de bits et la première ligne de l'image est ainsi reconstituée. Incrémenter les pointeurs et recommencer le processus pour chaque ligne. Pour le reste l'article de Max est très clair.

Sectorise

Bonjour ! Je vous écris au sujet du programme Sectorise de l'ANT de Commodore Revue n°17 (ça fait un bail, pas vrai ?). Ce programme est écrit sous Lattice C. Comme je fais toujours tout dans le mauvais sens, il se trouve que je possède l'Aztec C (v3.40 je crois). Donc, j'aurais aimé savoir si l'adaptation en Aztec nécessite des modifications et si oui lesquelles.

Autre chose de plus technique à vous demander : je possède un Amiga 2000A et à chaque démarrage l'écran s'affiche d'abord vert, puis gris foncé. Alors d'après vous, est-ce que ce vert pourrait provenir d'une panne interne (je pense aux circuits genre Denise et ses copines, ou autres) ? Voilà, j'ai fini, j'arrête de vous embêter et je vous laisse travailler malgré la chaleur... [C. Mathieu].

Réponse

Vous possédez un compilateur Aztec ? Que faire dans un cas comme celui-ci ? Facile : rien. Une source en C doit pouvoir être compilée par n'importe quel compilateur C, c'est un des nombreux avantages du C (pour ceux qui ont de petits moyens, il existe des compilateurs C dans le domaine public). Comme le précise l'auteur de l'article, les instructions #include "proto/dos.h" et #include "proto/exec.h" sont spécifiques au Lattice et vous devez donc les supprimer et rien ne devrait pêcher, quoiqu'avec un Aztec on ne sait jamais... (je ne le referais plus promis). De plus, les fichiers script contenant les commandes de compilation n'iront qu'avec le Lattice. Consultez votre notice pour les commandes de compilation Aztec.

Une couleur jaune, rouge ou... verte est normalement le signe qu'un circuit spécialisé est en panne. Mais dans votre cas, puisque l'ordinateur accepte quand même de fonctionner, il n'y a rien de grave. Peut-être une poussière mal placée ou un circuit mal enfoncé dans son support (si si, ça s'est déjà vu). Remède : ouvrir l'Amiga, le nettoyer avec un pinceau propre (pas de produits nettoyant suspects SVP), appuyer délicatement sur les gros composants noirs avec le doigt afin de les remettre en place et il n'y paraîtra pas. Envisager de donner un grand coup de poing sur l'ordinateur histoire de faire d'une pierre deux coups n'est pas une bonne idée ! (ça aussi c'est du déjà-vu). C'est vrai qu'il fait chaud. Bonsoir.


[Retour en haut] / [Retour aux articles] [Article précédent] / [Article suivant]