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

[metal] Add basic character output for VGA graphics mode console #649

Merged
merged 3 commits into from
Oct 5, 2022
Merged

[metal] Add basic character output for VGA graphics mode console #649

merged 3 commits into from
Oct 5, 2022

Conversation

tkchia
Copy link
Contributor

@tkchia tkchia commented Oct 4, 2022

The bare metal VGA console code can now (https://github.com/tkchia/cosmopolitan/commit/02ecb1ecea1ccf8bfed450d988092702f2efb5ad) do some basic text output onto a VGA graphics screen, with the help of glyphs from a public domain bitmap font. Scrolling also works properly.
20221004-3

To do:

  • implement some sort of "screen of death", to allow easier diagnosing of program crashes when they happen
  • allow switching to a different font — possibly with a different glyph size — even after console has already been initialized
  • support TrueType fonts, or at least some sort of graymap fonts
  • maybe add a visible software cursor
  • speed up bitblt operations with the help of SIMD instructions
    • also make sure bitblt works properly, SIMD or no, under "screen of death" conditions

Copy link
Owner

@jart jart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for sending this! Approved.

#if !defined(__STRICT_ANSI__) && \
((__GNUC__ + 0) * 100 + (__GNUC_MINOR__ + 0) >= 407 || \
__has_attribute(__optimize__))
#define unrollloops __attribute__((__optimize__("unroll-loops")))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh cool I didn't know about this.

uint8_t bits = *bitmap++;
switch (xleft) {
default:
*plotter++ = __builtin_add_overflow(bits, bits, &bits) ? fg : bg;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool fallthrough overflow pattern!

Copy link
Contributor Author

@tkchia tkchia Oct 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jart : I suspect that is about as optimized as one can go without bringing in SIMD instructions. :) Thank you!

},
[1] = { /* 33 */
0x00, /* ........ */
0x18, /* ...##... */
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this has a nice retro aesthetic that'll help us make progress until we can have truetype.

@jart jart merged commit edb8fef into jart:master Oct 5, 2022
@ghaerr
Copy link
Contributor

ghaerr commented Oct 5, 2022

Hello @tkchia, very nice work implementing the graphical VGA console. I'm quite impressed with your optimizations.

I notice that a 24bpp RGB/BGR mode isn't (yet) implemented - is VESA VBE not returning any of these modes?

Thank you!

@tkchia
Copy link
Contributor Author

tkchia commented Oct 6, 2022

Hello @ghaerr,

I notice that a 24bpp RGB/BGR mode isn't (yet) implemented - is VESA VBE not returning any of these modes?

I recall that my (actual) PC did in fact return some 24bpp modes, including modes 0x118 (1024 × 768 × 64K colours) and 0x112 (640 × 480 × 64K colours) etc. Do you think it will be useful to support these modes? I imagine that it will be a bit difficult to deal with them in an optimized manner...

Thank you!

@ghaerr
Copy link
Contributor

ghaerr commented Oct 7, 2022

Hello @tkchia,

I recall that my (actual) PC did in fact return some 24bpp modes, including modes 0x118 (1024 × 768 × 64K colours) and 0x112 (640 × 480 × 64K colours)

Those modes are 16bpp (=64K)... I was referring to 24bpp modes, which are 16M colors, but stored as 24 rather than 32 bits per pixel.

Do you think it will be useful to support these modes?

I think most modern cards supporting 24bpp would also support 32bpp RGBA/BGRA pixel format, perhaps take a further look to see whether the 24bpp formats have higher resolutions available for display?

I imagine that it will be a bit difficult to deal with them in an optimized manner...

Yes, of course the 24bpp format doesn't allow aliasing as short or long integers, but the preparation of such blitters would still be useful for 1) getting ready for having to deal with a separate alpha channel that may require byte moves to/from the framebuffer, and 2) @jart's request for considering an RGB (uint8[3][x]y) API/storage pixel format for the offscreen buffer.

Thank you!

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

Successfully merging this pull request may close these issues.

3 participants