Hi All,

I am wondering if anybody here have any experience on what is the best
way to dynamically allocate buffer for Option ROM during BIOS POST and
bootloader execution.

Since our code size is quite big, I don't want to waste any
significant code space for data storage in Option ROM image.   The
option ROM requires around 20K for the data buffer and I'll want it to
be valid during the POST and after int19 OS bootstrap is running
because our code provide the int13 function to access this storage
controller.  I was thinking to use PMM or EBDA. But according to PMM
spec, the PMM memory is not available after BIOS call int19.  And EBDA
also seems not an option for me because the part of the buffer I use
is for the this controller's host DMA buffer.  The EBDA memory address
can be changed if other Option ROM after mine also allocates EBDA
memory. Then my controller can overwrite the host memory that no
longer belongs to my option ROM.  So what are the other methods to get
memory?  Can I use any free conventional memory for my purpose? If so,
how do I guarantee that nobody else will touch it?  Will OS bootloader
touch conventional memory?

Thanks a lot!

William

William Zhang wrote:

> Hi All,
Hello,

> I am wondering if anybody here have any experience on what is the best
> way to dynamically allocate buffer for Option ROM during BIOS POST and
> bootloader execution.

> Since our code size is quite big, I don't want to waste any
> significant code space for data storage in Option ROM image.   The
> option ROM requires around 20K for the data buffer and I'll want it to
> be valid during the POST and after int19 OS bootstrap is running
> because our code provide the int13 function to access this storage
> controller.  I was thinking to use PMM or EBDA. But according to PMM
> spec, the PMM memory is not available after BIOS call int19.  And EBDA
> also seems not an option for me because the part of the buffer I use
> is for the this controller's host DMA buffer.  The EBDA memory address
> can be changed if other Option ROM after mine also allocates EBDA
> memory. Then my controller can overwrite the host memory that no
> longer belongs to my option ROM.

> So what are the other methods to get memory?

If you mean a part of the RAM which isn't affected by POST/reboot
then your search may be in vain.

Use a flash-RAM instead of a ROM ?

If I had to design a device now, it would act as a PCI-device
and also follow the Int13h rules similar how graphic-cards do.

> Can I use any free conventional memory for my purpose? If so,
> how do I guarantee that nobody else will touch it?

Never :)

> Will OS bootloader touch conventional memory?

Yes, almost all bootloaders start in real mode.

An option could be to have your ROM at  D_0000h (32K, but reporting
64K) and have a writeable shadow RAM at D_8000h, again like VGA.
But I think this also may not keep its contents during INT19h reboot.

__
wolfgang

On 02/08/2010 04:47 PM, William Zhang wrote:
> Hi All,
> 
> I am wondering if anybody here have any experience on what is the best
> way to dynamically allocate buffer for Option ROM during BIOS POST and
> bootloader execution.
> 
> Since our code size is quite big, I don't want to waste any
> significant code space for data storage in Option ROM image.   The
> option ROM requires around 20K for the data buffer and I'll want it to
> be valid during the POST and after int19 OS bootstrap is running
> because our code provide the int13 function to access this storage
> controller.  I was thinking to use PMM or EBDA. But according to PMM
> spec, the PMM memory is not available after BIOS call int19.  And EBDA
> also seems not an option for me because the part of the buffer I use
> is for the this controller's host DMA buffer.  The EBDA memory address
> can be changed if other Option ROM after mine also allocates EBDA
> memory. Then my controller can overwrite the host memory that no
> longer belongs to my option ROM.  So what are the other methods to get
> memory?  Can I use any free conventional memory for my purpose? If so,
> how do I guarantee that nobody else will touch it?  Will OS bootloader
> touch conventional memory?
> 

The standard way of doing this is to lower the Free Base Memory pointer
at address 0x413 and keep a pointer in your ROM area (during preboot the
"ROM area" will actually be writable in a PCI-compliant system; it gets
switched to readonly before INT 19h when the PMM system is torn down.)

Since you're only talking 20K, there probably isn't any reason to do
anything more exotic like using PMM to allocate upper memory but hooking
INT 15h to mask it from the OS.

	-hpa

spamtrap@inspiretomorrow.net wrote:

Make that: "H. Peter Anvin" <spamtrap@ inspire... etc.

Sorry 'bout that, Peter. (and others) We're workin' on it.

Best,
Frank

Thank you for all the reply.   Let me try to understand it. Since I am
quite new to BIOS, correct me if I am wrong.
I need to reduce the available conventional memory size saved at 0x413
by say 20K and also hook int 15h to report 20K less.  But what free
conventional memory can i use and how do i know it is not used by
somebody else and make sure nobody else will use it. Also I only find
int15 ah=3D0x88 (report extended memory size) and int15 ah=3D0xc1(get EBDA
segment address), what is the function number ah for getting the
conventional memory size?    Any help will be high appreciated!
William

On Feb 11, 8:53=A0am, spamt...@inspiretomorrow.net wrote:
> On 02/08/2010 04:47 PM, William Zhang wrote:
>
>
>
> > Hi All,
>
> > I am wondering if anybody here have any experience on what is the best
> > way to dynamically allocate buffer for Option ROM during BIOS POST and
> > bootloader execution.
>
> > Since our code size is quite big, I don't want to waste any
> > significant code space for data storage in Option ROM image. =A0 The
> > option ROM requires around 20K for the data buffer and I'll want it to
> > be valid during the POST and after int19 OS bootstrap is running
> > because our code provide the int13 function to access this storage
> > controller. =A0I was thinking to use PMM or EBDA. But according to PMM
> > spec, the PMM memory is not available after BIOS call int19. =A0And EBD=
A
> > also seems not an option for me because the part of the buffer I use
> > is for the this controller's host DMA buffer. =A0The EBDA memory addres=
s
> > can be changed if other Option ROM after mine also allocates EBDA
> > memory. Then my controller can overwrite the host memory that no
> > longer belongs to my option ROM. =A0So what are the other methods to ge=
t
> > memory? =A0Can I use any free conventional memory for my purpose? If so=
,
> > how do I guarantee that nobody else will touch it? =A0Will OS bootloade=
r
> > touch conventional memory?
>
> The standard way of doing this is to lower the Free Base Memory pointer
> at address 0x413 and keep a pointer in your ROM area (during preboot the
> "ROM area" will actually be writable in a PCI-compliant system; it gets
> switched to readonly before INT 19h when the PMM system is torn down.)
>
> Since you're only talking 20K, there probably isn't any reason to do
> anything more exotic like using PMM to allocate upper memory but hooking
> INT 15h to mask it from the OS.
>
> =A0 =A0 =A0 =A0 -hpa

On 02/11/2010 10:06 AM, William Zhang wrote:
> Thank you for all the reply.   Let me try to understand it. Since I am
> quite new to BIOS, correct me if I am wrong.
> I need to reduce the available conventional memory size saved at 0x413
> by say 20K and also hook int 15h to report 20K less.  But what free
> conventional memory can i use and how do i know it is not used by
> somebody else and make sure nobody else will use it. Also I only find
> int15 ah=0x88 (report extended memory size) and int15 ah=0xc1(get EBDA
> segment address), what is the function number ah for getting the
> conventional memory size?    Any help will be high appreciated!

No, you don't need to hook INT 15h since you're dealing with a small
amount of memory.  If you needed *lots* of memory you would have to
allocate memory from > 1 MB and that would require hooking INT 15h.

You don't need to hook anything.  Instead, just lower the amount of
conventional memory available at address 0x413.

For example, if the value in 0x413 (it's a word-sized variable, uint16_t
in C99 terminology) is 638, you would reduce it to 618, and the address
would be (618 << 10) = 0x9a800, or equivalently a segment address of
(618 << 6) = 9A80h:0000.

	-hpa

"H. Peter Anvin" <spamtrap@inspiretomorrow.net> wrote in message
news:hl1ud3$75h$1@terminus.zytor.com...
> Instead, just lower the amount of
> conventional memory available at address 0x413.
>

Are you sure this method works?

I've attempted to do just that in a couple of bootloaders, but the OSes I've
tried (DOS, Linux) don't seem to respect memory allocation via this method.
I think his driver is "toast" if it has any code in writable ram, whether
just below 640k or 512k via 0x413, or in a UMB (upper memory block) in ram
in the HMA (high memory area).


Rod Pemberton
PS. Added alt.os.development, comp.os.msdos.programmer.
(They may be interested, if not it's a cross-post test to non-moderated
groups from clax's new robomod.)

"Rod Pemberton" <do_not_have@havenone.cmm> wrote in message
news:hl28r3$8me$1@speranza.aioe.org...
> "H. Peter Anvin" <spamtrap@inspiretomorrow.net> wrote in message
> news:hl1ud3$75h$1@terminus.zytor.com...
> > Instead, just lower the amount of
> > conventional memory available at address 0x413.
> >
>
> Are you sure this method works?
>
> I've attempted to do just that in a couple of bootloaders, but the OSes
I've
> tried (DOS, Linux) don't seem to respect memory allocation via this
method.
> I think his driver is "toast" if it has any code in writable ram, whether
> just below 640k or 512k via 0x413, or in a UMB (upper memory block) in ram
> in the HMA (high memory area).
>

Egads!

> in the HMA (high memory area).

Correction, that should've said:
"in the UMA (upper memory area)."


Rod Pemberton

Thanks Peter for the detail explanation. Now I understood.  This is
much easier to use than EBDA, no memory move needed, no need to check
the segment address.  But won't it be conflicted with EBDA since EBDA
is also referring 0x413 to grow down its space from 0xA0000? Take the
example we are using here, assuming the first 2K is actually used by
EBDA and my program only see 638K convention memory available.  So if
i use 20K, then the free memory top is from 618K or sgemnt 0x9a80 now.
If somebody allocate 4K ebda, then it will starts from 0x9a80 to 4K
below it, that is 0x9980 segment. But EBDA  also shift its memory down
4K, then it is going to overwrite my allocated memory. Am I missing
something here?   Also when int19 start, will the os bootloader
overwrite the conventional memory allocated using this method?

On Feb 11, 1:55=A0pm, "H. Peter Anvin" <spamt...@inspiretomorrow.net>
wrote:
> On 02/11/2010 10:06 AM, William Zhang wrote:
>
> > Thank you for all the reply. =A0 Let me try to understand it. Since I a=
m
> > quite new to BIOS, correct me if I am wrong.
> > I need to reduce the available conventional memory size saved at 0x413
> > by say 20K and also hook int 15h to report 20K less. =A0But what free
> > conventional memory can i use and how do i know it is not used by
> > somebody else and make sure nobody else will use it. Also I only find
> > int15 ah=3D0x88 (report extended memory size) and int15 ah=3D0xc1(get E=
BDA
> > segment address), what is the function number ah for getting the
> > conventional memory size? =A0 =A0Any help will be high appreciated!
>
> No, you don't need to hook INT 15h since you're dealing with a small
> amount of memory. =A0If you needed *lots* of memory you would have to
> allocate memory from > 1 MB and that would require hooking INT 15h.
>
> You don't need to hook anything. =A0Instead, just lower the amount of
> conventional memory available at address 0x413.
>
> For example, if the value in 0x413 (it's a word-sized variable, uint16_t
> in C99 terminology) is 638, you would reduce it to 618, and the address
> would be (618 << 10) =3D 0x9a800, or equivalently a segment address of
> (618 << 6) =3D 9A80h:0000.
>
> =A0 =A0 =A0 =A0 -hpa

On 02/11/2010 05:29 PM, William Zhang wrote:
> Thanks Peter for the detail explanation. Now I understood.  This is
> much easier to use than EBDA, no memory move needed, no need to check
> the segment address.  But won't it be conflicted with EBDA since EBDA
> is also referring 0x413 to grow down its space from 0xA0000? Take the
> example we are using here, assuming the first 2K is actually used by
> EBDA and my program only see 638K convention memory available.  So if
> i use 20K, then the free memory top is from 618K or sgemnt 0x9a80 now.
> If somebody allocate 4K ebda, then it will starts from 0x9a80 to 4K
> below it, that is 0x9980 segment. But EBDA  also shift its memory down
> 4K, then it is going to overwrite my allocated memory. Am I missing
> something here?   Also when int19 start, will the os bootloader
> overwrite the conventional memory allocated using this method?
> 

No, the EBDA will already have adjusted 0x413.

The OS bootloader, or a BIOS-using real mode operating system, like DOS,
will respect this area; a protected-mode operating system will not (but
you should have a real hardware driver there.)

	-hpa

On Feb 11, 4:53=A0pm, "Rod Pemberton" <do_not_h...@havenone.cmm> wrote:
> "H. Peter Anvin" <spamt...@inspiretomorrow.net> wrote in messagenews:hl1u=
d3$75h$1@terminus.zytor.com...
>
> > Instead, just lower the amount of
> > conventional memory available at address 0x413.
>
> Are you sure this method works?
>
> I've attempted to do just that in a couple of bootloaders, but the OSes I=
've
> tried (DOS, Linux) don't seem to respect memory allocation via this metho=
d.
> I think his driver is "toast" if it has any code in writable ram, whether
> just below 640k or 512k via 0x413, or in a UMB (upper memory block) in ra=
m
> in the HMA (high memory area).
>
> Rod Pemberton
> PS. Added alt.os.development, comp.os.msdos.programmer.
> (They may be interested, if not it's a cross-post test to non-moderated
> groups from clax's new robomod.)

The only way to (try to?) guarantee that that memory doesn't get used
is to hook to all BIOS functions that enumerate memory (e.g. int 0x12,
int 0x15 fxns 0xE801, 0xE820, etc etc) and return reduced ranges.
There may be other places to consider (e.g. CMOS, tables for
multiprocessor configurations).

Alex

Yes I understand that new EBDA allocation after my driver will adjust
available system memory size at 0x413 but it will also move down the
original allocated memory which can be allocated by EBDA or my memory
allocated by this method. This will overwrite my memory, right? Can
EBDA tell the used memory from top of the free memory to 0xA0000 is
actually allocated by EDMA or by just adjusting 0x413?
On Feb 11, 7:10=A0pm, "H. Peter Anvin" <spamt...@inspiretomorrow.net>
wrote:
> On 02/11/2010 05:29 PM, William Zhang wrote:
>
> > Thanks Peter for the detail explanation. Now I understood. =A0This is
> > much easier to use than EBDA, no memory move needed, no need to check
> > the segment address. =A0But won't it be conflicted with EBDA since EBDA
> > is also referring 0x413 to grow down its space from 0xA0000? Take the
> > example we are using here, assuming the first 2K is actually used by
> > EBDA and my program only see 638K convention memory available. =A0So if
> > i use 20K, then the free memory top is from 618K or sgemnt 0x9a80 now.
> > If somebody allocate 4K ebda, then it will starts from 0x9a80 to 4K
> > below it, that is 0x9980 segment. But EBDA =A0also shift its memory dow=
n
> > 4K, then it is going to overwrite my allocated memory. Am I missing
> > something here? =A0 Also when int19 start, will the os bootloader
> > overwrite the conventional memory allocated using this method?
>
> No, the EBDA will already have adjusted 0x413.
>
> The OS bootloader, or a BIOS-using real mode operating system, like DOS,
> will respect this area; a protected-mode operating system will not (but
> you should have a real hardware driver there.)
>
> =A0 =A0 =A0 =A0 -hpa

Thanks Rod for forwarding the post.  Here is th orginal question and
post link

http://groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/e3522=
8bd2a0cf6b0

Hi All,

I am wondering if anybody here have any experience on what is the best
way to dynamically allocate buffer for Option ROM during BIOS POST and
bootloader execution.

Since our code size is quite big, I don't want to waste any
significant code space for data storage in Option ROM image.   The
option ROM requires around 20K for the data buffer and I'll want it to
be valid during the POST and after int19 OS bootstrap is running
because our code provide the int13 function to access this storage
controller.  I was thinking to use PMM or EBDA. But according to PMM
spec, the PMM memory is not available after BIOS call int19.  And EBDA
also seems not an option for me because the part of the buffer I use
is for the this controller's host DMA buffer.  The EBDA memory address
can be changed if other Option ROM after mine also allocates EBDA
memory. Then my controller can overwrite the host memory that no
longer belongs to my option ROM.  So what are the other methods to get
memory?  Can I use any free conventional memory for my purpose? If so,
how do I guarantee that nobody else will touch it?  Will OS bootloader
touch conventional memory?

Thanks a lot!

William

On Feb 11, 5:14=A0pm, "Rod Pemberton" <do_not_h...@havenone.cmm> wrote:
> "Rod Pemberton" <do_not_h...@havenone.cmm> wrote in message
>
> news:hl28r3$8me$1@speranza.aioe.org...
>
>
>
> > "H. Peter Anvin" <spamt...@inspiretomorrow.net> wrote in message
> >news:hl1ud3$75h$1@terminus.zytor.com...
> > > Instead, just lower the amount of
> > > conventional memory available at address 0x413.
>
> > Are you sure this method works?
>
> > I've attempted to do just that in a couple of bootloaders, but the OSes
> I've
> > tried (DOS, Linux) don't seem to respect memory allocation via this
> method.
> > I think his driver is "toast" if it has any code in writable ram, wheth=
er
> > just below 640k or 512k via 0x413, or in a UMB (upper memory block) in =
ram
> > in the HMA (high memory area).
>
> Egads!
>
> > in the HMA (high memory area).
>
> Correction, that should've said:
> "in the UMA (upper memory area)."
>
> Rod Pemberton

Thanks Rod for forwarding the post. Here is the original post and
link:
http://groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/e3522=
8bd2a0cf6b0

Hi All,

I am wondering if anybody here have any experience on what is the best
way to dynamically allocate buffer for Option ROM during BIOS POST and
bootloader execution.

Since our code size is quite big, I don't want to waste any
significant code space for data storage in Option ROM image.   The
option ROM requires around 20K for the data buffer and I'll want it to
be valid during the POST and after int19 OS bootstrap is running
because our code provide the int13 function to access this storage
controller.  I was thinking to use PMM or EBDA. But according to PMM
spec, the PMM memory is not available after BIOS call int19.  And EBDA
also seems not an option for me because the part of the buffer I use
is for the this controller's host DMA buffer.  The EBDA memory address
can be changed if other Option ROM after mine also allocates EBDA
memory. Then my controller can overwrite the host memory that no
longer belongs to my option ROM.  So what are the other methods to get
memory?  Can I use any free conventional memory for my purpose? If so,
how do I guarantee that nobody else will touch it?  Will OS bootloader
touch conventional memory?

Thanks a lot!

William

On Feb 11, 5:14=A0pm, "Rod Pemberton" <do_not_h...@havenone.cmm> wrote:
> "Rod Pemberton" <do_not_h...@havenone.cmm> wrote in message
>
> news:hl28r3$8me$1@speranza.aioe.org...
>
>
>
> > "H. Peter Anvin" <spamt...@inspiretomorrow.net> wrote in message
> >news:hl1ud3$75h$1@terminus.zytor.com...
> > > Instead, just lower the amount of
> > > conventional memory available at address 0x413.
>
> > Are you sure this method works?
>
> > I've attempted to do just that in a couple of bootloaders, but the OSes
> I've
> > tried (DOS, Linux) don't seem to respect memory allocation via this
> method.
> > I think his driver is "toast" if it has any code in writable ram, wheth=
er
> > just below 640k or 512k via 0x413, or in a UMB (upper memory block) in =
ram
> > in the HMA (high memory area).
>
> Egads!
>
> > in the HMA (high memory area).
>
> Correction, that should've said:
> "in the UMA (upper memory area)."
>
> Rod Pemberton

On 12 Feb, 07:54, William Zhang <spamt...@inspiretomorrow.net> wrote:
> Yes I understand that new EBDA allocation after my driver will adjust
> available system memory size at 0x413 but it will also move down the
> original allocated memory which can be allocated by EBDA or my memory
> allocated by this method. This will overwrite my memory, right? Can
> EBDA tell the used memory from top of the free memory to 0xA0000 is
> actually allocated by EDMA or by just adjusting 0x413?

The BIOS should keep track of where the EBDA is located separately
from the top-of-conventional-memory figure. On some systems the 2
bytes at 0x40e tells where the EBDA is. This won't change so if you
allocate 20k below it the EBDA will still be where it was and your
memory will be below the EBDA. For some references search for the
heading "the machine architecture" in

  http://aodfaq.wikispaces.com/

By the way, please post to Usenet *after* the message you are replying
to.

James

On 02/11/2010 11:33 PM, Alexei A. Frounze wrote:
> 
> The only way to (try to?) guarantee that that memory doesn't get used
> is to hook to all BIOS functions that enumerate memory (e.g. int 0x12,
> int 0x15 fxns 0xE801, 0xE820, etc etc) and return reduced ranges.
> There may be other places to consider (e.g. CMOS, tables for
> multiprocessor configurations).
> 

INT 0x12 reads the variable at 0x413.

	-hpa

Thanks James and everybody's help. I'll take a look the reference and
do some testing.

On Feb 12, 1:59=A0am, James Harris <spamt...@inspiretomorrow.net> wrote:
> On 12 Feb, 07:54, William Zhang <spamt...@inspiretomorrow.net> wrote:
>
> > Yes I understand that new EBDA allocation after my driver will adjust
> > available system memory size at 0x413 but it will also move down the
> > original allocated memory which can be allocated by EBDA or my memory
> > allocated by this method. This will overwrite my memory, right? Can
> > EBDA tell the used memory from top of the free memory to 0xA0000 is
> > actually allocated by EDMA or by just adjusting 0x413?
>
> The BIOS should keep track of where the EBDA is located separately
> from the top-of-conventional-memory figure. On some systems the 2
> bytes at 0x40e tells where the EBDA is. This won't change so if you
> allocate 20k below it the EBDA will still be where it was and your
> memory will be below the EBDA. For some references search for the
> heading "the machine architecture" in
>
> =A0http://aodfaq.wikispaces.com/
>
> By the way, please post to Usenet *after* the message you are replying
> to.
>
> James

H. Peter Anvin wrote:

> On 02/11/2010 10:06 AM, William Zhang wrote:
>> Thank you for all the reply.   Let me try to understand it. Since I am
>> quite new to BIOS, correct me if I am wrong.
>> I need to reduce the available conventional memory size saved at 0x413
>> by say 20K and also hook int 15h to report 20K less.  But what free
>> conventional memory can i use and how do i know it is not used by
>> somebody else and make sure nobody else will use it. Also I only find
>> int15 ah=0x88 (report extended memory size) and int15 ah=0xc1(get EBDA
>> segment address), what is the function number ah for getting the
>> conventional memory size?    Any help will be high appreciated!

> No, you don't need to hook INT 15h since you're dealing with a small
> amount of memory.  If you needed *lots* of memory you would have to
> allocate memory from > 1 MB and that would require hooking INT 15h.

> You don't need to hook anything.  Instead, just lower the amount of
> conventional memory available at address 0x413.

> For example, if the value in 0x413 (it's a word-sized variable, uint16_t
> in C99 terminology) is 638, you would reduce it to 618, and the address
> would be (618 << 10) = 0x9a800, or equivalently a segment address of
> (618 << 6) = 9A80h:0000.

Perhaps I see this from another aspect, but all my BIOSes
(x486,K7,K8,Phenom II) report 639 KB free after POST/Int19h.
The one KB missing is just the realmode IDT at the bottom.

The top of convential memory (below a0000h) may be used from
BIOS as default stack until the bootloader setup its own stack.

DOS,winDOS,win.com,ntldr,grub,... may use this range for stack
during bootup and/or even lateron (ie:DOS 6.00) as well.
I'm not sure if INT19h wont set 0x413 to 639KB default in general.

__
wolfgang

 

"wolfgang kern" <nowhere@never.at> wrote in message
news:hl4biq$3ha$1@newsreader2.utanet.at...
>
> Perhaps I see this from another aspect, but all my BIOSes
> (x486,K7,K8,Phenom II) report 639 KB free after POST/Int19h.
....
> The one KB missing is just the realmode IDT at the bottom.

Shouldn't the "missing" be the 1KB just below 640KB used for the EBDA?


RP

On 02/12/2010 11:52 AM, wolfgang kern wrote:
> 
> Perhaps I see this from another aspect, but all my BIOSes
> (x486,K7,K8,Phenom II) report 639 KB free after POST/Int19h.
> The one KB missing is just the realmode IDT at the bottom.
> 

No.  The 1K missing is the EBDA at the top.  The realmode IDT and basic
BDA at the bottom are counted in those 639K.

	-hpa

H. Peter Anvin wrote:

>> Perhaps I see this from another aspect, but all my BIOSes
>> (x486,K7,K8,Phenom II) report 639 KB free after POST/Int19h.
>> The one KB missing is just the realmode IDT at the bottom.

> No.  The 1K missing is the EBDA at the top.  The realmode IDT and basic
> BDA at the bottom are counted in those 639K.

Thanks, interesting and 'new' to me :)
Seems I skipped some information and ignored EBDA since decades.

same answer to Rod.

the question still is if INT19h wont reset 0413h to default.

__
wolfgang

On 02/13/2010 02:20 AM, wolfgang kern wrote:
> H. Peter Anvin wrote:
> 
>>> Perhaps I see this from another aspect, but all my BIOSes
>>> (x486,K7,K8,Phenom II) report 639 KB free after POST/Int19h.
>>> The one KB missing is just the realmode IDT at the bottom.
> 
>> No.  The 1K missing is the EBDA at the top.  The realmode IDT and basic
>> BDA at the bottom are counted in those 639K.
> 
> Thanks, interesting and 'new' to me :)
> Seems I skipped some information and ignored EBDA since decades.
> 
> same answer to Rod.
> 
> the question still is if INT19h wont reset 0413h to default.
> 

It doesn't.  PXE, for example, relies on that.

	-hpa