[02:14] *** phe has quit IRC (Quit: Leaving) [03:36] It's live. [03:36] Macintosh Emulation is at the Archive. [03:36] It's not officially announced because: [03:37] - I want to make better descriptions for these items we have [03:37] - I want bai and maybe a few other people to see if we can fix the sound problem, since this is SUCH a directed program [03:37] I wonder if we just jam up the frames to make them less wonky [03:39] haven't had any free cycles to dig into the code yet, sorry [03:41] This is how Jobs died [03:41] every time you improve macintosh emulation, steve jobs gets another set of wings [03:41] So, James' redo of this turned out to be a hackity hack hack, so that's good to know [03:41] Steve Jobs has over 100 pairs of wings [03:41] He looks like a goddamn bird orgy [03:48] By the way: [03:48] https://vice.janicek.co/c64/#{"controlPort2":"joystick","primaryControlPort":2,"keys":{"SPACE":"","RETURN":"","F1":"","F3":"","F5":"","F7":""}} [03:48] Who wants it [03:48] WHO. WANTS IT [09:18] *** phe has joined #jsmess [14:45] *** tobbez has quit IRC (Ping timeout: 240 seconds) [17:47] db48x: I assume it's not possible to redo the loader so that the ROMs 1 of X lines are just one line) [17:49] Also, is there a simple setting for how long it waits to give the frames back to the browser? Maybe we can just send it upwards and kill the sound issue. [17:50] a fundamental mistake that product managers frequently make is to ask whether something is possible [17:51] because it's always possible [17:51] what varies is how much time, effort, and money it will cost [17:51] Well, I'm different [17:51] I don't ask if it's possible [17:51] It's more is it not possible because of your beliefs in the system [17:51] in this specific case, the cost is some time spent designing the UI better [17:51] what if bios file 2 of 3 fails to load? what do we display then? [17:52] That's a good question [17:52] Goes red generally? Shows a failure? [17:52] I mean, the system is basically binary - it goes or doesn't go) [17:52] then then bios file 1 of 3 finishes last, becasue it was largest, and overwrites the red with white [17:53] and 2 of 3 and 3 of 3 aren't visible [17:53] Or, once it's red, it's dead [17:53] sure [17:53] Better dead than red [17:53] and once we show the status of 3 of 3, we don't reset it back to 1 of 3, unless 3 of 3 succeeded and 1 of 3 failed, in which case we do [17:54] Right [17:54] I mean, if it blows up, you're going to the log anyway [17:54] so you can see that this is not really a simplification [17:54] Since you don't even quite know the ROM dying in this case, it's binary anyway [17:55] it's not actually binary [17:55] * SketchCow and db48x go through window [17:55] it's already possible for files to be optional [17:56] Fine, we'll leave it for now if you like. [17:57] It's mostly reliant on the ability to shift the window down in the theater in Archive.org anyway [17:57] So regarding that sound loop [17:57] I don't really _like_ it, I just don't see it as a fatal flaw [17:57] I don't like it because it smashes down below the black line during a loading [17:57] Super ugly [17:59] I get where you're coming from, but I suspect that not everyone sees it that way [18:00] I think we've expanded out beyond what I can cover today before my Doctor's appointment [18:00] I'm quite fine with: [18:01] - Brewster notices and goes "it's uuugly" [18:01] - Tracey goes "hmmmph, does 3 lines of PHP, it works" [18:01] - Dan sips a smoothie and puts on sunglasses [18:01] heh [18:02] So, my HOPE is there's a frame setting in the PCE.js code we've done that can be shifted [18:02] Is the version we're using on guthub? [18:02] you're talking about audio now? [18:02] Yeah [18:02] Goothib [18:02] Garthob [18:02] I'm trying to occam that bastard [18:02] we are using https://github.com/db48x/retroweb-pcejs-jsdf [18:03] https://github.com/db48x/retroweb-pcejs-jsdf/blob/pcejs/src/drivers/sound/sound-sdl.c probably [18:04] sure [18:05] From a discussion with James: [18:05] Ah, yeah I never really got around to fixing the sound output of the emulator. Basically the emulator runs chunks of CPU cycles and then yields to the browser so that it can update the screen, play sounds, etc many times a second, but that means that there are gaps in the sound. I need to add some code to compensate for that [18:05] Other in browser emulators deal with it, so I'd just copy what they've done [18:05] but I ended up forgetting about it [18:05] James Friend [18:05] I'll have a look at it soon [18:08] .. [18:08] So, I'd say that maybe I could [18:08] - Ping James a little harder to ask where the code is that tunes the chunks [18:08] - Ping azakai (I did) to stop in and assess where it's shuttering [18:09] My main concern is that it might literally be a made-up number like "100" sitting somewhere that setting it to "125" fixes it. [18:09] We'll always have slower machines that blow up, but this is very fast stuff now [18:10] yeah sound stuttering is generally either "buffers are too small" or "timestep is too big" [18:10] comedy try mame option [18:10] https://github.com/db48x/retroweb-pcejs-jsdf/commit/512b3def42800b847776a2cce3b8c9fd9ae08c22 [18:11] aka, "I queued up 10ms of audio and then spent 12ms processing the next frame" [18:11] *** godane has quit IRC (Read error: Operation timed out) [18:14] Is this the code checked in? [18:14] yes [18:14] Is.... is there buffering on the sound of my heart breaking [18:15] heh [18:16] I didn't really take the time to look into how it's actually doing the sim though [18:16] I know that it doesn't try to adjust how much sim it does based on the amount of time it actually has [18:17] also, https://github.com/db48x/retroweb-pcejs-jsdf/blob/pcejs/src/arch/macplus/cmd_68k.c#L490 is dumb [18:20] SketchCow: I uploaded a new pce-macplus.js to loaderlab [18:20] this magic nummber looks suspect https://github.com/db48x/retroweb-pcejs-jsdf/blob/pcejs/src/arch/macplus/cmd_68k.c#L460 [18:21] "just run 10000 cpu cycles and get back to me" [18:21] bai: yep [18:25] thanks [18:26] in car driving [18:26] but watch this [18:29] do e [18:30] whoever says you can't admin at 80mph [18:34] how is it? [18:39] faster, but not really less glitchy [18:45] james verified 10000 magic made up number [18:46] he also adds: [18:46] https://github.com/jsdf/pce/blob/pcejs/src/arch/macplus/cmd_68k.c#L416 [18:46] yea, we knew it was a made-up number [18:46] as emsvripten [18:47] calls step function each frame [18:49] hey you never know [18:49] always nive to realize approach of james [18:49] which was to send it, flaming, out the doot [18:49] :) [18:50] would the trick from jsmess work [18:51] fling it all at browser [18:51] or do we have other ideas [18:55] jam magic number to 50000 [18:55] I wish I could ubderstand why your accoubt wont link directly to the engine item [18:55] I may switch ownership to you [18:56] see what happens [18:56] *** SketchCow sets mode: +o db48x [18:56] *** SketchCow sets mode: +o DFJustin [19:00] we probably want smaller, not igger [19:00] bigger* [19:00] I mean really we want that number to run the exact number of cpu cycles that will fit in a 60fps update loop [19:00] that code* [19:06] 5000 [19:26] db48x: you own it niw [19:27] yiu should be able to update [19:40] SketchCow: I uploaded another experiment [19:40] oh, excellent, I can edit it now [19:45] oh yea, gzip [20:16] ,glad it works [21:01] Back home again [21:01] Doctor says nothing to worry about re lump [21:28] I tried the simplest possible thing, but it didn't really work [21:33] but there are several things I don't understand about PCE's implementation, so... [21:35] I can yank in Hampa Hug [21:37] I pinged him, he might answer. [22:07] https://github.com/db48x/retroweb-pcejs-jsdf/commit/e3fe8762223d96cc3c9cf7c86670d518cd78503c [22:17] You just did that? [22:18] I don't think that's the place to fix it. Increasing amount of audio buffered at a time would probably help more [22:18] the SDL audio buffer size is here: https://github.com/jsdf/pce/blob/pcejs/src/drivers/sound/sound-sdl.c#L251 . [22:18] James Friend [22:18] I'd try increasing that (has to be a power of 2) and seeing if that helps (it seemed to in my experiment) [22:18] I'm pretty sure the issue is that all the audio in the buffer is being played by the browser, and then there's no more left to play, before the emulator fills it up again [22:18] James Friend [22:18] then you get a gap [22:19] yup [22:19] the trick is balancing it [22:19] PERFECTLY [22:28] I guess try throwing req.samples = 1024; into something higher [22:28] I vote 4096 [22:28] Who seconds [22:30] well, we can throw random magic numbers at it and see if it helps, but if we isolate all the variables we could science the shit out of this [22:31] no, it's not that simple [22:31] basically the size of the audio buffer is going to be time * samplerate, and we need to balance that with that number in the for loop (which shouldn't just be a hardcoded number of cycles, it should be adaptive based on simulator time) [22:31] regardless of the buffer size, PCE only writes those samples that were generated by the hardware in the amount of time that you advanced the simulation [22:32] yeah if the simulator is running at less than real time, all you can do is spread the gap out so it sounds just like a slowed down version of what it should be, rather than discrete blocks of sound [22:32] right [22:33] so I did a quick experiment [22:33] I made the sound buffer 32k samples long [22:33] you monster [22:33] and you can clearly hear what's going on [22:33] it writes some samples, then the rest of the buffer is empty [22:33] but it has to play the whole buffer before it can advance to the next frame [22:33] makes sense [22:33] so the gap gets huge [22:34] is it creating a new buffer each frame rather than continuously appending? [22:34] I haven't really looked into it [22:34] wait, hold on, it sounds like what you're saying is that the audio plays synchronously/ [22:34] ? [22:34] obviously the "right" way to structure it is to have a single large buffer, perhaps enough for a second of audio, and make it a ring buffer [22:35] yea [22:35] then you query the sound system to see how much of the buffer it has played, and generate enough sound samples to keep ahead of that play cursor [22:35] like, (frame calculations happen, sound is generated), then (buffer is played in its entirity), rinse, repeat? [22:35] bai: yep [22:35] ouuuuch [22:36] it should just keep a continuously-playing audio buffer, and every time the emulator generates more sound data it just appends to that buffer [22:36] right [22:37] oh you already detailed that and said everything else I was going to say :D [22:37] :) [22:40] I guess the question is, do you think it's a problem you can fix relatively easy, or should we bring people in? [22:45] btw, you can try it on erebor.db48x.net:8000 [22:45] Wait, you're not directly fucking the production environment in the eyesockets while testing wild variable changes? [22:45] You shame all of us [22:45] only occasionally [22:46] Which html is the test html [22:46] oh, example_macplus.html [22:46] for what it's worth, I test with the dark castle disk [22:46] Loads quick and CONSTANTLY makes sound [22:46] yea [22:47] on that one you can go in and adjust the volume in the control panel to make it beep, if you missed it during startup [22:47] something that must makes a sine wave might be best [22:54] * db48x starves [22:54] somehow I haven't eaten in hours [22:56] another complication is that I'm pretty sure now that it retires more than one cycle every time through the loop [22:56] not every cpu instruction can be completed in a single cycle, so I think when it hits one of those it skips ahead that many cycles [22:57] yeah, this method of doing a fixed number of cycles with skipping seems like it'll lead to performance being all over the place [22:57] so I compute that we need to do 20k cycles this frame, and call the step function 20k times, but it actually computed more than 20k cycles [22:57] does the emulator have a concept of emulated time passing? [22:58] just cycles, as far as I can tell [22:58] look at the mac_clock function in e68000.c [22:59] I think mame's is basically along the lines of, while (emulator->timeRemaining > 0) emulator->step(); [22:59] and the emulator keeps some internal running clock of how much time has passed in the simulation [22:59] sorry, macplus.c [23:03] https://archive.org/details/mac_MacPlaymate [23:03] aaaaaand right into the adult section [23:04] Although great news [23:05] I was able to extract that from a .sit and have it just work [23:05] SketchCow: cool, how'd you do it? [23:05] used unar, took the resrc and renamed it [23:08] renamed it to what? [23:10] From macplaymate.img.rsrc to macplaymate.img [23:11] db48x: looks like there is an rtc clock https://github.com/jsdf/pce/blob/66c8c3165421b0a6a31bf2e85dc0ea35c837c85f/src/arch/macplus/rtc.c#L524 [23:11] what did you do with the original .img? [23:11] sim->rtc [23:12] I did nothing... [23:15] bai: that keeps track of either how many cycles have passed, or what the host time is [23:15] depending on rtc->realtime [23:16] ah, damn, that's what I was afraid of [23:17] hmm, what about this function https://github.com/jsdf/pce/blob/66c8c3165421b0a6a31bf2e85dc0ea35c837c85f/src/arch/macplus/macplus.c#L1489 [23:17] this seems like it's doing the "if I'm running fast, sleep for a bit" logic [23:18] it has some code to skip whole seconds if the system is running too slow, heh [23:21] I think this is the kind of thing where we could #ifdef comment the calls to this function out, and handle this logic in the emscripten main handler [23:21] rather than using usleep() [23:26] the for loop with the magic 10k number could probably be changed to look at the sim->sync_sleep value....trying to figure out exactly how this logic works, I think it's basically a running count? [23:26] like if it's > 0 it sleeps for that many seconds, otherwise if it falls too far behind it just pauses execution for a second [23:26] nanoseconds, rather [23:26] er, micro [23:31] I'm going to go eat lunch ere I starve [23:31] I will read about the Panama canal the whole time, instead of thinking about PCE [23:36] *** godane has joined #jsmess