Available RAM threshold
Aharon Lavie
interrupt vector. This is also the default for the subsequent members
of the 80x86 family.
IBM and other BIOS vendors use addresses from 400H up for BIOS data.
Is there any upper limit for this usage? Is there any BIOS function
which provides information about such ceiling? What is the RAM
threshold available for the use of the operating system?
The documentation which I have reports BIOS data up to 500H inclusive.
For the sake of caution, for the time being I am assuming 600H for the
threshold. This is OK for my present hardware. If at all possible, I
would like to replace this assumption with a more solid knowledge.
Thanks in advance for any information.
Benjamin David Lunt
"Aharon Lavie" <sdc...@gmail.com> wrote in message
news:6b9bd041-4115-4b8a...@n13g2000vbe.googlegroups.com...
0x00600 is a safe starting point. Have a look at
http://www.frontiernet.net/~fys/rombios.htm
and RBILs' memory file at
http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.frontiernet.net/~fys/index.htm
http://www.frontiernet.net/~fys/collections.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some assembly required.
Maxim S. Shatskih
> Is there any upper limit for this usage?
0x700 I think.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Rod Pemberton
news:6b9bd041-4115-4b8a...@n13g2000vbe.googlegroups.com...
> interrupt vector. This is also the default for the subsequent members
> of the 80x86 family.
>
> IBM and other BIOS vendors use addresses from 400H up for BIOS data.
> Is there any upper limit for this usage?
Personally, I'd expect BIOS usage to be limited to the IVT, BDA, and EBDA.
But, Ben's webpage shows otherwise. For which, I've asked him some
questions in another post.
> Is there any BIOS function
> which provides information about such ceiling?
Don't know.
> What is the RAM
> threshold available for the use of the operating system?
From page "2-10 ROM BIOS" of "IBM Personal Computer Technical Reference
manual", "BIOS Memory Map" section:
Starting Address in Hex
00000 BIOS Interrupt Vectors
00080 Available Interrupt Vectors
00400 BIOS Data Area
00500 User Read/Write Memory
C8000 Disk Adapter
F0000 Read Only Memory
FE000 Bios Program Area
> The documentation which I have reports BIOS data up to 500H inclusive.
Inclusive? That depends on the IBM source. The map above indicates it's
"User Read/Write Memory", while the two below indicate it's either DOS or
BIOS:
On page "3-21", "BIOS Data Areas--September 1991" section of "IBM Personal
System/2 and Personal Computer BIOS Interface Technical Reference":
Address
(Hex) Function Size
40:AC to 40:FF Reserved byte
50:00 Print screen status (Interrupt 05H status) byte
On page "ROM BIOS 2-9" of "IBM Personal Computer Technical Reference
manual", "BIOS Memory Map" section:
Address Mode Function
(Hex)
400-48F ROM BIOS See BIOS Listing
490-4EF Reserved
4F0-4FF Reserved as Intra-Application
500-5FF Reserved for DOS and BASIC
500 DOS Print Screen Status Flag Store
0-Print Screen Not Active or Successful
Print Screen Operation
1-Print Screen In Progress
255-Error Encountered during Print Screen
Operation
504 DOS Single Drive Mode Status Byte
510-511 BASIC BASIC's Segment Address Store
512-515 BASIC Clock Interrupt Vector Segment: Offset Store
516-519 BASIC Break Key Interrupt Vector Segment: Offset
Store
51A-51D BASIC Disk Error Interrupt Vector Segment: Offset
Store
They contradict at location 0500. The IBM PC indicates 0500 is for DOS,
while PS/2 indicates 0500 is for BIOS.
Rod Pemberton
Rod Pemberton
news:1fe_m.14753$ft1....@newsfe10.iad...
Ben,
Is 0500 for DOS or for BIOS? One IBM document says it's for DOS. A
different IBM document says it's for BIOS. 0504 is listed as for DOS.
(Both IBM sources quoted in post to Lavie.)
I don't see 0505 on any IBM or other documents I have. Is the 0505 POST
work area for BIOS? Is it used _after_ booting? And, is that for all
machines, or just some? Why is that BIOS using areas other than BDA and
EBDA?
Rod Pemberton
wolfgang kern
Aharon Lavie asked:
...
> IBM and other BIOS vendors use addresses from 400H up for BIOS data.
> Is there any upper limit for this usage? Is there any BIOS function
> which provides information about such ceiling? What is the RAM
> threshold available for the use of the operating system?
...
The BIOS standard seem to have only a few defined bytes in the 0400h
range, but I'd recommend 0600h for a system start even 0500h and
the drive parameters at 0522... may not be used anymore.
__
wolfgang
s_dub...@yahoo.com
CPM-86 for the IBM PC/XT used 0051:0000h (510h) and boots on modern
hardware. Early pcdos/msdos used 0060:0000h (600h). Later,
0070:0000h.
There's about 29k from 600h to the boot sector load point at 7C00h.
If your code loader is in the boot sector abit of juggling is required
if your hobby OS is bigger than the 29.5k, including stack area.
There are a number of strategies with that point in mind.
In modern RomBios's, some of the PS/2 bios features are incorporated,
such as for a pointing device, found in the EBDA (Extended Bios Data
Area). If so, Int 15h Fn C1h returns the EBDA segment address. Also
the segment address is found at 40:000Eh.
Int 12h returns the amount of Conventional Memory in AX as a number of
1k blocks. This is an original PC/XT class function and so
conventional memory is that area available below the Option Rom
address space starting at the video adapter address of A000:0000h. A
value of 280h = 640k. But if the EBDA is present in the system the
value returned is reduced by the size of the EBDA, because the EBDA
would reside at the top of conventional memory. The EBDA is 'usually'
1k, but, for sure, some models of Toshiba laptops used a 2k EBDA.
The size of memory above 1mb is found on old gear with int 15h Fn 88h
which returns the number of contiguous 1k blocks above 1mb, up to
64mb. On more recent gear, int 15h Fn E820h gives the complete memory
map, see RBIL for details.
One question you didn't ask: at boot, where is SS:SP left pointing at?
Answer = 0000:0400h !
The above comments pertain to the 32bit architecture.
hth,
Steve
Benjamin David Lunt
Couldn't tell you for sure. I am sure that different BIOS' use
different places for different things.
In my "surfing", if I found a reference that was somewhat acceptable,
I updated that page. I am not saying that all the information on
that page is correct, just stuff that I found on acceptable pages.
So, your guess is as good as mine.
Ben
James Harris
...
> at boot, where is SS:SP left pointing at?
> Answer = 0000:0400h !
That's bizarre, isn't it. Unless the bootloader is started with
interrupts disabled an interrupt generated before the bootloader
relocates the stack will clobber a number of bytes of the interrupt
vector table. How many? I guess we have something like eight 16-bit
registers plus flags and IP making 20 bytes. Plus there are any
pushes, procedure calls and software interrupts that the interrupt
service routines make. Nested software interrupts especially will save
their own set of registers.
What size is each real-mode interrupt vector? Four bytes? We cannot
say how many nested interrupts there can be. Say there are three.
That's about 60 bytes or the top fifteen interrupt vectors destroyed.
True, we probably don't need those high vector numbers but it still
seems an odd place to put the stack.
Incidentally, rather than 0:400h I found that RBIL says in interrupt
0xfe that "the ROM BIOS uses 0030h:0100h as the initial stack on
startup." I know it comes to the same place.
Unless there is an NMI none of the above applies if the bootup code is
started with interrupts disabled. Another topic, perhaps.
James
James Harris
> "Aharon Lavie" <sdcs...@gmail.com> wrote in message
>
> news:6b9bd041-4115-4b8a...@n13g2000vbe.googlegroups.com...
>
> > For the 8086/8088, Intel reserves storage address range 0-3FFH for the
> > interrupt vector. This is also the default for the subsequent members
> > of the 80x86 family.
>
> > IBM and other BIOS vendors use addresses from 400H up for BIOS data.
> > Is there any upper limit for this usage?
>
> Personally, I'd expect BIOS usage to be limited to the IVT, BDA, and EBDA.
> But, Ben's webpage shows otherwise. For which, I've asked him some
> questions in another post.
If DOS is not loaded (and one isn't running ROM Basic and isn't on an
80286 <http://en.wikipedia.org/wiki/LOADALL>) then I think that's
right, Rod. The EBDA looks like it was formed in higher memory
specifically to avoid writing over memory just above the BDA.
The way I read Ben's web page seems, essentially, to agree with this.
He doesn't always say whether the entries are for DOS or BIOS. And
entries like 0x505 to 0x50e (POST work area) while obviously BIOS
don't apply once POST has finished.
>
> > Is there any BIOS function
> > which provides information about such ceiling?
(To Aharon) I've never come across a way to find the *lowest* address
available but the location seems to be fixed as don't use 0 to 0x500
inclusive. However, based on the info in RBIL if you are in a
bootloader you may want to use the DOS or old ROM Basic area from
0x504 upwards. Other sources point only to 0x500 being used by the
BIOS and don't mention anything higher. That's probably right but due
to the comments in RBIL (qv) it looks safer to avoid 0x501 to 0x503
also. We can get into protected mode without those extra three bytes,
eh.
> > What is the RAM
> > threshold available for the use of the operating system?
To find the highest memory you can access in real mode you can do as
Steve says and use interrupt 0x12.
> > The documentation which I have reports BIOS data up to 500H inclusive.
>
> Inclusive? That depends on the IBM source. The map above indicates it's
> "User Read/Write Memory", while the two below indicate it's either DOS or
> BIOS:
...
> They contradict at location 0500. The IBM PC indicates 0500 is for DOS,
> while PS/2 indicates 0500 is for BIOS.
Are you expecting perfection from the reference manuals? I'm not
claiming they are riddled with faults but they do have some.
Alternatively the PC reference manual may be right for the PC and the
PS/2 manual right for the PS/2. It doesn't really matter. As long as
one avoids 0x500 the code will work on either. As you know, there are
far more important differences if one is writing for the PC rather
than the AT or above.
If it helps the IBM AT manual I have shows the print screen routine as
part of the BIOS on page 5-162. And it is called by the keyboard BIOS
on page 5-119. In other words, print screen is/was a BIOS function on
the AT, not a DOS one.
James
wolfgang kern
James Harris wrote:
> ...
>> at boot, where is SS:SP left pointing at?
>> Answer = 0000:0400h !
> That's bizarre, isn't it. Unless the bootloader is started with
> interrupts disabled an interrupt generated before the bootloader
> relocates the stack will clobber a number of bytes of the interrupt
> vector table. How many? I guess we have something like eight 16-bit
> registers plus flags and IP making 20 bytes. Plus there are any
> pushes, procedure calls and software interrupts that the interrupt
> service routines make. Nested software interrupts especially will save
> their own set of registers.
> What size is each real-mode interrupt vector? Four bytes? We cannot
> say how many nested interrupts there can be. Say there are three.
> That's about 60 bytes or the top fifteen interrupt vectors destroyed.
> True, we probably don't need those high vector numbers but it still
> seems an odd place to put the stack.
Yeah, INT0xc0...ffh aren't defined nor used anyway, so this 256 bytes
from 0300..03ffh could be well enough for a startup.
> Incidentally, rather than 0:400h I found that RBIL says in interrupt
> 0xfe that "the ROM BIOS uses 0030h:0100h as the initial stack on
> startup." I know it comes to the same place.
Older BIOS-setup even asked me to store drive-parameters either at 0300h
or 0522h ...
> Unless there is an NMI none of the above applies if the bootup code is
> started with interrupts disabled. Another topic, perhaps.
I only disable IRQs during changes, so the BIOS keeps track on timers
and can react on keyboard events until I decide to take over control.
__
wolfgang
s_dub...@yahoo.com
> "Benjamin David Lunt" <zf...@frontiernet.net> wrote in messagenews:1fe_m.14753$ft1....@newsfe10.iad...
>
>
>
> > 0x00600 is a safe starting point. Have a look at
> > http://www.frontiernet.net/~fys/rombios.htm
>
> Ben,
>
> Is 0500 for DOS or for BIOS? One IBM document says it's for DOS. A
> different IBM document says it's for BIOS. 0504 is listed as for DOS.
> (Both IBM sources quoted in post to Lavie.)
A Phoenix Technical Ref I have lists 40:0100h as a one byte 'Print
screen status byte' used by Bios Service Int 05h.
That doesn't preclude Dos from revectoring it to its own handler. I
recall public domain utilities which took it over to 'print' to a file
instead of the line printer.
Steve
s_dub...@yahoo.com
wrote:
> On 30 Dec, 02:12, s_dubrov...@yahoo.com wrote:
>
> ...
>
> > at boot, where is SS:SP left pointing at?
> > Answer = 0000:0400h !
>
> That's bizarre, isn't it. Unless the bootloader is started with
> interrupts disabled an interrupt generated before the bootloader
> relocates the stack will clobber a number of bytes of the interrupt
> vector table. How many? I guess we have something like eight 16-bit
> registers plus flags and IP making 20 bytes. Plus there are any
> pushes, procedure calls and software interrupts that the interrupt
> service routines make. Nested software interrupts especially will save
> their own set of registers.
>
> What size is each real-mode interrupt vector? Four bytes? We cannot
> say how many nested interrupts there can be. Say there are three.
> That's about 60 bytes or the top fifteen interrupt vectors destroyed.
>
push the flags and the long ptr to return to on the bios stack before
entering the handler. A well behaved handler would switch to its own
stack on entry and save it's locals there (I've I hunch that stack
would be in the EBDA, but perhap a switch to PM occurs for certain
handlers). -so it's not near the 60 bytes. Besides, CP/M-86 uses Int
E0h at 0:0380h and would fail in practice if that much bios stack was
used by bios interrupts.
I'll mention now that there is a difference in register values found
between booting from power-on and a ctrl-alt-delete reboot. It is an
interesting exercise to make a bootable floppy with code to dump the
state of the registers at boot time, and compare the difference, and
the difference between machines.
Steve
James Harris
> On Dec 30, 1:33 am, James Harris <james.harri...@googlemail.com>
> wrote:
>
> > On 30 Dec, 02:12, s_dubrov...@yahoo.com wrote:
>
> > ...
>
> > > at boot, where is SS:SP left pointing at?
> > > Answer = 0000:0400h !
>
> > That's bizarre, isn't it. Unless the bootloader is started with
> > interrupts disabled an interrupt generated before the bootloader
> > relocates the stack will clobber a number of bytes of the interrupt
> > vector table. How many? I guess we have something like eight 16-bit
> > registers plus flags and IP making 20 bytes. Plus there are any
> > pushes, procedure calls and software interrupts that the interrupt
> > service routines make. Nested software interrupts especially will save
> > their own set of registers.
>
> > What size is each real-mode interrupt vector? Four bytes? We cannot
> > say how many nested interrupts there can be. Say there are three.
> > That's about 60 bytes or the top fifteen interrupt vectors destroyed.
>
> No, if the bios stack is in context and an Int nn occurs, it would
> push the flags and the long ptr to return to on the bios stack before
> entering the handler. A well behaved handler would switch to its own
> stack on entry and save it's locals there
Is this a guess? :-) Or have you seen a BIOS which does this? I'll
give an example of software interrupts and pushes being nested.
This is the BIOS response to the Print Screen key and is taken from
the original AT BIOS. References (s-ppp) are section and page numbers
from the AT tech ref manual.
First, when the keyboard BIOS receives a key press event (5-116) it
saves general registers (and two segment regs - I forgot those). When
it detects that the Print Screen key is the one which was pressed it
calls print screen as "int 5" (5-119) exactly as an app might.
The print_screen_1 routine (5-162) receives control, pushes a few of
its own registers (callee save) and calls int 0x10 to get the screen
mode.
The video BIOS (5-128) video_io_1 pushes its registers and does its
thing, etc.
So these do seem to recursively push registers consuming stack as they
go. Anything else wouldn't make sense. They have to save registers
they use. So far I haven't seen them switching stacks.
> (I've I hunch that stack
> would be in the EBDA, but perhap a switch to PM occurs for certain
> handlers). -so it's not near the 60 bytes. Besides, CP/M-86 uses Int
> E0h at 0:0380h and would fail in practice if that much bios stack was
> used by bios interrupts.
The EBDA is a data area. I don't know if there's a need to put a stack
in there too.
I suspect (this is me guessing now) that when DOS or another 16-bit OS
starts up it gives its apps a stack which is plenty large enough to
include BIOS calls. Then the 0x400 stack is not needed beyond the very
first stage of bootup. I would expect a boot loader to relocate the
stack to somewhere safer and larger as one of its very first actions.
Just don't press Print Screen before the bootloader gets control. ;-)
James
Aharon Lavie
> "Aharon Lavie" <sdcs...@gmail.com> wrote in message
Rod,
I am aware of imperfections in some reference manuals. Preferring to
err on the side of caution, I chose to assume byte 500H as a BIOS
datum. This assumption is reinforced by a number of references, e.g.
The book "PC Interns" by Michael Tischer (ISBN 1-55755-145-6), p. 84
The book "The Undocumented PC" by Franck van Gilluwe (ISBN
0-201-62277-7), p. 201
Aharon Lavie
[...snip...]
>
> One question you didn't ask: at boot, where is SS:SP left pointing at?
> Answer = 0000:0400h !
>
[...skip...]>
> Steve
Steve,
I have no need to ask this question, because the first thing that I
do, both in my MBR and in the boot sector of my system, is to disable
interrupts and establish my own stack.
Enabling interrupts and JMP FAR to establish CS:IP immediately
follows.