mamesick

Yes, it seems that it's fixed now. At least for the few games I tested.

My two cents are that maybe it would be better make an HBARCADE build, with all the arcade-only hacks supported by HBMAME developed using the ARCADE GUI code. I cannot help because I'm lack of time due to my real life job and sincerely also because I'm not interested. Though I have no objections. Good luck with the neogeo-decrypted driver.

You might want to add a couple of changes in this piece of code at line 4865 in WINUI.CPP, to ensure that the TreeView repainting after the View-->Show Folders menu action doesn't show garbage: void ToggleShowFolder(int folder) { int current_id = GetCurrentFolderID(); SetWindowRedraw(hWndList, false); SetShowFolder(folder, !GetShowFolder(folder)); ResetTreeViewFolders(); SelectTreeViewFolder(current_id); SetWindowRedraw(hWndList, true); } change to: void ToggleShowFolder(int folder) { int current_id = GetCurrentFolderID(); SetWindowRedraw(hWndList, false); SetWindowRedraw(hTreeView, false); SetShowFolder(folder, !GetShowFolder(folder)); ResetTreeViewFolders(); SelectTreeViewFolder(current_id); SetWindowRedraw(hTreeView, true); SetWindowRedraw(hWndList, true); }

Excellent! Exactly what I was hoping for!

Call me crazy, but this diff is the cause of the crash. Left panel, your STORE1 source, right panel, official MAME source. Filename: GENIE.LUA I spent an hour in analyzing all the differences between the two sources and this is what appears to be relevant. Though I compiled your STORE1 source applying the changes and no more crashes in TOKI. I want to do some futher test before, but I guess I found the solution to the problem. Further news from me tomorrow or maybe next monday. Have a nice weekend!

This is a backtrace obtained without stripping symbols in an ARCADE64 0.213 build that only supports TOKI.CPP and few other drivers. Commands used: >GDB ARCADE64 >RUN TOKI >BT Thread 1 received signal SIGSEGV, Segmentation fault. 0x0000000000792f00 in (anonymous namespace)::FM_OPL::WriteReg(int, int) [clone . constprop.80] () (gdb) bt #0 0x0000000000792f00 in (anonymous namespace)::FM_OPL::WriteReg(int, int) [clo ne .constprop.80] () #1 0x0000000000793008 in (anonymous namespace)::FM_OPL::ResetChip() () #2 0x00000000007934ac in ym3812_init(device_t*, unsigned int, unsigned int) () #3 0x0000000000771d09 in ym3812_device::device_start() () #4 0x00000000007f1da3 in device_t::start() () #5 0x00000000008a0cf9 in running_machine::start_all_devices() () #6 0x00000000008a67a0 in running_machine::start() () #7 0x00000000008a80f5 in running_machine::run(bool) () #8 0x000000000053cf0d in mame_machine_manager::execute() () As you can see, there's something serious (and terrible because it happens only in ARCADE64). All games with YM3812 sound chip are prones to crash. I'll do futher investigations in the future but I sincerely have no idea on what searching for. I wonder if you have modified some LUA compiling scripts to keep compatibility with 32-bit. I'm saying this because all is fine in MAME64, MAMEUI64 and my personal build which is obviously based on ARCADE with some changes here and there. Also, side note, the ARCADE213S.RAR file seems a bit different if compared with the local STORE1 distribution. I don't see the LOHTB changes in M72.CPP

IIRC the View-->Show Folders is hardcoded in source and is based on the order that you can find in TREEVIEW.CPP. If you have altered in some way that order during the treeview panel creation (e.g. you used TVI_SORT or something similar) the order is now broken. Search also in WINUI.CPP for the piece of code that builds this menu option, it should be were all the bitmaps menu icons are created. The variable should be ID_SHOW_FOLDER_START## and is also hardcoded in MAMEUI.RC

Very bad news, it crashes here even if compiled with GCC 7.2.0. My local source is fine, so I guess there's something in ARCADE that causes the crash. Curiously only on 64 bit build. A build with SYMBOLS is required but at the moment I cannot do it. We'll see in the next days.

Ok, I tested the ARCADE 0.212 from AntoPisa site, the problem is there too. At which version do you switched the GCC compiler? I have serious feeling that it could be the problem. EDIT: 0.209 is where the problem starts. Build Tools were updated around that period or at least so it's stated at Buildtools section of MAMEDEV at GitHub.

If ARCADE32 is fine, I doubt it could be one of the various hacks. Also, I don't recall any hack related to Seibu Sound Hardware, which seems to be the culprit. Maybe a GCC compiler issue? Maybe something corrupted the source code during compiling process (very unlikely, but who knows) ? I'll try to compile an ARCADE64 with my GCC 7.2.0 (I never upgraded it) but I cannot give a timeline because I'm busy, so it could require some days.

Hmmm... It seems there's something serious here. I tried just for curiousity other games with similar hardware to Seibu Cup Soccer (e.g. Toki) and they crashes the emulator too. The usual step to reproduce is launching the game, let it run for some seconds, then exit and relaunch it. Or launch a random game, then exit and launch e.g. Toki. Usually at the "Loading Complete" message it should freeze for a second and then the emulator closes itself completely. Analyzing "VERBOSE.TXT" all games when crashes are at this point: Starting palette ':palette' Starting Speaker ':mono' (missing dependencies; rescheduling) Starting YM3812 OPL2 ':ymsnd' I'll do some tests at home with my local build and with ARCADE64 0.213 on Windows 7. Maybe it's OS related, who knows.

Yes, I can confirm even if it happens randomly here. Sometimes it get stuck at "loading....." message and after one or two seconds it closes itself. ARCADE64 0.213 and Windows 10 X64 On official MAME 0.213 I'm not able to reproduce. Bad thing is that it seems the program crashes without any relevant message. I looked at "WINUI.TXT" and "VERBOSE.TXT" and I don't see anything that could help in debugging this. Maybe Robert will be able to investigate further.

I cannot repro the issue posted above. Which game is causing the troubles ? I tested a few, all seems fine here.

Yes, that hack check for Sengoku2 was added for that reason. It requires RASTER POSITION -1 instead of +1 like the vast majority on NeoGeo games.

There are a lot of games where official MAME raster implementation in NeoGeo is off by a couple of lines, e.g. Zed Blade, Garou, View Point intro logo, etc. etc. If you can run a side-by-side with Zed Blade you'll immediately see what I mean in Level 1, where there are 3 different layers of scroll at different speed. The hack code also "fixes" some bugs present on original hardware that are present in official MAME. If you wish to remove all the modified code there's no problem, but say " I cannot see anything wrong with Mame's standard rendering " it's a bold claim. LOL. Sengoku2 is a special case, where the wrong MAME implementation works as expected and the hacked code fails.