Skip to content
Archive of entries posted on September 2009

Generic Makefile Build Chain for Symbian OS v. 1.0

The build chain was originally made by Harry Li. I just continued the project and added support for static library linking, debugging etc. The 1.0 version can also build static libs, which can easily be linked from Symbian .mmp files,or Qt’s .pro files. Now we should be able to use the old already ported symbian engines(gpsp etc) with Qt too, so the porting process from the old Avkon based UI system to the Qt’s UI should be more pleasant :)

MOTIVATION

  • The C preprocessor can be used much better with makefile than with abld build. You can not compile a project relying heavily on c preprocessor with abld build, so the makefile build is really an essential tool for those projects.
  • It makes porting software from linux based systems easier. The GCCE is just a GCC build for Symbian  so now you can use GCC (hopefully almost same version) and same the build rules for the port in Symbian also.
  • You can create static libs from the code that is hard to port (you need some custom compiling tricks), and then link into it from mmp-files or from Qt project files.
  • The generic makefile build is also faster than the abld build. You could (hopefully) also make it faster with “-j” option with the future versions of GCCE

INSTALLATION

Here are the instructions to use this environment.

  1. install SVG2SVGConvertter. The installation file can be found under EPOCROOT\S60tools\svg2svgt\installer\
  2. The script should be executed from \gms directory. The script also expects to have \dist\gcce and \obj\gcce directories under the gms directory, so you should also make these folders.
  3. The OS_HRH part doesn’t seem to work in the defines.mk. I solved this my replacing the include statement in epoc32\gcce\gcce.h to
    #if defined(__PRODUCT_INCLUDE__)
     #include  //for MinGW
     //#include __PRODUCT_INCLUDE__ //quick hack
     #endif
    

Continue reading ‘Generic Makefile Build Chain for Symbian OS v. 1.0’ »

Fast image scaling with multiplier between 1-2

I made a simple scaling function for gpsp4symbian to stretch the frames into full screen. The algorithm seems to be working quite well with scaling factors between 1-2. Thanks to AnotherGuest for tips.

In this example 1.3 scaling factor is used for vertical scaling and 1.5 for horizontal scaling.

Fist let’s make the scaling tables.

void symb_create_interpolate_table()
  {
  TReal j = 1.33; //horizontal
  TReal loop = 0;
  TReal real_temp;

  for( TInt i=0; i<240; i++)
    {
    real_temp = i*j + 0.5;
    interptable_w[i] = real_temp;
    }

  j= 1.5; //vertical
  for( TInt i=0; i<160; i++)
    {
    real_temp = i*j + 0.5;
    interptable_h[i] = real_temp;
    }
  }

Then we can use the pre-calculated tables to determinate if we have to interpolate a pixel or a line or not. There are all kinds of nice interpolation algorithms for images, but in this example I just reproduced the pixels for the speed. In theory we should also do some filtering after the interpolation, but that’s also abandoned for the speed.

Continue reading ‘Fast image scaling with multiplier between 1-2’ »

Why Symbian is so slow compared to Linux

Symbian phones are really slow compared to Linux based devices like gp2x etc. You really don’t get even near to the same performance (in frames per second) with Symbian phone compared to an open Linux device with similar ARM processor.

Here’s couple of reason’s affecting my emulator ports.

1. No direct access to the frame buffer
Symbian doesn’t provide direct access to the frame buffer. The CDirectScreenAccess API is far from direct. All data goes through window server, so there’s cycles consumed in the sceduling (few context changes etc) and in the memcopy operations made by the Window Server. I’m assuming that the Window Server makes a transformation of the data passed to it via CDirectScreenAccess. This all makes the basic blit operation really slow in Symbian.

I’m hoping that the Qt will provide faster access to the the frame buffer, which could provide significant speed increase to my emulators.

2. Memory mapping and dynarec
The memory mapping affects only gpsp-emulator, but it affects to it heavily. I have to use the memory trampoline pattern to get the dynamic recompilation working in Symbian. This affects all the dynarec emulators a lot. I’m quite sure that psx4symbian would be possible with OMAP3 based devices, if Symbian memory mapping could be modified.

I don’t think that Symbian is going to change their memory mapping just to get dynarec emulator to run faster. However I’m quite sure that this also slows down all self-modifiyingcode which is being run in the Symbian OS, so there might be a little hope. At least I could add an idea about modifying the memory mapping into the Symbian Foundation’s idea database.

gpSP4Symbian: S60 3rd edition preview

This is just an initial release to gain some feedback how the port is currently working. I would like to know if you get any games running at correct speed. The first number in the fps-counter is telling how fast the emulator is running( it should be 60). If you do get something running at that speed, please also test the audio then. I have some tricks planned for the audio, but there’s really no point of doing it, if it doesn’t run fast enough.

Please list some games in the comments that you got running well, so I can test the audio with those. It’s really no point of tweaking audio, if the game doesn’t run well. Tell also what phone you are using. It would be very interesting to have some results from phones with 600Mhz ARM processor.

gba

Know issues:

  • key config is missing
  • only one game can be loaded with each run
  • audio may not work well. I really didn’t have a good setup to test it.
  • You should turn audio on after a game has been loaded. Turning the audio on before loading the game will crash the emulator.
  • The emulator requires a lot of CPU power. It really doesn’t work with my N96 or N73

KEYCONFIG

There is no keyconfig yet available, so you’ll have to bear with these for a while. up/down/left/righ form the d-pad
4:  L
5: A
6: start
7: R
8: B
9: select
#: save state
* :load state
left softkey: menu

Continue reading ‘gpSP4Symbian: S60 3rd edition preview’ »

gpSP: Building A Memory Trampoline

Thanks to the original gpSP creator Exophase for tips. I was really confused with BL instructions and the fact that the memory address was pointing into wrong memory area. The problem was in Symbian OS memory mappings. It’s a very common problem with dynarec and Symbian. I had pr

In Symbian you can create memory partitions for dynamic recompilation with CreateLocalCode and IMB_Range deal, as I wrote few moths ago.  The problem is the way how Symbian OS maps the memory. The pointer to the dynamic code area is too far from the ‘static code’. The BL instruction has a limit of +-32MB. The memory memory is mapped in different way, so we can not use the BL instruction to get to the static code from the dynamic code.

BLX instruction would have longer range than BL, so that could be used. Using the BLX instruction would look like this.

ldr reg, =address
blx reg

The ldr instruction is actually meta-code and compiles into something like this:

mov reg,#0xYYY
orr reg,reg,#0xYY000
orr reg,reg,#0xYY00000
orr reg,reg,#0xY0000000
bx reg

However the way the calling code skips over the bl instruction by adding a shifted bit to the pc it is impossible to replace this call with the register load plus BLX instruction. The solution is to make stubs to the ‘dynamic’ memory area for each function call instead, and then call the stub with bl, and use bx from that stub to reach out to the final destination.

Continue reading ‘gpSP: Building A Memory Trampoline’ »