Jump to content

Recommended Posts

 

I have been looking into the audio code a bit it should sound less 'crunchy' now.

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

(compared to https://www.commanderx16.com/emulator/x16emu.html?manifest=/emulator/9-chase-vault/ )

I tested on a Mac with Chrome and Safari. Please let me know if that improves it for you too.

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

It's almost perfect on Windows 10 / Chrome. A little stutter here or there, but a lot better and very usable! On Firefox it's still stuttering though, sadly.

  • Like 1

Share this post


Link to post
Share on other sites

Looks good to me on Chrome/Windows, as well! Only the slightest stutter once or twice while I played the whole first level. It's now better than my old laptop running the native emulator!

  • Like 1

Share this post


Link to post
Share on other sites

Chrome on Linux is still struggling. The frame rate is dragging, which also causes the music to break up. Firefox on Linux is better with the frame rate, with less dragging, but the sound is crunchier. So, definitely performance varies between browsers and platforms.

I'm curious to see how it works on a Mac, which I don't have.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

I tried my new PSG demo with the web emulator, and it works really well, much better than the YM2151. It's not perfect, but it's just as good, if not better than, the native emulator. Holding a sustained wave shows how the sampling is not quite perfect, with little fuzzy and crunchy bits here and there. But they don't really happen any more often with the web emulator.

  • Like 2

Share this post


Link to post
Share on other sites

The file in the zip is all-caps CHASVALT.PRG, but that shouldn't matter if you are still running from a Windows server. Are you still unzipping the archive before trying to load the PRG? This used to work.

Share this post


Link to post
Share on other sites

It used to work, but I believe we changed the expected case of filenames in response to my last demo, when the web emulator was failing to load .seq files that had been included.

Share this post


Link to post
Share on other sites

I've removed the case conversion from the code and it's working again. So it's up to the programmer to take care of referencing files correctly again now.

  • Like 3

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
On 6/29/2020 at 11:05 AM, MattGrandis said:

I've removed the case conversion from the code and it's working again. So it's up to the programmer to take care of referencing files correctly again now.

I have to come back to this: I uploaded a new version of Brixx (0.8), but it didn't load the new music assets. I uploaded V0.7 again, so people can still use it.

@MattGrandisIs there a chance I can test a ZIP file before I upload it? Downloading the V0.8 ZIP file and running it in the emulator on Windows 10 works.

@SebastianVogesI'm aware that upper/lower case makes a difference in the web emulator. I used lower case in the code until now, which worked for all graphics (upper case didn't work). But not for the new music files. Only difference: graphics loads into VRAM with vload() but the music files with cbm_k_load().

Any ideas?

Share this post


Link to post
Share on other sites

If you are using cc65, the default behavior is to remap string literals to PETSCII, so the cases are effectively reversed from ASCII. If you put capital letters in source assembly, the resulting machine code will use codes that are in the graphics range for the default character set. So, unless you put in specific character mapping directives in your code, use all lowercase for filenames in assembly. You can always double-check what is generated by using -l to generate a machine code listing. Then, you need to have all actual filenames in all caps so that they can be loaded successfully by the kernal.

  • Thanks 2

Share this post


Link to post
Share on other sites

Yes, thats how I did it. Lower case in source code, upper case on disk. This is really strange... Hm... I compose the filenames with sprintf(), maybe that's an issue?

In any case it would be nice to have a test function for the "try now" feature. Like upload a zip file for testing without showing it on the download page.

 

Share this post


Link to post
Share on other sites

The lesson I learned from my own adventures in case-sensitivity was to just put the filenames in the source file in same case as the filenames will exist on disk or in the zip. The reason being that the emulator's hooks for LOAD() and SAVE() don't bother converting between PETSCII and ASCII, they just take the binary filename in memory at face value and pass it straight to the OS functions.

  • Thanks 1

Share this post


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

Yes, thats how I did it. Lower case in source code, upper case on disk. This is really strange... Hm... I compose the filenames with sprintf(), maybe that's an issue?

Ah, you are using C. I'm not sure how cc65 handles ASCII character literals in that context. You may have to use integer character values for consistency, which sucks. PETSCII is fun when you are playing around in BASIC, but it's a pain when you are cross-developing on an ASCII/Unicode platform. You may need to experiment with disassembling the compiled code and see how it handles string and character literals in different contexts.

Share this post


Link to post
Share on other sites

In my code (also C) I've used lower case in source code (string literals, not composed with sprintf()), upper case on disk.  This has worked for me on Linux and (briefly) in setting up a new laptop w/Windows 10 to support X16 development.

Share this post


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

In any case it would be nice to have a test function for the "try now" feature. Like upload a zip file for testing without showing it on the download page.

Given that an upload can be edited, updated, or deleted after going live if it doesn't work to your liking, I don't think we can devote coding time/money to adding a "Test Try It Now" feature, sorry. 

Share this post


Link to post
Share on other sites
3 hours ago, Perifractic said:

Given that an upload can be edited, updated, or deleted after going live if it doesn't work to your liking, I don't think we can devote coding time/money to adding a "Test Try It Now" feature, sorry. 

Ok, I understand 🙂 that. But "delete" for a specific version I didn't find. If you look at the change log for Brixx, you'll see what I mean 😉.

  • Like 1

Share this post


Link to post
Share on other sites
Ok, I understand  that. But "delete" for a specific version I didn't find. If you look at the change log for Brixx, you'll see what I mean .
Ah ok that's more specific. At this stage I would just suggest leaving them there. Honestly I do not foresee many people digging down to earlier revisions. 99% of people will just download the latest one.
  • Like 1

Share this post


Link to post
Share on other sites

You're probably right. I'll build the webassembly myself and run it on my raspberry. So I can do the pre-testing from there.

Share this post


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

You're probably right. I'll build the webassembly myself and run it on my raspberry. So I can do the pre-testing from there.

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?

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