mame 2003 gamelist.xml with data from the binary

markwkidd

I need to spend some time with all of your work on this in order for me to keep track of the different enhancements that need to be made. I would like to help as much as I can.

Very exciting!

I thought I would get started with a straightforward update: flagging goldnaxa as unplayble. I have submitted a PR: https://github.com/libretro/mame2003-libretro/pull/340

markwkidd

@grant2258 could you talk me through your Altered Beast fix?

Do I understand correctly that changing the Makefile alone does not address the problem, there is a bug in the mame2003 m68000 CPU which you are fixing by importing part the Musashi emulator?

grant2258

Mame does use the Musashi emulator in it core its curently 3.3 the latest version is 3.4. There is no problem with this update.
just grabs the source

git clone https://github.com/kstenerud/Musashi.git
history.txt
m68kconf.h
m68kcpu.c
m68kcpu.h
m68kdasm.c
m68k.h
m68k_in.c
m68kmake.c

thats all the files that are there.

Now you need to compile the source file that generates the m68k emulator source.

with
gcc m68kmake.c -g -O2 -std=gnu99 -o m68kmake

now execute this

pi@retropie:~/RetroPie-Setup/Musashi $ ./m68kmake

            Musashi v3.3 68000, 68010, 68EC020, 68020 emulator
            Copyright 1998-2000 Karl Stenerud (karl@mame.net)

Generated 1962 opcode handlers from 513 primitives

what does this do it spits out these files
m68kopac.c
m68kopdm.c
m68kopnz.c
m68kops.c
m68kops.h

sudo cp *.c ../tmp/build/lr-mame2003/src/cpu/m68000/
sudo cp *.h ../tmp/build/lr-mame2003/src/cpu/m68000/

just replaces the files that where there

I believe the subtle differences the way in the way gcc compiles the older version is the problem. If you used the original version of gcc to compile mame 078 it will probably work. But there no need to do that when the cores been updated

grant2258

make files uses this for the core

SOURCES_C += $(CORE_DIR)/cpu/m68000/m68kops.c $(CORE_DIR)/cpu/m68000/m68kopac.c
$(CORE_DIR)/cpu/m68000/m68kopdm.c $(CORE_DIR)/cpu/m68000/m68kopnz.c
$(CORE_DIR)/cpu/m68000/m68kcpu.c $(CORE_DIR)/cpu/m68000/m68kmame.c

https://github.com/grant2258/mame2003-libretro/commit/9955f1c75066cb4b9c2c2b511ffbb64c5d3442a7

if you want to see the diff of the files

dankcushions

probably the best way to solve this is to have the musashi git master as a git submodule in mame2003.

grant2258

yea that could work but the makefile will need updated to do the source generation as well. I need to get ready for a new job interview. If any other info is needed let me know.

ps really sorry for diverting this threads topic but its kinda related to it all in a way. It would be nice to have a option to dump the the xml from the retroach menu

markwkidd

Is there any reason not to just permanently add the generated Musashi source files to the mame2003 /src/cpu/m68000 folder?

In other words, do we have to dynamically generate the Musashi code every time we build mame2003?

grant2258

@markwkidd

no shoud be fine just make sure to copy all .c and .h files it should be good.

Its only if you working on bugs or something updated in m68k_in.c the changes wont happen because m68kmake parses this file and spits out the freshly made files. posted above. again if someone is working on this core they should know that anyway . A quick fix is add the instuctions to compile it to to scriptmodules/libretrocores/lr-mame2003.sh if anythign is changed in the core.

dankcushions

This post is deleted!

grant2258

this is how the original make file does it

compile generated C files for the 68000 emulator

$(M68000_GENERATED_OBJS): $(OBJ)/cpu/m68000/m68kmake$(EXE)
@echo Compiling $(subst .o,.c,$@)...
$(CC) $(CDEFS) $(CFLAGSPEDANTIC) -c $*.c -o $@

additional rule, because m68kcpu.c includes the generated m68kops.h :-/

$(OBJ)/cpu/m68000/m68kcpu.o: $(OBJ)/cpu/m68000/m68kmake$(EXE)

generate C source files for the 68000 emulator

$(OBJ)/cpu/m68000/m68kmake$(EXE): src/cpu/m68000/m68kmake.c
@echo M68K make $<...
$(CC) $(CDEFS) $(CFLAGSPEDANTIC) -DDOS -o $(OBJ)/cpu/m68000/m68kmake$(EXE) $<
@echo Generating M68K source files...
$(OBJ)/cpu/m68000/m68kmake$(EXE) $(OBJ)/cpu/m68000 src/cpu/m68000/m68k_in.c

grant2258

this will be fine mark if it needs updated ill do it. I looked at the fba alpha they fixed it by using 3.32 mame2000 is using 3.1 so i think a few cores can do with the update if they have problems i dont imagine it will be getting updates too often anyway

grant2258

just pull it from here i already did the updates https://github.com/grant2258/mame2003-libretro

there really isint that many differences its just the because of the ms dos crlfs

grant2258

Well we can assume it will be added or a makefile will be done. Either way the core is fixed.

Here is a screenshot of what i did with the data we dumped to make a games list. I never added the number of players ill do that when i get time. Also notice the game rom names are right as well. This is great for people working on mame as well picking a game on if its working status. It also verifys the catver.ini .

ps this is how i found the golden axe issue so i might as well pick that game for the example.

Riverstorm

@grant2258 said in mame 2003 gamelist.xml with data from the binary:

Here is a screenshot of what i did with the data we dumped to make a games list. I never added the number of players ill do that when i get time.

That's really slick the number of players would be great. I manually tweak my gamelist.xml files to add 4 players to the title of the game just so it's easier when a group is playing. Is there an easy way/steps to access this information? It has to beat running each game to know if it's working! :)

grant2258

@riverstorm

details on post 10 just dowload it the data i dumped is in there so you dont need to get a dump.

then run python run.py

and itll make you the gamelist.xml

ill add the player counter i had that in my first version but i re done the code to use classes.

dont rely on unplayable being true thats the point of this. its to test if the information is right. Its more a developer thing to be honest it helps identify if a games status is wrong it can be reported and updated so we all have a better experience.

grant2258

@riverstorm

added the players to gamelist.xml

also uploaded to github. I think this is a bad idea because im useless with github be we will see how we go. I know mamemagic is a terrible name lol

https://github.com/grant2258/mamemagic2003.git

Riverstorm

@grant2258 said in mame 2003 gamelist.xml with data from the binary:

added the players to gamelist.xml
also uploaded to github. I think this is a bad idea because im useless with github be we will see how we go. I know mamemagic is a terrible name lol

Nice, thanks, Mamemagic is as good as any handle, it's just fine. :)

grant2258

@riverstorm np if you find any issues let me know

grant2258

@markwkidd

hiya mark would like to finish this catver.ini update for you. Now we have to make a few choices. There is only 5 conflicts in the catver.ini. Thats the only ones that need marked in.

Aqua Rush (AQ1/VER.A) Unplayable / please verify and update flag in driver source
Die Hard Arcade (US) Unplayable / please verify and update flag in driver source
Free Kick (bootleg) Unplayable / please verify and update flag in driver source
Major League Unplayable / please verify and update flag in driver source
Run and Gun (World ver. EAA) Unplayable / please verify and update flag in driver source

now we are using your current catver.ini as the template. The new catver we spit out will mark lightgun and all the unplayable as default so all we have to do is bring the original catver.ini you used before adding the unplayables and lightguns and just add them 5 as unplayable and leave the rest to default genre list. Unplayable or lightgun are marked when the new carver.ini is made.

we could call the new catver.ini we make mame2003.ini and use the normal carver.ini to only mark games that need checked and verified and changed in the source

I will Update github source for Major League. It segafaults on mame 078 and mame 2003 it is an unplayable.

Free Kick (bootleg) is playable i think that ws just a miss match with original Free Kick romname

Run and Gun (World ver. EAA) works you just need to initialize the eeprom to do that hold down service mode and reset the game. its slow on the pie though but thats no reason to mark it unplayable for people using other systems. I imagine will need to do this on all versions

markwkidd

@grant2258 said in mame 2003 gamelist.xml with data from the binary:

Aqua Rush (AQ1/VER.A) Unplayable / please verify and update flag in driver source
Die Hard Arcade (US) Unplayable / please verify and update flag in driver source
Free Kick (bootleg) Unplayable / please verify and update flag in driver source
Major League Unplayable / please verify and update flag in driver source
Run and Gun (World ver. EAA) Unplayable / please verify and update flag in driver source

I'm still here :) I've been away from home base this week. (And when I got back down to it yesterday, the first thing I did was push a patch that seriously broke RetroArch for a few hours.)

I did a round of MAME 0.78 testing on the romsets you listed:

aquarush.zip works so the mame2003 source should not be marked as GAME_NOT_WORKING.
diehard.zip has some kind of region protection/encryption happening and won't start. That will be updated to GAME_NOT_WORKING in the mame2003 source via my PR.
freekick.zip has a bad dump warning and no video. It is already flagged as GAME_NOT_WORKING in the mame2003 source, and I get the correct warning screen when I try to load in mame2003.
mjleague.zip crashes with an access violation. That will be updated to GAME_NOT_WORKING in the mame2003 source via my PR.

Here's that PR: https://github.com/libretro/mame2003-libretro/pull/344

File under Interesting:
rungun.zip does not pass the game's native self-check due to a bad ROM dump. I briefly looked through the MAME update history for this driver and it seems like maybe the driver code didn't change once a good dump was eventually found. In other words, it might be possible to get this game working simply by adding the appropriate ROM dump from a later MAME version. I'd like to try to do this before flagging it as unplayable.

I feel like I am still just dropping in and out on your project. I really hope to have some time this weekend to get totally aligned with you on how to complete the effort.

Thank you again.