From the PDF:
"It is true: in our quest to make full use of the CPU, we must abandon all of those helpful routines provided by BIOS. As we will see when we look in more detail at the 32-bit protected mode switch-over, BIOS routines, having been coded to work only in 16-bit real mode, are no longer valid in 32-bit protected mode; indeed, attempting to use them would likely crash the machine.
"So what this means is that a 32-bit operating system must provide its own drivers for all hardware of the machine (e.g. the keybaord, screen, disk drives, mouse, etc). Actually, it is possible for a 32-bit protected mode operating system to switch temporarily back into 16-bit mode whereupon it may utilise BIOS, but this teachnique can be more trouble than it is worth, especially in terms of performance."
--
In the toy 32-bit OS I am currently writing, having easy disk access and text output was more important to me than performance, so I decided to implement this technique to access the disk and screen via the BIOS instead of writing an ATA disk driver.
Although I could not find any minimal yet complete working examples of dropping to 16 bit and later resuming 32 bit mode, I was able to piece it together and write assembly functions called enter_16bit_real and resume_32bit_mode. See https://github.com/ironmeld/builder-hex0/blob/main/builder-h.... Those routines are working well but beware the project is a volatile work in progress and is coded in hex for bootstrapping reasons.
Windows 3.1, 95, 98, Me all did exactly the thing described as "more trouble than it is worth"; they are 32-bit protected mode operating systems[0] that makes frequent context switches to 16-bit mode and utilize BIOS functions.
[0] Yes, I know, Windows 3.1 applications were almost always 16-bit unless you installed Win32S. It's somewhat complicated.
I guess in their case they had so much already written code to work with BIOS calls it was worth adding the shim layer. But if you were to start tomorrow with no legacy code then it would be more trouble than it's worth.
If you are running your OS on a VM hypervisor (e.g.; Qemu, kvmtool), then you can just use virtio for disk and network I/O. No boring and complex device specification (e.g.; ATA) to implement.
Yeah, I'm avoiding modern interfaces due to my peculiar bootstrapping requirements (e.g. must run on old HW; no SW dependencies). virtio is probably a better choice for anyone trying to build something practical. On the other hand, it looks like using virtio would need a lot more code than accessing the BIOS and I couldn't easily find examples in assembly.
"So what this means is that a 32-bit operating system must provide its own drivers for all hardware of the machine (e.g. the keybaord, screen, disk drives, mouse, etc). Actually, it is possible for a 32-bit protected mode operating system to switch temporarily back into 16-bit mode whereupon it may utilise BIOS, but this teachnique can be more trouble than it is worth, especially in terms of performance."
--
In the toy 32-bit OS I am currently writing, having easy disk access and text output was more important to me than performance, so I decided to implement this technique to access the disk and screen via the BIOS instead of writing an ATA disk driver.
Although I could not find any minimal yet complete working examples of dropping to 16 bit and later resuming 32 bit mode, I was able to piece it together and write assembly functions called enter_16bit_real and resume_32bit_mode. See https://github.com/ironmeld/builder-hex0/blob/main/builder-h.... Those routines are working well but beware the project is a volatile work in progress and is coded in hex for bootstrapping reasons.