GroovyMame for arcade monitors version 0.146u4_013f

[Paradroid]

Any chance of a 0.145u4 build? Usually I'm not that fussed about waiting for the next release but in this case I'm keen to try out the new CPS1 clones, especially the so-called "Street Fighter II Champion Final Japanese Version".

[Calamity]

Version 0.145u4 is uploaded:

http://mario.groovy.org/GroovyMame/WindowsATIDrivers/

groovymame32_0145u4.013f.rar
groovymame64_0145u4.013f.rar

groovymame32_0145.013e_wiimote_linux.tar.bz2
groovymame64_0145.013e_wiimote_linux.tar.bz2

0145u4_groovymame_013f.diff

Thanks go to:

- VeS for building the Linux binaries including Wiimote support.

Compiling notes

Apply patches in this order:

1) 0145u1.diff -> 0145u2.diff -> 0145u3.diff -> 0145u4.diff
2) hi_145u1.txt (http://mamestuff.lowtrucks.net/MKChamp/)
3) 0145u4_groovymame_013f.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)

Notes about the 013f groovymame patch

The syncrefresh option has been slightly modified since it was moved back to the core in patch 013e, now it works smoother when pausing/resuming, etc. Basically I have reconstructed the implementation that once existed in MAME v0.113, when the throttle function still checked for syncrefresh. Since MAME v0.114, the throttle mechanism and the syncrefresh option were separated, as the throttle function was moved into the core but the syncrefresh was kept -inexplicably- in the OSD part. For the first time, I'm considering submiting this as a patch for main line MAME.

For some reason, the OS independent 'soundsync' patch introduced in 013e can break the sound in Linux, this happens when pausing/resuming, but also can produce some lag issues it seems. Until we figure out the reason, it's possible to disable it by commenting these lines in src\emu\video.c:

Code: [Select]

void video_manager::recompute_speed(attotime emutime)
[...]
//if (m_syncrefresh && m_throttle)
// m_speed = m_speed_percent * 1000;

Patch 013f also fixes a problem with -changeres that still remained, and caused games to lock under some circumstances. Hopefully this is finally fixed.

[jimmy2x2x]

Quick question about the filename, does the '013f' indicate the version of the groovymame patches?

[Calamity]

Quick question about the filename, does the '013f' indicate the version of the groovymame patches?

That's it.

013f fixes some problems with the -changeres option, will add extended info later...

[jimmy2x2x]

Cool, would like to know whats new so I can test it out..


off to try a few of my problem games from 0.145 build see if there is any difference

[Paradroid]

Thanks for the v0.145u4 build and upload Calamity! Much appreciated. I'm halfway through installing the external controls on my Blaupunkt television. Once that's done this new build will be a nice way to celebrate! Cheers!

[jimmy2x2x]

Didn't want to make a new thread for this, but congrats and good luck to Calamity!

http://forum.arcadecontrols.com/index.php?topic=118940.0

[Calamity]

Yes it's been a nice surprise 
Thanks!!!

[Paradroid]

Congrats on the nomination! After all the help you've given me over the last 6 months, well, I had to vote for you!

[milhouse]

This is really useful....

I am having one issue.  I used the "hack" to get Groovymame and HyperSping to get along.  The first time I did something wrong because I got alot of black screens with sound until I changed to D3D.  That problem is now solved, EXCEPT that Tempest is still having that issue.

I a using an ATI HD4650 and the log is attached.  Can anyone help me troubleshoot this?

Thanks.

[dapsaille]

Hi all,

 i've got some troubles getting Mame + groovy patches and SH3 drivers for Gentoo 64bits.

 Does someone have a working src archive or a 64bit linux build with Groovy patches and sh3 (even an old version) ?

 Thanks in advance 

[Jonny G]

Here's my Simpsons log for Calamity to take a look at. Music way out of sync, running between 95% and 103% Cheers!

[Calamity]

This is really useful....

I am having one issue.  I used the "hack" to get Groovymame and HyperSping to get along.  The first time I did something wrong because I got alot of black screens with sound until I changed to D3D.  That problem is now solved, EXCEPT that Tempest is still having that issue.

I a using an ATI HD4650 and the log is attached.  Can anyone help me troubleshoot this?

Thanks.

Hi milhouse,

Thanks for posting this and sorry for the late answer. This tempest game is interesting, it's reporting a resolution of 640x480 vertical but for some reason it's treated as horizontal by the GroovyMAME patch, so when MAME tries to render the screen rotated it doesn't fit and that's why you see a blank screen.

SwitchRes v0.013e: [tempest] (1) vertical (640x480@60.00)->(640x480@60.00)->(640x480@60.00)

I don't have a clue why this is happening. I don't have a valid tempest rom to try either. Anyway I'll need to have a look at this game.

[Calamity]

Here's my Simpsons log for Calamity to take a look at. Music way out of sync, running between 95% and 103% Cheers!

Everything looks fine in your log. Please check if your computer is capable of running this games at a constant 100% with regular MAME, or with GroovyMAME and the -nomodeline option.

[Ansa89]

Little update for groovymame patch (to compile against 0.145u6):

Code: [Select]

--- 0145u4_groovymame_013f.diff 2012-04-12 15:36:38.049538976 +0200
+++ 0145u6_groovymame_013f.diff 2012-04-12 15:36:38.055538820 +0200
@@ -22,7 +22,7 @@
 +
  // the running machine
  #include "machine.h"
- #include "mame.h"
+ #include "driver.h"
 diff -Nru src/emu/emu.mak src/emu/emu.mak
 --- src/emu/emu.mak 2012-03-17 15:46:18.000000000 +0100
 +++ src/emu/emu.mak 2012-03-17 16:45:04.000000000 +0100
@@ -42,7 +42,7 @@
 
  OSDSRC = $(SRC)/osd
  OSDOBJ = $(OBJ)/osd
-@@ -317,8 +319,13 @@
+@@ -318,8 +320,13 @@
  $(EMUIMAGEDEV)/serial.o \
  $(EMUIMAGEDEV)/snapquik.o \
 
@@ -60,7 +60,7 @@
 diff -Nru src/emu/emuopts.c src/emu/emuopts.c
 --- src/emu/emuopts.c 2012-03-17 15:46:18.000000000 +0100
 +++ src/emu/emuopts.c 2012-03-17 18:19:08.000000000 +0100
-@@ -106,6 +106,7 @@
+@@ -107,6 +107,7 @@
  { OPTION_FRAMESKIP ";fs(0-10)",                      "0",         OPTION_INTEGER,    "set frameskip to fixed value, 0-10 (autoframeskip must be disabled)" },
  { OPTION_SECONDS_TO_RUN ";str",                      "0",         OPTION_INTEGER,    "number of emulated seconds to run before automatically exiting" },
  { OPTION_THROTTLE,                                   "1",         OPTION_BOOLEAN,    "enable throttling to keep game running in sync with real time" },
@@ -68,7 +68,7 @@
  { OPTION_SLEEP,                                      "1",         OPTION_BOOLEAN,    "enable sleeping, which gives time back to other applications when idle" },
  { OPTION_SPEED "(0.01-100)",                         "1.0",       OPTION_FLOAT,      "controls the speed of gameplay, relative to realtime; smaller numbers are slower" },
  { OPTION_REFRESHSPEED ";rs",                         "0",         OPTION_BOOLEAN,    "automatically adjusts the speed of gameplay to keep the refresh rate lower than the screen" },
-@@ -122,12 +123,12 @@
+@@ -123,12 +124,12 @@
 
  // artwork options
  { NULL,                                              NULL,        OPTION_HEADER,     "CORE ARTWORK OPTIONS" },
@@ -87,7 +87,7 @@
 
  // screen options
  { NULL,                                              NULL,        OPTION_HEADER,     "CORE SCREEN OPTIONS" },
-@@ -197,11 +198,37 @@
+@@ -198,11 +199,37 @@
  { OPTION_RAMSIZE ";ram",                             NULL,        OPTION_STRING,     "size of RAM (if supported by driver)" },
  { OPTION_CONFIRM_QUIT,                               "0",         OPTION_BOOLEAN,    "display confirm quit screen on exit" },
  // MKChamp Hiscore Diff options
@@ -235,15 +235,15 @@
 diff -Nru src/emu/machine.c src/emu/machine.c
 --- src/emu/machine.c 2012-03-17 15:46:18.000000000 +0100
 +++ src/emu/machine.c 2012-03-17 16:45:04.000000000 +0100
-@@ -189,6 +189,7 @@
+@@ -188,6 +188,7 @@
+ {
  memset(gfx, 0, sizeof(gfx));
- memset(&generic, 0, sizeof(generic));
  memset(&m_base_time, 0, sizeof(m_base_time));
 + memset(&switchRes, 0, sizeof(switchRes));
 
  // set the machine on all devices
  device_iterator iter(root_device());
-@@ -264,6 +265,9 @@
+@@ -263,6 +264,9 @@
  // allocate a soft_reset timer
  m_soft_reset_timer = m_scheduler.timer_alloc(timer_expired_delegate(FUNC(running_machine::soft_reset), this));
 
@@ -256,20 +256,20 @@
 diff -Nru src/emu/machine.h src/emu/machine.h
 --- src/emu/machine.h 2012-03-17 15:46:18.000000000 +0100
 +++ src/emu/machine.h 2012-03-17 16:45:04.000000000 +0100
-@@ -418,6 +418,9 @@
+@@ -407,6 +407,9 @@
  // debugger-related information
  UINT32 debug_flags; // the current debug flags
 
 + // SwitchRes patch
-+ SwitchRes switchRes; // SwitchRes data
++ SwitchRes switchRes; // SwitchRes data
 +
- // generic pointers
- generic_pointers generic; // generic pointers
-
+ // internal core information
+ palette_private * palette_data; // internal data from palette.c
+ romload_private * romload_data; // internal data from romload.c
 diff -Nru src/emu/render.c src/emu/render.c
 --- src/emu/render.c 2012-01-24 15:18:56.000000000 +0100
 +++ src/emu/render.c 2012-03-17 16:45:04.000000000 +0100
-@@ -1203,10 +1203,54 @@
+@@ -1204,10 +1204,54 @@
  void render_target::compute_visible_area(INT32 target_width, INT32 target_height, float target_pixel_aspect, int target_orientation, INT32 &visible_width, INT32 &visible_height)
  {
  float width, height;
@@ -326,7 +326,7 @@
  {
  // start with the aspect ratio of the square pixel layout
  width = m_curview->effective_aspect(m_layerconfig);
-@@ -1221,9 +1265,9 @@
+@@ -1222,9 +1266,9 @@
 
  // based on the height/width ratio of the source and target, compute the scale factor
  if (width / height > (float)target_width / (float)target_height)
@@ -338,7 +338,7 @@
  }
 
  // stretch-to-fit case
-@@ -1231,12 +1275,12 @@
+@@ -1232,12 +1276,12 @@
  {
  width = (float)target_width;
  height = (float)target_height;
@@ -354,7 +354,7 @@
  }
 
 
-@@ -1343,7 +1387,7 @@
+@@ -1344,7 +1388,7 @@
  root_xform.yscale = (float)visheight;
  root_xform.color.r = root_xform.color.g = root_xform.color.b = root_xform.color.a = 1.0f;
  root_xform.orientation = m_orientation;
@@ -363,7 +363,7 @@
 
  // iterate over layers back-to-front, but only if we're running
  if (m_manager.machine().phase() >= MACHINE_PHASE_RESET)
-@@ -1372,7 +1416,7 @@
+@@ -1373,7 +1417,7 @@
  item_xform.color.b = curitem->color().b * root_xform.color.b;
  item_xform.color.a = curitem->color().a * root_xform.color.a;
  item_xform.orientation = orientation_add(curitem->orientation(), root_xform.orientation);
@@ -1932,7 +1932,7 @@
 diff -Nru src/mame/drivers/galaxian.c src/mame/drivers/galaxian.c
 --- src/mame/drivers/galaxian.c 2012-03-17 15:45:37.000000000 +0100
 +++ src/mame/drivers/galaxian.c 2012-03-17 16:45:05.000000000 +0100
-@@ -2016,7 +2016,7 @@
+@@ -2113,7 +2113,7 @@
  static MACHINE_CONFIG_START( galaxian_base, galaxian_state )
 
  /* basic machine hardware */
@@ -1941,7 +1941,7 @@
  MCFG_CPU_PROGRAM_MAP(galaxian_map)
  MCFG_CPU_VBLANK_INT("screen", interrupt_gen)
 
-@@ -2119,7 +2119,7 @@
+@@ -2216,7 +2126,7 @@
  MCFG_CPU_VBLANK_INT("screen", fakechange_interrupt_gen)
 
  /* basic machine hardware */
@@ -1950,7 +1950,7 @@
  MCFG_CPU_PROGRAM_MAP(tenspot_select_map)
  //MCFG_CPU_VBLANK_INT("screen", nmi_line_pulse)
 
-@@ -2235,7 +2235,7 @@
+@@ -2328,7 +2328,7 @@
  MCFG_CPU_IO_MAP(mshuttle_portmap)
 
  /* sound hardware */


[Calamity]

That's great Ansa89, thanks a lot!

[evh347]

I'm having the same problem...Mame .145 and Tempest audits good...boots to a black screen.

[jrose78]

I'm having the same problem...Mame .145 and Tempest audits good...boots to a black screen.

I have galaga that boots to a blank screen but audio continues. If I disable hlsl it works.

[Megaweapon]

Compiling notes

Apply patches in this order:

1) hi_145.txt (http://mamestuff.lowtrucks.net/MKChamp/)
2) 0145_groovymame_013e.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)

This is consistently failing to compile for me at the same place:

Code: [Select]

Compiling src/mame/drivers/taitopjc.c...
src/mame/video/taitojc.c: In function 'UINT32 screen_update_taitojc(device_t*, s
creen_device&, bitmap_ind16&, const rectangle&)':
src/mame/video/taitojc.c:318: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [obj/windows64/mame/video/taitojc.o] Error 1
make: *** Waiting for unfinished jobs....

F:\mamesrc>
I am using MAME 145 (no 'u') source with the above two diffs applied in the correct order under WinXP x64 with 64-bit MinGW (no compiler front end, just Mr. Do's instructions).

Anyone else seeing this?  Any suggestions?

[Ansa89]

Could be related to this?
Moreover, remember there is a precompiled executable for windows.

[Megaweapon]

Could be related to this?
Moreover, remember there is a precompiled executable for windows.

I applied the fix in the post you linked to the groovymame diff and did a clean compile but it still failed with the same error.

I'm still getting nag screens with the precompiled groovymame executable.  Am I doing something wrong?

[Calamity]

Hi Megaweapon,

The error you are reporting is a segmentation fault of the compiler itself, not an error in the source code. Try using MAME Compiler, it's what I use to make the Windows builds.

The nag screens are enabled by default so we don't violate MAME's license. You need to manually disable it through the option you'll find inside mame.ini (generated by groovymame).

[krick]

Hi Calamity,

I was trying to compile the x64 version of GroovyMAME tonight, and I think I found a small bug that would only affect the Windows x64 version, and only at compile time.  In osd\windows\window.c, you're patching in the following snippet:

Code: [Select]

@@ -1431,6 +1543,8 @@
  // syscommands: catch win_start_maximized
  case WM_SYSCOMMAND:
  {
+ mame_printf_verbose("window_proc: WM_SYSCOMMAND %d\n", wparam);
+
  // prevent screensaver or monitor power events
  if (wparam == SC_MONITORPOWER || wparam == SC_SCREENSAVE)
  return 1;
The problem is, in the x64 compiler, the wparam variable (a WPARAM type) is a 64-bit integer, and doesn't like being printf'd as a %d.  Casting it to a 32-bit integer lets it compile fine.  More info here.

This should fix it (it compiles at least, will let you know if I run into any bugs when I get a chance to use it):

Code: [Select]

@@ -1431,6 +1543,8 @@
  // syscommands: catch win_start_maximized
  case WM_SYSCOMMAND:
  {
+ mame_printf_verbose("window_proc: WM_SYSCOMMAND %d\n", (UINT32)wparam);
+
  // prevent screensaver or monitor power events
  if (wparam == SC_MONITORPOWER || wparam == SC_SCREENSAVE)
  return 1;
Cheers - I really appreciate all you're doing for the community!

I don't have a system that I can compile this on at the moment to test, but I think that a better solution than casting the WPARAM is to use %p as the format instead of %d.  WPARAM is a pointer.   %p should print the pointer in hexadecimal regardless of size without truncating.

[Calamity]

Hi guys,

Chris Kennedy (bitbytebit), the GroovyMAME/GroovyArcade creator as you know, is not going to be actively involved with the project for a while, hopefully we have him back here at some point. He proposed Ves and I to open a new site to host the project files. By now, we've started a project in Google Code:

http://code.google.com/p/groovyarcade/

This site will contain GroovyMAME binaries, diff files and other related stuff. We still need to set up the git so you can browse the source code etc., otherwise I don't believe we'll be allowed to nest in there for too long. We'll probably need to open a separate ftp at some point to host the GroovyArcade iso files.

My intention is to keep GroovyMAME updated to mainline MAME, it's a big challenge considering I'm not a C++ programmer. VeS for his part will keep GroovyArcade updated to the Linux kernel. I like to think of this project as a collective task, so don't hesitate to get involved.

An interesting battlefront could be updating the Switchres code. Since Chris integrated Switchres into MAME, so GroovyMAME was born, the Switchres project has been somewhat frozen. All the attention and development went into GroovyMAME, so the Switchres standalone program now lacks many of the features that were added to GroovyMAME recently.

On the other hand, the GroovyMAME patch needs a partial rewrite. Though it has worked quite well for most situations, your intensive tests have revealed many issues here and there that need to get targeted at some point. Most of these issues point to the project's real Achilles heel, the routine that's resposible for picking the best mode from the ones available in the system. But also the way the monitor_specs are defined needs to be slightly changed so the user can finally get full control on the modeline generator's output.

As for the CRT_Emudriver, well I don't think those can fit in Google Code, mainly because of their hacky nature, but also because the Google Code is only supposed to host binaries from the project's open source code. So by now they'll be available from download sites like this:

http://hotfile.com/dl/153631406/c6c491e/crt_emudriver_6.5_1.2_x64_multisync.rar.html
http://hotfile.com/dl/153629728/4e81a27/crt_emudriver_6.5_1.2_xp32_multisync.rar.html
http://hotfile.com/dl/153633303/6af9a89/crt_emudriver_9.3_1.2a_x64_multisync.rar.html
http://hotfile.com/dl/153632251/22a3edd/crt_emudriver_9.3_1.2a_xp32_multisync.rar.html

Someone suggested the possibility to provide diffs or a patcher for the Catalyst stuff instead of the full binary download in order to keep safe. Well, that would be possible but unfortunately there's more than patching the files. In order to get Windows to accept the drivers you need to obtain new hashes with a specific tool that's only available from Microsoft SDK. After my experience solving people's plain drivers installation related issues, trust me when I say that this route is not viable.

[lettuce]

Shame about Chris leaving the project, i sure hope he is in good health and so will be onboard aagin soon?

But im glad that this project is being kept alive as it is a godsend for us anal MAME'ers, keep up the sterling work Calamity and Ves!!. Hopefully the little bugs GrooyMAME has get squashed at soon

[Paradroid]

My intention is to keep GroovyMAME updated to mainline MAME, it's a big challenge considering I'm not a C++ programmer.

A lofty ambition! Sounds like some exciting things are on the way, time permitting...

Thanks again for all the work you guys have put in! You've re-defined just how perfect "arcade perfect" emulation can be.

[Abubu]

I hope you'll manage to keep up the good work guys!

I'm not a C++ programmer, but I have a lot of space on my FTP server. If you need a place to store your files or just a mirror, send me a message

Good luck and thanks for your amazing version of mame!

[krick]

On the other hand, the GroovyMAME patch needs a partial rewrite. Though it has worked quite well for most situations, your intensive tests have revealed many issues here and there that need to get targeted at some point. Most of these issues point to the project's real Achilles heel, the routine that's resposible for picking the best mode from the ones available in the system. But also the way the monitor_specs are defined needs to be slightly changed so the user can finally get full control on the modeline generator's output.

I'm excited about the Google Code site.   I think the project can really benefit from some proper bug tracking and wiki documentation.

I think one thing that's really needed is a list of specific problem games and edge cases so that each build can be properly regression tested.

[Ansa89]

A little typo in the main description: "It uses AdvanceMAME or" should be "It uses AdvanceMenu or".

[lettuce]

Is there a new version of VMmaker out?, as i noticed in Calamity's Monitor Present thread that one of the default modeline spec is 'CGA' but in the version of VMMaker i have there is no 'CGA'?

[Calamity]

Is there a new version of VMmaker out?, as i noticed in Calamity's Monitor Present thread that one of the default modeline spec is 'CGA' but in the version of VMMaker i have there is no 'CGA'?

I've attached the latest beta (I already did it in some other thread).

This one has native support for magic resolutions (you only need to use the right option in the ini), uses the same format for monitor_specs as GroovyMAME, and should work more eficiently when creating mode list for multisync setups.

The CGA setup is not in VMMaker, I just added it to that post because it's the values GM picks by default (and labels as 'cga' in the logs).

[Calamity]

A little typo in the main description: "It uses AdvanceMAME or" should be "It uses AdvanceMenu or".

Well spotted, thanks.

[Calamity]

I'm excited about the Google Code site.   I think the project can really benefit from some proper bug tracking and wiki documentation.

I think one thing that's really needed is a list of specific problem games and edge cases so that each build can be properly regression tested.

The Google Code thing is quite a new one to me, hopefully we figure it out and can benefit from its features.

I get your point on the test list of games, it's something that I really want to get done soon.

[Calamity]

I hope you'll manage to keep up the good work guys!

I'm not a C++ programmer, but I have a lot of space on my FTP server. If you need a place to store your files or just a mirror, send me a message

Good luck and thanks for your amazing version of mame!

Thanks a lot for your offering, this could be a nice solution actually. Well I don't know how much bandwidth this can actually consume, probably the isos are the most problematic thing to host, I don't think these are downloaded by thousands anyway...

[Abubu]

I hope you'll manage to keep up the good work guys!

I'm not a C++ programmer, but I have a lot of space on my FTP server. If you need a place to store your files or just a mirror, send me a message

Good luck and thanks for your amazing version of mame!

Thanks a lot for your offering, this could be a nice solution actually. Well I don't know how much bandwidth this can actually consume, probably the isos are the most problematic thing to host, I don't think these are downloaded by thousands anyway...

I have sent you a private message.

Best regards.

[lettuce]

Is there a new version of VMmaker out?, as i noticed in Calamity's Monitor Present thread that one of the default modeline spec is 'CGA' but in the version of VMMaker i have there is no 'CGA'?

I've attached the latest beta (I already did it in some other thread).

This one has native support for magic resolutions (you only need to use the right option in the ini), uses the same format for monitor_specs as GroovyMAME, and should work more eficiently when creating mode list for multisync setups.

The CGA setup is not in VMMaker, I just added it to that post because it's the values GM picks by default (and labels as 'cga' in the logs).

Ok cool, just that ive got hold a, HANTAREX CT 28 EQ MONITOR the type thats in a TV case. As its a CGA monitor just wanted to know if i use that as monitor type or edit the monitor_spec line?

[Calamity]

Thanks A LOT to Abubu for providing us with a ftp for hosting the GroovyArcade iso files.

Now the download links can be found in the main page at http://code.google.com/p/groovyarcade/

[ves]

Update groovymame 145u8


Calamity please review the updated

Groovymame145u8 windows
http://code.google.com/p/groovyarcade/downloads/list

I will try to make the linux version this afternoon.

Thank you very much Abubu!!!!

[jimmy2x2x]

Very nice, any chance of a 64 bit build please?

Thanks for all the effort guys, really appreciate it

[Calamity]

GroovyMAME 0.145u8 64 bit build uploaded...
http://code.google.com/p/groovyarcade/downloads/list