Dingoonity.org

okay this is a very advanced topic and i only just recently found out about it myselve with the help of sms_sdl emulator which ran really crap under dingux and i couldn't figure out why.

people should start with reading this :
http://www.ibm.com/developerworks/library/pa-dalign/
or 
http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment (even though it's arm related)

now that you know what alignment issues are you might think what does this have to do with dingux

well the problem (we didn't know about until today) is that the mips linux kernel seems to handle aligment issues for us but at the cost of speed. in other words it will decrease performance a lot on software that got affected by it.
so now that we know al of this, how can we check if our software has the problem ? It's really easy add the following include file in your main c/cpp file :
#include <sys/sysmips.h>

and in your main function add the following call :
sysmips(MIPS_FIXADE, 0,0,0);
what this function does is disabling the kernel from intercepting the unalligned memory access and handling it by itselve.
recompile your program and run it.
If the program runs fine without crashing your program is not affected by the problem, however if your program crashes with a "Bus Error" message your program is affected by this issue and you should seek out a way to align your data (examples are given on both sites i mentioned above).

to see what kind of an performance impact this has lets take sms_sdl i had compiled it with and without memory alginement and here are the results :
/boot # ./sms_sdl ./sonic2.sms  --fullspeed --fskip 0
SMS Plus/SDL v0.9.4aR7 (Build date Oct 17 2009)
(C) Charles Mac Donald in 1998, 1999, 2000
SDL Version by Gregory Montoir ([email protected])

Loaded `./sonic2.sms'.
Initializing SDL... Ok.
Initializing SDL TIMER SUBSYSTEM... Ok.
Initializing SDL CONTROLS SUBSYSTEM... Ok.
Initializing SDL VIDEO SUBSYSTEM... Ok.
Initializing SDL SOUND SUBSYSTEM... Ok.
Initializing virtual console emulation... Ok.
Starting emulation...
Shutting down virtual console emulation...
Shutting down SDL...
[INFO] Frames rendered = 1658.
[INFO] Average FPS = 52.79 (87%).
[INFO] Play time = 31.41 sec.
/boot # ./sms_sdl_aligned  ./sonic2.sms  --fullspeed --fskip 0
SMS Plus/SDL v0.9.4aR7 (Build date Oct 17 2009)
(C) Charles Mac Donald in 1998, 1999, 2000
SDL Version by Gregory Montoir ([email protected])

Loaded `./sonic2.sms'.
Initializing SDL... Ok.
Initializing SDL TIMER SUBSYSTEM... Ok.
Initializing SDL CONTROLS SUBSYSTEM... Ok.
Initializing SDL VIDEO SUBSYSTEM... Ok.
Initializing SDL SOUND SUBSYSTEM... Ok.
Initializing virtual console emulation... Ok.
Starting emulation...
Shutting down virtual console emulation...
Shutting down SDL...
[INFO] Frames rendered = 1665.
[INFO] Average FPS = 122.34 (203%).
[INFO] Play time = 13.61 sec.
/boot #

as you can see the unaligned version runs not even fullspeed it runs at 52 fps (87%) (the normal speed is 60 fps) while the alginment version runs at a whooping 122.34 fps average (203%).
So running a program that is affected with this problem will run very very bad with a lot of slowdowns.

I know of at least 1 other emulator that has this problem snes9x-sdl ! so speed could improve in snes9x-sdl as well given we align the data. i'll look into that some time or contact the current author thats currently doing snes9x ports so he knows about this.

Hope this helps !

I know of at least 1 other emulator that has this problem snes9x-sdl ! so speed could improve in snes9x-sdl as well given we align the data. i'll look into that some time or contact the current author thats currently doing snes9x ports so he knows about this.

Hope this helps !

He's Japanese, and his site is here:  http://www9.atpages.jp/~drowsnug95/
Hopefully he understands some amount of English, otherwise someone will have to be a translator.Full (or near full speed) SNES is one of the top things missing from the Dingoo, so if fixing the alignment issues gives the same level of performance increases as sms-sdl, full speed snes should be doable.

Exciting news!

Hopefully it'll be implemented as quick as everything else gets done in this scene!

We'll be running SNES in full speed in no time!! WOOHOO!! 

Nice to hear that tips.
joyrider, do you think this can also apply for Dingoo OS Native dev also ?

Hi, joyrider.

i am drowsnug from Japan.

I've released snes9x source code in my site,
http://www9.atpages.jp/~drowsnug95/?p=252#comments
Please optimise it! (I've tried, but failed )

Thank you.

YEAH! the demigods are joining! soon dingoo will reach it maximum power...

well i looked at the source code, and unfortunatly the code for allignements was already in place an being used, the bus error came from an unaligned struct in ppu.h (being struct SPPU)

which can be fixed by adding a "dummy padding" var to it like this :
    uint8  OAMReadFlip;
    uint16  padding;
    uint8  OAMData [512 + 32];

as i said the code for the alignment stuff was there and is being used, it wouldn't have been used if the FAST_LSB_WORD_ACCESS define would have been defined. so it was alligned al the time. except for that struct (which was made the OAMDATA being unaligned). You can see this in for example following code :
#ifdef FAST_LSB_WORD_ACCESS
   //unaligned
    long OpAddress = (*(uint32 *) cpu->PC + reg->X.W) & 0xffffff;
#else
   //aligned
    long OpAddress = (*cpu->PC + (*(cpu->PC + 1) << 8) + (*(cpu->PC + 2) << 16) + reg->X.W) & 0xffffff;
#endif

I did try some other stuff like no flipping of surfaces and a HW_SURFACE which gave me 3-4 fps increase, unfortunatly it has a side effect. Whenever pixel data gets written twice on the same frame on the same pixel it will flicker. (and the snes does seem to do this) so it's not really worth it.

The only thing i can try is to add the scaler from mame4all which i have gotten from alekmaul & used in gnuboy & sms_sdl to be used in snes9x to see ifs any faster. But that's about it, drowsnug did a great job already

Is snes9x using profiling? It could be a nice easy speedup, if it isn't already using it.You can do it with GCC4 pretty easily:
http://www.gp32x.com/board/index.php?/topic/28490-advanced-optimization-via-profiling-with-gcc4/page__st__15

EDIT: Just checked the source, and there are .gcno files so it's already using profiling.

It all depends where the misalignments happen in the code and if there are any to begin with since not all software has the issue. If the source is included of the software in question, you can easily test it with the sysmips call which disables the kernel trapping. If the application crashes with a "bus error" you know it has problems. In order to detect where exactly gdb is needed (which is included in the rootfs) You just run the software through gdb with the kernel trapping of the alignment issues disabled and gdb will show you the exact line where it happens. Unfortunatly with snes9x it was in a place that doesn't have any impact on the emulation speed, the struct i told about in my previous post. However with sms_sdl it was happening in the render code so you can probably guess it was happening quite often, thus the impact & speed increase gained by alligning reads / writes in sms_sdl
So it all depends on the software and where it happens, it's not some magical thing to make a software go twice as fast all of a sudden (unless its in a crucial part of the code).

So full speed snes won't happen, at least not by doing this, someone could try mips asm instructions but i don't know anything about that, so don't expect it to happen soon and neither being done by me

someone could try mips asm instructions but i don't know anything about that, so don't expect it to happen soon and neither being done by me

Any chance any ASM used on the PSP snes emulator would help (PSP does use a MIPS processor, right?)?