07-26-2011, 10:53 PM
Great then!
I will check the jpcsp sourcecode when I get some time and I will see how to do that.
In my emulator I run automated tests using the command line.
:: pspemu.exe --unit_tests
It launches all the tests I have done. It iterates recursively the tests_ex folder searching for .expected files. Then search for a file with the same name and .elf extension and executes it. It compares the Kprintf ouput with the one in the .expected file and shows a visual diff of the changes.
Also I can run only one tests or a few ones while I'm developing a functionality:
:: pspemu.exe --unit_tests cwd
Then before every commit I launch all the tests to check if I have introduced any regression. The more tests covering all the psp API, the less regressions can I make because I launch every test on every commit. (Still some are failing sometimes because of the multithreaded cpu execution [it introduces some indeterminacy on execution]).
In order to make this on jpcsp, I will need to start a new emulation state or reset a previous one. In a way I can load/unload several executables in a single run. And all the stuff should be independant of the display, and don't have static states that can't be resetted.
Then I will have to implement Kprintf on jpcsp and allow to hook it to be able to check on the automated tests.
At this stage it is easy to start and restart the emulation?
I will check the jpcsp sourcecode when I get some time and I will see how to do that.
In my emulator I run automated tests using the command line.
:: pspemu.exe --unit_tests
It launches all the tests I have done. It iterates recursively the tests_ex folder searching for .expected files. Then search for a file with the same name and .elf extension and executes it. It compares the Kprintf ouput with the one in the .expected file and shows a visual diff of the changes.
Also I can run only one tests or a few ones while I'm developing a functionality:
:: pspemu.exe --unit_tests cwd
Then before every commit I launch all the tests to check if I have introduced any regression. The more tests covering all the psp API, the less regressions can I make because I launch every test on every commit. (Still some are failing sometimes because of the multithreaded cpu execution [it introduces some indeterminacy on execution]).
In order to make this on jpcsp, I will need to start a new emulation state or reset a previous one. In a way I can load/unload several executables in a single run. And all the stuff should be independant of the display, and don't have static states that can't be resetted.
Then I will have to implement Kprintf on jpcsp and allow to hook it to be able to check on the automated tests.
At this stage it is easy to start and restart the emulation?