October 13, 2026 at 5:12 PM, "Michael Kelly" <[email protected] mailto:[email protected]?to=%22Michael%20Kelly%22%20%3Cmike%40weatherwax.co.uk%3E > wrote:
> > On 10/10/2026 20:28, Samuel Thibault wrote: > > > > > Hello, > > > > Michael Kelly, le sam. 10 oct. 2026 01:18:44 +0100, a ecrit: > > > > > > > > 3) My biggest worry was how to get a font loaded into the kernel. I think > > > that the multiboot module can do that and all that is needed is to strip > > > out > > > a special 'boot_font' module from the list as they are translated from > > > multiboot2 to multiboot. No need to worry about file system access or > > > embedding a font in the kernel itself. The font could be unloaded after > > > boot > > > when the user console takes over. > > > > > Embedding a basic font in the kernel looks fine enough to me. It can be > > e.g. 8-byte per character, covering only ascii, that's just 1KB of data. > > > I have a working prototype with an embedded font of size 8x14 which adds an > array of 1344 bytes if the characters 32-128 have bitmaps and characters > outside this range show as '?'. It's obviously even smaller with 8x8 but it > didn't look too good although it was perfectly readable. I'm now starting to > progress it to something that can be merged. Perhaps this is an unhelpful tip, but maybe it'll help... I personally am a fan of OpenBSD's spleen font. Again, maybe it's not helpful... https://github.com/fcambus/spleen > 1) bmpput and friends aren't in use. Can I just replace them or instead add > (for example) rgb32_put ? I haven't worked out what kind of framebuffer the > old code was intended for and it certainly needs alteration for a 32 bpp one > provided by the boot loader. > > 2) Similarly, do I need to maintain the font format that the code currently > expects? This is a sequence of character-set width scanlines. The simple font > definition that I've copied from the Seabios Qemu code is in a different > format. I can convert that if necessary so it's not a problem really. > > 3) Which of the different frame buffer encodings that are possible with > multiboot do I need to support? I suggest just the likely case of RGB and > 32bpp for the moment. > > Cheers, > > Mike. >
