Gp2xmess 0.11 Released

[telengard]

Hi everyone,

Got my gp2x back today with a wonderful d-pad on it (thanks DaveC!) and I can play games and not want to smash my gp2x to bits. Also motivated me to code a little bit so I dusted off gp2xmess. I read a comparison somewhere of PSP -vs- gp2x and the one issue the reviewer had with the colecovision emulation was no virtual keypad. Well, it's in there now. I couldn't find a game that used '*' and '#' so I couldn't test those but the numbers seem to work. If someone can verify those other two keys work that would be great. Also, you can remove cfg/coleco.cfg now which mapped '1' to a button, not really needed now.

Binary can be found here:

http://users.adelphia.net/~bsturk/gp2x/gp2xmess-0.11.zip

I know a lot of folks have had requests for updates etc to gp2xmess and I'm hoping I can resume work on it to some degree. Not psycho all day coding like I did when I first got the gp2x, but a more normal pace so I don't get burned out again.

Enjoy and as usual I'd love to hear your remarks etc...

~telengard

PS There is a spelling error in the posting guide if anyone cares

"When posting news don't forget to post your news source with reference links unless you are the autor of the software/hardware"

 

[TelcoLou]

Yess!! MESS!!!

Thanks for the update, will try ASAP

 

[DaveC]

Cool thanks, will test later.

I was just fiddling with the Coleco emu last week and was trying to get the keyboard to work to no avail.

This is a welcome addition, thanks

 

[zaphod79]

Many thanks - Mess is something i keep meaning to look at on my GP2x but never have - now seems like the perfect time

As to your question on buttons , i dont remember anything using the # key but Mr Do! used the * as the ingame pause (i remember pausing the game just to hear the little tune it used to play )

 

[telengard]

Many thanks - Mess is something i keep meaning to look at on my GP2x but never have - now seems like the perfect time

As to your question on buttons , i dont remember anything using the # key but Mr Do! used the * as the ingame pause (i remember pausing the game just to hear the little tune it used to play )

Excellent, thanks for the info. I think I have Mr Do (great game too!).

~telengard

 

[DaveC]

Do you think it is possible to get Atari7800 to go faster? It was real slow in the old release. Maybe the MMu hack or something?

 

[telengard]

Do you think it is possible to get Atari7800 to go faster? It was real slow in the old release. Maybe the MMu hack or something?

Hehe, it's real slow in the new release too. However, I spent some of tonight dusting off my gprof scripts and data to see if there were some things I could do to speed up a7800 emulation. As I've said in the past I'd like to avoid changing the core mess code as much as possible but I think with this driver there's no way around it. If I remember correctly the MMU hack helps with blitting. The speed issue here is system emulation nothing more. Way back when to prove it out I removed any blitting at all, blank screen. Very little change in FPS. I printed out some docs on optimizing for the ARM so here's hoping I can improve it with as little modifications as possible. This is important to me because it will facilitate merging to a new xmess which I plan on doing soon. There are some nice fixes since the version I based gp2xmess on.

I'm also considering adding Vectrex support and have *NO* idea how slow that one will be.

Stay tuned...

~telengard

 

[pariah]

Vectrex == yum!

p B)

 

[DaveC]

Do you think it is possible to get Atari7800 to go faster? It was real slow in the old release. Maybe the MMu hack or something?

Hehe, it's real slow in the new release too. However, I spent some of tonight dusting off my gprof scripts and data to see if there were some things I could do to speed up a7800 emulation. As I've said in the past I'd like to avoid changing the core mess code as much as possible but I think with this driver there's no way around it. If I remember correctly the MMU hack helps with blitting. The speed issue here is system emulation nothing more. Way back when to prove it out I removed any blitting at all, blank screen. Very little change in FPS. I printed out some docs on optimizing for the ARM so here's hoping I can improve it with as little modifications as possible. This is important to me because it will facilitate merging to a new xmess which I plan on doing soon. There are some nice fixes since the version I based gp2xmess on.

I'm also considering adding Vectrex support and have *NO* idea how slow that one will be.

Stay tuned...

~telengard

Great thanks. I do think if we are going to get any kind of speed out of these emus that some GP2X optimisations will be needed. The PC and GP2X are just WAY too much different in speed etc. Besides once you port it to the Gp2X why do we need to keep up with PC releases? I mean once an emu runs well there is really not much needed. I would rather have a fast and playable emu on the GP2X that may be a few versions behind, than an up-to-date but unplayably slow emu.

I think Vectrex will be a dog unless some tricks are used. Squidge made a Vectrex "emu" (actually a minestorm player, that is the only games that works) and it was full speed w/sound. I think he set up some sort of bitmap array of 320 x 240 and just calculated the pixels or something like that. You would obviously have to ditch floats on the GP2X. Not a big deal as you are always displaying the same res unlike a PC.

 

[telengard]

Do you think it is possible to get Atari7800 to go faster? It was real slow in the old release. Maybe the MMu hack or something?

Hehe, it's real slow in the new release too. However, I spent some of tonight dusting off my gprof scripts and data to see if there were some things I could do to speed up a7800 emulation. As I've said in the past I'd like to avoid changing the core mess code as much as possible but I think with this driver there's no way around it. If I remember correctly the MMU hack helps with blitting. The speed issue here is system emulation nothing more. Way back when to prove it out I removed any blitting at all, blank screen. Very little change in FPS. I printed out some docs on optimizing for the ARM so here's hoping I can improve it with as little modifications as possible. This is important to me because it will facilitate merging to a new xmess which I plan on doing soon. There are some nice fixes since the version I based gp2xmess on.

I'm also considering adding Vectrex support and have *NO* idea how slow that one will be.

Stay tuned...

~telengard

Great thanks. I do think if we are going to get any kind of speed out of these emus that some GP2X optimisations will be needed. The PC and GP2X are just WAY too much different in speed etc. Besides once you port it to the Gp2X why do we need to keep up with PC releases? I mean once an emu runs well there is really not much needed. I would rather have a fast and playable emu on the GP2X that may be a few versions behind, than an up-to-date but unplayably slow emu.

I think Vectrex will be a dog unless some tricks are used. Squidge made a Vectrex "emu" (actually a minestorm player, that is the only games that works) and it was full speed w/sound. I think he set up some sort of bitmap array of 320 x 240 and just calculated the pixels or something like that. You would obviously have to ditch floats on the GP2X. Not a big deal as you are always displaying the same res unlike a PC.

It's true, in order to get any decent speed out of some of the emulators I'll need to modify them. I am a little concerned though. I just went and tried Ballblazer on the a7800 and it's even slower than it was last I checked. I have since upgraded firmware. Weird. It's now choppy rather than just slow.
Looks like I have my work cut out for me.

Keeping up with the releases will be good for fixes. Especially for some of the more broken emulations like Odyssey 2. There was even a few Atari 7800 fixes (palette changes etc). Just makes the programmer's life easier.
But I'm finding I can only hold out so long. Nothing else is going to speed things up other than changing the code.

Yeah I have no clue how good the Vectrex emulation is in xmess. I'll find out at some point though!

~telengard

 

[DaveC]

It's true, in order to get any decent speed out of some of the emulators I'll need to modify them. I am a little concerned though. I just went and tried Ballblazer on the a7800 and it's even slower than it was last I checked. I have since upgraded firmware. Weird. It's now choppy rather than just slow.
Looks like I have my work cut out for me.

Keeping up with the releases will be good for fixes. Especially for some of the more broken emulations like Odyssey 2. There was even a few Atari 7800 fixes (palette changes etc). Just makes the programmer's life easier.
But I'm finding I can only hold out so long. Nothing else is going to speed things up other than changing the code.

Yeah I have no clue how good the Vectrex emulation is in xmess. I'll find out at some point though!

~telengard

What FW do you use? I use 2.1.1 is that what you use? 3.0 is bad as it takes long to boot up, I don't use that.

Odyssey 2 already has a dedicated emu out for the Gp2X. It is full speed with full sound anyway so no loss in that case.

 

[Blah]

@DaveC: The Vectrex used hardware vector graphics (a little motor controls the electron gun beam to make smooth lines, there are no pixels). Theres a fast, well-known algorithm for that, but that is beside the point. The Atari 7800 is a raster (pixel graphics) system just like the GP2X, Mega Drive, SNES, and almost everything else.

@Telengard: The MMU hack allows you to adjust the amount of cached and uncached RAM. This is a benifit for anything that needs more than the defualt 32mb of "fast" RAM. The only benfit of uncached RAM is that it can easily be accessed by the 940.

 

[DaveC]

@DaveC: The Vectrex used hardware vector graphics (a little motor controls the electron gun beam to make smooth lines, there are no pixels). Theres a fast, well-known algorithm for that, but that is beside the point. The Atari 7800 is a raster (pixel graphics) system just like the GP2X, Mega Drive, SNES, and almost everything else.

Well the vectrex didn't have a motor, it was just a yoke, like an oscilloscope. It has to be rasterized in this case, so then pixel transformations apply.

 

[Blah]

Exactly what I meant, except I didn't know it was called a yoke.

 

[telengard]

@DaveC: The Vectrex used hardware vector graphics (a little motor controls the electron gun beam to make smooth lines, there are no pixels). Theres a fast, well-known algorithm for that, but that is beside the point. The Atari 7800 is a raster (pixel graphics) system just like the GP2X, Mega Drive, SNES, and almost everything else.

@telengard: The MMU hack allows you to adjust the amount of cached and uncached RAM. This is a benifit for anything that needs more than the defualt 32mb of "fast" RAM. The only benfit of uncached RAM is that it can easily be accessed by the 940.

Hmm, this might actually be of some use depending on the bit depth of my surfaces I imagine. Wonder how hard it is to implement it to try out. I'm currently trying to remove /s and %s in the critical path of the a7800. Expensive operations...

~telengard

 

[naples39]

I'd love to see some speed increases in AppleII myself if that's possible.

 

[DaveC]

Hi everyone,

Got my gp2x back today with a wonderful d-pad on it (thanks DaveC!) and I can play games and not want to smash my gp2x to bits. Also motivated me to code a little bit so I dusted off gp2xmess. I read a comparison somewhere of PSP -vs- gp2x and the one issue the reviewer had with the colecovision emulation was no virtual keypad. Well, it's in there now. I couldn't find a game that used '*' and '#' so I couldn't test those but the numbers seem to work. If someone can verify those other two keys work that would be great. Also, you can remove cfg/coleco.cfg now which mapped '1' to a button, not really needed now.

I was trying to get the keyboard to work on the Coleco emu and I can't get it to work. When the game comes up with the menu I pull up the KB press 1 and nothing happens still. I have tried every button, what am I doing wrong?

I think Frogger uses the * key to start I think.

 

[telengard]

Hi everyone,

Got my gp2x back today with a wonderful d-pad on it (thanks DaveC!) and I can play games and not want to smash my gp2x to bits. Also motivated me to code a little bit so I dusted off gp2xmess. I read a comparison somewhere of PSP -vs- gp2x and the one issue the reviewer had with the colecovision emulation was no virtual keypad. Well, it's in there now. I couldn't find a game that used '*' and '#' so I couldn't test those but the numbers seem to work. If someone can verify those other two keys work that would be great. Also, you can remove cfg/coleco.cfg now which mapped '1' to a button, not really needed now.

I was trying to get the keyboard to work on the Coleco emu and I can't get it to work. When the game comes up with the menu I pull up the KB press 1 and nothing happens still. I have tried every button, what am I doing wrong?

I think Frogger uses the * key to start I think.

Hi DaveC,

I'm going to do some more testing tonight. I had tested it out with BurgerTime and I was able to start 1 and 2 player games. I wonder if some games use the 2nd pad instead of the 1st (sorta like the swap joystick in vice)?

I'll get back to ya... sorry that it's not working for you.

~telengard

 

[telengard]

Hi everyone,

Got my gp2x back today with a wonderful d-pad on it (thanks DaveC!) and I can play games and not want to smash my gp2x to bits. Also motivated me to code a little bit so I dusted off gp2xmess. I read a comparison somewhere of PSP -vs- gp2x and the one issue the reviewer had with the colecovision emulation was no virtual keypad. Well, it's in there now. I couldn't find a game that used '*' and '#' so I couldn't test those but the numbers seem to work. If someone can verify those other two keys work that would be great. Also, you can remove cfg/coleco.cfg now which mapped '1' to a button, not really needed now.

I was trying to get the keyboard to work on the Coleco emu and I can't get it to work. When the game comes up with the menu I pull up the KB press 1 and nothing happens still. I have tried every button, what am I doing wrong?

I think Frogger uses the * key to start I think.

Hi DaveC,

I'm going to do some more testing tonight. I had tested it out with BurgerTime and I was able to start 1 and 2 player games. I wonder if some games use the 2nd pad instead of the 1st (sorta like the swap joystick in vice)?

I'll get back to ya... sorry that it's not working for you.

~telengard

Something just occurred to me. Did you remove the cfg/coleco.cfg file? I believe that has a mapping for the '1' key which would make the keypad not work with the '1' key. You'd have to and in KEY_1 to it somehow and without a full virtual keyboard I'm not sure how to do that. So currently it's an either or thing unless you have the ability to configure gp2xmess with a real keyboard somehow (using a different version of mess etc). I guess I could keep the coleco.cfg with a mapping for both. I added this support too late at night as usual and didn't think it through 100%.

Do the other keys work for you?

 

[telengard]

Well it seems my little goal of not modifying core xmess code was somewhat of a waste.

xmess is dead, replaced by sdlmess. I'm currently moving to that to see just how much it supposedly improves performance compared to xmess. The "gloves are off" too as far as changing core code for optimization. If I can do it I will from now on.

The update to sdlmess will fix some of the reported issues w/ a2 emulation (bugs, programs not running etc) and hopefully others.

~telengard