[00:03] SNDTST: HELLO [00:03] I apologize for disappearing. [00:04] And oscar as well [00:04] Had to get bunch of stuff going here at Work [00:54] *** SNDTST has quit IRC (Read error: Operation timed out) [01:31] *** Vito` has joined #jsmess [01:39] Yes, likewise. It's been a week. [01:40] I think I came here with the same objective as you, SNDTST. [01:42] The short answer is: MAME is scriptable through Lua. Most of the internals are exposed through the Lua engine (looks like it's done mostly manually internally in luaengine.cpp). [01:43] It should be easy enough to write some simple Lua functions to switch disk images, since all that functionality is exposed. The challenge, I think, is going to be calling those from outside MAME. [01:44] I would say it's not even so much that that part is particularly difficult - it's just a matter of working out the correct magic incantation [01:44] this will probably all boil down to a couple one-liners in the end [01:45] If it were on a local machine, it'd be easy; just open up a local socket or the like, and feed some data back and forth over that. [01:46] I was trying to have a think about the ideal mechanism inside the browser, though. [01:46] there's likely some function in mame that basically boils down to execute_lua_script(str) [01:46] The magic Lua incantations probably aren't all that magical. [01:46] we can expose that function, then inject lua scripts from the client [01:47] Sure, I think looking at the Lua console plugin probably covers that pretty well; the Lua interpreter is pretty much just a read/evaluate/return/repeat loop. [01:48] yeah, that seems like the best place to start [02:04] As for actually switching the floppy, it looks like it's probably pretty well exposed in the machine.images[] array. Check https://github.com/mamedev/mame/blob/master/src/frontend/mame/luaengine.cpp starting line 1974. [02:05] Depending on what machine we're emulating, some combination of load() and unload() for switching disks should work. [02:06] Of course, it won't do much for the stuff that's using pce or DOSBox. [02:06] But this is a good place to start, I think. [02:07] I just need to finish assembling the environment; I'd love to be able to do this without having to modify MAME at all, which might be possible. [02:08] What would be helpful is if there were an easy way to bring up the emscripten console... anyone a seasoned hand who knows how to wave the dead chicken just right? [02:10] (this was easier in Quake...) [02:13] emscripten doesn't really have a console built in, but ctrl+shift+j (chrome) or ctrl+shift+i (ff) will get you the dev console. from there if you can get a reference to the running emscripten module, that's where the functions that control emscripten execution are defined [02:14] in mame I believe you can press ` to get to the mame osd menu, but I'm not sue if the lua stuff is exposed through that or not [02:16] oscar: Good to ask DFJustin or Lord_Nigh about how to do the interface part for you [02:17] The framework for making this get called by a key might be a lot easier than that [02:19] *** Ipggi has joined #jsmess [02:21] Yeah, I was hoping more for stdin/stdout emulation. [02:22] The MAME Lua console extension (which starts if you start it with -console on a regular machine) just uses that. [02:25] there is a way of hooking stdin/stdout from emscripten, so that's one way to consider if injecting scripts via some exposed function doesn't work out [02:25] I just wanted it to be able to test things using the Lua console to start with. [02:25] But I can do that with the desktop version, worst case. [02:42] Console works fine in the desktop version, now to fire that up with some useful ROMs... [02:46] So... [02:46] We ALWAYS suggest using the desktop version for your whacky tests [02:46] And THEN we see where it blows up in the emscripten [02:46] Then you're not wondering which 3-4 layers might have gone boom [02:57] Right. [02:57] So in any case, this works from the Lua console, assuming you have the proper disk image in the current working directory: [02:57] manager:machine().images["flop1"]:load("Wasteland_disk_1.dsk"); [02:57] That's on machine apple2ee, so disk drive names may vary. [02:58] The drives all live in the images[] table. [02:59] There are a few image devices for apple2ee, for example: [02:59] for k,v in pairs(manager:machine().images) do print(k); end [03:00] That'll give you: floppydisk1, floppydisk2, flop2, flop1, cassette, cass [03:01] Presumably the long names are just aliases for the short names, but I'm too lazy to verify right now. [03:02] Doing :load() immediately boots the image when the machine is in boot, similar to how it would work if you inserted the disk in the drive while it was in loading mode. [03:03] The Apple II doesn't have anything like a drive state sense, so all it knows is whether a valid data stream is coming off the head when the disk is spinning, but other systems might have more state sensing. [03:04] In any case, there's a corresponding unload() method for when we want to make the drive empty. [03:07] All of this should be relatively compatible with BrowserFS. I'll probably need to wait until after the weekend to assemble my test, though. [03:11] yes, when we compile MAME we can mark arbitrary C functions as exported [03:11] then we can call them from javascript [03:11] Well, that's handy. [03:11] the lua engine has a C api, so we should be able to make function calls or inject scripts on demand [03:11] Definitely. [03:12] It should be easy enough to write some simple Lua functions to switch disk images, since all that functionality is exposed. The challenge, I think, is going to be calling those from outside MAME. [03:12] mame's lua can check for keyboard inputs I believe, so it could be bound to a hotkey? [03:12] sure [03:12] but I'd want to have a drop-down menu on the screen as well [03:13] DFJustin: Yes, that's what I was thinking. [03:13] The Lua engine also lets you draw UI elements. [03:14] *** SNDTST has joined #jsmess [03:14] nice [03:14] but probably not super useful for us, since we're running MAME at such a low resolution [03:14] I'd say you might want to consider having an HTML drop-down menu for the current image in each drive, but that might be a bit much. [03:14] Or it might not, I dunno. [03:15] I think if you want to do it right, you probably want to expose the drive loading functionality through Emularity so arbitrary Javascript elements can call it, no? [03:15] I think if we just expose the underlying functionality in a good way, then we can handle the ui any number of ways [03:16] yeah, exactly [03:16] I saw the code in emularity for loading an image by index, is this as "simple" as supplying an array of images and then wiring up this function to a UI element? https://github.com/db48x/emularity/blob/master/loader.js#L577 [03:17] SNDTST: almost [03:17] SAE is specifically for amiga [03:17] SAE has some special sauce that MAME doesn't [03:17] I was gonna say, that's sorta along the right lines, but for the wrong emulator. [03:19] But the MAME external functions are right above that, and I think that might be where you'd want to lash up the loading/unloading logic. [03:20] oscar: almost :) [03:20] we would want a method or two on the MAMERunner that let you pick an image [03:20] Right. [03:20] the MAMELoader would have a method to set the list of images for a device [03:21] You probably also want to make methods for unloading (empty drive) and also loading a blank disk? [03:21] Well, blank disk is maybe a step too far. [03:21] no, it's not :D [03:21] For images that need a "blank" (but formatted) disk, you probably want to have a default image around for that. [03:22] Depends on the program, anyway. [03:22] we would need different blank disk images for different emulators though, so that would be something we could do later [03:22] Exactly. [03:22] there's no such thing as too much when it comes to this project :D [03:22] Haha, obviously. [03:22] if we can tie a cdrom directly into your system's burner via js, we would do it! [03:23] Not even just individual emulators, but given how many low-level variations there are on RWTS on Apple II, even on individual programs. [03:23] we still want to hook printing in [03:23] If I can print to my ImageWriter II via USB->Serial from The Print Shop, I'll be a happy man. :-) [03:23] print up some nice Print Shop Pro banners and invitations [03:24] yea, I've read about the Apple II and the RWTS, but I don't know much about it [03:24] I have two whole cases of fanfold and a bunch of ribbons, birthday parties are gonna be lit af at my house for the next decade. [03:24] haha [03:24] I assume there's a generic type of disk image that will hold any data any RWTS can write [03:26] Well, I've seen talk. [03:26] The thing about the Apple II is that the Disk II interface is so low-level; it's literally a bunch of control bits plus a simple decoding engine for the GCR formatting. [03:27] All the control for the motor, head stepper, and even the spacing and alignment of bits on the track are done in software. [03:27] It's not like the C64, where the 1541 is just a serial device that does EVERYTHING for you. [03:27] yea, I always enjoy reading 4am's notes on how he cracks apple2 software [03:28] So a lot of the copy protection regimes do incredibly fancy (or stupid) things with timing, changing the encoding bytes, other stuff. There's no way to make a "standard" blank disk. [03:28] But yeah, 4am's Twitter thread on Stupid Disk II Tricks is pretty amazing in terms of the really weird things people got up to. [03:28] seems like there should be [03:28] you can address any quarter track, and you can start and stop writing at any phase angle [03:29] and you can use any nibble translation table you want [03:29] My recollection is that the .DSK format pretty much just contains the encoded nibbles, but that isn't able to preserve the weird low-level variations you can have (like those ones, yes). [03:29] it doesn't seem hard to make a file that can hold that information, and let the software format it however it wants [03:30] So I know there's been a lot of talk about a new format that goes almost (or maybe actually) all the way down to the flux transition level. [03:30] but I agree that there's no universal _formatted_ disk [03:30] Right. [03:30] But that may not strictly matter, as long as the image format is capable of representing it. [03:30] Because most programs that need a weird format for saving data, for example, are going to be able to format their own. [03:31] indeed [03:32] The question of disk image formats, obviously, isn't 100% relevant to what we're looking at here; all we need to do is be able to point MAME to new filenames. :-) [03:32] true [03:33] I've gotta get to bed soon... does the Lua stuff I pasted above give you enough information to bang on it over the weekend? [03:33] We're headed out of town tomorrow, but I'll probably be able to revisit it some Sunday. [03:33] yeah, in the case of disk storage right now we just use browserfs to map localStorage to a directory [03:33] so we can store things like high scores, etc. for each user [03:34] Right, I figured. BrowserFS solves a lot of problems. [03:34] it's a great project, yeah [03:36] time for me to sleep [03:36] I'll be around all weekend [03:37] Sounds good! I'll probably be back Sunday evening, but if not, Monday. [04:13] *** Vito` has quit IRC (Read error: Connection reset by peer) [04:13] *** Ipggi has quit IRC (Read error: Connection reset by peer) [04:15] *** SNDTST has quit IRC (Read error: Operation timed out) [05:28] *** SNDTST has joined #jsmess [06:54] *** SNDTST has quit IRC (Read error: Operation timed out) [08:32] *** hook54321 has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** oscar has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** BnARobin has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** pfalleno1 has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** DFJustin has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** ted______ has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** arkiver has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** i0npulse has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** decay_ has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** godane has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** Lord_Nigh has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** Rai-chan has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** SketchCow has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** Ash has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** bai has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** datajerk has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** bwn has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** zino has quit IRC (irc.Prison.NET west.us.hub) [08:32] *** balrog has quit IRC (irc.Prison.NET west.us.hub) [08:33] *** azakai has quit IRC (Read error: Operation timed out) [08:34] *** db48x has quit IRC (Read error: Operation timed out) [08:55] *** logchfoo1 starts logging #jsmess at Sat Mar 03 08:55:43 2018 [08:55] *** logchfoo1 has joined #jsmess [14:37] *** db48x has joined #jsmess [16:10] *** Vito` has joined #jsmess [17:02] *** SNDTST has joined #jsmess [18:39] *** SNDTST has quit IRC (Leaving) [21:46] *** azakai_ has quit IRC (Read error: Operation timed out) [22:54] *** azakai_ has joined #jsmess