Cursor behaviour about cpm65 HOT 3 OPEN

Kinda intended? It's because there's no interrupt system, which means the cursor has to be drawn manually; undrawing it and drawing it for every character is surprisingly slow, so it only gets drawn when the system is waiting for user input.

It's not ideal as it makes the cursor vanish when the system is busy, but it is at least simple.

from cpm65.

I see. The Atari port has every operation encapsulated between hide_cursor and show_cursor. It's a lot faster than the original Atari OS console E: device, but could be sped up by doing the same as you do with the Oric port. It's mostly the calculate cursor address routine that gets called twice. Showing the cursor is only a matter of flipping bit 7 of the character. But in the 80 columns driver the whole glyph has to be inverted (6 bytes).

Another option is to draw the cursor with Player Missile Graphics (Atari's term for sprites), but that'll cost me 1kB of kilobyte aligned memory which is bit much for just a cursor.

I actually like it that the cursor is invisible during multiple screen operations without user input, as you won't see the cursor flashing around the screen, so I'm considering removing a lot of code and mimic the Oric driver in its cursor behaviour. Would that be ok?

from cpm65.

Go for it --- you know the Atari code a lot better than me...

For platforms with character mapped displays, caching the cursor address should make undrawing the cursor cheap. But drawing it does require the address calculation code, which is too expensive to call on every character. (There's a lot of overhead between the application and screen_putchar as is.) If you have a timer, one thing which could be done is that every character undraws the cursor, and then resets the timer. If, say, a tenth of a second passes without another character being drawn, the interrupt handler redraws it.

But a lot of the CP/M-65 platforms run with interrupts off for simplicity!

from cpm65.