31 ms·
Problem is that x86 segmentation support is lacking, which is important for things like the BIOS.
by yuhong 8y ago
Problem is that x86 segmentation support is lacking, which is important for things like the BIOS.
- geofft 8y agoFor certain ways of writing the BIOS - you can have the BIOS immediately enter 32/64-bit flat addressing mode (as if you were a 32/64-bit kernel) and then drop back to 16-bit mode when you're done if you need to do a legacy MBR boot. I think this is how coreboot/libreboot/linuxboot/etc. and Tianocore/EDK2 work. Can you use Tianocore as your BIOS for VirtualBox the way that you can use it (in the form of OVMF) for qemu? How is SeaBIOS built?
- yuhong 8y agoAnd even writing some 16-bit code using gcc is not impossible too. The problem is that it lacks support for things like near and far pointers.
- WalterBright 8y agoWithout near and far pointers, it is hopeless to write non-trivial programs for 16 bit DOS.
- yuhong 8y agoAnd even for things like BIOS they can be useful, and that is what I am most interested in.
- geofft 8y agoSure. My argument is that unless you're interested in retrocomputing (which is a cool field, but not the field VirtualBox is in) you shouldn't be writing non-trivial 16-bit programs at all any more - VirtualBox doesn't even support emulating any 16-bit-only CPUs. You should be writing 32-bit programs with a tiny bit of 16-bit code on each end (either in assembly or in trivial C) to switch from 16-bit to 32-bit mode and back. Since you only need the BIOS for a very small amount of time to support a bootloader loading itself, the slowness of switching modes at each interrupt will hardly be your limiting factor (especially given that you're in a VM). This has the advantage that you don't need any new compiler to build your program, neither OpenWatcom or Digital Mars. (Nothing against the Digital Mars compiler! I just think that it isn't the right engineering direction for VirtualBox to depend on retrocomputing.)
- yuhong 8y agoThough it is worth mention that the runtime code that implements BIOS services (INT 10h, 11h, 12h, 13h, etc...) for the most part can't switch to protected mode without breaking compatibility.
- pgeorgi 8y agoSeaBIOS is doing a reasonable job at that
- yuhong 8y agobut there is also the VGA BIOS.
- geofft 8y agoDo you even need a VGA BIOS in an emulator? It's an emulator - just write to segment B800 or wherever and have the host-side process just watch that page of memory. Again, qemu works fine without a retrocomputing compiler. Is VirtualBox doing something that prevents it from taking whatever approach qemu uses? (qemu even has the cool thing where "-curses" will cause it to copy segment B800 as text to your host-side terminal emulator and avoid rendering graphics at all.)
- yuhong 8y agoWhat I am talking about is things like this: https://mail.coreboot.org/pipermail/seabios/2015-April/009028.html https://mail.coreboot.org/pipermail/seabios/2015-April/00902...
- cesarb 8y agoYou're in an emulator - you don't have to switch to protected mode within the emulation, you can instead exit the VM and do the work outside the emulation. The caller within the emulation won't notice unless it's trying to single-step the BIOS code (and why would they do that?). Edit: unless the code within the emulator is trying to run the BIOS within an emulator of its own. Turtles all the way down...