Jump to content

Recommended Posts

Posted (edited)
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.

Edited by SebastianVoges
  • Thanks 1

Share this post


Link to post
Share on other sites

ok, thanks a lot! I did that - and it works here, while it didn't in the official web emulator. Strange...

So I assume the only difference  is that I didn't provide a manifest.json, instead relied on the generated one. I'll now retry to upload V0.8 with a ZIP file which includes the manifest.json.

Share this post


Link to post
Share on other sites

Unfortunately this didn't solve the problem. So:
- testing the same zip file content on a web emulator on my Raspian hosted webserver works
- on the official web emulator it doesn't.

Strange thing is: everything I'm loading into VRAM via vload() works. Everything else with cbm_k_load() doesn't.
I've reverted back to V0.7 again.

Any ideas? I'm scratching my head now...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
38 minutes ago, AndyMt said:

Any ideas? I'm scratching my head now...

What are you using cbm_k_load for? Are you loading data to banked RAM? If you are just loading everything directly to VRAM, might as well just use vload.

Otherwise, you may want to try taking a look at the machine code that cc65 is generating, make sure it is calling the Kernal LOAD function correctly. It may be worthwhile to roll your own assembly code to call the kernal and handle all this low-level business and link that into your C code.

  • Like 1

Share this post


Link to post
Share on other sites
13 minutes ago, SebastianVoges said:

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.

Ok, I've uploaded V0.8 again. I now included a manifest, so that should be fine now. And it works on my own installation of the web emulator. I'll check the console now...

12 minutes ago, SlithyMatt said:

What are you using cbm_k_load for? Are you loading data to banked RAM? If you are just loading everything directly to VRAM, might as well just use vload.

Otherwise, you may want to try taking a look at the machine code that cc65 is generating, make sure it is calling the Kernal LOAD function correctly. It may be worthwhile to roll your own assembly code to call the kernal and handle all this low-level business and link that into your C code.

I'm loading music file segments into banked RAM. I will try to check the generated assembler code, maybe I can see something there.

Share this post


Link to post
Share on other sites
Posted (edited)

@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"

Edited by AndyMt

Share this post


Link to post
Share on other sites
Posted (edited)
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.

Edited by SebastianVoges

Share this post


Link to post
Share on other sites

I've used BIN for all loadable assets, PRG for all executables, and not included any manifest in my zips, and everything works correctly.

I have notices that not using PRG for executables does not work, even if you explicitly put the filename to execute in the upload form. Once it gets to the emulator, it is checking the extension to determine file type and rejecting anything without the PRG extension as an executable. It may be doing the same check for BIN.

  • Like 1

Share this post


Link to post
Share on other sites

Yes the manifest generator certainly does atm. The emulator(s) don't, at least not for data files. Because everything works when I start Brixx in the (web) emulator directly.

I'll ommit the manifest in the future again.

Share this post


Link to post
Share on other sites

And for security reasons I've added a whitelist option to our server code that only allows certain extensions. Don't want someone to upload a .php file that can then be run straight from the server, right? So we're super doubly careful about extensions. BIN for all loadable assets is something I fully support.

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites

yes, that makes sense, especially for the web emulator. I'll change the program, assets and ZIP file accordingly :-).

Share this post


Link to post
Share on other sites

@MattGrandis

Could you maybe add SEQ, REL and DAT to the whitelist later? Those were quite common on the C64. At least for saving user data (high-scores, other databases etc).

Hm... how are we going to handle this in the web emulator? I assume not at all, that would be a massive security vulnerability...

Share this post


Link to post
Share on other sites
Posted (edited)

SEQ and DAT especially for sequentially read/written text and binary data respectively.

REL was more for relative files, which I used quite extensively back in the day, since the C64 version of fig-Forth I used in the 80s used relative files for block files.

Edited by BruceMcF
  • Like 1

Share this post


Link to post
Share on other sites
23 hours ago, MattGrandis said:

And for security reasons I've added a whitelist option to our server code that only allows certain extensions. Don't want someone to upload a .php file that can then be run straight from the server, right? So we're super doubly careful about extensions. BIN for all loadable assets is something I fully support.

Truly wise and secure. Thumb up! How about adding a note about this in the upload file form?

Share this post


Link to post
Share on other sites
1 hour ago, Cyber said:

Truly wise and secure. Thumb up! How about adding a note about this in the upload file form?

Thanks. We're trying to avoid additional work to the site at this time, as it all takes time and money. Bug fixes excepted of course. Otherwise, it's pretty much feature locked. 👍🕹

Share this post


Link to post
Share on other sites

@SebastianVogesAny plans to update the emulator behind the "Try Now" button with the latest r38 version 🙂? My latest game makes use of the sprite collision interrupts which are not available in r37.

Share this post


Link to post
Share on other sites
2 hours ago, AndyMt said:

@SebastianVogesAny plans to update the emulator behind the "Try Now" button with the latest r38 version 🙂? My latest game makes use of the sprite collision interrupts which are not available in r37.

That would be my job. Is the web emulator on version r38 already?

  • Like 1

Share this post


Link to post
Share on other sites
5 minutes ago, MattGrandis said:

That would be my job. Is the web emulator on version r38 already?

Oh sorry, for me it wasn't 100% clear who does what 😉.

No, the web emulator is still on R37.

  • Like 1

Share this post


Link to post
Share on other sites

If you have a project that requires several prg-files, can that use the "Try it now" button on this site? How do you do that? I have e.g. ARITM.PRG that could load EFFECTS.PRG at $400.

  • Like 1

Share this post


Link to post
Share on other sites

I haven't tried, but I assume you add both PRG in the same Zip file. When uploading you can specify which PRG shall be started first. That one then has to load the others.

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use