#jsmess 2017-04-05,Wed

↑back Search

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

irclogger-viewer