Commander X16

On 3/31/2022 at 12:44 AM, Michael Steil said:

Pull request, please? ?

done



Documentation additions/recommendations. Please review and adopt where it is correct/useful. by FlightControl-User · Pull Request #73 · commanderx16/x16-docs (github.com)

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:



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.

 

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 ...



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 ...



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

 

 

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

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.
   

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.

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. 

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?

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?

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.