[00:20] *** DFJustin has joined #jsmess [04:46] I've got the Arcade Repair set down to 223 and dropping. [10:10] *** Sgeo has quit IRC (Read error: Connection reset by peer) [16:03] *** dboard420 has quit IRC (Read error: Operation timed out) [16:03] *** dboard420 has joined #jsmess [18:48] *** Sgeo has joined #jsmess [20:01] Sharing for DFJustin and others: [20:01] https://docs.google.com/spreadsheets/d/1v5PgyIEDkXbK8jtBNSKTW-nmPTwqdNUQ8_ElKWF1jsk/edit?usp=sharing [20:07] Uncaught in Promise are the straight-up blow-ups. [20:07] If I fix them, they leave this list. [20:42] so there is some discussion about enabling threading in the mame emscripten build, that would require some server side changes to send the correct cross origin headers as per https://emscripten.org/docs/porting/pthreads.html [20:43] could provide some speed benefits [22:18] We can always do 39in1 as a test, and then talk to the devs when it works out to see what's being blocked [22:26] I'm continuing to find working CHDs and the amount of brokes in that google docs continues. [22:26] Hopefully you will see trends in what's causing the promises [22:26] Happy to recompile via whatever tricks you want [22:27] I'd have to make some changes to the codebase first [22:33] DFJustin, SketchCo2: gtfore06 (or anything that uses the mips3 drc) will not work without -nodrc, and with -nodrc performance will be terrible [22:33] I've been trying to track down the bugs that cause the C DRC interpreter to fail, but it's ... difficult [22:33] even with the C DRC interpreter, performance will likely still be just as bad as with -nodrc, though [22:38] So, feel free to look over the list of what I've put up, and add a note in the D column [22:39] I mean, first, there are SLOW machines, which is one issue, and then there are CRASHING machines. [22:39] For the record, the most "important" to me are the blitz machines, as I'm close friends with the lead dev, and he would love to see this emulated. [22:42] yeah, and those use mips3. :( [22:43] so, you're saying they need the -nodrc line or they'll crash [22:43] almost certainly. I'm chasing this bug and am not getting very far (so far) [22:43] this CPU core relies on recompiling instructions to x86 for performance; I'll do a quick performance test on my M1 Mac (where there is no DRC) to see what speeds I get [22:44] CPU emulation core** [22:44] I mean, tha'ts fine [22:44] yeah, can't really do that in emscripten [22:44] I'm fine with all of it. I'm trying to just limit DFJustin chasing pain [22:44] (the DRC part) [22:44] I'll at least give y'all a performance baseline [22:44] If you could go on that list on the google doc and add to Column D "add -nodrc" [22:45] I just did [22:45] for the two that I know off the top of my head [22:46] Doing a blitz test [22:56] blitz, using an optimized release build: without -nodrc I get a hard lock, with it I get performance around 50-60% [22:57] So is there something in the code I can find that tells me which of these locks I have can use NODRC [22:57] you can probably just add -nodrc always, it has no effect if the CPU has no DRC like a Z80 [22:58] it depends — drc c interpreter may be faster than -nodrc for some systems [22:58] but ... it's completely broken for mips3 [22:58] it's been slower in my experience but I suppose there could be one out there [22:58] Well, again, I'm trying to reduce your time wasted [22:58] if the driver has a #include "cpu/mips/mips3.h" — yeah, you'll need -nodrc [22:59] So if after I'm done, I have a pile of nodrc to add, or even looking for mips in the driver, that works. [22:59] DFJustin: hmmmm, good to know [23:00] aleck64.cpp:#include "cpu/mips/mips3.h" [23:00] atlantis.cpp:#include "cpu/mips/mips3.h" [23:00] caprcyc.cpp:#include "cpu/mips/mips3.h" [23:00] crimson.cpp:#include "cpu/mips/mips3.h" [23:00] decstation.cpp:#include "cpu/mips/mips3.h" [23:00] hng64.cpp:#include "cpu/mips/mips3.h" [23:00] iteagle.cpp:#include "cpu/mips/mips3.h" [23:00] kinst.cpp:#include "cpu/mips/mips3.h" [23:00] kpython.cpp:#include "cpu/mips/mips3.h" [23:00] magictg.cpp:#include "cpu/mips/mips3.h" [23:00] n64.cpp:#include "cpu/mips/mips3.h" [23:00] namcops2.cpp:#include "cpu/mips/mips3.h" [23:00] namcos23.cpp:#include "cpu/mips/mips3.h" [23:00] ncdmips.cpp:#include "cpu/mips/mips3.h" [23:00] o2.cpp:#include "cpu/mips/mips3.h" [23:00] octane.cpp:#include "cpu/mips/mips3.h" [23:00] ps2sony.cpp:#include "cpu/mips/mips3.h" [23:00] seattle.cpp:#include "cpu/mips/mips3.h" [23:01] vegas.cpp:#include "cpu/mips/mips3.h" [23:01] vp101.cpp:#include "cpu/mips/mips3.h" [23:01] And from that [23:01] biofreak.json: "wasm_filename": "mameseattle.wasm.gz", [23:01] blitz2k.json: "wasm_filename": "mameseattle.wasm.gz", [23:01] blitz99.json: "wasm_filename": "mameseattle.wasm.gz", [23:01] blitz.json: "wasm_filename": "mameseattle.wasm.gz", [23:01] calspeed.json: "wasm_filename": "mameseattle.wasm.gz", [23:01] carnevil.json: "wasm_filename": "mameseattle.wasm.gz", [23:01] hyprdriv.json: "wasm_filename": "mameseattle.wasm.gz", [23:01] mace.json: "wasm_filename": "mameseattle.wasm.gz", [23:01] sfrush.json: "wasm_filename": "mameseattle.wasm.gz", [23:01] sfrushrk.json: "wasm_filename": "mameseattle.wasm.gz", [23:02] vaportrx.json: "wasm_filename": "mameseattle.wasm.gz", [23:02] wg3dh.json: "wasm_filename": "mameseattle.wasm.gz", [23:02] So we start to solve the mysteries. That's all I want to do. [23:04] chances are these machines work at a playable rate... on native x86_64. [23:30] Are you sure it's "-nodrc" [23:32] { [23:32] "name": "wg3dh", [23:32] "arcade": "1", [23:32] "bios_filenames": [ [23:32] "" [23:32] ], [23:32] "peripherals": [ [23:32] "" [23:32] ], [23:32] "native_resolution": [ [23:32] 640, [23:32] 480 [23:32] ], [23:32] "extra_args=": [ [23:32] "" [23:32] ], [23:32] "driver": "wg3dh", [23:32] "wasmjs_filename": "mameseattle.js.gz", [23:32] "wasm_filename": "mameseattle.wasm.gz", [23:33] "file_locations": { [23:33] "mamesegag80r.wasm": "mameseattle.wasm.gz" [23:33] } [23:33] } [23:33] So, here, I was putting -nodrc in the extra_args [23:33] https://archive.org/details/arcade_wg3dh is clearly the best test, with a mere 87mb of CHD [23:35] "extra_args=": [ [23:35] "-nodrc" [23:35] ], [23:35] I used this, and it is still blowing up [23:35] The new blowup is definitely different. [23:36] extra_args shouldn't have an = [23:36] I feel like we've been through this a few times [23:36] Well [23:37] The main reason here is that these are all the CHD-ified machines that I just literally dropped the tools and tooling on to walk over to where effort was really needed. [23:37] Like, some of these were just the CHD uploaded and then walked away when we couldn't get CHDs to load [23:37] So I'm already forwarding 10-20 steps before you see them [23:37] (adding ROMs, getting other configs right, etc.) [23:37] But when they hit the promise, I have to stop [23:38] That's mostly why. Luckily, we're down to, like, 200 items and even these are falling [23:45] emularity_engine_v1 is definitely in need of a cleanup.