fpCR 3dfx [eng]

What a beautiful optimization for 3dfx drivers of Warp3D !

Some explanations are necessary : the old Gcc 2.90.27 was using a 6 instructions slow routine to round some FPU digit before sending them to the GPU :

This routine is present very often in the whole driver, it got the advantage to be a 100% compatible with the 68030/68882, the 68040 and the 68060.

The trouble is that it is very slow... In fact, it is quite possible to replace it with a single statement : fintrz.x !

But there is alas a but : fintrz is not in the transistors of 68040 ! It is emulated by the 68040.library.

Although present in the 68882 of the 68030, engineers at Motorola had the brilliant idea to reinstate it in the 68060 ! And, sigh, for our case here, we will win many cycles !!

So there had to make a choice with this fpCR routine :

1. Whether kept it as it is for not slow down the 68040
2. Or replace it by fintrz for favorise in speed the 68030 and 68060

It's the second choice which I made : sorry for the 68040 users... It's better to benefit the 68060. Besides, most accelerator cards for Amiga accepts upgrade to 68060, so everyone has the opportunity to use a 060...

After replacing the whole routine by fintrz, the 3dfx driver now weighs 11.3 Kb less !

Having some problems with Ma Config 1, I'm testing everything, and the beta 5 archive will be available soon in Downloads...

(translated by Squaley)

   

fpCR 3dfx [fr]

En voilà une belle optimisation pour les drivers 3dfx de Warp3D !

Quelques explications s'imposent : le vieux Gcc 2.90.27 utilisait une routine lente de 6 instructions pour arrondir certains chiffres FPU avant de les envoyer au GPU :

 

Cette routine est présente très souvent dans l'ensemble du driver, elle a l'avantage d'être 100% compatible avec le 68030/68882, le 68040 et le 68060.

Le soucis, c'est qu'elle est très lente... En fait, il est tout à fait possible de la remplacer par une seule instruction : fintrz.x !

Mais, il y a hélas un mais : fintrz n'est pas dans les transistors du 68040 ! Elle est donc émulée par la 68040.library.

Bien présente dans le 68882 du 68030, les ingénieurs de chez Motorola ont eu la brillante idée de la réintégrer dans le 68060 ! Et ouf pour notre cas ici, nous allons gagner de nombreux cycles !!

Alors, il y a fallut faire un choix avec cette routine fpCR :

1. Soit la garder telle quelle pour ne pas ralentir un peu le 68040,
2. Soit la remplacer par fintrz pour favoriser en vitesse le 68030 et le 68060.

C'est le deuxième choix que j'ai fait : désolé pour les utilisateurs de 68040... Il vaut mieux faire profiter le 68060. D'ailleurs la plupart des cartes accélératrices sur Amiga accepte l'upgrade en 68060, donc chacun a la possibilité d'utiliser un 060...

Après avoir remplacé toute cette routine par un fintrz, le driver 3dfx pèse maintenant 11,3 Ko de moins !

Ayant quelques soucis avec Ma Config 1, je suis en train de tout tester, et l'archive beta 5 sera bientôt disponible en Downloads... 

 

Compiler C/C++ [eng]

Some of you might wonder why disassemble executables ?

Well, simply because our C/C++ compiler produce slow code.

Today I disassembled StarShipW3D which was compiled by Alain Thellier with an old Gcc version, the 2.90.27...

Well, the generated code looks as two peas in a pod like the one from Warp3D. I am almost certain that all the 4.2 version has been compiled at the time with this version of Gcc...

Look now this edifying example in the W3D_Permedia2.library. This is the Per2_SetState function which is concerned. We must understand that our compilers are "mechanical", this means that they convert C/C++ code without thinking !

Per2_SetState weighs 134 bytes :

By looking closely and by understanding the routine, it's clear that we are facing bits tests. By thinking a little bit, it's possible to group all this tests in a single !

Every time a d0 bit is set to one, the routine does a "moveq #0,d0". For a better understanding, simply convert all this comparisons in binary :

• $00002000 = %0000000000000000 0010000000000000 (W3D_BLENDING)
• $00000400 = %0000000000000000 0000010000000000 (W3D_GOURAUD)
• $00000100 = %0000000000000000 0000000100000000 (W3D_TEXMAPPING)
• $00000010 = %0000000000000000 0000000000010000 (W3D_GLOBALTEXENV)
• $00000200 = %0000000000000000 0000001000000000 (W3D_PERSPECTIVE)
• $00000800 = %0000000000000000 0000100000000000 (W3D_ZBUFFER)
• $00001000 = %0000000000000000 0001000000000000 (W3D_ZBUFFERUPDATE)
• $02000000 = %0000001000000000 0000000000000000 (W3D_SCISSOR)
• $00080000 = %0000000000001000 0000000000000000 (W3D_DITHERING)
• $00004000 = %0000000000000000 0100000000000000 (W3D_FOGGING)
• $00400000 = %0000000001000000 0000000000000000 (W3D_ALPHATEST)
• $04000000 = %0000010000000000 0000000000000000 (W3D_CHROMATEST)
• $08000000 = %0000100000000000 0000000000000000 (W3D_CULLFACE)

Then you just need to gather all the different bit to be tested in a single digit, which gives :

• %0000111001001000 0111111100010000 = $E487F10

In order to remove the last "moveq #0,d0", we must inverse this digit with a not.l :

• not.l $E487F10 = $F1B780EF

Here is it a nicely optimised routine which has less of 12 bytes instead of the 134 from the beginning :

Well then, of course, is a rather special case, but nevertheless gives a good idea of human capacities to improve what C/C++ compiler robots does...

An Amiga coder told me that the 68k Macintosh CodeWarrior compiler produced a quality code, which I have not been able to verify...Maybe it should be adapted on ours Amiga ?

So, is that Warp3D will end up being faster overall ?

We muste believe, there's a lots and lots of work anyway !!

(translated by Squaley)

   

Compilateur C/C++ [fr]

Certains d'entre vous se demandent certainement pourquoi désassembler les exécutables ?

Et bien, tout simplement parce que nos compilateurs C/C++ produisent du code lent.

J'ai désassemblé aujourd'hui StarShipW3D qui avait été compilé par Alain Thellier avec une vieille version de Gcc, la 2.90.27...

Et bien, le code généré ressemble comme deux gouttes d'eau avec celui de Warp3D. Je suis donc quasi-certain que toute la version 4.2 a été compilé à l'époque avec cette version-là de Gcc...

Regardez maintenant cet exemple édifiant dans la W3D_Permedia2.library. C'est la fonction Per2_SetState qui est concernée. Il faut bien comprendre que nos compilateurs sont "mécaniques", c'est à dire qu'ils convertissent le code C/C++ en assembleur sans réfléchir !

Per2_SetState pèse 134 octets :

En regardant de plus près et en comprenant la routine, il est clair que nous avons à faire à des tests de bits. En réfléchissant un peu, il est tout à fait possible de regrouper tous ces nombreux tests en un seul !

Puisqu'à chaque fois qu'un bit de d0 est à un, la routine conduit à un "moveq #0,d0". Pour mieux comprendre, il suffit de convertir déjà toutes les comparaisons en binaire :

• $00002000 = %0000000000000000 0010000000000000 (W3D_BLENDING)
• $00000400 = %0000000000000000 0000010000000000 (W3D_GOURAUD)
• $00000100 = %0000000000000000 0000000100000000 (W3D_TEXMAPPING)
• $00000010 = %0000000000000000 0000000000010000 (W3D_GLOBALTEXENV)
• $00000200 = %0000000000000000 0000001000000000 (W3D_PERSPECTIVE)
• $00000800 = %0000000000000000 0000100000000000 (W3D_ZBUFFER)
• $00001000 = %0000000000000000 0001000000000000 (W3D_ZBUFFERUPDATE)
• $02000000 = %0000001000000000 0000000000000000 (W3D_SCISSOR)
• $00080000 = %0000000000001000 0000000000000000 (W3D_DITHERING)
• $00004000 = %0000000000000000 0100000000000000 (W3D_FOGGING)
• $00400000 = %0000000001000000 0000000000000000 (W3D_ALPHATEST)
• $04000000 = %0000010000000000 0000000000000000 (W3D_CHROMATEST)
• $08000000 = %0000100000000000 0000000000000000 (W3D_CULLFACE)

Ensuite, il suffit juste de concentrer tous les différents bit à tester en un seul chiffre, ce qui donne :

• %0000111001001000 0111111100010000 = $E487F10

Afin de pouvoir ôter encore le "moveq #0,d0" final, il faut inverser ce chiffre avec un not.l :

• not.l $E487F10 = $F1B780EF

Voilà donc la routine bien optimisée qui ne fait plus que 12 octets au lieu des 134 de départ :

Bon alors, c'est bien sûr un cas un peu particulier, mais qui donne toutefois une bonne idée sur les capacités humaines à améliorer ce que les robots compilateurs C/C++ pondent...

Un coder sur Amiga m'avait affirmé que le compilateur 68k CodeWarrior sur Macintosh produisait du code de qualité, ce que je n'ai pas encore pu vérifier... Peut-être faudrait-il l'adapter à nos Amiga ?

Alors, est-ce que Warp3D va finir par être globalement plus rapide ?

Faut y croire déjà, il y a encore beaucoup beaucoup de boulot en tout cas !!

 

MC68060FE133 [eng]

Since a while, the Natami Team has succeeded to buy a MC68060FE133 using a QFP240 size, like this photo proves it and which would run at 133 MHz.

Imagine Warp3D with a 68060 at 133 Mhz !!

I had contacted Thomas Hirsch for buying him a exemplary, but no news of him...

In short, I have finally found another one, but smaller, a QFP132 size, that is to say the same as some 68030. I also had to buy this set of five rare adapters QFP => PGA which elsewhere cost me arm and a leg :

With those adapters, it becomes possible to test these MC68060FE133 QFP132 on our 68030 cards :

So, let's weld...

Here, it suffice to plug it now :

Ouch !!!

It's a 68EC030 !!

I have been suckered like a newbie !!

Some people have erased the old mark and inscribed a new one to resell it at high price to idiots like me !

I precise that I'd not had photos of the CPU before buying, but shit anyway...

This time, another test at 60 Mhz on a Blizzard IV :

It works too, but it's very hot at this frequency :

 
Well, it's a fake. Another sword strike in the water and a fortune lost for nothing... I'm going to hang myself...

About the big FE133 QFP240 from Natami, it may actually be a MC68EC060FE50 or a MC68EC060FE75 without MMU nor FPU and also rebadged :

There is a software way of knowing whether these QFP240 MC68060FE133 are true or not : read an internal register called PCR that will give us the answer.

If you have a big MC68060FE133 QFP240, thanks to contact me by email !

(translated by Squaley)

   

MC68060FE133 [fr]

La Natami Team a réussi à acheter un MC68060FE133 au format QFP240 depuis quelque temps déjà, comme le prouve cette photo et qui tournerait à 133 Mhz.

Imaginez Warp3D avec un 68060 à 133 Mhz !!

J'avais contacté Thomas Hirsch pour lui en acheter un exemplaire, mais plus de nouvelles de sa part...

Bref, j'en ai finalement trouvé un autre, mais plus petit, au format QFP132, c'est à dire le même que pour certains 68030. J'ai dû acheter aussi ce lot de cinq rares adaptateurs QFP => PGA qui m'ont coûté la peau des fesses d'ailleurs :

Avec ces adaptateurs, il devient possible de tester ces MC68060FE133 QFP132 sur nos cartes 68030 Amiga à nous :

Allez, soudons... Mais pas comme Khephrens Loewe, hein, qui "soude comme une cochonne", parait-il...

Voilà, il suffit de plugger maintenant :

Arg !!!

C'est un 68EC030 !!

Je me suis fait avoir comme un débutant !!

Certaines personnes ont effacé l'ancien marquage et gravé un nouveau afin de refourguer le tout à prix d'or à des cons comme moi !

Je précise que je n'avais pas eu de photos du CPU avant l'achat, mais merde quand même...

Un autre essai à 60 Mhz sur une Blizzard IV cette fois :

Il fonctionne aussi, mais il est très chaud à cette fréquence :

Bon, c'est un fake. Encore un coup dans l'eau et une fortune dépensée pour rien... Je vais aller me pendre, moi...

Pour ce qui est du gros FE133 QFP240 du Natami, c'est peut-être en réalité un MC68EC060FE50 ou un MC68EC060FE75 sans MMU ni FPU qui a été rebadgé aussi :

Il y a un moyen software de savoir si ces MC68060FE133 QFP240 sont des vrais ou pas : lire un registre interne appellé PCR qui nous donnera la réponse.

Si vous avez un gros MC68060FE133 QFP240, merci de me contacter par email !
 

MUIBuilder [eng]

Do you know the MUIBuilder software (on Aminet) ?

It's a program which allow you to build GUIs on MUI in a few mouse clicks.

Then, once your creation is complete, a click is enough to get the C/C++ source code.

With GLBlitzQuake, there's a bunch of parameters to enter with the game launching, which is fastidious. For myself, I use these ones :

glquake68k_blitz +map dummy -guardband -particles 64 -hicontrast -gamma 0.7 -bpp 16 -width 640 -height 480 -mem 16 -zone 1024 -audspeed 5513 -bpp 16 -nojoy -nocdaudio -nopsx -litfiles -lm_RGB

To ease in a way the GLQuake configuration, I had realised this small GUI :

Knowing very little of C/C++, did a coder could finish it, that is to say adding the game launch, and some other small adjustements here and there ? Contact me by mail, of course !

(translated by Squaley)

   

MUIBuilder [fr]

Connaissez-vous le logiciel MUIBuilder (sur Aminet) ?

C'est un programme qui permet de construire des GUIs sous MUI en quelques clics de souris.

Ensuite, une fois votre création terminée, il suffit d'un clic pour que le source en C/C++ vous soit pondu.

Avec GLBlitzQuake, il y a une foule de paramètres à entrer avec le lancement du jeu, ce qui est assez fastidueux. Pour ma part, j'utilise ceux-ci :

glquake68k_blitz +map dummy -guardband -particles 64 -hicontrast -gamma 0.7 -bpp 16 -width 640 -height 480 -mem 16 -zone 1024 -audspeed 5513 -bpp 16 -nojoy -nocdaudio -nopsx -litfiles -lm_RGB

Afin de faciliter quelque peu la configuration de GLQuake, j'avais réalisé une petite GUI qui voici :

Ne connaissant que très peu le C/C++, un coder voudrait-il la finir, c'est à dire rajouter le lancement du jeu, et quelques autres petits ajustements ici et là ? Me contacter par email, bien sûr !
  

Known bugs [eng]

Here is two known bugs which I met under Warp3D v4.2 : attention, this problems occurs with programs using it but it can maybe come from the Kickstart or the Picasso96 RTG system, hard to know precisely...

The first which come from time to time, fonts become unreadable like here :

The second one happens when GLQuake is launched just after a demo also using Warp3D, like StarShipW3D. Eg, during Timedemo demo1, the benchmark results is lower of 0.5 fps than when using GLQuake and Warp3D for the first time.

For example, I have 21.4 fps during a normal boot. When I restart the Amiga with StarShipW3D and then GLQuake, I have only 20.9 fps...

Maybe a memory management problem from the Picasso96 graphic card ?
 

(translated by Squaley)

  

Bugs connus [fr]

Voici deux bugs connus que je rencontre sous Warp3D v4.2 : attention, ces problèmes apparaissent sous des programmes l'utilisant, mais viennent peut-être du Kickstart ou du système RTG Picasso96, difficile de savoir au juste...

Le premier qui arrive de temps en temps, ce sont les fontes qui deviennent illisibles comme ici :

Le deuxième, c'est lorsque GLQuake est lancé juste après une démo utilisant aussi Warp3D comme StarShipW3D par exemple : lors d'un Timedemo demo1, le résultat du benchmark est inférieur d'environ 0.5 fps que lorsque GLQuake est démarré utilisant pour le tout premier coup Warp3D.

Par exemple, j'obtiens 21.4 fps lors d'un boot classique. Lorsque je redémarre l'Amiga avec StarShipW3D et ensuite GLQuake, je n'ai plus que 20.9 fps...

Peut-être un problème de gestion mémoire de la carte graphique par Picasso96 ?

   

ForceVersion [eng]

ForceVersion is a variable found in ENVARC:Warp3D/ which offers the possibility to select routines of the old version 3.x of Warp3D for some functions :

•  W3D_SetState,
•  W3D_VertexPointer,
•  W3D_TexCoordPointer,
•  W3D_ColorPointer,
•  W3D_DrawArray,
•  W3D_DrawElements. 

Indeed, in the Warp3D library, there is six real time checks of the value of this variable. To select  the old routines of the version 3 of Warp3D 4.2, simply put 3 in ForceVersion or put 4 for the latest ones.

After some tests, here is the results with the new routines of the 4.2 version :

• ForceVersion at 3 (functions using 040/060 CPU) :

GLBlitzQuake with my Config 3 : 73.5 seconds and 13.2 fps
  

• ForceVersion at 4 (functions using the GPU) :

GLBlitzQuake with my Config 3 : 71.1 seconds and 13.6 fps


The results have convinced me to drop all the version 3 code which is slower than the last one in the beta 7. Needless to keep about 22 Kb of slower routines...

The ForceVersion variable has now no longer effect since the beta 7 !

(translated by Squaley)

  

ForceVersion [fr]

ForceVersion est une variable qui se trouve dans ENVARC:Warp3D/ et qui permet de sélectionner des routines de l'ancienne version 3.x de Warp3D pour quelques fonctions :

• W3D_SetState,
• W3D_VertexPointer,
• W3D_TexCoordPointer,
• W3D_ColorPointer,
• W3D_DrawArray,
• W3D_DrawElements.  

En effet, dans la librairie Warp3D, il y a donc six vérifications en temps réel de la valeur de cette variable. Pour sélectionner les anciennes routines de la version 3 de Warp3D v4.2, il suffit tout simplement de mettre 3 dans ForceVersion ou alors 4 pour avoir les toutes dernières.

Après quelques tests, voici les résultats d'avec les nouvelles routines de la version 4.2 :

• ForceVersion à 3 (fonctions utilisant le CPU 040/060) :

GLBlitzQuake avec ma Config 3 : 73.5 secondes et 13.2 fps

• ForceVersion à 4 (fonctions utilisant le GPU) :

GLBlitzQuake avec ma Config 3 : 71.1 secondes et 13.6 fps

Les résultats m'ont convaincu d'ôter tout le code 3 qui est bien plus lent que le tout dernier dans la béta 7. Inutile de garder environ 22 Ko de routines plus lentes...

La variable ForceVersion n'a donc plus aucun effet maintenant à partir de la beta 7 !