[Pickle]

Binary: http://dl.openhandhe...?0,0,0,0,71,134
Source: http://dl.openhandhe...?0,0,0,0,46,133

Features a number of new scalers such as Notaz's gpsp interpolation scaler, scale2x filter modes.
Supports internal overlocking at wiz speeds.
Sound is still a bit rough (if anyone wants to take a look, feel free as im stumped)

[Mistabeen]

You're like a lean mean porting machine :D (my god that sounded lame xD)
Eventho I don't have a wiz yet, kudos on the port.

[atomicthumbs]

This looks good. You're gonna release it for the Pandora too, right?  :P

[Pickle]

atomicthumbs, on 01 July 2009 - 04:53 PM, said:

This looks good. You're gonna release it for the Pandora too, right? :P

It will be on pandora one way or another. I think juanvvc mentioned it, if not I could.

This post has been edited by Pickle: 01 July 2009 - 09:17 PM

[EvilDragon]

Mmmh, I tried this on two WIZ: An 1.0.0 and an 1.1.0 one.
It runs too slow on both ones. Definately slower than the real GB should. I guess that's the reason the sound sounds a bit strange - it's also too slow :)

Clockspeed doesn't change anything, it runs as slow on 200MHz than it does at 500MHz.

Are you sure clockspeed is working? Or does the emulator itself have some timing bug making it run slower? (which would explain the slightly distorted sound)?

[DaveC]

Yeah I noticed the slowness too. I think the sound is frameskipping due to the poor performance. It is a bit odd since many higher end systems are emulated much better on the Wiz like Megadrive and SNES. I would think that Gameboy should run with underclock at full speed and perfect sound due to the simplistic GB hardware. I guess the problem may be that it was ported from a fairly unoptimised emu designed to run on much more powerful PCs. GB emulation on the GP2X was never very good either.

Rlyeh's GB emu on the 133 MHz GP32 ran perfectly with great accurate sound. It is too bad he never releases the source code to his emus and he has stopped developing. That would be a much better codebase to start from I think.

Are there any other GB emus that could be ported that were made with low powered devices like handhelds in mind? Maybe something from the PSP or DS?

[chaos engineer]

Yes, I still use my gp32 for GB/GBC-Emulation. Wonderful.

[Orkie]

I ported gnuboy about a year ago, and also had the sound issue. Not being the least bit interested in emulators, I abandoned it as soon as I ran into the first problem (this one) but it was certainly not due to it running too slowly - when I removed the frame limit code it ran any game I tried on it several times faster than the original machine.

This post has been edited by Orkie: 02 July 2009 - 03:12 PM

[Pickle]

Orkie, on 02 July 2009 - 11:12 AM, said:

I ported gnuboy about a year ago, and also had the sound issue. Not being the least bit interested in emulators, I abandoned it as soon as I ran into the first problem (this one) but it was certainly not due to it running too slowly - when I removed the frame limit code it ran any game I tried on it several times faster than the original machine.

So maybe this constant is wrong: static int framelen = 16666;

Edit: Ok the constant is right 1000/60, but if you look at the frame count it hovers around 50 fps. Im taking a look at the timer function in wiz_lib to verify they are correct and on the same scale.

This post has been edited by Pickle: 02 July 2009 - 03:48 PM

[juanvvc]

Pickle, on 02 July 2009 - 05:25 PM, said:

So maybe this constant is wrong: static int framelen = 16666;

Try to remove the call to sys_sleep(delay) in emu.c, just to check. It is the only code that limits the frame time, I think. If it runs as hell (it does in Gp2x), then we have to review the framelimit code :)

Anyway, I definitely changed the framelen variable in this very version. The Gp2x is using framelen=16748. It should be a value close to 1,000,000/60.

I've considered to port GEST but it involves tons of work. Gnuboy runs reasonably ok, it is pretty easy to port and its performance is not the best but more than enough for little devices. In runs 95% of games at fullspeed in Gp2x at 200MHz, so it should run all games nearly perfect in Wiz at any speed. Unfortunately, the code of Gnuboy is hard to read, at least for me.

[DurTahar]

Mine was running slow too but for me changing the clockspeed fixed it. I only tested this on Oracle of Ages though, so I don't know if any other games run poorly. The sound is still a little off but it's far from bad.

[Pickle]

juanvvc, on 02 July 2009 - 11:56 AM, said:

Pickle, on 02 July 2009 - 05:25 PM, said:

So maybe this constant is wrong: static int framelen = 16666;

Try to remove the call to sys_sleep(delay) in emu.c, just to check. It is the only code that limits the frame time, I think. If it runs as hell (it does in Gp2x), then we have to review the framelimit code :)

Anyway, I definitely changed the framelen variable in this very version. The Gp2x is using framelen=16748. It should be a value close to 1,000,000/60.

I've considered to port GEST but it involves tons of work. Gnuboy runs reasonably ok, it is pretty easy to port and its performance is not the best but more than enough for little devices. In runs 95% of games at fullspeed in Gp2x at 200MHz, so it should run all games nearly perfect in Wiz at any speed. Unfortunately, the code of Gnuboy is hard to read, at least for me.

Taking out that line does remove any limit and runs as fast as the wiz clockspeed is. I think the wiz_lib timer method isnt correct. The timer read is using the function clock() which is the ticks since the game started. I think this is the reason for getting 50 fps rather than 60 fps.

Update: I take that back clock() should work fine, basically its the number of usec the program has run. I dont see why the fps is around 50 fps

This post has been edited by Pickle: 02 July 2009 - 05:39 PM

[Pickle]

I have an alternative: VisualBoyAdvance. But it has some negatives, no frontend and much slower. Im going to tinker with it and see how it goes.

Update:

You can get it at pickle.gp2x.de/vba.zip
Ive included a gmenu file you can put in one of the gmenu sections. You should or course change any paths. This will act as ok frontend.
Press A+X+MENU+SELECT (or gameboy buttons A+B+SELECT+START if you remap buttons)
Look at the cfg file to change settings. A frameskip of 2 seems pretty good, if you could got to 1 with overclock

This post has been edited by Pickle: 02 July 2009 - 11:15 PM

[juanvvc]

VisualBoyAdvance is extremely difficult to read (and then, enhance) and it is focused on GBA more than GB. On the other hand, it uses the SDL. GEST was a simplification of VisualBoyAdvance that should run better and it is way more understable, but it has only support for DirectX. I really think that Gnuboy is the way to go, but an "emulator fight" is really exciting and welcomed, and it can improve emulation in all senses.

In fact, I ripped the SGB support from VisualBoyAdvance as tou can see in supergb.c and CREDITS :D

BTW, maybe you can change the call to spend_cycles in the function wiz_timer_delay of wiz_lib for "do nothing". That is:

void wiz_timer_delay(clock_t ticks)
{
	clock_t ini=wiz_timer_read();
	while (wiz_timer_read()-ini<ticks);;
}

Or maybe reduce the time of spend_cycles to, I don't know, 256.

[Pickle]

juanvvc, on 03 July 2009 - 05:53 AM, said:

VisualBoyAdvance is extremely difficult to read (and then, enhance) and it is focused on GBA more than GB. On the other hand, it uses the SDL. GEST was a simplification of VisualBoyAdvance that should run better and it is way more understable, but it has only support for DirectX. I really think that Gnuboy is the way to go, but an "emulator fight" is really exciting and welcomed, and it can improve emulation in all senses.

In fact, I ripped the SGB support from VisualBoyAdvance as tou can see in supergb.c and CREDITS :D

BTW, maybe you can change the call to spend_cycles in the function wiz_timer_delay of wiz_lib for "do nothing". That is:

 void wiz_timer_delay(clock_t ticks)
 {
 	clock_t ini=wiz_timer_read();
 	while (wiz_timer_read()-ini<ticks);;
 }
 

Or maybe reduce the time of spend_cycles to, I don't know, 256.

I tried both of those ideas yesterday in the attempt to find out why the delay was off. I tried usleep in there too, but that made it worse.

Ive also found another gb emu called gngb its fast, the frame limiter if good, sound is shakey. This is C based using SDL. It actually has a built in menu, but it only changes some settings not select a rom.