flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Goodbye to BIOS? [split off TetrOS thread]

Author
Thread Post new topic Reply to topic
DimonSoft



Joined: 03 Mar 2010
Posts: 774
Location: Belarus
DimonSoft
Mike Gonta wrote:
Tomasz Grysztar wrote:
While preparing to organize a 512-byte coding contest for the 20th anniversary of fasm, ...
It seems quite fitting (in an historical context) that such a contest (that is dependent on the BIOS)* coincides with Intel saying "Bye to BIOS" by 2020.

Didn’t they try to say “Bye to BIOS” ten years ago? And even before then?
Post 04 Nov 2019, 20:50
View user's profile Send private message Visit poster's website Reply with quote
Mike Gonta



Joined: 26 Dec 2010
Posts: 238
Location: the-ideom
Mike Gonta
DimonSoft wrote:
Mike Gonta wrote:
Tomasz Grysztar wrote:
While preparing to organize a 512-byte coding contest for the 20th anniversary of fasm, ...
It seems quite fitting (in an historical context) that such a contest (that is dependent on the BIOS)* coincides with Intel saying "Bye to BIOS" by 2020.

Didn’t they try to say “Bye to BIOS” ten years ago? And even before then?
The original technical implementation of The BIOS has been gone for quite a while now and replaced with the UEFI Compatibility Support Module.
It's the UEFI CSM that is going to disappear next year and as such the real mode BIOS and all such things (VGA, 0xB800, the related I/O ports, etc.) including
real mode will go with it.
Take away the BIOS and CSM requirement and it might open the door to also removing these legacy processor modes.
There have been rumors that a future Intel x86 processor would scale back some of its legacy support; a pure 32- and 64-bit processor that dropped 16-bit
compatibility would fit neatly with the plans to remove the last vestiges of the BIOS from UEFI.

Of course, we still have emulation.
Oscar Wilde could have wrote:
Emulation is the sincerest form of flattery that mediocrity can pay to greatness.

It was fun* while it lasted, (some say for too long).


*UEFI is simply no fun whatsoever.

_________________
Mike Gonta
the-ideom - now you know how to compile

https://mikegonta.com
Post 04 Nov 2019, 21:50
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 774
Location: Belarus
DimonSoft
UEFI is simply not mature enough yet. Many implementations still have very stupid bugs compared to differences in BIOS implementations.
Post 05 Nov 2019, 09:21
View user's profile Send private message Visit poster's website Reply with quote
Mike Gonta



Joined: 26 Dec 2010
Posts: 238
Location: the-ideom
Mike Gonta
DimonSoft wrote:
UEFI is simply not mature enough yet. Many implementations still have very stupid bugs compared to differences in BIOS implementations.
Maybe stupid bugs in the UEFI CSM as compared to the stupid bugs in the real mode BIOS firmware but what has that to do with UEFI without the CSM.

_________________
Mike Gonta
the-ideom - now you know how to compile

https://mikegonta.com
Post 05 Nov 2019, 09:56
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 774
Location: Belarus
DimonSoft
Mike Gonta wrote:
DimonSoft wrote:
UEFI is simply not mature enough yet. Many implementations still have very stupid bugs compared to differences in BIOS implementations.
Maybe stupid bugs in the UEFI CSM as compared to the stupid bugs in the real mode BIOS firmware but what has that to do with UEFI without the CSM.

I wish it was about CSM. For example, Graphics Output Protocol had a few problems in relatively new notebook models (a few years ago).

Another thing to discuss is whether the design choices like calling convention used in 64-bit UEFI were good ones. Reusing compiler-oriented calling convention might have seemed to be a good idea but why not reusing ART bytecode then? Gives even more bloat with less effort.

Probably the only good idea is to support loading arbitrarily-sized bootloaders. Used to be the most lacking feature since at least 8086. But… oh, wait, FAT? Why prefer some particular file systems? This decision might look quite stupid 30–40 years later. Why on earth a bootloader should be a normal file? From reliability point of view. Just make it a separate volume and let the OS author decide. You have GPT? That’s OK, just give us better volume-oriented disk API than BIOS did (anything is better than nothing), that would be just enough. Why add features that are to be deprecated in the future?
Post 05 Nov 2019, 12:34
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 200
Fulgurance
Hello, i have read this post, and i have question.

If next laptop have UEFI only, what is the future for system based into 16bits start mode coded into assembly ? Intel force all people to use PE to start all UEFI based system now ? Confused
Post 02 Apr 2020, 10:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17469
Location: In your JS exploiting you and your system
revolution
Fulgurance wrote:
Hello, i have read this post, and i have question.

If next laptop have UEFI only, what is the future for system based into 16bits start mode coded into assembly ? Intel force all people to use PE to start all UEFI based system now ? Confused
Yes. AIUI UEFI demands a FAT formatted partition, and a PE formatted initial boot loader. It might also demand a signed boot loader, that only MS can sign.

So choose your laptops with care if you intend to run a different OS from the one the maker puts on.
Post 02 Apr 2020, 15:16
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 200
Fulgurance
... It's very horrible ... bye to custom file system... Mandatory to use minimal fat system... pff

In futur, processor start into 32 bits mode ? Bye to 16 bits mode ? But how processor start ? With mandatory GDT ???
Post 02 Apr 2020, 15:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17469
Location: In your JS exploiting you and your system
revolution
IIRC VIA once made a CPU that had no 16-bit mode, only 32-bit.

It could happen soon. AMD and Intel might remove support for 16-bit.

So make good use of it now while you can.. And cry when it disappears.
Post 02 Apr 2020, 15:40
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 200
Fulgurance
It's only me i think when this come it's the end of the true programming ? I'm afraid in future assembly dissapear...
I think it's getting out of hand

And wait ??? But if 16bits dissapear, how use graphic mode into proprietary graphic card when you would like to build our driver without specification ???
Post 02 Apr 2020, 16:46
View user's profile Send private message Reply with quote
N-LG



Joined: 14 Feb 2019
Posts: 37
Location: france
N-LG
with UEFI, there is a new protocol called GOP (graphique Output Protocol) to control the graphics card, I haven't tried it yet but it doesn't seem very complicated to use
Post 02 Apr 2020, 17:27
View user's profile Send private message Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
There are plenty of old morherboards to choose from, i just got nos dell gx270 cg566 for $20usd, it has 845 chipset, 4gb ram, 800mhz bus, pentium 4 cpu (testing 3.2ghz) these old mb's will be around for good long time...

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.
Post 02 Apr 2020, 17:28
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7751
Location: Kraków, Poland
Tomasz Grysztar
Even if future generations of CPUs drop legacy modes and boot directly into the long mode (which would make most sense in my opinion, modern OSes do not use legacy modes anyway, for 32 bits there is a compatibility sub-mode of the long mode) it would in no way prevent you from writing in assembly. In many ways long mode is actually more comfortable to handle than the legacy modes.

You can use fasm to develop for UEFI (or even write EBC code instead of x86).
Post 02 Apr 2020, 17:48
View user's profile Send private message Visit poster's website Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 200
Fulgurance
There are any documentation about this new processor ? There any virtual machine and assembly to test and code for this new motherboard ?
Post 02 Apr 2020, 19:59
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 454
Location: Czech republic, Slovak republic
Feryno
16 bit realmode is still necessary:

multiprocessor systems - every application CPU starts in 16 bit realmode, abandoning this mode would require an update of APIC and IPI

wakeup from ACPI sleep - already prepared to resume CPU in protected mode but every current CPU still uses resume from S3 sleep in 16 bit realmode

so I expect 16 bit realmode will be still present for at least few years
Post 05 Apr 2020, 20:33
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 200
Fulgurance
It's so sad there is no way to use MBR and UEFI ... Confused I detest to use existing file system...
Post 08 Apr 2020, 10:38
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 774
Location: Belarus
DimonSoft
Why not? There’s a place for legacy MBR in GPT. Noone prevents you from making a disk that is both MBR and GPT. Except for the lack of tools to do so and the need to keep in mind the limitation differences of both schemes. And the need to keep both MBR and GPT info about partitions consistent (or not, if you wish to have some cool configuration).
Post 08 Apr 2020, 12:09
View user's profile Send private message Visit poster's website Reply with quote
Ali.Z



Joined: 08 Jan 2018
Posts: 360
Ali.Z
so sad to hear, maybe its better to backup our hardware.

but removing bios means removing realmode, but i dont want them to remove protected mode.

seems in a way or other they will force us to write the ugly 64bit assembly, plus 64bit processor is not really 64bit its still limited and cant address the full 64bit memory. basically like a game released in early access mode.

secure boot + signing that means they will force some ppl to specific OSes ... yea and maybe even buy new processor. just like the game game published by miceosoft and intel INTEL 7TH GEN IS NOT SUPPORTED ON WINDOWS 7 what a stupid deal.

new era of conspiracy, f*** them i wish all of their new designs burn.

_________________
Asm For Wise Humans
Post 08 Apr 2020, 20:58
View user's profile Send private message Reply with quote
guignol



Joined: 06 Dec 2008
Posts: 724
guignol
The mistake was introducing 3D gaming back in the 90s.

And SoC is the next near step of every personal computing.
though probably a separate chip on communications
Post 10 Apr 2020, 02:24
View user's profile Send private message Reply with quote
Fulgurance



Joined: 27 Nov 2017
Posts: 200
Fulgurance
Sorry guys,but i have other questions. I have looked into UEFI documentation for GOP Graphics output protocol, but how can i access to it ? It's not into EFI SYSTEM TABLE...
Post 10 Apr 2020, 11:10
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
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 vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.