NUL chars in the text buffer should not be rendered at all, others will render with background and foreground colors instead of framebuffer content, without transparency.
Palette can be different from the framebuffer's one.
This does not need to use multiplane capability of scanvideo, unless it is easier or faster than "naive" rendering.
Text "cells" could be 2 to 4 bytes:
8 bits for char to display
4 or 8 bits for background color
4 or 8 bits for foreground color
4 or 8 bits for font (index) to use
Text mode could have these attributes:
(array of) font to use (TODO, only 8x8?)
lines as framebuffer pixel width / font width (or just 8?)
columns as framebuffer pixel height / font height (or just 8?)
cursor:
shape: horizontal line or block (and/or reverse block and/or vertical line?),
animation: off, fixed, flashing slowly or flashing quickly,
current line,
current column
This could be the base for a "dumb" terminal understanding a subset of ANSI/VT100 sequences.
CHiPs44
commented
8 months ago
NUL chars in the text buffer should not be rendered at all, others will render with background and foreground colors instead of framebuffer content, without transparency.
Palette can be different from the framebuffer's one.
This does not need to use multiplane capability of scanvideo, unless it is easier or faster than "naive" rendering.
Text "cells" could be 2 to 4 bytes:
Text mode could have these attributes:
This could be the base for a "dumb" terminal understanding a subset of ANSI/VT100 sequences.