mame 2003 gamelist.xml with data from the binary
-
https://github.com/grant2258/mame2003-libretro/tree/output_data
thats how you get the data dumped its a quick hack and could be done better but the main thing is it does what we want make sure you have write permission to where it writing or itll segfault
-
one more update for catver.ini I just played goldnaxa its stats all read as good the game starts fine the collision detection is well off and its unplayable. I confirmed the same behavior in mame 0.78. This should be updated in catver.ini so someone knows to look at it to change the source flag. This helps with knowing whats good and bad so people will also know what needs worked on
-
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
-
@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?
-
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 sourcegit clone https://github.com/kstenerud/Musashi.git
history.txt
m68kconf.h
m68kcpu.c
m68kcpu.h
m68kdasm.c
m68k.h
m68k_in.c
m68kmake.cthats 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 m68kmakenow 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.hsudo 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
-
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.chttps://github.com/grant2258/mame2003-libretro/commit/9955f1c75066cb4b9c2c2b511ffbb64c5d3442a7
if you want to see the diff of the files
-
probably the best way to solve this is to have the musashi git master as a git submodule in mame2003.
-
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
-
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?
-
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.
-
This post is deleted! -
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 -
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
-
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
-
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.
-
@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! :)
-
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.
-
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
-
@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 lolNice, thanks, Mamemagic is as good as any handle, it's just fine. :)
-
@riverstorm np if you find any issues let me know
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.