EmuNewz Network

Full Version: Request of support for Nanodesktop JPCSP HAL
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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 ?
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.
(10-16-2010, 02:01 AM)Orphis Wrote: [ -> ]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.

This is a part of the NanoTile accelerator of Nanodesktop HAL
(HAL_PSP\ndHAL_WindowsRender.c)

Code:
inline void INTERNAL_WindowsRender_NOTRASP_BACKGR ()
/*
    Questa subroutine di WindowsRender esegue il render di tutto lo schermo. E' ottimizzata per
    funzionare nel caso in cui non vi siano trasparenze ed il background sia attivato
*/
{
  register unsigned short int PosPixelX, PosPixelY;
  register unsigned short int RgPosX1, RgPosY1, RgPosX2, RgPosY2;
  
  register unsigned short int NotActiveFBPage;
    
  register unsigned short int RPosX, RPosY;
  register unsigned char OwnerOfPixel;

  register int Counter, CounterX, CounterY;
  
  register int ADR;
  

  NotActiveFBPage=!ActiveFBPage;        // Tutte le operazioni di scrittura vengono eseguite nella pagina che
                                        // in quel momento non è attiva
  
  // Provvedi alla visualizzazione delle tiles
  
  INTERNAL_SetupFastPutPixel (NotActiveFBPage);
  
  sceGuStart(GU_DIRECT,ndlist);   // Preparati ad inviare comandi al chip grafico della PSP
  sceKernelDcacheWritebackAll();  // Pulisci la cache: necessario su PSP per evitare la corruzione dell'immagine
  
  ADR=AddrVideoMemory+NotActiveFBPage*PageSize;
  
  for (Counter=0; Counter<NrNanoTilesEnabled; Counter++)
  {
     RgPosX1 = ndNanoTile [Counter].PosX1+1;    // Forza questi valori dentro ai registri
     RgPosX2 = ndNanoTile [Counter].PosX2-1;
     RgPosY1 = ndNanoTile [Counter].PosY1+1;
     RgPosY2 = ndNanoTile [Counter].PosY2-1;
    
     OwnerOfPixel = ndNanoTile [Counter].Level1;  
  
     if (OwnerOfPixel!=255)    // Il tile appartiene a qualche finestra
     {
             RPosX=RgPosX1-(WindowData [OwnerOfPixel].WndLimitX1);                  // Viene calcolata la coordinata relativa per
             RPosY=RgPosY1-(WindowData [OwnerOfPixel].WndLimitY1);                  // accesso alla ram delle pagine logiche
                    
             sceGuCopyImage(GU_PSM_5551, RPosX,              RPosY,                 // Provvede a salvare la tile sullo schermo
                                         RgPosX2-RgPosX1+1,  RgPosY2-RgPosY1+1,     // usando il chip grafico della PSP
                                         WindowData [OwnerOfPixel].HwWndLength,
                                         WindowData [OwnerOfPixel]._p,
                                         RgPosX1, RgPosY1, 512,
                                         (void *)(ADR));
                                        
             sceGuTexSync();    
     }  
     else    // Il tile appartiene allo sfondo, che però in questo caso non è vuoto
     {
             sceGuCopyImage(GU_PSM_5551, RgPosX1,            RgPosY1,               // Provvede a salvare la tile sullo schermo
                                         RgPosX2-RgPosX1+1,  RgPosY2-RgPosY1+1,     // usando il chip grafico della PSP
                                         NDCFG_BASESCREENX,                             // PntToBaseScreen->Pixel è un multiplo di 16 qui
                                         &PntToBaseScreen->Pixel,                               // Indirizzo del basescreen
                                         RgPosX1, RgPosY1, 512,
                                         (void *)(ADR));
                                        
             sceGuTexSync();    
     }
        
  }
  
  sceGuFinish();
  sceGuSync(0,0);
  
  // Provvedi alla visualizzazione dei contorni delle tiles: prima operiamo sui contorni verticali
  
  for (CounterX=0; CounterX<NrXVertexEnabled; CounterX++)    
  {
        for (CounterY=0; CounterY<Windows_MaxScreenY; CounterY++)
        {
              PosPixelX = ndXVertexBuffer [CounterX].PosX;
              PosPixelY = CounterY;  
                
              OwnerOfPixel=OwnerArray [PosPixelX][PosPixelY][0];
    
              if (OwnerOfPixel!=255)                     // Il pixel appartiene a qualche finestra
              {
                 RPosX=PosPixelX-(WindowData[OwnerOfPixel].WndLimitX1);                  // Viene calcolata la coordinata relativa per
                 RPosY=PosPixelY-(WindowData[OwnerOfPixel].WndLimitY1);                  // accesso alla ram delle pagine logiche
    
                 INTERNAL_FastPutPixel (PosPixelX, PosPixelY, WINDOWDATA_P (OwnerOfPixel, RPosX, RPosY));
              }
              else                                       // Il pixel appartiene allo sfondo
              {
                 INTERNAL_FastPutPixel (PosPixelX, PosPixelY, PntToBaseScreen->Pixel [PosPixelY][PosPixelX]);                
              }      
        }
  }
    
  // Ed ora provvediamo a visualizzare i bordi orizzontali
    
  for (CounterY=0; CounterY<NrYVertexEnabled; CounterY++)    
  {
        PosPixelY = ndYVertexBuffer [CounterY].PosY;
        INTERNAL_LoadLine (PosPixelY);
        
        for (CounterX=0; CounterX<Windows_MaxScreenX; CounterX++)
        {
              PosPixelX = CounterX;  
              
              OwnerOfPixel=OwnerArray [PosPixelX][PosPixelY][0];
        
              if (OwnerOfPixel!=255)                     // Il pixel appartiene a qualche finestra
              {
                 RPosX=PosPixelX-(WindowData[OwnerOfPixel].WndLimitX1);                  // Viene calcolata la coordinata relativa per
                 RPosY=PosPixelY-(WindowData[OwnerOfPixel].WndLimitY1);                  // accesso alla ram delle pagine logiche
    
                 INTERNAL_SuperFastPutPixel (PosPixelX, WINDOWDATA_P (OwnerOfPixel, RPosX, RPosY));
              }
              else                                       // Il pixel appartiene allo sfondo
              {
                 INTERNAL_SuperFastPutPixel (PosPixelX, PntToBaseScreen->Pixel [PosPixelY][PosPixelX]);
              }
        }
  }
  
  
}

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.
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/Nanodes...esktop.htm) is down...
(10-16-2010, 08:15 PM)gid15 Wrote: [ -> ]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/Nanodes...esktop.htm) is down...

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:

[Image: 9kwg3m.jpg]

And here it is the same program compiler with JPCSP HAL:

[Image: 14cr9tv.jpg]

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/Na..._JPCSP.zip
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.
(10-15-2010, 10:41 PM)pegasus2000 Wrote: [ -> ]sceGuStart ()
sceGuCopyImage ()
sceGuTexSync();
sceGuFinish ();
sceGuSync (0,0);
Could you try to insert a call to sceGuDrawBuffer() before sceGuCopyImage(), i.e.
Code:
sceGuStart ()
sceGuDrawBuffer()
sceGuCopyImage ()
sceGuTexSync();
sceGuFinish ();
sceGuSync (0,0);

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.
(10-17-2010, 12:39 PM)gid15 Wrote: [ -> ]
(10-15-2010, 10:41 PM)pegasus2000 Wrote: [ -> ]sceGuStart ()
sceGuCopyImage ()
sceGuTexSync();
sceGuFinish ();
sceGuSync (0,0);
Could you try to insert a call to sceGuDrawBuffer() before sceGuCopyImage(), i.e.
Code:
sceGuStart ()
sceGuDrawBuffer()
sceGuCopyImage ()
sceGuTexSync();
sceGuFinish ();
sceGuSync (0,0);

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.

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/Nanodes...P_PSPE.htm
I've added a fix for this problem in r1803. I could run your PSP test application without the special Jpcsp software emulation.
(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/Nanodes..._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.
Pages: 1 2