Jump to content
  • 0

Current cursor physical line number R38


Justin Baldock
 Share

Question

Hi,

When using basic v2 on R38 ROM. I want to check what is the current cursor line number. On the C64 I can peek at $D6 and it returns the current line the cursor is on. When I try this on the X16 I get the value 8 back... no matter where the cursor is.

I've had a look at the repo and found,

x16-rom/kernal/cbm/editor.s, which appears to have, "tblx    .res 1           ;$D6"

Checking to find where tblx is explained I found

kernal/open-roms/screen/e566.cursor_home.s, which appears to explain it as the cursor_home, current row.

So $00D6 should be returning what I am looking for, my question is, am I misunderstanding or have I found a bug? (I'm leaning towards not understanding)

Edited by Justin Baldock
Updated for release ver.
Link to comment
Share on other sites

8 answers to this question

Recommended Posts

  • 0
On 11/15/2021 at 11:51 PM, Scott Robison said:

I *think* that is problematic since BASIC is in a different ROM bank than the kernal. Maybe there are stubs in BASIC rom to forward to the real kernal calls, though.

The Kernal jump tables are recreated in the BASIC ROM, so it's not an issue. It will automatically bank switch for you. Like the C64, you can access the CPU registers and flags through RAM when doing SYS calls:

A: $030C

X: $030D

Y: $030E

S (Flags): $030F

Carry is bit 0 of S, so you want to set that to have PLOT ($FFF0) return the position rather than set it. Then, after the call, the X register (ironically) will have the row, and Y will have the column.

image.png.fbed887cbae6fc24641db27991927399.png

  • Like 2
Link to comment
Share on other sites

  • 0

X16 Kernal is set up to use a lot less Zeropage memory than C64 Kernal and BASIC did. A lot of stuff is actually done in RAM bank 0 now. As JimmyDansbo points out, the .sym files are the easiest way to find where things actually live in memory. (I.e. where they finally got linked to during the build)

It's generally considered "risky" to use such locations in projects right now, as future builds of Kernal may place them in different locations. Certain well-known things like the RAM-vased IRQ/NMI/BRK vectors are highly unlikely to change, and the official API addresses are considered "written in stone" so those are fine to use as well, but if you go wandering around in RAM bank 0 to find the current Mouse X/Y locations, for instance, then assume these will break with each new Kernal build. That's one reason cc65 has functions that won't work properly in R39 - they do this and are thus tied to R38. (e.g. waitvsync() and cgetc(), kbhit() are all broken in R39)

  • Like 1
Link to comment
Share on other sites

  • 0
On 11/16/2021 at 5:30 AM, kelli217 said:

You could try using the KERNAL routine for plotting the cursor position.

Yes, that is also possible however it requires that you set the carry flag before calling it to get it to return the actual coordinates.

Something like this one-liner should work

Quote

POKE 783,1:SYS $FFF0:PRINT PEEK(781)

Address 780-783 are the CPU registers and flags just as the Commodore 64, see https://www.c64-wiki.com/wiki/SYS

$FFF0 is the kernal PLOT routine, see https://cx16.dk/c64-kernal-routines/plot.html

You do not have to switch ROM as the BASIC ROM does indeed have stubs to forward calls to the Kernal ROM just as @Scott Robison mentioned.

Above line will of course use more CPU cycles than a simple peek of a memory address, but you should be fairly certain that the addresses do not change.

  • Like 3
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
Answer this question...

×   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