OSDev.org

Yo!

I just got back from Alton Towers, twas fun, apart from the rain .

Anyways, I just wanted to know what bit you guys are making your OS in. 16-bit or 32-bit?

Im making mine in 16-bit for now.

~Touch

Alton Towers, that where you pay alot of money to wait in big ques .
As for 16 or 32 or even 64bits now.
My main OS is 32bit, but i coded a 16bit just for fun, alot easier with the help of BIOS .

Yeah, well me and my mate went for the BOGOFF offer!

Yeah, BIOS is useful. We might be using 32-bit in the future, but not for now.

Touch wrote:Yeah, well me and my mate went for the BOGOFF offer!

I hope you mean Buy One Get One Free

I am doing mine in 32bit. im more comfortable that way.

If you ask me, 16-bit is way to restricted to be used for a practical OS anymore, especially with the nasty kludge that is real mode segmentation on x86. I mean, really, who's brilliant idea was it to use 32 bits to represent a 20-bit address space, giving each memory location 16 distinct addresses?!?!?

I wouldn't say my OS is 32-bit, because it isn't really intended to be specific to an address width. As long as there is paging, and a reasonable amount of memory can be allocated, I expect that it should be portable amongst 32-, 64-, 128-, ...3453-bit systems.

Edit:

Besides, the tools available for >=32-bit work are a lot better.

Hi,

Touch wrote:Anyways, I just wanted to know what bit you guys are making your OS in. 16-bit or 32-bit?

Mine is being done for 32-bit and 64-bit, where the 64-bit micro-kernel can run 32-bit processes (including device drivers, etc).

16-bit is practically useless, partly because real mode segmentation is painful, partly because all of the BIOS functions are slow, lack functionality and are completely useless for multi-tasking, partly because the BIOS is obsolete (I expect it'll be replaced with EFI in the next 5 years), and partly because I think an OS should control access to the hardware (rather than having an OS where the BIOS is the kernel, and the kernel is a wrapper around the BIOS).


Cheers,

Brendan

What I want to know is, if they get rid of the BIOS, can we finally stick two fingers up at backwards compatibility and say goodbye to other anachronisms like having to enable the A20 line (I mean, I know it's easy to do, but why should I still have to do it 15 years after computers only wanted to address 1MB of RAM?)

Sorry - got up in a 'ranting mood' today

Adam

@Dex: Yes, the BOGOFF offer XD
@ AJ: LOL

Well, for now 16-bit is good for me, its learning etc. Maybe it will later be ported to others.

~Touch

AJ wrote:What I want to know is, if they get rid of the BIOS, can we finally stick two fingers up at backwards compatibility and say goodbye to other anachronisms like having to enable the A20 line (I mean, I know it's easy to do, but why should I still have to do it 15 years after computers only wanted to address 1MB of RAM?)

They will never get rid of the BIOS, its too intergated in to the x86 design, some big CO would like to.

Its ironic that one of the reasons, they give for geting rid of it, is they can not find enough ASM programmers, Put your hand up if your a ASM programmer and want a good paid job working on x86 BIOS

Hi,

Dex wrote:

AJ wrote:What I want to know is, if they get rid of the BIOS, can we finally stick two fingers up at backwards compatibility and say goodbye to other anachronisms like having to enable the A20 line (I mean, I know it's easy to do, but why should I still have to do it 15 years after computers only wanted to address 1MB of RAM?)

They will never get rid of the BIOS, its too intergated in to the x86 design, some big CO would like to.

Apple already got rid of the legacy BIOS, there's versions of Linux for EFI (and a "Linux BIOS" project to replace the BIOS with the Linux kernel), and I've heard rumours of a version of Windows designed to use EFI on 80x86 (which shouldn't be a big surprise considering they had a version of Windows for Itanium, where EFI is the only option). Also, I'd guess that at least half of the people here use GRUB, and start their kernel in protected mode without ever touching the BIOS.

For large companies (Microsoft), the legacy BIOS is an advantage - they have the finances to deal with the mess, and it makes things a little harder for their less well funded competition. Apple probably don't want others to use EFI as it makes it easier for "white box" manufacturers to sell "Apple compatible" hardware. Intel probably do want everyone to shift to EFI because that would help getting OS's, etc ported to Itanium.

Part of the rest of the "non-80x86" industry have been using OpenFirmware for a while now. It's a similar idea to EFI, and to be honest I'd prefer to see OpenFirmware on 80x86 and Itanium as this would make it easier to write platform independant OS code (but I'd assume both Intel and Microsoft would prefer EFI).

The 80x86 is probably the only architecture where the OS can't use BIOS code. The BIOS itself should have been extended with 32-bit versions of its functions around 20 years ago, and 64-bit versions of BIOS functions should be being introduced now. This didn't happen and won't be happening - they've left it too late, and the only sane course of action now is a completely new BIOS (with optional legacy support).

For me, I just want the entire industry to stand still for several years (so I've got a chance to catch up).

Dex wrote:Its ironic that one of the reasons, they give for geting rid of it, is they can not find enough ASM programmers, Put your hand up if your a ASM programmer and want a good paid job working on x86 BIOS

I've tried writing BIOS code before (for the Bochs project). Trying to get each function to behave correctly (while also updating the right flags, etc in the BDA) is a complete pain in the neck. Even finding a complete list of specifications or a detailed description of exactly what each function does is difficult.

Modern BIOSs are normally implemented in layers, where things like the disk access, PIT, CMOS, PCI, etc rarely changes. Most of the new work would be adapting existing code to new chipsets, and dealing with power management issues (including ACPI compatability).


Cheers,

Brendan

But the Intel macs and problably some other new computers have that new BIOS thing, right?
Can't remember the name now.. :S

EDIT: Yeah, I meant EFI. Brendan was a bit quicker..

Put your hand up if your a ASM programmer and want a good paid job working on x86 BIOS

*Hand shoots up!*

M$ are too stupid to see that there are people like us, probably better, like Linux, who will one day take down the M$ industry. I mean, Apple Macintosh, they are quite popular nowadays. BIOS is being removed by some companies like Brendan said.

Brendan wrote:I've heard rumours of a version of Windows designed to use EFI on 80x86

From what I know it was originally planned to include EFI support in Vista. Microsoft however decided to removed the feature as there are currently not enough computers that support the new standard. Probably one of the service packs will add EFI support to the system..

Dex wrote:Its ironic that one of the reasons, they give for geting rid of it, is they can not find enough ASM programmers, put your hand up if your a ASM programmer and want a good paid job working on x86 BIOS

The last real assembler hacker in his hopeless crusade agains a changing world

regards,
gaf

Dex wrote:Its ironic that one of the reasons, they give for geting rid of it, is they can not find enough ASM programmers, put your hand up if your a ASM programmer and want a good paid job working on x86 BIOS

The last real assembler hacker in his hopeless crusade agains a changing world
regards,
gaf

I think if i am not mistaken, that EFI was originally created for Intel's IA-64 architecture, i think that AMD with there AMD64 new that you can not get rid of legacy.
And even M$ is learning http://apcmag.com/apc/v3.nsf/0/E666E4A0 ... 2C008166C4
Watch and learn gaf