You are not logged in.
Hello, I can't get either cQuake or Quake DS to work in DeSmuME.
I have the file directory like it says in the readmes for them. In DeSmuME, I select compact flash for the gba slot, along with the proper directory. Both files are properly patched with mpcf.dldi.
They both start up saying they could initialize the file system, but they both fail to find the ".pak" files. I have double checked everything, it should work. I have also tried different builds of DeSmuME.
Anyone have any ideas as to why it's not working?
EDIT: Also, Quake DS should work, because it has been confirmed as working here: http://forums.desmume.org/viewtopic.php?pid=2539
EDIT: The only DLDI enabled homebrew I've been able to get work right so far is Lameboy.
Last edited by windwakr (2010-06-12 03:22:23)
Offline
Oh, I see. It isn't properly supporting subdirectories. The homebrew can only access the folder you specify, and not any of it's subdirectories. Is it supposed to not support them, or is there something wrong here?
Last edited by windwakr (2010-06-12 15:54:17)
Offline
On a completely unrelated note - while the sentiment is appreciated, there's no need to report every single item of spam. It's not like the report button turns on alarms at our houses for us to come immediately to the forum to take care of the Russian Viagra crisis.
I usually show up a couple times a day to check on the forum and get rid of spam, if you're that bothered by it.
Offline
it's supposed to work. it worked in desmume 0.9.5, i just checked. something got broke i guess.
disturbingly, I don't think the bug is in the compact flash code (which hasnt changed appreciably since long ago); there must be some core logic error that has got broken. yuck.
Offline
never mind it was an ancient bug in compact flash code. not sure how it ever worked. was using uninitialized data. fixed in r3659 and now quake works
Offline
After compiling the most recent SVN, I was still getting the errors, but I've figured it out!
Homebrew CANNOT access the lowest alphabetically named folder!
If just I just had a folder name "ID1" in my CF specified directory, Quake gives the "could not find ID1" error. If I then add a folder that would be placed lower alphabetically, for example "HD1", in the folder next to "ID1", Quake WORKS!
Hope this info helps.
Also, it looks like the CF settings ALWAYS get set to "use ROM path", no matter what else I set it to.
Last edited by windwakr (2010-06-14 00:45:05)
Offline
oh yeah i forgot to mention--the configurator is buggy. i guess i should fix that. you have to edit the ini file to get anything done right now.
i can confirm your 1st folder bug. i had a directory called `data` above ID1 which was making it work. thanks for figuring that out
Offline
The configurator is fixed in r3667.
Offline
I should add that new desmume builds will auto-patch DLDI.
Offline
Alright! I will waiting this one because somebody from other website will try Super Smash Bros Rumble games right now.
Offline
not sure whats up but the libfat code seems buggy to me. It would say that fat was init. but it would fail loading files. check a dir list and there are folders missing, the .. for going back a folder is in the middle of the folder list. some of the folders wont open, one of the folders goes to anther one and a sub folder for a folder is also listed as in the main dir.
Offline
yup its buggy. youre describing the exact bugs. allegedly it works if you create a disk image (it may only be the directory scanning code that is broken)
Offline
I just spent better half of the morning trying to find a way to make a img file. I found out how to make a iso from files and folders and how to convert a img to a iso, but nothing about file and folders to img or iso to img.
Can you point me in the right direction?
*EDIT*
Ok, I got a disk image made, but it seems it still a little buggy.
Last edited by KazoWAR (2010-08-20 01:09:24)
Offline
as of r3766 the cflash libfat emulation has been rewritten and now correctly handles the quake ID1 vs HD1 scenario. it may be a little rough around the edges in other ways, but now the code is much simpler and bugs should be fixable.
Offline
I compiled r3766 (I needed write support) and tested my app with it.
It works great so far (good work ! And just when I needed this).
I have a few questions :
1) Is there a way to make desmume use long names instead/in complement of 8.3 filenames
(like having a hashmap that stores the long name and associates it with the 8.3 name) ?
It woul allow testing/developping my app further (it works in collaboration with a window app, so I don't really have the choice for the filenames)
2) Is there a way to make desmume write the files to the windows directory (I'm using the "path to repository" option) ?
I ported sqlite3 to the ds and it would be extremely usefull for testing/debugging purposes
3) to use googletest in my nintendo ds app inside devmume I hacked a previous desmume version :
My apps poke information at some point in memory and desmume listens/peek to these places.
when it finds relevant information there, it stops emulation, write some files on disk and exits.
Could there be a command line option, say "-exitwithnds" that tells desmume to exit when the rom exits and to return the error return code of the rom ?
Offline
1. its supposed to be using long filenames. i checked. i distinctly observed it. are you needing 8.3 filenames?
2.a it isn't possible through compact flash emulation. something like that is planned for relatively soon, but it may take a couple of months to show up, minimum. it requires some new engineering and protocols
2.b. I have considered adding a "synch to disk" button in the compact flash config (something similar could be added as a commandline arg like --synch-on-exit=1). what this would do is scan the in-memory fat image that got written to and write back out all the files. I am afraid this might be too simplistic for you, as it may need to only write modified files or something, which would involve some additional tracking and stuff and 2.a. is a better solution at that point.
3. that is interesting. sounds feasible.
Offline
1. maybee I didn't identify correctly where my problem was coming from : turning the long file names into short ones solved the problem but maybee it wasn't related to desmume (I might have been using the official 0.96 release, would it make a difference ? )
I'll investigate the matter further and try to build a simple test case if desmume is at fault.
2. Ok, I'll cope with it.
2a will be a very nice addition in a couple of months and don't bother with 2b.
Better spend your time and energy on another place (especially if 2a is coming).
Just out of curiosity (I'm a noob in emulation/desmume internals, so bear with my stupidity ^^;),
At the moment, is there a way for desmume to know if the rom has tried to write to the "emulated fat files" that you maintain somewhere in memory ? And which file has been written to ?
If both answer are yes, maybee writting the file to the directory could be done by pausing emulation, writting the dirty emulated file to disk and rescanning the directory. But I guess that it would be slow.
And last but not least : I loooooooooove you and desmume.
Since I have managed to make libfat/nitrofs work in desmume, development speed has considerably increased (how I hated testing on the ds by removing putting in the sd card and the flashcart).
Many many thanks to the desmumle team.
Offline
yes, it makes a difference. i just said it was fixed yesterday. was 0.9.6 released yesterday?
desmume easily knows that something got written to. it might could even discern which files got written to, with enough clever code. similar clever code is why the old code was buggy and impossible to fix. it would be fairly tricky to figure this out in the new code. i don't think I am interested.
libfat has worked in desmume for a long time, it was just flaky.
Offline
Well, then, I'm sorry to report that long paths still don't work as of desmume revision 3766 (compiled it 4 hours after your 3766 commit)
as you can see there
Or am I doing something wrong ?
to launch the newly built desmume from svn, I'm using this command :
E:\Coding\Tools\DeSmuME_dev.exe --cflash-path=E:\Coding\Ankinds\Release\ E:\Coding\Ankinds\Release\Anki.nds
btw, it's really nice that desmume now automatically patches homebrew roms with the MPCF dldi. Thanks for that too.
Offline
it was lying. it was truly using LFN behind the scenes, but the console was printing the wrong filename. fixed in r3768
I guess it's nice that it autopatches, but homebrew programmers shouldve been modifying their makefile to automatically do it as part of the build process anyway..
Offline