davidgiven / cpm65

CP/M for the 6502
BSD 2-Clause "Simplified" License
266 stars 23 forks source link

Cursor behaviour #63

Open ivop opened 1 year ago

ivop commented 1 year ago

Hi,

Glancing over the new Oric port, I noticed that you only draw a cursor during screen_getchar. Is that intended behaviour? If so, I could greatly simplify and reduce the code in the Atari port (and future 80 columns driver).

Regards, Ivo

davidgiven commented 1 year ago

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.

ivop commented 1 year ago

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?

davidgiven commented 1 year ago

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!