OSDev.org

Hey,

Just wondering if there is a difference between the extended and configured memory that is returned by these two functions. I know that E801 may return AX=BX=0 which would lead me to believe that there is no difference... Just wondering what you guys have found in your own experience...

Cheers.

Hi,

GenX wrote:Just wondering if there is a difference between the extended and configured memory that is returned by these two functions. I know that E801 may return AX=BX=0 which would lead me to believe that there is no difference... Just wondering what you guys have found in your own experience...

As far as I can tell, the extended and configured values should be the same.

For 0xE801, Linux uses CX/DX but clears them before calling the BIOS and checks if they've changed after. If they haven't changed Linux uses AX/BX instead, but there's notes in the source saying that most people just use AX/BX. GRUB uses AX/BX but doesn't check for a buggy BIOS that returns zero. My E801 code uses AX/BX, but if they are zero it uses CD/DX.

Linux and GRUB don't support 0xE881, and Ralf Brown's list doesn't say too much about it. For my code, I copied the 0xE801 code and extended the registers (i.e. I'm using EAX/EBX unless they are zero).


Cheers,

Brendan

Hey Brendan,

Do you have any idea as to why Linux and GRUB don't support E881? It seems pretty trivial to implement it along side E801...

Thanks for the info, very interesting.

Cheers.

Hi,

GenX wrote:Do you have any idea as to why Linux and GRUB don't support E881? It seems pretty trivial to implement it along side E801...

I don't know - to me it seems like they do a crappy job of it and then expect the user to tell the OS correct information if it goes wrong. I only really checked them to make sure my own code is better. ::)


Cheers,

Brendan

Brendan wrote: I only really checked them to make sure my own code is better. ::)

And I am sure it is...

While we are talking about your code, I download the floppy image from your website and when I ran it in bochs I kept getting a divide by zero exception whenever I selected the boot option on the menu.

I put the image on a disk and ran it in my pc and whenever I select a menu option it just froze, when I tried to select a video mode the window with the mode list came up and then it froze. If I select the boot option it spews out a whole heap of info and after a bunch from the device manager it froze...

Cheers.

Hi,

GenX wrote:While we are talking about your code, I download the floppy image from your website and when I ran it in bochs I kept getting a divide by zero exception whenever I selected the boot option on the menu.

This is a known problem, caused by Bochs being so slow. The code measures how much the local APIC timer's count changes in 250 mS (IIRC) and uses this to calculate the CPUs bus speed. On Bochs (depending on how it's configured and the speed of the host machine) the local APICs timer count may not change in 250 mS, so it causes the divide by zero when it's trying to calculate the bus speed. It can't happen on a real computer where the bus speed is realistic.

GenX wrote:I put the image on a disk and ran it in my pc and whenever I select a menu option it just froze, when I tried to select a video mode the window with the mode list came up and then it froze. If I select the boot option it spews out a whole heap of info and after a bunch from the device manager it froze...

If it freezes after displaying a list of detected hardware, then everything worked correctly - it doesn't actually start any device drivers (they aren't part of the kernel). You should end up with something that looks like the screen shots at http://bcos.hopto.org/screens.html).

For the video window freezing, this is a problem. It sounds likely that there's a bug somewhere in the menu system's code.

This is the old version of the OS though, rather than the new/unreleased version. For the new version all of the real mode code is being rewritten and the old menu system's code was dumped.


Thanks,

Brendan

I look forward to checking out your latest work once it is released.

It appears as though it worked ok on my machine because the 2nd screen shot looks very similar to what mine looked like. ;D

From what I could tell on mine it looked as though it detected everything properly aswell... Although for the life of me I cannot work out why windows and your os detect two cpus?? I only have one, unless the actual device houses two seperate cpus... ???

GenX wrote: From what I could tell on mine it looked as though it detected everything properly aswell... Although for the life of me I cannot work out why windows and your os detect two cpus?? I only have one, unless the actual device houses two seperate cpus... ???

Do you have a processor with HyperThreading? They commonly show as two processors.

Hi,

GenX wrote:From what I could tell on mine it looked as though it detected everything properly aswell... Although for the life of me I cannot work out why windows and your os detect two cpus?? I only have one, unless the actual device houses two seperate cpus... ???

There's 2 possibilities - a dual core chip or a single core chip with hyper-threading.

For my OS, the list of detected hardware will display these differently. For a dual core chip you'd get something like:

[tt]|_CPU:Intel Pentium 4 (or whatever)
|_CPU:Intel Pentium 4 (or whatever)[/tt]

Where both CPUs connect to the same line on the left.

For hyper-threading it'll show the second CPU connected to the first CPU, like:

[tt]|_CPU:Intel Pentium 4 (or whatever)
| |_CPU:Intel Pentium 4 (or whatever)[/tt]

It's a subtle difference....


Cheers,

Brendan

Hey well there you go... It's the Hyper-Threading one, for two reasons, your OS displayed it like one and I specifically bought it as such... ;D

I just never realised it would appear as two cpus...

Thanks.