[00:08] Back [00:09] SketchCow, awesome [00:10] Listening to Break the Chain, this doesn [00:11] this doesn't seem to be in HVSC, unless I'm missing something. Huh. [00:11] n/m found it [00:13] Listen to https://deepsid.chordian.net/?file=MUSICIANS/I/Image/Break_the_Chain.sid vs https://archive.org/details/Break_the_Chain_1990_Dynamix&external_js=1 . It sounds faster than the IA version, because IA defaults to PAL, where here, this song was designed for NTSC. I don't know how to resolve this except maybe metadata, and that would still not help if different ones were on the same disk [00:23] Going to try compile again from v3.2 tag. Maybe that's more stable [00:23] If not, I'm still a fan of using a tag instead of whatever's latest [00:32] I agree [00:32] This sort of stuff comes later [00:33] Sgeo: Did the stuf I link to help? [00:35] Hmm? I saw the message about Wayland not working, but that doesn't seem to apply since I'm on X. (Although you didn't link that, maybe you linked something else I didn't notice?) [00:36] Well, it's an example of it coredumping due to issues against X [00:37] Maybe turn on an Xvb session just to see? [00:40] I have no idea what that is [00:41] Xvfb :1 -screen 0 1280x1280x24 & [00:41] https://i.imgur.com/u9ZXq3O.png [00:41] Well, that's nice. How did it work out [00:41] The switch to v3.2 tag worked [00:41] What does tag mean in this case [00:42] Wait, you compiled the latest beta? [00:42] Yes, and that was a mistake. Tag = specific version in SVN [00:43] OK [00:43] So, we have ourselves a functional little VICE [00:44] I THINK the next thing to do is make it absolutely hate life with an emscripten build [00:44] Unless there's something else [00:45] When you were talking about patches being unnecessary, was that just the patch to Emscripten itself you were referring to? Half of the VICE patch looks important and half looks like decisions I disagree with [00:45] ha ha [00:45] Emscripten. [00:45] We have the creator of Emscripten right here, after all. [00:45] He signed off on "we probably don't need those patches anymore." [00:46] The VICE patches are unquestionably important. [00:46] The main keys are how he re-jiggers the thing to flow so Emscripten won't blow up [00:48] Either bai or DFJustin or Vito` can respond with any questions you have about compiling in Emscripten [00:48] Although there are build scripts and you can see what he was generally going for [00:48] I'm SURE there's cases of him tying off features because it made things complicated [00:48] Features that would no longer be too complicated [00:50] I'm going to read the Emscripten tutorial a bit and then AFK for food, then I'll get started [00:52] A very simple overview is there's em* versions of everything that do the work of compiling out to javascript/webassembly. [00:52] emcc, emconfigure, etc. [00:55] Hmm, can this Emterpreter thing just sort of take care of the SDL_Delay stuff automagically? [00:56] In most cases with Emscripten, assume yes, and then walk it back if an issue arises. [00:56] And we keep the original vice.js to see if there was a hard-won lesson Robert ran into [00:56] The key is never murder yourself over this [00:58] But Emscripten at this point is ridiculously robust, in no small part due to this team of weirdos, who forced MAME through it [01:00] Sgeo: yeah there are three ways to do the emterpretify thing...either "emterpretify all the things" (slow, but best place to start), "emterpretify everything except these blacklisted functions", or "only emterpretify functi9ns on this whitelist" [01:02] the whitelist is the more ideal way of doing it in the long run, basically the process for that is that you have to whitelist every function ij the stack above any place which calls sleep() (or anything that used it) [01:02] really applied to anything that might block synchronously for more than a frame, like file IO [01:03] (not all, just ones which take a long time to return) [01:37] You seem to have bootstrapped Emscripten SDK by cloning from GitHub. In this case, use "git pull" instead of "emsdk update" to update emsdk. (Not doing that automatically in case you have local changes) [01:37] Yes [01:37] Following the instructions on the website gave me that message [01:37] Website might use clarification? [01:37] Yes, use git pull and keep going [01:37] The rest worked fine [01:38] azakai: Bug in the instructions on bootstrapping from the Emscripten site [01:53] *** db48x has joined #jsmess [01:57] SketchCow, what was your fix for the ar problem? [02:03] SketchCow: oh, what is the bug? [02:03] Disable it [02:04] Disable the check, it's horseshit [02:04] azakai, http://kripken.github.io/emscripten-site/docs/getting_started/downloads.html [02:04] azakai: It tells you to use emsdk update and it's really git pull [02:05] oh good point, thanks Sgeo and SketchCow - we changed to git pull but didn't update the later part [02:06] We're here to drag the emscripten wagon into the stratosphere of success [02:06] And play commodore 64 [02:10] I don't know how to actually disable stuff. Lemme try deleting the lines from configure.ac and reruning autogen [02:11] I actually took it out of the configure file, yes [02:11] But you got it to compile - how did you make it work [02:12] By not doing anything Emscripten related at that point. [02:12] That was a native build [02:12] I couldn't get the native build to work without removing it [02:12] Oh, huh. [02:12] I think you have a better environment than I did [02:13] What version of VICE were you building? If it was from SVN trunk, issues could be time of checkout related [02:13] 3.2 [02:13] Even I knew going later than 3.2 was kray [02:13] I was just following the neocities page's exact instructions >.> [02:14] Well, I was using a much older ubuntu too [02:14] So plenty of room for destruction [02:14] Anyway, you'll note that what he does in the code is a bunch of ifdefs [02:14] We did that in MAME too [02:14] Ah. Yeah I'm using Ubuntu 18.04 LTS [02:16] Unless you think it a bad idea, that main loop mod is critical [02:16] (I'm using https://github.com/rjanicek/vice.js/blob/master/vice/0001-Vice-2.4.4-Emscripten-changes.patch as the critical one) [02:16] There's a 2.4 but that's just one revision back [02:18] I can start playing with it after I see it failing horribly in a browser, I think? [02:18] export ar_check=no is probably the cleanest way to disable the check [02:19] I agree on that workflow [02:19] Just pointing out that's likely the #1 thing that will make it not run [02:19] Unless it magically does [02:20] Ah, ty [02:20] Hmm, when it complains about libpng, is it asking me to install libpng-dev or libpngsomething? [02:21] I assume yes unless someone thinks differently [02:21] db48x: This guy's on fire [02:21] *** SketchCow sets mode: +o db48x [02:21] Was hoping for something more specific lol. Well, my notes already have a cluttered and probably excessive apt-get install [02:22] I completely cargo cult, I know little [02:22] I just google for errors and then find what people did [02:24] I already have libpng-dev installed, so it's not that (unless it's failing to find it). And there's no "libpng" as such, just a bunch of versioned ones [02:24] Although since it did compile natively, this is odd [02:25] PNG is only used for screenshotting, I can remove it [02:28] Configured [02:35] ../../src/vice_sdl.h:59:14: fatal error: 'SDL/SDL_keysym.h' file not found [02:35] This looks like the issue a part of the VICE patch was supposed to handle, by referencing a different file. [02:35] But is this a VICE issue or an Emscripten problem [02:35] bai is SDL_keysym.h supposed to be in Emscripten somewhere? [02:36] emscripten ships a full sdl port these days so it ought to have everything, but there could be a mismatch if VICE is expecting SDL 1.2 since I think emscripten's is SDL2 [02:37] I think VICE can handle both, not sure what it defaults to [02:40] https://github.com/svn2github/vice-emu/blob/eb067976054d83631788968a42d140ec8cccbd4d/vice/doc/readmes/Readme-SDL2.txt#L44 [02:41] So I'm not sure if I should try to hack together the SDL version to work, or try using SDL2 and encountering such annoying bugs [02:50] I'm now getting spammed with identical warnings about unused command line arguments [02:53] Oh the Emscripten website has stuff about SDL1, I should look into that [03:01] I have an a.out.js now and I'm not totally sure where it came from. I did an emmake but the build script in the vice.js repo has more steps after it, which I haven't successfully performed yet [03:02] It probably explodes [03:06] sdl2 is probably the better target, unless their native sdl2 implementation has its own set of problems [03:07] https://retropie.org.uk/forum/topic/3972/vice-c64-emulator-now-supports-sdl2 [03:07] https://pyra-handheld.com/boards/threads/vice-3-2-sdl1-and-sdl2.77520/ [03:08] Two cites they definitely do sdl2.0 [03:08] There's some bugs though I think [03:13] ERROR:root:Compiler settings error: forced aligned memory is not supported in fastcomp [03:13] ERROR:root:Compiler settings are incompatible with fastcomp. You can fall back to the older compiler core, although that is not recommended, see http://kripken.github.io/emscripten-site/docs/building_from_source/LLVM-Backend.html [03:13] The build script from the vice.js repo sets forced aligned memory [03:13] azakai: Thoughts [03:15] Removed that option from the script, and now getting this issue. There is nothing after the last colon [03:15] error: Linking globals named 'console_open': symbol multiply defined! [03:15] WARNING:root:Note: Input file "@/tmp/tmpjxAxMB.response" did not exist. [03:15] ERROR:root:Failed to run llvm optimizations: [03:18] "EMCC_DEBUG=1 in the env should show more detailed logging, and might help figure this out." [03:19] Thansk [03:19] Well, that's more detailed. None of it after the colon where the wording makes me expect there to be something, but a LOT before that [03:30] bai, help/ [03:37] bai will see you but he has a kid and has to hop between that low priority issue and this [03:37] db48x and DFJustin - if you have any other thoughts on this [03:37] Is the error the same [03:37] Yes. I can send the other output but it doesn't look useful [03:39] https://hastebin.com/oyahacupoc [03:43] sounds like there's more than one definition for console_open [03:48] Going to try a make clean then emmake make x64 then the build script [03:56] :D [03:56] not sure about that particular issue. is console_open a vice function? [03:58] SketchCow: it's ok to ignore the "force aligned memory" warning. the flag is no longer relevant (can stop sending it to emcc) [03:58] Yes [03:58] Hmm, there's a console_unix.o that has one definition [03:58] Not sure where another would come from [03:59] There's also a console.o [03:59] for the console_open duplicate symbol, you can debug that by running llvm-nm on the input files (listed in the debug output there). you should see that it appears in more than one - perhaps the same library is statically linked in twice [03:59] There's no console.c, but there is a console.h [04:01] i have to go, but if you get stuck on this, i can help debug it tomorrow [04:05] Ok, thanks [04:24] Ignore the message "There's no console.c" [04:26] Trying native build with SDL2 [04:37] Native SDL2 build compiled but is segfaulting [04:57] https://docs.google.com/document/d/e/2PACX-1vRdZrs8HYEqL5AoQ9Au9R1RTFEff0-FDp36N2p3k8ln5_XyyypSKMhu6nAz0EWPLF_sTRjJGmAyYhCo/pub is where I'm keeping my notes btw, until success and I can post them somewhere more accessible [05:08] I now have x64.js and x64.wasm files [05:09] Out of laziness I'm changing the build script to make a html file [05:12] *** Sgeo_ has joined #jsmess [05:14] *** Sgeo has quit IRC (Ping timeout: 255 seconds) [05:16] There's a nonzero chance my computer dying just now affected files on the VM. The HTML file seems to be empty, despite it not being empty before computer died [05:16] I should just superglue the power cord in or something [05:20] It's blowing up, but with "LinkError: import object field '__mouse_enabled' is not a Number" [05:20] Not sure why it would blow up with that [05:34] How big is x64.js [05:38] 1.6mb, and there's a 2.6mb wasm file [05:47] Going to try adding joyport [05:51] Fixed that linker error, now weirder stuff is blowing up [05:52] fun :D [05:53] sorry I haven't been around to help much, just dealing with baby stuff [05:57] Currently caught in an endless loop of there are 20 million new directories the old build script didn't know about [05:58] oh, I know in the past, sometumes emscripten would get stuck in a bad state if a build was interrupted and you tried to resume [05:58] ...I think the script is wrong [05:58] not always, but sometimes, it would just chew through disk space until you did a make clean [05:58] It's using --embed-file to include .o files [05:58] or, emmake make clean really [05:58] Is that correct or incorrect usage of emcc? [05:58] https://github.com/rjanicek/vice.js/blob/master/build-x64#L29 [05:59] What's the right way to do this? [06:00] hmm. I've never used it like that no [06:00] I don't know what --embed-file does [06:01] Embeds a resource into the compiled result. But .o files should be LLVM code, right? So I'm confused [06:02] normally it's the same as gcc, emcc -o [06:05] Ah, ty [06:05] Let me get the bulk of these new imports in before I start messing with that [06:08] I do wonder if I should be replacing it with a listing of all .o files [06:09] Now it's complaining about a missing SDL_SetRelativeMouseMode, which I can confirm is NOT a part of VICE [06:13] Maybe I was misreading the script before [06:13] yeah that's an sdl function...it should trigger pointerlock in emscripten-conpiled apps, I believe [06:16] https://github.com/emscripten-ports/SDL2/blob/1d03c6824752d71d44c7e7ea3dd28909deda9659/include/SDL_mouse.h#L162 [06:16] that's for sdl2 [06:17] *** arkiver has quit IRC (hub.efnet.us irc.servercentral.net) [06:17] *** zino has quit IRC (hub.efnet.us irc.servercentral.net) [06:19] Ugh I screwed something up and now it's complaining at me about functions that I know should be there [06:26] WARNING:root:emcc: cannot find library "SDL2" [06:27] Oh I need a change in the build script [06:27] -s USE_SDL=2 [06:28] There you go! [06:29] LEss pleasantly, why is it STILL warning me about a boatload of missing functions? They shouldn't be missing [06:31] *** Arkiver2 has joined #jsmess [06:36] ERROR:root:vice/src/*.o: No such file or directory ("vice/src/*.o" was expected to be an input file, based on the commandline arguments provided) [06:36] It's... supposed to understand *, right? [06:43] Found the problem. Bash is VERY sensitive to spaces following \ line continuations [06:47] ahh, interesting [06:50] *** Sgeo_ has quit IRC (Read error: Operation timed out) [07:24] *** Sgeo has joined #jsmess [11:41] *** datajerk has quit IRC (Max SendQ exceeded) [11:41] *** datajerk has joined #jsmess [13:09] *** db48x` has joined #jsmess [13:10] *** db48x has quit IRC (Read error: Operation timed out) [14:40] *** db48x` is now known as db48x [14:41] *** mx has joined #jsmess [17:50] Continuing my uploads of C64 loveliness [17:51] Commodore C64 - Applications - Test Disks - [D64] Commodore C64 - Docs - [D64] [17:51] Commodore C64 - Applications - [D64] Commodore C64 - Educational - [D64] [17:51] Commodore C64 - Collections - Derbyshire Ram - [D64] Commodore C64 - GEOS - [D64] [17:51] Commodore C64 - Compilations - Games - [D64] Commodore C64 - Games - Boulder Dash - [D64] [17:51] Commodore C64 - Coverdisks - [D64] Commodore C64 - Games - Previews - [D64] [17:51] Commodore C64 - Cracktros - [D64] Commodore C64 - Games - SEUCK - [D64] [17:51] Commodore C64 - Demos - Collections - [D64] Commodore C64 - Games - [D64] [17:51] Commodore C64 - Demos - [D64] Commodore C64 - Music - [D64] [17:51] Commodore C64 - Diskmags - Commercial - [D64] Commodore C64 - Public Domain - [D64] [17:51] Commodore C64 - Diskmags - Scene - [D64] [17:51] Sticking with D64 for now because it basically works. [17:53] What other formats do you have? [17:53] Oh god, many. [17:53] And in theory it will take them all [17:53] But for the moment, let's move incrementally. [17:54] For example, before I remove duplicates, there are 184,314 C64 .d64 images [17:54] That's... a lot man [17:54] Hmm, GEOS is going to be unpleasant for users without some configuration. Maybe the best way is to be able to specify custom configuration files. [17:54] Well, we will be able to do that going forward. [17:54] We do it now. [17:54] a800 vs a800cart etc. [17:54] Boots off the cartridge slot instead of the disk [17:58] *** Arkiver2 is now known as arkiver [17:58] How goes the attack, sgeo [18:00] I just woke up, need to eat first [18:00] You went to SLEEP [18:00] In a BED [18:00] What THE [18:00] When he was working on our first massive round of adaptable response to MAME upgrads, Vito` rested for 5-10 minutes hanging upside down on a rod outside [18:02] Now removing all the [a2], [a], [b] stuff from this list. [18:02] [a2] was 20,000 items, for example. [18:06] *** Sgeo_ has joined #jsmess [18:08] *** Sgeo has quit IRC (Read error: Operation timed out) [18:09] *** Sgeo__ has joined #jsmess [18:10] So, in the TOSEC Naming Convention, if something is the same-but-different, like a sector layout or some other aspect, it gets a [a] designation. [18:10] If another copy shows up like this, it gets [a2] [18:10] [a3]. [a4]. [18:10] In most, like, at the worst, it gets to [a5] [18:11] In C64 land, though.... I'm at [a31] and climbing [18:12] *** Sgeo_ has quit IRC (Ping timeout: 255 seconds) [18:16] Damn, past [a39] [18:17] 15 items have 50 variations [18:19] ./Commodore C64 - Games - [D64]/Beach Head 2 (1985)(Access Software)[cr XCS][a65].zip [18:19] ./Commodore C64 - Games - [D64]/California Games (1987)(Epyx)(Disk 1 of 2 Side A)[cr ESI][a65].zip [18:20] ./Commodore C64 - Games - [D64]/California Games (1987)(Epyx)(Disk 1 of 2 Side B)[cr ESI][a65].zip [18:20] ./Commodore C64 - Games - [D64]/Caveman Ugh-lympics (1988)(Electronic Arts)(Disk 1 of 2 Side B)[cr ATC][a65].zip [18:20] ./Commodore C64 - Games - [D64]/Dallas Quest, The (1984)(Datasoft)[a65].zip [18:20] ./Commodore C64 - Games - [D64]/G.I. Joe (1985)(Epyx)(Side B)[cr ESI][a65].zip [18:20] ./Commodore C64 - Games - [D64]/Little Computer People (1985)(Activision)[a65].zip [18:20] We're at 65! [18:24] We're at 128. [18:29] Well, the winner was Little Computer People. [18:29] ./Commodore C64 - Games - [D64]/Little Computer People (1985)(Activision)[a289].zip [18:31] Yeah, see, I've already got it down to 86,814. Down from 184,314. [18:31] *** azakai has quit IRC (Ping timeout: 255 seconds) [18:44] Sgeo__: Just for trivia's sake - my goal will be to move the vice.js.gz into a second js, and we'll add a version called vice-24 as a potential emulator string, so that in the future, we can mess around with choosing the 3.2 or 2.4 variants to see if there's improvements in emulation [18:45] The way our system works, we can keep adding vice-*.cfg and vice-*.json files called against the vice.js.gz (and vice.wasm) that will account for having certain cards in, certain approaches, etc. [19:07] https://archive.org/details/helloFRIEND_2005_Fairlight&external_js=1 [19:07] Beauty [19:09] Uploading 20,000 demos now [19:46] sid_quad_address_start doesn't seem to be in the warnings of unresolved symbols [19:52] I just refreshed the page without doing anything and am now getting a totally different error [19:53] C64MEM: Error - Couldn't load kernal ROM `kernal'. [19:53] Error - Machine initialization failed. [19:53] Oh, so things we learned [19:53] I'm fine with working on fixing that, less fine with the fact that the prior error disappeared into the aether without me doing anything [19:53] Always use incognito mode [19:53] Maybe a file was cached in the browser [19:53] Or whatever the browser calls it [19:53] Always use it, then crush the incognito mode, then bring it back for each try [19:54] Because yes, that will eat your life otherwise [20:20] Looks like the build process is including the kernal, I guess VICE just isn't finding it, like it's not where it expects it to be [20:21] Or could be something wrong with the file [20:22] ...or file loading could be a sync issue? Hey bai, would trying to load a file be the sort of thing that I should be putting through emterpreter? I might just go ahead and add that setting to the build script now and see what happens [20:23] My suggestion, as always, is to see what the other thing did [20:24] https://archive.org/details/softwarelibrary_c64 [20:25] Going to let that run. Once the loader is put into the system (the updated one), that's 40,000 items [20:27] *** Sgeo_ has joined #jsmess [20:29] *** Sgeo__ has quit IRC (Ping timeout: 255 seconds) [20:41] Got past that issue, now at the point where it's complaining about the main loop function being missing [20:45] ROFL the reason that VICE.js constantly shouts perkele is that the setting wasn't set to stop the code after the main loop from running [20:48] Are your tests browsable from outside? [20:53] Not at the moment, I'm testing from Python's simplehttpserver on the machine [20:58] *** azakai has joined #jsmess [20:59] Hey, did old Emscripten stuff recommend coroutine libraries, and is that still applicable? [21:03] we didn't do any coroutine library stuff for mame or dosbox, to my knowledge - might have just been path of least resistance for whoever did vice.js stuff to make the main loop async [21:03] I would think the path of least resistance is usually to use Emterpreter? Maybe that's newer? [21:05] emterpreter was a later addition yeah [21:05] but doing it yourself may still be faster [21:06] it's hard to say really. with dosbox I know we were really paranoid about how much it would slow things down and were pleasantly surprised to find out that it was a non-issue [21:06] but it may be the kind of thing where it's fine for most emulated systems/games but it moves the cap on which ones we can run at 100% a bit lower [21:11] emscripten_set_main_loop_timing: Cannot set timing mode for main loop since a main loop does not exist! Call emscripten_set_main_loop first to set one up. [21:12] Sgeo_: Just as a VERY INSIGNIFICANT side thing, I'm (temporarily) turning off sound at archive. [21:12] I added the emscripten_set_main_loop to the same place vice.js did. And I added a log, that's showing up, so its not like the new code isn't being used [21:13] The sound buffer overflows on the firefox instance and I just want to screenshot the planet while we work on things [21:19] Yeah, fixed it [21:19] OKAY THIS NEXT IMPROVEMENT GOES OUT TO DFJUSTIN fingerguns [21:21] who what where [21:21] I'm doing the C64 from scratch [21:21] No legacy, no previous work [21:21] Therefore.... switching to PNG [21:22] \o/ [21:24] so there is the the c64 preservation collection set of .g64 images which is like the commodore 64 .woz https://archive.org/details/C64_Preservation_Project_10th_Anniversary_Collection [21:29] Well, one insane set at a time [21:29] AFK [22:06] When MAME emulates a machine that's in a text mode, like the C64 boot screen, does it still require a graphics display to do so? Or can that be seen in a terminal? [22:20] graphics display only [22:20] if it's a machine that does rs232 output you can direct that out to a terminal program though [22:29] *** zino has joined #jsmess [22:55] back [22:56] or to built-in terminal emulator [22:56] *** shattere1 is now known as shattered [22:56] I wonder if theres certain points where Emscripten assumes emscripten_set_main_loop won't be called, and it's too late to call it after that? [23:03] Hmm, actually, shouldn't Emterpretify_async make the whole thing not needed? Maybe something's calling emscripten_set_main_loop_timing which breaks without that main loop [23:05] hmm. I'm not sure if I've ever done anything PURELY with emterpretify, I've always worked with systems which did the requisite emscripten_set_main_loop stuff [23:06] which basically just involves breaking out of the typical native while (true) { doGameStuff(); } loop and letting emscripten call doGameStuff() [23:06] ("just") [23:22] Is there an easy way to trace what's making the call to emscripten_set_main_loop_timing ? [23:22] Or maybe I should make a dummy main loop [23:26] *** Lord_Nigh has quit IRC (Read error: Operation timed out) [23:30] *** Lord_Nigh has joined #jsmess [23:46] Wonder what happens if I disable sound, considering the VICE error I keep seeing about configuring sound [23:55] As a last resort I might try massaging the 2.4.4 patch into the VICE 3.2 codebase. I'd rather not, I like the thought of tampering with VICE as little as possible