| 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 |