WinUAE et DLL windows

15 sujets de 1 à 15 (sur un total de 17)

  • 1
  • 2
  • Gilloo

      #10651

      J’ai lu et relu le code source de WinUAE et j’ai découvert un truc assez intéressant: la possibilité de plugger une dll windows.

      Le code est dans la trappe AHI (audio) $f0ffc0.

      Il y a des limitations:

      coté Windows:

      – windows seulement (pas linux, mac, …)

      – dll 32bits.

      – points d’entrée typés extern “C”

      coté émulation:

      – Les buffers doivent être en CHIP (jusquà 8Mo, on peut voir venir)

      – Les adresses des buffers doivent être la somme de offset entre l’adresse amiga et l’adresse de base CHIP ($00000000) dans l’émulateur.

      – Les registres d1,d2,d3,d4,d5,d6,d7,a1,a2,a3,a4,a5,a6 et a7 peuvent être utilisés (j’ai un doute pour l’utilisation de a7)

      A quoi ça peut servir ?

      Ben à tout, suffit d’avoir des idées :-D

      J’en ai 2: (accéder aux ports usb, et accéder à d’autres fichiers dans windows, par des lecteurs réseau)

      Si cela intéresse quelques uns (ou unes, on peut rêver ;-) ), je peux faire un topic pour obligement ou sur ma page web…

      thellier

        #162991

        Hello

        Je te signale que Wazp3D pour WinUAE utilise ce principe (tout comme Quarktex) ce qui lui permet d’utiliser aussi le renderer:hard de l’opengl de Windows

        Ces 3 limitations que tu cite n’existent pas :

        – Les buffers doivent être en CHIP

        – Les adresses des buffers doivent être la somme de offset entre l’adresse amiga et l’adresse de base CHIP ($00000000) dans l’émulateur.

        – points d’entrée typés extern “C”

        En fait

        1) tu peut transmettre effectivement tes parametres que en commençant à partir du registre d1 (pas d0 comme dans les .library Amiga)

        2) il faut ajouter un “offset” aux adresses reçues depuis WinUAE

        3) Les registres transmis sont réordonnés automatiquement en ordering x86 mais pas le CONTENU des structures transmises

        faut voir dans aminet/wazp3d les fichiers

        winuaenative.h

        soft3d_open_dll.h

        où se trouvent plein de fonctions pratique pour ouvrir/fermer la dll et appeler une fonction x86 = ça évite de mettre de l’ASM dans ton listing

        dllbase=winuae_opendll(“soft3d.dll”);

        winuae_closedll(dllbase);

        voir aussi

        soft3d_functions_glue.h

        avec des functions-glue à la fois x86 et 68k

        soft3d_pc_glue.h

        qui fait l’arrivée des fonctions coté x86

        #define DLLFUNCTION(x) winuae_callnative0(funcptrs[x])

        ASM(APTR) LibSOFT3D_CreateTexture(A1(APTR sc),A2(APTR pt),D1(UWORD large),D2(UWORD high),D3(UWORD format),D4(UBYTE TexFlags))

        {if(dllbase) {DLLFUNCTION(SOFT3D_CreateTextureUAE);} else {return((APTR) SOFT3D_CreateTexture(sc,pt,large,high,format,TexFlags));} }

        /*==========================================================================*/

        APTR SOFT3D_CreateTextureUAE(ULONG d1,ULONG d2,ULONG d3,ULONG d4,ULONG d5,ULONG d6,ULONG d7,ULONG a1,ULONG a2,ULONG a3,ULONG a4,ULONG a5,struct winuae *a6)

        {

        APTR st;

        st=SOFT3D_CreateTexture(AmigaAPTR(a1),AmigaAPTR(a2),d1,d2,d3,d4);

        return(PcAPTR(st));

        }

        Alain Thellier – Wazp3D

        Mdwf

          #162992

          à quand une ppc.library custom pour WinUAE :-D

          Gilloo

            #162993

            Hello Alain,

            Concernant les offsets, ça marche car tu utilises z3offset de la structure passée en a6. or le z3offset est le décalage de la mémoire Zorro3.

            Mon décalage en CHIP avec la fonction 105 permet d’utiliser la partie basse de la mémoire pour les configurations A1000 ou A500 sans extension.

            Les contraintes DMA ne sont pas plus restrictives.

            roo, tu triches, LLc n’est pas Visual Studio :) et les points d’entrées doivent être de la forme.

            extern “C” __declspec(dllexport) int func1(unsigned long *a);

            du coté Amiga, une fois la DLL ouverte on peut chercher les points d’entrée avec ce qui suit

            ; input D1 dllhandle

            ; A0 function or variable name

            ; output D0 function or variable address

            DLL_GetProcAddress

            moveq #101,D0

            jsr $00f0ffc0

            rts

            et

            ; input A0 function address

            ; output D0 return

            DLL_Exec

            moveq #102,D0

            jsr $00f0ffc0

            rts

            pour sauter et exécuter au point d’entrée

            ULONG func1 = DLL_GetProcAddress(“func1”) ;

            placer ce que l’on souhaite dans les registres 68k

            appeler le point d’entrée

            ULONG ret = DLL_Exec(func1) ;

            et c’est tout.

            Pour mes besoins perso, je n’ai besoin que de buffers, pas de structures…

            Mais je regarderais de près ton implémentation 3D, ça peut toujours servir.

            En tout cas je suis content que d’autres utilisent déjà ces fonctions.

            Personne n’a une libusb déja toute faite ? :-D

            thellier

              #162994

              >une ppc.library custom pour WinUAE

              je crois pas que ça vaudrait le coup car l’appel x86 prend un certain temps quand même donc faut réserver ça a des fonctions qui manipulent des milliers d’octets

              UTILISER DU CODE X86 DANS WINUAE

              LE PRINCIPE

              Ca marche avec des . DLL x86 de windows

              Par exemple une dll de 10 fonctions

              On récupérer les adressses des 10 fonctions x86 de la .dll par leur 10 noms

              Donc on se retrouve avec une jump table de 10 pointeurs

              on met les parametres dans d1-d7 a0-a7 et on fait le saut magique dans la fonction x86

              Du coté x86 on a les parametres dans d1-d7 a0-a7 déjà ordonnées en x86 mais pour les pointeurs faut rajouter l’offset

              et faut éventuellement swapper les données transmises par pointeur (cad par reference)

              comme dans aminet/Wazp3D/soft3d_pc_glue.h

              Et ça marche :-)

              A oui je rajoute que (même si c’est parait il aussi possible..) les appels x86 ne peuvent pas rappeler le 68k

              ==> la fonction x86 ne peut pas utiliser amigaos mais juste manipuler les données transmises dans son coin ou avec l’aide de windows

              (note: il est bien évident que si le pointeur est la bitmap de l’écran Amiga dans winUAE alors ça le modifie bien )

              Dans ces fichiers de Wazp3D on trouve plein de fonctions pratiques

              aminet/Wazp3D/winuaenative.h

              aminet/Wazp3D/soft3d_open_dll.h

              qui évitent de mettre de l’asm partout et simplifient grandement le truc

              APPELER UNE FONCTION DLL

              pour appeler une fonction x86 de pointeur funcptr avec 3 parametres v1 v2 v3

              ULONG winuae_callnative3( ULONG funcptr, ULONG v1, ULONG v2, ULONG v3)

              idem de 0 à 12 parametres

              UNE LIBRARY 68k + x86

              Comme les parametres sont déjà dans les registres (mais faut pas utiliser d0 alors) alors on peut faire winuae_callnative0(funcptr); =0 parametres = utiliser ceux déjà dans les registres

              on fait alors un fichier comme le mien aminet/Wazp3D/soft3d_functions_glue.h juste pour aiguiller les appels sur le x86 ou le 68k

              A noter qu’il serait encore plus radical de rajouter une jumptable x86 à la .library en plus de la jumptable 68k existante

              LA DLL

              On créée sa .DLL avec un compilo windows comme LCC-Win32

              OUVRIR LA DLL

              dllbase = winuae_opendll(“soft3d.dll”);

              winuae_getnativeaddrall(dllbase,funcnames,funcptrs,FUNCNB);

              avec funcnames un tableau avec les noms des fonctions de la .dll

              avec funcptrs un tableau avec les pointeur des fonctions à obtenir

              FUNCNB le nombre de fonctions

              Attention: certains compilos rajoutent un _ devant les noms des fonctions de la .DLL ou pas

              FERMER LA DLL

              winuae_closedll(dllbase);

              avec la dllbase obtenue à l’ouverture

              EVOLUTION?

              L’idéal serait de créer carrément un OpenLibrary (en fait un OpenDLL) qui ouvrirait la DLL et renverrait toute la jumptable x86 en une seule fonction :-)


              @Gilloo
              j’ignorais le truc de la chip

              Ca peut me poser problème car si la mémoire manque alors Wazp3D va utiliser la chip et se foutre dedans

              Pour un c2p x86 ce serait bien…

              Alain

              thellier

                #162995

                >roo, tu triches, LLc n’est pas Visual Studio :) et les points d’entrées doivent être de la forme.

                extern “C” __declspec(dllexport) int func1(unsigned long *a);

                >Mode hacker sarcastique : ON

                On s’en fout tu les utilise en ASM donc pas besoin de les caster précisément alors un ULONG fait l’affaire ;-P

                >Mode hacker sarcastique : OFF

                Alain

                Gilloo

                  #162996

                  thellier a écrit :

                  >roo, tu triches, LLc n’est pas Visual Studio :) et les points d’entrées doivent être de la forme.

                  extern “C” __declspec(dllexport) int func1(unsigned long *a);

                  >Mode hacker sarcastique : ON

                  On s’en fout tu les utilise en ASM donc pas besoin de les caster précisément alors un ULONG fait l’affaire ;-P

                  >Mode hacker sarcastique : OFF

                  Alain

                  C’est pas le cast, c’est le dllexport, parce que cela fait belle lurette que le .def est obsolète dans le monde Visual… :-D

                  Pour la chip, je me suis trouvé coincé à essayer de trouver un moyen pour passer les adresses de chaines, la fonction 105 qui renvoie l’offset de l’adresse 0 (donc de la CHIP) rend ce service :) Comme quoi deux points de vue différents peuvent rendre service.

                  A mon avis, si tu ne sélectionnes pas la mémoire Z3 dans la configuration WinUAE, ta dll ne fonctionnera pas.

                  Gilloo

                    #162997

                    Hello Alain, je profite de ce fil pour parler de Warp3D.

                    J’ai donc installé

                    http://aminet.net/package/driver/video/Wazp3D

                    http://aminet.net/package/util/libs/StormMesa_Libs68K

                    et finalement j’arrive à voir

                    http://aminet.net/package/dev/src/Cow3D

                    http://aminet.net/package/dev/src/earth

                    et celui là plante

                    http://aminet.net/package/util/time/4D-Clock

                    Si j’active le JIT, cela plante lamentablement (erreur de l’émulateur et de windows, pas de gourou).

                    Si j’agrandis trop la fenêtre, je vois la scène coupée en deux…

                    Je me demande si j’ai la bonne version de Picasso96 et encore plus si le winUAE que j’ai n’est pas trop vieux…

                    Quelles sont les versions des libraries à vérifier ?

                    Quels sont les autres démos OpenGL à essayer ?

                    Punaise mon PC devient une SGI :)

                    (sachant que le PC est un portable i5 qui dépote…)

                    thellier

                      #162998

                      hello

                      Voici toute ma production

                      http://aminet.net/search?readme=thellier

                      Pour stormmesa vaut mieux utiliser mon update car l’original est plein de bugs

                      http://aminet.net/package/util/libs/StormMesa2010

                      le mieux c’est GlExcess,le jeu Cube,Tuxracer,etc…

                      Y a aussi des demos cools d’OpenGL (=StormMesa) comme atlantis,glutmech,etc…

                      La plupart sont illustrée ici

                      http://thellier.free.fr/Wazp3D_francais.htm

                      Wazp3D supporte le JIT et le rendu hardware dans WinUAE

                      http://www.youtube.com/watch?v=qCis7ZbAjd4

                      En rendu hard tu peut ajouter “Use filtering” c plus beau

                      Y a aussi “renderer: hard” mais il marche qu’en ecran 32bits et est moins rapide que “hard overlay”

                      FPSE (émulateur playstation) marche aussi très bien mais il faut la dernière version du plugin gpuw3d.dll et désactiver “Use ClearDrawRegion”

                      voir réglages de fpse sur la page de wazp3d

                      Si t’as un mail je peut t’envoyer ma dernière version de wazp et agl

                      Alain

                      PS: t’as raison sur l’import de la DLL = j’ai écris trop vite en pensant “du coté Amiga” Mais rien n’oblige à utiliser Visual car LCC peut suffire pour faire une simple .DLL

                      Je trouve le coup de l’offset z3/chip de winuae piegeux car du coté Amiga on sait pas à priori si un pointeur reçu est en chip ou z3 = à l’idéal il faudrait écrire une fonction qui vérifie si un pointeur reçu est dans la plage chip ou autre puis applique le bon offset…

                      thellier

                        #162999

                        Je t’ai mis ma dernière Wazp3D + le dernier StormMesa ici

                        http://thellier.free.fr/Wazp3D.zip

                        C’est la prochaine version v53 donc faut me signaler les erreurs avant que je la mette sur Aminet..

                        BTW Si qqun a un altivec et que la version altivec marche…

                        Alain

                        Gilloo

                          #163000

                          Le http://thellier.free.fr/Wazp3D.zip fonctionne!

                          En fait il faut au moins un WinUAE 2.3.1.b (décembre 2011), car 1.4.4.0 c’est trop vieux (pourtant de 2007 :-))

                          Ca dépote: pas de scintillement, le curseur de la souris peut se placer devant la scène, que du bonheur.

                          Je me demande si on pourrait pas faire des jeux de bagnoles en OpenGL :)

                          thellier

                            #163001

                            Hello

                            Il est vrai que la Wazp3D v53 est encore plus rapide en rendu hard car elle bufferize les drawtriangle/point/ligne en un seul appel x86

                            Comme jeux de bagnole y a juste Gran Turismo dans FPSE qui marche :-) mais il est trop lent chez moi….

                            Sur Os4 y a SuperTuxKart mais il doit avoir un problème de conception ou portage pour être aussi lent…

                            Tu peut aussi tester l’objet porsche dans Microbe3D

                            https://www.amigaimpact.org/modules/newbb/viewtopic.php?topic_id=10300&forum=3

                            Alain

                            Gilloo

                              #163002

                              Tadan!

                              J’ai enfin réussi à capter l’usb du PC proprement et directement depuis ANAIIS. Le schéma qui suit montre toutes les couches logicielles qu’il faut passer. Ce qui expliquerait pourquoi ça rame tant…

                              pilote -> ANAIIS -> hostusb.usbhcd -> winuae -> libusb.alib -> libusb.dll

                              Ce n’est pas simple à expliquer, vu qu’il a fallu composer avec les bogues du SASC, les structures à inverser intel, les arcanes de l’usb, et les bugs de libusb 1.2.6.0.

                              Pourquoi Monsieur SASC ne veut pas un pointeur de structure dans d6 et dans d1 ? Me faire ce coup là après 22 ans d’utilisation intensive, ça fait un gros choc :)

                              Pourquoi usb_control_msg refuse de lire 2 octets ? (ben la parade est de lire 512 octets, la fonction retournant le nombre d’octets lus permet d’ajuster ce que l’on veut, i.e. lire 2 octets :sweat:)

                              Pourquoi faut il utiliser usb_claim_interface() ? et le usb_release_interface() je l’appelle quand :-? ?

                              En plus il n’y a pas beaucoup d’exemples de libusb, sachant que M$ et Apple n’aiment pas que l’on regarde de trop près le contenu de leurs jardins secrets, je soupçonne que quelques menaces de procès dans les dents en ont dissuadé plus d’un.

                              Mais à quoi tout ce binz peut-il servir ?

                              :-D jailbreaker son iPad ? faire des devices pour ANAIIS ? Passer le temps ? Trouver un sujet de conversation pour son psy ? héhé les quatre mon général ;-)

                              Gilloo

                                #163003

                                Les joysticks (avec rumble!) et claviers, souris sont ok!

                                C’est merveilleux de voir ANAIIS fonctionner aussi sous PC, avec la libusb.dll

                                sous WinUAE.

                                Les ralentissements étaient dus à un usage un peu trop intensif de usb_claim_interface/usb_release_interface, maintenant, cela répond très vite.

                                Les imprimantes semblent fonctionner… mais méfiance

                                Les clefs usb et semblables ne fonctionnent pas encore, usb_bulk_read, me retourne -116 (timeout) alors que les usb_bulk_write semblent écrire quelque chose.

                                Reste encore à savoir comment gérer la déconnexion.

                                thellier

                                  #163004

                                  Hello

                                  Ton projet me fait penser: Tu crois que l’on pourrait porter ADB (android debug bridge) sur Amiga OS ?

                                  Ca permetrait de surfer via proxoid et un mobile android :-)Alain

                                15 sujets de 1 à 15 (sur un total de 17)

                                • 1
                                • 2
                                • Vous devez être connecté pour répondre à ce sujet.

                                Forums AmigaOS, MorphOS et AROS Émulation et autres OS WinUAE et DLL windows

                                Amiga Impact