Brendan's BIOS Wrapper (experimental!)

[Mike Gonta]

http://forum.osdev.org/viewtopic.php?p=221308


Mike Gonta
look and see - many look but few see

http://mikegonta.com

[Alexei A. Frounze]

Why not use v86?

Alex

[Rod Pemberton]

"Mike Gonta" <mike...@gmail.com> wrote in message
news:kj9qmr$8hi$1...@speranza.aioe.org...

> http://forum.osdev.org/viewtopic.php?p=221308
>

How is this different from your aeBIOS?


Rod Pemberton

[s_dub...@yahoo.com]

If the BIOS could talk, I wonder what it would say as to what it
already does. Certainly the POST code switches into and out of PMode
in setting up some of the BIOS extentions for 32bits.

Examining the GDTR from bootstrap code shows these descriptors on a
pentium mmx laptop (old dell latitude)..

-----------------
From CTRL-ALT-DEL
-----------------

CS Value: 00000000h
PIC1 Value: 000000B8h
CMOS Value: 0000009Ch
CR0 Value: 00000010h
CR2 Value: 00000000h
CR3 Value: 00000000h
GDTR Value: Limit: 0040h Base: 000682E0h
IDTR Value: Limit: 0400h Base: 00000000h

GDT:

0000000000000000h Null Descriptor
P PL S DEWA D/C (data/code)
FFFF 000006 93 0F 00h - 1 00 1 0011 .. D Expand UP WrA 16bit. 1meg
limit, base 060000h
FFFF 000000 93 00 00h - 1 00 1 0011 .. D Expand UP WrA 16bit. 64k
limit
FFFF 000000 93 8F 00h - 1 00 1 0011 .. D Expand UP WrA (8- 1000b) 4gig
limits,
FFFF 000000 9E CF 00h - 1 00 1 1110 .. C Conforming RO (C- 1100b) 4gig
limits, 32bit
FFFF 000006 9F 00 00h - 1 00 1 1111 .. C Conforming RO Accessed
(ran?), 16bit, base 060000h
FFFF 000000 93 00 00h - 1 00 1 0011 .. D Expand UP WrA 16bit. 64k
limit
FFFF 00F000 9E 00 00h - 1 00 1 1110 .. C Conforming RO, 16bit, base
00F000h

I guess I would have expected that the GDTR would've been cleared on
boot after POST. INT 19h for reboot doesn't clear it either. I put
this up for discussion, or to see if anyone else has experiences to
share.

Steve

[Rod Pemberton]

<s_dub...@yahoo.com> wrote in message
news:a938b21b-4c65-4c11...@k1g2000yqf.googlegroups.com...

> If the BIOS could talk, I wonder what it would say as to what it
> already does. Certainly the POST code switches into and out of
> PMode in setting up some of the BIOS extentions for 32bits.
>
> Examining the GDTR from bootstrap code shows these descriptors
> on a pentium mmx laptop (old dell latitude)..
>
> -----------------
> From CTRL-ALT-DEL
> -----------------
>

> [snip values and descriptors]

>
> I guess I would have expected that the GDTR would've been
> cleared on boot after POST. INT 19h for reboot doesn't
> clear it either. I put this up for discussion, or to see if
> anyone else has experiences to share.

1) CTRL-ALT-DEL is a warm reboot. I thought POST was just for
cold boot. Is that correct? If so, then there is no POST for a
CTRL-ALT-DEL ...

2) Aren't warm reboots required to preserve settings? I.e., warm
reboot was used to switch in-and-out of PM for 286's. That
functionality is still present in the BIOS.

3) The BIOS uses PM for at least two RM interrupts. Int 15h,
AH=87h and Int 15h, AH=89h. If a BIOS does any setup for them,
then PM registers will likely be trashed. I suspect most modern
BIOSes use PM for initializing memory chips also. As for 32-bit
PM BIOS routines, such as 32-bit PCI/PnP/APM routines, do they
need BIOS setup in PM prior to usage?

4) Are you seeing your issue on multiple machines? If not, I'd
assume it's BIOS specific. IIRC, Dell uses a custom BIOS not from
the major BIOS vendors ... Laptop BIOSes have also been known to
have some incompatibilities. You could search for the handful of
posts by Mark Larson who said he programmed Dell's BIOS for 10
years or so. One of his posts said Dell's BIOS is 256KB and
copied down in sections from ROM just under 4GB to RAM at E000h
and F000h. The last two RAM blocks are then "locked" to act like
ROM. Each block of code is executed in turn. I'm guessing that
this is except for the last two which are the normal BIOS and
jumped to for their init. I'm assuming this technique uses PM
code to move the blocks and is not a hardware mechanism.

5) sandpile.org has initial processor values. If your values
don't match, then the BIOS is probably setting or using them.
http://www.sandpile.org/x86/initial.htm

6) What exactly is your issue? GDTR trashed or modified? BIOS
not cleaning up after itself? POST not setting GDTR?

7) Why do you need or expect GDTR to be cleared?


Rod Pemberton

[s_dub...@yahoo.com]

On Apr 6, 4:16 am, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>
wrote:
> <s_dubrov...@yahoo.com> wrote in message

>
> news:a938b21b-4c65-4c11...@k1g2000yqf.googlegroups.com...
>
>
>
>
>
> > If the BIOS could talk, I wonder what it would say as to what it
> > already does.  Certainly the POST code switches into and out of
> > PMode in setting up some of the BIOS extentions for 32bits.
>
> > Examining the GDTR from bootstrap code shows these descriptors
> > on a pentium mmx laptop (old dell latitude)..
>
> > -----------------
> > From CTRL-ALT-DEL
> > -----------------
>
> > [snip values and descriptors]
>
> > I guess I would have expected that the GDTR would've been
> > cleared on boot after POST.  INT 19h for reboot doesn't
> > clear it either.  I put this up for discussion, or to see if
> > anyone else has experiences to share.
>
> 1) CTRL-ALT-DEL is a warm reboot.  I thought POST was just for
> cold boot.  Is that correct?  If so, then there is no POST for a
> CTRL-ALT-DEL ...

I always understood the warm boot as a shortened version of of POST.

>
> 2) Aren't warm reboots required to preserve settings?  I.e., warm
> reboot was used to switch in-and-out of PM for 286's.  That
> functionality is still present in the BIOS.
>

AIR, the 286 didn't provide a way to switch out of PM cleanly, and so
a few 'hacks' were used to do it. If that functionality is still
present in the BIOS then that is curious.

> 3) The BIOS uses PM for at least two RM interrupts.  Int 15h,
> AH=87h and Int 15h, AH=89h.  If a BIOS does any setup for them,
> then PM registers will likely be trashed.  I suspect most modern
> BIOSes use PM for initializing memory chips also.  As for 32-bit
> PM BIOS routines, such as 32-bit PCI/PnP/APM routines, do they
> need BIOS setup in PM prior to usage?
>

I don't really know, but I assume so. The POST has a duty to run the
intialization code of the option rom's found in the system. This is
old school stuff, I don't have good knowlege of modern BIOS
functionality, the new buss's - bridges, and such.

> 4) Are you seeing your issue on multiple machines?  If not, I'd
> assume it's BIOS specific.  IIRC, Dell uses a custom BIOS not from
> the major BIOS vendors ...  Laptop BIOSes have also been known to
> have some incompatibilities.  You could search for the handful of
> posts by Mark Larson who said he programmed Dell's BIOS for 10
> years or so.  One of his posts said Dell's BIOS is 256KB and
> copied down in sections from ROM just under 4GB to RAM at E000h
> and F000h.  The last two RAM blocks are then "locked" to act like
> ROM.  Each block of code is executed in turn.  I'm guessing that
> this is except for the last two which are the normal BIOS and
> jumped to for their init.  I'm assuming this technique uses PM
> code to move the blocks and is not a hardware mechanism.
>

Yes, the dell laptop, and a dell desktop (P4) they both have phoenix
bios's, surely dell has its own extentions to the bios, all vendors
have, in order to personalize their brand. The desktop has a couple
of more get entries.

> 5) sandpile.org has initial processor values.  If your values
> don't match, then the BIOS is probably setting or using them.http://www.sandpile.org/x86/initial.htm
>

I'm checking with boot-strap code, after the POST, way after what they
are looking at (which is the power-on state).

> 6) What exactly is your issue?  GDTR trashed or modified?  BIOS
> not cleaning up after itself?  POST not setting GDTR?
>

Not an 'issue', an observation, that there is leftover GDT data when
my boot strap code gets control. John Monahan piqued my interest with
his 386 monitor project. I hadn't delved much into PM really, so
other's such as Alexei have a dozen years more experience at it than
I. So, I wondered if others had also made this observation, and
explored it any further.

> 7) Why do you need or expect GDTR to be cleared?
>

Well (I expect), for security, or to avoid mishaps.
The GDTR tells where the GDT is, and that outlines a prior code
enviornment, which isn't overwritten in the case of this bootstrap, so
is available for observation/execution risks.

Steve

> Rod Pemberton

[Alexei A. Frounze]

On Apr 5, 8:48 am, "s_dubrov...@yahoo.com" <s_dubrov...@yahoo.com>
wrote:

I don't think there's any requirement or any compelling reason to
clean up GDTR and GDT. Certainly, this info may help in reverse
engineering the BIOS, but you could do it without the info. You're the
master, you can still read and write any memory location or I/O port
as you please, there's nothing to stop you other than the amount of
work to do. GDT(R) isn't giving away much or too much. You've got it
already.

Alex

[Rod Pemberton]

<s_dub...@yahoo.com> wrote in message
news:1005e5a1-63da-4b92...@g4g2000yqd.googlegroups.com...

> On Apr 6, 4:16 am, "Rod Pemberton"
<do_not_h...@notemailnotq.cpm>
> wrote:

> > 5) sandpile.org has initial processor values. If your values
> > don't match, then the BIOS is probably setting or using them.

> > [link]

> >
>
> I'm checking with boot-strap code, after the POST, way after
> what they are looking at (which is the power-on state).

Yes, it's true that's the power-on state values. But, if the BIOS
does not use PM, only uses RM, then I'd expect the GDTR to have
the power-on state values. Yes? I definately think it's unlikely
that any BIOS, except perhaps for a 386 or 486 or earlier, would
not need to use PM for some setup.

> Not an 'issue', an observation, that there is leftover GDT data
> when my boot strap code gets control. John Monahan piqued
> my interest with his 386 monitor project. I hadn't delved
> much into PM really, so other's such as Alexei have a dozen
> years more experience at it than I. So, I wondered if others
> had also made this observation, and explored it any further.

When your custom boot-up code gets control at 7C00h, you're in RM.
That's the same mode the processor powers up into. So, you can
set whatever mode you need and go from there. You still need to
set your own GDT. You don't want to use the BIOS' former PM GDT
or the power-on GDT, do you? Take control.

Also, if the BIOS placed the processor in v86 mode (etc.) instead
of RM, you'd have a serious problem.

If you're using a Multiboot loader, you'll be in a minimally setup
32-bit PM instead of RM. It does a minimal setup. I.e., even
though it sets up PM for you, you still have to load your own
GDT ... Otherwise, you're using the bootloader's GDT which is
setup for it's code needs. Thats acceptable until you've got your
GDT setup. Your GDT should match your code's needs.

> > 7) Why do you need or expect GDTR to be cleared?
>
> Well (I expect), for security, or to avoid mishaps.
> The GDTR tells where the GDT is, and that outlines a prior code

> environment, which isn't overwritten in the case of this

> bootstrap, so is available for observation/execution risks.

If you're wanting security, you probably want the new EFI or UEFI
type of BIOS which includes a secure boot method. This has links
to a few other BIOS related Wikipedia pages too.
http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

Since you're in RM when 7C00h gets control, the GDTR, if it was
set, tells where the GDT was once. But, the BIOS' PM is no longer
active. I.e., it's stale GDT data for an environment which may or
may not be in memory anymore or could be corrupt.

Even if a BIOS PM environment was still present in memory and you
could or did reactivate the stale GDT data, would the environment
be useful to you? For what? What could or would you use it for?
So much would be unknown about it...

Also, are you worried about erroneous flashing of the BIOS? I.e.,
BIOS virus? IIRC, most BIOSes since late 90's use a manufacturer
secret code to enable flashing. It might be possible for a
certain brand of machines to have a BIOS virus installed, but I'd
expect it to be rather difficult for a wide variety of machines.
A hacker would need many keys and methods for widespread use,
unless they were attacking a corporation or organization or
government that used many identical machines. Even if that is
possible, I suspect they'd still have to switch the processor into
RM to flash the BIOS. That's not an option on standard PM OSes
after the OS has booted.

What's in the PM BIOS environment that you don't have access to?
chip initialization? secret keys? I'd expect chip initialization
to be in the part of the BIOS that's temporary or bootstrap code.
The BIOS flash key might be hidden in that environment somewhere.

Personally, there is not much from the BIOS that I want. What I
want is to make certain is that I get to 7C00h, cleanly and
consistently and with a consistent entry state, without something
other than the BIOS taking control between power-up and transfer
to 7C00h. That's why the warm boot to switch out of PM concerns
me. I write values to CMOS register F and 40:72h and 40:67h for
my OS as an attempt to block usage or control misusage of that
feature and to ensure only cold reboots are done. I doubt that
Linux or Windows does that which is where it's probably needed...
Of course, in my simple OS, there is no way to prevent a hacker
from setting those. In Windows or Linux, they can unmap the pages
for segment 40h and block ports which allow the CMOS to be
updated.

Wouldn't the stale GDT environment be specific to the BIOS in
question? At the moment, other than the few items I mentioned
above, I can't really see much to do with how or for what a hacker
could use that environment ... Most OSes aren't based on the BIOS
calls anymore. Could it reveal the location of "secret" devices?
keys?


Rod Pemberton

[s_dub...@yahoo.com]

On Apr 7, 4:43 am, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>
wrote:
> <s_dubrov...@yahoo.com> wrote in message

>
> news:1005e5a1-63da-4b92...@g4g2000yqd.googlegroups.com...> On Apr 6, 4:16 am, "Rod Pemberton"
>
> <do_not_h...@notemailnotq.cpm>
>
> > wrote:
> > > 5) sandpile.org has initial processor values. If your values
> > > don't match, then the BIOS is probably setting or using them.
> > > [link]
>
> > I'm checking with boot-strap code, after the POST, way after
> > what they are looking at (which is the power-on state).
>
> Yes, it's true that's the power-on state values.  But, if the BIOS
> does not use PM, only uses RM, then I'd expect the GDTR to have
> the power-on state values.  Yes?  I definately think it's unlikely
> that any BIOS, except perhaps for a 386 or 486 or earlier, would
> not need to use PM for some setup.

Exactly, PM checks have been going on in the POST since way back in
the days of Plug and Play BIOS spec., circa 1994.

> > Not an 'issue', an observation, that there is leftover GDT data
> > when my boot strap code gets control.  John Monahan piqued
> > my interest with his 386 monitor project.  I hadn't delved
> > much into PM really, so other's such as Alexei have a dozen
> > years more experience at it than I.  So, I wondered if others
> > had also made this observation, and explored it any further.
>
> When your custom boot-up code gets control at 7C00h, you're in RM.
> That's the same mode the processor powers up into.  So, you can
> set whatever mode you need and go from there.  You still need to
> set your own GDT.  You don't want to use the BIOS' former PM GDT
> or the power-on GDT, do you?  Take control.

Well, I do. I setup a GDT later in the boot-strap code.

> Also, if the BIOS placed the processor in v86 mode (etc.) instead
> of RM, you'd have a serious problem.
>
> If you're using a Multiboot loader, you'll be in a minimally setup
> 32-bit PM instead of RM.  It does a minimal setup.  I.e., even
> though it sets up PM for you, you still have to load your own
> GDT ...  Otherwise, you're using the bootloader's GDT which is
> setup for it's code needs.  Thats acceptable until you've got your
> GDT setup.  Your GDT should match your code's needs.
>
> > > 7) Why do you need or expect GDTR to be cleared?
>
> > Well (I expect), for security, or to avoid mishaps.
> > The GDTR tells where the GDT is, and that outlines a prior code
> > environment, which isn't overwritten in the case of this
> > bootstrap, so is available for observation/execution risks.
>
> If you're wanting security, you probably want the new EFI or UEFI
> type of BIOS which includes a secure boot method.  This has links
> to a few other BIOS related Wikipedia pages too.http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

The test machine doesn't know EFI, the target is 32bit pentium class.

> Since you're in RM when 7C00h gets control, the GDTR, if it was
> set, tells where the GDT was once.  But, the BIOS' PM is no longer
> active.  I.e., it's stale GDT data for an environment which may or
> may not be in memory anymore or could be corrupt.
>
> Even if a BIOS PM environment was still present in memory and you
> could or did reactivate the stale GDT data, would the environment
> be useful to you?  For what?  What could or would you use it for?
> So much would be unknown about it...
>
> Also, are you worried about erroneous flashing of the BIOS?  I.e.,
> BIOS virus?  IIRC, most BIOSes since late 90's use a manufacturer
> secret code to enable flashing.  It might be possible for a
> certain brand of machines to have a BIOS virus installed, but I'd
> expect it to be rather difficult for a wide variety of machines.
> A hacker would need many keys and methods for widespread use,
> unless they were attacking a corporation or organization or
> government that used many identical machines.  Even if that is
> possible, I suspect they'd still have to switch the processor into
> RM to flash the BIOS.  That's not an option on standard PM OSes
> after the OS has booted.
>
> What's in the PM BIOS environment that you don't have access to?
> chip initialization? secret keys?  I'd expect chip initialization
> to be in the part of the BIOS that's temporary or bootstrap code.
> The BIOS flash key might be hidden in that environment somewhere.

These are all good questions, none I have answers for. Economy of
time argues against spending too much time on it.

> Personally, there is not much from the BIOS that I want.  What I
> want is to make certain is that I get to 7C00h, cleanly and
> consistently and with a consistent entry state, without something
> other than the BIOS taking control between power-up and transfer
> to 7C00h.  That's why the warm boot to switch out of PM concerns
> me.  I write values to CMOS register F and 40:72h and 40:67h for
> my OS as an attempt to block usage or control misusage of that
> feature and to ensure only cold reboots are done.  I doubt that
> Linux or Windows does that which is where it's probably needed...
> Of course, in my simple OS, there is no way to prevent a hacker
> from setting those.  In Windows or Linux, they can unmap the pages
> for segment 40h and block ports which allow the CMOS to be
> updated.
>
> Wouldn't the stale GDT environment be specific to the BIOS in
> question?  At the moment, other than the few items I mentioned
> above, I can't really see much to do with how or for what a hacker
> could use that environment ...  Most OSes aren't based on the BIOS
> calls anymore.  Could it reveal the location of "secret" devices?
> keys?
>
> Rod Pemberton

There is a part B to this. It turns out that int 19h is what I use to
terminate this experimental bootstrap with. So that, with the floppy
left in the drive, the bootstrap reboots itself. So it reports the
GDTR and GDT, which are now the values that were placed there in the
prior boot of the bootstrap, not what was leftover from the BIOS.
Useful information? -Well, it leads to a method whereby the bootstrap
can tell whether it booted previously. That is, whether the current
boot was thru int 19h or ctrl-alt-del. fwiw.

Steve

[Rod Pemberton]

<s_dub...@yahoo.com> wrote in message
news:ccd31c71-cb96-441e...@v20g2000yqj.googlegroups.com...

> There is a part B to this. It turns out that int 19h is what I
> use to terminate this experimental bootstrap with. So that,
> with the floppy left in the drive, the bootstrap reboots itself.

Did you mean Int 18h?

The PnP BIOS Spec. (1994) says that control may be returned to
system BIOS for recovery via either Int 19h or Int 18h.

The BIOS Boot Spec. (1996) says that hard drive boot sectors
execute Int 18h for boot failure, but floppy boot sectors use Int
19h. Then, the spec redefines the recovery vector for both hard
drive and floppy boot sectors to be Int 18h.

So, what age are the Phoenix BIOS in those two Dell machines?
I.e., in theory, a floppy boot sector for a pre-1996 machine could
use either Int 18h or Int 19h, while a floppy boot sector for a
post-1996 machine should use Int 18h. So, Int 18h would seem to
be the appropriate choice for both. The BBS also discusses some
other compatibility issues with use of Int 18h.

> So it reports the GDTR and GDT, which are now the values
> that were placed there in the prior boot of the bootstrap, not
> what was leftover from the BIOS. Useful information?
> -Well, it leads to a method whereby the bootstrap can tell
> whether it booted previously. That is, whether the current
> boot was thru int 19h or ctrl-alt-del. fwiw.

Ah, if widely applicable, then that might be something Ben Lunt
and James Harris would be interested in.


Rod Pemberton

[s_dub...@yahoo.com]

On Apr 7, 7:21 pm, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>

wrote:
> <s_dubrov...@yahoo.com> wrote in message
>
>

> > There is a part B to this.  It turns out that int 19h is what I
> > use to terminate this experimental bootstrap with.  So that,
> > with the floppy left in the drive, the bootstrap reboots itself.
>
> Did you mean Int 18h?
>

No, int 19h.

> The PnP BIOS Spec. (1994) says that control may be returned to
> system BIOS for recovery via either Int 19h or Int 18h.
>
> The BIOS Boot Spec. (1996) says that hard drive boot sectors
> execute Int 18h for boot failure, but floppy boot sectors use Int
> 19h.  Then, the spec redefines the recovery vector for both hard
> drive and floppy boot sectors to be Int 18h.
>
> So, what age are the Phoenix BIOS in those two Dell machines?

The laptop, Latitude CPi, says bios revision A07
Copyright 1985-1988 Phoenix Technologies Ltd.
Copyright 1990-1998 Dell Computer Corp. and others.

The desktop, Dim. 8250, is a much more recent antique:
Phoenix Rom Bios Plus version 1.10 A03 (c) 1985-1988
(c) 1990-2003 Dell Computer Corp.

-So this tells me the Phoenix core was licensed and augmented by Dell.

> I.e., in theory, a floppy boot sector for a pre-1996 machine could
> use either Int 18h or Int 19h, while a floppy boot sector for a
> post-1996 machine should use Int 18h.  So, Int 18h would seem to
> be the appropriate choice for both.  The BBS also discusses some
> other compatibility issues with use of Int 18h.
>

According to the Phoenix Technical Ref. I have (circa 1991), it calls
Int 19h function the "Bootstrap Loader". It calls Int 18h function
the "Process Boot Failure (XT,ISA,EISA)".

(In another chapter about the POST, describing the System Boot
Procedure:)

Once the POST completes its test and initialization procedures,
it boots the system using Int 19h as follows:
. . .
(typical, as known)
. . .
. If neither A: nor C: contains a disk with a boot sector, POST
issues
an Int 18h, which reports the problem and waits for a keystroke to
call
Int 19h again.

(The next section, headered: "Special use of INT 18h" says:)
"
The IBM BIOS uses INT 18h to point to a ROM-resident BASIC
interpreter.
Manufacturers of PC compatibles include BASIC on disk instead, and
use INT 18h to display the message NO BOOT DEVICE AVAILABLE. The
system user must then press F1 to have POST retry the boot procedure.

INT 18h can be vectored to a "no boot routine". An example of such a
routine would be one that allows a system to be booted over a network.
"

(The EISA Buss appeared with the ia80486, it instituted earliest PnP.)

(There is another section, headered: "Reentry into POST"..)

"
Introduction

Some computer operations require that the microprocessor be reset.
For
example, this occures when the device must return to real mode from
protected mode. If POST is executing when the microprocessor resets
itself, then the proper reentry must be made. To find the correct
point
at which to begin execution, POST reads CMOS RAM location 0Fh. This
one
byte location contains the microprocessor shutdown code that indicates
where POST should continue execution.

POST shutdown codes

The following are the microprocessor shutdown codes that the POST can
find at CMOS RAM location 0Fh:

00h = Normal execution of POST
01h = Chip set initialization for real mode reentry
04h = Jump to bootstrap code
05h = Issue an EOI and JMP to Dword pointer at 40:67h
06h = JMP to Dword pointer at 40:67h without EOI
07h = Return to INT 15h, Function AH=87h Block Move
08h = Return to POST memory test
09h = Return to INT 15h, Function AH=87h Block Move
0Ah = JMP to Dword pointer at 40:67h without EOI
0Bh = Return IRETS through 40:67h

If POST finds a shutdown code of 00h at CMOS RAM location 0Fh, it
performs its complete suite of tests an initializations. POST
also executes its complete suite of tests and initializations if
it finds any code other than the one listed above.
"

(Yes, I see the repeated functionality in the list.)
(ISTM for this method to work, the shutdown code must be checked)
(for very early in the POST execution in order to be restarted)
(without ending up in an endless loop.)

"
System RAM areas used by POST

The data definitions that POST uses are stored in the system RAM at
locations 40:12h, 40:15h, 40:67h, 40:6Bh, and 40:72h, but
initializes everything in 40:0h. See Chapter 3 for descriptions of
these data areas,
"

Chapter 3 Bios Data Area-

40:13h - 1 word - INT 12h - Installed memory in kilobytes (minus
size of the extended BIOS data area, if implemented)

40:15h - (not listed, omitted)

40:67h - 1 word - (*, **) - Address offset of option ROM

* - BIOS Service (INT nn) varies depending on which option ROM is
installed.

** - Also used by POST for return from RESET and by XT for cassette
data.

40:6Bh - 1 byte - POST - Last interrupt that occurred.

40:72h - 1 word - INT 09h,POST - Reset flag, where:
1234h = Bypass memory test
4321h = Preserve memory
64h = Burn-in mode

> > So it reports the GDTR and GDT, which are now the values
> > that were placed there in the prior boot of the bootstrap, not
> > what was leftover from the BIOS.  Useful information?
> > -Well, it leads to a method whereby the bootstrap can tell
> > whether it booted previously.  That is, whether the current
> > boot was thru int 19h or ctrl-alt-del.  fwiw.
>
> Ah, if widely applicable, then that might be something Ben Lunt
> and James Harris would be interested in.
>

Good point, it may not be widely applicable, it remains to be tested
as needed.

Steve

> Rod Pemberton

[Rod Pemberton]

<s_dub...@yahoo.com> wrote in message
news:130572e3-d785-49eb...@n4g2000yqj.googlegroups.com...

> On Apr 7, 7:21 pm, "Rod Pemberton"
<do_not_h...@notemailnotq.cpm>
> wrote:
> > <s_dubrov...@yahoo.com> wrote in message

> > > There is a part B to this. It turns out that int 19h is what
> > > I use to terminate this experimental bootstrap with. So
> > > that, with the floppy left in the drive, the bootstrap
> > > reboots itself.
> >
> > Did you mean Int 18h?
> >
> No, int 19h.

...

> > The PnP BIOS Spec. (1994) says that control may be returned to
> > system BIOS for recovery via either Int 19h or Int 18h.
> >
> > The BIOS Boot Spec. (1996) says that hard drive boot sectors
> > execute Int 18h for boot failure, but floppy boot sectors use
> > Int 19h. Then, the spec redefines the recovery vector for both
> > hard drive and floppy boot sectors to be Int 18h.
> >
> > So, what age are the Phoenix BIOS in those two Dell machines?
>
> The laptop, Latitude CPi, says bios revision A07
> Copyright 1985-1988 Phoenix Technologies Ltd.
> Copyright 1990-1998 Dell Computer Corp. and others.
>
> The desktop, Dim. 8250, is a much more recent antique:
> Phoenix Rom Bios Plus version 1.10 A03 (c) 1985-1988
> (c) 1990-2003 Dell Computer Corp.
>
> -So this tells me the Phoenix core was licensed and augmented by
> Dell.

To me, that means 1998 and 2003, respectively. I.e., when they
were last updated.

> > I.e., in theory, a floppy boot sector for a pre-1996 machine
> > could use either Int 18h or Int 19h, while a floppy boot
> > sector for a post-1996 machine should use Int 18h. So, Int 18h
> > would seem to be the appropriate choice for both. The BBS also
> > discusses some other compatibility issues with use of Int 18h.
> >
>
> According to the Phoenix Technical Ref. I have (circa 1991),

> [...]

I still think Int 18h is the appropriate choice given your BIOS
dates (1998 and 2003). :-) Do you? I.e., 1996 BBS probably
applies to both your machines, or, at least, I would think so
based on the dates, although the 1998 might be borderline. I'd
seriously doubt either machine still has BASIC installed. To me,
the lack of BASIC would indicate one of the other spec.'s would be
more relevant.

> [quotes on POST]

Thanks for those.

Did you find the Phoenix Tech. Ref. I online?

Well, I've collected info from a few sources on 40:67h, 40:72h,
CMOS 0Fh from the Internet, Usenet, RBIL, etc. They're all
similar but slightly different. What I've not found much
information on is whether the 40:72h setting or CMOS 0Fh setting
takes precedence. Usually 00h is mentioned for cold boot at
40:72h, while 1234h is mentioned for warm boot. Everything else
at 40:72h seems to be custom or random. Most of the CMOS 0Fh
values seem to be fairly standard, but some sources mention other
values or list them as operating differently. But, I've not found
anything to indicate whether 40:72h needs to be 0 for CMOS 0Fh
values to work or whether CMOS 0Fh needs to be 00h for 40:72h to
work. I.e., how do they work together? I haven't had time to
play around with it and my old machines keep getting packed up for
lack of use or for extra space...


Rod Pemberton

[Rod Pemberton]

<s_dub...@yahoo.com> wrote in message
news:130572e3-d785-49eb...@n4g2000yqj.googlegroups.com...

> According to the Phoenix Technical Ref. I have (circa 1991),

> [... regarding 40:67h ...]

As for 40:67h, 40:72h, and CMOS 0Fh, I've found info regarding
them in a variety of places. These are all available online.

1) "IBM Personal System/2 and Personal Computer BIOS Interface
Technical Reference", September 1991, pg. 3-7, "Section 3: BIOS
Data Areas", ps2bios3.pdf

(It might be available on bitsavers.trailing-edge.com or
mcamafia.de. etc. under a different name.)

2) Page 8 of "Design Considerations for the Embedded PC" by
Eric Auzas via Intel
http://download.intel.com/design/intarch/papers/esc_empc.pdf

3) Mark Larson post in reply to me in "How to reboot a computer
immediately by programming" comp.lang.asm.x86 2006
https://groups.google.com/d/msg/comp.lang.asm.x86/z57rT2HEGm0/M3P9yOg2PC4J

4) RBIL (Ralf Brown Interrupt List) also has information.

RBIL has four relevant sections. The MEM and CMOS info are in
their respective files. That info won't be present in html-ized
versions of RBIL online. These are the section headers:

INT 19 - SYSTEM - BOOTSTRAP LOADER
MEM 0040h:0067h - RESET RESTART ADDRESS
MEM 0040h:0072h - POST RESET FLAG
CMOS 0Fh - IBM - RESET CODE (IBM PS/2 "Shutdown Status Byte")

5) Bob Little post to comp.os.msdos.programmer,comp.programming
1998
https://groups.google.com/d/msg/comp.os.msdos.programmer/399RhCvq5nw/IYt855XePjQJ

6) pre-cursor post to RBIL fj.os.msdos 1994
https://groups.google.com/d/msg/fj.os.msdos/nxNX08BI6xk/G9MtoTlKH44J

7) Ari Lukumies post to comp.lang.asm.x86 1998
https://groups.google.com/d/msg/comp.lang.asm.x86/ERAWZaBmFKQ/_FIb2INxhqYJ

8) trivial info from Intel on their Geode ... probably in a Geode
manual ... I'm not tracking it down ...


Rod Pemberton

[s_dub...@yahoo.com]

On Apr 13, 9:28 pm, "Rod Pemberton" <do_not_h...@notemailnotq.cpm>

No? Actually I don't know how to answer you. Let's see what int 18h
gives me instead: (bell) "strike F1 to try reboot, F2 for setup
utility".
Not what I want in this case, so the answer is no. (Pressing F1
reboots the floppy, as it is bootable.) (It could be what I want
later, but not here.)

What I do now is:

mov ah,0
int 16h
int 19h

which is a pause for any keypress, then reboot. About the same thing
without the bell and msg, with any keypress, execution procedes to
reboot.

> I.e., 1996 BBS probably
> applies to both your machines, or, at least, I would think so
> based on the dates, although the 1998 might be borderline.  I'd
> seriously doubt either machine still has BASIC installed.  To me,
> the lack of BASIC would indicate one of the other spec.'s would be
> more relevant.
>

I think you miss the point, none other than IBM had BASIC in ROM
hooked to int 18h. That BASIC was hooked to int 18h meant that there
wasn't a bootable floppy in A: (or that the cassette wasn't available
for booting) and the boot failure fallback was BASIC in ROM (it wasn't
a failure per se, the user just saw the BASIC signon). The bios clone
makers didn't/couldn't supply BASIC in rom like IBM did because they
might be sued by IBM (one reason). They did various other things with
int 18h, but consistant with 'boot failure fallback', AFAICT. The
historical background is needed to interpret some of the descriptions
of int 18h, 19h, to see that the descriptions are consistent, if
vague.

Take this description from the PhoenixBIOS 4.0 User's Manual
(Technical Reference) pg80;

int 18h - BIOS Secondary Boot Request.
int 19h - BIOS Primary Boot Request.

-pretty vague, even misleading, unless viewed in the context of the
above, 'boot failure fallback' for int 18h. One is apt to see 'BIOS'
as a category, and read 'Secondary Boot Request' as nearly equivalent
to 'Primary Boot Request' or worse, read 'Secondary (HD) Boot Request'
and 'Primary (Floppy) Boot Request' . But taken in the light of the
IBM historical use, Primary means first functional attempt, and
Secondary means second functional attempt, in order.

If you disagree with that characterization, then we just disagree.

> > [quotes on POST]
>
> Thanks for those.
>
> Did you find the Phoenix Tech. Ref. I online?

Sort of, it's a book picked up on ebay several years ago.

The 'PhoenixBIOS 4.0 User's Manual' was a download from their website,
which I no longer see there. They seem to have moved on to 64 bit,
uefi, and dropped legacy references altogether.

>
> Well, I've collected info from a few sources on 40:67h, 40:72h,
> CMOS 0Fh from the Internet, Usenet, RBIL, etc.  They're all
> similar but slightly different.  What I've not found much
> information on is whether the 40:72h setting or CMOS 0Fh setting
> takes precedence.  Usually 00h is mentioned for cold boot at
> 40:72h, while 1234h is mentioned for warm boot.  Everything else
> at 40:72h seems to be custom or random.  Most of the CMOS 0Fh
> values seem to be fairly standard, but some sources mention other
> values or list them as operating differently.  But, I've not found
> anything to indicate whether 40:72h needs to be 0 for CMOS 0Fh
> values to work or whether CMOS 0Fh needs to be 00h for 40:72h to
> work.  I.e., how do they work together?  I haven't had time to
> play around with it and my old machines keep getting packed up for
> lack of use or for extra space...
>

I tend to view BIOS dates like a 'layer level waypoint' because
backward compatibility is strived for, generally.

Steve

> Rod Pemberton