"Try it now" web emulator limitations

CX16UserSteveC · Post by **CX16UserSteveC** » Tue Aug 25, 2020 8:16 pm

Where are the limitations of the "Try it now" web emulator documented? None of the cc65 applications I've uploaded seem to work with the "Try it now" feature.

StephenHorn · Post by **StephenHorn** » Tue Aug 25, 2020 8:58 pm

The most typical problems applications have in the web emulator are due to case sensitivity regarding filenames, and files using an extension that is not whitelisted. It is also possible to go astray if you place your executable in a subdirectory within the zip file.

I don't think these limitations are specifically documented anymore.

Files must use .prg or .seq extensions, and filenames are case-sensitive. There may be a very few other acceptable extensions, but those are the only ones I immediately know are valid. It's easy to mess up the case sensitivity if you originally worked on Windows. The hook in the emulator (as far as r37 is concerned, anyways) does a straight-up byte copy of the filename string without performing any PETSCII/ASCII conversion, so this is something to be aware of if your compiler or assembler is attempting to convert an ASCII string into, say, PETSCII (whether shifted or unshifted).

Perifractic · Post by **Perifractic** » Tue Aug 25, 2020 9:39 pm

40 minutes ago, StephenHorn said:

The most typical problems applications have in the web emulator are due to case sensitivity regarding filenames, and files using an extension that is not whitelisted. It is also possible to go astray if you place your executable in a subdirectory within the zip file.

I don't think these limitations are specifically documented anymore.

Files must use .prg or .seq extensions, and filenames are case-sensitive. There may be a very few other acceptable extensions, but those are the only ones I immediately know are valid. It's easy to mess up the case sensitivity if you originally worked on Windows. The hook in the emulator (as far as r37 is concerned, anyways) does a straight-up byte copy of the filename string without performing any PETSCII/ASCII conversion, so this is something to be aware of if your compiler or assembler is attempting to convert an ASCII string into, say, PETSCII (whether shifted or unshifted).

@StephenHorn is there anything I can add to the upload page to make it clearer to people what the requirements are? If you wanted to make a little Google Doc I could easily link to that.

StephenHorn · Post by **StephenHorn** » Tue Aug 25, 2020 10:01 pm

1 minute ago, Perifractic said:

@StephenHorn is there anything I can add to the upload page to make it clearer to people what the requirements are? If you wanted to make a little Google Doc I could easily link to that.

Well, the best person to write that documentation would probably be the guy who maintains the web emulator. :3 I'm just offering what I know from my own experience, and what I can recall from the handful of other threads that have been troubleshooting problems. Hopefully @SebastianVoges or @MattGrandis can chime in.

I thought there was another thread where someone needed to troubleshoot web emulator problems, asides from my own, of course.

From the original web emulator thread, it looks like DAT and REL may also be valid extensions, but I haven't personally tried them.

Crazy Tetronimoes' issues seemed to be solved when someone converted the BASIC source code that was originally uploaded into an encoded BASIC file.

I could collate this stuff into a Google doc, sure. Might make more sense to make it a github wiki page, though, on the web emulator's repo.

Perifractic · Post by **Perifractic** » Tue Aug 25, 2020 11:00 pm

Apologies @StephenHorn, I saw your reply about the web emulator and in my haste mistook your username for @SebastianVoges! The question was intended for Sebastian in either case. ?‍♂️

CX16UserSteveC · Post by **CX16UserSteveC** » Wed Aug 26, 2020 3:52 pm

18 hours ago, StephenHorn said:

The most typical problems applications have in the web emulator are due to case sensitivity regarding filenames, and files using an extension that is not whitelisted. It is also possible to go astray if you place your executable in a subdirectory within the zip file.

I don't think these limitations are specifically documented anymore.

Files must use .prg or .seq extensions, and filenames are case-sensitive. There may be a very few other acceptable extensions, but those are the only ones I immediately know are valid. It's easy to mess up the case sensitivity if you originally worked on Windows. The hook in the emulator (as far as r37 is concerned, anyways) does a straight-up byte copy of the filename string without performing any PETSCII/ASCII conversion, so this is something to be aware of if your compiler or assembler is attempting to convert an ASCII string into, say, PETSCII (whether shifted or unshifted).

My cc65 application file names are currently all upper case but with no extension. My programs can be loaded into the local emulator using the -prg option using their current file names, and so I thought it was only necessary to specify the file name for the web emulator as well. I always use upper case for my file names in case the user chooses to start the emulator first and then load the application via the Basic LOAD command. Should I use the .prg or .seq extension, and should these be .PRG or .SEQ when added to my file names?

Also, I have no zip file. Is a zip file required?

StephenHorn · Post by **StephenHorn** » Wed Aug 26, 2020 4:53 pm

I'm not sure what the answers are to some of those questions.

If you rename the application to have a .prg extension, it might work to upload that. If not, then in addition to renaming the .prg, you'll need to pack it into a zipfile.

I would suggest using .prg instead of .seq for your program. I don't know if the extension will make a difference eventually, but I don't think it makes a difference in r37. My understanding, though, is that there is some subtle difference between how C64s treated .prg files and .seq files, and cc65 normally outputs .prg files. (There are ways to override cc65's behavior, but I assume you're not doing that.)

Post by **Main Administrator** » Wed Aug 26, 2020 4:57 pm

@CX16UserSteveCPlease upload or link to the file(s) in question so I can have a look.

CX16UserSteveC · Post by **CX16UserSteveC** » Wed Aug 26, 2020 5:07 pm

12 minutes ago, StephenHorn said:

I'm not sure what the answers are to some of those questions.

If you rename the application to have a .prg extension, it might work to upload that. If not, then in addition to renaming the .prg, you'll need to pack it into a zipfile.

I would suggest using .prg instead of .seq for your program. I don't know if the extension will make a difference eventually, but I don't think it makes a difference in r37. My understanding, though, is that there is some subtle difference between how C64s treated .prg files and .seq files, and cc65 normally outputs .prg files. (There are ways to override cc65's behavior, but I assume you're not doing that.)

Thanks for your feedback. I added the .PRG extension to my file names and now my cc65 applications seem to work (at least to some degree) with the web emulator.

CX16UserSteveC · Post by **CX16UserSteveC** » Wed Aug 26, 2020 5:11 pm

10 minutes ago, MattGrandis said:

@CX16UserSteveCPlease upload or link to the file(s) in question so I can have a look.

Thanks for your offer to take a look but I added the .PRG extension to my file names and now all of my cc65 applications seem to work (at least to some degree) with the web emulator. My currently uploaded cc65 applications can all be downloaded (or tested with the "try it now" feature) from the Graphics Apps folder.