drivers

[[e-mail]]

I had a discussion on the osdev discord server about
drivers, and I basically agreed with their philosophy that
ARM64 had it right in that there is no BIOS and the only
thing you can rely on the firmware to do is put your OS
into memory. You are required to provide your own
drivers for everything else.

But that this philosophy couldn't be done in 1981 because
every byte counted and it was better to put drivers into
ROM if possible.

But I don't care about saving 4k worth of RAM. PDOS is
already more than 100k.

So I'm now thinking that PDOS should have drivers. Even
for outputting text.

But what I was thinking is that I could have a version of
the drivers that simply calls the BIOS (stepping down to
RM16).

And if I separate things out like this, I can have a version
of the drivers that calls my own C-like BIOS when run
under Windows. ie a BIOS that supports
bios->fopen("0x80", "r+b");

And I can have a version that does UEFI calls (stepping
up to LM64).

As well as one that directly manipulates hardware.

And I should be able to have a version that when opening
COM1 instead opens a bluetooth device. I might need to
use Linux format drivers or something so that people can
choose to use those, even though they're not public domain.

Another thing I am interested in doing is supporting morse
code as described here:

https://stackoverflow.com/questions/118984/how-can-you-program-if-youre-blind

BFN. Paul.

[Scott Lurndal]

Post by ***@gmail.com
I had a discussion on the osdev discord server about
drivers, and I basically agreed with their philosophy that
ARM64 had it right in that there is no BIOS and the only
thing you can rely on the firmware to do is put your OS
into memory. You are required to provide your own
drivers for everything else.

The same philosophy was used by SPARC, PA-RISC, Power,
MIPS, 68k, 88100 et alia since the 1980's. x86 was
the outlier with the BIOS providing the I/O capabilities
for DOS.