Virtual Jaguar Rx - R5 - Page 1

Je vous ai fait un "package" de ma version de l'émulateur VJ Rx.

Les nouvelles features sont exclusivement pour le débuggeur, le M68K et le C avec le format ELF/DWARF. Je ne supportes pas les informations de debug d'autres formats.

Pourrais-tu fournir le linker script que tu utilises pour vlink?
De mon côté je n'indique pas de linker script à vlink donc c'est celui par défaut qui est utilisé. Mais ça n'a pas l'air de convenir pour les info de debug. J'ai les warnings suivants:
vlink -b jagsrv startup.o game.o gpu3d.o dsp3d.o jag.o game68k.o ../MyLibs/graphics.a ./u235se/dsp.obj Warning 64: Section game.o(.debug_abbrev) was not recognized by target linker script. Warning 64: Section game.o(.debug_info) was not recognized by target linker script. Warning 64: Section game.o(.debug_line) was not recognized by target linker script. Warning 64: Section jag.o(.debug_abbrev) was not recognized by target linker script. Warning 64: Section jag.o(.debug_info) was not recognized by target linker script. Warning 64: Section jag.o(.debug_line) was not recognized by target linker script.
Pour référence, mon makefile:
OFILES = \ startup.o \ game.o \ gpu3d.o \ dsp3d.o \ jag.o \ game68k.o jag : $(OFILES) vlink -b jagsrv $(OFILES) ../MyLibs/graphics.a ./u235se/dsp.obj M682OBJ = vasmm68k_madmac.exe -quiet -Felf -ID:\cpluscplus\jaguar\jaguar\include -ID:\cpluscplus\jaguar\jaguar\projects\MyInclude $? -o $@ RISCOBJ = vasmjagrisc_madmac.exe -Felf -ID:\cpluscplus\jaguar\jaguar\include -ID:\cpluscplus\jaguar\jaguar\projects\MyInclude $? -o $@ C2OBJ = vc -k -c99 -g -DJAGUAR -O0 -c -o $@ $? # # 68k & gpu jaguar specific asm files # startup.o : startup.s $(M682OBJ) game68k.o : game68k.s $(M682OBJ) gpu3d.o : gpu3d.s $(RISCOBJ) dsp3d.o : dsp3d.s $(RISCOBJ) # # 68k jaguar specific C files # jag.o : jag.c $(C2OBJ) game.o : game.c $(C2OBJ) clean : del *.o del *.bin del *.bin.* del *.cof del *.rom del *.log del *.asm del *.out Par ailleurs j'ai des doutes sur vasmjagrisc_madmac. Dans la dernière version j'ai l'impression qu'il confond l'instruction abs et la directive abs. Il indique une erreur sur l'utilisation de l'instruction "abs registre" en demandant une constante.
J'ai utilisé une version plus ancienne mais j'ai l'impression que ça assemble pas correctement, on ne voit pas la 3D (et justement abs est utilisé avant les divisions pour la projection).
Mais bon, ça je verrai avec l'auteur de vasm.

Dernier truc, en mode debugger la sortie vidéo n'a pas l'air de toujours bien marcher. Bien souvent je ne vois rien (écran noir).
En mode normal la sortie vidéo marche bien.

Je te donnes un exemple d'un script que j'utilises.
Fichier joint : JagELFls_RAM_Debug

De manière générale, si tu as un warning avec un .debug_xyz, tu peux rajouter une section de cette manière.

.xyz 0:
{
*(.xyz)
} >dbg

Pour les options de Vlink: -b elf32jag -T JagELFls_RAM_Debug -EB -e _start

Pour la sortie vidéo du débuggeur, je subodores un problème de sync entre l'init de l'output vidéo et l'init du code. Mon work around serait que tu ouvres la fenêtre de l'output vidéo, après que l'init vidéo de ton code a été faite.
C'est la méthode que j'utilises et cela marche le plus souvent, en attendant que je trouves une solution.

Je vois que tu utilises u235se, j'avais essaye de m'en servir, mais son support ELF a un problème (les symboles ne sont pas reconnus). Si tu trouves un moyen de l'utiliser, cela m'intéresse.

J'aimes beaucoup Vlink et Vasm, j'ai communiqué de temps a autres avec le développeur (Frank). Il répond rapidement en général.
En aparté, Samedi dernier, il y a eu le meeting mensuel de Planet M68K. Le speaker invité était le développeur de VBcc.

Bon, j'ai essayé ton script et les options pour vlink.
Il semble y avoir un problème avec les modules générés par vbcc:
Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. vlink -b elf32jag -T JagELFls_RAM_Debug.txt -EB -e _start startup.o jag.o graphics.o gpu.o dsp.o Error 83: Section <.debug_abbrev> (0x0-0xc3) conflicts with ELF segment < load> (currently: 0x0-0x29b). Error 83: Section <.debug_line> (0x0-0x186) conflicts with ELF segment < load> (currently: 0x0-0x29b). NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1' Stop. Process completed, Exit Code 2. Execution time: 00:00.185
Si je retire les modules en C, ça ne fait plus l'erreur. Mais sans ces modules je ne vais pas bien loin!
Tu utilises gcc? Avec cygwin?

Ma toolchain est basé sur gcc, vasm (v1.8k) & vlink (v0.16h). Je suis en mode command prompt de Windows. J'utilises de temps en temps MSYS2/MinGW64 ou bien MinGW32.
Make 3.81 ou 4.3, mais ca ne fait pas trop de différences. Je n'ai jamais eu ce genre d'erreurs, est-ce que VBcc s'occupe de ELF/DWARF convenablement?

Bonne question! Je ne sais pas si vbcc s'occupe bien de ELF/DWARF.
Je ne vois pas à correspond le ELF segment < load>.

Il y a un moyen d'enlever les avertissements d'écriture à une adresse inconnue ?

DrTypoFr (./6) :
Bonne question! Je ne sais pas si vbcc s'occupe bien de ELF/DWARF.
Je ne vois pas à correspond le ELF segment < load>.

Éventuellement, tu pourrais faire un dump des obj générés par VBcc. Voir aussi si VBcc a besoin d'une option pour générer du ELF ou bien si c'est par défaut.

DEATH (./7) :
Il y a un moyen d'enlever les avertissements d'écriture à une adresse inconnue ?

Non, mais je pourrais rajouter une option pour se faire.

J'ai trouvé un gcc m68k elf en MinGW mais j'ai des doutes sur le code généré...
Voici la commande utilisé dans le makefile:
C2OBJ = m68k-elf-gcc.exe -fleading-underscore -g -ID:\cpluscplus\jaguar\jaguar\include -ID:\cpluscplus\jaguar\jaguar\projects\MyInclude -c $? -o $@
Bon on a des symboles, y'a du progrès:

| | _MainLoop: | | 004058: 4E56 FFE8 LINK.W A6, #$FFE8 | | 00405C: 42AE FFEC CLR.L (A6,$FFEC) == $1FFFD8 | | 004060: 42AE FFF8 CLR.L (A6,$FFF8) == $1FFFE4 | | 004064: 42AE FFE8 CLR.L (A6,$FFE8) == $1FFFD4 | | 004068: 42AE FFF4 CLR.L (A6,$FFF4) == $1FFFE0 | | 00406C: 4878 0960 PEA.L $960 | | 004070: 42A7 CLR.L -(A7) | | 004072: 42A7 CLR.L -(A7) | | 004074: 4879 000F 109C PEA.L _ptrtriclipped | | 00407A: 4EB9 0000 D0C8 JSR.L _Memset64 | | 004080: 4FEF 0010 LEA.L (A7,SINGLE_GO) == $1FFFE4, A7 | | 004084: 4878 0960 PEA.L $960 | | 004088: 42A7 CLR.L -(A7) | | 00408A: 42A7 CLR.L -(A7) | | 00408C: 4879 000F 19FC PEA.L _ptrtriclipped2 | | 004092: 4EB9 0000 D0C8 JSR.L _Memset64 | | 004098: 4FEF 0010 LEA.L (A7,SINGLE_GO) == $1FFFE4, A7 | | 00409C: 23FC 0011 2628 000F 2FFC MOVE.L #$112628, _ptDisplayList | | 0040A6: 206E FFEC MOVEA.L (A6,$FFEC) == $1FFFD8, A0 | | 0040AA: 2208 MOVE.L A0, D1 | | 0040AC: 2001 MOVE.L D1, D0 | | 0040AE: E588 LSL.L #$2, D0 | | 0040B0: 2200 MOVE.L D0, D1 | | 0040B2: 2001 MOVE.L D1, D0 | | 0040B4: E788 LSL.L #$3, D0 | | 0040B6: 9081 SUB.L D1, D0 | | 0040B8: D088 ADD.L A0, D0 | | -> 0040BA: E588 LSL.L #$2, D0 | | 0040BC: 21AE FFEC 09B0 000F 2C5C MOVE.L (A6,$FFEC) == $1FFFD8, (D0.L*1+994396)+0 == $F2C5C | | 0040C6: 206E FFEC MOVEA.L (A6,$FFEC) == $1FFFD8, A0 | | 0040CA: 2208 MOVE.L A0, D1 | | 0040CC: 2001 MOVE.L D1, D0
L'instruction:
| | 0040BC: 21AE FFEC 09B0 000F 2C5C MOVE.L (A6,$FFEC) == $1FFFD8, (D0.L*1+994396)+0 == $F2C5C
déclenche une alerte d'écriture à adresse inconnue.
C'est vraie qu'elle est bizarre cette instruction (indirection sur d0.l+994396? En 68000?)
Dans le désassembleur radare2, sur l'objet game.o, on a pour cette instruction:
move.l -0x14(a6),(d0.l)
Bizarre...

@dilinger: ton compilateur gcc, il vient d'où? Pourrais-tu le fournir?

Il te manque -m68000 et -gdwarf-2

J'ai une collection de gcc 68k. Je les generes moi meme. J'en ai aussi recupere un peu partout.
As tu un serveur FTP?

Avec -m68000 et -gdwarf-2 ça marche!
Enfin le linker s'est plaint que ___mulsi3 manquait mais j'ai trouvé une fonction C qui fait cette opération.
C'est pour multiplier 2 entier 32 bits. J'imagine que gcc ne l'a pas géré car le 68000 ne le fait pas de base... vbcc est moins contraignant là dessus.

Donc là le debuggage source fonctionne. Je peux tracer dans le source C, ce qui est bien!

Pour la sortie vidéo, je ne l'ai pas de façon fiable. J'ai essayé en ouvrant la fenêtre après l'init vidéo mais en général ça ne marche pas, écran noir.

Y'a un autre pb qui subsiste c'est que quand y'a la vidéo, je ne vois pas la 3D. Je vois le titre et le texte. Ca c'est assez bizarre, je vais creuser.

Je n'ai pas de serveur FTP. J'ai un google driver mais il faut un compte google pour y déposer des fichiers.
Sinon y'a transfernow qui permet en mode gratuit de transférer 5 Go de données.

DrTypoFr (./11) :
Avec -m68000 et -gdwarf-2 ça marche!
Enfin le linker s'est plaint que ___mulsi3 manquait mais j'ai trouvé une fonction C qui fait cette opération.
C'est pour multiplier 2 entier 32 bits. J'imagine que gcc ne l'a pas géré car le 68000 ne le fait pas de base... vbcc est moins contraignant là dessus.

Tu peux utiliser les librairies (libgcc (GCC low-level runtime library), libc, et libm) qui viennent avec gcc mais cela implique qu'il a été créer avec les options de configuration adéquates.
Certaines "distributions" de gcc viennent juste avec binutils, le compilateur et c'est tout.

Pour la sortie vidéo, je ne l'ai pas de façon fiable. J'ai essayé en ouvrant la fenêtre après l'init vidéo mais en général ça ne marche pas, écran noir.
Y'a un autre pb qui subsiste c'est que quand y'a la vidéo, je ne vois pas la 3D. Je vois le titre et le texte. Ca c'est assez bizarre, je vais creuser.

Pour l'output video, j'utilises la sortie OpenGL de l'émulateur le même utilisé en mode normal. Il faudrait que j'arrive a répliquer la méthode pour mon vidéo output. Toute aide est la bienvenue d'ailleurs.

Je n'ai pas de serveur FTP. J'ai un google driver mais il faut un compte google pour y déposer des fichiers.
Sinon y'a transfernow qui permet en mode gratuit de transférer 5 Go de données.

Je vais voir ce que je peux faire, mais au moins ton gcc est fonctionnel.

dilinger (./8) :

DrTypoFr (./6) :
Bonne question! Je ne sais pas si vbcc s'occupe bien de ELF/DWARF.
Je ne vois pas à correspond le ELF segment < load>.

Éventuellement, tu pourrais faire un dump des obj générés par VBcc. Voir aussi si VBcc a besoin d'une option pour générer du ELF ou bien si c'est par défaut.

DEATH (./7) :
Il y a un moyen d'enlever les avertissements d'écriture à une adresse inconnue ?

Non, mais je pourrais rajouter une option pour se faire.

Ce qui serait bien c'est la possibilité de pouvoir éditer le contenu de la RAM et de la ROM.

Bon j'ai buildé VJ avec quelques difficultés (vive Qt) mais ça ne marche pas.
Dans mainwin.cpp:
WriteLog("Test pattern 1 bitmap\n"); QImage tempImg(":/res/test-pattern.jpg"); QImage tempImgScaled = tempImg.scaled(VIRTUAL_SCREEN_WIDTH, VIRTUAL_SCREEN_HEIGHT_PAL, Qt::IgnoreAspectRatio, Qt::SmoothTransformation); for(uint32_t y=0; y<VIRTUAL_SCREEN_HEIGHT_PAL; y++) { const QRgb * scanline = (QRgb *)tempImgScaled.constScanLine(y); for(uint32_t x=0; x<VIRTUAL_SCREEN_WIDTH; x++) { uint32_t pixel = (qRed(scanline[x]) << 24) | (qGreen(scanline[x]) << 16) | (qBlue(scanline[x]) << 8) | 0xFF; testPattern[(y * VIRTUAL_SCREEN_WIDTH) + x] = pixel; } }
Il arrive manifestement pas à charger la ressource test-pattern.jpg.
Le pointeur scanline est NULL.
J'ai essayé en mettant un chemin absolu vers l'image, ça ne change rien.

NB: je compile avec VS2017.

J'avais eu ce genre de problèmes par le passé, cela voulait dire qu'une DLL de format d'images manquait. Dans ce cas ci, c'est qjpeg.dll ou qjpegd.dll.
Cette DLL doit être dans le répertoire imageformats.

...
+ imageformats
+ platforms
...
Qt5's required dlls
virtualjaguar.exe

C'était ça! Il manquait qjpegd.dll dans imageformats.
Ca fonctionne, avec l'option --debugger on a bien le debugger qui permet de tracer dans les sources des fichiers elf. Y'a aussi la sortie vidéo qui déconne (ce coup ci on voit que quart inférieur gauche de l'écran zoomé).
Ca valide toutes les dépendances (Qt, SDL ,OpenGL,libdwarf, libelf etc...).

J'espères que les features du debugger te seront utile. Dans Help / Contents, la documentation décrit sommairement les feature.

DEATH (./13) :
Ce qui serait bien c'est la possibilité de pouvoir éditer le contenu de la RAM et de la ROM.

J'ai rentré cette suggestion dans le pool of ideas du git.

C'était ça! Il manquait qjpegd.dll dans imageformats.

Je vais rajouter un détection check et rajouter un message dans le log.

Je regarde cette histoire de sortie vidéo qui ne se rétablit pas.
Quand on ferme la fenêtre de sortie vidéo, la fenêtre est juste cachée, on ne détruit rien. Je ne comprends pas pourquoi on n'a plus la sortie vidéo quand on réouvre la fenêtre...

je crée "simplement" un lien depuis le output OpenGL de l'émulateur mais je penses que, a un moment donné, je perds la synchronisation.

DrTypoFr (./9) :
@dilinger: ton compilateur gcc, il vient d'où? Pourrais-tu le fournir?

J'ai mis gcc 9.4.0 dans un serveur FTP, https://www.transfernow.net/dl/20210604fbsh8cYq

Merci pour cette version récente de gcc. J'ai pu compiler avec.
Faut que je vois pourquoi la 3D n'est pas rendue. Est-ce le code C? Est-ce que le code RISC? A voir...

Pour la sortie vidéo, quand on ferme et réouvre la fenêtre de sortie, le contexte (QGLContext) du GLWidget n'est plus valide.
Pour l'instant ce que j'ai trouvé pour qu'il retombe sur ses pattes c'est de détruire et recréer le GLWidget. Y'a probablement plus propre mais je vois pas trop.
Il reste un autre problème, à la réouverture l'image est zoomée.

Il y a de toute façon un problème de "dégradation" avec le temps. Par exemple mon test Mandelbrot fonctionne correctement le 1er coup. Puis si je le relance il commence à déconner.
Il faut que je relance virtualjaguar pour retrouver un fonctionnement correct.

DEATH (./22) :
Il y a de toute façon un problème de "dégradation" avec le temps. Par exemple mon test Mandelbrot fonctionne correctement le 1er coup. Puis si je le relance il commence à déconner.
Il faut que je relance virtualjaguar pour retrouver un fonctionnement correct.

Est-ce que c'est le même comportement sur la version originale de Virtual Jaguar?

DrTypoFr (./21) :
Faut que je vois pourquoi la 3D n'est pas rendue. Est-ce le code C? Est-ce que le code RISC? A voir...

Est-ce que tu changes de résolution entre l'affichage de tes textes et la 3D?
Est-ce que cela marche avec la version normale de Virtual Jaguar?

dilinger (./23) :
Est-ce que tu changes de résolution entre l'affichage de tes textes et la 3D?
Est-ce que cela marche avec la version normale de Virtual Jaguar?

Le texte et la 3D sont dans le même buffer.
Je ne peux pas tester dans la version normale de VJ, il ne prend pas les fichiers ELF.
Mais je pense que le problème vient plutôt de la compilation C par GCC que de l'émulation. Il y a notamment le pb des multiplications...

DrTypoFr (./24) :
Mais je pense que le problème vient plutôt de la compilation C par GCC que de l'émulation. Il y a notamment le pb des multiplications...

Tu peux trouver les librairies (libgcc (GCC low-level runtime library), libc, et libm) dans le package gcc 9.4.0. libgcc devrait résoudre tes soucis de multiplications.
Ou alors, comprendre pourquoi VBcc te pose problème avec Vlink.

dilinger (./23) :

DEATH (./22) :
Il y a de toute façon un problème de "dégradation" avec le temps. Par exemple mon test Mandelbrot fonctionne correctement le 1er coup. Puis si je le relance il commence à déconner.
Il faut que je relance virtualjaguar pour retrouver un fonctionnement correct.

Est-ce que c'est le même comportement sur la version originale de Virtual Jaguar?

Sur la version 2.1.2 de virtualJaguar il n'y a pas de différence en lançant mon programme plusieurs fois de suite (virtual Jaguar est également 2-3 secondes plus rapide qu'une Jaguar normal)
Le GPU et le DSP ont une très très légère différence de vitesse à peine remarquable
Le compteur FPS reste toujours à ~60FPS

Sur virtual Jaguar Rx au 1er lancement c'est comme virtualjaguar 2.1.2 : 2-3 secondes plus rapide qu'une vraie Jaguar, très très légère différence de vitesse entre le GPU et le DSP et compte FPS à ~60FPS.
Mais dès le second lancement (je clic sur l'icone "Insert cartridge" et je lance le même fichier) le compteur FPS indique ~34FPS et le GPU est beaucoup plus lent que le DSP.
Le GPU finit ~6s après le DSP, ce qui le rend d'ailleurs ~3s moins rapide que sur une vraie Jaguar. Une fois le calcul de la fractal terminer les FPS se stabilise à ~47FPS
Et ça reste comme ça jusqu'à ce que je relance complètement virtualJaguar Rx

Si ça peut t'aider, au niveau des cœurs du processeur (i5-3570) , au lancement de virtualjaguar 2.1.2 sans rien lancer il prend déjà ~5-10% sur 3 processeurs logique et ~20-25% sur le 4ème (à priori ça serait juste l'affichage de la simulation de "neige" sur l'écran qui fait ça)
En lançant mon programme ça ne bouge pas, puis au moment du calcul fractal 3 des processeurs montent à ~20-25-30% (c'est très variable) et le 4ème à ~50-55%.
Quand je clic sur l'icone "insert cartridge" et que virtualjaguar se met totalement en pause, les procs tombent tous à 0%

Sur virtualjaguar Rx j'ai à peut près le même comportement que virtualjaguar 2.1.2 pour le 1er lancement.
Au 2ème lancement le 4ème proc est à près de 100% et reste comme ça tout le temps (sauf en faisant pause), les autres procs montent à ~30-40% lors du calcul fractal.

J'ai rajouté les échanges dans mon git, au moins cela ne sera pas perdu.

Pour la multiplication, avec un test rapide la routine a l'air de bien se comporter. C'est peut-être autre.
Je vais essayer vasm avec vbcc en mode normal (non ELF) pour voir si c'est vasm qui pose pb.

Pour le zoom de la fenêtre de sortie j'ai résolu le pb mais il me semble que j'ai introduit une régression en mode fullscreen. Mais bon c'est pas ma priorité pour l'instant le mode fullscreen.

Bon ben c'est vasm la problème. Je l'ai utilisé à la place de rmac dans mon build non-ELF avec vbcc et y'a pas la 3D.

DrTypoFr (./29) :
Bon ben c'est vasm la problème. Je l'ai utilisé à la place de rmac dans mon build non-ELF avec vbcc et y'a pas la 3D.

C'est étrange, vasm et vbcc sont intimement liés pourtant.
vasm et rmac sont des assembleurs, en théorie tu utilises le même source asm donc, en théorie, le code généré serait le même. Est-ce le cas?