#jsmess 2018-03-26,Mon

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
SketchCowGreat [00:44]
.................. (idle for 1h26mn)
oscarAll 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?
I'm inclined to just staple them onto the emulator object, but that's pretty ugly and fragile.
It'll work for now, but probably only just.
[02:10]
......... (idle for 43mn)
The worst of this is: the Lua part is probably the simplest. It's all the JavaScript that's a pain. [02:54]
....... (idle for 34mn)
***datajerk has quit IRC (Read error: Operation timed out)
datajerk has joined #jsmess
[03:28]
db48xthat'll work for now [03:40]
.... (idle for 15mn)
oscarOK, well.
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.
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.
Which would be a great big mess from outside the program.
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.
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.
[03:55]
baiwe 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]
oscarAs 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.
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.
Maybe there's a way to pass args too that I'm just missing because I'm tired.
[04:00]
baiyeah, 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:03]
oscarWell, looking at what they've done, it looks like they just wanted a way to call the functional hooks for calling periodic functions.
So there's: bool lua_engine::execute_function(const char *id)
In which "id" is the name of a function.
[04:04]
baithis 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]
oscarLua likes to pass its arguments on its stack, but there's no corresponding function to push those in luaengine.cpp. [04:04]
baiyeah, that's what I'm wondering, if you somehow prepare the engine state by pushing variables, then call the function [04:05]
oscarSo you see a big pile of things like this:
execute_function("LUA_ON_RESUME");
Which just calls that function with no arguments. That's the only thing MAME ever does with calling the functions.
I'm not opposed to adding proper functionality for adding/pushing arguments; that wouldn't be that hard.
[04:05]
baiheh, 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]
oscarWell, the bright side is that it'd be super easy to just add the push/pop functions for the stack.
Though then you have to be careful about not embuggering the stack by pushing/popping the wrong number of things, etc.
But not tonight. :-)
You couldn't do this as an argumentless function in any practical sense.
Because you have to pass in the pathnames of files.
[04:06]
baiyeah 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]
oscarAnd 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]
baiwe're abusing computer science in never-before-seen ways [04:08]
oscarYes, it's an Inception-level headache.
Javascript as an IR is certainly a pathological corner case.
In any case.
My preferred approach is to use the "device" interface that emscripten offers.
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:08]
baiyeah, that's a powerful approach - I used that for ffmpeg-in-js to feed frame data in and out [04:10]
oscarSo it won't be that hard to just talk to the Lua program over that socket and issue commands/receive status updates.
I haven't had a chance to fully think through what the protocol should look like, but it doesn't have to be crazy.
Plus, it's something that could possibly be adapted for the other emulators if we want (though that seems more dubious).
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.
Getting those into the emulator is the challenging bit.
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.
But I think the socket into the custom Lua script should be clean and extensible.
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.
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.
It's not ready for a PR, obviously.
Not least because the media doesn't actually change yet.
[04:10]
SketchCowWould love to see [04:17]
..... (idle for 21mn)
oscarhttp://some.ridiculous.solutions/emularity/example_ia2.html
And my branch: https://github.com/superdave/emularity/tree/feature/swap-that-floppy
Currently, all the selector menu does is yell at you about which peripheral you're swapping and what the new disk path is.
With an empty string for eject.
Need to also add something for adding new disks (because Wasteland is gonna be useless without that option) and loading/storing local disks.
But that can come once the actual media change functionality is working.
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:38]
baiyeah, definitely some good progress here [04:42]
oscarAnd 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).
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:43]
Anyway, I'm about out of gas for tonight.
Feel free to fire off questions/flames while I brush my teeth.
[04:48]
Ah, a few things before I go to bed:
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.
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.
Anyway, good night!
[04:58]
bai'night [05:06]
.................. (idle for 1h25mn)
db48xoscar: the code looks pretty good so far
oscar: I posted a few comments, but there's nothing really wrong with it so far
[06:31]
........................................................... (idle for 4h53mn)
***godane has quit IRC (Ping timeout: 506 seconds) [11:24]
..................... (idle for 1h41mn)
godane has joined #jsmess [13:05]
SketchCowLooks like a good start [13:08]
oscarThanks 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.
I am... not really a Javascript guy.
Or at least haven't been for most of a decade.
...and my dusty neurons remembered `var` as the local scoping keyword, not `let`. Oy.
[13:19]
.... (idle for 16mn)
What's your general preference for making update commits vs. rebasing/squashing? [13:39]
................. (idle for 1h23mn)
***datajerk has quit IRC (Read error: Operation timed out)
datajerk has joined #jsmess
[15:02]
........ (idle for 38mn)
godane has quit IRC (Read error: Operation timed out) [15:42]
..................... (idle for 1h44mn)
db48xyea, var is fine too
and I prefer not to rebase or squash commits
[17:26]
oscarOhhhh, 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). [17:33]
....... (idle for 30mn)
baiyeah 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
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:03]
.... (idle for 15mn)
SketchCowdb48x: Operation Wipeout Engaged [18:19]
DFJustin: Need your help
Not urgent
But we're going to try PSX
[18:30]
DFJustinshould Just Work(tm) [18:34]
SketchCowhttps://archive.org/details/Dino_Crisis_USA_Demo
{
"name": "Sony Playstation",
"js_filename": "mamepsx.js.gz",
"bios_filenames": [
"psx.zip"
],
"peripherals": [
"psxcd"
],
"native_resolution": [
640,
480
],
"extra_args": [
""
],
"driver": "psx",
"file_locations": {
"mameatari400.wasm": "mamepsx.wasm.gz",
"mameatari400.wast": "mamepsx.wast.gz",
"mameatari400.js.mem": "mamepsx.js.mem.gz",
"mameatari400.asm.js": "mamepsx.asm.js.gz",
"mameatari400_wasm.wasm": "mamepsx_wasm.wasm.gz"
},
"wasmjs_filename": "mamepsx_wasm.js.gz",
"wasm_filename": "mamepsx_wasm.wasm.gz"
}
(Oops)
OK, fixing the atari
[18:36]
DFJustinthe driver field should be "psu" and not "psx" [18:39]
SketchCowI chose a 14mb file so we wouldn't shoot ourselves [18:39]
DFJustinit's psx.cpp but the individual machines are called psu, psj, pse for the different regions
peripheral should be cdrom and not psxcd
[18:40]
SketchCow{
"name": "Sony Playstation",
"js_filename": "mamepsx.js.gz",
"bios_filenames": [
"psx.zip"
],
"peripherals": [
"psxcd"
],
"native_resolution": [
640,
480
],
"extra_args": [
""
],
"driver": "psu",
"file_locations": {
"mamepsx.wasm": "mamepsx.wasm.gz",
"mamepsx.wast": "mamepsx.wast.gz",
"mamepsx.js.mem": "mamepsx.js.mem.gz",
"mamepsx.asm.js": "mamepsx.asm.js.gz",
"mamepsx_wasm.wasm": "mamepsx_wasm.wasm.gz"
},
"wasmjs_filename": "mamepsx_wasm.js.gz",
"wasm_filename": "mamepsx_wasm.wasm.gz"
}
https://archive.org/details/Dino_Crisis_USA_Demo
Any ideas?
Did I make a not great psx.zip?
Should it have psx_cd in it?
[18:41]
DFJustin<DFJustin> peripheral should be cdrom and not psxcd [18:45]
SketchCowUploading fix now [18:45]
DFJustinpsu needs stuff from psu.zip and psx_cd.zip [18:46]
SketchCowa hah
I don't see psu.zip anywhere
[18:46]
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.
And now I only own 34 Nigerian palaces and 3000 bitcoin
Oh yeah, super blowup, but for not found roms
[18:51]
DFJustinthat won't work, mame needs more stuff than typical emulators [18:52]
SketchCowps-20a.bin NOT FOUND (tried in psu psj psu)
Etc.
But the bios set and the regular set seems to be missing a psx
Yeah, I can't find these anywhere.
[18:52]
DFJustinhttps://archive.org/download/MAME_0.193_ROMs_split/MAME_0.193_ROMs_split.zip/MAME%200.193%20ROMs%20%28split%29%2Fpsu.zip [18:56]
SketchCowI thought I did everything, but still blowing up
I have to do a quick fedex run, back soon
Let me know if anything jumps out
[19:01]
DFJustinthe filename has to be psu.zip and not psx.zip [19:02]
oscarHoo boy, that... might get more attention than the handhelds. [19:12]
DFJustinnext problem, loading a zipped bin/cue doesn't seem to work with native mame
you're probably gonna be better off using chds
(the compression is better as well)
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
or you can convert with: chdman createcd -i foo.cue -o foo.chd
the chd is compressed so there's no need to zip it
[19:16]
........ (idle for 36mn)
***datajerk has quit IRC (Read error: Operation timed out)
godane has joined #jsmess
[19:59]
datajerk has joined #jsmess [20:06]
.... (idle for 18mn)
SketchCowI'm backj.
https://archive.org/details/Dino_Crisis_USA_Demo
[20:24]
What do we think I'm missing
Emulator right, emulator ext right (chd), chd is uploaded
[20:31]
DFJustineverything looks ok, may be an actual bug
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).
psx.cfg is 404
not present at https://archive.org/download/emularity_config_v1/
[20:35]
SketchCowUploading
Weird, though, because it showed it as not a problem on load
Tried it again, seemingly exploding.
It's definitely there though.
[20:44]
I'll find a second item to put up so we have comparison and it's not this specific one [20:53]
https://archive.org/details/psx_wipeout_usa\
https://archive.org/details/psx_wipeout_usa
If other ideas come, let me know
[21:02]
DFJustinI probably have to debug it at home [21:06]
SketchCowI'll be around [21:07]
DFJustinwipeout 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:15]
SketchCowMAME 0.195 Software List CHDs (merged)
109.5 / 2115373.0 MB Rate: 0.0 / 1870.3 KB Uploaded: 0.0 MB [ 0%] 13d 9:45 [ R: 0.00]
JUST 13 days left
(OK, it's down to 1day already)
[21:20]
DFJustinthe dino chd is fine I downloaded and ran it locally [21:20]
SketchCowAw, it's coming in at an anemic 76 megs a second [21:25]
.... (idle for 17mn)
oscarYou're waxin' your modem, try'na make it go faster... [21:42]
................ (idle for 1h18mn)
SketchCowI'll be on watchihg if you find sonethibg [23:00]
while a billion chds download [23:05]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)