any BIOS call to reset ESCD ?

[NimbUs]

Good day, everybody ! This might not be /the/ group
appropriate for my question, but, I guess, it is as bad as any
other group so please, bear with me one more moment :

Is there an API/ABI for resetting "ESCD" configuration data
stored "in the BIOS" ? The reason I ask being I've got older
PCs with (AMI-based) BIOSes, whose "setup" options do NOT
include effecting such reset of (so called plug and play)
configuration data.

I've got non permanent but recurrent problems with otherwise
functional Windows 98 SE installations (systems also multiboot
other Windowses and *X) -
but the booting problem is specific to 98 Se,viz a freeze
while initialising ntkern.vxd. No problem of the kind in any
other OS, and for reasons I'm too lazy to present I'm almost
sure it's related to ESCD data recorded by "other" OSes
conflicting Windows 98 "ntkern"'s idea of plug and play.

No relevant solution or reference to "my" problem on the
internet ever... even back in time before MS worked /hard/ to
remove all useful references to Win9x solutions from the
tubes, including removing "knowledge base' articles not only
from their servers, but from the Web Archive !

Anyway... is there a documented or known BIOS call for
resetting ESCD, either BIOS agnostic or proprietary to AMI ?

Regards

--
NimbUs

[Rod Pemberton]

I'm not sure how that's done. This is entirely speculative.

In either case, it seems you need access to 16-bit RM or
16-bit PM, such as with a DOS .com or a via a custom
bootloader at 0:7C00h from floppy, CDROM, or USB, or 16-bit
PM via DPMI host in DOS or 16-bit PM Windows code (perhaps
"Standard Mode" on earlier versions, like version 3.0).


1) first method

far call PnP function 42h read ESCD
far call PnP function 43h write ESCD

It's possible that reading and then writing will do the
trick, i.e., update the ESCD upon next boot, but I simply
don't know if it will and I can't confirm. It might.
It might not.

There seem to be two documents by Phoenix, Compaq,
and Intel that define how to call those functions:

"Plug and Play BIOS Specification"
http://download.intel.com/support/motherboards/desktop/sb/pnpbiosspecificationv10a.pdf

"Extended System Configuration Data Specification"
http://www.singlix.com/trdos/escd.pdf

These say you need to search the BIOS on 16-byte boundaries
to find ASCII "$PnP" - without quotes - which indicates the
*possible* start of a data structure. Of course, if there
is no "$PnP" in the BIOS, it's definately not a PNP capable
machine. After finding the "$PnP" signature, you then perform
a checksum on the data structure. If the checksum is valid,
you can use the data in the structure. The structure contains
a 16-bit RM code segment and offset and 16-bit PM code base
address and offset for the far call above. As well as code
segments and offsets, the structure also has data offsets
needed for the supported modes. You must construct a
selector for 16-bit PM. I'm not sure what to do if
the checksum is invalid.


2) second method

Also, RBIL (Ralf Brown Interrupt List) lists these calls as
available on Int 1Ah for Intel BIOS/motherboards:

Int 1Ah,AX=B400h Installation check
Int 1Ah,AX=B401h Get default config table
Int 1Ah,AX=B402h Copy and verify config table (? optional)
Int 1Ah,AX=B403h Store ESCD table in NVRAM

RBIL Int 1Ah,Ah=B4h functions via DJGPP's website
http://www.delorie.com/djgpp/doc/rbinter/ix/1A/B4.html

Those functions are documented in Intel's document:

"Plug and Play BIOS Extensions Design Guide"

This document was part of a software package called:

"Plug and Play BIOS Enhancement Kit"

That package is _only_ available to OEMs and BIOS vendors ...

There is no information in RBIL if these functions became
standard in other BIOSes.


If attempting to use the BIOS functions, only call the
next call, if the prior call succeeds, i.e., carry flag
clear or AX set to zero. You might want to set the carry
prior to each call as an additional safety measure.

Note that RBIL says B403h and B402h need DS:SI to point
to the configuration table. However, RBIL says B401h
returns the address of the configuration table in EDI.
I'm not sure what format EDI is and there doesn't seem
to be any information on how EDI is converted to DS:SI.

B402h is called "copy and verify". I'm not sure what
the "verify" does, but it might be worth calling B402h
after B401h, if "verify" does something useful.

Unfortunately, since I don't have that document and they
aren't part of any other BIOS, PNP, or PCI standards and
protocols, I'm unable to clarify:
a) whether EDI can be broken into DS and SI
b) whether RBIL's information on B401h returning EDI is
correct, e.g., instead of DS:SI
c) if "verify" of B402h does anything useful
d) correct parameters and functionality of these calls


3) you tried those and something is wrong with your ESCD ...

I'm not sure what will happen if bad ESCD data is written
to NVRAM. About the only thing you can reset at that point
are the BIOS settings, but they should probably only be
reset after you've reset the motherboard's CMOS.

So, I'd be prepared to power down, unplug the machine, wait
fifteen seconds to allow the power supply's capacitors to
completely drain their stored power. A good way to verify
that is to turn numlock LED on (visible) prior to powerdown
and unplug the power cord. Once you're sure that the only
power source to the motherboard is the CMOS battery, unplug
the the CMOS jumper. This will usually be a 3-pin header
with the jumper connected to two pins. Connect the
unconnected pin and the nearest pin, usually the middle pin,
for a few seconds with the jumper. E.g., if 2 and 3 are
connected, connect 1 and 2. The short will reset the
motherboard CMOS BIOS settings. This header should be
marked, but may be difficult to see. It's usually near
the edge of the motherboard, nearest to the CMOS battery.
The CMOS battery looks like a disc, watch battery. Check
the diagram in the motherboard manual to be sure. After
the CMOS has been cleared, reset the jumper, power up,
boot again, enter your BIOS, set the BIOS settings again,
save, boot again.

Good luck,


Rod Pemberton

[NimbUs]

Rod Pemberton wrote in news:op.xo4walw3mk81un@localhost:
> NimbUs <nim...@xxx.invalid> wrote:
(...)

>> Is there an API/ABI for resetting "ESCD" configuration data
>> stored "in the BIOS" ? The reason I ask being I've got older
>> PCs with (AMI-based) BIOSes, whose "setup" options do NOT
>> include effecting such reset of (so called plug and play)
>> configuration data.

> I'm not sure how that's done. This is entirely speculative.

You've obviously taken much time and care to research and write an
extensive reply, for which I wish to thank you. See my remarks
interspersed below...

> In either case, it seems you need access to 16-bit RM or
> 16-bit PM, such as with a DOS .com or a via a custom
> bootloader at 0:7C00h from floppy, CDROM, or USB, or 16-bit
> PM via DPMI host in DOS or 16-bit PM Windows code (perhaps
> "Standard Mode" on earlier versions, like version 3.0).

Goes without the saying. Since this is needed only before booting to
Windows 98, I would be accessing the ESCD in real mode from a .com
program or a .sys DOS "device driver".

> 1) first method

> far call PnP function 42h read ESCD
> far call PnP function 43h write ESCD

> It's possible that reading and then writing will do the
> trick, i.e., update the ESCD upon next boot, but I simply
> don't know if it will and I can't confirm. It might.
> It might not.

Would that not be just reading & flashing back the /same/ config info
which for some reason hangs my Windoze ? What I'm wanting to achieve is
the /reset/ of BIOS PnP config, that some (most?) BIOSes offer an
option to do.

> There seem to be two documents by Phoenix, Compaq,
> and Intel that define how to call those functions:

> "Plug and Play BIOS Specification"
http://download.intel.com/support/motherboards/desktop/sb/pnpbiosspeci
ficationv10a.pdf
>
> "Extended System Configuration Data Specification"
> http://www.singlix.com/trdos/escd.pdf

> These say you need to search the BIOS on 16-byte boundaries
> to find ASCII "$PnP" - without quotes - which indicates the

> *possible* start of a data structure. (...)

I'm familiar with what little BIOS PnP calls & structures were publicly
exposed and with RBIL, whose last revision unfortunately was, when,
year 2000? I'm familiar with programming techniques, real mode as well
as protected mode... The problem, and you mentionned it too, is that
crucial parts of the APIs are not free or even cheap to get - and other
parts are proprietary, often OEM specific.

> 2) second method
>
> Also, RBIL (Ralf Brown Interrupt List) lists these calls as
> available on Int 1Ah for Intel BIOS/motherboards:
>
> Int 1Ah,AX=B400h Installation check
> Int 1Ah,AX=B401h Get default config table
> Int 1Ah,AX=B402h Copy and verify config table (? optional)
> Int 1Ah,AX=B403h Store ESCD table in NVRAM

> RBIL Int 1Ah,Ah=B4h functions via DJGPP's website
> http://www.delorie.com/djgpp/doc/rbinter/ix/1A/B4.html

This doesn't tell us what a typical BIOS does when "resetting ESCD
data" upon reboot at the request of a user :(
Someone with such a BIOS could try to unassemble and/or trace the
relevant parts of BIOS setup - not trivial, I reckon.

> Those functions are documented in Intel's document:
>
> "Plug and Play BIOS Extensions Design Guide"
>
> This document was part of a software package called:
>
> "Plug and Play BIOS Enhancement Kit"
>
> That package is _only_ available to OEMs and BIOS vendors ...

Exactly ! This is the crux (crooks ?) !

> There is no information in RBIL if these functions became
> standard in other BIOSes.

(...)

[For ROD's long digression see his post upthread]

> I'm not sure what will happen if bad ESCD data is written
> to NVRAM. About the only thing you can reset at that point
> are the BIOS settings, but they should probably only be

> reset after you've reset the motherboard's CMOS. (...)

Nope, I don't think so. In theory it is not prescribed where and how an
OEM keeps that ESCD between reboots, but in practice it's a dedicated
block off the BIOS "flash" EEPROM. Not the so-called CMOS RAM (much too
tiny !)
There might be a couple bits in CMOS RAM relating to the status of
ESCD, telling BIOS e.g. wether the latter is valid altogether, and
whether user has declared his OS as "plug and play". But, the ESCD
itself is in the flash RAM !

> Good luck,

Thanks. Actually, I've worked around the annoying NTkern lock up and a
problem with video drivers at the same time, by reverting the Win 98 SE
registry to a 3 yrs old backup plus some magic incantations and poured
sweat. I am aware however problems can and will come back...
Anyway I won't have to work hard to find how to reset the ESCD in the
immediate future.

Thanks again. Now posting from the repaired 98 SE :) Oh, this Windows
98 install is complicated by the fact that it is supposed to be able to
run either natively on the "bare metal" as well as, virtualised, in
VMware from the SAME, "raw" disk partition, of course with different
"hardware profiles". Endless source of fun and, sometimes... trouvle
:=)

--
NimbUs

[Rod Pemberton]

On Tue, 11 Nov 2014 06:34:56 -0500, NimbUs <nim...@xxx.invalid> wrote:
> Rod Pemberton wrote in news:op.xo4walw3mk81un@localhost:
>> NimbUs <nim...@xxx.invalid> wrote:

> Since this is needed only before booting to Windows 98,

> [...]

> config info which for some reason hangs my Windoze ?

What's the issue with Win98/SE?

Have you tried booting into DOS?

IIRC, F8 pulls up Win/DOS boot menu. Or, you can add
"BootMenu=1" in MSDOS.SYS [Options] section for Windows 98/SE.
MSDOS.SYS on other versions of MS-DOS is a binary file.

Have you tried to boot Windows safe mode?

Safe mode disables custom drivers. IIRC, that's WIN/D:M from
the DOS command prompt. Type WIN/? to see the options.

Also, you could try deleting the Windows swap file.
It ends in .swp IIRC. It may be in C:\windows directory
or C:\ .

>> It's possible that reading and then writing will do the
>> trick, i.e., update the ESCD upon next boot, but I simply
>> don't know if it will and I can't confirm. It might.
>> It might not.
>
> Would that not be just reading & flashing back the /same/
> config info which for some reason hangs my Windoze ?

Most likely, but the BIOS versions say "read default".
I take "default" to be something other than "current".
Of course, they're for Intel and it's unknown as to
which other BIOSes support them, if any, but it's a
simple .com to check the install call.

If you don't try, you won't know. I can cite numerous
errors in manuals, schematics, etc I've come across in
my programming history.

> What I'm wanting to achieve is the /reset/ of BIOS
> PnP config, that some (most?) BIOSes offer an
> option to do.

The BIOS settings determine what gets written to ESCD, yes?

The BIOS must determine what options to display, yes?

So, some of that info is in CMOS. Perhaps, someone shouldn't
so quickly dismiss resetting the CMOS until someone tries. ;-)

>> Also, RBIL (Ralf Brown Interrupt List) lists these calls as
>> available on Int 1Ah for Intel BIOS/motherboards:
>>
>> Int 1Ah,AX=B400h Installation check
>> Int 1Ah,AX=B401h Get default config table
>> Int 1Ah,AX=B402h Copy and verify config table (? optional)
>> Int 1Ah,AX=B403h Store ESCD table in NVRAM
>
>> RBIL Int 1Ah,Ah=B4h functions via DJGPP's website
>> http://www.delorie.com/djgpp/doc/rbinter/ix/1A/B4.html
>
> This doesn't tell us what a typical BIOS does when
> "resetting ESCD data" upon reboot at the request of a user :(

True.

> Someone with such a BIOS could try to unassemble and/or trace the
> relevant parts of BIOS setup - not trivial, I reckon.

That's about the only solution, but the solution may only work
for a specific BIOS brand. The ESCD spec. may specify the format
of the ESCD data.

Are NVRAM chips used by BIOS standardized? Maybe, maybe not.

Is the BIOS enable method, perhaps I/O ports, standardized? No.?

> [For ROD's long digression see his post upthread]

It's not a digression. See above comments on "default".

>> I'm not sure what will happen if bad ESCD data is written
>> to NVRAM. About the only thing you can reset at that point
>> are the BIOS settings, but they should probably only be
>> reset after you've reset the motherboard's CMOS. (...)
>
> Nope, I don't think so.

See above comment on not dismissing things unknown.

> Anyway I won't have to work hard to find how to reset the ESCD in the
> immediate future.

Why did reverting the Win98/SE registry fix your BIOS ESCD problem? :-)

...

From my experience with Win98/SE, that's seems like a driver issue.
Drivers can be bypassed by starting Win98/SE in safe mode. You can
then delete or disable them, just not install them. You may have to
cancel the installing of files when booting Windows, if the driver is
bad or wrong.

> Thanks. Actually, I've worked around the annoying NTkern lock up and a
> problem with video drivers at the same time, by reverting the Win 98 SE
> registry to a 3 yrs old backup plus some magic incantations and poured
> sweat. I am aware however problems can and will come back...
>

> [...]

>
> Thanks again. Now posting from the repaired 98 SE :) Oh, this Windows
> 98 install is complicated by the fact that it is supposed to be able to
> run either natively on the "bare metal" as well as, virtualised, in
> VMware from the SAME, "raw" disk partition, of course with different
> "hardware profiles". Endless source of fun and, sometimes... trouvle

s/trouvle/trouble English? French?

I usually disable scanning the system registry in MSDOS.SYS "SystemReg=0".
If you manually execute scanreg.exe once a month, it'll save backups in
C:\windows\sysbckup as .cab files of system.dat and user.dat. Then, you
can restore the registry when damaged.


MDGX archive
-unofficial Win98/SE final update package
-NUSB Win98/SE native usb drivers, etc.
http://www.mdgx.com/

The two most useful MDGX webpages:
http://www.mdgx.com/web.htm#98SE
http://www.mdgx.com/upd98me.php

Japheth's version of HIMEMX, a HIMEM replacement
http://www.japheth.de/Jemm.html

BearWindows VBEMP universal VESA 2.0 video drivers for Win98/SE and WinNT
http://www.navozhdeniye.narod.ru/vbe9x.htm
http://www.bearwindows.boot-land.net/vbemp.htm

KernelEx Win98/SE enhancement project executes WinNT/XP/2k etc apps
http://kernelex.sourceforge.net/

Kstub ("patches" for KernelEx)
http://www.msfn.org/board/topic/157173-kext-diy-kernelex-extensions/


Also, Japheth's website seems to be offline at the moment.
You can paste his link into Wayback archive. They've
indexed his website.
http://archive.org/web/web.php


Rod Pemberton