Jump to content

Emulator r39 Released


Recommended Posts

On 4/2/2022 at 2:46 PM, desertfish said:

hey that's looking good!!

I wonder what the issue is with the mouse, in x16emu..

Me too. I've been looking into the code of the emu16 but it requires an explanation and a bit of a study before diving into it. It's not something you quickly can fix I guess without understanding the design and flow. 

Link to comment
Share on other sites

In r38 this code works just fine, just like it does in assembly, nothing fancy:

10 POKE $9F25,0
20 POKE $9F20,0:POKE $9F21,0:POKE $9F22,$20
30 FOR N=1 TO 80:POKE $9F23,N:NEXT N

In r39 however, this doesn't output anything. I'm using both the Linux and Windows versions, same issue. Am I missing something here?

Edited by Jeroen
Link to comment
Share on other sites

Yeah I had to change several routines in prog8's textio library to to add $b0.  But application code doesn't have to deal with this, and started working again after I changed the library.

Another way to deal with this is to use VTUI library which has just been updated as well for the new r39.

  • Like 1
Link to comment
Share on other sites

  • Administrators
On 4/2/2022 at 10:20 PM, desertfish said:

Yeah I had to change several routines in prog8's textio library to to add $b0.  But application code doesn't have to deal with this, and started working again after I changed the library.

Another way to deal with this is to use VTUI library which has just been updated as well for the new r39.

You could read the start of screen RAM from the VERA registers and be compatible with any start address! 🙂

  • Like 4
Link to comment
Share on other sites

On 4/3/2022 at 12:52 AM, Michael Steil said:

You could read the start of screen RAM from the VERA registers and be compatible with any start address! 🙂

Could BSOUT/CHROUT writing to screen have the same approach in the ROM and have somewhere a register that indicates to which layer it writes?

Would a pull request be an option to consider?

Link to comment
Share on other sites

On 4/3/2022 at 4:41 AM, svenvandevelde said:

Could BSOUT/CHROUT writing to screen have the same approach in the ROM and have somewhere a register that indicates to which layer it writes?

Would a pull request be an option to consider?

Rather than overloading output routines, it might be better to have a new Vera settings retrieval call.

  • Like 1
Link to comment
Share on other sites

I am sorry, I may have missed something, but as far as I know it is hardcoded that kernal routines use layer 1. What would be the benefit of having it say so in a register or memory location?

If you want kernal routines to work with something different than defaults, you should modify layer 1 registers, call kernal routines, then reset layer1 registers if needed.

Link to comment
Share on other sites

BSOUT allows echoing the output to the terminal. If the rom is not flexible to reposition its map base and layer for character (and bitmap) output, thus, focusing on basic or default level only, then rom is of less use for assembler coders. Conio type of routines are constructed to do the same, but faster and more flexible, as they write directly to vera memory. This however takes memory space in the ram ... and this approach cannot get echoing output working to the terminal (I think, maybe there is another trick).

This is the background of the request. Now that the R39 rom has already mapped the map base to $1B000 and layer 1, an improvement was done comparing with release R38, but still...

Just reflecting my thoughts.

Edited by svenvandevelde
Link to comment
Share on other sites

  • 2 weeks later...

SCREEN has a new, undocumented side effect in R39: it also changes background color to blue and foreground color to white. This didn't happen before in e.g. R38. R39 behavior breaks compatibility with many of my R38 programs, but I can fix that. I still think it would be better if the colors were preserved as before, because then you can test different screen modes without having to change the colors.

SCREEN 6 (20x15) works for me in my game Aritm (see Downloads) in R39 to make a more children friendly font, but "Try it now" is still R38.

I could make a version that works in both R38 an R39, by using SCREEN $FF (toggle), but if you RUN it several times it toggles instead of always setting it to 40x30 as it should. When "Try it now" becomes R39 I will probably change it again to SCREEN 3 or SCREEN 6.

  • Like 2
Link to comment
Share on other sites

  • 4 weeks later...
On 3/30/2022 at 12:18 AM, TomXP411 said:

The text frame buffer is now $1:B000

If your C programs use direct access, rather than KERNAL printing, then you need to modify the library code to use the new address. This will definitely have to be updated in cc65 and Kick C

 

The source for cputc says:

Quote

screen_addr := $1B000 ; VRAM address of text screen

https://github.com/cc65/cc65/blob/master/libsrc/cx16/cputc.s

 

That LOOKS right, but clearly something's wrong.

Link to comment
Share on other sites

  • Super Administrators
On 5/16/2022 at 6:35 AM, rje said:

To wit: my brain is wrong.  This change was made since my last build of cc65.

I just have to update.  Duh.

I was going to suggest that, but I thought "Oh, I'm sure he already did that..."  

🤣

  • Haha 1
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