Jump to content

Emulator r39 Released


Recommended Posts

On 3/30/2022 at 8:23 PM, Michael Steil said:

$FF6B

Typo, you are correct, i meant to write $FF6B

image.png.d3a6b84c60f6c0c96d849dea596e77b2.png

 

So this code seems to be correct.

This is the API call fragment:

image.png.774968d8b1de52ca20e656a0180cca83.png

However, the zero pages $22, $23, $24, $25 stay 0, regardless if I move the mouse or not.

I"m sequently calling this CX16_MOUSE_GET continuously.

I've attached a demo prg with source code in asm.

cx16-mouse.prgcx16-mouse.ccx16-mouse.asm

Link to comment
Share on other sites

There's been a change in the mouse_config() API  https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#function-name-mouse_config

However I think there's also a bug.   Setting X and Y both to zero seem to reduce the 'screen size' to 0 by 0 blocks instead of keeping the 'current' resolution as the documentation now says.

I find that if you set them to 80 and 60 respectively, or perhaps follow the code snippet given in the docs, the mouse moves again.

 

Also there is a small error in the documentation, it still says "Communication registers: .A, .X" , this should be   "Communication registers: .A, .X, .Y" now.

  • Thanks 1
Link to comment
Share on other sites

  • Administrators
On 3/31/2022 at 12:07 AM, desertfish said:

There's been a change in the mouse_config() API  https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#function-name-mouse_config

However I think there's also a bug.   Setting X and Y both to zero seem to reduce the 'screen size' to 0 by 0 blocks instead of keeping the 'current' resolution as the documentation now says.

I find that if you set them to 80 and 60 respectively, or perhaps follow the code snippet given in the docs, the mouse moves again.

0 does keep the current size config. It's just that if you never called mouse_config before, the current config is 0x0, which it will keep.

@svenvandevelde, you need to call mouse_config, like in the example in the docs.

 

  • Thanks 1
Link to comment
Share on other sites

  • Administrators
On 3/31/2022 at 12:07 AM, desertfish said:

Also there is a small error in the documentation, it still says "Communication registers: .A, .X" , this should be   "Communication registers: .A, .X, .Y" now.

Pull request, please? 🙂

  • Like 2
  • Haha 1
Link to comment
Share on other sites

that being said, i think there is an issue with the mouse handler ... This routine worked flawlessly on the R38.

I'm in the middle of an interrupt service routine where i execute the following code:

image.png.facd2f2db8c59fdc6d8d117d70c921c5.png

The registers $22 till $25 should contain the mouse x and y coordinates after the cx16_mouse_get call.
But they stay 0.

Some additional notes: I've been debugging and found that the memory locations A026 and beyond are not updated when walking the $FF6B API code flow, using the emulator debugger.
So in the API code, these memory locations are read, and then there is an sta ($00),x which is storing these contents in the zeropage $00 indexed by x, which has value $22 at the time of this execution. Bank RAM register $00 is zero, so it is reading from $00:A026, $00:A027, $00:$A028, $00:$A029 and writing into $22, $23, $24, $25. All values read and written are zero.
I guess this is because it seems that the mouse pointer cannot be moved. The graphics mode that is active at time of execution on the VERA is on layer 0 a tile mode, 16x16, 64x64 tile map. On layer 1 a tile (character) mode, 8x8 tiles, 64x64 tile map.


Could it be that the revised mouse configuration and coordinate limit system has a bug?

 

I've attached my SDCARD where the game prototype is installed.

CX16.zip

Can you please try to find what is the problem?
- Run x16emu attaching this CX16.vhd.
- Load in the emulator equinoxe-flightengine.prg.
- run the program

You'll first the diagnostics when loading the sprites and tiles.
Put a couple of key presses and the scrolling should start, but the mouse is not moving.
The player plane is 'for the moment' attached to the mouse position.

 

Edited by svenvandevelde
Link to comment
Share on other sites

I think I found the root cause and it seems that file handling APIs are conflicting ...

It seems that file IO is making the mouse freeze ... I could resimulate the problem in a simple program ... I've added the asm sources as you will check in assembler finally, but my main source is C, which i will explain.
The assembler outputs are fully c code annotated.

Let me first explain what is done ...

image.thumb.png.b2116ff4229dca05a7bb9c340259b09b.png

This program sets the mouse pointer, and opens the FILE for reading at channel 1 from the disk (secondary address is 0 for load).
File is on the disk, embedded in the sdcard attached. The file contains the text SVEN, which is displayed as the file will read 4 characters and display them.
Then normally, the file should be closed, right?

Well, that seems to be causing the mouse freezing issue.

In the below working version i am not closing the file, and the mouse works (with the loop displaying the addresses 22 till 25).

CX16-working.zipPLS TRY by unzipping cx16-mouse-working.zip, running cx16-mouse.prg from the sdcard image cx16.vhd sdcard.

 

Now the not working version, I've uncommented line 34, which closes the file ...

image.thumb.png.e3ea1cc04b3e6b4815e0b1493afefe81.png

CX16-problem.zipPLS TRY by unzipping cx16-mouse-problem.zip, running cx16-mouse.prg from the sdcard image cx16.vhd sdcard.

Now, you will see the file will be loaded, closed and all looks ok, but the mouse is NOT working!

Can somebody please check the ROM for any bugs or at least confirm this error using my program or trying this at home yourself?

I cannot use R39 like this until the root cause has been found.

I've added the sources in assembly language, and included a symbol file:


cx16-mouse - working.asm

cx16-mouse - working.vs

cx16-mouse - working.c

 cx16-mouse - problem.asm

cx16-mouse - problem.vs

cx16-mouse - problem.c

 

Note that the ASM output is not using optimizing compilation settings to improve assembler readability.

Sven

 

 

Edited by svenvandevelde
Link to comment
Share on other sites

On 3/31/2022 at 10:29 AM, svenvandevelde said:

I think I found the root cause and it seems that file handling APIs are conflicting ...

What a great discover/isolation of the issue you are encountering. I assume that those who wrote the ROM code will be able to track the issue given this great description and provided code.

Perhaps the community needs a couple of volunteers to get issues from the forum into the correct issue database - https://github.com/commanderx16/x16-rom/issues

Link to comment
Share on other sites

You should call cbm_k_clrchn() before you call cbm_k_close().

It's the opposite of when you started to use the file:

  1. OPEN the file,
  2. connect to the file.

When you're finished, you must:

  1. disconnect from the file,
  2. close the file.
  • Thanks 1
Link to comment
Share on other sites

  • Super Administrators
On 3/31/2022 at 11:26 AM, Edmond D said:

Perhaps the community needs a couple of volunteers to get issues from the forum into the correct issue database - https://github.com/commanderx16/x16-rom/issues

I think people can handle their own bug reports, but I suggest coming here for support first, to make sure the problem is actually the ROM or emulator, rather than a mistake on the user's part. 

What might help is a note on where to find the various issue trackers. Maybe a pinned post or header message with the URLs to the repositories. I'll look into that.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

On 3/31/2022 at 8:30 PM, Greg King said:

You should call cbm_k_clrchn() before you call cbm_k_close().

It's the opposite of when you started to use the file:

  1. OPEN the file,
  2. connect to the file.

When you're finished, you must:

  1. disconnect from the file,
  2. close the file.

Is it? That might also be a root cause. Don't know. I'll wil try this tomorrow and let you know. But if somebody using another platform could try to resimulate it? This might help to confirm the issue? This would eliminate the possibility that there is something wrong with the c code libraries which I'm using. 

Link to comment
Share on other sites

On 3/31/2022 at 8:36 PM, TomXP411 said:

but I suggest coming here for support first, to make sure the problem is actually the ROM or emulator, rather than a mistake on the user's part.

Indeed. So if someone could check if this problem can be resimulated using their own compiler or pure using assembly? So it can be confirmed or root cause can be found?

Link to comment
Share on other sites

I'd like to try your test program but the sdcard image acts weird, I can't load the file off of it. It is in petscii symbols (uppercase) and I can't load it it keeps saying file not found. Can you post just the PRGs zipped here perhaps as well instead of on an sdcard image?

Link to comment
Share on other sites

  • Super Administrators
On 3/31/2022 at 3:33 PM, desertfish said:

I'd like to try your test program but the sdcard image acts weird, I can't load the file off of it. It is in petscii symbols (uppercase) and I can't load it it keeps saying file not found. Can you post just the PRGs zipped here perhaps as well instead of on an sdcard image?

It's an upper-lower case thing. Just mount the file in Windows and invert the case, making the filename all (I think) upper case.

Link to comment
Share on other sites

On 3/31/2022 at 6:33 PM, desertfish said:

I'd like to try your test program but the sdcard image acts weird, I can't load the file off of it. It is in petscii symbols (uppercase) and I can't load it it keeps saying file not found. Can you post just the PRGs zipped here perhaps as well instead of on an sdcard image?

Type a control-n.  Then, load the file with lower-case letters:
load"cx16*"

  • Thanks 1
Link to comment
Share on other sites

On 4/1/2022 at 12:33 AM, desertfish said:

I'd like to try your test program but the sdcard image acts weird, I can't load the file off of it. It is in petscii symbols (uppercase) and I can't load it it keeps saying file not found. Can you post just the PRGs zipped here perhaps as well instead of on an sdcard image?

Of course, please find attached. Thank you for trying it out:

cx16-mouse - problem.prg

cx16-mouse - working.prg

FILE

 

Link to comment
Share on other sites

On 4/1/2022 at 5:42 AM, TomXP411 said:

It's an upper-lower case thing. Just mount the file in Windows and invert the case, making the filename all (I think) upper case.

Correct. In the above post I've attached the prg files and the input file for trying.
You can modify and compile using kick assembler the assembler files i attached in the above post.
For example, change the file name and then recompile ...

In parallel i'm also testing further and today i'm checking the ROM code as well ...

Edited by svenvandevelde
Link to comment
Share on other sites

On 3/31/2022 at 8:30 PM, Greg King said:

You should call cbm_k_clrchn() before you call cbm_k_close().

It's the opposite of when you started to use the file:

  1. OPEN the file,
  2. connect to the file.

When you're finished, you must:

  1. disconnect from the file,
  2. close the file.

This does not seem to help. Made a video demonstrating the issue.

Also the API CLRCHN is to clear all channels. I believe the CLRCHN is to refocus on the keyboard input and to clear all channels.
Should not influence the CLOSE call. But that is a discussion that already happened earlier in this forum.

Please have a look in the video, it demonstrates the problem.
This issue also occurs in my game, where i did identify the issue by eliminating all logic gradually
until i got the mouse pointer working, and then gradually i reapplied parts of the logic until i found the
exact routines that were causing the issue (i did multiple recompiles, as you can imagine :-)-.

 

Edited by svenvandevelde
Link to comment
Share on other sites

Could even further narrow the issue ... Just opening a file and closing a file result in the issue without any reading of characters done.

cx16-mouse - open close.prg

cx16-mouse - open close.asm

cx16-mouse - open only.prg

cx16-mouse - open only.asm

FILE

I'm going to leave it at this stage not to over pollute the forum here ... There is now sufficient information to have a look at the ROM code or emulator code (don't know), to see where the problem is.

Please try out the PRGs. I've made a very verbose explanation in the code ...
Also attached the relevant C code routines so you can see the logic on a higher level.

cx16-mouse - open close.c

cx16-mouse - open only.c

Would be interested @Michael Steil what is your take on this. I've been looking at the commit history of the R39 and I
don't think the issue is due to the mouse logic itself. I think the issue is related to a combination of dos or file io updates and screen mode updates.
I've also noticed a couple of vectors being updated ... Could it be that registers are incorrectly overwritten?

Note that in this resimulation is not doing much actually, just opening a file and closing and measuring mouse IO.
The screen writing is natively on the VERA, there are no CHROUT API calls done.

Sven

Edited by svenvandevelde
Link to comment
Share on other sites

On 4/1/2022 at 8:12 PM, desertfish said:

@svenvandevelde  with the "cx16-mouse open close.prg"  program, I could reproduce the problem. However, I think it's an emulator issue ;  the problem only occurs when using x16emu. Using box16 to run the same program, the issue does NOT occur.

 

now THAT is an amazing finding. Kudos @desertfish for this!
So I need to remake the ROM and plug it into the box16. Let me try that ...

On top, please find an interesting discussion here:
Match mouse position in emulator window with host position · Issue #376 · commanderx16/x16-emulator (github.com)

Edited by svenvandevelde
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