hiscore diff (with no nag/white box removal)

[MKChamp]

LOL...it's been out! 
You don't see it with the following at the bottom: Last Edit: October 14, 2010, 11:59:23 AM by MKChamp ?

[WhereEaglesDare]

  Ahh I was looking at the end of the thread for the post...     Sorry

[tkeahi]

I used the 140 diff file and compiled 140 but still get the "Initializing" and "Loading" white boxes. All the other nag screens get skipped.

-Disregard, I see the patch got updated. I'll download it and try again.

[MKChamp]

I used the 140 diff file and compiled 140 but still get the "Initializing" and "Loading" white boxes. All the other nag screens get skipped.

-Disregard, I see the patch got updated. I'll download it and try again.

yea...I haven't been testing...at all...really...and another mamer told me that a screen was showing up, so I re-uploaded a new 140 patch. Sorry to waste your time...let me know if anything else seems lacking...

[abelenki]

MKChamp, just wanted to let you know that your patch works brilliantly with MESS/MESSUI.

i just tried to compile MESS/MESSUI 0.140 (first time in my life). i applied hi_140.diff to MAME/MESS source tree, then compiled, and MESSUI doesn't have nag screens anymore.

awesome!! thanks a lot!!

p.s.: hi_140.diff doesn't apply to MAME 0.140u1 source tree, so i'm patiently waiting for hi_140u1.diff.

[MKChamp]

p.s.: hi_140.diff doesn't apply to MAME 0.140u1 source tree, so i'm patiently waiting for hi_140u1.diff.

Wait no more. 140u1 is up and ready. There was quit a bit changed from 140 to 140u1...so let me know if everything still works!
...and thanks for hosting the files!

[abelenki]

Wait no more. 140u1 is up and ready. There was quit a bit changed from 140 to 140u1...so let me know if everything still works!

many thanks!! i will check it out when i'm at home.

...and thanks for hosting the files!

no problem. it's a pleasure for me to host such a great project.

[wweumina]

There does seem to be a problem with the 140u1 hi score diff.  I've compiled 140u1 and it works fine, but when adding the hi patch I now can't play Donkey Kong.  I get garbage over the high score tables and it seems to have deleted my high scores for the game.  Not game to try any other games after losing the DK high scores.

[MKChamp]

I actually 'use' dkong when testing and it works fine for me. Try a clean compile.

[WhereEaglesDare]

There does seem to be a problem with the 140u1 hi score diff.  I've compiled 140u1 and it works fine, but when adding the hi patch I now can't play Donkey Kong.  I get garbage over the high score tables and it seems to have deleted my high scores for the game.  Not game to try any other games after losing the DK high scores.

I just tried it and it works fine for me.  i even made a new hi score on mine and it stayed.


BTW I really like the new font they are using on the UI.

[wweumina]

I actually 'use' dkong when testing and it works fine for me. Try a clean compile.

Yeah, sorry it was a strange one.  I deleted the dkong.hi file and it worked again.  I had to dig out my hex editor to put my scores back in but it's ok now. 

[yotsuya]

I just did my own compile for the first time (yay), and I too had the same issue with Donkey Kong (and only DK). Deleting the hi file makes it work, but then it happens over again. Wierd.

[B2K24]

Thank you very much MKChamp, Everything working great here. When u2 is released I will be happy to test anything you post.
Thank you so much for your time and work

[B2K24]

Many Thanks for having 140u2.diff posted so soon after the source release. Your work is very much appreciated

[MKChamp]

No need to thank me, I do it for myself 
But you're welcome!

[bitbytebit]

This patch when applied after the newest 140u2 hiscore patch will fix a bug that crept in which the machine memory was being freed before the hiscore callback read the hiscore to the games .hi file.  This probably is why some people had some games work and others not, or experienced random working and not.  I think in Windows the memory was still there, just technically freed but it was accessing memory that was freed to the operating system already (just lucky sometimes).  In Linux this turned out to always fail, at least on certain games, but not all of them.  Strange but this definitely is a bug that this patch fixes...

Code: [Select]

diff --git a/src/emu/machine.c b/src/emu/machine.c
index 6726451..dadcf47 100644
--- a/src/emu/machine.c
+++ b/src/emu/machine.c
@@ -332,10 +332,6 @@ void running_machine::start()
        crosshair_init(this);
        sound_init(this);
       
-  //MKCHAMP - INITIALIZING THE HISCORE ENGINE
-       if (!options_get_bool(&m_options, OPTION_DISABLE_HISCORE_PATCH))
-               hiscore_init(this);
-
        // initialize the debugger
        if ((debug_flags & DEBUG_FLAG_ENABLED) != 0)
                debugger_init(this);
@@ -361,6 +357,10 @@ void running_machine::start()
        // set up the cheat engine
        m_cheat = auto_alloc(this, cheat_manager(*this));
 
+       //MKCHAMP - INITIALIZING THE HISCORE ENGINE
+       if (!options_get_bool(&m_options, OPTION_DISABLE_HISCORE_PATCH))
+               hiscore_init(this);
+
        // disallow save state registrations starting here
        state_save_allow_registration(this, false);
 }


Here's the way I tracked it down, shows the backtrace of it trying to access the machine when it was already technically freed...

Code: [Select]

#0  0x000000000202703d in astring_c (str=0x80) at src/lib/util/astring.c:499
No locals.
#1  0x000000000040f280 in astring::operator char const* (this=0x80) at src/lib/util/astring.h:344
No locals.
#2  0x000000000040f69e in device_config::tag (this=0x0) at src/emu/devintrf.h:287
No locals.
#3  0x000000000040f6e6 in device_t::tag (this=0x6de6d90) at src/emu/devintrf.h:441
No locals.
#4  0x0000000000430dea in device_memory (device=0x6de6d90) at src/emu/dimemory.h:192
        intf = 0x0
#5  0x0000000000430e6a in device_get_space (device=0x6de6d90, spacenum=0) at src/emu/dimemory.h:204
No locals.
#6  0x0000000001e69af0 in copy_from_memory (machine=0x6d5c1e0, cpu=0, addr=20104, dest=0x6de6ff0 "\260\371B\a", num_bytes=4) at src/emu/hiscore.c:89
        i = 0
        targetspace = 0x6de6ff0
#7  0x0000000001e6a181 in hiscore_save (machine=0x6d5c1e0) at src/emu/hiscore.c:280
        data = 0x6de6ff0 "\260\371B\a"
        mem_range = 0x73b0f80
        filerr = FILERR_NONE
        f = 0x6d5d5c0
        fname = 0x6d58940
#8  0x0000000001e6a25d in hiscore_close (machine=...) at src/emu/hiscore.c:312
No locals.
#9  0x0000000001b75176 in running_machine::call_notifiers (this=0x6d5c1e0, which=MACHINE_NOTIFY_EXIT) at src/emu/machine.c:778
        cb = 0x73b0f60
#10 0x0000000001b74523 in running_machine::run (this=0x6d5c1e0, firstrun=true) at src/emu/machine.c:453
        error = 0
#11 0x0000000001b70cac in mame_execute (osd=..., options=0x6d38b50) at src/emu/mame.c:203
        gamename = {<_astring_base> = {text = 0x7fffffffe06c "pacman", alloclen = 52,
            smallbuf = "pacman\000\377\377\177\000\000.\257\003\002\000\000\000\000\264\032|\003\000\000\000\000`\227\324\006\000\000\000\000\255+|\003\000\000\000\000P\213\323\006\000\000\000"}, <No data fields>}
        driver = 0x2d87d40
        config = 0x6d6c010
        machine = 0x6d5c1e0
        firstgame = false
        firstrun = true
        exit_pending = false
        error = 0
#12 0x0000000001b0a3e4 in cli_execute (argc=2, argv=0x7fffffffe4a8, osd=..., osd_options=0x364ccc0) at src/emu/clifront.c:175
        gamename_option = 0x6d28f5c "pacman"
        driver = 0x2d87d40
        exename = {<_astring_base> = {text = 0x7fffffffe1dc "mame64", alloclen = 52,
            smallbuf = "mame64\000\004", '\000' <repeats 36 times>"\202, \303\336\367\377\177\000"}, <No data fields>}
        options = 0x6d38b50
        result = -1
        gamename = {<_astring_base> = {text = 0x7fffffffe21c "pacman", alloclen = 52,
            smallbuf = "pacman\000\000\000\000\000\000\350\213\264\367\377\177", '\000' <repeats 18 times>"\300, \343\377\377\377\177\000\000\340\243@\000\000\000\000"}, <No data fields>}
#13 0x00000000013183f6 in main (argc=2, argv=0x7fffffffe4a8) at src/osd/sdl/sdlmain.c:328
        osd = {<osd_interface> = {_vptr.osd_interface = 0x364d850, m_machine = 0x6d5c1e0}, <No data fields>}
        res = 0


This occured at least on pacman and tempest, donkey kong games seemed to somehow still work, guessing it's in how the machine for each game handled freeing the resources and probably some luck of memory being there even when already freed from mames ownership.

[MKChamp]

Thanks for the info. I re-uploaded 140u2 patch with the change...and they'll all have the move going forward.
Thanks again for the feedback!

[Creeper]

Ok, I'm new to compiling so don't judge me. Here's what I'm doing:

I've taken a fresh Mame139 source and I'm trying to compile using Mr. Do's instructions. I took the hi_139.diff that is supplied in this thread and I put it in the source directory. I patched mame with the diff and it seemed to work fine. I used the makemame.bat to start the compile and it seemed to be working although it took under 1 minute which is suspicious, but the file size was still 40mb+ and looked healthy. I then took the new EXE and copied it into my master mame139 directory I've been using. I also added the hiscore.dat and hi directory. When running the exe, nothing happens, a cmd flashes but nothing else.

The odd thing is that when I compile without using the hi_139.diff, the compile is completely normal. Takes about 10-15 minutes and it runs perfectly in the master directory.

Did I do something wrong with the patching? I changed the patchmame.bat to:

set path=C:\MinGW\mingw64-w32\bin

patch -p0 -E <hi_139.diff

The set path is correct and as I said it seemed to work.

[jahilton2002]

is there a u3 release for this thx 

[WhereEaglesDare]

Ok, I'm new to compiling so don't judge me. Here's what I'm doing:

I've taken a fresh Mame139 source and I'm trying to compile using Mr. Do's instructions. I took the hi_139.diff that is supplied in this thread and I put it in the source directory. I patched mame with the diff and it seemed to work fine. I used the makemame.bat to start the compile and it seemed to be working although it took under 1 minute which is suspicious, but the file size was still 40mb+ and looked healthy. I then took the new EXE and copied it into my master mame139 directory I've been using. I also added the hiscore.dat and hi directory. When running the exe, nothing happens, a cmd flashes but nothing else.

The odd thing is that when I compile without using the hi_139.diff, the compile is completely normal. Takes about 10-15 minutes and it runs perfectly in the master directory.

Did I do something wrong with the patching? I changed the patchmame.bat to:

set path=C:\MinGW\mingw64-w32\bin

patch -p0 -E <hi_139.diff

The set path is correct and as I said it seemed to work.

You want to try HeadKaze's Compiler.  It's a piece of cake and does the commands for you.

http://www.headsoft.com.au/index.php?category=mame&page=mc64

[jahilton2002]

your a star  thx mate

[Creeper]

Nice, yea Mame compiler worked much better but I still have a few questions and I'm not sure if this is for MKchamp or Headkaze.

I patched my Mame using the hi_139.diff and it worked fine, I compiled using Mame compiler and it also worked fine. I took the new EXE and dumped it into my Mame folder and started playing Donkey Kong Jr. I played for a bit and got a decent score, entered my name and what not and then hit reset to see if the score kept. It didn't. I exited to windows, and check the HI directory to see if there was anything and sure enough there was a dkongjr.hi file in there. What am I missing? It seems like its working but the game won't recognize it.

Also when I go to pause any game (mapped to keyboard F10) Mame crashes. Using the regular Mame.exe and it pauses fine.

Any help?

[WhereEaglesDare]

By reset do you mean you hit the MAME Reset key or escaped out and went back in..  If you reset the game (I think it is F3) it wipes it clean.  Get a score and hit escape and go back in and it will save it.

Also, Ive never had an issue with pause but I have had MAME crash on sometimes lately after exiting some games, like BioMechanical Toy, it will crash and lock up my Front End and I have to power down the cabinet to get it back up.

[Creeper]

Yea, I've been using the soft reset. I just tried exiting and going back in, you are right it is working. Is there anyway to soft reset without losing your high scores?

Thanks for your help

[WhereEaglesDare]

Yea, I've been using the soft reset. I just tried exiting and going back in, you are right it is working. Is there anyway to soft reset without losing your high scores?

Thanks for your help

Hmm I dunno.  MKChamp would know if there is.  Its probably a diff you can add in the mix to change the softreset.  Id like to know too, Id like to use reset but just dont and never though to ask about it.

[Creeper]

After further research it would appear that anything to do with Mame admin buttons is freezing Mame for me. This includes just hitting tab on the keyboard to bring up the Mame menu. 

[WhereEaglesDare]

After further research it would appear that anything to do with Mame admin buttons is freezing Mame for me. This includes just hitting tab on the keyboard to bring up the Mame menu. 

So if you hit TAB the thing locks up, how do you get out of MAME to fix it?  Do you have to restart the PC?  Do you have another PC you can try the MAME on to see if it is isolated to your PC?  What are the Specs of the MAME PC?  Are you using a front end?  What version MAME are you using?  140u2 hi?

[Creeper]

When Mame crashes I get a windows error saying mame has stopped working, then it goes straight back to Maximus Arcade.

I just took a completely fresh Mame139 with the compiled mame.exe and nothing but a donkey kong rom. I ran it and it works perfect. I copied my old mame.ini file into the mame directory and tried to run it again but it instantly crashes. So I create a brand new mame.ini file and try that, works perfect. Long story short as soon as I enable direct draw for my ArcadeVga and d9800 Mame won't run, but it works perfect with the old copy of Mame.

Any thoughts?

[kaptainsteve]

Hello,

Can somebody please help?

What do you do when compiling mame and you get this;

 "mingw32-make' is not recognized as an internal or external command, operable program or batch file.

Any suggestions will be appreciated.

Thanks.

Steve

[Bonechip]

Thank you MKChamp for keeping up with the Diff's.

[abelenki]

What do you do when compiling mame and you get this;

 "mingw32-make' is not recognized as an internal or external command, operable program or batch file.

it means, your MingW/bin folder is not set in your system paths. before compiling, make a .bat file with contents like this for patching:

Code: [Select]

set path=c:\MinGW\bin
patch -p0 -E < hi_141.diff
and for compiling:

Code: [Select]

set path=c:\MinGW\bin
make all
otherwise, read compiling guides.

[nintendoid]

hi I assume everyone is trying this on mame32... do you know if this works for just mame .141??? I too need the Donkey Kong save 

If someone has got this working please let me know... 

[WhereEaglesDare]

Works great with regular old MAME. Thats what I use.

[abelenki]

do you know if this works for just mame .141???

hiscore diff works with all MAME and MESS versions for which it's available - see the first page. namely - 0.108 to 0.141.

[wonderalex]

Ok - I give up.

I've been at this for 2 hours and I'm not getting anywhere.

I'm trying to re-compile MAME 135b (that's the MAME library I have) with the hiscore diff for my bro (who wants his hi scores - even if I cream him everytime I visit his place    ) .

I've tried Mr.Do's tutorial - the diff installs, but the compiling always ends in a few minutes with an error. When I try it again - it ends in seconds with an error.  I'd show you the code but I can't for some reason.

MAMECompiler64 1.17 and 1.18 won't even launch.

Help?

WonderAlex

[WhereEaglesDare]

I dunno, why not try to get the latest sets, 140 or 141, 140u1 has the hacked Donkey Kong 2 on it...

[MKChamp]

I believe the b means binary...or exe. You need the s or source to compile your own. Read and get headkaze's mame compiler. Everyone says it makes it as easy as turning your computer on.


Edit: I might have misread. I thought u were saying you tried to compile starting with the binary. At any rate, read headkazes thread thoroughly.

[Donkbaca]

Agreed  used headkaze's compiler. A chimp could use it, it's that easy

[wonderalex]

Yeah - I know 135s is the source (I'm not THAT daft  ), and I've followed the instructions yet I still get an error. I guess I could use the latest build and continue to use the 135 library until I get it updated - I'll think about it.

The real weird thing is Headkaze's compiler will not work. It doesn't even start.

I'm going to try it again with both flavours of MAME on my workstation (with XP) at the office over lunch.

I'll report back.

WonderAlex

[Donkbaca]

You have to completely delete the mame program, then re-download the source and diffs and start from scratch.  Otherwise it won't work.  You don't have delete the roms or the samples or that stuff, but you need to delete the exe and the other stuff in the root file, and start from scratch to use the compiler. Otherwise the compiler gets confused.