vendredi 30 mai 2014

MK1 040 in 060 [eng]

The CyberStorm MK1 require a different CPU module depending on the 040 or 060 installed on it... At last required !

I was thinking about making a special 68040 version of the W3D_AvengerLE.library without the fintrz emulation of the 040 (see the past article) but with this new hack, I hesitate... Maybe the users should upgrade their cards with 68060 which would bring a better confort...

Indeed, Musicman, has found the required modifications for the 040 modules to accept 060 ones !

First of all, weld the regulator, put the JMP on 3.3v, also the three diodes near the CPU support and install the 27C256 eprom like this :

Then, cut the trace here :

And scratch the PCB surface which gets to the hole :

Then, use a cable to link the hole with the second component from above :

To end, it's needed to lift the second pin of this 74F257A and connect it with the last one of his row :

Et voilà, it works very nicely : however the card refused to overclock at 60 Mhz or more but work perfectly at 50 Mhz.
 
(translated by Squaley)
     

MK1 040 en 060 [fr]

Les CyberStorm MK1 nécessitent un module CPU différent selon le 040 ou 060 installé dessus... Enfin nécessitaient !

Je pensais faire une version spéciale 68040 de la W3D_AvengerLE.library sans le fintrz émulé par les 040 (voir l'article d'il y a quelque temps) mais avec ce nouvel hack, j'hésite... Autant pour les utilisateurs d'upgrader leurs cartes en 68060 qui apportent un meilleur confort d'utilisation général...

Musicman a en effet trouvé les modifications requises pour que les modules 040 acceptent un 060 !
 
Il faut déjà souder le régulateur, positionner le JMP sur 3.3v, ainsi que les trois diodes près du support CPU et installer l'eprom 27C256 comme ceci :

Ensuite, il faut couper une piste ici :   
Et gratter le vernis de la piste menant au trou :

Ensuite, relier un câble du trou au deuxième composant du dessus :

Pour finir, il est nécessaire de soulever la seconde pinoche de ce 74F257A et la raccorder à sa dernière sur la même rangée :

Voilà, ça marche impec : petit bémol toutefois, la carte refusait l'overclocking 60 Mhz ou plus, mais fonctionne très bien à 50 Mhz.
 

jeudi 29 mai 2014

New bug ! [eng]

A new bug found in GLBlitzQuake, with the original Warp3D v4.2 libraries and a 3dfx graphic card, in the same room and side by side :

White stripes appear... With the AGA version of Frank Wille and PXLComputer, no bug...

Right next :

Points appear here, then there should be an opening...

With the Permedia2 drivers, the opening is there :

On the other side, the other white stripes bug is there too...

It's seems that this or these bug(s) are in W3D_AvengerLEMU.library and W3D_Permedia2.library than in GLBLitzQuake itself...
 
(translated by Squaley)
     

Nouveau bug ! [fr]

Un nouveau bug trouvé dans GLBlitQuake, à deux endroits avec les libraries originales Warp3D v4.2 dans la même salle côté à côté avec une carte vidéo 3dfx :

Des barres blanches apparaissent... Avec les versions AGA de Frank Wille et de PXLComputer, aucun bug...

Juste à côté :

Des points apparaissent ici, alors qu'il devrait y avoir une ouverture...

Avec les drivers Permedia2, l'ouverture est bien présente :

Par contre, l'autre bug des barres blanches est bien là aussi...

Il semblerait que ce ou ces bug(s) soit dans les W3D_AvengerLEMU.library et W3D_Permedia2.library plutôt que dans GLBLitzQuake lui-même...
     

mercredi 21 mai 2014

Swizzle [eng]

I'd already talked about this in a previous article : the 3dfx video cards were produced for the gigantic PC market which is the one of Little Endian.

Yet, our 68k are Big Endian, which causes a necessary data conversion with three instructions : ror/swap/ror...

Of course, this essential instructions already take CPU time and also weighs 6 bytes for every conversion in Warp3D !

Looking more closely the 3dfx datasheet, there's a bit called Swizzle which allows to change the GPU internal registers in Big Endian :

And it works !!

Yes, after some changes, this bit works nicely and it's now possible to remove all the ror/swap/ror conversions from the W3D_AvengerLE.library and W3D_AvengerLEMU.library !

The GPU "becomes" in a way Big Endian, what suits us !

So I made a very nice optimization : 22,2 Kb of saved on the library ! Yes, you still have read it well, there was 22,2 Kb of ror/swap/ror inside, and they are all wiped out now !! Clear off !

A big THANK YOU to 3dfx engineers who have made a nice job !

You still have to be patient, I'll put the new versions in Downloads soon...

(translated by Squaley)
     

Swizzle [fr]

J'en avais déjà parlé dans un précédent article : les cartes vidéo 3dfx ont été à la base construite pour le gigantesque marché du PC qui lui est Little Endian.

Or, nos 68k sont Big Endian, ce qui entraîne une nécessaire conversion des données avec trois instructions : ror/swap/ror...

Bien sûr, ces trois instructions indispensables prennent déjà du temps au CPU et pèse aussi 6 octets à chaque conversion dans Warp3D !

En regardant de plus près le datasheet des 3dfx, il existe un bit appelé Swizzle qui permet de changer les registres internes du GPU en Big Endian :

Et ça fonctionne !!

Oui, après quelques modifications, ce bit est bien opérationnel et il est maintenant possible d'ôter toutes les conversions ror/swap/ror des W3D_AvengerLE.library et W3D_AvengerLEMU.library !

Le GPU "devient" en quelque sorte Big Endian, ce qui nous arrange bien !

J'ai ainsi pu commettre une très belle optimisation : 22,2 Ko de gagner sur la librairie ! Oui, vous avez encore bien lu, il y avait 22,2 Ko de ror/swap/ror dedans, et qui ont donc tous dégagés maintenant !! Allez, du balais !

Un grand MERCI aux ingénieurs 3dfx qui ont fait du bon travail !

Un peu de patience, je vais mettre les nouvelles versions en Downloads bientôt...
 

vendredi 16 mai 2014

Warning [eng]

!! Warning !!

It seems that assholes are using another mail than mine to get people believe
that I'm the one who is writing

I only use one and only one email : cosmos [dot] amiga [at] gmail [dot] com
 
If you receive a message from another email than this one : It's somebody else than me...


!! Warning !!

(translated by Squaley)
     

Attention [fr]

!! Attention !!

Il semblerait que des connards utilisent un autre email que le mien pour
faire croire que c'est ma personne qui vous écrit
  
Je n'utilise qu'un unique et seul email : cosmos [dot] amiga [at] gmail [dot] com

Si vous recevez un message d'un autre email que celui-ci : c'est quelqu'un d'autre que moi...

 
!! Attention !!
   

bug fix [eng]

Good news today with a bug found in the W3D_Picasso96MU.library

The W3D_Picasso96.library and W3D_CyberGfx4.library are not concerned.

I had already mentioned in a former article there is some time : when I launched GLBlitzQuake just after a boot, I had planned fps. By cons, when I booted up another program just before Warp3D as Cow3D for example, then I was getting about 0.5 fps less with the same GLBlitzQuake...

Well, the bug was in the memory management of the 3dfx : and more precisely in the W3D_P96MU_AllocVMem function !

Note that I'm not sure about my fix, I'm working with a disassembled source : however with it, I always get the same fps result with GLBlitzQuake

For now with that big bug "patched up", the W3D_Picasso96MU.library goes to final release 4.3 !

W3D_Picasso96MU.library 4.3 :
  • fix W3D_P96MU_AllocVMem
  • correct _EndMarker
  • sections removed
  • all functions aligned with cnop 0,4
  • all jsr => bsr.w/.l
  • a lot of absolute addresses turned PC relative
  • unused code removed
  • all internal bsr functions are now called by jsr jmptable (LibraryTimer)
  • W3D_P96MU_AllocVMem optimized
  • W3D_P96MU_CheckBitmapVisible optimized
  • W3D_P96MU_Close optimized
  • W3D_P96MU_CreateContext optimized
  • W3D_P96MU_Expunge optimized
  • W3D_P96MU_LockHardware optimized
  • W3D_P96MU_Open optimized
  • W3D_P96MU_UnlockHardware optimized
  • W3D_P96MU_Version optimized
  • 1724 bytes saved
(translated by Squaley)
     

bug fix [fr]

Bonne nouvelle aujourd'hui avec un bug trouvé dans la W3D_Picasso96MU.library.

Les autres W3D_Picasso96.library et W3D_CyberGfx4.library ne sont pas concernées...

J'en avais déjà parlé dans un ancien article il y a quelque temps : lorsque je lançais GLBlitzQuake juste après un boot, j'avais les fps prévus. Par contre, quand je démarrais un autre programme Warp3D juste avant, comme Cow3D par exemple, j'obtenais alors environ 0.5 fps de moins avec ce même GLBlitzQuake...

Et bien, le bug était dans la gestion de la mémoire des 3dfx : et plus précisément dans la fonction W3D_P96MU_AllocVMem !

Noté que je ne suis pas certain de mon fix, je travaille avec un source désassemblé : néanmoins avec, j'ai maintenant toujours le même résultat fps avec GLBlitzQuake !

Avec ce gros bug "rafistolé" pour l'instant, la W3D_Picasso96MU.library passe en version finale 4.3 !

W3D_Picasso96MU.library 4.3 :
  • fix W3D_P96MU_AllocVMem
  • _EndMarker correct
  • toutes les sections ôtées
  • toutes les fonctions alignées avec cnop 0,4
  • tous les jsr convertis en bsr.w/.l
  • beaucoup d'adresses absolues maintenant PC relative
  • code inutile ôté
  • toutes les fonctions bsr internes sont maintenant appellées par jsr jmptable (LibraryTimer)
  • W3D_P96MU_AllocVMem optimisée
  • W3D_P96MU_CheckBitmapVisible optimisée
  • W3D_P96MU_Close optimisée
  • W3D_P96MU_CreateContext optimisée
  • W3D_P96MU_Expunge optimisée
  • W3D_P96MU_LockHardware optimisée
  • W3D_P96MU_Open optimisée
  • W3D_P96MU_UnlockHardware optimisée
  • W3D_P96MU_Version optimisée
  • 1724 octets d'économiser
  

mercredi 14 mai 2014

FastPatchQuake [eng]

FastPatchQuake 1.0 (on Aminet) is a patch which accelerate in a quite interresting way Quake and mostly GLBlitzQuake under Warp3D.

The author, a French, says he has fixed a bug that proves especially in rooms with torches. This has the effect of speeding up the game.

After a classic "Timedemo demo1", we get a good +0.5 fps anyway :

The most spectacular are in levels that include a lot of torches. For example, at the very beginning by making a "TimeRefresh", the results become very interesting :

And with :

To activate the patch, just copy the "fast" folder of the archive in the directory of GLBlitzQuake and add "-game fast" after the game exe !

EDIT : As Vincent said in comment, integrate this patch directly in the pak file is a better idea. The new pk0.pak update is available in Downloads...
 
(translated by Squaley)
     

FastPatchQuake [fr]

FastPatchQuake 1.0 (sur Aminet) est un patch qui accélère de façon intéressante Quake et surtout GLBlitzQuake sous Warp3D.

L'auteur, un français, nous dit qu'il a fixé un bug qui se révèle surtout dans les salles comportant des torches. Ce qui a pour effet d'accélérer le jeu.

Après un classique "Timedemo demo1", nous obtenons un bon +0.5 fps quand même :

Le plus spectaculaire, ce sont dans les niveaux qui comportent beaucoup de torches. Par exemple, au tout début en faisant un "TimeRefresh", les résultats deviennent très intéressants :

Et avec :

Il suffit pour activer le patch, de copier le dossier "fast" de l'archive dans le directory de GLBlitzQuake et d'ajouter "-game fast" après l'exe du jeu !
   
EDIT : Comme le disait Vincent en commentaire, intégrer ce patch direct dans le fichier pak est une meilleure idée. Le nouveau pk0.pak updaté est disponible dans les Downloads...
    

mardi 13 mai 2014

Some benches [eng]

Here is some benchmarks now that a lot of work has been done...

The W3D_AvengerLEMU.library v4.3 final is available since a few days et brings a welcome speedup for us fan of the Classics...

However, there is little change for now :
  • correct _EndMarker
  • sections removed
  • all functions aligned with cnop 0,4
  • all jsr => bsr.w/.l
  • removed many unused trigos routines
  • a lot of absolute addresses turned PC relative
  • _FunctionTable now relative (.w)
  • library now 100% PC relative
  • all fpCR replaced with fintrz for the 060
  • misc Fpu optimizations
  • many useless code removed
  • all nop removed
  • _ChangesSetupMode optimized
  • LEMU_CheckIdle optimized
  • LEMU_WaitIdle optimized
  • 56 072 bytes saved

I changed some settings on Ma Config 1 including the TLFSMem 1.9 patch which brings a better fastram management, especially with the only 64 MB of Apollo 1260...

I still use Ma Config 1 with the following softwares and Warp3D v4.2 :
  • GLBlitzQuake : 19.4 fps ("Timedemo demo1")
  • Quake2 : 12.6 fps ("Timedemo 1" and "map demo1.dm2")
  • StarShipW3D v1.1 : 86 fps
  • CavalleryW3D v1.1 : 31 fps
  • Cow3D v5.0 : 6 fps

Now only the changed v4.3 :
  • GLBlitzQuake : 21.5 fps
  • Quake2 : 14.5 fps
  • StarShipW3D v1.1 : 327 fps
  • CavalleryW3D v1.1 : 63 fps
  • Cow3D v5.0 : 14 fps

Hum, 327 fps yet quite constant :

If you knew all the time and all the knowledge it takes to achieve all that...

There's still a lot of work to obtain the target of at least 25 fps with GLBLitzQuake ...

(translated by Squaley)
     

Quelques benchs [fr]

Voici quelques benchmarks maintenant que beaucoup de travail a été réalisé...

La W3D_AvengerLEMU.library v4.3 finale est dispo depuis quelques jours et apporte un peu de speedup plus que bienvenu pour nous les fans des Classics...

Il y a toutefois peu de changement pour l'instant :
  • _EndMarker correct
  • toutes les sections ôtées
  • toutes les fonctions alignées avec cnop 0,4
  • tous les jsr convertis en bsr.w/.l
  • ôter beaucoup de fonctions trigos inutilisées
  • beaucoup d'adresses aboslues maintenant PC relative
  • _FunctionTable relative (.w)
  • la librairie est maintenant 100% PC relative
  • tous les fpCR remplacés par des fintrz pour favoriser le 060
  • diverses Fpu optimisations
  • beaucoup de code inutile ôté
  • tous les nop ôtés
  • _ChangesSetupMode optimisée
  • LEMU_CheckIdle optimisée
  • LEMU_WaitIdle optimisée
  • 56 072 octets d'économiser
 
J'ai changé quelques paramètres sur Ma Config 1 avec notamment le patch TLFSMem 1.9 qui apporte une bien meilleure gestion de la fastram, surtout avec seulement les 64 Mo de l'Apollo 1260...

J'utilise donc toujours Ma Config 1 avec les softs suivants et Warp3D v4.2 :
  • GLBlitzQuake : 19.4 fps ("Timedemo demo1")
  • Quake2 : 12.6 fps ("Timedemo 1" et "map demo1.dm2")
  • StarShipW3D v1.1 : 86 fps
  • CavalleryW3D v1.1 : 31 fps
  • Cow3D v5.0 : 6 fps

Maintenant avec seulement la v4.3 de changée :
  • GLBlitzQuake : 21.5 fps
  • Quake2 : 14.5 fps
  • StarShipW3D v1.1 : 327 fps
  • CavalleryW3D v1.1 : 63 fps
  • Cow3D v5.0 : 14 fps

Hum, 327 fps pas encore tout à fait constant :

Si vous saviez tout le temps et toutes les connaissances qu'il faut pour être arrivé à tout cela...

Y'a encore beaucoup de boulot en tout cas pour obtenir l'objectif d'au moins 25 fps avec GLBLitzQuake...
 

vendredi 9 mai 2014

4589 nop [eng]

The nop instruction from the 68k means no operation : that is to say it doesn't compute anything...

There were a total of 4589 in W3D_AvengerLE.library and W3D_AvengerLEMU.library ! Yes,yes, you read that right : 4589 in each one of it !!

They were placed immediately after each write in a register of the 3dfx GPU :

So why add all these nop ? No clue, it must be remembered that Warp3D has been compiled in 2002 : maybe by this time the pci.library from Médiators demanded it...

On the 060, nop also flush the write buffer... and it need 9 cycles to be run by the CPU

Meanwhile the pci.library has continued to evolve, and the last available version on the builder website since a few time is the v9.9.

Well, all these nop can simply be removed now ! Good riddance !!

Yet, the library has been alleviated of no less than 9Kb, and I have a gain of 0.7 fps under GLBlitzQuake

Great !!
(translated by Squaley)
     

4589 nop [fr]

L'instruction nop des 68k signifie no operation : c'est à dire qu'elle ne fait aucun calcul...

Il y en avait en tout 4589 dans les W3D_AvengerLE.library et W3D_AvengerLEMU.library ! Oui, oui, vous avez bien lu : 4589 dans chacune d'entre elles !!

Elles étaient placées juste après chaque écriture dans un registre du GPU 3dfx :

Alors pourquoi avoir rajouté toutes ces nop ? Aucune idée, il faut déjà bien se rappeler que Warp3D 4.2 a été programmé en 2002 : peut-être qu'à l'époque la pci.library des Médiators l'exigeait...

Sur 060, nop flush aussi le write buffer... et coûte 9 cycles pour s'exécuter par le CPU !

La pci.library quant à elle a continué à évoluer depuis, et la dernière version disponible il y a peu est la v9.9 sur le site du constructeur.

Et bien, tous ces nop peuvent être purement et simplement ôtés maintenant ! Allez, bon débarras !!

Déjà, la librairie s'en trouve allégée d'un peu plus de 9 Ko, et je gagne environ 0.7 fps sous GLBlitzQuake...

Super !!