GP32 More About Gp32 Sound Bug

[Franxis]

Hi,

I have changed the development of my MAME port to DevKitArm r11 + GpSdk, but i have the same problems than before...

I.e. Gunsmoke, Commando, etc drivers have vertical scanlines and are affected by gp32 sound bug. Then i remove a not used variable in a generic mame structure and the problem is solved itself (perfect image and sound quality), but the problem starts to appear in another drivers not affected previously by these bugs.

I'm not sure, but it seems that these problems are due to memory alignment, the position of the drivers into the memory or maybe due to the compiler.

Any suggestions?

If i have no solution i will have to do a lot of fxe files (each fxe for a collection of drivers and to do some tricks witch each of them until games will be not affected by these problems, because they seem to be random...).

 

[K-teto]

Im more interested in the multi fxe version...

 

[pea]

Hi,

I think I have problems that may be related (but may not). I have alignment issues in my code. For example, when I try to compile sprites into my apps, Only the first will work, and maybe the second if it happens to be aligned, but none after that. Even if I add __aligned etc this does not seem to help (or just cause issues in other places). These issues also seem to be random, and sometimes I think I fix it, and something else is broken. Maybe the -03 compiler flag ignores __aligned keywords in the code or something really stupid like that!

Other people, however, are not having any problems with this, so what I am thinking is that it is due to something specific to my dev environment - e.g. Compiler flags, or perhaps an older/newer version of a particular exe or library.

Perhaps the problems are related? How do I find out what my dev environment is? It is gcc of some kind, but not having much experience with gcc, I don't know exactly what...

 

[Franxis]

Im more interested in the multi fxe version...

​

There is no need to have multiple fxe because all games will run ok in only two separate fxe files. I have checked also 90% of games run ok with only one fxe file.

 

[DaveC]

Im more interested in the multi fxe version...

​

There is no need to have multiple fxe because all games will run ok in only two separate fxe files. I have checked also 90% of games run ok with only one fxe file.

​

You could have all of the Pac-Man games separate in Multipac.FXE That was a nice emu hopefully that would run well with sound. Was that updated at all?

 

[Franxis]

DaveC, all Pacman games (and a lot of more variants than MultiPac) are running in MAME now, almost as good as in MultiPac. Don't Worry .

 

[SvOlli]

I'm not sure, but it seems that these problems are due to memory alignment, the position of the drivers into the memory or maybe due to the compiler.

Any suggestions?

The problem is only connected to memory alignment indirectly. The databus isn't fast enough to for both cpu controlled and direct memory access. Best thing you can do is to make sure that you access the memory always in 32bit boundries, e.g. by reading and writing data as ints instead of chars. It took me weeks to figure that one out, not knowing anything about the sound bug.. :angry:

 

[DaveC]

DaveC, all Pacman games (and a lot of more variants than MultiPac) are running in MAME now, almost as good as in MultiPac. Don't Worry .

​

But you said *almost* as good. Multipac had sound and some speed issues. Almost as good would mean that the games run worse in MAME. I would prefer better not almost as good. That is why it may be an advantage to improve MultiPac so that it would run better than it does now which would mean it would have better more accurate sound and better speed at a lower clock rate. It sounds like everything in MAME will need to be run at 166 with sound and it still needs alot of frameskip. Running at 166 eats up batteries too fast, frameskip makes it choppy. If you just want to play a Pac-Man game and could get it running at 0 frameskip and perfect speed with sound at 133 it would be good to just use Multipac, wouldn't it?

 

[Franxis]

DaveC, yesterday i changed the z80 emulator used in MAME with a better one, and the speed has been improved and also the vertical scanlines an sound bugs have disappeared. The speed in Pacman is perfect now and the sound is better than Multipac. I will make you to change from Multipac to Mame, i promised you, i bet my di.... DD.

 

[Wonder Boy]

DaveC, yesterday i changed the z80 emulator used in MAME with a better one, and the speed has been improved and also the vertical scanlines an sound bugs have disappeared. The speed in Pacman is perfect now and the sound is better than Multipac. I will make you to change from Multipac to Mame, i promised you, i bet my di.... DD.

​

WoNDeRfuL.
:-D

DaveC... relax you man, wich Franxis knows what does

Un Saludo.

 

[DaveC]

DaveC, yesterday i changed the z80 emulator used in MAME with a better one, and the speed has been improved and also the vertical scanlines an sound bugs have disappeared. The speed in Pacman is perfect now and the sound is better than Multipac. I will make you to change from Multipac to Mame, i promised you, i bet my di.... DD.

​

Do you use Reesy's ASM Z80 core?

At what clock speed does Pac-Man run with sound? How about Ms. Pac-MAN (was a bit slower in Multipac) Multipac works well at 133Mhz.

Also is it possible that you can fix the gamma for the background for either MAME or Multipac? Color 0 (black background) should be an RGB value of 0,0,0 and not grey like multipac is now. A light background makes the contrast not good especially for the BLU. I can help give an example of correct background gamma if you need me to, so that you know what I am talking about.

Thanks much