Issues with the mouse

[vruumllc]

Hi, I'm trying to the mouse to control the cursor a simple text mode (mode1) editor that uses both the keyboard and the mouse to move the cursor. I'm using canvas mode3 (640X480), but I think the issues will still happen in 320x240.

Problem 1: If I move the cursor with mouse, then keyboard, then mouse, the cursor jumps back to original mouse position. I need a way to set mouse position to the current cursor position set with keyboard.

I tried writing to the mouse RIA registers like this:
RIA.addr0 = MOUSE_INPUT + 1;
RIA.step0 = 0;
RIA.rw0 = cur_col * 8;
RIA.addr0 = MOUSE_INPUT + 2;
RIA.step0 = 0;
RIA.rw0 = cur_row * 16;

Problem 2: This doesn't work, however, because the x and y mouse position registers are only a byte, 255 max, and the current position on the screen can exceed that in both X and Y.

In the paint program you used static int sx, sy to accumulate small delta movements, which is why it worked there, but I can't go backwards that way.

Any suggestions?

Thanks, tonyvr

[vruumllc]

Stupid web page...The first sentence should read:

Hi, I'm trying to write a simple text mode (mode1) editor that uses both the keyboard and the mouse to move a text mode cursor.

[rumbledethumps]

Writing to the mouse registers should be considered undefined behavior.

For even a trivial use case of the mouse, you'll have to implement a small driver that works like the paint program. Accumulate the small char movements and apply their delta to your cursor position. Perhaps keep your cursor position as a fixed point 8.8 so you can slow down the mouse as necessary.

This works like a Commodore 64 mouse. Maybe you can get some ideas looking at what C64 programmers do.

[vruumllc]

I just checked, and it turns out I misremembered how Norton Commander worked anyway. It used a text mode red block as the mouse, and blinking underscore attribute as the cursor, so there were indeed two separate positions to keep track of. You had to click the mouse to reset the text mode cursor position, just as we do today.

[vruumllc]

As for the way the paint mouse code works, I understand that. (or at least I thought I did). It just seems like the x and y variables can roll over and you can get an incorrect delta computed from your last saved value. I'll think about it some more.

[rumbledethumps]

The USB protocol is 8 bit and prone to the same rollover. The faster you poll, the faster the user can move the mouse. Most mice these days report 250Hz and higher, which a 6502 application polling >= 250Hz can take advantage of. There isn't a way to give the 6502 more data or faster reports.
In practice, 60Hz will rollover on mouse movements that were impossibly fast on "ball" mice. It's fine, but more is better.

[rumbledethumps]

Oh, and if you're wondering why the RIA doesn't track and report in 16 bits for slower polls, it's because there's no way to atomically transfer more than 8 bits. Unironically, the same problems we had to code around back in the day are still here.

The vsync example shows how to do interrupts on vsync, which you can write a mouse driver in. If it's not fast enough for you, use a 6522 timer to make a faster interrupt.

[vruumllc]

Interesting stuff. Thanks for your time.
I have been using your code from paint, and it does seem to work fine. I always like to think about the the edge cases, though. It's fun!