Updated Web Emulator

[SebastianVoges 37]

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, 2020 by SebastianVoges

[AndyMt 140]

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 140]

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 37]

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 514]

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 140]

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 140]

@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, 2020 by AndyMt

[SebastianVoges 37]

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, 2020 by SebastianVoges

[AndyMt 140]

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 514]

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 140]

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 146]

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 140]

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

[AndyMt 140]

@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 237]

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, 2020 by BruceMcF

[MattGrandis 146]

Those standard extensions should be working.

[Cyber 119]

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 638]

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

[AndyMt 140]

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

[MattGrandis 146]

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?

[AndyMt 140]

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.

[SebastianVoges 37]

Version 38 based web emulator build

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

e.g. https://x16emu.s3.amazonaws.com/x16emu.html 

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

[MattGrandis 146]

Fantastic, thanks @SebastianVoges! I've updated the version on our end to R38.

[mobluse 11]

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.

[AndyMt 140]

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.