FCEUltra for PS2

ragnarok2040 · #**101** 05-02-2008, 01:56 AM

Thanks,

, 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.

Update:
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

.

El Bombastico · #**102** 05-02-2008, 09:41 AM

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.

barf · #**103** 05-02-2008, 10:02 AM

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/"

ragnarok2040 · #**104** 05-02-2008, 10:38 AM

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

.

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:

Code:

  hdd0:/+SOMETHING/FOLDER/TO/FILE.EXTEN
|device|partition |   dir   |name| ext |

Then I can build a pfs path by just concatenating device+dir+name+ext, where device is equal to pfs0:/ or similar mount point.

El Bombastico · #**105** 05-03-2008, 02:52 AM

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.

ragnarok2040 · #**106** 05-03-2008, 06:01 AM

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

.

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...

, sounds like a Barack Obama quote, lol.

News Update:
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.

Update2:
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.

taonaut · #**107** 05-05-2008, 03:55 PM

keep up the good work!

orcanaoftime · #**108** 05-06-2008, 12:27 AM

Going to try the last couple of releases as soon as I get my PS2 back.

Thanks ragnarok2040 for a great emulator!

spkleader · #**109** 05-06-2008, 01:04 AM

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!

ragnarok2040 · #**110** 05-06-2008, 10:35 AM

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,

. 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.

CaptainHIT · #**111** 05-06-2008, 01:41 PM

Quote:

Originally Posted by ragnarok2040

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,

. 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.

Dude, you simply rule!

orcanaoftime · #**112** 05-06-2008, 05:30 PM

Great news!

spkleader · #**113** 05-06-2008, 05:58 PM

Great work ragnarok!
Thank you once again. Testing the new version and then closing the disc (finally)
And yes, I'm using a previous .cnf file from my memorycard...

Edit: uhhhhh.. something seens wrong ragnarok
This version can't read the roms from my hdd... (hdd0:/__boot/NES/ROMS)
Also, there's something wrong with savestates.. (my roms have long filenames.. it seens so save, but fail to load)
Where the audio, exit to elf, exit to mc configs went?

oh, I also deleted the FCEUltra.cnf file before testing it

El Bombastico · #**114** 05-06-2008, 11:32 PM

I still come across crashing when trying to play sram enabled games.

I probably should have posted earlier.

ragnarok2040 · #**115** 05-07-2008, 09:28 AM

Weird, spkleader, I haven't run across a problem loading roms from my hdd (other than battery backed games) or with loading/saving savestates. I didn't touch the savestate/loadstate code at all, so it should still be working fine... Is your savepath on your hdd? I haven't tested that feature extensively as of yet. Perhaps there's some sort of logic error on my part somewhere. I've tested loading and saving savestates with a game with a long filename, well longer than what I usually use (CONQUEST_OF_THE_CRYSTAL_PALACE.nes), and it worked fine for me, same filename being loaded and saved.

As for the path options, since my browser menu is a bit small and I need to expand it, I saved some space for the "Configure Input" option by deleting the "Configure Savepath" and "Configure Elfpath" options and just left their paths for selecting directly to configure. I'll redo it for the future release.

Do you mean the "Volume" option when you say audio config? If so, it's in the ingame menu. With all these options, I'll probably separate the menus into their own files so I can more easily modify them. Which reminds me, I left a display bug where Configuring input doesn't refresh the screen when exiting from the option... so you have to move it up or down in order to see the browser menu, but I just fixed it.

El Bombastico, your report limits the problem to a single line of code... which shouldn't have any problem working. If I remove all my custom save loading code, the function works as expected. Adding anything else causes it to crash. I'll try creating a new function to load custom savegames and reverting the normal function back to the way it was, and switching between the functions instead of doing it inside of the load gamesave function. Something I should have done in the first place, heh. I tend to keep forgetting that the quick fix isn't always the best route.

Seems that every time I touch something, something else tends to break. This version has the display bug in the menu fixed and the new custom game save function added with the original gamesave function restored.

spkleader · #**116** 05-07-2008, 10:56 AM

Thank you for your fast reply ragnarok.
It's 5:52 am and I still awake since my last report, so please bear with me..
I just downloaded the latest version and i'll try it by the morning.

By long filenames I mean long filenames with spaces and not "_"s
for example.. the game I'm using is Journey to Sillious (nice game, if you don't know, give it a try!) so my rom is called "Journey to Sillious.nes".
The samegame turned out this way ".elfJourney to.sav" and the savepath I used was the
memory card.
Sorry to report so many 'bugs' and such, but you know, it's all to enhance even more your emulator.
I'll give you a nice report for this new version by the morning and as usual but not less sincere, THANK YOU!

Oh and btw.. don't change your lineup of changes becose this 'bugs'... I'm sure you got more important things to deal at the moment and we always have the previous versions to play with

ragnarok2040 · #**117** 05-07-2008, 12:51 PM

I love that game

. Back in the day, like 13 or more years ago now, I managed to even beat it, though I had to cheat using a turbo controller for rapidfire, and it still took me a long time.

As for the bug, spaces shouldn't matter (my game filenames are messed up from being on a CD), but it looks like there might be a problem with a pointer somewhere. Somehow, .elf+FileBase (first few letters of the filename which should be "Journey to Sillious" since it's under 20 characters) is being copied to the .sav, and then iNESGameCRC32 isn't being added as well. I might not be using sprintf correctly, utilizing the same variable as an argument for an input string and output string could be corrupting it. Your rom could be a UNIF type rom as well, for which I hadn't added that type of save naming because it lacked CRC32 checksums. It should have defaulted to Journey to Sillious.sav, though. I've just changed it to use the first 8 characters of the MD5sum now.

sprintf(FileBase,"%s%08X", FileBase, iNESGameCRC32) would be:
Journey to SilliousABCD1234.sav
should be the normal output, where ABCD1234 is the CRC of the rom.

Since it's a simple thing to test, I've modified it so it copies FileBase to a temporary string, then uses that temporary string + CRC32 or MD5 to create the filename to FileBase.

spkleader · #**118** 05-07-2008, 06:37 PM

Ok, I just tried this new compilation ragnarok, totally skipped the version from the previous post...
So I deleted all the files from the FCEUMM folder in my memory card, copied the new elf to hdd0:\__boot\NES\ folder and launched it. It loaded, I configured the input for player one. and then went to the roms dir hdd0:\__boot\NES\ROMS.
roms are visible now, but when I tried to load one, emulator crashed.
Shall I test the one from the previous post?