Becky on Nostr: So, the driver is almost the same thing as ‘raw’ mode for a TTY, I think. Just so ...
So, the driver is almost the same thing as ‘raw’ mode for a TTY, I think.
Just so we’re on the same page, when you say ‘cursor positioning’, what exactly are you thinking? If you mean providing a gotoxy() routine, then yeah, I think that’s good for the driver. On the other hand, if you mean advancing the cursor after printing a character, then I think we should probably wrap that in with the ANSI code.
I think the driver should be there to handle the ugly stuff like:<li>set/get a character or color attribute from the text buffer.</li><li>scroll the text buffer (whether or not the buffer size matches the visible screen)</li><li>own the irqHandler that rebuilds Vera’s copy of the text.</li><li>(possibly) provide a sprite based cursor and a routine to position it / turn it on or off.</li><li>provide a kprint(x, y, message) type of routine that can fling a string at the screen for debugging purposes.</li>
(1/2)
Just so we’re on the same page, when you say ‘cursor positioning’, what exactly are you thinking? If you mean providing a gotoxy() routine, then yeah, I think that’s good for the driver. On the other hand, if you mean advancing the cursor after printing a character, then I think we should probably wrap that in with the ANSI code.
I think the driver should be there to handle the ugly stuff like:<li>set/get a character or color attribute from the text buffer.</li><li>scroll the text buffer (whether or not the buffer size matches the visible screen)</li><li>own the irqHandler that rebuilds Vera’s copy of the text.</li><li>(possibly) provide a sprite based cursor and a routine to position it / turn it on or off.</li><li>provide a kprint(x, y, message) type of routine that can fling a string at the screen for debugging purposes.</li>
(1/2)