Moving to R39

desertfish · Post by **desertfish** » Sat May 07, 2022 12:49 am

I was able to build the web emulator successfully myself, however it didn't run because it stopped with a audio subsystem not initialized SDL error.

I'm on Manjaro Linux and only had to install emscripten as additional package, then type make wasm

After that it downloaded and built the dependencies automatically, generated a couple of web files including a big wasm file at the end. I also tried building the official r38 release that's on the forum and it had the same issue when actually launching the emulator. So it's an issue on my end, but the actual compilation is done without errors. I know too little about emscripten to see where the problem lies.

mobluse · Post by **mobluse** » Thu Jun 09, 2022 10:12 am

I think this site should upgrade the web emulator to R41 now (since R39 had some bugs), but perhaps have R38 too for old programs that haven't been converted yet or doesn't work in both releases. One should be able to choose if a program should use R38 or R41, but all existing programs should have R38 in order not to break code.

desertfish · Post by **desertfish** » Thu Jun 09, 2022 11:29 am

To do that, someone has to step up that can successfully rebuild the emulator to WASM

I tried it as you can read above but wasn't able with my very limited knowledge about this process, to actually get it working....

SlithyMatt · Post by **SlithyMatt** » Thu Jun 09, 2022 1:40 pm

Really, the web emulator just needs to be brought up to date, and we need to deprecate earlier releases. R38 was around for a long time, but it's time to move past it.

TomXP411 · Post by **TomXP411** » Thu Jun 09, 2022 3:54 pm

On 6/9/2022 at 3:12 AM, mobluse said:

I think this site should upgrade the web emulator to R41 now (since R39 had some bugs), but perhaps have R38 too for old programs that haven't been converted yet or doesn't work in both releases. One should be able to choose if a program should use R38 or R41, but all existing programs should have R38 in order not to break code.

We're going to have to rebuild the framework for that for phpBB, since there's obviously no "phpBB Commander X16 emulator" plugin. When we do, we will have the ability to run different emulators for different downloads. So downloads that currently work in R38 will use the R38 emulator, and new uploads will use the latest emulator available at the time of upload.

There are some things in the back end of how the current system works that I don't like and I feel are security risks (I'm not going to give specifics on an open forum), so there will be some changes to the process until we find a way to make the "try it now" more secure.

desertfish · Post by **desertfish** » Thu Jun 09, 2022 4:09 pm

Ok , some progress, and some new setbacks.

I got the v41 wasm emulator built + running in a local browser!

However, there were a bunch of compiler errors that I don't understand (lack of C familiarity) and I simply commented out the offending lines, thus the result I have now will fail at certain things.

Johan Kårlin · Post by **Johan Kårlin** » Mon Jun 13, 2022 7:18 pm

I have finally started to upgrade my programs from r38 to r41. I am trying to find out exactly what the breaking changes are by browsing this thread and all the official documentation. I get that I cannot use zeropage 0 and 1 but then it is hard to see what has changed. Memory maps seem intact. Is there a short summary to find somewhere?

TomXP411 · Post by **TomXP411** » Tue Jun 14, 2022 2:18 am

On 6/13/2022 at 12:18 PM, Johan Kårlin said:

I have finally started to upgrade my programs from r38 to r41. I am trying to find out exactly what the breaking changes are by browsing this thread and all the official documentation. I get that I cannot use zeropage 0 and 1 but then it is hard to see what has changed. Memory maps seem intact. Is there a short summary to find somewhere?

As long as you use the KERNAL entry points, most things will remain intact. In fact, Michael seems to have worked very hard to keep the basic KERNAL routines the same.

As you already discovered, addresses 0 and 1 set the bank number for banked RAM and the system ROM. Also, the addresses in VERA have changed. So you need to query $9F35 to get the screen address. ROL this left one place to get high byte of the address, and the Carry flag is the bank number. Here's a little routine I worked up to load the data into a program: (Don't use this one. The routine 2 posts down is smarter and shorter. Also with one less bug.)

This loads the address into $0500, little Endian. See that $0502 is $21, which is the value set when Carry is set. This means that the map base is in bank 1. To confirm this output, I wrote a BASIC program that does the same basic thing, then tested its output by writing to the address I read and computed:

And a successful run:

Johan Kårlin · Post by **Johan Kårlin** » Tue Jun 14, 2022 6:37 am

Thanks! My starting point has been that the text layer is located att $0000 so this is most useful. ?

TomXP411 · Post by **TomXP411** » Tue Jun 14, 2022 7:51 am

On 6/13/2022 at 11:37 PM, Johan Kårlin said:

Thanks! My starting point has been that the text layer is located att $0000 so this is most useful. ?

Yes. That one was a surprise. The change was to allow for 320x240 bitmapped graphics, which uses more than 64K of RAM. So the text buffers were moved to bank 1, where they could live alongside the bitmap buffer. This means you can have text and bitmapped graphics on the screen at the same time (by enabling the second layer), and you can switch back and forth between text and graphic modes without losing text data or the bitmap data.

Since this could change again (although it probably won't), Michael made the suggestion to read the address from VERA. Hopefully that helps some other folks, and I'm hoping we see this behavior rolled into all the different compilers out there, when the compilers do direct screen access (ie: CONIO in C).