WinUAE et DLL windows
15 sujets de 1 à 15 (sur un total de 17)
- 1
- 2
-
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
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…
à quand une ppc.library custom pour WinUAE
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 ?
>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 chipCa 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
>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
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…
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.
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…)
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
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
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 ?
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
15 sujets de 1 à 15 (sur un total de 17)
- 1
- 2
- Vous devez être connecté pour répondre à ce sujet.
