mame 2003 gamelist.xml with data from the binary

grant2258

yes that the one i used but its parsed through mame data and if it doesnt match it prints a please verify. The original catver doesnt change a new one is just generated

grant2258

cocktail is removed the diff and catver have been updated same link

less source/catver.ini | grep -c "Unplayable"
391
less catver.ini | grep -c "Unplayable"
504

so its 113 new bad ones

markwkidd

Very cool. Let's spot check these.

If I recall correctly, the last time I updated catver.ini I went though the catver and the mame2003 source and I launched every game marked as unplayable via the original MAME 0.78 in Windows in order to avoid 'false positives' -- games incorrectly marked as unplayable.

My criteria for designating something playable would be 1) that it boots up with reasonably appropriate video and 2) that it accepts coins and other input.

Not a very comprehensive test but I think that's still good criteria. This turned up several games that were labelled unplayable in the source but that were in fact functional.

Your project seems kind of like the obvious second phase of what I did before to get rid of false positives.

Edit: Actually your project is less like the second phase and more like the proper way to do the thing I was doing manually :D I am definitely interested in using these results to improve catver.ini!

herb_fargus

When I was looking at this a ways back, perhaps this is a different issue, but I remember having a bit of confusion with all the filename changes between versions and it was a bit difficult for me to figure out which version I had. If I remember correctly there was a name change dat that exists that perhaps handle those cases

grant2258

yes that is exactly the it from mame to mame the rom realnames change so in one version of mame a.zip could be amazing game(jap)(unencryped) then a new dump arrives it becomes amazing game(world)

(now if these games get mixed up in the mame naming and you think your picking the right one and your not because its the wrong real name is there.

now that aside i was happy i got my naming right. Now i went the the catver.ini and just wanted to see how valid it was and if there was any missing games there wasnt btw. There was just one game done twice. Considering mark done this all manually the accuracy is damn good of what he marked up.

So now whats left if i want to help mame mark up games right and its wrong in the source i have all the information i need in the gamelist details section to know if its write or wrong

please try out the gamelist.xml and show the full details and let me know if you find this helpful for your testing.

here is the source please take it easy on with the coding in only a few days into python know c helped and and made some other things difficult.

ps use python 2.7

to run you need to use python2

type python run.py

new files will be in the build folder

i supplied the mame2003 data i pulled

ps ill post details on how to get the mame data from mame2003 itll be the same method to pull data for lr-mame2003-plus since there both mame2003

just replace the source/mame2003.xml with data you pull from mame plus

https://drive.google.com/open?id=1Dx4XYA96d-G921IB9Zdfz9rLrclMpkJv

ps you can run it on windows or unix it doesnt matter which

grant2258

well I just tried altered beast fancied a game all driver stats read good but the sprites are just lingering. I tried it on normal mame078 and it is fine this naming convention works great and its easy to check if the original mame had the same proplem or if it was introduced into the codebase

grant2258

on a unrelated subject ive fixed altered beast the 68k core needs an update to do it though. The makefile isint generating the 68k core properly either.

this needs added to the makefile anywhere at the top

CFLAGS = -std=gnu99 -Isrc -Isrc/includes -Isrc/$(CORE_DIR) -I$(CORE_DIR)/cpu/m68000 -Isrc/cpu/m68000

the make file should be compiling m68kmake.c and executing it to make the code

im not good with github but here is a bash command to update the core and compile it

cd /home/pi/RetroPie-Setup/
sudo ./retropie_packages.sh lr-mame2003 sources
git clone https://github.com/kstenerud/Musashi.git
cd Musashi/
#makefile in lrmame really needs to do this step it doesnt
gcc m68kmake.c -g -O2 -std=gnu99 -o m68kmake
#execute it and generate source files
./m68kmake
sudo cp *.c ../tmp/build/lr-mame2003/src/cpu/m68000/
sudo cp *.h ../tmp/build/lr-mame2003/src/cpu/m68000/

cd ..

sudo ./retropie_packages.sh lr-mame2003 build
sudo ./retropie_packages.sh lr-mame2003 install

grant2258

@markwkidd

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

grant2258

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

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