+- EmuNewz Network (https://www.emunewz.net/forum)
+-- Forum: PSP Emulation (https://www.emunewz.net/forum/forumdisplay.php?fid=191)
+--- Forum: JPCSP Official Forum (https://www.emunewz.net/forum/forumdisplay.php?fid=51)
+---- Forum: svn trunk discussion (https://www.emunewz.net/forum/forumdisplay.php?fid=56)
+---- Thread: Development offering (/showthread.php?tid=5928)
Pages:
1
2
RE: Development offering - soywiz - 07-31-2011
I have moved my tests to the new project and added an external to dpspemu. http://code.google.com/p/pspautotests/
Also I have added several of the jpcsp owners as owners of the project (feel free to add the people you think can help with this).
At the moment, most of the tests uses a pspDebugPrintf + Kprintf. The main problem is that psp doesn't run them on usermode.
Maybe we can hook normal printf output to a file like SDL does, or output via Kprintf on emulators. Or maybe a simple approach could be to have a special file: for example ms0:/__testoutput.txt that would be hooked by emulators and interpreted as testing output.
Also we have to check several tests.
For example. My CWD tests expects the program to be here 'ms0:/PSP/GAME/virtual':
http://code.google.com/p/pspautotests/source/browse/trunk/pspautotests/io/cwd/cwd.expected
Since my VirtualFileSystem is pretty flexible, allows to mount filesystems on any folder like *nix does. So I mount 'ms0:/PSP/GAME/virtual' on the executable folder on homebrew applications, also disallowing the access of the parent's root folder.
To have universal tests we should agree in some conventions like that.
RE: Development offering - soywiz - 08-01-2011
I have updated pspautotests. In the end I have decided that a good way to have psp-compatible executables in usermode and allow to output to a simple hookable file is doing the following:
- Try to open "emulator:/Kprintf" file. If the file was able to open, that means that we are running the program in a compatible emulator. If not, we are on a psp.
- Hook the stdout FILE handle.
- If we are in a compatible emulator, we will send printf output to the "emulator:/Kprintf" stream.
- If we are on the PSP, we will output the contents to 'ms0:/__testoutput.txt'.
- Also we will output all the stuff using pspDebugScreenPrintf. So if we have a display, we will be able to see the output directly.
- If we are on the PSP, the program will wait until the user press X button, so we can see the output on the display.
You can see the implementation here:
http://code.google.com/p/pspautotests/source/browse/trunk/pspautotests/common/common.c
http://code.google.com/p/pspemu/source/detail?r=303
RE: Development offering - soywiz - 08-01-2011
I have recently implemented the vfpu VFIM instruction on my emulator. And in the process I have seen a couple of things I want to notice:
http://code.google.com/p/pspautotests/source/browse/trunk/pspautotests/tests/cpu/vfpu/vfpu.elf
- On my constant's test. This is my output:
inf,1.414214,0.707107,1.128379
0.636620,0.318310,0.785398,1.570796
3.141593,2.718282,1.442695,0.434294
0.693147,2.302585,6.283185,0.523599
0.301030,3.321928,0.866025,0.000000
- But on jpcsp the output is:
340282346638528859811704183484516925440.000000,1.414214,0.707107,1.128379
0.636620,0.318310,0.785398,1.570796
3.141593,2.718282,1.442695,0.434294
0.693147,2.302585,6.283185,0.523599
0.301030,3.321928,0.866025,0.000000
It seems that the "inf" (infinity constant) is different.
I tried to run it on my psp to check the real behaviour. But it crashes at the begining. Do you know what could be the problem?
Also, implementing the VFIM instruction I have seen that you are storing the output as if it was VD. But the register number is getted from the place of the VT register. It is really using the VD register? Because if not, prefixes could get wrong. Probably the VD in a different offset, but I wanted to be sure and to avoid headaches in the future. We can also make a test for all the vfpu missing stuff including that. Testing all the instructions, with all the special cases, with prefixes and for example verifying that prefixes only affects to one instruction...
RE: Development offering - hlide - 08-02-2011
(08-01-2011, 04:01 AM)soywiz Wrote: Also, implementing the VFIM instruction I have seen that you are storing the output as if it was VD. But the register number is getted from the place of the VT register. It is really using the VD register? Because if not, prefixes could get wrong. Probably the VD in a different offset, but I wanted to be sure and to avoid headaches in the future. We can also make a test for all the vfpu missing stuff including that. Testing all the instructions, with all the special cases, with prefixes and for example verifying that prefixes only affects to one instruction...
VFIM and VIIM are very special instructions : the destination register is in the VT field but prefixes vpfxs and vpfxt are stated to have no effect on those instructions. However prefix vpfxd is stated to be valid. So we get the register index from VT field but handle it as it is a VD register so we may apply vpfxd on it.
But you're right, they need some tests with prefixes to assert or not those states.
RE: Development offering - Orphis - 08-05-2011
Silly question, but why do you code bat files and not real Makefiles ? It would be way easier to maintain and compile on Linux !
RE: Development offering - soywiz - 08-05-2011
I don't have a makefile interpreter. I just wanted to make it portable and easy to use.
At this moment you download the repository with a svn client, and then double click a file, and it will compile it without any extra requirements.
Also I don't like makefiles. I think makefiles are archaic and very hard to understand and maintain.
But definitively I could use cmake or ant and probably it's the way to go.
Also I think I will change my GUI frontend and will use GTK+ or WX so it will run on linux and mac.
But first I want to perform a HUGE refactoring and doing a propertly TDD. I want to detect bad designs, refactor and remove old code. And I'm on it right now.
If you want, you can remove .BAT files from pspautotests, and create a proper cmake, and or even makefile to compile examples. Probably a good idea if you plan to automate building and running tests on a linux machine.
Also, you can modify and create automated tests. That was the idea creating the pspautotests project.
RE: Development offering - Orphis - 08-05-2011
Makefile are really portable. All you need is make, which exists on every known platform, whereas batch is only available on Windows.
Makefiles aren't really archaic, they just have a special syntax and they're way more powerful than raw batch scripts. Sure, you get the work done, but the point with a good tool is to be smart. And it's not really hard to maintain, I'm not talking about an autotools generated Makefile here !
I really don't like CMake, I won't do that. It's an unnecessary dependency, because you'll still need make/nmake/whatever to build and run the tests.
So, if you want me to do them, just add me to the project so I can work and commit them.
RE: Development offering - soywiz - 08-07-2011
Ok. We can use makefiles. Not sure which is your user on google code. I don't see it here: http://code.google.com/p/jpcsp/people/list
Can you PM me your user so I can add you?
RE: Development offering - Orphis - 08-08-2011
Gid already did it
It's true that I don't commit much and it's difficult to link my Google account with my regular alias !
RE: Development offering - beanclr - 08-14-2011
Man soy, your moving way to fast for me to keep up. =P