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

[tkchia]

The bare metal VGA console code can now (tkchia@02ecb1e) 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.

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

[jart]

Thanks for sending this! Approved.

[jart]

Oh cool I didn't know about this.

[jart]

Cool fallthrough overflow pattern!

[tkchia]

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

[jart]

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

[ghaerr]

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]

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]

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!