#jsmess 2018-03-26,Mon

↑back Search

Time Nickname Message
00:44 πŸ”— SketchCow Great
02:10 πŸ”— oscar All right, so before I commit to a kind of hacky solution to get something functional for now, what's the preferred way of passing info about e.g. what images and peripherals are attached out of the loader?
02:11 πŸ”— oscar I'm inclined to just staple them onto the emulator object, but that's pretty ugly and fragile.
02:11 πŸ”— oscar It'll work for now, but probably only just.
02:54 πŸ”— oscar The worst of this is: the Lua part is probably the simplest. It's all the JavaScript that's a pain.
03:28 πŸ”— datajerk has quit IRC (Read error: Operation timed out)
03:30 πŸ”— datajerk has joined #jsmess
03:40 πŸ”— db48x that'll work for now
03:55 πŸ”— oscar OK, well.
03:56 πŸ”— oscar I have the UI elements for swapping media up and running, but they don't do anything to the emulator yet because I'm trying to figure out the best place to lash up all the control points.
03:57 πŸ”— oscar It would be great to call the Lua functions directly, but you'd need to write at least a bit of custom code in MAME because the Lua engine doesn't have any exposed way to call a function while passing it parameters (I don't think, anyway), and you can't just call the Lua C API function because at the very least you need to pass in a context pointer.
03:57 πŸ”— oscar Which would be a great big mess from outside the program.
03:58 πŸ”— oscar So lashing it up via the socket seems to be the most likely way, with the added bonus that you don't have to muck around with MAME at all. It should work with the stock binaries.
03:59 πŸ”— oscar But I haven't implemented that yet, because a) I've been getting the interface for actually loading the images and making the UI elements for selecting them work (which seems to be 100% now), and b) I've been trying to figure out order of operations to make that behave.
04:00 πŸ”— bai we do have a place where we can put JSMAME-specific functions, we keep a reference to the running machine and can expose functions which are bound to that context https://github.com/mamedev/mame/blob/master/src/emu/machine.h#L399-L414
04:00 πŸ”— oscar As to b), the primary constraint is that you need the filesystem up and running before you can create the "device node". So the code to instantiate that probably belongs in the before_emulator() callback.
04:01 πŸ”— oscar bai: Sure, the problem is that there aren't any existing ways to just call a Lua function with arguments. There's a way to call one *without* them (I think, unless I missed something) in luaengine.cpp, but it's kinda hard to tell it which disk to swap without arguments.
04:01 πŸ”— oscar Maybe there's a way to pass args too that I'm just missing because I'm tired.
04:03 πŸ”— bai yeah, that part I'm not familiar with at all. seems surprising that there wouldn't be SOME way of doing that, but without having looked at the code like you have, my opinion is pure speculation :D
04:04 πŸ”— oscar Well, looking at what they've done, it looks like they just wanted a way to call the functional hooks for calling periodic functions.
04:04 πŸ”— oscar So there's: bool lua_engine::execute_function(const char *id)
04:04 πŸ”— oscar In which "id" is the name of a function.
04:04 πŸ”— bai this whole thing is a bit of a frankenstein system, so it's not at all surprising when things don't line up how we initially expect :D
04:04 πŸ”— oscar Lua likes to pass its arguments on its stack, but there's no corresponding function to push those in luaengine.cpp.
04:05 πŸ”— bai yeah, that's what I'm wondering, if you somehow prepare the engine state by pushing variables, then call the function
04:05 πŸ”— oscar So you see a big pile of things like this:
04:05 πŸ”— oscar execute_function("LUA_ON_RESUME");
04:05 πŸ”— oscar Which just calls that function with no arguments. That's the only thing MAME ever does with calling the functions.
04:06 πŸ”— oscar I'm not opposed to adding proper functionality for adding/pushing arguments; that wouldn't be that hard.
04:06 πŸ”— bai heh, yeah it's also possible that their implementation is just super simple, and we'd have to think about how to implement the lua functions in terms of argumentless functions
04:06 πŸ”— oscar Well, the bright side is that it'd be super easy to just add the push/pop functions for the stack.
04:07 πŸ”— oscar Though then you have to be careful about not embuggering the stack by pushing/popping the wrong number of things, etc.
04:07 πŸ”— oscar But not tonight. :-)
04:07 πŸ”— oscar You couldn't do this as an argumentless function in any practical sense.
04:07 πŸ”— oscar Because you have to pass in the pathnames of files.
04:08 πŸ”— bai yeah this whole scenario is kind of hilarious - we want to fiddle with the stack state of an embedded lua interpreter running inside of a C app that's been compiled to wasm and controlled by js
04:08 πŸ”— oscar And you can't just pregenerate the Lua file for doing that in many cases, because that'll be problematic if the user wants to insert a blank disk/use their own/etc.
04:08 πŸ”— bai we're abusing computer science in never-before-seen ways
04:08 πŸ”— oscar Yes, it's an Inception-level headache.
04:09 πŸ”— oscar Javascript as an IR is certainly a pathological corner case.
04:09 πŸ”— oscar In any case.
04:09 πŸ”— oscar My preferred approach is to use the "device" interface that emscripten offers.
04:10 πŸ”— oscar That's actually pretty easy... you define a Javascript object full of callbacks for open/read/write/whatever and programs can talk to them. Really convenient way to implement a socket.
04:10 πŸ”— bai yeah, that's a powerful approach - I used that for ffmpeg-in-js to feed frame data in and out
04:10 πŸ”— oscar So it won't be that hard to just talk to the Lua program over that socket and issue commands/receive status updates.
04:11 πŸ”— oscar I haven't had a chance to fully think through what the protocol should look like, but it doesn't have to be crazy.
04:12 πŸ”— oscar Plus, it's something that could possibly be adapted for the other emulators if we want (though that seems more dubious).
04:12 πŸ”— oscar The funny thing is, the Lua command to switch disks or empty the drive is just a single line once you have the peripheral name and the path to the image.
04:12 πŸ”— oscar Getting those into the emulator is the challenging bit.
04:13 πŸ”— oscar I'd suggest just using the built-in console program, but that'll be fragile on the interface side if you ever want to try to read things from it, because the console echoes a whole lot of stuff to look pretty that you have to studiously ignore if you're a machine.
04:14 πŸ”— oscar But I think the socket into the custom Lua script should be clean and extensible.
04:15 πŸ”— oscar It should also allow us future things like receiving eject notifications from e.g. the Mac, which doesn't like manual ejections much. I know we use PCE for that for the moment, but there was some indication MAME could be in the running for that soon.
04:16 πŸ”— oscar Anyway, I'm gonna clean this up a smidge and make my commits, then put up a running example on my server for others to test.
04:16 πŸ”— oscar It's not ready for a PR, obviously.
04:16 πŸ”— oscar Not least because the media doesn't actually change yet.
04:17 πŸ”— SketchCow Would love to see
04:38 πŸ”— oscar http://some.ridiculous.solutions/emularity/example_ia2.html
04:38 πŸ”— oscar And my branch: https://github.com/superdave/emularity/tree/feature/swap-that-floppy
04:39 πŸ”— oscar Currently, all the selector menu does is yell at you about which peripheral you're swapping and what the new disk path is.
04:39 πŸ”— oscar With an empty string for eject.
04:39 πŸ”— oscar Need to also add something for adding new disks (because Wasteland is gonna be useless without that option) and loading/storing local disks.
04:40 πŸ”— oscar But that can come once the actual media change functionality is working.
04:41 πŸ”— oscar But the major achievements here are the per-instance extra emulator metadata (which will be useful for more than just media mapping), and the fact that we have the media selector menu loaded and knowledgeable about what disks are there.
04:42 πŸ”— bai yeah, definitely some good progress here
04:43 πŸ”— oscar And it's all still backwards compatible with older media; if the metadata's not there, it'll pretty much just act like it used to (because it doesn't have a mapping of what disks you really want, only what files exist with the emulator suffix).
04:43 πŸ”— oscar I, uh, haven't tested the backwards compatibility bit tonight, I probably broke one or two things that need to get fixed before it's final.
04:48 πŸ”— oscar Anyway, I'm about out of gas for tonight.
04:49 πŸ”— oscar Feel free to fire off questions/flames while I brush my teeth.
04:58 πŸ”— oscar Ah, a few things before I go to bed:
04:58 πŸ”— oscar 1) I still have the table-driven file loading code, but it's not 100% finished. It's not committed to that branch yet. It's mostly unimportant, but I think it'll make it helpful if we want to have any more dependent files getting loaded.
05:00 πŸ”— oscar 2) MAME does let you load images from within Zip files, but it seems to barf in the browser when I try that. I also need to do a bit of thinking on the schema for the XML metadata so that it's not trying to load the file Wasteland_Disks.zip/Wasteland_Disk_1.dsk from the server, for example. But it should be totally possible to specify that if we wanted, for some insane reason.
05:03 πŸ”— oscar Anyway, good night!
05:06 πŸ”— bai 'night
06:31 πŸ”— db48x oscar: the code looks pretty good so far
06:31 πŸ”— db48x oscar: I posted a few comments, but there's nothing really wrong with it so far
11:24 πŸ”— godane has quit IRC (Ping timeout: 506 seconds)
13:05 πŸ”— godane has joined #jsmess
13:08 πŸ”— SketchCow Looks like a good start
13:19 πŸ”— oscar Thanks for the feedback! Please feel free to be a Coding Standards Nazi, I'm 100% sure I made some other inconsistencies. And apologies for forgetting some Javascript things like variable scoping rules.
13:19 πŸ”— oscar I am... not really a Javascript guy.
13:19 πŸ”— oscar Or at least haven't been for most of a decade.
13:23 πŸ”— oscar ...and my dusty neurons remembered `var` as the local scoping keyword, not `let`. Oy.
13:39 πŸ”— oscar What's your general preference for making update commits vs. rebasing/squashing?
15:02 πŸ”— datajerk has quit IRC (Read error: Operation timed out)
15:04 πŸ”— datajerk has joined #jsmess
15:42 πŸ”— godane has quit IRC (Read error: Operation timed out)
17:26 πŸ”— db48x yea, var is fine too
17:29 πŸ”— db48x and I prefer not to rebase or squash commits
17:33 πŸ”— oscar Ohhhh, OK, var is an intermediate scope level, so I didn't totally remember it wrong. It's global within the function, while let is scoped to the block (a la LISP, which is probably where it came from).
18:03 πŸ”— bai yeah I still use var out of habit, and because every once in a while you'll run into a platform which still uses ancient JS which doesn't have let yet
18:04 πŸ”— bai not so much with this stuff though, there's a certain cut-off as far as browser features beyond which trying to run this emscripten stuff is just a lost cause :D
18:19 πŸ”— SketchCow db48x: Operation Wipeout Engaged
18:30 πŸ”— SketchCow DFJustin: Need your help
18:33 πŸ”— SketchCow Not urgent
18:33 πŸ”— SketchCow But we're going to try PSX
18:34 πŸ”— DFJustin should Just Work(tm)
18:36 πŸ”— SketchCow https://archive.org/details/Dino_Crisis_USA_Demo
18:36 πŸ”— SketchCow {
18:36 πŸ”— SketchCow "name": "Sony Playstation",
18:36 πŸ”— SketchCow "js_filename": "mamepsx.js.gz",
18:36 πŸ”— SketchCow "bios_filenames": [
18:36 πŸ”— SketchCow "psx.zip"
18:36 πŸ”— SketchCow ],
18:36 πŸ”— SketchCow "peripherals": [
18:36 πŸ”— SketchCow "psxcd"
18:36 πŸ”— SketchCow ],
18:36 πŸ”— SketchCow "native_resolution": [
18:36 πŸ”— SketchCow 640,
18:36 πŸ”— SketchCow 480
18:36 πŸ”— SketchCow ],
18:36 πŸ”— SketchCow "extra_args": [
18:36 πŸ”— SketchCow ""
18:37 πŸ”— SketchCow ],
18:37 πŸ”— SketchCow "driver": "psx",
18:37 πŸ”— SketchCow "file_locations": {
18:37 πŸ”— SketchCow "mameatari400.wasm": "mamepsx.wasm.gz",
18:37 πŸ”— SketchCow "mameatari400.wast": "mamepsx.wast.gz",
18:37 πŸ”— SketchCow "mameatari400.js.mem": "mamepsx.js.mem.gz",
18:37 πŸ”— SketchCow "mameatari400.asm.js": "mamepsx.asm.js.gz",
18:37 πŸ”— SketchCow "mameatari400_wasm.wasm": "mamepsx_wasm.wasm.gz"
18:37 πŸ”— SketchCow },
18:37 πŸ”— SketchCow "wasmjs_filename": "mamepsx_wasm.js.gz",
18:37 πŸ”— SketchCow "wasm_filename": "mamepsx_wasm.wasm.gz"
18:37 πŸ”— SketchCow }
18:37 πŸ”— SketchCow (Oops)
18:38 πŸ”— SketchCow OK, fixing the atari
18:39 πŸ”— DFJustin the driver field should be "psu" and not "psx"
18:39 πŸ”— SketchCow I chose a 14mb file so we wouldn't shoot ourselves
18:40 πŸ”— DFJustin it's psx.cpp but the individual machines are called psu, psj, pse for the different regions
18:41 πŸ”— DFJustin peripheral should be cdrom and not psxcd
18:41 πŸ”— SketchCow {
18:41 πŸ”— SketchCow "name": "Sony Playstation",
18:41 πŸ”— SketchCow "js_filename": "mamepsx.js.gz",
18:41 πŸ”— SketchCow "bios_filenames": [
18:41 πŸ”— SketchCow "psx.zip"
18:41 πŸ”— SketchCow ],
18:41 πŸ”— SketchCow "peripherals": [
18:41 πŸ”— SketchCow "psxcd"
18:41 πŸ”— SketchCow ],
18:41 πŸ”— SketchCow "native_resolution": [
18:41 πŸ”— SketchCow 640,
18:41 πŸ”— SketchCow 480
18:41 πŸ”— SketchCow ],
18:41 πŸ”— SketchCow "extra_args": [
18:41 πŸ”— SketchCow ""
18:41 πŸ”— SketchCow ],
18:41 πŸ”— SketchCow "driver": "psu",
18:41 πŸ”— SketchCow "file_locations": {
18:41 πŸ”— SketchCow "mamepsx.wasm": "mamepsx.wasm.gz",
18:41 πŸ”— SketchCow "mamepsx.wast": "mamepsx.wast.gz",
18:41 πŸ”— SketchCow "mamepsx.js.mem": "mamepsx.js.mem.gz",
18:41 πŸ”— SketchCow "mamepsx.asm.js": "mamepsx.asm.js.gz",
18:41 πŸ”— SketchCow "mamepsx_wasm.wasm": "mamepsx_wasm.wasm.gz"
18:41 πŸ”— SketchCow },
18:42 πŸ”— SketchCow "wasmjs_filename": "mamepsx_wasm.js.gz",
18:42 πŸ”— SketchCow "wasm_filename": "mamepsx_wasm.wasm.gz"
18:42 πŸ”— SketchCow }
18:43 πŸ”— SketchCow https://archive.org/details/Dino_Crisis_USA_Demo
18:43 πŸ”— SketchCow Any ideas?
18:45 πŸ”— SketchCow Did I make a not great psx.zip?
18:45 πŸ”— SketchCow Should it have psx_cd in it?
18:45 πŸ”— DFJustin <DFJustin> peripheral should be cdrom and not psxcd
18:45 πŸ”— SketchCow Uploading fix now
18:46 πŸ”— DFJustin psu needs stuff from psu.zip and psx_cd.zip
18:46 πŸ”— SketchCow a hah
18:46 πŸ”— SketchCow I don't see psu.zip anywhere
18:51 πŸ”— SketchCow I put a random .bin I got on the internet and put that with psx_cd.zip and made it psx.zip but I am not convinced that'll work.
18:51 πŸ”— SketchCow And now I only own 34 Nigerian palaces and 3000 bitcoin
18:52 πŸ”— SketchCow Oh yeah, super blowup, but for not found roms
18:52 πŸ”— DFJustin that won't work, mame needs more stuff than typical emulators
18:52 πŸ”— SketchCow ps-20a.bin NOT FOUND (tried in psu psj psu)
18:52 πŸ”— SketchCow Etc.
18:53 πŸ”— SketchCow But the bios set and the regular set seems to be missing a psx
18:56 πŸ”— SketchCow Yeah, I can't find these anywhere.
18:56 πŸ”— DFJustin https://archive.org/download/MAME_0.193_ROMs_split/MAME_0.193_ROMs_split.zip/MAME%200.193%20ROMs%20%28split%29%2Fpsu.zip
19:01 πŸ”— SketchCow I thought I did everything, but still blowing up
19:01 πŸ”— SketchCow I have to do a quick fedex run, back soon
19:01 πŸ”— SketchCow Let me know if anything jumps out
19:02 πŸ”— DFJustin the filename has to be psu.zip and not psx.zip
19:12 πŸ”— oscar Hoo boy, that... might get more attention than the handhelds.
19:16 πŸ”— DFJustin next problem, loading a zipped bin/cue doesn't seem to work with native mame
19:16 πŸ”— DFJustin you're probably gonna be better off using chds
19:20 πŸ”— DFJustin (the compression is better as well)
19:21 πŸ”— DFJustin the set at https://archive.org/details/MESS_0.149_CHD_psx is too out of date to have dino crisis but you know where to get the new ones
19:21 πŸ”— DFJustin or you can convert with: chdman createcd -i foo.cue -o foo.chd
19:23 πŸ”— DFJustin the chd is compressed so there's no need to zip it
19:59 πŸ”— datajerk has quit IRC (Read error: Operation timed out)
19:59 πŸ”— godane has joined #jsmess
20:06 πŸ”— datajerk has joined #jsmess
20:24 πŸ”— SketchCow I'm backj.
20:25 πŸ”— SketchCow https://archive.org/details/Dino_Crisis_USA_Demo
20:31 πŸ”— SketchCow What do we think I'm missing
20:32 πŸ”— SketchCow Emulator right, emulator ext right (chd), chd is uploaded
20:35 πŸ”— DFJustin everything looks ok, may be an actual bug
20:39 πŸ”— DFJustin I think it's this: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cors.archive.org/cors/emularity_config_v1/psx.cfg. (Reason: CORS header β€˜Access-Control-Allow-Origin’ missing).
20:39 πŸ”— DFJustin psx.cfg is 404
20:41 πŸ”— DFJustin not present at https://archive.org/download/emularity_config_v1/
20:44 πŸ”— SketchCow Uploading
20:44 πŸ”— SketchCow Weird, though, because it showed it as not a problem on load
20:46 πŸ”— SketchCow Tried it again, seemingly exploding.
20:47 πŸ”— SketchCow It's definitely there though.
20:53 πŸ”— SketchCow I'll find a second item to put up so we have comparison and it's not this specific one
21:02 πŸ”— SketchCow https://archive.org/details/psx_wipeout_usa\
21:02 πŸ”— SketchCow https://archive.org/details/psx_wipeout_usa
21:05 πŸ”— SketchCow If other ideas come, let me know
21:06 πŸ”— DFJustin I probably have to debug it at home
21:07 πŸ”— SketchCow I'll be around
21:15 πŸ”— DFJustin wipeout gets a new fun: WARNING: File system has desynchronized. Received following error: Error: EIO: UnknownError: The serialized value is too large (size=309196741 bytes, max=267386880 bytes).
21:20 πŸ”— SketchCow MAME 0.195 Software List CHDs (merged)
21:20 πŸ”— SketchCow 109.5 / 2115373.0 MB Rate: 0.0 / 1870.3 KB Uploaded: 0.0 MB [ 0%] 13d 9:45 [ R: 0.00]
21:20 πŸ”— SketchCow JUST 13 days left
21:20 πŸ”— SketchCow (OK, it's down to 1day already)
21:20 πŸ”— DFJustin the dino chd is fine I downloaded and ran it locally
21:25 πŸ”— SketchCow Aw, it's coming in at an anemic 76 megs a second
21:42 πŸ”— oscar You're waxin' your modem, try'na make it go faster...
23:00 πŸ”— SketchCow I'll be on watchihg if you find sonethibg
23:05 πŸ”— SketchCow while a billion chds download

irclogger-viewer