Jump to content

SebastianVoges

Members
  • Posts

    35
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by SebastianVoges

  1. On 4/1/2022 at 1:59 PM, TomXP411 said:

    @SebastianVoges 

    So after talking to the other guys on the admin team, we are going to move forward with just R39 on Try-It-Now. If you want to send me the the new assets, I'll update those as soon as I can. (This weekend is nearly 100% booked, so it will be early next week.)

    Thanks

     

    I will send them over before Monday , Cheers ! 

    • Like 1
    • Thanks 4
  2. On 3/31/2022 at 9:39 PM, Edmond D said:

    Thanks for there rewording, appreciated. I'm not sure exactly if its a trivial matter to update the online emulator or not, or even where it falls in the queue of things to do. I did hear that the forum transitioning might take some time. 

    Anyway, I'm happy to see that the forum, emulator and X16 codebase is moving "forward." As well, that there is a active and vibrant community here.

     

    I can only speak for the core web version , which is straightforward to update, just building the web target  and updating the hosted assets   (Eg https://sebastianvog.github.io/x16-emulator/x16emu.html )

    In the past I provided the web emulator assets to Matt Grandis, who updated the forum . I don’t know details of the  forum integration/hosting  and thoughts  about temporary backward compatibility to the existing r38 software library. 
     

     

    • Thanks 1
  3. What I have started working on is to have an additional web-assembly library target in the main emulator project. it will produce the webassembly binaries and a core js interface for low-level interactions with the emulator. it won't generate any html/css files. It's meant to be consumed by more complex projects as @Tmp2k is mentioning. The core library would stay vanilla-js with no framework dependencies other than the emscripten compiler. As a proof of concept I am building an Angular web app  which uses the library.  Not sure when this is landing, but hopefully soonish. 

    Having said that, i think there are still many features that can and hopefully will be added to the core web emulator, and that should/will be part the main x16emulator repo. or possibly there could be another project under the umbrella of the main x16 repo for a full featured web emulator. I think having it there would probably mean more contributors than forking off. But of course anyone can do how they please through the power of open source 🙂

    Cheers, looking forward seeing x16wide evolve....

  4. Sorry, late to reply here, but it looks like everything got covered 🙂

     I think it would be good to list the supported file extensions on the the upload page if possible. And/or a link to a document/sticky forum post. On the web-emulator I can be more pro-active and put out a visible dialog/warning if the webemulator is not able to load/find a file at startup, at least it will be easier to pinpoint what went wrong. (Right now it will log it in the javascript console, but I assume most people will never look at it)

    Lastly i looked a bit into the case sensitivity issue from the web emulators perspective. I could make the WebEmulators file-system case-insensitive, so it would work more like as it does on Windows. I will give it a try

    I probably can make those changes over the weekend and also update the webemulator to the latest r38 release.

     

    Cheers, 

    Sebastian

     

  5. 8 minutes ago, AndyMt said:

    @SebastianVogesLooking at the console output I might have spotted something: the generated manifest.json doesn't contain the music files. Looks like the included manifest was ignored. Does the manifest generator only include specific file extensions? Like BIN, PRG and BAS?

    The music files have "SMF"

    Aah, looks like that is the issue. the backend likely overwrites the manifest you included . And as you say it seems to ignore SMF files when generating the manifest . @MattGrandis will have to help us here.

  6. Perhaps the generated manifest is slightly different,  did you happen to look into the browsers javascript console and see if any errors were reported ? If you upload your 0.8 again I could take a look and verify if all assets get loaded, at least from the web-emulators perspective.

    • Like 1
  7. 3 hours ago, AndyMt said:

    Argh - the "emscripten" base for the webassembly doesn't build on 32 bit raspberries 😞... Can someone please provide me with the actual web-emulator files:

    
    ex16mu.data x16emu.html x16emu.js x16mu.wasm webassembly/styles.css webassembly/main.js

    and maybe what's needed to mimmic the "try now" button?

    You can get the webassembly assets here https://github.com/sebastianvog/x16-emulator/releases/tag/1.0.0-beta.4

    Extract that to a folder and run a local web server using this folder as root directory (for example running python -m SimpleHTTPServer 8080 within this folder )

    Now you should be able to run the emulator with http://localhost:8080/x16emu.html

    To load a PRG, you need your  apps assets in a folder  and a manifest.json file (for example in your current version looks like as generated https://www.commanderx16.com/emulator/40-brixx/manifest.json )

     If  have your game files in a brixx folder and also put the manifest.json in there, you should be able to launch the game in a browser with:

    http://localhost:8080/x16emu.html?manifest=/brixx/

    If something in the emulator startup doesn't load the javascript console might give some insight, if a file/path was not found.

    • Thanks 1
  8. Hi,

    I finally got around to sync up with the changes from the main x16 repository and clean-up/rebase my commits. I pushed out a new release here:

    https://github.com/sebastianvog/x16-emulator/releases/tag/1.0.0-beta.4

    I also updated https://x16emu.s3.amazonaws.com/x16emu.html

    @MattGrandisThis contains a fix for the audio distortion I addressed weeks ago, but never pushed out as a release. Also I would like to retire/not update the 

    https://sebastianvog.github.io/x16-emulator/x16emu.html .  Could we change the try-it-online link to go to either the version on amazon aws or to the one hosted on the commanderx16 site ?

    All the code changes are now in a PR to get back to the main x16 repo https://github.com/commanderx16/x16-emulator/pull/294

     

    • Like 2
    • Thanks 1
  9. 12 minutes ago, MattGrandis said:

    Oh, that's interesting. I'll change the code on our end so that it makes everything (manifest and filenames) uppercase, that should account for the problem in the future.

    I was thinking perhaps the web emulator could do that too, make everything uppercase that is passed into the emulators host filesystem.  I am not 100% sure though if that is the right thing to do.

    On https://github.com/commanderx16/x16-emulator about the Host Filesystem Interface it says: 

    Quote

    To avoid incompatibility problems between the PETSCII and ASCII encodings, use lower case filenames on the host side, and unshifted filenames on the X16 side.

     

  10. 25 minutes ago, SebastianVoges said:

    is there a chance it could be lower/case uppercase related to the assets that need to be loaded? i see in the source it uses "GRAPHICS_TABLES.SEQ" but the assets itself and the manifest is lower case 'graphics_tables.seq'

    That seems to be it, I renamed the assets to uppercase names and updated the manifest. and it's working now for me in the web emulator.

  11. 1 hour ago, StephenHorn said:

    I tested it on vanilla r37 by unpacking the r37 zip into a folder, unpacking my zip into that folder, then running the emulator, doing LOAD"X16-SPIRAL.PRG" and then RUN. Since it doesn't depend on any particular bugs (or bugfixes) or optimizations, it should work just fine on the r37-optimizations branch as well. Is there any way to open the emulator's debugger so the program can be stepped through and memory inspected?

    That's something I can add to the web emulator. Would that be accomplished by passing  '-debug' to the emulator during startup, or would anything additional need to be done ?

    For testing you could bring up the javascript console, go to the main.js sources and put a breakpoint on line 67 ( after var emuArguments are defined. then reload (f5 or reload icon the page) Once it breaks, you could paste "emuArguments.push('-debug')" into the javascript console window and then continue execution. I will  run the emulator with out the optimizations, and see if it's related to those. 

  12. I have to try it on Linux yet. Performance really differs between browsers/OS combination it seems.    One thing I Still would like to try is to pass native sample rate from the browser environment to the core emulator and use this rate.  I am not sure if there is significant  extra overhead if the sample rates don’t  match. In the Code we hardcode  Samplerate to 48828. But on the Mac the native sample rate in the chrome Audio context is 44100. Not sure if that matters at all.   After doing many modification to the audio code, I reverted most of them back and only increased the samples_per_buffer constant to 1024. Which got rid of the crunchiness in most cases. 

    • Like 2
  13. 15 minutes ago, MattGrandis said:

    We've been mulling over whether it would be a good idea to be able to put the manifest.json OUTSIDE the zip file, but before you do any work in that direction (unless you want to), I'll try rewriting our code so it adds the manifest.json directly to the zip file. One thing though: it looks like the "old" way doesn't work anymore. It's throwing an error: "Unable to read manifest. Check the manifest http parameter".

    See here: https://www.commanderx16.com/emulator/x16emu.html?manifest=/emulator/9-chase-vault/

    The manifest.json file still exists like before.

    I am fixing that now... copy&paste bug. I wish I had some unit-tests that could have caught that.

    In regards to the manifest.json separate from the zip, i thought about this too. Then inside the manifest we could have a link to the .zip file. also another thought if we do this, do we then really need the resources section or do we just load any file that is inside the zip the manifest is pointing to. That would make it easier to not have to maintain the list of resources to be loaded.

    so the manifest could just be

    {

    ...

    start_prg: FILE.PRG

    resource: https://x16repos.s3.amazonaws.com/chase.zip

    }

    I don't know, i kind of like that everything could be self-contained in one zip, but on the other hand it would simplify things. the developer would just upload a zip with all his x16 assets and just say what is the start_prg and don't worry about the resources section in the manifest

     

    • Like 1
  14. 54 minutes ago, MattGrandis said:

    I'm adding the new functionality now. I'll have to adapt some code on the server to add dealing with zip files, so until further notice, the Try it now function might break! I'll give notice here when everything's back to normal again.

    Sounds good.  And also if you think you the manifest/zip file mechanism for loading is missing something or could be done in a different/better way, please let me know. I am open to make modifications to make it as easy/useful as possible.

    • Like 1
  15. @MattGrandis @Perifractic

     I have an updated version here:

    https://x16emu.s3.amazonaws.com/x16emu.html?manifest=https://x16repos.s3.amazonaws.com/chase.zip

    Support for zip files in the ?manifest parameter was added. (the old way should also still work)

    The emulator expects the manifest.json in the root of the zip.

    Support for Basic programs was added: 

    In the manifest, the basic file has to be specified with 

     "start_bas": "HELLO.BAS"

    I also added error logging in the javascript console. If the emulator doesn't start as expected, the logging should hopefully point to the area of failure.

    Lastly , I took some work-in-progress speed optimization code from @StephenHorn and Michael Browns Pull Request to make web emulator a lot more usable.

    The zipped assets for the web emulator are under https://github.com/sebastianvog/x16-emulator/releases/tag/1.0.0-beta.2

    By next weekend I hope to clean up the code,  add  some general readme for the manifest.json format, and create a pull request to get this back into the main x16 GitHub repo.

    Cheers,

    Sebastian

    • Like 1
    • Thanks 2
×
×
  • Create New...

Important Information

Please review our Terms of Use