Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cursor behaviour #63

Open
ivop opened this issue Aug 24, 2023 · 3 comments
Open

Cursor behaviour #63

ivop opened this issue Aug 24, 2023 · 3 comments

Comments

@ivop
Copy link
Contributor

ivop commented Aug 24, 2023

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
Copy link
Owner

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
Copy link
Contributor Author

ivop commented Aug 25, 2023

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
Copy link
Owner

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants