mame 2003 gamelist.xml with data from the binary

grant2258

well im not familiar with stv bios but its not working right now so we can change the region in the bios somehow it probably would work.

there is a -bios swith but retroach wont support that anyway at the command line

this is for neogeo but the same syntax should apply

http://dammit.typepad.com/blog/2011/03/setting-the-neogeo-bios-in-mame.html

grant2258

never mind the above mark your right i pressed the service button and it worked lol

markwkidd

I'm going to submit a PR that will display this messagethe first time rungun is executed. I think this kind of popup should be used sparingly, but this is a perfect case for it.

0_1521907148012_Screenshot 2018-03-24 11.54.21.png

I'm also adding the rungun.nv memory map to the metadata folder.

grant2258

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

I'm going to submit a PR that will display this messagethe first time rungun is executed. I think this kind of popup should be used sparingly, but this is a perfect case for it.

I'm also adding the rungun.nv memory map to the metadata folder.

nicely done mark

markwkidd

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

never mind the above mark your right i pressed the service button and it worked lol

We will have to redeem diehard in a bit and also give it a custom warning message if possible.

What is the performance like in-game? It's taking quite a while to self-test here and the video seems like it might be off.

Hmm... it seems pretty messed up.

grant2258

mame diehard -bios us

is how start it in mame078 dont think you need the nvram set i can double check though. I think your probably going to need a i7 for this one

should be able to make a diehard.ini and just add
bios us

i not sure if we support ini files though another thing i would need to check

markwkidd

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

mame diehard -bios us

is how start it in mame078 dont think you need the nvram set i can double check though. I think your probably going to need a i7 for this one

should be able to make a diehard.ini and just add
bios us

i not sure if we support ini files though another thing i would need to check

It's pretty playable here in mame 0.78 with -bios us on whatever intel processor this old laptop has to offer. Lots of graphical glitches, but if we can get it working in this condition in mame2003 it's definitely not unplayable.

No there is no ini support in mame2003, by design. I have not yet encountered this scenario of needing a mame2003 equivalent of -bios flag.

Unless you have any leads on how to do that, I think that someone needs to summarize the investigation so far and start a github issue for making diehard playable.

Would you like to write it up?

grant2258

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

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

mame diehard -bios us

is how start it in mame078 dont think you need the nvram set i can double check though. I think your probably going to need a i7 for this one

should be able to make a diehard.ini and just add
bios us

i not sure if we support ini files though another thing i would need to check

It's pretty playable here in mame 0.78 with -bios us on whatever intel processor this old laptop has to offer. Lots of graphical glitches, but if we can get it working in this condition in mame2003 it's definitely not unplayable.

No there is no ini support in mame2003, by design. I have not yet encountered this scenario of needing a mame2003 equivalent of -bios flag.

Unless you have any leads on how to do that, I think that someone needs to summarize the investigation so far and start a github issue for making diehard playable.

Would you like to write it up?

You know more about the mame system and how it works with retroarch than I do I think it would be best if you wrote it up.

int determine_bios_rom(const struct SystemBios *bios)
{
const struct SystemBios *firstbios = bios;

/* set to default */
int bios_no = 0;

/* Not system_bios_0 and options.bios is set  */
if(bios && (options.bios != NULL))
{
	/* Allow '-bios n' to still be used */
	while(!BIOSENTRY_ISEND(bios))
	{
		char bios_number[3];
		sprintf(bios_number, "%d", bios->value);

		if(!strcmp(bios_number, options.bios))
			bios_no = bios->value;

		bios++;
	}

	bios = firstbios;

	/* Test for bios short names */
	while(!BIOSENTRY_ISEND(bios))
	{
		if(!strcmp(bios->_name, options.bios))
			bios_no = bios->value;

		bios++;
	}
}

debugload("Using System BIOS: %d\n", bios_no);

return bios_no;

}

in common.c

i guess a selector within retroarch in options perhaps off hand

markwkidd

Alrighty, issue logged.

Seems like there is a lot of developer interest in mame2003 this week. My dream would be someone else sees that and instantly knows how to fix. Regardless, it's a good start.

grant2258

thanks mark only meant to fix the catver didnt relise we would uncover these bugs along the way

markwkidd

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

thanks mark only meant to fix the catver didnt relise we would uncover these bugs along the way

Yep, that's how it goes! (This has already been great for the core.)

From your perspective, what is the next step on the catver.ini update?

grant2258

well we have taken the steps to fix any issues that werent marked as bad in the source from carver. It will do what it should do generated a gamelist by genre and unplayable like you did accept it will be automated when you run mamemagic from a freshly dumped xml. I will need a updated list thats not marked unplayable and ill finish up. No more updating catver.ini manually we update at the source level that way things can get fixed.

There is also the gamelist data that is created with information in it handy to test games and see there status see the screenshots above with the information it gives you.

This will work in lr-mame plus as well according to its flags being set in the source so we should be all good to go and the catver will be as accurate as the source information.

see post 31 great for debugging and checking if things are right information wise. I just wanted a nice games list its amazing how this all happened. I put it down to the work youve put in mark

markwkidd

Well, as always I have discovered 'one more thing' that probably should happen before the catver.ini.

Back in the dark ages of a couple of months ago, I made a series of manual edits to the MAME 0.78 XML.dat to fix bad merge tags. Those changes are traceable here: https://github.com/libretro/mame2003-libretro/commits/master/metadata/MAME 0.78 XML.dat

Now that I can so easily generate an XML DAT from mame2003-libretro (although not mame2003-plus-libretro -- sigh) I see that I need to make these same edits to the source so that the generated XML is correct.

I'll do this, but it may be a few days. One more thing, one more thing.

mediamogul

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

Back in the dark ages of a couple of months ago

I just can't believe the way we dressed back then. What were we thinking?

grant2258

@markwkidd

this can probably be automate as mame has a function to list bad merges it probably something that could be added to mamemagic. Id need to look into it a little more though

C:\Users\grant\Downloads\mame078b>mame.exe -lwm
CRC(2066a0b7) SHA1(6d4ccc27d6be185589e08aa9f18702b679e49a4a)
chg1 puckmana
5e.cpu newpuc2
CRC(2066a0b7) SHA1(6d4ccc27d6be185589e08aa9f18702b679e49a4a)
chg1 puckmana
5e.cpu newpuc2b
CRC(3591b89d) SHA1(79bb456be6c39c1ccd7d077fbe181523131fb300)
chg2 puckmana
hm11.5h hangly3
CRC(9d027c4a) SHA1(88e094880057451a75cdc2ce9477403021813982)
hm1.6e hangly3
np2b1.bin newpuc2b
CRC(3591b89d) SHA1(79bb456be6c39c1ccd7d077fbe181523131fb300)
hm11.5h hangly3
chg2 pacheart

i wont list them all

grant2258

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

Well, as always I have discovered 'one more thing' that probably should happen before the catver.ini.

Back in the dark ages of a couple of months ago, I made a series of manual edits to the MAME 0.78 XML.dat to fix bad merge tags. Those changes are traceable here: https://github.com/libretro/mame2003-libretro/commits/master/metadata/MAME 0.78 XML.dat

Now that I can so easily generate an XML DAT from mame2003-libretro (although not mame2003-plus-libretro -- sigh) I see that I need to make these same edits to the source so that the generated XML is correct.

I'll do this, but it may be a few days. One more thing, one more thing.

well this one is fixed just need to look into the other two remaining

edit:

all fixed no need to edit files

markwkidd

I'm just posting to say that Twinaphex merged the XML generator into standard mame2003 today. I hope to play around with it more once I have time.

grant2258

@markwkidd

nice work mate im going to to some work on mame magic for making a catver for mameplus when im off work should be Monday or Tuesday. I didnt think you would get it added to lrmame-2003 well done mate am very impressed :)