Updated Web Emulator

[SebastianVoges 33]

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 July 29 by SebastianVoges

[AndyMt 58]

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.

[AndyMt 58]

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...

[SebastianVoges 33]

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.

[SlithyMatt 206]

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.

[AndyMt 58]

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.

[AndyMt 58]

@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 July 29 by AndyMt

[SebastianVoges 33]

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 July 29 by SebastianVoges

[AndyMt 58]

Looks like it. Just tried to download a SMF files like you showed further up for the manifest:
https://www.commanderx16.com/emulator/40-brixx/brixx01.smf

Not found... So quick-fix would be to change the file endings to "BIN". If it's a hassle for @MattGrandis to fix this, then I'll go that route.

[SlithyMatt 206]

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.

[AndyMt 58]

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.

[MattGrandis 107]

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.

[AndyMt 58]

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

[AndyMt 58]

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

[BruceMcF 59]

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 July 30 by BruceMcF

[MattGrandis 107]

Those standard extensions should be working.

[Cyber 22]

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?

[Perifractic 186]

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. 🕹