New beta [eng]

A new beta 4 version is available for the Mediator 1200 in the "Downloads" section.

After all the performed work, it's time to do some benchmarks for games with a lot of triangles.
 

Here, it's BlitzQuake which I choosed since it gives quite precise results every time. First with the original version of Warp3D v4.2 on my Config 1 :

And now with the very last versions of the libraries :

When I see all the effort and time of coding to get not even more than one fps, it's annoy a lot...

(translated by Squaley)

  

Nouvelle béta [fr]

Une nouvelle version béta 4 est disponible pour les Mediator 1200 dans la section "Downloads".

Après tout le travail effectué, il est temps de faire quelques benchmarks pour les jeux avec beaucoup de triangles.

Ici, c'est BlitzQuake que j'ai choisis puisqu'il donne des résultats assez précis à chaque fois. Déjà avec les versions Warp3D v4.2 originale sur ma Config 1 :

Et maintenant avec toutes les dernières versions de librairies :

Quand je vois tous les efforts et le temps de coding pour arriver à seulement même pas une seule fps de plus, ça énerve beaucoup...
 

Direct / Indirect [eng]

There is two modes in Warp3D to draw 3D :

1. the direct mode,
2. and the indirect mode.

In direct mode, Warp3D really draws whenever a drawing function is called.

In indirect mode, Warp3D keeps in queue what to draw and executes it :

• during a W3D_Flush,
• when the queue is full,
• when indirect mode comes back manually with W3D_SetSate.

After some tests, indirect mode gives better results for small objects. On the other side, after a number of triangles to draw, the indirect mode gives the same results than the direct mode with our current versions of Warp3D.

Alain Thellier has had a good idea to recompile an indirect version of StarShipW3D and CavalleryW3D (available in the "Download" section), and the results are indeed very interresting with my new beta versions of Warp3D and my GRex 1200 (Config 2).

StarShipW3D with 170 triangles in indirect mode :

While in direct mode :

Now CavalleryW3D with 1090 triangles gives the same results in the two modes, the limit which I was talking about is reached :

With my Config 1, I get :

• StarShipW3D indirect : 225 fps
• StarShipW3D direct : 167 fps
• CavalleryW3D indirect : 43 fps
• CavalleryW3D direct : 43 fps

We have yet a lot of things to understand on Warp3D operations and 3dfx cards with our Amiga....
  

   (translated by Squaley)

  

Direct / Indirect [fr]

Il existe dans Warp3D deux modes pour tracer de la 3D :

1. le mode direct,
2. et le mode indirect.

 

En mode direct, Warp3D trace vraiment chaque fois qu'une fonction de traçage est appelée.

En mode indirect, Warp3D garde une liste (ou plutôt "Queue" en anglais) de ce qu'il faut tracer et ne l'exécute alors que :

• lors d'un W3D_Flush,
• lorsque la liste est pleine,
• lorsque le mode indirect revient manuellement avec W3D_SetSate.

Après quelques tests, le mode indirect donne de meilleurs résultats pour les petits objets. Par contre, après un certain nombre de triangles à dessiner, le mode indirect donne les même résultats que le mode direct avec nos versions actuelles de Warp3D.

Alain Thellier a eu la bonne idée de recompiler une version indirect de StarShipW3D et de CavalleryW3D (disponibles dans la rubrique "Download"), et les résultats sont en effet très intéressants avec mes nouvelles versions bêtas de Warp3D et mon GRex 1200 (Config 2).

StarShipW3D avec 170 triangles en mode indirect :

Alors que là en mode direct :

Maintenant CavalleryW3D avec 1090 triangles donne des résultats identiques dans les deux modes, la limite dont je parlais est atteinte :

Avec ma Config 1, j'obtiens :

• StarShipW3D indirect : 225 fps
• StarShipW3D direct : 167 fps
• CavalleryW3D indirect : 43 fps
• CavalleryW3D direct : 43 fps

Nous avons encore de nombreuses choses à comprendre sur le fonctionnement de Warp3D et des cartes 3dfx sur nos Amiga...

   

Fichy ? [eng]

There's something wrong with 3dfx on our hardware...

I've just look at this video. PC hardware used :

• Pentium 75 Mhz
• 16 Mo Ram
• Pci Voodoo 1 Canopus Pure 3D GPU@50 Mhz with 6 Mo Ram
• Screen size 640x480

 
Now my configuration :

• 68060 95 Mhz
• 64 Mo Fastram
• Pci Voodoo 3 2000 GPU@145 Mhz with 16 Mo Ram
• Screen size 640x480

The PC game is far more faster, I say about 25 fps with far less powerfull hardware than on my Amiga...

The BE => LE conversion needful on Amiga doesn't explain this slowness...

There is a big fishy thing on our side...

(translated by Squaley)

    

Cloche ? [fr]

Y'a quelque chose qui ne tourne pas rond avec les 3dfx sur notre hardware à nous...

Je viens de visionner cette vidéo. Le matériel PC utilisé est :

• Pentium à 75 Mhz
• 16 Mo de Ram
• Pci Voodoo 1 Canopus Pure 3D GPU@50 Mhz avec 6 Mo de Ram
• Résolution 640x480

Maintenant ma configuration :

• 68060 à 95 Mhz
• 64 Mo de fastram
• Pci Voodoo 3 2000 GPU@145 Mhz avec 16 Mo de Ram
• Résolution 640x480

Le jeu PC est bien plus rapide, je dirais du 25 fps avec du hardware bien moins puissant que le mien sur mon Amiga...

La convertion BE => LE de trois instructions nécessaire sur Amiga n'explique en rien un telle lenteur...

Il y a un gros truc qui cloche chez nous...

   

CyberGraphX4 [eng]

While waiting to get back a working Mediator, I've been fooled by a greedy french amiga fan : my CyberStormPPC rev0 which wasn't working with my GRex 4000D for two BlizzardPPC. I still accepted the deal because there was a rev2 essential to get working this time a GRex 1200 bought long before...

Anyway, this will help to work on both library Warp3D Picasso96 and CyberGraphx4 since the Grex works with this RTG.

Indeed, there is at least a good optimization in W3D_Cgfx4_function_1E : most of the trigonometry from the Motorola sources which I had already mentioned in a previous article is present again in W3D_CyberGfx4.library.

While I still don't know why, the emulated square root (fsqrt.d) is present in the motorola part and Warpd3D author have been deceived, in good faith, believing that is was emulated by the 68040 and 68060 : well no, the mnemonic fsqrt is present in the 68881, 68882, 68040 and 68060 chips.

In short, the full part have been deleted and the two connections have been replaced by a purely simple and much faster "fsqrt.d fp0" ...

Otherwise, while waiting for the Mediator and the fusion of LEMU/LE and BEMU/LE library, I replaced two small functions in the W3D_AvengerLE.library (the same that in previous article "The beta 3" under Picasso96) et I get a good speedup too :

Still using StarShipW3D :

Yet, it's a unique case of course : I should understand why the speedup is so important...

This is reverse engineering : start from a result (here compiled libraries with gcc) and  then "back the other way" to understand why and how worked the initial authors and C/C++ compiler...

I already found the datasheets from the Avenger Voodoo GPU which is going to help...

The benchs with GLBlitzQuake ("Timedemo demo1") gives us + 0.4 fps with both new functions, which is a good news, however less impressive...

 

(translated by Squaley)

   

CyberGraphX4 [fr]

En attendant de récupérer un Mediator qui fonctionne, je me suis bien fait rouler dans la farine par un Amigaïste français aux dents très longues : ma CyberStormPPC rev0 qui ne fonctionnait pas avec mon GRex 4000D contre deux BlizzardPPC. J'ai tout de même accepté parce qu'il y avait dans le lot une rev2 indispensable pour faire fonctionner mon cette fois GRex 1200 acheté il y a bien longtemps...

Bref, cela permettra de retravailler les deux librairies Warp3D Picasso96 et CyberGraphX4 puisque le GRex fonctionne avec ce dernier système RTG.

En effet, il y a au moins une belle optimisation dans la W3D_Cgfx4_function_1E : le gros paquet de trigo des sources de Motorola que j'avais déjà évoqué dans un article précédent est présent une nouvelle fois dans la librairie W3D_CyberGfx4.library.

La racine carré émulée (fsqrt.d) est bien dans le paquet Motorola pour je ne sais quelle raison d'ailleurs, et les auteurs de Warp3D ont donc été de bonne foie induit en erreur, croyant par cette présence qu'elle était émulée par les 68040 et 68060 : et bien non, la mnémonique fsqrt est bien dans les transistors des 68881, 68882, 68040 et 68060.

Bref, le paquet au complet a été supprimé et ses deux branchements ont purement été remplacé par un tout simple et bien plus rapide "fsqrt.d fp0"...

Sinon, en attendant le Mediator et la fusion des librairies LEMU/LE et BEMU/BE, j'ai remplacé deux petites fonctions dans la W3D_AvengerLE.library (les même que dans un précédent article "La béta 3" sous Picasso96) et j'obtiens un bon speedup aussi :

C'est toujours StarShipW3D qui est utilisé :

Alors, il s'agit d'un cas exceptionnel bien sûr : il faudrait comprendre pourquoi le speedup est si important...

C'est ça le reverse engineering : partir d'un résultat (ici des librairies compilées avec gcc) et ensuite "remonter dans l'autre sens" pour comprendre le comment du pourquoi ainsi que le pourquoi du comment de ce qui a été créé par les auteurs originaux et le compilateur C/C++ employé...

J'ai déjà trouvé le datasheet du GPU Avenger Voodoo ce qui va bien aider...

Les benchs avec GLBlitzQuake ("Timedemo demo1") donnent un + 0.4 fps avec ces deux nouvelles fonctions, ce qui est aussi plutôt une bonne nouvelle, certes moins impressionnante...

   

Unification [eng]

I was right to compare manualy A1200's and A4000's libraries !

In fact, those Mediators use there own libraries to be able to work flawlessly :

3dfx Mediator A1200T (Picasso96)

• W3D_AvengerBEMU.library (= BigEndian MMU) 
• W3D_AvengerLEMU.library (= LittleEndian MMU)

3dfx Mediator A3000/A4000 (Picasso96) & 3dfx GRex A1200T/A4000 (CyberGraphX)

• W3D_AvengerBE.library (= BigEndian) 
• W3D_AvengerLE.library (= LittleEndian)

Well, looking at the sources carefully, we can see that there are only few differences between thos two libraries : The A1200 version acceses the pci.library when asking a task but the A4000 one do not need to do that. There is also another difference in a little function and... that's all !!

   
The other part of the code is 100% identical !

This is a good news for us in order to put Warp3D into ROM in the future : only one file instead of two is required !

Only two tests need to be coded : one to identify if a Grex is connected, another one to detect if it is an A3000 or an A4000 which is in use. From here, we can orientate/point the code to the A1200's and A4000's libraries spécificities.

(translated by CrashMidnick)

     

Unification [fr]

J'ai bien fait de comparer à la main les librairies 1200 et 4000 !

En effet, ces deux modèles demandaient des versions spécifiques pour fonctionner convenablement :

3dfx Mediator A1200T (Picasso96)

• W3D_AvengerBEMU.library (= BigEndian MMU)
• W3D_AvengerLEMU.library (= LittleEndian MMU) 

3dfx Mediator A3000/A4000 (Picasso96) & 3dfx GRex A1200T/A4000 (CyberGraphX)

• W3D_AvengerBE.library (= BigEndian)
• W3D_AvengerLE.library (= LittleEndian) 

Et bien, en regardant avec attention les sources, les différences sont très minimes : la version 1200 accède à la pci.library pour une demande de renseignement tandis que celle du 4000 non. Il y a aussi une différence dans une autre petite fonction, et c'est tout !!

Tout le reste du code est 100% identique !

Ce qui arrange bien nos affaires quant à la finalité romable de Warp3D : beaucoup de place gagnée dans les eproms maintenant puisqu'il n'y a plus qu'un seul fichier au lieu de deux...

Il va suffir de coder deux tests : un qui détecte si un GRex est branché et un autre pour vérifier si c'est un 3000 ou 4000 qui est utilisé. Ensuite à partir de ces deux résultats, orienter le code vers les spécificités 1200 et 4000 des librairies.

  

The beta 3 [eng]

Good news today ! Do you smell the rubber ?

Speedup is pretty good, see by yourself. I use the little demo called StarShipW3D which is already very fast with original libraries on my setup :

I have chosen to start with StarShipW3D which seems to give us fairly accurate benchmarks...

In comparison, Cow3D is very slow on my setup : I can only reach about 7 fps... I also found a bug inside the program. Press the « B » key to turn the cache on and you will see that the cow has some glitches at some point during a turn and resume its original shape and so on...

Using my new Beta 4 for warp3D.library and the beta 3 for W3D_AvengerLEMU.library, a huge gain of speed can be noticed on our old 68k and 3dfx : + 49 fps !!

 

For the moment, I have reworked about five or six routines related to the W3D_LockHardware and W3D_UnLockHardware functions, more to come soon...

 (translated by CrashMidnick)
  

La béta 3 [fr]

De bonnes nouvelles aujourd'hui ! Ca commence à speeder grave...

L'accélération est plutôt bonne, constatez par vous-même. J'utilise la petite démo StarShipW3D qui est déjà très rapide avec les librairies originales sur ma configuration :

J'ai choisit de commencer par StarShipW3D qui semble donner des benchs constants assez précis... 

En comparaison, la Cow3D est très lente, environ 7 fps sur ma configuration... J'ai d'ailleurs trouver un bug dans celle-ci lorsque l'on appuie sur la touche "B" pour activer un cache : la vache se brouille à un moment pendant un tour et reprends sa forme originale et ainsi de suite...

Avec ma nouvelle beta 4 pour la Warp3D.library et la beta 3 pour la W3D_AvengerLEMU.library, il y a un beau sursaut de nos vieux 68k et 3dfx qui en ont encore dans le slip : + 49 fps !!

Je n'ai surtout retravaillé pour l'instant que cinq ou six routines relatives aux fonctions W3D_LockHardware et W3D_UnLockHardware, more to come soon...

  

Questions ? [eng]

With the well known utility SnoopDos, it seems to be possible to know which libraries are used by which programs what is useful. We can see here that two versions of LE and BE of W3D_Avenger.library are open by the Warp3D.library:

LE and BE letters mean Little Endian and Big Endian. they just are order of reading. For example, the hexadecimal number $12345678 is Big Endian (the same way of reading in french or english language) then Little Endian is $78563412.

PPC and 68k are Big Endian then x86 are Little Endian like the 3dfx by default. There is a needed conversion of BE => LE for our 68040/060 that take a little bit of procesor time because it has to use three instructions (rol.w/swap/rol.w) each time. The 3dfx drivers use about 4440 times these three instructions.

Always with the LibraryTimer utility, I can see that no W3D_AvengerBEMU.library function is called by the game Quake 2!

What's the use of this library? Thank you if you can answer with some commentary if you have the answer or just an idea that can help me to know and understand!

         (translated by johnz)
   

Interrogation ? [fr]

Avec l'utilitaire bien connu SnoopDos, il est possible de savoir quelles librairies sont chargées par tels ou tels programmes, ce qui est bien pratique. Ici, nous pouvons voir que les deux versions LE et BE de la W3D_Avenger.library sont ouvertes par la Warp3D.library :

Les lettres LE et BE signifient Little Endian et Big Endian. Ce sont tout simplement des ordres de lecture. Par exemple, le nombre hexadécimal $12345678 est Big Endian (le même que le sens de lecture de la langue française ou anglaise), alors qu'en Little Endian, c'est $78563412.
   

Les PPC et les 68k sont Big Endian, alors que les x86 sont Little Endian, ainsi que les 3dfx par défaut. Il y a donc une conversion BE => LE nécessaire pour nos 68040/060 qui prends hélas un peu de temps processeur, puisqu'il faut utiliser trois instructions (rol.w/swap/rol.w) à chaque fois. Les drivers 3dfx utilisent environ 4440 fois ces trois instructions de conversion.

Toujours avec l'utilitaire LibraryTimer, je m'aperçois qu'aucune fonction de la W3D_AvengerBEMU.library n'est appelée avec Quake 2 !

A quoi sert cette librairie alors ? Merci de répondre dans les commentaires ci-dessous si vous avez la réponse, ou même un idée qui pourrait m'aider à comprendre !

   

The beta 2 [eng]

The beta 2 is currently only a simple clearing with all internal connections routed through the Function Table too. In fact, here are the main steps that I can use to finally modify the programs as I want:

1. Disassembling a program or a library using InGo (available on Aminet),
2. Correctly format the source obtained using Ced, in order to have a clear listing,
3. Assembling the source using Phxass to check if everything is ok.

From here, the source is readable and writable. As an evidence, the more the ptogram is big, the more the source will be bigger too! For example, the W3D_AvengerLEMU.library has more than 152 610 code lines! I spent many days to put everything in good order, line by line! You have to see it to believe it, trust me... The fat Cosmos is crazy, isn't it?

 

Then, the first thing to do for this kind of very large library is what I call clearing stuff. This step is usefull to remove all unnecessary code, which is not used. As always, with this very same W3D_AvengerLEMU.library; there were many trigonometric math functions that were not in use at all into the library itself. Only two trigos were used. Moreover, all these functions are the same as those already present into the 68040 and 68060.library written by Motorola in 1990/91. In other words, the authors have included all the large package into the whole library. However, keeping only the two useful functions, leads to saving space: the library lost about 25,50 KB. It mean that less loading time is required from hard drive to ram and less fastram used.

It's better than nothing !

(translated by CrashMidnick)
 

La béta 2 [fr]

La version béta 2 est pour le moment un simple débroussaillage avec aussi tous les branchements internes redirigés par la Table de Fonctions (Function Table en anglais). En effet, voici les différentes étapes par lesquelles je peux pour finir modifier les programmes à ma guise :

1. Désassemblage du programme ou de la librairie avec InGo (sur Aminet),
2. Mise en forme du source obtenu avec Ced, de façon à avoir un listing clair,
3. Assemblage du source avec Phxass pour vérifier que tout est correct.

A partir de là, le source est exploitable et modifiable. Plus le programme est gros, plus le source le sera aussi bien évidement ! La W3D_AvengerLEMU.library par exemple fait plus de 152 610 lignes de code !! J'ai mis des jours et des jours à tout bien ordonner, ligne par ligne ! Il faut le vivre pour le croire, croyez-moi... L'est un peu crazy le gros Cosmos !!

  

Ensuite, le tout premier truc à faire pour ce genre de librairie très volumineuse, c'est ce que j'appelle le débroussaillage. Cette étape vise tout simplement à ôter tout le code inutile, celui qui n'est pas utilisé. Toujours avec cette même W3D_AvengerLEMU.library, et bien il y avait de nombreuses fonctions mathématiques trigonométriques qui ne servaient pas du tout dans la librairie. Seules deux trigos étaient utilisées. D'ailleurs, toutes ces fonctions étaient les mêmes que celles présentes dans la 68040 et 68060.library, écrites par Motorola en 1990/91. Bref, les auteurs ont inclus tout le gros paquet dans son entier. Or, en ne gardant que les deux fonctions utiles, en bien la librairie a rétrécie à vue d'oeil, et fait maintenant environ 26,50 Ko de moins.

26.50 Ko de moins, ça fait déjà un peu moins de temps de chargement du disque dur à la ram, et moins de fastram utilisée aussi. Toujours ça d'économiser !

 

LibraryTimer (II) [eng]

Looking closer at the source of the W3D_AvengerLEMU.library, I noticed that the internal functions are called directly by the bsr and not by the FunctionTable:

However, the LibraryTimer patches the library's FunctionTable to insert a counter and even a measure of time. Well, LibraryTimer will not add it in its statistics using this bsr. The solution is simple, just replace it with a jsr, being sure that a6 is the basis address of the W3D_AvengerLEMU.library:

All in all, there were less than a dozen of bsr calls. Now, we have more understandable statistics with LibraryTimer:

The -$3C function seems to be the most used one: it will be necessary to be sly as a fox to reduce instructions as much as possible. Here, every saved cycle is very important.

Here are the new statistics:

• fonction -$24: 382 fois
• fonction -$36: 1 fois
• fonction -$3C: 367 558 fois
• fonction -$5A: 110 fois
• fonction -$90: 23 fois
• fonction -$AE: 1 fois
• fonction -$B4: 845 fois
• fonction -$BA: 884 fois
• fonction -$D8: 2 357 fois
• fonction -$DE: 452 fois
• fonction -$E4: 383 fois
• fonction -$EA: 228 fois
• fonction -$108: 10 fois
• fonction -$10E: 382 fois
• fonction -$114: 383 fois
• fonction -$144: 5 054 fois
• fonction -$14A: 1 fois
• fonction -$162: 354 fois
• fonction -$180: 1 fois
• fonction -$198: 24 233 fois
• fonction -$19E: 113 013 fois
• fonction -$1B6: 150 286 fois
• fonction -$1C2: 6 524 fois

Now, using the very same method for the Warp3D.library, with the same game Quake 2:

• W3D_SetState: 7 932  fois
• W3D_LockHardware: 387 fois
• W3D_UnLockHardware: 386 fois
• W3D_WaitIdle: 386 fois
• W3D_AllocTexObj: 1 fois
• W3D_SetFilter: 3 fois
• W3D_SetTexEnv: 2 318 fois
• W3D_SetWrapMode: 1 fois
• W3D_SetBlendMode: 1 011 fois
• W3D_SetDrawRegion: 387 fois
• W3D_ClearZBuffer: 387 fois
• W3D_SetZCompareMode: 387 fois
• W3D_SetCurrentColor: 4 257 fois
• W3D_DrawTriFanV: 68 170 fois
• W3D_DrawTriStripV: 19 480 fois
• W3D_DrawArray: 142 166 fois

Now, work of re-programming can begin seriously, the coder knows exactly where to start in order to obtain results in terms of speed, visible to the naked eye.

(translated by CrashMidnick)
  

LibraryTimer (II) [fr]

En regardant de plus près le source de la W3D_AvengerLEMU.library, je m'aperçois que les fonctions internes sont appelées directement par des bsr et non par la FunctionTable :

Or, LibraryTimer patch la table des fonctions de la librairie afin d'y insérer un compteur et même une mesure de temps. Avec ce bsr, et bien LibraryTimer ne pourra l'ajouter dans ses statistiques. La solution est simple, il suffit de le remplacer par un jsr en étant sûr qu'a6 soit bien l'adresse de base de la W3D_AvengerLEMU.library :

Il y avait moins d'une dizaine d'appel bsr en tout et pour tout. Maintenant, nous allons obtenir des statistiques plus complètes et plus précises avec LibraryTimer :

La fonction -$3C fait alors son apparition comme étant la plus utilisée : il va falloir ruser comme un sioux afin de diminuer au maximum ses instructions nécessaires. Ici donc, chaque cycle gagné est très important.

Voici les nouvelles statistiques :

• fonction -$24 : 382 fois
• fonction -$36 : 1 fois
• fonction -$3C : 367 558 fois
• fonction -$5A : 110 fois
• fonction -$90 : 23 fois
• fonction -$AE : 1 fois
• fonction -$B4 : 845 fois
• fonction -$BA : 884 fois
• fonction -$D8 : 2 357 fois
• fonction -$DE : 452 fois
• fonction -$E4 : 383 fois
• fonction -$EA : 228 fois
• fonction -$108 : 10 fois
• fonction -$10E : 382 fois
• fonction -$114 : 383 fois
• fonction -$144 : 5 054 fois
• fonction -$14A : 1 fois
• fonction -$162 : 354 fois
• fonction -$180 : 1 fois
• fonction -$198 : 24 233 fois
• fonction -$19E : 113 013 fois
• fonction -$1B6 : 150 286 fois
• fonction -$1C2 : 6 524 fois

Maintenant, très exactement la même méthode pour la Warp3D.library, avec toujours le même jeu Quake 2 :

• W3D_SetState : 7 932  fois
• W3D_LockHardware : 387 fois
• W3D_UnLockHardware : 386 fois
• W3D_WaitIdle : 386 fois
• W3D_AllocTexObj : 1 fois
• W3D_SetFilter : 3 fois
• W3D_SetTexEnv : 2 318 fois
• W3D_SetWrapMode : 1 fois
• W3D_SetBlendMode : 1 011 fois
• W3D_SetDrawRegion : 387 fois
• W3D_ClearZBuffer : 387 fois
• W3D_SetZCompareMode : 387 fois
• W3D_SetCurrentColor : 4 257 fois
• W3D_DrawTriFanV : 68 170 fois
• W3D_DrawTriStripV : 19 480 fois
• W3D_DrawArray : 142 166 fois

Voilà, le travail de re-programmation peut commencer sérieusement, le codeur sait avec précision par où débuter de façon à obtenir des résultats en terme de vitesse visibles à l'oeil nu.

      

LibraryTimer (I) [eng]

LibraryTimer v1.1 is a program available on aminet is really interesting for our goal. It gives the possility to know with accuracy the usage frequency of any kind of Amiga library.

A reminder for beginners: libraries for our Amiga are made of many functions that have a special use. For example, the function R_CacheFlush of exec.library allows to undo everything in the CPU code and data cache. For who is interested in this article: Warp3D drivers have functions too and LibraryTimer allows to know how many time programs using Warp3D (like Quake 2 for example) call a lot of available functions. The use for coders is to rework the most important functions: the ones that are often called. Of course, statistics change according to launched programs and possibly according to a game sequence. So for the time, we launch Quake 2 and its beginning.

Its usage is very easy. You just have to launch the game:

Then go back to the Workbench with Amiga-M then click on LibraryTimer program. Once loaded, you have to choose a library to examinate. For our example, it's WD3_AvengerLEMU.library and after click on "Patch":

Go back to the game, then play it for a short time: something like two minutes in order to have a statistic sample. Go back to the workbench then click on "Update". Here is the number of "calls" displayed for every function (Offset) :

We can already see that few functions are called for the short play of Quake 2. Function -$24 and -$40 have been used 571 time ($23B in hexadecimal) and 572 time ($23C). We can observe that "Time ticks" give the average time taken by the executed function: I don't know now if these results are serious and accurate.

Another function has been used many time. It's the -$6C with 6769 calls ($1A71) :

But there is something stronger for our example! -$19E called 206 387 times ($32633) !! It's incredible! -$1BC and -$1C2 around 108 390 times ($1A766) and 14 307 ($37E3) for the other :

It's perfectly clear: it's -$19E that need to be optimized as much as possible!! it's called by W3D_GetDriverTexFmtInfo from Warp3D.library :

So you have understood: LibraryTimer is useful for locating used function and what's most important the ones that are the most requested.

(translated by johnz)

     

LibraryTimer (I) [fr]

Le programme LibraryTimer v1.1 disponible sur Aminet est vraiment très intéressant pour notre sujet. En effet, il permet de connaître avec précision la fréquence d'utilisation de telle ou telle fonction de n'importe quelle librairie Amiga.

Rappel pour les débutants : les librairies sur nos Amiga sont toutes composées de plusieurs fonctions ayant chacune une utilité bien spécifique. Par exemple, la fonction R_CacheFlush de l'exec.library permet de remettre le code et le data cache du CPU à zéro. Pour ce qui nous intéresse dans cet article aujourd'hui, et bien les drivers Warp3D possèdent eux aussi des fonctions, et LibraryTimer permet de savoir combien de fois les programmes utilisant Warp3D (comme Quake2 par exemple, ou n'importe quel autre) ont appelé chacune de ses nombreuses fonctions disponibles. L'utilité pour le coder est bien sûr de retravailler déjà les fonctions les plus importantes, celles qui sont les plus souvent appelées. Bien évidement, ces statistiques varient suivant les jeux lancés et même peut-être aussi suivant la séquence du jeu. Enfin bref, ici pour le moment, nous prenons Quake2 et le tout début de l'aventure.

Son utilisation est très simple. Il suffit déjà de lancer le jeu :

Ensuite, revenir sous le Workbench avec Amiga-M et cliquer sur le programme LibraryTimer. Une fois celui-ci chargé, il faut tout d'abord choisir la librairie à examiner. Pour cet exemple, c'est WD3_AvengerLEMU.library en cliquant alors après sur "Patch" :

Revenir au jeu, et y jouer pendant une courte durée, comme deux minutes, afin d'obtenir un échantillon statistique. Re-switcher ensuite au Workbench et cliquez sur "Update". Voilà, le nombre de "Calls" s'affiche pour chaque fonctions (Offset) :

Déjà, la constatation criante est que peu de fonctions sont appelées pour la portion de Quake2 jouée. Les fonctions -$24 et -$40 ont été utilisées respectivement 571 ($23B en hexadécimal) et 572 ($23C) fois. Notez que "Time ticks" donne aussi la moyenne de temps qu'a prise la fonction a été exécutée : j'ignore pour le moment si ces résultats sont probants et/ou précis.

Une autre fonction a été utilisé encore bien plus souvent, la -$6C avec 6769 ($1A71) appels :

Mais il y a bien plus fort pour notre exemple ! La -$19E appelée 206 387 ($32633) fois !! Incroyable ! Et les -$1BC et -$1C2 environ 108 390 ($1A766) et 14 307 ($37E3) fois :

Là, c'est clair et net : c'est la -$19E qu'il faut optimiser le plus possible !! Elle est appelée par W3D_GetDriverTexFmtInfo de la Warp3D.library :

Bref, vous l'avez compris, LibraryTimer est très utile pour déjà localiser les fonctions utilisées, et surtout celles qui sont le plus souvent sollicitées.

   

Various libraries [eng]

Here is a summarization of numerous available Warp3D libraries:

3dfx Mediator A1200T v4.2

• W3D_Picasso96MU.library (= MMU)
• W3D_AvengerBEMU.library (= BigEndian MMU)
• W3D_AvengerLEMU.library (= LittleEndian MMU)

• W3D_Picasso96M.library (= noMMU)
• W3D_AvengerBEM.library (= BigEndian noMMU)
• W3D_AvengerLEM.library (= LittleEndian noMMU)

3dfx Mediator A1200T with BlizzardPPC v4.2

• W3D_Picasso96M.library (= noMMU)
• W3D_AvengerBEM.library (= BigEndian noMMU)
• W3D_AvengerLEM.library (= LittleEndian noMMU) 

3dfx GRex A1200T/A4000 v4.2

• W3D_CyberGfx4.library
• W3D_AvengerBE.library (= BigEndian)
• W3D_AvengerLE.library (= LittleEndian)

3dfx Mediator A3000/A4000 v4.2

3dfx Prometheus A3000/A4000 v4.2

• W3D_Picasso96.library
• W3D_AvengerBE.library (= BigEndian)
• W3D_AvengerLE.library (= LittleEndian)

Permedia2 BVision/CyberVisionPPC A1200/A3000/A4000 v4.2

• W3D_CyberGfx4.library
• W3D_Permedia2.library

Virge CyberVision64 3D A1200/A2000/A3000/A4000 v3.0

• W3D_Virge.library

MMU expansion has no link with the 68k physical MMU:

• MMU = Warp3D is passing through P96 to control the graphic memory,
• noMMU = Warp3D use video card memory that is not used by Picasso96.

noMMU drivers won't be supported, there is so many work to do, along with the CyberVision 64/3D that just have 4 Mb of ram.

(translated by johnz)
  

Les différentes librairies [fr]

Voici un récapitulatif des nombreuses librairies Warp3D 68k originales et classées ici en fonction du matériel nécessaire :

3dfx Mediator A1200T v4.2

• W3D_Picasso96MU.library (= MMU)
• W3D_AvengerBEMU.library (= BigEndian MMU)
• W3D_AvengerLEMU.library (= LittleEndian MMU)

• W3D_Picasso96M.library (= noMMU)
• W3D_AvengerBEM.library (= BigEndian noMMU)
• W3D_AvengerLEM.library (= LittleEndian noMMU)

3dfx Mediator A1200T avec BlizzardPPC v4.2

• W3D_Picasso96M.library (= noMMU)
• W3D_AvengerBEM.library (= BigEndian noMMU)
• W3D_AvengerLEM.library (= LittleEndian noMMU) 

3dfx GRex A1200T/A4000 v4.2

• W3D_CyberGfx4.library
• W3D_AvengerBE.library (= BigEndian)
• W3D_AvengerLE.library (= LittleEndian)

3dfx Mediator A3000/A4000 v4.2

3dfx Prometheus A3000/A4000 v4.2

• W3D_Picasso96.library
• W3D_AvengerBE.library (= BigEndian)
• W3D_AvengerLE.library (= LittleEndian)

Permedia2 BVision/CyberVisionPPC A1200/A3000/A4000 v4.2

• W3D_CyberGfx4.library
• W3D_Permedia2.library

 
Virge CyberVision64 3D A1200/A2000/A3000/A4000 v3.0

• W3D_Virge.library

L'extension MMU ici n'a rien à voir avec la MMU physiques des CPUs 68k :

• MMU = Warp3D passe par Picasso96 pour la gestion de la mémoire graphique,
• noMMU = Warp3D prends la mémoire de la carte graphique inutilisée par Picasso96.

Les drivers noMMU ne seront pas supportés, c'est trop de boulot, ainsi que ceux de la CyberVision 64/3D qui ne possède que 4 Mo de video ram à son bord...

   

The 3dfx cards [eng]

Here is a summary of various Pci 3dfx recommended for the Mediator or the GRex. all of them have, at least, 16 Mo of Video memory on board:

• 3dfx Voodoo3 2000 GPU@143 Avenger and 16Mo of SGRam 6ns memory

• 3dfx Voodoo3 2000 GPU@143 Avenger and 16Mo of SDRam 6ns memory

• 3dfx Voodoo3 3000 GPU@166 Avenger and 16 Mo of SGRam 6ns memory

• 3dfx Voodoo3 3000 GPU@166 Avenger and 16Mo of SGRam 6ns memory

• 3dfx Voodoo4 4500 GPU@166 Napalm and 32 Mo of SDRam 6ns memory

• 3dfx Voodoo5 5500 GPUs@166 Avenger and 64 Mo of SDRam 6ns memory

 
Note: The Grex support for the 3D only the Avenger cards.

(translated by johnz)

     

Les cartes 3dfx [fr]

Voici un résumé des différentes cartes 3dfx Pci recommandées pour le Médiator ou les GRex. Elles ont toutes un minimum de 16 Mo de mémoire graphique à bord :

• 3dfx Banshee GPU@100 Banshee et 16 Mo de mémoire Fpm à 25ns

• 3dfx Voodoo3 2000 GPU@143 Avenger et 16Mo de mémoire SGRam 6ns

• 3dfx Voodoo3 2000 GPU@143 Avenger et 16Mo de mémoire SDRam 6ns

• 3dfx Voodoo3 3000 GPU@166 Avenger et 16 Mo de mémoire SGRam 6ns

• 3dfx Voodoo3 3000 GPU@143 Avenger et 16Mo de mémoire SDRam 6ns

• 3dfx Voodoo4 4500 GPU@166 Napalm et 32 Mo de mémoire SDRam 6ns

• 3dfx Voodoo5 5500 GPUs@166 Napalm et 64 Mo de mémoire SDRam 6ns

Note : les GRex ne supportent la 3D que pour les Avenger.
   

Romability [eng]

The romability is the possibility to put a program in the Kickstart rom.

In fact, every programs that everyone of us is using with a Classic isn't romable. A rom is a Read Only Memory.

The big majority of Amiga programs are coded in order to be executed in the ram chip or fast, "peu importe" Gainsbourg :D. Ram accept the reading and the writing of datas.

To make a soft romable, it needs to have a difference in writing. For us, the goal is to modify Warp3D drivers in order to only read their content.

     

Advantages of the romabilty are very important. We have to remember some reasons of the formidable succes of the Amiga 500 at its beginning: it was the simplicity of use. Almost everything was in the Kickstart 1.3 rom and users had a very simple computer to use without installation of additionnal programs. For example the sound driver (audio.device) was inside the kickstart, of course, it was useless to install or load it form a floppy disk or an external hard drive.

When everything is in the Rom, there's just to switch on the machine... and that's all! The computer is ready to work within a fraction of second without any kind of waiting for a loading from an hard disk drive or an USB key...

To cope with an important size of Warp3D drivers, it's possible to compact them in the rom. There's just to add a routine of decompression. At the boot, the content of Warp3D drivers will be unpacked in the fastram in order to make them usable and ready for the OS!

The romability is an important key for unsatisfied users with a Workbench 3.9 difficult to install and to use correctly.

(translated by johnz)
   

Romabilité [fr]

La romabilité est tout simplement la possibilité de mettre un programme dans la rom Kickstart.

En effet, tous les programmes que chacun de nous utilisent sur son Classic ne sont pas romable. Il faut bien voir que la ROM est une Read Only Memory, c'est à dire en bon français qu'elle ne fonctionne qu'en lecture seule.

La très grande majorité des programmes sur Amiga sont codés pour s'exécuter dans la ram (chip ou fast, peu importe) qui, elle, accepte la lecture et l'écriture des données.

Pour rendre donc un soft romable, il est donc obligatoire d'avoir cette différence d'écriture bien en tête, et pour ce qui nous concerne aujourd'hui de modifier les drivers Warp3D afin qu'ils n'utilisent que la lecture en leur sein.

 

Les avantages de la romabilité sont très importants. Rappelons qu'une des raisons du formidable succès de l'Amiga 500 à ses débuts, c'était justement sa simplicité d'utilisation. Presque tout était dans la rom Kickstart 1.3, et les utilisateurs avaient ainsi un ordinateur simple à utiliser, sans installation supplémentaire de logiciels additionnels. Par exemple, le driver sonore (audio.device) était bel et bien dans le Kickstart, nul besoin était de l'installer ou de le charger d'une disquette 3.5, d'un disque dur externe ou que sais-je encore...

Lorsque tout est en rom, il n'y a qu'à allumer la machine... et c'est tout ! L'ordinateur est prêt à l'emploi en une fraction de seconde, sans aucune attente comme un chargement plus ou moins long depuis un disque dur ou même une clé USB...

Pour finir, face à la taille relativement imposante des drivers Warp3D, il est tout à fait possible de les compacter dans la rom bien sûr. Il y a juste une routine de décompression a ajouter, et à l'allumage de la machine, celle-ci décompactera les drivers en fastram afin de les rendre utilisables et disponibles pour le système d'exploitation !

La romabilité est une des clés importantes pour satisfaire les utilisateurs qui ronchonnent en toute légitimité face à un Workbench 3.9 compliqué à installer et à utiliser correctement.