GP32 Lynx emulator

[NiN^_^NiN]

After poking through the source code and changing any values i could find (I can't program i'm just playing around) i decided to change the clock speed from 132 to 66 and to my surprise 66mhz runs the same speed as 132mhz

So after looking at it some more i relised that the problem with the handygp is the way it's being displayed on the LCD

I think the way the video is displayed is the reason it is so slow and by looking at the source code it looks like i might be right.

I'm nowere neer a programmer i can't even code text to display on the gp32 but from what i understand the video is being converted from RGB 8bit to gp32 palette values.

Could the slowdown be speed up if the video mode was in 8bit?

i changed GpGraphicModeSet(16, NULL); to GpGraphicModeSet(8, NULL); and the video was still there but the image size was actually alot bigger and it had lines through it.

But im almost 80% sure the whole slowdown is the way the video is handled.

just thought u might like to know :rolleyes:

h34r:

 

[unit3]

I'm nowere neer a programmer i can't even code text to display on the gp32 but from what i understand the video is being converted from RGB 8bit to gp32 palette values.

Could the slowdown be speed up if the video mode was in 8bit?

i changed GpGraphicModeSet(16, NULL); to GpGraphicModeSet(8, NULL); and the video was still there but the image size was actually alot bigger and it had lines through it.

I'm not sure what you mean by RGB 8-bit.. generally, you have to be over 8 bit mode to operate in RGB, 8 bit and under is generally always palette based. So if it was converting from lynx 8-bit palette mode to GP 8-bit palette mode, that would generally be how it should be operating.

If, however, you mean that it's changing from the Lynx 8-bit palette to the Gamepark's 16-bit RGB colour mode, that probably is less efficient. How much is up for debate, but you're probably right in thinking that it could be sped up by keeping the whole thing in 8-bit mode.

If I have time I'll poke around in the source and see if changing it over looks like a big job.

 

[NiN^_^NiN]

Cool

Lynx 8-bit palette to the Gamepark's 16-bit RGB colour mode

Thats what i am thinking by this code

/* Converts 8bit rgb values to a GP32 palette value */
#define GP_RGB24(r,g,B) (((((r>>3))&0x1f)<<11)|((((g>>3))&0x1f)<<6)|((((b>>3))&0x1f)<<1))

but as i said im not a programmer

but the palette is in 16bit which is of little use as the lynx is in 8bit.

The sound portion is in the source but it's been turned off from what i can see theres a bug that crashes it so thats why sound is disabled.

Guess i can't really do anything bout it :\

Oh but to compile it you need to open up the file gp32.mk which is in c:\devkitadv

and add this -lstdc++ you can put it between these 2 -lgpgraphic -lgpmem

h34r:

 

[unit3]

/* Converts 8bit rgb values to a GP32 palette value */
#define GP_RGB24(r,g,B) (((((r>>3))&0x1f)<<11)|((((g>>3))&0x1f)<<6)|((((b>>3))&0x1f)<<1))

Oh but to compile it you need to open up the file gp32.mk which is in c:\devkitadv

and add this -lstdc++ you can put it between these 2 -lgpgraphic -lgpmem

Hrm, despite what I said above, it does indeed look like the Lynx operates in an 8-bit RGB mode, and that function does just convert it to the GP32's RGB. You could make it slightly more efficient by going direct to GP32's 8-bit mode (with a palette that matches the Lynx's settings), but that code is pretty optimized, and it shouldn't slow things down much.

Also, I'm not using the devkitadvance stuff, I'm (currently) using the Debian cross-toolchain, so it may be a lot of effort to compile under my environment.

 

[tuskenraider2k]

Hi,
I've tried the emu and changed some things, but they only did a little speedup on the Geepee32 emu but not on the real GP32 :-( ..
but in this situaten I disabled the complete grafix (MIKIE_BAD_MODE & I removed the code in gpmain.cpp).. it runs about 20% faster, but would still be far to slow....

And, the handy emu worked on my 200mhz pentium with bad sound.

I think the emu itself must be optimised in some way. Perhaps some tweaks are possible for the gp32

 

[NiN^_^NiN]

I dont think we will get it at a good speed even if we put asm in it.

From what i can tell it is either bad coding for it to work on smaller sized mhz machines or its something in the code thats slowing it down.

even if we get the speed up enabling sound will make it run prob slower that what its running at now and thats not even playable.

h34r:

 

[tuskenraider2k]

Hii'

I wanted to try & experiment.. and got some speed ups.. finally )

especially the boot up of a game is faster , important or ? :unsure:

Well, but Chip's Challenge works ~40% faster with frameskip 5 further %'s..

But I don't think it will ever run at playable speeds

Greetings

download is here..:
http://www.fortunecity.de/lindenpark/may/197/gp32/

The executable is a bit large, because other stuff is included )

 

[NiN^_^NiN]

Hey tuskenraider2k

Great work i was talking with CHN the guy who ported it an hour ago and the reason it isn't going faster is cause of the timer in the core of the lynx that is the problem that was fixed in later versions of lynx but they dont have source code cause the guy stopped releasing it after a certin handy release.

But as for help you can try looking at the Mess source code of lynx i'm looking at it right now and it has been changed so im sure you could get it to work at a playable speed or even full speed

h34r: