OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:12 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Designing BIOS and DOS Portable for UEFI-only machines
PostPosted: Sun Nov 26, 2017 11:24 am 
Offline
Member
Member
User avatar

Joined: Tue Mar 06, 2007 11:17 am
Posts: 1225
I've been thinking in the possibility of UEFI-only machines given another topic around here that stated the plan of manufacturing UEFI-only, BIOS-less machines by 2020.

I think that BIOS PCs (UEFI working on top of BIOS) will always exist to keep using old compatible software like important versions of Linux, Windows, etc., and to provide easy access to the hardware.

But I've been thinking that with an UEFI-only machine, we could build an OS image that instead of loading an OS, could build the BIOS areas and go back to Real Mode from 32 or 64-bit UEFI, and from there, we could treat it as a standard BIOS-equipped machine.

If that wasn't possible for any reason, we could design a "BIOS Portable" project, that could be compiled for 16, 32 or 64-bit, and also a "DOS Portable" based on FreeDOS. With that combination, we could have a BIOS-equipped system with a BIOS call structure such that it could be used portably across modes.

By that time (2020), we could make that our BIOS/DOS versions use native drivers from their original driver CDs/media. In this way we could internally use native network, graphics, sound, TV and other drivers whenever we find nonstandard hardware, as is the case currently.

We could leave the machine in a fully predictable and simple state before leaving UEFI and passing control to our software.

It could be that UEFI-only machines could cause the modernization of the known structure and set of BIOS and DOS calls to fully native 32 and 64-bit modes. The intention as always would be to allow simple full access to the hardware with a small system as is BIOS/DOS. With that simplicity and by being able to use native drivers, we will be able to keep using BIOS/DOS as a backwards compatible platform, and since it will be relatively simple in its base, it will allow us to keep learning the actual details of the machine easily and with a known standard way, and also use DOS as a very capable standard loader for our OSes.

It seems to me that if UEFI-only machines arise as the common rule for part or all of future PCs, it will only make the known standards of the PC reach a stability milestone. Current BIOS/DOS-based standards will no longer change, would no longer move, and that would allow us to study them without fear of them changing. They will reach maturity, and that will give a definitive reference of what and how to reimplement a BIOS32/BIOS64 that we would load from UEFI for it to take full control.

With that, DOS could become a part of our BIOS32/BIOS64 portable system software design, started in a known state for all peripherals, and from there we would be free to load native drivers from the console, and we would have a very standard PC. It will probably end up taking us much nearer to the effort of making our own PCs from scratch, from the motherboard, but it looks that logically such is the task of operating system development. If we want PCs standard the way we need and like, we will need to make them ourselves at some point.

_________________
Live PC 1: Image Live PC 2: Image

YouTube:
http://youtube.com/@AltComp126/streams
http://youtube.com/@proyectos/streams

http://master.dl.sourceforge.net/projec ... 7z?viasf=1


Top
 Profile  
 
 Post subject: Re: Designing BIOS and DOS Portable for UEFI-only machines
PostPosted: Sun Nov 26, 2017 7:48 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

Idea #1 (providing a "100% compatible BIOS" on top of UEFI for legacy software)

~ wrote:
But I've been thinking that with an UEFI-only machine, we could build an OS image that instead of loading an OS, could build the BIOS areas and go back to Real Mode from 32 or 64-bit UEFI, and from there, we could treat it as a standard BIOS-equipped machine.


They won't just be changing the firmware to "UEFI only"; they'll also be ripping out lots of legacy hardware - things that have been superseded but kept around in some form for compatibility with old software designed for BIOS. This includes PIC chips (replaced by APICs), PIT chips (replaced by HPET), PS/2 controller (replaced by USB), legacy ATA modes in disk controllers, all "real mode" ROMs (mostly used by SCSI controllers and network cards), and VGA (the IO ports in the card itself, the hacks for IO port forwarding in PCI bridges, etc).

To emulate the BIOS in a useful way you'd have to be able to emulate all the "likely removed soon" legacy hardware too; and to do that you'd have to implement a full hyper-visor (and could just use an existing one instead).

Note: If it's just to make a few boot loaders work (e.g. by providing a few BIOS services/interrupts without emulating any of the raw hardware) then it'd be easier and better to replace the boot loaders with UEFI boot loaders. I don't include this in "emulate the BIOS in a useful way".

~ wrote:
If that wasn't possible for any reason, we could design a "BIOS Portable" project, that could be compiled for 16, 32 or 64-bit, and also a "DOS Portable" based on FreeDOS. With that combination, we could have a BIOS-equipped system with a BIOS call structure such that it could be used portably across modes.


With a huge amount of work you could provide something that nobody has wanted for decades (a 100% "BIOS and DOS compatible" platform) because of how badly it sucked.

~ wrote:
By that time (2020), we could make that our BIOS/DOS versions use native drivers from their original driver CDs/media. In this way we could internally use native network, graphics, sound, TV and other drivers whenever we find nonstandard hardware, as is the case currently.


In theory you might be able to use native DOS drivers; but in practice hardware manufacturers stopped providing DOS drivers many years ago and you can't execute something that never existed.


Idea #2 (providing a completely new and different "not compatible with BIOS but based on BIOS" API)

~ wrote:
By that time (2020), we could make that our BIOS/DOS versions use native drivers from their original driver CDs/media. In this way we could internally use native network, graphics, sound, TV and other drivers whenever we find nonstandard hardware, as is the case currently.

We could leave the machine in a fully predictable and simple state before leaving UEFI and passing control to our software.

It could be that UEFI-only machines could cause the modernization of the known structure and set of BIOS and DOS calls to fully native 32 and 64-bit modes. The intention as always would be to allow simple full access to the hardware with a small system as is BIOS/DOS. With that simplicity and by being able to use native drivers, we will be able to keep using BIOS/DOS as a backwards compatible platform, and since it will be relatively simple in its base, it will allow us to keep learning the actual details of the machine easily and with a known standard way, and also use DOS as a very capable standard loader for our OSes.

It seems to me that if UEFI-only machines arise as the common rule for part or all of future PCs, it will only make the known standards of the PC reach a stability milestone. Current BIOS/DOS-based standards will no longer change, would no longer move, and that would allow us to study them without fear of them changing. They will reach maturity, and that will give a definitive reference of what and how to reimplement a BIOS32/BIOS64 that we would load from UEFI for it to take full control.

With that, DOS could become a part of our BIOS32/BIOS64 portable system software design, started in a known state for all peripherals, and from there we would be free to load native drivers from the console, and we would have a very standard PC.


Why would you bother creating a new "32 bit and 64 bit boot API" that isn't compatible with any existing software when you could just use UEFI instead?

Don't forget that it's impossible to design an API that is simple enough to use as a "standard boot environment/API" (e.g. where it's normal to only allow one thing to happen at a time) but complex enough to be useful after an OS has started (e.g. where only allowing one thing to happen at a time is completely unacceptable).


Idea #3 (making it "easy" for people to create their own PC compatible hardware)

~ wrote:
It will probably end up taking us much nearer to the effort of making our own PCs from scratch, from the motherboard, but it looks that logically such is the task of operating system development. If we want PCs standard the way we need and like, we will need to make them ourselves at some point.


If you collected all of the drugs in the entire world and consumed all of them at once; it still wouldn't be enough to make the idea of creating your own PC compatible hardware seem plausible. 8)


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Designing BIOS and DOS Portable for UEFI-only machines
PostPosted: Mon Nov 27, 2017 3:22 am 
Offline
Member
Member

Joined: Tue May 13, 2014 3:02 am
Posts: 280
Location: Private, UK
Surely the easiest/most compatible way to have a "BIOS/DOS" environment in a UEFI-only PC would be to have a minimal "real OS" running DOS in a BIOS-enabled Virtual Machine?

Such a VM could have passthrough access to PCI devices (especially those fitted with Option ROMs which would be otherwise unused) and (near) direct access to storage devices. That should provide anything you "need" DOS for.

_________________
Image


Top
 Profile  
 
 Post subject: Re: Designing BIOS and DOS Portable for UEFI-only machines
PostPosted: Mon Nov 27, 2017 4:45 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Or you could just buy an old PC for next to nothing.

In other news, I'm working on a Windows 10 driver for mercury delay line memory modules.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], SemrushBot [Bot] and 64 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group