Jump to content

Moving to R39


Edmond D
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

  • Super Administrators
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.)
image.png.618a791419ddbbe91a3eeead2907cc19.png

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:
image.png.a2f02e41deeca759c43c435e1977766d.png

And a successful run:
image.png.8a770edab2b8b4328d90bc946984d041.png

  • Like 1
Link to comment
Share on other sites

  • Super Administrators
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). 

 

  • Like 1
Link to comment
Share on other sites

On 6/13/2022 at 10:18 PM, TomXP411 said:

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.

ASL instead of ROL!

  • Like 1
Link to comment
Share on other sites

  • Super Administrators
On 6/14/2022 at 3:27 AM, Greg King said:

ASL instead of ROL!

Yes, that would save one byte and 2 CPU cycles. Since ASL always shifts 0 into the low bit, I don't actually need the CLC first. Next time I need to do this, I'll probably use the ASL and save the extra byte. 

That's some of the fun about Assembly language: being able to sift through routines to save one or two bytes on a routine that's 18 bytes long. That one change is more than a 5% decrease in size and execution time... imagine if software engineers took that kind of care writing modern applications and operating systems.

In fact, now that I think about it, I could make this even smaller by removing the branch and rotating the Carry bit directly into $502. Let me see what that does...

... and here's the new routine:
STZ $0500
LDA $9F35
ASL
STA $0501
LDA #$08   ; Increment value. This gets shifted left to $1x in the next step.
ROL
STA $0502
BRK

This saves 7 bytes, although it's slightly less readable.

Also, it fixes a bug in the first example. I was setting the increment byte differently based on which bank the result landed in. This would have created unexpected behavior on R41 systems, assuming I was expecting an increment of 1.

In this case, note that I pre-load A with $08 before rotating in the Carry bit. Since we actually want the final result to set the increment to 1 (so $10 or $11), I pre-loaded the value with the increment one to the right of where I expect it to land. I could have also accomplished this with 

LDA #0
ROL
ORA #$10
STA $0502

But, as you can see, this adds 2 extra bytes. However, this approach is more readable, and it might be preferable in a situation where speed isn't as much of a concern. At the very least, I'd add a comment so the next person knows what I'm doing. 

So here are the test results:

Test on R41: I expect 00 B0 11
.:0500 00 B0 11 00 00 00 00 00

This is correct. R41 sets the Map base to $1:B000

Test on R38: I expect 00 00 10

.:0500 00 00 10 00 00 00 00 00

 

 

  • Like 2
Link to comment
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.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use