Writing to the screen without BIOS

[PavelChekov]

I meant a way to implement bitmap fonts without linking separate files.

[iansjack]

Well, you'd have to embed the data for your font in the source file. In this case you don't have to worry about file formats. The whole business of designing the font, defining the data, and writing it to the screen is up to you.

But it seems a lot of effort when so many well designed fonts already exist.

[PavelChekov]

That's a low-effort question which requires high-effort answers. How about you start with your own thoughts on the matter, lay out any problems that you can foresee and any possible solutions (even if not complete), outline what background reading you've already done, and ask more specific questions?

My problem is that I don't understand how the tutorial linked the PSF. As soon as I can load a ramdisk, I hope to use TTFs read from it.

Thanks

[nexos]

So imagine you have a file font.psf. You run the following:

Code: Select all

objcopy -O elf32-i386 font.psf font.o

adapted to your cross compiler and architecture, of course. Then, link font.o with the kernel. You will have symbols named _font_psf_start and _font_psf_end in your kernel binary to use the font.

[Octocontrabass]

As soon as I can load a ramdisk,

Doesn't your bootloader already load the RAMdisk?

I hope to use TTFs

Are you sure you want a whole TrueType renderer in your kernel?

[PavelChekov]

Doesn't your bootloader already load the RAMdisk?

I meant a root filesystem, not just an initrd.

Are you sure you want a whole TrueType renderer in your kernel?

I was using it as an example: I mean reading a font from my filesystem (probably /usr/share) instead of linking one, like ToaruOS.

[PavelChekov]

You will have symbols named _font_psf_start and _font_psf_end in your kernel binary to use the font.

Thats the part I don't understand: the symbols.

[Ethin]

Doesn't your bootloader already load the RAMdisk?

I meant a root filesystem, not just an initrd.

Are you sure you want a whole TrueType renderer in your kernel?

I was using it as an example: I mean reading a font from my filesystem (probably /usr/share) instead of linking one, like ToaruOS.

That's going to require a lot of work. UEFI will simplify it but if your not using UEFI you've made your life extremely difficult. If your loading the font from your boot loader you'll need to implement a minimal filesystem driver to be able to read files from the filesystem. If you want it loaded in your kernel, you'll have to bring up PCIe and use MMIO to set up, initialize, and read from the disks.

You can get away with something like Tarfs -- that's quite a minimal filesystem and easy to work with. And it would be good as a "bootstrap" filesystem. But either way, its going to require you to write quite a bit of code, particularly if the font isn't linked to your kernel.

[klange]

I was using it as an example: I mean reading a font from my filesystem (probably /usr/share) instead of linking one, like ToaruOS.

For my kernel (Misaka; just to be clear, ToaruOS had a different kernel up until May of this year, Misaka is a totally new thing), I embed a bitmap font, and I skip all of the silly tricks for "linking" a raw binary by encoding that font as a C source, so it ends up in my kernel binary like any other preinitialized object. It gets used by a framebuffer logging mechanism. The filesystem is not involved in this process.

(My bootloader does the same thing so it can draw text after modesetting)

You can get away with something like Tarfs -- that's quite a minimal filesystem and easy to work with. And it would be good as a "bootstrap" filesystem. But either way, its going to require you to write quite a bit of code, particularly if the font isn't linked to your kernel.

Yep! My current initrds are compressed tarballs, and my current boot process has just the initrd image as a multiboot/multiboot2 "module", so it's loaded by the bootloader alongside the kernel (I used to also load device drivers as modules, kinda like Hurd, but now the essential stuff is directly in my kernel and the less essential stuff is just a file on the ramdisk, loaded by the userspace startup scripts with an "insmod" syscall). Misaka has a rudimentary gzip decompression implementation so it can unpack the compressed image, provide it as ramdisk, mount the ramdisk directly with a read-only "tarfs", and then normally it gets migrated into a more flexible in-memory read-write tmpfs which is what the live CD uses from there.

[PavelChekov]

@klange I just presumed that was what these were for: https://github.com/klange/toaruos/tree/ ... ype/dejavu

[nexos]

The link you posted was for user space fonts. Nobody in there right mind would implement a TrueType renederer in kernel, trust me .

[klange]

@klange I just presumed that was what these were for: https://github.com/klange/toaruos/tree/ ... ype/dejavu

The "base" directory, as you probably guessed, is what becomes the ramdisk. Nothing in my kernel depends on things in the ramdisk, ergo the kernel does not use the TrueType fonts found therein.

TrueType is best kept as far away from your kernel as possible. Implementations of TrueType parsers have been a security plague for decades, notably pwning both the original Xbox and the iPhone.