mamesick

I really don't see why people waste their time in manually editing the .INIs when there's a well-tested and professional GUI to configure those options: You don't need to edit PLUGINS.INI. You can configure all the plugins you want from the GUI in a very easy way. This can be done globally or per single game (right-click on a game the select "Properties for..."

Easiest way is right-click on a game and select "Add to Custom Folder". Then simply choose the desidered folder. If no choice present, simply create a custom folder following Hyperscorpio instructions.

IIRC Robbert completely removed NEOGEO raster hack a while ago, in favour of original MAME code. NAMCONB1 is still needed. Those changes don't fix the terrible slowdowns in Nebulas Ray on some levels due to performing raster effects on sprites, when probably the original hardware doesn't do that. Also there's a fix for a 1 pixel offset line in raster irq. SIMPSONS is still needed. Those changes don't fix the music speed bug. Audio CPU still must be overclocked

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); SetWindowRed

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*, unsigne

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'

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.