.: live transmission :.

Aller au contenu | Aller au menu | Aller à la recherche

vendredi 11 février 2011

Norwegian Kindness par Spaceballs

Sortie à la Datastorm 2011, une nouvelle démo Amiga par le groupe Spaceballs, ceux-là même qui sont à l'origine de la SOTA...

Demain, ce sera au tour de la démo d'Epadrena ! Et sinon, il y a encore des gens qui suivent ce blog ?

jeudi 19 février 2009

Les évolutions de vasm

J'avais déjà repéré vasm voici quelques temps, mais je l'avais plus ou moins laissé de côté.

Pratiquement un an a passé depuis ma dernière investigation et entre temps Frank Wille a gommé la plupart des défauts que je lui avais trouvé, et en a profité pour complètement l'améliorer. On peut penser que le travail de MiKRO et de Frank pour porter vbcc sur Atari a dû largement aider la cause.

Lire la suite...

dimanche 22 juin 2008

Adebug arrivera-t-il un jour sur CT60 ?

Pour reprendre ce que j'ai déjà posté ailleurs...

Je travaille depuis quelques temps sur une version 2.14 d'Adebug qui supporte le 68060. J'ai plutôt bien avancé mais je me heurtais à des problèmes durant mes tests ; je viens de me rendre compte seulement aujourd'hui que les problèmes que je rencontre sont dûs à Magic !!! En fait, sous TOS normal, le debugger se comporte à peu près bien.

Pour résumé les problèmes sur lesquels je suis tombé : Bugs Adebug 060 sous Magic: - plante sur ILLEGAL, mais breakpoints OK - Plante en quittant dès lors qu'un programme est chargé

Bugs sous TOS: - Quitte OK - Quitte le programme User suite à un illegal, mais rend la main

J'essaye donc de comprendre pourquoi ça marche sous TOS et pas sous Magic, quelque chose m'échappe. Il faudra que je teste sous MiNT à l'occasion pour voir si j'ai les mêmes problèmes. J'espère corriger ces problèmes bientôt, pour faire une release et pouvoir m'attaquer à autre chose.

Et pour ceux qui n'ont pas suivis, la vesion 2.13 est sortie sous licence GPL il y a un peu plus d'un an. C'est disponible ici : adb_2_13.zip.

mercredi 5 mars 2008

Le cross-assembleur de rêve: vasm !

Il y a des soirs comme ça qui réservent plein de surprises !

Ce soir, sans trop y croire, j'ai jeté un oeil à vasm de Frank Wille, déjà auteur de PhxAss, un assembleur pour Amiga très performant, quasi 100% compatible avec Devpac, mais malheureusement absolument pas portable car écrit lui-même en assembleur.

Puis est venu vasm pour offrir un assembleur au compilateur vbcc du Dr. Volker Barthelmann. Cet assembleur est capable de générer du code pour différents processeurs, dont la série des 680x0 de Motorola. Avec son copain vlink, l'éditeur de lien, on peut générer des exécutables pour Amiga ou Atari ST (avec les symbôles siouplé !). La dernière fois que j'ai regardé, il manquait le support des macros, et contacté à ce sujet, Frank Wille m'a répondu que c'était l'affaire d'une soirée ou deux.

Un an est passé.. Et Frank Wille a donc passé une soirée sur vasm et a implémenté le support des macros !

Partons donc pour une petite description de la procédure de compilation sous Linux et un brin de mise en oeuvre.

Lire la suite...

jeudi 27 décembre 2007

Le rotozoomer de la Fantasia

Il était une fois un codeur dont le nom de scène est Oxbab, alors encore membre de Diamond Design. Ce groupe était actif sur Atari ST et a notamment collaboré avec Oxygene avant de ne faire qu'un avec ce dernier sur Amiga AGA, puis sur PC.

Diamond Design avait sorti en 1992 une démo appelé Brace. La démo était distribuée sous la forme d'une disquette normale sur laquelle se trouvait différents programmes TOS. Cette disquette était venue à point nommé lorsqu'il fallait coder un effet de rotozoom pour la Fantasia...

Lire la suite...

mardi 13 novembre 2007

Programmer sur Amiga (part II)

La suite de nos aventures sur la programmation de l'Amiga. Dans cette partie, nous allons faire un petit tour des outils disponibles sous forme commerciale (si l'on peut encore parler ainsi en 2007), ou dans le domaine public. Les choses sérieuses vont commencer dans la partie suivante.

Lire la suite...

lundi 12 novembre 2007

Un bien bel objet

Le processeur Motorola 68010 est le second rejeton de la famille des processeurs m68k.

Sorti en 1982, soit trois ans après le premier 68000, le processeur n'apporte pas de différence significative par rapport à son prédécesseur, mais quelques petites améliorations nécessaires à certains industriels :

  • meilleure gestion de la meilleure virtuelle, en conjonction avec une MMU dédiée ;
  • ajout du registre VBR, pour Vector Base Register, permettant de placer la table des vecteurs d'exception n'importe où en mémoire ;
  • passage de l'instruction MOVE from SR en superviseur, rendant l'utilisation de ce processeur impossible sur ST, ou du moins les premiers ;

Et surtout, les performances globales se sont vues améliorées de part l'optimisation du core, à ajouter à l'ajout d'un minuscule cache permettant d'améliorer le temps d'exécution de petites boucles.

MC 68010

Je n'ai plus qu'à lui trouver un Amiga 500 d'accueil et voir si j'y gagne au change...

vendredi 2 novembre 2007

Programmer sur Amiga (part I)

Après quelques semaines de tatonnement, j'ai réussi à programmer quelques petites choses inutiles sur mon Amiga. Voici le récit de mes aventures, sous la forme d'un petit mémento à l'attention de programmeur connaissant déjà la programmation du 68000.

Lire la suite...

jeudi 27 septembre 2007

En ouvrant le courrier...

Après avoir récupéré ma voiture au garage et payé une note assez salée, j'ai été consolé par l'arrivée d'un petit courrier qui fait plaisir. Il s'agit d'un objet tout bête mais totalement geek sur lequel j'ai craqué sur ebay.

pocketguide_thumb.jpg

Merci monsieur le facteur !!! Merci ma puce pour la mise en scène !!

(Toute ressemblance avec un blog existant ou ayant existé est purement fortuite)

mardi 28 août 2007

Amycoders, le retour !

Il y a quelques années, le site Amycoders centralisait des articles écrits par des codeurs Amiga renommés, on y trouvait notamment beaucoup de choses sur le 68060. L'ancien site non maintenu est doucement remplacé par un Wiki, simplement intitulé Amycoders.

Une saine lecture pour occuper les longues soirées d'hiver.

jeudi 12 mai 2005

Le clipping facile en 68000

Sur le forum "Coding" de dhs.nu, Peter se demandais à quoi pouvait bien servir les instructions CHK et CHK2. Ces instructions ont l'air plus ou moins inutiles aux yeux de beaucoup (dont je fais partie)... Et pourtant... Leonard/OXG nous explique une utilité possible de ces instructions, notamment pour réaliser une routine de clipping optimisée. Je cite:

I don't know that game code, but these intructions "may" be usefull for special ultra-optimisation :-) Explain:

In my fast mandelbrot routine, I use the instruction TRAPV. TRAPV flush an exeption if overflow flag is set. If not, it only takes 4 cyles. In a standard mandelbrot set, you have to check an exit condition at each iteration, and generally do 30 to 100 iterations before one and only exit. So using trapv takes only 4 cycles per iterations, instead of 8 for a BVS branch.

Anyway, I don't know the CHK timing instruction but it may be 4 cycles if CHK dn,dn exist. So in a loop where the exit condition does not occur very often ( say a 2d dot clipping routine), CHK may be usefull. ( again, IF it takes 4 cycles. If not, it's useless)

<lèche-bottes>
Ô maître Leonard, tu es grand !
</lèche-bottes>

Edit
Voici le détail de l'instruction CHK:
CHK - Check Against Bounds
This instruction checks its first operand against a data register's word contents. If the data register contains less than zero or greater than its first operand, a trap to the address specified by vector 6 occurs. Thus, CHK can be used to ensure that an element of an array is neither below nor above its boundaries. Syntax: CHK bounds, Dn where bounds is anything except an address register. Flags affected: All flags are undefined after this operation.

En français et en clair, cette instruction est effectivement toute adaptée au clipping. L'instruction teste si le registre de données (apparemment la seconde opérande) est inférieur à zéro ou bien supérieur au premier opérande, si oui le 68000 va déclencher une interruption type CHK (vecteur en $18). Donc, si le point ne doit pas être clippé, l'instruction consomme 12 cycles en tout, mais s'il doit être clippé, c'est 44 cycles + le temps d'exécution de la routine d'interruption + le RTE. Merci Leonard !