Release DraStic Nintendo DS emulator


So excited for potential gamepad support. I'm sure the Pyra version will be awesome too!
 
It looked like it'd give a non-negligible speedup, but he gave it to EvilDragon to test and he says in practice it made things slower. It sounded like it interacts poorly with frameskip.

Maybe notaz wants to try more with it. If he does I'll see about releasing it. But don't expect much. For the DSP to really be useful I think it would need to have code that's carefully optimized for it, but that could be extremely hard.
From my point of view this project is finished (and mostly failed, given ED's feedback). I don't have any ideas what more could be done with it (without sinking much more time into it), and you already have the latest code. You mentioned DMA but I doubt it would help much, it also looked unsafe to do in parallel (but I may be wrong here).
 
From my point of view this project is finished (and mostly failed, given ED's feedback). I don't have any ideas what more could be done with it (without sinking much more time into it), and you already have the latest code. You mentioned DMA but I doubt it would help much, it also looked unsafe to do in parallel (but I may be wrong here).
I think something must have been wrong for him to find everything slower when the benchmarks showed it was faster, maybe the threaded mode was interfering with frameskip. The non-threaded mode should be the same as normal execution, even if it doesn't have as much of a speedup. I don't see how it could be slower with your load balancing approach unless the DSP was much slower than it is. It's possible I'll look at it sometime.

DMA was just an idea to speedup some memcpy-like code, without intention of doing anything in parallel. I doubt it'd have made much of a difference. I think the only thing that could make any real difference is for me to substantially rewrite the code to be better optimized or optimizable for the DSP. It'd be very difficult to do given lack of ability to do fine-grained profiling or very easily run unit tests. From what I looked at with the cycle descriptions in the output ASM I was that it's as slow as it is, I do wonder if there were still some major offenders somewhere that could have been improved without rewriting everything, but I'll probably never know.
 
In case anyone wants this..

http://drastic-ds.com/dss_to_png.c

Source code for a little program to extract the screenshots from a savestate file. Only works with uncompressed savestates, and of course they need to have been saved with the option to store screenshots. Run as:

./dss_to_png <savestate file> <top PNG> <bottom PNG>

And it'll create two PNGs for the top and bottom screen.

I compiled it with this on my Linux PC:

gcc dss_to_png.c -lpng -o dss_to_png

Didn't upload a binary because I figure anyone on Linux can easily build it themselves, and I can't easily make a Windows binary just now. Maybe someone can make a Pandora binary too. Not putting a lot of effort into this since I'll properly incorporate the ability to save screenshots into the next version.
 
Exophase, if you need any testing done or access to an OMAP5 Devboard for building things, Wally and myself have OMAP5 devboards that we have been opening up for select Devs. Mine is running the 4.0 kernel with the latest updates from Nikolaus. From what I understand Drastic doesn't use Hardware rendering correct?, if so the lack of working SGX shouldn't be too much of an issue.
 
It doesn't use hardware rendering, but the Pandora version does use the display controller directly. In Linux it can use SGX instead, but there's a big performance overhead doing so, especially with scaling. Lordus added OpenGL ES rendering to that, maybe that'll work on the OMAP5 board.
 
High Resolution looks nice :) .

That's the reason why I didn't play some DS titles I wanted to play on my Pandora.

Was waiting for a high resolution possibility.

Thanks. I'm looking forward to this :)
.

Time ti finally buy Okamiden.
 
I'm having a lot of problems with DraStic. I downloaded it, transfered my nds and dsv files from my PC, and nothing works. I first tried Pokemon HeartGold, I get the intro movie sound but the screen is either all black or all white. Button inputs do nothing, and it eventually crashes on its own. I loaded up Metroid Prime: Hunters and got something similar: it goes straight to the title screen skipping the intro, but only shows one graphical layer, normally it has Samus and text and a transparent tron-lines type effect but all I see is the line effect solid, nothing else. buttons do nothing, emulator crashes.
 
A quick search through this topic tells me that these games work just fine for other people, so the problem must be with me.
 
The .nds files work fine in DeSmuME on my PC, so they're fine.
I've tried launching DraStic with and without the dsv files present, just in case. No difference.
I tried downloading r2.3.0.0p from both PNDManager and repo.openpandora.org (which should be exactly the same) and no difference.
My Pandora is a brand-new 1Ghz model so I'd certainly hope that's not the problem, but maybe there's some system setting I need to set or something?
I'm not entirely sure how to read pndrun_DraStic.out, but here it is for anyone who can pndrun_DraStic.out.txt.

Again, since others have said things work fine with these games I'm fairly certain that the problem is with me, but I have no idea what it is.
 

Attachments

  • pndrun_DraStic.out.txt
    2.5 KB · Views: 233
Last edited by a moderator:
@Breaded Butter

Code:
***Failed to load system file nds_bios_arm9.bin.
Can't find Nintendo ARM9 BIOS. Trying free DraStic ARM9 BIOS.
***Failed to load system file nds_bios_arm7.bin.
Can't find Nintendo ARM9 BIOS. Trying free DraStic ARM7 BIOS.
***Failed to load system file nds_firmware.bin.
You need the three firmware files put into the appdata/Drastic/system directory.
 
Last edited by a moderator:
Back
Top