Altharic

I think this will be one of them JPM MPS

I was happy to donate to that doorbell and if needs must I would do again was fun seeing the idea come to fruition @johnparker007 did you go out of pocket doing it?

Its a milestone albeit a comical one at the moment, the purchase and dumping of this means that Black Box once its been reviewed is completely preserved in MAME.

New MAME is out and looks like the arcade doorbell is emulated Also noticed is now working

The other hopper changes are in just waiting on the blackbox review now

Mines working again it hated my username having a space in the middle plus a trip the office for what I call 'labrat' day doesn't help I see Cuavas has reviewed blackbox we are ride on time (see what i did there) for that tech to be in mame :)

Same result unfortunately same with the alternative linker I'll have another go if I get time later Compiling resources generated/resource/mame_mame_vers.rc... Linking mame.exe... ld.lld: error: undefined symbol: driver_list::s_drivers_sorted >>> referenced by libemu.a(emuopts.o):(.refptr._ZN11driver_list16s_drivers_sortedE) >>> referenced by libemu.a(config.o) >>> referenced by libemu.a(render.o) ld.lld: error: undefined symbol: driver_list::s_driver_count >>> referenced by libemu.a(drivenum.o):(.refptr._ZN11driver_list14s_driver_countE) >>> referenced by libfrontend.a(selgame.o) >>> referenced by libfrontend.a(simpleselgame.o) collect2.exe: error: ld returned 1 exit status make[2]: *** [mame.make:271: ../../../../../mame.exe] Error 1 make[1]: *** [Makefile:1087: mame] Error 2 make: *** [makefile:1119: windows_x64] Error 2

Typical it failed on me I'll do a make clean and try again.

I still play classics so I would be one that used the basic layouts in MAME call me sad but its how I remember FME in its infancy great to see it working again. I do have a git set up and I can tweak those values and upload a new exe if needed I can leave it run to complie These are the values he changed in src/emu/render.h static constexpr int MAX_TEXTURE_SCALES = 20; static constexpr int MAX_TEXTURE_SCALES = 100;

The build has completed set one that didn't work before to scrape and it should work?

That should show a windows binary once its finished

When this completes it should work HERE

Thats the problem with MAME they want a one size fits all then are resistant when something does not fit

Would it not be an idea to post it as an issue on the git site https://github.com/mamedev/mame/issues

I think MAME does need to evolve to be able to cope with this wonder what tri lamp machines do in mame?

I have been looking at impact in mame seeing what runs etc and there are loads that have no layout or have one with issues. Speaking of Mpu4 this has been opened by James on the mame pulls Edit to add Cash Raider (ace) screenshot

Does this just affect mpu4 if so could you not test another tech and see what happens Impact seems more complete in mame?

It was upped on here a few pages ago by SomeRandomGuy the mame.zip had it in and the rest of the blackbox roms.

I have some of the roms you need see attached sru.zip blackbox.zip

Probably in MAME land those .hex roms would not be 'allowed' and would need to be split. This goes back to the 9.4 leak version of MFME thats how it took the roms seem to remember we used the dos copy command something like copy rom1 + rom2 + rom3 Rom4 rom.hex and it combined them into a 2mb file

The rom dat has grown somewhat in size over the years I remember when it barely fit on a CD to now where its many gigs I don't have a full set yet mine is 19 gig.

Quotes that have not aged well "The good news is that even if I get hit by a bus tomorrow nobody is going to have to repeat this part of the work."

That unfortunately isn't what the dat is designed for it for auditing romsets and for that purpose the tech is not recorded.

If you rebuilt the mame set from the fruit machine dat and used remove source files using clrmame what is left would be what isn't in mame.

There are gigs of roms that are not in mame yet that wouldn't surprise me.