Snes9x for ps2

[ragnarok2040]

I'm close. I just need to finish up the menus, redo some of the init code, and the gameplay loop. I also need to make some button graphics. That should be about it... Maybe a week to do the initial SVN commit, then some testing and debugging for any showstopper bugs. My estimates tend to be wrong, but I'm feeling confident right now.

[Northbear]

I'm close. I just need to finish up the menus, redo some of the init code, and the gameplay loop. I also need to make some button graphics. That should be about it... Maybe a week to do the initial SVN commit, then some testing and debugging for any showstopper bugs. My estimates tend to be wrong, but I'm feeling confident right now.

Sounds great ! Can't wait to mess around with it and play some of my favourite SNES games (I hope Chrono Trigger won't have any sound issues cuz i love the soundtrack)

Great Job !!!!

[ragnarok2040]

Yeah, I can't wait to get a build running to see if anything I've done has helped, heh. Especially for the rampant crashing *_*. The new gameplay loop uses a vsync interrupt handler to update the display, input handling, and output sound without blocking the execution of the EE. Hopefully that should speed things up.

I decided to use github for project hosting since google code doesn't support AFL 2.0. I've already uploaded ps2sdk with a few of my changes at http://github.com/ragnarok2040/ps2sdk. I used Mercurial to pull it from misfire's mirror, then converted it to subversion, fixed it up, then synced it with my local changes, then converted it to a git repository.

Now that my hosting is setup, I'm ready for when I get everything else done, .

[cosmito]

The new gameplay loop uses a vsync interrupt handler to update the display, input handling, and output sound without blocking the execution of the EE. Hopefully that should speed things up.

So does this means the above tasks are handled at the IOP side? cool.

[ragnarok2040]

Not really, .

Before, the emulator used to execute the emulation code then switch framebuffers, output sound, and handle input then start a vsync event during which the EE would be blocked waiting for the vsync event to be done. It basically hardlocked the emulator to run between vsyncs and wasted some of the EE's processing time during the vsync event. This causes those audio glitches in FCEUlta, actually.

Now, the emulation code/input handling will execute every loop, then when the vsync event occurs, it interrupts the loop to switch framebuffers and output sound. After that, the loop continues so there's no wasted EE time. It also desyncs it from the vsync period, so I'll need to use a timer or some other method to sync the emulator.

[ragnarok2040]

I decided to fix IOP rebooting when working on the new init code. Now, each EE-side RPC library as well as EE-side IOP related libraries can reset themselves if the IOP is reset and I think I've fixed any resource leaks that may have occurred. I haven't added support for IOPRP images as of yet since I haven't really had a need to use them. And I still need to test the poweroff code for IOP reboots.

It simplifies IOP rebooting down to 3 different methods.

	SifIopReset("rom0:UDNL rom0:EELOADCNF",0);
	while(!SifIopSync());

	SifInitRpc(0);

	FlushCache(0);
	FlushCache(2);

	// Same as first two lines above
	SifResetIop();

	SifInitRpc(0);

	FlushCache(0);
	FlushCache(2);

	// Same as the first two examples
	SifIopReboot("rom0:EELOADCNF");

My code worked after a thousand IOP reboots, so I think it's fine. This should allow me to swap modules pretty easily in the case that I want to make custom modules for offloading work to the IOP, in the future.

Current status:
The init code is almost done. Need to work on the gameplay loop, and finish up the rest of the menu code.

[djflexmaster79]

Hell yeah this is coming along really nice...


great work bro...

DJ

[ragnarok2040]

Thanks, .

It's getting real close. The primary init code is done, so only the configurable init code remains. I just need to make the configuration files, replace the menu strings with ones loaded from translation configuration and finish the skin. Then it's just fixing things so it compiles, then fixing any glaring logic errors. I can then commit the source to a git repository as the first working version, .

[dlsmd]

thanks, :d.

It's getting real close. The primary init code is done, so only the configurable init code remains. I just need to make the configuration files, replace the menu strings with ones loaded from translation configuration and finish the skin. Then it's just fixing things so it compiles, then fixing any glaring logic errors. I can then commit the source to a git repository as the first working version, :d.

sweeeeett!

sorry i could not help my self

[ragnarok2040]

Heh, I understand .

I've been working on the Makefile in preparation for compiling and made a nice rule for irx modules provided by ps2sdk or in ps2sdk's iop/irx directory.

%_irx.s:
	bin2s $(PS2SDK)/iop/irx/$*.irx $*_irx.s $*_irx

Now any object file ending with _irx.o will be converted by bin2s and assembled into an object file, with the intermediate .s files removed by make automatically. Freaked me out a bit when I saw make call rm without an explicit rule.

E.g. EE_OBJS=iomanX_irx.o main.o

I plan on using a gzipped tarball of modules to reduce size, but it should be useful for using bin2s with all sorts of files by changing the rule slightly.

Update:
The poweroff EE rpc code works fine having just tested it on a real ps2. I also corrected my init procedure by using SifLoadStartModule() for loading modules from the bios. The only difference is that there's an extra parameter for getting a module's result from the IOP side as well. It was the only way to determine if the cdvdman module had actually loaded correctly.