You are not logged in.
Pages: 1
If a program write to a file from within Desmume, using DLDI, the file seems to be read/written, but it never actually writes the data to disk. I assume this is intentional, but there are times that I would like to be able to see what was written. Is there any kind of flag I can pass to desmume to say "don't fake-out the IO for me - just do it for real?"
I am developing homebrew, and I want my homebrew application to be able to write a debug log. I had the idea that I could write the log file using FAT, and open another window to monitor the log file in real-time. But I found that desmume doesn't actually write to disk - it just emulates the writes and holds the data in memory. Is it possible to tell desmume to actually write the FAT data to disk and flush it out? Alternatively, is there a way to send debug messages to gdb? Or any other way to get log messages outside of the emulator window?
I think either gdb or desmume isn't closing TCP connections properly. It's working right now, but it didn't work 5 minutes ago... And netstat looks normal now, showing LISTENING instead of ESTABLISHED. Except for my weird TCP problem -- it works great! I definitely think it should be added to the trunk of desmume. I haven't used it too much, but so far there don't seem to be any compatibility problems.
I tried using this and I'm having intermittent network problems. This is on Windows XP. The tool works randomly about one in every 25 times I run it. :-( Here's what happens when I try to debug ds_2dand3d.nds:
1) C:\util\desmume\DeSmuME_gdb.exe --arm9gdb=24689 ds_2dand3d.nds
2) C:\util\devkitPro\insight\bin\arm-eabi-gd.exe ds_2dand3d.elf
GNU gdb 6.5.0
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=arm-eabi"...
(gdb) target remote :24689
:24689: No connection could be made because the target machine actively refused
it.
(gdb) quit
If I run netstat after running desmume_gdb.exe I see:
TCP 127.0.0.1:4788 127.0.0.1:24689 ESTABLISHED
TCP 127.0.0.1:24689 127.0.0.1:4788 ESTABLISHED
Which looks like desmume opened port 24689 then connected to itself. (???) Although it does this same thing even when it does work.
Should I submit a bug fix to the nehe demos to address this (not sure who owns those), or is this a desmume bug? It would be a shame for the homebrew developers to get the impression that desmume is really slow when it really isn't (I initially used no$gba because desumume wasn't running those demos very well)
The following .cpp demonstrates the problem:
////////////////////////////////////////////////////////////////////////////////
// desmume bug (???) sample application
//
// This demonstrates a performance-related bug in desmume
////////////////////////////////////////////////////////////////////////////////
#include <nds.h>
#include <stdio.h>
int main()
{
// Turn on everything
powerON(POWER_ALL);
// An application SHOULD call this routine. Failure to do so causes
// desmume to run horrendously slowly.
//irqInit();
irqSet(IRQ_VBLANK, 0);
irqEnable(IRQ_VBLANK);
while(1)
{
// wait for the screen to refresh
swiWaitForVBlank();
}
return 0;
}
Just run it and watch the frame counter. Ony my Athlon 3400+, the fps counter drops from 180fps to 23fps. But in reality, I think the frame counter is wrong and actuality is closer to <5 fps. Something really wacky happens if irqInit is not called. Since most well-behaved applications should be calling this, but I noticed that several sample applications that come with libnds aren't calling it. (The nehe 3D demos, for example)
I have several homebrew apps that ran horribly on desmume but ran fine on no$gba. I tracked the problem down to a missing call to LibNDS irqInit() my homebrew apps. Adding this called fixed things.
This is definitely a bug in my homebrew app. But is it also a bug in desmume?
I'm trying to use DeSmuME for homebrew development. The release notes indicate that there is FAT support, but I don't see any information on how to configure it. Ex: How do you set the root directory for the CF? Which fat drivers/libraries work with it? Ex: Which DLDI driver settings would work with it?
I tried opening some homebrew apps like DSOrganize, DSDoom, AmplituDS, and Moonshell - but none of them seem to work. I am hoping there is some FAT configuration setting hiding in the INI file.
Excerpt from Changelog:
0.3.3 -> 0.5.0
cart:
- Added CompactFlash/FAT emulation.
Pages: 1