Discussion:
EBDA detection
(too old to reply)
James Harris
2015-02-05 11:36:34 UTC
Permalink
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.

http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm

But that 16-bit word was originally used as a port address for a potential
LPT4. Comparing the two sources above and RBIL there is some disagreement
over when the meaning of those two bytes changed so I thought a better way
to detect the presence of an EBDA might be to add the apparent EBDA length
in kbytes (specified in its first two bytes) to its address and see if it
came to 640k.

http://stanislavs.org/helppc/ebda.html

I just tried that test on eight machines. On seven of them the calculation
worked out: the address and length added up to 640k (and the EBDA was 1k in
size in each case). But on one of them the EBDA was at 636k and of length 3k
(according to the values read). This means it ended at 639k rather than
640k.

I thought to post this for a number of reasons:

* I thought you might find it interesting

* I thought you might have some ideas as to what follows the EBDA in the
last 1024 bytes on that odd machine (unimportant, just of interest)

* I wondered if you had some better way to tell whether BDA offset 0x0e
contains an EBDA paragraph number or not. I could just assume that that's
what those bytes hold as the EBDA pointer has been its use for a long time
but perhaps there is a better way to check.

Any thoughts?

James
Alexei A. Frounze
2015-02-05 12:42:59 UTC
Permalink
Post by James Harris
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
But that 16-bit word was originally used as a port address for a potential
LPT4. Comparing the two sources above and RBIL there is some disagreement
over when the meaning of those two bytes changed so I thought a better way
to detect the presence of an EBDA might be to add the apparent EBDA length
in kbytes (specified in its first two bytes) to its address and see if it
came to 640k.
http://stanislavs.org/helppc/ebda.html
I just tried that test on eight machines. On seven of them the calculation
worked out: the address and length added up to 640k (and the EBDA was 1k in
size in each case). But on one of them the EBDA was at 636k and of length 3k
(according to the values read). This means it ended at 639k rather than
640k.
* I thought you might find it interesting
* I thought you might have some ideas as to what follows the EBDA in the
last 1024 bytes on that odd machine (unimportant, just of interest)
* I wondered if you had some better way to tell whether BDA offset 0x0e
contains an EBDA paragraph number or not. I could just assume that that's
what those bytes hold as the EBDA pointer has been its use for a long time
but perhaps there is a better way to check.
Any thoughts?
Int 0x12 / AX (and word at 0x40:0x13) should give you the size (in KBs) of the RAM below 640KB. As I understand it, the value should exclude EBDA (it would be useless otherwise). Can you dump the pairs of these values and see what's in there?

Alex
James Harris
2015-02-05 16:47:15 UTC
Permalink
Post by Alexei A. Frounze
Post by James Harris
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
But that 16-bit word was originally used as a port address for a potential
LPT4. Comparing the two sources above and RBIL there is some disagreement
over when the meaning of those two bytes changed so I thought a better way
to detect the presence of an EBDA might be to add the apparent EBDA length
in kbytes (specified in its first two bytes) to its address and see if it
came to 640k.
http://stanislavs.org/helppc/ebda.html
I just tried that test on eight machines. On seven of them the calculation
worked out: the address and length added up to 640k (and the EBDA was 1k in
size in each case). But on one of them the EBDA was at 636k and of length 3k
(according to the values read). This means it ended at 639k rather than
640k.
...
Post by Alexei A. Frounze
Post by James Harris
* I wondered if you had some better way to tell whether BDA offset 0x0e
contains an EBDA paragraph number or not. I could just assume that that's
what those bytes hold as the EBDA pointer has been its use for a long time
but perhaps there is a better way to check.
...
Post by Alexei A. Frounze
Int 0x12 / AX (and word at 0x40:0x13) should give you the size (in KBs) of
the RAM below 640KB. As I understand it, the value should exclude EBDA (it
would be useless otherwise). Can you dump the pairs of these values and
see what's in there?
It's a good idea but won't work with network boot. IME bootroms lower the
0x413 memory size before they pass control to the code they are booting, and
0x12 just reports that value.

James
Rod Pemberton
2015-02-06 00:51:29 UTC
Permalink
On Thu, 05 Feb 2015 06:36:34 -0500, James Harris
Post by James Harris
The address of the EBDA can apparently be found by looking
at BDA offset 0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
...
Post by James Harris
But that 16-bit word was originally used as a port address for a
potential LPT4. Comparing the two sources above and RBIL there
is some disagreement over when the meaning of those two bytes
changed so I thought a better way to detect the presence of an
EBDA might be to add the apparent EBDA length in kbytes
(specified in its first two bytes) to its address and see if
it came to 640k.
My notes say the BDA was 1981 with the original IBM PC,
and the EBDA was 1987 with the IBM PS/2.

ISTM, you'd need a REALLY old machine to have that old port
address conflict with the EBDA data.

So, is this an issue?
Post by James Harris
http://stanislavs.org/helppc/ebda.html
I just tried that test on eight machines. On seven of them the
calculation worked out: the address and length added up to 640k
(and the EBDA was 1k in size in each case). But on one of them
the EBDA was at 636k and of length 3k (according to the values
read). This means it ended at 639k rather than 640k.
The E820h memory maps show the EBDA size too, where E820h is
supported, i.e., roughly 1996 or later BIOSes. E.g., the EBDA is
the 002 block, or sometimes a 001 block, at 9FC00h or 9F800h or
9F400h, usually 400h or 800h or C00h bytes, respectively. You
should also note that Int 12h only reports the EBDA being used for
*some* machines, not all of them. Some machines with EBDA report
the full 640KB (A0000h) via Int 12h instead of less memory, instead
of the 639KB (9FC00h), 638KB (9F800h), 637KB (9F400h) values.

E820h maps a.o.d. 2011
https://groups.google.com/d/msg/alt.os.development/c1FIx1NwrVg/7JVaeVxvKRcJ
https://groups.google.com/d/msg/alt.os.development/c1FIx1NwrVg/3fSdpSFkpucJ
https://groups.google.com/d/msg/alt.os.development/c1FIx1NwrVg/uQ0vCwIeY6QJ

E820h maps a.o.d. 2013
https://groups.google.com/d/msg/alt.os.development/pYFS7bPzlPc/buOiJ37cefcJ

E820h results a.o.d. 2014
https://groups.google.com/d/msg/alt.os.development/IxHGWbTA_Fo/5833Wr6kBFgJ
Post by James Harris
* I thought you might have some ideas as to what follows the EBDA in the
last 1024 bytes on that odd machine (unimportant, just of interest)
Was this for DOS? If so, _maybe_ it's using Int 15h memory allocation:

http://support.microsoft.com/KB/95555

I would seriously doubt that though. I.e., I'd expect the BIOS to reduce
the available Int 12h memory for the EBDA *before* DOS got to it.

*But*, you did mention a boot rom to Alexei ... Perhaps, it's not Int 15h,
but the network code in the boot rom using memory? Does the network boot
code execute before the BIOS? If so, maybe, the boot rom is adjusting
Int 12h first, *before* the regular BIOS allocates the EBDA? That seems
possible to me ... Did you retrieve and dump the memory there?
Post by James Harris
* I wondered if you had some better way to tell whether BDA offset 0x0e
contains an EBDA paragraph number or not. I could just assume that that's
what those bytes hold as the EBDA pointer has been its use for a long
time but perhaps there is a better way to check.
BFN,


Rod Pemberton
James Harris
2015-02-06 12:36:58 UTC
Permalink
Post by Rod Pemberton
On Thu, 05 Feb 2015 06:36:34 -0500, James Harris
Post by James Harris
The address of the EBDA can apparently be found by looking
at BDA offset 0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
...
Post by James Harris
But that 16-bit word was originally used as a port address for a
potential LPT4. Comparing the two sources above and RBIL there
is some disagreement over when the meaning of those two bytes
changed so I thought a better way to detect the presence of an
EBDA might be to add the apparent EBDA length in kbytes
(specified in its first two bytes) to its address and see if
it came to 640k.
My notes say the BDA was 1981 with the original IBM PC,
and the EBDA was 1987 with the IBM PS/2.
ISTM, you'd need a REALLY old machine to have that old port
address conflict with the EBDA data.
So, is this an issue?
1987 is a long time ago so maybe it is no longer an issue. Does what you say
mean that all BIOSes produced since 1987 would have an EBDA? Or would it be
just those which are original PS/2s or are PS/2 compatible in some way? Or
would any particular feature depend on the machine so that we have to test
for each feature individually?

When considering clone PCs (i.e. all of them these days) I am never sure how
much of each ancestor a given clone will have adopted. For example, in this
case if a clone manufacturer made a machine in 2005, say, but had no need of
an EBDA could they decide to have its BIOS use BDA offset 0x0e for a
parallel port? Perhaps it might be a machine intended for industrial use
where extra serial and parallel ports were important.

I did think I might be able to detect PS/2 compatibility with int 0x15-c0
but *none* of the machines I've tried so far support that function; they all
return with carry set.
Post by Rod Pemberton
Post by James Harris
http://stanislavs.org/helppc/ebda.html
I just tried that test on eight machines. On seven of them the
calculation worked out: the address and length added up to 640k
(and the EBDA was 1k in size in each case). But on one of them
the EBDA was at 636k and of length 3k (according to the values
read). This means it ended at 639k rather than 640k.
The E820h memory maps show the EBDA size too, where E820h is
supported, i.e., roughly 1996 or later BIOSes. E.g., the EBDA is
the 002 block, or sometimes a 001 block,
I hadn't noticed that and it is a big surprise! Why would a BIOS report that
space as usable by an OS?

In fact, I just tried my test machines and they mostly report type 2 so your
type 1 seems at least to be unusual.

Do you think your BIOS may be wrong in reporting it as type 1? Or could it
be that that particular BIOS does not need any EBDA once the machine is up
and running? (Presumably, as it reports it as type 1 it can expect an OS to
trample on that space.)
Post by Rod Pemberton
at 9FC00h or 9F800h or
9F400h, usually 400h or 800h or C00h bytes, respectively. You
should also note that Int 12h only reports the EBDA being used for
*some* machines, not all of them. Some machines with EBDA report
the full 640KB (A0000h) via Int 12h instead of less memory, instead
of the 639KB (9FC00h), 638KB (9F800h), 637KB (9F400h) values.
I've seen that too. I have one machine (a Dell 486 laptop) which appears to
show a 1k EBDA from 9fc00 to 9ffff but in its e820 call to report that space
as start=0, length=640k (i.e. the whole lower 640k) which it says is all
type 1.

It seems that we might need to vet some of the figures obtained from BIOSes!
In this case, perhaps the table obtained from e820 should be adjusted to
remove what the machine identifies as its EBDA space so that the OS does not
touch the EBDA (at least if there's ever a chance of using the BIOS once the
OS is running).

...
Post by Rod Pemberton
Post by James Harris
* I thought you might have some ideas as to what follows the EBDA in the
last 1024 bytes on that odd machine (unimportant, just of interest)
http://support.microsoft.com/KB/95555
I would seriously doubt that though. I.e., I'd expect the BIOS to reduce
the available Int 12h memory for the EBDA *before* DOS got to it.
No, not for DOS. This was straight from a network boot.
Post by Rod Pemberton
*But*, you did mention a boot rom to Alexei ... Perhaps, it's not Int 15h,
but the network code in the boot rom using memory? Does the network boot
code execute before the BIOS? If so, maybe, the boot rom is adjusting
Int 12h first, *before* the regular BIOS allocates the EBDA? That seems
possible to me ... Did you retrieve and dump the memory there?
AIUI the network boot code will run fairly early in the BIOS sequence, at
the point where the BIOS initialises all bootable devices but that would
likely be after the BIOS has initialised memory in the way that it wants.

I didn't dump the memory there but I just tried booting that machine from
floppy and get the same result so it is not the network boot either.

James
Rod Pemberton
2015-02-07 05:24:38 UTC
Permalink
On Fri, 06 Feb 2015 07:36:58 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Thu, 05 Feb 2015 06:36:34 -0500, James Harris
Post by James Harris
The address of the EBDA can apparently be found by looking
at BDA offset 0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
...
Post by James Harris
But that 16-bit word was originally used as a port address for a
potential LPT4. Comparing the two sources above and RBIL there
is some disagreement over when the meaning of those two bytes
changed so I thought a better way to detect the presence of an
EBDA might be to add the apparent EBDA length in kbytes
(specified in its first two bytes) to its address and see if
it came to 640k.
My notes say the BDA was 1981 with the original IBM PC,
and the EBDA was 1987 with the IBM PS/2.
ISTM, you'd need a REALLY old machine to have that old port
address conflict with the EBDA data.
So, is this an issue?
1987 is a long time ago so maybe it is no longer an issue.
..
Post by James Harris
Does what you say mean that all BIOSes produced since 1987 would
have an EBDA? Or would it be just those which are original PS/2s
or are PS/2 compatible in some way? Or would any particular feature
depend on the machine so that we have to test for each feature
individually?
I have no idea. I've not needed the EBDA for ... anything.
I just have the dates from my personal PC timeline project.
We have RBIL and the PS/2 Tech. Ref. manuals for info.
Post by James Harris
When considering clone PCs (i.e. all of them these days) I am never
sure how much of each ancestor a given clone will have adopted. For
example, in this case if a clone manufacturer made a machine in 2005,
say, but had no need of an EBDA could they decide to have its BIOS use
BDA offset 0x0e for a parallel port? Perhaps it might be a machine
intended for industrial use where extra serial and parallel ports
were important.
No idea.
Post by James Harris
I did think I might be able to detect PS/2 compatibility with int 0x15-c0
but *none* of the machines I've tried so far support that function; they
all return with carry set.
...
Post by James Harris
Post by Rod Pemberton
Post by James Harris
http://stanislavs.org/helppc/ebda.html
I just tried that test on eight machines. On seven of them the
calculation worked out: the address and length added up to 640k
(and the EBDA was 1k in size in each case). But on one of them
the EBDA was at 636k and of length 3k (according to the values
read). This means it ended at 639k rather than 640k.
The E820h memory maps show the EBDA size too, where E820h is
supported, i.e., roughly 1996 or later BIOSes. E.g., the EBDA is
the 002 block, or sometimes a 001 block,
I hadn't noticed that and it is a big surprise!
That's why I mentioned it. I saw it as I skimmed those posts.
Post by James Harris
Why would a BIOS report that space as usable by an OS?
I have no idea. I would have to go back through the posts to find
which machine it was, mine, wolfgang's, Ben's. If it was around
the mid-90's, I'd assume the BIOS authors just didn't know what
to do or made a mistake or chose block 001 out of caution.
Or, maybe, it's a bug in my code. It was a rush job.
Post by James Harris
In fact, I just tried my test machines and they mostly report
type 2 so your type 1 seems at least to be unusual.
...
Post by James Harris
Do you think your BIOS may be wrong in reporting it as type 1?
I'm not sure whose machine it was offhand, but I could assume so.
Post by James Harris
Or could it be that that particular BIOS does not need any
EBDA once the machine is up and running?
I don't know what software uses the EBDA, but if it's like the
BDA, I would assume it's available for both OS and user usage.
Post by James Harris
(Presumably, as it reports it as type 1 it can expect an OS
to trample on that space.)
There might be some step we're not aware of which indicates
the presence of EBDA and whether it's active and valid or not.
It could be some machines have EBDA post PS/2 even if they
don't have PS/2 style mice. Your guess is as good as mine.
Post by James Harris
Post by Rod Pemberton
at 9FC00h or 9F800h or
9F400h, usually 400h or 800h or C00h bytes, respectively. You
should also note that Int 12h only reports the EBDA being used for
*some* machines, not all of them. Some machines with EBDA report
the full 640KB (A0000h) via Int 12h instead of less memory, instead
of the 639KB (9FC00h), 638KB (9F800h), 637KB (9F400h) values.
I've seen that too. I have one machine (a Dell 486 laptop) which
appears to show a 1k EBDA from 9fc00 to 9ffff but in its e820 call
to report that space as start=0, length=640k (i.e. the whole lower
640k) which it says is all type 1.
...
Post by James Harris
It seems that we might need to vet some of the figures obtained from BIOSes!
Yes.
Post by James Harris
In this case, perhaps the table obtained from e820 should be
adjusted to remove what the machine identifies as its EBDA
space so that the OS does not touch the EBDA (at least if
there's ever a chance of using the BIOS once the OS is running).
For a "safe" replacement version of E820h, I'd do a few things.
If the EBDA is missing from E820h, I'd insert a block for it.
If the EBDA is marked as block 001, I'd change it to block 002.

Although, I'm not thoroughly sure, what if any, negative
consequences that might have on software. It just seems
reasonable to me to do so.


Rod Pemberton
James Harris
2015-02-07 16:56:04 UTC
Permalink
Post by Rod Pemberton
On Fri, 06 Feb 2015 07:36:58 -0500, James Harris
...
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
My notes say the BDA was 1981 with the original IBM PC,
and the EBDA was 1987 with the IBM PS/2.
...
Post by Rod Pemberton
Post by James Harris
Does what you say mean that all BIOSes produced since 1987 would
have an EBDA? Or would it be just those which are original PS/2s
or are PS/2 compatible in some way? Or would any particular feature
depend on the machine so that we have to test for each feature
individually?
I have no idea. I've not needed the EBDA for ... anything.
Ah, that's not the issue. I wasn't thinking that we need its content but
that if an EBDA exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines seem
automatically to omit it from their e820 reports but not all do.

Potential reasons for omitting the EBDA space even if e820 does not:

* if we may want to drop back to real mode at any point
* if we want to use any BIOS services (whether directly or emulated)
* if the OS is to run in real mode
* if there's a chance that SMM routines may use the EBDA space

On the last point see

http://wiki.osdev.org/Memory_Map_%28x86%29

It says: "SMM also seems to use the EBDA. So the EBDA memory area should
never be overwritten."

I guess the same is true of the BDA.

...
Post by Rod Pemberton
For a "safe" replacement version of E820h, I'd do a few things.
If the EBDA is missing from E820h, I'd insert a block for it.
If the EBDA is marked as block 001, I'd change it to block 002.
Although, I'm not thoroughly sure, what if any, negative
consequences that might have on software. It just seems
reasonable to me to do so.
Me too. ISTM that we should take what e820 says is type 1 (available) or
type 3 (reclaimable) - or what we get from other sources if e820 is not
available - and then remove from that list various other things such as the
lowest page starting at 0 (containing the RM interrupt vectors, the BDA and
possibly other things) and any page containing any part of the EBDA. There
may be other things we have to omit from the available list but then what's
left should be safe to use.

James
Rod Pemberton
2015-02-08 02:27:32 UTC
Permalink
On Sat, 07 Feb 2015 11:56:04 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Fri, 06 Feb 2015 07:36:58 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
My notes say the BDA was 1981 with the original IBM PC,
and the EBDA was 1987 with the IBM PS/2.
Does what you say mean that all BIOSes produced since 1987 would
have an EBDA? Or would it be just those which are original PS/2s
or are PS/2 compatible in some way? Or would any particular feature
depend on the machine so that we have to test for each feature
individually?
I have no idea. I've not needed the EBDA for ... anything.
Ah, that's not the issue.
Not being the issue still doesn't make me any more familiar
with EBDA. ;-)
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines seem
automatically to omit it from their e820 reports but not all do.
There were machines were it wasn't in Int 12h.

Was there some where EBDA was not in the E820h map too? ...
Post by James Harris
* if we may want to drop back to real mode at any point
* if we want to use any BIOS services (whether directly or emulated)
* if the OS is to run in real mode
* if there's a chance that SMM routines may use the EBDA space
If we know it's used, then we shouldn't use it.
Post by James Harris
On the last point see
http://wiki.osdev.org/Memory_Map_%28x86%29
It says: "SMM also seems to use the EBDA. So the EBDA memory
area should never be overwritten."
I guess your guess about SMM and extra space was correct.
Post by James Harris
I guess the same is true of the BDA.
I'm pretty sure there was a mention somewhere of a low ram address
below which you weren't supposed to modify things, i.e., 600h or
800h or 1700h or somesuch ... Maybe, this was in RBIL.
Post by James Harris
Post by Rod Pemberton
For a "safe" replacement version of E820h, I'd do a few things.
If the EBDA is missing from E820h, I'd insert a block for it.
If the EBDA is marked as block 001, I'd change it to block 002.
Although, I'm not thoroughly sure, what if any, negative
consequences that might have on software. It just seems
reasonable to me to do so.
Me too. ISTM that we should take what e820 says is type 1 (available)
or type 3 (reclaimable) - or what we get from other sources if e820
is not available - and then remove from that list various other things
such as the lowest page starting at 0 (containing the RM interrupt
vectors, the BDA and possibly other things) and any page containing
any part of the EBDA. There may be other things we have to omit from
the available list but then what's left should be safe to use.
What concerns me the most is SMM using memory in that region, if that's
what's going on. Accidental use of that area by software or because
the E820h block is incorrectly marked could mean that the PS/2 BIOS
emulation for USB keyboard or mice gets blown out. What if the SMM is
emulating IDE access for a SATA drive and caching disk data there? If
that gets blown out, does some data on the drive get trashed? I.e.,
scary if they're doing that ...


Rod Pemberton
James Harris
2015-02-11 10:25:52 UTC
Permalink
Post by Rod Pemberton
On Sat, 07 Feb 2015 11:56:04 -0500, James Harris
...
Post by Rod Pemberton
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines seem
automatically to omit it from their e820 reports but not all do.
There were machines were it wasn't in Int 12h.
Was there some where EBDA was not in the E820h map too? ...
Yes, I've got one here. A Dell Latitude XP laptop which reports in e820 that
all of the low 640k is of type 1 but also reports a 1k EBDA at 639k.

...
Post by Rod Pemberton
I'm pretty sure there was a mention somewhere of a low ram address
below which you weren't supposed to modify things, i.e., 600h or
800h or 1700h or somesuch ... Maybe, this was in RBIL.
The only one I know of is 0x501 which RBIL shows as used by the NEC PC-9800.
Again according to RBIL 0x0504 is used by MS-DOS so if DOS is not running
then anything from 0x504 and above may be OK to use.

I haven't checked but IIRC the old Microsoft MBR copies itself to 0x600 if
that gives us any clues. Maybe they knew that 0x500 and above had some BIOS
uses. Also, given that MS copy running code there it's likely that
manufacturers would have kept that 512-bytes of space empty.

The 80286 apparently used some bytes from 0x800 as hardcoded space.

All of that may be irrelevant. If we just keep the lowest 4k (0x1000)
unchanged then all of those possible low-memory spaces are included.
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
For a "safe" replacement version of E820h, I'd do a few things.
If the EBDA is missing from E820h, I'd insert a block for it.
If the EBDA is marked as block 001, I'd change it to block 002.
Although, I'm not thoroughly sure, what if any, negative
consequences that might have on software. It just seems
reasonable to me to do so.
Me too. ISTM that we should take what e820 says is type 1 (available)
or type 3 (reclaimable) - or what we get from other sources if e820
is not available - and then remove from that list various other things
such as the lowest page starting at 0 (containing the RM interrupt
vectors, the BDA and possibly other things) and any page containing
any part of the EBDA. There may be other things we have to omit from
the available list but then what's left should be safe to use.
What concerns me the most is SMM using memory in that region, if that's
what's going on. Accidental use of that area by software or because
the E820h block is incorrectly marked could mean that the PS/2 BIOS
emulation for USB keyboard or mice gets blown out.
I suppose that if the BIOS uses the EBDA as a small (and from the only
memory map I have seen it was very small) mouse packet buffer then the SMM
code may well also write mouse data to the same part of the EBDA. Wouldn't
any bytes from the keyboard be put in the small BDA buffer?
Post by Rod Pemberton
What if the SMM is
emulating IDE access for a SATA drive and caching disk data there? If
that gets blown out, does some data on the drive get trashed? I.e.,
scary if they're doing that ...
I don't know what that would do but where the sector sizes are the same
there may not be much need for caching of that sort because the sectors
could be transferred directly, i.e. read a 512-byte sector from a SATA HDD
in IDE mode and you still get a 512-byte block. Even where a disk has 4k
sectors the disk or drive can make them appear as 512-byte blocks. So the
problem you mention of caching in that space may not arise.

James
Rod Pemberton
2015-02-13 01:02:15 UTC
Permalink
On Wed, 11 Feb 2015 05:25:52 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Sat, 07 Feb 2015 11:56:04 -0500, James Harris
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines seem
automatically to omit it from their e820 reports but not all do.
There were machines were it wasn't in Int 12h.
Was there some where EBDA was not in the E820h map too? ...
Yes, I've got one here. A Dell Latitude XP laptop which reports
in e820 that all of the low 640k is of type 1 but also reports
a 1k EBDA at 639k.
I'm trying to clarify what you're saying by "omit" from "e820":

"Most machines seem [to] automatically omit [the EBDA]
from their e820 reports ..."

Where is it omitted? That could mean omitted in two places:

1) the memory used for the EBDA region is not always subtracted
from the the reported e820 block for base memory from 0KB to 640KB

2) the EBDA block is completely omitted from the entire E820
report or memory map, i.e., no range report in e820 memory map
for the EBDA as a memory block, completely skipped

From the most recent statement, I think you're saying the
Dell Latitude XP does #1. I was asking if you were saying
that it does #2. IIRC, 30% or 40% of the reported machines
do #1 ...
Post by James Harris
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
For a "safe" replacement version of E820h, I'd do a few things.
If the EBDA is missing from E820h, I'd insert a block for it.
If the EBDA is marked as block 001, I'd change it to block 002.
Although, I'm not thoroughly sure, what if any, negative
consequences that might have on software. It just seems
reasonable to me to do so.
Me too. ISTM that we should take what e820 says is type 1 (available)
or type 3 (reclaimable) - or what we get from other sources if e820
is not available - and then remove from that list various other things
such as the lowest page starting at 0 (containing the RM interrupt
vectors, the BDA and possibly other things) and any page containing
any part of the EBDA. There may be other things we have to omit from
the available list but then what's left should be safe to use.
What concerns me the most is SMM using memory in that region, if that's
what's going on. Accidental use of that area by software or because
the E820h block is incorrectly marked could mean that the PS/2 BIOS
emulation for USB keyboard or mice gets blown out.
I suppose that if the BIOS uses the EBDA as a small (and from the only
memory map I have seen it was very small) mouse packet buffer then the
SMM code may well also write mouse data to the same part of the EBDA.
...
Post by James Harris
Wouldn't any bytes from the keyboard be put in the small BDA buffer?
I would assume so.

But, at this point, we don't know what SMM puts into the space between
the end of the EBDA and 640KB, for the machines that seem to have
allocated some extra space there.
Post by James Harris
Post by Rod Pemberton
What if the SMM is
emulating IDE access for a SATA drive and caching disk data there? If
that gets blown out, does some data on the drive get trashed? I.e.,
scary if they're doing that ...
I don't know what that would do but where the sector sizes are the same
there may not be much need for caching of that sort because the sectors
could be transferred directly, i.e. read a 512-byte sector from a SATA
HDD in IDE mode and you still get a 512-byte block. Even where a disk
has 4k sectors the disk or drive can make them appear as 512-byte blocks.
So the problem you mention of caching in that space may not arise.
I was thinking SMM ramdisk for one sector.

The point was we don't know what SMM puts there. It could be code.
It could be data. If it's relevant to proper operation of the computer
and is corrupted, then that could cause crashes, expose secure data,
allow for a breach, corrupt data, etc.

If it's SMM mode only data that's stored there, I'd be concerned too.
IIRC, SMM needs to save/restore the processor state ...

E.g., I had to make my keyboard driver a bit more fault tolerant
because of some issues. If the SMM caches keyboard data there,
and it's corrupted, and it's not something my driver was designed
to handle, then lockup, crash, etc. Similarly, if any disk data
is stored there, e.g., before SMM emulates a memory DMA controller
move, and that data is corrupted, then what?

At this point, too much is unknown from my perspective. So, it's
mostly worst case scenario speculation.


Rod Pemberton
James Harris
2015-02-13 08:49:29 UTC
Permalink
Post by Rod Pemberton
On Wed, 11 Feb 2015 05:25:52 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Sat, 07 Feb 2015 11:56:04 -0500, James Harris
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines seem
automatically to omit it from their e820 reports but not all do.
There were machines were it wasn't in Int 12h.
Was there some where EBDA was not in the E820h map too? ...
Yes, I've got one here. A Dell Latitude XP laptop which reports
in e820 that all of the low 640k is of type 1 but also reports
a 1k EBDA at 639k.
"Most machines seem [to] automatically omit [the EBDA]
from their e820 reports ..."
Originally: "automatically to omit" - no split infinitive. ;-) I.e. no
edit needed. :-)
Post by Rod Pemberton
1) the memory used for the EBDA region is not always subtracted
from the the reported e820 block for base memory from 0KB to 640KB
2) the EBDA block is completely omitted from the entire E820
report or memory map, i.e., no range report in e820 memory map
for the EBDA as a memory block, completely skipped
From the most recent statement, I think you're saying the
Dell Latitude XP does #1. I was asking if you were saying
that it does #2. IIRC, 30% or 40% of the reported machines
do #1 ...
Perhaps I should have said we might need to omit it from our maps of
*available* space, i.e. the map or maps that we build up from what e820
reports as type 1 (and possibly type 3). The Dell Latitude XP laptop
reports the whole lower 640k as type 1. Rather than taking that as
gospel it looks as though an OS ought to subtract the EBDA space that is
used on that machine.

IME most machines report the EBDA area as e820 type 2 but not that
particular laptop.

In other words, not all BIOSes subtract/omit the EBDA from their e820
reports of available memory (what you have as #1). As there might be
live data in there ISTM that *we* should be sure to subtract/omit that
space from any maps we make of available RAM.

Sorry it wasn't clearer before. I hope that makes more sense now as I
may have limited access to Usenet for the next few weeks so I am not
sure when I'll be able to reply further.

...
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
What if the SMM is
emulating IDE access for a SATA drive and caching disk data there?
If
that gets blown out, does some data on the drive get trashed? I.e.,
scary if they're doing that ...
I don't know what that would do but where the sector sizes are the same
there may not be much need for caching of that sort because the sectors
could be transferred directly, i.e. read a 512-byte sector from a SATA
HDD in IDE mode and you still get a 512-byte block. Even where a disk
has 4k sectors the disk or drive can make them appear as 512-byte blocks.
So the problem you mention of caching in that space may not arise.
I was thinking SMM ramdisk for one sector.
The point was we don't know what SMM puts there. It could be code.
It could be data. If it's relevant to proper operation of the
computer
and is corrupted, then that could cause crashes, expose secure data,
allow for a breach, corrupt data, etc.
I don't know for sure but I wouldn't worry too much. AIUI SMM can, if
necessary, be allocated its own RAM space completely hidden from us. We
in non-SMM mode would have no access to that so if the BIOS needed the
space for use when in SMM mode it could allocate such "SMM-private"
space. Alternatively if it wanted to use memory that *would* be visible
to an OS it could use the e820 report to let the OS know that that range
was not available for the OS to use.

James
Rod Pemberton
2015-02-13 12:27:28 UTC
Permalink
On Fri, 13 Feb 2015 03:49:29 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Wed, 11 Feb 2015 05:25:52 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Sat, 07 Feb 2015 11:56:04 -0500, James Harris
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines seem
automatically to omit it from their e820 reports but not all do.
There were machines were it wasn't in Int 12h.
Was there some where EBDA was not in the E820h map too? ...
Yes, I've got one here. A Dell Latitude XP laptop which reports
in e820 that all of the low 640k is of type 1 but also reports
a 1k EBDA at 639k.
"Most machines seem [to] automatically omit [the EBDA]
from their e820 reports ..."
Originally: "automatically to omit" - no split infinitive. ;-)
I.e. no edit needed. :-)
Sorry, I dropped your "to" when replying, but "seem automatically"
is very awkward, at least to me, if not incorrect in some manner.
ISTM, there is something missing, is in an incorrect location, or
is perhaps extra. Moving the "to" before "automatically" fixes it.
Removing both the "to" and "seem" fixes it. Switching "automatically"
and "seem" fixes it. Maybe, that's just American English? ...
Clearly, I'm excluding your combination, but since it's been decades
since I diagrammed sentences, I'm not sure as to why, or as to what
English issue this might represent.
Post by James Harris
Post by Rod Pemberton
1) the memory used for the EBDA region is not always subtracted
from the the reported e820 block for base memory from 0KB to 640KB
2) the EBDA block is completely omitted from the entire E820
report or memory map, i.e., no range report in e820 memory map
for the EBDA as a memory block, completely skipped
From the most recent statement, I think you're saying the
Dell Latitude XP does #1. I was asking if you were saying
that it does #2. IIRC, 30% or 40% of the reported machines
do #1 ...
Perhaps I should have said we might need to omit it from our maps of
*available* space, i.e. the map or maps that we build up from what e820
reports as type 1 (and possibly type 3). The Dell Latitude XP laptop
reports the whole lower 640k as type 1. Rather than taking that as
gospel it looks as though an OS ought to subtract the EBDA space that is
used on that machine.
Yes, but how do you conclude that the base range hasn't already
subtracted it? Do you assume that if the base is 640KB that the
EBDA hasn't been subtracted? As you found, some machines seem
to allocate additional space. If a machine allocates additional
space for the base but NOT the EBDA, the base won't be 640KB and
will still need to have EBDA subtracted.
Post by James Harris
IME most machines report the EBDA area as e820 type 2 but not that
particular laptop.
What do you mean by that?

1) the EBDA area is reported as type 1 for the Dell, or some type
other than type 2, perhaps 3 or 4 ...
2) the EBDA area is not listed in the e820 memory map report

I.e., is the EBDA reported as a different type, or simply not reported?
Post by James Harris
In other words, not all BIOSes subtract/omit the EBDA from their e820
reports of available memory (what you have as #1). As there might be
live data in there ISTM that *we* should be sure to subtract/omit that
space from any maps we make of available RAM.
Yes.
Post by James Harris
Sorry it wasn't clearer before. I hope that makes more sense now as I
may have limited access to Usenet for the next few weeks so I am not
sure when I'll be able to reply further.
I'm still not 100% clear. Basically, you presented same abiguity.
This is the new #1 and #2 above. I'm assuming you mean #1 yet again. ;-)

If the EBDA is not reported in the e820 map, then we also have the
issue of inserting it into the map.

Did you post an E820 map for this machine at some point in time?

That would be much easier than me "harassing" you for the info ...


Rod Pemberton
James Harris
2015-03-30 17:25:11 UTC
Permalink
Post by Rod Pemberton
On Fri, 13 Feb 2015 03:49:29 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Wed, 11 Feb 2015 05:25:52 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Sat, 07 Feb 2015 11:56:04 -0500, James Harris
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines seem
automatically to omit it from their e820 reports but not all do.
There were machines were it wasn't in Int 12h.
Was there some where EBDA was not in the E820h map too? ...
Yes, I've got one here. A Dell Latitude XP laptop which reports
in e820 that all of the low 640k is of type 1 but also reports
a 1k EBDA at 639k.
"Most machines seem [to] automatically omit [the EBDA]
from their e820 reports ..."
Originally: "automatically to omit" - no split infinitive. ;-)
I.e. no edit needed. :-)
Sorry, I dropped your "to" when replying, but "seem automatically"
is very awkward, at least to me, if not incorrect in some manner.
ISTM, there is something missing, is in an incorrect location, or
is perhaps extra. Moving the "to" before "automatically" fixes it.
Removing both the "to" and "seem" fixes it. Switching "automatically"
and "seem" fixes it. Maybe, that's just American English? ...
Clearly, I'm excluding your combination, but since it's been decades
since I diagrammed sentences, I'm not sure as to why, or as to what
English issue this might represent.
You may have already seen http://en.wikipedia.org/wiki/Split_infinitive.
As I say, I don't see a problem with splitting them or not splitting
them.
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
1) the memory used for the EBDA region is not always subtracted
from the the reported e820 block for base memory from 0KB to 640KB
2) the EBDA block is completely omitted from the entire E820
report or memory map, i.e., no range report in e820 memory map
for the EBDA as a memory block, completely skipped
From the most recent statement, I think you're saying the
Dell Latitude XP does #1. I was asking if you were saying
that it does #2. IIRC, 30% or 40% of the reported machines
do #1 ...
Perhaps I should have said we might need to omit it from our maps of
*available* space, i.e. the map or maps that we build up from what e820
reports as type 1 (and possibly type 3). The Dell Latitude XP laptop
reports the whole lower 640k as type 1. Rather than taking that as
gospel it looks as though an OS ought to subtract the EBDA space that is
used on that machine.
Yes, but how do you conclude that the base range hasn't already
subtracted it? Do you assume that if the base is 640KB that the
EBDA hasn't been subtracted? As you found, some machines seem
to allocate additional space. If a machine allocates additional
space for the base but NOT the EBDA, the base won't be 640KB and
will still need to have EBDA subtracted.
IIUC, by comparing int 0x15-e820 with int 0x15-c1.

I don't have my test machines here but IIRC the scenarios are

1. Machine's int 0x15-e820 reports 0 to 639k as type 1, and the next 1k
as type 2. Its int 0x15-c1 reports an EBDA at 639k, essentially agreeing
with the e820 report. If the OS rounds to 4k boundaries then it would
say that 4k to 636k is available for use.

2. Machine's int 0x15-e820 reports 0 to 640k as type 1. Its int 0x15-c1
reports an EBDA at 639k, i.e. overlapping what it reports as type 1.
Again, if the OS rounds to 4k boundaries it would say that 4k to 636k is
available for use, as in scenario 1.

3. Machine's int 0x15-e820 reports 0 to 640k as type 1. Its int 0x15-c1
returns carry set indicating not supported so no EBDA. Here the same OS
would say that 4k to 640k is available for use.

So I think the answer to what you asked me is that int 0x15-c1's report
can be used to subtract from what int 0x15-e820 reports, if necessary,
but I am not really sure what you meant. If I haven't answered you fully
can you give a scenario that I missed?
Post by Rod Pemberton
Post by James Harris
IME most machines report the EBDA area as e820 type 2 but not that
particular laptop.
What do you mean by that?
1) the EBDA area is reported as type 1 for the Dell, or some type
other than type 2, perhaps 3 or 4 ...
2) the EBDA area is not listed in the e820 memory map report
I.e., is the EBDA reported as a different type, or simply not
reported?
IIRC most machines report the EBDA as type 2 but the Dell (incorrectly?)
included the space set aside for EBDA memory in its type 1 report. I
think that is what you have as option 1.
Post by Rod Pemberton
Post by James Harris
In other words, not all BIOSes subtract/omit the EBDA from their e820
reports of available memory (what you have as #1). As there might be
live data in there ISTM that *we* should be sure to subtract/omit that
space from any maps we make of available RAM.
Yes.
Post by James Harris
Sorry it wasn't clearer before. I hope that makes more sense now as I
may have limited access to Usenet for the next few weeks so I am not
sure when I'll be able to reply further.
Good. I did say I would be out of communcation for a while.
Post by Rod Pemberton
I'm still not 100% clear. Basically, you presented same abiguity.
This is the new #1 and #2 above. I'm assuming you mean #1 yet again.
;-)
If the EBDA is not reported in the e820 map, then we also have the
issue of inserting it into the map.
Is there a reason for placing unusable memory in the OS's map? Wouldn't
it be enough for the OS to know of all *available* memory (plus all type
3 and type 4 spaces)?
Post by Rod Pemberton
Did you post an E820 map for this machine at some point in time?
That would be much easier than me "harassing" you for the info ...
No worries, I am not harassed. I don't recall posting a map of it. From
memory, though, I think it reports just two types:

1. 0 to 640k as type 1
2. something else - probably ROM - as type 2.
3. 1M upwards to somewhere as type 1.

Sorry I cannot confirm that. Is the above info enough?

James
Steve
2015-04-01 14:25:32 UTC
Permalink
Post by James Harris
Post by Rod Pemberton
Did you post an E820 map for this machine at some point in time?
That would be much easier than me "harassing" you for the info ...
No worries, I am not harassed. I don't recall posting a map of it. From
1. 0 to 640k as type 1
2. something else - probably ROM - as type 2.
3. 1M upwards to somewhere as type 1.
Sorry I cannot confirm that. Is the above info enough?
Hi,

Would some E820 maps from some older systems help any?
I could do at least a Pentium and a P-III for instance. Others
if wanted. If your e-mail is valid I could run some tests and
collect some old data and send it to you in a day or so.

Regards,

Steve N.
James Harris
2015-04-01 19:44:19 UTC
Permalink
Post by Steve
Post by James Harris
Post by Rod Pemberton
Did you post an E820 map for this machine at some point in time?
That would be much easier than me "harassing" you for the info ...
No worries, I am not harassed. I don't recall posting a map of it. From
1. 0 to 640k as type 1
2. something else - probably ROM - as type 2.
3. 1M upwards to somewhere as type 1.
Correction: that machine's report does not include any entry for type 2.
It only includes the two rows for type 1.
Post by Steve
Post by James Harris
Sorry I cannot confirm that. Is the above info enough?
Hi,
Would some E820 maps from some older systems help any?
I could do at least a Pentium and a P-III for instance. Others
if wanted. If your e-mail is valid I could run some tests and
collect some old data and send it to you in a day or so.
I don't have a need for such things just now but Rod or someone else
may. Your Pentium machine may be a good test bench in the future though.
Hopefully it will keep working.

James
Rod Pemberton
2015-04-02 05:49:27 UTC
Permalink
On Mon, 30 Mar 2015 13:25:11 -0400, James Harris
Post by James Harris
Post by Rod Pemberton
On Fri, 13 Feb 2015 03:49:29 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Wed, 11 Feb 2015 05:25:52 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Sat, 07 Feb 2015 11:56:04 -0500, James Harris
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines seem
automatically to omit it from their e820 reports but not all do.
There were machines were it wasn't in Int 12h.
Was there some where EBDA was not in the E820h map too? ...
Yes, I've got one here. A Dell Latitude XP laptop which reports
in e820 that all of the low 640k is of type 1 but also reports
a 1k EBDA at 639k.
"Most machines seem [to] automatically omit [the EBDA]
from their e820 reports ..."
Originally: "automatically to omit" - no split infinitive. ;-)
I.e. no edit needed. :-)
Sorry, I dropped your "to" when replying, but "seem automatically"
is very awkward, at least to me, if not incorrect in some manner.
ISTM, there is something missing, is in an incorrect location, or
is perhaps extra. Moving the "to" before "automatically" fixes it.
Removing both the "to" and "seem" fixes it. Switching "automatically"
and "seem" fixes it. Maybe, that's just American English? ...
Clearly, I'm excluding your combination, but since it's been decades
since I diagrammed sentences, I'm not sure as to why, or as to what
English issue this might represent.
You may have already seen http://en.wikipedia.org/wiki/Split_infinitive.
As I say, I don't see a problem with splitting them or not splitting
them.
We still seem to be discussing two different issues.
So, I'm not sure that you even read my reply above ...

You seem to be stuck on the splitting or not splitting
of the infinitive "to omit" with "automatically". The
issue I was taking cause with and corrected was the use
of "seem automatically," which I found to be awkward,
if not incorrect. I now believe it to be an incorrect
usage of an adjective after a verb.

I had to look this up since it's been so long. Apparently,
"automatically" is an adjective and "seem" is an intransitive
verb. Normally, an adverb follows an intransitive verb.
However, an adjective can follow an intransitive verb, if
the adjective describes the subject of the sentence. That's
were the problem arises.

In this case, the adjective describing the noun would be
"automatically" being used to describe the noun "machine".
Apparently, this can only be valid usage when the adjective-noun
combination form is also valid usage: "automatically machine".
Unfortunately, that adjective-noun combination makes no sense
whatsoever in English and is therefore incorrect English usage.

At least, that's true AFAICT from what little I read ...
Post by James Harris
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
Post by James Harris
[...]
Ok, I've reviewed the E820h memory maps posted to a.o.d.,
yet again ... So, let's rewind to this statement of yours
Post by James Harris
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines
seem automatically [sic] to omit it from their e820 reports
but not all do.
I have to disagree with the statement that most machines
remove the EBDA memory size from the E820h reports based
on the info below from the a.o.d. memory map posts.

The EBDA is in the E820 map for 9 of 11, not in the map
for 1, and unknown for 1 machine. The EBDA where known
is marked type 2 except for one machine with type 1.

Int 12h and BDA 0413h sizes are reduced by the EBDA size
or 6 of 11, not reduced for 2, and unknown for 3 machines.

CMOS 15-16 is not reduced by the EBDA size for 8 of 11,
and unknown for 3 machines.

I also included info for 3 emulators under Linux
at the bottom which is not tallied above. The
remainder of the info is available from the links
posted earlier in the thread.

ABIT SM5-A (from Rod Pemberton)
-EBDA is in E820 map:
000000000009FC00:0000000000000400:001
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

GigaByte GA MA78LM-S2H F3 (from Rod Pemberton)
-EBDA not in E820 map
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

Intel AA 719944-207 (from Rod Pemberton)
-EBDA is in E820 map:
000000000009F800:0000000000000800:002
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

MSI K9N Neo-F (from Rod Pemberton)
-EBDA is in E820 map:
000000000009FC00:0000000000000400:002
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

P-III system from Steve N. using Ben Lunt's MemE820Info
-EBDA is in E820 map:
(0 2): 0x000009FC00 1024 ( 0.00) type 2 (reserved)
-unknown effects on Int 12h and BDA 0413h
-unknown effects on CMOS 15-16

unknown machine from wolfgang
-EBDA is in E820 map:
01 0009_fc00 0000_0400 2 yes no
-unknown effects on Int 12h and BDA 0413h
-unknown effects on CMOS 15-16

unknown machine from CN
-EBDA not in E820 map
-unknown effects on Int 12h and BDA 0413h
-unknown effects on CMOS 15-16

Hewlett-Packard from Ben Lunt
-EBDA is in E820 map:
000000000009FC00:0000000000000400 type = 2
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

machine with American MegaTrends BIOS from Ben Lunt
-no E820 map
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

machine with Award BIOS from Ben Lunt
-EBDA is in E820 map:
000000000009FC00:0000000000000400 type = 2
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

machine with Phoenix BIOS from Ben Lunt
-EBDA is in E820 map:
000000000009F400:0000000000000C00 type = 2
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

Linux DOSBox (from Rod Pemberton)
-no E820h map
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

Linux dosemu w/MS-DOS v7.10 (from Rod Pemberton)
-EBDA not in E820 map
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA

Linux QEMU w/MS-DOS v7.10 (from Rod Pemberton)
-EBDA is in E820 map:
000000000009FC00:0000000000000400:002
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
Post by James Harris
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
1) the memory used for the EBDA region is not always subtracted
from the the reported e820 block for base memory from 0KB to 640KB
2) the EBDA block is completely omitted from the entire E820
report or memory map, i.e., no range report in e820 memory map
for the EBDA as a memory block, completely skipped
From the most recent statement, I think you're saying the
Dell Latitude XP does #1. I was asking if you were saying
that it does #2. IIRC, 30% or 40% of the reported machines
do #1 ...
From your "from memory" reply below and clarification post, it's
definately #2, and possibly #1 *if* the machine has an EBDA.
Post by James Harris
Post by Rod Pemberton
Post by James Harris
Perhaps I should have said we might need to omit it from our maps of
*available* space, i.e. the map or maps that we build up from what
e820 reports as type 1 (and possibly type 3). The Dell Latitude XP
laptop reports the whole lower 640k as type 1. Rather than taking
that as gospel it looks as though an OS ought to subtract the EBDA
space that is used on that machine.
Yes, but how do you conclude that the base range hasn't already
subtracted it? Do you assume that if the base is 640KB that the
EBDA hasn't been subtracted? As you found, some machines seem
to allocate additional space. If a machine allocates additional
space for the base but NOT the EBDA, the base won't be 640KB and
will still need to have EBDA subtracted.
IIUC, by comparing int 0x15-e820 with int 0x15-c1.
That could be a good indicator of the presence or absence
of the EBDA. If an EBDA (or XBDA) is present, there should
also be a length byte at the start.

I'd wonder how widely supported that function call is.
E.g., if BIOS calls for the A20 which came from the PS/2
aren't widely supported, is it safe to assume that
this PS/2 call is widely supported? It seems to be an
easy call to implement, which may increase the probability
of it's availability.
Post by James Harris
IIUC
FYI, I was asking how to determine whether the EBDA had
been subtracted or not from the low memory E820h entry
without knowing if the EBDA was present on that machine.
I.e., does 640KB mean no EBDA, or does 640KB mean the EBDA
still needs to be subtracted?
Post by James Harris
I don't have my test machines here but IIRC the scenarios are
1. Machine's int 0x15-e820 reports 0 to 639k as type 1, and the next 1k
as type 2. Its int 0x15-c1 reports an EBDA at 639k, essentially agreeing
with the e820 report. If the OS rounds to 4k boundaries then it would
say that 4k to 636k is available for use.
2. Machine's int 0x15-e820 reports 0 to 640k as type 1. Its int 0x15-c1
reports an EBDA at 639k, i.e. overlapping what it reports as type 1.
Again, if the OS rounds to 4k boundaries it would say that 4k to 636k is
available for use, as in scenario 1.
3. Machine's int 0x15-e820 reports 0 to 640k as type 1. Its int 0x15-c1
returns carry set indicating not supported so no EBDA. Here the same OS
would say that 4k to 640k is available for use.
So I think the answer to what you asked me is that int 0x15-c1's report
can be used to subtract from what int 0x15-e820 reports, if necessary,
but I am not really sure what you meant. If I haven't answered you fully
can you give a scenario that I missed?
That's fine.

By using Int 15h, AH=C1h, you found an alternate solution
to the issue of not knowing if the EBDA is present and
accounted for or not.
Post by James Harris
Post by Rod Pemberton
Post by James Harris
IME most machines report the EBDA area as e820 type 2 but not that
particular laptop.
What do you mean by that?
1) the EBDA area is reported as type 1 for the Dell, or some type
other than type 2, perhaps 3 or 4 ...
2) the EBDA area is not listed in the e820 memory map report
I.e., is the EBDA reported as a different type, or simply not
reported?
[...]
Your "from memory" E820 map clarification indicates "2)" here.
Post by James Harris
IIRC most machines report the EBDA as type 2
Yes.
Post by James Harris
but the Dell (incorrectly?)
included the space set aside for EBDA memory in its type 1 report.
I think that is what you have as option 1.
Isn't it true that some machines don't have an EBDA? I thought so ...
Therefore, I'm not sure that the claim that the EBDA was *included*
in the low memory type 1 report is always a correct assumption.
The EBDA could simply be not present, i.e., 640K should be valid for
some old machines. Your "from memory" memory map seems to indicate
that. Technically, one of my machines, one of Ben's machines, and
CN's new machine are that way. I thought one of wolfgang's was that
way too, but I couldn't locate that map.
Post by James Harris
Post by Rod Pemberton
I'm still not 100% clear. Basically, you presented same abiguity.
This is the new #1 and #2 above. I'm assuming you mean #1 yet again.
;-)
If the EBDA is not reported in the e820 map, then we also have the
issue of inserting it into the map.
Is there a reason for placing unusable memory in the OS's map?
Wouldn't it be enough for the OS to know of all *available* memory
(plus all type 3 and type 4 spaces)?
What I suggested would *reduce* available memory below 640K by
the size of the EBDA. E.g., Int 12h says 639K, so we have an
EBDA consuming space. The E820h map has no EBDA line and shows
the low memory E820h entry with a full 640K. We know the full
640K isn't available because of Int 12h/BDA 0413h. So, we must
correct the map by subtracting it. I.e., we need to fix the
640K E820h entry and optionally insert the EBDA type 2 entry.

I'm also assuming that the E820h map should be corrected prior to
use of E820h by the bootloader or the OS memory manager, etc.
Post by James Harris
Post by Rod Pemberton
Did you post an E820 map for this machine at some point in time?
That would be much easier than me "harassing" you for the info ...
No worries, I am not harassed. I don't recall posting a map of it. From
1. 0 to 640k as type 1
2. something else - probably ROM - as type 2.
3. 1M upwards to somewhere as type 1.
Sorry I cannot confirm that. Is the above info enough?
That (and your correction post) "from memory" info indicates
the EBDA is not in the E820h map. If EBDA is not present,
then 640K is correct. If EBDA is present, then 640K is wrong.
As you noted, Int 15h,AH=C1h should work fine to detect it's
presence.


Rod Pemberton

--
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.
James Harris
2015-04-04 15:50:11 UTC
Permalink
Post by Rod Pemberton
On Mon, 30 Mar 2015 13:25:11 -0400, James Harris
Post by James Harris
Post by Rod Pemberton
On Fri, 13 Feb 2015 03:49:29 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Wed, 11 Feb 2015 05:25:52 -0500, James Harris
Post by James Harris
Post by Rod Pemberton
On Sat, 07 Feb 2015 11:56:04 -0500, James Harris
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines seem
automatically to omit it from their e820 reports but not all do.
There were machines were it wasn't in Int 12h.
Was there some where EBDA was not in the E820h map too? ...
Yes, I've got one here. A Dell Latitude XP laptop which reports
in e820 that all of the low 640k is of type 1 but also reports
a 1k EBDA at 639k.
"Most machines seem [to] automatically omit [the EBDA]
from their e820 reports ..."
Originally: "automatically to omit" - no split infinitive. ;-)
I.e. no edit needed. :-)
Sorry, I dropped your "to" when replying, but "seem automatically"
is very awkward, at least to me, if not incorrect in some manner.
ISTM, there is something missing, is in an incorrect location, or
is perhaps extra. Moving the "to" before "automatically" fixes it.
Removing both the "to" and "seem" fixes it. Switching
"automatically"
and "seem" fixes it. Maybe, that's just American English? ...
Clearly, I'm excluding your combination, but since it's been decades
since I diagrammed sentences, I'm not sure as to why, or as to what
English issue this might represent.
You may have already seen
http://en.wikipedia.org/wiki/Split_infinitive.
As I say, I don't see a problem with splitting them or not splitting
them.
We still seem to be discussing two different issues.
Not for the first time. :-(
Post by Rod Pemberton
So, I'm not sure that you even read my reply above ...
Of course I read it. Though it seems I did not understand the point you
had in mind.
Post by Rod Pemberton
You seem to be stuck on the splitting or not splitting
of the infinitive "to omit" with "automatically". The
issue I was taking cause with and corrected was the use
of "seem automatically," which I found to be awkward,
if not incorrect. I now believe it to be an incorrect
usage of an adjective after a verb.
I had to look this up since it's been so long. Apparently,
"automatically" is an adjective and "seem" is an intransitive
verb.
Are you sure? I would have thought that "automatically" was an adverb.

I had to look the rest up. Apparently a *transitive* verb takes an
object, as in

He buys food.
He is going to buy food.

The verb forms "buys" and "to buy" apply to the object "food" in each
case so are transitive.

I found that the case you are talking about, an *in*transitive verb is
one that does not have an object, as in

He sneezed.
He is going to sneeze.

Here, "sneezed" or "to sneeze" apply to no object and, hence, are
intransitive.
Post by Rod Pemberton
Normally, an adverb follows an intransitive verb.
As in the following where "loudly" describes the sneeze?

He sneezed loudly.
Post by Rod Pemberton
However, an adjective can follow an intransitive verb, if
the adjective describes the subject of the sentence. That's
were the problem arises.
Can you give a short example of an adjective following an instransitive
verb where the adjective describes the subject of the sentence? I can
only think of examples where the adjective precedes the noun such as

Little Sally sneezed.

You could not put the adjective "little" after "sneezed" or it would not
make the same sense.
Post by Rod Pemberton
In this case, the adjective describing the noun would be
"automatically" being used to describe the noun "machine".
I am not sure if this is what you mean but the "automatically" was not
intended to describe the machines. It was meant to describe the "to
omit" as in

Some PCs seem automatically to omit the EBDA.

If I wanted to describe the machines in a similar way I would have
called them "automatic" rather than used "automatically" which, AIUI, is
an adverb. An adjective form would be

Some automatic machines seem to omit the EBDA.

Or combining an adjective qualification of the machine with another
adverbial qualification of the verb "to omit" could lead to.

Some automatic machines seem automatically to omit the EBDA.

That's not what I said but it illustrates the use of adjective and
adverb.
Post by Rod Pemberton
Apparently, this can only be valid usage when the adjective-noun
combination form is also valid usage: "automatically machine".
Unfortunately, that adjective-noun combination makes no sense
whatsoever in English and is therefore incorrect English usage.
At least, that's true AFAICT from what little I read ...
ISTM that you may have been misled by thinking that "automatically" was
an adjective but I think it is an adverb and describes the verb.

Interesting discussion, though! I had no idea what intransitive meant
before.

James
James Harris
2015-04-04 16:24:26 UTC
Permalink
Post by Rod Pemberton
On Mon, 30 Mar 2015 13:25:11 -0400, James Harris
Post by James Harris
Post by Rod Pemberton
On Fri, 13 Feb 2015 03:49:29 -0500, James Harris
...
Post by Rod Pemberton
Ok, I've reviewed the E820h memory maps posted to a.o.d.,
yet again ... So, let's rewind to this statement of yours
Post by James Harris
Post by Rod Pemberton
Post by James Harris
Post by James Harris
I wasn't thinking that we need its content but that if an EBDA
exists we might need to omit its memory from our memory maps
and be sure not to give it out to any programs. Most machines
seem automatically [sic] to omit it from their e820 reports
but not all do.
I have to disagree with the statement that most machines
remove the EBDA memory size from the E820h reports based
on the info below from the a.o.d. memory map posts.
Unfortunate phrasing on my part, I'm afraid. When I mentioned machines
omitting the EBDA from their e820 reports I meant that they omit it from
what they tell us is available. I don't necessarily mean that there is
*no* e820 entry for the EBDA space. I was classing a non-overlapping
type 2 report for the EBDA space as omitting that space. I regard e820
as telling us what memory is available. A type 2 report tells us that a
certain range is not available. There may be a better term than "omit"
for this but it's the one I used.

If a machine tells us that the EBDA space is of e820 type 1 I would say
that it has failed to omit that memory from its report and we need to do
that later. If it tells us that the EBDA space is of type 2 I was
classing it as omitting that space.

Since you have gone to the trouble of showing data on many machines I
will leave that below.
Post by Rod Pemberton
The EBDA is in the E820 map for 9 of 11, not in the map
for 1, and unknown for 1 machine. The EBDA where known
is marked type 2 except for one machine with type 1.
Int 12h and BDA 0413h sizes are reduced by the EBDA size
or 6 of 11, not reduced for 2, and unknown for 3 machines.
CMOS 15-16 is not reduced by the EBDA size for 8 of 11,
and unknown for 3 machines.
FWICR CMOS 15-16 should not omit the EBDA space and should be 640(k) for
most machines and 512(k) for exceptionally old ones; with any other
value meaning corruption or an ancient Amstrad machine.
Post by Rod Pemberton
I also included info for 3 emulators under Linux
at the bottom which is not tallied above. The
remainder of the info is available from the links
posted earlier in the thread.
ABIT SM5-A (from Rod Pemberton)
000000000009FC00:0000000000000400:001
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
GigaByte GA MA78LM-S2H F3 (from Rod Pemberton)
-EBDA not in E820 map
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
Intel AA 719944-207 (from Rod Pemberton)
000000000009F800:0000000000000800:002
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
MSI K9N Neo-F (from Rod Pemberton)
000000000009FC00:0000000000000400:002
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
P-III system from Steve N. using Ben Lunt's MemE820Info
(0 2): 0x000009FC00 1024 ( 0.00) type 2 (reserved)
-unknown effects on Int 12h and BDA 0413h
-unknown effects on CMOS 15-16
unknown machine from wolfgang
01 0009_fc00 0000_0400 2 yes no
-unknown effects on Int 12h and BDA 0413h
-unknown effects on CMOS 15-16
unknown machine from CN
-EBDA not in E820 map
-unknown effects on Int 12h and BDA 0413h
-unknown effects on CMOS 15-16
Hewlett-Packard from Ben Lunt
000000000009FC00:0000000000000400 type = 2
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
machine with American MegaTrends BIOS from Ben Lunt
-no E820 map
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
machine with Award BIOS from Ben Lunt
000000000009FC00:0000000000000400 type = 2
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
machine with Phoenix BIOS from Ben Lunt
000000000009F400:0000000000000C00 type = 2
-Int 12h and BDA 0413h are reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
Linux DOSBox (from Rod Pemberton)
-no E820h map
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
Linux dosemu w/MS-DOS v7.10 (from Rod Pemberton)
-EBDA not in E820 map
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
Linux QEMU w/MS-DOS v7.10 (from Rod Pemberton)
000000000009FC00:0000000000000400:002
-Int 12h and BDA 0413h are not reduced for EBDA
-CMOS 15-16 is not reduced for EBDA
...
Post by Rod Pemberton
Post by James Harris
Post by Rod Pemberton
Post by James Harris
Perhaps I should have said we might need to omit it from our maps of
*available* space, i.e. the map or maps that we build up from what
e820 reports as type 1 (and possibly type 3). The Dell Latitude XP
laptop reports the whole lower 640k as type 1. Rather than taking
that as gospel it looks as though an OS ought to subtract the EBDA
space that is used on that machine.
Yes, but how do you conclude that the base range hasn't already
subtracted it? Do you assume that if the base is 640KB that the
EBDA hasn't been subtracted? As you found, some machines seem
to allocate additional space. If a machine allocates additional
space for the base but NOT the EBDA, the base won't be 640KB and
will still need to have EBDA subtracted.
IIUC, by comparing int 0x15-e820 with int 0x15-c1.
That could be a good indicator of the presence or absence
of the EBDA. If an EBDA (or XBDA) is present, there should
also be a length byte at the start.
I'd wonder how widely supported that function call is.
E.g., if BIOS calls for the A20 which came from the PS/2
aren't widely supported, is it safe to assume that
this PS/2 call is widely supported? It seems to be an
easy call to implement, which may increase the probability
of it's availability.
I guess - and it is just a guess - that it will be supported on any
machine which has or might have an EBDA. Again, I guess it is a call
that IBM added when they defined the presence of the EBDA. That may be
just wishful thinking but it would make our lives easier if we ever got
to run on some very old machines.

...
Post by Rod Pemberton
Post by James Harris
but the Dell (incorrectly?)
included the space set aside for EBDA memory in its type 1 report.
I think that is what you have as option 1.
Isn't it true that some machines don't have an EBDA? I thought so ...
Therefore, I'm not sure that the claim that the EBDA was *included*
in the low memory type 1 report is always a correct assumption.
The EBDA could simply be not present, i.e., 640K should be valid for
some old machines. Your "from memory" memory map seems to indicate
that. Technically, one of my machines, one of Ben's machines, and
CN's new machine are that way. I thought one of wolfgang's was that
way too, but I couldn't locate that map.
AFAICR the Dell's int 0x15-c1 call reported an EBDA at 639k. That
*conflicted* with the e820 report which told me that 0-640k was all of
type 1. Easy solution is to ensure that the top 1k is removed from the
OS's idea of available space.

...
Post by Rod Pemberton
I'm also assuming that the E820h map should be corrected prior to
use of E820h by the bootloader or the OS memory manager, etc.
Me too.

James
Rod Pemberton
2015-02-23 00:18:43 UTC
Permalink
On Sat, 07 Feb 2015 21:27:32 -0500, Rod Pemberton
What concerns me the most is SMM using memory in [the EBDA] region, if
that's what's going on. Accidental use of that area by software or
because the E820h block is incorrectly marked could mean that the PS/2
BIOS emulation for USB keyboard or mice gets blown out. What if the
SMM is emulating IDE access for a SATA drive and caching disk data
there? If that gets blown out, does some data on the drive get trashed?
I.e., scary if they're doing that ...
Apparently, my concern and suspicion is justified, yet again ... :-D

Although, it wasn't for SMM, but it is in regards to hard drive access.

I ran across this which says some early, EBDA-unaware OSes trash the
EBDA memory area and that affects the FDPT (Fixed Disk Partition Table):

"Some really old OSes (Xenix circa 1986-7) do not understand the EBDA idea
and clear the memory. For those, the FDPT must be in the BIOS ROM area, or
the OS will destroy it (even when it's at 0:300 in the IVT)."

Apparently, it's from VirtualBox notes on clients' obscure BIOS usage:
http://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/PC/BIOS/notes.txt

So, that's another file to add to the collection of BIOS links.


Rod Pemberton
--
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.
JJ
2015-02-06 03:16:07 UTC
Permalink
Post by James Harris
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
But that 16-bit word was originally used as a port address for a potential
LPT4. Comparing the two sources above and RBIL there is some disagreement
over when the meaning of those two bytes changed so I thought a better way
to detect the presence of an EBDA might be to add the apparent EBDA length
in kbytes (specified in its first two bytes) to its address and see if it
came to 640k.
http://stanislavs.org/helppc/ebda.html
I just tried that test on eight machines. On seven of them the calculation
worked out: the address and length added up to 640k (and the EBDA was 1k in
size in each case). But on one of them the EBDA was at 636k and of length 3k
(according to the values read). This means it ended at 639k rather than
640k.
* I thought you might find it interesting
* I thought you might have some ideas as to what follows the EBDA in the
last 1024 bytes on that odd machine (unimportant, just of interest)
* I wondered if you had some better way to tell whether BDA offset 0x0e
contains an EBDA paragraph number or not. I could just assume that that's
what those bytes hold as the EBDA pointer has been its use for a long time
but perhaps there is a better way to check.
Any thoughts?
James
This is just my thoughts...

According to this Wikipedia section:

<http://en.wikipedia.org/wiki/IBM_Personal_System/2#Interface>

{quote}
Its primary use was to add a new buffer area for the dedicated mouse port.
{quote}

i.e. the PS/2 mouse port.

So, if a PS/2 mouse is supported in a system, so does EBDA and the value at
40h:0Eh should mean the EBDA segment instead of LPT4 port. This means that
the system is either a PS/2 system or a newer non-PS/2 system. Some newer
systems that save PS/2 mouse port function in its chipset but doesn't expose
the port connector will still have EBDA. It's is a similar case of micro
motherboards that only expose the IDE primary channel connector without
exposing the secondary channel due to insufficient board space.

As for distinguishing between old systems without PS/2 mouse port support,
and newer systems with PS/2 mouse port support, I think detecting the
presence of PS/2 mouse port should suffice. e.g. via Int 15h vector and Int
15h AX=C2xxh.


But there are several things that I don't really know what would happen if a
fully compliant PS/2 mouse port addon card (that doesn't convert the PS/2
mouse to USB mouse) is involved.

Do such addon cards exist? For systems that don't have PS/2 mouse port. e.g.
old ISA systems, or newer PCI systems with only USB ports.

What if a old ISA system with 4 LPT ports and without PS/2 port support, is
installed with that addon card? Will its ROM or driver software create EBDA
and overwrite the value at 40h:0Eh?

Are such addon card usable in EFI-only systems?
James Harris
2015-02-06 14:54:25 UTC
Permalink
Post by JJ
Post by James Harris
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
But that 16-bit word was originally used as a port address for a potential
LPT4. Comparing the two sources above and RBIL there is some disagreement
over when the meaning of those two bytes changed so I thought a better way
to detect the presence of an EBDA might be to add the apparent EBDA length
in kbytes (specified in its first two bytes) to its address and see if it
came to 640k.
...
Post by JJ
<http://en.wikipedia.org/wiki/IBM_Personal_System/2#Interface>
{quote}
Its primary use was to add a new buffer area for the dedicated mouse port.
{quote}
i.e. the PS/2 mouse port.
That's interesting. I didn't know that that was what it was for. To quote
the article more fully: "... the PS/2 introduced a new software data area
known as the Extended BIOS Data Area (EBDA). Its primary use was to add a
new buffer area for the dedicated mouse port."
Post by JJ
So, if a PS/2 mouse is supported in a system, so does EBDA and the value at
40h:0Eh should mean the EBDA segment instead of LPT4 port. This means that
the system is either a PS/2 system or a newer non-PS/2 system. Some newer
systems that save PS/2 mouse port function in its chipset but doesn't expose
the port connector will still have EBDA. It's is a similar case of micro
motherboards that only expose the IDE primary channel connector without
exposing the secondary channel due to insufficient board space.
I doubt that the presence or absence of PS/2 mouse functions would be
sufficient to say what BDA location 0x0e pointed at because a PC could
easily need space for an EBDA even if it did not have a PS/2 mouse. AIUI IBM
found the area they had designated as the BDA full and needed somewhere to
store extra variables.

...
Post by JJ
But there are several things that I don't really know what would happen if a
fully compliant PS/2 mouse port addon card (that doesn't convert the PS/2
mouse to USB mouse) is involved.
Do such addon cards exist? For systems that don't have PS/2 mouse port. e.g.
old ISA systems, or newer PCI systems with only USB ports.
What if a old ISA system with 4 LPT ports and without PS/2 port support, is
installed with that addon card? Will its ROM or driver software create EBDA
and overwrite the value at 40h:0Eh?
It would have to be an ISA card with PS/2 mouse driver support. If such a
thing exists I suspect that what it does to the BDA will depend on its
firmware. As a guess I would think most such firmware would overwrite
anything it needed to. The early PC days were not marked by cooperation and
concord!

James
JJ
2015-02-07 08:56:59 UTC
Permalink
Post by James Harris
I doubt that the presence or absence of PS/2 mouse functions would be
sufficient to say what BDA location 0x0e pointed at because a PC could
easily need space for an EBDA even if it did not have a PS/2 mouse. AIUI IBM
found the area they had designated as the BDA full and needed somewhere to
store extra variables.
Well, may be not the mouse. That might be too specific.
I think any PS/2 originated function should be enough for most systems. To
tell that the BIOS use the PS/2 style EBDA.

IMO...

If a BIOS follows the PS/2 method of exposing the EBDA location, it would
support Int 15h AH=C1h (i.e. doesn't return as error) and BDA 0Eh would
point to the EBDA location.

If a BIOS with EBDA doesn't set BDA 0Eh and don't support Int 15h AH=C1h,
its EBDA is guaranteed to be found at the end of the first 640KB of memory -
hinted by BDA 13h. This should be enough to determine the presence of EBDA
at boot time, after cold boot - to filter out viruses occupying memory area
at the end of the first 640KB of memory.

If the BIOS doesn't store it this way, the system will unlikely be able to
run any OS or boot loader because the softwares only know the common way of
how BIOS store its EBDA. They'll think that there's no EBDA. Eventually, the
EBDA would get overwritten and crashes the system. I won't call it an IBM
PC/compatible if that's the case.

Assuming that a BIOS uses the common data structure for its EBDA but doesn't
set BDA 0Eh or support Int 15h AH=C1h, some EBDA field values can be checked
against the ones retrived from interrupt services or directly from hardware.
e.g. hard disk parameter table, floppy drive type, CPU family & stepping,
keyboard ID. The memory area at the end of the first 640KB will need to be
scanned.

And if the EBDA data structure holds no similarity with the common EBDA, and
the BIOS doesn't set BDA 0Eh or support Int 15h AH=C1h, you can find out the
range of the EBDA memory address by setting memory-access hardware
breakpoints and calling all of system information retrieval interrupt
services. This is more like a brute force check because it checks whether a
limited number of memory addresses are accessed by those interrupt services.

Finally, if the system doesn't support hardware breakpoint, you'll have to
accept that the whole memory area at the end of the first 640KB of memory,
is the EBDA, even though it may include the area used by addon card ROMs.
James Harris
2015-02-07 14:47:55 UTC
Permalink
[how to detect whether an EBDA is present, and its start address]
Post by JJ
Post by James Harris
I doubt that the presence or absence of PS/2 mouse functions would be
sufficient to say what BDA location 0x0e pointed at because a PC could
easily need space for an EBDA even if it did not have a PS/2 mouse. AIUI IBM
found the area they had designated as the BDA full and needed somewhere to
store extra variables.
Well, may be not the mouse. That might be too specific.
I think any PS/2 originated function should be enough for most systems. To
tell that the BIOS use the PS/2 style EBDA.
IMO...
If a BIOS follows the PS/2 method of exposing the EBDA location, it would
support Int 15h AH=C1h (i.e. doesn't return as error) and BDA 0Eh would
point to the EBDA location.
That is a *very* good idea. I hadn't noticed that there is a BIOS call for
this. RBIL lists it as "Return EBDA segment address (PS)" where I presume
that the (PS) part means PS/2 (or maybe even also PS/1?).

I just tried the call on nine PCs with CPUs from a 486 to an Intel Atom. The
basic call worked on six of them returning CARRY = 0 and ES = the EBDA
address. On the other three the call returned with CARRY = 1 (even though
the value in ES had the EBDA segment number).

However, that problem flag could be fixed. I essentially stumbled on what to
do. If I set ES to zero before making the int 0x15-c1 call then *all* of the
test machines return CARRY = 0 and ES = the EBDA segment address.

I don't own any machine older than the Dell 486 laptop. For very-old-machine
testing the best I have is Dosbox which emulates a machine with a CPU
somewhere between a 386 and a 486. On Dosbox that call returns CARRY = 1
indicating that the call is not supported and from looking at BDA 0x0e
(which is zero) I suspect that there is no EBDA so the call's result
matches.

Overall, then, this seems to be a solution!
Post by JJ
If a BIOS with EBDA doesn't set BDA 0Eh and don't support Int 15h AH=C1h,
its EBDA is guaranteed to be found at the end of the first 640KB of memory -
hinted by BDA 13h. This should be enough to determine the presence of EBDA
at boot time, after cold boot - to filter out viruses occupying memory area
at the end of the first 640KB of memory.
RBIL labels the call as (PS) which I think means that it is supported only
on PS machines. AIUI the EBDA is present only on PS machines so if the call
is not supported can we not assume that the machine has no EBDA?

James
JJ
2015-02-08 01:49:13 UTC
Permalink
Post by James Harris
That is a *very* good idea. I hadn't noticed that there is a BIOS call for
this. RBIL lists it as "Return EBDA segment address (PS)" where I presume
that the (PS) part means PS/2 (or maybe even also PS/1?).
I thought you already knew that but wanted an alternative for BIOSes that
use its own EBDA specifications. i.e. they don't follow PS/2 style EBDA, or
when PS/2 style EBDA doesn't exist yet.
Post by James Harris
I just tried the call on nine PCs with CPUs from a 486 to an Intel Atom. The
basic call worked on six of them returning CARRY = 0 and ES = the EBDA
address. On the other three the call returned with CARRY = 1 (even though
the value in ES had the EBDA segment number).
However, that problem flag could be fixed. I essentially stumbled on what to
do. If I set ES to zero before making the int 0x15-c1 call then *all* of the
test machines return CARRY = 0 and ES = the EBDA segment address.
Yes, some BIOSes do have minor bugs.
Post by James Harris
I don't own any machine older than the Dell 486 laptop. For very-old-machine
testing the best I have is Dosbox which emulates a machine with a CPU
somewhere between a 386 and a 486. On Dosbox that call returns CARRY = 1
indicating that the call is not supported and from looking at BDA 0x0e
(which is zero) I suspect that there is no EBDA so the call's result
matches.
DosBox uses a 1992 Phoenix BIOS. It's a newer BIOS, since PS/2 was
introduced in 1987. Perhaps you should look by the BIOS release date rather
than CPU type because the CPU is irrelevant for this matter. Possibly BIOSes
between 1988 to 1990. I think three years is enough for BIOS manufacturers
to adopt the PS/2 style EBDA, or partially adopt it.

Virtual PC (2007 SP1) uses 2006 AMI BIOS. VMWare (v5.5.1) uses 2005 Phoenix
BIOS. VirtualBox (v4.1.0), Bochs, and QEMU use their own open source BIOSes
which are likely be designed to work like a newer BIOS (i.e. PS/2 style EBDA
compliant). They unlikely would work on a real machine anyway.

You can use QEMU or Bochs and configure it to use other BIOS. So you might
want to start collecting BIOS files from the net. To start with, there's a
an emulator called PCem whose website provides 3 AMI BIOSes but they're
dated 1992 and 1993. IIRC, there's a website that provide a quite number of
old BIOSes but I can't remember where.
Post by James Harris
RBIL labels the call as (PS) which I think means that it is supported only
on PS machines. AIUI the EBDA is present only on PS machines so if the call
is not supported can we not assume that the machine has no EBDA?
I don't think so. That won't stop BIOS manufacturer to use their own non
PS/2 style EBDA. Just like BIOSes/hardware that use their own custom port
numbers, memory mapped register, and interupt service and/or subservice
number.

As I mentioned before, any BIOS from addon card can add their own data area
onto the top of the first 640KB of memory. These would be their BDA. They
would be adjacent with previous BDA including the system's EBDA, if any.
James Harris
2015-02-11 09:58:54 UTC
Permalink
...
Post by JJ
Post by James Harris
RBIL labels the call as (PS) which I think means that it is supported only
on PS machines. AIUI the EBDA is present only on PS machines so if the call
is not supported can we not assume that the machine has no EBDA?
I don't think so. That won't stop BIOS manufacturer to use their own non
PS/2 style EBDA. Just like BIOSes/hardware that use their own custom port
numbers, memory mapped register, and interupt service and/or subservice
number.
Even if cards allocate their own space in I wouldn't call it an EBDA, just a
memory reservation. The term EBDA seems to have a fixed meaning as a space
for the BIOS to use.
Post by JJ
As I mentioned before, any BIOS from addon card can add their own data area
onto the top of the first 640KB of memory. These would be their BDA. They
would be adjacent with previous BDA including the system's EBDA, if any.
I suppose firmware on cards could set aside memory for their own workspaces
but

* I expect that PCI cards would use 32-bit-addressed space

* wouldn't pre-PCI cards that need a little bit of RAM have their own space,
probably in the c0000 .. dffff range?

If we just assumed that an OS must not use memory between the int 0x12 value
and 640k then the area could be wasted. I have seen with network boot that
it often reserves quite a chunk of memory in that space but AFAIK there
would be nothing in the bootrom reservation that would be needed once the OS
has been loaded into memory. At least, there may be useful info or even
routines there but without there being a standard way that the space can be
laid out we cannot make any use of them. Therefore could we not reuse that
space? From what I have read it seems we do need to preserve the BIOS's
EBDA, though, and probably any of the surrounding area that e820 marks as
type 2.

James
JJ
2015-02-12 00:30:11 UTC
Permalink
Post by James Harris
* I expect that PCI cards would use 32-bit-addressed space
Then you don't need to worry about EBDA presence because any system that
support PCI use newer BIOS, has EBDA. There's no need for a PCI card to use
base memory to store its configuration either, unless it's a standard
component that requires the configuratio be placed into BDA. e.g. COM/LPT
ports, or floppy controller; for system that no longer have them.
Post by James Harris
* wouldn't pre-PCI cards that need a little bit of RAM have their own space,
probably in the c0000 .. dffff range?
Yes, like A000-BFFF video RAM or the EMS frame buffer memory area, but
that's for buffer or user data, not configurations. It can be for
configurations, but it's uncommon. It's like a text mode program in a PC
with VGA display that use segment A000 to store temporary data.

Many cards use BDA reserved field(s) to store their configurations. A card's
manufacturer may decide to store their configuration in a separate block
near any existing EBDA since there was no more available BDA reserved field
that aren't yet used by other BIOS/card manufacturers.
Post by James Harris
If we just assumed that an OS must not use memory between the int 0x12 value
and 640k then the area could be wasted. I have seen with network boot that
it often reserves quite a chunk of memory in that space but AFAIK there
would be nothing in the bootrom reservation that would be needed once the OS
has been loaded into memory. At least, there may be useful info or even
routines there but without there being a standard way that the space can be
laid out we cannot make any use of them. Therefore could we not reuse that
space? From what I have read it seems we do need to preserve the BIOS's
EBDA, though, and probably any of the surrounding area that e820 marks as
type 2.
James
For network boot, yes. Its ROM and any memory area that it uses would not be
needed after an OS has been loaded.

For other components' ROM and its configuration in the E/BDA, it would
depend on the OS. An OS would have no need for them (except for memory
mapped RAM), once the OS use device drivers that can fully replace the ROMs.

The only problem is, memory mapped ROM, RAM, or registers, in the physical
memory space can't be unmapped/moved unless the hardware manufacturer
provide the capability to do so (i.e.vendor specific).
James Harris
2015-02-06 16:32:03 UTC
Permalink
"James Harris" <***@gmail.com> wrote in message news:mavkj0$jdn$***@dont-email.me...

...
Post by James Harris
I just tried that test on eight machines. On seven of them the calculation
worked out: the address and length added up to 640k (and the EBDA was 1k
in size in each case). But on one of them the EBDA was at 636k and of
length 3k (according to the values read). This means it ended at 639k
rather than 640k.
I just had to reboot my main PC and took the opportunity to run the same
test. It too showed an EBDA which ended before 640k. In this case the EBDA
started at 636k and was just 2k long so the 2k from 638k to 640k will have
apparently been unused.

I wonder if BIOSes, knowing that most OSes will use paging and give out
memory in chunks of 4k, will round the start of the EBDA down to the next
lowest 4k boundary. With paging turned on any space in a page prior to the
start of the EBDA will likely remain unused by a paging OS.

I've come across another anomaly which you might fing interesting. One PC
shows its EBDA starting at 9fc00 or 639k and being 1k long so just occupying
the top 1k but then the e820 map shows as follows.

From 0 for 620k is type 1 (available)
From 620k for 20k (i.e. to 640k) is type 2 (reserved)

In other words, this machine shows the last 20k of memory as reserved and
yet the EBDA is just in the last 1k so it has 19k mysteriously reserved.
Those figures appear whether it is booted from the network or from a floppy.
Int 0x12 also returns 620k when booted from floppy so it seems to be
deliberate.

I wonder if the final 20k of memory in that machine is used by SMM or
perhaps for some BIOS functions. The machine is unusual, having a Transmeta
CPU and being intended for thin client work, and a Phoenix BIOS written or
customised for HP. At any rate this is probably memory that an OS should not
touch.

James
Rod Pemberton
2015-02-07 05:25:40 UTC
Permalink
On Fri, 06 Feb 2015 11:32:03 -0500, James Harris
Post by James Harris
Post by James Harris
I just tried that test on eight machines. On seven of them the
calculation worked out: the address and length added up to 640k
(and the EBDA was 1k in size in each case). But on one of them
the EBDA was at 636k and of length 3k (according to the values
read). This means it ended at 639k rather than 640k.
I just had to reboot my main PC and took the opportunity to run the
same test. It too showed an EBDA which ended before 640k. In this
case the EBDA started at 636k and was just 2k long so the 2k from
638k to 640k will have apparently been unused.
Hmm... More computers with the same issue? Yeah, that's not good,
especially not knowing why.
Post by James Harris
I wonder if BIOSes, knowing that most OSes will use paging and give
out memory in chunks of 4k, will round the start of the EBDA down to
the next lowest 4k boundary. With paging turned on any space in a
page prior to the start of the EBDA will likely remain unused by
a paging OS.
That's a good guess.

x86 recommends aligning a bunch of processor structures, yes?
Post by James Harris
I've come across another anomaly which you might fing interesting.
One PC shows its EBDA starting at 9fc00 or 639k and being 1k long
so just occupying the top 1k but then the e820 map shows as follows.
From 0 for 620k is type 1 (available)
From 620k for 20k (i.e. to 640k) is type 2 (reserved)
In other words, this machine shows the last 20k of memory as reserved
and yet the EBDA is just in the last 1k so it has 19k mysteriously
reserved. Those figures appear whether it is booted from the network
or from a floppy. Int 0x12 also returns 620k when booted from floppy
so it seems to be deliberate.
That's just wierd. I don't know what to make of that. 20KB ...
Post by James Harris
I wonder if the final 20k of memory in that machine is used by SMM
or perhaps for some BIOS functions. The machine is unusual, having a
Transmeta CPU and being intended for thin client work, and a Phoenix
BIOS written or customised for HP. At any rate this is probably memory
that an OS should not touch.
SMM is a good guess. Although, I'd wonder why they didn't map it
between 640KB and the start of the BIOS ROMs. I'd also wonder why
they didn't use a shadow ROM that could be switched in/out by the BIOS.


Rod Pemberton
James Harris
2015-02-07 17:12:48 UTC
Permalink
Post by Rod Pemberton
On Fri, 06 Feb 2015 11:32:03 -0500, James Harris
...
Post by Rod Pemberton
Post by James Harris
I wonder if BIOSes, knowing that most OSes will use paging and give
out memory in chunks of 4k, will round the start of the EBDA down to
the next lowest 4k boundary. With paging turned on any space in a
page prior to the start of the EBDA will likely remain unused by
a paging OS.
That's a good guess.
x86 recommends aligning a bunch of processor structures, yes?
I am not sure I understand the question. Maybe it was rhetorical.

...
Post by Rod Pemberton
Post by James Harris
I wonder if the final 20k of memory in that machine is used by SMM
or perhaps for some BIOS functions. The machine is unusual, having a
Transmeta CPU and being intended for thin client work, and a Phoenix
BIOS written or customised for HP. At any rate this is probably memory
that an OS should not touch.
SMM is a good guess. Although, I'd wonder why they didn't map it
between 640KB and the start of the BIOS ROMs. I'd also wonder why
they didn't use a shadow ROM that could be switched in/out by the BIOS.
Yes, as I understood it SMM had its own RAM space and did not share it with
non-SMM modes though that may be too simplistic.

BTW, on a machine without e820 which may have been netbooted I was wondering
how to get the base memory size - typically 640k or, rarely, 512k on really
old machines. Network card Boot ROMs tend to adjust the values we can read
from the BDA or int 0x12 without leaving a record of what they were before.
But I came across a useful old post of yours on memory size determination in
which you pointed out that the base memory in k may be held in CMOS 0x15 and
0x16. On all machines I tested those bytes showed 640k. It seems from
various sources that the value will be wrong only on very old Amstrads....
and they probably stopped working shortly after being sold. ;-)

James
James Harris
2015-02-06 17:01:07 UTC
Permalink
Post by James Harris
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
But that 16-bit word was originally used as a port address for a potential
LPT4.
Another piece of info about that. I wondered if it would be feasible to see
whether that address (BDA 0x0e) held known port addresses for LPT4 and came
across this:

"In some cases, the BIOS supports a fourth printer port as well, but the
base address for it differs significantly between vendors." (so it doesn't
seem possible easily to recognise it as a port address)

and

"Since the reserved entry for a fourth logical printer port in the BIOS Data
Area (BDA) is shared with other uses on PS/2 machines and with S3 compatible
graphics cards, it typically requires special drivers in most environments."

That is from http://en.wikipedia.org/wiki/Parallel_port#Interfaces.

So that address can allegedly be used by some S3 graphics software too! I'm
not sure I believe it but that's what the article seems to say.

James
wolfgang kern
2015-02-09 11:40:43 UTC
Permalink
Post by James Harris
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
But that 16-bit word was originally used as a port address for a potential
Post by James Harris
LPT4. Comparing the two sources above and RBIL there is some
disagreement over when the meaning of those two bytes changed so I thought
a better way to detect the presence of an EBDA might be to add the
apparent EBDA length in kbytes (specified in its first two bytes) to its
address and see if it came to 640k.
I remember to once read that the forth LPT vanished when PS2 joined in.
And I found that several old DOS-drivers checked on the last bytes of
the BIOS-ROM (F000:FFF0..F) to either treat the word at 040e as:
IO-port or EBDA-segment or even as a video-value.
Post by James Harris
http://stanislavs.org/helppc/ebda.html
I just tried that test on eight machines. On seven of them the calculation
Post by James Harris
worked out: the address and length added up to 640k (and the EBDA was 1k
in size in each case). But on one of them the EBDA was at 636k and of
length 3k (according to the values read). This means it ended at 639k
rather than 640k.
* I thought you might find it interesting
* I thought you might have some ideas as to what follows the EBDA in the
last 1024 bytes on that odd machine (unimportant, just of interest)
* I wondered if you had some better way to tell whether BDA offset 0x0e
contains an EBDA paragraph number or not. I could just assume that that's
what those bytes hold as the EBDA pointer has been its use for a long time
but perhaps there is a better way to check.
Any thoughts?
I haven't seen much defined bytes within this 1kB so far, this few
mouse data could easy reside in the almost unused 0:0500 block as well.
So I think that this reserved 1kB become handy for TSRs because they
are protected from beeing overwritten by DOS.
Once I moved a recovery from DIV-exception there to make an old buggy
game work at all and I never encountered problems after this.

On my current machine there is nothing that changes if I overwrite EBDA,
perhaps DOS would choke on it, but I never tried.
__
wolfgang
James Harris
2015-02-11 11:13:57 UTC
Permalink
Post by wolfgang kern
Post by James Harris
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
But that 16-bit word was originally used as a port address for a
potential > LPT4. Comparing the two sources above and RBIL there is some
disagreement over when the meaning of those two bytes changed so I
thought a better way to detect the presence of an EBDA might be to add
the apparent EBDA length in kbytes (specified in its first two bytes) to
its address and see if it came to 640k.
I remember to once read that the forth LPT vanished when PS2 joined in.
And I found that several old DOS-drivers checked on the last bytes of
IO-port or EBDA-segment or even as a video-value.
Here's the layout of those last 16 bytes as far as I am aware of it

ffff0 .. ffff4: five-byte reset vector far jump
ffff5 .. ffffc: eight byte date in format mm/dd/yy (See note 1, below)
ffffd: one byte potentially involved in a checksum
ffffe: one-byte model
fffff: one-byte submodel

I don't suppose you can remember what they looked for in those 16 bytes can
you? I read in http://en.wikipedia.org/wiki/Parallel_port#Interfaces that S3
video cards sometimes make use of that BDA space. I know the BIOS date is in
there. Maybe they checked for that though that would not be enough by
itself. Maybe model and submodel?

Note 1. Although that field's date's slash chars are usually literal I have
one machine (Toshiba Tecra) where the second slash is not a slash but a
value of 0xc3. I don't know if that is supposed to mean anything or is just
a faulty value but the rest of the date is as normal. Weird, huh!

James
James Harris
2023-11-15 14:43:06 UTC
Permalink
Hello, again, Wolfgang et al.
Post by James Harris
Post by wolfgang kern
Post by James Harris
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
But that 16-bit word was originally used as a port address for a
potential > LPT4. Comparing the two sources above and RBIL there is some
disagreement over when the meaning of those two bytes changed so I
thought a better way to detect the presence of an EBDA might be to add
the apparent EBDA length in kbytes (specified in its first two bytes) to
its address and see if it came to 640k.
I remember to once read that the forth LPT vanished when PS2 joined in.
And I found that several old DOS-drivers checked on the last bytes of
IO-port or EBDA-segment or even as a video-value.
Here's the layout of those last 16 bytes as far as I am aware of it
ffff0 .. ffff4: five-byte reset vector far jump
ffff5 .. ffffc: eight byte date in format mm/dd/yy (See note 1, below)
ffffd: one byte potentially involved in a checksum
ffffe: one-byte model
fffff: one-byte submodel
I don't suppose you can remember what they looked for in those 16 bytes can
you? I read in http://en.wikipedia.org/wiki/Parallel_port#Interfaces that S3
video cards sometimes make use of that BDA space. I know the BIOS date is in
there. Maybe they checked for that though that would not be enough by
itself. Maybe model and submodel?
Note 1. Although that field's date's slash chars are usually literal I have
one machine (Toshiba Tecra) where the second slash is not a slash but a
value of 0xc3. I don't know if that is supposed to mean anything or is just
a faulty value but the rest of the date is as normal. Weird, huh!
Some years later ....

Largely by chance I found out yesterday what the 0xc3 byte means, and remembered this discussion. According to RBIL Toshiba didn't stick to the scheme of including both slashes in the mm/dd/yy BIOS date but in some cases replaced the second slash with their own 'product id' value. See table 00521 in

https://fd.lod.bz/rbil/interrup/bios/15c0.html#sect-1630

In my particular case it says the code 0xc3 means 'Toshiba 710CDT / 720CDT' which would be correct as the one I bought was advertised as a 710cdt.

One small mystery solved. There are lots of them in this game!
--
James Harris
wolfgang kern
2023-11-16 06:53:22 UTC
Permalink
Post by James Harris
Hello, again, Wolfgang et al.
Hi James,
time passed by but we are still alive, me at least particular.
interesting that old posts are archived for that long.
but this whole story became obsolete now because of UEFI.

I would restart my OS on UEFI if I find someone who can translate all
the in the UEFI-docs from C-shit into machine code man readable format.

I never will learn C anyway, but perhaps only short key hints are enough
to let me see how structs and parameter size/type look in reality.
__
wolfgang
Post by James Harris
Post by James Harris
Post by wolfgang kern
Post by James Harris
The address of the EBDA can apparently be found by looking at BDA offset
0x0e.
http://stanislavs.org/helppc/bios_data_area.html
http://www.bioscentral.com/misc/bda.htm
But that 16-bit word was originally used as a port address for a
potential > LPT4. Comparing the two sources above and RBIL there is some
disagreement over when the meaning of those two bytes changed so I
thought a better way to detect the presence of an EBDA might be to add
the apparent EBDA length in kbytes (specified in its first two bytes) to
its address and see if it came to 640k.
I remember to once read that the forth LPT vanished when PS2 joined in.
And I found that several old DOS-drivers checked on the last bytes of
IO-port or EBDA-segment or even as a video-value.
Here's the layout of those last 16 bytes as far as I am aware of it
ffff0 .. ffff4: five-byte reset vector far jump
ffff5 .. ffffc: eight byte date in format mm/dd/yy (See note 1, below)
ffffd: one byte potentially involved in a checksum
ffffe: one-byte model
fffff: one-byte submodel
I don't suppose you can remember what they looked for in those 16 bytes can
you? I read in http://en.wikipedia.org/wiki/Parallel_port#Interfaces that S3
video cards sometimes make use of that BDA space. I know the BIOS date is in
there. Maybe they checked for that though that would not be enough by
itself. Maybe model and submodel?
Note 1. Although that field's date's slash chars are usually literal I have
one machine (Toshiba Tecra) where the second slash is not a slash but a
value of 0xc3. I don't know if that is supposed to mean anything or is just
a faulty value but the rest of the date is as normal. Weird, huh!
Some years later ....
Largely by chance I found out yesterday what the 0xc3 byte means, and remembered this discussion. According to RBIL Toshiba didn't stick to the scheme of including both slashes in the mm/dd/yy BIOS date but in some cases replaced the second slash with their own 'product id' value. See table 00521 in
https://fd.lod.bz/rbil/interrup/bios/15c0.html#sect-1630
In my particular case it says the code 0xc3 means 'Toshiba 710CDT / 720CDT' which would be correct as the one I bought was advertised as a 710cdt.
One small mystery solved. There are lots of them in this game!
James Harris
2023-11-16 16:18:19 UTC
Permalink
Post by wolfgang kern
Post by James Harris
Hello, again, Wolfgang et al.
Hi James,
 time passed by but we are still alive, me at least particular.
interesting that old posts are archived for that long.
Google bought Deja and has lengthy archives of a.o.d with, fortunately,
the ability still to respond to old threads.

I hope Google will keep them indefinitely; there has been some great
content on this newsgroup over the years and I still refer back to it
from time to time.
Post by wolfgang kern
but this whole story became obsolete now because of UEFI.
UEFI is needed for some machines but there are lots which still boot via
the BIOS.

If you want to boot a UEFI-only PC you don't personally have to use
UEFI. You could use someone else's bootloader. Grub is perhaps best known.

I am no fan of Grub but AISI ideally one's OS could be booted from BIOS,
PXE, Grub, UEFI, etc.
Post by wolfgang kern
I would restart my OS on UEFI if I find someone who can translate all
the in the UEFI-docs ...
Yes, the UEFI docs are massive. And IMO the contents are obscure even
for a C programmer!
Post by wolfgang kern
I never will learn C anyway, but perhaps only short key hints are enough
to let me see how structs and parameter size/type look in reality.
Is there an existing thread on it? I don't see one.

A few months ago, as I wanted to support UEFI boot via my own bootloader
I looked into it - and found it horrendously complicated. To make
matters worse my test environment was hugely uninformative. Most of the
time I couldn't even tell whether my code had been booted or not.

I did, however, eventually get it working. As a result I have a Hello
World UEFI program written in assembly. I can share the details if you
like but it needs a thread of its own.

I also got working a program which went further along the boot process.
It interrogated the file system and successfully found a kernel file to
load. That's in C but it's enough to help show how to convert to asm.

At that point I'd done enough to convince me I could get it working so I
moved on to other things but if you are interested I could dig it out.
Like you, I don't want to have a C version. It was only to help me get
started. Longer term I would have the UEFI bootloader in pure asm or in
asm and my own language.

UEFI can be mastered!
--
James Harris
wolfgang kern
2023-11-17 03:17:18 UTC
Permalink
Post by James Harris
Post by wolfgang kern
Post by James Harris
Hello, again, Wolfgang et al.
Hi James,
  time passed by but we are still alive, me at least particular.
interesting that old posts are archived for that long.
Google bought Deja and has lengthy archives of a.o.d with, fortunately,
the ability still to respond to old threads.
I hope Google will keep them indefinitely; there has been some great
content on this newsgroup over the years and I still refer back to it
from time to time.
Post by wolfgang kern
but this whole story became obsolete now because of UEFI.
UEFI is needed for some machines but there are lots which still boot via
the BIOS.
If you want to boot a UEFI-only PC you don't personally have to use
UEFI. You could use someone else's bootloader. Grub is perhaps best known.
I am no fan of Grub but AISI ideally one's OS could be booted from BIOS,
PXE, Grub, UEFI, etc.
I don't like LILO nor GRUB, I want to have my own code running :)
Post by James Harris
Post by wolfgang kern
I would restart my OS on UEFI if I find someone who can translate all
the in the UEFI-docs ...
Yes, the UEFI docs are massive. And IMO the contents are obscure even
for a C programmer!
true.
Post by James Harris
Post by wolfgang kern
I never will learn C anyway, but perhaps only short key hints are
enough to let me see how structs and parameter size/type look in reality.
Is there an existing thread on it? I don't see one.
There were a few lines on it in other threads, but no there isn't a
UEFI->HEX thread yet.
Post by James Harris
A few months ago, as I wanted to support UEFI boot via my own bootloader
I looked into it - and found it horrendously complicated. To make
matters worse my test environment was hugely uninformative. Most of the
time I couldn't even tell whether my code had been booted or not.
I did, however, eventually get it working. As a result I have a Hello
World UEFI program written in assembly. I can share the details if you
like but it needs a thread of its own.
I also got working a program which went further along the boot process.
It interrogated the file system and successfully found a kernel file to
load. That's in C but it's enough to help show how to convert to asm.
I'd appreciate you for any hint on this conversion, but nothing in C.
Post by James Harris
At that point I'd done enough to convince me I could get it working so I
moved on to other things but if you are interested I could dig it out.
Like you, I don't want to have a C version. It was only to help me get
started. Longer term I would have the UEFI bootloader in pure asm or in
asm and my own language.
UEFI can be mastered!
Yes I think that too, even enduring by lots of obstacles.
I don't want a copy of your code, all I need is info:

how would C-declarations/parameter-structs look on my HEX-dump.
is there any easy short worded hint available for conversion ?
__
wolfgang
Scott Lurndal
2023-11-17 16:04:31 UTC
Permalink
Post by wolfgang kern
Post by James Harris
Post by wolfgang kern
Post by James Harris
Hello, again, Wolfgang et al.
Hi James,
  time passed by but we are still alive, me at least particular.
interesting that old posts are archived for that long.
Google bought Deja and has lengthy archives of a.o.d with, fortunately,
the ability still to respond to old threads.
I hope Google will keep them indefinitely; there has been some great
content on this newsgroup over the years and I still refer back to it
from time to time.
Post by wolfgang kern
but this whole story became obsolete now because of UEFI.
UEFI is needed for some machines but there are lots which still boot via
the BIOS.
If you want to boot a UEFI-only PC you don't personally have to use
UEFI. You could use someone else's bootloader. Grub is perhaps best known.
I am no fan of Grub but AISI ideally one's OS could be booted from BIOS,
PXE, Grub, UEFI, etc.
I don't like LILO nor GRUB, I want to have my own code running :)
Post by James Harris
Post by wolfgang kern
I would restart my OS on UEFI if I find someone who can translate all
the in the UEFI-docs ...
Yes, the UEFI docs are massive. And IMO the contents are obscure even
for a C programmer!
true.
Post by James Harris
Post by wolfgang kern
I never will learn C anyway, but perhaps only short key hints are
enough to let me see how structs and parameter size/type look in reality.
Is there an existing thread on it? I don't see one.
There were a few lines on it in other threads, but no there isn't a
UEFI->HEX thread yet.
Post by James Harris
A few months ago, as I wanted to support UEFI boot via my own bootloader
I looked into it - and found it horrendously complicated. To make
matters worse my test environment was hugely uninformative. Most of the
time I couldn't even tell whether my code had been booted or not.
I did, however, eventually get it working. As a result I have a Hello
World UEFI program written in assembly. I can share the details if you
like but it needs a thread of its own.
I also got working a program which went further along the boot process.
It interrogated the file system and successfully found a kernel file to
load. That's in C but it's enough to help show how to convert to asm.
I'd appreciate you for any hint on this conversion, but nothing in C.
Post by James Harris
At that point I'd done enough to convince me I could get it working so I
moved on to other things but if you are interested I could dig it out.
Like you, I don't want to have a C version. It was only to help me get
started. Longer term I would have the UEFI bootloader in pure asm or in
asm and my own language.
UEFI can be mastered!
Yes I think that too, even enduring by lots of obstacles.
how would C-declarations/parameter-structs look on my HEX-dump.
is there any easy short worded hint available for conversion ?
'char' -> 8 bit datum
'short' -> 16 bit datum
'int' -> 32 bit datum
'long' -> 64-bit datum (x86_64 linux)
'long' -> 32-bit datum (x86_64 windows)
'long long' -> 64-bit datum (x86_64 linux and windows)

Types are generally aligned on natural boundaries.

'<type> variable:1' 1-bit datum. Packed in the same word as
prior and subsequent bit-width declarations, overflowing into next word.

'struct' is a "record" of data, with the members aligned
on natural boundaries (unless the compiler is instructed to
pack the data).

In 64-bit modes, parameters are passed in registers
(rdi, rsi, rdx, rcx, r8, r9 in that order) and spill
to the stack for more than 6 parameters.

In 32-bit modes see the Intel x86/x86_64 ABI document
for how parameters are passed to functions, although
windows and unix have somewhat different conventions
here.
wolfgang kern
2023-11-17 22:18:12 UTC
Permalink
Post by Scott Lurndal
Post by wolfgang kern
Post by James Harris
Post by wolfgang kern
Post by James Harris
Hello, again, Wolfgang et al.
Hi James,
  time passed by but we are still alive, me at least particular.
interesting that old posts are archived for that long.
Google bought Deja and has lengthy archives of a.o.d with, fortunately,
the ability still to respond to old threads.
I hope Google will keep them indefinitely; there has been some great
content on this newsgroup over the years and I still refer back to it
from time to time.
Post by wolfgang kern
but this whole story became obsolete now because of UEFI.
UEFI is needed for some machines but there are lots which still boot via
the BIOS.
If you want to boot a UEFI-only PC you don't personally have to use
UEFI. You could use someone else's bootloader. Grub is perhaps best known.
I am no fan of Grub but AISI ideally one's OS could be booted from BIOS,
PXE, Grub, UEFI, etc.
I don't like LILO nor GRUB, I want to have my own code running :)
Post by James Harris
Post by wolfgang kern
I would restart my OS on UEFI if I find someone who can translate all
the in the UEFI-docs ...
Yes, the UEFI docs are massive. And IMO the contents are obscure even
for a C programmer!
true.
Post by James Harris
Post by wolfgang kern
I never will learn C anyway, but perhaps only short key hints are
enough to let me see how structs and parameter size/type look in reality.
Is there an existing thread on it? I don't see one.
There were a few lines on it in other threads, but no there isn't a
UEFI->HEX thread yet.
Post by James Harris
A few months ago, as I wanted to support UEFI boot via my own bootloader
I looked into it - and found it horrendously complicated. To make
matters worse my test environment was hugely uninformative. Most of the
time I couldn't even tell whether my code had been booted or not.
I did, however, eventually get it working. As a result I have a Hello
World UEFI program written in assembly. I can share the details if you
like but it needs a thread of its own.
I also got working a program which went further along the boot process.
It interrogated the file system and successfully found a kernel file to
load. That's in C but it's enough to help show how to convert to asm.
I'd appreciate you for any hint on this conversion, but nothing in C.
Post by James Harris
At that point I'd done enough to convince me I could get it working so I
moved on to other things but if you are interested I could dig it out.
Like you, I don't want to have a C version. It was only to help me get
started. Longer term I would have the UEFI bootloader in pure asm or in
asm and my own language.
UEFI can be mastered!
Yes I think that too, even enduring by lots of obstacles.
how would C-declarations/parameter-structs look on my HEX-dump.
is there any easy short worded hint available for conversion ?
'char' -> 8 bit datum
'short' -> 16 bit datum
'int' -> 32 bit datum
'long' -> 64-bit datum (x86_64 linux)
'long' -> 32-bit datum (x86_64 windows)
'long long' -> 64-bit datum (x86_64 linux and windows)
Types are generally aligned on natural boundaries.
'<type> variable:1' 1-bit datum. Packed in the same word as
prior and subsequent bit-width declarations, overflowing into next word.
'struct' is a "record" of data, with the members aligned
on natural boundaries (unless the compiler is instructed to
pack the data).
In 64-bit modes, parameters are passed in registers
(rdi, rsi, rdx, rcx, r8, r9 in that order) and spill
to the stack for more than 6 parameters.
In 32-bit modes see the Intel x86/x86_64 ABI document
for how parameters are passed to functions, although
windows and unix have somewhat different conventions
here.
THANKS, I copy this right now into my UEFI questionary.
__
wolfgang
James Harris
2023-11-24 18:15:14 UTC
Permalink
...
Post by wolfgang kern
I don't like LILO nor GRUB, I want to have my own code running :)
I'm very much the same!

...
Post by wolfgang kern
Post by James Harris
A few months ago, as I wanted to support UEFI boot via my own
bootloader I looked into it - and found it horrendously complicated.
To make matters worse my test environment was hugely uninformative.
Most of the time I couldn't even tell whether my code had been booted
or not.
I did, however, eventually get it working. As a result I have a Hello
World UEFI program written in assembly. I can share the details if you
like but it needs a thread of its own.
I also got working a program which went further along the boot
process. It interrogated the file system and successfully found a
kernel file to load. That's in C but it's enough to help show how to
convert to asm.
I'd appreciate you for any hint on this conversion, but nothing in C.
Sorry it took a while to write up but I've just started a "UEFI boot
basics" thread.
Post by wolfgang kern
Post by James Harris
At that point I'd done enough to convince me I could get it working so
I moved on to other things but if you are interested I could dig it
out. Like you, I don't want to have a C version. It was only to help
me get started. Longer term I would have the UEFI bootloader in pure
asm or in asm and my own language.
UEFI can be mastered!
Yes I think that too, even enduring by lots of obstacles.
how would C-declarations/parameter-structs look on my HEX-dump.
is there any easy short worded hint available for conversion ?
I see Scott's reply. Also, some comments added to the new thread but
feel free to ask about specifics or comment further.
--
James Harris
Loading...