Re: [OpenBIOS] Why protected mode?

[Timothy J. Massey]

On Thu, 15 Jul 1999 17:47:57 -0400 (EDT), Kevin P Lawton wrote:
> Well, it would have been a much different situation making
> a move between 8086 and 286 and doing it right from the
> beginning, than ramming all that IA32 stuff into a
> new VLIW architecture.   Woof.

Two things:  1) I see your point.  2) I don't want to offend anyone else by
continuing this increasingly off-topic thread!  :)

You win...  ;)  Besides, I never liked the 286 anyway!  :)

Tim Massey



-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

Why protected mode?

Oops sorry, that got off topic. :^)

-Kevin
-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

Why protected mode?

[Matthias Wächter]

On Thu, 15 Jul 1999, Timothy J. Massey wrote:
> Two things:  1) I see your point.  2) I don't want to offend anyone else by
> continuing this increasingly off-topic thread!  :)

about (1): Fine.

About (2): I don't agree. I think, the BIOS and the BIOS programmers play
a large role in the non-evolution of system startup but also of operating
system design. It's time for everyone involved, especially the BIOS
programmers, especially ones who want to do something "new", to discuss
the mistakes from the past, and these mistakes have a lot to do with the
processor "changes" and the way the BIOS changed with it... well, it
didn't. Currently we have the same BIOS interface as the 8086 (except
for the INT16 Bios extensions which are not used by some OSes, sadly,
Linux too in opposition to NT and Win98).

Sehr Wus,
- Matthias

-- 
Bunt ist das Dasein und granatenstark. Und: Volle Kanne, Hoschis!
                         aus: "Bill und Teds verrückte Reise durch die Zeit"
-----------------------------------------------------------------------------

-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

Why protected mode?

[Niklas Ekström]

On Fri, 16 Jul 1999, Matthias Wächter wrote:
> About (2): I don't agree. I think, the BIOS and the BIOS programmers play
> a large role in the non-evolution of system startup but also of operating
> system design. It's time for everyone involved, especially the BIOS
> programmers, especially ones who want to do something "new", to discuss
> the mistakes from the past, and these mistakes have a lot to do with the
> processor "changes" and the way the BIOS changed with it... well, it
> didn't.

I don't think BIOS designers are to blame for the incredibly stupid
hardware constructions of the IBM-PC compatible computers. I don't even
think you can blame the Intel engineer for that, since they did what they
had to do to keep their customers. Mostly it's all IBM's fault! ;)

So really there isn't much to discuss. If you want to make your BIOS
IBM-PC compatible, you will end up with the same stuff as always before,
but if you are ready to let the compability go you can do something much
better.

/ Niklas

-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

Why protected mode?

[James Oakley]

Niklas Ekström wrote:
> I don't think BIOS designers are to blame for the incredibly stupid
> hardware constructions of the IBM-PC compatible computers. I don't even
> think you can blame the Intel engineer for that, since they did what they
> had to do to keep their customers. Mostly it's all IBM's fault! ;)

I blame everybody, including customers :-)* The architecture should have
been better designed in the beginning, but nobody knew better, the
customers were reliant on the old technology. the only way is to ease
people out of it. Linux would be *much* more popular if it ran
everybody's crappy win32 apps, even though many UNIX apps are way better
(GIMP, TeX, etc).
> So really there isn't much to discuss. If you want to make your BIOS
> IBM-PC compatible, you will end up with the same stuff as always before,
> but if you are ready to let the compability go you can do something much
> better.

Not quite. Look at the Linux kernel, which managed to ease people into
radically new formats, a.out->ELF. It wasn't perfect, but it worked. I
don't know anybody with a.out binaries.

I think OpenBIOS should be configurable in the same way, and I'm
obviously not the only one. You could have an 'old-BIOS' configuration,
while developing a fancy new OpenBIOS way that eliminates limitations
and is designed to be easily 'upgradeable.' If it's there, the Linux
kernel guys could do a similar thing, allowing 'old-BIOS' or OpenBIOS
loading. Those who run certain other OSes could stick with old-BIOS
while those of us with Linux-only machines could test and use the new
format. Maybe something could be put in to allow the kernel to find out
which kind of BIOS is loading it and adjust itself accordingly.

James Oakley
[e-mail]
-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message

Why protected mode?

[Ed Brinker]

That's getting close to the truth.  Bill Gates made 40 gigadollars last
year which means that a lot of PC's are running with M$ software.  I don't
think that anyone wants to throw away that kind of money and go to a new
platform which may not have the kind of support they need for several years.

So with all of us not wanting to spend more money we find ways to use the
old stuff on our new PC's.

And as for where this all started, IMHO it started long before there was
any 8086's or 8088's.  Much of the structure of the BIOS and DOS has it's
beginnings in CP/M 1.4 for the 8080.

And as for the architecture of the x86, IMHO that comes from the 4040
through the 8080 to the 8086.  It was all very logical.  For example,
memories at the time were very slow.  To speed them up, it was necessary to
assert RAS before CAS, low address bits before high address bits. Intel
just couldn't put enough transistors on silicon to do it the right way.
And everybody had software that ran on the old  hardware and didn't want to
rewrite software to run on a different architecture.

Some manufacturers did have hardware that was well thought out (the
motorola 68xxx for example) running on for the time well thought out
operating systems (the MAC OS).  But that technical superiority ultimately
left Apple with less than 5% of the market while Wintel made giga dollars
cornering the market.  It's all about having lots of software for the end
user to use to run his spread sheet, word processor or ... and the ability
to market them.  And if Bill is anything, he is good a selling his ....

Six months ago when I joined this list, there was a discussion similar to
the current one.  Some of us pointed out that main frames didn't have
BIOS's but a simple (3 instruction) boot loader, that loaded a loader to
load the OS and that was really what the BIOS was doing for Wintel. Linux
does its own but very similar thing.  Since that was the Wintel/Mainframe
way of doing things, the flame throwers came out.

As I remember my first Pc, the BIOS provided some very basic hardware
interfaces that can't (couldn't) fit on my 360 (or 180) K floppy drive and
I couldn't afford a 2 megabyte (that's right, megabyte) hard drive, and it
loaded two routines which were packed right behind the boot sector on the
floppy: msdos.sys and io.sys (depending on the OS used DR-DOS, PC-DOS or
MS-DOS) and then command.com.  If I was brave enough, I could mix and
match, as I did by using msdos.sys and io.sys from M$ and command.com from
DR. (since M$ "borrowed" DOS from DR through QDOS they were and still are
largely compatible) (some think software piracy is wrong only if you steal
from Bill).

Today I have a 20 gigabyte hard drives and I don't think that the low level
interface routines need to be embedded in ROM.  And if I don't need to
embed the low level drivers in ROM, then they can go on a hard drive
with everything else.  That said then it would seem to me that:

    Preloader(3 instructions/MB unique)->loader->(BIOS->OS)

ought to work for all operating systems and all platforms and should be
cross platform C compatible.  Some of the libs would be hardware dependant
so that the #include's are still necessary.  (ie. #include <linlib.h> and
#include (i440FX.h> for example) and there might be some other unique libs.

The new BIOS could be installed by using a program similar to fdisk with
the following assumptions:

1.  There is a ROM on the motherboard that contains the preloader.

2.  The partition table resides in sector 0 and contains the loader  (no
change from now).  

3.  The remainder of cylinder 0 is reserved and contains a configurable
BIOS either preinstalled by the manufacturer, by a value added reseller or
the end user (the first partition begins at cyliner 1 so we still only have
4 partitions). An initial bios is placed there by the fdisk at the time the
disk is partitioned and could be replaced at anytime in the future by
rerunning the fdisk without changing the partition table.  The BIOS would
be loaded into shadow ram starting at location F0000 by the loader (to make
it compatible with current practice but could be loaded at any other memory
location compatible with the OS).

The BIOS itself could be configured with hardware unique drivers for the
video card, unique ide/scsi drivers etc. which might be optimized for
caching etc.  As long as the BIOS is loadable from the hard drive, it can
be made to look anyway you want, do anything you want and be configurable
anyway you want which gives us the ultimate flexibility.

I guess the point I'm reall trying to make is that while loader's and
BIOS's are different they are definitely not mutually exclusive but are
complimentary and by using both, maybe every one wins.


At 04:04 PM 7/16/99 -0230, you wrote:
> Niklas Ekström wrote:
> > I don't think BIOS designers are to blame for the incredibly stupid
> > hardware constructions of the IBM-PC compatible computers. I don't even
> > think you can blame the Intel engineer for that, since they did what they
> > had to do to keep their customers. Mostly it's all IBM's fault! ;)
>
> I blame everybody, including customers :-)* The architecture should have
> been better designed in the beginning, but nobody knew better, the
> customers were reliant on the old technology. the only way is to ease
> people out of it. Linux would be *much* more popular if it ran
> everybody's crappy win32 apps, even though many UNIX apps are way better
> (GIMP, TeX, etc).
> > So really there isn't much to discuss. If you want to make your BIOS
> > IBM-PC compatible, you will end up with the same stuff as always before,
> > but if you are ready to let the compability go you can do something much
> > better.
>
> Not quite. Look at the Linux kernel, which managed to ease people into
> radically new formats, a.out->ELF. It wasn't perfect, but it worked. I
> don't know anybody with a.out binaries.
>
> I think OpenBIOS should be configurable in the same way, and I'm
> obviously not the only one. You could have an 'old-BIOS' configuration,
> while developing a fancy new OpenBIOS way that eliminates limitations
> and is designed to be easily 'upgradeable.' If it's there, the Linux
> kernel guys could do a similar thing, allowing 'old-BIOS' or OpenBIOS
> loading. Those who run certain other OSes could stick with old-BIOS
> while those of us with Linux-only machines could test and use the new
> format. Maybe something could be put in to allow the kernel to find out
> which kind of BIOS is loading it and adjust itself accordingly.
>
> James Oakley
> [e-mail]
> -
> To Unsubscribe: send mail to [e-mail]
> with "unsubscribe openbios" in the body of the message

-
To Unsubscribe: send mail to [e-mail]
with "unsubscribe openbios" in the body of the message