Thanks, :D, that probably means my mountPartition() function isn't working correctly. For mass:, I'd commented out a delay loop after loading the usbhdfsd module so it would load faster in interpreter mode in PCSX2, but I'd forgotten to uncomment it when I released it. I'll make a new #ifdef guard around the loop so it only gets omitted when I'm testing. I'll release another build in a few hours when I get a chance to do some testing on my PS2.
I fixed partition mounting. I'd changed the function to use a partition name instead of a "hdd0:/" path, but hadn't changed the call in the browser so it tried to mount "hdd0:/partition/" instead of just "partition". I've also fixed it so that the history index and etc. are set back to what they were prior to trying to mount, if the mount fails. I've added the cdvd drive related calls to stop the disc spinning after a game is loaded, clear the cache for when a new cd/dvd is put in, and stop the disc from spinning if you browsed a cd/dvd and then changed to another device. I'm not sure if it will work right for putting in new discs. From my tests it took a few seconds for it to work after the call. I've changed the cnf loading to just check for hdd0:/+FCEUMM/ then mass:/FCEUMM and then mc0:/FCEUMM and then set that directory as the CNF savepath. This way you won't need a CNF file to use the harddrive or mass to save a newly created configuration. I also fixed a crash caused by an extraneous free() when booting battery backed games. I haven't managed to test it yet though. Here's the new beta :D.
For the new beta, hdd0: works but mass: still doesn't. And since when has Castlevania III been working normally? I've usually been testing with Akumajou Densetsu instead(fancier sound chip) for each release, so I forgot when that was.
In general my memory sticks only works with the IRX from uLE 3.80
I have not tried FCEUltra as I do not have any NES ROMs
If I recall correctly: "hdd0:/+partition/" not "hdd0:/partition/"
Perhaps my usbhdfsd.irx module got corrupted somehow. I'll recompile it and rebuild to see if it's that. I'll upload it and see if it helps :D.
For paths, I made a function that can assemble pretty much any path together from any device and even converts between pfs0:/ paths and hdd0:/ paths. I got the idea when looking at _splitpath and _makepath from the snes9x port.
For hdd0:/ paths:
Then I can build a pfs path by just concatenating device+dir+name+ext, where device is equal to pfs0:/ or similar mount point.
|device|partition | dir |name| ext |
The program can read mass: again. I checked to see if the cnf loading process was working properly by moving the FCEUMM folder from my memory card to my flash drive and loading and saving the config from the flash drive seems to be in working order.
It seems that when saving the save path to a folder in a hard drive partition, the partition remains mounted to pfs1: after saving because I was unable to access the partition that contained the save folder. Plus, looking at the save path in the menu showed that it saved as pfs1:/(whichever path).
Other problems I encountered include the program freezing when trying to play battery-backed games and exiting to ELF not working. I don't know if the battery-backed games problem has to do with the save path I had set(I got the same result using either hard drive or USB paths). On a side note: pressing square on a rom without sram loads the game normally(as circle would).
I hope all of these bug reports in a 24-hour period aren't too stressful or irritating.
Ahh, that's a logic error on my part, I forgot to unmount the partition the save path is on, when you browse for it and remount it to pfs0:. I'm trying to keep pfs0:/ dedicated for internal usage, like CNF loading, game saving, and such. Then when using the browser, it will mount other partitions to pfs1:, unless the partition you're browsing happens to be the same as the savepath partition, for which the mounting function will return pfs0. I missed what you said about Castlevania III, earlier, but the answer is that I added a new linker flag, and changed the sound loop into a while loop. Streamlining the code might have helped as well. I'd noticed a few small speedups, but slow games were still going slow though Castlevania III had been on the doorstep of being playable for a long while :D.
I'm experiencing crashing (freezing) on my end too with sram-enabled games, I'm going to have to run through the process of where it loads up savegames to see where the problem is. If I remember right, I had been experiencing this before but I don't remember ever solving it. It could be that the problem lies in a bug that existed before and the recent changes just highlighted it again.
The bug reports are fine, not stressful or anything. Gives me a chance to rethink the things I've done to see if there's a better way... :D, sounds like a Barack Obama quote, lol.
I've modified the browser and menus to all use a single input function that returns a newly pressed button state for parsing. This way I don't have 3 or 4 or 6 input functions all doing pretty much the same thing. I've also changed the directory list to use a linked list, to simplify things, which shouldn't cause any problems. I've also separated the browser history from the savepath browsing and elfpath browsing, this way it won't affect the first instance of the browser for selecting a rom. I think I broke booting to an elf in the previous betas, and I've fixed it back so it boots off memory card or the usb drive right now. I've gotta test the partition code after browsing for an elf/savepath on hdd0: to see if the fix I added worked. I think I fixed the sram crash, but I'm not sure, since I need to test it on my ps2 as well. I'm going to separate the code for partitioning and path parsing into a separate file from the browser, since it's starting to get cluttered, heh. I should have another release tonight or tomorrow.
Wow, seems pretty much dead on these forums the last week. Well, anyway, I think I fixed the sram problem, and I've added the function for configuring input. You'll need to configure both controllers using the 1st player's. I also fixed a bug for CNF saving/loading where if a device was found but no CNF was found, it defaulted to mc0:/FCEUMM/, now it will only do that as a last resort if no device or +FCEUMM partition is found.
keep up the good work! :)
Going to try the last couple of releases as soon as I get my PS2 back.
Thanks ragnarok2040 for a great emulator!
Thank you ragnarok!
Yeah, it's a bit slow in the PS2 front.. i've been trying to keep it up with a few multigames compilations here and there....
Right now I'm working in that HDD Install Disc that I mentionated earlier. I'm about to test your new release to include it in the disc, and release it ;)
Don't leave us ;)
btw, any new plans for FCEU or it's OK to include this new version on my new disc as it is?
EDIT: uhhh.... ragnarok, can you please make the default volume to 10? Coz when you start the fceu by the first time, the volume is set to 0 and no sound goes on.. heh Thank you!
Hrmm, the volume is set to 50 by default. Did you use an older FCEUltra.cnf file, maybe? There isn't any integrity checking for all the options, so if it misses one, it'll act like the load went fine, although some settings wouldn't be set. All the times I've tested it, without a FCEUltra.cnf, the volume always defaulted to 50, for me. I'll just fix it by initializing to default values first, then loading the CNF files, which will just set the default values to custom ones.
I'm uploading a new build, which has a fix dealing with saving the savepath to FCEUltra.cnf, as well. I had forgotten to make sure to copy over the "hdd0:" savepath in the case that it is on the hdd. You can include this version on your disc, :D. I don't have anything else really planned except for bug fixes, right now, and for tidying up the code. I've just finished my to-do list for things that need to be implemented for snes9x, and it's pretty hefty. Hopefully I'll have something to show by the end of the week.