5 ms·

It's x86, isn't it? I'd love to see something as small as this one that wouldn't rely as much on BIOS. The way I understand it, the following code is based one

by d33 7y ago

It's x86, isn't it? I'd love to see something as small as this one that wouldn't rely as much on BIOS. The way I understand it, the following code is based one of the assumptions you can't make without x86 BIOS, can you? /* video memory begins at address 0xb8000 */ char *vidptr = (char*)0xb8000;

jng 7y ago
That doesn't depend on BIOS, it depends on the standard "frame buffer" address for CGA/EGA/VGA graphics cards (I'm not 100% sure they all use the same address, those three and Hercules were the standard back in the day, and it seems my memory has started dropping nearly-useless information from 30 years ago, not a bad idea). I quote-unquote frame buffer because it's text mode, one byte for the ASCII code (extended to 256 characters in configurable and often confusing and incompatible ways, MS had "codepages" and ISO has the equivalent Latin-1 through Latin-14 or so), and one byte for the attribute. Many modern cards used to keep the basic VGA compatibility upon boot, until you switch them into more sophisticated modes. I'm not sure if they still do these days. QEMU, which is the actual target for the minimal demo kernel above, pretty sure supports it. BIOS used INT 10h for video operations, from mode setting to printing characters, code that calls INT 10h is actually relying on BIOS. IIRC next to nobody used it except for mode setting, you could much more easily and flexibly write the right bytes yourself (with a little bit more work for compatibility). Plus you could use DOS INT 21h to actually print output strings with a bit more of a concept of a terminal.
- d33 7y ago
  My bad then, thanks for clarifying. Anyway, would it still work on x86_64?
  - jng 7y ago
    Maybe emily-c knows the details. If the processor starts in real 16-bit mode these days like it used to do in the past (8086-compatible instruction decoding, flat mapping form virtual to physical memory, protected mode features mostly disabled, *16 segment registers, etc), there is no reason there should be a difference between 32-bit and 64-bit CPUs. But who knows, these things can get pretty hairy, and a lot of it is quite arbitrary, so you need to research the boot process of a modern x86_64 CPU.
    - emily-c 7y ago
      It is still possible but is BIOS dependent :) With UEFI, graphics is preferred to be done with the GOP driver/protocol (which will ultimately interact with video BIOS/graphics card option ROM for you). During early boot setting up the VGA decoding can either not be done or disabled when booting with UEFI. You might need your UEFI BIOS to be in CSM mode (legacy BIOS compatibility mode for UEFI) to get this to work and a lot of modern systems don't support CSM as of late. You can write to the framebuffer using GOP runtime services, and the VGA IO ports would likely do nothing since they wouldn't be decoded to the graphics card. Full fledged OSes just load a graphics driver and directly talk to the hardware -- something that is unfortunately not wieldy for hobby OSes :(
- emily-c 7y ago
  You're still relying pretty heavily on the BIOS to write to this region that you otherwise wouldn't be. Getting the legacy framebuffer region set up to be decoded to the graphics card is using some hacks to get it to work over PCI[e]. The memory controller/PCI root complex needs to be configured to forward transactions to the the legacy A and B segments to the PCI bus using a proprietary bit to enable that MMIO hole. To enable correct decoding of that, all PCI bridges on the path to the graphics device need to be specially marked in their config space bridge control as being "VGA compatible" so that legacy framebuffer hole requests and VGA IO ports can ultimately be forwarded to the graphics device. This needs to exist because the root ports/host bridges in the system base and limit need to encompass the addresses of their children as well as needing to exist in a hole that the memory controller/root complex knows to forward requests down to PCI.
  - jng 7y ago
    Thanks for the very complete explanation. It makes sense that this would work this way.

by d33 7y ago

jng 7y ago

That doesn't depend on BIOS, it depends on the standard "frame buffer" address for CGA/EGA/VGA graphics cards (I'm not 100% sure they all use the same address, those three and Hercules were the standard back in the day, and it seems my memory has started dropping nearly-useless information from 30 years ago, not a bad idea). I quote-unquote frame buffer because it's text mode, one byte for the ASCII code (extended to 256 characters in configurable and often confusing and incompatible ways, MS had "codepages" and ISO has the equivalent Latin-1 through Latin-14 or so), and one byte for the attribute. Many modern cards used to keep the basic VGA compatibility upon boot, until you switch them into more sophisticated modes. I'm not sure if they still do these days. QEMU, which is the actual target for the minimal demo kernel above, pretty sure supports it. BIOS used INT 10h for video operations, from mode setting to printing characters, code that calls INT 10h is actually relying on BIOS. IIRC next to nobody used it except for mode setting, you could much more easily and flexibly write the right bytes yourself (with a little bit more work for compatibility). Plus you could use DOS INT 21h to actually print output strings with a bit more of a concept of a terminal.

d33 7y ago
My bad then, thanks for clarifying. Anyway, would it still work on x86_64?
- jng 7y ago
  Maybe emily-c knows the details. If the processor starts in real 16-bit mode these days like it used to do in the past (8086-compatible instruction decoding, flat mapping form virtual to physical memory, protected mode features mostly disabled, *16 segment registers, etc), there is no reason there should be a difference between 32-bit and 64-bit CPUs. But who knows, these things can get pretty hairy, and a lot of it is quite arbitrary, so you need to research the boot process of a modern x86_64 CPU.
  - emily-c 7y ago
    It is still possible but is BIOS dependent :) With UEFI, graphics is preferred to be done with the GOP driver/protocol (which will ultimately interact with video BIOS/graphics card option ROM for you). During early boot setting up the VGA decoding can either not be done or disabled when booting with UEFI. You might need your UEFI BIOS to be in CSM mode (legacy BIOS compatibility mode for UEFI) to get this to work and a lot of modern systems don't support CSM as of late. You can write to the framebuffer using GOP runtime services, and the VGA IO ports would likely do nothing since they wouldn't be decoded to the graphics card. Full fledged OSes just load a graphics driver and directly talk to the hardware -- something that is unfortunately not wieldy for hobby OSes :(
emily-c 7y ago
You're still relying pretty heavily on the BIOS to write to this region that you otherwise wouldn't be. Getting the legacy framebuffer region set up to be decoded to the graphics card is using some hacks to get it to work over PCI[e]. The memory controller/PCI root complex needs to be configured to forward transactions to the the legacy A and B segments to the PCI bus using a proprietary bit to enable that MMIO hole. To enable correct decoding of that, all PCI bridges on the path to the graphics device need to be specially marked in their config space bridge control as being "VGA compatible" so that legacy framebuffer hole requests and VGA IO ports can ultimately be forwarded to the graphics device. This needs to exist because the root ports/host bridges in the system base and limit need to encompass the addresses of their children as well as needing to exist in a hole that the memory controller/root complex knows to forward requests down to PCI.
- jng 7y ago
  Thanks for the very complete explanation. It makes sense that this would work this way.