The following warnings occurred: | |||||||||||||||
Warning [2] Undefined property: MyLanguage::$archive_pages - Line: 2 - File: printthread.php(287) : eval()'d code PHP 8.2.28 (Linux)
|
![]() |
Request of support for Nanodesktop JPCSP HAL - Printable Version +- 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: Request of support for Nanodesktop JPCSP HAL (/showthread.php?tid=2463) Pages:
1
2
|
Request of support for Nanodesktop JPCSP HAL - pegasus2000 - 10-15-2010 Good morning, we're working on the next HAL (Hardware Abstraction Layer) for Nanodesktop SDK: it will be dedicated to JPCSP emulator. We have integrated your emulator in our SDK, created the new .mak files and integrated your program in the IDE. However, we have some requests about your source code. The first is the following: we have seen that functions as sceGuStart () sceGuCopyImage () sceGuTexSync(); sceGuFinish (); sceGuSync (0,0); don't work under your emulator. Nanodesktop uses (under PSP) the blitter function sceGuCopyImage in order to drammatically improve the speed of rendering. Actually, JPCSP HAL uses a software routine that emulates sceGuCopyImage using the virtual CPU (like PSPE HAL does too), but we think that... if you'd create a special blitter function that emulates sceGuCopyImage and if you'd provide it for the developers, the performance of the Nanodesktop applications under JPCSP could become very faster. A second issue: why your emulator assignes only 32 Mb of emulated ram to the homebrew ? We often develop applications using ndOpenCV that require 64 Mb of emulated ram to work. Can you introduce an option in your emulator that enables the 64 Mb (like in PSP-2000) for the emulated homebrew ? RE: Request of support for Nanodesktop JPCSP HAL - Orphis - 10-16-2010 64MB is doable, sure. For the Gu functions, what are you using them for ? We've learnt that most people didn't understand quite well how they work and the real intent using them. Since Gu is just a wrapper for the raw GE functionnality, sometimes when it's not used properly, it can make bad results in our emulator. So can you describe the essential parts of your code that is not working so we can check them against a real PSP and our emulator ? A link to the source code could be useful too. RE: Request of support for Nanodesktop JPCSP HAL - pegasus2000 - 10-16-2010 (10-16-2010, 02:01 AM)Orphis Wrote: 64MB is doable, sure. This is a part of the NanoTile accelerator of Nanodesktop HAL (HAL_PSP\ndHAL_WindowsRender.c) Code: inline void INTERNAL_WindowsRender_NOTRASP_BACKGR () As JPCSP HAL is written in way to adapt perfectly to the features of your emulator, for us it would be sufficient to have a routine that emulates: void sceGuCopyImage (int psm, int sx, int sy, int width, int height, int srcw, void *src, int dx, int dy, int destw, void *dest) Image transfer using the GE. The HAL could recall the special routines of your emulated kernel: it is not needed to emulate all SceGu routines. RE: Request of support for Nanodesktop JPCSP HAL - gid15 - 10-16-2010 Hi pegasus2000, could you post a compiled PSP application using this function and not rendering correctly on Jpcsp? There are only few PSP applications using sceGuCopyImage and our implementation might still have problems. Also, we still have open issues with homebrews rendering directly to the framebuffer, without using GE lists. It seems that the main site for nanodesktop (http://visilab.unime.it/~filippo/Nanodesktop/nanodesktop.htm) is down... RE: Request of support for Nanodesktop JPCSP HAL - pegasus2000 - 10-17-2010 (10-16-2010, 08:15 PM)gid15 Wrote: Hi pegasus2000, Yes. Unfortunately, Visilab website is down for some days because of a technical problem. I'll inform you immediately when it will return up (within few days). All homebrews that are compiled with PSP/PSP KSU/PSP CFW HAL use internally sceGuCopyImage() for video rendering acceleration, so all are not suitable under JPCSP. Here it is the Nanodesktop Demo 1 compiled with PSP HAL: ![]() And here it is the same program compiler with JPCSP HAL: ![]() When using JPCSP HAL, Nanodesktop uses a software routine running in the emulated CPU that does the same work of sceGuCopyImage() via software. In this way, it can compensate the lack of a working sceGuCopyImage() (the same approach is used in PSPE emulator). So, the support of sceGuCopyImage() is required only for performance reasons. We think that, as the JPCSP HAL is designed on the features of your emulator, perhaps you could simply create a module in your emulator containing some routines that are specific for Nanodesktop and that can be called by the HAL during the emulation, and one of this could be a Java routine that copies a rectangular area in memory from a position to another (i.e. what sceGuCopyImage() does). If you need a copy of the homebrew compiled for the real PSP and for JPCSP emulator, you can download that here: http://rapidshare.com/files/425552619/Nanodesktop_Demo_1_PSP_and_JPCSP.zip RE: Request of support for Nanodesktop JPCSP HAL - Orphis - 10-17-2010 For future reference, sceGuCopyImage in the pspsdk does : void sceGuCopyImage(int psm, int sx, int sy, int width, int height, int srcw, void* src, int dx, int dy, int destw, void* dest) { sendCommandi(TRXSBP,((unsigned int)src) & 0xffffff); sendCommandi(TRXSBW,((((unsigned int)src) & 0xff000000) >> 8)|srcw); sendCommandi(TRXPOS,(sy << 10)|sx); sendCommandi(TRXDBP,((unsigned int)dest) & 0xffffff); sendCommandi(TRXDBW,((((unsigned int)dest) & 0xff000000) >> 8)|destw); sendCommandi(TRXDPOS,(dy << 10)|dx); sendCommandi(TRXSIZE,((height-1) << 10)|(width-1)); sendCommandi(TRXKICK,(psm ^ 0x03) ? 0 : 1); } Everything should be implemented. But the TRXKICK doesn't seem to work quite well in this case. RE: Request of support for Nanodesktop JPCSP HAL - gid15 - 10-17-2010 (10-15-2010, 10:41 PM)pegasus2000 Wrote: sceGuStart ()Could you try to insert a call to sceGuDrawBuffer() before sceGuCopyImage(), i.e. Code: sceGuStart () From your test applications, I can see that this missing call is causing the problem in Jpcsp (the GE values in sceDisplay are never updated and do not match the updated FB values). I'm still investigating how to support your original sequence, but calling sceGuDrawBuffer could be a workaround. RE: Request of support for Nanodesktop JPCSP HAL - pegasus2000 - 10-22-2010 (10-17-2010, 12:39 PM)gid15 Wrote:(10-15-2010, 10:41 PM)pegasus2000 Wrote: sceGuStart ()Could you try to insert a call to sceGuDrawBuffer() before sceGuCopyImage(), i.e. Ok, I'll follow your advice and I'll signal you if it works. In the meantime, the Visilab website is online again: http://visilab.unime.it/~filippo/Nanodesktop/PSP_PSPE/nanodesktop_PSP_PSPE.htm RE: Request of support for Nanodesktop JPCSP HAL - gid15 - 10-25-2010 I've added a fix for this problem in r1803. I could run your PSP test application without the special Jpcsp software emulation. RE: Request of support for Nanodesktop JPCSP HAL - pegasus2000 - 10-26-2010 (10-25-2010, 04:29 PM)gid15 Wrote: I've added a fix for this problem in r1803. I could run your PSP test application without the special Jpcsp software emulation. Thanks. We would test the new version of your emulator. Is it possible to download an updated image from anywhere, or I can access only through SVN ? A second thing: in our tests, we have detected some problems of timing in Nanodesktop GraphDemo: http://visilab.unime.it/~filippo/Nanodesktop/PSP_PSPE/Homebrew%20Demos/ndPSP_PSPE_Homebrew_Demos.htm Could you test this application for us ? Perhaps you can find some bug in the new version of your emulator (the version for PSP HAL worked very bad last time). Thanks again. |