.: live transmission :.

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

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...

mercredi 23 janvier 2008

Info: la bonne doc du DSP

La documentation appropriée au DSP 56001 du Falcon 030 est difficile à trouver. Il est assez commun de trouver un fichier nommé DSP56000UM.pdf, mais ce dernier n'est pas adapté au 56001 équipant le Falcon. En plus de cela, il n'y a pas la moindre information sur le port SSI de ce même DSP, prouvant bien que ce n'est pas la bonne document. Mais où la trouver ? En fouinant les sites consacrés au NeXT, j'en ai trouvé un qui Fort heureusement, j'ai trouvé un site qui a archivé la documentation idoine.

Alors, ne prenez surtout pas le fichier DSP56000UM.pdf qui, comme nous venons de le voir, est tout pourri, mais jetez vous sur les fichiers DSP56001UM*.pdf.

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...

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...

lundi 15 octobre 2007

Bidouilles

boing.gifMon Falcon n'étant toujours pas fonctionnel, et la tentation de tartouiller quelques lignes de 68000 sur un Amiga étant assez forte, j'ai déniché une routine d'init dans le diskmag Trashcan #3 et j'ai commencé à jouer un peu avec et à la retoucher pour mes besoins.

Pour l'instant, j'en suis resté à l'initialisation ratée pour un effet, mais j'avais déjà fait ça il y a quelques années sur mon Amiga 600 et je vais m'inspirer des sources que j'ai conservé.

J'en dirai un peu plus sur mes avancées quand ça serait près, avec probablement quelques explications techniques pour les codeurs amateurs.

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 !

mardi 26 avril 2005

Les Gaps, etc

Reprise de l'ancien blog

Voici une petite explication trouvée sur le net par notre ami Skweek: Le formatage physique consiste à ainsi organiser la surface de chaque plateau en entités appelées pistes et secteurs, en polarisant grâce aux têtes d'écriture des zones du disques. Les pistes sont numérotées en partant de 0, puis les têtes polarisent concentriquement la surface des plateaux. Lorsque l'on passe à la piste suivante, la tête laisse un "trou" (appelé gap en anglais) et ainsi de suite. Chaque piste est elle-même organisée en secteurs (numérotés en commençant à partir de 1) séparés entre eux par des gaps. Chacun de ces secteurs commence par une zone réservée aux informations du système appelée préfixe et se termine par une zone appelée suffixe Le formatage de bas niveau a donc pour but de préparer la surface du disque a accueillir des données (il ne dépend donc pas du système d'exploitation et permet grâce à des tests effectués par le constructeur de "marquer les secteurs défectueux.

Donc, les GAPs sont bien des sortes de marqueurs qui se trouvent entre les secteurs d'une disquette !!!

Référence:

Voilà... C'était la minute nécessaire de docteur Frost !