now that ive been working on mame084 ive ran into come endian issues you should be aware of

[ghost]

it looks like the code has just been changed to suit the most common fit

run this little program

#include<stdio.h>

int main()
{
#ifdef MSB_FIRST
        printf("(ifdef MSB_FIRST) defined");
#else
        printf("(ifdef MSB_FIRST) not defined\n");
#endif

#ifdef LSB_FIRST
        printf("(ifdef LSB_FIRST) defined\n");
#else
        printf("(ifdef LSB_FIRST) not defined\n");
#endif

as expected nothing will be defined

but adding the code here

https://github.com/libretro/mame2003-plus-libretro/blob/b529f5d3b0c4f3574cba3e4e8eb3b38820f8c63a/src/common.c#L1422

returns

[INFO] Saved core options file to "C:\msys64\usr\local\bin\retroarch-core-options.cfg"
[INFO] [Video]: Does not have enough samples for monitor refresh rate estimation. Requires to run for at least 4096 frames.
[INFO] [Video]: Does not have enough samples for monitor refresh rate estimation. Requires to run for at least 4096 frames.
(ifdef MSB_FIRST) not defined
(ifdef LSB_FIRST) not defined
(ifdef MSB_FIRST) not defined
(ifdef LSB_FIRST) not defined
(ifdef MSB_FIRST) not defined
(ifdef LSB_FIRST) not defined
(ifdef MSB_FIRST) not defined
(ifdef LSB_FIRST) not defined
(ifdef MSB_FIRST) not defined
(ifdef LSB_FIRST) not defined
(ifdef MSB_FIRST) not defined
(ifdef LSB_FIRST) not defined
(ifdef MSB_FIRST) not defined
(ifdef LSB_FIRST) not defined
(ifdef MSB_FIRST) not defined
(ifdef LSB_FIRST) not defined
(ifdef MSB_FIRST) not defined
(ifdef LSB_FIRST) not defined

now the original code was defined as #ifdef LSB_FIRST that was changed to msb to suit its just something you should be aware of can cause issue as some drivers use this check

[ghost]

Well done i knew you'd have it more or less done in short order, we'll need to have a discussion sometime around what stuff you'd like to see added to this new core, i dont think every addition and fix from this core would need to be ported across but the Data East games should be worth consideration

Additonally we now have more scope to work on stuff that was not possible in the MAME2003 core

[ghost]

Well I seen myself the timing issues and interrupt problems ect. 2003+ can be the lower end core and this one is a mid end one if your interested in working with it that is.

The original source is identical (only changed the execution loop for userinterface and cpu interface. so it should just drop in from your xbox core. Im not completely finished but am getting there it is usable .

[ghost]

Sure i'd be interested in helping out with this core, as you said it will be easy to just drop in code from the xbox ports, however i mostly focused on the 2D games as the xbox could not handle the emulation of some of the chunky 3D ones.

So there is a large gap of fixes we could look at being as this core will not be targeted at the lower spec platforms, i mind you wanted to add sound for the Namco Sys 21 / 22 games i have the CPU and the sound cores already done all that would be required for those i think is to update the drivers to MAME100 or so to hook up the games to em.

Anyways stuff to look at down the road

[ghost]

yea sounds like a plan one issue i have is i need to update the mememory maps to mame088 for 64 bit fixes it also add a bit of extra mirrring support ad a bonus the change isint big i just need to make sure ist backwards compatible before doing it

https://github.com/mamedev/historic-mame/blob/28a51f2c8dfb158db3a6e4936024fc7b72ae21da/whatsnew.txt#L151-L166

basicallt this becomes this

    AM_RANGE(0x240000, 0x240fff) AM_WRITE(MWA16_RAM) AM_BASE((data16_t **)&generic_nvram) AM_SIZE(&generic_nvram_size)
    AM_RANGE(0x240000, 0x240fff) AM_WRITE(MWA16_RAM) AM_BASE(&generic_nvram16) AM_SIZE(&generic_nvram_size)

ive already grabbed the changes i need for it to test here

it the changes in

cpuintrf.c and memory.c i also updated the 68k in there as well still to be tested like isint a big change should be backwards compatible

https://github.com/grant2258/mame084/commit/3ed819d4189383e84bfb1ae28a338e3891b4fcd5

[ghost]

@grant2258

Obviously the above changes would require some of the xbox drivers we may wish to target to be reworked slightly memory wise no big deal but i wanna ask ya a quick question....

Is too late to abandon this core and possibly target a slightly later build say MAME95.?? performance wise we lose nothing the workload would be far less eg Sega 16 / 18 / X / Y / Model 1 and System 24 are already playable.

Data East, Kaneoko16, NMK16 and Sega System 32 drivers would be a breeze and due to the sound core changes CPS3 games could become a viable target via that driver from the same MAME core i took the PGM updates, it was only the incompatable custom sound those games use which was a barrier to getting them up and running in MAME84 then again you've backported newer soundcores already maybe it's actually doable in 84..??

https://github.com/amadvance/advancemame/commit/0d2f99495d29703139d36bd0f6e9849c02061798#diff-6ca56195eb1bb3e91db45493b2739f70

After the above we would have a good solid core gamewise just leaving the 3D games to try and better emulate, food for thought anyway.

[markwkidd]

@arcadez I see you linked to some AdvanceMAME source. To me since I have contributed little to the driver backport projects I try not to weigh in with unrequested ideas.

But...

I have always wondered if the people who worked on libretro cores before us ever considered porting AdvanceMAME to libretro. It seems like such an attractive match -- an MAME older version, still maintained, etc -- that I wondered if there was some reason that an AdvanceMAME/0.106 port was never attempted.

[ghost]

I dunno THB porting a whole core to another platform is above my level i think although in truth i've never tried mostly content to just add code to existing ports, certainly the core i linked to would more or less tick all the boxes leaving very little work left to do.

[ghost]

Well I had to update the memory address space(memory.c) to mame 090 (games ran fine but there was a global buffer overflow in the memory with bank address pointers when debuging)

everything seems to still work fine to be honest even if using address maps the old way.

Because we had to change the run loop something funky is going on in the user interface when trying to set default keys ill need to try narrow that down though once i get that i think it ready to go.

Is there any particular sound core you need updated I could take a wee peek should be doable to be honest. I could try with mame095 at some point so we have both options.

as for advancemame the target of that core is specific to advanced video options ect

[markwkidd]

I will try to find a list of what's been changed in advanceMAME. If all they do is focus on video and cross platform considerations it's probably not an especially useful partnership.

If they're making performance enhancements and backporting driver fixes it might be more with it. In that case I might try to see if there advanceMAME folks would be interested in adding a libretro osd to the AdvanceMAME codebase. I think the last thing this world needs is another hard fork of an emulator that's still maintained 😎

Maybe between this core, Grant's new work, and MAME 2010 I could port AdvanceMAME to libretro with enough time but I would only do it if there's some meaningful benefit

[ghost]

Well if you add the port the right way it shouldnt be an issue we only need to change 3 core files to get mame to work on libretro (as well as the libretro stuff.

src/mame.c
src/usrintrf.c
src/cpuexec.c

i will be renaming these to

src/libretro_mame.c
src/libretro_usrintrf.c
src/libretro_cpuexec.c

Any code changes that are specifically changed for libretro that can either be done with a #define or change the file name. The only reason im doing this is im planning to port this to sdl and gl native as well.

@markwkidd this is just cosmetic but will stop a lot of spam when compiling and just show errors. I would suggest you add this to the makefiles at the top for mame2003 and2003+

MAKEFLAGS += --silent

most warning get lost in the spam of normal compiling and you miss any errors you could have caught

The biggest issues I have is the way the mame files on 2003 where edited needlessly. The endian and static issues are easily fixed in osd_cpu.h that what threw me off when staring this i assumed this was already done properly someone just changed every INLINE ,LSB_FIRST and MSB_FIRST in the source code instead of defining it in the header.

[ghost]

Well I fink ill be starting from scratch just found a big issue with the editor im using (notepda++) in windows its locking files stopping git commits working properly.

Ill just work in linux unless i can find a decent editor for windows that doesnt do this.

[markwkidd]

Are you using msys2 @grant2258 ?

I use Notepad++ as my main editor and I don't think I've had this problem. I wonder if there is a difference between our environments. May just be easier to find a different editor :)

FWIW AdvanceMAME has been backporting new drivers and fixes. I'm going to keep thinking about the possibility of porting it as a future project

[ghost]

yea im using msys2 its completely up to date it could have been because i have more than one session open im not sure. I have done the basics have posted on the repo on my site.

I have a strange problem the default buttons are setting and working but input this machine there ally highlighted white like its not defaults. when you press a key all is good. Pressing delete twice will case a n/a or a crash every so often I get a feeling it could be ui related no sure ill try look into this when i get time. Its a shame really because it all done for the moment I even fixed the possible overflow that could have been causing it but that was the reason ts not working.

I have to agree with arcadez about not really wanting to go too high you just want a mame far enough to still run on old hardware and have a decent set of features. That why a lot of people with a pi dont like the new advanced mame because its too slow for them.

Its all personal choice at the end of the day more options are always good. The 084/095 will aimed at low/mid end hardware as opposed to just low. If your going high end hardware you might as well just use current mame imho.

@arcadez if i find out whats going on with interface issue ill look into starting to peek at doing mame 095. I get a feeling the input code needs changed in the libretro port ill start debugging when I get the time.

https://github.com/grant2258/ame

only 3 files have been changed in the main src and renamed to libretro. libretro_cpuexec.c
libretro_mame.c
libretro_usrintrf.c

the other fixex are 64 it segfaults i fixed on this port as well probably

[markwkidd]

It's not really the performance of AdvanceMAME versus 0.78 or 0.84 that interests me but that it is maintained. None of the other libretro MAME ports really gets any development attention. Bugs -- with the libretro parts and with the MAME parts -- just get opened and never closed.

If there was another libretro MAME that also had some active users & developers. That was getting bugfixes once in a while, and once in a while a backported driver... That's just a notion, a dream. But I'm thinking about it 😶

[ghost]

@arcadez Ive been a bit busy of late but ive finally got round to compiling mame095 to see if it would work and its up and running audio and gfx. The input system changed in mame085 so that will be needing done.

I also have to see whats going wrong with the mame084 input stuff im pretty sure its the hack happy emit stuff that was done ages ago instead of using structures.

So both targets are viable ill need to get the input working a little at least to test 095 more. and the input need fixed on mame084 as well. Hopefully we will get there in in time.

@markwkidd advancemame was last updated Sep 25, 2018 if you think its a viable after you disable all its original extra video support cause ra supports its own video I would say go for it

[meowthed]

with mame084, 66 games are supported out of the box. Highlights include a bunch of Konami GX stuff, PSX-based stuff, Galeco 3D, and some Mylstar prototypes. mame095 has support for 95 titles already, including AB Cop, and systems like Max-A-Flex, Arcadia, and Crystal System.

[ghost]

well I will do both only one will be used most likely. I tend to sticks to arcadez advise and the workload on us 095 seems the way to go.

I have keyboard and digital inputs working in mame 095 everything seems good to go I just need to tidy and fix some things up for 095.

I have to add extra code for the input to work on 084 Im pretty sure i know whats causing it it it just finding the time need to do some work on my mums car today mot is due new brakes and rotors and handbrake cable is all that needs done so not so bad this year. Just hope i done throw my back out lol

[ghost]

@grant2258 nice progress big yin, 95 is a good build we can forward port some drivers, fixes and improvements from the xbox 84 core and also backport things like the namco sound CPU, seibuspi and hopefully cps3 drivers.

[ghost]

@arnoldsecret

just a heads up Surprise Attack is already supported in 78 so is Twin Cobra II via the jap version Kyukyoku Tiger 2

[ghost]

ok guys is up in running all that will be coming is updates to joystick anlalog ect but it perfectly usable.

https://github.com/grant2258/ame095

now all i need to do is make a mame 095 romset for testing more. Actually enjoyed playing midnight restistace with decent sound! Ill try compile on the pie later.

[ghost]

Well it might not come to nothing but the option is there is we want to carry on with mid/low end hardware when we run out of ideas for this port game wise. I personally think we there or very close to the work involved it just too much to get stuff working. This port isint dead will still get updates for me if they are needed and can be done.

[ghost]

@arcadez2003 Ive been passing some time and have ported mame084 . I ran into an issue with input this game highlighting keys even when they where set to default and it was changing the default in input this game. So like a true spaz im hunting the code i done. It turns out mame084 had this issue all in the fix is here if you need it for your ole port.

https://github.com/grant2258/ame084/commit/53144949ac6f75afa84350045fb6bfcbfe4879a8

Its a simple one but a bugger to find. Anyway this port is just if you need any help your end on the 084 side of things

[arcadez2003]

@grant2258 Thanks big yin i'll check it oot doon the road